Daniel Allaire
05347e6206
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>
42 lines
1.9 KiB
YAML
42 lines
1.9 KiB
YAML
---
|
|
# Nomenclature = MODELE de l'ecosysteme (zones + placement des fonctions).
|
|
# L'ADRESSAGE (supernet, sous-reseaux, passerelles, VLAN, VMID) N'EST PAS ecrit ici :
|
|
# il se DERIVE du seul seed `index` (scripts/inventory_rules : supernet_de, base3_de,
|
|
# passerelle_de, vlan_de). Editer `index` via le panneau Intrants du GUI.
|
|
#
|
|
# INDEX 29 -> supernet 10.29.0.0/16, VLAN 1291 a 1296.
|
|
# Choisi libre le 2026-08-20 : 13 est le lab, 17 Chezlepro, 23 Technolibre. Les index
|
|
# bas (1, 11) ont deja force deux renumerotages — ils tombaient dans des plages que du
|
|
# materiel occupait deja. P21 garde la collision si un jour un autre s'en approche.
|
|
index: 29
|
|
cidr_hote: 24
|
|
reservations:
|
|
passerelle: 1
|
|
reserve_min: 2
|
|
reserve_max: 9
|
|
|
|
# PATIENT 0 PARTICIPE AUX DEVIS DU SITE (bascule le 2026-08-20).
|
|
#
|
|
# `federe: true` le rend visible a `devis_reseau.decouvrir()` : la frontiere lui pose ses
|
|
# regles et ses routes, le SDN cree ses zones, le pare-feu de l'hyperviseur derive ses
|
|
# groupes. C'est ce qu'il faut AVANT `make sdn-appliquer` — sinon ses VLAN n'existent
|
|
# nulle part et les VM naissent sur un reseau qui n'a pas ete provisionne.
|
|
#
|
|
# Il est reste a `false` tant qu'il n'etait qu'un plan : un ecosysteme qui n'existe pas
|
|
# n'a rien a faire dans la politique d'un site. C'est ainsi qu'un tenant perime avait
|
|
# injecte ses vieilles adresses dans le pare-feu partage, le 2026-08-12.
|
|
federe: true
|
|
|
|
# Zones de securite (un /24 + VLAN chacune) — seuls les libelles sont du modele.
|
|
categories:
|
|
1: { libelle: Frontiere }
|
|
3: { libelle: Donnees }
|
|
4: { libelle: Services-infra }
|
|
6: { libelle: Applications }
|
|
# Placement : quelle fonction dans quelle zone (categorie) et son rang (service).
|
|
fonctions:
|
|
data-sql: { categorie: 3, service: 1 }
|
|
forge: { categorie: 6, service: 1 }
|
|
infra-dns: { categorie: 4, service: 1 }
|
|
infra-edge: { categorie: 1, service: 1 }
|
|
infra-pki: { categorie: 4, service: 2 }
|