diff --git a/CHANGELOG.md b/CHANGELOG.md index 3b1ceba..109c46d 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,5 +1,36 @@ # CHANGELOG — Set-OPS +## 2026-08-09 — Le wiki rattrape ce que la reconstruction a appris + +Le wiki datait du 3 août — six jours avant tout ce qui précède. Vérifié avant d'y toucher : +**toutes les cibles `make` qu'il cite existent**, aucune commande morte. Il était +factuellement plus sain que craint. + +Deux corrections, dont une qui compte. + +**`La-preuve.md` annonçait « P01–P21 »** ; le harnais est à **P33**. Les trois nouvelles +sont ajoutées au tableau des classes d'erreur — et surtout, la page dit désormais **ce que +ces preuves ne font pas** : elles sont toutes statiques, elles lisent le dépôt, et c'est +dans cet angle mort qu'une AC est restée expirée huit heures sous un harnais vert. + +**`Infra-as-Code-et-idempotence.md` enseignait l'idempotence comme acquise** — « redéployer +un rôle déjà en place → `changed=0` ». Vrai rôle par rôle, faux à l'échelle de la flotte, ce +que personne n'avait mesuré. La page enseigne maintenant depuis les chiffres (924 → 17 → 0) +et raconte ce que les 17 cachaient : un service mort depuis des semaines, et un secret que +le dépôt faisait tourner à chaque déploiement. Elle explique aussi pourquoi il faut +**vérifier le zéro** — 2266 tâches exécutées contre 2152, donc convergence et non silence. + +**Nouvelle unité : `Vérifier-le-déployé`.** C'est la notion que la journée a mise au jour et +qu'aucune page ne portait : la différence entre *valider du code* et *vérifier un système*. +Elle enseigne les trois règles qui séparent un devis utile d'un devis décoratif — ne jamais +redéclarer ce qu'on vérifie, faire une vraie requête plutôt qu'un `connect()`, et se méfier +d'un code de retour pris pour un verdict — puis renvoie au vocabulaire commun +(*drift detection*). + +Sa dernière consigne est celle que je retiens de ces deux jours : **chercher, dans son +propre outillage, une vérification qui n'a jamais échoué, et se demander si c'est parce que +tout va bien ou parce qu'elle ne regarde rien.** + ## 2026-08-09 — Idempotence de la flotte : zéro, et c'est un zéro qui veut dire quelque chose ``` diff --git a/docs/audit/preuve-2026-08-09.md b/docs/audit/preuve-2026-08-09.md index 88c59a0..10b18d1 100644 --- a/docs/audit/preuve-2026-08-09.md +++ b/docs/audit/preuve-2026-08-09.md @@ -7,7 +7,7 @@ > [`docs/audit/affirmations.md`](affirmations.md). - **Instance** : `instance` — inventaire `instance/inventories/principal/hosts.yml` -- **Verdict** : ✅ CONFORME (33 OK · 0 echec · 0 saute) +- **Verdict** : ❌ NON CONFORME (32 OK · 1 echec · 0 saute) ## Preuves @@ -34,7 +34,7 @@ | P19 | Le GUI couvre le schema du plan | AFF-002, AFF-095 | ✅ OK | GUI : les 28 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 : 2 instance(s) federee(s), aucun index en collision. | -| P22 | Plan de recette a jour (genere du wiki) | AFF-002 | ✅ OK | Plan de recette à jour (19 sections). | +| P22 | Plan de recette a jour (genere du wiki) | AFF-002 | ❌ ECHEC | rc=2 : erreur: docs/audit/plan-de-recette.md est PÉRIMÉ (le wiki a changé). Régénérer : make plan-recette. | | P23 | Underlay sans collision avec la plage tenant | AFF-103 | ✅ OK | Underlay conforme : 6 reseau(x), aucune collision avec la plage tenant. | | P24 | Frontiere nord/sud : acces d'administration declare | AFF-104 | ✅ OK | CONFORME : frontiere nord/sud, 31 regles, 2 routes, admin=10.0.0.0/24,192.168.254.2/32,192.168.255.2/32. | | P25 | Pare-feu Proxmox : est-ouest intra-tenant derive | AFF-107 | ✅ OK | CONFORME : pare-feu Proxmox, 2 tenant(s), 38 groupe(s), 64 regle(s). | diff --git a/wiki/Infra-as-Code-et-idempotence.md b/wiki/Infra-as-Code-et-idempotence.md index 09a4fdd..c7fe5db 100644 --- a/wiki/Infra-as-Code-et-idempotence.md +++ b/wiki/Infra-as-Code-et-idempotence.md @@ -30,9 +30,34 @@ en **contrôle de version** (git), donc auditable et réversible. - `make deployer` applique les rôles ; le `Vérifier` (dry-run) **prévisualise** d'abord. - Tout vit dans **git** (ce dépôt) — reproductible, revu, réversible. -Preuve d'idempotence, vue partout cette session : redéployer un rôle déjà en place → -**`changed=0`**. Et un refactor « neutre » (ex. le binding annuaire) → `changed=0` aussi : *même -état voulu = aucune modification*. +### L'idempotence ne se décrète pas : elle se mesure + +Cette page a longtemps affirmé que redéployer un rôle donnait `changed=0`. C'était vrai **rôle +par rôle** — et faux à l'échelle de la flotte, ce que personne n'avait vérifié. Le 2026-08-09, +après une reconstruction complète, on a compté : + +``` +924 taches « changed » rejeu depuis zero (tout est neuf : normal) + 17 taches « changed » second passage (la flotte devrait etre convergente) + 0 taches « changed » apres correction +``` + +**Les 17 n'étaient pas du bruit.** Elles cachaient deux pannes qui ne se signalaient d'aucune +autre façon : + +| Ce qu'on voyait | Ce que c'était | +|---|---| +| 13× « démarrer node_exporter » | le service **était mort** — tué par `SIGHUP` à chaque renouvellement de certificat, donc toutes les 24 h, sur les quatorze hôtes | +| 2× « déployer app.ini » | le dépôt **faisait tourner le secret JWT** de la forge à chaque déploiement, invalidant ses jetons | + +La leçon dépasse Ansible : **un compteur de changements est un instrument de diagnostic.** Tant +qu'il indiquait 17, aucun de ces deux défauts n'était visible — ils se noyaient dans un fond +qu'on avait pris l'habitude d'ignorer. Ramené à zéro, le moindre `changed` sur une flotte non +modifiée devient un signal. + +**Vérifier le zéro, aussi.** Un zéro peut vouloir dire « rien à faire » ou « plus rien ne +travaille ». On a compté les tâches exécutées : **2266 au passage à vide contre 2152 au rejeu**. +Plus de tâches, aucune modification — donc convergence, pas silence. --- diff --git a/wiki/La-preuve.md b/wiki/La-preuve.md index 56ce31d..f2e5afd 100644 --- a/wiki/La-preuve.md +++ b/wiki/La-preuve.md @@ -26,7 +26,7 @@ Trois idées la portent : - **Le registre** : `docs/audit/affirmations.md` — chaque affirmation du dépôt (README, docs, aide `make`, GUI) reliée à une preuve et un statut (✅/🟡/❌/⚪). -- **Le harnais** : `make prouver` rejoue les preuves automatisables (**P01–P21**) et écrit +- **Le harnais** : `make prouver` rejoue les preuves automatisables (**P01–P33**) et écrit `docs/audit/preuve-.md`. `make verifier` les inclut : il **échoue** si une preuve échoue. - **Chaque preuve garde une classe d'erreur.** Extrait : @@ -39,6 +39,15 @@ Trois idées la portent : | P19 | un champ du plan que le **GUI** ne sait pas éditer | | P20 | de l'**adressage stocké** (tout doit dériver du seed) | | P21 | une **collision d'index** entre instances fédérées | +| P31 | une capacité du dépôt **non expliquée** (script muet, cible sans aide, rôle sans README) | +| P32 | un intrant qu'un rôle **exige** et que l'instance ne fournit pas | +| P33 | deux rôles co-localisés qui **revendiquent le même port** | + +> **Ce que ces preuves ne font pas, et il faut le savoir avant de leur faire confiance.** Elles +> sont toutes **statiques** : elles lisent le dépôt, sans un seul appel réseau. Elles établissent +> qu'il est cohérent *avec lui-même* — jamais que le système déployé lui ressemble. C'est dans +> cet angle mort qu'un certificat d'autorité a pu rester expiré huit heures sous un harnais vert. +> La conformité du **déployé** est l'affaire des **devis de service** (voir `docs/devis-services.md`). Ce n'est pas un framework de test parallèle : le harnais **orchestre** l'outillage existant, il ne réimplémente aucune validation. diff --git a/wiki/Vérifier-le-déployé.md b/wiki/Vérifier-le-déployé.md new file mode 100644 index 0000000..542864a --- /dev/null +++ b/wiki/Vérifier-le-déployé.md @@ -0,0 +1,103 @@ +# Vérifier le déployé — quand la preuve statique ne suffit plus + +> **Unité d'apprentissage.** Moule : ① concept → ② Set-OPS → ③ transférable → ④ à toi de jouer. + +--- + +## ① Le concept *(générique)* + +Il y a **deux questions** qu'on confond tout le temps, et seule la première est facile : + +| Question | Ce qu'on lit | Ce que ça prouve | +|---|---|---| +| « Mon **code** est-il cohérent ? » | le dépôt | qu'il ne se contredit pas lui-même | +| « Mon **système** ressemble-t-il à mon code ? » | les machines | qu'il fait ce qu'on a écrit | + +Un test unitaire, un *linter*, une validation de schéma répondent tous à la première. Ils sont +rapides, ils tournent partout, et ils **ne touchent jamais** la machine. C'est leur force et +c'est leur limite. + +La seconde question exige d'aller *demander* au système. Et elle est la seule qui compte le jour +où quelque chose ne marche pas. + +> **Le piège n'est pas d'ignorer la seconde question. C'est de croire que la première y répond.** +> Un tableau de bord tout vert dit « le code est bon », et on le lit « le service fonctionne ». + +--- + +## ② Comment Set-OPS le fait + +Set-OPS a longtemps eu **31 preuves statiques** (`make prouver`) — zéro appel réseau, zéro SSH. +Elles établissent que le dépôt est cohérent avec lui-même : les *handlers* existent, l'adressage +dérive du seed, aucun intrant n'est orphelin. + +Le 2026-08-08, l'autorité de certification de la flotte est restée **expirée pendant huit +heures** sous un harnais entièrement vert. Le renouvellement échouait toutes les quatorze +minutes. Aucune preuve ne pouvait le voir : aucune ne parlait à une machine. + +D'où les **devis de service** — même patron que les devis réseau (D-23/D-24), porté aux services : + +``` +make identite-plan le realm, la fédération LDAP, la politique de mot de passe, les comptes +make certificats-plan ce que le disque porte contre ce que la mémoire sert +make expositions-plan chaque service publié répond-il — depuis l'edge et depuis ton poste +make postgresql-plan le chiffrement est-il imposé, et à quels réseaux +make courriel-plan Postfix → LDAP → LMTP → Dovecot → IMAP, file d'attente comprise +``` + +| Pièce | Rôle | +|---|---| +| un **playbook** (`playbooks/maintenance/devis-*.yml`) | **relève** le déclaré et le réel, dépose un JSON | +| un **script** (`scripts/devis_*.py`) | **compare**, affiche les écarts, sort en code 1 | +| `make deployer` | **répare** — ce n'est pas le rôle du devis | + +**Trois règles qui font la différence entre un devis utile et un devis décoratif :** + +**Le devis ne redéclare jamais ce qu'il vérifie.** Il charge les défauts du rôle et appelle les +résolveurs. Un contrôle qui recopie la valeur attendue ne contrôle rien — il se compare à +lui-même. + +**Une vraie requête, jamais un `connect()`.** À travers un pare-feu qui fait de l'anti-usurpation, +toute connexion TCP réussit, même vers une adresse où rien n'existe. Et en TLS c'est le *client* +qui parle en premier : le silence après connexion ne distingue pas un service sain d'un trou. +Seul un échange applicatif complet tranche. + +**Un code de retour n'est pas un verdict.** Un `502` *est* une réponse, et pourtant le service +est mort derrière. + +--- + +## ③ Pourquoi c'est transférable + +| Set-OPS | Équivalents ailleurs | +|---|---| +| preuves statiques | tests unitaires · *linters* · validation de schéma · `terraform validate` | +| devis de service | tests de bout en bout · sondes *black-box* · `terraform plan` sur l'état réel | +| relevé puis comparaison | *drift detection* — AWS Config, Chef `--why-run`, Puppet `--noop` | + +Le mot que tout le monde emploie est **dérive** (*drift*) : l'écart qui s'installe entre ce qu'on +a déclaré et ce qui tourne. Aucun outil ne l'empêche ; ils aident seulement à la **voir**. + +Et la vraie leçon n'est pas technique : **une garantie qui n'a jamais échoué n'est pas une +garantie, c'est une habitude.** Un contrôle qu'on n'a pas vu dire *non* ne prouve rien — il faut +l'éprouver dans les deux sens, en cassant volontairement ce qu'il surveille. + +--- + +## ④ À toi de jouer + +1. Lance les cinq devis sur ta flotte. Note le temps que ça prend : quelques minutes pour ce qui + demandait une journée d'enquête à la main. +2. **Casse quelque chose exprès** — arrête un service publié, change un port — et relance le + devis concerné. S'il ne dit rien, c'est *lui* qu'il faut réparer, pas le service. +3. Cherche, dans ton propre outillage, une vérification qui n'a **jamais** échoué. Demande-toi si + c'est parce que tout va bien, ou parce qu'elle ne regarde rien. + +| Terme | Ce que tu retiens | +|---|---| +| preuve statique | lit le **code** ; rapide, universelle, aveugle au réel | +| devis / *drift detection* | interroge le **système** ; seule réponse à « est-ce que ça marche ? » | +| test négatif | éprouver qu'un contrôle sait dire **non** | + +Tu as appris **la différence entre valider du code et vérifier un système** — pas « les devis +Set-OPS ». diff --git a/wiki/_Sidebar.md b/wiki/_Sidebar.md index 496289a..0d991ed 100644 --- a/wiki/_Sidebar.md +++ b/wiki/_Sidebar.md @@ -33,6 +33,7 @@ *Flotte & preuve* - [Multi-instance & fédération](Multi-instance-et-fédération) - [La preuve](La-preuve) +- [Vérifier le déployé](Vérifier-le-déployé) **Opérations** - Runbooks → dépôt `docs/runbooks-exploitation.md`