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

Ecco le parti finali del seminario di miamammausalinux.org, intitolato “Evoluzione dell’alta affidabilita’ su Linux” che si è svolto nella giornata del 24 giugno 2011, presso l’hotel Holiday Inn di Rho.

La quinta e la sesta parte descrivono nel dettaglio la soluzione operativa di un sistema cluster in modalità active-active, mediante configurazioni e test funzionali.

Parte cinque di sei – Il Progetto (parte prima):

Parte sei di sei – Il Progetto (parte seconda):

Serie completa:

• Seminario “Evoluzione dell’alta affidabilita’ su Linux”: video uno e due di sei – “Introduzione” e “Cluster”
• Seminario “Evoluzione dell’alta affidabilita’ su Linux”: video tre e quattro di sei – “Heartbeat/Corosync” e “DRBD”
• Seminario “Evoluzione dell’alta affidabilita’ su Linux”: video cinque e sei di sei – “Il Progetto”

Un ringraziamento particolare a Lorenzo, per il preziosissimo supporto video che ci ha permesso di condividere l’evento con quanti non sono riusciti a partecipare.

Buona visione!

Ecco presentate le parti centrali del seminario di miamammausalinux.org, intitolato “Evoluzione dell’alta affidabilita’ su Linux” che si è svolto nella giornata del 24 giugno 2011, presso l’hotel Holiday Inn di Rho.

La terza parte introduce Heartbeat e Corosync, mentre nella quarta si approfondisce l’argomento DRBD.

Parte tre di sei – Heartbeat e Corosync:

Parte quattro di sei – DRBD:

Serie completa:

• Seminario “Evoluzione dell’alta affidabilita’ su Linux”: video uno e due di sei – “Introduzione” e “Cluster”
• Seminario “Evoluzione dell’alta affidabilita’ su Linux”: video tre e quattro di sei – “Heartbeat/Corosync” e “DRBD”
• Seminario “Evoluzione dell’alta affidabilita’ su Linux”: video cinque e sei di sei – “Il Progetto”

Un ringraziamento particolare a Lorenzo, per il preziosissimo supporto video che ci ha permesso di condividere l’evento con quanti non sono riusciti a partecipare.

Buona visione!

Nella giornata del 24 giugno 2011, presso l’hotel Holiday Inn di Rho si è svolto il primo seminario di miamammausalinux.org, intitolato “Evoluzione dell’alta affidabilita’ su Linux“.

Viste le numerose richieste ricevute e rispettando sempre la filosofia alla base del progetto miamammausalinux.org, il video del seminario viene proposto integralmente nelle sue sei parti, insieme alla documentazione fornita ai partecipanti.

Ecco le prime due parti.

Parte uno di sei – Introduzione:

Parte due di sei – Cluster:

Ed ecco il link alla documentazione:

Evoluzione dell'alta affidabilita' su Linux - Documentazione

Serie completa:

• Seminario “Evoluzione dell’alta affidabilita’ su Linux”: video uno e due di sei – “Introduzione” e “Cluster”
• Seminario “Evoluzione dell’alta affidabilita’ su Linux”: video tre e quattro di sei – “Heartbeat/Corosync” e “DRBD”
• Seminario “Evoluzione dell’alta affidabilita’ su Linux”: video cinque e sei di sei – “Il Progetto”

Un ringraziamento particolare a Lorenzo, per il preziosissimo supporto video che ci ha permesso di condividere l’evento con quanti non sono riusciti a partecipare.

Buona visione!

Nel precedente articolo “Introduzione alla virtualizzazione con KVM” sono stati introdotti gli aspetti base della virtualizzazione basata su KVM.
In questo articolo vedremo come implementare una completa soluzione di Virtualizzazione basata su KVM e Debian.

In particolare useremo Debian Squeeze, l’attuale release stable di Debian.

Prerequisiti

Per utilizzare KVM è necessario avere un processore dotato di estensioni per la virtualizzazione, per verificare che siano presenti è sufficiente lanciare il seguente comando:

# egrep -c '(vmx|svm)' /proc/cpuinfo
8

Se il comando (come nell’esempio) restituisce “1″ o un numero maggiore le estensioni sono state rilevate, mentre se restituisce 0, significa che il vostro processore non dispone di tali estensioni, quindi dovrete usare una soluzione differente come ad esempio Xen o VirtualBox.

Nel caso in cui vogliate creare VirtualMachine con un quantitativo di RAM superiore ai 2 GB è necessario avere un processore con architettura X86-64. Anche in questo caso possiamo estrarre questa informazione dal file /proc/cpuinfo:

# egrep -c ' lm ' /proc/cpuinfo
8

Anche in questo caso, se il comando (come nell’esempio) restituisce un numero diverso da 0, il vostro processore potrà eseguire software a 64 bit.

L’ulteriore componente in gioco è il kernel del vostro sistema, che deve essere compilato con il supporto ai 64 bit, per controllare è sufficiente lanciare ‘uname’:

# uname -m
x86_64

che dovrà restituire appunto “x86_64″.
Nel caso il vostro processore sia a 64 bit ma sistema operativo installato a 32, non preoccupatevi, non è necessario effettuare una nuova installazione. Linux infatti è in grado di far girare uno userland a 32 bit su un kernel a 64 bit e nei repository Debian per l’architettura i386 è presente proprio il pacchetto che ci interessa, installabile con un colpo di Apt:

# apt-get install linux-image-2.6-amd64

Al contrario delle estensioni per la virtualizzazione, non avere un processore x86_64 non pregiudica la funzionalità di KVM, semplicemente si potranno creare macchine virtuali con al massimo 2 Gb di RAM, quantitativo più che sufficiente per macchine virtuali di test.

Come ultimo prerequisito è necessario procurarsi un client VNC da installare sulla propria workstation, in questo caso si può proprio dire che uno vale l’altro, l’uso che se ne farà è davvero semplice e non richiede alcuna caratteristica avanzata.

Installazione e configurazione

Il processo di installazione è davvero molto semplice:

# apt-get install qemu-kvm libvirt-bin

APT scaricherà tutti i pacchetti necessari per preparare il vostro sistema alla virtualizzazione.

È possibile fare in modo che un utente non privilegiato possa creare e gestire le VM semplicemente aggiungendo l’utente al gruppo ‘libvirt’:

# adduser fpedrini libvirt

ed effettuare nuovamente la login al sistema per acquisire il nuovo gruppo.

Per verificare che tutto sia funzionante è necessario utilizzare il comando virsh, parte del pacchetto libvirt-bin:

# virsh --connect qemu:///system list

che mostrerà un output simile al seguente:

 Id Name                 State
----------------------------------
 
#

virsh è una shell interattiva che permette di gestire il proprio ambiente di virtualizzazione indipendentemente dall’Hypervisor (vedi precedente articolo) utilizzato, di cui comunque parleremo in maniera approfondita più avanti.

Come ultimo passo, per fare in modo che le virtual machine possano connettersi alla stessa rete presso cui il server è collegato, sarà necessario creare un bridge. Viceversa è possibile sfruttare le reti interne gestite da virsh via libvirt, ma questo tipo di configurazione non è trattata in questo articolo.
Per creare un bridge è necessario installare il pacchetto bridge-utils:

# apt-get install bridge-utils

E’ quindi sufficiente modificare la configurazione delle interfacce di rete in /etc/network/interfaces, creando una nuova stanza all’interno del file e fare in modo che l’interfaccia primaria diventi il bridge (per esempio br0):

auto br0
iface br0 inet static
        address 192.168.0.100
        network 192.168.0.0
        netmask 255.255.255.0
        broadcast 192.168.0.255
        gateway 192.168.0.1
        bridge_ports eth0
        bridge_fd 9
        bridge_hello 2
        bridge_maxage 12
        bridge_stp off

Oltre alle normali opzioni (address/network/broadcast/netmask e gateway) sono presenti anche le opzioni usate per la creazione del bridge, e la più importante è bridge_ports, che indica al sistema quale interfaccia fisica deve essere usata per la costruzione del bridge.

Riavviando il servizio di networking:

# /etc/init.d/networking restart

il bridge verrà attivato.

Creazione della prima Macchina Virtuale

Una volta installati i vari pacchetti necessari per la virtualizzazione e configurata la rete è possibile installare la prima virtual machine, sfruttando il comando virt-install.

Virt-install e’ un tool della suite di libvirt che permette di automatizzare i passaggi di base necessari alla creazione della VM, come ad esempio la creazione del file che fungerà da disco virtuale o la configurazione del file XML che contiene la definizione della Virtual Machine.

Se ad esempio volessimo installare una VM che faccia girare una nuova istanza di Debian Squeeze, il comando da lanciare sarà simile al seguente:

# virt-install --connect qemu:///system -n squeeze-vm -r 512 --vcpus=2 --disk path=/virtuals/squeeze-vm10.img,size=10 -c /dev/cdrom --vnc --noautoconsole --os-type linux --os-variant debiansqueeze --accelerate  --hvm --network=bridge:br0

Quello che all’inizio può sembrare un comando difficile e complesso, si rivela in realtà una lista di opzioni abbastanza facile da ricordare quando se ne conosce il significato:

• –connect qemu:///system indica a virt-install quale deve essere l’hypervisor target
• -n indica il nome della Virtual Machine, in questo caso squeeze-vm
• -r indica il quantitativo della ram virtuale in megabytes
• –vcpus=2 indica il quantitativo di cpu virtuali da assegnare alla VM. Test prestazionali indicano che su processori multicore come quelli odierni, assegnare più di due vcpu ad un sistema guest non porta ad alcun aumento di performance. Il numero di processori dedicati infatti serve semplicemente a far capire al sistema guest che sta girando in un ambiente SMP. Ci penserà l’hypervisor a dividere il carico sui core del sistema host
• –disk-path=/virtuals/squeeze-vm,size=10 indica a virt-install dove creare l’immagine per il disco virtuale e la sua dimensione. Può anche essere usato un dispositivo a blocchi (come ad esempio /dev/sdb1, la prima partizione del secondo disco del sistema host o un volume LVM), in questo caso l’opzione size non avrà alcun effetto.
• -c /dev/cdrom indica a virt-install il path dell’immagine di installazione del sistema guest. È possibile utilizzare anche un normale file .iso
• –vnc indica a virt-install di abilitare la console VNC non appena la macchina virtuale è stata creata.
• –os-type linux –os-variant debiansqueeze indicano a virt-install che tipo di sistema operativo verrà installato sul guest
• –accelerate –hvm indica a virt-install che il guest dovrà sfruttare l’accelerazione fornita da KVM. Ricordiamo che in realtà Qemu e KVM sono legati a doppio filo e il secondo può essere visto come un acceleratore per Qemu. inoltre la seconda opzione specifica che il guest dovrà essere un sistema completamente virtualizzato (e non paravirtualizzato come succederebbe con Xen)
• –network=bridge:br0 indica a virt-install quale sarà il bridge da usare per connettere questa virtual machine alla rete

Una volta premuto invio, l’output si presenterà in maniera simile alla seguente:

Starting install...
Creating domain...                                                                                                                                                      |    0 B     00:00     
Domain installation still in progress. Waiting for installation to complete.

a questo punto collegandosi mediante un client VNC (ad esempio vncviewer) al server è possibile completare l’installazione via console, come se si trattasse di una normale installazione Debian.

Dal momento che VNC non è un protocollo cifrato, è preferibile utilizzare un tunnel SSH (come spiegato in questo articolo) dalla propria workstation al server di virtualizzazione, puntando quindi il proprio client VNC alla porta aperta dal tunnel su localhost.

Gestione delle Virtual Machine

Gestire le virtual machine è possibile sempre mediante la comoda shell interattiva virsh di cui è stato fatto cenno poco sopra.

Virsh è il tool principe per la gestione delle macchine virtuali in quanto permette di eseguire con semplicità anche i compiti più complessi tramite una comoda interfaccia testuale.

Per lanciare virsh sarà necessario lanciare il comando:

# virsh --connect qemu:///system

Si presenterà quindi una vera e propria shell interattiva:

Welcome to virsh, the virtualization interactive terminal.
 
Type:  'help' for help with commands
       'quit' to quit
 
virsh #

Per ottenere la lista dei comandi disponibili è sufficiente scrivere help:

virsh # help
Commands:
 
    help            print help
    attach-device   attach device from an XML file
    attach-disk     attach disk device
    attach-interface attach network interface
    autostart       autostart a domain
    capabilities    capabilities
    cd              change the current directory
    connect         (re)connect to hypervisor
    ....
    version         show version
    vncdisplay      vnc display
    snapshot-create Create a snapshot
    snapshot-current Get the current snapshot
    snapshot-delete Delete a domain snapshot
    snapshot-dumpxml Dump XML for a domain snapshot
    snapshot-list   List snapshots for a domain
    snapshot-revert Revert a domain to a snapshot

I comandi disponibili per virsh sono moltissimi e permettono di gestire qualsiasi aspetto di una macchina virtuale, dal suo stato, alla gestione dei dischi virtuali, fino alla gestione delle reti interne.

I comandi sicuramente più utilizzati sono quelli relativi all’esecuzione di un guest, cioè list,start, shutdown e reboot, destroy, suspend e resume.

Tutti questi comandi risultano abbastanza autoesplicativi e, ad eccezione di list tutti necessitano del nome del sistema guest su cui dovranno agire. Il comando list invece accetta due parametri: –all e –inactive, che agiranno come filtri per visualizzare rispettivamente tutte le virtual machine o i soli guest inattivi, se invocato senza alcun parametro, verrà visualizzato l’elenco delle macchine virtuali avviate.

Come detto sopra, i comandi risultano abbastanza chiari, ma è bene fare attenzione ad un paio di dettagli, vediamo con ordine:

• start è sicuramente il più semplice, permette di avviare la virtual machine. In aggiunta, è utile citare il comando autostart che permette di comunicare a libvirt di avviare automaticamente le virtual machine all’avvio del sistema.
• shutdown permette di inviare al sistema guest un segnale di shutdown, simulando ciò che accade sulle macchine fisiche quando viene premuto il tasto di accensione
• reboot invia alla macchina virtuale il segnale di reboot che avvierà un processo di riavvio pulito del sistema.
• destroy fa in modo che il processo della virtual machine venga ucciso. Dal punto di vista della virtual machine questo è l’equivalente di un blackout, la corrente viene interrotta bruscamente. Ovviamente come succede per le macchine reali, questo comando potrebbe creare inconsistenze sul filesystem del guest anche se ovviamente non causerà alcun danno reale all’hardware
• suspend fa in modo che l’esecuzione della virtual machine venga interrotta. La ram rimarrà comunque occupata, ma la macchina virtuale non occuperà più alcuna risorsa relativa a CPU, HD e rete fino al resume.
• resume permette di far uscire la virtual machine dallo stato di ibernazione attivato con suspend

Menzione particolare meritano anche i comandi save e restore.
Save richiede, oltre al nome della virtual machine anche un parametro aggiuntivo, cioè il filename dove salvare lo stato del sistema guest. Al contrario di suspend, questo comando permette di salvare tutto ciò che concerne la virtual machine (ram, registri del processore, interrupts, eccetera, eccetera…) in un file, e terminare il processo del sistema guest. Questo fa si che una Virtual Machine possa essere spostata completamente da un host all’altro senza che il sistema e le applicazioni al suo interno ne risentano minimamente.
Restore, come la sua controparte richiede come parametro aggiuntivo il file da cui leggere lo stato della virtual machine da ripristinare.

Conclusioni

Questo articolo, per quanto lungo, rimane sempre e comunque una rapida introduzione al vasto argomento della virtualizzazione, tematica che grazie ai recenti miglioramenti di libvirt e dei tool a corredo sta diventando sempre più vasta e interessante.

Ciò nonostante credo che usando come base le informazioni qui contenute si possano creare ambienti di virtualizzazione in grado di competere (e in parecchi casi persino surclassare) le soluzioni di virtualizzazione proprietarie più blasonate.

Basti pensare che i grandi player del mondo della virtualizzazione (Amazon, RackSpace e Google, giusto per citare i più grandi) utilizzano soluzioni basate proprio sui software descritti in questo articolo.

Evoluzione dell’alta affidabilità su Linux
Venerdì 24 Giugno 2011
9:00 – 17:30
HOLIDAY INN MILAN RHO FAIR
Via Alessandro Volta, snc
20017 Rho Milano – Italy

Evoluzione dell'alta affidabilita' su Linux

Un seminario gratuito, che nel corso di una giornata tratterà di Linux, Opensource ed alta affidabilità, affrontando nel dettaglio argomenti quali Heartbeat, Corosync e DRBD per arrivare ad implementare nel laboratorio una soluzione NFS active-active completamente operativa.

L’evento è completamente gratuito e comprende il pranzo offerto da MMUL. I posti sono limitati a venti.

Per iscriversi, compilare il seguente form:

Per qualsiasi informazione, chiarimento o problema tecnico, scrivete una mail a info@miamammausalinux.org

Chi usa openLDAP si sara’ accorto che dalla versione 2.4 la configurazione e’ stata completamente stravolta passando dall’avere tutto in un unico file di configurazione, slapd.conf, ad una struttura ad albero tipica del database ldap.
Di seguito sono riportati i passi per configurare un consumer/proxy utilizzando il nuovo formato di configurazione cn=config.

Topologia.

Il sistema descritto in questo articolo consta di 3 server ldap, due di questi si trovano in rete di tipo trust (quindi affidabile) ed uno in dmz (ossia una rete demilitarizzata, che non contiene cioè dati sensibili).

Tali macchine verranno nominate server1, server2 e server3:

• server1 sarà il master, che, usando la nuova terminologia di openldap, diventa provider;
• server2 sarà il consumer, colui cioè che chiede aggiornamenti al provider e funzionerà da proxy, comunicando gli aggiornamenti al server3 che risiede in dmz;
• server3 risiederà in dmz;

Perché utilizzare un proxy? Per simulare il comportamento del vecchio slurpd, la componente che garantiva la replica del database ldap mediante una connessione dal provider al consumer. Il sistema di replica e’ cambiato, ora e’ il consumer che inizia la connessione col provider per avere gli aggiornamenti.
Finché i server stanno nella stessa rete non esiste nessun problema, ma se un server risiede in dmz e uno è nella rete trust non e’ opportuno aprire un passaggio tra le due reti, si dovrà quindi simulare il comportamento del vecchio slurpd e cioè sarà il consumer/proxy ad iniziare la connessione col server in dmz. Il traffico sarà quindi dalla rete trust alla rete dmz, come e’ gusto che sia, e non dalla rete dmz alla rete trust.

server1 e server3 montano una distribuzione Debian Lenny quindi la configurazione di slapd non è cambiata, mentre nel server2 invece è stato effettuato un aggiornamento da Debian Lenny a Debian Squeeze, che ha quindi implicato l’aggiornamento all’ultima versione del pacchetto openldap, che ha imposto il riadattamento della vecchia configurazione nel nuovo formato.

Opzionale: importare gli schema.

Se, oltre agli schema già inclusi di default, si volessero includere degli altri schema, come ad esempio phamm.schema bisognerà operare come segue:

• All’interno della directory /etc/ldap/schema sarà necessario creare un file, ad esempio schema_convert.conf ed inserire le seguenti righe:

  include core.schema
  include cosine.schema
  include inetorgperson.schema
  include phamm.schema

• Creare una directory di appoggio, ad esempio ldif_out, ed utilizzare il comando slaptest per popolare la directory:

  # mkdir ldif_out
  # slaptest -f  schema_convert.conf -F ldif_out.

• All’interno della directory ldif_out/cn=config/cn=schema modificare il file cn={x}phamm.ldif (al posto di x ci sarà un numero) eseguendo le seguenti modifiche:

  dn: cn={x}phamm

  verrà modificato in:

  dn: cn=phamm,cn=schema,cn=config, cn={x}phamm diventa cn=phamm

  infine, le ultime righe del file andranno cancellate:

  structuralObjectClass: olcSchemaConfig
  entryUUID: dded7120-64a0-102f-86a3-0507262554d4
  creatorsName: cn=config
  createTimestamp: 20101005074946Z
  entryCSN: 20101005074946.106061Z#000000#000#000000
  modifiersName: cn=config
  modifyTimestamp: 20101005074946Z

  Salvando quindi il file.

A questo punto sarà necessario lanciare il comando ldapadd:

# ldapadd -Y EXTERNAL -H ldapi:/// -f ldif_out/cn\=config/cn\=schema/cn\=\{x\}phamm.ldif

In modo da importare definitivamente lo schema.

Configurazione consumer per la replica:

Per configurare il server2 (consumer) sarà necessario creare un file nominato, ad esempio, syncpreplDbHdb.ldif all’interno della directory /etc/slapd.d con il seguente contenuto:

dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcSyncRepl
olcSyncrepl: rid=001 provider=ldap://server1:389 bindmethod=simple timeout=0 network-timeout=0 binddn="cn=replicant,dc=example,dc=com" credentials="xxx” keepalive=0:0:0 starttls=no filter="(objectclass=*)" searchbase="dc=example,dc=com" scope=sub schemachecking=off type=refreshAndPersist retry="60 10 300 +"

Come si può notare è stata utilizzata un’utenza ad hoc per la replica: cn=replicant,dc=example,dc=com. Attraverso il comando slapadd, sarà possibile includere la nuova configurazione all’interno del database ldap:

ldapadd -Y external -H ldapi:/// -f syncreplDbHdb.ldif.

La configurazione prosegue con l’aggiunta dei moduli necessari alla replica e la creazione degli indici.

Per aggiungere i moduli syncprov.la e back_ldap.la, necessari alla replica, basterà creare un file nominato, ad esempio, modules.ldif il cui contenuto dovrà essere:

n.b. il modulo back_ldap e’ necessario solo al consumer che opera anche come proxy.

dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov.la
-
add: olcModuleLoad
olcModuleLoad: back_ldap.la

Aggiungendo, come già fatto, il file ldif attraverso il comando ldapadd:

# ldapadd -Y external -H ldapi:/// -f modules.ldif.

L’aggiunta degli indici prevede la creazione di un file nominato, ad esempio, indexes.ldif con il seguente contenuto:

dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: entryUUID eq
-
add: olcDbIndex
olcDbIndex: entryCSN eq

per poi lanciare, come di consueto, il comando ldapadd:

# ldapadd -Y external -H ldapi:/// -f indexes.ldif.

Overlay syncprov (sync provider)

Gli overlay sono componenti software che servono per aggiungere funzionalità al database senza che sia necessario riscrivere un nuovo backend per gestirle, è possibile pensarlo come ad una sorta di plugin.

L’overlay syncprov deve essere definito per ogni macchina che funge da provider, siccome il consumer definito nell’articolo e’ anche il provider di se stesso, in quanto comunica gli aggiornamenti al database ldap che e’ il proxy (definito sotto), è necessario definire l’overlay synprov anche per il consumer.

Creare un file, ad esempio overlayDbHdb.ldif, con il seguente contenuto:

dn: olcOverlay=syncprov,olcDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpCheckpoint: 100 10
olcSpSessionlog: 100

come ormai chiaro, sarà necessario lanciare nuovamente il comando ldapadd:

# ldapadd -Y external -H ldapi:/// -f overlayDbHdb.ldif

Aggiunta del database ldap:

Per completare la configurazione sarà necessario aggiungere il database ldap. Il database ldap serve per fare in modo che il server agisca da proxy ed effettui il forward delle richieste ad un altro server ldap, in questo caso verso server3 in dmz.

Il database ldap verrà creato come di consueto attraverso un file nominato databaseLdap.ldif con il seguente contenuto:

dn: olcDatabase=ldap,cn=config
objectClass: olcDatabaseConfig
objectClass: olcLDAPConfig
olcDatabase: ldap
olcHidden: TRUE
olcSuffix: dc=example,dc=com
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRestrict: bind
olcRestrict: add
olcRestrict: modify
olcRestrict: rename
olcRestrict: delete
olcRestrict: search
olcRestrict: compare
olcRestrict: extended
olcRootDN: cn=admin,dc=example,dc=com
olcSyncrepl: rid=002 provider=ldap://localhost:389 bindmethod=simple timeout=0 network-timeout=0 binddn="cn=replicant,dc=example,dc=com" credentials="xxxx" keepalive=0:0:0 starttls=no filter="(objectclass=*)" searchbase="dc=example,dc=com" scope=sub schemachecking=off type=refreshAndPersist retry="60 10 300 +"
olcDbURI: "ldap://server3:389"
olcDbACLBind: bindmethod=simple timeout=0 network-timeout=0 binddn="cn=replicant,dc=example,dc=com" credentials="xxxx" keepalive=0:0:0

ed importato quindi con ldapadd:

# ldapadd -Y external -H ldapi:/// -f databaseLdap.ldif

Infine sarà necessario aggiungere l’overlay syncprov anche al database ldap, creando un file overlayDbLdap.ldif:

dn: olcOverlay=syncprov,olcDatabase={2}ldap,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov

eseguendo nuovamente il comando ldapadd:

# ldapadd -Y EXTERNAL -H ldapi:/// -f overlayDbLdap.ldif

Si completa così la configurazione di un consumer/proxy.

Conclusioni

Sulla base delle informazioni di questo articolo è possibile ricavare in autonomia la procedura per aggiornare anche il provider ed il server in dmz.
Nei successivi articoli verranno illustrate le configurazione complete degli altri server, in modo da completare l’argomento dell’upgrade di openldap.

Finalmente, dopo mesi di interminabile attesa, gli sviluppatori del progetto hanno ufficializzato l’uscita della nuova release del sistema operativo Debian GNU/Linux: Squeeze, la release 6.0.
Indicata da molti come la migliore Debian di sempre senza proclami altisonanti è forse il caso di sottolineare come questa release del sistema operativo abbia effettivamente numerose frecce all’arco, nell’ambito Desktop e, soprattutto, nell’ambito Server.
In particolare tra i software di natura Enterprise, vanno citati:

Sistema:
* GNU Compiler Collection 4.4.5
* Linux 2.6.32

Database:
* PostgreSQL 8.4.6
* MySQL 5.1.49

Web:
* Apache 2.2.16
* OpenJDK 6b18
* Tomcat 6.0.18

Integrazione:
* Samba 3.5.6

Monitoring:
* Nagios 3.2.3

Clustering:
* Pacemaker 1.0.9
* Heartbeat 3.0.3
* Corosync 1.2.1

Virtualizzazione:
* Xen Hypervisor 4.0.1 (con il supporto per dom0 e per domU)
* Qemu-KVM 0.12.5
* libvirt 0.8.3

Come è facile intuire, questa nuova Debian risulta certamente una scelta vincente in ambiti produttivi professionali. Tutte le informazioni su come scaricare, installare ed utilizzare questa nuova Debian sono sul rinnovato sito ufficiale:

http://www.debian.org/distrib/

Un nuovo importante capitolo è stato quindi aggiunto alla storia dei sistemi operativi!

Buon lavoro a tutti

Tomcat è un Application Server: un contenitore di applicazioni sviluppate attraverso il linguaggio di programmazione Java. Tomcat viene impiegato generalmente per l’esposizione di web service e questa sua attitudine, in caso di applicazioni critiche per importanza, deve essere obbligatoriamente associata all’alta affidabilità. Esso nativamente supporta un modello di cluster, che consente a diverse istanze di condividere le sessioni, in modo da garantire la sopravvivenza del servizio: se quindi un’istanza smette di funzionare, il suo ruolo viene assunto dall’istanza sopravvissuta.
Ma chi si occupa del controllo delle istanze stesse?
Questo articolo descrive un caso di studio relativo ad un cluster nativo Tomcat le cui istanze vengono gestite da Heartbeat attraverso il Cluster Resource Manager Pacemaker.

Installazione di Java

Java è essenziale per il funzionamento di Tomcat ed è anche il primo software da configurare per ottenere il risultato prefissato in questo articolo. Per prima cosa quindi sarà necessario scaricare il pacchetto di installazione dal sito ufficiale di SUN presso il link http://www.java.com/it/download/linux_manual.jsp?locale=it&host=www.java.com.
Ottenuto il file jre-6u23-linux-i586.bin, il cui nome potrà variare a seconda della versione, questo va eseguito:

# chmod +x jre-6u23-linux-i586.bin 
# ./jre-6u23-linux-i586.bin

L’esecuzione del file creerà una cartella nominata jre1.6.0_23 che sarà possibile spostare in un path consono, ad esempio /usr/local, per il quale potrà essere creato un link simbolico:

# mv jre1.6.0_23 /usr/local
# ln -s /usr/local/jre1.6.0_23 /usr/local/java

In questo modo sarà possibile far riferimento al path /usr/local/java per il raggiungimento degli eseguibili java ed inoltre, in caso di installazioni di versioni diverse di Java, basterà cambiare il puntamento del link simbolico.

Installazione di Tomcat

L’installazione di Tomcat viene descritta in maniera generalista, indipendente quindi dalla distribuzione utilizzata.
Per prima cosa quindi è necessario scaricare l’ultima versione dell’application server Tomcat, andando sul sito ufficiale di Tomcat (http://tomcat.apache.org/download-70.cgi) oppure scaricando il pacchetto da uno dei mirror:

# wget http://it.apache.contactlab.it/tomcat/tomcat-7/v7.0.6/bin/apache-tomcat-7.0.6.tar.gz -o /tmp/apache-tomcat-7.0.6.tar.gz

una volta terminato lo scaricamento, è possibile decomprimere il pacchetto in un path di sistema, ad esempio (e per convenzione) /usr/local:

# cd /usr/local
# tar -xzvf /tmp/apache-tomcat-7.0.6.tar.gz
# ln -s apache-tomcat-7.0.6 tomcat

L’ultimo comando lanciato crea un link simbolico, in modo che in futuro per accedere alla directory di Tomcat sarà sufficiente utilizzare il percorso /usr/local/tomcat.

Installazione di Heartbeat e Pacemaker

L’installazione dell’apparato cluster offerto dal progetto Linux-ha non verrà descritta in questo articolo, in quanto ampiamente trattata nei precedenti articoli della serie, in particolare nella puntata confronto pratico tra Heartbeat classico ed Heartbeat con Pacemaker.

Configurazione di Tomcat

La configurazione prevede due fasi: la prima relativa alle credenziali di accesso, la seconda relativa alle impostazioni per il clustering.
All’interno del file /usr/local/tomcat/conf/tomcat-users.xml sono definite le utenze di accesso alle diverse componenti dell’application server, in particolare, per permettere all’utente tomcat di gestire l’installazione di nuove applicazioni attraverso l’interfaccia web disponibile, il contenuto del file dovrà essere il seguente:

<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
  <role rolename="tomcat"/>
  <role rolename="manager-gui"/>
  <user username="tomcat" password="tomcat" roles="manager,manager-gui,tomcat"/>
</tomcat-users>

Inutile dire come il campo password debba essere modificato in base alla password scelta.
L’abilitazione del cluster Tomcat, data la natura introduttiva dell’articolo, verrà fatta nella modalità più semplice, così come illustrato dalla documentazione ufficiale di Tomcat (http://tomcat.apache.org/tomcat-7.0-doc/cluster-howto.html), abilitando cioè la seguente riga all’interno del file /usr/local/tomcat/conf/server.xml:

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>

La configurazione preliminare dell’application server è così completa.

Configurazione di Heartbeat e Pacemaker

Appena avviato il demone Heartbeat:

# /etc/init.d/heartbeat start

è possibile definire le configurazioni preliminari del cluster:

# crm configure property stonith-enabled="false"
# crm configure property no-quorum-policy="ignore"
# crm configure primitive ping ocf:pacemaker:ping params host_list="192.168.0.254" name="ping" op monitor interval="10s" timeout="60s" op start timeout="60s" op stop timeout="60s"
# crm configure clone ping_clone ping meta globally-unique="false"

Come spiegato nei precedenti articoli queste configurazioni preliminari indicano di non utilizzare stonith, ignorare l’assenza di quorum e creare una risorsa ping che controlli la connettività in entrambi i nodi attraverso il clone della risorsa stessa.
Maggiori informazioni e spiegazioni approfondite si trovano nella seconda parte del secondo articolo della serie.
In particolare l’ultima definizione, ossia la risorsa clonata per il controllo della connettività, favorisce lo spunto per la configurazione della risorsa Tomcat per la quale esiste un resource agent apposito: http://www.linux-ha.org/doc/re-ra-tomcat.html. Essendo obiettivo del progetto la gestione per mezzo di Pacemaker delle istanze di Tomcat, ed essendo le istanze di Tomcat in tutto e per tutto simili su entrambi nodi, queste potranno essere assimilate ad un’unica risorsa clonata.
Nel dettaglio, la configurazione sarà la seguente:

1
2
3

crm configure primitive cluster_tomcat ocf:heartbeat:tomcat params java_home="/usr/local/java/" catalina_home="/usr/local/tomcat/" op monitor interval="60s" timeout="30s" op start interval="0" timeout="60s" op stop interval="0" timeout="120s"
crm configure clone cluster_tomcat_clone cluster_tomcat meta globally-unique="false" target-role="Started"
crm configure location cluster_tomcat_on_connected_node cluster_tomcat_clone -inf: not_defined ping or ping lte 0

Nel dettaglio:

1. Viene definita la risorsa cluster_tomcat i cui parametri sono il path in cui è installato Java (java_home) ed il path di tomcat stesso (catalina_home);
2. La risorsa cluster_tomcat viene clonata dalla nuova risorsa cluster_tomcat_clone. Così come per la risorsa ping_clone che risiederà su ciascun nodo definito, anche questa avrà lo stesso comportamento;
3. Viene definita una location, ossia un vincolo che obbliga la risorsa clonata a funzionare unicamente sui nodi la cui connettività è comprovata (nodi su cui cioè la risorsa ping esiste e restituisce un risultato positivo);

A questo punto, la situazione del cluster dovrebbe essere la seguente:

============
Last updated: Mon Jan 24 10:17:05 2011
Stack: Heartbeat
Current DC: tomcatcluster-nodo2 (b091eddc-aa64-4d7d-8407-65a7dddafbdf) - partition with quorum
Version: 1.0.10-da7075976b5ff0bee71074385f8fd02f296ec8a3
2 Nodes configured, unknown expected votes
2 Resources configured.
============
 
Online: [ tomcatcluster-nodo1 tomcatcluster-nodo2 ]
 
 Clone Set: ping_clone
     Started: [ tomcatcluster-nodo1 tomcatcluster-nodo2 ]
 Clone Set: cluster_tomcat_clone
     Started: [ tomcatcluster-nodo1 tomcatcluster-nodo2 ]

Ed entrambe le istanze di Tomcat dovrebbero essersi avviate su ciascun nodo. E’ possibile verificarlo provando ad accedere all’interfaccia web di amministrazione presente su ciascun nodo:

http://tomcatcluster-nodo1:8080/manager/html
http://tomcatcluster-nodo2:8080/manager/html

Entrambi link dovrebbero essere funzionanti e richiedere uno username con password per accedervi. Una volta inserite le credenziali definite in fase di configurazione di Tomcat, sarà visibile l’interfaccia di amministrazione delle applicazioni.

Analisi dei log

L’avvio dei servizi Tomcat da parte del cluster può essere seguito dai file di log dell’application server stesso, all’interno dei quali è possibile verificare se il cluster nativo di Tomcat viene attivato correttamente.

# cat /usr/local/tomcat/logs/catalina.out
...
INFO: Cluster is about to start
...
INFO: Setting cluster mcast soTimeout to 500
...
INFO: Server startup in 3153 ms
...
21-gen-2011 17.05.47 org.apache.catalina.ha.tcp.SimpleTcpCluster memberAdded
INFO: Replication member added:org.apache.catalina.tribes.membership.MemberImpl[tcp://{192, 168, 0, 1}:4000,{192, 168, 0, 2},4000, alive=1259, securePort=-1, UDP Port=-1, id={101 64 89 59 2 -44 67 123 -73 23 4 -50 -57 105 8 58 }, payload={}, command={}, domain={}, ]
...

Il server è avviato e certamente ha considerato la configurazione, includendo l’host (memberAdded) 192.168.0.52 nel cluster.

Configurazione applicazione di Test

La configurazione può dirsi completa. E’ possibile quindi installare una semplice applicazione di test per verificare nell’effettivo il funzionamento delle sessioni condivise. Per fare ciò è sufficiente creare un’applicazione configurata con il parametro “” che indica al cluster di sfruttare la configurazione cluster per la condivisione delle sessioni.
L’applicazione TestSession, scaricabile dal portale è stata configurata proprio a questo scopo:

TestSession

Una volta scaricato il file TestSession.war, attraverso la console Tomcat e su ciascun nodo, sarà possibile installare l’applicazione nella sezione “WAR file to deploy”, selezionando il fie “war” scaricato e premendo il tasto “deploy”. Se l’esito sarà “OK”, entrambe le applicazioni saranno disponibili attraverso l’indirizzo:

http://tomcatcluster-nodo1:8080/TestSession
http://tomcatcluster-nodo2:8080/TestSession

E’ possibile dunque avviare i test.

Test di funzionamento

Il principio di funzionamento del cluster è quello di rispondere alle richieste. Generalmente in questo tipo di architettura, gli Application Server risiedono dietro a bilanciatori, cioè apparati hardware o software che distribuiscono il carico attraverso batterie di macchine che offrono servizi.
L’architettura di test predisposta non prevede l’utilizzo di un bilanciatore, a per simulare il bilanciamento del carico tra i due host sarà sufficiente inserire nel file /etc/hosts della propria macchina queste due righe:

192.168.0.1 tomcatcluster
#192.168.0.2 tomcatcluster

Come scritto in precedenza quindi, l’applicazione potrà essere chiamata come segue, senza far riferimento all’IP:

http://tomcatcluster:8080/TestSession/

Il test funzionerà in modo che chiamato l’url relativo al quale si passa un parametro, ad esempio:

http://tomcatcluster:8080/TestSession/session.jsp?aaa=111

la pagina visualizzi quanto segue:

Server info
 
    * Name: tomcatcluster-nodo1
    * Address: 192.168.0.1
 
Session Attributes
 
    * aaa = 111

Ovviamente le chiamate successive con parametri differenti aggiungeranno nuovi attributi.
Nella fattispecie, chiamare:

http://tomcatcluster:8080/TestSession/session.jsp?bbb=222

produrrà:

Server info
 
    * Name: tomcatcluster-nodo1
    * Address: 192.168.0.1
 
Session Attributes
 
    * aaa = 111
    * bbb = 222

Il test a questo punto è semplicissimo, modificando il file /etc/hosts in modo che appaia come segue:

#192.168.0.1 tomcatcluster
192.168.0.2 tomcatcluster

Di fatto il secondo nodo ora sarà quello attivo. Richiamando nuovamente lo script:

http://tomcatcluster:8080/TestSession/session.jsp?ccc=333

Si otterrà il seguente output:

Server info
 
    * Name: tomcatcluster-nodo2
    * Address: 192.168.0.2
 
Session Attributes
 
    * aaa = 111
    * bbb = 222
    * ccc = 333

Da notare come nel Server info ora il nodo sia tomcatcluster-nodo2, mentre i dati di sessione sono stati mantenuti.

Il corretto funzionamento è verificabile anche accedendo singolarmente a ciascun tomcat ai link presenti nella pagina manager nella colonna “Sessions”, dove vengono elencate le sessioni, che ovviamente hanno lo stesso codice su entrambi gli Application server.

Conclusioni

Terminata questa carrellata di concetti e test una cosa è chiara: come sempre questo è solo l’inizio. Sono moltissimi gli ambiti in cui soluzioni come (o simili) a quella presentata possono essere messe in produzione per ottenere infrastrutture stabili, sicure e funzionali. Sempre e comunque altamente affidabili.