D4rkst3randClaude Opus 5
e4a125e1c6
BEIM UEBERNEHMEN VON 3670 DATEIEN STARB DER DIENST. Nicht einmal, sondern in
Schleife: acht Neustarts, nach aussen 502 vom Proxy.
TypeError [ERR_INVALID_STATE]: ReadableStream is already closed
at ReadableByteStreamController.close (node:internal/webstreams/...)
DIE URSACHE WAR MEINE EIGENE AENDERUNG von vor einer Stunde. Um PowerShells
Formular-Rumpf zu vertragen, hatte ich `c.req.parseBody()` durch
`c.req.raw.formData()` ersetzt -- und damit Hono den Rumpf weggenommen, den es
selbst verwaltet. Beim Aufraeumen der Antwort schliesst dann jemand einen
Strom, der schon zu ist. Die Ausnahme faellt in einem Microtask an, also
AUSSERHALB jedes try/catch, und Node beendet den Prozess.
Beim Test mit 57 Dateien fiel das nicht auf. Bei 3670 schon.
Jetzt geht der Normalfall wieder ueber Hono; der eigene Weg gilt nur noch fuer
die Antwort mit Anfuehrungszeichen an der Grenzmarkierung, fuer die er gedacht
war.
UND EIN NETZ DARUNTER: process.on('uncaughtException') faengt, was ausserhalb
jedes try/catch anfaellt, und laesst den Dienst weiterlaufen. Die Abwaegung
steht im Code: das ist NICHT in jedem Fall richtig -- der Prozess kann danach
kaputt sein. Hier ueberwiegt das Weiterlaufen, weil dieser Dienst keinen
Zustand im Speicher haelt (alles in SQLite und auf der Platte) und ein Dienst,
der wegen EINER Anfrage fuer alle weg ist, der schlechtere Tausch waere. Laut
wird es trotzdem.
DER SCHADEN WAR REPARIERBAR, und zwar mit dem Werkzeug von heute Nachmittag:
206 Dateien waren durch, 2 lagen auf der Platte OHNE Datensatz (geschrieben,
dann starb der Prozess vor dem Eintrag), dazu eine verwaiste Vorschau. Der
Verwaisten-Finder hat sie gefunden, "aufnehmen" hat sie eingetragen -- keine
Datei verloren.
Und die Fehlermeldung im Uebernahmeskript verschwieg die Ursache: sie meldete
"Conversion from JSON failed ... Unexpected character <", obwohl die Wahrheit
ein 502 war. Jetzt wird der HTTP-Code mitgelesen, bei 502 sauber abgebrochen
und gesagt, dass ein neuer Lauf einfach weitermacht.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
d4rk_media
Eigener Medien-Dienst für alle FiveM-Ressourcen: Dateien annehmen, ablegen, ausliefern, in einem Dashboard verwalten. Ein Container, SQLite, Dateien auf einer Platte.
Läuft unter https://fivemanage.d4rkst3r.de — Dashboard und API an der
Wurzel, Dateien unter /f/.
vehicles/adder.webp → https://fivemanage.d4rkst3r.de/f/vehicles/adder.webp
Der Pfad ist der Schlüssel. vehicles/adder.webp bleibt
vehicles/adder.webp, damit die Vorlage in einem Skript schlicht
{model}.webp lauten kann. Die Adressen stehen nirgends in der Datenbank — sie
werden bei jeder Antwort aus PUBLIC_URL gebaut. Ein Umzug auf einen anderen
Namen ist eine geänderte Variable, kein Datenbankeingriff.
| Anleitung für Skripte | Wiki — Quelle ist docs/ |
| Stand und Reihenfolge | ROADMAP.md |
| Arbeitsweise | CLAUDE.md — prüfen statt raten |
Starten
cp .env.example .env # PUBLIC_URL und ADMIN_PASSWORD ausfüllen
docker compose up -d --build
Das war es. Ein Container, ein Volume, kein zweiter Dienst.
In Portainer: Stacks → Add stack → Repository, Compose path: docker-compose.yml. Die Werte kommen als Stack-Variablen.
Compose pathnimmt genau EINE Datei. Ergänzungen werden stillschweigend übergangen — alle Container gesund, alles 502. Das hat beim Vorgänger einen Nachmittag gekostet.
An der Oberfläche arbeiten
npm --prefix server/ui install
npm --prefix server/ui run dev
Läuft auf localhost:5173 und leitet /api und /f an den Container weiter.
Dass das Sitzungs-Cookie dabei ankommt, liegt an einer Ausnahme: es trägt
Secure, und ein Browser nimmt so eines über http nur auf localhost an.
Was der Dienst kann
Hochladen — über die Skript-API mit Token (drei Rumpfformen: multipart, Base64, rohe Bytes) oder aus dem Dashboard per Ziehen und Ablegen. Bilder, Videos, Ton, PDF.
Ausliefern — mit ETag, 304, Bereichsanfragen und nosniff. Vorschaubilder
werden beim Upload erzeugt (320 px WebP): aus 7,5 MB je Galerieseite werden
766 KB.
Verwalten — Galerie mit Ordnerbaum, Suche, Filter nach Medienart, Sortierung, Mehrfachauswahl, Verschieben, Löschen. Betrachter für Bild, Video, Ton und PDF ohne neuen Tab.
Nachvollziehen — ein Verlauf: wer hat wann was abgelegt, ersetzt, verschoben oder gelöscht.
Anmelden — über Discord (eine Rolle auf dem Server genügt) oder mit Passwort. Das Passwort bleibt als Notausgang.
Sichern — täglich, geprüft, in die Nextcloud. Und der Dienst meldet nach Discord, wenn die Sicherung ausbleibt.
Die eine Regel
Jeder Knopf gibt Rückmeldung, auch der erfolgreiche.
Das ist der Fehler, an dem der Fivemanage-Anlauf gescheitert ist: dessen
http-util.ts warf jeden Fehlschlag als new Error(…), die Hooks prüften auf
instanceof ApiError — und damit verschwand jeder Fehler lautlos. Create organization gab weder Erfolg noch Misserfolg zurück; das Ergebnis waren
neunzehn gleichnamige Organisationen.
Deshalb hier:
- In
server/ui/src/api.tssteht der einzigefetchund genau eine Fehlerklasse. - In
store.tsstehtrun(): Aktion rein, Erfolgstext rein — es meldet bei Erfolg diesen und bei Fehlschlag den Text des Dienstes. Wer darüber geht, kann keinen stillen Knopf bauen. - Jeder wartende Knopf ist gesperrt und zeigt einen Kreisel.
- Fehlermeldungen bleiben stehen, bis jemand sie wegklickt.
- Der Dienst hat eine Auffanglinie (
app.onError): auch ein unerwarteter Fehler bekommt einen Satz statt eines nacktenInternal Server Error.
Betrieb
Sicherung
tools/sichern.ps1, täglich 04:30 als geplante Aufgabe.
Die Datenbank wird nicht kopiert, sondern über SQLites eigene
Sicherungsschnittstelle herausgeholt — im WAL-Modus liegt das Zuletzte noch
nicht in media.db. Die Bilder kommen aus einem nur lesend eingehängten
Volume dazu, alles in ein tar.gz.
Und sie prüft sich selbst: auspacken, Datenbank öffnen, Medien, Token und
Benutzer zählen, mit dem laufenden Dienst vergleichen. Danach geht sie per
WebDAV in die Nextcloud und wird von dort zurückgeholt und die Prüfsumme
verglichen — ein PUT, der 201 sagt, hat nichts bewiesen.
Zugangsdaten und Aufbewahrung stehen im Panel unter Einstellungen.
Wiki
pwsh -File tools\wiki.ps1
Trägt docs/*.md ins Gitea-Wiki. Einseitig — docs/ ist die Quelle, das
Wiki die Kopie. Wer dort tippt, verliert es beim nächsten Lauf.
Zurückspielen
tar xzf d4rk_media-JJJJ-MM-TT-HHMM.tar.gz
Ergibt media.db und files/. Beides ins Volume legen, während der Container
steht. Die Vorschaubilder sind nicht im Archiv — sie lassen sich mit einem
Knopf unter Speicher neu rechnen.
Was hier bewusst fehlt
Logging. Genau dafür schleppt Fivemanage ClickHouse mit, und genau da ist der Wartungsaufwand echt. Der Verlauf im Dashboard beantwortet „wer war das" — mehr braucht es hier nicht.
Mandanten, Rollen, Teams. Ein Dienst, den eine Person betreibt.
Automatisches Löschen. Vorbereitet ist der Bericht davor: wie viel ist älter als 7/30/90/365 Tage, was liegt doppelt. Eine Regel zu bauen, bevor man weiß, was da liegt, ist der Weg, wie man Daten verliert.
Spielerportal. Setzt voraus, dass Spieler hochladen. Der richtige Weg wäre
dann presigned URLs — kurzlebige signierte Adressen, mit denen ein Client
hochlädt, ohne je einen Token zu sehen.
Zwei Dinge, die Zeit gekostet haben
Der Proxy hielt Bilder fest. NPMs assets.conf greift über eine Regex auf
jede URL, die auf .webp, .png, .js, .css endet, legt die Antwort 30
Minuten weg und ignoriert dabei unsere Kopfzeilen. Ein überschriebenes Bild
blieb damit eine halbe Stunde alt — und /api/exists/…webp wurde
zwischengespeichert und danach auch ohne Token ausgeliefert.
Behoben mit drei Blöcken in der Custom Nginx Configuration des Proxy-Hosts:
location ^~ /api/ { proxy_cache off; include conf.d/include/proxy.conf; }
location ^~ /f/ { proxy_cache off; include conf.d/include/proxy.conf; }
location ^~ /t/ { proxy_cache off; include conf.d/include/proxy.conf; }
Das ^~ ist der ganze Trick: eine gewöhnliche Präfix-Regel verliert gegen
die Regex. In einem Wegwerf-Nginx nachgemessen.
Node 22 ist festgenagelt. better-sqlite3 11.10.0 liefert fertige
Binärdateien für ABI 115 (Node 20) und 127 (Node 22) — Node 24 hat ABI 137
und fehlt. Der Griff zur neuesten Version fällt auf node-gyp zurück und
braucht python3, make und g++ im Abbild.
Herkunft
Der Vorgänger war Fivemanage Lite mit PostgreSQL, MinIO und ClickHouse. Der
Stack lief; woran er gescheitert ist, steht oben unter Die eine Regel und
ausführlich in ROADMAP.md. Von dem, was er über eine Dateiablage hinaus kann,
haben wir nichts gebraucht und alles mitgeschleppt.
Seine Compose-Dateien liegen in legacy/, als Beleg und wegen der Kommentare —
nichts davon wird noch gestartet.