Nagios è universalmente considerato il tool di monitoraggio opensource numero uno sulla piazza. La sua duttilità lo rende uno strumento indispensabile per tutti gli amministratori di sistema che si trovano a controllare numeri elevati di macchine e che necessitano di notifiche tempestive a seguito di malfunzionamenti.
Generalmente le notifiche dei guasti avvengono via mail o via sms, ma possono esserci casi in cui questi tipi di notifiche non sortiscano l’effetto desiderato. La soluzione presentata in questo articolo prevede che Nagios attraverso il software opensource di sintesi vocale Festival comunichi a voce quali sono i malfunzionamenti in corso.

Installazione di Festival

Il sistema di riferimento su cui verranno effettuate le prove è Debian Etch. Partiremo dal presupposto che sul sistema utilizzato vi sia una scheda audio correttamente configurata.
Festival è disponibile nei repository ufficiali della distribuzione ed è pertanto installabile attraverso apt-get :

$ apt-get install festival festvox-italp16k festvox-itapc16k

I tre pacchetti installati contengono il programma Festival e le voci italiane (maschile e femminile) da esso utilizzabili.
Per verificare il corretto funzionamento del software (e di conseguenza della scheda audio) è sufficiente lanciare il seguente comando :

$ echo "Ciao mondo" | festival --tts --language italian

Se dagli altoparlanti si sente una voce (un poco metallica per la verità, ma comunque intonata) che recita la frase “Ciao mondo” allora Festival è perfettamente funzionante e si può procedere con la configurazione di Nagios.

Installazione di Nagios

Anche Nagios è presente nei repository della distribuzione Etch ed è installabile quindi con il consueto comando apt-get :

$ apt-get install nagios2 nagios-plugins nagios-images

L’installazione si occupa di creare una configurazione base che comprende i controlli relativi alla macchina locale ed al gateway utilizzato da questa. Per consultare le informazioni relative ai controlli è possibile utilizzare l’interfaccia web che Nagios rende disponibile all’indirizzo http://localhost/nagios2.
Questa interfaccia però richiede un’autenticazione. All’interno della configurazione base creata dal sistema è stato definito un utente denominato nagiosadmin che ha i privilegi di accesso ai controlli di default definiti. A questo utente è quindi sufficiente assegnare una password :

htpasswd -c /etc/nagios2/htpasswd.users nagiosadmin
New password: 
Re-type new password: 
Adding password for user nagiosadmin

attraverso la quale sarà possibile accedere all’interfaccia, che non dovrebbe scostarsi troppo da quella in Figura 1.

Figura 1

Iterazione Nagios – Festival

Il comportamento di Nagios a fronte di controlli, azioni e notifiche è sempre lo stesso, lanciare uno script.
Pertanto il primo passo sarà quello di creare uno script che possa essere utilizzato da Nagios per notificare i malfunzionamenti in una forma interpretabile da Festival.
La filosofia utilizzata in questo senso è la seguente : a fronte di un service o host in stato CRITICAL, verrà creato un file di testo contenente il messaggio che Festival dovrà leggere.
Tale script risiederà nella cartella dei plugin di Nagios, e verrà nominato check_festival_parse :

$ vi /usr/lib/nagios/plugins/check_festival_parse

Lo script sarà così definito :

#!/bin/bash
 
# RaSca (rasca@miamammausalinux.org) - 2009/02/04 :
# Script per l'interpretazione delle notifiche Nagios e l'eventuale creazione
# (o cancellazione) dei file di testo contenente i messaggi.
 
# Primo parametro : il tipo di notifica (host o servizio)
tipo=$1
# Secondo parametro : stato dell'host/servizio
stato=$2
# Terzo parametro : Nome dell'host/servizio
nome=$3
# Path dove depositare i file di testo contenenti le notifiche
file_path="/var/log/nagios2/festival"
 
case "$tipo" in
 host)
  messaggio="ATTENZIONE. ATTENZIONE. L'host $nome e' in stato $stato"
  ;;
 service)
  messaggio="ATTENZIONE. ATTENZIONE. Il servizio $nome e' in stato $stato"
  ;;
 *)
  echo "Errore. Impossibile interpretare i parametri di input."
  exit 1
  ;;
esac
 
if [ "$stato" == "CRITICAL" ]
 then
  echo "$messaggio" > $file_path/festival_$tipo_$nome
 else
  rm -f $file_path/festival_$tipo_$nome
fi

I commenti all’interno sono autoesplicativi, serve solo aggiungere che per funzionare correttamente lo script ha bisogno di tre parametri che sono il tipo di notifica (relativa ad un service o un host), lo stato del servizio o dell’host ed il nome di quest’ultimo.
Viene inoltre definita attraverso la variabile file_path la posizione dei file di testo contenenti le notifiche. Nostro caso, per coerenza, la scelta è quella di creare una directory denominata festival nella directory principale dei log di nagios, /var/log/nagios2/.
Per completare questa fase del progetto è necessario settare i permessi di esecuzione dello script, creare la cartella che ospiterà i file di testo ed assegnare questa all’utente nagios in modo che questo, attraverso il demone, possa scriverci :

$ chmod +x /usr/lib/nagios/plugins/check_festival_parse
$ mkdir /var/log/nagios2/festival
$ chown nagios /var/log/nagios2/festival

Completata la definizione delle notifiche è necessario configurare l’interpretazione delle stesse da parte del sistema. Verrà definito quindi uno script che ciclicamente controllerà l’esistenza di file all’interno della cartella /var/log/nagios2/festival.
Il file si chiamerà semplicemente check_festival e risiederà sempre nella cartella dei plugin di Nagios :

$ vi /usr/lib/nagios/plugins/check_festival

e questo sarà il contenuto :

#!/bin/bash
 
# RaSca (rasca@miamammausalinux.org) - 2009/02/04 :
# Script che legge via TTS le eventuali notifiche presenti nei
# file in $file_path con cicli di 4 volte a distanza di 10 secondi
 
# Path dove leggere i file di testo contenenti le notifiche
file_path="/var/log/nagios2/festival/"
 
for i in `seq 1 4`
do
 for j in `find $file_path -type f`
  do
   cat $j | festival --tts --language italian
  done
 sleep 10s
done

Lo script definisce un ciclo che per quattro volte, a distanza di dieci secondi, controlla l’elenco dei file presenti nella directory /var/log/nagios2/festival/ e legge il contenuto di ciascuno di questi.
Anche questo script necessita dei permessi di esecuzione :

chmod +x /usr/lib/nagios/plugins/check_festival

A completamento di questa fase del progetto è necessario configurare Nagios affinché vengano definite le notifiche. Tutte le configurazioni di Nagios sono presenti nella cartella /etc/nagios2/conf.d/. All’avvio il demone nagios controlla tutti i file contenuti in questo path e ne ricava la propria configurazione.
Creando quindi un nuovo file all’interno di quest’area :

$ vi /etc/nagios2/conf.d/commands_festival

Si potranno definire due nuovi comandi chiamati host-notify-by-festival e notify-by-festival che lanceranno lo script check_festival_parse con i parametri relativi :

define command{
        command_name    host-notify-by-festival
        command_line    /usr/lib/nagios/plugins/check_festival_parse host $HOSTSTATE$ $HOSTNAME$
}
 
define command{
        command_name    notify-by-festival
        command_line    /usr/lib/nagios/plugins/check_festival_parse service $SERVICESTATE$ $SERVICEDESC$
}

Prima di caricare nuovamente la configurazione di Nagios è necessario associare i nuovi comandi alle notifiche dei contatti. Tali informazioni sono contenute nel file /etc/nagios2/conf.d/contacts_nagios2.cfg, all’interno del quale sono presenti le seguenti righe :

        service_notification_commands   notify-by-email
        host_notification_commands      host-notify-by-email

che andranno modificate aggiungendo i comandi sopra definiti :

        service_notification_commands   notify-by-email,notify-by-festival
        host_notification_commands      host-notify-by-email, host-notify-by-festival

Nagios è quindi pronto a caricare nuovamente la configurazione :

$ /etc/init.d/nagios2 reload
Reloading nagios2 monitoring daemon configuration files: nagios2.

L’ultima operazione per il completamento della configurazione del sistema riguarda la definizione all’interno dello schedulatore cron di sistema dell’esecuzione dello script di lettura del contenuto della cartella delle notifiche. In questo caso la definizione è relativa ad ogni minuto, ma è possibile modificarla in base alle proprie necessità :

# Crontab per lettura messaggi Nagios via festival ogni minuto
* *     * * *   root    /usr/lib/nagios/plugins/check_festival

Test di funzionamento

Per effettuare dei test di funzionamento è necessario configurare dei controlli associati ad un host di test. In questo caso la scelta è caduta su di un host di rete denominato test-server all’interno del quale gira un servizio HTTP (un webserver apache).
L’host verrà definito nel file /etc/nagios2/conf.d/test_hosts.cfg :

define host {
        host_name   test-server
        alias       Test server
        address     10.175.88.191
        use         generic-host
        }

Mentre i servizi ad esso associati verranno definiti nel file /etc/nagios2/conf.d/test_services.cfg :

define service {
        host				test-server
        service_description             HTTP
 	check_command                   check_http
        use                             generic-service
	notification_interval           0
}

Chiaramente per far assimilare le modifiche a Nagios è necessario effettuare il reload del servizio :

$ /etc/init.d/nagios2 reload
Reloading nagios2 monitoring daemon configuration files: nagios2.

Una volta che l’host test-server ed il servizio HTTP appariranno nel resoconto web si potranno simulare i malfunzionamenti per i quali ci si aspetta che Nagios parli.
Ad esempio, sospendendo il servizio HTTP sul server di test, una volta che Nagios avrà effettuato i quattro tentativi, definiti Attempt, la notifica verrà inviata dal sistema attraverso il comando notify-by-festival che di conseguenza creerà un file di testo nominato “festival_service_HTTP” contenente il testo “Attenzione. Attenzione. Il servizio HTTP e’ in stato CRITICAL”.
Quanto effettuato dal sistema è visibile dal log di Nagios, /var/log/nagios2/nagios.log :

[1233758032] SERVICE ALERT: test-server;HTTP;CRITICAL;SOFT;1;CRITICAL - Socket timeout after 10 seconds
[1233758092] SERVICE ALERT: test-server;HTTP;CRITICAL;SOFT;2;CRITICAL - Socket timeout after 10 seconds
[1233758152] SERVICE ALERT: test-server;HTTP;CRITICAL;SOFT;3;CRITICAL - Socket timeout after 10 seconds
[1233758212] SERVICE ALERT: test-server;HTTP;CRITICAL;HARD;4;CRITICAL - Socket timeout after 10 seconds
[1233758212] SERVICE NOTIFICATION: root;test-server;HTTP;CRITICAL;notify-by-festival;CRITICAL - Socket timeout after 10 seconds

Tale file sarà letto dallo script definito nel crontab di sistema che darà il via alle letture attraverso Festival.
In conclusione, Nagios dovrebbe parlare.
Una volta ripristinato il servizio HTTP il file verrà automaticamente rimosso sempre dallo script notify-by-festival e di conseguenza Nagios verrà zittito (con soddisfazione).

Conclusioni

E’ evidente che tutto l’impianto può essere personalizzato in modo che l’integrazione con il sistema di controllo avvenga nella maniera più consona possibile. Le potenzialità di una simile implementazione di Nagios sono moltissime ed applicabili ad uno spettro di situazioni altrettanto numerose.

Nello scorso articolo abbiamo visto come configurare ed installare NAGIOS affinché monitori servizi ed emetta notifiche via e-mail in caso di malfunzionamenti. Mentre però i servizi standard sono controllabili da remoto (tramite l’interrogazione di porte TCP), non è possibile ad esempio controllare la capienza del disco di una macchina remota (o i processi in esecuzione su questa o il numero degli utenti loggati) senza lanciare dei processi locali.
Per risolvere questo problema, esiste un programma “extra” creato al di fuori del pacchetto NAGIOS denominato NRPE : Nagios Remote Plugin Executor.

Concetto e requisiti di NRPE

NRPE presenta due componenti, una associata a NAGIOS e cioè il plugin check_nrpe, l’altra associata alla macchina sulla quale si vuole effettuare il controllo e cioè il demone NRPE.
La logica di funzionamento è la seguente : si ha la necessità di lanciare un plugin remoto, viene quindi effettuata la chiamata al plugin locale check_nrpe al quale andrà passato come parametro il nome del plugin remoto da eseguire. “check_nrpe” si collegherà alla macchina remota dove su una determinata porta (generalmente la 5666), sarà in ascolto il demone NRPE che riceverà la richiesta, eseguirà il plugin locale e restituirà l’esito del comando.

Installazione di NRPE

Prima di installare NRPE sulla macchina dove lasceremo il demone in attesa della richiesta di esecuzione di un qualsiasi plugin, sarà necessario installare il pacchetto nagios-plugins (Reperibile all’indirizzo http://prdownloads.sourceforge.net/nagiosplug/nagios-plugins-1.3.1.tar.gz?download), procedendo nella consueta maniera :

$ cd /usr/src
$ tar -xzvf nagios-plugins-1.3.1.tar.gz
$ cd nagios-plugins-1.3.1 
$ ./configure  --prefix=/usr/local/nagios --with-nagios-user=nagios --with-nagios-group=nagios
$ make all
$ make install

Questo perché il demone in se non fa nient’altro che eseguire degli script locali, che non sono presenti nel pacchetto NRPE (La cui grandezza supera di poco i 50 Kilobyte !).
Una volta completata l’installazione di nagios-plugins, troveremo nella directory /usr/local/nagios/libexec tutti i file eseguibili relativi ai plugin di NAGIOS.
A questo punto possiamo procedere con l’installazione vera e propria di NRPE.
Entrambe le componenti (il plugin ed il demone) si trovano nel pacchetto di installazione reperibile a questo indirizzo : http://prdownloads.sourceforge.net/nagios/nrpe-2.0.tar.gz?download
Il pacchetto si configura ed installa come segue :

$ cd /usr/src
$ tar -xzvf nrpe-2.0.tar.gz
$ cd nrpe-2.0
$ ./configure
$ make all

Alla fine del processo di “make” si noterà il seguente messaggio :

*** Compile finished ***
 
If the NRPE daemon and client compiled without any errors, you
can continue with installation.  The NRPE daemon and client
binaries are located in the src/ subdirectory.
 
 ** If this is your monitoring host **
 
     - Copy the check_nrpe client to the directory that
       contains your Nagios plugins.
     - Create a command definition in your Nagios config
       file for the NRPE client.  See the README file for
       more info on doing this.
 
 ** If this host will be running the NRPE daemon **
 
     - Copy the nrpe daemon to /usr/sbin, /usr/local/nagios
       or wherever you feel it fits best.
     - Copy the sample nrpe.cfg config file to /etc,
       /usr/local/nagios or wherever you feel it fits best.
     - Modify the /etc/services file and configure NRPE to
       run under inetd, xinetd, or as a standalone daemon.
       See the README file for more info on doing this.

Da qui in poi non ci sarà nulla di meglio che seguire le istruzioni appena lette.
Sarà necessario copiare sulla macchina dove abbiamo installato NAGIOS, il file /usr/src/nrpe-2.0/src/check_nrpe nella cartella dei plugin /usr/local/nagios/libexec (via rete o trasferendo il file su un dischetto) e sempre sul nostro server di controllo, aggiungere il riferimento a check_nrpe nel file dei comandi, aggiungendo cioè al file /usr/local/nagios/etc/checkcommands.cfg le seguenti righe :

# 'check_nrpe' command definition
define command{
        command_name    check_nrpe
        command_line    /usr/local/nagios/libexec/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
        }

in questo modo, come vedremo in seguito, potremo configurare un servizio per NAGIOS che faccia riferimento al comando check_nrpe. NAGIOS a questo punto non ha bisogno più di nulla, ciò che rimane da fare, riguarda solo la macchina che NAGIOS interrogherà, il server remoto.
Sulla macchina dove lasceremo in ascolto il demone dovremo creare la directory /usr/local/nagios/bin nella quale copieremo il file eseguibile del demone generato dalla compilazione di NRPE :

$ mkdir /usr/local/nagios/bin
$ cp /usr/src/nrpe-2.0/src/nrpe /usr/local/nagios/bin/

Creeremo poi la directory che conterrà la configurazione del demone /usr/local/nagios/etc e ci copieremo il file di esempio /usr/src/nrpe-2.0/src/nrpe.cfg :

$ mkdir /usr/local/nagios/etc
$ cp /usr/src/nrpe-2.0/nrpe.cfg /usr/local/nagios/etc/

Come ultima cosa, copieremo l’init-script (ossia il file di avvio del demone), nella cartella di sistema /etc/init.d in modo da poter automatizzare all’avvio l’esecuzione del demone NRPE e gli daremo permesso di esecuzione :

$ cp /usr/src/nrpe-2.0/init-script /etc/init.d/nrpe
$ chmod 755 /etc/init.d/nrpe

A questo punto potremo procedere con la configurazione del demone NRPE andando ad editare il file /usr/local/nagios/etc/nrpe.cfg , tra le opzioni indicate, le più importanti sono le seguenti :

server_port=5666

Indica la porta in ascolto e salvo esigenze specifiche è bene lasciare con questo valore,

allowed_hosts=127.0.0.1

Indica l’elenco degli host (separati da virgole) abilitati alle richieste. Ad esempio se il server NAGIOS avrà indirizzo 192.168.0.1, l’opzione dovrà essere modificata in allowed_hosts=127.0.0.1,192.168.0.1

nrpe_user=nagios
nrpe_group=nagios

Indicano rispettivamente l’utente ed il gruppo che andranno ad eseguire il processo.
Infine, le opzioni più importanti riguardano i comandi da eseguire :

command[check_disk1]=/usr/local/nagios/libexec/check_disk -w 20 -c 10 -p /dev/hda1

Ad esempio il comando appena scritto, denominato check_disk1, tramite il plugin check_disk consentirà di ricevere informazioni sullo stato del disco /dev/hda1.
A questo punto, non rimane altro da fare che lanciare il demone NRPE con questo comando :

$ /etc/init.d/nrpe start
Starting nrpe:                                             [  OK  ]

Se il comando non restituisce errori il demone è stato avviato correttamente.
L’ultima cosa da fare è quindi quella di configurare un servizio in NAGIOS che tramite il comando check_nrpe lanci il comando check_disk1 su questa macchina (che chiameremo remote_pc). Per fare ciò, immetteremo le informazioni relative all’host da controllare nel file /usr/local/nagios/etc/hosts.cfg :

# '' host definition
define host{
        use                     generic-host    ; Name of host template to use
        host_name               remote_pc
        alias                   Server remoto
        address                 192.168.1.2
        check_command           check-host-alive
        max_check_attempts      10
        notification_interval   120
        notification_period     24x7
        notification_options    d,u,r
        }

Includeremo questo host nel gruppo host “lan-servers” modificando nel file /usr/local/nagios/etc/hostgroups.cfg le righe relative :

# 'lan-servers' host group definition
define hostgroup{
	hostgroup_name	lan-servers
	alias			Gruppo gestione LAN
	contact_groups	lan-admins
	members		local_pc,remote_pc
	}

Ed infine configureremo il servizio per il nuovo host editando il file /usr/local/nagios/etc/services.cfg aggiungendo questa definizione :

# Service definition
define service{
	use                             generic-service         ; Name of service template to use
 
	host_name			remote_pc
	service_description	DISK /
	is_volatile			0
	check_period		24x7
	max_check_attempts	3
	normal_check_interval	5
	retry_check_interval	1
	contact_groups		lan-admins
	notification_interval	120
	notification_period	24x7
	notification_options	w,u,c,r
	check_command		check_nrpe!check_disk1
	}

Come si può notare, a differenza delle precedenti definizioni, all’opzione check_command viene passato il comando check_nrpe che ha come parametro il nome del plugin remoto da eseguire, definito precedentemente come check_disk1 sulla macchina remota all’interno del file /usr/local/nagios/etc/nrpe.cfg.
Terminata questa fase di configurazione è sufficiente ricaricare NAGIOS affinché rilevi le modifiche che abbiamo effettuato in questo modo :

$ /etc/init.d/nagios reload
Running configuration check...done
Reloading nagios configuration...done

Se il comando non restituisce errori, dovremo trovarci di fronte ad una schermata simile a quella di Figura 1, in cui rispetto a prima è stata aggiunta la riga relativa al controllo del disco della macchina remota a confermarci che tutto il nostro lavoro ha avuto buon esito.

Figura 1

Conclusioni

Più si sperimenterà l’utilizzo di questo programma più si capirà come sia essenziale il suo impiego all’interno di un sistema informativo, dal più semplice al più esteso.
Moltissime sono le potenzialità di NAGIOS e moltissimi i plugin non ufficiali per il controllo delle più svariate funzioni, si trovano tutti nel sito ufficiale di NAGIOS : http://www.nagios.org.

La serie comprende questi articoli :

Nagios, una rete sotto controllo Parte 1 : Installazione e configurazione
Nagios, una rete sotto controllo Parte 2 : NRPE : Nagios Remote Plugin Executor

Nota :

Questo articolo è originariamente apparso nell’edizione italiana di Linux Journal nel Giugno 2005.

Tutto quello di cui un’amministratore di sistema necessita per svolgere in maniera ottimale il proprio lavoro è il controllo di tutte le risorse che deve gestire. All’interno però di situazioni complesse, di sistemi estesi in cui operano decine di PC ciascuno con una propria specifica e critica funzione, ottenere il controllo totale risulta particolarmente complicato.
Si potrebbe creare un elenco scritto delle cose da controllare ogni mattina appena arrivati in ufficio o creare degli script specifici che partano automaticamente e che generino delle notifiche, ma sarebbe meglio essere sempre previdenti e agire appena un problema si rivela, senza magari ricevere prima una telefonata che segnala un disservizio.
Cerchiamo di capire con questo primo articolo come si possa implementare un complesso sistema di controllo e monitoraggio delle funzioni critiche di un sistema informativo servendosi del software Open Source : NAGIOS.

Perché usare NAGIOS

Il mercato mette a disposizione delle aziende parecchie soluzioni commerciali per il controllo dei sistemi : Openview, distribuito da HP dispone di un sistema di auto-rilevamento molto ben fatto, è un programma modulare (nel senso che a seconda di ciò che si vuole controllare, viene caricato un determinato “modulo” senza appesantire il sistema) e destinato ad un livello di utilizzo professionale, soprattutto a causa del costo. Presenta però alcuni lati negativi come la mancanza di un’ interfaccia web e l’obbligo di visionare lo stato dei sistemi solo dal PC sul quale è installato.
Un’altra alternativa è IBM Tivoli-netview che per funzionalità e capacità non è da meno ad Openview, ma come il precedente, risulta molto costoso e presenta un ulteriore lato negativo : gira solo su sitemi Unix AIX (che ne aggravano ulteriormente il costo).
Si fa presto a capire che seppur buoni, questi (come altri) programmi incidono sul bilancio aziendale in maniera consistente. Ecco perché ancora una volta l’alternativa più interessante è offerta dal mondo Open Source, precisamente da NAGIOS.
NAGIOS è un programma che consente di tenere sotto controllo servizi di rete, monitorare le risorse dei server come i carichi di lavoro e la capienza dei dischi, ricevere in tempo reale notifiche di malfunzionamenti via mail o addirittura SMS, possiede un interfaccia web completa, intuitiva e comprensibile, gira su tutti i sistemi unix-like (Linux in testa), è gratuito e rilasciato sotto licenza GPL (General Public License, http://www.gnu.org/copyleft/gpl.html).
Implementare NAGIOS in modo da monitorare un complesso sistema informativo consente di avere un’ efficiente alternativa ai software commerciali sopraelencati senza spendere nulla, a parte il tempo necessario per configurare a dovere questo utile software.

Concetto e requisiti di NAGIOS

NAGIOS è un demone, un programma sempre attivo e residente in memoria. In base al contenuto dei file di configurazione effettua tutti i controlli che sono stati decisi ed in caso di malfunzionamenti invia le notifiche agli utenti interessati. Per effettuare le interrogazioni ai servizi, NAGIOS si serve dei cosi detti “plugin” i quali altro non sono che dei programmi il cui unico scopo, una volta lanciati, è quello di interrogare questo o quel servizio e restituire un codice di uscita che NAGIOS interpreterà per effettuare le notifiche del caso.
NAGIOS possiede inoltre un interfaccia web (figura 1 e 2) che illustra, con una quantità considerevole di dettagli, lo stato di tutti i servizi, dei server e di quanto altro abbiamo deciso debba essere controllato.
A livello di requisiti, ciò di cui si necessita per compilare e far funzionare NAGIOS sono un compilatore C, che ci consentirà di compilare programma e plugin relativi, un web-server da configurare affinché visualizzi l’interfaccia web e la libreria “gd library” che consentirà all’interfaccia web di generare grafici e disegni. Ad ogni modo durante la fase di configurazione del programma, qualsiasi mancanza del sistema ci verrà segnalata in modo da potervi porre rimedio.

Installare NAGIOS

Descriveremo l’installazione partendo dai file sorgente in modo da rendere l’articolo il più generale possibile. Sono disponibili comunque i pacchetti binari per le più comuni distribuzioni, ma come sempre, luoghi e posizioni dei file di configurazione ed eseguibili potrebbero variare sensibilmente. Un elenco dei pacchetti disponibili lo si può trovare a questo indirizzo : http://dag.wieers.com/packages/nagios/.
A questo punto, per proseguire, è necessario prelevare i file sorgenti dal sito ufficiale di NAGIOS http://www.nagios.org. I file che ci interessano sono due, quello relativo al nucleo del programma : http://prdownloads.sourceforge.net/nagios/nagios-1.2.tar.gz?download e quello relativo ai plugin : http://prdownloads.sourceforge.net/nagiosplug/nagios-plugins-1.3.1.tar.gz?download al momento in cui scrivo le versioni “stabili” dei pacchetti sono quelle rappresentate dal relativo nome di file : 1.2 per quanto riguarda il programma effettivo ed 1.3.1 per quanto riguarda i suoi plugin.
Prima di iniziare, è necessario creare un utente denominato “nagios” affinché la nostra compilazione vada a buon fine. Questo utente sarà colui il quale avvierà il demone. Non è obbligatorio che questo si chiami “nagios” (è possibile modificarlo in fase di configurazione), ma torna utile in quanto è lo standard di installazione :

$ adduser nagios

Quindi, una volta scaricati i file procediamo con la decompressione del primo :

$ cd /usr/src
$ tar -xzvf nagios-1.2.tar.gz
$ cd nagios-1.2

Questo comando creerà la directory /usr/src/nagios-1.2 nella quale dovremo entrare per far parire la configurazione, lanciando il comando ./configure con alcune opzioni che indicano il percorso nel quale vogliamo che il programma venga installato, la directory relativa ai CGI (i programmi che consentono all’interfaccia web di funzionare a dovere), la directory base del sito, l’utente con il quale nagios verrà eseguito ed il suo gruppo :

$ ./configure --prefix=/usr/local/nagios --with-cgiurl=/nagios/cgi-bin --with-htmurl=/nagios/ --with-nagios-user=nagios –with-nagios-grp=nagios

E’ da notare che tutte le opzioni passate al comando qui sopra sono il default e che quindi sarebbe bastato digitare un ./configure per ottenere lo stesso risultato, in questo modo però, si capisce come personalizzare ulteriormente la propria installazione.
Completata la configurazione e verificato che tutto sia andato bene (in caso non lo fosse, ad esempio per problemi di mancanza di pacchetti, è necessario rimediare installandoli e rilanciare il comando) si può procedere con la compilazione effettiva seguita dall’installazione all’interno del nostro sistema dei file del programma :

$ make all
$ make install

Si procede poi con l’installazione dello script di init, che sarà necessario per avviare automaticamente il programma durante il boot del sistema e controllarne poi il funzionamento (in pratica per controllare le operazioni di start, stop, restart e reload del servizio).
Lo script nelle più comuni distribuzioni verrà posto nella directory /etc/rc.d/init.d :

$ make install-init

Per concludere, verranno installati i file “sample” (di esempio) necessari per orientarsi durante la prima configurazione di NAGIOS :

$ make install-config

Completiamo la fase di installazione installando i plugin con i seguenti comandi :

$ cd /usr/src
$ tar -xzvf nagios-plugins-1.3.1.tar.gz
$ cd nagios-plugins-1.3.1 
$ ./configure  --prefix=/usr/local/nagios --with-nagios-user=nagios --with-nagios-group=nagios
$ make all
$ make install

A questo punto l’installazione può dirsi teminata e la directory /usr/local/nagios/ avrà questo contenuto :

$ cd /usr/local/nagios/
$ ls
bin  etc  libexec  sbin  share  var

Tra le sottodirectory, bin/ contiene il file eseguibile nagios, /usr/local/nagios/libexec/ i file eseguibili dei plugin, etc/ i file di esempio e conterrà i file effettivi di configurazione, sbin/ gli script CGI per l’interfaccia web, share/ le pagine web “statiche” e la documentazione mentre var/ conterrà le informazioni di esecuzione di NAGIOS (file di lock e via dicendo).
Tutti i plugin contenuti in /usr/local/nagios/libexec/ sono file eseguibili da linea di comando. Questa qualità di NAGIOS (operare su eseguibili di sistema) ne estende le possibilità all’infinito. Qualsiasi sia la nostra esigenza, qualsiasi sia il servizio da monitorare, possiamo costruirci per conto nostro un plugin che ne verifichi il funzionamento.
A questo punto NAGIOS è pronto da configurare.

Configurare NAGIOS

NAGIOS necessità di un’approfondita configurazione che se fatta a regola d’arte può soddisfare le più svariate richieste. Va aggiunto però, che imparare a padroneggiare NAGIOS in un solo articolo è impossibile, pertanto è bene definire cosa ci proponiamo di implementare in modo da capire le basi del programma ed acquisire conoscenze che ci consentano in breve di approfondire lo studio e di sperimentare.
Possiamo quindi limitarci all’obiettivo di configurare NAGIOS affinché monitori lo stato di una sola risorsa, il server “local_pc” : se questo sia “vivo” (cioè se risponde ai ping), quanto spazio è presente sul disco e se il servizio HTTP è attivo. In caso di qualsiasi malfunzionamento, verrà allertato l’utente “lan_user_1”.
Per ciascun file di configurazione ci baseremo sui sample che il programma di installazione ha creato per noi, copiandoli in un nuovo file senza il suffisso “-sample”, ad esempio per il file hosts.cfg faremo come segue :

$ cd /usr/local/nagios/etc/
$ cp hosts.cfg-sample hosts.cfg

Editando il file ottenuto :

hosts.cfg

All’interno di questo file vanno poste le definizioni di ciascun host che intendiamo monitorare. Il formato degli inserimenti di questo file prevede la clausola define, seguita dal nome host e dalla definizione dei suoi parametri racchiusi tra due parentesi graffe.
La prima definizione, riguardante “generic-host”, riguarda il template (modello) su cui si baseranno gli inserimenti e va perciò mantenuta. Per il resto, dovendo configurare un solo host, utilizzeremo la seguente dichiarazione :

# 'local_pc' host definition
define host{
        use                     generic-host    ; Name of host template to use
        host_name               local_pc
        alias                   Server locale
        address                 192.168.1.1
        check_command           check-host-alive
        max_check_attempts      10
        notification_interval   120
        notification_period     24x7
        notification_options    d,u,r
        }

La definizione risulta abbastanza intuitiva in quanto ciascun parametro è auto-esplicativo. Il parametro più importante è “address” che identifica l’indirizzo della macchina, il quale potrebbe essere anche un sito internet, ad esempio www.esempio.com.

hostgroups.cfg

In questo file vengono definiti i gruppi di host e soprattutto il gruppo di contatto (che vedremo di seguito) ad essi associato. I membri del gruppo di contatto saranno allertati in caso di malfunzionamento. Nel nostro caso, il file conterrà :

# 'lan-servers' host group definition
define hostgroup{
	hostgroup_name	lan-servers
	alias			Gruppo gestione LAN
	contact_groups	lan-admins
	members		local_pc
	}

Abbiamo quindi configurato il gruppo “lan-servers” al quale il nostro host appartiene ed indicato per questo gruppo, i contatti di riferimento “lan-admins” che verranno dichiarati nel file che segue…

contactgroups.cfg

# 'lan-admins' contact group definition
 
define contactgroup{
	contactgroup_name	lan-admins
	alias			LAN Administrators
	members		lan_user_1
	}

Qui vengono indicati i gruppi di contatto, nel nostro caso, abbiamo dichiarato “lan-admins” nel quale sarà incluso l’utente deciso in partenza, “lan_user_1”, i cui dettagli verranno dichiarati in…

contacts.cfg

All’interno di questo file possiamo definire i dettagli relativi ai contatti, nel nostro caso il solo contatto che vogliamo dichiarare è “lan_user_1” :

# 'lan_user_1' contact definition
define contact{
	contact_name				lan_user_1
	alias						Network Administrator
	service_notification_period		24x7
	host_notification_period		24x7
	service_notification_options		w,u,c,r
	host_notification_options		d,u,r
	service_notification_commands		notify-by-email
	host_notification_commands		host-notify-by-email
	email						lan_user_1@localhost.localdomain
	}

services.cfg

Ultimo ma non per importanza, il file relativo ai servizi. Anche per questo è presente una template definita come “generic-service” che va obbligatoriamente inclusa in testa al file. Vanno poi incluse in questo file tutte le dichiarazioni dei servizi che vogliamo monitorare. Come deciso, controlleremo che la macchina sia attiva e raggiungibile dai ping, che non abbia il disco pieno e che su di essa sia attivo il servizio HTTP.

# Service definition
define service{
	use				generic-service
	host_name			local_pc
	service_description	PING
	is_volatile			0
	check_period		24x7
	max_check_attempts	3
	normal_check_interval	5
	retry_check_interval	1
	contact_groups		lan-admins
	notification_interval	120
	notification_period	24x7
	notification_options	c,r
	check_command		check_ping!200.0,20%!500.0,60%
	}
 
# Service definition
define service{
	use				generic-service
	host_name			local_pc
	service_description	DISK /
	is_volatile			0
	check_period		24x7
	max_check_attempts	3
	normal_check_interval	5
	retry_check_interval	1
	contact_groups		lan-admins
	notification_interval	120
	notification_period	24x7
	notification_options	w,u,c,r
	check_command		check_local_disk!20%!10%!/dev/hda1
	}
 
# Service definition
define service{
	use				generic-service
	host_name			local_pc
	service_description	HTTP
	is_volatile             0
	check_period            24x7
	max_check_attempts      3
	normal_check_interval   5
	retry_check_interval    1
	contact_groups          lan-admins
	notification_interval   120
	notification_period     24x7
	notification_options    w,u,c,r
	check_command           check_http
	}

Osservando le dichiarazioni di questi servizi si fa presto a capire come possa essere regolato qualsiasi dettaglio, il periodo di tempo (la cui definizione è indicata nel file timeperiods.cfg il quale, a meno di casi particolari, è bene lasciare con il contenuto di default) di ventiquattro ore per sette giorni, il numero massimo di tentativi prima di inviare segnalazioni di malfunzionamento e così via.
Il parametro che indica il comando da eseguire per effettuare il controllo è check_command, di fianco al quale va dichiarato il nome del plugin da utilizzare. Se il comando necessita di parametri, ed è il caso del comando check_ping, questi vanno indicati di seguito, separati con un punto esclamativo.
I comandi si trovano nel file checkcommand.cfg ed è proprio qui che, nell’eventualità in cui si vogliano costruire plugin per proprio conto, ne vanno indicate le dichiarazioni.
Per quel che ci riguarda, checkcommand.cfg può rimanere com’è, così come resource.cfg.

cgi.conf

All’interno di questo importantissimo file, vi sono indicate le opzioni per la gestione dei CGI, fondamentali per l’utilizzo dell’interfaccia web. I CGI sono una serie di programmi che NAGIOS utilizza per visualizzare nelle pagine web le più svariate informazioni. Questi programmi, si trovano nella directory /usr/local/nagios/sbin.
In questo file, vanno abilitate le linee relative ai permessi di accesso. Nel nostro caso sarà utile definire che l’utente “local_user_1” potrà accedere tramite browser alla consultazione di tutte le informazioni di NAGIOS, pertanto, nelle righe relative andrà indicato come nell’esempio riportato :

authorized_for_system_information=local_user_1

Più avanti vedremo come configurare il web server affinché l’interfaccia web funzioni a dovere.

nagios.cfg

L’ultimo file da tenere in considerazione, è nagios.cfg. Questo file contiene tutte le impostazioni generali di programma, a partire dalla posizione dei file di configurazione fino ad arrivare ai permessi di accesso dell’interfaccia web. Le impostazioni di default sono in generale ideali ed in caso di esigenze specifiche si può ottenere il risultato desiderato facendo riferimento ai commenti.
Solo un’opzione ci interessa abilitare ai fini del nostro progetto :

use_authentication=1

Quest’indicazione obbligherà NAGIOS a richiedere l’autenticazione per l’accesso ai sopracitati CGI.

Tra i file rimanenti, dependencies.cfg contiene le dipendenze dei diversi servizi ed al suo interno va indicato ad esempio che la vitalità del sito dipende dall’esecuzione del web server e senza di questo non può funzionare. Nel nostro caso, questo file può rimanere vuoto, così come il file escalations.cfg in cui si possono definire ad esempio il numero totale di volte in cui una notifica deve essere segnalata.

Configurare Apache affinché supporti NAGIOS

Prima di procedere con il primo avvio del programma, è bene predisporre Apache, il nostro web server, per il funzionamento di NAGIOS. All’interno del file httpd.conf vanno perciò immesse queste righe :

<Directory /usr/local/nagios/sbin>
AllowOverride AuthConfig
order allow,deny
allow from all
Options ExecCGI
</Directory>
 
<Directory /usr/local/nagios/share>
AllowOverride AuthConfig
order allow,deny
allow from all
</Directory>

In questo modo, oltre ad essere dichiarate, le directory di NAGIOS saranno anche protette (AllowOverride AuthConfig).
Per completare il discorso autenticazione, nella directory /usr/local/nagios/cgi, andrà creato un file denominato .htaccess con questo contenuto :

AuthName "Nagios Access"
AuthType Basic
AuthUserFile /usr/local/nagios/etc/htpasswd.users
require valid-user

La consultazione dei dettagli relativi allo stato dei servizi e degli host, raggiungibili attraverso l’indirizzo http://localhost/nagios, sarà protetta : all’accesso, verrà cioè richiesto di indicare un nome utente ed una password.
Il file .htaccess indica ad Apache che i dati di accesso sono inclusi nel file /usr/local/nagios/etc/htpasswd.users. Questo file viene creato con il comando htpasswd in questo modo :

$ htpasswd -c /usr/local/nagios/etc/htpasswd.users local_user_1
New password: ******
Re-type new password: ******
Adding password for user local_user_1

All’interno di htpasswd.users verranno registrati i dati di accesso l’utente “local_user_1” abilitato in precedenza nel file /usr/local/nagios/etc/cgi.conf.
Per creare altri utenti basterà rilanciare il comando senza l’opzione -c.
Nel caso in cui si volesse bloccare completamente l’accesso all’interfaccia web, sarà necessario inserire il file .htaccess anche nella directory /usr/local/nagios/share.

A questo punto, per applicare le modifiche è necessario avviare (o riavviare) il servizio di Apache in questo modo :

/etc/init.d/httpd start

La fase di configurazione può dirsi completata.

Avviare NAGIOS

Per avviare il demone di nagios è sufficiente lanciare il seguente comando :

/etc/init.d/nagios start
Starting network monitor: nagios
  PID TTY          TIME CMD
22037 ?        00:00:00 nagios

Se l’output è come quello mostrato, NAGIOS è in esecuzione e non resta che aprire il browser all’indirizzo http://localhost/nagios per verificare che tutto sia come ci aspettiamo : In Figura 1 è riportata la schermata definita “Tactical Overview” in cui c’è il riepilogo generale del sistema, mentre in Figura 2, “Service Detail”, è rappresentato il dettaglio dei servizi configurati.

Figura 1

Figura 2

Conclusioni

E’ facile capire come configurando attentamente in NAGIOS la nostra rete, potremo avere decine e decine di host costantemente sotto controllo e ricevere in caso di qualsiasi malfunzionamento un’istantanea notifica.
Nel prossimo articolo vedremo come monitorare risorse remote che necessitano dell’esecuzione di plugin locali tramite NRPE : Nagios Remote Plugin Executor.

La serie comprende questi articoli :

Nagios, una rete sotto controllo Parte 1 : Installazione e configurazione
Nagios, una rete sotto controllo Parte 2 : NRPE : Nagios Remote Plugin Executor

Nota :

Questo articolo è originariamente apparso nell’edizione italiana di Linux Journal nel Maggio 2005.