COME REALIZZARE SOSO

(Smart Optical Sensors Observatory)

di Massimo Silvestri (2008)

Introduzione
Le pagine che seguono descrivono la realizzazione di  una completa stazione di rilevamento ottico SOSO (Smart Optical Sensors Observatory) dotata della capacità di rilevare un eventuale movimento nell'immagine inquadrata dalla/e telecamera/e  con cui è equipaggiata per registrare sequenze video su  hard disk. Il presente tutorial fornirà le conoscenze per realizzare sia la parte hardware che la parte  software: a fine percorso si avrà a disposizione uno strumento che permetterà di sorvegliare  costantemente la volta celeste e registrare in tempo reale tutti gli eventi che si paleseranno nella zona monitorata. Questo strumento è realizzato con l'obiettivo di individuare e registrare fenomeni atmosferici anomali  che, per la rarità o la rapidità con cui si palesano, risultano difficili da osservare direttamente (fulmini  globulari, sprites, elves, etc.) e fenomeni conosciuti (ma altrettanto sfuggevoli) come fulmini, meteore e  bolidi. Il sistema SOSO inoltre, ha la capacità di avviare diverse procedure attraverso scripts con le quali controllare  ulteriori strumenti esterni affiancati al sistema per migliorarne la capacità di rilevamento e misurazione.
Prima di tutto, SOSO, dovendo essere uno strumento rivolto al rilevamento e alla registrazione di FLTA (Fenomeni Luminosi Transitori in  Atmosfera), dovrà essere dotato di telecamere estremamente sensibili e nel contempo a bassissimo rumore. E' previsto che debba lavorare in località remote dove l'osservazione è facilitata o dove si suppone che tali fenomeni si presentino più facilmente (vedi ad es. la vallata di Hessdalen), per cui la stazione dovrà essere dotata di un sistema operativo stabile, onde evitare blocchi irrecuperabili al sistema stesso; dovrà possedere inoltre tutta una serie di tool software ( programmi) per la gestione remota, l'upgrade del proprio software, il download dei dati ed i  sistemi di auto-ripristino. Nello specifico, il software di rilevamento del movimento dovrà essere facilmente programmabile in ogni suo parametro e possibilmente adattabile ad ogni situazione. Dovrà infine possedere la capacità di gestire più telecamere contemporaneamente e allo stesso tempo utilizzare il minor numero possibile di risorse del sistema operativo su cui è installato. Ciò è richiesto in quanto il personal computer deputato a queste operazioni, potendosi trovare ad operare in luoghi isolati ed impervi, potrebbe essere alimentato tramite batterie e  pannelli solari; pertanto, oltre al compito di gestire le telecamere, dovrà anche incaricarsi di espletare ogni altra funzione necessaria al conseguimento del lavoro assegnatogli (server FTP, gestire le comunicazioni, interfacciarsi e gestire altri strumenti). Avere più personal-computer, ognuno specializzato in un determinato compito, non è proponibile a fronte di una fonte di alimentazione energetica basata unicamente su pannelli solari.

La telecamera - Come abbiamo accennato, per questa realizzazione la telecamera dovrà essere ad elevata sensibilità, per poter rilevare le luci più deboli presenti nel cielo notturno, e  avere un basso rumore, per evitare falsi rilevamenti causati dai disturbi introdotti dalla sezione amplificatrice (effetto neve). A tale proposito è d'obbligo orientarsi verso telecamere che, secondo specifiche, montano sensori CCD estremamente sensibili seguiti da una sezione amplificatrice sulla quale si può intervenire al fine di determinare, in maniera fine, il livello di amplificazione del segnale. si consiglia pertanto l'utilizzo di telecamere ad uso astronomico come alcuni modelli della Mintron e della Watec (entrambe con uscita analogica in formato PAL) che si interfacciano senza problemi con le diverse schede di acquisizione analogica presenti sul mercato (sia PCI che USB) e che appunto forniscono una regolazione fine della sezione amplificatrice. Motion (il software di rilevamento) permette l'uso anche di network-camere o IP-camere, di cui sconsigliamo l'uso, vista la loro scarsa sensibilità.
Il Personal Computer - SOSO è stato realizzato utilizzando un Pentium IV a 3 Ghz, con 2 Giga di RAM e 250 Giga di hard disk.  Con questa configurazione, dopo più di un anno di funzionamento ininterrotto, non si sono mai manifestati problemi tecnici (esaurimento di risorse o blocchi causati da un hardware). Attualmente i processori P IV sono oramai obsoleti al confronto con i Core Duo e i Quad Core, per cui utilizzando questi processori di ultima generazione si avranno risorse maggiori da impegnare per ulteriori compiti. Considerando che il personal computer, utilizzato per questo tipo di realizzazione, sarà impiegato a tempo pieno, per tale scopo si potrà tranquillamente usare un  P 4  (a 3 Ghz) dismesso, oppure acquistarlo a basso prezzo presso una delle tante fiere d'elettronica. Non bisogna però lesinare sulla
dimensione della memoria RAM e nei confronti dell'hard disk, punti nevralgici del sistema. A seguito dell'esperienza acquisita in questo anno di vita di SOSO, una volta messo a punto il software di rilevamento si avranno da 1 a 2 Giga byte di materiale video (jpg e avi) registrato per notte. Molti file tra cui falsi allarmi dovuti alla scintillazione stellare, aerei e uccelli, verranno successivamente eliminati, ma è fondamentale avere un alta capacità di memorizzazione specialmente se non si ha una buona linea ADSL con cui scaricare da remoto l'HD. Deve essere presente una scheda di rete per l'eventuale collegamento ad un modem/router ADSL o ad un dispositivo wireless, con antenna modificata per coprire la distanza al primo punto utile d'accesso alla rete. Per chi non avesse a disposizione una connessione a banda larga è auspicabile l'utilizzo di un vecchio modem analogico a 56 Kbyte: questo non tanto per il download dei dati (con un disco capiente si può lasciare il sistema in funzione per alcune settimane prima di raggiungere lo strumento ed effettuare un backup in loco) ma quanto per la verifica del sistema ed eventuali piccoli interventi da remoto.
La custodia per telecamere - Come ho spiegato in precedenza, lo strumento che si va a realizzare deve funzionare continuamente a prescindere dalle condizioni climatiche presenti sul luogo di installazione. La telecamera, elemento centrale del sistema, sarà montata in esterno ed esposta a qualsiasi situazione atmosferica e quindi sia ai rigori dell'inverno (vento, pioggia, neve)  che al clima caldo e torrido dell'estate. Pertanto la scelta del tipo di custodia diventa strategica: ci si deve orientare da subito verso una custodia con indice di protezione (IP) 66. La presenza nella custodia di un tettuccio costituisce una buona scelta in quanto l'intercapedine d'aria che si forma fra corpo della custodia e tettuccio costituisce un buon sistema per proteggere da eccessivi innalzamenti  della temperatura all'interno della custodia quando è esposta al sole. Anche l'eventuale montaggio di una ventola interna, a fianco della telecamera, può costituire una ulteriore salvaguardia per il dispositivo ottico. Nel caso di SOSO la telecamera è messa in funzione solo nelle ore notturne in quanto, se utilizzata di giorno, la telecamera specificatamente studiata per luci a bassa intensità, produce una immagine completamente "bruciata" anche con il diaframma dell'obiettivo completamente chiuso (lo spegnimento della telecamera costituisce una ulteriore protezione contro un eventuale innalzamento della temperatura interna durante giornate estive). D'inverno invece, considerando che le specifiche della telecamera garantiscono un funzionamento regolare fino a -20°C, le temperature  raggiunte alle nostre latitudini non costituiscono un problema serio, mentre nel caso di luoghi di installazione con temperature più rigide un piccolo riscaldatore interno, costituito da una resistenza, unitamente al calore generato dalla medesima, permetterà al sistema di stabilizzare la temperatura ad un valore ideale per il suo funzionamento. La vera insidia è invece costituita dalla pioggia.
Le custodie da me provate, alcune anche con IP 66, vista la posizione di montaggio quasi verticale (utilizzata per riprendere la volta celeste) non hanno, tranne in un caso, retto al "test della doccia". Collocate le telecamere all'interno del box-doccia, in posizione verticale con all'interno delle medesime dei fogli di giornale (per evidenziare a fine prova eventuali tracce di umidità) sono state poi sottoposte a condizioni estreme... Su tre diverse custodie testate, tutte di tipo professionale, solo una ha retto alla prova mostrando l'interno completamente asciutto e la carta priva di qualsiasi segno d'umidità. Le restanti custodie, dopo pochi minuti di esposizioni ad un flusso d'acqua battente si sono trasformate in un acquario. Pertanto quando acquistate una custodia, partite già con un grado di protezione 66 e quindi controllare che il corpo centrale sia un unico pezzo realizzato in pressofusione e non da parti diverse assemblate fra loro in quanto, anche se munite di guarnizioni, col passare del tempo e con gli sbalzi termici a cui è sottoposta, questa tende a crepare,  permettendo alla pioggia di infiltrarsi.
Il pannello frontale recante la finestra in vetro dovrà anch'esso essere accuratamente controllato per verificare che il vetro risulti perfettamente incollato al pannello stesso. In caso di incollaggio insufficiente o dubbio, si dovrà sanare il problema ricorrendo all'utilizzo di una colla apposita per poi verificate la tenuta del pannello sottoponendolo al "test della doccia". L'inconveniente descritto si presenta in quanto la custodia, nel nostro caso, viene montata verticalmente e non in posizione canonica orizzontale e quindi le vie di scolo per l'acqua risultano inefficaci con il tipo di montaggio da noi richiesto.

Il software - Prima di giungere all'attuale configurazione software, ho inizialmente fatto una ricerca, tramite internet, di eventuali programmi che potessero soddisfare le caratteristiche prefissate per la realizzazione dello strumento SOSO, orientandomi verso quei software che da tempo erano utilizzati dagli astrofili, cacciatori di bolidi e meteore, e quindi per l'osservazione automatizzata della volta celeste. Fra questi programmi ricordiamo Metrec (Meteor Recognizer) di Sirko Molau, funzionante sotto il sistema operativo DOS. Metrec non richiede un personal computer di ultima generazione e si raccomanda soltanto l'utilizzo di un Pentium con frequenza di clock superiore a 500 Mhz e almeno 128 MB di memoria ram. Si richiede però una scheda di acquisizione video Matrox Meteor/Meteor II, in quanto per la cattura e l'analisi video si basa sulle librerie MIL studiate appositamente per interfacciarsi a questo video-grabber. L'utilizzo di un hardware preciso e l'impossibilità da parte del software e, più in generale, del sistema operativo di far fronte alle altre caratteristiche che lo strumento deve possedere, mi hanno fatto desistere da questa scelta di utilizzo, fermo restando il convincimento che rimane un ottimo software per la cattura e l'analisi di eventi meteorici e straordinario per le sessioni osservative assistite da un operatore. In questi ultimissimi anni è apparso sulla scena Ufocapture realizzato da Sonataco, la società di un astrofilo/programmatore giapponese. Questo pacchetto software nato espressamente per la cattura e analisi di movimenti video di bolidi, meteore e TLE (Transient Luminous Event - SOSO, Wikipedia, NOA -) e operante sotto S.O. Windows sta riscuotendo un incredibile successo per le performance dimostrate. Dal nome assai evocativo, Ufocapture oltre alla cattura di immagini e video sequenze permette attraverso altri programmi un'accurata post-analisi per poter risalire all'identità dell'oggetto fautore dell'allarme. Anche questo programma pur essendo eccezionale e fornendo risultati incredibili (basta visitare i siti web della Sonataco e di suoi utilizzatori, per rendersene conto) non soddisfaceva a pieno le caratteristiche previste per SOSO. Il software infatti riesce a gestire una sola telecamera e se non è disponibile almeno un P IV a 3Ghz con più di 256 MB di RAM il funzionamento non è garantito. Il software Ufocapture, come il precedente, è stato concepito per funzionare quasi esclusivamente durante le relative sessioni osservative e non permette di automatizzare altre attività se non quelle strettamente necessarie a tali scopi. Inoltre, utilizzando sistemi operativi come XP e Windows 2000, assai avidi di risorse di sistema, risulta impensabile delegare ad altri pacchetti software quelle automazioni minime tali da rendere il sistema completamente autonomo e gestibile da remoto. Un dispendioso utilizzo delle risorse di sistema (non ha senso avere un sistema operativo grafico su un apparato che deve funzionare senza l'ausilio di un operatore), l'utilizzo di ulteriori programmi specifici per raggiungere un minimo di automazione e infine  l'impossibilità di realizzare tutte le specifiche previste per il progetto SOSO mi hanno fatto scartare anche questo software.

La soluzione Linux/Motion
Da molti anni sono un utilizzatore Linux, un sistema operativo la cui filosofia deriva direttamente da Unix (lo si potrebbe definire un "dialetto" di quest'ultimo). Nel tempo ho imparato ad apprezzarne le doti di robustezza, flessibilità e capacità di adattamento ad ogni tipo di lavoro e/o utilizzo. Il fatto che sia un sistema operativo open-source ha agevolato il suo sviluppo con successo (grazie al contributo di una comunità di sviluppatori capaci e numerosissimi): ricordo per inciso che molti software di orientamento tecnico/scientifico sono stati realizzati da università ed istituti di ricerca per i loro progetti ed in seguito rilasciati per il loro libero utilizzo). Nella vastità di software teoricamente disponibile per la piattaforma di SOSO sono andato alla ricerca di un programma che meglio supportasse il nostro strumento. Pur non esistendo programmi specificatamente dedicati (come ad es. quelli valutati in precedenza) ho trovato, nel settore del video motion/sorveglianza, l'ottimo Motion di Jeroen Vreeken & Kenneth Jahn Lavrsen. Inizialmente concepito per la video-sorveglianza si è poi sviluppato ed evoluto arricchendosi di numerose funzionalità, grazie al fatto che essendo open source (i sorgenti vengono liberamente rilasciati) alcuni utilizzatori, anch'essi programmatori, lo hanno col tempo migliorato, implementandolo di nuove funzioni e rendendolo capace di adattarsi alle applicazioni più disparate, e non ultimo il controllo della volta celeste. Comunque, prima di descrivere il programma e di addentrarci nella sua configurazione, vediamo come installare Linux su un personal computer dedicato a questo tipo di ricerca. Per chi fosse già pratico di Linux è inutile soffermarsi su queste pagine, mentre chi fino ad ora ha sempre e solo utilizzato Windows l'approccio a questo nuovo sistema operativo potrebbe riservare alcune difficoltà che però con un po' di calma potranno essere prontamente risolte. L'approccio migliore è quello di dedicare un personal computer specificatamente a questo lavoro, nel caso invece si volesse utilizzare il proprio personal computer con già installato Windows (XP, W2000), occorre creare una nuova partizione nella quale sarà installato Linux e quindi attivare un dual bootloader. In questa situazione consiglio la creazione di una ulteriore partizione, del tipo FAT32 estesa, nella quale verranno memorizzati le immagini jpg, png e i video catturati nelle sessioni osservative. Questa partizione permetterà di avere un'area di interscambio file   ed evitare che il SO di un tipo interagisca con la partizione dell'altro. In fase operativa, durante la seduta osservativa, Linux salverà i suoi dati in quest'area predisposta, mentre l'osservazione dei risultati e la post-elaborazione potrà essere eseguita attraverso Windows; questo almeno fintanto che non ci si sentirà a proprio agio nell'operare con Linux e farlo divenire la propria scelta definitiva. L’utilizzo di un file system (fs) di tipo FAT32 rappresenta la migliore soluzione per l'interscambio dei dati. Pensare ad un NTFS risulterebbe laborioso in quanto all'interno del mondo Windows vi sono delle piccole differenze fra un NTFS generato da XP o da  Win2000 ed ancora ulteriori differenze con quello generato da Vista. Linux supporta la lettura e la scrittura in NTFS, ma se si dovessero riscontrare dei problemi nell'utilizzo di questo fs occorrerebbero conoscenze non superficiali di questo SO per risolverli.
E' impensabile utilizzare uno dei vari file system adottati da Linux in quanto sarebbero illeggibili da parte di Windows, anche se ultimamente si sta lavorando con buoni risultati alla creazione di programmi che permettano la loro gestione. Pertanto la scelta consigliata resta la FAT32. Considerate che l'hard disk dovrà possedere una buona capacità; uno spazio di 20 Giga per ciascun S.O. e almeno 80 - 100 Giga per la partizione estesa FAT32 per la memorizzazioni dei filmati SOSO attualmente dispone di un HD da 250 Giga ripartito fra Windows XP (20 Giga, installato per eventuali prove ma mai utilizzato), Linux Debian Lenny (20 Giga) ed il restante come partizione estesa FAT32 per la memorizzazione dei video-allarmi e foto. Con poco più di 200 Giga, SOSO ha un'autonomia, nel caso non si scaricassero i dati quotidianamente, di circa 3 settimane. Questo dato è indicativo poiché varia a seconda delle impostazioni di motion:  livello di sensibilità dell'innesco allarmi,  parametri di codifica dei video (maggiore è la compressione e minore sarà lo spazio utilizzato). Infine, l'utilizzo di una partizione dedicata esclusivamente alla memorizzazione dei dati acquisiti dalla telecamera mette al riparo lo strumento da eventuali blocchi di funzionamento dovuti alla saturazione dello spazio su hard disk. In quest'ultimo caso si avrebbe il blocco delle registrazioni ma lo strumento sarebbe ancora gestibile da remoto in quanto la partizione dedicata al sistema operativo risulta diversa da quella di memorizzazione dei dati (e quindi integra).

Pertanto anche nel caso si utilizzasse un solo SO è caldamente consigliato usare una doppia partizione per non incappare in questo possibile inconveniente, specialmente se lo strumento è collocato in una località remota difficilmente raggiungibile. Per chi avesse quindi il personal computer con l'intera partizione dedicata a Windows è consigliabile partizionare il disco rigido in maniera da non mescolare i due sistemi operativi fra loro e con una partizione dedicata ai dati. Consiglio inoltre di eseguire un backup dei propri dati. Esistono vari tools reperibili in internet, con un buon grado di affidabilità, ed è utile ricordare che è sufficiente un solo istante per perdere mesi se non anni di lavoro e di dati accumulati sul disco rigido. Pertanto, dopo essersi procurati alcuni dvd riscrivibili, effettuate il backup dei dati, anche se non dell'intera partizione, e poi procedete al ridimensionamento della partizione utilizzata e alla creazione di 2 nuove. Personalmente consiglio un ottimo programma open source per questo tipo di lavoro: Parted Magic.  
Parted Magic è un programma completamente grafico, avviabile da CD, che permette di ridimensionare e creare nuove partizioni con  qualunque tipo di file system. Ci si collega al sito e si scarica l'immagine del CD (estensione ISO). Una volta masterizzata attraverso un qualsiasi programma di masterizzazione (ad esempio Nero per i possessori di Windows), si procede al riavvio del  pc, con inserito nel lettore CD/DVD di questo disco, controllando che da bios sia settata la possibilità di bootare, come prima scelta, da questa periferica. Parted Magic si installerà nella memoria RAM e vi farà vedere in formato grafico lo stato e le dimensioni del disco. Una volta appurate le caratteristiche (che dovreste peraltro già conoscere) ridurrete la quantità di memoria a disposizione di XP a 20 Giga.
Nota bene: personalmente ho utilizzato questa procedura solo con Windows98, Windows 2000 e XP senza mai riscontrare problemi o perdite di dati; però non ho mai effettuato tale operazione con Vista e non conosco le possibili reazioni di tale SO ad un ridimensionamento della sua area di lavoro. E' bene quindi che prima vi informiate, ricercando attraverso la rete internet eventuali forum in cui viene discussa tale operazione. Quindi creiamo una seconda partizione primaria (sono quelle dalle quali si può effettuare il boot di sistema) ed una ulteriore partizione, questa volta estesa, di tipo FAT32.
Come vedete non ho specificato che tipo di fs utilizzare per la partizione che ospiterà Linux in quanto a seconda della distribuzione utilizzata si impiegherà un tipo di fs rispetto ad altri sempre utilizzati con Linux. Come vedremo, utilizzeremo una distribuzione largamente diffusa per le sue doti di facilità d'impiego, con procedure automatizzate d'installazione e tools automatici di riconoscimento hardware che permetteranno a chi non conosce Linux di giungere a fine installazione senza problemi. Per una maggiore conoscenza delle potenzialità di Parted Magic consiglio la lettura del tutorial di approfondimento presente all'interno del sito di riferimento. Come distribuzione Linux, personalmente uso da molti anni Debian, flessibile, robusta e dotata di un parco software vastissimo, ma riconosco anche il fatto che un utilizzatore alle prime armi potrebbe incontrare notevoli difficoltà d'installazione, soprattutto se l'hardware presente nel personal computer non risultasse immediatamente riconosciuto durante l'installazione. Occorrerebbe allora mettere mano agli scripts di configurazione del sistema, operazione semplice solo per chi ha già acquisito una certa conoscenza di Linux.  
Consiglio
Ubuntu, una distribuzione derivata da Debian che nel mondo dell'open source riscuote da tempo un notevole successo in quanto sempre aggiornatissima a livello di software e con dei tools di configurazione automatica e riconoscimento hardware che rendono la vita estremamente semplice anche ai novizi di questo sistema operativo. Una volta collegati al sito, seguite le indicazioni e scaricate l'iso della distribuzione e, anche in questo caso come per Magic, masterizzate il CD, quindi inseritelo nel lettore e riavviate il personal computer, avendo cura di controllare che venga effettuato il boot da questa periferica. Vi verranno presentate alcune semplici domande alla fine delle quali si avvierà il processo di installazione del SO. Abbiate cura di selezionare la partizione primaria libera in cui effettuare l'installazione (l'altra partizione primaria contiene XP, mentre quella estesa conterrà i dati salvati durante le varie sessioni osservative). Importante: ricordatevi, durante l'installazione di Ubuntu, di impostare il nome e la password di almeno un utente altrimenti a fine installazione non riuscirete a loggarvi al sistema, in quanto per sua natura Linux è un SO multiutente e quindi il sistema vi porrà le fatidiche richieste di user e password. Al termine dell'installazione Ubuntu rivelerà la presenza di XP ed automaticamente installerà Grub o Lilo (software per la gestione dei multi-boot).
Prima di procedere con l'installazione di Motion e la relativa configurazione, consiglio vivamente di spendere un po' del proprio tempo nella lettura di alcuni tutorial e how-to inerenti a Linux e alla propria distribuzione appena installata. Questo per avere una maggiore dimestichezza con lo strumento con cui si opera e per il fatto che le spiegazioni fornite attraverso la presente mini guida non sono sicuramente esaustive e non possono coprire ogni aspetto dell'installazione e del funzionamento di un sistema operativo come quello di Ubuntu. Siamo finalmente arrivati all'installazione e configurazione del software che ha permesso la realizzazione di SOSO:
Motion .
Motion nasce come software di video sorveglianza dotato di motion detection; confrontando continuamente il frame appena catturato con quello precedente rileva eventuali differenze nella scena inquadrata. Se il numero di pixel variati supera la soglia precedentemente impostata allora si attivano diverse procedure, fra le quali il salvataggio del frame variato sotto forma di immagine jpg o ppm e la registrazione della sequenza video (mpeg4, msmpeg4, swf, flv, ffv1) con la possibilità di salvare n frame prima e dopo il termine dell'allarme (pre-cattura e post-cattura). Si possono inoltre avviare diverse procedure sia all'inizio dell'allarme che al rientro: procedure determinate dalle necessità dell'utente tramite l'esecuzione di scripts.
Gli scripts, nel mondo Linux, sono dei file di testo in cui vengono scritte sequenze di comandi di shell (simili ai comandi dos) che danno vita a dei veri e propri programmi con i quali è possibile fare un'infinità di operazioni (l'interfaccia grafica con la quale si gestisce e utilizza in generale un pc sotto Linux non fa altro che richiamare a basso livello comandi di shell). Col tempo Motion si è arricchito di molte funzionalità, quali la presenza di un mini web-server dove, puntando il proprio browser, è possibile: a) osservare le scene riprese in tempo reale dalla/e telecamera/e; b) avere la possibilità di comandare un pan/tilt via rs232 per l'inseguimento del target; c) la gestione via rete di database come mysql o postgresql in cui memorizzare per ogni allarme diversi parametri inerenti al target (data e ora di inizio e fine allarme, numero di pixel variati, etc..).
Queste ed altre opzioni sono facilmente selezionabili attraverso il relativo file di configurazione di motion (motion.conf) presente nella directory .motion all'interno della propria directory-home. Ricordo inoltre che motion non dispone di un'interfaccia grafica, ma solamente di un comando shell attraverso il quale si richiama un file di configurazione per il settaggio di tutti i parametri, dopo di che il funzionamento passa in daemon-mode fintanto che non lo si termina. Installiamo ora il programma motion e le relative dipendenze (altri pacchetti software di cui motion necessita per svolgere le sue attività) attraverso il gestore grafico di pacchetti Synaptic. Durante questa procedura il computer si collegherà attraverso internet a particolari siti definiti repository, in cui sono contenuti tutti i pacchetti software relativi a quella specifica distribuzione. Tramite il mouse di dovrà selezionare Applicazioni -> Strumenti di sistema -> Synaptic. Una volta avviato il programma di installazione attraverso la funzione cerca troverete e selezionerete Motion e, una volta confermata la sua installazione, il programma verrà scaricato ed automaticamente installato. Spostiamoci ora nella dir ~/.motion (la tilde rappresenta la nostra home directory) nella quale è presente il file di configurazione di motion (motion.conf). Lanciamo il nostro editor preferito Gedit, Kedit o Kwrite , nel caso si lavori con interfaccia grafica, oppure nano o vim da shell. Una volta avviato l’editor di testo iniziamo la modifica dei parametri. Come si può osservare ogni parametro è preceduto da una esaustiva spiegazione della funzione svolta e dei valori che può assumere rendendo il settaggio estremamente semplice e intuitivo. Nel caso vi fossero dei dubbi consultate la pagina web
http://www.lavrsen.dk/twiki/bin/view/Motion/MotionGuide, un'esaustiva fonte di informazioni per settare al meglio il software. Resta comunque inteso che la migliore messa a punto dei parametri è quella ottenuta sul campo, quando anche la vostra stazione osservativa si dovrà confrontare con una realtà piena di eventi indesiderati che innescheranno falsi allarmi (foschia, nuvole, scintillazione stellare, seeing non ottimale, pioggia, insetti, etc.). Riporto il file di configurazione motion.conf di SOSO perché possiate meglio rendervi conto di come è configurata la nostra stazione. Noterete molti parametri che attualmente non sono configurati in quanto non utilizzati ed altri settati a seconda della configurazione hardware posseduta.
Nel mondo Linux i dispositivi hardware hanno un file che li rappresenta; in questo caso l'ingresso della scheda di acquisizione (parametro videodevice) verrà identificata come /dev/video0,  dispositivo video 0 nella dir /dev. Se si utilizzano più telecamere si dovranno inserire più video grabber ed il sistema operativo creerà più dispositivi con numerazione consecutiva. In questo caso si utilizzeranno dei file supplementari denominati thread, dove in ciascun file specifico ad una determinata telecamera verranno inseriti i relativi parametri dedicati. Diverse schede dispongono inoltre di vari ingressi video (composito, s-video) ragion per cui bisogna indicare a motion quali di questi utilizzare (parametro input). Non lasciatevi spaventare da queste spiegazioni o dalla mole di parametri da settare; dopo alcune semplici prove, la realtà risulterà molto più facile di quanto può risultare ora. Uno dei parametri fondamentali per il tipo di lavoro che svolge SOSO è despeckle che permette di inserire un filtraggio flessibile e personalizzabile per eliminare gli effetti della scintillazione stellare e del rumore nell'immagine. Combinando sequenze di erosioni (e/E) e di dilatazioni (d/D) si riescono a ripulire i vari frames video dal noise e da impercettibili variazioni dei pixels che possono generare falsi inneschi. Dopo varie prove ho trovato un buon compromesso fra soppressione di falsi allarmi e capacità di rilevare piccole variazioni impostando il despeckle a edD. Suggerisco di eseguire un certo numero di prove per ottenere la filtratura migliore rispetto al tipo di hardware utilizzato (
http://emit.demon.co.uk/motion/). Una volta terminata la configurazione di motion.conf, basterà eseguire da shell il comando motion ed automaticamente si avvierà il programma di monitoraggio, portandosi in daemon mode. Nel caso di SOSO il comando è avviato tramite lo schedulatore, il quale gestisce anche altre attività vitali per il buon funzionamento dello strumento (chiusura sessione osservativa, trasferimento dei dati al server remoto, programmi di diagnostica per la verifica di SOSO).

Le schede di acquisizione - Prima di procedere oltre nella spiegazione, occorre spendere alcune parole sulle video grabber supportate dal SO
Linux e di conseguenza di quelle che si possono effettivamente utilizzare in accoppiata con Motion. Alcuni produttori di hardware rilasciano i drive di supporto esclusivamente per i sistemi Windows e in alcuni casi non rilasciano nemmeno le specifiche per permettere alla community dei sviluppatori software legati a Linux di realizzare i moduli di supporto per quel determinato tipo scheda. Per fortuna la situazione tende a migliorare con l'aumentare degli utilizzatori dei sistemi operativi open source, ma suggerisco comunque, prima di procedere all'acquisto della video grabber di verificare sul sito di riferimento v4l (video for Linux, http://linuxtv.org/v4lwiki/index.php/Main_Page) la lista dell'hardware compatibile.
Le comunicazioni Arrivati a questo punto il sistema SOSO è già pronto ad entrare in funzione almeno nella situazione di utilizzo locale, ossia quando  l’utilizzatore ha la possibilità di accedere direttamente al personal computer.  Nel caso in cui lo strumento debba essere utilizzato e gestito da remoto ci troviamo allora a metà dell'impresa poiché dovremo ricorrere ad altri strumenti messi a disposizione dal nostro sistema operativo per poter gestire da remoto e automatizzare ogni operazione di scarico dati ottenuti dal nostro dispositivo. A questo punto siamo comunque in grado di rendere disponibile agli interessati, attraverso internet, lo scorrere delle immagini riprese dalla telecamera, in tempo reale. Se il sistema è connesso direttamente ad un modem/router ADSL senza problemi di firewall, possiamo utilizzare il mini server web messo a disposizione dal pacchetto Motion. Una volta programmati i pochi parametri inerenti al web server all'interno di motion.conf, chiunque puntando il proprio browser verso l'indirizzo e la porta specificata potrà osservare ciò che viene ripreso in quel momento dalla telecamera. Consiglio, per non appesantire il lavoro del personal computer che gestisce Motion, di limitare l'aggiornamento delle immagini via web ad 1 frame al secondo e di mantenerlo invariato anche in presenza di allarme (il software permetterebbe di aumentare in questo frangente il frame/rate fruibile via web). Nel caso si voglia rendere fruibile il web server all'intera comunità internet,  e non si disponga di un proprio dominio sul quale essere raggiunti, bisognerà ricorrere all'utilizzo di un dns dinamico. Questo servizio, disponibile gratuitamente per i privati o per chi lo utilizza senza finalità commerciali, permette di tenere traccia del vostro ip che dinamicamente muta ogni volta che vi collegate ad internet e quindi associare ad esso un indirizzo url attraverso il quale essere sempre raggiungibili via rete (http://it.wikipedia.org/wiki/Dynamic_DNS). Questo servizio viene fornito gratuitamente da diverse società previa una semplice registrazione attraverso cui si sceglierà user e password di riconoscimento e si sceglierà anche il nome del dominio con cui si sarà sempre raggiungibili. Per poter usufruire del servizio bisogna installare nel proprio personal computer un client che all'atto della connessione in internet, aggiornerà immediatamente il server del DNS dinamico del lip posseduto, in modo che chiunque possa essere indirizzato verso di voi.
Un client per Linux è ddclient presente in tutte le distribuzioni Linux, Ubuntu compresa. Altrimenti questo aggiornamento può essere eseguito attraverso il modem/router ADSL se dispone di questa funzionalità. Ricordatevi inoltre di aprire le porte del vostro router/firewall alle richieste di connessione provenienti dal mondo esterno, altrimenti chi vi contatta non potrà collegarsi al vostro mini web-server. Nel caso in cui, come è accaduto per SOSO, il personal computer sia configurato all'interno di una rete lan con politiche di sicurezza estremamente restrittive, per evitare intrusioni dalla rete esterna (quindi un firewall che blocca ogni tipo di traffico entrante), opereremo in altro modo. Il server http gestito da Motion sarà allora disattivato ed abiliteremo la funzione di snapshot, presente in motion.conf, indicando la cadenza di salvataggio dell'immagine jpeg di una al secondo. L'immagine salvata verrà poi ciclicamente trasferita tramite procedura ftp verso il server che ospiterà l'eventuale vostro sito web, nel quale allestirete una pagina live di ciò che la telecamera sta riprendendo in quel momento. L'avvio di questo trasferimento ciclico avviene attraverso l'ausilio di uno script da eseguire in concomitanza con l'avvio di Motion e da interrompere unitamente  alla fine della sessione osservativa. Il comando risulta lftp -f /percorso_file/online, avviato tramite lo schedulatore  di Linux crontab. Come potete verificare dalle pagine di spiegazioni a corredo, il comando lftp risulta essere un sofisticato programma di trasferimento file con decine di opzioni attraverso le quali si riescono a realizzare le azioni più sofisticate che ci prefiggeremo di svolgere (si possono consultare le funzionalità di lftp da shell richiamando le pagine di man col comando : man lftp). La pagina web che mostrerà l'immagine live conterrà una funzione che richiamerà, con la cadenza di una volta al secondo, l'immagine precedentemente trasferita (la si può comunque personalizzare a seconda delle proprie esigenze).Come precedentemente accennato, l'automazione delle varie attività del nostro strumento sono affidate allo schedulatore di sistema crontab. Questo comando permette da shell di schedulare ogni attivita' del sistema e di automatizzare ogni operazione ad orari prestabiliti rendendo superfluo l'intervento dell'operatore. Crontab ci permette inoltre di vedere o modificare le attività programmate nel personal computer. Qui di seguito mostro la foto della shell di SOSO con le attività svolte da
crontab.

Crontab, seguito dal parametro -l, visualizza le varie attività schedulate dall'operatore sul personal computer. Nel caso specifico di SOSO quello che vedete sono le esecuzioni di comandi che di script (lista di vari comandi concatenati fra loro inseriti in un file di testo) schedulati dal sottoscritto per automatizzare quasi tutte le funzioni di cui lo strumento necessita. Dico quasi tutte perché alcune altre funzioni (come la sincronizzazione dell'orologio di sistema attraverso la rete ad un server ntp) sono schedulate come amministratore di sistema e quindi non appaiono nella lista delle attività programmate come user soso (ricordo ancora che Linux è un sistema multiutente e solo l'amministratore di sistema ha la possibilità di eseguire comandi che possono influenzare globalmente il sistema, mentre gli user, o utilizzatori normali, possono eseguire comandi e funzioni che agiscono solo localmente sui propri dati e directory). Per comprendere meglio le varie attività schedulate attraverso crontab vediamo quali sono le attività svolte dal nostro strumento e attraverso quali comandi (o script) le realizziamo (gli orari che indichiamo qui di seguito sono in UTC). Un'ultima considerazione riguardo agli orari: le osservazioni vengono compiute indicativamente dal tramonto all'alba, quando l'oscurità permette una migliore individuazione e osservazione dei fenomeni FLTA, pertanto gli orari mostrati ora sono quelli utilizzati al momento della stesura di questa mini guida e cioè relativi al periodo invernale. Alle 17:59, un minuto prima dell'avvio di Motion viene accesa la telecamera. Questo dà il tempo necessario alla telecamera dopo l'accensione per stabilizzare l'uscita video e regolare il diaframma dell'obiettivo evitando così falsi allarmi dovuti ai primi istanti di funzionamento dell'apparato video (in seguito spiegherò come accendere un qualsiasi apparato elettronico attraverso l'utilizzo della porta parallela del personal computer e del programma parashell). Alle 18:00 viene avviato lo script start.sh che si incarica di abortire tutti i trasferimenti di file in atto avviati alla fine della sessione osservativa precedente, di avviare Motion e di trasferire le snapshot riprese con cadenza di una al secondo verso il sito esterno che mostra le immagini live (http://www.ciph-soso.net/live/soso.shtml). Dalle 19:00 fino alle 05:00, ogni 15 minuti viene lanciato lo script monitor.sh che verifica il funzionamento di Motion. Nel caso il programma non risulti presente fra i processi del sistema lo riattiva. Lo script deriva da una utility scaricata dal sito di Motion e realizzata quando ancora Motion non creava il file di pid (identificativo di processo) per la verifica diretta. Per cui chi vuole può sostituire questa procedura con una nuova che verifichi la presenza del pid.Alle 05:30 del mattino viene eseguito lo script stop.sh che pone termine alla sessione osservativa, spegne la telecamera e termina il trasferimento delle immagini snapshot verso il sito web di riferimento.
Terminate le attività notturne viene avviato l'upload del materiale registrato durante la nottata verso un server ftp esterno (ricordo che SOSO è posto dietro ad un firewall che impedisce di raggiungerlo dal mondo esterno e quindi non è stato possibile implementare internamente un server ftp). Quest'attività di upload viene avviata sempre da stop.sh che richiama a sua volta lo script trasferisci.sh. La presente attività procede fino al completo trasferimento dei file o termina quando parte l'attività osservativa serale successiva, che pone fine al trasferimento dei file per non sprecare inutilmente risorse di sistema ed occupazione di banda. I file non trasferiti non verranno cancellati, ma saranno eventualmente trasferiti il giorno seguente. La capacità di smaltimento dei file registrati dipende da vari fattori quali: a) il numero di eventi registrati e la loro durata; b) la larghezza di banda disponibile per i download, il  frame/rate impostato per la codifica dei video; c) non ultime, le condizioni meteo. Eventuali piogge con relative gocce d'acqua sul vetro della custodia genereranno allarmi continui ed un conseguente aumento delle registrazioni. Apriamo una piccola parentesi sulle modalità di attivazione della/e  telecamera/e e di eventuali altri strumenti connessi alla nostra postazione osservativa. Fin dalle prime sessioni osservative abbiamo considerato poco logico lasciare la telecamera perennemente alimentata, sia per evitare che la telecamera (assai costosa) si usuri inutilmente senza essere di nessuna utilità nelle ore diurne, sia perché nel periodo estivo esposta perennemente ai raggi solari si possono raggiungere temperature interne alla custodia tali da guastare o ridurre notevolmente il tempo di vita di quello che consideriamo il cuore di questo nostro sistema. Inizialmente si è utilizzato un timer esterno del tipo di quelli utilizzati per attivare ad orari prestabiliti dispositivi e luci. Poi ci si è resi conto della mancanza di flessibilità di un tale sistema: ad esempio l'essere legati ad una programmazione oraria rigida e al doversi recare in loco per modificarla, senza contare che l'orario del timer non poteva essere sincronizzato attraverso un server ntp o tramite un dispositivo GPS. Sempre attraverso la shell è possibile comandare singolarmente la variazione dello stato logico dei pin di output (D0 D7) della porta parallela. Pertanto ,realizzando un semplice circuito elettronico (fig. 1), è possibile comandare da personal computer l'accensione o lo spegnimento di uno o più carichi. Diversi sono gli schemi reperibili attraverso la rete e tutti si compongo di una sezione opto-isolante che permette di separare l'elettronica di potenza, che comanda il carico, dall'elettronica della porta parallela e quindi dall'intero personal computer. All'uscita del dispositivo optoelettronico è presente un transistor che comanda un relè collegato all'alimentazione della telecamera. Una volta realizzato il semplice circuito e prelevando il segnale di comando dal pin 2 (D0) della porta parallela questo sarà gestito attraverso il comando parashell (
http://parashell.sourceforge.net/) che ci permetterà di impostare a 1 (+5V) oppure a 0 (0V) il pin selezionato. Attraverso il comando pin, facente parte del medesimo tool, possiamo leggere le uscite precedentemente impostate.
 


fig.1 Semplice circuito elettronico da collegare alla porta parallela per comandare l'accensione della telecamera. Il circuito può essere replicato per ogni pin d'uscita della parallela (D0 a D7) potendo comandare con questa configurazione un massimo di 8 carichi. Per alimentarlo si può utilizzare un alimentatore esterno da 12 15 Volt recuperato da un modem non più utilizzato. Per aumentare la sicurezza si consiglia di lasciare separata la massa proveniente dal personal computer (porta parallela) da quella del circuito.



Giunti a questo punto non ci rimane che implementare un sistema di connessione sicura per amministrare da remoto il nostro strumento. Attraverso la gestione remota possiamo eseguire l'upgrade software, modificare gli orari dello schedulatore, o intervenire in qualsivoglia attività che implichi un nostro intervento diretto su tale apparecchiatura. Il software che permette di eseguire queste operazioni è OpenSSH , una suite di comandi shell che permettono di collegarsi ad un computer remoto attraverso un tunnel criptato e di ottenere da questi una consolle attraverso la quale amministrare il sistema come se si fosse fisicamente in loco. OpenSSH crea un tunnel blindato attraverso l'adozione di protocolli e chiavi di criptatura che proteggono il traffico da possibili intercettazioni. Ciò permette di attraversare la rete in tutta sicurezza e permette, nella massima flessibilità possibile, l'utilizzo di algoritmi come RSA, 3DES, Blowfish, DSA , DH, HMAC. Attraverso l'utilizzo del comando SSH, non solo possiamo sostituire efficacemente l'oramai obsoleto e poco sicuro telnet (poco sicuro in quanto tutto il traffico compresa l'autentificazione tramite user e password risultano in chiaro), ma possiamo attraverso l'utilizzo di un sofisticato sistema di chiavi asimmetriche (chiavi pubbliche e private), realizzare una autentificazione automatica con il personal computer remoto tralasciando l'utilizzo della password. Inoltre è possibile  eseguire in locale applicazioni grafiche lanciate sul personal computer remoto da amministrare, realizzando una sorta di VNC con il  beneficio che tutte le comunicazioni risulteranno criptate a prova di intrusione.
Installiamo OpenSSH attraverso i comandi visti precedentemente (apt-get oppure synaptic in modalità grafica) sia sul personal computer da amministrare in remoto che in quello locale dal quale opereremo. Prima di procedere nella configurazione del server SSH e del relativo client dobbiamo conoscere che tipo di politiche di sicurezza adotta il router/firewall dietro al quale è collocato il nostro strumento SOSO. Se il router/firewall permette a SOSO di essere contattato dal mondo Internet (quindi accetta le chiamate in ingresso) allora configureremo e avvieremo il server SSH sul pc che gestisce SOSO (lato remoto), mentre l'amministratore o chi è incaricato di verificare il funzionamento dello strumento dal proprio personal computer (lato locale) avvierà il client SSH. Se le politiche di sicurezza della rete lan in cui lo strumento è inserito risultano restrittive e permettono esclusivamente un traffico uscente verso internet, e non in entrambe le direzioni (come e' avvenuto nella realta per SOSO), allora la questione si complica leggermente, dato che non potremmo contattare direttamente il nostro apparato remoto e dovremo ricorrere al sistema del reverse tunneling SSH e all'attivazione di quest'ultimo attraverso un programma  di messaggistica istantanea (Instant Messaging, IM, basato su Pidgim, ex Gaim) ed uno script in Perl realizzato da Michael Schilli. Complicato? No, più difficile a dirsi che a farsi... Iniziamo con il caso più semplice, nel quale il nostro strumento è collegato alla rete internet attraverso un modem/router la cui configurazione permette di ricevere delle chiamate dal mondo esterno e, nel nostro caso, indirizzarle verso un server SSH. Ricordo che nel caso il collegamento ad Internet fosse realizzato attraverso l'utilizzo di una linea ADSL con ip dinamico, si ricorrera all'ausilio del DNS dinamico per poter essere sempre rintracciabili in rete, come illustrato precedentemente. In questa caso il personal computer di SOSO è il remoto e su questo andiamo ad installare il pacchetto software SSH server. Una volta completata l'installazione, prima di avviare il servizio ssh server, dobbiamo spostarci della directory  /etc/ssh/ e verificare se all'atto dell'installazione del programma sono state generate le chiavi di criptazione asimmetriche (pubblica e privata) rilevando la presenza dei file ssh_host_rsa_key e ssh_host_dsa_key e le relative chiavi pubbliche con estensione .pub. Nel caso così non fosse, attraverso il comando shell ssh-keygen eseguito con i privilegi di root, generiamo le chiavi pubbliche e private per gli algoritmi RSA e DSA:
 

ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N

ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N 

Fatta questa operazione mettiamo mano al file di configurazione del server sshd_config contenuto nella medesima directory. Normalmente questo presenta una configurazione di massima che rende il server già pronto ad essere usato sin da subito, ma suggerisco comunque di riguardarlo e di apportare alcune semplici modifiche per migliorarne la sicurezza. Qui di seguito riporto il contenuto del file sshd_config con i miei commenti in giallo. Nota bene che le righe (commenti e opzioni) che iniziano con # non vengono considerate dall'eseguibile.

# What ports, IPs and protocols we listen forPort 22  di default la porta 22 è associata al servizio SSH, consiglio di cambiarla con un altro valore non utilizzato da eventuali altri servizi per migliorare la sicurezza

#GatewayPorts no
#AllowTcpForwarding no
#Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 192.168.1.1
Protocol 2
indica al server di usare solo i protocolli di tipo 2 più sicuri
# HostKeys for protocol version 2 indica al server i file contenenti le chiavi private di crittazione rsa e dsa
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes
# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600 
tempo di rigenerazione chiavi di crittazione
ServerKeyBits 1024 
lunghezza in bit delle chiavi generate dal server
# Logging
SyslogFacility AUTH
LogLevel INFO
#Authentication:LoginGraceTime 120
PermitRootLogin no 
impedisce di loggarsi come root
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile    %h/.ssh/authorized_keys
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes
# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no
impedisce l'utilizzo di password vuote
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)ChallengeResponseAuthentication no
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication yes
# Kerberos options#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
# GSSAPI options
#GSSAPIAuthentication no

#GSSAPICleanupCredentials yesX11Forwarding yes permette al client di lanciare applicazioni grafiche
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes 
mantiene attiva la connessione anche quando non si inoltrano comandi
#UseLogin no#MaxStartups 10:30:60
#Banner /etc/issue.net
# Allow client to pass locale environment variables
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM yes

Una volta terminata la modifica del file di configurazione del server SSH possiamo rendere le modifiche immediatamente operative re-startando il servizio SSH attraverso il comando:

/etc/init.d/ssh restart

nel caso il servizio fosse già avviato. Se utilizzate una distribuzione diversa da Debian o Ubuntu, che in fase di installazione del server SSH non configura il sistema per l'avvio automatico di questo servizio, bisogna modificare manualmente la directory corrispondente al runlevel utilizzato inserendovi il link verso il servizio SSH presente nella dir   /etc/init. Nel computer domestico, che utilizzeremo per collegarci alla stazione remota (SOSO), dobbiamo installare il client SSH, attraverso il solito metodo visto precedentemente anche se la maggior parte delle distribuzioni Linux includono già di default il client SSH (considero scontato che anche nel personal computer di uso quotidiano vi sia presente un sistema operativo Linux). Il file di configurazione del client SSH_config presente nella directory /etc/ssh/  può essere trascurato in quanto i parametri necessari al funzionamento verranno passati attraverso la shell e sovrascriveranno quelli non settati presenti nel file di configurazione. A questo punto basterà lanciare da shell il comando:

ssh -X -p porta_server_ssh -l utente remoto indirizzo ip o url del server

Il parametro X ci permette di ricevere sessioni grafiche remote; con porta_server_ssh indichiamo su quale porta del personal computer remoto (il nostro SOSO) è in ascolto il server: con utente remoto indichiamo l'user con cui ci andremo a collegare ed infine forniremo l'indirizzo ip o l'url dove rintracciare il nostro pc-strumento. Come ricordato precedentemente, nel caso non disponessimo di un indirizzo ip nostro, ma solamente di uno dinamico, ricorreremo al servizio gratuito di dns dinamico per tenere traccia in rete dell'indirizzo ip verso il quale collegarci. Una volta raggiunto il server SSH, se è la prima volta che ci logghiamo, ci chiederà di accettare le chiavi di criptazione, e uno volta risposto affermativamente ci chiederà la password di autentificazione. Fornita la password relativa all'user con la quale ci autentifichiamo (che è poi la user e password che forniamo quando lavoriamo in locale sullo strumento/pc SOSO) ci apparirà sul desktop domestico la shell remota del nostro strumento e da questa possiamo inoltrare i nostri comandi con i quali amministrare il sistema. Nel caso dovessimo inoltrare comandi con privilegi da root useremo il comando su per cambiare identità. Una volta concluso il lavoro la sessione remota verrà terminata tramite il comando exit.

Per il mondo windows è stato sviluppato un client libero che permette di collegarsi a server remoti SSH attraverso l'applicativo PuTTY. Personalmente non l'ho mai utilizzato ma, sicuramente, una volta configurati i parametri del programma come indicato nel sito di riferimento la sessione di lavoro si svolgerà come se si trattasse del client Linux visto precedentemente. Passiamo ora ad illustrare un collegamento ad uno strumento SOSO posto dietro ad un firewall che non permette l'accesso a delle chiamate dal mondo internet, la qual cosa ci complica leggermente il lavoro! In questa situazione il server SSH del nostro strumento non sarà mai raggiunto da un qualsiasi client SSH in quanto il router/firewall impedirebbe l'accesso dal mondo esterno verso il personal computer. A questa condizione si è posto rimedio attraverso la tecnica di reverse tunneling. Come abbiamo visto in precedenza quando un client SSH si collega, dopo essersi autentificato al server remoto,  riceve come servizio la possibilità di inoltrare comandi che verranno eseguiti sul personal computer remoto (per intenderci quello in cui gira l'applicativo server): quindi il lato client utilizza una shell del remoto. Nel reverse tunneling, il client SSH reverse non riceverà la consolle o shell comandi dal server bensì fornirà la propria shell ad altri client che la utilizzeranno attraverso il server SSH che svolge le funzioni di ponte. Quindi nel personal computer di SOSO verrà lanciato un client SSH reverse che si collegherà ad un server SSH esterno (in questo modo il router/firewall non impedirà il collegamento in quanto risulta uscente). Allo stesso tempo, chi si deve collegare a  SOSO  avvierà una sessione SSH normale verso il server SSH indicando a quest'ultimo di volere essere messo in collegamento con il client proveniente dallo strumento: il gioco è fatto. In questa modalità di funzionamento, che è poi quella reale in cui opera SOSO, il server SSH è installato nel mio desktop domestico collegato a internet attraverso un ADSL a 20 Mbit la quale è sempre rintracciabile avendo attivato un servizio di Dynamic DNS (così oltre ad avere tutte le comunicazioni criptate ho anche il controllo sul server). Dal personal computer remoto, sede di SOSO, viene avviato un client SSH con le seguenti opzioni:

ssh -R porta_pc_di_casa:localhost:22 -p 22 -l user_abilitato_nel_pc_di_casa url_dinamico_pc_di_casa -f -N

-R indica che la porta domestica, ad esempio la 10000, deve essere forwardata sulla porta in ascolto di SOSO (in questo caso la porta standard 22).
-p 22 indica su che porta è in ascolto il server SSH-
l user indica il nome dell'utente attivo nel pc di casa
url dinamico che indirizza verso l'ip assegnato al collegamento internet di casa
-f  fa funzionare in background il client SSH
-N parametro utile per il forward delle porte con il protocollo di tipo 2 (più sicuro)

ssh -R 10000:127.0.0.1:22 -p 22 -l massimo www.pc_di_casa.org -f -N

Una volta lanciato questo comando da SOSO verrà richiesta la password con la quale l'utente massimo si autentifica sul proprio personal computer domestico e, una volta instaurato il collegamento, SOSO resta in attesa di un collegamento dalla parte di un altro client SSH verso cui inoltrare la propria shell di comandi.

Dal personal computer domestico lanceremo il client SSH con i seguenti parametri:

ssh -X -p porta_scelta_per_inoltrare_sul_pc_di_casa_la_shell_del_pc_remoto     -l utente_pc_soso

127.0.0.1127.0.0.1 rappresenta l'indirizzo ip virtuale interno al nostro personal computer, in cui risiede sia il server SSH che il client e che corrisponde a localhost; il comando quindi risulterà

ssh -X -p 10000 -l remoto 127.0.0.1

Una volta avviato questo comando SSH verrà richiesta la password relativa all'utente remoto presente sul personal computer di SOSO e a questo punto avremo a disposizione la shell di comandi domestica riferita al personal computer remoto. Ricordatevi di configurare i file sshd_config e ssh_config in maniera che la porta di ascolto del server e di inoltro del client coincidano. Di prassi il servizio SSH funziona sulla porta 22, ma nulla vieta (anzi è buona norma) di modificare tale valore scegliendone un'altra libera, per incrementare la sicurezza. A questo punto sembrerebbe tutto concluso se non fosse che vi sono due piccoli problemi da risolvere riguardo quest'ultima procedura che ho appena mostrato. Prima di tutto bisogna trovare il sistema di avviare un collegamento con lo strumento remoto ogni qualvolta ve ne sia la necessità. Quindi non è pensabile affidare allo schedulatore crontab l'incarico di avviare il reverse tunneling nello strumento dietro al firewall, in quanto il collegamento dovrebbe avvenire quando vi è una reale necessità e non a orari prefissati della giornata, magari dovendo attendere diverse ore prima di instaurare l'atteso collegamento. Inoltre, ogni volta che viene avviato da remoto un collegamento SSH, bisogna fornire la password per validare il collegamento e quindi bisogna realizzare una procedura che automatizzi l'autentificazione. Partiamo risolvendo la questione dell'autentificazione automatica del collegamento SSH. Esiste una procedura semplice e nel contempo sicura ed affidabile per collegarsi attraverso un tunnel SSH senza dover fornire alcuna password di autentificazione ed affidandosi all'utilizzo di una coppia di chiavi (pubblica e privata). La procedura di autentificazione è demandata all'utilizzo di chiavi SSH e viene rimossa la richiesta di password (tra l'altro se l'accesso al personal computer remoto (SOSO) viene eseguita da un computer in qualche modo visibile ad altri, meno volte si digita la password e minore è la possibilità che qualcuno possa carpirla). La procedura dovrà essere eseguita sia sul personal computer di SOSO che nel computer domestico. Tramite shell (può sembrare strano quante cose si possono fare attraverso la riga di comando!) nel personal computer domestico generiamo la coppia di chiavi SSH con le quali (pubblica e privata) permettere al personal computer remoto (SOSO) di collegarsi senza l'utilizzo della password:

ssh-keygen -t dsa -b 1024

-t indica il tipo di chiave da generare tra rsa1 (versione 1 sconsigliata) e rsa o dsa per la versione 2
-b lunghezza della chiave

Durante la generazione delle chiavi verrà richiesta una passphrase che verrà lasciata vuota. Da un punto di vista della sicurezza sarebbe un problema in caso di furto della chiave, ma dal punto di vista pratico permette l'accesso alla macchina remota senza la richiesta di una password. Anche senza passphrase le comunicazioni attraverso la rete risultano sempre criptate. Durante la generazione delle chiavi verrà chiesto di salvarle nella directory di default che risulta essere /home/directory_home/.ssh/ (dove directory_home avrà il nome dell'user utilizzato). In questa dir troveremo oltre ai file contenenti le chiavi (id_dsa file contenete la chiave privata e id_dsa.pub contenete quella pubblica) anche i file  authorized_keys e known_hosts. A questo punto copiamo la chiave pubblica (il contenuto di id_dsa.pub) nel file  authorized_keys del personal computer-strumento SOSO.
Ora nel personal computer-strumento SOSO generiamo le chiavi SSH, con il comando visto precedentemente, e copiamo la chiave pubblica di SOSO nel file  authorized_keys del nostro personal computer domestico.In ultimo modifichiamo il file di configurazione del server SSH nel pc di casa e settando la direttiva PubkeyAuthentication alla voce yes. Passiamo ora ad illustrare il sistema da me adottato per far eseguire nel momento di necessità il client SSH reverse precedentemente discusso. Inizialmente avevo pensato ad un sistema di attivazione basato su comandi inoltrati attraverso una mail al sistema SOSO, ma questo metodo non offriva sufficiente garanzia di immediatezza nel recapito del messaggio contenente il comando di attivazione.

Poi, casualmente, mi sono imbattuto in un interessante articolo, a firma Michael Schilli, apparso sulla rivista in lingua inglese Linux Magazine (www.linux-magazine.com/issue/50/Perl_Building_a_Jabber_Bot.pdf) in cui veniva spiegato come,  attraverso un servizio di messaggistica istantanea basata su server Jabber, si poteva contattare un personal computer remoto  sul quale era attivo uno script Perl, con il quale eseguire in tempo reale dei comandi impartitegli da remoto.Il programma, un vero agent- robot, ha la capacità di riconoscere l’identità di chi gli invia i comandi e quindi di eseguire solo quelle direttive provenienti da persone autorizzate. Tralasciando la parte hardware dell’articolo che esula dai nostri scopi (l’articolo era rivolto a chi si interessa di domotica) lo script in Perl (agent.pl) era proprio il software che faceva al caso nostro, previa una piccola modifica inerente ai comandi da eseguire. Ma vediamo in dettaglio come si svolge questa attivazione in quanto le spiegazioni fino ad ora fornite potrebbero risultare un po’ complicate. Esistono in rete un'infinità di servizi di messaggistica istantanea come MSN Messenger, AIM, ICQ, Yahoo, Jabber, etc; che offrono la possibilità a due o più persone di chattare, scambiarsi file e messaggi in tempo reale. Michael Schilli, appoggiandosi ad un server Jabber, realizza un programma in Perl che identifica chi gli invia un messaggio contenente un comando e, se il mittente è autorizzato, esegue il comando ricevuto. Nel caso invece che un messaggio arrivi da uno sconosciuto il programma si limita a scartarlo senza rispondere. La capacità di riconoscere il mittente amico è data dal fatto che agent-robot si interfaccia alla buddy list o lista di amici del client per messaggistica istantanea Gaim (recentemente il progetto ha cambiato nome ed è divenuto Pidgin). Nel nostro caso avvierà un tunnel SSH reverse verso il server SSH (avviato sul mio personal computer domestico) e io metterò in funzione a mia volta un collegamento SSH che mi permetterà di ricevere comodamente la shell di comandi di SOSO sul mio personal computer...Vediamo ora i semplici passi da attuare per realizzare quest'ultima configurazione. Sia con SOSO che con il personal computer domestico dal quale lo gestiremo, avviamo per la prima volta Pidgin. Ci verrà richiesto di configurare in nostro account di messaggistica istantanea con il quale saremo sempre identificati e contattati in Internet. Come detto precedentemente, per questo servizio utilizzeremo Jabber e quindi selezioneremo nella lista di protocolli possibili proprio quest’ultimo. Una volta configurato su entrambi i personal computer il relativo account eseguiamo il primo collegamento fra i due personal. Questo passo è necessario in quanto, all’avvio del primo collegamento, il client ricevente la chiamata fornirà l'autorizzazione valida anche in futuro per essere raggiunto da questo contatto, inserendolo nella lista degli amici, la famosa buddy list, che poi verrà sfruttata anche dallagent-robot per identificare i messaggi provenienti dagli amici. Si consiglia di fare questa operazione con i due personal computer vicini in modo da facilitarne lo svolgimento. Fatto ciò, sul personal computer che gestisce SOSO chiudiamo Pidgin in quanto questo programma ci è servito per configurare l’account con cui raggiungere il computer ed a creare la buddy list dei manutentori del sistema. Dall'articolo citato in precedenza copiamo lo script Perl agent.pl e creiamo un file di testo con estensione pl (perl). Lo script così ottenuto deve essere modificato per poter avviare i comandi utili alla gestione remota di SOSO.  La parte che ho variato è quella relativa alla parte finale dello script incaricato di identificare i comandi inviati e di farli eseguire. Riporto le righe di codice estrapolate dal programma di M. Schilli (dalla riga 98 alla 123) e di seguito le modifiche da me introdotte (le righe in blu sono mie note di spiegazione):

092 #############################
093 sub run_cmd {
094 #############################
095 my ($cmd) = @_;
096
097 # Find out external IP
098 if ( $cmd eq "ip" ) {
099 return LWP::Simple::get(
100 "
http://perlmeister" .
101 ".com/cgi/whatsmyip"
102 );
103 }
104
105 # Print Load    
<--  Commento di spiegazione al comando
106 if ( $cmd eq "load" ) {    
<-- Istruzione if di selezione comando
107 return `/usr/bin/uptime`;  
<-- Comando inoltrato alla consolle locale da agent.pl
108 }
109
110 # Switch bedroom light on/off
111 if ( $cmd =~
112 /^lamp\s+(on|off)$/ )
113 {
114 my $rc =
115 system(
116 "/usr/bin/lamp $1");
117 return $rc == 0
118 ? "ok"
119 : "not ok ($rc)";
120 }
121
122 return "Unknown Command";   
<-- Risposta inoltra a ritroso sul client di messaggistica istantanea nel caso
123 }                                                  <-- il comando inoltrato non è fra quelli previsti

Codice variato:

########################################### 
sub run_cmd {
########################################### 
my($cmd) = @_;  
# lista comandi   if($cmd eq "comandi") {   
<-- Esegue la lista degli script eseguibili presenti nella dir     
return `ls /home/soso/telecontrollo/`;            
<-- telecontrollo  
}

# Print Load  
if($cmd eq "load") {                                   
<-- Indica da quanto tempo il sistema è up     
return `/usr/bin/uptime`;  
}  

# avvia tunnel ssh reverse  
if($cmd eq "ssh") {                                      
<-- Avvia un tunnel SSH Reverse    
return `ssh -R 12000:127.0.0.1:11000 -p 11000 -l utente mio_indirizzo.org -f -N`;  

return "Unknown Command";

Terminata la parte relativa ai comandi occorre modificare la parte di script inerente all’invio della user e password di accesso ed autentificazione sul server Jabber in maniera da avere SOSO online per la ricezione dei comandi:

023 my $JABBER_USER =
024 'user';                                                    
<-- User di accesso al servizio Jabber
025 my $JABBER_PASSWD = "password";  <-- Password
026 my $JABBER_SERVER =
027 "jabber.org";                                 
<-- Indirizzo del server Jabber su cui abbiamo abilitato il nostro account
028 my $JABBER_PORT = 5222;      
<-- Porta su cui abilitiamo il servizio Jabber

Salviamo le modifiche e rendiamo eseguibile lo script appena realizzato attraverso il comando shell:

chmod ugo+x agent.pl

e infine copiamo il file nella directory /usr/bin .
Fatto ciò ricordiamoci di abilitare l’eventuale router al traffico sulla porta prescelta per servizio Jabber.
A questo punto nel computer che gestisce SOSO inseriamo il comando di avvio di agent.pl nel file inttab presente nella directory /etc, attraverso l’inserimento di questa semplice riga di testo alla fine del file:

x:3:respawn:su username -c /usr/bin/agent.pl

La direttiva respawn fa si che il processo che gestisce agent.pl venga riavviato in caso di chiusura accidentale dell'applicazione. A questo punto avviando dal nostro personal computer domestico il client Pidgin potremmo vedere il nostro strumento sempre online in attesa di ricevere i nostri comandi. Nessun problema per quanto riguarda la sicurezza in quanto il nostro agent-robot  risponderà solo a quei comandi inviati da account precedentemente inseriti nella  buddy list, senza contare il fatto che, se per caso un estraneo avviasse il collegamento SSH reverse, questo si collegherà esclusivamente al vostro server (ricordate le chiavi di autentificazione asimmetrica...) rintracciato attraverso un servizio dns dinamico di cui solo voi conoscete gli estremi di identificazione, user e password di abilitazione: il tutto nella massima sicurezza.