Unattended-Upgrades unter Ubuntu: Was die Standardkonfiguration installiert und was sie auslässt

„Automatische Sicherheitsupdates sind aktiviert“: Mit diesem Satz enden viele Server-Audits. Er stimmt auf den meisten Ubuntu-Systemen, und er beschreibt weniger, als es scheint. Das Paket, das die Arbeit erledigt, unattended-upgrades, wird mit einer Konfigurationsdatei ausgeliefert, deren Kommentare genau festhalten, was eingeschaltet ist, was ausgeschaltet ist und was nie zum Umfang gehörte.

Dieser Leitfaden liest die Datei so, wie das Upstream-Projekt sie ausliefert, Option für Option, und zeigt, wie sich jeder Punkt auf dem eigenen System prüfen lässt.

Die kurze Antwort

Mit der Standardkonfiguration gilt für unattended-upgrades:

• Es installiert Pakete aus dem Release-Pocket und dem Pocket -security, dazu aus den ESM-Sicherheits-Pockets, sofern sie auf dem System verfügbar sind.
• Es installiert nichts aus -updates, -proposed oder -backports, denn diese Zeilen sind auskommentiert.
• Es startet nicht neu, weil Automatic-Reboot standardmäßig false ist.
• Es benachrichtigt niemanden, weil Unattended-Upgrade::Mail standardmäßig eine leere Zeichenkette ist.
• Es rührt Fremdquellen nicht an, weil nur die aufgelisteten Origins erlaubt sind.

Jede dieser Voreinstellungen ist eine bewusste Entscheidung, und jede lässt sich mit etwa drei Zeilen ändern.

Zwei Dateien, zwei Aufgaben

Das Verhalten verteilt sich auf zwei Dateien in /etc/apt/apt.conf.d/.

20auto-upgrades ist der Schalter. In der Upstream-Fassung enthält die Datei genau zwei Zeilen:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Die README des Projekts beschreibt ihre Bedeutung nüchtern: Das System prüft jeden Tag auf Updates und installiert sie, sofern das möglich ist. Wer einen der beiden Werte auf "0" setzt, hält den jeweiligen Schritt an.

50unattended-upgrades ist die Richtlinie: welche Pakete infrage kommen und was nach der Installation geschieht. Alles Folgende stammt aus dieser zweiten Datei.

Welche Werte das eigene System tatsächlich anwendet, nachdem alle Fragmente zusammengeführt wurden, zeigt der Befehl, auf den die README verweist:

apt-config dump | grep -E 'Periodic|Unattended'

Was „Allowed-Origins“ wirklich erlaubt

Der Kern der Richtlinie ist eine einzige Liste. In der Ubuntu-Variante der Datei lautet sie:

Unattended-Upgrade::Allowed-Origins {
	"${distro_id}:${distro_codename}";
	"${distro_id}:${distro_codename}-security";
	"${distro_id}ESMApps:${distro_codename}-apps-security";
	"${distro_id}ESM:${distro_codename}-infra-security";
//	"${distro_id}:${distro_codename}-updates";
//	"${distro_id}:${distro_codename}-proposed";
//	"${distro_id}:${distro_codename}-backports";
};

(Die beiden ESM-Zeilen mit legacy-security sind hier der Kürze halber weggelassen.) Zeilen, die mit // beginnen, sind Kommentare. -updates ist also kein erlaubter Origin. Eine Korrektur, die Ihr Release nur über das Pocket -updates erreicht, wartet auf ein manuelles apt upgrade.

Der Kommentar über der Liste erklärt, warum das einfache Release-Pocket überhaupt enthalten ist: Unter Ubuntu können Sicherheitsupdates neue Abhängigkeiten aus Quellen außerhalb von Security nachziehen (als Beispiel wird chromium genannt), und durch das erlaubte Release-Pocket werden diese automatisch mitinstalliert.

Die README ergänzt eine Regel, die folgenreicher ist, als sie wirkt: Das Werkzeug installiert keine Pakete, deren Abhängigkeiten sich nicht aus erlaubten Origins beziehen lassen. Ein Sicherheitsupdate, dessen Abhängigkeit in einem nicht erlaubten Pocket liegt, wird zurückgehalten, ohne Fehlermeldung auf dem Bildschirm.

Fremdquellen stehen nicht auf der Liste

Das Docker-Repository, ein PPA, die apt-Quelle eines Herstellers: Keine davon passt auf ${distro_id}:${distro_codename}-security, also wird keine automatisch aktualisiert. Software aus diesen Quellen bleibt auf dem Stand, den Sie zuletzt von Hand installiert haben.

Die README dokumentiert die Abhilfe. Jedes Repository hat einen Origin und ein Archiv, sichtbar in den Feldern o= und a= der Ausgabe von:

apt-cache policy

Tragen Sie das dort abgelesene Paar in Ihre eigene Override-Datei ein (siehe unten), statt es zu raten. Die README dokumentiert außerdem Origins-Pattern, das mit Glob-Mustern wie "site=www.example.com,component=main" arbeitet.

Der Neustart, den niemand geplant hat

Das ist die Lücke mit den größten Folgen. In der Datei steht:

// Automatically reboot *WITHOUT CONFIRMATION* if
//  the file /var/run/reboot-required is found after the upgrade
//Unattended-Upgrade::Automatic-Reboot "false";

Der Standardwert ist false. Braucht ein Upgrade einen Neustart, um wirksam zu werden, wird die Markerdatei /var/run/reboot-required angelegt, und sonst geschieht nichts. Das korrigierte Kernel-Paket ist installiert, während der alte Kernel weiterläuft: Der Patch liegt auf der Platte, nicht im Arbeitsspeicher. Der Audit-Satz „Sicherheitsupdates laufen automatisch“ bleibt die ganze Zeit über wahr.

Prüfen lässt sich jedes System mit einer Zeile:

test -f /var/run/reboot-required && echo "reboot pending"

Soll das System selbst neu starten, bietet die Datei zwei Einstellungen, die zusammengehören:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

Ohne die zweite gilt der Standardwert "now", also unmittelbar nach dem Upgrade. Zu beachten ist auch, dass Automatic-Reboot-WithUsers standardmäßig true ist: Angemeldete Benutzer verhindern den Neustart nicht, solange Sie den Wert nicht auf false setzen.

Auf einem System, das nicht unbeaufsichtigt neu starten kann (ein primärer Datenbankserver, ein Host mit verschlüsseltem Root-Volume, das beim Booten eine Passphrase verlangt), lassen Sie den Neustart ausgeschaltet und lösen die andere Hälfte des Problems: den ausstehenden Neustart sichtbar machen.

Schweigen ist die Voreinstellung

Unattended-Upgrade::Mail ist im Auslieferungszustand leer, und die Datei benennt die Folge ausdrücklich: Ist der Wert leer oder nicht gesetzt, wird keine E-Mail verschickt. Sie nennt auch die Voraussetzung: eine funktionierende Mail-Einrichtung und ein Paket, das mailx bereitstellt.

MailReport kennt drei Werte: "always", "only-on-error" und "on-change". Auf einem einzelnen Server liefert "on-change" ein Protokoll jedes Pakets, das sich bewegt hat. In einer größeren Flotte hält "only-on-error" das Postfach lesbar.

Kommt E-Mail nicht infrage, gibt es einen zweiten Kanal. SyslogEnable ist standardmäßig false. Auf true gesetzt, gehen die Ereignisse an syslog, was laut README in Umgebungen nützlich ist, in denen Syslog-Meldungen an einen zentralen Speicher gesendet werden.

Wo man nachsieht, wenn scheinbar nichts passiert

Die README nennt den Ort: Alle Vorgänge werden in /var/log/unattended-upgrades/ protokolliert, einschließlich der Ausgabe von dpkg. Die Hauptdatei ist /var/log/unattended-upgrades/unattended-upgrades.log.

Was der nächste Lauf tun würde, ohne etwas zu verändern, zeigt der Befehl, den das Projekt zur Fehlersuche empfiehlt:

sudo unattended-upgrade --debug --dry-run

Die Ausgabe listet die erlaubten Origins so auf, wie das Werkzeug sie verstanden hat, danach jedes Kandidatenpaket samt dem Grund, warum es übernommen oder übersprungen wurde. Schneller lässt sich nicht bestätigen, dass ein hinzugefügtes Repository wirklich erfasst wird.

Drei Ursachen für ein nicht aktualisiertes Paket stehen in der Dokumentation des Projekts selbst:

1. Der Origin ist nicht erlaubt. Siehe die Liste oben.
2. Eine Abhängigkeit stammt aus einem nicht erlaubten Origin. Das Paket wird zurückgehalten.
3. Das Paket würde nach einer Konfigurationsdatei fragen. Laut README prüft das Werkzeug vor der Installation auf Conffile-Rückfragen und hält jedes Paket zurück, das eine solche verlangt.

Wann es läuft

Der Zeitplan steht nicht in den Dateien von unattended-upgrades. Er stammt aus zwei systemd-Timern, die apt mitbringt. Im Quellbaum von apt, gelesen am Tag der Entstehung dieses Artikels, löst apt-daily.timer um 6,18:00 mit RandomizedDelaySec=12h aus und übernimmt die Downloads, apt-daily-upgrade.timer löst um 6:00 mit RandomizedDelaySec=60m aus und übernimmt die Installation.

Beide tragen Persistent=true. Die systemd-Dokumentation definiert diese Einstellung: Der Dienst wird sofort ausgelöst, wenn er in der Zeit, in der der Timer inaktiv war, mindestens einmal ausgelöst worden wäre. Sie beschreibt das als nützlich, um verpasste Läufe nachzuholen, wenn das System ausgeschaltet war. Ein Laptop, der sein Zeitfenster verschlafen hat, aktualisiert sich daher kurz nach dem Aufwachen.

Ihre Distribution kann andere Werte ausliefern. Lesen Sie die eigenen:

systemctl cat apt-daily-upgrade.timer
systemctl list-timers 'apt-daily*'

Warum das Herunterfahren manchmal wartet

Hängt das Herunterfahren einen Moment, während ein Upgrade läuft, ist das so vorgesehen. Der Kommentar zu MinimalSteps erklärt, dass das Upgrade in möglichst kleine Schritte zerlegt wird, damit es sich mit SIGTERM unterbrechen lässt, und dass ein Herunterfahren während eines Upgrades dadurch mit kurzer Verzögerung möglich ist. Die Datei hält außerdem fest, dass unattended-upgrades dafür den Wert InhibitDelayMaxSec von logind auf 30 Sekunden anhebt.

In diesem Moment den Strom zu kappen, ist die schlechteste Reaktion. Passiert es doch, führt AutoFixInterruptedDpkg, standardmäßig true, beim nächsten Lauf dpkg --force-confold --configure -a aus, um die unterbrochene Arbeit abzuschließen.

Ändern, ohne die ausgelieferte Datei anzufassen

Die README ist in diesem Punkt deutlich: Überschrieben werden soll in einem separaten APT-Konfigurationsfragment, weil Aktualisierungen der ausgelieferten Datei mit lokalen Änderungen kollidieren und damit das Update von unattended-upgrades selbst blockieren können. Die neue Datei muss nach 50unattended-upgrades sortiert werden, und die README schlägt den Namen 52unattended-upgrades-local vor.

Ein vernünftiger Ausgangspunkt für einen einzelnen Server, ausschließlich aus dokumentierten Optionen:

// /etc/apt/apt.conf.d/52unattended-upgrades-local
Unattended-Upgrade::Mail "you@example.com";
Unattended-Upgrade::MailReport "on-change";
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";

Eine Falle betrifft Listen. Die README warnt: Wer eine Liste wie Origins-Pattern ersetzen will, muss die mitgelieferte Liste zuerst mit einer #clear-Direktive leeren. Andernfalls gelten die eigenen Einträge zusätzlich zu den mitgelieferten, nicht an ihrer Stelle.

Um ein Paket von automatischen Upgrades auszunehmen, nimmt Package-Blacklist reguläre Ausdrücke in Python-Syntax entgegen. Das Beispiel in der Datei zeigt den klassischen Fehler: Ohne abschließendes $ trifft "libc6" jedes Paket, dessen Name mit diesen Zeichen beginnt. Die README nennt dazu eine Nebenwirkung, die man kennen sollte: Hängt Paket A von dem gesperrten Paket B ab, wird weder A noch B aktualisiert.

Abschalten, und warum das selten die richtige Wahl ist

Der unterstützte Weg ist der, den die README nennt:

sudo dpkg-reconfigure -plow unattended-upgrades

Der Befehl setzt die beiden periodischen Werte für Sie. Es gibt legitime Gründe dafür: ein Produktivsystem unter Change-Kontrolle, auf dem jede Paketbewegung geplant wird, oder ein Host, den ein Konfigurationswerkzeug verwaltet und selbst aktualisiert.

Auf jedem anderen System tauscht das Abschalten ein kleines, begrenztes Risiko (ein Update, das sich danebenbenimmt) gegen ein unbegrenztes (eine bekannte Schwachstelle, die offen bleibt, bis jemand daran denkt). Meist genügen die feineren Werkzeuge: das eine Paket sperren, das Ihnen Sorgen macht, oder die Läufe mit Update-Days auf bestimmte Tage beschränken, etwa mit Werten wie {"Mon";"Fri"}.

Ein Audit in fünf Minuten

Führen Sie diese Befehle auf einem Server aus, von dem Sie annehmen, dass er „sich selbst aktualisiert“:

1. apt-config dump | grep -E 'Periodic|Unattended': Stehen beide periodischen Werte auf "1", und welche Origins sind erlaubt?
2. apt-cache policy: Welche Repositories gibt es auf diesem System, die von der erlaubten Liste nicht abgedeckt sind?
3. test -f /var/run/reboot-required && echo pending: Steht ein Neustart aus?
4. tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.log: Wann fand der letzte Lauf statt, und was hat er getan?
5. sudo unattended-upgrade --debug --dry-run: Was würde der nächste Lauf tun, und was würde er zurückhalten?

Lauten die Antworten „ja, keine, nein, letzte Nacht, nichts zurückgehalten“, stimmt der Audit-Satz endlich.

Die Optionsnamen, Standardwerte und wiedergegebenen Kommentare stammen aus den Dateien 50unattended-upgrades.Ubuntu und 20auto-upgrades sowie aus der README des Upstream-Repositorys von unattended-upgrades. Die Timer-Werte stammen aus dem Quellbaum von apt, die Definition von Persistent= aus dem Handbuch systemd.timer. Alle Quellen wurden am 7. Oktober 2026 gelesen. Paketierte Versionen unterscheiden sich je nach Release, maßgeblich ist daher die Datei auf Ihrem eigenen System.

Automatisches Patchen ist eine Schicht unter mehreren: Das Gesamtbild steht im Leitfaden zur Linux-Härtung, die Kontrollen auf Dienstebene behandelt systemd-Dienste härten.