Arbitrage rendu : le courrier local est route par uid, plus par l'attribut
mail. Dovecot le faisait DEJA (mail_home = /var/vmail/%{user | username}) ;
les deux moities ne s'accordaient que par coincidence, tant que mail valait
uid@<domaine_interne>. Cout assume : l'adresse interne est derivee et ne se
choisit plus ; en echange mail redevient libre de porter la vraie adresse de
la personne.
Puis la preuve de bout en bout a revele bien pire : toute livraison interne
etait DIFFEREE.
SSL_connect error to infra-mail-01:24: Connection timed out
status=deferred (Cannot start TLS: handshake failure)
Postfix etait durci (lmtp_tls_security_level = verify), le port LMTP de
Dovecot ecoutait en clair — son ssl = required global ne concerne que les
services de connexion. Les deux cotes d'un meme flux avaient ete traites
separement. Corrige et accorde : ssl = yes sur l'inet_listener (TLS implicite)
et lmtp_tls_wrappermode = yes cote client ; l'un sans l'autre ne marche pas.
Livraison prouvee : status=sent (250 ... Saved), message dans
/var/vmail/sysadmin/Maildir/.INBOX/new/.
Le devis disait CONFORME pendant ce temps : il verifiait la resolution et les
dialectes, jamais si le courrier BOUGE. Un devis qui ne regarde que les
reglages ne dit pas si le service rend son service. Il releve desormais la
file d'attente et ses raisons ; test negatif : la panne est nommee.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
PostgreSQL — rend visibles deux defauts deja vecus ici : un reseau ECRIT dans
pg_hba au lieu d'etre derive, et une ligne host en clair la ou il faut hostssl
(verrou qui saute sans bruit, les clients verify-full continuant de marcher).
Interroge pg_settings, jamais le fichier : un grep de postgresql.conf annonce
ssl_cert_file=snakeoil alors que le serveur sert le certificat de l'AC — la
valeur vient d'un conf.d que le grep ne voyait pas. L'instrument etait
incomplet, pas la configuration.
Courriel — chaque maillon interroge la ou il dit la verite : postmap -q pour
la resolution LDAP de Postfix, doveadm user pour celle de Dovecot (le maillon
exact ou la livraison avait bloque), vraies conversations SMTP/IMAP. Verifie
aussi qu'une adresse INEXISTANTE ne resout pas — sinon la boite est un
fourre-tout et le devis ne mesure plus rien.
Trouve immediatement une divergence reelle : Dovecot connait la boite de
sysadmin@chezlepro.internal, Postfix ne sait pas y router (query_filter
(mail=%s), et l'attribut mail porte sysadmin@chezlepro.ca). Collision de
roles : une identite ne porte qu'une adresse mail et on lui en demande deux —
notification joignable hors du systeme, et cle de routage local. Arbitrage a
rendre avant correction.
Tests negatifs : PostgreSQL 3 ecarts nommes, code 1. Une variable morte
trouvee dans une branche que le cas nominal n'emprunte jamais.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Troisieme devis de service. Chaque expose: du plan repond-il, et si non, ou
ca casse.
- requete HTTPS complete avec la racine de l'AC, jamais un connect() : a
travers l'OPNsense (anti-spoofing) toute connexion TCP reussit, et en TLS
le silence apres connect() ne distingue pas un service sain d'un trou.
- deux points de vue : depuis l'edge (edge + dorsal) et depuis le poste
(DNS + frontiere + edge + dorsal). Leur difference diagnostique.
- un code n'est pas un verdict : mon premier comparateur laissait passer un
502 des deux cotes. Trouve par le test negatif, pas par la relecture.
Etat : les 6 expositions repondent des deux cotes. Test negatif (frontiere
qui bloque + dorsal tombe) : 2 ecarts nommes distinctement, code 1.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Deuxieme application du patron devis/applicateur aux services. Trouve a la
premiere execution : sur infra-pki-01 — l'autorite elle-meme — le certificat
etait expire depuis plus de 8 h et le renouvellement echouait toutes les 14
minutes sur « 'step ca renew' requires the '--ca-url' flag ». Rien ne le
signalait.
Cause : sur l'hote de l'AC, /etc/step est le STEPPATH du SERVEUR, pas un
amorcage client — pas de defaults.json, et l'unite de renouvellement en
dependait. La lecon etait deja ecrite dans le commentaire de la tache
d'emission (« l'autorite ne bootstrape pas »), jamais reportee sur l'unite.
Le role ne pouvait pas non plus se soigner : la re-emission ne regardait que
la FORME (cert absent ou SAN manquant), jamais la validite. client_pki
verifie desormais l'echeance (client_pki_marge_renouvellement).
Ce qu'il a fallu desapprendre : les certificats vivent 24 h et se renouvellent
toutes les ~14 min ; « empreinte servie != empreinte disque » est l'etat
NORMAL. Comparer les empreintes aurait donne un verificateur qui crie en
permanence. Le signal est l'echeance de ce qui est SERVI, plus l'absence de
client_pki_reload_services.
Le devis a d'abord menti, du defaut meme qu'il traque : include_vars au niveau
du play prime sur les group_vars. Et le premier correctif a PARU marcher —
set_fact accepte un dictionnaire entier en argument libre sans erreur et n'en
fait rien. Il faut reimposer cle par cle. Les deux devis sont corriges et le
piege est consigne dans docs/devis-services.md avant d'ecrire le prochain.
Verifie dans les deux sens : CONFORME sur 14 hotes ; sur un releve ou l'on
rejoue une copie perimee en memoire, 2 ecarts et code de sortie 1.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Constat de l'exploitant : « ca fait beaucoup de trucs incoherents qu'on
debusque ensemble ». Il y a une raison mesurable — les 30 preuves de
prouver.py sont STATIQUES (0 appel reseau, 0 ssh, 0 ansible). Elles montrent
que le depot est coherent avec lui-meme ; aucune ne demande au systeme
deploye s'il ressemble a ce que le depot annonce. Les quatre defauts du jour
vivaient tous la.
La classe statique est presque epuisee : recensement des motifs « cree mais
ne reconcilie jamais » -> amorcage_acces (delibere, D-67), serveur_openldap
(corrige le matin), et un seul reste reel (rbac-oidc.yml). Une preuve
statique de plus aurait rapporte une ligne.
Le patron devis/applicateur (D-23/D-24) existait deja pour les quatre
pare-feu, jamais pour les services. make identite-plan l'y porte :
- playbooks/maintenance/devis-identite.yml RELEVE le declare et le reel
- scripts/devis_identite.py COMPARE (le raisonnement n'a rien a faire en
Jinja ; le depot a deja cette forme pour les devis reseau)
- le declare n'est jamais recopie : defauts du role + resolveurs. Un devis
qui redeclare ce qu'il verifie ne verifie rien.
Verifie dans les deux sens : CONFORME sur le systeme reel ; sur un releve ou
les quatre defauts du jour sont rejoues plus deux regressions, 6 divergences
listees et code de sortie 1.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Quatre defauts mesures dans l'integration Keycloak/LDAP, meme famille : une
valeur declaree d'un cote, consommee de l'autre, rien qui verifie la jonction.
1. Aucune regle ne s'appliquait sur le chemin d'un vrai utilisateur. Sonde :
« abcd » refuse par l'operation etendue LDAP, accepte par Keycloak (204),
puis actif pour l'authentification. Keycloak ecrivait userPassword en
direct (ppolicy aveugle) et le realm n'avait aucune passwordPolicy.
2. ldap_entry ne fait que CREER : la politique etait figee a sa creation. Le
depot disait pwdMustChange TRUE, le serveur FALSE — une reconstruction
from-zero aurait ressuscite la boucle du 2026-08-07. ldap_attrs state=exact
reconcilie la politique et l'overlay (DN lu, pas devine).
3. syncRegistrations absent : un compte cree dans Keycloak n'atteignait jamais
ou=people — acces web, aucune boite, invisible du modele de groupes.
4. Le prenom pointait sur cn (nom complet) : « Administrateur systeme systeme ».
Ajoute roles/resoudre_politique_mdp : LA declaration, traduite en pwdPolicy,
passwordPolicy et anti-force-brute. Les deux roles la consomment sans la
redeclarer.
usePasswordModifyExtendedOp ET validatePasswordPolicy : la seconde est
porteuse, Keycloak se liant en rootDN et slapd n'appliquant pas ses controles
de qualite au rootDN. La premiere seule aurait paru juste sans tenir.
Verification : abcd -> 400 « minimum length 12 » et absent de LDAP ; mot de
passe conforme -> 204 puis ldapwhoami accepte ; POST users -> 201 ET present
dans ou=people. Second passage des deux playbooks : changed=0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le realm portait une politique d'acces complete et aucun moyen d'ecrire a qui
que ce soit. Tout oubli remontait donc a l'exploitant, qui n'avait d'autre
choix que de manipuler le mot de passe d'autrui.
- serveur_keycloak/tasks/courriel-realm.yml : reconcilie smtpServer et
resetPasswordAllowed ; hote du relais DERIVE de applications.postfix.hote,
et refus explicite si le plan ne declare pas de MTA.
- passe par l'API d'administration : kcadm.sh accepte les deux formes -s sur
une map, sort en succes et n'ecrit rien (smtpServer reste vide).
- amorcage_acces_courriel redevient a declarer : cette adresse designe une
personne, hors du systeme qu'on amorce ; une boite interne serait illisible
tant qu'on n'a pas l'acces qu'on cherche justement a recuperer.
- autorisation.md §6.6 : le mecanisme, ses deux conditions, et l'ecart
d'adresse laisse par l'ancien mode READ_ONLY de la federation.
Preuve : banniere SMTP lue depuis idm-01, RCPT TO accepte, execute-actions-email
declenche, MTA en starttls -> relay=mx.chezlepro.ca status=sent (250). Second
deploiement changed=0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`ldappasswd` ne peut pas le changer : `cn=admin` n'est pas une entree de la base
mais le rootDN declare dans cn=config. Le mot de passe vit dans `olcRootPW` et se
modifie par un bind EXTERNAL. L'echec etait sans degat — l'ancien fonctionnait
toujours, verifie avant de continuer.
Keycloak stocke le mot de passe de LIAISON dans sa base et le masque : la
reconciliation d'hier couvrait l'URL, les DN et le mode, pas `bindCredential`.
Tourner le secret aurait coupe Keycloak de l'annuaire. Comme la valeur est
masquee, la reconciliation passe par une empreinte.
Verifie consommateur par consommateur : synchro LDAP de Keycloak (qui prouve la
liaison), carte LDAP de Postfix, Dovecot actif. Les trois rejouent a changed=0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le secret avait fui dans une sortie de diagnostic. Le faire tourner a d'abord
demande de rendre la rotation possible : ni Keycloak ni Forgejo ne reconciliaient
un secret OIDC existant. Le commentaire de clients-oidc.yml l'avouait
(« create-si-absent »), et `update-oauth` ne passait pas --secret.
Regenerer la voute aurait laisse les deux cotes sur l'ancienne valeur — ou un
seul des deux, et le SSO aurait casse sans que rien ne l'annonce.
Keycloak compare desormais le secret EN PLACE a celui voulu avant d'ecrire.
Verifie par empreinte aux trois endroits : voute, Keycloak, Forgejo — identiques.
Keycloak rejoue a changed=0.
Signale sans etre corrige : `Deployer app.ini` change a chaque passage. Forgejo
reecrit lui-meme ce fichier (il y persiste ses secrets generes) et le gabarit
l'ecrase. Prealable au correctif : decider quelles cles appartiennent au gabarit.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ce compte est le moyen de se changer lui-meme : regenerer la voute d'abord
l'aurait rendu inapplicable — plus rien n'aurait pu s'authentifier pour poser la
nouvelle valeur. L'ordre est inverse : s'authentifier avec l'actuelle, poser la
nouvelle, verifier, PUIS ecrire la voute.
C'est une procedure, pas un redeploiement. Meme contrainte pour
`vault_openldap_admin`, qui reste a faire. Consigne au runbook §6.7, avec le
rappel qu'une verification n'est pas un message de succes.
Verifie : admin (voute) OK, groupe sysadmin et role grafana-admin intacts,
rejeu a changed=0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le runbook promettait cette rotation ; le code ne savait pas la faire. Les trois
roles ne posaient le mot de passe qu'a la CREATION — regenerer la voute aurait
produit le mensonge silencieux corrige toute la journee.
Chaque role sait desormais CHANGER un mot de passe existant, idempotent par
empreinte du secret applique. Pour Nextcloud le secret passe par l'environnement,
pas par la ligne de commande ou il serait visible dans la table des processus.
`grafana-cli` ecrivait dans une base FANTOME en annoncant « changed successfully »
a chaque fois : il prend `paths.data` a `<homepath>/data`, le paquet Debian range
la base dans /var/lib/grafana. Demasque par le champ `updated` du compte, reste a
l'heure du deploiement initial malgre quatre reinitialisations « reussies ». Un
message de succes n'est pas une preuve ; l'etat l'est.
Verifie par authentification reelle : Grafana 200, Nextcloud 200. Forgejo ferme
l'API par doctrine (D-41) — seule preuve disponible : le retour de la commande.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le dernier `porte_par: liste-uid` du catalogue. `roles.ini` porte desormais
`groups = "sysadmin"` ; `serveur_icingaweb2_admins` devient un repli de
depannage, VIDE par defaut.
Le mode SSO complique le montage : les membres d'un `groupOfNames` sont des DN,
alors que `REMOTE_USER` est une chaine. Un backend LDAP supplementaire est
declare — jamais utilise pour authentifier — uniquement pour que `groups.ini`
resolve le nom vers son DN. Sans ce pont, l'habilitation par groupe est
impossible en SSO.
NON PROUVE : la resolution REMOTE_USER -> DN -> appartenance est interne a
Icinga Web 2 ; seule une connexion reelle par le SSO la confirmera.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`realm-admin` (role du client `realm-management`) est attache au GROUPE sysadmin.
Administrer le realm ne passe plus par le compte local. Portee : CE realm, jamais
`master` — le compte de secours reste hors d'atteinte du groupe, et c'est le sens
meme d'un acces de secours (D-40).
Les roles de CLIENT sont un espace de noms distinct : la declaration gagne
`roles_client`. L'API attend l'UUID du client, pas son clientId — interroger par
le nom rendait une erreur, la verification echouait toujours et la tache se
declarait `changed` a chaque passage. Deux passages consecutifs a changed=0.
La boucle de changement de mot de passe : `pwdMustChange: TRUE` signifie « quand
un ADMINISTRATEUR pose un mot de passe, l'utilisateur doit le changer ». Keycloak
ecrit en tant qu'administrateur — chaque changement relaye etait vu comme une
reinitialisation. Incompatible par construction avec un IdP qui relaie.
La contrainte est deplacee la ou l'utilisateur la voit : pwdMustChange FALSE cote
annuaire, action `UPDATE_PASSWORD` posee par Keycloak. J'avais eprouve pwdReset
au niveau LDAP, ou il marche, sans parcourir le chemin complet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le changement de mot de passe imposé echouait sur « Federated storage is not
writable » : `editMode=READ_ONLY` etait code en dur. Keycloak lisait l'annuaire
sans pouvoir y ecrire — `pwdReset` devenait un cul-de-sac, LDAP exigeant un
changement que Keycloak ne pouvait pas faire.
Trois modes, un seul tient avec la doctrine. `UNSYNCED` ferait ecrire Keycloak
dans SA base : Dovecot et Postfix, qui se lient directement a LDAP (D-39),
valideraient encore l'ancien mot de passe. Ca aurait « marche » a l'ecran en
cassant le courriel en silence. `WRITABLE` ecrit A TRAVERS : l'annuaire reste la
source unique, Keycloak n'en est qu'un client.
Le mode devient une variable et il est RECONCILIE : un provider cree en
READ_ONLY le serait reste a vie.
Deux fautes de ma part au passage : extraction ancree sur `$` alors que la ligne
finit par un guillemet, et pas de `|| true` — sous `pipefail`, un grep vide tue
le script. Masque par `no_log`, pour la troisieme fois aujourd'hui.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
La premiere connexion du sysadmin echouait sur « invalid username or password ».
Ni le jeton ni le compte : `https://auth.<domaine>/` redirige vers `/admin/`, la
console du realm `master`, ou `sysadmin` n'existe pas — il vit dans le realm
applicatif.
Le runbook disait « se connecter a Keycloak » SANS donner d'URL, et l'URL
evidente est la mauvaise. Il nomme desormais les deux consoles :
/realms/<realm>/account/ ton compte sysadmin + jeton
/admin/ Keycloak lui-meme admin + vault_keycloak_admin
L'absence de `pwdFailureTime` cote LDAP etait le vrai indice : aucune tentative
n'atteignait l'annuaire, donc le probleme etait en amont de la validation.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le sysadmin ne pouvait atteindre AUCUNE interface web de la flotte qu'il
administre : le pare-feu de l'hyperviseur n'autorisait le 443 de l'edge que
depuis `+t17-flotte`. Le reseau d'administration est dans `t17-admin`.
L'exploitant arrive par un TROISIEME chemin que rien ne declarait : ni `externe`
(Internet, affaire de la frontiere), ni `flotte` (le tenant). Le runbook de
reprise supposait pourtant qu'on ouvre Keycloak dans un navigateur.
`admin` devient un pair declarable — les reseaux de `nftables_admin_ssh`, deja
source unique de la garde anti-lockout. `serveur_nginx` le declare pour son 443.
L'edge SEUL : ouvrir les services en direct elargirait la surface pour rien.
Erreur de methode de ma part : mon premier test utilisait `/dev/tcp` et concluait
« atteignable ». Faux — la frontiere repond au SYN a la place de la cible. Je
l'avais consigne le matin meme.
`make ca-racine` / `make ca-empreinte` : l'hote de l'AC est derive du groupe
`serveur_step_ca`, et la sortie insiste sur la comparaison d'empreinte. La racine
est un certificat PUBLIC — hors voute, dans le magasin de confiance.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Quatre meta/empreinte.yml declaraient leurs valeurs A LA RACINE, sans la cle
`setops_empreinte:` : collabora, nextcloud, web_dorsal, web_frontal. Le lecteur
les voyait vides et rendait {0,0,0} — en silence. collab-01 s'est retrouvee avec
1 coeur / 1 Go pour porter Nextcloud ET Collabora, et a cesse de repondre en SSH
faute de memoire. Corrigee : 4c/5632Mo. Une garde refuse desormais cette forme.
Un fichier qui existe mais ne dit rien est pire qu'un fichier absent : le repli
aurait donne des valeurs sensees.
Deux courses de premier demarrage :
- le clone rend la main avant que son .conf existe -> attente active sur l'API ;
- le verrou dpkg frappait hors de `common_packages` -> `lock_timeout` pose en
module_defaults sur les 30 playbooks de groupe, une declaration au lieu de 30.
Au passage, j'ai failli livrer pire que le defaut : une URL coupee avec `>-`
inserait une ESPACE en son milieu. Le lint passait, la requete non.
Enfin : `proxmox_kvm` identifie une VM par son NOM. Une VM heritee homonyme lui
a fait rapporter `ok` sans rien cloner — un deploiement peut donc PARAITRE
reussi alors qu'aucune VM n'existe. Touche D-37 directement.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`forge-01` a echoue sur une URL de decouverte pointant
`https://keycloak.<domaine>` — le nom que rien ne publie. J'avais corrige
exactement ca dans `serveur_oauth2_proxy` quelques heures plus tot, en croyant
regler un cas isole.
Il etait dans quatre roles : forgejo, grafana, nextcloud, oauth2-proxy. Chacun
fabriquait le meme nom par la meme convention. Une cinquieme correction a la main
aurait diverge comme les quatre autres.
`roles/resoudre_idp` lit l'exposition declaree au plan et rend hote, base et
discovery. Les roles n'en gardent qu'un REPLI nomme, jamais la valeur de travail.
Verifie en base sur forge-01 : discovery = auth.chezlepro.internal,
GroupClaimName = groups, AdminGroup = sysadmin.
Meme lecon que `resoudre_annuaire` hier : corriger la valeur la ou elle echoue ne
corrige que la. Ce sont les copies silencieuses qui coutent la journee suivante.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Les deux services n'etaient pas encore deployes : les cabler maintenant vaut
mieux que les corriger apres. `porte_par` passe de `aucun` a `claim-groupe`.
Forgejo recoit --group-claim-name + --admin-group, et sa tache passe de « creer
si absent » a add-oauth OU update-oauth : le meme defaut que la federation
Keycloak — cree une fois, jamais corrige — l'attendait sinon.
Nextcloud recoit --mapping-groups + --group-provisioning, plus une tache qui
verse les membres du groupe d'habilitation dans le groupe interne `admin` : etre
dans un groupe projete ne donne aucun pouvoir en soi.
Le maillon qui manquait aux deux : AUCUN mapper de protocole n'emettait le claim.
Les groupes existaient dans le realm et n'apparaissaient dans aucun jeton — un
cablage correct des deux cotes et rien au milieu. `oidc-group-membership-mapper`
pose sur les trois clients, `full.path=false` pour que le claim porte `sysadmin`
et non `/sysadmin`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
La chaine est complete : LDAP cn=sysadmin -> groupe de realm -> role
grafana-admin -> Admin dans Grafana. Ajouter quelqu'un au groupe dans l'annuaire
lui ouvre Grafana sans deploiement et sans que personne ne soit nomme (D-66).
Rejoue : changed=0.
Defaut de fond trouve en chemin : la federation LDAP n'etait JAMAIS reconciliee.
`federation-ldap.yml` creait le provider s'il manquait puis ne le corrigeait
plus — il pointait encore `ldaps://id-ldap-01...`, le nom errone corrige le matin
meme dans `resoudre_annuaire`. La synchronisation echouait sur `UnknownHost`.
C'est le revers de D-67 au mauvais endroit : l'INFRASTRUCTURE se reconcilie,
seules les appartenances ne le sont pas. URL, usersDn et bindDn sont desormais
corriges a chaque passage.
Et j'avais masque l'echec avec `|| true` : le mapper existait, le realm restait
vide, rien ne disait pourquoi. Retire — l'erreur remonte avec son message.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Chaque role web declare le GROUPE qu'il reconnait et ce qu'il lui accorde. Un
troisieme champ s'est impose en ecrivant : `porte_par` — le mecanisme qui
transporte reellement l'habilitation. Sans lui, les declarations auraient decrit
une chaine inexistante.
Etat mesure : grafana `role-realm` (reel) ; forgejo, nextcloud et keycloak
`aucun` ; icingaweb2 `liste-uid` — il NOMME DES PERSONNES, ce que D-66 interdit.
Le maillon manquant est chez Keycloak : `role_assignments` assigne un role a un
UTILISATEUR, et son propre commentaire l'admettait (« en prod, preferer
l'assignation via groupe d'annuaire »). Sans group-ldap-mapper, les groupes LDAP
n'atteignent jamais les services. Sa meta a donc une autre forme,
`acces_projection` : Keycloak projette au lieu de consommer (D-65).
Defaut corrige : `serveur_icingaweb2_admins` valait "testmail", un compte de
test code en dur dans le moteur qu'aucune instance ne surchargeait — le seul
administrateur declare de la supervision etait un utilisateur inexistant. Il
suit desormais l'uid d'amorcage. Verifie sur mon-01 : users = "sysadmin".
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le module etait sur disque mais jamais charge (seul back_mdb l'etait). Depuis
OpenLDAP 2.5 son schema est INTEGRE au module : aucun .ldif a charger.
La contrainte mord, mesuree sur un compte fraichement amorce :
Insufficient access (50)
Operations are restricted to bind/unbind/abandon/StartTLS/modify password
Le sysadmin peut se connecter et RIEN d'autre que changer son mot de passe. Ce
que la doctrine promettait est garanti techniquement, plus seulement demande.
`pwdMustChange` est ce qui donne son effet a `pwdReset` : sans lui, marquer une
entree n'oblige a rien. La politique apporte aussi longueur minimale 12,
verrouillage apres 5 echecs, historique. `olcPPolicyUseLockout` reste FALSE :
annoncer « compte verrouille » renseignerait un attaquant sur son existence.
Le DN de la base est LU, pas suppose : olcDatabase={1}mdb est l'usage mais
l'index n'est pas garanti.
La detection du role d'amorcage s'est verifiee d'elle-meme : rejoue apres le
chargement, il annonce « Changement FORCE » la ou il disait l'inverse une heure
plus tot.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Cree uid=sysadmin et cn=sysadmin dans LDAP. Prouve sur idm-01 : le compte
s'authentifie, et le second passage ne touche a rien (changed=0, 7 taches
sautees) — idempotence par EXISTENCE, pas par conformite (D-67).
Il suit l'annuaire au lieu de se declarer au plan : il ecrit par `ldapi:///` et
doit tourner sur cet hote. Le declarer comme groupe obligerait chaque instance a
le poser sur le bon hote, et elles ne le nomment pas pareil (idm-01 ici,
id-ldap-01 chez Technolibre) — je l'ai d'abord pose sur infra-pki-01 par erreur.
Trois defauts trouves en le construisant :
1. `pwdReset` n'existe pas dans ce schema (overlay ppolicy non charge) :
l'entree entiere etait rejetee et `no_log` masquait la cause. J'avais suppose
un mecanisme sans verifier. Le role le DETECTE maintenant, et la doctrine ne
promet plus un changement force qui n'a pas lieu.
2. Le mot de passe aurait ete stocke EN CLAIR : `ldap_entry` ecrit userPassword
litteralement. Hache par `slappasswd -h {SSHA}` desormais.
3. `voute.py` ne scannait que roles/<groupe> : un role applique par un playbook
sans etre un groupe echappait au recensement, ce que D-20 interdit. Il suit
maintenant les listes `roles:` des playbooks.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
L'authentification etait resolue et gardee ; l'autorisation n'existait nulle
part. `ou=groups` est cree depuis le debut et AUCUN des 29 roles ne le lit ;
`ou=people` est vide.
D-67 contredit DELIBEREMENT la doctrine du depot : partout ailleurs un ecart est
un defaut a corriger, ici il est legitime — c'est le sysadmin qui travaille.
Set-OPS cree UN acces puis se retire. Idempotence par EXISTENCE, pas par
conformite : compte present, aucune action quel que soit son etat. Reconcilier
effacerait le compte cree la veille pour un nouvel employe.
D-65 : les groupes LDAP portent l'autorisation, Keycloak les projette. Dovecot
et Postfix ne savent pas lire un role Keycloak — un seul endroit a administrer.
D-66 : un service nomme un groupe, jamais une personne : revoquer quelqu'un ne
demande pas un deploiement.
Le §6 est un runbook de reprise. Il dit aussi ce qu'il faut regenerer pour que
la livraison soit un vrai transfert : les comptes de secours ont ete generes
pendant le deploiement, et leur auteur y a eu acces.
Sans registre de personnes, aucune donnee personnelle n'entre dans git.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
L'authentification etait resolue et gardee ; l'autorisation n'existait nulle
part. `ou=groups` est cree depuis le debut et AUCUN des 29 roles ne le lit —
toute personne authentifiee obtient le defaut du service.
D-65 : les groupes LDAP portent l'autorisation, Keycloak les projette.
L'argument est mecanique : Dovecot et Postfix ne savent pas lire un role
Keycloak. L'y loger rendrait la moitie courriel aveugle et imposerait deux
modeles de permissions.
D-66 : un service nomme un GROUPE, jamais une personne. Un depart devient une
ligne au plan, sans toucher un service.
Le vocabulaire d'habilitation reste celui du service : une echelle commune
devrait etre traduite partout, et la traduction est ou l'habilitation se perd.
Rien n'est construit : registre, role, meta/acces.yml et P31 restent a ecrire.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`resoudre_annuaire` fixait `id-ldap-01` en dur — une machine qui n'existe dans
aucun plan. Postfix ne pouvait pas se lier : « Can't contact LDAP server ».
L'intention etait juste et son commentaire le disait : un seul point ou le nom
est fixe, au lieu d'etre repete dans chaque role. Mais ECRIT au lieu d'etre
derive. Une valeur unique et fausse vaut mieux qu'une valeur repetee et fausse ;
elle reste fausse.
Le plan le declare (`applications.openldap.hote`) : c'est de la qu'elle vient.
infra-mail-01 et edge-mta-01 deployees, 19 playbooks sans un echec. LMTP en TLS
verifie, mynetworks sur le supernet derive, liaison LDAP etablie vers idm-01.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
oauth2-proxy fonctionne devant Icinga Web 2 : 302 vers Keycloak, qui federe
LDAP. Quatre defauts leves, dont trois du meme motif — un nom construit par
convention d'un cote, declare de l'autre.
1. Le secret de cookie etait en base64 STANDARD. oauth2-proxy decode en
url-safe : le decodage echoue, il retombe sur la chaine brute et se plaint de
sa LONGUEUR, jamais de l'encodage. Garde ajoutee qui refuse + et /.
2. L'issuer etait fabrique (`keycloak.<domaine>`), un nom que rien ne publie.
Le plan expose `auth.<domaine>` — c'est ce nom que le DNS resout et que nginx
sert. Derive desormais du champ `expose`.
3. Keycloak s'annoncait sous ce meme nom invente : « issuer did not match ».
Meme correctif a la source.
4. Le pare-feu est-ouest bloquait l'edge : nginx ne declarait son 443 qu'avec
`pair: externe`, que le devis est-ouest saute (il releve de la frontiere).
Le flux existait d'un seul cote et la matrice etait satisfaite. nginx declare
maintenant aussi son 443 depuis la flotte.
obs-01 et mon-01 deployees. 7 cibles Prometheus up, scrutees en TLS a travers
cinq zones du VRF.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Keycloak ne demarrait pas : pg_hba n'autorisait que 10.11.0.0/16 pour un tenant
en 10.27.0.0/16. La valeur etait figee dans group_vars, sous un commentaire
« AJUSTER au sous-reseau reel » que personne n'a suivi.
Postfix portait la meme valeur perimee et aurait echoue plus tard sur le
courriel. Technolibre aussi (10.12.0.0/16 pour un tenant en 10.21.0.0/16).
Quatre fichiers, une seule faute, repetee parce que recopiee.
`setops_supernet` se derive comme le VMID et l'adresse ; les quatre fichiers le
consomment. Chezlepro -> 10.27.0.0/16, Technolibre -> 10.21.0.0/16, sans saisie.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`idm-01` a prouve le routage inter-zone dans le VRF (10.27.19.21 -> 10.27.17.11,
deux passerelles anycast) et leve trois defauts qu'aucun devis ne pouvait
montrer :
1. Le handler de `client_pki` rechargeait `slapd` avant son installation —
consequence directe de l'ordre retabli. Un consommateur absent n'est pas une
erreur ; un vrai echec de rechargement reste fatal.
2. `resoudre_base` ne trouvait aucune base de portee `application` : Keycloak
declare `consommateur: keycloak`, le role cherchait `serveur_keycloak`. Le
lien est declare dans applications.yml — on le suit au lieu de retirer un
prefixe a la main.
3. Keycloak attend PostgreSQL, pas encore deploye. Pas un defaut : `deployer`
ne connait que l'ordre intra-hote, l'ordre inter-hotes est celui de `site`.
Et deux attentes, sans lesquelles on ne peut pas enchainer creation et
deploiement — donc sans lesquelles `myDay` ne reconstruit pas seul : SSH, puis
cloud-init et les maj automatiques. `creer-vm` rend desormais une VM PRETE.
`lock_timeout: 300` sur chaque tache apt complete l'attente : le verrou peut
etre repris ENTRE deux taches, ce qu'une verification en amont ne previent pas.
Defaut dans l'attente elle-meme : `unattended-upgrades` est un demon, toujours
actif — l'inclure rendait la condition impossible a satisfaire.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`make deployer` triait les groupes alphabetiquement apres le socle :
`client_metrique` passait avant `serveur_step_ca`, donc exigeait un certificat
que l'autorite, pas encore deployee, ne pouvait pas avoir emis — sur l'hote de
l'AC lui-meme. `docs/couches-deploiement.yml` existe pour definir cet ordre et
dit « integrations deployees en dernier » ; `make site` le lit, `deployer` ne
l'avait jamais lu. Meme registre desormais.
Deux politiques universelles se contredisaient : `client_pki` exemptait l'AC,
`client_metrique` refuse toute exemption. L'exemption confondait « ne pas
s'enroler » et « ne pas avoir de certificat ». `client_pki` distingue les deux
chemins : bootstrap pour les autres, EMISSION LOCALE sur l'AC. L'exemption
disparait, la doctrine reste.
Effet de bord instructif : `step ca bootstrap` ecrit aussi le defaults.json qui
porte l'URL de l'AC. En sautant le bootstrap on perdait l'information sans le
voir. `--ca-url` et `--root` sont explicites pour tous les hotes.
Mesure : infra-pki-01 et infra-dns-01 entierement deployees, aucun echec,
step-ca health=ok, powerdns resout la zone souveraine, et les deux hotes portent
un certificat de l'AC interne.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le generateur emettait `{protocole} dport {port}` pour tout flux. L'ICMP a un
type et un code, pas un port : `icmp dport frag-needed` produit un jeu que `nft`
rejette, et un jeu rejete ne se charge PAS — l'hote perd sa barriere au lieu
d'en gagner une.
Le defaut touchait les 14 hotes. La seconde barriere de D-31 n'avait jamais pu
demarrer nulle part ; personne ne l'avait vu parce qu'aucune VM tenant n'avait
encore ete deployee.
`_selecteur_nft()` traduit : `icmp frag-needed` devient
`icmp type destination-unreachable icmp code frag-needed`. Un code inconnu est
refuse a la generation, avec le nom du role fautif. La garde tourne aussi a la
verification, pour attraper un flux declare mais pas encore porte.
Mesure : nftables actif sur infra-pki-01 et infra-dns-01, 16 et 17 regles, dont
la garde anti-lockout.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Une VM ne peut pas s'installer sans resoudre des noms. PowerDNS repond
UNIQUEMENT pour la zone souveraine et ne recurse pour personne : il manquait un
resolveur recursif. `client_unbound` est l'outil ecrit pour ca — il rejoint
`client_journal` et `client_metrique` parmi les integrations universelles.
`infra-dns-01` est exempte (PowerDNS occupe son port 53), et
`serveur_powerdns_listen_addresses` passe de 0.0.0.0 a l'adresse de l'hote pour
laisser 127.0.0.1:53 libre. Mais l'appartenance au groupe est AUSSI ce qui ouvre
le port 53 a la frontiere : en exemptant la machine, je lui retirais le droit de
resoudre. `serveur_powerdns` declare donc son propre flux sortant — il ne
recurse pour personne, mais doit resoudre pour lui-meme.
Nouvel intrant `dns_amorcage`, derive jusqu'a `make creer-vm`. Cloud-init
l'ecrit bien mais sans effet : `dns-nameservers` exige `resolvconf`, absent du
gabarit, et installer resolvconf demande apt, qui demande la resolution.
`serveur_debian` pose donc le resolveur en pre_tasks, avant le premier apt, avec
une garde qui respecte la bascule ulterieure de client_unbound.
Defaut corrige en chemin : `_intrants_communs()` lisait `instance/` en dur ; le
chemin derive maintenant de l'inventaire recu, et un test le prouve.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`infra-pki-01` recreee pour eprouver la chaine complete. Tout ce qui derive du
seed est exact : VMID, pont t17serv sans etiquette, adresse, passerelle, pool,
et desormais le gabarit de calcul.
1. Le pare-feu est-ouest aurait enferme Ansible : `t<idx>-srv-debian`
n'autorisait SSH que depuis la flotte du tenant, et `admin_de(nom)` etait
collecte puis jamais utilise. IPSet `t<idx>-admin` dedie + regle sourcee
dessus. Pas d'ajout a `flotte`, qui sert aussi LDAP, SQL et les metriques.
2. L'applicateur ne convergeait pas : Proxmox range `x/32` en `x`, et la
comparaison litterale laissait un ecart perpetuel. `_norm()` le ferme.
3. `cloner-vm` refusait toute VM de tenant : son garde exigeait un VLAN, vide
par construction en SDN. Accepte desormais si un pont est fourni.
4. Le clonage ignore `cores`/`memory` : la VM heritait du gabarit (2/2048) au
lieu du plan (1/1024). Une tache les repose apres le clone.
Et le troisieme verrou de D-64 : `proxmox_clone_parefeu_interface: true`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le devis enseignait « politique d'entree DROP au datacenter ». Or policy_in y
est la politique par defaut de TOUTE VM dont le pare-feu s'active — 37 machines
heritees sans regles, sur ce cluster. `policy_in` existe aussi par VM : le devis
et l'applicateur le posent la. Meme isolation, sans falaise, et l'applicateur
n'a plus a refuser une partie de son devis.
Trois verrous, pas un : datacenter enable=1, `enable` de la VM (defaut 0), et
`firewall=1` sur la carte. C'est le verrou du milieu que j'avais manque en
annoncant que huit VM en production tomberaient.
`enable=1` au datacenter bascule et verifie : pve-firewall running, 12 chaines
cadres, AUCUNE chaine par VM, 0 regle visant roxanne, 15 VM toujours en marche,
hyperviseurs et frontiere joignables, sortie tenant 2/2.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Reconcilie les trois couches du devis : 26 IPSets, 36 groupes, affectations aux
VM. Cree, met a jour, retire — meme contrat que les applicateurs de la frontiere
et du SDN.
Il n'active JAMAIS le pare-feu du datacenter : ce reglage vaut pour toutes les
VM du cluster, y compris les 37 heritees sans regle, et le basculer couperait le
parc. L'ecart est signale a chaque execution ; la decision reste humaine.
Les 28 VM du devis n'existent pas encore : listees comme differees, pas comme
erreurs. Les objets poses sont donc inertes, ce qui rend l'application sure.
`scripts/proxmox_api.py` extrait ce que les deux applicateurs Proxmox partagent,
en particulier la recomposition du jeton dont la voute ne porte que le nom.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Deuxieme applicateur du depot, meme contrat que celui de la frontiere. Deux
cibles : les objets de cluster par l'API Proxmox, la sortie du VRF par SSH —
`/etc/frr/frr.conf.local` n'est expose par aucune API.
Perimetre strict : seules les zones du devis et les anciens nommages listes sont
touches ; une zone inconnue est signalee et laissee intacte. Un VNet encore
branche a une VM est refuse, avec le nom des machines. L'ordre suit les
dependances : sous-reseaux, VNets, zones.
`devis_sdn.strophe_frr()` est la source unique : le devis l'affiche,
l'applicateur la compare au fichier distant.
Defaut trouve a la premiere execution : la lecture sans `sudo` echouait, un
`|| true` masquait l'echec, et un fichier present etait declare absent puis
reecrit. Trois etats distingues desormais : absent, illisible, different.
Rejeu a vide, six VRF avec leur defaut, sortie tenant fonctionnelle.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`proxmox_sdn.sortie_primaire` etait declare et utilise par `devis_opnsense`
pour deriver le prochain saut de la frontiere, mais `devis_sdn` ne l'emettait
jamais : une zone creee depuis ce devis n'aurait pas eu de primaire, et les deux
devis se seraient contredits. Le devis l'emet, et refuse un primaire absent de
la liste des noeuds de sortie.
Cluster aligne : t17 passe a asgard,gandalf,vishnu (primaire asgard), strophe
FRR posee sur les trois noeuds, six VRF portant leur defaut.
Note de methode : une adresse ANYCAST ne peut pas servir de source de test. Le
ping depuis gandalf semblait mort a 100 % ; la capture a montre asgard recevant
les quatre reponses — la frontiere route le supernet vers le primaire, qui porte
la meme passerelle localement.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Deux obstacles, aucun n'etait celui qu'on croyait.
Proxmox n'installe AUCUN defaut dans le VRF du tenant : `default-originate`
annonce une route aux autres noeuds, il n'en pose pas chez lui. Les deux zones
etaient dans cet etat. La sortie vient d'une strophe frr.conf.local, que Proxmox
fusionne a chaque regeneration (verifie : survit a `pvesh set /cluster/sdn` et a
un redemarrage de FRR).
`nexthop-vrf default` emprunte UNE adresse au lieu d'importer la table
principale : la route par defaut des hyperviseurs ne gouverne pas la sortie des
tenants. `import vrf default` l'aurait fait contourner la frontiere et aurait
fuite le transport VXLAN, la gestion et les VLAN herites dans le VRF.
Le NAT sortant en mode automatique ne couvre que les reseaux directement
attaches ; un supernet joint par route statique en sort en silence. L'etat
montrait `nat_addr` absent : le filtre passait, la traduction manquait.
`devis_opnsense` emet le NAT (section 2bis), le reconciliateur l'applique et le
retire, et P24 refuse tout supernet route mais non traduit.
Mesure : tenant -> frontiere 3/3, -> passerelle FAI 3/3, -> Internet 2/2 pour
les deux tenants.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`scripts/appliquer_opnsense.py` remplace les scripts jetables du bac a sable.
Il travaille dans les deux sens : ce que le devis demande et qui manque est
cree, ce qu'il ne demande plus est retire. Sans ce second sens, un devis qui
change laisse des regles mortes — elles n'ouvrent rien, mais decrivent une
politique qui n'est plus la notre.
Perimetre strict : seuls les objets marques `setops:` ou prefixes `SETOPS_`
existent pour ce script. Ce qu'un humain a pose a la main lui est invisible.
L'ordre porte une propriete : alias, creations, PUIS retraits. A aucun instant
la politique n'est plus permissive qu'avant ; si un retrait echoue on reste en
surcouverture, jamais avec un trou.
Garde de la regle 4 : sans CONFIRMER=true, aucune ecriture. Le devis doit en
outre passer P24 avant qu'une requete ne parte.
Applique sur la frontiere : 3 alias et 3 regles crees, 2 regles perimees et 2
alias orphelins retires. Rejoue, le plan est vide — convergence prouvee.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le devis rangeait tout flux entrant sur le WAN, en supposant que
l'administration revenait par l'adresse publique. Vrai pour 192.168.255.0/24,
faux depuis que c'est 10.0.0.0/24 — directement attache sur `lan`. Les deux
regles SSH etaient mortes deux fois : mauvaise interface, et « Block private
networks » les aurait filtrees. Le devis conseillait meme de decocher ce filtre
sur le WAN, ce qui aurait affaibli l'interface publique pour rien.
`reseaux_locaux_frontiere()` derive de l'underlay les sous-reseaux ou la
frontiere porte une adresse, hors transit. Un alias par interface : Technolibre
a les deux cotes, Chezlepro seulement la gestion. Sans underlay, tout retombe
sur le WAN — comportement inchange.
P24 confronte desormais chaque regle d'administration a l'attachement de sa
source, et refuse l'ancien comportement.
Nouvel intrant `opnsense_if_gestion`, au catalogue du GUI.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`nftables_admin_ssh` est la source unique du « d'où administre-t-on » : il
alimente les alias de la frontière, le devis du commutateur et le jeu nftables
de chaque VM. Chezlepro déclarait encore l'ancien 192.168.255.0/24.
`make flux` échouait par ailleurs sur un tri mêlant ports numériques et
symboliques — défaut latent réveillé par les deux flux ICMP frag-needed, qui
sont dans les deux sens. `_cle_port()` rend la clé homogène.
Aperçus régénérés : les 14 hôtes actifs de Chezlepro portent 10.0.0.0/24.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le prochain saut des routes tenants ne s'écrit plus <NOEUD-DE-SORTIE-EVPN> : il
dérive. Deux déclarations doivent concorder, et c'est voulu — l'hébergeur nomme
le nœud (proxmox_sdn.sortie_primaire, propriété du cluster), l'underlay dit son
adresse SUR LE LIEN DE FRONTIÈRE. Nommer un nœud absent du lien rend le devis
muet plutôt que faux.
route add 10.21.0.0/16 via 10.0.4.41
route add 10.27.0.0/16 via 10.0.4.41
Le devis explique pourquoi cette adresse-là — ni l'underlay ni la gestion, la
frontière n'atteint que celle-là — et pourquoi un seul saut : une route statique
n'en porte qu'un, et deux nœuds actifs en sortie avec une seule route en entrée
donneraient un chemin asymétrique.
Identifiant d'interface vérifié plutôt que supposé : l'API des règles donne
elle-même sa liste (lan → GESTION, opt1 → TENANTS, wan → WAN). Ni le
périphérique vlan040, ni le libellé. L'intrant opnsense_if_transit: opt1 était
juste — question ouverte depuis deux jours, tranchée par la mesure.
Consigné au CHANGELOG : l'EVPN tourne (six sessions BGP, tunnels sortis de la
carte de gestion), une alarme retirée sur des VRF que je croyais inversés, et une
brèche réelle à filtrer avant la première VM tenant — un nœud de sortie expose au
tenant tout ce que l'hyperviseur touche directement, et déplacer la route par
défaut n'y suffira pas puisqu'une route connectée l'emporte.
30 preuves OK.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Les deux commutateurs deviennent bifrost-3 et bifrost-4, avec 10.0.0.3 et
10.0.0.4. Tout l'ensemble de bordure porte un seul nom, et son numéro est son
adresse : bifrost-1 = .1, bifrost-4 = .4. Plus de table de correspondance.
D-12 disait « bifrost aux frontières, sleipnir à la fabric » — le nom portait le
type de la machine. C'est le champ `role` qui le fait, et lui seul pilote le
devis : aucune logique ne dépendait du nom, seulement des données et un
commentaire. Le devis a suivi seul, jusqu'aux marqueurs de ports.
Inconvénient assumé : bifrost-3 ne dit plus « commutateur », il faut lire `role`.
La partie B du devis s'en charge à l'affichage.
30 preuves OK.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le pont n'était pas seulement non portable, il était faux. proxmox_clone_pont
faisait naître les VM sur vmbr1 avec une étiquette VLAN — l'ancien monde. En SDN
une VM appartient à son VNet ; c'est ce qu'il a fallu corriger à la main sur
infra-pki-01, et les treize suivantes auraient suivi.
deriver_nomenclature() expose désormais la zone de sécurité, instancier en dérive
proxmox_pont et une étiquette VIDE — le VNet porte déjà le tag, en poser un
second donnerait un double étiquetage. La chaîne va jusqu'à make creer-vm :
SETOPS_PONT='t11appl', SETOPS_VLAN=''.
Trois pièges. Un doublon dans le Makefile passait PONT_PROXMOX deux fois dans la
même cible, la seconde vide aurait écrasé la valeur dérivée. Un repli naïf sur
proxmox_vlan aurait fait revenir l'étiquette en SDN : le repli ne s'applique que
si la clé est ABSENTE, jamais si elle est présente et vide. Et le test unitaire
est tombé, à raison — il couvre maintenant cette distinction.
D-55 : le dépôt réseau porte le contrat entre l'Alliance et ses hébergeurs, et
abstrait le matériel en encapsulant chaque tenant dans sa zone EVPN. Mesuré : un
tenant est à deux valeurs de la portabilité complète (noeud, stockage).
D-57 : l'interface sysadmin d'un hyperviseur (vmbr0, 10.0.0.41/.43/.47) n'a pas
de route par défaut ; celle-ci vit sur vlan40, vers la frontière. On n'atteint
l'administration que depuis son propre domaine de diffusion. Ça tranche la
question de la sortie des nœuds laissée ouverte ce matin — option A, mais sur une
interface dédiée, ce qui lève l'objection qui la bloquait.
D-58 : un hôte déclare par quelle interface (`via`) chaque réseau lui arrive ; le
devis en dérive un port par interface et son type — trunk 11,40 sur bond3, accès
VLAN 10 sur vmbr0. Sans ça, ajouter le VLAN 10 le remettait sur le trunk du
transport, soit le domaine qu'on venait d'en sortir.
D-59 : un VLAN qui ne porte que des adresses d'hôte n'a pas besoin de pont.
Régression créée puis corrigée : le modèle public, qui ne déclare aucun
hyperviseur, n'émettait plus rien pour ce port. Il émet maintenant tout
l'underlay en disant que c'est un repli.
30 preuves OK, 4 tests unitaires.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Il valait partout ; il ne vaut que dans l'adressage dérivé des tenants, où
passerelle_de(index, zone) produit le même .1 dans les treize sous-réseaux d'un
tenant. C'est une propriété de la dérivation, pas une loi universelle.
Dans l'underlay il produisait deux effets pervers. Un seuil arbitraire : les
sous-réseaux plus étroits qu'un /24 étaient exemptés, donc élargir un /29
changeait la validité du fichier sans que rien d'autre bouge. Et une couture
entre propriétaires : l'octet attendu venait de la nomenclature d'un tenant,
appliquée à la fabric de l'hébergeur — la validité de l'underlay aurait dépendu
du tenant actif.
Ce qui reste est plus fort et suffit (D-52) : une passerelle doit être l'adresse
d'un hôte déclaré sur ce réseau. Elle attrape les passerelles fantômes, ce que le
comptage d'octets ne faisait pas. Vérifié : la garde mord toujours.
À noter, parce que l'ordre était mauvais : le ré-adressage de l'OPNsense en .1 a
été demandé au nom de cette règle, deux messages avant qu'elle soit recadrée. Pas
perdu — .1 est la position conventionnelle d'une passerelle — mais la portée
aurait dû être questionnée avant de faire changer une adresse en service.
D-53 : le réseau et l'underlay de l'hébergeur méritent leur propre dépôt.
underlay.yml décrit une infrastructure, le dépôt de tenant une organisation ; un
tenant peut déménager, une fabric non. Consigné, non fait.
D-54 : 10.0.0.0/24 est réservé à l'IPAM, la gestion des équipements et l'OOB,
accès sysadmin. Aucun hyperviseur, aucune VM, aucun trafic tenant. C'est la
raison d'être des VLAN 11 et 40.
30 preuves OK.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Aucun des trois SVI de sleipnir-01 n'avait de consommateur : les VTEP sont dans
le même sous-réseau, les nœuds de sortie sont adjacents à la frontière, et les
commutateurs peuvent sortir par l'OPNsense qui a déjà une patte sur le VLAN 10.
Deux décisions séparées avaient vidé ce rôle sans qu'on regarde leur effet
cumulé : le passage à l'EVPN a retiré les VLAN tenants du fil, puis la fusion du
lien de sortie dans le VLAN 40 a rendu les nœuds de sortie adjacents.
sleipnir-01 disparaît, pas seulement son rôle : en étoile, le centre est sur tous
les chemins, donc un point de panne unique du plan de données — ce qui vidait
aussi de son sens l'ajout d'une seconde carte à bond3. Deux switches L2 reliés,
bond3 répartis. D-51 ; D-05 renversée.
Le devis perd trois SVI, quatre routes, et surtout sa section 5 — celle qui
coupait l'accès d'administration au switch en cas d'erreur.
D-50 : `passerelle` signifiait « adresse du SVI du switch », une hypothèse
déguisée en donnée. Elle signifie maintenant « la passerelle de ce sous-réseau,
où qu'elle vive », et le devis dérive s'il doit émettre une interface routée —
uniquement si le porteur déclaré a le rôle switch. Le même moteur sert les deux
postures : le modèle public démontre celle où le switch route.
Deux gardes remplacées, pas affaiblies. À la place de « passerelle_sortie exige
passerelle » et « routeur.ip == passerelle », une règle plus forte : une
passerelle doit être l'adresse d'un hôte déclaré sur ce réseau. Elle attrape en
plus les passerelles fantômes. Éprouvée par trois sabotages, tous attrapés — et
elle a trouvé une sous-déclaration dans le modèle public.
Quatre trous corrigés, tous de la même famille (une liste figée finit par
mentir) : port de frontière figé sur le transit, trunk Proxmox excluant le
transit, switches d'accès sautant sa déclaration, et le switch de tête privé
d'adresse de gestion par la suppression du SVI.
D-03 renversée : le /29 élargi en /24 fait tomber l'exemption d'invariant, le .1
revient à la passerelle.
30 preuves OK.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le port du commutateur vers la frontière était figé sur le seul VLAN de transit.
Depuis que les bifrost ont une patte sur le VLAN de sortie tenant, ce port serait
resté muet : le devis aurait eu l'air juste et le trafic ne serait jamais arrivé.
Il dérive maintenant des rattachements déclarés des hôtes `role: frontiere`.
Contexte, côté underlay (dépôt de l'hébergeur) : le VTEP vivait sur le VLAN 10,
donc le transport tenant partageait son domaine de diffusion avec l'administration
des équipements. Plus grave, un nœud de sortie décapsule le trafic tenant et le
remet dans sa table principale — dont la route par défaut sort par vmbr0,
l'interface de gestion des nœuds. D'où deux VLAN dédiés, 11 (transport VXLAN) et
41 (trafic décapsulé). Le second n'a volontairement pas de passerelle : le
commutateur le transporte sans le router, et le devis n'émet donc pas
d'interface Vlan41.
Services de l'hébergeur — décision consignée, rien n'est construit :
Aucun équipement de l'hébergeur n'est dans un inventaire Ansible, et rien ne
sauvegarde leurs configurations. Ni hyperviseurs, ni commutateurs, ni frontière.
D-46 : un hébergeur porte trois catégories — son tenant (un client comme les
autres), ses opérations (supervision de la fabric, journaux, sauvegarde des
configs, DNS d'underlay), et le plan de contrôle (déjà dehors).
D-47 : les opérations vivent dans le dépôt de l'hébergeur, et leurs VM se
rattachent à un pont VLAN, jamais un VNet. Un service qui observe la fabric ne
peut pas dépendre d'elle : l'EVPN tombe, et la supervision tombe avec la raison
de la panne.
D-48 : les hyperviseurs sont gérables par Ansible ; « hors flotte » ne vaut que
pour les commutateurs (aucun agent) et la frontière (API seulement).
Question laissée ouverte : l'index 0 réservé au tenant propre de l'hébergeur. Il
produit les VNI 1001-1006, que le parc hérité utilise déjà (1001 TechnoLibre
historique, 1003 KBR), et P21 déclencherait une fausse collision entre deux
dépôts d'hébergeurs.
Construction parallèle vérifiée : aucune collision entre les 38 VM héritées et
les VNI/VLAN projetés.
30 preuves OK.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ajouter un tenant implique 1 zone EVPN + 6 VNets + 6 sous-réseaux sur le cluster.
Aucun générateur ne les produisait : dernière lacune dans un dépôt où tout dérive.
26 objets pour les deux tenants, VNI = 1000 + index×10 + zone, sous-réseau et
passerelle par les mêmes fonctions que l'inventaire.
Nommage, en deux temps. D'abord VRF0017 / v1174, alignés sur ce que le cluster
portait — réflexe inverse du bon : cette convention venait d'une création à la
main et ne disait pas de quel tenant il s'agissait. Forme retenue : t<index> pour
la zone, t<index><zone abrégée> pour le VNet (t17, t17serv). C'est le préfixe que
le pare-feu Proxmox utilisait déjà (t17-cli-metrique), donc un seul schéma dans
tout le dépôt. Abréviation = 4 premières lettres du libellé, accents retirés.
Pas de tiret entre index et zone, contrairement aux IPSets : t245-serv ferait 9
caractères, t245serv en fait 8 — la forme reste uniforme jusqu'au dernier index.
Contrainte cadrante : zones ET VNets sont limités à 8 caractères par Proxmox.
sdn-evpn.md annonçait chez17-services-infra (21) : il aurait été refusé à
l'application. P30 refuse tout dépassement et toute collision de nom, de VNI ou
de sous-réseau. Éprouvé aux bornes et par sabotage.
Vérification la plus forte : avant renommage, la dérivation reproduisait à
l'identique les deux zones créées à la main — nom, VNI de VRF, MTU, contrôleur.
voute.py saisir : le pendant de la génération. On génère un secret dont le dépôt
est la source, on saisit celui dont un tiers est la source — inventer une clé
d'API OPNsense donnerait une valeur refusée à la première requête, avec P18 au
vert sur une voûte inutilisable. Sans écho, double confirmation, rien sur la
ligne de commande.
Reste ouvert : aucun nœud de sortie déclaré. Le devis émet un marqueur, pas une
valeur plausible. Deux points à trancher — le nœud de sortie route selon sa
propre table (défaut actuel : 192.168.11.254, pas la frontière), et l'entrée
n'est pas redondante puisqu'elle dépend d'une route statique d'OPNsense vers un
seul nœud.
D-45 : l'affinité de VM attend Proxmox 9 (cluster en 8.4.19), tenue à la main.
30 preuves OK.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Une règle qu'aucune garde ne vérifie finit par ne plus être vraie — c'est ce qui
était arrivé aux 28 lignes d'intégration recopiées. Chaque rôle serveur_* porte
un meta/authentification.yml, confronté à son code par P29.
web-sso 5, socle-identite 2 (keycloak/openldap : ils SONT la chaîne d'identité),
ldap-direct 2, interne-sans-auth 2, sans-auth-humaine 12.
La preuve refuse l'oubli ET le mensonge. Éprouvée par sabotage sur sept cas :
déclaration supprimée, portée inventée, secours retiré, posture de formulaire
retirée, raison retirée, ldap-direct mensonger, réglage retiré des defaults.
Les deux derniers passaient dans la première version :
- le mensonge passait à cause d'un commentaire. Je cherchais le mot « ldap » dans
le rôle, et serveur_grafana/defaults/main.yml contient « désactiver quelqu'un
dans LDAP » : de la prose validait une déclaration fausse. La preuve exige
maintenant un indice nommé — variable <rôle>_oidc / <rôle>_ldap, ou URI ldap://
- le réglage retiré passait parce que le gabarit citait encore la variable alors
que plus rien ne lui donnait de valeur. La preuve lit defaults/main.yml en YAML
et exige que la clé y soit définie, pas mentionnée.
Elle a aussi forcé une valeur : oauth2-proxy était déclaré « formulaire local
fermé » alors qu'il n'a aucun compte local. D'où formulaire_local: aucun, qui
distingue « il n'y en a jamais eu » de « il y en a un, il est fermé ».
Correction d'une note de la veille : Prometheus et Loki ne sont PAS exposés
publiquement (aucun expose au plan). Seuls six groupes le sont. Le risque est
intra-tenant, pas frontalier. Les deux lacunes sont comptées à chaque exécution,
pas masquées.
AFF-111, D-42. 29 preuves OK, ansible-lint (production) sur 375 fichiers.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
