CentOS Linux come distribuzione stabile non esiste più: CentOS Linux 8 si è fermato alla fine del 2021, CentOS 7 il 30 giugno 2024, e anche CentOS Stream 8 ha chiuso a maggio 2024. Per chi ha server con applicazioni PHP, gli eredi naturali sono Rocky Linux e AlmaLinux, compatibili con Red Hat Enterprise Linux, gratuiti e con un supporto di sicurezza dichiarato fino al 31 maggio 2029 per la versione 8, al 31 maggio 2032 per la 9 e al 31 maggio 2035 per la 10.
Sulla carta la migrazione è semplice, perché esistono strumenti ufficiali che convertono un sistema in pochi comandi. Per un’applicazione PHP, però, i problemi stanno nei dettagli: la versione di PHP che cambia senza preavviso, i repository di terze parti, le estensioni compilate a parte, SELinux. In questo articolo vediamo quali percorsi esistono a seconda del sistema di partenza, cosa succede a PHP in ciascuno, come preparare l’inventario e quali verifiche fare dopo.
Il sistema di partenza decide il percorso
La distinzione più importante è tra due tipi di migrazione. La conversione resta sulla stessa versione principale, per esempio da CentOS Stream 8 a Rocky Linux 8: cambiano il marchio, le chiavi e i repository, mentre i pacchetti restano sostanzialmente gli stessi. Il cambio di versione principale, per esempio da CentOS 7 a una versione 8, 9 o 10, sostituisce invece tutto il software di sistema, PHP compreso.
Gli strumenti sono tre, tutti gratuiti e pubblicati dai progetti stessi:
- migrate2rocky: script di Rocky Linux che converte in Rocky un sistema 8 o 9 basato su CentOS, CentOS Stream, AlmaLinux, RHEL o Oracle Linux. Per i sistemi 9 si usa la variante
migrate2rocky9.sh; - almalinux-deploy: script di AlmaLinux che converte in AlmaLinux un sistema 8, 9 o 10 basato su CentOS 8, CentOS Stream, Rocky Linux, RHEL o Oracle Linux;
- ELevate: progetto di AlmaLinux basato su Leapp, lo strumento di Red Hat per gli aggiornamenti sul posto. Porta CentOS 7 a una versione 8, poi da 8 a 9 e da 9 a 10, una versione alla volta.
Da CentOS 7 non esiste una conversione diretta verso Rocky Linux o AlmaLinux 7, perché nessuno dei due progetti ha mai pubblicato una versione 7. Le strade sono l’aggiornamento sul posto con ELevate oppure un server nuovo.
Prima di tutto, l’inventario di PHP
Qualunque percorso tu scelga, la prima cosa da fare è registrare com’è configurato PHP oggi. Dopo la migrazione questo elenco serve a confrontare il prima e il dopo e a ricostruire quello che manca:
mkdir -p /root/inventario
# Versione, file ini caricati ed estensioni attive
php -v
php --ini
php -m | sort > /root/inventario/php-moduli.txt
# Pacchetti PHP con versione, release e fornitore
rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE} %{VENDOR}\n' | grep -i php | sort \
> /root/inventario/php-pacchetti.txt
# Repository attivi (su CentOS 7: yum repolist enabled)
dnf repolist --enabled
# Pool di PHP-FPM, di sistema e delle collezioni
ls /etc/php-fpm.d/ /etc/opt/rh/*/php-fpm.d/ /etc/opt/remi/*/php-fpm.d/ 2>/dev/null
# Attività pianificate che richiamano PHP
grep -rl php /etc/cron* /var/spool/cron 2>/dev/nullAll’inventario vanno aggiunti una copia del database, una snapshot completa del server e, se possibile, un ambiente di prova in cui eseguire la migrazione prima di farla in produzione. Tutte e tre le guide ufficiali lo raccomandano esplicitamente.
La conversione sulla stessa versione principale
Se parti da CentOS Linux 8, CentOS Stream 8 o 9, la conversione è il percorso più breve. CentOS Linux 8 è fermo alla 8.5 e i suoi repository sono in archivio: se dnf non risponde, va prima puntato su vault.centos.org, come abbiamo spiegato per CentOS 7. Poi bastano pochi comandi, da eseguire in una sessione screen o tmux per non perdere il lavoro se la connessione cade:
# Verso Rocky Linux (sistemi 8; per i sistemi 9 usa migrate2rocky9.sh)
curl -O https://raw.githubusercontent.com/rocky-linux/rocky-tools/main/migrate2rocky/migrate2rocky.sh
chmod u+x migrate2rocky.sh
./migrate2rocky.sh -r
# Verso AlmaLinux (sistemi 8, 9 e 10)
curl -O https://raw.githubusercontent.com/AlmaLinux/almalinux-deploy/master/almalinux-deploy.sh
sudo bash almalinux-deploy.sh
# Da CentOS Stream, che può avere pacchetti più recenti di AlmaLinux:
sudo bash almalinux-deploy.sh -dIn questo percorso PHP resta alla stessa versione. Il flusso del modulo php attivo resta attivo e i pacchetti vengono sostituiti con quelli ricostruiti dalla nuova distribuzione. Anche i repository di terze parti per la stessa versione principale, come Remi, continuano a funzionare: il pacchetto remi-release-8 vale per tutte le distribuzioni 8. Dopo il riavvio controlla con dnf module list --enabled php che il flusso sia quello di prima e confronta l’elenco delle estensioni.
Il salto di versione con ELevate
Da CentOS 7 ELevate permette di aggiornare il sistema sul posto. La guida rapida documenta il passaggio verso AlmaLinux 8; per arrivare alla 10 servono tre passaggi successivi, da 7 a 8, da 8 a 9 e da 9 a 10. Chi preferisce Rocky Linux può, una volta su AlmaLinux 8, usare migrate2rocky, che accetta AlmaLinux come sistema di partenza. I comandi principali per il primo passaggio sono questi:
# I repository di CentOS 7 sono offline: la guida usa il mirror di AlmaLinux
sudo curl -o /etc/yum.repos.d/CentOS-Base.repo https://el7.repo.almalinux.org/centos/CentOS-Base.repo
sudo yum update -y && sudo reboot
# Repository di ELevate, Leapp e dati per la destinazione AlmaLinux
sudo yum install -y http://repo.almalinux.org/elevate/elevate-release-latest-el$(rpm --eval %rhel).noarch.rpm
sudo yum install -y leapp-upgrade leapp-data-almalinux
# Analisi preliminare: non installa nulla, scrive il rapporto
sudo leapp preupgrade
less /var/log/leapp/leapp-report.txt
# Risolti gli impedimenti del rapporto, l'aggiornamento vero e proprio
sudo leapp upgrade
sudo rebootPer PHP questo percorso cambia molto. Il PHP 5.4 di CentOS 7 viene sostituito da quello della nuova versione, con un salto di diverse versioni del linguaggio. Le Software Collections rh-php non hanno un equivalente su EL 8. I pacchetti di Remi per EL 7 non fanno parte dei repository di terze parti che ELevate dichiara di gestire, e vanno rimossi prima e reinstallati dopo con il repository per la nuova versione. Le estensioni PECL compilate a mano vanno ricompilate. In pratica l’applicazione si ritrova su un PHP diverso nel momento stesso del riavvio.
Se dopo l’aggiornamento vuoi tornare alla stessa versione di PHP che usavi con Remi, la procedura è quella di una nuova installazione: rimuovi i vecchi pacchetti .el7.remi rimasti, installa EPEL e il pacchetto remi-release per la nuova versione del sistema, poi abilita il flusso corrispondente, per esempio php:remi-7.4, e reinstalla le estensioni dell’inventario. Prima di farlo, controlla che quella versione esista ancora per la nuova versione del sistema: Remi pubblica per ogni versione di Enterprise Linux un insieme di rami di PHP, e i più vecchi possono mancare.
Per PHP, spesso conviene un server nuovo
Quando la versione di PHP deve cambiare comunque, l’aggiornamento sul posto perde il suo vantaggio principale. Un server nuovo, installato da zero con Rocky Linux o AlmaLinux 9 o 10, permette di scegliere con calma la versione di PHP, da AppStream o da Remi, di adeguare l’applicazione su una copia, di provarla con i dati reali e di passare in produzione cambiando il DNS o il bilanciatore. Qualche giorno prima del passaggio conviene abbassare il TTL dei record DNS, così il cambio di indirizzo si propaga in pochi minuti. Il vecchio server resta acceso e pronto come piano di ritorno, e i dati scritti nel frattempo, come ordini e utenti registrati, vanno sincronizzati con una procedura provata in anticipo. Abbiamo descritto le versioni disponibili e le loro scadenze nell’articolo su PHP su RHEL 8, 9 e 10.
Se l’applicazione non è ancora pronta per la versione di PHP disponibile sul nuovo sistema, una strada è installare sul nuovo server la stessa versione usata oggi, per esempio una collezione di Remi, e fare il salto di PHP in un secondo momento. Le versioni fuori supporto richiedono però le stesse attenzioni di sempre: la combinazione di pacchetti ricostruiti con le patch e di una migrazione applicativa pianificata è quella che descriviamo nell’articolo su Remi e le Software Collections.
Le verifiche dopo la migrazione
Che si tratti di conversione, aggiornamento sul posto o server nuovo, prima di dichiarare chiuso il lavoro conviene controllare questi punti:
- versione di PHP ed elenco delle estensioni, confrontati con l’inventario;
- configurazione di PHP-FPM verificata con
php-fpm -te servizi avviati al boot; - attività pianificate, invio di email, connessioni verso API esterne e database;
- permessi di scrittura nelle cartelle di upload e di cache;
- SELinux: su Rocky Linux e AlmaLinux è attivo per impostazione predefinita, e se sul vecchio server era disattivato i problemi emergono subito;
- log di PHP e del server web nelle prime ore di traffico reale.
Con SELinux attivo i sintomi tipici sono upload che falliscono, chiamate HTTP verso l’esterno bloccate e connessioni al database rifiutate. Conviene lasciarlo attivo e assegnare i contesti e i permessi giusti:
# Cartelle in cui PHP deve scrivere (upload, cache)
semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/sito/uploads(/.*)?'
restorecon -Rv /var/www/sito/uploads
# PHP-FPM che chiama API esterne o un database su un altro server
setsebool -P httpd_can_network_connect on
setsebool -P httpd_can_network_connect_db on
# Invio di email dall'applicazione
setsebool -P httpd_can_sendmail on
# Ultimi accessi negati da SELinux
ausearch -m avc -ts recentSe preferisci farti accompagnare nella scelta del percorso e nella migrazione dell’applicazione, trovi i sistemi su cui lavoriamo nella sezione dedicata ai sistemi supportati.
Per concludere
Migrare da CentOS a Rocky Linux o AlmaLinux è semplice quando si resta sulla stessa versione principale: migrate2rocky e almalinux-deploy convertono un sistema 8 o 9 lasciando invariati PHP, i flussi dei moduli e i repository di terze parti. Da CentOS 7 la situazione cambia: ELevate aggiorna il sistema sul posto una versione alla volta, ma PHP cambia insieme al sistema, le collezioni rh-php spariscono e i pacchetti di Remi vanno reinstallati. Per questo, quando anche PHP deve cambiare, un server nuovo con Rocky Linux o AlmaLinux 9 o 10 è spesso la strada più sicura, con il vecchio server come piano di ritorno. In ogni caso servono un inventario di PHP prima di iniziare, una snapshot, un ambiente di prova e un controllo accurato dopo, SELinux compreso.
