Administratoren kennen das Problem nur allzu gut: Freitagnachmittag, gedanklich lockt schon das Wochenende und beim letzten Blick in das eigene Postfach taucht sie auf – die E-Mail, die kein Admins sehen möchte: "Kritische Lücke in Apache" heißt es dort, "aus der Ferne angreifbar", um mit den Rechten des Nutzers, der den Apache-Dienst auf dem System betreibt, beliebigen Code auszuführen.

Nervös geht der Admin die Anzahl der betroffenen Systeme im Kopf durch und merkt schnell, dass es mit dem wohlverdienten Wochenende vorerst nichts wird. Stattdessen beginnt das Einspielen von Updates, die der Hersteller der eigenen Distribution zwischenzeitlich zur Verfügung gestellt hat. IT-Verantwortliche, die ihre Hausaufgaben in der Vergangenheit gemacht haben, profitieren nun möglicherweise von Automatisierung und spielen die Updates auf vielen Systemen parallel ein.

Wer auf solche Annehmlichkeiten verzichten muss, hangelt sich von Server zu Server und sieht sich im schlimmsten Fall stundenlanger Arbeit gegenüber. Oder die Updates doch erst am Montag einspielen? Das kann sich als kostspieliger Fehler erweisen. Wenn etwa nämlich nicht nur die Apache-Software ein Sicherheitsproblem hat, sondern auch der Kernel, der diese beheimatet, wird aus einem Angriff auf den Webserver unter Umständen die Übernahme des kompletten Systems über eine Eskalation der Zugriffsberechtigungen bis hin zum Systemadministrator "root". Spätestens dann fängt die IT-Abteilung an, die Backups großflächig auszurollen – an regulären IT-Betrieb ist nicht mehr zu denken.

Sicherheitsupdates spielen heute also eine zentrale Rolle in der Systemadministration nach allen gängigen Standards. Aber auch andere Aktualisierungen können relevant sein: Wenn der eigene Dienst etwa nicht richtig funktioniert, weil er von einem Bug betroffen ist, wird der Admin reparierte Pakete seitens des Herstellers eher zeitnah einspielen wollen. Hier kommt zwar nicht dieselbe zeitkritische Komponente zum Tragen wie bei Sicherheitsupdates. Die Zeit drängt in der Regel dann aber ebenfalls.

Um die Not von Admins zu lindern, arbeiten die großen Distributoren seit Jahren an Lösungen für das Problem. Ein Ansatz hat sich in der letzten Dekade dabei immer stärker etabliert, zumal er etliche Male technisch verfeinert wurde – automatische Updates. Die Idee hinter diesem Ansatz ist denkbar banal: Merkt ein System, dass Aktualisierungen verfügbar sind, spielt es diese nach vom Admin festgelegten Regeln ein. Schon beim Gedanken daran läuft manchem Administrator allerdings ein Schauer über den Rücken.

Wer in den 2000er-Jahren bereits als Admin tätig war, hat schließlich noch mitbekommen, dass Anbieter wie Red Hat, SUSE oder Canonical bereits bei einfachen Paketupdates regelmäßig danebengegriffen haben. Seinerzeit fanden die Aktualisierungen nur unter persönlicher Überwachdmin ihren Weg auf die Systeme. Wenn etwas schiefging, waren oft bereits Rollback-Szenarien vorbereitet, mit denen sich die Änderungen rückgängig machen ließen. Und nun erwarten die Anbieter, dass Updates vollautomatisch eingespielt werden sollen, ohne dass jemand eingreifen kann? Da wollen wir genauer hinschauen.

Zunächst möchten wir an dieser Stelle für die großen Hersteller eine Lanze brechen. Alle Anbieter von Enterprise-Distributionen sind in der vergangenen Dekade im Hinblick auf Updates merklich besser geworden. Das Einspielen aktualisierter Pakete geht bei RHEL, SLES und Ubuntu heute deutlich flüssiger von der Hand, als es früher der Fall war. Das gilt für einzelne Updates innerhalb einer Version einer Distribution ebenso wie für Major-Releases des Systems. Nur Debian bildet hier eine Ausnahme, denn der Anbieter hatte seine Updates bereits Mitte der 2000er-Jahre ziemlich gut im Griff. Das Potenzial für Verbesserungen war also entsprechend kleiner.

Ferner bieten alle Distributoren heute eigene Werkzeuge für das automatische Einspielen von Updates an; und rund um das Feature ein Füllhorn an Konfigurationsoptionen. Bei keiner aktuellen Enterprise-Distribution stehen Sie als Administrator beispielsweise vor der Wahl, entweder stets alle verfügbaren Updates einzuspielen oder gar keine. Stattdessen unterteilen die Anbieter ihre "unattended Updates"– so der Name bei der Paketinstallation ohne Aufsicht – in funktionale Fehlerkorrekturen einerseits und Fehlerkorrekturen mit Sicherheitsbezug andererseits.

Im eingangs zitierten Beispiel lässt sich also nur Apache aktualisieren, ohne andere verfügbare Updates ebenfalls automatisch auf das System gespielt zu bekommen. Auch lässt sich einstellen, ob nach dem Einspielen eines neuen Kernel-Paketes ein Neustart des Systems erfolgen soll. Sie stellen auf Wunsch also nach einer Art Baukastenprinzip zusammen, welche Aktualisierungen Sie automatisch einspielen lassen möchten und welche Arbeitsschritte dabei der Automatismus absolviert. Sie behalten aber grundsätzlich die Kontrolle über den Vorgang.

Da stellt sich natürlich die Frage, welche Möglichkeiten die Enterprise-Distributionen bieten, um automatische Updates zu aktivieren und zu konfigurieren. Red Hat Enterprise Linux (RHEL) zeigt, wie es geht, Ubuntu erbt eine entsprechende Funktion von Debian – und SUSE Linux Enterprise Server (SLES) lässt sich bitten.

Red Hat darf in Sachen automatischer Updates den Titel des Klassenprimus für sich beanspruchen, denn von allen Enterprise-Distributionen setzt RHEL das Konzept am konsequentesten um. Der gesamte Ansatz fußt auf "dnf", Red Hats aktuellem Paketwerkzeug der Wahl, das unter der Haube wie gehabt auf RPM setzt. In Form von "dnf-automatic", das seinerseits im Hintegrund wieder "dnf" aufruft, bietet der Hersteller gar ein eigenes Werkzeug, das sich ausschließlich dem Thema automatisierter Updates widmet.

Um die Funktionalität zu nutzen, installieren Sie also das Paket "dnf-automatic". Das Werkzeug kommt mit einer eigenen Konfigurationsdatei daher, "/etc/dnf/automatic.conf". In ihr finden Sie sämtliche nötigen Parameter, um Updates für Ihr System zu steuern. Zunächst aktivieren Sie den Updatedienst, indem Sie "apply_updates" in der Datei auf "yes" setzen. Andernfalls würde "dnf-automatic" die Updates zwar herunterladen, sie aber nicht zugleich auch installieren. Parallel dazu sollte die Option "download_updates" auf "yes" stehen, damit "dnf-automatic" Updates zieht, sobald es von deren Verfügbarkeit erfährt. Das sorgt dafür, dass die Pakete lokal wenigstens bereits vorhanden sind, sodass ihr Download die Dauer des Updates nicht verlängert.

Darüber hinaus beherrscht "dnf-automatic" etliche Benachrichtigungsfunktionen, die gängigste davon ist die E-Mail. Falls "emit_via" auf "email" gesetzt ist, sollten Sie auch die Parameter "email_from" und "email_to" setzen. "from" bestimmt dabei den Absender, "to" den Empfänger. Obendrein sollte "email_host" einen vom System aus erreichbaren SMTP-Server enthalten, der so konfiguriert ist, dass er die E-Mails auch annimmt und zustellt oder an einen anderen Host weiterleitet.

Danach gilt es, die Updatefunktion durch "dnf-automatic" tatsächlich zu aktivieren. Das übernimmt das System durch die bloße Installation des "dnf-automatic"-Paketes nämlich nicht. Sie greifen ihm mittels

 unter die Arme: Nach diesem Befehl führt "dnf-automatic" den Befehl

als systemd-Timer aus, wenn "dnf-automatic" wie hier beschrieben konfiguriert ist. Wenn Sie genauer wissen möchten, was konfiguriert ist, schauen Sie mittels

genauer hin. Möchten Sie aber nur Benachrichtigungen über verfügbare Pakete bekommen, aktivieren Sie stattdessen den Timer "dnf-automatic-notifyonly.timer".

Einen kleinen Wermutstropfen gibt es bei RHEL dann aber doch: In seiner aktuellen Version besitzt "dnf-automatic" kein Werkzeug, um Systeme nach der Installation von Updates automatisiert neu zu starten. Das liegt auch an mangelnder Funktionalität "unter der Haube", also in "dnf" selbst. Denn bis Ende Januar 2023 konnte "dnf" selbst in den Augen der Entwickler nicht zuverlässig herausfinden, ob ein Reboot nach Änderungen nötig war oder nicht. Das hat sich mittlerweile geändert, eine entsprechende Funktionalität liegt in "dnf-automatic" nun vor (Bild 1). Wann diese es als Update aber in das offizielle RHEL schafft, stand zu Redaktionsschluss noch nicht fest. Und auch nicht, ob Red Hat das überhaupt vorsieht.

Die beiden Anweisungen sorgen dafür, dass sowohl Ubuntu als auch Debian ihre Paketlisten im Hintergrund regelmäßig aktualisieren und danach den Befehl apt upgrade ausführen. "apt" kommt dabei ab Werk mit einer eingebauten Weiche, um Updates in Kategorien einzuteilen. Das "upgrade" sorgt dafür, dass alle Updates eingespielt werden, die nicht die Installation oder das Entfernen anderer Pakete bedingen. Das Feature hat dabei eine eingebaute Verzögerung an Bord, die dafür sorgt, dass in Umgebungen mit Dutzenden Systemen nicht alle Pakete gleichzeitig mit dem Download der Updates beginnen. Die gewählte Verzögerung zu Beginn ist dabei zufällig ausgestaltet.

Sowohl Ubuntu als auch Debian erkennen im Rahmen von Updates übrigens automatisch, dass ein neuer Kernel installiert wird und ein Reboot nötig ist. Automatisch führen diesen Reboot aber beide Systeme nicht durch. Wer automatische Updates nutzen möchte, fügt in "/etc/apt/apt.conf.d/ 50unattended-upgrades" den Parameter "Unattended-Upgrade::Automatic-Reboot "true";" hinzu und installiert zusätzlich das Paket "update-notifier-common".

Die erwähnte Datei "/etc/apt/apt.conf.d/ 50unattended-upgrades" steuert automatische Updates in "apt" ganz grundsätzlich. Hier ist auch die Liste der Distributionen und Verzeichnisse aufgeführt, aus denen "apt" grundsätzlich automatische Updates bezieht. Dabei ist Vorsicht geboten, denn ab Werk steht diese nämlich nicht nur auf "security"; sie enthält stattdessen auch das "updates"-Verzeichnis, das funktionale Aktualisierungen enthält. Wer das Treiben also auf Sicherheitsupdates beschränken möchte, der findet hier die entsprechenden Parameter (Bild 2).

Etwas weniger komfortabel gestaltet sich das Prozedere bei SUSE Linux Enterprise Server. Um den Ansatz von SUSE nachzuvollziehen, ist zunächst ein kurzer Ausflug in die Art und Weise nötig, wie der Anbieter seine Paketupdates grundsätzlich verwaltet. Bekanntlich basiert SLES auf RPM und das Standardwerkzeug "zypper" ist der Königsweg, um auf der Kommandozeile Pakete zu installieren. Das Kommando zypper patch, ausgeführt mit den Rechten von "root", sorgt dafür, dass sämtliche Sicherheitsupdates installiert werden. SUSE unterscheidet hier nämlich zwischen normalen Updates und "Patches" – ein Begriff, der sich im SUSE-Universum stets auf Korrekturen mit Sicherheitskontext bezieht. Wer den Prozess automatisieren möchte, ist allerdings nicht bei Zypper richtig, sondern bei YaST.

Durch die Installation des Pakets "yast2-online-update-configuration" holen Sie sich ein YaST-Modul (Bild 3) auf das System, mit dem sich automatische Updates aktivieren lassen. Nach der Installation stehen die Optionen für Onlineupdates sowohl in der grafischen Version von YaST als auch in dessen CLI-Variante zur Verfügung. "yast2 online_update_configuration" (Bild 4) holt den Dialog dort auf den Bildschirm. Möchten Sie die Updates auf bestimmte Typen von Patches beschränken, gilt es, "Filter by Category" zu aktivieren und als Kategorie danach "Security" auszuwählen. Obendrein muss ganz oben der Haken bei "Automatic Online Update" gesetzt und das gewünschte Intervall ausgewählt sein.

Die Sache kommt allerdings mit einem Pferdefuß daher: YaST hat selbst keinerlei Handling für den Neustart eines Systems an Bord. Das liegt einerseits daran, dass SUSE Live Kernel Patching (KLP) beherrscht. Ein Patch für den Linux-Kernel muss also nicht unter allen Umständen zwangsläufig zum Neustart des Systems führen. Wer nur beschränktes Vertrauen in Live Kernel Patching hat, muss sich allerdings nach einer Alternative umschauen. Eine Empfehlung dafür liefert SUSE immerhin mit "rebootmgr". Das kleine Tool ist in der Lage, automatisch zu erkennen, ob beim letzten Update Patches mit Bezug zum Linux-Kernel installiert wurden. Ist das der Fall, kann "rebootmgr" das System je nach Konfiguration zu einem bestimmten Zeitpunkt oder während eines bestimmten Zeitraums automatisiert durchstarten. Die Variante mit der Angabe eines Zeitraums anstelle eines Zeitpunkts ist dabei besonders hilfreich, wenn Sie es nicht mit einzelnen Systemen zu tun haben, sondern mit einer Vielzahl an Servern. Den genauen Zeitpunkt während des Zeitraums wählt "rebootmgr" dann automatisch. Es ist dadurch unwahrscheinlich, dass von zehn Applikationsservern innerhalb des genannten Zeitraums alle gleichzeitig wegen des Neustarts offline sind.

Updates per Automatisierung einzuspielen, hat also durchaus seinen Reiz. Einerseits müssen Sie sich als Admin in dem Szenario nicht mit dem Kleinklein der Systemverwaltung beschäftigen. Das spart insbesondere bei nichthomogenen Setups Mühe, in denen mehrere Distributionen zum Einsatz kommen. Darüber hinaus sparen automatisch eingespielte Updates per Automatisierung Zeit, weil sich die Arbeitsschritte auf vielen Systemen gleichzeitig abwickeln lassen. Eigentlich ein idealer Ansatz, allerdings stehen passende Lösungen für "unattended upgrades" für die klassischen Automatisierer nicht gerade in großer Zahl zur Verfügung. Das liegt grundsätzlich daran, dass die Hersteller eben diese Arbeiten eher beim Lifecycle-Management verorten. Und tatsächlich: Red Hat Satellite, SUSE Manager oder Ubuntu Landscape bieten entsprechende Update-Features an.

Wer es etwas generischer mag, setzt auf Foreman [1] und erhält hier eine vergleichbare Funktionalität. Die Idee dahinter ist simpel: Über den Manager für die eigene Distribution lässt sich der gesamte Updatevorgang übergreifend steuern und bis ins kleinste Detail auch konfigurieren. Doch geht dieser Ansatz mit mehreren Wermutstropfen einher. Einerseits sind die Updatefunktionen der Lifecycle-Manager meist spezifisch für die Systeme des jeweiligen Herstellers konzipiert. Nicht jedes Management-Werkzeug ist überhaupt in der Lage, Systeme mit anderen Distributionen als jener zu bearbeiten, für die es programmiert wurde. Wer mit Landscape automatische Updates verwalten möchte, wird etwa letztlich nur dann wirklich glücklich, wenn er eine reine Ubuntu-Landschaft betreibt. Und andererseits gibt es die beschriebenen Management-Systeme nur gegen Bezahlung beim Hersteller. Und je nach Größe einer Umgebung kann der Geldbetrag, der für Landscape, Satellite und Co. anfällt, durchaus happig sein.

Allerdings existieren zwischen den Extremen auch Mittelwege, die eine sinnvolle Administration ohne großen finanziellen Mehraufwand ermöglichen. Bis hierhin haben wir die Unattended-Upgrade-Mechanismen für die vier gängigen Enterprise-Distributionen betrachtet. Auch wenn Ansible und Co. selbst keine automatischen Updates durchführen, lassen sie sich zumindest nutzen, um die in diesem Artikel beschriebene Konfiguration automatisiert auf allen betroffenen Systemen zu hinterlegen. Ein mustergültiges Beispiel für eine Ansible-Rolle, die für RHEL, Ubuntu und Debian das Problem löst, stammt von der amerikanischen Cybersecurity and Infrastructure Security Agency (CISA). Unter [2] finden Sie den Quelltext der Ansible-Rolle, der auf den genannten Distributionen unattended Upgrades entlang der Empfehlungen dieses Artikels automatisch einrichtet.

SLES-Admins schauen hier allerdings in die Röhre. Das ist sicherlich auch auf das bereits beschriebene Fehlen eines Updatemechanismus fernab von SUSE Manager zurückzuführen. Zwar lässt sich die gewünschte Funktionalität mittels

eines YaST-Profils nachrüsten, doch schweigt sich selbst die SUSE-eigene Dokumentation dazu weitgehend aus. Nicht verwunderlich ist deshalb, dass sich in der Open-Source-Community bis dato niemand gefunden hat, der eine Integration in Ansible oder einen anderen Automatisierer für die Funktion gebaut hat. Wer kein SLES betreibt, ist mit der beschriebenen Ansible-Rolle aber gut bedient. So gut, dass es sich unter Umständen lohnen kann, die Ansible-Rolle auch dann zu verwenden, wenn das eigene Set­up ansonsten eher auf Puppet, Chef oder eine andere Alternative setzt. Denn damit die beschriebene Ansible-Rolle ihren Dienst verrichtet, braucht sie im Grunde bloß eine lauffähige Version von "ansible-playbook" und ein Inventar aller zu bearbeitenden Systeme.

Die Möglichkeit effizienter automatischer Updates bieten alle großen Distributionen. Doch gibt das Feature sich bei RHEL, Debian und Ubuntu deutlich zutraulicher als bei SLES. Denn sowohl Red Hat als auch Debian haben "unattended upgrades" umfassend implementiert, inklusive der benötigten Parameter zur Konfiguration der Funktion. SUSE bietet in der Standardkonfiguration entsprechende Möglichkeiten gar nicht, diese lassen sich entweder durch die in AutoYaST beschriebene Funktionalität nachrüsten oder zentral über "SUSE Manager" steuern. Letzterer Ansatz ist freilich der vom Anbieter bevorzugte. Und das sicher nicht zuletzt deswegen, weil er Geld in die Kassen der Susen spült.

Fraglich ist indes, wie lange das Unattended-Upgrade-Feature für Linux-Distributionen überhaupt noch relevant sein wird. Denn ob sie es wollen oder nicht: Landauf wie landab werden Admins gerade durch die großen Hersteller mit Containern beglückt. Diesen liegt eine komplett andere Logik in der Updateverwaltung zugrunde, denn hier werden löchrige oder fehlerhafte Container einfach durch neue, aktualisierte Versionen ihrer selbst ersetzt. Vom Rumpfsystem, das zum Container-Spieler degradiert ist, bleibt nur der Kernel samt Runtime für die Container übrig. Und denen geht im Zweifelsfall das Lifecycle-Management an den Kragen – im Kontext umfassender CI/CD-Lösungen ist es meist schneller, ein System aus der Dose neu und samt aller nötigen Updates zu installieren, als diese nachträglich einzuspielen. Gut möglich also, dass die Situation im Hinblick auf automatische Updates in zehn Jahren eine völlig andere ist.