dnf-automatic: atualizações de segurança no Rocky e Alma

O que o dnf-automatic faz no Rocky Linux e no AlmaLinux

O dnf-automatic é a forma de obter atualizações de segurança não assistidas no Rocky Linux e no AlmaLinux. É um programa pequeno, iniciado por um temporizador do systemd, que lê /etc/dnf/automatic.conf e aplica o que esse ficheiro permite. A instalação requer um comando. O restante deste guia explica as definições que determinam se o sistema fica protegido ou se o programa não faz nada silenciosamente.

Se veio do Debian ou do Ubuntu, esta é a mesma função que o unattended-upgrades desempenha numa VPS Ubuntu. Há uma diferença mais importante do que todas as outras: o significado de "segurança" para o gestor de pacotes. No Ubuntu, trata-se de um pocket separado do arquivo. Na família RHEL, são metadados associados aos avisos publicados, e esses metadados podem estar ausentes ou desatualizados. Se apontar o dnf-automatic para um repositório sem dados de avisos, ele não instala nada, embora indique que a operação foi concluída com sucesso.

Este guia foi escrito para Rocky Linux 9 e AlmaLinux 9, que usam o DNF 4 (o DNF é o gestor de pacotes da família RHEL), em agosto de 2026. As versões 10 passaram para o DNF5 e os nomes mudam nessa versão, por isso têm uma secção própria perto do final. Cada comando abaixo deve ser executado no seu próprio sistema, com o resultado esperado apresentado ao lado.

Instale o dnf-automatic e leia a configuração incluída no pacote

Ativar atualizações automáticas faz parte do restante da configuração nos primeiros dez minutos num novo VPS, logo depois de criar um utilizador que não seja root e configurar uma firewall.

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

systemctl is-enabled mostra disabled numa instalação nova, porque instalar o pacote não inicia nada. Esta é a razão mais comum para um servidor que «tem o dnf-automatic» nunca ter aplicado uma única atualização.

A versão do DNF é relevante para uma opção. A definição reboot foi introduzida a montante no DNF 4.15, e a Red Hat fez o backport para dnf-4.14.0-6.el9 em novembro de 2023 através do aviso RHBA-2023:6645. O Rocky 9 e o AlmaLinux 9 recompilam esse pacote, por isso um sistema atualizado já tem essa opção, mas um sistema que não recebe atualizações desde 2023 não tem.

O ficheiro de configuração é /etc/dnf/automatic.conf. A cópia incluída no pacote lista todas as opções que esta compilação compreende, com o respetivo valor predefinido, comentado. Leia-a uma vez antes de a editar, porque esse ficheiro é a referência correta para a sua versão.

As duas opções que determinam o comportamento

download_updates e apply_updates na secção [commands] determinam o comportamento. Ambas ficam no por predefinição no EL9 (enterprise Linux 9, a base partilhada do Rocky 9 e do AlmaLinux 9), pelo que um dnf-automatic sem alterações que seja ativado apenas informa sobre o que está disponível.

• Ambas no: o dnf-automatic informa sobre as atualizações disponíveis e não altera nada no sistema.
• download_updates = yes com apply_updates = no: os pacotes são transferidos para a cache do DNF. A instalação fica rápida e não precisa de rede, mas nada foi alterado durante a noite.
• Ambas yes com upgrade_type = default: todas as atualizações disponíveis são instaladas, sejam de segurança ou não.
• Ambas yes com upgrade_type = security: apenas os pacotes indicados num aviso de segurança são instalados.

Um ponto de partida razoável para um VPS exposto publicamente:

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

network_online_timeout indica durante quantos segundos a execução aguarda por uma rede funcional antes de desistir. Isto é importante num servidor que acabou de arrancar. random_sleep é uma forma mais antiga de distribuir a carga por várias máquinas; atualmente, o timer desempenha essa função. Execute systemctl cat dnf-automatic.service para ver as opções exatas que o serviço fornecido passa.

Confirme que o ficheiro faz o que espera sem ter de aguardar até às 06:00:

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

O journal mostra o que a execução analisou e o que fez. Também pode forçar um comportamento a partir da linha de comandos. Essa opção substitui o ficheiro apenas durante essa execução:

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

O que upgrade_type = security realmente significa no Rocky e no Alma

O DNF não determina se uma atualização é de segurança comparando números de versão. Lê metadados de erratas: um ficheiro chamado updateinfo.xml publicado dentro do repositório, onde cada aviso lista os pacotes que o corrigem. O AlmaLinux publica estes avisos como avisos ALSA, e o Rocky publica-os como RLSA. upgrade_type = security cria um filtro a partir desses metadados e atualiza apenas os pacotes correspondentes.

Daqui resultam duas consequências, e ambas surpreendem muitos utilizadores.

Primeiro, sem metadados não existem atualizações. Se o repositório não tiver nenhum updateinfo.xml, o filtro não encontra correspondências e a execução termina com esta linha no journal:

No security updates needed, but 3 updates available

O servidor não foi corrigido e nada indicou uma falha. Confirme:

dnf updateinfo list --security
dnf check-update

Se dnf check-update listar pacotes enquanto dnf updateinfo list --security não imprimir absolutamente nada, ou não há atualizações pendentes associadas a um aviso, ou o repositório não tem dados de avisos para consultar. O Rocky e o AlmaLinux publicam esses dados, por isso, nesses dois sistemas, uma lista vazia é normalmente legítima. O CentOS Stream não os publica.

Segundo, o modo de segurança não aplica uma alteração mínima. O dnf-automatic adiciona o filtro de segurança e executa depois o fluxo normal de atualização. Assim, um pacote mencionado num aviso passa para a versão mais recente disponível no repositório e instala também as respetivas dependências. A alteração mais pequena, que consiste em passar apenas para a primeira versão que corrige o aviso, é dnf upgrade-minimal --security executada manualmente. O dnf-automatic não tem uma opção para isso.

Há ainda uma ressalva relativa ao Rocky. O Rocky gera as suas erratas a partir de dados da Red Hat através de um pipeline próprio, e esse pipeline ficou atrasado. Em setembro de 2025, utilizadores comunicaram que o updateinfo.xml do Rocky 9 BaseOS não era atualizado desde dezembro de 2024. Por isso, --security não continha avisos recentes, e a equipa do Rocky confirmou que se tratava de um problema conhecido. Se depender de upgrade_type = security, compare periodicamente a lista de avisos com os anúncios RLSA recentes. Num servidor em que a cobertura seja mais importante do que o controlo das alterações, upgrade_type = default com a periodicidade que escolher é a opção mais segura.

O timer do systemd que realmente o executa

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

list-timers deve mostrar uma linha com um horário NEXT aproximadamente a um dia de distância. Uma tabela vazia significa que o timer não está ativado, portanto nada será executado.

O timer fornecido é executado em *-*-* 6:00 com RandomizedDelaySec=60m e Persistent=true. O atraso aleatório distribui os servidores por uma hora, para que todos não consultem o mirror no mesmo segundo. Persistent=true significa que uma máquina desligada às 06:00 executa o trabalho perdido pouco depois de arrancar, em vez de o ignorar nesse dia.

Altere o agendamento com um drop-in. Não edite a unidade fornecida, porque uma atualização do pacote substitui os ficheiros em /usr/lib/systemd/system.

sudo systemctl edit dnf-automatic.timer

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

A linha OnCalendar= vazia é necessária. OnCalendar acumula entradas. Sem esse reset, mantém a entrada das 06:00 e adiciona uma segunda entrada, fazendo com que o trabalho seja executado duas vezes por dia. Confirme o resultado com systemctl list-timers dnf-automatic.timer e leia a coluna NEXT. As mesmas regras de drop-in aplicam-se a tudo o que agendar. Isto é abordado em escrever unidades de serviço e timer do systemd.

Agora, a armadilha. O pacote fornece mais três timers: dnf-automatic-notifyonly.timer, dnf-automatic-download.timer e dnf-automatic-install.timer. Cada um inicia o mesmo programa com flags de linha de comandos, e essas flags substituem download_updates e apply_updates do seu ficheiro de configuração. Ative um deles juntamente com dnf-automatic.timer e o trabalho será executado duas vezes, com dois comportamentos diferentes. Isto parece exatamente que o seu ficheiro de configuração está a ser ignorado. Ative um timer e verifique:

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

Como saber quando algo foi instalado?

emit_via na seção [emitters] controla os relatórios. No systemd, o emissor stdio escreve no journal. Esta é a opção mais confiável porque não requer a instalação de mais nada:

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

O emissor motd escreve o relatório em /etc/motd e substitui o conteúdo desse ficheiro. Se mantiver aí um banner de login, não use este emissor.

O emissor email abre uma ligação SMTP (simple mail transfer protocol) para email_host na porta email_port. Por predefinição, estes valores são localhost e 25. Um VPS novo não tem nada a escutar nessa porta, por isso a ligação é recusada e nenhum email é enviado. Execute ss -lnt | grep ':25' antes de depender deste emissor e configure um Postfix apenas para relay se a saída estiver vazia. Quando o envio de email funciona, o assunto é Updates applied on 'web01'. e o nome é obtido de system_name.

Para qualquer outro destino, o emissor command entrega o relatório a um programa seu através da entrada padrão:

[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 tem como predefinição no, o que significa que uma execução falhada não produz nenhum relatório. Ative esta opção. Um sistema de aplicação de patches que apenas anuncia os sucessos é pior do que não ter sistema nenhum, porque o silêncio parece indicar que está tudo saudável.

dnf-automatic não reinicia os seus serviços

A instalação de um pacote substitui ficheiros no disco. Um processo que já está em execução mantém o código antigo na memória, por isso uma biblioteca corrigida não tem efeito num daemon iniciado no mês passado. Essa diferença entre estar instalado e estar efetivamente em uso explica por que motivo a aplicação automática de patches precisa de uma política de reinício, e não apenas de uma política de instalação.

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

-s lista os serviços systemd cujos ficheiros foram alterados depois de terem sido iniciados. -r responde a uma pergunta e apresenta um de dois blocos:

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 não faz uma análise aprofundada. Verifica uma lista fixa de pacotes: kernel, kernel-core, kernel-rt, glibc, linux-firmware, systemd, dbus, dbus-broker, dbus-daemon e microcode_ctl. Se um deles tiver sido instalado depois do último boot, é apresentada a primeira resposta. Adicione os seus próprios nomes de pacotes num ficheiro terminado em .conf, em /etc/dnf/plugins/needs-restarting.d/, quando outro componente do sistema também precisar de um reboot para que as alterações tenham efeito.

Existe uma ressalva para scripts: dnf needs-restarting -r termina com um código diferente de zero tanto quando é necessário um reboot como quando o próprio comando falha. Por isso, o código de saída, por si só, não permite distinguir os dois casos. Leia o texto apresentado.

Reiniciar um serviço é a alteração menor e, normalmente, a opção correta. Reinicie o daemon SSH a partir de uma segunda sessão SSH que já esteja aberta, para que uma configuração inválida não o impeça de aceder ao sistema. Um kernel novo é o caso em que apenas um reboot resolve, porque o kernel em execução não pode ser substituído enquanto o sistema está ativo.

A máquina deve reiniciar sozinha?

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

reboot = never é o padrão. when-changed reinicia depois de qualquer atualização aplicada. when-needed reinicia apenas quando a verificação por trás de needs-restarting -r indica que um pacote principal foi substituído, que é o comportamento pretendido pela maioria dos administradores de um único servidor, combinado com uma janela do temporizador escolhida pelo próprio administrador. O padrão reboot_command avisa os utilizadores com sessão iniciada com cinco minutos de antecedência através de shutdown. Pode aumentar esse período.

Resolva duas questões antes de ativar esta opção. Todos os serviços dos quais depende têm de arrancar automaticamente no boot. Esta é a falha habitual numa stack do Docker Compose iniciada manualmente. Também precisa de acesso à consola ou ao modo de recuperação do fornecedor, porque não é possível corrigir por SSH um kernel que não arranca. Se faltar alguma destas condições, mantenha reboot = never e reinicie manualmente depois de consultar o journal.

Rocky, AlmaLinux e CentOS Stream: diferenças

No Rocky 9 e no AlmaLinux 9, tudo o que foi descrito acima é idêntico, incluindo o caminho da configuração e os nomes das unidades. Ambos publicam errata, por isso upgrade_type = security tem dados para filtrar.

O CentOS Stream é a exceção, e é uma exceção importante. Os repositórios do Stream não contêm updateinfo.xml, por isso o filtro de segurança nunca encontra correspondências e todas as execuções reportam No security updates needed. No Stream, use upgrade_type = default e aceite que serão aplicadas todas as atualizações. O Stream também está à frente do RHEL, por isso essa definição altera mais coisas num sistema Stream do que a mesma definição num sistema Rocky ou AlmaLinux.

O Rocky 10 e o AlmaLinux 10 passaram para DNF5, que renomeia alguns elementos. A documentação upstream do DNF5 define o temporizador como dnf5-automatic.timer, coloca os valores predefinidos fornecidos pelo pacote em /usr/share/dnf5/dnf5-plugins/automatic.conf, mantendo as suas substituições em /etc/dnf/automatic.conf, define download_updates como yes em vez de no e adiciona distro-sync como upgrade_type. A consulta de avisos é dnf advisory list, mantendo updateinfo como alias. Confirme o que a sua versão realmente instalou antes de copiar nomes de pacotes ou unidades de um guia escrito para a versão 9:

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

Muitos guias publicados sobre este tema ainda abrangem apenas o Rocky 8. O conjunto de opções aumentou desde que esses guias foram escritos. Consulte o ficheiro comentado no seu próprio sistema em vez de confiar num artigo antigo.

Modos de falha e mensagens que verá

Nada é executado. systemctl list-timers dnf-automatic.timer apresenta uma tabela vazia e systemctl is-enabled dnf-automatic.timer apresenta disabled. O pacote foi instalado, mas o timer nunca foi instalado.

O job é executado, mas não instala nada. O journal contém No security updates needed, but 3 updates available. O filtro de segurança não encontrou correspondências, porque nada pendente tem um advisory ou porque o repositório não publica dados de advisories.

Uma definição parece ser ignorada. O DNF regista uma opção desconhecida em automatic.conf no nível de debug e usa o valor predefinido. Por isso, uma chave escrita incorretamente não altera nada nem gera um aviso. Escreva apply_update = yes e apply_updates permanece em no, por isso o sistema descarrega indefinidamente e nunca instala nada. Depois de qualquer alteração, execute sudo systemctl start dnf-automatic.service e consulte o journal em vez de confiar no ficheiro.

O job é executado duas vezes por dia. Há dois timers ativados. systemctl list-unit-files 'dnf-automatic*' mostra quais são, e os timers adicionais passam flags que têm precedência sobre o seu ficheiro de configuração.

Não chega nenhum email. Ou não há nada a escutar na porta 25 para o emissor email, ou send_error_messages continua em no e a única ocorrência que valia a pena comunicar foi um erro.

Um serviço corrigido continua a indicar a versão antiga. O ficheiro no disco é novo, mas o processo em memória é antigo. dnf needs-restarting -s identifica os serviços que devem ser reiniciados.

FAQ

O dnf-automatic instala apenas atualizações de segurança no Rocky Linux?

Apenas se definir upgrade_type = security em /etc/dnf/automatic.conf e se os seus repositórios publicarem metadados de errata. O Rocky Linux e o AlmaLinux publicam esses metadados, pelo que o filtro tem avisos contra os quais pode comparar os pacotes. O valor predefinido fornecido é upgrade_type = default, que instala todas as atualizações disponíveis quando apply_updates = yes.

Por que o dnf-automatic informa "No security updates needed, but 3 updates available"?

O DNF determina o que conta como atualização de segurança ao ler updateinfo.xml do repositório. Cada aviso lista os pacotes que o corrigem. Quando esses metadados estão ausentes ou desatualizados, o filtro de segurança não encontra correspondências, enquanto continuam pendentes atualizações normais. Isso produz exatamente essa linha. Esse comportamento é esperado no CentOS Stream, que não publica errata. No Rocky ou AlmaLinux, compare dnf updateinfo list --security com dnf check-update e confirme se os metadados estão atualizados.

O dnf-automatic reinicia o meu servidor depois de uma atualização do kernel?

Não, a menos que o configure para isso. A opção reboot tem o valor predefinido never. Defina reboot = when-needed para que uma execução reinicie o sistema apenas quando a verificação por trás de dnf needs-restarting -r detetar que um pacote essencial, como kernel ou glibc, foi substituído desde o boot. reboot = when-changed reinicia o sistema depois de qualquer atualização aplicada. Ambas as opções usam reboot_command, cujo valor predefinido é shutdown -r +5, com uma mensagem de aviso para os utilizadores com sessão iniciada.

Como altero a hora de execução do dnf-automatic?

Execute sudo systemctl edit dnf-automatic.timer e adicione uma secção [Timer] com uma linha OnCalendar= vazia, seguida do seu agendamento, por exemplo OnCalendar=*-*-* 03:30. A linha vazia é necessária porque OnCalendar acumula valores. Se a omitir, a execução fornecida às 06:00 será mantida e uma segunda execução será adicionada. Confirme com systemctl list-timers dnf-automatic.timer e leia a coluna NEXT.

Ainda preciso de verificar um servidor que instala atualizações automaticamente?

Sim. O dnf-automatic instala os pacotes e termina. Não reinicia daemons e não comunica nada que possa consultar, a menos que emit_via indique um emissor que efetivamente leia. Defina emit_via como stdio, no mínimo, ative send_error_messages para que as falhas também sejam comunicadas e execute dnf needs-restarting -s depois de uma janela de aplicação de patches para localizar serviços que ainda estejam a executar código antigo.