cloud-init retire de la flotte : 14/14, 0 echec

Applique apres confirmation. Ordre suivi : obs-01 seul d abord, verifie,
puis les treize autres.

Releve sur les quatorze machines : paquet=0, unites=0, reseau=oui,
drapeau=oui, networking=enabled, echecs=0 — et sur chacune, ifquery rend
EXACTEMENT l adresse vive. C est le point : ifquery ne lit pas la memoire
du systeme, il RELIT le fichier que le retrait aurait pu emporter, donc il
repond ce que le prochain demarrage fera.

Second passage sur obs-01 : changed=1, et ce seul changement est la tache
nftables_baseline qui se declare toujours modifiee, anterieure a ce
chantier. Le retrait est idempotent.

make valider apres deploiement : 0 echec, 0 injoignable.

CE QUI N EST PAS PROUVE. Aucune machine n a ete REDEMARREE : la garde de
securite du poste a refuse le redemarrage, et on ne contourne pas une
garde. Le chemin de demarrage a donc ete prouve autrement — networking
(ifupdown) actif, systemd-networkd desactive, ifquery relit le fichier et
rend la bonne adresse, zero unite cloud-init dans multi-user.target, zero
unite en echec, nom d hote et cles SSH persistants. C est fort, ce n est
pas un redemarrage.

LE SITE. SITE-Chezlepro est une autre instance de CE depot : meme
serveur_durci, memes roles. Ses sept machines actives sont durcies depuis
le 2026-09-02 — leur prochain passage retirera cloud-init chez elles
aussi. Le site se deploie depuis son propre runner, pas depuis ce poste.

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
This commit is contained in:
Daniel Allaire 2026-09-09 11:03:45 -04:00
parent 0b0d9ca708
commit 2d9dc866a9

View file

@ -111,10 +111,51 @@ hyperviseur, metal nu, hebergeur sans API — ce chemin cesse d'etre une reimple
devient LE CHEMIN PORTABLE. C'est l'axe emancipation que le depot suit deja. Le seuil est
nomme ici pour ne pas etre franchi sans le voir.
### Non deploye
### Deploye le 2026-09-09 — 14/14
Le code est ecrit, valide et prouve ; **il n'a pas ete applique a la flotte**. Retirer un
paquet sur quatorze VM de production est une action a confirmer, pas a supposer.
Applique a la flotte de Chezlepro apres confirmation explicite. `serveur_durci` :
**14 hotes, 0 echec, 0 injoignable**. Ordre suivi : `obs-01` seul d'abord, verifie, puis
les treize autres.
Releve sur les quatorze machines apres coup :
paquet=0 unites=0 reseau=oui drapeau=oui networking=enabled echecs=0
et, sur chacune, `ifquery` rend EXACTEMENT l'adresse vive (`10.17.20.11`, `10.17.21.11`...).
C'est le point : `ifquery` ne lit pas la memoire du systeme, il **relit le fichier** que le
retrait aurait pu emporter — donc il repond ce que le prochain demarrage fera.
Second passage sur `obs-01` : `changed=1`, et ce seul changement est la tache
`nftables_baseline` qui se declare toujours modifiee, anterieure a ce chantier. Le retrait
est idempotent.
`make valider` apres deploiement : **0 echec, 0 injoignable** sur les quatorze.
**CE QUI N'A PAS ETE PROUVE, ET IL FAUT LE DIRE.** Aucune machine n'a ete REDEMARREE. Le
redemarrage etait le controle que je voulais faire — la garde de securite du poste l'a
refuse, et on ne contourne pas une garde. Le chemin de demarrage a donc ete prouve
AUTREMENT, sans redemarrer : `networking.service` (ifupdown) est le service actif,
`systemd-networkd` est desactive, NetworkManager absent ; `ifquery` relit le fichier et
rend la bonne adresse ; zero unite cloud-init subsiste dans
`systemctl list-dependencies multi-user.target` ; zero unite en echec ; le nom d'hote et
les trois cles d'hote SSH persistent hors de cloud-init.
C'est fort, ce n'est pas un redemarrage. La confirmation finale tient en une ligne, a
lancer par un humain sur une machine de son choix.
### Le SITE : le changement y est ARME, pas applique
`SITE-Chezlepro` est **une autre instance de ce depot** — meme
`playbooks/groupes/serveur_durci.yml`, memes roles. Ses sept machines actives
(`site-ops-01`, `site-cache-01`, `site-forge-01`, `site-pki-01`, `site-dns-01`,
`site-backup-01`, `site-mon-01`) sont durcies depuis le 2026-09-02 : leur prochain passage
de `serveur_durci` retirera cloud-init chez elles aussi, sans que personne ne le decide a
nouveau.
Ce n'est pas un oubli, c'est un fait a connaitre : le site se deploie depuis SON runner
(`site-ops-01`), pas depuis ce poste, et son inventaire n'est meme pas genere ici. Y aller
est un acte distinct, sur une machine distincte, et le site porte la forge qui sert ce
depot et le cache qui nourrit `apt` — un rayon d'action different.
## 2026-09-08 (4) — Les SIX registres ont un formulaire genere