Alliance-Boreale/Set-OPS-Public
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
Set-OPS-Public/roles/serveur_icingaweb2
History
Daniel Allaire 6f2acafdb6 acces : les cinq meta/acces.yml, et le mecanisme qui manque a chacun 
Chaque role web declare le GROUPE qu'il reconnait et ce qu'il lui accorde. Un
troisieme champ s'est impose en ecrivant : `porte_par` — le mecanisme qui
transporte reellement l'habilitation. Sans lui, les declarations auraient decrit
une chaine inexistante.

Etat mesure : grafana `role-realm` (reel) ; forgejo, nextcloud et keycloak
`aucun` ; icingaweb2 `liste-uid` — il NOMME DES PERSONNES, ce que D-66 interdit.

Le maillon manquant est chez Keycloak : `role_assignments` assigne un role a un
UTILISATEUR, et son propre commentaire l'admettait (« en prod, preferer
l'assignation via groupe d'annuaire »). Sans group-ldap-mapper, les groupes LDAP
n'atteignent jamais les services. Sa meta a donc une autre forme,
`acces_projection` : Keycloak projette au lieu de consommer (D-65).

Defaut corrige : `serveur_icingaweb2_admins` valait "testmail", un compte de
test code en dur dans le moteur qu'aucune instance ne surchargeait — le seul
administrateur declare de la supervision etait un utilisateur inexistant. Il
suit desormais l'uid d'amorcage. Verifie sur mon-01 : users = "sysadmin".

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-07 13:59:33 -04:00
..
defaults acces : les cinq meta/acces.yml, et le mecanisme qui manque a chacun 2026-08-07 13:59:33 -04:00
handlers serveur_oauth2_proxy : passerelle SSO OIDC générique + Icinga Web 2 au SSO 2026-07-03 19:05:04 -04:00
meta acces : les cinq meta/acces.yml, et le mecanisme qui manque a chacun 2026-08-07 13:59:33 -04:00
tasks Binding annuaire complété : icingaweb2 + client_ldap → resoudre_annuaire 2026-07-03 23:24:38 -04:00
templates serveur_oauth2_proxy : passerelle SSO OIDC générique + Icinga Web 2 au SSO 2026-07-03 19:05:04 -04:00
README.md docs : un README par rôle (12 manquants) + carte remise à l'état du code 2026-07-29 11:32:06 -04:00

README.md

serveur_icingaweb2

Frontal de supervision : Icinga Web 2 + module IcingaDB + module Business Process, co-localisé avec le moteur serveur_icinga. Application PHP servie par un nginx local et php-fpm ; l'edge nginx proxifie par nom.

Rôle

  • Résout sa base IcingaDB via resoudre_base (même consommateur que le moteur) et l'annuaire via resoudre_annuaire — aucun câblage en dur.
  • Installe icingadb-web (qui tire icingaweb2), le module BPM, PHP 8.4 (fpm, pgsql, ldap, intl, gd, curl, xml, mbstring) et nginx.
  • Déploie la configuration .ini (ressources, authentification, rôles, IcingaDB, Redis), active les modules, déploie le vhost nginx local et retire le site par défaut.
  • Processus métier (BPM) : peut en semer en IaC (serveur_icingaweb2_bpm_processes), tout en laissant le répertoire éditable depuis l'UI.

Deux modes d'authentification

serveur_icingaweb2_auth Fonctionnement
ldap (défaut) Connexion directe à OpenLDAP (LDAPS) — Icinga Web 2 n'a pas d'OIDC natif
external L'utilisateur est fourni par une passerelle SSO devant (serveur_oauth2_proxy → Keycloak) ; nginx pose REMOTE_USER

En mode external, restreindre l'écoute de nginx à la boucle locale (serveur_icingaweb2_nginx_bind: "127.0.0.1:") — sinon l'application reste joignable en contournant la passerelle.

Variables principales

Variable Défaut Rôle
serveur_icingaweb2_hostname icinga.{{ domaine_interne }} Nom servi
serveur_icingaweb2_http_port 8080 nginx local (l'edge proxifie ici)
serveur_icingaweb2_auth ldap Backend d'authentification
serveur_icingaweb2_remote_user $remote_user Variable nginx source de REMOTE_USER
serveur_icingaweb2_nginx_bind "" "127.0.0.1:" derrière une passerelle
serveur_icingaweb2_admins testmail uid recevant le rôle Administrateur (liste séparée par virgules)
serveur_icingaweb2_redis_port 6380 Redis IcingaDB local
serveur_icingaweb2_modules [icingadb, businessprocess] Modules activés
serveur_icingaweb2_bpm_processes {} Processus métier semés en IaC

Flux (meta/flux.yml)

8080/tcp entrant depuis l'edge · 5432/tcp → PostgreSQL (IcingaDB, verify-full) · 636/tcp → OpenLDAP. Icinga 2 (API 5665) et le Redis IcingaDB (6380) sont co-localisés : consommés en localhost, donc absents du registre des flux.

Notes / limites

  • serveur_icingaweb2_admins doit désigner de vrais uid de l'annuaire — sinon plus personne n'est administrateur de l'interface.
  • Les versions PHP sont épinglées à 8.4 (Debian 13) dans les noms de paquets, de service et de socket : une montée de Debian demandera de les changer ensemble.
  • Le Redis IcingaDB (6380) est distinct du groupe serveur_redis (cache applicatif) et du Redis de serveur_rspamd.
  • Semer un processus BPM ici le met sous gestion Ansible : il sera réécrit à chaque passage, même modifié dans l'UI. Par défaut, le rôle n'en sème aucun.

Prérequis

  • serveur_icingaweb2 requiert serveur_icinga, serveur_postgresql, serveur_openldap actifs (docs/dependances-groupes.yml).
  • client_pki (LDAPS + PostgreSQL verify-full). Couche apps.