آموزش فعال‌سازی مخازن 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 مواجه می‌شود. هیچ‌چیز خراب نیست و هیچ mirrorای هم از دسترس خارج نشده است. توزیع پایه به‌عمد مجموعه کوچکی از بسته‌ها را ارائه می‌دهد، CRB موجود است اما غیرفعال شده، و EPEL یک مخزن اجتماعی جداگانه است که باید خودتان آن را اضافه کنید.

در Ubuntu، همان بسته در universe قرار دارد و universe تقریباً در تمام imageهای ابری فعال است، بنابراین این پرسش هرگز مطرح نمی‌شود. خانواده Red Hat بسته‌های خود را به شکل متفاوتی تقسیم‌بندی کرده و به‌صورت پیش‌فرض تعداد کمتری را ارائه می‌دهد. راه‌حل شامل سه دستور است. باقی این راهنما بخشی است که در هفته اول کسی به شما نمی‌گوید: این مخازن چه تعهداتی دارند، چه تعهداتی ندارند، و چگونه از تسلط بی‌سروصدای یک مخزن شخص ثالث بر سیستم پایه خود جلوگیری کنید.

نحوه بررسی این دستورات. کانتینرهای تست دستورات ما فقط Ubuntu را اجرا می‌کنند، بنابراین دستورات dnf در ادامه، روی ماشین‌های تست خودمان اجرا نشده‌اند. این دستورات از مستندات Rocky Linux و AlmaLinux پیروی می‌کنند. هر مرحله خروجی‌ای که باید ببینید را نام می‌برد، بنابراین به‌جای کپی کردن کل بلوک به‌صورت یکجا، هر مرحله را روی سرور خود بررسی کنید.

BaseOS، AppStream و CRB چه هستند؟

BaseOS خودِ سیستم‌عامل است: هسته (kernel)، glibc، systemd و ابزارهای پایه محیط کاربری. نسخه‌های موجود در این بخش برای کل طول عمر آن نسخهٔ اصلی (major release) ثابت می‌مانند و اصلاحات امنیتی به این نسخه‌های ثابت‌شده بک‌پورت (backport) می‌شوند. اگر شماره نسخه یک بسته در BaseOS قدیمی به نظر می‌رسد، به این معنا نیست که وصله نشده است؛ بلکه یک نسخه قدیمیِ وصله‌شده است که هدف اصلی توزیع‌های سازمانی (enterprise) همین است.

AppStream شامل مواردی است که روی سیستم اجرا می‌کنید: وب‌سرورها، پایگاه‌های داده، محیط‌های اجرای زبان‌های برنامه‌نویسی، ویرایشگرها و عامل‌های مانیتورینگ. در نسخه 8، بخش بزرگی از AppStream به صورت ماژول‌هایی با استریم‌های جایگزین ارائه می‌شد، بنابراین dnf module list اهمیت داشت و شما برای مثال، یک استریم خاص از PHP را انتخاب می‌کردید. در نسخه 9، تقریباً تمام قابلیت‌های ماژولار حذف شدند، بنابراین در Rocky 9 و Alma 9 معمولاً یک نسخه از هر چیز دریافت می‌کنید و نیازی به فعال‌سازی ماژول پیش از نصب نیست.

Extras به‌صورت پیش‌فرض فعال است و حجم بسیار کمی دارد. این مخزن عمدتاً شامل بسته‌های انتشار برای سایر مخازن است که epel-release نیز از همین طریق تأمین می‌شود. به همین دلیل است که برای نصب EPEL روی Rocky یا Alma هرگز نیازی به اعتماد به URLهای تصادفی ندارید.

CRB مخزن CodeReady Builder است که در نسخه 8 با نام PowerTools شناخته می‌شد. این مخزن بخش توسعه توزیع را در بر می‌گیرد: هدرهای توسعه، کتابخانه‌های استاتیک، و ابزارهای تست و مستنداتی که بسته‌ها در زمان build به آن‌ها نیاز دارند. این مخزن در mirror موجود است اما به‌صورت پیش‌فرض غیرفعال است. در محصول اختصاصی Red Hat، همین محتوا با نام CodeReady Linux Builder ارائه می‌شود که همراه با اشتراک است، اما Red Hat اعلام کرده که تحت پوشش پشتیبانی قرار ندارد. Rocky و Alma هم محتوا و هم وضعیت غیرفعال بودن پیش‌فرض آن را به ارث برده‌اند.

برای خوانندگانی که از Debian یا Ubuntu می‌آیند: main بسته‌های زمان اجرا (runtime) و هدرهای -dev را در یک آرشیو ترکیب می‌کند، بنابراین مخزنی به نام CRB برای فعال‌سازی وجود ندارد. نزدیک‌ترین معادل برای EPEL، مخزن universe است که توسط جامعه کاربری نگهداری می‌شود و هیچ تعهد پشتیبانی از سوی فروشنده ندارد.

EPEL چیست و چه کسی از آن پشتیبانی می‌کند

عبارت EPEL مخفف Extra Packages for Enterprise Linux است. این یک پروژه از Fedora محسوب می‌شود: بسته‌هایی که در Fedora وجود دارند، برای نسخهٔ فعلی enterprise بازسازی شده و توسط گروه ویژه (SIG) مربوط به EPEL نگهداری می‌شوند؛ اعضای این گروه عمدتاً داوطلبان جامعهٔ Fedora هستند. Red Hat زیرساخت‌های ساخت و mirror را میزبانی می‌کند و برخی از مهندسان Red Hat نیز در نگهداری بسته‌ها مشارکت دارند. رابطه در همین نقطه به پایان می‌رسد. EPEL یک محصول Red Hat نیست. هیچ قرارداد پشتیبانی یا SLA (توافق‌نامه سطح خدمات) برای بسته‌های EPEL، چه روی RHEL و چه روی توزیع‌های بازسازی‌شده (rebuild)، وجود ندارد.

یک سیاست باعث می‌شود فعال‌سازی EPEL به‌طور کلی ایمن باشد: یک بستهٔ EPEL هرگز نباید جایگزین بسته‌ای از توزیع پایه شود. اگر AppStream نسخهٔ nginx را ارائه دهد، EPEL آن را ارائه نخواهد کرد. این قانون توسط افرادی که بسته‌های EPEL را بازبینی می‌کنند اعمال می‌شود، بنابراین این یک تضمین صرفاً در مورد EPEL است. این قانون شما را در برابر سایر مواردی که بعداً اضافه می‌کنید، محافظت نمی‌کند.

طول عمر تضمین‌شده نیز با توزیع پایه متفاوت است و این همان نکته‌ای است که در سال سوم مشکل‌ساز می‌شود. نسخهٔ بسته‌های BaseOS برای کل طول عمر 10 سالهٔ نسخهٔ اصلی (major release) ثابت می‌ماند. یک نگهداری‌کنندهٔ EPEL به بازهٔ زمانی بسیار کوتاه‌تری متعهد است: حداقل یک نسخهٔ فرعی (minor release) از RHEL یا 13 ماه، هر کدام که کوتاه‌تر باشد. در عمل، اکثر بسته‌ها بسیار طولانی‌تر از این مدت نگهداری می‌شوند. برخی از بسته‌ها زمانی که نگهداری‌کننده فعالیت خود را متوقف می‌کند بازنشسته می‌شوند و برخی دیگر در میانهٔ عمر توزیع شما به نسخهٔ اصلی جدیدتری ارتقا می‌یابند، زیرا EPEL از Fedora پیروی می‌کند. بنابراین یک dnf upgrade معمولی می‌تواند نسخهٔ اصلی جدیدی از یک ابزار EPEL را روی سیستمی که تصور می‌کردید پایدار است به شما تحویل دهد، و بسته‌ای که به آن وابسته‌اید ممکن است بدون هیچ اطلاع‌رسانی که به دست شما برسد، دریافت به‌روزرسانی را متوقف کند. همچنین نسخهٔ جدید در سرویسی که از قبل در حال اجراست اعمال نمی‌شود، بنابراین needs-restarting ابزاری است که پس از پایان تراکنش، به شما می‌گوید کدام پردازش‌ها هنوز از فایل باینری قدیمی استفاده می‌کنند.

یک پیامد دیگر که پیش از فعال‌سازی باید بدانید: EPEL بر اساس جدیدترین نسخهٔ فرعی RHEL ساخته می‌شود. اگر سروری را روی یک نسخهٔ فرعی قدیمی‌تر نگه داشته‌اید و از یک mirror ثابت یا مخزن point release فروشنده استفاده می‌کنید، ممکن است یک بستهٔ EPEL به کتابخانهٔ پایه‌ای جدیدتر از آنچه در اختیار دارید نیاز داشته باشد. dnf این مورد را به عنوان وابستگی گمشده گزارش می‌کند و در حالی که مشکل در واقع ناشی از اختلاف نسخه (version skew) است، ممکن است به نظر یک مشکل در mirror برسد.

فعال‌سازی 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 به بعد به‌صورت پیش‌فرض فعال است (تغییر در سپتامبر 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 بررسی کنید که آیا آن را در اختیار دارید یا خیر، زیرا این ابزار در تمام شاخه‌های هر بازسازی (rebuild) موجود نیست.

برای اثبات اینکه EPEL فقط فهرست نشده و واقعاً در دسترس است، بسته‌ای را از آن درخواست کنید که فقط در این مخزن وجود دارد:

dnf repoquery --repo=epel htop

این دستور نام بسته، نسخه و معماری آن را چاپ می‌کند. سکوت به این معنی است که مخزن فعال است اما چیزی برنمی‌گرداند، که معمولاً یک مشکل در mirror یا متادیتا است و نه یک مشکل پیکربندی؛ بنابراین در مرحله بعد sudo dnf clean all && sudo dnf makecache را امتحان کنید.

چرا dnf خطای no such command: 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 کار می‌کند زیرا آن بسته، قابلیت مجازی (virtual capability) مربوطه را اعلام می‌کند:

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 عرضه می‌شود، در مرحلهٔ حل وابستگی‌ها (dependency resolution) با شکست مواجه می‌شود و پیام خطا، نام آن کتابخانه و بسته‌ای که به آن نیاز دارد را ذکر می‌کند:

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 در نسخه 10، CRB را به‌طور پیش‌فرض فعال کرد تا از بروز آن جلوگیری کند. استفاده از --enablerepo=crb نیز به عنوان یک فلگ موقت برای یک نصب خاص کارساز است، اما اگر به‌طور کلی از EPEL استفاده می‌کنید، CRB را برای همیشه فعال نگه دارید؛ زیرا به‌روزرسانی بعدی EPEL ممکن است بدون هشدار قبلی، وابستگی جدیدی به CRB ایجاد کند.

این بسته از کدام مخزن (repository) آمده است؟

پس از چند هفته کار با چهار مخزن فعال، پرسش مفید دیگر این نیست که چه چیزی نصب شده است، بلکه این است که آن بسته از کجا آمده است.

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 ارزش آن را دارد که در ماه اول در یک تب جداگانه باز بماند، زیرا مفاهیم حتی زمانی که پرچم‌ها (flags) یکسان نیستند، به‌خوبی با هم مطابقت دارند.

چگونه از جایگزینی بسته‌های پایه توسط مخازن شخص ثالث جلوگیری کنم؟

تعهد EPEL بر این است که چنین کاری انجام ندهد. هیچ مخزن دیگری چنین تعهدی ندارد. مخزن یک فروشنده برای پایگاه‌داده، یک agent یا یک runtime زبان ممکن است نسخه اختصاصی خود از کتابخانه‌ای را ارائه دهد که در BaseOS نیز موجود است. در این حالت dnf آن را نصب می‌کند، زیرا قانون پیش‌فرض dnf ساده است: بالاترین نسخه برنده است، فارغ از اینکه از کجا آمده باشد.

دو کنترل بخش عمده این کار را انجام می‌دهند و هر دو در فایل مخزن تحت /etc/yum.repos.d/ قرار دارند.

priority= تعیین می‌کند که وقتی بیش از یک مخزن، بسته‌ای با نام یکسان ارائه می‌دهند، کدام‌یک برنده شود. اعداد کمتر برنده هستند و مقدار پیش‌فرض 99 است؛ بنابراین به مخازن پایه خود یک عدد کم و به هر مخزن شخص ثالث یک عدد بالا اختصاص دهید. در این صورت dnf حتی اگر نسخه شخص ثالث جدیدتر باشد، بسته پایه را انتخاب می‌کند. نسخه‌های مدرن dnf خودشان این موضوع را مدیریت می‌کنند، بنابراین بسته جداگانه yum-plugin-priorities که در دوران CentOS 7 استفاده می‌شد، دیگر بخشی از راهکار نیست.

includepkgs= گزینه فیلترینگ قوی‌تری است. excludepkgs= بسته‌های نام‌برده‌شده را از یک مخزن مسدود می‌کند که مستلزم آن است پیش‌بینی کنید آن مخزن چه چیزی ممکن است ارائه دهد. includepkgs= این رفتار را معکوس می‌کند: این مخزن فقط اجازه دارد این نام‌ها را ارائه دهد و نه هیچ چیز دیگر. برای مخزن یک فروشنده که فقط باید agent اختصاصی خودش را ارائه دهد، این کار با یک خط انجام می‌شود.

[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 در آینده عرضه می‌کند، بالاتر است. وقتی نسخه فرعی (minor release) بعدی Rocky منتشر شود، نسخه بسته شما از آن بالاتر است و به همین دلیل dnf upgrade آن را تغییر نمی‌دهد. اکنون ماشین شما ترکیبی را اجرا می‌کند که هیچ‌کس آن را تست نکرده است و این وضعیت سال‌ها به آرامی باقی می‌ماند، در حالی که شما تصور می‌کنید سیستم وصله (patch) شده است.

نشانه این مشکل این است که dnf upgrade گزارش می‌دهد کاری برای انجام دادن وجود ندارد، در حالی که sudo dnf distro-sync پیشنهاد می‌دهد لیست بلندی از بسته‌ها را به نسخه پایین‌تر (downgrade) برگردانید. distro-sync ابزار تعمیر است: این ابزار هر بسته نصب‌شده را مجبور می‌کند با آنچه مخازن فعال واقعاً ارائه می‌دهند مطابقت پیدا کند، که شامل downgradeها نیز می‌شود. ابتدا مخزن خارجی را غیرفعال کنید، سپس دستور را اجرا کنید و پیش از تأیید، لیست پیشنهادی را بخوانید. اگر RPM قدیمی دیگر در mirror موجود نباشد، تعمیر با شکست مواجه می‌شود؛ در آن نقطه، بازسازی سرور از یک image تمیز، سریع‌تر و ایمن‌تر از درگیری با حل‌کننده وابستگی‌ها (dependency solver) است.

باقی‌مانده‌های دوران ELevate نسخه رایج دیگری از این مشکل هستند. ELevate ابزار مهاجرت AlmaLinux است که بر پایه Leapp ساخته شده و برای انتقال سیستم‌های CentOS 7 یا تبدیل توزیع‌ها به یکدیگر استفاده می‌شود. مهاجرتی که با عجله انجام شده باشد، فایل‌های مخزن EL7 را در /etc/yum.repos.d/ و بسته‌های EL7 را همچنان نصب‌شده باقی می‌گذارد. آن‌ها را با rpm -qa | grep el7 پیدا کنید. هر کدام از این‌ها بسته‌ای است که هیچ مخزن فعالی نمی‌تواند آن را به‌روزرسانی کند و در اجرای بعدی Leapp، به عنوان بسته‌هایی گزارش می‌شوند که قابل نگاشت نیستند؛ این موضوع به مانعی برای ارتقا تبدیل می‌شود که باید دستی پاکسازی شود. آن‌ها را زمانی که سرور در وضعیت پایداری است پاک کنید، نه در روزی که به ارتقای اصلی بعدی نیاز دارید.

مخزن یک فروشنده (vendor repository) که بسته‌ای از AppStream را تحت‌الشعاع قرار می‌دهد، نسخه خفیف‌تری از همین بیماری است و خط includepkgs در بالا، درمان آن است. ابزارهای کانتینر معمولاً عامل این مشکل هستند، زیرا containerd.io از مخزن رسمی Docker با runc از AppStream تداخل دارد، بنابراین یکی از آن‌ها باید حذف شود. یک بار تصمیم بگیرید، استثنا را یادداشت کنید و از یک ترتیب معتبر پیروی کنید: راهنمای نصب Docker روی Rocky Linux مشخص می‌کند که ابتدا کدام بسته‌های توزیع باید حذف شوند.

ترجمه مفاهیم مخازن از 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 فراداده‌ها (metadata) را طبق زمان‌بندی خود به‌روزرسانی می‌کند و dnf makecache این کار را به‌صورت دستی و فوری انجام می‌دهد.
• دستور apt-cache policy <pkg> به dnf info <pkg> تبدیل می‌شود، به‌علاوه dnf list --showduplicates <pkg> برای مشاهده تمام نسخه‌های موجود.
• دستور apt-mark hold به dnf versionlock add تبدیل می‌شود، که از python3-dnf-plugin-versionlock استفاده می‌کند.
• قابلیت Pinning در /etc/apt/preferences.d/ به priority= در بخش مخازن تبدیل می‌شود، با این تفاوت که اولویت‌بندی اعداد در اینجا به صورت معکوس عمل می‌کند.
• دستور dpkg -S /path/to/file به rpm -qf /path/to/file تبدیل می‌شود.

به‌روزرسانی‌های خودکار بیشتر به عنوان یک مفهوم منتقل می‌شوند تا یک دستور سینتکسی، چرا که در اینجا معادل unattended-upgrades وجود ندارد. تایمر، فایل پیکربندی و بحث مربوط به نیاز به reboot در dnf-automatic در Rocky و Alma پوشش داده شده است.

فهرست مخازن را کوتاه نگه دارید

قابلیت CRB را فعال کنید، epel-release را نصب کنید و سپس اقدامات انجام‌شده و دلیل آن‌ها را در ابزار مدیریت پیکربندی یا در یک فایل متنی ساده روی همان سرور یادداشت کنید. وقتی سرور 3 سال عمر کرده و شخص دیگری مسئولیت آن را بر عهده دارد، ارزش این یادداشت بسیار فراتر از حد تصور است.

پیش از افزودن مخزن جدید، جستجو کنید. ابتدا dnf search و سپس dnf info را اجرا کنید و تنها پس از آن به فکر افزودن مخزن جدید باشید. بخش قابل‌توجهی از آنچه کاربران برای آن EPEL را فعال می‌کنند، از قبل در AppStream موجود است. مانیتورینگ سیستم واضح‌ترین مثال است، چرا که Performance Co-Pilot در مخازن پایه موجود است و به هیچ منبع شخص ثالثی نیاز ندارد. هر مخزن اضافی، یک طرف ثالث جدید است که می‌تواند در یک روز سه‌شنبه بسته‌ای برای شما ارسال کند و هر کدام از آن‌ها، ارتقای اصلی بعدی سیستم را دشوارتر می‌کنند.

اگر هنوز در حال انتخاب بین این دو توزیع هستید، بدانید که کل این ساختار در هر دو یکسان است و epel-release رفتاری کاملاً مشابه دارد. تفاوت‌های اصلی در جای دیگری نهفته است: مقایسه Rocky Linux و AlmaLinux فلسفه بازسازی (rebuild) را پوشش می‌دهد، چرا که 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 باشد. پیش از نصب بسته‌های EPEL، مخزن CRB را فعال کنید، زیرا بسیاری از آن‌ها به کتابخانه‌هایی وابسته هستند که تنها توسط CRB ارائه می‌شوند. در نسخه 8، شناسه مخزن به جای crb، برابر با powertools است.

آیا فعال‌سازی EPEL روی سرور عملیاتی (Production) امن است؟

این مخزن به‌طور گسترده استفاده می‌شود و بر اساس سیاستی بنا شده است که بسته‌های EPEL هرگز جایگزین بسته‌های توزیع پایه نمی‌شوند؛ بنابراین فعال‌سازی آن تغییری در آنچه BaseOS یا AppStream ارائه می‌دهند، ایجاد نمی‌کند. نکته مهم در مورد پشتیبانی است: EPEL یک پروژه داوطلبانه از Fedora است و هیچ توافق‌نامه سطح خدماتی (SLA) ندارد و نگهدارنده بسته تنها برای یک نسخه فرعی RHEL یا حداقل 13 ماه به آن متعهد است. با استفاده از dnf repository-packages epel list installed یک فهرست موجودی تهیه کنید و برای هر بسته EPEL که سرویس‌های مشتری‌محور به آن وابسته هستند، از dnf versionlock استفاده کنید.

چرا dnf خطای no such command: config-manager را نمایش می‌دهد؟

زیرا config-manager یک افزونه برای dnf است و نه یک دستور داخلی، و تصاویر مینیمال یا کانتینرها بدون dnf-plugins-core عرضه می‌شوند. خود پیام خطا راه‌حل را ارائه می‌دهد: sudo dnf install -y 'dnf-command(config-manager)'، که باید داخل کوتیشن قرار گیرد تا shell پرانتزها را پردازش نکند. اگر هنوز قادر به نصب چیزی نیستید، grep -rl crb /etc/yum.repos.d/ را اجرا کنید، فایلی که نام می‌برد را باز کنید و در بخش [crb]، مقدار enabled=1 را به‌صورت دستی تنظیم کنید.

تفاوت بین 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 کل مجموعه را در یک تراکنش پاک می‌کند؛ بنابراین پیش از تأیید، لیست پیشنهادی را به‌دقت مطالعه کنید.