Alliance-Boreale/Set-OPS-Public
2
0
Fork 0
Code Issues Pull requests 1 Projects Releases Packages Wiki Activity

icinga : deux temoins de sauvegarde, et non l un ou l autre

Browse source 
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 <noreply@anthropic.com>
This commit is contained in:
Daniel Allaire 2026-09-28 11:18:32 -04:00
parent fe9d47c4a6
commit 51b8165221
2 changed files with 46 additions and 13 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

21
CHANGELOG.md
View file

@ -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 à
`<nœud>!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: <nœud>` — 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

38
roles/serveur_icinga/templates/setops-sauvegardes.conf.j2
View file

@ -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: <noeud> » 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 %}