Linux Patchmanagement automatisieren, ohne den Betrieb zu stoppen
Ab etwa hundert Hosts ist der monatliche Patchtag keine Betriebsform mehr, sondern ein Risiko. Was trägt, ist automatisiertes Patchen in Ringen mit definierten Wartungsfenstern und einem Rückweg, der auch nachts funktioniert.
Warum der manuelle Patchtag an der Flotte scheitert
Auf einem einzelnen Server ist ein Update trivial. Bei 300 Systemen über Debian, Ubuntu, RHEL und SLES hinweg wird daraus ein Koordinationsproblem: unterschiedliche Paketmanager, unterschiedliche Wartungsfenster, Abhängigkeiten zwischen Datenbank, Applikationsserver und Reverse Proxy. Wer das per SSH-Schleife und Kalendereintrag löst, verschiebt Updates so lange, bis ein CVE mit hohem CVSS-Score die Entscheidung erzwingt.
Der zweite Treiber ist regulatorisch. NIS2, ISO 27001 und Kundenaudits fragen nicht nur, ob gepatcht wird, sondern in welcher Frist und wie das belegt ist. Ein Prozess, der von der Verfügbarkeit einzelner Kolleginnen und Kollegen am Samstag abhängt, ist weder reproduzierbar noch nachweisbar.
Typische Fehler sehen wir immer wieder in derselben Reihenfolge: unattended-upgrades wird aktiviert, aber niemand liest die Mails, deshalb bleibt der ausstehende Reboot monatelang liegen und der Kernel im Speicher ist Jahre alt. Oder dnf-automatic läuft mit apply auf einem Datenbankcluster und startet mitten im Tagesgeschäft Dienste neu. Oder es gibt gar keine Staffelung, sodass ein fehlerhaftes Paket alle Knoten einer HA-Gruppe gleichzeitig trifft. Automatisierung ohne definierte Ringe und ohne Rollback-Pfad vergrößert den Schaden, statt ihn zu begrenzen.
Vom Advisory bis zum bestätigten Reboot
- 01 Inventar und Patchquelle festlegen
- 02 Testring automatisch patchen
- 03 Produktion gestaffelt ausrollen
- 04 Reboot-Bedarf prüfen und einplanen
- 05 Dienste verifizieren, sonst Rollback
- 06 Patchstand berichten und dokumentieren
So sieht ein tragfähiger Patchprozess aus
Automatisiertes Patchmanagement besteht aus drei Schichten: der lokale Mechanismus auf dem einzelnen Host, die Orchestrierung über die Flotte und die Entscheidung, wann ein Reboot stattfindet. Die folgenden Punkte beschreiben, worauf es dabei technisch ankommt.
Lokale Automatik sauber konfigurieren
Unter Debian und Ubuntu steuerst du unattended-upgrades über /etc/apt/apt.conf.d/50unattended-upgrades und beschränkst die Origins in der Regel auf die Security-Suite. Unter RHEL, Rocky und AlmaLinux übernimmt dnf-automatic die Rolle, wobei der Unterschied zwischen download-only und apply die eigentliche Risikoentscheidung ist. Auf SLES erledigt das zypper-Backend in Verbindung mit dem Multi-Linux Manager denselben Job.
Flotten über Ansible in Ringen ausrollen
Ein Playbook mit ansible.builtin.package oder den distributionsspezifischen Modulen, kombiniert mit serial und max_fail_percentage, gibt dir kontrollierte Wellen: erst Testsysteme, dann unkritische Produktion, dann die Kernsysteme. Über pre_tasks und post_tasks nimmst du Knoten aus dem Loadbalancer, setzt Monitoring-Downtimes und prüfst anschließend den Dienststatus, bevor der nächste Knoten drankommt.
Reboots als eigenen, bewussten Schritt behandeln
Paketupdate und Neustart gehören getrennt. Ob ein Reboot nötig ist, verrät /var/run/reboot-required unter Debian oder needs-restarting -r unter RHEL. Mit dem reboot-Modul und definierten Wartebedingungen läuft der Neustart kontrolliert, bei Clustern erst nach Prüfung von Quorum und Ressourcenverteilung. Kernel Live Patching über kpatch oder das SUSE-Pendant verschiebt den Neustart, ersetzt ihn aber nicht dauerhaft.
Ausnahmen bewusst definieren statt stillschweigend zulassen
Datenbanken, Reverse Proxies, SAP-Systeme und Appliances gehören in eine eigene Gruppe mit engerem Wartungsfenster und manueller Freigabe. Versionspins über dnf versionlock oder apt-mark hold sind legitim, brauchen aber ein Ablaufdatum und einen Verantwortlichen, sonst wachsen sie zu unsichtbaren Altlasten heran.
Rollback und Snapshots vorher testen
Auf btrfs mit snapper unter SLES oder über Storage-Snapshots der Virtualisierung hast du einen echten Rückweg. dnf history undo hilft bei Paketproblemen, nicht bei Datenbankmigrationen. Wichtig ist, dass der Rollback-Pfad einmal geübt wurde, bevor du ihn nachts unter Druck zum ersten Mal ausprobierst.
Ergebnis messbar machen
Ein Report über verbleibende offene Updates, Patchalter pro Host und Zeit bis zum Reboot gehört ins Monitoring, etwa über Prometheus-Metriken oder die Inventarfunktionen des Multi-Linux Managers. Erst damit siehst du die Systeme, die aus der Automatik herausgefallen sind, und genau die sind erfahrungsgemäß das Problem.
Kurse zu automatisiertem Patchmanagement bei cmt
Diese Kurse vertiefen genau das, an echten Systemen statt nur an Folien. Als Präsenz oder Live-Online, auf Wunsch auch Inhouse für dein Team.
Häufige Fragen zu automatisiertem Patchmanagement
Noch etwas offen? Wir sind ohne Warteschleife für dich da.
Frag uns direktDarf man unattended-upgrades auf Produktivservern aktivieren?
Was ist der Unterschied zwischen dnf-automatic und einem Ansible-Playbook?
Macht Kernel Live Patching Reboots überflüssig?
Wie oft sollte gepatcht werden?
Welcher cmt-Kurs passt zum Aufbau eines automatisierten Patchprozesses?
Zuletzt geprüft am 26. Juli 2026.
Verwandte Linux-Themen
Alle Linux-Themen im ÜberblickEchte Stimmen aus unseren IT-Kursen
Qualitativ sehr guter Kurs. Ruhiger und wertschätzender Umgang. Keine Informationsüberlastung.
Sehr kompetenter Dozent der gut auf alle Fragen eingegangen ist.
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.
Patchprozess mit uns durchsprechen
Wenn du deinen Patchprozess von Handarbeit auf Automatisierung umstellen willst, schauen wir uns gemeinsam an, welche Systeme unbeaufsichtigt laufen können und wo du Freigaben brauchst. Melde dich für eine Kursempfehlung oder eine Inhouse-Schulung, die auf deine Distributionen und deine Betriebsrealität zugeschnitten ist.