EPEL y CRB en Rocky Linux y AlmaLinux

Por qué dnf no encuentra el paquete que necesita

EPEL y CRB son los dos repositorios que un servidor recién instalado de Rocky Linux o AlmaLinux no incluye de forma predeterminada. Por eso, dnf install htop en un sistema nuevo responde con No match for argument: htop y después con Error: Unable to find a match: htop. No hay ningún componente averiado ni ningún mirror caído. La distribución base incluye deliberadamente un conjunto reducido de paquetes, CRB está disponible pero desactivado y EPEL es un repositorio comunitario independiente que debe añadir.

En Ubuntu, el mismo paquete se encuentra en universe y universe está habilitado en casi todas las imágenes de cloud, por lo que esta situación no suele plantearse. La familia Red Hat organiza sus paquetes de otra forma y ofrece menos paquetes de forma predeterminada. La solución consta de tres comandos. El resto de esta guía cubre lo que nadie suele explicar durante la primera semana: qué ofrecen esos repositorios, qué no ofrecen y cómo evitar que un repositorio de terceros tome silenciosamente el control del sistema base.

Cómo se comprobaron estos comandos. Nuestros contenedores de prueba de comandos sólo ejecutan Ubuntu, por lo que los comandos dnf siguientes no se ejecutaron en nuestras propias máquinas de prueba. Se ajustan a la documentación de Rocky Linux y AlmaLinux. Cada paso indica la salida que debe ver. Compruebe cada uno en su propio servidor en lugar de pegar todo el bloque de una vez.

¿Qué son BaseOS, AppStream y CRB?

BaseOS es el propio sistema operativo: el kernel, glibc, systemd y el espacio de usuario principal. Las versiones de estos componentes rara vez cambian durante la vida de la versión principal. La mayoría de las correcciones, incluidas las de seguridad, se incorporan a la versión que ya tiene instalada, aunque una versión menor puede actualizar ocasionalmente un componente principal a una versión superior del proyecto original (AlmaLinux 9.2, por ejemplo, actualizó los paquetes del espacio de usuario de SELinux a la versión 3.5). Un número de versión que parece antiguo en BaseOS no indica que el paquete no tenga parches. Es una versión antigua con parches, que es precisamente el objetivo de una distribución empresarial.

AppStream contiene los componentes que se ejecutan sobre el sistema: servidores web, bases de datos, entornos de ejecución de lenguajes, editores y agentes de monitorización. En la versión 8, gran parte de AppStream se distribuía como módulos con streams alternativos, por lo que dnf module list era importante y había que elegir, por ejemplo, un stream de PHP. La versión 9 distribuye la versión predeterminada de cada aplicación como un paquete normal, por lo que en Rocky 9 y Alma 9 un dnf install normal proporciona esa versión sin tener que habilitar antes ningún módulo. Las versiones alternativas siguen llegando como streams de módulos: RHEL 9 documenta PHP 8.0 como el paquete php normal y PHP 8.1 y 8.2 como los streams php:8.1 y php:8.2, y AlmaLinux 9.8 añadió nuevos streams, como MariaDB 11.8, PostgreSQL 18 y Ruby 4.0. Si necesita una versión distinta de la predeterminada, dnf module list sigue siendo importante en la versión 9.

Extras está habilitado de forma predeterminada y es muy pequeño. Contiene principalmente paquetes de versión para otros repositorios, de donde procede el propio epel-release. Por eso nunca necesita confiar en una URL aleatoria para instalar EPEL en Rocky o Alma.

CRB es el repositorio CodeReady Builder, denominado PowerTools en la versión 8. Contiene la parte de desarrollo de la distribución: cabeceras de desarrollo, bibliotecas estáticas y las herramientas de pruebas y documentación que los paquetes necesitan durante la compilación. Ya está disponible en el mirror y está deshabilitado de forma predeterminada. En el producto propio de Red Hat, el mismo contenido se denomina CodeReady Linux Builder, se incluye con la suscripción y Red Hat indica que no está cubierto por el soporte. Rocky y Alma heredan tanto el contenido como la configuración deshabilitada de forma predeterminada.

Para los lectores que llegan desde Debian o Ubuntu: main mezcla los paquetes de ejecución y las cabeceras -dev en un mismo archivo, por lo que allí no existe un CRB que habilitar. El equivalente más cercano a EPEL es universe, que mantiene la comunidad y no incluye ningún compromiso de soporte del proveedor.

Qué es EPEL y quién lo mantiene

EPEL significa Extra Packages for Enterprise Linux. Es un proyecto de Fedora: paquetes que existen en Fedora, recompilados para la versión empresarial actual y mantenidos por el EPEL Special Interest Group, formado principalmente por voluntarios de la comunidad de Fedora. Red Hat aloja la infraestructura de compilación y de mirrors, y algunos ingenieros de Red Hat mantienen paquetes en él. Ahí termina la relación. EPEL no es un producto de Red Hat. No existe un contrato de soporte ni un SLA (acuerdo de nivel de servicio) para un paquete de EPEL, ni en RHEL ni en una reconstrucción.

Una política permite habilitar EPEL de forma segura: un paquete de EPEL nunca debe reemplazar un paquete de la distribución base. Si AppStream incluye nginx, EPEL no lo incluirá. Esa regla la aplican las personas que revisan los paquetes de EPEL, por lo que sólo constituye un compromiso sobre EPEL. No le protege de ningún otro repositorio que añada después.

El compromiso de duración también difiere del de la distribución base, y esto puede causar problemas en el tercer año. Un paquete de BaseOS normalmente conserva su versión durante los diez años de vida de la versión principal, con correcciones retroportadas y sólo alguna rebase deliberada. Un mantenedor de EPEL se compromete con un periodo mucho más corto: la propuesta de duración de los paquetes basada en la versión de EPEL lo expresa como al menos una versión menor de RHEL o 13 meses, lo que sea más corto. En la práctica, la mayoría de los paquetes se mantienen durante mucho más tiempo. Algunos se retiran cuando el mantenedor deja de trabajar en ellos, y otros saltan a una versión principal nueva durante la vida de su distribución porque EPEL sigue a Fedora. Por eso, una operación rutinaria de dnf upgrade puede instalarle una versión principal nueva de una herramienta de EPEL en una máquina que consideraba estable, y un paquete del que depende puede dejar de recibir actualizaciones sin que usted reciba ningún anuncio. Una versión nueva tampoco se aplica a un servicio que ya está en ejecución, por lo que necesita reiniciar indica qué procesos siguen usando el binario antiguo una vez terminada la transacción.

Hay otra consecuencia que conviene conocer antes de habilitarlo: EPEL no se compila contra la versión menor antigua en la que quizá mantiene un servidor. La política de EPEL de Fedora compila la versión menor principal de EPEL 10 contra CentOS Stream 10 y las versiones menores anteriores de EPEL 10 contra versiones menores específicas de RHEL 10. EPEL 8 y 9 tienen sus propias definiciones de destino. Si mantiene un servidor en una versión menor antigua mediante un mirror congelado o un repositorio de una versión puntual del proveedor, un paquete de EPEL puede requerir una biblioteca base más reciente que la disponible. dnf informa de esto como una dependencia ausente, y parece un problema del mirror cuando en realidad es un problema de desajuste de versiones.

Activar CRB e instalar EPEL en Rocky o 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 ahora debería mostrar baseos, appstream, extras, crb y epel. También puede aparecer una entrada pequeña de epel-cisco-openh264, que añade epel-release. Si crb no aparece en esa lista, el paso de activación no se aplicó y la siguiente sección explica el motivo.

En Rocky 8 y Alma 8, el repositorio todavía se llama PowerTools, por lo que el comando intermedio pasa a ser sudo dnf config-manager --set-enabled powertools. Los identificadores de repositorio distinguen entre mayúsculas y minúsculas. La documentación antigua de CentOS 8 lo escribe como PowerTools, con mayúsculas, y ese valor no coincide. En AlmaLinux 10, el repositorio CRB está activado de forma predeterminada desde 10.0 (cambio realizado en septiembre de 2025), por lo que sólo necesita el paso epel-release.

epel-release procede de extras, que ya está activado. Por tanto, no hay ninguna URL que deba confiarse ni ninguna clave que deba importar manualmente. El paquete escribe /etc/yum.repos.d/epel.repo e instala la clave de firma de EPEL en /etc/pki/rpm-gpg/. Confirme gpgcheck=1 en ese archivo e ignore cualquier guía que indique evitar un error de firma mediante --nogpgcheck. Un fallo en la comprobación de la firma significa que el paquete no es lo que declara ser o que el reloj del sistema es incorrecto.

En Rocky, epel-release también instala un pequeño auxiliar en /usr/bin/crb. Por tanto, sudo crb enable y crb status realizan la misma tarea sin el plugin. Compruebe si está instalado con command -v crb antes de depender de él, porque no está presente en todas las variantes de cada reconstrucción.

Para demostrar que EPEL es accesible y no sólo que aparece en la lista, solicite un paquete que sólo ese repositorio contiene:

dnf repoquery --repo=epel htop

Esto muestra el nombre, la versión y la arquitectura del paquete. La ausencia de salida significa que el repositorio está activado, pero no devuelve resultados. Normalmente se trata de un problema del mirror o de los metadatos, no de la configuración. En ese caso, pruebe sudo dnf clean all && sudo dnf makecache a continuación.

Por qué dnf muestra «no such command: config-manager»

Este es el primer punto que suele causar problemas. Ocurre precisamente en las imágenes que proporcionan muchos proveedores de 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 es un plugin, no un subcomando integrado de dnf. Se incluye en dnf-plugins-core, que una instalación completa del servidor incorpora, pero que las imágenes mínimas, las imágenes para la nube y las imágenes de contenedor omiten. La propia sugerencia de dnf funciona porque el paquete declara esa capacidad virtual:

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

Escríbalo entre comillas. Los paréntesis son sintaxis del shell. Por tanto, una versión sin comillas falla con un error de sintaxis, no con un error de dnf.

Si no puede instalar el plugin porque el repositorio que necesita está deshabilitado, edite el archivo directamente. Busque qué archivo contiene la sección, ábralo y establezca enabled=1 en [crb]:

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

Eso es exactamente lo que escribe config-manager, por lo que no se pierde nada al hacerlo manualmente. dnf repolist --enabled confirma el resultado.

Algunos paquetes de EPEL no se instalarán hasta habilitar CRB

La segunda causa habitual muestra un error que nunca menciona CRB. Un paquete de EPEL que enlaza con una biblioteca disponible únicamente en CRB falla durante la resolución de dependencias. El mensaje indica la biblioteca y el paquete que la necesita:

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

La causa es que CRB está deshabilitado, por lo que dnf no puede ver el único repositorio que proporciona esa biblioteca. Compruebe estos dos puntos en orden:

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

Si el segundo comando muestra un paquete y la instalación normal sigue fallando, CRB está deshabilitado. Esta clase de error es suficientemente frecuente como para que AlmaLinux habilitara CRB de forma predeterminada en la versión 10, específicamente para evitarlo. --enablerepo=crb también funciona como opción puntual en una sola instalación, pero deje CRB habilitado de forma permanente si utiliza EPEL, porque la siguiente actualización de EPEL puede incorporar una nueva dependencia de CRB sin avisar previamente.

¿De qué repositorio procede este paquete?

Después de varias semanas con cuatro repositorios habilitados, la pregunta útil deja de ser qué está instalado y pasa a ser de dónde procede.

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 sobre un paquete instalado muestra una línea From repo. dnf list installed muestra la misma información en su tercera columna, con un @ al principio. Por tanto, @epel significa que el paquete se instaló desde EPEL, y @System significa que dnf no sabe de dónde procede. Normalmente, esto indica que alguien ejecutó rpm -i sobre un archivo descargado. La línea repoquery muestra un recuento por repositorio. Es la forma más rápida de descubrir que un servidor heredado tiene cuarenta paquetes de un repositorio que nunca había visto. El último comando muestra exactamente lo que un repositorio le ha proporcionado. Necesita ese inventario antes de decidir eliminarlo.

El equivalente habitual en apt es apt-cache policy <package>. Conviene tener abiertas en una segunda pestaña las equivalencias de comandos entre dnf y apt durante el primer mes. Los conceptos se corresponden bien, aunque las opciones no sean iguales.

¿Cómo evitar que un repositorio de terceros sustituya un paquete base?

EPEL se compromete a no hacerlo. Ningún otro repositorio ofrece esa garantía. Un repositorio de un proveedor para una base de datos, un agente o un runtime de lenguaje puede publicar su propia compilación de una biblioteca que BaseOS también proporciona, y dnf la instalará porque la regla predeterminada de dnf es sencilla: gana la versión más alta, independientemente de su origen.

Dos controles cubren la mayor parte del trabajo y ambos se encuentran en el archivo del repositorio bajo /etc/yum.repos.d/.

priority= decide qué repositorio gana cuando varios contienen el mismo nombre de paquete. Los números más bajos ganan y el valor predeterminado es 99. Por tanto, asigne un número bajo a los repositorios base y uno alto a los repositorios de terceros. dnf elegirá entonces el paquete base incluso cuando la versión de terceros sea más reciente. Las versiones modernas de dnf gestionan esto directamente, por lo que el paquete independiente yum-plugin-priorities de la época de CentOS 7 ya no forma parte de la solución.

includepkgs= es la opción de filtrado más restrictiva. excludepkgs= bloquea paquetes con nombres concretos de un repositorio, lo que obliga a prever qué paquetes podría publicar. includepkgs= invierte ese comportamiento: este repositorio sólo puede proporcionar esos nombres y ningún otro. Un repositorio de un proveedor que sólo deba proporcionar su propio agente se configura con una sola línea.

[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

En la versión 8 hay otra configuración que debe conocer. Un paquete de un repositorio de terceros puede quedar oculto cuando un módulo de AppStream proporciona el mismo nombre. module_hotfixes=1, en la sección de ese repositorio, indica a dnf que deje de filtrarlo. Si un paquete que el repositorio del proveedor incluye con certeza aparece como ausente o no se puede instalar en un sistema con la versión 8, esa suele ser la causa: el filtrado modular lo hace invisible para la mayoría de los comandos de dnf en lugar de informar de un conflicto. La versión 9 tiene menos módulos, pero sigue incluyendo streams de módulos. Por tanto, el mismo filtrado puede aplicarse allí cuando un paquete del proveedor comparte nombre con otro.

Para fijar un paquete a una versión concreta, instale python3-dnf-plugin-versionlock y use sudo dnf versionlock add <package>. Es el equivalente de apt-mark hold. Tenga en cuenta una inversión que suele confundir a quienes vienen de Debian: en apt gana un Pin-Priority más alto; en dnf gana un priority más bajo.

Por qué mezclar repositorios adyacentes de RHEL impide actualizar un servidor

Rocky, Alma, CentOS Stream, Oracle Linux y RHEL son lo bastante parecidos para que sus paquetes se instalen unos sobre otros, pero también lo bastante diferentes para que el resultado deje de ser un sistema compatible con soporte. La razón de esa cercanía y el motivo por el que Stream se sitúa ahora por delante de RHEL, en lugar de estar a su lado, se explican en la historia de cómo Red Hat Linux se dividió en Fedora y RHEL y qué ocurrió con CentOS.

El mecanismo son los números de versión. CentOS Stream 9 va por delante de RHEL 9, y Red Hat describe el código de Stream como el que se convierte en la siguiente versión menor de RHEL. Si apunta un sistema Rocky 9 a un repositorio de Stream, aunque sea una sola vez y para un solo paquete, terminará con paquetes cuyas versiones están por delante de las que Rocky ofrece actualmente. Una versión menor posterior de Rocky puede ponerse al día, pero nada garantiza que publique ese paquete con una versión igual o superior a la instalada. Hasta que lo haga, dnf upgrade no lo actualizará. El equipo ejecuta ahora una combinación que nadie ha probado, y puede permanecer así silenciosamente durante años mientras usted cree que está actualizado.

El síntoma es que dnf upgrade no informa de nada que hacer, mientras sudo dnf distro-sync propone degradar una lista larga de paquetes. distro-sync es la herramienta de reparación: obliga a que todos los paquetes instalados coincidan con lo que ofrecen realmente los repositorios habilitados, incluidas las degradaciones. Deshabilite primero el repositorio externo, ejecútela después y revise la lista propuesta antes de aceptarla. La reparación falla cuando el RPM antiguo ya no está disponible en el mirror. En ese punto, reconstruir el servidor a partir de una imagen limpia es más rápido y seguro que luchar con el resolvedor de dependencias.

Los restos de ELevate son otra variante habitual de este problema. ELevate es la herramienta de migración de AlmaLinux basada en Leapp. Se utiliza para actualizar un sistema CentOS 7 o para convertirlo entre reconstrucciones. Una migración apresurada deja archivos de repositorio de EL7 en /etc/yum.repos.d/ y paquetes de EL7 todavía instalados. Puede encontrarlos con rpm -qa | grep el7. Cada uno es un paquete que ningún repositorio habilitado podrá actualizar. Una ejecución posterior de Leapp los informa como paquetes que no puede asignar, lo que se convierte en un bloqueo de actualización que debe resolver manualmente. Elimínelos mientras el servidor está estable, no el día que necesite realizar la siguiente actualización principal.

Un repositorio de un proveedor que oculta un paquete de AppStream es la variante menos grave del mismo problema, y la línea includepkgs anterior es la solución. Las herramientas de contenedores son el caso habitual, porque containerd.io del repositorio propio de Docker entra en conflicto con runc de AppStream. Por tanto, uno de los dos debe eliminarse. Tome la decisión una sola vez, documente la exclusión y siga un orden conocido y probado: el tutorial Instalar Docker en Rocky Linux explica qué paquetes de la distribución debe eliminar primero.

La traducción de apt a dnf para los repositorios

• /etc/apt/sources.list.d/*.sources se convierte en /etc/yum.repos.d/*.repo, donde un archivo puede contener varios [sections], cada uno con su propio identificador.
• add-apt-repository universe se convierte en dnf install epel-release, con la diferencia de que universe sigue dentro del archivo propio de Ubuntu y EPEL es un proyecto independiente.
• apt update no tiene un equivalente que deba recordar. dnf actualiza los metadatos según su propia programación, y dnf makecache lo fuerza en ese momento.
• apt-cache policy <pkg> se convierte en dnf info <pkg>, junto con dnf list --showduplicates <pkg> para ver todas las versiones disponibles.
• apt-mark hold se convierte en dnf versionlock add, a partir de python3-dnf-plugin-versionlock.
• El pinning en /etc/apt/preferences.d/ se convierte en priority= en la sección del repositorio, con los números en orden inverso.
• dpkg -S /path/to/file se convierte en rpm -qf /path/to/file.

Las actualizaciones automáticas se trasladan como concepto y no como sintaxis, porque aquí no existe unattended-upgrades. El temporizador, el archivo de configuración y la decisión de si se debe reiniciar se explican en dnf-automatic en Rocky y Alma.

Mantenga corta la lista de repositorios

Habilite CRB, instale epel-release y documente lo que hizo y el motivo, ya sea en su sistema de gestión de la configuración o en un archivo de texto del servidor. Esa nota es más útil de lo que parece cuando el servidor tiene tres años y otra persona se encarga de él.

Busque antes de añadir nada. Ejecute dnf search, después dnf info y sólo entonces considere añadir un repositorio. Una parte importante de lo que se habilita EPEL para instalar ya está disponible en AppStream. La supervisión del sistema es el ejemplo más claro: Performance Co-Pilot se distribuye en los repositorios base y no necesita ningún componente de terceros. Cada repositorio adicional añade otra parte que puede proporcionarle un paquete cualquier martes, y cada uno dificulta la siguiente actualización principal.

Si todavía está eligiendo entre las dos distribuciones, esta estructura es la misma en ambas y epel-release funciona de forma idéntica. Las diferencias reales están en otros aspectos: la comparación entre Rocky Linux y AlmaLinux explica la filosofía de las reconstrucciones, ya que AlmaLinux ahora busca compatibilidad ABI (interfaz binaria de aplicaciones) en lugar de una reconstrucción línea por línea.

FAQ

¿Cómo habilito EPEL en Rocky Linux 9 o AlmaLinux 9?

Ejecute sudo dnf install -y dnf-plugins-core, después sudo dnf config-manager --set-enabled crb y, por último, sudo dnf install -y epel-release. Confirme el resultado con dnf repolist --enabled, que debería mostrar baseos, appstream, extras, crb y epel. Habilite CRB antes de instalar paquetes de EPEL, porque muchos dependen de bibliotecas que sólo proporciona CRB. En la versión 8, el identificador del repositorio es powertools en lugar de crb.

¿Es seguro habilitar EPEL en un servidor de producción?

EPEL se usa ampliamente y se basa en una política según la cual sus paquetes nunca sustituyen a un paquete de la distribución base. Por tanto, habilitarlo no cambia el contenido que proporcionan BaseOS o AppStream. La limitación está en el soporte: EPEL es un proyecto voluntario de Fedora sin acuerdo de nivel de servicio, y la propuesta de ciclo de vida de paquetes de EPEL pide al mantenedor que se comprometa con un paquete durante tan sólo una versión secundaria de RHEL o 13 meses. Mantenga un inventario con dnf repository-packages epel list installed y use dnf versionlock para cualquier paquete de EPEL del que dependa un servicio orientado a clientes.

¿Por qué dnf indica no such command: config-manager?

Porque config-manager es un plugin de dnf, no un comando integrado, y las imágenes mínimas o de contenedor se distribuyen sin dnf-plugins-core. El propio mensaje indica la solución: sudo dnf install -y 'dnf-command(config-manager)', entre comillas para que el shell no interprete los paréntesis. Si todavía no puede instalar nada, ejecute grep -rl crb /etc/yum.repos.d/, abra el archivo que indique y establezca manualmente enabled=1 en la sección [crb].

¿Cuál es la diferencia entre CRB y PowerTools?

Son el mismo repositorio con dos nombres. La versión 8 lo denomina PowerTools y usa el identificador powertools. La versión 9 y las posteriores lo denominan CRB y usan el identificador crb. El producto de Red Hat utiliza el nombre CodeReady Linux Builder para este contenido. El repositorio contiene cabeceras de desarrollo, bibliotecas estáticas y herramientas de compilación, y está deshabilitado de forma predeterminada en Rocky y AlmaLinux 9. AlmaLinux 10 lo habilita de forma predeterminada desde 10.0, así que compruebe dnf repolist --enabled antes de ejecutar allí el comando de habilitación.

¿Cómo elimino EPEL de nuevo sin causar problemas?

Primero haga un inventario con dnf repository-packages epel list installed, porque eliminar sólo el paquete epel-release no elimina nada de lo instalado desde EPEL. Esos paquetes permanecen en el disco, pierden su fuente de actualizaciones y dejan de recibir correcciones de seguridad sin que aparezca ningún error que se lo indique. Decida qué hacer con cada paquete, elimine o sustituya los que ya no necesite y sólo después ejecute sudo dnf remove epel-release. Si un paquete de EPEL no ha sustituido a ningún otro y debe eliminarse, sudo dnf repository-packages epel remove borra el conjunto en una sola transacción. Lea atentamente la lista propuesta antes de confirmarla.