dnf-automatic instellen op Rocky Linux en AlmaLinux

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 "security" 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. Als u dnf-automatic richt op een repository zonder adviesgegevens, installeert het niets terwijl het succes rapporteert.

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 daar veranderen de namen, dus die krijgen tegen het einde een eigen sectie. Elk commando hieronder is bedoeld om door u op uw eigen server te worden uitgevoerd, 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 configuratie in de eerste tien minuten op een nieuwe VPS, direct nadat u een non-root gebruiker en een firewall heeft ingesteld.

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 waarom 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 in DNF 4.15 geïntroduceerd en Red Hat heeft deze in november 2023 via advisory RHBA-2023:6645 naar dnf-4.14.0-6.el9 geport. Rocky 9 en AlmaLinux 9 herbouwen dat pakket, dus een actuele server beschikt hierover, terwijl een server die 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, voorzien van commentaar. Lees het bestand één keer door voordat u het bewerkt, aangezien 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 u daarom alleen informeren over 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 verloopt daarna snel en vereist geen netwerk, maar er is die nacht niets gewijzigd.
• Beide yes met upgrade_type = default: elke beschikbare update wordt geïnstalleerd, ongeacht of het een beveiligingsupdate betreft.
• Beide yes met upgrade_type = security: alleen pakketten die in een beveiligingsadvies worden genoemd, worden geïnstalleerd.

Een redelijk uitgangspunt voor een VPS die aan het internet is blootgesteld:

[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 relevant voor een systeem dat zojuist is opgestart. random_sleep is een oudere methode om de belasting over meerdere machines te spreiden; de timer neemt die taak nu op zich. 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

Het logboek toont wat de uitvoering heeft overwogen en wat er is gedaan. U kunt ook één specifiek gedrag afdwingen vanaf de opdrachtregel; dit overschrijft het bestand voor die specifieke uitvoering:

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 is 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 vermeldt terwijl dnf updateinfo list --security niets weergeeft, zijn er ofwel geen openstaande updates met een advies, of de repository bevat geen adviesgegevens om te lezen. Rocky en AlmaLinux publiceren deze gegevens beide, 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 doorloopt vervolgens het normale upgradepad. 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 één 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 de lijst met adviezen dan af en toe met recente RLSA-aankondigingen. Op een systeem waar dekking belangrijker is dan wijzigingsbeheer, is upgrade_type = default volgens een schema dat u zelf kiest de veiligere instelling.

De systemd-timer die het proces 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 pakket-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 gecumuleerd; zonder deze reset behoudt u de invoer van 06:00 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 regels voor drop-ins gelden voor alles wat u plant, wat wordt behandeld in het schrijven van systemd service- en timer-units.

Nu de valkuil. Het pakket bevat 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 gebruikt, 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 output leeg blijft. Wanneer e-mail correct 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 run helemaal niets rapporteert. Schakel dit in. Een patch-systeem dat alleen successen meldt, is slechter dan geen systeem, omdat stilte wordt aangezien voor een gezonde status.

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 actieve status is de reden waarom onbeheerd patchen een herstartbeleid vereist en niet alleen een installatiebeleid.

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 print 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 onder /etc/dnf/plugins/needs-restarting.d/ wanneer iets anders op de server ook een herstart vereist om effect te sorteren.

Eén waarschuwing voor scripts: dnf needs-restarting -r geeft een non-zero exitcode terug, zowel wanneer een herstart vereist is als wanneer het commando zelf is mislukt. De exit-status alleen is dus onvoldoende om het 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 tijdens runtime kan worden vervangen.

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 deze tijd verlengen.

Regel twee zaken voordat u dit inschakelt. Elke service waarvan u afhankelijk bent, moet zelfstandig opstarten bij het booten; dit is het gebruikelijke probleem 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 het logboek heeft gecontroleerd.

Rocky, AlmaLinux en CentOS Stream: de verschillen

Op Rocky 9 en AlmaLinux 9 is alles hierboven identiek, tot aan het configuratiepad en de unit-namen aan toe. Beide publiceren errata, dus upgrade_type = security beschikt over gegevens om op te filteren.

CentOS Stream vormt de uitzondering, en wel een aanzienlijke. Stream-repositories bevatten geen updateinfo.xml, waardoor het beveiligingsfilter nooit een match vindt en elke uitvoering No security updates needed rapporteert. Gebruik op Stream upgrade_type = default en accepteer dat u elke update accepteert. Stream loopt bovendien voor op RHEL, waardoor die instelling op een Stream-systeem vaker wijzigt dan dezelfde instelling op Rocky of AlmaLinux.

Rocky 10 en AlmaLinux 10 zijn overgestapt op DNF5, wat zorgt voor naamswijzigingen. De officiële DNF5-documentatie noemt de timer dnf5-automatic.timer, plaatst de meegeleverde standaardinstellingen in /usr/share/dnf5/dnf5-plugins/automatic.conf, terwijl uw eigen overschrijvingen in /etc/dnf/automatic.conf blijven staan. De standaardwaarde voor download_updates is nu yes in plaats van no, en distro-sync is toegevoegd als upgrade_type. De query voor adviezen is dnf advisory list, waarbij updateinfo als alias behouden blijft. Controleer wat er daadwerkelijk op uw systeem is 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 beschikbare opties zijn uitgebreid sinds die teksten zijn geschreven; controleer daarom het bestand met commentaar 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 geeft disabled weer. Het pakket is geïnstalleerd, maar de timer nooit.

De taak wordt uitgevoerd en installeert niets. Het logboek bevat No security updates needed, but 3 updates available. Het beveiligingsfilter vond geen overeenkomsten, ofwel omdat er geen updates met een advies in de wachtrij staan, 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 eeuwig 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. Rocky Linux en AlmaLinux publiceren deze metadata, waardoor het filter advisories kan matchen. De standaardinstelling is upgrade_type = default, waarmee elke beschikbare update wordt geïnstalleerd 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 elke advisory de bijbehorende pakketten vermeldt. Wanneer deze metadata ontbreekt of verouderd is, matcht het beveiligingsfilter niets, terwijl er nog wel gewone updates openstaan. Dit resulteert in die specifieke melding. Dit is te verwachten op CentOS Stream, aangezien daar helemaal geen errata worden gepubliceerd. Vergelijk op Rocky of AlmaLinux de output 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 daarom vraagt. 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 sinds de laatste boot is vervangen. 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 werkt; zonder deze regel blijft de standaarduitvoering om 06:00 actief en wordt er een tweede tijdstip toegevoegd. Controleer dit met systemctl list-timers dnf-automatic.timer en lees de kolom NEXT.

Moet ik nog steeds een server controleren die zichzelf patcht?

Ja. dnf-automatic installeert pakketten en stopt daar. 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 te achterhalen welke services nog steeds oude code uitvoeren.