Daniel Allaire
4a1d0836d0
Solde la dette documentaire repérée à l'audit du 2026-07-03. Tous les rôles ont désormais un README, au format maison (intention → rôle → variables → notes/limites → prérequis). Ils documentent ce qui ne se lit PAS dans les tâches : - serveur_debian : rôle-catégorie sans tâches — il ne porte que le flux SSH du plan de gestion, sans quoi les nftables générés couperaient l'accès Ansible à toute la flotte ; le vrai travail est dans le playbook de groupe. - hosts_statiques : le plancher /etc/hosts comme CONDITION de l'ordre de reconstruction (résolution par nom avant que PowerDNS existe) ; fichier entièrement géré, alias d'exposition best-effort. - resoudre_base / resoudre_annuaire : entrées, sorties (facts), et pourquoi le FQDN plutôt que le nom court (fédération + nom canonique pour verify-full). - serveur_dovecot : les 3 réglages Dovecot 2.4 qui conditionnent la remise (static_allow_all_users, mail_inbox_path vide, mail_path par utilisateur) et le local-part seul comme chemin commun LMTP/IMAP ; limite mono-domaine. - serveur_postfix : liens mailstore/milter, recopie de /etc/hosts dans le chroot. - serveur_rspamd : clé DKIM idempotente ; le domaine signé doit être PUBLIC en prod, sinon la signature ne vaut rien pour les MX distants. - client_backup / serveur_backup : jobs déclaratifs, chiffrement côté client, deux pièges (jobs vides = silencieux ; dépôt neuf vide après un from-zero) ; hors-nœud n'est pas hors-site. - serveur_oauth2_proxy : le patron réutilisable Keycloak-devant-n'importe-quoi, et pourquoi allow_unverified_email est nécessaire avec un annuaire LDAP. - serveur_icingaweb2 : modes ldap vs external, écoute à restreindre en SSO. - client_unbound : le garde-fou de bascule (apply ET confirm, validation réelle avant de toucher /etc/resolv.conf). docs/carte-set-ops.md ne décrivait plus l'état du code : - expose EST consommé au déploiement (annoncé comme « Phase 3 à venir ») : expositions_des_applications + expositions.conf.j2, alias /etc/hosts, SANs d'edge dérivés par instancier.py ; - 3 mécanismes transverses ajoutés (résolution d'annuaire, plancher de résolution, resoudre_base nommé dans les bindings app→base) ; - 5 entrées d'index ajoutées : réseau/pare-feu, ordre de déploiement, preuve/recette, exploitation courante, wiki — pans du corpus non indexés ; - ce qui reste ouvert est marqué : meta/liens.yml sur le seul serveur_postfix, requiert non consommé au déploiement (l'ordre vient des couches + du graphe). make verifier vert : ansible-lint 514 fichiers, tests, syntax-check, 23 preuves CONFORME / 0 échec / 0 sauté. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| defaults | ||
| handlers | ||
| meta | ||
| tasks | ||
| templates | ||
| 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 viaresoudre_annuaire— aucun câblage en dur. - Installe
icingadb-web(qui tireicingaweb2), 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_adminsdoit 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 groupeserveur_redis(cache applicatif) et du Redis deserveur_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 + PostgreSQLverify-full). Couche apps.