ThysTips_dn42/infra-dn42
1
0
Fork 0
Code Issues Pull requests 1 Projects Releases Packages Wiki Activity Actions

feat(looking_glass) : le relais whois descend en conteneur, le dernier ip vrf exec s'en va #37

Merged
thystips merged 1 commit from feat/lg-whois-container into main 2026-08-14 02:16:13 +02:00
Conversation 0 Commits 1 Files changed 13 +621 -228
thystips commented 2026-08-13 00:48:52 +02:00
Owner
Copy link

Le relais whois du looking glass tourne désormais dans un conteneur lg, posé sur les deux nœuds qui portent roles.lg. Le frontal, lui, reste sur le nœud.

Ce que le déménagement retire

Le seul montage du dépôt où un processus était à cheval sur deux tables de routage : la socket était créée par systemd en table globale et passée par descripteur, le service tournait sous ip vrf exec — donc en root — et seul son sortant héritait de la VRF. whois.dn42 n'existe que dans l'overlay ; un conteneur y a simplement une patte.

C'était aussi le dernier ip vrf exec sous root et la dernière socket activée par systemd du dépôt.

Pourquoi le frontal n'a pas suivi

Ce n'est pas une étape oubliée. Il interroge les quatre agents sur le plan de management, hors-bande, et c'est la propriété pour laquelle ce rôle existe sous cette forme — un looking glass qui interrogerait ses agents par l'overlay cesserait de fonctionner au moment exact où on l'ouvre. Un conteneur a DN42 et le pont NATé, ni l'un ni l'autre n'étant ce plan-là.

Le descendre demande de lui donner une patte privée à lui, ce qui est une décision sur ens3 à Bordeaux : la seule carte de ce nœud, qui porte son IPv6 publique et ses deux routes par défaut. Rien ici ne la préjuge — le jour où la patte existera, le frontal rejoindra ce conteneur et le relais disparaîtra avec lui.

looking_glass devient donc le premier rôle du dépôt à tourner des deux côtés, d'où la scission node.yml / container.yml et les deux listes de gabarits de render-check qui empêchent chaque moitié de vérifier la portée de l'autre.

Le chemin, et pourquoi aucune règle n'a été ajoutée

Le nœud joint le relais par 10.42.0.43, sur le pont NATé — exactement comme il joint son résolveur par 10.42.0.53. Même motif, même raison (un processus en table globale ne joint aucun conteneur par DN42), et la même propriété : l'adresse est identique sur les deux nœuds, donc locale par construction.

Le sortant du nœud vers son propre pont relève de la politique accept d'output, et l'adresse n'étant pas dans @dn42_v4 elle ne rencontre pas le garde-fou anti-fuite. La matrice est mise à jour dans le même commit.

Le garde-fou du démontage, et il a servi

lg-whois-teardown.yml refuse de retirer les unités locales tant que le conteneur ne répond pas. Le mode de panne d'un whois absent est entièrement muet côté frontal : la page se rend, les sections Bird sont pleines, et le bloc whois est simplement vide.

⚠ État du déploiement

fr-rbx1 et son conteneur : déployés et vérifiés (relais actif, whois.dn42 résolu depuis le conteneur, frontal basculé, unités locales retirées, page /whois/AS4242421607 servie).

fr-bod1 : en attente, et son garde-fou a fait son travail — il a refusé, le conteneur ne répondant pas. La cause n'est pas dans cette PR : c'est le retour asymétrique vers les conteneurs, décrit dans la PR #36. fr-bod1 garde donc son relais local et sert normalement. Le nœud sera terminé dès que le /64 par nœud sera en place.

🤖 Generated with Claude Code

https://claude.ai/code/session_01FGwvXLVXJ2PrRFwJTB3Xp9

Le relais whois du looking glass tourne désormais dans un conteneur `lg`, posé sur les deux nœuds qui portent `roles.lg`. **Le frontal, lui, reste sur le nœud.** ## Ce que le déménagement retire Le seul montage du dépôt où un processus était à cheval sur **deux tables de routage** : la socket était créée par systemd en table globale et passée par descripteur, le service tournait sous `ip vrf exec` — donc **en root** — et seul son sortant héritait de la VRF. `whois.dn42` n'existe que dans l'overlay ; un conteneur y a simplement une patte. C'était aussi le dernier `ip vrf exec` sous root et la dernière socket activée par systemd du dépôt. ## Pourquoi le frontal n'a pas suivi Ce n'est pas une étape oubliée. Il interroge les quatre agents sur le **plan de management**, hors-bande, et c'est la propriété pour laquelle ce rôle existe sous cette forme — un looking glass qui interrogerait ses agents par l'overlay cesserait de fonctionner au moment exact où on l'ouvre. Un conteneur a DN42 et le pont NATé, ni l'un ni l'autre n'étant ce plan-là. Le descendre demande de lui donner une patte privée à lui, ce qui est une décision sur `ens3` à Bordeaux : la **seule carte de ce nœud**, qui porte son IPv6 publique et ses deux routes par défaut. Rien ici ne la préjuge — le jour où la patte existera, le frontal rejoindra ce conteneur et le relais disparaîtra avec lui. `looking_glass` devient donc **le premier rôle du dépôt à tourner des deux côtés**, d'où la scission `node.yml` / `container.yml` et les deux listes de gabarits de `render-check` qui empêchent chaque moitié de vérifier la portée de l'autre. ## Le chemin, et pourquoi aucune règle n'a été ajoutée Le nœud joint le relais par `10.42.0.43`, sur le pont NATé — exactement comme il joint son résolveur par `10.42.0.53`. Même motif, même raison (un processus en table globale ne joint aucun conteneur par DN42), et la même propriété : l'adresse est identique sur les deux nœuds, donc **locale par construction**. Le sortant du nœud vers son propre pont relève de la politique `accept` d'`output`, et l'adresse n'étant pas dans `@dn42_v4` elle ne rencontre pas le garde-fou anti-fuite. La matrice est mise à jour dans le même commit. ## Le garde-fou du démontage, et il a servi `lg-whois-teardown.yml` **refuse** de retirer les unités locales tant que le conteneur ne répond pas. Le mode de panne d'un whois absent est entièrement muet côté frontal : la page se rend, les sections Bird sont pleines, et le bloc whois est simplement vide. ## ⚠ État du déploiement **fr-rbx1 et son conteneur : déployés et vérifiés** (relais actif, `whois.dn42` résolu depuis le conteneur, frontal basculé, unités locales retirées, page `/whois/AS4242421607` servie). **fr-bod1 : en attente**, et son garde-fou a fait son travail — il a refusé, le conteneur ne répondant pas. La cause n'est pas dans cette PR : c'est le retour asymétrique vers les conteneurs, décrit dans la PR #36. `fr-bod1` garde donc son relais local et sert normalement. Le nœud sera terminé dès que le `/64` par nœud sera en place. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01FGwvXLVXJ2PrRFwJTB3Xp9
Le relais whois du looking glass tourne désormais dans un conteneur `lg`, posé
sur les deux nœuds qui portent `roles.lg`. Le frontal, lui, RESTE sur le nœud.

Ce qui part avec le déménagement est le seul montage du dépôt où un processus
était à cheval sur DEUX TABLES DE ROUTAGE : la socket était créée par systemd en
table globale et passée par descripteur, le service tournait sous `ip vrf exec`
— donc en root — et seul son sortant héritait de la VRF. `whois.dn42` n'existe
que dans l'overlay ; un conteneur y a simplement une patte.

Le frontal n'a pas suivi, et ce n'est pas une étape oubliée : il interroge les
quatre agents sur le plan de MANAGEMENT, hors-bande, et c'est la propriété pour
laquelle ce rôle existe sous cette forme — un looking glass qui interrogerait
ses agents par l'overlay cesserait de fonctionner au moment exact où on l'ouvre.
Un conteneur a DN42 et le pont NATé, ni l'un ni l'autre n'étant ce plan-là. Le
descendre demande de lui donner une patte privée à lui, ce qui est une décision
sur `ens3` à Bordeaux : la seule carte de ce nœud, qui porte son IPv6 publique
et ses deux routes par défaut.

`looking_glass` devient donc le premier rôle du dépôt à tourner DES DEUX CÔTÉS,
d'où la scission `node.yml` / `container.yml` et les deux listes de gabarits de
`render-check` qui empêchent chaque moitié de vérifier la portée de l'autre.

Le nœud joint le relais par `10.42.0.43`, sur le pont NATé, exactement comme il
joint son résolveur par `10.42.0.53` : même motif, même raison — un processus en
table globale ne joint aucun conteneur par DN42 — et la même propriété, l'adresse
étant identique sur les deux nœuds donc locale par construction.

Aucune règle de pare-feu ajoutée : le sortant du nœud vers son propre pont relève
de la politique `accept` d'`output`, et l'adresse n'étant pas dans `@dn42_v4`
elle ne rencontre pas le garde-fou anti-fuite. La matrice est mise à jour dans ce
commit.

`lg-whois-teardown.yml` retire les unités locales, avec un garde-fou en pre_task
qui REFUSE de le faire tant que le conteneur ne répond pas : le mode de panne
d'un whois absent est entièrement muet côté frontal — la page se rend, les
sections Bird sont pleines, et le bloc whois est simplement vide.

Déployé sur fr-rbx1 et son conteneur. fr-bod1 est en attente, bloqué par un
défaut ANTÉRIEUR et sans rapport, décrit dans la conversation.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGwvXLVXJ2PrRFwJTB3Xp9
thystips deleted branch feat/lg-whois-container 2026-08-14 02:16:13 +02:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
ThysTips_dn42/infra-dn42!37
No description provided.