dnf-automatic: Sicherheitsupdates auf Rocky und AlmaLinux

Was dnf-automatic unter Rocky Linux und AlmaLinux macht

dnf-automatic ermöglicht unbeaufsichtigte Sicherheitsupdates unter Rocky Linux und AlmaLinux. Es ist ein kleines Programm, das von einem systemd-Timer gestartet wird. Es liest /etc/dnf/automatic.conf und wendet die dort festgelegten Einstellungen an. Die Installation erfolgt mit einem einzigen Befehl. Im restlichen Abschnitt geht es um die Einstellungen, die entscheiden, ob das System geschützt wird oder das Programm unbemerkt nichts tut.

Wenn Sie von Debian oder Ubuntu kommen, erfüllt es dieselbe Aufgabe, die unattended-upgrades auf einem Ubuntu-VPS übernimmt. Ein Unterschied ist wichtiger als alle anderen: die Bedeutung des Begriffs "Sicherheit" für den Paketmanager. Unter Ubuntu handelt es sich um ein separates Archiv-Repository. In der RHEL-Familie sind Sicherheitsinformationen an veröffentlichte Advisories angehängt. Diese Metadaten können fehlen oder veraltet sein. Wenn Sie dnf-automatic auf ein Repository ohne Advisory-Daten verweisen, installiert es nichts und meldet trotzdem Erfolg.

Dieser Leitfaden bezieht sich auf Rocky Linux 9 und AlmaLinux 9, die DNF 4 verwenden (DNF ist der Paketmanager der RHEL-Familie), Stand August 2026. Die Versionen 10 verwenden DNF5, und dort ändern sich die Bezeichnungen. Deshalb gibt es dafür weiter unten einen eigenen Abschnitt. Jeder folgende Befehl wird auf Ihrem eigenen System ausgeführt. Die erwartete Ausgabe steht jeweils daneben.

Installieren Sie dnf-automatic und lesen Sie die mitgelieferte Konfiguration

Das Aktivieren automatischer Updates gehört zusammen mit den übrigen Einrichtungsschritten in die ersten zehn Minuten auf einem neuen VPS, direkt nachdem Sie einen Nicht-Root-Benutzer und eine Firewall eingerichtet haben.

sudo dnf install -y dnf-automatic
rpm -q dnf dnf-automatic
systemctl is-enabled dnf-automatic.timer

systemctl is-enabled gibt bei einer frischen Installation disabled aus, weil die Paketinstallation nichts startet. Das ist der häufigste Grund dafür, dass ein Server mit „dnf-automatic“ noch kein einziges Update angewendet hat.

Die DNF-Version ist für eine Option relevant. Die Einstellung reboot wurde mit DNF 4.15 upstream eingeführt. Red Hat hat sie im November 2023 über das Advisory RHBA-2023:6645 in dnf-4.14.0-6.el9 zurückportiert. Rocky 9 und AlmaLinux 9 bauen dieses Paket neu. Auf einem aktuellen System ist die Einstellung daher vorhanden, auf einem seit 2023 nicht mehr aktualisierten System nicht.

Die Konfigurationsdatei befindet sich unter /etc/dnf/automatic.conf. Die mitgelieferte Datei enthält jede von diesem Build unterstützte Option mit ihrem auskommentierten Standardwert. Lesen Sie sie einmal, bevor Sie sie bearbeiten. Diese Datei zeigt zuverlässig, welche Optionen Ihre Version unterstützt.

Die beiden Schalter, die das Verhalten bestimmen

download_updates und apply_updates im Abschnitt [commands] bestimmen das Verhalten. Unter EL9 (Enterprise Linux 9, die gemeinsame Basis von Rocky 9 und AlmaLinux 9) sind beide standardmäßig no. Ein unverändertes, aktiviertes dnf-automatic meldet daher nur, welche Updates verfügbar sind.

• Beide no: dnf-automatic meldet verfügbare Updates und ändert nichts am System.
• download_updates = yes mit apply_updates = no: Die Pakete werden in den DNF-Cache geladen. Die Installation geht danach schnell und benötigt kein Netzwerk. In dieser Nacht wurde jedoch noch nichts geändert.
• Beide yes mit upgrade_type = default: Jedes verfügbare Update wird installiert, unabhängig davon, ob es sich um ein Security-Update handelt.
• Beide yes mit upgrade_type = security: Es werden nur Pakete installiert, die in einem Security Advisory genannt sind.

Ein sinnvoller Ausgangspunkt für einen öffentlich erreichbaren VPS:

[commands]
upgrade_type = security
download_updates = yes
apply_updates = yes
random_sleep = 0
network_online_timeout = 60
reboot = never

network_online_timeout gibt an, wie viele Sekunden der Lauf auf ein funktionierendes Netzwerk wartet, bevor er abbricht. Das ist bei einem System wichtig, das gerade gestartet wurde. random_sleep ist eine ältere Möglichkeit, die Last auf mehrere Systeme zu verteilen. Diese Aufgabe übernimmt jetzt der Timer. Führen Sie systemctl cat dnf-automatic.service aus, um die genauen Optionen anzuzeigen, die der mitgelieferte Dienst verwendet.

Prüfen Sie, ob die Datei wie erwartet funktioniert, ohne bis 06:00 zu warten:

sudo systemctl start dnf-automatic.service
sudo journalctl -u dnf-automatic.service -n 50 --no-pager

Das Journal zeigt, was der Lauf geprüft und welche Aktionen er ausgeführt hat. Sie können außerdem ein Verhalten über die Befehlszeile erzwingen. Das überschreibt die Datei nur für diesen Lauf:

sudo dnf-automatic --downloadupdates --no-installupdates

Was upgrade_type = security unter Rocky und Alma tatsächlich bedeutet

DNF erkennt nicht anhand der Versionsnummern, ob ein Update ein Sicherheitsupdate ist. Es liest Errata-Metadaten: eine Datei namens updateinfo.xml, die innerhalb des Repositorys veröffentlicht wird und in der jedes Advisory die Pakete aufführt, mit denen es behoben wird. AlmaLinux veröffentlicht diese als ALSA-Advisories, Rocky als RLSA. upgrade_type = security erstellt aus diesen Metadaten einen Filter und aktualisiert nur die Pakete, auf die dieser Filter zutrifft.

Daraus folgen zwei Konsequenzen, die viele überraschen.

Erstens: Ohne Metadaten gibt es keine Updates. Wenn das Repository kein updateinfo.xml enthält, trifft der Filter auf nichts zu, und der Lauf endet mit dieser Zeile im Journal:

No security updates needed, but 3 updates available

Das System ist nicht gepatcht, und es wurde kein Fehler gemeldet. Prüfen Sie das selbst:

dnf updateinfo list --security
dnf check-update

Wenn dnf check-update Pakete auflistet, während dnf updateinfo list --security überhaupt nichts ausgibt, trägt entweder kein ausstehendes Update ein Advisory, oder das Repository enthält keine Advisory-Daten, die gelesen werden können. Rocky und AlmaLinux veröffentlichen diese Daten beide, daher ist eine leere Liste bei diesen beiden Distributionen normalerweise korrekt. CentOS Stream veröffentlicht sie überhaupt nicht.

Zweitens ist der Sicherheitsmodus kein minimales Update. dnf-automatic fügt den Sicherheitsfilter hinzu und führt anschließend den normalen Upgrade-Pfad aus. Daher wird ein in einem Advisory genanntes Paket auf die neueste Version im Repository aktualisiert und zieht dabei seine Abhängigkeiten mit. Der kleinere Schritt, also nur auf die früheste Version zu aktualisieren, die das Advisory behebt, ist dnf upgrade-minimal --security, das Sie manuell ausführen müssen. dnf-automatic bietet dafür keine Einstellung.

Für Rocky gilt außerdem ein weiterer Vorbehalt. Rocky erzeugt seine Errata über eine eigene Pipeline aus Red-Hat-Daten, und diese Pipeline ist in Rückstand geraten. Im September 2025 berichteten Benutzer, dass sich das Rocky-9-BaseOS-updateinfo.xml seit Dezember 2024 nicht verändert hatte. Dadurch fehlten --security aktuelle Advisories, und Mitarbeiter von Rocky bestätigten dies als bekanntes Problem. Wenn Sie auf upgrade_type = security angewiesen sind, vergleichen Sie die Advisory-Liste gelegentlich mit den aktuellen RLSA-Ankündigungen. Auf einem System, bei dem die Abdeckung wichtiger ist als eine strikte Änderungskontrolle, ist upgrade_type = default nach einem Zeitplan Ihrer Wahl die sicherere Einstellung.

Der systemd-Timer, der den Vorgang tatsächlich ausführt

sudo systemctl enable --now dnf-automatic.timer
systemctl list-timers dnf-automatic.timer

list-timers sollte eine Zeile mit einer NEXT Zeit ausgeben, die ungefähr einen Tag in der Zukunft liegt. Eine leere Tabelle bedeutet, dass der Timer nicht aktiviert ist. Der Vorgang wird dann nie ausgeführt.

Der mitgelieferte Timer wird um *-*-* 6:00 mit RandomizedDelaySec=60m und Persistent=true ausgeführt. Die zufällige Verzögerung verteilt die Serverflotte über eine Stunde. Dadurch greift nicht jeder Server in derselben Sekunde auf den Mirror zu. Persistent=true bedeutet, dass ein Rechner, der um 06:00 ausgeschaltet war, den verpassten Vorgang kurz nach dem Booten ausführt, anstatt ihn für diesen Tag zu überspringen.

Ändern Sie den Zeitplan mit einem Drop-in. Bearbeiten Sie nicht die mitgelieferte Unit, da ein Paket-Upgrade Dateien unter /usr/lib/systemd/system ersetzt.

sudo systemctl edit dnf-automatic.timer

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

Die leere Zeile OnCalendar= ist erforderlich. OnCalendar sammelt Werte an. Ohne diese Zurücksetzung behalten Sie daher den Eintrag für 06:00 und fügen einen zweiten hinzu. Der Vorgang wird dann zweimal täglich ausgeführt. Bestätigen Sie das Ergebnis mit systemctl list-timers dnf-automatic.timer und lesen Sie die Spalte NEXT. Dieselben Drop-in-Regeln gelten für alle anderen Zeitpläne. Das wird unter systemd-Service- und Timer-Units erstellen behandelt.

Nun zur Fehlerquelle. Das Paket liefert drei weitere Timer mit: dnf-automatic-notifyonly.timer, dnf-automatic-download.timer und dnf-automatic-install.timer. Jeder startet dasselbe Programm mit Kommandozeilen-Flags. Diese Flags überschreiben download_updates und apply_updates aus Ihrer Konfigurationsdatei. Aktivieren Sie einen dieser Timer zusätzlich zu dnf-automatic.timer, und der Vorgang wird zweimal mit zwei unterschiedlichen Verhaltensweisen ausgeführt. Das sieht genau so aus, als würde Ihre Konfigurationsdatei ignoriert. Aktivieren Sie einen Timer und prüfen Sie:

systemctl list-unit-files 'dnf-automatic*'

Woran erkenne ich, wann etwas installiert wurde?

emit_via im Abschnitt [emitters] steuert die Berichterstattung. Unter systemd schreibt der stdio-Emitter in das Journal. Das ist die zuverlässige Option, weil dafür nichts weiter installiert sein muss:

sudo journalctl -u dnf-automatic.service --since -7d --no-pager

Der motd-Emitter schreibt den Bericht nach /etc/motd und ersetzt den bisherigen Inhalt dieser Datei. Wenn Sie dort ein Login-Banner anzeigen, lassen Sie diesen Emitter weg.

Der email-Emitter baut eine SMTP-Verbindung (Simple Mail Transfer Protocol) zu email_host über email_port auf. Standardwerte sind localhost und 25. Auf einem frischen VPS lauscht dort kein Dienst. Daher wird die Verbindung abgelehnt und keine E-Mail gesendet. Führen Sie ss -lnt | grep ':25' aus, bevor Sie sich darauf verlassen. Richten Sie außerdem einen Relay-only-Postfix ein, wenn die Ausgabe leer bleibt. Wenn der E-Mail-Versand funktioniert, lautet der Betreff Updates applied on 'web01'.. Der Name wird aus system_name übernommen.

Für alle anderen Fälle übergibt der command-Emitter den Bericht über die Standardeingabe an ein Programm Ihrer Wahl:

[emitters]
emit_via = stdio, command
system_name = web01.example.com
send_error_messages = yes

[command]
command_format = /usr/local/bin/notify-ops
stdin_format = {body}

send_error_messages ist standardmäßig auf no gesetzt. Dadurch meldet ein fehlgeschlagener Lauf überhaupt nichts. Aktivieren Sie diese Option. Ein Patch-System, das nur erfolgreiche Läufe meldet, ist schlechter als gar keines, weil das Ausbleiben einer Meldung den Eindruck erweckt, alles sei in Ordnung.

dnf-automatic startet Ihre Dienste nicht neu

Die Installation eines Pakets ersetzt Dateien auf der Festplatte. Ein bereits laufender Prozess behält den alten Code im Speicher. Eine korrigierte Bibliothek hat daher keine Wirkung auf einen Daemon, der im letzten Monat gestartet wurde. Diese Lücke zwischen installiertem und wirksamem Code ist der Grund, warum unbeaufsichtigte Aktualisierungen eine Neustartstrategie und nicht nur eine Installationsstrategie benötigen.

sudo dnf install -y dnf-plugins-core
dnf needs-restarting -s
dnf needs-restarting -r

-s listet die systemd-Dienste auf, deren Dateien geändert wurden, nachdem sie gestartet wurden. -r beantwortet eine Frage und gibt einen von zwei Blöcken aus:

Core libraries or services have been updated since boot-up:
  * kernel
Reboot is required to fully utilize these updates.

No core libraries or services have been updated since boot-up.
Reboot should not be necessary.

-r ist keine umfassende Analyse. Der Befehl prüft eine feste Paketliste: kernel, kernel-core, kernel-rt, glibc, linux-firmware, systemd, dbus, dbus-broker, dbus-daemon und microcode_ctl. Wenn eines dieser Pakete nach dem letzten Boot installiert wurde, erhalten Sie die erste Antwort. Ergänzen Sie eigene Paketnamen in einer Datei mit der Endung .conf unter /etc/dnf/plugins/needs-restarting.d/, wenn auch etwas anderes auf dem System einen Neustart benötigt, damit die Änderung wirksam wird.

Ein Hinweis für Skripte: dnf needs-restarting -r beendet sich sowohl dann mit einem Status ungleich 0, wenn ein Neustart erforderlich ist, als auch dann, wenn der Befehl selbst fehlgeschlagen ist. Anhand des Exit-Status allein lassen sich diese Fälle daher nicht unterscheiden. Lesen Sie den ausgegebenen Text.

Einen Dienst neu zu starten, ist der kleinere Eingriff und normalerweise die richtige Maßnahme. Starten Sie den SSH-Daemon aus einer zweiten, bereits geöffneten SSH-Sitzung neu, damit Sie eine fehlerhafte Konfiguration nicht aussperrt. Bei einem neuen Kernel hilft nur ein Reboot, weil der laufende Kernel nicht im laufenden Betrieb ersetzt werden kann.

Soll der Server automatisch neu starten?

[commands]
reboot = when-needed
reboot_command = shutdown -r +5 'Rebooting after applying package updates'

reboot = never ist die Standardeinstellung. when-changed führt nach jedem angewendeten Update einen Neustart durch. when-needed startet nur neu, wenn die Prüfung hinter needs-restarting -r feststellt, dass ein Kernpaket ersetzt wurde. Das entspricht dem, was die meisten Betreiber eines einzelnen Servers benötigen, zusammen mit einem Zeitfenster, das sie selbst festlegen. Die Standardeinstellung reboot_command warnt angemeldete Benutzer über shutdown fünf Minuten vorher. Dieses Zeitfenster können Sie vergrößern.

Klären Sie zwei Punkte, bevor Sie die Funktion aktivieren. Jeder benötigte Dienst muss beim Systemstart selbstständig starten. Genau das ist bei einem manuell gestarteten Docker-Compose-Stack häufig nicht der Fall. Außerdem benötigen Sie über Ihren Provider Zugriff auf eine Konsole oder eine Rettungsumgebung, weil sich ein Kernel, der nicht startet, nicht über SSH reparieren lässt. Fehlt eine dieser Voraussetzungen, behalten Sie reboot = never bei und starten Sie den Server erst nach Prüfung des Journals manuell neu.

Rocky, AlmaLinux und CentOS Stream: die Unterschiede

Auf Rocky 9 und AlmaLinux 9 ist alles oben Genannte identisch, einschließlich des Konfigurationspfads und der Unit-Namen. Beide veröffentlichen Errata, daher enthält upgrade_type = security Daten, nach denen gefiltert werden kann.

CentOS Stream ist die Ausnahme, und zwar eine wesentliche. Die Stream-Repositorys enthalten keine updateinfo.xml. Daher kann der Security-Filter nie greifen, und jeder Lauf meldet No security updates needed. Verwenden Sie auf Stream upgrade_type = default und akzeptieren Sie, dass damit jedes Update installiert wird. Stream liegt außerdem vor RHEL. Daher bewirkt diese Einstellung auf einem Stream-System mehr Änderungen als dieselbe Einstellung auf Rocky oder AlmaLinux.

Rocky 10 und AlmaLinux 10 verwenden DNF5, das einige Bezeichnungen ändert. Die DNF5-Dokumentation des Upstream-Projekts nennt den Timer dnf5-automatic.timer, legt die mitgelieferten Standardwerte in /usr/share/dnf5/dnf5-plugins/automatic.conf ab, während Ihre Anpassungen weiterhin in /etc/dnf/automatic.conf stehen, setzt download_updates standardmäßig auf yes statt auf no und ergänzt distro-sync als upgrade_type. Die Abfrage der Advisories lautet dnf advisory list; updateinfo bleibt als Alias erhalten. Prüfen Sie, was Ihr Release tatsächlich installiert hat, bevor Sie Paket- oder Unit-Namen aus einer Anleitung für 9 übernehmen:

dnf list --available '*automatic*'
systemctl list-unit-files '*automatic*'

Viele veröffentlichte Anleitungen zu diesem Thema behandeln weiterhin nur Rocky 8. Seit ihrer Veröffentlichung wurde der Umfang der Optionen erweitert. Prüfen Sie daher die auskommentierte Datei auf Ihrem eigenen System, statt einem älteren Artikel zu vertrauen.

Fehlerbilder und die angezeigten Zeichenfolgen

Nichts wird ausgeführt. systemctl list-timers dnf-automatic.timer gibt eine leere Tabelle aus, und systemctl is-enabled dnf-automatic.timer gibt disabled aus. Das Paket wurde installiert, der Timer jedoch nicht.

Der Job wird ausgeführt, installiert aber nichts. Das Journal enthält No security updates needed, but 3 updates available. Der Sicherheitsfilter hat nichts gefunden. Entweder betrifft kein ausstehendes Update ein Advisory, oder das Repository stellt keine Advisory-Daten bereit.

Eine Einstellung scheint ignoriert zu werden. DNF protokolliert bei aktiviertem Debug-Level eine unbekannte Option in automatic.conf und verwendet anschließend den Standardwert. Ein falsch geschriebener Schlüssel hat daher keine Wirkung und erzeugt keine Warnung. Schreiben Sie apply_update = yes, und apply_updates bleibt auf no. Dadurch lädt das System dauerhaft herunter, installiert aber niemals etwas. Führen Sie nach jeder Änderung sudo systemctl start dnf-automatic.service aus, und prüfen Sie das Journal, statt der Datei zu vertrauen.

Der Job wird zweimal täglich ausgeführt. Zwei Timer sind aktiviert. systemctl list-unit-files 'dnf-automatic*' zeigt, welche das sind. Die zusätzlichen Timer übergeben Flags, die Ihre Konfigurationsdatei außer Kraft setzen.

Es kommt keine E-Mail an. Entweder lauscht für den email-Emitter nichts auf Port 25, oder send_error_messages steht weiterhin auf no. Dann wird nur ein Fehler gemeldet.

Ein gepatchter Dienst meldet weiterhin die alte Version. Die Datei auf der Festplatte ist neu, der Prozess im Speicher jedoch alt. dnf needs-restarting -s nennt die Dienste, die neu gestartet werden müssen.

FAQ

Installiert dnf-automatic unter Rocky Linux nur Sicherheitsupdates?

Nur wenn Sie upgrade_type = security in /etc/dnf/automatic.conf setzen und Ihre Repositorys Errata-Metadaten veröffentlichen. Rocky Linux und AlmaLinux veröffentlichen diese Metadaten, sodass der Filter passende Advisories finden kann. Der mitgelieferte Standardwert ist upgrade_type = default. Damit wird jedes verfügbare Update installiert, sobald apply_updates = yes.

Warum meldet dnf-automatic „No security updates needed, but 3 updates available“?

DNF ermittelt anhand von updateinfo.xml aus dem Repository, was als Sicherheitsupdate gilt. Jedes Advisory führt dort die Pakete auf, die den Fehler beheben. Fehlen diese Metadaten oder sind sie veraltet, findet der Sicherheitsfilter keine Treffer, während normale Updates weiterhin ausstehen. Dadurch entsteht genau diese Meldung. Dieses Verhalten ist bei CentOS Stream zu erwarten, weil dort überhaupt keine Errata veröffentlicht werden. Vergleichen Sie bei Rocky oder AlmaLinux dnf updateinfo list --security mit dnf check-update und prüfen Sie, ob Ihre Metadaten aktuell sind.

Startet dnf-automatic meinen Server nach einem Kernel-Update neu?

Nicht ohne Ihre entsprechende Konfiguration. Die Option reboot hat standardmäßig den Wert never. Setzen Sie reboot = when-needed. Dann führt ein Lauf nur dann einen Neustart aus, wenn die Prüfung hinter dnf needs-restarting -r feststellt, dass ein zentrales Paket wie kernel oder glibc seit dem Booten ersetzt wurde. reboot = when-changed führt nach jedem angewendeten Update einen Neustart aus. Beide Optionen verwenden reboot_command. Der Standardwert ist shutdown -r +5, wobei eine Warnmeldung an angemeldete Benutzer ausgegeben wird.

Wie ändere ich die Ausführungszeit von dnf-automatic?

Führen Sie sudo systemctl edit dnf-automatic.timer aus und fügen Sie einen Abschnitt [Timer] mit einer leeren Zeile OnCalendar= ein, gefolgt von Ihrem Zeitplan, zum Beispiel OnCalendar=*-*-* 03:30. Die leere Zeile ist erforderlich, weil OnCalendar die Werte sammelt. Wenn sie fehlt, bleibt der mitgelieferte Lauf um 06:00 Uhr erhalten und ein zweiter Lauf kommt hinzu. Prüfen Sie die Konfiguration mit systemctl list-timers dnf-automatic.timer und lesen Sie die Spalte NEXT.

Muss ich einen Server weiterhin prüfen, wenn er sich selbst aktualisiert?

Ja. dnf-automatic installiert Pakete und beendet seine Arbeit danach. Es startet keine Daemons neu. Außerdem erhalten Sie keine sichtbare Meldung, wenn emit_via keinen Emitter angibt, den Sie tatsächlich auswerten. Setzen Sie mindestens emit_via auf stdio, aktivieren Sie send_error_messages, damit auch Fehler gemeldet werden, und führen Sie dnf needs-restarting -s nach einem Patch-Fenster aus. So finden Sie Dienste, die weiterhin alten Code ausführen.