La commande qui enlève l’avis d’abonnement : la ligne la plus répandue, le dégât le plus discret

La première chose que tout le monde rencontre après l’installation est l’avis d’abonnement, et la première solution que tout le monde trouve est une commande d’une ligne. La version répandue de cette commande a été mesurée : elle peut casser toute la bibliothèque de l’interface.

AtlasPVE ·

Cette fiche répond à

  • proxmox enlever avis abonnement
  • proxmox no valid subscription
  • proxmox post install script
  • que faire après l’installation de proxmox
  • proxmox supprimer le nag

Vous avez installé Proxmox, vous vous êtes connecté et l’avis d’abonnement est apparu. Il agace, car il revient à chaque connexion. Vous cherchez, vous trouvez une commande d’une ligne. Elle semble marcher.

Cet article parle de cette commande, mais son vrai sujet n’est pas la commande : le coût discret de coller quelque chose qu’on ne comprend pas.

L’erreur mesurée

Il y a un vrai défaut dans la ligne largement diffusée, et ce défaut est subtil.

Dans les expressions régulières de base des outils de texte classiques, une barre verticale écrite avec une contre-oblique n’est pas un caractère ordinaire, c’est l’opérateur d’alternative. La condition dans le code de l’interface contient deux barres verticales, et quand la commande les échappe telles quelles, une alternative vide apparaît entre deux opérateurs d’alternative.

Une alternative vide correspond à chaque position du fichier. Exécutée avec « tout remplacer », l’expression sème la modification dans le fichier entier.

Ce n’est pas une supposition. Cela a été mesuré sur une copie du vrai fichier : 26458 lignes sur 26458 ont changé, et le nombre de false dans le fichier est passé de 558 à 26458. L’administrateur qui a lancé cette commande aurait cassé toute la bibliothèque d’interface de Proxmox.

S’y ajoute un second problème : la condition visée ne tient pas sur une ligne, Proxmox l’étale sur six. Un outil travaillant ligne par ligne n’aurait de toute façon jamais pu la viser correctement.

Pourquoi personne ne l’a remarqué

Parce que le dégât est silencieux. La commande ne renvoie pas d’erreur, rien ne s’allume en rouge. L’interface peut continuer de marcher un temps, l’ennui apparaît plus tard, et à ce moment personne ne fait le lien avec « la commande que j’ai collée la semaine dernière ».

La leçon générale : « ça marche chez tout le monde » n’est pas une preuve. Le plus souvent c’est seulement la preuve que personne n’a regardé.

Quatre règles pour toute modification de ce type

Toute opération qui touche un fichier système, quel qu’en soit l’auteur, doit porter ces quatre points.

La sauvegarde est prise une fois et jamais écrasée. La rafraîchir à chaque exécution revient, à la deuxième, à sauvegarder l’état cassé.

La visée est étroite. Si le texte visé a réellement changé, l’opération n’est pas effectuée. Modifier au jugé ce qui s’en rapproche est pire que ne rien modifier.

On relit le fichier après écriture. Si le résultat attendu n’apparaît pas, la sauvegarde est restaurée. Qu’une écriture n’ait pas échoué ne veut pas dire qu’elle a écrit la bonne chose.

On laisse une marque. La question « ce fichier est-il modifié » doit trouver réponse dans la présence d’une marque, pas dans une supposition.

Le cas auquel personne ne pense : et si la sauvegarde est déjà cassée

Même en faisant les quatre, il reste une faille. Et si un autre outil avait cassé le fichier plus tôt et que vous ayez pris la sauvegarde après ?

Alors le retour en arrière ramène le fichier cassé et vous croyez avoir corrigé. C’est pourquoi le retour doit lui aussi être vérifié : l’original est-il vraiment revenu, ou la sauvegarde elle-même était-elle déjà modifiée ?

C’est un exemple de la question qu’il faut se poser sans cesse quand on travaille sur une machine déjà installée : non pas ce qui se passe sur une installation neuve, mais ce qui se passe sur une machine porteuse d’un ancien état.

Ce que fait Atlas

Atlas fait ce travail dans le produit plutôt qu’en collant une commande, et il applique les quatre points ci-dessus.

La sauvegarde est prise une fois et n’est pas écrasée. La visée est étroite : un motif souple sur les espaces mais fidèle pour le reste, si bien qu’il tient encore si Proxmox change la mise en forme, mais si la condition elle-même a changé, rien n’est fait. Après écriture, le fichier est relu et vérifié ; si le résultat attendu n’apparaît pas, la sauvegarde est restaurée. Et le texte mis en place porte une marque, de sorte que la question « est-ce modifié » trouve une réponse certaine.

Côté retour en arrière, le dernier cas est traité aussi : après restauration de la sauvegarde, on vérifie que l’original est bien revenu, et sinon on le dit clairement.

La seule phrase que cet article veut vraiment dire est celle-ci : le travail n’est pas difficile, mais la différence entre bien le faire et sembler fonctionner passe par la mesure.

Sources

La documentation officielle de Proxmox. En anglais, et c’est elle qui a le dernier mot sur ce sujet.

Fiches liées

À quoi cela ressemble dans Atlas ?

Aller à la page produit