Как подключить EPEL и CRB в 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 — это сама операционная система: ядро, glibc, systemd и базовые компоненты пользовательского пространства. Версии пакетов здесь заморожены на весь жизненный цикл мажорного релиза, а исправления безопасности переносятся (backport) в эти фиксированные версии. Если номер версии в BaseOS выглядит устаревшим, это не означает, что пакет не обновлен. Это пропатченная старая версия, что является ключевой особенностью корпоративного дистрибутива.

AppStream содержит программное обеспечение, которое вы запускаете поверх системы: веб-серверы, базы данных, среды выполнения языков программирования, редакторы и агенты мониторинга. В версии 8 большая часть AppStream поставлялась в виде модулей с альтернативными потоками, поэтому dnf module list имел значение, и вы выбирали, например, один конкретный поток PHP. В версии 9 от модульности практически отказались, поэтому в Rocky 9 и Alma 9 вы обычно получаете одну версию продукта без необходимости предварительно включать модуль.

Extras включен по умолчанию и содержит очень мало пакетов. В основном он хранит релизные пакеты для других репозиториев, откуда и берется сам epel-release. Именно поэтому вам никогда не нужно доверять случайным URL для установки EPEL в Rocky или Alma.

CRB — это репозиторий CodeReady Builder, который в версии 8 назывался PowerTools. Он содержит инструменты для сборки дистрибутива: заголовочные файлы для разработки, статические библиотеки, а также инструменты для тестирования и документации, необходимые пакетам на этапе сборки. Он уже присутствует на зеркалах, но по умолчанию отключен. В продуктах 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 Special Interest Group, состоящая преимущественно из добровольцев сообщества Fedora. Red Hat предоставляет инфраструктуру для сборки и зеркалирования, а некоторые инженеры Red Hat сопровождают отдельные пакеты. На этом отношения заканчиваются. EPEL не является продуктом Red Hat. Для пакетов EPEL, будь то RHEL или его пересборки, не предусмотрены контракты на поддержку или SLA (соглашения об уровне обслуживания).

Безопасность использования 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 (изменение вступило в силу в сентябре 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)'

Используйте кавычки. Скобки являются синтаксисом оболочки, поэтому вариант без кавычек приведет к синтаксической ошибке, а не к ошибке 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 версии 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 стоит держать открытой во второй вкладке в течение первого месяца, так как концепции легко сопоставляются, даже если флаги различаются.

Как предотвратить замену базового пакета пакетом из стороннего репозитория?

EPEL гарантирует отсутствие подобных конфликтов. Другие репозитории — нет. Репозиторий поставщика базы данных, агента или среды выполнения может содержать собственную сборку библиотеки, которая уже есть в BaseOS. 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, поэтому подключение репозитория Stream к системе Rocky 9 — даже однократное и даже для одного пакета — приводит к тому, что у вас остаются пакеты, версии которых выше любых, которые когда-либо выпустит Rocky. Когда выйдет следующий минорный релиз Rocky, версия этого пакета в нем окажется ниже вашей, поэтому dnf upgrade не будет его обновлять. Машина начинает работать на комбинации пакетов, которую никто не тестировал, и это состояние сохраняется годами, пока вы полагаете, что система получает обновления безопасности.

Симптомом является ситуация, когда dnf upgrade сообщает об отсутствии задач, а sudo dnf distro-sync предлагает понизить версию (downgrade) для длинного списка пакетов. Инструмент 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.
• Pinning в /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 никогда не заменяют пакеты из базового дистрибутива, поэтому его включение не меняет содержимое BaseOS или AppStream. Нюанс заключается в поддержке: EPEL — это волонтерский проект Fedora без соглашения об уровне обслуживания (SLA), а мейнтейнер берет на себя обязательства по поддержке пакета на срок от одного минорного релиза RHEL или 13 месяцев. Ведите учет установленных пакетов с помощью dnf repository-packages epel list installed и используйте dnf versionlock для любого пакета из EPEL, от которого зависит клиентский сервис.

Почему dnf сообщает, что команда 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 очистит набор за одну транзакцию, поэтому внимательно изучите предложенный список перед подтверждением.