1 25/10/2026 10 min

Su Amazon Linux 2 PHP 7.4 non è una scelta “di default”: va installato in modo esplicito, tenendo conto del repository usato, dei moduli richiesti dall’applicazione e del fatto che la versione 7.4 è fuori supporto upstream. Questo significa che l’obiettivo non è solo “far partire php”, ma mettere in piedi un’installazione ripetibile, verificabile e con un piano di rollback chiaro.

La strada più pratica è usare il repository Remi, che su Amazon Linux 2 resta il riferimento quando serve una versione specifica di PHP e un set di pacchetti coerente con l’ecosistema LAMP o LEMP. Prima di toccare il sistema, conviene confermare due cose: che la macchina sia davvero Amazon Linux 2 e che non esista già una versione di PHP installata da un altro repository, perché il mix di sorgenti è la causa più comune di conflitti nei pacchetti.

1) Verifica del sistema e fotografia iniziale

Parti dal controllo del sistema e dello stato attuale dei pacchetti. Questa fase serve a evitare sorprese quando yum risolve le dipendenze e a capire se stai facendo un cambio controllato o una prima installazione.

Comandi utili:

cat /etc/system-release
rpm -qa | grep -E '^php|remi|epel'
yum repolist enabled

Se il sistema risponde con una stringa tipo Amazon Linux release 2, sei nel contesto giusto. Se trovi già pacchetti PHP installati, annota versioni e origine del repository; in caso di problemi, questa è la base per capire se rimuovere, aggiornare o affiancare i pacchetti esistenti. Se non hai visibilità sul repository da cui provengono i pacchetti, puoi chiuderla con:

rpm -qi php-cli | grep -E 'Name|Version|Vendor|From repo'

Se il comando non mostra il repository di origine, usa rpm -q --qf o verifica direttamente con yum info. Il punto non è la forma del comando, ma avere un dato certo prima di cambiare versione.

2) Abilitare Remi in modo pulito

Su Amazon Linux 2 Remi non basta “averlo presente”: va installato il pacchetto di release e poi abilitato il ramo corretto. Per PHP 7.4 il riferimento è il ramo remi-7.4. Prima però conviene aggiornare i metadati dei repository e installare gli strumenti base per gestire i repo esterni.

sudo yum update -y
sudo yum install -y yum-utils
sudo amazon-linux-extras install epel -y
sudo yum install -y https://rpms.remirepo.net/enterprise/remi-release-7.rpm

Il passaggio su EPEL è spesso necessario perché diversi moduli e dipendenze transitano da lì. Se il pacchetto remi-release non si installa, verifica che la macchina abbia accesso in uscita a Internet o ai mirror configurati; in ambienti chiusi il problema non è PHP, ma la connettività verso i repository.

Ora disabilita eventuali moduli PHP già attivi e abilita il ramo 7.4. Questo è il punto in cui molti operatori sbagliano lasciando attivi più stream contemporaneamente.

sudo yum module list php
sudo yum module reset php -y
sudo yum module enable php:remi-7.4 -y

Se il comando yum module list php non mostra un modulo PHP gestito dal sistema, non è un errore: su alcune macchine la base è minimale. In quel caso il reset può non fare nulla di utile, ma non rompe il flusso. La verifica vera è la disponibilità del ramo remi-7.4.

3) Installazione del runtime PHP 7.4

Una volta abilitato il modulo, installa il runtime e i moduli più comuni. La scelta dei pacchetti dipende dal tipo di applicazione, ma per un sito PHP classico conviene partire da un set essenziale e aggiungere solo ciò che serve davvero.

sudo yum install -y php php-cli php-common php-fpm php-opcache php-mysqlnd php-xml php-mbstring php-json php-gd php-pecl-zip

Se usi Apache con mod_php, il pacchetto php-fpm non è obbligatorio, ma resta spesso la scelta migliore per separare il web server dal motore PHP e controllare meglio pool, permessi e tuning. Se usi Nginx, php-fpm è praticamente la strada standard.

Per verificare la versione installata:

php -v
rpm -qa | grep '^php'

L’output atteso deve riportare PHP 7.4.x. Se vedi una versione diversa, significa che il sistema sta pescando da un repository non coerente o che il modulo non è stato realmente abilitato. In quel caso non forzare subito reinstallazioni: prima controlla la lista dei repository attivi e le priorità.

4) Configurare php-fpm per Apache o Nginx

Installare PHP non basta: serve anche il servizio che esegue gli script. Su Amazon Linux 2 il servizio si gestisce con systemd e il file di configurazione principale è sotto /etc/php-fpm.d/. Il comportamento corretto cambia a seconda del web server.

Per avviare e abilitare php-fpm:

sudo systemctl enable php-fpm
sudo systemctl start php-fpm
sudo systemctl status php-fpm --no-pager

Se il servizio non parte, il primo controllo è il log di systemd:

sudo journalctl -u php-fpm -xe --no-pager

Per Nginx, il socket o la porta ascoltata da php-fpm devono combaciare con la configurazione del virtual host. La configurazione predefinita usa spesso un socket Unix, ma in alcuni casi si preferisce una porta TCP locale. Controlla il file pool, di solito /etc/php-fpm.d/www.conf, e verifica i parametri listen, user e group.

Esempio di verifica del socket:

grep -E '^(listen|user|group) =' /etc/php-fpm.d/www.conf

Se il socket non è coerente con il web server, il sintomo tipico è un 502 Bad Gateway lato Nginx oppure una pagina vuota con errori nel log di Apache. In questo caso il problema non è PHP in sé, ma il collegamento tra web server e process manager.

5) Apache: modulo o proxy verso php-fpm

Con Apache hai due strade: caricare PHP tramite modulo oppure passare da php-fpm. La seconda è generalmente più pulita, soprattutto se vuoi separare responsabilità e gestire più siti con pool distinti. Su Amazon Linux 2, se il tuo stack usa Apache, verifica che il servizio sia attivo e che la configurazione del virtual host punti correttamente ai file PHP.

sudo systemctl status httpd --no-pager
sudo apachectl -M | grep -E 'proxy_fcgi|php'

Se usi php-fpm, il modulo proxy_fcgi deve essere disponibile. Se invece trovi il modulo PHP caricato direttamente in Apache, stai usando un percorso diverso e devi evitare di introdurre un secondo meccanismo senza averlo pianificato. Mischiare mod_php e php-fpm nello stesso sito è un classico modo per complicarsi la vita senza vantaggi immediati.

Un test minimo, senza toccare l’applicazione, è creare un file di prova nella document root:

<?php phpinfo();

Salvalo come /var/www/html/info.php, aprilo dal browser e verifica che la pagina mostri la versione 7.4. Non lasciare questo file esposto: serve solo per il test iniziale e poi va rimosso.

6) Nginx: upstream PHP e tuning minimo

Con Nginx il controllo è più esplicito: il server web inoltra le richieste PHP al socket o alla porta di php-fpm. Il file di configurazione del virtual host deve avere un blocco location ~ \.php$ corretto, senza ambiguità sul percorso dello script.

location ~ \.php$ { try_files $uri =404; fastcgi_pass unix:/run/php-fpm/www.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params;
}

La riga più delicata è SCRIPT_FILENAME: se punta male, PHP riceve un percorso errato e il risultato può andare da un 404 a un errore di esecuzione. Dopo ogni modifica, ricarica Nginx e verifica la sintassi prima del reload effettivo:

sudo nginx -t
sudo systemctl reload nginx

Se il test fallisce, non forzare il reload. Il vantaggio di nginx -t è proprio evitare un impatto inutile sul traffico in produzione.

7) Verifica dei moduli realmente caricati

Molti problemi arrivano non dall’installazione base, ma dall’assenza di un modulo richiesto dall’applicazione. Un CMS o un framework può partire con PHP 7.4 ma fallire subito se mancano mbstring, xml, zip o gd. La verifica va fatta lato runtime, non solo lato pacchetto installato.

php -m | sort
php -i | grep -E 'Loaded Configuration File|Scan this dir for additional .ini files'

Il primo comando ti dice quali estensioni sono effettivamente caricate. Il secondo ti mostra quale file php.ini è in uso e da quali directory vengono caricati gli snippet aggiuntivi. Questa informazione è fondamentale quando una modifica sembra “non prendere”, perché spesso il file editato non è quello letto dal runtime.

Se devi abilitare o disabilitare una singola estensione, controlla la directory degli .ini aggiuntivi, tipicamente sotto /etc/php.d/, e non fare editing casuale del php.ini principale se basta un file dedicato. È più pulito, più facile da versionare e più semplice da rollbackare.

8) Test di funzionalità e lettura degli errori

Un’installazione corretta non si misura solo con php -v. Il test vero è una richiesta HTTP che attraversi web server, PHP e, se presente, backend applicativo. Per questo conviene eseguire un controllo semplice ma realistico.

curl -I http://127.0.0.1/info.php
curl -s http://127.0.0.1/info.php | head

Se la risposta è 200 OK e il contenuto mostra la pagina di phpinfo(), il runtime è operativo. Se ottieni 502, guarda prima il log del web server e poi quello di php-fpm. Se ottieni 500, cerca errori PHP o permessi errati sulla document root.

I percorsi utili, a seconda dello stack, sono in genere:

  • /var/log/httpd/error_log per Apache
  • /var/log/nginx/error.log per Nginx
  • /var/log/php-fpm/error.log o il journal di systemd per php-fpm

Se i log non mostrano nulla di utile, alza temporaneamente il livello di dettaglio solo per il tempo necessario alla diagnosi e poi riportalo ai valori normali. L’obiettivo è avere evidenza, non lasciare il sistema in debug permanente.

9) Hardening minimo e manutenzione

Una volta installato PHP 7.4, il lavoro non è finito. Su un host esposto conviene ridurre la superficie d’attacco e mantenere il sistema gestibile. Il primo punto è non lasciare strumenti diagnostici aperti più del necessario, il secondo è controllare i permessi dei file dell’applicazione e il terzo è evitare di esporre informazioni sensibili nella risposta HTTP.

Alcuni controlli pratici:

php -i | grep expose_php
php -i | grep disable_functions

Se expose_php è attivo, valuta di disabilitarlo nel file di configurazione appropriato. Se l’applicazione non richiede funzioni specifiche, puoi anche restringere disable_functions, ma va fatto con criterio: un elenco troppo aggressivo rompe librerie e script legittimi. Qui serve una valutazione applicativa, non un copia-incolla generico.

Ricorda anche il tema ciclo di vita: PHP 7.4 è una versione legacy. Se lo stai installando per compatibilità con un’app esistente, la scelta corretta è pianificare già il passaggio a una versione supportata, testando prima il codice e le estensioni in staging. Installare 7.4 oggi può essere una necessità tecnica, ma non dovrebbe diventare un punto di arrivo.

10) Rollback rapido se qualcosa si rompe

Se dopo l’installazione il sito smette di rispondere, la prima mossa non è “rifare tutto”, ma tornare allo stato precedente in modo reversibile. Il rollback dipende da come eri partito: se hai sostituito una versione già presente, devi rimuovere i pacchetti nuovi e ripristinare il ramo precedente; se era una prima installazione, puoi disattivare il servizio e riportare il web server alla configurazione precedente.

sudo systemctl stop php-fpm
sudo yum remove -y php\*

Il comando di rimozione va usato con cautela, perché il pattern php* può essere ampio. Prima di eseguirlo, fai un elenco dei pacchetti che verrebbero rimossi con una simulazione o verifica manuale. Se hai bisogno di un rollback più sicuro, conserva un elenco dei pacchetti installati prima del change:

rpm -qa | grep '^php' > /root/php-packages.before.txt

Questa è la parte che evita i rollback improvvisati: sapere esattamente cosa era presente prima del cambio. In ambienti di produzione, la differenza tra un fix rapido e un incidente più grande è quasi sempre lì.

Se vuoi un’installazione stabile e facilmente gestibile, la regola pratica è semplice: repository coerenti, un solo stream PHP attivo, php-fpm verificato, log controllati e test HTTP finale. Il resto è solo rumore operativo.