"panic: pgdriver: invalid scheme: lite"
Die Anwendung geht direkt in den PostgreSQL-Treiber; DB_DRIVER wird nicht
ausgewertet. Die MySQL-DSN (lite:pass@tcp(db:3306)/...) liest der Treiber als
URI und findet als Schema den Benutzernamen.
Der Fehler war meiner, und die Ursache lehrreich: ich hatte MySQL aus deren
docker-compose.test.yml uebernommen, weil die als einzige zeigt, wie der
App-Container verdrahtet wird. Sie benutzt aber fivemanage/lite:latest von
Docker Hub — und diese Reihe steht bei beta.16 still. Das README sagt
postgres://, und es hat recht. Ich habe der aelteren Datei mehr geglaubt als
der Doku, weil sie konkreter aussah.
Damit faellt auch die Behauptung, MySQL genuege und man koenne den vorhandenen
QBox-Server mitbenutzen. Stimmt fuer diese Fassung nicht.
Das Volume heisst jetzt pgdata statt db: wer den Stack schon mit MySQL laufen
hatte, bekommt eine frische Ablage, statt dass PostgreSQL ueber ein
MySQL-Verzeichnis stolpert. Das alte bleibt als Waise liegen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ich hatte die Ports an 127.0.0.1 gebunden — enger und auf den ersten Blick
richtiger. Nur erreicht host.docker.internal das auf diesem Server nicht: die
Anfrage kommt aus dem NPM-Container ueber die Docker-Bruecke herein, nicht
ueber Loopback, und ein an 127.0.0.1 gebundener Port nimmt sie nicht an.
Der Beleg stand die ganze Zeit in der Containerliste: d4rkbot (3080),
cdn-files (8090) und portainer sind alle ohne 127.0.0.1-Praefix
veroeffentlicht, und NPM erreicht sie. So laeuft es hier, also laeuft es so.
Damit macht die FIREWALL den Port zu und nicht die Bindung — das steht jetzt
ausdruecklich in beiden Dateien, mitsamt den Befehlen zum Nachsehen. Wer weiss,
dass Loopback bei ihm erreicht wird, setzt BIND_ADDR=127.0.0.1.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Containerliste des Servers beantwortet beides.
Der NPM-Container hat 172.17.0.3 und liegt damit im Standard-Bridge-Netz,
nicht in "web". Meine Vermutung, "web" sei das Proxy-Netz, war falsch — es
gilt Weg B ueber den Host, so wie d4rkbot auf 3080 und cdn-files auf 8090
schon laufen. Im README steht das jetzt als Feststellung und nicht mehr als
Wahrscheinlichkeit.
Und die Ergaenzung wollte ausgerechnet 9000 und 8080 oeffnen — beide vergeben,
an Portainer und an nextcloud-aio. Jetzt 9100 und 9101, und ueber
MINIO_HOST_PORT und LITE_HOST_PORT einstellbar: die naechste Kollision ist dann
eine Variable und keine Dateiaenderung. Im Container bleibt es bei 9000 und
8080; nur die Seite zum Host wandert.
Belegt waren: 80, 81, 443, 2224, 3000, 3080, 3478, 8000, 8080, 8090, 8443,
9000, 9443, 11000.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
"network proxy declared as external, but could not be found".
Die Hauptdatei verlangte ein externes Netz namens proxy, das es auf diesem
Server gar nicht gibt — und die Ergaenzung fuer host.docker.internal half
nicht, weil die Basis es trotzdem forderte. Das war die falsche Reihenfolge:
der Weg nach aussen ist gerade das, was sich je Aufbau unterscheidet, und
gehoert damit nicht in die Basis.
Jetzt ist docker-compose.yml neutral — von aussen nicht erreichbar, und das
ausdruecklich. Dazu waehlt man eine von zwei Ergaenzungen:
docker-compose.proxynet.yml Proxy haengt im selben Netz (http://minio:9000)
docker-compose.hostports.yml Proxy geht ueber den Host
Die Netzliste dieses Servers zeigt kein "proxy", aber ein "web" — ein
Bridge-Netz ohne Stack, also die uebliche Konvention fuer einen Reverse Proxy.
PROXY_NETWORK steht deshalb auf "web", mit dem Hinweis, es nachzusehen statt zu
glauben.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
'docker.io/fivemanage/lite:0.1.0-beta.23: not found' — und zwar zu Recht.
Ich hatte die Registry aus deren docker-compose.test.yml uebernommen
(fivemanage/lite:latest, also Docker Hub) und den Tag aus den GitHub-Releases
(beta.23). Jede Haelfte fuer sich stimmte, die Kombination nicht.
Nachgesehen statt geraten:
ghcr.io/fivemanage/lite beta.18 bis beta.23 und latest
docker.io/fivemanage/lite endet bei beta.16
Docker Hub wird offenbar nicht mehr gepflegt. Das README des Projekts hat es
richtig: dort steht ghcr.io.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der bisherige Befehl war Bash und lief in Windows PowerShell 5.1 nicht — dort
gibt es weder printf noch openssl. Die PowerShell-Fassung steht jetzt zuerst,
Bash daneben.
Zwei Fallen sind darin vermerkt, beide bereits hineingetreten:
RandomNumberGenerator::Fill gibt es erst ab .NET 6; Windows PowerShell 5.1
laeuft auf .NET Framework und kennt nur ::Create().GetBytes().
Set-Content -Encoding utf8 schreibt in 5.1 ein BOM voran. Dann heisst die
erste Variable nicht DB_PASSWORD, und der Stack startet mit einer fehlenden
Angabe, deren Grund man nicht sieht. Der Inhalt ist ohnehin ASCII.
Dazu der Hinweis, dass Get-Random hier nicht taugt: es ist nicht
kryptografisch sicher, und erzeugt wird ein Token-Signaturgeheimnis.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Compose war fuer den sauberen Weg gebaut: NPM im selben Netz, kein Port
offen. Auf diesem Server laeuft NPM aber anders — Bot und Hub haengen dort an
`http://host.docker.internal:3080`, also ueber den Host. So wie sie war, haette
NPM `minio` gar nicht gefunden.
docker-compose.hostports.yml legt deshalb die beiden noetigen Ports offen, und
zwar an 127.0.0.1 gebunden: damit ist der Port vom Internet aus zu, und nur der
Host kommt heran.
Mit einem Vorbehalt, der in der Datei steht: ob `host.docker.internal` eine
Bindung an 127.0.0.1 ueberhaupt erreicht, haengt an der Docker-Fassung. Unter
Linux fuehrt der Weg ueber die Docker-Bruecke statt ueber Loopback, dann muss
die Bindung 0.0.0.0 lauten und die Firewall den Port zumachen. Klappt es nicht,
ist die Bindung nicht der Fehler, sondern der Weg.
Sauberer bleibt Weg A — NPM ins Netz `proxy` haengen. Dann braucht es diese
Datei gar nicht.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ein Ablageort fuer alle Resourcen statt Nextcloud plus rclone von Hand. Der
Unterschied ist nicht der Speicher — den gibt es schon — sondern ein
Schreibweg ueber HTTP: sobald ein Script hochladen soll, fehlt er, und Lite
bringt ihn mit, samt Token je Resource und einer Oberflaeche zum Nachsehen.
Zusammengestellt aus fivemanage/lite: dessen README, der
deployments/docker-compose.yml (Entwicklung, startet die App gar nicht) und der
deployments/docker-compose.test.yml (zeigt die App-Verdrahtung und dass MySQL
genuegt und ClickHouse nicht Pflicht ist).
Zwei Fassungen, und der Unterschied ist Absicht:
docker-compose.yml fuer den Betrieb ueber Portainer aus diesem Repo.
Keine offenen Ports, nur der Reverse Proxy
spricht mit der App.
docker-compose.local.yml zum Ausprobieren auf Docker Desktop. Ports offen,
kein Proxy. Eine beta.23 gehoert erst auf einen
Rechner, an dem nichts haengt.
Ohne ClickHouse und Jaeger: beides ist Logging und Tracing, fuer das Ablegen
von Bildern nicht noetig, und ClickHouse ist eine schwere Abhaengigkeit.
Ein Init-Container legt den Bucket an und stellt ihn auf oeffentlich lesbar.
Ohne diesen Schritt schlaegt der erste Upload fehl, und die Meldung nennt den
Grund nicht.
Healthchecks mit depends_on/condition, sonst startet die App gegen eine
Datenbank, die noch nicht antwortet, und beendet sich — beim ersten Hochfahren
jedes Mal.
NICHT laufen gelassen: Docker war von hier nicht erreichbar. Das YAML ist
geprueft, das Compose-Schema nicht.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
D4rkst3randClaude Opus 5