Con questo articolo vedremo come, utilizzando un tool che dialoga direttamente con il kernel Linux, monitorare un particolare path e rispondere ad alcuni eventi lanciando diversi comandi.

Come al solito mi piace analizzare una problematica reale per far comprendere meglio il problema e la soluzione che andremo ad implementare.

Immaginiamo di avere una macchina Linux (in questo caso specifico andremo ad utilizzare un server CentOS) attestata sulla rete perimetrale/pubblica della nostra azienda.

Questa macchina ha delle directory utente che vengono utilizzate, da procedure automatiche presenti su server remoti di altre aziende, per caricare dei file che la nostra azienda ha necessità di elaborare.

La soluzione “quick & dirty” sarebbe quella di accordarsi con l’azienda che caricherà il file sul nostro sistema sull’ora e definire una seguente procedura:

• Alle ore 00:00 viene avviato il trasferimento del file (di dimensione variabile) tramite scp
• Alle ore 01:00 viene avviato tramite cron un job che prende il file e lo elabora

Questa soluzione tendenzialmente può funzionare, ma possono verificarsi diversi problemi che possono bloccare la nostra procedura. Per esempio:

• Un problema sulle procedure dell’azienda remota tardano o falliscono, facendo slittare l’upload del file di più di un’ora. In questo caso il nostro job in partenza alle 01:00 fallirà poiché non troverà il file caricato.
• Sempre un problema sulle procedure dell’azienda remota fa tardare l’avvio dell’upload del file. In questo caso, quando il nostro job parte, potrebbe tentare di elaborare un file non ancora completo
• Le procedure partono correttamente ma, un lag di rete dato da N possibili motivi, fa allungare il tempo di trasferimento del file. Anche qui il nostro job potrebbe tentare di elaborare un file non ancora completamente trasferito.
• Delle modifiche alle procedure remote fanno variare il nome del file (che era stato precedentemente accordato). In questo caso, anche se il trasferimento è completo, il nostro script (se non correttamente ingegnerizzato) potrebbe non trovare il file semplicemente perché non si chiama come ci si aspetterebbe
• Sempre per modifiche alle procedure remote, il file potrebbe arrivare non normalizzato (quindi con permission sballate, etc.). In questo caso, magari, il nostro script potrebbe non essere in grado di leggere/scrivere o, più in generale, di elaborare il file

Come appare evidente, le problematiche possono essere molteplici!!!
Fortunatamente stiamo lavorando su linux e, il più delle volte, ci viene data la possibilità di risolvere i nostri problemi con un po’ di ingegno!

inotify

inotify è un sottosistema del kernel linux che lavora a livello di filesystem e ci permette, a fronte di alcuni eventi catturati, di notificare le variazioni all’applicazione.
E’ stato incluso nel mainstream del kernel linux con la versione 2.6.13 (rilasciata a Giugno 2005), ma può essere compilato con la versione 2.6.12 (e precedenti), tramite l’utilizzo di una patch.

In poche parole, dato un path, il sottosistema ne controlla gli inode puntati, e reagisce ad uno o più eventi su essi. A fronte dello scatenarsi di un evento (definito mask – maschera), possono essere eseguite delle operazioni.

Alcuni eventi che possono essere monitorati sono i seguenti:

• IN_ACCESS – E’ stato fatto un’accesso in lettura ad un file
• IN_MODIFY – E’ stata eseguita una modifica ad un file
• IN_ATTRIB – E’ stata eseguita una modifica agli attributi di un file
• IN_OPEN – Un file è stato aperto
• IN_CLOSE_WRITE – Un file, aperto in scrittura, è stato chiuso
• IN_CLOSE_NOWRITE – Un file, aperto NON in scrittura, è stato chiuso
• IN_MOVED_FROM e IN_MOVED_TO – Un file è stato spostato o copiato
• IN_DELETE – Un file/directory è stato cancellato
• IN_CREATE – Un file/directory è stato creato
• IN_DELETE_SELF – Il file/directory monitorato è stato cancellato

incrond

incrond è un demone che funziona in maniera molto simile a quello che è l’ormai conosciutissimo demone cron; la differenza sta nel fatto che, se cron lavora con giorni ed orari, incrond lavora invece con inotify.

Quello che possiamo fare per rendere la nostra procedura “intelligente” è andare a monitorare il path in cui l’azienda remota esegue l’upload del file e, al termine dell’upload, lanciare il job che elabora il file.
Questo ci permette di evitare di legarsi a gli orari, e di lanciare il nostro job ogni volta che un file viene caricato, indipendentemente dall’ora o dal nome del file. Esattamente quello che ci interessa.

Intanto andiamo ad installare il demone, operazione estremamente semplice:

# yum install incrond

A questo punto, la prima cosa da fare è creare il file /etc/incrond.allow contenente la lista degli utenti abilitati all’uso di incrond. Nel nostro caso abilitiamo l’utente root e l’utente matteo:

# cat > /etc/incrond.allow <<EOF
>root
>matteo
>EOF
# cat /etc/incrond.allow
root
matteo

Avviamo il demone ed assicuriamoci che sia abilitato per l’avvio automatico al boot della macchina:

# service incrond start
Starting incrond:                                          [  OK  ]
# chkconfig --list incrond
incrond        	0:off	1:off	2:off	3:off	4:off	5:off	6:off
# chkconfig incrond on

Ok, adesso siamo pronti per il definire il nostro monitoraggio.

Poniamo, nel nostro esempio, che l’utente matteo sia l’utente che carica il file, e che lo carica nel path /home/matteo/uploads.

Iniziamo a definire la incrontab (vedrete che l’assonanza con cron non è solo nelle definizioni, ma anche nei comandi) per l’utente matteo. Il comando è semplicissimo:

# su - matteo
$ incrontab -e

Questo apre il nostro editor di default e ci permette di compilare la incrontab.
Questa incrontab è composta da 3 campi (che vedremo di seguito) separati da spazio

ATTENZIONE – I campi DEVONO essere separati dal carattere di spaziatura. Separare i campi con il consueto TAB porta a problemi di interpretazione della incrontab da parte del demone incrond (dai, è tutto molto bello, un piccolo difetto lo possiamo anche concedere ).

I tre campi sono, nell’ordine:

• path – Il path ASSOLUTO che si desidera monitorare
• mask – L’evento che si vuole monitorare. Sono supportati tutte le maschere che sono state descritte prima, più la maschera IN_ALL_EVENTS che, semplicemente, cattura tutti gli eventi (ottima per il debugging)
• command- Il comando da eseguire quando viene catturato l’evento. Da notare che in questo comando possiamo utilizzare delle variabili di inotify che ci vengono passate direttamente dal demone. Queste variabili sono:
  • $@ – Il path monitorato
  • $# – Il file sul quale si è scatenato l’evento
  • $% – L’evento, in forma testuale, che si è verificato
  • $& – L’evento, in forma numerica, che si è verificato
  • $$ – Il carattere $

Semplice, non trovate?

Allora, torniamo all’esempio. Il nostro job si trova nella directory /home/matteo/scripts/, si chiama elaborazione.sh ed accetta come parametro il nome del file da elaborare.

Facciamo un’attimo il punto della situazione. In un certo momento (non sappiamo quale), la procedura remota andrà a caricare, con scp, il nostro file.
Una volta effettuata la connessione con successo, il file verrà in primo luogo creato (IN_CREATE), aperto in scrittura (IN_OPEN), scritto (una sequenza di IN_MODIFY) ed infine chiuso (IN_CLOSE_WRITE, visto che era stato aperto in scrittura).

Quindi, l’evento che andrà a determinare la fine del trasferimento è IN_CLOSE_WRITE. Andiamo quindi a compilare la incrontab dell’utente matteo:

/home/matteo/uploads IN_CLOSE_WRITE /home/matteo/scripts/elaborazione.sh $@/$#

Salviamo usciamo ed assicuriamoci che la nuova incrontab sia stata letta ed interpretata dal sistema:

table updated
$ exit
# tail -1 /var/log/cron
Oct 27 10:30:39 myserver incrond[889]: table for user matteo changed, reloading

Possiamo testare se funziona caricando un dummy file (supponiamo che i file contenti il testo “dummy” vengano ignorati dal nostro script) da una macchina remota:

client$ cat > dummyfile <<EOF
>dummy
>EOF
client$ cat dummyfile
dummy
client$ scp dummyfile matteo@myserver:uploads/
Password:

Torniamo sul server e, dal log di cron, vediamo che incrond ha catturato l’evento ed ha eseguito il nostro elaboratore:

# tail -1 /var/log/cron
Oct 27 10:35:43 myserver incrond[889]: (matteo) CMD (/home/matteo/scripts/elaborazione.sh /home/matteo/uploads/dummyfile)

Conclusioni

Abbiamo visto come installare e configurare incrond per monitorare il cambio di stato di un file in una directory.
Questa è una possibile soluzione pratica ad un problema che, tendenzialmente, si verifica abbastanza di frequente in ambienti enterprise, in cui ci sono flussi di lavoro locali/remoti che devono lavorare in relazione gli uni con gli altri.

In realtà, gli utilizzi di inotify sono estremamente ampi; per esempio, è il sistema che viene normalmente utilizzato dagli indicizzatori di filesystem su linux (per esempio, Beagle di SUSE).
Andando a monitorare l’intero filesystem (/) ed avendo le notifiche sulle modifiche di qualsiasi file al suo interno, l’indicizzatore può aggiornare i suoi database senza doversi rileggere l’intero filesystem.

Un’altro utilizzo può essere quello di monitorare il file di log di un’applicazione. Quando questa applicazione andrà a loggare qualcosa, possiamo mandare una mail contenente il file di configurazione a qualcuno.

Il limite è il vostro ingegno

Per sua stessa natura, Nagios funziona generalmente in maniera “attiva”, andando ad eseguire lui stesso i check verso gli host remoti, tramite script già forniti o custom, oppure interrogando direttamente un demone NRPE presente sulla macchina remota, e che in genere esegue check locali.

Nagios, però, può essere configurato per eseguire dei check “passivi”, ovvero fare in modo che un check che giri, possa essere messo in stati particolari da programmi estetrni. Questo è quello che normalmente succede quando si lavora sull’interfaccia web e si imposta, per esempio, un Acknowledge su un servizio, o si disabilitano le notifiche.

La cosa interessante che andremo a fare in questo tutorial è un’ulteriore step. In pratica faremo in modo che non solo il server su cui gira Nagios possa ricevere delle trap SNMP, ma che Nagios stesso reagisca, in maniera predeterminata, a queste trap.

Facciamo un’esempio pratico (sarà poi quello utilizzato nel tutorial, e che è stato personalmente testato da me): un bilanciatore hardware F5 è stato configurato per lanciare delle trap verso una macchina Nagios. Questo bilanciatore invia non solo trap relative al suo stato, ma anche delle trap che indicano lo stato di un host reale bilanciato.
In pratica, quello che si otterrà è il seguente flusso di eventi:

1. L’host reale ha qualche problema, e va in down (fisicamente, o anche il solo servizio bilanciato dall’F5)
2. Il bilanciatore se ne accorge, disabilita il reale dal pool legato al VIP (Virtual IP)
3. Il bilanciatore manda una trap verso il server su cui gira Nagios, identificando che un particolare host va in down
4. Il server cattura la trap, la interpreta, ed inietta direttamente in Nagios un comando
5. Nagios mette un particolare servizio in stato CRITICO, scatenando anche le notifiche del caso

In questo caso vediamo che non ci sono latenze dovute al timeslice di check di Nagios, ma la notifica è immediata alla verifica del problema.

Prima di entrare nel vivo del tutorial, tengo a precisare non verrà trattata l’installazione e/o la configurazione di Nagios (se non per quanto riguarda le parti relative al tutorial stesso), e l’ambiente su cui è stato testato il tutto gira attualmente con questo OS/questi software:

• Debian GNU/Linux 6.0
• Nagios3 presente sui repository Debian (Nagios 3.2.1-2)

Quindi farò riferimento ai path di default di questo sistema.
Bando alle ciance, andiamo ad incominciare

Configurare il sistema per ricevere le trap SNMP

Il primo passo è quello di far si che il nostro server (sul quale già sta girando Nagios) possa ricevere delle trap SNMP.
Niente di più semplice, dovreste avere già installato il pacchetto snmpd, nel caso in cui non lo fosse, un semplice

# apt-get install snmpd

vi risolverà il problema.
Questo pacchetto contiene un demone in grado di ricevere delle trap snmp. Per configurarlo editate il file /etc/default/snmpd aggiungendo/modificando le seguenti variabili:

TRAPDRUN=yes
TRAPDOPTS='-On -u snmptt -p /var/run/snmptrapd.pid'

Facendola breve diciamo di far partire il demone per le trap (TRAPDRUN=yes) e lo facciamo lanciare con le seguenti opzioni:

• -On     Fa si che il demone usi gli OID in formato numerico, ed evita che il traduttore debba eseguire la traduzione dal formato testuale a quello numerico
• -u snmptt     Fa girare il demone con l’utente snmptt
• -p /var/run/snmptrapd.pid     Definisce il PIDfile in cui andare a scrivere il pid del processo

Andiamo quindi a definire cosa il demone snmptrapd deve fare alla ricezione di una trap. Modifichiamo quindi il file
/etc/snmp/snmptrapd.conf inserendo le seguenti direttive alla fine:

disableAuthorization yes
traphandle default /usr/sbin/smptt

In questo caso, diciamo al demone di disattivare l’autenticazione per l’invio delle trap (per questo tutorial useremo il metodo KISS: Keep It Simple and Stupid), e diciamo al demone di prendere tutte le trap e girarle al software /usr/sbin/smptt (di cui parleremo a breve).
Aspettiamo a riavviare il demone poiché dobbiamo prima assicurarci di aver installato SNMPTT.

Configurare il traduttore di trap SNMPTT

Il traduttore è una parte fondamentale. E’ quel software che si occupa, una volta ricevuta la trap, di interpretarla, tradurla e scriverla da qualche parte.
La traduzione viene fatta utilizzando dei file .MIB che altro non sono che dizionari contenenti un riferimento TRAP -> MESSAGGIO.
Praticamente tutti i produttori di hardware che emettono trap SNMP forniscono i file .MIB necessari alla traduzione, e la F5 non è da meno.

Intanto installiamo il traduttore:

# apt-get install snmptt

Una volta installato, andiamo a modificare il file di configurazione /etc/snmp/snmptt.ini con i seguenti parametri:

mode = standalone          # Questo perché viene invocato da snmptrapd e non deve girare come demone
dns_enable = 0             # Evitiamo che risolva l'hostname per ogni trap che gli arriva
strip_domain = 0           # Diciamogli di non rimuovere il dominio dall'eventuale hostname
net_snmp_perl_enable = 1   # Può utilizzare il perl la traduzione
translate_value_oids = 1   # Traduce gli OID in formato testuale leggibile breve
translate_enterprise_oid_format = 1   # come sopra
translate_trap_oid_format = 1         # come sopra
translate_varname_oid_format = 1      # come sopra
log_enable = 1             # Abilita il logging delle trap
syslog_enable = 1          # Abilita il logging delle trap sul syslog
syslog_level = info        # Definisce il livello di logging per le trap su syslog

A questo punto portiamo sulla macchina i vari files .MIB relativi all’hardware che andrà a scatenare le trap e traduciamo questi file in formato comprensibile con snmptt. Nulla di più semplice:

# mkdir /etc/snmp/mibs    # In questa directory metteremo tutti i mib tradotti
# snmpttconvertmib --in=F5-BIGIP-COMMON.mib --out=F5-BIGIP-COMMON.conf
# mv F5-BIGIP-COMMON.conf /etc/snmp/mibs/

Lanciamo il comando per tutti i MIB che ci fornisce il produttore.
A questo punto, riapriamo il file di configurazione di snmptt (/etc/snmp/snmptt.ini) e terminiamo la configurazione aggiungendo/modificando alla fine:

snmptt_conf_files = <<END
/etc/snmp/snmptt.conf
/etc/snmp/mibs/F5-BIGIP-COMMON.conf
END

Riga per riga, andiamo a mettere tutti i file .conf che abbiamo generato con smpttconvertmib. A questo punto possiamo restartare il demone SNMPD (così da far partire il gestore di trap) e verificare che sia effettivamente partito:

# /etc/init.d/snmpd restart
# cat /var/run/snmptrapd.pid
7464

Perfetto, mettiamoci in tali sul file del syslog (per default il /var/log/messages) e dovremmo iniziare a veder passare le trap:

# tail -f /var/log/messages
Sep 20 11:23:40 nagios-mi snmptt[111]: .1.3.6.1.4.1.3375.2.4.0.29 Normal "Status Events" 192.168.0.1 - The system is in an unusable situation. AUDIT - user admin - RAW: httpd(mod_auth_pam): user=admin(admin) partition=[All] level=Administrator tty=1 host=10.10.0.1 attempts=1 start=\"Tue Sep 20 11:03:00 2011\" end=\"Tue Sep 20 11:23:30 2011\".

Ottimo, riceviamo le trap, ora dobbiamo trovare il modo di dire a Nagios che questa trap ha un significato, dirgli quale, e di scatenare un evento… procediamo

Catturare le trap

Ci viene in aiuto un’ottimo tool di nome SEC. Questo tool, in maniera generale, permette di analizzare live il contenuto di un file (quindi resta in ascolto ed analizza i nuovi contenuti) e di eseguire determinate operazioni a verificarsi di particolari eventi.
Nel nostro caso, lo metteremo in ascolto sul file in cui vengono slogate le trap /var/log/messages e, con il match su di una particolare RegExp, viene lanciato uno script con determinati parametri.
SEC è uno script in perl, ma ne esiste comunque una versione pacchettizzata per debian, dunque:

# apt-get install sec

Una volta installato, andiamo a modificare il file di configurazione /etc/sec.conf, inserendo i seguenti parametri:

type=Single
ptype=RegExp
pattern=.*(Normal|INFORMATIONAL|MINOR|WARNING|SEVERE|MAJOR|CRITICAL)\ \"Status Events\"\ (\b(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\b)\ \-\ (A service is detected (UP|DOWN)\.\ Pool\ member\ (\b(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\b)(.*)|(.*))
desc=snmptrap received from $2
action=shellcmd /usr/lib/nagios/eventhandlers/snmptraphandling.sh $2 $1 "$3" $4 $5

In pratica viene detto a SEC di eseguire la “action” quando un testo fa match con la regular expression definita in pattern. Senza stare li a parlare di regular expression (potremmo andare avanti per giorni e giorni), se arriva una trap SNMP con il seguente testo:

Sep 20 11:23:40 nagios-mi snmptt[111]: .1.3.6.1.4.1.3375.2.4.0.29 Normal "Status Events" 192.168.0.1 - The system is in an unusable situation. AUDIT - user admin - RAW: httpd(mod_auth_pam): user=admin(admin) partition=[All] level=Administrator tty=1 host=10.10.0.1 attempts=1 start=\"Tue Sep 20 11:03:00 2011\" end=\"Tue Sep 20 11:23:30 2011\".

otteniamo in output le seguenti variabili:

$1 = Normal
$2 = 192.168.0.1
$3 = The system is in an unusable situation. AUDIT - user admin - RAW: httpd(mod_auth_pam): user=admin(admin) partition=[All] level=Administrator tty=1 host=10.10.0.1 attempts=1 start=\"Tue Sep 20 11:03:00 2011\" end=\"Tue Sep 20 11:23:30
$4 =
$5 =

Come vediamo le ultime due variabili sono vuote. Nel caso, invece, ci arrivi una trap formata in quest’altra maniera (che indica lo stato UP/DOWN di un server fisico controllato dal bilanciatore):

Sep 20 11:47:33 nagios-mi snmptt[111]: .1.3.6.1.4.1.3375.2.4.0.10 Normal "Status Events" 192.168.0.1 - A service is detected DOWN. Pool member 192.168.0.100:18009 monitor status down. 192.168.0.100 18009

otteniamo, invece, in output le seguenti variabili:

$1 = Normal
$2 = 192.168.0.1
$3 = A service is detected DOWN. Pool member
$4 = DOWN
$5 = 192.168.0.100

In quest’altro caso le ultime due variabili sono valorizzate ed identificano, rispettivamente, lo stato del reale (UP o DOWN) ed il reale in question (192.168.0.100).

Ovviamente, questa RegExp è stata costruita in funzione di come SNMPTT, con i MIB forniti da F5, traduce le trap. Hardware differente, con MIB differenti, tradurranno le trap in maniera differente, e sarà quindi necessario andare a trovare una RegExp funzionante per quella casistica.

Ne approfitto per segnalare il link http://gskinner.com/RegExr/ veramente molto comodo per scrivere e testare le RegExp.

Quindi, abbiamo intercettato le trap con SEC, ed eseguiamo questo script /usr/lib/nagios/eventhandlers/snmptraphandling.sh passandogli le 5 variabili ottenute dalla RegExp, siano esse valorizzate o meno. Ma cosa fa questo script?

snmptraphandling.sh

Ho scritto personalmente questo script, basandomi su un’idea di Francois Meehan, autore di uno script python simile ma meno specializzato.

Potete scaricarlo da qui: snmptraphandling.zip

Questa versione in bash accetta in ingresso le seguenti variabili (nel seguente ordine):

HOST: Obbligatoria, identifica l’host che ha inviato la trap
SEVERITY: Obbligatoria, identifica il “peso” della trap (Normal, critical, etc.) così come viene definita da F5
“DATA”: Obbligatoria dentro i doppi apici. Contiene un testo che identifica meglio la trap, una descrizione
UP|DOWN: Opzionale, identifica lo stato di un reale
ALARMEDHOST: Opzionale, identifica l’host al quale viene applicata la variabile precedente.

Intanto lo script definisce, a seconda della SEVERITY, che valori applicare al Nagios.
Inoltre, nel caso vengano specificate anche le ultime due variabili, esegue operazioni differenti per scatenare allarmi specifici.

Ma come dialoga con Nagios? Semplicissimo, costruisce un comando ad-hoc interpretabile da Nagios, e lo inetta nel file

/var/lib/nagios3/rw/nagios.cmd

Questo file è specializzato per inviare segnali a Nagios e fargli eseguire operazioni particolari.

In pratica, all’arrivo di una trap viene scatenato un evento indirizzato all’host $HOST, per un servizio chiamato:

snmp_trap_handling_$HOST-…. Nel caso in cui non siano specificate le ultime 2 variabili
snmp_trap_handling_$ALARMED_HOST Nel caso in cui siano specificate le ultime 2 variabili.

Ma prendiamo in mano un’esempio completo, così da essere più chiari.
Ci arriva dal bilanciatore, per esempio, una trap SNMP che ci identifica che un’host è andato giù; all’interno del file
/var/log/messages verrà scritto (da SNMPTT) il seguente messaggio:

Sep 20 11:47:33 nagios-mi snmptt[111]: .1.3.6.1.4.1.3375.2.4.0.10 Normal "Status Events" 192.168.0.1 - A service is detected DOWN. Pool member 192.168.0.100:18009 monitor status down. 192.168.0.100 18009

SEC vedrà che questo testo fa match con la RegExp che gli abbiamo applicato, e lancerà questo comando:

/usr/lib/nagios/eventhandlers/snmptraphandling.sh 192.168.0.1 Normal \
"A service is detected DOWN. Pool member" DOWN 192.168.0.100

Lo script prenderà questi valori, li andrà ad elaborare (per esempio, cercando nelle configurazioni di nagios, andrà a tradurre 192.168.0.1 con bil-f5, che altro non è che il nome dell’host specificato in nagios) ed inietterà il seguente testo nel file
/var/lib/nagios3/rw/nagios.cmd:

[1316513822] PROCESS_SERVICE_CHECK_RESULT;bil-f5;snmp_trap_handling_192.168.0.100;2;A service is detected DOWN. Pool member 192.168.0.100:18009 monitor status down. 192.168.0.100

Questo testo fa si che il servizio “snmp_trap_handling_192.168.0.100″ venga applicato lo stato 2, ovvero il CRITICAL per Nagios.

Configurare Nagios

Per configurare il Nagios, andremo a creare 3 strutture nuove: la prima è un servizio template che funziona in passivo e che viene usato per creare qualsiasi servizio relativo alle trap snmp; la seconda è l’host che identifica il bilanciatore; la terza è il servizio vero e proprio che verrà messo in critical o meno all’arrivo della trap.
Quindi:

define service {
name generic-snmptrap
active_checks_enabled 1
passive_checks_enabled 1 ; Passive service checks are enabled
is_volatile 1
initial_state o
check_period never
notification_interval 120
notification_options w,u,c,r
notification_period 24x7
check_command return-ok
max_check_attempts 1
check_freshness 0
stalking_options o,w,u,c
register 0 ; Not register. Its just a template
}

Notiamo alcune configurazioni particolari:

passive_checks_enabled 1 Determina che il servizio risponde a check passivi

active_checks_enabled 1 Attiva anche i check attivi. Questo è stato fatto solo perché personalmente trovo che
Nagios debba sempre mostrare uno stato completamente verde. Disattivando i
check attivi, nel TacticalOverview di Nagios avremmo un host segnalato in rosso.

check_period never Non vengono mai schedati check per questo servizio (questo perché il servizio
risponde a delle trap e non esegue direttamente i check)

check_command return-ok Attivando i check attivi, è necessario definite un check_command. Ho usato
return-ok che è un check standard di Nagios che ritorna sempre un stato OK

stalking_options o,w,u,c Questo serve per evitare che mille trap dello stesso tipo vadano a saturare il
Nagios

A questo punto definiamo l’host:

define host{
use generic-host
host_name bil-f5
alias bil-f5
address 192.168.0.1
}

ed infine il servizio:

define service{
use generic-snmptrap
host_name bil-f5
service_description snmp_trap_handling_192.168.0.100
}

Vediamo quindi che, il match che esegue il Nagios, è sulla descrizione del servizio.

Conclusioni

Abbiamo infine visto il giro del fumo. Sembrano tante parole ed il tutto molto complicato, ma vi assicuro che, una volta implementato, va tutto liscio come l’olio.

Buon lavoro

Eccoci ancora qui con un altro tutorial semplice semplice ma, in alcuni casi, molto utile.

Il problema di oggi è stato il seguente: devo montare su una lama HP l’immagine di un disco USB per poter caricare dei file su un sistema “live” (quindi con lettore cd occupato) senza dover configurare la rete (e quindi, far riconfigurare la porta degli switch).

Le soluzioni sono 2:
1) Prendere una chiavetta USB, caricare i file, fare un’immagine e collegarla
2) Creare direttamente da sistema l’immagine di una chiavetta USB, caricare i file, e collegarla.

Dato che la prima soluzione prevede comunque di avere una chiavetta di dimensione “trasportabile” via rete (personalmente ho un pendrive da 16GB: per due file da 2mb l’uno, farmi un’immagine da 16GB e spostarla via rete è assurdo), la seconda è molto più malleabile in termine di dimensioni dell’immagine che si andrà a creare.

Ma, andiamo a cominciare: per prima cosa ci interessa creare un file (che altro non sarà che l’immagine della nostra chiavetta) di una dimensione particolare; nel mio caso, 10mb sono più che sufficienti.
Mano al buon, vecchio dd e dunque:

$ dd if=/dev/zero of=usbDisk.img bs=1024 count=10000

Quindi, partendo dal device “zero” (contenente, ovviamente, solo 0) creo un file “usbDisk.img” di dimensione 1024byte x 10000 = 1kb x 10000 = 10mb

Terminata la creazione, scatta la magia: andiamo a collegare questo file ad un device facendolo, in effetti, vedere al sistema come un dispositivo fisicamente collegato alla macchina:

$ losetup -f usbDisk.img

Questo comando prende il file usbDisk.img e lo collega al device /dev/loop0

Ora, come ogni disco che si rispetti, andiamo a crearci sopra una partizione; armiamoci di cfdisk (molto semplice, i puristi preferiranno fdisk, ma fate voi) e creiamo una singola partizione di tipo “Linux” sul disco:

$ cfdisk /dev/loop0

Salviamo ed usciamo.
In realtà quello che ci serve non è la partizione, bensì il fatto che cfdisk, in fase di scrittura, determina e scrive direttamente sul device informazioni come i cilindri, ecc. che servono successivamente per creare il filesystem.

Quindi, visto che vogliamo simulare un disco usb “standard”, andiamo a metterci sopra un filesystem che sia comune, e cosa meglio del vecchio fat32 per questo?

$ mkdosfs -F 32 /dev/loop0

Terminata la creazione possiamo montare il disco usb come un normalissimo device:

$ mkdir -p /mnt/fintoDisco
$ mount /dev/loop0 /mnt/fintoDisco

e copiarci sopra i file interessati.

Quando abbiamo finito ricordiamoci di smontare il device:

$ umount /mnt/fintoDisco

e, soprattutto, di sganciare il device dal file reale:

$ losetup -d /dev/loop0

Ora possiamo portarci in giro il file come più ci aggrada.

Buon divertimento e buon lavoro

Quante volte è capitato di eseguire un’operazione, magari per la prima volta, e dimenticarsi completamente di prendere appunti?

Lavorando in ambiente sistemistico, se questo avvenimento non è quotidiano, poco ci manca!

Ed in genere come risolviamo il problema? Le soluzioni sono due:

1. Scrolling del buffer del terminale: Alt+Pag.Up permettono di rileggere cosa si è fatto; il problema è che il buffer dei terminali è limitato (specialmente se si lavora in ambiente non grafico), e spesso alcune cose si perdono comunque;
2. Visione della history: I moderni terminali supportano la history, permettendo così di scorrere nei comandi lanciati e richiamarli velocemente; il problema è che anche visualizzando la history, non abbiamo l’output dei comandi che abbiamo lanciato.

Quello che servirebbe è un software che permetta di eseguire un logging completo (quindi sia dell’input che immettiamo che dell’output che viene generato).

Ci viene in aiuto script! Tanto semplice quanto funzionale.

Il modo più “pulito” per eseguire il comando è il seguente:

$ script
Script iniziato, il file è typescript
$

Come vedete pare che non sia successo nulla. Ed in effetti possiamo dimenticarci di aver lanciato il comando. Continuiamo pure con il nostro lavoro…

$ su -
Password:
# pwd
/root
# cd /etc/ssh/
# cat sshd_config | grep PermitRoot
PermitRootLogin yes
# sed -i -e "s/PermitRootLogin yes/PermitRootLogin no/" sshd_config
# cat sshd_config | grep PermitRoot
PermitRootLogin no
# /etc/init.d/ssh restart
* Restarting OpenBSD Secure Shell server sshd                           [ OK ]
# exit
logout
$

Semplicemente quando avremo finito la nostra sessione di lavoro, e lanceremo il consueto “exit“, avremo un output di questo tipo:

$ exit
exit
Script effettuato, il file è typescript

Ora, se dovessimo andare a rivedere la nostra sessione, magari per trasformarla in un howto od in un file da tenere sott’occhio quando tra 6 mesi ci verrà richiesto di fare la stessa cosa, possiamo vedere il contenuto del file “typescript” generato da script:

mcappadonna@laptop ~ $ cat typescript
Script iniziato su ven 16 gen 2009 12:08:38 CET
$ su -
Password:
# pwd
/root
# cd /etc/ssh/
# cat sshd_config | grep PermitRoot
PermitRootLogin yes
# sed -i -e "s/PermitRootLogin yes/PermitRootLogin no/" sshd_config
# cat sshd_config | grep PermitRoot
PermitRootLogin no
# /etc/init.d/ssh restart
* Restarting OpenBSD Secure Shell server sshd                          [ OK ]
# exit
logout
$ exit
exit
 
Script effettuato su ven 16 gen 2009 12:09:38 CET

Alcune opzioni comode di script sono le seguenti:

• -a : Appende l’output ad un file già presente;
• -q : Elimina dall’output i messaggi di script;
• -t : Aggiunge all’output l’indicazione dell’ora (utile per tenere un timestamp del lavoro)

Ovviamente, potete aggiungere a script l’indicazione del nome del file da salvare:

$ script sessioneDiProva.txt
Script iniziato, il file è sessioneDiProva.txt
$

Un’ultima cosa: se si dovesse avere la necessità di seguire in due utenti (remoti) la stessa sessione di shell ma non fosse possibile installare “screen” sulla macchina, una soluzione elegante può essere la seguente:

$ mkfifo temp; script -f temp

Il comando sembrerà appeso, ma nel momento in cui l’altro utente va ad eseguire un cat sul file, la sessione di script ha inizio e tutti vedono “live” la sessione di shell:

$ cat temp
Script iniziato su ven 16 gen 2009 12:16:28 CET
$

Comodo no?

Buon lavoro.