/*
 * 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 %}