إضافة EPEL وCRB على Rocky وAlmaLinux

لماذا لا يستطيع 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 حزمها بطريقة مختلفة، وتوفّر عدداً أقل منها افتراضياً. يتكون الإصلاح من 3 أوامر. أما بقية هذا الدليل فتتناول ما لا يخبرك به أحد في الأسبوع الأول: ما الذي يضمنه هذان المستودعان، وما الذي لا يضمنانه، وكيف تمنع مستودعاً تابعاً لجهة خارجية من السيطرة بهدوء على نظامك الأساسي.

كيف تحقّقنا من هذه الأوامر. تعمل حاويات اختبار الأوامر لدينا على Ubuntu فقط، لذلك لم تُنفَّذ أوامر dnf أدناه على أجهزة الاختبار الخاصة بنا. وهي تتبع وثائق Rocky Linux وAlmaLinux. يذكر كل إجراء المخرجات التي يفترض أن تراها، لذلك تحقّق من كل إجراء على خادمك بنفسك بدلاً من لصق الكتلة بأكملها دفعة واحدة.

ما هي BaseOS وAppStream وCRB؟

BaseOS هو نظام التشغيل نفسه: النواة وglibc وsystemd ومكونات userland الأساسية. تُجمَّد الإصدارات هنا طوال دورة الإصدار الرئيسي، وتُدمج إصلاحات الأمان في تلك الإصدارات المجمدة. رقم إصدار يبدو قديماً بسنوات في BaseOS لا يعني أن الحزمة لم تتلقَّ التصحيحات. بل يعني أنه إصدار قديم تلقى التصحيحات، وهذا هو جوهر توزيعة المؤسسات.

يحتوي AppStream على البرامج التي تشغّلها فوق النظام: خوادم الويب وقواعد البيانات وبيئات تشغيل اللغات والمحررات وعوامل المراقبة. في الإصدار 8، كان جزء كبير من AppStream يُوفَّر على شكل modules ذات streams بديلة، لذلك كان dnf module list مهماً، وكنت تختار، مثلاً، أحد streams الخاصة بـPHP. أزال الإصدار 9 معظم modularity، لذلك تحصل عادةً في Rocky 9 وAlma 9 على إصدار واحد من البرنامج، ولا تحتاج إلى تفعيل module أولاً.

يكون Extras مفعّلاً افتراضياً، وهو مستودع صغير جداً. يحتوي في الغالب على حزم release الخاصة بالمستودعات الأخرى، ومنها تأتي epel-release نفسها. ولهذا التفصيل لا تحتاج أبداً إلى الوثوق بعنوان URL عشوائي لتثبيت EPEL على Rocky أو Alma.

CRB هو مستودع CodeReady Builder، وكان يُسمّى PowerTools في الإصدار 8. يحتوي على جانب البناء في التوزيعة: ترويسات التطوير والمكتبات الساكنة وأدوات الاختبار والتوثيق التي تحتاج إليها الحزم وقت البناء. وهو موجود في mirror، لكنه معطّل افتراضياً. في منتج Red Hat نفسه، يُسمّى المحتوى ذاته CodeReady Linux Builder، ويأتي مع الاشتراك، وتذكر Red Hat أنه غير مشمول بالدعم. وترث Rocky وAlma المحتوى نفسه وحالة التعطيل الافتراضية.

بالنسبة إلى القراء القادمين من Debian أو Ubuntu: تجمع main حزم runtime وترويسات -dev في archive واحد، لذلك لا يوجد CRB لتفعيله هناك. وأقرب مقابل لـEPEL هو universe، وهو يُدار من المجتمع ولا يتضمن وعداً بدعم من المورّد.

ما هو EPEL، ومن يقف وراءه

يرمز EPEL إلى Extra Packages for Enterprise Linux. وهو مشروع تابع لـFedora: حزم موجودة في Fedora، يُعاد بناؤها للإصدار المؤسسي الحالي، وتتولى صيانتها مجموعة الاهتمامات الخاصة بـEPEL، التي تتألف في معظمها من متطوعين من مجتمع Fedora. تستضيف Red Hat بنية البناء والمرايا، ويصون بعض مهندسي Red Hat الحزم الموجودة فيه. وتنتهي العلاقة عند هذا الحد. EPEL ليس منتجاً من Red Hat. لا يوجد عقد دعم ولا اتفاقية مستوى خدمة (SLA) وراء حزمة EPEL، سواء على RHEL أو على إعادة بناء له.

تجعل إحدى السياسات تفعيل EPEL آمناً أصلاً: يجب ألا تستبدل حزمة EPEL حزمة من التوزيعة الأساسية مطلقاً. إذا كان AppStream يوفّر nginx، فلن يوفّرها EPEL. يطبّق هذه القاعدة الأشخاص الذين يراجعون حزم EPEL، ولذلك فهي ضمان يخص EPEL وحده. ولا تحميك من أي شيء آخر تضيفه لاحقاً.

ويختلف ضمان مدة الدعم أيضاً عن التوزيعة الأساسية، وهذا ما يسبب المشكلة في السنة الثالثة. تُجمَّد نسخة حزمة BaseOS طوال مدة الإصدار الرئيسي البالغة عشر سنوات. أما مشرف حزمة EPEL فيلتزم بفترة أقصر بكثير: إصدار RHEL فرعي واحد على الأقل أو 13 شهراً، أيهما أقصر. تُصان معظم الحزم عملياً مدة أطول بكثير من ذلك. لكن بعض الحزم تُحال إلى التقاعد عندما يتوقف المشرف عن صيانتها، وبعضها ينتقل إلى إصدار رئيسي جديد في منتصف عمر توزيعتك، لأن EPEL يتبع Fedora. لذلك قد يمنحك تحديث dnf upgrade اعتيادي إصداراً رئيسياً جديداً من أداة EPEL على جهاز كنت تظنه مستقراً، وقد تتوقف حزمة تعتمد عليها عن تلقي التحديثات من دون إعلان يصلك.

هناك نتيجة أخرى ينبغي أن تعرفها قبل تفعيله: يُبنى EPEL مقابل أحدث إصدار فرعي من RHEL. إذا أبقيت خادماً على إصدار فرعي أقدم، باستخدام مرآة مجمّدة أو مستودع إصدار نقطي من مورّد، فقد تتطلب حزمة EPEL مكتبة أساسية أحدث من الموجودة لديك. يعرض dnf ذلك على أنه تبعية مفقودة، وقد يبدو الأمر كأنه مشكلة في المرآة، بينما هو في الحقيقة مشكلة عدم تطابق في الإصدارات.

تفعيل CRB وتثبيت EPEL على Rocky أو Alma

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، وقد تغيّر ذلك في September 2025. لذلك لا تحتاج هناك إلا إلى تنفيذ خطوة epel-release.

يأتي epel-release من extras، وهو مفعّل مسبقاً. لذلك لا يوجد عنوان URL يتعين الوثوق به، ولا مفتاح يتعين استيراده يدوياً. تكتب الحزمة /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

هذا أول أمر يسبب مشكلة للمستخدمين، ويحدث تحديداً في الصور التي يوفّرها معظم مزوّدي 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 عبارة عن إضافة، وليست أمراً فرعياً مضمّناً في dnf. تأتي هذه الإضافة ضمن dnf-plugins-core، الذي يثبّته تثبيت الخادم الكامل، بينما تستبعده الصور المصغّرة والصور السحابية وصور الحاويات. تعمل توصية dnf نفسها لأن الحزمة تعلن عن هذه القدرة الافتراضية:

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

اكتبها بين علامتي اقتباس. الأقواس جزء من صياغة shell، لذلك تفشل النسخة غير المقتبسة بخطأ في الصياغة، وليس بخطأ من dnf.

إذا تعذّر عليك تثبيت الإضافة لأن المستودع الذي تحتاج إليه معطّل، فعدّل الملف بدلاً من ذلك. حدّد الملف الذي يحتوي على القسم، وافتحه، واضبط enabled=1 ضمن [crb]:

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

هذا هو بالضبط ما يكتبه config-manager، لذلك لا تفقد شيئاً عند إجراء التعديل يدوياً. يؤكد dnf repolist --enabled النتيجة.

لن تُثبَّت بعض حزم EPEL حتى تفعّل CRB

يؤدي الفخ الشائع الثاني إلى ظهور خطأ لا يذكر CRB مطلقاً. تفشل حزمة من EPEL ترتبط بمكتبة لا تتوفر إلا في CRB أثناء حل التبعيات، وتذكر الرسالة اسم المكتبة واسم الحزمة التي طلبتها:

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

السبب هو أن CRB معطّل، لذلك لا يستطيع dnf الوصول إلى المستودع الوحيد الذي يوفر هذه المكتبة. تحقّق من الأمرين بالترتيب:

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

إذا ذكر الأمر الثاني اسم حزمة بينما لا يزال التثبيت العادي يفشل، فهذا يعني أن CRB معطّل. هذا النوع من الأخطاء شائع بما يكفي لأن AlmaLinux فعّل CRB افتراضياً في الإصدار 10 تحديداً لمنع حدوثه. يعمل --enablerepo=crb أيضاً كخيار لمرة واحدة أثناء عملية تثبيت واحدة، لكن اترك CRB مفعّلاً دائماً إذا كنت تستخدم EPEL، لأن تحديث EPEL التالي قد يجلب تبعية جديدة من CRB من دون تحذير مسبق.

من أي مستودع جاءت هذه الحزمة؟

بعد مرور بضعة أسابيع مع تفعيل أربعة مستودعات، لا يعود السؤال المفيد هو ما الذي تم تثبيته، بل من أين جاءت الحزمة.

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 الحديث هذا الأمر بنفسه، ولذلك لم تعد حزمة yum-plugin-priorities المنفصلة من عصر CentOS 7 جزءاً من الحل.

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 بما يكفي لتثبيت حزم بعضها على بعض، لكنها تختلف بما يكفي لتصبح النتيجة نظاماً لا يستطيع أحد دعمه.

تتمثل الآلية في أرقام الإصدارات. يتقدم CentOS Stream 9 على RHEL 9، لذلك فإن توجيه جهاز Rocky 9 إلى مستودع Stream، ولو مرة واحدة أو لحزمة واحدة، يترك لديك حزم تسبق في إصداراتها أي حزم ستصدرها Rocky مستقبلاً. عند صدور الإصدار الفرعي التالي من Rocky، سيكون إصدارها من تلك الحزمة أقدم من الإصدار لديك، ولذلك لن يتعامل dnf upgrade معها. سيعمل الجهاز عندها بمزيج لم يختبره أحد، وسيبقى كذلك بهدوء لسنوات بينما تظن أنه محدّث.

يتمثل العرض في أن dnf upgrade لا يعرض أي شيء يجب تنفيذه، بينما يقترح sudo dnf distro-sync خفض إصدار قائمة طويلة من الحزم. تُستخدم distro-sync لإصلاح ذلك؛ فهي تفرض مطابقة كل حزمة مثبتة لما تعرضه المستودعات المفعّلة فعلياً، بما في ذلك خفض الإصدارات. عطّل المستودع الخارجي أولاً، ثم شغّلها، ثم اقرأ القائمة المقترحة قبل قبولها. تفشل عملية الإصلاح عندما لا يعود RPM الأقدم متاحاً على المرآة، وعندها تكون إعادة بناء الخادم من صورة نظيفة أسرع وأكثر أماناً من محاولة حل المشكلة باستخدام محلل الاعتماديات.

تُعد بقايا ELevate شكلاً شائعاً آخر من المشكلة نفسها. ELevate هي أداة ترحيل AlmaLinux المبنية على Leapp، وتُستخدم لترقية جهاز CentOS 7 أو للتحويل بين التوزيعات المعاد بناؤها. يترك الترحيل المتعجل ملفات مستودعات EL7 في /etc/yum.repos.d/، كما يترك حزم EL7 مثبتة. اعثر عليها باستخدام rpm -qa | grep el7. كل واحدة منها حزمة لا يستطيع أي مستودع مفعّل تحديثها، وسيعرضها تشغيل Leapp لاحقاً على أنها حزم لا يستطيع ربطها، فتصبح عائقاً أمام الترقية يجب إزالته يدوياً. أزلها بينما الخادم مستقر، وليس في اليوم الذي تحتاج فيه إلى الترقية الرئيسية التالية.

يُعد حجب مستودع مورّد لحزمة AppStream شكلاً أخف من المشكلة نفسها، ويمثل السطر includepkgs أعلاه علاجها. وتظهر هذه الحالة عادةً مع أدوات الحاويات، لأن containerd.io من مستودع Docker الخاص يتعارض مع runc من AppStream، ولذلك يجب إزالة أحدهما. اتخذ القرار مرة واحدة، وسجّل الاستثناء، واتبع ترتيباً معروفاً وناجحاً: يوضح دليل تثبيت Docker على Rocky Linux حزم التوزيعة التي يجب إزالتها أولاً.

ترجمة apt إلى dnf للمستودعات

• /etc/apt/sources.list.d/*.sources تصبح /etc/yum.repos.d/*.repo، حيث يمكن لملف واحد أن يحتوي على عدة [sections]، ولكل منها معرّف خاص.
• 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.

تُنقل التحديثات التلقائية بوصفها فكرة لا صيغة نحوية، إذ لا يوجد unattended-upgrades هنا. يشرح dnf-automatic على Rocky وAlma المؤقت، وملف الإعداد، ومسألة ما إذا كان ينبغي إعادة التشغيل.

اجعل قائمة المستودعات قصيرة

فعّل CRB، وثبّت epel-release، ثم سجّل ما فعلته وسبب ذلك، إما في نظام إدارة الإعدادات لديك أو في ملف عادي على الخادم. ستتضح قيمة هذه الملاحظة عندما يصبح الخادم قديماً بعد ثلاث سنوات، ويتولى إدارته شخص آخر.

ابحث قبل أن تضيف. شغّل dnf search، ثم dnf info، وبعد ذلك فقط فكّر في إضافة مستودع جديد. نسبة كبيرة مما يفعّله المستخدمون من EPEL متوفرة أصلاً في AppStream. وتُعد مراقبة النظام أوضح مثال على ذلك، لأن Performance Co-Pilot متوفر في المستودعات الأساسية ولا يحتاج إلى أي مكوّن من جهة خارجية. كل مستودع إضافي يعني جهة أخرى يمكنها توفير حزمة لك في أي وقت، وكل مستودع منها يجعل الترقية الرئيسية التالية أصعب.

إذا كنت لا تزال تختار بين التوزيعتين، فهذه البنية نفسها في كلتيهما، ويعمل epel-release بالطريقة نفسها. أما الاختلافات الفعلية فتوجد في مواضع أخرى: يتناول مقارنة Rocky Linux وAlmaLinux فلسفة إعادة البناء، لأن AlmaLinux يستهدف الآن التوافق مع ABI (واجهة التطبيق الثنائية) بدلاً من إعادة البناء المطابقة سطراً بسطر.

FAQ

كيف أفعّل EPEL على Rocky Linux 9 أو AlmaLinux 9؟

شغّل 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. فعّل CRB قبل تثبيت حزم EPEL، لأن كثيراً منها يعتمد على مكتبات لا يوفرها إلا CRB. في الإصدار 8 يكون معرّف المستودع powertools بدلاً من crb.

هل تفعيل EPEL على خادم إنتاج آمن؟

يُستخدم EPEL على نطاق واسع، وهو مبني على سياسة تمنع حزم EPEL من استبدال أي حزمة من التوزيعة الأساسية. لذلك لا يغيّر تفعيله ما توفره BaseOS أو AppStream. لكن توجد ملاحظة تتعلق بالدعم: EPEL مشروع Fedora تطوعي ولا يوفّر اتفاقية مستوى خدمة، وقد يلتزم المشرف بالحزمة لإصدار فرعي واحد من RHEL أو لمدة 13 شهراً فقط. احتفظ بجرد باستخدام dnf repository-packages epel list installed، واستخدم dnf versionlock مع أي حزمة EPEL تعتمد عليها خدمة موجهة للعملاء.

لماذا يقول dnf: no such command: config-manager؟

لأن config-manager إضافة لـ dnf وليست أمراً مضمّناً، ولأن الصور الدنيا أو صور الحاويات تُصدَر من دون dnf-plugins-core. تعرض الرسالة نفسها طريقة الإصلاح: sudo dnf install -y 'dnf-command(config-manager)'، مع وضعها بين علامتي اقتباس حتى لا تفسّر الصدفة الأقواس. إذا لم تتمكن من تثبيت أي شيء بعد، فشغّل grep -rl crb /etc/yum.repos.d/، وافتح الملف الذي يعرضه، واضبط enabled=1 يدوياً ضمن القسم [crb].

ما الفرق بين CRB وPowerTools؟

إنهما المستودع نفسه تحت اسمين مختلفين. يسمّيه الإصدار 8 PowerTools، ومعرّفه powertools، بينما يسمّيه الإصدار 9 والإصدارات الأحدث CRB، ومعرّفه crb. وتسمّي Red Hat محتواه CodeReady Linux Builder. يوفّر هذا المستودع ترويسات التطوير، والمكتبات الساكنة، وأدوات وقت البناء. وهو معطّل افتراضياً على Rocky وعلى AlmaLinux 9. يفعّله AlmaLinux 10 افتراضياً بدءاً من 10.0، لذلك تحقّق من dnf repolist --enabled قبل تشغيل أمر التفعيل هناك.

كيف أزيل EPEL مجدداً من دون التسبب في مشكلات؟

أنشئ جرداً أولاً باستخدام dnf repository-packages epel list installed، لأن إزالة الحزمة epel-release وحدها لا تزيل أي شيء ثُبّت من EPEL. تبقى هذه الحزم على القرص، وتفقد مصدر تحديثاتها، وتتوقف عن تلقي الإصلاحات الأمنية من دون ظهور خطأ يخبرك بذلك. قرّر لكل حزمة على حدة، وأزل الحزم التي لم تعد تحتاج إليها أو استبدلها، ثم شغّل sudo dnf remove epel-release فقط. إذا كانت إحدى حزم EPEL لم تستبدل أي حزمة أخرى ويجب إزالتها، فإن sudo dnf repository-packages epel remove يمسح المجموعة في معاملة واحدة. اقرأ القائمة المقترحة بعناية قبل تأكيد العملية.