Daniel Allaire
cccb4e5b43
Some checks are pending
verifier / verifier (push) Waiting to run
Icinga livre son exemple avec root@localhost — une adresse que personne ne lit. Une supervision qui voit tout et n en parle a personne a le meme effet qu aucune supervision, en plus couteux : elle rassure. serveur_icinga_destinataire cree un utilisateur dans le groupe auquel les notifications sont deja assignees (Icinga refuse deux objets de meme nom, on ne peut pas redefinir l exemple ; on en ajoute un autre, l exemple reste muet). Vide, aucun destinataire n est pose ET LE DEPLOIEMENT LE DIT — plutot que de laisser croire qu une alerte partira. Eprouve : message expedie par le relais du site, status=sent (250 2.0.0 Ok), livre directement a mx.chezlepro.ca sans intermediaire ni dependance envers un locataire. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019f91zs9SDdwSzL2CVei6on
83 lines
4.2 KiB
YAML
83 lines
4.2 KiB
YAML
---
|
|
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([])) }}
|
|
|
|
# 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: ""
|