cloud-init n est pas un logiciel d installation : c est une SOURCE DE VERITE EXTERNE. Il se reveille a chaque demarrage et relit le lecteur attache par l hyperviseur, qui peut redefinir comptes, cles SSH, mots de passe et reseau. Sur une machine que le plan possede, c est un second maitre — que le plan ne decrit pas, que make valider ne mesure pas, et qui parle en premier. Sa tache est finie a la premiere seconde : c est parce qu il a REUSSI a poser l adresse et les cles qu Ansible a pu entrer. TROIS MOITIES, ET ELLES SE DEFONT SEPAREMENT. - le GABARIT le garde : sans lui un clone n a ni adresse ni nom ; - le SOCLE ne l installe plus : le garder produisait un va-et-vient a chaque deploiement, deux changed par passage, idempotence perdue ; - le DURCISSEMENT le retire (roles/cloud_init_retrait, en dernier). P63 garde les trois, plus le CONTENU du role : une coquille vide passerait les trois premiers controles sans rien fermer. Quatre controles negatifs rejoues. CE QUI REND LE RETRAIT SUR EST MESURE, PAS SUPPOSE (obs-01, 2026-09-09) : /etc/network/interfaces.d/50-cloud-init n appartient a aucun paquet — dpkg -S ne le trouve pas — et le postrm ne le nomme jamais, meme en purge. L adresse survit. Le role le verifie quand meme, avant et apres, et n accuse que si le retrait l a emporte : une VM qui perd ce fichier ne se plaint pas, elle repart sans adresse et plus personne ne peut entrer. DEUX CHOIX DITS FRANCHEMENT. cloud-guest-utils reste (growpart : ni service, ni port, ni source de donnees). Les ~29 paquets orphelins ne sont pas retires par defaut : autoremove deciderait a partir des drapeaux dpkg, et un durcissement ne doit pas pouvoir surprendre. NON DEPLOYE : le code est ecrit, valide et prouve ; il n a pas ete applique a la flotte. Essai a blanc sur obs-01 : cloud-init a retirer, configuration reseau intacte. make prouver : CONFORME, 62 OK, 0 echec, 1 saute (63 preuves). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q |
||
|---|---|---|
| .. | ||
| defaults | ||
| tasks | ||
| README.md | ||
cloud_init_retrait
Retire cloud-init des machines déployées, dans le groupe serveur_durci.
Pourquoi. cloud-init est une source de vérité externe : à chaque démarrage il
relit le lecteur cloud-init attaché par l'hyperviseur, qui peut redéfinir comptes, clés
SSH, mots de passe et réseau. Sur une machine qu'Ansible possède, c'est un second maître
que le plan ne décrit pas et que make valider ne mesure pas.
Pourquoi c'est sans risque. Mesuré le 2026-09-09 sur obs-01 :
/etc/network/interfaces.d/50-cloud-init n'appartient à aucun paquet (dpkg -S ne le
trouve pas) et le postrm de cloud-init ne le nomme jamais, même en purge. L'adresse
posée à la naissance survit. Le rôle le vérifie plutôt que de le supposer, et refuse
d'aller plus loin si le fichier a disparu.
Ce qui n'est pas retiré. cloud-guest-utils (growpart) : aucun service, aucune
source de données, aucun pouvoir. Le retirer ne fermerait rien.
Le gabarit garde cloud-init — il est le seul chemin vers la première seconde d'un
clone (P56). Le retrait n'intervient qu'après, sur la machine déployée. C'est pourquoi
serveur_debian ne l'applique plus : sinon le socle l'installerait et le durcissement le
retirerait à chaque passage, un va-et-vient à chaque déploiement. P63 garde les trois
moitiés de cette décision.