Daniel Allaire
f89b097b26
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 |
||
|---|---|---|
| .. | ||
| 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.
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 :
- une réapplication automatique, à chaque démarrage, depuis un support que le plan ne possède pas et qu'aucune preuve ne lit ;
- 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.
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.