L'historique d'Icinga DB etait exclu de la restauration (2026-09-30) : son
environnement derive de l'AC d'Icinga, recreee a chaque reconstruction. L'AC est
desormais un jeu de sauvegarde, remis avant api setup ; la base d'Icinga est
restauree, et son schema n'est importe que sur une base vierge.
Les temoins comparaient PostgreSQL par nombre de lignes et n'ont pas vu 412
lignes d'historique remplacees par 380 neuves. Ils comparent desormais par cle.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
M4 a reconstruit Technolibre par le site qui la nomme ; les 7 jeux sont revenus
de l'instantane de 11:34, mais le premier depot d'apres reconstruction l'a chasse
par --keep-daily le jour meme : plus rien a quoi comparer.
Le depot d'avant rasage est etiquete avant-raser et garde jusqu'a la
reconstruction suivante. Le bilan dit ce qui a ete restaure et si c'est encore
au depot. setops-restaurer temoins et make temoins-etat comparent l'etat vivant
a cet instantane : une perte ou une identite changee est un ecart.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Il relaie et ne sert rien lui-meme. Un noeud qui n'a plus rien a
sauvegarder perd aussi ses verifications de depot et de restauration,
qui rapportaient sinon a des services qu'Icinga ne declare plus.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Chaque role proprietaire (AC, bases, annuaire, Nextcloud, rspamd/DKIM,
courriel, forge, web) remet son etat au moment ou il le creerait neuf,
depuis le dernier instantane anterieur a la naissance de la machine.
La sauvegarde refuse de deposer tant qu'un etat d'avant attend.
Outil de noeud setops-restaurer ; cibles sauvegarder-maintenant,
restauration-etat, restauration-renoncer ; test_restauration.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
La reconstruction ne reinjecte aucun instantane : annuaire, Keycloak,
Nextcloud et courriel remis depuis restic-tech (23:50) sur les machines
existantes. Le runbook coupe aussi la section sur DROP DATABASE.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Tour 1 8 passages ~2 h 30 16 defauts
Tour 2 3 passages 53 min 2 defauts
Tour 3 2 passages 37 min 0
LE TOUR 2 EST CELUI QUI COMPTE LE PLUS. J avais annonce deux passages ; il en
fallait trois, parce que les deux blocages connus sont EN SERIE : on ne peut
pas amorcer une forge qui ne tourne pas, et elle ne tourne qu apres la
convergence de la cle. Un runbook ecrit d apres un recit de depannage
contenait une erreur qu aucune relecture n aurait montree — il fallait le
SUIVRE pour la voir.
DEUX MURS DE PLUS, invisibles au tour 1. site-creer rend la main avant que
les machines repondent (3 min 20 mesurees). Et les cles d hote changent a
chaque reconstruction : accept-new couvre la premiere rencontre, jamais un
changement.
LE CYCLE DE LA CLE EST DENOUE. Aucun ordre de couches n y pouvait rien — les
certificats doivent venir tot. C est la propriete du geste qui a change de
main : serveur_forgejo revendique la cle au moment ou il cree le groupe.
client_pki garde la sienne et la repose a chaque passage, parce que step
reecrit la cle a chaque renouvellement. Gain : un passage entier et 300
secondes d attente perdue.
forge-amorcer purge desormais l entree perimee de l hote que GIT va
contacter, lu dans git remote get-url — pas celle de l API, qui peut etre un
tunnel. Et il rend les quatre premieres lignes de stderr : n afficher que la
derniere m a coute un aller-retour, git terminant toujours par un message
generique.
Le runbook porte les six etapes du tour 3 avec leurs durees reelles et les
dix-huit murs.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
SITE-Chezlepro n avait jamais ete rase. La limite qu on repetait partout —
l infrastructure d accueil n a jamais ete reconstruite depuis zero — se
lisait comme de la prudence. C etait seize defauts que rien d autre n aurait
pu reveler.
Un locataire naît dans un monde deja peuple : le site lui fournit paquets,
noms, genome, heure et depot. Un site n a personne au-dessus, sauf sa
frontiere. Onze des seize murs viennent de la.
DEUX CAPACITES QUI N EXISTAIENT PAS. make site-raser — rien ne detruisait les
machines du site, donc la limite etait un trou d outillage. make
forge-amorcer — la forge naît vide et le runner y clone ; l amorcage part du
poste, seul endroit qui detienne alors le genome.
TROIS GARDES QUI VERIFIAIENT LA FORME. La plus couteuse des familles : elles
donnent l apparence d une verification. Le resolveur comparait des adresses
au lieu de mesurer si la resolution aboutit, et protegeait ainsi l etat
casse. L administration etait reconnue a son port. Un flux a deux paires
n obtenait qu une branche.
UN ECART DE SECURITE. Le PostgreSQL du site servait le certificat auto-signe
de Debian, sans reseaux autorises ni hostssl — invisible tant qu aucun client
n exigeait la verification. Le defaut n a pas casse la construction : la
construction a revele le defaut.
UN ACCES ACCIDENTEL. Celui de l exploitant tenait au chevauchement d
adressage que le renumerotage a supprime. Separer les index n a pas cause le
probleme, il a retire le hasard qui le masquait.
La sequence du premier jour est ecrite : runbooks §9, avec les seize murs et
ce que chacun enseigne.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
Renommer une exposition touche cinq choses. Quatre suivent au deploiement ;
la cinquieme est celle que le navigateur regarde. serveur_nginx pose le vhost
et laisse le SAN en arriere — c est client_pki qui reemet, et rien ne le
reclame. Mesure deux fois le 2026-09-10.
Le controle compare trois listes : les expositions du plan, les noms du
certificat servi, et le code que rend le vhost. Dans les deux sens : un nom
reste dans le SAN apres avoir quitte le plan continue d etre authentifie.
Piege trouve en l ecrivant : client_pki met toujours le FQDN et le nom court
de la machine dans le SAN. Les compter comme vestiges faisait crier le
controle a chaque execution — et un controle qui crie toujours ne se lit plus.
Deux formes de terminaison, une seule question : le locataire termine sur un
edge, le site sur la machine elle-meme. Le porteur se derive de l une ou de
l autre.
Ce n est pas une preuve : rien de statique ne peut lire un certificat servi.
Les quatre controles a la demande n etaient nommes nulle part comme famille ;
ils ont maintenant leur section dans les runbooks.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
Question de l exploitant : le modele vit sur vishnu, les clones sur asgard,
qu arriverait-il si vishnu tombait ? Mesuree, la reponse se coupe en deux.
LES DONNEES SURVIVENT. Le pool CephNVMe est en size=3 / min_size=2 avec des
OSD sur les trois hotes, et les images du gabarit y sont repliquees.
L image reste lisible avec un noeud en moins, et les quatorze VM d un
ecosysteme tournent ailleurs sans s apercevoir de rien.
LA REPRODUCTION, NON. La configuration du gabarit porte le nom du noeud
dans son chemin - /etc/pve/nodes/vishnu/qemu-server/9006.conf - et le
clonage appelle nodes/vishnu/... Noeud eteint, aucune VM nouvelle ne peut
naitre. Or la reproduction est ce que ce depot existe pour garantir.
La decision est d ASSUMER la dependance et de la rendre COURTE, pas de la
supprimer : depuis la migration du gabarit sur stockage partage ce matin,
la remise en route est un deplacement de fichier de configuration, sans
mouvement de donnees. Un benefice qu on n avait pas cherche : la migration
sur Ceph a raccourci une panne qu on n avait pas encore nommee.
Documentee en trois endroits, parce qu un seul ne suffit pas : D-88 pour
nommer la dependance, le runbook section 7 pour la manoeuvre et l ordre
des gestes, et le bloc gabarit du plan du site - c est la que l exploitant
lit noeud: vishnu.
Ce qui n est PAS fait et qui est dit : rien ne MESURE cette dependance.
gabarit_etat compare le declare au reel, il ne demande pas si le noeud du
gabarit heberge autre chose que le gabarit.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
La revision a commence par un balayage par motifs — chemins morts, cibles make
absentes, comptes derives. Il a trouve une trentaine d ecarts et rate presque
tout le reste : un motif ne voit que ce qui s exprime en motif.
make hote-planifier en est l exemple. La cible EXISTE, donc le controle passait
au vert. C est une cible depreciee qui refuse et sort en 2, recommandee par
AGENTS.md, et qui contredit la REGLE D OR du meme fichier trois ecrans plus
haut. Il fallait lire pour la voir.
74 documents lus un par un. 66 corriges, 8 exacts.
CE QUI ETAIT FRANCHEMENT FAUX
AGENTS.md, la source d autorite, annoncait la flotte pas encore executee contre
des VM reelles. Elle a ete rasee et remontee depuis zero trois fois.
ecosysteme-chezlepro.md, le document montre a un client, portait la meme
phrase : il se sous-vendait gravement.
courriel-conception.md s ouvrait sur aucun role n est encore ecrit, au-dessus de
son propre paragraphe 1 qui les nomme. autorisation.md se terminait sur rien n
est construit alors qu il rapporte des mesures datees du role en fonctionnement.
hebergeur-exploitation.md disait rien n est fait d un depot qui existe.
filiation-emancipation.md se contredisait a deux ecrans de distance.
DES MODELES DECRITS D APRES UN MONDE ANTERIEUR
Le resolveur : cinq documents decrivaient un Unbound par VM en opt-in, trois le
donnaient en exemple d integration FACULTATIVE — il est universel depuis le
2026-08-24. L adressage de nomenclature-vm.md : reseau unique, VLAN 11-15, VMID
a cinq chiffres. Le nommage SDN de sdn-evpn.md contre le code : c est le wiki
qui avait raison.
CE QUI CASSE AU PREMIER ESSAI
Le nom du gabarit dore etait faux a quatre endroits, dont la procedure qui le
FABRIQUE et le critere R2 de l epreuve d operateur independant.
preparer-un-site-hebergeur.md avertissait qu une VM faite a la main serait
detruite : raser derive du plan, il ne la detruira jamais — le risque est l
inverse. Un mot de passe d essai en clair dans un depot public.
DEUX PREUVES ETENDUES, ET UNE QUI SE TROMPAIT ELLE-MEME
P57 couvre les groupes : elle a signale aussitot 29 groupes annonces au-dessus d
un tableau qui en cite 40. P29 confronte le tableau de authentification.md aux
declarations reelles : 12 annonces, 21 reels.
Et P57 imposait un chiffre faux — 56 preuves alors que le depot en porte 57, la
conditionnelle vivant hors de tout comptage. Un garde-fou qui fait respecter une
erreur ajoute l assurance a l erreur.
CE QUI RESTE, ET QU AUCUNE PREUVE NE TIENT
Deux comptes trouves a la main. Et une lacune reelle : rien ne garde les
meta/acces.yml — ni qu un service web-sso en porte un, ni que le groupe qu il
nomme existe. P29 tient les positions d authentification, personne ne tient les
habilitations.
make prouver : CONFORME, 56 OK, 0 echec, 1 saute. 0 lien mort.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
D-77 sortait deja le stockage de l'espace derive, mais par une EXCEPTION NOMMEE
plutot que par une regle. La question de l'exploitant — « le VLAN 40 n'a aucune
VM, pourquoi ne pas lui donner une adresse non routee ? » — a fait apparaitre le
critere juste.
Ce n'est pas « y a-t-il des machines dedans » (le VLAN de gestion n'en a pas plus
qu'un autre), c'est : ce reseau est-il jamais une DESTINATION, ou seulement un
CHEMIN ?
gestion (10) atteinte depuis ailleurs -> 10.<index>.0.0/24, UNIQUE
transit (40) prochains sauts seulement -> 192.168.40.0/24
transport VXLAN(50) VTEP <-> VTEP -> 192.168.50.0/24
stockage (20/30/31) baie <-> hyperviseurs -> 192.168.20/30/31.0/24
Sur six reseaux, CINQ cessent d'exiger la moindre coordination entre deux
hebergeurs, et « unique » redevient signifiant.
L'OS, trouve par l'exploitant avant ecriture : le VLAN 11 aurait produit
192.168.11.0/24, DEJA occupe par la gestion des hyperviseurs sur vmbr0
(passerelle .254). Le 11 se liberera quand cette gestion rejoindra 10.<index>.0.x
— mais faire dependre un plan d'adressage de l'ORDRE d'une migration est le genre
de dette qui se paie un an plus tard. Le transport passe au VLAN 50 : libre,
192.168.50.0/24 libre, et ne depend de rien. Verifie : rien ne code le 11 en dur.
underlay.yml n'est PAS modifie : il decrit le materiel tel qu'il est, et y ecrire
les nouvelles plages avant le deplacement physique le ferait mentir. Les adresses
changeront avec le materiel, dans l'ordre du runbook §6.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
10.17.0.1/24 posee par l'API a cote de 10.0.0.1/24, qui reste active. Ajouter
AVANT de retirer : un point de routage qui change d'adresse d'un coup coupe
simultanement l'exploitant, les commutateurs qui l'ont en passerelle par defaut,
et l'outil qui devait faire la bascule.
Documente l'ordre du reste (poste, commutateurs, hyperviseurs, transit, VXLAN,
stockage, puis retrait) et surtout ce qui n'en depend PAS : le renumerotage du
TENANT est independant — la frontiere route son supernet vers le meme prochain
saut quelle que soit sa propre adresse de gestion.
prouver reste a 1 : P03 signale l'ecart plan/applique, qui est reel jusqu'au
renumerotage du tenant.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
On savait que la donnee partait et arrivait. Pas qu'elle revenait.
Trois charges critiques eprouvees :
- cles de l'AC (infra-pki-01) : restauration + comparaison OCTET POUR OCTET,
12 fichiers, 11 identiques, root_ca_key et intermediate_ca_key compris. Seul
ecart : db/000000.vlog, le journal badger de step-ca, qui avance a chaque
emission. Attendu.
- annuaire (idm-01) : slapadd -u (essai a blanc) sur le LDIF restaure —
REJOUABLE, 7 entrees dont uid=sysadmin.
- bases (data-sql-01) : section forgejo REJOUEE dans une base d'epreuve —
0 erreur, 130 tables, comptes reels. Production verifiee intacte apres.
Controles negatifs : un LDIF corrompu fait sortir slapadd en 1 ; la garde SQL a
refuse une section mal decoupee.
LE PIEGE pg_dumpall : il ecrit CREATE DATABASE <suivante> AVANT le \connect
correspondant. Decouper « du \connect X au \connect suivant » emporte un ordre
visant une AUTRE base. Ma premiere decoupe l'a fait ; la garde a refuse de
rejouer. Consigne dans runbooks-exploitation.md §5.
valider.yml ne ment plus : il exigeait une restauration de TOUS les noeuds
client_backup, donc echouait sur ceux qui ne detiennent rien et sur les depots
vides. Quatre verdicts desormais (OK / A CONFIRMER / SANS OBJET / ECHEC),
ALIGNES sur ceux de la supervision. Et il prouve que l'annuaire est rejouable,
pas seulement present.
make valider : 0 echec sur toute la flotte.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Trois des cinq pieges restants avaient deja une page depuis que la semaine a
avance : le connect() vers le vide (frontiere-opnsense.md + le controle porte
par frontiere-mesurer), le `make prouver` vert (wiki « Verifier le deploye »),
et le banner exchange. Les deux orphelins — kcadm -s sur une map, grafana-cli
dans une base fantome — s'adressent a qui ECRIT du code, pas a qui reprend
l'exploitation : ils n'ont rien a faire dans un chemin de reprise.
Une page separee aurait redit ce que trois autres disent deja, et aurait donc
vieilli mal — le reproche exact qu'on faisait a sa version longue.
La section ⑤ de « Reprendre l'ecosysteme » porte desormais la REGLE qui les
relie (verifier l'instrument avant d'accuser le composant) et un tableau de
trois lignes qui renvoie chacune a son domicile. Plus de promesse en attente.
Et le banner exchange n'avait AUCUN domicile : le savoir vivait dans un
commentaire du Makefile et trois entrees du CHANGELOG — nulle part ou on le
cherche, exactement le mal que la refonte traite. Ecrit en runbook §3, avec
ses trois causes par frequence et ce qui tranche dans l'ordre.
runbooks-exploitation.md declare aussi son lecteur, comme le veut la
convention validee.
Verifie : chaque renvoi controle un a un, prouver.py 0 (33 OK), plan-recette
inchange.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Fermeture des dettes de doc :
- nouvelle unité wiki « Autorisation & RBAC » (authZ, exemple Grafana) ;
- section « le renouvellement est un système » dans l'unité PKI ;
- docs/runbooks-exploitation.md (cert expiré, RBAC Grafana, branding).
15 unités wiki.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
