1 15/04/2026 11 min

Installare Icinga2 e Icinga Web 2 su Ubuntu 22.04

Su Ubuntu 22.04 la strada più pulita per Icinga2 e Icinga Web 2 è separare bene i ruoli: Icinga2 per la raccolta e la valutazione degli stati, MariaDB per i dati storici e di configurazione, Apache o Nginx come front-end PHP, Icinga Web 2 come interfaccia. Se si mescolano i passaggi o si salta la parte API, l’installazione sembra “quasi pronta” ma l’interfaccia resta incompleta o non mostra gli oggetti monitorati.

Qui l’obiettivo è arrivare a un’installazione funzionante e verificabile, non a una demo. Prima si prepara il repository ufficiale, poi si installano i pacchetti base, quindi si configura Icinga2, il database e infine la web UI. Ogni blocco ha un controllo immediato, così se qualcosa non torna si capisce subito dove intervenire.

Prerequisiti e scelta dei componenti

Serve un host Ubuntu 22.04 aggiornato, accesso sudo e connettività verso il repository Icinga. In un’installazione standard si usano questi componenti:

  • icinga2: motore di monitoraggio e scheduler.
  • icinga2-ido-mysql: esporta gli stati nel database.
  • mariadb-server: backend SQL per IDO e Icinga Web 2.
  • apache2 + php: front-end web.
  • icingaweb2 e moduli: interfaccia grafica e integrazioni.

Se preferisci Nginx, la logica non cambia, ma qui uso Apache perché riduce i punti di attrito su Ubuntu e rende più lineare la procedura iniziale. In produzione la priorità non è “il web server più elegante”, ma quello che si configura senza ambiguità e con meno variabili.

Aggiungere il repository ufficiale Icinga

Su Ubuntu 22.04 i pacchetti del repository standard spesso non bastano o non sono allineati alle versioni desiderate. Conviene usare il repository ufficiale Icinga per evitare dipendenze vecchie o combinazioni incoerenti.

Installa prima gli strumenti di base e importa la chiave del repository. Il comando sotto è volutamente conservativo: non tocca configurazioni esistenti, aggiunge solo la sorgente pacchetti.

sudo apt update
sudo apt install -y curl gnupg2 ca-certificates lsb-release apt-transport-https
curl -fsSL https://packages.icinga.com/icinga.key | sudo gpg --dearmor -o /usr/share/keyrings/icinga-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/icinga-archive-keyring.gpg] https://packages.icinga.com/ubuntu icinga-$(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/icinga.list
sudo apt update

Verifica subito che il repository venga letto correttamente:

apt-cache policy icinga2 icingaweb2

Se il repository non compare, il problema è quasi sempre nella chiave, nel nome della release o nella connettività HTTPS verso packages.icinga.com. In quel caso non andare avanti: correggi prima la sorgente pacchetti.

Installare Icinga2 e i moduli principali

Una volta attivo il repository, installa il motore e il modulo IDO. L’IDO è il ponte tra Icinga2 e il database relazionale: senza di lui, Icinga Web 2 può essere installata ma non avrà dati storici e oggetti persistenti da interrogare in modo completo.

sudo apt install -y icinga2 icinga2-ido-mysql

Durante l’installazione, il pacchetto può proporre l’attivazione del modulo IDO. Se il prompt non appare o se vuoi controllare manualmente, abilita il modulo dopo l’installazione:

sudo icinga2 feature enable ido-mysql
sudo systemctl restart icinga2

Controlla che il servizio sia attivo e che la feature risulti abilitata:

systemctl status icinga2 --no-pager
icinga2 feature list

Nel caso di errori al riavvio, il primo file da guardare è spesso /var/log/icinga2/icinga2.log. La presenza di errori sul caricamento delle feature o del database indica subito se il problema è nella configurazione o nella connettività verso MariaDB.

Preparare MariaDB per IDO e Icinga Web 2

Il database va creato con utenti separati e privilegi minimi. È un errore comune riutilizzare l’account root di MariaDB dentro l’applicazione: funziona, ma aumenta inutilmente il rischio operativo e complica eventuali audit.

Installa MariaDB e avvialo se non è già presente:

sudo apt install -y mariadb-server
sudo systemctl enable --now mariadb

Crea i database e gli utenti dedicati. Sostituisci le password con valori robusti e non riutilizzati altrove.

sudo mysql -u root -p
CREATE DATABASE icinga2 CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
CREATE USER 'icinga2'@'localhost' IDENTIFIED BY 'PASSWORD_FORTE_1';
GRANT SELECT, INSERT, UPDATE, DELETE, DROP, CREATE VIEW, INDEX, EXECUTE ON icinga2.* TO 'icinga2'@'localhost';

CREATE DATABASE icingaweb2 CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
CREATE USER 'icingaweb2'@'localhost' IDENTIFIED BY 'PASSWORD_FORTE_2';
GRANT ALL PRIVILEGES ON icingaweb2.* TO 'icingaweb2'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Se usi password in chiaro nei comandi interattivi, trattale come temporanee: ruotale dopo il setup o redigi il file di configurazione dove necessario. Per una macchina in produzione è meglio salvare i dati sensibili in file con permessi stretti, non in cronologia shell o ticket.

Importare lo schema IDO

Il pacchetto icinga2-ido-mysql include lo schema SQL. L’importazione va eseguita una sola volta, poi il modulo Icinga2 scriverà nel database in modo continuo.

Prima identifica il file schema, che può cambiare leggermente a seconda della versione del pacchetto:

dpkg -L icinga2-ido-mysql | grep -E 'mysql/schema|ido-mysql.*sql'

Importa lo schema nel database icinga2:

mysql -u root -p icinga2 < /usr/share/icinga2-ido-mysql/schema/mysql.sql

Se il path non coincide, usa l’output del comando precedente per puntare al file corretto. Non forzare percorsi “a memoria”: una differenza di pacchetto può cambiare il nome del file e introdurre errori silenziosi se ci si accorge tardi dell’import fallito.

Configurare la connessione IDO in Icinga2

Ora va scritto il file di connessione al database per il modulo IDO. Su Ubuntu il punto più comodo è /etc/icinga2/features-available/ido-mysql.conf, che viene poi attivato tramite il symlink nella directory features-enabled.

Controlla il contenuto del file e inserisci i parametri corretti:

sudo editor /etc/icinga2/features-available/ido-mysql.conf
object IdoMysqlConnection "ido-mysql" {
  user = "icinga2"
  password = "PASSWORD_FORTE_1"
  host = "localhost"
  database = "icinga2"
}

Attiva la feature e riavvia il servizio:

sudo icinga2 feature enable ido-mysql
sudo systemctl restart icinga2

Verifica che il demone non segnali errori di autenticazione o di schema:

journalctl -u icinga2 -b --no-pager | tail -n 50
mysql -u icinga2 -p -h localhost -e 'SHOW TABLES;' icinga2

Se il servizio parte ma il database resta vuoto, il problema è quasi sempre uno tra password errata, schema non importato o permessi incompleti. La verifica più rapida è leggere gli ultimi log di Icinga2 e fare un test di connessione SQL diretto con lo stesso utente applicativo.

Installare Apache, PHP e Icinga Web 2

Icinga Web 2 richiede PHP e un web server. Su Ubuntu 22.04 la combinazione Apache + PHP-FPM è stabile e ben documentata; qui conviene rimanere sul percorso standard, così i controlli successivi sono prevedibili.

sudo apt install -y apache2 php php-cli php-gd php-intl php-mbstring php-mysql php-curl php-xml php-zip php-fpm icingaweb2 icingacli

Abilita i moduli Apache utili e riavvia il servizio se necessario:

sudo a2enmod rewrite proxy_fcgi setenvif headers ssl
sudo a2enconf php*-fpm
sudo systemctl reload apache2

Il pacchetto icingaweb2 installa i file applicativi, ma la configurazione iniziale avviene tramite web wizard o CLI. Per ridurre gli errori di digitazione, la procedura con browser è spesso la più semplice se il server è appena nato e non c’è ancora un framework di automazione.

Creare il token di setup e il primo utente amministrativo

Icinga Web 2 usa un token di setup temporaneo per autorizzare la configurazione iniziale. Questo evita di esporre un pannello di installazione aperto a chiunque conosca l’URL.

Genera il token e annotalo solo per il tempo necessario al wizard:

sudo icingacli setup token create

Se preferisci gestire la configurazione da shell, puoi predisporre il comando, ma il browser resta il percorso più immediato per una prima installazione. L’importante è non lasciare il token attivo oltre il necessario.

Configurazione web tramite wizard

Apri http://IP_DEL_SERVER/icingaweb2/setup e inserisci il token. Da lì il wizard guida nell’ordine corretto: moduli, prerequisiti PHP, backend di autenticazione, database Icinga Web 2 e backend di monitoraggio.

Nel passaggio sui moduli abilita almeno quelli minimi per operare con Icinga2. In una prima installazione, la scelta pragmatica è:

  • monitoring: modulo principale per gli oggetti e gli stati.
  • incubator: utile per alcuni moduli dipendenti.
  • director: solo se prevedi gestione centralizzata della configurazione, altrimenti rimandalo.

Durante la configurazione del backend di autenticazione crea un utente amministratore locale. Non usare account condivisi: in caso di audit o troubleshooting serve sapere chi ha fatto cosa, e un amministratore nominativo è il minimo sindacale.

Nel passo del database Icinga Web 2 usa l’utente icingaweb2 creato prima. Se il wizard segnala errori di connessione, controlla subito host, password e privilegi. Il database corretto è icingaweb2, non icinga2: è un errore banale ma frequente quando si ripete la procedura a memoria.

Configurare il backend di monitoraggio

Il backend di monitoraggio collega la UI al database IDO. Qui devi indicare il nome della risorsa DB configurata nel wizard o nei file di configurazione. In pratica, Icinga Web 2 deve sapere da dove leggere gli stati di Icinga2.

Se vuoi verificare la configurazione a livello file, i riferimenti principali sono questi:

ls -R /etc/icingaweb2
cat /etc/icingaweb2/resources.ini
cat /etc/icingaweb2/modules/monitoring/backends.ini

La presenza di una risorsa DB valida e di un backend Monitoring coerente è la condizione minima per vedere gli oggetti in UI. Se il login funziona ma la schermata resta vuota, il problema di solito non è Apache: è il backend di monitoraggio o l’IDO non popolato.

Permessi, sicurezza e superficie esposta

Una volta che tutto funziona, conviene chiudere i dettagli che spesso vengono trascurati. Icinga2 espone l’API solo se abilitata; non va lasciata attiva senza motivo su reti non fidate. I file di configurazione con password devono avere permessi stretti e non essere leggibili da utenti non necessari.

Controlla i permessi dei file sensibili:

sudo chmod 640 /etc/icinga2/features-available/ido-mysql.conf
sudo chown root:icinga /etc/icinga2/features-available/ido-mysql.conf
sudo chmod 640 /etc/icingaweb2/resources.ini

Se devi abilitare l’API di Icinga2 per integrazioni future, fallo con un token dedicato e con accesso limitato. Non riusare credenziali amministrative del pannello. La regola pratica è semplice: ogni integrazione ha il suo account, il suo scope e la sua rotazione.

Verifiche finali

A questo punto il sistema deve rispondere su tre livelli: servizio, database e interfaccia. Le verifiche minime sono queste:

systemctl is-active icinga2
systemctl is-active apache2
mysql -u icinga2 -p -h localhost -e 'SELECT COUNT(*) FROM icinga_state;' icinga2
curl -I http://localhost/icingaweb2

L’output atteso è: servizi attivi, query SQL eseguita senza errori, risposta HTTP valida dal front-end. Se curl -I restituisce 200 o 302 verso il login, il lato web è a posto. Se invece il sito risponde ma la dashboard è vuota, torna al backend Monitoring e al modulo IDO.

Un controllo utile è anche leggere gli ultimi eventi del demone:

journalctl -u icinga2 -b --no-pager | tail -n 30

Se compaiono errori di autenticazione verso MariaDB, la soluzione corretta non è riavviare all’infinito: correggi credenziali e privilegi, poi riavvia una sola volta e verifica di nuovo il log. Se invece il problema è lato PHP, i log da leggere sono /var/log/apache2/error.log e, se usi PHP-FPM, il relativo journal del servizio PHP.

Piccolo scenario di test: un host fittizio

Dopo l’installazione conviene creare un test minimo per evitare di scoprire problemi solo quando arriva il primo oggetto reale. Un host fittizio o un semplice ping check permette di validare il flusso end-to-end: configurazione, esecuzione del check, scrittura nell’IDO e visualizzazione in UI.

Se hai già un template base, aggiungi un oggetto semplice e verifica che appaia in Icinga Web 2. In alternativa, usa i comandi di validazione della configurazione di Icinga2 prima di ricaricare il demone:

sudo icinga2 daemon -C

Se la sintassi è valida, il comando termina senza errori bloccanti. È il controllo più economico per evitare di portare in produzione configurazioni rotte, soprattutto quando si iniziano ad aggiungere host, servizi e notifiche.

Nota operativa su backup e rollback

Prima di modificare file in /etc/icinga2 o /etc/icingaweb2, salva una copia dei file toccati o usa un sistema di versioning. Il rollback minimo consiste nel ripristino del file precedente e nel riavvio del servizio interessato. Per il database, il rollback va pianificato con dump SQL, perché le tabelle IDO cambiano continuamente e non è sensato improvvisare su dati già popolati.

Un approccio pratico è questo: prima fai un backup dei file, poi applichi una sola modifica, poi verifichi log e risposta web. Se qualcosa rompe, torni al file precedente e riavvii il solo servizio coinvolto. È il modo più veloce per tenere basso il blast radius.

Quando fermarsi e cosa controllare per primo

Se il wizard non completa la configurazione, se la dashboard mostra errori di backend o se Icinga2 non scrive nel database, non aggiungere componenti a caso. Il primo filtro è sempre lo stesso: stato dei servizi, log recenti, test di connessione al DB e validazione sintattica della configurazione. Solo dopo si passa a moduli aggiuntivi, integrazioni API o tuning del polling.

In un’installazione ben riuscita, Icinga2 deve risultare attivo, l’IDO deve contenere dati, Icinga Web 2 deve aprirsi senza errori e l’utente amministrativo deve poter navigare i menu principali. Se uno di questi quattro punti manca, il problema è quasi sempre localizzabile con pochi comandi e senza toccare il resto della macchina.