Bild, Video, Ton und PDF konnte der Betrachter schon. Was fehlte, war
ausgerechnet die Art, die man am ehesten nur lesen und nicht herunterladen
will: eine .md landete im Zweig "laesst sich hier nicht anzeigen".
LESBARES. Markdown gesetzt, .lua und .json eingefaerbt, CSV als Tabelle, alles
Uebrige mit Zeilennummern. Der Tokenizer ist DERSELBE wie fuer die Schnipsel
auf der API-Seite und nicht ein zweiter -- zwei waeren zwei, die auseinander
laufen. Die Zeilennummern liegen in einer eigenen Spalte: so nimmt ein
Markieren mit der Maus sie nicht mit.
Die CSV-Zerlegung kann Anfuehrungszeichen und doppelte darin. Das ist der Teil,
den ein split(';') falsch macht, und CSV aus Excel hat ihn regelmaessig; das
Trennzeichen wird aus der Kopfzeile geraten.
NICHT ALLES WIRD GEHOLT. Die Groesse steht in der Datenbank, also wissen wir
vorher, worauf wir uns einlassen: ueber 512 KB kommt per Bereichsanfrage nur
der Anfang, und das steht auch da. Ein Betrachter, der bei einem 400-MB-
Protokoll den Tab abschiesst, ist schlimmer als einer, der die Datei gar nicht
erst oeffnet. Gemessen: Range: bytes=0-49 -> 206, 50 Bytes.
MARKDOWN OHNE BIBLIOTHEK, und das ist kein Geiz. Der uebliche Weg heisst marked
plus DOMPurify und endet bei dangerouslySetInnerHTML -- damit haengt die
Sicherheit dieser Seite an der Frage, ob die Filterliste vollstaendig ist. Hier
entsteht NIE eine HTML-Zeichenkette: der Text wird zu React-Knoten, und ein
<script> in einer hochgeladenen .md erscheint als die acht Zeichen, die es ist.
Im ganzen ui/ steht kein einziges dangerouslySetInnerHTML.
Die eine Luecke, die React nicht schliesst, ist href: [klick](javascript:...)
kaeme durch. Zwoelf Faelle in Node durchgeprueft, alle bestanden -- http,
https, mailto und relative Ziele durch; javascript:, JavaScript:, mit
Leerzeichen davor, data:, vbscript:, file: abgelehnt und als Text stehen
gelassen.
DER PLAYER. Die Bedienelemente bleiben die des Browsers: ein selbstgebauter
Schieber sieht in jedem Browser anders falsch aus, kennt keine
Tastatursteuerung und keine Untertitel. Drumherum kam, was der Browser nicht
mitbringt.
Lautstaerke ueber Dateien hinweg -- <video> setzt sie bei jedem neuen Element
auf 1 zurueck, und wer sich durch zwanzig Clips klickt, stellt sie sonst
zwanzigmal leise, waehrend der einundzwanzigste ungefragt wieder hochfaehrt.
Weiter zum naechsten Stueck, abschaltbar, und nur wenn das Naechste auch etwas
zum Abspielen ist: nach einem Lied ungefragt bei einem Bild zu landen waere
schlechter als stehenzubleiben.
Tastatur an EINER Stelle: Leertaste haelt an, Pfeile springen fuenf Sekunden,
Umschalt+Pfeil wechselt die Datei. Bei allem anderen blaettern die Pfeile wie
bisher. Dass das so ist, steht als Zeile unter dem Bild -- eine unsichtbare
Sonderregel fuehlt sich an wie ein Fehler.
SERVER. Die Typtabelle kennt jetzt md, markdown, csv, lua, xml, yml, yaml,
toml, ini, cfg, sql und log -- alle als text/plain. Nicht als text/markdown
(braechte nichts) und erst recht nicht als text/html: wer einen Upload-Token
hat, koennte damit eine Seite unter unserem Namen veroeffentlichen. html, css
und js stehen deshalb weiterhin NICHT drin.
Der Betrachter entscheidet trotzdem nach der Endung und erst danach nach der
gemeldeten Art. Grund steht in der Datenbank: items/readme.md lag schon da und
trug application/octet-stream, weil sie vor der erweiterten Tabelle hochgeladen
wurde. Wer nur auf die Art schaut, zeigt die alte README nicht an und eine neue
schon -- und sucht den Unterschied an der falschen Stelle.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Vier Dinge, alle am laufenden Dienst gemessen.
PAPIERKORB. Loeschen war endgueltig -- bei einem Knopf "alle 3861 waehlen"
direkt neben "loeschen" ist das die falsche Haerte, und die Sicherung half nur
bis zum letzten naechtlichen Lauf. Die Datei wandert jetzt nach
/data/papierkorb, der Datensatz in eine eigene Tabelle, nach 30 Tagen raeumt
der Dienst stuendlich selbst auf. Der Ablagename traegt eine laufende Nummer:
unter demselben Pfad koennen nacheinander verschiedene Dateien gelegen haben,
und beide sollen zurueckholbar sein. Geprueft: loeschen -> oeffentlich 404,
Eintrag im Papierkorb, zurueckholen -> 200 samt neu gerechneter Vorschau.
ABRUFZAEHLER. media.abrufe und zuletzt_abgerufen. Gezaehlt wird im Speicher und
alle 30 Sekunden weggeschrieben -- ein UPDATE je Kachel waeren bei einer
Galerieseite 120 Schreibvorgaenge. Der 304 zaehlt mit (der Aufrufer WOLLTE die
Datei, er hatte sie nur schon), HEAD nicht. Was vor dem Einbau lag, steht als
"nie geholt" da, auch wenn es taeglich benutzt wurde -- die Karte im
Speicherbericht sagt das auch dazu, statt eine Zahl zu zeigen, die luegt.
WEBP OHNE ADRESSAENDERUNG. Der Pfad ist die Adresse: aus items/foo.png darf
nicht items/foo.webp werden. Die sparsame Fassung liegt deshalb DANEBEN und
wird unter DERSELBEN Adresse ausgeliefert, wenn der Aufrufer per Accept sagt,
dass er WebP versteht. Nachgemessen an einer Datei: 6448 Bytes fuer curl, 2758
fuer einen Browser. Ueber den ganzen Bestand: 3606 Fassungen, 199,3 MB ->
33,1 MB, gespart 166,2 MB. Bei 29 lohnt WebP nicht -- dort bleibt es beim
Original.
Zwei Dinge haengen daran, beide gegengeprueft: "Vary: Accept" (ohne die Zeile
legt ein Zwischenspeicher die WebP-Fassung fuer alle ab, auch fuer die, die sie
nicht lesen koennen) und getrennte ETags mit "-w" (sonst bekaeme jemand auf
seinen If-None-Match hin ein 304 fuer das falsche Bild). Gemessen: derselbe
ETag mit Accept -> 304, ohne Accept -> 200 mit dem PNG.
ZIP HOCHLADEN. Ein Archiv wird ausgepackt statt abgelegt, die Ordner darin
bleiben erhalten und haengen sich hinter den gewaehlten Zielordner. fflate und
nicht adm-zip: reines JavaScript, keine native Bibliothek -- dieses Projekt hat
schon einen halben Abend an einer ABI-Nummer verloren. Grenzen: 5000 Eintraege,
256 MB entpackt, geprueft VOR dem Entpacken (eine Zip-Bombe waere sonst schon
im Speicher). Zip-Slip gemessen: "../../../../etc/passwd" und
"..\..\windows\hosts" abgelehnt, die harmlose Datei im selben Archiv abgelegt.
UND EIN KNOPF, DER GELOGEN HAT. Der erste Nachruestlauf ueber alle Dateien
brauchte mehr als 90 Sekunden -- genau da gibt Nginx Proxy Manager auf. Der
Aufrufer sah einen 504, waehrend die Arbeit im Hintergrund weiterlief und
fertig wurde. Ein Knopf, der Erfolg als Fehler meldet, ist schlimmer als einer
ohne Rueckmeldung.
Beide Wartungsknoepfe laufen deshalb in Runden zu 300 Stueck: der Server meldet
"offen" und "fertig", die Oberflaeche ruft erneut auf und zeigt dabei "280
erzeugt, noch 129 offen ...". Gemessen: 7,8 s je Runde statt 90+ am Stueck. Der
Vorschau-Knopf hatte dieselbe Wand und wurde mitgezogen, obwohl er noch nicht
dagegengelaufen war.
Nebenbei: der Verwaisten-Sucher kennt jetzt auch /data/webp (gleiche Schleife,
Ordner im Ergebnis vorangestellt), Verschieben und Loeschen nehmen die sparsame
Fassung mit, und das Loeschen eines Ordners raeumt thumbs/ und webp/ hinterher.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
DIE README BESCHRIEB NOCH DEN VORGAENGER: "Fivemanage Lite mit MySQL und
MinIO", Ausprobieren ueber docker-compose.local.yml, vier Geheimnisse, davon
drei fuer Dienste, die es nicht mehr gibt. Jetzt beschreibt sie, was da ist:
ein Container, SQLite, Dateien auf einer Platte -- Starten, was der Dienst
kann, die eine Regel und wie sie im Code durchgesetzt wird, Betrieb (Sicherung,
Wiki, Zurueckspielen), was bewusst fehlt, und die zwei Dinge, die Zeit gekostet
haben.
Und die .env.example nannte DB_PASSWORD, MINIO_ROOT_PASSWORD und
API_TOKEN_HMAC_SECRET -- drei Werte fuer Dienste, die seit Wochen weg sind, und
KEINEN der acht, die das Compose wirklich liest. Nachgezaehlt: jetzt sind alle
acht genannt, zwei als Pflicht, sechs als Optional mit dem Grund dahinter.
EMBEDS IM STIL DES BOTS. Auf den Hinweis hin in d4rkbot/src/embeds.js
nachgesehen: dort gibt es eine zentrale Embed-Fabrik mit Markenfarbe
(#f5c518), Fusszeile "D4RKST3R // <TAG>" und Zeitstempel. Zwei Dienste
desselben Hauses sollen in einem Kanal nicht wie zwei Fremde aussehen -- also
uebernommen statt neu erfunden, samt Feldern statt Fliesstext und Discords
Zeitmarken (<t:...:R>), die "vor 3 Stunden" in der Zeitzone des Lesers
anzeigen.
EINE ABWEICHUNG, mit Absicht: der Bot faerbt alles in der Markenfarbe, hier
faerbt die SCHWERE. Eine Warnung, die aussieht wie jede andere Nachricht, ist
eine Warnung, die man ueberliest -- und diese Meldungen gibt es nur, weil
jemand sie sehen soll.
Die Testnachricht schickt jetzt echte Zahlen mit. So sieht man nicht nur, DASS
etwas ankommt, sondern auch, ob es lesbar ist.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Organisation wird angelegt. NewOrganizationRoute.tsx ruft nur mutate(data)
ohne onSuccess, ohne Navigation, ohne Meldung — die Seite bleibt einfach
stehen. Im Container-Log steht dazu nichts, weil der Handler nur im Fehlerfall
protokolliert; genau dieses Schweigen ist der Hinweis, dass es geklappt hat.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Das Tracing-Rauschen alle fuenf Minuten ist kein Fehler und laesst sich in
beta.23 nicht abstellen: otlpEndpoint ist eine Konstante, ENV waehlt nur
zwischen TLS und unverschluesselt. Da die Adresse localhost lautet, hilft auch
kein Jaeger-Container daneben — der muesste sich den Netzwerk-Namensraum
teilen.
Wichtiger: wenn ein Knopf in der Oberflaeche nichts tut, steht der Grund im
Log und nie auf dem Bildschirm. http-util.ts wirft jeden Fehler als
new Error(...) weiter, die Hooks pruefen auf "instanceof ApiError" — das ist
danach nie wahr. 401, 500 und ein falscher Rumpf sehen alle gleich aus.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Stack lief, meldete alle Container gesund — und beide Adressen gaben 502.
Grund: kein einziger Port veroeffentlicht. Die standen in
docker-compose.hostports.yml, und Portainer hat die nicht angewandt.
Das war mein Anleitungsfehler. Ich hatte geschrieben, man koenne unter
"Compose path" zwei Pfade mit Komma angeben. Portainer nimmt dort EINE Datei.
Die Ergaenzung wurde nicht etwa abgelehnt, sondern stillschweigend ignoriert —
die schlechteste Art zu scheitern, weil danach alles gesund aussieht.
Eine Trennung, die man nicht anwenden kann, ist keine. Die Ports stehen jetzt
in docker-compose.yml, wo dieser Server sie ohnehin braucht.
docker-compose.proxynet.yml bleibt als der sauberere Weg fuer einen Proxy im
selben Docker-Netz, jetzt aber mit dem Hinweis, dass er ueber Portainer-aus-
Repo nicht zu haben ist. Hier trifft er nicht zu: NPM liegt auf 172.17.0.3 im
Standard-Bridge-Netz.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Zwei Funde beim Lesen von pkg/storage/s3/s3.go und der .env.template des
Projekts.
BUCKET_DOMAIN fehlte. AWS_ENDPOINT ist nur der Weg, auf dem Lite die Dateien
HINLEGT — http://minio:9000, Containername im internen Netz, und das ist
richtig so. Die oeffentliche Adresse, die Lite nach dem Upload zurueckgibt,
baut es aus BUCKET_DOMAIN. Die Variable steht nicht im README des Projekts,
nur in dessen .env.template (BUCKET_DOMAIN=http://localhost:9000/lite-dev,
also Endpunkt plus Bucket). Ohne sie waere jeder Upload scheinbar geglueckt
und das Bild von aussen nicht abrufbar — ein Fehler, der erst im Handy
auffaellt und dort nach einem CDN-Problem aussieht.
minio-init faellt weg, und zwar nicht nur als Ballast: Lite legt den Bucket
beim Start selbst an und setzt dabei die oeffentliche Leserichtlinie. Es
ueberspringt beides, wenn der Bucket schon existiert ("already exists.
skipping creation and policy application"). Mein Init-Container kam ihm zuvor
und haette damit genau die Richtlinie verhindert, die er ersetzen sollte. Dass
es trotzdem funktioniert haette — mc anonymous set download tut dasselbe —
macht es nicht besser, sondern nur unauffaelliger.
AWS_REGION folgt jetzt deren Vorlage (eu-west-1 statt auto). Fuer MinIO ist
sie gleichgueltig, das SDK verlangt aber eine.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
"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>
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