History

Daniel Allaire 4dd4d3755d icinga : le pair est verifie — mais pas avec un certificat step-ca Objectif : supprimer le `curl -k` du rapporteur. Fait, et la maniere a ete imposee par la mesure. SERVIR UN CERTIFICAT STEP-CA SUR L'API EST IMPOSSIBLE. Icinga le dit lui-meme : « Our certificate will expire soon, but we own the CA. Renewing. » Il renouvelle tout certificat expirant sous 30 jours ; les notres vivent 24 h ; possedant une AC, il re-emet avec la sienne et ecrase le notre a chaque demarrage. Collision entre deux politiques de PKI, et la notre n'est pas negociable. Deux decouvertes en chemin, toutes deux par le garde-fou `icinga2 daemon -C` ajoute au role, qui a ARRETE le deploiement avant de redemarrer la supervision : - cert_path/key_path/ca_path sont DEPRECIES depuis 2.8 ; les poser reveille un chemin de code herite qui exige en plus un objet Endpoint ; - l'identite de l'API est le CN du certificat. NodeName valait « mon-01 », donc le SAN aussi, alors qu'on appelle par le FQDN : aucune verification n'aurait pu reussir. NodeName est desormais aligne sur le FQDN. A LA PLACE : Icinga garde son AC (domaine de confiance FERME, legitime) et backup-01 verifie le pair contre CETTE AC, recuperee depuis mon-01 au deploiement. Le pair est authentifie ; seule la racine differe. Controle negatif — une verification qu'on ne teste pas est un ornement : avec la mauvaise AC (step-ca), curl refuse (« unable to get local issuer certificate ») ; avec la bonne, les neuf rapports passent. Sous-AC step-ca ecartee : elle poserait sur l'hote de supervision une cle capable d'EMETTRE pour n'importe quel nom, alors qu'on a choisi le sens du flux pour que compromettre mon-01 ne donne rien. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>		2026-08-12 08:33:50 -04:00
..
defaults	icinga : le pair est verifie — mais pas avec un certificat step-ca	2026-08-12 08:33:50 -04:00
handlers	Rendre le dry-run (--check) fiable sur les rôles applicatifs	2026-07-01 21:01:53 -04:00
meta	supervision : c'est le DEPOT qui dit ou en sont les sauvegardes	2026-08-11 21:39:05 -04:00
tasks	icinga : le pair est verifie — mais pas avec un certificat step-ca	2026-08-12 08:33:50 -04:00
templates	icinga : le pair est verifie — mais pas avec un certificat step-ca	2026-08-12 08:33:50 -04:00
README.md	Set-OPS — moteur d'ecosystemes numeriques souverains (Alliance Boreale)	2026-06-24 20:17:46 -04:00

README.md

serveur_icinga

Supervision active Icinga — cœur de surveillance. Portée actuelle : Icinga 2 + Icinga DB (avec son Redis dédié et sa base PostgreSQL). Icinga Web 2 est différé à une phase dédiée.

Rôle (cœur)

Ajoute le dépôt apt officiel Icinga (trousseau + source signée) et installe icinga2, icingadb, icingadb-redis.
icinga2 api setup + activation de la fonctionnalité icingadb.
Base PostgreSQL via le registre (instance/plan/bases-donnees.yml, entrée icingadb) : PostgreSQL crée la base/compte, ce rôle importe le schéma et écrit /etc/icingadb/config.yml (BD + Redis).

Base de données

Entrée registre icingadb (PostgreSQL sur data-01). Mot de passe partagé via Vault (vault_bd_icingadb), comme Keycloak. Dépendance serveur_icinga requiert serveur_postgresql actif (déjà dans docs/dependances-groupes.yml).

Différé (phase Icinga Web 2)

icingaweb2 + sa 2e base (icingaweb) + PHP-FPM + vhost nginx + assistant de configuration (jeton de setup). À faire proprement avec sa doc verbatim.

Limites / caveats honnêtes

Les pages détaillées Icinga DB/Web ont renvoyé des 404 ; la config Icinga DB (config.yml, chemin du schéma /usr/share/icingadb/schema/pgsql/schema.sql, port Redis 6380) suit la structure documentée standard mais n'a pas pu être vérifiée verbatim — à confirmer/ajuster selon la version installée (variables prévues).
Non testé live (mon-01 planifié).
L'import de schéma s'exécute une seule fois (marqueur /etc/icingadb/.schema-imported).

Prérequis

serveur_postgresql actif (base icingadb créée), accès réseau à data-01:5432.