Der erste automatische Lauf war erfolgreich (14:20, 18 Punkte, 0
auffaellig). Zwei Nachtraege:
RECHTE
Zustandsdatei und Protokoll lagen mit 644 in einem 755-Verzeichnis.
Personenbezogene Daten stehen dort keine -- wohl aber eine
vollstaendige Liste aller Dienste, Adressen und ihres Zustands. Fuer
jemanden, der einen Angriff vorbereitet, ist das eine bequeme
Landkarte. Jetzt 700/600. Kostet nichts, also gibt es auch keinen
Grund, es herzugeben.
PROBESCHALTER
node waechter.mjs --probe
Verschickt eine Meldung, ohne dass etwas kaputt sein muss. Das ist die
einzige Moeglichkeit, den MELDEWEG zu pruefen, ohne auf eine echte
Stoerung zu warten.
Der Grund ist derselbe wie beim stillen "if (!url) return;", das diese
Reihe ausgeloest hat: Eine Ueberwachung, deren Zustellung
stillschweigend nicht funktioniert, ist schlimmer als gar keine. Man
haelt die Stille dann fuer "alles in Ordnung" -- dabei ist sie nur
Stille.
Steht bewusst VOR den Messungen: Wer den Meldeweg pruefen will, soll
nicht erst 18 Punkte abfragen muessen.
Co-Authored-By: Claude Opus 5 <[email protected]>
Der Befund war besser als der Aufgabentitel: Alle Dienste haben
Restart=always und stehen nach einem Absturz von selbst wieder auf. Die
Luecke liegt woanders:
- Dauerschleife: Startet ein Dienst und stuerzt sofort wieder ab, gibt
systemd nach wenigen Versuchen auf. Dann bleibt er unten.
- "active" heisst nicht "antwortet". Ein haengender Dienst gilt
systemd als gesund.
- Zertifikatsablauf und volle Platte machen keinen Dienst inaktiv,
legen aber alles lahm.
Geprueft werden 18 Punkte: sechs Dienste, neun Adressen, Plattenplatz,
zwei Zertifikatslaufzeiten.
WARUM ALS ROOT PER CRON
Ein Waechter, der ueber den internen Dienst meldet, hat einen
Konstruktionsfehler mit Ansage: Ausgerechnet wenn DIESER Dienst das
Problem ist, kaeme keine Meldung durch. Also liest er .env und Datenbank
selbst und verschickt selbst -- unabhaengig davon, ob noch irgendetwas
laeuft. Ohne Fremdpakete, nur Node-Bordmittel, sqlite3 und systemctl.
NUR BEI ZUSTANDSWECHSEL
Gemeldet wird, wenn etwas kippt -- in beide Richtungen. Nicht alle fuenf
Minuten dasselbe. Wer staendig Meldungen bekommt, sieht irgendwann keine
mehr an und uebersieht die eine, auf die es ankam.
ZWEI EIGENE FEHLER, DIE DER TEST GEFUNDEN HAT
1. Zuerst stand je Adresse eine handgepflegte Liste erlaubter
Antwortcodes. Der erste Lauf meldete VanVans Shop als ausgefallen --
er war es nicht, er steht ebenfalls hinter einer Zugangswand und
antwortet mit 302. Ich war damit genau in die Falle gelaufen, vor der
der Kommentar an derselben Stelle warnte.
2. Danach galt "unter 400" als heil. Jetzt meldete das Postfach einen
Ausfall, weil die geprueften Adresse 404 lieferte -- der Dienst lief
einwandfrei, ich hatte die Adresse falsch gewaehlt.
Beide Male dieselbe Lehre: Eine Ueberwachung, die bei einer falsch
getippten Adresse "Ausfall" ruft, erzieht einen dazu, ihre Meldungen zu
ignorieren. Die Regel lautet jetzt "unter 500", denn der Waechter fragt
"lebt der Dienst?", nicht "ist der Inhalt richtig?". 401, 403 und 404
BEWEISEN, dass jemand da ist und zuhoert. Nur 5xx und Schweigen heissen,
dass dahinter nichts mehr laeuft. Ausnahme sind die beiden Pflichtseiten
Impressum und Widerruf -- dort ist alles ausser 200 bereits ein Mangel.
GEPRUEFT AM SERVER
Ausfall eingebaut: erkannt und gemeldet. Ausfall dauert an: still, keine
Wiederholung. Wieder erreichbar: Entwarnung. 18 Punkte, 0 Fehlalarme
ueber mehrere Laeufe.
⚠️ GRENZE, DIE BLEIBT
Ist der Server als Ganzes weg -- Netz, Strom, Hardware --, meldet auch
dieser Waechter nichts. Dagegen hilft nur eine Ueberwachung ausserhalb
der Maschine. Steht so im Kopf der Datei, damit sich niemand in falscher
Sicherheit wiegt.
Co-Authored-By: Claude Opus 5 <[email protected]>
DogFatherGitandClaude Opus 5