Publication du wiki depuis le depot (source: f89b097)
parent
c7e58e544f
commit
6808e65473
1 changed files with 9 additions and 0 deletions
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in a new issue