Configurare gli aggiornamenti automatici in Ubuntu 20.04

Perché automatizzare gli update su Ubuntu 20.04

Su Ubuntu 20.04 gli aggiornamenti automatici non servono a “tenere tutto sempre nuovo”, ma a ridurre il tempo di esposizione delle vulnerabilità e a togliere lavoro ripetitivo all’operatore. Il punto non è abilitare una funzione e dimenticarsene: il punto è decidere quali aggiornamenti installare, quando, e con quale livello di controllo sui riavvii e sulla telemetria operativa.

In pratica, il meccanismo più usato su Ubuntu è unattended-upgrades, affiancato da apt-daily e apt-daily-upgrade gestiti da systemd. La scelta corretta in ambito server è quasi sempre: sicurezza automatica, aggiornamenti completi solo se hai finestra di manutenzione o policy specifica. Se invece stai lavorando su un nodo desktop o su una VM non critica, puoi essere più aggressivo, ma conviene comunque sapere cosa succede sotto il cofano.

Questo articolo parte da una base operativa concreta: installazione, configurazione, verifica, esclusione di pacchetti, gestione dei reboot e controlli finali. Dove il comportamento dipende dall’ambiente, lo dico esplicitamente e ti indico come chiudere il dubbio con un comando o un file da guardare.

Cosa fa davvero unattended-upgrades

unattended-upgrades legge le sorgenti APT autorizzate e applica automaticamente gli aggiornamenti che rientrano nelle regole definite in /etc/apt/apt.conf.d/50unattended-upgrades. Di default, su Ubuntu, l’obiettivo è installare patch di sicurezza provenienti dai pocket autorizzati, lasciando fuori il resto del ciclo dei pacchetti salvo configurazione esplicita.

La parte importante è distinguere tre livelli:

1. Download degli indici: il sistema aggiorna i metadata APT.
2. Installazione automatica: il sistema applica i pacchetti che corrispondono alle regole.
3. Reboot opzionale: il sistema può riavviarsi solo se abilitato e se necessario.

Se vuoi un controllo minimo, automatizza solo il punto 2. Il reboot automatico è una scelta architetturale, non un default da accettare alla cieca, soprattutto su server con servizi stateful, cluster o nodi che richiedono drain prima del riavvio.

Installazione dei componenti necessari

Su Ubuntu 20.04 il pacchetto chiave è unattended-upgrades. In molti casi è già presente, ma conviene verificarlo e non assumere nulla.

sudo apt update
sudo apt install unattended-upgrades apt-listchanges

apt-listchanges non è obbligatorio, ma è utile se vuoi ricevere changelog e note prima o durante l’upgrade manuale. Per gli aggiornamenti automatici puri non è indispensabile, però in ambienti amministrati aiuta a capire cosa è stato toccato senza scavare ogni volta nei log.

Verifica che il pacchetto sia installato:

dpkg -l unattended-upgrades apt-listchanges

Atteso: stato ii per i pacchetti installati. Se vedi un o righe mancanti, il componente non è presente e la configurazione automatica non partirà come previsto.

Abilitazione del servizio automatico

Ubuntu usa due file di configurazione principali per decidere se l’automazione è attiva: /etc/apt/apt.conf.d/20auto-upgrades e /etc/apt/apt.conf.d/50unattended-upgrades. Il primo abilita il ciclo automatico, il secondo definisce cosa può essere installato.

Il modo più semplice e pulito per attivare l’automatismo è creare o modificare /etc/apt/apt.conf.d/20auto-upgrades con questi valori:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Il significato è lineare: aggiornamento delle liste pacchetti ogni giorno e avvio del processo unattended ogni giorno. Se vuoi disattivarlo temporaneamente, imposta entrambi a 0. Questo è il rollback più semplice e reversibile: modifica del file, nessun effetto collaterale sui pacchetti già installati.

Per verificare che la configurazione sia stata letta correttamente, puoi usare:

cat /etc/apt/apt.conf.d/20auto-upgrades

Se il file contiene valori diversi, l’automazione potrebbe essere attiva solo in parte o non esserlo affatto. Non dare per scontato che un pacchetto installato equivalga a un servizio realmente operativo.

Regolare il perimetro degli aggiornamenti

Il file /etc/apt/apt.conf.d/50unattended-upgrades è quello che decide da quali origini scaricare gli update. Qui sta la parte più delicata: se allarghi troppo il perimetro, rischi di includere pacchetti che preferivi gestire manualmente; se lo restringi troppo, perdi il vantaggio della patching automation.

In un server Ubuntu standard, le righe più importanti sono quelle che autorizzano il pocket di sicurezza. Un esempio tipico è questo:

Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}-security";
};

Su focal, il valore atteso del codename è focal. Se vuoi controllare il codename reale della macchina, usa:

lsb_release -cs

Se il risultato non coincide con ciò che vedi nel file di configurazione, hai trovato una causa probabile di mancata applicazione delle patch. In quel caso la falsificazione è semplice: correggi il codename o lascia la variabile di sistema, poi riesegui il test di simulazione.

Escludere pacchetti che non devono muoversi

Ci sono casi in cui l’automazione va bene, ma non per tutto. Pensa a stack con agenti di monitoring, driver particolari, componenti di storage, versioni bloccate di runtime o software di terze parti che rompe facilmente compatibilità. In questi casi si usano le blacklist di unattended-upgrades.

Nel file /etc/apt/apt.conf.d/50unattended-upgrades puoi definire una sezione come questa:

Unattended-Upgrade::Package-Blacklist {
        "linux-image-generic";
        "postgresql*";
        "docker-ce";
};

Qui la precisione conta. Escludere un meta-package del kernel può essere una scelta sensata in ambienti dove il reboot automatico non è accettabile, ma non va fatto per abitudine. Escludere un database server può essere corretto se hai una policy di upgrade coordinato, però devi compensare con un processo manuale e con verifica versione. Se non hai un motivo operativo, stai solo rimandando il problema.

Per vedere quali aggiornamenti verrebbero applicati senza eseguirli davvero, il test più utile è la simulazione:

sudo unattended-upgrade --dry-run --debug

Questo comando è il tuo filtro di sicurezza. Se nella lista compaiono pacchetti che non vuoi aggiornare, correggi prima il perimetro e solo dopo riattiva il ciclo automatico.

Gestire i riavvii senza farsi sorprendere

Il reboot automatico è la parte che crea più danni quando viene trattata come dettaglio. Su Ubuntu 20.04 puoi abilitarlo con una variabile nella stessa configurazione di unattended-upgrades:

Unattended-Upgrade::Automatic-Reboot "false";

Se vuoi abilitarlo, imposta "true" e valuta anche l’orario. In ambienti server, spesso conviene lasciare il reboot disattivato e integrare la logica in una finestra manutentiva gestita da orchestrazione o da procedura operativa. L’automazione del patching non implica l’automazione del restart, soprattutto se il servizio ha stato locale, code in memoria o dipendenze esterne fragili.

Puoi anche definire un orario di reboot, sempre nel file di configurazione:

Unattended-Upgrade::Automatic-Reboot-Time "02:30";

La verifica non è teorica: controlla i log e il timer. I service e i timer systemd da ispezionare sono:

systemctl status apt-daily.timer apt-daily-upgrade.timer
systemctl list-timers | grep apt

Atteso: timer attivi e prossima esecuzione programmata. Se i timer sono disabilitati, l’automazione non parte anche se i file di configurazione sono corretti.

Log da controllare quando qualcosa non torna

Quando gli update automatici non si comportano come previsto, i log sono la prima fonte affidabile. Su Ubuntu 20.04 conviene partire da questi file:

• /var/log/unattended-upgrades/unattended-upgrades.log
• /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
• /var/log/apt/history.log
• /var/log/apt/term.log

Il primo ti dice cosa ha deciso il motore di unattended-upgrades; il secondo mostra l’installazione effettiva tramite dpkg; gli ultimi due ti danno contesto APT generale. Se i file non esistono, il problema può essere che il job non è mai partito o che la configurazione di logging è stata alterata.

sudo tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.log
sudo tail -n 50 /var/log/apt/history.log

Se trovi messaggi tipo lock contention, repository non raggiungibili o pacchetti trattenuti, hai già un indizio concreto. In particolare, un lock APT occupato da un’altra sessione manuale può bloccare l’esecuzione automatica senza che il sistema sia “rotto”: in quel caso la soluzione non è forzare, ma capire quale processo sta usando APT e quando rilascerà il lock.

Simulare prima di affidarsi al cron implicito

Il test più utile, prima di mettere in produzione la configurazione, è la simulazione con debug. Non cambia nulla sul sistema, ma ti mostra il comportamento atteso con le regole attuali.

sudo unattended-upgrade --dry-run --debug

Cosa osservare:

1. Se il comando trova pacchetti candidati.
2. Se i pacchetti provengono dalle origini attese.
3. Se compaiono esclusioni o pacchetti trattenuti.
4. Se il sistema segnala reboot pending.

Se il dry-run non mostra niente, non significa necessariamente che la configurazione sia sbagliata. Può semplicemente voler dire che non ci sono aggiornamenti disponibili nel pocket autorizzato. Il modo corretto di chiudere il dubbio è verificare gli indici APT e i candidati con:

apt list --upgradable

Se anche qui non appare nulla, la macchina è semplicemente allineata. Se invece ci sono update e unattended-upgrades non li prende, il problema è quasi sempre nel perimetro delle origini o nelle esclusioni.

Un file di configurazione sensato per un server generico

Per un server Ubuntu 20.04 standard, una base ragionevole è questa: aggiornamento automatico delle liste, installazione dei soli update di sicurezza, reboot disattivato, nessuna blacklist iniziale salvo necessità reale.

// /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

// /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}-security";
};
Unattended-Upgrade::Automatic-Reboot "false";

Questo non è un modello universale, ma è un buon punto di partenza. Su nodi applicativi con deploy frequenti potresti preferire una finestra notturna e reboot coordinato; su workstation di supporto potresti voler accettare un reboot automatico se non c’è impatto sugli utenti; su nodi database, quasi sempre, il reboot automatico resta spento.

Controlli finali e rollback rapido

Prima di considerare chiusa la configurazione, fai questi controlli minimi:

1. Verifica i timer: systemctl list-timers | grep apt.
2. Verifica il file di abilitazione: cat /etc/apt/apt.conf.d/20auto-upgrades.
3. Verifica il perimetro: grep -n "Allowed-Origins\|Package-Blacklist\|Automatic-Reboot" /etc/apt/apt.conf.d/50unattended-upgrades.
4. Verifica i log: tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.log.

Se qualcosa non torna, il rollback più semplice è riportare APT::Periodic::Unattended-Upgrade a 0 e, se serve, disabilitare i timer. Questo riduce subito il blast radius: nessuna disinstallazione, nessun impatto sui pacchetti già presenti, solo stop dell’automazione.

sudo systemctl disable --now apt-daily.timer apt-daily-upgrade.timer

Assunzione operativa: la macchina è un Ubuntu 20.04 con APT standard, repository ufficiali e accesso a systemd; se usi mirror custom, proxy o repository terzi, valida sempre il perimetro con un dry-run prima di lasciare l’automazione attiva.