D4rkst3randClaude Opus 5
40c446f859
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>
214 lines
7.9 KiB
Markdown
214 lines
7.9 KiB
Markdown
# 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](https://git.d4rkst3r.de/D4rkst3r/d4rk_media/wiki) — Quelle ist `docs/` |
|
|
| **Stand und Reihenfolge** | `ROADMAP.md` |
|
|
| **Arbeitsweise** | `CLAUDE.md` — prüfen statt raten |
|
|
|
|
---
|
|
|
|
## Starten
|
|
|
|
```bash
|
|
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 path` nimmt 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
|
|
|
|
```bash
|
|
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. Ein **ZIP wird ausgepackt** statt abgelegt, und die Ordner
|
|
darin bleiben erhalten — 3670 Bilder einzeln ins Fenster zu ziehen ist keine
|
|
Bedienung.
|
|
|
|
**Ausliefern** — mit ETag, `304`, Bereichsanfragen und `nosniff`. Vorschaubilder
|
|
werden beim Upload erzeugt (320 px WebP): aus 7,5 MB je Galerieseite werden
|
|
766 KB.
|
|
|
|
**Sparen, ohne Adressen zu ändern** — neben jedem PNG und JPEG liegt eine
|
|
WebP-Fassung, ausgeliefert unter *derselben* Adresse je nach `Accept` des
|
|
Aufrufers. Nachgemessen über den ganzen Bestand: **199 MB → 33 MB**, das sind
|
|
83 %. Für Lua ändert sich nichts — es schickt kein `Accept: image/webp` und
|
|
bekommt weiterhin das Original.
|
|
|
|
**Zurückholen** — Gelöschtes liegt 30 Tage im Papierkorb, danach räumt der
|
|
Dienst selbst auf. Die Datei ist dann nur nicht mehr öffentlich, nicht weg.
|
|
|
|
**Zählen** — wie oft eine Datei geholt wurde und wann zuletzt. Beantwortet die
|
|
Frage, die ein Aufbewahrungsbericht sonst nicht beantworten kann: *braucht das
|
|
noch jemand?*
|
|
|
|
**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.ts` steht der **einzige** `fetch` und **genau eine**
|
|
Fehlerklasse.
|
|
- In `store.ts` steht `run()`: 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 nackten `Internal 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
|
|
|
|
```bash
|
|
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
|
|
|
|
```bash
|
|
tar xzf d4rk_media-JJJJ-MM-TT-HHMM.tar.gz
|
|
```
|
|
|
|
Ergibt `media.db` und `files/`. Beides ins Volume legen, während der Container
|
|
steht. Vorschaubilder und WebP-Fassungen sind **nicht** im Archiv — beides ist
|
|
abgeleitet und wird mit zwei Knöpfen unter *Speicher → Wartung* neu gerechnet.
|
|
Der Papierkorb ist ebenfalls nicht drin: was dort liegt, ist gelöscht.
|
|
|
|
---
|
|
|
|
## 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:
|
|
|
|
```nginx
|
|
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.
|