|
Some checks are pending
verifier / verifier (push) Waiting to run
`serveur_ops` et `serveur_ops_site` sont deployes sur `site-ops-01` : le moteur, les plans des trois tenants, les collections hors ligne, et la voute de l'underlay deposee CHIFFREE. Le site a son runner. DEUX FORMES DE RUNNER, ET UNE SEULE ETAIT PREVUE. `serveur_ops` exigeait un depot `role: instance` et un `serveur_ops_instance` — la forme d'un runner de TENANT, qui pilote un ecosysteme, monte son plan par le lien `instance`, detient sa voute. Un runner de SITE ne pilote rien : il MATERIALISE le terrain que d'autres occuperont, et son inventaire est dynamique. Son plan declarait donc ses depots de tenants en `role: tenant`, a dessein et avec ses raisons ecrites — et le role le refusait au nom d'une exigence qui ne le concernait pas. Il exige desormais que le runner pilote QUELQUE CHOSE, sans prescrire quoi. Et il posait le lien quand meme : `serveur_ops_instance: ""` donnait `instance -> /opt/setops/`, un repertoire qui n'est l'ecosysteme de personne. Un lien qui existe et ne designe rien est pire qu'un lien absent : tout ce qui le suit croit avoir trouve une instance. LE CERTIFICAT COUVRE LES NOMS DU SERVICE. `client_pki` ne mettait dans ses SAN que le FQDN, le nom court et l'IP. Le clonage du genome a bute dessus : « certificate subject name (site-forge-01.genese.internal) does not match target hostname 'forge.genese.internal' ». Le nom declare `expose:` etait publie partout — plancher, zone DNS — et couvert nulle part. Les expositions que cet hote SERT REELLEMENT entrent maintenant dans le certificat. Un certificat qui revendiquerait le nom d'un service rendu ailleurs serait une usurpation, pas une commodite. `make genome-pousser` — LE RUNNER POUSSE, LE POSTE NE ROUTE PAS. La forge du genome vit DANS le site, sur un reseau que le poste de l'exploitant ne route pas. On ne perce pas un chemin pour lui : on lui retire le role. Le poste emballe les commits dans un `git bundle` — un fichier, verifiable, qui ne demande aucun reseau — et le runner verifie, avance EN AVANCE RAPIDE SEULEMENT, puis pousse avec SA cle, autorisee en ecriture sur ces depots-la seulement. Ce qui est pousse se DERIVE de `serveur_ops_depots`. `DEPOT=<nom>` en cible un seul. Trois pieges rencontres, tous inscrits dans le code : l'outil ne peut pas etre supposé present sur le runner (il ne recevrait cette version qu'APRES la poussee qu'elle sert a faire — le controleur le porte) ; la branche n'est pas toujours `main` (deux depots vivent sur `master`, et le plan le declarait deja) ; le dossier des depots freres contient un espace, d'ou `argv` et non `cmd`. Le juge n'est pas le journal du playbook mais LA FORGE : on demande a son API ce qu'elle porte, et on refuse si ca differe de ce que porte le runner. Six depots verifies. Pourquoi ca comptait : la forge du site etait restee quatre commits derriere le poste, sans que rien ne le signale — dont le correctif qui desarme le pare-feu Proxmox. Un ecosysteme qui se reproduit depuis une forge en retard reproduit ses defauts. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| affirmations.md | ||
| plan-de-recette.md | ||
| preuve-2026-07-20.md | ||
| preuve-2026-07-22.md | ||
| preuve-2026-07-23.md | ||
| preuve-2026-08-01.md | ||
| preuve-2026-08-02.md | ||
| preuve-2026-08-03.md | ||
| preuve-2026-08-04.md | ||
| preuve-2026-08-06.md | ||
| preuve-2026-08-08.md | ||
| preuve-2026-08-09.md | ||
| preuve-2026-08-10.md | ||
| preuve-2026-08-11.md | ||
| preuve-2026-08-12.md | ||
| preuve-2026-08-13.md | ||
| preuve-2026-08-14.md | ||
| preuve-2026-08-18.md | ||
| preuve-2026-08-19.md | ||
| preuve-2026-08-20.md | ||
| preuve-2026-08-23.md | ||
| preuve-2026-08-24.md | ||
| preuve-2026-08-25.md | ||
| preuve-2026-08-26.md | ||
| protocole-operateur-independant.md | ||
| README.md | ||
| reference-avant-reconstruction-2026-08-08.md | ||
Audit de conformité — mode d'emploi
Pour qui : le mainteneur — comment le dispositif de preuve fonctionne, et comment l'étendre.
Ce dossier contient le dispositif qui garde Set-OPS honnête : il ne doit jamais affirmer plus que ce qu'il prouve.
Les pièces
| Fichier | Rôle |
|---|---|
affirmations.md |
Le registre : chaque affirmation publique du dépôt (README, AGENTS, QUICKSTART, docs, wiki, aide make, GUI) tracée vers une commande de preuve et un statut (✅/🟡/❌/⚪), plus le journal des traitements (ce qui a été corrigé, quand, comment). |
scripts/prouver.py |
Le harnais : un orchestrateur mince qui rejoue les preuves automatisables du registre en appelant l'outillage existant (les mêmes scripts que make verifier). Il ne réimplémente aucune validation. |
preuve-AAAA-MM-JJ.md |
La pièce justificative : le rapport horodaté produit par make prouver. Rejouable et présentable (audit, certification, revue). |
protocole-operateur-independant.md |
L'épreuve humaine : le protocole qui met AFF-002 (« exploitable sans IA ») à l'épreuve d'un sysadmin qui n'est pas l'auteur. Aucune commande locale ne peut prouver cette affirmation ; produit un rapport operateur-independant-AAAA-MM-JJ.md. |
Produire une preuve
make prouver
Cela exécute chaque preuve et écrit docs/audit/preuve-<date>.md. La commande sort en
erreur (rc≠0) si une preuve automatisable échoue — utilisable en garde-fou (CI locale,
pré-commit). Une preuve SAUTÉE (⚪) n'est pas un échec.
Prérequis Vault
La preuve P15 (inventaire Ansible complet, ansible-inventory --list) déchiffre le
group_vars de l'instance. Sans ANSIBLE_VAULT_PASSWORD_FILE, elle est automatiquement
sautée (⚪) avec la mention du prérequis — le reste du harnais reste vert, car les
validateurs Python lisent le plan et l'inventaire directement, sans secret. Pour l'inclure :
export ANSIBLE_VAULT_PASSWORD_FILE=~/.config/setops-vault-pass
make prouver
Ce que couvre make prouver
| # | Preuve | Ce qu'elle établit |
|---|---|---|
| P01 | Lint (ansible-lint) |
0 violation, profil production. |
| P02 | Tests unitaires | inventory_host — cas nominal + refus. |
| P03 | Diff-vide du plan | l'inventaire est généré depuis le plan (diff vide). |
| P04 | Groupes ↔ playbooks | chaque groupe opérationnel a son playbook homonyme. |
| P05 | Dépendances de groupes | graphe cohérent, aucune entrée orpheline. |
| P06 | Validateurs de registres | serveurs / applications / bases / domaines valides. |
| P07 | GUI | node --check du JS du GUI. |
| P08 | Orchestration | couches + graphe : aucun cycle, aucune arête en arrière. |
| P09 | Flux réseau | schéma + matrice d'audit cohérents. |
| P10 | Handlers ↔ notify | tout notify pointe vers un handler du même rôle. |
| P11 | Syntaxe | --syntax-check de tous les playbooks (via make syntaxe). |
| P12 | Runbooks cités | les fichiers docs/ référencés existent. |
| P13 | Invariants structurels | LICENSE, socle en forme dossier, pas de couches parallèles, SSH clé-only, nftables désactivé par défaut. |
| P14 | Chemins d'inventaire | aucun instance/inventories/lab/group_vars codé en dur. |
| P15 | Modèle public socle |
ses registres (domaines/serveurs/applications/bases) valident. |
| P16 | Inventaire Ansible (voûte) | ansible-inventory --list — sauté sans mot de passe Vault. |
| P17 | Tous les modèles d'instance | chaque modèle découvert valide (pas seulement socle). SETOPS_MODELES=../Set-OPS-Modeles inclut les modèles assemblés privés. |
| P18 | Gabarit de voûte complet | vault.yml.example couvre exactement les secrets que le plan exige (rôles actifs + bases + group_vars). |
| P19 | GUI couvre le plan | tout champ présent dans un plan réel est éditable par le GUI (nomenclature tolérée : le seed index est désormais un intrant ; l'adressage est dérivé, donc rien à éditer). |
| P20 | Adressage dérivé du seed | aucune nomenclature ne stocke d'adressage (supernet, sous-réseau, passerelle, VLAN) : tout se dérive du seul index. Attrape toute rechute vers l'écriture manuelle. |
| P21 | Fédération sans collision | aucune paire d'instances fédérées ne partage un index (mêmes VLAN/VMID sur le trunk). Le garde-fou du multi-instances ; vue avec make instances. |
| P22 | Plan de recette à jour | docs/audit/plan-de-recette.md (les 78 gestes manuels, générés des exercices du wiki) est à jour — il ne peut pas dériver du wiki. Régénérer : make plan-recette. |
| P23 | Underlay sans collision | la fabric physique (underlay.yml : mgmt/iSCSI/Ceph, cluster-global) n'empiète pas sur la plage tenant — VLAN < 1000 et sous-réseaux hors des supernets 10.(10+index).0.0/16. Sautée si underlay.yml absent. Vue : make underlay. |
P17, P18, P19 ferment les angles morts du harnais : il ne vérifiait qu'une instance et le seul modèle
socle. P17 aurait attrapé l'hôte fantôme d'integral; P18, les neuf secrets absents du gabarit Chezlepro ; P19, les champsliens/websocketque le GUI ne savait pas écrire. Chacune a une CLI dédiée (scripts/modeles.py,voute.py,couverture_gui.py) utilisable seule.
Le rapport relie chaque preuve aux affirmations qu'elle couvre (colonne « Affirmations »), et liste à part les déclarations d'intention (⚪ invérifiables localement : AFF-036, 091, 096, 007) — assumées comme intentions, jamais présentées comme prouvées.
Ajouter une preuve
- Ajouter (ou corriger) l'affirmation dans
affirmations.mdavec sa commande de preuve. - Ajouter une entrée à la liste
PREUVESdescripts/prouver.py: soit une ou plusieurs commandes (cmds, toutes doivent renvoyer 0), soit une fonction nativefuncrenvoyant(ok, détail)pour un invariant simple. Renseignerrefsavec les ID d'affirmations. - Ne pas réimplémenter de logique de validation : appeler l'outillage existant
(
scripts/*.py,ansible-lint, ciblesmake). Le harnais orchestre, il ne valide pas.
Rapport avec make verifier
make verifier inclut désormais les preuves : il enchaîne ses vérifications au fil de
l'eau (lint, tests, cohérence, syntaxe — arrêt au premier échec) puis termine par
python3 scripts/prouver.py --verifier — les preuves du registre sans écrire de rapport
(pour ne pas écraser la pièce justificative committée). Ainsi, make verifier échoue si une
preuve échoue.
make prouver (sans --verifier) reste le mode pièce justificative : il exécute tout,
horodate et écrit docs/audit/preuve-<date>.md. Les deux réutilisent le même
outillage. (Quelques vérifications se recouvrent entre les deux étapes — coût assumé : la
sortie détaillée de verifier est conservée, et prouver ajoute les preuves manquantes.)