Migrare server CentOS 6, 7 e 8 a Oracle Linux

La migrazione da CentOS 6, 7 e 8 a Oracle Linux si fa bene solo se la tratti come un cambio controllato, non come un semplice reinstall. Il punto non è “convertire” un sistema e sperare che tutto resti uguale: devi prima capire cosa sta girando sulla macchina, quali servizi sono critici, quali repository usa, se il server è fisico o virtuale, e soprattutto quanto margine hai per un eventuale rollback.

Oracle Linux è compatibile a livello binario con l’ecosistema RHEL, ma il percorso operativo cambia in base alla versione di CentOS di partenza. Su CentOS 6 il salto è più delicato perché si entra in una zona di fine ciclo molto vecchia; su CentOS 7 il passaggio è più lineare; su CentOS 8 bisogna distinguere bene tra stream, repository attivi e pacchetti installati, perché il sistema è già vicino alla generazione attuale della piattaforma EL8/EL9. In pratica: prima si fotografa lo stato, poi si migra, poi si verifica che il sistema sia davvero tornato in servizio.

Quando conviene migrare e quando no

La migrazione ha senso se vuoi mantenere compatibilità con software enterprise, ridurre il rischio legato a una distribuzione fuori supporto o riallineare il parco macchine a una base più standardizzata. Ha meno senso se il server è già in dismissione, se l’applicazione è legata a pacchetti molto vecchi o se l’ambiente è talmente personalizzato da rendere più sicuro un rebuild pulito.

La regola pratica è semplice: se il server ospita servizi con dipendenze note e documentate, la conversione è ragionevole; se invece trovi librerie manualmente compilate, repository terzi non tracciati o modifiche sparse in più anni, spesso è più pulito ricostruire una nuova VM e migrare i dati e i servizi uno per uno.

Inventario prima del cambio

Prima di toccare il sistema, raccogli almeno questi elementi: versione esatta del sistema, kernel in uso, pacchetti installati da repository esterni, servizi attivi, stato di SELinux, configurazioni di rete, spazio disco e tipo di filesystem. Se salti questa fase, il rischio è di scoprire i problemi solo dopo il reboot o dopo il cambio dei repository.

Su un host Linux recente, i controlli base sono questi:

cat /etc/redhat-release
uname -r
rpm -qa | wc -l
systemctl list-unit-files --type=service --state=enabled
ip a
ip r
df -h
mount
getenforce

Se il sistema è CentOS 6, alcuni comandi possono non essere disponibili nella stessa forma di CentOS 7 e 8. In quel caso usa gli equivalenti storici, ma il concetto non cambia: devi sapere esattamente cosa stai portando avanti e cosa no.

Strategia corretta: backup, snapshot e finestra di manutenzione

La migrazione va fatta con un rollback credibile. Se il server è virtuale, lo snapshot della VM è spesso la forma più veloce di rete di sicurezza; se è fisico, serve almeno un backup verificato e testato, non solo eseguito. Per i dati applicativi, il backup del database e dei file di configurazione deve essere separato dal backup dell’intero sistema, così puoi recuperare in modo mirato anche se la conversione va solo parzialmente bene.

Le directory da salvare dipendono dal ruolo del server, ma in genere non dovrebbero mancare `\etc`, i dati applicativi, le home degli utenti di servizio, le configurazioni di web server, mail server e database, oltre a eventuali file di licenza o chiavi operative. I segreti non vanno mai lasciati in chiaro in documentazione o script condivisi: se devi conservarli per il rollback, usa un vault o un archivio protetto e ruota ciò che è opportuno ruotare dopo il cambio.

CentOS 6: il caso più delicato

CentOS 6 è il caso più fragile, perché parliamo di una piattaforma molto vecchia. Qui la domanda giusta non è solo “si può migrare?”, ma “ha senso farlo sullo stesso host?”. Se il sistema è ancora in produzione, la prima scelta tecnica da considerare è quasi sempre una ricostruzione su nuova VM con dati migrati, soprattutto se l’applicazione dipende da versioni vecchie di PHP, MySQL o librerie di sistema non più attuali.

Se devi procedere comunque, il lavoro corretto parte da una verifica di compatibilità dei pacchetti e delle dipendenze. In molti casi conviene usare la migrazione come occasione per standardizzare i repository e ridurre il numero di componenti legacy. Non aspettarti però una conversione “pulita” come con versioni più recenti: il rischio di conflitti tra pacchetti e configurazioni obsolete è alto, quindi il rollback deve essere pronto prima di iniziare.

CentOS 7: il percorso più lineare

Su CentOS 7 la migrazione è più gestibile perché la base è più vicina al target Oracle Linux. Qui l’obiettivo è preservare i servizi, sostituire i repository CentOS con quelli Oracle e riallineare il sistema con i pacchetti supportati. In molti ambienti il passaggio si può fare senza reinstallare da zero, ma solo se il server è pulito, aggiornato e non pieno di software installato a mano.

Prima di cambiare i repository, conviene aggiornare il sistema all’ultimo stato disponibile per la tua release, verificare che non ci siano pacchetti bloccati e rimuovere quanto non serve. Meno differenze hai tra lo stato corrente e il sistema target, meno possibilità hai di incontrare conflitti dopo il reboot.

CentOS 8: attenzione alla base repository

Su CentOS 8 il punto critico è la coerenza dei repository e del ciclo di vita della piattaforma. Prima di migrare, controlla quali repo sono attivi e se il sistema sta pescando da sorgenti miste, perché è uno dei modi più rapidi per creare un ambiente non ripetibile. Se trovi repository esterni per web stack, database o agent di monitoraggio, documentali prima di fare qualsiasi sostituzione.

Il cambio va impostato come una sostituzione controllata della base pacchetti, non come una sovrascrittura indiscriminata. Anche qui il principio è lo stesso: prima inventario, poi sostituzione, poi validazione dei servizi. Se il sistema è usato per applicazioni sensibili, prepara una finestra di manutenzione e comunica il rischio di breve indisponibilità, anche quando la procedura sembra lineare.

Flusso operativo consigliato

Il flusso sotto è quello che userei come base in un contesto reale, adattandolo alla versione di partenza e allo stato del server. Non è una ricetta magica: è una traccia prudente per non perdere il controllo del cambiamento.

1. Congela lo stato. Fai snapshot o backup completo, salva la configurazione dei servizi e verifica che il restore sia possibile. Se non hai un modo di tornare indietro, non partire.
2. Fotografa il sistema. Esporta elenco pacchetti, repository, servizi, utenti di servizio, cron, firewall e stato SELinux. Conserva l’output in un archivio separato dal server.
3. Pulisci il superfluo. Rimuovi pacchetti obsoleti o non usati, disabilita repository inutili e verifica che il sistema sia aggiornato per quanto possibile nella sua release attuale.
4. Prepara il target. Installa o abilita i repository Oracle Linux necessari, verificando che corrispondano alla versione corretta e al modello di supporto che intendi adottare.
5. Esegui la conversione. Segui il metodo supportato per la tua release, evitando procedure improvvisate. La parte delicata è il riallineamento dei pacchetti di base e del kernel.
6. Riavvia e verifica. Controlla kernel, servizi, log e funzionalità applicativa. Se il server non torna operativo in tempi brevi, fermati e passa al rollback.

Verifiche tecniche prima della conversione

Le verifiche che contano davvero sono quelle che riducono il numero di sorprese. Un esempio concreto: controlla se il sistema usa un kernel custom, se ci sono moduli terzi, se il boot dipende da configurazioni manuali o se l’applicazione ha hook particolari all’avvio. Tutto ciò che non è standard va trattato come rischio di compatibilità.

Una serie minima di controlli utili è questa:

rpm -qa | sort > /root/pkglist-before.txt
repoquery --installed > /root/repo-installed.txt 2>/dev/null || true
systemctl --failed
journalctl -p err -b --no-pager | tail -n 50
ss -tulpn

Se `repoquery` non è disponibile, annotalo come gap operativo e installa il pacchetto necessario solo se serve davvero e se il repository è affidabile. Non aggiungere strumenti al volo senza sapere da dove arrivano.

Repository, kernel e pacchetti base

La parte più importante della migrazione è il riallineamento della base di sistema. Devi evitare mix incoerenti tra pacchetti CentOS e Oracle Linux, soprattutto su componenti fondamentali come kernel, glibc, yum/dnf e librerie base. Un sistema con repository sporchi spesso sembra funzionare fino al primo aggiornamento serio, e lì emergono i conflitti peggiori.

Prima di cambiare, è utile salvare la configurazione dei repository attivi. Se usi file in `\etc\yum.repos.d\`, fai una copia completa in un percorso di backup separato. Dopo la conversione, confronta i file con un diff per verificare che non siano rimaste sorgenti obsolete o duplicate.

cp -a /etc/yum.repos.d /root/yum.repos.d.backup.$(date +%F)
ls -l /etc/yum.repos.d/
diff -ruN /root/yum.repos.d.backup.* /etc/yum.repos.d/ | less

Verifica post-migrazione

Dopo il reboot, non limitarti a controllare che il server risponda a ping. Quel test dice poco. Devi verificare il kernel in esecuzione, lo stato dei servizi, l’accessibilità delle porte applicative, i log di sistema e il comportamento del servizio principale. Se c’è un web stack, controlla anche la pagina di salute o l’endpoint applicativo, non solo la home page.

Un set minimo di controlli è questo:

cat /etc/redhat-release
uname -r
systemctl --failed
journalctl -b -p err --no-pager | tail -n 100
ss -tulpn
curl -I http://127.0.0.1/

Se il server espone un servizio diverso da HTTP, sostituisci l’ultimo controllo con una richiesta coerente: SMTP, SSH, database o API locale. Il punto è sempre lo stesso: verificare il layer applicativo reale, non solo il sistema operativo.

Rollback credibile se qualcosa va storto

Il rollback va pianificato prima della conversione. Se hai snapshot, il ritorno alla situazione iniziale è rapido; se hai solo backup file-level, devi sapere esattamente quali file ripristinare e in che ordine. In caso di problemi gravi dopo il cambio, non perdere tempo a fare tentativi casuali: torna allo stato precedente, riapri la finestra di analisi e confronta configurazioni, repository e log.

Il rollback deve coprire almeno tre livelli: sistema operativo, configurazioni applicative e dati. Se hai toccato solo la base pacchetti e non i dati, il rientro è più semplice; se hai cambiato anche configurazioni di servizio o schema applicativi, il ripristino richiede più attenzione. Per questo conviene mantenere separati backup del sistema e backup dei dati.

Errori comuni da evitare

Il primo errore è partire senza inventario. Il secondo è fidarsi di un backup mai testato. Il terzo è convertire un server con repository di terze parti senza sapere se esistono equivalenti compatibili. Il quarto è giudicare conclusa la migrazione appena il sistema si accende. In realtà il lavoro finisce solo quando i servizi sono operativi e i log sono puliti.

Un altro errore frequente è trattare tutte le macchine allo stesso modo. Un file server, un nodo web, un database host e una VM con software legacy non hanno lo stesso profilo di rischio. La migrazione va adattata al ruolo del server, non al contrario.

Scelta pratica tra conversione e reinstallazione

Se il server è semplice, ben documentato e con pochi servizi, la conversione può essere la strada più rapida. Se invece il sistema è vecchio, stratificato e pieno di eccezioni, la reinstallazione pulita è spesso la scelta più economica nel medio periodo. Il criterio non è ideologico: è il costo reale di mantenimento dopo la migrazione.

In molte infrastrutture mature, la soluzione migliore è ibrida: si crea un nuovo host Oracle Linux, si replicano i servizi essenziali, si migra il traffico e solo dopo si dismette il vecchio CentOS. È più laborioso all’inizio, ma riduce il rischio operativo e rende il rollback molto più semplice.

Assunzioni operative

Le indicazioni qui sopra assumono un ambiente Linux server con accesso amministrativo, finestra di manutenzione e possibilità di backup o snapshot. Se il server è in produzione senza margine di fermo, la scelta più prudente resta una migrazione parallela su nuovo host, non una conversione in-place.