Le nom du serveur : choisissez-le à l'installation, puis n'y touchez plus

Vous tapez un nom pendant l'installation. À cet instant cela paraît sans importance, car un nom est d'habitude une étiquette.

Pas ici. Sur Proxmox le nom du serveur est une adresse, et le changer plus tard est un travail bien plus lourd que vous ne l'imaginez.

Où le nom est utilisé

La configuration vit dans un dossier portant ce nom. Les définitions de vos machines se trouvent sous ce dossier. Changez le nom et les définitions restent sous l'ancien.

Les fichiers des graphiques d'historique portent son nom. Changez le nom et un fichier neuf et vide est ouvert pour le nouveau nom. Les anciennes données ne sont pas supprimées, mais plus personne ne les regarde. Ce que vous voyez dans le panneau, c'est un serveur sans passé.

Dans un cluster, les membres sont reconnus par leur nom. Renommer un nœud revient, du point de vue du cluster, à détruire ce nœud et à en mettre un neuf à sa place.

Les certificats contiennent le nom. Changez-le et vous obtenez un avertissement du navigateur, puis vous partez en chercher la raison.

Voilà pourquoi renommer n'est pas une opération cosmétique

Sur un serveur seul c'est laborieux : il faut déplacer la configuration, réorganiser les services, réémettre le certificat.

Dans un cluster, ce que l'on fait réellement n'est pas un renommage : vous sortez le nœud du cluster et le réintégrez sous le nouveau nom. Autrement dit c'est le même travail qu'une reconstruction, sous une autre étiquette.

Bref, la décision prise à l'installation est celle dont le retour en arrière coûte le plus cher. Elle vaut cinq minutes de réflexion.

Au moment de choisir un nom

Court et en minuscules. Même si vous tapez un long nom de domaine, c'est la première partie qui sert ; écrire le reste n'apporte rien.

Rendez-le durable. Ne mettez pas le rôle dans le nom. La machine qui est serveur de sauvegarde aujourd'hui peut être le serveur principal demain, et vous vous retrouvez avec un serveur principal appelé « sauvegarde ». Idem pour l'emplacement en baie, le nom du client, le nom du projet : tout cela peut bouger, la machine non.

Parlant mais neutre. Assez pour distinguer deux machines, pas assez pour raconter une histoire.

Si les graphiques se sont vidés

C'est ici que cet article gagne sa place. Le panneau fonctionne, les machines tournent, mais les graphiques d'historique paraissent vides.

Le premier endroit à regarder est le nom du serveur. Si le nom et celui que le système attend ont divergé, le fichier de graphique n'est pas trouvé là où on le cherche et l'écran revient vide. Rien ne lève d'erreur, car techniquement il n'y en a pas : le fichier cherché n'existe pas, c'est tout.

Ce que fait Atlas

Derrière cet article il y a un défaut du produit lui-même, et il mérite d'être raconté.

Dans Atlas, le nom du serveur était résolu à cinq endroits distincts, et trois d'entre eux portaient le même défaut : quand la source était momentanément injoignable, le nom était inventé. Une valeur par défaut répandue était inscrite et gardée en mémoire pour toute la durée du processus.

On a mesuré, et deux choses en sont sorties.

La première : une fois la valeur inventée inscrite, le fait que le bon nom devienne disponible plus tard ne servait plus à rien, car la vérification en mémoire se trouve tout en haut. Un raté momentané se transformait donc en une mauvaise réponse permanente.

La seconde, et la plus sournoise : la conséquence d'un mauvais nom n'était pas la même partout. Les graphiques des machines invitées continuaient à fonctionner, parce que ces fichiers sont adressés par numéro de machine et que le nom n'est jamais vérifié. Les graphiques du serveur lui-même se vidaient, parce que le chemin du fichier contient le nom. L'état du serveur et la liste des machines tombaient aussi.

Le symptôme était donc mêlé : certains graphiques pleins, d'autres vides. Personne, devant un tel tableau, ne soupçonne le nom.

La correction s'est ramenée à trois règles. Pas d'invention : si c'est inconnu, on dit que c'est inconnu. Seul un nom vérifié est gardé en mémoire : une valeur venue de la voie de secours est utilisée mais pas stockée, si bien que l'appel suivant réessaie. La voie de secours est le nom propre de la machine, car sur Proxmox les deux sont déjà identiques.

La leçon générale

Ailleurs dans ce wiki nous avons écrit : une réponse vide et une absence de réponse ne sont pas la même chose.

Le défaut ici est d'un cran pire : mettre une valeur par défaut d'apparence plausible à la place de quelque chose d'inconnu. Une liste vide est au moins bizarre, et le bizarre se remarque. Un nom inventé n'est pas bizarre, il a l'air parfaitement correct, et donc personne ne le regarde.

Et s'il est ensuite stocké, une panne temporaire devient permanente.

On peut l'écrire comme une règle : une valeur par défaut est bonne là où elle est vraiment la valeur par défaut ; là où elle tient lieu d'inconnu, c'est un mensonge.