D4rkst3randClaude Opus 5
6bd1c7a55e
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>
219 lines
9.7 KiB
Markdown
219 lines
9.7 KiB
Markdown
# 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.
|