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
Beide Skripte erkennen die Installationsart selbst (systemd-Dienst oder Docker)
Sicherung für den Dienst-Weg: pg_dump über DATABASE_URL, Uploads aus UPLOAD_DIR
Fehlgeschlagene Sicherung bricht die Aktualisierung ab – vor jeder Änderung
Hinweis am Ende von deploy/lxc-installer.sh auf die Skripte umgestellt
Handbuch und Betriebsdoku angepasst
Docker-Weg vollständig durchgespielt
Zwei Fehler beim Durchspielen gefunden
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).
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.
Quelle: docs/issues/031-update-skript-beide-varianten.md – dort wird dieses Issue gepflegt.
## 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**.
---
Quelle: `docs/issues/031-update-skript-beide-varianten.md` – dort wird dieses Issue gepflegt.
florian.wilde
added this to the v0.20.0 milestone 2026-10-03 14:20:38 +00: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.
Ziel
deploy/update.shunddeploy/backup.shkonnten nur Docker. Die Installation als Dienst (Node undPostgreSQL direkt im LXC) ging leer aus – dort half nur der Weg über das Gerüst der community-scripts.
Aufgaben
npm ci,prisma migrate deploy, bauen,systemctl restartpg_dumpüberDATABASE_URL, Uploads ausUPLOAD_DIRdeploy/lxc-installer.shauf die Skripte umgestelltZwei Fehler beim Durchspielen gefunden
die Adresse aus
HOSTNAME– und Docker setzt darin den Containernamen. Der Server lauschte alsonur auf der Container-IP, nicht auf
127.0.0.1. Der Dienstwebblieb dauerhaft auf„health: starting“; von außen war er trotzdem erreichbar, deshalb fiel es bisher nicht auf.
Behoben mit
ENV HOSTNAME=0.0.0.0im Dockerfile; die Prüfungen verwenden jetzt127.0.0.1statt
localhost(das löst im Container auch auf::1auf)./var/backupsgehört root) und dieAktualisierung 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
webzum ersten Mal auf healthy.Quelle:
docs/issues/031-update-skript-beide-varianten.md– dort wird dieses Issue gepflegt.