Come installare LAMP su Debian passo dopo passo

Su Debian, un LAMP fatto bene non è solo “installare quattro pacchetti”: la differenza la fanno l’ordine delle operazioni, i controlli dopo ogni step e qualche scelta minima di hardening prima di esporre il servizio. Qui parto da una macchina Debian recente, con accesso root o sudo, e assumo che l’obiettivo sia avere Apache, MariaDB e PHP funzionanti su una base pulita, senza introdurre configurazioni fragili o dipendenze inutili.

La sequenza corretta è semplice: aggiorni i repo, installi il web server, prepari il database, aggiungi PHP con il modulo per Apache, poi validi tutto con un file di test e con un controllo reale della catena richiesta. Se salti la verifica a ogni passaggio, il problema emerge dopo, quando hai già più variabili in gioco.

Prerequisiti minimi e assunzioni operative

Prima di toccare i pacchetti, verifica di avere una sessione con privilegi amministrativi e una macchina raggiungibile in rete. Se stai lavorando in produzione, considera ogni modifica come potenzialmente impattante: Apache può prendere la porta 80/443, MariaDB può cambiare stato dei servizi e PHP può alterare il comportamento delle applicazioni già presenti.

Controlla la versione di Debian e lo stato generale del sistema:

cat /etc/debian_version
uname -a
systemctl --failed

Se `systemctl --failed` mostra unità in errore, non ignorarle: un LAMP sano sopra un host già instabile è un falso positivo. In particolare, spazio disco insufficiente, problemi DNS o una rete non coerente possono mandare fuori strada anche un’installazione corretta.

Aggiornamento iniziale e baseline del sistema

La prima operazione è aggiornare gli indici e i pacchetti. Su Debian recente è preferibile partire da un sistema allineato, così eviti di diagnosticare come “problema del LAMP” qualcosa che è solo un mismatch di repository o librerie vecchie.

sudo apt update
sudo apt upgrade -y

Dopo l’aggiornamento, verifica che non siano rimasti pacchetti in stato anomalo:

apt list --upgradable
sudo dpkg --audit

`dpkg --audit` deve tornare vuoto. Se segnala pacchetti semi-configurati, risolvi prima di proseguire: un’installazione LAMP sopra un package manager incoerente tende a produrre errori laterali difficili da leggere.

Installare Apache su Debian e validare il servizio

Per il web server installa Apache con i moduli base necessari. In molti casi basta il pacchetto principale; il resto si aggiunge in base alle esigenze applicative.

sudo apt install -y apache2

Subito dopo verifica stato, porta in ascolto e risposta HTTP locale:

systemctl status apache2 --no-pager
ss -ltnp | grep ':80'
curl -I http://127.0.0.1

Il risultato atteso è un `HTTP/1.1 200 OK` o comunque una risposta valida dal server locale. Se `curl -I` fallisce ma il servizio è “active”, guarda i log:

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

Su Debian, il documento radice predefinito è di solito in `var/www/html`, e la pagina standard di Apache serve come prima conferma che il vhost di default è operativo. Non considerarlo un traguardo finale: è solo il test della catena minima tra processo, porta e HTTP.

Preparare MariaDB senza lasciare buchi inutili

Per il database, MariaDB è la scelta più lineare su Debian per un LAMP classico. Installa il server e, se ti serve, anche il client per test locali e manutenzione.

sudo apt install -y mariadb-server mariadb-client

Controlla subito che il servizio sia attivo e che il socket sia presente:

systemctl status mariadb --no-pager
ss -ltnp | grep ':3306'
sudo mariadb -e 'SELECT VERSION();'

Se il comando SQL risponde con la versione, il database è raggiungibile localmente. A questo punto esegui il minimo hardening disponibile sul sistema, senza inventare policy strane: rimuovi utenti anonimi, disabilita login remoto per root e togli il database di test se presente.

sudo mariadb-secure-installation

Le domande del wizard vanno lette con attenzione. In generale, per un server standard, ha senso impostare una password forte per l’account amministrativo del database, rimuovere accessi anonimi e disabilitare il test database. Se l’applicazione richiede accesso remoto, non aprirlo a tutta la rete: limita gli host autorizzati e usa firewall e privilegi DB minimi.

Se vuoi verificare lo stato delle tabelle e del motore, usa un controllo rapido:

sudo mariadb-check --all-databases

Un errore qui non significa automaticamente corruzione, ma merita attenzione prima di caricare un’applicazione sopra il database.

Installare PHP con supporto Apache

Per un LAMP classico su Debian, la combinazione più semplice è PHP con il modulo Apache. Se non hai esigenze specifiche, parte da lì; se poi ti serve PHP-FPM, lo aggiungi come evoluzione, non come complicazione iniziale.

sudo apt install -y php libapache2-mod-php php-mysql

Il pacchetto `php-mysql` serve per l’integrazione con MariaDB/MySQL. Dopo l’installazione, controlla la versione e verifica che Apache carichi il modulo PHP:

php -v
apache2ctl -M | grep php

Se `apache2ctl -M` non mostra il modulo PHP, non andare a tentoni: verifica quali moduli sono abilitati e se il pacchetto è installato correttamente.

ls /etc/apache2/mods-enabled/ | grep php
sudo a2query -m php*

Su alcune versioni e scenari può essere più pulito usare `php-fpm` invece del modulo Apache, soprattutto se ospiti più siti o vuoi separare meglio il runtime. Ma per la guida base, il modulo integrato è il percorso con meno attrito e meno punti di rottura iniziali.

Creare il test PHP e verificare l’intera catena

Il test più utile non è un file HTML statico: è una pagina PHP che confermi parsing, esecuzione e integrazione con il server web. Crea un file temporaneo nella document root.

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

Ora apri la pagina dal browser oppure usa curl:

curl -I http://127.0.0.1/info.php
curl -s http://127.0.0.1/info.php | head

Se vedi l’output di `phpinfo()`, la catena Apache-PHP funziona. Se il browser mostra download del file invece di eseguirlo, il modulo PHP non è agganciato correttamente al vhost o al server globale. Se ottieni 500, guarda prima i log di Apache e poi quelli PHP se presenti.

journalctl -u apache2 -n 100 --no-pager
sudo tail -n 100 /var/log/apache2/error.log

Dopo il test, elimina il file. Lasciare `phpinfo()` esposto è un errore classico: espone dettagli utili su moduli, percorsi e configurazione dell’ambiente.

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

Permessi, document root e principio del minimo privilegio

Una delle cause più frequenti di problemi su LAMP non è il software, ma i permessi sbagliati. La regola pratica è semplice: il web server deve leggere ciò che serve e scrivere solo dove l’applicazione richiede davvero scrittura. Non dare ownership totale a `www-data` se non hai una ragione concreta.

Controlla la proprietà dei file nella document root:

namei -l /var/www/html
ls -ld /var/www/html

Per applicazioni reali, separa codice e dati scrivibili. Un esempio tipico è tenere i sorgenti in sola lettura e concedere scrittura solo a directory come `uploads`, `cache` o `tmp`, secondo i requisiti del software. Se devi correggere permessi, fallo in modo mirato e documentato, non con un `chmod -R 777` che crea più problemi di quanti ne risolva.

Configurazione base di Apache: vhost, moduli e log

Appena il stack base è su, conviene passare da sito di default a virtual host dedicato. Anche su un singolo dominio, avere un file di configurazione separato ti rende la gestione più pulita e il rollback più semplice.

Un vhost minimale può essere strutturato così:

<VirtualHost *:80> ServerName esempio.local DocumentRoot /var/www/esempio <Directory /var/www/esempio> AllowOverride All Require all granted </Directory> ErrorLog ${APACHE_LOG_DIR}/esempio_error.log CustomLog ${APACHE_LOG_DIR}/esempio_access.log combined
</VirtualHost>

Salva il file, abilita il sito e ricarica Apache:

sudo mkdir -p /var/www/esempio
sudo a2ensite esempio.conf
sudo apache2ctl configtest
sudo systemctl reload apache2

Il comando `apache2ctl configtest` deve rispondere `Syntax OK`. Se fallisce, non ricaricare il servizio: correggi prima la sintassi. Questo è uno dei pochi casi in cui la disciplina evita downtime inutile.

Firewall e esposizione rete: apri solo ciò che serve

Se il server è esposto in rete, verifica che il firewall non stia bloccando la porta 80 o 443. Su Debian potresti usare `ufw`, `nftables` o regole di infrastruttura esterna. Non dare per scontato che “Apache è su” significhi “il sito è raggiungibile”.

sudo ss -ltnp | egrep ':80|:443'
sudo ufw status verbose

Se usi UFW, abilita solo le porte necessarie:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw status numbered

Per MariaDB, in un LAMP base non aprire la 3306 verso l’esterno se non c’è un requisito esplicito. In caso contrario, la superficie d’attacco cresce senza benefici reali. Se il database deve essere raggiunto da host remoti, restringi l’origine con regole firewall e con grant SQL specifici per host, non con accessi ampi.

Hardening minimo che vale il costo

Una volta funzionante il stack, applica solo le misure che hanno rapporto favorevole tra rischio e beneficio. Aggiornamenti regolari, rimozione della pagina di test, log leggibili e permessi corretti sono il minimo sindacale. Se il server è pubblico, aggiungi anche HTTPS con certificato valido, ma quella è una fase successiva rispetto all’installazione base.

Controlla che Apache non esponga informazioni inutili:

apache2ctl -M
apache2ctl -V

Se vuoi ridurre il fingerprinting, puoi lavorare sui banner e sui moduli non necessari, ma fallo con cognizione: nascondere versioni non sostituisce patching e non mitiga vulnerabilità reali. L’obiettivo è ridurre rumore e superficie, non simulare sicurezza.

Per PHP, il passo più utile è verificare il file di configurazione attivo e capire quali limiti sono stati ereditati:

php --ini
php -i | egrep 'Loaded Configuration File|memory_limit|upload_max_filesize|max_execution_time'

Se l’applicazione ha requisiti diversi, modifica il file corretto, non uno a caso. In caso di dubbio, il risultato di `php --ini` ti dice esattamente quale configurazione è in uso.

Check finale: cosa deve funzionare prima di considerare chiuso il lavoro

Una installazione LAMP su Debian non è “finita” quando i pacchetti sono installati. È finita quando questi controlli passano senza ambiguità: Apache risponde localmente, il vhost è attivo, PHP viene eseguito, MariaDB accetta connessioni locali, i log non mostrano errori ricorrenti e il file di test è stato rimosso.

systemctl is-active apache2 mariadb
curl -I http://127.0.0.1
sudo mariadb -e 'SELECT 1;'
apache2ctl configtest

Se tutto è verde, hai una base LAMP pulita e ragionevolmente sicura per iniziare a deployare un sito o un’app PHP. Da qui in poi la differenza la fanno l’applicazione, il tuning e la gestione operativa: backup, monitoraggio, aggiornamenti e test di restore. Se uno di questi punti manca, il rischio non è più nell’installazione, ma nella manutenzione.

Assunzione operativa: Debian recente con systemd, Apache come web server, MariaDB come database locale e PHP gestito via modulo Apache per semplicità iniziale.