… configurato via ldap.
Nagios è una nota applicazione open source per il monitoraggio di computer e risorse di rete. La sua funzione base è quella di controllare nodi, reti e servizi specificati, avvertendo quando questi non garantiscono il loro servizio o quando ritornano attivi. Il tutto abitualmente è gestito attraverso una pletora di files di configurazione che definiscono tutti gli oggetti che servono alla configurazione di questo prodotto.
Gli oggetti definiti sono:
- command: definizione dei comandi per la scansione di qualunque cosa
- contact: i contatti ai quali bussare se qualcosa va male
- timeperiods: intervalli di tempo nei quali un servizio (o una notifica) è attivo [1]
- host: ovvero il server che viene monitorato
- hostgroup: sono un raggruppamento mnemonico dei server. In realtà via Ldap non si possono usare
- service: sono i servizi che vengono monitorati: per esempio webserver, db server, dns ecc..
- servicegroup: sono un raggruppamento mnemonico dei servizi. In realtà via Ldap non si possono usare
La configurazione via file di testo è abbastanza scomoda, soprattutto se ci sono una fila di amministratori che devono gestirla e la cosa è in rapido divenire: una macchina che viene spenta intenzionalmente senza che venga tolta dal controllo Nagios, rischia di generare una serie di alert inutili e quindi di fare correre persone ecc. ecc.
Inoltre se si vogliono, per ridondanza, mettere più di un server Nagios, ogni modifica va replicata su tutte le macchine. Se si abbina alla cosa la possibile concorrenza delle modifiche si capisce come il mix rischi di diventare esplosivo.
La soluzione ldap, “regala” senza troppa fatica, una configurazione in un singolo punto, concorrenza nelle modifiche, consistenza con il resto dell’infrastruttura.
Questa soluzione è stata implementata da un personaggio che ha un sito dal nome buffo, e che ha provato (a quanto ho capito) a committare il tutto nel master branch, in realtà senza riuscirci. Nel post qui sopra, ci sono gli rpm che ha creato con il binario, la patch da applicare e un po’ di altre amenità.
Fortunatamente il mio server di monitoraggio (che poi è il mio desktop) era una macchina Fedora, quindi i due file RPM (quello di Nagios in sé e quello dell’interfaccia web) si sono installati senza il minimo problema.
Riavviato il server web (e risolti alcuni problemini alla configurazione e all’autenticazione), alla pagina http://localhost/nagios/ rispondeva allegramente l’interfaccia, che monitora di default localhost.
In generale per riavviare il servizio Nagios, si usa il comando
service nagios restart
Prima del riavvio è bene controllare la configurazione utilizzando il comando
nagios -v /etc/nagios/nagios.cfg
A questo punto, nel file /etc/nagios/nagios.cfg si commenta la riga
cfg_file=/etc/nagios/objects/localhost.cfg
e si aggiunge la riga che chiama l’albero ldap dove sono messi tutti gli oggetti.
ldap_server=ldap://ldap.localnet/name=Nagios,o=Qccv
Il comando di controllo della configurazione si lamenterà che non è possibile aggiungere nessun servizio, e quindi uscirà con errore.
A questo punto bisogna mettere host e servizi dentro LDAP.
Si introduce un nuovo concetto (che è implicito nella configurazione testuale) ovvero quello di monitorGroup.
Un monitorGroup è sostanzialmente un server di monitoraggio. Serve per mantenere in un solo ldap i dati di più server di monitoraggio. L’oggetto LDAP deve avere objectClass monitorgroup e deve contenere nell’attributo monitorFQDN l’hostname completo del server di monitoraggio.
Per come la cosa è costruita, il programma scandaglia un sottoramo dell’albero, cercando tutti gli oggetti che rispondono alle caratteristiche di host, di service e di monitorGroup.
Gli host sono definiti con queste classi e questi attributi:
- objectClass monitorHost
da compilare cn, ipHostNumber, relativeDomainName, uguali a quelli sopra. Inoltre è da compilare il campo monitorGroup, con il nome completo di percorso del monitorGroup (o dei monitorGroup) che monitorizzano l’host. Inoltre qua si riscrive la descrizione, e il template che l’host estende. - objectClass top
più una structural class, che può essere Host, ipHost, o qualcos’altro (da testare. La structural class in generale può essere quella della struttura preesistente).
I servizi invece sono così definiti:
- objectClass monitoredService
obbligatori cn, hostName (o una lista di hostName) e monitorGroup. Ovviamente utili check-command e nagius-use, che è il template di servizio. check-command è opzionale perchè potrebbe essere già definito nel template. È invece obbligatoria la descrizione. Senza questa il servizio non viene riconosciuto. - objectClass top
Se tutto funziona al riavvio del servizio (service nagios restart, come root) oppure al controllo dei file di configurazione (nagios -v /etc/nagios/nagios.cfg) vengono rilevati i host e servizi relativi al monitorGroup sul quale stiamo lavorando.
A questo punto c’è solo da sbizzarrirsi: la definizione di host e servizi diventa un gioco, centralizzato, replicabile, protetto contro le modifiche concorrenti, integrabile con la infrastruttura ldap esistente.
[1] utile per esempio se il sistemista si può allertare via sms, pager o mail in orari diversi