3 Commits

Include renames

Author	SHA1	Message	Date
florian.wildeandClaude Opus 5	d311fe48c0	fix(docker): keine Ports auf 0.0.0.0 und ein Overlay ohne Freigaben ... Der Datenbankport wurde in beiden Betriebsarten auf 0.0.0.0 gelegt, obwohl ihn nur die Entwicklung braucht: im Container spricht die Anwendung "db:5432" ueber das Compose-Netz an, und backup.sh geht ueber docker exec. Auf einem Server lauschte Postgres damit im Netz, geschuetzt allein durch das Passwort aus der .env. Die Anleitung riet zwar zu 127.0.0.1, aber als Handgriff statt als Voreinstellung -- die falsche Richtung. Datenbank und Adminer binden jetzt von Haus aus auf 127.0.0.1. Liegen mehrere Stacks auf einem Host und regelt ein gemeinsamer Reverse Proxy den Zugang, braucht Nebula gar keinen Host-Port. docker-compose.server.yml nimmt beide Freigaben zurueck und haengt die Anwendung in ein geteiltes Netz. Das braucht !reset: Compose fuehrt "ports" beim Zusammenfuehren anhaengend statt ersetzend zusammen, eine leere Liste im Override wuerde also nichts loeschen. update.sh las die Adresse aus APP_PORT und haette in diesem Modus einen Port gemeldet, den es nicht gibt. Es fragt jetzt Docker und sagt sonst, dass nur das interne Netz erreichbar ist. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-27 09:19:51 +02:00
florian.wildeandClaude Opus 5	6808d4d34a	fix(scripts): Einrichtung und Update ohne Node ... Ein reiner Docker-Host hat kein Node installiert. Die Anleitung verlangte trotzdem "node scripts/setup.mjs", und update.sh las die Versionsnummer mit "node -p" - beides waere dort gescheitert. scripts/setup.sh macht dasselbe wie die .mjs-Fassung in reinem POSIX-Shell: .env aus der Vorlage anlegen, ein APP_SECRET wuerfeln (openssl, sonst /dev/urandom) und die Rechte auf 600 setzen. Ersetzt wird zeilenweise statt mit einem sed-Ausdruck, weil base64 Schraegstriche enthaelt. update.sh liest die Version jetzt selbst aus der package.json. Dabei fielen zwei Fehler auf, die mein eigener Rat verursacht hat. Die Anleitung empfiehlt APP_PORT="127.0.0.1:3000", damit die Anwendung nur hinter dem Reverse Proxy erreichbar ist - die Gesundheitspruefung baute daraus aber "http://127.0.0.1:127.0.0.1:3000". Und curl ist auf einem Docker-Host nicht garantiert. Gefragt wird deshalb jetzt der Container selbst ueber seinen HEALTHCHECK; curl liefert nur noch die Antwort zum Anzeigen, wenn es da ist. Am Ende nannte das Skript den Sicherungspfad mit Anfuehrungszeichen - so liess er sich nicht kopieren. Nachgewiesen: dreimal gegen die laufende Instanz durchgelaufen, jedes Mal mit Sicherung, Bau, Neustart und gesunder Antwort. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 00:26:46 +02:00
florian.wildeandClaude Opus 5	47245152a2	docs: Anleitung fuer den Serverbetrieb und Update-Skript ... DEPLOYMENT.md fuehrt Schritt fuer Schritt vom leeren Server zur Instanz hinter TLS: Docker, Konfiguration, Reverse Proxy mit Caddy oder nginx, Firewall, Sicherungen per Cron. Dazu, was an Haertung schon eingebaut ist - und was der Betreiber selbst beisteuern muss. scripts/update.sh macht die Schritte in der richtigen Reihenfolge: pruefen, holen, sichern, bauen, starten, Gesundheit pruefen. Erst bauen und dann umschalten, damit ein gescheiterter Bau die laufende Fassung nicht mitnimmt; die Sicherung liegt vor jeder Schemaaenderung. Antwortet /api/health nach einer Minute nicht, zeigt es die letzten Logzeilen und nennt den Weg zurueck. Es weigert sich zu laufen, solange APP_SECRET leer oder noch der Entwicklungswert ist - mit diesem Wert liegen die Git-Tokens faktisch offen. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 00:14:31 +02:00