Automatische beveiligingsupdates met dnf-automatic

Wat dnf-automatic doet op Rocky Linux en AlmaLinux

dnf-automatic is de manier waarop u onbeheerde beveiligingsupdates uitvoert op Rocky Linux en AlmaLinux. Het is een klein programma, gestart door een systemd-timer, dat /etc/dnf/automatic.conf leest en toepast wat dat bestand toestaat. De installatie vereist één commando. De rest van deze handleiding gaat over de instellingen die bepalen of het de server beschermt of stilletjes niets doet.

Als u afkomstig bent van Debian of Ubuntu, is dit dezelfde taak als wat unattended-upgrades doet op een Ubuntu VPS. Eén verschil is belangrijker dan alle andere: wat het woord "beveiliging" betekent voor de pakketbeheerder. Op Ubuntu is dit een apart archiefgedeelte. Bij de RHEL-familie is het metadata die is gekoppeld aan gepubliceerde adviezen, en die metadata kan ontbreken of verouderd zijn. Wijs dnf-automatic naar een repository zonder adviesgegevens en het installeert niets, terwijl het rapporteert dat de actie is geslaagd.

Deze handleiding is geschreven voor Rocky Linux 9 en AlmaLinux 9, die gebruikmaken van DNF 4 (DNF is de pakketbeheerder van de RHEL-familie), per augustus 2026. De 10-releases zijn overgestapt op DNF5 en de namen veranderen daar, dus die krijgen tegen het einde een eigen sectie. Elk commando hieronder is bedoeld om uit te voeren op uw eigen server, met de output die u daarna kunt verwachten.

Installeer dnf-automatic en lees de meegeleverde configuratie

Het inschakelen van automatische updates hoort bij de rest van de installatie in de eerste tien minuten op een nieuwe VPS, direct nadat u een non-root gebruiker en een firewall heeft ingesteld. Als de firewall nog niet is geconfigureerd, firewalld is wat Rocky en AlmaLinux standaard meeleveren, en met een paar commando's opent u SSH, opent u de poort waarop uw site luistert en zorgt u dat beide instellingen behouden blijven na een herstart.

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

systemctl is-enabled geeft disabled weer op een verse installatie, omdat het installeren van het pakket niets opstart. Dat is de meest voorkomende reden dat een server die "dnf-automatic heeft" nog nooit een update heeft toegepast.

De DNF-versie is van belang voor één optie. De instelling reboot werd upstream geïntroduceerd in DNF 4.15, en Red Hat heeft deze in november 2023 via advisory RHBA-2023:6645 teruggepoort naar dnf-4.14.0-6.el9. Rocky 9 en AlmaLinux 9 herbouwen dat pakket, dus een actueel systeem beschikt hierover, terwijl een systeem dat sinds 2023 niet is bijgewerkt dit niet heeft.

Het configuratiebestand is /etc/dnf/automatic.conf. De meegeleverde kopie bevat elke optie die deze build begrijpt, inclusief de standaardwaarde, als commentaar. Lees dit bestand eenmaal door voordat u het bewerkt, omdat dit bestand de feitelijke configuratie voor uw versie bevat.

De twee schakelaars die bepalen wat er gebeurt

download_updates en apply_updates in de sectie [commands] bepalen het gedrag. Beide staan standaard op no op EL9 (Enterprise Linux 9, de gedeelde basis van Rocky 9 en AlmaLinux 9). Een ongewijzigde dnf-automatic die u inschakelt, zal daarom alleen rapporteren wat er beschikbaar is.

• Beide no: dnf-automatic rapporteert beschikbare updates en wijzigt niets aan het systeem.
• download_updates = yes met apply_updates = no: pakketten worden opgehaald in de DNF-cache. De installatie is daarna snel en vereist geen netwerk, maar er is vannacht niets gewijzigd.
• Beide yes met upgrade_type = default: elke beschikbare update wordt geïnstalleerd, ongeacht of het een beveiligingsupdate is of niet.
• Beide yes met upgrade_type = security: alleen pakketten die in een beveiligingsadvies worden genoemd, worden geïnstalleerd.

Een redelijk uitgangspunt voor een publieke VPS:

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

network_online_timeout is het aantal seconden dat de uitvoering wacht op een werkend netwerk voordat het proces wordt afgebroken; dit is van belang op een systeem dat zojuist is opgestart. random_sleep is een oudere methode om de belasting over veel machines te spreiden; de timer voert die taak nu uit. Voer systemctl cat dnf-automatic.service uit om de exacte vlaggen te zien die de meegeleverde service doorgeeft.

Controleer of het bestand doet wat u verwacht, zonder te wachten tot 06:00:

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

De journal toont wat de uitvoering heeft overwogen en wat er is gedaan. U kunt ook één gedrag afdwingen vanaf de opdrachtregel, wat het bestand voor die specifieke uitvoering overrulet:

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

Wat upgrade_type = security werkelijk betekent op Rocky en Alma

DNF bepaalt niet of een update een beveiligingsupdate is door versienummers te vergelijken. Het leest errata-metadata: een bestand genaamd updateinfo.xml dat in de repository wordt gepubliceerd, waarin elk advies de pakketten vermeldt die het probleem verhelpen. AlmaLinux publiceert deze als ALSA-adviezen, Rocky publiceert ze als RLSA. upgrade_type = security bouwt een filter op basis van die metadata en voert alleen upgrades uit voor de pakketten die daarmee overeenkomen.

Dit heeft twee gevolgen, die beide vaak als verrassing komen.

Ten eerste betekent het ontbreken van metadata dat er geen updates plaatsvinden. Als de repository geen updateinfo.xml bevat, komt het filter nergens mee overeen en eindigt de uitvoering met deze regel in het logboek:

No security updates needed, but 3 updates available

De server is niet gepatcht en er is geen foutmelding gerapporteerd. Controleer dit zelf:

dnf updateinfo list --security
dnf check-update

Als dnf check-update pakketten weergeeft terwijl dnf updateinfo list --security helemaal niets toont, bevat ofwel geen enkele beschikbare update een advies, of de repository heeft geen adviesgegevens om te lezen. Zowel Rocky als AlmaLinux publiceren deze gegevens, dus op die twee systemen is een lege lijst meestal correct. CentOS Stream publiceert deze gegevens helemaal niet.

Ten tweede is de beveiligingsmodus geen minimale wijziging. dnf-automatic voegt het beveiligingsfilter toe en voert daarna het normale upgradepad uit. Een pakket dat in een advies wordt genoemd, wordt dus bijgewerkt naar de nieuwste versie in de repository en trekt daarbij de afhankelijkheden mee. De kleinere stap, waarbij alleen wordt bijgewerkt naar de vroegste versie die het advies verhelpt, is dnf upgrade-minimal --security die handmatig wordt uitgevoerd. dnf-automatic heeft hier geen instelling voor.

Er is nog een kanttekening voor Rocky. Rocky genereert zijn errata op basis van Red Hat-gegevens via een eigen pipeline, en die pipeline loopt soms achter. In september 2025 rapporteerden gebruikers dat de Rocky 9 BaseOS updateinfo.xml sinds december 2024 niet was bijgewerkt, waardoor --security recente adviezen miste. Het team van Rocky bevestigde dit als een bekend probleem. Als u afhankelijk bent van upgrade_type = security, vergelijk dan de lijst met adviezen af en toe met de recente RLSA-aankondigingen. Op een systeem waar dekking belangrijker is dan wijzigingsbeheer, is upgrade_type = default volgens een schema naar keuze de veiligere instelling.

De systemd-timer die de taak daadwerkelijk uitvoert

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

list-timers hoort één rij weer te geven met een NEXT-tijd die ongeveer een dag in de toekomst ligt. Een lege tabel betekent dat de timer niet is ingeschakeld, waardoor de taak nooit zal worden uitgevoerd.

De meegeleverde timer wordt geactiveerd om *-*-* 6:00 met RandomizedDelaySec=60m en Persistent=true. De willekeurige vertraging spreidt de belasting over een uur, zodat niet elke server op exact hetzelfde moment de mirror benadert. Persistent=true zorgt ervoor dat een machine die om 06:00 uitgeschakeld was, de gemiste taak kort na het opstarten alsnog uitvoert in plaats van de dag over te slaan.

Wijzig het schema met een drop-in bestand. Bewerk nooit de meegeleverde unit, omdat een package-upgrade de bestanden onder /usr/lib/systemd/system overschrijft.

sudo systemctl edit dnf-automatic.timer

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

De lege OnCalendar=-regel is vereist. OnCalendar wordt opgebouwd, dus zonder deze reset behoudt u de 06:00-vermelding en voegt u een tweede toe, waardoor de taak twee keer per dag wordt uitgevoerd. Controleer het resultaat met systemctl list-timers dnf-automatic.timer en lees de NEXT-kolom. Dezelfde drop-in regels gelden voor alles wat u plant, wat wordt behandeld in het schrijven van systemd service- en timer-units.

Nu de valkuil. Het pakket levert nog drie andere timers: dnf-automatic-notifyonly.timer, dnf-automatic-download.timer en dnf-automatic-install.timer. Elk start hetzelfde programma met command-line flags, en deze flags overschrijven download_updates en apply_updates uit uw configuratiebestand. Schakel er een in naast dnf-automatic.timer en de taak wordt twee keer uitgevoerd met twee verschillende gedragingen, wat er precies zo uitziet alsof uw configuratiebestand wordt genegeerd. Schakel één timer in en controleer:

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

Hoe weet ik wanneer iets is geïnstalleerd?

emit_via in de sectie [emitters] beheert de rapportage. Onder systemd schrijft de stdio-emitter naar de journal; dit is de betrouwbare optie omdat hiervoor geen extra software vereist is:

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

De motd-emitter schrijft het rapport naar /etc/motd en overschrijft de inhoud van dat bestand. Als u daar een login-banner bewaart, laat deze emitter dan achterwege.

De email-emitter opent een SMTP-verbinding (simple mail transfer protocol) naar email_host op email_port, met localhost en 25 als standaardwaarden. Een nieuwe VPS heeft daar geen actieve luisterende service, waardoor de verbinding wordt geweigerd en er geen e-mail wordt verzonden. Voer ss -lnt | grep ':25' uit voordat u hierop vertrouwt en configureer een relay-only Postfix als de uitvoer leeg blijft. Wanneer e-mail wel werkt, luidt het onderwerp Updates applied on 'web01'., waarbij de naam wordt overgenomen uit system_name.

Voor alle overige gevallen geeft de command-emitter het rapport door aan een eigen programma via standard input:

[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 staat standaard op no, wat betekent dat een mislukte uitvoering niets rapporteert. Schakel dit in. Een patchsysteem dat alleen successen meldt is slechter dan geen systeem, omdat stilte ten onrechte als een gezonde status wordt geïnterpreteerd.

dnf-automatic herstart uw services niet

Het installeren van een pakket vervangt bestanden op de schijf. Een proces dat al draait, houdt de oude code in het geheugen vast; een gepatchte bibliotheek heeft dus geen effect op een daemon die vorige maand is gestart. Dat gat tussen installatie en activering is de reden waarom onbeheerd patchen niet alleen een installatiebeleid vereist, maar ook een herstartbeleid.

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

-s somt de systemd-services op waarvan de bestanden zijn gewijzigd nadat ze waren gestart. -r beantwoordt één vraag en toont een van de twee volgende blokken:

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 is geen diepgaande analyse. Het controleert een vaste lijst met pakketten: kernel, kernel-core, kernel-rt, glibc, linux-firmware, systemd, dbus, dbus-broker, dbus-daemon en microcode_ctl. Als een van deze na de laatste boot is geïnstalleerd, krijgt u het eerste antwoord. Voeg uw eigen pakketnamen toe in een bestand dat eindigt op .conf in /etc/dnf/plugins/needs-restarting.d/ wanneer iets anders op de server ook een herstart vereist om effect te sorteren.

Een waarschuwing voor scripts: dnf needs-restarting -r geeft een exitcode die niet nul is, zowel wanneer een herstart vereist is als wanneer het commando zelf is mislukt; de exit-status alleen is dus onvoldoende om dit onderscheid te maken. Lees de uitvoertekst.

Het herstarten van een service is de kleinere ingreep en meestal de juiste keuze. Herstart de SSH-daemon vanuit een tweede SSH-sessie die al openstaat, zodat een foutieve configuratie u niet buitensluit. Een nieuwe kernel is het geval waarbij alleen een herstart helpt, omdat de draaiende kernel niet ter plekke kan worden vervangen. Als u de updates van een bepaalde ochtend wilt verdelen over deze twee categorieën, helpt welke updates een herstart vereisen en welke slechts een service-herstart u om de uitvoer pakket voor pakket door te nemen.

Containers zijn een apart geval, omdat dnf-automatic de pakketten van de host patcht en nooit de userland aanraakt die in een image is ingebakken. Een server die Docker Engine op Rocky Linux of AlmaLinux draait, moet daarom ook zijn images opnieuw ophalen en zijn containers opnieuw aanmaken voordat een fix de code bereikt die daadwerkelijk verkeer afhandelt.

Moet de server automatisch herstarten?

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

reboot = never is de standaardinstelling. when-changed herstart na elke toegepaste update. when-needed herstart alleen wanneer de controle achter needs-restarting -r aangeeft dat een kernpakket is vervangen; dit is wat de meeste beheerders van een enkele server wensen, in combinatie met een zelfgekozen tijdsvenster. De standaardwaarde reboot_command geeft ingelogde gebruikers vijf minuten waarschuwing via shutdown, en u kunt dit tijdsbestek vergroten.

Regel twee zaken voordat u dit inschakelt. Elke service waarvan u afhankelijk bent, moet zelfstandig opstarten bij een reboot; dit is het gebruikelijke knelpunt bij een Docker Compose-stack die handmatig is gestart. Daarnaast heeft u console- of rescue-toegang van uw provider nodig, omdat een kernel die niet opstart niet via SSH kan worden hersteld. Als een van beide ontbreekt, behoud dan reboot = never en voer de herstart zelf uit nadat u de logs heeft gecontroleerd.

Rocky, AlmaLinux en CentOS Stream: de onderlinge verschillen

Op Rocky 9 en AlmaLinux 9 is alles hierboven identiek, tot aan het configuratiepad en de unit-namen aan toe. Beide publiceren errata, waardoor upgrade_type = security gegevens heeft om op te filteren. De verouderde Rocky-errata die eerder werd beschreven, is een van de weinige punten waarop hun dagelijkse werking daadwerkelijk verschilt. Als de server nog niet is gebouwd, weeg dit dan af tegen de compatibiliteitsbelofte en ondersteuning voor oudere CPU's die de twee onderscheiden.

CentOS Stream is de uitzondering, en wel een ingrijpende. Stream-repositories bevatten geen updateinfo.xml, waardoor het beveiligingsfilter nooit een match kan vinden en elke uitvoering No security updates needed rapporteert. Gebruik op Stream upgrade_type = default en accepteer dat u elke update doorvoert. Stream loopt bovendien voor op RHEL, waardoor die instelling op een Stream-server vaker wijzigt dan dezelfde instelling op Rocky of AlmaLinux. Dat verschil is geen toeval van de verpakking, maar het resultaat van het besluit van Red Hat in 2020 om CentOS te veranderen in een rolling preview van RHEL; dit is hetzelfde besluit dat leidde tot het ontstaan van Rocky Linux en AlmaLinux.

Rocky 10 en AlmaLinux 10 zijn overgestapt op DNF5, wat zaken hernoemt. De upstream DNF5-documentatie geeft de timer aan als dnf5-automatic.timer, plaatst de meegeleverde standaardinstellingen in /usr/share/dnf5/dnf5-plugins/automatic.conf en uw eigen overrides nog steeds in /etc/dnf/automatic.conf, zet download_updates standaard op yes in plaats van no, en voegt distro-sync toe als een upgrade_type. De advisory-query is dnf advisory list, waarbij updateinfo als alias behouden blijft. Controleer wat uw release daadwerkelijk heeft geïnstalleerd voordat u pakket- of unit-namen kopieert uit een handleiding die voor versie 9 is geschreven:

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

Veel gepubliceerde handleidingen over dit onderwerp behandelen nog steeds alleen Rocky 8. De set aan opties is sindsdien uitgebreid, dus controleer het becommentarieerde bestand op uw eigen systeem in plaats van te vertrouwen op een verouderd artikel.

Foutmodi en de meldingen die u zult zien

Niets wordt uitgevoerd. systemctl list-timers dnf-automatic.timer toont een lege tabel en systemctl is-enabled dnf-automatic.timer toont disabled. Het pakket is geïnstalleerd, maar de timer niet.

De taak wordt uitgevoerd en installeert niets. Het logboek bevat No security updates needed, but 3 updates available. Het beveiligingsfilter vond geen overeenkomsten, omdat er geen openstaande adviezen zijn of omdat de repository geen adviesgegevens publiceert.

Een instelling lijkt te worden genegeerd. DNF logt een onbekende optie in automatic.conf op debug-niveau en gebruikt vervolgens de standaardwaarde. Een verkeerd gespelde sleutel verandert dus niets en waarschuwt niemand. Schrijf apply_update = yes en apply_updates blijft op no staan, waardoor de server blijft downloaden en nooit installeert. Voer na elke wijziging sudo systemctl start dnf-automatic.service uit en lees het logboek in plaats van op het bestand te vertrouwen.

De taak wordt twee keer per dag uitgevoerd. Er zijn twee timers ingeschakeld. systemctl list-unit-files 'dnf-automatic*' laat zien welke, en de extra timers geven vlaggen door die uw configuratiebestand overschrijven.

Er komt geen e-mail aan. Of er luistert niets op poort 25 naar de email-emitter, of send_error_messages staat nog op no en het enige dat het melden waard was, was een fout.

Een gepatchte service rapporteert nog steeds de oude versie. Het bestand op de schijf is nieuw, maar het proces in het geheugen is oud. dnf needs-restarting -s noemt de services die opnieuw moeten worden opgestart.

FAQ

Installeert dnf-automatic alleen beveiligingsupdates op Rocky Linux?

Alleen als u upgrade_type = security instelt in /etc/dnf/automatic.conf, en alleen als uw repositories errata-metadata publiceren. Zowel Rocky Linux als AlmaLinux publiceren deze metadata, waardoor het filter beveiligingsadviezen kan matchen. De standaardinstelling is upgrade_type = default, die elke beschikbare update installeert zodra apply_updates = yes wordt uitgevoerd.

Waarom meldt dnf-automatic "No security updates needed, but 3 updates available"?

DNF bepaalt wat een beveiligingsupdate is door updateinfo.xml uit de repository te lezen, waarin elk advies de bijbehorende pakketten vermeldt. Wanneer deze metadata ontbreekt of verouderd is, matcht het beveiligingsfilter niets, terwijl er wel gewone updates klaarstaan. Dit resulteert in die specifieke melding. Dit is normaal gedrag op CentOS Stream, aangezien daar geen errata worden gepubliceerd. Vergelijk op Rocky of AlmaLinux de uitvoer van dnf updateinfo list --security met dnf check-update en controleer of uw metadata actueel is.

Start dnf-automatic mijn server opnieuw op na een kernel-update?

Niet tenzij u dat instelt. De optie reboot staat standaard op never. Stel reboot = when-needed in; de server start dan alleen opnieuw op wanneer de controle achter dnf needs-restarting -r vaststelt dat een kernpakket zoals kernel of glibc is vervangen sinds de laatste boot. reboot = when-changed start de server na elke toegepaste update opnieuw op. Beide gebruiken reboot_command, dat standaard op shutdown -r +5 staat met een waarschuwingsbericht voor ingelogde gebruikers.

Hoe wijzig ik het tijdstip waarop dnf-automatic wordt uitgevoerd?

Voer sudo systemctl edit dnf-automatic.timer uit en voeg een [Timer]-sectie toe met een lege OnCalendar=-regel, gevolgd door uw planning, bijvoorbeeld OnCalendar=*-*-* 03:30. De lege regel is vereist omdat OnCalendar cumulatief is; als u deze weglaat, blijft de standaarduitvoering om 06:00 actief en wordt er een tweede tijdstip toegevoegd. Controleer dit met systemctl list-timers dnf-automatic.timer en bekijk de kolom NEXT.

Moet ik een server die zichzelf patcht nog steeds controleren?

Ja. dnf-automatic installeert alleen pakketten. Het herstart geen daemons en rapporteert niets dat u zult zien, tenzij emit_via een emitter specificeert die u daadwerkelijk uitleest. Stel emit_via minimaal in op stdio, schakel send_error_messages in zodat ook fouten worden gerapporteerd, en voer dnf needs-restarting -s uit na een patchvenster om services te vinden die nog steeds oude code uitvoeren.