Rocky Linux और AlmaLinux में EPEL और CRB कैसे जोड़ें

dnf आपको वांछित पैकेज क्यों नहीं दिखा पा रहा है

EPEL और CRB वे दो रिपॉजिटरी हैं जो एक नए Rocky Linux या AlmaLinux सर्वर पर पहले से उपलब्ध नहीं होती हैं, यही कारण है कि एक नए सर्वर पर dnf install htop चलाने पर No match for argument: htop का उत्तर मिलता है और फिर Error: Unable to find a match: htop दिखाई देता है। सिस्टम में कोई खराबी नहीं है और न ही कोई मिरर डाउन है। बेस डिस्ट्रीब्यूशन जानबूझकर केवल कुछ ही पैकेज प्रदान करता है, CRB सिस्टम में मौजूद तो होता है लेकिन बंद रहता है, और EPEL एक अलग कम्युनिटी रिपॉजिटरी है जिसे आपको स्वयं जोड़ना पड़ता है।

Ubuntu पर वही पैकेज universe में होता है, और लगभग हर क्लाउड इमेज पर universe पहले से सक्षम होता है, इसलिए यह समस्या वहां नहीं आती है। Red Hat परिवार अपने पैकेजों को अलग तरह से विभाजित करता है और डिफ़ॉल्ट रूप से कम पैकेज प्रदान करता है। इसका समाधान तीन कमांड्स में है। इस गाइड का शेष भाग वह जानकारी है जो आपको पहले सप्ताह में कोई नहीं बताता: ये रिपॉजिटरी क्या वादा करती हैं, क्या वादा नहीं करती हैं, और किसी थर्ड-पार्टी रिपॉजिटरी को आपके बेस सिस्टम पर अनचाहे नियंत्रण से कैसे रोकें।

इन कमांड्स की जांच कैसे की गई। हमारे कमांड टेस्ट कंटेनर केवल Ubuntu पर चलते हैं, इसलिए नीचे दी गई dnf कमांड्स हमारे अपने टेस्ट मशीनों पर निष्पादित नहीं की गई थीं। ये Rocky Linux और AlmaLinux के डॉक्यूमेंटेशन का पालन करती हैं। प्रत्येक चरण में उस आउटपुट का नाम दिया गया है जिसे आपको देखना चाहिए, इसलिए पूरे ब्लॉक को एक साथ पेस्ट करने के बजाय अपने सर्वर पर प्रत्येक कमांड की जांच करें।

BaseOS, AppStream और CRB क्या हैं?

BaseOS स्वयं ऑपरेटिंग सिस्टम है: kernel, glibc, systemd और मुख्य userland। इसके संस्करण major release के पूरे जीवनकाल के लिए स्थिर (frozen) रहते हैं, और सुरक्षा सुधारों (security fixes) को उन स्थिर संस्करणों में backport किया जाता है। BaseOS में वर्षों पुराना दिखने वाला संस्करण नंबर unpatched पैकेज नहीं होता है। यह एक patched पुराना संस्करण है, जो कि एक enterprise distribution का मुख्य उद्देश्य है।

AppStream में वे चीजें होती हैं जिन्हें आप ऊपर चलाते हैं: web servers, databases, language runtimes, editors और monitoring agents। संस्करण 8 पर, AppStream का अधिकांश हिस्सा alternate streams वाले modules के रूप में दिया गया था, इसलिए dnf module list महत्वपूर्ण था और आप उदाहरण के लिए, एक PHP stream चुनते थे। संस्करण 9 ने लगभग सभी modularity को हटा दिया है, इसलिए Rocky 9 और Alma 9 पर आपको आमतौर पर किसी चीज का एक ही संस्करण मिलता है और पहले enable करने के लिए कोई module नहीं होता है।

Extras डिफ़ॉल्ट रूप से enabled होता है और बहुत छोटा है। इसमें मुख्य रूप से अन्य repositories के लिए release packages होते हैं, जहाँ से epel-release आता है। यही कारण है कि Rocky या Alma पर EPEL इंस्टॉल करने के लिए आपको कभी भी किसी रैंडम URL पर भरोसा करने की आवश्यकता नहीं होती है।

CRB का अर्थ CodeReady Builder repository है, जिसे संस्करण 8 पर PowerTools कहा जाता था। इसमें distribution का build पक्ष होता है: development headers, static libraries, और वे test और documentation टूल्स जिनकी packages को build के समय आवश्यकता होती है। यह पहले से ही mirror पर मौजूद है और डिफ़ॉल्ट रूप से disabled है। Red Hat के अपने उत्पाद पर इसी सामग्री को CodeReady Linux Builder कहा जाता है, यह subscription के साथ आता है, और Red Hat का कहना है कि यह support के अंतर्गत नहीं आता है। Rocky और Alma दोनों ही इस सामग्री और डिफ़ॉल्ट रूप से disabled रहने की स्थिति को विरासत में प्राप्त करते हैं।

Debian या Ubuntu से आने वाले पाठकों के लिए: main runtime packages और -dev headers को एक ही archive में मिला देता है, इसलिए वहाँ enable करने के लिए कोई CRB नहीं होता है। EPEL का सबसे करीबी विकल्प universe है, जिसे समुदाय द्वारा maintain किया जाता है और इसमें कोई vendor support का वादा नहीं होता है।

EPEL क्या है और इसके पीछे कौन है

EPEL का अर्थ है Extra Packages for Enterprise Linux। यह एक Fedora प्रोजेक्ट है: इसमें वे पैकेज शामिल हैं जो Fedora में मौजूद हैं और जिन्हें वर्तमान एंटरप्राइज रिलीज के लिए फिर से बनाया गया है। इसका रखरखाव EPEL Special Interest Group द्वारा किया जाता है, जिसमें मुख्य रूप से Fedora समुदाय के स्वयंसेवक शामिल हैं। Red Hat इसके बिल्ड और मिरर इंफ्रास्ट्रक्चर को होस्ट करता है, और कुछ Red Hat इंजीनियर इसमें पैकेज का रखरखाव करते हैं। इनका संबंध यहीं तक सीमित है। EPEL कोई Red Hat उत्पाद नहीं है। EPEL पैकेज के लिए, चाहे वह RHEL पर हो या किसी अन्य रीबिल्ड पर, कोई सपोर्ट कॉन्ट्रैक्ट या SLA (service level agreement) नहीं होता है।

एक नीति EPEL को इनेबल करने के लिए सुरक्षित बनाती है: EPEL पैकेज कभी भी बेस डिस्ट्रीब्यूशन के पैकेज को प्रतिस्थापित (replace) नहीं करना चाहिए। यदि AppStream में nginx मौजूद है, तो EPEL में वह नहीं होगा। यह नियम उन लोगों द्वारा लागू किया जाता है जो EPEL पैकेजों की समीक्षा करते हैं, इसलिए यह केवल EPEL के बारे में एक वादा है। यह आपको बाद में जो कुछ भी आप जोड़ते हैं, उससे सुरक्षा नहीं देता है।

इसका लाइफटाइम प्रॉमिस भी बेस डिस्ट्रीब्यूशन से अलग है, और यही बात तीसरे वर्ष में समस्या पैदा करती है। BaseOS पैकेज का वर्जन प्रमुख रिलीज के पूरे दस वर्षों के जीवनकाल के लिए स्थिर (frozen) रहता है। एक EPEL मेंटेनर बहुत छोटी अवधि के लिए प्रतिबद्ध होता है: कम से कम एक RHEL माइनर रिलीज या 13 महीने, जो भी कम हो। व्यवहार में अधिकांश पैकेज उससे कहीं अधिक समय तक बनाए रखे जाते हैं। कुछ पैकेज तब रिटायर कर दिए जाते हैं जब मेंटेनर आगे बढ़ जाता है, और कुछ आपके डिस्ट्रो के जीवनकाल के बीच में ही नए प्रमुख वर्जन पर चले जाते हैं, क्योंकि EPEL Fedora का अनुसरण करता है। इसलिए, एक सामान्य dnf upgrade आपको उस मशीन पर एक EPEL टूल का नया प्रमुख वर्जन दे सकता है जिसे आप स्थिर मानते थे, और जिस पैकेज पर आप निर्भर हैं, वह बिना किसी सूचना के अपडेट प्राप्त करना बंद कर सकता है। एक नया वर्जन पहले से चल रही सर्विस में तुरंत प्रभावी नहीं होता है, इसलिए needs-restarting आपको बताता है कि ट्रांजेक्शन पूरा होने के बाद कौन सी प्रक्रियाएं अभी भी पुरानी बाइनरी पर चल रही हैं।

इसे इनेबल करने से पहले एक और परिणाम जानना आवश्यक है: EPEL को नवीनतम RHEL माइनर रिलीज के आधार पर बनाया जाता है। यदि आप किसी सर्वर को पुराने माइनर वर्जन पर रखते हैं, किसी फ्रोजन मिरर या वेंडर पॉइंट रिलीज रिपॉजिटरी का उपयोग करके, तो EPEL पैकेज को आपके पास मौजूद लाइब्रेरी से नई बेस लाइब्रेरी की आवश्यकता हो सकती है। dnf इसे एक मिसिंग डिपेंडेंसी के रूप में रिपोर्ट करता है, और यह मिरर की समस्या जैसा दिखता है जबकि वास्तव में यह वर्जन के असंतुलन (version skew) की समस्या होती है।

Rocky या Alma पर CRB सक्षम करें और EPEL इंस्टॉल करें

sudo dnf install -y dnf-plugins-core
sudo dnf config-manager --set-enabled crb
sudo dnf install -y epel-release
sudo dnf makecache
dnf repolist --enabled

dnf repolist --enabled को अब baseos, appstream, extras, crb और epel की सूची दिखानी चाहिए। आपको एक छोटी epel-cisco-openh264 प्रविष्टि भी दिख सकती है, जिसे epel-release जोड़ता है। यदि उस सूची से crb गायब है, तो सक्षम करने वाला चरण पूरा नहीं हुआ है, और अगला अनुभाग इसका कारण बताता है।

Rocky 8 और Alma 8 पर रिपॉजिटरी को अभी भी PowerTools कहा जाता है, इसलिए बीच वाला कमांड sudo dnf config-manager --set-enabled powertools हो जाता है। रिपॉजिटरी आईडी केस-सेंसिटिव होती हैं, और पुराने CentOS 8 दस्तावेज़ इसे बड़े अक्षरों में PowerTools लिखते हैं, जो मैच नहीं करेगा। AlmaLinux 10 पर CRB रिपॉजिटरी 10.0 संस्करण से डिफ़ॉल्ट रूप से सक्षम है (सितंबर 2025 में बदलाव किया गया), इसलिए वहां आपको केवल epel-release चरण की आवश्यकता है।

epel-release, extras से आता है, जो पहले से ही सक्षम है, इसलिए भरोसा करने के लिए कोई URL नहीं है और न ही मैन्युअल रूप से कोई की (key) इम्पोर्ट करने की आवश्यकता है। पैकेज /etc/yum.repos.d/epel.repo लिखता है और EPEL साइनिंग की को /etc/pki/rpm-gpg/ के अंतर्गत इंस्टॉल करता है। उस फ़ाइल में gpgcheck=1 की पुष्टि करें, और किसी भी ऐसे गाइड को अनदेखा करें जो आपको --nogpgcheck के साथ सिग्नेचर एरर को बायपास करने के लिए कहता है। विफल सिग्नेचर चेक का मतलब है कि पैकेज वह नहीं है जो वह होने का दावा करता है, या आपकी घड़ी गलत है।

Rocky पर, epel-release, /usr/bin/crb पर एक छोटा हेल्पर भी इंस्टॉल करता है, इसलिए sudo crb enable और crb status प्लगइन के बिना भी वही काम करते हैं। इस पर निर्भर होने से पहले command -v crb के साथ जांच लें कि क्या यह आपके पास मौजूद है, क्योंकि यह हर रीबिल्ड की हर ब्रांच पर मौजूद नहीं होता है।

यह साबित करने के लिए कि EPEL केवल सूचीबद्ध ही नहीं बल्कि पहुंच योग्य भी है, इससे एक ऐसा पैकेज मांगें जो केवल उसी में उपलब्ध हो:

dnf repoquery --repo=epel htop

यह पैकेज का नाम, संस्करण और आर्किटेक्चर प्रिंट करता है। यदि कोई आउटपुट नहीं आता है, तो इसका मतलब है कि रिपॉजिटरी सक्षम तो है लेकिन कुछ भी वापस नहीं कर रही है, जो आमतौर पर कॉन्फ़िगरेशन के बजाय मिरर या मेटाडेटा की समस्या होती है, इसलिए इसके बाद sudo dnf clean all && sudo dnf makecache आज़माएं।

dnf क्यों कहता है कि config-manager जैसा कोई command नहीं है

यह पहली समस्या है जिसका सामना लोग करते हैं, और यह बिल्कुल उन images के साथ होती है जो अधिकांश VPS providers आपको देते हैं।

No such command: config-manager. Please use /usr/bin/dnf --help
It could be a DNF plugin command, try: "dnf install 'dnf-command(config-manager)'"

config-manager एक plugin है, न कि dnf का कोई built-in subcommand। यह dnf-plugins-core में आता है, जिसे full server install तो install कर लेता है, लेकिन minimal images, cloud images और container images में इसे छोड़ दिया जाता है। dnf का अपना सुझाव इसलिए काम करता है क्योंकि package उस virtual capability को घोषित करता है:

sudo dnf install -y 'dnf-command(config-manager)'

इसे quote करें। कोष्ठक (parentheses) shell syntax हैं, इसलिए बिना quote किया हुआ version dnf error के बजाय syntax error के साथ fail हो जाएगा।

यदि आप plugin को install नहीं कर पा रहे हैं क्योंकि जिस repository की आपको आवश्यकता है वह disabled है, तो इसके बजाय file को edit करें। पता लगाएँ कि कौन सी file उस section को रखती है, उसे open करें, और [crb] के अंतर्गत enabled=1 को set करें:

grep -rl crb /etc/yum.repos.d/

यह बिल्कुल वही है जो config-manager लिखता है, इसलिए इसे manually करने से कुछ भी खोता नहीं है। dnf repolist --enabled परिणाम की पुष्टि करता है।

कुछ EPEL packages तब तक install नहीं होंगे जब तक CRB चालू न हो

दूसरी सामान्य समस्या में एक ऐसी error आती है जिसमें CRB का उल्लेख नहीं होता। यदि कोई EPEL package ऐसी library पर निर्भर है जो केवल CRB में उपलब्ध है, तो dependency resolution के दौरान वह विफल हो जाता है। error message में उस library और उसे चाहने वाले package का नाम दिखाई देता है:

Error:
 Problem: conflicting requests
  - nothing provides libexample.so.0()(64bit) needed by examplepkg-1.4-2.el9.x86_64 from epel

इसका कारण यह है कि CRB disabled है, इसलिए dnf उस एकमात्र repository को नहीं देख पा रहा है जो वह library प्रदान करती है। इन दो चीजों की क्रमानुसार जाँच करें:

dnf repolist --enabled
dnf --enablerepo=crb repoquery --whatprovides 'libexample.so.0()(64bit)'

यदि दूसरी command किसी package का नाम दिखाती है, लेकिन सामान्य install विफल रहता है, तो इसका मतलब है कि CRB बंद है। इस प्रकार की error इतनी आम है कि AlmaLinux ने version 10 में CRB को default रूप से चालू कर दिया है ताकि यह समस्या न हो। --enablerepo=crb का उपयोग एक बार के install के लिए flag के रूप में भी किया जा सकता है, लेकिन यदि आप EPEL का उपयोग करते हैं, तो CRB को स्थायी रूप से enabled रखें। ऐसा इसलिए है क्योंकि अगला EPEL update बिना किसी पूर्व चेतावनी के एक नई CRB dependency की मांग कर सकता है।

यह पैकेज किस रिपॉजिटरी से आया है?

चार रिपॉजिटरी सक्षम होने के कुछ सप्ताह बाद, सबसे महत्वपूर्ण प्रश्न यह नहीं रह जाता कि क्या इंस्टॉल है, बल्कि यह हो जाता है कि वह कहाँ से आया है।

dnf repolist --all
dnf info htop
dnf repoquery --installed --qf '%{from_repo} %{name}' | sort | uniq -c | sort -rn
dnf repository-packages epel list installed

किसी इंस्टॉल किए गए पैकेज पर dnf info चलाने से एक From repo लाइन प्रिंट होती है। dnf list installed समान जानकारी को अपने तीसरे कॉलम में @ के साथ दिखाता है, इसलिए @epel का अर्थ है कि इसे EPEL से इंस्टॉल किया गया है, और @System का अर्थ है कि dnf को नहीं पता कि यह कहाँ से आया है, जिसका आमतौर पर मतलब है कि किसी ने डाउनलोड की गई फाइल पर rpm -i चलाया है। repoquery लाइन प्रति रिपॉजिटरी एक गणना देती है, जो यह पता लगाने का सबसे तेज़ तरीका है कि आपके द्वारा विरासत में मिले सर्वर में ऐसी रिपॉजिटरी से चालीस पैकेज हैं जिसके बारे में आपने कभी नहीं सुना है। अंतिम कमांड ठीक वही सूचीबद्ध करती है जो एक रिपॉजिटरी ने आपको दिया है, और उस रिपॉजिटरी को हटाने का निर्णय लेने से पहले आपको उस इन्वेंट्री की आवश्यकता होती है।

यहाँ apt की आदत apt-cache policy <package> है, और dnf और apt कमांड के समकक्ष को पहले महीने के लिए दूसरे टैब में खुला रखना उपयोगी है, क्योंकि फ्लैग्स अलग होने पर भी अवधारणाएं स्पष्ट रूप से मेल खाती हैं।

मैं किसी थर्ड-पार्टी रिपॉजिटरी को बेस पैकेज बदलने से कैसे रोकूँ?

EPEL ऐसा न करने का वादा करता है। कोई अन्य रिपॉजिटरी ऐसा नहीं करती है। किसी डेटाबेस, एजेंट या लैंग्वेज रनटाइम के लिए वेंडर रिपॉजिटरी किसी ऐसी लाइब्रेरी का अपना बिल्ड शिप कर सकती है जिसे BaseOS भी प्रदान करता है, और dnf उसे इंस्टॉल कर देगा, क्योंकि dnf का डिफ़ॉल्ट नियम सरल है: जहाँ से भी आए, उच्चतम वर्ज़न जीतता है।

दो कंट्रोल्स अधिकांश काम करते हैं, और दोनों /etc/yum.repos.d/ के अंतर्गत रिपॉजिटरी फ़ाइल में रहते हैं।

priority= यह तय करता है कि जब एक से अधिक रिपॉजिटरी में एक ही पैकेज का नाम हो, तो कौन सी रिपॉजिटरी जीतेगी। कम संख्या वाले जीतते हैं और डिफ़ॉल्ट 99 है, इसलिए अपनी बेस रिपॉजिटरी को कम संख्या दें और किसी भी थर्ड-पार्टी रिपॉजिटरी को उच्च संख्या दें। dnf तब बेस पैकेज को ही लेता है, भले ही थर्ड-पार्टी वर्ज़न नया हो। आधुनिक dnf इसे स्वयं संभालता है, इसलिए CentOS 7 युग का अलग yum-plugin-priorities पैकेज अब समाधान का हिस्सा नहीं है।

includepkgs= फ़िल्टर विकल्पों में से अधिक शक्तिशाली है। excludepkgs= रिपॉजिटरी से नामित पैकेजों को ब्लॉक करता है, जिसके लिए आपको यह अनुमान लगाने की आवश्यकता होती है कि वह क्या शिप कर सकता है। includepkgs= इसे उलट देता है: यह रिपॉजिटरी केवल इन नामों को प्रदान कर सकती है और कुछ नहीं। एक वेंडर रिपॉजिटरी जिसे केवल अपना एजेंट ही देना चाहिए, उसके लिए यह एक लाइन का काम है।

[vendor-tools]
name=Vendor tools for EL9
baseurl=https://packages.example.com/el9/x86_64/
enabled=1
gpgcheck=1
gpgkey=https://packages.example.com/RPM-GPG-KEY-vendor
priority=90
includepkgs=vendor-agent,vendor-agent-plugins

वर्ज़न 8 पर जानने के लिए एक और सेटिंग है। जब कोई AppStream मॉड्यूल समान नाम प्रदान करता है, तो थर्ड-पार्टी रिपॉजिटरी के पैकेज को छिपाया जा सकता है, और उस रिपॉजिटरी के सेक्शन में module_hotfixes=1 dnf को इसे फ़िल्टर करना बंद करने के लिए कहता है। यदि कोई पैकेज dnf repoquery को दिखाई देता है लेकिन 8 बॉक्स पर इंस्टॉल नहीं होता है, तो आमतौर पर यही कारण होता है। वर्ज़न 9 ने लगभग सभी मॉड्यूल हटा दिए हैं, इसलिए यह वहां शायद ही कभी दिखाई देता है।

किसी एक पैकेज को एक वर्ज़न पर पिन करने के लिए, python3-dnf-plugin-versionlock इंस्टॉल करें और sudo dnf versionlock add <package> का उपयोग करें। यह apt-mark hold के बराबर है। एक उलटफेर पर ध्यान दें जो Debian से आने वाले लोगों को भ्रमित करता है: apt में उच्च Pin-Priority जीतता है, dnf में कम priority जीतता है।

RHEL के आस-पास के रिपॉजिटरी को मिलाने से सर्वर अपग्रेड के अयोग्य क्यों हो जाता है

Rocky, Alma, CentOS Stream, Oracle Linux और RHEL एक-दूसरे के इतने करीब हैं कि इनके पैकेज एक-दूसरे पर इंस्टॉल हो जाते हैं, लेकिन ये इतने अलग भी हैं कि इनका परिणाम एक ऐसा सिस्टम बन जाता है जिसे कोई भी सपोर्ट नहीं कर सकता। वे इतने करीब क्यों हैं, और विशेष रूप से Stream अब RHEL के बगल में बैठने के बजाय उससे आगे क्यों है, यह Red Hat Linux के Fedora और RHEL में विभाजित होने और CentOS का क्या हुआ, इसकी कहानी है।

इसका कारण वर्ज़न नंबर हैं। CentOS Stream 9, RHEL 9 से आगे चलता है, इसलिए एक Rocky 9 बॉक्स को Stream रिपॉजिटरी की ओर इंगित करना, एक बार के लिए या एक पैकेज के लिए भी, आपको ऐसे पैकेज दे देता है जिनके वर्ज़न Rocky द्वारा कभी भी जारी किए जाने वाले किसी भी वर्ज़न से आगे होते हैं। जब अगला Rocky माइनर रिलीज़ आता है, तो उस पैकेज का उसका वर्ज़न आपके वर्ज़न से कम होता है, इसलिए dnf upgrade उसे नहीं छुएगा। मशीन अब एक ऐसे संयोजन पर चल रही है जिसका किसी ने परीक्षण नहीं किया है, और यह वर्षों तक चुपचाप ऐसा ही रहता है जबकि आप मान लेते हैं कि यह पैच किया गया है।

इसका लक्षण यह है कि dnf upgrade यह रिपोर्ट करता है कि करने के लिए कुछ नहीं है, जबकि sudo dnf distro-sync पैकेजों की एक लंबी सूची को डाउनग्रेड करने का प्रस्ताव देता है। distro-sync मरम्मत का टूल है: यह हर इंस्टॉल किए गए पैकेज को सक्षम रिपॉजिटरी द्वारा प्रदान किए गए पैकेज से मेल खाने के लिए मजबूर करता है, जिसमें डाउनग्रेड भी शामिल हैं। पहले बाहरी रिपॉजिटरी को अक्षम करें, फिर इसे चलाएं, और स्वीकार करने से पहले प्रस्तावित सूची को पढ़ें। मरम्मत तब विफल हो जाती है जब पुराना RPM मिरर पर नहीं होता है, और उस बिंदु पर सर्वर को एक साफ इमेज से फिर से बनाना, डिपेंडेंसी सॉल्वर से लड़ने की तुलना में तेज़ और सुरक्षित होता है।

ELevate युग के अवशेष इस समस्या का दूसरा सामान्य रूप हैं। ELevate, Leapp पर आधारित AlmaLinux माइग्रेशन टूल है, जिसका उपयोग CentOS 7 बॉक्स को आगे बढ़ाने या रीबिल्ड के बीच बदलने के लिए किया जाता है। एक जल्दबाजी में किया गया माइग्रेशन /etc/yum.repos.d/ में EL7 रिपॉजिटरी फाइलें और अभी भी इंस्टॉल किए गए EL7 पैकेज छोड़ देता है। उन्हें rpm -qa | grep el7 के साथ खोजें। प्रत्येक एक ऐसा पैकेज है जिसे कोई भी सक्षम रिपॉजिटरी कभी अपडेट नहीं कर सकती है, और बाद में Leapp रन उन्हें ऐसे पैकेज के रूप में रिपोर्ट करता है जिन्हें वह मैप नहीं कर सकता है, जो एक अपग्रेड ब्लॉकर बन जाता है जिसे आप हाथ से साफ करते हैं। उन्हें तब साफ करें जब सर्वर शांत हो, न कि उस दिन जब आपको अगले बड़े अपग्रेड की आवश्यकता हो।

AppStream पैकेज को शैडो करने वाली वेंडर रिपॉजिटरी उसी बीमारी का हल्का रूप है, और ऊपर दी गई includepkgs लाइन इसका इलाज है। कंटेनर टूलिंग इसका सामान्य मामला है, क्योंकि Docker की अपनी रिपॉजिटरी से containerd.io, AppStream से runc के साथ संघर्ष करता है, इसलिए उनमें से एक को जाना होगा। एक बार निर्णय लें, बहिष्करण (exclusion) को लिखें, और एक ज्ञात अच्छी प्रक्रिया का पालन करें: Rocky Linux पर Docker इंस्टॉल वॉकथ्रू में बताया गया है कि पहले कौन से डिस्ट्रीब्यूशन पैकेज हटाने हैं।

apt से dnf में रिपॉजिटरी का अनुवाद

• /etc/apt/sources.list.d/*.sources का स्थान /etc/yum.repos.d/*.repo ले लेता है, जहाँ एक फाइल में कई [sections] हो सकते हैं, जिनमें से प्रत्येक की अपनी id होती है।
• add-apt-repository universe का स्थान dnf install epel-release ले लेता है, अंतर यह है कि universe अभी भी Ubuntu के अपने आर्काइव के भीतर है और EPEL एक अलग प्रोजेक्ट है।
• apt update का कोई समकक्ष नहीं है जिसे आपको याद रखना हो। dnf अपने शेड्यूल पर मेटाडेटा रिफ्रेश करता है, और dnf makecache इसे अभी करने के लिए बाध्य करता है।
• apt-cache policy <pkg> का स्थान dnf info <pkg> ले लेता है, साथ ही उपलब्ध प्रत्येक वर्ज़न को देखने के लिए dnf list --showduplicates <pkg> का उपयोग होता है।
• apt-mark hold का स्थान dnf versionlock add ले लेता है, जो python3-dnf-plugin-versionlock से आता है।
• /etc/apt/preferences.d/ में पिनिंग, रिपॉजिटरी सेक्शन में priority= बन जाती है, जिसमें नंबर विपरीत दिशा में चलते हैं।
• dpkg -S /path/to/file का स्थान rpm -qf /path/to/file ले लेता है।

स्वचालित अपडेट (automatic updates) सिंटैक्स के बजाय एक विचार के रूप में स्थानांतरित होते हैं, क्योंकि यहाँ कोई unattended-upgrades नहीं है। टाइमर, कॉन्फ़िगरेशन फाइल और रीबूट करने के प्रश्न को Rocky और Alma पर dnf-automatic में कवर किया गया है।

रिपॉजिटरी सूची को छोटा रखें

CRB को सक्षम करें, epel-release इंस्टॉल करें, और फिर आपने जो किया और क्यों किया, उसे अपने कॉन्फ़िगरेशन प्रबंधन में या सर्वर पर एक साधारण फ़ाइल में लिख लें। जब सर्वर तीन साल पुराना हो जाता है और कोई और उसे संभाल रहा होता है, तो वह नोट बहुत कीमती साबित होता है।

कोई भी रिपॉजिटरी जोड़ने से पहले खोजें। dnf search चलाएं, फिर dnf info चलाएं, और उसके बाद ही किसी नई रिपॉजिटरी पर विचार करें। लोग जिस काम के लिए EPEL को सक्षम करते हैं, उसका एक बड़ा हिस्सा पहले से ही AppStream में मौजूद होता है। सिस्टम मॉनिटरिंग इसका सबसे स्पष्ट उदाहरण है, क्योंकि Performance Co-Pilot बेस रिपॉजिटरी में ही उपलब्ध है और इसके लिए किसी तीसरे पक्ष की आवश्यकता नहीं है। हर अतिरिक्त रिपॉजिटरी एक ऐसा पक्ष है जो आपको किसी भी मंगलवार को कोई पैकेज भेज सकता है, और इनमें से प्रत्येक रिपॉजिटरी अगले बड़े अपग्रेड को कठिन बना देती है।

यदि आप अभी भी इन दोनों डिस्ट्रिब्यूशन के बीच चयन कर रहे हैं, तो यह पूरा लेआउट दोनों पर समान है, और epel-release एक जैसा व्यवहार करता है। वास्तविक अंतर कहीं और हैं: Rocky Linux और AlmaLinux की तुलना रीबिल्ड दर्शन को कवर करती है, क्योंकि AlmaLinux अब लाइन-दर-लाइन रीबिल्ड के बजाय ABI (एप्लिकेशन बाइनरी इंटरफ़ेस) संगतता को लक्षित करता है।

FAQ

Rocky Linux 9 या AlmaLinux 9 पर EPEL को कैसे enable करें?

sudo dnf install -y dnf-plugins-core चलाएं, फिर sudo dnf config-manager --set-enabled crb, और उसके बाद sudo dnf install -y epel-release चलाएं। dnf repolist --enabled के साथ पुष्टि करें, जिसमें baseos, appstream, extras, crb और epel दिखाई देने चाहिए। EPEL packages install करने से पहले CRB को enable करें, क्योंकि इनमें से कई packages उन libraries पर निर्भर करते हैं जो केवल CRB प्रदान करता है। Version 8 पर repository id crb के बजाय powertools होती है।

क्या production server पर EPEL को enable करना सुरक्षित है?

यह व्यापक रूप से उपयोग किया जाता है और इस नीति पर आधारित है कि EPEL packages कभी भी base distribution के package को replace नहीं करते हैं, इसलिए इसे enable करने से BaseOS या AppStream द्वारा प्रदान की जाने वाली चीजें नहीं बदलती हैं। इसमें सावधानी यह है कि EPEL एक volunteer Fedora project है जिसका कोई service level agreement नहीं है, और एक maintainer किसी package के लिए कम से कम एक RHEL minor release या 13 महीने तक ही प्रतिबद्ध होता है। dnf repository-packages epel list installed के साथ एक inventory रखें, और किसी भी ऐसे EPEL package पर dnf versionlock का उपयोग करें जिस पर customer facing service निर्भर करती है।

dnf यह क्यों कहता है कि no such command: config-manager?

क्योंकि config-manager एक dnf plugin है, न कि built-in command, और minimal या container images में dnf-plugins-core नहीं होता है। error message में ही इसका समाधान दिया गया है: sudo dnf install -y 'dnf-command(config-manager)', जिसे quotes में रखें ताकि shell parentheses को न पढ़े। यदि आप अभी कुछ भी install नहीं कर सकते हैं, तो grep -rl crb /etc/yum.repos.d/ चलाएं, उस file को खोलें जिसका नाम यह बताता है, और [crb] section में enabled=1 को मैन्युअल रूप से set करें।

CRB और PowerTools के बीच क्या अंतर है?

ये दोनों एक ही repository के दो नाम हैं। Version 8 में इसे id powertools के साथ PowerTools कहा जाता है, version 9 और उसके बाद के versions में इसे id crb के साथ CRB कहा जाता है, और Red Hat का अपना product इस content को CodeReady Linux Builder कहता है। इसमें development headers, static libraries और build time tooling होते हैं, और यह Rocky और AlmaLinux 9 पर default रूप से disabled होता है। AlmaLinux 10 में यह 10.0 से default रूप से enabled है, इसलिए वहां enable command चलाने से पहले dnf repolist --enabled की जाँच करें।

चीजों को तोड़े बिना EPEL को वापस कैसे हटाएं?

सबसे पहले dnf repository-packages epel list installed के साथ inventory लें, क्योंकि केवल epel-release package को हटाने से EPEL से install की गई कोई भी चीज़ नहीं हटती है। वे packages disk पर बने रहते हैं, उन्हें updates मिलना बंद हो जाता है, और बिना किसी error message के उन्हें security fixes मिलना भी बंद हो जाते हैं। package-दर-package निर्णय लें, जिन्हें आप नहीं चाहते उन्हें हटाएं या replace करें, और उसके बाद ही sudo dnf remove epel-release चलाएं। यदि EPEL की किसी चीज़ ने किसी को replace नहीं किया है और उसे हटाना ही है, तो sudo dnf repository-packages epel remove एक ही transaction में पूरे set को साफ कर देता है, इसलिए पुष्टि करने से पहले प्रस्तावित सूची को ध्यान से पढ़ें।