MONITORAGGIO ATTIVO DI UN CLUSTER DI RASPBERRY PI - Falzaresi Stefano.pdf · soluzione permette di con gurare delle soglie di allerta per alcune grandezze fondamentali quali il carico

ALMA MATER STUDIORUM – UNIVERSITA DI BOLOGNACAMPUS DI CESENA

Scuola di ScienzeCorso di Laurea in Ingegneria e Scienze Informatiche

MONITORAGGIO ATTIVODI UN

CLUSTER DI RASPBERRY PI

Elaborato in

PROGRAMMAZIONE DI RETI

Relatore

GABRIELE D’ANGELOPresentata da

STEFANO FALZARESI

Seconda Sessione di LaureaAnno Accademico 2015 – 2016

Se vuoi qualcosa vai e inseguila...

Indice

Introduzione vii

1 Analisi 1

1.1 Descrizione del problema . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Valutazione di mercato . . . . . . . . . . . . . . . . . . . . . . . 2

1.2.1 Site24x7 . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2.2 Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2.3 Zabbix . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2.4 Valutazione . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.3 Scelta della soluzione . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Struttura della Soluzione Proposta 9

2.1 Progettazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3 Polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4 Comunicazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.5 GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.5.2 Homepage . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.5.3 Admin Page . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Implementazione 23

3.1 Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1.1 Interfaccia Web . . . . . . . . . . . . . . . . . . . . . . . 23

3.1.2 API Manager . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2 Polling e Comunicazione . . . . . . . . . . . . . . . . . . . . . . 30

3.2.1 Raspberry Pi . . . . . . . . . . . . . . . . . . . . . . . . 30

3.2.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.3 GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.3.1 Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.3.2 Stile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.4 Accessibilita . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

v

vi INDICE

4 Valutazioni Finali 474.1 Analisi dei Risultati . . . . . . . . . . . . . . . . . . . . . . . . . 474.2 Considerazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.3 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Ringraziamenti 49

A Elenco API 51

B Guida all’installazione 63

Sitografia 73

Introduzione

All’interno del campus di Cesena dell’universita Alma Mater Studiorum estato sviluppato un esempio di cluster computing basato sull’uso di 64 Raspber-ry Pi interconnessi tra loro tramite connessione ethernet e disposti all’internodi una struttura composta da mattoncini Lego a creare delle torri colorate.Infrastrutture di questo tipo richiedono che venga effettuata una rilevazionecostante dello stato dei dispositivi che le costituiscono cosı da poter indivi-duare tempestivamente possibili malfunzionamenti o un carico di lavoro nonadeguato.Nel corso di questa tesi verranno inizialmente analizzati i requisiti che un siste-ma di monitoraggio per cluster di questo tipo deve possedere e le funzionalitache dovra mettere a disposizione dell’amministratore e degli utenti che vi do-vranno interagire, in funzione ad essi si effettuera una scelta della soluzioneche verra ritenuta piu adatta allo svolgimento dei compiti richiesti.La proposta che si decidera di adottare verra analizzata nel dettaglio cosı daidentificare le caratteristiche fondamentali della struttura, il funzionamentodelle parti che la compongono e la motivazione alla base di alcune delle sceltetecnologiche effettuate.Nella parte conclusiva della trattazione ogni modulo sviluppato verra attenta-mente sezionato ed analizzato. Per ogni sezione verranno indicati i linguaggidi programmazione utilizzati, la motivazione alla base delle scelte effettuate edestratti implementativi che maggiormente caratterizzano la parte esposta.A corredo sono state aggiunte a questa tesi due appendici, nella prima sonoindicate tutte le API messe a disposizione dal sistema con una spiegazionedelle funzionalita di ognuna ed una indicazione dei dati necessari al correttofunzionamento; la seconda invece contiene una guida all’installazione del siste-ma con indicazione dei prerequisiti richiesti e dei passi necessari per la messain opera.

vii

Capitolo 1

Analisi

La trattazione di questo capitolo sara volta alla definizione del proble-ma, alla ricerca ed alla conseguente selezione della soluzione piu consona allenecessita espresse.

1.1 Descrizione del problema

Il dipartimento di Informatica Scienza e Ingegneria dell’Universita di Bo-logna con il supporto finanziario di Ser.In.Ar da agosto 2013 [1] ha ideato,progettato ed in seguito prodotto un cluster di calcolo denominato “Raspein”.Per lo sviluppo si e scelto, a differenza di altri cluster, di utilizzare come nodidei Raspberry Pi Model B ver. 2 (da qui il nome Raspein) cosı da avere unsistema compatto e dai costi contenuti con il quale pero gli studenti potesseroeffettuare delle sperimentazioni reali su una struttura di calcolo distribuita.Inizialmente il sistema era composto da 32 nodi che sono poi stati raddoppiaticosı da ottenere un cluster formato da 64 Raspberry suddivisi in varie torricomposte da mattoncini Lego R©. Ora che il cluster Raspein e completamen-te operativo e funzionante si e palesata la necessita di dotarlo di un sistemache ne permetta il monitoraggio in tempo reale, compito di questa tesi saraquindi la ricerca, la selezione e l’implementazione di una soluzione in grado dirisolvere questa problematica. D’accordo con il docente si e deciso di focaliz-zare la ricerca su alcuni aspetti fondamentali che la soluzione proposta dovraobbligatoriamente possedere:

• Basso impatto prestazionale sui dispositivi periferici

• Possibilita di assegnare un range di valori “ammessi” per ogni sensore

• Possibilita di avere un sistema di alerting qualora venga rilevato un valoreal di fuori del range indicato

1

2 CAPITOLO 1. ANALISI

• Avere una visualizzazione “mobile friendly”

• Permettere l’interfacciamento con applicazioni mobili native

• Costi di gestione contenuti

1.2 Valutazione di mercato

Una volta definiti i criteri si e avviata una ricerca di mercato per identi-ficare i principali sistemi di monitoraggio disponibili, tra i risultati ottenutie quindi stata fatta un’ulteriore selezione mantenendo solamente le soluzioniaventi le caratteristiche richieste dai requisiti esposti; si e deciso di valutare siasoftware a pagamento che software gratuiti analizzando innanzitutto le funzio-nalita offerte e valutandone poi in seguito l’impatto economico. Le soluzionipiu interessanti verranno ora analizzate con attenzione per definirne pregi edifetti relativamente alla specifica implementazione.

1.2.1 Site24x7

[2]

Caratteristiche

Site24x7 R© e un sistema di monitoraggio offerto da Zoho Corporation; que-sta e una soluzione di tipo cloud che non richiede quindi l’installazione di unserver centralizzato presso la rete da monitorare, e una suite in abbonamentocon varie soglie disponibili a partire da un minimo di 9$ mensili (permettendoil monitoraggio fino ad un massimo di 10 dispositivi). Il sistema si presentasin da subito molto completo ed articolato, al primo avvio una procedura gui-data porta alla messa in monitoraggio di un host che potra essere un Server ouna risorsa web. La tipologia server richiede che sul dispositivo da monitoraresia installato un agent di connessione, questo, attraverso un codice univoco,effettuera il binding con il nostro account che iniziera da quel momento a ri-cevere con periodicita definibile i dati dal dispositivo, l’agent e presente per lamaggior parte dei sistemi operativi e, per effettuarne l’installazione, non sononecessarie particolari abilita.

CAPITOLO 1. ANALISI 3

Figura 1.1: Pannello di controllo Site24x7

Il supporto tecnico al servizio e garantito da un call center sempre attivo,da dei webinar gratuiti e da delle guide molto complete che rendono inoltrela configurazione del sistema estremamente facile. Come da richieste questasoluzione permette di configurare delle soglie di allerta per alcune grandezzefondamentali quali il carico della CPU, lo spazio su disco o la memoria occu-pata, qualora vengano oltrepassate si ricevera una notifica attraverso Twitter,email, SMS o Messaggio istantaneo. Site24x7 mette inoltre a disposizione deipropri clienti un’applicazione mobile (disponibile su piattaforme iOS e An-droid) attraverso la quale e possibile accedere al proprio account e monitorarei dispositivi connessi.

Valutazione

Dalle verifiche e dai test effettuati su questo strumento ho potuto constata-re che l’offerta e molto completa e permette di rispondere a molti dei requisitirichiesti. Nonostante questo esistono pero delle problematiche legate alla par-ticolare natura delle nostre necessita, il problema principale di questa tipologiadi servizio e rappresentato dal fatto che per collezionare i dati viene utilizza-to un demone che, a volte, ha richiesto un utilizzo di CPU che si e attestatointorno al 5% su un server con una potenza di calcolo superiore a quella deiRaspberry che dovremmo andare ad analizzare; inoltre questo sistema essendobasato su servizi in cloud richiede che i dispositivi monitorati facciano costan-temente delle comunicazioni tramite Internet andando ad incidere in questomodo sul traffico generato dalla rete. In ultimo una delle richieste era potermonitorare varie tipologie di grandezze sui dispositivi quali ad esempio la tem-


peratura del sistema, su Site24x7 questa tipologia di controllo non e presentee sarebbe quindi necessario svilupparla, da zero.

1.2.2 Nagios

[3]

Caratteristiche

Nagios R© e un prodotto sviluppato dalle Nagios Enterprises e basato sull’ar-chitettura Nagios Core fornita in licenza GPLv2 (GNU General Public Licen-se), l’azienda produttrice ha deciso di fornire due diverse tipologie di servizio,una completamente gratuita attraverso Nagios Core ed una a pagamento at-traverso Nagios XI. Le differenze tra le due versioni sono irrilevanti nell’otticadi questo progetto e quindi risulta essere sufficiente analizzare le funzionalitamesse a disposizione da Nagios Core. Per il funzionamento del sistema e indi-spensabile la presenza di un computer con sistema operativo Linux che fungerada server web e server applicativi, l’installazione risulta essere relativamentefacile[4] ma richiede comunque un minimo di conoscenza di Linux e dei suoicomandi principali; in circa 20 minuti il sistema dovrebbe essere pronto peressere poi configurato. Tutta la configurazione e basata su dei file di testonei quali vengono indicati i vari host (che possono anche essere suddivisi ingruppi), i servizi da monitorare su ognuno di essi e il metodo di notifica dautilizzare nel qual caso avvenga un evento problematico.

define host{

use generic-host ; Inherit default values from a template

host_name remotehost ; The name we are giving to this host

alias Some Remote Host ; A longer name associated with the host

address 192.168.1.50 ; IP address of the host

hostgroups allhosts ; Host groups this host is associated with

}

define command{

name check_http

command_name check_http

command_line $USER1$/check_http -I $HOSTADDRESS$ $ARG1$

}

Listato 1.1: Esempio di file di configurazione

Questa soluzione mette a disposizione dei propri utenti una moltitudine di plu-gin che permettono l’utilizzo di particolari funzionalita non nativamente im-


plementate, uno di questi e ad esempio NRPE (Nagios remote plugin executor,fondamentale per il controllo di sistemi remoti (nel caso specifico i Raspberry).

Figura 1.2: funzionamento NRPE[5]

Tra i vari plugin pero non e stato possibile trovare qualcosa che permettala comunicazione attraverso twitter e dispositivi mobili.

Valutazione

La natura open source del progetto lo ha reso inizialmente e per vari anniuno dei software maggiormente utilizzati, la community molto attiva ha inoltrepermesso la creazione di molti plugin capaci di coprire svariate necessita, negliultimi due anni pero la mancanza di nuove funzionalita e di un restyling graficohanno portato questo software a perdere sempre piu quote di mercato fino adattestarsi ad un 20%[6] circa e vedendo la conseguente nascita ed affermazionedi soluzioni piu innovative. Allo stato di sviluppo attuale questo softwarenon mette a disposizione dei plugin funzionanti per l’utilizzo di Twitter oper il monitoraggio del sistema su dispositivi mobili; non riuscendo quindi arispondere completamente a tutte le richieste effettuate sarebbe necessario daparte nostra implementare tali funzionalita all’interno di nuovi plugin ma ciorichiede l’acquisizione di specifiche competenze in merito ed un considerevoletempo di sviluppo.

1.2.3 Zabbix

[7]

Caratteristiche

Zabbix R© e un software sviluppato dalla Zabbix SIA dagli inizi del 2005,questo prodotto viene rilasciato con licenza GPLv2 ma, se utilizzato a scopicommerciali, il produttore invita ad acquistare un servizio di supporto a pa-gamento. E un sistema di tipo centralizzato che richiede quindi un server rag-giungibile dai dispositivi oggetto del monitoraggio. L’installazione del server


principale richiede una piattaforma LAMP (Linux Apache MySql Phpmyad-min) basata su una qualsiasi distribuzione Linux, per agevolare l’installazionesono resi disponibili un Live CD o una macchina virtuale preconfigurata anchese il fornitore consiglia quest’ultima tipologia di approccio solo per effettuaredei test e non per la vera messa in produzione. Al termine dell’installazionela configurazione del sistema puo essere effettuata interamente attraverso l’in-terfaccia web di Zabbix, per compiere questa fase non e disponibile una verae propria procedura guidata ma, seguendo il manuale disponibile online[8], ipassi per la creazione di un host e dei relativi “sensori” non risultano essereestremamente complessi ed e inoltre possibile, una volta terminata la confi-gurazione del primo dispositivo, creare un layout personalizzato da poter poiesportare per la creazione dei successivi. La comunicazione tra server e dispo-sitivi puo essere fatta in modo passivo con il server che attende i dati daglialtri host o attivo con il server che invia ad uno o piu host le richieste di undeterminato valore; la comunicazione server-client puo avvenire attraverso unagent preventivamente installato sui client (che poi rimarra continuamente inesecuzione) o “agentless” attraverso dei trap snmp (simple network manage-ment protocol). Per ogni risorsa monitorata e possibile definire delle soglie che,nel caso in cui vengano oltrepassate, mettono in moto la procedura di alertingche si occupera di avvisare l’amministratore della rete dell’avvenuto guasto.

Figura 1.3: Dashboard di Zabbix


Le tipologie di notifica offerte nativamente sono: email, SMS (richiede unmodem GSM), Jaber o Ez Texting, e pero possibile definire degli script per-sonalizzati attraverso linguaggio bash (bourne again shell) o python. Non epresente un’applicazione ufficiale per smartphone o tablet ma, grazie alle API(application programming interface) messe a disposizione, varie soluzioni diterze parti sono comunque ottenibili dagli application store.

1.2.4 Valutazione

Zabbix e tra le migliori soluzioni gratuite presenti sul mercato, una grafi-ca moderna unita ad una rapida curva d’apprendimento hanno portato questoprodotto ad essere una delle vere alternative a Nagios sul quale sta ormai pren-dendo il sopravvento. Grazie alla sua comunita molto attiva e possibile trovaresvariati template gia fatti per il monitoraggio di particolari dispositivi o peraggiungere funzionalita al sistema. Nonostante cio pero non sono ancora at-tualmente disponibili un sistema di alerting attraverso twitter o un sistema peril monitoraggio della temperatura di sistema; probabilmente e possibile imple-mentare queste funzionalita grazie all’utilizzo degli alert script personalizzatie delle API disponibili ma questo richiederebbe ovviamente del tempo sia perlo studio del sistema che per la creazione ed il testing di quanto necessario.

1.3 Scelta della soluzione

Dall’analisi effettuata sulle tre soluzioni sopra elencate quella con la mag-gior parte delle caratteristiche richieste risulta essere Site24x7 che pero a frontedi un costo non indifferente di 780$ annui non fornisce tutte le funzionalita ri-chieste ed inoltre la tipologia di comunicazione basata sul continuo scambiodi dati attraverso la rete Internet collide con due delle basi fondamentali sucui si basa questo progetto, il basso impatto sulle prestazioni di ogni singoloRaspberry e lo spreco minimo di banda. Tutte le altre soluzioni invece nonrispondendo completamente alle richieste fatte richiederebbero, da parte di chiimplementera il sistema, un impegno non indifferente per l’apprendimento ap-profondito dello stesso cosı da poter aggiungere, manutenere ed adattare neltempo alle mutevoli necessita i moduli mancanti. Queste conoscenze acqui-site andrebbero si ad accrescere il bagaglio di competenza di chi le andra astudiare ma risulterebbero poco spendibili nel futuro trasformando cosı il tem-po utilizzato quasi in un tempo sprecato. Per tutte queste motivazioni credoche, nonostante la grande quantita di funzionalita disponibili, nessuna delleproposte attualmente presenti sul mercato possa ritenersi adatta ad effettua-re il monitoraggio del cluster e ritengo quindi che, sia a livello di formazione


che a livello di future implementazioni, sia preferibile sviluppare una soluzio-ne personalizzata che abbracci completamente le necessita precedentementedescritte.

Capitolo 2

Struttura della SoluzioneProposta

Questo capitolo trattera in dettaglio la soluzione selezionata evidenzian-done le funzionalita e la composizione. Verra effettuata una suddivisioneper moduli ognuno dei quali verra approfondito mostrandone funzionalita estruttura.

9

10 CAPITOLO 2. STRUTTURA DELLA SOLUZIONE PROPOSTA

2.1 Progettazione

Come visto precedentemente le necessita molto specifiche che il progettopossiede ci hanno portato a scegliere di sviluppare una soluzione completa-mente personalizzata piuttosto che adattare un software gia sul mercato, i duepilastri portanti che hanno guidato l’intera fase di progettazione sono statil’uso limitato di risorse sui dispositivi periferici e la possibilita di espandibi-lita futura. Per fare cio si e quindi scelto di ideare un sistema che avesse unCore principale al quale poter collegare uno o piu moduli, il dialogo tra Coree moduli periferici verra poi effettuato utilizzando le piu moderne tecnologieweb. Questo tipo di struttura e pensata per essere la base da cui partire perimplementare di volta in volta sempre nuove funzionalita permettendo pero diriutilizzare cio che era stato precedentemente fatto. In questa relazione verratrattata la prima versione del sistema, i moduli sviluppati per questa versionesono i seguenti:

Core: immagazzina i dati ricevuti e li scambia con gli altri moduli

Polling: acquisisce i dati dai dispositivi li verifica e li invia al Core

Comunicazione: si occupa della comunicazione tra sistema utenti ed ammi-nistratori

GUI: rende il progetto accessibile all’utente finale

Attraverso la Figura 2.1 viene mostrata l’organizzazione di questi moduli el’interazione presente tra di essi, e possibile notare come il Core sia al centrodell’intero sistema e come quindi gli altri moduli periferici dialoghino quasiesclusivamente con esso.

Figura 2.1: Struttura del progetto

CAPITOLO 2. STRUTTURA DELLA SOLUZIONE PROPOSTA 11

La struttura a moduli utilizzata permette inoltre di suddividere le funzio-nalita tra vari dispositivi o server, questa tipologia di approccio permette digarantire un’elevata scalabilita e flessibilita del sistema; per molte parti inoltree possibile effettuare una ulteriore segmentazione interna permettendo cosı disfruttare ad esempio servizi gia presenti sulla rete di destinazione (ad esempiopotrebbe essere riutilizzato un server dei database o un server web). Per me-glio analizzare e definire l’intero sistema entreremo ora piu nel dettaglio dellequattro parti evidenziate.

2.2 Core

Il Core rappresenta la base di tutto il sistema ed ogni altro modulo perpoter funzionare deve interagire con esso, le sue funzioni principali sono quindiimmagazzinare i dati, organizzarli e scambiarli con le altre parti del sistemain modo semplice e standardizzato. Volendo permettere l’utilizzo di questomodulo anche a servizi di terze parti (quali ad esempio un’applicazione mobile)si e deciso di dotarlo di un sistema di autenticazione basato su dei token e, adogni richiesta di interazione, ogni client dovra quindi allegare anche il propriotoken univoco; ad ognuno di essi e assegnato inoltre un livello permettendocosı di inibire l’accesso ad una o piu risorse. In Figura 2.2 viene delineata lastruttura del Core e le due parti fondamentali che lo compongono:

API Manager: riceve ed interpreta le richieste

Authenticator: verifica le credenziali fornite e il livello delle stesse

Figura 2.2: Struttura interna del Core


2.2.1 Funzionamento

Attraverso il protocollo HTTP (Hypertext Transfer Protocol) i client inter-rogano le REST API (Representational State Transfer) messe a disposizionedall’API Manager, le tipologie di richiesta supportate sono:

GET per la lettura di dati

POST per la scrittuda di dati

Per questa specifica installazione si e scelto di effettuare lo scambio di datiattraverso il protocollo HTTP che risulta essere non sicuro in quanto lo scam-bio di dati che avviene tra client e server e totalmente in chiaro, sara quindinecessario a livello di firewall di rete imporre delle limitazioni al traffico chepuo essere instradato verso il server che fara da API Manager cosı che la comu-nicazione avvenga tra due dispositivi all’interno di una rete trusted (che potraessere una rete locale o una rete creatasi attraverso una VPN(Virtual privatenetwork)).In alternativa, nel caso in cui si decida di rendere tale servizio totalmente acces-sibile anche dall’esterno sara necessario utilizzare un protocollo maggiormentesicuro come ad esempio HTTPS (Hypertext transfer protocol over secure soc-ket layer) che prevede la trasmissione di pacchetti HTTP attraverso un tunnelcrittografato, per fare cio sara necessario configurare in modo adeguato il ser-ver web che fornisce le API e acquistare da delle CA(Certification Authority)un certificato digitale che ne attesti l’identita.In Figura 2.3 viene mostrato il diagramma di sequenza relativo alla ricezionedi una richiesta; appena questa viene ricevuta l’API Manager ne verifica latipologia ed in seguito passa la chiave di autenticazione e il nome dell’APIrichiesta all’authenticator che, con i dati forniti, interroga il proprio databasee verifica che la chiave fornita risulti correttamente censita e che non sia statarevocata, se questo controllo ha esito positivo viene verificato quindi, sempreattraverso un’interrogazione al database, il livello di autenticazione necessarioper usufruire dell’API, se vi e corrispondenza tra il livello della chiave e quel-lo necessario all’uso della funzione l’esito positivo verra inviato alla sessionedell’API manager che aveva effettuato la chiamata il quale lo interpretera e diconseguenza valutera la successiva operazione da svolgere.


Figura 2.3: Diagramma di sequenza, ricezione di una richiesta

Al fine di permettere il corretto funzionamento di questo servizio e necessa-rio che l’amministratore del sistema possa gestire tutti i token di autenticazionemessi a disposizione degli utilizzatori, per fare cio e stato creato un appositoportale web attraverso il quale sara quindi possibile crearli e modificarli; co-me e possibile notare dalla Figura 2.4 in fase di creazione vengono richiestiesclusivamente una descrizione ed un livello da assegnare alla chiave, se il pro-cesso termina in modo corretto verra mostrata la chiave alfanumerica generataautomaticamente ed utilizzabile per l’autenticazione alle API.


Figura 2.4: Nuova chiave correttamente generata

Vista la delicatezza di questa procedura si e deciso di dotare di un ulteriorelivello di sicurezza le operazioni che prevedono una interazione con il data-base, ogni funzione sviluppata identifica quindi prima di effettuare qualsiasioperazione, la pagina di provenienza della chiamata e verifica che tale pagi-na appartenga ad un referer valido, in caso contrario la computazione verrainterrotta.

2.3 Polling

Lo scopo principale del modulo di polling e la raccolta ed interpretazionedei dati provenienti dai dispositivi e il successivo invio al Core. Come mostratoin Figura 2.5 gli elementi che compongono questo modulo sono due:

Controller: interagisce con Core e dispositivi

Dispositivi: generano file di diagnostica

Figura 2.5: Struttura del modulo di polling


2.3.1 Funzionamento

Il controller avvia il modulo e richiede al Core i dati di configurazione ne-cessari per poter essere operativo come ad esempio la cartella da cui dovranoessere prelevati i dati dei dispositivi. Questi ultimi invece, avendo risorse li-mitate, non dialogano direttamente con il Core e quindi all’interno del codicesviluppato contengono gia tutte le informazioni necessarie a rilevare in modoperiodico i valori dei sensori presenti e esportare questo dato all’interno delcontroller; attraverso protocollo NFS (Network file system), i dati rilevati so-no inseriti, unitamente all’identificativo del dispositivo, all’interno di un fileopportunamente formattato. Ad intervalli prefissati il controller verifica all’in-terno della cartella comunicatagli in fase di avvio se sono presenti dei nuovi filee, se cosı fosse,li analizza singolarmente effettuandone il parsing ed identifican-do il Raspberry che lo ha generato e le grandezze presenti al suo interno, unavolta verificata online l’effettiva esistenza del dispositivo i dati rilevati vengonoinviati al Core che li rendera poi fruibili agli altri moduli.

2.4 Comunicazione

Questo modulo svolge tutte le operazioni di controllo e comunicazione delsistema, l’unico elemento che ne compone la struttura e il controller il qualerichiede i dati al Core e li analizza per poi valutare se e necessario effettuarel’invio di una comunicazione.

Figura 2.6: Infrastuttura di comunicazione

2.4.1 Funzionamento

Come il modulo di polling anche quello di comunicazione all’avvio contattail Core per prendere tutti i dati a lui necessari per l’interfacciamento, nellafattispecie vengono importati tutti i dati necessari all’invio di messaggi tramiteTwitter tra i quali e presente anche il nickname dell’amministratore di sistema.Le funzionalita specifiche messe a disposizione da questo modulo sono tre:

invio messaggi di errore all’amministratore

risposta a query specifiche


aggiornamento dello stato

L’invio di messaggi di errore all’amministratore viene effettuato al rilevamentodi un valore non corretto per uno o piu sensori presenti su un Raspberry, perfare cio il modulo contatta in modo periodico il Core richiedendo i dati ditutti i Raspberry a cui risulta collegato e per ognuno analizza i dati dei sensoriattivi, se il range indicato non e corretto viene inviato un messaggio attraversole API fornite da Twitter e, nello stesso istante, viene pubblicato anche untweet sulla pagina del sistema.

Figura 2.7: Esempio di comunicazione effettuata su Twitter [9]

La seconda funzionalita di questo modulo permette agli utenti finali di ri-chiedere, tramite Twitter, lo stato di un particolare dispositivo, per un vincolodi sicurezza posto dalle API del social network questa funzione e disponibileesclusivamente agli utenti che risultano essere follower dell’account @Raspein-Monitor; scrivendo infatti a questo account un messaggio privato con la di-citura “status nome Raspberry” si avra in risposta l’elenco dei sensori attivicon l’ultimo valore rilevato e la data di rilevamento. Per fare cio il controllerverifica in modo periodico i messaggi ricevuti e li analizza iterativamente ri-chiedendo poi in diretta al Core i dati richiesti dall’utente.L’ultima funzione messa a disposizione e esclusivamente di tipo “social”; essa


permette infatti all’amministratore di scrivere un messaggio privato a @Ra-speinMonitor richiedendo di postare un aggiornamento di stato sul profilopubblico del sistema; per farlo e sufficiente inviare un messaggio privato conla scritta “update messaggio da pubblicare” ed il controller effettuera la pub-blicazione del messaggio verificando preventivamente che il mittente sia effet-tivamente l’amministratore.

Figura 2.8: Scambio di messaggi tra amministratore e modulo dicomunicazione

2.5 GUI

La GUI (Graphical user interface) e, come indica anche il nome stesso,quella parte del sistema che si interfaccia direttamente con l’utente finale.Come mostrato in Figura 2.9 questo modulo e composto esclusivamente dalserver web Apache al quale i client si collegano.


Figura 2.9: Interfacciamento della GUI con client e Core

2.5.1 Funzionamento

Essendoci tra le richieste di base la necessita che questo sistema fosse visua-lizzabile sia su computer che su dispositivi mobili (con particolare attenzioneai tablet) la scelta progettuale e stata quella di utilizzare nella costruzione del-le pagine il framework Bootstrap[10]. Bootstrap prevede la suddivisione dellapagina web secondo una griglia che poi viene adattata e modificata al cambiaredelle dimensioni del display che la sta visualizzando rendendo cosı la pagina“responsive”. Per lo sviluppo di questo progetto web si e scelto di utilizzarele tecnologie che piu rappresentano l’attuale era della navigazione, per la crea-zione delle pagine e stato utilizzato il linguaggio HTML (HyperText markuplanguage) nella sua ultima quinta versione, la formattazione delle pagine e in-vece resa possibile grazie ad un importante utilizzo di fogli di stile in linguaggioCSS3[11] (Cascading style sheet). Si e scelto infine di popolare il contenuto del-le pagine non con PHP, uno dei piu classici sistemi server side, ma sfruttandodegli script jQuery[12] e la tecnica AJAX (Asynchronous JavaScript an XML)cosı da rendere il caricamento dei contenuti asincrono a quello della pagina edella grafica e dando inoltre all’utente la possibilita di interagire con la paginain modo piu dinamico.

2.5.2 Homepage

La homepage mostra lo stato attuale di ogni Raspberry posizionandoli al-l’interno delle torri che costituiscono il cluster Raspein, all’utilizzatore e per-messo cliccare su ognuno dei valori rilevati per vederne attraverso un graficol’andamento nelle ultime 24 ore, cliccando invece sul Lego che identifica il Ra-spberry e possibile selezionare un arco temporale da analizzare ed un sensore,


verra cosı mostrato un grafico con i dati richiesti.Tutti i valori mostrati e quelli presenti all’interno dei grafici vengono prelevatidal Core attraverso le API messe a disposizione. Per disegnare invece i graficiviene utilizzato un servizio web offerto da Google chiamato Google Charts [13].

Figura 2.10: Homepage, visualizzazione di un grafico[14]

2.5.3 Admin Page

Vi e poi la pagina admin raggiungibile solamente previa autenticazione edattraverso la quale l’amministratore puo completamente configurare il sistemae modificare i dati utilizzati dagli altri moduli.


Figura 2.11: Pagina di amministrazione[15]

La pagina e formata da due sezioni:

Devices: da cui gestire torri e dispositivi

System: da cui gestire le impostazioni di sistema

Attraverso le icone presenti all’interno della prima sezione e possibile aggiun-gere o rimuovere delle torri e, per ognuna, e possibile aggiungere, modificare orimuovere i dispositivi al suo interno.

Figura 2.12: Pagina admin, gestione delle torri

Per procedere alla fase di aggiunta di un dispositivo e sufficiente premereil tasto corrispondete ed inserire i dati dello stesso nella modale che verravisualizzata, i dati richiesti sono il colore che si vuole assegnare al dispositivo(cosı da modificare il colore dell’icona presente in homepage), un nome univocoed una posizione all’interno della torre, e poi necessario indicare per i sensori


attivi il range entro il quale il dispositivo e in uno stato di normalita e fuoridal quale si ricevera invece una notifica.

Figura 2.13: Pagina admin, aggiunta di un dispositivo

Attraverso system e invece possibile configurare tutte le variabili di sistemache consentono il corretto funzionamento degli altri moduli, contiene quindile informazioni relative a Twitter ed al percorco in cui i dispositivi salvano ipropri file di diagnostica.

Figura 2.14: Pagina admin, sezione “system”

Capitolo 3

Implementazione

Nel capitolo seguente verra mostrato il metodo implementativo utilizzatoper produrre il sistema precedentemente illustrato.

3.1 Core

Le parti costituenti il Core sono due, una che effettua l’autenticazione degliutenti e una che esegue l’effettiva computazione delle richieste, entrambe leparti sono web-based quindi le tecnologie ed i linguaggi utilizzati sono propridi questo ambiente.

3.1.1 Interfaccia Web

L’interfaccia web, da utilizzarsi per la creazione e modifica dei token diautenticazione, e stata prodotta utilizzando il linguaggio HTML unito al fra-mework Bootstrap ed a CSS3 per lo stile.Per l’interfaccia si e scelto di operare principalmente utilizzando degli scriptjQuery, dovendo pero interagire con un database relazionale e stato necessarioutilizzare anche PHP, per fare cio la tecnica utilizzata e stata AJAX con richie-ste POST, nel Listato 3.1 e mostrato un esempio rappresentante la chiamataad una funzione PHP e la conseguente interpretazione del risultato di tipoJson, la funzione viene abilitata alla pressione di un elemento sulla pagina cheabbia id “addBtn”, avendo utilizzato jQuery ogni elemento sulla pagina puoessere utilizzato per far scaturire un evento differentemente da quanto invecesuccederebbe con una pagina sviluppata esclusivamente in linguaggio HTML,inoltre si puo notare come i dati poi utilizzati non debbano per forza essereall’interno di uno stesso form ma, come successo per l’evento click, possonoessere attinti da qualsiasi elemento presente nel documento.

23

24 CAPITOLO 3. IMPLEMENTAZIONE

I selettori messi a disposizione da questo linguaggio sono vari, quelli maggior-mente utilizzati nello sviluppo di questo progetto sono i selettori di “classe” odi “id”, un punto apposto all’inizio del nome identifica la volonta di selezionareuna classe, un cancelletto invece prevede la selezione di un oggetto per id.

$("#addBtn").click(function(){

var desc=$("#description").val();

var lvl=$("#level").val();

desc = desc.replace("’","");

$.ajax({

url: ’php/newKey.php’,

type: ’POST’,

data: {"desc":desc,"lvl":lvl},

dataType: ’json’,

})

.done(function (result) {

$("#newKeyP").text(result);

})

.fail(function () {

$("#newKeyP").text("Error try again");

});

});

Listato 3.1: Chiamata AJAX ad una funzione PHP

Nel Listato 3.2 viene invece mostrata la funzione PHP relativa allo scriptsopra sopra analizzato la cui funzione e generare una nuova chiave di auten-ticazione, la particolarita di questa funzione, proposta poi anche nelle succes-sive funzioni dell’authenticator, sta nel controllo preventivo del referer dellafunzione, viene cioe identificato l’url richiedente e viene verificato che sia cor-rispondente a quello aspettato per la funzione in oggetto, questo accorgimentoe stato preso per ridurre le possibilita di un attacco esterno. Volendo rendereil piu possibile “portabile” questo progetto si e inoltre deciso di salvare l’urlradice di ogni pagina all’interno di un file di configurazione, tale url verra poireso disponibile a tutte le funzioni che lo necessitano, nello stesso file sonoinoltre inseriti i dati fondamentali di accesso al database locale.Al termine della verifica di attendibilita del referer la funzione procede allacreazione di un nuovo token di autenticazione, basandosi su un set di caratterialfanumerici ogni catattere viene estratto in modo casuale dal set fino a com-porre una stringa avente una lunghezza fissa di 40 caratteri.La chiave generata ed il suo livello vengono poi salvati all’interno del databasee ed alla funzione AJAX chiamante viene restituito un risultato contenente lachiave.

CAPITOLO 3. IMPLEMENTAZIONE 25

<?php

include("../inc/settings.php");

$ref = $_SERVER["HTTP_REFERER"];

if( $ref === $referrer."newKey.php"){

$description = $_POST["desc"];

$level = $_POST["lvl"];

$myConn = new mysqli($db_server,$db_user,$db_pass,$db_name);

do{

$string = ’’;

$characters = ’abcdefghijklmnopqrstuvwxyz0123456789’;

for ($i = 0; $i < 40; $i++) {

$string .= $characters[rand(0, strlen($characters) - 1)];

}

$query = "insert into apis

values(DEFAULT,’".$string."’,’".$description."’,".$level.",1)";

$toRet = $string;

}while(!($myConn->query($query)));

error_log("ritorno ".$toRet);

echo json_encode($toRet);

}else{

die;

}

Listato 3.2: Funzione PHP di creazione nuova chiave

L’applicativo web mette inoltre a disposizione dell’operatore altre funzio-ni che permettono la visualizzazione e modifica di chiavi precedentementegenerate, anche in questo caso l’interazione e del tipo jQuery - AJAX - PHP.

3.1.2 API Manager

il gestore delle API e la sezione piu corposa di questa parte ed e statainteramente sviluppata utilizzando come linguaggio di programmazione PHPorientato ad oggetti, sono stati quindi creati vari oggetti ognuno dei quali svol-ge una funzione specifica e rende disponibile vari metodi per potervi interagireed operare quindi piu ad alto livello.L’aspetto fondamentale che un set di API deve possedere e dato dalla sempli-cita di utilizzo, e necessario quindi fare in modo che richiamando uno specificourl il sistema possa riconoscere automaticamente il corretto servizio da erogare;per poter ottenere questo risultato e stato necessario abilitare sul server webApache il modulo “mod rewrite”[16] questo modulo permette infatti, tramite


delle regular expression, di identificare l’url richiesto e reindirizzarlo ad unapagina di destinazione senza pero perdere l’url iniziale.Per permettere il corretto funzionamento di questo modulo e necessario chealcune funzioni all’interno della configurazione del server web siano corretta-mente configurate, nel Listato B.3 e indicato il codice necessario a permettereinnanzitutto l’esecuzione dello script di istruzione del modulo, questa confi-gurazione e legata esclusivamente alla cartella in cui il modulo deve essereutilizzato.

<Directory "/var/www/wss/">

Options Indexes FollowSymLinks

AllowOverride All

Allow from All

</Directory>

Listato 3.3: Particolare del file di configurazione di Apache

Lo script di istruzione andra composto all’interno del file “.htaccess” ed ilcodice necessario al corretto funzionamento, creato prendendo spunto da ma-nualistica e da ricerche online [17] e il seguente.

RewriteEngine On

RewriteCond %{REQUEST_FILENAME} !-f

RewriteRule ^(.*)$ /wss/index.php [QSA,L]

Listato 3.4: File .htaccess utilizzato

Con il comando “RewriteEngine” viene abilitato il motore del modulo perquesta sezione del sito; con il comando “RewriteCond” invece viene definitala condizione che attiva o meno il modulo, nell’ esempio mostrato la regolaviene attivata se la risorsa richiesta non e un file presente sul server, infine ilcomando “RewriteRule” definisce cosa e necessario fare se la regola precedentee stata soddisfatta, l’operazione da fare in questo caso e un redirect alla paginaindex.php.Il file index.php deve poter soddisfare quindi tutte le richieste inoltrategli, perfare cio all’interno dello stesso vengono instanziate tutte le classi necessarie,l’implementazione prevede la presenza di tre classi differenti:

Tools: per la gestione dell’autenticazione

Getters: contenente tutte le funzioni di tipo GET

Setters: contenente tutte le funzioni di tipo POST


Tools

Questo elemento si occupa di realizzare l’autenticazione del client, e com-posto da due funzioni:

explane url: effettua il parsing dell’url ricevuto identificando al suo internol’API richiesta

apiAuth: verifica se la key ricevuta esiste a sistema e, in caso affermativo, seil suo livello e sufficiente per l’utilizzo dell’API.

class tools {

function explane_uri($string) {

$string = str_replace("/wss/", ’’, $string);

if ($string != "") {

$vet = explode(’/’, $string);

return $vet[0];

} else

return null;

}

function apiAuth($key,$reqApi){

include ("/var/www/wss/inc/settings.php");

$keyManagerConn = new mysqli($db_api_server,

$db_api_username,

$db_api_password,

$db_api_db);

$apiManagerConn = new mysqli($db_model_server,

$db_model_username,

$db_model_password,

$db_model_db);

$response =0;

$keyLevel = 0;

$getLevelQuery = "select a.level from apis a

where a.enable=1 and a.key=’".$key."’";

if( $levelRes = $keyManagerConn->query($getLevelQuery)){

if($levelRes->num_rows == 1){

$rowLevel = $levelRes->fetch_assoc();

$keyLevel = $rowLevel["level"];

}

}


$keyManagerConn->close();

if($keyLevel !=0){

$getApiData = "select a.level,a.enable from availableApis

a

where a.name=’".$reqApi."’";

if($apiData = $apiManagerConn->query($getApiData)){

if($apiData->num_rows ==1){

$rowData = $apiData->fetch_assoc();

if($rowData["enable"] == 1){

if($rowData["level"]<=$keyLevel){

$response = 2;

}

else{

$response = 1;

}

}

}

}

}

$apiManagerConn->close();

return $response;

}

}

Listato 3.5: Specifica dell’autenticazione

Getters

Questa classe risponde a tutte le richieste di tipo GET effettuate dai client,al suo interno si compone di un costruttore e di una serie di funzioni specificheche sono elencate nell’appendice di questa tesi.Ogni funzione presuppone una interazione con il database, nell’esempio allega-to vengono mostrati il costruttore e una funzione che restituisce le informazionidi uno specifico Raspberry organizzate all’interno di un elemento Json.

class getters {

protected $modelDbConn;

function __construct(){

include("/var/www/wss/inc/settings.php");

$this->modelDbConn = new mysqli($db_model_server,

$db_model_username,

$db_model_password,


$db_model_db);

}

function getRaspi($args){

$return = null;

$query = "select * from raspberry";

if(isset($args["id"])){

if(is_numeric($args["id"])) {

$query .= " where enable=1 and id=" . $args["id"];

}

}

if($tempRes = $this->modelDbConn->query($query)){

$return[] = array("result"=>"success");

while($row = $tempRes->fetch_assoc()){

$return[] = $row;

}

}else{

$return[] = array("result"=>"error");

}

$this->modelDbConn->close();

return json_encode($return);

}

}

Listato 3.6: Parte della classe Getters con costruttore ed una funzione

Setters

Questo oggetto, strutturalmente simile a getters si occupa di gestire tuttele richieste ricevute e correttamente autenticate aventi metodo POST, questatipologia di chiamate e volta ad effettuare soprattutto aggiornamento o in-serimento di nuovi dati all’interno del database, un esempio e rappresentatodalla seguente funzione che permette di aggiungere, per un sensore specifico,il valore da esso rilevato.

function addData($args){

$return = -1;

if(isset($args["id"]) && isset($args["value"])){

if(is_numeric($args["id"]) && is_numeric($args["value"])){

$insData = "insert into sensorData

(sensorId,value,date) ".

"values(".$args["id"].",

".$args["value"].",


NOW())";

if($this->modelDbConn->query($insData)){

$return = $this->modelDbConn->insert_id;

}

}

}

$this->modelDbConn->close();

return json_encode($return);

}

Listato 3.7: Estratto dell’oggetto Setters

3.2 Polling e Comunicazione

In questa implementazione specifica si e scelto di portare all’interno del-lo stesso server sia il modulo di Polling che il modulo di comunicazione, losviluppo di questi due moduli prevede l’utilizzo di due differenti linguaggi diprogrammazione:

Bash per la creazione dei file su Raspberry

Java per le operazioni svolte dal server

3.2.1 Raspberry Pi

Su Raspberry Pi il linguaggio scelto e stato bash in quanto risulta esseredi uso comune e con costi computazionali limitati, questo e fondamentale perun dispositivo in cui la capacita di calcolo e limitata e che, quando il clustersara operativo, sara necessario sfruttare al 100%.Per non appesantire ulteriormente il sistema si e scelto di evitare l’installazio-ne di demoni all’interno del dispositivo ma di sfruttare invece “crontab” undemone gia attivo ed in funzione normalmente sui sistemi operativi Linux eche ha come unico scopo l’esecuzione programmata di alcune operazioni. Nellafattispecie a crontab viene richiesto di avviare lo script “monBatch.sh” il cuiscopo e rilevare lo stato del Raspberry e creare un file con una struttura bendefinita cosı che possa essere analizzato dal server.Anche sulla creazione del file si e cercato in tutti i modi di ridurre al minimoi byte utilizzati cosı da avere dimensioni contenute e tempi di trasferimentorapidi, la struttura del file prevede che per ogni riga venga indicato un sensoredefinito da l’id della propria tipologia e dal valore rilevato, nella prima riga delfile dovra inoltre essere inserito il nome del Raspberry che ha creato il file, una


volta generato il file viene salvato in una directory apposita che verra indicataanche nei parametri di configurazione dell’installazione cosı che il server possaidentificarla senza possibilita di errore.

#!/bin/bash

#con questo script estraggo i dati di funzionamento di raspberry

#e li metto su file

FREECPU=$(vmstat | awk ’FNR==3{print $15}’)

FREEMEM=$(free -m | grep Mem | awk ’{print $4}’)

FREEHD=$(df | grep /dev/root | awk ’{print $5}’ | sed s"/.$//")

TEMP=$(cat /sys/class/thermal/thermal_zone0/temp)

echo "0-raspMans" > /home/pi/Documents/RaspeinMon/Data/testRes

echo "1-"$FREECPU >>/home/pi/Documents/RaspeinMon/Data/testRes

echo "2-"$FREEMEM >>/home/pi/Documents/RaspeinMon/Data/testRes

echo "3-"$TEMP >>/home/pi/Documents/RaspeinMon/Data/testRes

echo "4-"$FREEHD >>/home/pi/Documents/RaspeinMon/Data/testRes

Listato 3.8: Script per l’estrazione dello stato di un Raspberry

3.2.2 Server

Per produrre la parte server si e scelto di effettuarne lo sviluppo utilizzandoJava, uno dei piu utilizzati linguaggi di programmazione orientata ad oggetti,la scelta di questo linguaggio e stata dettata in primis dall’elevata portabilitaofferta da questo linguaggio di programmazione ed inoltre anche per la grandeesperienza pregressa maturata in universita.Per cercare di rendere l’applicativo maggiormente snello e reattivo si e scel-to di utilizzare una struttura a Thread, all’avvio viene quindi avviato un“MainThread” il quale effettua l’avvio di ulteriori due thread:

MessageCrawlerThread per gestire la comunicazione

RasperyDataCollectorThread per il polling dei dati provenienti dai dispo-sitivi

tutti i thread vengono interrotti in modo controllato se l’utente richiede diterminare l’esecuzione attraverso ad esempio il comando CTRL+C.


Figura 3.1: Organizzazione dei thread

public class MainThread extends Thread{

private Boolean stop;

private MessageCrawlerThread messageHandler;

private RaspberryDataCollectorThread dataCollector;

@Override

public void run() {

this.stop=false;

ApiInteractor apint = new ApiInteractor();

ServerConfiguration serverConf = new

ServerConfigurationImpl(apint,1);

TwitterInteractor twitterInt = new

TwitterInteractor(serverConf.getTwitterConsumerKey(),

serverConf.getTwitterConsumerSecret(),

serverConf.getTwitterAccessToken(),

serverConf.getTwitterAccessTokenSecret(),

serverConf.getTwitterContactName()

);

this.messageHandler = new MessageCrawlerThread(twitterInt);

this.dataCollector = new

RaspberryDataCollectorThread(serverConf.getFolder(),

apint,twitterInt);

messageHandler.start();

dataCollector.start();

while (!this.stop){

try {

Thread.sleep(10000);


} catch (InterruptedException e) {

System.out.println("Presa eccezione nel main");

messageHandler.stopThread();

e.printStackTrace();

}

}

}

public void stopThread(){

this.stop=true;

messageHandler.stopThread();

}

}

Listato 3.9: Classe MainThread

Comunicazione

La parte di comunicazione e svolta dall’oggetto MessageCrawlerThreadquesto thread si esegue in modo periodico la funzione parseMessages dellaclasse “TwitterInteractor”. Questo metodo nel momento in cui viene invocatoverifica attraverso le API di Twitter e la libreria Twitter4J [18] se sono presentidei messaggi privati per l’account impostato (i dati sono prelevati dal Coree vengono passati nel costruttore di TwitterInteractor) e, nel caso ci fossero,vengono analizzati per individuare se e presente uno dei comandi riconosciuti.Nel caso in cui il comando richiesto preveda di prelevare dei dati dal Core vieneinstanziata la classe ApiInteractor che provvede ad eseguire le operazioni diGET e POST sul Core.


Figura 3.2: Diagramma delle classi della parte di comunicazione

Polling

La parte che effettua il polling dei dati dai dispositivi e svolta dall’oggetto“RaspberryDataCollectorThread”.Vista la crescente complessita di questa parte si e scelto di creare delle inter-facce e delle implementazioni delle stesse per ogni tipologia di operazione daeseguire cosicche la classe principale possa lavorare piu ad alto livello e futu-ri interventi di manutenzione risultino piu agevoli. Il diagramma delle classisottostante illustra le relazioni presenti tra i vari oggetti e la tipica distinzioneinterfaccia - classe presente in organizzazioni di questa tipologia.


Figura 3.3: Diagramma delle classi della parte di polling

Il costruttore della classe RaspberryDataCollectorThread prevede che ven-gano passate alla stessa gli elementi necessari all’espletamento delle propriefunzioni, questi elementi sono:

Folder necessario per identificare la cartella in cui vengono salvati i file daidispositivi

ApiInteractor per l’interazione con il Core

TwitterInteractor per l’invio di messaggi di allerta

Estendendo la superclasse Thread l’oggetto RaspberryDataCollectorThreadviene messo in esecuzione richiamando il metodo .start che produce l’esecu-zione di “run”; questo metodo in modo periodico verifica la presenza di file


all’interno della directory inizialmente definita e, attraverso l’oggetto “FilePar-singImpl”, effettua il parsing di ogni singolo file presente creando per ognunoun nuovo oggetto di tipo “RaspberryImplOnline”, copia speculare del dispo-sitivo ricevuto attraverso le API. Per ogni dispositivo viene poi verificata lapresenza dei corretti sensori e, per ognuno, aggiunto il valore rilevato.Durante l’aggiunta dei dati e presente un particolare metodo privato “chec-kRange” che verifica se il valore rilevato risulta compreso nel range di valoridefinito dall’amministratore attraverso la GUI e, nel caso vi sia un errore, inviaun messaggio privato al gestore indicandogli l’errore rilevato, in aggiunta vieneeffettuato un aggiornamento di stato sul profilo del sistema.

private void checkRange(Sensor sens,double value){

int error=0;

if(sens.getFrom() != sens.getTo()){

if(value > sens.getTo() || value < sens.getFrom()){

error ++;

try {

String sensType="";

switch (sens.getType()){

case 1:

sensType = "CPU";

break;

case 2:

sensType = "MEM";

break;

case 3:

sensType = "TEMP";

break;

case 4:

sensType = "DISK";

break;

}

twitterInt.sendErrorMessage("Il dispositivo Raspberry

avente nome "+this.name+

" e posizione "+this.position

+" ha rilevato un valore al di fuori del range

impostato sulla risorsa "

+sensType + " il valore doveva essere compreso

tra "+sens.getFrom()+ " e " + sens.getTo()

+" ed invece e "+ value);

} catch (TwitterException e) {



}

}else{

//Valore nei limiti

}

}

if(error !=0){

try {

twitterInt.sendStatusUpdate("Errors found on last check

please verify");

} catch (TwitterException e) {


}

}

}

Listato 3.10: Metodo checkRange estratto da RaspberryImplOnline

3.3 GUI

L’ultima sezione sviluppata e la GUI, per l’utilizzatore dell’applicativo ri-sulta essere la parte che maggiormente ne influenza il gradimento e quindi, perriuscire al meglio, deve essere pensata e sviluppata mettendosi dalla parte del-l’utilizzatore stesso. Partendo da questo concetto base si e scelto di svilupparel’interfaccia grafica secondo i nuovi dettami dello sviluppo web che prediligo-no pagine pulite e semplici e automaticamente adattabili a dispositivi aventidisplay di tutte le dimensioni.Inizialmente e stata valutata la possibilita di utilizzare dei CMS (content ma-nagement system) per la creazione delle pagine e del loro contenuto ma poi,analizzando quelli presenti sul commercio, e stato chiaro che le necessita delprogetto erano al di fuori di quanto attualmente disponibile e che l’adatta-mento degli attuali sistemi avrebbe richiesto lo sviluppo di particolari modulipersonalizzati; si e scelto quindi di partire da zero e produrre interamentescripts, layout grafico e pagine html.Le pagine che compongono il sito sono due, la homepage a cui accedono tut-ti gli utenti finali e la parte admin a cui possono accedere esclusivamente gliamministratori.In entrambe le pagine il linguaggio di programmazione utilizzato maggiormentee stato l’HTML prediligendolo al PHP.


3.3.1 Scripts

Come per la parte del Core vista inizialmente si e optato per l’utilizzo discript jQuery e AJAX per richiedere i dati alle API in modo asincrono, ognipagina ha un suo set di scripts apposito cosı che i dati caricati dal dispositivosiano esclusivamente quelli necessari alla visualizzazione di quella pagina.Durante lo sviluppo di questa parte ci si e immediatamente accorti che l’u-tilizzo di script per intercettare eventi su oggetti generati in modo dinamiconon si poteva basare sui classici paradigmi utilizzati in pagine statiche, perrisolvere questo problema quindi si e dovuto operare utilizzando delle parti-colari funzioni di jQuery che basano gli eventi non sull’oggetto cliccato masul body della pagina, nel Listato 3.11 l’evento “click” sull’oggetto con classe“deviceIcon” viene rilevato dal body della pagina invece che dalla classe stessa.

$(document).ready(function(e) {

$("body").on("click",".deviceIcon",function(){

populateModal($(this).siblings(".devId").text());

});

});

Listato 3.11: Script della homepage

Come detto la pagina viene popolata dinamicamente e quindi al caricamentodella stessa viene inviata una richiesta alle API con i dati di tutti i dispositiviattivi sull’installazione e in questo modo la pagina viene disegnata, nei listatisussessivi vengono mostrate tre delle funzioni che eseguono queste operazioni.“GetSystemsAndRaspi” interroga una funzione PHP locale chiamata “getCon-figuration.php” che rileva, da un file di configurazione presente nel webserver,il link del Core (cosı che per esigenze di installazione il Core possa essere spo-stato), il token di autenticazione e l’id dell’installazione; con questi dati vienepoi richiamata una API sul Core che restituisce sottoforma di Json tutti idispositivi presenti nell’installazione indicata e, per ognuno di questi, vienedefinita la struttura in torri attraverso la chiamata alle funzioni “addTower” e“addDeviceToTower”.

function getSystemsAndRaspi(){

$.ajax({

url: ’/scripts/getConfiguration.php’,

type: ’POST’,


success: function(res){

var key = res.key;


var id = res.id;

var server = res.server;

$.ajax({

url: server+’/getRaspiFromInstId/’,

type: ’GET’,

data: {key:key,instId:id},


success: function(resApi){

var tower = 0;

var i = 1;

if(resApi[0].result === "success"){

for(i=1; i<resApi.length;i++){

if(tower != resApi[i].tower){

tower = resApi[i].tower;

addTower(tower);

}

addDeviceToTower(tower,

resApi[i].name,

resApi[i].id,

resApi[i].color);

}

}

},

error: function(){

alert("Dati Errati API");

}

});

},

error: function(){

alert("Dati Errati");

}

});

}

Listato 3.12: Funzione GetSystemsAndRaspi

Le funzioni addTower e addDeviceToTower hanno lo scopo di generare la pa-gina modificando il codice HTML della stessa, per farlo utilizzano il metodo“append” che permette di aggiungere del codice dopo un dato elemento, nellafattispecie sono stati creati due elementi aventi come classe “towerContainer”per le torri e “deviceContainer” per i dispositivi.Una ulteriore problematica incontrata nell’interazione con oggetti creati dina-micamente e stata l’utilizzo del metodo “val” fornito da jQuery, questo metodonon e infatti utilizzabile in quanto la pagina viene creata dopo che il dom (ele-


mento che rappresenta il contenitore di tutta la pagina) e stato caricato, lasoluzione intrapresa prevede l’aggiunta di elementi nascosti con i dati necessa-ri inseriti all’interno del testo e recuperabili quindi attraverso il metodo “text”.

function addTower(towerId){

$(".towerContainer").append(

"<div id=’tower"+towerId+"’ class=\"col-xs-12 col-sm-6\">"+

"<fieldset class=\"colContainer\">"+

"<legend class=\"towerLegend \">Tower

"+towerId+"</legend>"+

"<div class=\"row\">"+

"<div class=\"deviceContainer\">"+

"</div>"+

"</div></fieldset></div>");

}

function addDeviceToTower(towerId,deviceName,deviceId,deviceColor){

var tower = "#tower"+towerId;

var device = "device"+deviceId;

$(tower).children().find(".deviceContainer").append(


"<div class=\"col-xs-12 device\">"+

"<form class=\"form-inline\" role=\"form\">"+

"<div class=\"col-xs-3 myDevIconCont\">"+

"<span>"+

"<img src=\"img/"+deviceColor+

"Icon.png\" aria-hidden=\"true\""+

"class=\"deviceIcon img-responsive\""+

" data-toggle=\"modal\" "+

"data-target=\"#myStatsModal\" "+

"alt=\"device icon\">"+

"<p class=\"hidden devId\">"+deviceId+"</p>"+

"</span></div>"+

"<div class=\"col-xs-9\">"+


"<div class=\"col-xs-12\">"+

"<p id=\""+device+"\" "+

"class=\"deviceInfo\">"+

"Device #"+deviceName+"</p>"+

"</div>"+

"</div>"+

"</form>"+

"</div>"+

"</div>");


setRaspiLastValues(deviceId,deviceName);

}

Listato 3.13: Funzioni AddTower e AddDeviceToTower

All’interno della homepage sono stati inseriti dei grafici cosi da permettere agliutenti di visualizzare in tempo reale lo stato di un particolare sensore o di unparticolare dispositivo; per lo sviluppo di questa sezione si e scelto di utilizzareun servizio gia presente sulla rete e gratuitamente offerto da Google chiamatoGoogle Charts[13].Attraverso i Google Charts e possibile disegnare dei grafici in funzione a unabase dati fornita con una particolare formattazione; nella pagina i grafici sonoinseriti all’interno di una modale e vengono quindi caricati in modo asincronoalla pressione del tasto, questo permette di ridurre il tempo di caricamentodella pagina anche se ovviamente rallenta leggermente l’apertura del graficostesso che andra quindi a comporsi nell’istante in cui l’utente ne richiede lavisione; la funzione che recupera i dati odierni dal Core e li passa a Google-Charts e chiamata “populateChart” ed e mostrata nel listato seguente, esisteinoltre una ulteriore funzione chiamata “populateChartFromTo” che si occu-pa di disegnare il grafico relativo ai valori in un range di tempo selezionatodall’utente e che prevede un funzionamento simile alla precedente.

$.ajax({

url: server+’/getTodayData/’,

type: ’GET’,

data: {key:key,id:sensorId},


success: function(resData){

if(resData[0].result === "success"){

var chartData = new google.visualization.DataTable();

var f=1;

chartData.addColumn("datetime","date");

chartData.addColumn("number",sensType+" Value");

for(f=1; f<resData.length;f++){

chartData.addRows(resData.length-1);

chartData.setCell(f-1,1,resData[f].value);

chartData.setCell(f-1,0,new

Date(resData[f].date));

}

google.charts.setOnLoadCallback(drawChart(chartData,

"curve_chart"));

$("#modalH3").text(sensType + " values");

}

},


error: function(){


}

});

Listato 3.14: Funzione populateChart

Gli script presenti all’interno della zona admin prevedono, a differenza diquanto accade nella homepage, che l’amministratore possa interagire in modoattivo con il sistema, da questa sezione e infatti possibile modificare la con-figurazione, aggiungere o rimuovere dispositivi. Il numero di script utilizzatisara quindi maggiore rispetto alla homepage e prevede un approccio simile aquanto analizzato basato su jQuery ed AJAX, un esempio e mostrato nel Li-stato 3.15 che mostra la procedura utilizzata per la rimozione da interfaccia eda database di un particolare dispositivo

function removeDevice(deviceId){

var id = deviceId.substring(7);

$.ajax({

url: ’/scripts/getConfiguration.php’,

type: ’POST’,


success: function(res){

var key = res.key;

var server = res.server;

var instId = res.id;

$.ajax({

url: server+’/editRaspi/’,

type: ’POST’,

data: {key:key,

id:id,

enable:0

},


success: function(resApi){

if(resApi != -1){

$(deviceId).remove();

}else{

alert("unable to remove");

}

},

error: function(){


}


});

},

error: function(){

alert("Dati Errati");

}

});

}

Listato 3.15: Rimozione di un dispositivo

3.3.2 Stile

Per lo sviluppo delle pagine si e scelto di utilizzare un approccio mobile-oriented, uno dei framework attualmente maggiormente utilizzati [19] per que-sta tipologia di progetti e Bootstrap, questo framework basato su delle librerieJavaScript e fogli di stile CSS prevede una suddivisione degli elementi compo-nenti la pagina in classi particolari.Il CSS viene suddiviso utilizzando delle “media query” che permettono di de-finire l’aspetto di un determinato elemento in funzione alla dimensione delloschermo, nell’esempio mostrato si puo notare come due elementi siano visualiz-zati in modo diverso nel caso in cui il dispositivo abbia un display con larghezzafino a 767pixel o su un display con larghezza compresa tra 768 e 991pixel.

@media (max-width: 767px) {

.containerLogin{

margin:2%;

}

.headerImg{

display:none;

}

}

@media (min-width: 768px) and (max-width: 991px) {

.containerLogin{

margin:4%;

}

.headerImg{

display:block;

}

}

Listato 3.16: Esempio di media query


Oltre a definire questa suddivisione tramite media query la particolarita diBootstrap risiede nel suddividere la pagina in una griglia[20] che, a secondadelle dimensioni dello schermo, potra essere:

xs: extra small

sm: small

md: medium

lg: large

questo tipo di concetto e stato inizialmente complesso da interpretare e da uti-lizzare in quanto gli elementi non vengono piu gestiti all’interno della paginain funzione al loro tipo ma principalmente per la classe a cui appartengono.Con Bootstrap la pagina viene quindi suddivisa in dodici colonne e, ogni ele-mento che la compone puo essere dimensionato utilizzando una o piu colonne,per migliorare l’adattabilita pero e inoltre possibile definire che un oggetto sialargo un quantitativo di colonne differente tra le varie tipologie di visualizza-zione evitando cosı posizionamenti erronei o sprechi di spazio, per fare cio enecessario quindi definire tutte queste particolarita in fase di progettazione edassociare poi ad ogni elemento le classi piu adatte. Tutti gli elementi che sitrovano all’interno di un oggetto avranno a loro volta una dimensione che potraandare da uno a dodici colone indifferentemente dalle dimensioni del padre, ladimensione pero in pixel di ogni colonna risultera inferiore alla corrispondentenel padre.Nell’esempio viene mostrato come una torre nella homepage abbia una di-mensione di dodici colonne in un display di piccole dimensioni “col-xs-12” maassuma poi una dimensione di sei colonne per display di dimensioni che van-no da small a salire “col-sm-6”, se non differentemente indicato le dimensionimaggiori ereditano la classe delle inferiori cosı che non serva obbligatoriamenteriscrivere la classe per ogni dimensione.Nello stesso esempio si puo notare la suddivisione per righe “row” utilizzatasolitamente con questo framework, questa suddivisione permette di meglio ge-stire il movimento degli oggetti al cambio di risoluzione.Un’ultima particolarita puo essere rilevata nell’oggetto immagine, in questo ca-so e presente un “data-toggle” che assegna all’immagine l’evento di comparsadi una form modale avente id “myStatsModal”.

<div id="tower2" class="col-xs-12 col-sm-6">

<fieldset class="colContainer">

<legend class="towerLegend ">Tower 2</legend>

<div class="row">

<div class="deviceContainer">


<div class="row">

<div class="col-xs-12 device">

<form class="form-inline" role="form">

<div class="col-xs-3 myDevIconCont">

<span>

<img src="img/greenIcon.png"

aria-hidden="true" class="deviceIcon

img-responsive" data-toggle="modal"

data-target="#myStatsModal" alt="device

icon">

<p class="hidden devId">10</p>

</span>

</div>

<div class="col-xs-9">

<div class="row">

<div class="col-xs-12">

<p id="device10"

class="deviceInfo">Device

#bohProva2</p>

</div>

</div>

</div>

</form>

</div>

</div>

</div>

</div>

</fieldset>

</div>

Listato 3.17: Utilizzo di bootstrap nella homepage

L’utilizzo di Bootstrap ha permesso di semplificare la creazione di un sito re-sponsive ma il design pensato per le varie pagine si discosta molto dagli stan-dard del framework, per ottenere quindi il risultato voluto e stato necessariocreare dei fogli di stile personalizzati che vengono caricati in cascata ai CSS diBootstrap cosı da essere applicati per ultimi agli elementi come da linguaggioCSS.Per non interferire con la struttura di Bootstrap si e inoltre deciso di utilizzare,ove possibile, delle classi personalizzate per ogni tipologia di elemento evitan-do quindi di usare le classi gia proprie del framework. La suddivisione dellostile e stata fatta in piu CSS in modo che ogni pagina carichi esclusivamentequanto necessario per la visualizzazione fatta eccezione per i contenuti comuni


quali testata e piede che si ripetono in entrambe le pagine. Anche per questielementi si sono utilizzate le media query cosi da rendere le pagine sempre cor-rettamente dimensionate; l’impatto grafico e l’usabilita da computer sono statiinoltre inseriti dei particolari effetti quando il mouse si trova su un elemento,un esempio e mostrato di seguito.

.deviceIcon:hover{

background-color:rgba(52, 175, 211,0.2);

}

.deviceInfo{

font-family: Roboto;

color: #34afd3;

font-weight: 500;

}

Listato 3.18: Esempio di stile sull’elemento con classe deviceIcon

3.4 Accessibilita

Grazie alle nuove tecnologie sempre piu persone hanno accesso alle pagineweb esistenti online, per questo e importante che queste siano fruibili dallamaggior parte di utenti possibile compreso chi possiede delle disabilita, attra-verso dei tool online [21] tutte le pagine create sono state rese compatibili conlo standard WCAG 2.0 (Web content accessibility guidelines) livello AAA che,su direttiva del W3C [22] (World wide web consortium) definisce quelle che solole linee guida per permettere l’accesso ai contenuti web anche per utenti chepresentano disabilita.

Capitolo 4

Valutazioni Finali

4.1 Analisi dei Risultati

L’intento di questa tesi era riuscire a dotare un cluster, formato da vari Ra-spberry Pi, di un sistema di monitoraggio utilizzando il quantitativo minimodi risorse e permettendo che il sistema potesse interagire con il mondo esterno.Analizzando la soluzione prodotta ritengo che il risultato voluto sia stato ot-tenuto, seppure ci sia spazio per ulteriori miglioramenti il software sviluppatopermette di effettuare il monitoraggio non solo di un cluster Raspberry ma ingenerale di un qualsiasi dispositivo o insieme di dispositivi basato su sistemaoperativo Linux. L’impatto prestazionale e stato, come da richieste, ridotto alminimo e cio permette quindi di essere applicato anche a dispositivi con risorselimitate (ad esempio Beagle Board).Utilizzando esclusivamente tecnologie open source la soluzione non prevedecosti derivanti da licenze o da contratti di manutenzione quindi puo ritenersia costo nullo se non quello dato dall’intervento umano per manutenere o am-pliare il sistema.Per finire ritengo sia soddisfatto anche l’intento di voler creare un progettoche definisse le basi da cui partire per lo studio e l’implementazione di nuovefunzionalita, la struttura modulare basata su un nucleo centrale permetterainfatti di sviluppare sempre nuove funzionalita o migliorare quelle esistenti.

4.2 Considerazioni

Personalmente ho trovato il percorso di realizzazione del progetto moltointeressante e formativo, dover sviluppare delle soluzioni su diversi ambiti del-la programmazione da quella web a quella piu a basso livello e su tipologiedi host piu disparati che vanno da piccoli dispositivi quali i Raspberry Pi a

47

48 CAPITOLO 4. VALUTAZIONI FINALI

server di maggiori dimensioni ha richiesto che io acquisissi nuove competenzee migliorassi quelle esistenti.Questo processo di crescita, soprattutto per lo sviluppo web, si nota chia-ramente valutando le differenze presenti tra i due siti web creati per questoprogetto, il primo per la gestione delle API key e molto piu standard ed utilizzaconcetti piu semplici , il secondo che rende il progetto visibile al pubblico hauna grafica completamente personalizzata ed utilizza delle interazioni moltopiu complesse.

4.3 Sviluppi futuri

Per questa tesi si era valutata la possibilita di sviluppare anche una appli-cazione per dispositivi mobili ma si e poi preferito concentrare maggiormentel’attenzione sulla creazione dell’infrastruttura permettendo comunque la frui-zione del progetto attraverso browser web anche su smartphone e tablet, lo svi-luppo di un’applicazione nativa potrebbe pero rappresentare una delle possibilievoluzioni del sistema con la possibilita anche di espandere questo pensiero adispositivi indossabili.Sarebbe inoltre interessante studiare ed implementare diverse tipologie di co-municazione tra il sistema e gli utenti utilizzando ad esempio email, SMS oaltri metodi.In ultimo si potrebbe valutare l’implementazione di questo sistema anche suinfrastrutture di maggiori dimensioni, infatti sviluppando un servizio per ilpolling di dispositivi Windows (utilizzando ad esempio Java o C#), potrebbeessere possibile monitorare tutti i computer presenti sulla rete, inoltre creandoun modulo che sfrutta il protocollo SNMP tale controllo potrebbe essere estesoa dispositivi di rete quali stampanti o switch.

Ringraziamenti

Vorrei ringraziare innanzitutto il mio relatore Gabriele d’Angelo per l’op-portunita offerta e la profonda dedizione che mette nel suo mestiere, la passioneche lo muove rende ogni studente orgoglioso di aver frequentato il suo corso.

Ringrazio Mariachiara per avermi sopportato e supportato sin dall’inizio inquesta avventura iniziata quasi per scherzo ma felicemente portata a termine.

Ringrazio l’azienda per cui lavoro che ha saputo sopportare i miei giorni diferie passati a lezione o sui libri.

Ringrazio infine gli “...Aspiranti ingegneri...”, abbiamo passato tre anni in-sieme in cui ci siamo conosciuti, siamo cresciuti ed insieme abbiamo affrontatoogni esame nella buona e nella cattiva sorte.

L’ultimo ringraziamento e forse il piu importante va al “Dream Team”ed alla “Somma e potente Chiara”, le sere passate assieme intorno ad untavolo e la loro amicizia sono state il carburante che e riuscito a portarmi qui,nonostante chi diceva che non ce l’avrei potuta fare, nonostante la stanchezzae gli impegni, gran parte del mio percorso e merito loro e non potro mairingraziarli a sufficienza, saranno per sempre i miei ragazzi che ho visto crescereed io saro per sempre “quello anziano”.

Grazie di cuore a tutti.

49

Appendice A

Elenco API

In questa sezione verranno elencate le API fornite dal Core e per ognunaverranno indicati i dati necessari ed il risultato aspettato. Per ognuna e in-dispensabile passare come argomento ”key” il token di autenticazione quinditale argomento verra tralasciato.

A.1 Getters

Tutte le API di tipo “getter” e che prevedono esclusivamente la lettura didati dal Core devono essere richieste tramite metodo GET.

A.1.1 getRaspi

Questa funzione fornisce uno specifico Raspberry o un elenco di Raspberry

Parametri

id rappresenta l’id dell’installazione richiesta (opzionale)

Risposta

in risposta viene restituito un Json con il campo “result” come primo ele-mento, il valore di questo elemento potra essere “error” in caso di errore o“success” se la ricerca ha dato esito positivo, in questo caso i seguenti datiseguiranno:

id identificativo del dispositivo

name nome del dispositivo

tower torre all’interno della quale il dispositivo e inserito

51

52 APPENDICE A. ELENCO API

position posizione occupata all’interno della torre

description descrizione del dispositivo (attualmente non utilizzata)

instId id dell’installazione a cui fa riferimento

color colore che dovra avere nella visualizzazione

A.1.2 getRaspiFromInstId

Questa funzione fornisce l’elenco dei Raspberry associati ad uno specificoid di installazione.

Parametri

instId rappresenta l’id dell’installazione richiesta

Risposta









A.1.3 getRaspiFromName

Questa funzione fornisce uno specifico Raspberry effettuandone la ricercaper nome.

Parametri

name rappresenta il nome del Raspberry da ricercare

APPENDICE A. ELENCO API 53

Risposta









A.1.4 getSensors

Questa funzione ritorna l’elenco dei sensori associati ad uno specifico Ra-spberry.

Parametri

id rappresenta l’id del Raspberry del quale si richiedono i sensori

Risposta


id identificativo del sensore

type codice rappresentante la tipologia di sensore

typeDesc descrizione della tipologia di sensore

description descrizione del sensore (attualmente non utilizzata)

fromValue valore minimo da cui il sensore si trova in stato di normalita

toValue valore massimo entro il quale il sensore si trova in stato di normalita


A.1.5 getData

Questa funzione restituisce l’elenco dei valori rilevati da un determinatosensore.

Parametri

id rappresenta l’id del sensore di cui si richiedono i rilevamenti

Risposta


id identificativo della rilevazione

sensorId id del sensore

value valore rilevato

date timestamp della rilevazione

A.1.6 getTodayData

Questa funzione fornisce le rilevazioni effettuate da un determinato sensorenelle ultime 24 ore, viene restituita solo una rilevazione ogni cinque per evitareun eccessivo quantitativo di dati, per avere un risultato completo vedere lafunzione getTodayDataFull.

Parametri


Risposta







A.1.7 getTodayDatFull

Questa funzione fornisce le rilevazioni effettuate da un determinato sensorenelle ultime 24 ore.

Parametri


Risposta






A.1.8 getFromToData

Questa funzione fornisce le rilevazioni effettuate da un determinato sensorein una fascia temporale specifica, il risultato ottenuto viene limitato ad unarilevazione su dieci per evitare quantitativi troppo elevati di dati, e comunquepresente la funzione getFromToDataFull per avere un risultato completo.

Parametri


from indica la data da cui si vogliono i dati

to indica la data fino alla quale si richiedono i dati


Risposta






A.1.9 getFromToDataFull

Questa funzione fornisce le rilevazioni effettuate da un determinato sensorein una fascia temporale specifica.

Parametri


from indica la data da cui si vogliono i dati

to indica la data fino alla quale si richiedono i dati

Risposta






A.1.10 getLastData

Questa funzione restituisce l’ultimo valore rilevato da un determinato sen-sore


Parametri

id rappresenta l’id del sensore di cui si richiedono il valore

Risposta






A.1.11 getConfiguration

Questa funzione restituisce i Parametri di configurazione di una determi-nata installazione

Parametri

id identifica l’id dell’installazione

Risposta


id identificativo dell’installazione

apiKey token assegnato a questa installazione

folder cartella nella quale il Controller dei dispositivi andra a cercare i file daanalizzare

twitterConsumerKey API key utilizzata per l’invio di messaggi su twitter

twitterConsumerSecret codice segreto utilizzato per le API


twitterAccessToken token utilizzato per l’invio di messaggi su twitter

twitterAccessTokenSecret codice segreto utilizzato per il token

twitterContactName nickname dell’amministratore del sistema

A.2 Setters

Tutte le API di tipo “setter” che prevedono cioe la scrittura di dati nelCore devono essere istanziate con metodo POST

A.2.1 addRaspi

Aggiunge un Raspberry al sistema.

Parametri




description descrizione del dispositivo



Risposta

verra restituito l’id del Raspberry aggiunto o -1 in caso di errore

A.2.2 addSensor

Aggiunge un sensore ad un Raspberry precedentemente creato

Parametri

raspId id del Raspberry a cui aggiungere il sensore

sensType id identificante la tipologia di sensore



from valore di soglia minimo per il sensore

to valore di soglia massimo per il sensore

Risposta

verra restituito l’id del sensore creato o -1 in caso di errore

A.2.3 addData

Permette di aggiungere un rilevamento ad un sensore.

Parametri

id identificativo del sensore


Risposta

verra restituito l’id dell’inserimento o -1 in caso di errore

A.2.4 editRaspi

Questa funzione permette di modificare un Raspberry precedentementecreato.

Parametri

Fatta esclusione per l’id tutti gli altri dati sono opzionali

id id del Raspberry





enable stato del dispositivo, 0 indica disattivo (e quindi non visibile) 1 indicaattivo e quindi visibile



Risposta

verra restituito 1 se la modifica ha avuto esito positivo o -1 se la modificaha avuto esito negativo

A.2.5 editSensor

Questa funzione permette di aggiornare un sensore precedentemente creato

Parametri

Fatta esclusione per l’id tutti gli altri dati sono opzionali

id id del sensore

description descrizione del sensore

type identificativo della tipologia di sensore

from valore di soglia minimo per il sensore

to valore di soglia massimo per il sensore

Risposta


A.2.6 moveSensor

Questa funzione permette di spostare un sensore da un Raspberry ad unaltro

Parametri

sensId id del sensore

raspId id del Raspberry di destinazione

Risposta



A.2.7 setEnvironment

Questa funziona imposta la configurazione di una determinata installazio-ne, se la configurazione non esiste verra creata con i Parametri inviati

Parametri

instId identificativo dell’installazione

apiKey token assegnato a questa installazione

folder cartella nella quale il Controller dei dispositivi andra a cercare i file daanalizzare

twitterConsumerKey API key utilizzata per l’invio di messaggi su twitter

twitterConsumerSecret codice segreto utilizzato per le API

twitterAccessToken token utilizzato per l’invio di messaggi su twitter

twitterAccessTokenSecret codice segreto utilizzato per il token

twitterContactName nickname dell’amministratore del sistema

Risposta


Appendice B

Guida all’installazione

B.1 Pre-Requisiti

Questo progetto e stato sviluppato in ambiente Linux prevedendo princi-palmente l’utilizzo di due tecnologie:

JVM (Java virtual machine): sul server di polling

Web: su API e GUI

e quindi necessario che prima di procedere all’installazione del sistema si veri-fichi che i seguenti prerequisiti siano soddisfatti.

B.1.1 JVM

Sul server che ricevera i dati dai Raspberry e che ne effettuera l’invio alCore e necessario verificare che sia correttamente installato Java, per fare cio esufficiente eseguire da console il comando “java -version”, la versione minimarichiesta e la 7 e quindi il comando dovrebbe dare un esito come quello indicatoin figura

63

64 APPENDICE B. GUIDA ALL’INSTALLAZIONE

Figura B.1: Versione di Java installata

nel caso in cui venga visualizzato un errore indicante “comando non tro-vato” sara necessario effettuare l’installazione dell’ambiente Java denominato“JRE”(Java runtime environment); in distribuzioni basate su kernel debian esufficiente eseguire il comando “sudo apt-get install default-jre”.

B.1.2 Web

Molti dei moduli sviluppati sono basati su tecnologie web, per fare cio equindi necessario verificare per ognuno di essi che i seguenti prerequisiti sianosoddisfatti.

Server Web

E necessario innanzitutto che sia installato un web server, in ambiente Li-nux i piu comuni sono Apache[23] e Nginx[24] per la cui installazione si rimandaalle rispettive guide fornite dai produttori.

DBMS

Dovendo immagazzinare dei dati questo progetto necessita di un DBMS(Database management system), tutto lo sviluppo e stato effettuato utilizzan-do il DBMS relazionale MySql[25], per l’utilizzo con altri RDBMS sara neces-sario analizzare ed adattare query ed oggetti utilizzati per la connessione aidatabase.Per verificare che MySql sia correttamente installato digitare il comando “my-sql –version”.

APPENDICE B. GUIDA ALL’INSTALLAZIONE 65

Nel caso in cui sia necessario effettuarne l’installazione in un ambiente conkernel Debian e sufficiente digitare i seguenti comandi:

sudo apt-get update

sudo apt-get install mysql-server libapache2-mod-auth-mysql

php5-mysql

Listato B.1: Installazione Mysql

Per altri ambienti si rimanda invece alle guide disponibili sul sito di MySql[27].

PHP

Verificare che sul server sia installato PHP almeno alla versione 5, pereffettuare questa verifica e sufficiente, da console, digitare il comando “php-version” ed identificare la versione installata come da figura

Figura B.2: Versione di PHP installata

Nel caso in cui venga utilizatto Apache e inoltre necessario accertarsi che ilmodulo “mod rewrite” sia attivo, per fare cio e sufficiente creare una file PHPcon il seguente codice:

<?php

phpinfo();

?>

Listato B.2: Php Info

aprendo da browser web la pagina corrispondente verranno mostrate delle in-formazioni dettagliate dell’installazione PHP che si sta utilizzando, nella sezio-ne “loaded modules” dovrebbe essere mostrato come da Figura B.3 il suddetto


modulo.

Figura B.3: Moduli Attivi

Nel caso in cui il modulo non risulti effettivamente attivo e possibile abili-tarlo digitando il comando “a2enmod rewrite”.Per permetterne il corretto funzionamento e necessario che alcune funzioni al-l’interno della configurazione del server web siano correttamente configurate,nel Listato B.3 e indicato il codice necessario a permettere innanzitutto l’e-secuzione dello script di istruzione del modulo, questa configurazione e legataesclusivamente alla cartella in cui il modulo deve essere utilizzato.

<Directory "/var/www/wss/">

Options Indexes FollowSymLinks

AllowOverride All

Allow from All

</Directory>

Listato B.3: Particolare del file di configurazione di Apache

Lo script di istruzione andra composto all’interno del file “.htaccess” ed ilcodice necessario e il seguente:

RewriteEngine On

RewriteCond %{REQUEST_FILENAME} !-f

RewriteRule ^(.*)$ /wss/index.php [QSA,L]

Listato B.4: File .htaccess utilizzato

Nel caso in cui si preferisca utilizzare come server web Nginx sara necessariomodificare la configurazione del sistema inserendo la seguente direttiva:

location / {

if (!-e $request_filename){

rewrite ^(.*)$ /wss/index.php break;

}

Listato B.5: Rewrite rule Nginx


Si consiglia inoltre di installare un tool di gestione del database basato suPHP come ad esempio phpMyAdmin[25], questo permettera una piu agevolemanutenzione dei database.

B.2 Installazione

Nelle pagine a seguire verranno indicati i passaggi necessari all’installazionedell’intero sistema, per semplicita si e scelto di effettuare una suddivisione dellaguida e dei file di installazione intorno ai moduli sviluppati.Tutto il materiale necessario all’installazione e inoltre disponibile sul repositorydel progetto [29].

B.2.1 Admin

Per permettere il funzionamento della parte admin e necessario innanzi-tutto installare il database corrispondente, all’interno della cartella “databa-se” e presente il file “apiKeys.sql” che contiene tutti i comandi necessari allacreazione del database ed al popolamento dello stesso con dei dati di provainiziali.

1. accedere a phpMyAdmin

2. autenticarsi con le credenziali di MySql

3. andare nella sezione “importa”

4. nella sezione “File Da Importare” premere sfoglia e selezionare il fileapiKeys.sql

5. premere il tasto “Esegui” lasciando invariato il resto del contenuto

E necessario ora procedere alla configurazione dei parametri necessari a far sıche le pagine PHP e gli script che compongono questo sito possano corretta-mente interagire con il database.

1. entrare all’interno della cartella “website\inc”

2. aprire il file “settings.php” con un editor di testo

3. configurare i parametri al suo interno indicando:

db server: nome o indirizzo del server DBMS


db user: nome di un utente con privilegi di lettura e scrittura sul da-tabase

db pass: password per l’utente indicato

db name: nome del database da utilizzare, questo valore dovrebbe ri-manere invariato nel caso in cui sia stata utilizzata la proceduraautomatizzata di creazione del database

referrer: indicare l’url a cui il sito rispondera, questo dato e fondamen-tale per il corretto accesso al sistema

4. salvare il file e chiudere l’editor

Terminata la configurazione di database e parametri di connessione e pos-sibile proseguire posizionando i file necessari all’interno del server web chedovra rendere disponibile questo modulo, per fare cio e sufficiente copiare l’in-tero contenuto della cartella “website” all’interno del server stesso.E ora possibile verificare il corretto funzionamento del sistema, per fare cioaccedere all’url indicato precedentemente nel campo “referrer” e digitare comecredenziali di accesso:

Username: admin

Password: admin

se la configurazione e stata effettuata correttamente si verra reindirizzati allapagina in cui gestire le api key di autenticazione. In caso contrario verificare ilog del server web per identificare il problema.Se la configurazione ha avuto esito positivo si consiglia di creare immediata-mente una nuova API e disabilitare quella inserita di default, tale chiave sarapoi necessaria nei passaggi successivi.

B.2.2 WSS

Per permettere il funzionamento di questa parte e fondamentale innanzi-tutto che sia stato configurato correttamente il modulo “Admin” in quantoentrambe le parti condividono un database. All’interno della cartella “data-base” e presente il file “raspeinModel.sql” in cui sono presenti tutti i comandinecessari alla creazione del database delle API fornite, effettuarne l’importseguendo i seguenti passaggi:





4. nella sezione “File Da Importare” premere sfoglia e selezionare il fileraspeinModel.sql


Come precedentemente fatto e ora necessario configurare attraverso un editordi testo il file “settings.php” presente all’interno del percorso “website\inc”, iparametri necessari sono:

db api server: nome o ip del server in cui e installato il db contenente le apikey

db api username: nome di un utente con privilegi di lettura sul precedentedatabase

db api password: password dell’utente precedentemente indicato

db api db: nome del database in cui sono salvate le api key

db model server: nome del server in cui e stato installato il database “ra-speinModel”

db model username: nome di un utente con privilegi di lettura e scritturasul database raspeinModel

db model password: password dell’utente appena indicato

db model db: nome del database che si desidera utilizzare in alternativa araspeinModel

Al termine di questa configurazione e possibile spostare tutto il contenutodella cartella “website” all’interno del server web che fornira le funzionalita delCore, e importante verificare che questo server sia accessibile tramite protocollohttp o https dagli altri moduli, in caso contrario il sistema non sara funzionante.Questo modulo fa uso delle funzionalita di rewrite quindi e necessario verificareche la configurazione sia stata effettuata correttamente, per fare cio e possibilerichiedere l’API “getConfiguration” digitando l’url“http://url del server/wss/getConfiguration” senza indicare alcun parametro;il browser dovrebbe indicare “Errore 500”, questo significa che il modulo hafunzionato correttamente in quanto l’url e stato identificato e passato alle APIche pero non hanno potuto verificare l’autenticazione in quanto non e statoinviato il token di autenticazione.


B.2.3 Polling e Comunicazione

Terminate le precedenti configurazioni si puo passare alla parte riguardantei moduli di polling e comunicazione, per il funzionamento di questi moduli einnanzitutto necessario verificare che il server adibito alla loro esecuzione abbiaaccesso verso l’esterno in quanto deve poter interagire con le API di Twitter.E inoltre necessario creare un’applicazione twitter attraverso l’apposito portale[30],sara questa a permettere l’invio di messaggi attraverso il social network.

Device

Nei dispositivi da controllare e necessario innanzitutto creare uno scriptbash che rilevi i valori da monitorare e li salvi su un file che possa essereletto dal server, per semplicita e stato gia creato un file di esempio, e possibiletrovarlo all’interno del percorso “Polling e Comunicazione\Device” con il nomemonBatch.sh.Per ogni dispositivo lo script andra modificato indicando:

DEVICENAME: nome del dispositivo

DIRECTORY: destinazione del file in cui salvare il risultato, questa direc-tory deve essere accessibile al server di polling

Per terminare e necessario configurare crontab attraverso il comando “crontab-e” in modo che esegua lo script appena creato in modo periodico, un esempioe il seguente che mostra cosa indicare per effettuare una esecuzione costantecon periodo di 5 minuti.

#run mon batch every 5 min

*/5 * * * * /home/pi/Documents/RaspeinMon/monBatch.sh

Listato B.6: Esempio di crontab

Server

Per poter funzionare la parte server necessita che sia messo in esecuzio-ne un file jar, il modo piu comodo per fare questo e creare un demone daavviare all’accensione del server. Innanzitutto e necessario configurare il file“settings.conf” indicando:

ApiKey: il token da utilizzare per autenticarsi con il Core

ServerName: url al quale risponde il Core

instID: id dell’installazione che si intende utilizzare


Posizionare quindi il file all’interno della cartella “/root” del server e rinomi-narlo in “.settings.conf”.Se si ha dimestichezza con la creazione di servizi in sistemi Linux sara neces-sario creare un demone appunto che esegua il file jar contenuto nella cartella.Nel caso in cui invece non si abbia tale dimestichezza eseguire i seguentipassaggi:

1. copiare i file “deviceMonitor” e “deviceMonitor.jar” all’interno della car-tella “/etc/init.d”

2. eseguire il comando “update-rc.d deviceMonitor defaults”

Cosı facendo si e creato un servizio secondo i parametri inseriti all’interno delfile “deviceMonitor” che, all’avvio del server, esegue il file “deviceMonitor.jar”,come per gli altri servizi sono disponibili i comandi stop/start/restart.

B.2.4 GUI

La GUI di questo progetto e sviluppata quasi completamente utilizzandodegli script jQuery e delle funzioni AJAX, si e scelto pero di utilizzare un’au-tenticazione basata su utenti presenti in un database per poter accedere allaparte privata, sara quindi necessario creare un piccolo database in cui inserireamministratori e relative credenziali.




4. nella sezione “File Da Importare” premere sfoglia e selezionare il fileraspeinWeb.sql


Configurare quindi il file “include.php” presente all’interno della cartella “web-site\inc”, i parametri necessari sono:

dbUser: utente con privilegi di lettura sul database

dbPass: password dell’utente

dbServer: indirizzo del server su cui e installato il database

dbName: nome del database da utilizzare, se si utilizza quello precedente-mente creato non e necessario sostituire questa parte


instId: id relativo all’installazione presente sul Core, se e la prima effettuatalasciare il valore “1”

apiKey: chiave da utilizzare per autenticarsi al Core

apiServer: url a cui accedere per interagire con il Core

Al termine della configurazione sara sufficiente copiare tutti i file presenti al-l’interno della cartella “website” nel server web che eseguira questo modulo.Le credenziali da utilizzare per accedere alla pagina di configurazione sono:

Username: admin

Password: admin

B.3 Configurazione

Terminata l’installazione sara necessario accedere alla GUI ed iniziare aconfigurare il sistema, per fare cio entrare nella sezione admin e configurareinnanzitutto la parte “System”, in questa sezione bisognera indicare:

• percorso sul server di polling in cui vengono salvati i file dei dispositivi

• dati relativi alle chiavi dell’applicazione creata su Twitter

• contatto Twitter dell’amministratore

una volta terminata questa parte sara possibile aggiungere le varie torri etutti i dispositivi presenti al loro interno, il nome di ognuno di essi andra poiindicato nel rispettivo file di configurazione cosı che i dati rilevati venganocorrettamente associati.

Sitografia

[1] Gabriele D’Angelo, Rapein Project, http://pads.cs.unibo.it/doku.php?id=raspein:index

[2] Zoho Corp, Site24x7 Logo, http://www.site24x7.com

[3] Nagios Enterprises Nagios Logo, http://www.nagios.org

[4] Nagios Enterprises, Nagios Quickstart Installation Guides,https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/4/en/quickstart.html

[5] Egalstad, NRPE - Nagios Remote Plugin Executor ,https://exchange.nagios.org/directory/Addons/Monitoring-Agents/NRPE–2D-Nagios-Remote-Plugin-Executor/details

[6] Javier Bello, Top 15 best network monitoring tools for 2016,http://blog.pandorafms.org/network-monitoring-tools/

[7] Zabbix SIA, Zabbix Logo, http://www.zabbix.com

[8] Zabbix SIA, Zabbix documentation - quickstart,https://www.zabbix.com/documentation/3.0/manual/quickstart

[9] Stefano Falzaresi, Raspein Monitor onTwitter,https://twitter.com/raspeinmonitor

[10] Anonimo, Bootstrap Homepage,http://getbootstrap.com

[11] W3Schools, CSS3 Introduction,http://www.w3schools.com/css/css3 intro.asp

[12] jQuery Foundation, jQuery API,http://api.jquery.com/

[13] Google Developers, Google Charts Homepa-ge,https://developers.google.com/chart/

[14] Stefano Falzaresi, Raspein homepage,http://raspein.stestaz.com/

[15] Stefano Falzaresi, Raspein admin pa-ge,http://raspein.stestaz.com/admin.php

73

74 SITOGRAFIA

[16] Apache Software Foundation, Apache Modulemod rewrite,https://httpd.apache.org/docs/current/mod/mod rewrite.html

[17] HTML.it, Riscrivere gli URL con il modulomod rewrite,http://www.html.it/articoli/riscrivere-gli-url-con-il-modulo-modrewrite-di-apache-3/

[18] Anonimo, Twitter4j Project,http://twitter4j.org/en/index.html

[19] Q-Success, Historical trends in the usage of JavaScript libraries for websi-tes,https://w3techs.com/technologies/history overview/javascript library/all

[20] Anonimo, Bootstrap CSS overview,http://getbootstrap.com/css/

[21] Achecker, Bootstrap Web accessibility chec-ker,http://achecker.ca/checker/index.php

[22] W3C, W3C website, https://www.w3.org/

[23] Apache Software Foundation, Apache HTTP Server Project,https://httpd.apache.org/

[24] Nginx Inc., Nginx, http://nginx.org/

[25] Oracle, MySql Homepage, http://mysql.com/

[26] PostgreSQL Global Development Group , PostgreSQL,https://www.postgresql.org/

[27] Oracle , MySql Downloads ans repositories,http://www.mysql.com/downloads/

[28] phpMyAdmin , Bringing MySQL to the web,https://www.phpmyadmin.net/

[29] Stefano Falzaresi , Monitorize Project Repository,https://github.com/stestaz/monitorize.git

[30] Twitter Inc, Application Management , https://apps.twitter.com/