Instalar DNF en RHEL/CentOS 7: Una Guía Técnica Completa

DNF (Dandified YUM) es el gestor de paquetes de nueva generación para distribuciones Linux basadas en RPM, diseñado como reemplazo completo de YUM. Ofrece una resolución de dependencias más rápida a través de la biblioteca `libsolv`, menor consumo de memoria y una API de Python estable. Aunque RHEL/CentOS 7 incluye YUM por defecto, DNF se puede instalar completamente a través del repositorio EPEL y puede ejecutarse en paralelo con YUM — o como reemplazo transparente — en el mismo sistema.

Esta guía recorre el proceso de instalación completo, explica las diferencias arquitectónicas entre YUM y DNF, cubre casos límite del mundo real y le proporciona una referencia de comandos lista para producción.

Por qué DNF supera a YUM en RHEL/CentOS 7

Antes de tocar la terminal, entender *por qué* vale la pena la actualización le ayuda a tomar una decisión informada — especialmente en un entorno de Hosting VPS de larga duración donde la fiabilidad de la gestión de paquetes es crítica.

Diferencias Arquitectónicas Principales

YUM depende de un resolvedor de dependencias basado en Python que tiene problemas de rendimiento bien documentados con árboles de dependencias grandes. DNF reemplaza ese resolvedor con `libsolv`, un motor de resolución de dependencias basado en SAT-solver desarrollado originalmente por SUSE. Las consecuencias prácticas son significativas:

• Velocidad de resolución de dependencias: DNF resuelve cadenas de dependencias complejas en una fracción del tiempo que requiere YUM, especialmente notable al resolver conflictos en conjuntos de paquetes grandes.
• Huella de memoria: YUM carga los metadatos completos del repositorio en memoria. DNF utiliza carga diferida y almacena en caché de forma más agresiva, reduciendo el uso máximo de RAM.
• Estabilidad de la API: La API de Python de YUM cambiaba de forma impredecible entre versiones menores. DNF expone una API de Python documentada y versionada en la que los autores de plugins pueden confiar.
• Arquitectura de plugins: DNF utiliza un sistema de plugins limpio basado en hooks. Los plugins de YUM a menudo interfieren entre sí debido al acoplamiento débil.
• Historial de transacciones: DNF mantiene una base de datos de historial de transacciones más completa, haciendo que las reversiones y auditorías sean más precisas.

YUM vs. DNF: Comparación de Características

Requisitos Previos

Antes de continuar, confirme lo siguiente:

• Una instancia en ejecución de RHEL 7 o CentOS 7 (metal desnudo, VM o un VPS en la nube).
• Acceso root o sudo — todos los comandos de instalación requieren privilegios elevados.
• Conectividad a internet activa — el repositorio EPEL debe ser accesible.
• Al menos 500 MB de espacio libre en disco para DNF, sus dependencias y la caché de metadatos del repositorio.

Si está ejecutando una instalación mínima de CentOS 7 en un Servidor Dedicado, verifique que `curl` y `wget` estén disponibles, ya que ocasionalmente están ausentes en imágenes reducidas.

Paso 1: Actualizar los Paquetes del Sistema Existentes

Sincronizar su base de datos de paquetes antes de instalar nuevo software previene conflictos de versiones y garantiza que el paquete de versión EPEL se instale correctamente con el estado actual de su base de datos RPM.

“`bash

sudo yum update -y

“`

Qué hace esto: Descarga y aplica todas las actualizaciones disponibles para los paquetes instalados actualmente, actualiza los metadatos del repositorio y reconstruye el bloqueo de transacciones RPM. En un sistema de producción, programe esto durante una ventana de mantenimiento — las actualizaciones del kernel requieren un reinicio para tener efecto.

Caso límite: Si `yum update` falla con un error `Multilib version problems`, ejecute `sudo yum update –setopt=protected_multilib=false -y` como solución temporal, luego investigue los paquetes en conflicto antes de continuar.

Paso 2: Habilitar el Repositorio EPEL

DNF no está disponible en los repositorios base predeterminados de CentOS/RHEL 7. El repositorio Extra Packages for Enterprise Linux (EPEL), mantenido por el proyecto Fedora, lo proporciona.

“`bash

sudo yum install epel-release -y

“`

Verificar que el repositorio está activo:

“`bash

yum repolist | grep epel

“`

La salida esperada debe mostrar `epel/x86_64` con un recuento de paquetes distinto de cero (típicamente 13.000+). Si el repositorio aparece deshabilitado, fuerce su habilitación:

“`bash

sudo yum-config-manager –enable epel

“`

Nota de seguridad: Los paquetes EPEL son compilados y firmados por el equipo de infraestructura de Fedora. El paquete `epel-release` instala la clave GPG automáticamente. Puede verificar la huella de la clave en el servidor de claves oficial de Fedora antes de confiar en los paquetes de este repositorio — un paso que vale la pena realizar en sistemas de producción reforzados.

¿Detrás de un proxy o firewall? Si su servidor no puede acceder directamente a los mirrors de Fedora, configure `/etc/yum.conf` con los ajustes de su proxy:

“`ini

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

proxy_username=user

proxy_password=pass

“`

Paso 3: Instalar DNF

Con EPEL activo, instale DNF y sus dependencias principales en un solo comando:

“`bash

sudo yum install dnf -y

“`

Esto incluye `dnf`, `dnf-data`, `python-dnf`, `libcomps`, `librepo` y `libsolv` como dependencias automáticas. El tamaño total de descarga suele estar entre 3–8 MB dependiendo de lo que ya esté instalado.

Qué se instala:

• `dnf` — el binario principal y la interfaz de línea de comandos
• `libsolv` — el resolvedor de dependencias basado en SAT
• `librepo` — la biblioteca de descarga paralela
• `libcomps` — analizador XML de comps para grupos de paquetes
• `python-dnf` — enlaces de Python y la biblioteca principal de DNF

Paso 4: Verificar la Instalación

Confirme que DNF está operativo y compruebe su versión:

“`bash

dnf –version

“`

Una instalación exitosa produce una salida similar a:

“`

4.0.9.2

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

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

“`

Ejecute una verificación de cordura más profunda listando los repositorios disponibles según DNF:

“`bash

dnf repolist

“`

La salida debe reflejar lo que muestra `yum repolist`, confirmando que DNF ha heredado correctamente su configuración de repositorio existente de `/etc/yum.repos.d/`.

Importante: DNF en CentOS 7 lee los mismos archivos `.repo` de repositorio que YUM. No se requiere migración de repositorios. Ambas herramientas comparten `/etc/yum.repos.d/` y `/var/cache/` (en subdirectorios separados).

Paso 5: Referencia de Comandos Principales de DNF

DNF es intencionalmente compatible en comandos con YUM. La siguiente tabla cubre las operaciones que usará con mayor frecuencia:

Historial de Transacciones y Reversión de DNF

Esta es una de las características operativamente más valiosas de DNF y una que YUM maneja deficientemente. Cada instalación, actualización o eliminación se registra en `/var/lib/dnf/history/`. Para inspeccionar transacciones recientes:

“`bash

dnf history list

“`

Para ver exactamente qué cambió en una transacción específica:

“`bash

dnf history info <transaction-id>

“`

Para deshacer una transacción (por ejemplo, revertir una actualización defectuosa):

“`bash

sudo dnf history undo <transaction-id>

“`

Esta capacidad es particularmente útil en un VPS con cPanel donde una actualización de paquete podría entrar en conflicto con las dependencias del panel de control.

Archivo de Configuración de DNF

La configuración global de DNF se encuentra en `/etc/dnf/dnf.conf`. Parámetros clave de ajuste para uso en producción:

“`ini

[main]

gpgcheck=1

installonly_limit=3

clean_requirements_on_remove=True

best=True

skip_if_unavailable=False

“`

• `installonly_limit=3` — mantiene solo las últimas 3 versiones del kernel, evitando que `/boot` se llene.
• `clean_requirements_on_remove=True` — elimina automáticamente las dependencias huérfanas al eliminar paquetes.
• `best=True` — siempre instala la última versión disponible, generando un error en lugar de degradar silenciosamente.

Paso 6: Configurar DNF como Gestor de Paquetes Predeterminado

En RHEL/CentOS 7, YUM sigue siendo el predeterminado del sistema. Tiene dos opciones para hacer de DNF su interfaz principal.

Opción A: Alias de Shell (A Nivel de Usuario, No Destructivo)

Añada lo siguiente a `~/.bashrc` (para el usuario actual) o `/etc/bashrc` (para todo el sistema):

“`bash

alias yum='dnf'

“`

Aplique inmediatamente:

“`bash

source ~/.bashrc

“`

Limitación: Este alias solo se aplica a sesiones de shell interactivas. Los scripts que invocan `yum` directamente a través de su ruta absoluta (`/usr/bin/yum`) o que se ejecutan bajo diferentes usuarios (p. ej., trabajos cron, unidades systemd) no se ven afectados.

Opción B: Enlace Simbólico (A Nivel de Sistema)

Para un reemplazo más completo, cree un enlace simbólico que redirija el binario `yum` a `dnf`:

“`bash

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

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

“`

Advertencia crítica: Este enfoque afecta a todos los usuarios y todos los scripts en todo el sistema. Pruebe exhaustivamente en un entorno que no sea de producción primero. Algunos scripts del sistema y herramientas de terceros (incluidos ciertos componentes de cPanel/WHM) llaman explícitamente a `/usr/bin/yum` y pueden comportarse de forma inesperada si el binario es reemplazado. Siempre haga una copia de seguridad del binario original como se muestra arriba.

Opción C: DNF como Plugin de YUM (Recomendado para Servidores)

El enfoque más limpio para servidores de producción es dejar YUM intacto y simplemente usar `dnf` explícitamente en sus propios flujos de trabajo y scripts de automatización. Esto evita cualquier riesgo de romper las herramientas del sistema mientras le da acceso completo a las capacidades de DNF.

Problemas Prácticos y Casos Límite

Estos son problemas que surgen en implementaciones reales y rara vez se cubren en tutoriales básicos.

Conflictos de clave GPG: Si instala paquetes de múltiples repositorios de terceros, la aplicación más estricta de GPG de DNF (cuando `gpgcheck=1`) puede rechazar paquetes que YUM aceptaba silenciosamente antes. Siempre importe las claves GPG del repositorio explícitamente con `sudo rpm –import <key-url>`.

Incompatibilidad de plugins: Algunos plugins de YUM (p. ej., `yum-plugin-fastestmirror`) no tienen un equivalente directo en DNF o se comportan de manera diferente. DNF tiene su propio plugin `fastestmirror` (`dnf-plugin-fastestmirror`), pero no está habilitado por defecto. Instálelo con `sudo dnf install python3-dnf-plugin-fastestmirror`.

Divergencia de ubicación de caché: YUM almacena en caché los metadatos en `/var/cache/yum/`. DNF usa `/var/cache/dnf/`. Si el espacio en disco es limitado, ambas cachés pueden coexistir y consumir espacio significativo. Ejecute `sudo dnf clean all` y `sudo yum clean all` de forma independiente para recuperar espacio.

Gestión de suscripciones RHEL: En sistemas RHEL 7 registrados (a diferencia de CentOS), el plugin `subscription-manager` se integra con YUM. DNF en RHEL 7 puede no respetar completamente los repositorios con acceso por suscripción sin configuración adicional. Verifique con `subscription-manager repos –list-enabled` después de cambiar.

Sensibilidad a la versión de Python: DNF en CentOS 7 usa enlaces de Python 2 (`python-dnf`). Si ha actualizado a Python 3 en su sistema, asegúrese de no estar rompiendo inadvertidamente la cadena de dependencias `python-dnf`. DNF 4+ en RHEL 8+ usa Python 3 de forma nativa.

Planificación de su Ruta de Migración Más Allá de CentOS 7

CentOS 7 alcanzó el fin de vida el 30 de junio de 2024. Instalar DNF es una mejora operativa útil, pero no cambia la postura de seguridad subyacente de una distribución EOL. Si todavía ejecuta cargas de trabajo de CentOS 7, un plan de migración a AlmaLinux 8/9, Rocky Linux 8/9 o RHEL 8/9 debería estar en su hoja de ruta. Todas estas distribuciones usan DNF de forma nativa, haciendo que la familiaridad que construya ahora sea directamente transferible.

Para equipos que ejecutan múltiples servicios en infraestructura obsoleta, los Paneles de Control VPS pueden simplificar significativamente la gestión de entornos paralelos durante una ventana de migración.

Si sus cargas de trabajo incluyen stacks de alojamiento web, migrar a una distribución moderna también le permite aprovechar al máximo la automatización de Certificados SSL a través de Certbot y ACME, que tiene un soporte significativamente mejor en RHEL 8+ y sus derivados.

Matriz de Decisión de Referencia Rápida

Use esta lista de verificación antes y después de la instalación para confirmar una configuración limpia y segura para producción:

• [ ] `yum update -y` completado sin errores antes de instalar EPEL
• [ ] Repositorio EPEL verificado activo a través de `yum repolist | grep epel`
• [ ] `dnf –version` devuelve una cadena de versión válida
• [ ] La salida de `dnf repolist` coincide con la salida de `yum repolist`
• [ ] `/etc/dnf/dnf.conf` revisado y ajustado para su entorno
• [ ] `installonly_limit` configurado para prevenir el desbordamiento de la partición `/boot`
• [ ] Decisión tomada sobre la estrategia de alias vs. enlace simbólico vs. coexistencia
• [ ] Binario de YUM respaldado si se usa el enfoque de enlace simbólico
• [ ] Trabajos cron y scripts de automatización auditados en busca de rutas `yum` codificadas
• [ ] Cronograma de migración EOL de CentOS 7 documentado

Preguntas Frecuentes

¿Pueden DNF y YUM coexistir en el mismo sistema CentOS 7 sin conflictos?

Sí. Ambas herramientas leen de `/etc/yum.repos.d/` y mantienen directorios de caché separados. Comparten la base de datos RPM (`/var/lib/rpm`), por lo que una transacción completada por una es inmediatamente visible para la otra. Ejecutar ambas simultáneamente (p. ej., dos instalaciones concurrentes) causará un conflicto de bloqueo RPM, pero el uso secuencial es completamente seguro.

¿Instalará DNF en CentOS 7 romperá los plugins de YUM existentes?

No. DNF se instala como un binario independiente y no modifica la instalación de YUM. Sus plugins de YUM existentes permanecen intactos. Sin embargo, DNF no carga plugins de YUM — si depende de plugins específicos de YUM, necesita encontrar e instalar sus equivalentes de DNF por separado.

¿DNF en CentOS 7 admite módulos DNF (flujos de módulos)?

No. Los flujos de módulos DNF son una característica introducida en DNF 4 y RHEL/CentOS 8. La versión de DNF disponible a través de EPEL para CentOS 7 es DNF 4.x, pero el soporte de flujos de módulos requiere la infraestructura del repositorio AppStream, que no existe en CentOS 7.

¿Por qué `dnf update` a veces produce resultados diferentes a `yum update` en el mismo sistema?

El resolvedor `libsolv` de DNF aplica una lógica de dependencias más estricta y puede resolver selecciones de versiones de manera diferente al resolvedor interno de YUM. En la mayoría de los casos el resultado es idéntico, pero en entornos con dependencias complejas o en conflicto, DNF puede seleccionar diferentes versiones de paquetes o rechazar transacciones que YUM habría permitido silenciosamente. Esto es una característica, no un error — el comportamiento de DNF es más predecible y auditable.

¿Es seguro usar DNF en un servidor CentOS 7 que aloja aplicaciones web de producción?

Sí, con la advertencia de que use el enfoque de coexistencia (deje YUM intacto, use DNF explícitamente) en lugar de reemplazar el binario de YUM. Verifique que cualquier software de panel de control o automatización de implementación en su servidor no tenga suposiciones codificadas sobre el comportamiento de YUM antes de cambiar su flujo de trabajo principal a DNF.