Pourquoi un bureau par SSH.

« Je peux déjà tout faire avec ssh et vim »

C'est vrai. Chacune des choses décrites sur cette page est possible avec une session SSH, un shell et un éditeur que vous connaissez déjà. Si vous administrez un seul serveur, que vim vous est naturel et que votre travail tient dans un terminal - ce n'est pas pour vous, et nous préférons que vous gardiez votre installation.

La couche graphique n'existe pas parce que le terminal serait insuffisant. Elle existe parce qu'un terminal est une interface séquentielle, et que certaines tâches ne le sont pas. Surveiller un transfert tout en lisant un journal tout en modifiant une configuration, c'est trois fenêtres dans n'importe quel bureau - et trois volets tmux plus beaucoup de discipline dans un terminal.

Où la couche graphique gagne vraiment sa place

Quatre situations, celles qui reviennent le plus.

• Déplacer des fichiers, et voir où ça en est. Copier un répertoire d'un endroit à un autre avec scp, c'est un curseur qui clignote et de l'espoir. L'explorateur le fait avec une file d'attente, un pourcentage par transfert et un renommage plutôt qu'un écrasement silencieux quand la destination porte déjà ce nom. Sur un dossier de 4 Go et une liaison lente, « est-ce que ça avance encore ? » est une vraie question.
• Lire du code que vous n'avez pas écrit. Modifier un fichier connu, c'est le travail de vim. Comprendre une base de code inconnue - passer d'un fichier à l'autre, suivre un include, chercher dans une arborescence - c'est le travail d'un arbre de fichiers et d'onglets. C'est ce qu'apporte un éditeur Monaco posé sur le système de fichiers distant, sans rien récupérer en local.
• Arriver sur un serveur qu'on n'a jamais vu. C'est le cas le plus fort. Termal détecte ce que la machine fait tourner - Plesk, cPanel, ou simplement nginx ou Apache -, liste les sites qu'elle sert avec la version de PHP réellement utilisée par chacun, montre les services et conteneurs actifs, et trouve les fichiers de journaux. Obtenir la même image à la main, c'est une douzaine de commandes et la connaissance des endroits où chaque distribution range les choses.
• Tester depuis la position réseau du serveur. Une route interne qui répond sur le serveur et nulle part ailleurs est malaisée à inspecter depuis un terminal. Le client HTTP exécute curlsur le serveur et présente les en-têtes et le corps. Le navigateur va plus loin : il sort de votre machine par défaut, mais vous pouvez basculer sa sortie réseau sur le serveur - le trafic passe alors par un tunnel SOCKS5 ouvert sur la connexion SSH que vous avez déjà, et une pastille dans la barre d'outils indique laquelle des deux est active. Avec les outils de développement ancrés par onglet, une page interne devient quelque chose qu'on regarde, plutôt que quelque chose qu'on déduit.

Tout cela sur une seule connexion

C'est le point qui compte du point de vue de l'architecture, et c'est pourquoi ce bureau n'est pas un simple habillage posé sur une poignée d'appels SSH.

Termal OS entretient un pool de connexions SSH réutilisées - une par serveur, avec un keepalive, et tout circule dessus : les métriques, l'explorateur de fichiers, le terminal, l'éditeur, le suivi des journaux. Ouvrir le gestionnaire de fichiers n'ouvre pas une seconde session. Aucun port supplémentaire, aucun agent, aucune seconde authentification, et rien d'installé sur la machine. Du point de vue du serveur, vous êtes une unique connexion SSH qui fait des choses ordinaires.

Cette contrainte est aussi ce qui permet au bureau de fonctionner sur des hébergements où vous n'avez ni root ni le droit d'installer quoi que ce soit : mutualisé, infogéré, le serveur d'un client. Un panneau d'administration graphique qui exigerait un démon y serait inutilisable.

Ce que contient réellement le bureau

Un gestionnaire de fenêtres avec barre des tâches, menu démarrer et icônes de bureau, et 23 applications. Celles qui font le travail :

• Explorateur - explorateur SFTP : copier, déplacer, envoyer, télécharger un dossier sous forme d'archive, permissions, glisser-déposer, file de transferts avec progression.
• Terminal - un véritable shell PTY, pas une simple boîte à commandes.
• Termal Code - Monaco (l'éditeur de VS Code) avec arborescence et onglets, éditant directement sur le système de fichiers distant.
• Navigateur - multi-onglets, favoris, téléchargements, affichage de la source, et outils de développement ancrés par onglet.
• Moniteur, Processus, Journaux - métriques en direct, liste de processus depuis laquelle on peut tuer une tâche, et suivi des journaux avec détection automatique des fichiers Apache, nginx, PHP, MySQL et syslog habituels.
• Requête web, Zip, Git, FTP, Corbeille - les petits outils qui, sinon, vous renvoient au shell en plein milieu d'une tâche.
• Copilote - des questions en langage courant, auxquelles répondent une commande et son explication. Rien ne s'exécute avant votre clic, et tout passe par votre propre clé d'API.

Il y a aussi un client de messagerie, des notes, une calculatrice, un convertisseur, un sélecteur de couleurs et quelques jeux. Treize des vingt-trois sont désactivées par défaut - seuls le magasin d'applications, les paramètres, l'explorateur et la corbeille sont permanents - parce qu'un premier lancement qui enfouirait l'explorateur sous un menu de jeux serait son propre argument contre l'idée entière. Activez ce que vous utilisez.

Ce que les développeurs devraient regarder

Le bureau est extensible, et son modèle d'extension est ce qu'il y a de plus intéressant dans le code.

Une application tierce s'exécute dans une iframe en bac à sable. Elle ne peut toucher ni au système de fichiers, ni au réseau, ni au presse-papiers directement. Chaque appel privilégié passe par un message vers l'hôte, qui le confronte aux permissions déclarées par l'application dans son manifeste - et il n'y en a que six : fs.read, fs.write, net, storage, clipboard, webview. Elles vous sont montrées au moment de l'installation. La règle inscrite dans l'en-tête du moteur est sans détour : l'iframe n'est jamais digne de confiance, l'hôte valide tout.

Cela compte davantage ici que dans la plupart des systèmes d'extensions, parce que ces applications s'exécutent contre des serveurs auxquels vous avez donné un accès SSH. Un magasin où une extension pourrait lire vos clés en silence serait indéfendable.

Et le SDK n'est pas une API séparée, au rabais, greffée pour les tiers : la calculatrice intégrée est enregistrée via Termal.app() - le point d'entrée public qu'utilise une application tierce. Huit exemples complets sont livrés avec le SDK, d'une application de notes à un hôte de webview en passant par un widget serveur.

La référence complète - manifeste, moteur d'exécution, boîtes de dialogue, sélecteurs de fichiers, stockage, réseau, webview, presse-papiers, contrôle de fenêtre, traductions, empaquetage - se trouve sur la page du Termal App Studio.

Ce qu'il n'est pas

• Pas un remplacement de votre terminal. Il en contient un, et vous l'utiliserez. Si votre travail tient déjà dans un shell, le bureau n'ajoute rien dont vous ayez besoin.
• Pas un protocole de bureau distant. Ni X11, ni VNC, ni RDP, ni serveur d'affichage du côté de votre machine. Le gestionnaire de fenêtres tourne localement, dans l'application ; seuls les fichiers, le shell et les métriques traversent la connexion SSH.
• Pas actif en permanence. La collecte continue fenêtre fermée, mais l'application doit tourner sur une machine allumée. Refermez le portable et elle s'arrête - voyez la comparaison avec Netdata, où ce point pèse le plus.
• Pas fait pour mille serveurs. De quelques-uns à quelques dizaines. Linux par SSH uniquement : pas de SNMP, pas de Windows, pas de découverte réseau.