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

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

ऑटोमॅटिक अपडेट्स सुरू करणे हे नवीन VPS सेटअपच्या पहिल्या दहा मिनिटांमधील कामाचा भाग आहे. हे काम तुम्ही non-root युजर तयार केल्यानंतर आणि फायरवॉल सेट केल्यानंतर लगेच करावे. जर फायरवॉलचे काम बाकी असेल, तर Rocky आणि AlmaLinux मध्ये firewalld आधीच उपलब्ध असते. काही कमांड्स वापरून तुम्ही SSH आणि तुमच्या साइटचा पोर्ट उघडू शकता, तसेच रीबूटनंतरही हे नियम कायम राहतील याची खात्री करू शकता.

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 ही आहे. या फाईलमध्ये तुमच्या बिल्डसाठी उपलब्ध असलेले सर्व पर्याय आणि त्यांचे डिफॉल्ट व्हॅल्यूज कमेंट्सच्या स्वरूपात दिलेले आहेत. ती एडिट करण्यापूर्वी एकदा पूर्ण वाचा, कारण तुमच्या आवृत्तीसाठी तीच अधिकृत माहिती आहे.

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

download_updates आणि apply_updates हे [commands] विभागातील घटक वर्तन ठरवतात. 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 नावाची फाईल, जिथे प्रत्येक ॲडव्हायझरीमध्ये ती दुरुस्त करणारी पॅकेजेस सूचीबद्ध असतात. AlmaLinux हे ALSA ॲडव्हायझरीज म्हणून प्रकाशित करते, तर Rocky त्यांना RLSA म्हणून प्रकाशित करते. upgrade_type = security त्या मेटाडेटावरून एक फिल्टर तयार करते आणि फक्त जुळणारी पॅकेजेस अपग्रेड करते.

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

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

No security updates needed, but 3 updates available

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

dnf updateinfo list --security
dnf check-update

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

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

Rocky बाबत आणखी एक महत्त्वाची गोष्ट लक्षात ठेवा. Rocky आपला errata रेड हॅटच्या डेटावरून स्वतःच्या पाइपलाइनद्वारे तयार करते आणि ती पाइपलाइन कधीकधी मागे पडते. सप्टेंबर 2025 मध्ये वापरकर्त्यांनी नोंदवले की Rocky 9 BaseOS updateinfo.xml डिसेंबर 2024 पासून अपडेट झालेला नाही, त्यामुळे --security मध्ये अलीकडील ॲडव्हायझरीज गहाळ होत्या आणि Rocky च्या कर्मचाऱ्यांनी ही एक ज्ञात समस्या असल्याचे मान्य केले. जर तुम्ही upgrade_type = security वर अवलंबून असाल, तर अधूनमधून ॲडव्हायझरी यादीची 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 चे मूल्य साठवले जाते, त्यामुळे जर तुम्ही रिसेट केले नाही, तर 06:00 ची मूळ वेळ तशीच राहून दुसरी वेळ त्यात जोडली जाईल आणि प्रक्रिया दिवसातून दोनदा चालेल. निकालाची खात्री करण्यासाठी systemctl list-timers dnf-automatic.timer वापरा आणि NEXT कॉलम तपासा. हेच ड्रॉप-इन नियम इतर कोणत्याही शेड्युलिंगसाठी लागू होतात, ज्याची माहिती systemd सर्व्हिस आणि टायमर युनिट्स लिहिणे मध्ये दिली आहे.

आता एक महत्त्वाची खबरदारी. हे पॅकेज आणखी तीन टायमर्स पुरवते: 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 तुमच्या सर्व्हिसेस रीस्टार्ट करत नाही

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

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 सेशनमधून करा, जेणेकरून चुकीच्या कॉन्फिगरेशनमुळे तुम्ही लॉक होणार नाही. नवीन कर्नलच्या बाबतीत केवळ रीबूटच मदत करतो, कारण चालू असलेले कर्नल जागेवर बदलता येत नाही. जर तुम्हाला एखाद्या विशिष्ट दिवशीचे अपडेट्स या दोन प्रकारांत विभागून पाहायचे असतील, तर कोणत्या अपडेट्ससाठी रीबूटची गरज आहे आणि कशासाठी फक्त सर्व्हिस रीस्टार्टची हे प्रत्येक पॅकेजसाठी आउटपुट तपासून पाहते.

कंटेनर्सचा विषय वेगळा आहे, कारण dnf-automatic फक्त होस्टची पॅकेजेस पॅच करते आणि इमेजमध्ये असलेल्या userland ला स्पर्शही करत नाही. त्यामुळे, Docker Engine on Rocky Linux or AlmaLinux चालवणाऱ्या सर्व्हरवर, प्रत्यक्ष ट्रॅफिक हाताळणाऱ्या कोडपर्यंत सुधारणा पोहोचण्यासाठी इमेजेस पुन्हा पुल करणे आणि कंटेनर्स पुन्हा तयार करणे आवश्यक असते.

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

[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 सेटिंग कायम ठेवा आणि journal वाचल्यानंतर स्वतः सर्व्हर रीबूट करा.

Rocky, AlmaLinux आणि CentOS Stream: त्यांच्यातील फरक

Rocky 9 आणि AlmaLinux 9 वर वरील सर्व गोष्टी अगदी सारख्याच आहेत, अगदी configuration path आणि unit names सुद्धा. दोन्ही वितरणे errata प्रकाशित करतात, त्यामुळे upgrade_type = security कडे फिल्टर करण्यासाठी डेटा उपलब्ध असतो. आधी नमूद केलेली जुनी Rocky errata ही त्यांच्या दैनंदिन कार्यपद्धतीत दिसणारी काही मोजकी तफावत आहे. त्यामुळे जर सर्व्हर अजून तयार केला नसेल, तर compatibility promise आणि जुन्या CPU साठीचे समर्थन, जे या दोघांना वेगळे करते याचा विचार करा.

CentOS Stream हा अपवाद आहे आणि तो महत्त्वाचा आहे. Stream repositories मध्ये updateinfo.xml नसतात, त्यामुळे security filter कधीही जुळत नाही आणि प्रत्येक run मध्ये No security updates needed असा रिपोर्ट येतो. Stream वर, upgrade_type = default वापरा आणि हे स्वीकारा की तुम्हाला सर्व updates स्वीकारणे भाग आहे. Stream हे RHEL च्या पुढे चालते, त्यामुळे Rocky किंवा AlmaLinux च्या तुलनेत Stream सर्व्हरवर settings मध्ये अधिक बदल होतात. हा फरक पॅकेजिंगमधील त्रुटी नसून, 2020 मध्ये Red Hat ने CentOS ला RHEL चे rolling preview बनवण्याचा घेतलेला निर्णय आहे, जो निर्णय Rocky Linux आणि AlmaLinux च्या अस्तित्वाचे कारण ठरला.

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

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

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

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

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

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

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

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

कोणतेही मेल येत नाहीत. एकतर email एमिटरसाठी पोर्ट 25 वर काहीही लिसन करत नाही, किंवा send_error_messages अजूनही no वर आहे आणि रिपोर्ट करण्यासारखी एकमेव गोष्ट म्हणजे एरर.

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

FAQ

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

फक्त जर तुम्ही 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 रन करा.