From 51b8165221b35f7de065a29accf947de2f749102 Mon Sep 17 00:00:00 2001 From: Daniel Allaire Date: Mon, 28 Sep 2026 11:18:32 -0400 Subject: [PATCH] icinga : deux temoins de sauvegarde, et non l un ou l autre Au site, la verification que chaque noeud fait de son depot visait un service que le gabarit ne creait que sans depot dans l ecosysteme : 404 toutes les 4 h depuis le 20 septembre sur site-forge-01, site-mon-01 et site-pki-01. Les deux temoins existent maintenant ; six services au vert, relus dans Icinga. Co-Authored-By: Claude Opus 5.5 --- CHANGELOG.md | 21 ++++++++++ .../templates/setops-sauvegardes.conf.j2 | 38 ++++++++++++------- 2 files changed, 46 insertions(+), 13 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 088deec..a654f6a 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,5 +1,26 @@ # CHANGELOG — Set-OPS +## 2026-09-28 (1) — La sauvegarde de la forge du génome passait ; sa vérification parlait dans le vide + +**Question de l'exploitant : la sauvegarde de `site-forge-01` passe-t-elle vraiment ?** Oui, +et c'est maintenant mesuré jusqu'à la restauration : `setops-sauvegarde` réussit chaque nuit +(dernier instantané 2026-09-28 02:43, 9 conservés, ~45 Mio), et `set-ops-public.git` +restauré depuis `latest` passe `git fsck`, avec pour tête `859ac07` — exactement ce que la +forge portait à 02:43, avant les poussées de la journée. + +**Ce que la mesure a trouvé en chemin.** La vérification que chaque nœud fait de SON dépôt +(`setops-verification-depot`, celle qui détient la clé) échouait toutes les quatre heures +depuis le 2026-09-20 sur `site-forge-01`, `site-mon-01` et `site-pki-01` : 48 fois +« ECHEC du rapport Icinga : 404 No objects found ». Le nœud rapportait à +`!sauvegarde` ; `setops-sauvegardes.conf.j2` ne créait ce service que dans un +écosystème SANS dépôt. Le site en a un (`site-backup-01`) : seuls existaient les services +du témoin du dépôt, `site-backup-01!sauvegarde: ` — au vert, et donc crus complets. + +Le gabarit choisissait l'un OU l'autre témoin ; il crée désormais les deux quand un dépôt +existe. Déployé sur `site-mon-01`, vérification relancée sur les trois nœuds : six +services au vert, et les deux témoins disent la même chose (1723 fichiers, 40 Mo pour la +forge). Chez les tenants, sans dépôt, rien ne change. + ## 2026-09-27 (1) — Patient 0 effacé, l'index 29 libéré Ses machines n'existaient plus depuis le 2026-09-06 (D-83), mais son plan restait sur diff --git a/roles/serveur_icinga/templates/setops-sauvegardes.conf.j2 b/roles/serveur_icinga/templates/setops-sauvegardes.conf.j2 index 7d4dd4c..e182a30 100644 --- a/roles/serveur_icinga/templates/setops-sauvegardes.conf.j2 +++ b/roles/serveur_icinga/templates/setops-sauvegardes.conf.j2 @@ -29,10 +29,25 @@ object CheckCommand "setops-passif" { command = [ "/bin/true" ] } +{# + DEUX TEMOINS, ET NON L'UN OU L'AUTRE (2026-09-28). + + Ce fichier choisissait : s'il existait un depot dans l'ecosysteme, les services + s'attachaient au DEPOT ; sinon, aux NOEUDS. Or depuis que « la verification suit la + cle », `client_backup` installe sa verification sur CHAQUE noeud, depot ou pas. Au + site, qui a son depot (`site-backup-01`), le rapport des noeuds visait donc un service + que ce fichier n'avait pas cree : `site-forge-01`, `site-mon-01` et `site-pki-01` + ont recu un 404 toutes les quatre heures du 2026-09-20 au 2026-09-28, et leur + verification — la seule qui detienne la cle — n'est arrivee nulle part. Leur unite + echouait ; Icinga, lui, ne voyait que le temoignage du depot, et le croyait complet. + + Les deux se completent : le depot dit ce qu'on peut affirmer SANS lire (des octets + arrivent, et quand) ; le noeud dit ce qu'on ne sait qu'AVEC la cle (l'instantane + s'ouvre, il n'est pas vide). Ils ont chacun leur service. +#} {% if serveur_icinga_hote_sauvegarde %} {# - L'ECOSYSTEME A SON PROPRE DEPOT : c'est LUI qui rapporte, parce qu'il est le seul a - voir ce qui est reellement arrive. Les services s'attachent donc a son hote. + LE TEMOIN DU DEPOT : ce que l'hote des depots peut affirmer sans pouvoir lire. #} {% for noeud in serveur_icinga_sauvegarde_attendue | sort %} object Service "sauvegarde: {{ noeud }}" { @@ -45,19 +60,17 @@ object Service "sauvegarde: {{ noeud }}" { vars.setops_source = "{{ noeud }}" } {% endfor %} -{% else %} +{% endif %} {# - AUCUN DEPOT DANS CET ECOSYSTEME — le cas normal depuis qu'ils deposent chez leur - HEBERGEUR (2026-09-02). + LE TEMOIN DU NOEUD — toujours, qu'il y ait un depot dans l'ecosysteme ou non. - Le site heberge des octets chiffres COTE CLIENT : il ne peut ni les lire, ni dire - s'ils valent quelque chose. La verification revient donc au seul qui detient la cle, - le NOEUD lui-meme — et le service s'attache a lui, ce qui est d'ailleurs plus juste : - la sauvegarde de `idm-01` est un attribut de `idm-01`, pas d'une machine tierce. + Le depot heberge des octets chiffres COTE CLIENT : il ne peut ni les lire, ni dire + s'ils valent quelque chose. Seul le NOEUD, qui detient la cle, le peut — et le + service s'attache a lui, ce qui est d'ailleurs plus juste : la sauvegarde de `idm-01` + est un attribut de `idm-01`, pas d'une machine tierce. - Le service n'est plus nomme « sauvegarde: » mais simplement « sauvegarde » : - le nom du noeud est desormais porte par l'hote. Repeter le nom dans le service - donnerait « idm-01 / sauvegarde: idm-01 ». + Le service est nomme simplement « sauvegarde » : le nom du noeud est porte par + l'hote. Repeter le nom dans le service donnerait « idm-01 / sauvegarde: idm-01 ». #} {% for noeud in serveur_icinga_sauvegarde_attendue | sort %} object Service "sauvegarde" { @@ -70,4 +83,3 @@ object Service "sauvegarde" { vars.setops_source = "{{ noeud }}" } {% endfor %} -{% endif %}