--- # Icinga Web 2 (UI native Icinga) + module IcingaDB, sur le nœud de supervision. # App PHP servie par nginx local + php-fpm ; l'edge nginx proxifie par nom. # Auth LDAP direct (OpenLDAP) — icingaweb2 n'a pas d'OIDC natif ; SSO via proxy = raffinement. serveur_icingaweb2_paquets: - icingadb-web # module IcingaDB (tire icingaweb2 en dépendance) - icingaweb2-module-businessprocess # module BPM (vues d'impact métier) - php8.4-fpm - php8.4-cli - php8.4-pgsql - php8.4-ldap - php8.4-intl - php8.4-gd - php8.4-curl - php8.4-xml - php8.4-mbstring - nginx # INSTALLES AVANT LES PAQUETS TIERS, pour qu'apt ne choisisse pas apache2 (voir tasks). serveur_icingaweb2_web_prealables: - php8.4-fpm - nginx # Ce qu'un ordre d'installation fautif a laisse, et que le role retire s'il part seul. serveur_icingaweb2_apache_restes: - apache2 - apache2-bin - apache2-data - apache2-utils - libapache2-mod-php8.4 serveur_icingaweb2_php_fpm_service: "php8.4-fpm" serveur_icingaweb2_php_fpm_socket: "/run/php/php8.4-fpm.sock" serveur_icingaweb2_nginx_service: "nginx" # Publication : nginx LOCAL sur ce port ; l'edge proxifie icinga. ici. serveur_icingaweb2_hostname: "icinga.{{ domaine_interne }}" serveur_icingaweb2_http_port: 8080 serveur_icingaweb2_docroot: "/usr/share/icingaweb2/public" serveur_icingaweb2_config_dir: "/etc/icingaweb2" # Base IcingaDB (via le registre — même consommateur que le moteur). serveur_icingaweb2_icinga_groupe: "serveur_icinga" # Redis IcingaDB (local au nœud de supervision). serveur_icingaweb2_redis_host: "127.0.0.1" serveur_icingaweb2_redis_port: 6380 # Authentification LDAP (OpenLDAP, LDAPS). La connexion (url, base, users_dn, bind_dn, # bind_password) est fournie par le rôle partagé resoudre_annuaire (voir tasks « Adopter la # connexion annuaire »). Utilisée seulement en mode auth "ldap" ; en SSO, résolue mais inutilisée. serveur_icingaweb2_ldap_port: 636 serveur_icingaweb2_ldap_user_class: "inetOrgPerson" serveur_icingaweb2_ldap_user_attr: "uid" # Qui reçoit le rôle Administrateur (liste d'uid séparés par des virgules). # # /!\ NOMMER DES PERSONNES contredit D-66 : révoquer quelqu'un demande alors un # déploiement, et la liste vieillit sans que rien ne le signale. Icinga Web 2 sait # lire un groupe d'annuaire (backend LDAP de type `group`) — c'est là qu'il faut # aller. Voir roles/serveur_icingaweb2/meta/acces.yml. # # En attendant, le défaut suit l'`uid` d'amorçage plutôt qu'un compte de test : # `testmail` était codé en dur et n'existe dans aucune instance — le seul # administrateur déclaré était donc un utilisateur inexistant (2026-08-07). # Repli seulement, et VIDE par defaut : l'habilitation passe par le GROUPE # (`serveur_icingaweb2_groupe_admin`). Le renseigner nomme des personnes, ce que # D-66 interdit — a n'utiliser que pour un depannage. serveur_icingaweb2_admins: "" # Habilitation par groupe d'annuaire. Le schema est celui que `amorcage_acces` pose : # des `groupOfNames` dont les membres sont des DN. serveur_icingaweb2_groupe_admin: "{{ amorcage_acces_groupe | default('sysadmin') }}" serveur_icingaweb2_groupe_class: "groupOfNames" serveur_icingaweb2_groupe_membre_attr: "member" serveur_icingaweb2_groupes_dn: "ou=groups,{{ resoudre_annuaire_base_dn | default('') }}" # Backend d'authentification : "ldap" (direct) ou "external" (utilisateur fourni par une # passerelle SSO devant, ex. oauth2-proxy → Keycloak). En "external", nginx doit poser REMOTE_USER. # TROIS MODES D'AUTHENTIFICATION, ET LE TROISIEME EST NE POUR LE SITE (2026-09-14). # # `ldap` — connexion directe a l'annuaire. Icinga Web 2 n'a pas d'OIDC natif. # `external` — une passerelle SSO devant (oauth2-proxy -> Keycloak) pose `REMOTE_USER`, # et un backend LDAP sert a resoudre les GROUPES. # `db` — ni annuaire ni passerelle : Icinga Web 2 gere ses comptes LUI-MEME, # dans sa propre base, avec sa propre page de connexion. # # POURQUOI `db` EXISTE. Un SITE n'a ni LDAP ni Keycloak — ce sont des services # d'ecosysteme, et l'hebergeur n'en est pas un. Sans ce mode, la console de supervision # du site etait impossible : le plan declarait `serveur_icinga` sans `serveur_icingaweb2`, # et 88 verdicts se calculaient sans que personne puisse les LIRE. # # PREMIERE ECRITURE, ET ELLE ETAIT DE TROP (corrigee le 2026-09-15). Ce mode s'appelait # `locale` et posait un `auth_basic` nginx devant le backend `external` : nginx demandait # le mot de passe et l'application croyait le nom qu'il lui passait. Ca marchait, et ca # reinventait une page de connexion devant une application qui en a une. # # L'exploitant l'a dit en une phrase : *« Icinga Web 2 permet nativement de gerer des # comptes ; ce genre d'intervention n'est pertinente que pour integrer Icinga a Keycloak # chez les tenants. »* Un vestibule n'a de sens que devant une application qui ne sait # pas s'authentifier — et celle-ci sait. # # CE QUE LE MODE NATIF DONNE EN PLUS : la gestion des comptes DANS l'interface. Creer, # desactiver, changer un mot de passe ne demande plus un deploiement ni un passage par la # voute. Et l'habilitation cesse de nommer une personne en dur dans `roles.ini` : les # GROUPES d'Icinga Web 2 existent aussi en base. serveur_icingaweb2_auth: "ldap" # Variable nginx d'où vient REMOTE_USER. En SSO : l'en-tête d'oauth2-proxy. serveur_icingaweb2_remote_user: "$remote_user" # Préfixe d'écoute nginx local ("" = toutes interfaces ; "127.0.0.1:" = local, derrière la passerelle). serveur_icingaweb2_nginx_bind: "" # Modules icingaweb2 à activer. serveur_icingaweb2_modules: - icingadb - businessprocess # Processus métier (BPM) à semer, en IaC (nom -> contenu du .conf). Vide par défaut : # les processus sont normalement édités via l'UI. Un contenu ici est géré par Ansible. serveur_icingaweb2_bpm_processes: {} # --- LES VUES METIER, DERIVEES (2026-10-04) -------------------------------------------- # # Une vue d'ensemble par CLIENTELE INTERNE, construite seule : chaque sonde declare dans le # `meta/supervision.yml` de son role le service metier auquel elle contribue (`metier:`) ; # ce catalogue dit comment chaque service s'appelle et QUI le voit. Les vues ne retiennent # que les services presents dans l'ecosysteme : un site sans courriel n'a pas de case # « courriel », un locataire sans forge pas de case « forge ». # # Fichiers poses : `setops-.conf` dans le repertoire des processus. Le prefixe les # distingue des processus ecrits a la main ou dans l'interface, que le role ne touche pas. serveur_icingaweb2_bpm_vues: personnel: titre: "Mes outils" # PAS DE PERSONNEL SANS COMPTES : la vue n'existe que la ou l'on se connecte. Au site, # le seul « outil » trouve etait son relais de courriel — celui des alertes. requiert: connexion description: >- Les outils du quotidien fonctionnent-ils ? Vert : tout marche. Rouge : un outil est en panne, et la supervision le voit aussi. direction: titre: "Services rendus" description: >- Les services que l'organisation rend sont-ils rendus, et ses données sont-elles en sûreté ? Un voyant par service, et un pour les fondations techniques. exploitation: titre: "Exploitation" description: >- Qu'est-ce qui casse, et où ? Chaque service se déplie jusqu'au contrôle Icinga et à la machine en cause ; le socle se lit machine par machine. # L'ORDRE EST CELUI DE L'AFFICHAGE. `fondation: true` : regroupe sous « Fondations # techniques » dans la vue de la direction. `par_machine: true` : un sous-noeud par machine. serveur_icingaweb2_bpm_services: - {cle: connexion, titre: "Se connecter (compte unique)", vues: [personnel, direction, exploitation]} - {cle: courriel, titre: "Courriel", vues: [personnel, direction, exploitation]} - {cle: fichiers, titre: "Fichiers partagés", vues: [personnel, direction, exploitation]} - {cle: edition, titre: "Édition en ligne", vues: [personnel, direction, exploitation]} - {cle: web, titre: "Sites web publics", vues: [personnel, direction, exploitation]} - {cle: noms_publics, titre: "Noms publics des locataires", vues: [direction, exploitation]} - {cle: sauvegardes_locataires, titre: "Sauvegardes des locataires", vues: [direction, exploitation]} - {cle: forge, titre: "Forge et génome", vues: [direction, exploitation]} - {cle: paquets, titre: "Dépôt de paquets", vues: [direction, exploitation]} - {cle: machines, titre: "Création des machines", vues: [direction, exploitation]} - {cle: donnees, titre: "Sûreté des données", vues: [direction, exploitation]} # L'EDGE N'EST PAS LE WEB PUBLIC : c'est la passerelle par laquelle on joint les services # internes. Classe « sites web publics », il faisait apparaitre une vue « Mes outils » au # site, qui n'a pas d'utilisateurs. - {cle: acces, titre: "Passerelle d'accès (edge)", vues: [direction, exploitation], fondation: true} - {cle: frontiere, titre: "Frontière (une patte par zone)", vues: [direction, exploitation], fondation: true} - {cle: noms, titre: "Résolution des noms", vues: [direction, exploitation], fondation: true} - {cle: confiance, titre: "Autorité de certification", vues: [direction, exploitation], fondation: true} - {cle: base, titre: "Bases de données", vues: [direction, exploitation], fondation: true} - {cle: supervision, titre: "Supervision", vues: [direction, exploitation], fondation: true} - {cle: pilotage, titre: "Pilotage (console et runner)", vues: [direction, exploitation], fondation: true} - {cle: socle, titre: "Socle des machines", vues: [direction, exploitation], fondation: true, par_machine: true} # Les processus que le role a poses autrefois et qu'il retire (sans extension). # `supervision` : l'exemple ecrit a la main dans les group_vars des locataires — il visait # un hote `icinga` et des controles (`load`, `procs`, `swap`, `ssh`) qui n'existent plus. serveur_icingaweb2_bpm_retires: [supervision] # Le nom de l'ecosysteme en tete de chaque vue. serveur_icingaweb2_bpm_nom: "{{ organisation | default(domaine_interne) }}" # LES CODES QU'UNE CONSOLE SAINE PEUT RENDRE A UNE REQUETE NON AUTHENTIFIEE. # # 200 quand la racine se sert, 302 quand elle renvoie vers le formulaire de connexion, # 401/403 quand une passerelle SSO se tient devant. Les quatre disent la meme chose : la # pile PHP est vivante. Ce qu'ils excluent, c'est le 502 et le 504 — php-fpm mort ou # bloque — et l'absence de reponse, qui est le nginx local tombe. serveur_icingaweb2_sonde_codes: "HTTP/1.1 200,HTTP/1.1 302,HTTP/1.1 401,HTTP/1.1 403" # CE QUE LA VIGIE LIT, EPROUVE AVEC SES PROPRES IDENTIFIANTS (2026-09-28). La table que la # sonde interroge dans la base du moteur, au travers de la ressource que la vigie utilise. # Mise en defaut PAR PARAMETRE : une table qui n'existe pas. serveur_icingaweb2_sonde_table: "host" # --- MODE `db` : le compte d'amorcage de la console ------------------------------------ # # UN SEUL COMPTE EST POSE PAR LE MOTEUR, et c'est voulu : celui qui permet d'entrer la # premiere fois. Les suivants se creent DANS l'interface, par quelqu'un qui a une tete et # un contexte — pas par un deploiement. # # LE MOT DE PASSE VIENT DE LA VOUTE. Vide, le role REFUSE de deployer en mode `db` : # degrader, jamais deviner, et surtout jamais un mot de passe par defaut sur une console # qui montre l'etat de toute une fabric. serveur_icingaweb2_admin_utilisateur: "icinga-admin" serveur_icingaweb2_admin_motdepasse: "{{ vault_icingaweb2_admin | default('') }}" # LE SCHEMA DES TABLES DE COMPTES, livre par le paquet. On le charge UNE FOIS — la # presence de `icingaweb_user` sert de temoin, parce que rejouer ce fichier sur une base # deja peuplee echouerait sur les objets existants. serveur_icingaweb2_schema: "/usr/share/icingaweb2/schema/pgsql.schema.sql" # TLS VERS POSTGRESQL, DERIVE DE CE QUE SERT LE SERVEUR. Voir `resoudre_base` et P78. # # P78 nommait ce role comme « sans reglage TLS » — c'etait vrai et sans consequence tant # qu'il ne tournait nulle part face a un `hostssl`. Au site, il en trouve un. serveur_icingaweb2_db_sslmode: >- {{ 'verify-full' if (resoudre_base_db_tls_force | default(false)) else '' }} serveur_icingaweb2_db_sslrootcert: "/etc/step/certs/root_ca.crt"