Rocky Linux आणि AlmaLinux वर dnf-automatic कसे सेट करावे

Rocky Linux आणि AlmaLinux वर dnf-automatic काय करते

Rocky Linux आणि AlmaLinux वर आपोआप (unattended) सुरक्षा अपडेट्स मिळवण्यासाठी dnf-automatic चा वापर केला जातो. हा एक छोटा प्रोग्राम आहे, जो systemd timer द्वारे सुरू होतो. तो /etc/dnf/automatic.conf फाईल वाचतो आणि त्या फाईलमध्ये परवानगी दिलेल्या गोष्टी लागू करतो. हे इन्स्टॉल करण्यासाठी फक्त एक कमांड लागते. या मार्गदर्शिकेचा उर्वरित भाग त्या सेटिंग्जवर आधारित आहे, ज्या ठरवतात की हे टूल सर्व्हरचे संरक्षण करेल की शांतपणे काहीही न करता थांबून राहील.

जर तुम्ही Debian किंवा Ubuntu कडून आला असाल, तर हे काम Ubuntu VPS वर unattended-upgrades करते तसेच आहे. एक फरक इतर सर्वांपेक्षा महत्त्वाचा आहे: पॅकेज मॅनेजरसाठी "security" या शब्दाचा अर्थ काय आहे. Ubuntu मध्ये हे एक स्वतंत्र आर्काइव्ह पॉकेट असते. RHEL फॅमिलीमध्ये, ही प्रकाशित ॲडव्हायझरीजना (advisories) जोडलेली मेटाडेटा असते आणि हा मेटाडेटा कधीकधी गहाळ किंवा जुना असू शकतो. जर तुम्ही dnf-automatic ला अशा रिपॉझिटरीकडे वळवले जिथे ॲडव्हायझरी डेटा नाही, तर ते काहीही इन्स्टॉल करणार नाही आणि तरीही यशस्वी झाल्याचा रिपोर्ट देईल.

हे मार्गदर्शन Rocky Linux 9 आणि AlmaLinux 9 साठी लिहिलेले आहे, जे ऑगस्ट 2026 पर्यंत DNF 4 (DNF हे RHEL फॅमिलीमधील पॅकेज मॅनेजर आहे) वापरतात. 10 व्या रिलीजमध्ये DNF5 चा वापर सुरू झाला आहे आणि तिथे नावे बदलली आहेत, त्यामुळे त्यांच्यासाठी शेवटी एक स्वतंत्र विभाग दिला आहे. खालील प्रत्येक कमांड तुम्हाला तुमच्या स्वतःच्या सर्व्हरवर चालवायची आहे, आणि त्यासोबत तुम्हाला अपेक्षित असलेले आउटपुट दिले आहे.

dnf-automatic इन्स्टॉल करा आणि त्यासोबत येणारी कॉन्फिगरेशन फाईल वाचा

ऑटोमॅटिक अपडेट्स सुरू करणे हे नवीन VPS वरील पहिल्या दहा मिनिटांच्या सेटअपचा भाग असावे. हे काम तुम्ही नॉन-रूट युजर आणि फायरवॉल सेट केल्यानंतर लगेच करावे.

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 मध्ये RHBA-2023:6645 या ॲडव्हायझरीद्वारे ती dnf-4.14.0-6.el9 मध्ये बॅकपोर्ट केली होती. Rocky 9 आणि AlmaLinux 9 हे पॅकेज पुन्हा बिल्ड करतात, त्यामुळे सध्याच्या सिस्टिममध्ये ही सेटिंग उपलब्ध आहे, परंतु 2023 पासून अपडेट न केलेल्या सिस्टिममध्ये ती नसेल.

कॉन्फिगरेशन फाईल /etc/dnf/automatic.conf येथे असते. या फाईलमध्ये तुमच्या बिल्डसाठी उपलब्ध असलेले सर्व पर्याय आणि त्यांचे डिफॉल्ट व्हॅल्यूज कमेंट्सच्या स्वरूपात दिलेले असतात. ती एडिट करण्यापूर्वी एकदा वाचून घ्या, कारण तुमच्या व्हर्जनसाठी नेमके कोणते पर्याय उपलब्ध आहेत, याची हीच अधिकृत माहिती आहे.

काय घडेल हे ठरवणारे दोन स्विचेस

[commands] विभागातील download_updates आणि apply_updates हे पर्याय वागणूक ठरवतात. EL9 (Rocky 9 आणि AlmaLinux 9 चा सामायिक आधार असलेले enterprise Linux 9) वर हे दोन्ही बाय-डिफॉल्ट no असतात, त्यामुळे तुम्ही इनेबल केलेले अनएडिटेड dnf-automatic फक्त काय उपलब्ध आहे हेच तुम्हाला सांगेल.

• दोन्ही no: dnf-automatic उपलब्ध अपडेट्सची माहिती देते आणि सर्व्हरवर कोणताही बदल करत नाही.
• download_updates = yes सह apply_updates = no: पॅकेजेस DNF कॅशेमध्ये डाउनलोड केली जातात. त्यानंतर इन्स्टॉलेशन जलद होते आणि नेटवर्कची गरज भासत नाही, परंतु आज रात्री काहीही बदलले जात नाही.
• दोन्ही yes सह upgrade_type = default: प्रत्येक उपलब्ध अपडेट इन्स्टॉल केले जाते, मग ते सुरक्षेशी संबंधित असो वा नसो.
• दोन्ही yes सह upgrade_type = security: फक्त सुरक्षा सल्लागारांमध्ये (security advisory) नमूद केलेली पॅकेजेस इन्स्टॉल केली जातात.

पब्लिक-फेसिंग 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 आवृत्ती क्रमांकांची तुलना करून एखादे अपडेट सुरक्षा अपडेट आहे की नाही हे ठरवत नाही. ते errata मेटाडेटा वाचते: रिपॉझिटरीमध्ये प्रकाशित केलेली updateinfo.xml नावाची फाईल, जिथे प्रत्येक सल्लागार (advisory) त्यातील त्रुटी दुरुस्त करणारी पॅकेजेस सूचीबद्ध करतो. AlmaLinux हे ALSA advisories म्हणून प्रकाशित करते, तर Rocky ते RLSA म्हणून प्रकाशित करते. upgrade_type = security त्या मेटाडेटावरून एक फिल्टर तयार करते आणि फक्त जुळणारी पॅकेजेस अपग्रेड करते.

याचे दोन परिणाम होतात आणि दोन्ही लोकांना आश्चर्यचकित करतात.

पहिले, मेटाडेटा नसल्यास कोणतेही अपडेट मिळत नाही. जर रिपॉझिटरीमध्ये updateinfo.xml नसेल, तर फिल्टर कशाशीही जुळत नाही आणि प्रक्रिया जर्नलमध्ये या ओळीसह संपते:

No security updates needed, but 3 updates available

सर्व्हर पॅच केलेला नसतो आणि कशाचीही त्रुटी नोंदवली जात नाही. स्वतः तपासा:

dnf updateinfo list --security
dnf check-update

जर dnf check-update पॅकेजेसची यादी दाखवत असेल आणि dnf updateinfo list --security काहीही प्रिंट करत नसेल, तर याचा अर्थ एकतर प्रलंबित अपडेटमध्ये कोणतीही सल्लागार माहिती नाही किंवा रिपॉझिटरीमध्ये वाचण्यासाठी कोणताही सल्लागार डेटा उपलब्ध नाही. Rocky आणि AlmaLinux दोन्ही हे प्रकाशित करतात, त्यामुळे या दोन्हीवर रिकामी यादी असणे सामान्यतः सत्य असते. CentOS Stream हे अजिबात प्रकाशित करत नाही.

दुसरे, सुरक्षा मोड म्हणजे किमान बदल नव्हे. dnf-automatic सुरक्षा फिल्टर जोडते आणि त्यानंतर सामान्य अपग्रेड मार्ग चालवते, त्यामुळे सल्लागारात नमूद केलेले पॅकेज रिपॉझिटरीमधील नवीनतम आवृत्तीवर जाते आणि त्यासोबत त्याच्या अवलंबित्व (dependencies) असलेल्या फाईल्सनाही अपडेट करते. लहान पाऊल, म्हणजे फक्त त्रुटी दुरुस्त करणारी सर्वात जुनी आवृत्ती मिळवणे, हे केवळ dnf upgrade-minimal --security हाताने चालवल्यास शक्य होते. dnf-automatic मध्ये यासाठी कोणतीही सेटिंग नाही.

Rocky बाबत आणखी एक सावधगिरी बाळगणे आवश्यक आहे. Rocky आपला errata डेटा Red Hat च्या डेटावरून स्वतःच्या पाइपलाइनद्वारे तयार करते आणि ती पाइपलाइन मागे पडली आहे. सप्टेंबर 2025 मध्ये वापरकर्त्यांनी नोंदवले की Rocky 9 BaseOS updateinfo.xml डिसेंबर 2024 पासून अपडेट झालेली नाही, त्यामुळे --security मध्ये अलीकडील advisories गहाळ होत्या आणि Rocky कर्मचाऱ्यांनी ही एक ज्ञात समस्या असल्याचे मान्य केले आहे. जर तुम्ही upgrade_type = security वर अवलंबून असाल, तर अधूनमधून advisory यादीची RLSA घोषणांशी तुलना करा. ज्या सर्व्हरवर बदलांच्या नियंत्रणापेक्षा सुरक्षा कव्हरेज अधिक महत्त्वाचे आहे, तिथे तुमच्या निवडीच्या वेळापत्रकानुसार upgrade_type = default वापरणे अधिक सुरक्षित आहे.

सिस्टमवर प्रत्यक्ष चालणारा systemd टायमर

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

list-timers कमांडने एक ओळ दिसली पाहिजे, ज्यामध्ये NEXT वेळ साधारणपणे एका दिवसाच्या अंतरावर असेल. जर टेबल रिकामे असेल, तर याचा अर्थ टायमर enable केलेला नाही आणि कोणतीही प्रक्रिया कधीही चालणार नाही.

दिलेला टायमर *-*-* 6:00 वाजता RandomizedDelaySec=60m आणि Persistent=true सह सुरू होतो. रँडम डिलेमुळे सर्व सर्व्हर्स एकाच वेळी मिररवर लोड टाकत नाहीत, तर तो तासाभराच्या कालावधीत विभागला जातो. Persistent=true चा अर्थ असा की, जर एखादे मशीन 06:00 वाजता बंद असेल, तर ते सुरू झाल्यावर टायमर ते काम लगेच पूर्ण करतो, तो दिवस वगळला जात नाही.

शेड्युल बदलण्यासाठी ड्रॉप-इन (drop-in) फाईल वापरा. मूळ युनिट फाईलमध्ये बदल करू नका, कारण पॅकेज अपडेट झाल्यावर /usr/lib/systemd/system अंतर्गत असलेल्या फाईल्स पुन्हा लिहिल्या जातात.

sudo systemctl edit dnf-automatic.timer

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

रिकामी OnCalendar= ओळ आवश्यक आहे. OnCalendar चे मूल्य साठवले जाते (accumulate होते), त्यामुळे जर तुम्ही ते रिसेट केले नाही, तर 06:00 ची एन्ट्री तशीच राहून दुसरी एन्ट्री जोडली जाईल आणि काम दिवसातून दोनदा चालेल. निकाल तपासण्यासाठी systemctl list-timers dnf-automatic.timer वापरा आणि NEXT कॉलम वाचा. हेच ड्रॉप-इन नियम इतर कोणत्याही शेड्युलिंगसाठी लागू होतात, ज्याबद्दल अधिक माहिती writing systemd service and timer units मध्ये दिली आहे.

आता एक महत्त्वाची गोष्ट लक्षात घ्या. हे पॅकेज आणखी तीन टायमर्स देते: dnf-automatic-notifyonly.timer, dnf-automatic-download.timer आणि dnf-automatic-install.timer. प्रत्येक टायमर कमांड-लाईन फ्लॅग्ससह तोच प्रोग्राम सुरू करतो आणि हे फ्लॅग्स तुमच्या कॉन्फिगरेशन फाईलमधील download_updates आणि apply_updates ला ओव्हरराईड (override) करतात. जर तुम्ही dnf-automatic.timer सोबत यापैकी एखादा टायमर enable केला, तर ते काम दोनदा आणि वेगवेगळ्या पद्धतीने चालेल, ज्यामुळे तुमची कॉन्फिगरेशन फाईल दुर्लक्षित होत असल्याचे वाटू शकते. कोणताही एक टायमर enable करा आणि तपासा:

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

एखादी गोष्ट कधी इन्स्टॉल झाली हे मला कसे कळेल?

emit_via मधील [emitters] विभाग रिपोर्टिंग नियंत्रित करतो. systemd अंतर्गत stdio एमिटर journal मध्ये लिहितो, जो एक विश्वासार्ह पर्याय आहे कारण त्यासाठी इतर कशाचीही स्थापना करण्याची आवश्यकता नसते:

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

motd एमिटर रिपोर्ट /etc/motd मध्ये लिहितो आणि त्या फाईलची सामग्री बदलतो. जर तुम्ही तिथे लॉगिन बॅनर ठेवला असेल, तर हा एमिटर वापरू नका.

email एमिटर email_host वर email_port द्वारे SMTP (simple mail transfer protocol) कनेक्शन उघडतो, जे डीफॉल्टनुसार localhost आणि 25 असते. नवीन VPS वर तिथे काहीही ऐकणारे (listening) नसते, त्यामुळे कनेक्शन नाकारले जाते आणि कोणताही ईमेल पाठवला जात नाही. त्यावर अवलंबून राहण्यापूर्वी ss -lnt | grep ':25' चालवा आणि जर आउटपुट रिकामे असेल तर relay-only Postfix सेट करा. जेव्हा मेल काम करतो, तेव्हा विषयामध्ये Updates applied on 'web01'. असे दिसते, जे system_name कडून नाव घेते.

इतर कोणत्याही गोष्टीसाठी, command एमिटर रिपोर्ट तुमच्या प्रोग्रामला स्टँडर्ड इनपुटवर देतो:

[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 वर असतो, ज्याचा अर्थ असा की अयशस्वी रनबद्दल काहीही रिपोर्ट केले जात नाही. ते सुरू करा. अशी पॅचिंग सिस्टीम जी फक्त यशच जाहीर करते, ती नसण्यापेक्षा वाईट आहे, कारण शांतता म्हणजे सर्व काही ठीक आहे असा चुकीचा अर्थ निघू शकतो.

dnf-automatic तुमच्या सर्व्हिसेस रीस्टार्ट करत नाही

पॅकेज इन्स्टॉल केल्यामुळे डिस्कवरील फाइल्स बदलतात. एखादी प्रक्रिया आधीच सुरू असेल, तर ती मेमरीमध्ये जुना कोड वापरत राहते. त्यामुळे, गेल्या महिन्यात सुरू झालेल्या डेमनसाठी पॅच केलेली लायब्ररी काहीही काम करत नाही. इन्स्टॉल केलेली आवृत्ती आणि प्रत्यक्षात कार्यरत असलेली आवृत्ती यातील या तफावतीमुळेच, केवळ इन्स्टॉलेशन पॉलिसी पुरेशी नसते, तर अनअटेंडेड पॅचिंगसाठी रीस्टार्ट पॉलिसीचीही आवश्यकता असते.

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

-s अशा systemd सर्व्हिसेसची यादी देते ज्यांच्या फाइल्स त्या सुरू झाल्यानंतर बदलल्या आहेत. -r एका प्रश्नाचे उत्तर देते आणि खालीलपैकी एक ब्लॉक प्रिंट करते:

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 हे सखोल विश्लेषण नाही. ते पॅकेजेसच्या एका निश्चित यादीची तपासणी करते: kernel, kernel-core, kernel-rt, glibc, linux-firmware, systemd, dbus, dbus-broker, dbus-daemon आणि microcode_ctl. जर यापैकी एखादे पॅकेज शेवटच्या बूटनंतर इन्स्टॉल केले असेल, तर तुम्हाला पहिले उत्तर मिळते. जेव्हा सर्व्हरवरील इतर कोणत्याही गोष्टीसाठी रीबूटची आवश्यकता असते, तेव्हा /etc/dnf/plugins/needs-restarting.d/ अंतर्गत .conf ने संपणाऱ्या फाइलमध्ये तुमच्या स्वतःच्या पॅकेजची नावे जोडा.

स्क्रिप्ट्ससाठी एक महत्त्वाची टीप: जेव्हा रीबूटची आवश्यकता असते आणि जेव्हा कमांड स्वतः अयशस्वी होते, अशा दोन्ही वेळी dnf needs-restarting -r नॉन-झिरो एक्झिट स्टेटस देते. त्यामुळे केवळ एक्झिट स्टेटसवरून फरक ओळखता येत नाही. आउटपुटमधील मजकूर वाचा.

सर्व्हिस रीस्टार्ट करणे हा लहान उपाय आहे आणि सहसा तोच योग्य असतो. SSH डेमन रीस्टार्ट करताना आधीच उघड्या असलेल्या दुसऱ्या SSH सेशनमधून करा, जेणेकरून चुकीच्या कॉन्फिगरेशनमुळे तुम्ही लॉक होणार नाही. नवीन कर्नलच्या बाबतीत मात्र केवळ रीबूटच मदत करतो, कारण कार्यरत कर्नल जागेवरच बदलता येत नाही.

बॉक्सने स्वतःहून रीबूट करावे का?

[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 वर वरील सर्व गोष्टी अगदी सारख्याच आहेत, अगदी configuration path आणि unit names सुद्धा. दोन्ही वितरणे errata प्रकाशित करतात, त्यामुळे upgrade_type = security कडे फिल्टर करण्यासाठी डेटा उपलब्ध असतो.

CentOS Stream हा अपवाद आहे आणि तो महत्त्वाचा आहे. Stream repositories मध्ये updateinfo.xml नसतात, त्यामुळे security filter कधीही जुळत नाही आणि प्रत्येक रनला No security updates needed असा रिपोर्ट मिळतो. Stream वर, upgrade_type = default वापरा आणि सर्व अपडेट्स स्वीकारले जातील हे गृहीत धरा. Stream हे RHEL च्या पुढे चालते, त्यामुळे Rocky किंवा AlmaLinux च्या तुलनेत Stream बॉक्सवर settings मध्ये अधिक बदल होतात.

Rocky 10 आणि AlmaLinux 10 मध्ये DNF5 चा वापर सुरू झाला आहे, ज्यामुळे नावांमध्ये बदल झाले आहेत. Upstream DNF5 दस्तऐवजीकरणानुसार timer चे नाव dnf5-automatic.timer असे आहे, डीफॉल्ट सेटिंग्ज /usr/share/dnf5/dnf5-plugins/automatic.conf मध्ये आहेत आणि तुमचे overrides /etc/dnf/automatic.conf मध्ये राहतील. यामध्ये download_updates डीफॉल्टनुसार 'yes' असते (आधी 'no' होते) आणि upgrade_type म्हणून distro-sync जोडले गेले आहे. Advisory query साठी dnf advisory list वापरले जाते, तर updateinfo हे alias म्हणून ठेवले आहे. 9 क्रमांकाच्या आवृत्तीसाठी लिहिलेल्या मार्गदर्शकामधून package किंवा unit names कॉपी करण्यापूर्वी तुमच्या सिस्टमवर नेमकी कोणती आवृत्ती इन्स्टॉल आहे याची खात्री करा:

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

या विषयावरील अनेक प्रकाशित मार्गदर्शक अजूनही फक्त Rocky 8 साठी आहेत. त्या लेखनानंतर पर्यायांची संख्या वाढली आहे, त्यामुळे जुन्या लेखावर विश्वास ठेवण्याऐवजी तुमच्या स्वतःच्या बॉक्सवरील commented file तपासा.

अपयशाचे प्रकार आणि दिसणारे संदेश

काहीही चालत नाही. systemctl list-timers dnf-automatic.timer एक रिकामी सारणी (table) दर्शवते आणि systemctl is-enabled dnf-automatic.timer मध्ये disabled असे दिसते. पॅकेज इन्स्टॉल झाले आहे, पण टायमर कधीच सेट झाला नाही.

जॉब चालतो पण काहीही इन्स्टॉल होत नाही. जर्नलमध्ये No security updates needed, but 3 updates available हा संदेश असतो. सुरक्षा फिल्टरला काहीही सापडले नाही, कारण एकतर प्रलंबित (pending) असलेल्या कोणत्याही पॅकेजला सल्लागार (advisory) जोडलेला नाही किंवा रिपॉझिटरीमध्ये कोणतीही सल्लागार माहिती प्रकाशित केलेली नाही.

एखादी सेटिंग दुर्लक्षित केल्यासारखी वाटते. DNF, automatic.conf मध्ये अज्ञात पर्याय असल्याचे debug लेव्हलवर नोंदवते आणि त्यानंतर डीफॉल्ट सेटिंग वापरते. त्यामुळे चुकीचे स्पेलिंग असलेली की (key) काहीही बदलत नाही आणि कोणालाही चेतावणी देत नाही. apply_update = yes लिहा आणि apply_updates हे no वरच राहते, परिणामी सर्व्हर सतत डाउनलोड करत राहतो पण काहीही इन्स्टॉल करत नाही. कोणताही बदल केल्यानंतर, फाईलवर विश्वास ठेवण्याऐवजी sudo systemctl start dnf-automatic.service चालवा आणि जर्नल वाचा.

जॉब दिवसातून दोनदा चालतो. दोन टायमर enable केलेले आहेत. systemctl list-unit-files 'dnf-automatic*' द्वारे कोणते टायमर चालू आहेत ते समजते आणि अतिरिक्त टायमर असे फ्लॅग्स वापरतात जे तुमच्या कॉन्फिगरेशन फाईलला ओव्हरराइड करतात.

कोणताही ईमेल येत नाही. एकतर email एमिटरसाठी पोर्ट 25 वर कोणतीही सेवा ऐकत (listening) नाही, किंवा send_error_messages अजूनही no वर आहे आणि केवळ त्रुटी (error) आल्यासच अहवाल देण्याचे ठरले आहे.

पॅच केलेली सेवा अजूनही जुनीच आवृत्ती दर्शवते. डिस्कवरील फाईल नवीन आहे पण मेमरीमधील प्रक्रिया जुनीच आहे. dnf needs-restarting -s मध्ये ज्या सेवा रिस्टार्ट करणे आवश्यक आहे त्यांची नावे असतात.

FAQ

dnf-automatic फक्त Rocky Linux वर सुरक्षा अपडेट्स इन्स्टॉल करते का?

केवळ जर तुम्ही upgrade_type = security हे /etc/dnf/automatic.conf मध्ये सेट केले असेल आणि तुमच्या रिपॉझिटरीजनी errata मेटाडेटा प्रकाशित केला असेल तरच हे शक्य आहे. Rocky Linux आणि AlmaLinux दोन्ही हे प्रकाशित करतात, त्यामुळे फिल्टरकडे जुळवणी करण्यासाठी advisories उपलब्ध असतात. डीफॉल्ट सेटिंग upgrade_type = default अशी असते, जी apply_updates = yes झाल्यावर सर्व उपलब्ध अपडेट्स इन्स्टॉल करते.

dnf-automatic "No security updates needed, but 3 updates available" असा रिपोर्ट का देते?

रिपॉझिटरीमधील updateinfo.xml वाचून DNF सुरक्षा अपडेट काय आहे हे ठरवते, जिथे प्रत्येक advisory मध्ये संबंधित पॅकेजेसची यादी असते. जेव्हा हा मेटाडेटा गहाळ किंवा जुना असतो, तेव्हा सुरक्षा फिल्टरला काहीही सापडत नाही, परंतु सामान्य अपडेट्स प्रलंबित असतात, ज्यामुळे हा संदेश दिसतो. CentOS Stream वर हे अपेक्षित आहे, कारण ते कोणतेही errata प्रकाशित करत नाही. Rocky किंवा AlmaLinux वर, dnf updateinfo list --security ची तुलना dnf check-update शी करा आणि तुमचा मेटाडेटा अद्ययावत असल्याची खात्री करा.

कर्नल अपडेटनंतर dnf-automatic माझा सर्व्हर रीबूट करेल का?

जोपर्यंत तुम्ही तशी सूचना देत नाही, तोपर्यंत ते रीबूट करणार नाही. reboot पर्यायाचे डीफॉल्ट मूल्य never असते. reboot = when-needed सेट केल्यास, जेव्हा dnf needs-restarting -r मधील तपासणीनुसार kernel किंवा glibc सारखे मुख्य पॅकेज बूट झाल्यानंतर बदलले गेले असेल, तेव्हाच सर्व्हर रीबूट होतो. reboot = when-changed कोणत्याही अपडेटनंतर रीबूट करते. दोन्ही पर्याय reboot_command वापरतात, जे डीफॉल्टनुसार shutdown -r +5 वर सेट असते आणि लॉग-इन असलेल्या वापरकर्त्यांना चेतावणी संदेश पाठवते.

dnf-automatic चालण्याची वेळ मी कशी बदलू?

sudo systemctl edit dnf-automatic.timer रन करा आणि एक [Timer] विभाग जोडा, ज्यामध्ये एक रिकामी OnCalendar= ओळ असेल आणि त्यानंतर तुमची वेळ (उदा. OnCalendar=*-*-* 03:30) असेल. रिकामी ओळ आवश्यक आहे कारण OnCalendar जमा होत जाते, त्यामुळे ती न दिल्यास आधीची 06:00 ची वेळ कायम राहून दुसरी वेळ जोडली जाईल. systemctl list-timers dnf-automatic.timer वापरून खात्री करा आणि NEXT कॉलम तपासा.

स्वतःहून पॅच होणाऱ्या सर्व्हरला तपासण्याची अजूनही गरज आहे का?

हो. dnf-automatic फक्त पॅकेजेस इन्स्टॉल करते आणि तिथेच थांबते. ते daemons रीस्टार्ट करत नाही आणि जोपर्यंत emit_via मध्ये तुम्ही वाचता असा emitter सेट नसेल, तोपर्यंत तुम्हाला कोणताही रिपोर्ट मिळणार नाही. किमान emit_via ला stdio वर सेट करा, अपयश कळवण्यासाठी send_error_messages सुरू करा आणि पॅच विंडो नंतर जुने कोड चालवणारे सर्व्हिसेस शोधण्यासाठी dnf needs-restarting -s रन करा.