Cómo activar EPEL y CRB en Rocky 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 nada averiado ni ningún mirror fuera de servicio. La distribución base incluye deliberadamente un conjunto reducido de paquetes. CRB está presente, pero desactivado. 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 duda no suele aparecer. La familia Red Hat distribuye sus paquetes de otra forma y parte de un conjunto más reducido. La solución son tres comandos. El resto de esta guía explica lo que esos repositorios ofrecen, lo que no ofrecen y cómo evitar que un repositorio de terceros sustituya silenciosamente a los paquetes base del sistema.

Cómo se comprobaron estos comandos. Nuestros contenedores de prueba ejecutan sólo Ubuntu, por lo que los comandos dnf siguientes no se ejecutaron en nuestras propias máquinas de prueba. Se basan en 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 se congelan durante toda la vida de la versión principal, y las correcciones de seguridad se incorporan a esas versiones congeladas. 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 lo que se ejecuta sobre el sistema: servidores web, bases de datos, runtimes 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 eliminó casi toda la modularidad, por lo que en Rocky 9 y Alma 9 normalmente se obtiene una única versión de cada componente y no es necesario habilitar antes ningún módulo.

Extras está habilitado de forma predeterminada y es muy pequeño. Contiene principalmente paquetes de release para otros repositorios, de donde procede el propio epel-release. Por eso nunca es necesario 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, pero 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 soporte. Rocky y Alma heredan tanto el contenido como la configuración deshabilitada de forma predeterminada.

Para quienes llegan desde Debian o Ubuntu: main mezcla los paquetes de runtime y las cabeceras -dev en un mismo archivo, por lo que allí no existe un CRB que habilitar. La alternativa más cercana 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 y se recompilan para la versión empresarial actual. Los mantiene 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 ningún contrato de soporte ni ningún SLA (acuerdo de nivel de servicio) asociado a 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 publica nginx, EPEL no lo hará. Las personas que revisan los paquetes de EPEL hacen cumplir esta regla, por lo que es una garantía limitada a EPEL. No le protege de ningún otro repositorio que añada posteriormente.

La garantía de duración también difiere de la de la distribución base, y esto causa problemas en el tercer año. La versión de un paquete de BaseOS permanece congelada durante los diez años de vida de la versión principal. Un responsable de EPEL se compromete a un periodo mucho más corto: al menos una versión menor de RHEL o 13 meses, lo que sea menor. En la práctica, la mayoría de los paquetes se mantienen durante mucho más tiempo. Algunos se retiran cuando el responsable deja de mantenerlos, y otros saltan a una nueva versión principal durante la vida de su distribución porque EPEL sigue el ciclo de Fedora. Por tanto, una operación rutinaria de dnf upgrade puede instalar una nueva versión principal de una herramienta de EPEL en una máquina que consideraba estable. Además, un paquete del que depende puede dejar de recibir actualizaciones sin ningún anuncio que llegue hasta usted.

Hay otra consecuencia que conviene conocer antes de habilitarlo: EPEL se compila contra la versión menor más reciente de RHEL. Si mantiene un servidor en una versión menor antigua y utiliza un mirror congelado o un repositorio del proveedor para una versión puntual, un paquete de EPEL puede requerir una biblioteca base más reciente que la disponible en su sistema. dnf informa de esto como una dependencia ausente. Parece un problema del mirror, pero 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 mayúsculas y minúsculas. La documentación antigua de CentOS 8 lo escribe como PowerTools, con mayúsculas, y ese valor no coincidirá. En AlmaLinux 10, el repositorio CRB se activa de forma predeterminada desde 10.0 (cambio aplicado en septiembre de 2025), por lo que sólo necesita ejecutar el paso epel-release.

epel-release procede de extras, que ya está activado. Por tanto, no hay ninguna URL que deba confiar 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 le indique solucionar un error de firma con --nogpgcheck. Un error en la comprobación de firma significa que el paquete no es lo que afirma ser o que el reloj del sistema está desajustado.

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

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

dnf repoquery --repo=epel htop

El comando muestra el nombre, la versión y la arquitectura del paquete. Que no muestre nada 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 complemento, no un subcomando integrado de dnf. Se incluye en dnf-plugins-core, que una instalación completa del servidor instala como dependencia, pero que las imágenes mínimas, las imágenes cloud y las imágenes de contenedor omiten. La sugerencia del propio 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 complemento porque el repositorio que necesita es el que 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 hacerlo manualmente no cambia el resultado. dnf repolist --enabled confirma el resultado.

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

La segunda trampa habitual produce un error que nunca menciona CRB. Un paquete de EPEL que enlaza con una biblioteca incluida sólo 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 consultar 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, pero la instalación normal sigue fallando, CRB está deshabilitado. Este tipo de error es suficientemente habitual como para que AlmaLinux habilitara CRB de forma predeterminada en la versión 10, precisamente para evitarlo. --enablerepo=crb también funciona como una opción de una sola vez para una instalación concreta, pero deje CRB habilitado permanentemente si utiliza EPEL, porque la siguiente actualización de EPEL puede incorporar una nueva dependencia de CRB sin avisarle antes.

¿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 en un paquete instalado muestra una línea From repo. dnf list installed muestra la misma información en su tercera columna con un @ delante, por lo que @epel significa que está instalado desde EPEL, y @System significa que dnf no sabe de dónde procede. Esto suele indicar 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 del que nunca ha oído hablar. El último comando muestra exactamente lo que un repositorio ha proporcionado. Necesita ese inventario antes de decidir eliminarlo.

El equivalente habitual en apt es apt-cache policy <package>. Conviene mantener abiertos en otra pestaña los equivalentes de comandos de dnf y apt durante el primer mes, porque los conceptos se corresponden 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 también proporciona BaseOS, y dnf la instalará porque su regla predeterminada es sencilla: gana la versión más alta, independientemente de su origen.

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

priority= decide qué repositorio gana cuando varios ofrecen el mismo nombre de paquete. Ganan los números más bajos y el valor predeterminado es 99, por lo que debe asignar un número bajo a los repositorios base y uno alto a los repositorios de terceros. Entonces, dnf elegirá el paquete base aunque 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 determinados paquetes de un repositorio, por lo que debe prever qué paquetes podría publicar. includepkgs= invierte ese comportamiento: este repositorio sólo puede proporcionar estos nombres y ningún otro. Para un repositorio de proveedor que sólo debe proporcionar su propio agente, basta con una 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, y module_hotfixes=1 en la sección de ese repositorio indica a dnf que deje de filtrarlo. Si un paquete es visible para dnf repoquery pero no se instala en un sistema con la versión 8, esa suele ser la causa. La versión 9 eliminó casi todos los módulos, por lo que esto aparece rara vez allí.

Para fijar un paquete en 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 deja un servidor sin posibilidad de actualización

Rocky, Alma, CentOS Stream, Oracle Linux y RHEL son lo bastante parecidos para que sus paquetes se instalen unos sobre otros, y lo bastante diferentes para que el resultado deje de ser un sistema que alguien pueda admitir.

El mecanismo son los números de versión. CentOS Stream 9 va por delante de RHEL 9, por lo que apuntar un sistema Rocky 9 a un repositorio de Stream, aunque sea una sola vez y para un solo paquete, hace que el sistema conserve paquetes cuyas versiones estén por delante de cualquier versión que Rocky llegue a publicar. Cuando aparece la siguiente versión menor de Rocky, su versión de ese paquete es inferior a la instalada, por lo que dnf upgrade no la modifica. El equipo ejecuta entonces una combinación que nadie ha probado, y permanece así silenciosamente durante años mientras usted da por hecho 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 anterior ya no está en el mirror. En ese punto, reconstruir el servidor desde una imagen limpia es más rápido y seguro que luchar con el solucionador de dependencias.

Los restos de ELevate son la 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 convertirlo entre rebuilds. Una migración apresurada deja archivos de repositorio de EL7 en /etc/yum.repos.d/ y paquetes de EL7 todavía instalados. Búsquelos con rpm -qa | grep el7. Cada uno es un paquete que ningún repositorio habilitado podrá actualizar, y una ejecución posterior de Leapp los informa como paquetes que no puede mapear. Esto 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 versión leve de la misma enfermedad, 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 lo que debe eliminar uno de ellos. Tome la decisión una sola vez, documente la exclusión y siga un orden conocido: la guía instalación de Docker en Rocky Linux explica qué paquetes de la distribución se deben 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 id.
• 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 propio calendario, 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 deje constancia de lo que hizo y del motivo, ya sea en su sistema de gestión de la configuración o en un archivo de texto en el servidor. Esa nota es más importante de lo que parece cuando el servidor tiene tres años y otra persona se encarga de administrarlo.

Busque antes de añadir nada. Ejecute dnf search, después dnf info y sólo entonces considere añadir un repositorio nuevo. Una proporción considerable de los paquetes para los que se habilita EPEL ya está disponible en AppStream. La monitorización del sistema es el ejemplo más claro, porque Performance Co-Pilot se incluye en los repositorios base y no necesita ningún componente de terceros. Cada repositorio adicional es otra entidad que puede proporcionarle un paquete un martes cualquiera, y cada uno dificulta la próxima actualización principal.

Si todavía está eligiendo entre las dos distribuciones, esta organización es igual en ambas y epel-release se comporta de la misma manera. 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 la 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 luego 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 que impide que sus paquetes sustituyan paquetes de la distribución base. Por tanto, habilitarlo no cambia el contenido que proporcionan BaseOS o AppStream. La limitación está relacionada con el soporte: EPEL es un proyecto voluntario de Fedora sin acuerdo de nivel de servicio, y un mantenedor puede comprometerse con un paquete durante una sola versión secundaria de RHEL o durante 13 meses. Mantenga un inventario con dnf repository-packages epel list installed y use dnf versionlock en cualquier paquete de EPEL del que dependa un servicio orientado a clientes.

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

Porque config-manager es un plugin de dnf y 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 enabled=1 manualmente 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 propio de Red Hat denomina a este contenido CodeReady Linux Builder. 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 sistema, dejan de recibir actualizaciones de su repositorio de origen y dejan de recibir correcciones de seguridad sin mostrar ningún error que lo indique. Evalúe cada paquete por separado, 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. Revise atentamente la lista propuesta antes de confirmarla.