Come installare lo stack LAMP su Debian 10 -- TrgtKLS • Tech, Sicurezza e Strumenti & guide per Webmaster

1 1 visite 12/05/2026 Pubblicato il: 12/05/2026 20:00 Tempo di lettura: 11 min

Debian 10 e stack LAMP: scelta delle versioni e ordine corretto

Su Debian 10 lo stack LAMP classico resta una base solida per siti PHP tradizionali, pannelli hosting leggeri e applicazioni interne. La regola pratica è semplice: prima il web server, poi il database, infine PHP e l’integrazione tra i tre. Saltare l’ordine non rompe tutto, ma complica la diagnosi quando qualcosa non risponde come previsto.

Qui l’obiettivo non è “installare pacchetti e basta”, ma arrivare a un’installazione verificabile: servizio attivo, modulo PHP agganciato ad Apache, database accessibile solo dove serve e test finale con una pagina PHP che dimostri il flusso end-to-end.

Debian 10 usa versioni stabili ma non recentissime. Questo è utile in produzione quando la priorità è la compatibilità, non l’ultimo rilascio. Se ti serve una versione più nuova di PHP, la strada cambia e va pianificata a parte; qui resto sul percorso nativo della distribuzione, che è quello meno rumoroso e più facile da mantenere.

Preparazione del sistema: aggiornamento, hostname e accesso root controllato

Prima di installare qualsiasi componente, conviene partire da un sistema aggiornato e con accesso amministrativo chiaro. Se lavori da remoto, evita di fare tutto in una sessione fragile: meglio avere una shell stabile, sudo funzionante e un secondo accesso pronto nel caso in cui una modifica di rete o firewall ti tagli fuori.

La prima verifica utile è capire lo stato del sistema e applicare gli aggiornamenti di sicurezza disponibili.

sudo apt update
sudo apt upgrade -y
sudo reboot

Dopo il reboot, controlla che il nome host sia coerente con la macchina che stai preparando, soprattutto se prevedi certificati TLS o virtual host multipli.

hostnamectl
ip a
sudo timedatectl status

Il controllo dell’orario non è cosmetico: se poi aggiungi TLS, replica database o log centralizzati, un orologio fuori fase crea errori che sembrano casuali e invece sono banalmente temporali.

Installazione di Apache: il front-end HTTP del server

Apache su Debian 10 si installa in modo diretto. Il punto non è il pacchetto in sé, ma verificare subito che il demone parta, che ascolti sulla porta giusta e che il firewall non lo blocchi.

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

Il controllo minimo è una risposta HTTP locale. Se la macchina è raggiungibile in rete, prova sia da localhost sia dall’esterno, perché un servizio “up” ma non esposto è un falso positivo molto comune.

curl -I http://127.0.0.1/
curl -I http://IP_DEL_SERVER/

Se il secondo comando fallisce ma il primo no, il problema è quasi sempre a livello di rete locale, firewall o security group. In Debian, se usi UFW, abilita almeno il traffico HTTP e, se previsto, HTTPS.

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

In alternativa, se non usi UFW, verifica le regole nftables o il firewall del provider. Non dare per scontato che “Apache non funzioni” quando il problema è il layer di rete davanti.

MariaDB: database locale, password e hardening minimo

Per uno stack LAMP classico su Debian 10, MariaDB è la scelta naturale. L’installazione è rapida, ma la parte importante è la messa in sicurezza iniziale: rimozione di accessi inutili, password amministrativa, database di test e account anonimi.

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

A questo punto esegui la procedura di hardening interattiva. Non è un rituale da ignorare: imposta le basi corrette prima di mettere qualunque applicazione sopra il database.

sudo mysql_secure_installation

Durante la procedura, le scelte ragionevoli per un host web standard sono: password forte per l’account amministrativo, rimozione degli utenti anonimi, disabilitazione del login remoto per root e rimozione del database di test. Se l’applicazione dovrà connettersi da un altro host, non aprire MariaDB a tutta la rete per comodità: crea un utente dedicato e limita l’origine IP.

Verifica il servizio con una connessione locale e controlla che il socket sia attivo.

sudo mysql -e 'SELECT VERSION();'
sudo ss -ltnp | grep 3306

Se il socket non compare, il problema va cercato nei log del servizio e nello stato del processo, non nel PHP. Su Debian il punto di partenza resta sempre il journal di systemd.

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

Per un uso web standard, conviene anche assicurarsi che MariaDB ascolti solo su localhost. In molti casi è già il comportamento predefinito, ma vale la pena verificare il parametro di bind prima di esporre il database senza motivo.

grep -R "^bind-address" /etc/mysql/

Se trovi un bind su 0.0.0.0 e non ti serve l’accesso remoto, correggilo nel file di configurazione appropriato e riavvia il servizio. Il blast radius qui è limitato al database, ma il rollback deve essere immediato: backup del file prima della modifica e riavvio solo dopo il controllo della sintassi.

PHP su Debian 10: modulo Apache e pacchetti essenziali

Il pezzo che più spesso crea confusione è PHP: installarlo non basta, va agganciato al web server. Su Debian 10 il percorso più lineare è usare il modulo Apache con PHP della repository ufficiale della distribuzione.

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

Il pacchetto `php-mysql` abilita l’integrazione con MariaDB/MySQL, mentre gli altri moduli coprono casi comuni: HTTP client, immagini, stringhe multibyte, XML e archivi compressi. Non installare tutto “per sicurezza” se non serve: ogni estensione in più è superficie di manutenzione e, in certi casi, di attacco.

Controlla quale versione di PHP hai effettivamente installato e quali moduli sono caricati.

php -v
php -m | sort

Se Apache usa il modulo PHP, il test più semplice è creare una pagina temporanea con `phpinfo()`. Va rimossa subito dopo la verifica, perché espone dettagli sensibili dell’ambiente.

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

Poi apri il file dal browser o con curl. Se il contenuto viene scaricato come testo, PHP non è agganciato al server; se vedi la pagina generata, il collegamento funziona.

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

Quando la verifica è conclusa, elimina il file di test.

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

Se preferisci usare PHP-FPM invece del modulo Apache, il discorso cambia: serve la configurazione del proxy verso il socket FPM e una gestione diversa dei pool. Su Debian 10 il modulo Apache resta però il cammino più breve per uno stack LAMP semplice e leggibile.

Test end-to-end: la pagina PHP che parla con MariaDB

Una volta che Apache, MariaDB e PHP sono attivi, il test serio non è solo “PHP gira”, ma “PHP parla con il database”. Questo è il punto in cui molte installazioni apparentemente sane mostrano l’errore vero: credenziali sbagliate, privilegi mancanti o socket non raggiungibile.

Crea un database e un utente dedicati all’applicazione. Non usare root dal codice, neppure in laboratorio, perché poi il modello mentale sbagliato tende a restare anche quando l’ambiente diventa produttivo.

sudo mysql

CREATE DATABASE appdb;
CREATE USER 'appuser'@'localhost' IDENTIFIED BY 'PASSWORD_FORTE';
GRANT ALL PRIVILEGES ON appdb.* TO 'appuser'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Se vuoi verificare la connessione da PHP, usa un file minimo e rimuovilo appena finito. Non lasciare credenziali in chiaro oltre il tempo strettamente necessario, e se il file serve solo per test locale tienilo fuori dal document root appena puoi.

cat <<'PHP' | sudo tee /var/www/html/dbtest.php
<?php
$mysqli = new mysqli('localhost', 'appuser', 'PASSWORD_FORTE', 'appdb');
if ($mysqli->connect_error) {
    http_response_code(500);
    die('DB error: ' . $mysqli->connect_error);
}
echo 'DB OK';
PHP

Apri la pagina e verifica che risponda con `DB OK`. Se fallisce, controlla prima il log di Apache e poi la sintassi del file PHP. Spesso l’errore è banale: virgolette, password errata o permessi utente non allineati.

curl -s http://127.0.0.1/dbtest.php
sudo tail -n 50 /var/log/apache2/error.log

Quando il test è passato, elimina il file e ruota eventuali credenziali usate solo per la prova, se sono state esposte in un contesto condiviso.

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

Permessi, document root e struttura dei virtual host

Un errore tipico nelle installazioni rapide è confondere i permessi del web server con i permessi di sviluppo. Apache deve leggere i file, non possederli tutti con privilegi eccessivi. Se stai servendo una sola applicazione, conviene già impostare una struttura pulita per virtual host e document root dedicata.

Per un sito singolo, crea una directory separata invece di usare sempre `/var/www/html`. È una scelta piccola che semplifica molto quando arrivano più host o più ambienti.

sudo mkdir -p /var/www/example.local/public_html
sudo chown -R www-data:www-data /var/www/example.local
sudo chmod -R 750 /var/www/example.local

Un file di virtual host minimale può essere questo. Adatta `ServerName` al tuo dominio o hostname interno.

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

    <Directory /var/www/example.local/public_html>
        Options -Indexes +FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/example.local_error.log
    CustomLog ${APACHE_LOG_DIR}/example.local_access.log combined
</VirtualHost>

Salva il file in `/etc/apache2/sites-available/example.local.conf`, abilitalo e ricarica Apache. Il controllo finale deve includere sia la configurazione sia l’attivazione del sito.

sudo a2ensite example.local.conf
sudo apache2ctl configtest
sudo systemctl reload apache2

Se usi `.htaccess`, il parametro `AllowOverride All` è necessario, ma non va lasciato aperto senza motivo su directory non controllate. Ogni eccezione alla configurazione standard ha un costo di manutenzione e va giustificata.

Log da leggere davvero: dove guardare quando qualcosa non torna

Quando il sito non risponde o mostra una pagina bianca, la sequenza giusta è sempre la stessa: status dei servizi, log applicativi, log del web server, poi database. Invertire l’ordine porta a perdere tempo in ipotesi premature.

Su Debian 10 i riferimenti più utili sono questi: `journalctl -u apache2`, `journalctl -u mariadb`, `/var/log/apache2/error.log` e, se l’applicazione scrive log propri, il suo percorso specifico. Non serve memorizzare tutto, serve avere il reflex di cercarli prima di cambiare configurazioni a caso.

sudo journalctl -u apache2 --no-pager -n 50
sudo journalctl -u mariadb --no-pager -n 50
sudo tail -n 50 /var/log/apache2/error.log
sudo tail -n 50 /var/log/apache2/access.log

Se vedi errori PHP nel log di Apache, il problema può essere nel codice, nei permessi o in una dipendenza mancante. Se invece Apache risponde ma il browser mostra errore 500, il livello giusto da ispezionare è quasi sempre il log applicativo o quello del virtual host specifico.

Hardening minimo: ridurre esposizione senza complicare l’operatività

Una volta che tutto funziona, fai il minimo indispensabile per non regalare superficie d’attacco. Non è il momento di trasformare il server in una cattedrale di policy, ma è il momento giusto per togliere ciò che non serve.

Disabilita la pagina di test o i file temporanei lasciati in document root.
Verifica che MariaDB non ascolti su interfacce pubbliche se non è richiesto.
Conserva password e credenziali fuori dal codice quando possibile.
Aggiorna il sistema con una finestra regolare, non “quando capita”.
Se esponi il server su Internet, pianifica subito TLS con certificato valido.

Per Apache, l’ordine delle verifiche è: moduli caricati, virtual host attivo, configurazione valida, log puliti. Per il database, è: servizio attivo, socket o porta corretta, account applicativo con privilegi minimi, nessun accesso remoto inutile. Per PHP, è: versione coerente, moduli richiesti, integrazione col web server, nessun file di test rimasto in giro.

Checklist finale per considerare lo stack pronto

Lo stack LAMP su Debian 10 lo puoi considerare pronto quando queste condizioni sono vere contemporaneamente: Apache risponde localmente e dalla rete prevista, MariaDB è attivo e non esposto oltre il necessario, PHP esegue codice lato server e il test applicativo parla con il database senza credenziali hardcoded lasciate in produzione.

Apache: `systemctl is-active apache2` restituisce `active` e `curl -I http://127.0.0.1/` mostra `HTTP/1.1 200 OK` o comunque una risposta valida.
MariaDB: `systemctl is-active mariadb` restituisce `active` e `sudo mysql -e 'SELECT 1;'` funziona in locale.
PHP: `php -v` mostra la versione attesa e una pagina `.php` viene eseguita, non scaricata.
Integrazione: una query semplice da PHP verso MariaDB restituisce esito positivo.
Igiene operativa: file di test rimossi, log controllati, virtual host separato se il server ospita più siti.

Assunzione operativa: ambiente Debian 10 standard, installazione su host singolo, Apache come web server e MariaDB locale, senza proxy esterni o CDN davanti.