Publication du wiki depuis le depot (source: f89b097)

Daniel Allaire 2026-09-09 10:12:01 -04:00
parent c7e58e544f
commit 6808e65473

@ -49,6 +49,15 @@ Le durcissement (`serveur_durci`) le **retire** donc, une fois qu'il a réussi
parce qu'il a réussi qu'Ansible a pu entrer. Le gabarit, lui, le garde : sans lui, un clone
n'a ni adresse ni nom d'hôte.
*Ce que ça ne fait pas* : ça **ne reprend pas la main à l'hébergeur**. `qemu-guest-agent`
reste sur chaque VM — il doit y être, c'est par lui que la création confirme qu'une machine
existe — et l'API de l'hyperviseur expose sur son dos `exec`, `file-write`,
`set-user-password`, `shutdown` : strictement plus que le lecteur cloud-init. Ce qui est
fermé est plus étroit, et bien réel : une réapplication *automatique, à chaque démarrage*,
depuis un support que le plan ne possède pas, et un interpréteur Python complet lancé en
root au démarrage. Qu'un hyperviseur puisse tout faire chez ses invités est une propriété
de la virtualisation, pas de cloud-init.
*Pourquoi ça ne coupe pas le réseau* : l'adresse posée à la naissance vit dans
`/etc/network/interfaces.d/50-cloud-init`, un fichier qui **n'appartient à aucun paquet** —
`dpkg -S` ne le trouve pas, et le `postrm` ne le nomme jamais, même en `purge` (mesuré le