Daniel Allaire
a74e35bf21
Some checks are pending
verifier / verifier (push) Waiting to run
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>
38 lines
1.5 KiB
Django/Jinja
38 lines
1.5 KiB
Django/Jinja
# Managed by Ansible — Set-OPS
|
|
|
|
datasource_list: [ NoCloud, ConfigDrive, None ]
|
|
|
|
preserve_hostname: false
|
|
# `manage_etc_hosts` N'EST PAS ICI, ET C'EST VOULU (2026-08-25).
|
|
#
|
|
# Ce fragment le posait a `true`, pendant que `hosts_statiques` en posait un autre a
|
|
# `false`. Deux ecritures, deux fichiers, un desaccord — et dans `cloud.cfg.d` l'ordre
|
|
# est LEXICAL : `99-setops-hosts.cfg` (`-`, 0x2D) est lu avant `99_setops.cfg` (`_`,
|
|
# 0x5F). C'est donc celui-ci qui gagnait, et cloud-init reecrivait /etc/hosts a chaque
|
|
# demarrage — effacant le plancher de resolution en silence.
|
|
#
|
|
# Le defaut ne se voit qu'au redemarrage SUIVANT, et il se manifeste ailleurs : un `apt
|
|
# update` qui ne resout plus le cache, un certificat dont le nom ne pointe nulle part.
|
|
# Mesure du 2026-08-25 : les cinq machines du site redemarrees, /etc/hosts reduit aux
|
|
# entrees Debian par defaut, avec un `127.0.1.1 site-pki-01.chezlepro.ca` venu du
|
|
# `searchdomain` Proxmox — pas meme le bon domaine.
|
|
#
|
|
# LE ROLE QUI POSSEDE LE FICHIER DECIDE : `hosts_statiques` ecrit /etc/hosts, c'est donc
|
|
# lui qui dit si cloud-init peut y toucher. Quand il est inactif, rien ne l'interdit plus
|
|
# et cloud-init reprend son comportement par defaut — ce qui est le bon repli.
|
|
disable_root: {{ cloud_init_disable_root | bool | lower }}
|
|
ssh_pwauth: {{ cloud_init_ssh_pwauth | bool | lower }}
|
|
|
|
ssh_deletekeys: {{ cloud_init_ssh_deletekeys | bool | lower }}
|
|
ssh_genkeytypes:
|
|
- rsa
|
|
- ecdsa
|
|
- ed25519
|
|
|
|
growpart:
|
|
mode: auto
|
|
devices:
|
|
- /
|
|
ignore_growroot_disabled: false
|
|
|
|
resize_rootfs: true
|