Università degli Studi di Napoli Federico II

Transcript

1 Università degli Studi di Napoli Federico II Facoltà di Scienze MM.FF.NN. Corso di Laurea in Informatica Tesi Sperimentale di Laurea Triennale Implementazione di un modulo per l'autenticazione degli utenti unina su portale di monitoraggio della rete di Ateneo Relatori Candidato Prof. Guido Russo Dr. Ing. Catello Di Martino Anno accademico 2009/2010 Pisa Marco Matricola: 873/15

2 Desidero ringraziare... Il prof. G. Russo e all'ing. C. Di Martino per l'opportunita che mi hanno dato e per il supporto umano e professionale che mi hanno messo a disposizione durante tutto lo svolgimento del tirocinio I miei genitori, mio fratello e la mia ragazza per avermi sostenuto in questa esperienza di vita. Tutti gli amici, colleghi del corso di laurea e del centro ScoPe, in particolare Enzo e Nicola che mi sostenuto e condiviso questa esperienza E tutte le persone a me care che hanno creduto in me, e mi hanno sostenuto. Un GRAZIE a tutti

3 Indice 1 Introduzione Monitoraggio & Porting Il Portale wifed.scope.unina.it Architettura del Portale: I Servizi Offerti LAMPP: Linux, Apache, Mysql, Php, Perl CMS Joomla Monitoraggio della rete Protocollo SNMP Cacti Rrdtool : Round-Robin Database Tool Porting del Portale Requisiti per il Porting Virtual Machine: Vmware Wifed.scope.unina.it: porting Wifed02.scope.unina.it: porting Wifed03.scope.unina.it : Guida al Porting Statistiche Wi-Fi : Porting del Servizio Gestione dell'accesso Autenticazione di un Utente Il Protocollo Ldap Ldap: di unina CMS Joomla:struttura sviluppatore Struttura del CMS Joomla Componenti Moduli Plug-in Scelta di Implementare il progetto tramite il Plugin di joomla Interfacciarsi con i server Ldap di unina Perchè un Web Service? Web Service di unina Progetto: Autenticazione tramite Ldap nel CMS Joomla Analisi dei requisiti Realizzazione Prototipo Progettazione Problematiche riscontrate Scelte Progettuali Casi D'uso Diagrammi delle classi Diagrammi di Sequenza Implementazione Conclusioni Appendice...66 Pagina 3 di 127

4 6.1 Codice Sorgente Codice plugin File xml di configurazione Guida alla configurazione del Plug-in How To Installazione Lamp: Cacti Tomcat Tomcat : installazione modulo Axis Vmware: installazione "player"&"workstation" Vmware: creare un virtual machine con OS Ubuntu Joomla: installazione & configurazione Ripristino dei servizio di Statistiche del Portale Wifed Bibliografia Sitografia Pagina 4 di 127

5 1 Introduzione L'obbiettivo del lavoro realizzato durante il periodo di tirocinio, consiste nell'apprendere conoscenze, esperienza e familiarità con gli strumenti di lavoro usati al centro Scope "Controll Room", sede del mio tirocinio. Per raggiungere questo obbiettivo, mi sono stati affidati due progetti, uno nell'ambito del monitoraggio, l'altro nell'ambito delle tecnologie web. I due progetti (o lavori) sono: il porting su macchine virtuali del portale "wifed" e la creazione di un plug-in per autenticarsi su un server Ldap esterno al portale web, per la precisione il server ldap è quello di unina. Questo per permettere a qualsiasi studente di unina di Autenticarsi sul nostro portale wifed. Questi lavori, si collocano nell'ambito dell'iniziativa "WiFiSud" del progetto "ICT4 University" che realizza quanto previsto dall'obbiettivo Università del Piano E-Gov In particolare l'iniziativa ha previsto il finanziamento di progetti delle università del sud per realizzare, estendere o completare reti di connettività senza fili e sviluppare servizi on-line di tipo amministrativo e/o didattico, accessibili gratuitamente da parte degli studenti. La tesi affronta, quindi, due argomenti fondamentali: le problematiche affrontate durante il porting del portale wifed sulle macchine virtuali e la creazione del plugin per l'autenticazione di un utente con credenziali unina. I problemi maggiori riscontrati durante il lavoro di Porting del portale "wifed" sono stati la scarsa conoscenza e la difficoltà nell'analisi dei servizi offerti, che erano molti e dislocati in tre macchine fisiche, difficile capire chi monitorasse cosa. Queste difficoltà derivano anche dalla scarsa conoscenza dei tool utilizzati per creare i vari servizi di monitoraggio. Lo scopo del porting, e quello di svincolare il software dell'hardwar, utilizzando le Virtul Machine. Inizialmente i servizi del portale erano dislocati in tre macchine fisiche, che sono state riprodotte in tre macchine virtuali, che risiedono ora Pagina 5 di 127

6 su una sola macchina server dedicata. La configurazione delle tre macchine virtuali e identica alle tre macchine fisiche, salvo per una differenza: si è deciso di utilizzare come sistema operativo Ubuntu Server Per riuscire a effettuare il porting, si è dovuto accrescere la conoscenza di alcuni strumenti di lavoro come: cacti,bash,script perl. Un piccolo aiuto è arrivato dalle tesi dei colleghi che hanno creato il portale con i relativi servizi. L'altro lavoro svolto e stato quello di creare un plugin che, integrato al CMS Joomla, permettesse allo stesso di autenticare un utente con le credenziali unina. Quindi questo plugin doveva effettuare un interrogazione ai server Ldap di unina, per controllare le credenziali inserite dall'utente. Per motivi di sicurezza, unina ci ha permesso di interrogare i loro server tramite un web service, che viene già sfruttata da altre strutture che utilizzano le credenziali unina, per autenticare i propri utenti. La ricca documentazione fornita in allegato al framework del cms joomla, è stata di enorme aiuto alla comprensione della struttura dello stesso. Durante la fase di implementazione del plugin, sono stati effettuati molti test in un ambiente simulato, per non creare problemi al web service di unina. Il codice realmente scritto non è molto, ma l'analisi del core di joomla effettuata ha richiesto molto tempo. Il tipo di plugin implementato, può essere riutilizzato in qualsiasi altro ambiente che sia scritto in php. Nel prossimo capitolo inizieremo a descrivere l'ambiente di lavoro creato per effettuare il Porting del portale "Wifed". Pagina 6 di 127

7 2 Monitoraggio & Porting In questo capitolo come già anticipato nel precedente, parlerò dell'ambiente di lavoro e degli strumenti usati per effettuare il porting del portale, iniziando conl'analisi dettagliata dei servizi offerti e della loro locazione sulle macchine del centro scope "controll Room". 2.1 Il Portale wifed.scope.unina.it Premetto che il portale è stato realizzato da altri colleghi, quindi ho analizzato in dettaglio la struttura per riuscire poi a replicarla su altre macchine. È stato usato il CMS Joomla per facilitare la gestione delle pagine e la rappresentazione grafica delle informazioni da mostrare al pubblico. È possibile effettuare piccole e veloci modifiche al portale da remoto, utilizzando delle credenziali di amministrazione, grazie alla natura del CMS, in quanto possiede un'interfaccia di gestione dei contenuti. Anche per le statistiche wi-fi c'è un interfaccia web di amministrazione da remoto. Il compito del portale è offrire all'utenza, nel caso specifico gli studenti, lo stato della rete universitaria, sia wi-fi che wired. Inoltre mostra anche le statistiche sulla sola rete wi-fi. I dati che vengono raccolti e messi a disposizione sotto forma di grafici sono moltissimi, tra cui il numero di client (pc collegati) collegati alla rete wi-fi, il numero di Access Point attivi in quel momento, il livello di traffico sui protocolli TCP, UDP e molti altri. Lo strumento usato, che permette il monitoraggio di tutti questi dati è "cacti" con licenza "open source", che usa il protocollo SNMP per effettuare la raccolta dati e rrdtool per memorizzarli e interpretarli. Al momento ci sono solo Pagina 7 di 127

8 quattro zone sotto monitoraggio: Monte Sant'Angelo (Chimica, Matematica, Aulario, Centri Comuni), Ingegneria (Via Claudio, P.le Tecchio, Agnano), Zona Ospedaliera (pansolini) e il Centro Storico. Il portale web "wifed" fa uso delle più aggiornate tecnologie web al momento in uso, tra cui possiamo vedere : Html4, Css2, Lamp, CMS joomla, Perl, bash e moltri altri strumenti Architettura del Portale: I Servizi Offerti Il portale wifed, è composto da tre gruppi di servizi : monitoraggio wi-fi, monitoraggio wired, statistiche wi-fi. I tre gruppi di servizi sono stati sviluppati da tre colleghi differenti. È questo il motivo principale per il quale il portale risiedeva, prima del porting, su tre macchine differenti. Le macchine sono così chiamate: wifed, wifed02, wifed03. La prima si occupa di mascherare la sotto struttura, caricando poi il CMS in un "iframe" all'interno della pagina principale, in questo modo si mascherano tutte le richieste. La seconda si occupa del monitoraggio wi-fi, sia della creazione dei grafici, sia della strutturazione e visualizzazione dei dati raccolti. La terza macchina si occupa di ospitare il cms e di monitorare la "wired", di prendere i dati statistici della wi-fi e di mostrarli su richiesta. Inoltre si occupa anche di girare le richieste sul monitoraggio della wi-fi sulla macchina "wifed02". Pagina 8 di 127

9 La figura seguente vi mostra come era dislocato il portale e come erano divisi i servizi offerti. Figura 1: Struttura delle Macchine e Sintesi dei Servizi Offerti Pagina 9 di 127

10 Di seguito invece mostriamo come è ora localizzato il portale. Figura 2: Nuova Struttura delle Macchine e Sintesi dei Servizi Offerti Pagina 10 di 127

11 Schematizziamo come ora sono divisi i vari servizi: net-mon.scope.unina.it: contiene tutte le virtual machine VM - Wifed.scope.unina.it: Maschera tutta la struttura del portale tramite un "iframe". VM - Wifed02.scope.unina.it: Monitoraggio wi-fi della zona Monte Sant'Angelo, Ingegnaria, Zona Ospedaliera, Centro Storico. Applicativo "Server" delle Statistiche Wi-Fi. VM - Wifed03.scope.unina.it: Monitoraggio Wi-Red della zona Monte Sant'Angelo, Ingegneria, Centro Storico, Zona Ospedaliera. Monitorando il traffico in entrate e uscita. Applicativo "Client" delle statistiche Wi-Fi. Portale Web, creato tramite CMS joomla. Interfaccia Web delle statistiche Wi-Fi. Pagina 11 di 127

12 2.1.2 LAMPP: Linux, Apache, Mysql, Php, Perl LAMP è un acronimo che indica una piattaforma per lo sviluppo di applicazioni web che prende il nome dalle iniziali dei componenti software con cui è realizzata. Lamp sta ad indicare appunto Linux, Apache, Mysql, Php. Sulle nostre macchine c'è la variante che contiene anche Perl. La piattaforma LAMP è una delle più utilizzate a livello mondiale. Ognuna delle applicazioni dalle quali è composta è predisposta per l'eccellente funzionamento in concomitanza con le altre. - Linux : Sistema Operativo - Apache: Web Server -Mysql : Database management system (o database server); -Php : Linguaggio di scripting per programmazione web lato server -Perl : Linguaggio di programmazione alti livello CMS Joomla Cosè un CMS? Un content management system, in acronimo CMS, letteralmente "sistema di gestione dei contenuti", è uno strumento software installato su un server web studiato per facilitare la gestione dei contenuti di siti web, svincolando l'amministratore da conoscenze tecniche di programmazione Web. Joomla è un software di content management per siti web, realizzato completamente nel linguaggio PHP. È pubblicato con licenza open source GNU GPL v.2 Joomla è uno dei pochi CMS completamente modulari, cioè e composto da estensioni (o moduli) i quali permettono di accrescere le funzionailtà di base del CMS. Le componenti fondamentali di questo cms sono: Template,Core di joomla; le estensioni vengono agganciate tramite il core per poter essere interfacciate con il Pagina 12 di 127

13 template. Per template si intende una struttura grafica base, come mostrato in figura, e la stilizazzione delle varie parti che lo compongono. Figura 3: Template bse di joomla. Ad ogni parte del template viene impostato uno stile ben preciso, che verrà mantenuto anche se si inserisce una nuova estensione. Per estensioni si intendono script php completi che offrono nuove funzionalità da agganciare al core in qualsiasi parte del template, non comprendono al loro interno istruzioni grafiche, le stesse vengono delegate al template. A loro volte le estensioni si dividono in tre elementi distinti, in base a quanto sono indipendenti o quanto modificano una funzionalità già esistente nel CMS Joomla. Più avanti parleremo in modo più approfondito di questo strumento, per capire come integrare un plug-in. Pagina 13 di 127

14 2.2 Monitoraggio della rete I servizi offerti dal portale sono messi a disposizione grazie al CMS joomla, come già detto precedentemente, ma vengono resi disponibili grazie all'azione di monitoraggio effettuato da altri strumenti, come rrdtool e cacti. Anche loro per poter lavorare necessitano del sistema Lamp e di altri strumenti. Una corretta valutazione dello stato di un sistema complesso è alla base del processo di manutenzione, gestione ed evoluzione del sistema stesso. Il monitoraggio dunque svolge un ruolo di primaria importanza nella vita ed evoluzione del sistema. I monitoraggi attivi, raccolgono informazioni sullo stato della rete attraverso interrogazioni periodiche fatte ai vari apparati che si vogliono monitorare. In tale ambito, il protocollo maggiormente utilizzato è quello SNMP, che è anche quello usato dai nostri servizi di monitoraggio. Di seguito parleremo in modo più dettagliato dei tre strumenti usati per il monitoraggio: SNMP, Cacti, RrdTool. Pagina 14 di 127

15 2.2.1 Protocollo SNMP Simple Network Management Protocol (SNMP) appartiene alla suite di protocolli Internet definita dalla IETF (Internet Engineering Task Force). Il protocollo opera al livello 7 del modello OSI. Esso consente di effettuare interrogazioni, controllli nonchè gestire il funzionamento degli elementi di una rete che sfrutta il protocollo IP, per essere identificato. Fino ad oggi sono in circolazione tre Standard di snmp, venendo identificati tra loro in base alla versione (v1,v2,v3).la SNMPv2 venne creata per migliorare, in linea generale, la prima versione, la SNMPv3 create per migliorare l'aspetto sulla sicurezza. L'SNMP è un protocollo che usa UDP come protocollo di trasporto. E' stato preferito il protocollo UDP a TCP per minimizare l'aumento del traffico dovuto alle comunicazioni fatti al dispositivo. Non è stato scelto il protocollo TCP essendo orientato alla connessione richiede più risorse di rete. L'aspetto negativo derivante dall'uso del protocollo UDP è che non si ha la certezza che il messaggio arrivi a destinazione. Inoltre è stato scelto questo protocollo poichè l' SNMP è nato per gestire e monitorare le prestazioni di rete e un'eventuale congestione di quest'ultima, sarebbe aggravata dall'utilizzo di TCP. Internet Network Management Framework (SNMP), è composta da tre componenti fondamentali : Le apparecchiature gestite (managed devices) sono degli elementi di rete (ponti, hub, router o server), che contengono degli "oggetti di gestione" (managed objects) da dove vengono estrapolate le informazioni sull'apparato; Gli agenti (management agent ), cioè un'applicazione di gestione di rete che risiede in una periferica e incaricata di trasmettere i dati locali di gestione della periferica in formato SNMP; Pagina 15 di 127

16 I sistemi di management della rete (network management systems sigla NMS o manger), cioè una console attraverso la quale gli amministratori possono realizzare dei compiti amministrativi. Il manager rappresenta l'applicazione remota che avvia il programma che gestisce SNMP. I sistemi gestiti a loro volta, sono dotati di un programma di management agent, ospitano quindi un agente di gestione. Il management agent, si frappone tra il manager e il managed devices, per permettere la comunicazione tramite il protocollo snmp. Il management agent è anche responsabile dell'accesso alla base di dati MIB. Il funzionamento di SNMP è molto semplice. La piattaforma della gestione di rete invia interrogazioni all'agente, quest'ultimo a sua volta risponde. Interrogazioni e risposte si riferiscono a variabili accessibili solo da parte del management agent. Le variabili d'agente sono memorizzate nella base di dati chiamata MIB, il management agent recupera le variabili nella MIB utilizzando un identificativo ( OID Object ID ), che è organizzato gerarchicamente Cacti Cacti è un sistema web-based di statistiche sui servizi che consente di tenere sotto controllo lo stato dei sistemi raggiungibili sulla rete. Questo è il sistema scelto dai miei predecessori per monitorare la rete. Le strutture principali sono: I grafici: possono essere a barre o composti da linee, possono rappresentare i dati tramite diverse scale o presentare leggende e sintesi testuali delle informazioni. I device: sono le apparecchiature da controllare, server, stampati o stazioni sismiche. Esistono decine di test che possono essere usati per controllarne il funzionamento. I data source: sono le sorgenti dati o ancora meglio l insieme delle tecniche Pagina 16 di 127

17 usate per collezionare le informazioni dalle macchine. Scritto interamente in php, linguaggio di scripting, fa di lui uno strumento leggero facile da usare e molto potente dal punto di vista della flessibilità. Il sistema si appoggia ad altri strumeni per funzionare: Net-SNMP, per le interrogazioni SNMP; RRDTool, per la persistenza dei dati frutto di monitoraggio e la loro presentazione per mezzo di grafici; piattaforma LAMP (Linux Apache Mysql Php), ed in particolare: PHP ed Apache, per la presentazione dei dati e per le interfacce utente; MySQL, per la persistenza dei dati di configurazione. Tutto l applicativo è altamente personalizzabile e può avere più utenti con viste personalizzate e diversi livelli di permesso per le modifiche. La figura di seguito mostrata la schermata iniziale di Cacti attraverso la quale è possibile accedere. Figura 4: Autenticazione di Cacti Pagina 17 di 127

18 Una schermata modulare di cacti potrebbe essere la seguente: Figura 5: Schermata Modulare di cacti Per quanto riguarda la definizione dei monitoraggi, le chiamate a Net-SNMP possono essere definite per mezzo di: script di shell bash; script Perl; definizione di template in XML (extensible Markup Language). Una volta definite le interrogazioni SNMP desiderate, attraverso processo di polling, Cacti prevede ad eseguirle ad intervalli di tempo regolari, passandone i risultati ad RRDTool. In prima istanza, RRDTool può essere considerato come un vero e proprio database ottimizzato per gli ambienti di monitoraggio in genere. Nel successivo Pagina 18 di 127

19 paragrafo sarà descritto in maniera esaustiva tale software, del quale Cacti viene considerato un'interfaccia user friendly, in quanto l'applicazione realizzata prevede, a livello del data layer, una ricca interazione con quest'ultimo. Di seguito visualizzeremo alcune parti dell'interfaccia Web del Tool Cacti: Inserimento nuovo dispositivo da monitorare, come si può vedere le opzini per il monitoraggio sono molto esaustive. Figura 6: Interfaccia Grafica, Inserimento Nuovo Dispositivo Pagina 19 di 127

20 Lista Dispositivi Monitorati, ci offre una panoramica dei dispositivi monitorati, quanti dati stiamo raccogliendo (numero dei DataSorce), e quanti grafici aggiorna ogni ciclo, e molte altre info ulti, ping, ip, cicli lettura ecc... Figura 7: Interfaccia Grafica, Lista Dispositivi Monitorati Pagina 20 di 127

21 Lista di alcuni grafici filtrati, riguadante la macchina locale. Figura 8: Lista Dei Grafici filtrata su dispositivo "localhost" Pagina 21 di 127

22 2.2.3 Rrdtool : Round-Robin Database Tool RRDTool (acronimo di Round Robin Database Tool) è un software open source realizzato interamente in C da Tobias Oetiker ed è uno degli strumenti maggiormente utilizzati nell'ambito dei sistemi di monitoraggio in genere. Il compito principale di RRDTool, in un sistema di monitoraggio, è l'archiviazione di serie temporali. Le principali caratteristiche sono: dimensioni degli archivi (file RRD Round Robin Database), a regime, costanti; dump degli archivi in file XML; fetch di serie temporali parziali dagli archivi, file rrd; rappresentazione dei dati per mezzo di grafici (fig. ). Figura 9: Grafico generato da uno script bash che utilizza rrdtool Pagina 22 di 127

23 RRDTool può essere utilizzato per monitorare qualsiasi tipo di dato sia possibile raccogliere in maniera automatica, ma viene soprattutto utilizzato in congiunzione col protocollo SNMP. È basato essenzialmente sul concetto del round robin una tecnica che utilizza un numero finito di elementi e un puntatore all'elemento corrente. I nuovi elementi vengono aggiunti sovrascrivendo i dati più vecchi. In pratica il database è circolare, una volta raggiunta la fine il puntatore si sposta di nuovo sul primo elemento e inizia a sovrascrivere i dati. I vantaggi delll'utilizzio di questa tecnica sta nel fatto che le dimensione degli archivi non variano mai, una volta creato è associato ad un dispositivo monitorato, la dimensione è fissa.questo aggevola la manutenzione del databse. Un altro aspetto importante da evidenziare di RRDTool è che i valori non vengono memorizzati quando disponibili, ma ad intervalli di tempo predeterminati. Se durante l'intervallo di raccolta il dato non è disponibile, viene memorizzato al suo posto il valore unknown (nan) per quell'intervallo. E' chiaro che con troppi intervalli in cui i dati non sono disponibili i risultati risulteranno evidentemente alterati, per cui è molto importante garantire in qualche modo un flusso costante di dati per l'aggiornamento del database. Un RRD (Round Robin Database) può contenere qualsiasi tipo di dato numerico, non necessariamente intero, con l'unico limite dato dall'applicabilità della sua struttura circolare. Pagina 23 di 127

24 2.3 Porting del Portale L'obbiettivo di questo porting è spostare il portale su una macchina più potente, che permetta una migliore gestione del portale web. Prima di tutto si sono analizati i requisiti per poi procedere con le relative installazioni e configurazione dei vari software necessari al porting Requisiti per il Porting I requsiti necessari per portale questo porting a buon fine, sono: Analisi corretta del vecchio portale. Disponibilità software dei Sistemi Operativi, e delle configurazioni degli stessi. Disponibilità saftware di tutti i tool utilizati dal vecchio portale. Conoscenza delle configurazione degli stessi. Accesso a tutti i software protetti. Macchina fisica, di destinazione delle Vistual Machine, connessa a internet, nella stessa rete delle vecchie macchine fisiche. Precisazione: si è deciso di non rispettare lo stesso ambiente di esecuzione, infatti sulle nuove macchine, il Sistema Operativo è Ubuntu server Scelta fatta sulla base della semplicità d'uso di tale sistema, la natura "server" dello stesso e per la ricca comunità che "ubuntu" possiede per eventuali problemi. Pagina 24 di 127

25 2.3.2 Virtual Machine: Vmware Per migliorare la portabilità del portale in futuro, si e deciso di trasportare lo stesso su macchine virtuali. Una macchina virtuale è un software che crea un ambiente virtuale che emula il comportamento di una macchina fisica ed in cui alcune applicazioni possono essere eseguite come se interagissero con tale macchina. Il software di virtualizzazione utilizato è "vmware", nello specifico la distribuzione usata è "workstation v7", che permette di creare una o più virtual machine e di gestirele in modo ottimale. Tale distribuzione è stata ustata per creare le tre macchine virtuali Wifed.scope.unina.it: porting Per quanto riguarda la macchina "wifed", funge da server principale, è gira tutte le richieste alle altre due macchine. Effettuando un redirect all'interno del frame, inserito nella pagina "index.html" del web server apache2, che vi è installato. Sulla macchina è stato installato appunto solo il LAMP, per avere una configurazione standard, anche se bastava mettere solo apache2. Il motivo per cui questa macchina ha solo l vunzionalità di "redirect", anche se carica tutte le richieste all'interno di un "iframe" e quello di mascerare la struttura fisica del portale, cioe l'utente meno esperto non si accorge che in realtà sono diverse macchine a offrire il servizzi che lui utilizza. Pagina 25 di 127

26 2.3.4 Wifed02.scope.unina.it: porting Recapitolando iservizi offerti, monitoraggio di 6 dispositivi e creazione di 64 grafici. Prima di tutto la classica configurazione LAMP, in più si è dovuto installare il pacchetto "libnet-snmp-perl" e "perl" per far funzionare correttamente degli script, che completano il servizio di monitoraggio. Per quanto riguarda il LAMP si è usato l'installer "Wifi Web Monitoring Portal", scaricabile dallo stesso Portale "Wifed". Dopo aver configurato l'ambiente, si è passato alla pratica, copiando i vari servizi: si è effettuato il dump del DB "cacti", per salvare tutte le configurazioni, dopo è stato importato il file.sql nel database presente nella virtual machine. Effettuato la copia del database, ora passiamo alla copia degli "rrd". Per trasportare gli "rrd" su una differente macchina c'è bisogno di trasformarli prima in file "xml" formato che memorizza i dati indipendentemente dalla macchina o dal SO, poi sono stati copiati in questa forma nella virtual machine e riconvertiti in formato "rrd". Queste operazioni vengono fatte tramite uno script shell. Dopo aver effettuato queste copie dei dati di configurazione, si è passati alla ricreazione del monitoraggio dei dispositivi e dei grafici in cacti, che anche se sono stati copiati, non hanno funzionato correttamente, decidendo di reinserirli a mano, copiando la configurazione dalla macchina originaria. Si sono anche dovuti sistemare gli script di aggiornamento dei grafici del sito, che hanno subbito una leggera modifica dovuta alla riconfigurazione dei grafici in cacti. Completate le configurazioni dei vari software tool (es: cacti,rrdtool,script bash), e della cartella di root del web server, si sono avviati gli script per aggiornare i grafici del portale e si è atteso per vedere se tutto era andato come doveva. Pagina 26 di 127

27 2.3.5 Wifed03.scope.unina.it : Guida al Porting In questa macchina vi dovranno essere installatti i seguenti servizi: CMS Joomla, monitoraggio di 4 dispositivi e 16 grafici. Anche qui abbiamo messo la configurazione base, Lamp più cacti; dopo di che siamo passati a fare il "dump" di tutti i DataBase che ci servivano, sulla veccchia macchina: cacti,joomla,rrdb ; effettuando le stesse operazioni descritte precedentemente. Effettuato il dump di tutte le basi di dati, si è passati all'inserimento manuale dei dispositivi e dei grafici che questa macchina deve monitorare, copiandoli dalla macchina originaria. Effettuato l'inserimento e controllato che tutto funzionava correttamente, siamo passati a joomla, dove ci siamo limitati a copiare l'intera cartella "Joomla", nella stessa locazione ma nella macchina virtuale, cioè nella root del web server Statistiche Wi-Fi : Porting del Servizio Le statistiche Wi-Fi sono composte da due sistemi indipendenti, che lavorano su due tipologie di macchine, il prima, server, che ha lo scopo di raccogliere i dati per metterli a disposizione del secondo, client, che li prende e li pubblica attraverso il CMS Joomla. Questi sistemi possono funzionare su qualsiasi macchina che dispone di: Joomla o cacti in base al tipo di operazione, per la presentazione e per la raccolta dei dati. Nel nostro caso il sistema server è situato sulla wifed02, raccolta dati, e il sistema client è situato sulla wifed03, presentazione dei grafici. Detti ciò passiamo all'installazione del sistema server delle statistiche. Per prima cosa, abbiamo installatto il pacchetto "sun-java6-jdk", su entrambe le macchine, per permettere l'esecuzione di applicazioni scritte in "java". Per effettuare una corretta configurazione del sistema server delle statistiche, abbiamo seguito le indicazioni sulla guida di Paolo Vanacore, creatore del servizio. Rimandando all'appendice "How To" Pagina 27 di 127

28 per una miniguida alla configurazione. Il programma "DataServer.jar", viene fornito con un file di configurazione: server_config.xml dove all'interno vengono definite le proprieta del servizio, che devono essere impostate correttamente per un corretto funzionamento del servizio. Eseguendo il file jar tramite la seguante istruzione: shell>java -jar./dataserver.jar >./logfile & l'applicativo genera un autuput, sullo "stdio" che abbiamo reindirizzato su un file di log, per tenere traccia di eventuali errori. Per quanto eiguarda il lato "client" c'è voluto l'installazione di "tomcat", per permettere la messa in esercizio dell'interfaccia di amministrazione delle statistiche. A cui si può acceder anche da remoto, tramite il web. Per quanto riguarda "tomcat" si è installato la stessa versione della macchina portingata: la versione 6. Installato tomcat 6 correttamente, e avviato, si è modificata la porta di ascolto alla "8090", e si è configurato anche qui il file, dataclient_config.xml anche qui i parametri da settare sono molto semplici. Dopo aver configurato correnttamente il client, avviarlo con il comando analogo al server: shell>java -jar./dataserver.jar >./logfile & anche qui c'è il redirect dell'imput per tenere traccia di eventuali errori nel log. Dopo di ciò si è passati al "deploy" delle interfaccie WiStatAdmin & WiStat, tramite l'interfaccia di tomcat, raggiungibile all'indirizzo " e autenticandosi come "manager" o "amministratore".per effettuare una corretta configurazione del sistema client delle statistiche e di tomcat, abbiamo seguito le indicazioni sulla guida di Paolo Vanacore, creatore del servizio. Rimandando all'appendice "How To" per una miniguida alla configurazione. Pagina 28 di 127

29 3 Gestione dell'accesso L'infrastruttura di rete Dell'Università di Napoli Federico II possiede innumerevoli risorse informatiche che richiedono all'utilizatore un autenticazione per poter usare tale risorsa. Dato il gran numero di utenza che l'università possiede e impraticabile e impensabile che ogni servizio o gruppo di servizi gestisca separatamente l'autenticazione, infatti tutti i servizi si appoggiano ad un unico servizio di autenticazione dell'utenza, questo servizio è composto da un database basato su Directory Access utilizante il sitema OpneLdap per comunicare con gli altri sistemi, lo stesso si basa sul protocollo Ldap. Questo tipo di servizio è composto da più server ridondanti posizionati in modo distribuito nelle varie sedi principali di unina, questo per garantire il funzionamento del servizio sia per grassi carichi, sia per eventuali guasti a un o più server. Pagina 29 di 127

30 3.1 Autenticazione di un Utente L autenticazione è un processo mediante il quale un computer o software verifica la corretta identità dell utente che vuole avvedervi. Essa utilizza diverse tipologie di credenziali, per effettuare l autenticazione. Le tipologie di credenziali vanno dalla più semplice coppia UserName Password, a quelle biometriche come le impronte digitale o la scansione della retina oculare. Un utente autenticato, a seconda del software che sta utilizzando può avere più privilegi rispetto a un utente ospite. Il modulo di autenticazione, progettato, che viene integrato nel cms joomla, viene usato per riconoscere un qualsiasi utente che si collega al portale wifed, come utente unina tramite la coppia di credenziali username e password che usa per accedere al portale unina. Lo username rappresenta in modo univoco mediante il quale un utente viene riconosciuto dal sistema informatico, in questo caso dal portale. Questo nome nella maggior parte delle volte non corrisponde al nome reale dell utente ma è uno pseudonimo. La password unita all username permette l identificazione di un utente. Mente lo username e di dominio pubblico, tutti lo possono conoscere la password e privata e solo l utente la dovrebbe conoscere. Pagina 30 di 127

31 3.2 Il Protocollo Ldap Ldap sta per Lightweight Directory Access Protocol, si tratta di un protocollo clientserver utilizato per accedere a servizi di "directory". I Directory sono database specializati ad offrire massime prestazioni in fase di lettura delle informazione. Unendo il protocollo al tipo di server, oggi si parla direttamente di "directory Ldap". Questi database vengono usati principalmente dove la loro potenzialità e meglio sfruttata, dove i dati sono statici e le modifiche sono rare o quasi del tutto assenti. Un server Directory Ldap organizza le informazioni in una struttura gerarchica di oggetti chiamati "Entry". L'insieme di tutte queste Entry, vanno a formare una struttura dati organizata ad albero, dove ogni nodo o foglia viene identificat mediante un Relative Distinuished Name (RDN), l'unione di tutti gli RDN a partire dalla foglia fino alla radice dell'albero, forma il Distinguished Name (DN) che identifica in modo univoco una Entry, di seguito una figura che faccia capire la struttura di una directory Pagina 31 di 127

32 Figura 10: Struttura ad Albero generica di un server Ldap Ciascuna Entry ha una serie di attributi, costituiti dall'associazione attributo-valore; per ogni attributo possono esserci più valori. Ognuno degli attributi dell'elemento è definito come membro di una classe di oggetti, raggruppati in uno schema. Ogni elemento nella directory è associato a una o più classi di oggetti, che definiscono se un attributo sia opzionale o meno, e che tipo di informazioni questo contenga. I nomi degli attributi solitamente sono scelti per essere facilmente memorizzabili, per esempio "cn" per common name, o "mail" per un indirizzo . I valori degli attributi Pagina 32 di 127

33 dipendono dal tipo. Esistono anche i LDIF (Ldap Data Interchange Format) che permettono di importare o esportare "entry" tramite un semplice file di testo che contiene un attributo (nome/valore) per ogni riga del file. Pagina 33 di 127

34 3.2.1 Ldap: di unina L'università dispone anchessa di questo tipo di server per consentire l'accesso agli utenti nei propri servizi. Quindi anche io con il mio progetto iterrogherò questo server per determinare se un utente, puo o meno essere autenticato come utente unina: studente,ricercatore o professore che sia. Di sefuito lo schema del server Ldap di unina: version: 1 dn: dc=unina,dc=it objectclass: dcobject objectclass: organization dc: unina o: unina dn: ou=opensso,dc=unina,dc=it objectclass: organizationalunit objectclass: top ou: opensso dn: ou=istituzionali,ou=opensso,dc=unina,dc=it objectclass: organizationalunit objectclass: top ou: istituzionali dn: ou=docenti,ou=istituzionali,ou=opensso,dc=unina,dc=it objectclass: organizationalunit objectclass: top ou: Docenti dn: ou=polo DELLE SCIENZE E DELLE TECNOLOGIE (400000),ou=Docenti,ou=istituzionali,ou=opensso,dc=unina,dc=it objectclass: top objectclass: organizationalunit objectclass: inetlocalmailrecipient objectclass: posixaccount cn: POLO DELLE SCIENZE E DELLE TECNOLOGIE (400000) description: gidnumber: 100 homedirectory: /home/ maillocaladdress: doc_400000@unina.it mailroutingaddress: doc_400000@unina.it ou: POLO DELLE SCIENZE E DELLE TECNOLOGIE (400000) uid: doc_ uidnumber: dn: ou=dipartimento DI SCIENZE FISICHE (100560),ou=POLO DELLE SCIENZE E DELLE TECNOLOGIE (400000),ou=Docenti,ou=istituzionali,ou=opensso,dc=unina,dc=it Pagina 34 di 127

35 objectclass: top objectclass: organizationalunit objectclass: inetlocalmailrecipient objectclass: posixaccount cn: DIPARTIMENTO DI SCIENZE FISICHE (100560) description: gidnumber: 100 homedirectory: /home/ maillocaladdress: mailroutingaddress: ou: DIPARTIMENTO DI SCIENZE FISICHE (100560) uid: doc_ uidnumber: dn: cn=docente docente DI SCIENZE FISICHE (100560),ou=POLO DELLE SCIENZE E DELLE TECNOLOGIE (400000),ou=Docenti,ou=istituzionali,ou=opensso,dc=unina,dc=it objectclass: inetorgperson objectclass: inetlocalmailrecipient objectclass: posixaccount objectclass: shadowaccount objectclass: organizationalperson objectclass: person objectclass: top objectclass: inetuser businesscategory: N carlicense: {SHA}98O8HYCOBHMq32eZZczDTKeuNEE= cn: docente docente (docente@unina.it) departmentnumber: DDDDDD11D11D111D description: cn=user,ou=gruppi,ou=opensso,dc=unina,dc=it employeenumber: employeetype: Docenti gidnumber: 100 givenname: docente homedirectory: /home/docente inetuserstatus: Active internationalisdnnumber: loginshell: /bin/false mail: docente@unina.it mail: mat98765@unina.it maillocaladdress: docente@unina.it mailroutingaddress: docente@unina.it ou: docente docente (docente@unina.it) physicaldeliveryofficename: physicaldeliveryofficename: FACOLTA' DI SCIENZE MATEMATICHE, FISICHE E NATURALI sn: docente title: Docenti di ruolo di Ia fascia uid: docente uidnumber: userpassword:: e1niqx1rs0r2whrluwfutc8wa3lhn1d1a1bdduhozwc9 Pagina 35 di 127

36 dn: ou=personalet.a.,ou=istituzionali,ou=opensso,dc=unina,dc=it objectclass: organizationalunit objectclass: top ou: PersonaleT.A. dn: ou=altra struttura (100000),ou=PersonaleT.A.,ou=istituzionali,ou=opensso,dc=unina,dc=it objectclass: top objectclass: organizationalunit objectclass: inetlocalmailrecipient objectclass: posixaccount cn: ALTRA STRUTTURA (100000) description: gidnumber: 100 homedirectory: /home/ maillocaladdress: mailroutingaddress: ou: altra struttura (100000) uid: doc_ uidnumber: dn: ou=csi - centro di ateneo per i servizi informativi (295550),ou=altra struttura (100000),ou=PersonaleT.A.,ou=istituzionali,ou=opensso,dc=unina,dc=it objectclass: top objectclass: organizationalunit objectclass: inetlocalmailrecipient objectclass: posixaccount cn: CSI - CENTRO DI ATENEO PER I SERVIZI INFORMATIVI (295550) description: gidnumber: 100 homedirectory: /home/ maillocaladdress: @unina.it mailroutingaddress: @unina.it ou: csi - centro di ateneo per i servizi informativi (295550) uid: doc_ uidnumber: dn: cn=personale personale(personale@unina.it),ou=csi - centro di ateneo per i servizi informativi (295550),ou=altra struttura (100000),ou=PersonaleT.A.,ou=istituzionali,ou=opensso,dc=unina,dc=it objectclass: inetorgperson objectclass: inetlocalmailrecipient objectclass: posixaccount objectclass: shadowaccount objectclass: organizationalperson objectclass: inetuser objectclass: person objectclass: top businesscategory: N carlicense: {SHA}98O8HYCOBHMq32eZZczDTKeuNEE= Pagina 36 di 127

37 cn: personale departmentnumber: PPPPPP11P11P111P description: cn=user,ou=gruppi,ou=opensso,dc=unina,dc=it employeenumber: employeetype: PersonaleTA gidnumber: 100 givenname: personale homedirectory: /home/personale inetuserstatus: Active loginshell: /bin/false mail: mail: maillocaladdress: mailroutingaddress: ou: personale physicaldeliveryofficename: physicaldeliveryofficename: CSI - CENTRO DI ATENEO PER I SERVIZI INFORMATIVI sn: personale title: Personale tecnico amm.vo uid: personale uidnumber: userpassword:: e1niqx05oe84sfldt0jitxezmmvawmn6rfrlzxvoruu9 dn: ou=studenti,ou=opensso,dc=unina,dc=it objectclass: organizationalunit objectclass: top ou: studenti dn: ou=attivi,ou=studenti,ou=opensso,dc=unina,dc=it objectclass: top objectclass: organizationalunit ou: attivi dn: ou=facolta' DI SCIENZE MATEMATICHE FISICHE E NATURALI (17),ou=attivi,ou=studenti,ou=opensso,dc=unina,dc=it objectclass: top objectclass: organizationalunit objectclass: inetlocalmailrecipient objectclass: posixaccount cn: FACOLTA' DI SCIENZE MATEMATICHE FISICHE E NATURALI (17) description: 17 gidnumber: 100 homedirectory: /home/17 maillocaladdress: fac17@unina.it mailroutingaddress: fac17@unina.it ou: FACOLTA' DI SCIENZE MATEMATICHE FISICHE E NATURALI (17) uid: fac17 uidnumber: Pagina 37 di 127

38 dn: ou=informatica (566),ou=FACOLTA' DI SCIENZE MATEMATICHE FISICHE E NATURALI (17),ou=attivi,ou=studenti,ou=opensso,dc=unina,dc=it objectclass: top objectclass: organizationalunit objectclass: inetlocalmailrecipient objectclass: posixaccount cn: INFORMATICA (566) description: 566 gidnumber: 100 homedirectory: /home/566 maillocaladdress: cdl566@unina.it mailroutingaddress: cdl566@unina.it ou: INFORMATICA (566) uid: cdl566 uidnumber: dn: cn=studente studente (studente@studenti.unina.it),ou=informatica (566),ou=FACOLTA' DI SCIENZE MATEMATICHE FISICHE E NATURALI (17),ou=attivi,ou=studenti,ou=opensso,dc=unina,dc=it objectclass: inetorgperson objectclass: inetlocalmailrecipient objectclass: posixaccount objectclass: shadowaccount objectclass: organizationalperson objectclass: person objectclass: top objectclass: inetuser carlicense: {SHA}98O8HYCOBHMq32eZZczDTKeuNEE= cn: studente studente (studente@studenti.unina.it) departmentnumber: SSSSSS11S11S111S description: cn=user,ou=gruppi,ou=opensso,dc=unina,dc=it description: cn=admin,ou=gruppi,ou=opensso,dc=unina,dc=it employeenumber: employeetype: Studente gidnumber: 100 givenname: studente homedirectory: /home/studente inetuserstatus: Active loginshell: /bin/bash mail: studente@studenti.unina.it mail: mat @studenti.unina.it maillocaladdress: studente@studenti.unina.it maillocaladdress: mat @studenti.unina.it mailroutingaddress: studente@studenti.unina.it ou: studente studente (studente@studenti.unina.it) physicaldeliveryofficename: 566 roomnumber: sn: studente street: Inactive uid: studente Pagina 38 di 127

39 uidnumber: userpassword:: e1niqx1py00rwvhqauvmmm9wsnredzk2vxjeys90exm9 dn: cn=studente2 studente (566),ou=FACOLTA' DI SCIENZE MATEMATICHE FISICHE E NATURALI (17),ou=attivi,ou=studenti,ou=opensso,dc=unina,dc=it objectclass: inetorgperson objectclass: inetlocalmailrecipient objectclass: posixaccount objectclass: shadowaccount objectclass: organizationalperson objectclass: person objectclass: top objectclass: inetuser carlicense: {SHA}98O8HYCOBHMq32eZZczDTKeuNEE= cn: studente2 studente (studente2@studenti.unina.it) departmentnumber: SSSSSS11S11S111S description: cn=user,ou=gruppi,ou=opensso,dc=unina,dc=it description: cn=admin,ou=gruppi,ou=opensso,dc=unina,dc=it employeenumber: employeetype: Studente gidnumber: 100 givenname: studente homedirectory: /home/studente inetuserstatus: Active loginshell: /bin/bash mail: studente@studenti.unina.it mail: mat @studenti.unina.it maillocaladdress: studente@studenti.unina.it maillocaladdress: mat @studenti.unina.it mailroutingaddress: studente@studenti.unina.it ou: studente studente (studente@studenti.unina.it) physicaldeliveryofficename:566 roomnumber: sn: studente2 street: Inactive uid: studente2 uidnumber: userpassword:: e1niqx1py00rwvhqauvmmm9wsnredzk2vxjeys90exm9 dn: ou=gruppi,ou=opensso,dc=unina,dc=it objectclass: organizationalunit objectclass: top ou: gruppi dn: cn=user,ou=gruppi,ou=opensso,dc=unina,dc=it objectclass: groupofuniquenames objectclass: top cn: User Pagina 39 di 127

40 uniquemember: cn=studente studente (566),ou=FACOLTA' DI SCIENZE MATEMATICHE FISICHE E NATURALI (17),ou=attivi,ou=studenti,ou=opensso,dc=unina,dc=it dn: cn=admin,ou=gruppi,ou=opensso,dc=unina,dc=it objectclass: groupofuniquenames objectclass: top cn: admin uniquemember: cn=studente studente (studente@studenti.unina.it),ou=informatica (566),ou=FACOLTA' DI SCIENZE MATEMATICHE FISICHE E NATURALI (17),ou=attivi,ou=studenti,ou=opensso,dc=unina,dc=it dn: cn=superuser,ou=gruppi,ou=opensso,dc=unina,dc=it objectclass: groupofuniquenames objectclass: top cn: superuser uniquemember: cn=studente studente (studente@studenti.unina.it),ou=informatica (566),ou=FACOLTA' DI SCIENZE MATEMATICHE FISICHE E NATURALI (17),ou=attivi,ou=studenti,ou=opensso,dc=unina,dc=it dn: cn=administrator,ou=gruppi,ou=opensso,dc=unina,dc=it objectclass: groupofnames objectclass: top cn: Administrator member: cn=studente studente (studente@studenti.unina.it),ou=informatica (566),ou=FACOLTA' DI SCIENZE MATEMATICHE FISICHE E NATURALI (17),ou=attivi,ou=studenti,ou=opensso,dc=unina,dc=it Questo è solo una parte dello schema Ldap dei server Unina. Pagina 40 di 127

41 3.3 CMS Joomla:struttura sviluppatore Per quanto riguarda il lato del CMS Joomla, che comprende la funzione di mandare le richieste al server Ldap unina per poter identificare un utente, parleremo della sua struttura o meglio del lato dallo sviluppatore. Più precisamente parleremo delle Estensioni, la cui facilità di implementazione di una di essa, lo ha reso popolare nel mondo dei CMS Struttura del CMS Joomla Il cms joomla e composto da un core o motore, che è la parte principale del CMS che lo rende già completo così comè.il motore del cms è in grado di eseguire delle funzionalità aggiuntive tramite l'installazione delle estensioni più precisamente tramite la registrazione delle estensioni nella stessa componente del motore del cms. Durante questa registrazione dell'estenzione, vengono impostati vari valori, tra cui anche quello che determina se l'estenzione deve essere eseguita o meno. Le Estenzioni si dividono in tre categorie fondamentali: Componenti, Moduli, Plugin; ogni estensione ha il suo campo di esercizio. In base alle esigenze della funzionalità che si vuole implementare si sfrutta uno di questi tre pattern. Tutti e tre i pattern si basano sull' MVC (che sta per, Model View Controller ), che permette la creazione delle estensioni (componente, modulo o plugin che sia), separando durante l'implementazione le tre entità del pattern. Le sue entità principali sono: il Modello: fornisce i metodi per accedere ai dati utili all'applicazione; la Vista: visualizza i dati contenuti nel model e si occupa dell'interazione con utenti e agenti; il Controllore: riceve i comandi dell'utente (in genere attraverso il view) e li Pagina 41 di 127

42 attua modificando lo stato degli altri due componenti; Il Modello rappresenta lo stato del sistema (modellizza il sistema) per mezzo di oggetti e/o strutture dati. La Vista è una rappresentazione del Modello mentre il Controller è Figura 11: Struttura a Blocchi CMS Joomla un oggetto che si occupa dell'interazione con l'utente. Di seguito la figura dello schema a blocchi del CMS Joomla: Spiegheremo di sequito quel'è il campo di esercizio ed eventualmente le defferenze tra i tre tipi di estensioni. Pagina 42 di 127

43 3.3.2 Componenti Le Componenti sono elementi del nucleo fondamentale delle funzionalità di Joomla, perché rappresentano la funzionalità nella sua interezza, senza bisogno di interagire con altre funzionalità. Es di componenti sono: Banner, Newsfeed, Sondaggi e Weblink, ecc L'implementazione delle componenti avviene spesso quando si crea una funzionalità che non appoggia addosso ad altre per funzionare.quindi una funzionalità nuova e indipendente. Di solito queste funzionalità comprendono principalmente la visualizzazione dei contenuti nella parte principale del template Moduli I Moduli estendono le capacità di Joomla. Sono più snelli delle componti, ofrono al software nuove funzinalità. I Moduli sono piccole voci di contenuto che possono essere visualizzate dovunque il template consenta di essere visualizzate assegnandole a posizioni e pagine attraverso il gestore dei moduli nella interfaccia amministrativa. I Moduli di Joomla possono comprendere: Menu principale, Top Menu, Selettore template, Sondaggi, Conteggio click ecc. A differenza delle componenti i moduli sono più snelli nel codice è di solito per offrire la funzionalità si appoggiano ad altre già esistenti. Pagina 43 di 127

44 3.3.4 Plug-in Plugin è il termine usato nella versione 1.5, mentre mambot veniva usato nella versione 1.0. Un plugin o mambot è una piccola funzione finalizzata ad un determinato compito che intercetta il contenuto prima che questo venga visualizzato e lo manipola in qualche modo. Joomla fornisce un numero di Plugin nella distribuzione base, per esempio gli editore WYSIWYG, ma ci sono molti altri plugin disponibili per specifiche funzioni. Il plug-in a differenza degli altri due tipi di estensioni, non comprende a presciendere la programmazione della logica e della modellazione dell'informazione, il suo scopo è quello di effettuare controllo di flusso aggiuntivi per migliorare o potenziare una determinata funzionalità Scelta di Implementare il progetto tramite il Plugin di joomla Si è deciso di implementare un plug-in anzicche uno degli altri due tipi di estensioni, poiche in raltà non si richiede di creare una funionalità nuova ma solo di estendere la già esistente funzione di autenticazione che offre il cms jooma. Oltre a ciò in questo modo si sfrutta il modulo classico di login, il classico form "UserName & Password", che è già fornito dal CMS joomla, permettendoci cosi di concentrarci solo sul codice che si doveva eseguire, o meglio sui controlli delle credenziali. Joomla aggancia i suoi plug-in a eventi, che vengono scatenati in determinati momenti. Il CMS Joomla offre un numero considerevole di eventi a cui si può agganciare il prorpiro plug-in, gli eventi sono suddivisi in gruppi, in base a quale parte del codice motore del cms lo scatena, i gruppi sono: authentication: per estendere l'autenticazione Pagina 44 di 127

45 content: per effettuare controlli o inserire funzionalità nei contenuti editors: per realizzare editor search: per estendere le funzionalità di ricerca system: per far eseguire codice in vari momenti del caricamento del framework user: per estendere le funzionalità degli utenti Nel nostro caso, la funzione viene aganciata all'evento "onauthenticate", nel gruppo di eventi "authentication".l'evento viene lanciato dal core di joomla quando si rende necessario controllare le credenziali di un utente. Questo evento viene associato al modulo "Autenticati", già esistente dal pacchetto base di joomla. L'enveto viene scatenato subito dopo aver inviato i dati, quindi la richiesta viene girata in modo gerarchico a tutti i plugin che sono aganciati a l'evento "onauthenticate". Se uno fallisce, login fallito, si passa al plugin successivo fino a quando o si a successo o sono finiti i plugin. Quindi l'ordine gerarchico dei plugin è importantissimo se si ha più di un plugin agganciato sullo steso evento. Questo sistema ci consente di non intaccare i sistemi di autenticazione già esistenti ed eventualemente funzionante. Di seguito la lista completa di tutti gli eventi che il motore del CMS joomla è in grado di gestire: Authentication: onauthenticate Content: onpreparecontent onafterdisplaytitle onbeforedisplaycontent onbeforecontentsave Pagina 45 di 127

46 onaftercontentsave Editors: oninit ongetcontent onsetcontent onsave ondisplay ongetinsertmethod Editors XTD (Extended): ondisplay Search: onsearch onsearchareas System: onafterinitialise onafterroute onafterdispatch onafterrender User: onloginuser onloginfailure onlogoutuser onlogoutfailure Pagina 46 di 127

47 onbeforestoreuser onafterstoreuser onbeforedeleteuser onafterdeleteuser XML-RPC: ongetwebservices Pagina 47 di 127

48 3.4 Interfacciarsi con i server Ldap di unina Perchè un Web Service? Un primo problema è stato riscontrato quando è stato necessario contattare gli amministratori di rete unina per chiedere l'accesso ai server Ldap, che per ovvi motivi sulla sicurezza interna degli stessi, mi è stato negato. Con loro si è cercato una soluzione che mi permettesse comunque di interrogare i server ldap di unina, in modo da determinare se delle credenziali fossero corrette o meno. Durante questo colloquio con gli amministratori, sono state poste due possibilità di interrogazione dei server Ldap di unina, entrambe non permettono di comunicare direttamente con i server, ma con le due strategie differenti proposte, ero in grado di controllare le credenziali. Le due strategie proposte sono: interrogazione di un Service Web tramite comunicazione SOAP e utilizare una classe java da loro fornito per comunicare a più basso livello con i server ldap di unina. La classe java doveva esser inclusa all'interno del codice del mio programma. Sono state analizate le due proposte ed è stata scartata subito quella della classe java, visto che il programma veniva sviluppato in linguaggio script php, che è lo stesso linguaggio di scripting con cui è stato realizato il cms joomla. Pertanto si è passati a strutturare il plugin in modo da interagire con un servizio web. Di seguito illustrero cosè un Servizio Web. Pagina 48 di 127

49 3.4.2 Web Service di unina Secondo la definizione data dal World Wide Web Consortium (W3C) un Web Service (servizio web) è un sistema software progettato per supportare l'interoperabilità tra diversi elaboratori su di una medesima rete. La caratteristica fondamentale di un Web Service è quella di offrire un'interfaccia software attraverso la quale altri sistemi possono interagire con lo stesso attivando le operazioni descritte nell'interfaccia tramite appositi "messaggi" inclusi in una "busta" (la standard è SOAP:Simple Object Access Protocol): tali messaggi sono, solitamente, trasportati tramite il protocollo HTTP e formattati secondo lo standard XML. Questo permette a software scritti in diversi linguaggi di comunicare tra loro tramite lo scambio di messaggi formattati in xml. Nel nostro caso si farà comunicare uno script in php con il service di unina, questo ci permetterà di effettuare l'autenticazione di un utente tramite le credenziali semplici di uno studente unina. Un Service Web per poter esser publicato, ha bisogno che venga accompagnato da un documento che ne descriva come lo si può utilizare. Questo documento e il WDSL, formattato come un XML, con delle specifiche regole di composizioni. DEF:Un WDSL (Web Services Description Language), è un documento che descrive il servizio, cosa offra e che parametri si aspetta. Questo documento permette agli altri software di comunicare con un service senza che si sappia la sua vera natura. Esempio dell'architettura di un servizio: Pagina 49 di 127

50 Figura 12: Schema di Funzionamento di un Servizio Web. Fase1: Il client recupera il "wdsl" tramite una richiesta http. Fase2: Dopo aver analizato il descrittore del servizio, compone il messaggio in modo che il servizio lo posso comprendere, utilizando lo standard Soap. Lo serializza e lo invia al servizio. Fase 3: Il Servizio deserializza il messaggio in input, e lo legge per poi rispondere alla richiesta con un'altro messaggio. Fase 4: dopo aver elaborato il messaggio in imput, ne produce uno per rispondere alla richiesta, serializandolo e inviandolo tramite lo standard Soap. Fase 5: Il client deserializza la risposta e la leggere. Questo è un ciclo di "richiesta-risposta", completo. Pagina 50 di 127

51 4. Progetto: Autenticazione tramite Ldap nel CMS Joomla Di seguito varrà spiegato cosa ho progettato e come lo creato, i vari problemi affrontati e come sono stati risolti. 4.1 Analisi dei requisiti Il progetto è volto a realizare un servizio di autenticazione di tutti gli studenti unina sul portale "wifed" con le stesse credenziali unina. In particolare si deve creare una funzionalità al già presente portale web, che interroghi i server Ldap di unina per effettuare l'autenticazione di un utente con le credenziali semplici. Il sistema prevede, al momento della progettazione, tre gruppi di utenti: Visitatore Utente Autenticato Amministratore Il Visitatore, è un utente che non ha effettuato l'autenticazione, quindi non ha privilegi. L'Utente Autenticato, è un utente che effettuato il "login" e avuto successo nell'operazione, ha privilegi di visitare l'intero portale wifed, salvo l'interfaccia di amministrazione del CMS joomla che l'interfaccia di amministrazione delle statistiche wifed. L'Amministratore, ha i massimi privilegi nel portale "wifed". Al momento la gestione degli amministratori avviene sul database interno del portale wifed, questo per avere una gestione personale degli utenti che ne fanno parte. Pagina 51 di 127

52 4.2 Realizzazione Prototipo Durante la fase di analisi del lavoro che dovevo svolgere, si è deciso di sviluppare un prototipo dell'applicazione reale, odne evitare problemi al servizio di autenticazione unina, che potevano scaturire dalle varie fasi di test sull'applicazione che si stava realizando. Per creare un abiente di test verosimile, si è dovuto creare e pubblicare un servizio web che imitasse quello di unina. Ciò è stato fatto con l'aiuto di due moduli aggiuntivi di apache2 che ci ha permesso di aggevolare il lavoro di pubblicazione e generazione del wdsl del servizio, questi due moduli sono Tomcat6 e Axis. Tomcat, più conosciuto, che permette l'esecuzione di codice java e interfacciarlo su internet. Axis si occupa di compilare la classe java e generare il wdsl che la descriveva. Tramite l'interfaccia "localhost:8080" si poteva comunicare con il servizio web. Di seguito una struttura a blocchi dei tuol installati nell'ambiente creato per effettuare i test di funzionamento del prototipo: Pagina 52 di 127

53 Figura 13: Struttura a blocchi dei tool installati nell'ambientedi testing Durante le fasi di test si sono riscontrati molti problemi sull'interrogazione del servizio. La composizione del messaggio che veniva inviato al servizio e del tutto automatica, grazie alla classe php "SOAPClient" che compilava il messaggio tramite l'analisi del wdls, perciò gli errori riscontrati spesso non si capivano. Dopo lunghe fasi di test si è scoperto che per usare quella classe SoapClient, si devono conoscere i metodi da interrogare, quindi basta analizare il wdsl. Quindi in analisi del proptotipo realizato, si e visto che gli unici parametri di configurazione sono l'indirizzo del wdsl. Il nome del metodo deve esser inserito nel codice a mano, questo provocherà problemi in caso venga aggiornao o moificato il servizio a livello di codie. Invece se viene spostato, basterà andare a modificare l'indirizzo del wdsl del servizio nell'interfaccia di configurazione del plugin tramite l'interfccia amministrativa del cms joomla. Pagina 53 di 127

54 Di seguito un esempio dell'interfaccia di configurazione del plug-in di test: Figura 14: Schermata di configurazione del plugin Pagina 54 di 127

55 4.3 Progettazione Di seguito viene descritto il lavoro svolto e la struttura dettagliata del software creato Problematiche riscontrate Durante l'analisi del problema e la creazione del prototipo, si sono riscontrati diversi ostacoli: Mantenimento del Database Locale degli utenti. Staticita nella struttura del messaggio soap per interrogare il servizio di autenticazione unina. Conoscenza approfondita del framework del cms joomla questi problemi hanno rallentato la fase di implementazione, ma per fortuna sono stati, tutti o in parte, risolti. Pagina 55 di 127

56 4.3.2 Scelte Progettuali Nella creazione e messa in esercizio del programma da implementare sono state fatta varie scelte che hanno determinta la natura del programma. Premessa: si deve dire che l'ambiente di sviluppo di questa applicazione e limitato dal fatto che deve essere integrato all'interno di un cms web, per la precisione il cms e Joomla. Le scelte fatte sono sinteticamente: Creazione di un plugin (modulo di joomla): scelto perchè permette di non modificare la già utilizata autenticazione sul db locare, infatti permette di estendere la funionalità di autenticazione in modo parallelo. Quindi l'autenticazione funzioneranno entrambe sia sul db locare sia tramite credenziali unina. Con priorita alle credenziali unina. Precisando che nel database locale esiste solo il gruppo utenti "amministatori". Utilizzo del Web Service di unina per controllare le credenziali di uno studente, comunicazione tramite lo standard soap. Utilizzo della classe SOAPClient della libreria standard di php, con la limitazione, già anticipata, che si deve conoscere il nome del metodo da richiamre per far effettuare il controllo delle credenziali dal web Service. Il framework di sviluppo e il CMS Joomla. Pagina 56 di 127

57 4.3.3 Casi D'uso Di seguito viene illustrato il diagrammi dei casi d'uso: Figura 15: Diagramma dei Casi D'Uso Si evince che il Visitatore per effettuare l'autenticazione il sistema usufruisce sempre del plugin da me progettato, anche se ad autenticarsi e un amministratore di sitema che è registrato nel database locale. Pagina 57 di 127

58 4.3.4 Diagrammi delle classi Di sequito in dettaglio il diagramma della classe implemantata per creare il plugin. Figura 16: Diagramma delle classi Il nostro plugin nasce estendendo una classe più generica fornitaci dal core di joomla. La nostra classe estendendo "jplugin" sovrascrive anche l'evento a cui si sta aganciando, in questo modo il core di joomla eseguirà il nostro metodo sovrascrito allo scatenarsi dell'evento "onauthenticate". La nostra classe comunica con l'oggetoo "SOAPClient" che mette a disposizione funzioni per interrogare un Web Service con più sicurezza e automazione. Pagina 58 di 127

59 4.3.5 Diagrammi di Sequenza Diagramma di sequenza di un autenticazione andata con successo. Figura 17: Diagramma sequenza, Autenticazione Pagina 59 di 127

60 4.3.6 Implementazione In questo paragrafo si parlera di come è stato implementato il plugin, descrivendo la funzionalità di alcune righe di codice, utilizate nel plugin in esercizio. Una premessa prima di passare alla descrizione dell'implementazione: per meglio capire la struttura di funzionamento qui di seguito uno schema a blocchi che ci fa capire come il plugin viene interrogato dal cor di joomla. Figura 18: Struttura di interrogazione di un plugin.ù Come potete vedere il core di joomla ha in se registrati tutti i plugin agganciati ad uno specifico evento. Nella reggistrazione del plugin, joomla chiede anche la priorità di esecuzione, o meglio chiede l'ordine con cui i plugin registrati devono essere interrogati. In base alla priorità assegnata il core di joomla interroga uno ad uno i plugin registrati fino a quando o uno non esce con stato "ok" o finchè non finisce la lista dei plugin registrati ad un dato evento. Una volta che il plugin viene selezionato per l'interrogazione, viene eseguito il costruttore e poi viene lanciato il metodo che è agganciato all'evento, nel nostro caso "onauthenticate(...)". Pagina 60 di 127

61 All''inizio la funzione effettua lettura dei paramtri in ingresso e lettura dei parametri di configurazione, l'unico e l'indirizzo del wdsl. Successivamente utiliza la classe "SOAPClient" per scaricare il descrittore del Web Service. Dopo di che invia le credenziali al WebService per verificare se sono valide. In caso vi sia un erroe durante la richiesta, viene catturato: se al contrario la comunicazione non ha problemi si continua con l'esecuzione del codice. Passando al contrllo della risposta ricevuta dal web service per capire quale è stato il risultato della verifica delle credenziali. In base al al valore ritornato dalla richiesta di verifica, lo funzione imposta un valore di "stato" ed esce dalla funzione. Se le credenziali sono errate si esegue: Pagina 61 di 127

62 se al contrario il test ha avuto esito positivo si esegue: impostando oltre allo stato di "autenticato", il nome dell'utente autenticato, che risiede nella posizione "2", e l' che risiede nella posizione "1". Nel caso in cui la risposta del web service da esito negativo il core di joomla si ritroverà con un ritorno di stato "jauthenticate_status_failure", e passerà ad interrogare il plugin successivo, che nella nostra configurazione è quello di default di joomla, cioè autentica gli utenti tramite il database locale dello stesso joomla. Oltre all'implementazione del plugin, ho dovuto settare il descrittore del plugin, cioè quel file che permette al core di joomla di registrare il nostro plugin su un dato evento. Oltre a collegare il nostro plugin su l'evento, il descrittore del plugin permetti di creare una interfaccia di "back-and" che permette la configurazione dello stesso plugin e eventualmente il settaggio di parametri. Per fare tutto ciò il plugin deve essere installato e esenza questo descrittore joomla non permette l'installazione. Il descrittore e un file xml che accompagna il codice del plugin che è scritto in php. Alcune delle direttive più importanti sono: che è la direttiva più importante, poichè indica a joomla dei dati generali sul plugin, versione tipo di estensione e gruppo di appartenenza. La riga 1 ci fa capire che si tratta di un file xml, è quindi per essere preso in considerazione deve essere correttamnte formato. Pagina 62 di 127

63 I successivi sono di carattere descrittivo del plugin, compensibili da chiunque dopo di che vi è la lista dei file che viene associata al plugin, nel nostro caso che è un plugin di controllo e quindi il codice sta tutto in un solo file. In fine vi è la lista dei parametri, i tipi di parametri possono essere: text: box di testo a una linea textarea: box di testo a più linee list: visualizza una combobox a cascata che ti permette di selezionare un valore raio: visualizza più opzione da cui se ne seleziona una sola. space: mette uno spazio bianco nella visualizzazione dei parametri ogni tipo di parametro ha i suoi attributi che possono essere impostati, come nel nostro caso. Pagina 63 di 127

64 5 Conclusioni Il risultato del lavoro svolto dà la possobilità a uno studente iscritto alla federico II di accedere con le credenziali universitaria al portale di monitoraggio Wifed.scope.unina.it. Il lavoro è stato diviso in due fasi: 1) fase di analisi del probblema e della struttura del cms joomla, per meglio integrare l'idea all'interno del portale web. 2) la fase di sviluppo di un prototipo in ambiente di test, e successivamente l'implementazione del software integrato nel portale web, questa analisi potrà essere sfruttata nel caso si vogliano aggiungere altre funzionalità al portale web. Il plugin sviluppato, verifica se le credenziali inserite sono corrette; non controlla o legge altri dati come ad esempio il livello di privilegi. Uno sviluppo futuro potrebbe essere: modificare il codice e inserire il grado di privilegio di amministratore permettere al portale web di riconoscere il tipo di utente che si è autenticato e quindi controllare se si tratta di uno studente o professore. Sotto l'aspetto personale, questo tirocinio mi ha permesso di migliorare le mie nozioni di sviluppatore, aumentando notevolmente la mia conoscenza su molti tool di monitoraggio e sviluppo di servizi web. Pagina 64 di 127

65 Inoltre ho avuto la possibilità, quando si è trattato l'argomento sul porting, di lavorare in gruppo, all'interno del quale ho avuto scambi di opinioni, dissensi su alcuni temi, consensi su altri. Ho avuto l'opportunità di inquadrare e analizzare i problemi da più punti di vista e ciò mi ha permesso di condividere con loro le soluzioni migliori. E' stato sicuramente un momento di crescita professionale e di vita. Pagina 65 di 127

66 6 Appendice 6.1 Codice Sorgente Qui di seguito tutto il codice sorgente del plugin implementato Codice plugin File si chiama : "LdapWebService.php" il codice : <?php /** $Id: ldap.php :10:00Z louis $ Joomla JFramework Copyright (C) Open Source Matters. All rights reserved. GNU/GPL, see LICENSE.php * Joomla! is free software. This version may have been modified pursuant * to the GNU General Public License, and as distributed it includes or * is derivative of works licensed under the GNU General Public License or * other free or open source software licenses. * See COPYRIGHT.php for copyright notices and details. */ // Check to ensure this file is included in Joomla! defined('_jexec') or die( 'Restricted access' ); jimport( 'joomla.plugin.plugin' ); Pagina 66 di 127

67 /** * LDAP Authentication Plugin * Joomla JFramework 1.5 */ class plgauthenticationldapwebservice extends JPlugin { /** * Constructor * * For php4 compatability we must not use the constructor as a constructor for plugins * because func_get_args ( void ) returns a copy of all passed arguments NOT references. * This causes problems with cross-referencing necessary for the observer design pattern. * object $subject The object to observe array $config An array that holds the plugin configuration 1.5 */ /** Costruttore */ function plgauthenticationldapwebservice(& $subject, $config) { parent:: construct($subject, $config); } Pagina 67 di 127

68 /** * This method should handle any authentication and report back to the subject * public array $credentials Array holding the user credentials array $options object $response object boolean Array of extra options Authentication response object 1.5 */ function onauthenticate( $credentials, $options, &$response ) { // LDAP does not like Blank passwords (tries to Anon Bind which is bad) if (empty($credentials['password'])) { $response->status = JAUTHENTICATE_STATUS_FAILURE; $response->error_message = 'Controllare inserimento della password'; return false; } if (empty($credentials['username'])) { $response->status = JAUTHENTICATE_STATUS_FAILURE; $response->error_message = 'Controllare inserimento dell\' UserName'; return false; } Pagina 68 di 127

69 /** Ritorna 4 parametri : array[0] Esito richiesta [true,false] array[1] login array[2] fullname array[3] msg_error */ /** load plugin params info */ $wdsl= $this->params->get('wdsl'); /** Effettua il controllo delle credenziali tramite il service web, offerto da unina! */ try{ /** Legge il wsdl, per interfacciarsi con il servizio (da caricare) */ $service =new SoapClient($wdsl); /** Effettua la richiesta di controllo credenziali () */ $result = $service->autentica($credentials['username'],$credentials['password']); } catch (SoapFault $e){ $response->status = JAUTHENTICATE_STATUS_FAILURE; $response->error_message = 'Errore durante la richiesta al servizio web'; return false; } /** ok, la rischiesta ha avuto una risposta */ if($result[0]) { $response-> = $result[1]; $response->fullname = $result[2]; $response->status = JAUTHENTICATE_STATUS_SUCCESS; $response->error_message = $result[3]; } Pagina 69 di 127

70 else { $response->status = JAUTHENTICATE_STATUS_FAILURE; $response->error_message = $result[3]; } } }?> Pagina 70 di 127

71 6.1.2 File xml di configurazione Qui di seguito verrà riportato il file di configurazione utilizato per integrare il plugin all'interno di joomla. File: LdapWebService.xml contenuto: <?xml version="1.0" encoding="utf-8"?> <install version="1.5.0" type="plugin" group="authentication"> <name>authentication - LdapWebService</name> <author>joomla! Project</author> <creationdate>november 2005</creationDate> <copyright>copyright (C) Open Source Matters. All rights reserved.</copyright> <license> GNU/GPL</license> <author >admin@joomla.org</author > <authorurl> <version>1.5</version> <description>autenticazione tramite un Web Service</description> <files> <filename plugin="ldapwebservice">ldapwebservice.php</filename> </files> Pagina 71 di 127

72 <params> <param name="wdsl" type="text" size="50" default=" label="indirizzo del wdsl" description="immettere l'indirizzo del descrittore del web service" /> </params> </install> Pagina 72 di 127

73 6.2 Guida alla configurazione del Plug-in Qui verrà illustrato e spiegato come fare per installare e configurare il plugin da me implementeto. Per far funzionare il tutto si devono soddisfare le seguenti condizioni: Aver installato: Lamp Cms joomla sulla macchina avere accesso al Web Service di Unina. Dopo di che accedere alla prte amministrativa di joomla, tramite l'interfaccia di login lato back-and e inserendo le credenziali. Se il login ha avuto successo ci troveremo nella sezione del back-and del cms joomla: Pagina 73 di 127

74 Figura 19: Interfaccia Jooma, Sezione Amministrazione Dopo di che dal menù in alto, sezione Estenzione, selezioniamo "installa\disistalla" come mostrato di seguito: Figura 20: Interfaccia di joomla, Menu Installa/disistalla Pagina 74 di 127

75 Dopo di che ci troveremo nella sezione delle Estenzioni, qui vengono mostrate tutte le estenzioni installate nel cms joomla, divise per categoria, con delle varie statistiche: versione, compatibilità, attiva/disattiva ecc... Noi ci troviamo nella paggina principale dove ci permette di aggiungere una nuova estenzione: Figura 21: Interfaccia di Joomla, installazione estenzione tramite l'interfaccia intuitiva e semplice selezionare il pacchetto del plugin fornito e cliccare su "carica file & installa". Pagina 75 di 127

76 Se tutto è andato bene uscirà il seguente messaggio: Figura 22: Interfaccia di Joomla, estenzione installata con successo altrimenti al posto del messaggio di successo, uscira il nome dell'errore evidenziato non in blu ma in rosso. In questo caso riferirsi alla documentazione ufficiale, per evitare di commettere ulteriori errori. Dopo aver installato l'estenzione (plugin), ritornare nella home dell'amministratore. Pagina 76 di 127

77 andare nel menu "estenzioni", ma questa volta fare clik su "gestione plugin". Figura 23: Interfaccia di Joomla, menù Gestione Plugin Pagina 77 di 127

78 Ci troveremo un elenco di tutti i plugin installati e funzionanti. Figura 24: Interfaccia joomla, lista plugin Da qui si può decidere cosa fare di un plugin, o meglio si accede alla pagina di configurazione di ogni plugin. Pagina 78 di 127

79 Cercare il plugin appena installato e cliccare sopra al nome, per accedere alla pagina di configurazione. Figura 25: Interfaccia configurazione plugin LdapWebService oltre ai valori standard che possiede ogni plugin (lato sinistro), vi sono paramatri avanzati sul lato destro, nel nostro caso vi è solo la posizione del "wdsl" necessaria per poter comunicare con il web service. Una volta effettuata la configurazione il gico è fatto, si potrebbe anche uscire e utilizare finalmente il nostro plugin. Pagina 79 di 127

80 Ultimo accorgimento, joomla di defoult possiede un plugin che registra automaticamente nel database locale tutti gli utenti che vengono autenticati con altri plugin. Nel nostro caso deve essere disattivato, per non duplicare le informazioni e per non contaminare la gestione degli utenti del DB locale. Per fare ciò si deve ritornare nella sezione "gestione plugin", cercare il plugin : User Joomla Figura 26: Interfaccia joomla, plugin: User joomla Pagina 80 di 127

81 e nella scheda di configurazione, spuntare l'opzione di auto registraizone. Figura 27: Auto Registrazione Utente Joomla Salvare il tutto e uscire dall'interfaccia per poi verificare il corretto funzionamento del plugin. Pagina 81 di 127

82 6.3 How To Tutte le guide che vengono indicate qui, sono state fatte durante la configurazione dell'ambiente di test e durante il lavoro svolto nel porting. Quindi le ripropongo qualora qualcuno dovesse mettere mano al mio lavoro, o reimpostare alcuni servizi del portale web. Di seguito ci sono anche le guide per l'installazione di tutti i tool utilizati durante il mio tirocinio al centro "ScoPE Control Room". Pagina 82 di 127

83 6.3.1 Installazione Lamp: Configurazione per sitemi (debian) Pacchetti da installare: apache2 mysql-server mysql-client php5 libapache2-mod-php5 phpmyadmin: tool per gestire graficamente i vostri DataBase Il comando per effettuare un installazione e molto semplice sudo apt-get install <nome pacchetto> Anche se si può inserire tutti i pacchetti separati da uno spazzio, io preferisco fare le installazioni dei pachetti separatemente per ogni programma. Quindi seguiamo i mini wizard che si avvieranno con l'esecuzione di questi tre comandi. sudo apt-get install apache2 sudo apt-get install mysql-server mysql-client sudo apt-get install php5 libapache2-mod-php5 Pagina 83 di 127

84 Nei wizard verranno chieste, per apache niente; per mysql verrà chiesto la pasword di root da impostare; per php5 verra chiesto, tramite una serie di ozioni, quale server web abinare il pacchetto, noi segneremo apache2. Dopo aver fatto tutto bisogna vedere se funziona tutto, ma prima riavviamo i servizi principali: sudo /etc/init.d/apache2 restart sudo /etc/init.d/mysql restart dopo il riavvio dei servizi possiamo verificare se mysql funziona, basta che inseriamo un semplice comando da shell di linux: ~ mysql -u root -p vi chiederà la password di root, che è stata inserita nel wizard durante l'installazione, dopo di che se funziona correttamente la schell diventerà: mysql> Con il comando "sql" che segue show databases; vi elenchera tutti i database che sono presenti nel nostro DatabaseSystem dovrebbero uscire solo il db di configurazione: [immagine] poi per uscire esequire il seguente comando: quit; Pagina 84 di 127

85 dopo aver verificato che mysql funziona, possiamo passiamo al PHP. Per verificare che php funzioni dobbiamo creare un nuovo file nella cartella che apache riconosce come root del vostro localhost, se rimangono le impostazzioni base, la cartella è :/var/www/ Andiamo in questa cartella e creiamo un file che chiameremo index.php il cui contenuto sarà: <?php phpinfo();?> questo lo possiamo fare con un semplice editor oppure scrivendo questa riga da terminale: cd /var/www; gksudo chmod 775./ ; echo <?php phpinfo();?> > index.php; Questo dovrebbe automatizzare il tutto! Dopo di che aprite un Browser-Web e nella barra degli indirizzi scrivete: dovrebbe uscire una pagina contenete tutte le informazioni riguardanti il modulo PHP installato. In caso contrario, si è sicuramente verificato un errore, durante la procedura di installazione. Fatto ciò per controllare che tutto il sistema Ldap sia correttamente installato e funzionante, si deve verificare che il modulo php riesca a comunicare con mysql. Prima di controllare si deve modificare il file di configurazione del modulo php: il file Pagina 85 di 127

86 php.ini che sta nella cartella: /etc/php5/apache2/ Visto che si deve modificarlo, aprirlo con i diritti di amministratore, o usare il seguente comando: sudo gedit /etc/php5/apache2/php.ini Questo comando aprirà "gedit" si può usare qualsiasi edito di testo per effettuare questa modifica. Se nonavete gedit o non funziona, potete usare "vi" che c'è sempre in una distribuzione linux, il comando diventerà: sudo vi /etc/php5/apache2/php.ini Una volta aperto il file, il primissimo controllo che si deve fare, è la configurazione delle estensioni, quindi controlliamo che tutte le estensioni essenziali ci siano. Andiamo nella cartella, precedentemente detta cd /etc/php5/apache2 all'interno troveremo il file di configurazione di php, lo apriamo e cerchiamo questa estensione: "extension=msql.so" Sicuramente la troviamo, ma potrebbe essere che sia commentata, se e' commentata togliere il commento ";" altrimenti lasciate stare. Un suggerimento, di solito questo comando risiede alla richa 936, se non vi è in tale locazione non vuol dire che non ci sia. Nel caso non ci sia aggiungere la riga cercatta così come. Dopo aver fatto la modifica, salvare e chiudere il file "php.ini". Ora per verificare praticamente che php comunichi con mysql, si deve scrivere un piccolo programmino che cerchi di connettersi al database, o più facilmente Pagina 86 di 127

87 installiamo un utiliti, che ci permette di lavorare con i database a livello grafico. Il mio consiglio e "PhpMyAdmin", scitto in interamente in php. Non è un tool essenziale per il corretto funzionamento di "Lamp", ma aiuta con la gestione dei database. PHPMYADMIN Figura 28: PhpMyAdmin Interfaccia Utente principale Pagina 87 di 127

88 Installiamo ora un gestore grafico per DB, che vi aiuterà a gestire al meglio Mysql. Il pacchetto è: sudo apt-get install phpmyadmin Dopo di che lasciate fare tutto a lui. Anche qui dovrebbe partire un pocolo wizard, come sempre seguide le istruzioni che vi dice, e rispondete alle domande che vi vengono poste. L'installazione automatica non vi mette la cartella di "PhpMyAdmin" nella "default root" /var/www che viene raggiunta da apache, quindi dobiamo mettere un link simbolico, che permetta ad apache di raggiungere il nuovo gestore appena installato. Quindi dopo l installazione scrivere questa riga per abbilitare PhpMyAdmin ad essere raggiunto da Apache2, o meglio per creare il link. sudo ln -s /usr/share/phpmyadmin /var/www/phpmyadmin se la cartella di origini :"/usr/share/phpmyadmin", non è quella giusta (prima di effettuare il comando verificare se lo è); sostituitela con la cartella giusta. Fatto ciò tutto dovrebbe andar bene, in caso di errori andate sulla documentazione ufficiale : "" Un accorgimento, gli errori derivanti potrebbero essere causati da permessi non corretti. Se non si hanno specifiche richieste sui permessi, impostare l'intera cartella a 775 (o 755), in questo modo: sudo chmod 775 -R /usr/share/phpmyadmin per evitare che non riesca ad accedere al file di configurazione. Dopo di che, riavviamo il demone apahe2 e di mysql sudo /etc/init.d/mysql restart Pagina 88 di 127

89 sudo /etc/init.d/apache2 restart (in redat httpd è il nome del servizio) Dopo aver installato, ci troveremo il tool all'indirizzo: " (attenzione l'indirizo e case sensite) Vi troverete a dover inserire delle credenziali, a meno che durante il wizar non avete impostato diversamente. Figura 29: PhpMyAdmin Interfaccia Login con accesso da amministratore si posso fare molte cose: creare un nuovo database, quadrato rosso come visto nella prima figura creare uno nuovo gruppo o nuovo utente: Pagina 89 di 127

90 Figura 30: Creare nuovo Gruppo o Utente creare e configurare dettagliatamente i campi di una tabella: Figura 31: Creare i campi di una tabella Pagina 90 di 127

91 configurare i permessi di un nuovo utente : Figura 32: Impostazioni dei permessi di un utente è molto altro ancora. Per ulteriori approfondimenti riferirsi alla documentazione ufficiale, o alla grandissima comunita di questo tool. " Pagina 91 di 127

92 6.3.2 Cacti installazione da repository del tool "cacti". Pacchetto: cacti-spine per installare sudo apt-get installa cacti-spine e seguire il mini wizard che parte subito dopo l installazione( o durante) Dopo si devono effettuare due controlli fondamentali: 1)controllare che abbia installato il DB in Mysql, con il comando: mysql -u root -p entriamo in mysql, poi vediamo i database presenti, con il seguente comando: show databases; che vi mostrerà tutta la lista dei database presenti, ci dovrebbe essere anche cacti Se avete particolari permessi per Mysql, ricordate di dare pieno accesso al Db: cacti a cacti. 2) aprire un browser e andare all'indirizzo partira un breve wizard dove non bisogna modificare praticamente niente, visto che ci sono i link ai sorgenti dei programmi e protocolli usati da cacti. Pagina 92 di 127

93 Figura 33: Wizard install di cacti, prima pagina In questa pagina permette di indicare se è una nuova installazione o un aggiornamento, fecendo anche un riepilogo di alcuni dati riguardante il sistema operativo e i dati del database a cui accederà per il suo funzionamento. Pagina 93 di 127

94 Figura 34: Wizard installa di cacti, seconda facciata Nella seconda pagina, visualizza un riepilogo di tutte le locazioni più importante tra cui dove reperire i tool che usa per il monitoraggio, ES: rrdtool, snmp ecc... Pagina 94 di 127

95 Andando avanti si potrà accedere con le credenziali iniziali login/pw=admin/admin Che dovranno esser modificate subito, stesso cacti avviera la procedura di modifica password, per evitare che c'è ne dimentichiamo. Dopo la modifica della password cacti e pronto. Figura 35: Pagina principale di cacti Pagina 95 di 127

96 Cacti di default si mostra con il monitoraggio della macchina "localhost" per controllare il funzionamento dello stesso nel monitorare un dispositivo. Al primo accesso si avrà la configurazione di default, ma stesso dall'interfaccia si è in grado di configurare cacti a piacimento. Nel setting dell interfaccia è possibile fare tutto quello che si vuole.vi è anche una sezione "Utiliy" dove si può accedere ai log e ad altre sezioni utili. Figura 36: Interfaccia di cacti, Utility Pagina 96 di 127

97 CRON Per rendere il monitoraggio di cacti sempre attivo, si ricorre ad un'altro tool: "CRON" che permette di eseguire, comandi da schell a cadenze periodiche. Quello che interessa è che il file "poller.php", si deve forzare il suo avvio ogni 5min, per permettere a cacti di funzionare meglio. Per inserire un comando nel toll Cron, bisogn configurare il file "crontab". Le locazioni che ci interessano sono: /etc/init.d/cron -> servizio /etc/crontab -> Script( listaistruzioni) la riga da inserire in crontab, dopo aperto con il seguente comando sudo gedit /etc/crontab e: (senza i ") "*/5 **** php /usr/share/cacti/site/poller.php > /usr/share/cacti/site/poller.log 2>&1" o se nn va provate a mettete quest altra. "*/5 **** php /usr/share/cacti/site/poller.php-> forza/dev/null 2>&1 " Ricordate che il tempo per verificare il fuzionamento di un nuovo dispositivo, e di circa 5m cioe' il tempo che intercorre tra un interrogazione e un'altra. tenre presente che all'inserimento di un nuovo dispositivo il tempo di ricerca potrebbe richiedere piu' cicli di interrogazione. quindi aspettare almeno una 30' di minuti. Pagina 97 di 127

98 controllare sempre anche il log di cacti presente nella sezione "System Utilites". che mostra tutte le operazioni del poller.php. Il log mostra anche eventuali "worning", utili a capire cosa non funziona perfettamente durante il monitoraggio dei dispositivi. Prima di inserire vedete se il file "poller.php" si trova veramente nella cartella che state indicando, altrimenti il monitoraggio non funziona. Se non si trova lì cambiate il path /usr/share/cacti/site/poller.php con quello vostro. ATTENZIONE ci potrebbero essere problemi con i permessi di accesso a questo file, controllare sempre nel log o in caso di sicurezza dare 775 come permessi. Pagina 98 di 127

99 6.3.3 Tomcat (guida per sistemi Debian) Apache Tomcat (o semplicemente Tomcat) è un web container open source sviluppato dalla Apache Software Foundation. Implementa le specifiche JSP e Servlet di Sun Microsystems, fornendo quindi una piattaforma per l'esecuzione di applicazioni Web sviluppate nel linguaggio Java. La sua distribuzione standard include anche le funzionalità di web server tradizionale, che corrispondono al prodotto Apache. Tomcat non è l'unico Application Server per Servlet/JSP in circolazione, ha la licenza "open" ed è anche il più diffuso, quindi ha una comunita molto grande che lo sostiene. Cosa da considerare in caso di problemi durante l'instllazione o l'utilizzo di un software. Questa guida servirà ad installare Apache Tomcat utilizzando i pacchetti precompilati di Ubuntu prelevabili dal repository Universe. Prima di iniziare con la procedura di installazione di tomcat dobbiamo assicurarci di aver installato la java vitual machine e la jre, nel dubbio eseguiamo il seguente comando per installare il pacchetto jdk che contiene tutto il necessario: sudo apt-get install sun-java6-jdk dopo di che si può passare all'installazione del pacchetto di tomcat, installeremo la versione più stabile al momento: sudo apt-get install tomcat6 Pagina 99 di 127

100 la procedura automatica di installazione, dovrebbe fare tutto, ma si potrebbe verificare qualche problema con lo script di avvio del servizio. In tal caso creare uno script per init.d per fa si che il demone di tomcat venga attivato all'avvio o comunque dia la possibilità di avviarlo, arrestarlo e riavviarlo. Crearlo in /etc/init.d/tomcat con l'editor di testo preferito e copiare quanto segue : #!/bin/bash # Startup script for the Tomcat server # chkconfig: # description: Starts and stops the Tomcat daemon. # processname: tomcat # pidfile: /var/run/tomcat.pid # See how we were called. case $1 in start) export JAVA_HOME=/usr/lib/jvm/java sun/ export CLASSPATH=/usr/local/tomcat/lib/servlet-api.jar export CLASSPATH=/usr/local/tomcat/lib/jsp-api.jar export JRE_HOME=/usr/lib/jvm/java sun/ echo "Tomcat is started" sh /usr/local/tomcat/bin/startup.sh ;; stop) export JRE_HOME=/usr/lib/jvm/java sun/ sh /usr/local/tomcat/bin/shutdown.sh echo "Tomcat is stopped" ;; restart) export JRE_HOME=/usr/lib/jvm/java sun/ sh /usr/local/tomcat/bin/shutdown.sh echo "Tomcat is stopped" Pagina 100 di 127

101 sh /usr/local/tomcat/bin/startup.sh echo "Tomcat is started" ;; *) echo "Usage: /etc/init.d/tomcat start stop restart" ;; esac exit 0 Da notare che ci sono dei riferimenti, nello script, alle variabili d'ambiente che indicano a tomcat dove trovare java, eventuali problemi sul funzionamento di tomcato potrebbero derivare dalle non corrette informazioni all'interno di questo script, quindi prima di registrare lo stesso, controllare che la vostra java virtual machine si trovi nelle posizioni indicate. Prima di avviare lo script, impostare dei permessi che ne permettino l'esecuzione, eseguite il seguente comando, per impostare i permessi a tutti gli utenti: sudo chmod 775 /etc/init.d/tomcat Dopo aver scritto lo script, e dato i permessi possiamo avviare il servizio, tramite il seguente comando: sudo /etc/init.d/tomcat start Se la configurazione è stata effettuata correttamente puntando all'indirizzo si dovrebbe avere la pagina di benvenuto di tomcat. Per accedere al pannello amministrativo di Tomcat è necessario attivare Tomcat Manager (nel caso non lo si trova gia installato lo si può installare dal repositori tramite il pacchetto tomcat6-nanager). Pagina 101 di 127

102 Per attivare il pacchetto amministrativo si deve creare un utente "amministratore" nell'archivio utenti di tomcat. Per farlo basta andare a modificare il file tomcat-users.xml che risiede nella cartella: /usr/share/tomcat/skel/conf/ lo si può aprire con un qualsiasi editor di testo. Il file ha la struttur di un file "xml". Prima di creare una voce utente, si deve creare il ruolo di "manager" e di "amministratore", basta copiare le seguenti riche: <role rolename="manager"/> <role rolename="admin"/> mentre per creare l'utente con i ruoli di admin e manager, inserire: <user username="your USERNAME " password="your PASSWORD" roles="admin,manager"/> Per dare all'utente un unico ruolo, come admin, basta impostare ala proprietà roles un solo ruolo: <user username="your USERNAME " password="your PASSWORD" roles="admin"/> Fatto questo, chiudere il file e salvere, dopo di che per accedere al pannello di controllo di tomcat manager digitare il seguente indirizzo vi chiedere delle credenziali, inseritele ed ecco a voi la schermate di gestione delle servlet di tomacat. Pagina 102 di 127

103 Figura 37: Tomcat6 - Gestore Grafico delle Servlet Pagina 103 di 127

104 6.3.4 Tomcat : installazione modulo Axis Innanzi tutto diciamo che Axis e un modulo di apache, ed è il framework di sviluppo per i web service mentre Tomcat è l'application server dove avviene l'esposizione dei web server. Quindi Axis si appoggia a tomcat per esporre i web service. Axis viene utilizato nella fase di testing del plugin per creare un web service che simula quello di unina. L'installazione è molto semplice, dall'ambiente viene visto come applicativo di tomcat, quindi basta effettuare il deploy del pacchetto compresso tramite l'interfaccia di manager di tomcat. Figura 38: Interfaccia di Tomcat per il Deploy di un applicazione Pagina 104 di 127

105 oppure andare nella cartella delle webapps di tomcat, copiare la cartella di axis. /usr/share/tomcat6/webapps/ dopo aver effettuato questa operazione, si deve verificare che axis funzioni. Per verificare ciò basta vedere se all'indirizzo axis è accessibile, dovrebbe visualizare questa pagina: Figura 39: Home Page di Axis fatto ciò dovrebbe funzionare correttamnte. Pagina 105 di 127

106 6.3.5 Vmware: installazione "player"&"workstation" Innanzi tutto andarsi a scaricare l'applicazione sul sito nella sezione dawload o produzione scaricarsi vmware player, per riuscire a scaricarsi l'applicativo, bisogna registrarsi e accettare la licenza d'uso prima di ricevere il software. Dopo di che eseguire l'applicativo, l'installer fa partire un wizard che ti permettera di configurare a piacimento il tool. I passi del wizard sono i classici di ogni wizard di installazione software, locazione, cartella predefinita per le virtual machine, ecc... Di seguito vi spiegherò come creare una macchina virtuale, tramite l'utilizzo del wizard di vmware player. Il wizard e del tutto simile a quello che offre Workstation. Pagina 106 di 127

107 6.3.6 Vmware: creare un virtual machine con OS Ubuntu Una volta installato il software di virtualizazzione, creare una macchina virtuale diventa abbastanza semplice. Per prima cosa si deve analizare la propria macchina fisica per determinare se è in grado di supportare anche quella virtuale, e determinare anche quante risorse gli può dare. Dopo l'analisi e prima di avviare il software di virtualizzazione, ci dobbiamo procurare il Sistema Operativo che voglio far partire sulla nostra macchina virtuale, fatto ciò si avvia il software che si presenta così: Figura 40: vmware - home del tool Pagina 107 di 127

108 Click su "create a new virtual machine",vi si aprirà un wizard di configurazione. La prima cosa che vi chiederà è: come si vuole installare l'so, se da CD-ROM\DVD o tramite ISO. Figura 41: vmware - dove si trova il SO da installare Pagina 108 di 127

109 Fatta qusta scelta si passerà ad impostare i dati di utente di root, che per un sistema Linux e importantissimo. Figura 42: vmware - Dati utente root del SO Pagina 109 di 127

110 Dopo di che ci permetterà di impostare il nome della VM, e dove la vogliamo memorizare. Figura 43: vmware - Dove memorizare la VM Pagina 110 di 127

111 Dopo di che si deve configurare la dimensione dell'hdd virtuale, e quale formato del file si decide di usare, mediamente si utilizano sui 20/40 gb per la creazione di una VM per un ambiente di test, ma in base al vostro spazzio o quello che si deve fare si può inserire qualsiasi dimensione. La seconda opzione e se si vuole dividere il filesystem virtuale in più file, o rimanere che abbia una dimensione fissa. Ovviamente le due scelte hanno pro e contro. Figura 44: vmware - Dimensione hdd virtuale Pagina 111 di 127

112 Arrivati a questo punto siamo quasi alla fine, se ci accontentiamo della configurazione custom della VM, basta clickare su "finish" e il software passera alla procedura di installazione del SO. Altrimenti si fa click su "customize hardware" per personalizare le impostazioni hardware della macchina. Figura 45: vmware - riepilogo hardware macchina virtuale Pagina 112 di 127

113 Come ad esempio la dimensione che si riserva per la Ram. Per questo motivo prima di installare una vm si deve conoscere le risorse diponibili di quella fisica. Oltre alla ram il wizard permette di configurare ogni componente hardware che si vuole "virtualizare", anche il numero di processori. Figura 46: vmware - impostazione hardware personalizata Finita la configurazione personalizata si ritorna alla schermata del riepilogo delle componenti hardware e si fa click su "finish", e il tool si occupera di virtualizare la macchina e avviare la procedura di installazione del s.o. scelto nalla prima fase del wizard. Pagina 113 di 127

114 6.3.7 Joomla: installazione & configurazione PREMSESSA: Da tenere presente che il cms joomla senza la piattaforma Lamp che lo supporta non funziona, quindi prima di continuare a seguire questa guida, ci si preoccupi di installare è configurare correttamente Lamp. Per installare il cms joomla è molto semplice, innanzitutto scaricare l'ultima versione stabile o la versione 1.5, che è ustata nel nostro portale web. Scompattare il file zip, e inserire tutta la cartella nella cartella del Server Web Apache: /var/www. Cerchiamo di rinominare prima la cartella che ci siamo scaricati dando un nome semplice, Es:joomla. Una volta effettuato il posizionamento del pacchetto di joomla nella cartella "www",accederemo al cms tramite l'indirizzo, con un qualsiasi browser, è si presenterà un piccolo wizard da seguire obligatoriamente, che serve a effettuare una prima configurazione. La prima schermata sarà: Selezionare la lingua, sia del back-and sia del front-and: Pagina 114 di 127

115 Figura 47: Joomla- Selezione lingua Dopo di che andando su avanti, il wizard effettuerà dei controlli sui servizi che servono per far funzionare correttamente il cms. Controlla se vi è presente il php, la versione, i supporti concessi, oltre a controllare i servizi a cui si più aganciare, controlla anche le impostazioni del file di configurzione di php, per meglio capire se si sta in fase di pubblicazione o di testing. Ovviamente se manca qualcosa di importante, o qualche impostazione rende il cms joomla vulnerabile, l'interfaccia suggerira di modificare tale impostazione. Pagina 115 di 127

116 Figura 48: joomla - contrplli di preinstallazione Prima di questa schermata ci viene presentata la licenza uso, che deve essere letta, poi si passa avanti. Dopo di che si passa ad impostare il database, per impostare il Database, basta dirgli dove lo si raggiunge:tipo,nome Host (localhost, nel nostro caso), dati di un utente che abbia i permessi di creare un nuovo DataBase. Il cms joomla permette di installare nel proprio spazio, più copiè, per fare ciò basta che quando si è in questa perte di configurazione, si acceda a proprieta avanzate in fondo alla pagina, e si setti un prefisso a tutto il database, questo per tutte le copie (ovviamente ad ogni copia un prefisso differente). Pagina 116 di 127

117 Figura 49: joomla - Configurazione del DataBase In questa schermata di imposta il servizio ftp automatico offerto dal cms. Nel nostro caso il servizio non viene sfruttato, visto che si ha accesso diretto alla macchina su cui si sta lavorando. Lo si sfrutta quando non si conoscono client ftp, o ci si avvicina per la prima volta ai CMS, e quindi non si conosce la struttura del filesystem dello stesso. Pagina 117 di 127

118 Figura 50: joomla - Configurazione Ftp Dopo l'ftp si passa a configurare i dati del nostro nuovo portale: Titolo, credenziali del Super Amministratore è la nostra , nel caso qualche utente ci volesse contattare. Pagina 118 di 127

119 Figura 51: joomla - Configurazione dati Sito Successivamente si passa alla schermata di conclusione,che ci dice che tutto è andato bene, joomla è installato correttamente e per iniziare ad usarlo dobbiamo cancellare la cartella "installation", anche se io consiglio di mettere un prefisso. Figura 52: joomla - messaggio di completamento installazione. Pagina 119 di 127

120 Nel caso ci dimenticassimo di cancellare quella cartella joomla non riesce a funzionare, poichè cercherebbe sempre di effettuare il wizard. Partendo da questa posizione invece ci ricoderebbe di cancellare la cartella installation. Figura 53: joomla - Cancellare cartella "installation" Dopo di che il cms è installato e si può raggiungere il front-and all'indirizzo : e il Back-and all'indirizzo: il back-and ci permette di inserire i contenuti e di configurare il nostro cms come meglio ci piace o ci è più consono al suo utilizzo. Pagina 120 di 127

121 6.3.8 Ripristino dei servizio di Statistiche del Portale Wifed Nella fase del porting si è dovuto trasportare anche il servizio di statistiche dei dispositivi wi-fi che il portale monitorava. Questa operazione non è molto semplice, per effettuare un corretto ripristino del servizio, per prima cosa bisgno installare tomcat sulla macchina che espone i dati, o meglio quella che contiene il cms joomla. Per un aiuto vedere la guida al paragrafo installazione di Tomcat6 prima di continuare, si deve dire che il servizio di statistica wi-fi viene garantito da due applicazioni DataServer.jar, DataClient.jar queste applicazioni java hanno una il compito di raccogliere le informazioni e l'altro di esporre sotto forma di grafici le stesse informazioni. Il DataServer.jar deve risiedere nella "home" della macchina Wifed02 Il DataClient.jar deve risiedere nella "home" della macchina Wifed03 Passiamo alle singole configurazioni delle applicazioni: WIFED02: L'applicazione viene fornita oltre che dal jar, di altri due file: server_config.dtd server_config.xml che permettono di configurare l'applicazione su alcuni spetti. Dopo aver configurato il DataServer, modificando adeguatamente il file "server_config.xml" lo si può lanciare con il seguente comando: Pagina 121 di 127

122 /> java -jar DataServer.jar > logfile & questo tipo di comando gira tutto l'outuput dell'applicazione in un file "logfile" che risiede nella cartella dell'applicazione. Per terminare il DataServer è sufficiente uccidere il relativo processo. Tramite il comando netstat -ltup è possibile conoscere l'elenco delle porte sulle quali vi sono processi in ascolto. Da questo elenco si può identificare il PID del DataServer. Successivamente è sufficiente uccidere il processo con il comando kill -9 <PID> dove <PID> è l'identificativo del processo precedentemente identificato. WIFED03: In questa macchina va installato il DataClient.jar che è accompoagnato anchesso da altri file: dataclient_config.dtd dataclient_config.xml rrdb.sql i soliti due fai per la configurazione, è un ".sql" che è il dump del database che usa per creare i grafici da esporre tramite il cms joomla. Quindi prima di avviare il DataClient, bisogna creare il Database, per farlo accedere alla shell di comanfo e eseguire i deguenti comandi: /> mysql -u root -p mysql> source "</pathname/>rrdb.sql" Dove </pathname/> è il percorso completo al file rrdb.sql. Questi due comandi ci permettono di creare il database necessario al corretto funzionamento del programma. Pagina 122 di 127

123 Come per il DataServer anche per il DataClient è necessario configurare il file dataclient_config.xml. L'esecuzione e la terminazione del DataClient è analoga a quella del DataServer. E' quindi possibile digitare il seguente comando bash per eseguire il DataClient : /> java -jar DataClient.jar > logfile & Dopo di che il tutto dovrebbe funzionare correttamente. Ricordiamo di effettuare il deploy, tramite l'interfaccia di tomcat delle applicazioni: Wistat Wistat Admin sempre fornite con le applicazioni DataServer.jar e DataClient.jar. Pagina 123 di 127

124 Queste permetto di accedere tramite interfaccia alle impostazioni delle statistiche. Di seguito il deploy, tramite interfaccia web di tomcat: Figura 54: Interfaccia di Tomcat: deploy di un applicazione web Pagina 124 di 127