Ubuntu LTS o release intermedia: cosa scegliere sul server

Ubuntu LTS e release intermedie: la risposta breve

La scelta tra una Ubuntu LTS e una release intermedia su un server dipende da un solo dato: per quanto tempo la release continua a ricevere aggiornamenti di sicurezza. Una LTS offre cinque anni di manutenzione di sicurezza standard. Una release intermedia offre nove mesi, dopodiché gli aggiornamenti terminano e devi eseguire un upgrade o ricreare il sistema. Usa una LTS per tutto ciò da cui dipendono altre persone. Usa una release intermedia solo quando puoi ricreare il sistema senza dover chiedere l'autorizzazione a nessuno.

LTS significa supporto a lungo termine. Canonical pubblica una LTS ogni due anni, ad aprile degli anni pari, e una release intermedia ogni sei mesi tra una LTS e l'altra. La versione 26.04 LTS è stata rilasciata il 23 aprile 2026 e la relativa manutenzione di sicurezza standard prosegue fino al 2031. La versione 26.10 è prevista per il 15 ottobre 2026 ed è una release intermedia, quindi il relativo supporto termina a luglio 2027.

Durata del supporto per ogni release di 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 effettuate su un server di test. Una release LTS riceve 60 mesi di manutenzione di sicurezza standard, pari a 1 aggiornamento pianificato della release nell’arco di cinque anni. Una release interim riceve 9 mesi di supporto. Mantenere il canale interim per gli stessi cinque anni richiede 10 aggiornamenti della release, perché non è possibile saltare una release e in cinque anni se ne susseguono 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 condizione sufficiente per la maggior parte dei piccoli parchi di VPS. Non esiste un’estensione equivalente per le release interim. Il supporto dura nove mesi e non è possibile prolungarlo con un abbonamento.

Quanto costa davvero su un server in nove mesi

Prendiamo 26.10 come esempio concreto. Viene rilasciato il 15 ottobre 2026 e il suo supporto 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. Se lo si legge come un calendario, sembra esserci una sola finestra di manutenzione ogni tre trimestri. Questa lettura è errata, e lo è nel modo più costoso.

Un upgrade della 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 il processo per chiederti come gestire i file di configurazione che hai modificato e riavvia il sistema al termine. Per questo deve essere eseguito in una finestra pianificata, non come attività in background.

Se lo esegui tramite ssh e la connessione cade, lo strumento ti protegge da questa eventualità. Avvia una propria sessione screen e apre un secondo sshd, informandoti 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, questo canale di fallback non sarà disponibile e una connessione interrotta lascerà il sistema con un insieme di pacchetti aggiornato solo parzialmente. Eseguire personalmente l'upgrade all'interno di tmux o screen offre la stessa protezione su qualsiasi server.

Le richieste relative ai file di configurazione sono ciò che trasforma un upgrade 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 tuo file significa perdere le modifiche introdotte nel nuovo valore predefinito. Usare il file del maintainer significa perdere le tue impostazioni di hardening finché non le reinserisci. Nessuna delle due risposte è sicura senza sapere cosa è cambiato in quella release. Per questo la lettura delle note di rilascio fa parte della finestra di manutenzione e non è un'attività facoltativa.

Poi devi moltiplicare il lavoro per il numero di server. Un VPS sul ciclo interim richiede dieci finestre di upgrade in cinque anni. Cinque VPS richiedono cinquanta finestre, a meno che ogni server non sia usa e getta e venga ricreato da un'immagine. Cinque server sul ciclo LTS richiedono cinque upgrade 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 fissi. 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 la macchina.

È utile conoscere il meccanismo, perché chiarisce che la regola non è modificabile. do-release-upgrade scarica un file meta-release da changelogs.ubuntu.com, quindi scarica uno strumento di aggiornamento realizzato per una specifica transizione. Canonical sviluppa e testa una transizione alla volta, quindi un salto che ignora una release non dispone né dello strumento né dei test necessari. Il programma di aggiornamento non rifiuta l'operazione per prudenza. Non c'è nulla da offrire.

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 nulla: in questo modo impedisci a un collega ben intenzionato di avviare un aggiornamento che non avevi pianificato. In una release che non è una LTS, lts si comporta esattamente come normal, perché la release successiva a 26.10 è 27.04 in entrambe le configurazioni. Il controllo stampa Checking for a new Ubuntu release e quindi una riga New release ... available. oppure No new release found.

Esiste un'altra regola di pianificazione che spesso crea problemi. L'aggiornamento da una LTS alla LTS successiva non viene proposto il giorno in cui viene rilasciata la nuova LTS. Viene attivato con la prima point release, prevista per il 27 agosto 2026 nella versione 26.04.1. Una point release non è una nuova versione di Ubuntu, ma la stessa release con quattro mesi di correzioni accumulate integrate nei nuovi supporti di installazione, e l'attesa serve a consentire al percorso di aggiornamento di ricevere quei quattro mesi di test prima di essere proposto. Un sistema 24.04 con Prompt=lts che durante l'estate del 2026 restituiva No new release found. non era guasto. Stava applicando la policy. Quando il percorso viene aperto, l'aggiornamento da 24.04 a 26.04 LTS è l'operazione 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 userspace che l'archivio LTS non include.
• La macchina è un host di build, un runner CI o un sistema di test che ricrei da un'immagine; in questo caso l'aggiornamento consiste nel creare una nuova istanza, non nell'aprire una finestra di manutenzione.
• Una funzionalità hardware o dell'hypervisor è stata introdotta dopo il congelamento della LTS e non esiste alcun backport.
• Stai verificando 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 riserva costa meno che trovarla sul sistema che conta.

La maggior parte delle persone che scelgono una release intermedia ha bisogno di un pacchetto più recente, non di una distribuzione più recente. Esistono due alternative meno costose. Lo stack di abilitazione hardware porta nell'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 fornitore aggiorna un solo componente invece dell'intero sistema operativo.

Quando scegliere la release interim è un errore

• Qualsiasi sistema con utenti paganti o un servizio di reperibilità. Accettereste un aggiornamento obbligatorio due volte l’anno in cambio di versioni dei pacchetti che potreste non usare mai.
• Qualsiasi macchina in cui unattended-upgrades esegue automaticamente l’applicazione delle patch di sicurezza. Questa automazione è affidabile solo quanto il pocket di sicurezza da cui recupera i pacchetti.
• Un parco di macchine che aggiornate manualmente, perché il costo reale è dato da una finestra di manutenzione moltiplicata per il numero di sistemi.
• Qualsiasi sistema che installate e poi non controllate per un anno. Una release interim dimenticata diventa, dopo nove mesi, un server esposto a Internet senza 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

Questa riga è identica sia su un server completamente aggiornato sia su un server la cui release è diventata obsoleta quattro mesi fa. Se nessuno legge gli errori di apt o tiene traccia della data di fine del ciclo di vita, nulla sulla macchina indica quale dei due casi si sta osservando.

Il tipo di modifica che arriva prima sul canale interim

Nel marzo 2026 un ingegnere di Canonical ha proposto sul forum Ubuntu Discourse di rimuovere, dalla versione 26.10, il bootloader GRUB firmato fornito per Secure Boot. La proposta elimina i driver del filesystem per btrfs, hfsplus, xfs e zfs, i parser delle immagini JPEG e PNG, le tabelle delle partizioni Apple, /boot su LVM, il RAID software diverso da RAID 1 e un /boot cifrato 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 RAM iniziale che il kernel monta prima del vero root. Ad agosto 2026 si tratta di una proposta ancora in discussione, non di una modifica già rilasciata.

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. Verifica il tuo sistema invece di dare questo per scontato. Se il tuo root è ZFS oppure /boot si trova su btrfs o all'interno di LUKS, questo è esattamente il tipo di modifica che può interessarti per primo sul canale interim; il consiglio dello stesso thread agli utenti coinvolti è di rimanere su una versione LTS. Questo consiglio riassume l'intera argomentazione in una frase. Le versioni interim sono il punto in cui le modifiche vengono sperimentate. Una LTS è il punto in cui arrivano dopo che due anni di versioni interim hanno evidenziato ciò che possono rompere.

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

Scelta del track durante la configurazione del server

Scegli il track al momento dell'installazione. Cambiarlo in seguito richiede una reinstallazione oppure 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 dovrebbe indicare la release che intendevi installare e, su una LTS, la riga della descrizione dovrebbe terminare con LTS. La riga Prompt dovrebbe corrispondere al track scelto, non a quello incluso 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 che la scelta fosse 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 alle altre note di configurazione del server. Questo rientra nelle attività dei primi dieci minuti su un nuovo VPS, perché una data di supporto conservata soltanto nella memoria di qualcuno è quella che scade senza che nessuno se ne accorga. Se vuoi evitare del tutto il ciclo di sei mesi, vale la pena dedicare un'ora alla lettura del modello di release di FreeBSD a confronto con Linux prima di scegliere una delle due opzioni per un'intera flotta.

FAQ

Devo usare una release interim di Ubuntu su un server di produzione?

Nella quasi totalità dei casi, no. Una release interim 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 le macchine che vengono comunque ricreate da un'immagine, come i runner CI e gli host di build. In questi casi, un aggiornamento corrisponde alla creazione di una nuova istanza, non all'apertura di una finestra di manutenzione. Se dal server dipendono utenti reali, installate la LTS e dedicate le finestre risparmiate ad altre attività.

Per quanto tempo è supportata una release interim di Ubuntu?

Nove mesi. 26.10 viene rilasciata il 15 ottobre 2026 e la manutenzione di sicurezza termina a luglio 2027, come è avvenuto per 25.10, terminata a luglio 2026. Ogni release interim segue lo stesso ciclo: viene rilasciata ad aprile o a 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 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 interim 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 ogni transizione singolarmente. Il programma di aggiornamento scarica uno strumento specifico per quel passaggio. Per questo non esiste uno strumento per un salto di due release e tale aggiornamento non viene mai proposto.

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

I suoi pacchetti vengono spostati su old-releases.ubuntu.com. Di conseguenza, sudo apt update inizia a fallire quando accede ad archive.ubuntu.com e restituisce errori 404. Per quella release non vengono più pubblicati nuovi aggiornamenti di sicurezza. La macchina non segnala questa situazione. Il server continua a funzionare e a gestire il traffico, mentre ogni nuova vulnerabilità pubblicata al suo interno rimane aperta. Il ripristino richiede un aggiornamento di release eseguito sotto pressione oppure una ricostruzione. È quindi necessario controllare la data, non attendere la comparsa dei sintomi.

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

Di solito 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, verificate quale kernel è in uso con uname -r. Se manca una versione dello userspace e non del kernel, un container o un repository del fornitore richiede una modifica molto più contenuta rispetto allo spostamento dell'intera macchina sul ciclo interim.