Ciclo di vita e upgrade di release
Modulo 4: Software e aggiornamenti · Tempo di lettura: 11 minuti
Obiettivo della lezione: Dopo questa lezione saprà verificare il ciclo di vita della Sua distribuzione, saprà che cosa significa "end of life" per il Suo server e saprà pianificare ed eseguire in sicurezza un upgrade di release.
Concetti chiave: release, LTS, supporto standard, Debian LTS, Ubuntu ESM e Ubuntu Pro, end of life (EOL), /etc/os-release, do-release-upgrade, upgrade minimo e completo, repository di terze parti, snapshot, curl | bash
Ogni release ha una data di scadenza
Gli aggiornamenti automatici (lezione 4.2) funzionano solo finché la Sua distribuzione produce ancora aggiornamenti per la Sua versione. Ogni release di Debian e Ubuntu riceve aggiornamenti di sicurezza per un periodo fisso. Poi si ferma: il Suo server non riceve più correzioni, nemmeno per vulnerabilità gravi. Questo si chiama end of life (EOL).
Per vedere quale versione ha, usi:
anna@web1:~$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
...Su Ubuntu compare per esempio VERSION="24.04.3 LTS (Noble Numbat)".
Debian
Debian supporta pienamente una release per circa tre anni. Dopodiché subentra il team Debian LTS per altri due anni, con aggiornamenti di sicurezza per i pacchetti più usati. Per le release attuali (situazione a novembre 2026, da verificare su debian.org/releases):
| Release | Pubblicata | Fine supporto ordinario | Fine LTS |
|---|---|---|---|
| Debian 13 "trixie" | 9 agosto 2025 | agosto 2028 | 30 giugno 2030 |
| Debian 12 "bookworm" | 10 giugno 2023 | 11 luglio 2026 | 30 giugno 2028 |
Debian 12 riceve quindi ancora aggiornamenti tramite LTS, ma è nella fase finale. Un nuovo server lo installi su Debian 13.
Ubuntu
Ubuntu pubblica ogni due anni, ad aprile, una release LTS (Long Term Support), con cinque anni di manutenzione di sicurezza standard. Con un abbonamento Ubuntu Pro (gratuito per uso personale su alcune macchine) si aggiunge ESM (Expanded Security Maintenance), fino a dieci anni in totale.
| Release | Supporto standard fino a | Con ESM fino a |
|---|---|---|
| Ubuntu 26.04 LTS | maggio 2031 | maggio 2036 |
| Ubuntu 24.04 LTS | maggio 2029 | maggio 2034 |
Tra una release LTS e l'altra escono versioni intermedie (come la 25.10) con solo nove mesi di supporto. Non sono pensate per un server che deve funzionare per anni. Per un server scelga sempre una LTS.
Che cosa significa EOL per Lei
Un server su una release che non riceve più aggiornamenti continua a funzionare normalmente. Ed è proprio questo l'aspetto insidioso: non si accorge di nulla, finché qualcuno sfrutta una vulnerabilità corretta ovunque tranne che da Lei. Inoltre:
- il nuovo software (una nuova versione di PHP, una nuova release di Docker) non viene più compilato per la Sua release;
- anche i repository di terze parti smettono, spesso prima;
- più aspetta, più grande è il salto. Debian non supporta il salto di una release: da 11 a 13 si deve passare per la 12.
Segni quindi la data EOL del Suo server in agenda, con un promemoria sei mesi prima.
Due strade: aggiornare o ricostruire
Ci sono due percorsi puliti verso una nuova release.
- Upgrade in-place: aggiorna il server esistente alla nuova release. È rapido e tutto resta al suo posto, ma anche vecchi residui e personalizzazioni vengono portati con sé.
- Ricostruire da zero: crea un nuovo server con la nuova release, vi reinstalla i Suoi servizi (comodo con gli appunti della lezione 10.4 o con Docker Compose, modulo 9), trasferisce i dati dal Suo backup e cambia il DNS (lezione 7.1). Più lavoro, ma il risultato è pulito ed è al tempo stesso un test del Suo backup.
Per un piccolo server con pochi servizi un upgrade in-place va benissimo. Se gira molto software personalizzato, o se il server è già stato aggiornato più volte, valuti invece di ricostruirlo.
Preparare un upgrade in-place
Prima di iniziare, si assicuri di queste cinque cose:
- Uno snapshot nel pannello del Suo provider, subito prima di iniziare, e un backup recente fuori dal server (modulo 8). Uno snapshot è la Sua via rapida per tornare indietro se l'upgrade si interrompe a metà.
- Un secondo accesso: la console del Suo provider. Lavora via SSH, e se le impostazioni di rete o il server SSH cambiano durante l'upgrade, vorrà poter proseguire dalla console. Le note di rilascio di Debian lo dicono esplicitamente: predisponga in anticipo un altro modo per accedere.
- Leggere le note di rilascio, soprattutto il capitolo "Issues to be aware of". Per Debian 13 vi si trova per esempio:
/tmpora risiede di default in memoria,/etc/sysctl.confnon viene più letto (usi/etc/sysctl.d/) e/bootdeve essere abbastanza grande. - Controllare i repository di terze parti. I pacchetti che non provengono da Debian o Ubuntu stessi possono entrare in conflitto durante l'upgrade. Verifichi quali repository ha (
ls /etc/apt/sources.list.d/) e se il produttore offre già una versione per la nuova release. - Una sessione che sopravviva a una connessione interrotta. Avvii l'upgrade in
tmuxoscreen. Se cade la Sua connessione internet, l'upgrade prosegue e può riprenderlo contmux attach.
Debian: i passaggi
Dalle note di rilascio di Debian 13, per un upgrade dalla 12 alla 13:
root@web1:~# apt update && apt full-upgrade # prima aggiornare completamente la release attuale
root@web1:~# sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/debian.sources
root@web1:~# apt update
root@web1:~# apt upgrade --without-new-pkgs # aggiornamento minimo
root@web1:~# apt full-upgrade # aggiornamento completo
root@web1:~# rebootSe usa ancora /etc/apt/sources.list, modifichi lì il nome in codice. I repository di terze parti li disattivi temporaneamente durante l'upgrade (rinominandoli in .disabled) e poi li riattivi con il nome in codice della nuova release, se il produttore lo prevede.
Durante l'upgrade presti attenzione alle domande sui file di configurazione. Se ha modificato un file di persona, come sshd_config, dpkg Le chiede se vuole mantenere la Sua versione. Mantenga la Sua versione se sa perché l'ha modificata, e poi la confronti con quella nuova (.dpkg-dist).
Dopo il riavvio:
anna@web1:~$ cat /etc/os-release | grep VERSION=
VERSION="13 (trixie)"
anna@web1:~$ systemctl --failed
anna@web1:~$ sudo apt autoremovesystemctl --failed (lezione 6.1) deve risultare vuoto. Verifichi anche che i Suoi siti web e container funzionino e che il Suo monitoraggio (lezione 8.3) sia verde.
Ubuntu: do-release-upgrade
Ubuntu ha un programma apposito:
anna@web1:~$ sudo apt update && sudo apt full-upgrade
anna@web1:~$ sudo do-release-upgradeDue cose da sapere. Primo: Ubuntu propone l'upgrade da una LTS alla successiva solo dopo la prima point release (per esempio la 26.04.1, qualche mese dopo aprile). È una scelta voluta: nei primi mesi vengono risolti i problemi più grossi. Secondo: se esegue l'upgrade via SSH, do-release-upgrade avvisa che per sicurezza avvia un server SSH aggiuntivo su una porta di riserva. Quella porta deve poter passare attraverso il Suo firewall (lezione 5.2) se ne ha bisogno; di solito non serve, perché ha la console.
La grande trappola: software esterno alla distribuzione
Gli upgrade falliscono quasi sempre per colpa di software che non proviene dalla distribuzione. Tre abitudini fanno la differenza:
- Niente
curl https://... | bash. Uno script preso da internet ed eseguito direttamente come root può modificare qualsiasi cosa sul Suo server: aggiungere repository, considerare affidabili chiavi per tutti i repository, sovrascrivere file. Non sa che cosa è successo, e al prossimo upgrade qualcosa si rompe. Scarichi uno script del genere, lo legga ed esegua piuttosto i passaggi di persona. - Un repository aggiuntivo solo dal produttore stesso, con una chiave propria (
Signed-By, lezione 4.1), e annoti nella documentazione del server perché è presente. - Nessun file
.debisolato scaricato da siti web se lo stesso software è disponibile dalla distribuzione o dal repository del produttore. Quei file non ricevono mai aggiornamenti.
Su AlmaLinux e Rocky Linux
Una versione "major" (9, 10) riceve lì circa dieci anni di aggiornamenti, e le versioni intermedie (9.6, 9.7) si aggiornano normalmente con dnf upgrade. Un salto in-place a una nuova versione major è possibile con lo strumento ELevate (AlmaLinux), ma molti amministratori, per il passaggio a una nuova versione major, preferiscono comunque ricostruire da zero.
In pratica
Nella schermata VPS di WebOké crea uno snapshot prima di un upgrade (al massimo due alla volta, sullo stesso storage del Suo VPS) e dispone della console come secondo accesso. Presso altri provider i nomi sono simili: snapshot, console VNC o web, rescue. Uno snapshot non sostituisce un backup fuori dal server; lo elimini quando tutto funziona, perché cresce con ogni modifica.
Riepilogo
- Ogni release riceve aggiornamenti di sicurezza per un periodo fisso; poi diventa end of life e il Suo server non riceve più correzioni.
- Debian: circa tre anni più due anni di LTS; Ubuntu LTS: cinque anni più ESM fino a dieci. Per un server scelga sempre una LTS e segni la data di fine supporto in agenda.
- Prepari un upgrade con uno snapshot, un backup, la console, le note di rilascio e una sessione tmux.
- Debian: repository al nuovo nome in codice,
apt upgrade --without-new-pkgs,apt full-upgrade; Ubuntu:do-release-upgrade, dopo la prima point release. - Il software esterno alla distribuzione è la principale fonte di problemi negli upgrade: niente
curl | bash, solo repository del produttore con una chiave propria.
Quiz
Esercizio
Esercizio O4.3: Il Suo piano di upgrade. Verifichi su quale release gira il Suo server e fino a quando riceve aggiornamenti di sicurezza. Poi prepari un piano di upgrade: quali repository di terze parti ha, come crea uno snapshot e un backup, come accede tramite la console, quali passaggi esegue, come verifica il risultato, e se sceglie un upgrade in-place o la ricostruzione da zero (con motivazione)?
Esercizio O4.3: Il Suo piano di upgrade
Questo esercizio lo svolge da sé; nessuno lo verifica. Spunti ciò che ha fatto e segni l'esercizio come completato.
Snapshot e backup, leggere le note di rilascio, lavorare in tmux; Debian: fonti sul nuovo nome in codice, apt upgrade --without-new-pkgs, apt full-upgrade, riavvio; Ubuntu: do-release-upgrade. Poi controllare systemctl --failed, siti, container e monitoraggio. Ricostruire da zero conviene in presenza di molte personalizzazioni ed è anche un test del Suo backup.
Le Sue spunte e note restano solo in questo browser; non le inviamo da nessuna parte. Se ha effettuato l'accesso, conserviamo in I miei corsi solo il fatto che ha svolto l'esercizio.
Per approfondire
- Snapshot e backup del suo VPS
- Collegare una ISO propria o reinstallare la sua VPS
- Release di Debian e periodi di supporto: https://www.debian.org/releases/
- Debian 13, note di rilascio capitolo 4 (upgrade) e 5 (punti di attenzione): https://www.debian.org/releases/trixie/release-notes/
- Ubuntu, ciclo di rilascio: https://ubuntu.com/about/release-cycle
- Documentazione di Ubuntu Server, Upgrade your release: https://ubuntu.com/server/docs/how-to/software/upgrade-your-release/
