Set-OPS-Public/roles/serveur_icinga
Daniel Allaire f05f505b88 Reconstruction propre : orchestrateur ordonné, registre des flux + pare-feu
Rend l'écosystème reconstructible en une commande (create+deploy idempotent) et
ajoute la couche « accès » (nftables least-privilege) au zéro-confiance.

Orchestrateur (phase 2) :
- docs/couches-deploiement.yml : registre des couches (socle → pki → services → apps → agents)
- scripts/orchestrer.py : tri par couche + topo intra-couche (graphe) → playbooks/site.yml ordonné
- Makefile : site / deployer-tout / flotte-creer / reconstruire / myDay (+ gardes CONFIRMER)
- docs/dependances-groupes.yml : graphe complété (keycloak→openldap, dovecot, postfix, icingaweb2, nextcloud)

Audit codé-en-dur (phase 1b) : labels/slug OIDC dérivés de l'intrant `organisation`
(serveur_forgejo/grafana/nextcloud) — le moteur ne porte plus de nom de tenant.

Registre des flux réseau (phase 0) :
- meta/flux.yml pour tous les rôles (29 rôles, 63 flux ; schéma + matrice validés)
- scripts/resoudre_flux.py : matrice d'audit (docs/registre-flux.md) + rulesets nftables résolus par hôte
- roles/nftables_baseline : déploie le ruleset résolu (moindre-privilège) quand activé, sinon repli

Correctifs : détection du coffre Vault (chemin production → inventaire réellement résolu).
Outillage : make wiki-publier (publication du wiki pédagogique dans Forgejo).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-07 03:08:09 -04:00
..
defaults Références par FQDN partout : fin des IP codées en dur 2026-07-05 00:40:57 -04:00
handlers Rendre le dry-run (--check) fiable sur les rôles applicatifs 2026-07-01 21:01:53 -04:00
meta Reconstruction propre : orchestrateur ordonné, registre des flux + pare-feu 2026-07-07 03:08:09 -04:00
tasks DRY : rôle utilitaire partagé resoudre_base (résolution BD depuis le registre) 2026-07-03 15:57:06 -04:00
templates Zéro-confiance : IcingaDB→PG en TLS vérifié (cert step-ca) 2026-07-04 20:32:05 -04:00
README.md Set-OPS — moteur d'ecosystemes numeriques souverains (Alliance Boreale) 2026-06-24 20:17:46 -04:00

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.