dnf-automatic: atualizacoes de seguranca 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 supervisionadas no Rocky Linux e no AlmaLinux. É um pequeno programa iniciado por um temporizador do systemd. Lê /etc/dnf/automatic.conf e aplica o que esse ficheiro permite. A instalação requer um comando. O resto deste guia explica as definições que determinam se o sistema fica protegido ou se o programa não faz nada sem informar.

Se veio do Debian ou do Ubuntu, este programa executa a mesma função que o unattended-upgrades executa 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 repositório separado. Na família RHEL, é composto por 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, mas comunica uma execução bem-sucedida.

Este guia foi escrito para o Rocky Linux 9 e o AlmaLinux 9, que utilizam 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 fim. Cada comando abaixo deve ser executado no seu próprio sistema. O resultado esperado é apresentado ao lado.

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

Ativar as atualizações automáticas faz parte da restante configuração nas primeiros dez minutos num novo VPS, logo depois de ter um utilizador que não seja root e uma firewall. Se a configuração da firewall ainda estiver pendente, firewalld é o que Rocky e AlmaLinux incluem, e alguns comandos permitem SSH, abrem a porta onde o seu site escuta e fazem com que ambas as configurações persistam depois de um reboot.

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

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

A versão do DNF é importante para uma opção. A configuração reboot foi introduzida a montante no DNF 4.15, e a Red Hat fez backport para dnf-4.14.0-6.el9 em novembro de 2023 através do advisory RHBA-2023:6645. Rocky 9 e AlmaLinux 9 recompilam esse pacote, por isso uma máquina atualizada já a tem, mas uma máquina 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 lista todas as opções compreendidas por esta build, com o valor predefinido comentado. Leia-o uma vez antes de o 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. Por predefinição, ambas estão no no EL9 (enterprise Linux 9, a base comum do Rocky 9 e do AlmaLinux 9), pelo que um dnf-automatic ativado sem alterações apenas informa sobre o que está disponível.

• Ambas no: o dnf-automatic comunica 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 é depois rápida e não precisa de rede, mas nada foi alterado esta 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 são instalados os pacotes mencionados num aviso de segurança.

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

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

network_online_timeout é o número de segundos que a execução espera por uma rede funcional antes de desistir. Isto é importante num sistema que acabou de arrancar. random_sleep é uma forma antiga de distribuir a carga por várias máquinas; atualmente, o timer trata dessa tarefa. 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 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 alteração substitui o ficheiro apenas nessa 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 que uma atualização é de segurança comparando números de versão. Ele lê metadados de errata: 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 alguns utilizadores.

Primeiro, sem metadados não há atualizações. Se o repositório não tiver nenhum updateinfo.xml, o filtro não corresponde a nada e a execução termina com esta linha no journal:

No security updates needed, but 3 updates available

O sistema 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 ler. O Rocky e o AlmaLinux publicam esses dados, por isso, nesses dois sistemas, uma lista vazia é normalmente um resultado legítimo. O CentOS Stream não os publica.

Segundo, o modo de segurança não corresponde a uma alteração mínima. O dnf-automatic adiciona o filtro de segurança e depois executa o fluxo normal de atualização. Assim, um pacote indicado 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 relataram que o updateinfo.xml BaseOS do Rocky 9 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 sistema em que a cobertura seja mais importante do que o controlo de alterações, upgrade_type = default segundo um agendamento à sua escolha é 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 às *-*-* 6:00 com RandomizedDelaySec=60m e Persistent=true. O atraso aleatório distribui os servidores por uma hora, para que nenhum servidor aceda ao 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 ignorar esse 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 é obrigatória. OnCalendar acumula valores. Sem essa reposição, 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 qualquer outro agendamento, conforme explicado em escrever unidades de serviço e timers do systemd.

Agora, o problema. 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 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 sei 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 precisa de mais nada instalado:

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 arquivo. Se você mantém ali um banner de login, não use esse emissor.

O emissor email abre uma conexão SMTP (simple mail transfer protocol) para email_host na porta email_port. Esses valores são, por padrão, localhost e 25. Um VPS recém-criado não tem nada escutando nessa porta, portanto a conexão é recusada e nenhum email é enviado. Execute ss -lnt | grep ':25' antes de depender desse recurso e configure um Postfix somente para relay se a saída estiver vazia. Quando o envio de email funcionar, o assunto será Updates applied on 'web01'., usando o nome de system_name.

Para qualquer outro destino, o emissor command entrega o relatório a um programa seu pela 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}

Por padrão, send_error_messages é no, o que significa que uma execução com falha não informa nada. Ative essa opção. Um sistema de aplicação de patches que anuncia apenas os sucessos é pior do que 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 detalhada. 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, recebe a primeira resposta. Adicione os seus próprios nomes de pacotes num ficheiro terminado em .conf, dentro de /etc/dnf/plugins/needs-restarting.d/, quando outro componente do sistema também precisar de um reboot para que a atualização tenha efeito.

Há uma ressalva importante 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 deixe sem acesso. Um kernel novo é o caso em que apenas um reboot resolve o problema, porque o kernel em execução não pode ser substituído enquanto o sistema está ativo. Se quiser separar as atualizações de uma determinada manhã nesses dois grupos, quais atualizações precisam de um reboot e quais precisam apenas de um reinício do serviço analisa a saída pacote a pacote.

Os contentores são um caso separado, porque o dnf-automatic aplica patches aos pacotes do host e nunca altera o userland incluído numa imagem. Por isso, uma máquina que execute Docker Engine no Rocky Linux ou AlmaLinux também precisa de obter novamente as imagens e recriar os contentores antes de a correção chegar ao código que está efetivamente a servir tráfego.

O servidor deve reiniciar sozinho?

[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 essencial foi substituído. É isso que a maioria dos administradores de servidores individuais pretende, combinado com uma janela do temporizador definida pelo próprio administrador. O padrão reboot_command dá aos utilizadores com sessão iniciada um aviso de cinco minutos através de shutdown. Pode aumentar esse período.

Resolva dois pontos antes de ativar esta opção. Todos os serviços dos quais depende têm de arrancar automaticamente no boot. Esta é normalmente a falha de uma 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 algum destes requisitos faltar, 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 apresentado 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 errata obsoleto do Rocky descrito anteriormente é um dos poucos pontos em que o comportamento diário realmente diverge. Se o servidor ainda não foi instalado, considere também a promessa de compatibilidade e o suporte a CPUs mais antigas que distinguem os dois.

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 instaladas todas as atualizações. O Stream também está à frente do RHEL, por isso essa configuração sofre mais alterações num servidor Stream do que num servidor Rocky ou AlmaLinux com a mesma configuração. Essa diferença não resulta de um acaso do empacotamento. É consequência da decisão da Red Hat, em 2020, de transformar o CentOS numa pré-visualização contínua do RHEL. Foi essa mesma decisão que levou à criação do Rocky Linux e do AlmaLinux.

O Rocky 10 e o AlmaLinux 10 passaram para o DNF5, que altera os nomes. A documentação do DNF5 upstream indica 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 advisories é dnf advisory list, mantendo updateinfo como alias. Confirme o que a sua versão realmente instalou antes de copiar nomes de pacotes ou de 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 cresceu desde a publicação desses guias. Consulte o ficheiro comentado no seu próprio servidor em vez de confiar num artigo antigo.

Modos de falha e as 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. Isso acontece porque nenhum item 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 ao nível de debug e usa o valor predefinido. Assim, uma chave escrita incorretamente não altera nada nem gera um aviso. Escreva apply_update = yes e apply_updates mantém-se em no. O servidor continuará a descarregar indefinidamente, mas nunca instalará 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. Os timers adicionais passam flags que têm precedência sobre o 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 como no e o único evento que valia a pena comunicar foi um erro.

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

FAQ

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

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

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

O DNF determina o que conta como atualização de segurança lendo 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. Este comportamento é esperado no CentOS Stream, que não publica errata. No Rocky Linux ou AlmaLinux, compare dnf updateinfo list --security com dnf check-update e confirme se os metadados estão atualizados.

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

Não, a menos que lhe peça 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 feita por dnf needs-restarting -r detetar que um pacote essencial, como kernel ou glibc, foi substituído desde o arranque. 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 a que o dnf-automatic é executado?

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, mantém a execução predefinida das 06:00 e adiciona uma segunda execução. Verifique 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 para aí. Não reinicia daemons e não apresenta qualquer informação que possa ver, a menos que emit_via indique um emissor que efetivamente consulte. 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 correções para encontrar serviços que ainda estejam a executar código antigo.