History

Daniel Allaire a74e35bf21 Some checks are pending verifier / verifier (push) Waiting to run Details site : le plancher survit au redemarrage, et la zone dit les vraies adresses Le decoupage du site en quatre zones a deplace cinq machines. Ni le plancher /etc/hosts ni la zone DNS n'avaient suivi. Quatre defauts, tous dans le moteur. LE PLANCHER ETAIT EFFACE A CHAQUE DEMARRAGE — ET LE PREMIER CORRECTIF N'EN ETAIT PAS UN. `hosts_statiques` posait `99-setops-hosts.cfg` avec `manage_etc_hosts: false`, pendant que `cloud_init` posait `99_setops.cfg` avec `true`. Dans `cloud.cfg.d` l'ordre est LEXICAL et le dernier gagne : `-` vaut 0x2D, `_` vaut 0x5F. On a donc retire la cle de `cloud_init` — le role qui POSSEDE le fichier decide — puis renomme notre fragment `zz-` pour passer apres le `99_chezlepro.cfg` du gabarit dore. Et ca ne suffisait toujours pas. Redemarrage d'epreuve : plancher encore efface. La cause reelle est ailleurs — Proxmox inscrit `manage_etc_hosts: true` dans la USER-DATA de son lecteur cloud-init, et la user-data prime sur `cloud.cfg.d` tout entier. Aucun fragment ne pouvait gagner ; renommer pour parler en dernier ne servait a rien, le dernier mot n'appartenant pas a ce repertoire. Ce que cloud-init regenere, il le regenere depuis `hosts.debian.tmpl` — le gabarit le documente lui-meme. `hosts_statiques` le pose desormais avec le MEME contenu que /etc/hosts, et une garde compare les deux a chaque passage. Redemarrage d'epreuve : les neuf entrees sont la. La garde precedente affirmait « conforme » en mesurant l'ordre lexical — vrai, et sans rapport avec ce qui se passait. Une garde qui mesure la mauvaise chose est pire qu'aucune. LA ZONE DNS NE PUBLIAIT PAS LES NOMS DE SERVICE. `forge.genese.internal` et `pki.genese.internal` — des noms que les certificats portent et que les clients appellent — n'avaient aucun enregistrement. Seul le plancher savait les resoudre. Trois causes empilees : - le plan du site coupait `serveur_powerdns_publier_expositions`, au motif que « le site n'a pas d'edge » : ca confondait PUBLIC et EXPOSE ; - `expositions_des_applications` rendait `domaine: None` faute de `domaines.yml`, et le modele de zone ecarte les expositions dont le domaine n'est pas la zone. Repli ajoute, symetrique de celui deja ecrit pour `edge` : sans domaine public declare, le domaine est celui que porte le FQDN ; - `serveur_powerdns` exigeait les deux registres et echouait si `domaines.yml` manquait — le meme tout-ou-rien que `hosts_statiques` a corrige le meme jour. Puis `named-checkzone` a refuse la zone : `dns.genese.internal` heritait d'un CNAME par defaut du role ET d'un A par exposition. La garde a bien joue son role — elle a arrete une zone cassee avant qu'elle soit servie. Le plan l'emporte desormais sur le defaut du role. Un service ne doit pas dependre d'un plancher pour etre joignable : le plancher est un filet, pas le sol. VERIFICATION. Les huit noms — cinq machines, trois services — resolvent vers les bonnes adresses depuis les cinq hotes, par le plancher ET par le DNS, et le plancher survit au redemarrage. P46 refuse desormais deux choses : plus d'un role ecrivant `manage_etc_hosts`, et l'absence du gabarit maitre. Controle negatif verifie. RESTE NOMME, PAS CORRIGE : la zone INVERSE. `serveur_powerdns_zone_inverse` derive d'un supernet /16 — la forme d'un tenant. Un site declare plusieurs /24 et n'a pas de supernet unique : aucune zone inverse n'est generee. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>		2026-08-25 20:31:01 -04:00
..
defaults	plancher : nommer ce qui est hors de l'ecosysteme	2026-08-23 10:09:08 -04:00
tasks	site : le plancher survit au redemarrage, et la zone dit les vraies adresses	2026-08-25 20:31:01 -04:00
templates	site : le plancher survit au redemarrage, et la zone dit les vraies adresses	2026-08-25 20:31:01 -04:00
README.md	resolveur : un par tenant, et non plus un par machine	2026-08-24 16:59:34 -04:00

README.md

hosts_statiques

Plancher de résolution : génère /etc/hosts depuis l'inventaire, pour que tout l'écosystème se résolve par nom même DNS éteint.

Rôle

Génère /etc/hosts (template hosts.j2) à partir des hôtes actifs de l'inventaire : IP, nom court, FQDN interne.
Alias d'exposition (optionnel, actif par défaut) : pose <IP de l'edge> <FQDN exposé> pour chaque application qui déclare un expose dans le plan — la résolution des services publiés ne dépend donc pas non plus du DNS.

Pourquoi

C'est ce qui rend l'ordre de reconstruction possible : appliqué dans la couche socle (via playbooks/groupes/serveur_debian.yml), il donne la résolution par nom avant que serveur_powerdns n'existe. Sans lui, tout service référençant un FQDN interne (resoudre_base, resoudre_annuaire, certificats step_ca…) échouerait au premier déploiement d'une instance neuve.

Les trois couches de résolution : ce plancher → PowerDNS autoritatif → Unbound local (client_resolveur, opt-in). Cf. docs/dns-interne.md.

Variables

Variable	Défaut	Rôle
`hosts_statiques_actif`	`true`	Génère (ou non) `/etc/hosts`
`hosts_statiques_domaine`	`{{ domaine_interne }}`	Suffixe des FQDN
`hosts_statiques_publier_expositions`	`true`	Ajoute les alias `expose` → edge
`hosts_statiques_expositions`	`[]`	Calculé par le rôle (filtre `expositions_des_applications`)

Notes / limites

Les alias d'exposition sont best-effort : le rôle lit applications.yml et domaines.yml sur le nœud de contrôle (delegate_to: localhost, stat d'abord). Plan absent (ex. préparation du golden template) → alias simplement omis, pas d'échec.
Le fichier est entièrement géré par Ansible : toute ligne ajoutée à la main sur un nœud est écrasée au prochain passage. C'est voulu (source unique = le plan).
Postfix tourne en chroot : serveur_postfix recopie ce /etc/hosts dans /var/spool/postfix/etc/ pour que le MTA bénéficie du même plancher.

Prérequis

domaine_interne défini ; setops_plan_dir pour les alias d'exposition.
Filtre expositions_des_applications (filter_plugins/).