(pagina 6 di 10)

L’utility incron

Con la nota utility di scheduling (pianificazione dei processi) cron è possibile programmare nel tempo l’esecuzione di procedure con qualsiasi tipo di periodicità. Analogamente, con incron si può programmare il lancio di qualsiasi programma a seguito di eventi che coinvolgano determinati file. L’analogia con cron è molto spinta e così come si utilizza il comando crontab per programmare nel tempo le azioni, allo stesso modo esiste il comando incrontab per la schedulazione di azioni conseguenti a modifiche su file o directory. L’installazione per chi utilizza sistemi Debian GNU/Linux e derivati è immediata: apt-get install incron. Per le altre distribuzioni bisogna scaricare il codice sorgente all’indirizzo http://inotify.aiken.cz e successivamente compilarlo e installarlo seguendo le istruzioni. In analogia a cron anche incron si compone di due elementi: incrontab con il quale si manipolano le istruzioni di schedulazione; incrond, il processo demone in esecuzione in background, che da luogo alla schedulazione configurata utilizzando i servizi di inotify. Esistono varie tabelle per le schedulazioni; quelle di sistema si trovano sotto /etc/incron.d, mentre ogni utente può gestire una propria schedulazione a condizione che esso stesso sia inserito nel file /etc/incron.allow. Vediamo ora come si gestisce la tabella utente delle istruzioni per incron analizzando un caso reale. Ad esempio, utilizziamo incron in congiunzione con rsync per tenere sempre allineato il backup di una certa directory. Abbiamo scelto rsync perché si tratta di un’ottima utility per sincronizzare file e directory minimizzando il trasferimento dei dati. Se la directory di cui vogliamo il backup è / source_dir e quella sotto cui salvare il backup è /backup_dir, allora il nostro obiettivo è far intervenire rsync ogni qual volta un file o una directory saranno creati, cancellati o modificati in /source_dir o nelle sue eventuali sottocartelle. Sempre in perfetta analogia con cron bisogna eseguire il comando incrontab -e per aprire l’editor con il quale inserire la riga seguente:

/source_dir IN_DELETE,IN_CLOSE_WRITE

/usr/bin/rsync -a -v --delete /source_dir

/backup_dir

Come si evince dall’esempio ogni istruzione per incron è strutturata secondo lo schema seguente: dove con si indica il file o la directory da monitorare, nel nostro caso /source_dir. con gli eventi da monitorare secondo una tabella di simboli. Mentre con il comando da lanciare ad ogni evento che si verifica; nel nostro caso rsync con i relativi parametri. Vediamo ora in sintesi un esempio che ci permette di spiegare un altro aspetto della sintassi di incron. Supponiamo che alla comparsa di un file sotto una certa directory, ad esempio /monitor_dir, bisogna eseguire uno script (/usr/bin/runme) che richiede come argomento il nome del file stesso. La regola da inserire tramite incrontab sarà

/monitor_dir IN_CREATE /usr/bin/runme $@/$#

Gli eventi che riguardano i file

Quali sono gli eventi che riguardano i file? Sono tutti quelli previsti nel file inotify.h sotto /usr/include/sys. E cioè: eventi di base, composti, eventi nel kernel e, infine, quelli particolari. Nelle rispettive tabelle è possibile trovare una lista dei relativi parametri indicativi dell’evento e spesso utilizzati dai vari programmi, ad esempio incron. Inoltre, esiste un importante flag chiamato IN_ NO_LOOP che può essere utilizzato per evitare delle pericolose situazioni di loop. Ad esempio, se creiamo una regola che in seguito alla modifica degli attributi di un file opera un chmod sul file stesso dopo il primo evento la procedura non si fermerà più. Utilizzando IN_NO_LOOP, invece, si disabilita temporaneamente la regola dopo aver processato l’evento. Successivamente la regola verrà di nuovo abilitata.

Eventi nel kernel

Quelli “attivati” direttamente dal kernel Linux

NOME EFFETTOIN_UNMOUNT Unmount del filesystem su cui risiede il file o la directory monitorataIN_Q_OVERFLOWSaturazione della coda che raccoglie gli eventiIN_IGNORED Rimozione di uno dei monitoraggi da parte del sistemaEventi compostiNascono dall’unione di eventi di baseNOME EFFETTOIN_CLOSE IN_CLOSE_WRITE or IN_CLOSE_NOWRITEIN_MOVE IN_MOVED_FROM or IN_MOVED_TOIN_ALL_EVENTSUn qualsiasi evento della tabella “Eventi dibase”Eventi particolariNon classificabili nelle altre categorieNOME EFFETTOIN_ONLYDIR Il monitoraggio avviene solo se il path èuna directoryIN_DONT_FOLLOWMonitoraggio del link simbolico e non del file o della directory a cui il link puntaIN_MASK_ADD Aggiunta di altre condizioni al monitoraggio in essereIN_ISDIR Evento che interessa una directoryIN_ISONESHOT Rimuove il monitoraggio dopo il primo eventoL’applicazione Logsend Per questa applicazione non esiste il corrispondente pacchetto precompilato, quindi, anche gli utenti Debian GNU/Linux devono installare il programma tramite compilazione del codice sorgente. Occorre scaricare il file compresso da http://logsend. sourceforge.net/download.shtml e seguire le istruzioni dettagliate riportate in http://logsend.sourceforge.net/README.shtml. Bisogna solo dedicare particolare attenzione ai requisiti necessari. Nel sistema devono essere disponibili: l’interprete Bash; il pacchetto Dialog, un MTA (Message Trasport Agent) come Postfix, Qmail, Sendmail o Exim e il programma Mailx per l’invio delle e-mail,il comando awk e ancora il pacchetto inotify-tools trattato in precedenza. In breve, supponendo di aver scaricato il package sotto /tmp e utilizzando l’utente root per installarlo bisogna eseguire i comandi seguenti:cd /usr/localtar -xvzf /tmp/logsend-1.0.tar.gzcd logsend-1.0make installOgni utente può quindi configurare logsend per monitorare adeguatamente i file che desidera tramite il comando logsend config, il quale attiva una pratica interfaccia a console. Tramite la configurazione di base si possono impostare i file da monitorare, le stringhe da cercare e l’indirizzo e-mail a cui spedire gli allarmi.

Come backend per logsend scegliamo inotify

Inotify e la notifica degli avvisi tramite e-mail Supponiamo di voler essere avvertiti, tramite e-mail, di ogni accesso come utente root alla nostra macchina costantemente esposta su Internet. Di norma ogni qual volta si verifica questo evento nel file /var/log/auth.log viene scritta una riga del tipo:May 12 18:26:51 machine-name login[11611]: ROOT LOGIN on ‘ttyX’Nella configurazione di base oltre all’indirizzo e-mail a cui vorremmo essere avvertiti inseriremo il file “/var/log/auth.log” come file da monitorare e la stringa “ROOT.LOGIN” come stringa da cercare. Da notare il punto che simboleggia lo spazio bianco: quest’ultimo carattere è vietato in quanto il programma si avvale della nota utility grep, occorre quindi inserire tanti punti quanti sono gli spazi nella stringa in questione. Terminata la configurazione bisogna avviare il programma logsend in modalità batch per iniziare l’attività di monitoraggio. La sintassi del comando è logsend start. Gli accessi come utente root avvengono anche tramite il comando su (switch user); vanno quindi intercettati anche questi eventi che a loro volta lasciano questo tipo di traccia sul file /var/log/auth.log:May 7 19:11:43 machine-name su[10242]:Successfulsu for root by some_userA questo punto, bisogna riavviare la configurazione di logsend e cambiare la stringa di ricerca in questo modo: ROOT. LOGIN\Successful.su.for.root.by. Da notare come l’operatore OR è implementato tramite i due caratteri \. Infine, non resta che riavviare logsend con logsend restart per cominciare a utilizzare la nuova configurazione. Per gli amanti della riga comando va detto che è possibile configurare manualmente logsend senza utilizzare l’interfaccia testuale. Nel file README dell’applicazione è, infatti, illustrata la struttura dei file creati sotto la directory $HOME/.logsend. Udev: un caso reale di utilizzo del nuovo sistema di notifica Per ultimo citiamo un importante fruitore dei servizi di inotify e cioè il sistema per la gestione dell’hardware udev. Questa piattaforma rappresenta, praticamente, la nuova infrastruttura, corredata da una serie di utility, che “gira” in user space e gestisce in modo dinamico il popolamento della directory /dev affinché solo le interfacce (i file) dei dispositivi realmente collegati al sistema siano presenti al suo interno. Ebbene, udevd, il processo demone (il servizio) di udev, eseguito al boot della macchina attraverso lo script /etc/init.d/udev, carica in memoria tutte le regole leggendo i file /etc/udev/rules.d/*.rules. In caso di successiva modifica delle regole, il kernel utilizza proprio inotify per comunicare i cambiamenti a udevd e provvede quindi all’aggiornamento delle proprie regole. A questo punto è chiaro come siano particolarmente importanti in questo caso alcune caratteristiche di inotify. Ad esempio, la comunicazione tramite file descriptor che permette di gestire in tempo reale gli eventi.Link utiliRisorse su Internet per approfondirehttp://inotify.aiken.cz/?section=inotify-cxx&page=about=enhttp://search.cpan.org/~mlehmann/Linux-Inotify2-1.1/Inotify2.pmhttp://pyinotify.sourceforge.nethttp://jnotify.sourceforge.nethttp://tab.snarc.org/projects/ocaml_inotifyhttp://inotify-tools.sourceforge.nethttp://inotify.aiken.cz/?section=incron&page=about=enhttp://distanz.ch/inotailhttp://logsend.sourceforge.nethttp://iwatch.sourceforge.nethttp://mswatch.sourceforge.net

Pagina 6/10