florian.wildeandClaude Opus 5
6dfa85381a
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>
4.3 KiB
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.