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

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.

Questo articolo illustra come ottenere un’installazione coerente di un fileserver Linux basato su SAMBA, che amministri l’accesso alle condivisioni attraverso utenti che appartengano a gruppi di sistema, gestiti in una forma riconoscibile.
Gli utenti, pur essendo a tutti gli effetti parte del sistema, avranno permessi di accesso unicamente attraverso il protocollo CIFS, gestito dalle macchine Microsoft Windows.

Installazione di SAMBA

La procedura descritta fa riferimento al sistema operativo Ubuntu Server 10.4, ed all’ultima release stabile disponibile in esso per il progetto libero SAMBA, la versione 3.4.7.
L’installazione per Ubuntu ed i sistemi Debian, può essere effettuata come di consueto:

# apt-get install samba

mentre nei sistemi che fanno uso di rpm e di yum il comando sarà invece:

# yum install samba

Prima di effettuare qualsiasi operazione è bene salvare il file di configurazione originale di SAMBA:

# cd /etc/samba
# mv smb.conf smb.conf.org

nel corso dell’articolo partiremo da un file completamente vuoto, per sottolineare come sia possibile impostare pochi parametri per essere operativi nel minor tempo possibile.

Configurazione di SAMBA (impostazioni globali)

Le configurazioni descritte fanno hanno come presupposto il fatto che l’utente con cui si sta operando all’interno del sistema sia “root”. Attraverso l’editor preferito sarà possibile creare un nuovo file smb.conf:

# sudo su -
# vi /etc/samba/smb.conf

All’interno del quale dovranno essere impostati i seguenti parametri:

[global]
   security = user
   workgroup = NETWORK.LOCAL
   server string = %h server (Samba, Ubuntu) 
 
   wins support = yes 
   dns proxy = no 
 
   log file = /var/log/samba/log.%m 
   max log size = 1000 
   syslog = 0 
 
   encrypt passwords = true 
   passdb backend = tdbsam
 
   directory mask = 2770 
   create mask = 0660

Le configurazioni indicano che il server è di tipo standalone (security = user), ossia non collegato a sistemi di autenticazione centralizzati. Il server è parte del gruppo di lavoro “NETWORK.LOCAL” (opzione workgroup, che andrà modificata a seconda delle impostazioni relative propria rete Microsoft Windows) e funzionerà da server WINS (wins support = yes) in modo da gestire la risoluzione dei nomi Microsoft Windows per la rete, ma non controllerà però i nomi effettuando query sul server dns di sistema (dns proxy = no).
Il sistema registrerà un log per ciascuna macchina che si collegherà (log file = /var/log/samba/log.%m), tale log non potrà eccedere un megabyte di grandezza (max log size = 1000). Inoltre nessuna informazione verrà registrata nel file /var/log/syslog (syslog = 0), il file di log generale relativo al sistema. Tutte le informazioni relative all’esecuzione del demone saranno reperibili all’interno del file /var/log/samba/log.smbd.
Il sistema di autenticazione cripterà le password (encrypt passwords) ed utilizzerà il backend tdbsam (opzione passdb backend), ossia il database locale.
Le ultime due opzioni indicate definiscono la maschera attraverso la quale verranno create le directory (directory mask = 2770) ed i file (create mask = 0660). Le directory verranno quindi create con permessi di lettura, scrittura ed esecuzione per il proprietario ed il gruppo, mentre per tutti gli altri saranno inaccessibili. I file verranno creati con i medesimi permessi ad eccezione dell’esecuzione.
Particolarità aggiuntiva della modalità di creazione delle cartelle è quella di possedere il bit setgid (http://it.wikipedia.org/wiki/Setuid_e_setgid) che impone l’appartenenza al gruppo della cartella padre per tutti i file e le cartelle create al suo interno. Questo significa che chiunque appartenga al gruppo della cartella padre potrà creare file e cartelle al suo interno, tali file e cartelle apparterranno al gruppo della cartella padre. In questo modo i permessi specifici di accesso per i gruppi definiti nelle cartelle governeranno la totalità degli accessi.

Configurazione di un gruppo

Ciascun gruppo di accesso verrà nominato in questo modo:

# groupadd samba_rwx_Amministrazione

Il criterio con cui i gruppi vengono creati e nominati è ottenibile scomponendo il nome attraverso i caratteri “_” (underscore), dove “samba” indica che il gruppo è inerente al servizio samba, “rwx” indica il tipo di accesso che può essere appunto “rwx” (permessi di lettura e scrittura) o “rx” (sola lettura), mentre “Amministrazione” indica il nome della condivisione a cui il gruppo si riferisce.

Aggiunta di un’utenza

Ogni utenza creata nel sistema che farà riferimento al servizio samba, avrà come gruppo primario samba, con identificativo “999″, creato con il seguente comando:

# groupadd -g 999 samba

In questo modo, la separazione degli ambiti operativi sarà oltre che configurata nel sistema, anche ben visibile.
Per aggiungere un’utenza al sistema i passi da compiere sono quindi i seguenti:

1. Lanciare il comando:

   # useradd -g samba -s /bin/false -d -c "Utente di test" user1

   In cui user1 rappresenta il nome attraverso il quale l’utente dovrà accedere alle condivisioni. A user1 viene assegnato il gruppo primario “samba” (-g samba), una shell di login nulla in modo che non possa mai effettuare il login nel sistema (-s /bin/false) ed una breve descrizione dell’utenza (-d, generalmente nome e cognome, oppure un indicativo della funzione svolta).

2. L’utente creato va poi aggiunto al database locale SAMBA, attraverso questo comando:

   # smbpasswd -a user1

   indicando per due volte la password scelta, che può essere anche omessa nel caso in cui lo si decida (è sempre consigliabile inserirne una).

3. L’utente va quindi aggiunto ad uno dei gruppi disponibili. Aggiungere utenti al gruppo è possibile con il seguente comando:

   # adduser user1 samba_rwx_Amministrazione

Per controllare quali utenti appartengono al gruppo è sufficiente digitare il seguente comando:

# cat /etc/group | grep "samba_rwx_Amministrazione"
samba_rwx_Amministrazione:user1,user2,user3

Mentre per controllare un singolo utente a quali gruppi appartiene, il comando sarà invece:

# groups user1
user1 : samba samba_rwx_Amministrazione

Aggiunta di una condivisione

Ciascuna condivisione fa riferimento ad un path locale, nel caso descritto viene creata una cartella /share:

# mkdir /share

al di sotto della quale tutte le cartelle condivise verranno create:

1
2
3

# mkdir /share/Amministrazione
# chgrp samba_rwx_Amministrazione /share/Amministrazione
# chmod 2770 /share/Amministrazione

Queste operazioni andranno eseguite per ciascuna nuova condivisione creata e si riassumono come segue:

1. Creazione effettiva della cartella;
2. Assegnazione della cartella al gruppo creato;
3. Impostazione del permesso setgid (vedi sopra) ricorsivo sulla cartella appena creata;

Le condivisioni verranno definite nel file di configurazione smb.conf in coda alle dichiarazioni globali, in un formato simile al seguente:

[Amministrazione] 
comment = Amministrazione 
read only = no 
write list = @samba_rwx_Amministrazione
read list = 
path = /share/Amministrazione

Il codice illustrato definisce una condivisione denominata “Amministrazione” a cui possono accedere in scrittura nella directory “/share/Amministrazione” unicamente gli utenti appartenenti al gruppo “samba_rwx_Amministrazione”.

Pertanto, per aggiungere una condivisione sarà quindi sufficiente eseguire la creazione e l’assegnazione dei permessi come descritto sopra ed inserire all’interno del file /etc/samba/smb.conf una dichiarazione seguendo il modello indicato:

[<NOMECONDIVISIONE>] 
comment = <Descrizione condivisione>
read only = no 
write list = @<gruppo con permessi di scrittura>
read list = @<gruppo con permessi di lettura>
path = <path della condivisione>

Nel caso l’accesso venga deciso unicamente in lettura o unicamente in scrittura, è possibile omettere le righe relative (write list o read list) dalla dichiarazione.

Attivazione delle configurazioni

Per applicare le nuove configurazioni, il servizio SAMBA necessita di essere ricaricato:

# service smbd reload

Da questo momento in poi sarà possibile utilizzare una qualsiasi macchina Microsoft Windows per testare l’effettivo successo delle configurazioni impostate.

Note

Quanto descritto consente di configurare SAMBA affinché possa interagire con client o server Microsoft Windows come se fosse un file e print server Microsoft.
E’ possibile variare le configurazioni in modo che SAMBA agisca da Primary Domain Controller (PDC), Backup Domain Controller o prendere parte ad un dominio Active Directory.
Sul portale tecnico sono disponibili diversi articoli che approfondiscono questi argomenti:

Realizzare un Primary Domain Controller con SAMBA, Openldap e smbldap-tools : (1 di 6)
Realizzare un Primary Domain Controller con SAMBA, Openldap e smbldap-tools : (2 di 6)
Realizzare un Primary Domain Controller con SAMBA, Openldap e smbldap-tools : (3 di 6)
Realizzare un Primary Domain Controller con SAMBA, Openldap e smbldap-tools : (4 di 6)
Realizzare un Primary Domain Controller con SAMBA, Openldap e smbldap-tools : (5 di 6)
Realizzare un Primary Domain Controller con SAMBA, Openldap e smbldap-tools : (6 di 6)

Samba e Active Directory (1 di 3): diventare parte di un Dominio
Samba e Active Directory (2 di 3): interrogare il dominio
Samba e Active Directory (3 di 3): configurare pam per l’autenticazione locale

In attesa quindi di saggiare le meraviglie dell’annunciato SAMBA 4, che conterrà un motore interno volto ad eguagliare l’efficienza e la funzionalità di Microsoft Active Directory, è chiaro come sia già possibile adottare SAMBA in ambiti produttivi di svariato genere, con successo, e senza costi di licenza.

Nel precedente articolo è stato effettuato un confronto tra le tipologie possibili di utilizzo relativo ad Heartbeat, nella modalità classica ed in quella mediante CRM (Cluster Resource Manager) per l’erogazione in alta affidabilità del servizio Apache.
In quest’ultimo articolo verrà proposto un vero case study relativo alla configurazione di un cluster erogante uno storage NFS in alta affidabilità i cui dati verranno ridondati via DRBD (Network Raid 1), mediante la configurazione di Pacemaker.
Peculiarità del progetto sarà l’utilizzo per l’erogazione delle directory NFS di entrambi i nodi, in modo da sfruttare tutte le macchine presenti, per un cluster di tipo active-active.

Il progetto

Quanto si propone di realizzare è un sistema in alta affidabilità che consenta di impiegare tutte le macchine presenti all’interno del cluster per rendere disponibile spazio all’interno di una rete. In altre parole, un Network Attached Storage (NAS), un’entità composta da due macchine collegate alla rete che consentano a dei client di montare le partizioni e fruire dello spazio reso disponibile.
Le componenti impiegate all’interno del progetto saranno:

1. Heartbeat e Pacemaker: per la gestione del cluster;
2. DRBD: per la replica dei dati fra le due macchine attraverso un network raid 1;
3. NFS: per la condivisione attraverso la rete dello spazio;

Il progetto si rifà nelle sue fondamenta a quanto illustrato nella seconda parte del precedente articolo e, se non lo si è ancora fatto, è bene dare una rapida lettura in modo da poter applicare i concetti lì illustrati senza perplessità.
Il cluster verrà costruito su due sistemi (debian-lenny-nodo1 e debian-lenny-nodo2) collegati ciascuno alla rete locale (192.168.1.0/24) e l’uno all’altro da un cavo cross (10.0.0.0/24, connessione necessaria per realizzare il network raid 1 con DRBD), lo spazio locale verrà esportato attraverso il protocollo NFS. In particolare verranno definite due condivisioni distinte, corrispondenti a due cartelle locali chiamate /share-a e /share-b.
Obiettivo ultimo è quello di ottenere ciascuna condivisione esportata da un nodo, in modo da avere (a regime ed in condizioni ottimali) un cluster in cui nessun nodo risulti passivo.
Unico requisito richiesto sui nodi è la presenza dei pacchetti heartbeat e pacemaker (la cui installazione è descritta nell’articolo precedente) e del demone NFS. Nei sistemi Debian ed Ubuntu sarà quindi necessario installare il pacchetto nfs-kernel-server mentre in RedHat/SuSe il pacchetto sarà nfs.

La gestione locale dei dati: device, md, LVM o tutti e tre?

Prima di iniziare a configurare il cluster è bene decidere come verranno gestiti sulle macchine i dati che andranno esposti. Questa scelta, la più delicata poiché intacca direttamente le performance, va fatta sulla base dell’hardware disponibile, partendo da tre ambiti operativi:

• device: partizioni fisiche (ad esempio /dev/sda3, /dev/sda4 e via dicendo);
• md (Multiple Disk): gestione locale dei raid, i dati sono ridondati sulle singole macchine (oltre che in rete);
• LVM (Logical Volume Manager): volumi logici, per una gestire più elastica dello spazio locale;

Partendo dal presupposto che l’utilizzo dei device è indispensabile (visto che si sta parlando di dischi locali), scegliere se configurare raid locali o LVM dipende da quanto si dispone.
Se le macchine utilizzate possiedono una controller RAID hardware, allora si potrà evitare di configurare i dispositivi md, così come se si ritiene la ridondanza locale superflua (del resto i dati verranno comunque ridondati in rete).
Se il sistema necessiterà di frequenti variazioni in termini di spazio sulle partizioni esposte sarà doveroso impiegare volumi logici in modo da gestire con facilità operazioni di ridimensionamento. Inoltre la gestione dei volumi logici potrebbe essere preferita dai più, proprio per la semplicità con cui è possibile apportare variazioni allo spazio disponibile, soprattutto in situazioni complesse.
Lampante è come più livelli di complessità si aggiungono, maggiore sarà il carico che graverà sul sistema operativo e maggiore dovrà essere la capacità di gestire eventuali malfunzionamenti.
Come sempre quindi, la libertà di scelta è totale e dipende unicamente dell’utente.
Nel caso illustrato la scelta è caduta sull’impiego di LVM su due partizioni (/dev/sda3 e /dev/sdb3), in quanto le macchine su cui la soluzione viene implementata possiedono una controller RAID integrata che si occupa di ridondare i due dischi disponibili.
Su entrambe le macchine sono stati definiti due Physical Volume:

# pvcreate /dev/sd[ab]3

Ai quali è stato associato un Volume Group denominato vg_share:

# vgcreate vg_share /dev/sd[ab]3

Ed infine sono stati creati due Logical Volume, denominati lv_drbd0 ed lv_drbd1, i quali rappresenteranno le due condivisioni relative ai device drbd che verranno in seguito creati:

# lvcreate -n lv_drbd0 -L 1G vg_share
# lvcreate -n lv_drbd1 -L 1G vg_share

l’opzione “-L” definisce lo spazio massimo occupabile dal volume logico, chiaramente essendo un progetto con fini puramente didattici lo spazio è stato ridotto per facilitare e velocizzare le operazioni di creazione ed aggiornamento.
All’interno della cartella /dev/mapper/ saranno quindi visibili i seguenti file:

# ls -la /dev/mapper/
totale 0
drwxr-xr-x  2 root root     100 2010-09-14 12:15 .
drwxr-xr-x 17 root root    3700 2010-09-14 12:15 ..
crw-rw----  1 root root  10, 59 2010-09-14 12:15 control
brw-rw----  1 root disk 251,  0 2010-09-14 12:15 vg_share-lv_drbd0
brw-rw----  1 root disk 251,  1 2010-09-14 12:15 vg_share-lv_drbd1

a dimostrazione che i volumi logici sono pronti ad essere utilizzati.

Configurazione preliminare di Heartbeat

La configurazione preliminare di Heartbeat si rifà totalmente a quanto illustrato nel precedente articolo al paragrafo “Configurazione di Heartbeat in modalità CRM con Pacemaker”:

/etc/ha.d/ha.cf:

autojoin none
keepalive 1
deadtime 10
warntime 5
initdead 20
mcast eth0 239.0.0.43 694 1 0
bcast eth1
node    debian-lenny-nodo1
node    debian-lenny-nodo2
crm respawn

/etc/ha.d/authkeys:

auth 1
1 crc

Quindi una volta avviato 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.1.1" 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"

In breve viene disabilitato lo stonith, viene imposto al cluster di ignorare l’assenza di quorum e viene definita una risorsa ping che controlla la connettività in entrambi i nodi attraverso il clone della risorsa stessa.
La situazione del cluster viene così riassunta:

# crm status
============
Last updated: Tue Sep 14 12:17:29 2010
Stack: Heartbeat
Current DC: debian-lenny-nodo1 (1627f3ec-ec7e-4f0c-b69e-e9729933a2cc) - partition with quorum
Version: 1.0.8-042548a451fce8400660f6031f4da6f0223dd5dd
2 Nodes configured, unknown expected votes
1 Resources configured.
============
 
Online: [ debian-lenny-nodo1 debian-lenny-nodo2 ]
 
 Clone Set: ping_clone
     Started: [ debian-lenny-nodo1 debian-lenny-nodo2 ]

Per qualsiasi dubbio in merito alle configurazioni sopra riportate, come già detto, è bene far riferimento al precedente articolo.

Configurazione preliminare di DRBD

In questa fase del progetto è necessario configurare i due volumi logici creati in precedenza affinché possano essere utilizzati con DRBD. Per prima cosa il sistema deve essere predisposto per supportare DRBD, il che significa che vanno installati i pacchetti relativi al modulo che verrà inserito all’interno del kernel. Come sempre tutto dipende dalla distribuzione che si sta utilizzando, nel caso illustrato Debian offre il meta pacchetto drbd8-modules-2.6-686 che si occupa di installare la corretta versione associata al kernel utilizzato:

apt-get install drbd8-modules-2.6-686 drbd8-utils

Con Ubuntu è sufficiente installare il pacchetto drbd8-utils che risolverà le dipendenze ed installerà il modulo, stesso dicasi per SuSe, mentre per RedHat è necessario utilizzare i pacchetti Extra di CentOS.
Maggiori informazioni sulle versioni disponibili sono qui: http://www.drbd.org/download/packages/.

Installato il modulo, per configurare i due volumi logici i passi da seguire sono semplicissimi. In prima istanza va modificato il file /etc/drbd.conf come segue:

global { usage-count no; }
 
common { protocol C; syncer { rate 100M; } }
 
resource r0 {
        device /dev/drbd0;
        meta-disk internal;
        disk /dev/mapper/vg_share-lv_drbd0;
 
        on debian-lenny-nodo1 {
                address 10.0.0.1:7788;
        }
 
        on debian-lenny-nodo2 {
                address 10.0.0.2:7788;
        }
}
 
resource r1 {
        device /dev/drbd1;
        meta-disk internal;
        disk /dev/mapper/vg_share-lv_drbd1;
 
        on debian-lenny-nodo1 {
                address 10.0.0.1:7789;
        }
 
        on debian-lenny-nodo2 {
                address 10.0.0.2:7789;
        }
}

Le dichiarazioni presenti nel file sono auto esplicative: Il tipo di algoritmo con cui verrà gestita la sincronizzazione è C (replicazione sincrona, standard, qui i dettagli sui diversi protocolli disponibili), mentre la velocità a cui i dati verranno sincronizzati è 100 Mega (qui come calcolare la corretta velocità di sincronizzazione).
sono state definite due risorse (resource) che poggeranno su volumi logici interni (disk) e registreranno i meta-dati relativi alla sincronizzazione internamente (meta-disk), ciascuna risorsa farà viaggiare le informazioni per la sincronizzazione sull’interfaccia locale relativa alla rete 10.0.0.0 (address) ad una porta differente (7788 e 7789).

A questo punto i volumi logici vanno inizializzati in modo che il sistema possa iniziare a servirsi dei device. Le operazioni da compiere in sequenza, su entrambi i nodi, sono le seguenti:

1
2
3
4
5

# modprobe drbd
# drbdadm create-md r0
# drbdadm create-md r1
# drbdadm up r0
# drbdadm up r1

Linea per linea, ecco quanto fatto:

1. Caricamento del modulo drbd: il sistema è in grado di supportare dispositivi drbd;
2. Creazione del meta-device sopra il volume logico r0, così come dichiarato nel file di configurazione, il volume /dev/mapper/vg_share-lv_drbd0 viene inizializzato;
3. Creazione del meta-device sopra il volume logico r1, così come dichiarato nel file di configurazione, il volume /dev/mapper/vg_share-lv_drbd1 viene inizializzato;
4. Attivazione del meta-device, da questo momento il sistema “vede” /dev/drbd0;
5. Attivazione del meta-device, da questo momento il sistema “vede” /dev/drbd1;

Come ultima fase per l’inizializzazione dei dispositivi è necessario effettuare la prima sincronizzazione in modo che i volumi remoti vengano allineati. Per far ciò è necessario lanciare il seguente comando su uno solo dei due nodi:

# drbdadm -- --overwrite-data-of-peer primary all

Il comando forza lo stato primario del nodo su cui è stato lanciato ed avvia nel contempo la prima sincronizzazione, al termine della quale lo stato dei meta-device drbd sarà il seguente:

# cat /proc/drbd 
version: 8.3.7 (api:88/proto:86-91)
GIT-hash: ea9e28dbff98e331a62bcbcc63a6135808fe2917 build by root@debian-lenny-nodo1, 2010-09-13 18:03:02
 0: cs:Connected ro:Secondary/Secondary ds:UpToDate/UpToDate C r----
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
 1: cs:Connected ro:Secondary/Secondary ds:UpToDate/UpToDate C r----
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

Per concludere la configurazione preliminare di drbd andrà creato un filesystem su ciascuno dei device creati:

# mkfs.ext3 /dev/drbd0
# mkfs.ext3 /dev/drbd1

E rimosso l’avvio automatico del demone dal sistema, poiché questo verrà gestito totalmente dal cluster. Per Debian ed Ubuntu il comando da lanciare sarà:

# update-rc.d -f drbd remove

mentre nel caso di RedHat/CentOS/SuSe:

# chkconfig --level 123456 drbd off

E’ giunto il momento di configurare lo storage condiviso.

Configurazione di Heartbeat e DRBD

Prima implementare l’esposizione dello spazio che abbiamo creato via NFS è necessario configurare il cluster affinché gestisca i dispositivi DRBD e ne amministri lo stato. Come stabilito in precedenza infatti, il controllo di tali componenti sarà totalmente nelle mani del cluster e non del sistema operativo. In altre parole i due componenti DRBD non saranno gestiti come demoni, ma come due risorse distinte.
DRBD, rispetto a quanto illustrato sinora, non è una risorsa standard: non è assimilabile infatti alle risorse comuni poiché necessità di risiedere su (almeno) due nodi, questa peculiarità però non permette comunque di creare un clone della risorsa da ripartire sulle altre macchine, poiché in ciascuno dei nodi su cui essa sarà attiva questa dovrà assumere uno stato differente.
Per questa ragione, dopo aver definito le risorse standard associate ai dispositivi DRBD in precedenza creati (r0 ed r1):

# crm configure primitive drbd0 ocf:linbit:drbd params drbd_resource="r0" op monitor interval="20s" timeout="40s" op start interval="0" timeout="240s" op stop interval="0" timeout="100s"
# crm configure primitive drbd1 ocf:linbit:drbd params drbd_resource="r1" op monitor interval="20s" timeout="40s" op start interval="0" timeout="240s" op stop interval="0" timeout="100s"

è necessario configurare due risorse multi-state:

# crm configure ms ms-drbd0 drbd0 meta master-max="1" notify="true"
# crm configure ms ms-drbd1 drbd1 meta master-max="1" notify="true"

I due comandi, ciascuno relativo ad una risorsa DRBD, definiscono una risorsa multi-state che può avere un solo nodo master (master-max) il quale una volta assunto il proprio stato (master o slave che sia) deve notificare il successo agli altri nodi (notify), in modo che la risorsa sia in uno stato coerente su entrambi i nodi.
Dopo qualche secondo sarà possibile osservare all’interno dello stato del cluster quanto realizzato:

============
Last updated: Wed Sep 15 20:16:44 2010
Stack: Heartbeat
Current DC: debian-lenny-nodo1 (1627f3ec-ec7e-4f0c-b69e-e9729933a2cc) - partition with quorum
Version: 1.0.8-042548a451fce8400660f6031f4da6f0223dd5dd
2 Nodes configured, unknown expected votes
3 Resources configured.
============
 
Online: [ debian-lenny-nodo1 debian-lenny-nodo2 ]
 
 Clone Set: ping_clone
     Started: [ debian-lenny-nodo1 debian-lenny-nodo2 ]
 Master/Slave Set: ms-drbd0
     Masters: [ debian-lenny-nodo1 ]
     Slaves: [ debian-lenny-nodo2 ]
 Master/Slave Set: ms-drbd1
     Masters: [ debian-lenny-nodo1 ]
     Slaves: [ debian-lenny-nodo2 ]

Come si evince dall’output mostrato il nodo master per entrambe le risorse è debian-lenny-nodo1.

Ora che il cluster controlla i dispositivi è necessario esporli. Per fare ciò sono necessarie tre componenti:

1. Indirizzo IP: ossia l’indirizzo di riferimento per l’intera rete a quela specifica condivisione;
2. Filesystem: ovvero il mount del filesystem relativo alla risorsa DRBD in modo che ci si possa scrivere sopra;
3. NFS: in modo da esporre la condivisione con il protocollo NFS e permettere il mount da parte di client di rete;

Esisteranno quindi due gruppi di risorse contenenti le tre risorse descritte, tali gruppi verranno nominati come le cartelle che dovranno esporre, così come definito in fase di studio del progetto: share-a e share-b.

Indirizzo IP

La configurazione degli indirizzi IP è identica a quanto illustrato nel precedente articolo:

# crm configure primitive share-a-ip ocf:heartbeat:IPaddr2 params ip="192.168.1.33" nic="eth0" op monitor interval="20s" timeout="40s"
# crm configure primitive share-b-ip ocf:heartbeat:IPaddr2 params ip="192.168.1.34" nic="eth0" op monitor interval="20s" timeout="40s"

al gruppo che eroga share-a pertanto verrà associato l’indirizzo 192.168.1.33 mentre a share-b 192.168.1.34, entrambe le risorse sono gestite dal il resource agent IPAddr2.

Filesystem

Il dispositivo /dev/drbd0 verrà associato a share-a ed alla directory /share-a, così come share-b monterà /dev/drbd1 sulla directory /share-b.
Andranno quindi create le directory per i mount su entrambi i nodi:

# mkdir /share-a
# mkdir /share-b

Ed infine configurate le risorse attraverso il resource agent Filesystem:

# crm configure primitive share-a-fs ocf:heartbeat:Filesystem params device="/dev/drbd0" directory="/share-a" fstype="ext3" op monitor interval="20s" timeout="40s" op start interval="0" timeout="60s" op stop interval="0" timeout="60s" meta is-managed="true" 
# crm configure primitive share-b-fs ocf:heartbeat:Filesystem params device="/dev/drbd1" directory="/share-b" fstype="ext3" op monitor interval="20s" timeout="40s" op start interval="0" timeout="60s" op stop interval="0" timeout="60s" meta is-managed="true"

NFS

Per permettere l’esportazione di ciascuna share in maniera indipendente, fermo restando che su ogni sistema il demone NFS deve essere in esecuzione, è possibile utilizzare un resource agent denominato exportfs.
Questo resource agent creato da Holger Teutsch, potrebbe non essere disponibile se non si possiede una versione recente di Heartbeat (successiva al marzo 2010). In questo caso il problema è facilmente risolvibile installando il resource agent su entrambi i nodi come segue:

# cd /usr/lib/ocf/resource.d/heartbeat/
# wget http://hg.linux-ha.org/agents/raw-file/c8d8b1126ffd/heartbeat/exportfs
# chmod +x exportfs

In questo modo sarà possibile dichiarare due risorse exportfs affinché espongano le due cartelle:

# crm configure primitive share-a-exportfs ocf:heartbeat:exportfs params directory="/share-a" clientspec="192.168.1.0/24" options="rw,async,no_subtree_check,no_root_squash" fsid="1" op monitor interval="10s" timeout="30s" op start interval="0" timeout="40s" op stop interval="0" timeout="40s"
# crm configure primitive share-b-exportfs ocf:heartbeat:exportfs params directory="/share-b" clientspec="192.168.1.0/24" options="rw,async,no_subtree_check,no_root_squash" fsid="2" op monitor interval="10s" timeout="30s" op start interval="0" timeout="40s" op stop interval="0" timeout="40s"

Il resource agent exportfs si occupa di aggiornare in tempo reale lo stato delle export NFS di sistema, utilizzando appunto il comando exportfs.
Come è facile notare la dichiarazione del resource agent si rifà totalmente alla sintassi del comando exportfs, o più semplicemente al contenuto del file /etc/exports (ossia il file di configurazione di NFS), in particolare:

• directory definisce la directory locale che verrà esportata;
• client_spec definisce quali client potranno accedere alla condivisione;
• options contiene le opzioni di esportazione: lettura/scrittura (rw), l’allineamento del filesystem sarà asincrono (async) e tutto il volume verrà esportato senza controllo alle sotto directory (no_subtree_check), infine sarà possibile per l’utente root del client remoto avere privilegi di root sulla condivisione (no_root_squash);
• fsid definisce un identificatore univoco per la condivisione;

Raggruppare le risorse create

Ora che è terminata la creazione delle risorse, è facile notare come queste abbiano nomi riconducibili al loro utilizzo, ma siano in realtà slegate le une dalle altre. Necessitano quindi, per una corretta gestione, di essere raggruppate. Pacemaker permette di creare quindi gruppi di risorse, la cui definizione sequenziale stabilisce anche l’ordine con cui le risorse verranno avviate:

# crm configure group share-a share-a-fs share-a-exportfs share-a-ip
# crm configure group share-b share-b-fs share-b-exportfs share-b-ip

Sono stati quindi definiti due gruppi share-a e share-b che avvieranno innanzitutto il filesystem, seguito dall’export dello stesso via NFS ed infine l’indirizzo IP. Chiaramente in fase di stop l’ordine sarà logicamente invertito, garantendo in caso di disservizi ai client remoti in prima istanza di perdere connettività con il server (i client non rilevando più l’indirizzo del server tratterranno le connessioni esistenti in stato di attesa, TIME_WAIT) e, una volta che le risorse saranno ripristinate sul nodo attivo, di continuare a scrivere senza alcuna perdita di dati.

Collocazione, ordinamento e controllo connettività delle risorse

La configurazione del cluster non è però ancora completa. Le risorse drbd ed i gruppi share al momento non sono correlati. Infatti per come è stato configurato il sistema su un nodo potrebbe avviarsi share-a, ma non esserci la risorsa drbd0 promossa allo stato di master, quindi non utilizzabile come mount point, né scrivibile.
Per ovviare a questa potenziale situazione, è necessario associare i gruppi share ai nodi su cui la risorsa drbd è master.
Pacemaker gestisce queste operazioni attraverso le colocation:

# crm configure colocation share-a_on_ms-drbd0 inf: share-a ms-drbd0:Master
# crm configure colocation share-b_on_ms-drbd1 inf: share-b ms-drbd1:Master

Viene definita per entrambi i gruppi share una colocation di peso infinito (inf, quindi senza possibilità di variazione) per cui il gruppo si avvierà solo laddove la risorsa multi-state è in stato master.

E’ necessaria un’altra condizione per aggiungere coerenza alla configurazione e riguarda l’ordinamento nell’avvio delle risorse. Chiaramente ciascun gruppo share non ha ragione di avviarsi se non dopo che il dispositivo drbd è attivo. Pacemaker gestisce la cosa attraverso le definizioni order:

# crm configure order share-a_after_ms-drbd0 inf: ms-drbd0:promote share-a:start
# crm configure order share-a_after_ms-drbd1 inf: ms-drbd1:promote share-b:start

Viene definita una order di peso infinito in cui l’operazione di promozione a master della risorsa multi-state vincola l’avvio del gruppo share.

A completamento della configurazione non rimane che associare le risorse ai nodi con connettività, facendo riferimento alla risorsa ping dichiarata in precedenza e clonata in tutti i nodi:

# crm configure location share-a_on_connected_node share-a rule -inf: not_defined ping or ping lte 0
# crm configure location share-b_on_connected_node share-b rule -inf: not_defined ping or ping lte 0

Viene definita una location relativa ai gruppi share la cui regola di peso meno infinito (-inf) si verifica in assenza di connettività: la risorsa ping non è definita oppure restituisce un valore negativo.
In questo modo quando un nodo che ospita un gruppo perderà la connettività Pacemaker tenterà di effettuare uno switch del gruppo su un altro nodo attivo.

Cleanup finale

Ora che la configurazione del cluster è completa è facile immaginare come tutte le operazioni effettuate possano aver falsato lo stato generale del cluster, quindi, al fine di partire da una situazione pura, è possibile lanciare i seguenti comandi:

# crm resource cleanup share-a
# crm resource cleanup share-b

L’operazione di cleanup della risorsa come dice il nome, azzera il conteggio degli errori per le risorse e le riavvia ordinatamente in modo da, come detto, partire da zero a vagliare eventuali problemi.
Lo stato del cluster a configurazione ultimata dovrebbe essere quindi il seguente:

# crm status
============
Last updated: Fri Sep 17 14:33:16 2010
Stack: Heartbeat
Current DC: debian-lenny-nodo1 (1627f3ec-ec7e-4f0c-b69e-e9729933a2cc) - partition with quorum
Version: 1.0.8-042548a451fce8400660f6031f4da6f0223dd5dd
2 Nodes configured, unknown expected votes
5 Resources configured.
============
 
Online: [ debian-lenny-nodo1 debian-lenny-nodo2 ]
 
 Clone Set: ping_clone
     Started: [ debian-lenny-nodo1 debian-lenny-nodo2 ]
 Master/Slave Set: ms-drbd0
     Masters: [ debian-lenny-nodo2 ]
     Slaves: [ debian-lenny-nodo1 ]
 Master/Slave Set: ms-drbd1
     Masters: [ debian-lenny-nodo1 ]
     Slaves: [ debian-lenny-nodo2 ]
 Resource Group: share-a
     share-a-fs (ocf::heartbeat:Filesystem):    Started debian-lenny-nodo1
     share-a-exportfs   (ocf::heartbeat:exportfs):      Started debian-lenny-nodo1
     share-a-ip (ocf::heartbeat:IPaddr2):       Started debian-lenny-nodo1
 Resource Group: share-b
     share-b-fs (ocf::heartbeat:Filesystem):    Started debian-lenny-nodo2
     share-b-exportfs   (ocf::heartbeat:exportfs):      Started debian-lenny-nodo2
     share-b-ip (ocf::heartbeat:IPaddr2):       Started debian-lenny-nodo2

Creare una configurazione active active

Il progetto iniziale prevede che nessun nodo, in condizioni normali, sia passivo. Pertanto per completare la configurazione del cluster è necessario assegnare ciascun gruppo share ad uno specifico nodo.
Tale risultato è ottenibile mediante l’aggiunta di due ulteriori regole di tipo location:

location cli-prefer-share-a share-a rule inf: #uname eq debian-lenny-nodo1
location cli-prefer-share-b share-b rule inf: #uname eq debian-lenny-nodo2

In questo modo, la regola creata impone che share-a venga associata al nodo debian-lenny-nodo1 mentre share-b al nodo debian-lenny-nodo2: i due nodi saranno entrambi operativi, completando così l’obiettivo deciso in fase di progettazione.

Considerazioni sulla stickiness

La politica del cluster in merito al posizionamento di una risorsa dipende dal peso che questa ha. Il peso viene stabilito in base alle condizioni del cluster e della risorsa stessa. Molte delle regole relative a definizioni di location e order fanno infatti riferimento a pesi infiniti in modo che se queste si verificano lo stato del cluster DEVE variare.
Lo stickiness di una risorsa rappresenta il peso necessario al suo spostamento dalla posizione attuale nel momento in cui il cluster subisce variazioni.

Ad esempio…

Il valore di default della stickyness è 0. se una risorsa viene migrata a mano, il cluster aggiunge una regola di location come quelle descritte poco sopra. Se il nodo che eroga la risorsa perde di connettività, allora questa, per la sua sopravvivenza, verrà migrata sul nodo attivo. Quando però il nodo originale tornerà a vivere, la risorsa, per via della regola impostata, verrà nuovamente migrata in quanto non ha vincoli (la stickiness è 0) che la legano al nodo attuale. Questo significa che nel giro i poco tempo si assisterà a due switch della risorsa, assimilabili a due interruzioni di servizio.
Facile capire come non sempre questo possa essere il comportamento desiderato. Basti pensare al caso di database Oracle, ed a tutti i problemi che comporta uno switch.
Inutile dire che meno sono, meglio è.
Fortunatamente Pacemaker consente di impostare il valore di default di stickiness a infinito:

crm configure property default-resource-stickiness=INFINITY

In questo modo se una risorsa associata ad un nodo migra, alla ricomparsa del nodo questa rimarrà dov’è, limitando ulteriori disservizi.
A seconda della decisione presa in merito alla stickiness, si dovrà quindi scegliere se questa dovrà rimanere al suo valore di default o avere altri valori (numeri maggiori di zero per arrivare ad INFINITY).

Configurazione finale

La configurazione estesa (modificabile attraverso il comando crm configure edit) è la seguente:

node $id="1627f3ec-ec7e-4f0c-b69e-e9729933a2cc" debian-lenny-nodo1
node $id="f4380aee-c67b-4472-9449-5fa8e5ddae34" debian-lenny-nodo2
primitive drbd0 ocf:linbit:drbd \
	params drbd_resource="r0" \
	op monitor interval="20s" timeout="40s" \
	op start interval="0" timeout="240s" \
	op stop interval="0" timeout="100s"
primitive drbd1 ocf:linbit:drbd \
	params drbd_resource="r1" \
	op monitor interval="20s" timeout="40s" \
	op start interval="0" timeout="240s" \
	op stop interval="0" timeout="100s"
primitive ping ocf:pacemaker:ping \
	params host_list="192.168.1.1" name="ping" \
	op monitor interval="10s" timeout="60s" \
	op start interval="0" timeout="60s" \
	op stop interval="0" timeout="60s"
primitive share-a-exportfs ocf:heartbeat:exportfs \
	params directory="/share-a" clientspec="192.168.1.0/24" options="rw,async,no_subtree_check,no_root_squash" fsid="1" \
	op monitor interval="10s" timeout="30s" \
	op start interval="0" timeout="40s" \
	op stop interval="0" timeout="40s"
primitive share-a-fs ocf:heartbeat:Filesystem \
	params device="/dev/drbd0" directory="/share-a" fstype="ext3" \
	op monitor interval="20s" timeout="40s" \
	op start interval="0" timeout="60s" \
	op stop interval="0" timeout="60s" \
	meta is-managed="true"
primitive share-a-ip ocf:heartbeat:IPaddr2 \
	params ip="192.168.1.33" nic="eth0" \
	op monitor interval="20s" timeout="40s"
primitive share-b-exportfs ocf:heartbeat:exportfs \
	params directory="/share-b" clientspec="192.168.1.0/24" options="rw,async,no_subtree_check,no_root_squash" fsid="2" \
	op monitor interval="10s" timeout="30s" \
	op start interval="0" timeout="40s" \
	op stop interval="0" timeout="40s"
primitive share-b-fs ocf:heartbeat:Filesystem \
	params device="/dev/drbd1" directory="/share-b" fstype="ext3" \
	op monitor interval="20s" timeout="40s" \
	op start interval="0" timeout="60s" \
	op stop interval="0" timeout="60s" \
	meta is-managed="true"
primitive share-b-ip ocf:heartbeat:IPaddr2 \
	params ip="192.168.1.34" nic="eth0" \
	op monitor interval="20s" timeout="40s"
group share-a share-a-fs share-a-exportfs share-a-ip
group share-b share-b-fs share-b-exportfs share-b-ip
ms ms-drbd0 drbd0 \
	meta master-max="1" notify="true"
ms ms-drbd1 drbd1 \
	meta master-max="1" notify="true"
clone ping_clone ping \
	meta globally-unique="false"
location cli-prefer-share-a share-a \
	rule $id="cli-prefer-rule-share-a" inf: #uname eq debian-lenny-nodo1
location cli-prefer-share-b share-b \
	rule $id="cli-prefer-share-b-rule" inf: #uname eq debian-lenny-nodo2
location share-a_on_connected_node share-a \
	rule $id="share-a_on_connected_node-rule" -inf: not_defined ping or ping lte 0
location share-b_on_connected_node share-b \
	rule $id="share-b_on_connected_node-rule" -inf: not_defined ping or ping lte 0
colocation share-a_on_ms-drbd0 inf: share-a ms-drbd0:Master
colocation share-b_on_ms-drbd1 inf: share-b ms-drbd1:Master
order share-a_after_ms-drbd0 inf: ms-drbd0:promote share-a:start
order share-a_after_ms-drbd1 inf: ms-drbd1:promote share-b:start
property $id="cib-bootstrap-options" \
	dc-version="1.0.8-042548a451fce8400660f6031f4da6f0223dd5dd" \
	cluster-infrastructure="Heartbeat" \
	stonith-enabled="false" \
	no-quorum-policy="ignore" \
	last-lrm-refresh="1284661245"

Test funzionale

Una volta montato da parte di un client lo share NFS:

# mount -t nfs 192.168.1.33:/share-a /mnt/

è possibile lanciare sempre sul client una copia arbitraria di file:

cp -av /usr/ /mnt/

partirà la copia dei file e sarà possibile agire quindi sul cluster, tenendo monitorato sia la copia che lo stato attraverso crm_mon.

Primo test: disconnessione cavo LAN nodo master

Alla disconnessione del cavo la risorsa ping avverte immediatamente l’assenza di connettività e forza la migrazione del gruppo share-a al nodo rimanente, in questo caso il debian-lenny-nodo1. Il tutto è osservabile dal file /var/log/syslog:

Sep 17 18:05:35 debian-lenny-nodo2 heartbeat: [1079]: info: Link debian-lenny-nodo1:eth0 dead.
...
Sep 17 18:05:46 debian-lenny-nodo2 kernel: [20384.996634] block drbd1: peer( Primary -> Secondary ) 
...
Sep 17 18:05:50 debian-lenny-nodo2 Filesystem[27581]: [27636]: INFO: Running start for /dev/drbd0 on /share-a
...
Sep 17 18:05:50 debian-lenny-nodo2 kernel: [20389.636665] EXT3-fs: mounted filesystem with ordered data mode.
...
Sep 17 18:05:51 debian-lenny-nodo2 exportfs[27676]: [27739]: INFO: File system exported
...
Sep 17 18:05:52 debian-lenny-nodo2 IPaddr2[27764]: [27817]: INFO: ip link set eth0 up
...

Lato client, la scrittura su NFS si ferma per qualche secondo e riparte appena l’ultima operazione di start è eseguita da Pacemaker.

Secondo test: migrazione manuale delle risorse

Lanciando il comando migrate sulla risorsa share-a viene forzato manualmente lo switch della risorsa dal nodo attuale al nodo indicato:

crm resource migrate share-a debian-lenny-nodo1

Quanto il cluster fa in questo genere di operazione è quello di modificare la stessa location descritta poco sopra:

# crm configure show
...
...
location cli-prefer-share-a share-a \
	rule $id="cli-prefer-rule-share-a" -inf: #uname eq debian-lenny-nodo1
...
...

In sostanza la location prima impostata su share-a è stata modificata da Pacemaker da inf a -inf invertendo il vincolo che legava la risorsa al nodo debian-lenny-nodo1.
E’ necessario porre particolare attenzione a questa regola, poiché il peso -inf implica che la risorsa sarà da qui in poi SEMPRE associata al nodo debian-lenny-nodo2, poiché non potrà più risiedere sul nodo originale.

Per ripristinare la situazione originaria e rimuovere la regola aggiunta esistono due modi:

1. Lanciare il comando precedente utilizzando unmigrate, in modo che la risorsa torni sul nodo originale (e la regola verrà cancellata, eliminando anche l’impostazione della configurazione originale);
2. Modificare a mano la configurazione del cluster attraverso il comando crm configure edit rimuovendo la linea aggiunta automaticamente, in modo da lasciare la risorsa dove si trova ora senza vincolarne i futuri spostamenti;

Lato client l’operazione è ancora più indolore di prima: dai log il comportamento è simile al precedente test e la scrittura sullo share NFS si ferma il tempo che la risorsa migra.

Terzo test: spegnimento improvviso nodo master

Lo spegnimento improvviso del nodo master rende il comportamento del cluster del tutto simile a quello illustrato primo test, con una differenza sostanziale:

...
Sep 17 18:36:37 debian-lenny-nodo2 heartbeat: [1079]: WARN: node debian-lenny-nodo1: is dead
...
Sep 17 18:36:37 debian-lenny-nodo2 crmd: [1120]: WARN: check_dead_member: Our DC node (debian-lenny-nodo1) left the cluster
...
Sep 17 18:36:37 debian-lenny-nodo2 kernel: [22236.912107] block drbd0: peer( Primary -> Unkno
wn ) conn( Connected -> NetworkFailure ) pdsk( UpToDate -> DUnknown ) 
...

Il cluster ha dovuto rimpiazzare il proprio DC (Designated Coordinator) poiché spento ed ovviamente il dispositivo drbd è in stato Primary sul nodo sopravvissuto, ma ovviamente in stato Unknown nella sua replica.

Anche in questo caso, lato client tutto si è svolto in maniera trasparente, la copia si è fermata per qualche secondo per poi ripartire.

Conclusioni

La soluzione illustrata descrive a pieno le potenzialità del progetto Pacemaker. E’ possibile combinare i suggerimenti espressi in questo lungo articolo immaginando di disporre di un cluster composto da più di due macchine, o segmentando ulteriormente le share esposte, creando ulteriori volumi logici e dispositivi drbd.
Il tutto con dei costi decisamente contenuti rispetto alle soluzioni NAS in commercio: in pratica il solo prezzo dell’hardware!
Bene, con quest’ultima parte la serie “Evoluzione dell’alta affidabilità su Linux” può dirsi conclusa. Sicuramente “Mia Mamma Usa Linux” tornerà su temi inerenti l’argomento, magari trattando l’integrazione delle tecniche di virtualizzazione nel cluster, utilizzando virtual machines come fossero risorse da migrare, magari senza necessità che i sistemi virtualizzati vengano spenti!
Commenti sulla serie sono ben accetti, suggerimenti su futuri argomenti anche di più, proposte di collaborazione sono in assoluto il meglio.
Lunga vita al software libero.

VPN significa, letteralmente Rete Privata Virtuale, cioè una serie di collegamenti virtuali e privati creati su un’infrastruttura ad accesso pubblico, come ad esempio Internet. Una rete privata virtuale consente di comunicare in maniera sicura attraverso un canale insicuro in una forma efficiente ed economica.

In questo articolo vedremo come creare un server VPN a cui far collegare diversi client, con l’obiettivo di creare una rete estesa e sicura. Il tutto verrà realizzato mediante il celebre software opensource OpenVPN.

Un po’ di teoria

Prima di incominciare con la parte pratica, vediamo quali sono i concetti di base di una VPN.

L’esigenza alla base di una VPN è quella di creare un canale di comunicazione sicuro tra diversi soggetti, appoggiandosi ad un’infrastruttura già esistente, in modo da poter scambiare i propri dati come se si fosse connessi ad una grande rete LAN senza affrontare i costi altissimi per l’installazione di un’infrastruttura fisica tra diverse sedi.

Seguendo l’analogia che rappresenta Internet come un sistema idraulico, si può pensare ad una VPN come un “tubo dentro ad un tubo”.

Tipologie di VPN

Esistono innumerevoli tipi di tecnologie per la creazione di VPN che differiscono per diversi fattori, come ad esempio:

• I protocolli usati per creare i tunnel privati sulla rete sottostante;
• La posizione degli endpoint dei tunnel;
• Il livello di sicurezza fornito;
• Il livello OSI usato per l’interconnessione delle diverse reti;

Attualmente vengono identificati tre tipologie principali di VPN:

• Trusted VPN
• Secured VPN
• Hybrid VPN

Le VPN di tipo ‘Trusted’ sono state le prime ad essere create e sono ancora in uso in alcuni ambienti come quelli bancari, si tratta di reti virtuali create a partire dall’hardware di rete: in questo caso esiste un ISP (Internet Service Provider) che stabilisce indirizzi e politiche di routing per il proprio cliente, creando così una vera e propria rete virtuale sulla propria infrastruttura. Il grosso vantaggio che forniscono queste reti è il fatto che il traffico viaggia su percorsi ben definiti ed è possibile stabilire in maniera molto semplice politiche di QoS (la qualità del servizio offerto dalla rete), anche se è necessario sacrificare un po’ di flessibilità.

Le VPN di tipo ‘Secured’ invece prevedono che il traffico venga incanalato su tunnel cifrati e spedito attraverso Internet come se fosse normale traffico. Nel caso in cui uno di questi pacchetti finisca nelle proverbiali mani sbagliate, le informazioni in esso contenute saranno comunque inaccessibili. Lo svantaggio rispetto alle trusted VPN è la mancanza di predeterminazione dei percorsi effettuati dai pacchetti.

L’ultima tipologia di VPN è, come suggerisce il nome, un mix tra le due tipologie precedenti, prendendo la sicurezza intrinseca nata dalla cifratura di tutto il traffico di rete delle Secured VPN e la possibilità di fare QoS in maniera semplice, tipica delle Trusted VPN.

OpenVPN permette di creare proprio Secured VPN.

Installazione

Giungiamo così alla parte più pratica dell’articolo, l’installazione e configurazione del servizio OpenVPN. L’articolo tratta l’installazione del software su un sistema operativo Debian Lenny, ma a pacchetti installati, le informazioni sono utilizzabili sulle più diffuse distribuzioni.

Verrà assunto inoltre che il router con il quale si accede ad internet permetta di fare l’apertura della porta 1194 TCP (e anche UDP se possibile) verso il vostro server.

Il primo step è naturalmente quello di installare openvpn:

# aptitude install openvpn

Una volta installati i vari pacchetti, siamo pronti per sporcarci le mani.

Generazione dei certificati

Per la cifratura dei pacchetti OpenVPN usa il protocollo SSL, e per tanto è necessario generare tutta la serie di certificati per permettere sia la cifratura della connessione che l’autenticazione dei vari client.

Fortunatamente il pacchetto di OpenVPN fornisce una serie di script già pronti atti a tale scopo nel path /usr/share/doc/openvpn/examples/easy-rsa/2.0/:

# ls /usr/share/doc/openvpn/examples/easy-rsa/2.0/
build-ca          build-key-server  Makefile              sign-req
build-dh          build-req         openssl-0.9.6.cnf.gz  vars
build-inter       build-req-pass    openssl.cnf           whichopensslcnf
build-key         clean-all         pkitool
build-key-pass    inherit-inter     README.gz
build-key-pkcs12  list-crl          revoke-full

Nulla vieta di lasciare gli script li dove sono e copiare solo i file generati nella directory di configurazione di OpenVPN, io per comodità preferisco spostare tutta la directory sotto /etc/openvpn/easy-rsa/.

# cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0/ /etc/openvpn/easy-rsa
# cd /etc/openvpn/easy-rsa

Tra i vari file potrete notare un file di testo chiamato “vars”, è un file che contiene tutte le variabili necessarie agli script di generazione di certificati e chiavi.
Sebbene non sia necessario modificare i parametri preimpostati (poichè possono essere sovrascritti durante l’esecuzione dei vari script) risulta più comodo in caso di generazione di un gran numero di certificati.

I parametri da modificare sono i seguenti:

• KEY_SIZE
• KEY_COUNTRY
• KEY_PROVINCE
• KEY_CITY
• KEY_ORG
• KEY_EMAIL

Sono parametri abbastanza auto esplicativi, ecco come si presenta il mio file vars:

export KEY_SIZE=2048
...
export KEY_COUNTRY="IT"
export KEY_PROVINCE="IT"
export KEY_CITY="Milano"
export KEY_ORG="VostraAzienda"
export KEY_EMAIL="my-email@vostraazienda.it"

A questo punto siamo pronti per generare la nostra certificate authority, ossia la componente (auto generata) che validerà i certificati per la comunicazione, ed i certificati stessi.
Prima di tutto dobbiamo fare in modo di esportare tutto ciò che è contenuto dentro al file ‘vars’ appena modificato:

# source vars
NOTE: If you run ./clean-all, I will be doing a rm -rf on /etc/openvpn/easy-rsa/keys
# ./clean-all

È necessario richiamare anche lo script “clean-all” per avere la certezza di partire con un ambiente pulito.

Ora possiamo generare la nostra Certificate Authority:

# ./build-ca
Generating a 1024 bit RSA private key
..................................................++++++
...++++++
writing new private key to 'ca.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [IT]:
State or Province Name (full name) [IT]:
Locality Name (eg, city) [Milano]:
Organization Name (eg, company) [VostraAzienda]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) [VostraAzienda CA]:
Email Address [my-email@vostraazienda.it]:

Alla richiesta di input mi sono limitato semplicemente a premere invio, i dati erano già corretti poichè sono stati modificati nel file ‘vars’.
Ora possiamo creare il certificato per il server VPN:

# ./build-key-server Gateway

Gateway è il nome della macchina su cui sto installando il server VPN, per coerenza la coppia chiave/certificato avrà il nome dell’host su cui viene usato. Vediamo l’esecuzione dello script:

Generating a 1024 bit RSA private key
..................++++++
.++++++
writing new private key to 'Gateway.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [IT]:
State or Province Name (full name) [IT]:
Locality Name (eg, city) [Milano]:
Organization Name (eg, company) [VostraAzienda]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) [Gateway]:
Email Address [me@myhost.mydomain]:
 
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:password
An optional company name []:
Using configuration from /etc/openvpn/easy-rsa/openssl.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'IT'
stateOrProvinceName   :PRINTABLE:'IT'
localityName          :PRINTABLE:'Milano'
organizationName      :PRINTABLE:'VostraAzienda'
commonName            :PRINTABLE:'Gateway'
emailAddress          :IA5STRING:'my-email@vostraazienda.it'
Certificate is to be certified until Apr 25 13:50:00 2020 GMT (3650 days)
Sign the certificate? [y/n]:y
 
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

Quando lo script chiede una password è lecito premere semplicemente invio per evitare di dover immettere la password ogni (ri)avvio di OpenVPN.

Generiamo ora il file Diffie-Hellman, necessario per l’avvio delle connessioni cifrate.
Attenzione, è un’operazione MOLTO lunga, quindi preparatevi a prendervi un paio di caffè…

# ./build-dh
Generating DH parameters, 2048 bit long safe prime, generator 2
This is going to take a long time
........+............

Dopo la vostra ristorante pausa caffè, passiamo a generare l’ultima chiave necessaria per l’instaurazione di una connessione sicura, questa chiave dovrà essere copiata anche su tutti i client.

# openvpn --genkey --secret keys/ta.key

Generazione dei certificati per i client

La generazione del certificato per il client è letteralmente identica alla generazione di un certificato per il server.
Personalmente preferisco generare dei certificati nominali:

# ./build-key fpedrini

e seguirà una procedura identica a quella della generazione del certificato per il server.

Configurazione del server

Passiamo ora configurazione vera e propria del demone di OpenVPN.
Anche in questo caso il pacchetto debian ci viene in aiuto con un file di configurazione già precotto e adatto ai nostri scopi, dobbiamo solo aggiustare qualche piccolo parametro.

Innanzitutto è necessario copiare il file di esempio nella directory giusta:

# cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz /etc/openvpn/
# cd /etc/openvpn
# gunzip server.conf.gz

Ora siamo pronti a modificare la configurazione, per brevità citerò solo le direttive che andremo a toccare:

local 192.168.0.1
port 1194
proto udp

Queste direttiva indicano ad OpenVPN rispettivamente:

• Su quale indirizzo ip locale mettersi in attesa di connessioni, se omessa il demone userà tutte le interfacce
• Su quale porta ascoltare, la 1194 è il default
• Che tipo di protocollo utilizzare per il tunnel, le possibilità sono ‘TCP’ e ‘UDP’, vedremo più avanti le differenze

dev tun

Indica a OpenVPN di creare un tunnel al layer 3 del livello OSI, utilizzando ‘tap’ invece, andremmo a creare un bridge di rete a livello 2.

ca easy-rsa/keys/ca.crt
cert easy-rsa/keys/Gateway.crt
key easy-rsa/keys/Gateway.key  # This file should be kept secret
dh easy-rsa/keys/dh2048.pem

Queste direttive invece indicano al demone dove andare a prendere i file relativi alla Certification Authority, al certificato del server e il file Diffie-Hellman.

server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.1.0 255.255.255.0"

Questi parametri stabiliscono:

• la subnet e la maschera della rete della VPN, il server prenderà automaticamente il primo indirizzo
• il file in cui salvare la lista degli ip assegnati dal dhcp interno di OpenVPN
• la rotta che il server deve comunicare al client per fare in modo che possano raggiungere la rete dietro alla VPN.

;push "redirect-gateway def1 bypass-dhcp"

Questa riga fa in modo che tutto il traffico generato dai client passi attraverso la VPN. Non sempre è consigliabile attivare questa opzione, poichè causa un notevole rallentamento nella connessione dei client dal momento che i pacchetti del traffico “normale” dovranno transitare sulla VPN prima di poter uscire su internet.
Nella mia configurazione è stata lasciata commentata.

push "dhcp-option DNS 192.168.1.1"
push "dhcp-option DNS 208.67.220.220"
push "dhcp-option WINS 192.168.1.3"

Le prime tre righe permettono di forzare i server DNS e i server WINS tramite il DHCP interno di OpenVPN, mentre l’ultima permette ai client di comunicare tra di loro.

keepalive 10 120

Il keepalive di OpenVPN permette di tenere vive le sessioni che passano attraverso i firewall, il primo parametro stabilisce ogni quanti secondi mandare un messaggio verso il client (è qualcosa di simile ad un ping ICMP), il secondo invece stabilisce il periodo massimo di inattività di una connessione.

tls-auth keys/ta.key 0

È il file necessario per la creazione della connessione cifrata, il secondo parametro settato a 0 indica che la chiave sta venendo usata dal server, mentre sui client sarà impostato a 1.

log-append  /var/log/openvpn/openvpn.log
verb 3

E per concludere i parametri dedicati al logging, che sono abbastanza auto esplicativi. Il livello di verbosità può variare da 1 a 20.

Per testare rapidamente la configurazione è sufficiente lanciare direttamente OpenVPN (assicurandosi prima di aver fermato il demone lanciato dall’init script durante l’installazione):

# invoke-rc.d openvpn stop
Stopping virtual private network daemon: server.
# openvpn server.conf

Se non ricevete nessun errore allora la vostra configurazione è corretta, potete interrompere l’esecuzione con Ctrl+C.

Come ultima cosa è necessario configurare il file /etc/default/openvpn per permettere l’avvio automatico del demone in fase di boot:

...
...
AUTOSTART="server"
...
...

La riga fondamentale è AUTOSTART=”server”, che permette all’initscript di far partire il demone usando la configurazione “server”, quella da noi creata.

Configurazione di IPTables

Per consentire ai pacchetti che viaggiano sulla vpn di passare sulla rete vera è necessario abilitare il forwarding tramite iptables, con due semplici regolette:

iptables -A INPUT -i tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -j ACCEPT

e ovviamente attivare il forward con

sysctl -w net.ipv4.ip_forward=1

Configurazione dei client

La configurazione dei client è abbastanza rapida, innanzitutto vediamo cosa serve per un client:

• La coppia certificato/chiave per il client (i due file .key e .crt)
• Il certificato della CA del server (il file ca.crt)
• La chiave di autenticazione TLS (il file ta.key)
• Il file di configurazione per il client.

I primi tre pezzettini li possiamo recuperare tranquillamente dal server, li abbiamo generati nei passi precedenti, vediamo ora la struttura del file di configurazione:

client

Specifica che si tratta appunto di un client

dev tun
proto udp

queste righe specificano rispettivamente che stiamo creando una connessione a livello IP e che ci vogliamo connettere usando un tunnel UDP,
Ovviamente questi dati devono coincidere con le impostazioni lato server

remote mightyvpn.vostraazienda.it 1194

l’hostname e la porta a quale connettersi, anche in questo caso la porta deve coincidere con quella specificata nella configurazione del server.
È possibile specificare più server remoti, nel caso in cui uno di essi sia inattivo, OpenVPN passerà al successivo.

resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun

Queste direttive stabiliscono che:

• Il client OpenVPN dovrà tentare all’infinito di risolvere il nome del server (ovviamente è utile solo se come remote server si specifica un nome e non un indirizzo IP)
• Il client non deve fare ‘bind’ su una porta specifica
• Il client deve fare “privilege dropping” dopo l’inizializzazione (inutile su sistemi windows)
• Il client deve tentare di rendere persistenti il tunnel

ca ca.crt
cert fpedrini.crt
key fpedrini.key
ns-cert-type server
tls-auth ta.key 1

Ed infine questi sono i parametri relativi ai certificati. Come potete vedere la configurazione è identica al lato server, con l’eccezione della riga ‘tls-auth’, che finisce per “1″.

Una volta salvato il file di configurazione come ‘/etc/openvpn/client.conf’ e affiancato da tutti i vari file a corredo è possibile avviare la connessione ad OpenVPN.

Analogamente a quanto fatto per il server, è possibile fare in modo che il proprio pc avvii la connessione all’avvio del demone OpenVPN modificando opportunamente il file /etc/default/openvpn:

...
...
AUTOSTART="client"
...
...

Conclusioni

Il test principale di funzionamento è quanto di più banale possa esserci: vedere cioè se dai client che si connettono alla rete si riesce ad accedere a computer presenti nella sotto rete, controllando servizi che si conosce come attivi o attraverso banali ping.
In pochi passi un’intera infrastruttura può essere accessibile ovunque, grazie ad OpenVPN!

Installazione, configurazione ed utilizzo

Ma andiamo con ordine! Se non avete già installato questo web server, fatelo ora, usando il metodo più appropriato per la vostra distribuzione linux preferita. A questo punto dovete editare il file di configurazione di default che può essere apache2.conf oppure httpd.conf e assicurarsi che siano abilitati seguenti moduli:

• mod_authn_file
• mod_authz_user
• mod_auth_basic
• mod_auth_digest
• mod_dav_fs

I primi moduli sono necessari per regolare l’accesso alle risorse di apache, l’ultimo è quello che gestirà tutto il calendario.
Bene, ora modificate la configurazione del modulo dav_fs inserendo le segenti voci:

DavLockDB "/usr/var/DavLock"
<Directory "/srv/httpd/htdocs/calendars">
    Dav On
 
    Order Allow,Deny
    Allow from all
 
    AuthType Digest
    AuthName calendars
 
    AuthUserFile "/usr/user.passwd"
    AuthDigestProvider file
 
    <LimitExcept OPTIONS>
        require user nomeutente
    </LimitExcept>
</Directory>

La creazione del file /usr/user.passwd si effettua attraverso il seguente, semplice comando:

$ htdigest -c "/usr/user.passwd" calendars nomeutente

Ovviamente per le direttive siete liberissimi di scegliere i percorsi che più vi aggradano.
Vediamo cosa vogliono dire le varie opzioni:

• DavLockDB serve per specificare quale file apache userà come file di lock per impedire rovinose scritture simultanee sui file gestiti via dav_fs
• Dav On usato all’interno di un tag Directory abilita la gestione di quella cartella tramite il modulo dav_fs
• Seguono le direttive standard per gestire l’autenticazione degli utenti tramite file di password
• Infine con la direttiva LimitExcept si definisce il livello di accesso alle risorse

Questa ultima direttiva è decisamente importante: il modulo dav_fs permette di eseguire degli upload di file sul proprio web server e sicuramente non vogliamo che tale comportamento sia aperto e disponibile a qualsiasi utente di internet!
Così come è scritta, la direttiva richiede un accesso autenticato sia per la modifica dei calendari che per la loro lettura, se volessimo rilassare i permessi, possiamo usare LimitExcept GET OPTIONS: in questo modo è possibile a utenti non autenticati di visionare i file salvati in /calendars ma, francamente, sconsiglio di eseguire questo tipo di rilassamento.
Bene, il server è pronto! Aprite la vostra applicazione di calendaring preferita, potete create un nuovo calendario all’indirizzo http://server/calendars/calendario.ics e usarlo per la gestione dei vostri appuntamenti.

Possibili miglioramenti

Prima di concludere, lascio qualche considerazione per possibili migliorie:

• L’acesso protetto da password serve per controllare chi può accedere alle risorse e chi no, ma senza un adeguato supporto crittografigo risulta quasi inutile: vi consiglio di combinare questa configurazione con il supporto di apache per https o di modificare la regola Allow from per restringere l’accesso alle risorse solo da connessioni sicure come tunnel ssh o vpn
• L’architettura presentata è pensata per un calendar server casalingo, tuttavia scala bene se vogliamo tenere directory separate tra più utenti: basta replicare il blocco di direttive Directory per ogni utenza che si vuole aggiungere adattandola, ovviamente, al nuovo username. I problemi nascono quando si vogliono condividere i calendari in sola lettura:
  • Una prima soluzione, semplice, consiste nel mettersi d’accordo sull’accesso alle risorse: gli stessi client permettono di scegliere se impotare i calendari in sola lettura o meno.
  • Una seconda soluzione, più complessa, prevede l’utilizzo di più direttive Limit al posto di una LimitExcept, in questo modo potremmo usare, per esempio, Limit GET OPTIONS su valid_users per permettere la sola lettura agli utenti autenticati e Limit PUT al proprietario del calendario per permettere solo a lui la modifica dei contenuti. Tale strada, però, può essere potenzialmente pericolosa in caso di utilizzo di metodi http sconosciuti, per maggiori informazioni vi rimando alla documentazione ufficiale delle due direttive
• In questo articolo abbiamo usato il modulo dav_fs solo per gestire un file .ics ma in realtà abbiamo configurato un vero e proprio storage personale sul vostro server apache: potete prendere un qualsiasi client dav e caricare file sotto la cartella /calendars

Conclusioni

Questo è tutto! Come avete potuto notare la creazione di un server per un calendario remoto personale non è poi tanto difficile, per quanto riguarda invece gli ambienti enterprise questa soluzione potrebbe essere un po troppo stretta ma in questo caso si possono applicare le altre idee proposte oppure sposarsi su programmi dedicati come la suite Zimbra oppure il Calendar Server di Apple.

Alla prossima!

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

Il problema è noto: lo strumento per il controllo di risorse e servizi Nagios viene in genere predisposto per inviare le notifiche attraverso messaggi di posta elettronica, ma cosa succede se l’anomalia riguarda proprio l’invio delle mail di notifica? Sul precedente articolo di Mia Mamma Usa Linux “Un Nagios parlante con Festival” è stata presentata una soluzione per fare in modo che un computer segnali i malfunzionamenti attraverso un sintetizzatore vocale e delle casse audio, ma se non si ha la disponibilità di un impianto audio o più semplicemente se la macchina che effettua i controlla risiede in una locazione diversa da quella in cui ci si trova (tipicamente un centro elaborazione dati) come ci si deve comportare?
Una soluzione percorribile è quella di utilizzare le notifiche SMS, che unite alle notifiche standard danno un’approssimativa certezza di ricevere da almeno una fonte la segnalazione di un guasto.
Quanto verrà presentato in questo articolo è nello specifico una soluzione che prevede l’integrazione di Nagios con la chiavetta modello ONDA MT503HS e più in generale una soluzione applicabile a tutte le chiavette USB attualmente sul mercato.

Cenni sul dispositivo

Ogni operatore di telefonia mobile possiede un’offerta che prevede una chiavetta USB funzionante come modem che permette la connessione GPRS/EDGE/UMTS/HSDPA all’operatore stesso e la conseguente navigazione in internet.
Questi tipi di pendrive generalmente hanno una peculiarità interessante, vengono definiti “flip-flop“, possono cioè essere usati in due modi: come dispositivo di archiviazione di massa (possiedono infatti uno slot per micro-sd) o come modem. A deciderne l’impiego è generalmente l’utente che una volta inserita la chiavetta si trova di fronte alla scelta attraverso un menu, quantomeno sui sistemi operativi Microsoft Windows, in quanto il driver viene letto ed installato partendo dai dati che si trovano sulla memoria flash del dispositivo.
Il motivo che rende questo dispositivo ideale per la realizzazione del progetto di notifiche SMS è che una volta posta la chiavetta in stato “modem”, questa risulta interrogabile con i comuni comandi AT, . Questa funzionalità permette quindi di utilizzare il modem per l’invio di SMS. Un altro indubbio vantaggio è quello dell’alimentazione: il dispositivo riceve l’energia necessaria attraverso i 5 volt della presa USB e non richiede pertanto un trasformatore.
Inoltre sebbene ogni chiavetta sia venduta da uno specifico operatore supporta SIM di qualsiasi tipo, pertanto se la pendrive è venduta dall’operatore Tim, è possibile comunque utilizzarla con una SIM dell’operatore Vodafone, e così via.
Tirando le somme si capisce come un computer con collegata una pendrive di questo tipo possa facilmente diventare un gateway sms, proprio quello che serve per realizzare il progetto descritto.
Il motivo per cui la pendrive scelta è il modello Onda MT503HS è puramente casuale, come si dice in questi casi era “quello che passava il convento“.

Requisiti preliminari ed essenziali

Prima di fare qualsiasi cosa, l’esperienza suggerisce di recarsi nel luogo dove dovrà risiedere la macchina su cui verrà installato Nagios, inserire la SIM che si vorrà usare per le notifiche in un telefonino e controllare quanto segnale c’è a disposizione. Una pendrive usb generalmente prende come un comune cellulare, nello stesso posto se quindi il cellulare ha campo, lo avrà anche la chiavetta.
L’esperienza inoltre insegna che si può costruire il miglior software per le notifiche possibile, testarlo in ogni modo ed orgogliosamente portarlo nel luogo dove risiederà convinti del corretto funzionamento per finire a tutta velocità contro il muro rappresentato dell’assenza di campo.
A seconda del luogo quindi è meglio capire quale sia il miglior operatore della zona, in modo da non incorrere in cocenti delusioni.

Configurazione della pendrive

La pendrive Onda MT503HS è venduta come compatibile con tutti i maggiori sistemi operativi: Windows, Linux e Mac OSx. Nella confezione è presente un CD contenente i driver di ogni sistema e se si usa Linux, almeno nel caso di Debian, questi driver non funzionano. Il pacchetto di installazione prevede la compilazione dei sorgenti del modulo relativo al dispositivo, ma l’esito delle operazioni di compilazione è sempre negativo.
Fortunatamente però Linux consente di ovviare al problema con i driver nativi e l’utilizzo di un programma, denominato usb_modeswitch che permette di forzare la scelta dell’impiego del dispositivo.
La procedura di installazione descritta è relativa a Debian Lenny, ma come sempre ci si può riferire al sito del progetto per recuperare i sorgenti o capire dove reperire i pacchetti binari per le più diffuse distribuzioni.
Il pacchetto è installabile attraverso apt-get:

$ apt-get install usb-modeswitch

oltre all’eseguibile /usr/sbin/usb_modeswitch i file necessari al corretto funzionamento del meccanismo di switch della periferica sono due:

/etc/usb_modeswitch.conf

Al cui interno vanno abilitate le righe relative al modello della pendrive. Cercando la parola chiave “ONDA MT503HS”, si trova la sezione in cui abilitare le righe rimuovendo i caratteri “;” iniziali:

########################################################
# ONDA MT503HS (most likely a ZTE model)
#
# Contributor: Lucio Asnaghi a.k.a. kRAkEn/gORe
 
DefaultVendor=  0x19d2
DefaultProduct= 0x2000
 
TargetVendor=   0x19d2
TargetProduct=  0x0002
 
MessageEndpoint=0x08
MessageContent="55534243b0c8dc812000000080000a85010101180101010101000000000000"
########################################################

/etc/udev/rules.d/usb_modeswitch.rules

Analogamente cercando la stringa relativa al modello “ONDA MT503HS”, va abilitata la regola udev che associa l’esecuzione del comando usb_modeswitch all’inserimento della periferica:

########################################################
# ONDA MT503HS (most likely a ZTE model)
#
# Contributor: Lucio Asnaghi a.k.a. kRAkEn/gORe
# Vendor:Product id = 0x19d2:0x2000
SUBSYSTEM=="usb", SYSFS{idVendor}=="19d2", SYSFS{idProduct}=="2000", RUN+="/usr/sbin/usb_modeswitch --DefaultVendor 0x19d2 --DefaultProduct 0x2000 --MessageEndpoint 0x08 --MessageContent 55534243b0c8dc812000000080000a85010101180101010101000000000000"
 
########################################################

E’ palese che a seconda del modello di pendrive in possesso corrisponderà un’abilitazione diversa all’interno dei suddetti file.
Terminate le modifiche è possibile inserire la pendrive nella porta USB, monitorando quanto viene scritto dal sistema all’interno del file /var/log/messages:

Jun 12 09:11:35 nagios kernel: [   21.897954] usb 1-1: configuration #1 chosen from 1 choice
Jun 12 09:11:35 nagios kernel: [   21.901706] scsi1 : SCSI emulation for USB Mass Storage devices
Jun 12 09:11:35 nagios kernel: [   21.913128] usb 1-1: New USB device found, idVendor=19d2, idProduct=0002
Jun 12 09:11:35 nagios kernel: [   21.913139] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jun 12 09:11:35 nagios kernel: [   21.913148] usb 1-1: Product: ONDA CDMA Technologies MSM
Jun 12 09:11:35 nagios kernel: [   21.913154] usb 1-1: Manufacturer: Qualcomm, Incorporated
Jun 12 09:11:35 nagios kernel: [   21.913161] usb 1-1: SerialNumber: Data Interface
Jun 12 09:11:35 nagios kernel: [   23.110641] usbcore: registered new interface driver usbserial
Jun 12 09:11:35 nagios kernel: [   23.110682] usbserial: USB Serial support registered for generic
Jun 12 09:11:35 nagios kernel: [   23.110789] usbcore: registered new interface driver usbserial_generic
Jun 12 09:11:35 nagios kernel: [   23.110796] usbserial: USB Serial Driver core
Jun 12 09:11:35 nagios kernel: [   23.133222] usbserial: USB Serial support registered for GSM modem (1-port)
Jun 12 09:11:35 nagios kernel: [   23.133291] option 1-1:1.1: GSM modem (1-port) converter detected
Jun 12 09:11:35 nagios kernel: [   23.133459] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB0
Jun 12 09:11:35 nagios kernel: [   23.133496] option 1-1:1.2: GSM modem (1-port) converter detected
Jun 12 09:11:35 nagios kernel: [   23.133578] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB1
Jun 12 09:11:35 nagios kernel: [   23.133611] option 1-1:1.3: GSM modem (1-port) converter detected
Jun 12 09:11:35 nagios kernel: [   23.133689] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB2
Jun 12 09:11:35 nagios kernel: [   23.133721] option 1-1:1.4: GSM modem (1-port) converter detected
Jun 12 09:11:35 nagios kernel: [   23.133809] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB3
Jun 12 09:11:35 nagios kernel: [   23.133841] option 1-1:1.5: GSM modem (1-port) converter detected
Jun 12 09:11:35 nagios kernel: [   23.133923] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB4
Jun 12 09:11:35 nagios kernel: [   23.133950] usbcore: registered new interface driver option
Jun 12 09:11:35 nagios kernel: [   23.133957] option: USB Driver for GSM modems: v0.7.2

Dapprima il dispositivo viene riconosciuto come una periferica di archiviazione di massa e subito dopo subentra la regola udev che lo converte in una periferica ad accesso seriale utilizzando il modulo usbserial e creando i device ttyUSB tutti di tipo GSM Modem.
Il dispositivo di riferimento da utilizzare sarà ttyUSB1.

Spedire SMS dalla linea di comando

Tra i vari pacchetti disponibili per la gestione degli SMS in Linux, gsm-utils consente di gestire attraverso la linea di comando quanto necessario per l’invio di SMS. Il pacchetto è disponibile nelle maggiori distribuzioni. L’installazione su sistemi Debian è la consueta:

$ apt-get install gsm-utils

Il comando che permette l’invio dei messaggi di testo è gsmsendsms ed ha la seguente sintassi:

/usr/bin/gsmsendsms -C <numero del centro messaggi> -d /dev/ttyUSB1 <numero di cellulare> "<messaggio di testo>"

I parametri da specificare, come è intuibile, sono il numero del centro messaggi, che varia da operatore ad operatore (ed è rintracciabile generalmente con una semplice ricerca in google), il device da utilizzare, che come precedentemente illustrato è /dev/ttyUSB1, il numero del cellulare di destinazione preceduto sempre dal prefisso internazionale (quindi per l’Italia +39) ed infine il testo da inviare.
Provando a lanciare il comando in questione l’output potrebbe essere il seguente:

/usr/bin/gsmsendsms[ERROR]: unexpected response '+ZUSIMR:2' when sending 'AT+CMGS=18'

Sebbene questo appaia a tutti gli effetti come un errore, l’SMS arriva comunque a destinazione.

Nello specifico…

Per eliminare questo inconveniente (che a tutti gli effetti è qualcosa di unicamente estetico) è necessario utilizzare il programma minicom e configurarlo per accedere al device /dev/ttyUSB1 alla velocità di 9600 baud.
Una rapida occhiata mostrerà infatti come la pendrive scriva costantemente il codice +ZUSIMR:2, confondendo il programma che si aspetta un “OK” come responso al comando AT inviato al dispositivo.
Il problema è risolvibile immettendo la seguente stringa:

AT+CPMS="SM","ME","MT"

attraverso minicom. Subito dopo l’immissione del comando la sequenza interminabile di +ZUSIMR:2 terminerà.
La stringa di comando AT passata al dispositivo seleziona dove verranno memorizzati i messaggi SMS in arrivo. L’ordine indicato è SM (SIM card), ME (dispositivo) e (altra area del dispositivo).

Configurare Nagios

Per concludere il progetto con successo non rimane altro da fare con configurare Nagios in modo che supporti le notifiche via SMS.
Nel file commands.cfg dela directory /etc/nagios3 andranno quindi definiti i nuovi tipi di modifica attraverso l’SMS in questa forma:

# 'notify-host-by-sms' command definition
define command{
	command_name	notify-host-by-sms
	command_line	/usr/bin/gsmsendsms -C <numerocentromessaggi> -d /dev/ttyUSB1 $CONTACTPAGER$ "Nagios - $NOTIFICATIONTYPE$ - Host $HOSTNAME$ is in state $HOSTSTATE$ - Date/Time: $LONGDATETIME$"
	}
 
# 'notify-service-by-sms' command definition
define command{
	command_name	notify-service-by-sms
	command_line	/usr/bin/gsmsendsms -C <numerocentromessaggi> -d /dev/ttyUSB1 $CONTACTPAGER$ "Nagios - $NOTIFICATIONTYPE$ - Service $SERVICEDESC$ (Host $HOSTALIAS$) is in state $SERVICESTATE$ - Date/Time: $LONGDATETIME$"
	}

infine, per ogni contatto definito all’interno della configurazione di Nagios (generalmente nel file contacts.cfg) andranno inserite le nuove notifiche create:

define contact{
        contact_name                    <nome contatto>
        alias                           <alias contatto>
        service_notification_period     24x7
        host_notification_period        24x7
        service_notification_options    u,c,r
        host_notification_options       d,r
        service_notification_commands   notify-service-by-email,notify-service-by-sms
        host_notification_commands      notify-host-by-email,notify-host-by-sms
        email                           <email contatto>
        pager                           <numero di telefono>
	}

Riavviato il servizio, le notifiche via SMS per il contatto arriveranno al numero indicato nel campo pager:

$ /etc/init.d/nagios3 reload

Per testare subito quanto creato sarà sufficiente attraverso l’interfaccia web accedere al dettaglio di un host o di un servizio e cliccare sulla voce “Send custom service notification”. Se l’SMS arriva la missione è compiuta.

Accertarsi che il sistema stia funzionando

Certo si potrebbe sindacare sul fatto che se si rompe la macchina delle notifiche si è punto e a capo, ma questa è una cosa a cui si può porre rimedio inserendo degli invii automatici di SMS a crontab che segnalano come il sistema di notifiche SMS stia correttamente funzionando:

# Notifica quotidiana del funzionamento notifiche SMS
00 09	* * *	root	/usr/bin/gsmsendsms -C <numerodelcentromessaggi> -d /dev/ttyUSB1 <numerodicellulare> "Nagios: Se ricevi questo messaggio, il servizio di notifica SMS funziona correttamente."

Ogni giorno quindi, alle nove della mattina il numero di cellulare inserito nel comando riceverà un SMS che proverà il corretto funzionamento delle notifiche.

Conclusioni

Il metodo presentato nell’articolo è certamente economico, per certi versi non privo di difficoltà, ma indubbiamente alla portata di chiunque.
Scegliendo con oculatezza il piano tariffario associato alla SIM che sarà presente nella pendrive si potrà certamente rendere il servizio di monitoraggio di Nagios completo e professionale.

Nei precedenti articoli pubblicati nella serie “SSH in CHROOT: Una gabbia per la shell sicura” parte 1 e parte 2, veniva affrontato il tema della messa in sicurezza di SSH attraverso una Patch che obbligava determinati utenti a rimanere chiusi all’interno di una gabbia virtuale.
Dalla versione 5 di SSH però è possibile sfruttare un meccanismo nativo che implementa il CHROOT. Ecco spiegato come.

Capire la versione di SSH installata nel sistema

Prima di procedere con la configurazione del pacchetto è bene accertarsi che la versione di SSH installata nel sistema sia uguale o superiore alla 4.8p1, su sistemi Debian e derivati, l’interrogazione è possibile attraverso il seguente comando:

# dpkg -l openssh-*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Nome                                    Versione                                Descrizione
+++-=======================================-=======================================-==============================================================================================
ii  openssh-blacklist                       0.4.1                                   list of default blacklisted OpenSSH RSA and DSA keys
ii  openssh-blacklist-extra                 0.4.1                                   list of non-default blacklisted OpenSSH RSA and DSA keys
ii  openssh-client                          1:5.1p1-5                               secure shell client, an rlogin/rsh/rcp replacement
ii  openssh-server                          1:5.1p1-5                               secure shell server, an rshd replacement

Mentre in sistemi RedHat e derivati è sufficiente interrogare l’elenco pacchetti installati con rpm:

$ rpm -qa openssh*
openssh-4.3p2-16.el5
openssh-askpass-4.3p2-16.el5
openssh-clients-4.3p2-16.el5
openssh-server-4.3p2-16.el5

Nei casi riportati, sul sistema Debian (versione Lenny) la versione di SSH supporta nativamente il Chroot mentre il sistema RedHat (versione 5) no. In questo caso è necessario eseguire l’aggiornamento del pacchetto se ne si vorrà sfruttare la nuova funzionalità, ricompilando localmente la versione 5 partendo dai sorgenti disponibili presso il sito ufficiale del progetto OpenSSH oppure scaricando un rpm precompilato da repository pubblici come http://www.rpmfind.net.

Come funziona il CHROOT nativo

Il metodo con cui il demone SSH, previa configurazione, costruisce la gabbia per l’utente che effettua la login può essere diviso in due tipologie: l’accesso diretto via ssh e quello via sftp.
Nel primo caso la directory nella quale l’utente effettuerà il login dovrà contenere la struttura essenziale di file e directory necessaria alla navigazione all’interno del sistema, mentre attraverso il funzionamento sftp il demone non necessiterà di un ambiente nativo, ma sfruttando il comando interno sftp, fornirà l’interfaccia di accesso al sistema.

Predisposizione del sistema

I test che verranno effettuati nel corso dell’articolo partiranno dal presupposto che esista un gruppo denominato test e che tutte le utenze facenti parte di questo gruppo vengano ingabbiate.
Verrà quindi creato un utente denominato test con cui verranno effettuate le prove:

$ adduser test

Il comando crea automaticamente il gruppo omonimo.
Terminata la creazione dell’utente di test è necessario creare la struttura relativa alla gabbia. Per far questo è possibile utilizzare lo script create_chroot_env.sh contenuto nel file ssh-in-chroot-scripts.tar presentato nella precedente serie di articoli.
Lanciando il comando come segue:

$ ./create_chroot_env.sh /chroot

nella cartella /chroot verrà creato un ambiente con tutti i requisiti imposti da ssh per l’implementazione della gabbia.
Requisito essenziale per il corretto funzionamento del sistema è che la cartella nella quale verrà impostata la gabbia sia accessibile in scrittura alla sola utenza di root. Avendo lanciato lo script come utente root (non sarebbe possibile altrimenti utilizzare il path definito) tale requisito è pienamente rispettato.

Configurazione del demone per l’utilizzo via ssh

A questo punto la configurazione del server ssh andrà variata per supportare il chroot esclusivamente per le utenze facenti parte del gruppo test attraverso l’aggiunta delle seguenti righe nel file /etc/ssh/sshd_config:

Match Group test
        ChrootDirectory /chroot/

terminata la modifica le configurazioni andranno ricaricate attraverso il seguente comando:

$ /etc/init.d/ssh reload

Verifica del funzionamento

Per verificare il funzionamento della gabbia è sufficiente effettuare il login nel sistema e controllare come e se sia possibile muoversi all’interno di questo:

$ ssh test@172.16.1.130
test@172.16.1.130's password: 
Linux anomalia 2.6.26-1-686 #1 SMP Fri Mar 13 18:08:45 UTC 2009 i686
 
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
 
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Jun  9 23:09:39 2009 from 172.16.1.1
-bash-3.2$ pwd
/
-bash-3.2$ ls
bin  dev  etc  home  lib
-bash-3.2$ cd ..
-bash-3.2$ pwd
/
-bash-3.2$ ls
bin  dev  etc  home  lib

l’output illustrato conferma le aspettative: a login effettuato non è possibile scorrere il path precedente alla cartella /. La gabbia funziona.

Configurazione del demone per l’utilizzo via sftp

La configurazione impostata non prevede l’utilizzo di sftp, infatti un tentativo di connessione non andrebbe a buon fine:

$ sftp test@172.16.1.130
Connecting to 172.16.1.130...
test@172.16.1.130's password: 
subsystem request failed on channel 0
Couldn't read packet: Connection reset by peer

per fare in modo che questo tipo di connessione sia utilizzabile, è necessario modificare nuovamente /etc/ssh/sshd_config sostituendo la riga

Subsystem sftp /usr/lib/openssh/sftp-server

con

Subsystem sftp internal-sftp

In questo modo si indica ad ssh di utilizzare per il comando sftp non lo script locale /usr/lib/openssh/sftp-server ma la versione interna al demone.

Verifica del funzionamento

A questo punto dopo aver ricaricato il demone, è possibile provare nuovamente la login via sftp:

$ sftp test@172.16.1.130
Connecting to 172.16.1.130...
test@172.16.1.130's password: 
subsystem request failed on channel 0
Couldn't read packet: Connection reset by peer
rasca@anomalia:~$ sftp test@172.16.1.130
Connecting to 172.16.1.130...
test@172.16.1.130's password: 
sftp> ls
bin   dev   etc   home  lib   
sftp> cd ..
sftp> ls 
bin   dev   etc   home  lib

Come da pronostico, il login ha avuto successo.
E’ da notare che in questo caso la directory di arrivo dell’utenza è sempre la / del chroot ma si può fare in modo che questa corrisponda ad una qualsiasi cartella o alla home dell’utente modificando il parametro ChrootDirectory nel file di configurazione di ssh. E’ consentito l’utilizzo delle diciture speciali %h, corrispondente alla homedir dell’utente, e %u, corrispondente al nome dell’utente.

        ChrootDirectory %h

E’ chiaro che ogni directory scelta dovrà possedere il requisito essenziale di essere di proprietà di root e non scrivibile da alcun gruppo.

Conclusioni

Rispetto alla soluzione presentata nei precedenti articoli, che comportava l’applicazione di una patch ai sorgenti di ssh, quanto illustrato ha l’indubbio vantaggio di sfruttare un’implementazione nativa che non necessita di operazioni sul pacchetto. Certo i requisiti richiesti, in particolare relativamente alla proprietà della cartella madre del chroot, sono piuttosto rigidi ed obbligano a riflettere su come distribuire le utenze.
La soluzione migliore, come sempre, è quella più funzionale allo scopo che ci si prefigge.