Установка DNF на RHEL/CentOS 7: Полное техническое руководство
DNF (Dandified YUM) — это менеджер пакетов нового поколения для Linux-дистрибутивов на основе RPM, разработанный как полная замена YUM. Он обеспечивает более быстрое разрешение зависимостей благодаря библиотеке `libsolv`, меньшее потребление памяти и стабильный Python API. Хотя RHEL/CentOS 7 поставляется с YUM по умолчанию, DNF полностью устанавливается через репозиторий EPEL и может работать параллельно с YUM или в качестве его прозрачной замены на той же системе.
Это руководство охватывает полный процесс установки, объясняет архитектурные различия между YUM и DNF, рассматривает реальные граничные случаи и предоставляет готовый к использованию в продакшене справочник команд.
Почему DNF превосходит YUM на RHEL/CentOS 7
Прежде чем приступать к работе с терминалом, понимание *причин* необходимости обновления поможет вам принять обоснованное решение — особенно в давно работающей среде VPS Хостинга, где надёжность управления пакетами имеет критическое значение.
Основные архитектурные различия
YUM использует основанный на Python резолвер зависимостей, у которого задокументированы проблемы с производительностью при работе с большими деревьями зависимостей. DNF заменяет этот резолвер на `libsolv` — движок разрешения зависимостей на основе SAT-решателя, изначально разработанный компанией SUSE. Практические последствия весьма значительны:
- Скорость разрешения зависимостей: DNF разрешает сложные цепочки зависимостей за долю времени, требуемого YUM, что особенно заметно при разрешении конфликтов в больших наборах пакетов.
- Потребление памяти: YUM загружает все метаданные репозитория в память. DNF использует отложенную загрузку и более агрессивное кэширование, снижая пиковое использование RAM.
- Стабильность API: Python API YUM непредсказуемо менялся между минорными версиями. DNF предоставляет задокументированный, версионированный Python API, на который могут опираться авторы плагинов.
- Архитектура плагинов: DNF использует чистую систему плагинов на основе хуков. Плагины YUM нередко конфликтуют друг с другом из-за слабой связанности.
- История транзакций: DNF ведёт более богатую базу данных истории транзакций, делая откаты и аудит более точными.
YUM vs. DNF: сравнение функций
| Функция | YUM | DNF |
|---|
| — | — | — |
|---|
| Резолвер зависимостей | На основе Python (внутренний) | SAT-решатель `libsolv` |
|---|
| Использование памяти | Высокое (полная загрузка метаданных) | Низкое (отложенная загрузка + агрессивное кэширование) |
|---|
| Python API | Нестабильный между версиями | Стабильный, версионированный API |
|---|
| Система плагинов | Слабо связанная, склонная к конфликтам | На основе хуков, изолированная |
|---|
| Откат транзакций | Ограниченный | Полная история с поддержкой отката |
|---|
| Параллельная загрузка | Нет | Да (через `librepo`) |
|---|
| Слабые зависимости | Не поддерживаются | Поддерживаются (`Recommends`, `Suggests`) |
|---|
| Потоки модулей | Не поддерживаются | Поддерживаются (DNF 4+) |
|---|
| Статус поддержки | Конец жизненного цикла | Активно поддерживается |
|---|
| По умолчанию на RHEL/CentOS | 7 и ранее | 8 и позднее |
|---|
Предварительные требования
Перед началом убедитесь в следующем:
- Работающий экземпляр RHEL 7 или CentOS 7 (физический сервер, виртуальная машина или облачный VPS).
- Доступ root или sudo — все команды установки требуют повышенных привилегий.
- Активное подключение к интернету — репозиторий EPEL должен быть доступен.
- Не менее 500 MB свободного дискового пространства для DNF, его зависимостей и кэша метаданных репозитория.
Если вы используете минимальную установку CentOS 7 на Выделенном Сервере, убедитесь, что `curl` и `wget` доступны, так как они иногда отсутствуют в урезанных образах.
Шаг 1: Обновление существующих системных пакетов
Синхронизация базы данных пакетов перед установкой нового программного обеспечения предотвращает конфликты версий и гарантирует, что пакет релиза EPEL установится корректно относительно текущего состояния вашей базы данных RPM.
“`bash
sudo yum update -y
“`
Что делает эта команда: загружает и применяет все доступные обновления для установленных пакетов, обновляет метаданные репозитория и пересоздаёт блокировку транзакций RPM. На продакшен-системе планируйте это на период технического обслуживания — обновления ядра требуют перезагрузки для вступления в силу.
Граничный случай: если `yum update` завершается с ошибкой `Multilib version problems`, выполните `sudo yum update –setopt=protected_multilib=false -y` как разовое решение, а затем изучите конфликтующие пакеты перед продолжением.
Шаг 2: Подключение репозитория EPEL
DNF недоступен в стандартных базовых репозиториях CentOS/RHEL 7. Его предоставляет репозиторий Extra Packages for Enterprise Linux (EPEL), поддерживаемый проектом Fedora.
“`bash
sudo yum install epel-release -y
“`
Проверьте, что репозиторий активен:
“`bash
yum repolist | grep epel
“`
Ожидаемый вывод должен показывать `epel/x86_64` с ненулевым количеством пакетов (обычно 13 000+). Если репозиторий отображается как отключённый, принудительно включите его:
“`bash
sudo yum-config-manager –enable epel
“`
Примечание по безопасности: пакеты EPEL собираются и подписываются командой инфраструктуры Fedora. Пакет `epel-release` автоматически устанавливает GPG-ключ. Вы можете проверить отпечаток ключа на официальном сервере ключей Fedora перед тем, как доверять пакетам из этого репозитория — этот шаг стоит выполнить на защищённых продакшен-системах.
Работаете за прокси или файрволом? Если ваш сервер не может напрямую обращаться к зеркалам Fedora, настройте `/etc/yum.conf` с параметрами прокси:
“`ini
proxy=http://your-proxy-server:port
proxy_username=user
proxy_password=pass
“`
Шаг 3: Установка DNF
После активации EPEL установите DNF и его основные зависимости одной командой:
“`bash
sudo yum install dnf -y
“`
Это подтянет `dnf`, `dnf-data`, `python-dnf`, `libcomps`, `librepo` и `libsolv` в качестве автоматических зависимостей. Общий размер загрузки обычно составляет от 3 до 8 MB в зависимости от того, что уже установлено.
Что устанавливается:
- `dnf` — основной бинарный файл и интерфейс командной строки
- `libsolv` — резолвер зависимостей на основе SAT
- `librepo` — библиотека параллельной загрузки
- `libcomps` — парсер XML comps для групп пакетов
- `python-dnf` — Python-привязки и основная библиотека DNF
Шаг 4: Проверка установки
Убедитесь, что DNF работает, и проверьте его версию:
“`bash
dnf –version
“`
Успешная установка выдаёт вывод, аналогичный следующему:
“`
4.0.9.2
Installed: dnf-0:4.0.9.2-1.el7.noarch at …
Built : CentOS BuildSystem <http://bugs.centos.org> at …
“`
Выполните более глубокую проверку работоспособности, перечислив доступные репозитории, как их видит DNF:
“`bash
dnf repolist
“`
Вывод должен совпадать с тем, что показывает `yum repolist`, подтверждая, что DNF корректно унаследовал вашу существующую конфигурацию репозитория из `/etc/yum.repos.d/`.
Важно: DNF на CentOS 7 читает те же файлы `.repo` репозитория, что и YUM. Миграция репозиториев не требуется. Оба инструмента используют `/etc/yum.repos.d/` и `/var/cache/` (в отдельных подкаталогах).
Шаг 5: Справочник основных команд DNF
DNF намеренно совместим с командами YUM. В следующей таблице приведены наиболее часто используемые операции:
| Задача | Команда DNF |
|---|
| — | — |
|---|
| Обновить все пакеты | `sudo dnf update -y` |
|---|
| Установить пакет | `sudo dnf install <package> -y` |
|---|
| Удалить пакет | `sudo dnf remove <package> -y` |
|---|
| Найти пакет | `dnf search <keyword>` |
|---|
| Получить информацию о пакете | `dnf info <package>` |
|---|
| Список установленных пакетов | `dnf list installed` |
|---|
| Список доступных обновлений | `dnf check-update` |
|---|
| Очистить кэшированные метаданные | `sudo dnf clean all` |
|---|
| Просмотр истории транзакций | `dnf history` |
|---|
| Откат транзакции | `sudo dnf history undo <id>` |
|---|
| Установить группу пакетов | `sudo dnf groupinstall "<group>"` |
|---|
| Включить репозиторий | `sudo dnf config-manager –enable <repo>` |
|---|
История транзакций DNF и откат
Это одна из наиболее ценных с операционной точки зрения функций DNF, с которой YUM справляется плохо. Каждая установка, обновление или удаление записывается в `/var/lib/dnf/history/`. Для просмотра последних транзакций:
“`bash
dnf history list
“`
Чтобы увидеть, что именно изменилось в конкретной транзакции:
“`bash
dnf history info <transaction-id>
“`
Чтобы отменить транзакцию (например, откатить неудачное обновление):
“`bash
sudo dnf history undo <transaction-id>
“`
Эта возможность особенно полезна на VPS с cPanel, где обновление пакета может конфликтовать с зависимостями панели управления.
Файл конфигурации DNF
Глобальная конфигурация DNF находится в `/etc/dnf/dnf.conf`. Ключевые параметры настройки для продакшен-использования:
“`ini
[main]
gpgcheck=1
installonly_limit=3
clean_requirements_on_remove=True
best=True
skip_if_unavailable=False
“`
- `installonly_limit=3` — сохраняет только последние 3 версии ядра, предотвращая переполнение `/boot`.
- `clean_requirements_on_remove=True` — автоматически удаляет осиротевшие зависимости при удалении пакета.
- `best=True` — всегда устанавливает последнюю доступную версию, выдавая ошибку вместо молчаливого понижения версии.
Шаг 6: Настройка DNF как менеджера пакетов по умолчанию
На RHEL/CentOS 7 YUM остаётся системным менеджером по умолчанию. У вас есть два варианта сделать DNF основным интерфейсом.
Вариант A: псевдоним в оболочке (на уровне пользователя, без деструктивных изменений)
Добавьте следующее в `~/.bashrc` (для текущего пользователя) или `/etc/bashrc` (для всей системы):
“`bash
alias yum='dnf'
“`
Примените немедленно:
“`bash
source ~/.bashrc
“`
Ограничение: этот псевдоним применяется только к интерактивным сессиям оболочки. Скрипты, которые вызывают `yum` напрямую по абсолютному пути (`/usr/bin/yum`) или выполняются под другими пользователями (например, задания cron, юниты systemd), не затрагиваются.
Вариант B: символическая ссылка (на уровне системы)
Для более полной замены создайте символическую ссылку, перенаправляющую бинарный файл `yum` на `dnf`:
“`bash
sudo mv /usr/bin/yum /usr/bin/yum.bak
sudo ln -s /usr/bin/dnf /usr/bin/yum
“`
Критическое предупреждение: этот подход затрагивает всех пользователей и все скрипты в масштабах системы. Тщательно протестируйте в непродакшен-среде. Некоторые системные скрипты и сторонние инструменты (включая отдельные компоненты cPanel/WHM) явно вызывают `/usr/bin/yum` и могут вести себя непредсказуемо при замене бинарного файла. Всегда создавайте резервную копию оригинального бинарного файла, как показано выше.
Вариант C: DNF как плагин YUM (рекомендуется для серверов)
Наиболее чистый подход для продакшен-серверов — оставить YUM нетронутым и просто явно использовать `dnf` в собственных рабочих процессах и скриптах автоматизации. Это исключает любой риск поломки системных инструментов, предоставляя полный доступ к возможностям DNF.
Практические подводные камни и граничные случаи
Это проблемы, возникающие в реальных развёртываниях и редко освещаемые в базовых руководствах.
Конфликты GPG-ключей: если вы устанавливаете пакеты из нескольких сторонних репозиториев, более строгая проверка GPG в DNF (при `gpgcheck=1`) может отклонять пакеты, которые YUM ранее принимал молча. Всегда явно импортируйте GPG-ключи репозиториев с помощью `sudo rpm –import <key-url>`.
Несовместимость плагинов: некоторые плагины YUM (например, `yum-plugin-fastestmirror`) не имеют прямого эквивалента в DNF или ведут себя иначе. DNF имеет собственный плагин `fastestmirror` (`dnf-plugin-fastestmirror`), но он не включён по умолчанию. Установите его с помощью `sudo dnf install python3-dnf-plugin-fastestmirror`.
Различие расположения кэша: YUM кэширует метаданные в `/var/cache/yum/`. DNF использует `/var/cache/dnf/`. Если дисковое пространство ограничено, оба кэша могут сосуществовать и занимать значительный объём. Запускайте `sudo dnf clean all` и `sudo yum clean all` независимо для освобождения места.
Управление подпиской RHEL: на зарегистрированных системах RHEL 7 (в отличие от CentOS) плагин `subscription-manager` интегрируется с YUM. DNF на RHEL 7 может не полностью учитывать репозитории, защищённые подпиской, без дополнительной настройки. Проверьте с помощью `subscription-manager repos –list-enabled` после переключения.
Чувствительность к версии Python: DNF на CentOS 7 использует привязки Python 2 (`python-dnf`). Если вы обновились до Python 3 на своей системе, убедитесь, что вы случайно не нарушаете цепочку зависимостей `python-dnf`. DNF 4+ на RHEL 8+ использует Python 3 нативно.
Планирование пути миграции за пределы CentOS 7
CentOS 7 достиг конца жизненного цикла 30 июня 2024 года. Установка DNF является полезным операционным улучшением, но не меняет базовую ситуацию с безопасностью дистрибутива с истёкшим сроком поддержки. Если вы всё ещё используете рабочие нагрузки CentOS 7, план миграции на AlmaLinux 8/9, Rocky Linux 8/9 или RHEL 8/9 должен быть в вашей дорожной карте. Все эти дистрибутивы используют DNF нативно, что делает накопленные вами знания напрямую применимыми.
Для команд, управляющих несколькими сервисами на устаревшей инфраструктуре, Панели управления VPS могут значительно упростить управление параллельными средами в период миграции.
Если ваши рабочие нагрузки включают стеки веб-хостинга, миграция на современный дистрибутив также позволяет в полной мере воспользоваться автоматизацией SSL-сертификатов через Certbot и ACME, которая значительно лучше поддерживается на RHEL 8+ и его производных.
Краткая матрица принятия решений
Используйте этот контрольный список до и после установки для подтверждения чистой, безопасной для продакшена настройки:
- [ ] `yum update -y` завершён без ошибок перед установкой EPEL
- [ ] Репозиторий EPEL подтверждён активным через `yum repolist | grep epel`
- [ ] `dnf –version` возвращает корректную строку версии
- [ ] Вывод `dnf repolist` совпадает с выводом `yum repolist`
- [ ] `/etc/dnf/dnf.conf` проверен и настроен для вашей среды
- [ ] `installonly_limit` установлен для предотвращения переполнения раздела `/boot`
- [ ] Принято решение о стратегии: псевдоним, символическая ссылка или сосуществование
- [ ] Бинарный файл YUM сохранён в резервную копию при использовании подхода с символической ссылкой
- [ ] Задания cron и скрипты автоматизации проверены на наличие жёстко заданных путей `yum`
- [ ] Задокументированы сроки миграции с CentOS 7 в связи с окончанием поддержки
FAQ
Могут ли DNF и YUM сосуществовать на одной системе CentOS 7 без конфликтов?
Да. Оба инструмента читают из `/etc/yum.repos.d/` и ведут отдельные каталоги кэша. Они совместно используют базу данных RPM (`/var/lib/rpm`), поэтому транзакция, выполненная одним инструментом, немедленно становится видна другому. Одновременный запуск обоих (например, два параллельных процесса установки) вызовет конфликт блокировки RPM, но последовательное использование полностью безопасно.
Сломает ли установка DNF на CentOS 7 существующие плагины YUM?
Нет. DNF устанавливается как независимый бинарный файл и не изменяет установку YUM. Ваши существующие плагины YUM остаются нетронутыми. Однако DNF не загружает плагины YUM — если вы зависите от конкретных плагинов YUM, вам нужно найти и установить их эквиваленты для DNF отдельно.
Поддерживает ли DNF на CentOS 7 модули DNF (потоки модулей)?
Нет. Потоки модулей DNF — это функция, введённая в DNF 4 и RHEL/CentOS 8. Версия DNF, доступная через EPEL для CentOS 7, — это DNF 4.x, но поддержка потоков модулей требует инфраструктуры репозитория AppStream, которой не существует на CentOS 7.
Почему `dnf update` иногда даёт результаты, отличающиеся от `yum update` на одной системе?
Резолвер `libsolv` в DNF применяет более строгую логику зависимостей и может разрешать выбор версий иначе, чем внутренний резолвер YUM. В большинстве случаев результат идентичен, но в средах со сложными или конфликтующими зависимостями DNF может выбирать другие версии пакетов или отклонять транзакции, которые YUM молча допустил бы. Это особенность, а не ошибка — поведение DNF более предсказуемо и поддаётся аудиту.
Безопасно ли использовать DNF на сервере CentOS 7, на котором размещены продакшен-веб-приложения?
Да, при условии, что вы используете подход сосуществования (оставляете YUM нетронутым, явно используете DNF), а не заменяете бинарный файл YUM. Убедитесь, что любое программное обеспечение панели управления или автоматизация развёртывания на вашем сервере не имеют жёстко заданных предположений о поведении YUM, прежде чем переводить основной рабочий процесс на DNF.
