History

Daniel Allaire 1410fe41ec les cles de signature passent aussi par le cache get_url IGNORE la configuration d apt : le mandataire pose dans /etc/apt/apt.conf.d/ ne vaut que pour apt. Les six cles de signature sortaient donc TOUJOURS en direct, malgre tout le travail sur le remap. Un trou reste ouvert derriere une porte qu on croyait fermee. Et ce n etait pas theorique. Depuis collab-01 : en direct grafana 200 collabora TIMEOUT via le cache collabora 200 La route directe vers Collabora ne passe pas depuis cette zone. Trois cles sur quatre avaient reussi PAR CHANCE, parce que leurs fournisseurs etaient joignables. Le meme geste corrige les deux : plus rien ne sort, et la machine qui n avait pas de route en trouve une. POURQUOI SEULE UNE NAISSANCE POUVAIT LE MONTRER. Mes deploiements de convergence rendaient failed=0 parce que les cles etaient DEJA sur disque et que la tache etait sautee. Le defaut existait depuis le premier commit du remap, invisible a tout deploiement sur une flotte existante. C est l argument de la reconstruction depuis zero, applique a moi-meme. Troisieme reconstruction : 32 minutes, un seul echec - celui-ci. Clonage 3 min 52, zero fatal dans le journal, 963 Mo servis par le cache contre 183 tires de l Internet, soit 81 pourcent servis localement. Et la derive s est effacee toute seule : apt-cacher-ng tournait encore sur forge-01 que plus aucun plan ne declarait. Je proposais de l arreter a la main ; la reconstruction l a fait. Ce qui n est pas au plan n existe pas apres une naissance. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q		2026-09-10 15:41:56 -04:00
..
defaults	les depots tiers passent par le cache, et le tenant n a plus le sien	2026-09-10 14:53:48 -04:00
handlers	Rendre le dry-run (--check) fiable sur les rôles applicatifs	2026-07-01 21:01:53 -04:00
meta	sondes : quatorze, une par role, derivees en objets Icinga	2026-09-10 03:00:21 -04:00
tasks	les cles de signature passent aussi par le cache	2026-09-10 15:41:56 -04:00
templates	cache-apt scindee — et la scission a revele que moteur aurait alarme a tort	2026-09-10 03:27:52 -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.