Instalați DNF pe RHEL/CentOS 7: Un Ghid Tehnic Complet

DNF (Dandified YUM) este managerul de pachete de nouă generație pentru distribuțiile Linux bazate pe RPM, conceput ca înlocuitor complet pentru YUM. Oferă o rezolvare mai rapidă a dependențelor prin biblioteca `libsolv`, un consum mai redus de memorie și un API Python stabil. Deși RHEL/CentOS 7 vine implicit cu YUM, DNF poate fi instalat complet prin depozitul EPEL și poate rula în paralel cu — sau ca înlocuitor transparent pentru — YUM pe același sistem.

Acest ghid parcurge procesul complet de instalare, explică diferențele arhitecturale dintre YUM și DNF, acoperă cazuri limită din lumea reală și vă oferă un manual de referință pentru comenzi gata de producție.

De ce DNF depășește YUM pe RHEL/CentOS 7

Înainte de a deschide terminalul, înțelegerea *motivului* pentru care actualizarea contează vă ajută să luați o decizie informată — mai ales pe un mediu VPS Hosting cu rulare îndelungată, unde fiabilitatea gestionării pachetelor este critică.

Diferențe arhitecturale de bază

YUM se bazează pe un rezolvator de dependențe bazat pe Python care are probleme de performanță bine documentate cu arbori mari de dependențe. DNF înlocuiește acel rezolvator cu `libsolv`, un motor de rezolvare a dependențelor bazat pe SAT-solver, dezvoltat inițial de SUSE. Consecințele practice sunt semnificative:

• Viteza de rezolvare a dependențelor: DNF rezolvă lanțuri complexe de dependențe într-o fracțiune din timpul necesar YUM, lucru deosebit de vizibil la rezolvarea conflictelor în seturi mari de pachete.
• Amprenta de memorie: YUM încarcă întreaga metadată a depozitului în memorie. DNF folosește încărcare leneșă și memorează în cache mai agresiv, reducând utilizarea maximă a RAM.
• Stabilitatea API: API-ul Python al YUM s-a schimbat imprevizibil între versiunile minore. DNF expune un API Python documentat și versionat pe care autorii de plugin-uri se pot baza.
• Arhitectura plugin-urilor: DNF folosește un sistem de plugin-uri curat bazat pe hook-uri. Plugin-urile YUM interferează adesea între ele din cauza cuplării slabe.
• Istoricul tranzacțiilor: DNF menține o bază de date mai bogată a istoricului tranzacțiilor, făcând revenirile și auditurile mai precise.

YUM vs. DNF: Comparație de funcționalități

Cerințe preliminare

Înainte de a continua, confirmați următoarele:

• O instanță funcțională de RHEL 7 sau CentOS 7 (metal gol, VM sau un VPS în cloud).
• Acces root sau sudo — toate comenzile de instalare necesită privilegii ridicate.
• Conectivitate activă la internet — depozitul EPEL trebuie să fie accesibil.
• Cel puțin 500 MB spațiu liber pe disc pentru DNF, dependențele sale și memoria cache a metadatelor depozitului.

Dacă rulați o instalare minimală de CentOS 7 pe un Server Dedicat, verificați că `curl` și `wget` sunt disponibile, deoarece acestea lipsesc uneori din imaginile reduse la minimum.

Pasul 1: Actualizați pachetele de sistem existente

Sincronizarea bazei de date de pachete înainte de instalarea de software nou previne conflictele de versiuni și asigură că pachetul de lansare EPEL se instalează corect față de starea curentă a bazei de date RPM.

“`bash

sudo yum update -y

“`

Ce face aceasta: Descarcă și aplică toate actualizările disponibile pentru pachetele instalate în prezent, reîmprospătează metadatele depozitului și reconstruiește blocarea tranzacției RPM. Pe un sistem de producție, programați aceasta în timpul unei ferestre de întreținere — actualizările de kernel necesită o repornire pentru a intra în vigoare.

Caz limită: Dacă `yum update` eșuează cu o eroare `Multilib version problems`, rulați `sudo yum update –setopt=protected_multilib=false -y` ca soluție temporară, apoi investigați pachetele conflictuale înainte de a continua.

Pasul 2: Activați depozitul EPEL

DNF nu este disponibil în depozitele de bază implicite CentOS/RHEL 7. Depozitul Extra Packages for Enterprise Linux (EPEL), întreținut de proiectul Fedora, îl furnizează.

“`bash

sudo yum install epel-release -y

“`

Verificați că depozitul este activ:

“`bash

yum repolist | grep epel

“`

Rezultatul așteptat ar trebui să arate `epel/x86_64` cu un număr nenul de pachete (de obicei 13.000+). Dacă depozitul apare dezactivat, forțați activarea acestuia:

“`bash

sudo yum-config-manager –enable epel

“`

Notă de securitate: Pachetele EPEL sunt construite și semnate de echipa de infrastructură Fedora. Pachetul `epel-release` instalează automat cheia GPG. Puteți verifica amprenta cheii față de serverul oficial de chei Fedora înainte de a avea încredere în pachetele din acest depozit — un pas care merită efectuat pe sistemele de producție întărite.

În spatele unui proxy sau firewall? Dacă serverul dvs. nu poate accesa direct oglinzile Fedora, configurați `/etc/yum.conf` cu setările proxy-ului dvs.:

“`ini

proxy=http://your-proxy-server:port

proxy_username=user

proxy_password=pass

“`

Pasul 3: Instalați DNF

Cu EPEL activ, instalați DNF și dependențele sale de bază într-o singură comandă:

“`bash

sudo yum install dnf -y

“`

Aceasta aduce `dnf`, `dnf-data`, `python-dnf`, `libcomps`, `librepo` și `libsolv` ca dependențe automate. Dimensiunea totală a descărcării este de obicei între 3–8 MB, în funcție de ce este deja instalat.

Ce se instalează:

• `dnf` — binarul principal și interfața de linie de comandă
• `libsolv` — rezolvatorul de dependențe bazat pe SAT
• `librepo` — biblioteca de descărcare paralelă
• `libcomps` — parser XML comps pentru grupuri de pachete
• `python-dnf` — legăturile Python și biblioteca de bază DNF

Pasul 4: Verificați instalarea

Confirmați că DNF funcționează și verificați versiunea sa:

“`bash

dnf –version

“`

O instalare reușită produce un rezultat similar cu:

“`

4.0.9.2

Installed: dnf-0:4.0.9.2-1.el7.noarch at …

Built : CentOS BuildSystem <http://bugs.centos.org> at …

“`

Rulați o verificare mai aprofundată listând depozitele disponibile văzute de DNF:

“`bash

dnf repolist

“`

Rezultatul ar trebui să reflecte ceea ce arată `yum repolist`, confirmând că DNF a moștenit corect configurația depozitului existent din `/etc/yum.repos.d/`.

Important: DNF pe CentOS 7 citește aceleași fișiere `.repo` ale depozitului ca YUM. Nu este necesară nicio migrare a depozitului. Ambele instrumente partajează `/etc/yum.repos.d/` și `/var/cache/` (în subdirectoare separate).

Pasul 5: Manual de referință pentru comenzi DNF de bază

DNF este compatibil intenționat cu comenzile YUM. Tabelul următor acoperă operațiunile pe care le veți folosi cel mai frecvent:

Istoricul tranzacțiilor DNF și revenirea

Aceasta este una dintre cele mai valoroase funcționalități operaționale ale DNF și una pe care YUM o gestionează slab. Fiecare instalare, actualizare sau eliminare este înregistrată în `/var/lib/dnf/history/`. Pentru a inspecta tranzacțiile recente:

“`bash

dnf history list

“`

Pentru a vedea exact ce s-a schimbat într-o tranzacție specifică:

“`bash

dnf history info <transaction-id>

“`

Pentru a anula o tranzacție (de exemplu, revenirea după o actualizare defectuoasă):

“`bash

sudo dnf history undo <transaction-id>

“`

Această capacitate este deosebit de utilă pe un VPS cu cPanel unde o actualizare de pachet ar putea intra în conflict cu dependențele panoului de control.

Fișierul de configurare DNF

Configurația globală a DNF se află la `/etc/dnf/dnf.conf`. Parametri cheie de ajustare pentru utilizarea în producție:

“`ini

[main]

gpgcheck=1

installonly_limit=3

clean_requirements_on_remove=True

best=True

skip_if_unavailable=False

“`

• `installonly_limit=3` — păstrează doar ultimele 3 versiuni de kernel, prevenind umplerea `/boot`.
• `clean_requirements_on_remove=True` — elimină automat dependențele orfane la eliminarea pachetelor.
• `best=True` — instalează întotdeauna cea mai recentă versiune disponibilă, generând o eroare în loc să facă downgrade în tăcere.

Pasul 6: Configurarea DNF ca manager de pachete implicit

Pe RHEL/CentOS 7, YUM rămâne implicit pentru sistem. Aveți două opțiuni pentru a face DNF interfața dvs. principală.

Opțiunea A: Alias de shell (la nivel de utilizator, nedestructiv)

Adăugați următoarele în `~/.bashrc` (pentru utilizatorul curent) sau `/etc/bashrc` (la nivel de sistem):

“`bash

alias yum='dnf'

“`

Aplicați imediat:

“`bash

source ~/.bashrc

“`

Limitare: Acest alias se aplică doar sesiunilor interactive de shell. Scripturile care invocă `yum` direct prin calea absolută (`/usr/bin/yum`) sau care rulează sub alți utilizatori (de ex., sarcini cron, unități systemd) nu sunt afectate.

Opțiunea B: Legătură simbolică (la nivel de sistem)

Pentru o înlocuire mai completă, creați o legătură simbolică care redirecționează binarul `yum` către `dnf`:

“`bash

sudo mv /usr/bin/yum /usr/bin/yum.bak

sudo ln -s /usr/bin/dnf /usr/bin/yum

“`

Avertisment critic: Această abordare afectează toți utilizatorii și toate scripturile la nivel de sistem. Testați temeinic într-un mediu non-producție mai întâi. Unele scripturi de sistem și instrumente terțe (inclusiv anumite componente cPanel/WHM) apelează explicit `/usr/bin/yum` și pot să se comporte neașteptat dacă binarul este înlocuit. Faceți întotdeauna o copie de rezervă a binarului original, așa cum este indicat mai sus.

Opțiunea C: DNF ca plugin YUM (recomandat pentru servere)

Cea mai curată abordare pentru serverele de producție este să lăsați YUM intact și să folosiți pur și simplu `dnf` explicit în propriile fluxuri de lucru și scripturi de automatizare. Aceasta evită orice risc de a deteriora instrumentele de sistem, oferindu-vă în același timp acces complet la capacitățile DNF.

Capcane practice și cazuri limită

Acestea sunt probleme care apar în implementările reale și sunt rareori acoperite în tutorialele de bază.

Conflicte de chei GPG: Dacă instalați pachete din mai multe depozite terțe, aplicarea mai strictă a GPG de către DNF (când `gpgcheck=1`) poate respinge pachete pe care YUM le-a acceptat anterior în tăcere. Importați întotdeauna cheile GPG ale depozitului explicit cu `sudo rpm –import <key-url>`.

Incompatibilitate de plugin-uri: Unele plugin-uri YUM (de ex., `yum-plugin-fastestmirror`) nu au un echivalent direct în DNF sau se comportă diferit. DNF are propriul plugin `fastestmirror` (`dnf-plugin-fastestmirror`), dar nu este activat implicit. Instalați-l cu `sudo dnf install python3-dnf-plugin-fastestmirror`.

Divergența locației cache-ului: YUM memorează în cache metadatele în `/var/cache/yum/`. DNF folosește `/var/cache/dnf/`. Dacă spațiul pe disc este limitat, ambele cache-uri pot coexista și consuma spațiu semnificativ. Rulați `sudo dnf clean all` și `sudo yum clean all` independent pentru a recupera spațiu.

Gestionarea abonamentelor RHEL: Pe sistemele RHEL 7 înregistrate (spre deosebire de CentOS), plugin-ul `subscription-manager` se integrează cu YUM. DNF pe RHEL 7 poate să nu respecte pe deplin depozitele restricționate prin abonament fără configurare suplimentară. Verificați cu `subscription-manager repos –list-enabled` după comutare.

Sensibilitate la versiunea Python: DNF pe CentOS 7 folosește legăturile Python 2 (`python-dnf`). Dacă ați actualizat la Python 3 pe sistemul dvs., asigurați-vă că nu deteriorați inadvertent lanțul de dependențe `python-dnf`. DNF 4+ pe RHEL 8+ folosește Python 3 nativ.

Planificarea căii de migrare dincolo de CentOS 7

CentOS 7 a atins sfârșitul vieții pe 30 iunie 2024. Instalarea DNF este o îmbunătățire operațională utilă, dar nu schimbă postura de securitate de bază a unei distribuții EOL. Dacă mai rulați sarcini de lucru CentOS 7, un plan de migrare la AlmaLinux 8/9, Rocky Linux 8/9 sau RHEL 8/9 ar trebui să fie pe foaia dvs. de parcurs. Toate aceste distribuții folosesc DNF nativ, făcând familiarizarea pe care o construiți acum direct transferabilă.

Pentru echipele care rulează mai multe servicii pe infrastructuri îmbătrânite, Panouri de control VPS pot simplifica semnificativ gestionarea mediilor paralele în timpul unei ferestre de migrare.

Dacă sarcinile dvs. de lucru includ stive de găzduire web, migrarea la o distribuție modernă vă permite, de asemenea, să profitați pe deplin de automatizarea Certificatelor SSL prin Certbot și ACME, care are suport semnificativ mai bun pe RHEL 8+ și derivatele sale.

Matricea de decizie de referință rapidă

Folosiți această listă de verificare înainte și după instalare pentru a confirma o configurare curată, sigură pentru producție:

• [ ] `yum update -y` finalizat fără erori înainte de instalarea EPEL
• [ ] Depozitul EPEL verificat activ prin `yum repolist | grep epel`
• [ ] `dnf –version` returnează un șir de versiune valid
• [ ] Rezultatul `dnf repolist` corespunde cu rezultatul `yum repolist`
• [ ] `/etc/dnf/dnf.conf` revizuit și ajustat pentru mediul dvs.
• [ ] `installonly_limit` setat pentru a preveni umplerea partiției `/boot`
• [ ] Decizie luată privind strategia alias vs. legătură simbolică vs. coexistență
• [ ] Binarul YUM salvat ca copie de rezervă dacă se folosește abordarea cu legătură simbolică
• [ ] Sarcinile cron și scripturile de automatizare auditate pentru căi `yum` hardcodate
• [ ] Calendarul de migrare EOL CentOS 7 documentat

Întrebări frecvente

Pot DNF și YUM să coexiste pe același sistem CentOS 7 fără conflicte?

Da. Ambele instrumente citesc din `/etc/yum.repos.d/` și mențin directoare de cache separate. Partajează baza de date RPM (`/var/lib/rpm`), astfel că o tranzacție finalizată de unul este imediat vizibilă pentru celălalt. Rularea ambelor simultan (de ex., două instalări concurente) va cauza un conflict de blocare RPM, dar utilizarea secvențială este complet sigură.

Va strica instalarea DNF pe CentOS 7 plugin-urile YUM existente?

Nu. DNF se instalează ca un binar independent și nu modifică instalarea YUM. Plugin-urile YUM existente rămân intacte. Cu toate acestea, DNF nu încarcă plugin-urile YUM — dacă vă bazați pe plugin-uri YUM specifice, trebuie să găsiți și să instalați separat echivalentele lor DNF.

Suportă DNF pe CentOS 7 modulele DNF (fluxuri de module)?

Nu. Fluxurile de module DNF sunt o funcționalitate introdusă în DNF 4 și RHEL/CentOS 8. Versiunea DNF disponibilă prin EPEL pentru CentOS 7 este DNF 4.x, dar suportul pentru fluxuri de module necesită infrastructura depozitului AppStream, care nu există pe CentOS 7.

De ce `dnf update` produce uneori rezultate diferite față de `yum update` pe același sistem?

Rezolvatorul `libsolv` al DNF aplică o logică de dependențe mai strictă și poate rezolva selecțiile de versiuni diferit față de rezolvatorul intern al YUM. În majoritatea cazurilor rezultatul este identic, dar în medii cu dependențe complexe sau conflictuale, DNF poate selecta versiuni diferite de pachete sau poate refuza tranzacții pe care YUM le-ar fi permis în tăcere. Aceasta este o funcționalitate, nu un defect — comportamentul DNF este mai previzibil și mai auditabil.

Este sigur să folosiți DNF pe un server CentOS 7 care găzduiește aplicații web de producție?

Da, cu condiția să folosiți abordarea de coexistență (lăsați YUM intact, folosiți DNF explicit) în loc să înlocuiți binarul YUM. Verificați că orice software de panou de control sau automatizare de implementare de pe serverul dvs. nu are presupuneri hardcodate despre comportamentul YUM înainte de a comuta fluxul de lucru principal la DNF.