Il 30 giugno 2024 CentOS 7 ha smesso di ricevere aggiornamenti. Da quel giorno il sistema non riceve più patch, i mirror ufficiali sono stati spenti e yum, senza modifiche alla configurazione, non riesce nemmeno a scaricare l’elenco dei pacchetti. Eppure nell’autunno 2026 molti server CentOS 7 sono ancora in produzione, spesso con siti, negozi online e gestionali in PHP che nessuno ha il tempo di portare su un sistema nuovo nel giro di poche settimane.
In questo articolo vediamo cosa è cambiato davvero dopo la fine del supporto, da dove arriva il PHP installato su un CentOS 7 e chi lo aggiorna oggi, come rimettere il server in condizione di essere gestito e come proteggere PHP con il backport delle patch mentre si prepara l’uscita. Chiudiamo con le strade per lasciare CentOS 7 senza perdere il controllo dell’applicazione.
Cosa è cambiato il 30 giugno 2024
CentOS Linux 7 è uscito nel 2014 ed è stato per dieci anni la base di una quota enorme di server web. Il progetto CentOS aveva annunciato con largo anticipo la data di fine, e alla scadenza sono successe tre cose:
- niente più aggiornamenti: nessuna correzione di sicurezza o di bug per il kernel, le librerie e i pacchetti applicativi, PHP compreso;
- pacchetti in archivio: tutto il contenuto è stato spostato su
vault.centos.org, dove resta disponibile ma congelato all’ultima versione, la 7.9.2009; - mirror spenti: il servizio
mirrorlist.centos.org, usato dalla configurazione predefinita di yum, non risponde più, e qualsiasi installazione fallisce con un errore di risoluzione del nome.
Red Hat Enterprise Linux 7, da cui CentOS 7 è ricostruito, ha invece un supporto a pagamento. Red Hat ha annunciato l’Extended Life Cycle Support per RHEL 7.9 fino al 31 maggio 2029, con le correzioni di sicurezza classificate come critiche o importanti. Questo supporto vale solo per i sistemi con un abbonamento RHEL: un CentOS 7 non lo riceve, a meno di convertirlo prima in RHEL con lo strumento Convert2RHEL di Red Hat.
Da dove arriva il PHP del tuo CentOS 7
Il PHP incluso in CentOS 7 è la versione 5.4.16, fuori supporto dal 2015 per il progetto PHP. Quasi nessuna applicazione recente funziona su quella versione, per questo sui server CentOS 7 PHP arriva quasi sempre da un’altra fonte: le Software Collections di Red Hat distribuite dal progetto CentOS, il repository di Remi Collet con i pacchetti base o con le sue collezioni installabili in parallelo, oppure repository come IUS e Webtatic, oggi chiusi.
Il ciclo di vita delle Software Collections di Red Hat per RHEL 7 indica giugno 2024 come fine del supporto per PHP 7.3, l’ultima versione distribuita in questa forma: le versioni precedenti erano già scadute da anni. Remi Collet ha chiuso i repository per Enterprise Linux 7, e gli ultimi pacchetti, come PHP 8.3.8, risalgono a giugno 2024. Il risultato è lo stesso per tutte le origini: il pacchetto installato oggi è l’ultimo che riceverai.
Per sapere quale caso è il tuo, bastano pochi comandi. Funzionano anche se i repository non sono raggiungibili, perché leggono solo il database dei pacchetti installati:
# Pacchetti PHP installati e repository di provenienza (terza colonna)
yum --disablerepo='*' list installed 'php*' 'rh-php*'
# Chi ha costruito il pacchetto: CentOS, Remi o altri
rpm -qi php-cli | grep -E '^(Version|Release|Vendor|Packager|Build Date)'
# Collezioni installate in parallelo (Red Hat e Remi)
ls -d /opt/rh/rh-php* /opt/remi/php* 2>/dev/null
# Servizi PHP-FPM in esecuzione
systemctl list-units --type=service | grep -i fpmUn suffisso .el7.remi nel campo Release indica i pacchetti di Remi, un nome che inizia con rh-php le Software Collections. Annota anche i servizi FPM attivi: sullo stesso server possono girare due o tre versioni di PHP, una per ogni sito.
Primo passo: rimettere il server in condizione di essere gestito
Un server su cui yum non funziona è un server su cui non puoi installare uno strumento di diagnosi, una dipendenza o un pacchetto corretto. Prima di qualsiasi altra cosa conviene puntare i repository di CentOS all’archivio, che contiene l’ultima versione di ogni pacchetto:
# Copia di sicurezza della configurazione attuale
cp -a /etc/yum.repos.d /root/yum.repos.d.bak
# Disattiva mirrorlist e usa l'archivio vault.centos.org
sed -i -e 's|^mirrorlist=|#mirrorlist=|' \
-e 's|^#baseurl=http://mirror.centos.org|baseurl=https://vault.centos.org|' \
/etc/yum.repos.d/CentOS-*.repo
# Ricostruisce la cache e verifica che i repository rispondano
yum clean all && yum makecache && yum repolistLo stesso comando aggiorna anche i file delle Software Collections, se il loro nome inizia con CentOS-, come CentOS-SCLo-scl-rh.repo. Il vault non porta nuove correzioni: rende solo di nuovo possibile installare quello che c’era. Per lo stesso motivo conviene tenere una copia locale dei pacchetti PHP in uso, perché un archivio esterno può cambiare o sparire, e ricostruire il server senza quei file sarebbe molto più difficile:
# Scarica i pacchetti PHP installati in una cartella locale (richiede yum-utils)
mkdir -p /srv/rpm-locali && cd /srv/rpm-locali
yumdownloader $(rpm -qa --qf '%{NAME}\n' | grep -E '^(php|rh-php)' | sort -u)Proteggere PHP con il backport delle patch
Ogni vulnerabilità di PHP pubblicata dopo l’ultimo pacchetto resta aperta sul server. Il backport delle patch serve a chiuderla senza cambiare versione: si prende il pacchetto sorgente esatto da cui è nato quello installato, si adattano al suo codice le correzioni scritte per i rami supportati e si ricostruisce il pacchetto.
Il punto chiave è che il nuovo pacchetto ha lo stesso nome, gli stessi percorsi e le stesse estensioni del precedente, con un numero di release più alto. Per il server è un normale aggiornamento: la configurazione di PHP-FPM, i pool, il php.ini e l’applicazione restano come sono. Nel nostro servizio il lavoro segue sempre gli stessi passaggi:
- analisi delle CVE pubblicate dopo l’ultimo pacchetto e di quali riguardano davvero la tua configurazione, cioè SAPI, estensioni caricate ed esposizione;
- ricostruzione del pacchetto RPM a partire da quello in uso, che sia della distribuzione, delle Software Collections o di Remi;
- test in un ambiente di prova con l’applicazione reale;
- rilascio con Ansible e un piano di rollback pronto.
Per un intervento d’urgenza su una singola CVE il nostro obiettivo è di 24 ore dall’analisi al rilascio. Su un ramo molto vecchio il lavoro accumulato può essere ampio: sul solo PHP 5.6.40, l’ultima versione ufficiale del ramo, il nostro pacchetto corregge 55 CVE, 11 delle quali aggiunte da noi con backport dedicati.
Il rollback, su CentOS 7, si appoggia allo storico delle transazioni di yum. Il changelog del pacchetto ricostruito elenca le CVE corrette, così chi fa un audit può verificarle:
# CVE corrette nel pacchetto installato
rpm -q --changelog php-fpm | grep -i cve | head -n 20
# Storico delle transazioni che hanno toccato PHP-FPM
yum history list php-fpm
# Annulla una transazione e torna ai pacchetti precedenti
yum history undo <ID>Cosa il backport di PHP non copre
Il backport di PHP corregge l’interprete e le sue estensioni. Il kernel, OpenSSL, la glibc, il server web e il resto del sistema operativo restano alle ultime versioni del 2024, senza correzioni. Per questo il backport non rende CentOS 7 un sistema supportato: riduce il rischio sul componente più esposto, quello che riceve ogni richiesta dal web, e dà il tempo di preparare il passaggio a un sistema nuovo.
Le misure da affiancare
Su un sistema operativo fermo, qualche misura di contorno riduce molto la superficie di attacco. Nessuna sostituisce le correzioni; insieme rendono più difficile sfruttare le falle che restano aperte:
- disattivare le estensioni PHP che l’applicazione non usa, partendo dall’elenco di
php -m; - far ascoltare PHP-FPM su un socket locale o solo su 127.0.0.1, mai su un indirizzo raggiungibile dall’esterno;
- limitare per indirizzo IP le aree amministrative del CMS e gli strumenti come phpMyAdmin;
- mettere davanti al server un reverse proxy aggiornato, su un sistema supportato, che gestisca TLS e filtri le richieste;
- limitare le connessioni in uscita del server a quelle necessarie, così una compromissione ha meno strade per scaricare altro codice;
- tenere backup recenti e verificati, conservati fuori dal server.
Le alternative per restare
Il backport delle patch non è l’unico modo per comprare tempo. Le alternative realistiche sono due, e vanno valutate guardando a quale PHP usi davvero:
- convertire il server in RHEL 7 e acquistare l’ELS: copre il sistema operativo e i pacchetti di RHEL 7.9 inclusi nel programma, quindi il PHP 5.4 di base. Se il sito usa PHP da Remi o da una collezione, quel PHP resta comunque senza correzioni;
- un supporto esteso di terze parti: alcuni fornitori pubblicano aggiornamenti a pagamento per CentOS 7. Prima di scegliere, verifica che il perimetro includa la versione e l’origine del PHP che hai installato, oltre al sistema di base.
In tutti i casi resta valido lo stesso schema in tre fasi: rendere il server gestibile, proteggere PHP e poi uscire.
Pianificare l’uscita da CentOS 7
La destinazione naturale è un sistema della stessa famiglia con un lungo supporto davanti: Rocky Linux, AlmaLinux o RHEL, in versione 9 o 10. Rocky Linux e AlmaLinux dichiarano il supporto di sicurezza fino al 31 maggio 2032 per la versione 9 e fino al 31 maggio 2035 per la versione 10. Le strade per arrivarci sono due:
- un nuovo server in parallelo, installato da zero con la versione di PHP più recente compatibile con l’applicazione. È la strada più pulita: il vecchio server resta acceso fino a quando il nuovo non ha superato i test, e il passaggio si fa cambiando il DNS o il bilanciatore;
- l’aggiornamento sul posto con ELevate, il progetto di AlmaLinux basato su Leapp, che porta CentOS 7 a EL 8 e poi, con passaggi successivi, a EL 9 e 10. Ogni passaggio cambia la versione di PHP e richiede di rivedere i repository di terze parti.
In entrambi i casi il lavoro più delicato riguarda l’applicazione: un codice nato per PHP 5.6 o 7.x va adeguato a PHP 8, con librerie, temi, plugin e moduli da aggiornare. Abbiamo descritto strumenti e controlli nell’articolo su come migrare da CentOS a Rocky Linux o AlmaLinux. Se ti serve un aiuto per l’analisi del tuo server, puoi contattarci indicando versione di PHP e origine dei pacchetti.
In breve
Dal 30 giugno 2024 CentOS 7 non riceve aggiornamenti e i suoi repository sono in archivio su vault.centos.org. Il PHP installato, che venga dalla distribuzione, dalle Software Collections o da Remi, è fermo all’ultimo pacchetto del 2024, e ogni nuova CVE resta aperta. Il primo passo è rendere di nuovo gestibile il server, puntando i repository all’archivio e salvando in locale i pacchetti in uso. Il secondo è proteggere PHP con il backport delle patch, ricostruendo gli stessi pacchetti con le correzioni, testati con l’applicazione reale e rilasciati con un piano di rollback, insieme a qualche mitigazione intorno. Il terzo è uscire da CentOS 7 verso una versione 9 o 10 di Rocky Linux, AlmaLinux o RHEL, con l’applicazione portata su PHP 8. Il backport è il ponte, la migrazione è la meta.
