CentOS: cos’è, versioni, CentOS Stream e come usarlo su un server

CentOS è un progetto open source legato all’ecosistema Red Hat Enterprise Linux, ma il CentOS di oggi non coincide con il vecchio CentOS Linux che per anni è stato usato come alternativa gratuita e compatibile con RHEL. Quel modello è terminato: il progetto si concentra ora su CentOS Stream, una distribuzione che si colloca nel percorso di sviluppo fra Fedora e Red Hat Enterprise Linux.

Questa distinzione è il punto da chiarire prima di parlare di uso server, installazione o alternative. Se stai scegliendo una distribuzione per un nuovo server, devi capire se ti serve proprio Stream oppure se il tuo scenario è più adatto a RHEL, Rocky Linux, AlmaLinux, Ubuntu Server o Debian.

In questa guida vediamo quindi cos’è CentOS oggi, cosa è cambiato, quali versioni sono ancora mantenute, come installare e amministrare CentOS Stream e soprattutto quando ha senso sceglierlo per un server.

Cos’è CentOS oggi e cosa è cambiato

Il CentOS Project è una comunità e un progetto open source che sviluppa un ecosistema intorno a una piattaforma Linux. La sua distribuzione principale è oggi CentOS Stream.

Per anni il nome CentOS è stato associato soprattutto a CentOS Linux, una ricostruzione di Red Hat Enterprise Linux ottenuta dai sorgenti pubblici di RHEL e pensata per offrire un ambiente molto vicino a quello enterprise senza il contratto commerciale Red Hat.

Quel rapporto è cambiato.

CentOS Linux 8 ha raggiunto la fine del supporto il 31 dicembre 2021 e CentOS Linux 7 il 30 giugno 2024. Il progetto non ha prodotto un “CentOS Linux 9” nello stesso senso delle generazioni precedenti: la linea attiva è CentOS Stream.

La pagina ufficiale che confronta CentOS Linux e CentOS Stream chiarisce proprio questo passaggio.

Dal vecchio CentOS Linux a CentOS Stream

Il vecchio flusso può essere semplificato così:

Fedora → RHEL → CentOS Linux

CentOS Linux arrivava dopo RHEL: prendeva i sorgenti corrispondenti alla release enterprise e costruiva una distribuzione downstream, cioè a valle.

Con CentOS Stream la posizione cambia:

Fedora → CentOS Stream → RHEL

Stream si colloca prima delle successive release minori di RHEL. Il codice che supera i processi di sviluppo e validazione entra in questo flusso e permette alla community di vedere e contribuire a ciò che sta prendendo forma nell’ecosistema Enterprise Linux.

Questo non significa che CentOS Stream sia semplicemente una “beta di RHEL”. La documentazione del progetto lo descrive come una distribuzione continuamente aggiornata, costruita con gli ingegneri RHEL e utilizzabile come ambiente di sviluppo, base per i SIG e anche come sistema operativo di produzione. La differenza reale è dove si colloca nel ciclo di sviluppo e quale tipo di garanzia o supporto ti serve.

Fedora, CentOS Stream e RHEL: come sono collegati

Fedora è la parte più a monte del percorso: introduce più rapidamente nuove tecnologie e costituisce la base dalla quale vengono derivate le future generazioni Enterprise Linux.

CentOS Stream viene creato a partire da Fedora, ma segue poi un proprio ciclo. Il progetto indica una nuova major release indicativamente ogni tre anni e circa cinque anni di manutenzione, allineati alla fase di full support della corrispondente generazione RHEL.

RHEL è il prodotto enterprise commerciale di Red Hat. Aggiunge un modello di supporto, lifecycle, certificazioni, servizi e responsabilità del vendor che non coincide con quello di una distribuzione community.

Per capire la relazione tecnica senza affidarti alle vecchie definizioni della distribuzione, puoi consultare anche la documentazione ufficiale di CentOS Stream.

Perché non esiste CentOS Linux 9

È una delle confusioni più frequenti perché molti utenti cercano “CentOS 9” aspettandosi il successore diretto di CentOS Linux 8.

Quel successore, come rebuild downstream di RHEL, non è stato prodotto dal CentOS Project. La generazione 9 appartiene a CentOS Stream.

Se trovi una guida che presenta “CentOS 9” come la normale evoluzione del vecchio CentOS Linux senza spiegare Stream, il problema non è solo terminologico: rischia di farti scegliere il sistema sulla base di un modello che non esiste più.

A cosa serve CentOS e perché viene usato sui server

Stream è una distribuzione Linux general purpose particolarmente vicina all’ecosistema RHEL. Può essere usata per server web, ambienti di sviluppo, CI/CD, laboratori, infrastrutture cloud, container, servizi di rete e workload che beneficiano della compatibilità con il mondo Enterprise Linux.

Se il concetto di macchina server non ti è ancora chiaro, nella nostra guida abbiamo spiegato cos’è un server e come funziona. La distribuzione è il sistema operativo che può essere installato su quella macchina: non è il server fisico o virtuale in sé.

CentOS Server: cosa significa realmente

“CentOS Server” viene spesso usato come se fosse il nome di un prodotto separato. In pratica indica CentOS Stream configurato per svolgere ruoli server.

Puoi quindi installarlo su:

• un server fisico;
• una macchina virtuale;
• un VPS;
• un’istanza cloud;
• un ambiente di laboratorio;
• un nodo destinato a servizi web, database o container.

Su un VPS, per esempio, normalmente non devi partire necessariamente da una ISO: il provider può offrirti un’immagine Stream già pronta. In questo caso provisioning, rete iniziale e accesso SSH possono dipendere dalla piattaforma che ospita la VM.

Su un server dedicato, invece, potresti avere più controllo sul processo di installazione, sul partizionamento e sull’intero stack software.

Quando CentOS Stream ha senso

Lo prenderei seriamente in considerazione quando:

• lavori o sviluppi software destinato all’ecosistema RHEL;
• vuoi vedere prima ciò che entrerà nelle successive minor release RHEL;
• ti serve una piattaforma Enterprise Linux aperta alla collaborazione;
• vuoi un ambiente coerente con tooling e convenzioni tipiche RHEL;
• stai costruendo test, CI o proof of concept per sistemi che poi gireranno su RHEL;
• il tuo workload è compatibile con il modello di aggiornamento di Stream.

Il progetto stesso indica che Stream può essere usato anche in produzione. Questo però non rende automaticamente Stream la scelta migliore per ogni produzione.

Se un’applicazione richiede una certificazione vendor precisa, un lifecycle più lungo, supporto commerciale con SLA o una piattaforma che rimanga più strettamente legata a una specifica release enterprise, la decisione può spostarsi verso RHEL o verso altre distribuzioni Enterprise Linux.

Il criterio corretto non è quindi “Stream è stabile oppure no?”, ma:

quanto il tuo workload tollera e beneficia di un flusso più vicino allo sviluppo RHEL, e quali garanzie operative devi rispettare?

Versioni CentOS: quali sono ancora supportate

Parlare genericamente di “ultima versione” non basta, perché devi distinguere il vecchio ramo Linux da Stream.

Versione	Modello	Stato	Cosa fare
CentOS Linux 7	rebuild downstream di RHEL	EOL	pianificare la migrazione
CentOS Linux 8	rebuild downstream di RHEL	EOL	migrare verso una piattaforma supportata
CentOS Stream 8	ramo Stream	EOL	migrare
CentOS Stream 9	ramo Stream	supportato fino al 31 maggio 2027	mantenerlo o pianificare la transizione in base al workload
CentOS Stream 10	ramo Stream più recente	ciclo previsto fino circa al 2030	riferimento naturale per nuovi deployment compatibili

Il download ufficiale di CentOS espone le release Stream disponibili, le immagini ISO e le alternative per cloud e container.

CentOS Stream 9 o Stream 10?

Per un nuovo deployment non sceglierei automaticamente la versione con il numero più alto senza verificare tre cose:

1. compatibilità hardware;
2. compatibilità dell’applicazione;
3. lifecycle necessario.

Stream 10 è la major più recente e porta una base software più nuova. Stream 9 può però avere senso quando devi mantenere compatibilità con componenti, automazioni o software legati alla generazione Enterprise Linux 9 e hai già pianificato il passaggio successivo.

Se invece stai costruendo un nuovo ambiente senza vincoli legacy, Stream 10 è normalmente il punto da valutare per primo, soprattutto se il lifecycle di Stream 9 sarebbe troppo corto per il progetto.

Il requisito x86-64-v3 di CentOS Stream 10

Una differenza concreta di Stream 10 riguarda l’architettura x86_64. La release note ufficiale di CentOS Stream 10 specifica che i build AMD/Intel a 64 bit puntano al livello x86-64-v3.

Il vantaggio è poter sfruttare un set più moderno di funzionalità della CPU. La conseguenza è altrettanto importante: hardware x86 molto vecchio potrebbe non essere compatibile.

Prima di migrare una macchina fisica datata o una VM eseguita su host legacy, controlla quindi le capability reali della CPU. La documentazione ufficiale suggerisce anche di usare:

ld.so --help

per verificare i livelli supportati sul sistema.

È il genere di controllo che conviene fare prima della migrazione, non dopo aver scoperto che il nuovo sistema non può avviarsi sulla piattaforma prevista.

Come controllare il lifecycle prima di installare

Non affidarti al numero della major o alla data di pubblicazione di una guida.

Controlla sempre:

• pagina download ufficiale;
• release notes della major;
• fine supporto dichiarata dal progetto;
• compatibilità dell’applicazione;
• supporto del provider cloud o del software che dovrai installare.

Il lifecycle del sistema operativo è soltanto uno strato. Un runtime, un database o un repository aggiuntivo può avere una finestra di manutenzione diversa.

CentOS Stream 10: cosa cambia rispetto alle generazioni precedenti

Stream 10 non è soltanto “Stream 9 con numerazione nuova”. Cambia la baseline dell’intera piattaforma: kernel, toolchain, runtime, database e requisiti hardware appartengono a una generazione Enterprise Linux successiva.

BaseOS, AppStream e CRB

La struttura dei repository aiuta a capire dove arrivano i pacchetti.

BaseOS contiene il nucleo delle funzionalità del sistema operativo e i componenti necessari alla piattaforma base.

AppStream contiene applicazioni e runtime user-space destinati ai diversi workload. Alcuni componenti possono seguire lifecycle propri, quindi non devi assumere che ogni pacchetto abbia automaticamente la stessa durata della major.

CRB, CodeReady Builder, contiene pacchetti utili soprattutto per sviluppo e build ed è disabilitato per impostazione predefinita.

Questa separazione è importante quando installi dipendenze, repository aggiuntivi o software server: prima di abilitare sorgenti esterne, verifica se ciò che ti serve è già disponibile nei repository previsti dalla distribuzione.

Stack server e software di base

La release note di Stream 10 documenta una baseline moderna per kernel, linguaggi, web server e database. Tra i componenti elencati compaiono Apache HTTP Server, Nginx, PostgreSQL, MariaDB, MySQL, PHP, Python, Node.js e OpenJDK.

Non significa che devi installarli tutti sullo stesso server. Al contrario, un buon deployment parte dal workload e aggiunge solo i servizi necessari.

Se la macchina deve ospitare un sito web, per esempio, potresti avere bisogno di un server HTTP e di un runtime applicativo; il database può stare sulla stessa VM in un progetto piccolo oppure essere separato o gestito esternamente in un’architettura più complessa.

Funzioni rimosse e compatibilità

Ogni major release porta anche rimozioni o sostituzioni.

Nelle note di Stream 10, per esempio, il progetto segnala cambiamenti relativi a Xorg e la sostituzione di Redis con Valkey nella baseline della distribuzione. Non trattare quindi un major upgrade come un normale aggiornamento dei pacchetti.

Prima di migrare verifica sempre:

• software installato;
• repository terzi;
• moduli e driver;
• servizi custom;
• configurazioni SELinux;
• regole firewall;
• automazioni;
• runtime applicativi;
• dipendenze non incluse nei repository standard.

È questo inventario, più del comando di upgrade, a determinare quanto sarà difficile una migrazione.

CentOS Server: download e installazione

Il punto di partenza corretto è la pagina ufficiale di download già indicata sopra, non un mirror trovato casualmente.

Il progetto rende disponibili ISO, pacchetti, immagini cloud e container per diverse architetture. La scelta dipende da dove installerai il sistema.

ISO, cloud image o container: cosa scegliere

Per un server fisico o una VM che vuoi installare manualmente, puoi utilizzare un’immagine ISO.

La DVD ISO include un insieme ampio di pacchetti e può essere usata come sorgente di installazione completa. La Boot ISO è più piccola e serve principalmente ad avviare l’installer recuperando poi i componenti necessari dalle sorgenti configurate.

In cloud o su un VPS conviene prima controllare le immagini offerte dal provider. Se esiste una Stream image ufficiale o mantenuta dalla piattaforma, spesso è più sensato partire da quella anziché simulare un’installazione fisica via ISO.

Per workload containerizzati, invece, il progetto pubblica immagini dedicate: un container della distribuzione non sostituisce però un intero host. Kernel, rete e isolamento dipendono dal runtime e dal sistema host.

Come installare CentOS Stream passo passo

Su una macchina fisica o VM con installazione da ISO, il flusso generale è questo:

1. Scarica l’immagine per la tua architettura dalla pagina ufficiale.
2. Verifica checksum e provenienza dell’immagine prima di usarla.
3. Crea il supporto avviabile oppure collega l’ISO alla macchina virtuale.
4. Avvia il sistema dal supporto di installazione.
5. Imposta lingua, tastiera e fuso orario secondo il contesto.
6. Configura storage e partizionamento. Se il disco contiene dati, controlla con attenzione il layout prima di confermare.
7. Definisci rete e hostname se necessario per l’ambiente.
8. Scegli l’ambiente software coerente con il ruolo della macchina: su un server è spesso preferibile una base essenziale.
9. Crea gli utenti e le credenziali amministrative.
10. Avvia l’installazione e riavvia sul sistema appena creato.

Su VPS e cloud alcuni di questi passaggi vengono sostituiti dal provisioning del provider. Non modificare automaticamente indirizzamento, route o cloud-init appena entri nella VM: prima verifica come la piattaforma genera la configurazione.

Cosa configurare subito dopo l’installazione

Una macchina che ha completato il boot non è ancora un server pronto per essere esposto su Internet.

Partirei da questi controlli:

sudo dnf upgrade --refresh
hostnamectl
ip -br address
ip route
sudo ss -tulpn

Il primo comando aggiorna i pacchetti disponibili; gli altri aiutano a verificare identità della macchina, rete, route e servizi in ascolto.

Poi controlla l’accesso remoto. Se gestirai la macchina tramite SSH, il servizio è sshd:

sudo systemctl status sshd

e, quando deve essere abilitato:

sudo systemctl enable --now sshd

Per l’accesso remoto pubblico è preferibile utilizzare chiavi e verificare una seconda sessione funzionante prima di eliminare eventuali modalità di autenticazione che stai usando. Nella nostra guida dedicata trovi un approfondimento su come funziona SSH e come usarlo.

Come gestire un server CentOS

Non serve imparare centinaia di comandi per iniziare. Devi piuttosto capire quali strumenti controllano pacchetti, servizi, log, rete, firewall e sicurezza.

DNF e RPM per pacchetti e aggiornamenti

CentOS Stream usa il formato RPM e DNF come gestore dei pacchetti.

Per cercare un pacchetto:

dnf search nome-pacchetto

Per visualizzarne le informazioni:

dnf info nome-pacchetto

Per installarlo:

sudo dnf install nome-pacchetto

Per aggiornare il sistema:

sudo dnf upgrade --refresh

Prima di aggiungere repository esterni, chiediti perché servono. Ogni repository aggiuntivo introduce un’altra sorgente di pacchetti con proprie chiavi, politiche, tempi di aggiornamento e possibili conflitti.

systemd e systemctl per i servizi

I servizi vengono normalmente gestiti da systemd.

Per controllare lo stato di un servizio:

sudo systemctl status nome-servizio

Per avviarlo:

sudo systemctl start nome-servizio

Per abilitarlo anche ai successivi avvii:

sudo systemctl enable nome-servizio

Oppure puoi fare entrambe le operazioni:

sudo systemctl enable --now nome-servizio

Quando qualcosa non parte, evita la sequenza casuale “restart e speriamo”. Consulta anche i log:

sudo journalctl -u nome-servizio

Il log ti dice molto più di una serie di riavvii senza diagnosi.

SSH e amministrazione remota

Per un VPS, una VM cloud o un server headless, SSH è normalmente il canale principale di amministrazione.

La regola pratica è semplice: prima garantisci un accesso remoto funzionante, poi irrigidisci la configurazione.

Se cambi sshd_config, verifica la sintassi prima di ricaricare il servizio:

sudo sshd -t

Solo se non restituisce errori procedi con il reload appropriato.

Su una macchina esposta pubblicamente valuta autenticazione tramite chiavi, limitazione degli utenti autorizzati e politiche coerenti con il tuo modello di gestione. Cambiare semplicemente la porta SSH non sostituisce autenticazione robusta, aggiornamenti e controllo degli accessi.

firewalld: aprire soltanto ciò che serve

Negli ambienti Enterprise Linux firewalld è lo strumento standard per gestire il firewall host.

Prima controlla lo stato:

sudo firewall-cmd --state

Per visualizzare la configurazione della zona:

sudo firewall-cmd --list-all

Se devi esporre HTTP e HTTPS, puoi autorizzare i servizi necessari nella zona corretta:

sudo firewall-cmd --add-service=http --permanent
sudo firewall-cmd --add-service=https --permanent
sudo firewall-cmd --reload

Non copiare però queste regole se la macchina non deve pubblicare un sito web. Il firewall va costruito a partire dai servizi realmente raggiungibili.

E soprattutto: se stai lavorando da remoto, non applicare una policy che blocchi SSH prima di aver verificato la regola che mantiene il tuo accesso.

SELinux: perché non conviene disattivarlo alla cieca

SELinux aggiunge Mandatory Access Control alle normali autorizzazioni Unix e permette di limitare ciò che processi e servizi possono fare anche quando i permessi classici non bastano a fermarli.

Puoi vedere lo stato con:

getenforce

oppure ottenere più informazioni con:

sestatus

Se un’applicazione funziona solo dopo aver disattivato SELinux, non assumere che la soluzione definitiva sia lasciare il controllo disabilitato. Prima individua il denial, verifica contesti, porte, boolean e policy richieste.

Disattivare un livello di sicurezza perché una configurazione non è stata capita trasforma un problema diagnostico in un indebolimento permanente del sistema.

CentOS vs RHEL: qual è la differenza oggi

Il confronto moderno non è più “stesso sistema, uno gratis e uno a pagamento”.

Aspetto	CentOS Stream	Red Hat Enterprise Linux
Posizione nel ciclo	upstream delle successive minor release di RHEL	distribuzione enterprise rilasciata e supportata da Red Hat
Modello	distribuzione open source sviluppata pubblicamente come parte del processo di sviluppo RHEL	prodotto enterprise open source commercializzato e supportato da Red Hat
Aggiornamenti	continuous delivery: riceve continuamente modifiche destinate alle successive minor release RHEL	aggiornamenti gestiti secondo lifecycle e policy di rilascio RHEL
Supporto	community; nessun supporto Red Hat incluso	supporto Red Hat disponibile in base alla sottoscrizione
Certificazioni e SLA	non offre le stesse garanzie, certificazioni e SLA associati a RHEL	ecosistema di certificazioni hardware/software e servizi di supporto enterprise
Caso tipico	sviluppo e test per l’ecosistema RHEL; anche produzione quando il modello Stream è compatibile con i requisiti del workload	produzione con requisiti di supporto vendor, certificazioni, lifecycle enterprise o compliance

La spiegazione di Red Hat su CentOS conferma la differenza fra il vecchio CentOS Linux e l’attuale Stream.

Stream è upstream, il vecchio CentOS Linux era downstream

Questa è la differenza concettuale più importante.

CentOS Linux ricostruiva RHEL dopo il rilascio. Stream espone il ramo in cui prendono forma gli aggiornamenti della successiva minor release RHEL.

Per uno sviluppatore può essere un vantaggio: può verificare prima incompatibilità, proporre modifiche e allinearsi al futuro della piattaforma.

Per un’organizzazione che vuole soprattutto una release enterprise già definita, certificata e coperta da supporto vendor, questo stesso posizionamento può non essere il requisito prioritario.

Quando RHEL giustifica il costo

RHEL ha senso quando il valore non è soltanto “avere Linux”, ma avere un prodotto con un ecosistema commerciale attorno:

• supporto ufficiale;
• lifecycle enterprise;
• certificazioni hardware e software;
• responsabilità del vendor;
• strumenti e servizi Red Hat;
• requisiti di compliance o procurement.

Se nessuno di questi elementi serve al tuo progetto, la sottoscrizione può non essere il fattore decisivo. Se invece un fornitore certifica la sua applicazione solo su specifiche versioni RHEL, scegliere una distribuzione “simile” non equivale automaticamente a rispettare quella certificazione.

CentOS vs Ubuntu Server: quale scegliere

Stream e Ubuntu Server sono entrambe distribuzioni Linux valide per workload server, ma provengono da ecosistemi diversi e adottano strumenti e lifecycle differenti.

Criterio	CentOS Stream	Ubuntu Server
Ecosistema	Fedora / RHEL / Enterprise Linux	Debian / Ubuntu
Pacchetti	RPM	DEB
Gestore principale	DNF	APT
Firewall tipico	firewalld	UFW come frontend comune
Focus lifecycle	allineato allo sviluppo e al full support RHEL	release regolari più LTS
Scenario forte	RHEL development, Enterprise Linux, Stream	server general purpose, cloud, ecosistema Ubuntu
Supporto commerciale	non equivalente a una sottoscrizione RHEL	Canonical offre servizi commerciali

Se vuoi approfondire installazione e amministrazione dell’altra piattaforma, trovi una guida completa dedicata a Ubuntu Server.

RPM/DNF vs DEB/APT

La differenza più visibile per chi amministra la macchina è il sistema di pacchetti.

Su CentOS userai soprattutto RPM e DNF:

sudo dnf install nginx

Su Ubuntu userai pacchetti DEB e APT:

sudo apt install nginx

La sintassi è la parte facile. La differenza più profonda riguarda repository, packaging, release cadence, documentazione e compatibilità dell’ecosistema che gira intorno alla distribuzione.

Ecosistema RHEL vs ecosistema Ubuntu

Sceglierei Stream quando la vicinanza a RHEL è un requisito concreto: sviluppo destinato a RHEL, software Enterprise Linux, test anticipati o competenze interne già costruite su RPM/DNF, SELinux e firewalld.

Sceglierei Ubuntu Server quando il progetto è più legato all’ecosistema Debian/Ubuntu, quando il software è documentato e supportato soprattutto lì o quando il team possiede già procedure operative basate su APT e release LTS.

Non cambierei distribuzione solo perché una classifica online dichiara una delle due “migliore”. Il costo operativo maggiore arriva spesso da competenze, automazioni e compatibilità che devi ricostruire, non dal nome scritto sull’ISO.

Alternative a CentOS: Rocky Linux, AlmaLinux, RHEL, Ubuntu e Debian

Il passaggio dal vecchio CentOS Linux a Stream ha aperto uno spazio importante per le distribuzioni che vogliono offrire un’esperienza Enterprise Linux più vicina al modello downstream ricercato dagli utenti storici CentOS.

Le alternative non sono però intercambiabili.

Rocky Linux

Rocky Linux è una distribuzione Enterprise Linux community-oriented nata anche per rispondere all’esigenza lasciata dal cambio di direzione del progetto.

Il progetto mantiene più generazioni Enterprise Linux con lifecycle lunghi; la documentazione ufficiale delle release Rocky Linux indica quali versioni sono supportate e le relative finestre di manutenzione.

La valuterei se vuoi rimanere nell’ecosistema RHEL-like e cerchi una distribuzione downstream orientata alla compatibilità con Enterprise Linux.

AlmaLinux

AlmaLinux è un’altra distribuzione community enterprise sviluppata dalla AlmaLinux OS Foundation.

Il progetto dichiara compatibilità con RHEL secondo il proprio modello, ma non è corretto descriverla semplicemente come una “copia” del vecchio CentOS. Governance, build process e politiche del progetto sono propri.

La pagina delle release AlmaLinux permette di verificare versioni e lifecycle correnti.

Un dettaglio utile per l’hardware meno recente: AlmaLinux 10 offre anche una variante x86_64-v2, mentre CentOS Stream 10 su x86_64 punta a v3. Può diventare un criterio concreto quando stai migrando server più vecchi.

Red Hat Enterprise Linux

RHEL è la scelta da valutare quando servono supporto Red Hat, certificazioni, lifecycle e integrazioni enterprise formalmente riconosciute.

È anche il riferimento rispetto al quale va interpretato Stream. Se il tuo obiettivo è eseguire software certificato per RHEL, controlla sempre cosa considera supportato il vendor dell’applicazione: compatibilità tecnica e supporto contrattuale non sono la stessa cosa.

Ubuntu Server e Debian

Ubuntu Server e Debian escono dal ramo Enterprise Linux/RHEL, ma proprio per questo possono essere alternative migliori quando non hai bisogno di compatibilità RHEL.

Ubuntu offre release LTS, ampia disponibilità nei cloud e una grande quantità di documentazione. Debian privilegia un modello community e un ciclo più conservativo.

Se l’obiettivo è semplicemente costruire un web server, un VPS o un’applicazione Linux, non c’è un motivo automatico per restare nella famiglia RHEL.

Prima di scegliere il sistema operativo conviene anche distinguere il sistema dalla piattaforma su cui verrà eseguito: il confronto tra hosting Linux e hosting Windows risolve un problema diverso dalla scelta fra distribuzioni Linux.

Quale alternativa scegliere: matrice decisionale

Scenario	Prima scelta da valutare	Perché
sviluppi per future release RHEL	CentOS Stream	è parte del percorso di sviluppo RHEL
vuoi supporto e certificazioni Red Hat	RHEL	è il prodotto enterprise supportato dal vendor
vuoi restare RHEL-like con lifecycle downstream	Rocky Linux o AlmaLinux	modello orientato all’uso Enterprise Linux
hai hardware x86 che non supporta v3	verificare AlmaLinux x86_64-v2 o altra piattaforma compatibile	Stream 10 x86_64 punta a v3
vuoi una piattaforma server general purpose con release LTS	Ubuntu Server	ecosistema e lifecycle Ubuntu
preferisci una distribuzione community Debian	Debian	modello e strumenti Debian
devi testare compatibilità con ciò che arriverà in RHEL	CentOS Stream	riduce la distanza dal ramo che alimenta RHEL

La tabella serve come punto di partenza. La scelta finale deve includere applicazioni, supporto del provider, competenze del team, automazione, hardware e durata prevista del progetto.

Stai ancora usando CentOS 7 o CentOS 8? Cosa fare

Se un server esegue ancora CentOS Linux 7 o CentOS Linux 8, il problema principale non è che “sia vecchio”: la distribuzione non riceve più gli aggiornamenti ordinari del progetto.

Questo cambia il rischio operativo.

Una macchina EOL può continuare ad accendersi e far funzionare applicazioni per anni. Non significa che sia una piattaforma correttamente mantenuta.

Perché restare su una release EOL è un problema

Con l’EOL vengono meno gli aggiornamenti previsti dal progetto per quella release. Più passa il tempo, più aumenta la probabilità di dover convivere con:

• vulnerabilità non corrette dalla distribuzione;
• repository archiviati;
• software non più supportato;
• incompatibilità con tooling recente;
• difficoltà nel ricevere assistenza da vendor e provider;
• upgrade futuri più complessi.

Il fatto che l’applicazione “funzioni ancora” non misura lo stato di sicurezza o manutenibilità della piattaforma.

Migrare verso Stream, Rocky, AlmaLinux o RHEL

Non esiste una destinazione universale.

Stream ha senso se vuoi entrare nel modello Stream e il workload è compatibile con quel ciclo.

Rocky Linux o AlmaLinux sono candidati naturali se il motivo per cui usavi CentOS era avere una piattaforma Enterprise Linux downstream con lifecycle lungo.

RHEL è il percorso più lineare quando supporto e certificazioni Red Hat sono requisiti espliciti.

In altri casi può essere il momento giusto per rivalutare anche Ubuntu Server o Debian, soprattutto se l’applicazione non dipende dall’ecosistema RHEL.

Perché la migrazione va testata prima

Non trattare la migrazione del sistema operativo come un aggiornamento di routine.

Prima costruisci un inventario:

• pacchetti installati;
• repository esterni;
• versione del database;
• web server;
• runtime PHP, Python, Java, Node.js o altri linguaggi;
• servizi systemd;
• job schedulati;
• certificati;
• utenti e chiavi SSH;
• mount e storage;
• regole firewall;
• policy SELinux;
• software compilato manualmente;
• agent di backup, monitoring e sicurezza.

Poi riproduci il workload in un ambiente di staging o su una nuova VM.

Per molti server è più sicuro costruire una nuova macchina supportata, migrare applicazioni e dati, testare e infine spostare il traffico anziché trasformare in-place un sistema vecchio senza un rollback credibile.

Domande frequenti su CentOS

CentOS esiste ancora?

Sì. Il CentOS Project esiste e sviluppa CentOS Stream. Ciò che è terminato è CentOS Linux, il vecchio rebuild downstream di RHEL.

CentOS è gratuito?

CentOS Stream è software open source e può essere scaricato senza acquistare una sottoscrizione RHEL. Questo non significa però che supporto commerciale, hosting, amministrazione o software che installerai sopra siano necessariamente gratuiti.

Qual è l’ultima versione di CentOS?

La major Stream più recente è CentOS Stream 10. Prima di installarla verifica sempre la pagina ufficiale di download e le release notes perché immagini e pacchetti vengono aggiornati continuamente.

CentOS Stream è adatto a un server?

Sì. Può essere usato come sistema operativo server e il progetto stesso lo considera utilizzabile anche in produzione. Va però scelto conoscendo il suo posizionamento nel ciclo RHEL. Se ti servono supporto vendor, certificazioni o un modello downstream con lifecycle diverso, valuta RHEL, Rocky Linux o AlmaLinux.

CentOS ha un’interfaccia grafica?

Può eseguire un ambiente desktop, ma un server non richiede necessariamente una GUI. Per VPS, cloud e macchine headless l’amministrazione tramite SSH è spesso più semplice e riduce i componenti installati inutilmente.

Si può usare CentOS per WordPress?

Sì. WordPress può funzionare su CentOS Stream se configuri uno stack compatibile con i suoi requisiti: web server, PHP, database e HTTPS. La scelta della distribuzione non sostituisce però la corretta manutenzione di WordPress, PHP, database e servizi sottostanti.

Conclusione

CentOS non è scomparso, ma il CentOS che molti amministratori ricordano è cambiato radicalmente.

Se per “CentOS” intendi il vecchio rebuild gratuito e downstream di RHEL, quel prodotto non esiste più. Il progetto attuale ruota attorno a CentOS Stream, una distribuzione posizionata fra Fedora e RHEL e pensata anche come spazio pubblico in cui prende forma Enterprise Linux.

Per un nuovo server sceglierei Stream quando la vicinanza allo sviluppo RHEL è un vantaggio concreto, quando devo testare software destinato a quel mondo o quando il workload è compatibile con il modello Stream. Non lo sceglierei invece per inerzia solo perché “abbiamo sempre usato CentOS”.

Se l’obiettivo è riprodurre più da vicino il vecchio scenario Enterprise Linux downstream, confronterei Rocky Linux e AlmaLinux. Se servono supporto e certificazioni ufficiali, valuterei RHEL. Se la compatibilità RHEL non è un requisito, metterei sul tavolo anche Ubuntu Server e Debian.

La decisione migliore arriva quindi da una domanda molto pratica: quale piattaforma rende più semplice mantenere, aggiornare e supportare il tuo workload per tutto il suo ciclo di vita?