2026-06-24 20:17:46 -04:00
|
|
|
---
|
2026-08-07 15:33:32 -04:00
|
|
|
|
|
|
|
|
# L'URL PUBLIQUE de l'IdP se derive de l'exposition declaree au plan, elle ne se
|
|
|
|
|
# fabrique pas : `keycloak.<domaine>` n'est publie nulle part (voir resoudre_idp).
|
site : un ecosysteme complet — PKI, DNS, forge, cache, runner
Le site portait trois services sur les sept du modele `origine`. Sa forge servait LE
GENOME EN CLAIR et aucune de ses machines n'avait de certificat — donc aucun chiffrement
est-ouest, ce que la doctrine zero-confiance interdit. site-pki-01 (step-ca) et
site-dns-01 (PowerDNS + resolveur colocalises) rejoignent les trois autres.
Quatre defauts que le site a fait tomber, chacun invisible chez un tenant :
- DNS bloque par notre propre default-deny. Un tenant a son resolveur DANS son reseau
et ne traverse jamais la frontiere ; le site interroge la sienne. La regle est derivee
de `site.dns_amorcage`, destination declaree, jamais `any`.
- serveur_cache_site n'installe rien : il marque un cache et lit les variables de
serveur_artefacts. Les defauts d'un role ne sont en portee que dans le play qui
l'inclut — une dependance de role regle l'ordre ET la portee.
- resoudre_idp partait meme avec OIDC desactive, et exigeait un plan. La resolution
suit desormais l'usage.
- le plancher /etc/hosts etait VIDE : `hotes_actifs` n'existait pas dans l'inventaire
du site. Un role qui reussit en n'ecrivant rien est la pire forme d'echec.
Une machine du site peut desormais se configurer (`variables:`), appliquee en dernier :
ce qu'une machine declare d'elle-meme prime sur ce que le site declare pour toutes.
Verifie et non suppose : systemd disait `active` mais rien n'ecoutait sur 443 — step-ca
sert sur 8443. La zone souveraine resout et la recursion marche, mesurees sur la machine.
42 preuves vertes, ansible-lint profil production.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-25 12:00:17 -04:00
|
|
|
#
|
|
|
|
|
# ON NE RESOUT PAS UN FOURNISSEUR QU'ON N'UTILISERA PAS (2026-08-25).
|
|
|
|
|
#
|
|
|
|
|
# Cette resolution partait INCONDITIONNELLEMENT, y compris quand OIDC est desactive.
|
|
|
|
|
# `resoudre_idp` lit les registres du plan (`applications.yml`, `domaines.yml`) et exige
|
|
|
|
|
# que l'IdP y declare une exposition. Sur une forge SANS Keycloak — celle du site, qui
|
|
|
|
|
# porte le genome et n'a pas d'annuaire — il n'y a ni Keycloak ni plan : le role echouait
|
|
|
|
|
# sur `'setops_plan_dir' is undefined`, un message qui ne dit rien de la vraie cause.
|
|
|
|
|
#
|
|
|
|
|
# `serveur_forgejo_oidc_actif` derive deja de la presence du groupe `serveur_keycloak`.
|
|
|
|
|
# Il suffisait de s'en servir ici aussi : la resolution suit l'usage.
|
2026-08-07 15:33:32 -04:00
|
|
|
- name: Resoudre le fournisseur d'identite (role partage)
|
|
|
|
|
ansible.builtin.include_role:
|
|
|
|
|
name: resoudre_idp
|
|
|
|
|
vars:
|
|
|
|
|
resoudre_idp_realm: "{{ serveur_forgejo_oidc_realm }}"
|
site : un ecosysteme complet — PKI, DNS, forge, cache, runner
Le site portait trois services sur les sept du modele `origine`. Sa forge servait LE
GENOME EN CLAIR et aucune de ses machines n'avait de certificat — donc aucun chiffrement
est-ouest, ce que la doctrine zero-confiance interdit. site-pki-01 (step-ca) et
site-dns-01 (PowerDNS + resolveur colocalises) rejoignent les trois autres.
Quatre defauts que le site a fait tomber, chacun invisible chez un tenant :
- DNS bloque par notre propre default-deny. Un tenant a son resolveur DANS son reseau
et ne traverse jamais la frontiere ; le site interroge la sienne. La regle est derivee
de `site.dns_amorcage`, destination declaree, jamais `any`.
- serveur_cache_site n'installe rien : il marque un cache et lit les variables de
serveur_artefacts. Les defauts d'un role ne sont en portee que dans le play qui
l'inclut — une dependance de role regle l'ordre ET la portee.
- resoudre_idp partait meme avec OIDC desactive, et exigeait un plan. La resolution
suit desormais l'usage.
- le plancher /etc/hosts etait VIDE : `hotes_actifs` n'existait pas dans l'inventaire
du site. Un role qui reussit en n'ecrivant rien est la pire forme d'echec.
Une machine du site peut desormais se configurer (`variables:`), appliquee en dernier :
ce qu'une machine declare d'elle-meme prime sur ce que le site declare pour toutes.
Verifie et non suppose : systemd disait `active` mais rien n'ecoutait sur 443 — step-ca
sert sur 8443. La zone souveraine resout et la recursion marche, mesurees sur la machine.
42 preuves vertes, ansible-lint profil production.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-25 12:00:17 -04:00
|
|
|
when: serveur_forgejo_oidc_actif | bool
|
authentification : SSO Keycloak devant, secours par sudo, formulaire local fermé
Directive : toute authentification web passe par Keycloak, LDAP est la source
unique des comptes, chaque service garde un accès de secours par sudo sur
l'hôte. Les trois sont indissociables — la chaîne service → Keycloak → LDAP est
en série, donc sans secours une panne exclut tout le monde, y compris pour
réparer. Portée : le web seulement ; IMAP/SMTP se lient à LDAP directement et
SSH est en clé seule.
Posture <rôle>_connexion_locale, false par défaut. Le compte local existe — il
ne peut pas dépendre de Keycloak — mais son formulaire n'est plus proposé au
repos : ouvert en permanence, il contourne la politique de mot de passe, le MFA
et surtout la révocation centrale.
Vérifié auprès de l'amont, puis par rendu réel des gabarits dans les deux
postures :
- Grafana GF_AUTH_DISABLE_LOGIN_FORM → ferme ;
- Forgejo ENABLE_INTERNAL_SIGNIN + ENABLE_BASIC_AUTHENTICATION → ferme, API
Basic comprise. N'existe que depuis la v10 (ticket amont 7476) ; le rôle
épingle 10.0.0 et un assert refuse la fermeture en deçà, car le réglage serait
ignoré sans erreur ;
- Nextcloud hide_login_form → MASQUE seulement : ?direct=1 reste le chemin de
secours documenté par l'amont. Écrit comme tel, sans prétendre à l'équivalence.
Défaut attrapé par le rendu : la condition Forgejo sans `| bool` n'émettait rien
dans aucune posture — une valeur en chaîne est vraie au sens Jinja, la connexion
locale serait restée ouverte en silence.
docs/authentification.md, décisions D-38 à D-41. ansible-lint (production) sans
échec, 28 preuves OK.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-03 16:50:36 -04:00
|
|
|
- name: Refuser de fermer la connexion locale sur un Forgejo anterieur a la v10
|
|
|
|
|
# `ENABLE_INTERNAL_SIGNIN` a ete ajoute en v10 (suivi amont, issue 7476). Sur une
|
|
|
|
|
# version anterieure il est ignore EN SILENCE : le role croirait avoir ferme la porte
|
|
|
|
|
# alors qu'elle reste ouverte. On refuse plutot que de laisser croire.
|
|
|
|
|
ansible.builtin.assert:
|
|
|
|
|
that:
|
|
|
|
|
- serveur_forgejo_version is version('10.0.0', '>=')
|
|
|
|
|
fail_msg: >-
|
|
|
|
|
serveur_forgejo_connexion_locale=false exige Forgejo >= 10.0.0
|
|
|
|
|
(ici {{ serveur_forgejo_version }}) : le reglage serait ignore sans erreur.
|
|
|
|
|
Mettre a jour, ou assumer la connexion locale en la passant a true.
|
|
|
|
|
when: not (serveur_forgejo_connexion_locale | bool)
|
|
|
|
|
|
2026-06-24 20:17:46 -04:00
|
|
|
- name: Exiger les secrets Forgejo (Vault)
|
|
|
|
|
ansible.builtin.assert:
|
|
|
|
|
that:
|
|
|
|
|
- serveur_forgejo_secret_key | length > 0
|
|
|
|
|
- serveur_forgejo_internal_token | length > 0
|
|
|
|
|
- serveur_forgejo_admin_password | length > 0
|
|
|
|
|
fail_msg: "secret_key, internal_token et admin_password sont requis (Ansible Vault)."
|
|
|
|
|
|
forgejo : apprendre SQLite, et retirer ce qui ne servait pas
Doute de l'exploitant sur patient 0 : « je doute de la pertinence de pgsql ». Mesure
plutot que discussion.
REDIS NE SERVAIT A RIEN : le role serveur_forgejo ne le mentionne ni dans son app.ini, ni
dans ses defauts, et ne declare aucun lien. Heritage du modele `forge`. Retire du plan.
POSTGRESQL ETAIT EXIGE PAR LE ROLE : DB_TYPE = postgres en dur, resoudre_base sans
condition. Le doute etait fonde, le moteur ne savait pas faire autrement.
INTERRUPTEUR `serveur_forgejo_bd: postgres|sqlite`. En sqlite la base devient un FICHIER
sous serveur_forgejo_data. Ce que ca change ailleurs : rien. Le job de sauvegarde
`serveur_forgejo` emporte deja ce dossier ; PGSSLROOTCERT etait deja conditionne au mode
TLS ; et P35 lit desormais l'interrupteur (convention `<role>_bd`, group_vars de
l'instance puis defaut du role), donc n'attend aucune entree de registre. Une valeur
inconnue est REFUSEE au debut du role plutot que de retomber en silence sur PostgreSQL.
PATIENT 0 PASSE DE SIX A QUATRE MACHINES (Dovecot, Redis, PostgreSQL et sa VM). Sur la
machine dont tout descend, chaque service en moins est une chose de moins a defendre, a
sauvegarder et a rebatir. Et l'effet depasse patient 0 : une offre `forge` pour un petit
organisme cesse d'exiger une VM PostgreSQL.
LA NEUVIEME. En verifiant P35 sur patient 0, elle a rendu un verdict JUSTE SUR LE MAUVAIS
ECOSYSTEME : `plan = RACINE / "instance" / "plan"`, le symlink en dur. Neuvieme resolution
d'instance codee en dur en cinq jours. Ce n'est plus une serie de bogues, c'est une piece
manquante : une resolution unique et partagee, a faire en une fois et de tete reposee.
Enseigne : SQLite au glossaire (P39 l'exige desormais), et le README du role documente
l'interrupteur et ce qu'il ne change pas.
make verifier 40/40 ; make ci 40/40 ; lint et syntaxe du role verts.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-22 13:10:05 -04:00
|
|
|
- name: Refuser une base de donnees inconnue
|
|
|
|
|
# Une valeur mal orthographiee ne doit pas retomber en silence sur le defaut : elle
|
|
|
|
|
# ferait deployer PostgreSQL a qui croyait choisir SQLite, et l'ecart se lirait au
|
|
|
|
|
# premier demarrage, pas ici.
|
|
|
|
|
ansible.builtin.assert:
|
|
|
|
|
that:
|
|
|
|
|
- serveur_forgejo_bd in ['postgres', 'sqlite']
|
|
|
|
|
fail_msg: >-
|
|
|
|
|
serveur_forgejo_bd={{ serveur_forgejo_bd }} : valeurs acceptees `postgres` ou
|
|
|
|
|
`sqlite`.
|
|
|
|
|
|
2026-07-03 15:57:06 -04:00
|
|
|
- name: Resoudre la base de donnees depuis le registre (role partage)
|
|
|
|
|
ansible.builtin.include_role:
|
|
|
|
|
name: resoudre_base
|
|
|
|
|
vars:
|
|
|
|
|
resoudre_base_groupe: "{{ serveur_forgejo_groupe }}"
|
forgejo : apprendre SQLite, et retirer ce qui ne servait pas
Doute de l'exploitant sur patient 0 : « je doute de la pertinence de pgsql ». Mesure
plutot que discussion.
REDIS NE SERVAIT A RIEN : le role serveur_forgejo ne le mentionne ni dans son app.ini, ni
dans ses defauts, et ne declare aucun lien. Heritage du modele `forge`. Retire du plan.
POSTGRESQL ETAIT EXIGE PAR LE ROLE : DB_TYPE = postgres en dur, resoudre_base sans
condition. Le doute etait fonde, le moteur ne savait pas faire autrement.
INTERRUPTEUR `serveur_forgejo_bd: postgres|sqlite`. En sqlite la base devient un FICHIER
sous serveur_forgejo_data. Ce que ca change ailleurs : rien. Le job de sauvegarde
`serveur_forgejo` emporte deja ce dossier ; PGSSLROOTCERT etait deja conditionne au mode
TLS ; et P35 lit desormais l'interrupteur (convention `<role>_bd`, group_vars de
l'instance puis defaut du role), donc n'attend aucune entree de registre. Une valeur
inconnue est REFUSEE au debut du role plutot que de retomber en silence sur PostgreSQL.
PATIENT 0 PASSE DE SIX A QUATRE MACHINES (Dovecot, Redis, PostgreSQL et sa VM). Sur la
machine dont tout descend, chaque service en moins est une chose de moins a defendre, a
sauvegarder et a rebatir. Et l'effet depasse patient 0 : une offre `forge` pour un petit
organisme cesse d'exiger une VM PostgreSQL.
LA NEUVIEME. En verifiant P35 sur patient 0, elle a rendu un verdict JUSTE SUR LE MAUVAIS
ECOSYSTEME : `plan = RACINE / "instance" / "plan"`, le symlink en dur. Neuvieme resolution
d'instance codee en dur en cinq jours. Ce n'est plus une serie de bogues, c'est une piece
manquante : une resolution unique et partagee, a faire en une fois et de tete reposee.
Enseigne : SQLite au glossaire (P39 l'exige desormais), et le README du role documente
l'interrupteur et ce qu'il ne change pas.
make verifier 40/40 ; make ci 40/40 ; lint et syntaxe du role verts.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-22 13:10:05 -04:00
|
|
|
when: serveur_forgejo_bd == 'postgres'
|
2026-06-24 20:17:46 -04:00
|
|
|
|
2026-07-03 15:57:06 -04:00
|
|
|
- name: Adopter les facts de base pour Forgejo
|
2026-06-24 20:17:46 -04:00
|
|
|
ansible.builtin.set_fact:
|
2026-07-03 15:57:06 -04:00
|
|
|
serveur_forgejo_entree: "{{ resoudre_base_entree }}"
|
|
|
|
|
serveur_forgejo_db_password: "{{ resoudre_base_db_password }}"
|
|
|
|
|
serveur_forgejo_db_host: "{{ resoudre_base_db_host }}"
|
|
|
|
|
serveur_forgejo_db_port: "{{ resoudre_base_db_port }}"
|
2026-06-24 20:17:46 -04:00
|
|
|
no_log: true
|
forgejo : apprendre SQLite, et retirer ce qui ne servait pas
Doute de l'exploitant sur patient 0 : « je doute de la pertinence de pgsql ». Mesure
plutot que discussion.
REDIS NE SERVAIT A RIEN : le role serveur_forgejo ne le mentionne ni dans son app.ini, ni
dans ses defauts, et ne declare aucun lien. Heritage du modele `forge`. Retire du plan.
POSTGRESQL ETAIT EXIGE PAR LE ROLE : DB_TYPE = postgres en dur, resoudre_base sans
condition. Le doute etait fonde, le moteur ne savait pas faire autrement.
INTERRUPTEUR `serveur_forgejo_bd: postgres|sqlite`. En sqlite la base devient un FICHIER
sous serveur_forgejo_data. Ce que ca change ailleurs : rien. Le job de sauvegarde
`serveur_forgejo` emporte deja ce dossier ; PGSSLROOTCERT etait deja conditionne au mode
TLS ; et P35 lit desormais l'interrupteur (convention `<role>_bd`, group_vars de
l'instance puis defaut du role), donc n'attend aucune entree de registre. Une valeur
inconnue est REFUSEE au debut du role plutot que de retomber en silence sur PostgreSQL.
PATIENT 0 PASSE DE SIX A QUATRE MACHINES (Dovecot, Redis, PostgreSQL et sa VM). Sur la
machine dont tout descend, chaque service en moins est une chose de moins a defendre, a
sauvegarder et a rebatir. Et l'effet depasse patient 0 : une offre `forge` pour un petit
organisme cesse d'exiger une VM PostgreSQL.
LA NEUVIEME. En verifiant P35 sur patient 0, elle a rendu un verdict JUSTE SUR LE MAUVAIS
ECOSYSTEME : `plan = RACINE / "instance" / "plan"`, le symlink en dur. Neuvieme resolution
d'instance codee en dur en cinq jours. Ce n'est plus une serie de bogues, c'est une piece
manquante : une resolution unique et partagee, a faire en une fois et de tete reposee.
Enseigne : SQLite au glossaire (P39 l'exige desormais), et le README du role documente
l'interrupteur et ce qu'il ne change pas.
make verifier 40/40 ; make ci 40/40 ; lint et syntaxe du role verts.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-22 13:10:05 -04:00
|
|
|
when: serveur_forgejo_bd == 'postgres'
|
2026-06-24 20:17:46 -04:00
|
|
|
|
|
|
|
|
- name: Creer l'utilisateur systeme git
|
|
|
|
|
ansible.builtin.user:
|
|
|
|
|
name: "{{ serveur_forgejo_utilisateur }}"
|
|
|
|
|
system: true
|
|
|
|
|
shell: /bin/bash
|
|
|
|
|
home: "/home/{{ serveur_forgejo_utilisateur }}"
|
|
|
|
|
create_home: true
|
|
|
|
|
comment: "Git Version Control"
|
|
|
|
|
|
2026-08-09 13:58:33 -04:00
|
|
|
# Le chemin de destination PORTE la version : `forgejo-10.0.0` ne peut pas designer un
|
|
|
|
|
# autre contenu demain. Le binaire est donc immuable une fois pose, et le retelecharger
|
|
|
|
|
# n'a aucun sens — or `get_url` sans garde recontacte le serveur distant a CHAQUE
|
|
|
|
|
# deploiement, pour 106 Mo deja presents.
|
|
|
|
|
#
|
|
|
|
|
# Constate le 2026-08-09 pendant le passage d'idempotence : « Connection failure: The
|
|
|
|
|
# read operation timed out ». Un deploiement de flotte echouait parce qu'un serveur tiers
|
|
|
|
|
# etait lent — sur une plateforme qui se veut souveraine, c'est une dependance de trop
|
|
|
|
|
# sur le chemin critique.
|
trois reconstructions : trouver, verifier, prouver — 37 min 24 au tour 3
Tour 1 8 passages ~2 h 30 16 defauts
Tour 2 3 passages 53 min 2 defauts
Tour 3 2 passages 37 min 0
LE TOUR 2 EST CELUI QUI COMPTE LE PLUS. J avais annonce deux passages ; il en
fallait trois, parce que les deux blocages connus sont EN SERIE : on ne peut
pas amorcer une forge qui ne tourne pas, et elle ne tourne qu apres la
convergence de la cle. Un runbook ecrit d apres un recit de depannage
contenait une erreur qu aucune relecture n aurait montree — il fallait le
SUIVRE pour la voir.
DEUX MURS DE PLUS, invisibles au tour 1. site-creer rend la main avant que
les machines repondent (3 min 20 mesurees). Et les cles d hote changent a
chaque reconstruction : accept-new couvre la premiere rencontre, jamais un
changement.
LE CYCLE DE LA CLE EST DENOUE. Aucun ordre de couches n y pouvait rien — les
certificats doivent venir tot. C est la propriete du geste qui a change de
main : serveur_forgejo revendique la cle au moment ou il cree le groupe.
client_pki garde la sienne et la repose a chaque passage, parce que step
reecrit la cle a chaque renouvellement. Gain : un passage entier et 300
secondes d attente perdue.
forge-amorcer purge desormais l entree perimee de l hote que GIT va
contacter, lu dans git remote get-url — pas celle de l API, qui peut etre un
tunnel. Et il rend les quatre premieres lignes de stderr : n afficher que la
derniere m a coute un aller-retour, git terminant toujours par un message
generique.
Le runbook porte les six etapes du tour 3 avec leurs durees reelles et les
dix-huit murs.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-12 20:55:59 -04:00
|
|
|
# LE ROLE QUI CREE LE GROUPE REVENDIQUE LA CLE (2026-09-12).
|
|
|
|
|
#
|
|
|
|
|
# `client_pki` (couche `pki_client`) pose les droits de la cle d'hote pour le groupe qui
|
|
|
|
|
# doit la lire — ici `git`. Mais ce groupe est cree JUSTE AU-DESSUS, dans une couche
|
|
|
|
|
# POSTERIEURE. Au premier jour d'un site, l'ordre se mord la queue :
|
|
|
|
|
#
|
|
|
|
|
# client_pki a besoin du groupe git <- cree par ce role
|
|
|
|
|
# forgejo a besoin de la cle lisible <- posee par client_pki
|
|
|
|
|
#
|
|
|
|
|
# Mesure sur deux reconstructions completes : le passage 1 laisse la cle en `root:root`,
|
|
|
|
|
# Forgejo ne demarre pas, et l'attente du premier demarrage coute 300 SECONDES pour rien.
|
|
|
|
|
# Il fallait un passage entier de plus.
|
|
|
|
|
#
|
|
|
|
|
# AUCUN ORDRE DE COUCHES NE DENOUE CE CYCLE — les certificats doivent venir tot, tout le
|
|
|
|
|
# monde en depend. Ce qui se deplace, c'est la PROPRIETE DU GESTE : le role qui cree le
|
|
|
|
|
# groupe est celui qui peut, a cet instant, donner l'acces.
|
|
|
|
|
#
|
|
|
|
|
# `client_pki` garde la sienne et la REPOSE a chaque passage — `step` reecrit la cle a
|
|
|
|
|
# chaque renouvellement, et ne regler les droits qu'ici les perdrait des le premier.
|
|
|
|
|
# Les deux taches se recouvrent, et c'est voulu : l'une amorce, l'autre entretient.
|
|
|
|
|
- name: Donner acces a la cle d'hote au groupe git (amorcage)
|
|
|
|
|
ansible.builtin.file:
|
|
|
|
|
path: "{{ client_pki_cle | default('/etc/step/certs/' ~ (ansible_fqdn | default(ansible_hostname)) ~ '.key') }}"
|
|
|
|
|
owner: root
|
|
|
|
|
group: "{{ serveur_forgejo_utilisateur }}"
|
|
|
|
|
mode: "{{ client_pki_cle_mode | default('0640') }}"
|
|
|
|
|
failed_when: false # pas encore de certificat : `client_pki` passera apres
|
|
|
|
|
|
2026-08-09 13:58:33 -04:00
|
|
|
- name: Le binaire de cette version est-il deja pose ?
|
|
|
|
|
ansible.builtin.stat:
|
|
|
|
|
path: "/usr/local/bin/forgejo-{{ serveur_forgejo_version }}"
|
|
|
|
|
register: serveur_forgejo_binaire_present
|
|
|
|
|
|
artefacts : le controleur telecharge et pousse, la cible ne tire plus
Inventaire mesure de ce qu'une reconstruction de tenant telecharge — ~1,5 Gio :
Nextcloud 230 Mio, image collabora/code 471 Mio (Docker Hub), Keycloak 140,
Forgejo 101, oauth2-proxy 18, plus les paquets apt (Debian + Grafana +
smallstep + Icinga) sur 14 hotes.
Les quatre archives sont EPINGLEES EN VERSION et vont chacune sur UN SEUL
hote. Les retelecharger a chaque reconstruction est un gaspillage et une
dependance de plus sur le chemin critique — un serveur tiers lent a deja fait
tomber un deploiement le 2026-08-09, sur le binaire Forgejo precisement.
POURQUOI POUSSER PLUTOT QUE SERVIR UN CACHE. L'exploitant proposait son poste
comme cache HTTP ; l'intention est juste mais elle butait sur ce qu'on avait
ferme le matin meme : les regles sortantes visent !SETOPS_INTERNES, donc une
VM de tenant ne peut plus atteindre le poste. Servir un cache aurait exige de
ROUVRIR un flux vers le plan d'administration.
L'inversion evite le probleme entier : le controleur telecharge dans son cache
(~/.cache/setops, garde par un stat), puis pousse par le canal SSH qui existe
deja. Aucun port, aucun service, aucune regle, aucun couplage. Et ces
artefacts deviennent deployables HORS LIGNE une fois le cache rempli.
Ce que ca ne couvre pas, et qu'il faut nommer : l'image collabora/code, seule
entorse a la doctrine « zero Docker » du depot — elle merite sa propre
decision, pas un contournement discret ; et les paquets apt, dont le cache a
sa place cote HEBERGEUR, partage entre tenants.
Et une mesure qui a contredit mon hypothese : le .zip de Nextcloud pese
271 Mio contre 230 pour le .tar.bz2. Il telecharge PLUS pour decompresser
moins lentement. Le changement de format attend une mesure, pas une intuition.
Verifie : cache rempli (491 Mio, 4/4), ansible-lint production sur 79 fichiers,
prouver.py 35 OK, plus aucun get_url n'ecrit sur la cible.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 20:58:58 -04:00
|
|
|
# Le controleur telecharge, puis pousse par SSH — la cible ne tire jamais d'Internet.
|
|
|
|
|
# Motif explique en detail dans `roles/serveur_nextcloud/tasks/installer.yml`. C'est
|
|
|
|
|
# precisement ce binaire qui a fait tomber un deploiement de flotte le 2026-08-09, sur un
|
|
|
|
|
# « read operation timed out » venu d'un serveur tiers.
|
|
|
|
|
- name: Cache d artefacts du contrôleur
|
|
|
|
|
ansible.builtin.file:
|
|
|
|
|
path: "{{ serveur_forgejo_cache_local }}"
|
|
|
|
|
state: directory
|
|
|
|
|
mode: "0700"
|
|
|
|
|
delegate_to: localhost
|
|
|
|
|
become: false
|
|
|
|
|
when: not serveur_forgejo_binaire_present.stat.exists
|
|
|
|
|
|
depot de binaires : le site tient ce que les runners allaient chercher
Le cache du site couvrait apt ; quatre artefacts arrivaient autrement, parce qu ils
ne vivent dans aucun depot apt. Le controleur les tire puis les pousse par SSH.
Mesure du 2026-09-12 : le cache du runner du site est ABSENT. Un second locataire
monte depuis lui sortait chercher 570 Mo sur codeberg.org, github.com et
download.nextcloud.com, alors que le meme ecosysteme ne demandait plus un seul
paquet a Debian. Le poste du mainteneur les a depuis toujours : personne ne l avait vu.
Pas de relais transparent, et la mesure tranche : github.com redirige vers une URL
signee valable une heure, differente a chaque requete. Un cache qui la prend pour
cle ne fait jamais mouche. Le relais marcherait pour deux amonts sur quatre.
Donc un vrai depot, dans le service qui existe deja. LocalDirs d apt-cacher-ng publie
un repertoire du disque sous un prefixe, eprouve AVANT d ecrire le role. Aucun service,
aucun port, aucun certificat, aucun flux nouveaux : l ingress 3142 pair flotte couvre
exactement ce chemin.
Les versions ne sont pas recopiees : le role lit les defauts des quatre consommateurs.
Les quatre roles recoivent une tache AJOUTEE, placee avant leur stat de cache — si le
depot sert, le stat le voit et la tache amont se saute d elle-meme. Aucune tache
existante n a change.
P70 exige que tout dest ecrit sous un cache_local figure au depot. Une liste qui suit
une autre prend du retard ; celle-ci est nee avec sa garde.
Deux marches payees en chemin :
- failed_when: false REECRIT le verdict, donc la premiere garde de signature ne
gardait rien. Elles mesurent le fichier desormais.
- file: state=directory cree les parents en 0750 : apt-cacher-ng, qui ne tourne pas
en root, rendait 403 sur chaque fichier. Un chemin se traverse en entier.
Verifie sur l infrastructure : 6/6 artefacts servis (200/206) depuis le runner du site
ET depuis une machine du locataire a travers la frontiere ; les 6 empreintes SHA-256
sont identiques a celles qui ont construit Chezlepro ; second passage changed=0.
make prouver : 69 OK, 0 echec, 1 saute. ansible-lint : 0 failure, profil production.
Inclut aussi force: true sur cinq telechargements de cles : une reprise conditionnelle
ne reprend rien (304 Not Modified, size 0, attempts 5).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-12 23:45:00 -04:00
|
|
|
# --- LE DEPOT DU SITE D'ABORD, L'INTERNET ENSUITE (2026-09-12) ----------------
|
|
|
|
|
#
|
|
|
|
|
# Le site tient ces artefacts dans son cache (`serveur_artefacts`, LocalDirs). Un runner
|
|
|
|
|
# qui les y trouve ne sort pas du tout : c'est le meme principe que le cache apt, applique
|
|
|
|
|
# aux publications qui ne vivent dans aucun depot apt.
|
|
|
|
|
#
|
|
|
|
|
# PLACEE AVANT LE `stat` DU CACHE DU CONTROLEUR, ET C'EST TOUT LE MONTAGE : si le depot
|
|
|
|
|
# sert le fichier, le `stat` qui suit le voit, et la tache de telechargement amont se
|
|
|
|
|
# saute d'elle-meme. Aucune tache existante n'a change.
|
|
|
|
|
#
|
|
|
|
|
# `failed_when: false` — le depot est une COMMODITE. Site sans depot, depot qui n'a pas
|
|
|
|
|
# encore cette version, cache du site tout neuf : on retombe sur l'amont, comme avant.
|
|
|
|
|
- name: Prendre le binaire Forgejo au dépôt du site, avant de sortir sur Internet
|
|
|
|
|
ansible.builtin.get_url:
|
|
|
|
|
url: "{{ setops_depot_binaires }}/forgejo-{{ serveur_forgejo_version }}"
|
|
|
|
|
dest: "{{ serveur_forgejo_cache_local }}/forgejo-{{ serveur_forgejo_version }}"
|
|
|
|
|
mode: "0644"
|
|
|
|
|
timeout: 30
|
|
|
|
|
delegate_to: localhost
|
|
|
|
|
become: false
|
|
|
|
|
failed_when: false
|
|
|
|
|
when:
|
|
|
|
|
- setops_depot_binaires | default('') | length > 0
|
|
|
|
|
- not serveur_forgejo_binaire_present.stat.exists
|
|
|
|
|
|
artefacts : le controleur telecharge et pousse, la cible ne tire plus
Inventaire mesure de ce qu'une reconstruction de tenant telecharge — ~1,5 Gio :
Nextcloud 230 Mio, image collabora/code 471 Mio (Docker Hub), Keycloak 140,
Forgejo 101, oauth2-proxy 18, plus les paquets apt (Debian + Grafana +
smallstep + Icinga) sur 14 hotes.
Les quatre archives sont EPINGLEES EN VERSION et vont chacune sur UN SEUL
hote. Les retelecharger a chaque reconstruction est un gaspillage et une
dependance de plus sur le chemin critique — un serveur tiers lent a deja fait
tomber un deploiement le 2026-08-09, sur le binaire Forgejo precisement.
POURQUOI POUSSER PLUTOT QUE SERVIR UN CACHE. L'exploitant proposait son poste
comme cache HTTP ; l'intention est juste mais elle butait sur ce qu'on avait
ferme le matin meme : les regles sortantes visent !SETOPS_INTERNES, donc une
VM de tenant ne peut plus atteindre le poste. Servir un cache aurait exige de
ROUVRIR un flux vers le plan d'administration.
L'inversion evite le probleme entier : le controleur telecharge dans son cache
(~/.cache/setops, garde par un stat), puis pousse par le canal SSH qui existe
deja. Aucun port, aucun service, aucune regle, aucun couplage. Et ces
artefacts deviennent deployables HORS LIGNE une fois le cache rempli.
Ce que ca ne couvre pas, et qu'il faut nommer : l'image collabora/code, seule
entorse a la doctrine « zero Docker » du depot — elle merite sa propre
decision, pas un contournement discret ; et les paquets apt, dont le cache a
sa place cote HEBERGEUR, partage entre tenants.
Et une mesure qui a contredit mon hypothese : le .zip de Nextcloud pese
271 Mio contre 230 pour le .tar.bz2. Il telecharge PLUS pour decompresser
moins lentement. Le changement de format attend une mesure, pas une intuition.
Verifie : cache rempli (491 Mio, 4/4), ansible-lint production sur 79 fichiers,
prouver.py 35 OK, plus aucun get_url n'ecrit sur la cible.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 20:58:58 -04:00
|
|
|
- name: L artefact est-il déjà dans le cache du contrôleur ?
|
|
|
|
|
ansible.builtin.stat:
|
|
|
|
|
path: "{{ serveur_forgejo_cache_local }}/forgejo-{{ serveur_forgejo_version }}"
|
|
|
|
|
register: serveur_forgejo_cache_present
|
|
|
|
|
delegate_to: localhost
|
|
|
|
|
become: false
|
2026-08-09 13:58:33 -04:00
|
|
|
when: not serveur_forgejo_binaire_present.stat.exists
|
artefacts : le controleur telecharge et pousse, la cible ne tire plus
Inventaire mesure de ce qu'une reconstruction de tenant telecharge — ~1,5 Gio :
Nextcloud 230 Mio, image collabora/code 471 Mio (Docker Hub), Keycloak 140,
Forgejo 101, oauth2-proxy 18, plus les paquets apt (Debian + Grafana +
smallstep + Icinga) sur 14 hotes.
Les quatre archives sont EPINGLEES EN VERSION et vont chacune sur UN SEUL
hote. Les retelecharger a chaque reconstruction est un gaspillage et une
dependance de plus sur le chemin critique — un serveur tiers lent a deja fait
tomber un deploiement le 2026-08-09, sur le binaire Forgejo precisement.
POURQUOI POUSSER PLUTOT QUE SERVIR UN CACHE. L'exploitant proposait son poste
comme cache HTTP ; l'intention est juste mais elle butait sur ce qu'on avait
ferme le matin meme : les regles sortantes visent !SETOPS_INTERNES, donc une
VM de tenant ne peut plus atteindre le poste. Servir un cache aurait exige de
ROUVRIR un flux vers le plan d'administration.
L'inversion evite le probleme entier : le controleur telecharge dans son cache
(~/.cache/setops, garde par un stat), puis pousse par le canal SSH qui existe
deja. Aucun port, aucun service, aucune regle, aucun couplage. Et ces
artefacts deviennent deployables HORS LIGNE une fois le cache rempli.
Ce que ca ne couvre pas, et qu'il faut nommer : l'image collabora/code, seule
entorse a la doctrine « zero Docker » du depot — elle merite sa propre
decision, pas un contournement discret ; et les paquets apt, dont le cache a
sa place cote HEBERGEUR, partage entre tenants.
Et une mesure qui a contredit mon hypothese : le .zip de Nextcloud pese
271 Mio contre 230 pour le .tar.bz2. Il telecharge PLUS pour decompresser
moins lentement. Le changement de format attend une mesure, pas une intuition.
Verifie : cache rempli (491 Mio, 4/4), ansible-lint production sur 79 fichiers,
prouver.py 35 OK, plus aucun get_url n'ecrit sur la cible.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 20:58:58 -04:00
|
|
|
|
patient 0 debout — et quatre defauts que seul un ecosysteme DIFFERENT pouvait montrer
Quatre machines, zero echec, la forge repond (service actif, ecoute 3000, HTTP 200).
forge-01 121 taches, infra-pki-01 109, infra-edge-01 92, infra-dns-01 84.
1. UN TIERS INTERMITTENT ARRETAIT TOUT. `packages.smallstep.com` repond une fois sur deux ;
`get_url` abandonne a 10 s sans reprise. Mesure AVANT d'accuser le reseau : DNS
resolvait, la poignee TLS aboutissait, 138 Ko depuis deb.debian.org passaient en 0,09 s,
et le chemin acceptait 1450 octets en refusant 1500 — l'attendu exact en overlay. Le
reseau n'y etait pour rien. Reprises posees sur les trois telechargements du chemin
critique (serveur_step_ca, client_pki, serveur_forgejo). Une dizaine d'autres restent
sans reprise : liste dans le CHANGELOG.
2. UN `register` A ECRASE UN CHEMIN DE FICHIER. En posant la reprise, j'ai enregistre dans
`client_pki_cle`, nom que le role utilisait deja pour la cle privee. L'ecart s'est vu 70
taches plus loin : `step ca certificate` recevait un dict serialise a la place du
fichier et refusait « too many positional arguments ». Un register ecrit dans l'espace
de noms de TOUT le role.
3. LE SSO SE DECLARAIT AU LIEU DE SE DERIVER. `serveur_forgejo_oidc_actif: true` en dur
faisait cabler une source OAuth2 vers un Keycloak inexistant. Derive desormais de
l'inventaire. Quatrieme manifestation en deux jours de la meme hypothese — le moteur
supposait l'ecosysteme COMPLET — apres les intrants (P32), les bases (P35) et les
dependances causales.
AUCUN de ces defauts n'etait visible sur Chezlepro, qui porte tout et tournait deja. Ils ne
pouvaient apparaitre qu'au premier ecosysteme DIFFERENT.
make verifier 41 OK, 0 echec, 0 saute ; make test inchange.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 02:53:44 -04:00
|
|
|
# Un serveur tiers intermittent ne doit pas arreter un deploiement de quarante minutes
|
|
|
|
|
# (mesure du 2026-08-23 : la meme URL pend, puis rend 200 en 0,48 s au second essai).
|
|
|
|
|
# Defaut de `get_url` : 10 s et aucune reprise.
|
artefacts : le controleur telecharge et pousse, la cible ne tire plus
Inventaire mesure de ce qu'une reconstruction de tenant telecharge — ~1,5 Gio :
Nextcloud 230 Mio, image collabora/code 471 Mio (Docker Hub), Keycloak 140,
Forgejo 101, oauth2-proxy 18, plus les paquets apt (Debian + Grafana +
smallstep + Icinga) sur 14 hotes.
Les quatre archives sont EPINGLEES EN VERSION et vont chacune sur UN SEUL
hote. Les retelecharger a chaque reconstruction est un gaspillage et une
dependance de plus sur le chemin critique — un serveur tiers lent a deja fait
tomber un deploiement le 2026-08-09, sur le binaire Forgejo precisement.
POURQUOI POUSSER PLUTOT QUE SERVIR UN CACHE. L'exploitant proposait son poste
comme cache HTTP ; l'intention est juste mais elle butait sur ce qu'on avait
ferme le matin meme : les regles sortantes visent !SETOPS_INTERNES, donc une
VM de tenant ne peut plus atteindre le poste. Servir un cache aurait exige de
ROUVRIR un flux vers le plan d'administration.
L'inversion evite le probleme entier : le controleur telecharge dans son cache
(~/.cache/setops, garde par un stat), puis pousse par le canal SSH qui existe
deja. Aucun port, aucun service, aucune regle, aucun couplage. Et ces
artefacts deviennent deployables HORS LIGNE une fois le cache rempli.
Ce que ca ne couvre pas, et qu'il faut nommer : l'image collabora/code, seule
entorse a la doctrine « zero Docker » du depot — elle merite sa propre
decision, pas un contournement discret ; et les paquets apt, dont le cache a
sa place cote HEBERGEUR, partage entre tenants.
Et une mesure qui a contredit mon hypothese : le .zip de Nextcloud pese
271 Mio contre 230 pour le .tar.bz2. Il telecharge PLUS pour decompresser
moins lentement. Le changement de format attend une mesure, pas une intuition.
Verifie : cache rempli (491 Mio, 4/4), ansible-lint production sur 79 fichiers,
prouver.py 35 OK, plus aucun get_url n'ecrit sur la cible.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 20:58:58 -04:00
|
|
|
- name: Télécharger le binaire Forgejo dans le cache du contrôleur (une seule fois)
|
2026-06-24 20:17:46 -04:00
|
|
|
ansible.builtin.get_url:
|
|
|
|
|
url: "{{ serveur_forgejo_url }}"
|
artefacts : le controleur telecharge et pousse, la cible ne tire plus
Inventaire mesure de ce qu'une reconstruction de tenant telecharge — ~1,5 Gio :
Nextcloud 230 Mio, image collabora/code 471 Mio (Docker Hub), Keycloak 140,
Forgejo 101, oauth2-proxy 18, plus les paquets apt (Debian + Grafana +
smallstep + Icinga) sur 14 hotes.
Les quatre archives sont EPINGLEES EN VERSION et vont chacune sur UN SEUL
hote. Les retelecharger a chaque reconstruction est un gaspillage et une
dependance de plus sur le chemin critique — un serveur tiers lent a deja fait
tomber un deploiement le 2026-08-09, sur le binaire Forgejo precisement.
POURQUOI POUSSER PLUTOT QUE SERVIR UN CACHE. L'exploitant proposait son poste
comme cache HTTP ; l'intention est juste mais elle butait sur ce qu'on avait
ferme le matin meme : les regles sortantes visent !SETOPS_INTERNES, donc une
VM de tenant ne peut plus atteindre le poste. Servir un cache aurait exige de
ROUVRIR un flux vers le plan d'administration.
L'inversion evite le probleme entier : le controleur telecharge dans son cache
(~/.cache/setops, garde par un stat), puis pousse par le canal SSH qui existe
deja. Aucun port, aucun service, aucune regle, aucun couplage. Et ces
artefacts deviennent deployables HORS LIGNE une fois le cache rempli.
Ce que ca ne couvre pas, et qu'il faut nommer : l'image collabora/code, seule
entorse a la doctrine « zero Docker » du depot — elle merite sa propre
decision, pas un contournement discret ; et les paquets apt, dont le cache a
sa place cote HEBERGEUR, partage entre tenants.
Et une mesure qui a contredit mon hypothese : le .zip de Nextcloud pese
271 Mio contre 230 pour le .tar.bz2. Il telecharge PLUS pour decompresser
moins lentement. Le changement de format attend une mesure, pas une intuition.
Verifie : cache rempli (491 Mio, 4/4), ansible-lint production sur 79 fichiers,
prouver.py 35 OK, plus aucun get_url n'ecrit sur la cible.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 20:58:58 -04:00
|
|
|
dest: "{{ serveur_forgejo_cache_local }}/forgejo-{{ serveur_forgejo_version }}"
|
|
|
|
|
mode: "0644"
|
patient 0 debout — et quatre defauts que seul un ecosysteme DIFFERENT pouvait montrer
Quatre machines, zero echec, la forge repond (service actif, ecoute 3000, HTTP 200).
forge-01 121 taches, infra-pki-01 109, infra-edge-01 92, infra-dns-01 84.
1. UN TIERS INTERMITTENT ARRETAIT TOUT. `packages.smallstep.com` repond une fois sur deux ;
`get_url` abandonne a 10 s sans reprise. Mesure AVANT d'accuser le reseau : DNS
resolvait, la poignee TLS aboutissait, 138 Ko depuis deb.debian.org passaient en 0,09 s,
et le chemin acceptait 1450 octets en refusant 1500 — l'attendu exact en overlay. Le
reseau n'y etait pour rien. Reprises posees sur les trois telechargements du chemin
critique (serveur_step_ca, client_pki, serveur_forgejo). Une dizaine d'autres restent
sans reprise : liste dans le CHANGELOG.
2. UN `register` A ECRASE UN CHEMIN DE FICHIER. En posant la reprise, j'ai enregistre dans
`client_pki_cle`, nom que le role utilisait deja pour la cle privee. L'ecart s'est vu 70
taches plus loin : `step ca certificate` recevait un dict serialise a la place du
fichier et refusait « too many positional arguments ». Un register ecrit dans l'espace
de noms de TOUT le role.
3. LE SSO SE DECLARAIT AU LIEU DE SE DERIVER. `serveur_forgejo_oidc_actif: true` en dur
faisait cabler une source OAuth2 vers un Keycloak inexistant. Derive desormais de
l'inventaire. Quatrieme manifestation en deux jours de la meme hypothese — le moteur
supposait l'ecosysteme COMPLET — apres les intrants (P32), les bases (P35) et les
dependances causales.
AUCUN de ces defauts n'etait visible sur Chezlepro, qui porte tout et tournait deja. Ils ne
pouvaient apparaitre qu'au premier ecosysteme DIFFERENT.
make verifier 41 OK, 0 echec, 0 saute ; make test inchange.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 02:53:44 -04:00
|
|
|
timeout: 30
|
artefacts : le controleur telecharge et pousse, la cible ne tire plus
Inventaire mesure de ce qu'une reconstruction de tenant telecharge — ~1,5 Gio :
Nextcloud 230 Mio, image collabora/code 471 Mio (Docker Hub), Keycloak 140,
Forgejo 101, oauth2-proxy 18, plus les paquets apt (Debian + Grafana +
smallstep + Icinga) sur 14 hotes.
Les quatre archives sont EPINGLEES EN VERSION et vont chacune sur UN SEUL
hote. Les retelecharger a chaque reconstruction est un gaspillage et une
dependance de plus sur le chemin critique — un serveur tiers lent a deja fait
tomber un deploiement le 2026-08-09, sur le binaire Forgejo precisement.
POURQUOI POUSSER PLUTOT QUE SERVIR UN CACHE. L'exploitant proposait son poste
comme cache HTTP ; l'intention est juste mais elle butait sur ce qu'on avait
ferme le matin meme : les regles sortantes visent !SETOPS_INTERNES, donc une
VM de tenant ne peut plus atteindre le poste. Servir un cache aurait exige de
ROUVRIR un flux vers le plan d'administration.
L'inversion evite le probleme entier : le controleur telecharge dans son cache
(~/.cache/setops, garde par un stat), puis pousse par le canal SSH qui existe
deja. Aucun port, aucun service, aucune regle, aucun couplage. Et ces
artefacts deviennent deployables HORS LIGNE une fois le cache rempli.
Ce que ca ne couvre pas, et qu'il faut nommer : l'image collabora/code, seule
entorse a la doctrine « zero Docker » du depot — elle merite sa propre
decision, pas un contournement discret ; et les paquets apt, dont le cache a
sa place cote HEBERGEUR, partage entre tenants.
Et une mesure qui a contredit mon hypothese : le .zip de Nextcloud pese
271 Mio contre 230 pour le .tar.bz2. Il telecharge PLUS pour decompresser
moins lentement. Le changement de format attend une mesure, pas une intuition.
Verifie : cache rempli (491 Mio, 4/4), ansible-lint production sur 79 fichiers,
prouver.py 35 OK, plus aucun get_url n'ecrit sur la cible.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 20:58:58 -04:00
|
|
|
delegate_to: localhost
|
|
|
|
|
become: false
|
|
|
|
|
when:
|
|
|
|
|
- not serveur_forgejo_binaire_present.stat.exists
|
|
|
|
|
- not (serveur_forgejo_cache_present.stat.exists | default(false))
|
patient 0 debout — et quatre defauts que seul un ecosysteme DIFFERENT pouvait montrer
Quatre machines, zero echec, la forge repond (service actif, ecoute 3000, HTTP 200).
forge-01 121 taches, infra-pki-01 109, infra-edge-01 92, infra-dns-01 84.
1. UN TIERS INTERMITTENT ARRETAIT TOUT. `packages.smallstep.com` repond une fois sur deux ;
`get_url` abandonne a 10 s sans reprise. Mesure AVANT d'accuser le reseau : DNS
resolvait, la poignee TLS aboutissait, 138 Ko depuis deb.debian.org passaient en 0,09 s,
et le chemin acceptait 1450 octets en refusant 1500 — l'attendu exact en overlay. Le
reseau n'y etait pour rien. Reprises posees sur les trois telechargements du chemin
critique (serveur_step_ca, client_pki, serveur_forgejo). Une dizaine d'autres restent
sans reprise : liste dans le CHANGELOG.
2. UN `register` A ECRASE UN CHEMIN DE FICHIER. En posant la reprise, j'ai enregistre dans
`client_pki_cle`, nom que le role utilisait deja pour la cle privee. L'ecart s'est vu 70
taches plus loin : `step ca certificate` recevait un dict serialise a la place du
fichier et refusait « too many positional arguments ». Un register ecrit dans l'espace
de noms de TOUT le role.
3. LE SSO SE DECLARAIT AU LIEU DE SE DERIVER. `serveur_forgejo_oidc_actif: true` en dur
faisait cabler une source OAuth2 vers un Keycloak inexistant. Derive desormais de
l'inventaire. Quatrieme manifestation en deux jours de la meme hypothese — le moteur
supposait l'ecosysteme COMPLET — apres les intrants (P32), les bases (P35) et les
dependances causales.
AUCUN de ces defauts n'etait visible sur Chezlepro, qui porte tout et tournait deja. Ils ne
pouvaient apparaitre qu'au premier ecosysteme DIFFERENT.
make verifier 41 OK, 0 echec, 0 saute ; make test inchange.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 02:53:44 -04:00
|
|
|
register: serveur_forgejo_bin
|
|
|
|
|
retries: 5
|
|
|
|
|
delay: 6
|
|
|
|
|
until: serveur_forgejo_bin is succeeded
|
artefacts : le controleur telecharge et pousse, la cible ne tire plus
Inventaire mesure de ce qu'une reconstruction de tenant telecharge — ~1,5 Gio :
Nextcloud 230 Mio, image collabora/code 471 Mio (Docker Hub), Keycloak 140,
Forgejo 101, oauth2-proxy 18, plus les paquets apt (Debian + Grafana +
smallstep + Icinga) sur 14 hotes.
Les quatre archives sont EPINGLEES EN VERSION et vont chacune sur UN SEUL
hote. Les retelecharger a chaque reconstruction est un gaspillage et une
dependance de plus sur le chemin critique — un serveur tiers lent a deja fait
tomber un deploiement le 2026-08-09, sur le binaire Forgejo precisement.
POURQUOI POUSSER PLUTOT QUE SERVIR UN CACHE. L'exploitant proposait son poste
comme cache HTTP ; l'intention est juste mais elle butait sur ce qu'on avait
ferme le matin meme : les regles sortantes visent !SETOPS_INTERNES, donc une
VM de tenant ne peut plus atteindre le poste. Servir un cache aurait exige de
ROUVRIR un flux vers le plan d'administration.
L'inversion evite le probleme entier : le controleur telecharge dans son cache
(~/.cache/setops, garde par un stat), puis pousse par le canal SSH qui existe
deja. Aucun port, aucun service, aucune regle, aucun couplage. Et ces
artefacts deviennent deployables HORS LIGNE une fois le cache rempli.
Ce que ca ne couvre pas, et qu'il faut nommer : l'image collabora/code, seule
entorse a la doctrine « zero Docker » du depot — elle merite sa propre
decision, pas un contournement discret ; et les paquets apt, dont le cache a
sa place cote HEBERGEUR, partage entre tenants.
Et une mesure qui a contredit mon hypothese : le .zip de Nextcloud pese
271 Mio contre 230 pour le .tar.bz2. Il telecharge PLUS pour decompresser
moins lentement. Le changement de format attend une mesure, pas une intuition.
Verifie : cache rempli (491 Mio, 4/4), ansible-lint production sur 79 fichiers,
prouver.py 35 OK, plus aucun get_url n'ecrit sur la cible.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 20:58:58 -04:00
|
|
|
|
forgejo : epingle 16.0.2, et le verificateur accepte la cle PRIMAIRE
Six majeures d'un coup, mais la decouverte importante est ailleurs.
LA « ROTATION DE CLE » N'EN ETAIT PAS UNE. Quatre versions, trois signataires
differents — 10.0.0 par B3B1F60A, 12.0.0 par D0A82005, 14.0.0 et 16.0.2 par
C4186DF6. Ce ne sont pas des cles distinctes : ce sont des SOUS-CLES de
signature sous une primaire stable depuis 2022 (EB114F5E...C5923710, « Forgejo
<contact@forgejo.org> »). La sous-cle 0F527CF9...0E1609E5 est bien celle qui
avait signe la 12.0.0.
D'ou une correction du verificateur : il comparait l'empreinte du SIGNATAIRE,
donc une sous-cle, et aurait echoue a chaque rotation LEGITIME — on aurait
appris a lever la garde pour avancer, ce qui est la pire chose qui puisse
arriver a un controle. Il accepte desormais la cle primaire (dernier champ de
VALIDSIG), qui survit aux rotations et refuse quand meme une cle etrangere.
FORGEJO A L'ANCRE QUE KEYCLOAK N'A PAS. forgejo.org/download publie
l'empreinte, et le binaire vient de codeberg.org : la source de confiance est
INDEPENDANTE du canal de livraison. Le projet annonce lui-meme la rotation
(« the GPG key is updated on a regular basis »), ce qui confirme qu'epingler la
primaire est le bon choix. Somme sha256 egalement publiee et verifiee conforme.
Eprouve dans les deux sens : nominal 0 ; binaire altere d'un octet 1 ;
empreinte de Keycloak appliquee a Forgejo 1 ; signature d'un autre artefact 1 ;
et Keycloak ne regresse pas apres modification du comparateur.
Verifie : versions-mesurer 0 en retard, role applique sur forge-01,
ansible-lint production sur 50 fichiers, prouver.py 35 OK (code lu sans tube).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 01:04:16 -04:00
|
|
|
# VERIFIER LA SIGNATURE AVANT DE POSER UN BINAIRE EXECUTABLE SUR UN HOTE.
|
|
|
|
|
#
|
|
|
|
|
# C'est un binaire, pas une archive de donnees : ce qu'on depose ici s'execute en tant que
|
|
|
|
|
# service. La verification tourne sur le CONTROLEUR, contre la cle versionnee du depot et
|
|
|
|
|
# l'empreinte PRIMAIRE epinglee — voir `defaults/main.yml` pour la raison de la primaire.
|
patient 0 debout — et quatre defauts que seul un ecosysteme DIFFERENT pouvait montrer
Quatre machines, zero echec, la forge repond (service actif, ecoute 3000, HTTP 200).
forge-01 121 taches, infra-pki-01 109, infra-edge-01 92, infra-dns-01 84.
1. UN TIERS INTERMITTENT ARRETAIT TOUT. `packages.smallstep.com` repond une fois sur deux ;
`get_url` abandonne a 10 s sans reprise. Mesure AVANT d'accuser le reseau : DNS
resolvait, la poignee TLS aboutissait, 138 Ko depuis deb.debian.org passaient en 0,09 s,
et le chemin acceptait 1450 octets en refusant 1500 — l'attendu exact en overlay. Le
reseau n'y etait pour rien. Reprises posees sur les trois telechargements du chemin
critique (serveur_step_ca, client_pki, serveur_forgejo). Une dizaine d'autres restent
sans reprise : liste dans le CHANGELOG.
2. UN `register` A ECRASE UN CHEMIN DE FICHIER. En posant la reprise, j'ai enregistre dans
`client_pki_cle`, nom que le role utilisait deja pour la cle privee. L'ecart s'est vu 70
taches plus loin : `step ca certificate` recevait un dict serialise a la place du
fichier et refusait « too many positional arguments ». Un register ecrit dans l'espace
de noms de TOUT le role.
3. LE SSO SE DECLARAIT AU LIEU DE SE DERIVER. `serveur_forgejo_oidc_actif: true` en dur
faisait cabler une source OAuth2 vers un Keycloak inexistant. Derive desormais de
l'inventaire. Quatrieme manifestation en deux jours de la meme hypothese — le moteur
supposait l'ecosysteme COMPLET — apres les intrants (P32), les bases (P35) et les
dependances causales.
AUCUN de ces defauts n'etait visible sur Chezlepro, qui porte tout et tournait deja. Ils ne
pouvaient apparaitre qu'au premier ecosysteme DIFFERENT.
make verifier 41 OK, 0 echec, 0 saute ; make test inchange.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 02:53:44 -04:00
|
|
|
|
|
|
|
|
# Un serveur tiers intermittent ne doit pas arreter un deploiement de quarante minutes
|
|
|
|
|
# (mesure du 2026-08-23 : la meme URL pend, puis rend 200 en 0,48 s au second essai).
|
|
|
|
|
# Defaut de `get_url` : 10 s et aucune reprise.
|
depot de binaires : le site tient ce que les runners allaient chercher
Le cache du site couvrait apt ; quatre artefacts arrivaient autrement, parce qu ils
ne vivent dans aucun depot apt. Le controleur les tire puis les pousse par SSH.
Mesure du 2026-09-12 : le cache du runner du site est ABSENT. Un second locataire
monte depuis lui sortait chercher 570 Mo sur codeberg.org, github.com et
download.nextcloud.com, alors que le meme ecosysteme ne demandait plus un seul
paquet a Debian. Le poste du mainteneur les a depuis toujours : personne ne l avait vu.
Pas de relais transparent, et la mesure tranche : github.com redirige vers une URL
signee valable une heure, differente a chaque requete. Un cache qui la prend pour
cle ne fait jamais mouche. Le relais marcherait pour deux amonts sur quatre.
Donc un vrai depot, dans le service qui existe deja. LocalDirs d apt-cacher-ng publie
un repertoire du disque sous un prefixe, eprouve AVANT d ecrire le role. Aucun service,
aucun port, aucun certificat, aucun flux nouveaux : l ingress 3142 pair flotte couvre
exactement ce chemin.
Les versions ne sont pas recopiees : le role lit les defauts des quatre consommateurs.
Les quatre roles recoivent une tache AJOUTEE, placee avant leur stat de cache — si le
depot sert, le stat le voit et la tache amont se saute d elle-meme. Aucune tache
existante n a change.
P70 exige que tout dest ecrit sous un cache_local figure au depot. Une liste qui suit
une autre prend du retard ; celle-ci est nee avec sa garde.
Deux marches payees en chemin :
- failed_when: false REECRIT le verdict, donc la premiere garde de signature ne
gardait rien. Elles mesurent le fichier desormais.
- file: state=directory cree les parents en 0750 : apt-cacher-ng, qui ne tourne pas
en root, rendait 403 sur chaque fichier. Un chemin se traverse en entier.
Verifie sur l infrastructure : 6/6 artefacts servis (200/206) depuis le runner du site
ET depuis une machine du locataire a travers la frontiere ; les 6 empreintes SHA-256
sont identiques a celles qui ont construit Chezlepro ; second passage changed=0.
make prouver : 69 OK, 0 echec, 1 saute. ansible-lint : 0 failure, profil production.
Inclut aussi force: true sur cinq telechargements de cles : une reprise conditionnelle
ne reprend rien (304 Not Modified, size 0, attempts 5).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-12 23:45:00 -04:00
|
|
|
# LA SIGNATURE AUSSI VIENT DU DEPOT QUAND IL L'A (2026-09-12). Elle pese 228 octets,
|
|
|
|
|
# mais elle est demandee a CHAQUE passage ou la cible n'a pas encore le binaire : sans
|
|
|
|
|
# elle ici, un ecosysteme entierement servi par le site sortirait quand meme sur Internet
|
|
|
|
|
# pour un quart de kilo-octet. Une sortie reste une sortie.
|
|
|
|
|
- name: Prendre la signature au dépôt du site, avant de sortir sur Internet
|
|
|
|
|
ansible.builtin.get_url:
|
|
|
|
|
url: "{{ setops_depot_binaires }}/forgejo-{{ serveur_forgejo_version }}.asc"
|
|
|
|
|
dest: "{{ serveur_forgejo_cache_local }}/forgejo-{{ serveur_forgejo_version }}.asc"
|
|
|
|
|
mode: "0644"
|
|
|
|
|
timeout: 30
|
|
|
|
|
force: true
|
|
|
|
|
delegate_to: localhost
|
|
|
|
|
become: false
|
|
|
|
|
failed_when: false
|
|
|
|
|
when:
|
|
|
|
|
- setops_depot_binaires | default('') | length > 0
|
|
|
|
|
- not serveur_forgejo_binaire_present.stat.exists
|
|
|
|
|
|
|
|
|
|
# ON MESURE LE FICHIER, PAS LE VERDICT DE LA TACHE. `failed_when: false` REECRIT le
|
|
|
|
|
# verdict : la tache n'est plus jamais `failed`, donc une garde posee dessus est toujours
|
|
|
|
|
# vraie et ne garde rien. Le depot connait cette marche — elle a deja declare « joignable »
|
|
|
|
|
# un amont mesure muet la seconde d'avant. Ce qui compte ici, c'est qu'un fichier soit la.
|
|
|
|
|
- name: La signature est-elle arrivée dans le cache du contrôleur ?
|
|
|
|
|
ansible.builtin.stat:
|
|
|
|
|
path: "{{ serveur_forgejo_cache_local }}/forgejo-{{ serveur_forgejo_version }}.asc"
|
|
|
|
|
register: serveur_forgejo_asc_present
|
|
|
|
|
delegate_to: localhost
|
|
|
|
|
become: false
|
|
|
|
|
|
forgejo : epingle 16.0.2, et le verificateur accepte la cle PRIMAIRE
Six majeures d'un coup, mais la decouverte importante est ailleurs.
LA « ROTATION DE CLE » N'EN ETAIT PAS UNE. Quatre versions, trois signataires
differents — 10.0.0 par B3B1F60A, 12.0.0 par D0A82005, 14.0.0 et 16.0.2 par
C4186DF6. Ce ne sont pas des cles distinctes : ce sont des SOUS-CLES de
signature sous une primaire stable depuis 2022 (EB114F5E...C5923710, « Forgejo
<contact@forgejo.org> »). La sous-cle 0F527CF9...0E1609E5 est bien celle qui
avait signe la 12.0.0.
D'ou une correction du verificateur : il comparait l'empreinte du SIGNATAIRE,
donc une sous-cle, et aurait echoue a chaque rotation LEGITIME — on aurait
appris a lever la garde pour avancer, ce qui est la pire chose qui puisse
arriver a un controle. Il accepte desormais la cle primaire (dernier champ de
VALIDSIG), qui survit aux rotations et refuse quand meme une cle etrangere.
FORGEJO A L'ANCRE QUE KEYCLOAK N'A PAS. forgejo.org/download publie
l'empreinte, et le binaire vient de codeberg.org : la source de confiance est
INDEPENDANTE du canal de livraison. Le projet annonce lui-meme la rotation
(« the GPG key is updated on a regular basis »), ce qui confirme qu'epingler la
primaire est le bon choix. Somme sha256 egalement publiee et verifiee conforme.
Eprouve dans les deux sens : nominal 0 ; binaire altere d'un octet 1 ;
empreinte de Keycloak appliquee a Forgejo 1 ; signature d'un autre artefact 1 ;
et Keycloak ne regresse pas apres modification du comparateur.
Verifie : versions-mesurer 0 en retard, role applique sur forge-01,
ansible-lint production sur 50 fichiers, prouver.py 35 OK (code lu sans tube).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 01:04:16 -04:00
|
|
|
- name: Récupérer la signature détachée du binaire
|
|
|
|
|
ansible.builtin.get_url:
|
|
|
|
|
url: "{{ serveur_forgejo_signature_url }}"
|
|
|
|
|
dest: "{{ serveur_forgejo_cache_local }}/forgejo-{{ serveur_forgejo_version }}.asc"
|
|
|
|
|
mode: "0644"
|
patient 0 debout — et quatre defauts que seul un ecosysteme DIFFERENT pouvait montrer
Quatre machines, zero echec, la forge repond (service actif, ecoute 3000, HTTP 200).
forge-01 121 taches, infra-pki-01 109, infra-edge-01 92, infra-dns-01 84.
1. UN TIERS INTERMITTENT ARRETAIT TOUT. `packages.smallstep.com` repond une fois sur deux ;
`get_url` abandonne a 10 s sans reprise. Mesure AVANT d'accuser le reseau : DNS
resolvait, la poignee TLS aboutissait, 138 Ko depuis deb.debian.org passaient en 0,09 s,
et le chemin acceptait 1450 octets en refusant 1500 — l'attendu exact en overlay. Le
reseau n'y etait pour rien. Reprises posees sur les trois telechargements du chemin
critique (serveur_step_ca, client_pki, serveur_forgejo). Une dizaine d'autres restent
sans reprise : liste dans le CHANGELOG.
2. UN `register` A ECRASE UN CHEMIN DE FICHIER. En posant la reprise, j'ai enregistre dans
`client_pki_cle`, nom que le role utilisait deja pour la cle privee. L'ecart s'est vu 70
taches plus loin : `step ca certificate` recevait un dict serialise a la place du
fichier et refusait « too many positional arguments ». Un register ecrit dans l'espace
de noms de TOUT le role.
3. LE SSO SE DECLARAIT AU LIEU DE SE DERIVER. `serveur_forgejo_oidc_actif: true` en dur
faisait cabler une source OAuth2 vers un Keycloak inexistant. Derive desormais de
l'inventaire. Quatrieme manifestation en deux jours de la meme hypothese — le moteur
supposait l'ecosysteme COMPLET — apres les intrants (P32), les bases (P35) et les
dependances causales.
AUCUN de ces defauts n'etait visible sur Chezlepro, qui porte tout et tournait deja. Ils ne
pouvaient apparaitre qu'au premier ecosysteme DIFFERENT.
make verifier 41 OK, 0 echec, 0 saute ; make test inchange.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 02:53:44 -04:00
|
|
|
timeout: 30
|
forgejo : epingle 16.0.2, et le verificateur accepte la cle PRIMAIRE
Six majeures d'un coup, mais la decouverte importante est ailleurs.
LA « ROTATION DE CLE » N'EN ETAIT PAS UNE. Quatre versions, trois signataires
differents — 10.0.0 par B3B1F60A, 12.0.0 par D0A82005, 14.0.0 et 16.0.2 par
C4186DF6. Ce ne sont pas des cles distinctes : ce sont des SOUS-CLES de
signature sous une primaire stable depuis 2022 (EB114F5E...C5923710, « Forgejo
<contact@forgejo.org> »). La sous-cle 0F527CF9...0E1609E5 est bien celle qui
avait signe la 12.0.0.
D'ou une correction du verificateur : il comparait l'empreinte du SIGNATAIRE,
donc une sous-cle, et aurait echoue a chaque rotation LEGITIME — on aurait
appris a lever la garde pour avancer, ce qui est la pire chose qui puisse
arriver a un controle. Il accepte desormais la cle primaire (dernier champ de
VALIDSIG), qui survit aux rotations et refuse quand meme une cle etrangere.
FORGEJO A L'ANCRE QUE KEYCLOAK N'A PAS. forgejo.org/download publie
l'empreinte, et le binaire vient de codeberg.org : la source de confiance est
INDEPENDANTE du canal de livraison. Le projet annonce lui-meme la rotation
(« the GPG key is updated on a regular basis »), ce qui confirme qu'epingler la
primaire est le bon choix. Somme sha256 egalement publiee et verifiee conforme.
Eprouve dans les deux sens : nominal 0 ; binaire altere d'un octet 1 ;
empreinte de Keycloak appliquee a Forgejo 1 ; signature d'un autre artefact 1 ;
et Keycloak ne regresse pas apres modification du comparateur.
Verifie : versions-mesurer 0 en retard, role applique sur forge-01,
ansible-lint production sur 50 fichiers, prouver.py 35 OK (code lu sans tube).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 01:04:16 -04:00
|
|
|
force: true
|
|
|
|
|
delegate_to: localhost
|
|
|
|
|
become: false
|
depot de binaires : le site tient ce que les runners allaient chercher
Le cache du site couvrait apt ; quatre artefacts arrivaient autrement, parce qu ils
ne vivent dans aucun depot apt. Le controleur les tire puis les pousse par SSH.
Mesure du 2026-09-12 : le cache du runner du site est ABSENT. Un second locataire
monte depuis lui sortait chercher 570 Mo sur codeberg.org, github.com et
download.nextcloud.com, alors que le meme ecosysteme ne demandait plus un seul
paquet a Debian. Le poste du mainteneur les a depuis toujours : personne ne l avait vu.
Pas de relais transparent, et la mesure tranche : github.com redirige vers une URL
signee valable une heure, differente a chaque requete. Un cache qui la prend pour
cle ne fait jamais mouche. Le relais marcherait pour deux amonts sur quatre.
Donc un vrai depot, dans le service qui existe deja. LocalDirs d apt-cacher-ng publie
un repertoire du disque sous un prefixe, eprouve AVANT d ecrire le role. Aucun service,
aucun port, aucun certificat, aucun flux nouveaux : l ingress 3142 pair flotte couvre
exactement ce chemin.
Les versions ne sont pas recopiees : le role lit les defauts des quatre consommateurs.
Les quatre roles recoivent une tache AJOUTEE, placee avant leur stat de cache — si le
depot sert, le stat le voit et la tache amont se saute d elle-meme. Aucune tache
existante n a change.
P70 exige que tout dest ecrit sous un cache_local figure au depot. Une liste qui suit
une autre prend du retard ; celle-ci est nee avec sa garde.
Deux marches payees en chemin :
- failed_when: false REECRIT le verdict, donc la premiere garde de signature ne
gardait rien. Elles mesurent le fichier desormais.
- file: state=directory cree les parents en 0750 : apt-cacher-ng, qui ne tourne pas
en root, rendait 403 sur chaque fichier. Un chemin se traverse en entier.
Verifie sur l infrastructure : 6/6 artefacts servis (200/206) depuis le runner du site
ET depuis une machine du locataire a travers la frontiere ; les 6 empreintes SHA-256
sont identiques a celles qui ont construit Chezlepro ; second passage changed=0.
make prouver : 69 OK, 0 echec, 1 saute. ansible-lint : 0 failure, profil production.
Inclut aussi force: true sur cinq telechargements de cles : une reprise conditionnelle
ne reprend rien (304 Not Modified, size 0, attempts 5).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-12 23:45:00 -04:00
|
|
|
when:
|
|
|
|
|
- not serveur_forgejo_binaire_present.stat.exists
|
|
|
|
|
# Le depot a servi : ne pas ressortir pour ecraser ce qu'on a deja.
|
|
|
|
|
- not (serveur_forgejo_asc_present.stat.exists and (serveur_forgejo_asc_present.stat.size | default(0)) > 0)
|
patient 0 debout — et quatre defauts que seul un ecosysteme DIFFERENT pouvait montrer
Quatre machines, zero echec, la forge repond (service actif, ecoute 3000, HTTP 200).
forge-01 121 taches, infra-pki-01 109, infra-edge-01 92, infra-dns-01 84.
1. UN TIERS INTERMITTENT ARRETAIT TOUT. `packages.smallstep.com` repond une fois sur deux ;
`get_url` abandonne a 10 s sans reprise. Mesure AVANT d'accuser le reseau : DNS
resolvait, la poignee TLS aboutissait, 138 Ko depuis deb.debian.org passaient en 0,09 s,
et le chemin acceptait 1450 octets en refusant 1500 — l'attendu exact en overlay. Le
reseau n'y etait pour rien. Reprises posees sur les trois telechargements du chemin
critique (serveur_step_ca, client_pki, serveur_forgejo). Une dizaine d'autres restent
sans reprise : liste dans le CHANGELOG.
2. UN `register` A ECRASE UN CHEMIN DE FICHIER. En posant la reprise, j'ai enregistre dans
`client_pki_cle`, nom que le role utilisait deja pour la cle privee. L'ecart s'est vu 70
taches plus loin : `step ca certificate` recevait un dict serialise a la place du
fichier et refusait « too many positional arguments ». Un register ecrit dans l'espace
de noms de TOUT le role.
3. LE SSO SE DECLARAIT AU LIEU DE SE DERIVER. `serveur_forgejo_oidc_actif: true` en dur
faisait cabler une source OAuth2 vers un Keycloak inexistant. Derive desormais de
l'inventaire. Quatrieme manifestation en deux jours de la meme hypothese — le moteur
supposait l'ecosysteme COMPLET — apres les intrants (P32), les bases (P35) et les
dependances causales.
AUCUN de ces defauts n'etait visible sur Chezlepro, qui porte tout et tournait deja. Ils ne
pouvaient apparaitre qu'au premier ecosysteme DIFFERENT.
make verifier 41 OK, 0 echec, 0 saute ; make test inchange.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 02:53:44 -04:00
|
|
|
register: serveur_forgejo_sig
|
|
|
|
|
retries: 5
|
|
|
|
|
delay: 6
|
|
|
|
|
until: serveur_forgejo_sig is succeeded
|
forgejo : epingle 16.0.2, et le verificateur accepte la cle PRIMAIRE
Six majeures d'un coup, mais la decouverte importante est ailleurs.
LA « ROTATION DE CLE » N'EN ETAIT PAS UNE. Quatre versions, trois signataires
differents — 10.0.0 par B3B1F60A, 12.0.0 par D0A82005, 14.0.0 et 16.0.2 par
C4186DF6. Ce ne sont pas des cles distinctes : ce sont des SOUS-CLES de
signature sous une primaire stable depuis 2022 (EB114F5E...C5923710, « Forgejo
<contact@forgejo.org> »). La sous-cle 0F527CF9...0E1609E5 est bien celle qui
avait signe la 12.0.0.
D'ou une correction du verificateur : il comparait l'empreinte du SIGNATAIRE,
donc une sous-cle, et aurait echoue a chaque rotation LEGITIME — on aurait
appris a lever la garde pour avancer, ce qui est la pire chose qui puisse
arriver a un controle. Il accepte desormais la cle primaire (dernier champ de
VALIDSIG), qui survit aux rotations et refuse quand meme une cle etrangere.
FORGEJO A L'ANCRE QUE KEYCLOAK N'A PAS. forgejo.org/download publie
l'empreinte, et le binaire vient de codeberg.org : la source de confiance est
INDEPENDANTE du canal de livraison. Le projet annonce lui-meme la rotation
(« the GPG key is updated on a regular basis »), ce qui confirme qu'epingler la
primaire est le bon choix. Somme sha256 egalement publiee et verifiee conforme.
Eprouve dans les deux sens : nominal 0 ; binaire altere d'un octet 1 ;
empreinte de Keycloak appliquee a Forgejo 1 ; signature d'un autre artefact 1 ;
et Keycloak ne regresse pas apres modification du comparateur.
Verifie : versions-mesurer 0 en retard, role applique sur forge-01,
ansible-lint production sur 50 fichiers, prouver.py 35 OK (code lu sans tube).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 01:04:16 -04:00
|
|
|
|
|
|
|
|
- name: Vérifier la signature du binaire contre l empreinte épinglée
|
|
|
|
|
ansible.builtin.command:
|
|
|
|
|
argv:
|
|
|
|
|
- python3
|
|
|
|
|
- "{{ role_path }}/../../scripts/verifier_signature.py"
|
|
|
|
|
- --artefact
|
|
|
|
|
- "{{ serveur_forgejo_cache_local }}/forgejo-{{ serveur_forgejo_version }}"
|
|
|
|
|
- --signature
|
|
|
|
|
- "{{ serveur_forgejo_cache_local }}/forgejo-{{ serveur_forgejo_version }}.asc"
|
|
|
|
|
- --cle
|
|
|
|
|
- "{{ role_path }}/files/forgejo-release.asc"
|
|
|
|
|
- --empreinte
|
|
|
|
|
- "{{ serveur_forgejo_signature_empreinte }}"
|
|
|
|
|
delegate_to: localhost
|
|
|
|
|
become: false
|
|
|
|
|
changed_when: false
|
|
|
|
|
when: not serveur_forgejo_binaire_present.stat.exists
|
|
|
|
|
|
artefacts : le controleur telecharge et pousse, la cible ne tire plus
Inventaire mesure de ce qu'une reconstruction de tenant telecharge — ~1,5 Gio :
Nextcloud 230 Mio, image collabora/code 471 Mio (Docker Hub), Keycloak 140,
Forgejo 101, oauth2-proxy 18, plus les paquets apt (Debian + Grafana +
smallstep + Icinga) sur 14 hotes.
Les quatre archives sont EPINGLEES EN VERSION et vont chacune sur UN SEUL
hote. Les retelecharger a chaque reconstruction est un gaspillage et une
dependance de plus sur le chemin critique — un serveur tiers lent a deja fait
tomber un deploiement le 2026-08-09, sur le binaire Forgejo precisement.
POURQUOI POUSSER PLUTOT QUE SERVIR UN CACHE. L'exploitant proposait son poste
comme cache HTTP ; l'intention est juste mais elle butait sur ce qu'on avait
ferme le matin meme : les regles sortantes visent !SETOPS_INTERNES, donc une
VM de tenant ne peut plus atteindre le poste. Servir un cache aurait exige de
ROUVRIR un flux vers le plan d'administration.
L'inversion evite le probleme entier : le controleur telecharge dans son cache
(~/.cache/setops, garde par un stat), puis pousse par le canal SSH qui existe
deja. Aucun port, aucun service, aucune regle, aucun couplage. Et ces
artefacts deviennent deployables HORS LIGNE une fois le cache rempli.
Ce que ca ne couvre pas, et qu'il faut nommer : l'image collabora/code, seule
entorse a la doctrine « zero Docker » du depot — elle merite sa propre
decision, pas un contournement discret ; et les paquets apt, dont le cache a
sa place cote HEBERGEUR, partage entre tenants.
Et une mesure qui a contredit mon hypothese : le .zip de Nextcloud pese
271 Mio contre 230 pour le .tar.bz2. Il telecharge PLUS pour decompresser
moins lentement. Le changement de format attend une mesure, pas une intuition.
Verifie : cache rempli (491 Mio, 4/4), ansible-lint production sur 79 fichiers,
prouver.py 35 OK, plus aucun get_url n'ecrit sur la cible.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 20:58:58 -04:00
|
|
|
- name: Déposer le binaire Forgejo sur l hôte depuis le cache
|
|
|
|
|
ansible.builtin.copy:
|
|
|
|
|
src: "{{ serveur_forgejo_cache_local }}/forgejo-{{ serveur_forgejo_version }}"
|
2026-06-24 20:17:46 -04:00
|
|
|
dest: "/usr/local/bin/forgejo-{{ serveur_forgejo_version }}"
|
|
|
|
|
owner: root
|
|
|
|
|
group: root
|
|
|
|
|
mode: "0755"
|
artefacts : le controleur telecharge et pousse, la cible ne tire plus
Inventaire mesure de ce qu'une reconstruction de tenant telecharge — ~1,5 Gio :
Nextcloud 230 Mio, image collabora/code 471 Mio (Docker Hub), Keycloak 140,
Forgejo 101, oauth2-proxy 18, plus les paquets apt (Debian + Grafana +
smallstep + Icinga) sur 14 hotes.
Les quatre archives sont EPINGLEES EN VERSION et vont chacune sur UN SEUL
hote. Les retelecharger a chaque reconstruction est un gaspillage et une
dependance de plus sur le chemin critique — un serveur tiers lent a deja fait
tomber un deploiement le 2026-08-09, sur le binaire Forgejo precisement.
POURQUOI POUSSER PLUTOT QUE SERVIR UN CACHE. L'exploitant proposait son poste
comme cache HTTP ; l'intention est juste mais elle butait sur ce qu'on avait
ferme le matin meme : les regles sortantes visent !SETOPS_INTERNES, donc une
VM de tenant ne peut plus atteindre le poste. Servir un cache aurait exige de
ROUVRIR un flux vers le plan d'administration.
L'inversion evite le probleme entier : le controleur telecharge dans son cache
(~/.cache/setops, garde par un stat), puis pousse par le canal SSH qui existe
deja. Aucun port, aucun service, aucune regle, aucun couplage. Et ces
artefacts deviennent deployables HORS LIGNE une fois le cache rempli.
Ce que ca ne couvre pas, et qu'il faut nommer : l'image collabora/code, seule
entorse a la doctrine « zero Docker » du depot — elle merite sa propre
decision, pas un contournement discret ; et les paquets apt, dont le cache a
sa place cote HEBERGEUR, partage entre tenants.
Et une mesure qui a contredit mon hypothese : le .zip de Nextcloud pese
271 Mio contre 230 pour le .tar.bz2. Il telecharge PLUS pour decompresser
moins lentement. Le changement de format attend une mesure, pas une intuition.
Verifie : cache rempli (491 Mio, 4/4), ansible-lint production sur 79 fichiers,
prouver.py 35 OK, plus aucun get_url n'ecrit sur la cible.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 20:58:58 -04:00
|
|
|
when: not serveur_forgejo_binaire_present.stat.exists
|
2026-06-24 20:17:46 -04:00
|
|
|
|
|
|
|
|
- name: Activer la version courante du binaire
|
|
|
|
|
ansible.builtin.file:
|
|
|
|
|
src: "/usr/local/bin/forgejo-{{ serveur_forgejo_version }}"
|
|
|
|
|
dest: "{{ serveur_forgejo_binaire }}"
|
|
|
|
|
state: link
|
|
|
|
|
notify: Redemarrer forgejo
|
2026-10-04 00:09:03 -04:00
|
|
|
# En simulation, une NOUVELLE version n'a pas ete copiee : le lien n'aurait pas de cible
|
|
|
|
|
# (2026-10-03, premiere montee simulee). Une version deja posee, elle, se simule.
|
|
|
|
|
when: not (ansible_check_mode and not serveur_forgejo_binaire_present.stat.exists)
|
2026-06-24 20:17:46 -04:00
|
|
|
|
restauration : la reconstruction remet l'etat de l'incarnation precedente
Chaque role proprietaire (AC, bases, annuaire, Nextcloud, rspamd/DKIM,
courriel, forge, web) remet son etat au moment ou il le creerait neuf,
depuis le dernier instantane anterieur a la naissance de la machine.
La sauvegarde refuse de deposer tant qu'un etat d'avant attend.
Outil de noeud setops-restaurer ; cibles sauvegarder-maintenant,
restauration-etat, restauration-renoncer ; test_restauration.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-30 02:39:22 -04:00
|
|
|
# LES DEPOTS D'UNE INCARNATION PRECEDENTE (2026-09-30). Avant que le role ne cree
|
|
|
|
|
# l'arborescence : ensuite, le repertoire ne serait plus vierge. La base, elle, a deja
|
|
|
|
|
# ete remise par `serveur_postgresql` (ou vit dans ces fichiers, en SQLite). La
|
|
|
|
|
# configuration revient avec le secret JWT que le role relit plus bas.
|
|
|
|
|
- name: Restauration — les donnees de Forgejo sont-elles vierges ?
|
|
|
|
|
ansible.builtin.find:
|
|
|
|
|
paths: "{{ serveur_forgejo_data }}"
|
|
|
|
|
file_type: any
|
|
|
|
|
register: serveur_forgejo_data_initial
|
|
|
|
|
|
|
|
|
|
- name: Restauration — serveur_forgejo d'une incarnation precedente ?
|
|
|
|
|
ansible.builtin.include_role:
|
|
|
|
|
name: client_backup
|
|
|
|
|
tasks_from: restaurer.yml
|
|
|
|
|
vars:
|
|
|
|
|
client_backup_restaurer_jeu: serveur_forgejo
|
|
|
|
|
client_backup_restaurer_vierge: "{{ serveur_forgejo_data_initial.matched | default(1) == 0 }}"
|
|
|
|
|
|
|
|
|
|
- name: Restauration — remettre serveur_forgejo
|
|
|
|
|
changed_when: true
|
|
|
|
|
ansible.builtin.command:
|
|
|
|
|
argv: >-
|
|
|
|
|
{{ ['/usr/local/sbin/setops-restaurer', 'fichiers',
|
|
|
|
|
'--instantane', client_backup_restauration.instantane]
|
|
|
|
|
+ client_backup_restauration.chemins }}
|
|
|
|
|
when: client_backup_restauration.etat == 'a_restaurer'
|
|
|
|
|
|
|
|
|
|
# restic rend les proprietaires NUMERIQUES ; `git` n'a pas forcement le meme uid que sur
|
|
|
|
|
# la machine d'avant.
|
|
|
|
|
- name: Restauration — rendre les donnees au service
|
|
|
|
|
ansible.builtin.file:
|
|
|
|
|
path: "{{ item.chemin }}"
|
|
|
|
|
owner: "{{ item.proprietaire }}"
|
|
|
|
|
group: "{{ serveur_forgejo_utilisateur }}"
|
|
|
|
|
recurse: true
|
|
|
|
|
loop:
|
|
|
|
|
- { chemin: "{{ serveur_forgejo_data }}", proprietaire: "{{ serveur_forgejo_utilisateur }}" }
|
|
|
|
|
- { chemin: "{{ serveur_forgejo_config_dir }}", proprietaire: root }
|
|
|
|
|
when: client_backup_restauration.etat == 'a_restaurer'
|
|
|
|
|
|
|
|
|
|
- name: Restauration — acter serveur_forgejo
|
|
|
|
|
ansible.builtin.include_role:
|
|
|
|
|
name: client_backup
|
|
|
|
|
tasks_from: acter.yml
|
|
|
|
|
vars:
|
|
|
|
|
client_backup_acter_etat: restaure
|
|
|
|
|
when: client_backup_restauration.etat == 'a_restaurer'
|
|
|
|
|
|
2026-06-24 20:17:46 -04:00
|
|
|
- name: Creer les repertoires de donnees
|
|
|
|
|
ansible.builtin.file:
|
|
|
|
|
path: "{{ serveur_forgejo_data }}/{{ item }}"
|
|
|
|
|
state: directory
|
|
|
|
|
owner: "{{ serveur_forgejo_utilisateur }}"
|
|
|
|
|
group: "{{ serveur_forgejo_utilisateur }}"
|
|
|
|
|
mode: "0750"
|
|
|
|
|
loop:
|
|
|
|
|
- ""
|
|
|
|
|
- custom
|
|
|
|
|
- data
|
|
|
|
|
- log
|
|
|
|
|
|
|
|
|
|
- name: Creer le repertoire de configuration
|
|
|
|
|
ansible.builtin.file:
|
|
|
|
|
path: "{{ serveur_forgejo_config_dir }}"
|
|
|
|
|
state: directory
|
|
|
|
|
owner: root
|
|
|
|
|
group: "{{ serveur_forgejo_utilisateur }}"
|
|
|
|
|
mode: "0770"
|
|
|
|
|
|
2026-08-09 14:44:03 -04:00
|
|
|
# JWT_SECRET appartient au SERVICE, pas au depot : Forgejo le genere au premier
|
|
|
|
|
# demarrage et le persiste dans `app.ini`. Le gabarit ne le portait pas — donc chaque
|
|
|
|
|
# rendu l'EFFACAIT, Forgejo en generait un nouveau au redemarrage, et le passage suivant
|
|
|
|
|
# recommencait. Autrement dit : chaque deploiement faisait tourner le secret JWT de la
|
|
|
|
|
# forge, invalidant les jetons qu'elle avait emis. Trouve par le passage d'idempotence du
|
|
|
|
|
# 2026-08-09 — seule ligne differente entre deux rendus.
|
|
|
|
|
#
|
|
|
|
|
# On le RELIT donc avant de rendre, et on le repose tel quel. Le depot cesse de disputer
|
|
|
|
|
# au service une valeur qui lui appartient.
|
|
|
|
|
- name: Relire le secret JWT genere par Forgejo (lui appartient)
|
|
|
|
|
ansible.builtin.slurp:
|
|
|
|
|
src: "{{ serveur_forgejo_config }}"
|
|
|
|
|
register: serveur_forgejo_app_ini
|
|
|
|
|
failed_when: false
|
|
|
|
|
no_log: true
|
|
|
|
|
|
|
|
|
|
- name: Retenir le secret JWT (vide au premier deploiement)
|
|
|
|
|
ansible.builtin.set_fact:
|
|
|
|
|
# Sans groupe de capture : on selectionne la ligne, puis on retire le prefixe. La
|
|
|
|
|
# forme avec `regex_search(..., '\\1', multiline=True)` fonctionnait pourtant en
|
|
|
|
|
# isolation — mais elle echouait sur l'hote, et `no_log` (indispensable ici, c'est un
|
|
|
|
|
# secret) empechait de voir pourquoi. Une expression qu'on ne peut pas diagnostiquer
|
|
|
|
|
# en place doit ceder a une expression plus simple.
|
|
|
|
|
serveur_forgejo_jwt_secret: >-
|
|
|
|
|
{{ (serveur_forgejo_app_ini.content | default('') | b64decode).splitlines()
|
|
|
|
|
| select('match', '^JWT_SECRET *=')
|
|
|
|
|
| map('regex_replace', '^JWT_SECRET *= *', '')
|
|
|
|
|
| first | default('', true) | trim }}
|
|
|
|
|
no_log: true
|
|
|
|
|
|
2026-06-24 20:17:46 -04:00
|
|
|
- name: Deployer app.ini
|
|
|
|
|
ansible.builtin.template:
|
|
|
|
|
src: app.ini.j2
|
|
|
|
|
dest: "{{ serveur_forgejo_config }}"
|
2026-07-03 15:52:38 -04:00
|
|
|
owner: "{{ serveur_forgejo_utilisateur }}" # Forgejo persiste des secrets générés (oauth2 JWT) → doit pouvoir écrire
|
2026-06-24 20:17:46 -04:00
|
|
|
group: "{{ serveur_forgejo_utilisateur }}"
|
2026-08-09 14:44:03 -04:00
|
|
|
# 0600, et non 0640 : Forgejo REECRIT ce fichier lui-meme (il y persiste des secrets
|
|
|
|
|
# generes) et le repose systematiquement en 0600. Le role remettait 0640 a chaque
|
|
|
|
|
# passage, Forgejo le ramenait a 0600 — deux proprietaires pour un fichier, en
|
|
|
|
|
# desaccord, et un `changed` perpetuel qui redemarrait le service pour rien.
|
|
|
|
|
# Trouve par le passage d'idempotence du 2026-08-09 : contenu identique, diff VIDE,
|
|
|
|
|
# seul le mode differait — c'est ce qui rendait la cause invisible.
|
|
|
|
|
#
|
|
|
|
|
# Le desaccord n'avait aucun effet utile : le groupe est `git`, c'est-a-dire le
|
|
|
|
|
# service lui-meme. On s'aligne sur le plus strict, qui est aussi le sien.
|
|
|
|
|
mode: "0600"
|
2026-06-24 20:17:46 -04:00
|
|
|
no_log: true
|
|
|
|
|
notify: Redemarrer forgejo
|
|
|
|
|
|
2026-07-04 15:47:39 -04:00
|
|
|
- name: Deployer l'identite visuelle (logo, favicon, accent aurore, accueil)
|
|
|
|
|
ansible.builtin.copy:
|
|
|
|
|
src: custom/
|
|
|
|
|
dest: "{{ serveur_forgejo_data }}/custom/"
|
|
|
|
|
owner: "{{ serveur_forgejo_utilisateur }}"
|
|
|
|
|
group: "{{ serveur_forgejo_utilisateur }}"
|
|
|
|
|
mode: "0644"
|
|
|
|
|
directory_mode: "0755"
|
|
|
|
|
when: serveur_forgejo_branding | bool
|
|
|
|
|
notify: Redemarrer forgejo
|
|
|
|
|
|
2026-06-24 20:17:46 -04:00
|
|
|
- name: Deployer l'unite systemd forgejo
|
|
|
|
|
ansible.builtin.template:
|
|
|
|
|
src: forgejo.service.j2
|
|
|
|
|
dest: /etc/systemd/system/forgejo.service
|
|
|
|
|
owner: root
|
|
|
|
|
group: root
|
|
|
|
|
mode: "0644"
|
|
|
|
|
notify: Redemarrer forgejo
|
|
|
|
|
|
|
|
|
|
- name: Activer et demarrer Forgejo
|
2026-07-01 21:01:53 -04:00
|
|
|
when: not ansible_check_mode
|
2026-06-24 20:17:46 -04:00
|
|
|
ansible.builtin.systemd:
|
|
|
|
|
name: "{{ serveur_forgejo_service }}"
|
|
|
|
|
enabled: true
|
|
|
|
|
state: started
|
|
|
|
|
daemon_reload: true
|
|
|
|
|
|
forgejo : laisser le premier demarrage finir avant de l interrompre
Deuxieme reconstruction de validation de Chezlepro : 14/14 hotes, 0 echec,
make valider 0 echec sur 13. Les corrections de la veille ont toutes tenu —
la garde de clonage a laisse passer trois WARNINGS, client_artefacts a degrade
sur le cache du site puis bascule seul.
Un defaut que la premiere reconstruction n avait pas montre : le role DEMARRE
Forgejo, qui entame son initialisation de premier lancement (schema +
migrations, plusieurs dizaines de secondes), puis flush_handlers le REDEMARRE
parce qu app.ini vient de changer. Redemarre au milieu, il laisse la version
cible inscrite et le schema absent — 5 tables, version=305 — et boucle
indefiniment sur migration[v14a] : la relation collaboration n existe pas .
Le service reste active, il reessaie, et n ecoute jamais son port.
Invisible aux deploiements suivants : la base est deja migree, le premier
demarrage est instantane, le redemarrage ne tombe au milieu de rien. Le defaut
n existe que sur une base VIERGE, et meme la il depend du timing.
La chaine de sauvegarde est prouvee sur une flotte nee il y a une heure : neuf
detenteurs deposent chez l hebergeur, chacun verifie SON depot avec la cle qu il
est seul a detenir, et le rapporte a sa propre supervision.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019f91zs9SDdwSzL2CVei6on
2026-09-02 22:27:38 -04:00
|
|
|
# LAISSER LE PREMIER DEMARRAGE FINIR AVANT DE L'INTERROMPRE (2026-09-02).
|
|
|
|
|
#
|
|
|
|
|
# Au TOUT PREMIER demarrage, Forgejo cree son schema et deroule ses migrations — plusieurs
|
|
|
|
|
# dizaines de secondes. Le `flush_handlers` ci-dessous le REDEMARRE parce qu'`app.ini`
|
|
|
|
|
# vient de changer. Redemarre au milieu, il laisse une base a moitie faite : la version
|
|
|
|
|
# cible est deja inscrite dans `version`, le schema ne l'est pas.
|
|
|
|
|
#
|
|
|
|
|
# Il ne s'en releve jamais seul. La migration suivante cherche une table qui n'a jamais
|
|
|
|
|
# ete creee et echoue en boucle :
|
|
|
|
|
#
|
|
|
|
|
# migration[v14a_add-foreign-keys-collaboration] ... failure to delete inconsistent
|
|
|
|
|
# records before foreign key sync: la relation « collaboration » n'existe pas
|
|
|
|
|
#
|
|
|
|
|
# ORM engine initialization attempt #1/10, #2/10... indefiniment. Le service reste
|
|
|
|
|
# `active` — il n'a pas plante, il reessaie — et n'ecoute jamais son port.
|
|
|
|
|
#
|
|
|
|
|
# CE QUI RENDAIT CE DEFAUT INVISIBLE : aux deploiements SUIVANTS la base est deja migree,
|
|
|
|
|
# le premier demarrage est instantane, et le redemarrage ne tombe au milieu de rien. Il
|
|
|
|
|
# ne se manifeste que sur une base VIERGE — donc a la reconstruction, et pas a chaque
|
|
|
|
|
# fois : c'est une course. Il a fallu deux reconstructions completes pour le voir.
|
|
|
|
|
- name: Attendre la fin du PREMIER demarrage avant tout redemarrage
|
|
|
|
|
ansible.builtin.wait_for:
|
|
|
|
|
host: 127.0.0.1
|
|
|
|
|
port: "{{ serveur_forgejo_http_port }}"
|
|
|
|
|
timeout: 300
|
|
|
|
|
when: not ansible_check_mode
|
|
|
|
|
|
2026-07-03 15:52:38 -04:00
|
|
|
- name: Appliquer les redemarrages Forgejo (config a jour) avant admin/OAuth2
|
|
|
|
|
ansible.builtin.meta: flush_handlers
|
|
|
|
|
|
forgejo : laisser le premier demarrage finir avant de l interrompre
Deuxieme reconstruction de validation de Chezlepro : 14/14 hotes, 0 echec,
make valider 0 echec sur 13. Les corrections de la veille ont toutes tenu —
la garde de clonage a laisse passer trois WARNINGS, client_artefacts a degrade
sur le cache du site puis bascule seul.
Un defaut que la premiere reconstruction n avait pas montre : le role DEMARRE
Forgejo, qui entame son initialisation de premier lancement (schema +
migrations, plusieurs dizaines de secondes), puis flush_handlers le REDEMARRE
parce qu app.ini vient de changer. Redemarre au milieu, il laisse la version
cible inscrite et le schema absent — 5 tables, version=305 — et boucle
indefiniment sur migration[v14a] : la relation collaboration n existe pas .
Le service reste active, il reessaie, et n ecoute jamais son port.
Invisible aux deploiements suivants : la base est deja migree, le premier
demarrage est instantane, le redemarrage ne tombe au milieu de rien. Le defaut
n existe que sur une base VIERGE, et meme la il depend du timing.
La chaine de sauvegarde est prouvee sur une flotte nee il y a une heure : neuf
detenteurs deposent chez l hebergeur, chacun verifie SON depot avec la cle qu il
est seul a detenir, et le rapporte a sa propre supervision.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019f91zs9SDdwSzL2CVei6on
2026-09-02 22:27:38 -04:00
|
|
|
- name: Attendre que Forgejo reponde (apres redemarrage)
|
2026-07-03 15:52:38 -04:00
|
|
|
ansible.builtin.wait_for:
|
|
|
|
|
host: 127.0.0.1
|
|
|
|
|
port: "{{ serveur_forgejo_http_port }}"
|
|
|
|
|
timeout: 120
|
|
|
|
|
when: not ansible_check_mode
|
|
|
|
|
|
2026-06-24 20:17:46 -04:00
|
|
|
- name: Creer le compte administrateur (une fois)
|
genome : les cinq depots vivent sur la forge de patient 0
La boucle est fermee. Set-OPS-public (avec son etiquette SIGNEE v2026.08.21),
SITE-Chezlepro, OPS-Chezlepro, OPS-Patient0 et Set-OPS-Modeles sont sur la forge de
l'ecosysteme que le moteur vient de fabriquer. La filiation reste donc verifiable depuis
l'enfant, sans rien demander au parent.
Le genome existe desormais en TROIS exemplaires vivants et independants : eregion, le poste
de l'exploitant, patient 0. C'est le seuil a partir duquel reecrire l'histoire suppose de
convaincre plusieurs temoins — la propriete recherchee, obtenue sans blockchain, comme
effet secondaire de la lignee.
LE CHEMIN A DU SE PLIER A LA POLITIQUE. Le port 3000 n'est pas ouvert depuis le poste, et
le SSH de forge-01 refuse le transfert de ports (durcissement). Versement par paquets git
deposes sur l'hote, puis pousses depuis lui a travers l'API locale — donc par les crochets
de la forge, comme n'importe quel push. Aucune regle assouplie pour la commodite.
LE COMPTE DE SECOURS NE SECOURAIT RIEN. Forgejo exige par defaut un changement de mot de
passe au premier acces et refuse toute requete d'API tant qu'il n'a pas eu lieu. Or ce role
DESACTIVE la connexion locale (SSO d'abord) : aucun chemin n'existait pour ce changement.
Le compte administrateur etait donc inutilisable des sa creation, sur toutes les forges
deployees. `--must-change-password=false` est pose ; le mot de passe vient de la voute et
tourne deja par empreinte.
Cinquieme defaut revele par le meme ecosysteme. Aucun n'etait visible sur une flotte
debout : il fallait en construire une AUTRE, et s'en servir.
make verifier 41 OK, 0 echec, 0 saute ; lint vert.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 03:09:34 -04:00
|
|
|
# `--must-change-password=false` : SANS LUI, LE COMPTE EST INUTILISABLE (2026-08-23,
|
2026-09-27 21:53:36 -04:00
|
|
|
# premiere forge d'un ecosysteme). Forgejo exige par defaut un changement de mot de passe
|
genome : les cinq depots vivent sur la forge de patient 0
La boucle est fermee. Set-OPS-public (avec son etiquette SIGNEE v2026.08.21),
SITE-Chezlepro, OPS-Chezlepro, OPS-Patient0 et Set-OPS-Modeles sont sur la forge de
l'ecosysteme que le moteur vient de fabriquer. La filiation reste donc verifiable depuis
l'enfant, sans rien demander au parent.
Le genome existe desormais en TROIS exemplaires vivants et independants : eregion, le poste
de l'exploitant, patient 0. C'est le seuil a partir duquel reecrire l'histoire suppose de
convaincre plusieurs temoins — la propriete recherchee, obtenue sans blockchain, comme
effet secondaire de la lignee.
LE CHEMIN A DU SE PLIER A LA POLITIQUE. Le port 3000 n'est pas ouvert depuis le poste, et
le SSH de forge-01 refuse le transfert de ports (durcissement). Versement par paquets git
deposes sur l'hote, puis pousses depuis lui a travers l'API locale — donc par les crochets
de la forge, comme n'importe quel push. Aucune regle assouplie pour la commodite.
LE COMPTE DE SECOURS NE SECOURAIT RIEN. Forgejo exige par defaut un changement de mot de
passe au premier acces et refuse toute requete d'API tant qu'il n'a pas eu lieu. Or ce role
DESACTIVE la connexion locale (SSO d'abord) : aucun chemin n'existait pour ce changement.
Le compte administrateur etait donc inutilisable des sa creation, sur toutes les forges
deployees. `--must-change-password=false` est pose ; le mot de passe vient de la voute et
tourne deja par empreinte.
Cinquieme defaut revele par le meme ecosysteme. Aucun n'etait visible sur une flotte
debout : il fallait en construire une AUTRE, et s'en servir.
make verifier 41 OK, 0 echec, 0 saute ; lint vert.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 03:09:34 -04:00
|
|
|
# au premier acces, et refuse TOUTE requete d'API tant qu'il n'a pas eu lieu :
|
|
|
|
|
# « You must change your password ». Or ce role desactive la connexion locale
|
|
|
|
|
# (`serveur_forgejo_connexion_locale: false`, SSO d'abord) — il n'existait donc aucun
|
|
|
|
|
# chemin pour effectuer ce changement. Le compte de secours ne secourait rien.
|
|
|
|
|
#
|
|
|
|
|
# Le mot de passe vient de la voute et tourne par empreinte (voir plus bas) : exiger un
|
|
|
|
|
# changement manuel en plus ferait diverger la voute de la realite, ce que ce role
|
|
|
|
|
# s'emploie justement a empecher.
|
2026-06-24 20:17:46 -04:00
|
|
|
ansible.builtin.shell:
|
|
|
|
|
cmd: >-
|
|
|
|
|
{{ serveur_forgejo_binaire }} admin user create
|
|
|
|
|
--admin --username {{ serveur_forgejo_admin_user }}
|
|
|
|
|
--email {{ serveur_forgejo_admin_email }}
|
|
|
|
|
--password '{{ serveur_forgejo_admin_password }}'
|
genome : les cinq depots vivent sur la forge de patient 0
La boucle est fermee. Set-OPS-public (avec son etiquette SIGNEE v2026.08.21),
SITE-Chezlepro, OPS-Chezlepro, OPS-Patient0 et Set-OPS-Modeles sont sur la forge de
l'ecosysteme que le moteur vient de fabriquer. La filiation reste donc verifiable depuis
l'enfant, sans rien demander au parent.
Le genome existe desormais en TROIS exemplaires vivants et independants : eregion, le poste
de l'exploitant, patient 0. C'est le seuil a partir duquel reecrire l'histoire suppose de
convaincre plusieurs temoins — la propriete recherchee, obtenue sans blockchain, comme
effet secondaire de la lignee.
LE CHEMIN A DU SE PLIER A LA POLITIQUE. Le port 3000 n'est pas ouvert depuis le poste, et
le SSH de forge-01 refuse le transfert de ports (durcissement). Versement par paquets git
deposes sur l'hote, puis pousses depuis lui a travers l'API locale — donc par les crochets
de la forge, comme n'importe quel push. Aucune regle assouplie pour la commodite.
LE COMPTE DE SECOURS NE SECOURAIT RIEN. Forgejo exige par defaut un changement de mot de
passe au premier acces et refuse toute requete d'API tant qu'il n'a pas eu lieu. Or ce role
DESACTIVE la connexion locale (SSO d'abord) : aucun chemin n'existait pour ce changement.
Le compte administrateur etait donc inutilisable des sa creation, sur toutes les forges
deployees. `--must-change-password=false` est pose ; le mot de passe vient de la voute et
tourne deja par empreinte.
Cinquieme defaut revele par le meme ecosysteme. Aucun n'etait visible sur une flotte
debout : il fallait en construire une AUTRE, et s'en servir.
make verifier 41 OK, 0 echec, 0 saute ; lint vert.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 03:09:34 -04:00
|
|
|
--must-change-password=false
|
2026-06-24 20:17:46 -04:00
|
|
|
--config {{ serveur_forgejo_config }}
|
|
|
|
|
&& touch {{ serveur_forgejo_data }}/.admin-created
|
|
|
|
|
creates: "{{ serveur_forgejo_data }}/.admin-created"
|
|
|
|
|
become: true
|
|
|
|
|
become_user: "{{ serveur_forgejo_utilisateur }}"
|
|
|
|
|
environment:
|
|
|
|
|
GITEA_WORK_DIR: "{{ serveur_forgejo_data }}"
|
|
|
|
|
no_log: true
|
2026-07-03 15:52:38 -04:00
|
|
|
|
forgejo : verifier l'etat du compte, ne pas faire confiance au drapeau
Toute l'API rendait 403 — ni 401, ni message de droits : jeton valide, identite reconnue,
requete rejetee. La cause etait `must-change-password` sur le compte d'administration.
Le role passait DEJA `--must-change-password=false`, corrige le 2026-08-23 sur la premiere
forge de patient 0. Forgejo 16 a ignore l'option : le compte de la forge du SITE est ne
avec le drapeau pose malgre elle. La correction d'il y a deux jours ne protegeait plus
rien, et rien ne le disait.
Le role ne demande donc plus a la creation de bien se comporter : il CONSTATE l'etat voulu
et le retablit, par une tache idempotente sans effet quand la creation a tenu parole.
Le genome vit desormais sur la forge du site : six depots, 606 commits, chaque tete
confrontee entre le poste et la forge — identique. L'ancienne forge reste comme second
remote : « une famille, pas un maitre ».
42 preuves vertes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-25 13:33:10 -04:00
|
|
|
# ON VERIFIE L'ETAT, ON NE FAIT PAS CONFIANCE AU DRAPEAU (2026-08-25).
|
|
|
|
|
#
|
|
|
|
|
# La creation passe deja `--must-change-password=false` — corrige le 2026-08-23, sur la
|
2026-09-27 21:53:36 -04:00
|
|
|
# premiere forge d'un ecosysteme. **Forgejo 16 l'a ignore** : le compte de la forge du SITE
|
forgejo : verifier l'etat du compte, ne pas faire confiance au drapeau
Toute l'API rendait 403 — ni 401, ni message de droits : jeton valide, identite reconnue,
requete rejetee. La cause etait `must-change-password` sur le compte d'administration.
Le role passait DEJA `--must-change-password=false`, corrige le 2026-08-23 sur la premiere
forge de patient 0. Forgejo 16 a ignore l'option : le compte de la forge du SITE est ne
avec le drapeau pose malgre elle. La correction d'il y a deux jours ne protegeait plus
rien, et rien ne le disait.
Le role ne demande donc plus a la creation de bien se comporter : il CONSTATE l'etat voulu
et le retablit, par une tache idempotente sans effet quand la creation a tenu parole.
Le genome vit desormais sur la forge du site : six depots, 606 commits, chaque tete
confrontee entre le poste et la forge — identique. L'ancienne forge reste comme second
remote : « une famille, pas un maitre ».
42 preuves vertes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-25 13:33:10 -04:00
|
|
|
# est ne avec le drapeau POSE malgre l'option.
|
|
|
|
|
#
|
|
|
|
|
# La panne qui en resulte n'accuse rien de juste : toute requete d'API rend **403**, pas
|
|
|
|
|
# 401. Le jeton est valide, l'identite reconnue, la requete rejetee quand meme — on
|
|
|
|
|
# cherche un scope, un droit, une politique, et la cause est un drapeau sur le compte.
|
|
|
|
|
#
|
|
|
|
|
# D'ou cette tache : elle ne demande pas a la creation de bien se comporter, elle CONSTATE
|
|
|
|
|
# l'etat voulu et le retablit. Idempotente, et sans effet quand la creation a tenu parole.
|
|
|
|
|
- name: Le compte d'administration ne doit exiger aucun changement de mot de passe
|
|
|
|
|
ansible.builtin.command:
|
|
|
|
|
cmd: >-
|
|
|
|
|
{{ serveur_forgejo_binaire }} admin user must-change-password --unset
|
|
|
|
|
{{ serveur_forgejo_admin_user }}
|
|
|
|
|
--config {{ serveur_forgejo_config }}
|
|
|
|
|
become: true
|
|
|
|
|
become_user: "{{ serveur_forgejo_utilisateur }}"
|
|
|
|
|
environment:
|
|
|
|
|
FORGEJO_WORK_DIR: "{{ serveur_forgejo_data }}"
|
|
|
|
|
register: forgejo_mcp
|
|
|
|
|
changed_when: "'Updated 1 users' in (forgejo_mcp.stdout | default(''))"
|
|
|
|
|
failed_when:
|
|
|
|
|
- forgejo_mcp.rc != 0
|
|
|
|
|
- "'not found' not in (forgejo_mcp.stderr | default(''))"
|
|
|
|
|
|
2026-07-03 15:52:38 -04:00
|
|
|
- name: Configurer la source OAuth2 SSO (Keycloak, idempotent)
|
|
|
|
|
ansible.builtin.shell:
|
|
|
|
|
executable: /bin/bash
|
|
|
|
|
cmd: |
|
|
|
|
|
set -euo pipefail
|
|
|
|
|
FJ="{{ serveur_forgejo_binaire }} --config {{ serveur_forgejo_config }}"
|
2026-08-07 14:49:28 -04:00
|
|
|
# Les reglages de GROUPE sont RECONCILIES, pas seulement poses a la creation :
|
|
|
|
|
# `add-oauth` une fois puis plus rien laissait un cablage perime vivre
|
|
|
|
|
# indefiniment — c'est ce qui est arrive a la federation LDAP de Keycloak, qui
|
|
|
|
|
# a pointe un hote inexistant pendant des semaines (2026-08-07).
|
|
|
|
|
OPTS_GROUPE=""
|
|
|
|
|
{% if serveur_forgejo_oidc_groupe_admin | length > 0 %}
|
|
|
|
|
OPTS_GROUPE="--group-claim-name {{ serveur_forgejo_oidc_groupe_claim }} --admin-group {{ serveur_forgejo_oidc_groupe_admin }}"
|
|
|
|
|
{% endif %}
|
|
|
|
|
ID=$($FJ admin auth list 2>/dev/null \
|
|
|
|
|
| awk -v n="{{ serveur_forgejo_oidc_nom }}" '$2 == n {print $1}' | head -1)
|
|
|
|
|
if [ -z "$ID" ]; then
|
2026-07-03 15:52:38 -04:00
|
|
|
$FJ admin auth add-oauth \
|
|
|
|
|
--name "{{ serveur_forgejo_oidc_nom }}" \
|
|
|
|
|
--provider openidConnect \
|
|
|
|
|
--key "{{ serveur_forgejo_oidc_client_id }}" \
|
|
|
|
|
--secret "$OIDC_SECRET" \
|
2026-08-07 14:49:28 -04:00
|
|
|
--auto-discover-url "{{ serveur_forgejo_oidc_discovery }}" \
|
|
|
|
|
$OPTS_GROUPE >/dev/null
|
2026-07-03 15:52:38 -04:00
|
|
|
echo SETOPS_CHANGED
|
2026-08-07 14:49:28 -04:00
|
|
|
else
|
|
|
|
|
# `update-oauth` est idempotent cote Forgejo : il reecrit les memes valeurs
|
|
|
|
|
# sans effet de bord. On ne peut pas comparer avant/apres (la CLI n'expose
|
|
|
|
|
# pas le detail d'une source), donc on ne signale PAS `changed`.
|
2026-08-07 22:20:11 -04:00
|
|
|
# `--secret` fait partie de la reconciliation : sans lui, faire tourner
|
|
|
|
|
# `vault_forgejo_oidc` laissait Forgejo sur l'ancienne valeur.
|
2026-08-07 14:49:28 -04:00
|
|
|
$FJ admin auth update-oauth --id "$ID" \
|
|
|
|
|
--auto-discover-url "{{ serveur_forgejo_oidc_discovery }}" \
|
2026-08-07 22:20:11 -04:00
|
|
|
--secret "$OIDC_SECRET" \
|
2026-08-07 14:49:28 -04:00
|
|
|
$OPTS_GROUPE >/dev/null
|
|
|
|
|
echo SETOPS_OK
|
2026-07-03 15:52:38 -04:00
|
|
|
fi
|
|
|
|
|
environment:
|
|
|
|
|
OIDC_SECRET: "{{ serveur_forgejo_oidc_client_secret }}"
|
|
|
|
|
GITEA_WORK_DIR: "{{ serveur_forgejo_data }}"
|
|
|
|
|
become: true
|
|
|
|
|
become_user: "{{ serveur_forgejo_utilisateur }}"
|
|
|
|
|
register: serveur_forgejo_oauth
|
|
|
|
|
changed_when: "'SETOPS_CHANGED' in serveur_forgejo_oauth.stdout"
|
|
|
|
|
no_log: true
|
|
|
|
|
when:
|
|
|
|
|
- serveur_forgejo_oidc_actif | bool
|
|
|
|
|
- not ansible_check_mode
|
2026-08-07 21:10:47 -04:00
|
|
|
|
|
|
|
|
# --- ROTATION DU COMPTE DE SECOURS -------------------------------------------
|
|
|
|
|
# `admin user create` porte `creates: .admin-created` : il ne tourne qu'UNE fois.
|
|
|
|
|
# Changer la voute ne changeait donc rien, et la voute se mettait a mentir. Meme
|
|
|
|
|
# raisonnement que pour Grafana — idempotence par EMPREINTE du secret applique.
|
|
|
|
|
- name: Empreinte du mot de passe admin en place
|
|
|
|
|
ansible.builtin.slurp:
|
|
|
|
|
src: "{{ serveur_forgejo_marqueur_admin }}"
|
|
|
|
|
register: serveur_forgejo_marque
|
|
|
|
|
failed_when: false
|
|
|
|
|
changed_when: false
|
|
|
|
|
no_log: true
|
|
|
|
|
|
|
|
|
|
- name: Appliquer le mot de passe du compte de secours (rotation)
|
|
|
|
|
ansible.builtin.command:
|
|
|
|
|
argv:
|
|
|
|
|
- "{{ serveur_forgejo_binaire }}"
|
|
|
|
|
- "--config"
|
|
|
|
|
- "{{ serveur_forgejo_config }}"
|
|
|
|
|
- admin
|
|
|
|
|
- user
|
|
|
|
|
- change-password
|
|
|
|
|
- "--username"
|
|
|
|
|
- "{{ serveur_forgejo_admin_user }}"
|
|
|
|
|
- "--password"
|
|
|
|
|
- "{{ serveur_forgejo_admin_password }}"
|
|
|
|
|
environment:
|
|
|
|
|
GITEA_WORK_DIR: "{{ serveur_forgejo_data }}"
|
|
|
|
|
become: true
|
|
|
|
|
become_user: "{{ serveur_forgejo_utilisateur }}"
|
|
|
|
|
changed_when: true
|
|
|
|
|
no_log: true
|
|
|
|
|
when: >-
|
|
|
|
|
(serveur_forgejo_marque.content | default('') | b64decode | trim)
|
|
|
|
|
!= (serveur_forgejo_admin_password | hash('sha256'))
|
|
|
|
|
|
|
|
|
|
- name: Retenir l'empreinte appliquee
|
|
|
|
|
ansible.builtin.copy:
|
|
|
|
|
content: "{{ serveur_forgejo_admin_password | hash('sha256') }}\n"
|
|
|
|
|
dest: "{{ serveur_forgejo_marqueur_admin }}"
|
|
|
|
|
owner: root
|
|
|
|
|
group: root
|
|
|
|
|
mode: "0600"
|
|
|
|
|
no_log: true
|
sondes : les six premieres, et le patron qui les rend eprouvables
Ajout de meta/supervision.yml a six roles, chacun deposant sa propre sonde
selon le contrat des greffons Nagios.
DEUX PRINCIPES POSES AU DOCUMENT DE CONCEPTION, parce que la premiere
sonde les a imposes :
1. UNE SONDE DOIT POUVOIR ETRE MISE EN DEFAUT PAR PARAMETRE. Cible et
seuils sont des variables du role : on la prouve rouge avec un port ferme
ou un seuil impossible, sur une machine reelle, sans rien casser, et
aussi souvent qu on veut. Une sonde qu on ne peut prouver qu en cassant un
service ne sera prouvee qu une fois.
2. LA SONDE VIT LA OU VIT LA VERITE. « Ce noeud est-il collecte ? » est
une sonde de serveur_prometheus, pas de client_metrique : une seule y voit
les N noeuds, et surtout elle voit le cas SILENCIEUX — celui qui a cesse d
etre collecte ne peut pas s en plaindre.
LES SIX : cache-apt (artefacts, repond + place), resolution (resolveur,
zone interne ET Internet — deux chemins distincts), forge (forgejo, son
propre /api/healthz), collecte (prometheus, 15/15 cibles), tableaux
(grafana, base ok), ingestion (loki, PRET a ingerer, pas seulement en
ecoute).
TROIS FOIS J AI ECRIT LA SONDE AVANT DE MESURER, ET TROIS FOIS ELLE A EU
TORT. La forge : port 443 et chemin des depots INVENTES — elle ecoute en
3000 derriere l edge et n a legitimement aucun depot. Loki : j ai conclu
« panne persistante » sur deux lectures prises a quelques secondes d
intervalle, juste apres un redemarrage ; l anneau etait ACTIVE et la
reponse est passee a ready moins d une minute plus tard. Le delai de
stabilisation est desormais un AVERTISSEMENT nomme, pas une panne.
On demande au service ce qu il pense de lui-meme quand il sait le dire
(healthz, /ready, /api/health) plutot que d inventer un critere de l
exterieur.
make prouver : CONFORME.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-10 02:48:55 -04:00
|
|
|
|
|
|
|
|
# --- Sonde de supervision (docs/supervision-conception.md) --------------------------
|
|
|
|
|
# Le role qui possede la verite depose sa propre sonde ; le porteur (`client_sante`) la
|
|
|
|
|
# fait tourner et pousse le verdict, sans savoir ce qu'elle mesure.
|
|
|
|
|
- name: Assurer le repertoire des sondes de supervision
|
|
|
|
|
ansible.builtin.file:
|
|
|
|
|
path: /usr/local/lib/setops/sondes
|
|
|
|
|
state: directory
|
|
|
|
|
owner: root
|
|
|
|
|
group: root
|
|
|
|
|
mode: "0755"
|
|
|
|
|
|
|
|
|
|
- name: Deposer la sonde « forge »
|
|
|
|
|
ansible.builtin.template:
|
|
|
|
|
src: sonde-forge.sh.j2
|
|
|
|
|
dest: /usr/local/lib/setops/sondes/forge.sh
|
|
|
|
|
owner: root
|
|
|
|
|
group: root
|
|
|
|
|
mode: "0750"
|