Commit graph

4 commits

Author SHA1 Message Date
6642796518 plan : la base tient dans un fichier — PostgreSQL et sa machine s'en vont
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>
2026-08-22 13:57:40 -04:00
bb5fe9ff30 plan : Redis retire — le role Forgejo n'y fait aucune reference
Verifie plutot que suppose : serveur_forgejo ne mentionne Redis ni dans son app.ini, ni
dans ses defauts, et ne declare aucun lien vers lui. Il etait au plan par heritage du
modele `forge`, pas par besoin.

Un service qui tourne sans rien servir n'est pas neutre sur la machine dont tout le reste
descend : c'est une surface a defendre, une sauvegarde a surveiller, et une chose de plus
qui peut tomber un soir ou l'on cherche autre chose.

Registre valide, inventaire regenere.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-22 11:00:03 -04:00
05347e6206 architecture : la sauvegarde sort du cluster, et Dovecot quitte le plan
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>
2026-08-22 10:55:11 -04:00
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