Avant de lancer un script communautaire sur votre hôte Proxmox : cinq choses à lire

Les scripts communautaires sont réellement bons. Ils portent un savoir que quelqu'un a payé en soirées perdues, ils gèrent les cas pénibles sur lesquels vous seriez tombé à minuit, et pour beaucoup de tâches le script vaut mieux que ce que vous auriez écrit. Cet article n'est pas un plaidoyer contre eux.

Il porte sur un écart précis. Une installation par paquet et un script collé en une ligne se ressemblent à l'écran, et ce ne sont pas du tout les mêmes choses.

Ce qu'un paquet donne et qu'une ligne collée ne donne pas

Une signature. Les paquets sont signés et la signature est vérifiée. Une URL n'est vérifiée que contre votre hypothèse que l'URL est la bonne.

Une version. Vous pouvez dire quelle version vous avez, et la personne qui vous aide aussi. « Le script du readme, il y a quelques semaines » n'est pas une version.

Un chemin de désinstallation. Les paquets consignent ce qu'ils ont posé et savent l'enlever. Un script pose souvent des fichiers à six endroits et n'en garde aucun souvenir.

Une relation avec un mainteneur. Quand un paquet change de comportement, il y a un journal des modifications. Un script peut changer sous la même URL sans rien laisser à lire.

Rien de tout cela ne rend les scripts mauvais. Cela en fait une autre sorte de chose, qui mérite une autre habitude.

Les cinq choses à lire

Pas tout le script, et pas ligne par ligne. Ces cinq réponses sont généralement visibles en une passe.

① Que touche-t-il en dehors de son propre répertoire ? Un script qui n'écrit que sous son dossier est facile à cerner. Un script qui modifie des fichiers dans les répertoires de configuration système fait des changements qui lui survivront.

② Ajoute-t-il un dépôt ou une clé ? C'est la ligne aux conséquences les plus lourdes dans la plupart des scripts et elle passe en une seconde. Ajouter une source de paquets signifie que toute mise à jour future sur cette machine fera confiance à une nouvelle partie. Cela peut être parfaitement raisonnable et cela devrait être une décision, pas un effet de bord.

③ Touche-t-il au démarrage, au noyau ou au réseau ? Ce sont les trois qui peuvent rendre un hôte injoignable ou non démarrable, et sur un hyperviseur cela veut dire que tout ce qui est dessus part aussi. Un script qui installe une application web n'a rien à faire dans la configuration du chargeur de démarrage, et s'il y touche, cela mérite d'être compris avant l'exécution.

④ Y a-t-il un retour en arrière ? Cherchez un chemin de désinstallation, ou à défaut la liste de ce qu'il a créé. Si aucun des deux n'existe, votre retour en arrière est un instantané pris avant, ce qui veut dire qu'il faut en prendre un.

⑤ Que se passe-t-il s'il tourne deux fois ? Beaucoup de scripts sont écrits pour une machine propre, et un second passage double des entrées, réinitialise une configuration que vous avez modifiée, ou échoue à mi-chemin en laissant un demi-état. Vous le lancerez deux fois un jour, généralement parce que le premier passage a semblé échouer.

La ligne collée, précisément

Le motif consistant à récupérer un script et à le tuber directement dans un shell a une propriété qui mérite d'être nommée : vous ne pouvez pas lire ce que vous avez exécuté. Non pas « vous ne l'avez pas fait », vous ne le pouvez pas, car cela n'a jamais été un fichier.

Il y a aussi une variante plus subtile. Lire le script dans votre navigateur et lancer la commande récupérer-et-tuber sont deux requêtes distinctes. Rien ne garantit qu'elles ont renvoyé les mêmes octets.

La solution coûte une étape en plus. Téléchargez le fichier, regardez-le, puis lancez la copie locale. Vous savez alors ce qui a tourné, vous pouvez relancer l'identique plus tard, et si quelque chose casse vous avez le texte réel plutôt que le souvenir d'une page web.

Un hyperviseur n'est pas un endroit où essayer

C'est ce qui sépare un hôte Proxmox d'un portable. Tout le reste de la machine se trouve en dessous. Un script qui met un portable dans un état bizarre vous coûte une soirée ; le même script sur un hôte emporte toutes les machines virtuelles.

Deux habitudes rendent presque tout cela sûr :

Lancez-le d'abord dans une machine virtuelle si c'est plausible. La plupart des scripts qui installent un service n'ont pas besoin d'être sur l'hôte. Ce n'est pas un contournement, c'est en général le bon endroit.

S'il doit vraiment tourner sur l'hôte, instantané d'abord. Non parce que le script est suspect, mais parce que « je vais juste essayer » est exactement la phrase qui précède le besoin d'un retour en arrière.

Ce que cet article n'est pas

Pas une raison de se méfier de la communauté. Les scripts partagés sont l'une des meilleures choses de cet écosystème, et les auteurs sont souvent plus prudents que ceux qui les exécutent.

Pas une raison de lire chaque ligne. Cinq questions en une passe suffisent à attraper la catégorie de surprise qui fait vraiment mal.

Ce que fait Atlas

Atlas prend un instantané avant les opérations qui modifient l'état de l'hôte, si bien que le retour en arrière existe sans que vous ayez à penser à le créer. Cela couvre l'étape quatre de la liste ci-dessus, celle que l'on saute.

Le journal d'audit enregistre qui a lancé quoi, quand, sur quoi et avec quel résultat, ce qui transforme « quelque chose a changé mardi dernier » en réponse lisible plutôt qu'en enquête.

La chaîne de ressources aide plutôt après coup qu'au moment de décider : si quelque chose se comporte différemment après une installation, la carte montre à quoi la machine ressemble maintenant, des invités jusqu'aux disques physiques.

Et là où Atlas installe lui-même des logiciels, via le catalogue d'applications, la version est figée, la source est fixe et un point de restauration est pris avant le début. C'est un chemin volontairement étroit et sélectionné, et il ne remplace pas les scripts communautaires. Ce sont simplement les mêmes cinq questions, répondues à l'avance pour les applications qu'il porte.