Set-OPS-Public/roles/cloud_init/defaults/main.yml

---
cloud_init_ssh_pwauth: false
# `cloud_init_manage_etc_hosts` A ETE RETIREE (2026-08-25) : elle entrait en conflit avec
# le fragment de `hosts_statiques`, qui possede /etc/hosts et decide seul si cloud-init
# peut y toucher. La garder ici, sans effet, serait un mensonge — une variable qu'on
# renseigne et qui ne change rien est pire que son absence.
cloud_init_disable_root: true
cloud_init_ssh_deletekeys: true
Set-OPS — moteur d'ecosystemes numeriques souverains (Alliance Boreale) 2026-06-24 20:17:46 -04:00			`---`
			`cloud_init_ssh_pwauth: false`
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			# `cloud_init_manage_etc_hosts` A ETE RETIREE (2026-08-25) : elle entrait en conflit avec
			# le fragment de `hosts_statiques`, qui possede /etc/hosts et decide seul si cloud-init
			`# peut y toucher. La garder ici, sans effet, serait un mensonge — une variable qu'on`
			`# renseigne et qui ne change rien est pire que son absence.`
Set-OPS — moteur d'ecosystemes numeriques souverains (Alliance Boreale) 2026-06-24 20:17:46 -04:00			`cloud_init_disable_root: true`
			`cloud_init_ssh_deletekeys: true`