Daniel Allaire
45aaf2808d
La separation faite, la distribution devient sure. `serveur_ops_site` et `serveur_ops_tenant` deposent desormais LA CLE de la voute qu'ils deposaient deja chiffree. Le runner du site l'a recue : une seule cle chez lui, en 0600, et il ouvre sa voute tout seul. La fabric, pas un tenant. `false` PAR DEFAUT, ET CE N'EST PAS DECORATIF. Armer est le moment ou un humain remet la cle — le seul geste que la reproduction exige de lui. Un defaut a `true` armerait des machines sans que personne ne l'ait decide. Les deux roles exigent une declaration au plan et refusent d'armer sans qu'on dise AVEC QUELLE cle : poser un fichier vide laisserait un runner se croire arme. ECRIRE PUIS RELIRE, contre la faute SYMETRIQUE de celle de la voute : la on craignait un chiffre devenu clair, ici on craint une cle qui serait une voute, ou vide — Ansible accepte un mot de passe vide et n'ouvre rien. Existence, taille et mode mesures apres ecriture. CE QUE CA CHANGE : le mot de passe se tapait a chaque deploiement. Un geste repete vingt fois par semaine ne prouve rien, et il rendait tout deploiement non interactif impossible sans blocage. Il se remet une fois, et c'est un evenement. P32 A TROUVE LA MOITIE MANQUANTE : le role du tenant exigeait `serveur_ops_tenant_cle_source`, absente du plan de Chezlepro. Dit avant tout deploiement, dans les bons termes. make verifier : vert. make prouver : CONFORME, 52 OK, 0 echec, 0 saute. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019f91zs9SDdwSzL2CVei6on |
||
|---|---|---|
| .. | ||
| defaults | ||
| meta | ||
| tasks | ||
| README.md | ||
serveur_ops_site
Le runner de SITE : celui qui matérialise. Il crée des VM sur la fabric, et rien d'autre.
Pourquoi ce rôle existe séparément
Le travail d'un runner se divise en trois, et la ligne de partage est celle des voûtes :
| voûte requise | portée | rôle | |
|---|---|---|---|
| calculer — plan → inventaire | aucune | tenant | serveur_ops |
| configurer — rôles sur ses machines | tenant | tenant | serveur_ops |
| matérialiser — créer/détruire des VM | SITE | fabric | ce rôle |
Un runner par tenant qui matérialiserait mettrait la voûte du SITE en N exemplaires — le secret le plus dangereux du système, recopié autant de fois qu'il y a de locataires.
Un runner unique qui ferait tout devrait entrer en SSH chez tous les tenants, donc traverser le default-deny inter-tenant. Et il rendrait l'émancipation impossible : un écosystème dont le runner appartient à l'hébergeur ne peut pas se rebâtir sans lui.
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 a le droit de 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.
Ce qu'il dépose, et comment
La voûte du SITE, chiffrée, en 0600. Le mot de passe n'est jamais 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: false est obligatoire sur la copie. Sans lui, Ansible déchiffre la source
quand il détient le mot de passe — constaté le 2026-08-24 : 776 octets en clair au lieu de
3465 chiffrés, sur une machine où ils n'avaient rien à faire. Le rôle relit l'en-tête
après avoir écrit et refuse si le fichier n'est pas chiffré.
Colocalisation
Rien n'oblige à lui donner sa propre machine : chez l'hébergeur, les deux pouvoirs résident légitimement au même endroit, et une machine de plus dans un écosystème volontairement maigre se paie. Le déclarer séparément rend le pouvoir visible, ce qui est l'essentiel.
Chez un tenant qui n'est pas l'hébergeur, la question ne se pose pas : le rôle n'a pas à y être.
Variables
| Variable | Rôle |
|---|---|
serveur_ops_site_depot |
dossier du dépôt SITE chez le runner (cloné par serveur_ops) |
serveur_ops_site_voute_source |
chemin de underlay.vault.yml sur le contrôleur |
serveur_ops_site_voute_deposer |
false pour un runner qui lit la carte sans détenir les clés |
Ce que ce rôle ne fait pas
Il n'installe rien, n'ouvre aucun port, ne sauvegarde rien. Il ne fait qu'attribuer un pouvoir — et le rendre lisible dans le plan.