44ad7dc6b32f3a51d920282fde8f788565bab3fc
16
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
44ad7dc6b3 |
feat: Umbenennen, Fivemanage-Sprache, Freigabe-Links, sichtbare Zahlen
UMBENENNEN gab es gar nicht -- verschieben ja, umbenennen nirgends. Jetzt fuer
Datei und Ordner. Die WARNUNG ist dabei der eigentliche Teil: beim Verschieben
wandert eine Datei, beim Umbenennen aendert sich IHRE ADRESSE, und die steht
womoeglich in einem Skript, das niemand mehr im Kopf hat. Der Dialog zeigt
deshalb die Abrufzahl und beim Ordner die Zahl der betroffenen Dateien, BEVOR
gedrueckt wird -- eine Datei mit viertausend Abrufen umzubenennen ist etwas
anderes als eine mit null, und der Dienst ist die einzige Stelle, die den
Unterschied kennt.
Am echten Fall geprueft, dem Kollisionsfund: items/coiloverss.png (hielt die
+-Fassung) -> items/coiloverss-plus.png, alte Adresse 404, neue 200 mit 4375 B,
Vorschau mitgewandert. Ordner: probe -> beispiele, 5 Dateien, alle Pfade in
einer Transaktion umgeschrieben.
Ein Fallstrick dabei: thumbPath haengt ".webp" an. Fuer eine Datei richtig, fuer
einen ORDNER Unsinn -- der Vorschauordner heisst thumbs/vehicles und nicht
thumbs/vehicles.webp. Dafuer gibt es jetzt moveFolder.
DIE 93 KOLLISIONEN SIND ERLEDIGT. tools/kollisionen.ps1 rechnet dieselbe
Zaehmung auf der Quelle nach und zeigt, was zusammenfaellt -- es aendert nichts,
damit die Entscheidung auf Zahlen steht. Ergebnis: 91 von 93 sind dieselbe Datei
zweimal (WEAPON_SMG.png und weapon_smg.png, byteweise gleich gross), da fehlte
nichts. Echt verloren waren ZWEI, beide mit + im Namen. Beide nachgeholt.
FIVEMANAGE-SPRACHE. POST /api/image|video|audio (v1) und POST /api/v3/file (v3),
Schluessel nackt im Authorization-Kopf. Auf einem laufenden Server stecken die
Fivemanage-Aufrufe in einem Dutzend fremder Ressourcen; sie alle umzuschreiben
tut niemand, und deshalb bliebe dieser Dienst ungenutzt daneben stehen. So ist
der Umzug eine Zeile je Skript: die Adresse.
Beide Formen sind AUS ECHTEM CODE abgelesen und nicht geraten -- fivemanage/sdk
fuer v3, Awleks/Devm-Camera fuer den aelteren Weg ueber screenshot-basic.
Gemessen: v1 -> {url,id,path}, v3 -> {status:"ok",data:{id,url}}, ohne
Schluessel 401, ein Video an /api/image -> 415 mit Grund.
Dabei bin ich in eine Falle gelaufen, vor der im eigenen Repo ein Kommentar
warnt: die Token-Wache hing an use('*'), und der Einhaengepunkt ist /api -- also
galt sie auch fuer /api/dash daneben. Das Dashboard bekam 401 auf die ANMELDUNG.
Wortwoertlich derselbe Fehler steht in upload.ts als Kommentar, weil er dort
schon einmal passiert ist. Gemerkt hat es der Gegentest, nicht der Kopf.
FREIGABE-LINKS. /s/<schluessel> zeigt einen Ordner ohne Anmeldung. Was dabei
ausdruecklich dabeisteht, in der Karte und in der Rueckfrage vor dem
Zurueckziehen: FREIGEGEBEN WIRD DIE LISTE, NICHT DER INHALT. Die Dateien sind
ohnehin oeffentlich; ein zurueckgezogener Link macht sie nicht wieder privat, er
nimmt nur die Uebersicht weg. Ohne diesen Satz zieht jemand einen Link zurueck
und glaubt, etwas sei verschwunden.
Die Antwort ist abgemessen: Name, Groesse, Art, Adresse, Laenge. NICHT Hash,
Token, Zeitpunkte, Abrufzahlen, IDs -- nichts davon braucht, wer einen Katalog
ansieht, und jedes davon waere eine Auskunft ueber den Betrieb. Ein unbekannter
Schluessel und ein zurueckgezogener geben dieselbe Antwort.
ZAHLEN, DIE SCHON DA WAREN. Sortieren nach Abrufen und nach "zuletzt geholt";
die Kachel zeigt dann auch diese Zahl statt Groesse und Datum, denn nach etwas
zu ordnen, das man nirgends sieht, ist eine Reihenfolge ohne Begruendung. Und je
Token, was damit abgelegt wurde: media.token_id wird seit dem ersten Tag
geschrieben und war NIRGENDS zu sehen. Gemessen: d4rk_photostudio haelt 810
Dateien / 99,5 MB, 3640 liegen ohne Token da.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
|
d125c6bf72 |
feat: Vorschau fuer Video und Ton, Ordner anlegen dort, wo man es sucht
Mit den ersten echten Clips fiel auf, was bei 3600 Bildern nie auffiel: alles,
was kein Bild ist, bekam ein FRAGEZEICHEN auf die Kachel -- ausgerechnet das
Zeichen fuer "unbekannt" auf einer voellig gesunden MP4.
Jetzt: ein Standbild aus dem Clip (ein Zehntel hinein, weil viele mit Schwarz
oder einem Einblender beginnen und eine schwarze Kachel so aussagekraeftig ist
wie gar keine), bei Ton das eingebettete Titelbild, dazu ein Abspielzeichen und
die LAUFZEIT in der Ecke. Fehlt eine Vorschau, kommt ein Zeichen, das die ART
benennt, statt eines Fragezeichens.
DER PREIS IST FFMPEG IM ABBILD, und der wurde zweimal gemessen und zweimal
gedrueckt:
vorher 460 MB
apt-get install ffmpeg 1,11 GB
statisches ffmpeg + ffprobe 835 MB
statisches ffmpeg allein 648 MB
Debians Paket schaltet jeden Filter frei und zieht die Abhaengigkeiten mit:
libllvm15 (114 MB), Mesa samt libgl1-mesa-dri, libz3 und libflite1 -- ein
SPRACHSYNTHESIZER. Alles fuer Filter, die ein Dienst ohne Bildschirm nie
anfasst; --no-install-recommends half nicht, es sind harte Abhaengigkeiten.
ffprobe flog danach auch noch raus: 135 MB fuer eine einzige Aufgabe, die
Laenge zu nennen -- die steht auch im Kopf, den ffmpeg beim Oeffnen druckt.
Gegengeprueft an beiden Dateien, auf zwei Nachkommastellen identisch:
ffprobe 29.767967 | ffmpeg Duration: 00:00:29.77
ffprobe 645.642449 | ffmpeg Duration: 00:10:45.64
Der Preis dafuer ist ebenfalls zu benennen: die Fassung haengt jetzt an einer
Zeile im Dockerfile und nicht mehr an apt. Vertretbar, weil ffmpeg hier nur
eigene, bereits abgelegte Dateien anfasst und nicht am Netz haengt.
EIN FEHLER, DER ZWEIMAL DERSELBE WAR. "Keine Bildspur" ist bei Ton der
Normalfall -- die meisten MP3 tragen kein Titelbild. Der erste Anlauf erkannte
das am WORTLAUT der Fehlermeldung, und der ist zwischen den Fassungen anders:
ffmpeg 5.1 "Stream map '0:v:0' matches no streams."
ffmpeg 7.1 "Failed to set value '0:v:0' for option 'map'"
Ergebnis: eine gesunde MP3 wurde als "1 fehlgeschlagen" gezaehlt, und dann
sucht jemand einen Fehler, den es nicht gibt. Gelesen wird jetzt die
SPURENLISTE ("Stream #0:1: Video:"), die seit jeher so dasteht -- und die kommt
aus demselben Aufruf wie die Laenge, also ein Blick in die Datei statt drei.
Gemessen: fehler 0, ohneBild 1.
Beide Wege durchgeprueft. Video: 320x180, Durchschnittsfarbe RGB(97,140,155) --
echtes Bild und kein schwarzer Vorspann. Ton mit angehaengtem Titelbild:
Vorschau erzeugt, dauer 8.05, Kachel zeigt 0:08.
UND ZWEI ORDNER-LUECKEN, beide beim Benutzen gefunden.
"Wie lege ich neue Ordner an?" -- gar nicht, ausser man wusste es: der Knopf
sass NUR im Verschieben-Dialog. Wer einen leeren Ordner wollte, musste erst
Dateien auswaehlen und "Verschieben" druecken. Eine Funktion, die man nur ueber
eine andere Funktion erreicht, ist fuer den, der sie sucht, nicht vorhanden.
Jetzt steht sie unter dem Ordnerbaum, mit der Angabe, IN welchem Ordner sie
entsteht -- sonst tippt jemand "waffen", landet in "items/waffen" und sucht
danach an der Wurzel.
Zielordner beim Hochladen: vorher galt stillschweigend der in der Galerie
angeklickte. Richtig, solange man es weiss, und ein Fallstrick, sobald man es
nicht weiss -- wer nach einer Suche hochlaedt, steht in "Alle" und legt an der
Wurzel ab. Der angeklickte bleibt die Voreinstellung, ist jetzt aber sichtbar
und aenderbar, samt "neuer Ordner" direkt daneben.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
|
7b35ef5698 |
feat: Betrachter fuer Lesbares, und aus dem <video> wird ein Player
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>
|
||
|
|
40c446f859 |
feat: Papierkorb, Abrufzaehler, WebP ohne Adressaenderung, ZIP hochladen
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> |
||
|
|
51071fc292 |
docs: README und .env.example auf den Stand -- und Embeds im Stil des Bots
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> |
||
|
|
b1576cefb0 |
docs: "Create organization" tut nichts — neu laden hilft
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> |
||
|
|
0b45f31c15 |
docs: zwei Eigenheiten festhalten, die sonst zweimal Zeit kosten
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> |
||
|
|
e2e12409b8 |
fix: Host-Ports in die Grunddatei, hostports.yml entfaellt
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> |
||
|
|
65a04af8a1 |
fix: BUCKET_DOMAIN ergaenzt, minio-init entfernt
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> |
||
|
|
ca85c4f135 |
fix: PostgreSQL statt MySQL — beta.23 kennt DB_DRIVER nicht
"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> |
||
|
|
c5b66b466a |
fix: an alle Adressen binden, sonst erreicht NPM die Dienste nicht
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> |
||
|
|
d0f173d67d |
fix: freie Host-Ports, und der Weg ist jetzt belegt statt vermutet
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> |
||
|
|
9c690c46b9 |
fix: das externe Netz war fest verdrahtet und existierte nicht
"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> |
||
|
|
d33db5eb79 |
README: die Geheimnisse in PowerShell erzeugen
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> |
||
|
|
ba5c733e27 |
Ergaenzung fuer einen Reverse Proxy ausserhalb des Docker-Netzes
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> |
||
|
|
72f61dbd07 |
Medien-Stack: Fivemanage Lite mit MySQL und MinIO
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>
|