Daniel Allaire
1295eeaf4e
Contrainte de l'exploitant apres avoir vu backup-01 et collab-01 crees avant l'AC et le DNS. Ma premiere reponse etait incomplete : un clone est bien inerte, mais un echec a la 12e VM coute 40 minutes sans rien deployer, et le journal donne l'impression que le moteur ignore ses couches. Mesure avant de coder : - enregistrements A : DEJA derives du plan (zone generee depuis hotes_actifs) - zone inverse / PTR : n'existe NULLE PART, aucun role ne touche in-addr.arpa - ordre d'amorcage : aucun, deployer-tout est par couches Le premier point a reduit le travail de moitie — j'allais ecrire un enrolement DNS par hote alors que la zone directe etait deja correcte. Zone inverse derivee du supernet (27.10.in-addr.arpa), PTR issus de la MEME source que les A : pas d'endroit ou elles puissent diverger. Vide si le supernet n'est pas un /16. _amorcer-socle monte l'AC puis le DNS completement avant deployer-tout ; les deux derives de applications.<app>.hote, dans un ordre causal et non alphabetique. Deux exceptions assumees : l'AC s'auto-signe, le DNS pose son propre enregistrement. P10 a attrape un handler que je venais d'inventer (Recharger PowerDNS au lieu de Validate and reload PowerDNS) avant tout deploiement. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
10 lines
339 B
Django/Jinja
10 lines
339 B
Django/Jinja
zone "{{ serveur_powerdns_zone }}" {
|
|
type master;
|
|
file "{{ serveur_powerdns_zone_directory }}/{{ serveur_powerdns_zone }}.zone";
|
|
};
|
|
{% if serveur_powerdns_zone_inverse %}
|
|
zone "{{ serveur_powerdns_zone_inverse }}" {
|
|
type master;
|
|
file "{{ serveur_powerdns_zone_directory }}/{{ serveur_powerdns_zone_inverse }}.zone";
|
|
};
|
|
{% endif %}
|