Инсталиране на 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-solver двигател за разрешаване на зависимости, първоначално разработен от SUSE. Практическите последици са значителни:

• Скорост на разрешаване на зависимости: DNF разрешава сложни вериги от зависимости за малка част от времето, което изисква YUM, което е особено забележимо при разрешаване на конфликти в големи набори от пакети.
• Използване на памет: YUM зарежда цялото метаданни на хранилището в паметта. DNF използва отложено зареждане и кешира по-агресивно, намалявайки пиковото използване на RAM.
• Стабилност на API: Python API на YUM се променяше непредвидимо между второстепенни версии. DNF предоставя документиран, версиониран Python API, на който авторите на плъгини могат да разчитат.
• Архитектура на плъгините: DNF използва чиста система за плъгини, базирана на куки. Плъгините на YUM често си пречат един на друг поради слабото свързване.
• История на транзакциите: DNF поддържа по-богата база данни с история на транзакциите, което прави връщанията назад и одитите по-прецизни.

YUM срещу DNF: Сравнение на функциите

Предварителни изисквания

Преди да продължите, потвърдете следното:

• Работещ екземпляр на RHEL 7 или CentOS 7 (физически сървър, виртуална машина или облачен VPS).
• Root или sudo достъп — всички команди за инсталация изискват повишени привилегии.
• Активна интернет връзка — хранилището EPEL трябва да е достъпно.
• Поне 500 MB свободно дисково пространство за DNF, неговите зависимости и кеша на метаданните на хранилището.

Ако работите с минимална инсталация на CentOS 7 на Dedicated Server, проверете дали `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 вашия основен интерфейс.

Вариант А: Псевдоним на обвивката (на ниво потребител, без разрушителни последствия)

Добавете следното към `~/.bashrc` (за текущия потребител) или `/etc/bashrc` (за цялата система):

“`bash

alias yum='dnf'

“`

Приложете незабавно:

“`bash

source ~/.bashrc

“`

Ограничение: Този псевдоним се прилага само за интерактивни сесии на обвивката. Скриптове, които извикват `yum` директно чрез абсолютния им път (`/usr/bin/yum`) или които се изпълняват под различни потребители (напр. cron задачи, systemd единици), не се влияят.

Вариант Б: Символна връзка (на системно ниво)

За по-задълбочена замяна, създайте символна връзка, която пренасочва двоичния файл `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` и може да се държат неочаквано, ако двоичният файл бъде заменен. Винаги архивирайте оригиналния двоичен файл, както е показано по-горе.

Вариант В: 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.