Daniel Allaire
5c638675cb
Filet sous make publier : compare la forge du site a eregion (repere seulement, depots lisibles sans identifiant), tolere l ecart d une publication en cours. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
90 lines
4.7 KiB
YAML
90 lines
4.7 KiB
YAML
---
|
|
# LE RUNNER DE SITE — celui qui MATÉRIALISE.
|
|
#
|
|
# Le travail d'un runner se divise en trois, et les deux premières portées appartiennent
|
|
# au TENANT tandis que la troisième appartient à la FABRIC :
|
|
#
|
|
# calculer plan -> inventaire aucune voûte portée OPS (serveur_ops)
|
|
# configurer rôles sur ses machines voûte du TENANT portée OPS (serveur_ops)
|
|
# matérialiser créer/détruire des VM voûte du SITE portée SITE (ce rôle)
|
|
#
|
|
# POURQUOI LA SÉPARATION. Si chaque écosystème portait le pouvoir de matérialiser, la
|
|
# voûte du SITE se retrouverait en N exemplaires — le secret le plus dangereux du système,
|
|
# recopié autant de fois qu'il y a de locataires. C'est précisément ce que la séparation
|
|
# des voûtes (2026-08-22) cherchait à éviter.
|
|
#
|
|
# Et l'inverse serait pire : un runner UNIQUE qui ferait tout devrait entrer en SSH chez
|
|
# tous les tenants, donc traverser le default-deny inter-tenant — et rendrait toute
|
|
# émancipation impossible, puisqu'un écosystème ne pourrait plus se rebâtir sans son hôte.
|
|
#
|
|
# Deux pouvoirs, deux rôles, aucun omnipotent : ce rôle crée des VM vides et n'entre
|
|
# jamais chez un tenant ; `serveur_ops` habille des machines et ne touche jamais la fabric.
|
|
#
|
|
# QUI PEUT LE DÉCLARER : l'écosystème de l'HÉBERGEUR, celui qui exploite la fabric. Un
|
|
# tenant ordinaire qui le déclarerait s'arrogerait un pouvoir sur ses voisins.
|
|
|
|
serveur_ops_site_utilisateur: "setops"
|
|
serveur_ops_site_racine: "/opt/setops"
|
|
|
|
# Le dépôt du SITE, tel qu'il atterrit chez le runner. Il doit avoir été cloné par
|
|
# `serveur_ops` (entrée `role: hebergeur` de `serveur_ops_depots`).
|
|
serveur_ops_site_depot: ""
|
|
|
|
# --- LA VOÛTE DU SITE --------------------------------------------------------
|
|
#
|
|
# Déposée CHIFFRÉE, jamais en clair. Le mot de passe n'est pas stocké : le Makefile
|
|
# ajoute `--ask-vault-pass` quand aucun fichier de mot de passe n'est défini, et
|
|
# l'exploitant le tape au moment d'agir.
|
|
#
|
|
# `decrypt: no` EST OBLIGATOIRE sur la copie. Sans lui, Ansible DÉCHIFFRE la source quand
|
|
# il détient le mot de passe — mesuré le 2026-08-24, 776 octets en clair au lieu de 3465
|
|
# chiffrés, sur une machine où ils n'avaient rien à faire.
|
|
serveur_ops_site_voute_source: ""
|
|
serveur_ops_site_voute_deposer: true
|
|
|
|
# --- ARMER LE RUNNER : LA CLE DE SA VOUTE ------------------------------------
|
|
#
|
|
# UN RUNNER MAITRE DE SA VOUTE (decision de l'exploitant, 2026-08-28). Deposer le chiffre
|
|
# sans la cle laisse un runner qui calcule son inventaire et ne peut rien en faire : chaque
|
|
# role reclamant un secret echoue sur son assertion, et l'echec ne dit pas qu'il manque un
|
|
# FICHIER — seulement que les valeurs sont vides.
|
|
#
|
|
# `false` PAR DEFAUT, ET CE N'EST PAS DE LA PRUDENCE DECORATIVE. Armer est un ACTE, pas un
|
|
# reglage : c'est le moment ou un humain remet la cle, et c'est le seul geste que la
|
|
# reproduction exige de lui (cf. docs/filiation-emancipation.md). Un defaut a `true`
|
|
# armerait des machines sans que personne ne l'ait decide.
|
|
#
|
|
# LA SOURCE EST UN POINTEUR, JAMAIS UNE VALEUR : le chemin du fichier de mot de passe sur
|
|
# le poste de l'exploitant. Il ne vit dans aucun depot, et rien ici n'en lit le contenu.
|
|
#
|
|
# DESTINATION : `<racine>/.config/setops-vault-<depot-en-minuscules>`, la meme convention
|
|
# que `scripts/voutes.py` — le runner derive donc sa propre liste d'identites sans qu'on
|
|
# ait a la lui ecrire. Hors de tout depot git, en 0600.
|
|
serveur_ops_site_cle_deposer: false
|
|
serveur_ops_site_cle_source: ""
|
|
serveur_ops_site_cle_destination: >-
|
|
{{ serveur_ops_site_racine }}/.config/setops-vault-{{ serveur_ops_site_depot | lower }}
|
|
|
|
# LA CONFORMITE DE LA FABRIC (2026-09-28) — voir `templates/conformite-fabric.sh.j2`.
|
|
# Des plans de LECTURE seulement : aucun n'ecrit.
|
|
serveur_ops_site_conformite_plans:
|
|
- proxmox-fw-plan
|
|
- sdn-plan
|
|
- frontiere-plan
|
|
- vpn-admin-plan
|
|
serveur_ops_site_conformite_etat: "/var/lib/setops/conformite-fabric.json"
|
|
serveur_ops_site_conformite_horaire: "hourly"
|
|
# Au-dela, le constat est PERIME et la sonde passe au rouge : un minuteur mort ne doit pas
|
|
# laisser la derniere bonne nouvelle au vert.
|
|
serveur_ops_site_conformite_age_max_h: 3
|
|
|
|
# LE FILET DU GENOME (2026-09-28) — voir `templates/sonde-genome-a-jour.sh.j2`.
|
|
# Les depots qu'eregion laisse lire SANS IDENTIFIANT, et leur adresse. Les depots prives n'y
|
|
# sont pas : donner au site un jeton sur une forge heritee l'y lierait. La sonde les NOMME
|
|
# comme non compares.
|
|
serveur_ops_site_genome_repere:
|
|
set-ops-public: "https://forge.alliance-boreale.ca/Alliance-Boreale/Set-OPS-Public.git"
|
|
# `make publier` pousse eregion une minute avant la forge du site : un ecart plus jeune que
|
|
# ceci n'est pas un retard.
|
|
serveur_ops_site_genome_tolerance_min: 60
|
|
serveur_ops_site_genome_etat: "/var/lib/setops/genome-ecarts.json"
|