`etat: planifie` etait l'heritage du modele : `flotte-creer` ne cree que les hotes ACTIFS,
donc le deploiement n'aurait fabrique aucune machine. Passer a `actif` est la declaration
d'intention — « je veux que cette machine existe » — et c'est le seul geste qui la
transforme en VM.
L'inventaire regenere ne porte plus que trois integrations : client_backup, client_pki,
client_unbound. `client_journal` et `client_metrique` sont tombes d'eux-memes — patient 0
n'a ni Loki ni Prometheus, et le moteur sait desormais qu'une integration universelle sans
service central n'a personne a qui parler.
Dependances causales : OK.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le role sait desormais faire SQLite (`serveur_forgejo_bd: sqlite`), et c'est le bon choix
ici : quelques comptes, des depots qui sont pour l'essentiel des MIROIRS. Exiger une VM
PostgreSQL — un serveur, une zone, un secret, une sauvegarde — pour une base que trois
personnes sollicitent etait un cout sans contrepartie.
Partent ensemble : l'application postgresql, la machine data-sql-01, les entrees du
registre des bases, et la zone Donnees devenue vide. Une nomenclature qui decrit une zone
sans machine est un mensonge en attente.
PATIENT 0 : QUATRE MACHINES. infra-pki-01, infra-dns-01, infra-edge-01, forge-01. Sur la
machine dont tout le reste descend, chaque service en moins est une chose de moins a
defendre, a sauvegarder, et a rebatir un soir de reconstruction.
La sauvegarde ne change pas : le fichier vit sous serveur_forgejo_data, que le job
`serveur_forgejo` de client_backup emporte deja.
Les quatre registres valident, l'inventaire est regenere, P35 ne reclame plus rien.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
DEUX DECISIONS DE L'EXPLOITANT, prises en regardant ce que patient 0 doit survivre.
1. LA SAUVEGARDE POINTE HORS CLUSTER (eregion). Le defaut du role poserait un backup-01
sur le MEME cluster : on sauvegarderait le genome a cote du genome, et la perte du
cluster emporterait les deux. Patient 0 existe pour survivre a la perte du reste.
Une seule cle a surcharger — client_backup_cible — parce que le transport est du SFTP
sur SSH, pas une derivation du plan.
CE QUI PART EST PETIT, et c'est le raisonnement qui compte : les quatre depots du
genome sont des MIROIRS (le poste de l'exploitant, eregion, chaque enfant en portent
une copie) — on les repousse depuis n'importe quel survivant. Reste l'irremplacable :
les cles de l'AC, et la base de la forge le jour ou elle portera autre chose que des
miroirs.
DEFAUT ASSUME, ecrit dans le fichier : eregion n'est pas geree par Set-OPS, donc ni
prouvee ni reconstructible. C'est un domaine de panne DIFFERENT d'asgard — le point —
pas un domaine sur. A revoir quand une troisieme machine existera.
2. DOVECOT RETIRE. Une boite aux lettres sans MTA pour l'alimenter ne servait rien ici.
Patient 0 passe de six a cinq machines : moins de surface a defendre sur la machine
dont tout descend, et une sauvegarde de moins a surveiller. L'application, la machine
et la fonction orpheline partent ensemble — une nomenclature qui place une machine
inexistante est un mensonge en attente.
Les quatre registres valident, l'inventaire est regenere.
RESTE UNE ACTION HUMAINE, sur eregion : creer le compte restic et y poser
cle-publique-sauvegarde.txt. La commande exacte est dans 20-sauvegarde.yml.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le modele `forge` posait `client_smtp` sur deux machines alors qu'aucun MTA ne figure au
plan. La dependance causale (client_smtp -> serveur_postfix actif) aurait REFUSE le
deploiement, et l'aurait refuse tard : apres le clonage.
Porter des depots n'exige pas d'envoyer du courriel. Le jour ou la forge devra notifier,
ce sera un relais declare, pas une integration orpheline.
Registre valide, inventaire regenere.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Aujourd'hui, tout ce qui fabrique Chezlepro vit sur `eregion` — une machine HORS FLOTTE,
montee a la main, que Set-OPS ne deploie pas, ne sauvegarde pas et ne prouve pas. Un
ecosysteme entier depend d'un point unique que le moteur ignore.
Patient 0 le remplace par le plus petit ecosysteme COMPLET (PKI, DNS, edge, courriel,
PostgreSQL, forge — six machines), bati par le moteur, sauvegarde par le moteur, verifie
par le harnais. On ne deplace pas le point unique de defaillance : on l'elimine.
Derive du modele `forge`, avec trois ecarts assumes :
- INDEX 29 (10.29.0.0/16, VLAN 1291-1296), choisi libre : 13 lab, 17 Chezlepro,
23 Technolibre ; les index bas (1, 11) ont deja force deux renumerotages.
- `federe: false` — patient 0 est EXCLU des devis du site tant qu'il n'est pas
materialise. Une flotte en cours de reconstruction n'a pas a se voir reserver des VLAN
et des regles pour un ecosysteme qui n'existe pas (c'est exactement ce qui avait
injecte les adresses d'un tenant perime dans le pare-feu partage, le 2026-08-12).
A basculer a `true` AVANT `make sdn-appliquer`, le jour du deploiement.
- `forge-01` recoit 80G au lieu du defaut : elle hebergera les depots de TOUTE la
lignee, pas seulement les siens.
Le modele `forge` dont il derive etait lui-meme perime sur deux points, corriges ici :
`client_pki` liste a la main alors que l'integration est devenue universelle, et un FQDN
expose reste en `exemple.internal`. Les modeles PRIVES ne sont pas couverts par le
harnais — P17 ne decouvre que le modele public.
VERIFIE : les quatre registres valident, le gabarit de voute couvre les 20 secrets exiges,
l'inventaire est genere et applique. Et sur l'instance de l'exploitant, en pleine
reconstruction : `make verifier` -> 38 OK, 0 echec, 0 saute ; les devis ne voient
toujours que Chezlepro et Technolibre.
CE QUI N'EST PAS ICI, ET NE LE SERA JAMAIS : le mot de passe de la voute. C'est le seul
objet que la reproduction exige d'un humain — le mettre dans la forge reviendrait a
enfermer la cle dans le coffre.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
