La virtualizzazione è una tecnologia che sta prendendo sempre più piede nell’informatica moderna grazie alla diffusione di hardware sempre più potente, in grado di far girare più sistemi operativi in maniera concorrente.

In questo articolo introdurremo i concetti di base della virtualizzazione e ci soffermeremo su KVM, uno dei progetti liberi più attivi nel campo della virtualizzazione.

Pro e contro della virtualizzazione

La virtualizzazione che in quest’ultimo periodo occupa un sacco di spazio sulle riviste specializzate e sembra essere l’ultimo baluardo tecnologico, è in realtà una tecnologia che ha origini addirittura negli anni ’60, nei laboratori di IBM dove nacque il CP-40, precursore del sistema CP-67 e di tutta la “VM Family” di IBM, che era alla base dei sistemi operativi per i mainframe IBM s370 prima e s390 dopo.

Ma come mai solo ora la virtualizzazione (e il suo diretto discendente il Cloud Computing) sta tornando così di moda e occupa in maniera prepotente una fetta sempre più grande del mercato?

Come accennato poco sopra, ogni mese l’hardware diventa sempre più potente ed economico, basti pensare all’evoluzione dei processori che dai modelli single core di pochi anni fa siamo arrivati a sei core impacchettati sul singolo processore.

Grazie a questa potenza smisurata, siamo in grado di poter far girare più sistemi operativi sullo stesso hardware in maniera concorrente, senza dover ogni volta riavviare per passare da un sistema all’altro, tramite tecniche di virtualizzazione.

Come dice il nome stesso, la virtualizzazione permette di creare dei sistemi virtuali all’interno del sistema operativo vero e proprio, in modo da far girare un qualsiasi sistema operativo su dell’hardware virtuale messo a disposizione del sistema di virtualizzazione.

In questo modo, avendo abbastanza risorse hardware a disposizione potremo far girare sulle nostre workstation una serie sterminata di virtual machine con i più disparati sistemi operativi, da varie distribuzioni Linux ad altri sistemi proprietari come Windows e MacOs (a patto di rispettare le licenze, ovviamente!).

Il vantaggio più grande è proprio quello di poter disporre di sistemi di test per i più svariati usi, ad esempio uno sviluppatore potrà testare i propri software sui vari sistemi senza avere una pletora di installazioni diverse, mentre un sistemista potrà testare diverse configurazioni in tutta tranquillità senza dover cercare server per creare gli ambienti di test.

Se ci spostiamo invece su ambienti più grandi, come quelli aziendali, la virtualizzazione permette di ridurre i costi e consolidare la propria infrastruttura aziendale, accorpando su un sistema fisico più macchine virtuali, in modo da ridurre sia il costo dell’hardware che i consumi energetici (che spesso e volentieri sono la spesa più grande del reparto IT delle aziende).
Il cloud computing porta addirittura al limite il concetto di virtualizzazione, creando pool di risorse virtuali sparse su vari nodi, proprio nell’ottica di sfruttare sempre meglio le risorse inutilizzate dei vari server.

Ovviamente non è tutto oro quello che luccica, virtualizzare un sistema, specialmente quando si tratta di server, pone seri problemi di performance e ridondanza, visto che bisogna calcolare con molta precisione quante macchine virtuali potranno essere ospitate dal singolo sistema di virtualizzazione per evitare di sovraccaricare la macchina fisica e avere performance poco soddisfacenti, e predisporre sistemi di migrazione automatici delle virtual machine su altri nodi di virtualizzazione per evitare che in caso di guasto hardware si perda una serie di servizi che possono essere vitali, ma questi sono temi decisamente avanzati rispetto allo scopo di questo articolo.

KVM in dettaglio

KVM sta per Kernel-based Virtual Machine e, come dice il nome, è composto da un modulo integrato nel kernel linux (dalla release 2.6.20) che permette di sfruttare le estensioni di virtualizzazione dei processori moderni.

Di per sè KVM non effettua nessun tipo di emulazione, si limita ad attivare le estensioni della CPU e a mettere a disposizione dello userspace un dispositivo in grado di riservare le risorse hardware da mettere a disposizione dei sistemi virtuali.
Un programma userspace (in particolare le libvirt o QEMU, come vedremo in fase di implementazione nel prossimo articolo) si occuperà di richiedere al modulo di riservare questa o quella risorsa e di svolgere le operazioni necessarie per l’esecuzione della VM.
Inoltre si KVM occupa di aggiungere una terza modalità all’esecuzione del kernel, la Guest Mode.

Normalmente il kernel ha due modalità di esecuzione, la Kernel mode (o Ring0) in cui solo software fidato (quindi, di fatto, solo il kernel) può essere eseguito con la massima priorità per operazioni privilegiate come l’accesso diretto all’hardware, e la User Mode, in cui vengono eseguite tutte le operazioni non privilegiate relative ai programmi userspace.

L’introduzione di KVM ha introdotto la Guest Mode, una modalità particolare in cui il kernel del sistema host (che è il sistema vero e proprio che ospita i sistemi guest, cioè le virtual machine) permette ai kernel dei sistemi virtualizzati di eseguire operazioni privilegiate come l’accesso diretto all’hardware virtuale.

Il punto di forza di KVM sta proprio in questa sua semplicità, il cuore del sistema di virtualizzazione (l’hypervisor come vedremo poco più avanti) svolge poche fondamentali operazioni, mentre tutta la parte di emulazione dell’hardware viene demandata a componenti esterne e specializzate (come le libvirt o Qemu).

La semplicità dell’hypervisor è però legata anche al suo punto debole (se così si può definire) di KVM: la dipendenza da hardware specializzato.
KVM riesce ad essere così semplice e rapido proprio grazie all’utilizzo delle estensioni speciali inserite nei processori x86 di ultima generazione: AMD-V per i processori AMD e VT-x per i processori Intel, senza le quali KVM non può proprio funzionare.

Come funziona

Abbiamo parlato dei vantaggi e svantaggi della virtualizzazione, ed in particolare di KVM, ma esattamente cosa sta sotto a questa meravigliosa tecnologia?
In tutti i sistemi di virtualizzazione dai primi sistemi di IBM (il CP-40 nato alla fine degli anni ’60), passando per Xen, VMWare e KVM troviamo un elemento comune chiamato Hypervisor.

L’hypervisor è quel componente (sia esso hardware come nel CP-40 di IBM o software come avviene oggi) che si inserisce tra i sistemi guest (le virtual machine) e l’hardware sottostante e gestisce i meccanismi di virtualizzazione dell’hardware da mettere a disposizione dei sistemi guest.

Architettura di un sistema di virtualizzazione

Si possono riconoscere due tipologie di hypervisor, i cosiddetti “Native” (o “Bare Metal”) e gli hypervisor “Hosted”.
La prima famiglia è la più anziana e trova le sue origini sempre nei laboratori di IBM: si tratta di un piccolissimo strato di software che gira direttamente su hardware specializzato e permette la gestione dei sistemi host.

I sistemi ‘Hosted’ invece, sono i più giovani, si tratta di hypervisor che girano come processo all’interno di sistemi operativi general purpose, i software di virtualizzazione come VirtualBox o VMWare Workstation ne sono un esempio.

Ovviamente come in tutte le cose la distinzione non è più così netta, KVM ad esempio è un ibrido tra le due famiglie dal momento che necessita sia di hardware specializzato (le estensioni per la virtualizzazione del processore), sia di un sistema operativo che permetta a tutti i suoi compontenti di essere eseguiti.

Architettura di KVM

Come si può vedere dalla figura, la parte dell’hypervisor (in arancione) è divisa in due parti, la prima legata allo userspace, le libvirt e QEMU che si occupano di fornire la parte di emulazione dell’hardware (forniscono cioè i virtual device che verranno visti dai sistemi guest), mentre la seconda risiede all’interno del kernel, il modulo di KVM, l’hypervisor appunto che permette la gestione dell’hardware di virtualizzazione (le famose estensioni VTX e AMD-V) e che espone un device file in /dev/kvm usato per associare i sistemi guest alle risorse assegnate.

Conclusioni

La virtualizzazione è un mercato in continua espansione, sempre più vendor stanno impegnando risorse nella ricerca e nello sviluppo di soluzioni alternative.
In questo calderone di soluzioni emergenti, il primo beneficiario è senza dubbio Linux, che grazie alla sua architettura flessibile sta giocando un ruolo chiave per lo sviluppo di nuove tecnologie come KVM che, assieme a lguest e Xen stanno portando a grossi cambiamenti volti all’incremento di performance di tutto il kernel.

Nel precedente articolo è stata affrontata l’evoluzione del progetto Heartbeat, dalla versione iniziale in cui il supporto era limitato a due macchine e con un CRM (Cluster Resource Manager) dalle funzionalità ridotte, per arrivare all’evoluzione del progetto culminata in Pacemaker, il CRM avanzato con il quale è possibile specificare priorità, ordini e dipendenze delle risorse al fine di ottenere il controllo totale su quanto erogato dal cluster.
In questo nuovo articolo viene analizzata a fondo, con un esempio pratico, la configurazione delle due modalità operative di Heartbeat, al fine di effettuare un confronto sul funzionamento del cluster con e senza Pacemaker.

Versioni di Heartbeat ed installazione

Fino alla versione 3 il progetto Heartbeat era un unico monolite contenente tutte le componenti funzionali all’esecuzione del software. L’evoluzione del programma ha comportato la suddivisione dello stesso in sotto progetti, ciascuno sviluppato indipendentemente rispetto agli altri, ma critico per una specifica funzione all’interno dell’architettura cluster.
Ad oggi l’intero progetto Heartbeat è quindi suddiviso in tre componenti:

1. Heartbeat: comprendente il demone heartbeat, fornitore dell’infrastruttura cluster;
2. Cluster Glue: un insieme di librerie con scopi specifici:
   • LRM (Local Resource Manager): incaricato di ricevere le istruzioni dal CRM, passarle ai Resource Agents e riportarne l’esito;
   • STONITH (Shoot The Other Node In The Head): incaricato di gestire situazioni ambigue in cui una risorsa potrebbe essere utilizzata contemporaneamente da più nodi;
   • hb_report: incaricato di fornire dettagli sugli errori che si verificano nel sistema;
   • Cluster Plumbing Library:una libreria per la comunicazioni interne al cluster;
3. Resource Agents: comprendente un insieme di script standard per le risorse del cluster;

A ciascuna di queste componenti corrisponde un pacchetto scaricabile dalla sezione downloads del sito di Heartbeat: http://www.linux-ha.com/wiki/Downloads.
Le maggiori distribuzioni al momento distribuiscono ancora pacchetti di Heartbeat nelle versioni precedenti alla 3.
Scegliendo di utilizzare la versione più recente di ciascun software, è quindi possibile ricompilare manualmente i pacchetti partendo dai sorgenti oppure utilizzare pacchetti ricompilati.
Nel caso si usasse Debian Lenny è possibile dichiarare il seguente repository all’interno del file /etc/apt/sources.list:

deb http://people.debian.org/~madkiss/ha lenny main

Mentre per Ubuntu Hardy Heron i repository sono i seguenti:

deb http://ppa.launchpad.net/ubuntu-ha/ppa/ubuntu karmic main

Ubuntu Lucid Lynx supporta invece la versione più recente della suite Heartbeat.

Per l’installazione sarà quindi necessario utilizzare lo strumento di gestione pacchetti fornito con la propria distribuzione: apt per Debian ed Ubuntu, yast per SuSe/OpenSuse e yum per CentOS/RedHat.

L’esempio che verrà implementato nel corso dell’articolo prevede la messa in alta affidabilità di due servizi nelle due versioni di Heartbeat: un indirizzo IP ed il webserver apache2. Il presupposto da cui si partirà è quello di avere un cluster composto da due nodi, collegati ciascuno alla rete locale (192.168.1.0/24) e l’uno all’altro da un cavo cross (10.0.0.0/24).

Configurazione di Heartbeat in modalità classica (senza CRM)

Sebbene Heartbeat sia giunto ormai alla versione 3.0.3 ed il CRM sia stato introdotto dalla versione 2, la modalità predefinita con cui il software viene avviato è quella senza CRM.
Qualsiasi configurazione Heartbeat 1.x quindi funzionerà verosimilmente su tutte le versioni successive.
Al di là delle innovazioni a livello software apportate al progetto, il principio di funzionamento senza CRM rimane quindi invariato, così come i file di configurazione necessari al funzionamento del cluster, come illustrato nel precedente articolo.
Il primo di questi è /etc/ha.d/ha.cf, il cui contenuto dovrà essere simile a quanto segue (ed identico in entrambi i nodi):

##      keepalive: how long between heartbeats?
keepalive 1
##      deadtime: how long-to-declare-host-dead?
deadtime 10
##      warntime: how long before issuing "late heartbeat" warning?
warntime 5
##      Very first dead time (initdead)
initdead 20
##      What interfaces to unicast heartbeats over?
ucast eth1 10.0.0.1
ucast eth1 10.0.0.2
ucast eth0 192.168.1.86
ucast eth0 192.168.1.66
##      Should we autofailback?
auto_failback off
##      Who is part of the cluster?
node    debian-lenny-nodo1
node    debian-lenny-nodo2
##      Network monitoring
ping 192.168.1.50
respawn hacluster /usr/lib/heartbeat/ipfail
apiauth ipfail gid=haclient uid=hacluster

I commenti presenti all’interno del listato rendono le opzioni autoesplicative. Particolare attenzione va posta relativamente ad alcune opzioni:

auto_failback si riferisce alle risorse: se impostata ad “on” nel momento in cui una risorsa effettua uno switch su un nodo differente dall’attuale (per via di un malfunzionamento di quest’ultimo) nel momento in cui il nodo tornerà attivo la risorsa effettuerà un nuovo switch.

ping definisce un indirizzo ip che verrà usato come riferimento per capire se un nodo è parte della rete: “vedendo” l’indirizzo indicato il nodo avrà coscienza di essere presente sulla rete. A tutti gli effetti l’ip indicato è considerato un nodo del cluster, pertanto dovrà essere un ip affidabile, ad esempio quello del gateway di rete. E’ inoltre possibile definire un gruppo di ip, attraverso la direttiva ping_group in modo da non affidarsi ad un unico host per il monitoring.

respawn e apiauth definiscono rispettivamente un comando e l’utente con cui questo deve essere lanciato. Insieme alla definizione del nodo ping completano la parte di monitoraggio della connettività necessaria ad Heartbeat per regolarsi in caso di connettività limitata od assente.

Le ultime tre opzioni descritte, come apparirà chiaro in seguito, risultano di importanza critica in configurazioni senza CRM.

Il secondo file essenziale alla costruzione del cluster è /etc/ha.d/haresources:

debian-lenny-nodo1 IPaddr::192.168.1.200/24/eth0 apache2

Il contenuto definisce il nodo master per le due risorse definite: l’indirizzo ip 192.168.1.200 (associato all’interfaccia eth0) e apache2, il demone che controlla il webserver. Entrambe le risorse verranno quindi, in condizioni normali, avviate sul nodo identificato come debian-lenny-nodo1.

L’ultimo file ad essere creato è /etc/ha.d/authkeys e contiene le informazioni per la sicurezza delle comunicazioni tra i due nodi. Non essendo vincolante ai fini del progetto avere una comunicazione criptata tra i nodi, il contenuto del file può essere il seguente:

auth 1
1 crc

Che sta ad indicare come non esisterà sicurezza nella comunicazione fra i nodi (eccettuato il controllo sulla corruzione dei pacchetti).

Prima di avviare il demone per la prima volta ed effettuare i test è necessario accertarsi che il demone apache non venga avviato al boot del sistema, poiché verrà gestito da heartbeat. In Debian/Ubuntu si può rimuovere così:

# update-rc.d -f apache2 remove

Mentre in RedHat/Centos/Opensuse il comando da usare è chkconfig:

# chkconfig --level 123456 apache2 off

A questo punto è possibile avviare su entrambi i nodi il demone heartbeat:

# /etc/init.d/heartbeat start

dopo alcuni minuti i servizi dovrebbero salire sul nodo che secondo quanto impostato nella configurazione sarà master, debian-lenny-nodo1. Il tutto è verificabile attraverso il controllo sullo stato dell’interfaccia eth0:0:

# ifconfig eth0:0
eth0:0    Link encap:Ethernet  HWaddr 08:00:27:59:18:22  
          inet addr:192.168.1.200  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:10 Base address:0xd020

E sull’effettiva esecuzione del demone apache2:

# ps -ef| grep apache
root      2052     1  0 11:30 ?        00:00:00 /usr/sbin/apache2 -k start
www-data  2053  2052  0 11:30 ?        00:00:00 /usr/sbin/apache2 -k start
www-data  2054  2052  0 11:30 ?        00:00:00 /usr/sbin/apache2 -k start
www-data  2057  2052  0 11:30 ?        00:00:00 /usr/sbin/apache2 -k start

Test di Heartbeat in modalità classica (senza CRM)

Il comportamento nelle varie situazione del demone heartbeat è osservabile attraverso il principale file di log di sistema, su entrambi i nodi:

tail -f /var/log/syslog

Primo test: disconnessione cavo LAN

Il primo test riguarderà la disconnessione del cavo di rete LAN relativo al nodo master, l’operazione genererà alcune righe di log, la più importante delle quali, sull’unico nodo rimasto attivo in rete, riporterà quanto segue:

...
ResourceManager[14403]: [14415]: info: Acquiring resource group: debian-lenny-nodo1 IPaddr::192.168.1.200/24/eth0 apache2
...

l’indicazione è chiara: le risorse sono state acquisite dal nodo secondario. A rilevare l’assenza di connettività è stato, come precedentemente illustrato, l’esegubile ipfail.

Secondo test: disconnessione cavo Heartbeat

Il secondo test prevede la rimozione del cavo che collega i due nodi del cluster:

...
Apr  8 16:24:16 debian-lenny-nodo1 kernel: [17722.012482] eth1: link down
Apr  8 16:24:25 debian-lenny-nodo1 heartbeat: [14269]: info: Link debian-lenny-nodo2:eth1 dead.
Apr  8 16:24:25 debian-lenny-nodo1 ipfail: [14297]: info: Link Status update: Link debian-lenny-nodo2/eth1 now has status dead
Apr  8 16:24:25 debian-lenny-nodo1 ipfail: [14297]: debug: Found ping node 192.168.1.50!
Apr  8 16:24:26 debian-lenny-nodo1 ipfail: [14297]: info: Asking other side for ping node count.
Apr  8 16:24:26 debian-lenny-nodo1 ipfail: [14297]: debug: Message [num_ping] sent.
Apr  8 16:24:26 debian-lenny-nodo1 ipfail: [14297]: info: Checking remote count of ping nodes.
Apr  8 16:24:27 debian-lenny-nodo1 ipfail: [14297]: debug: Got asked for num_ping.
Apr  8 16:24:27 debian-lenny-nodo1 ipfail: [14297]: debug: Found ping node 192.168.1.50!
Apr  8 16:24:28 debian-lenny-nodo1 ipfail: [14297]: info: Ping node count is balanced.
Apr  8 16:24:28 debian-lenny-nodo1 ipfail: [14297]: debug: Abort message sent.
Apr  8 16:24:28 debian-lenny-nodo1 ipfail: [14297]: info: No giveup timer to abort.
...

I messaggi riguardano l’interfaccia secondaria e, come è osservabile, la perdita di questa interfaccia non provoca alcun tipo di switch, in quanto la comunicazione tra i nodi funziona ancora attraverso l’interfaccia primaria, quindi attraverso la LAN.

Terzo test: spegnimento improvviso nodo master

Il terzo test consiste nella rimozione improvvisa dell’alimentazione relativa al nodo master:

Apr  8 16:24:16 debian-lenny-nodo2 heartbeat: [8170]: WARN: node debian-lenny-nodo1: is dead
Apr  8 16:24:16 debian-lenny-nodo2 ipfail: [8233]: info: Status update: Node debian-lenny-nodo1 now has status dead
...
...
Apr  8 16:24:16 debian-lenny-nodo2 ResourceManager[8913]: [8925]: info: Acquiring resource group: debian-lenny-nodo1 IPaddr::192.168.1.200/24/eth0 apache2
Apr  8 16:24:17 debian-lenny-nodo2 ipfail: [8233]: debug: Found ping node 192.168.1.50!
Apr  8 16:24:17 debian-lenny-nodo2 IPaddr[8937]: [8972]: INFO:  Resource is stopped
Apr  8 16:24:17 debian-lenny-nodo2 ResourceManager[8913]: [8987]: info: Running /etc/ha.d/resource.d/IPaddr 192.168.1.200/24/eth0 start
Apr  8 16:24:17 debian-lenny-nodo2 ipfail: [8233]: info: NS: We are still alive!
...
...

Lo switch avviene in maniera corretta, è possibile notare il messaggio “We are still alive!” che indica come il nodo secondario abbia rilevato che il nodo primario sia assente, acquisendone le risorse, una volta accertato il proprio grado di connettività con la rete.

Quarto test: migrazione manuale delle risorse

Heartbeat dispone di un ristretto set di comandi che consentono di interagire con le risorse. Questi comandi sono contenuti nella cartella /usr/share/heartbeat/, ed il comando che consente di gestire le risorse dichiarate è hb_takeover, la cui sintassi d’impiego è la seguente:

# /usr/share/heartbeat/hb_standby all|foreign|local|failback

I parametri passabili al comando comprendono la possibilità da parte di un nodo di acquisire tutte le risorse (all), le risorse del nodo secondario (foreign), le risorse di proprietà (local), le risorse precedentemente migrate (failback).
Nel caso che si vuole simulare il nodo secondario lancerà il seguente comando:

# /usr/share/heartbeat/hb_standby foreign

Ed il comportamento del cluster, osservabile dal nodo primario, sarà il seguente:

Apr  8 16:28:36 debian-lenny-nodo1 heartbeat: [14269]: info: debian-lenny-nodo1 wants to go standby [local]
Apr  8 16:28:36 debian-lenny-nodo1 heartbeat: [14269]: info: standby: debian-lenny-nodo2 can take our local resources
Apr  8 16:28:36 debian-lenny-nodo1 heartbeat: [14859]: info: give up local HA resources (standby).
Apr  8 16:28:36 debian-lenny-nodo1 ResourceManager[14872]: [14884]: info: Releasing resource group: debian-lenny-nodo1 IPaddr::192.168.1.200/24/eth0 apache2
Apr  8 16:28:36 debian-lenny-nodo1 ResourceManager[14872]: [14895]: info: Running /etc/init.d/apache2  stop
Apr  8 16:28:38 debian-lenny-nodo1 ResourceManager[14872]: [14929]: info: Running /etc/ha.d/resource.d/IPaddr 192.168.1.200/24/eth0 stop
Apr  8 16:28:38 debian-lenny-nodo1 IPaddr[14956]: [14968]: INFO: ifconfig eth0:0 down
Apr  8 16:28:38 debian-lenny-nodo1 IPaddr[14930]: [14972]: INFO:  Success

Le risorse sono state correttamente spostate su debian-lenny-nodo2.

Quinto test: standby manuale di un nodo

Il quinto test della serie prevederà la messa in standby del nodo attivo, al fine di verificare il corretto spostamento delle risorse. Il controllo di questa funzionalità da parte del cluster è possibile mediante lo stesso comando precedentemente illustrato, lanciato senza argomenti (che equivale a lanciarlo parametro “all”) sul secondo nodo:

# /usr/share/heartbeat/hb_standby

Il comportamento è il seguente:

Apr  8 16:29:48 debian-lenny-nodo1 heartbeat: [14269]: info: debian-lenny-nodo2 wants to go standby [all]
Apr  8 16:29:49 debian-lenny-nodo1 ipfail: [14297]: debug: Other side is unstable.
Apr  8 16:29:51 debian-lenny-nodo1 heartbeat: [14269]: info: standby: acquire [all] resources from debian-lenny-nodo2
Apr  8 16:29:51 debian-lenny-nodo1 heartbeat: [14974]: info: acquire all HA resources (standby).
Apr  8 16:29:51 debian-lenny-nodo1 ResourceManager[14987]: [14999]: info: Acquiring resource group: debian-lenny-nodo1 IPaddr::192.168.1.200/24/eth0 apache2
Apr  8 16:29:52 debian-lenny-nodo1 IPaddr[15011]: [15046]: INFO:  Resource is stopped
Apr  8 16:29:52 debian-lenny-nodo1 ResourceManager[14987]: [15061]: info: Running /etc/ha.d/resource.d/IPaddr 192.168.1.200/24/eth0 start
Apr  8 16:29:53 debian-lenny-nodo1 IPaddr[15088]: [15121]: INFO: Using calculated netmask for 192.168.1.200: 255.255.255.0
Apr  8 16:29:53 debian-lenny-nodo1 IPaddr[15088]: [15143]: INFO: eval ifconfig eth0:0 192.168.1.200 netmask 255.255.255.0 broadcast 192.168.1.255
Apr  8 16:29:53 debian-lenny-nodo1 IPaddr[15062]: [15162]: INFO:  Success
Apr  8 16:29:53 debian-lenny-nodo1 ResourceManager[14987]: [15183]: info: Running /etc/init.d/apache2  start

Tutte le risorse vengono acquisite dal nodo debian-lenny-nodo2.

Sesto test: interruzione manuale di un servizio

L’ultimo test della serie comprende lo stop manuale di uno dei servizi erogati. Ad esempio apache:

# /etc/init.d/apache2 stop

è facile verificare come nessuna azione venga svolta da Heartbeat, il servizio infatti rimane spento, e l’unica via per fare in modo che il cluster lo riavvii è quella di mandare in standby manualmente il nodo.

Gli ultimi tre test mostrano come in realtà il controllo manuale del cluster sia unicamente la simulazione della messa in standby di un nodo o lo stop di un servizio attivo. Lo standby non avviene in maniera totale, il nodo non viene escluso dal cluster, semplicemente rilascia le proprie risorse e lo stesso vale per i servizi.
Quanto descritto rappresenta una grossa differenza nei confronti dell’utilizzo del CRM Pacemaker, ed il concetto sarà ancora più chiaro nei paragrafi successivi.

Configurazione di Heartbeat in modalità CRM con Pacemaker

L’esecuzione di Heartbeat in modalità CRM prevede che nel sistema sia installato il pacchetto Pacemaker. Questo pacchetto è disponibile nelle maggiori distribuzioni (e nei repository indicati nel primo capitolo dell’articolo) e tra le varie librerie e file che installa uno su tutti sarà fondamentale nel proseguo dell’articolo: /usr/sbin/crm. Come verrà illustrato in seguito il comando crm consente di interagire direttamente con il cluster, il suo comportamento e la sua configurazione.
Prima di procedere è necessario predisporre nuovamente il file di configurazione /etc/ha.d/ha.cf con questo contenuto, su entrambi i nodi:

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

Le differenze con la precedente configurazione sono subito evidenti. Esiste una nuova opzione chiamata autojoin none che disabilita la funzione automatica di scoperta ed aggiunta di nodi sulla rete, inoltre sono state modificate le informazioni relative alla rete: non viene più definito un unicast per ciascuna interfaccia interessate alla comunicazione del cluster, i pacchetti viaggeranno in multicast per la rete locale ed in broadcast per la rete non condivisa (il cavo cross che collega le due macchine).
Infine, l’opzione crm respawn indica che il cluster userà il Cluster Resource Manager, Pacemaker.
Va sottolineato come siano assenti i parametri relativi al monitoraggio della connettività, che verrà gestita in maniera totale da Pacemaker.
E’ chiaro come in questa configurazione il file /etc/ha.d/haresources non ha più ragione di esistere in quanto, così come spiegato nel precedente articolo, a preoccuparsi della gestione delle risorse è il CRM stesso.
Il file relativo al protocollo di comunicazione e sicurezza /etc/ha.d/authkeys rimane invece identico.

E’ quindi possibile avviare Heartbeat per la prima volta:

# /etc/init.d/heartbeat start

Le fasi di avvio sono visibili attraverso il log, oppure utilizzando il già citato comando crm con il parametro status.
Inizialmente lo stato del cluster sarà il seguente:

# crm status
============
Last updated: Wed Jun 16 11:34:38 2010
Current DC: NONE
0 Nodes configured, unknown expected votes
0 Resources configured.
============

Dopo qualche minuto, una volta che i nodi avranno avviato le comunicazioni la situazione varierà in questa forma:

# crm status
============
Last updated: Wed Jun 16 11:35:48 2010
Stack: Heartbeat
Current DC: debian-lenny-nodo2 (e1f7faf3-7152-4c51-bfc4-b5382944a62e) - partition with quorum
Version: 1.0.8-2c98138c2f070fcb6ddeab1084154cffbf44ba75
2 Nodes configured, unknown expected votes
0 Resources configured.
============
 
Online: [ debian-lenny-nodo1 debian-lenny-nodo2 ]

Il cluster può dirsi così avviato. Sebbene non ci siano risorse configurate (“0 Resources configured.“) i due nodi configurati risultano “Online”, pronti cioè ad erogare risorse e debian-lenny-nodo2 ha il ruolo di DC, Designated Coordinator, il nodo “master” che guiderà cioè le operazioni.

Qualsiasi tipo di configurazione sul cluster può essere effettuata attraverso il comando crm, mediante il parametro configure seguito dalle impostazioni da modificare.
Di seguito in quattro fasi viene illustrata una configurazione che rispetti fedelmente quanto fatto per la versione senza CRM.

Prima fase: comportamento generale del cluster

# crm configure property stonith-enabled="false"

Disabilitazione dello stonith: come anticipato in apertura di articolo, lo stonith prevede la configurazione di device specifici che possano essere guidati al fine di spegnere immediatamente un nodo in situazioni in cui non si ha la certezza di quale nodo sia ancora vivo. Nel caso illustrato la configurazione dello stonith verrà pertanto disabilitato.
Una interessante documentazione su come configurare lo stonith su Heartbeat è disponibile sul sito Novell, a
questo indirizzo.

# crm configure property no-quorum-policy="ignore"

Non considerazione dell’assenza di quorum: se la locazione comune dei dati relativi al cluster (quorum) non sarà accessibile da parte dei nodi, il cluster non dovrà prendere alcun provvedimento. Le opzioni disponibili sono ignore, stop, freeze e suicide.
Il valore stop porterà il cluster a fermare ordinatamente tutte le risorse.
Il valore freeze consentirà al cluster di continuare ad erogare le risorse in esecuzione senza però avviarne di nuove.
Il valore suicide obbligherà il cluster a spegnere immediatamente tutti i nodi con limitato accesso al quorum.

Chiaramente le due opzioni stonith-enabled e no-quorum-policy non vengono considerate nella configurazione classica. Il concetto di quorum e stonith si applica solo a cluster gestiti da CRM, in cui esiste una memoria comune.

Seconda fase: controllo della connettività

Il controllo della connettività con Pacemaker è possibile attraverso la definizione di una risorsa denominata “ping”:

# 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"

Il comando crea una risorsa (primitive) denominata ping, il cui Resource Agent (RA) è di tipo ocf, fornito da pacemaker: il path effettivo dell’eseguibile sarà quindi /usr/lib/ocf/resource.d/pacemaker/ping (si veda l’articolo precedente per l’approfondimento sulle tipologie di resource agent e loro posizionamento).
Il RA supporta diversi parametri, fra questi host_list deve contenere la lista degli host da controllare per verificare la connettività (in questo caso il gateway di rete) e name dovrà corrispondere al nome interno della risorsa (si veda la quarta fase).
Infine le indicazioni che seguono le voci “op” (abbreviazione di operations) consentono di definire le politiche di monitoring della risorsa: come deve essere controllata (ad intervalli di 10 secondi e con 60 secondi di timeout) ed in quanto tempo si deve avviare e fermare (entro i 60 secondi di timeout).

La definizione della risorsa ping non è però sufficiente per fornire ad ogni nodo uno strumento per il controllo della connettività, poiché, definita nel modo indicato, la risorsa ping verrà eseguita su un unico nodo. Proprio per ovviare a questo problema e fare in modo che la stessa risorsa possa girare su più nodi è possibile clonarla:

# crm configure clone ping_clone ping meta globally-unique="false"

Il comando indica al cluster di creare la risorsa ping_clone che girerà su tutti i nodi, indistintamente (meta globally-unique=”false”).

Terza fase: definizione delle risorse

Per riprodurre il test e confrontarlo con il precedente rimangono da definire le due risorse scelte ip e apache. La risorsa ip verrà dichiarata come segue:

# crm configure primitive cluster-ip ocf:heartbeat:IPaddr2 params ip="192.168.1.200" nic="eth0" op monitor interval="10s" timeout="20s" op start timeout="20s" op stop timeout="20s"

il nome della risorsa è cluster-ip ed il resource agent utilizzato sarà di tipo OCF, con fornitore heartbeat.
I parametri comprendono l’indirizzo ip che verrà erogato ed il nic (la scheda di rete) a cui verrà associato.
Per quanto riguarda le politiche di monitoring vale quanto detto poco sopra per la risorsa ping.

Il servizio apache2 verrà dichiarato in maniera similare:

crm configure primitive cluster-apache2 ocf:heartbeat:apache params configfile="/etc/apache2/apache2.conf" httpd="/usr/sbin/apache2" port="80" op monitor interval="10s" timeout="60s" op start timeout="40s" op stop timeout="60s"

E’ da notare che il Resource Agent utilizzato non è, come per la configurazione di Heartbeat senza CRM, lo script di avvio del demone presente in /etc/init.d, ma un vero e proprio resource agent di tipo OCF. I parametri necessari al funzionamento sono il file di configurazione (configfile), l’eseguibile del demone (httpd) e la porta su cui apache sarà in ascolto (port).
Anche in questo caso per le opzioni di monitoring vale quanto espresso in precedenza.

Per completare la configurazione delle risorse verrà definito un gruppo, denominato cluster, a cui verranno associate le risorse definite:

# crm configure group cluster cluster-ip cluster-apache2

Il gruppo cluster potrà essere utilizzato nella configurazione come un unica risorsa, le cui operazioni di avvio e stop rispetteranno l’ordine indicato nella definizione: in fase di start del gruppo cluster verrà avviato prima cluster-ip e poi cluster-apache2, in fase di stop verrà prima stoppato cluster-apache2 e poi cluster-ip.

Quarta fase: associazione delle risorse al nodo attivo

La configurazione del cluster, definiti i parametri di monitoraggio della connessione ed il gruppo delle risorse, potrebbe sembrare a questo punto completa:

# crm status
============
Last updated: Wed Jun 16 15:36:43 2010
Stack: Heartbeat
Current DC: debian-lenny-nodo2 (e1f7faf3-7152-4c51-bfc4-b5382944a62e) - partition with quorum
Version: 1.0.8-2c98138c2f070fcb6ddeab1084154cffbf44ba75
2 Nodes configured, unknown expected votes
2 Resources configured.
============
 
Online: [ debian-lenny-nodo1 debian-lenny-nodo2 ]
 
 Clone Set: ping_clone
     Started: [ debian-lenny-nodo1 debian-lenny-nodo2 ]
 Resource Group: cluster
     cluster-ip	(ocf::heartbeat:IPaddr2):	Started debian-lenny-nodo1
     cluster-apache2	(ocf::heartbeat:apache):	Started debian-lenny-nodo1

Ma non è così. E’ vero che al momento il cluster eroga quanto stabilito, ma non è ancora stato definito il comportamento da assumere in caso di assenza di connettività. Se infatti si dovesse rimuovere il cavo di rete LAN dal nodo debian-lenny-nodo1 le risorse non verrebbero automaticamente migrate sul secondo nodo.
Questo perché il cluster non è istruito a dovere in merito al comportamento da assumere a fronte di un esito negativo delle operazioni effettuate dalla risorsa clonata ping.
Quanto descritto rappresenta un’altra grossa differenza tra le due tipologie di funzionamento: in un caso la definizione di ipfail forzava lo standby delle risorse in autonomia (e minor controllo), con Pacemaker la filosofia cambia: tutto va definito, aggiungendo certamente complessità all’architettura, ma rendendo il controllo sul cluster totale.
Per definire quindi un vincolo sull’erogazione delle risorse è necessario definire una “location”:

# crm configure location cluster_on_connected_node cluster rule -inf: not_defined ping or ping lte 0

Viene definita cioè una regola denominata cluster_on_connected_node associata alla risorsa cluster che prevede di dare il peso di meno infinito (-inf, rendere cioè incapace di erogare risorse) al nodo in cui la risorsa nominata ping non sia definita (not_defined) o il cui codice di uscita sia minore o uguale a zero (lte 0 e quindi il comando ping non ha avuto esito positivo, il ping node non risponde).

Grazie a questa regola la struttura realizzata con Heartbeat e Pacemaker risulta l’esatta replica della soluzione Heartbeat senza CRM per comportamento e configurazione.

La configurazione completa

E’ possibile ottenere il resoconto della configurazione, completo di highlight attraverso il comando crm configure show:

# crm configure show
node $id="1984521f-539f-4967-b0ff-eb23f3cf9ccf" debian-lenny-nodo1
node $id="e1f7faf3-7152-4c51-bfc4-b5382944a62e" debian-lenny-nodo2
primitive cluster-apache2 ocf:heartbeat:apache \
	params configfile="/etc/apache2/apache2.conf" httpd="/usr/sbin/apache2" port="80" \
	op monitor interval="10s" timeout="60s" \
	op start interval="0" timeout="40s" \
	op stop interval="0" timeout="60s"
primitive cluster-ip ocf:heartbeat:IPaddr2 \
	params ip="192.168.1.200" nic="eth0" \
	op monitor interval="10s" timeout="20s" \
	op start interval="0" timeout="20s" \
	op stop interval="0" timeout="20s"
primitive ping ocf:pacemaker:ping \
	params host_list="192.168.1.1" name="ping" \
	op stop interval="0" timeout="60s" \
	op start interval="0" timeout="60s" \
	op monitor interval="10s" timeout="60s"
group cluster cluster-ip cluster-apache2
clone ping_clone ping \
	meta globally-unique="false"
location cluster_on_connected_node cluster \
	rule $id="cluster_on_connected_node-rule" -inf: not_defined ping or ping lte 0
property $id="cib-bootstrap-options" \
	dc-version="1.0.8-2c98138c2f070fcb6ddeab1084154cffbf44ba75" \
	cluster-infrastructure="Heartbeat" \
	stonith-enabled="false" \
	no-quorum-policy="ignore" \
	last-lrm-refresh="1276694458"

E’ da notare che oltre ad essere un comando invocabile con specifiche opzioni, crm può essere lanciato senza argomenti, in modo da accedere alla console di amministrazione interattiva che permette di controllare il cluster su tutti i livelli. Ad esempio digitando in sequenza:

# crm
crm(live)# configure
crm(live)configure# edit

Si accederà alla configurazione riportata sopra all’interno dell’editor di testo vi, questa configurazione potrà essere modificata a piacimento e salvata attraverso il comando vi “:wq”.
Le modifiche verranno applicate digitando:

crm(live)configure# commit

L’interfaccia analizzerà quanto digitato ed applicherà alla configurazione effettiva del cluster le modifiche, ovviamente se e soltanto se queste rispettano la sintassi e la struttura del cluster.

Test di Heartbeat in modalità CRM con Pacemaker

Anche nella configurazione con Pacemaker il comportamento di Heartbeat è osservabile dal file di log di sistema /var/log/syslog. La quantità di log relativa a questa configurazione di Heartbeat è decuplicata rispetto alla configurazione classica, il che rende a volte complicato seguire quanto avviene nel cluster. Un buon approccio in caso di disservizi o comportamenti divergenti da quanto ci si aspetta è quello di cercare parole chiave come “error” o “warning” in modo da evidenziare subito potenziali problemi.

Primo test: disconnessione cavo LAN

Il comportamento di Heartbeat nei confronti della disconnessione del cavo LAN è il seguente (vengono riportate solo alcune righe del log del nodo attivo):

Jun 17 17:11:42 debian-lenny-nodo1 attrd: [2426]: info: attrd_trigger_update: Sending flush op to all hosts for: ping (0)
...
Jun 17 17:11:43 debian-lenny-nodo1 lrmd: [2424]: info: rsc:cluster-apache2:16: stop
...
Jun 17 17:11:46 debian-lenny-nodo1 lrmd: [2424]: info: rsc:cluster-ip:17: stop
...
Jun 17 17:11:49 debian-lenny-nodo1 lrmd: [2424]: info: perform_op:2873: operation monitor[11] on ocf::ping::ping:1 for client 2427, its parameters: CRM_meta_clone=[1] host_list=[192.168.1.1]

Il nodo attivo segnala di aver perso connettività (leggendo la risposta del comando clonato ping) e procede con lo stop delle due risorse interessate (che verranno attivate sul nodo secondario, ovviamente se questo ha connettività).
Il nodo debian-lenny-nodo1 continua a tentare la connessione al nodo ping.
Da notare che debian-lenny-nodo1 non viene in alcuna maniera escluso dal cluster poiché l’interfaccia Heartbeat (il cavo che collega fra loro le due macchine) è attiva, garantendo la comunicazione dei due nodi.

Secondo test: disconnessione cavo Heartbeat

La rimozione del cavo heartbeat, così come il secondo test di Heartbeat senza CRM, non comporta alcuna variazione nello stato del cluster:

Jun 18 10:57:12 debian-lenny-nodo1 kernel: [ 3020.112982] eth1: link down
Jun 18 10:57:20 debian-lenny-nodo1 heartbeat: [11076]: info: Link debian-lenny-nodo2:eth1 dead.

Viene unicamente rilevata (sia dal kernel che da heartbeat) l’assenza di connettività sull’interfaccia eth1, ma la comunicazione del cluster è ancora garantita dal link eth0.

Terzo test: spegnimento improvviso nodo master

Ecco cosa avviene all’atto di spegnimento improvviso del nodo erogante i servizi:

1
2
3
4
5
6
7
8
9
10
11
12
13

Jun 18 11:00:44 debian-lenny-nodo1 heartbeat: [11076]: WARN: node debian-lenny-nodo2: is dead
Jun 18 11:00:44 debian-lenny-nodo1 heartbeat: [11076]: info: Link debian-lenny-nodo2:eth0 dead.
Jun 18 11:00:44 debian-lenny-nodo1 heartbeat: [11076]: info: Link debian-lenny-nodo2:eth1 dead.
...
Jun 18 11:00:45 debian-lenny-nodo1 crmd: [11091]: WARN: check_dead_member: Our DC node (debian-lenny-nodo2) left the cluster
...
Jun 18 11:00:48 debian-lenny-nodo1 crmd: [11091]: info: do_dc_takeover: Taking over DC status for this partition
...
Jun 18 11:00:53 debian-lenny-nodo1 pengine: [12660]: notice: unpack_config: On loss of CCM Quorum: Ignore
...
Jun 18 11:00:53 debian-lenny-nodo1 lrmd: [11088]: info: rsc:cluster-ip:13: start
...
Jun 18 11:00:53 debian-lenny-nodo1 lrmd: [11088]: info: rsc:cluster-apache2:15: start

In sequenza quanto avviene sul nodo sopravvissuto è:

• linea 1,2,3) Rilevazione della perdita di connettività totale con l’altro nodo;
• linea 5) Rilevazione della perdita di DC;
• linea 7) Presa i carico da parte del nodo attuale del ruolo di DC;
• linea 9) Come da configurazione l’assenza di quorum viene ignorata;
• linea 11,13) Avvio dei servizi;

Il nodo debian-lenny-nodo1 ha quindi preso in carico la totalità delle risorse, in maniera automatica.

Quarto test: migrazione manuale delle risorse

La migrazione manuale delle risorse è possibile sempre attraverso l’utilizzo del comando crm:

1

# crm resource migrate cluster debian-lenny-nodo2

In questo caso, il gruppo di risorse cluster viene migrato dal nodo attuale al nodo debian-lenny-nodo2: è possibile migrare indistintamente un gruppo o una singola risorsa, ma se questa fa parte del gruppo, allora tutto il gruppo verrà migrato.
La migrazione della risorsa genera automaticamente un’aggiunta nella configurazione del cluster di questo tipo:

location cli-prefer-cluster cluster \
	rule $id="cli-prefer-rule-cluster" inf: #uname eq debian-lenny-nodo2

il cui scopo è chiaro: la regola infatti indica al cluster di dare priorità inf (ossia infinità) all’esecuzione della risorsa cluster sul nodo il cui comando uname equivale a debian-lenny-nodo2. Non a caso, la regola viene automaticamente battezzata “cli-prefer-cluster”. Va chiarito che sebbene il peso della regola sia infinito, questa decade in caso il nodo preferito smetta di funzionare.
E’ possibile ripristinare la migrazione attraverso il comando inverso:

# crm resource unmigrate cluster

Tale operazione ripristinerà la situazione precedente, rimuovendo la regola aggiunta all’interno della configurazione.

Quinto test: standby manuale di un nodo

Anche la messa in standby di un nodo è effettuabile attraverso il comando crm:

# crm node standby debian-lenny-nodo1

Lo stato del cluster al termine di questa operazione sarà quindi il seguente:

...
Node debian-lenny-nodo1 (1984521f-539f-4967-b0ff-eb23f3cf9ccf): standby
Online: [ debian-lenny-nodo2 ]
 
 Clone Set: ping_clone
     Started: [ debian-lenny-nodo2 ]
     Stopped: [ ping:0 ]
 Resource Group: cluster
     cluster-ip (ocf::heartbeat:IPaddr2):       Started debian-lenny-nodo2
     cluster-apache2    (ocf::heartbeat:apache):        Started debian-lenny-nodo2

Le risorse vengono correttamente migrate sul nodo secondario ed il nodo primario viene messo in stato “standby”. Per ripristinare la situazione è sufficiente anche in questo caso forzare debian-lenny-nodo1 a tornare online:

# crm node online debian-lenny-nodo1

Sesto test: interruzione manuale di un servizio

L’ultimo test della serie prevede l’interruzione manuale di un servizio. Verrà simulato il crash del servizio apache2 tramite un comando kill, Il presupposto è che il servizio apache2 sia in esecuzione su debian-lenny-nodo1:

# killall apache2

Ecco le operazioni che il cluster esegue per porre rimedio alla situazione:

1
2
3
4
5

Jun 18 11:29:21 debian-lenny-nodo1 apache[24129]: [24187]: INFO: apache not running
...
Jun 18 11:29:21 debian-lenny-nodo1 crmd: [11091]: WARN: update_failcount: Updating failcount for cluster-apache2 on debian-lenny-nodo1 after failed monitor: rc=7 (update=value++, time=1276853361)
...
Jun 18 11:29:22 debian-lenny-nodo1 lrmd: [11088]: info: rsc:cluster-apache2:45: start

In sequenza quello che avviene è:

• linea 1) Il monitor ha rilevato che il servizio non sta funzionando;
• linea 3) Pacemaker aggiorna il conteggio dei disservizi relativi alla risorsa cluster-apache2;
• linea 5) La risorsa viene nuovamente eseguita;

La risorsa è di nuovo attiva e funzionante.

E’ possibile monitorare in maniera costante lo stato del cluster attraverso il comando crm_mon il cui funzionamento consiste nell’esecuzione del comando crm status ad intervalli regolari. crm_mon supporta il parametro –failcount che permette di avere un sommario dei disservizi rilevati sul cluster. Nell’esempio illustrato, l’output del comando sarà il seguente:

...
Online: [ debian-lenny-nodo1 debian-lenny-nodo2 ]
 
 Clone Set: ping_clone
     Started: [ debian-lenny-nodo1 debian-lenny-nodo2 ]
 Resource Group: cluster
     cluster-ip (ocf::heartbeat:IPaddr2):       Started debian-lenny-nodo1
     cluster-apache2    (ocf::heartbeat:apache):        Started debian-lenny-nodo1
 
Migration summary:
* Node debian-lenny-nodo1: 
   ping:0: migration-threshold=1000000 fail-count=1
   cluster-apache2: migration-threshold=1000000 fail-count=1
* Node debian-lenny-nodo2:

Il Migration summary presenta la situazione relativa alle risorse intaccate dai nostri test, il cui conteggio dei disservizi è 1 (fail-count=1).
E’ possibile azzerare tale conteggio effettuando un cleanup della risorsa:

# crm resource cleanup cluster-apache2
Cleaning up cluster-apache2 on debian-lenny-nodo1
Cleaning up cluster-apache2 on debian-lenny-nodo2

Conclusioni

Giunti al termine di questo lunghissimo articolo le conclusioni da trarre sono molteplici. La prima di queste è che l’argomento Heartbeat/Pacemaker risulta tutt’altro che esaurito: esistono moltissime altre componenti del progetto che qui non sono state nemmeno accennate. Certo è che da questo confronto balza subito all’occhio come le differenze tra i due tipi di impiego siano sostanziali. La soluzione Heartbeat/Pacemaker sebbene sia evidentemente complicata offre un controllo insperato su tutte le componenti del cluster, oltre ad un monitoraggio costante di tutte le risorse configurate. L’implementazione della soluzione classica è immediata, ma come si è visto limitata.
La scelta su quale sia la scelta migliore per la propria infrastruttura è unicamente dell’utente, che come sempre nel mondo OpenSource è libero di scegliere, sperimentare e realizzare.
Nel prossimo articolo verrà presentata una soluzione Heartbeat/Pacemaker per implementare uno Storage NFS Active/Active basato su DRBD.

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!

Orientarsi nell’attuale panorama dei cluster sotto Linux potrebbe essere, particolarmente per un neofita, molto complicato. L’insieme di progetti, nomi e versioni è certamente variegato.
Ottenere alta affidabilità di servizi sotto Linux è possibile in svariati modi: si può optare per una soluzione completamente commerciale come Veritas Cluster (http://www.symantec.com/it/it/business/cluster-server), si può considerare un prodotto Opensource sponsorizzato da un’azienda commerciale come la RedHat Cluster Suite (http://www.redhat.com/cluster_suite/), prodotta e manutenuta come dice il nome stesso da RedHat (ma disponibile per quasi tutte le distribuzioni) oppure utilizzare Hertbeat (http://www.linux-ha.org/) prodotto e manutenuto dalla comunità del progetto Linux-HA.
Questo primo articolo cerca di analizzare l’evoluzione del progetto Heartbeat, facendo luce su quali siano oggi i software da utilizzare per creare un’architettura ad alta affidabilità attraverso i software OpenSource disponibili: Hertbeat stesso, Pacemaker sino ad arrivare alla Standard Based Cluster Framework con OpenAIS e Corosync.

In principio era Heartbeat

Il progetto Heartbeat nasce nel 1999 con l’obiettivo di creare e diffondere un software Opensource in grado di garantire l’alta affidabilità nei servizi erogati da sistemi Linux.
Heartbeat è di fatto un software per creare cluster di servizi. Un cluster di servizi è composto da un insieme di macchine, definite nodi, sulle quali vengono distribuiti programmi definiti risorse. Se un nodo per qualsiasi ragione smette di funzionare, al suo posto ne subentra un altro in grado di garantire il funzionamento delle stesse risorse, con lo scopo di recare il minor disservizio possibile all’utente finale.
Questa tipologia di funzionamento è definita active-passive. Una risorsa è attiva su un nodo active mentre gli altri nodi passive sono in attesa, pronti ad erogare la risorsa in caso di malfunzionamenti relativi al nodo attivo.

Prima della versione 2.0, Heartbeat supportava cluster composti unicamente da due macchine ed aveva strumenti integrati in grado di svolgere operazioni sulle risorse stesse in maniera limitata. Non era possibile definire priorità nell’avvio delle risorse o dipendenze di una risorsa rispetto ad un’altra. Relativamente alla singola risorsa Heartbeat si preoccupava solamente dell’avvio, del termine e del posizionamento della stessa all’interno di un nodo specifico.
Il modo in cui il cluster gestiva una risorsa era definito dall’RA, il Resource Agent.
Un Resource Agent era uno script a cui il sistema faceva riferimento per avviare, fermare e controllare lo stato delle risorse. I Resource Agent di Heartbeat 1 erano contenuti all’interno delle directory /etc/ha.d/resource.d e /etc/init.d. Questi altro non erano che script di avvio dei demoni che supportavano operazioni di start, stop e status. Potenzialmente quindi QUALSIASI servizio poteva essere posto sotto cluster (purché supportasse le tre operazioni citate), sebbene il controllo da parte del sistema di questi servizi fosse essenzialmente nullo.

I limiti insiti in un’architettura simile sono subito evidenti. Basti pensare ad uno scenario in cui Heartbeat eroga il database MySQL. Il cluster si preoccupa di avviare il servizio sul nodo attivo. Se però MySQL per qualsiasi ragione (carico di utenti eccessivo, saturazione del buffer, mancanza di spazio o banalmente uno stop manuale) smette di funzionare, Heartbeat non ovvia in alcuna maniera all’inconveniente e solo un eventuale crash del nodo attivo provoca il cosiddetto switch della risorsa, lo spostamento cioè della stessa sul nodo rimanente, che a sua volta diventa attivo.
La possibilità di effettuare controlli sullo stato di salute delle risorse e di agire autonomamente in funzione di disservizi nelle versioni precedenti alla 2.0 di Heartbeat poteva essere abilitata mediante l’utilizzo di programmi esterni (ad esempio keepalived), ma non era parte integrante del cluster.

L’avvento del CRM

Un gestore delle risorse è sempre esistito all’interno del software Heartbeat. In origine infatti le informazioni relative al posizionamento della risorse ed alla struttura del cluster venivano lette in fase di avvio da due file di testo:

• /etc/ha.d/ha.cf contenente la definizione della struttura del cluster (numero ed indirizzo dei nodi, tempistiche di controllo, politica relativa ai log);
• /etc/ha.d/haresources contenente la definizione delle risorse erogate dal cluster;

Questi file (identici su entrambi i nodi) contenevano informazioni che così come erano scritte, tali rimanevano sino al termine dell’esecuzione del programma Heartbeat.
La configurazione era quindi statica ed una variazione, per essere assimilata dal sistema, comportava il cosiddetto reload del servizio Heartbeat, una rilettura totale dei file di configurazione.

Questo limite unito a quelli descritti nel paragrafo precedente sono stati al centro dell’evoluzione del progetto Heartbeat e sono culminati nel CRM, il Cluster Resource Manager.
Il CRM introdotto con Heartbeat 2 evolve radicalmente la funzione del gestore delle risorse attraverso una gestione dinamica delle stesse, un totale controllo sui servizi erogati ed il supporto ad un numero di nodi maggiore di due.
Se abilitato (esplicitamente, all’interno della configurazione di Heartbeat) il CRM consente infatti di gestire l’avvio e la destinazione delle risorse, raggrupparle, controllarne lo stato di salute e definire priorità di esecuzione di una risorsa rispetto ad un’altra. Se non abilitato Heartbeat continua a funzionare nella maniera classica descritta in precedenza.
Utilizzando il CRM, tutte le informazioni relative alla configurazione dei nodi, delle risorse ed dello stato generale del cluster sono mantenute all’interno di un unico file XML denominato CIB, Cluster Information Base.
I file che dalla versione 2 di Heartbeat permettono di definire il cluster sono quindi due:

• /etc/ha.d/ha.cf contenente la definizione della struttura del cluster (che dichiara anche l’opzione crm=on, ed indica al sistema di utilizzare il CRM);
• /var/lib/heartbeat/crm/cib.xml contenente tutte le informazioni relative alle risorse ed allo stato attuale del cluster;

I file illustrati sono identici in tutti i nodi. E va sottolineato come le operazioni manuali dirette sul CIB siano sconsigliate, in quanto esistono tool appositi (primo fra tutti il comando crm, che verrà illustrato nei successivi articoli di questa serie) che permettono di interagire con esso.
L’altra grande novità di Heartbeat 2 risiede nel modo in cui le risorse vengono gestite. Infatti il metodo attraverso Resource Agent classici (sebbene supportato) viene sconsigliato in funzione di Resource Agent di tipo OCF, Open Clustering Framework. Questi Resource Agent oltre a possedere le medesime proprietà di quelli classici (quindi start, stop e status) supportano anche ulteriori opzioni che consentono di definire in maniera approfondita il comportamento della risorsa nelle varie situazioni, per aumentare il più possibile il controllo del sistema.
A differenza degli RA classici, gli RA di tipo OCF risiedono nella cartella /usr/lib/ocf/resource.d/.
Maggiori dettagli sui Resoruce Agent di tipo OCF verranno introdotti nei successivi articoli e sono consultabili all’indirizzo http://www.linux-ha.org/HeartbeatResourceAgent.

L’evoluzione della specie: Pacemaker

La necessità di creare un CRM sempre più evoluto che potesse occuparsi a trecentosessanta gradi delle risorse, rendendo più flessibile la gestione delle stesse ed ovviando ai limiti della componente integrata è stata evidenziata a partire dal 2004, anno in cui al progetto Heartbeat è stata affiancato lo sviluppo di un CRM indipendente.
Il nome di questo progetto è Pacemaker.
Pacemaker rappresenta un progetto di CRM a sé stante, indipendente dalla piattaforma cluster di Heartbeat, il cui obiettivo è quello di proporre un’interfaccia comune alla gestione delle risorse del cluster.
Le figure riportate di seguito (ottenute dal sito ufficiale http://www.clusterlabs.org) riassumono le diverse tipologie di funzionamento di Pacemaker, partendo dalla classica Active-Passive:

Figura 1

passando dal supporto di più nodi:

Figura 2

per arrivare al supporto di più nodi collegati al medesimo storage:

Figura 3

Ciascuna di queste tipologie di cluster rappresenta i diversi livelli di complessità ottenibili mediante l’impiego di Pacemaker.
In questo primo articolo le informazioni illustrate vanno prese con beneficio di inventario, in quanto temi come DRBD o Load Balancing non sono ancora stati trattati. Ciò che però è importante capire sono i tre livelli nei quali il cluster viene diviso:

• Il livello hardware: rappresentato dai nodi fisici;
• Il cluster stack: rappresentato dall’unione del CRM con il sistema di gestione della comunicazione dei nodi;
• Il livello servizi: rappresentato dall’insieme dei servizi del sistema che verranno fruiti;

Balzerà all’occhio il fatto che all’interno del cluster stack, il sistema di gestione della comunicazione dei nodi è identificato come OpenAIS e non come Heartbeat. ll motivo di questo è spiegato nell’ultimo paragrafo di questo primo articolo.

OpenAIS: l’avvento dello Standard Based Cluster Framework

In tutte le immagini illustrate nel precedente paragrafo il cosiddetto cluster stack è rappresentato dall’unione di due componenti: la prima è il CRM su cui è stata fatta sufficiente chiarezza, la seconda è OpenAIS.
Secondo la definizione ufficiale, OpenAIS è uno Standard Based Cluster Framework (ossia una struttura di supporto standard per i cluster) che implementa una serie di API (Application Programming Interface, un insieme di strumenti specifici) e di politiche volte a sviluppare applicazioni che mantengono attivi i servizi nonostante potenziali malfunzionamenti.
OpenAIS rappresenta quindi il mezzo utilizzato dal sistema per garantire la comunicazione tra i nodi e permettere al CRM di interagire con gli stessi.
Questo spiega la presenza di OpenAIS nelle figure presentate: la decisione su cosa utilizzare per rendere disponibile la struttura di supporto del cluster a Pacemaker è dell’utente, poiché Heartbeat non è il solo strumento utilizzabile che supporta lo Standard Based Cluster Framework.
In origine il progetto OpenAIS oltre al Framework rendeva disponibile anche il cluster engine, il programma per la gestione dell’infrastruttura del cluster. Dal Luglio 2008 la parte relativa al cluster engine di OpenAIS è stata separata in un progetto a sé stante denominato Corosync.
Corosync è un cluster engine che si pone allo stesso livello di Heartbeat, il cui modello di configurazione verrà illustrato nei prossimi articoli.

Conclusioni

Il numero di nomi e definizioni illustrate in quest’articolo è oggettivamente enorme e giustifica la difficoltà nel mettere insieme le cose. La stesura di questo articolo ha richiesto molto più tempo del previsto proprio per via del fatto che oltre ai nomi, anche i concetti esposti sono moltissimi e parecchio complicati.
Il rischio è quindi che queste tecnologie, che sono alla portata di tutti, rimangano confinate ai margini dell’utilizzo per via di tutte le variazioni che nel tempo hanno riguardato i vari progetti.
Questo non deve succedere: le potenzialità di Pacemaker (con Hertbeat o Corosync) sono enormi e sarà evidente nel corso dei successivi articoli in cui finalmente verrà illustrato come mettere in pratica tutte queste tecnologie OpenSource.

The Onion Router (comunemente chiamato Tor) è un software che implementa la tecnica omonima dell’onion routing per contrastare quella forma di censura chiamata analisi del traffico.
Per capire il funzionamento e l’utilizzo di Tor, dobbiamo essere sicuri di conoscere quale problema vuole risolvere. Cosa è, quindi, l’analisi del traffico?

Con analisi del traffico si definisce una tecnica censoria basata sull’analisi passiva del traffico prodotto da una macchina o da un gruppo di esse. Ispezionando i pacchetti che escono da una rete, un attaccante è in grado di inferire un sacco di informazioni riguardanti l’origine di quei pacchetti. Pensate a una mail: un attaccante che ne intercetta il contenuto è in grado di sapere chi sia il mittente, a quale indirizzo sta scrivendo e cosa gli vuole comunicare. Quando questo concetto viene spostato a livello di traffico di rete lo scenario non cambia: un attaccante che intercetta un qualsiasi traffico di rete è in grado di inferire, dall’header dei pacchetti, chi li ha inviati, chi li riceverà e, guardando il body, cosa si vogliono comunicare.
Una prima soluzione a questo tipo di problemi è quello di impiegare la crittografia, sfortunatamente, in entrambi gli scenari descritti in precedenza, la crittografia stessa non è in grado di fermare l’analisi del traffico ma solo di impedire la lettura dei contenuti del corpo del messaggio: per come deve funzionare la comunicazione su Internet, le informazioni dell’header sono in chiaro e disponibili a chiunque riesca a leggerne il contenuto.
Questo problema è stato affrontato da tempo, con soluzioni più o meno efficaci: all’inizio degli anni 80 David Chaum propose le Mix Networks, una serie di proxy server da utilizzarsi in cascata. In questo modo un attaccante doveva ispezionare il traffico in più punti (all’uscita di ogni proxy, per la precisione) per poter inferire qualcosa di utile sul mittente del pacchetto che usciva dall’ultimo nodo della catena. L’idea di Chaum, benchè non utilizzata, è stato il seme che ha lanciato la ricerca sull’onion routing, letteralmente routing a cipolla.
La ricerca sull’onion routing è stata portata avanti nel corso degli anni 90 dallo United States Naval Research Laboratory che ha poi passato il lavoro alla Electronic Frountier Foundation e, Venerdì 13 Agosto 2004 al 13th USENIX Security Symposium, Tor è stato presentato al pubblico. Da li in poi lo sviluppo del programma è andato in crescendo, gli sviluppatori hanno salutato la EFF che ha dato casa alle prime versioni del programma e, al giorno d’oggi, Tor è un prodotto dell’ormai a se stante Tor Project.
Ma non è solo con la storia che si impara come funziona un protocollo, quindi rimbocchiamoci le maniche e guardiamo da vicino come funziona un programma. Guardiamo la prima figura:

i nodi con un simbolo + verde sono relay della rete Tor, Jane e Bob sono dei server pubblicamente raggiungibili da Internet, Alice è la nostra protagonista e sta utilizzando Tor in modalità client. Dave è un particolare server pubblico chiamato “Tor directory server”, lui e i suoi simili forniscono la lista pubblica di relay Tor e la mantegono periodicamente aggiornata. Il primo passo compiuto dal client Tor di Alice è, appunto, quello di contattare un directory server per ottenere la lista dei nodi marchiati con un simbolo + verde.
A questo punto Alice istruisce il proprio client di contattare il server Bob, per esempio perchè vuole visitare una pagina web ospitata li sopra, il nodo Tor di Alice si preoccupa di costruire una catena di nodi attraverso i quali invierà la richiesta, come mostrato nella seconda figura:

nella terminologia di Tor, i nodi prendono un particolare nome a seconda della loro posizione nella catena di comunicazione o circuito: il primo nodo si chiama Guard Node (nodo di guardia), il secondo Middleman Node (nodo intermediario) e il terzo Exit Node (nodo di uscita). La scelta dei nodi di una catena viene effettuata dal client di Alice in base alle informazioni ricevute dal directory server: ogni relay Tor quando si registra presso le directory invia il proprio indirizzo ip e una serie di caratteristiche. I nodi di uscita sono i più importanti: contattando loro personalmente le macchine esterne alla rete Tor devono dire esplicitamente di essere volenterosi e in grado di farlo. Parimenti, i nodi di guardia vincono questo status quando hanno servito la rete Tor per un lungo periodo: sono nodi fidati a cui possiamo affidare il primo passo per entrare nella rete. Tutti i rimanenti relay sono considerati nodi intermediari. Il perchè di queste scelte e di questa classificazione si può spiegare brevemente dicendo che sono il primo e l’ultimo nodo della catena che rappresentano un ottimo punto per attaccare il protocollo, purtroppo parlare di attacchi al protocollo Tor meriterebbe una serie di articoli a se stante, quindi per questa introduzione ci limitiamo a una seppur stringata spiegazione.
Un altro punto importante è osservare il colore delle frecce: la comunicazione che avviene all’interno della rete Tor è completamente crittata, questo impedisce a un attaccante che riesca a intercettare uno qualsiasi di quei messaggi, di ricostruire tutto il flusso. Nella figura, l’ultimo collegamento (tra Exit e Bob) non è crittato ma questo dipende dal tipo di richiesta che ha effettuato Alice a monte del circuito: nel nostro esempio abbiamo ipotizzato una pagina web servita con HTTP, se Alice avesse usato HTTPS anche l’ultimo link sarebbe stato verde. Va ribadito, comunque, che l’ultima comunicazione è estranea alla trasmissione di informazioni all’interno del protocollo di Tor.
Per capire come mai questo protocollo è resistente agli attacchi di analisi del traffico è utile analizzare cosa accade all’interno di un circuito:

questo è il pacchetto che viene inviato da Alice a Guard, il contenuto della buccia rossa è protetto con le chiavi di Guard stesso, quindi solo lui può leggere cosa c’è scritto. Leggendo le istruzioni contenute in questo strato, Guard capisce che deve inviare il resto del contenuto a Middleman:

questo è il contenuto visto da Middleman: come nel caso precedente la buccia di colore verde è leggibile solo dal destinatario. In questo strato Middleman legge che deve spedire il resto del contenuto ad Exit. Come potete notare, già a questo livello è sparita ogni indicazione riguardante Alice.

Questo è l’ultimo passaggio: Exit riceve da Middleman quello che rimane della cipolla, legge il contenuto decifrabile solo da lui e scopre che deve fare richiesta, secondo l’esempio che ci sta accompagnando per tutto l’articolo, di una pagina web presso il server Bob.
Una volta che Bob ha trasmesso il contenuto necessario ad Exit questo impacchetterà tutto e spedirà a Middleman il quale, vedendo che gli sta arrivando una risposta da Exit, passerà a Guard e questi chiuderà il circuito inviando la risposta ad Alice.
In questo modo il protocollo è in gradi di sconfiggere l’analisi del traffico: l’utilizzo della crittografia e del “remixaggio” dei pacchetti impedisce a un attaccante che osserva il traffico prodotto da uno qualsiasi dei nodi di correlarne il contenuto e il mittente. Inoltre, per prevenire che uno dei nodi del circuito possa leggere arbitrariamente il contenuto delle risposte, la comunicazione viene protetta con una chiave di sessione, che viene modificata frequentemente, apribile solo da Alice.

Per il momento questo è tutto: spero di aver stuzzicato il vostro interesse in questa tecnologia, l’installazione e l’utilizzo di questo programma sono sicuramente materiale per un prossimo articolo!

Dopo aver affrontato i comandi interni alla shell Bash ed i comandi di sistema richiamabili all’interno dalla stessa per la manipolazione degli stream di output e dei contenuti dei file in questo articolo verranno trattati i comandi per la gestione delle code di stampa.
Verranno illustrati i comandi per inviare un file direttamente alla stampante, analizzare la coda di stampa e rimuovere lavori in coda.

I comandi per operare sulle code di stampa nei sistemi Linux moderni sono forniti dal pacchetto del server di posta CUPS. CUPS fornisce un set di comandi retro compatibili al precedente gestore della posta Linux, LPD: questo significa che il nome degli stessi è stato mantenuto identico in modo da favorire l’integrazione di CUPS con i programmi che fanno riferimento a comandi di sistema come lpstat, lpq e così via.
Sebbene CUPS di default renda disponibile un’interfaccia web alla porta 631, alla quale si può accedere con il proprio browser, molte volte potrebbe essere necessario utilizzare la linea di comando per operare sulle code di stampa. I comandi che consentono tali operazioni si dividono in comandi che richiedono i permessi dell’utente root ed in comandi utilizzabili da utenti non privilegiati.

Informazioni sulle stampanti (utente root)

lpstat

Capire quali sono le code configurate all’interno del sistema è il primo passo per iniziare ad operare all’interno delle stesse.
Il comando lpstat consente di visualizzare diverse informazioni sulle stampanti installate all’interno del sistema, ad esempio attraverso l’opzione “-p” il comando restituisce l’elenco delle stampanti:

# lpstat -p
la stampante Brother-HL-4040CN è in attesa.  Abilitata da gio 19 nov 2009 18:23:32 CET
la stampante HPDeskJet9300 è in attesa. Abilitata da sab 21 nov 2009 18:15:58 CET
la stampante PDF è in attesa.  Abilitata da gio 19 nov 2009 17:29:14 CET

Un diverso elenco, contenente i riferimenti delle stampanti (socket, path remoti, etc.) è ottenibile attraverso l’opzione “-v”:

# lpstat -v
dispositivo per Brother-HL-4040CN: socket://192.168.1.13
dispositivo per HPDeskJet9300: smb://RASCA/RASCABOX/HPDeskjet9300
dispositivo per PDF: cups-pdf:/

E’ possibile inoltre identificare la coda di default verso cui vengono diretti i lavori in stampa (opzione “-d”):

# lpstat -d
destinazione predefinita di sistema: PDF

Tutte le informazioni illustrate sono ottenibili in un unico contatto attraverso l’opzione “-t”, mentre, lanciato senza argomenti, il comando restituisce l’elenco dei lavori in coda, ottenibile anche con i comandi illustrati di seguito.

Gestire la coda (utente root)

lpq

E’ possibile ottenere l’elenco dei lavori accodati nella stampante di default o di una specifica attraverso il comando lpq:

# lpq
PDF è pronta
Posiz.   Proprietario    Stampa   Doc.             Dim. totali
1st     rasca   298     Command-Line Printing and Optio 396288 byte

Nel caso si volessero conoscere i dettagli della coda relativa ad una stampante specifica, questa va specificata con l’opzione “-P”:

# lpq -P HPDeskJet9300
HPDeskJet9300 è pronta
nessuna voce

lprm

Per operare sulle code, rimuovendo lavori di cui si conosce l’identificativo (ottenuto attraverso lpq), è possibile utilizzare il comando lprm, indicando con l’opzione “-P” l’accoppiata coda/identificativo:

# lprm -P PDF/298

Inviare stampe (utente non privilegiato)

lpr

Se un utente comune volesse lanciare delle stampe da linea di comando, cosa molto utile in caso di lavori di sistema notturni, notifiche di problemi (o qualsiasi altro motivo per cui sia sensato utilizzare della carta!), il comando da utilizzare è lpr che stampa il contenuto di un file di testo passato come parametro:

$ lpr testfile

pr e fmt

lpr può essere utilizzato anche per dirigere l’output di un comando alla stampante. Ad esempio, utilizzando i comandi pr o fmt che formattano un file di testo per la stampa è possibile passare attraverso una pipe ad lpr la stampa da effettuare:

$ pr -a testfile | lpr

oppure

$ pr -a testfile | lpr

mpage

Lo stesso discorso si applica al comando mpage che consente di operare con maggior dettaglio sul formato di stampa. Lanciato senza argomenti, mpage produrrà una pagina divisa in quattro contenente il testo all’interno del file passato come parametro. Attraverso l’opzione “-b” è poi possibile specificare il formato della carta che verrà utilizzato dalla stampante (di default A4). Per conoscere i formati supportati è possibile utilizzare il parametro “-b” con l’aggiunta di un punto interrogativo:

$ mpage -b?
Mpage knows about the following paper types:
Type           Points Wide Points High
-------------- ----------- -----------
Letter                 612         792
LetterSmall            612         792
Tabloid                792        1224
Ledger                1224         792
Legal                  612        1008
Statement              396         612
Executive              540         720
A0                    2384        3368
A1                    1684        2384
A2                    1192        1684
A3                     842        1192
A4                     596         842
A4Small                595         842
A5                     420         595
B4                     729        1032
B5                     516         729
Folio                  612         936
Quarto                 610         780
10x14                  720        1008

Oltre all’utilizzo attraverso una pipe, mpage supporta anche la stampa diretta di file (anche in formato postscript), così come funziona lpr:

$ mpage -PPDF testfile

Numerose sono le opzioni disponibili per il comando mpage e sono tutte documentate nella man page del programma.

Conclusioni

Questa breve carrellata di comandi presenta alcune utili informazioni che potrebbero risultare vitali in situazioni (volute o meno) in cui non sia disponibile altro accesso al sistema che quello della linea di comando.
Approfondendo presso i link presentati qui sotto sarà possibile acquisire la padronanza totale del sistema di stampa da linea di comando.

Fonti di informazioni utili:

Pagina ufficiale del progetto CUPS: http://www.cups.org/documentation.php/options.html
The Linux Printing Usage HOWTO: http://tldp.org/HOWTO/Printing-Usage-HOWTO.html

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!

Nel primo articolo di questa serie sono stati affrontati i comandi interni alla shell Bash che permettono di agevolare il proprio lavoro ed ottimizzarne le tempistiche di realizzazione.
In questa nuova puntata verranno trattati comandi di sistema, generalmente ignorati, richiamabili all’interno della shell Bash per la manipolazione degli stream di output e dei contenuti dei file.

Comandi per l’elaborazione degli stream di testo

Lo studio del contenuto dei file, dal filtro dei contenuti all’ordinamento di questi sono operazioni effettuate quotidianamente attraverso diffusissimi comandi come cat, grep e sort. Ma esiste un nutrito numero di comandi utilizzabili per l’elaborazione dei così detti “stream” di testo, eccone descritti alcuni.

tac

Il funzionamento di tac è quello dell’esatto opposto di cat. Esso infatti concatena e stampa il contenuto dei file in ordine inverso, partendo cioè dall’ultima riga. Supponendo di avere il seguente file di testo:

$ cat elenco
1
2
3
4
5
6

l’output generato da tac sarà il seguente:

$ tac elenco
6
5
4
3
2
1

tr

Il comando tr permette di modificare o cancellare caratteri da uno stream di input. Dato ad esempio il file contenente l’elenco precedente, sarà possibile ad esempio sostituire i caratteri newline (accapo) con il carattere “#”, utilizzando il comando in questa forma:

$ cat elenco_num | tr "\n" "#"
1#2#3#4#5#6#

L’opzione “-d” del comando consente di eliminare e non sostituire le occorrenze trovate, applicato al comando precedente, correggerebbe l’output come segue:

$ cat elenco | tr "\n" "#" | tr -d "#"
12345678910

tr permette di utilizzare anche specifici set di caratteri, senza che ne venga indicato uno specifico. Ad esempio dato il seguente file di testo:

$ cat elenco
A
B
C
D
E
F

è possibile convertire tutte le lettere maiuscole in minuscole attraverso l’utilizzo dei seguenti set:

$ cat elenco | tr "[:upper:]" "[:lower:]"
a
b
c
d
e
f

L’elenco completo dei set di caratteri utilizzabili si trova nella man page del comando.

nl

nl consente di numerare le righe proveniente da uno stream di input. La forma in cui la numerazione appare dipende dalle opzioni passate, senza alcuna opzione il comando numererà le righe con gli indici allineati a destra:

$ cat elenco | nl
     1	A
     2	B
     3	C
     4	D
     5	E
     6	F

è possibile specificare un formato diverso per l’indice di riga attraverso l’opzione “-n”, ad esempio per fare in modo che gli indici siano allineati a sinistra l’opzione da passare sarà “-n ln”, mentre per lasciare gli indici allineati a destra e fare in modo che gli spazi precedenti siano riempiti da zero l’opzione sarà “-n rz”.
E’ possibile specificare anche il carattere di separazione tra l’indice e la riga associata, che di default è tab, con un altro carattere attraverso l’opzione “-s”.
Ecco un esempio:

$ cat elenco | nl -n rz -s "#"
000001#A
000002#B
000003#C
000004#D
000005#E
000006#F

paste

Il comando paste permette di unire due file riga per riga. Nell’esempio più banale paste è utilizzato come segue:

$ paste elenco elenco_num 
A	1
B	2
C	3
D	4
E	5
F	6

ed anche per questo comando è possibile sostituire con l’opzione “-d” il carattere che separa le righe, di default sempre tab, con un carattere a scelta:

$ paste -d "#" elenco elenco_num
A#1
B#2
C#3
D#4
E#5
F#6

paste può essere utilizzato per operare anche su stream di input in modo da unire le righe prodotte ad un’elaborazione a quelle di un file:

$ tac elenco|paste - elenco
F	A
E	B
D	C
C	D
B	E
A	F

lo stream generato dal comando tac viene utilizzato da paste attraverso l’introduzione del carattere “-” per ottenere l’unione di tutte le righe del file con quelle dello stesso, ma contrapposte.

wc

wc effettua un conteggio e totalizza a seconda delle opzioni il numero di caratteri (“-m”), parole (“-w”), byte (“-c”) e linee (“-l”) di un file o di uno stream di input. Ad esempio per conoscere il numero di file nascosti presente in una directory, sarà sufficiente utilizzare il comando come segue:

$ ls .* | wc -l
681

Lanciato senza argomenti wc restituisce tre valori: il numero di linee, di parole e di byte. Ad esempio nel caso di un calcolo su due file il comportamento del comando sarà il seguente:

$ wc elenco elenco_num 
 6  6 12 elenco
 6  6 12 elenco_num
12 12 24 totale

tee

Il comando tee permette di redirigere l’output di un comando all’interno di un file e nel contempo stamparlo a video. Mentre la ridirezione classica effettuata attraverso il carattere “>” non permette di consultare istantaneamente l’output, attraverso tee è possibile osservare riproporre il flusso output del comando lanciato ed al contempo salvarlo in un file:

$ tac elenco | tee elenco_inv | wc -l
6

L’esempio dimostra la peculiarità del comando tee: lo stream di output viene registrato all’interno del file elenco_inv e passato al comando wc che ne calcola il numero di righe.

Conclusioni

Chiaramente ciascuno dei comandi illustrati possiede numerosi altri parametri che ne alterano il funzionamento, questi sono consultabili attraverso le man page sempre complete e prodighe di importanti informazioni. Scopo di questa serie di articoli rimane quello di fornire spunti dietro i quali approfondire.
Nel prossimo articolo verranno affrontati i comandi utilizzabili per la gestione delle code di stampa da linea di comando.

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

La linea di comando e più propriamente la console bash rappresentano lo strumento di cui ogni sistemista Linux non può fare a meno. Modificare file, elaborare contenuti ed operare sui processi sono parte del lavoro quotidiano di chiunque gestisca sistemi informatici più o meno ampi.
Interessante è capire come esistano moltissimi comandi a disposizione di un sistemista oltre a quelli comunemente usati che, per quanto ignorati, possono facilitare il lavoro quotidiano.
Questo primo articolo cerca di effettuare una panoramica ricca di esempi di come sia possibile utilizzare comandi incorporati della shell come set, declare, type e molti altri.

Comandi interni alla shell

La prima panoramica riguarda i comandi interni alla shell. Caratteristica di questi comandi è di non avere binari corrispondenti installati nel sistema (in directory come /bin, /sbin, /usr/bin e così via), infatti è l’ambiente erogato dall’eseguibile bash (a sua volta un binario installato nel sistema) a renderli disponibili.

set

Il comando set permette di modificare molti comportamenti e funzionalità della bash. Per abilitare una funzionalità si antepone all’opzione interessata un carattere “-”, viceversa per disabilitarla è sufficiente anteporre un carattere “+” all’opzione.
Lanciato senza parametri il programma restituisce le impostazioni generali della shell, comprensive di variabili e funzioni che si riferiscono all’ambiente.
Alcuni esempi di utilizzo di set:
Per fare in modo che le variabili create vengano automaticamente esportate è possibile attivare l’opzione “a”:

$ set -a
$ VARIABILE="VALORE"
$ bash
$ echo $VARIABILE
VALORE

Per fare in modo che i comandi lanciati all’interno del sistema siano stampati, sarà sufficiente attivare l’opzione “x”, prima dell’output di ogni comando successivo lanciato apparirà il comando effettivamente lanciato. Cosa questo significhi lo si capisce dal seguente listato:

rasca@anomalia:~$ set -x
++ echo -ne '\033]0;rasca@anomalia: ~\007'
rasca@anomalia:~$ ls
+ ls --color=auto
...
...

il comando lanciato è quindi in realtà un alias dello stesso con l’opzione “–color=auto”.

Le altre funzionalità relative al comando set si trovano nella voce omonima della man page del comando bash.

declare

Il comando declare è utilizzato per la dichiarazione delle variabili. Generalmente in bash una variabile viene dichiarata automaticamente con la sua definizione:

$ FOO=bar

dopodiché è utilizzabile con il nome $FOO. Il comando declare consente in fase di dichiarazione di specificare il tipo di variabile oltre che alcuni attributi inerenti al suo utilizzo.
Ad esempio, per dichiarare un array utilizzando il comando declare si utilizzerà l’opzione “-a”:

$ declare -a elementi=("primo" "secondo" "terzo")

mentre l’opzione “-i” dichiarerà una variabile di tipo integer:

$ declare -i numero=10

declare torna utile in fase di definizione anche per esportare automaticamente le variabili, attraverso l’opzione “-x”:

$ declare -x -i numero=10

questo comando ottiene lo stesso effetto di:

$ export numero=10

ma in più aggiunge anche la definizione del tipo. Infine, attraverso l’opzione “-r” è possibile rendere la variabile readonly, ossia non scrivibile all’interno della sessione.

NOTA: Le variabili di tipo array non sono esportabili a causa di un baco nella BASH (vedere la man page).

type

Il comando type può essere utilizzato per conoscere le caratteristiche relative agli argomenti passati. Attraverso l’opzione “-t” viene restituito il tipo di parametro passato:

$ type -t ls
alias
$ type -t /bin/ls
file
$ type -t echo
builtin
$ type -t set_prefix
function
$ type -t while  
keyword

E’ da notare la differenza tra “ls” e “/bin/ls”, rispettivamente un alias (relativo ad un file eseguibile) ed un file eseguibile. Ad un comando di tipo builtin non corrisponde necessariamente un file eseguibile, mentre le ultime due righe rappresentano rispettivamente una funzione disponibile nell’ambiente ed una parola chiave relativa al linguaggio bash.
Un’altra opzione supportata dal comando type è “-a” che indica tutte le corrispondenze al parametro passato. Ad esempio, relativamente ai comandi precedentemente esposti i risultati saranno i seguenti:

$ type -a echo
echo is a shell builtin
echo is /bin/echo
$ type -a ls  
ls is aliased to `ls --color=auto'
ls is /bin/ls
$ type -a set_prefix
set_prefix is a function
set_prefix () 
{ 
    [ -z ${prefix:-} ] || prefix=${cur%/*}/;
    [ -r ${prefix:-}CVS/Entries ] || prefix=""
}
$ type -a while     
while is a shell keyword

il comando echo viene indicato come interno e disponibile inoltre con l’eseguibile /bin/echo, lo stesso avviene per il comando ls per il quale viene indicata la definizione dell’alias oltre che il path del file effettivo. Infine la funzione set_prefix viene stampata nella sua interezza, mentre per while rimane l’indicazione di keyword.

exec

Il comando exec permette di lanciare un comando utilizzando il process ID (PID) della shell corrente. Questo significa che la shell verrà rimpiazzata dal comando, non generando un nuovo PID e comporta inoltre che il termine del comando corrisponderà con il termine della shell.
Ad esempio, se nell’ambiente grafico da una console viene lanciato il comando

$ exec xterm

alla chiusura della shell del programma xterm, anche la console verrà automaticamente chiusa.

jobs

Se il comando interno bg viene utilizzato per mandare un processo in background (cioè sullo sfondo del sistema e non in primo piano, mantenendone l’esecuzione) ed il comando interno fg viene utilizzato invece per mandare in foreground (quindi, in primo piano) un processo, il comando jobs permette di effettuare il listato dei processi e di conoscere informazioni relative a questi.
Supponendo di avere due script denominati script e script1 lanciati entrambi automaticamente in background attraverso il carattere speciale & alla fine dell’invocazione:

$ ./script &
[1] 28548
$ ./script1 &
[2] 29261

Sarà possibile conoscere lo stato dei processi in sospeso attraverso jobs:

$ jobs
[1]-  Running                 ./script &
[2]+  Running                 ./script1 &

Di questi attraverso l’opzione “-l” si potrà conoscere identificativo e PID:

$ jobs -l
[1]- 28548 Running                 ./script &
[2]+ 29261 Running                 ./script1 &

O solamente il PID:

$ jobs -p
28548
29261

Su tali processi sarà possibile effettuare operazioni di kill (considerando il PID):

$ kill 28548
$ 
[1]-  Terminated              ./script

Oppure operazioni di foregrounding/backgrounding, attraverso i già citati comandi interni fg e bg, considerando invece l’identificativo:

$ fg 2
./script1

Il tutto grazie ai dati resi disponibili dal comando interno jobs.

Conclusioni

I comandi interni alla bash illustrati e molti altri sono tutti ottimamente documentati all’interno della già citata man page della Bash ($ man bash), più propriamente nel capitolo “COMANDI INCORPORATI DELLA SHELL“.
Nella seconda parte di questo articolo verranno trattate utility di sistema come paste, tee, apropos e molte altre, generalmente poco utilizzate, ma di indubbio interesse.