Ubuntu LTS o interim: quale scegliere per un server?

Ubuntu LTS e release interim: la risposta breve

La scelta tra una release Ubuntu LTS e una release interim per un server dipende da un solo dato: per quanto tempo la release riceve aggiornamenti di sicurezza. Una LTS include cinque anni di manutenzione di sicurezza standard. Una release interim include nove mesi di aggiornamenti; al termine, gli aggiornamenti si interrompono e devi eseguire un upgrade o ricreare il server. Usa una LTS per tutti i sistemi da cui dipendono altre persone. Usa una release interim solo dove puoi ricreare il sistema senza dover chiedere l'intervento di nessuno.

LTS significa long term support. Canonical pubblica una LTS ogni due anni, ad aprile degli anni pari, e una release interim ogni sei mesi negli intervalli. La 26.04 LTS è stata rilasciata il 23 aprile 2026 e la relativa manutenzione di sicurezza standard prosegue fino al 2031. La 26.10 è prevista per il 15 ottobre 2026 ed è una release interim, quindi il relativo ciclo di supporto termina a luglio 2027.

Durata del supporto per ogni release Ubuntu

[
  {
    "label": "LTS, standard support",
    "support_months": 60,
    "upgrades_over_5_years": 1
  },
  {
    "label": "LTS with Ubuntu Pro",
    "support_months": 120,
    "upgrades_over_5_years": 0
  },
  {
    "label": "Interim release",
    "support_months": 9,
    "upgrades_over_5_years": 10
  }
]

Questi sono i valori della policy pubblicata da Canonical ad agosto 2026, non misurazioni eseguite su un server di test. Una release LTS include 60 mesi di manutenzione di sicurezza standard. In cinque anni, questo corrisponde a 1 aggiornamento di release pianificato. Una release interim include 9 mesi di supporto. Restare sul canale interim per gli stessi cinque anni richiede 10 aggiornamenti di release, perché non è possibile saltare una release e cinque anni ne comprendono dieci.

Un abbonamento Ubuntu Pro porta il supporto delle release LTS a 120 mesi, cioè dieci anni, ed estende la copertura dal componente main all'intero archivio. Ad agosto 2026, Pro è gratuito per l'uso personale su un massimo di cinque macchine, una copertura sufficiente per la maggior parte delle piccole flotte VPS. Non esiste un'offerta equivalente per le release interim. Il supporto dura nove mesi e nessun abbonamento lo estende.

Quanto costa nove mesi su un server reale

Prendiamo 26.10 come esempio pratico. Viene rilasciato il 15 ottobre 2026 e la manutenzione di sicurezza termina a luglio 2027, seguendo lo stesso ciclo di nove mesi che ha portato alla fine del supporto di 25.10 a luglio 2026. Letto come un calendario, sembra esserci una sola finestra di manutenzione ogni tre trimestri. Questa interpretazione è errata, e lo è nella direzione più costosa.

Un aggiornamento di release sostituisce il sistema operativo direttamente sul sistema esistente. do-release-upgrade riscrive le sorgenti apt, disabilita i repository di terze parti, modifica la versione di quasi tutti i pacchetti installati, interrompe la procedura per chiedere conferma sui file di configurazione modificati e riavvia il sistema al termine. Per questo richiede una finestra pianificata e non può essere eseguito come attività in background.

Se lo esegui tramite ssh, lo strumento protegge la procedura dall'interruzione della connessione. Avvia una propria sessione screen e apre un secondo sshd, comunicandotelo prima:

To make recovery in case of failure easier, an additional sshd will
be started on port '1022'. If anything goes wrong with the running ssh
you can still connect to the additional one.

Lascialo attivo. Se il firewall o il firewall di rete separato del provider blocca la porta 1022, questa modalità di fallback non è disponibile. In caso di interruzione della connessione, potresti quindi ritrovarti con un insieme di pacchetti aggiornato solo parzialmente. Eseguire personalmente la procedura all'interno di tmux o screen offre la stessa protezione su qualsiasi macchina.

Le richieste relative ai file di configurazione sono ciò che trasforma un aggiornamento di quindici minuti in un'operazione di un'ora:

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?

Mantenere il proprio file significa non applicare le modifiche introdotte dal nuovo valore predefinito. Usare il file del manutentore significa perdere le proprie configurazioni di hardening finché non vengono ripristinate. Nessuna delle due risposte è sicura senza sapere che cosa è cambiato in quella release. Per questo la lettura delle note di rilascio fa parte della finestra di manutenzione e non è un'attività facoltativa da svolgere in seguito.

Poi moltiplica il lavoro per il numero di macchine. Un VPS sul canale intermedio richiede dieci finestre di aggiornamento in cinque anni. Cinque VPS richiedono cinquanta finestre, a meno che ogni macchina sia usa e getta e venga ricreata da un'immagine. Cinque macchine sul canale LTS richiedono cinque aggiornamenti nello stesso periodo, e puoi scegliere il mese in cui eseguire ciascuno di essi.

Perché non puoi saltare una release di Ubuntu

I percorsi di aggiornamento sono prestabiliti. Una release intermedia viene aggiornata alla release successiva, qualunque essa sia. Una LTS viene aggiornata direttamente alla LTS successiva oppure alla release intermedia successiva, se lo richiedi. Nessun aggiornamento può saltare due passaggi. Per passare da 26.10 a 28.04 LTS devi attraversare 27.04 e 27.10 oppure reinstallare il sistema.

È utile conoscere il meccanismo, perché chiarisce che questa regola non è modificabile. do-release-upgrade scarica un file meta-release da changelogs.ubuntu.com, quindi scarica uno strumento di aggiornamento creato per una specifica transizione. Canonical sviluppa e collauda una transizione alla volta, quindi per un salto che omette una release non esistono né lo strumento né i test necessari. Il programma di aggiornamento non rifiuta l'operazione per prudenza. Non ha nulla da proporre.

La release proposta dipende da una riga di configurazione:

grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c

Prompt=lts propone soltanto la LTS successiva. Prompt=normal propone la release successiva, LTS o meno. Prompt=never non propone alcuna release. In questo modo impedisci a un collega benintenzionato di avviare un aggiornamento non pianificato. Su una release che non è LTS, lts si comporta esattamente come normal, perché la release successiva a 26.10 è 27.04 in entrambi i casi. Il controllo stampa Checking for a new Ubuntu release e poi una riga New release ... available. oppure No new release found.

C'è un'altra regola di pianificazione che spesso viene trascurata. L'aggiornamento da una LTS alla LTS successiva non viene proposto il giorno del rilascio della nuova LTS. Diventa disponibile con la prima point release; 26.04.1 è prevista per il 27 agosto 2026. Un sistema 24.04 con Prompt=lts che ha risposto No new release found. per tutta l'estate del 2026 non aveva problemi. Stava applicando la policy prevista. Quando il percorso diventa disponibile, l'aggiornamento da 24.04 a 26.04 LTS è quello da pianificare e provare.

Quando scegliere una release intermedia

Quattro casi in cui è realmente la scelta migliore:

• Ti serve subito, su questo sistema, una versione del kernel o dello spazio utente che l'archivio LTS non include.
• Il sistema è un host di build, un runner CI o un ambiente di test che ricrei da un'immagine. In questo caso l'upgrade crea una nuova istanza invece di richiedere una finestra di manutenzione.
• Una funzionalità hardware o dell'hypervisor è stata introdotta dopo il congelamento della LTS e non esiste alcun backport.
• Vuoi verificare cosa conterrà la prossima LTS. 28.04 viene assemblata a partire da 26.10, 27.04 e 27.10. Individuare una modifica incompatibile su una VPS di test costa meno che trovarla sul sistema importante.

La maggior parte degli utenti che sceglie una release intermedia ha bisogno di un solo pacchetto più recente, non di una distribuzione più recente. Esistono due alternative meno costose. Lo stack di abilitazione hardware porta in una LTS i kernel delle release successive: su 24.04 è sudo apt install linux-generic-hwe-24.04 e avanza a ogni point release, a partire dalla seconda. Per una singola applicazione, un'immagine container o il repository del produttore aggiornano un solo componente invece dell'intero sistema operativo.

Quando scegliere una release intermedia è una scelta errata

• Qualsiasi sistema con utenti paganti o con un turno di reperibilità. Accetteresti un aggiornamento obbligatorio due volte all'anno in cambio di versioni dei pacchetti che potresti non utilizzare mai.
• Qualsiasi macchina in cui unattended-upgrades gestisce automaticamente le patch di sicurezza. L'automazione è affidabile solo quanto il security pocket da cui recupera gli aggiornamenti.
• Un parco di sistemi che aggiorni manualmente, perché il costo reale è una finestra di manutenzione moltiplicata per il numero di macchine.
• Qualsiasi sistema che installi e poi non controlli per un anno. Una release intermedia dimenticata diventa, dopo nove mesi, un server esposto a Internet e privo di patch.

Quest'ultimo problema si verifica senza segnali evidenti, ed è proprio questo a renderlo pericoloso. Quando una release raggiunge la fine del ciclo di vita, i relativi pacchetti vengono spostati su old-releases.ubuntu.com, quindi sudo apt update inizia a restituire errori 404 quando contatta archive.ubuntu.com. Gli elenchi dei pacchetti presenti sul disco diventano obsoleti. unattended-upgrades continua a essere eseguito secondo la pianificazione e continua a scrivere righe come questa in /var/log/unattended-upgrades/unattended-upgrades.log:

No packages found that can be upgraded unattended and no pending auto-removals

La riga è identica su un server completamente aggiornato e su un server la cui release non è più supportata da quattro mesi. Se nessuno legge gli errori di apt o controlla la data di fine del ciclo di vita, il sistema non fornisce alcuna indicazione per capire quale dei due casi si sta osservando.

Il tipo di modifica che arriva prima nel canale intermedio

Nel marzo 2026 un ingegnere Canonical ha proposto su Ubuntu Discourse di rimuovere, da 26.10, il bootloader GRUB firmato distribuito per il secure boot. La proposta elimina i driver del filesystem per btrfs, hfsplus, xfs e zfs, i parser per immagini JPEG e PNG, le tabelle delle partizioni Apple, /boot su LVM, il software RAID diverso da RAID 1 e un /boot crittografato con LUKS. Il motivo dichiarato è che i parser all'interno di un bootloader sono una fonte ricorrente di vulnerabilità e che la logica per lo storage e la cifratura appartiene all'initramfs, il piccolo filesystem iniziale in RAM che il kernel monta prima del vero root. Ad agosto 2026 si tratta di una proposta ancora discussa, non di una modifica già distribuita.

Per la maggior parte delle istanze VPS non cambierebbe nulla, perché si avviano senza secure boot da un semplice /boot ext4 su una tabella delle partizioni GPT. Verificate la vostra configurazione invece di dare nulla per scontato. Se il root usa ZFS, oppure /boot si trova su btrfs o all'interno di LUKS, questo è esattamente il tipo di modifica che si incontra per primo nel canale intermedio; il consiglio espresso nella discussione agli utenti interessati è di rimanere su una versione LTS. Questo consiglio riassume l'intero argomento in una frase. Le versioni intermedie sono il luogo in cui le modifiche vengono sperimentate. Una LTS è il punto in cui arrivano dopo che due anni di versioni intermedie hanno mostrato che cosa possono compromettere.

Lo stesso schema si presenta in forma più limitata a ogni versione intermedia. Le versioni predefinite del database, del runtime del linguaggio e della configurazione di init avanzano, quindi i file di configurazione che prima funzionavano possono smettere di funzionare. Portare avanti le versioni predefinite è il compito per cui esiste una versione intermedia; per questo leggere le note di rilascio prima di ciascuno di questi dieci aggiornamenti fa parte del costo che avete accettato.

Scegliere il canale durante la configurazione del server

Scegli il canale durante l'installazione, perché cambiarlo in seguito richiede una reinstallazione o una sequenza di aggiornamenti. Su un server nuovo, quattro comandi indicano la situazione:

lsb_release -a
grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c
pro security-status

lsb_release -a deve indicare la release che intendevi installare e, su una LTS, la riga della descrizione termina con LTS. La riga Prompt deve corrispondere al canale scelto, non a quello incluso casualmente nell'immagine del provider. Su una LTS attuale, do-release-upgrade -c dovrebbe restituire No new release found.. Se invece propone una release intermedia, Prompt è impostato su normal e occorre verificare se la scelta era intenzionale. pro security-status indica quanti pacchetti installati sono coperti da ciascun flusso di aggiornamento e segnala chiaramente quando la macchina non è associata a un abbonamento.

Annota quindi la data di fine del supporto in un punto che potrai consultare nuovamente, insieme al resto delle note di configurazione del server. Questa attività rientra nelle altre operazioni da eseguire nei primi dieci minuti su un nuovo VPS, perché una data di supporto conservata soltanto nella memoria di qualcuno è destinata a scadere senza che nessuno se ne accorga. Se vuoi evitare completamente il ciclo di aggiornamenti semestrale, vale la pena dedicare un'ora alla lettura del modello di release di FreeBSD a confronto con Linux prima di impegnare un'intera infrastruttura in una delle due opzioni.

FAQ

Devo eseguire una release intermedia di Ubuntu su un server di produzione?

Nella quasi totalità dei casi, no. Una release intermedia smette di ricevere aggiornamenti di sicurezza nove mesi dopo il rilascio. Usarla in produzione significa quindi pianificare obbligatoriamente un aggiornamento circa due volte all'anno, per sempre. Le eccezioni reali sono i sistemi che vengono comunque ricreati da un'immagine, come i runner CI e gli host di build. In questi casi, un aggiornamento corrisponde alla creazione di una nuova istanza e non a una finestra di manutenzione. Se dal server dipendono utenti reali, installate la LTS e usate le finestre di manutenzione risparmiate per altre attività.

Per quanto tempo è supportata una release intermedia di Ubuntu?

Nove mesi. 26.10 viene rilasciata il 15 ottobre 2026 e la relativa manutenzione di sicurezza termina a luglio 2027, come è avvenuto per 25.10, la cui manutenzione è terminata a luglio 2026. Ogni release intermedia segue lo stesso ciclo: viene rilasciata ad aprile o ottobre e termina nove mesi dopo. Una LTS riceve cinque anni di manutenzione di sicurezza standard, estesi a dieci anni con Ubuntu Pro, che ad agosto 2026 è gratuito per l'uso personale su un massimo di cinque macchine.

Posso saltare le release di Ubuntu durante un aggiornamento?

No. do-release-upgrade procede un passaggio alla volta: una release intermedia passa alla release successiva, mentre una LTS può passare direttamente alla LTS successiva. Per passare da 26.10 a 28.04 LTS è necessario eseguire prima l'aggiornamento a 27.04 e poi a 27.10, oppure reinstallare la macchina. Canonical crea e verifica una transizione alla volta. Inoltre, il programma di aggiornamento scarica uno strumento specifico per quel passaggio. Per un salto di due release non esiste quindi alcuno strumento e l'aggiornamento non viene mai proposto.

Cosa accade quando la mia release di Ubuntu raggiunge la fine del ciclo di vita?

I relativi pacchetti vengono spostati su old-releases.ubuntu.com. Di conseguenza, sudo apt update inizia a restituire errori 404 quando accede ad archive.ubuntu.com e per quella release non vengono più pubblicati aggiornamenti di sicurezza. La macchina non segnala automaticamente la situazione. Il server continua a funzionare e a gestire il traffico, mentre ogni nuova vulnerabilità scoperta nei suoi componenti rimane esposta. Il ripristino richiede un aggiornamento della release eseguito sotto pressione, oppure una ricostruzione del sistema. È quindi necessario controllare la data, non aspettare la comparsa dei sintomi.

Il kernel della LTS è troppo vecchio per l'hardware recente?

Di norma, no, perché una LTS non mantiene il kernel originale per cinque anni. Lo stack Hardware Enablement, HWE, porta nella LTS i kernel delle release successive tramite le point release. Un'installazione server può abilitarlo con un pacchetto come linux-generic-hwe-24.04. Prima di considerare il kernel la causa del problema, controllate quale versione è in esecuzione con uname -r. Se manca una versione dello userspace e non una funzionalità del kernel, un container o un repository del fornitore rappresentano una modifica molto più contenuta rispetto allo spostamento dell'intera macchina sul ciclo delle release intermedie.