Alliance-Boreale/Set-OPS-Public
2
0
Fork 0
Code Issues Pull requests 1 Projects Releases Packages Wiki Activity
Set-OPS-Public/docs/audit/preuve-2026-08-27.md

89 lines
9.6 KiB
Markdown
Raw Normal View History

audit : rapport de preuve du jour (49 OK, apres correction du retour du site) Rejoue apres les deux corrections portees par SITE-Chezlepro (8c28641) : la patte 192.168.11.17 de la frontiere sur `grappe-controle`, et `proxmox_api_host` passe d'un nom d'hyperviseur a une adresse. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-27 15:41:08 -04:00
# Preuve de conformite — Set-OPS — 2026-08-27
> Genere par `make prouver` (`scripts/prouver.py`). **Rejouable** : relancer
> reproduit ce rapport. Chaque preuve rejoue l'outillage existant du depot ;
> aucune validation n'est reimplementee ici. Voir le mode d'emploi :
> [`docs/audit/README.md`](README.md), et le registre trace :
> [`docs/audit/affirmations.md`](affirmations.md).
- **Instance** : `instance` — inventaire `instance/inventories/production/hosts.yml`
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
- **Verdict** : ✅ CONFORME (52 OK · 0 echec · 0 saute)
audit : rapport de preuve du jour (49 OK, apres correction du retour du site) Rejoue apres les deux corrections portees par SITE-Chezlepro (8c28641) : la patte 192.168.11.17 de la frontiere sur `grappe-controle`, et `proxmox_api_host` passe d'un nom d'hyperviseur a une adresse. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-27 15:41:08 -04:00
## Preuves
| # | Preuve | Affirmations | Statut | Detail |
|---|---|---|---|---|
| P01 | Lint (ansible-lint) | AFF-006 | ✅ OK |  |
| P02 | Tests unitaires (inventory_host) | — | ✅ OK | >>> le verrou tient : aucune VM n'aurait ete touchee |
| P03 | Diff-vide du plan — TOUTES les instances | AFF-001, AFF-004, AFF-030, AFF-031, AFF-032 | ✅ OK | 4 instance(s) verifiee(s) — OPS-Chezlepro-lab, OPS-Chezlepro, OPS-Technolibre, OPS-Patient0 : plan et inventaire applique coincident. |
| P04 | Groupes <-> playbooks homonymes | AFF-008 | ✅ OK | |
| P05 | Dependances causales de groupes | AFF-009, AFF-084 | ✅ OK | |
| P06 | Validateurs de registres (serveurs/apps/bases/domaines) | AFF-003 | ✅ OK | Registre des domaines valide. |
| P07 | GUI (node --check) | AFF-033 | ✅ OK | JS du GUI : syntaxe valide (node --check). |
| P08 | Orchestration (couches + graphe) | AFF-070 | ✅ OK | Orchestration coherente : 37 groupes classes, aucun cycle, aucune arete en arriere. |
| P09 | Flux reseau (schema + matrice) | AFF-071 | ✅ OK | Flux coherents : 35 rôles, 92 flux, schéma + matrice OK. |
| P10 | Handlers <-> notify | AFF-034, AFF-035 | ✅ OK | Tout notify pointe vers un handler du meme role (49 roles). |
| P11 | Syntaxe des playbooks (--syntax-check) | AFF-083 | ✅ OK | serveur_oauth2_proxy |
| P12 | Existence des runbooks cites | AFF-010, AFF-011, AFF-012, AFF-083 | ✅ OK | 17/17 runbooks/registres cites presents. |
| P13 | Invariants structurels/doctrinaux | AFF-015, AFF-022, AFF-037, AFF-038, AFF-062 | ✅ OK | LICENSE, socle dossier, pas de couches paralleles, SSH clef-only, nftables off : OK. |
| P14 | Pas de chemin lab/ code en dur | AFF-097 | ✅ OK | Aucun chemin instance/inventories/lab/group_vars code en dur. |
| P15 | Modele public socle valide | AFF-022, AFF-099 | ✅ OK | Modele public socle : domaines/serveurs/applications/bases valides. |
| P16 | Inventaire Ansible complet (--list) | AFF-030 | ✅ OK | 5 hotes, 14 groupes (inventaire dechiffre et parse). |
| P17 | Tous les modeles valident (registres + underlay) | AFF-022, AFF-099 | ✅ OK | Les 1 modele(s) decouvert(s) valident. |
| P18 | Gabarit de voute complet | AFF-026 | ✅ OK | Gabarit de voute complet : 18 secret(s) exige(s), tous presents. Voute reelle : 21 cle(s), aucun manque. |
| P19 | Le GUI couvre le schema du plan | AFF-002, AFF-095 | ✅ OK | GUI : les 14 champ(s) des plans reels sont editables (2 plan(s) inspecte(s)), registres toleres : nomenclature. |
| P20 | Adressage 100% derive du seed (aucun stocke) | AFF-001, AFF-003 | ✅ OK | 2 nomenclature(s) : adressage 100% derive du seed index. |
| P21 | Federation : aucun index en collision | AFF-102 | ✅ OK | Federation coherente : 3 instance(s) federee(s), aucun index en collision. |
| P22 | Plan de recette a jour (genere du wiki) | AFF-002 | ✅ OK | Plan de recette à jour (22 sections). |
| P23 | Underlay sans collision avec la plage tenant | AFF-103 | ✅ OK | Underlay conforme : 11 reseau(x), aucune collision avec la plage tenant. |
| P24 | Frontiere nord/sud : acces d'administration declare | AFF-104 | ✅ OK | note : serveur_powerdns declare un port `derive` que le plan du site ne resout pas — aucune regle emise. |
| P25 | Pare-feu Proxmox : est-ouest intra-tenant derive | AFF-107 | ✅ OK | CONFORME : pare-feu Proxmox, 3 tenant(s), 50 groupe(s), 79 regle(s). |
| P26 | Integrations universelles : aucun hote laisse de cote | AFF-108 | ✅ OK | 5 hote(s) x 5 integration(s) universelle(s) : aucune lacune, aucune recopie (0 exemption(s) derivee(s) du service rendu). |
| P27 | Propriete des intrants : hebergeur et tenant separes | AFF-109 | ✅ OK | 8 cle(s) de cluster chez l'hebergeur, aucune recopiee dans les group_vars du tenant. |
| P28 | Pools Proxmox : un par tenant, sans collision | AFF-110 | ✅ OK | CONFORME : 3 pool(s) Proxmox, 35 VM placee(s), aucun nom ni VMID en collision. |
| P29 | Authentification : chaque role declare sa position | AFF-111 | ✅ OK | 29 role(s) serveur declares (interne-sans-auth 2, ldap-direct 2, sans-auth-humaine 18, socle-identite 2, web-sso 5) ; 2 lacune(s) nommee(s) : serveur_loki, serv |
| P30 | SDN EVPN : zones, VNets et sous-reseaux derives | AFF-112 | ✅ OK | CONFORME : SDN EVPN, 3 zone(s), 15 VNet(s), 15 sous-reseau(x), aucune collision. |
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
| P31 | Documentation : tout ce que le depot FAIT est nomme | — | ✅ OK | 51 scripts expliques et atteignables, 104 cibles make documentees, 61 roles avec README. |
audit : rapport de preuve du jour (49 OK, apres correction du retour du site) Rejoue apres les deux corrections portees par SITE-Chezlepro (8c28641) : la patte 192.168.11.17 de la frontiere sur `grappe-controle`, et `proxmox_api_host` passe d'un nom d'hyperviseur a une adresse. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-27 15:41:08 -04:00
| P32 | Intrants exiges par les roles : tous fournis | — | ✅ OK | CONFORME : 14 exigence(s) de role, toutes satisfaites (39 cle(s) declaree(s) par l'instance). |
| P33 | Aucune collision de port entre roles co-localises | — | ✅ OK | CONFORME : 33 revendication(s) de port, aucune collision entre roles co-localises (16 groupes). |
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
| P34 | Chaque document declare son lecteur | — | ✅ OK | 42 document(s) declarent leur lecteur (25 genere(s) exempte(s)). |
audit : rapport de preuve du jour (49 OK, apres correction du retour du site) Rejoue apres les deux corrections portees par SITE-Chezlepro (8c28641) : la patte 192.168.11.17 de la frontiere sur `grappe-controle`, et `proxmox_api_host` passe d'un nom d'hyperviseur a une adresse. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-27 15:41:08 -04:00
| P35 | Toute application exigeant une base en a une au plan | — | ✅ OK | 0 application(s) exigeant une base l'ont toutes (0 entree(s) au registre). |
| P36 | Tout detenteur d'etat porte une sauvegarde | — | ✅ OK | 2 hote(s) detiennent de l'etat, tous porteurs de `client_backup` (9 groupe(s) au catalogue). |
| P37 | Le placement du tenant existe chez son hebergeur | — | ✅ OK | placement confronte a l'hebergeur monte (SITE-Chezlepro) : noeud, stockage, pont — tous offerts. |
| P38 | Catalogue des services : la carte dit ce que le moteur fait | — | ✅ OK | Catalogue a jour : 36 role(s) serveur/client tous nommes, 37 groupe(s) cite(s) en table existent tous. |
| P39 | Glossaire : tout mot employe est enseigne | — | ✅ OK | Glossaire complet : 81 terme(s) du jargon expliques, 15 lien(s) valides, 27 page(s) de wiki toutes atteignables. |
| P40 | Parente : l'ecosysteme sait de quoi il descend | — | ✅ OK | Parente coherente : 4 depot(s), tous retrouves, tous porteurs d'un remote. |
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
| P41 | Resolution d'instance : une seule, partagee | — | ✅ OK | Resolution unique : 47 script(s) passent par `inventory_rules`, 3 exemption(s) nommee(s). |
audit : rapport de preuve du jour (49 OK, apres correction du retour du site) Rejoue apres les deux corrections portees par SITE-Chezlepro (8c28641) : la patte 192.168.11.17 de la frontiere sur `grappe-controle`, et `proxmox_api_host` passe d'un nom d'hyperviseur a une adresse. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-27 15:41:08 -04:00
| P42 | L'edge porte les noms qu'il publie | — | ✅ OK | 4 edge(s) emettent un certificat portant les noms publies (OPS-Chezlepro-lab/principal, OPS-Chezlepro/principal, OPS-Technolibre/principal, OPS-Patient0/product |
| P43 | Frontiere : le devis voit les machines du site | — | ✅ OK | Devis de la frontiere : 5 machine(s) du plan retrouvees, 56 regle(s) du site. |
| P44 | Integrations : le serveur avant ses clients | — | ✅ OK | 4 integration(s) appliquent leur serveur avant leurs clients. |
| P45 | Pare-feu Proxmox : arme sur les VNet SDN, jamais ailleurs | — | ✅ OK | Le pare-feu Proxmox ne s'arme que sur un VNet SDN (4 cas evalues, dont un qui doit rendre VRAI). |
| P46 | Plancher /etc/hosts : un seul role en decide | — | ✅ OK | Un seul maitre du plancher — roles/hosts_statiques/tasks/main.yml : manage_etc_hosts: false ; et le gabarit maitre est pose (roles/hosts_statiques/templates/hos |
| P47 | Zones inverses : couvrir l'occupe, et rien de plus | — | ✅ OK | Les zones inverses couvrent l'occupe et rien de plus (5 cas evalues, dont un site a quatre zones et un tenant a une). |
| P48 | La carte d'orientation designe ce qui existe, et compte juste | — | ✅ OK | La carte designe 84 chemin(s) qui existent, et ses 7 chiffres correspondent a la mesure. |
| P49 | Registre des flux : la matrice d'audit est a jour | — | ✅ OK | Le registre des flux reproduit exactement ce que les `meta/flux.yml` declarent (110 lignes). |
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
| P50 | Silences : un refus muet est declare, place en dernier, et motive | — | ✅ OK | 2 silence(s) declare(s), tous en sequence > 1 (la plus haute des 121 regles `pass`), tous non consignes et tous motives. |
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
| P51 | Collections : toutes declarees, toutes epinglees | — | ✅ OK | 3 collection(s) et 2 bibliotheque(s) Python declarees et epinglees : ansible.posix==1.6.2, community.general==10.3.0, community.postgresql==3.10.2 |
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
| P52 | Materialiser n'exige pas d'entrer dans le tenant | — | ✅ OK | `creer-vm` confirme par l'agent invite (API des hyperviseurs, deja utilisee pour creer), sans exiger d'entrer dans le tenant. |
audit : rapport de preuve du jour (49 OK, apres correction du retour du site) Rejoue apres les deux corrections portees par SITE-Chezlepro (8c28641) : la patte 192.168.11.17 de la frontiere sur `grappe-controle`, et `proxmox_api_host` passe d'un nom d'hyperviseur a une adresse. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-27 15:41:08 -04:00
## Couverture des affirmations ✅ du registre
Chaque affirmation ✅ automatisable est couverte par la preuve indiquee ci-dessus.
Les ✅ **structurelles/doctrinales** non rejouables par une commande (ex. AFF-005
`make`=aide, AFF-014 ciblage groupe, AFF-024 `instancier-appliquer`, AFF-051 autorite
d'AGENTS.md, AFF-073/075 gardes `make`, AFF-090 wiki) ont ete verifiees a l'audit ;
elles restent hors du harnais recurrent (rien d'executable a rejouer).
## Declarations d'intention (⚪ invérifiables localement — assumees)
Ces affirmations ne sont pas rejouables hors production ; elles sont **assumees**
comme declarations d'intention, non comme preuves :
- **AFF-036** — « testables avec `--check` autant que possible » : verifiable seulement
contre une flotte vivante.
- **AFF-091** — contenu pedagogique du wiki : affirmations conceptuelles.
- **AFF-096** — « GUI 100 % francais » : revue exhaustive des libelles rendus, non automatisee.
- **AFF-007** — hote d'exemple `web-frontal-01` : placeholder assume.
_Rapport genere le 2026-08-27._
Reference in a new issue Copy permalink