Einer der vier Punkte bis 1.0.0: eine Sicherung einmal wirklich
zurueckspielen. Mit einem eigenen Stapel durchgespielt - Datenstand
festgehalten, Marke gesetzt, PDF abgelegt, gesichert, alle Volumes
zerstoert, zurueckgespielt. Datenbank, PDF und Anmeldung waren zurueck.
Zwei Luecken kamen erst dabei heraus:
1. Ohne --clean liess sich die Sicherung nur in eine LEERE Datenbank
zurueckspielen - im Ernstfall also gerade nicht. Jetzt
pg_dump --clean --if-exists, gegen eine Datenbank mit Daten geprueft.
2. Fuer die hochgeladenen PDFs gab es keinen beschriebenen Weg zurueck.
deploy/restore.sh haelt die Dienste an, spielt Datenbank und PDFs zurueck,
startet wieder und prueft die Erreichbarkeit. Die .env bleibt unangetastet:
Sie traegt APP_SECRET, und ein falscher Wert dort macht gespeicherte
Zugangsdaten unlesbar.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
deploy/update.sh und deploy/backup.sh konnten nur Docker. Beide erkennen die
Installationsart jetzt selbst und beherrschen auch die Installation als
Dienst: npm ci, prisma migrate deploy, bauen, systemctl restart - und
pg_dump ueber DATABASE_URL fuer die Sicherung.
Beim Durchspielen gegen einen laufenden Stapel zwei Fehler gefunden:
1. Die Zustandspruefung 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. Der
Dienst web blieb dauerhaft auf "health: starting". Behoben mit
ENV HOSTNAME=0.0.0.0; geprueft wird jetzt ueber 127.0.0.1.
2. Eine fehlgeschlagene Sicherung hielt die Aktualisierung nicht auf. Jetzt
bricht sie ab, bevor etwas veraendert wird, und nennt die Auswege.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Vier Anleitungen unter docs/betrieb/: Inbetriebnahme in der richtigen
Reihenfolge, HTTPS mit nginx Proxy Manager sowie netbird als privates Netz,
OIDC mit authentik samt Fehlerbildern, und Sicherung einschliesslich
Zurueckspielen.
Beim Aufschreiben zwei Fehler gefunden, die nur hinter einem Reverse Proxy
auftreten: Die OIDC-Rueckkehradresse uebersah die im Dashboard eingetragene
Adresse, und beim Einloesen des Codes wurde die interne Adresse verwendet -
der Anbieter haette den Tausch abgelehnt.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>