Montages persistants : la seule ligne qui peut empêcher une machine de démarrer

Vous montez un disque ou un stockage réseau à la main, et cela marche. Vous redémarrez la machine et c’est parti.

La solution est évidente : ajouter une ligne à la liste de ce qui est monté au démarrage. Et c’est exactement là que commence le danger.

Ce fichier n’est pas comme les autres

La plupart des fichiers de configuration du serveur, quand ils sont cassés, empêchent un service de fonctionner. Quand ce fichier est cassé, la machine peut ne pas démarrer.

Le résultat n’est pas « le service est tombé » mais « le système est tombé dans un shell de secours ». Et à ce moment-là vous ne pouvez plus vous connecter à distance ; il vous faut un clavier et un écran ou une console physique.

Le déséquilibre que personne ne remarque

Une configuration réseau cassée est agaçante : vous perdez l’accès distant. Mais la machine démarre quand même.

Une ligne de montage cassée peut empêcher la machine de démarrer du tout.

Et pourtant les gens sont bien plus prudents en modifiant le fichier réseau. L’ordre du danger est l’inverse de l’intuition, et c’est l’intuition qui a tort.

Trois règles

Vérifiez la structure avant d’écrire. Une ligne demande au moins trois champs : la source, la cible et le type de système de fichiers. Une ligne à laquelle il manque des champs donne du fil à retordre à tout outil qui lit le fichier.

Écrivez de façon atomique. Une écriture à moitié faite est pire dans ce fichier que pas d’écriture du tout : il reste un fichier tronqué, et la machine essaie de démarrer avec.

Ne laissez pas un disque absent prendre la machine en otage. Pour les stockages réseau et les disques amovibles, utilisez l’option qui laisse le démarrage se poursuivre quand le montage échoue. Qu’un disque de sauvegarde ne soit pas branché n’est pas une raison pour que le serveur ne démarre pas.

Le piège de la vérification : un contrôle qui plante n’est pas un contrôle réussi

La leçon la plus générale de cet article est ici, et elle ne vaut pas que pour ce fichier.

Il existe un outil standard pour valider ce fichier. Mesuré sur une vraie machine, voici ce qui est ressorti : l’outil plante quand il voit une ligne comportant moins de trois colonnes. Autrement dit, il explose précisément quand il voit la forme incorrecte qu’il est censé attraper.

Qu’un outil de vérification plante ne veut pas dire que la vérification est passée. La bonne réponse n’est pas « pas de problème » mais « impossible de vérifier ».

Un processus qui ne fait pas cette distinction approuve le fichier le plus dangereux à son moment le plus faible.

Le deuxième piège : toute plainte n’est pas une erreur

Le même outil de validation peut dire deux choses différentes, et les confondre crée un nouveau problème.

Une erreur de format veut dire que le fichier n’est pas lisible. C’est vraiment dangereux et l’écriture doit être annulée.

Une plainte sémantique est autre chose : des choses comme « cible inaccessible au démarrage » ou « type de système de fichiers inconnu ». Elles ne corrompent pas le fichier et peuvent être légitimes. Ajouter une ligne pour un appareil pas encore branché est courant et correct ; l’option qui laisse le démarrage se poursuivre existe justement pour cela.

Un contrôle qui met les deux dans le même panier rejette une ligne toute neuve et parfaitement valide. Autrement dit, une porte trop stricte rend le travail impossible et pousse les gens à couper la porte.

Ce que fait Atlas

Dans Atlas, toute écriture dans ce fichier passe par une seule porte. Chaque ligne est contrôlée structurellement avant l’écriture, l’écriture est atomique, et après l’écriture le fichier est relu et vérifié ; si le résultat attendu n’apparaît pas, l’état précédent est restauré.

Les deux pièges ci-dessus sont traités délibérément. L’outil de validation externe ne compte que comme signal secondaire : s’il plante, le résultat n’est pas « propre » mais « impossible de vérifier ». Et les erreurs de format et les plaintes sémantiques sont traitées séparément ; seule une erreur de format entraîne une annulation, tandis que les plaintes sémantiques ne sont pas avalées mais signalées à l’appelant.

La nécessité de cette distinction a elle aussi été trouvée par la mesure : dans la première version les deux entraînaient une annulation, et dans cet état même une ligne toute neuve et entièrement valide était rejetée.

Une note honnête sur l’histoire : le produit écrivait autrefois dans ce fichier depuis huit endroits différents, et aucun ne vérifiait que ce qui était écrit était valide ; deux d’entre eux réécrivaient tout le fichier de façon non atomique. Dans le même produit, le fichier réseau, qui ne peut pas empêcher la machine de démarrer, était écrit de façon atomique. Le fichier le plus dangereux était donc le moins protégé. Cela a été mesuré et ramené derrière une seule porte.