Archivi tag: plugin

Nagios: script bash + expect per monitorare il numero di NAT translation sui router Cisco

Dopo aver cercato a lungo un OID SNMP che potesse restituirmi on-the-fly il numero di NAT translation attive sul mio router Cisco, sono arrivato alla conclusione che il modo più semplice per ricavare tale informazione consiste nel creare uno scrip bash + expect da dare in pasto a Nagios.

Nagios_logo_blackPer prima cosa, dunque, mi sono soffermato sulla creazione dello scrip expect, in modo da poter interrogare il router oggetto di monitoraggio, lanciando un comando specifico, che è il seguente:

Router# show ip nat statistics

Ed ecco lo scrip expect vero e proprio:

#!/usr/bin/expect

set ip [lindex $argv 0]
set password1 [lindex $argv 1]
set password2 [lindex $argv 2]

spawn ssh -l nightfly "$ip"
expect "*?assword:*"
send "$password1\r"
expect ">"
send "ena\r"
expect "Password:"
send "$password2\r"
expect "#"
send "show ip nat statistics\r"
expect "#"
send "exit\r"
expect eof

Esso riceve come parametri l’IP del dispositivo, la password vty e la password ena.
Dopo averlo chiamato get_nat_num (ed averlo reso eseguibile con chmod +x get_nat_num), mi sono soffermato sulla creazione dello scrip bash, che è il seguente:

#!/bin/bash

host=$1
password1=$2
password2=$3
warning=$4
critical=$5

usage="check_nat_translations <host> <password1> <password2> <warning> <critical>"

if [ -n "$host" ]; then

        if [ -n "$password1" ];then

                if [ -n "$password2" ];then

                        if [ -n "$warning" ];then

                                if [ -n "critical" ];then

                                        if [ "$critical" -lt "$warning" ];then

                                                echo "UNKNOWN: critical has to be greater than warning"
                                                exit 3;

                                        else

                                                output=`/usr/lib64/nagios/plugins/get_nat_num $1 $2 $3 | grep "Total active translations"  | awk '{print $4}'`

                                        fi

                                        if [ -n "$output" ];then

                                                if [ "$output" -ge "$critical" ];then

                                                        echo "CRITICAL: total number of active NAT translations is $output | nat_translations=$output;$warning;$critical";
                                                        exit 2;

                                                elif [ "$output" -lt "$critical"  -a  "$output" -ge "$warning" ];then

                                                        echo "WARNING: total number of active NAT translations is $output | nat_translations=$output;$warning;$critical";
                                                        exit 1;

                                                else

                                                        echo "OK: total number of active NAT translations is $output | nat_translations=$output;$warning;$critical";
                                                        exit 0;

                                                fi
                                        else

                                                echo "UNKNOWN: output is null"
                                                exit 3;

                                        fi

                                else

                                        echo "$usage"
                                        exit 3;
                                fi

                        else

                                echo "$usage"
                                exit 3;
                        fi

                else

                        echo "$usage"
                        exit 3;
                fi
        else

                echo "$usage"
                exit 3;
        fi

else

        echo "$usage"
        exit 3;

fi

Esso accetta in ingresso 5 parametri: i primi 3 da passare allo scrip get_nat_num, gli ultimi 2 da utilizzare come soglie per Nagios (una warning ed una critical).

Rendiamo eseguibile anche questo scrip (chmod +x check_nat_translations) e soffermiamoci sulla configurazione di Nagios.

Come primo step occorre creare il comando che utilizza i plugin appena creati:

# 'check_nat_translations' command definition
 define command{
 command_name    check_nat_translations
 command_line    $USER1$/check_nat_translations $HOSTADDRESS$ $ARG1$ $ARG2$ $ARG3$ $ARG4$
 }

Successivamente è necessario creare un servizio (da inserire nel file di configurazione relativo ad un host determinato), che si avvalga del comando creato in precedenza:

define service{
 use                             local-service         ; Name of service template to use
 host_name                       cisco
 service_descripion             NAT Translations Number
 check_command                   check_nat_translations!password1!password2!40000!50000
 }

Salviamo la configurazione, riavviamo Nagios, ed il gioco è fatto.

Alla prossima.

Nagios troubleshooting

In questo post ho illustrato il comando da lanciare per appurare molto velocemente l’eventuale presenza di errori all’interno della configurazione di Nagios . Qui, invece, ho discusso di un valido tool in grado di debuggare i plugin utilizzati dall’NMS in questione.

nagiosEntrambi i suddetti metodi non rappresentano le uniche alternative in fase di troubleshooting. Infatti, Nagios mette a disposizione nativamente una modalità debug, la quale è in grado di “mostrare” come i vari comandi (configurati all’interno del file commands.cfg e valorizzati in nomehost.cfg) vengono interpretati ed eseguiti di volta in volta.

Per attivare tale modalità occorre operare all’interno del file /etc/nagios/nagios.cfg, impostando il debug level a 2048 (macros):

debug_level=2048

Il file da consultare sarà questo:

/var/log/nagios/nagios.debug

Inoltre, quando si ha a che fare con alcuni plugin sviluppati soprattutto in perl che lanciati da linea di comando come utente nagios funzionano correttamente mentre da pagina Web restituiscono un risultato di tipo Critical con output null, si può aggiungere, all’interno del file /etc/nagios/commands.cfg (in corrispondenza del comando che fa uso del suddetto plugin), la seguente entry:

2>&1

Ad esempio, per il plugin check_squid.pl ho definito il seguente comando:

'check_squid' command definition
define command{
        command_name    check_squid
        command_line    $USER1$/check_squid -u $ARG1$ -p $HOSTADDRESS$ -l $ARG2$ -e $ARG3$ 2>&1
        }

in modo tale da pololare il risultato del check presente nella pagina Web reindirizzando lo standard err (2>) nello standard out (&1).

Entrambi i metodi illustrati in questo post prevedono un reload della configurazione di Nagios per entrare in funzione:

[root@NMS ~]# service nagios reload

Per ora è tutto.

Alla prossima.

Joomla! o non Joomla!: questo è il problema

Joomla! o non Joomla!: questo è il problema. Già, proprio così, ed è anche un problema abbastanza serio. Da quando è nato questo magnifico CMS (insieme ai suoi fantastici fratelli, quali Drupal, Mambo e compagnia bella) la vita per noi web-developer (se così possiamo definirci) è diventata quasi un inferno. Ed è così che mi ritrovo magicamente in una sorta di limbo, in cui programmare vecchio stile è diventata una pratica fuori moda, per non dire sconveniente e controproducente. Parole grosse le mie? Forse, ma rispecchiano (quasi interamente) la realtà. Ed è così che giornalmente devo fare i conti con un branco di wannabe web-developer che si vantano di questa o quell’applicazione, di questo o di quel portale, nonostante la loro unica abilità consista nel saper installare qualche plugin di Joomla! e saper rimuovere (non con poche difficoltà) qualsiasi richiamo al vero creatore dell’applicazione. Ma che senso ha tutto questo? Cosa ne è del controllo del codice, della logica di programmazione, dell’analisi dei requisiti, ecc.?

Così finiremo per ritrovarci in un mondo fatto per il 90% da finti programmatori PHP e da finti webmaster, che rivendono i loro lavori per 4 soldi (ho visto portali venduti alla modica cifra di 190 €), perchè effettivamente di risorse mentali per le loro creazioni ne hanno impiegate ben poche.

E che dire poi dell’aspetto relativo alla sicurezza? Se io sul mio portale (relativamente sicuro) installo un plugin di un “indiano” semi-sconosciuto e semi-ignorante che non ha provveduto a realizzare i meccanismi più elementari di controllo dell’input e che crede che OWASP sia una specialità culinaria turca, posso dire allegramente addio a tutte le altre politiche di sicurezza, ed il defacing sarà solo questione di tempo.

C’è poi la questione dei colloqui di lavoro. Direte voi: cosa diamine c’entrano i colloqui di lavoro con Joomla!? C’entrano… eccome! Alla domanda (che puntualmente mi viene posta) “conosci Joomla!?” Io puntualmente rispondo: “si, ma faccio volentieri a meno di usarlo!”. Ed ecco che negli occhi del mio interlocutore leggo (non necessariamente in quest’ordine): smarrimento, delusione, derisione e compassione, seguite dalla fatidica frase: “ti faremo sapere”. E la mia reazione è sempre la stessa: no comment (anche se dovrei reagire in modo diverso, ad esempio chiedendogli se conosce il significato dei tag <tr> e <td>).

Certo, Joomla! è intuitivo da usare, ci semplifica notevolmente la vita ma… ricordate… non è tutto oro quello che luccica!

Alla prossima.