1 03/11/2026 11 min

Su AlmaLinux 8 e Rocky Linux 8 XAMPP si installa senza troppi passaggi, ma vale la pena chiarire subito una cosa: non è il pacchetto più “nativo” per queste distribuzioni. È una stack pronta all’uso pensata per sviluppo e test, quindi comoda quando vuoi Apache, MariaDB/MySQL, PHP e Perl in un colpo solo, ma meno adatta a un server esposto senza un minimo di controllo su porte, permessi e superficie d’attacco.

Se l’obiettivo è lavorare in locale o preparare un ambiente di staging, XAMPP resta una scelta rapida. Se invece vuoi un’installazione da produzione, conviene valutare i pacchetti nativi di AlmaLinux/Rocky o una configurazione separata con repository ufficiali, perché gestire aggiornamenti e hardening è più lineare. Qui però partiamo dal caso pratico: installare XAMPP correttamente, verificare che parta e capire dove mettere le mani se qualcosa non torna.

Prerequisiti su AlmaLinux o Rocky 8

Prima di scaricare qualsiasi cosa, controlla di essere su un sistema 64 bit e di avere privilegi amministrativi. XAMPP per Linux è distribuito come installer grafico o come pacchetto eseguibile da terminale, quindi la procedura è semplice, ma conviene preparare il terreno: spazio disco sufficiente, SELinux da gestire in modo consapevole e nessun servizio già in ascolto sulle porte classiche di Apache o MySQL, se vuoi evitare conflitti.

Le porte più importanti da tenere d’occhio sono 80, 443 e 3306. Se Apache di sistema o MariaDB sono già attivi, XAMPP può partire lo stesso in alcuni casi, ma spesso si scontra con binding già occupati. Per un ambiente pulito, conviene sapere in anticipo cosa sta ascoltando.

Una verifica rapida aiuta a capire subito se ci sono conflitti:

sudo ss -ltnp | egrep ':(80|443|3306)\s'

Se il comando non restituisce nulla, le porte sono libere. Se invece vedi processi come httpd o mariadbd, dovrai decidere se fermarli o cambiare configurazione. Il rollback, in questo caso, è banale: riavviare i servizi originali se decidi di tornare indietro.

Scaricare il pacchetto corretto di XAMPP

Il modo più sicuro è prendere il pacchetto direttamente dal sito ufficiale di Apache Friends. Per Linux viene fornito un installer con estensione .run. Non serve aggiungere repository esterni, e questo è un vantaggio: sai esattamente cosa stai installando e da dove arriva il file.

Scarica il pacchetto nella tua home o in una directory temporanea dedicata, poi verifica che il file sia presente e abbia dimensioni plausibili. Se lavori in team, conviene tenere il file in un archivio interno o in una cartella condivisa con checksum verificato, così eviti di ridistribuire versioni diverse senza accorgertene.

Un flusso essenziale può essere questo:

cd /tmp
wget https://www.apachefriends.org/xampp-files/<versione>/xampp-linux-x64-<versione>-installer.run
ls -lh xampp-linux-x64-<versione>-installer.run

La parte <versione> va sostituita con quella effettiva disponibile sul sito ufficiale. Se preferisci il download via browser, nessun problema: l’importante è che il file sia integro e che tu sappia dove l’hai salvato.

Rendere eseguibile l’installer e avviare l’installazione

Il file .run va reso eseguibile prima dell’avvio. Questo è il punto in cui molti inciampano, perché il pacchetto viene scaricato correttamente ma non parte con il doppio clic o con l’esecuzione diretta da shell.

chmod +x xampp-linux-x64-<versione>-installer.run
sudo ./xampp-linux-x64-<versione>-installer.run

Se stai usando un desktop con ambiente grafico, l’installer può aprirsi come procedura guidata. Da terminale, invece, avrai comunque il controllo dei passaggi. In entrambi i casi, l’installazione finisce di norma in /opt/lampp, che è il percorso standard di XAMPP su Linux.

Qui c’è il primo dettaglio utile da tenere a mente: XAMPP non si installa come i pacchetti RPM classici di AlmaLinux e Rocky. Quindi non cercare i binari in /usr/sbin o i file di configurazione nella struttura tipica del sistema. La sua root è /opt/lampp, e da lì gestisci servizi, log e configurazioni.

Struttura delle directory di XAMPP

Dopo l’installazione, conviene orientarsi subito nella gerarchia dei file. È una delle cose più importanti per evitare modifiche fatte nel posto sbagliato. I percorsi più usati sono questi:

  • /opt/lampp/htdocs per i file web pubblici
  • /opt/lampp/etc/httpd.conf per la configurazione principale di Apache
  • /opt/lampp/etc/php.ini per la configurazione di PHP
  • /opt/lampp/var/mysql per i dati del database
  • /opt/lampp/logs per i log di Apache e degli altri componenti

Se devi intervenire sulla configurazione, fai sempre una copia prima di modificare. Un semplice diff ti evita ore di ricerca quando una direttiva rompe l’avvio del servizio.

sudo cp /opt/lampp/etc/httpd.conf /opt/lampp/etc/httpd.conf.bak
sudo cp /opt/lampp/etc/php.ini /opt/lampp/etc/php.ini.bak

Rollback minimo: ripristinare il file originale e riavviare XAMPP. È un’operazione semplice, ma va sempre prevista prima di toccare configurazioni di base.

Avvio, arresto e stato dei servizi

Una volta installato, XAMPP si gestisce con lo script lampp. I comandi fondamentali sono pochi e vanno memorizzati subito, perché sono quelli che userai per capire se tutto è davvero operativo.

sudo /opt/lampp/lampp start
sudo /opt/lampp/lampp stop
sudo /opt/lampp/lampp restart
sudo /opt/lampp/lampp status

Se l’avvio va a buon fine, dovresti vedere messaggi che indicano l’attivazione di Apache e del database. Se invece uno dei servizi non parte, il comando status è il primo punto da controllare, perché ti dice subito quale componente è fermo.

Un controllo pratico dal browser è aprire http://localhost/ sul server stesso oppure l’IP della macchina, se stai lavorando da remoto. La pagina iniziale di XAMPP è il riscontro immediato che Apache sta servendo contenuti dalla directory corretta.

Se non risponde, non partire subito a modificare file a caso: prima verifica il processo, poi i log.

Verificare Apache, PHP e database con controlli rapidi

La verifica migliore è quella che separa i tre livelli: web server, interprete PHP e database. In questo modo capisci subito se il problema è di rete locale, di configurazione o di runtime.

Per Apache, controlla che la porta sia in ascolto:

sudo ss -ltnp | grep ':80 '

Per PHP, crea un file di test in /opt/lampp/htdocs:

echo '<?php phpinfo(); ?>' | sudo tee /opt/lampp/htdocs/info.php > /dev/null

Aprendo http://localhost/info.php dovresti vedere la pagina informativa di PHP. Se invece scarica il file o mostra il sorgente, il problema è nella gestione del modulo PHP da parte di Apache.

Per MySQL/MariaDB, il controllo minimo è il socket o la porta. Se XAMPP ha avviato correttamente il database, la porta 3306 dovrebbe risultare occupata dal processo interno di XAMPP, non da quello di sistema.

Gestire conflitti con Apache o MariaDB di sistema

Su AlmaLinux e Rocky 8 è comune trovare già installati httpd o mariadb-server. Questo non è un errore, ma può creare conflitti diretti con XAMPP. Se vuoi usare XAMPP come stack principale, devi evitare doppie istanze sulla stessa porta.

Il modo più pulito è fermare i servizi di sistema che entrano in conflitto e disabilitarli solo se sai che non ti servono in avvio automatico. Prima controlla lo stato, poi decidi.

sudo systemctl status httpd mariadb

Se risultano attivi e vuoi liberarli, fermali con cautela:

sudo systemctl stop httpd mariadb

Rollback: riavviare i servizi di sistema con systemctl start httpd mariadb se decidi di tornare alla stack nativa. È una strada reversibile e va preferita rispetto a cambiamenti permanenti finché non hai scelto l’architettura definitiva.

In alternativa, se vuoi tenere entrambi gli stack installati, puoi cambiare le porte di XAMPP modificando la configurazione di Apache in /opt/lampp/etc/httpd.conf e, se necessario, quella del database. È una soluzione valida, ma richiede attenzione perché cambia gli URL e i client collegati.

SELinux su AlmaLinux e Rocky 8: cosa aspettarsi

Qui serve realismo: SELinux può interferire con alcune operazioni di XAMPP, soprattutto se provi a servire contenuti da percorsi non standard o se modifichi permessi in modo troppo permissivo. Non è una buona idea spegnerlo alla cieca. Prima capisci se il blocco è davvero SELinux e non un problema di porta, file o permessi.

Il controllo rapido è questo:

sestatus

Se SELinux è Enforcing e qualcosa non funziona, cerca i denial nei log di audit. Il file tipico è /var/log/audit/audit.log. Una verifica utile è filtrare gli eventi recenti legati ad Apache o a XAMPP.

sudo ausearch -m avc -ts recent

Se emergono blocchi reali, la correzione corretta non è disattivare SELinux in modo permanente, ma applicare il contesto giusto o definire una policy mirata. Se sei in fase di test rapido, puoi temporaneamente passare a Permissive, ma solo sapendo che stai abbassando il livello di protezione e che il rollback consiste nel riportarlo a Enforcing.

Permessi dei file web e cartella htdocs

La directory /opt/lampp/htdocs è il punto in cui metti i file del sito o dell’applicazione. Qui il problema più comune non è XAMPP in sé, ma i permessi: file troppo chiusi, proprietario sbagliato o contenuti caricati con un utente diverso da quello che serve.

Per sviluppo locale, una configurazione semplice e leggibile è mantenere i file accessibili al tuo utente e assicurarti che Apache possa leggerli. Se invece lavori in team, conviene definire un gruppo condiviso e una policy coerente, invece di fare chmod 777, che è la scorciatoia peggiore in assoluto.

Un controllo di base può essere questo:

ls -ld /opt/lampp/htdocs
ls -l /opt/lampp/htdocs

Se il contenuto non è leggibile da Apache, il sintomo tipico è una pagina bianca, un errore 403 o il download del file PHP invece dell’esecuzione. In quel caso, la prima verifica non è il codice applicativo ma i permessi e i log di Apache.

Log da controllare quando qualcosa non parte

Quando XAMPP non si avvia o una pagina non risponde, i log sono la fonte primaria. L’errore vero quasi sempre è già scritto lì, spesso in modo più chiaro di qualsiasi messaggio a schermo.

I file più utili sono:

  • /opt/lampp/logs/error_log per Apache
  • /opt/lampp/logs/access_log per le richieste HTTP
  • /opt/lampp/var/mysql/*.err per gli errori del database

Un controllo immediato può essere questo:

sudo tail -n 50 /opt/lampp/logs/error_log
sudo tail -n 50 /opt/lampp/var/mysql/*.err

Se trovi errori del tipo “address already in use”, il problema è quasi sempre un conflitto di porte. Se invece vedi errori su file mancanti o permessi negati, il punto da correggere è la configurazione o il filesystem, non XAMPP in sé.

Avvio automatico e integrazione con systemd

XAMPP non si integra con systemd come i servizi nativi della distribuzione. Questo significa che, di default, non hai la stessa gestione automatica al boot che avresti con httpd o mariadb. Per ambienti di laboratorio va bene così; per ambienti più strutturati, devi decidere se vuoi un avvio automatico e come gestirlo in modo controllato.

Se vuoi automatizzare, la via più pulita è creare un’unità systemd dedicata che richiami lo script di XAMPP. È una modifica reversibile, ma va testata con attenzione perché introduce dipendenze di boot e possibili ritardi se il filesystem o la rete non sono pronti al momento giusto.

In genere conviene prima validare manualmente il comportamento con start e stop, poi decidere se formalizzare l’avvio automatico. Se non hai un’esigenza precisa, il controllo manuale resta più trasparente e meno fragile.

Quando XAMPP non è la scelta giusta

Vale la pena dirlo senza giri di parole: XAMPP è comodo, ma non è la soluzione ideale per ogni server Linux. Se stai costruendo un’infrastruttura da produzione, vuoi aggiornamenti granulari, logging integrato con il sistema, hardening più fine e una gestione dei servizi coerente con la distro. In quel caso, installare Apache, PHP e MariaDB dai repository ufficiali o dai repository mantenuti dal vendor è spesso la strada più pulita.

XAMPP ha senso quando vuoi una piattaforma pronta da avviare, magari per sviluppo, demo, test di applicazioni legacy o ambienti didattici. Il vantaggio è la velocità; il compromesso è che devi accettare una struttura un po’ separata dal resto del sistema e gestire tu alcune scelte operative.

Checklist finale di verifica

Prima di considerare conclusa l’installazione, passa questa sequenza minima:

  1. Verifica che /opt/lampp esista e che l’installer sia terminato senza errori.
  2. Lancia sudo /opt/lampp/lampp status e controlla che Apache e il database risultino attivi.
  3. Apri http://localhost/ e conferma che la pagina di XAMPP risponda.
  4. Crea un file PHP di test in /opt/lampp/htdocs e verifica l’esecuzione.
  5. Controlla i log in /opt/lampp/logs/error_log se qualcosa non torna.
  6. Conferma che nessun servizio di sistema stia occupando le stesse porte, oppure documenta il conflitto e la scelta fatta.

Assunzione operativa: ambiente di test o sviluppo su AlmaLinux/Rocky 8, con installazione XAMPP eseguita come stack separata in /opt/lampp e con eventuali conflitti di porta risolti prima dell’uso quotidiano.