Daniel Allaire
8890c997af
Some checks are pending
verifier / verifier (push) Waiting to run
La doctrine des runners decrit trois portees depuis le 2026-08-22 : calculer plan -> inventaire aucune voute serveur_ops configurer roles sur ses machines voute du TENANT <- revendiquee, jamais recue materialiser creer/detruire des VM voute du SITE serveur_ops_site La deuxieme ligne etait un trou. RIEN ne deposait jamais la voute d'un tenant sur son runner. Un runner pouvait deriver son inventaire et ne rien pouvoir en faire : chaque role qui demande un secret echouait sur son assertion, et l'echec ne disait pas qu'il manquait un FICHIER, seulement que les valeurs etaient vides. Decouvert en preparant la reconstruction de Chezlepro. Le runner du SITE peut materialiser ses quinze machines ; il ne peut pas les configurer, parce que Chezlepro a sa PROPRE autorite de certification — donc `client_pki` y reclame un secret de Chezlepro. Le runner du site ne l'a pas, et NE DOIT PAS l'avoir : c'est la ligne qui rend l'hebergement mutualise defendable. `serveur_ops_tenant` est le symetrique exact de `serveur_ops_site` : un MARQUEUR, pas un installateur. Il depose la voute `decrypt: false`, puis RELIT l'en-tete du fichier depose — une voute dechiffree par accident est une fuite silencieuse. Le dossier d'inventaire (`principal` ou `production`) se DECOUVRE sur la machine plutot que d'etre ecrit. Pourquoi un role a part et non une option de `serveur_ops` : donner sa voute a un runner est un POUVOIR, pas un reglage. Le declarer au plan force a repondre a « cette machine a-t-elle le droit de configurer cet ecosysteme ? » — une option activee par defaut y repondrait a notre place. CHEZLEPRO LISAIT ENCORE SON GENOME CHEZ PATIENT 0. Trouve au passage, et bloquant pour la reconstruction : `serveur_ops_forge_amont` pointait sur `10.29.16.11` — la forge de patient 0, l'amont d'avant que le site ait la sienne. D-81 a tranche depuis. Laisse tel quel, Chezlepro se serait reconstruit depuis un moteur perime, sur un reseau que le decoupage en zones a de toute facon deplace. Corrige vers la forge du site, PAR SON IP — `forge.genese.internal` appartient a la zone souveraine du site, et un tenant ne resout que la sienne ; le certificat SERVI porte bien `IP Address:10.0.33.11`. La racine de l'AC du site est desormais versionnee a cote de la carte de la fabric a laquelle elle appartient, et son chemin se DERIVE du symlink `underlay.yml` : il vaut depuis le poste comme depuis un runner. Le role est inscrit dans les quatre registres qui l'exigeaient — couches de deploiement, graphe des dependances, catalogue des services, carte d'orientation. Ce sont les preuves P08, P38 et P48 qui l'ont reclame, chacune a son tour. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
84 lines
9 KiB
Markdown
84 lines
9 KiB
Markdown
# Preuve de conformite — Set-OPS — 2026-08-26
|
||
|
||
> 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** : `/home/danallaire/Espace Chezlepro/DépôtsSurForge/Set-OPS-public/instance` — inventaire `/home/danallaire/Espace Chezlepro/DépôtsSurForge/Set-OPS-public/instance/inventories/production/hosts.yml`
|
||
- **Verdict** : ✅ CONFORME (47 OK · 0 echec · 1 saute)
|
||
|
||
## Preuves
|
||
|
||
| # | Preuve | Affirmations | Statut | Detail |
|
||
|---|---|---|---|---|
|
||
| P01 | Lint (ansible-lint) | AFF-006 | ✅ OK | [0m[0m |
|
||
| 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 | ⚪ SAUTE | Voute chiffree sans ANSIBLE_VAULT_PASSWORD_FILE (prerequis AFF-026). |
|
||
| 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 non lisible ici : verification sautee.) |
|
||
| 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. |
|
||
| P31 | Documentation : tout ce que le depot FAIT est nomme | — | ✅ OK | 50 scripts expliques et atteignables, 104 cibles make documentees, 61 roles avec README. |
|
||
| 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). |
|
||
| P34 | Chaque document declare son lecteur | — | ✅ OK | 42 document(s) declarent leur lecteur (24 genere(s) exempte(s)). |
|
||
| 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. |
|
||
| P41 | Resolution d'instance : une seule, partagee | — | ✅ OK | Resolution unique : 46 script(s) passent par `inventory_rules`, 3 exemption(s) nommee(s). |
|
||
| 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. |
|
||
|
||
## 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-26._
|