Aggiornare CentOS 7 a 8: guida pratica passo passo

CentOS 7 non è una piattaforma da trascinare oltre il necessario: se devi passare a CentOS 8, trattalo come un cambio controllato, non come un semplice aggiornamento di pacchetti. Il punto critico non è solo il salto di release, ma l’impatto su kernel, librerie, repository, servizi e tool di amministrazione. In pratica: prima si misura lo stato attuale, poi si definisce il percorso di migrazione, poi si esegue con rollback pronto.

La strada più sicura è quasi sempre reinstallare CentOS 8 e migrare servizi e dati, non fare un upgrade in-place su una macchina di produzione senza finestra, test e backup verificati. Se hai un ambiente piccolo o un host non critico, puoi anche valutare un upgrade diretto, ma devi accettare il rischio operativo: i break più frequenti arrivano da repository non allineati, moduli terzi, configurazioni legacy e dipendenze RPM non più compatibili.

Prima domanda: davvero vuoi “aggiornare” o vuoi “migrare”?

Su CentOS 7 verso CentOS 8 la distinzione conta. Upgrade in-place significa cercare di trasformare il sistema esistente mantenendo host, hostname, IP e quasi tutta la configurazione. Migrazione significa costruire un nuovo sistema e spostare applicazioni, dati e servizi. In produzione, la seconda opzione è quasi sempre quella che riduce il blast radius.

Se hai un web server LAMP/LEMP, un nodo database o un server di posta, il problema non è solo il sistema operativo. Devi verificare compatibilità di PHP, MariaDB/MySQL, OpenSSL, librerie di sistema, firewall, SELinux e, in alcuni casi, del pannello di controllo. Anche un dettaglio banale come un modulo Apache non disponibile in CentOS 8 può bloccare il servizio dopo il riavvio.

Verifica iniziale: fotografia del sistema prima di toccare qualcosa

Prima di decidere la strategia, salva una fotografia dello stato. Non è burocrazia: è il tuo punto di confronto per capire se il nuovo host è davvero equivalente e per tornare indietro se qualcosa si rompe.

Esegui almeno questi controlli:

cat /etc/centos-release
uname -r
rpm -qa | sort > /root/rpm-list-centos7.txt
systemctl list-unit-files --state=enabled > /root/enabled-services.txt
ss -tulpn > /root/listening-ports.txt
ip a > /root/network-state.txt

Se il sistema ospita applicazioni web, registra anche versioni e configurazioni rilevanti:

httpd -v 2>/dev/null || nginx -v 2>&1
php -v
mysql --version 2>/dev/null || mariadb --version 2>/dev/null
crontab -l
ls -la /etc/httpd/ /etc/nginx/ /etc/php* /etc/my.cnf.d/ 2>/dev/null

Se usi servizi custom, annota anche i file unit di systemd in /etc/systemd/system/ e gli eventuali override in /etc/systemd/system/*.d/. È lì che spesso si annida il problema dopo la migrazione: path hardcoded, variabili d’ambiente mancanti, permessi o dipendenze non dichiarate.

Compatibilità: cosa rompe più spesso nel salto a CentOS 8

CentOS 8 introduce un ecosistema diverso da CentOS 7. Il cambio più visibile per chi gestisce stack server è il passaggio a versioni diverse di componenti di base e il fatto che molti repository di terze parti non sono allineati allo stesso modo. I casi più comuni sono questi:

Un errore tipico è dare per scontato che “se i file ci sono, il servizio riparte”. Non basta. Un virtual host Apache può essere sintatticamente valido ma fallire perché il modulo PHP-FPM non è attivo, il socket è cambiato o il contesto SELinux impedisce l’accesso alla directory document root.

Approccio consigliato: nuova installazione e migrazione ordinata

Se vuoi ridurre i rischi, questa è la sequenza giusta: prepari il nuovo server CentOS 8, replichi servizi e configurazioni, testi i componenti, sposti i dati, cambi il traffico. È il classico approccio blue/green adattato a un ambiente Linux tradizionale.

Backup: non farlo “a sensazione”

Il backup deve essere ripristinabile, non solo “presente”. Se non hai già una procedura di restore testata, la migrazione è un salto nel buio. Conserva almeno configurazioni, dati applicativi, dump database, chiavi di servizio e certificati. Se possibile, crea anche uno snapshot della VM o dell’istanza prima di iniziare.

Un set minimo ragionevole può essere questo:

tar czf /root/etc-backup.tgz /etc
rsync -aHAX --numeric-ids /var/www/ /backup/var-www/
mysqldump --single-transaction --routines --events --all-databases > /backup/all-databases.sql
cp -a /etc/pki /backup/pki-backup
cp -a /etc/letsencrypt /backup/letsencrypt-backup 2>/dev/null

Per i segreti, niente copie sparse e non controllate. Se hai chiavi private, token o credenziali in file di configurazione, redigili nel materiale operativo e pianifica la rotazione dove serve. Se una chiave è esposta durante la migrazione, considera compromesso il suo ciclo di vita: va sostituita, non solo copiata.

Nuovo host CentOS 8: base pulita e servizi minimi

Sul nuovo host installa solo ciò che serve davvero. Più pacchetti importi, più aumenti il rischio di conflitti e dipendenze non necessarie. Parti da rete, accesso remoto, repository ufficiali, strumenti base e monitoraggio essenziale.

Verifica subito lo stato del sistema:

cat /etc/centos-release
systemctl status sshd
firewall-cmd --state
getenforce

Se SELinux è attivo, bene. Non spegnerlo per comodità: adegua i contesti. Disabilitarlo per “far partire tutto” è un fix temporaneo che diventa debito tecnico e spesso maschera un errore di configurazione o di permessi.

Migrazione web stack: Apache o Nginx senza sorprese

Nel caso di un sito web, la migrazione va fatta in due livelli: prima la piattaforma, poi l’applicazione. Per Apache, esporta virtual host, rewrite, moduli e certificati. Per Nginx, controlla include, upstream e socket PHP-FPM. In entrambi i casi, fai un test di configurazione prima del riavvio.

apachectl configtest
nginx -t
php-fpm -t 2>/dev/null

Se il vecchio sistema usava PHP 7.x e sul nuovo host hai una versione diversa, verifica estensioni e compatibilità applicativa. Il test più utile non è la pagina iniziale del sito, ma il comportamento delle aree davvero sensibili: login, upload, form, cron applicativi, chiamate API e integrazioni esterne.

Un dettaglio pratico: se il sito è dietro CDN o proxy, fai i test bypassando la cache o puntando temporaneamente il file hosts al nuovo origin. Così eviti di confondere un problema applicativo con un contenuto ancora servito dall’edge precedente.

Database: il punto dove i problemi costano di più

Per i database, la regola è semplice: non improvvisare. Prima controlla versione e stato, poi prepara dump o replica, infine esegui il passaggio. Se il database è locale e piccolo, un dump e restore può bastare. Se è grande o con uptime critico, meglio replica, failover o migrazione a caldo con finestra ben definita.

Controlli minimi:

systemctl status mariadb
mysqladmin ping
mysql -e 'SHOW VARIABLES LIKE "version";'
mysql -e 'SHOW DATABASES;'

Dopo il restore, esegui un controllo di integrità applicativa: tabelle presenti, account applicativi, permessi, charset e collation. Un database che “si avvia” non è automaticamente un database sano. A volte il problema emerge solo quando l’applicazione prova a leggere un campo o a scrivere una coda.

Firewall, porte e accesso remoto

Durante la migrazione, non portarti dietro solo le porte “ovvie”. Mappa tutte le esposizioni reali: SSH, HTTP, HTTPS, SMTP, IMAP, POP, database, pannelli e agenti di monitoraggio. Un host apparentemente “su” ma irraggiungibile per firewall è un falso positivo classico.

Con firewalld verifica le zone attive e i servizi abilitati:

firewall-cmd --get-active-zones
firewall-cmd --list-all
firewall-cmd --list-services

Se devi aprire una porta, fallo in modo esplicito e con rollback pronto. Esempio: prima aggiungi la regola, poi verifichi il servizio, infine rimuovi eventuali eccezioni temporanee.

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

Cutover: come evitare il classico downtime inutile

Il cambio di traffico va fatto solo quando il nuovo host ha superato i test funzionali. Se hai un DNS con TTL basso, pianifica la variazione con anticipo. Se invece puoi cambiare IP su bilanciatore o reverse proxy, preferisci quella via: è più controllabile e più veloce da invertire.

Prima del cutover, controlla questi punti:

Un controllo semplice ma efficace è questo:

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

Se il sito usa hostname virtuali, prova anche con l’header corretto o con /etc/hosts sul tuo client di test. Molti errori arrivano da virtual host non selezionato, certificato sbagliato o redirect che punta ancora al vecchio ambiente.

Upgrade in-place: quando ha senso e quando evitarlo

Un upgrade in-place può avere senso su sistemi semplici, senza stack complessi e con manutenzione già standardizzata. Ma se il server ospita servizi critici, il rapporto rischio/beneficio tende a essere sfavorevole. Il vantaggio è la conservazione dell’ambiente; lo svantaggio è che ti porti dietro anche errori, workaround e configurazioni nate per CentOS 7.

Se decidi comunque di farlo, lavora sempre su una copia o su una macchina non critica. Verifica la disponibilità di tool e repository coerenti con il percorso di upgrade e leggi la documentazione del metodo specifico che intendi usare. Non tutte le combinazioni di pacchetti e repository terzi sono supportate allo stesso modo.

In pratica, prima di qualsiasi tentativo in-place devi avere:

Post-migrazione: controlli che evitano il falso “tutto ok”

Dopo il passaggio, non fermarti alla homepage. Controlla i log di sistema e applicazione, la saturazione delle risorse e il comportamento dei job schedulati. Il server può sembrare sano per 10 minuti e poi fallire al primo cron, al primo rinnovo TLS o al primo accesso a un endpoint poco usato.

Comandi utili per una verifica rapida:

journalctl -p err -xb
systemctl --failed
ss -tulpn
free -m
uptime
df -h

Se la macchina è web-facing, aggiungi un controllo delle metriche che ti interessano davvero: error rate, latency p95, tempi di risposta del backend, code in coda e saturazione CPU. Non basta vedere che “risponde”: devi capire se risponde bene.

Rollback: il piano che devi avere prima, non dopo

Il rollback deve essere realistico. Se hai scelto la migrazione su nuovo host, il rollback più rapido è tornare al vecchio server o ripristinare il puntamento DNS/load balancer. Se hai tentato un upgrade in-place, il rollback vero è quasi sempre il restore dello snapshot o del backup completo. Le mezze misure, in questa fase, allungano solo il fermo.

Per questo conviene mantenere il vecchio sistema acceso e non modificato almeno per il tempo necessario a validare il nuovo. Anche dopo il cutover, tienilo pronto per un eventuale switch inverso. Se devi ruotare certificati o credenziali durante la migrazione, fallo in modo coordinato su entrambi gli ambienti finché non hai chiuso la finestra.

Assunzione operativa: se il servizio è esposto agli utenti o ai clienti, consideralo in produzione fino a prova contraria e verifica ogni passaggio con evidenza osservabile, non con supposizioni.

Sequenza pratica consigliata, senza giri inutili

Se vuoi ridurre al minimo gli imprevisti, la vera regola è questa: non migrare il sistema, migra il servizio. Il sistema operativo è il contenitore; ciò che conta è che applicazioni, dati e integrazioni continuino a funzionare con lo stesso comportamento percepito dagli utenti. Se il nuovo host è più pulito, più osservabile e più facile da mantenere, hai fatto il lavoro giusto.

Se invece vuoi tentare l’upgrade diretto, fallo solo dopo aver capito esattamente cosa stai portando con te: repository, moduli, configurazioni, dipendenze, segreti e processo di recovery. Senza questa fotografia, l’aggiornamento da CentOS 7 a 8 è un cambio di etichetta, non una migrazione affidabile.