1 26/04/2026 10 min

Base pulita su EL8: repository, PHP e strumenti necessari

Su AlmaLinux e Rocky Linux 8 la strada più lineare per Laravel è partire da una base aggiornata, attivare i repository giusti e installare un PHP compatibile con la versione del framework che vuoi usare. Il punto non è “far partire qualcosa”, ma evitare combinazioni fragili: PHP troppo vecchio, moduli mancanti, permessi sbagliati e web server configurato a metà. Se l’obiettivo è un deploy ripetibile, conviene trattare il sistema come un host applicativo e non come una macchina generica con PHP installato al volo.

Su EL8 il pacchetto PHP dei repository base spesso non basta per progetti moderni. In pratica conviene usare il modulo AppStream se la versione è adeguata, oppure un repository esterno controllato, mantenendo però chiaro cosa stai installando e perché. Per Laravel, la scelta reale dipende dalla versione del framework e dal set di estensioni richieste dal progetto.

Prima di toccare il sistema, verifica lo stato atteso: una macchina EL8 aggiornata, con rete funzionante, accesso root o sudo, e un web server già deciso tra Apache e Nginx. Lo stato osservato tipico è un host pulito o semi-configurato, con PHP assente o troppo vecchio e nessun Composer disponibile.

Pacchetti PHP consigliati e dipendenze per Laravel

Laravel non vive di solo PHP. In un’installazione reale servono estensioni precise per database, JSON, XML, mbstring, curl, zip e, spesso, opcache. Se manca anche solo un modulo critico, Composer può installare il progetto ma l’applicazione si romperà al primo bootstrap o durante una migrazione.

Un set tipico, da adattare alla versione di PHP disponibile sul tuo repository, comprende php, php-cli, php-fpm, php-mysqlnd, php-mbstring, php-xml, php-json, php-gd, php-curl, php-zip e php-opcache. Se prevedi code execution, queue worker o task pianificati, php-cli è obbligatorio; se usi Nginx, php-fpm non è opzionale.

Ecco un’installazione base con i tool necessari per scaricare e gestire dipendenze:

sudo dnf update -y
sudo dnf install -y dnf-utils unzip curl git policycoreutils-python-utils

Se il repository PHP non è già quello che ti serve, controlla prima cosa è disponibile nel sistema. Questo evita di installare pacchetti da fonti non coerenti con il resto dell’host.

dnf module list php
php -v

Se il modulo AppStream non offre una versione sufficiente per il progetto, la scelta pratica è usare un repository gestito con attenzione. In contesti standard su EL8 si trova spesso il repository Remi, ma la regola operativa resta la stessa: prima leggi la versione che stai per installare, poi allinei estensioni e runtime, infine blocchi la configurazione in modo ripetibile.

Installazione di PHP con estensioni Laravel-ready

Una volta deciso il canale, installa PHP e i moduli necessari in un colpo solo. Questo riduce il rischio di ritrovarsi con Composer che segnala requisiti mancanti dopo aver già creato directory e permessi. Il principio è semplice: prima runtime completo, poi progetto.

Con repository standard o allineato al tuo ambiente, il comando può assomigliare a questo:

sudo dnf install -y php php-cli php-fpm php-mysqlnd php-mbstring php-xml php-json php-gd php-curl php-zip php-opcache

Dopo l’installazione, controlla subito versione e moduli caricati. Non dare per scontato che il pacchetto installato sia il runtime effettivamente in uso da CLI e FPM: su sistemi con più repository o versioni residue, il binario e il pool FPM possono divergere.

php -v
php -m | sort
systemctl status php-fpm --no-pager

Se l’output di php -m non include almeno mbstring, xml, curl, zip e il modulo per il database che userai, fermati qui e correggi il set di pacchetti. È più economico sistemare subito che inseguire errori di Composer o schermate bianche in produzione.

Composer: installazione corretta e verifica della catena di trust

Laravel si installa e si aggiorna con Composer, quindi Composer non è un dettaglio secondario. Installarlo da script senza verifiche è comodo, ma in un host esposto è una pessima abitudine. La procedura corretta è scaricare l’installer, verificare l’hash pubblicato e poi posizionare il binario in un path standard.

Il flusso tipico è questo:

cd /tmp
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
EXPECTED_SIGNATURE=$(curl -s https://composer.github.io/installer.sig)
php -r "if (hash_file('sha384', 'composer-setup.php') === '$EXPECTED_SIGNATURE') { echo 'Installer verified'.PHP_EOL; } else { echo 'Installer corrupt'.PHP_EOL; unlink('composer-setup.php'); exit(1); }"
sudo php composer-setup.php --install-dir=/usr/local/bin --filename=composer
php -r "unlink('composer-setup.php');"
composer --version

Questo passaggio ha un blast radius basso, ma il rollback è banale: rimuovi il binario in /usr/local/bin/composer se hai bisogno di tornare indietro e ripeti l’installazione da una fonte diversa. Non salvare segreti o token in chiaro nei file di configurazione del sistema: Composer, eventuale repository privato e variabili d’ambiente vanno trattati con la stessa disciplina del resto dello stack.

Creazione del progetto Laravel e layout del filesystem

Per un’installazione nuova, crea una directory applicativa dedicata e separa codice, cache e log dal resto del sistema. Su EL8 una struttura semplice e leggibile funziona meglio di soluzioni creative. Un layout comune è /var/www/laravel-app con proprietà del web user e permessi coerenti per storage e bootstrap/cache.

Se il progetto nasce da zero, usa Composer direttamente:

sudo mkdir -p /var/www/laravel-app
sudo chown -R $USER:$USER /var/www/laravel-app
cd /var/www/laravel-app
composer create-project laravel/laravel .

Se invece stai distribuendo un repository esistente, clona il codice e poi installa le dipendenze con composer install. In questo caso il file .env va preparato a parte e mai versionato con credenziali in chiaro. Se il progetto usa variabili sensibili, la chiusura corretta è un file locale protetto, un secret manager o un meccanismo di injection lato piattaforma.

Per allineare i permessi minimi indispensabili:

sudo chown -R apache:apache /var/www/laravel-app
sudo find /var/www/laravel-app -type f -exec chmod 0644 {} \;
sudo find /var/www/laravel-app -type d -exec chmod 0755 {} \;
sudo chmod -R ug+rwx /var/www/laravel-app/storage /var/www/laravel-app/bootstrap/cache

Qui il rischio è chiaro: permessi troppo larghi facilitano scritture indesiderate, permessi troppo stretti rompono cache, upload e log. Il compromesso corretto è limitare la scrittura alle sole directory che Laravel deve usare davvero.

Nginx con PHP-FPM: scelta pulita per performance e isolamento

Se vuoi una configurazione snella e prevedibile, Nginx con PHP-FPM è spesso la combinazione più lineare su AlmaLinux e Rocky Linux 8. Il vantaggio pratico è il controllo esplicito del passaggio delle richieste PHP al socket FPM, con meno ambiguità rispetto a setup più “magici”.

Abilita e avvia il servizio:

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

Un server block minimo per Laravel deve puntare alla directory public, non alla root del progetto. Questo dettaglio evita l’esposizione di file interni e allinea il document root al front controller di Laravel.

server {
    listen 80;
    server_name example.com;
    root /var/www/laravel-app/public;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.(php)$ {
        include fastcgi_params;
        fastcgi_pass unix:/run/php-fpm/www.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

    location ~ /\.(?!well-known).* {
        deny all;
    }
}

Dopo aver salvato il file in /etc/nginx/conf.d/, verifica la sintassi e ricarica il servizio. Il controllo prima del reload è obbligatorio: un errore di configurazione Nginx può interrompere il sito anche se PHP è perfetto.

sudo nginx -t
sudo systemctl reload nginx

Se usi SELinux in enforcing, non saltare la parte di contesto. Il classico errore è avere permessi UNIX corretti ma accesso negato dal MAC layer. Per Laravel, i contesti più rilevanti sono quelli del document root e delle directory scrivibili dall’applicazione.

sudo semanage fcontext -a -t httpd_sys_content_t "/var/www/laravel-app(/.*)?"
sudo restorecon -Rv /var/www/laravel-app

Apache con PHP-FPM: quando serve compatibilità o abitudine operativa

Apache resta una scelta valida, soprattutto se hai già vhost consolidati, .htaccess in uso o una base operativa che lo preferisce. Anche qui il consiglio è usare PHP-FPM, non ricadere su configurazioni vecchie con mod_php se non hai un motivo preciso. Con FPM, il comportamento è più prevedibile e l’isolamento migliore.

Installa e avvia i servizi necessari:

sudo dnf install -y httpd
sudo systemctl enable --now httpd php-fpm

Un virtual host essenziale per Laravel può usare DocumentRoot /var/www/laravel-app/public e una regola che indirizza tutto verso index.php. Se hai bisogno di .htaccess, abilita AllowOverride All solo dove serve, non sull’intero filesystem.

<VirtualHost *:80>
    ServerName example.com
    DocumentRoot /var/www/laravel-app/public

    <Directory /var/www/laravel-app/public>
        AllowOverride All
        Require all granted
    </Directory>

    ProxyPassMatch ^/(.*\.php)$ unix:/run/php-fpm/www.sock|fcgi://localhost/var/www/laravel-app/public/
</VirtualHost>

Dopo la modifica, controlla la sintassi e ricarica il demone. Se il sito non risponde, i primi log da guardare sono /var/log/httpd/error_log e il log di PHP-FPM, di solito sufficiente a capire se il problema è di socket, permessi o mapping delle richieste.

.env, database e chiavi applicative: la parte che spesso viene fatta male

Laravel senza un file .env coerente è solo una directory con codice PHP. Il file deve contenere i parametri dell’applicazione, il nome del database, il driver, il timezone, il dominio e la chiave applicativa generata da Laravel. Le credenziali vanno protette, non incollate in documenti condivisi, ticket o note operative.

Una volta preparato il database, imposta i parametri necessari e genera la key:

cd /var/www/laravel-app
cp .env.example .env
php artisan key:generate

Se il database è MySQL o MariaDB, crea schema e utente con privilegi limitati al solo database dell’applicazione. Non usare account amministrativi nel file di configurazione. Il blast radius di un errore di credenziali non deve superare il singolo progetto.

Dopo aver configurato il database nel file .env, testa la connessione con una migrazione o con un comando artisan che tocchi il layer applicativo. Se fallisce, la distinzione utile è questa: errore di rete o autenticazione nel database, oppure errore PHP a monte perché manca un’estensione o il runtime corretto.

php artisan migrate --force

Cache, storage e ottimizzazioni utili in produzione

Quando il progetto parte, le ottimizzazioni applicative vanno fatte con criterio. Laravel offre cache della configurazione, delle route e delle view, ma queste operazioni hanno senso solo se il file .env è già stabile. Se continui a cambiare variabili a mano, le cache ti complicano la vita invece di semplificarla.

Le classiche ottimizzazioni sono:

php artisan config:cache
php artisan route:cache
php artisan view:cache

Per il filesystem interno, verifica che storage sia scrivibile dal processo web e che eventuali upload siano collocati in una partizione con spazio sufficiente. Un disco quasi pieno è uno dei modi più banali per trasformare un’app sana in un sito che risponde male o non risponde affatto.

Controlli rapidi utili prima di aprire il traffico reale:

df -h
free -m
journalctl -u php-fpm -n 50 --no-pager
tail -n 50 /var/log/nginx/error.log

Se il sito mostra pagina bianca, non partire subito da Laravel: prima guarda PHP-FPM, log del web server, spazio disco e stato SELinux. Nella maggior parte dei casi il problema è uno di questi quattro, non il framework in sé.

Controlli finali, hardening minimo e rollback pratico

Un’installazione fatta bene non si ferma al “funziona sul browser”. Devi controllare che il front controller risponda, che i log vengano scritti, che il web server non esponga directory sensibili e che il servizio PHP-FPM sia sotto controllo. Se usi firewall, apri solo ciò che serve davvero: in genere 80 e 443 lato pubblico, niente altro.

Una verifica pratica minima è questa:

curl -I http://example.com
php artisan --version
php artisan tinker --execute="echo app()->version();"

Se qualcosa non torna, il rollback più pulito è riportare indietro la configurazione del virtual host, disabilitare eventuali cambi SELinux non necessari e ripristinare la versione precedente dei pacchetti o del repository PHP. Per le modifiche ai file di configurazione, tenere una copia del prima è il modo più semplice per rientrare in pochi minuti.

Assunzione operativa: l’host è destinato a servire un’applicazione in produzione o quasi-produzione, quindi ogni modifica a PHP, web server, permessi o database va trattata come change controllato, con verifica immediata e possibilità concreta di rollback.