Commit graph

3 commits

Author SHA1 Message Date
f802e96b42 recette : la donnee REVIENT — restauration eprouvee, pas seulement sauvegarde
On savait que la donnee partait et arrivait. Pas qu'elle revenait.

Trois charges critiques eprouvees :
  - cles de l'AC (infra-pki-01) : restauration + comparaison OCTET POUR OCTET,
    12 fichiers, 11 identiques, root_ca_key et intermediate_ca_key compris. Seul
    ecart : db/000000.vlog, le journal badger de step-ca, qui avance a chaque
    emission. Attendu.
  - annuaire (idm-01) : slapadd -u (essai a blanc) sur le LDIF restaure —
    REJOUABLE, 7 entrees dont uid=sysadmin.
  - bases (data-sql-01) : section forgejo REJOUEE dans une base d'epreuve —
    0 erreur, 130 tables, comptes reels. Production verifiee intacte apres.

Controles negatifs : un LDIF corrompu fait sortir slapadd en 1 ; la garde SQL a
refuse une section mal decoupee.

LE PIEGE pg_dumpall : il ecrit CREATE DATABASE <suivante> AVANT le \connect
correspondant. Decouper « du \connect X au \connect suivant » emporte un ordre
visant une AUTRE base. Ma premiere decoupe l'a fait ; la garde a refuse de
rejouer. Consigne dans runbooks-exploitation.md §5.

valider.yml ne ment plus : il exigeait une restauration de TOUS les noeuds
client_backup, donc echouait sur ceux qui ne detiennent rien et sur les depots
vides. Quatre verdicts desormais (OK / A CONFIRMER / SANS OBJET / ECHEC),
ALIGNES sur ceux de la supervision. Et il prouve que l'annuaire est rejouable,
pas seulement present.

make valider : 0 echec sur toute la flotte.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-12 09:50:51 -04:00
b95a82251b doc : pas de page « ce qui va te mentir » — les pieges ont trouve leur domicile
Trois des cinq pieges restants avaient deja une page depuis que la semaine a
avance : le connect() vers le vide (frontiere-opnsense.md + le controle porte
par frontiere-mesurer), le `make prouver` vert (wiki « Verifier le deploye »),
et le banner exchange. Les deux orphelins — kcadm -s sur une map, grafana-cli
dans une base fantome — s'adressent a qui ECRIT du code, pas a qui reprend
l'exploitation : ils n'ont rien a faire dans un chemin de reprise.

Une page separee aurait redit ce que trois autres disent deja, et aurait donc
vieilli mal — le reproche exact qu'on faisait a sa version longue.

La section ⑤ de « Reprendre l'ecosysteme » porte desormais la REGLE qui les
relie (verifier l'instrument avant d'accuser le composant) et un tableau de
trois lignes qui renvoie chacune a son domicile. Plus de promesse en attente.

Et le banner exchange n'avait AUCUN domicile : le savoir vivait dans un
commentaire du Makefile et trois entrees du CHANGELOG — nulle part ou on le
cherche, exactement le mal que la refonte traite. Ecrit en runbook §3, avec
ses trois causes par frequence et ce qui tranche dans l'ordre.

runbooks-exploitation.md declare aussi son lecteur, comme le veut la
convention validee.

Verifie : chaque renvoi controle un a un, prouver.py 0 (33 OK), plan-recette
inchange.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-09 23:59:02 -04:00
b6952759f5 Doc à jour : unité wiki Autorisation & RBAC + leçon renouvellement + runbooks
Fermeture des dettes de doc :
- nouvelle unité wiki « Autorisation & RBAC » (authZ, exemple Grafana) ;
- section « le renouvellement est un système » dans l'unité PKI ;
- docs/runbooks-exploitation.md (cert expiré, RBAC Grafana, branding).
15 unités wiki.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-04 17:30:13 -04:00