durcissement : cloud-init nait avec la VM et ne lui survit pas
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
2026-09-09 09:25:42 -04:00
|
|
|
# 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.
|
|
|
|
|
|
D-85 : ce que le retrait de cloud-init NE ferme pas
La premiere redaction se lisait comme une emancipation. Elle n en est pas
une, et il valait mieux le dire que de laisser un lecteur presse en
conclure trop.
Retirer cloud-init n ote AUCUN pouvoir a l hebergeur. qemu-guest-agent est
au gabarit — il doit y etre (P56) — et l API Proxmox expose sur son dos,
sur toute VM vivante de la flotte, un pouvoir strictement plus grand que
le lecteur cloud-init. Releve le 2026-09-09 sur edge-mta-01, avec le jeton
du site : exec, exec-status, file-read, file-write, set-user-password,
shutdown.
Ce que D-85 ferme est donc precis et etroit : une reapplication
AUTOMATIQUE a chaque demarrage, depuis un support que le plan ne possede
pas et qu aucune preuve ne lit ; et le code de cloud-init lui-meme, un
interpreteur Python complet execute en root au boot avec ses ~29
dependances. La mainmise d un hyperviseur sur ses invites est une
propriete de la VIRTUALISATION, pas de cloud-init — elle appelle sa propre
decision, qui n est pas prise.
LE SEUIL EST NOMME. L alternative existe et sa piece est deja au gabarit :
poser adresse et cle par agent/file-write + agent/exec, sans reseau.
Aujourd hui ce serait reimplementer un standard, ce que positionnement.md
interdit, au moment le plus fragile et pour le pire mode de panne — une VM
injoignable. Le jour ou une premiere seconde ne pourra plus etre amorcee
par Proxmox (autre hyperviseur, metal nu, hebergeur sans API), ce chemin
devient LE chemin portable.
La nuance est portee partout ou l affirmation est faite : D-85, le README
et l entete du role, AGENTS.md, le wiki.
make prouver : CONFORME, 62 OK, 0 echec, 1 saute.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-09 10:11:52 -04:00
|
|
|
## Ce que ce rôle ne ferme PAS
|
|
|
|
|
|
|
|
|
|
Il **n'ôte aucun pouvoir à l'hébergeur**, et le croire serait la mauvaise leçon.
|
|
|
|
|
`qemu-guest-agent` est au gabarit — il doit y être (P56) — et l'API Proxmox expose sur son
|
|
|
|
|
dos, sur toute VM vivante, un pouvoir **strictement plus grand** que le lecteur
|
|
|
|
|
cloud-init : `exec`, `file-write`, `file-read`, `set-user-password`, `shutdown` (relevé le
|
|
|
|
|
2026-09-09 sur `edge-mta-01`).
|
|
|
|
|
|
|
|
|
|
Ce que ce rôle ferme est précis et étroit :
|
|
|
|
|
|
|
|
|
|
1. une réapplication **automatique, à chaque démarrage**, depuis un support que le plan ne
|
|
|
|
|
possède pas et qu'aucune preuve ne lit ;
|
|
|
|
|
2. le code de cloud-init lui-même — un interpréteur Python complet exécuté en root au
|
|
|
|
|
démarrage, et ses ~29 dépendances.
|
|
|
|
|
|
|
|
|
|
La mainmise de l'hyperviseur sur ses invités est une propriété de la virtualisation, pas de
|
|
|
|
|
cloud-init. Elle appelle sa propre décision, qui n'est pas prise. Cf. **D-85**.
|
|
|
|
|
|
durcissement : cloud-init nait avec la VM et ne lui survit pas
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
2026-09-09 09:25:42 -04:00
|
|
|
**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.
|