Fedora su VPS: il ciclo di supporto di 13 mesi

Quanto a lungo riceve aggiornamenti di sicurezza una release di Fedora?

Un server Fedora richiede un aggiornamento di versione circa una volta all'anno, per tutto il periodo in cui la macchina resta in esercizio. Fedora pubblica una nuova release all'incirca ogni sei mesi. Ogni release è supportata fino a circa quattro settimane dopo la pubblicazione della release di due versioni successive. In pratica, riceve aggiornamenti per circa 13 mesi. Dopo tale data, la release non riceve più alcuna correzione di sicurezza. Il server continua a funzionare, ma il suo insieme di pacchetti non viene più aggiornato.

Le date rendono il quadro concreto. Ad agosto 2026, le release supportate sono Fedora 43 e Fedora 44. Fedora 44 è stata pubblicata il 28 aprile 2026 e la fine del supporto è prevista per giugno 2027. Fedora 42 è stata pubblicata ad aprile 2025 ed è arrivata a fine supporto a maggio 2026, quattro settimane dopo l'arrivo di Fedora 44. Un server creato da un'immagine Fedora 42 era quindi fuori supporto tredici mesi dopo, senza che nessuno avesse commesso errori.

Fedora rispetto a una LTS, in mesi

LTS significa supporto a lungo termine: una release che il fornitore continua ad aggiornare con patch per anni invece che per mesi. EOL significa fine del ciclo di vita, cioè la data in cui gli aggiornamenti cessano. Di seguito sono riportate le informazioni pubblicate da ciascun progetto per la release che installeresti oggi.

[
  {
    "distro": "Fedora 44",
    "support_window": 13,
    "upgrades_per_decade": 10
  },
  {
    "distro": "Ubuntu 26.04 LTS",
    "support_window": 60,
    "upgrades_per_decade": 2
  },
  {
    "distro": "Debian 13 stable",
    "support_window": 36,
    "upgrades_per_decade": 3
  },
  {
    "distro": "AlmaLinux 10",
    "support_window": 120,
    "upgrades_per_decade": 1
  }
]

Fedora offre 13 mesi di supporto per release. Una Ubuntu LTS offre 60, mentre una rebuild enterprise come AlmaLinux offre 120. Considera la seconda colonna come il carico operativo. In dieci anni, Fedora richiede circa 10 aggiornamenti dell'intero sistema operativo, rispetto a 2 per Ubuntu LTS. Il valore di 36 mesi indicato per Debian corrisponde al normale supporto di sicurezza; un team LTS separato estende la durata della maggior parte delle release fino a circa cinque anni.

Queste sono finestre di supporto pubblicate e verificate ad agosto 2026, non tempi di disponibilità misurati. Il motivo delle differenze tra i cicli è descritto in la differenza tra Ubuntu LTS e release intermedie su un server. Qui conta il lavoro operativo che ciascuna opzione richiede.

Cosa comporta realmente un aggiornamento di versione di Fedora

DNF 5 è il gestore di pacchetti predefinito da Fedora 41 e dnf lo utilizza. Il comando system-upgrade fa parte di dnf5, quindi non è necessario installare prima alcun plugin. Partire dalla release corrente, completamente aggiornata:

sudo dnf upgrade --refresh
sudo reboot

Il riavvio è importante perché l'aggiornamento viene risolto in base a ciò che è installato e in esecuzione. Un aggiornamento parziale del kernel o di glibc rende quindi più difficile interpretare il passaggio successivo. Ora prepara la nuova release. Sostituisci 44 con la release a cui vuoi passare:

sudo dnf system-upgrade download --releasever=44

Questo risolve l'intera transazione e scarica tutti i pacchetti, senza modificare il sistema in esecuzione. Su un server di piccole dimensioni, prevedi alcune migliaia di pacchetti e da uno a tre gigabyte. Se dnf non riesce a risolvere la transazione, si arresta qui e indica il pacchetto che ha bloccato l'operazione. È il caso migliore, perché l'errore si verifica mentre la macchina è ancora attiva e hai ancora una shell.

Esegui quindi il comando:

sudo dnf offline status
sudo dnf system-upgrade reboot

dnf offline status conferma che una transazione è stata preparata ed è in attesa. dnf system-upgrade reboot riavvia la macchina per eseguire una transazione offline: un avvio minimale durante il quale la transazione RPM viene eseguita autonomamente. Questo approccio è necessario perché sostituire glibc e systemd mentre i servizi sono in esecuzione può lasciare il sistema installato solo parzialmente. Il server non sarà raggiungibile per l'intera durata della transazione, in genere diversi minuti su un VPS di piccole dimensioni, quindi si riavvierà nuovamente nella nuova release. Pianifica due riavvii e una finestra durante la quale SSH non risponderà.

Quando il sistema torna disponibile:

cat /etc/fedora-release
sudo dnf system-upgrade log --number=-1
sudo dnf distro-sync
sudo dnf repoquery --extras

/etc/fedora-release dovrebbe stampare una riga simile a Fedora release 44 (Forty Four). Il sottocomando log stampa il log della transazione eseguita durante l'avvio offline. È l'unico registro di ciò che è avvenuto mentre non avevi accesso a una shell. distro-sync aggiorna alla versione della nuova release tutto ciò che è rimasto indietro. repoquery --extras elenca i pacchetti installati che non si trovano più in alcun repository abilitato. È qui che puoi trovare i residui di un repository che non ha mai pubblicato pacchetti per la nuova release.

Crea uno snapshot del disco prima del download. La transazione viene eseguita mentre non puoi vedere lo schermo. Se si verifica un errore durante l'avvio offline, SSH non tornerà disponibile e l'unico modo per accedere al sistema sarà tramite la console fornita dal provider, VNC o seriale. Verifica di avere una console o uno snapshot prima di iniziare, non dopo.

C'è un altro controllo che spesso viene saltato:

sudo find /etc -name '*.rpmnew' -o -name '*.rpmsave'

Quando un pacchetto distribuisce un nuovo file di configurazione predefinito e hai modificato quello precedente, RPM non sovrascrive il tuo file. Scrive la versione inclusa nel pacchetto accanto a quella esistente come .rpmnew. Di conseguenza, sshd o nginx continua a comportarsi esattamente come nella release precedente, mentre i nuovi valori predefiniti restano inutilizzati sul disco. Leggi questi file dopo ogni aggiornamento. Installare rpmconf ed eseguire sudo rpmconf -a li analizza uno alla volta e mostra le differenze.

I repository di terze parti causano gli errori durante l'aggiornamento

I pacchetti Fedora vengono aggiornati insieme il giorno del rilascio. I pacchetti esterni a Fedora seguono invece la pianificazione dei rispettivi fornitori. La maggior parte dei repository dei fornitori include $releasever nell'URL. Dopo l'aggiornamento, quindi, dnf cerca un percorso che potrebbe non esistere ancora.

Elenca i repository configurati:

sudo dnf repo list --enabled
grep -R -e baseurl -e metalink /etc/yum.repos.d/

Per ogni repository che non appartiene a Fedora, verifica il supporto per la release di destinazione prima di confermare qualsiasi operazione:

sudo dnf --releasever=44 --repo=docker-ce-stable makecache

Se il fornitore ha pubblicato il repository per quella release, dnf scarica i metadati e termina senza messaggi. In caso contrario, viene restituito un errore 404 per un percorso come https://download.docker.com/linux/fedora/44/x86_64/stable/repodata/repomd.xml. Lo stesso errore interromperà l'operazione system-upgrade download successiva. Nelle prime settimane dopo una release Fedora, questa è la causa più comune per cui un aggiornamento non può iniziare.

Le opzioni sono due. Attendi alcune settimane che il fornitore pubblichi il repository. Di solito è la scelta corretta. In alternativa, esegui l'aggiornamento senza quel repository:

sudo dnf system-upgrade download --releasever=44 --disable-repo=docker-ce-stable

Disabilitare un repository non rimuove i relativi pacchetti. I pacchetti restano installati e senza gestione da parte del repository. Se impediscono di completare la transazione, dnf lo segnala. L'aggiunta di --allowerasing consente a dnf di rimuovere i pacchetti installati per risolvere il conflitto. Controlla quindi l'elenco delle rimozioni prima di confermare. È in quell'elenco che si rischia di rimuovere un database server che si intendeva mantenere.

Cosa succede a un server Fedora che non rispetta la finestra

Il giorno stesso non succede nulla. Il problema si manifesta la volta successiva in cui si usa il gestore dei pacchetti. Le release non più supportate vengono rimosse dalla rete di mirror e spostate nell'archivio, quindi dnf upgrade non riesce a recuperare i metadati e restituisce un errore 404 sull'URL metalink della release:

Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=fedora-42&arch=x86_64

La macchina continua a gestire il traffico di rete, ed è proprio questo a rendere il problema silenzioso e pericoloso. Non riceve aggiornamenti di sicurezza. Inoltre non può installare nulla. Quando viene pubblicato un avviso di sicurezza per OpenSSH o nginx, quindi, non esiste un metodo supportato per applicare la correzione.

È possibile risolvere il problema, ma la procedura è lenta. Puoi reindirizzare i repository all'archivio Fedora usando https://dl.fedoraproject.org/pub/archive/fedora/linux/ e aggiornare da lì. Fedora prevede il passaggio di una o due release alla volta. Un server fermo a quattro release precedenti richiede quindi diversi passaggi consecutivi. Ognuno può fallire e viene eseguito senza visibilità durante un avvio offline. Su un VPS, ricreare il server con un'immagine aggiornata e trasferire i dati è di solito il lavoro più breve e sicuro. È la stessa attività descritta in i primi dieci minuti su un nuovo VPS.

Gli aggiornamenti automatici applicano patch a una release. Non la aggiornano mai a una nuova versione.

Fedora può installare gli aggiornamenti secondo una pianificazione:

sudo dnf install -y dnf5-plugin-automatic
sudo systemctl enable --now dnf5-automatic.timer

Le impostazioni si trovano in /etc/dnf/automatic.conf, che sovrascrive i valori predefiniti forniti in /usr/share/dnf5/dnf5-plugins/automatic.conf. apply_updates è disabilitato per impostazione predefinita; quindi, nella configurazione iniziale, il timer scarica gli aggiornamenti ma non ne installa nessuno. upgrade_type sceglie tra default e security. reboot accetta never, when-changed oppure when-needed.

Questo mantiene il sistema aggiornato all'interno della stessa release. Non porterà mai Fedora 43 a Fedora 44, perché l'aggiornamento di versione è un'operazione separata e pianificata, che riavvia il sistema per eseguire una transazione offline. Questa è la differenza operativa principale rispetto a una LTS. Su Ubuntu, gli aggiornamenti di sicurezza non presidiati mantengono una macchina aggiornata per tutti i cinque anni previsti senza modificare la versione, mentre il cambio di versione è un'attività pianificata, come l'aggiornamento da 24.04 a 26.04, eseguita una volta ogni pochi anni.

Quando Fedora è la scelta giusta per un server

Fedora è una buona scelta quando l'aggiornamento frequente è l'obiettivo.

• Ti serve un kernel o uno userspace più recente di qualsiasi versione LTS: hardware recente oppure uno stack di container e systemd che arriverà in una release enterprise solo tra un anno. Fedora passa inoltre ai nuovi kernel upstream durante il ciclo di vita di una release, quindi il vantaggio non si limita al momento dell'installazione.
• Stai verificando ciò che confluirà in RHEL (Red Hat Enterprise Linux). Fedora alimenta CentOS Stream, che a sua volta alimenta RHEL; pertanto, il software che oggi viene compilato ed eseguito su Fedora viene testato sulla piattaforma enterprise dei prossimi anni.
• La macchina è progettata per avere una durata breve. Un build runner o un sistema di test che viene eliminato dopo due mesi non raggiunge mai la propria data di fine vita. La stessa logica si applica alle VM temporanee che assegni agli agenti di programmazione, in cui il sistema viene ricreato molto più spesso delle release di Fedora.
• Qualcuno è responsabile dell'upgrade. Fedora è adatta a un server con un responsabile identificato e un'attività pianificata in calendario. È invece una scelta inadatta per il sistema di cui tutti si sono dimenticati.

Il compromesso: pacchetti aggiornati su una base stabile

La maggior parte di chi vuole Fedora su un server ha bisogno di due o tre pacchetti aggiornati, non di un sistema operativo aggiornato. Le due esigenze sono separabili. Usate come base una distribuzione LTS o una ricostruzione enterprise, quindi installate il software più recente solo dove serve. Un'immagine container fornisce la nuova versione dell'applicazione su un host che non dovete aggiornare per questo motivo (eseguire Docker su un VPS). Un repository del fornitore per il singolo pacchetto che vi interessa, ad esempio PostgreSQL o nginx, aggiorna quel componente e lascia invariata la base.

Il compromesso è concreto in entrambe le direzioni. Un container fornisce uno userspace aggiornato sul kernel obsoleto dell'host, quindi non risolve il problema quando dovete aggiornare proprio il kernel. Un repository del fornitore fornisce un pacchetto più recente su una base che il fornitore ha testato meno. In entrambi i casi, gli aggiornamenti di sicurezza del sistema di base seguono il ciclo LTS. È questo ciclo a richiedere una finestra di manutenzione ogni anno su Fedora.

Se scegliete Fedora per un server, inserite il ciclo di aggiornamento nel calendario. Quando viene rilasciata una nuova versione, attendete alcune settimane affinché i repository dei fornitori si aggiornino, create uno snapshot, eseguite l'upgrade e verificate che i servizi siano tornati operativi. Questa procedura richiede circa un'ora all'anno e funziona. Il problema nasce quando ci si ricorda dell'upgrade soltanto perché qualcosa si è già guastato.

FAQ

Per quanto tempo è supportata una release di Fedora?

Per circa 13 mesi. Fedora pubblica una release all'incirca ogni sei mesi e supporta ciascuna release fino a circa quattro settimane dopo la pubblicazione della release successiva di due versioni. Fedora 44 è stata rilasciata il 28 aprile 2026, con fine del ciclo di vita prevista per giugno 2027. Dopo tale data, la release non riceve più aggiornamenti di sicurezza e i relativi pacchetti vengono rimossi dai mirror e spostati nell'archivio di Fedora.

Posso saltare una release di Fedora ed eseguire l'upgrade di due versioni in una volta?

Sì, entro certi limiti. dnf system-upgrade download --releasever= accetta come destinazione una release più recente di una o due versioni, e passare direttamente a una release di due versioni successive è esattamente il metodo usato per un ciclo di upgrade annuale. Andare oltre non è un percorso supportato e ogni release aggiuntiva aumenta la probabilità che una ridenominazione di pacchetto o una modifica del formato di configurazione interrompa la transazione. Se una macchina è già indietro di diverse release e ha superato la fine del ciclo di vita, in genere ricreare il sistema usando un'immagine aggiornata è più rapido di una catena di upgrade.

Cosa succede se il mio server Fedora raggiunge la fine del ciclo di vita?

Continua a funzionare, ma non riceve più patch. Il comando dnf upgrade successivo non va a buon fine e restituisce un errore 404 sull'URL metalink della release in uso, perché le release che hanno raggiunto la fine del ciclo di vita vengono spostate nell'archivio disponibile all'indirizzo dl.fedoraproject.org. È possibile reindirizzare a tale archivio i file dei repository ed eseguire l'upgrade per passaggi, oppure ricreare il server usando una release supportata. Fino a quando non si esegue una di queste operazioni, nessun aggiornamento di sicurezza può raggiungere la macchina e nessun pacchetto può essere installato.

Fedora è una scelta inadatta per un server di produzione?

È una scelta predefinita inadatta, ma può essere ragionevole se esiste un motivo specifico. Il costo consiste nell'eseguire ogni anno un upgrade completo del sistema operativo, per sempre, su una macchina che si potrebbe preferire non modificare. Scegli Fedora quando serve un kernel o uno userspace più recente di quello incluso in una release LTS, oppure quando il server è progettato per avere una durata breve. Scegli una release LTS o una ricostruzione enterprise quando vuoi applicare patch a un server per anni senza cambiarne la versione.