Si le fichier de configuration d'une machine casse : où se trouve l'ancienne version

Chaque machine virtuelle et chaque conteneur possède un petit fichier texte. Combien de cœurs, combien de mémoire, quel disque, quel réseau : tout est là, écrit sous une forme lisible par un humain.

Que se passe-t-il si ce fichier casse, où est l'ancienne version, et à quoi faut-il faire attention si vous le modifiez à la main ?

D'abord la bonne nouvelle : un fichier cassé n'affecte que sa propre machine

Chaque machine a son propre fichier. Une faute de frappe dans l'un ne fait pas tomber le panneau, n'arrête pas les autres machines, n'affecte pas le serveur.

Le symptôme est généralement celui-ci : cette machine n'apparaît plus dans la liste, ou refuse de démarrer. Tout le reste continue de fonctionner normalement. Sachez-le avant de paniquer, car la première impression est en général « le système est cassé », et ce n'est pas le cas.

Comment il casse

La modification à la main. C'est la cause la plus fréquente. Une virgule, un guillemet, un nom de clé mal orthographié.

La modification pendant que la machine tourne. Même si le fichier ne casse pas, il se passe quelque chose d'inattendu : votre changement prend effet au prochain démarrage alors que vous le croyez immédiat. Ou bien le système met lui-même le fichier à jour et écrase ce que vous avez écrit.

Une écriture interrompue en cours de route. Le courant saute, le disque se remplit, le processus est tué. Le fichier reste à moitié fait.

Le troisième est le plus sournois et mérite son propre titre.

Un fichier à moitié écrit est pire que pas de fichier du tout

Si un fichier est absent, c'est un état évident. Un programme regarde, ne le trouve pas, dit « pas là » et continue avec des valeurs par défaut. Cet état se traite facilement.

Un fichier à moitié écrit n'est pas comme ça. Il ressemble à un fichier. Le programme vérifie son existence, le trouve, lui fait confiance, et essaie de travailler avec les données incomplètes qu'il contient. L'ennui n'apparaît pas au moment de la lecture, mais après.

La solution est simple et vaut pour toute écriture : n'écrasez pas le fichier directement. Écrivez d'abord sous un nom temporaire, puis déplacez-le à sa place. Un déplacement se fait entièrement ou pas du tout ; il n'y a pas d'entre-deux. Ainsi le contenu du fichier est soit l'ancien, soit le nouveau, jamais la moitié.

Si vous écrivez un script qui touche à la configuration de Proxmox, cette seule habitude vaut plus que tout le reste du code que vous écrirez.

L'ancienne version se trouve à deux endroits

Dans la sauvegarde. La sauvegarde d'une machine emporte non seulement le disque mais aussi le fichier de configuration tel qu'il était à ce moment. Quand vous restaurez la sauvegarde, la configuration revient aussi. La plupart des gens pensent à une sauvegarde comme à des données seulement, et ne réalisent jamais qu'ils tiennent là un chemin de récupération.

Dans l'instantané. Quand vous prenez un instantané, la configuration de ce moment est écrite dans une section nommée du même fichier. Le fichier porte donc une partie de sa propre histoire en lui.

Mais ces deux-là ne se remplacent pas, et la différence compte : l'enregistrement de l'instantané se trouve à l'intérieur du même fichier. Si le fichier lui-même est détruit, cet enregistrement part avec. Une sauvegarde est ailleurs. Le vrai chemin de récupération est la sauvegarde ; un instantané n'est qu'un point auquel vous pourriez vouloir revenir.

Si vous modifiez à la main

Arrêtez d'abord la machine.

Faites une copie avant de modifier, et mettez cette copie ailleurs. L'endroit où vit la configuration a été conçu pour de la configuration ; n'y laissez pas de sauvegardes.

Après le changement, démarrez la machine et voyez qu'elle fonctionne vraiment. Ne remettez pas cela au prochain redémarrage en oubliant ; une modification inachevée oubliée revient des mois plus tard sous forme de panne que personne ne relie à quoi que ce soit.

La règle générale : « fichier absent » et « fichier cassé » sont deux états distincts

Le chemin de récupération d'un programme est en général écrit avec l'état « fichier absent » en tête, parce que c'est celui qui vient d'abord à l'esprit. L'état « le fichier est là mais son contenu est cassé » ne vient pas à l'esprit.

Or c'est le second qui est vraiment dangereux, justement parce qu'il n'a pas été envisagé. Et les deux ne se ressemblent pas : un fichier absent porte un marqueur, un contenu cassé non.

Ce que fait Atlas

Atlas tient quelques petits fichiers de réglages qui lui sont propres, et il y a ici plusieurs choses à raconter honnêtement, car toutes ont été trouvées en mesurant.

Deux fichiers frères se comportaient différemment. L'un se réparait tout seul quand son fichier était corrompu : il mettait le cassé de côté et repartait propre. L'autre non : il levait une erreur et s'arrêtait là, c'est-à-dire que cette fonction devenait définitivement inutilisable, sans aucun moyen pour l'utilisateur de la réparer depuis le produit.

La cause était exactement la règle ci-dessus : la branche de récupération avait été écrite pour l'état « fichier absent ». Une erreur de contenu cassé ne porte pas ce marqueur, donc la branche ne l'attrapait pas et l'erreur s'échappait vers le haut.

Les copies mises de côté n'étaient jamais nettoyées. Chaque événement de corruption laissait un fichier permanent, sans limite de nombre. Mesuré sur une machine en service : deux d'entre elles traînaient là depuis des mois. C'est la même règle qu'ailleurs dans ce wiki : tout ce qui écrit doit avoir un plafond.

Deux mises de côté au même instant produisaient le même nom et la deuxième copie écrasait la première, si bien qu'une version cassée disparaissait en silence.

Tout a été corrigé, et une règle a été posée sur la mise de côté elle-même : elle ne lève jamais d'erreur, en aucune circonstance. La mise de côté est une étape de récupération, et une étape de récupération ne doit pas devenir une nouvelle source de panne. Cette phrase paraît petite, mais c'est celle que devrait afficher au mur quiconque écrit du code de récupération.