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>
Ein per curl geladenes ct-Skript kann seine eigene Herkunft nicht ermitteln.
Das Geruest suchte install/proxledger-install.sh deshalb bei den
community-scripts auf GitHub und brach mit 404 ab, nachdem der Container
bereits angelegt war. Jetzt setzt das Skript COMMUNITY_SCRIPTS_URL selbst;
fuer Forks und andere Zweige bleibt es ueberschreibbar.
Ausserdem die Vorgabe fuer den Arbeitsspeicher auf 4 GB angehoben: next build
braucht waehrend der Installation deutlich mehr als 2 GB.
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>
README und Inbetriebnahme nannten Platzhalter, die community-scripts-Dateien
einen falschen Benutzerpfad (fw statt florian.wilde) - der Einzeiler haette
dort ins Leere gezeigt.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Docker: deploy/update.sh sichert, baut, migriert und prueft die
Erreichbarkeit; der Worker hat jetzt eine Zustandspruefung. Der ganze Stapel
wurde durchgespielt - bauen, starten, migrieren, anmelden, Agent-Skript
abrufen.
Dabei ein echter Fehler aufgefallen: Nach der Anmeldung zeigte die
Weiterleitung auf den internen Containernamen. Hinter einem Reverse Proxy
waere das eine tote Adresse gewesen. Weiterleitungen nehmen jetzt die
eingetragene Adresse, sonst APP_URL, sonst die Proxy-Kopfzeilen.
Dazu Skripte nach Art der Proxmox VE Helper-Scripts (Node und PostgreSQL
direkt im LXC, ohne Docker). Vorerst intern: Eine Einreichung setzt
oeffentlichen Quelltext voraus und laeuft ueber ProxmoxVED.
Ausserdem docs/roadmap.md: Bis 1.0.0 fehlt kein Code mehr, sondern
Erprobung.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Mehrstufiges Abbild mit Standalone-Ausgabe, eigener Migrationsdienst, Worker als
ESM-Buendel, LXC-Installer fuer Proxmox, Reverse-Proxy-Beispiele, Sicherungsskript
und Zustandspruefung. Stapel gebaut und mit Agent-Durchlauf geprueft.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
florian.wildeandClaude Opus 5