Daniel Allaire a1997774be frontiere : appliquee, et la contrainte de nommage d'OPNsense consignee

Devis clos : 0 a creer, 0 a retirer, 65 inchange + 15 routes. Flotte verifiee
apres coup -- DNS interne, Internet et apt sans erreur sur les cinq hotes.

OPNsense refuse un alias de 32 caracteres ou plus. La contrainte n'etait ecrite
nulle part et se manifestait a l'APPLICATION, pas au devis. nom_alias abrege
desormais (SERVEUR_ -> SRV_, comme le pare-feu est-ouest) et REFUSE bruyamment
si le nom deborde encore : un devis qui promet un objet que la cible rejettera
n'est pas un devis. Le role devient serveur_cache_site.

« RIEN N'EST APPLIQUE » signifiait « pas encore recharge », pas « rien ecrit » :
les objets etaient dans la config, le pare-feu en marche les ignorait. J'avais
lu le message a l'envers.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-24 17:51:29 -04:00

2.3 KiB

Raw Blame History

serveur_cache_site

Le cache d'artefacts du SITE : celui que les écosystèmes voisins prennent comme amont, pour que Debian ne soit téléchargé qu'une fois pour toute la fabric.

Le chaînage

VM du tenant  →  cache du tenant  →  cache du SITE  →  Debian

Chaque écosystème garde le sien — il reste maître de ses paquets et s'en émancipe d'un drapeau — mais il ne va plus chercher chez Debian.

Un cache unique où toutes les VM taperaient aurait demandé un flux de chaque machine de chaque tenant vers un hôte d'un autre tenant : N×M chemins à travers le default-deny. Avec le chaînage il n'y en a qu'un par écosystème, entre deux caches.

Et l'étanchéité y gagne : le cache du site ne voit que des requêtes agrégées, jamais quelle machine installe quoi.

Pourquoi deux rôles plutôt qu'un drapeau

Les flux se déclarent dans meta/flux.yml, qui est statique. Un rôle unique aurait dû déclarer l'ingress inter-tenant pour tous les caches — et le devis l'a montré :

+ TENANT_PATI29 -> CHEZ17_SERVEUR_ARTEFACTS     un maillage complet,
+ TENANT_TECH23 -> CHEZ17_SERVEUR_ARTEFACTS     chaque cache acceptant chaque autre

Avec la séparation, l'ingress n'existe qu'ici, et un seul cache est joignable.

Qui peut le déclarer

L'écosystème de l'hébergeur, celui qui exploite la fabric. Un tenant ordinaire qui le déclarerait s'offrirait à servir ses voisins sans y être invité.

C'est le même patron que serveur_ops_site : le runner de site prépare le terrain — VNets, routes, flux — pour que les plans des tenants tiennent. Aucun écosystème n'ouvre de porte chez un autre ; c'est le site qui autorise.

Ce qu'il vérifie

Qu'il ne se chaîne pas lui-même. Il est le bout de la chaîne : le laisser pointer sur un amont ferait tourner les paquets en rond entre deux caches, ou les ferait sortir du site sans que personne ne l'ait décidé.

Que le cache écoute vraiment. Le rôle n'installe rien : sa seule prise sur le réel est de vérifier que le service qu'il désigne existe. Sans ça, il attribuerait une responsabilité à un port que personne n'écoute.

Ce que ce rôle ne fait pas

Il n'installe ni ne configure apt-cacher-ng — c'est serveur_artefacts. Il attribue une responsabilité et la rend lisible dans le plan.

2.3 KiB Raw Blame History Unescape Escape