Aggiornamenti di sicurezza automatici con dnf-automatic

Cosa fa dnf-automatic su Rocky Linux e AlmaLinux

dnf-automatic consente di installare automaticamente gli aggiornamenti di sicurezza su Rocky Linux e AlmaLinux. È un programma di piccole dimensioni, avviato da un timer systemd, che legge /etc/dnf/automatic.conf e applica le impostazioni consentite da quel file. L'installazione richiede un solo comando. Il resto della guida descrive le impostazioni che determinano se il sistema è protetto oppure se il programma non esegue alcuna operazione senza segnalarlo chiaramente.

Se si proviene da Debian o Ubuntu, svolge la stessa funzione di unattended-upgrades su un VPS Ubuntu. Una differenza è più importante delle altre: il significato di "security" per il gestore dei pacchetti. Su Ubuntu indica un archivio separato. Nella famiglia RHEL è costituito dai metadati associati agli advisory pubblicati, che possono essere assenti o non aggiornati. Se si configura dnf-automatic per usare un repository privo di dati sugli advisory, non installa nulla, ma segnala comunque il completamento corretto.

Questa guida si riferisce a Rocky Linux 9 e AlmaLinux 9, che usano DNF 4 (DNF è il gestore dei pacchetti della famiglia RHEL), aggiornati ad agosto 2026. Le release 10 sono passate a DNF5 e in quel caso i nomi cambiano, quindi sono trattate in una sezione dedicata verso la fine. Ogni comando riportato di seguito deve essere eseguito sul proprio sistema; accanto al comando è indicato l'output previsto.

Installare dnf-automatic e leggere la configurazione inclusa

L'abilitazione degli aggiornamenti automatici rientra nella configurazione iniziale descritta in primi dieci minuti su un nuovo VPS, subito dopo aver creato un utente non-root e configurato un firewall. Se la configurazione del firewall è ancora da completare, firewalld è il firewall incluso in Rocky e AlmaLinux e alcuni comandi consentono di aprire SSH, la porta su cui il sito è in ascolto e di mantenere entrambe le impostazioni dopo un riavvio.

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

systemctl is-enabled stampa disabled su un'installazione appena effettuata, perché l'installazione del pacchetto non avvia alcun servizio. Questo è il motivo più comune per cui un server che "ha dnf-automatic" non ha mai applicato un singolo aggiornamento.

La versione di DNF è importante per un'opzione. L'impostazione reboot è stata introdotta upstream in DNF 4.15 e Red Hat l'ha inclusa tramite backport in dnf-4.14.0-6.el9 nel novembre 2023 con l'advisory RHBA-2023:6645. Rocky 9 e AlmaLinux 9 ricompilano quel pacchetto, quindi un sistema aggiornato la include, mentre un sistema non aggiornato dal 2023 non la include.

Il file di configurazione è /etc/dnf/automatic.conf. La copia inclusa nel pacchetto elenca ogni opzione supportata da questa build, con il relativo valore predefinito commentato. Leggilo prima di modificarlo, perché quel file documenta esattamente ciò che supporta la tua versione.

I due interruttori che determinano il comportamento

download_updates e apply_updates nella sezione [commands] determinano il comportamento. Per impostazione predefinita, in EL9 (enterprise Linux 9, la base comune di Rocky 9 e AlmaLinux 9) sono entrambi no. Di conseguenza, un’istanza di dnf-automatic appena abilitata segnala soltanto gli aggiornamenti disponibili.

• Entrambi no: dnf-automatic segnala gli aggiornamenti disponibili senza modificare il sistema.
• download_updates = yes con apply_updates = no: i pacchetti vengono scaricati nella cache di DNF. L’installazione successiva è rapida e non richiede la rete, ma durante questa esecuzione non viene modificato nulla.
• Entrambi yes con upgrade_type = default: vengono installati tutti gli aggiornamenti disponibili, inclusi quelli non di sicurezza.
• Entrambi yes con upgrade_type = security: vengono installati soltanto i pacchetti indicati in un avviso di sicurezza.

Un punto di partenza ragionevole per un VPS esposto su Internet:

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

network_online_timeout indica per quanti secondi l’esecuzione attende una rete operativa prima di interrompersi. Questo è importante su un server appena avviato. random_sleep è un metodo precedente per distribuire il carico tra più macchine; ora questo compito è svolto dal timer. Eseguire systemctl cat dnf-automatic.service per visualizzare i flag esatti passati dal servizio fornito dal pacchetto.

Verificare che il file produca il comportamento previsto senza attendere le 06:00:

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

Il journal mostra quali elementi sono stati valutati dall’esecuzione e quali azioni sono state eseguite. È inoltre possibile forzare un comportamento dalla riga di comando. L’opzione sovrascrive il file soltanto per quella esecuzione:

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

Cosa significa davvero upgrade_type = security su Rocky e Alma

DNF non determina che un aggiornamento sia di sicurezza confrontando i numeri di versione. Legge i metadati degli errata: un file chiamato updateinfo.xml pubblicato all'interno del repository, in cui ogni advisory elenca i pacchetti che lo risolvono. AlmaLinux pubblica questi dati come advisory ALSA, mentre Rocky li pubblica come RLSA. upgrade_type = security crea un filtro a partire da questi metadati e aggiorna soltanto i pacchetti corrispondenti.

Ne derivano due conseguenze, entrambe spesso sorprendenti.

Primo: senza metadati non ci sono aggiornamenti. Se il repository non contiene alcun updateinfo.xml, il filtro non trova corrispondenze e l'esecuzione termina con questa riga nel journal:

No security updates needed, but 3 updates available

Il server non è stato aggiornato e non è stato segnalato alcun errore. Verificalo direttamente:

dnf updateinfo list --security
dnf check-update

Se dnf check-update elenca alcuni pacchetti mentre dnf updateinfo list --security non restituisce nulla, significa che nessun aggiornamento in sospeso è associato a un advisory oppure che il repository non contiene dati sugli advisory da leggere. Rocky e AlmaLinux li pubblicano entrambi, quindi su queste due distribuzioni un elenco vuoto è generalmente corretto. CentOS Stream non li pubblica affatto.

Secondo: la modalità di sicurezza non applica una modifica minima. dnf-automatic aggiunge il filtro di sicurezza e poi esegue il normale percorso di aggiornamento. Di conseguenza, un pacchetto incluso in un advisory viene portato alla versione più recente disponibile nel repository e installa anche le relative dipendenze. Il passaggio più contenuto, che porta il pacchetto soltanto alla prima versione che risolve l'advisory, si esegue con dnf upgrade-minimal --security manualmente. dnf-automatic non dispone di un'impostazione per questo comportamento.

Per Rocky si applica un'ulteriore avvertenza. Rocky genera gli errata a partire dai dati Red Hat tramite una propria pipeline, che ha accumulato ritardi. A settembre 2025 alcuni utenti hanno segnalato che il updateinfo.xml BaseOS di Rocky 9 non veniva aggiornato da dicembre 2024. Di conseguenza, --security non conteneva gli advisory più recenti e lo staff di Rocky ha confermato che si trattava di un problema noto. Se fai affidamento su upgrade_type = security, confronta periodicamente l'elenco degli advisory con gli annunci RLSA recenti. Su un server in cui la copertura è più importante del controllo delle modifiche, upgrade_type = default secondo una pianificazione scelta da te è l'impostazione più sicura.

Il timer systemd che lo esegue realmente

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

list-timers dovrebbe visualizzare una riga con un orario NEXT a circa un giorno di distanza. Una tabella vuota indica che il timer non è abilitato, quindi il job non verrà mai eseguito.

Il timer fornito dal pacchetto viene eseguito alle *-*-* 6:00 con RandomizedDelaySec=60m e Persistent=true. Il ritardo casuale distribuisce i server nell'arco di un'ora, così non contattano tutti il mirror nello stesso secondo. Persistent=true indica che una macchina spenta alle 06:00 esegue il job saltato poco dopo l'avvio, invece di ignorarlo per quel giorno.

Modificate la pianificazione con un drop-in. Non modificate l'unità fornita dal pacchetto, perché un aggiornamento del pacchetto sostituisce i file sotto /usr/lib/systemd/system.

sudo systemctl edit dnf-automatic.timer

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

La riga OnCalendar= vuota è obbligatoria. OnCalendar accumula i valori, quindi senza questo reset mantenete la voce delle 06:00 e ne aggiungete una seconda; il job viene quindi eseguito due volte al giorno. Confermate il risultato con systemctl list-timers dnf-automatic.timer e leggete la colonna NEXT. Le stesse regole per i drop-in si applicano a qualsiasi altra pianificazione, come descritto in scrivere unità service e timer systemd.

Ora la situazione insidiosa. Il pacchetto fornisce altri tre timer: dnf-automatic-notifyonly.timer, dnf-automatic-download.timer e dnf-automatic-install.timer. Ognuno avvia lo stesso programma con flag da riga di comando, e questi flag hanno precedenza su download_updates e apply_updates del file di configurazione. Abilitatene uno insieme a dnf-automatic.timer: il job viene eseguito due volte con comportamenti diversi, dando l'impressione che il file di configurazione venga ignorato. Abilitate un timer e verificate:

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

Come sapere quando è stato installato qualcosa?

emit_via nella sezione [emitters] controlla la generazione dei report. In systemd, l'emettitore stdio scrive nel journal. È l'opzione più affidabile perché non richiede l'installazione di altri componenti:

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

L'emettitore motd scrive il report in /etc/motd e sostituisce il contenuto del file. Se il file contiene un banner di accesso, non includere questo emettitore.

L'emettitore email apre una connessione SMTP (simple mail transfer protocol) verso email_host sulla porta email_port, che per impostazione predefinita sono localhost e 25. Su un VPS appena creato non c'è nulla in ascolto su quella porta, quindi la connessione viene rifiutata e non viene inviata alcuna email. Esegui ss -lnt | grep ':25' prima di farvi affidamento e configura un Postfix per il solo inoltro se l'output è vuoto. Quando l'invio delle email funziona, l'oggetto è Updates applied on 'web01'. e il nome viene ricavato da system_name.

Per qualsiasi altra destinazione, l'emettitore command passa il report a un tuo programma tramite lo standard input:

[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}

Per impostazione predefinita, send_error_messages è impostato su no. Di conseguenza, un'esecuzione non riuscita non produce alcun report. Attivalo. Un sistema di applicazione delle patch che comunica soltanto i successi è peggiore di nessun sistema, perché il silenzio viene interpretato come uno stato corretto.

dnf-automatic non riavvia i servizi

L’installazione di un pacchetto sostituisce i file su disco. Un processo già in esecuzione mantiene il vecchio codice in memoria, quindi una libreria aggiornata non ha effetto su un daemon avviato il mese scorso. Questa differenza tra aggiornamento installato e aggiornamento effettivo è il motivo per cui l’applicazione automatica delle patch richiede una policy di riavvio, non soltanto una policy di installazione.

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

-s elenca i servizi systemd i cui file sono cambiati dopo l’avvio. -r risponde a una domanda specifica e stampa uno di due blocchi:

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 non esegue un’analisi approfondita. Controlla un elenco fisso di pacchetti: kernel, kernel-core, kernel-rt, glibc, linux-firmware, systemd, dbus, dbus-broker, dbus-daemon e microcode_ctl. Se uno di questi è stato installato dopo l’ultimo boot, viene restituita la prima risposta. Quando anche un altro componente del sistema richiede un riavvio per applicare le modifiche, aggiungi i relativi nomi di pacchetto in un file che termina con .conf, nella directory /etc/dnf/plugins/needs-restarting.d/.

Per gli script è importante considerare un’eccezione: dnf needs-restarting -r restituisce un codice diverso da zero sia quando è richiesto un riavvio sia quando il comando stesso non è riuscito. Il solo codice di uscita non permette quindi di distinguere i due casi. Leggi il testo dell’output.

Riavviare un servizio è l’intervento più limitato e, nella maggior parte dei casi, quello corretto. Riavvia il daemon SSH da una seconda sessione SSH già aperta, così una configurazione errata non ti impedisce di accedere al sistema. Il kernel è il caso in cui soltanto un riavvio del sistema è sufficiente, perché il kernel in esecuzione non può essere sostituito direttamente. Se vuoi suddividere gli aggiornamenti di una determinata mattina in queste due categorie, quali aggiornamenti richiedono un riavvio e quali soltanto il riavvio di un servizio analizza l’output pacchetto per pacchetto.

I container costituiscono un caso distinto, perché dnf-automatic aggiorna i pacchetti dell’host e non modifica mai lo userland incluso in un’immagine. Un sistema che esegue Docker Engine su Rocky Linux o AlmaLinux richiede quindi anche il nuovo pull delle immagini e la ricreazione dei container, prima che la correzione raggiunga il codice che sta effettivamente gestendo il traffico.

Il server deve riavviarsi automaticamente?

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

reboot = never è il valore predefinito. when-changed riavvia il server dopo ogni aggiornamento applicato. when-needed riavvia il server solo quando il controllo eseguito da needs-restarting -r rileva che è stato sostituito un pacchetto di base. È l’impostazione preferita dalla maggior parte degli amministratori di un singolo server, insieme a una finestra temporale scelta autonomamente. Il valore predefinito reboot_command avvisa gli utenti con sessione attiva cinque minuti prima del riavvio tramite shutdown. L’intervallo può essere esteso.

Prima di attivare questa funzione, verifica due aspetti. Ogni servizio da cui dipendi deve avviarsi automaticamente all’avvio del sistema. Questo è il problema tipico di uno stack Docker Compose avviato manualmente. Devi inoltre avere accesso alla console o alla modalità di ripristino del provider, perché un kernel che non si avvia non può essere riparato tramite SSH. Se manca uno dei due requisiti, mantieni reboot = never e riavvia manualmente il server dopo aver esaminato il journal.

Rocky, AlmaLinux e CentOS Stream: differenze

Su Rocky 9 e AlmaLinux 9 tutto quanto descritto sopra è identico, inclusi il percorso di configurazione e i nomi delle unità. Entrambi pubblicano errata, quindi upgrade_type = security dispone di dati da filtrare. L'errata obsoleto di Rocky descritto in precedenza è uno dei pochi casi in cui il comportamento quotidiano differisce realmente. Se il server non è ancora stato installato, valuta questo aspetto insieme alla garanzia di compatibilità e al supporto per le CPU meno recenti che distinguono i due sistemi.

CentOS Stream è l'eccezione, e la differenza è sostanziale. I repository Stream non contengono updateinfo.xml, quindi il filtro di sicurezza non può mai trovare corrispondenze e ogni esecuzione restituisce No security updates needed. Su Stream, usa upgrade_type = default e accetta di installare ogni aggiornamento. Stream è inoltre più avanzato rispetto a RHEL, quindi questa impostazione produce più aggiornamenti su un server Stream rispetto alla stessa impostazione su Rocky o AlmaLinux. Questa differenza non dipende casualmente dalla pacchettizzazione, ma dalla decisione presa da Red Hat nel 2020 di trasformare CentOS in un'anteprima rolling di RHEL, la stessa decisione che ha portato alla nascita di Rocky Linux e AlmaLinux.

Rocky 10 e AlmaLinux 10 sono passati a DNF5, che rinomina diversi elementi. La documentazione upstream di DNF5 indica il timer come dnf5-automatic.timer, colloca i valori predefiniti distribuiti in /usr/share/dnf5/dnf5-plugins/automatic.conf, mentre le personalizzazioni restano in /etc/dnf/automatic.conf, imposta download_updates su yes invece che su no e aggiunge distro-sync come upgrade_type. La query per gli advisory è dnf advisory list, mentre updateinfo resta disponibile come alias. Verifica quali elementi sono stati effettivamente installati dalla tua release prima di copiare nomi di pacchetti o unità da una guida scritta per la versione 9:

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

Molte guide pubblicate su questo argomento trattano ancora soltanto Rocky 8. Da allora l'insieme delle opzioni è cresciuto, quindi controlla il file con i commenti sul tuo server invece di fare affidamento su un articolo obsoleto.

Modalità di errore e stringhe visualizzate

Non viene eseguito nulla. systemctl list-timers dnf-automatic.timer visualizza una tabella vuota e systemctl is-enabled dnf-automatic.timer visualizza disabled. Il pacchetto è stato installato, ma il timer non è mai stato creato.

Il job viene eseguito, ma non installa nulla. Il journal contiene No security updates needed, but 3 updates available. Il filtro di sicurezza non ha trovato corrispondenze: nessun aggiornamento in sospeso include un advisory oppure il repository non pubblica dati sugli advisory.

Un'impostazione sembra ignorata. A livello di debug, DNF registra un'opzione sconosciuta in automatic.conf e poi usa il valore predefinito. Una chiave scritta in modo errato non produce quindi alcun effetto e non genera avvisi. Impostare apply_update = yes lascia apply_updates al valore no: il server continua a scaricare aggiornamenti senza mai installarli. Dopo ogni modifica, eseguire sudo systemctl start dnf-automatic.service e leggere il journal invece di considerare attendibile il file.

Il job viene eseguito due volte al giorno. Sono abilitati due timer. systemctl list-unit-files 'dnf-automatic*' mostra quali sono attivi; quelli aggiuntivi passano flag che hanno la precedenza sul file di configurazione.

Non arriva alcuna email. Nessun processo è in ascolto sulla porta 25 per l'emitter email, oppure send_error_messages è ancora impostato su no e l'unico evento da segnalare era un errore.

Un servizio aggiornato continua a riportare la versione precedente. Il file sul disco è nuovo, ma il processo in memoria è ancora quello precedente. dnf needs-restarting -s indica i servizi da riavviare.

FAQ

dnf-automatic installa solo gli aggiornamenti di sicurezza su Rocky Linux?

Solo se imposti upgrade_type = security in /etc/dnf/automatic.conf e solo se i repository pubblicano metadati sugli errata. Rocky Linux e AlmaLinux li pubblicano entrambi, quindi il filtro ha avvisi da confrontare. Il valore predefinito fornito è upgrade_type = default, che installa ogni aggiornamento disponibile quando apply_updates = yes.

Perché dnf-automatic segnala "No security updates needed, but 3 updates available"?

DNF determina quali aggiornamenti sono di sicurezza leggendo updateinfo.xml dal repository, dove ogni avviso elenca i pacchetti che lo risolvono. Quando questi metadati mancano o sono obsoleti, il filtro di sicurezza non trova corrispondenze mentre gli aggiornamenti ordinari sono ancora in attesa, producendo esattamente quella riga. È previsto su CentOS Stream, che non pubblica alcun errata. Su Rocky o AlmaLinux, confronta dnf updateinfo list --security con dnf check-update e verifica che i metadati siano aggiornati.

dnf-automatic riavvierà il server dopo un aggiornamento del kernel?

Non se non lo richiedi. L'opzione reboot ha come valore predefinito never. Imposta reboot = when-needed: un'esecuzione riavvia il sistema solo quando il controllo alla base di dnf needs-restarting -r rileva che un pacchetto fondamentale, come kernel o glibc, è stato sostituito dall'avvio. reboot = when-changed riavvia il sistema dopo qualsiasi aggiornamento applicato. Entrambe le opzioni usano reboot_command, il cui valore predefinito è shutdown -r +5, con un messaggio di avviso agli utenti connessi.

Come posso modificare l'orario di esecuzione di dnf-automatic?

Esegui sudo systemctl edit dnf-automatic.timer e aggiungi una sezione [Timer] con una riga OnCalendar= vuota seguita dalla pianificazione, ad esempio OnCalendar=*-*-* 03:30. La riga vuota è necessaria perché OnCalendar accumula i valori: se la ometti, mantieni l'esecuzione fornita alle 06:00 e ne aggiungi una seconda. Verifica con systemctl list-timers dnf-automatic.timer e leggi la colonna NEXT.

Devo controllare comunque un server che installa automaticamente le patch?

Sì. dnf-automatic installa i pacchetti e si ferma. Non riavvia i demoni e non segnala nulla che tu possa vedere, a meno che emit_via non indichi un emitter che consulti effettivamente. Imposta almeno emit_via su stdio, attiva send_error_messages in modo da segnalare anche gli errori ed esegui dnf needs-restarting -s dopo una finestra di applicazione delle patch per individuare i servizi che eseguono ancora il codice precedente.