1 10/05/2026 10 min

CentOS 8 e CentOS Stream: il punto vero prima di toccare i repository

La migrazione da CentOS 8 a CentOS Stream non è un semplice upgrade di versione. È un cambio di modello operativo: da una distribuzione che riceveva rebuild dei pacchetti RHEL a un ramo che anticipa parte del lavoro che confluirà nella prossima minor release di Red Hat Enterprise Linux. In pratica, il sistema resta Linux enterprise class, ma la traiettoria dei pacchetti cambia. Questo dettaglio conta più del nome sulla release note, perché incide su stabilità percepita, tempi di aggiornamento e compatibilità con software di terze parti.

Se il server ospita solo servizi interni, applicazioni ben testate o ambienti di staging, CentOS Stream può essere una scelta ragionevole. Se invece il nodo è un riferimento per workload molto conservativi, appliance, stack vendor certificati o ambienti con finestre di change strette, va valutato con più attenzione. Il punto non è “Stream è buono o cattivo”: il punto è sapere che il flusso di aggiornamento è diverso e che la verifica va fatta prima, non dopo, il riavvio o il cambio dei mirror.

Quando ha senso migrare e quando no

Ha senso migrare se vuoi continuare a usare una base familiare al mondo RHEL, ma accetti una cadenza di update più dinamica. È utile anche se ti serve allinearti a pipeline CI/CD che testano spesso i pacchetti di sistema, o se il nodo è già gestito con automazione e rollback rapidi. Su macchine virtuali o host facilmente ripristinabili il rischio operativo è più basso, quindi il cambio di modello pesa meno.

Non ha senso migrare “alla cieca” su server con software certificato contro una specifica minor release di RHEL clone, su host di produzione senza snapshot o backup verificati, o su macchine in cui i pacchetti extra provengono da repository terzi poco mantenuti. In questi casi, prima di cambiare strada, conviene verificare se esiste una sostituzione già supportata: Rocky Linux, AlmaLinux, RHEL vero, oppure un refresh architetturale che elimini il vincolo invece di trascinarselo dietro.

Cosa cambia davvero: repository, ciclo di vita e aspettative

Su CentOS 8 classico il problema principale è la fine del supporto della linea tradizionale. Dopo EOL, i repository standard non sono più un punto di riferimento affidabile per patch e aggiornamenti ordinari. La migrazione a Stream serve proprio a uscire da questo vicolo cieco e riportare il sistema su un ramo mantenuto. Ma il prezzo è che i pacchetti non sono più “fotocopia” di RHEL: possono arrivare prima, con piccole differenze di comportamento, dipendenze o versioni di librerie.

Per un sysadmin questo significa una cosa molto concreta: i conflitti non si scoprono con il nome della distro, si scoprono con i pacchetti installati. Un stack PHP-FPM, una versione di PostgreSQL da repo esterno, un modulo kernel fuori albero, un agente di backup compilato contro librerie vecchie: tutti elementi che possono sopravvivere a un cambio di release, ma non sempre a un cambio di stream. Il controllo va fatto prima di sostituire gli URL dei repository e prima del primo `dnf distro-sync`.

Checklist tecnica prima della migrazione

Prima di iniziare, fotografa lo stato attuale. Non basta sapere che “il server va”: serve sapere cosa c’è sopra e come è stato ottenuto. La sequenza minima è questa.

  1. Verifica la release e il kernel installato.

    cat /etc/centos-release
uname -r
rpm -q kernel-core

  2. Elenca i repository attivi e quelli di terze parti.

    dnf repolist --enabled
ls -1 /etc/yum.repos.d/

  3. Salva lo stato dei pacchetti installati per confronto post-change.

    rpm -qa --qf '%{NAME} %{VERSION}-%{RELEASE}.%{ARCH}\n' | sort > /root/pkglist-before-centos-stream.txt

  4. Controlla spazio libero su `/`, `/boot` e sugli eventuali mount critici.

    df -hT
lsblk -f

  5. Verifica se ci sono pacchetti in hold, exclude o versionlock.

    dnf versionlock list 2>/dev/null || true
grep -R "exclude=" /etc/yum.repos.d/ /etc/dnf/ /etc/dnf/plugins/ 2>/dev/null || true

Se compare un gap, non andare avanti per intuito. Per esempio, se non sai quali repo terzi sono in uso, chiudi il gap con `dnf repolist -v` e con un inventario dei pacchetti non standard (`rpm -qa | grep -E 'remi|elrepo|epel|mariadb|nginx|postgresql|docker|kernel'`). Se non hai snapshot o backup verificato, quello è il primo prerequisito, non il secondo.

Strategia di migrazione: approccio prudente, non eroico

La migrazione va fatta come change controllato, non come operazione “una volta e via”. La strategia più pulita è: aggiornare tutto ciò che è possibile, rimuovere o congelare i componenti incompatibili, sostituire i repository CentOS 8 con quelli di Stream, eseguire il sync dei pacchetti, poi riavviare e validare servizi e dipendenze.

Il punto delicato è il passaggio da `dnf upgrade` a `dnf distro-sync`. Il primo porta avanti i pacchetti rispetto ai repo abilitati; il secondo riallinea il sistema al contenuto dei repository correnti, anche se questo implica downgrade o sostituzioni. È proprio il comportamento che ti serve quando cambi ramo, ma va usato con consapevolezza perché può toccare componenti che dipendono da versioni precise.

Procedura pratica: da CentOS 8 a CentOS Stream

La procedura più comune prevede l’uso del pacchetto di rilascio di Stream e la sostituzione dei repository. Il nome esatto dei pacchetti può variare in base al punto di partenza, ma il flusso resta questo: preparazione, swap dei repo, sincronizzazione, reboot, validazione.

  1. Aggiorna il sistema CentOS 8 fino all’ultimo stato disponibile e riavvia se hai appena aggiornato il kernel.

    dnf update -y
reboot

  2. Installa il pacchetto di rilascio di CentOS Stream e sostituisci i repository standard.

    dnf install -y centos-release-stream
rpm -q centos-release-stream

  3. Disabilita i repository CentOS Linux e abilita quelli Stream, verificando i file in `/etc/yum.repos.d/`.

    grep -R "^enabled=" /etc/yum.repos.d/ | sort

  4. Esegui il riallineamento dei pacchetti al nuovo ramo.

    dnf distro-sync -y

  5. Controlla eventuali conflitti, rimuovi solo i pacchetti che bloccano la transizione e ripeti il sync.

    dnf distro-sync -y --allowerasing

  6. Riavvia il nodo e verifica il ramo attivo.

    reboot
cat /etc/centos-release
uname -r

Il punto 5 è quello che spesso sblocca la transizione, ma va usato con criterio. `--allowerasing` può rimuovere pacchetti che non trovano più una combinazione valida nel nuovo set di repository. In un server con servizi esposti, questo non è un dettaglio. Prima di accettarlo, leggi l’elenco di ciò che verrebbe rimosso e confrontalo con il tuo inventario applicativo. Se trovi componenti critici, fermati e valuta una sostituzione controllata o il mantenimento temporaneo del vecchio nodo in parallelo.

Repo terzi, EPEL e moduli esterni: dove si rompe più spesso

La maggior parte dei problemi non arriva dal core del sistema, ma dai pacchetti esterni. EPEL di solito è gestibile, ma vanno controllate le versioni disponibili per Stream. Repo come Remi, ELRepo, PostgreSQL ufficiale, MariaDB, Docker, Influx, Elastic o vendor specifici hanno cicli propri e non sempre allineati al cambio di base OS. Un pacchetto che compila e parte non è automaticamente un pacchetto che resterà stabile dopo il `distro-sync`.

La verifica utile è semplice: per ogni servizio critico chiediti da quale repository arriva il pacchetto e se quel repository dichiara supporto per CentOS Stream. Lo fai con `dnf info nomepacchetto`, `rpm -qi nomepacchetto` e, se necessario, controllando il file repo corrispondente. Se il pacchetto è installato da sorgente o da build interna, verifica le dipendenze condivise: librerie OpenSSL, libxml, libpq, ICU, runtime PHP, Java, Python. È lì che spesso nasce l’incompatibilità silenziosa.

Servizi da validare subito dopo il reboot

Dopo il riavvio non limitarti a vedere se il sistema “sale”. Controlla i servizi che per te sono davvero il criterio di successo. In un host web tipico la sequenza minima è: rete, SSH, storage, database, web server, PHP-FPM o runtime applicativo, job scheduler, agent di monitoraggio e backup.

  1. Stato generale dei servizi.

    systemctl --failed
systemctl status sshd nginx httpd php-fpm mariadb postgresql --no-pager

  2. Log di boot e warning del kernel.

    journalctl -p warning -b --no-pager
journalctl -u nginx -u php-fpm -u mariadb -b --no-pager

  3. Verifica reachability dei servizi esposti.

    curl -I http://127.0.0.1/
curl -I https://127.0.0.1/ --insecure

  4. Controllo dei mount e dello spazio.

    mount | column -t
df -hT

  5. Se usi SELinux, verifica che non ci siano denials nuovi.

    ausearch -m avc -ts boot 2>/dev/null | tail -n 20
getenforce

Un errore tipico è considerare il servizio attivo anche se risponde male. Per esempio, `nginx` può essere up ma l’app dietro può restituire 502 perché `php-fpm` ha preso una libreria diversa o non riesce a caricare un modulo. Per questo la validazione deve andare oltre `systemctl is-active`: serve una richiesta reale, un log reale e, se possibile, un controllo applicativo che attraversi il layer reverse proxy, runtime e database.

Rollback: cosa preparare prima di fare il salto

Il rollback vero non è “spero di poter tornare indietro”. È avere un piano ripetibile. Su una VM, il rollback migliore è snapshot o restore dell’immagine disco prima del cambio. Su bare metal, il rollback realistico è un backup completo testato, più una procedura di reinstallazione con ripristino dati e configurazioni. Se il nodo è critico, il cambio va fatto su un clone o su un host parallelo, non sull’unico esemplare disponibile.

Dal punto di vista operativo, conserva almeno questi elementi: lista pacchetti pre-change, copia dei file in `/etc`, esportazione delle configurazioni applicative, dump dei database quando pertinente, e una nota con le versioni di kernel, librerie e servizi. Se qualcosa si rompe, non vuoi ricostruire da memoria. Vuoi confrontare stato prima/dopo e capire se il problema è nel ramo Stream, in un repo terzo o in una configurazione già fragile che il cambio ha solo fatto emergere.

Problemi tipici e come leggerli senza perdere tempo

Se `dnf distro-sync` fallisce con conflitti di dipendenze, quasi sempre c’è un pacchetto esterno che impone una versione non compatibile. Se dopo il reboot il sistema sale ma alcuni servizi no, il problema è più spesso in librerie condivise, permessi, policy SELinux o moduli caricati dal servizio. Se la rete non risponde come prima, controlla prima la configurazione di NetworkManager, i rename delle interfacce e le regole firewall, poi il resto.

Se compare una pagina bianca su stack LAMP/LEMP, non dare per scontato che sia colpa di Stream. Verifica `php-fpm`, i socket, i permessi su `session.save_path`, i log dell’app e il database. In un upgrade di base OS, i sintomi spesso arrivano da un effetto domino: una libreria cambia, un modulo non si carica, il service manager riavvia, il proxy riceve errore. Il fix strutturale non è “riprovare il reboot”, ma isolare quale dipendenza ha deviato dal comportamento atteso.

Una regola pratica che evita metà degli incidenti

Se il server ha più di un ruolo, separa il cambio in due fasi: prima la base OS, poi l’applicazione. In altre parole, non approfittare della migrazione per aggiornare anche stack PHP, database, web server e agent di terze parti nello stesso finestrone. Ogni ulteriore variabile rende più difficile attribuire il problema. Se qualcosa si rompe, devi sapere se è colpa del cambio di release o di un upgrade collaterale.

Questa disciplina vale ancora di più su ambienti con alta densità di servizi. Un nodo che ospita web, mail relay, backup agent e monitoring agent non va trattato come una workstation. Il cambio di distro è un evento infrastrutturale, non un semplice `dnf update`. Pianifica, misura, cambia una cosa alla volta e conserva sempre il punto di ritorno.

Conclusione operativa: il criterio giusto non è “si può fare”, ma “si può assorbire il rischio”

Migrare da CentOS 8 a CentOS Stream è tecnicamente fattibile e, in molti casi, è la strada più lineare per uscire dall’EOL senza cambiare famiglia di sistema. Però va letto come un cambio di contratto operativo: repository diversi, ritmo diverso, aspettative diverse. Se il tuo ambiente regge aggiornamenti più frequenti e hai un rollback serio, il passaggio è sensato. Se invece il nodo vive di compatibilità rigida e pacchetti esterni poco controllati, conviene fermarsi prima e riprogettare il percorso.

Assunzione: i comandi mostrati sono pensati per un host Linux recente con `dnf` e `systemd`; prima di eseguirli su produzione, verifica snapshot, repo terzi e dipendenze applicative.