--- serveur_icinga_paquets: - icinga2 - icingadb - icingadb-redis - postgresql-client # pour importer le schema vers la BD distante serveur_icinga_service_icinga2: "icinga2" serveur_icinga_service_icingadb: "icingadb" serveur_icinga_service_redis: "icingadb-redis" # Depot apt officiel Icinga (paquet trousseau + source signee). serveur_icinga_keyring_url: >- https://packages.icinga.com/icinga-archive-keyring_latest+debian{{ ansible_distribution_major_version }}.deb serveur_icinga_depot_source: >- deb [signed-by=/usr/share/keyrings/icinga-archive-keyring.gpg] https://packages.icinga.com/debian icinga-{{ ansible_distribution_release }} main # Base Icinga DB : resolue depuis le registre par le groupe consommateur. serveur_icinga_groupe: "serveur_icinga" serveur_icinga_db_host: "" # dérivé (FQDN) par resoudre_base au déploiement # Redis dedie a Icinga DB (paquet icingadb-redis). serveur_icinga_redis_host: "localhost" serveur_icinga_redis_port: 6380 serveur_icinga_config: "/etc/icingadb/config.yml" serveur_icinga_schema: "/usr/share/icingadb/schema/pgsql/schema.sql" # TLS vers PostgreSQL (zero-confiance). true = IcingaDB verifie le cert serveur # contre le root_ca step-ca (host dans le SAN). root_ca doit etre lisible (0644). serveur_icinga_db_tls: false serveur_icinga_db_ca: "/etc/step/certs/root_ca.crt" # --- Identite TLS de l'API (5665) --- # Icinga s'emet lui-meme son certificat, avec sa propre AC : il renouvelle tout ce qui # expire sous 30 jours, et les certificats Set-OPS vivent 24 h. Lui servir un certificat # step-ca est donc impossible — il l'ecrase a chaque demarrage (mesure le 2026-08-11). # Le consommateur verifie donc le pair contre l'AC d'Icinga : domaine de confiance ferme, # pair authentifie, plus aucun `curl -k`. # # NodeName aligne sur le FQDN : le certificat auto-emis porte NodeName en CN et en SAN, # et c'est par le FQDN qu'on appelle l'API. Sans cet alignement, aucune verification ne # peut reussir. # DERIVE DE L'INVENTAIRE, pas de `ansible_fqdn`. Le fait depend du resolveur de la # machine et de la forme de /etc/hosts — il a rendu « mon-01 » alors que le FQDN etait # correct (2026-08-12), produisant un certificat SAN=mon-01 que personne ne pouvait # verifier en appelant par le nom complet. L'inventaire, lui, est la meme source que # celle dont `serveur_backup` compose son URL : les deux ne peuvent pas diverger. serveur_icinga_node_name: "{{ inventory_hostname }}.{{ domaine_interne }}" serveur_icinga_ca: "/var/lib/icinga2/ca/ca.crt" # Ou le depot de sauvegarde attend cette AC (cf. serveur_backup_ca_verification). serveur_icinga_ca_destination_depot: "/etc/setops/icinga-ca.crt" # --- Supervision des sauvegardes (resultats passifs pousses par le depot) --- # Le controle porte sur la VERITE DE TERRAIN (l'instantane cote depot), pas sur l'unite # systemd du noeud source : une unite verte sur un depot vide a menti pendant un mois. serveur_icinga_setops_conf: "/etc/icinga2/conf.d/setops-sauvegardes.conf" serveur_icinga_api_conf: "/etc/icinga2/conf.d/setops-api-users.conf" serveur_icinga_api_utilisateur: "setops-depot" serveur_icinga_api_motdepasse: "{{ vault_icinga_api_depot | default('') }}" # Hote portant les depots : DERIVE du groupe, jamais ecrit en dur. serveur_icinga_hote_sauvegarde: "{{ (groups['serveur_backup'] | default([]) | first) | default('') }}" # Noeuds dont on ATTEND un instantane : ceux qui portent client_backup ET detiennent # reellement de l'etat. Meme regle que `client_backup_jobs`, et meme source que P36 — # la liste en clair du catalogue, lue depuis le role qui la possede. serveur_icinga_sauvegarde_attendue: >- {{ (client_backup_groupes_etat | default([]) | map('extract', groups) | select('defined') | flatten | unique | list) | intersect(groups['client_backup'] | default([])) }} # LES NOEUDS DONT ON RAPPORTE LA SANTE : tous ceux du plan. # # `serveur_debian` est le socle — tout hote deploye le porte. Il n'y a donc pas de liste a # tenir : un noeud qui entre dans l'ecosysteme entre dans la supervision, et un noeud # rase en sort. Une liste ecrite a la main aurait ce defaut precis : elle ne bouge que # quand quelqu'un y pense. serveur_icinga_sante_attendue: "{{ groups['serveur_debian'] | default([]) }}" # LES HOTES A DEFINIR, UNE SEULE FOIS — l'union de ce que les controles attachent. # # Icinga REFUSE un `object Host` en double : deux fichiers de controle qui definissent le # meme hote font rejeter TOUTE la configuration, donc AUCUNE supervision. Les hotes vivent # donc dans `setops-hotes.conf`, et les fichiers de controle n'attachent que des services. serveur_icinga_hotes_supervises: >- {{ (serveur_icinga_sante_attendue + serveur_icinga_sauvegarde_attendue + ([serveur_icinga_hote_sauvegarde] if serveur_icinga_hote_sauvegarde else [])) | unique | list }} serveur_icinga_hotes_conf: "/etc/icinga2/conf.d/setops-hotes.conf" serveur_icinga_sante_conf: "/etc/icinga2/conf.d/setops-sante.conf" serveur_icinga_sondes_conf: "/etc/icinga2/conf.d/setops-sondes.conf" # Rempli a l'execution depuis les `meta/supervision.yml` des roles. serveur_icinga_sondes: {} # A QUI LA SUPERVISION PARLE — vide = personne, et on le DIT. # # Icinga livre son exemple avec `root@localhost`. Une supervision qui voit tout et # n'en parle a personne a le meme effet qu'une supervision absente, en plus couteux : # elle rassure. Renseigne, ce champ cree un destinataire dans le groupe auquel les # notifications sont deja assignees. # # Vide, aucun destinataire n'est pose et le deploiement le SIGNALE — plutot que de # laisser croire qu'une alerte partira. serveur_icinga_destinataire: "" # --- Sonde de supervision ----------------------------------------------------------- serveur_icinga_sonde_config_db: /etc/icingadb/config.yml # SEUILS SUR LE BATTEMENT D'ICINGADB, qui bat en continu (releve : 1 s sur un systeme # sain). Les premiers seuils — 15 et 90 min — visaient la fraicheur des ETATS, et # auraient alarme sur un ecosysteme stable ou plus rien ne change. Sur un battement, une # minute de silence est deja anormale. serveur_icinga_sonde_age_avert: 60 serveur_icinga_sonde_age_crit: 300