1 14/10/2026 10 min

Stack LAMP su Ubuntu 20.04: cosa installare davvero

Su Ubuntu 20.04 lo stack LAMP non è solo una sequenza di pacchetti da installare. Se vuoi un server che stia in piedi senza rincorrere bug banali, devi ragionare subito su tre livelli: web server, database e runtime PHP. La scelta più lineare resta Apache + MariaDB + PHP, perché è ben supportata, facile da manutenere e abbastanza prevedibile anche in ambienti piccoli o medi.

Qui parto da un’installazione pulita, con controlli verificabili ad ogni passo. L’obiettivo non è solo vedere la pagina di test, ma arrivare a una base solida: servizi attivi, moduli corretti, permessi sensati e un primo hardening minimo. Dove serve, indico anche cosa controllare se qualcosa non torna.

Prima di iniziare: requisiti e decisioni pratiche

Assumo un server Ubuntu 20.04 aggiornato, accesso sudo e un hostname già impostato. Se stai lavorando su una macchina esposta a Internet, considera il setup come potenzialmente in produzione: apri solo le porte necessarie e verifica subito firewall, DNS e certificati dopo l’installazione.

Per questa guida uso Apache come web server, MariaDB come database e PHP con libapache2-mod-php. Se in seguito vorrai passare a PHP-FPM con Apache o migrare a Nginx, la logica cambia un po’, ma la base di installazione resta la stessa.

1) Aggiornare il sistema prima di installare

Il primo errore tipico è installare tutto su un sistema non allineato. Su Ubuntu 20.04 conviene partire con un update completo, così riduci conflitti di dipendenze e ti assicuri patch recenti per i pacchetti già presenti.

Esegui:

sudo apt update
sudo apt -y upgrade

Verifica che non ci siano pacchetti bloccati o errori di repository:

apt list --upgradable
sudo apt update

Se apt update segnala repository rotti o chiavi mancanti, fermati lì: prima correggi le sorgenti, poi prosegui. Non ha senso installare uno stack applicativo sopra una base di pacchetti incoerente.

2) Installare Apache

Apache è il primo blocco dello stack. Su Ubuntu 20.04 si installa in modo pulito con i pacchetti standard, e systemd ne gestisce avvio e persistenza.

Installa il servizio:

sudo apt install -y apache2

Controlla lo stato del servizio:

systemctl status apache2 --no-pager

Ti aspetti active (running). Se non lo è, guarda subito i log del servizio:

journalctl -u apache2 -xe --no-pager

Verifica anche che risponda in locale:

curl -I http://127.0.0.1

Un HTTP/1.1 200 OK o comunque una risposta valida indica che il daemon è up e sta ascoltando correttamente sulla porta 80.

Se il server è remoto, puoi testare anche dall’esterno con il suo IP pubblico. In quel caso, se non risponde, i colpevoli più probabili sono firewall, security group o binding errato. Apache di default ascolta su 80 e, se attivi TLS, su 443.

3) Aprire il firewall solo per i servizi necessari

Con UFW attivo conviene autorizzare solo ciò che serve. Per un LAMP base, almeno HTTP e, se previsto, HTTPS.

Comandi tipici:

sudo ufw allow 'Apache'
sudo ufw status verbose

Se vuoi essere più esplicito, puoi aprire singolarmente le porte:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Controlla che il profilo sia quello giusto e che non ci siano regole in conflitto. Se UFW è disattivato, non dare per scontato che sia il problema: su alcuni ambienti il filtraggio avviene a monte, ad esempio nel provider cloud o in una ACL di rete.

4) Installare MariaDB e proteggerlo subito

MariaDB è una scelta molto comune su Ubuntu 20.04 per compatibilità e semplicità operativa. Installa il server e verifica che il servizio sia attivo prima di passare alla configurazione applicativa.

Installa il database:

sudo apt install -y mariadb-server mariadb-client

Controlla lo stato:

systemctl status mariadb --no-pager

Se il servizio non parte, il log utile è quasi sempre questo:

journalctl -u mariadb -xe --no-pager

Una volta avviato, applica la procedura di hardening base:

sudo mysql_secure_installation

Le domande più importanti sono la rimozione degli utenti anonimi, il blocco del login remoto di root e l’eliminazione del database di test. In un ambiente serio queste opzioni vanno quasi sempre accettate.

Per verificare l’accesso locale al database:

sudo mysql -u root -p

Se entri nella shell MariaDB, la base è corretta. Da lì puoi già creare un database e un utente dedicato all’applicazione, evitando di usare root per tutto.

5) Creare database e utente applicativo

Non usare il database di root per il sito. Crea invece un database dedicato e un utente con privilegi limitati al solo schema necessario.

Esempio:

sudo mysql -u root -p
CREATE DATABASE sitodb;
CREATE USER 'sito_user'@'localhost' IDENTIFIED BY 'password_forte_da_sostituire';
GRANT ALL PRIVILEGES ON sitodb.* TO 'sito_user'@'localhost';
FLUSH PRIVILEGES;
EXIT;

La password nel comando è solo un segnaposto: in produzione va scelta e conservata in modo sicuro, non incollata in chiaro in documenti o ticket. Se devi distribuirla in un team, usa un secret manager o almeno un canale cifrato e ruota il valore dopo l’onboarding.

Verifica che l’utente si autentichi correttamente:

mysql -u sito_user -p -h localhost sitodb

Se l’accesso fallisce, controlla host associato all’utente, quoting del nome e policy di autenticazione di MariaDB.

6) Installare PHP e i moduli utili

Per un LAMP classico su Apache, la via più semplice è installare PHP con il modulo Apache e i moduli più usati dalle applicazioni web. Su Ubuntu 20.04, la versione di default è PHP 7.4.

Installa il runtime:

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

Controlla la versione disponibile:

php -v

Una risposta con la versione conferma che il binario è presente e funzionante. Se l’applicazione richiede estensioni specifiche, aggiungile ora, non quando il sito mostra fatal error in produzione.

Per vedere i moduli caricati:

php -m

Se un modulo manca, il sintomo tipico è un errore nel log applicativo o una funzionalità che non parte, ad esempio upload, XML parsing o connessioni al DB. La verifica preventiva ti evita diagnosi più lunghe dopo.

7) Far parlare Apache e PHP

Con libapache2-mod-php Apache interpreta direttamente i file PHP. In questo modello la configurazione è semplice e adatta a chi vuole partire senza introdurre subito PHP-FPM.

Riavvia Apache dopo l’installazione dei moduli:

sudo systemctl restart apache2

Crea un file di test nella document root predefinita:

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

Apri nel browser http://IP_DEL_SERVER/info.php e verifica che venga mostrata la pagina di PHP info. Se vedi il sorgente invece della pagina interpretata, PHP non è agganciato ad Apache. Se vedi errore 500, il problema è più spesso di configurazione o permessi.

Dopo il test, rimuovi il file:

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

Questo passaggio non è opzionale: phpinfo() espone informazioni utili anche a chi non dovrebbe vederle, come moduli caricati, percorsi e dettagli ambientali.

8) Creare un VirtualHost dedicato

La root /var/www/html va bene per i test, non per un sito vero. Appena possibile crea un VirtualHost dedicato, così separi configurazione, log e contenuti.

Esempio di file:

sudo nano /etc/apache2/sites-available/sito.conf

Contenuto minimo:

<VirtualHost *:80> ServerName sito.example.com ServerAdmin webmaster@sito.example.com DocumentRoot /var/www/sito ErrorLog ${APACHE_LOG_DIR}/sito_error.log CustomLog ${APACHE_LOG_DIR}/sito_access.log combined <Directory /var/www/sito> AllowOverride All Require all granted </Directory>
</VirtualHost>

Abilita sito e modulo rewrite se ti serve per CMS o routing pulito:

sudo mkdir -p /var/www/sito
sudo a2ensite sito.conf
sudo a2enmod rewrite
sudo apache2ctl configtest
sudo systemctl reload apache2

Il controllo apache2ctl configtest deve rispondere con Syntax OK. Se non lo fa, non ricaricare il servizio alla cieca: correggi prima il file, poi ricarica.

9) Permessi e ownership della web root

I permessi sbagliati sono una delle cause più frequenti di pagine bianche, errori 403 o upload falliti. La web root dovrebbe essere scrivibile solo dove serve davvero, non ovunque.

Imposta una ownership coerente, ad esempio:

sudo chown -R www-data:www-data /var/www/sito
sudo find /var/www/sito -type d -exec chmod 755 {} \;
sudo find /var/www/sito -type f -exec chmod 644 {} \;

Se l’applicazione deve caricare file, valuta una directory specifica con permessi più permissivi, non l’intero albero. Questo riduce l’impatto di un eventuale exploit applicativo.

10) Verifiche finali da fare subito

Una volta completata l’installazione, verifica il comportamento end-to-end. Non basta che i servizi siano “running”: devi vedere che HTTP, PHP e database siano coerenti tra loro.

Controlli rapidi:

systemctl is-active apache2
systemctl is-active mariadb
php -v
curl -I http://127.0.0.1

Se hai già creato il VirtualHost, prova anche la risoluzione del nome e la risposta del sito. Nel caso di DNS non ancora configurato, puoi testare con /etc/hosts o con un curl --resolve temporaneo.

Esempio:

curl -I --resolve sito.example.com:80:IP_DEL_SERVER http://sito.example.com

Questo ti dice subito se il virtual host risponde correttamente anche prima della propagazione DNS.

11) Hardening minimo che vale la pena fare subito

Prima di lasciare il server esposto, applica almeno questi punti: rimuovi file di test, limita i privilegi DB, non lasciare moduli inutili attivi e pianifica l’aggiornamento del sistema. Se il server è pubblico, aggiungi TLS appena il dominio è pronto.

Per Apache, controlla i moduli caricati:

apache2ctl -M

Disabilita ciò che non serve davvero. Ogni modulo in più è un pezzo di superficie d’attacco e una possibile variabile di troubleshooting.

Per gli aggiornamenti di sicurezza, su Ubuntu 20.04 ha senso avere almeno l’attenzione su unattended-upgrades o su una finestra di manutenzione regolare. Non è il tema centrale della installazione, ma è ciò che distingue un server “installato” da uno gestibile nel tempo.

12) Cosa fare se qualcosa non va

Se il sito non risponde, segui sempre la catena giusta: rete, Apache, PHP, database, permessi. In ordine pratico, i tre comandi che chiariscono più situazioni sono questi:

systemctl status apache2 --no-pager
journalctl -u apache2 -xe --no-pager
curl -I http://127.0.0.1

Se Apache è ok ma il sito mostra errore applicativo, guarda i log del VirtualHost e i log PHP o dell’applicazione. Se il database non risponde, verifica systemctl status mariadb e la connettività locale. Se trovi disco pieno o memoria esaurita, il sintomo può essere una pagina bianca o un 500 apparentemente casuale.

In altre parole: non partire da rifacimenti strutturali. Prima osserva, poi correggi il punto che rompe la catena.

13) Snodo finale: quando il LAMP è davvero pronto

Lo stack è pronto quando questi tre fatti sono veri insieme: Apache risponde, MariaDB accetta connessioni locali con un utente dedicato, PHP viene eseguito da Apache senza errori. Se uno di questi tre manca, non sei ancora in uno stato affidabile per ospitare un’applicazione.

A quel punto puoi installare CMS, framework o applicazioni custom con una base pulita. La differenza, in pratica, la fanno i controlli fatti subito e non dopo il primo guasto.

Se vuoi usare questa installazione come base di produzione, il passo successivo naturale è aggiungere TLS con un certificato valido, logging centralizzato e backup del database. Ma il primo obiettivo resta sempre lo stesso: avere un LAMP semplice, leggibile e verificabile.

Assunzione: questa procedura parte da un server Ubuntu 20.04 pulito, con accesso sudo e nessun vincolo particolare di hosting o pannello.