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 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 mapoprotektahan 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 sa iba ang isang pagkakaiba: ang kahulugan ng salitang "security" para sa package manager. Sa Ubuntu, hiwalay itong archive pocket. Sa RHEL family, metadata ito na nakakabit sa mga published advisory, at maaaring wala o luma na ang metadata na iyon. Kung ituturo mo ang dnf-automatic sa repository na walang advisory data, wala itong ii-install kahit mag-report itong successful.

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 sarili silang section malapit sa dulo. Ang bawat command sa ibaba ay para patakbuhin mo sa sarili mong server, kasama ang output na dapat mong asahan sa tabi nito.

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

Kasama sa setup ng unang sampung minuto sa bagong VPS ang pag-enable ng automatic updates, pagkatapos mong magkaroon ng non-root user at firewall.

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. Ni-backport ito ng Red Hat sa dnf-4.14.0-6.el9 noong November 2023 sa pamamagitan ng advisory na RHBA-2023:6645. Rebuild ng Rocky 9 at AlmaLinux 9 ang package na iyon. Kaya mayroon nito ang kasalukuyang box, ngunit wala nito ang box 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 na naka-comment. Basahin muna ito bago mag-edit, dahil ang file na iyon ang nagsasabi ng aktuwal na configuration para sa iyong version.

Ang dalawang switch na nagtatakda kung ano ang mangyayari

Ang download_updates at apply_updates sa seksyong [commands] ang nagtatakda ng 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 wala itong babaguhin sa server.
• download_updates = yes kasama ang apply_updates = no: ida-download ang mga package sa DNF cache. Mabilis ang pag-install pagkatapos at hindi na nito kailangan ng network, pero walang nabago ngayong gabi.
• Parehong yes kasama ang upgrade_type = default: mai-install ang lahat ng available na update, security man o hindi.
• Parehong yes kasama ang upgrade_type = security: mai-install lamang ang mga package na nakalista sa isang security advisory.

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 ang bilang ng segundo na hihintayin ng run para sa gumaganang network bago sumuko. Mahalaga ito sa server na kakasimula pa lamang. 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. Papalitan nito ang file para sa run na iyon lamang:

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 inilalabas sa loob ng repository, kung saan nakalista sa bawat advisory ang mga package na nag-aayos dito. Inilalabas ito ng AlmaLinux bilang ALSA advisories, at ng Rocky bilang RLSA. Gumagawa ang upgrade_type = security ng filter mula sa metadata na ito at ina-upgrade lamang ang mga package na tumutugma rito.

Dalawang resulta ang sumusunod, at parehong nakalilito sa maraming user.

Una, walang updates kapag 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 patched ang server, at walang nag-ulat ng failure. Suriin ito mismo:

dnf updateinfo list --security
dnf check-update

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

Ikalawa, hindi minimal na pagbabago ang security mode. Idinadagdag ng dnf-automatic ang security filter at saka pinapatakbo ang karaniwang upgrade path. Dahil dito, lilipat ang package na nakalista sa isang advisory sa pinakabagong version sa repository at isasama 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 para rito ang dnf-automatic.

May isa pang caveat para sa Rocky. Binubuo 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 ang Rocky 9 BaseOS updateinfo.xml mula December 2024. Dahil dito, nawawala ang mga bagong advisory sa --security, at kinumpirma ito ng Rocky staff bilang isang kilalang issue. Kung umaasa ka sa upgrade_type = security, ihambing paminsan-minsan ang listahan ng advisory sa mga bagong RLSA announcement. Sa server kung saan mas mahalaga ang coverage kaysa change control, mas ligtas na setting ang upgrade_type = default ayon sa schedule na pipiliin mo.

Ang systemd timer na aktuwal na nagpapatakbo nito

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

Dapat mag-print ang list-timers ng isang row na may oras sa NEXT na humigit-kumulang isang araw mula ngayon. Ibig sabihin ng walang laman na table ay hindi naka-enable ang timer, kaya walang kailanman tatakbo.

Tumatakbo ang kasamang timer 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 kumonekta ang lahat ng server sa mirror sa eksaktong parehong segundo. Ibig sabihin ng Persistent=true, kung naka-off ang machine noong 06:00, tatakbo ang na-miss na job makalipas ang ilang sandali pagkatapos nitong mag-boot sa halip na malaktawan ang araw na iyon.

Baguhin ang schedule gamit ang drop-in. Huwag i-edit ang kasamang unit, 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

Kailangan ang walang laman na OnCalendar= line. Naiipon ang OnCalendar, kaya kung wala ang reset na iyon, mananatili ang entry na 06:00 at madaragdagan 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 ang mga panuntunan sa drop-in para sa anumang iba pang ise-schedule mo. Saklaw ito sa pagsulat ng systemd service at timer units.

Narito ang trap. May tatlo pang timer na kasama sa package: dnf-automatic-notifyonly.timer, dnf-automatic-download.timer at dnf-automatic-install.timer. Pare-pareho nilang pinapatakbo ang program gamit ang command-line flags, at ino-override ng mga flag na iyon ang download_updates at apply_updates mula sa iyong config file. Kung ie-enable mo ang isa sa mga ito kasabay ng dnf-automatic.timer, tatakbo nang dalawang beses ang job na may dalawang magkaibang behavior. Magmumukha itong binabalewala ang iyong config file. Mag-enable ng isang timer at suriin:

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

Kailan ko malalaman kung may na-install?

Kinokontrol ng emit_via sa seksyong [emitters] ang pag-uulat. Sa ilalim ng systemd, isinusulat ng stdio emitter ang mga entry 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 report sa /etc/motd at pinapalitan ang buong laman ng file na iyon. Kung may login banner ka roon, huwag isama ang emitter na ito.

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

Para sa iba pang gamit, ipinapasa ng command emitter ang report sa sarili mong program sa 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 iniuulat ang isang failed run. I-enable ito. Mas masahol kaysa sa walang patching system ang sistemang nag-aanunsyo lamang ng mga matagumpay na operasyon, dahil ipinapahiwatig ng katahimikan na maayos ang kalagayan ng system.

Hindi nire-restart ng dnf-automatic ang iyong mga serbisyo

Ang pag-install ng package ay nagpapalit ng mga file sa disk. Ang prosesong tumatakbo na ay nagpapanatili ng lumang code sa memory, kaya walang epekto ang na-patch na library sa daemon na nagsimula noong nakaraang buwan. Ang agwat na ito sa pagitan ng naka-install at aktibong code ang dahilan kung bakit kailangan ng unattended patching ang restart policy, hindi lamang install policy.

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

-s ang naglilista ng mga systemd service na ang mga file ay nagbago mula nang magsimula ang mga ito. Isang tanong lang ang sinasagot ng -r, at isa sa dalawang block ang ipinapakita nito:

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 ginagawa ng -r. Tinitingnan nito ang isang nakatakdang 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 pagkatapos ng huling boot, makukuha mo ang unang sagot. Idagdag ang sarili mong mga pangalan ng package sa file na nagtatapos sa .conf sa ilalim ng /etc/dnf/plugins/needs-restarting.d/ kapag may iba pang bahagi ng server na nangangailangan ng reboot para magkabisa ang pagbabago.

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

Mas maliit na hakbang ang pag-restart ng isang serbisyo, at kadalasan ito ang 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 in place ang kernel na kasalukuyang tumatakbo.

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 lang 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-ari ng single-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 kailangan mo. Karaniwang problema ito sa isang 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 may kulang sa alinman sa mga ito, panatilihing 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, pareho ang lahat ng nasa itaas, pati ang config path at mga unit name. Pareho rin silang naglalabas ng errata, kaya may data na maaaring i-filter ang upgrade_type = security.

Ang CentOS Stream ang exception, at malaking pagkakaiba ito. Walang updateinfo.xml ang Stream repositories, kaya hindi kailanman magmamatch ang security filter at iuulat ng bawat run ang No security updates needed. Sa Stream, gamitin ang upgrade_type = default at tanggapin na lahat ng update ang kukunin mo. Nauuna rin ang Stream sa RHEL, kaya mas maraming pagbabago ang setting na iyon sa isang Stream box kaysa sa parehong setting sa Rocky o AlmaLinux.

Lumipat sa DNF5 ang Rocky 10 at AlmaLinux 10, kaya nagbago ang mga pangalan. Itinuturing ng upstream DNF5 documentation na dnf5-automatic.timer ang timer, inilalagay ang shipped defaults sa /usr/share/dnf5/dnf5-plugins/automatic.conf habang nananatili sa /etc/dnf/automatic.conf ang iyong mga override, itinatakda ang download_updates sa yes sa halip na no, at idinaragdag ang distro-sync bilang isang upgrade_type. Ang advisory query ay dnf advisory list, at nananatiling alias ang updateinfo. Tiyakin muna kung ano talaga ang na-install ng release mo bago kopyahin ang mga pangalan ng package o unit mula sa gabay na isinulat para sa 9:

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

Maraming published guide para sa paksang ito ang tumatalakay pa rin sa Rocky 8 lamang. Mas marami na ang mga option mula nang isulat ang mga iyon, kaya suriin ang commented file sa sarili mong box sa halip na umasa sa lumang article.

Mga failure mode at mga string na makikita mo

Walang anumang 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 na-install ang timer.

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

Mukhang binabalewala ang isang setting. Nagtatala ang DNF ng unknown option sa automatic.conf kapag debug level, at pagkatapos ay ginagamit ang default. Dahil dito, walang epekto at walang warning ang maling spelling ng key. Isulat ang apply_update = yes, at mananatili ang apply_updates sa no. Dahil dito, 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 magtiwala sa 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. Ang mga karagdagang timer ay nagpapasa ng mga flag na nangingibabaw sa configuration file.

Walang dumarating na email. Maaaring walang nakikinig sa port 25 para sa email emitter, o maaaring send_error_messages ay no pa rin at error lamang ang tanging nirereport.

Ang na-patch na service ay nag-uulat pa rin ng lumang version. Bago ang file sa disk, pero luma pa ang process na nasa memory. Tinutukoy ng dnf needs-restarting -s kung aling mga service ang kailangang i-restart.

FAQ

Nag-i-install ba ang dnf-automatic ng security updates lamang sa Rocky Linux?

Oo, kung ise-set mo ang upgrade_type = security sa /etc/dnf/automatic.conf, at kung naglalabas ang iyong mga repository ng errata metadata. Parehong naglalabas 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 “Walang kailangang security update, pero may 3 available na update”?

Tinutukoy ng DNF kung alin ang security update sa pamamagitan ng pagbasa sa updateinfo.xml mula sa repository, kung saan nakalista sa bawat advisory ang mga package na nag-aayos nito. Kapag nawawala o luma ang metadata na iyon, walang tumutugma sa security filter habang may nakabinbin pa ring ordinaryong update, kaya eksaktong lumalabas ang linyang iyon. Inaasahan ito sa CentOS Stream, na walang inilalabas na errata. Sa Rocky o AlmaLinux, ikumpara ang dnf updateinfo list --security sa dnf check-update at tiyaking napapanahon ang iyong metadata.

Awtomatiko bang magre-reboot ang dnf-automatic ng aking server pagkatapos ng kernel update?

Hindi, maliban kung hihilingin mo ito. Ang default ng reboot option ay never. I-set ang reboot = when-needed at magre-reboot ang isang run kapag natukoy ng check sa likod ng dnf needs-restarting -r na may core package gaya ng kernel o glibc na napalitan mula nang mag-boot. Ang reboot = when-changed ay nagre-reboot pagkatapos ng anumang nailapat na update. Parehong gumagamit ang mga ito 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 ng pagtakbo ng dnf-automatic?

Patakbuhin ang sudo systemctl edit dnf-automatic.timer at magdagdag ng [Timer] section na may isang walang-lamang OnCalendar= line, na sinusundan ng iyong schedule, halimbawa OnCalendar=*-*-* 03:30. Kailangan ang walang-lamang line dahil nag-a-accumulate ang OnCalendar. Kung aalisin mo ito, mananatili ang kasamang 06:00 run at madadagdagan ito ng ikalawang run. I-verify gamit ang systemctl list-timers dnf-automatic.timer at basahin ang NEXT column.

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

Oo. Nag-i-install ng packages ang dnf-automatic at doon ito nagtatapos. Hindi nito nire-restart ang mga daemon, at wala kang makikitang report maliban kung ang emit_via ay tumutukoy sa isang emitter na aktuwal mong binabasa. I-set ang emit_via sa stdio bilang minimum, i-enable 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 rin ng lumang code.