Installare e configurare Nagios 4 su Ubuntu 22.04

Su Ubuntu 22.04 la strada più pulita per Nagios 4 resta quella classica: pacchetti di sistema per dipendenze e web server, compilazione del core dai sorgenti, poi integrazione con Apache e plugin. È una scelta sensata quando vuoi controllo preciso su versioni, percorsi e permessi, senza dipendere da pacchetti vecchi o incompleti. Qui l’obiettivo è arrivare a un’installazione funzionante, verificabile e abbastanza solida da stare in produzione senza sorprese inutili.

Prima di toccare il sistema conviene chiarire il perimetro: Nagios Core non fa magie, non sostituisce metriche o log centralizzati e non risolve problemi di osservabilità da solo. Fa bene una cosa precisa: controllare host e servizi, avvisare quando qualcosa esce dai limiti e permettere una catena di escalation chiara. Se il tuo ambiente ha già Prometheus, Zabbix o una piattaforma SaaS di monitoring, Nagios ha ancora senso se ti serve compatibilità con plugin esistenti, logica di check molto personalizzata o una UI storica che il team sa già usare.

Architettura minima: cosa installi davvero

Una installazione Nagios 4 standard su Ubuntu 22.04 include questi pezzi:

• nagios core: demone principale, scheduler, configurazioni, stato e notifiche.
• nagios plugins: i controlli veri e propri, come ping, HTTP, disk, load, SMTP e così via.
• Apache + CGI: interfaccia web e comandi CGI per la gestione operativa.
• utente e gruppo dedicati: isolamento dei permessi, soprattutto su file di stato e log.

La parte importante è la separazione dei ruoli: Nagios esegue i check, Apache espone la UI, i plugin fanno la diagnostica, e i permessi devono consentire tutto questo senza aprire scritture inutili sul filesystem. Se questa base è sbagliata, i sintomi tipici sono pagine web vuote, permessi negati nei log o service check che restano in pending.

Prerequisiti e pacchetti di sistema

Parti aggiornando il sistema e installando le dipendenze necessarie per compilare Nagios e farlo dialogare con Apache. I pacchetti sotto sono un buon baseline per Ubuntu 22.04:

sudo apt update && sudo apt -y upgrade

sudo apt install -y autoconf gcc libc6 make wget unzip apache2 php libapache2-mod-php libgd-dev libmcrypt-dev libssl-dev bc gawk dc build-essential libnet-snmp-perl gettext

Per i plugin standard conviene installare anche i tool di base che userai nei check più comuni:

sudo apt install -y monitoring-plugins monitoring-plugins-basic monitoring-plugins-standard

Se il repository Ubuntu non offre il metapacchetto esatto nel tuo mirror o lo vuoi evitare per non mescolare troppo, il punto pratico è che ti servono comunque i binari dei plugin più usati. In quel caso li compilerai insieme a Nagios o li installerai come pacchetti separati. La verifica minima, dopo l’installazione, è che i comandi esistano in /usr/lib/nagios/plugins/ o nel path equivalente del sistema.

Utenti, gruppi e directory di lavoro

Prima di compilare, crea utente e gruppo dedicati. Questo evita di dover correggere permessi a posteriori su file di runtime, log e command pipe.

sudo useradd nagios

sudo groupadd nagcmd

Su molte guide il gruppo di comando viene chiamato nagcmd e l’idea resta valida: Apache deve poter inviare comandi a Nagios tramite la coda dei comandi, ma senza diventare proprietario dei file. Aggiungi l’utente web al gruppo di comando:

sudo usermod -a -G nagcmd www-data

Qui la verifica è banale ma importante: id www-data deve mostrare il gruppo aggiunto. Se non compare, il login di Apache verso la CGI di Nagios fallirà o la UI ti mostrerà errori di autorizzazione.

Scaricare e compilare Nagios Core 4

Per mantenere il controllo sulla versione, scarica Nagios Core dai sorgenti ufficiali. Al momento, i passaggi classici restano stabili anche su Ubuntu 22.04.

cd /tmp

wget https://assets.nagios.com/downloads/nagioscore/releases/nagios-4.4.14.tar.gz

tar xzf nagios-4.4.14.tar.gz

cd nagios-4.4.14

Nota pratica: la versione può cambiare, ma il flusso di compilazione resta simile. Se usi un tarball diverso, verifica sempre il changelog e le dipendenze richieste. Non dare per scontato che una release più recente mantenga gli stessi path o i medesimi comportamenti CGI.

./configure --with-command-group=nagcmd

make all

Se ./configure si ferma, il punto da guardare è quasi sempre il pacchetto mancante o una libreria di sviluppo assente. In particolare libgd-dev, libssl-dev e gli strumenti di compilazione sono i candidati più frequenti. La verifica utile è il log dell’output di configure, non il messaggio sintetico finale.

Installazione dei binari, CGI e configurazioni base

Dopo la compilazione, installa i componenti principali con i target del Makefile:

sudo make install

sudo make install-commandmode

sudo make install-config

sudo make install-init

Il primo installa i binari e i file principali, il secondo imposta i permessi per i comandi esterni, il terzo copia i file di configurazione di esempio, il quarto installa lo script di avvio compatibile con systemd o init, a seconda di come il pacchetto lo espone. Su Ubuntu 22.04, poi, systemd è il riferimento operativo: il servizio va controllato con systemctl, non con vecchi comandi SysV.

A questo punto esistono di norma i file in /usr/local/nagios/, mentre le configurazioni principali stanno in /usr/local/nagios/etc/. Il file più importante per la tua prima verifica è /usr/local/nagios/etc/nagios.cfg. Se non sai da dove parte il motore, lì trovi i path dei file di oggetti, i log e i parametri di runtime.

Installare e configurare Nagios Plugins

Il core da solo non basta: senza plugin i check non fanno nulla di utile. Scarica i plugin standard compatibili con la tua release. La logica è la stessa: compilazione, installazione, verifica del path.

cd /tmp

wget https://github.com/nagios-plugins/nagios-plugins/releases/download/release-2.4.11/nagios-plugins-2.4.11.tar.gz

tar xzf nagios-plugins-2.4.11.tar.gz

cd nagios-plugins-2.4.11

./configure --with-nagios-user=nagios --with-nagios-group=nagios

make

sudo make install

La verifica pratica è semplice: ls /usr/local/nagios/libexec/ deve restituire i plugin, ad esempio check_http, check_ping, check_disk. Se il path differisce, annotalo subito perché verrà richiamato nei comandi di test e nella configurazione degli host.

Configurare Apache per la UI di Nagios

La parte web su Ubuntu si appoggia ad Apache. Devi abilitare il sito CGI di Nagios e il modulo auth necessario per proteggere l’accesso. Prima copia il file di configurazione web dal tree di Nagios:

sudo make install-webconf

Se il comando non è disponibile nel tuo tree o la build è stata personalizzata, il file da cercare è comunque un frammento Apache con alias e directory per /nagios e /nagios/cgi-bin. La configurazione tipica usa autenticazione Basic con un file password dedicato.

sudo htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin

Usa una password robusta e trattala come segreto: non salvarla in chiaro in ticket o script condivisi. Se devi ruotarla, rifai il comando e aggiorna solo il valore necessario. Il file /usr/local/nagios/etc/htpasswd.users deve avere permessi stretti.

Abilita i moduli e ricarica Apache se necessario:

sudo a2enmod cgi rewrite ssl

sudo systemctl restart apache2

La verifica giusta qui non è “il servizio è attivo”, ma “la pagina risponde e chiede autenticazione”. Testa localmente:

curl -I http://localhost/nagios/

Atteso: HTTP/1.1 401 Unauthorized o una risposta che mostra la challenge Basic Auth. Se ottieni 404, il sito non è stato configurato; se ottieni 500, guarda i log Apache in /var/log/apache2/error.log e i permessi CGI.

Avvio del servizio e controlli iniziali

Una volta installato, avvia Nagios e controlla lo stato con systemd:

sudo systemctl start nagios

sudo systemctl enable nagios

sudo systemctl status nagios --no-pager

Se il servizio non parte, il log principale è spesso il primo posto da leggere. In installazioni classiche trovi informazioni utili in /usr/local/nagios/var/nagios.log e, in caso di errori CGI o web, nei log Apache. Il pattern da cercare è quasi sempre uno tra: file di configurazione non trovato, permessi insufficienti, comando non valido, oggetto duplicato o plugin assente.

Per validare la sintassi prima del restart, usa il check integrato:

sudo /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

Se il risultato dice che tutto è OK, hai già eliminato una buona fetta di problemi. Se invece trovi errori di oggetti duplicati, file mancanti o direttive errate, correggi prima di riavviare. È un passaggio noioso ma è quello che evita restart inutili e falsi positivi in produzione.

Primo host e primo servizio: un test che vale più della teoria

Per capire se la pipeline funziona davvero, aggiungi un host locale e un check semplice. È il modo più rapido per validare parsing, scheduling, esecuzione plugin e visualizzazione web.

Nel file degli oggetti, ad esempio /usr/local/nagios/etc/objects/localhost.cfg o in un file dedicato incluso da nagios.cfg, puoi definire un servizio HTTP verso localhost. Un esempio minimale:

define service{

    use                 generic-service

    host_name           localhost

    service_description HTTP

    check_command       check_http

}

La verifica minima è che il servizio appaia nella UI e che il risultato del check passi da PENDING a OK. Se resta in pending, guarda la coda dei comandi, i log di Nagios e il path dei plugin. Se va in CRITICAL, il plugin è eseguito ma il target non risponde come previsto.

Hardening minimo: quello che conviene fare subito

Un’installazione funzionante non è automaticamente una buona installazione. Le prime correzioni sensate riguardano accesso, esecuzione e superficie esposta.

1. Limita l’accesso a /nagios a reti amministrative o VPN, se possibile, con regole Apache o firewall. La UI non deve essere esposta “per comodità” su Internet.
2. Controlla i permessi di /usr/local/nagios/etc/htpasswd.users e dei file di configurazione. Devono essere leggibili solo da chi serve davvero.
3. Verifica che il gruppo di comando includa solo gli utenti necessari. www-data è sufficiente per Apache; non aggiungere account umani senza motivo.
4. Se la macchina espone altri servizi, controlla che Nagios non apra porte extra non previste. Il demone ascolta dove serve, non deve diventare una superficie laterale inutile.
5. Regola la retention dei log e dello stato se il monitoraggio copre molti host: file troppo grandi o storage lento si trasformano in latenze e check ritardati.

Qui la metrica da osservare non è solo il “servizio attivo”, ma la qualità del ciclo di check: ritardo di scheduling, numero di check in ritardo, tempi medi di plugin e percentuale di errori. Se il carico cresce, questi numeri ti dicono prima della UI se la piattaforma sta saturando.

Integrazione con notifiche e comandi esterni

Nagios diventa utile quando le notifiche sono affidabili. Il punto non è spedire email a caso, ma avere una catena chiara: stato del servizio, contatto o gruppo contatti, comando di notifica, trasporto. Su ambienti semplici l’email basta; su ambienti strutturati puoi integrare webhook, script o sistemi di ticketing.

La parte delicata è sempre la stessa: evitare script fragili e credenziali sparse. Se usi SMTP autenticato, configura il relay in modo centralizzato e conserva i segreti fuori dai file world-readable. Se usi script personalizzati, verifica che siano eseguibili dall’utente Nagios e che abbiano timeout brevi, altrimenti ti ritrovi notifiche bloccate da un comando esterno lento.

Debug rapido quando qualcosa non torna

Tre controlli risolvono gran parte dei casi reali:

1. Sintassi Nagios: sudo /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg. Se fallisce, non riavviare alla cieca.
2. Log runtime: /usr/local/nagios/var/nagios.log per oggetti, scheduling, check e notifiche; /var/log/apache2/error.log per CGI e autenticazione.
3. Permessi: verifica appartenenza a nagcmd, proprietario dei file e accesso ai plugin in /usr/local/nagios/libexec/.

Se la UI si apre ma non mostra stati aggiornati, il problema non è quasi mai il browser. Di solito è un mismatch tra permessi, coda dei comandi o demone Nagios fermo. Se i check partono ma non arrivano notifiche, il problema è nella definizione dei contact, nei command object o nel trasporto mail.

Ripristino e manutenzione nel tempo

Quando la configurazione funziona, salva subito una copia dei file chiave in un repository o almeno in una directory versionata. I candidati sono /usr/local/nagios/etc/nagios.cfg, i file in /usr/local/nagios/etc/objects/ e il frammento Apache installato da Nagios. Se un domani devi fare un upgrade o correggere un check rotto, il rollback deve essere un semplice ripristino dei file, non una ricostruzione da memoria.

Per la manutenzione ordinaria, la sequenza sensata è questa: aggiornare Ubuntu con finestra controllata, validare che i plugin base funzionino, testare la sintassi Nagios, poi ricaricare il servizio. Se cambi una definizione di check o una notifica, verifica sempre almeno un host non critico prima di estendere la modifica all’intero parco monitorato.

In un ambiente ben tenuto, Nagios non dovrebbe essere il sistema più rumoroso della stack. Se lo diventa, vuol dire che stai usando il monitoraggio per inseguire problemi strutturali: storage lento, DNS interni instabili, target non inventariati bene o soglie troppo aggressive. Meglio correggere la causa che alzare i limiti a caso.

Con questi passaggi hai un’installazione completa di Nagios 4 su Ubuntu 22.04, con UI protetta, plugin operativi, check testabili e un minimo di hardening. Il valore vero non è “averlo installato”, ma averlo reso leggibile, ripetibile e abbastanza pulito da reggere modifiche future senza perdere controllo.