Fedora Server su VPS: come gestire il ciclo di 13 mesi

Per quanto tempo una release di Fedora riceve aggiornamenti di sicurezza?

Un server Fedora richiede un aggiornamento di versione circa una volta all'anno, per tutto il ciclo di vita della macchina. Fedora pubblica una nuova release all'incirca ogni sei mesi. Ogni release è supportata fino a circa quattro settimane dopo il rilascio della versione successiva alla successiva, il che equivale a circa 13 mesi di aggiornamenti. Dopo tale data, la release non riceve più alcuna correzione di sicurezza. Il sistema continua a funzionare, con un set di pacchetti che nessuno corregge più.

Le date rendono il concetto concreto. Ad agosto 2026 le release supportate sono Fedora 43 e Fedora 44. Fedora 44 è stata rilasciata il 28 aprile 2026 e la sua fine del ciclo di vita è prevista per giugno 2027. Fedora 42 è stata rilasciata nell'aprile 2025 ed è giunta a fine ciclo di vita nel maggio 2026, quattro settimane dopo l'arrivo di Fedora 44. Un server creato da un'immagine di Fedora 42 è risultato quindi fuori supporto tredici mesi dopo, senza che sia stato commesso alcun errore operativo.

Fedora a confronto con una LTS, in mesi

LTS significa long term support: una release che il fornitore continua ad aggiornare per anni anziché per mesi. EOL significa end of life, la data in cui il rilascio di patch termina. Ecco cosa pubblica ogni 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 per ogni release. Una Ubuntu LTS ne offre 60, mentre una rebuild enterprise come AlmaLinux ne offre 120. Leggi la seconda colonna come il carico di lavoro. In dieci anni, Fedora richiede circa 10 aggiornamenti dell'intero sistema operativo, contro 2 su una Ubuntu LTS. Il dato di Debian di 36 mesi si riferisce al supporto di sicurezza standard, mentre un team LTS dedicato estende la maggior parte delle release a circa cinque anni.

Queste sono le finestre di supporto pubblicate, verificate nell'agosto 2026, non l'uptime misurato. Il motivo per cui le cadenze differiscono appartiene a la differenza tra Ubuntu LTS e le release intermedie su un server. Ciò che conta qui è il lavoro che ciascuna di esse comporta per te.

In cosa consiste effettivamente un aggiornamento di versione di Fedora

DNF 5 è il gestore pacchetti predefinito a partire da Fedora 41 e dnf lo esegue. Il comando system-upgrade è parte integrante di dnf5, quindi non è necessario installare alcun plugin preliminare. Se provieni da un sistema Debian o Ubuntu, la maggior parte dei comandi quotidiani ha un equivalente diretto tra apt e dnf, ma l'aggiornamento di versione descritto di seguito è una delle poche operazioni che non ha un vero corrispettivo. Inizia dalla release corrente, assicurandoti che sia completamente aggiornata:

sudo dnf upgrade --refresh
sudo reboot

Il riavvio è importante perché l'aggiornamento viene risolto in base a ciò che è installato ed in esecuzione; un aggiornamento del kernel o di glibc applicato solo parzialmente rende difficile diagnosticare i passaggi successivi. Ora prepara la nuova release. Sostituisci 44 con la release verso cui intendi aggiornare:

sudo dnf system-upgrade download --releasever=44

Questa operazione risolve l'intera transazione, scarica tutti i pacchetti e non modifica nulla sul sistema in esecuzione. Aspettati di scaricare alcune migliaia di pacchetti per un totale compreso tra uno e tre gigabyte su un server di piccole dimensioni. Se dnf non riesce a risolvere la transazione, si interrompe in questa fase indicando il pacchetto che ha causato il blocco. Questo è lo scenario migliore, poiché il fallimento avviene mentre la macchina è ancora attiva e hai ancora accesso alla shell.

Successivamente, avvia l'aggiornamento:

sudo dnf offline status
sudo dnf system-upgrade reboot

dnf offline status conferma che una transazione è pronta e in attesa. dnf system-upgrade reboot riavvia la macchina in una transazione offline: un avvio minimale in cui la transazione RPM viene eseguita in isolamento. Il processo funziona in questo modo perché sostituire glibc e systemd mentre i servizi sono in esecuzione porterebbe a un sistema installato solo parzialmente. Il server non sarà raggiungibile per l'intera durata della transazione, solitamente alcuni minuti su una VPS piccola, dopodiché si riavvierà nuovamente nella nuova release. Pianifica due riavvii e un intervallo di tempo in cui SSH non risponderà.

Al riavvio:

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 relativo a quell'avvio offline, che rappresenta l'unico registro di quanto accaduto mentre non avevi accesso alla shell. distro-sync aggiorna eventuali pacchetti rimasti alle versioni della nuova release. repoquery --extras elenca i pacchetti installati che non appartengono più ad alcun repository abilitato; è qui che troverai i residui di repository che non hanno pubblicato versioni per la nuova release.

Esegui uno snapshot del disco prima della fase di download. La transazione viene eseguita mentre non puoi monitorare lo schermo, quindi se fallisce durante l'avvio offline, SSH non tornerà attivo e l'unico modo per accedere sarà tramite la console fornita dal provider, VNC o seriale. Assicurati di avere accesso a una console o di aver effettuato uno snapshot prima di iniziare, non dopo.

Un ulteriore controllo che spesso viene ignorato:

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

Quando un pacchetto rilascia un nuovo file di configurazione predefinito e tu hai modificato quello vecchio, RPM non sovrascrive il tuo file. Scrive la versione fornita dal pacchetto accanto ad esso come .rpmnew. Di conseguenza, il tuo sshd o nginx continuerà a comportarsi esattamente come nella vecchia release, mentre le nuove impostazioni predefinite rimarranno inutilizzate sul disco. Leggi quei file dopo ogni aggiornamento. Installare rpmconf ed eseguire sudo rpmconf -a ti permetterà di esaminarli uno alla volta e visualizzare le differenze.

I repository di terze parti sono la causa dei problemi durante l'aggiornamento

I pacchetti ufficiali di Fedora vengono aggiornati simultaneamente al rilascio della nuova versione. Qualsiasi software proveniente da fonti esterne a Fedora segue invece una pianificazione propria. La maggior parte dei repository dei vendor inserisce $releasever nel proprio URL; di conseguenza, non appena si esegue l'aggiornamento, dnf inizia a richiedere un percorso che potrebbe non essere ancora disponibile.

Elenca i repository attivi:

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

Per ogni repository che non appartiene a Fedora, verifica la compatibilità con la versione di destinazione prima di procedere con qualsiasi operazione:

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

Se il vendor ha pubblicato i pacchetti per quella versione, dnf scarica i metadati e termina senza errori. In caso contrario, si riceverà un errore 404 per un percorso simile a https://download.docker.com/linux/fedora/44/x86_64/stable/repodata/repomd.xml e lo stesso errore bloccherà system-upgrade download in seguito. Nelle prime settimane successive al rilascio di una versione di Fedora, questo è il motivo più comune per cui un aggiornamento non viene avviato.

Hai due opzioni. Attendere alcune settimane che il vendor pubblichi gli aggiornamenti, che solitamente è la scelta corretta. Oppure procedere all'aggiornamento senza quel repository:

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

Disabilitare un repository non rimuove i pacchetti installati da esso. Questi rimangono sul sistema senza essere gestiti e, se bloccano la transazione, dnf lo segnalerà. L'aggiunta di --allowerasing consente a dnf di rimuovere i pacchetti installati per risolvere il conflitto; pertanto, leggi attentamente l'elenco di rimozione prima di accettare. È proprio in quell'elenco che gli utenti rischiano di rimuovere involontariamente un server di database che intendevano mantenere.

Cosa succede a un server Fedora che perde la finestra di aggiornamento

Non succede nulla il giorno stesso. Il problema si manifesta la volta successiva in cui si interagisce con il gestore pacchetti. Le versioni giunte a fine ciclo di vita vengono rimosse dalla rete dei mirror e spostate nell'archivio; di conseguenza, dnf upgrade fallisce durante il recupero dei metadati, restituendo un errore 404 sull'URL del metalink della propria versione:

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

La macchina continua a gestire il traffico, il che rende questa situazione silenziosa e pericolosa. Non riceve alcun aggiornamento di sicurezza. Inoltre, non è possibile installare nulla, quindi nel momento in cui viene pubblicato un bollettino di sicurezza per OpenSSH o nginx, non si dispone di alcun metodo supportato per applicare le patch.

Uscire da questa condizione è possibile, ma lento. È necessario reindirizzare i repository verso l'archivio di Fedora su https://dl.fedoraproject.org/pub/archive/fedora/linux/ ed eseguire l'avanzamento di versione da lì. Fedora prevede un salto di una o due versioni alla volta; pertanto, un sistema arretrato di quattro versioni richiede diversi passaggi consecutivi, ognuno con il rischio di fallimento e ognuno eseguito senza supporto in fase di avvio. Su un VPS, ricostruire il sistema partendo da un'immagine aggiornata e migrare i dati è solitamente l'operazione più rapida e sicura, e comporta lo stesso lavoro descritto in i primi dieci minuti su un nuovo VPS.

Gli aggiornamenti automatici applicano le patch a una release. Non eseguono mai un upgrade della stessa.

Fedora può installare i propri aggiornamenti tramite un timer:

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

Le impostazioni risiedono 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, appena installato, il timer scarica gli aggiornamenti ma non ne installa nessuno. upgrade_type permette di scegliere tra default e security. reboot accetta never, when-changed o when-needed.

Questo mantiene il sistema aggiornato all'interno della stessa release. Non passerà mai da Fedora 43 a Fedora 44, poiché l'avanzamento di versione è un'operazione distinta e deliberata che richiede un riavvio per eseguire una transazione offline. Questa è la differenza pratica rispetto a una versione LTS. Su Ubuntu, gli aggiornamenti di sicurezza automatici mantengono una macchina operativa per l'intero arco dei cinque anni senza alcun cambio di versione, e il passaggio di versione stesso è un'attività pianificata, come l'upgrade dalla 24.04 alla 26.04, che avviene solo ogni pochi anni.

Quando Fedora è la scelta giusta per un server

Fedora è una buona scelta quando la novità è l'obiettivo principale.

• È necessario un kernel o uno userspace più recente di quanto offra qualsiasi versione LTS: hardware recente, oppure uno stack di container e systemd che arriverà su una release enterprise solo tra un anno. Fedora adotta nuovi kernel upstream durante il ciclo di vita di una release, quindi il vantaggio non si limita al momento dell'installazione.
• Si sta validando ciò che confluirà in RHEL (Red Hat Enterprise Linux). Fedora alimenta CentOS Stream, che a sua volta alimenta RHEL; pertanto, il software che viene compilato ed eseguito oggi su Fedora viene testato in vista della piattaforma enterprise di tra un paio d'anni.
• La macchina ha una vita breve per progettazione. Un build runner o un ambiente di test che viene eliminato dopo due mesi non raggiungerà mai la data di fine supporto. La stessa logica si applica alle VM usa e getta fornite agli agenti di programmazione, dove la macchina viene ricostruita molto più spesso di quanto Fedora rilasci nuove versioni.
• Qualcuno si occupa dell'aggiornamento. Fedora è adatta a un server che ha un responsabile designato e una pianificazione degli interventi. È invece una scelta inadeguata per una macchina di cui tutti si sono dimenticati.

La via di mezzo: pacchetti aggiornati su una base stabile

La maggior parte degli utenti che desidera Fedora su un server necessita di due o tre pacchetti aggiornati, non di un sistema operativo interamente aggiornato. Questi aspetti sono separabili. Utilizza una distribuzione LTS o una build enterprise come base, quindi importa il software nuovo solo dove è effettivamente necessario. Un'immagine container fornisce la nuova versione dell'applicazione su un host che non dovrai mai aggiornare per questo scopo (eseguire Docker su una VPS). Un repository del fornitore per il singolo pacchetto di tuo interesse, come PostgreSQL o nginx, aggiorna solo quel componente lasciando invariata la base.

Il compromesso è trasparente in entrambe le direzioni. Un container offre un nuovo userspace sul vecchio kernel dell'host, quindi non è utile se è proprio il kernel ciò di cui hai bisogno. Un repository del fornitore fornisce un nuovo pacchetto su una base che il fornitore ha testato meno. Entrambi mantengono gli aggiornamenti di sicurezza del sistema di base secondo il ciclo LTS, e quel ciclo è la parte che su Fedora ti costa una finestra di manutenzione ogni anno.

Se scegli Fedora per un server, pianifica il ciclo sul calendario. Quando viene rilasciata una nuova versione, attendi alcune settimane affinché i repository dei fornitori si allineino, esegui uno snapshot, aggiorna e infine verifica che i servizi siano tornati operativi. Questo ritmo richiede circa un'ora all'anno e funziona. La versione che fallisce è quella in cui l'aggiornamento viene ricordato solo perché qualcosa si è già rotto.

FAQ

Per quanto tempo è supportata una release di Fedora?

Circa 13 mesi. Fedora pubblica una release all'incirca ogni sei mesi e supporta ciascuna di esse fino a circa quattro settimane dopo il rilascio della versione successiva alla seconda. Fedora 44 è stata rilasciata il 28 aprile 2026 con fine vita prevista per giugno 2027. Superata tale data, la release smette di ricevere aggiornamenti di sicurezza e i suoi pacchetti vengono rimossi dai mirror per essere spostati nell'archivio di Fedora.

Posso saltare una release di Fedora e aggiornare due versioni in una volta sola?

Sì, entro certi limiti. dnf system-upgrade download --releasever= accetta una destinazione con una o due release di vantaggio, e saltare due versioni alla volta è esattamente il modo in cui funziona un ritmo di aggiornamento annuale. Andare oltre non è un percorso supportato e ogni release aggiuntiva aumenta la probabilità che una ridenominazione di pacchetto o una modifica al formato di configurazione blocchi la transazione. Se una macchina è già indietro di diverse release e ha superato la fine del ciclo di vita, ricostruirla su un'immagine corrente è solitamente più rapido rispetto a una catena di aggiornamenti.

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

Continua a funzionare ma smette di ricevere patch. Il successivo dnf upgrade fallisce con un errore 404 sull'URL del metalink per la tua release, poiché le release a fine vita vengono spostate nell'archivio all'indirizzo dl.fedoraproject.org. Puoi reindirizzare i file dei repository verso quell'archivio ed eseguire l'aggiornamento a tappe, oppure ricostruire il server su una release supportata. Finché non esegui una di queste due operazioni, nessun aggiornamento di sicurezza può raggiungere la macchina e nessun pacchetto verrà installato.

Fedora è una scelta sbagliata per un server di produzione?

È una scelta predefinita sbagliata, ma una scelta ragionevole se supportata da una motivazione. Il costo è un aggiornamento completo del sistema operativo ogni anno, per sempre, su una macchina che potresti preferire non toccare. Scegli Fedora quando hai bisogno di un kernel o di uno userspace più recenti di quanto offra una versione LTS, o quando il server è progettato per avere una vita breve. Scegli una LTS o una distribuzione enterprise quando vuoi applicare patch a un server per anni senza cambiarne la versione.