Rocky Linux और AlmaLinux पर dnf-automatic कैसे सेटअप करें

Rocky Linux और AlmaLinux पर dnf-automatic क्या करता है

dnf-automatic वह टूल है जिसके जरिए आप Rocky Linux और AlmaLinux पर unattended security updates प्राप्त करते हैं। यह एक छोटा प्रोग्राम है, जिसे systemd timer द्वारा शुरू किया जाता है। यह /etc/dnf/automatic.conf को पढ़ता है और उस फाइल में दी गई अनुमति के अनुसार अपडेट लागू करता है। इसे इंस्टॉल करने के लिए केवल एक कमांड की आवश्यकता होती है। इस गाइड का शेष भाग उन सेटिंग्स के बारे में है जो यह तय करती हैं कि यह आपके सर्वर को सुरक्षित रखेगा या चुपचाप कुछ नहीं करेगा।

यदि आप Debian या Ubuntu से आए हैं, तो यह वही काम करता है जो Ubuntu VPS पर unattended-upgrades करता है। एक अंतर बाकी सभी से अधिक महत्वपूर्ण है: package manager के लिए "security" शब्द का क्या अर्थ है। Ubuntu पर यह एक अलग archive pocket है। RHEL परिवार में यह प्रकाशित advisories के साथ जुड़ी metadata है, और यह metadata गायब या पुरानी हो सकती है। यदि आप dnf-automatic को ऐसी repository पर पॉइंट करते हैं जिसमें advisory data नहीं है, तो यह कुछ भी इंस्टॉल नहीं करेगा और सफलता की रिपोर्ट देगा।

यह गाइड Rocky Linux 9 और AlmaLinux 9 के लिए लिखी गई है, जो अगस्त 2026 तक DNF 4 (DNF, RHEL परिवार का package manager है) का उपयोग करते हैं। 10 releases में DNF5 का उपयोग किया गया है और वहां नाम बदल गए हैं, इसलिए उनके लिए अंत में एक अलग सेक्शन दिया गया है। नीचे दी गई प्रत्येक कमांड आपको अपने सर्वर पर चलानी है, और उसके साथ वह आउटपुट दिया गया है जिसकी आपको अपेक्षा करनी चाहिए।

dnf-automatic इंस्टॉल करें और इसके साथ आने वाली config को पढ़ें

Automatic updates को इनेबल करना नए VPS पर शुरुआती दस मिनट के सेटअप का हिस्सा होना चाहिए, ठीक उसी समय जब आप एक non-root user बना लेते हैं और firewall सेट कर लेते हैं। यदि firewall वाला हिस्सा अभी बाकी है, तो Rocky और AlmaLinux में firewalld पहले से आता है, और कुछ commands चलाकर आप SSH और अपनी site के listening port को open कर सकते हैं, साथ ही यह सुनिश्चित कर सकते हैं कि reboot के बाद भी ये settings बनी रहें।

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

systemctl is-enabled एक fresh install पर disabled प्रिंट करता है, क्योंकि package इंस्टॉल करने से कोई service अपने आप start नहीं होती। यही सबसे आम कारण है कि जिस सर्वर पर "dnf-automatic" मौजूद है, उसने कभी कोई update apply नहीं किया।

एक option के लिए DNF का version मायने रखता है। reboot setting DNF 4.15 में upstream आई थी, और Red Hat ने इसे नवंबर 2023 में advisory RHBA-2023:6645 के माध्यम से dnf-4.14.0-6.el9 में backport किया था। Rocky 9 और AlmaLinux 9 इस package को rebuild करते हैं, इसलिए एक current box में यह मौजूद है, जबकि 2023 से बिना update किए गए box में यह नहीं होगा।

Config file /etc/dnf/automatic.conf है। इसकी जो copy साथ आती है, उसमें इस build द्वारा समझे जाने वाले सभी options और उनके default values, comment के रूप में दिए गए हैं। इसे edit करने से पहले एक बार जरूर पढ़ें, क्योंकि वही file आपके version के लिए वास्तविक जानकारी का स्रोत है।

वे दो स्विच जो यह तय करते हैं कि क्या होगा

download_updates और apply_updates, [commands] सेक्शन में, व्यवहार को निर्धारित करते हैं। EL9 (Enterprise Linux 9, जो Rocky 9 और AlmaLinux 9 का साझा आधार है) पर डिफ़ॉल्ट रूप से ये दोनों no होते हैं, इसलिए यदि आप बिना किसी बदलाव के dnf-automatic को enable करते हैं, तो यह केवल आपको उपलब्ध अपडेट्स के बारे में सूचित करेगा।

• दोनों no: dnf-automatic केवल उपलब्ध अपडेट्स की रिपोर्ट करता है और सिस्टम में कोई बदलाव नहीं करता है।
• download_updates = yes के साथ apply_updates = no: पैकेज DNF कैश में डाउनलोड कर लिए जाते हैं। इसके बाद इंस्टॉलेशन तेज़ होता है और नेटवर्क की आवश्यकता नहीं होती, लेकिन वर्तमान में कोई बदलाव नहीं किया जाता है।
• दोनों yes के साथ upgrade_type = default: सभी उपलब्ध अपडेट्स इंस्टॉल कर दिए जाते हैं, चाहे वे सुरक्षा से संबंधित हों या नहीं।
• दोनों yes के साथ upgrade_type = security: केवल वे पैकेज इंस्टॉल किए जाते हैं जो सुरक्षा एडवाइजरी में नामित हैं।

पब्लिक-फेसिंग VPS के लिए एक उचित शुरुआती बिंदु:

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

network_online_timeout यह निर्धारित करता है कि नेटवर्क के काम करने के लिए रन कितने सेकंड प्रतीक्षा करेगा, जो अभी-अभी बूट हुए सर्वर के लिए महत्वपूर्ण है। random_sleep कई मशीनों पर लोड को विभाजित करने का एक पुराना तरीका है, और अब यह काम timer द्वारा किया जाता है। यह देखने के लिए कि शिप की गई सर्विस कौन से सटीक फ्लैग्स का उपयोग करती है, systemctl cat dnf-automatic.service चलाएं।

यह साबित करने के लिए कि फाइल आपकी अपेक्षा के अनुसार काम करती है, बिना 06:00 बजे तक प्रतीक्षा किए:

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

जर्नल यह दिखाता है कि रन ने क्या विचार किया और क्या किया। आप कमांड लाइन से भी एक विशिष्ट व्यवहार को लागू कर सकते हैं, जो केवल उस रन के लिए फाइल की सेटिंग्स को ओवरराइड कर देगा:

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

Rocky और Alma पर upgrade_type = security का वास्तविक अर्थ

DNF यह तुलना नहीं करता कि कोई अपडेट सुरक्षा अपडेट है या नहीं, इसके लिए वह केवल version numbers नहीं देखता। यह errata metadata पढ़ता है: एक फाइल जिसे updateinfo.xml कहा जाता है, जो repository के भीतर प्रकाशित होती है, जहाँ प्रत्येक advisory उन packages की सूची देती है जिन्हें वह ठीक करती है। AlmaLinux इन्हें ALSA advisories के रूप में प्रकाशित करता है, Rocky इन्हें RLSA के रूप में प्रकाशित करता है। upgrade_type = security उस metadata से एक filter बनाता है और केवल उन packages को अपग्रेड करता है जो उससे मेल खाते हैं।

इसके दो परिणाम होते हैं, और दोनों ही लोगों को आश्चर्यचकित करते हैं।

पहला, metadata न होने का अर्थ है कोई अपडेट नहीं। यदि repository में कोई updateinfo.xml नहीं है, तो filter किसी भी चीज़ से मेल नहीं खाता और run journal में इस line के साथ समाप्त हो जाता है:

No security updates needed, but 3 updates available

सर्वर पैच नहीं हुआ है, और किसी ने भी विफलता की सूचना नहीं दी। स्वयं जाँच करें:

dnf updateinfo list --security
dnf check-update

यदि dnf check-update packages की सूची दिखाता है जबकि dnf updateinfo list --security कुछ भी print नहीं करता है, तो या तो लंबित अपडेट में कोई advisory नहीं है, या repository के पास पढ़ने के लिए कोई advisory डेटा नहीं है। Rocky और AlmaLinux दोनों इसे प्रकाशित करते हैं, इसलिए उन दोनों पर एक खाली सूची आमतौर पर सही होती है। CentOS Stream इसे बिल्कुल भी प्रकाशित नहीं करता है।

दूसरा, security mode न्यूनतम बदलाव नहीं है। dnf-automatic सुरक्षा filter जोड़ता है और फिर सामान्य upgrade path चलाता है, इसलिए advisory में नामित package repository के नवीनतम version पर चला जाता है और अपने dependencies को भी साथ ले आता है। छोटा कदम, यानी केवल उस शुरुआती version पर जाना जो advisory को ठीक करता है, वह dnf upgrade-minimal --security है जिसे हाथ से चलाया जाता है। dnf-automatic में इसके लिए कोई setting नहीं है।

Rocky पर एक और चेतावनी लागू होती है। Rocky अपने errata को Red Hat डेटा से अपनी pipeline के माध्यम से उत्पन्न करता है, और वह pipeline पीछे चल रही है। सितंबर 2025 में उपयोगकर्ताओं ने बताया कि Rocky 9 BaseOS updateinfo.xml दिसंबर 2024 से आगे नहीं बढ़ा था, इसलिए --security में हालिया advisories गायब थीं, और Rocky के कर्मचारियों ने इसे एक ज्ञात समस्या के रूप में पुष्टि की। यदि आप upgrade_type = security पर निर्भर हैं, तो समय-समय पर advisory सूची की तुलना हालिया RLSA घोषणाओं से करें। ऐसे सर्वर पर जहाँ बदलाव नियंत्रण (change control) से अधिक कवरेज मायने रखती है, अपनी पसंद के schedule पर upgrade_type = default चलाना अधिक सुरक्षित setting है।

वह systemd timer जो वास्तव में इसे चलाता है

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

list-timers को एक पंक्ति दिखानी चाहिए जिसमें NEXT समय लगभग एक दिन बाद का हो। यदि तालिका खाली है, तो इसका मतलब है कि timer enabled नहीं है, इसलिए कुछ भी कभी नहीं चलेगा।

shipped timer *-*-* 6:00 पर RandomizedDelaySec=60m और Persistent=true के साथ चलता है। random delay एक पूरे fleet के load को एक घंटे में फैला देता है ताकि हर सर्वर एक ही सेकंड में mirror को hit न करे। Persistent=true का अर्थ है कि जो मशीन 06:00 बजे बंद थी, वह boot होने के तुरंत बाद छूटे हुए job को चलाएगी, न कि उस दिन को छोड़ देगी।

schedule को बदलने के लिए drop-in का उपयोग करें। shipped unit को edit न करें, क्योंकि package upgrade /usr/lib/systemd/system के अंतर्गत मौजूद फाइलों को बदल देता है।

sudo systemctl edit dnf-automatic.timer

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

खाली OnCalendar= पंक्ति आवश्यक है। OnCalendar जमा (accumulate) होता रहता है, इसलिए उस reset के बिना आप 06:00 वाली entry को बनाए रखेंगे और एक दूसरी entry जोड़ देंगे, जिससे job दिन में दो बार चलेगा। systemctl list-timers dnf-automatic.timer के साथ परिणाम की पुष्टि करें और NEXT column को पढ़ें। यही drop-in नियम किसी भी अन्य चीज़ पर लागू होते हैं जिसे आप schedule करते हैं, जिसे writing systemd service and timer units में कवर किया गया है।

अब मुख्य समस्या। यह package तीन और timers के साथ आता है: dnf-automatic-notifyonly.timer, dnf-automatic-download.timer और dnf-automatic-install.timer। प्रत्येक एक ही program को command-line flags के साथ शुरू करता है, और वे flags आपकी config file से download_updates और apply_updates को override कर देते हैं। dnf-automatic.timer के साथ-साथ उनमें से किसी एक को enable करने पर job दो अलग-अलग व्यवहारों के साथ दो बार चलेगा, जो बिल्कुल ऐसा दिखेगा जैसे आपकी config file को ignore किया जा रहा है। एक timer को enable करें और जाँचें:

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

मुझे कैसे पता चलेगा कि कोई चीज़ कब install की गई थी?

emit_via, [emitters] सेक्शन में रिपोर्टिंग को नियंत्रित करता है। systemd के अंतर्गत, stdio emitter journal में लिखता है, जो कि सबसे भरोसेमंद विकल्प है क्योंकि इसके लिए किसी अन्य चीज़ को install करने की आवश्यकता नहीं होती:

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

motd emitter रिपोर्ट को /etc/motd में लिखता है और उस फ़ाइल की सामग्री को बदल देता है। यदि आप वहाँ कोई login banner रखते हैं, तो इस emitter का उपयोग न करें।

email emitter email_port पर email_host के लिए एक SMTP (simple mail transfer protocol) कनेक्शन खोलता है, जो डिफ़ॉल्ट रूप से localhost और 25 पर होता है। एक नए VPS पर वहाँ कोई service listening नहीं होती, इसलिए कनेक्शन अस्वीकार कर दिया जाता है और कोई mail नहीं भेजा जाता। इस पर निर्भर होने से पहले ss -lnt | grep ':25' चलाएँ, और यदि आउटपुट खाली है तो relay-only Postfix सेट करें। जब mail काम करने लगे, तो subject Updates applied on 'web01'. पढ़ेगा, जो system_name से नाम लेता है।

किसी भी अन्य चीज़ के लिए, command emitter रिपोर्ट को 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 डिफ़ॉल्ट रूप से no पर सेट होता है, जिसका अर्थ है कि एक failed run कुछ भी रिपोर्ट नहीं करता है। इसे चालू करें। एक ऐसी patching system जो केवल अपनी सफलताओं की घोषणा करती है, वह किसी भी system से बदतर है, क्योंकि खामोशी को स्वास्थ्य (health) मान लिया जाता है।

dnf-automatic आपकी services को restart नहीं करता है

Package install करने से disk पर मौजूद files बदल जाती हैं। जो process पहले से चल रही है, वह पुरानी code को ही memory में रखती है, इसलिए पिछले महीने start हुई daemon पर patch की गई library का कोई असर नहीं पड़ता। install की गई और प्रभावी (effective) स्थिति के बीच का यही अंतर कारण है कि unattended patching के लिए केवल install policy ही नहीं, बल्कि restart policy की भी आवश्यकता होती है।

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

-s उन systemd services की सूची देता है जिनकी files उनके start होने के बाद बदली हैं। -r एक प्रश्न का उत्तर देता है, और दो में से एक block print करता है:

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 कोई गहन विश्लेषण नहीं है। यह packages की एक निश्चित सूची की जाँच करता है: kernel, kernel-core, kernel-rt, glibc, linux-firmware, systemd, dbus, dbus-broker, dbus-daemon और microcode_ctl। यदि इनमें से कोई भी last boot के बाद install किया गया था, तो आपको पहला उत्तर मिलता है। जब server पर किसी अन्य चीज़ को प्रभावी होने के लिए reboot की आवश्यकता हो, तो /etc/dnf/plugins/needs-restarting.d/ के अंतर्गत .conf पर समाप्त होने वाली file में अपने स्वयं के package names जोड़ें।

scripts के लिए एक चेतावनी: dnf needs-restarting -r तब non-zero exit code देता है जब reboot की आवश्यकता होती है और तब भी जब command स्वयं विफल हो जाती है, इसलिए केवल exit status से यह पता नहीं लगाया जा सकता है। output text को पढ़ें।

Service को restart करना एक छोटा कदम है और आमतौर पर यही सही होता है। SSH daemon को किसी दूसरे, पहले से खुले हुए SSH session से restart करें, ताकि गलत configuration के कारण आप lock-out न हो जाएँ। नया kernel वह स्थिति है जहाँ केवल reboot ही मदद करता है, क्योंकि चल रहे kernel को सीधे replace नहीं किया जा सकता है। यदि आप किसी विशेष सुबह के updates को इन दो श्रेणियों में बाँटना चाहते हैं, तो किन updates के लिए reboot और किनके लिए केवल service restart की आवश्यकता है लेख package-दर-package output को समझने में मदद करता है।

Containers एक अलग मामला है, क्योंकि dnf-automatic host के packages को patch करता है और image में मौजूद userland को कभी नहीं छूता है। इसलिए, Rocky Linux या AlmaLinux पर Docker Engine चलाने वाले server को भी अपने images को फिर से pull करने और containers को recreate करने की आवश्यकता होती है, इससे पहले कि कोई fix उस code तक पहुँचे जो वास्तव में traffic serve कर रही है।

क्या सर्वर को अपने आप रीबूट होना चाहिए?

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

reboot = never डिफ़ॉल्ट सेटिंग है। when-changed किसी भी अपडेट के लागू होने के बाद रीबूट करता है। when-needed केवल तब रीबूट करता है जब needs-restarting -r के पीछे की जांच यह बताती है कि कोई कोर पैकेज बदला गया है, जो कि अधिकांश सिंगल-सर्वर मालिकों के लिए उपयुक्त है, जिसे उनके द्वारा चुने गए टाइमर विंडो के साथ जोड़ा जाता है। डिफ़ॉल्ट reboot_command लॉग-इन उपयोगकर्ताओं को shutdown के माध्यम से पांच मिनट की चेतावनी देता है, और आप इस अवधि को बढ़ा सकते हैं।

इसे चालू करने से पहले दो चीजें सुनिश्चित कर लें। जिस भी सर्विस पर आप निर्भर हैं, उसे बूट के समय अपने आप शुरू होना चाहिए, जो कि मैन्युअल रूप से शुरू किए गए Docker Compose stack के लिए एक सामान्य कमी है। और आपके पास अपने प्रदाता से कंसोल या रेस्क्यू एक्सेस होना चाहिए, क्योंकि जो कर्नल बूट नहीं होता उसे SSH के माध्यम से ठीक नहीं किया जा सकता। यदि इनमें से कोई भी उपलब्ध नहीं है, तो reboot = never को बनाए रखें और जर्नल पढ़ने के बाद स्वयं रीबूट करें।

Rocky, AlmaLinux और CentOS Stream: इनमें अंतर

Rocky 9 और AlmaLinux 9 पर ऊपर दी गई हर चीज़ समान है, यहाँ तक कि config path और unit names भी। दोनों errata प्रकाशित करते हैं, इसलिए upgrade_type = security में फ़िल्टर करने के लिए डेटा उपलब्ध रहता है। पहले वर्णित पुराना Rocky errata उन कुछ स्थानों में से एक है जहाँ इनका दैनिक व्यवहार वास्तव में अलग होता है, इसलिए यदि सर्वर अभी तक तैयार नहीं किया गया है, तो इसे compatibility promise और older-CPU support जो दोनों को अलग करते हैं के साथ तौलें।

CentOS Stream एक अपवाद है, और यह एक कठिन अपवाद है। Stream repositories में कोई updateinfo.xml नहीं होता, इसलिए security filter कभी भी मैच नहीं कर सकता और हर रन No security updates needed रिपोर्ट करता है। Stream पर, upgrade_type = default का उपयोग करें और यह स्वीकार करें कि आप हर अपडेट ले रहे हैं। Stream, RHEL से आगे चलता है, इसलिए Rocky या AlmaLinux की तुलना में Stream बॉक्स पर वह सेटिंग अधिक बदलती है। यह अंतर पैकेजिंग की कोई दुर्घटना नहीं है, बल्कि 2020 में Red Hat द्वारा CentOS को RHEL का rolling preview बनाने के निर्णय का परिणाम है, जो कि वही निर्णय है जिसके कारण Rocky Linux और AlmaLinux अस्तित्व में आए।

Rocky 10 और AlmaLinux 10, DNF5 पर चले गए हैं, जो चीजों का नाम बदल देता है। अपस्ट्रीम DNF5 दस्तावेज़ीकरण timer को dnf5-automatic.timer के रूप में देता है, shipped defaults को /usr/share/dnf5/dnf5-plugins/automatic.conf में रखता है जबकि आपके overrides अभी भी /etc/dnf/automatic.conf में होते हैं, download_updates को no के बजाय yes पर डिफ़ॉल्ट करता है, और upgrade_type के रूप में distro-sync को जोड़ता है। advisory query dnf advisory list है, जिसमें updateinfo को alias के रूप में रखा गया है। 9 के लिए लिखे गए गाइड से package या unit names कॉपी करने से पहले पुष्टि करें कि आपके release ने वास्तव में क्या इंस्टॉल किया है:

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

इस विषय के लिए कई प्रकाशित गाइड अभी भी केवल Rocky 8 को कवर करते हैं। जब वे लिखे गए थे, तब से option set बढ़ गया है, इसलिए किसी पुराने लेख पर भरोसा करने के बजाय अपने बॉक्स पर मौजूद commented file की जाँच करें।

विफलता के प्रकार और आपको दिखाई देने वाले संदेश

कुछ भी रन नहीं होता। systemctl list-timers dnf-automatic.timer एक खाली टेबल प्रिंट करता है और systemctl is-enabled dnf-automatic.timer disabled प्रिंट करता है। पैकेज इंस्टॉल हो गया था, लेकिन टाइमर कभी सेट नहीं हुआ।

जॉब रन होती है और कुछ भी इंस्टॉल नहीं करती। जर्नल में No security updates needed, but 3 updates available दिखाई देता है। सिक्योरिटी फिल्टर किसी से मैच नहीं हुआ, या तो इसलिए कि पेंडिंग अपडेट में कोई एडवाइजरी नहीं है या रिपॉजिटरी कोई एडवाइजरी डेटा पब्लिश नहीं कर रही है।

एक सेटिंग अनदेखी लगती है। DNF, automatic.conf में एक अज्ञात विकल्प को डिबग लेवल पर लॉग करता है और फिर डिफ़ॉल्ट का उपयोग करता है, इसलिए गलत स्पेलिंग वाली की (key) कुछ नहीं बदलती और किसी को चेतावनी भी नहीं देती। apply_update = yes लिखें और apply_updates, no पर ही रहता है, इसलिए बॉक्स हमेशा डाउनलोड करता रहता है और कभी इंस्टॉल नहीं करता। किसी भी बदलाव के बाद, sudo systemctl start dnf-automatic.service रन करें और फाइल पर भरोसा करने के बजाय जर्नल पढ़ें।

जॉब दिन में दो बार रन होती है। दो टाइमर इनेबल हैं। systemctl list-unit-files 'dnf-automatic*' दिखाता है कि कौन से, और अतिरिक्त टाइमर ऐसे फ्लैग पास करते हैं जो आपकी कॉन्फ़िगरेशन फाइल को ओवरराइड कर देते हैं।

कोई मेल प्राप्त नहीं होता। या तो email एमिटर के लिए पोर्ट 25 पर कोई लिसन नहीं कर रहा है, या send_error_messages अभी भी no है और रिपोर्ट करने लायक एकमात्र चीज एक त्रुटि थी।

एक पैच की गई सर्विस अभी भी पुराना वर्जन दिखाती है। डिस्क पर फाइल नई है और मेमोरी में प्रोसेस पुरानी है। dnf needs-restarting -s उन सर्विसेज के नाम बताता है जिन्हें रीस्टार्ट करना है।

FAQ

क्या dnf-automatic, Rocky Linux पर केवल security updates ही install करता है?

केवल तभी, यदि आप upgrade_type = security को /etc/dnf/automatic.conf में सेट करते हैं, और केवल तभी यदि आपके repositories errata metadata प्रकाशित करते हैं। Rocky Linux और AlmaLinux दोनों इसे प्रकाशित करते हैं, इसलिए filter के पास मिलान करने के लिए advisories होती हैं। डिफ़ॉल्ट रूप से upgrade_type = default सेट होता है, जो apply_updates = yes होने पर हर उपलब्ध update को install कर देता है।

dnf-automatic यह क्यों रिपोर्ट करता है कि "No security updates needed, but 3 updates available"?

DNF यह तय करता है कि क्या security update है, इसके लिए वह repository से updateinfo.xml पढ़ता है, जहाँ प्रत्येक advisory उन packages की सूची देती है जिन्हें वह ठीक करती है। जब यह metadata गायब या पुराना होता है, तो security filter किसी भी चीज़ से मेल नहीं खाता जबकि सामान्य updates अभी भी लंबित होते हैं, जिससे बिल्कुल वही लाइन दिखाई देती है। CentOS Stream पर यह अपेक्षित है, जो कोई errata प्रकाशित नहीं करता है। Rocky या AlmaLinux पर, dnf updateinfo list --security की तुलना dnf check-update से करें और जाँचें कि आपका metadata वर्तमान है या नहीं।

क्या kernel update के बाद dnf-automatic मेरे सर्वर को reboot करेगा?

नहीं, जब तक आप ऐसा करने के लिए नहीं कहते। reboot विकल्प डिफ़ॉल्ट रूप से never पर होता है। reboot = when-needed सेट करें और एक run केवल तब reboot करेगा जब dnf needs-restarting -r के पीछे की जाँच यह पाए कि kernel या glibc जैसा कोई core package boot के बाद बदला गया है। reboot = when-changed किसी भी लागू update के बाद reboot करता है। दोनों reboot_command का उपयोग करते हैं, जो डिफ़ॉल्ट रूप से shutdown -r +5 पर होता है और logged-in users को एक चेतावनी संदेश देता है।

मैं dnf-automatic के चलने का समय कैसे बदलूँ?

sudo systemctl edit dnf-automatic.timer चलाएँ और एक [Timer] section जोड़ें जिसमें एक खाली OnCalendar= लाइन हो, जिसके बाद आपका schedule हो, उदाहरण के लिए OnCalendar=*-*-* 03:30। खाली लाइन आवश्यक है क्योंकि OnCalendar जमा (accumulate) होता है, इसलिए इसे छोड़ देने पर 06:00 वाला डिफ़ॉल्ट run बना रहता है और एक दूसरा run जुड़ जाता है। systemctl list-timers dnf-automatic.timer के साथ सत्यापित करें और NEXT कॉलम पढ़ें।

क्या मुझे अभी भी उस सर्वर की जाँच करने की आवश्यकता है जो खुद को patch करता है?

हाँ। dnf-automatic केवल packages install करता है और वहीं रुक जाता है। यह daemons को restart नहीं करता है, और यह आपको कुछ भी रिपोर्ट नहीं करेगा जब तक कि emit_via में कोई ऐसा emitter न हो जिसे आप वास्तव में पढ़ते हैं। कम से कम emit_via को stdio पर सेट करें, send_error_messages को चालू करें ताकि विफलताएं भी रिपोर्ट हों, और patch window के बाद dnf needs-restarting -s चलाएँ ताकि उन services का पता चल सके जो अभी भी पुराना code चला रही हैं।