Come installare Observium su Ubuntu 20.04 -- TrgtKLS • Tech, Sicurezza e Strumenti & guide per Webmaster

1 1 visite 22/04/2026 Pubblicato il: 22/04/2026 13:59 Tempo di lettura: 11 min

Perché Observium va installato con criterio su Ubuntu 20.04

Observium non è solo un pannello grafico per SNMP: è un sistema di raccolta, normalizzazione e visualizzazione che vive di dipendenze precise. Su Ubuntu 20.04 funziona bene, ma la differenza tra un’installazione pulita e una piena di problemi sta quasi sempre nei dettagli: PHP con i moduli giusti, database dimensionato in modo sensato, cron attivo e permessi coerenti. Se salti uno di questi punti, l’interfaccia può anche aprirsi, ma i grafici restano vuoti o i dispositivi non vengono scoperti come dovrebbero.

Qui conviene ragionare come in un cambio controllato: prima prepari il sistema, poi installi il codice, poi colleghi il database e infine attivi i job periodici. Il risultato atteso è semplice: accesso web funzionante, login operativo, discovery SNMP attiva e cron che alimenta i dati senza errori nei log.

Prerequisiti reali: cosa serve prima di iniziare

Prima di toccare il server, verifica di avere una macchina Ubuntu 20.04 aggiornata, un nome host risolvibile, accesso sudo e un database MySQL o MariaDB locale o remoto. Observium richiede anche un server web e PHP compatibile. Su 20.04 la strada più lineare è Apache con PHP-FPM oppure Apache con mod_php, ma per ridurre attriti conviene restare su un’installazione classica LAMP ben chiusa.

Per SNMP lato dispositivi, il software non fa magie: se router, switch, server o firewall non espongono community o credenziali corrette, l’interfaccia resterà bella ma inutile. La parte Observium si installa sul server; la parte di monitoraggio vero si sblocca solo quando gli endpoint SNMP rispondono.

Se vuoi tenere il blast radius sotto controllo, crea un utente dedicato e lavora in una directory dedicata. Evita di usare account amministrativi per l’applicazione e non mettere segreti in chiaro dentro script improvvisati: meglio file di configurazione protetti e permessi stretti.

Pacchetti da installare su Ubuntu 20.04

Parti dall’aggiornamento del sistema e installa i pacchetti base. I nomi possono variare leggermente in base alla variante di PHP scelta, ma la lista seguente copre il caso più comune.

sudo apt update
sudo apt -y upgrade
sudo apt install -y apache2 mariadb-server mariadb-client \
  php php-cli php-common php-mysql php-gd php-snmp php-curl php-xml \
  php-mbstring php-zip php-bcmath php-opcache graphviz fping rrdtool \
  snmp snmpd unzip git

Il punto critico qui non è la quantità dei pacchetti, ma la presenza di quelli che Observium usa davvero: rrdtool per le serie storiche, snmp per interrogare i device, fping per i controlli di reachability e i moduli PHP per parlare con database e grafici. Se uno di questi manca, il problema si vede quasi sempre nei log applicativi o nelle pagine che segnalano componenti non disponibili.

Scaricare Observium e preparare la directory corretta

Observium pubblica una versione Community e una commercial. Per una guida di installazione su Ubuntu 20.04, la logica non cambia: scarichi il pacchetto appropriato, lo estrai in una directory sotto controllo e assegni il proprietario al servizio web. Usa una path pulita, ad esempio /opt/observium, così separi l’applicazione dal resto del filesystem e semplifichi backup e manutenzione.

sudo mkdir -p /opt/observium
cd /opt/observium
sudo wget https://www.observium.org/observium-community-latest.tar.gz
sudo tar zxvf observium-community-latest.tar.gz
sudo chown -R www-data:www-data /opt/observium

Se l’URL del pacchetto cambia o il download richiede autenticazione, non forzare con mirror casuali: chiudi il gap consultando la pagina di rilascio ufficiale e verificando checksum o istruzioni correnti. Una source sbagliata qui significa installare codice vecchio o incompleto, con problemi difficili da distinguere da un bug applicativo.

Database: schema, utente e privilegi minimi

Observium usa un database MySQL/MariaDB per la parte relazionale: utenti, dispositivi, metadati, configurazione e stato applicativo. Le serie storiche restano nei file RRD, quindi il database non va trattato come un archivio di telemetria grezza, ma come il catalogo dell’intero sistema. Questo aiuta anche a dimensionarlo: non serve esagerare con RAM o storage solo per il DB, ma serve affidabilità.

sudo mysql -u root -p

CREATE DATABASE observium DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'observium'@'localhost' IDENTIFIED BY 'PASSWORD_FORTE';
GRANT ALL PRIVILEGES ON observium.* TO 'observium'@'localhost';
FLUSH PRIVILEGES;
EXIT;

La password va generata e conservata in un secret manager o in un file protetto; non lasciarla in chiaro in una nota operativa condivisa. Se il database è remoto, restringi l’host di origine e verifica il firewall: Observium deve parlare col DB, ma non per questo il servizio MySQL va esposto a tutto il mondo.

Configurazione principale di Observium

La configurazione base vive nel file /opt/observium/config.php. Qui definisci il database, l’URL esterno e alcuni parametri di funzionamento. Il file è anche il punto giusto per fissare la community SNMP di default, se stai facendo un setup di laboratorio o una prima importazione controllata.

sudo cp /opt/observium/config.php.default /opt/observium/config.php
sudo nano /opt/observium/config.php

$config['db_host'] = 'localhost';
$config['db_user'] = 'observium';
$config['db_pass'] = 'PASSWORD_FORTE';
$config['db_name'] = 'observium';
$config['base_url'] = 'http://monitoring.example.local/';

Se usi HTTPS dietro reverse proxy o CDN, imposta subito l’URL corretto. Un base URL sbagliato non rompe tutto, ma genera redirect incoerenti, asset caricati male e link interni che puntano al protocollo sbagliato. È il classico difetto che sembra minore finché non inizi a usare la GUI in modo serio.

Per i dispositivi SNMP, aggiungi almeno un default community solo se sai esattamente cosa stai facendo. In ambienti reali è meglio definire credenziali per gruppi di device e non affidarsi a una community unica per tutto. La sicurezza non è un extra: SNMP v2c con community debole è un’esposizione evitabile.

Import del database iniziale e setup dell’utente amministratore

Observium include uno script di installazione che crea le tabelle necessarie e prepara l’ambiente. Eseguilo una sola volta, quando il database è pronto e la configurazione punta al posto giusto. Se lo lanci con credenziali errate o su un DB già popolato, rischi di sporcare la baseline e confondere i controlli successivi.

cd /opt/observium
sudo ./discovery.php -u

In molte installazioni il comando di bootstrap viene affiancato dalla creazione dell’utente admin. Se il pacchetto o la versione che stai usando prevede uno script dedicato, verifica la sintassi nel file README della release. Non inventare opzioni: su strumenti di monitoring, una flag sbagliata può generare stato incoerente e perdere tempo in diagnosi inutili.

Apache: virtual host e document root

Su Ubuntu 20.04, Apache è la scelta più lineare per pubblicare l’interfaccia web. Definisci un virtual host dedicato e punta la document root alla directory web di Observium. In genere si usa /opt/observium/html/ come root del sito.

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

<VirtualHost *:80>
    ServerName monitoring.example.local
    DocumentRoot /opt/observium/html/

    <Directory /opt/observium/html/>
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/observium-error.log
    CustomLog ${APACHE_LOG_DIR}/observium-access.log combined
</VirtualHost>

Attiva il sito e i moduli necessari, poi ricarica il servizio. Se usi PHP-FPM, aggiungi la parte di proxy FastCGI secondo la tua configurazione standard; se resti su mod_php, verifica che la versione PHP sia coerente con i moduli installati. Il sintomo classico di mismatch è una pagina bianca o errori 500 con riferimenti a funzioni PHP mancanti.

sudo a2enmod rewrite headers
sudo a2ensite observium.conf
sudo systemctl reload apache2

PHP: impostazioni che evitano falsi problemi

Observium non ama configurazioni PHP tirate all’osso. Su 20.04 conviene alzare i limiti in modo ragionevole, specialmente se prevedi molti dispositivi o grafici complessi. I parametri più utili sono memoria, tempo massimo di esecuzione e timezone.

sudo nano /etc/php/7.4/apache2/php.ini

memory_limit = 256M
max_execution_time = 300
date.timezone = Europe/Rome

Dopo la modifica, ricarica Apache o PHP-FPM in base allo stack scelto. Se la UI mostra warning su PHP memory o su moduli assenti, controlla anche il log errori di Apache e il file log dell’applicazione. Non è raro che il problema vero sia un modulo mancante e non il valore del limite.

Cron: il pezzo che fa davvero vivere Observium

Molti installano Observium e si fermano alla pagina di login. In realtà, senza cron, il sistema resta quasi fermo. Discovery, poller, housekeeping e update dei dati dipendono dai job schedulati. Questo è il punto in cui un’installazione “funzionante” diventa un sistema di monitoraggio utile.

Observium fornisce uno script di cron da integrare nel sistema. Il modo più pulito è usare la crontab dell’utente dedicato o un file in /etc/cron.d/ con permessi corretti. La seconda opzione è spesso più chiara per manutenzione e audit.

sudo cp /opt/observium/misc/observium.cron /etc/cron.d/observium
sudo chmod 644 /etc/cron.d/observium

Verifica che gli script puntino ai path giusti e che l’utente abbia accesso in scrittura alle directory RRD e ai log. Se il cron gira ma i grafici non si aggiornano, il problema spesso è un permesso sbagliato su /opt/observium/rrd/ o su una directory di lock. In quel caso il falso positivo è pericoloso: la GUI sembra viva, ma i dati non cambiano.

SNMP sui dispositivi: senza questo Observium non raccoglie nulla

Il server è pronto, ma i device devono rispondere in SNMP. Su Linux puoi testare il lato Observium con un semplice snmpwalk. Se non ottieni risposte, il problema non è la GUI: è la connettività, la community, il firewall o la configurazione SNMP del dispositivo.

snmpwalk -v2c -c COMMUNITY 192.0.2.10 sysName.0

Il risultato atteso è una risposta coerente con il nome del device. Se ricevi timeout, controlla ACL, UDP/161, community e versione SNMP. Su apparati moderni può essere preferibile SNMPv3, soprattutto in reti dove la community in chiaro è un rischio operativo non accettabile.

Verifica finale dell’installazione

A questo punto l’obiettivo è confermare tre cose: il sito risponde, il database è collegato e il polling produce dati. Non basta vedere la home page. Devi verificare il comportamento end-to-end.

Apri http://monitoring.example.local/ e controlla che la pagina di login sia raggiungibile senza errori 500 o redirect anomali.
Controlla i log Apache in /var/log/apache2/observium-error.log e /var/log/apache2/observium-access.log per eventuali errori PHP o permessi.
Verifica che il database risponda con il database name corretto e che lo stato dell’app mostri dispositivi o almeno nessun errore di connessione al DB.
Lancia un test SNMP su un dispositivo noto e conferma che la discovery lo veda.
Controlla il cron con grep o con i log di sistema se i job non partono.

sudo tail -n 50 /var/log/apache2/observium-error.log
sudo grep -i observium /var/log/syslog | tail -n 50

Se la pagina si apre ma non compare nessun dato, il problema di solito è uno tra questi: cron non eseguito, permessi sbagliati sulle directory RRD, SNMP non raggiungibile o configurazione DB incompleta. L’ordine giusto di diagnosi è sempre quello: prima osservi i log, poi verifichi il layer di rete, solo dopo ritocchi la config.

Hardening minimo sensato

Observium espone dati di rete e inventario. Non è un componente da lasciare in chiaro e aperto senza controlli. Il minimo sindacale è HTTPS, restrizione dell’accesso amministrativo, aggiornamenti regolari e segreti protetti. Se il pannello è raggiungibile da Internet, almeno limita l’accesso a IP fidati o passa da VPN.

Per HTTPS puoi usare un certificato Let’s Encrypt o un certificato interno, a seconda del contesto. Se il server è dietro un reverse proxy, assicurati che Observium veda correttamente lo schema esterno. Un mismatch HTTP/HTTPS qui non è solo estetico: può rompere login, redirect e cookie di sessione.

Infine, separa i permessi: il web server deve leggere il codice e scrivere solo dove serve. Le directory di log e RRD devono essere scrivibili dal processo applicativo, ma il resto no. Questo riduce il danno in caso di exploit o configurazione errata.

Problemi tipici e come leggerli senza perdere tempo

Se la pagina è bianca, il primo sospetto è PHP: modulo mancante, memory limit basso o errore di sintassi nel file di config. Se vedi timeout nei grafici, controlla RRD e cron. Se i device non compaiono, il problema è quasi sempre SNMP o firewall. Se il login funziona ma i link interni fanno redirect strani, il base URL è probabilmente sbagliato.

Una buona abitudine è tenere sempre sotto mano tre punti di osservazione: il log web, il log applicativo e l’esito di un snmpwalk su un device noto. Con questi tre artefatti, nella maggior parte dei casi capisci in pochi minuti se il guasto è nel server, nella rete o nell’endpoint monitorato.

Assunzione: la procedura è stata eseguita su Ubuntu 20.04 con Apache e MariaDB locali; se usi Nginx, PHP-FPM separato o database remoto, vanno adattati virtual host, socket PHP e ACL di rete.