رفع خطای پیدا نشدن بسته در Rocky Linux و 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 بسته‌های خود را به شکل متفاوتی دسته‌بندی کرده و به‌صورت پیش‌فرض تعداد کمتری را ارائه می‌دهد. راه‌حل شامل سه دستور است. باقی این راهنما بخشی است که در هفته اول کسی به شما نمی‌گوید: این مخازن چه تعهداتی دارند، چه کارهایی انجام نمی‌دهند و چگونه از تسلط بی‌سروصدای یک مخزن شخص ثالث بر سیستم پایه خود جلوگیری کنید.

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

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

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

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

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

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

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

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

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

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

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

یک پیامد دیگر که پیش از فعال‌سازی باید بدانید: EPEL بر اساس جدیدترین نسخه فرعی RHEL ساخته می‌شود. اگر سروری را روی یک نسخه فرعی قدیمی‌تر نگه داشته‌اید و از یک mirror ثابت یا مخزن نسخه خاص فروشنده استفاده می‌کنید، ممکن است یک بسته 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 یا metadata است، نه پیکربندی؛ بنابراین در مرحله بعد 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 ارائه می‌شود که در نصب کامل سرور به‌طور خودکار دریافت می‌شود، اما در ایمیج‌های minimal، ایمیج‌های ابری و ایمیج‌های container حذف شده است. پیشنهاد خودِ 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 ارائه می‌شود، در مرحلهٔ حل وابستگی‌ها (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 ایجاد کند.

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

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

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

مکانیسم اصلی، شمارهٔ نسخه‌هاست. CentOS Stream 9 جلوتر از RHEL 9 حرکت می‌کند؛ بنابراین اگر یک سیستم Rocky 9 را به مخزن Stream متصل کنید، حتی برای یک بار و حتی برای یک بسته، در نهایت بسته‌هایی خواهید داشت که نسخه‌شان از هر چیزی که Rocky در آینده ارائه می‌دهد، بالاتر است. وقتی نسخهٔ فرعی بعدی Rocky منتشر شود، نسخهٔ آن بسته در مخازن رسمی پایین‌تر از نسخهٔ نصب‌شده روی سیستم شماست، بنابراین dnf upgrade آن را به‌روزرسانی نخواهد کرد. اکنون دستگاه شما ترکیبی از بسته‌ها را اجرا می‌کند که توسط هیچ‌کس تست نشده است و این وضعیت ممکن است سال‌ها به صورت خاموش باقی بماند، در حالی که شما تصور می‌کنید سیستم وصله (patch) شده است.

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

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

سایه انداختن مخزن یک فروشنده (vendor) بر روی یک بسته از 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 در اینجا وجود ندارد. زمان‌بند (timer)، فایل پیکربندی و موضوع نیاز به راه‌اندازی مجدد (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 می‌گوید چنین دستوری وجود ندارد: config-manager؟

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

تفاوت بین CRB و PowerTools چیست؟

آن‌ها یک مخزن واحد با دو نام متفاوت هستند. در نسخه 8، این مخزن با شناسه powertools به نام PowerTools شناخته می‌شود، در حالی که در نسخه 9 و بالاتر، با شناسه crb به نام CRB شناخته می‌شود. در محصول اختصاصی Red Hat، محتوای آن CodeReady Linux Builder نام دارد. این مخزن شامل هدرهای توسعه، کتابخانه‌های استاتیک و ابزارهای زمان ساخت (build time) است و به‌طور پیش‌فرض در 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 کل مجموعه را در یک تراکنش پاکسازی می‌کند؛ بنابراین پیش از تأیید، فهرست پیشنهادی را با دقت بخوانید.