d07e7c3d90
Moves the Prosody server, xmpp-web frontends (chat/plaza), and Forgejo's wiki-update webhook notifier from pinix to blunix, co-located with Traefik/ACME so TLS comes straight from Traefik's cert store instead of the old manual copy process. pinix's prosody/xmpp-web/webhook modules stay in place but deactivated as a fallback, matching the earlier Forgejo migration's pattern. Implements docs/intent/xmpp-umzug-pinix-blunix.md. Deployed and verified live on blunix (nixos-rebuild switch, chat/plaza returning 200, prosody healthy, agent XMPP listeners reconnected). Two first-bootstrap bugs found and fixed during that verification, both specific to bringing Prosody up on a host it never ran on before: - prosody-certs-sync.service used to call a blocking `systemctl reload-or-restart prosody.service` whenever the cert file differed from what's installed -- including on first activation, where prosody.service's own start job is still queued behind this unit (Requires+After), deadlocking forever. Now only reloads an already-running Prosody; ordering alone brings up a fresh one with the cert just installed. - hosts/blunix/localServices/secrets.nix force-owned the global `bindPW` secret to root with the (previously correct) rationale that it belongs to a pinix-only service. Prosody now runs on blunix too and needs to read it directly as its own LDAP bind config include, so that override no longer applies to it. pinix's own deploy (data migration, DNS/webhook cutover) is separate follow-up work, not part of this commit. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ANg2L2xUmNJ45t9mcv6HVT
130 lines
7.1 KiB
Markdown
130 lines
7.1 KiB
Markdown
# Intent: XMPP/Prosody-Umzug von pinix nach blunix
|
|
|
|
## Ziel
|
|
|
|
Den kompletten XMPP-Stack (Prosody-Server, Web-Frontends, Zertifikatsverwaltung,
|
|
Forgejo-Benachrichtigung) von `pinix` nach `blunix` umziehen, mit derselben
|
|
Resilienz-Motivation wie beim bereits abgeschlossenen Forgejo-Umzug
|
|
(`docs/roadmap.md`, "Forgejo-Umzug von pinix nach blunix — erledigt
|
|
(06.09.2026)"): Erreichbarkeit unabhängig von `pinix`-Ausfällen.
|
|
|
|
## Umfang
|
|
|
|
- Prosody-Server (`hosts/pinix/localServices/prosody/setup-prosody.nix`) inkl.
|
|
aller virtualHosts (`${domain}`, `bot.${domain}`), MUC-Konfiguration,
|
|
HTTP-Upload (`httpFileShare`) — Modul zieht nach `blunix` um.
|
|
- Vollständige 1:1-Datenübernahme von `/var/lib/prosody` (Accounts, Roster,
|
|
MUC-Archiv, Uploads) von pinix nach blunix. Bestehende MUC-Bot-Affiliations
|
|
(z. B. `update@muc`, `lobby@muc`) bleiben dadurch automatisch erhalten.
|
|
- xmpp-web-Frontends (`chat.0ff.space`, `plaza.0ff.space`,
|
|
`hosts/pinix/localServices/xmpp-web.nix`) inkl. nginx-Reverse-Proxy ziehen
|
|
mit um.
|
|
- TLS-Umstellung: weg vom manuellen Zertifikats-Kopierprozess (aktuell
|
|
dokumentiert in `hosts/pinix/localServices/prosody/README.md`, Abschnitt
|
|
"Refresh the TLS certificate"), hin zu direktem Zugriff auf die von Traefik
|
|
verwalteten Zertifikate, da Prosody jetzt co-located mit der
|
|
ACME-Terminierung läuft.
|
|
- Wegfall der bisherigen blunix-seitigen Passthrough-Konfiguration, da das
|
|
Backend nun lokal läuft:
|
|
- `hosts/blunix/localServices/upload-prosody.nix` (Traefik-Loadbalancer →
|
|
`tailnetIPs.pinix:5280`)
|
|
- `hosts/blunix/localServices/traefik/xmpp-web.nix` (TCP-TLS-Passthrough für
|
|
5222/5269 und die Web-Frontends)
|
|
- `wiki-update.sh` (Forgejo-Push-Benachrichtigung nach `update@muc.${domain}`,
|
|
aktuell Teil von `hosts/pinix/localServices/webhook.nix`) zieht mit nach
|
|
`blunix` um, in das dortige `hosts/blunix/localServices/webhook.nix`.
|
|
- Schnittstellenänderungen, die sich aus dem Umzug ergeben (Ergebnis des im
|
|
Chat bestätigten Abgrenzungs-/Schnittstellenchecks):
|
|
- **Forgejo → Webhook-Ziel:** wechselt von
|
|
`tailnetIPs.pinix:9000/hooks/wiki-update` auf lokal (`127.0.0.1` oder
|
|
`tailnetIPs.blunix`, konsistent mit den bestehenden blunix-Hooks). Die
|
|
Repo-seitigen Webhook-URLs (Forgejo-DB, nicht Nix) für `nixos-config`,
|
|
`website`, `dashboard`, `launcher` müssen manuell umgestellt werden.
|
|
- **Forgejo `webhook.ALLOWED_HOST_LIST`**
|
|
(`hosts/blunix/localServices/forgejo.nix`): pinix-Eintrag bleibt trotzdem
|
|
bestehen, solange `gitpull-calendar-web` (calendar-web bleibt auf pinix,
|
|
unabhängig von Vikunja) dort weiter empfängt — nur der `wiki-update`-Teil
|
|
wandert.
|
|
- **AdGuard internes DNS:** chat/plaza/upload sind aktuell öffentliche
|
|
Hostnamen ohne internen Rewrite — voraussichtlich keine Änderung nötig,
|
|
wird bei der Umsetzung gegengeprüft.
|
|
- **LLDAP (blunix):** Prosodys LDAP-Bind wechselt von Tailnet-Adresse
|
|
(`tailnetIPs.blunix:3890`) auf `127.0.0.1:3890` — reiner Lesezugriff,
|
|
keine LLDAP-Konfigänderung.
|
|
- **agent-xmpp-listener (blunix, bereits dort):** verbindet sich schon
|
|
gegen `bot.${domain}`; Zielserver wird nach dem Umzug lokal statt entfernt
|
|
erreichbar — sollte ohne Konfigänderung weiterlaufen, wird nach der
|
|
Migration verifiziert.
|
|
- **Secrets:** `go-sendxmpp.age`, `motd.age`, LDAP-Bind-Passwort — laut
|
|
`secrets/secrets.nix` bereits für alle Hosts entschlüsselbar (siehe
|
|
Annahmen); nötig ist nur das Laufzeit-Wiring (Pfad/Owner) in
|
|
`hosts/blunix/localServices/secrets.nix`.
|
|
- pinix-Prosody-/xmpp-web-/`wiki-update`-Module werden nach dem Umzug
|
|
deaktiviert, nicht gelöscht (Forgejo-Fallback-Muster:
|
|
`systemd.services.<...>.enable = false`, Modulimport bleibt bestehen).
|
|
|
|
## Explizit ausgeschlossen
|
|
|
|
- `vikunja-update.sh` und der `vikunja@`-Bot-Account: bleiben unverändert auf
|
|
pinix. Aktuell ungenutzt (Nutzer setzt Vikunja derzeit nicht ein), daher
|
|
keine Prüfung oder Anpassung im Rahmen dieses Vorhabens.
|
|
- Vikunja selbst bleibt auf pinix, keine Migration.
|
|
- Kein festes Wartungsfenster erforderlich — der Umschaltzeitpunkt ist frei
|
|
wählbar, keine harte Anforderung an Nahtlosigkeit.
|
|
- Root-Cause der pinix-Instabilität (siehe Forgejo-Umzugsnotiz vom
|
|
31.07.2026) wird nicht untersucht — dieses Vorhaben behebt das
|
|
Resilienz-Symptom, nicht die Ursache.
|
|
- Endgültige Stilllegung/Löschung des pinix-Moduls ist explizit spätere
|
|
Nacharbeit, kein Teil dieses Vorhabens.
|
|
- Änderungen an `agents/catalog.json`, `agents/*.md` oder
|
|
`agents/claude-settings/*.json` sind nicht Teil dieses Vorhabens — der
|
|
Umzug berührt nur die Multi-Host-, nicht die Rollen-/Katalog-Grenze.
|
|
|
|
## Annahmen
|
|
|
|
- `go-sendxmpp.age` und `motd.age` sind laut `secrets/secrets.nix`
|
|
(`publicKeys = users ++ systems`) bereits für alle Hosts inkl. blunix
|
|
entschlüsselbar; erforderlich ist nur das Laufzeit-Wiring (Pfad/Owner) in
|
|
`hosts/blunix/localServices/secrets.nix`, keine `agenix -r`-Rotation.
|
|
- LDAP-Auth bleibt inhaltlich unverändert gegen LLDAP (bereits auf blunix
|
|
laufend), wechselt durch die Co-Location lediglich von Tailnet- auf
|
|
Loopback-Zugriff.
|
|
- Federation/S2S (Port 5269) und öffentliche DNS-Einträge ändern sich nicht,
|
|
da blunix bereits der öffentliche Ingress-Punkt für den XMPP-Traffic ist
|
|
(aktuell per TCP-Passthrough).
|
|
- Die Umsetzung (Implementierung, Tests, Aktivierung) übernimmt die
|
|
Admin-Rolle nach diesem Intent-Dokument; der Planner implementiert nichts
|
|
selbst.
|
|
|
|
## Offene Risiken
|
|
|
|
- Split-Brain-Risiko wie beim Forgejo-Umzug: pinix darf während/nach der
|
|
Migration nicht versehentlich reaktiviert werden (z. B. durch einen
|
|
unabhängigen pinix-Redeploy, der das deaktivierte Modul wiederbelebt).
|
|
- TLS-Private-Key-Handling während der Datenübernahme erfordert dieselbe
|
|
Sorgfalt wie der bestehende Zertifikats-Rotationsprozess (Key nie im
|
|
Klartext loggen/committen, korrekte Dateiberechtigungen).
|
|
- Kurze Verbindungsunterbrechung für laufende Clients (z. B. Monal) beim
|
|
Cutover ist zu erwarten; laut Nutzer unkritisch, da der Zeitpunkt frei
|
|
wählbar ist.
|
|
- Karenzzeit vor der endgültigen pinix-Stilllegung analog Forgejo ("ein paar
|
|
Tage bestätigter Stabilität auf blunix") ist einzuplanen, bevor das
|
|
pinix-Modul entfernt wird.
|
|
- Die Repo-seitigen Forgejo-Webhook-URLs (nicht Nix-verwaltet) müssen manuell
|
|
in der Forgejo-Weboberfläche für die betroffenen Repos umgestellt werden —
|
|
leicht zu vergessen, da es sich nicht in `nix flake check` zeigt.
|
|
|
|
## Erfolgskriterien
|
|
|
|
- Prosody läuft vollständig auf blunix; c2s, s2s, MUC und HTTP-Upload sind
|
|
funktional erreichbar.
|
|
- `chat.0ff.space` und `plaza.0ff.space` laufen von blunix aus, TLS wird über
|
|
Traefik/ACME bezogen statt über den manuellen Kopierprozess.
|
|
- Bestehende Accounts, Roster, MUC-Historie und Uploads sind nach dem Umzug
|
|
unverändert nutzbar.
|
|
- `wiki-update.sh` sendet Forgejo-Push-Benachrichtigungen erfolgreich von
|
|
blunix aus in `update@muc.${domain}`.
|
|
- Der `agent-xmpp-listener` auf blunix funktioniert nach der Migration
|
|
unterbrechungsfrei weiter.
|
|
- pinix-Prosody-/xmpp-web-/`wiki-update`-Module sind deaktiviert (nicht
|
|
aktiv), Daten und Module bleiben als Fallback liegen.
|