Jinsi ya kusanidi dnf-automatic kwenye Rocky na AlmaLinux

Kazi ya dnf-automatic kwenye Rocky Linux na AlmaLinux

dnf-automatic ndiyo njia ya kupata masasisho ya usalama ya kiotomatiki kwenye Rocky Linux na AlmaLinux. Hii ni programu ndogo, inayozinduliwa na systemd timer, inayosoma /etc/dnf/automatic.conf na kutekeleza kile ambacho faili hiyo inaruhusu. Usakinishaji unahitaji amri moja tu. Sehemu iliyobaki ya mwongozo huu inahusu mipangilio inayoamua kama programu hii italinda seva yako au itakaa kimya bila kufanya chochote.

Ikiwa unatoka Debian au Ubuntu, hii inafanya kazi sawa na unattended-upgrades kwenye Ubuntu VPS. Kuna tofauti moja muhimu kuliko nyingine zote: maana ya neno "security" kwa meneja wa vifurushi (package manager). Kwenye Ubuntu, hii ni sehemu tofauti ya hazina (archive pocket). Kwenye familia ya RHEL, hii ni metadata iliyoambatishwa kwenye ushauri (advisories) zilizochapishwa, na metadata hiyo inaweza kukosekana au kupitwa na wakati. Ukielekeza dnf-automatic kwenye hazina (repository) isiyo na data ya ushauri, haitasakinisha chochote huku ikiripoti kuwa imefanikiwa.

Mwongozo huu umeandikwa kwa ajili ya Rocky Linux 9 na AlmaLinux 9, zinazotumia DNF 4 (DNF ndiye meneja wa vifurushi kwenye familia ya RHEL), kufikia Agosti 2026. Matoleo ya 10 yamehamia DNF5 na majina yamebadilika huko, kwa hivyo yana sehemu yake maalum karibu na mwisho. Kila amri hapa chini ni ya wewe kuiendesha kwenye seva yako, pamoja na matokeo unayopaswa kutarajia kando yake.

Sakinisha dnf-automatic na usome faili ya usanidi inayokuja nayo

Kuwezesha masasisho ya kiotomatiki ni sehemu ya usanidi wa awali kama ilivyoainishwa katika dakika kumi za kwanza kwenye VPS mpya, mara tu baada ya kuwa na mtumiaji asiye root na firewall.

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

systemctl is-enabled huchapisha disabled kwenye usakinishaji mpya, kwa sababu kusakinisha kifurushi hakuanzishi huduma yoyote. Hiyo ndiyo sababu ya kawaida inayofanya seva ambayo "ina dnf-automatic" kutotekeleza hata sasisho moja.

Toleo la DNF ni muhimu kwa chaguo moja. Mpangilio wa reboot uliongezwa kwenye DNF 4.15, na Red Hat iliingiza kipengele hicho kwenye dnf-4.14.0-6.el9 mnamo Novemba 2023 kupitia ushauri wa RHBA-2023:6645. Rocky 9 na AlmaLinux 9 hufanya upya kifurushi hicho, kwa hivyo seva iliyosasishwa inacho, lakini seva ambayo haijaguswa tangu 2023 haina.

Faili ya usanidi ni /etc/dnf/automatic.conf. Nakala inayokuja na kifurushi inaorodhesha kila chaguo linalotambuliwa na toleo hili, ikiwa na thamani yake ya msingi ikiwa imewekwa kwenye maoni (commented). Isome mara moja kabla ya kuibadilisha, kwa sababu faili hiyo ndiyo chanzo sahihi cha ukweli kuhusu toleo lako.

Swichi mbili zinazoamua kitakachotokea

download_updates na apply_updates katika sehemu ya [commands] huamua tabia ya mfumo. Zote mbili ni no kwa chaguo-msingi kwenye EL9 (enterprise Linux 9, msingi wa pamoja wa Rocky 9 na AlmaLinux 9), kwa hivyo dnf-automatic ambayo haijahaririwa na ukaikamilisha itakuambia tu kile kinachopatikana.

• Zote no: dnf-automatic huripoti masasisho yanayopatikana na haibadilishi chochote kwenye seva.
• download_updates = yes na apply_updates = no: vifurushi hupakuliwa kwenye cache ya DNF. Usakinishaji huwa wa haraka na hauhitaji mtandao, lakini hakuna kilichobadilika usiku huo.
• Zote yes na upgrade_type = default: kila sasisho linalopatikana husakinishwa, iwe ni la usalama au la.
• Zote yes na upgrade_type = security: vifurushi vilivyotajwa katika ushauri wa usalama pekee ndivyo husakinishwa.

Sehemu nzuri ya kuanzia kwa VPS inayotazamana na umma:

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

network_online_timeout ni sekunde ngapi operesheni husubiri mtandao ufanye kazi kabla ya kukata tamaa, jambo ambalo ni muhimu kwenye seva iliyowashwa upya. random_sleep ni njia ya zamani ya kusambaza mzigo kwenye mashine nyingi, na kipima muda (timer) hufanya kazi hiyo sasa. Endesha systemctl cat dnf-automatic.service ili kuona flag kamili ambazo huduma iliyosafirishwa hutumia.

Thibitisha kuwa faili inafanya unachofikiri, bila kusubiri hadi saa 06:00:

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

Jarida (journal) linaonyesha kile operesheni ilichozingatia na ilichokifanya. Unaweza pia kulazimisha tabia moja kutoka kwa mstari wa amri, ambayo hupuuza faili kwa operesheni hiyo pekee:

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

Maana halisi ya upgrade_type = security kwenye Rocky na Alma

DNF haibaini kama sasisho ni la kiusalama kwa kulinganisha namba za toleo. Inasoma metadata ya errata: faili linaloitwa updateinfo.xml lililochapishwa ndani ya hazina (repository), ambapo kila ushauri (advisory) huorodhesha vifurushi vinavyorekebisha tatizo husika. AlmaLinux huchapisha haya kama ushauri wa ALSA, Rocky huchapisha kama RLSA. upgrade_type = security huunda kichujio (filter) kutoka kwa metadata hiyo na kusasisha vifurushi vinavyolingana na kichujio hicho pekee.

Kuna matokeo mawili yanayotokana na hili, na yote huwashangaza watumiaji.

Kwanza, kutokuwepo kwa metadata kunamaanisha hakuna sasisho. Ikiwa hazina haina updateinfo.xml, kichujio hakilingani na chochote na mchakato huishia na mstari huu kwenye jarida (journal):

No security updates needed, but 3 updates available

Seva haijafanyiwa viraka (patched), na hakuna kilichoripoti hitilafu. Kagua mwenyewe:

dnf updateinfo list --security
dnf check-update

Ikiwa dnf check-update inaorodhesha vifurushi wakati dnf updateinfo list --security haionyeshi chochote, basi ama hakuna sasisho linalosubiri ambalo lina ushauri, au hazina haina data ya ushauri ya kusoma. Rocky na AlmaLinux zote huchapisha data hii, kwa hivyo kwenye mifumo hiyo miwili, orodha tupu kwa kawaida ni sahihi. CentOS Stream haichapishi data hii kabisa.

Pili, hali ya usalama (security mode) si mabadiliko madogo. dnf-automatic huongeza kichujio cha usalama kisha huendesha njia ya kawaida ya kusasisha, kwa hivyo kifurushi kilichotajwa kwenye ushauri huhamia kwenye toleo jipya zaidi lililopo kwenye hazina na kuvuta utegemezi (dependencies) wake pamoja nacho. Hatua ndogo zaidi, ya kuhamia kwenye toleo la awali kabisa linalorekebisha ushauri huo, ni dnf upgrade-minimal --security inayofanywa kwa mikono. dnf-automatic haina mpangilio wa kufanya hivi.

Tahadhari nyingine inahusu Rocky. Rocky hutengeneza errata yake kutoka kwa data ya Red Hat kupitia mfumo wake wa ndani, na mfumo huo umekuwa ukichelewa. Mnamo Septemba 2025, watumiaji waliripoti kuwa updateinfo.xml ya Rocky 9 BaseOS haikuwa imebadilika tangu Desemba 2024, kwa hivyo --security ilikuwa imekosa ushauri wa hivi karibuni, na wafanyakazi wa Rocky walithibitisha kuwa hilo ni tatizo linalojulikana. Ikiwa unategemea upgrade_type = security, linganisha orodha ya ushauri na matangazo ya hivi karibuni ya RLSA mara kwa mara. Kwenye seva ambapo usalama ni muhimu zaidi kuliko udhibiti wa mabadiliko, upgrade_type = default kwa ratiba unayochagua ndiyo mpangilio salama zaidi.

Timer ya systemd inayoiendesha

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

list-timers inapaswa kuonyesha safu moja yenye muda wa NEXT ambao ni takriban siku moja ijayo. Jedwali tupu linamaanisha kuwa timer haijawashwa, kwa hivyo hakuna kitakachowahi kuendeshwa.

Timer iliyokuja na programu huanza saa *-*-* 6:00 ikiwa na RandomizedDelaySec=60m na Persistent=true. Ucheleweshaji wa nasibu (random delay) husambaza kazi kwenye kundi la seva ndani ya saa moja ili kila seva isigonge mirror kwa sekunde moja. Persistent=true inamaanisha kuwa mashine iliyokuwa imezimwa saa 06:00 itaendesha kazi iliyokosa muda mfupi baada ya kuwaka, badala ya kuruka siku hiyo.

Badilisha ratiba kwa kutumia drop-in. Usihariri unit iliyokuja na programu, kwa sababu upgrade ya kifurushi hubadilisha faili zilizo chini ya /usr/lib/systemd/system.

sudo systemctl edit dnf-automatic.timer

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

Mstari mtupu wa OnCalendar= unahitajika. OnCalendar hujikusanya, kwa hivyo bila kufuta huko utabaki na ingizo la saa 06:00 na kuongeza la pili, na kazi itaendeshwa mara mbili kwa siku. Thibitisha matokeo kwa systemctl list-timers dnf-automatic.timer na usome safu ya NEXT. Kanuni zilezile za drop-in hutumika kwa kitu kingine chochote unachopanga, jambo ambalo limefafanuliwa katika kuandika systemd service na timer units.

Sasa, mtego wenyewe. Kifurushi hicho huja na timer nyingine tatu: dnf-automatic-notifyonly.timer, dnf-automatic-download.timer na dnf-automatic-install.timer. Kila moja huanzisha programu ileile ikiwa na flag za command-line, na flag hizo hubatilisha download_updates na apply_updates kutoka kwenye faili yako ya usanidi. Ukiwasha mojawapo kando ya dnf-automatic.timer, kazi hiyo itaendeshwa mara mbili kwa tabia mbili tofauti, jambo linaloonekana kama faili yako ya usanidi imepuuzwa. Washa timer moja na uangalie:

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

Nitajuaje wakati kitu kiliposakinishwa?

emit_via katika sehemu ya [emitters] hudhibiti utoaji wa ripoti. Chini ya systemd, emitter ya stdio huandika kwenye journal, ambayo ndiyo chaguo la kutegemewa kwa sababu haihitaji kitu kingine chochote kusakinishwa:

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

Emitter ya motd huandika ripoti hiyo ndani ya /etc/motd na kubadilisha yaliyomo kwenye faili hilo. Ikiwa unaweka login banner hapo, usitumie emitter hii.

Emitter ya email hufungua muunganisho wa SMTP (simple mail transfer protocol) kwenda email_host kwenye email_port, ambayo kwa kawaida ni localhost na 25. VPS mpya haina kitu kinachosikiliza hapo, kwa hivyo muunganisho hukataliwa na hakuna barua pepe inayotumwa. Endesha ss -lnt | grep ':25' kabla ya kuitegemea, na usanidi Postfix ya relay-only ikiwa pato ni tupu. Barua pepe ikifanya kazi, kichwa cha habari kitasomeka Updates applied on 'web01'., kikichukua jina kutoka system_name.

Kwa kitu kingine chochote, emitter ya command hukabidhi ripoti hiyo kwa programu yako kupitia 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 kwa kawaida ni no, ambayo inamaanisha kuwa uendeshaji ulioshindwa hautoa ripoti yoyote. Iwezeshe. Mfumo wa patching unaotangaza mafanikio yake pekee ni mbaya zaidi kuliko kutokuwa na mfumo wowote, kwa sababu ukimya hufasiriwa kama hali nzuri ya mfumo.

dnf-automatic haianzishi upya huduma zako

Kusakinisha kifurushi hubadilisha faili kwenye diski. Mchakato unaoendelea kufanya kazi huendelea kutumia msimbo wa zamani uliopo kwenye kumbukumbu, kwa hivyo maktaba iliyorekebishwa haitafanya kazi kwa daemon iliyoanza mwezi uliopita. Pengo hilo kati ya kilichosakinishwa na kinachofanya kazi ndilo sababu inayofanya urekebishaji wa kiotomatiki kuhitaji sera ya kuanzisha upya (restart policy) na si sera ya kusakinisha pekee.

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

-s huorodhesha huduma za systemd ambazo faili zake zimebadilika baada ya kuanza. -r hujibu swali moja, na kuchapisha moja ya vizuizi viwili:

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 si uchambuzi wa kina. Hukagua orodha maalum ya vifurushi: kernel, kernel-core, kernel-rt, glibc, linux-firmware, systemd, dbus, dbus-broker, dbus-daemon na microcode_ctl. Ikiwa mojawapo ilisakinishwa baada ya boot ya mwisho, utapata jibu la kwanza. Ongeza majina yako ya vifurushi kwenye faili inayoishia na .conf chini ya /etc/dnf/plugins/needs-restarting.d/ wakati kitu kingine kwenye seva kinahitaji reboot ili kianze kufanya kazi.

Tahadhari moja kwa hati (scripts): dnf needs-restarting -r hutoka (exit) kwa hali isiyo ya sifuri (non-zero) wakati reboot inahitajika na pia wakati amri yenyewe imeshindwa, kwa hivyo hali ya kutoka (exit status) pekee haiwezi kutofautisha hayo. Soma maandishi ya matokeo.

Kuanzisha upya huduma ni hatua ndogo na kwa kawaida ndiyo sahihi. Anzisha upya SSH daemon kutoka kwa kikao cha pili cha SSH ambacho tayari kimefunguliwa, ili usanidi mbaya usikufungie nje. Kernel mpya ni hali ambapo reboot pekee ndiyo husaidia, kwa sababu kernel inayofanya kazi haiwezi kubadilishwa ikiwa bado inatumika.

Je, seva inapaswa kujiwasha upya yenyewe?

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

reboot = never ndiyo chaguo-msingi. when-changed huwasha upya seva baada ya kila sasisho lililowekwa. when-needed huwasha upya seva pale tu ambapo ukaguzi wa nyuma wa needs-restarting -r unapoonyesha kuwa kifurushi cha msingi (core package) kimebadilishwa, jambo ambalo ndilo linalohitajika na wamiliki wengi wa seva moja, likiambatana na muda wa kusubiri waliochagua wenyewe. Chaguo-msingi la reboot_command huwapa watumiaji walioingia kwenye mfumo onyo la dakika tano kupitia shutdown, na unaweza kuongeza muda huo.

Thibitisha mambo mawili kabla ya kuwasha kipengele hiki. Kila huduma unayotegemea lazima ianze yenyewe wakati wa boot, jambo ambalo mara nyingi husahaulika kwa Docker Compose stack iliyoanzishwa kwa mkono. Pia, unahitaji uwezo wa kufikia console au hali ya rescue kutoka kwa mtoa huduma wako, kwa sababu kernel isiyoweza kuwaka haiwezi kurekebishwa kupitia SSH. Ikiwa mojawapo ya haya hayapo, weka reboot = never na uwashe upya seva mwenyewe baada ya kusoma journal.

Rocky, AlmaLinux na CentOS Stream: tofauti zao

Kwenye Rocky 9 na AlmaLinux 9 kila kitu kilichotajwa hapo juu ni sawa, kuanzia njia ya faili za usanidi (config path) hadi majina ya unit. Zote mbili huchapisha errata, kwa hivyo upgrade_type = security ina data inayoweza kuchujwa.

CentOS Stream ni ubaguzi, na ni ubaguzi mgumu. Repositories za Stream hazibebi updateinfo.xml, kwa hivyo kichujio cha usalama hakiwezi kupata matokeo yoyote na kila uendeshaji huripoti No security updates needed. Kwenye Stream, tumia upgrade_type = default na ukubali kuwa unapokea kila sasisho. Stream pia huenda mbele ya RHEL, kwa hivyo mpangilio huo hubadilika zaidi kwenye mashine ya Stream kuliko mpangilio uleule kwenye Rocky au AlmaLinux.

Rocky 10 na AlmaLinux 10 zimehamia kwenye DNF5, ambayo hubadilisha majina ya vitu. Nyaraka za DNF5 kutoka kwa msanidi mkuu zinaonyesha timer kama dnf5-automatic.timer, huweka chaguo-msingi zilizokuja na programu kwenye /usr/share/dnf5/dnf5-plugins/automatic.conf huku marekebisho yako yakibaki kwenye /etc/dnf/automatic.conf, huweka download_updates kuwa yes badala ya no, na huongeza distro-sync kama upgrade_type. Hoja ya ushauri (advisory query) ni dnf advisory list, huku updateinfo ikibaki kama alias. Thibitisha kile ambacho toleo lako limesakinisha hasa kabla ya kunakili majina ya vifurushi au unit kutoka kwenye mwongozo ulioandikwa kwa ajili ya toleo la 9:

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

Miongozo mingi iliyochapishwa kuhusu mada hii bado inashughulikia Rocky 8 pekee. Seti ya chaguzi imekua tangu miongozo hiyo iandikwe, kwa hivyo kagua faili yenye maelezo (commented file) kwenye mashine yako badala ya kuamini makala ya zamani.

Njia za kufeli na ujumbe utakaouona

Hakuna kinachoendeshwa. systemctl list-timers dnf-automatic.timer inachapisha jedwali tupu na systemctl is-enabled dnf-automatic.timer inachapisha disabled. Kifurushi kiliwekwa, lakini kipima muda (timer) hakikuwekwa.

Kazi inaendeshwa lakini haisakinishi kitu. Journal ina ujumbe wa No security updates needed, but 3 updates available. Kichujio cha usalama hakikupata kitu, aidha kwa sababu hakuna kinachosubiri chenye ushauri (advisory) au kwa sababu hazina (repository) haichapishi data za ushauri.

Mpangilio unaonekana kupuuzwa. DNF inaandika chaguo lisilojulikana katika automatic.conf kwenye kiwango cha debug kisha inatumia chaguo-msingi, kwa hivyo ufunguo uliokosewa kuandikwa haubadilishi kitu na haumuonyi mtu yeyote. Andika apply_update = yes na apply_updates inabaki kuwa no, kwa hivyo seva inapakua milele na haisakinishi kamwe. Baada ya kuhariri chochote, endesha sudo systemctl start dnf-automatic.service na usome journal badala ya kuamini faili.

Kazi inaendeshwa mara mbili kwa siku. Vipima muda viwili vimewezeshwa. systemctl list-unit-files 'dnf-automatic*' inaonyesha vipi, na vile vya ziada vinapitisha flag zinazozidi usanidi wa faili yako.

Barua pepe haifiki. Aidha hakuna kinachosikiliza kwenye port 25 kwa ajili ya emitter ya email, au send_error_messages bado ni no na kitu pekee cha kuripoti kilikuwa hitilafu.

Huduma iliyorekebishwa bado inaripoti toleo la zamani. Faili iliyo kwenye diski ni mpya na mchakato uliopo kwenye kumbukumbu (memory) ni wa zamani. dnf needs-restarting -s inataja huduma zinazopaswa kuanzishwa upya.

FAQ

Je, dnf-automatic husakinisha masasisho ya usalama pekee kwenye Rocky Linux?

Ni pale tu utakapoweka upgrade_type = security katika /etc/dnf/automatic.conf, na ikiwa hazina zako (repositories) zinachapisha metadata ya errata. Rocky Linux na AlmaLinux zote huchapisha metadata hiyo, kwa hivyo kichujio kinaweza kulinganisha na ushauri wa kiusalama. Chaguo-msingi lililopo ni upgrade_type = default, ambalo husakinisha kila sasisho linalopatikana mara tu apply_updates = yes.

Kwa nini dnf-automatic inaripoti "No security updates needed, but 3 updates available"?

DNF huamua ni nini kinachozingatiwa kama sasisho la usalama kwa kusoma updateinfo.xml kutoka kwenye hazina, ambapo kila ushauri huorodhesha vifurushi vinavyorekebisha tatizo husika. Metadata hiyo inapokosekana au kupitwa na wakati, kichujio cha usalama hakioni kitu chochote wakati masasisho ya kawaida bado yanasubiri, jambo linalozalisha ujumbe huo. Hii ni kawaida kwenye CentOS Stream, ambayo haichapishi errata yoyote. Kwenye Rocky au AlmaLinux, linganisha dnf updateinfo list --security dhidi ya dnf check-update na uhakikishe kuwa metadata yako ni ya sasa.

Je, dnf-automatic itawasha upya seva yangu baada ya sasisho la kernel?

Haitafanya hivyo isipokuwa ukiagiza. Chaguo la reboot lina thamani-msingi ya never. Weka reboot = when-needed na mfumo utawaka upya tu wakati ukaguzi ulio nyuma ya dnf needs-restarting -r utakapobaini kuwa kifurushi muhimu kama kernel au glibc kimebadilishwa tangu seva iwake. reboot = when-changed huwasha upya baada ya sasisho lolote kutumika. Zote hutumia reboot_command, ambayo ina thamani-msingi ya shutdown -r +5 ikiambatana na ujumbe wa onyo kwa watumiaji walioingia kwenye mfumo.

Ninawezaje kubadilisha muda ambao dnf-automatic inafanya kazi?

Tekeleza sudo systemctl edit dnf-automatic.timer na uongeze sehemu ya [Timer] yenye mstari wa OnCalendar= usio na kitu, ikifuatiwa na ratiba yako, kwa mfano OnCalendar=*-*-* 03:30. Mstari usio na kitu unahitajika kwa sababu OnCalendar hujilimbikiza, hivyo kuuuacha kutasababisha ratiba ya saa 06:00 iliyokuja na mfumo kubaki na kuongeza ya pili. Thibitisha kwa systemctl list-timers dnf-automatic.timer na usome safu ya NEXT.

Je, bado ninahitaji kukagua seva inayojisasisha yenyewe?

Ndiyo. dnf-automatic husakinisha vifurushi na kuishia hapo. Haianzishi upya daemons, na hairipoti chochote utakachokiona isipokuwa emit_via itaje mfumo wa utoaji taarifa (emitter) unaousoma kweli. Weka emit_via kuwa stdio kama kiwango cha chini, washa send_error_messages ili makosa yaripotiwe pia, na utekeleze dnf needs-restarting -s baada ya muda wa kusasisha ili kubaini huduma zinazoendelea kutumia msimbo wa zamani.