Set-OPS-Public/roles/serveur_resolveur_site
Daniel Allaire a5c9a88f00 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
..
defaults resolveur du site : le troisieme service prete pendant la jeunesse d un tenant 2026-08-30 12:37:33 -04:00
meta resolveur du site : le troisieme service prete pendant la jeunesse d un tenant 2026-08-30 12:37:33 -04:00
tasks resolveur du site : le troisieme service prete pendant la jeunesse d un tenant 2026-08-30 12:37:33 -04:00
README.md resolveur du site : le troisieme service prete pendant la jeunesse d un tenant 2026-08-30 12:37:33 -04:00

serveur_resolveur_site

Le marqueur du résolveur du site. Il dit que ce résolveur est celui que les écosystèmes de ce site interrogent tant qu'ils n'ont pas le leur, et déclare le flux qui le permet. Il n'installe rien.

Le troisième service prêté

C'est le même patron que serveur_artefacts + serveur_cache_site, et que serveur_forgejo + serveur_forge_site : un installateur, un marqueur.

ce que le site prête pendant la jeunesse du tenant
les paquets serveur_cache_site
le génome serveur_forge_site
les noms ce rôle

Ce qu'il a corrigé

Mesuré le 2026-08-30 sur infra-pki-01, première machine à porter l'autorité de certification de Chezlepro :

DNS               BLOQUÉ      un tenant résout chez lui, sa requête ne sort pas
443 sortant       OK          par adresse
apt via le cache  OK          le mandataire résout à sa place

apt s'en sortait ; tout le reste était aveugle aux noms — un get_url, un dépôt tiers en HTTPS, un git clone. Versionner la clé de signature Smallstep a fait passer une tâche, et l'échec s'est déplacé d'un cran : le dépôt lui-même devait être joint par son nom.

Pourquoi pas l'Unbound de la frontière

Il tourne sur le boîtier sans être un service géré, et le plan du site l'avait déjà écrit une fois : « un processus n'est pas un service ». site-dns-01 est déployé par le moteur, vérifié par le harnais, et porte ses flux.

Où vit la dérivation

La liste d'autorisation est calculée par scripts/site_inventaire.py, qui connaît le plan du site et le registre des tenants. Le rôle, lui, tourne sur une machine qui n'a aucune raison de lire la carte de l'hébergeur — la dérivation appartient à qui détient les deux sources.

Attention au filtre : resoudre_flux._supernets_voisins() exclut l'instance montée (personne n'est son propre voisin). Le site sert tous ceux qu'il héberge, y compris celui qu'on déploie — sans quoi le seul tenant en cours de montage serait précisément celui qu'on prive de résolution.

Ce que ce rôle ne fait pas

Il n'installe rien, n'ouvre aucun port, ne sauvegarde rien. Il attribue une responsabilité — et vérifie deux choses : que le résolveur écoute, et que sa liste d'autorisation admet réellement les tenants du site. Sans la seconde, la panne chez le locataire ressemblerait à un DNS mort alors que c'est une ACL.