Ein Host mit apt-Exit 100 stoppte die Patch-Runde der ganzen Flotte

Der Bericht endete mit failed. Das ist zuerst eine gute Nachricht: Der Lauf hat ein Ergebnis gemeldet. Die schlechte Nachricht steht hinter dieser Zeile. Ein Datei-Host hielt in der Nacht des 16. September 2026 apt-get mit Exit-Code 100 auf, 19 Pakete waren offen, davon fünf Sicherheitsupdates. Der Runner nahm das als Abbruch der ganzen Runde, nicht als Antwort für diesen einen Host. Jeder Host hinter ihm bekam an dem Abend weder Patches noch eine CVE-Prüfung. Eine Warteschlange, deren Fehlermodus „der Rest läuft nie" heißt, ist keine Warteschlange. Sie ist eine versteckte Abhängigkeit.

Was in der Nacht passierte

Der Nightly-Runner arbeitet die Flotte Host für Host ab, in fester Reihenfolge, und tut dabei zwei Dinge: patchen und CVEs prüfen. Die Reihenfolge ist kein Selbstzweck. Sie hält die Datenbank-Hosts am Anfang, wo ein Fehler am teuersten ist. Diese Entscheidung bleibt.

Aufgeschrieben hat niemand den zweiten Zweig. apt-get beendet sich mit 100, wenn es nicht durchkommt, so steht es in der Manpage. Ein Fremddepot hielt zwei Pakete zurück, der Runner bekam Exit 100 und machte daraus einen harten Abbruch. 19 Pakete blieben liegen, davon fünf mit Sicherheitsbezug. Dahinter: nichts. Kein Patch, kein Scan, keine Zeile „hier wurde gar nicht begonnen". Am Morgen stand failed im Bericht, und für das System war die Sache erledigt.

Erfolg und ungepatcht in einer Minute

Am 17. September haben wir nachgestellt, dabei kam der zweite Befund heraus. Ein manueller Einzellauf auf demselben Host, angesetzt beim Schreiben einer Betriebsnotiz, endete mit ok. apt meldete im selben Atemzug weiterhin 14 Pakete als „not upgraded". Erfolg und ungepatcht, eine Minute auseinander. Der Lock (flock) schützt nur den Wrapper des Nachtlaufs; ein direkter Aufruf läuft daran vorbei.

Vier Befehle aus diesem Fenster, erwartetes Ergebnis gegen reale Konsequenz:

Das Muster ist nicht Nachlässigkeit, sondern die Lücke zwischen dem, was ein Befehl zurückgibt, und dem, was wir daraus lesen. Ein Zugang in einer Befehlszeile landet in jeder Aufzeichnung, die diese Zeile mitschreibt.

Fehlend ist schlimmer als rot

Der dritte Fund ist stiller und unangenehmer. Der CVE-Watcher führt eine eigene Pin-Datei für Hostschlüssel, unabhängig von unserer ssh-Config, und läuft mit StrictHostKeyChecking=accept-new. Eine neue Key nimmt er kommentarlos. Eine geänderte Key ist ein harter Abbruch, und weil er im ssh-Aufruf passiert, wird daraus kein roter Eintrag: Der Host fehlt. Ein Produktionsknoten war dreizehn Läufe in Folge blind, bei ruhigen Dashboards.

Dazu unsere Vorgeschichte: 34 Maschinen teilen sich einen Hostschlüssel aus einem Golden Template. Eine geänderte Key ist bei uns Routine, kein Angriff. Ein Monitoring, das diesen Normalfall nicht aushält, meldet keine Sicherheit, es schaltet sich selbst ab. Aufräumen half auch nicht: Unsere Config zu bereinigen genügte nicht, weil der Job eine zweite Pin-Datei liest, und es gibt eine dritte, versionierte Kopie. Werkzeuge mit eigener known_hosts müssen im Inventar stehen, sonst beginnt die Reparatur jede Woche von vorn.

Das ist die Lektion aus unserem DNS-SERVFAIL-Monitoring. Dort stand die Prüfung auf Grün, weil sie nur Erreichbarkeit maß und nicht die Auflösung. Hier verschwindet ein Host, weil die Prüfung nicht sagen kann, dass sie selbst nicht gelaufen ist. Eine Prüfung, die „heute habe ich nicht stattgefunden" nicht formulieren kann, ist Theater. Die Frage „hat jeder Host heute einen Eintrag bekommen?" ist deshalb eine eigene Kennzahl, pro Host, als Zeitstempel, nicht als Aggregat. Ein Summenwert über eine Flotte unterscheidet den Ausfall des Prüfers nicht von einem ruhigen Abend.

Unsere Entscheidung: fail-open für die Flotte

Wir haben den Fehlerfall beschlossen, statt ihn weiterzuverwalten. Fail-open für die Flotte, fail-stop pro Host. Das apt-Problem eines einzelnen Hosts darf nicht noch einmal mehr als dreißig Hosts ihre Patch-Nacht kosten. Ein Scheitern ist kein Abbruch mehr, sondern eine eigene Zeile mit eigenem Alarm: Host, Exit-Code, offene Pakete, Zeitpunkt. Die Reihenfolge bleibt begründet. Nur ihr Ende ist jetzt ein Normalfall.

Wer das nachbaut, braucht vier Zeilen; die stehen an einem Abend:

1. Erwartete Hosts gegen gelieferte Zeilen. Die Liste ist bekannt, der Bericht bekommt pro Host eine Zeile, auch bei Auslassung. Melden Sie die Differenz, nicht den Aggregatwert.
2. Host-Fehler als Zeile, nicht als Abbruch. Der Exit-Code gehört in den Bericht, die Schleife läuft weiter. Ein Alarm pro Scheitern, nicht einer pro Nacht.
3. Zeitstempel der letzten erfolgreichen Prüfung pro Host. Ein fehlender Eintrag wird sichtbar, ohne dass jemand den Bericht lesen muss. Das ist die Antwort auf dreizehn blinde Läufe.
4. Kein Werkzeug ohne Versionsnummer im Image-Tag. Läuft ein Patchwerkzeug in einem Container mit mutablem Tag, ist „seid ihr gepatcht?" nicht mehr beantwortbar, weil der Tag die Antwort nicht trägt. Für Patch-Management im KMU haben wir das aufgeschrieben, für die Werkzeuge selbst nie angewendet.

Punkt 4 zahlt am meisten: eine Tag-Änderung, und eine Frage, die im Audit sonst niemand beantwortet.

Prozessdoku ist kein Monitoring

Jetzt die unbequeme Seite. Unsere Flotte hat einen dokumentierten Patch-Prozess mit zwölf Schritten, inklusive Wartungsfenster. Er hat trotzdem eine Nacht hervorgebracht, in der ein Sicherheitsupdate auf dreißig Rechnern lag, während der Bericht failed schrieb und ihn niemand las. Zwölf Schritte auf Papier sind eine Absicht, keine Überwachung.

Dazu der vierte Befund: Die Plandatei des Nachtlaufs wird aus der Shell-History erzeugt, und ihre Befehle sind über die Monate von dem abgedriftet, was tatsächlich gebraucht wird. Wir vertrauen den Zahlen aus den Vorprüfungen inzwischen mehr als dem Text des Plans. Ein Plan, den niemand gegenmisst, ist eine Erinnerung.

Der fünfte Punkt klingt nach Kosmetik und ist es nicht. Der Bericht färbt seine Badge nach Wörtern: „uebersprungen" und „nicht erreichbar" werden bewusst gelb, und ein ausgeschlossenes Wort ist der String „0 Befehle fehlgeschlagen". Wer eine Meldung umformuliert, ändert die farbliche Aussage des Berichts. Wortwahl ist tragende Konstruktion, keine Textpflege. Ein Alarm, der wartet, bis ihn jemand liest, ist keine Kontrolle. Deshalb blockt bei uns CrowdSec statt fail2ban von selbst, und bei Backups wird verifiziert und zurückgespielt statt geglaubt. Beim Patchen gaben wir uns mit failed zufrieden.

Stand: 17. September 2026, zweite Nacht. Der Datei-Host hat weiterhin offene Pakete, das Fremddepot hält sie zurück. Diesmal eine Zeile mit eigenem Alarm, kein Abbruch für alle dahinter.

Weiterführende Quellen

• Debian: apt-get(8), DIAGNOSTICS, Exit-Code 100 bei Fehlern
• OpenSSH: ssh_config(5), StrictHostKeyChecking mit accept-new
• Linux man page: flock(1), Sperren von Dateien für parallele Läufe
• Docker: Build best practices, Images über Tags und Digests referenzieren
• Google SRE Book: Monitoring Distributed Systems