dnf-automatic: aggiornamenti di sicurezza su Rocky e Alma

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 di questa guida descrive le impostazioni che determinano se il server è protetto oppure se il programma non esegue alcuna operazione senza segnalarlo chiaramente.

Se provieni da Debian o Ubuntu, svolge lo stesso compito di unattended-upgrades su un VPS Ubuntu. Una differenza è più importante di tutte le altre: il significato della parola "security" per il gestore dei pacchetti. In Ubuntu è un archivio separato. Nella famiglia RHEL è costituito da metadati associati agli advisory pubblicati, che possono mancare o non essere aggiornati. Se configuri 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), ad agosto 2026. Le release 10 sono passate a DNF5 e i nomi cambiano; per questo motivo sono trattate in una sezione dedicata verso la fine. Ogni comando riportato di seguito deve essere eseguito sul tuo server; accanto trovi l'output previsto.

Installare dnf-automatic e leggere la configurazione inclusa

L'attivazione 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.

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 pulita, 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. Red Hat l'ha poi riportata in dnf-4.14.0-6.el9 a novembre 2023 tramite l'advisory RHBA-2023:6645. Rocky 9 e AlmaLinux 9 ricompilano quel pacchetto. Di conseguenza, un sistema aggiornato la include, mentre un sistema rimasto invariato 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 una volta prima di modificarlo, perché quel file riflette esattamente la configurazione supportata dalla tua versione.

I due switch che determinano il comportamento

download_updates e apply_updates nella sezione [commands] determinano il comportamento. Per impostazione predefinita, su EL9 (Enterprise Linux 9, la base condivisa di Rocky 9 e AlmaLinux 9) entrambi sono no. Di conseguenza, un’istanza di dnf-automatic attivata senza modifiche si limita a indicare gli aggiornamenti disponibili.

• Entrambi no: dnf-automatic segnala gli aggiornamenti disponibili e non modifica 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 applicata alcuna modifica.
• Entrambi yes con upgrade_type = default: vengono installati tutti gli aggiornamenti disponibili, inclusi quelli non relativi alla 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 a 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. È importante su un sistema appena riavviato. random_sleep è un metodo meno recente per distribuire il carico su più macchine; ora questo compito è svolto dal timer. Esegui systemctl cat dnf-automatic.service per visualizzare i flag esatti passati dal servizio fornito dal pacchetto.

Verifica che il file faccia ciò che prevedi, 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 durante l’esecuzione e quali azioni sono state effettuate. Puoi anche forzare un comportamento dalla riga di comando. Questa opzione sovrascrive il file soltanto per l’esecuzione corrente:

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

Che cosa significa davvero upgrade_type = security su Rocky e Alma

DNF non determina se un aggiornamento è di sicurezza confrontando i numeri di versione. Legge i metadati degli errata: un file chiamato updateinfo.xml pubblicato nel repository, in cui ogni advisory elenca i pacchetti che risolvono il problema. AlmaLinux pubblica questi advisory 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 conseguono due aspetti, entrambi 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 i pacchetti mentre dnf updateinfo list --security non stampa nulla, può significare che nessun aggiornamento in sospeso ha un advisory associato oppure che il repository non contiene dati sugli advisory. 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 aggiornato alla versione più recente disponibile nel repository e installa anche le relative dipendenze. L'operazione più conservativa, che aggiorna soltanto alla prima versione in grado di risolvere l'advisory, è dnf upgrade-minimal --security eseguito manualmente. dnf-automatic non dispone di un'impostazione per questo comportamento.

Esiste un'ulteriore limitazione relativa a Rocky. Rocky genera gli errata dai dati Red Hat tramite una propria pipeline, che ha accumulato ritardi. Nel settembre 2025, gli utenti hanno segnalato che il updateinfo.xml di Rocky 9 BaseOS non veniva aggiornato dal dicembre 2024. Di conseguenza, --security non conteneva gli advisory più recenti e il personale 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 degli aggiornamenti è più importante del controllo delle modifiche, upgrade_type = default secondo una pianificazione definita da te è l'impostazione più sicura.

Il timer systemd che lo esegue effettivamente

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 perso poco dopo l'avvio, invece di saltare l'esecuzione della giornata.

Modifica la pianificazione con un drop-in. Non modificare 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 vuota OnCalendar= è necessaria. OnCalendar accumula i valori, quindi senza quell'azzeramento mantieni la voce delle 06:00 e ne aggiungi una seconda; il job viene quindi eseguito due volte al giorno. Conferma il risultato con systemctl list-timers dnf-automatic.timer e leggi la colonna NEXT. Le stesse regole per i drop-in si applicano a qualsiasi altra pianificazione, come descritto in scrivere unità systemd di servizio e timer.

Ora vediamo il problema più insidioso. 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 della riga di comando, che sovrascrivono download_updates e apply_updates del file di configurazione. Se ne abiliti uno insieme a dnf-automatic.timer, il job viene eseguito due volte con comportamenti diversi. Questo dà l'impressione che il file di configurazione venga ignorato. Abilita un solo timer e verifica:

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

Come sapere quando è stato installato qualcosa?

emit_via nella sezione [emitters] controlla la generazione dei report. Con systemd, l'emittente 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'emittente motd scrive il report in /etc/motd e sostituisce il contenuto del file. Se il file contiene un banner di accesso, non includere questo emittente.

L'emittente email apre una connessione SMTP (simple mail transfer protocol) verso email_host sulla porta email_port, che per impostazione predefinita sono localhost e 25. Un VPS appena creato non ha nulla in ascolto su quella porta. La connessione viene quindi rifiutata e non viene inviata alcuna email. Esegui ss -lnt | grep ':25' prima di affidarti a questa funzione e configura un Postfix utilizzato solo come relay se l'output è vuoto. Quando l'invio email funziona, l'oggetto è Updates applied on 'web01'. e il nome viene ricavato da system_name.

Per qualsiasi altro caso, l'emittente 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. Questo significa che un'esecuzione non riuscita non produce alcun report. Abilita questa opzione. Un sistema di patching che segnala soltanto i successi è peggiore di nessun sistema, perché il silenzio può essere interpretato come assenza di problemi.

dnf-automatic non riavvia i servizi

L'installazione di un pacchetto sostituisce i file sul disco. Un processo già in esecuzione mantiene in memoria il codice precedente, quindi una libreria corretta non ha effetto su un daemon avviato il mese scorso. Questa differenza tra codice installato e codice effettivamente in uso spiega perché 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 sola domanda 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 server richiede un riavvio per rendere effettive le modifiche, aggiungi i nomi dei relativi pacchetti in un file che termina con .conf, nella directory /etc/dnf/plugins/needs-restarting.d/.

Una precisazione per gli script: dnf needs-restarting -r restituisce un codice diverso da zero sia quando è richiesto un riavvio sia quando il comando stesso non è riuscito. Il solo stato di uscita non consente quindi di distinguere i due casi. Leggi il testo dell'output.

Il riavvio di 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, in modo che una configurazione errata non ti impedisca di accedere al server. Un nuovo kernel è il caso in cui soltanto un riavvio del sistema risolve il problema, perché il kernel in esecuzione non può essere sostituito senza riavviare.

Il server deve riavviarsi automaticamente?

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

reboot = never è l'impostazione predefinita. when-changed riavvia il server dopo ogni aggiornamento applicato. when-needed riavvia il server solo quando il controllo eseguito da needs-restarting -r rileva la sostituzione di un pacchetto del kernel, che è la configurazione desiderata dalla maggior parte degli amministratori di server singoli, insieme a una finestra temporale scelta autonomamente. L'impostazione predefinita reboot_command avvisa gli utenti con sessione attiva cinque minuti prima tramite shutdown; questo intervallo può essere esteso.

Prima di attivare questa funzione, verifica due aspetti. Ogni servizio da cui dipendi deve avviarsi autonomamente al boot. Questo è il problema tipico di uno stack Docker Compose avviato manualmente. Devi inoltre disporre dell'accesso alla console o alla modalità di ripristino fornita dal provider, perché un kernel che non esegue il boot non può essere riparato tramite SSH. Se manca uno dei due requisiti, mantieni reboot = never e riavvia manualmente il server dopo avere consultato 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.

CentOS Stream è l'eccezione, e il limite è 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, usare upgrade_type = default e accettare di installare tutti gli aggiornamenti. Stream è inoltre più avanti rispetto a RHEL, quindi questa impostazione produce più aggiornamenti su un sistema Stream rispetto alla stessa impostazione su Rocky o AlmaLinux.

Rocky 10 e AlmaLinux 10 sono passati a DNF5, che rinomina alcuni elementi. La documentazione upstream di DNF5 indica il timer come dnf5-automatic.timer, colloca i valori predefiniti forniti dal pacchetto in /usr/share/dnf5/dnf5-plugins/automatic.conf, mentre le proprie modifiche 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. Verificare cosa è stato effettivamente installato dalla propria 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 è aumentato. Controllare quindi il file con i valori commentati sul proprio sistema invece di fare affidamento su un articolo datato.

Modalità di errore e stringhe visualizzate

Non viene mai 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 configurato.

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 contiene 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 usa quindi il valore predefinito. Una chiave scritta in modo errato non produce alcun effetto e non genera avvisi. Imposta apply_update = yes e verifica che apply_updates resti su no; in caso contrario il server scarica continuamente gli aggiornamenti ma non li installa mai. Dopo ogni modifica, esegui sudo systemctl start dnf-automatic.service e consulta 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 e 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'emettitore 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 è aggiornato, ma il processo in memoria usa ancora la versione 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 errata. Rocky Linux e AlmaLinux li pubblicano entrambi, quindi il filtro dispone degli advisory da confrontare. Il valore predefinito fornito è upgrade_type = default, che installa ogni aggiornamento disponibile dopo 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 advisory elenca i pacchetti che lo risolvono. Quando questi metadati mancano o sono obsoleti, il filtro di sicurezza non trova corrispondenze mentre gli aggiornamenti ordinari restano in sospeso, 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 senza una configurazione esplicita. L'opzione reboot ha come valore predefinito never. Imposta reboot = when-needed: un'esecuzione riavvia il server solo quando il controllo eseguito da dnf needs-restarting -r rileva che un pacchetto fondamentale, come kernel o glibc, è stato sostituito dopo l'avvio. reboot = when-changed riavvia il server dopo qualsiasi aggiornamento applicato. Entrambe le opzioni usano reboot_command, che ha come valore predefinito shutdown -r +5 e visualizza 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 comunque controllare un server che installa automaticamente gli aggiornamenti?

Sì. dnf-automatic installa i pacchetti e si ferma lì. Non riavvia i daemon e non segnala nulla che tu possa vedere, a meno che emit_via non specifichi un emitter che controlli effettivamente. Imposta almeno emit_via su stdio, abilita send_error_messages in modo da segnalare anche gli errori ed esegui dnf needs-restarting -s al termine della finestra di applicazione delle patch per individuare i servizi che eseguono ancora codice precedente.