supervision : c'est le DEPOT qui dit ou en sont les sauvegardes
Icinga ne surveillait rien : aucun objet Host ni Service de Set-OPS, seulement
la config Debian d'origine sur localhost.
Superviser setops-sauvegarde.service aurait reproduit le defaut du jour meme :
l'unite etait VERTE sur onze noeuds pendant qu'elle n'emportait rien. Le noeud
sait qu'il a LANCE sa sauvegarde, pas qu'elle est ARRIVEE. backup-01 evalue donc
ses depots et pousse un resultat passif par noeud vers l'API Icinga.
Trois criteres, parce qu'un seul suffit a mentir : l'instantane existe, il est
recent (26 h / 50 h), il contient au moins un fichier.
Le sens du flux est delibere : le depot parle a la supervision, jamais l'inverse
— compromettre mon-01 ne donne aucun acces aux sauvegardes.
Le ttl de 6 h fait la fraicheur : si le rapporteur se tait, Icinga perime les
services tout seul. C'est le silence qui a laisse le defaut vivre un mois.
Deux erreurs corrigees par la mesure :
- --data-urlencode refuse en Bad Request (l'API veut du JSON) ; le flux, le TLS
et l'auth marchaient, seule la charge etait perdue.
- le seuil « vide » en octets signalait a tort idm-01 (2363 o) : un export LDIF
d'un annuaire a un compte pese cela. « Vide » se mesure en FICHIERS. Et le
verdict est un AVERTISSEMENT : la machine ne distingue pas « les donnees ont
disparu » de « il n'y en a pas encore ».
Reserve assumee : curl -k — l'API presente le cert de sa propre AC, pas step-ca.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 21:39:05 -04:00
|
|
|
/*
|
|
|
|
|
* 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 resultats sont POUSSES par `backup-01`, qui est le seul a pouvoir lire ses depots.
|
|
|
|
|
* 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" ]
|
|
|
|
|
}
|
|
|
|
|
|
2026-09-02 18:53:44 -04:00
|
|
|
{% 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.
|
|
|
|
|
#}
|
supervision : c'est le DEPOT qui dit ou en sont les sauvegardes
Icinga ne surveillait rien : aucun objet Host ni Service de Set-OPS, seulement
la config Debian d'origine sur localhost.
Superviser setops-sauvegarde.service aurait reproduit le defaut du jour meme :
l'unite etait VERTE sur onze noeuds pendant qu'elle n'emportait rien. Le noeud
sait qu'il a LANCE sa sauvegarde, pas qu'elle est ARRIVEE. backup-01 evalue donc
ses depots et pousse un resultat passif par noeud vers l'API Icinga.
Trois criteres, parce qu'un seul suffit a mentir : l'instantane existe, il est
recent (26 h / 50 h), il contient au moins un fichier.
Le sens du flux est delibere : le depot parle a la supervision, jamais l'inverse
— compromettre mon-01 ne donne aucun acces aux sauvegardes.
Le ttl de 6 h fait la fraicheur : si le rapporteur se tait, Icinga perime les
services tout seul. C'est le silence qui a laisse le defaut vivre un mois.
Deux erreurs corrigees par la mesure :
- --data-urlencode refuse en Bad Request (l'API veut du JSON) ; le flux, le TLS
et l'auth marchaient, seule la charge etait perdue.
- le seuil « vide » en octets signalait a tort idm-01 (2363 o) : un export LDIF
d'un annuaire a un compte pese cela. « Vide » se mesure en FICHIERS. Et le
verdict est un AVERTISSEMENT : la machine ne distingue pas « les donnees ont
disparu » de « il n'y en a pas encore ».
Reserve assumee : curl -k — l'API presente le cert de sa propre AC, pas step-ca.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 21:39:05 -04:00
|
|
|
object Host "{{ serveur_icinga_hote_sauvegarde }}" {
|
|
|
|
|
check_command = "hostalive"
|
|
|
|
|
address = "{{ serveur_icinga_hote_sauvegarde }}.{{ domaine_interne }}"
|
|
|
|
|
vars.role = "depot de sauvegarde"
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
{% 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 %}
|
2026-09-02 18:53:44 -04:00
|
|
|
{% else %}
|
|
|
|
|
{#
|
|
|
|
|
AUCUN DEPOT DANS CET ECOSYSTEME — le cas normal depuis qu'ils deposent chez leur
|
|
|
|
|
HEBERGEUR (2026-09-02).
|
|
|
|
|
|
|
|
|
|
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 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 ».
|
|
|
|
|
#}
|
|
|
|
|
{% for noeud in serveur_icinga_sauvegarde_attendue | sort %}
|
|
|
|
|
object Host "{{ noeud }}" {
|
|
|
|
|
check_command = "hostalive"
|
|
|
|
|
address = "{{ noeud }}.{{ domaine_interne }}"
|
|
|
|
|
vars.role = "detenteur d etat"
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
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 %}
|
|
|
|
|
{% endif %}
|