No description
Find a file
Daniel Allaire 3cf00bbf3a patient 0 : le plan de l'ecosysteme dont les autres descendront
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>
2026-08-20 20:51:00 -04:00
inventories/production patient 0 : le plan de l'ecosysteme dont les autres descendront 2026-08-20 20:51:00 -04:00
plan patient 0 : le plan de l'ecosysteme dont les autres descendront 2026-08-20 20:51:00 -04:00
.gitignore patient 0 : le plan de l'ecosysteme dont les autres descendront 2026-08-20 20:51:00 -04:00
README.md patient 0 : le plan de l'ecosysteme dont les autres descendront 2026-08-20 20:51:00 -04:00

OPS-Patient0 — l'écosystème d'origine

Pour qui : l'exploitant de la lignée. Ce dépôt est le plan d'un écosystème Set-OPS comme les autres — mais de celui dont les autres descendent.

Ce qu'il est

Patient 0 est le plus petit écosystème complet : PKI, DNS, edge, courriel, PostgreSQL, et une forge. Six machines. Sa raison d'être tient en une phrase :

porter les dépôts qui fabriquent les écosystèmes, et les servir à ses enfants.

Aujourd'hui, ce rôle est tenu par eregion.chezlepro.ca — une machine hors flotte, montée à la main, que Set-OPS ne déploie pas, ne sauvegarde pas et ne prouve pas. Tout ce qui fabrique Chezlepro dépend d'elle. Patient 0 la remplace par un écosystème bâti par le moteur, sauvegardé par le moteur, vérifié par le harnais. On ne déplace pas le point unique de défaillance : on l'élimine.

La boucle, et comment elle se casse

Pour rebâtir patient 0, il faut le dépôt du moteur — qui vit sur patient 0. On n'échappe pas à ça par la ruse, mais par le nombre. Le génome doit exister en au moins trois endroits vivants, sans coordination :

patient 0 (la forge mère)  ·  le poste de l'exploitant  ·  restic hors cluster
        + chaque écosystème enfant, qui en porte un miroir

N'importe quel survivant réamorce les autres. Une famille, pas un maître.

Ce que ce dépôt contient, et ce qu'il ne contiendra jamais

plan/ les six machines, leurs zones, leurs applications
inventories/production/group_vars/ les intrants, le placement Proxmox, le gabarit de voûte
inventories/production/hosts.yml généré depuis le plan — ne jamais l'éditer à la main
le mot de passe de la voûte jamais. Ni ici, ni dans aucun dépôt : c'est le seul objet que la reproduction exige d'un humain

Deux réglages à connaître

index: 29 — tout l'adressage en dérive (10.29.0.0/16, VLAN 1291-1296). Choisi libre : 13 est le lab, 17 Chezlepro, 23 Technolibre. Les index bas (1, 11) ont déjà forcé deux renumérotages, ils tombaient dans des plages occupées par du matériel.

federe: false — patient 0 est exclu des devis du site tant qu'il n'est pas matérialisé : ni la frontière, ni le SDN, ni le pare-feu de l'hyperviseur ne lui réservent quoi que ce soit. C'est délibéré et temporaire. À basculer à true le jour où on le déploie, avant make sdn-appliquer — sinon ses zones n'existeront nulle part.

Ce qui reste à faire avant de le matérialiser

  • Décider où il vit. Sur asgard, la perte du cluster emporte patient 0 et Chezlepro d'un coup. Ailleurs, la famille survit à la perte du cluster. Le déménagement tient en quatre valeurs (group_vars/proxmox.yml) et un symlink.
  • Créer la voûte réelle : ansible-vault create inventories/production/group_vars/all/vault.yml, en couvrant les noms du gabarit (vault.yml.example).
  • Basculer federe: true, puis make instanciermake instancier-appliquer.
  • make placement-plan — confronter les quatre valeurs au cluster avant de cloner quoi que ce soit : quarante minutes de déploiement ne se rattrapent pas.
  • Déployer, puis y pousser les quatre dépôts du génome (moteur, instances, hébergeur, modèles) et inscrire la parenté de chacun.