Fedora 45 è pronta. Il tuo sistema lo è davvero?

Fedora Linux 45 è disponibile dal 3 novembre 2026. Il comunicato ufficiale elenca nuove versioni di GNOME, KDE, strumenti di sviluppo e funzionalità di installazione. Tutto vero. Ma per chi amministra una macchina su cui girano servizi, container e VPN, la domanda interessante non è quali numeri siano cambiati. È quali assunzioni della configurazione precedente smettano di essere valide dopo l’aggiornamento.

Il rilascio comprende Workstation, KDE Plasma Desktop, Server, Cloud, CoreOS, IoT, Atomic Desktops e Spins, come confermano Fedora Magazine e LWN. Non sono però sistemi intercambiabili: un desktop tradizionale, un host container e un sistema Atomic hanno percorsi di aggiornamento e ripristino differenti. Trattarli allo stesso modo è il primo errore da evitare.

Il numero della release non misura il rischio

Un upgrade può terminare senza errori e lasciare comunque un servizio inutilizzabile. Il pacchetto si installa, il sistema si riavvia, il login funziona. Poi scopri che il client VPN non è più disponibile, che un container dipendeva da una modalità di networking superata o che un percorso di storage non viene montato come previsto. Non è un paradosso: il successo del package manager e la continuità operativa sono due verifiche diverse.

Per questo il primo lavoro non è avviare DNF. È costruire un inventario: filesystem e cifratura, servizi systemd, connessioni VPN, container, repository aggiuntivi, moduli kernel, applicazioni con runtime vincolati e modalità di accesso remoto. L’inventario va confrontato con le modifiche effettive della release, non con una lista generica di novità.

Storage: Stratis in Anaconda è una possibilità, non una migrazione automatica

La novità più interessante per chi installa macchine è il supporto integrato a Stratis nell’installer Anaconda. L’annuncio Fedora descrive la possibilità di configurare pool e filesystem tramite Cockpit Storage nelle installazioni grafiche, oppure tramite direttive dedicate in Kickstart per quelle automatizzate. Stratis combina componenti come device-mapper, XFS e LUKS per gestire pooling, provisioning, dimensionamento e cifratura.

Questo non significa che un’installazione esistente venga convertita a Stratis durante l’upgrade. Significa che la piattaforma offre nuove opzioni per progettare installazioni e provisioning. La differenza conta: il progetto del layout dei dischi deve essere esplicito e verificato. Prima di cambiare filesystem o partizionamento, servono backup ripristinabili, una prova di boot e una procedura di recupero che non dipenda dalla stessa macchina che stai modificando.

Non è neppure prudente confondere snapshot con backup. Uno snapshot locale può aiutare a tornare a uno stato precedente, ma non protegge necessariamente dal guasto del disco, da errori di configurazione persistenti o da un incidente che coinvolga l’intero host.

VPN e sicurezza: il problema sono le dipendenze invisibili

Fedora segnala esplicitamente il ritiro dei plugin NetworkManager-vpnc e NetworkManager-fortisslvpn. Se una connessione remota di lavoro si appoggia a uno di questi componenti, non basta verificare che il sistema si aggiorni: bisogna verificare prima l’alternativa supportata e testare l’autenticazione. È particolarmente importante quando quella VPN rappresenta l’unico percorso per intervenire sulla macchina da remoto.

Fedora 45 introduce inoltre controlli più rigorosi sulle firme dei pacchetti e altre modifiche di sicurezza documentate nel ciclo di rilascio. È una direzione sensata, ma può far emergere repository di terze parti o pacchetti locali che prima passavano senza una verifica sufficiente. La risposta corretta non è disattivare il controllo per far funzionare l’installazione: è capire da dove proviene il pacchetto, come viene firmato e chi ne garantisce gli aggiornamenti.

Container e toolchain: il test deve riprodurre il carico reale

Il rilascio aggiorna profondamente toolchain e librerie, con componenti come Python 3.15, GCC 16.2 e Podman 6 riportati nelle panoramiche tecniche del rilascio. Un numero di versione più recente non certifica la compatibilità di un progetto. Un’estensione compilata, uno script di automazione o una configurazione di rete container possono avere vincoli che non compaiono nel changelog generale.

Su una macchina di sviluppo la prova dovrebbe includere build pulita, suite di test, connessione ai database e avvio dei container. Su un host operativo servono anche test dei servizi dopo il reboot, persistenza dei volumi, networking, job pianificati, log e osservabilità. Se non hai una lista di controlli ripetibile, stai facendo un esperimento, non una procedura di aggiornamento.

Una procedura sensata prima di premere Invio

• Classifica le macchine. Desktop, server, VM, Cloud e Atomic richiedono piani diversi.
• Leggi i problemi noti. Consulta la documentazione Fedora e i blocker risolti; non dedurre la sicurezza dal solo annuncio.
• Verifica il backup. Prova almeno il recupero dei dati critici e documenta come ripristinare l’accesso.
• Riproduci il carico. Testa in VM o staging le dipendenze che usi davvero.
• Prepara il rollback. Definisci prima cosa fare se il sistema parte ma il servizio non funziona.
• Aggiorna per fasi. Una macchina pilota prima delle altre, con un intervallo di osservazione e criteri di stop.

Per un sistema Fedora tradizionale il percorso di aggiornamento passa dalla documentazione DNF system-upgrade; per Atomic Desktops valgono procedure di rebase specifiche. Non copiare comandi da un articolo senza verificare edizione, architettura, release di partenza e stato dei repository. Le istruzioni ufficiali per l’upgrade sono il punto di partenza, non una sostituzione dell’inventario.

Il vero aggiornamento è la qualità del processo

Fedora 45 porta novità concrete. Stratis nell’installer, gli aggiornamenti del desktop e delle toolchain e le modifiche alle policy di sicurezza meritano attenzione. Ma il valore di una release non si misura solo in funzionalità aggiunte: si misura anche nella capacità di adottarle senza perdere controllo sul sistema.

Chi gestisce sistemi dovrebbe pretendere tre cose da ogni upgrade: sapere cosa cambia, poter verificare che ciò che conta continui a funzionare e avere una strada praticabile per tornare indietro. Il resto è entusiasmo per il numero stampato sulla schermata di avvio.