Sonene trenger ikke stå i [zones] på sentralen. En sone sender hjerteslag
hvert 30. s (POST /api/mesh/register med navn, egen adresse og
mesh-nøkkelen), dukker opp i lista med en gang, og tas ut etter 90 s uten
slag. Riktig nøkkel er godkjenningen. Statisk [zones] vinner over et navn
som melder seg (409) – en skrivefeil i config skal ikke kunne overstyres av
en boks på nettet.
Hvorfor push og ikke pull fra NetBird: netbird status --json gir navn, IP og
status per peer, men ikke grupper. Pull ville krevd en service-token mot
management-serveren og virket bare over NetBird. Push virker likt over
NetBird og LAN, uten token, og gir liveness gratis.
Sonen finner sentralen lagvis: ANNOUNCER_SENTRAL hvis satt (NetBird-DNS-navn,
konvensjon announcer-<navn>.skynet.corp), ellers mDNS (_announcer._tcp,
discovery.py). Egen adresse regnes ut som ruten mot sentralen – over NetBird
blir det wt0-adressen, på LAN LAN-adressen – med ANNOUNCER_URL som
overstyring. Hjerteslag hvert 5. s til første OK, så oppstart ikke tar et
halvt minutt.
Containeren bruker nå vertens nett. mDNS-multicast når ikke LAN-et fra
bridge-nettet, så det var ingen vei utenom – og det ga tilbake ufw: det
gamle Docker-smutthullet er borte, portregler virker igjen, og BIND_IP er
appens eget --host. Appen lytter alltid også på 127.0.0.1 for helsesjekken.
install.sh tar NETBIRD_SETUP_KEY: installerer NetBird, melder maskina inn
som announcer-<navn>, venter på wt0, binder til NetBird-adressen.
Management-URL leses fra /etc/netbird/config.json når den finnes.
Rollen avgjøres av config (Config.role): sentral hvis [zones] eller
ANNOUNCER_ROLE=sentral, sone hvis bare nøkkelen er satt, ellers som før.
Dispatcher og ZonePoller slår opp soner ved hver bruk, siden de kommer og
går. register følger, som play, aldri med «alt åpent». Flask sorterte
JSON-nøkler alfabetisk, så sonene kom i feil rekkefølge i /api/status –
app.json.sort_keys = False.
25 nye tester, 173 totalt. Verifisert i compose på host-nett: to soner
meldte seg innen 4 s uten noe [zones], fordeling til en av dem havnet i kø,
avahi-browse på verten ser sentralen, en stoppet sone ble tatt ut etter 90 s
og var tilbake 2 s etter start. Underveis fant live-testen at testkonfigen
fortsatt hadde statiske a/b – og sentralen avviste hjerteslagene med 409,
som den skal.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Crew-panelet har ikke OIDC ennå, så OIDC-veien kunne ikke prøves i det hele
tatt – bare enhetstestes mot et stubbet HTTP-lag. Dette gir noe å faktisk
logge inn i.
docker compose up --build
localhost:8091 announcer med PIN, JWT og OIDC slått på samtidig
localhost:9000 docker/dummy_idp.py, som står for crew-panelet
8091 med vilje, så den ikke kolliderer med tjenesten på 8090.
Dummy-IdP-en kjører en ekte autorisasjonskode-runde: den krever PKCE med
S256, avviser feil code_verifier, bruker koden bare én gang, og signerer
id_token med klienthemmeligheten. Du velger hvem du logger inn som – Kari
(crew), Kent (admin) eller Ola, som har null roller og dermed skal gi 403
og ikke 401. /token?who=kari&go=1 logger deg inn via token-lenka, slik
panelet skal gjøre.
To ting i oppsettet som ser rart ut, men ikke er det:
- authorization_endpoint peker på localhost:9000 fordi nettleseren skal
dit, mens token_endpoint peker på idp:9000 fordi announcer selv snakker
med den inne i compose-nettet. Delt horisont. Det tester samtidig at
manuelle endepunkter virker, som er veien når et panel mangler discovery.
- UV_PROJECT_ENVIRONMENT=/opt/venv i bildet: /app er et bind-mount av
repoet, og uten den ville containerens uv sync overskrevet .venv som den
kjørende tjenesten bruker.
/run/user/1000 er montert inn, så pw-play i containeren spiller på vertens
anlegg. Det er verifisert; kommenter ut linja hvis du bare skal teste UI.
Docker er bare for testing. På en ekte maskin kjører appen nativt med
install.sh, fordi lyden skal ut på maskinens egen lydutgang.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>