1 18/05/2026 10 min

Stack LAMP su AlmaLinux 8: scelta dei pacchetti e ordine corretto

Su AlmaLinux 8 il modo più pulito per mettere in piedi un stack Apache, database e PHP è partire dai repository di base, verificare cosa è già presente nel sistema e installare i componenti nell’ordine giusto: web server, database, runtime PHP e moduli applicativi. L’errore tipico non è l’installazione in sé, ma il lasciare il sistema in uno stato ambiguo: due versioni di PHP, database non avviato, firewall aperto a metà o VirtualHost che puntano a directory senza permessi corretti.

Qui l’obiettivo è avere un ambiente coerente, ripetibile e facile da controllare. AlmaLinux 8 usa dnf e systemd, quindi conviene trattare ogni passaggio come una piccola change: installo, verifico, abilito al boot, testo il servizio, poi passo allo step successivo. Se qualcosa non torna, il rollback deve essere semplice: disabilitare il servizio, rimuovere il pacchetto o ripristinare la config salvata.

Preparazione del sistema e aggiornamento base

Prima di installare i pacchetti, allineo il sistema e controllo che non ci siano problemi banali di rete o repository. Questo evita di perdere tempo su errori che in realtà arrivano da un mirror non raggiungibile o da metadati DNF corrotti.

Eseguo un aggiornamento completo e verifico la release:

sudo dnf update -y
cat /etc/almalinux-release
sudo dnf repolist

Il risultato atteso è un sistema aggiornato, con repository attivi e senza warning evidenti. Se dnf repolist mostra repository disabilitati o errori di metadata, il problema va risolto prima di andare avanti. In ambienti con proxy o mirror interni, conviene anche controllare DNS e reachability verso i repository configurati.

Installare Apache su AlmaLinux 8

Apache su AlmaLinux 8 si installa in modo diretto dal repository standard. Il servizio si chiama httpd e la configurazione principale vive in /etc/httpd/conf/httpd.conf, con i siti spesso gestiti tramite file separati in /etc/httpd/conf.d/.

Installo, avvio e abilito il servizio:

sudo dnf install -y httpd
sudo systemctl enable --now httpd
sudo systemctl status httpd --no-pager

La verifica minima è semplice: systemctl status deve mostrare active (running). In parallelo, controllo che il processo ascolti sulla porta 80:

sudo ss -tulpn | grep ':80 '

Se il servizio non parte, i log sono il primo punto da leggere:

sudo journalctl -u httpd -b --no-pager | tail -n 50

Un errore frequente è la presenza di un’altra applicazione già in ascolto sulla porta 80. In quel caso Apache fallisce in avvio e il log lo dice chiaramente. La correzione non è forzare Apache, ma liberare la porta o cambiare binding in modo consapevole.

Aprire il firewall senza esporre più del necessario

Su AlmaLinux 8 il firewall predefinito è spesso firewalld. Se Apache deve essere raggiungibile dall’esterno, apro il servizio HTTP e, se previsto, HTTPS. Non apro porte a caso: solo quelle necessarie al traffico reale.

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --list-services

Il controllo finale è banale ma decisivo: se il servizio è attivo e la porta è aperta, una richiesta da una macchina remota deve rispondere. Se il server è dietro una security group o un firewall upstream, il problema può essere fuori da AlmaLinux: in quel caso il comando locale non basta e va verificato anche il layer di rete a monte.

Installare MariaDB come scelta pratica per il database

Nel linguaggio comune si dice spesso “MySQL”, ma su AlmaLinux 8 la strada più lineare è MariaDB, che è compatibile per la maggior parte degli scenari LAMP e arriva con pacchetti ben integrati nel sistema. Se il requisito è proprio MySQL Oracle, la procedura cambia per repository e manutenzione; qui uso la variante più naturale per AlmaLinux 8.

Installazione e avvio:

sudo dnf install -y mariadb-server
sudo systemctl enable --now mariadb
sudo systemctl status mariadb --no-pager

Verifico che il database risponda localmente:

sudo mysql -u root -e 'SELECT VERSION();'

Se il login root fallisce subito dopo l’installazione, può essere normale: dipende dal metodo di autenticazione iniziale e dalla procedura di hardening. Il punto è distinguere un database non avviato da un database avviato ma protetto da autenticazione locale. I log utili sono in journalctl -u mariadb e, se necessario, nel file di log configurato lato MariaDB.

Hardening minimo del database

Subito dopo l’installazione conviene fare una pulizia minima: password root, rimozione account anonimi, disabilitazione del login remoto root e rimozione del database di test. Su un server esposto, lasciare l’installazione “di fabbrica” è una cattiva idea.

sudo mysql_secure_installation

Le scelte da fare dipendono dal contesto, ma la direzione è quasi sempre la stessa: password forte, nessun account anonimo, test database rimosso, accesso root remoto negato. Se il database deve servire applicazioni esterne, meglio creare un utente dedicato con privilegi limitati sul solo schema necessario.

Esempio di creazione di un database e di un utente applicativo:

sudo mysql -u root
CREATE DATABASE appdb;
CREATE USER 'appuser'@'localhost' IDENTIFIED BY 'password_forte_da_sostituire';
GRANT ALL PRIVILEGES ON appdb.* TO 'appuser'@'localhost';
FLUSH PRIVILEGES;

Qui il punto non è la sintassi in sé, ma il principio: privilegi minimi e credenziali mai riusate. La password nell’esempio va sostituita subito e non va mai lasciata in chiaro in documentazione operativa o nei file di configurazione senza protezione adeguata.

Installare PHP e i moduli essenziali

PHP su AlmaLinux 8 può essere installato dalla distribuzione base oppure tramite repository aggiuntivi, a seconda della versione richiesta dall’applicazione. Per un setup standard, il pacchetto base e alcuni moduli comuni sono sufficienti: integrazione con Apache, supporto al database, estensioni per stringhe, XML e compressione.

Installazione tipica:

sudo dnf install -y php php-cli php-common php-mysqlnd php-gd php-xml php-mbstring php-opcache

Verifico la versione e i moduli caricati:

php -v
php -m

Il controllo importante è che php-mysqlnd sia presente se l’applicazione parla con MariaDB/MySQL, e che opcache sia caricato se si vuole una base prestazionale decente. In ambienti dove serve una versione PHP specifica, va valutata la sorgente dei pacchetti prima dell’installazione, perché il rischio più comune è avere un runtime non allineato ai requisiti del codice applicativo.

Collegare PHP ad Apache nel modo giusto

Su AlmaLinux 8 l’integrazione tra Apache e PHP può passare tramite mod_php o tramite PHP-FPM. Per un server semplice, mod_php è immediato; per carichi più ordinati e separazione migliore tra web server e runtime, PHP-FPM è spesso la scelta più pulita. Qui conviene decidere subito, perché mescolare i due modelli crea confusione.

Se si usa l’approccio classico con mod_php, dopo l’installazione il test più semplice è creare un file PHP nella document root di default, ad esempio /var/www/html/info.php:

<?php
phpinfo();

Poi si verifica da browser o via curl:

curl http://127.0.0.1/info.php

Se la pagina mostra l’output di phpinfo(), l’integrazione di base è funzionante. Dopo il test, il file va rimosso: lasciare info.php pubblicamente accessibile è un errore inutile perché espone dettagli interni della configurazione.

Se invece si vuole PHP-FPM, la logica cambia: il servizio PHP gira separato e Apache fa da proxy verso il socket o la porta locale. È una scelta più adatta quando si vuole isolare il runtime o gestire versioni multiple. In quel caso la verifica passa da systemctl status php-fpm e dalla corretta configurazione del VirtualHost.

Creare un VirtualHost pulito

Una configurazione ordinata non lascia tutto nel default site. Creo un VirtualHost dedicato e separo document root, log e parametri del sito. Questo semplifica troubleshooting e rollback.

sudo mkdir -p /var/www/example.com/public_html
sudo mkdir -p /var/www/example.com/logs
sudo chown -R apache:apache /var/www/example.com

File esempio in /etc/httpd/conf.d/example.com.conf:

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/example.com/public_html

    ErrorLog /var/www/example.com/logs/error.log
    CustomLog /var/www/example.com/logs/access.log combined

    <Directory /var/www/example.com/public_html>
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

Dopo aver scritto il file, controllo la sintassi e ricarico Apache:

sudo apachectl configtest
sudo systemctl reload httpd

Il controllo configtest deve restituire Syntax OK. Se fallisce, non si forza il reload: si corregge prima il file. In ambienti reali, una sintassi sbagliata su Apache è un problema evitabile e va trattata come tale.

Permessi, SELinux e il punto che rompe più spesso i deploy

Su AlmaLinux 8 SELinux è spesso attivo e non va trattato come un fastidio da spegnere. Se una pagina PHP non legge file o non scrive upload, il problema può essere un contesto errato, non il codice dell’applicazione.

Controllo lo stato di SELinux:

getenforce
sestatus

Se serve permettere ad Apache di connettersi al database in rete o ad altri servizi, il contesto va abilitato in modo mirato. Esempio classico per connessioni outbound di Apache:

sudo setsebool -P httpd_can_network_connect on

Per directory di upload o contenuti dinamici con scrittura, spesso conta anche il contesto dei file. Il controllo utile è:

ls -Z /var/www/example.com/public_html

Se l’app non riesce a scrivere, il problema si vede spesso anche nei log di audit o nei messaggi di errore dell’applicazione. In quel caso la correzione va fatta con il contesto SELinux corretto, non con chmod generici che allargano troppo i permessi.

Test finale dell’intero stack

A questo punto il test deve coprire l’intera catena: Apache risponde, PHP viene eseguito, il database è raggiungibile e il firewall non blocca nulla. Un test minimo ma realistico è una pagina PHP che interroga il database e restituisce un risultato semplice.

<?php
$mysqli = new mysqli('localhost', 'appuser', 'password_forte_da_sostituire', 'appdb');
if ($mysqli->connect_error) {
    http_response_code(500);
    die('DB connection failed');
}
echo 'OK';

Il risultato atteso è una risposta OK via browser o via curl. Se appare un errore 500, il percorso di diagnosi è lineare: prima Apache, poi PHP, poi credenziali e accesso al database. Se la pagina bianca compare senza messaggi, i log applicativi e quelli di Apache diventano il primo riferimento utile.

Controlli rapidi da tenere a portata di mano:

sudo tail -n 50 /var/log/httpd/error_log
sudo journalctl -u httpd -b --no-pager | tail -n 50
sudo journalctl -u mariadb -b --no-pager | tail -n 50

Manutenzione essenziale dopo l’installazione

Un stack installato bene ma non governato tende a degradare nel tempo. Le attività minime da prevedere sono aggiornamenti regolari, controllo dello spazio disco, rotazione log e verifica dei servizi al boot. Se il server ospita più siti, conviene anche documentare quali VirtualHost dipendono da quali versioni PHP e quali database.

Per una base operativa, i comandi più utili restano questi:

sudo systemctl is-enabled httpd mariadb
sudo systemctl is-active httpd mariadb
sudo df -h
sudo ss -tulpn

Se il sistema cresce, il passo successivo naturale è passare a PHP-FPM, separare meglio i pool, definire backup del database e introdurre un monitoraggio minimo su error rate, latenza e saturazione disco. L’installazione iniziale è solo il primo blocco; la qualità del servizio la fa la manutenzione.

Sequenza operativa consigliata in sintesi

Se devo ridurre tutto a una sequenza pratica, la logica è questa: aggiorno il sistema, installo Apache, apro il firewall, installo MariaDB, applico l’hardening minimo, installo PHP e i moduli necessari, creo il VirtualHost, verifico SELinux, testo un endpoint PHP e solo alla fine rimuovo i file di prova. È il modo più semplice per evitare di dover riaprire tutto tre volte per colpa di un dettaglio lasciato indietro.

Su AlmaLinux 8 questa impostazione funziona bene perché sfrutta i pacchetti nativi, resta compatibile con la gestione standard di systemd e mantiene il sistema leggibile anche a distanza di mesi. Se il requisito applicativo impone MySQL Oracle o una versione PHP specifica, la struttura resta la stessa: cambia la sorgente dei pacchetti, non la disciplina operativa.

Assunzione operativa: il server è un host Linux recente con systemd, SELinux attivo e accesso amministrativo locale; se uno di questi punti non vale, la procedura va adattata prima di applicarla in produzione.