Daniel Allaire
6a5a49f924
Some checks are pending
verifier / verifier (push) Waiting to run
`serveur_ops` et `serveur_ops_site` sont deployes sur `site-ops-01` : le moteur, les plans des trois tenants, les collections hors ligne, et la voute de l'underlay deposee CHIFFREE. Le site a son runner. DEUX FORMES DE RUNNER, ET UNE SEULE ETAIT PREVUE. `serveur_ops` exigeait un depot `role: instance` et un `serveur_ops_instance` — la forme d'un runner de TENANT, qui pilote un ecosysteme, monte son plan par le lien `instance`, detient sa voute. Un runner de SITE ne pilote rien : il MATERIALISE le terrain que d'autres occuperont, et son inventaire est dynamique. Son plan declarait donc ses depots de tenants en `role: tenant`, a dessein et avec ses raisons ecrites — et le role le refusait au nom d'une exigence qui ne le concernait pas. Il exige desormais que le runner pilote QUELQUE CHOSE, sans prescrire quoi. Et il posait le lien quand meme : `serveur_ops_instance: ""` donnait `instance -> /opt/setops/`, un repertoire qui n'est l'ecosysteme de personne. Un lien qui existe et ne designe rien est pire qu'un lien absent : tout ce qui le suit croit avoir trouve une instance. LE CERTIFICAT COUVRE LES NOMS DU SERVICE. `client_pki` ne mettait dans ses SAN que le FQDN, le nom court et l'IP. Le clonage du genome a bute dessus : « certificate subject name (site-forge-01.genese.internal) does not match target hostname 'forge.genese.internal' ». Le nom declare `expose:` etait publie partout — plancher, zone DNS — et couvert nulle part. Les expositions que cet hote SERT REELLEMENT entrent maintenant dans le certificat. Un certificat qui revendiquerait le nom d'un service rendu ailleurs serait une usurpation, pas une commodite. `make genome-pousser` — LE RUNNER POUSSE, LE POSTE NE ROUTE PAS. La forge du genome vit DANS le site, sur un reseau que le poste de l'exploitant ne route pas. On ne perce pas un chemin pour lui : on lui retire le role. Le poste emballe les commits dans un `git bundle` — un fichier, verifiable, qui ne demande aucun reseau — et le runner verifie, avance EN AVANCE RAPIDE SEULEMENT, puis pousse avec SA cle, autorisee en ecriture sur ces depots-la seulement. Ce qui est pousse se DERIVE de `serveur_ops_depots`. `DEPOT=<nom>` en cible un seul. Trois pieges rencontres, tous inscrits dans le code : l'outil ne peut pas etre supposé present sur le runner (il ne recevrait cette version qu'APRES la poussee qu'elle sert a faire — le controleur le porte) ; la branche n'est pas toujours `main` (deux depots vivent sur `master`, et le plan le declarait deja) ; le dossier des depots freres contient un espace, d'ou `argv` et non `cmd`. Le juge n'est pas le journal du playbook mais LA FORGE : on demande a son API ce qu'elle porte, et on refuse si ca differe de ce que porte le runner. Six depots verifies. Pourquoi ca comptait : la forge du site etait restee quatre commits derriere le poste, sans que rien ne le signale — dont le correctif qui desarme le pare-feu Proxmox. Un ecosysteme qui se reproduit depuis une forge en retard reproduit ses defauts. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| defaults | ||
| meta | ||
| tasks | ||
| templates | ||
| README.md | ||
serveur_ops
Poste d'exploitation : la machine depuis laquelle l'écosystème se reconstruit lui-même. Ansible épinglé, le génome cloné depuis sa propre forge, et une clé SSH qui n'appartient qu'à lui.
Principe
Un écosystème pouvait jusqu'ici détenir son génome sans savoir l'exécuter. Les cinq dépôts vivaient sur sa forge — moteur, plans, modèles, étiquette signée — mais Set-OPS ne tournait que depuis le poste de son mainteneur. L'écosystème possédait le livre ; personne, chez lui, ne savait le lire à voix haute.
serveur_ops est la différence entre une archive et une matrice.
Ce que le poste emporte
/opt/setops/
Set-OPS-public/ le moteur ← cloné depuis genome/set-ops-public
OPS-<instance>/ le plan ← cloné depuis genome/ops-<instance>
venv/ ansible-core 2.18 (épinglé)
.ssh/id_ed25519 la clé du poste
LISEZ-MOI.md mode d'emploi, généré
Le moteur et les instances sont des dossiers frères, comme sur le poste du
mainteneur : c'est cette fraternité que scripts/instances.py découvre pour proposer
les instances pilotables. Le lien instance désigne celle qu'on pilote.
D'où vient le génome : de sa propre forge
Le poste clone depuis https://forge.<domaine>/genome/…, pas depuis la forge
parente. Les dépôts y sont des miroirs, resynchronisés toutes les huit heures : la copie
est vivante, et l'écosystème se reconstruit depuis lui-même.
Le clone est anonyme — les dépôts du génome sont lisibles sur la forge interne. Un secret de moins sur une machine qui en concentre déjà beaucoup.
La confiance TLS vient de client_pki (racine step-ca dans le magasin système). Sans
elle, git clone refuse le certificat de la forge, et il a raison de refuser.
Les deux choses qu'il n'a PAS
Le mot de passe de la voûte. Il se saisit à l'exécution. Une machine qui détiendrait à la fois le plan, l'accès SSH à toute la flotte et la clé des secrets n'aurait plus aucune profondeur : la compromettre serait compromettre l'écosystème entier.
Le fichier de voûte lui-même. Les dépôts d'instance excluent vault.yml de git —
c'est la règle « aucun secret en clair ». Le génome cloné ici porte donc le plan sans
les secrets.
Conséquence à connaître, et qui n'est pas un défaut mais une conception :
la STRUCTURE de l'écosystème se reconstruit depuis la forge
les SECRETS se restaurent depuis la sauvegarde (restic)
Deux sources distinctes, qu'un même incident n'atteint pas ensemble.
Sa clé doit être autorisée
Le poste fabrique sa propre paire, distincte de celle du mainteneur : deux exploitants,
deux révocations possibles, et l'accès du poste se lit dans les authorized_keys de la
flotte au lieu de se confondre avec celui d'un humain.
Tant que cette clé publique n'est pas portée aux intrants SSH du plan, le poste ne joint aucun hôte. Le rôle l'affiche au déploiement ; elle se relit à tout moment :
cat /opt/setops/.ssh/id_ed25519.pub
C'est volontairement un geste humain : donner à une machine le droit d'entrer partout mérite une décision, pas un effet de bord.
Variables principales
| Variable | Défaut | Rôle |
|---|---|---|
serveur_ops_utilisateur |
setops |
compte d'exploitation |
serveur_ops_racine |
/opt/setops |
racine du poste |
serveur_ops_ansible |
ansible-core>=2.18,<2.19 |
version épinglée |
serveur_ops_forge_url |
https://forge.<domaine> |
source du génome |
serveur_ops_depots |
moteur + instance | quoi cloner, et où |
serveur_ops_instance |
l'instance du plan | cible du lien instance |
serveur_ops_cle_generer |
true |
fabriquer la clé du poste |
Dépendances
serveur_forgejo (la source du génome) — déclaré dans docs/dependances-groupes.yml,
avec sauf_si serveur_ops_forge_externe pour l'écosystème qui lit son génome ailleurs.
serveur_step_ca est utilisé si présent : sans confiance PKI, le clone échoue sur
le certificat.
Ce que ce rôle ne fait pas
Il n'ouvre aucun service, n'écoute sur aucun port, ne publie rien à l'edge. Il ne sauvegarde rien non plus : tout ce qu'il contient se recompose depuis la forge.