Files
d4rk_media/docs/ideen.md
T
D4rkst3randClaude Opus 5 6bd1c7a55e docs: Richtigstellung -- "drei Orte" sind zwei Platten, und keiner ist auswaerts
Nachgemessen, nachdem die Frage aufkam, wie Sicherungen aus dem Haus kommen.
Das Ergebnis widerspricht dem, was ich heute frueh selbst hier eingetragen habe.

ALLE Docker-Volumes liegen in einer einzigen Datei:

    C:\Users\Darkster\AppData\Local\Docker\wsl\disk\docker_data.vhdx   51,5 GB

Das ist Platte 0. Darin: die Daten von d4rk_media, die Datenbank des Bots UND
DIE NEXTCLOUD. cdn.d4rkst3r.de und media.d4rkst3r.de loesen beide auf
88.218.224.10 auf, und die vierzehn nextcloud-aio-Container laufen auf genau
dieser Maschine.

    C:\backup\d4rk_media   Platte 0   dieselbe wie die Daten
    D:\backup\d4rk_media   Platte 1   echt getrennt
    Nextcloud              Platte 0   dieselbe wie die Daten

Die Nextcloud-Kopie stand hier als "die einzige Trennung". Sie ist in Wahrheit
die am WENIGSTEN getrennte von allen dreien -- und der Grund fuer den Irrtum ist
der uebliche: eine Adresse mit eigenem Namen und eigenem Zertifikat SIEHT wie
ein anderer Ort aus. Nachgesehen hatte das niemand.

Was die drei Ziele wirklich abdecken: eine Platte stirbt -> D: faengt es auf,
das war den Aufwand wert. Rechner tot, Feuer, Diebstahl, Verschluesselung ->
alle drei Kopien sind gleichzeitig weg.

"sicherung ok an 3 Orten" auf der Statusseite bleibt woertlich richtig -- sie
zaehlt Ablageorte, nicht Platten und nicht Gebaeude. Wer daraus "also sicher"
liest, liest mehr hinein als dasteht.

In docs/ideen.md steht das Thema wieder offen, mit den Kandidaten und der
Eigenschaft, auf die es dabei ankommt: HOLEN statt SCHICKEN. Ein Ziel, in das
der Server selbst schreiben darf, ist auch eines, das ein uebernommener Server
loeschen kann.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-12 15:27:36 +02:00

9.7 KiB
Raw Blame History

Was noch ginge

Stand 12.08.2026. Diese Liste ist nicht eine Sammlung von allem, was denkbar wäre — sie ist das, was beim Bauen und Messen wirklich aufgefallen ist. Was hier steht, hat einen Grund; was keinen hatte, steht am Ende unter „Verworfen, mit Begründung".

Sortiert nach dem, was ich zuerst täte.


1 · Sicher wertvoll

Die Oberfläche auf dem Telefon — abgelehnt am 12.08.2026

Vom Betreiber verworfen: das Dashboard wird nicht mobil benutzt. Der Rest des Abschnitts bleibt stehen, damit die Messung nicht verlorengeht, falls sich das je ändert.

Gemessen: 18 Umbruchpunkte (sm:/lg:/xl:) im ganzen Frontend. Die Galerie ist ein Raster und passt sich an — die vier Tabellen in Verlauf, Token, Konten und Papierkorb nicht. Auf einem Telefon laufen sie seitlich heraus.

Der Umbau ist keine Kosmetik: Karten statt Tabellenzeilen unterhalb einer Breite, so wie es die Galerie schon macht. Betrifft vier Dateien.

Lohnt sich nur, wenn du das Dashboard mobil aufmachst. Sonst ist es Arbeit für einen Bildschirm, den niemand benutzt.

Sitzungen beenden können

Gemessen: 86 offene Sitzungen, davon 82 von admin — meine Testanmeldungen von heute. Sie laufen nach 30 Tagen aus, und pruneSessions räumt stündlich die abgelaufenen weg. Was fehlt, ist ein Knopf „alle anderen Sitzungen beenden" im Kontomenü.

Das ist mehr als Ordnung: wer sich an einem fremden Rechner angemeldet hat und es später merkt, hat heute keine Möglichkeit, das zurückzunehmen — außer das Passwort zu ändern und zu hoffen, dass das die Sitzungen mitnimmt (tut es nicht, sie hängen an einer eigenen Tabelle).

Was der Verlauf nicht sieht

Gemessen: events kennt upload, replace, delete, move, rename — alles über Dateien. Nichts über Einstellungen. Wer den Discord-Webhook geändert hat, wer einen Token angelegt oder gelöscht hat, wer ein Konto entfernt hat: steht nirgends.

Bei zwei Konten ist das verschmerzbar. Sobald ein drittes dazukommt — und über die Discord-Rolle entsteht es von selbst — ist es die erste Frage, die man stellt, wenn etwas anders ist als gestern.


2 · Nützlich, wenn der Fall eintritt

Massen-Umbenennen

Suchen und Ersetzen über Pfade, mit Vorschau vor dem Zuschlagen. Bei 3578 Items ist eine Umbenennung von Hand keine.

Der Anlass wäre etwa: items/ nach inventar/ verschieben, oder eine Namenskonvention ändern. Heute geht das nur Datei für Datei oder gar nicht.

Die Warnung wäre dieselbe wie beim Ordner-Umbenennen — jede alte Adresse gibt danach 404 —, nur mal tausend.

Bilder beim Ablegen verkleinern

Eine Obergrenze für die Kantenlänge, einstellbar je Token. Wer ein 6000 × 4000 großes Foto hochlädt, bekommt es auf, sagen wir, 2048 gerechnet.

Gemessen und deshalb keine Dringlichkeit: ein 12000 × 12000 großes PNG hat den Dienst nicht in Verlegenheit gebracht — Vorschau in 374 ms, Speicher bei 47 MB von 31 GB. libvips arbeitet kachelweise und dekodiert nie das ganze Bild. Es geht also um Plattenplatz und Ladezeit beim Ausliefern, nicht um Stabilität.

Fehlende Bilder finden

Eine Liste hereinreichen (Fahrzeugmodelle, Item-Namen) und beantwortet bekommen: wozu fehlt ein Bild? Heute beantwortet das niemand — das Fotostudio weiß, was es aufgenommen hat, der Dienst weiß, was liegt, und die Differenz rechnet niemand aus.

Das wäre ein Endpunkt, der eine Liste entgegennimmt und die fehlenden zurückgibt. Klein, und die Antwort auf „warum zeigt das Handy bei manchen Autos kein Bild".

Einstellungen aus- und einlesen

Discord-Zugang, Sicherungsziel, Vorlagen, Meldungsanlässe — alles steht in settings und ist beim Neuaufsetzen von Hand nachzutragen. Ein Export als JSON (ohne die Geheimnisse, oder mit einer ausdrücklichen Ansage) macht aus einer Stunde Klickerei fünf Minuten.


3 · Wäre schön, drängt nicht

Verlauf als CSV — gebaut am 12.08.2026

GET /api/dash/verlauf/export, wahlweise ?was=verwaltung. Der Knopf sitzt in der Reiterleiste und holt den Verlauf, der gerade offen ist — zwei Knöpfe nebeneinander wären die Frage „welchen von beiden?" an einer Stelle, wo die Antwort schon auf dem Bildschirm steht.

Semikolon und CRLF wie beim Bestands-Export, und aus demselben Grund: Excel in deutscher Einstellung nimmt bei Komma alles in eine Spalte und bei nacktem LF die halbe Datei in eine Zelle. Gemessen an der ausgelieferten Datei: 5364 Zeilen, 5364 CRLF, kein einziges nacktes LF.

Meldung bei Upload — gebaut am 12.08.2026

Mit Drossel, und die ist der eigentliche Inhalt. Jeder Upload schiebt eine Frist von zwei Minuten nach hinten; erst nach der Ruhe geht eine Nachricht raus, mit Anzahl, Summe, Absendern und den ersten fünf Pfaden.

Ohne das wäre die Funktion ein Schaden statt eines Nutzens: 900 Fahrzeugbilder ergäben 900 Nachrichten, Discord drosselt Webhooks, und wer danach eine echte Meldung bekommt, sieht sie nicht mehr. Ein Serienlauf ergibt jetzt eine Zeile, ein einzelnes Bildschirmfoto ergibt eine Zeile — beide sagen dasselbe, nur mit anderen Zahlen.

Der Anlass heißt upload und ist abschaltbar wie die anderen drei. Die Liste steht an zwei Stellen (Server und Oberfläche) — genau die Verdopplung, die bei platte schon einmal ein Kreuzchen verschluckt hat; deshalb steht jetzt in beiden ein Verweis auf die andere. Nachgemessen: vier geschickt, vier gespeichert.

Papierkorb mit Größendeckel — gebaut am 12.08.2026

20 GB. Beim Ausleeren wird erst nach Alter geräumt (30 Tage) und dann nach Größe, das Älteste zuerst — dessen Versehen wäre am ehesten schon aufgefallen. Die Grenze steht in der Antwort von /api/dash/papierkorb, damit die Oberfläche sie nicht ein zweites Mal hinschreibt.

Bei 910 GB frei ist das heute keine Grenze, sondern eine Zusicherung: der Papierkorb kann nicht mehr unbemerkt zur zweiten Ablage werden.

Ein Ziel AUSSERHALB dieser Maschine — offen

Nachgemessen am 12.08.2026: es verlässt heute nichts diesen Rechner. Auch die Nextcloud nicht — sie läuft hier, in denselben Docker-Volumes, auf derselben Platte 0 wie die Daten. Details in der ROADMAP.

Gegen einen Plattenausfall ist gesorgt (D: ist eine eigene NVMe). Gegen Feuer, Diebstahl oder eine verschlüsselte Maschine ist es nicht.

Kandidaten, mit dem, was sie wirklich können:

Weg deckt ab Haken
Private PC holt ab (robocopy/rsync vom PC aus) Rechner tot, Server kompromittiert PC muss laufen, wenn geholt wird
5-TB-Platte am Router Rechner tot gleiches Haus; der Server darf schreiben, also erreicht Ransomware sie auch
5-TB-Platte am Server Plattenausfall dritte Platte im selben Gehäuse, kein Gewinn gegen Feuer
Discord-Kanal (nur der Bot, 993 KB/Tag) Haus tot 9 MB je Datei — für d4rk_media mit 336 MB unbrauchbar

Die Eigenschaft, auf die es ankommt, ist HOLEN statt SCHICKEN. Ein Ziel, in das der Server selbst schreiben darf, ist auch ein Ziel, das ein übernommener Server löschen kann. Wer die Sicherung vom anderen Ende abholt, hält keine Zugangsdaten auf der Maschine, die geschützt werden soll.


Mehrere Sicherungsziele — gebaut am 12.08.2026

Ein zweites Laufwerk, einstellbar im Panel unter Einstellungen → Sicherung. Damit liegt jedes Archiv an drei Orten: C:ackup, das zweite Laufwerk und die Nextcloud.

Die drei sind nicht dreimal dasselbe. Die Nextcloud hilft, wenn der ganze Rechner weg ist — aber wer 335 MB (oder später 100 GB) zurückholen muss, lädt sie über die Leitung. Das zweite Laufwerk ist in Minuten zurückgespielt.

Und es warnt, wenn es dieselbe Platte ist. Das ist der eigentliche Inhalt: ein zweiter Ordner auf C: sieht im Panel genauso grün aus wie eine echte zweite Platte und hilft gegen gar nichts. Verglichen wird die physische Platte, nicht der Laufwerksbuchstabe — zwei Partitionen derselben NVMe sterben zusammen. Nachgemessen in beide Richtungen: C: gegen D: ergibt Nr. 0 gegen Nr. 1 und ein „andere Platte"; C: gegen C: ergibt zweimal Nr. 0 und die Warnung.

Ein echter Lauf: 4630 Einträge, 335,9 MB, auf beiden Zielen die Prüfsumme FFCE4D0A7310… — identisch. Die Statusseite sagt seitdem sicherung ok an 3 Orten statt nur ok.


Verworfen, mit Begründung

Diese standen auf der Liste und sind gemessen wieder heruntergefallen. Sie stehen hier, damit sie nicht beim nächsten Mal wieder aufschlagen.

Idee Warum nicht
Doppelte Dateien zusammenführen 5 Gruppen, 0,0 MB verschwendet. Es gibt nichts zu holen.
Aufräumen nach Alter Alle vier Altersstufen im Bericht stehen auf 0 Dateien. Es ist nichts alt.
Grenze für Bildmaße als Schutz 12000 × 12000 → 374 ms, 47 MB. libvips streamt, die Gefahr gibt es nicht.
Plattenplatz-Wächter Gebaut. 80/90/95 %, meldet nach Discord.
Kontingent je Token Gebaut, auf beiden Upload-Wegen geprüft.
Eigene Statusseite bauen /status reicht — der d4rkbot zeigt sie schon an.

Und was heute noch schnell repariert wurde

pruneEvents lief nie von selbst. Die Funktion gibt es seit dem ersten Tag und sie räumt Ereignisse älter als 180 Tage weg — aufgerufen wurde sie aber nur von /maintenance/prune-sessions, einem Weg, den nicht einmal die Oberfläche anbietet. Die dokumentierte Aufbewahrung griff damit nie, und die Tabelle wuchs für immer.

Zum Vergleich: pruneSessions hängt seit jeher an einem stündlichen Takt. Das eine war verdrahtet, das andere nicht, und der Unterschied fiel niemandem auf, weil beide in derselben Zeile stehen.

Gemessen: nach einem Tag mit Umzug und Serienlauf standen 5355 Zeilen in events. Läuft jetzt täglich, mit zwei Minuten Verzögerung nach dem Start.