Administrer les paquets avec DNF

DNF est le gestionnaire de paquets des distributions Red Hat et dérivées (RHEL, AlmaLinux, Rocky Linux, Fedora). Cette page vous apprend à installer, mettre à jour, chercher et supprimer des logiciels avec DNF, puis à revenir en arrière quand une mise à jour casse un service. Chaque action est suivie de sa commande de vérification : sur un serveur, une commande qui « semble » avoir fonctionné ne suffit pas.

Vous verrez aussi où DNF écrit réellement ses journaux (ce n'est pas dans journalctl), comment enchaîner dépôts, groupes et plugins, et ce qui change entre DNF 4 et DNF 5.

Ce que vous allez apprendre

Installer, vérifier et supprimer un paquet, avec le contrôle qui prouve le résultat.
Rechercher le paquet qui fournit un fichier ou une commande précise.
Appliquer les seules mises à jour de sécurité sans embarquer le reste.
Installer un groupe de paquets en maîtrisant ce qui est réellement tiré.
Annuler une transaction ratée grâce à l'historique DNF.
Diagnostiquer un échec en lisant les vrais fichiers de journal de DNF.

Prérequis

Il vous faut une machine sous RHEL 10, AlmaLinux, Rocky Linux ou Fedora, et un compte disposant de sudo. Toutes les commandes qui modifient le système exigent les privilèges root : elles sont préfixées par sudo dans ce guide. Les commandes de simple lecture (search, info, repoquery) fonctionnent sans privilèges.

Si vous découvrez la notion de gestionnaire de paquets, la page Les gestionnaires de paquets Linux pose le vocabulaire commun à DNF, APT et Zypper.

Installer, vérifier, supprimer : la boucle de base

C'est la boucle que vous répéterez tous les jours. Installer un paquet, puis vérifier qu'il est bien présent dans la base RPM, puis le supprimer proprement. L'étape de vérification n'est pas un luxe : DNF peut afficher Complete! alors qu'il a en réalité installé une version différente de celle que vous visiez, ou remplacé un paquet par un autre.

Installez le serveur web nginx :

sudo dnf install nginx

Vérifiez immédiatement le résultat. La première commande interroge la base RPM locale, la seconde affiche le dépôt d'origine (colonne de droite), ce qui vous dit d'où vient réellement le paquet :

rpm -q nginx
dnf list installed nginx

Sur AlmaLinux 10, la sortie confirme la version et le dépôt appstream :

nginx-1.26.3-6.el10_2.5.x86_64
Installed Packages
nginx.x86_64          2:1.26.3-6.el10_2.5          @appstream

Pour supprimer le paquet, utilisez remove. DNF retire aussi les dépendances devenues orphelines, car l'option clean_requirements_on_remove=True est active par défaut sur RHEL. Vérifiez ensuite que la base RPM ne connaît plus le paquet :

sudo dnf remove nginx
rpm -q nginx

La sortie attendue est package nginx is not installed. Un rpm -q qui renvoie encore une version signifie que la suppression a échoué ou qu'un autre paquet réinstalle la dépendance.

Rechercher un paquet avant de l'installer

La moitié du travail consiste à trouver le bon nom de paquet. Trois commandes suffisent, et elles répondent à trois questions différentes. Les confondre fait perdre du temps : search cherche dans les noms et descriptions, provides cherche dans le contenu des paquets, info décrit un paquet déjà identifié.

Quand vous connaissez un mot-clé mais pas le nom exact du paquet :

dnf search apache

Quand vous connaissez un fichier ou une commande et cherchez le paquet qui le livre, c'est provides qu'il vous faut. C'est la commande qui vous sauve quand un script échoue sur un command not found :

dnf provides /usr/bin/python3

La sortie nomme le paquet et le dépôt, ici la base RPM locale (@System) :

python3-3.9.18-1.el9_3.x86_64 : Python 3.9 interpreter
Repo        : @System
Matched from:
Filename    : /usr/bin/python3

Une fois le paquet identifié, info affiche sa version, sa taille, sa licence et son dépôt avant que vous ne l'installiez :

dnf info nginx

Pour aller plus loin, repoquery interroge les métadonnées des dépôts sans rien installer. Deux usages reviennent en administration : savoir qui dépend d'une bibliothèque avant de la supprimer, et distinguer ce que vous avez explicitement installé de ce qui est arrivé en dépendance.

dnf repoquery --whatrequires zlib
dnf repoquery --userinstalled

Mettre à jour le système sans tout casser

Sur DNF, update et upgrade sont deux noms de la même commande. Aucune différence de comportement, contrairement à ce que la mémoire d'APT pourrait vous suggérer. Les deux mettent à jour tous les paquets disponibles :

sudo dnf upgrade

Sur un serveur, vous voulez souvent geler le noyau ou un applicatif métier pendant que le reste avance. L'option --exclude accepte un joker, à condition de le protéger des interprétations du shell par des guillemets simples :

sudo dnf --exclude='kernel*' upgrade

Le cas le plus fréquent en production reste la mise à jour de sécurité seule. Commencez par un état des lieux : updateinfo summary compte les avis de sécurité en attente et les classe par gravité.

dnf updateinfo summary

Sur une AlmaLinux 10 fraîche, la sortie donne immédiatement l'ampleur du retard :

Updates Information Summary: available
    10 Security notice(s)
         2 Important Security notice(s)
         6 Moderate Security notice(s)
         2 Low Security notice(s)

Listez ensuite le détail des avis, puis n'appliquez que ceux-là. Les correctifs de sécurité passent, les nouvelles fonctionnalités attendent la prochaine fenêtre de maintenance :

dnf updateinfo list security
sudo dnf upgrade --security

Certains services continuent de tourner avec l'ancienne bibliothèque chargée en mémoire après une mise à jour. La commande needs-restarting vous le dit, et son option -r répond à la seule question qui compte : faut-il redémarrer la machine ?

dnf needs-restarting -r

La sortie est explicite et constitue votre vérification post-mise à jour :

No core libraries or services have been updated since boot-up.
Reboot should not be necessary.

Installer un groupe de paquets

Un groupe est un ensemble cohérent de paquets livré sous un nom unique, par exemple une chaîne de compilation complète. C'est un gain de temps réel, mais c'est aussi la fonction la plus mal comprise de DNF, parce que tous les paquets d'un groupe ne sont pas égaux.

Listez d'abord les groupes réellement disponibles sur votre système. Ne devinez pas leur nom : DNF refuse tout groupe qu'il ne connaît pas.

dnf group list

Sur AlmaLinux 10, vous obtenez des groupes d'environnement (Server, Minimal Install, Workstation) et des groupes classiques (Development Tools, Container Management, Headless Management, RPM Development Tools).

Avant d'installer, inspectez le contenu du groupe. C'est ici que se joue tout le malentendu : DNF classe les paquets en trois catégories.

dnf group info "Development Tools"

La sortie sépare explicitement les paquets obligatoires (Mandatory), les paquets par défaut (Default) et les paquets optionnels (Optional) :

Group: Development Tools
 Description: A basic development environment.
 Mandatory Packages:
   autoconf
   automake
   gcc
   make
   ...
 Default Packages:
   git
   valgrind
   ...
 Optional Packages:
   cmake
   expect

Retenez la règle : dnf group install installe les paquets obligatoires et les paquets par défaut, mais PAS les paquets optionnels. Pour les inclure, il faut l'option --with-optional.

sudo dnf group install "Development Tools"
sudo dnf group install "Development Tools" --with-optional

L'écart est mesurable. Sur Rocky Linux 9, la première commande annonce Install 282 Packages et ne tire ni cmake ni expect ; la seconde annonce Install 321 Packages et les inclut. Vérifiez ensuite que le groupe est bien marqué comme installé :

dnf group list --installed

La suppression d'un groupe suit la même logique. Elle retire les paquets du groupe, mais conserve ceux qui sont encore requis par d'autres logiciels, ce qui évite de casser le système :

sudo dnf group remove "Development Tools"

Gérer les dépôts

Un dépôt est une source de paquets. Un serveur RHEL en connaît quelques-uns par défaut (baseos, appstream, extras), et vous en ajouterez pour les logiciels tiers. Commencez toujours par regarder ce qui est actif, car un paquet introuvable vient neuf fois sur dix d'un dépôt désactivé.

dnf repolist

Pour voir aussi les dépôts désactivés, ajoutez all. La colonne d'état vous indique lesquels sont enabled ou disabled :

dnf repolist all

Le dépôt CRB (CodeReady Builder), qui contient les bibliothèques de développement, est un exemple classique de dépôt livré mais désactivé. Activez-le avec le plugin config-manager, puis vérifiez qu'il apparaît bien dans la liste des dépôts actifs :

RHEL 9 / 10 (DNF 4)
Fedora (DNF 5)

sudo dnf config-manager --set-enabled crb
dnf repolist | grep crb

sudo dnf config-manager enable crb
dnf repolist | grep crb

La sortie attendue confirme l'activation :

crb                              AlmaLinux 10 - CRB

Pour ajouter un dépôt tiers, créez un fichier .repo dans /etc/yum.repos.d/, le répertoire où RHEL stocke la définition de ses sources de paquets. Le nom du fichier importe peu, l'identifiant entre crochets est celui que vous manipulerez ensuite.

[monitoring-interne]
name=Depot de supervision interne
baseurl=http://repo.interne.lan/monitoring/el10/
enabled=1
gpgcheck=1
gpgkey=http://repo.interne.lan/monitoring/RPM-GPG-KEY-monitoring

La directive gpgcheck=1 est la ligne la plus importante du fichier : elle impose la vérification de la signature de chaque paquet. Un dépôt sans gpgcheck accepte n'importe quel RPM modifié en transit. Vérifiez que DNF voit bien le nouveau dépôt avant de vous en servir :

dnf repolist | grep monitoring-interne

Enfin, vous pouvez ignorer ponctuellement un dépôt pour une seule commande, sans rien modifier durablement. C'est utile pour forcer l'origine d'un paquet :

sudo dnf install nginx --disablerepo=epel

Les plugins : ce qui n'est pas livré par défaut

Plusieurs commandes présentées comme « DNF » ne sont pas dans DNF. Ce sont des plugins, regroupés dans le paquet dnf-plugins-core. Sur une image minimale Rocky 9, ce paquet est absent, et les commandes échouent avec un message trompeur :

No such command: config-manager. Please use /usr/bin/dnf --help
It could be a DNF plugin command, try: "dnf install 'dnf-command(config-manager)'"

Ce message ne signifie pas que la commande n'existe pas : il signifie que le plugin n'est pas installé. Les trois commandes concernées sont config-manager (gestion des dépôts), needs-restarting (services à redémarrer) et download (téléchargement sans installation).

sudo dnf install dnf-plugins-core
rpm -q dnf-plugins-core

Sur AlmaLinux 10, ces plugins sont déjà présents via python3-dnf-plugins-core : les commandes fonctionnent sans rien installer. Sur une Rocky 9 minimale ou un conteneur, il faut les ajouter. Testez plutôt que de supposer.

Le plugin download récupère un RPM dans le répertoire courant sans l'installer. C'est la base des déploiements en environnement isolé (air gap), où la machine cible n'a aucun accès aux dépôts :

dnf download nginx
ls nginx-*.rpm

Configurer DNF

Le fichier /etc/dnf/dnf.conf contrôle le comportement global. Sur AlmaLinux 10, sa configuration par défaut tient en cinq lignes, et elle est déjà saine :

[main]
gpgcheck=1
installonly_limit=3
clean_requirements_on_remove=True
best=True
skip_if_unavailable=False

Notez que best=True est déjà actif par défaut sur RHEL : DNF cherche toujours la meilleure version disponible. Passer --best en ligne de commande est donc redondant sur cette famille de distributions. De même, installonly_limit=3 conserve les trois derniers noyaux, ce qui vous garantit un noyau de secours au démarrage.

Trois réglages valent la peine d'être ajoutés, car ils ne sont pas activés par défaut. Vous pouvez vérifier leur valeur courante avec dnf config-manager --dump :

max_parallel_downloads=10
fastestmirror=True
keepcache=True

max_parallel_downloads vaut 3 par défaut et peut monter à 10 (maximum accepté par DNF) : c'est le gain le plus visible sur une mise à jour massive. fastestmirror (désactivé par défaut) classe les miroirs par latence. keepcache (désactivé par défaut) conserve les RPM téléchargés, utile si vous devez rejouer une installation ou alimenter un cache local.

Automatiser les mises à jour

Sur un parc de serveurs, appliquer les correctifs de sécurité à la main ne tient pas. dnf-automatic fait ce travail via un timer systemd. Attention à une confusion fréquente : ce n'est pas un composant de dnf-plugins-core, c'est un paquet distinct à installer explicitement.

sudo dnf install dnf-automatic
rpm -q dnf-automatic

Le comportement se règle dans /etc/dnf/automatic.conf. Par défaut, RHEL 10 télécharge les mises à jour mais ne les applique pas (apply_updates = no) et ne redémarre jamais (reboot = never). C'est un choix prudent que vous devez modifier en conscience :

[commands]
upgrade_type = security
download_updates = yes
apply_updates = yes
reboot = never

[emitters]
emit_via = stdio

Ici, upgrade_type = security restreint l'automatisation aux seuls correctifs de sécurité, ce qui est le réglage le plus défendable sur un serveur de production. Activez ensuite le timer, puis vérifiez qu'il est bien armé et quand il se déclenchera :

sudo systemctl enable --now dnf-automatic.timer
systemctl list-timers dnf-automatic.timer

Le timer dnf-automatic.timer se déclenche à 06h00 (OnCalendar=*-*-* 6:00) avec une temporisation aléatoire. Des variantes existent selon l'intention : dnf-automatic-download.timer (télécharger seulement), dnf-automatic-install.timer (installer) et dnf-automatic-notifyonly.timer (notifier sans rien faire). Sur Fedora, le paquet s'appelle dnf5-plugin-automatic.

Revenir en arrière avec l'historique

C'est la fonction qui distingue DNF d'un simple installateur, et celle qui vous sauvera un jour. DNF enregistre chaque transaction dans une base et sait la rejouer à l'envers. Après une mise à jour qui casse un service, vous n'êtes pas condamné à réinstaller la machine.

Listez les transactions. Chacune porte un identifiant (ID), la commande lancée, la date et le nombre de paquets touchés :

dnf history list

Sur AlmaLinux 10, la sortie ressemble à ceci :

ID     | Command line             | Date and time    | Action(s)      | Altered
-------------------------------------------------------------------------------
     4 | -y install nginx         | 2026-07-12 08:30 | Install        |    5 EE
     3 | -y install dnf-plugins-c | 2026-07-12 08:30 | Install        |    1

Avant d'annuler quoi que ce soit, inspectez la transaction concernée. La commande affiche l'utilisateur, le code de retour et la liste exacte des paquets modifiés :

dnf history info 4

Puis annulez-la. undo inverse la transaction : ce qui a été installé est supprimé, ce qui a été mis à jour est rétrogradé à sa version précédente. Vérifiez ensuite l'état réel du paquet :

sudo dnf history undo 4
rpm -q nginx

Quand une seule version pose problème, downgrade suffit et évite de toucher au reste de la transaction. La réinstallation répare de son côté un paquet dont les fichiers ont été corrompus, sans écraser vos fichiers de configuration personnalisés :

sudo dnf downgrade nginx
sudo dnf reinstall nginx

Où DNF écrit ses journaux

Point de vigilance majeur, et erreur très répandue sur le web : DNF ne journalise pas dans journalctl. Il n'existe aucune unité dnf.service. Une commande comme journalctl -u dnf ne renvoie donc rien du tout, et vous fait croire à tort qu'aucun événement n'a été enregistré.

La preuve tient en une commande. Les seules unités systemd liées à DNF concernent le cache et l'automatisation, jamais DNF lui-même :

systemctl list-unit-files | grep -i dnf

dnf-automatic.service                  static   -
dnf-makecache.service                  static   -
dnf-makecache.timer                    enabled  enabled

DNF écrit dans des fichiers plats, sous /var/log/. Trois fichiers vous intéressent, et ils répondent à des questions différentes :

Fichier	Contenu	Quand le lire
`/var/log/dnf.log`	Déroulé complet de DNF, résolution de dépendances, plugins	Une commande échoue ou se comporte bizarrement
`/var/log/dnf.rpm.log`	Actions RPM réelles : `Installed`, `Upgraded`, `Erased`	Savoir ce qui a vraiment changé sur le disque
`/var/log/dnf.librepo.log`	Téléchargements, miroirs, erreurs réseau	Un dépôt est injoignable ou lent

Pour suivre une installation en direct ou comprendre un échec récent, ouvrez le journal principal. Sur Fedora (DNF 5), le fichier s'appelle /var/log/dnf5.log et remplace les précédents :

sudo tail -f /var/log/dnf.log
sudo grep -iE 'error|fail' /var/log/dnf.log

Le journal dnf.rpm.log est le plus lisible pour un audit : chaque ligne dit ce qui a été installé, mis à jour ou supprimé, avec la version exacte.

sudo tail -5 /var/log/dnf.rpm.log

SUBDEBUG Upgrade: openssl-1:3.5.5-4.el9_8.x86_64
SUBDEBUG Upgraded: openssl-1:3.0.7-24.el9.x86_64

DNF 4 et DNF 5 : ce qui change

Une confusion circule beaucoup : RHEL 10 n'est pas passé à DNF 5. Sur AlmaLinux 10.2, dnf --version renvoie 4.20.0 et le binaire réel est /usr/bin/dnf-3. C'est Fedora qui a basculé sur DNF 5 (dnf5), avec des options réécrites. Écrire vos scripts en syntaxe DNF 4 reste donc le bon choix pour le parc RHEL.

Voici les divergences qui cassent réellement un script, toutes vérifiées en conteneur :

Besoin	DNF 4 (RHEL 9 et 10)	DNF 5 (Fedora)
Activer un dépôt	`dnf config-manager --set-enabled crb`	`dnf config-manager enable crb`
Lister les avis de sécurité	`dnf updateinfo list security`	`dnf advisory list --security`
Journal principal	`/var/log/dnf.log` + `dnf.rpm.log`	`/var/log/dnf5.log`
Plugins `download`, `needs-restarting`	Paquet `dnf-plugins-core`	Intégrés au binaire
`--no-packages` sur un groupe	N'existe pas (erreur)	Marque le groupe sans installer
Mises à jour automatiques	Paquet `dnf-automatic`	Paquet `dnf5-plugin-automatic`

Une autre différence structurante concerne la modularité (les AppStream modules, qui permettaient de choisir la version majeure d'un langage). Sur Rocky 9, dnf module list affiche des flux comme mariadb 10.11 ou maven 3.8. Sur AlmaLinux 10, la même commande ne renvoie aucun module : la modularité a été retirée de RHEL 10. Ne construisez plus de procédure autour de dnf module enable.

Sécurité et points de vigilance

La signature GPG est votre seule garantie qu'un RPM n'a pas été modifié entre le dépôt et votre serveur. Elle est active par défaut (gpgcheck=1), et l'option --nogpgcheck la désactive. Traitez cette option comme un dernier recours de laboratoire : une erreur de signature signale soit un dépôt mal configuré, soit un paquet compromis, et les deux méritent une enquête, pas un contournement.

L'option --allowerasing est le second piège. Elle autorise DNF à supprimer des paquets pour résoudre un conflit, et elle peut désinstaller un composant dont un service dépend. Lancez toujours la commande sans -y d'abord, et lisez la section Removing du récapitulatif avant de valider :

sudo dnf install nginx --allowerasing

Enfin, dnf autoremove supprime les dépendances orphelines. La commande réduit la surface d'attaque, mais elle est agressive : sur un système où des paquets ont été installés à la main, elle peut retirer des bibliothèques encore utilisées par un binaire hors RPM. Inspectez la liste proposée avant de confirmer :

sudo dnf autoremove

Le nettoyage du cache, lui, est sans risque. Il libère de l'espace et force le rechargement des métadonnées, ce qui résout la plupart des « paquet introuvable » alors qu'il existe :

sudo dnf clean all
sudo dnf makecache

Dépannage

Voici les symptômes que vous rencontrerez le plus souvent, et la manière de les lever. Le réflexe commun à presque tous : rafraîchir les métadonnées avant de chercher plus loin.

Symptôme	Cause probable	Solution
`No match for argument: <paquet>` alors que le paquet existe	Métadonnées périmées ou dépôt désactivé	`sudo dnf clean all && sudo dnf makecache`, puis `dnf repolist all`
`No such command: config-manager`	Plugin absent	`sudo dnf install dnf-plugins-core`
`Warning: Group Web Server does not exist`	Groupe inexistant sur RHEL 9 et 10	`dnf group list` pour lire les vrais noms
`journalctl -u dnf` ne renvoie rien	Aucune unité `dnf.service` n'existe	Lire `/var/log/dnf.log` et `/var/log/dnf.rpm.log`
Conflit de dépendances au `upgrade`	Versions incohérentes entre dépôts	`sudo dnf distro-sync`, sinon `--allowerasing` après lecture du récapitulatif
`GPG check FAILED`	Clé du dépôt absente ou paquet altéré	Importer la bonne clé (`gpgkey=`) ; ne pas contourner avec `--nogpgcheck`
Un service tourne encore avec l'ancienne bibliothèque	Processus non redémarré après mise à jour	`dnf needs-restarting -r` puis redémarrer le service concerné

La commande dnf distro-sync mérite une mention à part. Elle aligne toutes les versions installées sur ce que proposent les dépôts, quitte à rétrograder des paquets. C'est l'outil de sortie de crise après un mélange de dépôts tiers :

sudo dnf distro-sync
dnf repoquery --duplicates

Mettre en pratique

Les commandes DNF s'oublient si elles ne passent pas par les doigts. Deux labs couvrent ce guide : le premier vous fait déclarer un dépôt dans un fichier .repo avec gpgcheck et le valider dans dnf repolist ; le second déroule la boucle installer, interroger et supprimer des paquets, vérification RPM à chaque étape.

Configurer un dépôt dnf avec un fichier .repo

$ dsoxlab run l2-repo-configure

Environnement : VM·Durée : ~20 min

Validé : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

dsoxlab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Installer la CLI dsoxlab, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
git clone https://github.com/stephrobert/linux-dsoxlab-training.git
cd linux-dsoxlab-training

Lancer ce lab, puis valider votre travail :

dsoxlab run l2-repo-configure
dsoxlab check l2-repo-configure

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress.

Installer, supprimer et interroger des paquets avec dnf

$ dsoxlab run l2-package-management

Environnement : VM·Durée : ~20 min

Validé : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

Installer la CLI dsoxlab, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
git clone https://github.com/stephrobert/linux-dsoxlab-training.git
cd linux-dsoxlab-training

Lancer ce lab, puis valider votre travail :

dsoxlab run l2-package-management
dsoxlab check l2-package-management

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

Le chronomètre démarre au clic sur Démarrer
Questions à choix multiples, vrai/faux et réponses courtes
Vous pouvez naviguer entre les questions
Les résultats détaillés sont affichés à la fin

À retenir

update et upgrade sont identiques sur DNF ; l'option --security est la seule qui compte vraiment sur un serveur de production.
dnf group install n'installe pas les paquets optionnels. Il prend les mandatory et les default ; il faut --with-optional pour le reste (282 paquets contre 321 sur Development Tools).
L'option --no-packages n'existe pas en DNF 4, et en DNF 5 elle marque le groupe sans installer les paquets. Ce n'est pas un mode « minimal ».
DNF ne journalise pas dans systemd. Aucune unité dnf.service n'existe : les journaux sont dans /var/log/dnf.log, /var/log/dnf.rpm.log et /var/log/dnf.librepo.log (ou dnf5.log sur Fedora).
dnf history undo <ID> annule une transaction ratée. C'est votre filet de sécurité : inspectez d'abord avec dnf history info <ID>.
config-manager, needs-restarting et download sont des plugins livrés par dnf-plugins-core, absents d'une installation minimale.
RHEL 10 utilise toujours DNF 4 (4.20). DNF 5 est la voie Fedora, avec une syntaxe différente pour les dépôts et les avis de sécurité.
La modularité a disparu de RHEL 10 : dnf module ne renvoie plus rien, ne bâtissez plus de procédure dessus.

Administrer les paquets avec DNF

Ce que vous allez apprendre

Prérequis

Installer, vérifier, supprimer : la boucle de base

Rechercher un paquet avant de l'installer

Mettre à jour le système sans tout casser

Installer un groupe de paquets

Gérer les dépôts

Les plugins : ce qui n'est pas livré par défaut

Configurer DNF

Automatiser les mises à jour

Revenir en arrière avec l'historique

Où DNF écrit ses journaux

DNF 4 et DNF 5 : ce qui change

Sécurité et points de vigilance

Dépannage

Mettre en pratique

Contrôle de connaissances

Contrôle de connaissances

Informations

Vérification

Profil de compétences

Quoi faire maintenant

À retenir