Console, shell et SSH : trois portes distinctes vers la même machine

Vous n'arrivez plus à joindre une machine. Avant de paniquer, posez une seule question : quelle porte utilisiez-vous ?

Il existe trois portes distinctes vers la même machine, et chacune dépend de choses différentes. Savoir laquelle s'est fermée vous dit directement où se situe le problème.

Trois portes

La console. Regarder l'écran et le clavier de la machine. L'équivalent d'aller devant un serveur physique et d'y brancher un moniteur. Elle n'utilise pas le réseau de l'invité, elle passe par l'hôte.

Le shell. Taper une commande et récupérer une sortie. Il n'imite pas un écran, il ouvre directement un canal de commande.

SSH. Un service qui tourne dans l'invité. Il lui faut le réseau, il lui faut le service en marche, il lui faut des identifiants.

La règle : plus la porte est confortable, plus l'invité doit fonctionner

SSH est le plus confortable. Vous vous connectez depuis votre propre terminal, le copier-coller fonctionne, vous déplacez des fichiers. En échange il exige le plus : la configuration réseau doit être bonne, l'interface doit être active, le service doit tourner, le pare-feu doit l'autoriser, la clé ou le mot de passe doit être valide. Qu'un maillon de cette chaîne casse et la porte se ferme.

La console est la moins confortable. Vous regardez un écran dans un navigateur, et le copier-coller y est souvent pénible. En échange elle n'exige presque rien : le réseau de l'invité peut être cassé, le pare-feu peut tout bloquer, SSH peut ne pas être installé du tout, l'écran apparaît quand même. Parce que cet écran vient de l'hôte, pas du réseau de l'invité.

C'est pour cela que la console est un chemin de secours. Non parce qu'elle est confortable, mais parce qu'elle dépend de très peu de choses.

L'incident classique

Vous modifiez un réglage réseau. Vous l'appliquez. La connexion tombe et ne revient pas.

Ce que vous avez fait n'était peut-être même pas faux : parfois le réglage est correct et la session meurt simplement pendant que l'interface bascule. Mais maintenant vous ne joignez plus la machine par le réseau, et pour réparer il faudrait justement joindre la machine.

Vous ouvrez la console, l'écran apparaît, vous corrigez le réglage. Comme elle n'est jamais passée par le réseau, le réseau cassé ne l'a pas touchée.

L'habitude pratique qui en découle : vérifiez que la console s'ouvre avant de toucher à un réglage réseau. Faites le travail risqué en tenant déjà un chemin de secours qui marche, plutôt que d'en chercher un après coup.

Côté shell, un conteneur et une machine virtuelle ne sont pas la même chose

Cette distinction surprend beaucoup de monde, car dans le panneau les deux sont côte à côte et proposent le même bouton.

Dans un conteneur l'hôte peut entrer directement. Le conteneur partage le noyau de l'hôte, donc les processus qui s'y trouvent sont déjà visibles pour l'hôte. L'hôte peut y exécuter une commande sans rien demander à l'intérieur.

Dans une machine virtuelle cela ne marche pas ainsi. Une machine virtuelle est une boîte scellée : l'hôte voit son disque et sa mémoire comme des blocs et ignore ce qu'ils contiennent. L'hôte ne peut pas pousser une commande dans la boîte.

Le seul chemin est qu'une chose à l'intérieur écoute. C'est exactement ce qu'est l'agent invité : un petit service installé dans la machine virtuelle, qui écoute les demandes de l'hôte et y répond. S'il n'est pas installé, la porte du shell n'existe pas pour cette machine virtuelle, et ce n'est pas une panne, c'est une conséquence de l'architecture.

Pour la même raison le shell ne fonctionne pas quand une machine virtuelle est éteinte. Il n'y a rien pour écouter. La console, elle, affiche aussi l'écran d'une machine éteinte, et quand vous la démarrez vous voyez ce qui se passe dès la première seconde.

La console a aussi ses limites

Pour être honnête, la console n'est pas magique.

Si l'hôte lui-même est éteint, les trois portes sont fermées. La console passe par l'hôte, donc elle part avec lui.

Autre chose : la console vous donne un écran, pas des fichiers. Si vous devez sortir un fichier, la console est un mauvais outil. Bonne pour le secours, pas pour le travail quotidien.

Enfin, l'accès console est une autorisation distincte. Qu'un utilisateur puisse lire le panneau ne signifie pas qu'il peut regarder les écrans des machines, et cette séparation est voulue : un écran montre le contenu du travail en cours.

Ce que fait Atlas

Atlas ouvre la console depuis son propre écran, sans demander une seconde connexion. Cela paraît anodin, mais il y a derrière une histoire qui mérite d'être racontée honnêtement.

La console vit en réalité à l'adresse propre du panneau Proxmox. Atlas est à une autre. Pour un navigateur ce sont deux sites distincts, et la session de l'un ne passe pas d'elle-même à l'autre. Sans rien faire, l'utilisateur qui appuie sur le bouton console obtient une erreur "pas de session" et on lui demande de se connecter au panneau une deuxième fois.

La première solution était celle-ci : transmettre la session au panneau depuis un cadre invisible. Cela marchait. Puis les navigateurs ont durci leurs règles sur les cookies tiers et cela a cessé de marcher. Il n'y avait aucun bug dans le code ; le sol sous lui avait bougé.

La deuxième solution est restée parce qu'elle est plus solide : la console est servie depuis l'adresse propre d'Atlas. Le navigateur voit un seul site, il ne reste aucune session à transmettre, et le problème disparaît à sa source.

Deux détails petits mais honnêtes : les en-têtes qui posent des cookies dans les réponses venant du panneau sont retirés, donc Atlas n'accumule pas de cookies du panneau à sa propre adresse. Et la connexion vers le panneau reste à l'intérieur de la machine, elle ne sort jamais sur le réseau.

La leçon générale, indépendamment de tout produit : une solution qui marchait et cesse de marcher ne signifie pas toujours un bug. Parfois c'est une hypothèse sur laquelle vous vous appuyiez qui a changé. La solution qui dure est celle qui s'appuie sur le moins d'hypothèses.