Installare Apache, MySQL e PHP su AlmaLinux 9 o Rocky

Su AlmaLinux 9 e Rocky Linux 9 la strada più lineare per un stack LAMP è partire dai repository di base, installare Apache, un motore SQL compatibile con MySQL e PHP con i moduli davvero necessari, poi chiudere con verifica, firewall e un minimo di hardening. Il punto non è “far partire i servizi”, ma portarli in uno stato coerente: repository allineati, pacchetti aggiornati, permessi corretti e una pagina di test che confermi che web server, PHP e database parlano davvero tra loro.

Qui sotto trovi una procedura pensata per un server pulito, con privilegi amministrativi e systemd. Dove serve, distinguo tra installazione base e scelta del motore database: su questi sistemi il candidato più comune è MariaDB, ma se vuoi MySQL Community il flusso è simile, cambia solo il repository e qualche nome di pacchetto. Se non hai ancora deciso quale usare, il criterio pratico è semplice: per compatibilità e manutenzione ordinaria MariaDB è spesso la scelta più rapida; MySQL Community ha senso se ti serve allineamento preciso con uno stack applicativo che lo richiede.

Pacchetti da installare su AlmaLinux 9 e Rocky Linux 9

Prima di tutto aggiorna l’indice pacchetti e installa i componenti principali. Su un sistema appena predisposto conviene anche includere gli strumenti per SELinux e il firewall, perché spesso sono loro a bloccare l’accesso nonostante i servizi siano in ascolto.

Se vuoi una base LAMP classica con MariaDB, il set minimo è questo:

sudo dnf update -y
sudo dnf install -y httpd mariadb-server php php-cli php-common php-mysqlnd php-gd php-xml php-mbstring php-json php-opcache firewalld policycoreutils-python-utils

Se invece preferisci MySQL Community Server, prima aggiungi il repository ufficiale MySQL e poi installi il server al posto di MariaDB. La logica resta identica, ma evita di tenere contemporaneamente i pacchetti dei due mondi sulla stessa macchina, perché rischi conflitti e dipendenze poco pulite.

Un dettaglio utile: su AlmaLinux e Rocky il modulo PHP disponibile nei repository di base è spesso sufficiente per la maggior parte dei siti classici. Se però devi gestire estensioni specifiche, verifica la disponibilità con dnf search php- o dnf info php prima di improvvisare repository aggiuntivi. Più fonti abiliti, più aumenta il rischio di versioni incoerenti.

Avvio dei servizi e abilitazione all’avvio automatico

Dopo l’installazione, il primo obiettivo è portare i servizi in stato attivo e persistente. Non dare per scontato che siano abilitati: su molte installazioni il pacchetto viene installato, ma il servizio resta fermo finché non lo avvii esplicitamente.

sudo systemctl enable --now httpd
sudo systemctl enable --now mariadb
sudo systemctl status httpd mariadb --no-pager

Per PHP non c’è un servizio da avviare nel modello classico con Apache e mod_php o PHP-FPM, quindi la verifica passa dal web server e dal modulo PHP installato. Se usi PHP-FPM, la logica cambia leggermente: devi avviare anche php-fpm e configurare Apache perché inoltri le richieste PHP al socket o alla porta corretta.

Per capire subito se qualcosa non torna, controlla gli ultimi log di sistema e di Apache:

sudo journalctl -u httpd -n 50 --no-pager
sudo journalctl -u mariadb -n 50 --no-pager

Se vedi errori su binding della porta 80, quasi sempre c’è già un altro servizio in ascolto oppure il firewall non è il problema ma solo un sintomo successivo. Se invece MariaDB non parte, i casi tipici sono dati corrotti, permessi errati sulla directory dati o configurazione non valida introdotta da un file in /etc/my.cnf.d/.

Configurazione base di Apache su port 80 e 443

La configurazione iniziale di Apache su questi sistemi è già sensata per un sito singolo, ma conviene verificare che la document root e i permessi siano coerenti. Il percorso standard è /var/www/html.

Crea una pagina di test per confermare che il server risponde in chiaro prima di passare a PHP:

echo '<h1>Apache OK</h1>' | sudo tee /var/www/html/index.html

Se vuoi un virtual host dedicato, crea un file in /etc/httpd/conf.d/ invece di editare il file principale. È una scelta più pulita, perché ti permette di tenere separati i siti e di fare rollback senza toccare il resto della configurazione.

sudo tee /etc/httpd/conf.d/site-test.conf > /dev/null <<'EOF'
<VirtualHost *:80> ServerName example.local DocumentRoot /var/www/example.local/public_html <Directory /var/www/example.local/public_html> AllowOverride All Require all granted </Directory> ErrorLog logs/example.local-error.log CustomLog logs/example.local-access.log combined
</VirtualHost>
EOF

Dopo ogni modifica, valida la sintassi prima di riavviare. È una banalità che evita incidenti inutili:

sudo apachectl configtest
sudo systemctl reload httpd

Se apachectl configtest restituisce Syntax OK, hai già filtrato gli errori più costosi: parentesi mancanti, direttive fuori posto, file incluso con sintassi errata. In caso di errore, il messaggio indica quasi sempre il file e la riga da correggere.

Installazione e inizializzazione di MariaDB

MariaDB su AlmaLinux 9 e Rocky 9 si installa dal repository standard. Dopo l’installazione, il passaggio importante è la messa in sicurezza iniziale. Non basta avviare il servizio: il database va protetto con account, password e rimozione degli elementi di default non necessari.

sudo systemctl enable --now mariadb
sudo mysql_secure_installation

Durante la procedura interattiva, in genere conviene: impostare una password robusta per l’utente amministrativo, rimuovere gli utenti anonimi, disabilitare il login remoto di root, eliminare il database di test e ricaricare le tabelle dei privilegi. Su un server esposto in rete, questi passaggi non sono opzionali.

Se devi verificare che il servizio sia davvero operativo, entra nella console SQL locale:

sudo mysql -u root -p

Una volta dentro, controlla la versione e lo stato di base:

SELECT VERSION();
SHOW DATABASES;

Se l’accesso fallisce, verifica prima l’autenticazione configurata sul sistema. Su molte installazioni moderne root usa un plugin locale o autenticazione socket: non è un errore, è una scelta di sicurezza. In quel caso l’accesso avviene da root di sistema, non con una password MySQL tradizionale, a meno che tu non abbia impostato diversamente.

PHP con Apache: modulo classico o PHP-FPM

Su questa piattaforma hai due strade realistiche. La prima è il classico mod_php, semplice e immediato. La seconda è PHP-FPM, più flessibile e spesso preferibile se vuoi separare meglio il processo PHP da Apache. Per un’installazione standard e rapida, il modulo classico è ancora la via più diretta; per siti con carichi variabili o più pool PHP, FPM è più ordinato.

Per verificare che PHP sia installato e funzionante, crea una pagina di test temporanea. Non lasciare il file di diagnostica online più del necessario, perché espone informazioni utili a chi non dovrebbe vederle.

cat <<'EOF' | sudo tee /var/www/html/info.php > /dev/null
<?php
phpinfo();
EOF

Poi apri http://tuo-host/info.php dal browser. Se la pagina mostra la schermata di phpinfo(), il collegamento tra Apache e PHP è corretto. Se invece scarica il file o mostra il sorgente, la gestione del tipo MIME o del modulo PHP non è configurata come dovrebbe.

Quando hai finito il test, rimuovi il file:

sudo rm -f /var/www/html/info.php

Se preferisci PHP-FPM, installa il pacchetto dedicato e abilitalo:

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

In questo scenario Apache deve essere configurato per inoltrare i file .php al socket di FPM. La configurazione esatta dipende da come vuoi servire il sito, ma il principio è sempre lo stesso: Apache gestisce la connessione HTTP, PHP-FPM esegue lo script. Se il tuo stack è semplice e non hai esigenze particolari, il modulo PHP integrato resta più rapido da mettere in piedi; se vuoi più controllo, FPM è la scelta migliore.

Firewall e SELinux: i due punti che bloccano più spesso

Su AlmaLinux e Rocky il firewall e SELinux non vanno “disattivati per comodità”. Vanno configurati. È una differenza sostanziale, perché un server che funziona solo con protezioni abbassate è già fuori standard operativo.

Apri i servizi HTTP e HTTPS nel firewall:

sudo systemctl enable --now firewalld
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --list-services

L’output atteso deve includere http e, se usi TLS, https. Se il servizio risponde in locale ma non dall’esterno, questa è una delle prime verifiche da fare.

Per SELinux, la regola pratica è: lascia attivo il contesto di sicurezza e correggi i permessi o i boolean necessari. Per esempio, se Apache deve connettersi al database remoto, il boolean va abilitato in modo esplicito:

sudo getsebool httpd_can_network_connect_db
sudo setsebool -P httpd_can_network_connect_db on

Se invece servi contenuti da una directory non standard, il problema spesso è il contesto SELinux dei file. In quel caso controlla i contesti con ls -Z e applica il context corretto con semanage fcontext e restorecon. Non è un dettaglio estetico: su questi sistemi SELinux decide davvero se Apache può leggere o no un file.

Verifica completa dello stack LAMP

Quando tutto sembra pronto, fai una verifica dall’esterno e una dal server. Dal lato rete, il test più rapido è una richiesta HTTP con intestazioni; dal lato applicativo, il test migliore è una pagina PHP che interroga il database.

curl -I http://127.0.0.1/
php -v
mysql -u root -p -e 'SELECT 1;'

Se vuoi verificare anche che PHP riesca a collegarsi al database, crea un file di prova temporaneo fuori dalla document root pubblica o in una directory protetta, con credenziali dedicate e non con l’utente amministrativo. Un esempio minimale, da adattare al tuo ambiente, è usare un database di test e un utente con soli privilegi necessari. Evita di usare root nel codice applicativo: è una cattiva abitudine che diventa un problema appena il sito cresce.

Un controllo utile è osservare i log di Apache mentre ricarichi la pagina di test. Se compare un errore PHP, il server ti dice subito se manca un modulo, se il file non è leggibile o se c’è un problema di permessi. I log sono spesso più affidabili del browser, soprattutto quando il problema è lato server e non lato rendering.

Hardening minimo consigliato dopo l’installazione

Una volta completata l’installazione, ci sono alcune rifiniture che vale la pena fare subito. La prima è togliere le informazioni superflue dai banner e dalle risposte HTTP. La seconda è ridurre l’esposizione dei servizi che non servono. La terza è mantenere aggiornati i pacchetti di sicurezza.

Per Apache, valuta di nascondere la versione e il sistema operativo nei banner, sempre con la consapevolezza che l’obiettivo è ridurre l’esposizione, non “nascondere” un servizio vulnerabile. Il vero controllo resta l’aggiornamento:

sudo dnf update -y
sudo systemctl restart httpd mariadb

Per MariaDB, crea account applicativi dedicati con privilegi limitati. Un sito web non dovrebbe mai usare credenziali amministrative per operazioni ordinarie. Se hai bisogno di un solo database, assegna solo quel database e solo i privilegi indispensabili.

Infine, conserva una copia della configurazione funzionante. Anche solo un diff dei file in /etc/httpd/ e /etc/my.cnf.d/ ti fa risparmiare tempo quando devi ripristinare o clonare il server. Il rollback più semplice è quello che hai già preparato prima di cambiare qualcosa.

Problemi tipici e lettura rapida dei sintomi

Se il sito mostra una pagina bianca, controlla prima i log PHP e Apache, poi il modulo installato e infine i permessi dei file. Se il browser restituisce 403, spesso il problema è SELinux o una direttiva Require troppo restrittiva. Se vedi 500, la causa è quasi sempre a livello applicativo o di configurazione. Se il database non risponde, verifica che il servizio sia attivo, che il socket esista e che la connessione locale non sia bloccata da autenticazione o policy.

Se il server risponde solo in locale ma non dalla rete, il sospetto cade sul firewall o sul binding del servizio. Se invece il DNS punta al server sbagliato, nessuna configurazione locale ti salverà: in quel caso il problema è a monte e va corretto lato record DNS o indirizzo pubblico. La prima cosa da fare è sempre capire il layer che sta fallendo, non toccare subito la configurazione a caso.

Assunzioni: server nuovo o comunque non ancora in produzione, AlmaLinux 9 o Rocky Linux 9 aggiornati, accesso root o sudo, stack LAMP base con Apache, MariaDB e PHP, nessun reverse proxy o CDN davanti durante i test iniziali.