59 commits

Author	SHA1	Message	Date
Daniel Allaire	88033f37b8	GUI : la vue Nomenclature, et deux fautes que mes bancs ne voyaient pas ... LA VUE. La nomenclature etait le seul registre que le GUI ne savait pas ecrire du tout : ajouter une fonction exigeait d ouvrir le YAML. Elle a sa vue, et son formulaire est GENERE depuis le schema. Deuxieme registre sur six. couverture_gui verifier passe : les 28 champs des plans reels sont editables. Elle n est pas un registre comme les autres : elle decrit la REGLE dont VMID, VLAN, adresse et passerelle se derivent. Chaque fonction montre ce qu elle derive et les VM qui la portent ; l index est montre mais pas editable, parce qu il est alloue par le site ; valider_nomenclature refuse de retirer une fonction encore portee, ou de designer une zone non declaree. DEUX FAUTES, ET POURQUOI MES BANCS NE LES VOYAIENT PAS. Le formulaire des bases, livre la veille, etait casse dans un navigateur. Il lisait data.schema, or il n existe aucun data global : c est une const locale de charger(). ReferenceError a l ouverture, et zone morte dans sauvegarderBases. Je l avais eprouve sous node EN LUI PASSANT data : le banc reproduisait la fonction, pas sa portee. D ou test_rendu_gui.py, qui charge le JS entier dans un DOM simule et dessine les douze vues, avec son controle negatif. Le schema decrivait reservations comme une table de zones ; le fichier reel est un bloc plat. P61 comparait des NOMS aplatis, donc ne voyait rien. Elle compare desormais aussi la FORME. ECRIRE SANS DEPLACER UN COMMENTAIRE. _fusion_chirurgicale remplace le bloc entier des qu une valeur change : quinze entrees compactes devenaient 42 lignes, et le commentaire du poste d exploitation se retrouvait en tete du bloc, ou il affirmait que collab etait le poste d exploitation. Un commentaire deplace n est pas laid, il est faux. _fusion_table edite les tables ligne a ligne ; le diff fait trois lignes. Au passage : sort_keys triait le schema, donc l ordre des cases a l ecran (reserve_max avant reserve_min) ; et _ecrire_index_nomenclature ecrivait encore par write_text, oubliee au passage des ecritures atomiques. LIMITE : deux registres sur six sont generes, et je n ai toujours pas ouvert cette page dans un navigateur. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q	2026-09-08 17:08:45 -04:00
Daniel Allaire	0eaceb1048	schema du plan : la forme des registres devient derivee, et gardee ... Etape 2 du chantier « l UI reflete fidelement la structure ». Le GUI porte CHAMPS_ECRITS_PAR_GUI, une liste tenue A LA MAIN de ce qu il sait ecrire, que P19 confronte au reel. C est une copie — gardee, donc honnete, mais une copie : quelqu un doit penser a l allonger. `make schema` produit docs/audit/schema-plan.json : six registres, 42 champs, leurs types, leurs enumerations et ce qui est requis. CE QUE LE SCHEMA EST, ET CE QU IL N EST PAS schema -> la FORME -> generera les champs du formulaire validateurs -> la COHERENCE -> refusent une saisie incoherente Un JSON Schema ne sait pas dire qu un `consommateur` designe une application inexistante, ni qu une integration universelle recopiee au plan est un defaut. Vouloir l y mettre creerait la seconde source de verite que tout ce depot refuse. Les valider_* restent l autorite. LES ENUMERATIONS SONT IMPORTEES, JAMAIS RECOPIEES ETATS_SERVEUR, PORTEES_BD et AUTORITES_DNS viennent des constantes que les validateurs appliquent. Une enumeration recopiee diverge — c est la lecon des neuf resolutions d instance que P41 garde depuis. CE QUE L ETAPE 1 AVAIT TROUVE, ET QUE P61 A CONFIRME Le recensement montrait `categorie` et `service` presents dans TOUS les plans et absents de CHAMPS_ECRITS_PAR_GUI, dont la ligne `nomenclature` est vide : le GUI ne sait pas les editer, l operateur doit ouvrir le YAML. P61 a refuse le premier schema pour cette raison exacte. Les trois tables imbriquees de la nomenclature sont donc DECRITES et non resumees en « object ». 31 champs observes dans l instance courante, 42 decrits par le schema. La difference n est pas du bavardage : observer une instance n est pas un schema. `noeud`, `stockage` et `coeurs` sont legitimes et simplement inutilises ici — un schema derive de l observation les INTERDIRAIT. P61, EPROUVEE DANS LES DEUX SENS fichier genere perime -> REFUSE champ du plan absent du schema -> REFUSE champ decrit mais inutilise au plan -> COMPTE, pas refuse Le troisieme point est delibere : refuser obligerait a retirer du schema un champ valide des que plus personne ne s en sert. Meme mesure que les lacunes nommees de P29. UN DEFAUT DE MON INSTRUMENT, PAYE EN ROUTE P61 comparait des noms a plat quand couverture_gui aplatit les tables imbriquees : elle criait sur un schema correct. L instrument mesurait autre chose que la cible. On aplatit desormais des deux cotes. make prouver : CONFORME, 60 OK, 0 echec, 1 saute. Prochaine etape : generer les formulaires depuis ce schema, et retirer CHAMPS_ECRITS_PAR_GUI. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q	2026-09-08 15:19:20 -04:00
Daniel Allaire	6077b179af	plan : l ecriture des registres devient atomique — tout, ou rien ... `path.open("w")` TRONQUE avant d ecrire : entre les deux, le fichier est vide. Une exception dans yaml.safe_dump, un disque plein, un Ctrl-C, et instance/plan/serveurs.yml reste mutile. L asymetrie fait la gravite : hosts.yml se regenere d un make instancier-appliquer, le PLAN ne se regenere de rien. C est la source unique de verite. Git est le filet, mais encore faut-il savoir qu on est tombe. TREIZE SITES, UNE SEULE FONCTION Le defaut n etait pas dans le GUI seul : douze sites dans sept fichiers, dont les miroirs CLI des MEMES registres. Corriger le GUI seul aurait recree la divergence que P41 garde depuis les neuf resolutions d instance. La fonction vit donc dans inventory_rules.py, que les sept importaient deja. Une source, pas douze. TROIS DETAILS QUI FONT LA DIFFERENCE ENTRE « CA MARCHE » ET « CA TIENT » temporaire dans le MEME dossier os.replace n est atomique qu au sein d un meme systeme de fichiers ; un /tmp sur une autre partition casserait la garantie sans rien dire fsync AVANT le rename sinon le renommage peut atteindre le disque avant le contenu : au retour d une coupure brutale, un fichier neuf et VIDE — le defaut qu on ferme, deplace d un cran report des droits mkstemp cree en 0600, le plan est en 0664 et doit rester lisible par le groupe sur les runners LE TEST PORTE SON PROPRE CONTROLE NEGATIF scripts/tests/test_ecriture_atomique.py rejoue D ABORD l ancienne forme et verifie qu elle DETRUIT. Sans ce controle, « le fichier est intact » ne prouverait rien — il pourrait l etre parce que rien n a ete ecrit du tout. Une garantie qu on n a jamais vue echouer n est pas une garantie, c est une habitude. Branche sur P02, dont le titre annoncait « inventory_host » alors qu il lance maintenant trois tests. Corrige au passage. LA VOUTE DU GUI : VERIFIEE, PAS DE DEFAUT Le soupcon etait qu executer_flux pose ANSIBLE_VAULT_PASSWORD_FILE (un seul mot de passe) alors que creer une VM ouvre DEUX voutes depuis « une voute, une cle ». Eprouve contre deux voutes JETABLES a mots de passe distincts — jamais les vraies. Les deux variables se CUMULENT : Ansible essaie tous les secrets, et un PASSWORD_FILE errone n empeche rien. Confirme en sondant l environnement qu une recette make recoit reellement : le mot de passe saisi ET les cinq cles calculees par voutes.py. Ce qui sauve ce chemin n est donc pas le mot de passe saisi, c est l IDENTITY_LIST que make pose par-dessus. Chacun couvre ce que l autre ne couvre pas — le PASSWORD_FILE sert le runner qui n a que sa cle, l IDENTITY_LIST le poste qui les a toutes. Ecrit au-dessus du code, pour que personne ne « simplifie » en retirant l un des deux. make prouver : CONFORME, 59 OK, 0 echec, 1 saute. make instancier : DIFF VIDE, quatre registres relus, droits 664 preserves. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q	2026-09-08 14:57:57 -04:00
Daniel Allaire	c9d31e9a60	preuves : trois gardes pour ce que ma lecture ne tiendra pas ... Une revision de documentation vieillit comme le reste. Ce qui tient, c est ce qu une machine verifie — et trois lacunes etaient nommees sans etre gardees. P58 HABILITATIONS. autorisation.md posait la regle (un service nomme un GROUPE, jamais une personne, D-66) et meta/acces.yml la portait ; rien ne la verifiait. P29 gardait les POSITIONS d authentification, personne ne gardait les DROITS. Le controle qui porte la preuve est un croisement : une entree porte_par: role-realm affirme que l habilitation voyage par un role de realm projete depuis un groupe LDAP. P58 le confronte a serveur_keycloak. Sans ca, un service annonce une habilitation que rien ne transporte, et l ecran reste vide sans que personne sache pourquoi. CE QU ELLE N EXIGE PAS, et c est le point le plus important : que les groupes nommes existent dans l annuaire. Ce serait contredire le regime du paragraphe 2 — le depot AMORCE un acces et se retire, les appartenances appartiennent a une personne. dev et personnel n existent dans aucun code, et ce n est pas un defaut. P59 ENUMERATIONS ANNONCEES. Les deux ecarts trouves a la main pendant la tournee — cinq portes annoncees devant une table de six, huit lignes renvoyees vers une fiche qui en compte dix — etaient d une forme que P57 ne voit pas. Ma premiere version a signale CINQ ecarts, et les cinq etaient du bruit : dans « reprise dans les deux devis : », le nombre qualifie autre chose que la liste. Cent pour cent de faux positifs — la preuve qui crie sur un cas sain et qu on apprend a ignorer. Resserree aux deux formes ou le nombre ne peut compter rien d autre. Etroite et vraie plutot que large et devineuse. P60 WIKI PUBLIE. Le wiki est publie DEPUIS le depot ; rien ne mesurait l ecart, et il s est creuse de VINGT-SEPT JOURS en silence. Deux unites jamais publiees, vingt et une differentes : pour qui lit la forge plutot que le depot, toute la revision n existait pas. Le harnais est STATIQUE, zero appel reseau — cloner la forge romprait la seule propriete qui fasse qu une preuve vaille hors de ce poste. La mesure passe donc par un TEMOIN que make wiki-publier depose. Amorce avec la valeur MESUREE : le wiki d eregion porte b6167f2, dont le message dit source: ac85278. Ce qu elle ne prouve pas : un temoin dit ce qui est PARTI, jamais ce qui est ARRIVE. LES TROIS SONT EPROUVEES DANS LES DEUX SENS Douze essais negatifs, douze refus : groupe non projete, acces.yml disparu, personne au lieu d un groupe, mecanisme invente, raison manquante, compte revenu a cinq, septieme porte ajoutee sans toucher au compte, renvoi croise fausse, temoin absent, temoin d un autre depot. Une garantie qu on n a jamais vu dire non n est pas une garantie, c est une habitude. ETAT : NON CONFORME, 58 OK, 1 echec, 1 saute. P60 est rouge, et c est le comportement voulu : le registre a le droit de perdre. Le retard qu elle signale est reel et anterieur a elle. Une commande le ferme, et elle vient ensuite. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q	2026-09-08 12:47:18 -04:00
Daniel Allaire	5bc3bceac1	documentation : la tournee des 74 documents, parce qu un balayage ne lit pas ... La revision a commence par un balayage par motifs — chemins morts, cibles make absentes, comptes derives. Il a trouve une trentaine d ecarts et rate presque tout le reste : un motif ne voit que ce qui s exprime en motif. make hote-planifier en est l exemple. La cible EXISTE, donc le controle passait au vert. C est une cible depreciee qui refuse et sort en 2, recommandee par AGENTS.md, et qui contredit la REGLE D OR du meme fichier trois ecrans plus haut. Il fallait lire pour la voir. 74 documents lus un par un. 66 corriges, 8 exacts. CE QUI ETAIT FRANCHEMENT FAUX AGENTS.md, la source d autorite, annoncait la flotte pas encore executee contre des VM reelles. Elle a ete rasee et remontee depuis zero trois fois. ecosysteme-chezlepro.md, le document montre a un client, portait la meme phrase : il se sous-vendait gravement. courriel-conception.md s ouvrait sur aucun role n est encore ecrit, au-dessus de son propre paragraphe 1 qui les nomme. autorisation.md se terminait sur rien n est construit alors qu il rapporte des mesures datees du role en fonctionnement. hebergeur-exploitation.md disait rien n est fait d un depot qui existe. filiation-emancipation.md se contredisait a deux ecrans de distance. DES MODELES DECRITS D APRES UN MONDE ANTERIEUR Le resolveur : cinq documents decrivaient un Unbound par VM en opt-in, trois le donnaient en exemple d integration FACULTATIVE — il est universel depuis le 2026-08-24. L adressage de nomenclature-vm.md : reseau unique, VLAN 11-15, VMID a cinq chiffres. Le nommage SDN de sdn-evpn.md contre le code : c est le wiki qui avait raison. CE QUI CASSE AU PREMIER ESSAI Le nom du gabarit dore etait faux a quatre endroits, dont la procedure qui le FABRIQUE et le critere R2 de l epreuve d operateur independant. preparer-un-site-hebergeur.md avertissait qu une VM faite a la main serait detruite : raser derive du plan, il ne la detruira jamais — le risque est l inverse. Un mot de passe d essai en clair dans un depot public. DEUX PREUVES ETENDUES, ET UNE QUI SE TROMPAIT ELLE-MEME P57 couvre les groupes : elle a signale aussitot 29 groupes annonces au-dessus d un tableau qui en cite 40. P29 confronte le tableau de authentification.md aux declarations reelles : 12 annonces, 21 reels. Et P57 imposait un chiffre faux — 56 preuves alors que le depot en porte 57, la conditionnelle vivant hors de tout comptage. Un garde-fou qui fait respecter une erreur ajoute l assurance a l erreur. CE QUI RESTE, ET QU AUCUNE PREUVE NE TIENT Deux comptes trouves a la main. Et une lacune reelle : rien ne garde les meta/acces.yml — ni qu un service web-sso en porte un, ni que le groupe qu il nomme existe. P29 tient les positions d authentification, personne ne tient les habilitations. make prouver : CONFORME, 56 OK, 0 echec, 1 saute. 0 lien mort. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q	2026-09-06 16:18:23 -04:00
Daniel Allaire	cf9abe74b6	sauvegarde : le site protege enfin son propre etat ... L hebergeur protegeait l etat de tous ses locataires et pas le sien. Deux choses qu il detient et que personne ne peut regenerer : la racine de son AC, et la forge du genome. Le reste est reconstructible par le code. Preuve faite, pas annoncee : sauvegarde reelle puis restic check et restitution. 13 fichiers pour l AC (root_ca_key et intermediate_ca_key compris), 835 pour la forge. Le site depose avec SON identite, sur le compte restic que serveur_backup lui cree, separe des comptes des locataires par les memes permissions. La cible est derivee du expose de l application qui porte serveur_backup_site : le nom du service, pas une adresse — client_backup_repo la grave dans le chemin de chaque instantane. P36 ne lisait que le plan de l instance montee, donc jamais celui du site — qui detient pourtant le plus. Elle lit desormais les deux. Verifiee en la faisant echouer : integration retiree, la preuve tire. Reste ouvert : personne ne verifie les sauvegardes du site. Le depot tourne avec verification_locale a false (pose pour les locataires, dont il ne peut pas ouvrir les depots) et le site n a pas de supervision. La sauvegarde existe et se restaure ; c est son SILENCE qui n alerte pas encore. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019f91zs9SDdwSzL2CVei6on	2026-09-02 11:21:52 -04:00
Daniel Allaire	2f2323bd3e	gabarit : minimal — il etait un cache du socle, et il perimait sans le dire ... Il portait DIX-SEPT roles : exactement ceux du socle et du durcissement, que le deploiement rejoue a l identique. C etait donc un CACHE — et comme tout cache, il perimait sans le dire. MESURE : derniere recapture le 2026-08-09, et SIX de ses roles avaient change depuis — common_packages, cloud_init, ssh_baseline, ssh_hardening, auditd, nftables_baseline. Rien ne le signalait : le deploiement masquait la derive en reappliquant tout, donc personne ne pouvait la voir. Aucune preuve du harnais ne regardait sa fraicheur. IL NE GARDE QUE CE QUI DOIT EXISTER AVANT QU ANSIBLE PUISSE AGIR : qemu_guest_agent l agent repond AVANT SSH — P52 s en sert cloud_init le seul chemin vers la premiere seconde sudo_ansible la porte par ou tout entre ssh_baseline le serveur SSH Ce ne sont pas des choix d efficacite, ce sont des conditions d existence. CE QUE CA COUTE, ET QUI EST COUVERT : une VM neuve n est plus durcie a la naissance. Elle nait cependant DERRIERE LE PARE-FEU DE L HYPERVISEUR, policy_in=REJECT arme au clonage — verifie sur obs-01. La fenetre d exposition est fermee par la fabric, pas par le gabarit. Mon objection initiale tombait devant la mesure. P56 GARDE LES DEUX MOITIES. Qu il ne REGROSSISSE pas : un role ajoute recree le cache, donc la peremption invisible. Et que rien de retire ne soit PERDU : un role absent du gabarit ET du socle disparaitrait de toutes les machines neuves, sans erreur ni trace, et la panne arriverait des mois plus tard sur une machine qu on croyait durcie. Verifie : 14 retires, 14 repris, zero orphelin. Deux controles negatifs. make verifier : vert. make prouver : CONFORME, 56 OK, 0 echec. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019f91zs9SDdwSzL2CVei6on	2026-09-01 10:35:20 -04:00
Daniel Allaire	bb63865a37	cles : le terrain etait inoccupable — la cle du tenant nait avec ses machines ... Le deploiement lance depuis ops-01 s est arrete au premier geste, sur les quinze machines a la fois : Permission denied (publickey). Les VM neuves n acceptaient que la cle de l exploitant. Celle du runner EST declaree au plan, mais c est le SOCLE qui la depose — et le socle doit etre applique par quelqu un qui peut deja entrer. Boucle fermee : le tenant recevait un terrain qu il ne pouvait pas occuper. DEUX CLES, DEUX PORTEES : la cle du SITE -> sur le SEUL runner du tenant l insemination la cle du TENANT -> sur TOUTES ses machines il va les configurer POSER UNE CLE AU CLONAGE N EST PAS ENTRER CHEZ LE TENANT. C est un parametre de creation, au meme titre que l adresse ou le disque : le site ecrit les conditions de NAISSANCE, il n ouvre aucune session. Le site n obtient aucun acces sur ces machines ; seul le runner du tenant en obtient un. Forme tranchee par l exploitant : le site renseigne le seul runner, qui se charge de toute sa flotte. Le plancher /etc/hosts suit le meme chemin — ops-01 a le sien depuis son insemination et resout ses quinze voisines par leur nom. LA REVOCATION EST HONOREE A LA NAISSANCE : une entree a etat absent n est pas reposee. Sans cette lecture, une cle retiree de la flotte serait ressuscitee sur chaque VM creee ensuite — panne lente, silencieuse, invisible au plan. P55 garde les deux moities : la cle du site ne nait que sur un porteur de serveur_ops_tenant, et aucune machine ne reste sans celle de son tenant. Une frontiere tenue a une seule couche n est pas tenue. Deux controles negatifs. make verifier : vert. make prouver : CONFORME, 55 OK, 0 echec, 0 saute. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019f91zs9SDdwSzL2CVei6on	2026-08-30 08:54:17 -04:00
Daniel Allaire	90ea474745	inseminer : le geste sort de mes mains et entre dans le depot ... L insemination avait ete conduite A LA MAIN depuis le runner du site — hors du depot, donc sans preuve. Elle a maintenant sa cible : make inseminer TENANT=OPS-Chezlepro TENANT= PLUTOT QUE LE SYMLINK instance : le runner du SITE amorce PLUSIEURS locataires ; pointer un lien global sur l un d eux le ferait se prendre pour ce tenant. Il en NOMME un par commande. Ca borne aussi le couplage que creer-vm imposait en silence — rien ne disait sur quels tenants ce lien pouvait pointer. L HOTE SE DERIVE : celui qui porte serveur_ops_tenant. Meme critere que le flux d insemination et que la cle SSH du runner — le meme mot borne les trois pouvoirs. P54 GARDE LA LIGNE DE PARTAGE la ou elle glisserait sans bruit. Les deux couches retenues sont les seules qui ne reclament aucun secret. Le jour ou l on en ajouterait une, le deploiement echouerait chez le tenant sur une valeur vide, et ce message ne dirait pas qu un POUVOIR a ete franchi. Controle negatif : ajouter client_pki, la couche suivante, fait echouer la preuve. UN GARDE-FOU EXISTANT A INTERCEPTE UNE INSEMINATION MAL DIRIGEE. Le make parent exporte SETOPS_INVENTAIRE ; ma resolution en heritait et visait l inventaire d un AUTRE ecosysteme. Le refus vient d inventory_rules, pas de la cible — exactement l erreur qu un runner servant plusieurs locataires commettrait en silence. make verifier : vert. make prouver : CONFORME, 54 OK, 0 echec, 0 saute. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019f91zs9SDdwSzL2CVei6on	2026-08-28 17:14:37 -04:00
Daniel Allaire	4beb7e0724	flux : l interne refuse a voix haute, la bordure se tait (P53) ... Decision de l exploitant : block vers l Internet, reject a l interieur, parce que c est prudent. Ce n est pas le refus qui informe, c est CE QU IL FAIT AU SILENCE : sous drop partout, un timeout voulait dire aucune machine, aucune route, ou une politique. Quand la politique parle, il n en reste qu une. nftables par hote policy drop + reject with icmpx type admin-prohibited pare-feu Proxmox policy_in = REJECT (POLITIQUE_VM, source unique) frontiere OPNsense block — INCHANGE, et c est la condition admin-prohibited ET NON tcp reset : un RST est indiscernable d un port ferme sans service. La chaine forward reste muette : elle porte le trafic qui TRAVERSE l hote, et y repondre ferait parler cette machine au nom d une destination qui n est pas elle. POURQUOI C EST PRUDENT : l obscurite etait deja nulle a l interieur (chaque machine porte un /etc/hosts qui liste ses voisines), et la bordure protege le reject — rien d indeclare ne franchit le perimetre, donc il ne repond jamais a l Internet. 982 000 entrees par jour a la frontiere, dont 82 % un balayage VNC. LA MESURE A CORRIGE LA MESURE, DEUX FOIS. Ma preuve interdisait le litteral DROP et a fait echouer un code JUSTE : la detection d une politique posee AU DATACENTER, qui est un garde-fou. Une preuve qui interdit un mot au lieu de mesurer une propriete finit par accuser ce qu elle devrait proteger. Et l absence parlait deja : EHOSTUNREACH en 3,05 s pour une machine inexistante, timeout a 6 s pour un refus de la frontiere. Mes deux erreurs de diagnostic ne venaient pas du drop mais de ma SONDE — curl et bash /dev/tcp ecrasent les deux dans un meme echec. Applique : 6 VM en REJECT, 0 creee, 0 retiree. Rien ne se ferme. Trois controles negatifs verifies. make verifier : vert. make prouver : CONFORME, 53 OK, 0 echec, 0 saute. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019f91zs9SDdwSzL2CVei6on	2026-08-28 16:43:22 -04:00
Daniel Allaire	377462b141	voutes : une voute, une cle — separer avant de distribuer ... Decision de l'exploitant : chaque runner est maitre de sa voute et en detient la cle. C'est ce qui rend un runner autonome, donc ce qui rend l'emancipation atteignable. Elle exigeait un prealable, mesure ce matin : UN SEUL mot de passe ouvrait les SIX voutes de la flotte, celle de la fabric comprise. DISTRIBUER AVANT DE SEPARER AURAIT ETE PIRE QUE LE STATU QUO : poser « la » cle sur chaque runner rendait chaque runner capable d'ouvrir les autres. Compromettre le plus petit locataire donnait les secrets de l'hebergeur. Cinq cles, une par ecosysteme, sous ~/.config/setops-vault-<depot>. Verification croisee apres rechiffrement : la diagonale, et rien qu'elle. L'ancienne cle maitresse n'ouvre plus aucune des six. UN SEUL MOT DE PASSE NE POUVAIT PLUS SUFFIRE, et pas pour la raison qu'on croit : `cloner_vm_debian.yml` charge la voute du TENANT puis celle de l'UNDERLAY dans la meme execution. `ANSIBLE_VAULT_IDENTITY_LIST` en porte plusieurs et les essaie toutes — un seul export suffit pour les 28 appels a ansible-playbook, sans en toucher un seul. La liste se derive dans scripts/voutes.py. CE QUI BORNE LE POUVOIR N'EST PAS LA LISTE MAIS LA PRESENCE DES FICHIERS. Sur le poste, toutes les cles sont la — c'est l'humain qui les detient toutes, et P03 lit les inventaires de tous les freres. Sur un runner, une seule existe. Le code est identique, le pouvoir ne l'est pas. DEUX PREUVES ONT DIT CE QUI MANQUAIT. P03 est tombee des la separation : elle lit les inventaires voisins, donc il lui faut leurs cles — c'est elle qui a etabli que la liste devait couvrir le voisinage. P16 s'est mise a SAUTER : sa garde ne connaissait que ANSIBLE_VAULT_PASSWORD_FILE. Une preuve sautee se lit trop facilement comme une preuve passee. COUT ASSUME : le chiffre et sa cle cohabiteront sur la meme machine des que les runners recevront la leur. Le pari tient parce que le perimetre est borne. Les six voutes sauvegardees avant rechiffrement. L'ancienne cle maitresse reste sur le poste : la retirer est une decision, pas un nettoyage. make verifier : vert. make prouver : CONFORME, 52 OK, 0 echec, 0 saute — sans ANSIBLE_VAULT_PASSWORD_FILE. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019f91zs9SDdwSzL2CVei6on	2026-08-28 14:23:33 -04:00
Daniel Allaire	6fe62f74e1	creer-vm : prouver la materialisation sans entrer chez le tenant ... `creer-vm` confirmait son succes en attendant une reponse SSH. Le runner du SITE materialise le terrain de TOUS les tenants, mais la frontiere lui refuse d'entrer chez eux — c'est le sens meme de leur isolation. La premiere VM qu'il a creee a donc ete declaree en echec apres 600 secondes alors qu'elle tournait, avec l'adresse exacte que le plan lui destinait : Attente de SSH sur ops-01 ............ ECHEC: injoignable apres 600s. LA TENTATION ETAIT D'OUVRIR LE SSH du runner vers tous les tenants. Ca aurait repare la mesure en detruisant ce qu'elle protege : une machine capable d'entrer chez chaque locataire est precisement ce que cette architecture refuse d'avoir. L'agent invite repond sans rien ouvrir — l'API des hyperviseurs est deja le flux par lequel la VM vient d'etre creee, donc qui peut la creer peut la voir naitre — et il PROUVE DAVANTAGE. « Quelque chose ecoute sur le port 22 » ne dit ni quel systeme a demarre, ni si cloud-init a pose la bonne adresse. Sur ops-01 : 10.17.19.41 portee sur asgard — Debian GNU/Linux 13 (trixie) 6.12.101 Ses echecs distinguent deux causes tres differentes : « la machine demarre mais rapporte une AUTRE adresse — cloud-init, ou le pont sur lequel elle est posee », et « introuvable sur la fabric ». ATTENDRE LA DISPONIBILITE A CHANGE DE MAIN. Guetter cloud-init et la liberation de dpkg appartient a qui va CONFIGURER : `deployer` le fait desormais, la ou il se contentait d'un `ping` unique. Il y gagne ce qu'il n'avait pas — attendre le verrou APT, faute de quoi la premiere couche echouait dessus. Contrepartie assumee : un nom d'hote errone patiente au lieu d'echouer vite ; echouer vite interdirait de chainer creation et deploiement, le geste central d'une reconstruction. P52 garde le couplage ferme. Deux controles negatifs verifies. make prouver : CONFORME, 52 OK, 0 echec. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-27 22:48:49 -04:00
Daniel Allaire	5d0f82792a	portabilite : declarer ce dont le moteur depend — quatre defauts reveles par le runner ... Premiere materialisation d'une VM de tenant depuis le runner du SITE. Elle a echoue quatre fois d'affilee, sur quatre dependances que le moteur ne declarait nulle part. Chacune fonctionnait chez le mainteneur pour une raison DIFFERENTE, et aucune de ces raisons n'existe sur une autre machine. 1. VERSIONS DES COLLECTIONS. `requirements.yml` les nommait sans les epingler. Le runner a recu `community.general` 13.3.0 quand le poste porte la 10.3.0 — et la 11 a retire les modules Proxmox de cette collection. ERROR! couldn't resolve module/action 'community.general.proxmox_pool' 2. INSTALLATION EN AVANT. `ansible-galaxy` ne retrograde pas : declarer la 10.3.0 ne suffisait pas a defaire une 13.3.0 deja posee. `--force`. 3. EMPLACEMENT. Le `Makefile` pose `ANSIBLE_HOME ?= $(CURDIR)/.ansible` : sous `make`, Ansible ne lit QUE `<moteur>/.ansible/collections`. Le role deposait dans `<racine>/.ansible/collections` — a cote, jamais lu. Invisible chez le mainteneur, ou les collections viennent du paquet systeme, toujours dans le chemin quel que soit ANSIBLE_HOME. Et le garde-fou d'installation suivait le DEPOT des archives : changer la destination ne le declenchait pas. Il mesure desormais la destination — meme piege qu'en 2026-08-24, deplace d'un cran. 4. BIBLIOTHEQUES PYTHON. Le venv recevait `ansible-core` et `pyyaml`, ecrits en dur. Les modules Proxmox tournent `delegate_to: localhost` et exigent `proxmoxer` SUR LE CONTROLEUR. La bibliotheque Python proxmoxer est absente Ne d'ici : `requirements-python.txt`, avec sa frontiere ecrite — il ne declare QUE ce qui tourne sur le controleur. `python-ldap` et `psycopg2` s'executent sur leurs cibles ; le poste du mainteneur ne les a pas et la flotte se deploie, ce qui prouve que la ligne est au bon endroit. P51 garde les trois faiblesses de cette famille : une dependance utilisee sans etre declaree (le defaut du 2026-08-24, `ansible.posix`), une dependance declaree sans version, et `proxmoxer` absent alors que des playbooks Proxmox existent. Quatre controles negatifs verifies. RESULTAT : ops-01 materialisee par le runner du site. L'agent invite rapporte `eth0 10.17.19.41/24`, Debian 13 trixie — l'adressage derive du plan, applique. Un seul executant masque ces ecarts indefiniment ; un second les revele tous en une soiree. Meme mecanique que le second tenant en aout. make prouver : CONFORME, 51 OK, 0 echec. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-27 22:38:35 -04:00
Daniel Allaire	3fa6e4c3e1	collections : epingler les versions — le runner echouait la ou le poste reussissait ... Premiere materialisation de VM depuis le runner du SITE : ERROR! couldn't resolve module/action 'community.general.proxmox_pool' Meme depot, meme playbook, meme plan que chez le mainteneur. La difference tenait a une seule chose que le moteur ne disait pas : la VERSION de ses collections. Le poste porte `community.general` 10.3.0. Le runner, monte un jour plus tard, a recu la 13.3.0 — et la version 11 a RETIRE les modules Proxmox de cette collection (ils vivent desormais dans `community.proxmox`). `requirements.yml` nommait ses collections sans dire lesquelles : chaque machine installait donc ce qui etait courant le jour de son montage. Une dependance non epinglee n'est pas une dependance, c'est un pari sur l'etat d'Internet a la date du deploiement. TROIS CORRECTIONS. `requirements.yml` epingle les trois collections aux versions eprouvees. `serveur_ops` installe avec `--force`. Sans lui, ansible-galaxy laisse en place une version SUPERIEURE a celle demandee : il ne retrograde pas. Un poste peut etre en avance, pas seulement en retard, et le depot doit faire autorite dans les deux sens. P51 garde les deux faiblesses de ce fichier — celle du 2026-08-24, une collection utilisee sans etre declaree (`ansible.posix`), et celle d'aujourd'hui, declaree sans version. La preuve ne lit que les fichiers de TACHES : un `defaults/main.yml` porte `net.ipv4.ip_forward`, qu'un motif trop large prend pour un module. MIGRATION CONNUE, PAS FAITE : passer les quatre modules Proxmox a `community.proxmox` permettra de suivre `community.general` au-dela de la 11. make prouver : CONFORME, 51 OK, 0 echec. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-27 18:58:23 -04:00
Daniel Allaire	3b65384b0f	frontiere : le devis sait desormais refuser SANS consigner ... L'outil ne savait qu'AUTORISER — `"action": "pass"` etait en dur dans l'emetteur. Une regle de silence ne pouvait donc pas naitre du depot, et j'en avais pose deux a la main sur le boitier : exactement ce que ce projet refuse. CE QUI L'A MOTIVE. Le journal de la frontiere ecrivait 982 000 entrees par jour, dont 82 % un balayage Internet contre le port VNC et le reste du bavardage de decouverte du reseau local. Sa fenetre utile etait tombee a QUARANTE-QUATRE SECONDES. J'y ai cherche la trace d'un flux du site vers les hyperviseurs, je n'ai rien trouve, et j'en ai conclu a tort qu'aucune regle ne bloquait. Un journal noye ment aussi surement qu'un journal mort. Mesure apres declaration : ~20 700/jour. Une regle de silence ne change AUCUN comportement : ce qu'elle vise etait deja refuse par le defaut. Elle ne supprime qu'une trace que personne ne lira. TROIS PIECES. `cle_regle` accepte une action sans changer d'un octet la cle des regles `pass` deja posees. L'ajout naif d'un champ les aurait toutes detruites pour les recreer a l'identique, sur la frontiere, en production. Le plan l'a confirme : 7 a creer, 0 a retirer, 121 inchangees. `_corps_regle` lit l'action, la consignation et la SEQUENCE depuis le devis. La sequence est ce qui rend un `block` sur : OPNsense evalue en `quick`, donc un blocage large emis avant les `pass` fermerait courrier, web et acces distant. `devis_opnsense` lit `opnsense_silences` et en fabrique regles et alias, motif compris — une regle `block` muette sans raison ecrite est indiscernable d'un oubli. P50 garde ces deux dangers. Controles negatifs verifies : un silence en sequence 1 echoue, un silence sans motif echoue. Carte : 28 pieces d'audit (P48 l'avait vu juste). make prouver : CONFORME, 50 OK, 0 echec. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-27 18:10:39 -04:00
Daniel Allaire	561c034eb4	flux : P49 — le registre des flux avait derive sans bruit ... `docs/registre-flux.md` est GENERE depuis les `roles/*/meta/flux.yml`, et c'est le document qu'un humain lit pour savoir ce que le pare-feu laisse passer. Son EXISTENCE etait verifiee depuis longtemps ; sa FRAICHEUR ne l'etait pas. Il avait derive : la garde d'administration y portait encore `10.0.0.0/24` alors que le reseau d'administration vaut `10.17.0.0/24`, deux flux `client_resolveur` ajoutes depuis n'y figuraient pas, et un hote manquait des listes de sources. Un lecteur y aurait lu un pare-feu qui n'existe plus. L'inventaire avait deja sa garde — P03, le diff-vide du plan. Le registre des flux est le meme genre d'artefact : genere, versionne, lu par un humain. Il lui manquait la meme. `generer_registre` etant une fonction PURE, P49 la rejoue en memoire et compare — une preuve qui repare ce qu'elle mesure ne mesure plus rien. Controle negatif ideal, et il ne s'invente pas : la version commitee elle-meme. Restauree, la preuve echoue ; regeneree, elle passe. CE QUE CETTE DECOUVERTE CORRIGE AUSSI DANS MA TETE. J'avais decrit le symptome comme « le runner salit ses propres clones » — une contradiction structurelle entre un depot-clone et un repertoire de travail. C'etait faux, et la question de l'exploitant l'a mis au jour. Regenerer un artefact DOIT produire un diff quand les sources ont change ; ce qui manquait n'etait pas une architecture, c'etait une garde. Un symptome observe depuis un seul endroit ressemble toujours a une propriete de cet endroit. Ce commit emporte aussi la regeneration elle-meme : le registre du moteur, et les quatorze fichiers nftables de Chezlepro, remis en accord avec leurs sources. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 16:58:17 -04:00
Daniel Allaire	9e8679215d	carte : P48 — l'index du mainteneur ne peut plus mentir ... `docs/carte-set-ops.md` est l'index du MAINTENEUR : l'ordre de lecture du corpus, et surtout le catalogue des MECANISMES TRANSVERSES avec, pour chacun, OU IL VIT DANS LE CODE. Son but est ecrit en toutes lettres : « ne plus re-deterrer ce qui existe ». Elle n'avait aucune garde, alors que `catalogue-services.md` a la sienne depuis P38. Ses sept chiffres etaient faux — 54 roles annonces contre 60, 34 documents contre 38, 15 pieces d'audit contre 27, 70 decisions contre 78. Le defaut couteux n'est pourtant pas la. C'est le POINTEUR MORT : la carte dit ou vit un mecanisme, quelqu'un ne l'y trouve pas, et le reimplemente a cote — exactement la panne qu'elle existe pour prevenir. Aucun de ces nombres ne fait travailler personne ; mais un document dont les faits verifiables sont faux cesse d'etre consulte, et c'est alors ses pointeurs qu'on perd. P48 verifie les deux : 84 chemins cites existent, et 7 chiffres correspondent a la mesure. Controle negatif verifie sur les DEUX moities — un chiffre fausse, un pointeur casse, la preuve echoue dans les deux cas. QUATRE DISTINCTIONS ont du etre ecrites pour qu'elle ne soit pas fausse dans l'autre sens : un gabarit de nom (`preuve-<date>.md`) decrit une forme, pas un fichier ; un chemin hors depot (`~/.config/setops-vault-pass`) vit sur le poste de l'exploitant, et c'est tout l'interet de la doctrine des voutes ; un fragment (`meta/acces.yml`) vaut comme SUFFIXE, parce qu'un index se lit ainsi ; et un artefact GENERE (`hosts.yml`) n'a pas a exister dans le moteur. Les quatre sont nommees dans le code plutot que sautees en silence. Le tableau « Le depot en chiffres » remplace les comptes en prose : ce qu'on n'entretient pas, on ne l'affirme pas — ou bien on le fait recompter. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 13:56:58 -04:00
Daniel Allaire	e5841ea684	dns : quatre zones inverses pour le site, et rien de plus ... Le site ne servait aucun PTR. `serveur_powerdns_zone_inverse` derivait d'un supernet /16 — la forme d'un TENANT, qui tire tout de son index. Un site ne derive pas : il declare plusieurs /24 et n'a pas de supernet unique, si bien que la derivation rendait une chaine vide et qu'aucune zone n'etait generee. Le site revendique desormais exactement ce qu'il occupe : 31.0.10.in-addr.arpa 32.0.10.in-addr.arpa 33.0.10.in-addr.arpa 34.0.10.in-addr.arpa Revendiquer `0.10.in-addr.arpa` d'un seul geste aurait ete plus simple et faux : cette zone couvre aussi la frontiere, le transit et les hyperviseurs, qui ne sont pas a lui. Une autorite qu'on s'attribue sans l'exercer est une panne differee — le resolveur repondrait NXDOMAIN pour des adresses qu'un autre sait nommer. LA DERIVATION VIT DANS UN FILTRE (`zones_inverses`) parce qu'elle a DEUX appelants : `serveur_powerdns` ecrit ces zones, `serveur_resolveur` les delegue a l'autoritatif. Deux calculs separes finiraient par diverger, et la divergence ne se verrait qu'au premier PTR interroge. Le nom d'une zone dit sa profondeur — trois etiquettes numeriques valent un /24, deux valent un /16 — et le modele en deduit seul la forme du PTR. DEUX CHEMINS MORTS TROUVES EN ROUTE. Les zones etaient servies, et personne ne les demandait. `serveur_resolveur` deleguait la zone directe par une `stub-zone` mais pas les inverses : `dig -x` rendait vide depuis les cinq machines alors que la meme requete posee directement a l'autoritatif repondait juste. Un service correct derriere un chemin que rien n'emprunte. Puis, les stubs poses, Unbound repondait toujours NXDOMAIN avec le drapeau `aa` — une reponse AUTORITAIRE, sans jamais consulter le stub. Il embarque des `local-zone` pour tout l'espace RFC1918 inverse. `nodefault` n'y change rien : ce mode n'agit que si le nom correspond EXACTEMENT a une zone par defaut, et la sienne est `10.in-addr.arpa`, le /8 entier. C'est `transparent` qui laisse la requete suivre son cours — pour nos quatre zones seulement, la ou `unblock-lan-zones` aurait ouvert tout l'espace prive. Rien ne distinguait ce blocage d'une absence : le meme NXDOMAIN qu'un nom qui n'existe pas. AUSSI : les zones inverses sont desormais validees par `named-checkzone` comme la directe (un fichier mal forme etait refuse en silence par PowerDNS), et une zone qu'un ecosysteme cesse de revendiquer est retiree du repertoire. VERIFICATION. Les cinq PTR resolvent depuis les cinq hotes par le resolveur, les huit noms directs par le plancher ET par le DNS, et les deux roles sont idempotents (changed=0). P47 evalue la derivation sur cinq cas — un site a quatre zones, un tenant a une, deux machines d'un meme /24 qui n'en font qu'une, aucune adresse, une adresse illisible. Controle negatif verifie. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-25 20:58:50 -04:00
Daniel Allaire	a74e35bf21	site : le plancher survit au redemarrage, et la zone dit les vraies adresses ... Le decoupage du site en quatre zones a deplace cinq machines. Ni le plancher /etc/hosts ni la zone DNS n'avaient suivi. Quatre defauts, tous dans le moteur. LE PLANCHER ETAIT EFFACE A CHAQUE DEMARRAGE — ET LE PREMIER CORRECTIF N'EN ETAIT PAS UN. `hosts_statiques` posait `99-setops-hosts.cfg` avec `manage_etc_hosts: false`, pendant que `cloud_init` posait `99_setops.cfg` avec `true`. Dans `cloud.cfg.d` l'ordre est LEXICAL et le dernier gagne : `-` vaut 0x2D, `_` vaut 0x5F. On a donc retire la cle de `cloud_init` — le role qui POSSEDE le fichier decide — puis renomme notre fragment `zz-` pour passer apres le `99_chezlepro.cfg` du gabarit dore. Et ca ne suffisait toujours pas. Redemarrage d'epreuve : plancher encore efface. La cause reelle est ailleurs — Proxmox inscrit `manage_etc_hosts: true` dans la USER-DATA de son lecteur cloud-init, et la user-data prime sur `cloud.cfg.d` tout entier. Aucun fragment ne pouvait gagner ; renommer pour parler en dernier ne servait a rien, le dernier mot n'appartenant pas a ce repertoire. Ce que cloud-init regenere, il le regenere depuis `hosts.debian.tmpl` — le gabarit le documente lui-meme. `hosts_statiques` le pose desormais avec le MEME contenu que /etc/hosts, et une garde compare les deux a chaque passage. Redemarrage d'epreuve : les neuf entrees sont la. La garde precedente affirmait « conforme » en mesurant l'ordre lexical — vrai, et sans rapport avec ce qui se passait. Une garde qui mesure la mauvaise chose est pire qu'aucune. LA ZONE DNS NE PUBLIAIT PAS LES NOMS DE SERVICE. `forge.genese.internal` et `pki.genese.internal` — des noms que les certificats portent et que les clients appellent — n'avaient aucun enregistrement. Seul le plancher savait les resoudre. Trois causes empilees : - le plan du site coupait `serveur_powerdns_publier_expositions`, au motif que « le site n'a pas d'edge » : ca confondait PUBLIC et EXPOSE ; - `expositions_des_applications` rendait `domaine: None` faute de `domaines.yml`, et le modele de zone ecarte les expositions dont le domaine n'est pas la zone. Repli ajoute, symetrique de celui deja ecrit pour `edge` : sans domaine public declare, le domaine est celui que porte le FQDN ; - `serveur_powerdns` exigeait les deux registres et echouait si `domaines.yml` manquait — le meme tout-ou-rien que `hosts_statiques` a corrige le meme jour. Puis `named-checkzone` a refuse la zone : `dns.genese.internal` heritait d'un CNAME par defaut du role ET d'un A par exposition. La garde a bien joue son role — elle a arrete une zone cassee avant qu'elle soit servie. Le plan l'emporte desormais sur le defaut du role. Un service ne doit pas dependre d'un plancher pour etre joignable : le plancher est un filet, pas le sol. VERIFICATION. Les huit noms — cinq machines, trois services — resolvent vers les bonnes adresses depuis les cinq hotes, par le plancher ET par le DNS, et le plancher survit au redemarrage. P46 refuse desormais deux choses : plus d'un role ecrivant `manage_etc_hosts`, et l'absence du gabarit maitre. Controle negatif verifie. RESTE NOMME, PAS CORRIGE : la zone INVERSE. `serveur_powerdns_zone_inverse` derive d'un supernet /16 — la forme d'un tenant. Un site declare plusieurs /24 et n'a pas de supernet unique : aucune zone inverse n'est generee. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-25 20:31:01 -04:00
Daniel Allaire	ac48b7650b	proxmox : le pare-feu ne s'arme que dans le SDN — et 45e preuve ... Le decoupage du site en quatre zones a revele un defaut qui dormait dans le moteur. `firewall=1` sur l'interface d'une VM fait passer tout le trafic ponte par conntrack. Sur un VNet SDN c'est sans consequence : en EVPN le routage inter-VNet se fait dans le VRF, SUR LE NOEUD, et le flux ne quitte jamais l'hyperviseur. Sur un pont classique route par une frontiere externe, deux VM du MEME noeud dans deux VLAN differents ne se parlent qu'en EPINGLE : la trame sort par le lien physique, la frontiere la route, elle revient sur le meme pont. La meme table conntrack voit alors les deux moities de la connexion, classe le retour INVALID, et PVEFW-FORWARD le jette. La mesure a tranche : ops(asgard) -> pki(asgard) 0/8 dns(gandalf) -> cache(gandalf) 0/8 ops(asgard) -> forge(vishnu) 6/8 dns(gandalf) -> pki(asgard) 6/8 ops(asgard) -> cache(gandalf) 8/8 dns(gandalf) -> forge(vishnu) 8/8 Toutes les paires intra-noeud echouent, toutes les paires inter-noeuds passent. Douze tentatives faisaient monter le compteur `ctstate INVALID` de +112 sur asgard et +116 sur gandalf ; `firewall=0` pose, il ne bouge plus — 0 sur les deux, pour le meme trafic. Le defaut se deguise en panne reseau : la poignee TCP ABOUTIT, et ce sont les paquets de DONNEES qui disparaissent. L'AC le disait dans son propre journal (`TLS handshake error ... i/o timeout` : elle accepte et attend un ClientHello qui n'arrive jamais). Ecartes un par un, par la mesure : regles identiques champ par champ, alias corrects, assignation des interfaces confirmee, ARP et routes saines, IPS desactive, shaper vide, NAT source limite a `wan`, MTU a 1500 de bout en bout — et la taille sans effet, 100 octets se perdant comme 1460. L'INTENTION DECLAREE NE SUFFIT PAS : un tenant declare `proxmox_clone_parefeu_interface: true` avec `proxmox_clone_pont: vmbr1` comme valeur PAR DEFAUT, chaque hote la remplacant par son VNet derive. L'hote qui retombe sur `vmbr1` naitrait arme sur un pont classique. `cloner_vm_debian.yml` croise donc l'intention avec le pont REELLEMENT utilise, et le dit quand il desarme — un desarmement muet serait le meme piege, en silence. P45 EVALUE l'expression du playbook sur quatre cas plutot que d'en lire le texte, dont un qui DOIT rendre vrai : sans lui, une expression constamment fausse passerait la preuve sans rien garantir. Controle negatif verifie — le drapeau remis a plat fait echouer la preuve. Ce commit emporte aussi le desarmement d'`unattended-upgrades` dans `common_packages`, jusqu'ici applique sur les machines mais pas versionne : le verrou dpkg tenu 48 minutes par une vague de maj automatiques a coute deux deploiements. Le site a revele ce defaut parce qu'il a ete le premier a porter plusieurs zones. Ce n'est pas une particularite du site : un tenant derive les siennes du meme principe. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-25 19:50:53 -04:00
Daniel Allaire	1a7c042e5b	site : quatre zones d'autorite, et l'ordre inscrit dans les integrations ... Le site n'est plus un /24 plat. Une zone par nature d'autorite — pilotage, autorite, genome, service — chacune son VLAN et sa patte sur la frontiere. L'inversion corrigee, mesuree : les cinq VM du site n'avaient AUCUN filtrage est-ouest, contre policy_in=DROP sur une machine de tenant. La plus autoritaire etait la moins protegee. Filtrage nord-sud par choix de l'exploitant : un seul point de police, un seul devis. 90 -> 117 regles. Chaque flux `flotte` produit une regle par zone SOURCE, destination nommee — ce qui etait gratuit devient police. L'ORDRE FAIT PARTIE DE L'INTEGRATION. client_pki tournait en parallele sur tous les hotes ; sur celui qui porte l'autorite il recharge step-ca, et les quatre autres echouaient dans cette fenetre sur `TLS handshake timeout` — un message qui accuse le reseau. Chaque integration declare desormais sa dependance dans meta/integration.yml, les playbooks en sont le miroir genere, et P44 refuse l'ecart (4 controles negatifs). `serveur: ~` est une reponse valable : client_metrique pose un exportateur qu'on vient LIRE. Autres defauts du meme soir : - le plancher /etc/hosts venait APRES le premier apt, qui vise le cache par son NOM : boucle fermee des que les adresses changent. Il ne s'installe pas, il rend installable. - dns_amorcage ecrit en dur a eu tort deux fois ; il se derive de serveur_resolveur. - l'ACL du resolveur derivait d'un seul sous-reseau : trois zones refusees sur quatre. ET UNE ERREUR A MOI : j'ai diagnostique un trou noir de MTU et declare 1450. Faux — pas de VXLAN sur ce chemin, tout est a 1500 de bout en bout. Ma mesure etait reelle, mon interpretation non : je venais de debrancher la carte a chaud, et chaque `ip link set mtu` reconfigurait l'interface. C'est la reconfiguration qui debloquait, pas la valeur. 44 preuves vertes, ansible-lint profil production. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-25 17:31:07 -04:00
Daniel Allaire	158c3b314a	preuve : P43 — la frontiere voit-elle les machines du site ? ... Couvre ce qui a failli coûter 36 objets ce soir : le devis de la frontiere avait cesse de voir le site et proposait de retirer tous ses alias et toutes ses regles. Harnais vert, lint vert — seule la lecture manuelle du plan avant application l'a attrape. La premiere version etait inutile, et c'est instructif : elle lisait le plan par `devis_opnsense._machines_du_plan_site()`, la fonction meme dont la panne etait a detecter. Eprouvee sur la regression reelle, elle SE TAISAIT — les deux voyaient le vide, et elle concluait « rien a prouver ». Une preuve qui partage la source de ce qu'elle verifie ne verifie rien. La version retenue lit plan/serveurs.yml et plan/applications.yml DIRECTEMENT et confronte au devis produit. Eprouvee sur la regression reelle : elle refuse et nomme la cause. 43 preuves vertes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-25 14:11:39 -04:00
Daniel Allaire	665b07ba82	serveur_ops : la difference entre une archive et une matrice ... Un ecosysteme pouvait DETENIR son genome sans savoir l'executer. Le poste d'exploitation porte Ansible epingle, le genome clone depuis SA PROPRE forge, et une cle SSH qui n'appartient qu'a lui. Il n'emporte ni la voute ni son mot de passe : la structure se reconstruit depuis la forge, les secrets depuis la sauvegarde. Deux sources qu'un meme incident n'atteint pas ensemble. Une machine neuve traverse tout le moteur sans rien heriter, et revele ce qu'un etat anterieur masquait. Deux defauts silencieux en sont sortis. setops_plan_dir pointait le lien `instance` en dur : neuf roles lisaient donc le plan d'une AUTRE instance. Le plancher de patient 0 portait les FQDN de Chezlepro, et son edge publiait server_name forge.chezlepro.internal. La variable suit desormais l'inventaire reellement charge. Trois instances sur quatre declaraient les SAN d'exposition de leur edge ; la quatrieme et le modele public ne les avaient pas. La forge de patient 0 etait donc publiee derriere le certificat auto-signe de Debian, sans que rien ne le signale -- `git clone` fut le premier a refuser, a juste titre. P42 le reclame maintenant pour tout ecosysteme qui declare un edge. Le harnais a ecrit la moitie de ce role : 5 echecs sur la piece neuve, aucun n'empechait le code de tourner, tous la rendaient invisible a la carte, au graphe et au lecteur. 42 preuves, 0 echec. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-23 11:58:10 -04:00
Daniel Allaire	5bb503be45	doc : enseigner la classe de defaut, pas seulement la corriger ... L'exploitant, apres le refactor : « je n'y comprends rien ». C'est la mesure qui compte — la regle fondatrice du depot est qu'un humain pilote sans IA, et une correction qu'il ne peut pas expliquer ne lui appartient pas. - L'unite « La preuve » gagne une section : le defaut le plus dangereux n'est pas l'erreur, c'est la COPIE. Neuf copies ne vieillissent pas ensemble, et la divergence ne se voit jamais de l'interieur d'une copie. Avec le cas vecu — un devis qui repondait CONFORME sur le mauvais ecosysteme parce que les deux avaient les memes valeurs. - Le glossaire gagne « source unique » et « resolution d'instance » ; P39 les exige. - Le rapprochement qui rend la chose evidente : c'est la meme lecon que proxmox-hebergeur.yml, ou les listes du cluster recopiees chez chaque tenant avaient deja diverge. Une source, pas N copies — pour les donnees comme pour le code. Plan de recette regenere. make verifier 41/41. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-22 14:31:52 -04:00
Daniel Allaire	c18debc25e	resolution d'instance : une seule, partagee — au lieu de neuf copies ... Cinq jours, cinq defauts, tous de la meme famille : « quelle instance, quel inventaire ? » Neuf modules portaient chacun leur reponse. - 18 aout : P03 comparait chaque instance a l'inventaire d'une AUTRE ; - 19 aout : verifier_ports codait `principal/` en dur ; verifier_intrants et _frontiere_absente lisaient le symlink au lieu de la variable ; - 20 aout : devis_placement rendait un verdict juste sur le mauvais tenant ; - 22 aout : P35, puis P36 — la dixieme, trouvee par la preuve elle-meme. Aucune n'etait une faute d'inattention : chacune avait ete ecrite de bonne foi, a un moment ou le besoin semblait local. C'est le mode de panne de la duplication — pas l'erreur, mais la DERIVE, invisible depuis l'interieur d'un fichier. LA RESOLUTION UNIQUE. `inventory_rules` porte instance_courante(), inventaire_de(), dossier_inventaire() et plan_de(). Trois niveaux de repli, dont le TROISIEME manquait a la moitie des copies : un hosts.yml existant, puis un REPERTOIRE existant (instance neuve — c'est ce qui faisait echouer `make instancier` sur le modele public), puis le defaut. Vingt-huit modules y sont branches. CE QUI REND CE REFACTOR SUR : avant de toucher quoi que ce soit, chaque module a ete interroge sur ce qu'il resolvait, pour les DEUX ecosystemes. Apres refactor, meme mesure : 17 modules x 2 instances, diff VIDE. Aucune resolution n'a change — prouve, pas suppose. P41 echoue des qu'un module reintroduit une copie. Eprouvee en negatif : une copie replacee dans genome.py est signalee avec son numero de ligne. Trois exemptions nommees : instances.py et inventory_gui.py manipulent le SYMLINK lui-meme (bascule d'instance), et devis_opnsense lit deliberement quelle instance est ACTIVE. Elles parlent du lien, pas de la resolution. make verifier 41 OK, 0 echec, 0 saute ; make ci idem ; lint vert. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-22 14:19:55 -04:00
Daniel Allaire	bd1b897815	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
Daniel Allaire	79461fdc38	filiation : signer, inscrire la parente, et compter les temoins ... L'exploitant : « j'ai une intuition : blockchain ». L'intuition visait le bon probleme — une memoire partagee, verifiable, sans centre — mais la reponse etait deja dans git. GIT EST DEJA UNE CHAINE DE HACHAGE : chaque commit porte l'empreinte de son parent, un arbre de Merkle. Ce qui manquait n'etait pas la chaine mais l'AUTEUR : `user.name` est declaratif, et toute la soiree du 20 des commits ont porte « Daniel Allaire » sans qu'aucune preuve ne les lie a une cle (verifie : 8 commits, 0 signature, 0 etiquette). POSE AUJOURD'HUI : - signature par cle SSH (celle que la forge connait deja), etiquettes signees par defaut ; premiere etiquette v2026.08.21, verifiee par `git verify-tag` ; - `.git-allowed-signers` VERSIONNE : qui clone verifie sans rien demander a la forge, et sans lui faire confiance. Retirer une ligne revoque pour la suite ; le passe signe reste verifiable ; - `scripts/genome.py` + trois cibles make : les QUATRE depots sans lesquels un ecosysteme ne renait pas (moteur, instance, hebergeur, modeles), DERIVES et non declares ; - `parente.yml` par ecosysteme : de quel moteur il descend, a quel commit, sous quelle etiquette. Patient 0 descend de 742bcbf, etiquette v2026.08.21 ; - P40 : la parente est inscrite, chaque depot se retrouve, chaque commit inscrit EXISTE encore (une histoire reecrite se voit la), chacun porte un remote. Sautee proprement quand l'instance n'est pas un depot git — le modele jetable de la CI. POURQUOI PAS DE BLOCKCHAIN. Elle resout : qui ecrit ensuite, quand personne ne fait confiance a personne et qu'il y a de l'argent en jeu. Aucun des trois ici. Et la multiplicite qu'elle achete cher, la lignee la produit comme effet secondaire : chaque enfant porte une copie du code dont il descend, donc reecrire l'histoire suppose de convaincre TOUS les descendants. Le jour ou l'Alliance certifiera, ce sera un JOURNAL DE TRANSPARENCE (Certificate Transparency, Sigstore), pas une chaine. ENSEIGNE, pas seulement pose : nouvelle unite « Filiation, signatures et temoins » (moule en quatre temps), onze termes au glossaire, et P39 les exige desormais. make verifier 40 OK, 0 echec, 0 saute ; make ci idem. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 12:56:29 -04:00
Daniel Allaire	1f47e9bca8	glossaire : le metier n'etait explique nulle part ... Demande de l'exploitant apres une soiree passee a croiser « strophe FRR », VRF, VNet et nexthop-vrf : cet ecosysteme doit rester pilotable par un humain, idealement un seul ; que chaque notion sous-jacente soit ENSEIGNEE. MESURE AVANT D'ECRIRE : 40 termes employes par le depot et absents du glossaire — LDAP 184 fois, playbook 165, underlay 106, EVPN 66, VRF 33, LMTP 25. Le glossaire expliquait le vocabulaire propre a Set-OPS (plan, index, voute, zone) et laissait dehors tout ce qui vient du metier. Or c'est le metier qui perd le lecteur. CE N'EST PAS UN DEFAUT DE REDACTION. La regle fondatrice du depot est qu'un humain pilote sans IA. Chaque mot obscur retire une personne a la liste de celles qui peuvent reprendre le systeme : un vocabulaire non explique est un defaut de CONCEPTION. - Glossaire reecrit : 67 termes groupes par famille (plan, machines, Ansible, reseau, noms, confiance, identite, courriel, etat et preuve). Chaque entree dit ce que c'est ET pourquoi ce depot s'en sert, avec renvoi vers l'unite qui developpe. - Unite d'apprentissage manquante : « Le reseau des tenants ». Dix-sept des quarante termes y vivaient sans domicile. Elle suit l'ordre ou les problemes se sont poses : deux clients sur un cable -> VLAN -> ses deux limites -> encapsulation -> pourquoi 1450 -> EVPN -> le VRF, qui n'est pas une interdiction mais une ignorance structurelle. - Navigation : la nouvelle unite est au sidebar ; le plan de recette regenere (P22 l'a exige des l'ajout de la page — le harnais a mordu). P39 verifie : chaque terme du jargon a une entree ; chaque lien du glossaire mene a une page existante ; chaque page du wiki est atteignable depuis la navigation. LA LISTE EST DECLAREE, ET C'EST UN CHOIX MESURE. La derivation automatique a ete essayee : 153 acronymes dans le wiki et le README, dont la moitie sont des mots francais en capitales (AUCUNE, AVANT, TOUS). Un controle qui exige une entree pour « AUCUNE » finit desactive, et une preuve desactivee ne garde rien. La preuve dit elle-meme cet angle mort. EPROUVEE EN NEGATIF contre le glossaire d'avant : 49 termes manquants, nommes un par un. make verifier 39 OK, 0 echec, 0 saute ; make ci idem. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-21 12:15:55 -04:00
Daniel Allaire	a68b9cd10e	CI : le harnais ne se declenchait que par memoire ... Trente-huit preuves, des tests, un lint — et RIEN ne les executait sans qu'un humain tape `make`. Le meilleur atout du depot dependait de ne pas oublier. Il a desormais une CI (.forgejo/workflows/verifier.yml) et une cible qui la rejoue a l'identique : `make ci`. CE QUE LA CI A TROUVE AVANT D'EXISTER. Ecrire le workflow supposait de repondre a une question jamais posee : est-ce qu'un depot PUBLIC, seul, se tient ? Mesure sur un clone nu : non, a cinq endroits. - `make instancier` echouait sur le modele public — le tout premier geste du QUICKSTART. Le Makefile forcait `principal/hosts.yml` alors que le modele vit en `production/` ; sa precedence suit desormais celle du code (fichier, puis REPERTOIRE existant, puis defaut). - P32 parcourait les 54 roles sans regarder ce que l'instance deploie. Elle passait sur l'ecosysteme de reference PARCE QU'IL PORTE TOUT. Or les modeles sont des OFFRES : toute offre plus petite que l'ecosysteme complet echouait son propre harnais, pour des services qu'elle ne vend pas. Le perimetre se lit maintenant du plan (groupes de l'inventaire, puis roles composes par leur playbook). - P24 : le modele public ne declarait aucun reseau d'administration — une flotte qu'on construit et ou l'on n'entre plus. `nftables_admin_ssh` est pose, avec le pourquoi. - P33 : verifier_ports.py codait `instance/inventories/principal/hosts.yml` en dur. - P32 et P24 lisaient le symlink `instance/` au lieu de SETOPS_INSTANCE. Toutes de la MEME FAMILLE que P03 avant-hier : une resolution d'inventaire recopiee, une variable d'environnement qui deborde de sa portee. Le depot en compte SEPT ; deux de plus sont corrigees ici, et la septieme le dit en commentaire plutot que de le taire. `make ci` NE TOUCHE AUCUN SYMLINK : le modele public est monte comme instance jetable, vise par SETOPS_INSTANCE/SETOPS_UNDERLAY, detruit en sortant. Deux details mesures parce que devines faux d'abord : l'instance jetable est un DOSSIER FRERE (la federation se decouvre ainsi ; ailleurs, quatre preuves tombent) ; et SETOPS_UNDERLAY n'est pose QUE pour la verification, sinon l'inventaire est ecrit avec une fabric et regenere avec une autre — la commande fabriquait l'ecart qu'elle denonce. RESULTAT : clone nu sans instance ni frere -> 38 OK, 0 echec, 0 saute. Depot de l'exploitant avec ses 3 instances -> 38 OK, 0 echec, 0 saute. Aucun residu. Et le lint du depot a refuse mon propre fichier de CI avant qu'il ne tourne une seule fois (`on:` lu par YAML comme le booleen vrai). Le harnais mordait deja. A AJUSTER AU PREMIER PASSAGE, ecrit en tete du workflow : l'etiquette `runs-on` doit correspondre a un runner Forgejo enregistre, et le runner a besoin du reseau pour pip et ansible-galaxy. Le vert de cette CI dira que le moteur et son modele public se tiennent — pas que la flotte va bien : aucune VM jointe, aucune voute. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-20 19:29:46 -04:00
Daniel Allaire	f01f06df5e	catalogue : la carte des services avait quatre mois de retard sur le moteur ... `catalogue-services.md` est le document qu'on lit pour savoir ce que Set-OPS FAIT : l'hebergeur d'un second site, un futur client, un mainteneur qui arrive. Verifie role par role contre roles/, voici ce qu'il disait de faux. - « Capacites futures encore a implementer : collaboration (Nextcloud/Collabora) et couche web (frontal/dorsal) » — les quatre roles existent, collab-01, web-frontal-01 et web-dorsal-01 sont ACTIFS, et les deux roles web sont codifies depuis les spikes du 2026-07-05. - « La federation LDAP n'est pas automatisee dans le role ; Keycloak n'est pas expose » — serveur_keycloak/tasks/federation-ldap.yml existe, et le plan declare `expose: auth.<domaine>`. - `infra-mail-01` : « Sendmail MTA » — c'est Dovecot ; Sendmail est retire depuis le 2026-07-04. La table des hotes datait d'avant la separation edge-mta / mailstore. - `client_supervision` annonce comme integration — n'a JAMAIS eu ni role ni playbook. La supervision ne pose rien sur les hotes : controles actifs depuis le coeur, resultats passifs pousses par l'API (c'est backup-01 qui rapporte l'etat de ses depots). - Une colonne « Role » decorative inventait des noms (`nextcloud`, `client_metriques`) : le role porte le nom du GROUPE. Colonne retiree. Et NEUF roles vivants ne figuraient dans aucune table — le socle, toute la pile courriel, les sauvegardes, Icinga Web 2, oauth2-proxy, Unbound. Deux (`serveur_backup`, `client_backup`) n'etaient nommes NULLE PART. P38 — CE QUE P31 NE POUVAIT PAS VOIR. P31 verifie que tout est nomme et atteignable, pas qu'un document dise vrai : une carte peut etre complete et perimee. P38 confronte le catalogue au code dans les deux sens, et c'est la TABLE qui fait foi des deux cotes : tout role figure dans une ligne de table (la prose ne suffit pas — la pile courriel y etait racontee et introuvable pour qui lit un index), et tout groupe cite en table existe reellement (role, ou playbook de groupe pour `serveur_durci`, qui en compose onze). Deux exemptions nommees : la prose peut citer les roles RETIRES, sinon on ne peut plus ecrire d'ou l'on vient ; et P38 ne juge pas si une description est JUSTE — cela se revoit contre le CHANGELOG, le mecaniser serait se mentir. EPROUVEE EN NEGATIF : rejouee contre la version d'avant, elle echoue en nommant les neuf roles absents et les trois cases fantomes. Le catalogue dit aussi desormais ou il s'arrete : la reconstruction prouve qu'une machine nue atteint l'etat voulu, pas la tenue sous charge ; et l'usage reel de Nextcloud n'est pas consigne comme preuve. Lacune nommee au passage : la dependance causale serveur_web_frontal -> serveur_nginx n'est toujours pas declaree. make prouver : 38 OK, 0 echec, 0 saute. make test inchange. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-19 11:07:59 -04:00
Daniel Allaire	4462c13b3d	P03 : la preuve comparait chaque instance a l'inventaire d'UNE SEULE ... Trouve en validant une mise a jour du CHANGELOG. Deux invocations de la meme preuve, deux verdicts : `make prouver` -> NON CONFORME (« lab : 17 hotes avec ecart »), `python3 scripts/prouver.py` -> CONFORME 37/37. Le lab n'avait aucun ecart. DEUX VARIABLES DESIGNENT LA CIBLE, ET LA SECONDE GAGNE. Le Makefile exporte SETOPS_INVENTAIRE (ligne 13), derive de l'instance ACTIVE ; instancier.py:68 lui fait FORCER la cible par-dessus SETOPS_INSTANCE. P03 (prouver.py:505) ne redirigeait que SETOPS_INSTANCE : elle generait le plan de CHAQUE instance federee et le comparait a l'inventaire applique de la SEULE instance active. LE ROUGE N'ETAIT PAS LE PROBLEME, LE VERT L'ETAIT. Sous `make`, l'inventaire applique de lab et de Technolibre n'etait JAMAIS lu — l'angle meme pour lequel P03 a ete ecrite le 2026-08-12 (un tenant qu'on ne regarde pas imposant ses vieilles adresses au pare-feu partage). La preuve etait aveugle a son propre cas, par l'invocation documentee. Les rapports du 13 et du 14 sortent de cette invocation-la. Signature visible sans lire le code : les hosts.genere.yml de lab et de Technolibre ne bougeaient pas. CORRECTIF, cinq sites : env.pop("SETOPS_INVENTAIRE") partout ou l'on redirige SETOPS_INSTANCE — P03 et P15, plus les trois applicateurs (opnsense, proxmox_fw, sdn) qui pointent vers l'HEBERGEUR. Ces trois sont sans effet tant qu'hebergeur et tenant actif coincident, c'est-a-dire jusqu'au second site. Le geste existait deja (modeles.py:96). GARDE, pour que la classe cesse d'etre silencieuse : inventory_rules.inventaire_force() REFUSE une cible hors de l'instance visee, en nommant les deux valeurs. Eprouvee dans les deux sens (contradiction -> code 1 ; cible legitime dans l'instance -> passe). Branchee sur les quatre resolutions de _inventaire (instancier, serveurs, applications, config_proxmox). Le GUI garde la sienne : il ne redirige jamais SETOPS_INSTANCE pour un fils et resout par symlink a chaque requete. make prouver : 37 OK, 0 echec, 0 saute — et les hosts.genere.yml des TROIS instances portent l'horodatage du passage. make test 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 14:35:01 -04:00
Daniel Allaire	199783f5fd	D-80 : un tenant est agnostique de son underlay, a trois cles pres ... Formulation de l'exploitant, meilleure que celle du depot. Le commentaire disait « la fabric reste celle de l'hebergeur, quel que soit le tenant actif » — vrai, mais centre sur l'HEBERGEUR. Le cadrage juste est centre sur le TENANT : les deux symlinks composent deux axes INDEPENDANTS (instance = quel tenant, underlay.yml = sur quelle fabric). Tout l'adressage derive du seed index : le plan se deplace d'une fabric a l'autre sans y toucher. Ce qui ne se deplace pas tient en TROIS CLES — proxmox_clone_noeud, _stockage, _pont. Elles vivent cote tenant (c'est lui qui choisit ou se poser) mais nomment des objets de l'hebergeur. Trois, pas trente : c'est ce qui separe « portable » de « theoriquement portable ». P37 confronte ces trois noms aux listes de proxmox-hebergeur.yml, trouve par derivation du symlink underlay.yml. Un nom absent est un ecart STATIQUE (D-75) — sans quoi une faute de frappe ne se decouvre qu'au premier clone, apres quarante minutes. Eprouvee en negatif sur les trois cles. Non verifie et dit comme tel : le gabarit (_vmid_modele) est un objet du cluster, pas une liste declaree. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 09:47:38 -04:00
Daniel Allaire	93a92aae86	P03 : la preuve regarde TOUTES les instances — et trouve une collision d'emblee ... P03 ne verifiait la fraicheur de l'inventaire que pour l'instance ACTIVE. Or la frontiere nord/sud est PARTAGEE : ses alias d'hotes sont construits depuis le hosts.yml de CHAQUE tenant. Un tenant qu'on ne regarde pas — parce qu'il n'a aucune VM, precisement — impose donc ses adresses au pare-feu de tout le monde. Elle boucle desormais sur les instances decouvertes, chacune verifiee via SETOPS_INSTANCE (que instancier.py honore deja). AU PREMIER PASSAGE, elle a trouve une troisieme instance perimee et une collision franche : OPS-Chezlepro-lab (index 1) applique : 10.11.18.21 <- ancienne derivation OPS-Technolibre (index 11) derive : 10.11.x.x <- nouvelle derivation Le lab occupait EXACTEMENT la plage desormais attribuee a Technolibre. P21 garde les index ; rien ne gardait les inventaires APPLIQUES. La collision serait apparue le jour ou les deux auraient tourne ensemble. Les trois instances sont alignees : 10.1 (lab), 10.11 (Technolibre), 10.17 (Chezlepro). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-12 17:21:09 -04:00
Daniel Allaire	2c7849f6b3	P03 : la preuve du diff-vide peut enfin echouer — et elle echoue ... instancier.py comparer affichait l'ecart puis renvoyait TOUJOURS 0. P03 « Diff-vide du plan » ne pouvait donc pas echouer : elle est passee au vert pendant que quatorze hotes divergeaient du plan. Deux appelants, deux besoins — d'ou un MODE plutot qu'un changement de comportement : `make instancier` est une INSPECTION (voir le diff avant de decider ; un code d'erreur y transformerait la lecture en panne), P03 est une AFFIRMATION (« le plan reproduit l'inventaire »). prouver sort desormais a 1, et c'est EXACT : depuis le retrait du decalage de +10, le plan derive 10.17.x.x tandis que l'inventaire applique — et les quatorze VM qui tournent — portent 10.27.x.x. Le depot est sciemment dans cet etat jusqu'au renumerotage. Une preuve rouge qui dit vrai vaut mieux qu'une verte qui ne regarde rien. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-12 16:28:30 -04:00
Daniel Allaire	8eedeaf31f	sauvegarde : le catalogue derive du groupe, et P36 le prouve ... Correction : l'entree precedente attribuait le defaut a la reconstruction from-zero. C'est faux — le commit fondateur 7476a54 (2026-07-03) disait lui-meme « Reste : jobs Tier 1 (pg_dump/slapcat/vmail/forgejo) ». Ils n'ont jamais ete ecrits, et infra-pki-01 a ensuite perdu son integration client_backup. Le role qui POSSEDE la donnee dit comment la sortir : client_backup_jobs est l'intersection du catalogue et des group_names du noeud. Un tenant qui deplace un service emporte sa sauvegarde avec lui. On sauvegarde l'etat NON REGENERABLE : ni zones PowerDNS ni tableaux Grafana, ils se redeploient. L'unite qui ment est RETIREE, pas rendue bloquante : refuser le deploiement aurait casse infra-edge-01, infra-dns-01 et mon-01, qui ne detiennent legitimement rien. Le defaut etait le timer qui echouait chaque nuit en donnant l'apparence d'une sauvegarde. P36 (D-75) lit les groupes detenteurs dans le catalogue : ajouter un role au catalogue etend la preuve du meme geste. Elle a attrape infra-pki-01 — les cles de l'AC — corrige au plan. Mesure hors-noeud : collab-01 64,0 MiB/272, edge-mta-01 4,4 MiB/139, data-sql-01 1,0 MiB (pg_dumpall complet), forge-01 26,4 KiB/68, infra-pki-01 20,1 KiB/21, idm-01 2,3 KiB/5 (slapcat). 9 hotes, 9 success. Reste : rien ne surveille l'unite — c'est ce silence qui a laisse le defaut vivre un mois. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-11 20:50:46 -04:00
Daniel Allaire	9e4101723b	preuve : P31 ignorait les scripts invoques par un role ou un playbook ... En ajoutant la verification de signature, P31 a declare `verifier_signature.py` « injoignable » — alors qu'il tourne a chaque deploiement de Keycloak. Elle ne regardait que le Makefile et les autres scripts, jamais les roles ni les playbooks. Une preuve qui ignore un chemin d'appel reel accuse du code sain, et on apprend a passer outre : le pire sort possible pour une garde. ET J'AI POUSSE AVEC CETTE PREUVE EN ECHEC. Troisieme fois de la session, et toujours la meme faute : `prouver.py | tail -1` rend le code de sortie de `tail`, donc le `&&` qui suit continue quoi qu'il arrive. Le commit precedent (verification de signature Keycloak) est parti avec 34 OK / 1 echec. Corrige ici, et la lecon vaut plus que le correctif : ne jamais lire le verdict d'une garde a travers un tube. Verifie : prouver.py 35 OK, code de sortie lu SANS tube. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-11 00:52:21 -04:00
Daniel Allaire	777bea8408	portabilite : Technolibre debout, six devis, et P35 ... L'epreuve de portabilite est passee. Un second ecosysteme souverain complet, monte depuis zero par le meme moteur : 14 hotes, 2583 taches ok, 331 changed, 0 failed. Plan distinct, voute separee, realm technolibre, sa propre AC — et une topologie differente : LDAP et SSO sur des machines separees la ou Chezlepro les co-localise. Cinq devis CONFORME (identite, certificats, PostgreSQL, courriel, frontiere — 55 lignes 0 ecart). Le sixieme dit exactement la bonne chose : les 6 services repondent depuis l'edge, aucun depuis le poste, qui ne resout pas encore technolibre.internal (6 entrees /etc/hosts absentes — le plancher). SIXIEME DEFAUT MOTEUR. Le devis d'identite interrogeait LDAP en `ldapi:///` — un socket UNIX LOCAL — depuis l'hote serveur_keycloak. Cela ne marchait que par CO-LOCATION ACCIDENTELLE. Un tenant qui separe l'annuaire du SSO echouait sur « Failed to import python-ldap » : l'hote SSO n'a pas de client LDAP. Les deux lectures sont deleguees a l'hote DERIVE par resoudre_annuaire. P35 (D-75) : toute application dont le role exige une base en a une au plan. La garde de resoudre_base existait deja, mais s'est declenchee a la 92e tache de collab-01, apres quarante minutes, pour un ecart entierement lisible dans le plan. Rien n'y est code en dur : les roles concernes sont ceux qui INCLUENT resoudre_base, et le groupe reclame est lu dans le DEFAUT de la variable passee — jamais deduit du nom. serveur_icingaweb2 reclame la base de serveur_icinga ; une preuve supposant « role = groupe » aurait crie sur un cas sain. Eprouvee dans les deux sens ET sur les deux tenants, dont les registres n'ont pas la meme portee : base retiree -> ECHEC la nommant ; restauree -> OK. Verifie : prouver.py 35 OK sur les deux instances, ansible-lint production. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-10 13:36:44 -04:00
Daniel Allaire	ac85278366	preuve : P34 — chaque document declare son lecteur (D-74) ... La refonte de ce matin posait une convention. Une convention qu'on n'outille pas tient tant que quelqu'un y pense : c'est le raisonnement de D-70, applique au corpus documentaire. Etat de depart mesure : 2 documents sur 34 declaraient leur lecteur. Les 32 autres disaient leur SUJET — ce qui avait enfoui le runbook de reprise le plus utile du depot au §6 de autorisation.md. Les 38 le declarent desormais, lecteur determine document par document et non colle au gabarit : l'exploitant (devis, migration de tenant, cycle de vie, gabarit d'or), le mainteneur (conceptions, registres, carte), le lecteur externe (ecosysteme-chezlepro), l'agent IA (MISE-A-JOUR-CODEX-CLAUDE). Deux exemptions DERIVEES, pas listees — un chemin en dur aurait vieilli a la premiere page ajoutee : un document qui s'annonce genere, et un fragment sans titre. Les 13 exemptes verifies un par un ; aucun document ecrit a la main n'est exempte par accident. La preuve ne lit que l'EN-TETE, ce qui empeche frontiere-opnsense.md et plan-et-generation.md — qui parlent de generation dans leur corps — d'etre exemptes a tort. Eprouvee dans les deux sens. Elle a echoue seule des sa premiere execution en nommant deux documents que mon inventaire avait manques (docs/audit/). Puis test negatif delibere : declaration retiree de meta-classe.md -> ECHEC la nommant ; restauree -> OK. Ce qu'elle ne teste pas : que le lecteur declare soit le BON. Ca se juge en revue ; elle garantit qu'on a du y penser. P01–P34. Comptes perimes corriges au passage (AGENTS.md et devis-services.md annoncaient encore 30 preuves). Verifie : prouver.py 0 (34 OK), plan-recette inchange. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-10 07:53:04 -04:00
Daniel Allaire	28e0c45696	P33 / D-73 : aucune collision de port entre roles co-localises ... Deuxieme des trois chantiers ouverts par la reconstruction. Retrouve son defaut n6 a froid, sans machine. Le SASL de Dovecot et l'interface d'Alloy se disputaient le 12345 sur infra-mail-01 depuis le premier jour, et c'est Dovecot qui perdait EN SILENCE. Il a fallu inverser l'ordre de demarrage — ce que fait un rejeu depuis zero — pour que ca devienne audible. Le controle n'etait possible qu'apres avoir DECLARE le port d'Alloy : un port SUBI (defaut amont d'un logiciel qu'on n'a pas choisi) n'existe pour aucun registre, donc aucune preuve ne peut le voir. Il faut l'imposer pour le verifier. partage: true — nouveau mot du registre — distingue « j'ouvre cette ecoute » de « je decris celle d'un autre » (serveur_backup empruntant le sshd de serveur_debian). Sans lui, la seule co-location legitime de la flotte serait signalee a tort, et une preuve qui crie sur un cas sain finit par etre ignoree. Verifie dans les deux sens : 32 revendications sans collision sur le reel ; en remettant Alloy a 12345, le defaut n6 est nomme, code 1. Harnais : 33 preuves, 0 echec, 0 sautee. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-09 09:46:17 -04:00
Daniel Allaire	d52f256366	P32 / D-72 : tout intrant exige par un role est fourni par l'instance ... Premier des trois chantiers rendus evidents par la reconstruction. Il aurait trouve son defaut n1 — amorcage_acces_courriel — SANS RIEN DETRUIRE. Un assert de role declare un contrat ; rien ne verifiait que l'instance l'honore, et le manque ne se voit qu'au moment ou la garde s'execute — donc, pour un intrant d'amorcage, seulement en repartant de rien. Satisfait par : defaut non vide (vault_* compris, gardes par P18), set_fact de resolveur, ou declaration de l'inventaire. Aucune voute dechiffree : la preuve reste statique. Deux fois mon instrument a accuse le composant a sa place, avant meme sa premiere execution utile : il criait au manque sur serveur_postfix_mailstore_hote, pourtant fourni — je ne lisais pas le fichier d'inventaire, puis je n'y cherchais que les blocs vars: alors qu'instancier ecrit sous le nom d'hote. Verifie dans les deux sens : 30 exigences satisfaites sur le reel ; sur un double sans la declaration d'hier, le defaut n1 est nomme, code 1. Harnais : 32 preuves, 0 echec, 0 sautee. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-09 09:40:25 -04:00
Daniel Allaire	872d590031	P31 : le motif laissait passer toute cible contenant une majuscule ... « Pourquoi pas make myDay ? » — la cible existe (alias strict de reconstruire) mais n'avait aucun texte d'aide, et P31 la declarait conforme. Le motif etait ^[a-z][a-z0-9_-]*: — toute majuscule echappait au controle. myDay est citee dans l'aide du Makefile et dans la GUI, et n'apparaissait dans aucun recensement. Une preuve ne vaut que ce que vaut son motif. Celle-ci a ete ecrite avec la conviction d'etre rigoureuse et testee dans les deux sens le jour meme. Le trou a ete trouve par une question, pas par un test. Troisieme fois sur la meme preuve en une journee, apres le rapport genere qui se citait lui-meme et l'inventaire genere qui l'aurait satisfaite par construction. La difficulte n'est pas d'ecrire un test, c'est de delimiter honnetement ce qu'il regarde. 87 cibles documentees, 36 scripts, 54 roles. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-08 14:34:00 -04:00
Daniel Allaire	a430edf014	make raser : la seule commande destructive du moteur, avec ses quatre verrous ... Ajoutee pour rendre la reconstruction from-zero REPETABLE — un test qu'on ne peut jouer qu'une fois n'est pas une recette. Verrous, tous eprouves avant usage : - VMID derives du plan uniquement (le gabarit dore est structurellement exclu) - le NOM doit correspondre : un VMID du plan sous un autre nom fait refuser l'operation ENTIERE. Pas theorique — le 2026-08-07 une VM heritee portait un VMID du plan sous le nom web-frontal-01 et proxmox_kvm rapportait ok. - il faut NOMMER l'ecosysteme (INSTANCE=) : le symlink instance/ peut pointer n'importe ou ; taper le nom distingue le POC de la production. - CONFIRMER=true ; sans lui, inventaire et rien d'autre. Le verrou du nom est le seul qu'on ne peut pas eprouver sur le vrai cluster sans y fabriquer une collision : scripts/tests/test_raser.py l'isole derriere un faux cluster, rattache a P02. Harnais : 31 preuves, 0 sautee. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-08 14:22:04 -04:00
Daniel Allaire	5308574730	D-70 / P31 : l'exigence de documentation devient une preuve ... Directive de l'exploitant : la doc dit et explique tout ce que Set-OPS fait. Une exigence seulement enoncee pourrit en silence — trois exemples le jour meme dans la carte. Ecart mesure : 66 cibles make sur 85 sans texte d'aide (make aide en montrait 19), 11 scripts sur 35 cites nulle part. Les 66 cibles ont recu leur aide : 85 commandes documentees. P31 garde le couvert. Le chemin pour l'ecrire a ete instructif : deux fois mon critere s'est revele creux. D'abord « le nom apparait dans un document » — le rapport d'audit GENERE recopiait les noms manquants dans son message d'echec. Puis j'ai failli refaire le trou en plus grand : generer un inventaire de l'outillage aurait satisfait le critere par construction. Un critere qu'on peut satisfaire en generant du texte ne prouve rien. P31 teste donc que chaque script porte une docstring qui l'explique et reste ATTEIGNABLE (cible make ou autre outil), que chaque cible porte son aide (sauf les internes prefixees _, exemption nommee), que chaque role a son README. Verifiee dans les deux sens. Ce qu'elle ne garde pas, et c'est dit dans son code : que l'explication soit bonne. Le pourquoi se juge en revue. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-08 13:21:23 -04:00
Daniel Allaire	3b1d9b6660	SDN : make devis-sdn — zone, VNets et sous-réseaux dérivés du seed (D-43/44, P30) ... 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>	2026-08-04 11:06:42 -04:00
Daniel Allaire	22ef279464	authentification : chaque rôle déclare sa position, gardé par P29 ... 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>	2026-08-03 17:05:43 -04:00
Daniel Allaire	60a60b6fb1	pools Proxmox : un par tenant, dérivé de l'index (D-37, P28) ... Onze des quatorze serveurs portent le même nom court chez Chezlepro et chez Technolibre. Vérifié un par un, ce n'est pas un problème technique : tout le reste dérive du seed et diverge (10.27.19.21 contre 10.21.19.21, VMID 117402101 contre 111402101, VLAN 1174 contre 1114, deux domaines internes), et rien n'est indexé sur le nom court — les opérations Proxmox portent toutes un vmid, les certificats un FQDN, et client_backup_repo vise backup-01.{{ domaine_interne }}. Le coût est humain : la console Proxmox affiche le nom, et deux infra-pki-01 y sont indiscernables à l'œil. Le VMID porte le tenant, encore faut-il connaître le codage. Un pool par tenant, dérivé du dossier d'instance et de l'index — déjà unique par P21, donc aucun registre de plus : Chezlepro-17, Technolibre-11. make devis-proxmox-pools rattrape la flotte existante (création du pool, puis affectation des VM actives). Les VM créées ensuite entrent d'elles-mêmes : make creer-vm dérive le pool par la même fonction et le passe à la création. Le playbook crée le pool au préalable — proxmox_kvm échoue sur un pool inconnu, et l'API ne sait pas changer le pool d'une VM existante ; c'est aussi pourquoi le rattrapage passe par les membres. P28 garde deux collisions : même nom de pool entre tenants, et surtout même VMID — une machine appartenant à deux tenants serait pire qu'une homonymie. Rien n'est renommé : les homonymes sont la preuve que la nomenclature est un vrai gabarit. Le devis ne lit pas le cluster, il dit l'état cible et non l'écart. 27 preuves OK, 0 échec. --syntax-check du playbook de clonage. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 15:15:14 -04:00
Daniel Allaire	b0e56cbfc0	intégrations : le rôle déclare sa politique ; le cluster passe à l'hébergeur ... Deux corrections de propriété, l'une dans le plan, l'autre dans les intrants. 1. Intégrations universelles (D-33/D-34, P26) Le plan portait 57 lignes d'intégration écrites à la main, dont 28 disaient oui à quelque chose de vrai pour tous les hôtes. Elles n'existaient que pour être oubliées — et elles l'avaient été : dans Chezlepro, backup-01 et infra-pki-01 n'étaient ni supervisés, ni journalisés, ni certifiés. Le rôle déclare désormais sa politique une fois, dans meta/integration.yml ; le plan ne garde que les vrais choix et refuse la recopie. Les exemptions se dérivent du service rendu (sauf_role), jamais d'un nom d'hôte : l'AC ne s'enrôle pas auprès d'elle-même, et l'exemption suit step-ca si on le déplace. Une seule fonction de résolution — integrations_de() — lue par l'inventaire, la voûte et le panneau. Sans le passage par la voûte, les secrets des intégrations universelles auraient cessé d'être exigés et P18 serait passé au vert sur une voûte incomplète. Vérifié : diff vide sur Technolibre (la politique reproduit exactement les 41 lignes retirées) ; sur Chezlepro, exactement les groupes manquants, et pas client_pki sur infra-pki-01. 2. Vue Intégrations : la matrice La fiche montrait les intégrations d'UN serveur ; le trou de Chezlepro n'a pas été trouvé par le panneau mais par le devis de pare-feu. Matrice serveurs x intégrations : colonnes de politique en lecture seule, facultatives cochables sur place, ligne de couverture n/N qui rend le motif visible sans le juger. 3. Propriété des intrants (D-35/D-36, P27) Le cluster Proxmox appartient à l'hébergeur, comme sa fabric et sa frontière. Recopié chez chaque tenant, son inventaire avait déjà divergé : deux listes de stockages contradictoires pour le même matériel. API/nœuds/stockages/ponts vont dans proxmox-hebergeur.yml, à côté d'underlay.yml, dont le chemin se dérive — l'hébergeur reste non déclaré (D-17). Restent au tenant son golden template et ses défauts de placement. Le panneau nomme désormais le propriétaire de chaque section : éditer une section « hébergeur » vaut pour tous ses tenants, et l'écran ne le disait pas. 26 preuves OK, 0 échec. --syntax-check des deux playbooks Proxmox. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 14:09:22 -04:00
Daniel Allaire	fd62b59989	pare-feu Proxmox : le filtrage est-ouest intra-tenant, dérivé (P25) ... `make devis-proxmox-fw` : 34 groupes de sécurité, 40 règles, 2 tenants — depuis les 57 flux intra-tenant que le registre connaissait déjà. Défense en profondeur, pas remplacement : l'hyperviseur filtre puis l'hôte destinataire filtre à nouveau. Coût de maintenance nul, les deux barrières lisent le registre par les MÊMES fonctions — la duplication est dans l'application, jamais dans la décision. Un IPSet par rôle porte les membres, les groupes y renvoient : ajouter un hôte à un rôle met à jour toutes les règles qui l'autorisent, en un endroit. Garde ajoutée après coup : Proxmox limite un nom de groupe à 18 caractères. Ma première version tronquait sans vérifier — deux rôles tronqués au même nom auraient fusionné leurs règles, donnant à une VM les autorisations d'un rôle qu'elle ne porte pas, silencieusement. Le préfixe porte maintenant l'index plutôt que l'étiquette, et une garde échoue sur toute collision. Exercée. Conséquence consignée : tout ce qui entre dans un tenant passant par la frontière, le contrôleur Ansible aussi — l'OPNsense devient un prérequis de déploiement, pas une étape parmi d'autres. Preuves : 25 OK, 0 échec. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 11:43:32 -04:00
Daniel Allaire	1917545126	audit : les preuves réseau étaient accrochées à la mauvaise affirmation ... P21, P23 et P24 renvoyaient à AFF-001 — « Set-OPS est un moteur Ansible générique » — sans rapport avec la fédération, l'underlay ni la frontière. P17, P19 et P20 n'avaient aucune référence. Une preuve accrochée à la mauvaise affirmation passe au vert et n'atteste de rien de ce qu'on croit. Ajouté §10 du registre : six affirmations (AFF-101..106) pour l'architecture réseau et la fédération. La couverture du plan par le panneau est en 🟡, avec ses exceptions nommées — listes de tables de l'underlay, ports physiques, nœud de sortie. Volontairement absente : la justesse des devis. Leur syntaxe dépend d'un matériel que le dépôt ne possède pas ; six familles ont été confrontées au commutateur réel, deux étaient fausses, mais c'est une vérification datée et non une preuve rejouable. Le dépôt n'affirme pas que ses devis s'appliquent, il affirme qu'ils dérivent. Corrigé aussi : P03, P06, P12 et P13 portent maintenant les références que la table leur attribuait déjà — la correspondance existait en double et seul le document la tenait. Et la table attribuait AFF-030 (« inventaire complet ») à P15, qui valide le modèle socle ; c'est P16 qui exécute `ansible-inventory --list`. 35 affirmations référencées, aucune référence orpheline. Preuves : 24 OK, 0 échec. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-03 09:36:30 -04:00
Daniel Allaire	7256486c9c	modèles : l'underlay devient modélisable, et P17 le valide ... Un modèle décrivait un tenant — ses services, ses zones, ses bases. Tous les hébergeurs n'ont pas le même matériel : l'infrastructure physique mérite le même traitement. Le modèle public gagne un underlay volontairement minimal (un commutateur, pas de fabric de stockage séparée), point de départ honnête d'un petit hébergeur. Les montages plus riches sont d'autres modèles, conformément à la doctrine : un générique public, les étoffés en privé. Le modèle contient désormais deux moitiés qui ne vont pas au même endroit : `plan/` et `inventories/` chez le tenant, `underlay.yml` chez l'hébergeur. `modeles.py verifier` le valide (P17), facultativement et sur sa cohérence INTERNE seulement — pas contre les tenants fédérés réels, un modèle étant un gabarit et non un site déployé. Il a fallu rendre paramétrables deux hypothèses du validateur, qui lisait la nomenclature de l'instance active et globait les dépôts frères ; comportement par défaut inchangé. Cinq cas de rejet exercés : VLAN empiétant sur la plage tenant, passerelle au mauvais dernier octet (lue dans la nomenclature du modèle), routeur inconnu, sortie hors du lien, port déclaré deux fois. Preuves : 24 OK, 0 échec. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-02 17:11:18 -04:00