Alliance-Boreale/Set-OPS-Public
2
0
Fork 0
Code Issues Pull requests 1 Projects Releases Packages Wiki Activity

site : cloud-init retire des sept machines de l hebergeur

Browse source 
make site-appliquer GROUPE=serveur_durci : 7 hotes, 0 echec, 0 injoignable.
Configuration reseau intacte sur les sept, ifquery rend l adresse attendue
sur chacune, zero unite cloud-init restante, zero unite en echec.

Le site HEBERGE, d ou la verification apres coup depuis les machines qui
ont le flux : la forge repond 200 et sert toujours ce depot au bon commit,
le cache APT repond 200, le DNS resout, step-ca rend status ok.

Le site ne portait pas le piege openipmi : il n applique pas
client_metrique.

TROUVE EN VERIFIANT, SANS RAPPORT : site-backup-01 est DANS le groupe
client_pki et n a ni /etc/step, ni minuterie de renouvellement, ni meme la
racine de l AC. Les six autres ont leur certificat et leur minuterie
quotidienne. L appartenance au groupe dit « couverte », la machine dit le
contraire. Non corrige — c est une decision d exploitation.

Corrige au passage deux affirmations fausses du CHANGELOG : le site n est
plus « arme, pas applique », et il ne faut pas passer par site-ops-01 pour
le deployer.

make prouver : CONFORME.

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 19:35:17 -04:00
parent f4bb40c4f2
commit e9b22b0be0
1 changed files with 33 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

34
CHANGELOG.md
View file

@ -246,7 +246,39 @@ 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
### Le SITE : fait le 2026-09-09 — 7/7
`make site-appliquer GROUPE=serveur_durci` : **7 hotes, 0 echec, 0 injoignable**.
Configuration reseau intacte sur les sept, `ifquery` rend l'adresse attendue sur chacune
(`10.0.31.11`, `10.0.33.11`...), zero unite cloud-init restante, zero unite en echec.
Le site HEBERGE — c'est ce qui rendait l'operation plus lourde que chez le tenant. Verifie
apres coup, depuis les machines qui ont le flux : la forge repond `HTTP 200` et sert
toujours ce depot au bon commit ; le cache APT repond `HTTP 200` ; le DNS resout
`forge.genese.internal` ; step-ca rend `{"status":"ok"}`.
Le site ne portait pas le piege `openipmi` : il n'applique pas `client_metrique`.
*(Ce paragraphe remplace celui qui disait le changement « arme, pas applique » — et qui
disait aussi, a tort, qu'il fallait passer par `site-ops-01`. `make site-appliquer`
fonctionne depuis le poste.)*
### Trouve en verifiant : `site-backup-01` n'a jamais recu `client_pki`
Elle est DANS le groupe `client_pki` — et elle n'a ni `/etc/step`, ni minuterie de
renouvellement, ni meme la racine de l'AC dans `/usr/local/share/ca-certificates/`. Les
six autres machines du site ont leur certificat et leur minuterie quotidienne, qui tourne.
L'appartenance au groupe dit « couverte ». La machine dit le contraire. C'est la meme
famille que le reste : *un perimetre declare n'est pas un perimetre mesure.* Sans rapport
avec le retrait de cloud-init — trouve en le verifiant.
**Non corrige** : `make site-appliquer GROUPE=client_pki` le poserait (essai a blanc :
sept changements, dont l'etablissement de la confiance). L'echec que le mode simulation
affiche sur `root_ca.crt` est un artefact — le fichier manque parce que le bootstrap n'a
ete que simule.
### Ce qui restait a faire (historique)
`SITE-Chezlepro` est **une autre instance de ce depot** — meme
`playbooks/groupes/serveur_durci.yml`, memes roles. Ses sept machines actives