Come installare Open Web Analytics su Ubuntu e CentOS

Open Web Analytics: scelta dello stack e prerequisiti

Open Web Analytics funziona bene in un classico stack LAMP, quindi Apache o Nginx davanti, PHP lato applicazione e MySQL o MariaDB come backend. Su Ubuntu e CentOS la differenza reale non è tanto nel software, quanto nei nomi dei pacchetti, nel path della configurazione e nel modo in cui il servizio web espone PHP. Se l’obiettivo è avere un’installazione stabile, conviene partire da una base pulita: sistema aggiornato, web server già funzionante, database locale o remoto, e un dominio o sottodominio dedicato.

Prima di toccare i pacchetti, verifica tre cose: versione di PHP compatibile con la release che vuoi installare, estensioni PHP richieste, e spazio disco sufficiente per log, cache e archivio eventi. OWA non è pesante come una suite analytics enterprise, ma può crescere in fretta se tracci parecchio traffico.

Ubuntu: installazione dei pacchetti base

Su Ubuntu il percorso più lineare è installare Apache, MariaDB e PHP con le estensioni comuni. Se usi una release recente, il comando sotto è un buon punto di partenza.

sudo apt update
sudo apt install apache2 mariadb-server php libapache2-mod-php php-mysql php-curl php-gd php-xml php-mbstring php-zip php-intl unzip wget

Se il tuo ambiente usa Nginx invece di Apache, il principio non cambia, ma dovrai aggiungere PHP-FPM e adattare il virtual host. Per questa guida resto su Apache perché riduce i punti di attrito durante la prima installazione.

CentOS: pacchetti equivalenti e repository

Su CentOS il nome dei pacchetti cambia, e spesso cambia anche il repository da cui arrivano le versioni PHP più aggiornate. Su sistemi basati su CentOS Stream o compatibili RHEL-like, il flusso tipico è installare Apache, MariaDB e PHP con i moduli richiesti. Se il repository di default offre una versione di PHP troppo vecchia rispetto ai requisiti di OWA, valuta Remi o il repository aziendale approvato.

sudo dnf install httpd mariadb-server php php-mysqlnd php-curl php-gd php-xml php-mbstring php-zip php-intl unzip wget

Su versioni più vecchie, il comando può diventare yum al posto di dnf. La logica operativa resta identica.

Database: creare utente e schema senza esporre privilegi inutili

OWA richiede un database dedicato. Non usare l’account root del database nell’applicazione: crea uno schema separato e un utente con permessi limitati a quel solo schema. È una misura banale, ma in caso di compromissione riduce il danno.

sudo mysql

CREATE DATABASE owa CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'owauser'@'localhost' IDENTIFIED BY 'CAMBIA_QUESTA_PASSWORD';
GRANT ALL PRIVILEGES ON owa.* TO 'owauser'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Se il database è remoto, sostituisci localhost con l’IP o il range autorizzato e limita l’accesso a livello firewall. Evita di aprire MariaDB su tutte le interfacce senza una ragione precisa.

Scaricare Open Web Analytics e posizionarlo nel web root

Il codice va estratto in una directory servita dal web server, ad esempio /var/www/owa. In un ambiente ordinato conviene tenere separati codice applicativo e document root del virtual host, così sai sempre dove intervenire in caso di update.

cd /tmp
wget https://github.com/Open-Web-Analytics/Open-Web-Analytics/archive/refs/heads/master.zip -O owa.zip
unzip owa.zip
sudo mkdir -p /var/www/owa
sudo rsync -a Open-Web-Analytics-master/ /var/www/owa/

Il link del progetto può cambiare nel tempo, quindi se il repository principale viene riorganizzato conviene verificare il path ufficiale e sostituire l’URL. Questo è uno dei rari casi in cui il controllo preliminare evita più tempo perso del download stesso.

Permessi corretti per Apache e PHP

Una parte delle installazioni fallisce non per OWA, ma per permessi sbagliati sulla directory. L’utente del web server deve leggere i file dell’applicazione e scrivere solo dove serve davvero, ad esempio cache o upload. Non dare ownership completa a www-data o apache sull’intera tree se non è necessario.

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

Se OWA richiede una directory scrivibile, individuala nella documentazione della release o nei messaggi dell’installer e assegna solo quella porzione al gruppo del web server. Se non lo fai, il rischio è di aprire troppo la superficie di scrittura.

Virtual host Apache su Ubuntu

Su Ubuntu puoi creare un virtual host dedicato in /etc/apache2/sites-available/owa.conf. La configurazione tipica punta alla directory dell’applicazione e abilita il sito con a2ensite.

<VirtualHost *:80>
    ServerName analytics.example.com
    DocumentRoot /var/www/owa

    <Directory /var/www/owa>
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/owa_error.log
    CustomLog ${APACHE_LOG_DIR}/owa_access.log combined
</VirtualHost>

Dopo aver salvato il file, abilita il sito e il modulo rewrite se serve. Molte applicazioni PHP storiche si appoggiano a AllowOverride All, quindi non togliere quella direttiva a meno che tu non abbia verificato che OWA non la usi.

sudo a2enmod rewrite
sudo a2ensite owa.conf
sudo apache2ctl configtest
sudo systemctl reload apache2

Virtual host Apache su CentOS

Su CentOS il file del virtual host va di solito in /etc/httpd/conf.d/owa.conf. La sintassi è simile, ma il servizio da ricaricare è httpd e non apache2.

<VirtualHost *:80>
    ServerName analytics.example.com
    DocumentRoot /var/www/owa

    <Directory /var/www/owa>
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog logs/owa_error.log
    CustomLog logs/owa_access.log combined
</VirtualHost>

sudo apachectl configtest
sudo systemctl enable --now httpd
sudo systemctl reload httpd

Se SELinux è attivo, può bloccare lettura o scrittura anche quando i permessi Unix sembrano corretti. In quel caso il problema non è il virtual host, ma il contesto di sicurezza.

SELinux: il dettaglio che rompe molte installazioni su CentOS

Con SELinux in enforcing, Apache può avere accesso limitato alle directory fuori dai percorsi standard o ai socket del database. Prima di disabilitarlo, controlla i log di audit e correggi il contesto. Disattivarlo “per provare” è spesso la scorciatoia che poi resta in produzione, e non è una buona idea.

sudo ausearch -m avc -ts recent
sudo grep AVC /var/log/audit/audit.log | tail -n 20

Se il problema è l’accesso a file web, un contesto coerente può essere la soluzione. Il comando esatto dipende dalla tua policy, ma il controllo minimo è verificare che il contenuto servito da Apache abbia il contesto corretto. Se devi aprire eccezioni, documentale e limita il perimetro al solo path necessario.

Configurazione iniziale via browser

Con web server, PHP e database pronti, apri il dominio nel browser. L’installer di OWA ti chiederà i dati del database, il nome del sito, un account amministrativo e parametri base dell’applicazione. Qui l’errore più comune è inserire credenziali non testate prima, oppure puntare al database sbagliato.

Compila i campi con attenzione e, se disponibile, salva temporaneamente i valori in un file di note protetto o in un password manager aziendale. Non lasciare password nel testo della documentazione operativa né in uno script condiviso.

Verifiche lato PHP prima di accusare l’applicazione

Quando l’installer non parte o mostra una pagina bianca, il colpevole è spesso PHP e non OWA. Controlla la versione effettiva, le estensioni caricate e gli errori nel log del web server. Un check rapido evita di inseguire il problema nel codice sbagliato.

php -v
php -m | egrep 'curl|gd|xml|mbstring|mysqli|zip|intl'
sudo tail -n 50 /var/log/apache2/error.log
sudo tail -n 50 /var/log/httpd/error_log

Su Ubuntu, se usi PHP-FPM, il log può stare in un path diverso e il web server può mostrare solo l’errore generico. In quel caso controlla anche il log del pool FPM. Il punto non è avere “più log”, ma trovare il primo errore utile.

Hardening minimo dopo l’installazione

Dopo aver completato l’installazione, fai un minimo di hardening. Serve poco, ma serve. Metti HTTPS, limita l’accesso all’area amministrativa se possibile, aggiorna le password di default, e verifica che il database non sia esposto all’esterno senza motivo. Una piattaforma analytics raccoglie dati e quindi vale quanto un altro servizio sensibile dal punto di vista privacy.

Se hai un reverse proxy o un CDN davanti, controlla che gli header vengano preservati correttamente. Altrimenti rischi di registrare IP errati, user agent incompleti o schemi HTTP/HTTPS sbagliati. Per un sistema di analytics è un difetto funzionale, non solo estetico.

HTTPS con certificato valido

Per la parte TLS puoi usare un certificato del tuo CA interno o una soluzione pubblica come Let’s Encrypt. L’importante è non rimandare: se l’installazione vive in chiaro, anche solo per test, poi spesso resta così.

sudo certbot --apache -d analytics.example.com

Se il server è dietro bilanciatore o proxy, la terminazione TLS potrebbe stare altrove. In quel caso il certificato non si installa sul nodo applicativo, ma sul layer corretto della catena.

Controlli finali: cosa deve funzionare davvero

Dopo la configurazione, non limitarti a vedere la home page. Fai una verifica funzionale minima: la pagina deve caricare, l’installer deve scrivere nel database, il pannello deve autenticare un utente e i log non devono mostrare errori ripetuti. Se vuoi essere più rigoroso, genera una visita di test e verifica che l’evento compaia nei report o nel database.

curl -I https://analytics.example.com
sudo systemctl status apache2
sudo systemctl status httpd

Se curl -I restituisce un 200 o un 302 atteso, il layer HTTP è vivo. Se invece hai 500, torna ai log. Se hai timeout, guarda prima DNS, firewall e virtual host. Se il sito risponde ma l’installer fallisce, il problema è quasi sempre applicativo o di database.

Problemi tipici e lettura rapida del sintomo

Una pagina bianca indica spesso errore PHP con display disabilitato. Un errore 500 suggerisce configurazione, permessi o estensioni mancanti. Un redirect infinito fa pensare a HTTPS mal gestito o a un base URL incoerente. Se il login funziona ma i dati non vengono raccolti, controlla il tag di tracking, il blocco lato browser e l’eventuale filtro del proxy.

Quando il database è lento, i report sembrano “vuoti” anche se i dati arrivano. Non scambiare una latenza alta per assenza di dati. In un sistema analytics la metrica da guardare non è solo uptime, ma anche tempo di risposta delle query e ritardo nella disponibilità dei report.

Upgrade e manutenzione senza perdere i dati

Prima di aggiornare OWA, fai backup del codice, del database e della configurazione web. Il ripristino deve essere semplice: file applicativi da una parte, dump SQL dall’altra. Se il sito è in produzione, testa l’upgrade in staging con una copia del database, altrimenti scopri i problemi quando gli utenti li vedono già.

mysqldump -u owauser -p owa > owa-backup.sql
sudo tar -czf owa-files-backup.tar.gz /var/www/owa

Per il rollback, conserva la versione precedente del codice e il dump precedente allo schema migration. Se l’aggiornamento tocca anche le tabelle, il rollback senza backup del database è solo teoria.

Conclusione operativa: installazione pulita, meno sorprese

Installare Open Web Analytics su Ubuntu o CentOS non è complicato, ma va fatto con metodo: pacchetti corretti, database dedicato, permessi stretti, virtual host pulito, controlli PHP e una verifica finale che non si fermi alla sola pagina di benvenuto. Se tratti l’installazione come un servizio da mettere in produzione e non come una demo da far partire in fretta, eviti la maggior parte dei problemi che poi consumano tempo in troubleshooting.

Assunzione: ambiente Linux recente con Apache e MariaDB/MySQL locali; se usi Nginx, PHP-FPM o database remoto, adatta i path e i servizi da verificare.