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.

Ausgeben, was Ihr System vor Änderungen ermittelt

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 für 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 eingerichtet wurde, war das der Installer.

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

apt-config dump ist der entscheidende Befehl. APT liest jede Datei in /etc/apt/apt.conf.d/ in Dateinamenreihenfolge ein und führt die Werte zusammen. Daher überschreibt ein einfacher Wert in 99local denselben Wert in 20auto-upgrades. Wenn Sie eine einzelne Datei lesen, sehen Sie, was diese Datei vorgibt. 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 nicht innerhalb des letzten Tages 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 eine Fehlermeldung auszugeben. Wenn Ihre Ausgabe für diesen Schlüssel 0 enthält oder der Schlüssel überhaupt nicht vorhanden ist, haben Sie die Ursache 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

--priority=low ist hier nicht optional. Die Frage hat eine niedrige Priorität. Bei der Standardpriorität gibt dpkg-reconfigure nichts aus, ändert nichts und beendet sich mit Exit-Code 0. Das sieht genauso aus wie ein erfolgreich ausgeführter Befehl. Beantworten Sie den Dialog mit Ja. 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 einrichten, gibt es keinen Dialog, den Sie beantworten können. Setzen Sie die Antwort daher zuerst:

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 Falle. Die Debconf-Antwort enthält weiterhin den alten Wert. Beim nächsten dpkg-reconfigure oder bei einer Neuinstallation des Pakets wird die Datei aus Debconf neu geschrieben. Ihre manuelle Änderung wird dabei völlig ohne Ausgabe rückgängig gemacht. Setzen Sie beide Werte oder setzen Sie Debconf und überlassen Sie die Datei dem Postinst-Skript.

Das ist der einzige wesentliche Unterschied zur anderen Variante dieser Pakktfamilie. Dort aktiviert das Installationsprogramm dasselbe Paket für Sie. Deshalb startet die Einrichtung von Ubuntu unattended-upgrades auf einem System, das sich bereits selbst mit Sicherheitsupdates versorgt, 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 Sie der Installation aller Updates zustimmen. Jede Paketquelle enthält Release-Metadaten: eine Herkunft, ein Label, eine Suite, einen Codenamen und eine Website. unattended-upgrades prüft die Kandidatenversion jedes aktualisierbaren Pakets, liest die Metadaten der Quelle, aus der es stammen würde, und installiert das Paket nur, wenn diese Quelle einem Eintrag in Unattended-Upgrade::Origins-Pattern 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, mit denen 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 belässt den Dateinamen in jeder Zeile. Dadurch sehen Sie, zu welchem Eintrag jeder Metadatenblock gehört. Diese Feldwerte stehen auf der rechten Seite Ihrer Muster. ${distro_codename} wird in einem Muster zur Laufzeit durch den Codenamen des verwendeten Releases ersetzt. Dadurch bleibt eine Datei auch nach einem Release-Upgrade funktionsfähig.

Lesen Sie Ihre eigenen Muster zusammen mit den zugehörigen Metadaten. Die Antwort auf die Frage, ob Sie nur Sicherheitskorrekturen oder auch Updates für Point-Releases erhalten, steht dort und nirgendwo sonst:

• Ein Muster mit label=Debian-Security trifft auf das Sicherheitsarchiv zu. Dort werden die Debian-Sicherheitshinweise veröffentlicht.
• Ein Muster mit der Suite -updates trifft auf stable-updates zu. Diese Quelle enthält Änderungen, die Debian zwischen Point-Releases veröffentlicht, beispielsweise Zeitzonendaten.
• Ein Muster mit der unveränderten Release-Suite übernimmt Änderungen aus Point-Releases, sobald diese veröffentlicht werden. Das führt zu mehr Änderungen und mehr Testaufwand auf Ihrer Seite.
• Eine von Ihnen selbst hinzugefügte Paketquelle trifft zunächst auf nichts zu, bis Sie dafür ein Muster festlegen.

Der letzte Punkt überrascht viele Benutzer. Eine Paketquelle eines Drittanbieters hat ihre eigene Herkunft und ihr eigenes Label. unattended-upgrades erkennt daher die Kandidatenversion, stellt aber fest, dass die Quelle keinem Muster entspricht, und fährt fort. Ein Muster für diese Quelle sollten Sie wohlüberlegt festlegen. Ein Anbieter kann innerhalb derselben Suite eine neue Hauptversion veröffentlichen. Damit würden Sie nächtlichen, unbeaufsichtigten Upgrades dieser Software zustimmen.

unattended-upgrades wechselt außerdem niemals zwischen Debian-Releases. Das Programm aktualisiert Pakete innerhalb des aktuell 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 ergänzt. Ein zweiter Origins-Pattern-Block in einer anderen Datei wird zur ausgelieferten Liste hinzugefügt, statt sie zu ersetzen. Wenn Sie die Liste ersetzen möchten, müssen Sie sie daher zuerst leeren:

#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 ausgelieferten Datei sortiert wird, beispielsweise /etc/apt/apt.conf.d/52unattended-upgrades-local. 50unattended-upgrades ist eine Conffile. Wenn Sie diese Datei bearbeiten, hält jedes künftige Paket-Upgrade 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 und wird als origin:archive-Paare geschrieben. Sie wird weiterhin gelesen. Daher enthält eine aus einem Tutorial kopierte Konfiguration häufig beide Listen, ohne dass eindeutig erkennbar ist, welche Liste zugetroffen hat. Unattended-Upgrade::Package-Blacklist enthält reguläre Ausdrücke, die mit Paketnamen abgeglichen werden. Ein zu weit gefasster Ausdruck kann dort deutlich mehr Pakete blockieren als beabsichtigt. Der folgende Probelauf gibt aus, 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

Die Binärdatei steht im Singular, der Paketname im Plural. Wenn Sie hier unattended-upgrades eingeben, erhalten Sie command not found. Viele interpretieren das fälschlich als Beleg dafür, dass das Paket fehlt.

Dieser eine Befehl beantwortet fast jede Frage nach dem Muster „Warum wurde dieses Paket übersprungen?“, weil er seine eigene Entscheidungsfindung ausgibt. Weiter oben zeigt er die Herkunftsangaben, die er aus Ihren Mustern berechnet hat:

Allowed origins are: ...

Danach folgt eine Zeile pro infrage kommendem Paket. Sie enthält den Herkunftseintrag 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 verarbeitet würden. Auf einem System ohne anstehende Aktionen sieht sie so aus:

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

Setzen Sie die ersten beiden Ausgaben zusammen, ist die Diagnose direkt möglich. Suchen Sie die Zeile Checking: für das Paket, dessen Upgrade Sie erwartet haben. Vergleichen Sie den Herkunftseintrag Feld für Feld mit den darüber ausgegebenen zulässigen Herkunftsangaben. Ein nicht übereinstimmendes Feld, meistens label oder archive, ist der vollständige Grund dafür, dass das Paket übersprungen wurde.

--dry-run bewertet Pakete nur im Arbeitsspeicher und installiert nichts. Sie können den Befehl daher beliebig oft ausführen. Er schreibt trotzdem weiter nach /var/log/unattended-upgrades/unattended-upgrades.log.

Wenn die Herkunftsangaben übereinstimmen und ein Paket weiterhin zurückgehalten wird, prüfen Sie diese Ursachen:

• apt-mark showhold listet Pakete auf, die Sie oder ein Tool festgesetzt haben. unattended-upgrades ändert kein festgehaltenes Paket.
• Für das Upgrade müsste ein weiteres Paket entfernt oder hinzugefügt werden. unattended-upgrades vermeidet das, sofern die relevanten Schlüssel dies nicht erlauben. Vergleichen Sie die Ausgabe daher mit sudo apt-get -s upgrade. Dort wird dieselbe Entscheidung ohne diese Sicherheitsregeln angezeigt.
• 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. Daher werden keine Pakete heruntergeladen oder entpackt. Prüfen Sie dies mit df -h /var.
• /boot ist mit alten Kerneln belegt. Dadurch schlägt das nächste Kernel-Upgrade fehl. Prüfen Sie 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.

Sollte der Server selbstständig 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 Laufs vorhanden ist. Diese Markierungsdatei wird nicht von unattended-upgrades angelegt. Ein anderes Paket muss sie erstellen. Unter Debian ist das normalerweise needrestart. Gehen Sie nicht davon aus, dass sie 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 diese Datei auf Ihrem System nie erscheint, wird Automatic-Reboot "true" nie ausgelöst. Sie können dann monatelang annehmen, dass Sie wegen Kernel-Updates neu starten, während weiterhin der alte Kernel läuft. uname -r gegen das neueste installierte linux-image-Paket schafft Klarheit.

Automatic-Reboot-Time plant den Neustart für diese Uhrzeit, statt ihn sofort auszuführen. Wenn Automatic-Reboot-WithUsers auf false gesetzt ist, wird der Neustart übersprungen, solange jemand angemeldet ist. Auf einem Server mit einer dauerhaft geöffneten Sitzung bedeutet das, dass er überhaupt nicht neu startet.

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 Systeme 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 weiterhin eine aktualisierte Bibliothek verwenden, und deckt damit alle Fälle außer dem Kernel ab. Im Standardmodus fragt es vor dem Neustart. Lesen Sie daher /etc/needrestart/needrestart.conf, bevor Sie sich bei einem unbeaufsichtigten Lauf darauf verlassen.

Funktioniert das auf testing und unstable genauso?

Alles oben beschreibt Debian stable, bei dem Sicherheitskorrekturen aus einem separaten Archiv mit eigener Bezeichnung eintreffen. Diese Struktur ermöglicht die Einstellung „nur Sicherheitsaktualisierungen“ überhaupt. Die anderen Suites sind anders aufgebaut. Eine von einem stable-Server kopierte Konfiguration passt daher weniger gut, als ihr Autor erwartet. Automatische Upgrades auf einer sich fortlaufend ändernden Suite bedeuten außerdem unbeaufsichtigte Änderungen an Hauptversionen. Dem stimmen Sie auf andere Weise zu. Wenn Sie diese Entscheidung abwägen, beschreibt Debian stable, testing oder unstable auf einem Server ausführen, was die einzelnen Varianten bieten. Auf der Red-Hat-Seite gibt es für dieselbe Aufgabe ein anderes Tool und eine andere Terminologie. dnf-automatic auf Rocky Linux und AlmaLinux erledigt sie mit einem eigenen Timer und einer eigenen Konfigurationsdatei.

Automatische Upgrades verkürzen den Zeitraum zwischen der Veröffentlichung einer Korrektur und ihrer Installation. Sie zeigen jedoch nicht, welche Schwachstellen weiterhin offen sind. Kombinieren Sie sie daher mit einer Prüfung Ihres Servers auf bekannte CVEs. CVE steht für common vulnerabilities and exposures. Das ist die öffentliche Kennung, unter der eine Korrektur verfolgt 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 eine debconf-Frage, unattended-upgrades/enable_auto_updates, und schreibt anhand der Antwort /etc/apt/apt.conf.d/20auto-upgrades. Der Debian-Installer speichert für diese Frage false. Wenn das Paket als Teil einer Task oder als Abhängigkeit installiert wird, wird es deshalb 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 niedrige Priorität ist wichtig, weil der Befehl bei der Standardpriorität beendet wird, ohne die Frage anzuzeigen.

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. Außerdem zeigt er für jedes aktualisierbare Paket eine Checking:-Zeile mit dem zugehörigen Origin-Eintrag sowie die 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 Sicherheitsupdates 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 entspricht. Das Security-Archiv, die Suite stable-updates und jedes von Ihnen hinzugefügte Repository sind separate Einträge. Geben Sie auf Ihrem eigenen System apt-config dump Unattended-Upgrade::Origins-Pattern aus und vergleichen Sie die Ausgabe anschließend 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. Deshalb wählt systemd einen zufälligen Zeitpunkt innerhalb dieses Zeitfensters, statt das Upgrade zu einer festen Kalenderzeit zu starten. Dadurch wird die Last auf alle Debian-Systeme verteilt, 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 Sie eine leere OnCalendar=-Zeile, gefolgt von Ihrem eigenen Wert.

Sollte ich den automatischen Neustart für Sicherheitsupdates aktivieren?

Nur wenn ein ungeplanter Neustart sicher ist. Unattended-Upgrade::Automatic-Reboot "true" startet das System ohne Rückfrage neu, sobald nach einem Lauf /var/run/reboot-required vorhanden ist. Diese Markierung wird von einem anderen Paket, normalerweise needrestart, angelegt und nicht von unattended-upgrades selbst. Prüfen Sie nach einem Kernel-Upgrade, ob die Datei auf Ihrem System erscheint, bevor Sie dieser Einstellung vertrauen. Auf einem System, das beim Booten eine Passphrase benötigt oder auf dem Dienste manuell gestartet wurden, lassen Sie die Einstellung auf false und überwachen Sie die Markierungsdatei. So kann eine Person den Zeitpunkt des Neustarts festlegen.