Rocky AlmaLinux : activer EPEL et CRB avec dnf

Pourquoi dnf ne trouve pas le paquet voulu

EPEL et CRB sont les deux dépôts qu’un serveur Rocky Linux ou AlmaLinux fraîchement installé n’active pas par défaut. C’est pourquoi dnf install htop sur une nouvelle machine renvoie No match for argument: htop, puis Error: Unable to find a match: htop. Rien n’est défectueux et aucun miroir n’est hors service. La distribution de base fournit volontairement un nombre limité de paquets. CRB est présent, mais désactivé, et EPEL est un dépôt communautaire distinct que vous devez ajouter.

Sur Ubuntu, le même paquet se trouve dans universe, et universe est activé sur presque toutes les images cloud. La question ne se pose donc jamais. La famille Red Hat répartit ses paquets différemment et en active moins par défaut. La correction tient en trois commandes. Le reste de ce guide est le point que personne ne vous explique pendant la première semaine : ce que ces dépôts garantissent, ce qu’ils ne garantissent pas et comment empêcher un dépôt tiers de prendre discrètement le contrôle de votre système de base.

Comment ces commandes ont été vérifiées. Nos conteneurs de test exécutent uniquement Ubuntu. Les commandes dnf ci-dessous n’ont donc pas été exécutées sur nos propres machines de test. Elles suivent la documentation de Rocky Linux et d’AlmaLinux. Chaque étape indique la sortie que vous devez obtenir. Vérifiez donc chaque étape sur votre propre serveur au lieu de coller tout le bloc en une seule fois.

Que sont BaseOS, AppStream et CRB ?

BaseOS est le système d’exploitation lui-même : le kernel, glibc, systemd et l’espace utilisateur de base. Les versions de ces composants restent figées pendant toute la durée de vie de la version majeure, et les correctifs de sécurité sont rétroportés dans ces versions figées. Un numéro de version qui semble ancien dans BaseOS ne signifie pas que le paquet n’est pas corrigé. Il s’agit d’une ancienne version corrigée, ce qui constitue précisément le principe d’une distribution d’entreprise.

AppStream contient les composants que vous exécutez par-dessus le système : serveurs web, bases de données, environnements d’exécution de langages, éditeurs et agents de supervision. Dans la version 8, une grande partie d’AppStream était fournie sous forme de modules avec des streams alternatifs. dnf module list était donc important et vous deviez choisir, par exemple, un stream PHP. La version 9 a supprimé presque toute la modularité. Sur Rocky 9 et Alma 9, vous obtenez donc généralement une seule version d’un composant, sans module à activer au préalable.

Extras est activé par défaut et reste très limité. Il contient principalement les paquets de release d’autres dépôts. C’est de là que vient epel-release. C’est pourquoi vous n’avez jamais besoin de faire confiance à une URL aléatoire pour installer EPEL sur Rocky ou Alma.

CRB est le dépôt CodeReady Builder, appelé PowerTools dans la version 8. Il contient les composants nécessaires à la construction des paquets : en-têtes de développement, bibliothèques statiques, ainsi que les outils de test et de documentation requis lors de la construction. Il est déjà présent sur le mirror, mais désactivé par défaut. Dans le produit Red Hat lui-même, le même contenu s’appelle CodeReady Linux Builder. Il est inclus dans l’abonnement, et Red Hat précise qu’il n’est pas couvert par le support. Rocky et Alma héritent à la fois de ce contenu et de cette désactivation par défaut.

Pour les lecteurs venant de Debian ou d’Ubuntu : main regroupe les paquets d’exécution et les en-têtes -dev dans une même archive. Il n’y a donc pas de CRB à activer. L’équivalent le plus proche d’EPEL est universe, qui est maintenu par la communauté et ne s’accompagne d’aucun engagement de support de la part d’un éditeur.

Ce qu’est EPEL et qui le maintient

EPEL signifie Extra Packages for Enterprise Linux. Il s’agit d’un projet Fedora : des paquets présents dans Fedora, reconstruits pour la version Enterprise actuelle et maintenus par l’EPEL Special Interest Group, principalement composé de bénévoles de la communauté Fedora. Red Hat héberge l’infrastructure de build et de mirror, et certains ingénieurs Red Hat y maintiennent des paquets. La relation s’arrête là. EPEL n’est pas un produit Red Hat. Aucun contrat de support ni SLA (service level agreement) ne couvre un paquet EPEL, que vous l’utilisiez sur RHEL ou sur une reconstruction.

Une règle permet d’activer EPEL sans remplacer les paquets de la distribution de base : un paquet EPEL ne doit jamais remplacer un paquet fourni par la distribution de base. Si AppStream fournit nginx, EPEL ne le fournira pas. Cette règle est appliquée par les personnes qui examinent les paquets EPEL. Elle constitue donc un engagement limité à EPEL. Elle ne vous protège contre rien d’autre que vous ajouteriez par la suite.

La garantie de durée de maintenance diffère également de celle de la distribution de base. C’est souvent au cours de la troisième année que ce point pose problème. La version d’un paquet BaseOS reste figée pendant toute la durée de vie de dix ans de la version majeure. Un mainteneur EPEL s’engage sur une période bien plus courte : au moins une version mineure de RHEL ou 13 mois, selon la période la plus courte. En pratique, la plupart des paquets sont maintenus bien plus longtemps. Certains sont retirés lorsque leur mainteneur passe à autre chose. D’autres passent à une nouvelle version majeure pendant la durée de vie de votre distribution, car EPEL suit Fedora. Ainsi, un simple dnf upgrade peut installer une nouvelle version majeure d’un outil EPEL sur une machine que vous pensiez stable. Un paquet dont vous dépendez peut aussi cesser de recevoir des mises à jour sans annonce qui vous parvienne.

Une autre conséquence doit être connue avant l’activation d’EPEL : EPEL est construit pour la version mineure la plus récente de RHEL. Si vous maintenez un serveur sur une version mineure plus ancienne, avec un mirror figé ou un repository de version ponctuelle fourni par le vendor, un paquet EPEL peut nécessiter une bibliothèque de base plus récente que celle dont vous disposez. dnf signale alors une dépendance manquante. Le problème ressemble à un problème de mirror, alors qu’il s’agit en réalité d’un décalage de versions.

Activer CRB et installer EPEL sur Rocky ou Alma

sudo dnf install -y dnf-plugins-core
sudo dnf config-manager --set-enabled crb
sudo dnf install -y epel-release
sudo dnf makecache
dnf repolist --enabled

dnf repolist --enabled doit maintenant afficher baseos, appstream, extras, crb et epel. Vous pouvez également voir une petite entrée epel-cisco-openh264, ajoutée par epel-release. Si crb ne figure pas dans cette liste, l’activation n’a pas fonctionné. La section suivante en explique la raison.

Sur Rocky 8 et Alma 8, le dépôt s’appelle encore PowerTools. La commande intermédiaire devient donc sudo dnf config-manager --set-enabled powertools. Les identifiants de dépôts sont sensibles à la casse. Les anciennes documentations CentOS 8 l’écrivent PowerTools avec des majuscules, ce qui ne correspondra pas. Sur AlmaLinux 10, le dépôt CRB est activé par défaut à partir de 10.0, depuis la modification de septembre 2025. Dans ce cas, seule l’étape epel-release est nécessaire.

epel-release provient de extras, qui est déjà activé. Il n’y a donc aucune URL à approuver ni aucune clé à importer manuellement. Le paquet écrit /etc/yum.repos.d/epel.repo et installe la clé de signature EPEL dans /etc/pki/rpm-gpg/. Confirmez gpgcheck=1 dans ce fichier et ignorez tout guide qui vous demande de contourner une erreur de signature avec --nogpgcheck. Un échec de la vérification de signature signifie que le paquet n’est pas celui qu’il prétend être ou que l’horloge du système est incorrecte.

Sur Rocky, epel-release installe également un petit helper dans /usr/bin/crb. sudo crb enable et crb status effectuent donc la même tâche sans le plugin. Vérifiez sa présence avec command -v crb avant de vous y fier, car il n’est pas présent dans toutes les branches de toutes les rebuilds.

Pour vérifier qu’EPEL est accessible et pas seulement répertorié, demandez-lui un paquet qu’il est le seul à fournir :

dnf repoquery --repo=epel htop

Cette commande affiche le nom, la version et l’architecture du paquet. L’absence de sortie signifie que le dépôt est activé, mais qu’il ne renvoie rien. Il s’agit généralement d’un problème de mirror ou de metadata plutôt que d’un problème de configuration. Essayez donc sudo dnf clean all && sudo dnf makecache.

Pourquoi dnf indique « no such command: config-manager »

C’est le premier point qui pose problème. Cela se produit précisément avec les images que fournissent la plupart des hébergeurs VPS.

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)'"

config-manager est un plugin, et non une sous-commande intégrée à dnf. Il est fourni dans dnf-plugins-core. Une installation complète du serveur l’installe généralement, contrairement aux images minimales, aux images cloud et aux images de conteneur. La suggestion de dnf fonctionne, car le paquet déclare cette capacité virtuelle :

sudo dnf install -y 'dnf-command(config-manager)'

Utilisez-la entre guillemets. Les parenthèses correspondent à la syntaxe du shell. Sans guillemets, la commande échoue avec une erreur de syntaxe, et non avec une erreur de dnf.

Si vous ne pouvez pas installer le plugin parce que le dépôt dont vous avez besoin est désactivé, modifiez directement le fichier. Identifiez le fichier qui contient la section, ouvrez-le, puis définissez enabled=1 sous [crb] :

grep -rl crb /etc/yum.repos.d/

C’est exactement ce que config-manager écrit. Vous ne perdez donc rien en effectuant la modification manuellement. dnf repolist --enabled confirme le résultat.

Certains paquets EPEL ne s’installent pas tant que CRB n’est pas activé

Le deuxième piège courant produit une erreur qui ne mentionne jamais CRB. Un paquet EPEL qui dépend d’une bibliothèque fournie uniquement par CRB échoue lors de la résolution des dépendances. Le message indique le nom de la bibliothèque et du paquet qui la requiert :

Error:
 Problem: conflicting requests
  - nothing provides libexample.so.0()(64bit) needed by examplepkg-1.4-2.el9.x86_64 from epel

La cause est que CRB est désactivé. dnf ne peut donc pas accéder au seul dépôt qui fournit cette bibliothèque. Vérifiez les deux points dans l’ordre :

dnf repolist --enabled
dnf --enablerepo=crb repoquery --whatprovides 'libexample.so.0()(64bit)'

Si la deuxième commande indique un paquet alors que l’installation simple échoue toujours, CRB est désactivé. Ce type d’erreur est suffisamment courant pour qu’AlmaLinux active CRB par défaut dans la version 10, afin d’éviter ce problème. --enablerepo=crb fonctionne également comme option ponctuelle pour une seule installation, mais laissez CRB activé en permanence si vous utilisez EPEL, car la prochaine mise à jour EPEL peut introduire une nouvelle dépendance CRB sans vous en avertir au préalable.

De quel dépôt ce paquet provient-il ?

Après quelques semaines avec quatre dépôts activés, la question utile n’est plus de savoir ce qui est installé, mais d’où cela provient.

dnf repolist --all
dnf info htop
dnf repoquery --installed --qf '%{from_repo} %{name}' | sort | uniq -c | sort -rn
dnf repository-packages epel list installed

dnf info sur un paquet installé affiche une ligne From repo. dnf list installed présente la même information dans sa troisième colonne, précédée de @. Ainsi, @epel signifie que le paquet a été installé depuis EPEL, tandis que @System signifie que dnf ne sait pas d’où il provient. Cela indique généralement que quelqu’un a exécuté rpm -i sur un fichier téléchargé. La ligne repoquery indique le nombre de paquets par dépôt. C’est le moyen le plus rapide de découvrir qu’un serveur dont vous avez hérité contient quarante paquets provenant d’un dépôt dont vous n’avez jamais entendu parler. La dernière commande liste précisément ce qu’un dépôt vous a fourni. Cet inventaire est nécessaire avant de décider de le supprimer.

Avec apt, on utilise apt-cache policy <package>. Les équivalents des commandes dnf et apt méritent de rester ouverts dans un deuxième onglet pendant le premier mois. Les concepts correspondent bien, même lorsque les options diffèrent.

Comment empêcher un dépôt tiers de remplacer un paquet de base ?

EPEL garantit qu’il ne le fera pas. Aucun autre dépôt ne le garantit. Le dépôt d’un fournisseur pour une base de données, un agent ou un runtime peut fournir sa propre version d’une bibliothèque également fournie par BaseOS. dnf l’installera, car sa règle par défaut est simple : la version la plus récente l’emporte, quelle que soit son origine.

Deux contrôles couvrent l’essentiel du problème. Ils se trouvent tous les deux dans le fichier du dépôt sous /etc/yum.repos.d/.

priority= détermine quel dépôt l’emporte lorsque plusieurs dépôts proposent le même nom de paquet. Les valeurs les plus basses sont prioritaires et la valeur par défaut est 99. Attribuez donc une valeur basse à vos dépôts de base et une valeur élevée à tout dépôt tiers. dnf choisira alors le paquet de base même si la version du dépôt tiers est plus récente. Les versions modernes de dnf gèrent cela directement. Le paquet distinct yum-plugin-priorities de l’époque de CentOS 7 ne fait donc plus partie de la solution.

includepkgs= est l’option de filtrage la plus stricte. excludepkgs= bloque certains paquets nommés dans un dépôt, ce qui vous oblige à prévoir ceux qu’il pourrait fournir. includepkgs= inverse le comportement : ce dépôt peut fournir ces noms, et rien d’autre. Pour un dépôt fournisseur qui ne doit fournir que son propre agent, une seule ligne suffit.

[vendor-tools]
name=Vendor tools for EL9
baseurl=https://packages.example.com/el9/x86_64/
enabled=1
gpgcheck=1
gpgkey=https://packages.example.com/RPM-GPG-KEY-vendor
priority=90
includepkgs=vendor-agent,vendor-agent-plugins

Avec la version 8, il faut connaître un paramètre supplémentaire. Un paquet provenant d’un dépôt tiers peut être masqué lorsqu’un module AppStream fournit le même nom. Le paramètre module_hotfixes=1, dans la section de ce dépôt, indique à dnf de ne plus appliquer ce filtrage. Si un paquet est visible avec dnf repoquery mais refuse de s’installer sur un système en version 8, c’est généralement la cause. La version 9 a supprimé presque tous les modules, ce cas y est donc rare.

Pour limiter un paquet à une version donnée, installez python3-dnf-plugin-versionlock et utilisez sudo dnf versionlock add <package>. C’est l’équivalent de apt-mark hold. Notez une inversion qui surprend les utilisateurs venant de Debian : dans apt, la valeur Pin-Priority la plus élevée l’emporte, tandis que dans dnf, c’est la valeur priority la plus basse.

Pourquoi le mélange de dépôts proches de RHEL rend un serveur impossible à mettre à niveau

Rocky, Alma, CentOS Stream, Oracle Linux et RHEL sont suffisamment proches pour que leurs paquets s’installent les uns sur les autres, mais suffisamment différents pour produire un système que personne ne peut prendre en charge.

Le mécanisme repose sur les numéros de version. CentOS Stream 9 évolue en avance sur RHEL 9. Si vous configurez un serveur Rocky 9 pour utiliser un dépôt Stream, même une seule fois et pour un seul paquet, vous installez des paquets dont les versions sont en avance sur tout ce que Rocky publiera. Lorsque la prochaine version mineure de Rocky sort, sa version de ce paquet est inférieure à la vôtre. Dans ce cas, dnf upgrade ne le modifie pas. La machine exécute alors une combinaison que personne n’a testée. Cette situation peut rester invisible pendant des années, tandis que vous pensez que le serveur est à jour.

Le symptôme est que dnf upgrade n’indique rien à faire, tandis que sudo dnf distro-sync propose de rétrograder une longue liste de paquets. distro-sync est l’outil de réparation : il force chaque paquet installé à correspondre à ce que proposent réellement les dépôts activés, y compris en effectuant les rétrogradations nécessaires. Désactivez d’abord le dépôt étranger, exécutez ensuite l’outil, puis examinez la liste proposée avant de l’accepter. La réparation échoue lorsque l’ancien RPM n’est plus disponible sur le miroir. À ce stade, reconstruire le serveur à partir d’une image propre est plus rapide et plus sûr que de lutter avec le résolveur de dépendances.

Les restes d’une migration avec ELevate sont une autre cause fréquente du même problème. ELevate est l’outil de migration d’AlmaLinux, basé sur Leapp. Il permet de faire évoluer un serveur CentOS 7 ou de le convertir vers un autre rebuild. Une migration effectuée trop rapidement laisse des fichiers de dépôt EL7 dans /etc/yum.repos.d/ et des paquets EL7 encore installés. Recherchez-les avec rpm -qa | grep el7. Chacun correspond à un paquet qu’aucun dépôt activé ne pourra mettre à jour. Lors d’une exécution ultérieure de Leapp, ils apparaissent comme des paquets impossibles à mapper. Ils bloquent alors la mise à niveau et doivent être supprimés manuellement. Supprimez-les pendant que le serveur fonctionne normalement, et non le jour où vous devez effectuer la prochaine mise à niveau majeure.

Un dépôt fournisseur qui prend le pas sur un paquet AppStream est une forme moins grave du même problème. La ligne includepkgs ci-dessus permet de le corriger. Les outils de conteneurs sont le cas le plus fréquent, car containerd.io provenant du propre dépôt de Docker entre en conflit avec runc provenant d’AppStream. Vous devez donc en conserver un seul. Prenez une décision, notez l’exclusion et suivez un ordre éprouvé : le guide installer Docker sur Rocky Linux indique quels paquets de la distribution supprimer en premier.

La traduction d’apt vers dnf pour les dépôts

• /etc/apt/sources.list.d/*.sources devient /etc/yum.repos.d/*.repo, sachant qu’un fichier peut contenir plusieurs [sections], chacun avec son propre identifiant.
• add-apt-repository universe devient dnf install epel-release. La différence est que universe fait toujours partie des archives Ubuntu, tandis qu’EPEL est un projet distinct.
• apt update n’a pas d’équivalent à retenir. dnf actualise les métadonnées selon son propre calendrier, et dnf makecache force cette actualisation immédiatement.
• apt-cache policy <pkg> devient dnf info <pkg>, avec dnf list --showduplicates <pkg> en plus pour afficher toutes les versions disponibles.
• apt-mark hold devient dnf versionlock add, à partir de python3-dnf-plugin-versionlock.
• Le pinning dans /etc/apt/preferences.d/ devient priority= dans la section du dépôt, les nombres évoluant en sens inverse.
• dpkg -S /path/to/file devient rpm -qf /path/to/file.

Les mises à jour automatiques se transposent comme concept plutôt que comme syntaxe, car il n’existe pas de unattended-upgrades ici. Le timer, le fichier de configuration et le choix de redémarrer ou non sont présentés dans dnf-automatic sur Rocky et Alma.

Limiter la liste des dépôts

Activez CRB, installez epel-release, puis consignez ce que vous avez fait et pourquoi, soit dans votre gestion de configuration, soit dans un fichier standard sur le serveur. Cette note prend toute son importance lorsque le serveur a trois ans et qu’une autre personne en assure la maintenance.

Recherchez avant d’ajouter. Exécutez dnf search, puis dnf info, et n’envisagez un nouveau dépôt qu’ensuite. Une part surprenante des logiciels pour lesquels EPEL est activé se trouve déjà dans AppStream. La supervision système en est l’exemple le plus clair, car Performance Co-Pilot est fourni dans les dépôts de base et ne nécessite aucun dépôt tiers. Chaque dépôt supplémentaire est une partie de plus susceptible de vous fournir un package un mardi, et chacun rend la prochaine mise à niveau majeure plus difficile.

Si vous hésitez encore entre les deux distributions, cette organisation est identique sur les deux, et epel-release se comporte de la même manière. Les véritables différences se trouvent ailleurs : la comparaison entre Rocky Linux et AlmaLinux présente la philosophie de ces rebuilds, car AlmaLinux vise désormais la compatibilité ABI (application binary interface) plutôt qu’un rebuild strict, ligne par ligne.

FAQ

Comment activer EPEL sur Rocky Linux 9 ou AlmaLinux 9 ?

Exécutez sudo dnf install -y dnf-plugins-core, puis sudo dnf config-manager --set-enabled crb, puis sudo dnf install -y epel-release. Vérifiez avec dnf repolist --enabled, qui doit afficher baseos, appstream, extras, crb et epel. Activez CRB avant d’installer les paquets EPEL, car beaucoup dépendent de bibliothèques fournies uniquement par CRB. En version 8, l’identifiant du dépôt est powertools au lieu de crb.

Est-il sûr d’activer EPEL sur un serveur de production ?

EPEL est largement utilisé. Sa politique garantit que ses paquets ne remplacent jamais un paquet de la distribution de base. Son activation ne modifie donc pas le contenu fourni par BaseOS ou AppStream. La réserve concerne le support : EPEL est un projet Fedora maintenu par des bénévoles, sans accord de niveau de service, et un mainteneur peut ne s’engager sur un paquet que pour une version mineure de RHEL ou pendant 13 mois. Tenez un inventaire avec dnf repository-packages epel list installed et utilisez dnf versionlock pour tout paquet EPEL dont dépend un service accessible aux clients.

Pourquoi dnf indique-t-il « no such command: config-manager » ?

Parce que config-manager est un plugin dnf, et non une commande intégrée, tandis que les images minimales ou de conteneur sont livrées sans dnf-plugins-core. Le message indique lui-même la correction : sudo dnf install -y 'dnf-command(config-manager)', entre guillemets pour empêcher le shell d’interpréter les parenthèses. Si vous ne pouvez encore rien installer, exécutez grep -rl crb /etc/yum.repos.d/, ouvrez le fichier indiqué et définissez manuellement enabled=1 dans la section [crb].

Quelle est la différence entre CRB et PowerTools ?

Il s’agit du même dépôt sous deux noms. La version 8 l’appelle PowerTools et utilise l’identifiant powertools. La version 9 et les suivantes l’appellent CRB et utilisent l’identifiant crb. Red Hat appelle ce contenu CodeReady Linux Builder. Il fournit des en-têtes de développement, des bibliothèques statiques et des outils de build. Il est désactivé par défaut sur Rocky et AlmaLinux 9. AlmaLinux 10 l’active par défaut depuis 10.0. Vérifiez donc dnf repolist --enabled avant d’exécuter la commande d’activation.

Comment supprimer EPEL sans rien casser ?

Commencez par établir un inventaire avec dnf repository-packages epel list installed, car la suppression du seul paquet epel-release ne désinstalle rien de ce qui a été installé depuis EPEL. Ces paquets restent sur le disque, ne reçoivent plus de mises à jour et ne bénéficient plus des correctifs de sécurité, sans qu’aucune erreur ne vous en informe. Examinez les paquets un par un, supprimez ou remplacez ceux dont vous n’avez plus besoin, puis exécutez seulement ensuite sudo dnf remove epel-release. Si un paquet EPEL n’a remplacé aucun paquet et doit simplement être supprimé, sudo dnf repository-packages epel remove efface l’ensemble en une seule transaction. Lisez donc attentivement la liste proposée avant de confirmer.