In einer gemischten IT-Umgebung gehören Updates zum täglichen Betrieb. Bei Windows arbeiten wir bereits mit WSUS und Action1. Mit zusätzlichen Linux-Servern, verschiedenen Distributionen und mehreren Docker-Umgebungen stellte sich für uns die Frage, wie wir auch dort den Überblick behalten.
Wir haben uns bewusst für eine Entkopplung entschieden: Windows bleibt bei WSUS und Action1. Für Linux setzen wir PatchMon ein. Die Trennung betrifft die Werkzeuge für das Patchmanagement. Gemeinsame Aufgaben wie Überwachung, Protokollierung und die Kontrolle nach einer Wartung bleiben weiterhin wichtig.
Weshalb wir Windows und Linux getrennt betreuen
Für uns gab es keinen Anlass, die vorhandenen Windows-Abläufe allein wegen der Linux-Erweiterung abzulösen. WSUS und Action1 behalten dort ihren Platz. Linux erhält mit PatchMon eine eigene zentrale Anlaufstelle für den Paketstand und die anstehenden Aktualisierungen.
Das passt zu unserer Umgebung: Auf Windows und Linux unterscheiden sich Paketquellen, Wartungsabläufe und die Anwendungen, die nach einem Update wieder funktionieren müssen. Eine gemeinsame Oberfläche wäre angenehm. Für unseren Betrieb war es wichtiger, die bestehenden Abläufe weiterzuverwenden und Linux gezielt zu ergänzen.
Diese Entscheidung ist eine Aufteilung für unseren konkreten Betrieb. Sie sagt nichts darüber aus, ob ein einzelnes Produkt grundsätzlich beide Plattformen verwalten könnte.
Auch das Patchmanagement selbst kann ausfallen
Ein weiterer Grund für die Trennung ist die Verfügbarkeit der Verwaltungswerkzeuge selbst. Wenn eine Patchplattform wegen einer Störung oder einer eigenen Sicherheitsaktualisierung vorübergehend nicht erreichbar ist, sollen Windows und Linux nicht beide von derselben zentralen Instanz abhängen.
Ein konkretes Beispiel gab es in dieser Woche: Auch bei uns war Action1 vorübergehend nicht verfügbar. Am 21. Oktober 2026 erklärte ein Action1-Vertreter in einer öffentlichen Mitteilung zur vorsorglichen Dienstunterbrechung, dass die Dienste angesichts der bekannt gewordenen PHP-Sicherheitslücken vorübergehend pausiert wurden. Nach der Aktualisierung der Komponenten mit PHP-Paketen meldete er den Betrieb wieder als hergestellt; Hinweise auf eine Kompromittierung seien nicht gefunden worden.
Für mich macht dieses Beispiel die Überlegung hinter unserer Aufteilung greifbar. Auch ein Werkzeug, mit dem wir andere Systeme absichern, braucht gelegentlich selbst eine Wartung. Mit dem eigenen PatchMon-Betrieb für Linux begrenzen wir die gemeinsame Abhängigkeit von einer einzelnen Patchplattform. Das schafft keine vollständige Ausfallsicherheit: Gemeinsame Abhängigkeiten wie Netzwerk, Stromversorgung oder Virtualisierung bleiben separat zu betrachten.
PatchMon als zentrale Übersicht für Linux
PatchMon betreiben wir selbst als Docker-Anwendung auf einem Linux-Server. Auf den aufgenommenen Linux-Systemen läuft jeweils ein Agent, der seine Informationen an die zentrale Instanz übermittelt. In der Weboberfläche sehen wir damit den installierten Paketbestand, ausstehende Aktualisierungen und die gemeldeten Sicherheitsupdates.
Gerade bei mehreren Distributionen hilft uns diese Übersicht. Wir müssen für eine erste Bestandsaufnahme nicht jedes System einzeln per SSH öffnen. Der Blick in die Details bleibt trotzdem wichtig: Welches Paket ist betroffen? Welcher Dienst verwendet es? Ist nach der Installation ein Neustart erforderlich?
Die Aufnahme eines Hosts prüfen wir deshalb in mehreren Schritten. Ein gestarteter Agent ist der Anfang. Danach kontrollieren wir die Verbindung und ob sein Bericht tatsächlich in der Oberfläche ankommt. Erst mit diesen Daten lässt sich sinnvoll über den nächsten Wartungsschritt entscheiden.
Automatische Sicherheitsupdates am Beispiel der Blog VM
Unsere Blog-VM zeigt, dass zentrale Übersicht und lokale Updateausführung unterschiedliche Aufgaben haben können. Die Debian-VM meldet ihren Paketstand an PatchMon. Die täglichen Sicherheitsupdates führt sie über das Debian-Werkzeug unattended-upgrades aus.
Für eine solche Automatisierung werden die Paketlisten vorab aktualisiert und Sicherheitsupdates in einem festgelegten Wartungsfenster installiert. Die Auswahl der freigegebenen Paketquellen muss bewusst erfolgen; andere Quellen fallen nicht automatisch unter dieselbe Auswahl.
Das Neustartverhalten muss zur Anwendung passen. Für eine statische Website kann eine geplante kurze Unterbrechung vertretbar sein. Bei einem Arbeitsplatzserver mit laufenden Benutzersitzungen braucht die Wartung einen anderen Ablauf.
Konfiguration und Simulation sind sinnvolle Vorprüfungen. Der reguläre Ablauf muss anschliessend zeigen, ob Installation, ein gegebenenfalls nötiger Neustart und der Wiederanlauf wie geplant funktionieren.
Die Verbindung aus der DMZ gezielt erlauben
Bei der Aufnahme eines Systems aus einer getrennten Netzwerkzone muss die vorhandene Netztrennung erhalten bleiben. Eine Verwaltungsverbindung sollte deshalb auf den benötigten Dienst begrenzt und mit aktiver Zertifikatsprüfung eingerichtet werden.
Eine Besonderheit entsteht, wenn mehrere Anwendungen dieselbe Reverse-Proxy-Adresse verwenden. Eine Firewallfreigabe zu dieser Adresse allein unterscheidet die einzelnen Anwendungen noch nicht.
In einem solchen Fall kann zusätzlich eine anwendungsbezogene Begrenzung am Reverse Proxy erforderlich sein. Zur Abnahme gehören eine positive Probe zum erlaubten Dienst und negative Proben zu anderen Anwendungen. Erst beide Seiten zusammen prüfen den vorgesehenen Umfang.
Docker Images brauchen eine eigene Betrachtung
Neben den Linux-Paketen kann die Docker-Integration auch Stacks, Container und Images erfassen. Das ergänzt eine Containerverwaltung um eine gemeinsame Bestandsübersicht. Die PatchMon-Dokumentation zur Docker-Integration beschreibt die Erfassung über den lokalen Docker-Socket und die Prüfung der Registry.
Ein angezeigtes Imageupdate bedeutet zunächst, dass hinter demselben Tag ein anderes Image verfügbar ist. Bei einem fest auf eine Version gesetzten Tag ersetzt diese Prüfung daher keine Recherche nach neueren Versionen. Ebenso ist ein Updatehinweis allein noch kein Nachweis einer Sicherheitslücke.
Für die tatsächliche Aktualisierung prüfen wir weiterhin Sicherung, Versionshinweise, Abhängigkeiten und den anschliessenden Funktionstest. Das Aktualisieren der Linux-Pakete auf dem Host erneuert keine Anwendungsimages in seinen Containern. Automatische Containerupdates haben wir mit der Inventarisierung nicht eingerichtet; die angezeigten Updates gehen wir gesondert an.
Eine gelbe Anzeige braucht Kontext
Auch die Zahl der laufenden Container muss man einordnen. Ein Stack kann neben dauerhaft laufenden Diensten einmalige Initialisierungs- oder Hilfscontainer enthalten. Wenn eine solche Aufgabe erfolgreich endet, bleibt ihr Container je nach Aufbau im Zustand beendet sichtbar.
Bei unserem Ticketsystem ist das beispielsweise für den Initialisierungscontainer vorgesehen. Entscheidend sind dann der erfolgreiche Abschluss, der Exitcode und die Funktion der eigentlichen Anwendung. Alle Container eines Stacks dauerhaft zu starten wäre dafür kein sinnvolles Ziel.
Das gilt ähnlich für die Paketübersicht: Eine grüne Anzeige ist hilfreich, ersetzt aber weder die Überwachung noch den Test der Anwendung nach einer Wartung. Checkmk behält deshalb seine Aufgabe in unserem Betrieb. PatchMon ergänzt den Blick auf den Aktualisierungsstand.
Wo wir den Ausbau vorerst begrenzen
Für NAS-Systeme oder andere Sonderplattformen ist gesondert zu prüfen, ob die Agent-Einbindung unterstützt und betrieblich sinnvoll ist. Eine bestehende Containerverwaltung und eine neue Inventarisierung lösen unterschiedliche Aufgaben. Zusätzliche Sonderlösungen sollten ihren Pflegeaufwand rechtfertigen.
Auch komplexere Wartungsabläufe bleiben ein eigener nächster Schritt. Bei Citrix-Desktops gehören etwa laufende Sitzungen, der Wartungsmodus und die erneute Registrierung nach einem Neustart zum Ablauf. Solche Abhängigkeiten wollen wir in einem separaten Versuch zur zentralen Wartungsautomation betrachten.
Für heute steht die Aufteilung fest: Windows betreuen wir mit WSUS und Action1 weiter. Linux erhält mit PatchMon eine zentrale Übersicht und einen eigenen Weg für das Patchmanagement. Welche Updates automatisch laufen dürfen und welche eine geplante Wartung brauchen, entscheiden wir passend zur Aufgabe des jeweiligen Systems.