dnf-automatic: actualizaciones de seguridad en Rocky y

Qué hace dnf-automatic en Rocky Linux y AlmaLinux

dnf-automatic permite instalar actualizaciones de seguridad sin intervención en Rocky Linux y AlmaLinux. Es un programa pequeño que inicia un temporizador de systemd, lee /etc/dnf/automatic.conf y aplica lo que permite ese archivo. La instalación requiere un solo comando. El resto de esta guía trata sobre los ajustes que determinan si protege el servidor o no hace nada silenciosamente.

Si viene de Debian o Ubuntu, cumple la misma función que unattended-upgrades en un VPS de Ubuntu. Hay una diferencia más importante que las demás: el significado de la palabra "seguridad" para el gestor de paquetes. En Ubuntu, es un archivo independiente del repositorio. En la familia RHEL, son metadatos asociados a avisos publicados, y esos metadatos pueden faltar o estar desactualizados. Si configura dnf-automatic para usar un repositorio sin datos de avisos, no instala nada aunque informe de que la operación se realizó correctamente.

Esta guía se basa en Rocky Linux 9 y AlmaLinux 9, que usan DNF 4 (DNF es el gestor de paquetes de la familia RHEL), a fecha de agosto de 2026. Las versiones 10 cambiaron a DNF5 y los nombres son distintos, por lo que tienen su propia sección casi al final. Cada comando siguiente debe ejecutarlo en su propio servidor; junto a él se muestra la salida esperada.

Instale dnf-automatic y lea la configuración incluida

La activación de las actualizaciones automáticas forma parte del resto de la configuración de los primeros diez minutos en un VPS nuevo, justo después de crear un usuario que no sea root y configurar un firewall. Si todavía falta configurar el firewall, firewalld es el firewall incluido en Rocky y AlmaLinux, y unos pocos comandos permiten SSH, abren el puerto en el que escucha el sitio y hacen que ambas reglas sobrevivan a un reinicio.

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 nueva, porque la instalación del paquete no inicia ningún servicio. Esta es la razón más habitual por la que un servidor que «tiene dnf-automatic» nunca ha aplicado una sola actualización.

La versión de DNF es importante para una opción. La configuración reboot llegó al proyecto original en DNF 4.15, y Red Hat la incorporó mediante backport en dnf-4.14.0-6.el9 en noviembre de 2023 a través del aviso RHBA-2023:6645. Rocky 9 y AlmaLinux 9 recompilan ese paquete, por lo que un sistema actualizado la incluye y uno que no se ha actualizado desde 2023 no.

El archivo de configuración es /etc/dnf/automatic.conf. La copia incluida muestra todas las opciones que entiende esta compilación, con su valor predeterminado comentado. Léalo una vez antes de editarlo, porque ese archivo refleja exactamente lo que admite su versión.

Los dos interruptores que deciden el comportamiento

download_updates y apply_updates de la sección [commands] deciden el comportamiento. En EL9 (enterprise Linux 9, la base común de Rocky 9 y AlmaLinux 9), ambos están no de forma predeterminada, por lo que un dnf-automatic sin editar que habilite sólo le indicará qué actualizaciones están disponibles.

• Ambos no: dnf-automatic informa de las actualizaciones disponibles y no cambia nada en el sistema.
• download_updates = yes con apply_updates = no: los paquetes se descargan en la caché de DNF. La instalación posterior es rápida y no necesita red, pero esa noche no se cambia nada.
• Ambos yes con upgrade_type = default: se instala cada actualización disponible, tenga relación con la seguridad o no.
• Ambos yes con upgrade_type = security: sólo se instalan los paquetes incluidos 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 el número de segundos que la ejecución espera a que haya una red operativa antes de abandonar. Esto es importante en un sistema que acaba de arrancar. random_sleep es una forma antigua de distribuir la carga entre varios equipos, y ahora el temporizador realiza esa tarea. Ejecute systemctl cat dnf-automatic.service para ver los indicadores exactos que pasa el servicio proporcionado.

Compruebe que el archivo hace lo que espera sin tener que 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 evaluó y las acciones que realizó. También puede forzar un comportamiento desde la línea de comandos. Esto sólo sobrescribe el archivo durante 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 los metadatos de erratas: un archivo llamado updateinfo.xml que se publica dentro del repositorio. Cada aviso enumera los paquetes que lo corrigen. AlmaLinux publica estos avisos como avisos ALSA y Rocky los publica como RLSA. upgrade_type = security crea un filtro a partir de esos metadatos y actualiza sólo los paquetes que coinciden.

De aquí se derivan dos consecuencias que suelen sorprender.

Primero, sin metadatos no hay actualizaciones. Si el repositorio no contiene ningún updateinfo.xml, el filtro no encuentra coincidencias y la ejecución termina con esta línea en el journal:

No security updates needed, but 3 updates available

El sistema no está actualizado y no se informó ningún error. Compruébelo:

dnf updateinfo list --security
dnf check-update

Si dnf check-update muestra paquetes y dnf updateinfo list --security no imprime nada, puede que ninguna actualización pendiente tenga un aviso asociado o que el repositorio no tenga datos de avisos que consultar. Rocky y AlmaLinux publican estos datos, por lo que en ambos sistemas una lista vacía suele ser correcta. CentOS Stream no los publica.

Segundo, el modo de seguridad no aplica un cambio mínimo. dnf-automatic añade el filtro de seguridad y después ejecuta la ruta de actualización normal. Por tanto, un paquete incluido en un aviso se actualiza a la versión más reciente del repositorio y también instala sus dependencias. El cambio más reducido, que consiste en actualizar sólo hasta la primera versión que corrige el aviso, se ejecuta con dnf upgrade-minimal --security manualmente. dnf-automatic no tiene una opción para hacerlo.

Hay otra consideración aplicable a Rocky. Rocky genera sus erratas a partir de datos de Red Hat mediante su propia canalización, y esa canalización se ha quedado atrasada. En septiembre de 2025, los usuarios informaron de que el updateinfo.xml de Rocky 9 BaseOS no había cambiado desde diciembre de 2024. Por ello, --security no incluía avisos recientes, y el personal de Rocky confirmó que se trataba de un problema conocido. Si depende de upgrade_type = security, compare periódicamente la lista de avisos con los anuncios RLSA recientes. En un sistema donde la cobertura sea más importante que el control de cambios, upgrade_type = default con la periodicidad que elija es la opción más segura.

El temporizador de systemd que realmente 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 aproximadamente un día posterior. Una tabla vacía significa que el temporizador no está habilitado y, por tanto, nunca se ejecutará.

El temporizador incluido se ejecuta a las *-*-* 6:00 con RandomizedDelaySec=60m y Persistent=true. El retraso aleatorio distribuye los servidores de una flota durante una hora, para que no todos accedan al mirror en el mismo segundo. Persistent=true significa que una máquina apagada a las 06:00 ejecuta el trabajo omitido poco después de arrancar, en lugar de saltarse ese día.

Cambie la programación con un drop-in. No edite la unidad incluida, porque una actualización del paquete reemplaza los archivos de /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 acumula los valores. Sin ese restablecimiento, conserva la entrada de las 06:00 y añade una segunda, por lo que el trabajo se ejecuta dos veces al día. Confirme el resultado con systemctl list-timers dnf-automatic.timer y lea la columna NEXT. Las mismas reglas para drop-ins se aplican a cualquier otra tarea que programe. Se explica en cómo escribir unidades de servicio y temporizador de systemd.

Ahora, la trampa. El paquete incluye otros tres temporizadores: dnf-automatic-notifyonly.timer, dnf-automatic-download.timer y dnf-automatic-install.timer. Cada uno inicia el mismo programa con opciones de línea de comandos, y esas opciones sobrescriben download_updates y apply_updates del archivo de configuración. Habilite uno junto con dnf-automatic.timer y el trabajo se ejecutará dos veces con comportamientos diferentes. Esto parece exactamente que se está ignorando el archivo de configuración. Habilite un temporizador y compruebe:

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

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

emit_via de la sección [emitters] controla los informes. En systemd, el emisor stdio escribe en el journal. Es la opción más 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 incluya este emisor.

El emisor email abre una conexión SMTP (protocolo simple de transferencia de correo) con email_host en email_port. De forma predeterminada, estos valores son localhost y 25. Un VPS recién creado no tiene nada escuchando allí, por lo que la conexión se rechaza y no se envía ningún correo. Ejecute ss -lnt | grep ':25' antes de depender de esta función y configure un Postfix de solo retransmisión si la salida está vacía. Cuando el correo funciona, el asunto es Updates applied on 'web01'. y toma el nombre de system_name.

Para cualquier otro caso, el emisor command entrega el informe a uno de sus programas mediante 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}

De forma predeterminada, send_error_messages tiene el valor no, lo que significa que una ejecución fallida no informa de nada. Actívelo. Un sistema de aplicación de parches que solo anuncia sus éxitos es peor que no tener ninguno, porque el silencio parece indicar que todo funciona.

dnf-automatic no reinicia los servicios

Instalar un paquete reemplaza archivos en el disco. Un proceso que ya está en ejecución conserva el código antiguo en memoria, por lo que una biblioteca corregida no tiene efecto en un daemon que se inició el mes pasado. Esta diferencia entre lo instalado y lo efectivo explica por qué la aplicación automática de parches necesita una política de reinicio, no sólo una política de instalación.

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

-s muestra los servicios de systemd cuyos archivos cambiaron después de iniciarse. -r responde a una pregunta y muestra uno de 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 realiza un análisis detallado. 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, se obtiene 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 componente del sistema también necesite un reinicio para que el cambio sea efectivo.

Hay una salvedad para los scripts: dnf needs-restarting -r termina con un estado distinto de cero tanto cuando se necesita reiniciar como cuando el propio comando falla, por lo que el estado de salida por sí solo no permite distinguir ambos casos. Lea el texto de salida.

Reiniciar un servicio es la medida menor y normalmente la adecuada. Reinicie el daemon de SSH desde una segunda sesión de SSH que ya esté abierta, para que una configuración incorrecta no le impida acceder al sistema. Un kernel nuevo es el caso en el que sólo sirve reiniciar el sistema, porque el kernel en ejecución no se puede reemplazar directamente. Si quiere clasificar las actualizaciones de una mañana concreta en esos dos grupos, qué actualizaciones requieren reiniciar y cuáles sólo requieren reiniciar un servicio explica cómo revisar la salida paquete por paquete.

Los contenedores son un caso distinto, porque dnf-automatic aplica parches a los paquetes del host y nunca modifica el espacio de usuario incluido en una imagen. Por tanto, un sistema que ejecuta Docker Engine en Rocky Linux o AlmaLinux también necesita volver a descargar las imágenes y recrear los contenedores antes de que una corrección llegue al código que realmente atiende el tráfico.

¿Debe el servidor reiniciarse por sí 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 después de cualquier actualización aplicada. when-needed sólo reinicia cuando la comprobación asociada a needs-restarting -r indica que se reemplazó un paquete principal. Es lo que quieren la mayoría de los administradores de un solo servidor, junto con una ventana del temporizador que hayan elegido. El valor predeterminado de reboot_command avisa con cinco minutos de antelación a los usuarios que han iniciado sesión mediante shutdown. Puede ampliar ese plazo.

Antes de activar esta opción, resuelva dos cuestiones. Todos los servicios de los que depende deben iniciarse automáticamente durante el arranque. Esta es la deficiencia habitual de una pila de Docker Compose iniciada manualmente. También necesita acceso a la consola o al modo de rescate del proveedor, porque un kernel que no arranca no se puede reparar mediante SSH. Si falta cualquiera de estos requisitos, mantenga reboot = never y reinicie manualmente después de revisar el journal.

Rocky, AlmaLinux y CentOS Stream: diferencias

En Rocky 9 y AlmaLinux 9 todo lo anterior es idéntico, incluida la ruta de configuración y los nombres de las unidades. Ambos publican erratas, por lo que upgrade_type = security contiene datos que se pueden filtrar. Las erratas obsoletas de Rocky descritas antes son uno de los pocos puntos en los que su comportamiento diario realmente difiere. Si el servidor todavía no está instalado, tenga en cuenta también la promesa de compatibilidad y la compatibilidad con CPU antiguas que los diferencian.

CentOS Stream es la excepción, y la diferencia es importante. Los repositorios de Stream no contienen updateinfo.xml, por lo que el filtro de seguridad nunca puede coincidir y cada ejecución informa de No security updates needed. En Stream, use upgrade_type = default y acepte que instalará todas las actualizaciones. Stream también va por delante de RHEL, por lo que ese ajuste cambia más en un servidor Stream que en uno con Rocky o AlmaLinux. Esta diferencia no se debe al empaquetado. Es consecuencia de la decisión de Red Hat de 2020 de convertir CentOS en una vista previa continua de RHEL. Es la misma decisión que dio lugar a Rocky Linux y AlmaLinux.

Rocky 10 y AlmaLinux 10 pasaron a DNF5, que cambia algunos nombres. La documentación de DNF5 indica que el temporizador es dnf5-automatic.timer, que los valores predeterminados incluidos se encuentran en /usr/share/dnf5/dnf5-plugins/automatic.conf y que las sobrescrituras siguen en /etc/dnf/automatic.conf. También establece download_updates en yes en lugar de no y añade distro-sync como upgrade_type. La consulta de avisos es dnf advisory list, y updateinfo se conserva como alias. Confirme qué instaló realmente su versión 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 sólo Rocky 8. El conjunto de opciones ha crecido desde que se redactaron. Revise el archivo comentado en su propio servidor en lugar de confiar en un artículo antiguo.

Modos de fallo y cadenas que verá

No se ejecuta nada. systemctl list-timers dnf-automatic.timer muestra una tabla vacía y systemctl is-enabled dnf-automatic.timer muestra disabled. El paquete está instalado, pero el temporizador nunca se instaló.

El trabajo se ejecuta y no instala nada. El journal contiene No security updates needed, but 3 updates available. El filtro de seguridad no encontró coincidencias porque ningún paquete pendiente tiene un aviso de seguridad o porque el repositorio no publica datos de avisos.

Una configuración parece ignorarse. DNF registra una opción desconocida en automatic.conf con el nivel de depuración y usa el valor predeterminado. Por tanto, una clave mal escrita no cambia nada ni genera advertencias. Escriba apply_update = yes y apply_updates se mantiene en no, por lo que el equipo descarga continuamente y nunca instala nada. Después de editar el archivo, ejecute sudo systemctl start dnf-automatic.service y revise el journal 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 son, y los adicionales pasan indicadores que prevalecen sobre el archivo de configuración.

No llega ningún correo. No hay ningún proceso escuchando en el puerto 25 para el emisor email, o send_error_messages sigue en no y lo único que merecía informarse era un error.

Un servicio actualizado sigue mostrando la versión anterior. El archivo del disco es nuevo, pero el proceso en memoria es antiguo. dnf needs-restarting -s indica qué servicios se deben reiniciar.

FAQ

¿dnf-automatic instala sólo actualizaciones de seguridad en Rocky Linux?

Sólo si establece upgrade_type = security en /etc/dnf/automatic.conf y sus repositorios publican metadatos de erratas. Rocky Linux y AlmaLinux los publican, por lo que el filtro tiene avisos con los que comparar. El valor predeterminado incluido es upgrade_type = default, que instala todas las actualizaciones disponibles cuando apply_updates = yes.

¿Por qué dnf-automatic muestra «No security updates needed, but 3 updates available»?

DNF determina qué cuenta como una actualización de seguridad leyendo updateinfo.xml del repositorio. Cada aviso contiene los paquetes que lo corrigen. Cuando faltan esos metadatos o están desactualizados, el filtro de seguridad no encuentra coincidencias, mientras las actualizaciones normales siguen pendientes. Por eso aparece exactamente esa línea. Es normal en CentOS Stream, que no publica erratas. En Rocky o AlmaLinux, compare dnf updateinfo list --security con dnf check-update y compruebe que los metadatos estén actualizados.

¿dnf-automatic reiniciará mi servidor después de actualizar el kernel?

No, a menos que se lo indique. La opción reboot tiene never como valor predeterminado. Establezca reboot = when-needed para que una ejecución reinicie el sistema sólo cuando la comprobación de dnf needs-restarting -r detecte que un paquete esencial, como kernel o glibc, fue reemplazado desde el arranque. reboot = when-changed reinicia el sistema después de aplicar cualquier actualización. Ambas opciones usan reboot_command, cuyo valor predeterminado es shutdown -r +5, con un mensaje de advertencia para los usuarios conectados.

¿Cómo cambio la hora a 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 acumula valores. Si la omite, conserva la ejecución incluida de las 06:00 y añade una segunda. Verifique la configuración con systemctl list-timers dnf-automatic.timer y lea la columna NEXT.

¿Tengo que seguir comprobando un servidor que instala sus propias actualizaciones?

Sí. dnf-automatic instala paquetes y se detiene ahí. No reinicia los servicios y no informa de nada que pueda ver, a menos que emit_via nombre un emisor que realmente consulte. Establezca como mínimo emit_via en stdio, active send_error_messages para informar también de los errores y ejecute dnf needs-restarting -s después de una ventana de actualización para encontrar servicios que sigan ejecutando código antiguo.