2026-06-24 20:17:46 -04:00
|
|
|
---
|
|
|
|
|
groupes:
|
|
|
|
|
client_pki:
|
|
|
|
|
requiert_groupes_actifs:
|
|
|
|
|
- serveur_step_ca
|
|
|
|
|
raison: "La confiance CA et ACME client dependent de l'autorite interne."
|
|
|
|
|
surveillance: "Verifier validite CA, emission ACME et expiration des certificats."
|
|
|
|
|
|
|
|
|
|
client_metrique:
|
|
|
|
|
requiert_groupes_actifs:
|
|
|
|
|
- serveur_prometheus
|
|
|
|
|
raison: "Les exporters clients doivent etre collectes par Prometheus."
|
|
|
|
|
surveillance: "Verifier targets Prometheus, scrape duration et erreurs de collecte."
|
|
|
|
|
|
|
|
|
|
client_journal:
|
|
|
|
|
requiert_groupes_actifs:
|
|
|
|
|
- serveur_loki
|
|
|
|
|
raison: "L'expedition des journaux depend du collecteur central Loki."
|
|
|
|
|
surveillance: "Verifier ingestion Loki, retard et volume de journaux."
|
|
|
|
|
|
|
|
|
|
client_smtp:
|
|
|
|
|
requiert_groupes_actifs:
|
Retirer 3 rôles legacy (serveur_sendmail, client_dns, client_ldap) + nettoyage
Supprimés (supersédés / hors-conception) : serveur_sendmail (→ Postfix),
client_dns (→ plancher + client_unbound), client_ldap (login LDAP OS, hors
design). Rôles + playbooks de groupe retirés.
Nettoyage des références :
- dependances-groupes.yml : entrées client_dns/client_ldap retirées + entrées
mortes des scaffoldings (nextcloud/collabora/client_supervision) ; deps
périmées corrigées (client_smtp → serveur_postfix ; serveur_keycloak →
serveur_postgresql, la raison parlait à tort de Nextcloud).
- 6 modèles d'exemple : app mail serveur_sendmail → serveur_postfix.
- README, AGENTS : listes/glossaire nettoyés.
- catalogue-services : listes, tables, roadmap ; note « rôles retirés ».
- nomenclature-vm : infra-mail-01 → serveur_dovecot (était faux).
- courriel-conception, dns-interne (re-ciblé client_unbound), pouvoirs,
intrants, READMEs (client_smtp/forgejo/openldap/unbound).
ansible-lint : 0 échec (366 fichiers). instancier OK.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-04 12:14:04 -04:00
|
|
|
- serveur_postfix
|
|
|
|
|
raison: "Les notifications locales doivent relayer vers un MTA actif (Postfix)."
|
2026-06-24 20:17:46 -04:00
|
|
|
surveillance: "Verifier file d'attente, relais SMTP et echecs de livraison."
|
|
|
|
|
|
2026-07-07 03:08:09 -04:00
|
|
|
serveur_postfix:
|
|
|
|
|
requiert_groupes_actifs:
|
|
|
|
|
- serveur_dovecot
|
|
|
|
|
raison: "Postfix remet le courrier local via LMTP a Dovecot (mailstore) ; la remise exige Dovecot actif."
|
|
|
|
|
surveillance: "Verifier file d'attente, remise LMTP (status=sent) et rejets."
|
|
|
|
|
|
2026-06-24 20:17:46 -04:00
|
|
|
serveur_keycloak:
|
|
|
|
|
requiert_groupes_actifs:
|
|
|
|
|
- serveur_postgresql
|
2026-07-07 03:08:09 -04:00
|
|
|
- serveur_openldap
|
|
|
|
|
raison: "Keycloak persiste dans PostgreSQL et federe l'annuaire OpenLDAP (resoudre_annuaire_uri)."
|
|
|
|
|
surveillance: "Verifier connexion base, federation LDAP, etat realm et disponibilite OIDC."
|
|
|
|
|
|
|
|
|
|
serveur_dovecot:
|
|
|
|
|
requiert_groupes_actifs:
|
|
|
|
|
- serveur_openldap
|
|
|
|
|
raison: "Dovecot resout ses utilisateurs (userdb/passdb) sur l'annuaire OpenLDAP (resoudre_annuaire_*)."
|
|
|
|
|
surveillance: "Verifier bind LDAP, authentification IMAP et remise LMTP."
|
2026-06-24 20:17:46 -04:00
|
|
|
|
|
|
|
|
serveur_grafana:
|
|
|
|
|
requiert_groupes_actifs:
|
|
|
|
|
- serveur_prometheus
|
|
|
|
|
- serveur_loki
|
|
|
|
|
raison: "Grafana est utile comme interface aux metriques et journaux centraux."
|
|
|
|
|
surveillance: "Verifier datasources Prometheus/Loki et authentification."
|
|
|
|
|
|
|
|
|
|
serveur_icinga:
|
|
|
|
|
requiert_groupes_actifs:
|
|
|
|
|
- serveur_postgresql
|
|
|
|
|
raison: "La plateforme Icinga Web/BPM depend d'une base relationnelle."
|
|
|
|
|
surveillance: "Verifier moteur Icinga, base, interface web et notifications."
|
|
|
|
|
|
2026-07-07 03:08:09 -04:00
|
|
|
serveur_icingaweb2:
|
|
|
|
|
requiert_groupes_actifs:
|
|
|
|
|
- serveur_icinga
|
|
|
|
|
- serveur_postgresql
|
|
|
|
|
- serveur_openldap
|
|
|
|
|
raison: "Frontal web d'Icinga : lit IcingaDB (base), affiche le moteur Icinga et authentifie sur l'annuaire OpenLDAP (resoudre_annuaire)."
|
|
|
|
|
surveillance: "Verifier acces IcingaDB, connexion Icinga et authentification LDAP."
|
|
|
|
|
|
2026-06-24 20:17:46 -04:00
|
|
|
serveur_forgejo:
|
|
|
|
|
requiert_groupes_actifs:
|
|
|
|
|
- serveur_postgresql
|
|
|
|
|
- serveur_nginx
|
dependances : un ecosysteme minimal n'est pas un ecosysteme incomplet
Le controle de dependances a REFUSE le deploiement de patient 0 : client_journal requiert
serveur_loki, client_metrique requiert serveur_prometheus, serveur_forgejo requiert
serveur_postgresql et serveur_postfix. Quatre refus, une seule racine — le moteur suppose
que tout ecosysteme porte tous les services. Apres les intrants (P32) et les bases (P35),
troisieme manifestation en cinq jours. Et le mur que rencontrerait toute offre plus petite
que l'ecosysteme de reference.
UNE INTEGRATION UNIVERSELLE A BESOIN D'UN INTERLOCUTEUR. « Tout hote est mesure » est vrai
dans un ecosysteme qui porte un Prometheus ; ailleurs, la meme phrase pose sur chaque
machine un client qui n'a personne a qui parler. La regle est desormais DERIVEE : le
service central d'une integration est celui que le registre des dependances lui donne
deja. Rien de neuf a tenir a jour, donc rien de neuf a oublier.
Chezlepro -> diff VIDE (tous ses services existent, rien ne change)
patient 0 -> client_backup, client_pki, client_unbound
UNE EXIGENCE N'EST PAS TOUJOURS ABSOLUE. Deux notions manquaient au registre :
`sauf_si` l'exigence tombe sous condition (Forgejo + SQLite)
`utilise_si_present` un agrement, jamais bloquant (Forgejo notifie SI un MTA existe)
Les confondre obligeait une forge a deployer une pile courriel entiere pour exister.
ET LA LECON D'HIER A SERVI : trois lecteurs avaient besoin le meme jour de lire une
variable d'instance (P35, les clauses sauf_si, le generateur). Trois copies auraient
recommence ce qu'on venait de refermer. Il y en a UNE, dans inventory_rules.
make verifier 41/41 ; make ci 41/41 ; inventaire de Chezlepro identique.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-22 14:54:00 -04:00
|
|
|
# UNE EXIGENCE PEUT ETRE CONDITIONNELLE (2026-08-22). Depuis que le role sait tenir sa
|
|
|
|
|
# base dans un fichier, exiger un serveur PostgreSQL est faux pour qui a choisi SQLite
|
|
|
|
|
# — et bloquait le deploiement d'un ecosysteme parfaitement coherent.
|
|
|
|
|
sauf_si:
|
|
|
|
|
serveur_postgresql: { variable: serveur_forgejo_bd, vaut: sqlite }
|
|
|
|
|
# UTILISE SI PRESENT : Forgejo envoie des notifications quand un MTA existe, et s'en
|
|
|
|
|
# passe sinon. Ce n'etait pas une EXIGENCE — le confondre avec une exigence obligeait
|
|
|
|
|
# une forge a deployer une pile courriel pour exister.
|
|
|
|
|
utilise_si_present:
|
2026-07-03 15:52:38 -04:00
|
|
|
- serveur_postfix
|
dependances : un ecosysteme minimal n'est pas un ecosysteme incomplet
Le controle de dependances a REFUSE le deploiement de patient 0 : client_journal requiert
serveur_loki, client_metrique requiert serveur_prometheus, serveur_forgejo requiert
serveur_postgresql et serveur_postfix. Quatre refus, une seule racine — le moteur suppose
que tout ecosysteme porte tous les services. Apres les intrants (P32) et les bases (P35),
troisieme manifestation en cinq jours. Et le mur que rencontrerait toute offre plus petite
que l'ecosysteme de reference.
UNE INTEGRATION UNIVERSELLE A BESOIN D'UN INTERLOCUTEUR. « Tout hote est mesure » est vrai
dans un ecosysteme qui porte un Prometheus ; ailleurs, la meme phrase pose sur chaque
machine un client qui n'a personne a qui parler. La regle est desormais DERIVEE : le
service central d'une integration est celui que le registre des dependances lui donne
deja. Rien de neuf a tenir a jour, donc rien de neuf a oublier.
Chezlepro -> diff VIDE (tous ses services existent, rien ne change)
patient 0 -> client_backup, client_pki, client_unbound
UNE EXIGENCE N'EST PAS TOUJOURS ABSOLUE. Deux notions manquaient au registre :
`sauf_si` l'exigence tombe sous condition (Forgejo + SQLite)
`utilise_si_present` un agrement, jamais bloquant (Forgejo notifie SI un MTA existe)
Les confondre obligeait une forge a deployer une pile courriel entiere pour exister.
ET LA LECON D'HIER A SERVI : trois lecteurs avaient besoin le meme jour de lire une
variable d'instance (P35, les clauses sauf_si, le generateur). Trois copies auraient
recommence ce qu'on venait de refermer. Il y en a UNE, dans inventory_rules.
make verifier 41/41 ; make ci 41/41 ; inventaire de Chezlepro identique.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-22 14:54:00 -04:00
|
|
|
raison: "Forgejo depend d'une base (serveur ou fichier) et d'une publication HTTP(S) ; le courriel est un agrement."
|
2026-06-24 20:17:46 -04:00
|
|
|
surveillance: "Verifier HTTP(S), base, files Git et envoi courriel."
|
|
|
|
|
|
2026-07-07 03:08:09 -04:00
|
|
|
serveur_nextcloud:
|
|
|
|
|
requiert_groupes_actifs:
|
|
|
|
|
- serveur_postgresql
|
|
|
|
|
- serveur_keycloak
|
|
|
|
|
- serveur_collabora
|
|
|
|
|
raison: "Nextcloud persiste dans PostgreSQL (verify-full), federe l'identite par OIDC (Keycloak) et valide WOPI contre Collabora (edition en ligne)."
|
|
|
|
|
surveillance: "Verifier base, decouverte OIDC, autodetection WOPI et acces web."
|
|
|
|
|
|