dnf-automatic Security Updates sa Rocky at AlmaLinux

Ano ang ginagawa ng dnf-automatic sa Rocky Linux at AlmaLinux

Ang dnf-automatic ang ginagamit para sa unattended security updates sa Rocky Linux at AlmaLinux. Isa itong maliit na program na sinisimulan ng isang systemd timer. Binabasa nito ang /etc/dnf/automatic.conf at inilalapat ang mga pinapahintulutan ng file na iyon. Isang command lang ang kailangan para sa installation. Ang natitirang bahagi ng gabay na ito ay tungkol sa mga setting na tumutukoy kung poprotektahan nito ang server o tahimik na walang gagawin.

Kung galing ka sa Debian o Ubuntu, ito ang katumbas ng ginagawa ng unattended-upgrades sa isang Ubuntu VPS. Mas mahalaga kaysa sa ibang pagkakaiba ang kahulugan ng salitang "security" para sa package manager. Sa Ubuntu, hiwalay itong archive pocket. Sa RHEL family, metadata itong nakakabit sa mga naka-publish na advisory, at maaaring wala o luma na ang metadata na iyon. Kapag itinuro mo ang dnf-automatic sa repository na walang advisory data, wala itong ini-install kahit nag-uulat itong matagumpay ang operasyon.

Isinulat ang gabay na ito para sa Rocky Linux 9 at AlmaLinux 9, na gumagamit ng DNF 4 (ang DNF ang package manager sa RHEL family), hanggang Agosto 2026. Lumipat ang 10 releases sa DNF5 at nagbabago roon ang mga pangalan, kaya may hiwalay silang seksyon malapit sa dulo. Ang bawat command sa ibaba ay dapat mong patakbuhin sa sarili mong server. Katabi nito ang inaasahang output.

Mag-install ng dnf-automatic at basahin ang config na kasama nito

Kasama sa unang setup ang pag-enable ng automatic updates. Gawin ito sa unang sampung minuto sa bagong VPS, pagkatapos magkaroon ng non-root user at firewall. Kung hindi pa tapos ang firewall setup, firewalld ang kasama sa Rocky at AlmaLinux, at may ilang command ito para buksan ang SSH, buksan ang port na ginagamit ng site, at matiyak na mananatiling aktibo ang mga ito pagkatapos ng reboot.

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

Ipinapakita ng systemctl is-enabled ang disabled sa bagong install dahil walang sinisimulan ang pag-install ng package. Ito ang pinakakaraniwang dahilan kung bakit ang server na “may dnf-automatic” ay wala pang nailalapat na kahit isang update.

Mahalaga ang DNF version para sa isang option. Idinagdag upstream ang setting na reboot sa DNF 4.15, at ni-backport ito ng Red Hat sa dnf-4.14.0-6.el9 noong November 2023 sa pamamagitan ng advisory na RHBA-2023:6645. Nire-rebuild ng Rocky 9 at AlmaLinux 9 ang package na iyon, kaya mayroon nito ang kasalukuyang system, ngunit wala nito ang system na hindi na-update mula pa noong 2023.

Ang config file ay /etc/dnf/automatic.conf. Inililista ng kasamang kopya ang bawat option na nauunawaan ng build na ito, kasama ang default nito bilang comment. Basahin muna ito bago mag-edit, dahil ito ang nagsasabi kung ano talaga ang sinusuportahan ng iyong version.

Ang dalawang switch na tumutukoy sa magiging resulta

Tinutukoy ng download_updates at apply_updates sa seksyong [commands] ang behavior. Pareho silang no bilang default sa EL9 (enterprise Linux 9, ang shared base ng Rocky 9 at AlmaLinux 9), kaya ang hindi binagong dnf-automatic na ie-enable mo ay magsasabi lamang kung ano ang available.

• Parehong no: iuulat ng dnf-automatic ang mga available na update at walang babaguhin sa server.
• download_updates = yes na may apply_updates = no: ida-download ang mga package sa DNF cache. Mabilis na ang pag-install pagkatapos at hindi na nito kailangan ng network, pero walang nabago ngayong gabi.
• Parehong yes na may upgrade_type = default: ii-install ang lahat ng available na update, security man o hindi.
• Parehong yes na may upgrade_type = security: mga package lamang na nakalista sa isang security advisory ang ii-install.

Makatuwirang panimulang configuration para sa isang public-facing VPS:

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

Ang network_online_timeout ay kung ilang segundo maghihintay ang run para sa gumaganang network bago sumuko. Mahalaga ito sa server na katatapos lamang mag-boot. Ang random_sleep ay mas lumang paraan ng paghahati ng load sa maraming machine, at timer na ang gumagawa ng tungkuling iyon ngayon. Patakbuhin ang systemctl cat dnf-automatic.service upang makita ang eksaktong flags na ipinapasa ng service na kasama sa package.

Patunayan na ginagawa ng file ang inaasahan mo nang hindi naghihintay hanggang 06:00:

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

Ipinapakita ng journal kung ano ang sinuri ng run at kung ano ang ginawa nito. Maaari ka ring magtakda ng isang behavior mula sa command line. Para sa run na iyon lamang, o-override nito ang file:

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

Ano talaga ang ibig sabihin ng upgrade_type = security sa Rocky at Alma

Hindi tinutukoy ng DNF kung security update ang isang update sa pamamagitan ng paghahambing ng mga version number. Binabasa nito ang errata metadata: isang file na tinatawag na updateinfo.xml na inilalathala sa loob ng repository, kung saan inililista sa bawat advisory ang mga package na nag-aayos sa isyu. Inilalathala ito ng AlmaLinux bilang mga ALSA advisory, at ng Rocky bilang mga RLSA. Gumagawa ang upgrade_type = security ng filter mula sa metadata na ito at ina-upgrade lamang ang mga package na tumutugma rito.

May dalawang resulta rito, at parehong nakalilito sa maraming user.

Una, walang update kung walang metadata. Kung walang updateinfo.xml ang repository, walang matutugmang package ang filter at matatapos ang run sa linyang ito sa journal:

No security updates needed, but 3 updates available

Hindi na-patch ang server, at walang nag-ulat ng failure. Suriin ito mismo:

dnf updateinfo list --security
dnf check-update

Kung naglilista ang dnf check-update ng mga package habang walang inilalabas na anuman ang dnf updateinfo list --security, maaaring walang pending update na may advisory, o walang advisory data ang repository na mabasa. Parehong naglalathala nito ang Rocky at AlmaLinux, kaya sa dalawang iyon, karaniwang tama ang walang laman na listahan. Hindi ito inilalathala ng CentOS Stream.

Ikalawa, hindi minimal change ang security mode. Idinadagdag ng dnf-automatic ang security filter at pagkatapos ay pinapatakbo ang karaniwang upgrade path. Dahil dito, ang package na nakalista sa isang advisory ay inililipat sa pinakabagong version sa repository at kasama nitong kinukuha ang mga dependency nito. Ang mas maliit na hakbang—ang paglipat lamang sa pinakamaagang version na nag-aayos sa advisory—ay dnf upgrade-minimal --security na manu-manong pinapatakbo. Walang setting ang dnf-automatic para rito.

May isa pang caveat para sa Rocky. Ginagawa ng Rocky ang errata nito mula sa data ng Red Hat sa pamamagitan ng sarili nitong pipeline, at nahuli ang pipeline na iyon. Noong September 2025, iniulat ng mga user na hindi gumalaw mula December 2024 ang Rocky 9 BaseOS updateinfo.xml. Dahil dito, nawawala sa --security ang mga bagong advisory, at kinumpirma ng Rocky staff na isa itong kilalang isyu. Kung umaasa ka sa upgrade_type = security, paminsan-minsang ihambing ang listahan ng advisory sa mga bagong RLSA announcement. Sa server kung saan mas mahalaga ang coverage kaysa change control, mas ligtas ang upgrade_type = default ayon sa schedule na pipiliin mo.

Ang aktuwal na nagpapatakbo rito ay ang systemd timer

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

Dapat magpakita ang list-timers ng isang row na may NEXT oras na humigit-kumulang isang araw mula ngayon. Kapag walang laman ang table, hindi naka-enable ang timer kaya walang kailanman tatakbo.

Ang timer na kasama sa package ay tumatakbo sa *-*-* 6:00, gamit ang RandomizedDelaySec=60m at Persistent=true. Ipinapamahagi ng random delay ang mga server sa loob ng isang oras upang hindi sabay-sabay na ma-access ng buong fleet ang mirror sa iisang segundo. Ibig sabihin ng Persistent=true, kapag naka-off ang isang machine noong 06:00, tatakbo ang napalampas na job pagkalipas ng kaunti matapos itong mag-boot, sa halip na laktawan ang araw na iyon.

Baguhin ang schedule gamit ang drop-in. Huwag i-edit ang unit na kasama sa package, dahil pinapalitan ng package upgrade ang mga file sa ilalim ng /usr/lib/systemd/system.

sudo systemctl edit dnf-automatic.timer

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

Kinakailangan ang walang-lamang OnCalendar= line. Naiipon ang OnCalendar, kaya kung hindi mo ito ire-reset, mananatili ang entry na 06:00 at madadagdagan ito ng pangalawang entry. Dahil dito, tatakbo ang job nang dalawang beses bawat araw. Kumpirmahin ang resulta gamit ang systemctl list-timers dnf-automatic.timer at basahin ang column na NEXT. Pareho rin ang mga tuntunin sa drop-in para sa iba pang ise-schedule mo. Tinalakay ito sa pagsulat ng systemd service at timer units.

Narito ang karaniwang problema. May tatlo pang timer na kasama sa package: dnf-automatic-notifyonly.timer, dnf-automatic-download.timer at dnf-automatic-install.timer. Pare-pareho nilang sinisimulan ang program gamit ang command-line flags, at ino-override ng mga flag na iyon ang download_updates at apply_updates mula sa config file mo. Kapag nag-enable ka ng isa sa mga ito kasabay ng dnf-automatic.timer, dalawang beses tatakbo ang job na may magkaibang behavior. Magmumukhang hindi pinapansin ang config file mo. Mag-enable ng isang timer at suriin:

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

Paano ko malalaman kung kailan na-install ang isang bagay?

Kinokontrol ng emit_via sa seksyong [emitters] ang pag-uulat. Sa ilalim ng systemd, isinusulat ng stdio emitter ang output sa journal. Ito ang maaasahang opsyon dahil wala na itong ibang kailangang i-install:

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

Isinusulat ng motd emitter ang ulat sa /etc/motd at pinapalitan ang laman ng file na iyon. Kung may login banner ka roon, huwag isama ang emitter na ito.

Binubuksan ng email emitter ang koneksiyong SMTP (simple mail transfer protocol) sa email_host gamit ang email_port, na ang default ay localhost at 25. Walang nakikinig sa port na iyon sa bagong VPS, kaya tatanggihan ang koneksiyon at walang ipapadalang mail. Patakbuhin ang ss -lnt | grep ':25' bago ito asahan, at mag-set up ng relay-only Postfix kung walang laman ang output. Kapag gumagana na ang mail, ang subject ay Updates applied on 'web01'., at kinukuha ang pangalan mula sa system_name.

Para sa iba pang gamit, ipinapasa ng command emitter ang ulat sa isang program na ikaw ang gumawa, gamit ang 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}

Ang default ng send_error_messages ay no, kaya walang iuulat ang isang nabigong run. I-enable ito. Mas masahol kaysa sa walang patching system ang sistemang tagumpay lamang ang inaanunsyo, dahil ipinapakahulugan ng katahimikan na maayos ang kalagayan.

dnf-automatic ay hindi nagre-restart ng iyong mga service

Pinapalitan ng pag-install ng package ang mga file sa disk. Ang prosesong tumatakbo na ay nananatili sa lumang code na nasa memory, kaya walang epekto ang patched library sa daemon na nagsimula noong nakaraang buwan. Ang agwat sa pagitan ng naka-install at aktuwal na ginagamit ang dahilan kung bakit kailangan ng unattended patching ng restart policy, hindi lamang ng install policy.

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

Inililista ng -s ang mga systemd service na nagbago ang mga file matapos magsimula ang mga ito. Sinasagot ng -r ang isang tanong at nagpi-print ng isa sa dalawang block:

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.

Hindi malalim na pagsusuri ang -r. Sinusuri nito ang nakapirming listahan ng mga package: kernel, kernel-core, kernel-rt, glibc, linux-firmware, systemd, dbus, dbus-broker, dbus-daemon at microcode_ctl. Kung na-install ang isa sa mga ito matapos ang huling boot, makukuha mo ang unang sagot. Idagdag ang sarili mong mga package name sa file na nagtatapos sa .conf sa ilalim ng /etc/dnf/plugins/needs-restarting.d/ kung may iba pang bahagi ng server na kailangan ng reboot bago magkabisa ang pagbabago.

May isang mahalagang limitasyon para sa mga script: nag-e-exit ang dnf needs-restarting -r na may non-zero status kapag kailangan ng reboot at kapag nabigo mismo ang command. Kaya hindi matutukoy ng exit status lang ang pagkakaiba ng dalawang sitwasyon. Basahin ang output text.

Mas maliit na hakbang ang pagre-restart ng service at karaniwan itong tamang gawin. I-restart ang SSH daemon mula sa pangalawang SSH session na nakabukas na, para hindi ka ma-lock out kapag may maling configuration. Ang bagong kernel ang sitwasyong reboot lang ang makalulutas, dahil hindi maaaring palitan ang kernel na kasalukuyang tumatakbo habang nasa operasyon ito. Kung gusto mong paghiwalayin ang mga update sa isang partikular na umaga sa dalawang kategoryang ito, ipinapakita ng kung aling mga update ang nangangailangan ng reboot at alin ang kailangan lamang ng service restart ang resulta package bawat package.

Hiwalay na kaso ang mga container, dahil ina-update ng dnf-automatic ang mga package ng host at hindi nito ginalaw ang userland na naka-embed sa image. Kaya ang server na nagpapatakbo ng Docker Engine sa Rocky Linux o AlmaLinux ay kailangan ding muling mag-pull ng mga image at gumawa ulit ng mga container bago makarating ang fix sa code na aktuwal na naghahatid ng network traffic.

Dapat bang awtomatikong mag-reboot ang server?

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

reboot = never ang default. Nagre-reboot ang when-changed pagkatapos ng anumang nailapat na update. Nagre-reboot lamang ang when-needed kapag sinabi ng check sa likod ng needs-restarting -r na napalitan ang isang core package. Ito ang karaniwang gusto ng mga may iisang server, kasama ang timer window na sila mismo ang pumili. Nagbibigay ang default na reboot_command ng limang minutong babala sa mga naka-login na user sa pamamagitan ng shutdown, at maaari mo itong pahabain.

Ayusin muna ang dalawang bagay bago mo ito i-enable. Kailangang awtomatikong magsimula sa boot ang bawat service na kinakailangan mo. Karaniwang problema ito sa Docker Compose stack na manu-manong sinimulan. Kailangan mo rin ng console o rescue access mula sa provider, dahil hindi maaayos sa SSH ang kernel na hindi nagbo-boot. Kung wala ang alinman sa mga ito, panatilihing naka-disable ang reboot = never at ikaw mismo ang mag-reboot pagkatapos basahin ang journal.

Rocky, AlmaLinux at CentOS Stream: kung saan sila nagkakaiba

Sa Rocky 9 at AlmaLinux 9, magkapareho ang lahat ng nasa itaas, pati ang config path at mga unit name. Pareho silang nagpa-publish ng errata, kaya may data na maaaring i-filter ang upgrade_type = security. Ang stale Rocky errata na inilarawan kanina ay isa sa iilang aktuwal na pagkakaiba sa pang-araw-araw na behavior nila. Kaya kung hindi pa naibubuild ang server, isaalang-alang ito kasama ng compatibility promise at suporta sa mas lumang CPU na naghihiwalay sa dalawa.

Ang CentOS Stream ang exception, at malaking pagkakaiba ito. Walang updateinfo.xml ang mga Stream repository, kaya hindi kailanman magmamatch ang security filter at bawat run ay mag-uulat ng No security updates needed. Sa Stream, gamitin ang upgrade_type = default at tanggapin na lahat ng update ang makukuha mo. Nauuna rin ang Stream sa RHEL, kaya mas madalas magbago ang setting na iyon sa isang Stream server kaysa sa kaparehong setting sa Rocky o AlmaLinux. Hindi ito nagkataon lamang dahil sa packaging. Resulta ito ng desisyon ng Red Hat noong 2020 na gawing rolling preview ng RHEL ang CentOS. Ito rin ang desisyong nagpasimula sa pagkakatatag ng Rocky Linux at AlmaLinux.

Lumipat sa DNF5 ang Rocky 10 at AlmaLinux 10, kaya nagbago ang ilang pangalan. Sa upstream DNF5 documentation, ang timer ay dnf5-automatic.timer. Nasa /usr/share/dnf5/dnf5-plugins/automatic.conf ang mga default na kasama sa package, habang nasa /etc/dnf/automatic.conf pa rin ang mga override mo. Naka-default ang download_updates sa yes sa halip na no. Idinagdag din ang distro-sync bilang upgrade_type. Ang advisory query ay dnf advisory list, at nananatiling alias ang updateinfo. Kumpirmahin muna kung ano talaga ang na-install sa iyong release bago kopyahin ang mga package name o unit name mula sa gabay na isinulat para sa 9:

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

Maraming published guide tungkol sa paksang ito ang para pa rin sa Rocky 8. Mas marami na ang option ngayon kaysa noong isinulat ang mga iyon, kaya suriin ang commented file sa sarili mong server sa halip na umasa sa lumang article.

Mga failure mode at mga string na makikita mo

Walang kailanman tumatakbo. Nagpi-print ang systemctl list-timers dnf-automatic.timer ng walang laman na table at nagpi-print ang systemctl is-enabled dnf-automatic.timer ng disabled. Na-install ang package, pero hindi kailanman na-set up ang timer.

Tumatakbo ang job pero walang nai-install. Makikita sa journal ang No security updates needed, but 3 updates available. Walang tumugma sa security filter, maaaring dahil walang pending update na may advisory o dahil walang advisory data na inilalabas ang repository.

Mukhang hindi pinapansin ang isang setting. Nagtatala ang DNF ng unknown option sa automatic.conf kapag debug level at pagkatapos ay ginagamit ang default. Kaya walang epekto ang maling spelling ng key at wala ring warning. Isulat ang apply_update = yes at nananatili ang apply_updates sa no, kaya patuloy na nagda-download ang server pero walang nai-install. Pagkatapos ng anumang pagbabago, patakbuhin ang sudo systemctl start dnf-automatic.service at basahin ang journal sa halip na basta pagkatiwalaan ang file.

Dalawang beses bawat araw tumatakbo ang job. May dalawang naka-enable na timer. Ipinapakita ng systemctl list-unit-files 'dnf-automatic*' kung alin ang mga ito, at ang mga karagdagang timer ay nagpapasa ng mga flag na nangingibabaw sa iyong config file.

Walang dumarating na mail. Maaaring walang nakikinig sa port 25 para sa email emitter, o maaaring send_error_messages pa rin ang no at error lamang ang ini-report.

Luma pa rin ang bersyong iniuulat ng isang na-patch na service. Bago ang file sa disk ngunit luma ang process na nasa memory. Tinutukoy ng dnf needs-restarting -s kung aling mga service ang kailangang i-restart.

FAQ

Ini-install ba ng dnf-automatic ang mga security update lamang sa Rocky Linux?

Oo, kung ise-set mo ang upgrade_type = security sa /etc/dnf/automatic.conf, at kung nagpa-publish ang iyong mga repository ng errata metadata. Parehong nagpa-publish nito ang Rocky Linux at AlmaLinux, kaya may mga advisory na mapagtutugmaan ang filter. Ang default na kasama sa package ay upgrade_type = default, na nag-i-install ng lahat ng available na update kapag apply_updates = yes.

Bakit nag-uulat ang dnf-automatic ng "No security updates needed, but 3 updates available"?

Tinutukoy ng DNF kung ano ang itinuturing na security update sa pamamagitan ng pagbasa sa updateinfo.xml mula sa repository, kung saan inililista ng bawat advisory ang mga package na nag-aayos sa isyu. Kapag nawawala o luma na ang metadata na iyon, walang natutugma ang security filter habang may nakabinbin pa ring mga ordinaryong update, kaya eksaktong lumalabas ang linyang iyon. Inaasahan ito sa CentOS Stream dahil wala itong pino-publish na errata. Sa Rocky o AlmaLinux, ikumpara ang dnf updateinfo list --security sa dnf check-update at tiyaking napapanahon ang iyong metadata.

Magre-reboot ba ang dnf-automatic ng server ko pagkatapos ng kernel update?

Hindi, maliban kung hihilingin mo ito. Ang reboot option ay may default na never. I-set ang reboot = when-needed, at magre-reboot ang isang run lamang kapag natukoy ng check sa likod ng dnf needs-restarting -r na napalitan mula nang mag-boot ang isang core package gaya ng kernel o glibc. Ang reboot = when-changed ay nagre-reboot pagkatapos ng anumang nailapat na update. Pareho silang gumagamit ng reboot_command, na may default na shutdown -r +5 at nagpapakita ng warning message sa mga naka-login na user.

Paano ko babaguhin ang oras kung kailan tumatakbo ang dnf-automatic?

Patakbuhin ang sudo systemctl edit dnf-automatic.timer at magdagdag ng seksyong [Timer] na may blangkong linyang OnCalendar=, na sinusundan ng iyong schedule, halimbawa OnCalendar=*-*-* 03:30. Kinakailangan ang blangkong linya dahil nag-iipon ang OnCalendar. Kung aalisin ito, mananatili ang kasamang 06:00 run at madaragdagan ito ng pangalawang run. I-verify gamit ang systemctl list-timers dnf-automatic.timer at basahin ang column na NEXT.

Kailangan ko pa bang suriin ang server na awtomatikong nag-i-install ng patches?

Oo. Nag-i-install lamang ng mga package ang dnf-automatic at doon ito nagtatapos. Hindi nito nire-restart ang mga daemon, at wala kang makikitang ulat maliban kung ang emit_via ay tumutukoy sa isang emitter na aktuwal mong binabasa. I-set ang emit_via sa stdio bilang minimum, i-on ang send_error_messages upang maiulat din ang mga failure, at patakbuhin ang dnf needs-restarting -s pagkatapos ng patch window upang makita kung aling mga serbisyo ang gumagamit pa ng lumang code.