2026-06-24 20:17:46 -04:00
|
|
|
---
|
|
|
|
|
# Version Forgejo : verifier/ajuster sur https://forgejo.org/download/
|
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
|
|
|
serveur_forgejo_version: "16.0.2"
|
2026-06-24 20:17:46 -04:00
|
|
|
serveur_forgejo_url: >-
|
|
|
|
|
https://codeberg.org/forgejo/forgejo/releases/download/v{{ serveur_forgejo_version }}/forgejo-{{ serveur_forgejo_version }}-linux-amd64
|
|
|
|
|
|
|
|
|
|
serveur_forgejo_binaire: "/usr/local/bin/forgejo"
|
|
|
|
|
serveur_forgejo_utilisateur: "git"
|
|
|
|
|
serveur_forgejo_data: "/var/lib/forgejo"
|
|
|
|
|
serveur_forgejo_config_dir: "/etc/forgejo"
|
|
|
|
|
serveur_forgejo_config: "/etc/forgejo/app.ini"
|
|
|
|
|
serveur_forgejo_service: "forgejo"
|
|
|
|
|
|
|
|
|
|
# Publication (derriere serveur_nginx, TLS a l'edge).
|
|
|
|
|
serveur_forgejo_hostname: "forge.{{ domaine_interne }}"
|
2026-07-04 15:47:39 -04:00
|
|
|
|
|
|
|
|
# --- Identité visuelle (branding, léger). serveur_forgejo_branding=true déploie le
|
|
|
|
|
# dossier custom/ (logo, favicon, accent aurore CSS, page d'accueil brandée).
|
|
|
|
|
serveur_forgejo_app_name: "Forgejo"
|
|
|
|
|
serveur_forgejo_theme: "forgejo-auto"
|
|
|
|
|
serveur_forgejo_meta_description: "Forge git souveraine."
|
|
|
|
|
serveur_forgejo_branding: false
|
2026-07-03 15:52:38 -04:00
|
|
|
# Adresse d'ecoute : 0.0.0.0 car l'edge nginx est sur un AUTRE hote (le distant doit
|
|
|
|
|
# joindre le backend). A restreindre par pare-feu (nftables) au reseau interne / a l'edge.
|
|
|
|
|
serveur_forgejo_http_addr: "0.0.0.0"
|
2026-06-24 20:17:46 -04:00
|
|
|
serveur_forgejo_http_port: 3000
|
|
|
|
|
|
site : un SITE a bien un plan — et huit defauts que lui seul pouvait reveler
J'ai repete toute la journee qu'un SITE n'est pas un plan. C'etait faux : j'en
reconstruisais un morceau par morceau dans underlay.yml sans le nommer. Ce qui est vrai,
c'est qu'un site ne DERIVE pas — il declare ses adresses parce qu'il EST le terrain — et
ne passe donc pas par `instancier`. Mais ne pas deriver n'est pas ne pas avoir de plan.
SITE-Chezlepro/plan/{10-intrants,serveurs,applications}.yml ; underlay.yml ne garde que
la fabric. Ce qui est MESURE d'un cote, ce qui est VOULU de l'autre. Les groupes viennent
du registre des applications, les gardes ont suivi le plan (4 controles negatifs).
Huit defauts, tous invisibles chez un tenant parce qu'il a toujours tout :
- client_pki codait `infra-pki-01` EN DUR — vrai par coincidence de nomenclature ;
- aucun moyen pour un service non-root de lire la cle (Forgejo tourne en `git`) ;
- le certificat, PUBLIC par nature, restait en 0600 ;
- l'unite Forgejo n'avait pas d'ExecReload : un cert renouvele aurait ete servi perime ;
- le role ne savait pas servir TLS lui-meme (il y avait toujours un edge) ;
- le cert ne couvrait pas le nom de SERVICE, faute d'`expose:` ;
- les registres se chargeaient en tout-ou-rien : sans domaines.yml, plancher vide ;
- le flux declarait 3000 en dur.
Le message accusait presque toujours autre chose : le DNS quand c'etait un nom faux, une
permission de fichier quand c'etait un port privilegie, rien du tout quand le plancher
s'ecrivait vide.
ROOT_URL est gravee dans les URL de clonage : la forge sert desormais sur 443, avec
CAP_NET_BIND_SERVICE, et son URL n'a plus de port.
Verifie depuis le reseau : Verify return code 0, https://forge.genese.internal/ -> 200.
42 preuves vertes, flux coherents (34 roles, 92 flux).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-25 13:15:34 -04:00
|
|
|
# --- SERVIR TLS SOI-MEME, QUAND IL N'Y A PAS D'EDGE DEVANT (2026-08-25) --------
|
|
|
|
|
#
|
|
|
|
|
# Le patron habituel est un nginx d'edge qui termine le TLS et parle en clair a la forge
|
|
|
|
|
# sur la boucle locale. Le gabarit posait donc `ROOT_URL = https://…` sans jamais
|
|
|
|
|
# configurer de certificat : c'etait vrai PARCE QUE quelqu'un d'autre s'en chargeait.
|
|
|
|
|
#
|
|
|
|
|
# La forge du SITE n'a pas d'edge devant elle — le site n'en a pas — et elle porte LE
|
|
|
|
|
# GENOME. Le code qui fabrique tous les ecosystemes voyageait donc en clair sur le
|
|
|
|
|
# reseau, alors que l'AC du site tourne a trois adresses de la.
|
|
|
|
|
#
|
|
|
|
|
# `false` par defaut : chez un tenant, rien ne change, l'edge garde son role. C'est
|
|
|
|
|
# l'ecosysteme sans edge qui doit le demander.
|
|
|
|
|
serveur_forgejo_tls: false
|
|
|
|
|
# Le certificat de la MACHINE, pose par `client_pki` — pas un cert propre a la forge.
|
|
|
|
|
# Une machine, une identite : c'est ce que l'AC a signe, avec ses SAN.
|
|
|
|
|
serveur_forgejo_tls_cert: "/etc/step/certs/{{ ansible_fqdn | default(ansible_hostname) }}.crt"
|
|
|
|
|
serveur_forgejo_tls_cle: "/etc/step/certs/{{ ansible_fqdn | default(ansible_hostname) }}.key"
|
|
|
|
|
|
2026-06-24 20:17:46 -04:00
|
|
|
# Base de donnees : resolue depuis le registre par le groupe consommateur.
|
|
|
|
|
serveur_forgejo_groupe: "serveur_forgejo"
|
2026-07-05 00:40:57 -04:00
|
|
|
serveur_forgejo_db_host: "" # dérivé (FQDN) par resoudre_base au déploiement
|
2026-06-24 20:17:46 -04:00
|
|
|
|
|
|
|
|
# Relais courriel.
|
|
|
|
|
serveur_forgejo_smtp: "infra-mail-01.{{ domaine_interne }}"
|
|
|
|
|
|
|
|
|
|
# Secrets OBLIGATOIRES (Ansible Vault).
|
2026-07-01 21:29:18 -04:00
|
|
|
serveur_forgejo_secret_key: "{{ vault_forgejo_secret_key | default('') }}" # rempli depuis la voute (vault_forgejo_secret_key)
|
|
|
|
|
serveur_forgejo_internal_token: "{{ vault_forgejo_internal_token | default('') }}" # rempli depuis la voute (vault_forgejo_internal_token)
|
2026-06-24 20:17:46 -04:00
|
|
|
serveur_forgejo_admin_user: "forgejo-admin"
|
|
|
|
|
serveur_forgejo_admin_email: "admin@{{ domaine_interne }}"
|
2026-07-01 21:29:18 -04:00
|
|
|
serveur_forgejo_admin_password: "{{ vault_forgejo_admin | default('') }}" # rempli depuis la voute (vault_forgejo_admin)
|
2026-07-03 15:52:38 -04:00
|
|
|
|
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
|
|
|
# --- Connexion locale (accès de secours) ---
|
|
|
|
|
# `false` = le formulaire identifiant/mot de passe n'est PAS proposé au repos ; le SSO
|
|
|
|
|
# Keycloak est le seul chemin annoncé. Le compte local continue d'exister : on l'atteint
|
|
|
|
|
# par `sudo` sur l'hôte (voir docs/authentification.md), qui est le mécanisme de secours
|
|
|
|
|
# retenu. Une porte de connexion ouverte en permanence contournerait la politique de mot
|
|
|
|
|
# de passe, le MFA et surtout la révocation centrale — désactiver quelqu'un dans LDAP
|
|
|
|
|
# laisserait le compte local valide, sans que rien ne le signale.
|
|
|
|
|
# Forgejo : `ENABLE_INTERNAL_SIGNIN` n'existe QUE depuis la v10 — verifie sur le
|
|
|
|
|
# suivi amont (issue 7476, close : « This option was added to Forgejo v10 »). Le
|
|
|
|
|
# role epingle 10.0.0, donc le reglage mord. Sur une version anterieure il serait
|
|
|
|
|
# ignore EN SILENCE : c'est le cas ou une garde vaut mieux qu'un commentaire.
|
|
|
|
|
serveur_forgejo_connexion_locale: false
|
|
|
|
|
|
2026-07-07 03:08:09 -04:00
|
|
|
# --- SSO OIDC (Keycloak, realm applicatif) — « Se connecter avec <organisation> » ---
|
2026-07-03 15:52:38 -04:00
|
|
|
# Requiert client_pki (confiance step_ca) + résolution de l'hôte Keycloak (plancher/DNS).
|
|
|
|
|
# Le client OIDC doit exister dans le realm (serveur_keycloak_clients).
|
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
|
|
|
# LE SSO SUIT L'EXISTENCE D'UN FOURNISSEUR D'IDENTITE — il ne se declare pas (2026-08-23).
|
|
|
|
|
#
|
|
|
|
|
# `true` en dur faisait echouer le deploiement de tout ecosysteme SANS Keycloak : la forge
|
|
|
|
|
# tentait de cabler une source OAuth2 vers un fournisseur qui n'existe pas. C'est la
|
|
|
|
|
# quatrieme fois en deux jours que la meme hypothese se paie — le moteur supposait
|
|
|
|
|
# l'ecosysteme COMPLET, apres les intrants (P32), les bases (P35) et les dependances
|
|
|
|
|
# causales.
|
|
|
|
|
#
|
|
|
|
|
# Derive de l'inventaire : un groupe `serveur_keycloak` sans hote, c'est un ecosysteme sans
|
|
|
|
|
# identite federee. Surchargeable pour un IdP externe au plan.
|
|
|
|
|
serveur_forgejo_oidc_actif: "{{ (groups['serveur_keycloak'] | default([])) | length > 0 }}"
|
2026-07-07 03:08:09 -04:00
|
|
|
serveur_forgejo_oidc_nom: "{{ organisation | default('organisation') | lower | replace(' ', '-') }}" # slug du callback : /user/oauth2/<nom>/callback
|
2026-07-03 15:52:38 -04:00
|
|
|
serveur_forgejo_oidc_client_id: "forgejo"
|
|
|
|
|
serveur_forgejo_oidc_client_secret: "{{ vault_forgejo_oidc | default('') }}" # voûte (vault_forgejo_oidc)
|
2026-07-05 00:47:44 -04:00
|
|
|
serveur_forgejo_oidc_realm: "{{ identite_realm | default('chezlepro') }}"
|
2026-08-07 15:33:32 -04:00
|
|
|
# DERIVE de l'exposition declaree au plan (role `resoudre_idp`). La valeur
|
|
|
|
|
# ci-dessous n'est qu'un REPLI : `keycloak.<domaine>` n'est publie nulle part.
|
|
|
|
|
serveur_forgejo_oidc_repli: >-
|
|
|
|
|
https://keycloak.{{ domaine_interne }}/realms/{{ serveur_forgejo_oidc_realm }}/.well-known/openid-configuration
|
|
|
|
|
serveur_forgejo_oidc_discovery: >-
|
|
|
|
|
{{ resoudre_idp_discovery | default(serveur_forgejo_oidc_repli) }}
|
2026-07-04 18:53:31 -04:00
|
|
|
|
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
|
|
|
# --- QUELLE BASE DE DONNEES ---------------------------------------------------
|
|
|
|
|
#
|
|
|
|
|
# `postgres` (defaut) : la base vit dans le registre du plan, sur un serveur dedie.
|
|
|
|
|
# `sqlite` : un FICHIER dans les donnees de Forgejo, aucun serveur, aucun
|
|
|
|
|
# secret de base, aucune VM. C'est le defaut documente de Forgejo
|
|
|
|
|
# pour une petite instance, et il tient tres bien quelques dizaines
|
|
|
|
|
# d'utilisateurs et des miroirs.
|
|
|
|
|
#
|
|
|
|
|
# POURQUOI CE CHOIX EXISTE (2026-08-22). Une offre `forge` pour un petit organisme
|
|
|
|
|
# exigeait une VM PostgreSQL entiere — un serveur, une zone, un secret, une sauvegarde —
|
|
|
|
|
# pour une base que trois personnes sollicitent. Le premier ecosysteme a en avoir profite
|
|
|
|
|
# est patient 0, qui porte le genome : moins de surface sur la machine dont tout descend.
|
|
|
|
|
#
|
|
|
|
|
# CE QUE `sqlite` CHANGE AILLEURS : rien a la sauvegarde — le job `serveur_forgejo` de
|
|
|
|
|
# `client_backup` emporte deja `serveur_forgejo_data`, ou le fichier se trouve. Et rien
|
|
|
|
|
# au registre : aucune entree de base n'est attendue (P35 le sait).
|
|
|
|
|
serveur_forgejo_bd: "postgres"
|
|
|
|
|
serveur_forgejo_db_chemin: "{{ serveur_forgejo_data }}/forgejo.db"
|
|
|
|
|
|
2026-07-04 18:53:31 -04:00
|
|
|
# TLS vers PostgreSQL (zero-confiance). 'disable' = compat ; 'verify-full' = chiffre + verifie
|
|
|
|
|
# le cert serveur contre le root_ca step-ca (via PGSSLROOTCERT dans l'unite systemd).
|
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
|
|
|
# Sans objet en `sqlite` : il n'y a pas de connexion reseau a chiffrer.
|
TLS des bases : le consommateur suit son serveur, il ne le devine plus
La supervision du SITE etait morte depuis 11:10 et rien ne le disait. icingadb
refuse par pg_hba — hostssl impose cote serveur, connexion en clair cote client.
icinga2 tournait, redis tournait, les sondes poussaient, et rien n atteignait la
base : les verdicts se calculaient dans le vide.
La cause est une seconde liste tenue a la main. tls_force allume hostssl ; chaque
consommateur avait SON interrupteur a allumer dans les group_vars. Chezlepro
avait les trois, le site avait le premier. serveur_forgejo disait pire que rien :
sslmode disable ecrit en dur, le contraire de ce que le serveur imposait.
resoudre_base expose resoudre_base_db_tls_force, lu dans les hostvars de la
machine qui PORTE la base. Les trois interrupteurs en derivent. Un serveur qui
ne declare rien ne force rien : on ne casse pas un ecosysteme qui n a pas
bascule.
P78 refuse une valeur ecrite chez un consommateur, et nomme les deux roles sans
reglage TLS plutot que de rendre un vert muet sur eux.
Apres : icingadb active, TLSv1.3 vu par PostgreSQL, 16 hotes et 88 services en
base. Les cinq sondes des marqueurs du site, INCONNU faute de deploiement,
rapportent leur phrase.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-14 18:42:21 -04:00
|
|
|
# DÉRIVÉ DE CE QUE SERT LE SERVEUR, plus posé à la main. Voir `resoudre_base`.
|
|
|
|
|
# `disable` restait écrit en dur ici alors que le serveur pouvait exiger TLS : le
|
|
|
|
|
# consommateur affirmait le contraire de ce que le serveur imposait.
|
|
|
|
|
serveur_forgejo_db_sslmode: >-
|
|
|
|
|
{{ 'verify-full' if (resoudre_base_db_tls_force | default(false)) else 'disable' }}
|
2026-07-04 18:53:31 -04:00
|
|
|
serveur_forgejo_db_sslrootcert: "/etc/step/certs/root_ca.crt"
|
2026-08-07 14:49:28 -04:00
|
|
|
|
|
|
|
|
# --- Habilitation par groupe (D-66) -------------------------------------------
|
|
|
|
|
# Forgejo lit un claim de groupes dans le jeton OIDC et accorde l'administration
|
|
|
|
|
# aux membres d'un groupe nomme. Sans ces reglages, TOUT utilisateur authentifie
|
|
|
|
|
# obtient le niveau par defaut et l'administration reste au compte local de
|
|
|
|
|
# secours — ce que `meta/acces.yml` signalait comme `porte_par: aucun`.
|
|
|
|
|
#
|
|
|
|
|
# Le claim `groups` est celui que Keycloak emet pour les groupes projetes depuis
|
|
|
|
|
# LDAP (group-ldap-mapper). Voir docs/autorisation.md.
|
|
|
|
|
serveur_forgejo_oidc_groupe_claim: "groups"
|
|
|
|
|
serveur_forgejo_oidc_groupe_admin: "sysadmin"
|
2026-08-07 21:10:47 -04:00
|
|
|
|
|
|
|
|
# Empreinte du mot de passe admin APPLIQUE (rotation). Voir tasks/main.yml.
|
|
|
|
|
serveur_forgejo_marqueur_admin: "/etc/forgejo/.setops-admin-sha256"
|
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
|
|
|
|
|
|
|
|
# Cache d'artefacts DU CONTROLEUR (pas de la cible). Le controleur telecharge une fois,
|
|
|
|
|
# puis pousse par SSH : aucun flux nouveau, et l'artefact devient deployable hors ligne.
|
|
|
|
|
# Surchargeable par `setops_cache_artefacts` pour partager un cache commun.
|
|
|
|
|
serveur_forgejo_cache_local: "{{ setops_cache_artefacts | default(lookup('env', 'HOME') + '/.cache/setops') }}"
|
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
|
|
|
|
|
|
|
|
# SIGNATURE DU BINAIRE — Forgejo signe ses releases (PGP detachee, `.asc`) ET publie une
|
|
|
|
|
# somme sha256. Les deux ont ete verifiees avant epinglage.
|
|
|
|
|
#
|
|
|
|
|
# ON EPINGLE LA CLE PRIMAIRE, PAS LA SOUS-CLE QUI SIGNE. Forgejo fait tourner ses
|
|
|
|
|
# sous-cles de signature — 0F527CF9... pour la 12.0.0, 3BF4E813... pour la 16.0.2 — sous
|
|
|
|
|
# une primaire stable depuis 2022, et le dit explicitement sur sa page de telechargement
|
|
|
|
|
# (« the GPG key is updated on a regular basis »). Epingler la sous-cle ferait echouer la
|
|
|
|
|
# verification a chaque rotation LEGITIME, et on apprendrait a lever la garde pour
|
|
|
|
|
# avancer. La primaire survit aux rotations et refuse quand meme une cle etrangere.
|
|
|
|
|
#
|
|
|
|
|
# Cette empreinte a une SOURCE INDEPENDANTE du telechargement : forgejo.org/download la
|
|
|
|
|
# publie, et le binaire vient de codeberg.org. C'est ce qui manque a Keycloak.
|
|
|
|
|
serveur_forgejo_signature_empreinte: "EB114F5E6C0DC2BCDD183550A4B61A2DC5923710"
|
|
|
|
|
serveur_forgejo_signature_url: "{{ serveur_forgejo_url }}.asc"
|
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 -----------------------------------------------------------
|
|
|
|
|
# L'ADRESSE VIENT DU ROLE, PAS D'UNE SUPPOSITION : la forge ecoute en clair sur son
|
|
|
|
|
# `http_port` (l'edge fait le TLS devant). Viser 443 en dur, comme la premiere version de
|
|
|
|
|
# la sonde, cassait sur toute forge derriere un edge — c'est-a-dire toutes celles des
|
|
|
|
|
# tenants.
|
frontiere posee, et cinq sondes qui disaient faux
Application de ce que l entree precedente avait prepare : 49 regles creees,
5 retirees. Cibles Prometheus 2/8 -> 8/8, hotes dans Loki 1/7 -> 7/7.
Puis correction de ce que l application a revele. Cinq defauts, tous de la
meme famille : un reglage qui ne suit pas l interrupteur dont il depend.
- la sonde de Loki interrogeait en HTTPS un Loki servant en clair ;
- la sonde de la forge visait http:// sur un port 443 chiffre, puis
validait un certificat emis pour le FQDN en interrogeant 127.0.0.1 ;
- la sonde du runner comparait six depots a UNE branche quand le plan en
declare une par depot. Elle contredisait la declaration qu elle etait
censee verifier : elle n accusait pas la machine, elle s accusait
elle-meme.
Le tenant restait juste dans les cinq cas. C est le site, qui deploie ces
roles autrement, qui les a tous reveles d un coup.
La sonde des journaux, elle, avait deux defauts a la naissance. Elle criait
une perte deja reparee, faute de dire sur QUELLE fenetre - un ecart sans sa
fenetre n est pas une mesure, c est un nombre. Et elle alertait sur la
cicatrice plutot que sur la plaie : le compteur d Alloy est cumulatif, donc
six machines restaient orange pour toujours. Ce qui alerte est desormais la
CROISSANCE. En echange, un cas muet leve maintenant : zero envoi et zero
rejet n est pas la sante, c est un agent qui ne fait rien.
Enfin, le runner ne pouvait plus cloner le genome. Defaut PREEXISTANT,
revele par le redeploiement et non cause par lui - le diff des regles
generees le montre. generer_nftables(site=True) lisait le plan du TENANT :
derive se resolvait donc a 3000, le port que Forgejo ecoute derriere un
edge, alors que le plan du site dit 443 et explique pourquoi. La forge
ouvrait un port que personne n ecoute et laissait 443 ferme a toute la
flotte.
Mesure finale : Icinga 51/51, Prometheus 8/8, Loki 7/7, prouver 64 OK,
lint 0 defaut sur 82 fichiers. Controles negatifs sur des COPIES des
sondes : les quatre rendent CRITICAL.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-10 10:27:12 -04:00
|
|
|
#
|
|
|
|
|
# ET LE SCHEMA SUIT `serveur_forgejo_tls`, comme le port suit `http_port` (2026-09-10).
|
|
|
|
|
# La ligne corrigeait le port et laissait `http` en dur : au SITE, ou la forge sert son
|
|
|
|
|
# propre TLS sur 443, la sonde envoyait du clair a un port chiffre et recevait
|
|
|
|
|
# « Client sent an HTTP request to an HTTPS server » — un CRITICAL sur une forge qui
|
|
|
|
|
# servait parfaitement le genome au meme instant.
|
|
|
|
|
#
|
|
|
|
|
# Troisieme occurrence du meme defaut dans la meme journee (Grafana, Loki, ici) : un
|
|
|
|
|
# parametre corrige a moitie, dont la moitie restee en dur ne dit rien tant que le
|
|
|
|
|
# deploiement ne change pas de camp.
|
|
|
|
|
serveur_forgejo_sonde_schema: "{{ 'https' if serveur_forgejo_tls | bool else 'http' }}"
|
|
|
|
|
serveur_forgejo_sonde_url: >-
|
|
|
|
|
{{ serveur_forgejo_sonde_schema }}://127.0.0.1:{{ serveur_forgejo_http_port }}
|