1 15/10/2026 10 min

Su Ubuntu 20.04 LTS lo stack LAMP resta una scelta lineare quando serve servire siti PHP classici con un controllo chiaro su web server, database e runtime. La parte davvero importante non è installare i pacchetti, ma farlo con un ordine che riduca gli errori: prima verificare che il sistema sia allineato, poi portare su Apache, quindi MariaDB, infine PHP e l’integrazione con il virtual host. Se salti questi passaggi, il risultato tipico è un server che risponde ma non esegue PHP, oppure un database accessibile solo in locale senza una policy minima di sicurezza.

Obiettivo operativo e scelte di base

Su Ubuntu 20.04 LTS i componenti di riferimento sono Apache 2.4, MariaDB 10.3 e PHP 7.4. È una combinazione stabile, supportata dal ciclo della distribuzione, e abbastanza prevedibile da amministrare sia in ambienti piccoli sia su server condivisi o VPS. In questa guida l’obiettivo è arrivare a un host che risponde su HTTP, esegue PHP tramite libapache2-mod-php e usa MariaDB con una configurazione base solida, senza aprire più del necessario.

La logica è questa: Apache gestisce la parte web, MariaDB conserva i dati applicativi e PHP interpreta il codice lato server. Il punto critico, in pratica, è il confine tra Apache e PHP: se il modulo non è attivo o il file di test non viene servito nella directory corretta, si finisce a debuggare sintomi che sembrano di rete ma sono solo di configurazione locale.

1. Allineare il sistema prima di installare

Prima di aggiungere pacchetti conviene portare il sistema allo stato più pulito possibile. Questo riduce conflitti, migliora la leggibilità dei log e rende più semplice il rollback di eventuali cambiamenti. Il controllo minimo è aggiornare l’indice dei pacchetti e verificare che non ci siano errori di repository.

sudo apt update
sudo apt -y upgrade
sudo apt -y autoremove

Se apt update restituisce errori su repository esterni, non ignorarli: prima risolvi quelli, poi procedi. In caso di server in produzione, ha senso fare anche uno snapshot o almeno annotare l’elenco dei pacchetti installati. Il rischio qui non è tanto il singolo comando, quanto il fatto che un upgrade lasci il sistema in uno stato misto se ci sono dipendenze interrotte.

2. Installare Apache e verificare il servizio

Apache è il primo pezzo da portare su perché offre subito un segnale chiaro di salute del server. L’installazione è semplice e il servizio parte in automatico. La verifica non va saltata: serve a distinguere un problema di web server da un problema di applicazione.

sudo apt install -y apache2
sudo systemctl enable --now apache2
sudo systemctl status apache2 --no-pager

Il risultato atteso è active (running). Se non lo è, i log del servizio sono il primo posto da guardare:

journalctl -u apache2 -n 50 --no-pager

Un controllo rapido lato rete locale è utile per confermare che il demone risponda prima ancora di esporlo in DNS o firewall:

curl -I http://127.0.0.1

Se vedi un HTTP/1.1 200 OK o un redirect coerente con la configurazione, Apache è vivo. Se invece ottieni connessione rifiutata o timeout, il problema è a livello servizio o bind sulla porta 80. In quel caso non andare avanti con PHP: prima chiudi il layer web.

3. Aprire il firewall solo per ciò che serve

Su un server esposto non ha senso installare uno stack e poi lasciare porte aperte per abitudine. Se usi UFW, abilita solo HTTP e, se necessario, HTTPS. Il database non va pubblicato su Internet per un setup standard LAMP.

sudo ufw allow 'Apache Full'
sudo ufw status verbose

Il profilo Apache Full apre 80 e 443. Se stai ancora lavorando in HTTP puro, puoi anche limitarti a Apache, ma in pratica conviene preparare subito TLS se il server andrà in produzione. Il punto è mantenere il blast radius ridotto: niente porte extra, niente esposizioni non motivate.

4. Installare MariaDB e mettere in sicurezza l’accesso iniziale

MariaDB fornisce il database relazionale tipico per applicazioni PHP classiche. Dopo l’installazione, il primo obiettivo non è creare subito un database, ma impostare una base di sicurezza minima: niente accessi anonimi, niente login root remoto, niente database di test lasciati aperti.

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

Subito dopo esegui il tool di hardening iniziale:

sudo mysql_secure_installation

Le risposte dipendono dal contesto, ma in un’installazione standard conviene: impostare una password per l’utenza amministrativa se richiesto, rimuovere utenti anonimi, disabilitare l’accesso root remoto, eliminare il database di test e ricaricare i privilegi. Se il tool propone opzioni diverse in base alla versione, non andare a memoria: leggi il prompt e chiudi la configurazione con attenzione.

Una verifica minima dell’accesso locale è questa:

sudo mysql -e 'SELECT VERSION();'

Se il comando ritorna la versione del server, il demone è operativo e l’interfaccia locale funziona. Se fallisce, controlla il socket, lo stato del servizio e gli ultimi log:

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

5. Installare PHP 7.4 e i moduli più utili

Su Ubuntu 20.04 la versione nativa è PHP 7.4. Per un LAMP classico, il modo più semplice è usare il modulo Apache integrato. È meno flessibile di PHP-FPM, ma riduce i punti di rottura e va benissimo per molte installazioni tradizionali. I moduli da installare dipendono dal tipo di sito, ma una base ragionevole include supporto per MySQL, XML, curl e mbstring.

sudo apt install -y php libapache2-mod-php php-mysql php-cli php-curl php-xml php-mbstring

Dopo l’installazione, controlla la versione effettiva del binario e i moduli caricati:

php -v
php -m | sort

Il modulo php-mysql è quello che permette a PHP di parlare con MariaDB. Senza quello, il codice applicativo può sembrare corretto ma fallire appena prova a creare una connessione al database. Se l’applicazione richiede estensioni aggiuntive, installale solo quando servono: meno moduli significa meno superficie di manutenzione.

6. Verificare la catena Apache-PHP con un file di test

La verifica più utile, prima di configurare un sito reale, è un file PHP minimale nella document root di default. Su Ubuntu con Apache la directory è in genere /var/www/html. Il test deve confermare tre cose: Apache serve il file, PHP viene interpretato e il browser riceve output dinamico, non il sorgente.

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

Aprendo http://IP_DEL_SERVER/info.php dovresti vedere la pagina di phpinfo(). In alternativa, da shell puoi fare un controllo rapido con curl e cercare una firma nota:

curl -s http://127.0.0.1/info.php | grep -i 'PHP Version'

Se invece il browser scarica il file o mostra il codice PHP in chiaro, il modulo non è agganciato correttamente ad Apache. In quel caso verifica che libapache2-mod-php sia installato e che il modulo sia attivo:

apache2ctl -M | grep php

Un output coerente indica che il parsing PHP è abilitato. Se non compare nulla, riavvia Apache dopo l’installazione del modulo e ricontrolla i log.

7. Creare un virtual host pulito invece di lavorare sul sito di default

Il sito di default va bene per il test iniziale, ma non per un ambiente che deve durare. Appena la catena base è confermata, conviene creare un virtual host dedicato. Questo separa i document root, semplifica la manutenzione e riduce gli errori quando ospiti più domini sullo stesso server.

Un esempio minimale di file di configurazione potrebbe essere /etc/apache2/sites-available/example.conf:

<VirtualHost *:80> ServerName example.test ServerAlias www.example.test DocumentRoot /var/www/example <Directory /var/www/example> AllowOverride All Require all granted </Directory> ErrorLog ${APACHE_LOG_DIR}/example_error.log CustomLog ${APACHE_LOG_DIR}/example_access.log combined
</VirtualHost>

Attiva il sito, disabilita quello di default se non ti serve e ricarica Apache:

sudo mkdir -p /var/www/example
sudo chown -R www-data:www-data /var/www/example
sudo a2ensite example.conf
sudo a2dissite 000-default.conf
sudo apache2ctl configtest
sudo systemctl reload apache2

Il comando apache2ctl configtest deve restituire Syntax OK. Se non lo fa, non ricaricare il servizio: correggi prima l’errore. È un classico caso in cui un reload fatto male lascia il server in uno stato che sembra funzionante ma non lo è.

8. Preparare l’applicazione PHP e il collegamento al database

Per dimostrare che lo stack è realmente operativo, conviene creare un test applicativo che interroga MariaDB. Questo chiude il cerchio tra web server, runtime e database. Un file PHP minimale può usare mysqli o PDO; per un esempio semplice, mysqli è immediato.

sudo mysql -e "CREATE DATABASE appdb; CREATE USER 'appuser'@'localhost' IDENTIFIED BY 'CambiaQuestaPassword'; GRANT ALL PRIVILEGES ON appdb.* TO 'appuser'@'localhost'; FLUSH PRIVILEGES;"

Qui c’è un punto delicato: la password non va lasciata in chiaro in documentazione o script condivisi. In un contesto reale, usa un gestore segreti o almeno un file di configurazione con permessi stretti, ad esempio fuori dalla document root. Il test temporaneo può essere rimosso appena verificato il flusso.

Un file di prova, ad esempio /var/www/example/dbtest.php, può contenere:

<?php
$mysqli = new mysqli('localhost', 'appuser', 'CambiaQuestaPassword', 'appdb');
if ($mysqli->connect_error) { die('Connessione fallita: ' . $mysqli->connect_error);
}
echo 'Connessione al database OK';
$mysqli->close();
?>

Aprendo http://example.test/dbtest.php dovresti vedere il messaggio di successo. Se compare un errore di autenticazione, il problema è nelle credenziali o nei privilegi. Se invece compare un errore di classe mancante o estensione non trovata, ricontrolla php-mysql.

9. Hardening minimo che vale la pena fare subito

Un LAMP appena installato funziona, ma non è ancora rifinito. Ci sono alcune cose che conviene sistemare subito per evitare problemi banali: rimuovere file di test, limitare permessi, evitare l’esposizione di informazioni inutili e preparare un minimo di logging leggibile.

Rimuovi il file info.php appena hai finito di testarlo:

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

Se usi il virtual host dedicato, puoi anche bloccare il listing delle directory e tenere AllowOverride solo se ti serve davvero per .htaccess. In molti casi è meglio spostare le regole dentro il vhost, perché è più esplicito e più facile da versionare.

Per Apache, i log utili sono in genere in /var/log/apache2/. Per MariaDB, i dettagli dipendono dalla configurazione, ma il journal del servizio aiuta quasi sempre:

journalctl -u apache2 -n 100 --no-pager
journalctl -u mariadb -n 100 --no-pager

In ottica sicurezza, il controllo principale è semplice: il database non deve essere raggiungibile da IP esterni se non c’è un’esigenza precisa, e i file della webroot non devono contenere credenziali riusabili in chiaro. Se un’app legacy le richiede, almeno isola il file di configurazione e limita i permessi al solo utente del web server.

10. Controlli finali e segnali che lo stack è sano

Quando tutto è installato, non fermarti al fatto che “la pagina si apre”. Un controllo decente deve coprire almeno stato dei servizi, risposta HTTP, parsing PHP e connessione al database. Se questi quattro punti sono allineati, lo stack è pronto per ospitare un’applicazione reale.

systemctl is-active apache2
systemctl is-active mariadb
curl -I http://127.0.0.1
php -v
sudo mysql -e 'SELECT 1;'

Il risultato atteso è: servizi attivi, HTTP 200 o redirect coerente, versione PHP stampata correttamente e query SQL eseguita senza errori. Se uno di questi punti fallisce, non cambiare tre cose insieme: isola il layer che rompe e intervieni lì. È il modo più veloce per non perdere tempo in falsi positivi.

Assunzione operativa: questa procedura è pensata per un server Ubuntu 20.04 LTS standard, con accesso root o sudo e nessun pannello di terze parti che riscriva la configurazione di Apache o MariaDB.