Installer DNF sur RHEL/CentOS 7 : Un Guide Technique Complet

DNF (Dandified YUM) est le gestionnaire de paquets de nouvelle génération pour les distributions Linux basées sur RPM, conçu comme un remplacement complet de YUM. Il offre une résolution des dépendances plus rapide grâce à la bibliothèque `libsolv`, une consommation mémoire réduite et une API Python stable. Bien que RHEL/CentOS 7 soit livré avec YUM par défaut, DNF est entièrement installable via le dépôt EPEL et peut fonctionner en parallèle avec YUM — ou comme remplacement transparent — sur le même système.

Ce guide présente le processus d’installation complet, explique les différences architecturales entre YUM et DNF, couvre les cas particuliers réels et vous fournit une référence de commandes prête pour la production.

Pourquoi DNF surpasse YUM sur RHEL/CentOS 7

Avant de toucher au terminal, comprendre *pourquoi* la mise à niveau est importante vous aide à prendre une décision éclairée — en particulier sur un environnement VPS Hosting de longue durée où la fiabilité de la gestion des paquets est critique.

Différences architecturales fondamentales

YUM s’appuie sur un résolveur de dépendances basé sur Python qui présente des problèmes de performances bien documentés avec les grands arbres de dépendances. DNF remplace ce résolveur par `libsolv`, un moteur de résolution de dépendances basé sur un solveur SAT, développé à l’origine par SUSE. Les conséquences pratiques sont significatives :

• Vitesse de résolution des dépendances : DNF résout les chaînes de dépendances complexes en une fraction du temps requis par YUM, ce qui est particulièrement notable lors de la résolution de conflits dans de grands ensembles de paquets.
• Empreinte mémoire : YUM charge l’intégralité des métadonnées du dépôt en mémoire. DNF utilise le chargement différé et met en cache de manière plus agressive, réduisant l’utilisation maximale de la RAM.
• Stabilité de l’API : L’API Python de YUM changeait de manière imprévisible entre les versions mineures. DNF expose une API Python documentée et versionnée sur laquelle les auteurs de plugins peuvent s’appuyer.
• Architecture des plugins : DNF utilise un système de plugins propre basé sur des hooks. Les plugins YUM interfèrent souvent les uns avec les autres en raison d’un couplage lâche.
• Historique des transactions : DNF maintient une base de données d’historique des transactions plus riche, rendant les retours arrière et les audits plus précis.

YUM vs. DNF : Comparaison des fonctionnalités

Prérequis

Avant de procéder, confirmez les éléments suivants :

• Une instance fonctionnelle de RHEL 7 ou CentOS 7 (bare metal, VM ou VPS cloud).
• Accès root ou sudo — toutes les commandes d’installation nécessitent des privilèges élevés.
• Connectivité internet active — le dépôt EPEL doit être accessible.
• Au moins 500 MB d’espace disque libre pour DNF, ses dépendances et le cache des métadonnées du dépôt.

Si vous exécutez une installation minimale de CentOS 7 sur un Serveur Dédié, vérifiez que `curl` et `wget` sont disponibles, car ils sont parfois absents dans les images allégées.

Étape 1 : Mettre à jour les paquets système existants

La synchronisation de votre base de données de paquets avant l’installation de nouveaux logiciels prévient les conflits de versions et garantit que le paquet de version EPEL s’installe correctement par rapport à l’état actuel de votre base de données RPM.

“`bash

sudo yum update -y

“`

Ce que cela fait : Télécharge et applique toutes les mises à jour disponibles pour les paquets actuellement installés, actualise les métadonnées du dépôt et reconstruit le verrou de transaction RPM. Sur un système de production, planifiez cette opération pendant une fenêtre de maintenance — les mises à jour du noyau nécessitent un redémarrage pour prendre effet.

Cas particulier : Si `yum update` échoue avec une erreur `Multilib version problems`, exécutez `sudo yum update –setopt=protected_multilib=false -y` comme solution de contournement ponctuelle, puis examinez les paquets en conflit avant de continuer.

Étape 2 : Activer le dépôt EPEL

DNF n’est pas disponible dans les dépôts de base par défaut de CentOS/RHEL 7. Le dépôt Extra Packages for Enterprise Linux (EPEL), maintenu par le projet Fedora, le fournit.

“`bash

sudo yum install epel-release -y

“`

Vérifiez que le dépôt est actif :

“`bash

yum repolist | grep epel

“`

La sortie attendue doit afficher `epel/x86_64` avec un nombre de paquets non nul (généralement 13 000+). Si le dépôt apparaît désactivé, forcez son activation :

“`bash

sudo yum-config-manager –enable epel

“`

Note de sécurité : Les paquets EPEL sont construits et signés par l’équipe d’infrastructure Fedora. Le paquet `epel-release` installe automatiquement la clé GPG. Vous pouvez vérifier l’empreinte de la clé sur le serveur de clés officiel de Fedora avant de faire confiance aux paquets de ce dépôt — une étape qui vaut la peine d’être effectuée sur les systèmes de production renforcés.

Derrière un proxy ou un pare-feu ? Si votre serveur ne peut pas accéder directement aux miroirs Fedora, configurez `/etc/yum.conf` avec vos paramètres de proxy :

“`ini

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

proxy_username=user

proxy_password=pass

“`

Étape 3 : Installer DNF

Avec EPEL actif, installez DNF et ses dépendances principales en une seule commande :

“`bash

sudo yum install dnf -y

“`

Cela inclut `dnf`, `dnf-data`, `python-dnf`, `libcomps`, `librepo` et `libsolv` comme dépendances automatiques. La taille totale du téléchargement est généralement comprise entre 3 et 8 MB selon ce qui est déjà installé.

Ce qui est installé :

• `dnf` — le binaire principal et l’interface en ligne de commande
• `libsolv` — le résolveur de dépendances basé sur SAT
• `librepo` — la bibliothèque de téléchargement parallèle
• `libcomps` — l’analyseur XML comps pour les groupes de paquets
• `python-dnf` — les liaisons Python et la bibliothèque principale DNF

Étape 4 : Vérifier l’installation

Confirmez que DNF est opérationnel et vérifiez sa version :

“`bash

dnf –version

“`

Une installation réussie produit une sortie similaire à :

“`

4.0.9.2

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

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

“`

Effectuez une vérification plus approfondie en listant les dépôts disponibles tels que vus par DNF :

“`bash

dnf repolist

“`

La sortie doit correspondre à ce que montre `yum repolist`, confirmant que DNF a correctement hérité de votre configuration de dépôt existante depuis `/etc/yum.repos.d/`.

Important : DNF sur CentOS 7 lit les mêmes fichiers `.repo` de dépôt que YUM. Aucune migration de dépôt n’est requise. Les deux outils partagent `/etc/yum.repos.d/` et `/var/cache/` (dans des sous-répertoires séparés).

Étape 5 : Référence des commandes DNF principales

DNF est intentionnellement compatible avec les commandes YUM. Le tableau suivant couvre les opérations que vous utiliserez le plus fréquemment :

Historique des transactions DNF et retour arrière

Il s’agit de l’une des fonctionnalités les plus précieuses opérationnellement de DNF, et l’une que YUM gère mal. Chaque installation, mise à jour ou suppression est enregistrée dans `/var/lib/dnf/history/`. Pour inspecter les transactions récentes :

“`bash

dnf history list

“`

Pour voir exactement ce qui a changé dans une transaction spécifique :

“`bash

dnf history info <transaction-id>

“`

Pour annuler une transaction (par exemple, annuler une mauvaise mise à jour) :

“`bash

sudo dnf history undo <transaction-id>

“`

Cette fonctionnalité est particulièrement utile sur un VPS avec cPanel où une mise à jour de paquet pourrait entrer en conflit avec les dépendances du panneau de contrôle.

Fichier de configuration DNF

La configuration globale de DNF se trouve dans `/etc/dnf/dnf.conf`. Paramètres de réglage clés pour une utilisation en production :

“`ini

[main]

gpgcheck=1

installonly_limit=3

clean_requirements_on_remove=True

best=True

skip_if_unavailable=False

“`

• `installonly_limit=3` — conserve uniquement les 3 dernières versions du noyau, empêchant `/boot` de se remplir.
• `clean_requirements_on_remove=True` — supprime automatiquement les dépendances orphelines lors de la suppression d’un paquet.
• `best=True` — installe toujours la dernière version disponible, générant une erreur au lieu d’effectuer silencieusement une rétrogradation.

Étape 6 : Configurer DNF comme gestionnaire de paquets par défaut

Sur RHEL/CentOS 7, YUM reste le système par défaut. Vous avez deux options pour faire de DNF votre interface principale.

Option A : Alias shell (niveau utilisateur, non destructif)

Ajoutez ce qui suit à `~/.bashrc` (pour l’utilisateur actuel) ou `/etc/bashrc` (à l’échelle du système) :

“`bash

alias yum='dnf'

“`

Appliquez immédiatement :

“`bash

source ~/.bashrc

“`

Limitation : Cet alias s’applique uniquement aux sessions shell interactives. Les scripts qui invoquent `yum` directement via leur chemin absolu (`/usr/bin/yum`) ou qui s’exécutent sous différents utilisateurs (par exemple, tâches cron, unités systemd) ne sont pas affectés.

Option B : Lien symbolique (niveau système)

Pour un remplacement plus complet, créez un lien symbolique qui redirige le binaire `yum` vers `dnf` :

“`bash

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

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

“`

Avertissement critique : Cette approche affecte tous les utilisateurs et tous les scripts à l’échelle du système. Testez soigneusement dans un environnement hors production d’abord. Certains scripts système et outils tiers (y compris certains composants cPanel/WHM) appellent explicitement `/usr/bin/yum` et peuvent se comporter de manière inattendue si le binaire est remplacé. Sauvegardez toujours le binaire original comme indiqué ci-dessus.

Option C : DNF comme plugin YUM (recommandé pour les serveurs)

L’approche la plus propre pour les serveurs de production est de laisser YUM intact et d’utiliser simplement `dnf` explicitement dans vos propres flux de travail et scripts d’automatisation. Cela évite tout risque de casser les outils système tout en vous donnant un accès complet aux capacités de DNF.

Pièges pratiques et cas particuliers

Ce sont des problèmes qui surviennent dans les déploiements réels et qui sont rarement couverts dans les tutoriels de base.

Conflits de clés GPG : Si vous installez des paquets depuis plusieurs dépôts tiers, l’application plus stricte de GPG par DNF (lorsque `gpgcheck=1`) peut rejeter des paquets que YUM acceptait silencieusement auparavant. Importez toujours les clés GPG des dépôts explicitement avec `sudo rpm –import <key-url>`.

Incompatibilité des plugins : Certains plugins YUM (par exemple, `yum-plugin-fastestmirror`) n’ont pas d’équivalent direct dans DNF ou se comportent différemment. DNF dispose de son propre plugin `fastestmirror` (`dnf-plugin-fastestmirror`), mais il n’est pas activé par défaut. Installez-le avec `sudo dnf install python3-dnf-plugin-fastestmirror`.

Divergence de l’emplacement du cache : YUM met en cache les métadonnées dans `/var/cache/yum/`. DNF utilise `/var/cache/dnf/`. Si l’espace disque est limité, les deux caches peuvent coexister et consommer un espace significatif. Exécutez `sudo dnf clean all` et `sudo yum clean all` indépendamment pour récupérer de l’espace.

Gestion des abonnements RHEL : Sur les systèmes RHEL 7 enregistrés (par opposition à CentOS), le plugin `subscription-manager` s’intègre avec YUM. DNF sur RHEL 7 peut ne pas honorer entièrement les dépôts soumis à abonnement sans configuration supplémentaire. Vérifiez avec `subscription-manager repos –list-enabled` après le changement.

Sensibilité à la version Python : DNF sur CentOS 7 utilise les liaisons Python 2 (`python-dnf`). Si vous avez mis à niveau vers Python 3 sur votre système, assurez-vous de ne pas casser involontairement la chaîne de dépendances `python-dnf`. DNF 4+ sur RHEL 8+ utilise Python 3 nativement.

Planification de votre parcours de migration au-delà de CentOS 7

CentOS 7 a atteint sa fin de vie le 30 juin 2024. L’installation de DNF est une amélioration opérationnelle utile, mais elle ne modifie pas la posture de sécurité sous-jacente d’une distribution en fin de vie. Si vous exécutez encore des charges de travail CentOS 7, un plan de migration vers AlmaLinux 8/9, Rocky Linux 8/9 ou RHEL 8/9 devrait figurer dans votre feuille de route. Toutes ces distributions utilisent DNF nativement, rendant la familiarité que vous acquérez maintenant directement transférable.

Pour les équipes gérant plusieurs services sur une infrastructure vieillissante, les Panneaux de contrôle VPS peuvent simplifier considérablement la gestion des environnements parallèles pendant une fenêtre de migration.

Si vos charges de travail incluent des piles d’hébergement web, la migration vers une distribution moderne vous permet également de tirer pleinement parti de l’automatisation des Certificats SSL via Certbot et ACME, qui bénéficie d’un bien meilleur support sur RHEL 8+ et ses dérivés.

Matrice de décision de référence rapide

Utilisez cette liste de contrôle avant et après l’installation pour confirmer une configuration propre et prête pour la production :

• [ ] `yum update -y` terminé sans erreurs avant l’installation d’EPEL
• [ ] Dépôt EPEL vérifié actif via `yum repolist | grep epel`
• [ ] `dnf –version` retourne une chaîne de version valide
• [ ] La sortie de `dnf repolist` correspond à la sortie de `yum repolist`
• [ ] `/etc/dnf/dnf.conf` examiné et ajusté pour votre environnement
• [ ] `installonly_limit` défini pour éviter le débordement de la partition `/boot`
• [ ] Décision prise sur la stratégie alias vs. lien symbolique vs. coexistence
• [ ] Binaire YUM sauvegardé si l’approche par lien symbolique est utilisée
• [ ] Tâches cron et scripts d’automatisation audités pour les chemins `yum` codés en dur
• [ ] Calendrier de migration de fin de vie CentOS 7 documenté

FAQ

DNF et YUM peuvent-ils coexister sur le même système CentOS 7 sans conflits ?

Oui. Les deux outils lisent depuis `/etc/yum.repos.d/` et maintiennent des répertoires de cache séparés. Ils partagent la base de données RPM (`/var/lib/rpm`), donc une transaction effectuée par l’un est immédiatement visible par l’autre. L’exécution simultanée des deux (par exemple, deux installations concurrentes) provoquera un conflit de verrou RPM, mais une utilisation séquentielle est entièrement sûre.

L’installation de DNF sur CentOS 7 cassera-t-elle les plugins YUM existants ?

Non. DNF s’installe comme un binaire indépendant et ne modifie pas l’installation YUM. Vos plugins YUM existants restent intacts. Cependant, DNF ne charge pas les plugins YUM — si vous dépendez de plugins YUM spécifiques, vous devez trouver et installer leurs équivalents DNF séparément.

DNF sur CentOS 7 prend-il en charge les modules DNF (flux de modules) ?

Non. Les flux de modules DNF sont une fonctionnalité introduite dans DNF 4 et RHEL/CentOS 8. La version de DNF disponible via EPEL pour CentOS 7 est DNF 4.x, mais la prise en charge des flux de modules nécessite l’infrastructure du dépôt AppStream, qui n’existe pas sur CentOS 7.

Pourquoi `dnf update` produit-il parfois des résultats différents de `yum update` sur le même système ?

Le résolveur `libsolv` de DNF applique une logique de dépendances plus stricte et peut résoudre les sélections de versions différemment du résolveur interne de YUM. Dans la plupart des cas, le résultat est identique, mais dans les environnements avec des dépendances complexes ou conflictuelles, DNF peut sélectionner des versions de paquets différentes ou refuser des transactions que YUM aurait silencieusement autorisées. Il s’agit d’une fonctionnalité, pas d’un bug — le comportement de DNF est plus prévisible et auditable.

Est-il sûr d’utiliser DNF sur un serveur CentOS 7 qui héberge des applications web en production ?

Oui, à condition d’utiliser l’approche de coexistence (laisser YUM intact, utiliser DNF explicitement) plutôt que de remplacer le binaire YUM. Vérifiez que tout logiciel de panneau de contrôle ou toute automatisation de déploiement sur votre serveur n’a pas d’hypothèses codées en dur sur le comportement de YUM avant de basculer votre flux de travail principal vers DNF.