D4rkst3r/d4rk_media
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: /status fuer die Statusseite -- und der Fehler, den es dabei gefunden hat

Browse Source 
/health gab es und bleibt, wie es ist: app.get('/health', c => c.json({ok:true})).
Diese Zeile beweist genau eines -- der Prozess nimmt Anfragen an. Daran haengt
der HEALTHCHECK des Containers, und DORT ist billig richtig: eine schwere
Pruefung, die bei einer langsamen Platte einmal ausfaellt, liesse Docker den
Container neu starten, also genau dann, wenn er unter Last steht.

Fuer eine Statusseite ist das zu duenn -- sie stuende auf Gruen, waehrend die
Platte voll ist und kein Upload mehr angenommen wird.

/status sieht deshalb wirklich nach: Datenbank (eine echte Abfrage, nicht "die
Datei ist da"), Platte (schreiben UND wieder loeschen, der einzige Beweis),
Ausliefern (eine zufaellige Datei aus der Datenbank auf der Platte nachmessen),
Bestand, Platz und Sicherung. 200 wenn der Dienst sein Geschaeft tut, 503 wenn
nicht; ?streng=1 laesst auch eine Beeintraechtigung rot werden -- WELCHES von
beiden richtig ist, weiss nur, wer die Statusseite betreibt.

Oeffentlich, aber wortkarg: keine Dateizahlen, Groessen, Pfade, Tokennamen,
Benutzer. Und mit einer Zehn-Sekunden-Bremse -- ein oeffentlicher Endpunkt, der
auf die Platte schreibt, waere sonst ein Verstaerker.

UND DABEI FIEL EIN FEHLER IN MEINEM EIGENEN ZURUECKSPIEL-SKRIPT AUF.

Der harte Weg sollte an einem Wegwerf-Container geprueft werden. Der traf
zufaellig auf ein GEBRAUCHTES Volume, und die Zahlen waren eindeutig:

    media.db aus dem Archiv, mit altem WAL daneben :     0 Zeilen
    dieselbe Datei ohne die beiden Begleiter       :  4452 Zeilen
    Dateien auf der Platte                        :  4452

zurueckspielen.ps1 entfernte media.db, aber NICHT media.db-wal und
media.db-shm. Die liegen bei einem echten Zurueckspielen immer da -- der
laufende Dienst arbeitet im WAL-Modus. SQLite spielt das WAL der ALTEN
Datenbank ueber die NEUE, und heraus kommt der schlimmste denkbare Zustand: der
Dienst kommt hoch, /health ist gruen, die Mediathek ist leer, waehrend alle
Dateien danebenliegen.

Drei Konsequenzen:

1. Die Aufraeumzeile steht jetzt an EINER Stelle und nimmt media.db-wal,
   media.db-shm und *.tmp mit. Uebung und Ernstfall fahren denselben Befehl --
   zwei Fassungen waeren zwei, von denen die geuebte die harmlosere ist.

2. Die Uebung TAEUSCHT JETZT EINE BESTEHENDE INSTALLATION VOR, bevor sie
   zurueckspielt: Container starten, warten bis media.db-wal daliegt, stoppen,
   und erst dann einspielen. In ein leeres Volume zu spielen probt den Fall,
   der nie eintritt.

3. /status erkennt den Zustand selbst -- "kein Eintrag in der Datenbank, aber
   Dateien auf der Platte". Am kaputten Container gemessen:

       /health sagt:  HTTP 200
       /status sagt:  HTTP 503

Der geuebte Lauf danach, ueber eine vorgetaeuschte Installation:

    im Volume liegt jetzt: files media.db media.db-shm media.db-wal
    4452 Medieneintraege, 4452 Dateien -- gleich viele
    ok  items/shushi.png · items/weedbud_1.png · items/cc-castella.png
    Die Uebung ist bestanden.

Gefunden beim Ueben und nicht im Ernstfall. Genau dafuer gibt es sie.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
D4rkst3r
2026-08-12 00:04:26 +02:00
co-authored by Claude Opus 5
parent 338f8e59cf
commit 3f706b27e1
6 changed files with 469 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
tools/zurueckspielen.ps1
+56 -4
View File
@@ -35,6 +35,32 @@ param(
$ErrorActionPreference = 'Stop'
# WAS BEIM ZURUECKSPIELEN WEG MUSS -- an EINER Stelle, weil die Uebung genau
# denselben Befehl fahren soll wie der Ernstfall. Zwei Fassungen waeren zwei,
# von denen die geuebte die harmlosere ist.
#
# media.db-wal UND media.db-shm STEHEN HIER MIT ABSICHT, und das ist teuer
# gelernt: SQLite laeuft in diesem Dienst im WAL-Modus, neben der Datenbank
# liegen also immer zwei Begleitdateien. Die Sicherung enthaelt sie NICHT --
# sie braucht sie auch nicht, `db.backup()` schreibt eine fertig
# zusammengefuehrte Datei.
#
# Wer beim Zurueckspielen nur media.db ersetzt, laesst damit das WAL der ALTEN
# Datenbank neben der NEUEN liegen. SQLite spielt es beim Oeffnen ein, und das
# Ergebnis ist das Schlimmste, was hier passieren kann:
#
# media.db aus dem Archiv, mit altem WAL daneben : 0 Zeilen
# dieselbe Datei ohne die beiden Begleiter : 4452 Zeilen
# Dateien auf der Platte : 4452
#
# Der Dienst kaeme HOCH, /health waere gruen, und die Mediathek waere leer --
# waehrend alle Dateien danebenliegen. Nachgemessen am 12.08.2026, gefunden
# beim Ueben und nicht im Ernstfall. Genau dafuer gibt es die Uebung.
#
# .tmp ebenfalls: writeFileAtomic legt Zwischendateien an, und ein Absturz
# mitten im Schreiben laesst eine liegen.
$script:AUFRAEUMEN = 'rm -rf files media.db media.db-wal media.db-shm papierkorb thumbs webp *.tmp'
function Schritt($t) { Write-Host "==> $t" -ForegroundColor Cyan }
function Gut($t) { Write-Host " $t" -ForegroundColor Green }
function Schlecht($t) { Write-Host " $t" -ForegroundColor Red }
@@ -103,12 +129,37 @@ if (-not $Echt) {
docker volume rm $pVolume 2>&1 | Out-Null
try {
Schritt 'Wegwerf-Volume anlegen und Archiv hineinspielen'
Schritt 'Wegwerf-Volume anlegen'
docker volume create $pVolume | Out-Null
# ------------------------------------------------------------------
# ERST EINE BESTEHENDE INSTALLATION VORTAEUSCHEN, und das ist der
# Kern der Uebung: im Ernstfall wird ueber etwas zurueckgespielt, das
# schon da ist -- mit einer laufenden Datenbank, mit media.db-wal
# daneben, mit Vorschauen. In ein LEERES Volume zu spielen probt genau
# den Fall, der nie eintritt.
#
# Dass das ein Unterschied ist, ist nicht theoretisch: die erste
# Fassung dieses Skripts liess media.db-wal stehen, und der Dienst kam
# danach mit einer LEEREN Mediathek hoch, waehrend alle Dateien
# danebenlagen. Aufgefallen ist es nur, weil ein Uebungslauf zufaellig
# auf ein gebrauchtes Volume traf.
Schritt 'Eine bestehende Installation vortaeuschen (damit die Uebung eine ist)'
docker run -d --name "$pContainer-alt" `
-e PUBLIC_URL=http://probe.invalid -e ADMIN_PASSWORD=nur-fuer-die-uebung `
-v "${pVolume}:/data" $Abbild | Out-Null
Start-Sleep -Seconds 4
docker stop "$pContainer-alt" 2>&1 | Out-Null
docker rm "$pContainer-alt" 2>&1 | Out-Null
$begleiter = docker run --rm -v "${pVolume}:/data" --entrypoint sh $Abbild `
-c "ls /data | tr '\n' ' '"
Gut "im Volume liegt jetzt: $($begleiter.Trim())"
Schritt 'Zurueckspielen -- mit DEMSELBEN Befehl wie der Ernstfall'
docker run --rm -v "${pVolume}:/data" -v "${archivOrdner}:/in:ro" `
--entrypoint sh $Abbild -c "cd /data && tar xzf '/in/$archivDatei' && chown -R node:node /data"
--entrypoint sh $Abbild -c "cd /data && $script:AUFRAEUMEN && tar xzf '/in/$archivDatei' && chown -R node:node /data"
if ($LASTEXITCODE -ne 0) { throw 'Auspacken fehlgeschlagen' }
Gut 'ausgepackt'
Gut 'eingespielt'
Schritt 'Einen zweiten Dienst davorhaengen (ohne Port nach aussen)'
# KEIN veroeffentlichter Port: der Uebungslauf soll sich mit nichts
@@ -201,6 +252,7 @@ const zeilen = db.prepare('SELECT path, sha256, size FROM media ORDER BY RANDOM(
# Aufraeumen IMMER -- auch nach einem Abbruch. Ein liegengebliebenes
# Uebungs-Volume mit 300 MB findet sonst niemand wieder.
Schritt 'Aufraeumen'
docker rm -f "$pContainer-alt" 2>&1 | Out-Null
docker rm -f $pContainer 2>&1 | Out-Null
docker volume rm $pVolume 2>&1 | Out-Null
Gut 'Wegwerf-Volume und Probe-Container entfernt'
@@ -241,7 +293,7 @@ try {
# In EINEM Container-Aufruf: zwischen Loeschen und Einspielen darf nichts
# liegen, in dem jemand den Dienst wieder startet.
docker run --rm -v "${Volume}:/data" -v "${archivOrdner}:/in:ro" --entrypoint sh $Abbild `
-c "cd /data && rm -rf files media.db papierkorb thumbs webp && tar xzf '/in/$archivDatei' && chown -R node:node /data"
-c "cd /data && $script:AUFRAEUMEN && tar xzf '/in/$archivDatei' && chown -R node:node /data"
if ($LASTEXITCODE -ne 0) { throw 'Einspielen fehlgeschlagen' }
Gut 'eingespielt'
} catch {