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>
91 lines
4.5 KiB
Markdown
91 lines
4.5 KiB
Markdown
# É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-pass` vivent hors dépôt
|
|
> et hors cluster ; le code est sur `eregion.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.
|