4 commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
| 5bc3bceac1 |
documentation : la tournee des 74 documents, parce qu un balayage ne lit pas
Some checks failed
verifier / verifier (push) Has been cancelled
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 |
|||
| 3445ccb836 |
portee : les trois devis d'un site partagent enfin la meme regle
Le commit du 2026-08-14 nommait lui-meme ce qui restait : « meme hypothese ailleurs, non corrigee — devis_sdn et devis_reseau partent du meme decouvrir(). A traiter quand ils serviront sur un second site. » C'est fait AVANT, pas pendant la visite. Les trois devis equipent le MATERIEL d'un site : la frontiere (regles, routes), le commutateur (VLAN, SVI, routes) et le SDN de l'hyperviseur (zones, VNets). Un tenant d'ailleurs y ajoutait des objets que le materiel accepte, qui ne correspondent jamais a rien, et que rien ne signale. UNE SEULE FONCTION AU LIEU D'UN FILTRE RECOPIE TROIS FOIS : `devis_reseau.decouvrir_du_site()` = decouvrir() restreint par `underlay.tenants`, la doctrine ecrite une fois. Le filtre inline de devis_opnsense est retire au profit d'elle. `admin_tous_tenants()` la suit : le routeur d'un site n'a pas a savoir revenir vers le plan de gestion d'un tenant qu'il ne porte pas. EPROUVE dans les trois situations : underlay sans la cle -> les deux tenants, comme avant ; underlay du second site -> OPS-Technolibre seul ; nom declare qu'aucun dossier ne fournit -> ATTENTION et le reste est retenu ; filtre qui ne retient rien -> refus, code 1. SANS EFFET SUR LE SITE ACTUEL : l'underlay de Chezlepro ne declare pas `tenants`, et cle absente = toute la federation (verifie : decouvrir() et decouvrir_du_site() rendent la meme liste ici). ET LA CLE EST ENFIN DOCUMENTEE — c'etait le vrai trou. `underlay.tenants` existait depuis le 14 sans figurer ni dans underlay.yml.example ni dans l'annexe du runbook d'implantation : indecouvrable pour qui monte un second site. prouver 37 OK, 0 echec, 0 saute ; make test inchange. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
|||
| 7339cc64b4 |
frontiere : une frontiere ne police que les tenants de SON site
Mesure du 2026-08-14, sur le second site. `make frontiere-plan` voulait poser sur la frontiere de Technolibre les regles ET les routes de CHEZLEPRO : 30 objets de plus, dont six routes vers des sous-reseaux 10.17.x qui n'existent pas la-bas. LE DEFAUT EST DE PORTEE, ET IL EST SILENCIEUX. Les devis partaient de `devis_reseau.decouvrir()`, qui rend TOUTE la federation — tout dossier frere portant une nomenclature avec un index. C'etait juste tant qu'il n'y avait qu'un site : l'hebergeur unique portait bien tous les tenants. Des le second, le boitier aurait accepte ces trente objets, aucun n'aurait jamais correspondu a un paquet, et rien ne l'aurait signale — une politique qui a l'air complete et ne protege rien. Encore le chèque vert sur un perimetre vide. CORRECTIF : l'hebergeur declare dans SON underlay les tenants qu'il porte (`underlay.tenants`), et `devis_opnsense` s'y limite. Cle ABSENTE = ancien comportement (toute la federation) : un site unique n'a rien a declarer, c'est le second qui doit se nommer. Un nom declare qu'aucun dossier frere ne fournit est signale, pas ignore. MEME HYPOTHESE AILLEURS, non corrigee ici : `devis_sdn` et `devis_reseau` partent du meme `decouvrir()`. A traiter quand ils serviront sur un second site. AU PASSAGE, un defaut du document ecrit la veille : le squelette d'`underlay.yml` de `implanter-un-tenant-sur-un-site.md` omettait `index`. Sans cette cle, `make underlay` refuse le reseau de gestion en le prenant pour le supernet d'un AUTRE site — message deroutant, cause triviale. Trouve en s'en servant, moins de 24 h apres l'avoir ecrit. prouver 37/37, make test 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
|||
| 1d875f50ec |
doc : implanter un tenant sur un site neuf — le runbook de l'intervention
Le depot couvrait deja « l'hebergeur prepare son materiel » et « un tenant VIVANT change d'hebergeur, sans coupure ». Il manquait le troisieme cas, qui est celui qu'on s'apprete a faire : un tenant dont le plan existe deja prend corps sur un site qui n'a jamais rien porte. Rien a migrer, rien a interrompre — donc ni la sequence de gel/bascule de migration-tenant.md, ni le bootstrap de QUICKSTART. SIX PHASES, chacune fermee par une commande qui INTERROGE le systeme : 0 bureau (index du site = index du tenant, depot hebergeur, gabarit, voute) 1 reconnaissance du cluster -> `make underlay`, `make placement-plan` 2 frontiere -> `make frontiere-plan` 3 gabarit (convertir en template ; un clone de VM vivante en ferait 14 copies) 4 composer les DEUX symlinks (D-80) + les 4 valeurs de placement 5 materialiser -> `make sdn-appliquer` puis `make reconstruire` 6 recette : devis, restauration eprouvee, supervision CE QUE LE RUNBOOK PORTE ET QU'AUCUN AUTRE DOCUMENT NE DIT - Un site NEUF se batit d'emblee dans l'adressage cible (D-77/D-78). Le site historique est encore en 10.0.x et migrera par runbooks §6 ; sur un site vierge la cible ne coute rien. Deux sites en 10.0.0.0/24 rendraient la reprise mutuelle IMPOSSIBLE : deux plans de gestion identiques ne peuvent pas s'atteindre. - L'ordre de `reconstruire` est explique ligne a ligne, dont le piege `make flux` : sans lui nftables tombe en `policy drop` SANS AUCUNE REGLE, la flotte monte, SSH repond, et tout le reste est mur (trouve le 2026-08-10). - Un site a UN SEUL noeud : il est aussi noeud de sortie, aucun pont ne peut etre partiel, aucune haute disponibilite — a dire, pas a laisser supposer. - PVE 9 n'a jamais ete eprouve ici : tout ecart est inconnu jusqu'a mesure. - « Ce qui n'est PAS fait en repartant » : resserrer le compte d'API, le lien inter-sites, le gabarit des deux cotes, la voute hors de son propre site. ANNEXE : les squelettes d'`underlay.yml` et `proxmox-hebergeur.yml` pour un site a un noeud, a remplir depuis la RECONNAISSANCE et jamais de memoire — c'est en recopiant des listes chez chaque tenant qu'elles avaient diverge. Sixieme porte dans la table de routage du README. Les 21 cibles make citees ont ete verifiees comme existantes. prouver 37/37 (P34 : 40 documents declarent leur lecteur), make test 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
