Daniel Allaire
cbb186d2fa
Ecosysteme chezlepro detruit (14 VM, disques compris) puis rejoue depuis le plan seul, sans restaurer aucune sauvegarde. Les cinq devis rendent le meme verdict qu'avant la destruction. Premiere fois que le depot peut affirmer que le SYSTEME RECONSTRUIT est celui que le plan decrit, au lieu d'affirmer que le depot est coherent avec lui-meme. Six defauts trouves, tous invisibles autrement : trois d'ordre, deux courses de premier demarrage, un conflit de port. Ils dormaient tous derriere un etat preexistant — un compte deja la, des roles crees par un passage anterieur, des clients existants, un service qui tournait depuis toujours, un port deja tenu. Le rejeu n'a rien casse : il a retire l'etat qui masquait. Refait a la main : la seule base de Grafana, dont le schema etait reste a moitie migre apres l'interruption du defaut n5. Rien d'autre. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
4.5 KiB
État de référence — avant reconstruction from-zero
Figé le 2026-08-08, écosystème chezlepro (index 17, 14 VM), avant destruction et rejeu complet du plan. Ce document existe pour que « identique » soit prouvable plutôt que ressenti. Toute divergence après reconstruction se lit contre lui.
Les cinq devis, avant
identite CONFORME : le réel correspond au déclaré (1 compte(s) dans l'annuaire).
certificats CONFORME : aucun certificat servi n'est en fin de vie.
expositions CONFORME : toute exposition déclarée répond, des deux points de vue.
postgresql CONFORME : chiffrement imposé, et aucun réseau hors du supernet dérivé.
courriel CONFORME : la chaîne tient, de la résolution LDAP à la boîte.
Ce que la flotte porte
backup-01 10.27.18.21 1 service(s) metier
collab-01 10.27.21.21 3 service(s) metier
data-sql-01 10.27.18.11 2 service(s) metier
edge-mta-01 10.27.16.21 2 service(s) metier
forge-01 10.27.21.11 1 service(s) metier
idm-01 10.27.17.11 3 service(s) metier
infra-dns-01 10.27.19.11 1 service(s) metier
infra-edge-01 10.27.16.11 2 service(s) metier
infra-mail-01 10.27.19.31 2 service(s) metier
infra-pki-01 10.27.19.21 2 service(s) metier
mon-01 10.27.20.21 6 service(s) metier
obs-01 10.27.20.11 2 service(s) metier
web-dorsal-01 10.27.21.41 2 service(s) metier
web-frontal-01 10.27.21.31 2 service(s) metier
Ce qui sera perdu et devra être refait à la main
| Objet | Conséquence | Geste de reprise |
|---|---|---|
Clé racine de l'AC (/etc/step-ca/secrets/root_ca_key) |
la racine installée dans le navigateur devient inutile ; tous les certificats changent | make ca-racine + réinstaller, en comparant l'empreinte (§6.3) |
Mot de passe du compte sysadmin |
l'annuaire est recréé vide, puis amorcé | relever le jeton d'amorçage en voûte (§6.1) et le changer |
| Contenu applicatif (dépôts Forgejo, fichiers Nextcloud, courriels, tableaux Grafana) | non sauvegardé, non reconstructible par le code | aucun — assumé : c'est un POC |
Ce qui survit : les deux voûtes et
~/.config/setops-vault-passvivent hors dépôt et hors cluster ; le code est sureregion.chezlepro.ca(192.168.12.201), machine distincte du tenant. Rien de ce qui est nécessaire au rejeu n'est dans les 14 VM.
Après reconstruction — 2026-08-09
Écosystème détruit (14 VM, disques compris) puis rejoué depuis le plan seul. Aucune sauvegarde restaurée : ni LDAP, ni base, ni certificat, ni fichier.
identite CONFORME
certificats CONFORME
expositions CONFORME
postgresql CONFORME
courriel CONFORME
Cinq sur cinq, identiques à la référence. C'est la première fois que le dépôt peut dire que le système reconstruit est celui que le plan décrit — au lieu de dire que le dépôt est cohérent avec lui-même.
Les six défauts que seul un rejeu depuis zéro pouvait montrer
| # | Défaut | Pourquoi il dormait |
|---|---|---|
| 1 | amorcage_acces_courriel jamais déclaré par le tenant |
le compte existait déjà, le garde-fou n'avait jamais eu à se déclencher |
| 2 | rôles de realm créés après leur attachement aux groupes | un passage précédent les avait créés |
| 3 | claim de groupes posé avant les clients OIDC | les clients existaient déjà |
| 4 | écriture Keycloak annulée par le collecteur de transactions | la synchro LDAP complète ne se rejoue pas en exploitation |
| 5 | grafana-cli lancé avant que Grafana ait fini de démarrer |
le service tournait depuis toujours |
| 6 | port d'Alloy (12345) en collision avec le SASL de Dovecot | Alloy tenait le port ; c'est Dovecot qui échouait, en silence |
Trois défauts d'ordre, deux courses de premier démarrage, un conflit de port. Aucun n'était visible à un redéploiement, et aucun aux 31 preuves statiques — elles lisent le dépôt, pas la machine.
Le sixième mérite d'être relu : le conflit existait depuis toujours, mais dans l'autre
sens. Alloy tenait 12345 et l'écoute SASL de Dovecot échouait sans que personne ne le
voie. La reconstruction a inversé l'ordre de démarrage et rendu visible un défaut qui
était là depuis le début.
Ce qui a dû être refait à la main
- La base de Grafana : le premier démarrage, interrompu par le défaut nº 5, avait
laissé un schéma à moitié migré (
no such column: with_credentials). Base mise de côté, recréée par Grafana — 95 s pour lier son port, ce qui explique la course. - Rien d'autre. Ni certificat, ni compte, ni zone DNS, ni base de données.