Daniel Allaire
51b8165221
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>
85 lines
4 KiB
Django/Jinja
85 lines
4 KiB
Django/Jinja
/*
|
|
* Gere par Set-OPS (role serveur_icinga). Ne pas editer a la main.
|
|
*
|
|
* Supervision des sauvegardes. Le controle ne porte PAS sur l'unite systemd du noeud
|
|
* source : une unite verte sur un depot vide est exactement ce qui a menti pendant un
|
|
* mois (2026-07-03 -> 2026-08-11). Il porte sur la VERITE DE TERRAIN, cote depot :
|
|
* l'instantane du noeud existe-t-il, est-il RECENT, et n'est-il pas VIDE.
|
|
*
|
|
* Les HOTES sont definis ailleurs (`setops-hotes.conf`) depuis le 2026-09-09 : deux
|
|
* fichiers qui definissent le meme `object Host` font rejeter TOUTE la configuration.
|
|
* Ce fichier n'attache que des services.
|
|
*
|
|
* QUI POUSSE : CHAQUE NOEUD, POUR SON PROPRE DEPOT. Cette ligne a dit le contraire
|
|
* jusqu'au 2026-09-14 — elle nommait `backup-01`, « le seul a pouvoir lire ses depots ».
|
|
* Or `backup-01` a ete RETIRE le 2026-09-02, et c'est tout le sujet : le site heberge des
|
|
* octets chiffres cote client, il ne peut pas les ouvrir, donc pas les juger.
|
|
*
|
|
* LA VERIFICATION SUIT LA CLE. Chaque noeud verifie SON depot distant et rapporte
|
|
* lui-meme, par `client_backup` et son minuteur. Le code de ce fichier avait suivi la
|
|
* decision — il attache les services aux vrais noeuds — mais l'en-tete decrivait encore
|
|
* un acteur disparu, a celui-la meme qui l'ouvrirait pour comprendre qui pousse.
|
|
* Le `ttl` porte dans chaque envoi fait la fraicheur : sans nouvelle, Icinga bascule tout
|
|
* seul en « expire ». C'est le SILENCE qui doit alerter, pas seulement l'echec — le
|
|
* silence est precisement ce qui n'a alerte personne.
|
|
*/
|
|
|
|
object CheckCommand "setops-passif" {
|
|
// Les resultats arrivent par l'API ; cette commande n'est jamais executee.
|
|
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 %}
|
|
{#
|
|
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 }}" {
|
|
host_name = "{{ serveur_icinga_hote_sauvegarde }}"
|
|
check_command = "setops-passif"
|
|
enable_active_checks = false
|
|
enable_passive_checks = true
|
|
volatile = false
|
|
max_check_attempts = 1
|
|
vars.setops_source = "{{ noeud }}"
|
|
}
|
|
{% endfor %}
|
|
{% endif %}
|
|
{#
|
|
LE TEMOIN DU NOEUD — toujours, qu'il y ait un depot dans l'ecosysteme ou non.
|
|
|
|
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 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" {
|
|
host_name = "{{ noeud }}"
|
|
check_command = "setops-passif"
|
|
enable_active_checks = false
|
|
enable_passive_checks = true
|
|
volatile = false
|
|
max_check_attempts = 1
|
|
vars.setops_source = "{{ noeud }}"
|
|
}
|
|
{% endfor %}
|