Warum unattended-upgrades bei Debian nichts tut

Warum unattended-upgrades bei einer neuen Debian-Installation nichts tut

Unter Debian kann unattended-upgrades installiert sein und trotzdem kein einziges Upgrade ausführen, weil die Installation des Pakets und seine Aktivierung zwei getrennte Schritte sind. Das Paket stellt vor der Konfiguration eine debconf-Frage, und der Debian-Installer speichert die Antwort false auf diese Frage. Ubuntu beantwortet dieselbe Frage anders. Deshalb wirkt dasselbe Paket dort funktionsfähig und hier fehlerhaft.

Auf dem System weist nichts darauf hin. Beim Booten erscheint kein Fehler, bei der Anmeldung keine Warnung, und es gibt keine Logdatei, die Sie prüfen können, weil der Code, der diese Logdatei schreiben würde, nie aufgerufen wird. Die Aktivierung erfolgt mit einem Befehl. Der restliche Leitfaden behandelt die vier Punkte, die unattended-upgrades danach weiterhin stoppen können: aus welchen Repositories es Upgrades installieren darf, wann die systemd-Timer tatsächlich ausgelöst werden, wie Sie feststellen, dass ein Lauf fehlgeschlagen ist, und ob der Rechner sich selbst neu starten darf.

Geben Sie aus, was Ihr System vor Änderungen annimmt

dpkg -l unattended-upgrades | tail -n 1
sudo apt install -y debconf-utils
sudo debconf-show unattended-upgrades
cat /etc/apt/apt.conf.d/20auto-upgrades
apt-config dump APT::Periodic

debconf-show gibt den gespeicherten Wert von unattended-upgrades/enable_auto_updates aus. Ein * am Anfang dieser Zeile bedeutet, dass ein Wert gesetzt wurde, statt den Paketstandard zu verwenden. Auf einem System, das mit dem Debian-Installer installiert wurde, stammt dieser Wert vom Installer.

cat gibt möglicherweise cat: /etc/apt/apt.conf.d/20auto-upgrades: No such file or directory aus. Das erklärt die ausbleibende Ausführung bereits allein: Ohne Datei gibt es keine periodischen Schlüssel, daher wird nie etwas eingeplant.

apt-config dump ist der entscheidende Befehl. APT liest die Dateien in /etc/apt/apt.conf.d/ in der Reihenfolge ihrer Dateinamen und führt sie zusammen. Daher überschreibt ein einfacher Wert in 99local denselben Wert in 20auto-upgrades. Es werden nur Namen ohne Erweiterung oder mit der Erweiterung .conf berücksichtigt. Eine Datei wie 99local.bak wird daher übersprungen. Wenn Sie eine einzelne Datei lesen, sehen Sie, was in dieser Datei steht. apt-config dump zeigt, was APT tatsächlich ausführen wird.

Zwei Schlüssel bestimmen, ob überhaupt etwas geschieht:

• APT::Periodic::Update-Package-Lists aktualisiert die Paketlisten. Das ist die Aufgabe, die apt update manuell ausführt.
• APT::Periodic::Unattended-Upgrade führt das Upgrade selbst aus.

Ihre Werte sind nicht wahr oder falsch. Es handelt sich um Intervalle in Tagen. "1" bedeutet „ausführen, wenn dies im letzten Tag nicht geschehen ist“, "7" bedeutet wöchentlich und "0" bedeutet nie. APT::Periodic::Unattended-Upgrade "0"; ist eine gültige Konfiguration, die dauerhaft nichts ausführt, ohne auch nur einmal einen Fehler zu melden. Wenn Ihre Ausgabe für diesen Schlüssel 0 zeigt oder der Schlüssel überhaupt nicht vorhanden ist, haben Sie den Grund gefunden.

Aktivieren mit dpkg-reconfigure oder durch manuelles Schreiben der Schlüssel

sudo apt update
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

Die Frage hat eine niedrige Priorität. Deshalb wird sie bei einer normalen Installation nicht angezeigt. dpkg-reconfigure zeigt Fragen mit niedriger Priorität unabhängig von der konfigurierten debconf-Priorität an. --priority=low legt daher nur ausdrücklich fest, was ohnehin bereits geschieht. Das einzige zu vermeidende Flag ist --default-priority. Es deaktiviert dieses Verhalten und blendet die Frage wieder aus. Beantworten Sie den Dialog mit yes. Das postinst-Skript des Pakets schreibt anschließend /etc/apt/apt.conf.d/20auto-upgrades anhand Ihrer Antwort.

Auf einem Rechner, den Sie per Skript erstellen, gibt es keinen Dialog. Setzen Sie die Antwort daher vorher:

echo 'unattended-upgrades unattended-upgrades/enable_auto_updates boolean true' \
  | sudo debconf-set-selections
sudo dpkg-reconfigure -f noninteractive unattended-upgrades
apt-config dump APT::Periodic

Sie können die beiden Schlüssel auch direkt schreiben:

printf 'APT::Periodic::Update-Package-Lists "1";\nAPT::Periodic::Unattended-Upgrade "1";\n' \
  | sudo tee /etc/apt/apt.conf.d/20auto-upgrades
apt-config dump APT::Periodic

Das wirkt sofort, hinterlässt aber eine Fehlerquelle. Die debconf-Antwort enthält weiterhin den alten Wert. Beim nächsten dpkg-reconfigure oder bei einer erneuten Installation des Pakets schreibt das postinst-Skript die Datei erneut aus den debconf-Daten und verwirft Ihre Änderung, ohne eine Ausgabe zu erzeugen. Setzen Sie beide Werte oder konfigurieren Sie debconf und überlassen Sie die Datei dem postinst-Skript.

Das ist der wesentliche Unterschied zur anderen Variante dieser Familie. Dort aktiviert das Installationsprogramm dasselbe Paket für Sie. Die Ubuntu-Konfiguration für unattended-upgrades geht daher von einem System aus, das bereits automatisch Aktualisierungen installiert, und konzentriert sich auf die Feinabstimmung. Alles Folgende gilt für beide Varianten.

Welche Updates installiert Debian tatsächlich für Sie?

Das Aktivieren des Timers bedeutet nicht, dass automatisch alles installiert wird. Jede Paketquelle enthält Metadaten zum Release: Origin, Label, Suite, Codename und Site. unattended-upgrades prüft die verfügbare Version jedes aktualisierbaren Pakets, liest die Metadaten der Paketquelle, aus der diese Version stammen würde, und installiert sie nur, wenn die Quelle einem Eintrag in Unattended-Upgrade::Origins-Pattern oder in der älteren Liste Unattended-Upgrade::Allowed-Origins entspricht. Gibt es keine Übereinstimmung, wird das Paket bewusst und ohne Meldung nicht aktualisiert.

Geben Sie zuerst Ihre Muster und anschließend die Metadaten aus, gegen die sie abgeglichen werden:

apt-config dump Unattended-Upgrade::Origins-Pattern
grep -H -E '^(Origin|Label|Suite|Codename|Components):' /var/lib/apt/lists/*Release
apt-cache policy

grep -H lässt den Dateinamen in jeder Zeile stehen. Dadurch sehen Sie, zu welchem Quellenblock die jeweiligen Metadaten gehören. Diese Feldwerte sind die rechten Seiten Ihrer Muster. ${distro_codename} wird in einem Muster zur Laufzeit durch den Codename des verwendeten Releases ersetzt. Dadurch funktioniert eine Datei auch nach einem Release-Upgrade weiter.

Lesen Sie Ihre Muster zusammen mit den zugehörigen Metadaten. Die Antwort auf die Frage „Erhalte ich nur Sicherheitsupdates oder auch Updates für Point-Releases?“ steht ausschließlich in diesen beiden Listen:

• Ein Muster mit label=Debian-Security entspricht dem Security-Archiv. Dort werden die Debian-Sicherheitsmeldungen veröffentlicht.
• Ein Muster mit der Suite -updates entspricht stable-updates. Diese Suite enthält Änderungen, die Debian zwischen Point-Releases veröffentlicht, beispielsweise Zeitzonendaten.
• Ein Muster mit der Suite des eigentlichen Releases übernimmt Änderungen aus Point-Releases, sobald diese veröffentlicht werden. Das bedeutet mehr Änderungen und mehr Testaufwand auf Ihrer Seite.
• Eine selbst hinzugefügte Paketquelle entspricht zunächst keiner Regel. Erst ein dafür angelegtes Muster wird berücksichtigt.

Dieser letzte Punkt überrascht viele Benutzer. Eine Paketquelle eines Drittanbieters hat ein eigenes Origin und ein eigenes Label. unattended-upgrades sieht die verfügbare Version, stellt fest, dass die Quelle keinem Muster entspricht, und fährt fort. Das Hinzufügen eines Musters für diese Quelle sollten Sie sorgfältig abwägen. Ein Anbieter kann innerhalb derselben Suite eine neue Hauptversion veröffentlichen. Damit würden Sie unbeaufsichtigten Upgrades auf neue Hauptversionen dieser Software mitten in der Nacht zustimmen.

unattended-upgrades führt Sie außerdem nie von einem Debian-Release in ein anderes. Es aktualisiert Pakete innerhalb des verwendeten Releases. Der Wechsel von einem stabilen Release zum nächsten bleibt eine manuelle Aufgabe, die Sie selbst planen.

Beachten Sie beim Ändern der Liste, dass APT-Listen Einträge anhängen. Ein zweiter Origins-Pattern-Block in einer anderen Datei ergänzt die mitgelieferte Liste, anstatt sie zu ersetzen. Leeren Sie die bestehende Liste daher zuerst, wenn Sie sie ersetzen möchten:

#clear Unattended-Upgrade::Origins-Pattern;
Unattended-Upgrade::Origins-Pattern {
  "origin=Debian,codename=${distro_codename},label=Debian-Security";
  "origin=Debian,codename=${distro_codename}-security,label=Debian-Security";
};

Legen Sie lokale Änderungen in einer neuen Datei ab, die nach der mitgelieferten Datei sortiert wird, beispielsweise /etc/apt/apt.conf.d/52unattended-upgrades-local. 50unattended-upgrades ist eine verwaltete Konfigurationsdatei. Sobald Sie sie bearbeitet haben, hält ein späteres Paket-Upgrade mit einer geänderten Version dieser Datei an und fragt, wie mit Ihrer Version verfahren werden soll. Eine separate Datei verursacht keinen Konflikt.

Zwei weitere Schlüssel sollten Sie bei dieser Gelegenheit ausgeben. Unattended-Upgrade::Allowed-Origins ist die ältere Form desselben Konzepts. Sie verwendet origin:archive-Paare und wird weiterhin eingelesen. Eine aus einem Tutorial kopierte Konfiguration enthält daher häufig beide Listen, ohne eindeutig erkennen zu lassen, welche Liste zugeordnet wurde. Unattended-Upgrade::Package-Blacklist enthält reguläre Ausdrücke, die gegen Paketnamen abgeglichen werden. Ein zu weit gefasster Ausdruck verhindert dort deutlich mehr Aktualisierungen als beabsichtigt. Der folgende Probelauf zeigt, welche Regeln tatsächlich angewendet wurden.

Warum wurde zum erwarteten Zeitpunkt nichts ausgeführt?

Zwei systemd-Timer steuern diesen Vorgang, und sie haben unterschiedliche Aufgaben. apt-daily.timer startet apt-daily.service. Dieser aktualisiert die Paketlisten und lädt Pakete herunter. apt-daily-upgrade.timer startet apt-daily-upgrade.service. Dieser ruft unattended-upgrade auf. Beide führen /usr/lib/apt/apt.systemd.daily mit unterschiedlichen Argumenten aus. Wenn der zweite Timer deaktiviert oder maskiert ist, können beide regelmäßigen Schlüssel 1 lesen, ohne dass jemals etwas installiert wird.

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

list-timers liefert für jede Unit NEXT, LEFT, LAST und PASSED. Ein Timer ohne NEXT wird nicht ausgeführt. Wenn is-enabled masked ausgibt, wurde der Timer ausdrücklich deaktiviert. Nichts, was Sie in apt.conf.d eintragen, ändert daran etwas.

Lesen Sie nun den Abschnitt [Timer], den systemctl cat ausgegeben hat. OnCalendar ist der früheste Zeitpunkt, zu dem der Timer ausgelöst werden kann. RandomizedDelaySec fügt danach eine zufällige Wartezeit hinzu. Dadurch greifen viele Debian-Rechner nicht in derselben Sekunde auf dieselben Spiegelserver zu. Deshalb zeigt die Spalte NEXT eine Zeit, die nicht mit OnCalendar übereinstimmt. Deshalb erfolgte der Lauf gestern zu einer anderen Minute. Das Verhalten ist beabsichtigt. Persistent=true bedeutet, dass ein Rechner, der zum geplanten Zeitpunkt ausgeschaltet war, den Auftrag kurz nach dem nächsten Boot ausführt, statt ihn für diesen Tag zu überspringen.

Um das Zeitfenster zu verschieben, überschreiben Sie die Unit, statt sie zu bearbeiten:

sudo systemctl edit apt-daily-upgrade.timer

[Timer]
OnCalendar=
OnCalendar=03:30
RandomizedDelaySec=30m

Die leere Zeile OnCalendar= ist erforderlich, weil sich Einstellungen mit mehreren Werten in Units ansammeln: Wenn Sie sie weglassen, bleibt der ausgelieferte Zeitplan erhalten und ein zweiter kommt hinzu. systemctl edit lädt systemd für Sie neu. Bestätigen Sie das Ergebnis daher mit systemctl list-timers 'apt-daily*' und prüfen Sie den neuen NEXT.

Sie müssen nie auf einen Timer warten, um dies zu testen:

sudo systemctl start apt-daily-upgrade.service
journalctl -u apt-daily-upgrade.service --since -1h

Ein Punkt verwirrt Benutzer, die in /etc/cron.daily suchen: APT liefert /etc/cron.daily/apt-compat weiterhin für Systeme ohne systemd aus. Lesen Sie die Datei mit cat. Auf einem systemd-System wird sie frühzeitig beendet, sodass der Vorgang nicht zweimal ausgeführt wird.

Nachweis: unattended-upgrade --dry-run --debug funktioniert

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

Der Befehl steht im Singular, der Paketname im Plural. Debian 12 und 13 enthalten außerdem ein /usr/bin/unattended-upgrades, sodass der Plural dort nicht mehr mit command not found endet. Der dokumentierte Befehl und der in dieser Anleitung durchgehend verwendete Befehl lautet jedoch unattended-upgrade.

Dieser eine Befehl beantwortet fast jede Frage nach dem Muster „Warum wurde dieses Paket übersprungen?“, weil er seine Entscheidung selbst ausgibt. Nahe am Anfang zeigt er die Ursprünge an, die er aus Ihren Mustern ermittelt hat:

Allowed origins are: ...

Danach folgt eine Zeile für jedes mögliche Paket. Sie enthält den Ursprungsdatensatz der Version, die installiert würde:

Checking: curl ([<Origin component:'main' archive:'stable' origin:'Debian' label:'Debian' site:'deb.debian.org' isTrusted:True>])

Anschließend folgt die Liste der Pakete, die bearbeitet würden. Auf einem System ohne anstehende Aktionen ist die Liste leer:

No packages found that can be upgraded unattended and no pending auto-removals

Setzen Sie die erste und die zweite Ausgabe zusammen, ist die Diagnose direkt möglich. Suchen Sie die Checking:-Zeile des Pakets, dessen Upgrade Sie erwartet haben. Vergleichen Sie den Ursprungsdatensatz Feld für Feld mit den darüber ausgegebenen zulässigen Ursprüngen. Ein nicht übereinstimmendes Feld, meist label oder archive, ist der vollständige Grund, warum das Paket übersprungen wurde.

--dry-run markiert Pakete nur im Speicher und installiert nichts. Sie können den Befehl daher beliebig oft ausführen. Er hängt trotzdem Einträge an /var/log/unattended-upgrades/unattended-upgrades.log an.

Wenn die Ursprünge übereinstimmen und ein Paket weiterhin zurückgehalten wird, prüfen Sie die folgenden Punkte:

• apt-mark showhold listet Pakete auf, die von Ihnen oder einem Tool gepinnt wurden. unattended-upgrades verschiebt kein zurückgehaltenes Paket.
• Für das Upgrade müsste ein weiteres Paket entfernt oder hinzugefügt werden. unattended-upgrades vermeidet das, sofern die entsprechenden Schlüssel dies nicht erlauben. Vergleichen Sie die Ausgabe daher mit sudo apt-get -s upgrade. Dieser Befehl zeigt dieselbe Entscheidung ohne diese Sicherheitsregeln.
• dpkg ist nach einem unterbrochenen Lauf nur teilweise konfiguriert. Beheben Sie das mit sudo dpkg --configure -a und prüfen Sie die Ausgabe anschließend erneut.
• /var hat keinen freien Speicherplatz. Deshalb werden keine Pakete heruntergeladen oder entpackt. Prüfen Sie dies mit df -h /var.
• /boot ist mit alten Kerneln gefüllt. Dadurch schlägt das nächste Kernel-Upgrade fehl. Prüfen Sie dies mit df -h /boot und geben Sie apt-config dump Unattended-Upgrade::Remove-Unused-Kernel-Packages aus, um festzustellen, ob die Bereinigung aktiviert ist.

Wenn Sie apt manuell ausführen, während der Timer aktiv ist, erhalten Sie Could not get lock /var/lib/dpkg/lock-frontend. Diese Meldung bedeutet, dass unattended-upgrades ordnungsgemäß arbeitet. Warten Sie, bis der Vorgang abgeschlossen ist.

Wie finden Sie heraus, wann ein Lauf fehlschlägt?

Beginnen Sie mit den Logs, da diese unabhängig von jeder weiteren Konfiguration vorhanden sind:

sudo tail -n 40 /var/log/unattended-upgrades/unattended-upgrades.log
sudo tail -n 40 /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
journalctl -u apt-daily-upgrade.service --since -7d

Die erste Datei ist das Entscheidungs-Log: Welche Prüfungen durchgeführt, welche Auswahl getroffen und welche Pakete installiert wurden. Die zweite Datei enthält die rohe Ausgabe von dpkg. Dort ist erkennbar, wenn das postinst-Skript eines Pakets fehlschlägt. Ein separates Shutdown-Log wird erstellt, wenn Upgrades während des Herunterfahrens ausgeführt werden.

E-Mail ist der übliche Benachrichtigungsweg:

Unattended-Upgrade::Mail "you@example.com";
Unattended-Upgrade::MailReport "on-change";

MailReport akzeptiert always, on-change und only-on-error. only-on-error klingt nach der disziplinierten Wahl und ist auf einem Server, an dem sich niemand anmeldet, normalerweise die falsche Option. Wenn ein Rechner keine Upgrades mehr ausführt, sendet er ebenfalls keine Fehler. Die Stille sieht dann für einen funktionierenden und einen ausgefallenen Rechner gleich aus. on-change sendet Ihnen bei jeder Installation eine E-Mail. Dadurch dient die E-Mail zugleich als Nachweis, dass der Timer noch aktiv ist.

E-Mails verlassen den Rechner nur, wenn der Rechner E-Mails senden kann. unattended-upgrades übergibt die Nachricht an das lokale Mailsystem. Sie benötigen daher einen MTA (mail transfer agent) wie postfix oder einen mit sendmail kompatiblen Relay-Client wie msmtp. Prüfen Sie dies mit command -v sendmail und command -v mail. Ist keines von beiden vorhanden, wird der Bericht nirgendwohin gesendet. Das Upgrade läuft trotzdem erfolgreich durch, und der gesamte Fehler bleibt unsichtbar. Beachten Sie außerdem, dass eine neue VPS-IP-Adresse keine Reputation für den E-Mail-Versand besitzt. Direkt an ein öffentliches Postfach gesendete E-Mails landen daher häufig im Spam. Das Relay über einen bereits verwendeten Mailprovider ist zuverlässiger, als dafür einen eigenen Server zu betreiben.

Wenn Sie ganz auf E-Mail verzichten möchten, überwachen Sie den Zeitstempel des Logs über das Monitoring, das Sie bereits einsetzen:

stat -c '%y %n' /var/log/unattended-upgrades/unattended-upgrades.log

Wenn sich ein Zeitstempel eine Woche lang nicht ändert, wurde der Timer unabhängig von der Konfiguration angehalten. Diese Prüfung gehört neben die übrigen routinemäßigen Prüfungen für die Linux-Serverwartung.

Soll der Server sich selbst neu starten?

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

Wenn Automatic-Reboot auf true gesetzt ist, führt unattended-upgrades den Neustart ohne Bestätigung aus. Das geschieht nur, wenn die Datei /var/run/reboot-required nach Abschluss des Durchlaufs vorhanden ist. Unter Debian 12 und 13 erstellt das Paket unattended-upgrades diese Markierungsdatei über einen Kernel-Hook, /etc/kernel/postinst.d/unattended-upgrades, der beim Installieren eines Kernel-Pakets ausgeführt wird. Ein Bibliotheks-Upgrade löst ihn nicht aus. Gehen Sie nicht davon aus, dass die Datei vorhanden ist. Prüfen Sie dies nach dem nächsten Kernel-Upgrade:

ls -l /var/run/reboot-required /var/run/reboot-required.pkgs
uname -r
dpkg -l 'linux-image-*' | grep '^ii'

Wenn die Datei auf Ihrem System nie erscheint, wird Automatic-Reboot "true" nie ausgelöst. Dann können Sie monatelang davon ausgehen, dass Sie wegen Kernel-Updates neu starten, während tatsächlich noch der alte Kernel läuft. uname -r gegen das zuletzt installierte linux-image-Paket schafft Klarheit.

Automatic-Reboot-Time plant den Neustart für diese Uhrzeit, statt ihn sofort auszuführen. Mit Automatic-Reboot-WithUsers auf false wird der Neustart übersprungen, solange jemand angemeldet ist. Auf einem Server, auf dem immer eine Sitzung geöffnet ist, erfolgt dann überhaupt kein Neustart.

Bei dieser Entscheidung geht es darum, was beim anschließenden Hochfahren geschieht, nicht um den Neustart selbst. Ein Dienst, den jemand manuell gestartet hat, läuft danach nicht wieder. Ein verschlüsseltes Volume, das beim Booten eine Passphrase benötigt, wird nicht eingebunden. Zwei voneinander abhängige Rechner können in der falschen Reihenfolge wieder hochfahren. Aktivieren Sie den automatischen Neustart für einen zustandslosen Webserver, dessen Ausfall um 02:00 für eine Minute akzeptabel ist. Lassen Sie ihn dort deaktiviert, wo eine Person benötigt wird, und überwachen Sie stattdessen die Markierungsdatei, damit ein Mensch den Zeitpunkt festlegt. Dazwischen liegt needrestart. Es startet Dienste neu, die noch gegen eine aktualisierte Bibliothek laufen, und deckt damit alles außer dem Kernel ab. Im Standardmodus fragt es vor dem Neustart nach. Lesen Sie daher /etc/needrestart/needrestart.conf, bevor Sie es in einem unbeaufsichtigten Durchlauf verwenden.

Funktioniert das auf testing und unstable genauso?

Alles oben Beschriebene beschreibt Debian stable, wo Sicherheits-Patches aus einem separaten Archiv mit einem eigenen Label stammen. Diese Struktur ermöglicht es überhaupt erst, die Einstellung "nur Sicherheits-Updates" zu verwenden. Die anderen Suites sind anders aufgebaut, sodass eine von einem stable-Server kopierte Konfiguration weniger bewirkt, als der Autor erwartet. Zudem bedeuten automatische Upgrades bei einer sich ständig ändernden Suite unbeaufsichtigte Änderungen der Hauptversion. Diesen Änderungen zuzustimmen ist eine andere Entscheidung. Wenn Sie diese Wahl abwägen, behandelt den Betrieb von Debian stable, testing oder unstable auf einem Server, was die jeweilige Suite zusichert. Im Red Hat-Umfeld erfordert dieselbe Aufgabe ein anderes Werkzeug und eine andere Terminologie; dnf-automatic auf Rocky Linux und AlmaLinux erledigt dies mit einem eigenen Timer und einer eigenen Konfigurationsdatei.

Automatische Upgrades verkürzen die Zeitspanne zwischen der Veröffentlichung eines Patches und dessen Installation. Sie geben jedoch keinen Aufschluss darüber, was weiterhin anfällig ist. Kombinieren Sie diese daher mit einer Überprüfung auf bekannte CVEs auf Ihrem Server. CVE steht für Common Vulnerabilities and Exposures, die öffentliche Kennung, unter der ein Patch nachverfolgt wird.

Die Prüfung in fünf Minuten

1. apt-config dump APT::Periodic gibt beide Schlüssel mit einem Wert ungleich 0 aus.
2. systemctl list-timers 'apt-daily*' gibt für beide Timer eine NEXT-Zeit aus.
3. sudo unattended-upgrade --dry-run --debug gibt erlaubte Quellen aus, die das Security-Archiv für Ihren Codenamen enthalten.
4. sudo systemctl start apt-daily-upgrade.service wird erfolgreich abgeschlossen, und der Zeitstempel von /var/log/unattended-upgrades/unattended-upgrades.log ändert sich.
5. Eine Woche später führt dasselbe Log die Pakete auf, die es installiert hat.

Wenn die ersten vier Prüfungen erfolgreich sind, ist der Rechner konfiguriert. Wenn auch die fünfte erfolgreich ist, funktioniert die Konfiguration.

FAQ

Warum installiert Debian unattended-upgrades, lässt es aber deaktiviert?

Das Paket stellt die debconf-Frage unattended-upgrades/enable_auto_updates und schreibt den Wert aus der Antwort nach /etc/apt/apt.conf.d/20auto-upgrades. Der Debian-Installer speichert false für diese Frage. Deshalb wird das Paket, wenn es als Teil einer Task oder als Abhängigkeit installiert wird, so konfiguriert, dass es nichts tut. Führen Sie sudo debconf-show unattended-upgrades aus, um die gespeicherte Antwort anzuzeigen, und anschließend sudo dpkg-reconfigure --priority=low unattended-upgrades, um sie zu ändern. Die Frage hat eine niedrige Priorität. Eine normale Installation zeigt sie deshalb nicht an. dpkg-reconfigure zeigt Fragen mit niedriger Priorität standardmäßig an, sodass sie hier auch ohne das Flag erscheint.

Wie teste ich unattended-upgrades, ohne auf den Timer zu warten?

Führen Sie sudo unattended-upgrade --dry-run --debug aus. Der Befehl gibt die akzeptierten Ursprünge aus. Für jedes aktualisierbare Paket wird eine Checking:-Zeile mit dem zugehörigen Origin-Eintrag ausgegeben. Außerdem zeigt er die Liste der Pakete an, die installiert würden. Es wird dabei nichts installiert. Um den tatsächlichen Ablauf zu testen, führen Sie sudo systemctl start apt-daily-upgrade.service aus und lesen Sie anschließend journalctl -u apt-daily-upgrade.service --since -1h zusammen mit /var/log/unattended-upgrades/unattended-upgrades.log.

Installiert unattended-upgrades neben Sicherheitskorrekturen auch reguläre Updates?

Nur wenn ein Muster dies festlegt. Ein Paket-Upgrade wird installiert, wenn die Quelle des Pakets einem Eintrag in Unattended-Upgrade::Origins-Pattern oder im älteren Unattended-Upgrade::Allowed-Origins entspricht. Das Security-Archiv, die Suite stable-updates und jedes selbst hinzugefügte Repository sind separate Einträge. Geben Sie apt-config dump Unattended-Upgrade::Origins-Pattern und apt-config dump Unattended-Upgrade::Allowed-Origins auf Ihrem eigenen System aus und vergleichen Sie die Ergebnisse mit grep -H -E '^(Origin|Label|Suite|Codename):' /var/lib/apt/lists/*Release. Der Befehl wechselt außerdem nie zwischen Debian-Releases.

Warum wird das Upgrade nicht zu der im Timer festgelegten Zeit ausgeführt?

apt-daily-upgrade.timer setzt RandomizedDelaySec zusätzlich zu OnCalendar. systemd wählt deshalb einen zufälligen Zeitpunkt innerhalb dieses Zeitfensters, statt den Vorgang genau zur Kalenderzeit zu starten. Dadurch verteilt sich die Last auf alle Debian-Systeme, die dieselben Spiegelserver verwenden. systemctl list-timers 'apt-daily*' zeigt den tatsächlich gewählten Zeitpunkt an. Um das Zeitfenster zu ändern, führen Sie sudo systemctl edit apt-daily-upgrade.timer aus und übergeben eine leere OnCalendar=-Zeile, gefolgt von Ihrem eigenen Wert.

Sollte ich automatische Neustarts für Sicherheitsupdates aktivieren?

Nur wenn ein ungeplanter Neustart unkritisch ist. Unattended-Upgrade::Automatic-Reboot "true" führt ohne Bestätigung einen Neustart aus, sobald nach einem Lauf /var/run/reboot-required vorhanden ist. Unter Debian 12 und 13 wird diese Markierungsdatei von einem Kernel-Hook erzeugt, den das Paket unattended-upgrades bereitstellt. Sie erscheint daher nach Kernel-Upgrades, nicht aber nach Bibliotheks-Upgrades. Prüfen Sie nach einem Kernel-Upgrade, ob die Datei auf Ihrem System erscheint, bevor Sie dieser Einstellung vertrauen. Wenn das System beim Booten eine Passphrase benötigt oder Dienste ausführt, die jemand manuell gestartet hat, lassen Sie die Einstellung auf false und überwachen Sie die Markierungsdatei. So kann eine Person den geeigneten Zeitpunkt für den Neustart festlegen.