florian.wildeandClaude Opus 5
94d5edbc6c
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>
Installation als LXC-Container nach Art der Proxmox VE Helper-Scripts
Diese beiden Skripte folgen den Konventionen von community-scripts.org
(der Nachfolge von tteck's Helper-Scripts). Sie legen einen unprivilegierten Debian-13-Container an,
installieren Node.js 24 und PostgreSQL 17, holen ProxLedger aus dem Git-Repository, richten zwei
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) |
install/proxledger-install.sh |
Installation im Container |
Verwendung im eigenen Netz
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) lädt das Skript von den community-scripts nach – das ist öffentlich und ohne
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
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:
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:
PROXLEDGER_REPO=https://git.example.de/fw/ProxLedger.git PROXLEDGER_BRANCH=main bash -c "$(curl -fsSL …)"
Ist das Git-Repository nicht ohne Anmeldung lesbar, gehört ein Lesezugriffs-Token in die Adresse
(https://<token>@git.example.de/...). Das Token landet dann in der Prozessliste des Containers –
also besser einen Deploy-Token verwenden, der nur lesen darf.
Was eine Einreichung bei community-scripts verlangen würde
Wir liefern die Skripte vorerst nur intern aus. Für eine Einreichung wären zusätzlich nötig:
- Öffentlich erreichbarer Quelltext. Die Skripte dort holen die Anwendung praktisch immer aus
einem öffentlichen GitHub-Repository (
fetch_and_deploy_gh_release). Ein privates Gitea genügt nicht. - Pull Request gegen ProxmoxVED, nicht gegen ProxmoxVE. Neue Skripte, die direkt gegen ProxmoxVE eingereicht werden, werden ohne Prüfung geschlossen.
- MIT-Lizenz im eigenen Repository und der Lizenzkopf in beiden Skripten (steht bereits darin).
- Englische Dokumentation – die Skripte selbst sind auf Englisch gehalten, die deutschen Kommentare in diesem Verzeichnis müssten übersetzt werden.
- Metadaten für die Webseite. Die JSON-Dateien liegen inzwischen nicht mehr im Skript-Repository; wo sie hingehören, steht in der aktuellen Beitragsanleitung. Das ist beim Einreichen zu prüfen.
Die Skripte sind so geschrieben, dass für eine spätere Einreichung nur die Quelle zu tauschen und die Kommentare zu übersetzen sind – am Ablauf ändert sich nichts.
Unterschied zum Docker-Weg
| Helper-Script (LXC) | Docker Compose | |
|---|---|---|
| Umgebung | eigener Container auf dem Proxmox-Host | beliebiger Docker-Host |
| Datenbank | PostgreSQL im selben Container | eigener Dienst |
| Aktualisierung | update-Weg des Skripts |
bash deploy/update.sh |
| Sicherung | Proxmox-Sicherung des Containers | bash deploy/backup.sh |
Beide Wege sind gleichwertig. Wer ohnehin Proxmox betreibt, fährt mit dem LXC-Weg meist einfacher – die Sicherung des Containers erledigt dann die gewohnte Proxmox-Sicherung mit.