History

Daniel Allaire 5abf20102d le site surveille enfin sa fabric La supervision du site voyait ses sept VM et rien d autre. Au depart, depuis site-mon-01, les trois hyperviseurs, les neuf pattes de la frontiere et sa PROPRE passerelle par defaut rendaient tous 100 pourcent de perte au ping. 16 hotes UP sur 16 dont 9 pattes de frontiere en controle ACTIF 11 cibles Prometheus dont 3 hyperviseurs, job fabric separe LE PARTAGE. Les hyperviseurs portent node_exporter - D-48 l autorise - et exposent 1005 unites systemd avec leur etat, soit ce que la sonde sante mesurait, plus la charge et le disque. Ils n entrent PAS dans le socle : leur appliquer serveur_durci reecrirait le pare-feu, le SSH et les sysctl de la machine qui tient tout le reste. La frontiere, elle, n accueille aucun agent : controle actif, une entree par PATTE, parce qu une interface eteinte coupe une zone pendant que les autres vont bien. ON TIRE, ON NE POUSSE PAS. J avais propose du passif et il avait ete valide ; la mesure a dit non. Un hyperviseur envoie vers un routeur qui ne connait pas les reseaux du site, et sa route par defaut est GELEE (D-57). Le porteur de sante y expirait en 20 s. LE VRAI DEFAUT ETAIT UNE LISTE QUI N A PAS SUIVI. Le mecanisme de routage existait deja sur vmbr0, avec un commentaire du 2026-08-26 tenant exactement le raisonnement qu on venait de refaire. Sa liste s arretait a 10.0.34.0/24 quand le site en declare six : les zones sauvegarde et supervision sont nees, les routes n ont pas suivi. Le symptome ne ressemblait pas a une route manquante - il ressemblait a un pare-feu, puis a un probleme de reseau chez l exploitant. make routes-fabric-etat compare desormais TROIS choses : zones declarees, routes declarees dans /etc/network/interfaces, routes vivantes dans le noyau. Le cas le plus traitre est vivante mais non declaree : tout fonctionne, la supervision est verte, et la panne attend la prochaine maintenance. Eprouvee dans les deux sens. Deux defauts trouves en construisant. bifrost-2 est un nom RESERVE, pas un boitier - l underlay le disait en prose, illisible par le moteur ; il porte desormais etat: reserve. Et un service passif n existe que pour un hote qui peut POUSSER : l appartenance a un groupe sert deux choses qui ne coincident pas toujours, a qui l on deploie et de qui l on attend un rapport. Les commutateurs restent dehors, choix de l exploitant, coherent avec D-48. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q		2026-09-10 18:50:43 -04:00
..
defaults	le site surveille enfin sa fabric	2026-09-10 18:50:43 -04:00
handlers	Rendre le dry-run (--check) fiable sur les rôles applicatifs	2026-07-01 21:01:53 -04:00
meta	le site surveille enfin sa fabric	2026-09-10 18:50:43 -04:00
tasks	un fichier vide existe, et une sonde pour les correctifs	2026-09-10 17:26:35 -04:00
templates	le site surveille enfin sa fabric	2026-09-10 18:50:43 -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.