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

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

dnf-automatic इंस्टॉल करें और इसकी कॉन्फ़िगरेशन फाइल पढ़ें

स्वचालित अपडेट (automatic updates) को सक्षम करना नए VPS पर शुरुआती दस मिनट के सेटअप का हिस्सा होना चाहिए, ठीक उसी समय जब आप एक non-root user बना लेते हैं और firewall सेट कर लेते हैं।

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

systemctl is-enabled एक फ्रेश इंस्टॉल पर disabled प्रिंट करता है, क्योंकि पैकेज इंस्टॉल करने से कोई प्रक्रिया अपने आप शुरू नहीं होती। यही सबसे आम कारण है कि जिस सर्वर में "dnf-automatic" मौजूद है, उसने कभी कोई अपडेट लागू नहीं किया।

एक विकल्प के लिए DNF का वर्ज़न मायने रखता है। reboot सेटिंग DNF 4.15 में आई थी, और Red Hat ने इसे नवंबर 2023 में advisory RHBA-2023:6645 के माध्यम से dnf-4.14.0-6.el9 में बैकपोर्ट किया था। Rocky 9 और AlmaLinux 9 इस पैकेज को रीबिल्ड करते हैं, इसलिए एक अपडेटेड सिस्टम में यह मौजूद है, जबकि 2023 से अनटच्ड सिस्टम में यह नहीं होगा।

कॉन्फ़िगरेशन फाइल /etc/dnf/automatic.conf है। इसकी डिफ़ॉल्ट कॉपी में वे सभी विकल्प सूचीबद्ध हैं जिन्हें यह बिल्ड समझता है, और वे सभी कमेंट किए गए हैं। इसे एडिट करने से पहले एक बार जरूर पढ़ें, क्योंकि वही फाइल आपके वर्ज़न के लिए सटीक जानकारी का स्रोत है।

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

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 कई मशीनों पर लोड को विभाजित करने का एक पुराना तरीका है, और अब यह काम टाइमर करता है। यह देखने के लिए कि शिप की गई सर्विस कौन से सटीक फ्लैग पास करती है, 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 इस 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 data नहीं है। 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 data से अपनी 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 जुड़ता रहता है, इसलिए उस reset के बिना आप 06:00 वाली entry को बनाए रखेंगे और एक दूसरी entry जोड़ देंगे, जिससे job दिन में दो बार चलेगा। systemctl list-timers dnf-automatic.timer के साथ परिणाम की पुष्टि करें और NEXT column को पढ़ें। यही drop-in नियम किसी भी अन्य चीज़ पर लागू होते हैं जिसे आप schedule करते हैं, जिसे systemd service और timer units लिखना में कवर किया गया है।

अब एक जाल (trap) है। यह 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 एमिटर journal में लिखता है, जो कि एक भरोसेमंद विकल्प है क्योंकि इसके लिए किसी अन्य चीज़ को install करने की आवश्यकता नहीं होती है:

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

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

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

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

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

Package install करने से डिस्क पर मौजूद फाइलें बदल जाती हैं। जो process पहले से चल रही है, वह पुरानी code को ही memory में रखती है। इसलिए, पिछले महीने शुरू हुए daemon पर patch की गई library का कोई असर नहीं पड़ता। installed और 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 की सूची देता है जिनकी फाइलें उनके शुरू होने के बाद बदल गई हैं। -r एक प्रश्न का उत्तर देता है, और नीचे दिए गए दो blocks में से एक को 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 पर समाप्त होने वाली फाइल में अपने स्वयं के package के नाम जोड़ें।

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

Service को restart करना एक छोटा कदम है और आमतौर पर यही सही तरीका होता है। SSH daemon को किसी दूसरे खुले हुए SSH session से restart करें, ताकि गलत configuration के कारण आप बाहर न हो जाएँ। नया kernel वह स्थिति है जहाँ केवल reboot ही मदद करता है, क्योंकि चल रहे kernel को उसी स्थान पर replace नहीं किया जा सकता।

क्या बॉक्स को स्वयं रीबूट होना चाहिए?

[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 के पास फ़िल्टर करने के लिए डेटा होता है।

CentOS Stream एक अपवाद है, और यह एक कठिन अपवाद है। Stream repositories में कोई updateinfo.xml नहीं होता, इसलिए security filter कभी मैच नहीं हो सकता और हर run No security updates needed रिपोर्ट करता है। Stream पर, upgrade_type = default का उपयोग करें और यह स्वीकार करें कि आप हर update ले रहे हैं। Stream, RHEL से आगे चलता है, इसलिए Rocky या AlmaLinux की तुलना में Stream box पर वह सेटिंग अधिक बदलती है।

Rocky 10 और AlmaLinux 10, DNF5 पर चले गए हैं, जो चीजों का नाम बदल देता है। अपस्ट्रीम DNF5 documentation टाइमर को 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 ने वास्तव में क्या install किया है:

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

इस विषय पर कई प्रकाशित गाइड अभी भी केवल Rocky 8 को कवर करते हैं। जब से वे लिखे गए थे, तब से option set बढ़ गया है, इसलिए किसी पुराने लेख पर भरोसा करने के बजाय अपने box पर मौजूद 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 इंस्टॉल करता है?

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

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

DNF repository से updateinfo.xml पढ़कर यह तय करता है कि क्या security update माना जाएगा, जहाँ प्रत्येक 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 के पीछे की जाँच यह पाए कि boot के बाद से kernel या glibc जैसा कोई core package बदला गया है। reboot = when-changed किसी भी applied update के बाद reboot करता है। दोनों reboot_command का उपयोग करते हैं, जो डिफ़ॉल्ट रूप से shutdown -r +5 पर होता है और logged-in users को एक चेतावनी संदेश दिखाता है।

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

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

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

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