PHP su SUSE Linux Enterprise: pacchetti RPM, zypper e gestione delle patch

SUSE Linux Enterprise è meno diffusa di Debian o RHEL sui server web, ma la si incontra spesso in aziende che l’hanno scelta per SAP o per altri applicativi gestionali e poi l’hanno usata anche per il portale, l’intranet o l’e-commerce. In questi contesti PHP è raramente il centro dell’attenzione: arriva da un modulo del sistema, viene aggiornato con le patch mensili insieme a tutto il resto, e nessuno si chiede fino a quando quelle patch continueranno ad arrivare.

In questo articolo vediamo dove si trova PHP su SUSE Linux Enterprise Server, quale versione porta ogni service pack, come funzionano il supporto generale e LTSS per i pacchetti PHP, come si cercano e si installano le patch di sicurezza con zypper e cosa fare quando una service pack o un prodotto escono dal supporto.

Dove si trova PHP su SUSE

Su SLES il sistema di base è volutamente ridotto, e i pacchetti applicativi sono organizzati in moduli da attivare a parte. PHP si trova nel modulo Web and Scripting, insieme ad Apache e ad altri linguaggi. Le versioni di PHP sostituite da una più recente passano nel modulo Legacy. I nomi dei pacchetti indicano la versione principale: php5, php7 e php74 su SLES 12, php7 e php8 su SLES 15, con i relativi php8-fpm, apache2-mod_php8 e le estensioni.

Il nome del pacchetto non basta per sapere quale ramo è installato: php8 è PHP 8.0 su SLES 15 SP4 e SP5, 8.2 su SP6 e 8.4 su SP7. Esiste poi SUSE Package Hub, con pacchetti mantenuti dalla comunità e non coperti dal supporto commerciale di SUSE: se il PHP in uso arriva da lì, valgono altre regole.

# Prodotto e service pack
cat /etc/os-release

# Moduli registrati e stato dell’abbonamento
sudo SUSEConnect --status-text
sudo SUSEConnect --list-extensions

# Pacchetti PHP installati, con versione e fornitore
rpm -qa 'php*' | sort
rpm -qi php8 | grep -E '^(Version|Release|Vendor)'

# Versioni disponibili nei repository e quella installata
zypper search -s php8

Quale PHP in ogni versione di SLES

Le note di rilascio di SLES 15 SP7 riassumono la regola: ogni service pack porta come predefinito un nuovo ramo di PHP, mentre gli aggiornamenti dentro lo stesso ramo, per esempio da 8.4.x a 8.4.y, escono quando servono per correggere vulnerabilità e bug.

Prodotto	PHP	Fine del supporto generale	Fine di LTSS
SLES 12 SP5	5.5, 7.0 e 7.4 nel modulo Web and Scripting	31 ottobre 2024	il modulo non è coperto
SLES 15 SP0 e SP1	7.2	conclusa	conclusa
SLES 15 SP2 e SP3	7.4	conclusa	conclusa
SLES 15 SP4	8.0	31 dicembre 2023	31 dicembre 2026
SLES 15 SP5	8.0	31 dicembre 2024	31 dicembre 2027
SLES 15 SP6	8.2	31 dicembre 2025	31 dicembre 2028
SLES 15 SP7	8.4	31 luglio 2031	31 luglio 2034
SLES 16.0	8.4	30 novembre 2027	30 novembre 2030

Supporto generale e LTSS: cosa vale per PHP

Ogni service pack di SLES 15 ha un periodo di supporto generale, che di norma si chiude qualche mese dopo l’uscita della service pack successiva. Dopo quella data le patch arrivano solo a chi ha un abbonamento aggiuntivo LTSS, il Long Term Service Pack Support. Gli avvisi di sicurezza di SUSE per php8 pubblicati nel 2026 elencano tra i prodotti interessati anche SLES 15 SP4 LTSS: chi è rimasto su una service pack precedente con LTSS riceve quindi ancora le correzioni per il proprio PHP.

SLES 12 è diverso, ed è il caso più delicato. Il supporto generale di SLES 12 SP5 si è chiuso il 31 ottobre 2024 e il prodotto prosegue con LTSS, ma la pagina del ciclo di vita di SUSE indica che il modulo Web and Scripting di SLES 12 non ha copertura LTSS. In pratica un server SLES 12 con LTSS attivo continua a ricevere patch per il kernel e il sistema di base, ma non per PHP 5.5, 7.0 o 7.4. È una situazione facile da fraintendere, perché l’abbonamento è in regola e zypper patch continua a installare aggiornamenti.

Patch e pacchetti: come ragiona zypper

Su SUSE gli aggiornamenti ufficiali sono distribuiti come patch: oggetti con un nome, una categoria (security, recommended, optional), una gravità e l’elenco dei pacchetti RPM da aggiornare. Ogni patch fa riferimento agli identificativi CVE che corregge e ai bug interni di SUSE. Questo rende zypper molto comodo per rispondere a una domanda precisa: la vulnerabilità appena pubblicata è già corretta su questo server?

# Aggiorna i metadati dei repository
sudo zypper refresh

# Patch di sicurezza applicabili al sistema
zypper list-patches --category security

# Patch che correggono una CVE precisa (anche con --all per vedere quelle già installate)
zypper list-patches --cve=CVE-AAAA-NNNNN

# Dettagli di una patch: pacchetti, gravità, riferimenti
zypper info -t patch NOME-DELLA-PATCH

# Installa solo le patch per quella CVE
sudo zypper patch --cve=CVE-AAAA-NNNNN

# Processi che usano ancora file sostituiti, da riavviare
sudo zypper ps -s
# Nome del servizio FPM: dipende dal pacchetto installato, verificalo prima
systemctl list-unit-files 'php*fpm*'
sudo systemctl restart php-fpm   # sostituisci con il nome trovato sopra

# Conferma nel changelog del pacchetto installato
rpm -q --changelog php8 | grep -m 10 -i cve

Il riavvio è un passaggio che si dimentica spesso. Dopo l’aggiornamento i file sul disco sono quelli nuovi, ma i processi di PHP-FPM e Apache già in esecuzione continuano a usare il codice vecchio finché non vengono riavviati. zypper ps mostra proprio questi processi.

Proteggere pacchetti PHP ricostruiti

Quando il PHP di SUSE non riceve più correzioni, come per i pacchetti del modulo Web and Scripting su SLES 12, una delle strade è installare pacchetti RPM ricostruiti con le patch di sicurezza. Su SUSE ci sono due meccanismi che aiutano a mantenerli al loro posto.

• Fedeltà al fornitore: per default zypper non sostituisce un pacchetto installato con una versione più recente di un fornitore diverso, cioè con un campo Vendor diverso nell’intestazione RPM. Un pacchetto ricostruito con un proprio Vendor non viene quindi rimpiazzato da un aggiornamento di SUSE, salvo opzioni esplicite come --allow-vendor-change o gruppi di fornitori equivalenti definiti in /etc/zypp/vendors.d/;
• blocchi: zypper addlock impedisce qualsiasi modifica ai pacchetti indicati, anche con espressioni come 'php7*'. È utile durante una finestra di collaudo, ma va tolto quando si vuole installare una nuova versione.

# Blocca i pacchetti PHP 7 durante il collaudo
sudo zypper addlock 'php7*' 'apache2-mod_php7'
zypper locks

# Sblocca quando è il momento di aggiornare
sudo zypper removelock 'php7*' 'apache2-mod_php7'

# Fornitore dei pacchetti installati, per capire chi li aggiornerà
rpm -qa --queryformat '%{NAME} %{VERSION}-%{RELEASE} %{VENDOR}\n' 'php*' | sort

È il modo in cui lavoriamo anche noi con il backport delle patch: partiamo dai pacchetti RPM in uso, aggiungiamo le correzioni delle CVE adattate al ramo, ricostruiamo, proviamo con l’applicazione reale e installiamo con Ansible, con un piano di rollback.

Quando la service pack esce dal supporto

Su SLES 15 la scadenza della service pack è un evento prevedibile, e le strade sono note:

1. passare alla service pack successiva con zypper migration, sapendo che cambia anche il ramo di PHP predefinito: da SP5 a SP6 si passa da PHP 8.0 a 8.2, da SP6 a SP7 da 8.2 a 8.4;
2. restare sulla service pack con LTSS, per avere tempo di preparare l’applicazione al nuovo ramo, entro le date indicate da SUSE;
3. usare pacchetti corretti quando né la service pack né LTSS coprono il PHP che serve, come su SLES 12;
4. migrare l’applicazione a un ramo di PHP supportato, che resta la meta in tutti i casi.

Il primo punto è quello che sorprende più spesso. Su altre distribuzioni l’aggiornamento minore del sistema non cambia la versione di PHP, su SLES 15 sì. Un’applicazione che funziona con PHP 8.0 non è detto che funzioni con 8.2 senza modifiche: prima della migrazione della service pack serve una verifica del codice, come per qualunque migrazione verso PHP 8.

Una lista di controllo per i server SUSE

• prodotto e service pack di ogni server, con la data di fine del supporto generale e di LTSS;
• moduli attivi e abbonamenti, verificati con SUSEConnect --status-text;
• origine dei pacchetti PHP: modulo Web and Scripting, modulo Legacy, Package Hub o pacchetti ricostruiti, riconoscibili dal campo Vendor;
• patch di sicurezza in sospeso, con zypper list-patches --category security;
• per SLES 12, conferma che il PHP in uso non riceve più correzioni anche con LTSS attivo;
• data prevista per il passaggio alla service pack o al prodotto successivo, con il ramo di PHP che ne deriva.

In breve

Su SUSE Linux Enterprise PHP si trova nel modulo Web and Scripting, e su SLES 15 ogni service pack porta un nuovo ramo predefinito: 7.2, 7.4, 8.0, 8.2 e infine 8.4 con SP7, la stessa versione di SLES 16.0. Le patch arrivano come oggetti con categoria e riferimenti CVE, e zypper permette di cercarle e installarle per numero di vulnerabilità, ricordando di riavviare i servizi con zypper ps. Dopo il supporto generale le correzioni continuano con LTSS sulle service pack di SLES 15, mentre su SLES 12 il modulo Web and Scripting non è coperto da LTSS e il suo PHP è senza patch. In quei casi servono pacchetti ricostruiti, protetti dalla fedeltà al fornitore di zypper, insieme a un piano di migrazione verso un ramo supportato.