verifier / verifier (push) Has been cancelled

Details

documentation : la tournee des 74 documents, parce qu un balayage ne lit pas

La revision a commence par un balayage par motifs — chemins morts, cibles make
absentes, comptes derives. Il a trouve une trentaine d ecarts et rate presque
tout le reste : un motif ne voit que ce qui s exprime en motif.

make hote-planifier en est l exemple. La cible EXISTE, donc le controle passait
au vert. C est une cible depreciee qui refuse et sort en 2, recommandee par
AGENTS.md, et qui contredit la REGLE D OR du meme fichier trois ecrans plus
haut. Il fallait lire pour la voir.

74 documents lus un par un. 66 corriges, 8 exacts.

CE QUI ETAIT FRANCHEMENT FAUX

AGENTS.md, la source d autorite, annoncait la flotte pas encore executee contre
des VM reelles. Elle a ete rasee et remontee depuis zero trois fois.
ecosysteme-chezlepro.md, le document montre a un client, portait la meme
phrase : il se sous-vendait gravement.

courriel-conception.md s ouvrait sur aucun role n est encore ecrit, au-dessus de
son propre paragraphe 1 qui les nomme. autorisation.md se terminait sur rien n
est construit alors qu il rapporte des mesures datees du role en fonctionnement.
hebergeur-exploitation.md disait rien n est fait d un depot qui existe.
filiation-emancipation.md se contredisait a deux ecrans de distance.

DES MODELES DECRITS D APRES UN MONDE ANTERIEUR

Le resolveur : cinq documents decrivaient un Unbound par VM en opt-in, trois le
donnaient en exemple d integration FACULTATIVE — il est universel depuis le
2026-08-24. L adressage de nomenclature-vm.md : reseau unique, VLAN 11-15, VMID
a cinq chiffres. Le nommage SDN de sdn-evpn.md contre le code : c est le wiki
qui avait raison.

CE QUI CASSE AU PREMIER ESSAI

Le nom du gabarit dore etait faux a quatre endroits, dont la procedure qui le
FABRIQUE et le critere R2 de l epreuve d operateur independant.
preparer-un-site-hebergeur.md avertissait qu une VM faite a la main serait
detruite : raser derive du plan, il ne la detruira jamais — le risque est l
inverse. Un mot de passe d essai en clair dans un depot public.

DEUX PREUVES ETENDUES, ET UNE QUI SE TROMPAIT ELLE-MEME

P57 couvre les groupes : elle a signale aussitot 29 groupes annonces au-dessus d
un tableau qui en cite 40. P29 confronte le tableau de authentification.md aux
declarations reelles : 12 annonces, 21 reels.

Et P57 imposait un chiffre faux — 56 preuves alors que le depot en porte 57, la
conditionnelle vivant hors de tout comptage. Un garde-fou qui fait respecter une
erreur ajoute l assurance a l erreur.

CE QUI RESTE, ET QU AUCUNE PREUVE NE TIENT

Deux comptes trouves a la main. Et une lacune reelle : rien ne garde les
meta/acces.yml — ni qu un service web-sso en porte un, ni que le groupe qu il
nomme existe. P29 tient les positions d authentification, personne ne tient les
habilitations.

make prouver : CONFORME, 56 OK, 0 echec, 1 saute. 0 lien mort.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q

2026-09-06 16:18:23 -04:00

5 KiB

Raw Blame History

Pour qui : l'exploitant, le jour où il réalise que 1 644 octets valent toute l'installation. À faire une fois, puis à refaire quand une clé change.

Sortir les clés du poste

Ce qui est en jeu

Le code de Set-OPS est répliqué trois fois : eregion, la forge du site, patient 0. Les voûtes chiffrées y sont aussi. Le coffre est solide.

Les clés qui l'ouvrent vivent dans neuf fichiers de ce poste — 1 644 octets — sans aucune copie ailleurs. S'y ajoutent les clés SSH par lesquelles on entre sur les hyperviseurs, la frontière et chaque machine.

Ce qu'on perd avec le poste, par ordre de gravité :

Ce qui disparaît	Conséquence
Le poste seul	Les mots de passe restic restent lisibles sur les machines vivantes (`/etc/setops/restic.pass`) — récupérable, mais douloureux, et plus aucun déploiement possible entre-temps
Le poste et une machine	L'état de cette machine devient illisible
Le poste et le site	Terminal

La manœuvre

make cles-recenser                       # voir ce qui sortirait, sans rien écrire
make cles-exporter VERS=/media/…/CLE     # sortir, chiffrer, RELIRE

Lance-la toi-même, dans ton terminal. gpg demande une phrase de passe : elle ne doit passer ni par un journal, ni par le contexte d'un assistant. C'est la seule façon de s'en assurer.

L'outil refuse trois choses, et chacune a été éprouvée en la faisant échouer :

une destination dans l'infrastructure — ces clés ouvrent les sauvegardes ; les y ranger ferait un coffre dont la clé est à l'intérieur ;
écraser une archive existante — elle est peut-être la seule ;
une archive qu'il n'arrive pas à rouvrir — elle est alors supprimée. Une sauvegarde de clés qu'on ne sait pas ouvrir est pire que rien : elle donne le sentiment d'être protégé.

Il ne montre jamais le contenu des clés — seulement leur nom, leur taille et leur empreinte. De quoi vérifier sans divulguer.

Les deux gestes qui restent, et qui ne sont pas facultatifs

1. La phrase de passe va ailleurs que le support. Séparés, ils ne valent rien l'un sans l'autre ; ensemble, ils valent l'installation. Un papier dans un autre lieu, ou un gestionnaire de mots de passe qui n'est pas sur ce poste.

2. Une seconde copie, dans un autre lieu physique. Un support unique dans un tiroir unique, c'est le problème qu'on vient de fermer, déplacé de quelques mètres.

Les rouvrir — la moitié qui compte

Le jour où l'on s'en sert, le poste est mort. Le dépôt Set-OPS est répliqué trois fois, mais le cloner demande la clé SSH… qui est dans l'archive qu'on essaie d'ouvrir. Une procédure rangée dans le dépôt serait donc inaccessible exactement quand elle sert.

La clé se suffit donc à elle-même. À côté de l'archive :

setops-cles-<poste>.tar.gpg      les clés, chiffrées
restaurer_cles.py                le script, autonome
LISEZ-MOI-RESTAURATION.txt       le mode d'emploi, et les commandes manuelles

Une clé faite avant cette version ne porte pas les compagnons. make cles-compagnons VERS=/media/…/CLE les y dépose sans refaire l'archive : ni phrase de passe redemandée, ni risque d'écraser ce qui est déjà vérifié.

Sur la machine neuve, il ne faut que gpg, python3 et la phrase de passe :

python3 restaurer_cles.py setops-cles-*.tar.gpg --lister   # voir sans rien écrire
python3 restaurer_cles.py setops-cles-*.tar.gpg            # remettre en place

Le script remet chaque fichier à sa place selon son nom, et repose les droits à 0600. Ce n'est pas cosmétique : ssh refuse une clé privée que d'autres peuvent lire, et son message ne dit pas qu'il s'agit d'un droit — une archive extraite depuis un support FAT arrive systématiquement dans cet état. Il refuse aussi d'écraser une clé déjà là : lancé par erreur sur un poste qui fonctionne, il ne détruit rien.

Si même ce script refuse de tourner, le LISEZ-MOI porte les commandes manuelles — gpg, tar, chmod. Les deux chemins ont été éprouvés le 2026-09-05 : export, poste vidé, restauration depuis la clé seule, empreintes comparées — identiques, 4 sur 4, droits 700/600.

L'éprouver pendant qu'on a encore le choix

make cles-restaurer ARCHIVE=/media/…/setops-cles-*.tar.gpg

Il refusera, puisque les clés sont déjà en place — et ce refus est en soi la preuve que l'archive s'ouvre et que la phrase de passe est la bonne. C'est le test le moins cher qui existe, et il vaut d'être refait après chaque changement de clé.

Quand recommencer

Quand une voûte est créée ou sa clé changée (voutes.py), quand une paire SSH de runner est refaite, et à l'arrivée d'un écosystème. make cles-recenser dit en une seconde si l'archive rangée est encore complète : compare le nombre de fichiers et les empreintes.

Ce que ça ne couvre pas

La phrase de passe elle-même : si elle est perdue, l'archive est du bruit. C'est le prix du chiffrement, et c'est pour ça que le geste 1 n'est pas décoratif.

5 KiB Raw Blame History