Merge branch 'phase/033-adresse-haerten'

Abmelden fuehrte im Docker-Betrieb auf 0.0.0.0:3000 - eine Adresse, die kein
Browser aufrufen kann. Ursache war hausgemacht: ENV HOSTNAME=0.0.0.0 aus
#031 reparierte die Zustandspruefung und lenkte zugleich alle Weiterleitungen
aus Server Actions dorthin, weil Next sie serverseitig absolut macht. Vorher
stand dort der Containername - derselbe Fehler, nur unauffaelliger.

Neuer Helfer eigenerPfad() baut die Adresse aus Einstellung, APP_URL oder den
Kopfzeilen der Anfrage. Betroffen waren Abmelden, die Sitzungspruefung und das
Loeschen eines Kunden. Zusaetzlich uebergeht oeffentlicheBasis() eine als
Lausch-Adresse eingetragene APP_URL, statt sie zu uebernehmen.

Gegen einen Docker-Stapel geprueft: Mit APP_URL=http://0.0.0.0:3000 leitet die
Anwendung jetzt auf den tatsaechlich aufgerufenen Namen.

Dazu #032: Das ct-Skript setzt die Herkunft der App-Skripte selbst, und die
Speichervorgabe steht auf 4 GB.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

CHANGELOG.md

@@ -17,6 +17,25 @@ und dieses Projekt folgt [Semantic Versioning](https://semver.org/lang/de/).
 
 ### Sicherheit
 
+## [0.20.1] – 2026-10-03
+
+### Behoben
+- **Abmelden führte auf `0.0.0.0:3000`** und damit ins Leere. Next.js macht Weiterleitungen aus Server Actions serverseitig absolut und nahm dafür die Lausch-Adresse des Servers. Betroffen waren Abmelden, die Sitzungsprüfung und das Löschen eines Kunden (#033)
+- Eine als Lausch-Adresse eingetragene `APP_URL` (`0.0.0.0`, `::`) wird jetzt übergangen statt übernommen (#033)
+- Die LXC-Installation brach mit *404 – Could not fetch install/proxledger-install.sh* ab: Ein per curl geladenes ct-Skript kennt seine Herkunft nicht und suchte bei den community-scripts (#032)
+
+### Geändert
+- Vorgabe für den Arbeitsspeicher des LXC von 2 auf 4 GB – `next build` scheitert sonst während der Installation am Speicher (#032)
+
+## [0.20.0] – 2026-10-03
+
+### Hinzugefügt
+- `deploy/update.sh` und `deploy/backup.sh` erkennen die Installationsart selbst und beherrschen jetzt auch die Installation als Dienst (Node und PostgreSQL direkt im Container) – nicht mehr nur Docker (#031)
+- Eine fehlgeschlagene Sicherung bricht die Aktualisierung ab, bevor etwas verändert wird (#031)
+
+### Behoben
+- Die Zustandsprüfung des Web-Containers konnte nie gelingen: Next bindet im Standalone-Modus an die Adresse aus `HOSTNAME`, und Docker setzt dort den Containernamen – der Server lauschte nur auf der Container-IP. `web` blieb dauerhaft auf „health: starting“ (#031)
+
 ## [0.19.2] – 2026-10-03
 
 ### Sicherheit

DEVLOG.md

@@ -2,7 +2,7 @@
 
 ## Zeitübersicht
 
-**Gesamt:** 15 h 23 min
+**Gesamt:** 16 h 58 min
 
 | Issue | Zeit |
 |---|---|
@@ -36,6 +36,9 @@
 | #028 Passkeys | 0 h 45 min |
 | #029 Einrichtungsdokumentation | 0 h 40 min |
 | #030 netbird Reverse Proxy | 0 h 20 min |
+| #031 Update für beide Varianten | 0 h 45 min |
+| #032 LXC-Installation korrigiert | 0 h 20 min |
+| #033 Weiterleitung auf Lausch-Adresse | 0 h 30 min |
 
 | Meilenstein | Zeit |
 |---|---|
@@ -58,7 +61,7 @@
 
 ## 2026-09-17 · Sitzung 1 · 19:36–laufend
 **Issue:** #001–#007 (Meilensteine v0.1.0 bis v0.4.0)
-**Version:** 0.19.2
+**Version:** 0.20.1
 
 ### Erledigt
 - Auftrag gelesen, Rückfragen gestellt
@@ -169,6 +172,13 @@
 - `npm audit` vor der Freigabe erneut laufen lassen: In den zwei Wochen seit dem letzten Stand kam eine kritische Meldung zu Next.js dazu (RCE in `next/og`). Wir nutzen `next/og` nicht, waren also nicht angreifbar – angehoben auf 16.3.8, Tests und Build grün
 - Lehre für den Betrieb: Vor jedem Produktivgang und danach regelmäßig `npm audit` prüfen, nicht nur bei Änderungen am Code
 
+- Update- und Sicherungsskript für beide Installationsarten (#031). Beim Durchspielen zwei Fehler gefunden: Die Zustandsprüfung des Web-Containers konnte nie gelingen (Next bindet an `HOSTNAME`, Docker setzt dort den Containernamen), und eine fehlgeschlagene Sicherung hielt die Aktualisierung nicht auf
+- Lehre: Ein Skript, das nie unter echten Bedingungen gelaufen ist, ist eine Behauptung. Erst der Durchlauf gegen einen laufenden Stapel hat beide Fehler gezeigt
+
+- Erster echter Einsatz durch Florian – und prompt zwei Fehler, die kein Test gezeigt hatte (#032, #033)
+- #033 war hausgemacht: Mein `HOSTNAME=0.0.0.0` aus #031 hat den Healthcheck repariert und dafür alle Weiterleitungen aus Server Actions auf `0.0.0.0` gelenkt. Vorher stand dort der Containername – derselbe Fehler, nur unauffälliger
+- Lehre: Weiterleitungen gehören aus der konfigurierten Adresse gebaut, nie aus dem, was der Server über sich selbst weiß
+
 ### Nächster Schritt
 - #016 Benutzerhandbuch mit Screenshots, danach #017 Favicons und #019 CI-Pipeline
 - Für 1.0.0 fehlt noch: PMG (kein Host verfügbar) und der Fall „aktive Subscription auf PBS“ (#023)

Dockerfile

@@ -24,6 +24,9 @@ RUN npx prisma generate \
 FROM basis AS laufzeit
 ENV NODE_ENV=production
 ENV PORT=3000
+# Ohne diese Zeile nimmt Next den von Docker gesetzten HOSTNAME als Bindeadresse und lauscht
+# nur auf der Container-IP. Die Zustandsprüfung über 127.0.0.1 schlägt dann immer fehl.
+ENV HOSTNAME=0.0.0.0
 
 RUN addgroup -g 1001 -S proxledger && adduser -S proxledger -u 1001 -G proxledger
 

deploy/backup.sh

@@ -1,5 +1,6 @@
 #!/usr/bin/env bash
-# Sichert Datenbank und hochgeladene PDFs von ProxLedger.
+# Sichert Datenbank, hochgeladene PDFs und die Konfiguration von ProxLedger.
+# Erkennt selbst, ob die Installation mit Docker oder als Dienst im Container läuft.
 #
 #   ./backup.sh /pfad/zum/sicherungsordner
 #
@@ -13,17 +14,50 @@ set -o pipefail
 ZIEL="${1:-/var/backups/proxledger}"
 AUFBEWAHRUNG_TAGE="${AUFBEWAHRUNG_TAGE:-30}"
 STAND=$(date +%Y%m%d-%H%M%S)
-COMPOSE_VERZEICHNIS="${COMPOSE_VERZEICHNIS:-/opt/proxledger}"
+VERZEICHNIS="${COMPOSE_VERZEICHNIS:-$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)}"
 
 mkdir -p "$ZIEL"
-cd "$COMPOSE_VERZEICHNIS"
+cd "$VERZEICHNIS"
 
+# Siehe deploy/update.sh – der Dienst ist das eindeutigere Merkmal.
+if systemctl cat proxledger.service >/dev/null 2>&1; then
+  ART="dienst"
+else
+  ART="docker"
+fi
+
+echo "Sichere ProxLedger (${ART}) nach ${ZIEL} …"
+
+if [ "$ART" = "docker" ]; then
   echo "Sichere Datenbank …"
   docker compose exec -T postgres pg_dump -U "${POSTGRES_USER:-proxledger}" "${POSTGRES_DB:-proxledger}" \
     | gzip > "${ZIEL}/datenbank-${STAND}.sql.gz"
 
   echo "Sichere hochgeladene Dateien …"
   docker compose run --rm -T --entrypoint tar web -czf - /data/uploads > "${ZIEL}/uploads-${STAND}.tar.gz" 2>/dev/null || true
+else
+  # DATABASE_URL steht in der .env; pg_dump versteht sie direkt.
+  # shellcheck disable=SC1091
+  set -o allexport
+  . ./.env
+  set +o allexport
+
+  [ -n "${DATABASE_URL:-}" ] || {
+    echo "DATABASE_URL fehlt in der .env – ohne sie keine Sicherung." >&2
+    exit 1
+  }
+
+  echo "Sichere Datenbank …"
+  pg_dump "$DATABASE_URL" | gzip > "${ZIEL}/datenbank-${STAND}.sql.gz"
+
+  echo "Sichere hochgeladene Dateien …"
+  UPLOADS="${UPLOAD_DIR:-${VERZEICHNIS}/data/uploads}"
+  if [ -d "$UPLOADS" ]; then
+    tar -czf "${ZIEL}/uploads-${STAND}.tar.gz" -C "$(dirname "$UPLOADS")" "$(basename "$UPLOADS")"
+  else
+    echo "  (kein Upload-Verzeichnis unter ${UPLOADS})"
+  fi
+fi
 
 echo "Sichere Konfiguration …"
 cp .env "${ZIEL}/env-${STAND}.txt"

deploy/community-scripts/README.md

@@ -6,6 +6,10 @@ installieren Node.js 24 und PostgreSQL 17, holen ProxLedger aus dem Git-Reposito
 systemd-Dienste ein (Dashboard und Worker) und schreiben die erzeugten Zugangsdaten nach
 `/opt/proxledger/.credentials`.
 
+**Ressourcen:** Die Vorgabe ist 2 CPU-Kerne, **4 GB RAM** und 12 GB Platte. Die 4 GB braucht
+`next build` während der Installation; im Betrieb genügen 2 GB, die sich im Nachhinein in Proxmox
+wieder absenken lassen.
+
 | Datei | Zweck |
 |---|---|
 | `ct/proxledger.sh` | Container anlegen, Ressourcen abfragen, Aktualisierung (`update_script`) |
@@ -19,8 +23,26 @@ Auf dem Proxmox-VE-Host als root:
 bash -c "$(curl -fsSL https://git.wilde-server.de/florian.wilde/ProxLedger/raw/branch/main/deploy/community-scripts/ct/proxledger.sh)"
 ```
 
-Das Gerüst (`build.func`, `install.func`) lädt das Skript von den community-scripts nach – das ist
+Das Gerüst (`build.func`) lädt das Skript von den community-scripts nach – das ist öffentlich und ohne
-öffentlich und ohne Konto erreichbar. Nur ProxLedger selbst kommt aus dem eigenen Git.
+Konto erreichbar. Nur ProxLedger selbst kommt aus dem eigenen Git.
+
+**Wichtig:** Ein per `curl` geladenes ct-Skript kann seine eigene Herkunft nicht ermitteln. Ohne
+Angabe sucht das Gerüst `install/proxledger-install.sh` bei den community-scripts auf GitHub und
+bricht mit *404 – Could not fetch install/proxledger-install.sh* ab. Das ct-Skript setzt deshalb
+
+```bash
+COMMUNITY_SCRIPTS_URL="https://git.wilde-server.de/florian.wilde/ProxLedger/raw/branch/main/deploy/community-scripts"
+```
+
+selbst. Für einen anderen Zweig oder einen Fork lässt sich die Angabe von außen überschreiben:
+
+```bash
+COMMUNITY_SCRIPTS_URL=https://git.example.de/<nutzer>/ProxLedger/raw/branch/<zweig>/deploy/community-scripts \
+  bash -c "$(curl -fsSL …/ct/proxledger.sh)"
+```
+
+Das Verzeichnis dahinter muss `ct/` und `install/` enthalten – deshalb zeigt die Angabe auf
+`deploy/community-scripts`, nicht auf die Wurzel des Repositorys.
 
 Zwei Umgebungsvariablen steuern die Quelle, solange das Repository nicht öffentlich ist:
 

deploy/community-scripts/ct/proxledger.sh

@@ -1,5 +1,10 @@
 #!/usr/bin/env bash
-_CS_DEFAULT_URL="https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main"
+# Woher die App-Skripte kommen. Ein per curl geladenes ct-Skript kann seine eigene Herkunft nicht
+# ermitteln – ohne diese Angabe sucht das Geruest install/proxledger-install.sh bei den
+# community-scripts und bricht mit 404 ab. Ueberschreibbar fuer eigene Zweige oder Forks.
+COMMUNITY_SCRIPTS_URL="${COMMUNITY_SCRIPTS_URL:-https://git.wilde-server.de/florian.wilde/ProxLedger/raw/branch/main/deploy/community-scripts}"
+export COMMUNITY_SCRIPTS_URL
+_CS_DEFAULT_URL="$COMMUNITY_SCRIPTS_URL"
 _cs_boot="${COMMUNITY_SCRIPTS_CORE_DIR:-$(dirname "${BASH_SOURCE[0]}")/../../core}/core/build.func"
 source "$_cs_boot" 2>/dev/null || source <(curl -fsSL "${COMMUNITY_SCRIPTS_CORE_URL:-https://raw.githubusercontent.com/community-scripts/core/main}/core/build.func")
 # Copyright (c) 2021-2026 tteck
@@ -10,8 +15,10 @@ source "$_cs_boot" 2>/dev/null || source <(curl -fsSL "${COMMUNITY_SCRIPTS_CORE_
 APP="ProxLedger"
 var_tags="${var_tags:-monitoring;licensing}"
 var_cpu="${var_cpu:-2}"
-var_ram="${var_ram:-2048}"
+# 4 GB fuer die Installation: `next build` braucht deutlich mehr als 2 GB und bricht sonst mit
-var_disk="${var_disk:-10}"
+# einem Speicherfehler ab. Nach der Installation genuegen 2 GB im Betrieb.
+var_ram="${var_ram:-4096}"
+var_disk="${var_disk:-12}"
 var_os="${var_os:-debian}"
 var_version="${var_version:-13}"
 var_arm64="${var_arm64:-yes}"

deploy/community-scripts/install/proxledger-install.sh

@@ -40,7 +40,13 @@ msg_info "Setting up ProxLedger"
 $STD git clone --branch "$ZWEIG" --depth 1 "$QUELLE" /opt/proxledger
 cd /opt/proxledger
 
-IP_ADRESSE=$(hostname -I | awk '{print $1}')
+# Erreichbare Adresse des Containers ermitteln. `hostname -I` liefert sie in aller Regel;
+# notfalls hilft die Route nach draussen. 0.0.0.0 waere eine Lausch-Adresse und im Browser nutzlos.
+IP_ADRESSE=$(hostname -I 2>/dev/null | awk '{print $1}')
+if [ -z "$IP_ADRESSE" ] || [ "$IP_ADRESSE" = "0.0.0.0" ]; then
+  IP_ADRESSE=$(ip route get 1.1.1.1 2>/dev/null | awk '/src/ {print $7; exit}')
+fi
+[ -n "$IP_ADRESSE" ] || IP_ADRESSE="localhost"
 cat <<EOF >/opt/proxledger/.env
 DATABASE_URL="postgresql://${DB_USER}:${DB_PASS}@localhost:5432/${DB_NAME}?schema=public"
 APP_SECRET="${APP_SECRET}"
@@ -107,6 +113,8 @@ msg_ok "Created Services"
 {
   echo "ProxLedger"
   echo "Adresse:     http://${IP_ADRESSE}:3000"
+  echo "             (Im Journal steht 0.0.0.0:3000 - das ist nur die Lausch-Adresse,"
+  echo "              im Browser gehoert die obige IP oder der spaetere DNS-Name hinein.)"
   echo "Benutzer:    admin@proxledger.local"
   echo "Passwort:    ${ADMIN_PASS}"
   echo

deploy/lxc-installer.sh

@@ -181,4 +181,5 @@ printf '  3. Für den Betrieb über HTTPS einen Reverse Proxy davorsetzen (Beisp
 echo
 gelb "APP_URL in /opt/proxledger/.env auf die endgültige Adresse setzen, sobald der Reverse Proxy steht."
 printf '  Logs ansehen:   pct exec %s -- docker compose -f /opt/proxledger/docker-compose.yml logs -f\n' "$CTID"
-printf '  Aktualisieren:  pct exec %s -- bash -c "cd /opt/proxledger && git pull && docker compose up -d --build"\n' "$CTID"
+printf '  Aktualisieren:  pct exec %s -- bash -c "bash /opt/proxledger/deploy/update.sh"\n' "$CTID"
+printf '  Sichern:        pct exec %s -- bash -c "bash /opt/proxledger/deploy/backup.sh /var/backups/proxledger"\n' "$CTID"

deploy/update.sh

@@ -1,7 +1,8 @@
 #!/usr/bin/env bash
-# ProxLedger aktualisieren (Docker-Installation).
+# ProxLedger aktualisieren – erkennt selbst, ob die Installation mit Docker
+# oder als Dienst im Container (Node + PostgreSQL direkt) läuft.
 #
-#   bash deploy/update.sh            # Quelltext holen, neu bauen, migrieren, neu starten
+#   bash deploy/update.sh                 # sichern, holen, bauen, migrieren, neu starten
 #   bash deploy/update.sh --ohne-sicherung
 #
 # Vor dem Aktualisieren wird gesichert – das dauert Sekunden und erspart schlechte Abende.
@@ -23,20 +24,53 @@ fehler() {
 SICHERN="ja"
 [ "${1:-}" = "--ohne-sicherung" ] && SICHERN="nein"
 
-command -v docker >/dev/null 2>&1 || fehler "Docker nicht gefunden."
+# Wohin gesichert wird. Der Standardort gehört root; wer anders arbeitet, setzt SICHERUNG_ZIEL.
-[ -f .env ] || fehler "Keine .env gefunden – wird dieses Skript im richtigen Verzeichnis ausgeführt?"
+SICHERUNG_ZIEL="${SICHERUNG_ZIEL:-/var/backups/proxledger}"
 
+# ---------------------------------------------------------------- Art der Installation
+#
+# Der systemd-Dienst ist das eindeutigere Merkmal: Die docker-compose.yml liegt auch im
+# Quelltext der Dienst-Installation, ein Dienst namens proxledger aber nur dort.
+installationsart() {
+  if systemctl cat proxledger.service >/dev/null 2>&1; then
+    printf 'dienst'
+  elif command -v docker >/dev/null 2>&1 && [ -f docker-compose.yml ]; then
+    printf 'docker'
+  fi
+}
+
+ART=$(installationsart)
+[ -n "$ART" ] || fehler "Keine Installation gefunden – weder der Dienst proxledger noch Docker mit docker-compose.yml."
+
+blau "Installationsart: ${ART}"
+
+# ---------------------------------------------------------------- Sicherung
 if [ "$SICHERN" = "ja" ]; then
-  blau "Sicherung anlegen …"
+  blau "Sicherung anlegen nach ${SICHERUNG_ZIEL} …"
-  bash deploy/backup.sh
+  if ! bash deploy/backup.sh "$SICHERUNG_ZIEL"; then
+    fehler "Die Sicherung ist fehlgeschlagen – deshalb wird nicht aktualisiert.
+  Häufigste Ursache: fehlende Rechte am Zielordner. Mögliche Wege:
+    sudo bash deploy/update.sh
+    SICHERUNG_ZIEL=/pfad/mit/rechten bash deploy/update.sh
+    bash deploy/update.sh --ohne-sicherung   (nur wenn anderweitig gesichert ist)"
+  fi
   gruen "Sicherung abgeschlossen."
+else
+  printf '\033[1;33m! Ohne Sicherung – auf eigenes Risiko.\033[0m\n'
 fi
 
+# ---------------------------------------------------------------- Quelltext
 if [ -d .git ]; then
   blau "Neuen Stand holen …"
   git pull --ff-only
+else
+  printf '\033[1;33m! Kein Git-Verzeichnis – der Quelltext bleibt wie er ist.\033[0m\n'
 fi
 
+# ---------------------------------------------------------------- Aktualisieren
+if [ "$ART" = "docker" ]; then
+  [ -f .env ] || fehler "Keine .env gefunden – wird dieses Skript im richtigen Verzeichnis ausgeführt?"
+
   blau "Abbilder neu bauen …"
   docker compose build --pull
 
@@ -45,16 +79,50 @@ docker compose run --rm migrate
 
   blau "Dienste neu starten …"
   docker compose up -d
+else
+  command -v npm >/dev/null 2>&1 || fehler "npm nicht gefunden – gehört zur Installation als Dienst."
+  [ -f .env ] || fehler "Keine .env gefunden (erwartet in ${VERZEICHNIS})."
 
-# Kurz warten und nachsehen, ob das Dashboard wieder antwortet.
+  # Die .env trägt APP_SECRET; ein git pull fasst sie nicht an, aber sicher ist sicher.
+  cp .env "/tmp/proxledger-env-$(date +%s).sicherung"
+
+  blau "Abhängigkeiten installieren …"
+  npm ci
+
+  blau "Datenbank migrieren …"
+  npx prisma generate
+  npx prisma migrate deploy
+
+  blau "Anwendung bauen …"
+  npm run build
+  npm run build:worker
+
+  blau "Dienste neu starten …"
+  systemctl restart proxledger proxledger-worker
+fi
+
+# ---------------------------------------------------------------- Prüfen
 blau "Warte auf das Dashboard …"
-for versuch in $(seq 1 30); do
+PORT="${PORT:-3000}"
-  if docker compose exec -T web wget -qO- http://localhost:3000/api/gesundheit >/dev/null 2>&1; then
+
+for versuch in $(seq 1 45); do
+  if [ "$ART" = "docker" ]; then
+    erreichbar=$(docker compose exec -T web wget -qO- "http://127.0.0.1:3000/api/gesundheit" >/dev/null 2>&1 && echo ja || echo nein)
+  else
+    erreichbar=$(curl -fsS -o /dev/null --max-time 2 "http://localhost:${PORT}/api/gesundheit" && echo ja || echo nein)
+  fi
+
+  if [ "$erreichbar" = "ja" ]; then
     gruen "ProxLedger läuft wieder (nach ${versuch} s)."
-    docker compose ps
+    [ "$ART" = "docker" ] && docker compose ps
+    [ "$ART" = "dienst" ] && systemctl --no-pager --lines=0 status proxledger proxledger-worker | grep -E "●|Active:"
     exit 0
   fi
   sleep 1
 done
 
+if [ "$ART" = "docker" ]; then
   fehler "Das Dashboard antwortet nicht. Protokoll ansehen: docker compose logs -n 50 web"
+else
+  fehler "Das Dashboard antwortet nicht. Protokoll ansehen: journalctl -u proxledger -n 50"
+fi

docker-compose.yml

@@ -60,7 +60,7 @@ services:
     volumes:
       - uploads:/data
     healthcheck:
-      test: ["CMD", "wget", "-qO-", "http://localhost:3000/api/gesundheit"]
+      test: ["CMD", "wget", "-qO-", "http://127.0.0.1:3000/api/gesundheit"]
       interval: 30s
       timeout: 5s
       retries: 5

docs/anleitung/README.md

@@ -396,31 +396,46 @@ Rückweg immer nutzbar.
 **Sichern:**
 
 ```bash
-./deploy/backup.sh /var/backups/proxledger
+bash /opt/proxledger/deploy/backup.sh /var/backups/proxledger
 ```
 
-Das Skript sichert Datenbank, hochgeladene PDFs und die `.env`. Für regelmäßige Sicherungen in die
+Das Skript sichert Datenbank, hochgeladene PDFs und die `.env` – und erkennt selbst, ob die
-Crontab eintragen:
+Installation mit Docker oder als Dienst im Container läuft. Für regelmäßige Sicherungen in die Crontab:
 
 ```
 30 2 * * * /opt/proxledger/deploy/backup.sh /var/backups/proxledger
 ```
 
-**Zurückspielen:**
+**Zurückspielen** (Docker):
 
 ```bash
 gunzip -c datenbank-20260917-023000.sql.gz | docker compose exec -T postgres psql -U proxledger proxledger
 ```
 
+Bei der Installation als Dienst stattdessen:
+
+```bash
+gunzip -c datenbank-20260917-023000.sql.gz | psql "$DATABASE_URL"
+```
+
 **Aktualisieren:**
 
 ```bash
-cd /opt/proxledger
+bash /opt/proxledger/deploy/update.sh
-git pull
-docker compose up -d --build
 ```
 
-Migrationen laufen dabei automatisch.
+Ein Befehl für beide Installationsarten. Der Reihe nach: sichern, neuen Stand holen, bauen,
+migrieren, neu starten – und zum Schluss prüfen, ob das Dashboard wieder antwortet. Schlägt die
+Sicherung fehl, bricht das Skript ab, **bevor** etwas verändert wird.
+
+| Aufruf | Wirkung |
+|---|---|
+| `bash deploy/update.sh` | der übliche Weg |
+| `SICHERUNG_ZIEL=/pfad bash deploy/update.sh` | anderer Ort für die Sicherung |
+| `bash deploy/update.sh --ohne-sicherung` | nur, wenn anderweitig gesichert ist |
+
+Beim LXC-Weg nach Art der Helper-Scripts geht es auch über das Skript auf dem Proxmox-Host – dort
+erkennt das Gerüst eine vorhandene Installation und bietet die Aktualisierung an.
 
 > `APP_SECRET` unbedingt mitsichern: Ohne diesen Wert sind alle Sitzungen ungültig. Und beachte, dass eine
 > Sicherung die Zugangsdaten für SMTP und Webhook im Klartext enthält – sie gehört entsprechend geschützt.

docs/betrieb/sicherung.md

@@ -14,10 +14,15 @@ Maschinenkennung, nicht an einem Token.
 ## Sichern
 
 ```bash
-bash deploy/backup.sh          # Datenbank und Uploads
+bash deploy/backup.sh /var/backups/proxledger
 ```
 
-Beim LXC-Weg reicht zusätzlich die gewohnte Proxmox-Sicherung des Containers.
+Das Skript erkennt selbst, ob die Installation mit Docker oder als Dienst läuft, und sichert in beiden
+Fällen Datenbank, Uploads und `.env`. Beim LXC-Weg reicht zusätzlich die gewohnte Proxmox-Sicherung
+des Containers.
+
+Vor jeder Aktualisierung läuft es ohnehin automatisch – [`deploy/update.sh`](../../deploy/update.sh)
+ruft es als Erstes auf und bricht ab, wenn es fehlschlägt.
 
 ## Zurückspielen
 

docs/issues/031-update-skript-beide-varianten.md

@@ -0,0 +1,33 @@
+# #031 Update- und Sicherungsskript für beide Installationsarten
+**Status:** erledigt
+**Meilenstein:** v0.20.0
+**Labels:** deployment
+**Geschätzt:** 2 h   **Tatsächlich:** 0 h 45 min
+
+## Ziel
+`deploy/update.sh` und `deploy/backup.sh` konnten nur Docker. Die Installation als Dienst (Node und
+PostgreSQL direkt im LXC) ging leer aus – dort half nur der Weg über das Gerüst der community-scripts.
+
+## Aufgaben
+- [x] Beide Skripte erkennen die Installationsart selbst (systemd-Dienst oder Docker)
+- [x] Dienst-Weg: `npm ci`, `prisma migrate deploy`, bauen, `systemctl restart`
+- [x] Sicherung für den Dienst-Weg: `pg_dump` über `DATABASE_URL`, Uploads aus `UPLOAD_DIR`
+- [x] Fehlgeschlagene Sicherung bricht die Aktualisierung ab – **vor** jeder Änderung
+- [x] Hinweis am Ende von `deploy/lxc-installer.sh` auf die Skripte umgestellt
+- [x] Handbuch und Betriebsdoku angepasst
+- [x] Docker-Weg vollständig durchgespielt
+
+## Zwei Fehler beim Durchspielen gefunden
+1. **Die Zustandsprüfung des Web-Containers konnte nie gelingen.** Next bindet im Standalone-Modus an
+   die Adresse aus `HOSTNAME` – und Docker setzt darin den Containernamen. Der Server lauschte also
+   nur auf der Container-IP, nicht auf `127.0.0.1`. Der Dienst `web` blieb dauerhaft auf
+   „health: starting“; von außen war er trotzdem erreichbar, deshalb fiel es bisher nicht auf.
+   Behoben mit `ENV HOSTNAME=0.0.0.0` im Dockerfile; die Prüfungen verwenden jetzt `127.0.0.1`
+   statt `localhost` (das löst im Container auch auf `::1` auf).
+2. **Die Sicherung scheiterte stumm an fehlenden Rechten** (`/var/backups` gehört root) und die
+   Aktualisierung lief trotzdem weiter. Jetzt bricht sie ab und nennt die drei Auswege.
+
+## Prüfung
+Vollständiger Durchlauf gegen einen laufenden Stapel: Sicherung (Datenbank 6,3 KB mit 25 Tabellen,
+Uploads, `.env`), Abbilder gebaut, migriert, neu gestartet, Dashboard nach zwei Sekunden wieder da.
+Danach stand `web` zum ersten Mal auf **healthy**.

docs/issues/032-lxc-installation-korrekturen.md

@@ -0,0 +1,27 @@
+# #032 LXC-Installation: Herkunft der Skripte und Speicher
+**Status:** erledigt
+**Meilenstein:** v0.20.1
+**Labels:** deployment
+**Geschätzt:** 1 h   **Tatsächlich:** 0 h 20 min
+
+## Auslöser
+Erster echter Lauf auf `hv-rz5-pve-02`: Der Container entstand, dann brach es ab mit
+
+```
+curl: (22) The requested URL returned error: 404
+✖️  Could not fetch install/proxledger-install.sh
+📁  Looked in: https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main
+```
+
+## Ursache
+Ein per `curl` geladenes ct-Skript kann seine eigene Herkunft nicht ermitteln. Das Gerüst setzt dann
+die Standardadresse der community-scripts ein und sucht dort `install/proxledger-install.sh`.
+
+## Behebung
+- Das ct-Skript setzt `COMMUNITY_SCRIPTS_URL` selbst auf die eigene Gitea-Adresse (für Forks und
+  andere Zweige weiterhin überschreibbar).
+- Vorgabe für den Arbeitsspeicher von 2 auf **4 GB** angehoben: `next build` braucht während der
+  Installation deutlich mehr als 2 GB und wäre nach zehn Minuten am Speicher gescheitert.
+- Die ermittelte Adresse wird geprüft; `hostname -I` ohne Ergebnis fällt auf die Route nach außen
+  zurück, und in den Zugangsdaten steht der Hinweis, dass `0.0.0.0` aus dem Journal keine
+  aufrufbare Adresse ist.

docs/issues/033-weiterleitung-lauschadresse.md

@@ -0,0 +1,35 @@
+# #033 Abmelden führte auf die Lausch-Adresse
+**Status:** erledigt
+**Meilenstein:** v0.20.1
+**Labels:** bug, deployment
+**Geschätzt:** 1 h   **Tatsächlich:** 0 h 30 min
+
+## Auslöser
+Im Docker-Betrieb führte **Abmelden** auf `0.0.0.0:3000/login` – eine Adresse, die kein Browser
+aufrufen kann (`ERR_ADDRESS_INVALID`).
+
+## Ursache
+Hausgemacht, und zwar in #031: Für die Zustandsprüfung des Containers wurde `ENV HOSTNAME=0.0.0.0`
+gesetzt, damit der Server auf allen Schnittstellen lauscht. Next.js macht eine Weiterleitung aus
+einer Server Action aber **serverseitig absolut** und nimmt dafür genau diese Adresse. Vorher stand
+dort der Containername (`http://0a5963a591df:3000/`) – derselbe Fehler, nur weniger auffällig.
+
+Betroffen waren alle Weiterleitungen, die nicht über eine `Request` liefen: Abmelden, die Prüfung in
+`sitzungErforderlich` und das Löschen eines Kunden.
+
+## Behebung
+- Neuer Helfer `eigenerPfad()` in `src/lib/adresse.ts`: baut die Adresse aus Einstellung, `APP_URL`
+  oder den Kopfzeilen der Anfrage – nie aus der Lausch-Adresse.
+- `oeffentlicheBasis()` übergeht unbrauchbare Angaben (`0.0.0.0`, `::`) jetzt ausdrücklich, statt sie
+  zu übernehmen. Eine falsch eingetragene Adresse macht das Dashboard damit nicht unbenutzbar.
+- Zwei zusätzliche Tests.
+
+## Prüfung
+Gegen einen Docker-Stapel durchgespielt: Mit `APP_URL=http://0.0.0.0:3000` in der `.env` – also der
+Fehlkonfiguration – leitet die Anwendung jetzt auf den tatsächlich aufgerufenen Namen
+(`http://localhost:3003/login`) statt auf die Lausch-Adresse.
+
+## Lehre
+Der Fix für die Zustandsprüfung hat einen zweiten Fehler sichtbar gemacht, der vorher nur anders
+aussah. Weiterleitungen gehören grundsätzlich aus der **konfigurierten** Adresse gebaut, nicht aus
+dem, was der Server zufällig über sich selbst weiß.

docs/issues/README.md

@@ -34,4 +34,7 @@ Details und Architektur: [../architektur.md](../architektur.md). Zeiten werden a
 | [#028](028-passkeys.md) | Anmeldung mit Passkeys | erledigt | v0.18.0 | 4 h | 0 h 45 min |
 | [#029](029-betriebsdokumentation.md) | Einrichtungsdokumentation | erledigt | v0.19.0 | 3 h | 0 h 40 min |
 | [#030](030-netbird-reverse-proxy.md) | netbird Reverse Proxy in die Anleitung | erledigt | v0.19.1 | 1 h | 0 h 20 min |
-| | **Summe** | | | **147 h** | **15 h 23 min** |
+| [#031](031-update-skript-beide-varianten.md) | Update- und Sicherungsskript für beide Varianten | erledigt | v0.20.0 | 2 h | 0 h 45 min |
+| [#032](032-lxc-installation-korrekturen.md) | LXC-Installation: Herkunft der Skripte und Speicher | erledigt | v0.20.1 | 1 h | 0 h 20 min |
+| [#033](033-weiterleitung-lauschadresse.md) | Abmelden führte auf die Lausch-Adresse | erledigt | v0.20.1 | 1 h | 0 h 30 min |
+| | **Summe** | | | **151 h** | **16 h 58 min** |

package.json

@@ -1,6 +1,6 @@
 {
   "name": "proxledger",
-  "version": "0.19.2",
+  "version": "0.20.1",
   "private": true,
   "scripts": {
     "dev": "next dev",

src/lib/adresse.ts

@@ -9,31 +9,34 @@
  * sich fälschen; für eine Weiterleitung auf die eigene Seite ist das unkritisch, als erste Wahl aber
  * unnötig.
  */
-export function oeffentlicheBasis(request: Request, eingetragen?: string): URL {
+/**
-  if (eingetragen) {
+ * Lausch-Adressen taugen nicht als Ziel für einen Browser: `0.0.0.0` heißt „alle Schnittstellen“.
+ * Steht so etwas in der Konfiguration, wird es übergangen statt eine unerreichbare Seite zu bauen.
+ */
+const UNBRAUCHBAR = new Set(["0.0.0.0", "::", "[::]", "", "0"]);
+
+function brauchbar(adresse: string | undefined): URL | null {
+  if (!adresse) return null;
   try {
-      return new URL(eingetragen);
+    const ergebnis = new URL(adresse);
+    return UNBRAUCHBAR.has(ergebnis.hostname) ? null : ergebnis;
   } catch {
-      // Unbrauchbarer Eintrag: weiter mit den übrigen Quellen.
+    return null;
   }
 }
 
-  if (process.env.APP_URL) {
+export function oeffentlicheBasis(request: Request, eingetragen?: string): URL {
-    try {
+  const ausEinstellung = brauchbar(eingetragen);
-      return new URL(process.env.APP_URL);
+  if (ausEinstellung) return ausEinstellung;
-    } catch {
+
-      // ebenso
+  const ausUmgebung = brauchbar(process.env.APP_URL);
-    }
+  if (ausUmgebung) return ausUmgebung;
-  }
 
   const gastgeber = request.headers.get("x-forwarded-host") ?? request.headers.get("host");
   if (gastgeber) {
     const schema = request.headers.get("x-forwarded-proto") ?? new URL(request.url).protocol.replace(":", "");
-    try {
+    const ausKopfzeile = brauchbar(`${schema}://${gastgeber}`);
-      return new URL(`${schema}://${gastgeber}`);
+    if (ausKopfzeile) return ausKopfzeile;
-    } catch {
-      // ebenso
-    }
   }
 
   return new URL(request.url);
@@ -43,3 +46,19 @@ export function oeffentlicheBasis(request: Request, eingetragen?: string): URL {
 export function eigeneAdresse(request: Request, pfad: string, eingetragen?: string): URL {
   return new URL(pfad, oeffentlicheBasis(request, eingetragen));
 }
+
+/**
+ * Dasselbe für Server Actions und Seiten, die keine `Request` zur Hand haben.
+ *
+ * Nötig, weil Next.js eine Weiterleitung aus einer Server Action serverseitig absolut macht – und
+ * dafür die Adresse nimmt, auf die der Server lauscht. Im Container ist das `0.0.0.0` (oder der
+ * Containername); im Browser landet man damit auf einer Seite, die es nicht gibt.
+ */
+export async function eigenerPfad(pfad: string, eingetragen?: string): Promise<string> {
+  const { headers } = await import("next/headers");
+  const kopfzeilen = await headers();
+
+  // Die Anfrage selbst gibt es hier nicht; eine leere mit den echten Kopfzeilen genügt.
+  const basis = oeffentlicheBasis(new Request("http://platzhalter.invalid", { headers: kopfzeilen }), eingetragen);
+  return new URL(pfad, basis).toString();
+}

src/server/actions/auth.ts

@@ -2,12 +2,16 @@
 
 import { cookies } from "next/headers";
 import { redirect } from "next/navigation";
+import { eigenerPfad } from "@/lib/adresse";
 import { SITZUNGS_COOKIE } from "@/lib/sitzung";
 import { protokolliere } from "@/server/audit";
+import { einstellungen } from "@/server/einstellungen";
 
 /** Abmelden aus dem Benutzermenü. Die Anmeldung selbst läuft über /api/auth/anmelden. */
 export async function abmelden() {
   (await cookies()).delete(SITZUNGS_COOKIE);
   await protokolliere("abmeldung", "Benutzer", null, {});
-  redirect("/login");
+
+  const { dashboardUrl } = await einstellungen();
+  redirect(await eigenerPfad("/login", dashboardUrl));
 }

src/server/actions/kunden.ts

@@ -6,6 +6,7 @@ import { z } from "zod";
 import { prisma } from "@/lib/db";
 import { protokolliere } from "@/server/audit";
 import { sitzungErforderlich } from "@/server/auth/sitzungspflicht";
+import { eigenerPfad } from "@/lib/adresse";
 
 export interface AktionsErgebnis {
   fehler?: string;
@@ -79,7 +80,7 @@ export async function kundeLoeschen(formular: FormData) {
 
   revalidatePath("/kunden");
   revalidatePath("/hosts/nicht-zugeordnet");
-  redirect("/kunden");
+  redirect(await eigenerPfad("/kunden"));
 }
 
 const standortSchema = z.object({

src/server/auth/sitzungspflicht.ts

@@ -2,6 +2,7 @@ import { cookies } from "next/headers";
 import { redirect } from "next/navigation";
 import { cache } from "react";
 import type { Rolle } from "@/generated/prisma/enums";
+import { eigenerPfad } from "@/lib/adresse";
 import { prisma } from "@/lib/db";
 import { type GeleseneSitzung, SITZUNGS_COOKIE, sitzungLesen } from "@/lib/sitzung";
 import { darf, type Recht } from "./rollen";
@@ -68,10 +69,10 @@ export const angemeldet = cache(async (): Promise<AngemeldeterBenutzer | null> =
  */
 export async function sitzungErforderlich(recht?: Recht): Promise<AngemeldeterBenutzer> {
   const benutzer = await angemeldet();
-  if (!benutzer) redirect("/login?fehler=Bitte+anmelden.");
+  if (!benutzer) redirect(await eigenerPfad("/login?fehler=Bitte+anmelden."));
 
   if (recht && !darf(benutzer.rolle, recht)) {
-    redirect("/?fehler=Für+diesen+Bereich+fehlt+die+Berechtigung.");
+    redirect(await eigenerPfad("/?fehler=Für+diesen+Bereich+fehlt+die+Berechtigung."));
   }
 
   return benutzer;

tests/sicherheit.test.ts

@@ -100,6 +100,19 @@ describe("Öffentliche Adresse", () => {
     expect(eigeneAdresse(anfrageMit({}), "/").host).toBe("0a5963a591df:3000");
   });
 
+  it("übergeht eine Lausch-Adresse in der Konfiguration", () => {
+    // 0.0.0.0 heißt „alle Schnittstellen“ – als Ziel im Browser ist das unbrauchbar.
+    // Genau so stand es nach einer Installation in der .env und führte beim Abmelden ins Leere.
+    const anfrage = anfrageMit({ host: "proxledger.firma.de" });
+    expect(eigeneAdresse(anfrage, "/login", "http://0.0.0.0:3000").host).toBe("proxledger.firma.de");
+  });
+
+  it("übergeht auch eine Lausch-Adresse aus der Umgebung", () => {
+    vi.stubEnv("APP_URL", "http://0.0.0.0:3000");
+    const anfrage = anfrageMit({ host: "proxledger.firma.de" });
+    expect(eigeneAdresse(anfrage, "/login").host).toBe("proxledger.firma.de");
+  });
+
   it("übergeht einen unbrauchbaren Eintrag, statt zu scheitern", () => {
     const anfrage = anfrageMit({ "x-forwarded-host": "dashboard.kunde.de" });
     expect(eigeneAdresse(anfrage, "/", "keine-adresse").host).toBe("dashboard.kunde.de");