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.1 KiB

Raw Blame History

Sauvegardes (3-2-1)

Unité d'apprentissage. Moule : ① concept → ② Set-OPS → ③ transférable → ④ à toi de jouer.

① Le concept (générique)

Sauvegarder quoi ? Pas forcément « tout ». Si ton infra est reconstructible (par du code), les machines ne sont pas précieuses — c'est la donnée d'état (non régénérable) qui l'est.

La règle 3-2-1 : 3 copies, sur 2 supports, dont 1 hors-site. Une seule copie n'est pas une sauvegarde.

Logique vs image : logique = un export applicatif cohérent (pg_dump, slapcat) ; image = une copie brute du disque/VM. La logique est fine et portable ; l'image est grosse et rapide à restaurer.

La vérité qui fait mal : une sauvegarde jamais restaurée n'existe pas. La restauration testée est le seul critère. « Ça a tourné » ≠ « ça restaure ».

Trois propriétés d'une bonne sauvegarde : chiffrée (au repos), dédupliquée (économe), avec rétention (garder N jours/semaines, purger le reste).

② Comment Set-OPS le fait

Choix fondateur : sauvegarder la donnée (l'infra est reconstructible par le code + le template), pas les VM.

Pièce	Rôle
restic	l'outil : chiffrement côté client, déduplication, rétention.
`serveur_backup`	la cible hors-nœud (un dépôt restic par nœud) — depuis le 2026-09-01, chez l'hébergeur (`site-backup-01`), un compte Unix par écosystème.
`client_backup`	intégration par nœud : jobs déclaratifs (dump + chemins), timer quotidien, rétention — et, depuis le 2026-09-02, vérification de son propre dépôt distant.

Qui vérifie a changé. Le dépôt était le seul à voir ce qui arrivait vraiment : un nœud sait qu'il a lancé sa sauvegarde, pas qu'elle a abouti. C'était juste tant que le dépôt vivait dans l'écosystème. Depuis que les écosystèmes déposent chez leur hébergeur — qui héberge du chiffré côté client et ne peut rien juger — la vérification revient au seul qui détient la clé : le nœud lui-même. Il interroge son dépôt distant, et non le fait d'avoir lancé un timer. Une unité verte sur un dépôt vide est exactement ce qui a menti pendant un mois.

Ce qu'on protège, par tiers :

Tier 0 (vital) : les clés de la CA step-ca (/etc/step-ca) — l'ancre de confiance, irremplaçable.
Tier 1 (critique) : bases PostgreSQL (pg_dumpall), annuaire LDAP (slapcat), boîtes /var/vmail, dépôts Forgejo.

Prouvé, pas supposé : chaque tier a été restauré et vérifié (clés CA byte-identiques, les 3 bases PostgreSQL présentes, testmail retrouvé dans l'export LDAP).

③ Pourquoi c'est transférable

Set-OPS	Équivalents ailleurs
restic	BorgBackup · Restic partout · Duplicity
dépôt hors-nœud	NFS · S3/MinIO · un NAS · un cloud souverain
3-2-1, restauration testée	principes universels — vrais pour Veeam, tar+cron, ou un cloud

Tu as appris quoi sauvegarder, la règle 3-2-1, logique vs image, et surtout restaurer-pour-prouver — pas « restic ». Ça vaut pour n'importe quel outil.

④ À toi de jouer

Lance une sauvegarde. Sur un nœud avec client_backup :
```
/usr/local/sbin/setops-sauvegarder.sh
```

Liste les instantanés (le dépôt vit hors-nœud, et hors de l'écosystème) :

# NE PAS RECOPIER UNE ADRESSE ICI : la cible est une valeur du plan, et elle a
# deja change. Le noeud la porte deja, gravee dans son propre script.
eval "$(grep -E '^export RESTIC_' /usr/local/sbin/setops-sauvegarder.sh)"
restic snapshots

Le même dépôt est interrogé chaque nuit par setops-verifier-mon-depot.sh, qui rapporte à Icinga : c'est le nœud, seul détenteur de la clé, qui juge.

Restaure — le vrai test. Restaure dans un dossier temporaire et compare :
```
restic restore latest --target /tmp/rst
diff -r /etc/step-ca /tmp/rst/etc/step-ca && echo "RESTAURATION FIDÈLE"
```
(sur infra-pki-01 ; ailleurs, compare le dump correspondant.)
Casse & répare. Supprime un fichier de donnée (une copie de test !), restaure-le depuis l'instantané, vérifie qu'il est identique. Tu viens de sentir que la valeur d'une sauvegarde est la restauration, pas la sauvegarde.

Pour aller plus loin (dépôt)

Rôles : roles/serveur_backup, roles/client_backup.
Philosophie « donnée, pas VM » + les tiers : voir le CHANGELOG (entrée sauvegardes) et les jobs en host_vars.
Le 1 hors-site de la règle 3-2-1 : make depot-hors-site VERS=<répertoire> (playbooks/maintenance/depot-hors-site.yml). Il emporte le dépôt du site — celui de l'hébergeur et ceux des locataires, puisque c'est l'hébergeur qui a pris cette promesse. La copie est opaque, et l'empreinte est prise à la source puis recalculée sur la copie : sans cela on rentre chez soi avec un répertoire, pas avec une sauvegarde. Manœuvre exécutée le 2026-09-05 — 233 fichiers, 95,7 Mo, empreintes identiques une à une.

5.1 KiB Raw Blame History