Встановлення 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 проти DNF: порівняння функцій

Передумови

Перед початком переконайтеся в наступному:

• Запущений екземпляр RHEL 7 або CentOS 7 (фізичний сервер, VM або хмарний 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 та відкат

Це одна з найбільш цінних з операційної точки зору функцій 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 після закінчення підтримки

Поширені запитання

Чи можуть 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.