Set-OPS-Public/roles/serveur_powerdns/tasks/main.yml
Daniel Allaire a74e35bf21
Some checks are pending
verifier / verifier (push) Waiting to run
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

104 lines
3.8 KiB
YAML

---
- name: Installer PowerDNS Authoritative
ansible.builtin.apt:
name: "{{ serveur_powerdns_packages }}"
state: present
update_cache: true
cache_valid_time: 3600
- name: Créer le répertoire des zones PowerDNS
ansible.builtin.file:
path: "{{ serveur_powerdns_zone_directory }}"
state: directory
owner: root
group: root
mode: "0755"
- name: Déployer la configuration du backend BIND
ansible.builtin.template:
src: setops-bind.conf.j2
dest: /etc/powerdns/pdns.d/setops-bind.conf
owner: root
group: root
mode: "0644"
notify: Validate and reload PowerDNS
- name: Déployer l'index des zones PowerDNS
ansible.builtin.template:
src: bindbackend.conf.j2
dest: "{{ serveur_powerdns_bind_config }}"
owner: root
group: root
mode: "0644"
notify: Validate and reload PowerDNS
# CHAQUE REGISTRE EST CHARGE POUR LUI-MEME (2026-08-25).
#
# Ce `include_vars` listait les deux fichiers en dur et echouait si l'un manquait.
# `domaines.yml` declare les domaines PUBLICS, et un ecosysteme peut legitimement n'en
# avoir aucun — c'est le cas du SITE, dont tous les services sont internes.
#
# Le defaut est reste invisible tant que le site gardait `publier_expositions: false` ;
# il est apparu a la seconde ou on a voulu publier ses noms de service. C'est le MEME
# defaut que `hosts_statiques` a corrige le meme jour, dans les memes termes : un registre
# absent n'est pas une faute, il est simplement absent.
- name: Vérifier la présence des registres du plan (sur le nœud de contrôle)
ansible.builtin.stat:
path: "{{ item }}"
register: serveur_powerdns_plan
delegate_to: localhost # les registres du plan vivent sur le nœud de contrôle
become: false # lire un fichier ne nécessite pas de privilèges
loop:
- "{{ setops_plan_dir }}/applications.yml"
- "{{ setops_plan_dir }}/domaines.yml"
loop_control:
label: "{{ item | basename }}"
when: serveur_powerdns_publier_expositions | bool
- name: Charger les registres applications et domaines (si présents)
ansible.builtin.include_vars:
file: "{{ item.item }}"
loop: "{{ serveur_powerdns_plan.results | default([]) }}"
loop_control:
label: "{{ item.item | basename }}"
when:
- serveur_powerdns_publier_expositions | bool
- item.stat.exists | default(false)
- name: Dériver les A d'exposition (FQDN publics -> edge qui les sert)
ansible.builtin.set_fact:
serveur_powerdns_expositions: >-
{{ {'applications': applications | default({})}
| expositions_des_applications({'domaines_publics': domaines_publics | default({})}) }}
when: serveur_powerdns_publier_expositions | bool
- name: Générer la zone DNS interne depuis l'inventaire
ansible.builtin.template:
src: zone.db.j2
dest: "{{ serveur_powerdns_zone_directory }}/{{ serveur_powerdns_zone }}.zone"
owner: root
group: root
mode: "0644"
notify: Validate and reload PowerDNS
# Meme source que la zone directe : `hotes_actifs` et son `ansible_host`. Deux zones
# alimentees par une seule verite — l'endroit ou elles divergeraient n'existe pas.
- name: Générer la zone DNS inverse depuis l'inventaire
ansible.builtin.template:
src: zone-inverse.db.j2
dest: "{{ serveur_powerdns_zone_directory }}/{{ serveur_powerdns_zone_inverse }}.zone"
owner: root
group: root
mode: "0644"
when: serveur_powerdns_zone_inverse | length > 0
notify: Validate and reload PowerDNS
- name: Activer et démarrer PowerDNS
ansible.builtin.systemd:
name: "{{ serveur_powerdns_service_name }}"
enabled: true
state: started
# Dry-run (--check) : le paquet n'est pas reellement installe, donc le service
# n'existe pas encore et systemd echouerait. On saute en mode check seulement ;
# en vrai deploiement, la tache s'execute normalement.
when: not ansible_check_mode