9e4132cc7e7ea6064c52005148f1bc030c9c22d7
7
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  D4rkst3randClaude Opus 5
|
ab93e0ae4e |
feat: die Archive lassen sich aus dem Panel holen
Einstellungen -> "Sicherungen holen": die fertigen Archive mit Datum, Groesse
und einem Knopf. Der erste Schritt, der eine Kopie VON DIESEM RECHNER HERUNTER
bringt -- bisher haette man sich dafuer per Fernwartung auf den Server klicken
muessen, und genau daran hat es gelegen. Nicht Unwille, sondern
Umstaendlichkeit.
Der Ordner haengt NUR LESEND in den Container. Ein Dienst, der seine eigenen
Sicherungen loeschen kann, ist genau das Werkzeug, das man einem uebernommenen
Dienst nicht in die Hand geben will. Nachgemessen im Container:
touch /sicherungen/probe -> Read-only file system
Und es gibt NUR EINE FORM VON NAMEN -- nicht "alles ausser .. und /", sondern
ein Muster, das genau auf die eigenen Archive passt. Wer einen Pfad
hineinschmuggeln will, muesste ihn erst so benennen. Das ist der Unterschied
zwischen dicht gemacht und dicht gebaut:
../../etc/passwd -> 404
..%2f..%2fdata%2fmedia.db -> 400
media.db -> 400
<archiv>.tar.gz.evil -> 400
ohne Anmeldung -> 401
Der ganze Weg einmal wirklich gegangen, nicht nur die Kopfzeilen: 336 MB in
15,9 s durch den Proxy, sha256 auf der Platte gleich sha256 heruntergeladen,
tar tzf zeigt 4639 Eintraege. Gestroemt und nicht in den Speicher gelesen --
sonst haetten Dienst UND Proxy die 336 MB gleichzeitig im Arbeitsspeicher.
Jeder Griff steht im Verwaltungs-Verlauf. Geloggt wird der GRIFF und nicht der
Erfolg: ein abgebrochener Download taucht ebenfalls auf, und das ist gewollt --
wer spaeter fragt, wer sich den Bestand geholt hat, will die Anfrage sehen.
Die fuenf neuen Pruefungen sind in tools/rundgang.py mit drin; der steht jetzt
bei 29 in Ordnung, 0 nicht.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
D4rkst3randClaude Opus 5
|
3a89acaa41 |
docs: der Server steht im Rechenzentrum -- das dreht die Bewertung um
Ich hatte "gleiches Haus" geschrieben und damit die Platte am Router als
halben Schritt abgetan. Falsch: der Rechner ist ein Windows-Root-Server im
Rechenzentrum, bedient von zu Hause ueber mRemoteNG. Ein Ziel beim Betreiber
daheim sind also zwei Gebaeude, zwei Netze, zwei Stromkreise, zwei Anbieter --
besser wird ein Sicherungsziel kaum.
Gemessen, was dafuer schon dasteht:
sshd Running, Automatic, 0.0.0.0:22 und [::]:22
Firewall "OpenSSH SSH Server (sshd)" -> Allow
sshd_config Subsystem sftp sftp-server.exe
je Nacht d4rk_media 335,9 MB + d4rkbot 0,9 MB = 336,9 MB
Auf der Serverseite fehlt nichts ausser einem Konto, das nur lesen darf. Der
Rest ist ein Skript auf dem Heimrechner, das HOLT statt zu bekommen -- ein
Ziel, in das der Server schreiben darf, ist auch eines, das ein uebernommener
Server loeschen kann.
Fund am Rande: in sshd_config steht kein PasswordAuthentication no. Der
OpenSSH-Standard ist yes -- auf Port 22, offen ins Internet, mit AllowGroups
einschliesslich administrators.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
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>
|
||
|
D4rkst3randClaude Opus 5
|
74e2128afb |
feat: die Sicherung liegt an drei Orten statt an zweien
Der letzte offene Punkt aus docs/ideen.md. Ein ZWEITES LAUFWERK, einstellbar im
Panel unter Einstellungen -> Sicherung; sichern.ps1 legt das Archiv dort ab,
vergleicht die Pruefsumme und duennt auch dort aus.
WARUM DAS NICHT DASSELBE IST WIE DIE NEXTCLOUD. Die hilft, wenn der ganze
Rechner weg ist -- aber wer 335 MB, spaeter 100 GB, zurueckholen muss, laedt sie
ueber die Leitung. Das zweite Laufwerk ist in Minuten zurueckgespielt. Zwei
Fragen, zwei Antworten, deshalb zwei Ziele.
UND ES WARNT, WENN ES DIESELBE PLATTE IST -- das ist der eigentliche Inhalt.
Ein zweiter Ordner auf C: sieht im Panel genauso gruen aus wie eine echte zweite
Platte und hilft gegen gar nichts. Verglichen wird die PHYSISCHE Platte und
nicht der Laufwerksbuchstabe: zwei Partitionen derselben NVMe sterben zusammen.
Nachgemessen in beide Richtungen:
C:\backup gegen D:\backup -> Nr. 0 gegen Nr. 1 -> "andere Platte"
C:\backup gegen C:\Users -> Nr. 0 gegen Nr. 0 -> Warnung
Auf diesem Rechner sind das zwei getrennte NVMe zu je 954 GB.
GEMESSEN AN EINEM ECHTEN LAUF, keinem Trockentest: 4630 Eintraege, 335,9 MB,
auf beiden lokalen Zielen und in der Nextcloud dieselbe Pruefsumme
FFCE4D0A7310... -- identisch.
Geprueft wird mit der Pruefsumme und nicht mit der Dateigroesse: eine
abgebrochene Kopie auf eine volle Platte hat oft genau die richtige Laenge und
trotzdem Nullen am Ende. Schlaegt das Kopieren oder der Vergleich fehl, ist der
ganze Lauf gescheitert (exit 1, ok:false) -- ein Ziel, das still ausfaellt, ist
genau das, wogegen das hier gebaut ist.
Der Bericht traegt jetzt zweit:true. Fehlt das Feld, ist KEIN zweites Ziel
eingerichtet -- es steht absichtlich nicht als false da, denn das laese sich wie
"hat nicht geklappt".
Die Statusseite zaehlt die Orte mit: "sicherung ok an 3 Orten" statt nur "ok".
Eine Sicherung, die es nur einmal gibt, ist gruen und trotzdem eine, die ein
Plattenausfall mitnimmt -- das gehoert dorthin, wo jemand hinsieht.
Der Pfad wird beim Speichern auf seine FORM geprueft (Laufwerksbuchstabe oder
UNC-Freigabe): der Dienst laeuft im Container und kann ihn nicht nachschlagen,
aber ein relativer Pfad ist mit Sicherheit ein Tippfehler -- und ein Tippfehler
in einem Sicherungsziel faellt sonst erst auf, wenn man die Sicherung braucht.
Nachgemessen: "backup/woauchimmer" -> 400 mit Text.
Und zurueckspielen.ps1 sagt im Kopf, was zu tippen ist, wenn genau diese Platte
das Problem ist. Das ist der Fall, fuer den das Ganze da ist, und niemand soll
ihn um vier Uhr nachts erst herleiten muessen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
D4rkst3randClaude Opus 5
|
bbb74138c8 |
feat: Verlauf als CSV, Meldung bei Upload mit Drossel, Deckel auf dem Papierkorb
Abschnitt 3 aus docs/ideen.md, bis auf die Sicherungsziele. VERLAUF ALS CSV. Der Export konnte nur den Bestand; wer nachrechnen wollte, was ueber einen Zeitraum passiert ist, sass vor einer Tabelle, die nach 500 Zeilen umblaettert. Der Knopf sitzt in der Reiterleiste und holt den Verlauf, DER GERADE OFFEN IST -- zwei Knoepfe nebeneinander waeren die Frage "welchen von beiden?" an einer Stelle, wo die Antwort schon auf dem Bildschirm steht. Semikolon und CRLF wie beim Bestands-Export; das war dort nachgemessen worden. Gemessen an der ausgelieferten Datei: 5371 Zeilen, kein einziges nacktes LF. Ohne Anmeldung 401 -- die Route liegt hinter dem Waechter, was nach dem Sitzungs-Fehler von vorgestern ausdruecklich nachgeprueft wurde. MELDUNG BEI UPLOAD -- die Drossel ist der eigentliche Inhalt. Jeder Upload schiebt eine Frist von zwei Minuten nach hinten; erst nach der Ruhe geht EINE Nachricht raus. Ohne das waere die Funktion ein Schaden: 900 Fahrzeugbilder ergaeben 900 Nachrichten, Discord drosselt Webhooks, und wer danach eine echte Meldung bekommt, sieht sie nicht mehr. Gemessen: drei Uploads mit zehn Sekunden Abstand -> eine Meldung ueber drei Dateien. Ein einzelner Upload -> eine Meldung ueber eine Datei. Nur Token-Uploads, absichtlich. Was ueber das Dashboard hereinkommt, hat gerade jemand selbst hochgeladen und bestaetigt bekommen. Zurueckholen aus dem Papierkorb meldet gar nichts: das ist kein Neues, das ist ein Wiedergefundenes. Und derselbe Fehler wie bei 'platte' lauerte schon wieder: die Liste der Anlaesse steht im Server UND in der Oberflaeche, und der Server verwirft beim Speichern alles, was in seiner Liste fehlt -- ein Kreuzchen, das sich setzen laesst und beim naechsten Laden weg ist. Diesmal beide angefasst, in beiden steht jetzt ein Verweis auf die andere. Nachgemessen: vier geschickt, vier gespeichert. DECKEL AUF DEM PAPIERKORB. 30 Tage UND 20 GB, was zuerst greift. Wer 200 GB loescht, haelt sie sonst 30 Tage doppelt und merkt es erst, wenn die Platte voll ist. Geraeumt wird das AELTESTE zuerst -- dessen Versehen waere am ehesten schon aufgefallen. Ueber PAPIERKORB_MAX_MB verstellbar, und das nicht aus Bequemlichkeit: ein Deckel von 20 GB laesst sich nicht pruefen, ohne 20 GB zu loeschen. Mit 0.0002 MB nachgemessen -- vier Eintraege zu 422 Bytes, drei entfernt, uebrig blieb der NEUESTE. Danach zurueck auf 20 GB, gemessen 21474836480. NEBENBEI, DREIMAL DIESELBE SORTE FEHLER: "0.0 MB" fuer 422 Bytes, "0 KB" fuer 106 Bytes, "0.0 MB von 0.0 MB" beim Deckel. Es gab drei Byte-Formatierer, jeder mit anderer Untergrenze. Jetzt einer in meldung.ts, von Bytes bis GB, exportiert und von dash.ts mitbenutzt. Nachgemessen ueber alle Stufen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
D4rkst3randClaude Opus 5
|
29e516559a |
feat: Sitzungen beenden, Verwaltungs-Verlauf -- und ein Kaestchen, das log
DER FEHLER ZUERST, denn er ist meiner von gestern: die Liste der
Meldungsanlaesse stand ZWEIMAL da -- als Standard in meldung.ts und noch einmal
als Weissliste beim Speichern in dash.ts. Beim Einbau des Plattenwaechters habe
ich nur die erste angefasst.
Ergebnis: das Kaestchen "Der Platz auf der Platte wird knapp" liess sich
ankreuzen, der Server warf den Wert beim Speichern weg, und beim naechsten
Laden war es wieder aus. Ohne ein Wort dazu. Nachgemessen am laufenden Dienst:
geschickt ["sicherung","verwaiste","platte"]
gespeichert ["sicherung","verwaiste"]
Die Liste steht jetzt an EINER Stelle (ANLAESSE in meldung.ts) und wird von
beiden benutzt. Gegengeprueft: alle drei kommen an.
SITZUNGEN BEENDEN. Wer sich an einem fremden Rechner angemeldet hat und es
spaeter merkt, hatte keine Moeglichkeit das zurueckzunehmen -- ein geaendertes
Passwort half nicht, die Sitzungen haengen an einer eigenen Tabelle und
ueberleben es. Der Knopf steht im Kontomenue und nur dann, wenn es ueberhaupt
eine zweite Sitzung gibt. Gemessen: 87 offen, 86 beendet, meine lebt.
Dabei in die eigene Falle getreten: der Weg lag zuerst bei den anderen
/auth-Wegen -- und die stehen mit Absicht VOR der Wache, weil man sich anmelden
koennen muss, ohne angemeldet zu sein. Dort ist c.get('user') leer, und der Weg
antwortete mit "Cannot read properties of undefined". Hono setzt Middleware und
Handler in der Reihenfolge ihrer Anmeldung zusammen; der Pfad sagt darueber
nichts.
VERWALTUNGS-VERLAUF. Der Datei-Verlauf beantwortet "was ist mit den Dateien
passiert". Wer den Discord-Webhook geaendert, einen Token angelegt oder ein
Konto entfernt hat, stand nirgends. Bei zwei Konten verschmerzbar -- sobald ein
drittes ueber die Discord-Rolle von selbst entsteht, ist es die erste Frage.
Eigene Tabelle und nicht events: dort traegt jede Zeile path und size, und eine
Einstellungsaenderung muesste path mit etwas fuellen, das kein Pfad ist.
WERTE STEHEN DORT NIE, nur Schluesselnamen. Unter den Einstellungen liegen das
Discord-Geheimnis und das Nextcloud-Passwort; ein Verlauf, der sie mitschreibt,
macht aus einer Tabelle mit einem Passwort eine Tabelle mit allen, die es je
gab.
Beim Einbau derselbe Fehlertyp wie gestern beim SVG: im SQL-Kommentar standen
Backticks, und das Schema liegt in einem Template-Literal -- ein Backtick
beendet es. Der Uebersetzer hat es gefangen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
D4rkst3randClaude Opus 5
|
a91c4261de |
fix: pruneEvents lief nie von selbst -- und eine Liste, was noch ginge
DIE FUNKTION GIBT ES SEIT DEM ERSTEN TAG und sie raeumt Ereignisse aelter als 180 Tage weg. Aufgerufen wurde sie aber nur von /maintenance/prune-sessions -- einem Weg, den nicht einmal die Oberflaeche anbietet. Die dokumentierte Aufbewahrung griff damit NIE, und die Tabelle wuchs fuer immer. Zum Vergleich: pruneSessions haengt seit jeher an einem stuendlichen Takt. Das eine war verdrahtet, das andere nicht, und der Unterschied fiel niemandem auf, weil beide in derselben Zeile des Wartungswegs stehen. Gemessen: nach EINEM Tag mit Umzug und Serienlauf standen 5355 Zeilen in events. Laeuft jetzt taeglich, mit zwei Minuten Verzoegerung nach dem Start -- nicht stuendlich wie die Sitzungen, denn ein DELETE ueber ein halbes Jahr hat es nicht eilig. Dazu docs/ideen.md: was beim Bauen und Messen wirklich aufgefallen ist, nach Dringlichkeit sortiert. Mit einem eigenen Abschnitt fuer das, was gemessen wieder heruntergefallen ist -- Doppelte (0,0 MB verschwendet), Aufraeumen nach Alter (alle Stufen auf 0), eine Grenze fuer Bildmasse (12000x12000 kostet 374 ms und 47 MB, libvips streamt). Damit sie nicht beim naechsten Mal wieder aufschlagen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |