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

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

EPEL और CRB ऐसे दो repositories हैं जो एक नए Rocky Linux या AlmaLinux सर्वर में पहले से उपलब्ध नहीं होते हैं, यही कारण है कि एक नए सर्वर पर dnf install htop चलाने पर No match for argument: htop का उत्तर मिलता है और फिर Error: Unable to find a match: htop दिखाई देता है। कुछ भी खराब नहीं है और कोई भी mirror down नहीं है। Base distribution जानबूझकर केवल सीमित पैकेज प्रदान करता है, CRB मौजूद तो है लेकिन बंद (switched off) रहता है, और EPEL एक अलग community repository है जिसे आपको स्वयं जोड़ना पड़ता है।

Ubuntu पर वही पैकेज universe में होता है, और लगभग हर cloud image पर universe पहले से enabled रहता है, इसलिए यह प्रश्न कभी उठता ही नहीं है। Red Hat परिवार अपने पैकेजों को अलग तरह से विभाजित करता है और डिफ़ॉल्ट रूप से कम पैकेज प्रदान करता है। इसका समाधान तीन commands में है। इस गाइड का शेष भाग वह जानकारी है जो आपको पहले सप्ताह में कोई नहीं बताता: ये repositories क्या वादा करते हैं, क्या वादा नहीं करते हैं, और किसी third-party repository को आपके base system पर चुपचाप कब्जा करने से कैसे रोकें।

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

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। Version 8 पर, AppStream का अधिकांश हिस्सा alternate streams वाले modules के रूप में दिया गया था, इसलिए dnf module list महत्वपूर्ण था और आप उदाहरण के लिए, एक PHP stream चुनते थे। Version 9 ने लगभग सभी modularity को हटा दिया है, इसलिए Rocky 9 और Alma 9 पर आपको आमतौर पर किसी चीज़ का एक ही संस्करण मिलता है और उसे enable करने के लिए कोई module नहीं होता।

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

CRB का अर्थ CodeReady Builder repository है, जिसे version 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 है, जो समुदाय द्वारा संचालित है और इसमें कोई vendor support का वादा नहीं होता है।

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

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

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

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

इसे सक्षम करने से पहले एक और परिणाम जानना आवश्यक है: EPEL को नवीनतम RHEL माइनर रिलीज के आधार पर बनाया गया है। यदि आप किसी सर्वर को पुराने माइनर वर्जन पर रखते हैं, या किसी फ्रोजन मिरर या वेंडर पॉइंट रिलीज रिपॉजिटरी का उपयोग करते हैं, तो EPEL पैकेज को आपके पास मौजूद लाइब्रेरी से नई बेस लाइब्रेरी की आवश्यकता हो सकती है। dnf इसे एक गायब निर्भरता (missing dependency) के रूप में रिपोर्ट करता है, और यह मिरर की समस्या जैसा दिखता है जबकि वास्तव में यह वर्जन के असंतुलन (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 लिखता है और /etc/pki/rpm-gpg/ के अंतर्गत EPEL साइनिंग की इंस्टॉल करता है। उस फ़ाइल में 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 प्रदाता आपको देते हैं।

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 तो खींच लेता है, लेकिन 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 आता है।

यदि आप plugin install नहीं कर सकते क्योंकि जिस repository की आपको आवश्यकता है वह disabled है, तो इसके बजाय file को edit करें। पता लगाएँ कि कौन सी file में वह section है, उसे खोलें, और [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 के दौरान वह fail हो जाता है। 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 fail हो जाता है, तो इसका मतलब है कि 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 के संबंधित repositories को मिलाने से सर्वर अपग्रेड करने योग्य क्यों नहीं रहता

Rocky, Alma, CentOS Stream, Oracle Linux और RHEL एक-दूसरे के इतने करीब हैं कि इनके packages एक-दूसरे पर install हो जाते हैं, लेकिन ये इतने अलग भी हैं कि इनका परिणाम एक ऐसा सिस्टम बन जाता है जिसे कोई भी support नहीं कर सकता।

इसका मुख्य कारण version numbers हैं। CentOS Stream 9, RHEL 9 से आगे चलता है, इसलिए यदि आप किसी Rocky 9 मशीन को Stream repository से जोड़ते हैं—भले ही केवल एक बार या केवल एक package के लिए—तो आपके पास ऐसे packages आ जाएंगे जिनके versions Rocky द्वारा कभी भी जारी किए जाने वाले versions से आगे होंगे। जब अगला Rocky minor release आता है, तो उस package का version आपके version से कम होता है, इसलिए dnf upgrade उसे अपडेट नहीं करेगा। मशीन अब एक ऐसे संयोजन पर चल रही है जिसे किसी ने टेस्ट नहीं किया है, और यह वर्षों तक चुपचाप ऐसे ही बनी रहती है जबकि आप यह मान लेते हैं कि यह patched है।

इसका लक्षण यह है कि dnf upgrade कोई काम नहीं दिखाता, जबकि sudo dnf distro-sync packages की एक लंबी सूची को downgrade करने का सुझाव देता है। distro-sync मरम्मत का टूल है: यह हर installed package को enabled repositories द्वारा प्रदान किए गए packages से मेल खाने के लिए मजबूर करता है, जिसमें downgrades भी शामिल हैं। पहले बाहरी repository को disable करें, फिर इसे चलाएं, और स्वीकार करने से पहले प्रस्तावित सूची को ध्यान से पढ़ें। यदि पुराना RPM mirror पर उपलब्ध नहीं है तो मरम्मत विफल हो जाती है, और उस स्थिति में dependency solver से लड़ने के बजाय सर्वर को clean image से फिर से बनाना अधिक तेज और सुरक्षित होता है।

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

AppStream package को shadow करने वाली vendor repository इसी समस्या का हल्का रूप है, और ऊपर दी गई includepkgs लाइन इसका समाधान है। Container tooling इसका सामान्य उदाहरण है, क्योंकि Docker की अपनी repository से containerd.io, AppStream के runc के साथ conflict करता है, इसलिए उनमें से एक को हटाना ही पड़ता है। एक बार निर्णय लें, exclusion को लिख लें, और एक ज्ञात सही क्रम का पालन करें: Docker install on Rocky Linux वॉकथ्रू में बताया गया है कि पहले कौन से distribution packages हटाने हैं।

Repositories के लिए 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 के अपने archive के भीतर है और EPEL एक अलग प्रोजेक्ट है।
• apt update का कोई समकक्ष नहीं है जिसे आपको याद रखना हो। dnf अपने शेड्यूल पर metadata को रिफ्रेश करता है, और dnf makecache इसे तुरंत करने के लिए मजबूर करता है।
• apt-cache policy <pkg> का स्थान dnf info <pkg> ले लेता है, साथ ही उपलब्ध हर version को देखने के लिए dnf list --showduplicates <pkg> का उपयोग होता है।
• apt-mark hold का स्थान dnf versionlock add ले लेता है, जो python3-dnf-plugin-versionlock से आता है।
• /etc/apt/preferences.d/ में Pinning, repository सेक्शन में 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 powertools होती है, न कि crb।

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

इसका व्यापक रूप से उपयोग किया जाता है और यह इस नीति पर आधारित है कि EPEL packages कभी भी base distribution के किसी package को replace नहीं करते हैं, इसलिए इसे enable करने से BaseOS या AppStream द्वारा प्रदान की जाने वाली चीजें नहीं बदलती हैं। इसमें एक ही चेतावनी है: support। 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 में इसे powertools id के साथ PowerTools कहा जाता है, version 9 और उसके बाद के versions में इसे crb id के साथ 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 से ली गई किसी चीज़ ने किसी अन्य package को replace नहीं किया है और उसे हटाना अनिवार्य है, तो sudo dnf repository-packages epel remove एक ही transaction में पूरे set को साफ कर देता है, इसलिए पुष्टि करने से पहले प्रस्तावित सूची को ध्यान से पढ़ें।