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

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

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

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

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

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

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

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

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

inotify

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

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

Alcuni eventi che possono essere monitorati sono i seguenti:

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

incrond

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

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

Intanto andiamo ad installare il demone, operazione estremamente semplice:

# yum install incrond

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

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

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

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

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

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

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

# su - matteo
$ incrontab -e

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

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

I tre campi sono, nell’ordine:

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

Semplice, non trovate?

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

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

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

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

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

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

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

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

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

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

Conclusioni

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

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

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

Il limite è il vostro ingegno

Debian e le distribuzioni da lei derivate, utilizzano l’accoppiata apt-get e dpkg per installare e mantenere aggiornati i programmi. Mentre dpkg si preoccupa di lavorare esclusivamente in locale, scompattanto i pacchetti ed assicurandosi che la loro installazione sia portata a buon fine, è apt-get il vero cavallo da lavoro: si preoccupa di mantenere aggiornati gli indici per il reperimento dei pacchetti, calcola e risolve le dipendenze al momento dell’installazione di un nuovo programma e si preoccupa di scaricare il deb dai repository remoti.
Quest’ultima azione, il download, può incidere notevolmente sulle performance della rete, specialmente se si è scelto di installare diversi pacchetti (si pensi agli effetti di un apt-get install ubuntu-desktop sopra un Ubuntu base system) e se questa operazione viene effettuata da più di un computer della stessa rete.

Una prima soluzione potrebbe essere quella di tenere un repository locale e scaricare i pacchetti necessari da quel repository, sfortunamente questa soluzione richiede un notevole consumo di spazio ed ogni giorno è necessario scaricare gli aggiornamenti al repository anche se alcuni o tutti dei programmi scaricati non sono necessari.
Per ovviare a questi effetti entrano in gioco i proxy apt: risolvono il problema di consumo di banda tenendo nella cache locale i pacchetti richiesti e sono meglio della presenza di un repository personale in quanto non si devono sprecare spazio e banda per avere tutti i pacchetti salvati nella cache in ogni momento.
La soluzione più semplice per installare un proxy apt è quella di eleggere, se già presente, il proxy della rete a fare anche da proxy per i deb scaricati: da un lato si ha un immediato vantaggio di configurazione, con poche righe uno squid è in grado di tenere in cache pure i pacchetti dei programmi, dall’altro si hanno delle limitazioni sulla flessibilità di configurazione e sui protocolli supportati per il download dai repository.
Per superare anche queste limitazioni è sufficiente utilizzare un programma dedicato al caching dei deb, quello storico è apt-proxy seguito, in ordine cronologico, da approx, apt-cacher e apt-cacher-ng. In questo articolo parleremo dell’utilizzo di approx perchè è il più vecchio proxy apt funzionante, in quanto il povero apt-proxy mostra i segni dell’età non risultando affatto scalabile su larga scala.
Il comportamento dei proxy apt è molto semplice: vengono configurati per fornire la cache di alcuni repository, quando un client li contatta e richiede un pacchetto, i proxy controllano la presenza del pacchetto nella loro cache, se questo manca verrà scaricato dal repository e passato al client altrimenti verrà servita la copia locale, risultando così estremamente veloce e risparmiando un download extra inutile. L’installazione di approx è immediata:

root@proxy:~# apt-get install approx

una volta finito il processo, si deve editare il file /etc/default/approx solamente nel caso sia necessario fornire al nostro proxy apt… un proxy per uscire! Per esempio:

# Default settings for approx, included by the /etc/init.d/approx shell script
 
# Uncomment and edit this definition to have approx use a proxy server
export http_proxy=il-mio-proxy:porta

A questo punto si può procedere alla vera configurazione di approx, il file /etc/approx/approx.conf:

# Here are some examples of remote repository mappings.
# See http://www.debian.org/mirror/list for mirror sites.
 
debian          http://mi.mirror.garr.it/mirrors/debian
security        http://security.debian.org/debian-security
volatile        http://volatile.debian.org/debian-volatile
 
# The following are the default parameter values, so there is
# no need to uncomment them unless you want a different value.
# See approx.conf(5) for details.
 
#$interface      any
$port          80
#$max_wait      10
#$max_rate      unlimited
#$user          approx
#$group         approx
#$syslog         daemon
#$pdiffs        true
#$verbose        false
#$debug         false

La prima sezione specifica a quale nome faranno riferimento i repository proxati, la sintassi è molto semplice:

nome_repo      url_repo

così facendo, all’indirizzo http://proxy/nome_repo risponderà la cache di url_repo o, come accade nella prima riga del nostro file di configurazione, http://proxy/debian/ è una cache per http://mi.mirror.garr.it/mirrors/debian.
A questo punto basta modificare il /etc/apt/sources.list delle macchine della propria rete e del proxy stesso, utilizzando i nuovi url:

http://proxy/debian/   lenny main contrib non-free
http://proxy/security/   lenny/updates main contrib non-free
http://proxy/volatile/   lenny/volatile main contrib non-free

La seconda sezione, invece, si occupa della gestione delle opzioni di configurazione del comportamento di approx stesso, nel nostro esempio abbiamo configurato come porta di ascolto la 80, al contrario del default storico di apt-proxy: la 9999. Se non avessimo cambiato la configurazione, il proxy avrebbe comunque funzionato ma nei client si doveva configurare esplicitamente la porta di ascolto del server usando, per esempio, una riga come http://proxy:9999/debian/ lenny main contrib non-free.
Il proxy è ora in piedi, sta venendo utilizzato dai client e possiamo anche dimenticarci della sua presenza! Se però vogliamo provare a verificare manualmente il suo comportamento, approx ci fornisce due ulteriori programmi che vengono usati esclusivamente da cron per mantenere in forma il proxy ma che il sistemista curioso può provare a lanciare manualmente.
Il primo programma è update_approx che viene schedulato come giornaliero al momento dell’installazione, questo programma si preoccupa di aggiornare la lista e le versioni dei programmi reperibili dai repository remoti.
Il secondo è gc_approx, il garbage collector: come dice il nome, questo programma si preoccupa di tenere pulita la cache di approx, eliminando i pacchetti superfli e non più disponibili dai repository remoti. Al momento dell’installazione questo programma viene schedulato come settimanale.
Credo che valga veramente la pena installare approx o un altro proxy apt: il risparmio di banda è notevole già da quando si utilizzano solo due macchine e la vostra connessione vi ringrazierà

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

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

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

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

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

Ci viene in aiuto script! Tanto semplice quanto funzionale.

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

$ script
Script iniziato, il file è typescript
$

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

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

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

$ exit
exit
Script effettuato, il file è typescript

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

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

Alcune opzioni comode di script sono le seguenti:

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

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

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

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

$ mkfifo temp; script -f temp

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

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

Comodo no?

Buon lavoro.