Il 2 ed il 9 marzo 2012, nell’ambito del progetto scuole, presso l’istituto tecnico I.T.I.S. Cannizzaro di Rho, in provincia di Milano, MMUL ha tenuto due seminari tecnici gratuiti sul tema Virtualizzazione in Linux.
Agli alunni è stato offerta la possibilità di visionare una soluzione reale, basata su libvirt/qemu e KVM per sperimentare funzionalità, problematiche, vantaggi e svantaggi relativi alla virtualizzazione in generale e nello specifico in quella OpenSource.

Nell’articolo le foto della giornata e la documentazione scaricabile.

A disposizione degli alunni (e di quanti sono interessati) vengono forniti i pdf contenenti le slide utilizzate negli incontri.

2012/03/02 – Prima parte

2012/03/02 – Seconda parte

Per tutte le scuole ed i professori interessati al progetto scuole di MMUL, il riferimento è il sito ufficiale: http://www.mmul.it/scuole.php.

In ambiente enterprise vi è sempre più sovente l’esigenza di automatizzare qualsiasi processo sistemistico; uno dei processi che toglie tempo al lavoro di amministrazione delle macchine è quello dei rilasci (soprattutto in ambiente di test).

In questo articolo verrà spiegato come poter automatizzare rilasci di siti attraverso SubVersion, Apache e SSH.

Il nostro obiettivo e’ quello di rendere il più possibile automatica tutta l’operazione di rilascio in ambiente di test di alcuni siti statici e di permettere estrema flessibilita’ agli sviluppatori di tali siti, in maniera tale da renderli autonomi per modifiche, aggiornamenti ed eventuali roll-back. Gioca un ruolo molto importante il fatto che, sfruttando SubVersion (e quindi un sistema di versioning), e’ possibile per lo sviluppatore riportare il sito ad una revision specifica in ogni momento.

Ambiente operativo

Prendiamo come case test un ambiente cosi’ configurato:

Distribuzione: Ubuntu 10.04 LTS
Repository Utilizzati: default dell’installazione

- Server A:  Server con Apache: configurazione standard per poter gestire piu’ VirtualHost, dove ogni VirtualHost sara’ un diverso sito da erogare (configurazione VirtualHost Apache2);

- Server B:  Server  con Apache + Subversion configurati  (ci sono veramente molti HOWTO disponibili in rete su come configurare i servizi, ecco un esempio);

Configurazioni preliminari

Una volta installato Apache2, Ubuntu imposta il servizio in modo che venga avviato mediante l’utenza www-data. Questa utenza nel file /etc/passwd si presenta in questa modo:

www-data:x:33:33:www-data:/var/www:/bin/sh

Sia sul Server A che sul Server B è necessario modificare quindi alcuni parametri dell’utenza www-data al fine di avere una home dell’utente “coerente” col sistema, dove sarà possibile posizionare le chiavi pubbliche/private SSH necessarie a far funzionare il tutto: modifichiamo quindi l’utente:

# usermod www-data -d /home/www-data

e creiamone la HOME

<

# mkdir /home/www-data

dando i permessi all’utente

# chown -R www-data:www-data /home/www-data

Per testare il tutto proviamo ad entrare con l’utenza appena creata

# su - www-data

Ora che su entrambi i Server abbiamo modificato l’utenza www-data è possibile iniziare a creare le chiavi necessarie.
In questo case test i fornitori che useranno subversion con relativi progetti saranno:

• fornitore1
• • progetto1
  • progetto2
• fornitore2
• • progetto3
  • progetto4

Configurazione

Il percorso logico che dovranno fare i Server è il seguente:

Server B -> COMMIT SVN (post-commit hook) -> SSH FORCE COMMAND (svn up) -> Server A

E’ necessario quindi creare sul Server B le chiavi SSH, una per ciascun fornitore/progetto, per l’autenticazione automatizzata.

Le fasi sono le seguenti:

Creazione directory base:

[root@ServerB]# su - www-data
[www-data@ServerB]$ mkdir .ssh
[www-data@ServerB]$ chmod 700 .ssh
[www-data@ServerB]$ cd .ssh
[www-data@ServerB]$ mkdir fornitore1 fornitore2

Creazione chiavi fornitore1 (per progetto1 e progetto2):

[www-data@ServerB]$ cd fornitore1
[www-data@ServerB]$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/www-data/.ssh/fornitore1/id_rsa): /home/www-data/.ssh/fornitore1/id_rsa_progetto1
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/www-data/.ssh/fornitore1/id_rsa_progetto1.
Your public key has been saved in /home/www-data/.ssh/fornitore1/id_rsa_progetto1.pub.
The key fingerprint is:
x:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx www-data@ServerB
[www-data@ServerB]$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/www-data/.ssh/fornitore1/id_rsa): /home/www-data/.ssh/fornitore1/id_rsa_progetto2
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/www-data/.ssh/fornitore1/id_rsa_progetto2.
Your public key has been saved in /home/www-data/.ssh/fornitore1/id_rsa_progetto2.pub.
The key fingerprint is:
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx www-data@ServerB

Creazione chiavi fornitore2 (per progetto3 e progetto4):

[www-data@ServerB]$ cd ../fornitore2
[www-data@ServerB]$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/www-data/.ssh/fornitore2/id_rsa): /home/www-data/.ssh/fornitore2/id_rsa_progetto3
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/www-data/.ssh/fornitore2/id_rsa_progetto3.
Your public key has been saved in /home/www-data/.ssh/fornitore2/id_rsa_progetto3.pub.
The key fingerprint is:
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx www-data@ServerB
[www-data@ServerB]$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/www-data/.ssh/fornitore2/id_rsa): /home/www-data/.ssh/fornitore2/id_rsa_progetto4
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/www-data/.ssh/fornitore2/id_rsa_progetto4.
Your public key has been saved in /home/www-data/.ssh/fornitore2/id_rsa_progetto4.pub.
The key fingerprint is:
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx www-data@ServerB

In questo modo sono state create le chiavi necessarie per far sì che il ServerB possa autenticarsi con chiave SSH su ServerA. Ora è necessario modificare il file authorized_keys su ServerA:

# su - www-data
[www-data@ServerA]$ mkdir .ssh
[www-data@ServerA]$ chmod 700 .ssh
[www-data@ServerA]$ cd .ssh
[www-data@ServerA]$ touch authorized_keys
[www-data@ServerA]$ chmod 644 authorized_keys

Da ServerB è necessario prendere le chiavi pubbliche precedentemente create per poi inserirle nel file authorized_keys di ServerA:

[www-data@ServerA]$ cat .ssh/fornitore1/id_rsa_progetto1.pub
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAomhotTKNhOwyWFLF0BctOHG+yg0MVN5DREszJlMz4/UEAOfk1MTftEAHVyqhX/oj7n+0ITB2GTrLSR1n5Yx7WZrBc+4fdZMf6gRUZYeZjDyqj4/Odbuy1XPkXAARcNlSw8tOHi3GzyR3ghUGKtUzcSrbZnSegViVji5Yyvs6tdlToofKjt/r542eWWqj7syRAtDqqmQQNBQxQqMcDIOGaSjIluvg60qkEXnYiqQ+J43xbP8w6YK5Z1trOMuTRb4ocK4aJ0zLMiLnjwLIU+gkl8LlzxZwtE97dURPbVQRxPastFKnTWy0v9jguX7NHZmTN4q7z8OQRH4oagSV1lbdSw== www-data@ServerB

La chiave deve essere copiata e poi incollata nel file authorized_keys di ServerA aggiungendo:

ssh-rsa <strong>command="/usr/local/bin/svnup.sh fornitore1 progetto1"</strong> AAAAB3NzaC1yc2EAAAABIwAAAQEAomhotTKNhOwyWFLF0BctOHG+yg0MVN5DREszJlMz4/UEAOfk1MTftEAHVyqhX/oj7n+0ITB2GTrLSR1n5Yx7WZrBc+4fdZMf6gRUZYeZjDyqj4/Odbuy1XPkXAARcNlSw8tOHi3GzyR3ghUGKtUzcSrbZnSegViVji5Yyvs6tdlToofKjt/r542eWWqj7syRAtDqqmQQNBQxQqMcDIOGaSjIluvg60qkEXnYiqQ+J43xbP8w6YK5Z1trOMuTRb4ocK4aJ0zLMiLnjwLIU+gkl8LlzxZwtE97dURPbVQRxPastFKnTWy0v9jguX7NHZmTN4q7z8OQRH4oagSV1lbdSw== www-data@ServerB

Ovviamente tutte le chiavi pubbliche precedentemente create devono essere aggiunte, cambiando, all’accorrenza fornitore1 progetto1.

Nel case test preso in esame , il file authorized_keys, alla fine, si presenterà in questo modo:

[www-data@ServerA]$ cat .ssh/authorized_keys
ssh-rsa <strong>command="/usr/local/bin/svnup.sh fornitore1 progetto1"</strong> [... key data ..] www-data@ServerB
ssh-rsa <strong>command="/usr/local/bin/svnup.sh fornitore1 progetto2"</strong> [... key data ..] www-data@ServerB
ssh-rsa <strong>command="/usr/local/bin/svnup.sh fornitore2 progetto3"</strong> [... key data ..] www-data@ServerB
ssh-rsa <strong>command="/usr/local/bin/svnup.sh fornitore2 progetto4"</strong> [... key data ..] www-data@ServerB

La parte relativa alla configurazione SSH è terminata; rimangono da configurare  i repository SVN, gli scripts di hook e lo script presente nel force command SSH.

Creare i repository SVN ed i relativi script

Su ServerB I repository SVN dovranno essere cosi configurati:

rootSVN/fornitoreX/

Nel caso in oggetto, su ServerB la situazione sarà:

[root@ServerB]# cd /store/subversion
[root@ServerB]# svnadmin create fornitore1
[root@ServerB]# svnadmin create fornitore2
[root@ServerB]# chown -R www-data:www-data fornitore1 fornitore2

Nota: In questo modo ogni fornitore avrà un proprio repository: ciò fa sì che ogni progetto nuovo creato dovrà essere un commit: le REV gestite da SVN, quindi, non saranno a livello di singolo progetto.

In /rootSVN/fornitoreX/hooks/ saranno presenti gli script di HOOK di SVN:

[root@ServerB]# su - www-data
[www-data@ServerB]$ cd /store/subversion/fornitore1/hooks
[www-data@ServerB]$ cp post-commit.tmlp post-commit
[www-data@ServerB]$ chmod +x post-commit

Il file post-commit deve essere modificato in questo modo:

#!/bin/sh
REPOS="$1"
REV="$2"
/usr/share/subversion/hook-scripts/post-commit-fornitore1.sh "$REPOS" "$REV"

Di seguito lo script /usr/share/subversion/hook-scripts/post-commit-fornitore1.sh

#!/bin/sh
REPOS=$1
REV=$2
SVNLOOK=/usr/bin/svnlook
TMPFILE=$(mktemp /tmp/svnXXX)
$SVNLOOK changed -r "$REV" "$REPOS" | cut -d '/' -f2 | sort | uniq > $TMPFILE
for line in $(cat $TMPFILE)
do
ssh -i /home/www-data/.ssh/fornitore1/id_rsa_$line www-data@ServerA >&2
done
rm $TMPFILE

Cosa succede: lo script post-commit entra in gioco nel momento in cui viene fatto un COMMIT su SVN. Nel momento in cui il COMMIT viene effettuato l’hook prende i parametri “fornitore1 ultimaREV“  e li passa allo script /usr/share/subversion/hook-scripts/post-commit-fornitore1.sh che, tramite svnlook crea una lista (salvata in $TMPFILE ) dei progetti che vengono modificati dal commit. A seconda dei progetti che vengono modificati, lo script fa partire la connessione SSH verso ServerA utilizzando come certificato quello adeguato per far eseguire il force command giusto su ServerA.

Fatto ciò, bisogna configurare lo script /usr/local/bin/svnup.sh su ServerA e inizializzare la DocumentRoot che andrà ad accogliere il commit per essere erogato da Apache2:

[root@ServerA]# cd /usr/local/bin

Nella configurazione di test, la root dei vari repository è:

/store/www

mentre le DocumentRoot dei progetti:

/store/www/progettoX/www

Creare il file svnup.sh e modificarlo come segue:

#!/bin/bash
FORNITORE=$1
PROGETTO=$2</p>
WWWDIR="/store/www/${PROGETTO}/www"
 
(
 
cd $WWWDIR
 
svn --username ${FORNITORE} --password $(grep ${FORNITORE} /home/www-data/mapFornitori | cut -d':' -f2) up
 
)

E’ possibile notare come venga usato il file /home/www-data/mapFornitori come mappatura dei fornitori e della propria password: questo è necessario poichè SVN memorizza un solo username associato ad una sola password nei propri metadata. Il file è così composto:

fornitore1:passwordFornitore1
fornitore2:passwordFornitore2

Ora che il giro SSH + HOOKS SVN è completato, è necessario creare la DocumentRoot del progetto ed inizializzarla (e, quindi, diventerà una working copy):

[root@ServerA]# su - www-data
[www-data@ServerA]$ mkdir /store/www/progetto1
[www-data@ServerA]$ cd /store/www/progetto1
[www-data@ServerA]$ svn co --username=fornitore1 --password=progetto1 http://ServerB/fornitore1/progetto1 www

Nota: se non viene eseguita l’inizializzazione non saranno creati i metadata necessari ad SVN per far funzionare il comando svn up

Da questo momento in poi, ogni qualvolta vi sarà un commit SVN (per esempio viene committata una pagina nuova in progetto1 di fornitore1) il girò sarà il seguente:

Sviluppatore esegue il commit, dopo il quale l’hook post-commit esegue /usr/share/subversion/hook-scripts/post-commit-fornitore1.sh “progetto1″ “2″ che poi esegue   ssh -i /home/www-data/.ssh/fornitore1/id_rsa_progetto1 www-data@ServerA

Quest’ultimo, in virtù dell’opzione command=”/usr/local/bin/svnup.sh fornitore1 progetto1″ fa sì che su ServerA venga eseguito in sequenza:

cd /store/www/progetto1/www
svn --username fornitore1 --password passwordFornitore1 up

Aggiornando la working copy che verrà erogata da Apache2.

Conclusioni

La soluzione presentata mostra come, con un minimo di implementazione, sia possibile creare automatismi preziosi, soprattutto laddove esistono situazioni in cui molte persone sviluppano su siti diversi il cui codice risiede in un repository centrale per il versioning. Gli spunti offerti possono servire da punto di partenza per l’introduzione di varianti volte ad automatizzare il processo di sviluppo. Il limite è solo la fantasia.

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

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

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

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

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

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

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

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

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

inotify

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

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

Alcuni eventi che possono essere monitorati sono i seguenti:

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

incrond

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

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

Intanto andiamo ad installare il demone, operazione estremamente semplice:

# yum install incrond

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

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

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

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

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

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

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

# su - matteo
$ incrontab -e

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

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

I tre campi sono, nell’ordine:

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

Semplice, non trovate?

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

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

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

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

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

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

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

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

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

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

Conclusioni

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

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

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

Il limite è il vostro ingegno

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

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

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

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

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

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

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

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

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

Configurare il sistema per ricevere le trap SNMP

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

# apt-get install snmpd

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

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

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

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

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

disableAuthorization yes
traphandle default /usr/sbin/smptt

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

Configurare il traduttore di trap SNMPTT

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

Intanto installiamo il traduttore:

# apt-get install snmptt

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

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

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

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

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

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

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

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

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

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

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

Catturare le trap

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

# apt-get install sec

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

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

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

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

otteniamo in output le seguenti variabili:

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

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

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

otteniamo, invece, in output le seguenti variabili:

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

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

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

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

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

snmptraphandling.sh

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

Potete scaricarlo da qui: snmptraphandling.zip

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Configurare Nagios

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

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

Notiamo alcune configurazioni particolari:

passive_checks_enabled 1 Determina che il servizio risponde a check passivi

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

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

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

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

A questo punto definiamo l’host:

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

ed infine il servizio:

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

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

Conclusioni

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

Buon lavoro

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

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

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

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

Serie completa:

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

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

Buona visione!

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

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

Parte tre di sei – Heartbeat e Corosync:

Parte quattro di sei – DRBD:

Serie completa:

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

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

Buona visione!

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

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

Ecco le prime due parti.

Parte uno di sei – Introduzione:

Parte due di sei – Cluster:

Ed ecco il link alla documentazione:

Evoluzione dell'alta affidabilita' su Linux - Documentazione

Serie completa:

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

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

Buona visione!

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

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

Prerequisiti

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

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

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

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

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

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

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

# uname -m
x86_64

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

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

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

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

Installazione e configurazione

Il processo di installazione è davvero molto semplice:

# apt-get install qemu-kvm libvirt-bin

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

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

# adduser fpedrini libvirt

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

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

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

che mostrerà un output simile al seguente:

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

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

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

# apt-get install bridge-utils

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

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

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

Riavviando il servizio di networking:

# /etc/init.d/networking restart

il bridge verrà attivato.

Creazione della prima Macchina Virtuale

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

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

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

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

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

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

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

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

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

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

Gestione delle Virtual Machine

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

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

Per lanciare virsh sarà necessario lanciare il comando:

# virsh --connect qemu:///system

Si presenterà quindi una vera e propria shell interattiva:

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

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

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

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

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

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

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

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

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

Conclusioni

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

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

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

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

Evoluzione dell'alta affidabilita' su Linux

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

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

Per iscriversi, compilare il seguente form:

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

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

Topologia.

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

Tali macchine verranno nominate server1, server2 e server3:

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

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

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

Opzionale: importare gli schema.

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

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

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

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

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

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

  dn: cn={x}phamm

  verrà modificato in:

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

  infine, le ultime righe del file andranno cancellate:

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

  Salvando quindi il file.

A questo punto sarà necessario lanciare il comando ldapadd:

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

In modo da importare definitivamente lo schema.

Configurazione consumer per la replica:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Overlay syncprov (sync provider)

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

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

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

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

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

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

Aggiunta del database ldap:

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

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

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

ed importato quindi con ldapadd:

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

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

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

eseguendo nuovamente il comando ldapadd:

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

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

Conclusioni

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