Set-OPS-Public/roles/serveur_resolveur_site/meta/main.yml

16 lines
780 B
YAML
Raw Normal View History

resolveur du site : le troisieme service prete pendant la jeunesse d un tenant Apres les paquets (serveur_cache_site) et le genome (serveur_forge_site), les NOMS. Meme patron : un installateur, un marqueur. CE QUE CA CORRIGE, mesure sur infra-pki-01, premiere machine a porter l autorite de Chezlepro : DNS BLOQUE un tenant resout chez lui, sa requete ne sort pas 443 sortant OK par adresse apt via le cache OK le mandataire resout a sa place apt s en sortait ; TOUT LE RESTE ETAIT AVEUGLE AUX NOMS. Versionner la cle de signature Smallstep a fait passer une tache et l echec s est deplace d un cran : le depot lui-meme devait etre joint par son nom. POURQUOI PAS L UNBOUND DE LA FRONTIERE : il tourne sur le boitier sans etre un service gere, et le plan du site l avait deja ecrit une fois — un processus n est pas un service. site-dns-01 est deploye par le moteur et verifie par le harnais. OU VIT LA DERIVATION : dans site_inventaire.py, qui connait le plan du site ET le registre des tenants. Le role tourne sur une machine qui n a aucune raison de lire la carte de l hebergeur — la derivation appartient a qui detient les deux sources. PIEGE DE FILTRE, ATTRAPE EN LE BRANCHANT : _supernets_voisins() EXCLUT l instance montee (personne n est son propre voisin). Le site sert TOUS ceux qu il heberge — y compris celui qu on deploie. Reutilise tel quel, il privait de resolution le seul tenant en cours de montage. On reutilise donc la DECOUVERTE partagee sans son filtre : deux recensements divergent, deux filtres non. Le marqueur verifie deux choses : que le resolveur ECOUTE, et que sa liste d autorisation ADMET reellement les tenants. Sans la seconde, la panne chez le locataire ressemblerait a un DNS mort alors que c est une ACL. make verifier : vert. make prouver : CONFORME, 55 OK, 0 echec, 0 saute. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019f91zs9SDdwSzL2CVei6on
2026-08-30 12:37:33 -04:00
---
# CE RÔLE EN EXIGE UN AUTRE, ET C'EST À ANSIBLE DE LE SAVOIR.
#
# `serveur_resolveur_site` n'installe rien : il MARQUE un résolveur comme celui que les
# écosystèmes du site interrogent pendant leur jeunesse, et vérifie qu'il écoute vraiment.
# Pour cela il lit les variables de `serveur_resolveur`.
#
# Les valeurs par défaut d'un rôle ne sont en portée que DANS LE PLAY QUI L'INCLUT. Une
# dépendance de rôle règle les deux choses d'un coup : Ansible applique l'installateur
# AVANT le marqueur, dans le MÊME play, donc ses variables sont en portée — et l'ordre
# cesse de dépendre de la façon dont on lance le déploiement.
#
# Même raisonnement, mot pour mot, que `serveur_cache_site` et `serveur_forge_site`.
dependencies:
- role: serveur_resolveur