deploy/131-portal-einrichten.sh (als root auf 131): legt /etc/nexarch/web-portal.env an (Policy-Token wird nur zwischen Dateien kopiert), installiert die Unit aus der Vorlage, traegt Audience portal in account-api.env ein, ergaenzt den nginx-Block 8450 und CORS-Header fuer /auth/ und /account/ am Core (8443), oeffnet Port 8450 in /etc/nftables.conf, baut Portal und Login (mit NEXT_PUBLIC_PORTAL_URL) aus origin/main neu, startet account-api neu und prueft alles.
docs/BETRIEB-PORTAL.md: Abschnitt 131 verweist darauf und nennt die CORS-Luecke.
Auswirkung
Aendert auf 131: /etc/nexarch/{web-portal.env,account-api.env}, nginx (nexarch-gui, neue Dateien in /etc/nginx), /etc/nftables.conf, Unit nexarch-web-portal, Builds unter /opt/nexarch-web/{portal,account}. Jede geaenderte Datei wird vorher nach /root/portal-einrichten-<Zeit> gesichert; nginx und nft werden vor dem Laden geprueft und bei Fehler zurueckgenommen, Builds bei Fehler auf den alten .next zurueckgestellt.
Mit portal hat der Core zwei Audiences; Anfragen ohne ?module= werden dann abgelehnt. Auf 131 nutzt bisher kein Frontend eine Sitzung (geprueft).
account-api steht auf 131 weiterhin auf failed, solange das DB-Passwort nicht zur DSN passt (SQLSTATE 28P01). Das Skript startet neu und zeigt die Ursache, kann das Passwort aber nicht setzen.
Tests
bash -n; die nginx-Aenderung wurde an einem Auszug trocken geprueft. Das Skript selbst ist nicht auf 131 gelaufen (Betreiberaktion).
## Aenderung
- `deploy/131-portal-einrichten.sh` (als root auf 131): legt `/etc/nexarch/web-portal.env` an (Policy-Token wird nur zwischen Dateien kopiert), installiert die Unit aus der Vorlage, traegt Audience `portal` in `account-api.env` ein, ergaenzt den nginx-Block 8450 und CORS-Header fuer `/auth/` und `/account/` am Core (8443), oeffnet Port 8450 in `/etc/nftables.conf`, baut Portal und Login (mit `NEXT_PUBLIC_PORTAL_URL`) aus `origin/main` neu, startet `account-api` neu und prueft alles.
- `docs/BETRIEB-PORTAL.md`: Abschnitt 131 verweist darauf und nennt die CORS-Luecke.
## Auswirkung
- Aendert auf 131: `/etc/nexarch/{web-portal.env,account-api.env}`, nginx (`nexarch-gui`, neue Dateien in `/etc/nginx`), `/etc/nftables.conf`, Unit `nexarch-web-portal`, Builds unter `/opt/nexarch-web/{portal,account}`. Jede geaenderte Datei wird vorher nach `/root/portal-einrichten-<Zeit>` gesichert; nginx und nft werden vor dem Laden geprueft und bei Fehler zurueckgenommen, Builds bei Fehler auf den alten `.next` zurueckgestellt.
- Mit `portal` hat der Core zwei Audiences; Anfragen ohne `?module=` werden dann abgelehnt. Auf 131 nutzt bisher kein Frontend eine Sitzung (geprueft).
- `account-api` steht auf 131 weiterhin auf `failed`, solange das DB-Passwort nicht zur DSN passt (SQLSTATE 28P01). Das Skript startet neu und zeigt die Ursache, kann das Passwort aber nicht setzen.
## Tests
`bash -n`; die nginx-Aenderung wurde an einem Auszug trocken geprueft. Das Skript selbst ist nicht auf 131 gelaufen (Betreiberaktion).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Env-Datei, Unit, nginx-Block 8450, nft-Regel, Audience portal, CORS am Core
und Neubau von Portal und Login in einem idempotenten Lauf mit Sicherungen.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Auf 131 hat /opt/nexarch-web/portal/web/shl kein node_modules; der rsync
laesst node_modules aus. Typpruefung scheiterte mit TS2307 'react'.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Account auf 131 hat Next 14.2.35, die Quelle braucht 16.3.5 (--webpack
unbekannt). Abhaengigkeiten werden jetzt per Lockdatei-Hash erneuert,
shl/node_modules wird auf die der App verlinkt (eine React-Instanz).
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
patrick
merged commit 52a6a4bfd7 into main2026-10-29 11:17:24 +01:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Aenderung
deploy/131-portal-einrichten.sh(als root auf 131): legt/etc/nexarch/web-portal.envan (Policy-Token wird nur zwischen Dateien kopiert), installiert die Unit aus der Vorlage, traegt Audienceportalinaccount-api.envein, ergaenzt den nginx-Block 8450 und CORS-Header fuer/auth/und/account/am Core (8443), oeffnet Port 8450 in/etc/nftables.conf, baut Portal und Login (mitNEXT_PUBLIC_PORTAL_URL) ausorigin/mainneu, startetaccount-apineu und prueft alles.docs/BETRIEB-PORTAL.md: Abschnitt 131 verweist darauf und nennt die CORS-Luecke.Auswirkung
/etc/nexarch/{web-portal.env,account-api.env}, nginx (nexarch-gui, neue Dateien in/etc/nginx),/etc/nftables.conf, Unitnexarch-web-portal, Builds unter/opt/nexarch-web/{portal,account}. Jede geaenderte Datei wird vorher nach/root/portal-einrichten-<Zeit>gesichert; nginx und nft werden vor dem Laden geprueft und bei Fehler zurueckgenommen, Builds bei Fehler auf den alten.nextzurueckgestellt.portalhat der Core zwei Audiences; Anfragen ohne?module=werden dann abgelehnt. Auf 131 nutzt bisher kein Frontend eine Sitzung (geprueft).account-apisteht auf 131 weiterhin auffailed, solange das DB-Passwort nicht zur DSN passt (SQLSTATE 28P01). Das Skript startet neu und zeigt die Ursache, kann das Passwort aber nicht setzen.Tests
bash -n; die nginx-Aenderung wurde an einem Auszug trocken geprueft. Das Skript selbst ist nicht auf 131 gelaufen (Betreiberaktion).🤖 Generated with Claude Code