Daniel Allaire e006dee693 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

2.6 KiB

Raw Permalink Blame History

DNS interne

Le service DNS interne est la premiere capacite de plateforme.

Plancher de resolution independant du DNS. Le socle (hosts_statiques, dans serveur_debian) genere /etc/hosts sur chaque VM depuis l'inventaire : tout l'ecosysteme se resout par nom meme serveur DNS eteint (et au bootstrap, avant que PowerDNS ne soit la). PowerDNS devient une commodite (zone, externe, dynamique), plus un point de defaillance. Le resolveur local client_unbound est optionnel (opt-in, avec bascule validee) : sans lui, le plancher /etc/hosts suffit.

Groupes

serveur_powerdns -> service DNS central PowerDNS Authoritative
client_unbound   -> resolveur local optionnel (opt-in, bascule validee)

client_unbound (résolveur local optionnel) peut viser PowerDNS en stub-zone + récursion.

Zone initiale

La zone initiale est :

exemple.internal

Elle est definie dans :

instance/inventories/production/group_vars/serveur_powerdns.yml

Enregistrement automatique

Le role serveur_powerdns genere la zone a partir de l'inventaire.

Les hotes qui remplissent ces conditions sont ajoutes automatiquement :

hote dans hotes_actifs
ansible_host defini

Exemple :

web-frontal-01 ansible_host=10.0.2.31
-> web-frontal-01.exemple.internal A 10.0.2.31

Les enregistrements additionnels explicites sont dans serveur_powerdns_records.

Backend PowerDNS

Le premier jalon utilise le backend BIND de PowerDNS.

Raison :

pas de dependance prematuree a PostgreSQL ;
zone lisible et generee par Ansible ;
idempotence simple ;
bon point de depart pour la supervision.

Quand serveur_postgresql sera stable, il sera possible de migrer vers un backend SQL si le besoin operationnel le justifie.

Résolveur local (optionnel)

Le role client_unbound (opt-in) installe un résolveur récursif local qui, en stub-zone, délègue les noms internes à PowerDNS et récurse le reste.

La bascule du resolver local est protegee (le role valide qu'Unbound répond AVANT de basculer /etc/resolv.conf) :

client_unbound_apply: true
client_unbound_confirm: true

Sans ces deux variables, le role prépare Unbound mais ne modifie pas /etc/resolv.conf.

Cette protection est volontaire : une mauvaise configuration DNS peut couper la resolution de noms.

Surveillance a prevoir

Les premiers checks utiles :

service pdns actif ;
port UDP/TCP 53 disponible ;
SOA de exemple.internal resoluble ;
enregistrement ns1.exemple.internal resoluble ;
enregistrements des hotes actifs presents ;
serial de zone attendu ;
latence de resolution.

2.6 KiB Raw Permalink Blame History