RPM и DNF: Полное руководство по управлению пакетами в CentOS, Fedora и RE OS | AdminWiki

RPM и DNF: Полное руководство по управлению пакетами в CentOS, Fedora и RE OS

26 июля 2026 11 мин. чтения
Содержание статьи

DNF (Dandified YUM) - это основной пакетный менеджер в CentOS 8+, Fedora и RE OS. Он работает поверх формата RPM и заменяет устаревший YUM. С помощью DNF вы устанавливаете, удаляете и обновляете софт, разрешаете зависимости и управляете репозиториями. В этой статье собраны проверенные команды и сценарии для ежедневной работы DevOps-инженера и системного администратора. Вы получите готовую шпаргалку и пошаговые инструкции для настройки окружения.

Введение: почему DNF и RPM - основа управления ПО в RHEL-совместимых системах

RPM (Red Hat Package Manager) - это формат пакетов и низкоуровневая утилита для работы с ними. Каждый RPM-пакет содержит бинарные файлы, скрипты установки и метаданные: версию, архитектуру, зависимости. DNF работает как надстройка: он читает базу RPM, скачивает пакеты из репозиториев, вычисляет дерево зависимостей и передает готовый список утилите rpm для установки.

DNF появился в Fedora 18 как экспериментальная замена YUM, а с RHEL 8 и CentOS 8 стал стандартом. Ключевые преимущества DNF перед YUM: строгая проверка зависимостей через библиотеку libsolv, поддержка модульных потоков (modularity) и документированное API на Python 3. Для администратора это означает меньше конфликтов при обновлениях и предсказуемое поведение менеджера. Если вы переходите с CentOS 7, где использовался YUM, синтаксис DNF останется знакомым - большинство команд совпадают.

Это руководство построено от простых операций к продвинутым. Сначала разберем ежедневные задачи: установка, удаление, обновление. Затем перейдем к поиску пакетов, настройке репозиториев и работе с группами. В конце рассмотрим низкоуровневые команды RPM, историю транзакций и автоматизацию обновлений. Все примеры проверены на CentOS 9 Stream, Fedora 40 и RE OS 8.

Быстрый старт: основные команды DNF для ежедневной работы

Этот раздел - самодостаточная шпаргалка. Команды покрывают 90% задач администратора при работе с пакетами. Для углубленного изучения каждой операции переходите к соответствующим разделам ниже.

Установка пакетов: dnf install и его ключи

Базовая установка из подключенных репозиториев выполняется одной командой:

dnf install nginx

DNF автоматически найдет пакет, вычислит зависимости и запросит подтверждение. Для автоматического согласия используйте ключ -y:

dnf install -y nginx

Установка локального RPM-файла, скачанного вручную:

dnf install ./package.rpm

DNF попытается разрешить зависимости через подключенные репозитории. Если подписи пакетов не проверяются в изолированной среде, отключите проверку GPG ключом --nogpgcheck:

dnf install --nogpgcheck ./custom-app.rpm

Установка конкретной версии пакета с указанием эпохи, версии и релиза:

dnf install nginx-1.24.0-2.el9

Массовая установка нескольких пакетов одной строкой:

dnf install nginx mariadb-server php-fpm

Удаление пакетов: dnf remove и очистка зависимостей

Удаление пакета с сохранением его зависимостей в системе:

dnf remove nginx

DNF удалит только указанный пакет. Пакеты, установленные как зависимости и не требующиеся другим программам, останутся. Для их автоматической очистки используйте autoremove:

dnf autoremove

Эта команда сканирует базу и удаляет все «осиротевшие» зависимости. Запускайте её после крупных удалений или периодически для поддержания чистоты системы. Будьте внимательны: если пакет был установлен явно, но позже помечен как зависимость, autoremove может его удалить. Проверьте список перед подтверждением.

Для удаления пакета вместе с его неиспользуемыми зависимостями одной командой:

dnf remove --noautoremove nginx

Ключ --noautoremove отключает автоматическое удаление зависимостей при этой транзакции.

Обновление системы: dnf update и dnf upgrade

Проверка доступных обновлений без их применения:

dnf check-update

Команда выводит список пакетов с новыми версиями и возвращает код 100, если обновления есть. Это удобно для скриптов мониторинга.

Применение всех доступных обновлений:

dnf update

dnf update и dnf upgrade в DNF - синонимы. Обе команды обновляют пакеты до последних версий в подключенных репозиториях. Разница проявляется при обновлении с устареванием пакетов (obsoletes): upgrade обрабатывает их, update - нет. На практике используйте upgrade как более полный вариант.

Обновление только пакетов, связанных с безопасностью:

dnf update --security

Это критично для серверов, где важна стабильность. DNF установит только исправления уязвимостей, не затрагивая функциональные обновления. Для работы ключа нужны репозитории с корректными метаданными security (например, официальные репозитории RE OS и CentOS).

Обновление ядра и перезагрузка:

dnf update kernel
reboot

DNF сохраняет предыдущие версии ядра. После перезагрузки старое ядро остается доступным в загрузчике для отката.

Поиск и анализ пакетов перед установкой

Перед установкой пакета администратор должен знать: что именно ставится, из какого репозитория, какие зависимости потянет и какие файлы принесет в систему. DNF предоставляет полный набор инструментов для такого анализа.

Использование dnf search и dnf list для поиска

Поиск пакета по названию и описанию:

dnf search nginx

Команда ищет подстроку в именах и кратких описаниях пакетов. Результат можно фильтровать через grep:

dnf search nginx | grep -i stream

Просмотр установленных пакетов:

dnf list installed

Список доступных для установки пакетов из репозиториев:

dnf list available

Поиск пакета, который предоставляет конкретный файл - частая задача при ошибках «command not found»:

dnf provides /usr/bin/htop

DNF покажет, какой пакет нужно установить, чтобы получить искомый бинарник или библиотеку. Это работает и для ещё не установленных файлов.

Анализ пакета: dnf info, deplist и repoquery

Получение детальной информации о пакете:

dnf info nginx

Вывод включает версию, архитектуру, размер, репозиторий-источник и краткое описание.

Просмотр дерева зависимостей:

dnf deplist nginx

Команда показывает, какие пакеты потребуются для установки и какие зависят от nginx. Это помогает оценить объем изменений до начала транзакции.

Запросы к репозиториям через repoquery дают больше гибкости. Список всех файлов в пакете без его установки:

dnf repoquery -l nginx

Поиск пакета-владельца файла в репозиториях (аналог provides, но с расширенными фильтрами):

dnf repoquery --file /etc/nginx/nginx.conf

Управление репозиториями: добавление, отключение и настройка

Репозитории - источники RPM-пакетов. Стандартная установка CentOS или RE OS подключает базовые репозитории (BaseOS, AppStream). Для расширения доступного ПО администратор добавляет сторонние источники: EPEL, RPM Fusion, репозитории вендоров.

Просмотр и управление списком репозиториев

Список всех подключенных репозиториев:

dnf repolist all

Вывод показывает ID репозитория, имя и статус (enabled/disabled). Детальная информация о конкретном репозитории:

dnf repoinfo epel

Включение и отключение репозиториев через config-manager:

dnf config-manager --set-enabled epel
dnf config-manager --set-disabled epel

Временное отключение репозитория для одной команды:

dnf install --disablerepo=epel nginx

Временное включение отключенного репозитория:

dnf install --enablerepo=powertools package

Подключение дополнительных репозиториев: EPEL и RPM Fusion

EPEL (Extra Packages for Enterprise Linux) - официальный репозиторий от Fedora Project с дополнительными пакетами для RHEL-совместимых систем. Установка:

dnf install epel-release

После установки пакета epel-release репозиторий активируется автоматически. Проверьте доступность новых пакетов:

dnf repolist | grep epel
dnf search htop

RPM Fusion предоставляет ПО, которое не включено в официальные репозитории из-за патентных или лицензионных ограничений (мультимедиа кодеки, драйверы NVIDIA). Подключение free и nonfree веток:

dnf install --nogpgcheck https://download1.rpmfusion.org/free/el/rpmfusion-free-release-9.noarch.rpm
dnf install --nogpgcheck https://download1.rpmfusion.org/nonfree/el/rpmfusion-nonfree-release-9.noarch.rpm

Для Fedora используйте соответствующие версии пакетов с сайта RPM Fusion.

Тонкая настройка: приоритеты и исключения

Конфликты версий возникают, когда один пакет доступен в нескольких репозиториях. Для управления приоритетами установите плагин:

dnf install dnf-plugin-priorities

В файлах репозиториев /etc/yum.repos.d/*.repo добавьте параметр priority. Чем меньше число, тем выше приоритет:

[baseos]
name=RE OS BaseOS
baseurl=http://repo.re-os.ru/baseos/
priority=1

Для блокировки обновления конкретных пакетов используйте параметр exclude в /etc/dnf/dnf.conf или в секции репозитория:

exclude=kernel* nginx*

Это предотвратит случайное обновление ядра из EPEL или обновление nginx до мажорной версии, несовместимой с вашими конфигурациями. После изменения конфигурации очистите кэш:

dnf clean all

Работа с группами пакетов и модулями

Группы пакетов - это логические наборы ПО для типовых задач: «Development Tools» для компиляции, «Container Management» для работы с Docker, окружения рабочего стола. Модули - механизм выбора конкретной версии ПО в рамках одного репозитория.

Установка и удаление групп пакетов

Просмотр всех доступных групп, включая скрытые:

dnf group list --hidden

Информация о составе группы:

dnf group info "Development Tools"

Установка группы:

dnf group install "Development Tools"

Удаление группы:

dnf group remove "Development Tools"

Разница между установкой группы и отдельных пакетов в том, что группа помечается как явно установленная. При удалении группы DNF удалит все пакеты, входящие в неё, если они не требуются другим программам.

Модули: выбор версии ПО в Fedora и RE OS

Модульность (modularity) позволяет репозиториям предлагать несколько версий одного приложения. Например, в AppStream можно выбрать Python 3.9 или 3.11, Node.js 18 или 20. Просмотр доступных модулей:

dnf module list

Каждый модуль имеет потоки (streams) - версии приложения. Включение конкретного потока:

dnf module enable nodejs:20

Установка модуля:

dnf module install nodejs:20

Сброс выбора модуля к состоянию по умолчанию:

dnf module reset nodejs

Переключение версии Python с 3.9 на 3.11 на RE OS 8:

dnf module reset python39
dnf module enable python311
dnf module install python311

Модульность снижает риск конфликтов версий при установке ПО из разных потоков. DNF отслеживает зависимости внутри модуля и не допустит установки несовместимых комбинаций.

Низкоуровневая работа с RPM: когда DNF недостаточно

DNF покрывает большинство задач, но есть сценарии, где нужен прямой доступ к утилите rpm: установка локальных пакетов с пропуском зависимостей, аудит целостности системы, извлечение файлов из пакетов.

Установка и обновление локальных RPM-пакетов

Установка локального пакета с подробным выводом прогресса:

rpm -ivh package.rpm

Ключи: -i - install, -v - verbose, -h - хэш-прогресс. Если зависимости не удовлетворены, rpm выдаст ошибку и не установит пакет. Для установки с игнорированием зависимостей (только в исключительных случаях):

rpm -ivh --nodeps package.rpm

Обновление установленного пакета локальным RPM:

rpm -Uvh package.rpm

Ключ -U обновляет пакет, если он уже установлен, или устанавливает как новый. Для принудительной переустановки той же версии:

rpm -ivh --force package.rpm

Рекомендация: если пакет скачан вручную и требует зависимостей, используйте dnf localinstall вместо чистого rpm. DNF сам разрешит зависимости через репозитории.

Аудит и проверка целостности установленных пакетов

Проверка всех установленных пакетов на предмет изменений файлов:

rpm -Va

Вывод использует коды: S - изменён размер, M - изменены права или тип файла, 5 - изменена контрольная сумма, T - изменено время модификации. Отсутствие вывода означает, что все файлы соответствуют эталону из RPM-базы.

Проверка конкретного пакета:

rpm -V nginx

Это быстрый способ обнаружить взлом или случайное изменение конфигурационных файлов. Учтите, что легитимные изменения конфигов (/etc/nginx/nginx.conf) тоже отобразятся в выводе - это нормально.

Поиск пакетов, установленных в системе, но не имеющих файлов (пустые или метапакеты):

rpm -qa --qf '%{NAME} %{SIZE}\n' | grep ' 0$'

Запрос информации из базы RPM

Список всех установленных пакетов с сортировкой по дате установки (последние сверху):

rpm -qa --last

Просмотр конфигурационных файлов, входящих в пакет:

rpm -qc nginx

Просмотр файлов документации:

rpm -qd nginx

Форматированный вывод с произвольными полями через --qf (query format):

rpm -qa --qf "%-30{NAME} %-10{VERSION} %{INSTALLTIME:date}\n"

Извлечение файлов из RPM-пакета без установки через rpm2cpio:

rpm2cpio package.rpm | cpio -idmv

Это полезно, когда нужно достать один файл из пакета, не затрагивая систему.

История транзакций DNF: отмена и откат изменений

DNF записывает каждую операцию (установку, удаление, обновление) в журнал транзакций. Это позволяет отменить неудачное обновление или вернуть систему к предыдущему состоянию.

Просмотр истории транзакций:

dnf history list

Вывод показывает ID транзакции, команду, дату и количество изменённых пакетов. Детальная информация о конкретной транзакции:

dnf history info 42

Отмена последней транзакции (операция, обратная выполненной):

dnf history undo 42

Если транзакция 42 установила nginx, undo удалит его. Если транзакция удалила пакет, undo установит его обратно. Откат системы к состоянию после транзакции 40 (отмена всех транзакций после указанной):

dnf history rollback 40

Разница между undo и rollback: undo отменяет одну транзакцию, rollback откатывает все транзакции до указанной, включая её саму. Пример: после массового обновления система стала нестабильной. Выполните:

dnf history list
dnf history rollback 38

Система вернётся к набору пакетов, который был после транзакции 38.

Автоматизация обновлений с dnf-automatic

Для серверов, где ручное обновление неудобно, настройте автоматическую установку обновлений безопасности через dnf-automatic. Пакет входит в стандартные репозитории.

Установка:

dnf install dnf-automatic

Конфигурационный файл /etc/dnf/automatic.conf управляет поведением. Ключевые параметры в секции [commands]:

upgrade_type = security
download_updates = yes
apply_updates = yes

Параметр upgrade_type принимает значения security (только обновления безопасности) или default (все обновления). Для критичных production-серверов выбирайте security. Секция [emitters] настраивает уведомления:

emit_via = motd

Активация через systemd-таймер:

systemctl enable --now dnf-automatic.timer

Таймер по умолчанию запускает обновление ежедневно. Проверьте расписание:

systemctl list-timers dnf-automatic.timer

Логи доступны через journalctl:

journalctl -u dnf-automatic

Для углублённой настройки автоматизации Linux-серверов, включая написание скриптов и использование Ansible, обратитесь к руководству по автоматизации администрирования Linux.

Решение типичных проблем и лучшие практики

Устранение конфликтов зависимостей

Ошибка «nothing provides ...» означает, что требуемая зависимость отсутствует в подключенных репозиториях. Алгоритм действий:

  1. Проверьте вывод dnf install - в нём указано, какой именно пакет требуется.
  2. Найдите пакет, предоставляющий зависимость: dnf provides <зависимость>.
  3. Если пакет найден в отключенном репозитории, временно включите его: --enablerepo=<repo>.
  4. Если зависимость недоступна, попробуйте установить с пропуском сломанных пакетов: dnf install --skip-broken <пакет>.
  5. Для поиска неудовлетворённых зависимостей в системе: dnf repoquery --unsatisfied.

Восстановление после сбоя транзакции

Если установка или обновление прервались (питание, сеть), база RPM может остаться в несогласованном состоянии. Порядок восстановления:

  1. Очистите кэш DNF: dnf clean all.
  2. Попробуйте синхронизировать установленные пакеты с репозиториями: dnf distro-sync. Команда приводит версии пакетов к тем, что доступны в репозиториях.
  3. Если ошибка сохраняется, проверьте целостность базы RPM: rpm --rebuilddb.
  4. Отмените последнюю незавершённую транзакцию: dnf history undo last.

Профилактика: регулярные задачи администратора

Чек-лист для поддержания системы в здоровом состоянии:

  • Очистка кэша загруженных пакетов: dnf clean packages. Освобождает место в /var/cache/dnf.
  • Очистка устаревших метаданных репозиториев: dnf clean metadata.
  • Проверка неустановленных обновлений безопасности: dnf updateinfo list security.
  • Аудит целостности критичных пакетов: rpm -V kernel openssh nginx.
  • Обновление GPG-ключей репозиториев: rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-*.
  • Тестирование обновлений в staging-окружении перед развёртыванием на production.

Безопасность сервера не ограничивается обновлениями пакетов. Полный цикл hardening-мероприятий, включая настройку файрвола и аудит конфигураций, описан в практическом руководстве по защите Linux-сервера.

Для администрирования серверов через веб-интерфейс рассмотрите Cockpit - он интегрируется с systemd и позволяет управлять пакетами, службами и контейнерами из браузера. Подробная инструкция по установке и настройке доступна в руководстве по настройке Cockpit.

Управление пакетами - одна из фундаментальных задач при работе с Linux. Если вы систематизируете знания по всей экосистеме, начните с практического руководства по Linux для IT-специалистов - оно охватывает выбор дистрибутива, работу в bash и настройку сетей.

Поделиться:
Сохранить гайд? В закладки браузера