Configurar dnf-automatic en Rocky Linux y AlmaLinux

Qué hace dnf-automatic en Rocky Linux y AlmaLinux

dnf-automatic es la herramienta para obtener actualizaciones de seguridad automáticas en Rocky Linux y AlmaLinux. Es un programa pequeño, iniciado por un temporizador de systemd, que lee /etc/dnf/automatic.conf y aplica lo que dicho archivo permite. La instalación requiere un solo comando. El resto de esta guía trata sobre los ajustes que determinan si protege el servidor o si simplemente no realiza ninguna acción.

Si proviene de Debian o Ubuntu, esta herramienta realiza la misma función que unattended-upgrades en un VPS con Ubuntu. Una diferencia es más importante que todas las demás: lo que significa la palabra "seguridad" para el gestor de paquetes. En Ubuntu es un repositorio independiente. En la familia RHEL es metadato adjunto a los avisos publicados, y dicho metadato puede faltar o estar desactualizado. Si apunta dnf-automatic a un repositorio sin datos de avisos, no instalará nada y reportará una ejecución exitosa.

Esta guía está redactada para Rocky Linux 9 y AlmaLinux 9, que utilizan DNF 4 (DNF es el gestor de paquetes de la familia RHEL), a fecha de agosto de 2026. Las versiones 10 utilizan DNF5 y los nombres cambian, por lo que tienen su propia sección al final. Cada comando a continuación es para ejecutarlo en su propio servidor, con la salida que debería esperar al lado.

Instalar dnf-automatic y leer la configuración que incluye

Habilitar las actualizaciones automáticas forma parte de la configuración inicial descrita en los primeros diez minutos en un VPS nuevo, justo después de crear un usuario sin privilegios de root y configurar el firewall.

sudo dnf install -y dnf-automatic
rpm -q dnf dnf-automatic
systemctl is-enabled dnf-automatic.timer

systemctl is-enabled muestra disabled en una instalación limpia, ya que instalar el paquete no inicia ningún proceso. Esta es la razón más común por la que un servidor que "tiene dnf-automatic" nunca ha aplicado una sola actualización.

La versión de DNF es relevante para una opción específica. El ajuste reboot se introdujo en la versión upstream de DNF 4.15, y Red Hat lo integró en dnf-4.14.0-6.el9 en noviembre de 2023 mediante el aviso RHBA-2023:6645. Rocky 9 y AlmaLinux 9 reconstruyen dicho paquete, por lo que un sistema actualizado lo incluye, mientras que un sistema que no se ha tocado desde 2023 carece de él.

El archivo de configuración es /etc/dnf/automatic.conf. La copia que se incluye lista todas las opciones que esta compilación reconoce, junto con su valor predeterminado, comentado. Léalo una vez antes de editarlo, ya que ese archivo contiene la información veraz sobre su versión específica.

Los dos interruptores que deciden qué sucede

download_updates y apply_updates en la sección [commands] deciden el comportamiento. Ambos están en no de forma predeterminada en EL9 (enterprise Linux 9, la base compartida de Rocky 9 y AlmaLinux 9), por lo que un dnf-automatic sin editar que usted habilite solo le informará de lo que está disponible.

• Ambos en no: dnf-automatic informa de las actualizaciones disponibles y no cambia nada en el equipo.
• download_updates = yes con apply_updates = no: los paquetes se descargan en la caché de DNF. La instalación es rápida y no requiere red, pero no se modifica nada esa noche.
• Ambos en yes con upgrade_type = default: se instala cada actualización disponible, sea de seguridad o no.
• Ambos en yes con upgrade_type = security: solo se instalan los paquetes mencionados en un aviso de seguridad.

Un punto de partida razonable para un VPS expuesto a Internet:

[commands]
upgrade_type = security
download_updates = yes
apply_updates = yes
random_sleep = 0
network_online_timeout = 60
reboot = never

network_online_timeout es la cantidad de segundos que la ejecución espera a que la red funcione antes de desistir, lo cual es importante en un equipo que acaba de arrancar. random_sleep es una forma antigua de distribuir la carga entre muchas máquinas, y el temporizador realiza esa función actualmente. Ejecute systemctl cat dnf-automatic.service para ver los flags exactos que pasa el servicio instalado.

Compruebe que el archivo hace lo que usted espera, sin esperar hasta las 06:00:

sudo systemctl start dnf-automatic.service
sudo journalctl -u dnf-automatic.service -n 50 --no-pager

El journal muestra lo que la ejecución consideró y lo que hizo. También puede forzar un comportamiento desde la línea de comandos, lo cual sobrescribe el archivo solo para esa ejecución:

sudo dnf-automatic --downloadupdates --no-installupdates

Qué significa realmente upgrade_type = security en Rocky y Alma

DNF no determina si una actualización es de seguridad comparando números de versión. Lee metadatos de erratas: un archivo llamado updateinfo.xml publicado dentro del repositorio, donde cada aviso enumera los paquetes que lo corrigen. AlmaLinux publica estos avisos como ALSA, Rocky los publica como RLSA. upgrade_type = security construye un filtro a partir de esos metadatos y actualiza solo los paquetes que coinciden.

Se derivan dos consecuencias, y ambas sorprenden a los usuarios.

Primero, sin metadatos no hay actualizaciones. Si el repositorio no contiene un updateinfo.xml, el filtro no coincide con nada y la ejecución termina con esta línea en el registro:

No security updates needed, but 3 updates available

El equipo no está parcheado y nada informó de un fallo. Compruébelo usted mismo:

dnf updateinfo list --security
dnf check-update

Si dnf check-update enumera paquetes mientras dnf updateinfo list --security no imprime nada, o bien no hay nada pendiente que contenga un aviso, o el repositorio no tiene datos de avisos para leer. Tanto Rocky como AlmaLinux los publican, por lo que en ambos una lista vacía suele ser correcta. CentOS Stream no los publica en absoluto.

Segundo, el modo de seguridad no es un cambio mínimo. dnf-automatic añade el filtro de seguridad y luego ejecuta la ruta de actualización ordinaria, por lo que un paquete mencionado en un aviso pasa a la versión más reciente del repositorio y arrastra sus dependencias. El paso más pequeño, actualizar solo a la versión más antigua que corrige el aviso, es dnf upgrade-minimal --security ejecutado manualmente. dnf-automatic no tiene una configuración para ello.

Existe una advertencia adicional para Rocky. Rocky genera sus erratas a partir de los datos de Red Hat mediante su propia canalización, y esa canalización se ha retrasado. En septiembre de 2025, los usuarios informaron que el updateinfo.xml de Rocky 9 BaseOS no se había movido desde diciembre de 2024, por lo que --security carecía de avisos recientes, y el personal de Rocky confirmó que era un problema conocido. Si depende de upgrade_type = security, compare la lista de avisos con los anuncios recientes de RLSA de vez en cuando. En un equipo donde la cobertura es más importante que el control de cambios, upgrade_type = default en un horario que usted elija es la configuración más segura.

El temporizador de systemd que lo ejecuta

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

list-timers debería mostrar una fila con una hora NEXT programada para dentro de un día aproximadamente. Una tabla vacía significa que el temporizador no está habilitado, por lo que nunca se ejecutará nada.

El temporizador incluido se dispara a las *-*-* 6:00 con RandomizedDelaySec=60m y Persistent=true. El retardo aleatorio distribuye la carga de un conjunto de servidores a lo largo de una hora para que no todos accedan al espejo en el mismo segundo. Persistent=true significa que una máquina que estaba apagada a las 06:00 ejecutará la tarea pendiente poco después de arrancar, en lugar de saltarse el día.

Cambie la programación mediante un archivo de sustitución (drop-in). No edite la unidad original, ya que una actualización del paquete reemplaza los archivos en /usr/lib/systemd/system.

sudo systemctl edit dnf-automatic.timer

[Timer]
OnCalendar=
OnCalendar=*-*-* 03:30
RandomizedDelaySec=30m

La línea vacía OnCalendar= es obligatoria. OnCalendar es acumulativo, por lo que sin ese reinicio conservaría la entrada de las 06:00 y añadiría una segunda, haciendo que la tarea se ejecute dos veces al día. Confirme el resultado con systemctl list-timers dnf-automatic.timer y lea la columna NEXT. Las mismas reglas de sustitución se aplican a cualquier otra tarea programada, lo cual se detalla en escritura de unidades de servicio y temporizadores de systemd.

Ahora, la trampa. El paquete incluye tres temporizadores adicionales: dnf-automatic-notifyonly.timer, dnf-automatic-download.timer y dnf-automatic-install.timer. Cada uno inicia el mismo programa con parámetros de línea de comandos, y esos parámetros sobrescriben download_updates y apply_updates de su archivo de configuración. Si habilita uno de ellos junto con dnf-automatic.timer, la tarea se ejecutará dos veces con comportamientos distintos, lo que parecerá exactamente como si su archivo de configuración fuera ignorado. Habilite un solo temporizador y verifique:

systemctl list-unit-files 'dnf-automatic*'

¿Cómo sé cuándo se instaló algo?

emit_via en la sección [emitters] controla la generación de informes. En systemd, el emisor stdio escribe en el journal, que es la opción fiable porque no requiere instalar nada más:

sudo journalctl -u dnf-automatic.service --since -7d --no-pager

El emisor motd escribe el informe en /etc/motd y reemplaza el contenido de ese archivo. Si mantiene allí un banner de inicio de sesión, no utilice este emisor.

El emisor email abre una conexión SMTP (simple mail transfer protocol) hacia email_host en el puerto email_port, que por defecto son localhost y 25. Un VPS recién instalado no tiene nada escuchando ahí, por lo que la conexión se rechaza y no se envía ningún correo. Ejecute ss -lnt | grep ':25' antes de confiar en esta opción y configure un Postfix solo para retransmisión (relay) si la salida está vacía. Cuando el correo funciona, el asunto aparece como Updates applied on 'web01'., tomando el nombre de system_name.

Para cualquier otro caso, el emisor command entrega el informe a un programa propio a través de la entrada estándar:

[emitters]
emit_via = stdio, command
system_name = web01.example.com
send_error_messages = yes

[command]
command_format = /usr/local/bin/notify-ops
stdin_format = {body}

send_error_messages tiene como valor predeterminado no, lo que significa que una ejecución fallida no informa nada en absoluto. Actívelo. Un sistema de parches que solo anuncia sus éxitos es peor que no tener ninguno, porque el silencio se interpreta como un estado saludable.

dnf-automatic no reinicia sus servicios

La instalación de un paquete reemplaza los archivos en el disco. Un proceso que ya está en ejecución mantiene el código antiguo en la memoria, por lo que una biblioteca parcheada no tiene efecto en un daemon que se inició el mes pasado. Esa brecha entre lo instalado y lo efectivo es la razón por la que la aplicación de parches desatendida requiere una política de reinicio y no solo una política de instalación.

sudo dnf install -y dnf-plugins-core
dnf needs-restarting -s
dnf needs-restarting -r

-s enumera los servicios de systemd cuyos archivos cambiaron después de su inicio. -r responde a una pregunta e imprime uno de estos dos bloques:

Core libraries or services have been updated since boot-up:
  * kernel
Reboot is required to fully utilize these updates.

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

-r no es un análisis profundo. Comprueba una lista fija de paquetes: kernel, kernel-core, kernel-rt, glibc, linux-firmware, systemd, dbus, dbus-broker, dbus-daemon y microcode_ctl. Si uno de ellos se instaló después del último arranque, obtendrá la primera respuesta. Añada sus propios nombres de paquetes en un archivo que termine en .conf dentro de /etc/dnf/plugins/needs-restarting.d/ cuando otro elemento del sistema también requiera un reinicio para surtir efecto.

Una advertencia para los scripts: dnf needs-restarting -r devuelve un código de salida distinto de cero tanto cuando se requiere un reinicio como cuando el comando en sí ha fallado, por lo que el estado de salida por sí solo no permite distinguirlos. Lea el texto de salida.

Reiniciar un servicio es la acción más sencilla y, por lo general, la correcta. Reinicie el daemon de SSH desde una segunda sesión de SSH que ya esté abierta, para que una configuración incorrecta no le bloquee el acceso. Un kernel nuevo es el caso en el que solo un reinicio ayuda, ya que el kernel en ejecución no puede reemplazarse en caliente.

¿Debería el servidor reiniciarse solo?

[commands]
reboot = when-needed
reboot_command = shutdown -r +5 'Rebooting after applying package updates'

reboot = never es el valor predeterminado. when-changed reinicia el sistema tras aplicar cualquier actualización. when-needed reinicia únicamente cuando la comprobación detrás de needs-restarting -r indica que se ha reemplazado un paquete del núcleo, que es lo que la mayoría de los propietarios de un solo servidor prefieren, junto con una ventana de tiempo programada por ellos mismos. El valor predeterminado reboot_command advierte a los usuarios conectados con cinco minutos de antelación mediante shutdown, y es posible ampliar este margen.

Defina dos aspectos antes de activar esta función. Cada servicio del que dependa debe iniciarse automáticamente durante el arranque, lo cual suele ser la carencia habitual en una pila de Docker Compose iniciada manualmente. Además, necesita acceso a la consola o al modo de rescate de su proveedor, ya que un kernel que no arranca no puede repararse mediante SSH. Si falta alguno de estos requisitos, mantenga reboot = never y realice el reinicio usted mismo tras consultar el registro.

Rocky, AlmaLinux y CentOS Stream: diferencias entre ellos

En Rocky 9 y AlmaLinux 9 todo lo anterior es idéntico, incluyendo la ruta de configuración y los nombres de las unidades. Ambos publican erratas, por lo que upgrade_type = security dispone de datos para filtrar.

CentOS Stream es la excepción, y es una importante. Los repositorios de Stream no contienen updateinfo.xml, por lo que el filtro de seguridad nunca encontrará coincidencias y cada ejecución informará No security updates needed. En Stream, utilice upgrade_type = default y acepte que está aplicando todas las actualizaciones. Stream también se ejecuta por delante de RHEL, por lo que esa configuración cambia con mayor frecuencia en un equipo con Stream que la misma configuración en Rocky o AlmaLinux.

Rocky 10 y AlmaLinux 10 migraron a DNF5, lo cual cambia los nombres de los elementos. La documentación oficial de DNF5 indica que el temporizador es dnf5-automatic.timer, sitúa los valores predeterminados de fábrica en /usr/share/dnf5/dnf5-plugins/automatic.conf mientras que sus anulaciones siguen en /etc/dnf/automatic.conf, establece download_updates como yes en lugar de no, y añade distro-sync como un upgrade_type. La consulta de avisos es dnf advisory list, manteniendo updateinfo como alias. Confirme qué versión tiene instalada realmente antes de copiar nombres de paquetes o unidades de una guía escrita para la versión 9:

dnf list --available '*automatic*'
systemctl list-unit-files '*automatic*'

Muchas guías publicadas sobre este tema todavía cubren únicamente Rocky 8. El conjunto de opciones ha crecido desde que se redactaron, así que revise el archivo comentado en su propio equipo en lugar de confiar en un artículo antiguo.

Modos de fallo y las cadenas que verá

Nada se ejecuta. systemctl list-timers dnf-automatic.timer muestra una tabla vacía y systemctl is-enabled dnf-automatic.timer imprime disabled. El paquete se instaló, pero el temporizador nunca lo hizo.

El trabajo se ejecuta y no instala nada. El registro contiene No security updates needed, but 3 updates available. El filtro de seguridad no encontró coincidencias, ya sea porque nada de lo pendiente tiene un aviso o porque el repositorio no publica datos de avisos.

Un ajuste parece ignorado. DNF registra una opción desconocida en automatic.conf al nivel de depuración y luego utiliza el valor predeterminado, por lo que una clave mal escrita no cambia nada y no avisa a nadie. Escriba apply_update = yes y apply_updates permanece en no, por lo que el equipo descarga indefinidamente y nunca instala. Después de cualquier edición, ejecute sudo systemctl start dnf-automatic.service y lea el registro en lugar de confiar en el archivo.

El trabajo se ejecuta dos veces al día. Hay dos temporizadores habilitados. systemctl list-unit-files 'dnf-automatic*' muestra cuáles, y los adicionales pasan indicadores que anulan su archivo de configuración.

No llega ningún correo. O bien no hay nada escuchando en el puerto 25 para el emisor email, o send_error_messages sigue en no y lo único que merecía la pena informar era un error.

Un servicio parcheado sigue informando la versión antigua. El archivo en el disco es nuevo y el proceso en memoria es el antiguo. dnf needs-restarting -s nombra los servicios que debe reiniciar.

FAQ

¿dnf-automatic instala solo actualizaciones de seguridad en Rocky Linux?

Solo si configura upgrade_type = security en /etc/dnf/automatic.conf, y solo si sus repositorios publican metadatos de erratas. Tanto Rocky Linux como AlmaLinux los publican, por lo que el filtro dispone de avisos con los cuales realizar la comparación. El valor predeterminado de fábrica es upgrade_type = default, que instala todas las actualizaciones disponibles una vez que apply_updates = yes.

¿Por qué dnf-automatic informa "No security updates needed, but 3 updates available"?

DNF determina qué cuenta como actualización de seguridad leyendo updateinfo.xml del repositorio, donde cada aviso enumera los paquetes que lo corrigen. Cuando estos metadatos faltan o están desactualizados, el filtro de seguridad no encuentra coincidencias mientras hay actualizaciones ordinarias pendientes, lo que genera exactamente esa línea. Es un comportamiento esperado en CentOS Stream, que no publica erratas en absoluto. En Rocky o AlmaLinux, compare dnf updateinfo list --security con dnf check-update y verifique que sus metadatos estén al día.

¿dnf-automatic reiniciará mi servidor tras una actualización del kernel?

No, a menos que usted lo solicite. La opción reboot tiene como valor predeterminado never. Configure reboot = when-needed y la ejecución solo reiniciará cuando la comprobación detrás de dnf needs-restarting -r detecte que un paquete central como kernel o glibc fue reemplazado desde el arranque. reboot = when-changed reinicia tras cualquier actualización aplicada. Ambos utilizan reboot_command, que por defecto es shutdown -r +5 con un mensaje de advertencia para los usuarios que hayan iniciado sesión.

¿Cómo cambio la hora en la que se ejecuta dnf-automatic?

Ejecute sudo systemctl edit dnf-automatic.timer y añada una sección [Timer] con una línea OnCalendar= vacía seguida de su programación, por ejemplo OnCalendar=*-*-* 03:30. La línea vacía es necesaria porque OnCalendar se acumula, por lo que omitirla mantendría la ejecución de las 06:00 de fábrica y añadiría una segunda. Verifique con systemctl list-timers dnf-automatic.timer y lea la columna NEXT.

¿Todavía necesito revisar un servidor que se parchea a sí mismo?

Sí. dnf-automatic instala paquetes y se detiene ahí. No reinicia daemons y no informa de nada que usted verá a menos que emit_via nombre un emisor que usted realmente lea. Configure emit_via a stdio como mínimo, active send_error_messages para que también se informen los fallos, y ejecute dnf needs-restarting -s después de una ventana de parcheo para encontrar servicios que aún ejecutan código antiguo.