Universit`adegli Studi di Padova Facolt`adi Scienze MM.FF.NN. Laurea in Informatica
Sviluppo di un modulo di controllo di processo in Nagios
Candidato: Relatore: Francesca Mabilia Claudio Enrico Palazzi
Anno Accademico 2010-2011 Ad una persona molto speciale Matteo Indice
1 Introduzione1 1.1 Motivazioni di sviluppo...... 2 1.2 Contesto aziendale ...... 3 1.3 Scopo dello stage...... 4
2 Nagios5 2.1 Funzionamento ...... 6 2.1.1 Esempio di servizio...... 7 2.2 Caratteristiche ...... 7
3 Nagios addon: NagVis 11 3.1 Funzionamento ...... 11 3.1.1 MKLivestatus, check mk...... 12
4 Analisi dei requisiti 15 4.1 Descrizione del progetto ...... 15 4.2 Requisiti di sistema...... 16 4.3 Modalit`ad’uso ...... 17 4.4 Inserimento processo...... 17 4.5 Funzioni del prodotto...... 19 4.6 Requisiti degli utenti...... 19 4.7 Use case...... 20 4.7.1 Use case Monitora Processi ...... 20 4.7.2 Use case Crea Processi...... 22 4.8 Requisiti...... 23
5 Progettazione 27 5.1 Architettura...... 28 5.1.1 Architettura Nagios...... 29 5.1.2 Architettura NagVis ...... 31
i INDICE INDICE
5.2 Definizione componenti...... 33 5.2.1 Modulo in Nagios...... 33 5.2.2 Modulo in NagVis ...... 41
6 Test 49 6.1 Test effettuati...... 49 6.2 Collaudo...... 51
7 Installazione plugin 53 7.1 Configurazione Nagios ...... 53 7.2 Configurazione NagVis...... 54
8 Utilizzo del plugin 57 8.1 Modulo Nagios ...... 58 8.2 Addon NagVis...... 60 8.2.1 Creare un processo...... 65
9 Conclusioni 69 9.1 Consuntivo ...... 69 9.2 Applicazioni del software...... 70 9.3 Considerazioni personali ...... 71
A Framework ITIL 73
B Installazione MKLivestatus 77
C Installazione NagVis 83
Glossario 87
Bibliografia 89
ii Elenco delle figure
3.1 Funzionamento check mk ...... 13
4.1 Use case monitora processi ...... 20 4.2 Use case crea processi ...... 22
5.1 Comunicazione Nagios - NagVis ...... 27 5.2 Struttura configurazione Nagios ...... 28 5.3 Struttura Nagios ...... 29 5.4 Esecuzione CGI Nagios ...... 30 5.5 Diagramma delle attivit`aper la creazione di processi in NagVis . . 32 5.6 Struttura dei file Nagios utilizzati ...... 33 5.7 Struttura dei file NagVis utilizzati ...... 41
8.1 Nagios home page ...... 57 8.2 Link per visualizzare i processi ...... 58 8.3 Visione globale dei processi in Nagios ...... 59 8.4 Visione dettagliata dei processi in Nagios ...... 60 8.5 NagVis home page ...... 61 8.6 Visione globale dei processi in NagVis ...... 62 8.7 Visualizzazione NagVis del processo ”primo” ...... 63 8.8 Men`uOpen di NagVis ...... 64 8.9 Men`uActions di NagVis ...... 64 8.10 Men`uOpen di NagVis ...... 65 8.11 Men`uActions di NagVis ...... 66 8.12 Men`uActions di NagVis ...... 67
9.1 Consuntivo con le preventivate e quelle effettive...... 70
A.1 Framework ITIL ...... 75
C.1 WUI di NagVis ...... 86
iii ELENCO DELLE FIGURE ELENCO DELLE FIGURE
iv Elenco delle tabelle
4.1 Elenco dei requisiti ...... 26
9.1 Tabella riassuntiva ore preventivate per le attivit`adi stage. . . . . 69
B.1 Tabella dei parametri nagios.cfg per Livestatus ...... 82
v Capitolo 1
Introduzione
Chiunque abbia avuto l’opportunit`adi amministrare una rete con un certo numero di nodi di rete, o comunque una rete in cui sono attivi dei servizi critici, ha certamente avuto la necessit`adi monitorare gli elementi di criticit`a della stessa. Esistono situazioni dove l’interruzione di un servizio pu`oportare un grosso danno economico, commerciale o d’immagine. Il monitoraggio `efondamentale per numerosi motivi, tra i quali:
• In caso di reti complesse solo una visione d’insieme pu`odare la sensazione di come stanno andando le cose
• I dati raccolti dal monitoraggio possono essere utilizzati per analisi di vario genere, per spiegare situazioni accadute o prevenire problemi futuri
Chi si fosse trovato in tale situazione ha pensato quindi a delle soluzioni. Queste sono solitamente, avendo costi elevati, vengono impiegate solo dove la rete da amministrare `everamente complessa o dove la criticit`adei servizi `e molto elevata. Inoltre le soluzioni non sempre sono semplici, anzi sono quasi sempre macchinose da avviare e da utilizzare e per ridurre la complessit`adella situazione a volte portano all’inserimento di una serie di servizi aggiuntivi per aiutare gli amministratori di rete nel proprio lavoro. In questo primo capitolo verranno spiegate innanzitutto le motivazioni che hanno spinto l’azienda alla proposta del presente stage, le convenzioni utilizzate per la stesura del documento, il contesto nel quale il progetto andr`ainserito e gli scopi predisposti per la realizzazione del progetto. Verr`aintrodotto inoltre il concetto di processo Nagios. Nel secondo e terzo capitolo verranno spigate le principali funzionalit`adel software Nagios e del rispettivo plugin NagVis. Si passer`apoi alla descrizione delle fasi di analisi e progettazione del plugin. Nel capitolo 6 vengono brevemente esposti i test effettuati sul prodotto sviluppato
1 1.1. MOTIVAZIONI DI SVILUPPO CAPITOLO 1. INTRODUZIONE
ed i risultati a cui hanno portato. Nel settimo paragrafo viene spiegato come i moduli sviluppati vengono installati e nel capitolo seguente grazie all’aiuto di alcuni screenchot viene illustrato il funzionamento del plugin prodotto al termine del periodo di stage. L’ultimo capitolo `ededicato alle conclusioni alle quali ha portato lo sviluppo del progetto dal punto di vista tecnico e personale.
1.1 Motivazioni di sviluppo
All’aumentare del grado di complessit`adella rete e del numero di macchine collegate, anche le attivit`api`usemplici diventano un problema. Ad esempio, vorremo sicuramente sapere se i servizi sono tutti regolarmente in funzione o se la nostra banda comincia ad essere satura di traffico. Non `ecerto una buona idea collegarsi una per una alle varie macchine e controllarne lo stato, oppure mettersi davanti ad una console dove scorrono i dump degli analizzatori di rete. Per questo, un’architettura di rete sicura deve prevedere anche dei sistemi di monitoraggio centralizzato, in grado di fornire rapidamente un riassunto dello stato globale della rete. Grazie ad essi, `emolto pi`usemplice rilevare eventuali anomalie ed intraprendere le opportune azioni correttive, indagando nel contempo sulle cause dell’anomalia. Tutto questo, all’interno dell’azienda, `egestito da Nagios, il quale fornisce una visione generale di tutti gli oggetti che vengono monitorati. Per lo stesso motivo che ci spinge ad utilizzare un software di monitoraggio `eanche logico pensare che se la rete `emolto estesa si potrebbe desiderare una visualizzazione pi`uschematica dei servizi (o altri oggetti). La scelta deriva dal fatto che per l’espletamento di un unico compito, come ricevere la posta elettronica, in Na- gios `enecessario controllare lo stato di diversi oggetti, il che potrebbe richiedere molto tempo. Avere una visione d’insieme di tutti i processi intesi come compiti che i diversi client devono svolgere, permette di accorciare i tempi di rileva- mento ed individuazione del problema all’interno della rete e di conseguenza la possibilit`adi correzione dello stesso. Per i motivi descritti si `eritenuto necessario lo sviluppo di un modulo aggiuntivo in Nagios che permettesse di monitorare lo stato di tutti i processi in esecuzione nella rete controllata. Questo andr`aad aiutare il personale del supporto ad assistere ciascun cliente in modo pi`uefficiente ed a garantirgli i servizi di cui necessita.
2 CAPITOLO 1. INTRODUZIONE 1.2. CONTESTO AZIENDALE
1.2 Contesto aziendale
L’azienda presso la quale `estato eseguito il lavoro di stage `eInfonet Solutions S.p.a. con sede a Pieve di Curtarolo (PD).
Da quindici anni il Gruppo Infonet garantisce ai propri clienti – aziende del manifatturiero e di servizi, enti pubblici, organizzazioni no-profit – soluzioni su misura per ottimizzare la gestione di piattaforme IT disegnate sulle reali necessit`adi performance e risparmio. Conosce i propri clienti uno per uno. Studia le loro esigenze e confeziona, con perizia minuziosa e con competenze di alto livello, sistemi su misura per garan- tire la massima efficienza di gestione, la sicurezza nella trasmissione e nella conservazione delle informazioni, l’assistenza per accrescere la competitivit`a. Il Gruppo Infonet `epartner affidabile per ogni cliente e non vende prodotti pre- confezionati. Sceglie di progettare soluzioni mirate, di costruire idee che siano la risposta migliore – per efficacia, costi e approccio razionale – alle esigenze di ogni sin- golo cliente. Il Gruppo Infonet offre qualit`agarantita. I pi`uimportanti produttori mondiali di hardware e software per l’Information Technology li ha scelti come partner accreditato. E attraverso il loro lavoro di progettazione possono individuare le migliori tecnologie per dare ad ogni esi- genza la risposta migliore.
L’azienda `esuddivisa in vari gruppi di lavoro appartenenti a diversi settori di competenza: • Support, si occupa di fornire da remoto assistenza informatica di vario genere ai clienti dell’azienda; • Delivery, personale che all’occorrenza effettua gli interventi presso la sede del cliente; • Customer service, si occupa della gestione delle richieste dei clienti e ne ricerca di nuovi; • Controllo e gestione, gestisce la parte amministrativa dell’azienda. Durante lo stage ho potuto osservare come questi lavorino e interagiscano tra loro, quanto una chiara e corretta comunicazione possa essere fondamentale per implementare i servizi desiderati dal cliente nel modo corretto. E` impor- tante che tra il personale non ci siano incomprensioni o scrupoli nel comunicare
3 1.3. SCOPO DELLO STAGE CAPITOLO 1. INTRODUZIONE
delle problematiche di ogni tipo, perch´equesto graverebbe sul servizio erogato e quindi sull’immagine dell’azienda nei confronti del cliente.
1.3 Scopo dello stage
Il progetto si inserisce in un pi`uampio contesto aziendale il quale prevede il rispetto di determinate pratiche per l’erogazione di servizi IT, si tratta del framework ITIL. L’obiettivo del presente stage `equello di sviluppare un modulo di controllo di processo in Nagios. Questa componente aggiuntiva dovr`apermettere agli utenti Nagios di monitorare insiemi di oggetti di rete (nodi e/o servizi) atti ad espletare una funzione pi`uampia. Il suddetto insieme di oggetti verr`aquindi visto come un unico processo con componenti collegate secondo un preciso schema, controllate periodicamente per verificare lo stato globale della funzione a cui sono associate. Ad esempio si pu`oconsiderare il processo di posta elettronica come l’insieme dei servizi necessari affinch´el’utente sia in grado di ricevere le e-mail. Lo stato del processo di ”mail service” sar`aquindi determinato dalla condizione in cui sono i servizi TCP, DNS, SNMP, NRPE etc. che gli appartengono. Qualora anche uno solo di questi servizi fosse in uno stato di criticit`a,l’intero stato del processo risulter`acritico. Lo scopo dello stage `equindi di progettare un prodotto software sotto forma di plugin Nagios che l’azienda possa utilizzare al suo interno, o anche estendere ulteriormente ed adattare alle proprie esigenze.
4 Capitolo 2
Nagios
L’acronimo ricorsivo N.A.G.I.O.S sta per Nagios Ain’t Gonna Insist On Saint- hood. E` un riferimento all’incarnazione originale del software. Questo pro- gramma `estato scritto da Ethan Galstad sulla base di un suo programma precedente, Netsaint, il quale aveva, a suo parere, dei difetti di architettura tali da richiedere la riscrittura del codice. Non contiene funzioni per la gestione della rete ma solo per il monitoraggio di apparecchiature e servizi. Nagios `euna nota applicazione open source per il monitoraggio di com- puter, switch, router, stampanti e altro, ed anche servizi pi`uo meno standard come HTTP, FTP, POP3 e similari. E` fortemente personalizzabile, in quanto i controlli avvengono tramite programmi esterni (plugin) i quali vengono eseguiti ad intervalli regolari. La disponibilit`adel codice sorgente facilita la scrittura di nuovi test, qualora non esistessero gi`a. La sua funzione base `equella di controllare nodi, reti e servizi specificati. Questi comandi eseguono un test sul servizio, verificano se il risultato numerico `econtenuto nel range accettato e lo pubblicano sull’interfaccia web. Una volta rilevato un problema in un dispositivo sotto monitoraggio, il programma `ein grado di segnalare i malfunzionamenti,come specificato prece- dentemente, attraverso la sua interfaccia (Web). E` per`opredisposto anche per spedire una e-mail ad un gruppo di persone definito in precedenza o addirittura di avvisarle attraverso l’invio di un SMS. Tale fase, detta notifica, `eanch’essa fortemente personalizzabile e pu`oessere gestita con un qualsiasi programma esterno al motore di Nagios. In origine Nagios `estato sviluppato per Linux, ma pu`ofunzionare correttamente anche su altre varianti di Unix, `erilasciato sotto la GNU General Public License Versione 2 pubblicata dalla Free Software Foundation.
5 2.1. FUNZIONAMENTO CAPITOLO 2. NAGIOS
2.1 Funzionamento
Le principali componenti di Nagios sono: • I plugins che sono i comandi da eseguire • Gli agenti sono installati sugli oggetti da monitorare consentono l’esecuzione di numerosi check • Addon servono per aggiungere funzionalit`autili al Nagios • L’interfaccia web riassume e mostra tutti i dati raccolti • Nagios interroga gli elementi della rete attraverso degli agenti installati sui vari oggetti. I principali sono NSClient++ per sistemi Windows e NRPE per Linux.
La configurazione si articola nei seguenti files: • hosts.cfg definisce gli host da monitorare • commands.cfg definisce i comandi da utilizzare nei servizi • services.cfg definisce i servizi per ogni host • contacts.cfg definisce i contatti necessari per le notifiche • hostgroups.cfg definisce gruppi di host • contactgroups.cfg definisce gruppi di contatti per le notifiche • timeperiods.cfg definisce i periodi di tempo I plugins corrispondono a dei file alcuni binari cio`everi e propri programmi, altri script, normalmente perl o bash. Ne esistono molti gi`aprecostituiti e pronti all’uso, per monitorare le pi`usvariate entit`a. • CPU, RAM, spazio disco • Database mysql • Eventi particolari nei files di syslog • Carico e numero di processi in un server La vera potenza del Nagios sta nella possibilit`adi scrivere un plugin per monitorare quasi tutto ci`oche si vuole.
6 CAPITOLO 2. NAGIOS 2.2. CARATTERISTICHE
2.1.1 Esempio di servizio define service{ use generic-service host_name host1.dominio.loc service_description telnet check_period 24x7 normal_check\_interval 3 contact_groups admins check_command check_tcp!23 }
check tcp!numero porta TCP `ela sintassi per l’utilizzo del plugin stesso:
• Il comando Check tcp!23 controlla lo stato della porta 23 tcp (telnet) sul- l’host host1.dominio.loc
• Il valore di normal check interval definisce la frequenza (in minuti) con cui viene effettuato il controllo
2.2 Caratteristiche
Alcune delle molte caratteristiche di Nagios suddivise nei principali ambiti sono:
Monitoraggio completo • Capacit`adi monitorare le applicazioni, servizi, sistemi operativi, protocolli di rete, metriche di sistema e componenti di infrastruttura con un unico strumento
• Monitoraggio di servizi di rete (SMTP, POP3, HTTP, NNTP, PING, ICMP, SNMP, FTP, SSH, etc.)
• Monitoraggio delle risorse di sistema (carico del processore, uso dell’hard disk, log di sistema sulla maggior parte dei sistemi operativi, anche per Microsoft Windows tramite NRPE NT).
• Monitoraggio remoto supportato attraverso SSH o SSL encrypted tunnels.
• Script potenti di API consentono di monitorare facilmente applicazioni per- sonalizzate, servizi e sistemi
7 2.2. CARATTERISTICHE CAPITOLO 2. NAGIOS
Visibilit`a
• Visione centralizzata di tutta le infrastrutture IT monitorate
• Informazioni di stato dettagliate disponibili tramite interfaccia web opzionale per la visualizzazione dell’attuale stato, delle notifiche, dello storico dei problemi, dei file di log, etc.
Consapevolezza
• Rilevamento rapido di interruzioni delle infrastrutture
• Avvisi conseguenti allo stato dei servizi (o altro) possono essere inviati al personale tecnico via email o SMS
• Capacit`adi assicurare che le notifiche di allarme raggiungano le persone preposte
• Capacit`adi definire event handlers, ovvero azioni automatiche che vengono attivate all’apparire di un problema o alla sua risoluzione
Rimediare ai problemi
• Avvisi forniscono una comunicazione sui problemi noti e la reazione ad essi
• I gestori di eventi consentono il riavvio automatico di applicazioni fallite, di servizi etc.
Architettura estendibile
• L’integrazione con applicazioni “fatte in casa” e di terze parti `eresa semplice grazie a diverse API
• Centinaia di comunit`adi sviluppo di addons estendono le funzionalit`adi base Nagios
• Semplici plugin permettono agli utenti di sviluppare facilmente nuovi con- trolli per i servizi in base alle proprie esigenze, usando Bash, C++, Perl, Python, PHP, C#, etc.
8 CAPITOLO 2. NAGIOS 2.2. CARATTERISTICHE
Stabile, affidabile e piattaforma di rispetto • Oltre 10 anni di sviluppo attivo
• Vasta gamma per monitorare migliaia di nodi
• Funzionalit`adi “failover” garantisce un controllo non-stop delle componenti dell’infrastruttura IT di importanza critica
• Molti premi, copertura mediatica e riconoscimenti sono prova del valore di Nagios
Vivace comunit`a • Si stima che sia oltre un milione di utenti in tutto il mondo
• Un’attiva comunit`adi mailing list fornisce supporto gratuito
• Le centinaia addons sviluppate dalle comunity estendono le funzionalit`adi Nagios
Codice personalizzabile • Software Open Source
• Pieno accesso al codice sorgente
• Rilasciato sotto la licenza GPL
9 2.2. CARATTERISTICHE CAPITOLO 2. NAGIOS
10 Capitolo 3
Nagios addon: NagVis
NagVis `eun addon per la gestione della visualizzazione del sistema di controllo di rete Nagios. NagVis pu`oessere utilizzato per visualizzare i dati Nagios, ad esempio per raffigurare i processi IT come un sistema di posta elettronica o di un’infrastruttura di rete. Utilizzando i dati forniti da una back-end, in deter- minati intervalli vengono aggiornati gli oggetti posti sulle mappe per riflettere il loro stato attuale. Queste mappe permettono di organizzare gli oggetti da visualizzare in diversi layout:
• Fisico (ad esempio tutti gli host in un reparto)
• Logico (ad esempio tutti i server di un’applicazione)
• Geografica (ad esempio tutti gli host in un paese)
• Processi di business (ad esempio, tutti gli host / servizi coinvolti in un processo)
3.1 Funzionamento
In generale NagVis `euno strumento di presentazione per le informazioni che sono raccolte da Nagios e trasferite usando backend. Le backend supportate sono:
• Mklivestatus (default dal NagVis 1,5)
• NDOUtils / IDOUtils (richiede MySQL)
• Merlin (richiede MySQL)
11 3.1. FUNZIONAMENTO CAPITOLO 3. NAGIOS ADDON: NAGVIS
• Ndo2fs
La backend ottiene le informazioni dal processo di Nagios (mklivestatus o ndo2fs) o da un database (NDOUtils / IDOUtils, Merlin). E` possibile aggiungere tutti gli oggetti di Nagios (Host, Servizi, Hostgroups, Servicegroups) sulle cos`ıdefinite mappe. Ogni mappa pu`oessere configurata attraverso il proprio file di configurazione. E` possibile modificare i file di config- urazione direttamente utilizzando un qualsiasi editor di testo o lo strumento di configurazione web chiamato WUI. Inoltre `epossibile aggiungere alcuni oggetti speciali alle mappe NagVis. Questi oggetti sono le immagini (shape), caselle di testo (textbox) e oggetti che riferiscono ad altre mappe. Ciascuno degli oggetti sulle mappe pu`oessere configurato per soddisfare le esigenze dell’utente. Ad esempio ci sono i link ai frontend Nagios per ogni oggetto che rappresenta un entit`adi Nagios. Questi collegamenti si possono facilmente personalizzare. Vi `eun men`uabilitato di default il quale al passaggio del mouse visualizza le informazioni dettagliate per ogni oggetto. Quest’ultimo pu`oessere facilmente modificato cambiando i modelli che lo definiscono. E` anche possibile disattivare il men`u.Secondo l’impostazione predefinita lo stato degli oggetti viene visu- alizzato utilizzando le icone sulla mappa. E` possibile modificare queste icone (iconsets) aggiungendone dalla home page NagVis oppure crearne di proprie. Lo stato degli oggetti pu`oanche essere visualizzato come linee o gadget. Oltre alle mappe normali c’`ela visualizzazione di automap le quali vien- gono generate automaticamente in base alla configurazione di Nagios. Per utilizzarle bisogna impostare le relazioni gerarchiche in Nagios. Le automap generano un’immagine di sfondo in base alla configurazione, i parametri di configurazione e le relazioni di gerarchia. Dalla versione NagVis 1,5 `epossibile definire automap multiple. Per quanto riguarda la licenza, NagVis `eun software libero; `epossibile ridistribuirlo e / o modificarlo secondo i termini della GNU General Public License versione 2 come pubblicata dalla Free Software Foundation. NagVis `edistribuito nella speranza che possa essere utile, ma senza alcuna garanzia, nemmeno la garanzia implicita di commerciabilit`ao idoneit`aper un particolare scopo.
3.1.1 MKLivestatus, check mk
MKLivestatus utilizza check mk, un nuovo metodo di Nagios-plugin per il recupero dei dati.
12 CAPITOLO 3. NAGIOS ADDON: NAGVIS 3.1. FUNZIONAMENTO
Check mk adotta un nuovo approccio per la raccolta dei dati dai sistemi operativi e dalle componenti di rete. Rende obsoleta NRPE, check by ssh, NSClient e check snmp; ha molti vantaggi, i pi`uimportanti dei quali sono: • Significativa riduzione di utilizzo della CPU sull’host Nagios. • Inventario automatico di elementi da controllare su host. Pi`u`egrande l’installazione di Nagios, pi`uimportante `eavere questi punti. In realt`acheck mk consente di implementare un ambiente di monitoraggio supe- riore a 20,000 controlli/min. Check mk `eun software libero. E` possibile uti- lizzare, modificarlo e ridistribuirlo secondo i termini della licenza GNU GPL versione 2.
Principio di base La figura seguente illustra come funziona check mk. I dati vengono recuperati in quattro fasi:
Figura 3.1: Funzionamento check mk
1. Per ogni host Nagios innesca un controllo attivo per l’intervallo di verifica. Questo controllo attivo richiama check mk come plugin. 2. check mk connette l’host di destinazione tramite TCP. Nell’host il check mk agent recupera tutti i dati pertinenti su quell’host in una sola volta e lo rimanda indietro come testo ASCII. 3. check mk estrae i dati sulle prestazioni e li inserisce direttamente in banche dati round robin. 4. check mk estrae i dati rilevanti, li confronta con livelli di warning/critici e sottopone tutti i risultati del controllo di questo host tramite controlli passivi dei servizi Nagios.
13 3.1. FUNZIONAMENTO CAPITOLO 3. NAGIOS ADDON: NAGVIS
14 Capitolo 4
Analisi dei requisiti
Il seguente capitolo illustra l’analisi dei requisiti effettuata sul capitolato ed inoltre fornisce una descrizione formale di tutti i requisiti e delle funzionalit`a richieste dall’azienda.
4.1 Descrizione del progetto
Nagios R CoreTM `eun sistema Open Source, originariamente progettato per funzionare sotto Linux, atto al monitoraggio delle applicazioni di rete avvisan- do l’utente quando lo stato di talune `ecritico e quando migliorano. E` quin- di un sistema di controllo di rete, orientato prevalentemente ai dispositivi (server, switch, router, firewall), che o tramite agenti o attraverso l’inter- rogazione (polling) SNMP consente di collezionare informazioni relative allo stato di funzionamento dei nodi di una rete, di correlarne i valori secondo uno schema di causalit`a,generare quindi degli allarmi e intraprendere azioni cor- rettive. Il sistema permette inoltre la creazione di report storici finalizzati alla determinazione dei livelli di servizio effettivamente offerti dalla rete. Non esiste in Nagios il concetto di processo, inteso come insieme di oggetti di rete (nodi e/o servizi), collegati secondo un preciso schema, dal corretto funzionamento dei quali dipende l’espletamento di una determinata funzione globale. Per esemplificare, un processo, secondo questa accezione, potrebbe es- sere la ”posta elettronica” costituita da un flusso TCP che deve attraversare un firewall, un MX record in un DNS che deve essere precisato e deve rispondere, un software antispam, un servizio SMTP, ecc . . . Il processo `edunque un insieme eterogeneo di servizi, nodi di rete e funzioni, associabili in forma libera, sul quale interessa poter definire un insieme di controlli, coordinati, dall’esito dei quali dipende lo stato di salute finale del
15 4.2. REQUISITI DI SISTEMA CAPITOLO 4. ANALISI DEI REQUISITI
processo globale ed in ultima analisi, l’effettivo espletamento della funzione globale richiesta. Qualora lo stato fosse critico il sistema deve inviare, a chi di competenza, una notifica nella quale viene spiegato il problema e da cosa deriva, per permetterne l’analisi e la correzione dello stesso. Come requisito desiderabile `erichiesto lo sviluppo di un’interfaccia grafica pi`uintuitiva che permetta la visualizzazione globale e di dettaglio dello stato del processo. Inoltre questa struttura dovrebbe offrire la possibilit`aall’utente di creare, mediante un wizard, un nuovo processo. Questa modalit`adi creazione deve risultare pi`usemplice rispetto alla precedente operazione di inserimento manuale del codice.
4.2 Requisiti di sistema
L’unico requisito che necessita il prodotto `e,ovviamente, che sia installato e configurato correttamente Nagios secondo le istruzioni del manuale d’instal- lazione reperibile al sito http://nagios.sourceforge.net/docs/3_0/quickstart.html nel quale si trovano i link per l’installazione sulle diverse distribuzioni Linux: Fedora, openSUSE, Ubuntu. Nagios Core necessita solamente di una macchina con Linux (o UNIX) che abbia accesso alla rete e un compilatore C installato (per l’installazione da codice sorgente). Si `edeciso di utilizzare il CGI incluso con Nagios Core per il quale `e necessario avere installato il software seguente • Un server web (preferibilmente Apache)
• Libreria Thomas Boutell, versione 1.6.3 o superiore GD (richiesto dal sta- tusmap e tendenze CGI) Per lo sviluppo dei requisiti desiderabili `enecessaria l’installazione del plugin NagVis il quale richiede la configurazione di una backend per consentire la comunicazione con Nagios e diversi pacchetti php, quali: • php5-gd
• php5-gettext
• php5-mbstring
• php5-session
• php5-json
16 CAPITOLO 4. ANALISI DEI REQUISITI 4.3. MODALITA` D’USO
• php5-pdo e pdo-sqlite Da NagVis 1.5 `estata utilizzata come backend di default MKLivestatus dal momento che `emolto pi`uveloce, leggera e stabile di NDO (utilizzata nelle versioni precedenti). E` quindi necessario installare MKLivestatus 1.1.0 e configurarlo sul Nagios gi`a presente dopo di che si pu`oprocedere con l’installazione del software NagVis.
4.3 Modalit`ad’uso
Pensato per rendere pi`uveloce ed efficiente il monitoraggio di processi deve permettere una rapida interazione e una rappresentazione grafica essenziale comunque allineata allo stile delle pagine che gi`acompongono il sistema Nagios. Il prodotto risulta utilizzabile con tutte le sue funzionalit`aprevio inserimento dei file che compongono il plugin. E` inoltre necessario che l’utente definisca dei processi, dato che intende mon- itorarli. Questo semplicemente creando un file processes.cfg nel quale pu`oin- serire il numero di processi necessari secondo la notazione indicata nel paragrafo seguente. Per quanto riguarda il monitoraggio attraverso l’addon NagVis in- nanzitutto `enecessario aver installato e configurato correttamente tale software e ci`oche esso richiede. Per una descrizione pi`uapprofondita della configurazione dei diversi plugin sviluppati, si rimanda al capitolo 7 nel quale `espiegata in dettaglio tutta la procedura necessaria per far si che i moduli vengano inseriti e configurati affinch`efunzionino correttamente.
4.4 Inserimento processo
Per la definizione dei processi l’utente deve creare il file processes.cfg nel- l’apposita cartella dove sono definiti gli altri file di configurazione: $ cat > /usr/local/nagios/etc/objects/processes.cfg Questo file non va riferito dal ”Main Configuration File” nagios.cfg altrimenti Nagios darebbe un segnale di errore. I processi che vengono inseriti devono avere la seguente struttura: define process { process_name nomeProcesso host_name nomeHost1,nomeHostN hostgroup_name nomeHostgroup1,nomeHostgroupM
17 4.4. INSERIMENTO PROCESSO CAPITOLO 4. ANALISI DEI REQUISITI service_members nomeHost1,servizioX,nomeHost2, servizioY servicegroup_name nomeServicegroup1,nomeServicegroupZ contact_members nomeContatto1,nomeContattoT contactgroup_members nomeContactgroup1,nomeContactgroupU } Per vedere il nuovo processo definito `esufficiente aggiornare la pagina di visu- alizzazione generale dei processi o attendere che venga aggiornata automatica- mente. Quando l’utente crea il processo deve necessariamente inserire tutti i parametri sopra elencati, se per un campo non sono previsti dati basta lasciare in bianco la riga andando a capo come mostrato nell’esempio seguente. define process { process_name prova host_name localhost hostgroup_name service_members localhost,HTTP servicegroup_name contact_members nomeContatto1 contactgroup_members } Altra cosa molto importante da precisare `eche in tutti i processi deve essere sempre dichiarato almeno un contatto o un contactgroup, questo per poter inviare le notifiche a chi di competenza quando lo stato del processo `ecritico. Con lo sviluppo della funzionalit`adi creazione del processo tramite interfac- cia grafica questi passaggi non sono necessari in quanto viene fatto tutto auto- maticamente dalla procedura. Per utilizzare questo strumento per la creazione del processo `esufficiente cliccare dal men`uNagios, posizionato sulla sinistra dello schermo, il link ”NagVis processes”. A questo punto nella parte di navigazione della pagina si pu`oselezionare dal men`uNagVis situato in alto a sinistra: Open → Create new process La procedura aiuta l’utente nell’inserimento dei dati corretti. E` molto importante prestare attenzione all’ordine in cui vengono inseriti i servizi o gli host; devono comparire secondo una certa logica dettata dalla funzione che essi svolgono. Questo poich´el’ordine con cui vengono controllati i servizi/host `equello di definizione all’interno del processo, per evitare controlli inutili `ebene sapere a priori le dipendenze tra ciascun oggetto. Ad esempio `e inutile controllare per primo lo stato del firewall se prima non ho controllato che la linea fosse attiva.
18 CAPITOLO 4. ANALISI DEI REQUISITI 4.5. FUNZIONI DEL PRODOTTO
4.5 Funzioni del prodotto
Il prodotto consiste nello sviluppo di un modulo di controllo Nagios per il monitoraggio di processi (insiemi di dispositivi di rete e servizi). L’utente, tramite un’opportuna interfaccia grafica, pu`omonitorare lo stato complessivo di tutti i processi definiti. L’aspetto grafico della pagina di monitoraggio `eanalogo a quello delle al- tre pagine gi`apresenti in Nagios. Inoltre tramite lo specifico link `epossibile passare a una visualizzazione pi`udettagliata del processo desiderato. L’inter- faccia grafica che viene utilizzata in Nagios ha una struttura tabellare, con- tiene informazioni di tipo generale nella parte superiore della pagina seguite dall’intestazione relativa ai contenuti specifici. Ciascuna tabella rappresenta un oggetto definito e contiene le informazioni principali che lo riguardano. E` sempre possibile avere maggiori informazioni per ciascun oggetto, sia esso un servizio, un nodo di rete o altro. La visualizzazione del processo `ediretta conseguenza della definizione da parte dell’utente di uno o pi`uprocessi che intende monitorare. Una volta che questi appartengono al sistema vengono periodicamente controllati per saperne lo stato. La funzione che effettua il controllo sullo stato degli oggetti all’interno del processo `estrutturata in modo tale da effettuare le verifiche sul funzionamento di servizi/host in modo sequenziale, o meglio secondo l’ordine in cui sono stati definiti. Non appena lo stato del processo risulta critico non vengono effettuati altri controlli e viene inviata una notifica. In questo modo si impone una sorta di gerarchia tra le funzioni che offrono i diversi oggetti. La notifica viene inviata automaticamente a tutti i contatti, o gruppi di contatti, che appartengono al processo, con la descrizione del problema trovato. Lo sviluppo della parte inerente la creazione guidata del processo ha la funzione di aiutare l’utente nella definizione di taluno e facilitare l’operazione di correzione di eventuali errori. Offre inoltre un’altra possibilit`adi visual- izzazione dei processi secondo la struttura di NagVis, a livello globale e di dettaglio, pi`usemplice da comprendere rispetto a quella standard di Nagios.
4.6 Requisiti degli utenti
Il prodotto non richiede particolari requisiti per il suo utilizzo in quanto rapp- resenta i dati d’interesse in modo analogo al sistema nel quale viene inserito. L’utente che utilizza il modulo aggiuntivo `euna persona che gi`ausa Nagios e che ne conosce il funzionamento. Essendo il plugin strutturato allo stesso
19 4.7. USE CASE CAPITOLO 4. ANALISI DEI REQUISITI
modo della struttura che lo accoglie, l’utente non necessita di altre conoscenze, tecniche o meno, per il suo utilizzo. L’addon NagVis aggiuntiva non `eattualmente conosciuta all’interno del contesto in cui il progetto va inserito, tuttavia `esufficiente seguire la guida d’installazione disponibile anche in appendice al presente documento. Per il suo utilizzo, relativamente al progetto, non richiede una conoscenza approfondita del software in quanto `esemplice ed intuitivo.
4.7 Use case
4.7.1 Use case Monitora Processi
Figura 4.1: Use case monitora processi
Use Case: Monitora processi Nagios
Attori Coinvolti: User.
20 CAPITOLO 4. ANALISI DEI REQUISITI 4.7. USE CASE
Pre-condizioni: Il computer sul quale viene utilizzato il modulo deve rispettare i requisiti di sistema descritti nel paragrafo 4.2 anche senza NagVis.
Descrizione Sintetica: L’utente ha la possibilit`adi visualizzare i proces- si, da lui definiti, tramite il link inserito nel men`uNagios situato nella parte sinistra dello schermo “Nagios processes”. Inizialmente `eraffigurata a livello globale una tabella per monitorare l’insieme di tutti i processi. Attraverso il percorso indicato dal link presente in ogni riga `epossibile passare alla visual- izzazione specifica di ciascun processo con informazioni, pi`uapprofondite, che lo riguardano. Allo stesso modo `epossibile passare dalla vista di dettaglio delle componenti del processo alla pagina con le informazioni specifiche di ogni oggetto. Se il sis- tema rileva uno stato di criticit`ainvia automaticamente una notifica all’utente preposto. L’utente pu`oinoltre in ogni momento utilizzare il sistema Nagios come di consueto.
Post-condizioni: l’Utente in qualsiasi momento pu`omonitorare lo stato dei processi da lui definiti.
21 4.7. USE CASE CAPITOLO 4. ANALISI DEI REQUISITI
4.7.2 Use case Crea Processi
Figura 4.2: Use case crea processi
Use Case: Crea e monitora processi NagVis
Attori Coinvolti: User
Pre-condizioni: Il computer sul quale viene utilizzato il modulo deve rispettare tutti i requisiti di sistema descritti nel paragrafo 4.2.
Descrizione Sintetica: L’utente ha la possibilit`adi visualizzare i processi, da lui definiti, tramite il link inserito nel men`uNagios situato nella parte sinistra dello schermo ”NagVis processes”. Inizialmente `eraffigurata a livello globale una tabella per monitorare lo stato d’insieme di tutti i processi. Mediante un click nel riquadro del processo d’interesse l’utente passa alla visualizzazione in dettaglio del processo e dello stato degli elementi che lo compongono. Tale vista `edifferente da quella offerta da Nagios, ha una struttura pi`uschematica ed intuitiva.
22 CAPITOLO 4. ANALISI DEI REQUISITI 4.8. REQUISITI
Dalla visualizzazione NagVis pu`oinoltre avviare la procedura di creazione di un nuovo processo. E` guidato nell’inserimento dei parametri mediante men`ua discesa contenenti gli oggetti gi`adefiniti in Nagios. Se l’utente commette degli errori questi gli vengono segnalati dall’interfaccia grafica e gli impediscono di avanzare con la procedura di creazione, lasciando naturalmente la possibilit`a di tornare indietro e correggere il dato errato.
Post-condizioni: l’Utente in qualsiasi momento pu`omonitorare lo stato dei processi da lui definiti e inoltre ne pu`ofacilmente creare di nuovi in base alla sua configurazione Nagios.
4.8 Requisiti
Nella tabella seguente vengono riportati i requisiti rilevati durante la fase di analisi. E` stata fatta una prima classificazione suddividendoli in:
• Obbligatori: requisiti esplicitamente richiesti dal capitolato che verranno ob- bligatoriamente realizzati, irrinunciabili per il cliente, senza i quali l’attivit`a di stage perderebbe significato
• Desiderabili: requisiti ritenuti importanti, non strettamente necessari al cliente ma con valore aggiunto importante. Anche se non necessariamente esplicitati nel capitolato verranno realizzati se per il loro soddisfacimento si rientra ugualmente entro i tempi preventivati per lo sviluppo dell’intero progetto.
• Opzionali : requisiti aggiuntivi di cui non si garantisce la realizzazione, non costituiscono alcun tipo di vincolo contrattuale
Successivamente `estata fatta un’ulteriore distinzione tra requisiti:
• Funzionali
• Non funzionali
• Di qualit`a
• Di usabilit`a
• D’ambiente
23 4.8. REQUISITI CAPITOLO 4. ANALISI DEI REQUISITI
Una classificazione aggiuntiva `etra requisiti espliciti ed impliciti a seconda che siano richiesti o meno dal committente, ma non si `eritenuta necessaria l’incorporazione anche di questa differenziazione.
Tipo di requisito Requisito Funzionale obbligatorio Comprensione, attraverso l’esame dei sorgenti del- la applicazione e della documentazione generale di prodotto, della struttura e delle modalit`adi funzionamento di Nagios Funzionale obbligatorio La struttura dei file cerati deve essere conforme alle specifiche Nagios Funzionale obbligatorio Deve essere presente in Nagios una visualizzazione globale dei processi definiti Funzionale obbligatorio Deve essere presente in Nagios una visualizzazione di dettaglio per tutti i processi definiti Funzionale obbligatorio Definizione di ”gestione di processo” in ambito Nagios Funzionale obbligatorio Individuazione delle strutture e dei metodi pi`u adeguati per implementare la gestione del processo precedentemente definita Funzionale obbligatorio Gestione del processo come sequenza ordinata di tutti e soli i controlli necessari per stabilirne lo stato globale Funzionale obbligatorio Modellizzazione dell’interfaccia utente Funzionale obbligatorio Invio di notifiche quando lo stato del processo `e critico Funzionale obbligatorio Produzione del codice, sotto forma di plugin di Nagios, necessario per la gestione del processo Funzionale obbligatorio Verifica del funzionamento del codice prodotto Funzionale desiderabile Sviluppo di una interfaccia grafica di configu- razione della gestione del processo Funzionale desiderabile L’interfaccia grafica deve permettere di creare un nuovo processo Funzionale desiderabile L’interfaccia per l’inserimento del processo pu`o utilizzare plugin specifici per Nagios Funzionale desiderabile La comunicazione tra Nagios e il plugin deve avvenire tramite backend
24 CAPITOLO 4. ANALISI DEI REQUISITI 4.8. REQUISITI
Funzionale desiderabile L’interfaccia per l’inserimento del processo perme- tte di: • Scegliere il nome del processo
• Scegliere il numero e conseguentemente il nome dei servizi (e degli host corrispondenti) che compongono il nuovo processo
• Scegliere il numero e il nome dei ”gruppi di servizi” che compongono il nuovo processo
• Scegliere il numero e il nome degli host che compongono il nuovo processo
• Scegliere il numero e il nome dei ”gruppi di host” che compongono il nuovo processo
• Scegliere il numero e il nome dei contatti che compongono il nuovo processo
• Scegliere il numero e il nome dei ”gruppi di contatti” che compongono il nuovo processo
Funzionale desiderabile La selezione degli attributi del processo da creare avviene tra l’insieme di oggetti gi`a definiti in Nagios Funzionale desiderabile In caso di inserimento di dati errati si interrompe il procedimento per la creazione del processo e viene segnalato l’errore all’utente affinch´epossa correggerlo Funzionale desiderabile L’interfaccia grafica del plugin deve permettere sia la visualizzazione globale dello stato dei processi che quella di dettaglio Funzionale opzionale Inserire dei limiti di ”Warning” e ”Critical” per lo stato del processo oltre a quelli di defautl entrambi impostati ad 1 Funzionale opzionale Utilizzo di MySQL come DB di appoggio per la gestione dei dati coinvolti Non funzionale obbligatorio Documentazione precisa del codice
25 4.8. REQUISITI CAPITOLO 4. ANALISI DEI REQUISITI
Usabilit`aobbligatorio L’interfaccia deve essere in lingua inglese per essere allineata con il resto del sistema Ambiente obbligatorio Il modulo viene sviluppato e testato su piattaforma openSUSE 11.3 Ambiente desiderabile L’interfaccia grafica alternativa a quella Nagios `e sviluppata con l’utilizzo del plugin NagVis 1.5.4 Ambiente desiderabile La comunicazione tra Nagios e il plugin NagVis avviene tramite backend MKLivestatus Tabella 4.1: Elenco dei requisiti
26 Capitolo 5
Progettazione
Il presente paragrafo ha lo scopo di presentare le scelte progettuali operate e le varie componenti necessarie a soddisfare i requisiti individuati nella fase di analisi. Per avere una prima visione a livello generico dell’infrastruttura sulla quale si va ad operare si faccia riferimento all’immagine seguente.
Figura 5.1: Comunicazione Nagios - NagVis
Il sistema Nagios funziona correttamente anche senza l’installazione della backend o del software NagVis. Si `escelto di implementare questa struttura di comunicazione perch´epermette uno scambio di dati ed informazioni tra i due software in tempi molto brevi. NagVis ha il vantaggio di essere sviluppato come plugin di Nagios, quindi la sua interfaccia `egi`apensata per facilitare l’interazione con l’utente, il quale pu`ofacilmente cambiare vista tramite i link presenti sugli oggetti delle mappe. In fase di progettazione sono stati suddivisi i due ambiti nei quali inserire i moduli per i processi, atti al monitoraggio da un lato e per la creazione dall’altro. Questo per garantire come prima cosa il soddisfacimento dei requisiti obbligatori.
27 5.1. ARCHITETTURA CAPITOLO 5. PROGETTAZIONE
5.1 Architettura
La struttura dell’architettura all’interno di Nagios `efacilmente personalizz- abile, nel caso di studio si `epensato di utilizzare una suddivisione dei file di con- figurazione come rappresentato nella figura seguente. Il file di configurazione
Figura 5.2: Struttura configurazione Nagios
Nagios ha al suo interno dei riferimenti ad altri file, per sapere dove prendere le informazioni che si devono rappresentare. Nel caso di studio sono stati uti- lizzati i principali oggetti che possono essere definiti in Nagios suddividendoli per categoria in file differenti. Come si pu`onotare non `epresente il file processes.cfg che interessa mag- giormente il plugin, questo perch´e`epresente all’interno della cartella con tutti i file di configurazione, ma non `eriferito da nagios.cfg. Se il riferimento fosse definito Nagios darebbe errore e non sarebbe possibile utilizzare il software.
28 CAPITOLO 5. PROGETTAZIONE 5.1. ARCHITETTURA
5.1.1 Architettura Nagios L’architettura di Nagios `estrutturata nel seguente modo:
• Si tratta di un demone che gestisce tutte le operazioni
• Negli Object Definition Files si specificano hosts, services, hostgroups, con- tacts, contactgroups, commands, etc...
• Nei Resource Files le configurazioni sensibili (tipo password) per non ren- derle disponibili sui cgi
• CGI Config Files: configurazioni dei CGI (responsabili dell’interfaccia web)
Figura 5.3: Struttura Nagios
Su questa base l’elaborazione del modulo Nagios si `esviluppata seguendo lo schema logico utilizzato dal software. Come corpo centrale del plugin si indi- vidua l’interfaccia grafica gestita da CGI per l’interpretazione dei parametri, passati tramite il link, la quale utilizza chiamate a comandi di check per ot- tenere lo stato degli oggetti da rappresentare. Nel caso di sviluppo ci sono solamente due possibilit`adi passaggio di parametri, o si richiede una visione globale e quindi non ne vengono passati, oppure si desidera visualizzare i dati
29 5.1. ARCHITETTURA CAPITOLO 5. PROGETTAZIONE
relativi ad un unico processo e di conseguenza si avr`acome parametro il nome di quest’ultimo. Il CGI per l’interfaccia grafica necessita dei dati relativi alle componenti da monitorare e di parametri per poter rappresentare lo stato corretto dei giusti oggetti. Per reperire le informazioni viene fatto accesso ai file di configurazione relativi alle componenti da monitorare.
Figura 5.4: Esecuzione CGI Nagios
Come si vede dall’immagine precedente l’utente interagisce con l’interfaccia web, creata dal file CGI a seconda delle sue richieste. I controlli relativi allo sta- to dei processi sono affidati esclusivamente al comando check process definito in uno script perl ed eseguito periodicamente in parallelo all’aggiornamento del- l’interfaccia. Se il controllo rileva dei problemi viene inviata una notifica agli utenti preposti, semplicemente eseguendo il comando send notification presente nella cartella /usr/local/nagios/libexec/, avente parametro contenente le problematiche emerse. Tutti i dati relativi allo stato degli oggetti monitorati vengono letti dal file di status di Nagios, i parametri inerenti gli oggetti definiti all’interno del processo invece vengono letti dai diversi file di configurazione nei quali sono descritti.
30 CAPITOLO 5. PROGETTAZIONE 5.1. ARCHITETTURA
5.1.2 Architettura NagVis La visualizzazione in questo software avviene tramite pagine php e con l’utilizzo di JavaScript. Nagvis permette di memorizzare e visualizzare i dati raccolti da Nagios nel modo che lo sviluppatore ritiene pi`uopportuno. I parametri ricevuti si ottengono attraverso beckend, nel caso di studio, live quindi disponibili in tempi brevi. MKLivestatus fornisce quindi un collegamento tra le due strutture di monitoraggio, questo canale di comunicazione che viene creato permette a NagVis di ottenere in tempi brevi i parametri che necessita per sapere lo stato delle componenti di ogni specifico processo. Il modulo sviluppato per NagVis prevede l’inserimento di due file php nec- essari semplicemente per la creazione di un nuovo processo. La procedura di creazione si sarebbe potuta svolgere in modo indipendente dalla struttura Nagios, ma in tal caso le architetture Nagios e NagVis sarebbero state indipen- denti per quanto riguarda il monitoraggio dei processi. Ci`oavrebbe dato luogo a delle incongruenze tra i due software, i processi definiti in ciascuno sareb- bero stati visibili solo localmente. Per avere la medesima configurazione di controllo in entrambi i sistemi si sarebbero dovuti definire i processi due volte, la prima per Nagios e la seconda per NagVis. Per ovviare a questa procedura decisamente inefficiente si `edeciso di salvare, al momento della creazione, nel file di configurazione dei processi in Nagios i parametri scelti dall’utente nel procedimento di definizione NagVis. Come si pu`ovedere dal diagramma di attivit`ain figura 5.5 definendo il processo attraverso la procedura sviluppata in NagVis si mantiene aggiornata la situazione dei processi creati anche nella visualizzazione Nagios.
31 5.1. ARCHITETTURA CAPITOLO 5. PROGETTAZIONE
Figura 5.5: Diagramma delle attivit`aper la creazione di processi in NagVis
32 CAPITOLO 5. PROGETTAZIONE 5.2. DEFINIZIONE COMPONENTI
5.2 Definizione componenti
Innanzitutto sono stati inseriti due link nel file side.php che definisce la parte di navigazione Nagios. Il primo per la visualizzazione dei processi in NagVis ed il secondo per il monitoraggio in Nagios.
5.2.1 Modulo in Nagios Dopo l’installazione di Nagios e dei moduli da sviluppare, la situazione all’in- terno della gerarchia delle cartelle, per quanto riguarda le comunicazioni tra i file definiti, sar`ala seguente.
Figura 5.6: Struttura dei file Nagios utilizzati
Le comunicazioni tra i diversi file avvengono in due modalit`adistinte: lettura o chiamata per l’esecuzione di script perl. Le interazioni possibili che si possono distinguere sono sei:
1. Dal men`udi Nagios, rappresentato dal file side.php, mediante il link ”Nagios processes” si passa alla visualizzazione di tutti i processi definiti la quale viene creata dal file process.cgi
2. process.cgi permette due visualizzazioni distinte, una per lo stato globale dei processi ed una per quello di dettaglio del singolo processo. La prima esegue periodicamente il comando check process il quale ritorna al CGI lo stato globale del processo che riceve come parametro.
33 5.2. DEFINIZIONE COMPONENTI CAPITOLO 5. PROGETTAZIONE
3. check process `euno script perl incaricato di verificare lo stato di un pro- cesso, questo mediante la lettura dei file di configurazione, per verificare che oggetti deve controllare, e di status.dat per sapere lo stato di ciascuno. 4. Quando nella fase di controllo degli stati si rileva uno stato di criticit`adel processo viene inviata una email ai contatti di competenza. Questo viene fatto tramite l’esecuzione dello script send notification al quale vengono passati tutti i dati relativi agli oggetti in stato critico.
5. send notification per ottenere gli indirizzi email dei contatti a cui deve inviare la notifica legge il file di configurazione relativo ai contatti.
6. Come detto nel punto 2 process.cgi permette anche la visualizzazione di dettaglio di un singolo processo. Per verificare lo stato di tutti gli oggetti da monitorare il CGI va a leggere i file di configurazione ed il file status.dat. Le componenti principali che sono state create sono quindi tre:
• Lo script per il comando check process
• Lo script send notification
• Il file CGI process.cgi per l’interfaccia grafica Il file check process `euno script perl situato nella cartella /usr/local/nagios/libexec/ la quale contiene tutti gli script dei vari coman- di che rappresentano i plugin Nagios eseguibili per il relativo servizio. Questo script ha lo scopo di determinare lo stato del processo che gli viene passato come parametro. Viene ora descritta la struttura del codice definito: • Innanzitutto vengono definite le librerie che lo script utilizza, i prototipi delle funzioni, le variabili d’ambiente e le variabili globali.
• Le funzioni definite sono: sub print_help (); sub print_usage (); sub state ($$$); sub trim($);
Rispettivamente per la stampa di un aiuto per l’utilizzo del comando, l’uti- lizzo del comando, il calcolo dello stato del processo e l’eliminazione di spazi bianchi all’inizio ed alla fine di una stringa.
34 CAPITOLO 5. PROGETTAZIONE 5.2. DEFINIZIONE COMPONENTI
• Dopo la definizione delle varie subroutine `epresente il codice del main dello script. Questa porzione di codice cattura i parametri in ingresso quando viene lanciato il comando, li interpreta e ne controlla la correttezza.
La struttura della funzione state `ecomprensibilmente pi`ucomplessa delle altre. Riceve tre parametri, rispettivamente ”nome del processo”, ”limite di warning”, ”limite di critical”. All’interno della funzione vengono prelevati con un parser:
• I valori degli stati di tutti gli host e tutti i servizi dal file status.dat
• I componenti degli hostgroups e servicegroups dai rispettivi file localhost.cfg e services.cfg
• I dati relativi al processo specificato, da processes.cfg
Salvati i dati nelle opportune variabili vengono fatti i controlli per definire lo stato del processo. Per prima cosa esegue i controlli su services e servicegroups e salva lo stato globale di questi in una variabile. Poi analogamente su hosts e hostgroups. E` stato implementato anche un requisito opzionale riguardante le soglie oltre le quali un processo `econsiderato in stato Warning o Critical. Di default sono entrambe impostate ad 1, cio`enon appena viene trovato un servizio, un host o un altro oggetto che `ein stato di allerta la condizione globale del processo ne risente. L’utente pu`ocambiare il valore di queste variabili a suo piacimento, per fare un esempio si supponga che il limite di warning sia 2 e quello di Critical sia 3:
• Saranno necessari due servizi (o host) in stato di Warning perch´elo sia anche la condizione del processo
• Per ottenere una situazione di processo Critical saranno necessari tre servizi (o host) in tale stato
Con l’utilizzo di questi parametri l’utente pu`oquindi rendere pi`urestrittivo o permissivo il monitoraggio del processo. Per modificare tali limiti `eper`onec- essario passarli come parametri al comando check process, si devono quindi sostituire gli interi di ’-w’ e ’-c’ con le soglie desiderate. La chiamata al comando `ela seguente $result=system(’’$nagios/libexec/check process -P $key -w 1 -c 1’’); ed `esituata in /usr/local/nagios/sbin/process.cgi.
35 5.2. DEFINIZIONE COMPONENTI CAPITOLO 5. PROGETTAZIONE
Per stabilire lo stato globale del processo viene fatto il confronto delle due variabili nelle quali `esalvata rispettivamente, la condizione di tutti i servizi (e servicegroup) e quella di tutti gli host (e hostgroup). Va messo in evidenza il fatto che quando il numero di servizi in stato ”- Critical” `epari al limite imposto non vengono fatti ulteriori controlli perch´esi `egi`ain grado di determinare lo stato globale del processo. Inoltre l’utente ha inserito all’interno del processo i vari oggetti secondo uno specifico ordine di priorit`a,andare a controllare lo stato di un oggetto sapendo che il precedente `egi`acritico non avrebbe senso. Per determinare lo stato globale del processo per`onon si considera il limite di criticit`ain modo congiunto tra host e servizi, bens`ısi utilizza una variabile per gli uni ed una per gli altri. Non appena uno di questi due gruppi di oggetti raggiunge il livello di allerta si pu`odeterminare lo stato del processo. Di seguito viene riportata la porzione di codice che effettua il controllo degli stati dei servizi: @a=split(’,’,@pro[2]); for($b=0;$b<(@a)/2;$b++){ for($stat=0;$stat<@serviceState && $numeroCritical<$in_crit && $fo;$stat++){ if(trim(@a[$b*2+1]) eq trim(@serviceName[$stat]) && trim( @a[$b*2]) eq trim(@serviceHName[$stat])){ if(@serviceState[$stat]==1){ $numeroWarning++; if($numeroWarning>=$in_warn && @serviceState[$stat]>$ processState){ $processState=@serviceState[$stat]; } } else { if(@serviceState[$stat]==2 || @serviceState[$stat]==3){ $numeroCritical++; $mailParam = $mailParam.trim(@serviceName[$stat]).","; if($numeroCritical>=$in_crit && @serviceState[$stat]>$ processState){ $processState=@serviceState[$stat]; } } } $fo =0; } } $fo =1;
36 CAPITOLO 5. PROGETTAZIONE 5.2. DEFINIZIONE COMPONENTI
}
Quando l’algoritmo rileva che un componente `ein stato critico aggiunge ad una variabile dedicata alla raccolta dei dati critici il nome del servizio. In modo pi`uo meno analogo vengono fatti i controlli sugli stati degli altri oggetti da monitorare. Mediante una serie di blocchi condizionali (if) viene poi stabilito lo stato globale del processo e questo sar`ail valore di uscita della funzione, se risulta essere ”Critical” viene chiamato lo script per l’invio della notifica agli utenti. Il file con il codice per l’invio di email `edefinito in /usr/local/nagios/libexec/send notification ed `eun comando per Na- gios eseguibile anche da shell. Lo script ha lo scopo di inviare una notifica, nel nostro caso una email, quando lo stato del processo `ecritico. Non effettua nessun controllo sullo stato perch´eil comando viene eseguito solamente quando si `egi`arilevata una situazione critica. Viene ora descritta la struttura del codice definito:
• Innanzitutto vengono definite le librerie che lo script utilizza, i prototipi delle funzioni, le variabili d’ambiente e le variabili globali.
• Le funzioni definite sono: sub print_help (); sub print_usage (); sub trim($); sub sendmail($);
Rispettivamente per la stampa di un aiuto per l’utilizzo del comando, l’u- tilizzo del comando, l’eliminazione di spazi bianchi all’inizio ed alla fine di una stringa e l’invio della email
• Dopo la definizione delle varie subroutine `epresente il codice del main dello script. Questa porzione di codice cattura i parametri in ingresso quando viene lanciato il comando, li interpreta e ne controlla la correttezza.
37 5.2. DEFINIZIONE COMPONENTI CAPITOLO 5. PROGETTAZIONE
La struttura della funzione sendmail `enecessario descriverla. Per prima cosa interpreta il parametro che gli viene passato con la seguente notazione nomeProcesso+nomeS1,nomeSN,+nomeH1,+contact1, contactN+contactG1 suddivide quindi tutti i dati a seconda della loro categoria, viene poi creato con essi il corpo della mail che deve essere spedita. Per il reperimento degli indirizzi a cui mandare le notifiche viene letto il file contacts.cfg nel quale sono definiti tutti i contatti. Associando il nome del contatto con il suo indirizzo vengono quindi eseguiti i comandi per l’invio della email. Passiamo ora alla descrizione del file process.cgi. Il suddetto file `eun CGI situato nella cartella /usr/local/nagios/sbin/ la quale contiene tutti i CGI definiti in Nagios per la visualizzazione grafica delle componenti da monitorare nella rete definita. process.cgi ha lo scopo di rappresentare nell’interfaccia grafica del sistema gli stati dei processi e dei relativi oggetti. Anche per questo file si `eutilizzato il linguaggio perl. Per quanto riguarda la parte HTML ha la struttura analoga a quella degli altri CGI utilizzati da Nagios. Il corpo centrale del codice `esuddiviso in due parti principali:
• Visualizzazione globale
• Visualizzazione di dettaglio
A seconda di cosa l’utente abbia richiesto viene caricata la pagina corretta. Per la parte inerente il monitoraggio dell’insieme di tutti i processi viene creata semplicemente una tabella con i rispettivi stati. Nella pagina seguente viene riportato il codice della suddetta tabella. print "
\n"; print "
| Process | "; print "Status | "; print "Last Check | "; my ($i) =0; for my $key (keys %allProcesses){ chomp ; s/\&/\&/g; s/\
|---|---|---|
| $key | \n"; # Process print "$procState | \n"; # Status print "$mdate | \n"; # Last Check $i ++; } print "
Come si comprende dal codice l’insieme dei processi `erappresentato da una tabella che ne specifica:
• Nome
• Stato
• Ultimo controllo effettuato
Lo stile di visualizzazione `eanalogo a quello delle tabelle definite da Nagios in quanto viene utilizzato lo stesso foglio di stile (status.css). La seconda parte del file, per la creazione dell’interfaccia grafica che mostra all’utente una visione pi`udettagliata del processo da lui selezionato viene creata similarmente a quella descritta sopra. Naturalmente per rappresentare i singoli processi sono necessarie informazioni diverse e saranno presenti da una, fino
39 5.2. DEFINIZIONE COMPONENTI CAPITOLO 5. PROGETTAZIONE
ad un massimo di quattro tabelle a seconda di quante tipologie di oggetti caratterizzano lo specifico processo. La prima tabella rappresenta i servizi ed `estrutturata come segue • Nome host • Nome servizio • Stato servizio • Ultimo controllo effettuato • Informazioni inerenti il servizio Qualora non ci fossero servizi da monitorare all’interno del processo ovviamente questa tabella non verrebbe creata. Le successive sono: Host • Nome host • Stato host • Ultimo controllo effettuato • Informazioni inerenti l’host Servicegroups • Nome del servicegroup • Stato complessivo • Numero e stato di tutti i suoi servizi Hostgroups • Nome dell’hostgroup • Stato complessivo • Numero e stato di tutti i suoi host Analogamente ai servizi anche queste tabelle vengono create solo se le loro componenti appartengono al processo. Come gli altri file anche process.cgi ha la definizione della funzione trim per la rimozione di spazi bianchi all’inizio e alla fine di una stringa che gli viene passata come parametro. Per ciascun componente sia esso service, host o altro `esempre disponibile un link all’apposito CGI Nagios, per la visione di tutte le sue caratteristiche.
40 CAPITOLO 5. PROGETTAZIONE 5.2. DEFINIZIONE COMPONENTI
5.2.2 Modulo in NagVis Per quanto riguarda la struttura della gerarchia delle cartelle in NagVis si ha la seguente situazione.
Figura 5.7: Struttura dei file NagVis utilizzati
In questo caso le modalit`adi comunicazione tra i file avvengono tramite: lettura o link. Le interazioni possibili che si possono distinguere sono sei: 1. Quando si vuole creare un nuovo processo tramite il link ”Create new process” nel men`uNagVis viene caricata la pagina createMap.php per l’inserimento dei parametri.
2. In createMap.php vengono inseriti i primi parametri, dopo di che vengono fatti dei controlli su di essi tramite un form che invia i dati alla pagina corrente, e se corretti si pu`oprocedere con la selezione degli oggetti da monitorare nel processo. 3. Una volta inseriti tutti i dati, tramite l’apposito pulsante si accede alla pagina createView.php. 4. Quest’ultima effettua dei controlli per verificare la correttezza dei dati, qualora fossero errati permette solamente di tornare alla pagina precedente per correggerli.
41 5.2. DEFINIZIONE COMPONENTI CAPITOLO 5. PROGETTAZIONE
5. Se tutti i controlli vanno a buon fine si presenta un riepilogo dei dati inseriti e tramite un link a index.php si pu`opassare alla visualizzazione del processo appena creato.
6. La rappresentazione grafica, quindi l’interpretazione, dei dati presenti nei file di configurazione delle mappe `efatta da NagVis, a seconda dei parametri passati alla pagina index.php.
Viene ora descritta la struttura dei file che permettono la creazione di nuovi processi mediante interfaccia grafica, la visualizzazione degli oggetti del pro- cesso `euna diretta conseguenza dei parametri che seleziona l’utente. In NagVis le componenti che sono state definite sono due semplici file php:
• createMap.php
• createView.php
Entrambi creati nella cartella /usr/local/nagvis/share/frontend/nagvis-js/. La pagina createMap.php `esuddivisa in due parti. La prima prevede l’inseri- mento, in apposite caselle di testo, del numero di oggetti che si vogliono inserire all’interno del processo. La seconda `einvece dedicata alla selezione dei nomi di ciascun servizio/host o altro. Il file `estrutturato nel seguente modo. Fase 1:
• Un primo form per l’inserimento del numero di oggetti da creare
• Vengono presi dalla variabile d’ambiente i numeri inseriti dall’utente
• Se almeno uno tra i primi quattro parametri `ediverso da 0 (zero) viene fatto un controllo sui dati relativi a contact e contactgroups:
– Se almeno uno `ediverso da 0 (zero) si passa alla fase successiva (Fase 2) – Altrimenti viene segnalato un errore
• Analogamente se i primi quattro parametri sono tutti impostati a zero e almeno uno degli ultimi due ha un valore diverso viene segnalato un errore.
Fase 2:
42 CAPITOLO 5. PROGETTAZIONE 5.2. DEFINIZIONE COMPONENTI
• Vengono letti i file Nagios di configurazione, contenenti servizi, host, ser- vicegroup e hostgroup. Per avere a disposizione il nome di ciascun oggetto definito • Viene richiesto di inserire il nome del processo (il quale deve essere univoco) • Si passa alla creazione della tabella che contiene le ComboBox con i parametri da selezionare Sono visibili solamente le etichette ed i men`ua discesa delle tipologie di oggetto che si vogliono aggiungere al processo. Per la scelta del nome del servizio si `eritenuto necessario richiedere anche l’host al quale esso `eassociato per il semplice motivo che lo stesso servizio (con anche nome identico) pu`oessere definito in diversi host. Infine vengono spediti alla pagina successiva tramite campo nascosto i parametri che indicano il numero di oggetti definiti per ciascun tipo. Viene riportata la porzione di codice per l’acquisizione e successiva visual- izzazione dei nomi dei servicegroup che sono definiti all’interno dell’apposito file Nagios. // Get servicegroups defined $fileservicesname="../../../../nagios/etc/objects/services. cfg "; $fileservices = fopen($fileservicesname, ’r’) or exit("Unable to open file services.cfg!"); $ lineserv ; $nagiosServG=array(); $ nsg =0; while (1) { $lineserv=fgets($fileservices); if($lineserv = = null) break; if(!strncmp(" servicegroup_name",$lineserv,18)){ $names=explode(" ",$lineserv); $nagiosServG[$nsg]=$names[2]; $ nsg ++; } } fclose($fileservices); // Servicegroups combobox definition if($servicegroups!=0){ echo "
Per tutti i form `esempre stato utilizzato come passaggio dei parametri il meto- do post. I dati compilati vengono reindirizzati al file createView.php il quale ha il compito di controllarne la correttezza, se rileva degli errori permette solo di tornare alla pagina precedente, altrimenti procede con la generazione del processo. In questa fase i possibili errori che pu`ocommettere l’utente che comportano il blocco del procedimento di creazione sono solamente due:
• Inserimento di un nome gi`aesistente per il processo
• Associazione ”servizio-host” non corretta
In questi casi viene visualizzato un messaggio che specifica l’errore rilevato ed un pulsante per tornare alla pagina precedente.
";Se tutti i parametri sono corretti allora procede con la creazione del processo. Questa fase `ecomposta da pi`uparti, una per creare la mappa NagVis relativa al processo e l’altra per definirlo all’interno del file process.cfg di Nagios. Nel contempo i dati vengono anche stampati a video con la funzione di fornire all’utente una sorta di riassunto delle componenti del processo che ha appena creato. Il flusso di operazioni compiute dal codice `eil seuente:
• Definizione della mappa NagVis, che corrisponde al nostro processo
• Elenco nella pagina php dei contatti e contactgroups che appartengono al processo
• Elenco nella pagina php dei servizi che compongono il processo
44 CAPITOLO 5. PROGETTAZIONE 5.2. DEFINIZIONE COMPONENTI
• Elenco nella pagina php dei servicegroup che compongono il processo e disegno degli stessi all’interno della mappa
• Elenco nella pagina php degli hostgroup che compongono il processo e disegno degli stessi all’interno della mappa
• Elenco nella pagina php degli host che compongono il processo e disegno degli stessi all’interno della mappa con i rispettivi servizi da monitorare
• Aggiornamento, mediante l’aggiunta del nuovo processo, del file processes.cfg di Nagios
• Disegno di host e servizi associati per quegli host che non sono da monitorare in quanto non presenti come oggetti del processo
• Definizione e disegno dello stato globale del processo
• Inserimento della legenda nella mappa
Queste operazioni utilizzano un insieme di funzioni che sono state definite per la creazione di elementi all’interno della mappa NagVis. function textboxFu($testo, $x, $y, $w, $color); function serviceFu($nomeServizio, $x, $y, $nomeHost); function servicegroupFu($nomeServicegroup, $x, $y); function hostFu($nomeHost, $x, $y); function hostgroupFu($nomeHostgroup, $x, $y); function lineFu($tipo, $x, $y);
Ciascuna ritorna una stringa con la definizione, secondo la sintassi NagVis, della specifica componente con i parametri ricevuti, la quale andr`ainserita all’interno del file di configurazione della mappa. Vediamo ora un utilizzo di alcune di queste funzioni per la creazione degli host collegati tramite delle frecce ai rispettivi servizi da monitorare. if($hosts!=0){ echo "Hosts:
- "; for($k=0;$k<$hosts;$k++){ $name="hosts".$k; $newHosts[$k]=$_POST[$name]; echo "
- $newHosts[$k] "; fputs($file, textboxFu($newHosts[$k],$xHosts,$y,150,"FFA 500") .hostFu($newHosts[$k],$xHosts+135,$y));
45 5.2. DEFINIZIONE COMPONENTI CAPITOLO 5. PROGETTAZIONE
$yH =$y +12; if($services!=0){ for($i=0;$i<$services;$i++){ if($newServicesH[$i]==$newHosts[$k]){ fputs($file, textboxFu($newServices[$i],$xServices , $y,150,"00BFFF").serviceFu($newServices[$i], $xServices+135,$y,$newServicesH[$i])); $y=$y +12; fputs($file, lineFu(11,"190,249","$yH,$y")); $y=$y +13; } } }//End insert services $y=$y +25; } echo "
Per quanto riguarda il successivo inserimento all’interno della mappa dei servizi i cui host non appartengono al processo, il procedimento `epressoch´eanalogo. Per`o`eimportante specificare che l’host non viene definito come appartenente alla mappa ma `esemplicemente visualizzata una stringa con il suo nome. Il suo stato non viene quindi monitorato. Questa scelta `estata dettata dal fatto che si `eriscontrata una differenza nell’interpretazione di ”stato dell’host” tra Nagios e NagVis. Il primo control- la se la situazione dell’host `eUP, DOWN o UNREACHABLE; il suo plugin invece assegna all’host lo stato pi`u”critico” tra tutti quelli dei servizi che gli appartengono, sia definiti nella mappa che presenti solo in Nagios. Per evitare di avere differenze tra gli elementi che vengono monitorati nei due software si `edeciso di non inserire nemmeno nella visualizzazione Nagios, gli host che non sono stati esplicitamente aggiunti come componenti del pro- cesso. Questa soluzione per`onon risolve a pieno il problema perch´equalora l’host che genera lo stato di incongruenza tra i due sistemi fosse tra quelli da monitorare l’utente avr`aun esito discordante del controllo dello stato del pro- cesso, tra la visione di Nagios e quella di NagVis. L’aggiornamento del file processes.cfg viene effettuato con il seguente codice fputs($filenagios, "define process { process_name $nomeProcesso host_name$proHosts hostgroup_name$proHostsG
46 CAPITOLO 5. PROGETTAZIONE 5.2. DEFINIZIONE COMPONENTI
service_members$proServices servicegroup_name$proServicesG contact_members$proContact contactgroup_members$proContactG } ");
Nelle variabili sono presenti i dati inseriti dall’utente formattati secondo la specifica notazione per la definizione del processo. Dopo che sono state eseguite tutte le operazioni per creare e aggiornare i file d’interesse viene inserito nella pagina php un pulsante per permettere all’utente di passare alla visualizzazione del processo che ha appena definito. In NagVis non `estata inserita la possibilit`adi scelta da parte dell’utente della soglia di ”Warning” e di ”Critical”. L’implementazione di questa funzion- alit`aavrebbe richiesto uno studio approfondito del codice NagVis per il quale non era stato preventivato del tempo percui le ore di lavoro sono state dedicate al soddisfacimento dei requisiti obbligatori tralasciando questa caratteristica di secondaria importanza.
47 5.2. DEFINIZIONE COMPONENTI CAPITOLO 5. PROGETTAZIONE
48 Capitolo 6
Test
Questo capitolo ha lo scopo di esporre i test pi`usignificativi effettuati durante le fasi Questo capitolo ha lo scopo di esporre i test pi`usignificativi effettuati durante le fasi di verifica e collaudo dei moduli prodotti durante lo stage, di descrivere gli eventuali problemi rilevati e come questi sono stati affrontati. Per lo sviluppo del progetto ed anche per la successiva fase di test sono stati resi disponibili dall’azienda tutti i mezzi necessari, quali:
• Un computer con gi`ainstallato il sistema operativo openSUSE
• Un server di prova
• Un collegamento alla rete internet
Tutta la documentazione o le informazioni necessarie per lo sviluppo e gli ap- profondimenti sono disponibili in Internet. Seguendo le indicazioni fornite in- izialmente e quelle specificate nel capitolato c’`estato ugualmente modo di anal- izzare diverse possibili soluzioni per lo sviluppo dei plugin, per poi scegliere la modalit`aimplementativa migliore.
6.1 Test effettuati
I test per il corretto funzionamento di tutte le componenti dei moduli svilup- pati, sono stati fatti a partire dall’inizio della stesura del codice per quanto riguarda l’utilizzo di tecniche di analisi statica, e da quando `estato prodotto il primo modulo per l’analisi dinamica. Quest’ultima, detta anche prova soft- ware consiste nella verifica dinamica del comportamento di un programma su un inseme finito di casi.
49 6.1. TEST EFFETTUATI CAPITOLO 6. TEST
Sono emerse le seguenti problematiche:
• L’interpretazione dello stato di un host `edifferente tra Nagios e NagVis, questo perch´edettato da controlli di tipo diverso da parte dei due sistemi. Per evitare in parte la situazione di incongruenza dei risultati dello stato globale di uno stesso processo nei due software `estato necessario fare dis- tinzione tra host appartenenti al processo e quindi da monitorare, e host di cui solo i servizi sono da controllare perch´ecomponenti del processo. Il problema persiste quando l’host che genera l’incongruenza `etra quelli da monitorare. Dopo uno studio sul codice NagVis atto all’interpretazione degli stati dei diversi oggetti Nagios, in particolare quello presente nella cartella /usr/local/nagvis/share/server/core/classes/objects/, si `e deciso di non modificare le classi gi`adefinite. Sar`aquindi possibile ad esempio avere la situazione in cui uno stesso pro- cesso in Nagios ha stato OK ed in NagVis WARNING per le motivazioni precedentemente esposte.
• La gestione di hostgroup e servicegroup `erisultata molto complessa perch´e al loro interno possono contenere altri hostgroup e servicegroup. In caso di quantit`acospicue di oggetti il controllo risultava estremamente lento con complessit`acomputazionale di O(n6). Analizzando meglio i casi da valutare ed i controlli da effettuare si `eriuscito a portare questa complessit`aa O(n4) che risulta essere comunque alta ma gestibile pi`ufacilmente.
Nella fase di prova dell’interfaccia grafica offerta da NagVis si `eriscontrato un problema della versione software, in quanto se si modificavano determi- nate caratteristiche della mappa (che per noi rappresenta il processo) c’era la possibilit`ache venissero generati degli errori. Poniamo l’esempio che si vada a modificare il processo ”primo” perch´ela visualizzazione non `edi nostro gradimento. Vogliamo ingrandire il contorno delle etichette e renderne doppie tutte le sue dimensioni, l’applicazione ci d`ala possibilit`adi farlo. Quando si va a caricare la pagina relativa al processo questa non viene visualizzata perch´evengono inseriti dei parametri non riconosciuti ed appare una finestra che segnala l’errore. Passando alla versione successiva del software il problema non si `epi`uriscontrato.
50 CAPITOLO 6. TEST 6.2. COLLAUDO
6.2 Collaudo
Durante tutto lo sviluppo del progetto, i moduli sono stati testati sul soft- ware Nagios e Nagvis installato inizialmente. Non `estata possibile l’imple- mentazione di una vera e propria rete con diverse macchine aventi servizi ed altri oggetti da monitorare, ma essendo il sistema operativo sottostante Lin- ux il singolo elaboratore `eutilizzabile anche come server. Questa importante caratteristica ha dato la possibilit`adi effettuare, sulla singola macchina, una simulazione della situazione reale per compiere la fase di collaudo. Per una simulazione corretta `estato necessario:
• Avere le caratteristiche del software dell’elaboratore descritte nel paragrafo 4.2
• Definire, secondo la sintassi Nagios, pi`udi un host teorico, che nella realt`a corrispondeva sempre al localhost, ciascuno con ogni tipologia di oggetti, quali servizi, contatti, hostgroup, etc.
• Definire dei processi per comprendere i possibili casi di prova che avrebbero messo in difficolt`ai moduli
• Compiere operazioni di creazione, manutenzione, monitoraggio di processi attraverso l’interfaccia NagVis
• Creare quindi tutte quelle situazioni ritenute di possibile criticit`adallo stu- dio effettuato a priori, quelle in cui si potrebbero verificare degli errori per un’errata interpretazione da parte del modulo sviluppato
Dopo alcune semplici prove con questi elementi si `etestata la reazione dei mod- uli abilitando o disabilitando determinati servizi sulla macchina, per monitorare l’effetto che questo comportava. Le prove sono state effettuate in diversi momenti per pi`uvolte, ed al ter- mine prestabilito anche in presenza del tutor esterno corrispondente al pro- ponente. Sono state inoltre testate tutte le caratteristiche corrispondenti ai requisiti richiesti per verificare che fossero soddisfatti tutti quelli obbligatori e desiderabili. E` stato possibile anche il soddisfacimento di uno dei due requisiti opzionali. La fase di collaudo ha dato quindi esito positivo e si pu`opensare ad un possibile utilizzo dei moduli sviluppati, all’interno dell’azienda.
51 6.2. COLLAUDO CAPITOLO 6. TEST
52 Capitolo 7
Installazione plugin
In questo capitolo vengono spiegate in dettaglio le azioni necessarie per una corretta configurazione dei plugin che sono stati sviluppati, sia nell’ambiente Nagios che in quello NagVis.
7.1 Configurazione Nagios
Per poter utilizzare il plugin sviluppato per Nagios `enecessario andare ad in- serire o sostituire alcuni file presenti nella nuova configurazione gi`apresente nell’elaboratore. Tutti i file che vengono elencati sono forniti in un unico pac- chetto fornito sotto forma di file .zip, spetta all’utente inserirli correttamente nella directory giusta.
• /usr/local/nagios/share/side.php File che rappresenta il men`uNagios sempre presente nella parte sinistra della pagina. E` necessario inserirlo perch´esono stati aggiunti i link alle due diverse visualizzazioni sviluppate.
• /usr/local/nagios/etc/localhost.cfg File di configurazione di host e hostgroups dei quali contiene tutte le de- finizioni. E` necessario inserirlo perch´enell’installazione di Nagios eseguita seguendo il manuale contiene la definizione di tutti gli oggetti. Si `evoluto quindi fare una distinzione e raggruppare da un lato host e dall’altro servizi.
• /usr/local/nagios/etc/services.cfg File di configurazione di servizi e servicegroups dei quali contiene tutte le definizioni. E` necessario inserirlo perch´eNagios non lo definisce, in quanto come detto nel punto recedente, raggruppa tutti gli oggetti in un unico file.
53 7.2. CONFIGURAZIONE NAGVISCAPITOLO7. INSTALLAZIONE PLUGIN
• /usr/local/nagios/etc/processes.cfg File di configurazione dei processi che verranno definiti. Non `enecessario inserirlo perch´einizialmente non avr`adefinizioni, al suo interno `epresente un esempio di processo lasciato commentato, per fornire all’utente una sorta di template sulla base del quale definire tutti i processi che intende monitorare. Qualora non venisse inserito quando bisogner`adefinire il primo processo l’utente dovr`acrearlo.
• /usr/local/nagios/sbin/process.cgi File CGI che permette di interpretare i dati presenti nei diversi file di con- figurazione. Fornisce la visione tabellare dei processi, a livello globale o dettagliato, e dei loro stati.
• /usr/local/nagios/libexec/check process Script Perl che effettua i controlli necessari per definire lo stato globale del processo che gli viene passato come parametro, tenendo in considerazione i livelli di warning e critical impostati dall’utente.
• /usr/local/nagios/libexec/send notification Script Perl che a seconda della struttura del parametro che gli viene passato genera un testo che poi spedisce come corpo di una email ai contatti preposti.
Inoltre l’utente dovr`adefinire in nagios.cfg il riferimento al file di configurazione contenente i servizi ed i servicegroups con la seguente riga di codice cfg file=/usr/local/nagios/etc/objects/services.cfg
7.2 Configurazione NagVis
Solo dopo aver configurato correttamente la parte relativa a Nagios (e ovvia- mente aver installato NagVis) si possono inserire i file relativi all’utilizzo del plugin per la creazione del processo. Tutti i file che vengono elencati sono forniti in un unico pacchetto, spetta all’utente inserirli correttamente nella directory giusta.
• /usr/local/nagvis/share/userfiles/templates/default.header.html File che rappresenta il men`uNagVis presente nella parte superiore delle sue pagine. E` necessario inserirlo perch´e`estato aggiunto il link che permette di avviare la procedura di creazione del nuovo processo.
54 CAPITOLO 7. INSTALLAZIONE PLUGIN7.2. CONFIGURAZIONE NAGVIS
• /usr/local/nagvis/share/frontend/nagvis-js/classes/ NagVisHeaderMenu.php In questo file sono presenti le definizioni di tutte le variabili che vengono utilizzate per il men`u. E` necessario inserirlo perch´e`estata aggiunta la definizione della variabile riguardante il link per la creazione del processo.
• /usr/local/nagvis/share/frontend/nagvis-js/createMap.php Prima pagina php che `estata sviluppata per la creazione del processo. Per- mette l’inserimento dei parametri corrispondenti a numero, tipo e identifi- cazione degli oggetti che si intendono monitorare.
• /usr/local/nagvis/share/frontend/nagvis-js/createView.php Seconda pagina php che `estata sviluppata per la creazione del processo. Ef- fettua un controllo sui parametri inseriti nella pagina precedente e se corretti crea il processo in Nagios e NagVis.
• /usr/local/nagvis/share/userfiles/images/maps/leg.png Immagine di sfondo della mappa per avere la legenda che illustri il significato delle icone di stato.
Per avere un’idea a livello generale della gerarchia di cartelle che il plugin utilizza, si faccia riferimento alla figura 5.7
55 7.2. CONFIGURAZIONE NAGVISCAPITOLO7. INSTALLAZIONE PLUGIN
56 Capitolo 8
Utilizzo del plugin
In questo paragrafo vengono mostrate le principali caratteristiche del modulo sviluppato e viene data una spiegazione dell’uso che l’utente ne pu`ofare. Come prima cosa `enecessario che l’utente inserisca nome utente e password per accedere al sistema Nagios che normalmente utilizza. La situazione che gli si presenta `ela seguente:
Figura 8.1: Nagios home page
57 8.1. MODULO NAGIOS CAPITOLO 8. UTILIZZO DEL PLUGIN
Il men`uNagios `esempre presente nella parte sinistra della pagina, la nav- igazione avviene a destra permettendo cos`ı di cambiare vista in modo pi`u rapido. L’utente a cui `edestinato il plugin sviluppato utilizza gi`ail software Nagios e quindi ne conosce il funzionamento. La prima differenza che si nota `el’aggiunta, nel men`u,della sezione ”Monitored processes” la quale contiene due nuovi link.
Figura 8.2: Link per visualizzare i processi
Come utilizzare questi link verr`aspiegato nelle prossime sezioni.
8.1 Modulo Nagios
Per definire un processo utilizzando solamente il software Nagios ed il plugin sviluppato, l’utente deve avere i permessi di accesso in lettura e scrittura al file di configurazione processes.cfg qualora fosse gi`astato creato. In quest’ul- timo pu`oaggiungere la definizione che desidera sempre rispettando la sintassi preposta. Nel caso in cui il file di configurazione per i processi non fosse presente nell’apposita cartella l’utente deve crearlo. Questa situazione si verificher`a solamente al primo accesso che che si vorr`afare al file. La struttura per la definizione del processo all’interno del file di configurazione e l’eventuale creazione di quest’ultimo sono definite nel capitolo 4.4. Il link ”Nagios pro- cesses” permette di avere una visione d’insieme dello stato dei processi che sono stati definiti. Nel riquadro in alto a sinistra sono sempre disponibili le informazioni ri- guardanti lo stato della pagina creata tramite cgi. Tra queste `eanche presente l’intervallo di tempo che intercorre tra un controllo ed il successivo. Come si pu`ovedere dalla figura nella pagina successiva la grafica `eessenziale e coerente con la tipica struttura Nagios.
58 CAPITOLO 8. UTILIZZO DEL PLUGIN 8.1. MODULO NAGIOS
Figura 8.3: Visione globale dei processi in Nagios
In questa pagina l’utente riesce a controllare lo stato di tutti i processi che sono stati definiti rendendo pi`usemplice il monitoraggio della rete per la quale deve garantire il corretto funzionamento dei servizi. Con l’aiuto dell’interfaccia grafica del plugin sar`aquindi sufficiente monitorare la pagina corrispondente all’illustrazione 8.3 per sapere se `enecessario un intervento atto a ripristinare la situazione ideale. Quando viene riscontrato un problema a livello globale su un determinato processo `esufficiente cliccare il link presente sul corrispondente nome, per ottenerne una visualizzazione pi`uparticolareggiata. Come si pu`ovedere nell’immagine 8.4, nella pagina riguardante lo specifico processo vengono rappresentati tutti gli oggetti che gli appartengono. Questa visione dettagliata permette di risalire al servizio o all’host che ha causato lo stato di non corretto espletamento delle funzioni che compongono il processo.
59 8.2. ADDON NAGVIS CAPITOLO 8. UTILIZZO DEL PLUGIN
Figura 8.4: Visione dettagliata dei processi in Nagios
Posto l’esempio del processo inteso come ”mail service” quando uno degli host non riceve pi`ula posta elettronica `esufficiente andare a controllare lo stato delle componenti dello stesso per trovare l’oggetto che ha generato il problema. Se non fosse definito il processo, per trovare il problema si sarebbe dovuto controllare lo stato di tutti gli oggetti definiti in Nagios.
8.2 Addon NagVis
Il link ”NagVis processes” permette di accedere ad una visione alternativa dei processi definiti rispetto a quella offerta da Nagios. Al primo accesso all’utente si presenta la seguente schermata per effettuare il login in NagVis, potr`apoi decidere se memorizzare la password per non doverla reinserire ogni volta che il servizio viene riavviato. Ad ogni modo se l’utente effettua il login quando accende la macchina poi fino al suo spegnimento non gli verr`achiesto nuovamente.
60 CAPITOLO 8. UTILIZZO DEL PLUGIN 8.2. ADDON NAGVIS
Figura 8.5: NagVis home page
Dopo aver inserito correttamente nome utente e password si ha una visione globale di tutti i processi definiti. Oltre al servizio aggiuntivo di creazione guidata che `estato definito si `edeciso di lasciare tutte le funzionalit`agi`a presenti in NagVis per permettere all’utente competente una massima usabilit`a del software. Nell’immagine seguente `erappresentata la pagina che si presenta all’utente una volta loggato. D`auna visione d’insieme di tutti i processi che sono stati definiti. (In aggiunta `epresente una tabella contenente lo stato delle automap, le quali sono delle altre funzionalit`aofferte da NagVis.) Al passaggio del mouse sopra al riquadro rappresentante un processo compare una tabella che rias- sume alcune delle componenti che caratterizzano il processo in questione ed il loro stato. Cliccando su uno di questi riquadri si passa alla visualizzazione di dettaglio del processo che si `eselezionato. Da questa visione di dettaglio si hanno informazioni relative a tutti gli oggetti che compongono il processo, quali servicegroups, hostgroups, servizi e host. La situazione descritta `equella presentata nella figura 8.6.
61 8.2. ADDON NAGVIS CAPITOLO 8. UTILIZZO DEL PLUGIN
Figura 8.6: Visione globale dei processi in NagVis
In ogni schermata rappresentante un processo `esempre presente la legenda sul lato destro della pagina. Nella parte superiore della pagina sempre su sfondo verde c’`euna sezione che individua il nome del processo visualizzato e lo stato in cui si trova. Per non creare incomprensioni sono presenti delle frecce che collegano ciascun host ai suoi servizi che si `escelto di monitorare. Ogni oggetto nella mappa (cos`ı`echiamata in NagVis questa visualizzazione) ha associata un’icona che ne rappresenta lo stato, o meglio, tutti gli oggetti che si `erichiesto di monitorare hanno questa piccola immagine. Si noti, nell’esempio di processo riportato nell’immagine che segue, come l’icona raffigurante lo stato non `epresente nel secondo e terzo host mentre invece compare nel primo. Questo `edovuto al fatto che quando l’utente ha creato il processo ha inserito fra gli host da monitorare solamente ”localhost” che quindi viene controllato. La domanda che sorge spontanea a questo punto `e”Perch´esono presenti anche altri due host se l’utente non l’ha richiesto?”. La risposta `emolto sem- plice, quando si scelgono i servizi da monitorare `enecessario specificare a quale host appartengono, se questo non fa parte degli host che si vogliono controllare viene inserita nella mappa semplicemente la sua etichetta.
62 CAPITOLO 8. UTILIZZO DEL PLUGIN 8.2. ADDON NAGVIS
In questo modo l’utente non influenza lo stato globale del processo ma pu`o vedere ugualmente il nome dell’host al quale sono associati i servizi che ha scelto di controllare.
Figura 8.7: Visualizzazione NagVis del processo ”primo”
Come nel caso della visualizzazione globale anche qui c’`ela possibilit`adi avere delle informazioni pi`udettagliate su ciascun oggetto definito nella mappa. Infatti passando con il cursore, poniamo l’esempio, sull’icona che rappresenta lo stato di un servizio compare una tabella che descrive le caratteristiche specifiche dello stesso. Con un click sull’icona di ciascun oggetto si passa in automatico alla visualizzazione Nagios, generata tramite extinfo.cgi, che specifica in det- taglio tutti i parametri relativi ad esso. In alto `epresente la barra di stato NagVis, grazie al men`ua discesa che compare al semplice passaggio del mouse `epossibile navigare nell’anbiente NagVis. Nella sezione ”Open” c’`ela possibilit`adi tornare alla vista globale dell’illus- trazione 8.6, visualizzare un processo a scelta tra quelli definiti, o usufruire di altre funzionalit`aofferte da NagVis. Come seconda voce di questo men`utrovi- amo il link per l’utilizzo del modulo che durante lo stage `estato implementato per questo software sotto la voce ”Create new process”.
63 8.2. ADDON NAGVIS CAPITOLO 8. UTILIZZO DEL PLUGIN
Figura 8.8: Men`uOpen di NagVis
In ”Actions” sono presenti delle voci che rappresentano azioni che si possono compiere all’interno di una mappa.
Figura 8.9: Men`uActions di NagVis
64 CAPITOLO 8. UTILIZZO DEL PLUGIN 8.2. ADDON NAGVIS
8.2.1 Creare un processo Per la creazione di un nuovo processo basta cliccare su “Create new process” ed una semplicissima interfaccia guida l’utente nella procedura. Per prima cosa viene richiesto il numero di oggetti da creare per ciascuna categoria. Una vol- ta premuto il pulsante OK, se i dati sono corretti, si richiede innanzitutto di inserire il nome del processo dopo di che a seconda dei parametri precedente- mente immessi `epresente un determinato numero di men`ua discesa. Ciascuno di essi ha come parametri i nomi dei corrispettivi oggetti che sono gi`adefiniti in Nagios. La situazione descritta `eraffigurata nell’immagine 8.10.
Figura 8.10: Men`uOpen di NagVis
Dopo aver inserito tutti i parametri basta cliccare il pulsante ”Create pro- cess” per avviare i controlli per la creazione del processo. Qualora l’utente inserisca un nome di processo che risulta gi`adefinito gli viene segnalato l’errore e, tornando alla pagina precedente attraverso l’apposito pulsante, pu`oessere corretto. Altro errore che si potrebbe commettere `eassociare un servizio ad un host che non lo contiene per correggerlo si procede come nel caso precedente.
65 8.2. ADDON NAGVIS CAPITOLO 8. UTILIZZO DEL PLUGIN
Inserendo tutti i parametri corretti si passa alla visualizzazione di un rias- sunto dei dati che sono stati inseriti nella creazione del processo come mostrato dall’immagine 8.11.
Figura 8.11: Men`uActions di NagVis
Infine premendo il pulsante ”View process” si passa alla visualizzazione grafica del processo. (Figura 8.12) Come si pu`onotare lo stato d’insieme del processo `einfluenzato dallo stato di tutte le sue componenti, in questo caso il fatto che semplicemente un host sia in stato di allerta comporta uno stato globale di ”WARNING”.
66 CAPITOLO 8. UTILIZZO DEL PLUGIN 8.2. ADDON NAGVIS
Figura 8.12: Men`uActions di NagVis
67 8.2. ADDON NAGVIS CAPITOLO 8. UTILIZZO DEL PLUGIN
68 Capitolo 9
Conclusioni
In questo ultimo capitolo dopo il consuntivo sulle ore preventivate, vengono esposte alcune considerazioni tecniche sull’utilizzo che potr`aessere fatto del software e per concludere delle impressioni personali.
9.1 Consuntivo
Lo stage `einiziato il giorno 18/10/2010 e si `econcluso il giorno 16/12/2010. A progetto concluso `estata fatta una presentazione ed il collaudo dell’appli- cazione, per verificare la correttezza delle funzionalit`asviluppate ed esporre al tutor ed all’ufficio preposto i moduli prodotti. Prima dell’inizio dello stage `estato fatta una stima delle ore da dedicare ad ogni fase dello sviluppo del progetto, la suddivisione del carico di lavoro preventivata `ela seguente:
Attivit`a Ore Studio della documentazione Nagios 40 Approfondimento del funzionamento pratico del server Nagios 50 Definizione dei processi 50 Sviluppo dei moduli 90 Test 40 Documentazione 40 TOTALE ORE 310
Tabella 9.1: Tabella riassuntiva ore preventivate per le attivit`adi stage.
69 9.2. APPLICAZIONI DEL SOFTWARE CAPITOLO 9. CONCLUSIONI
C’`estato tempo a sufficienza per soddisfare tutti i requisiti obbligatori e desiderabili, inoltre si `epotuto estendere il codice prodotto affinch´epermettesse il soddisfacimento di un requisito opzionale. Come si pu`ovedere dal grafico (consuntivo) i tempi preventivati sono stati pressoch´erispettati fatta eccezione per le fasi di progettazione e program- mazione le quali hanno richiesto del tempo aggiuntivo. Queste ore che sono state aggiunte non vanno per`oad aumentare il monte ore totale se non di due unit`ain quanto la fase di studio del dominio e del software da utilizzare `estata pi`ubreve del previsto.
Figura 9.1: Consuntivo con le preventivate e quelle effettive.
9.2 Applicazioni del software
Durante lo studio del software nel quale inserire il progetto ho potuto imparare come funzionano le diverse applicazioni per il monitoraggio di risorse di rete che prima mi erano totalmente sconosciute. Nagios `eun software open source molto diffuso utilizzato a partire dalla fine degli anni novanta. E` in continuo miglioramento da parte degli sviluppatori e da utenti competenti i quali seg-
70 CAPITOLO 9. CONCLUSIONI 9.3. CONSIDERAZIONI PERSONALI
nalano le problematiche riscontrate, ma possono anche loro stessi sviluppare dei plugin per integrare le funzionalit`adel sistema che desiderano. L’azienda utilizza Nagios per monitorare la rete di diversi clienti, ha richiesto lo sviluppo del plugin per permettere al personale dedicato al supporto di indi- viduare in tempi brevi la presenza di un problema e la causa di taluno. Questo per velocizzare il tempo d’intervento a beneficio del personale, che ci metter`a meno a trovare il problema, e del cliente il quale avr`aun disservizio minore. Il plugin sviluppato e testato su una simulazione dei rete pu`oessere instal- lato ed utilizzato nel reale contesto per cui `estato pensato. Inizialmente sar`a necessario dedicare del tempo per definire tutti i processi da monitorare ma una volta fatto questo si avranno i benefici descritti precedentemente. Qualora si decidesse di non utilizzare NagVis ma si volesse ugualmente avere una procedu- ra guidata per la creazione del processo `esufficiente effettuare delle modifiche ad alcune semplici istruzioni nei file createMap.php e createView.php, quali:
• La modifica del path per aprire i file di configurazione dei vari oggetti Nagios
• La rimozione di tutte le funzioni, e delle rispettive chiamate, per la creazione di oggetti appartenenti alle mappe NagVis
• La modifica del link che dalla pagina di report porta alla visualizzazione del processo Invece nel file side.php di Nagios il link ”NagVis processes” diven- terebbe ”Create new process” con riferimento alla pagina createMap.php
9.3 Considerazioni personali
Lo studio e la successiva realizzazione dei moduli richiesti per il progetto di stage `estato molto interessante, in quanto mi ha permesso di studiare nel dettaglio la struttura del software Nagios, dei suoi plugin e della piattaforma openSUSE sulla quale `estato installato. Questo mi ha consentito di ragionare approfonditamente sul possibile sviluppo dei moduli richiesti dall’azienda in vista della loro installazione nel sistema gi`ain utilizzo presso di loro. Questa esperienza, oltre ad aver accresciuto le mie conoscenze nell’ambito dei software di monitoraggio di risorse di rete, mi ha dato la possibilit`adi inserirmi in un ambito lavorativo che ho trovato molto accogliente e stimolante per la crescita personale. Inoltre, per l’inserimento in un ambito lavorativo nel settore IT oppure per un eventuale futuro di collaborazione con l’azienda, `estato molto importante capire il modo di lavorare al suo interno e comprendere come funzionano le piattaforme su cui si opera.
71 9.3. CONSIDERAZIONI PERSONALI CAPITOLO 9. CONCLUSIONI
72 Appendice A
Framework ITIL
Information Technology Infrastructure Library (ITIL), `eun insieme di linee guida ispirate dalla pratica (Best Practices) nella gestione dei servizi IT (IT Service Management) e consiste in una serie di pubblicazioni che forniscono indicazioni sull’erogazione di servizi IT di qualit`ae sui processi e mezzi necessari a supportarli. Il progetto sviluppato si inserisce in questo contesto, in particolare nel mod- ulo del Service Management, il quale contiene a sua volta due sezioni, ”Service Delivery” e ”Service Support”. I plugin che sono stati prodotti appartengono a quest’ultimo e servono a facilitare le diagnostiche di errori e quindi a migliorare il servizio fornito al cliente. All’interno del ”Service Support” i plugin prodotti appartengono al modulo dell’Incident Management, il quale `eresponsabile della gestione di tutti gli errori, la loro individuazione e registrazione fino alla risoluzione finale e la chiusura del problema. L’obiettivo di Incident Management `eil ripristino del normale servizio non appena possibile con il minimo disturbo per il business. IT Service Management (ITSM) `ela disciplina che si occupa della ges- tione di sistemi di information technology (IT) su larga scala, filosoficamente concentrata sulla prospettiva del cliente e del contributo dell’IT al business. I fornitori di servizi IT non possono pi`upermettersi di focalizzarsi solo sulla tecnologia, devono ora considerare la qualit`adei servizi che forniscono e focalizzarsi nella relazione con il cliente. Le raccomandazioni di ITIL sono state sviluppate negli anni ottanta dal- la Central Computer and Telecommunications Agency (CCTA) del Governo Britannico in risposta alla crescente dipendenza dall’information technology. Riconoscendo che, senza pratiche standard, i contratti fra gli enti governativi e le organizzazioni del settore privato venivano generati indipendentemente dalle proprie pratiche di gestione IT e duplicavano gli sforzi all’interno dei loro
73 APPENDICE A. FRAMEWORK ITIL progetti ICT (Information and Communications Technology) con conseguenti errori ed incremento dei costi. Le prime pubblicazioni furono rilasciate nel 1989 ma ITIL non `estato largamente adottato fino alla met`adegli anni novanta. Questa pi`ularga adozione e conoscenza ha condotto all’emissione di stan- dard a supporto, incluso ISO/IEC 20000 (precedentemente British Standards — BS 15000), il quale `euno standard internazionale che ricopre molti degli elementi di ITIL per la gestione dei servizi IT. Il framework `ebasato fonda- mentalmente su best practices nel service management, non `ecio`eun modello teorico, ma una collezione di pratiche che hanno dato prova sul campo di es- sere funzionali ad una solida implementazione di IT Service Management di alto livello. Secondo ITIL i tre obiettivi dell’IT Service Management (ITSM) sono i seguenti:
• Allineare i servizi IT con i bisogni correnti e futuri del business e dei clienti
• Migliorare la qualit`adei servizi IT erogati
• Ridurre i costi fissi di erogazione dei servizi
La filosofia ITIL adotta un approccio process-driven che si pu`outilizzare in organizzazioni sia grandi che piccole. L’IT service management `escomposto in una serie di processi integrati e correlati tra loro. La figura A.1 rappresenta l’ambiente globale e la struttura in cui i moduli sono stati prodotti. Essa illustra il rapporto che ognuno dei moduli ha con il business e la tecnologia. Dal grafico si pu`onotare come il modulo ”La Prospet- tiva di Business” `epi`ustrettamente allineato con il business e l’ ”ICT Infras- tructure Management” `eil modulo pi`ustrettamente allineato con la tecnologia stessa. Il Service Desk fornisce un unico punto centrale di contatto per tutti gli utenti dell’IT all’interno di una organizzazione, gestione di tutti gli incidenti, le domande e le richieste. Fornisce un’interfaccia per tutti i processi del Service Support.
74 APPENDICE A. FRAMEWORK ITIL
Figura A.1: Framework ITIL
ITIL suggerisce sia implementato il proprio framework di service manage- ment (e che hanno valore anche oltre l’ITIL) secondo una successione ben definita di passi (process improvement model) che portano ad uno stato in cui il miglioramento del processo `ecostruito all’interno del processo stesso. I passi sono:
• Definizione della Visione e degli obiettivi di business (chiedersi dove si vuole arrivare)
• Accertamento della situazione corrente (chiedersi dove si `eadesso)
• Definizione del percorso di implementazione (chiedersi come arrivare fino alla realizzazione della visione e degli obiettivi di business)
• Definizione dei criteri di misura e di metriche (chiedersi come definire i punti di arrivo in termini quantitativi)
75 APPENDICE A. FRAMEWORK ITIL
76 Appendice B
Installazione MKLivestatus
Per impostare manualmente Livestatus, `epossibile scaricare il codice sor- gente indipendentemente dal Check MK alla pagina di download. Scompattate l’archivio in un luogo adeguato ed entrare nella directory appena creata: root@linux# wget ’http://www.mathias-kettner.de/download/mk- livestatus -1.1.6p1.tar.gz’ root@linux# tar xzf mk-livestatus-1.1.6p1.tar.gz root@linux# cd mk-livestatus-1.1.6p1 Adesso bisogna compilare il modulo. Livestatus utilizza uno standard di script di configurazione ed `equindi compilato con ./configure && make. user@host> ./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for g++... g++ checking for C++ compiler default output file name... a.out checking whether the C++ compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes ... e cos`ıvia, finch`e: configure: creating ./config.status config.status: creating Makefile
77 APPENDICE B. INSTALLAZIONE MKLIVESTATUS config.status: creating src/Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands Se si esegue su una CPU multicore `epossibile velocizzare la compilazione con l’aggiunta di -j 4 oppure -j 8 al comando make: user@host> make -j 8 g++ -DHAVE_CONFIG_H -I. -I.. -I../nagios -fPIC -g -O2 -MT livestatus_so-AndingFil... g++ -DHAVE_CONFIG_H -I. -I.. -I../nagios -fPIC -g -O2 -MT livestatus_so-ClientQue... g++ -DHAVE_CONFIG_H -I. -I.. -I../nagios -fPIC -g -O2 -MT livestatus_so-Column.o ... g++ -DHAVE_CONFIG_H -I. -I.. -I../nagios -fPIC -g -O2 -MT livestatus_so-ColumnsCo... g++ -DHAVE_CONFIG_H -I. -I.. -I../nagios -fPIC -g -O2 -MT livestatus_so-ContactsC... g++ -DHAVE_CONFIG_H -I. -I.. -I../nagios -fPIC -g -O2 -MT livestatus_so-CustomVar... g++ -DHAVE_CONFIG_H -I. -I.. -I../nagios -fPIC -g -O2 -MT livestatus_so-CustomVar...... e cos`ıvia. Dopo che la compilazione ha avuto successo, un make install installer`aun singolo campo chiamato livestatus.o in /usr/local/lib/mk-livestatus ed il programma unixcat in /usr/local/bin (come al solito, `epossibile modificare i tracciati con le opzioni standard da configure): root@linux# make install Making install in src make[1]: Entering directory ‘/d/nagvis-dev/src/mk-livestatus -1.1.6p1/src’ make[2]: Entering directory ‘/d/nagvis-dev/src/mk-livestatus -1.1.6p1/src’ test -z "/usr/local/bin" || /bin/mkdir -p "/usr/local/bin" /usr/bin/install -c ’unixcat’ ’/usr/local/bin/unixcat’ test -z "/usr/local/lib/mk-livestatus" || /bin/mkdir -p "/ usr/local/lib/mk-livestatus" /usr/bin/install -c -m 644 ’livestatus.so’ ’/usr/local/lib/mk-livestatus/livestatus .so’ ranlib ’/usr/local/lib/mk-livestatus/livestatus.so’ /bin/sh /d/nagvis-dev/src/mk-livestatus -1.1.6p1/install-sh -d /usr/local/lib/mk-livestatus
78 APPENDICE B. INSTALLAZIONE MKLIVESTATUS
/usr/bin/install -c livestatus.o /usr/local/lib/mk- livestatus rm -f /usr/local/lib/mk-livestatus/livestatus.so make[2]: Leaving directory ‘/d/nagvis-dev/src/mk-livestatus -1.1.6p1/src’ make[1]: Leaving directory ‘/d/nagvis-dev/src/mk-livestatus -1.1.6p1/src’ make[1]: Entering directory ‘/d/nagvis-dev/src/mk-livestatus -1.1.6 p1’ make[2]: Entering directory ‘/d/nagvis-dev/src/mk-livestatus -1.1.6 p1’ make[2]: Nothing to be done for ‘install-exec-am’. make[2]: Nothing to be done for ‘install-data-am’. make[2]: Leaving directory ‘/d/nagvis-dev/src/mk-livestatus -1.1.6 p1’ make[1]: Leaving directory ‘/d/nagvis-dev/src/mk-livestatus -1.1.6 p1’
Il tuo ultimo compito `equello di caricare livestatus.o in Nagios. A Nagios bisogna specificare che deve caricare quel modulo e inviare gli aggiornamenti di stato di tutti gli eventi al modulo.
79 APPENDICE B. INSTALLAZIONE MKLIVESTATUS
Questo con le seguenti due linee in nagios.cfg: broker_module=/usr/local/lib/mk-livestatus/livestatus.o / var/lib/nagios/rw/live event_broker_options=-1
L’unico argomento obbligatorio da specificare `eil percorso completo per il socket UNIX che Livestatus deve creare /var/lib/nagios/rw/live. Si prega di cambiarlo solo se necessario. La soluzione migliore `eprobabilmente quella di metterlo nella stessa directory come il Nagios pipe. Proprio come Nagios fa con la sua pipe, Livestatus crea il socket con le autorizzazioni 0660. Se la directory dove si trova il socket ha lo sticky bit di gruppo impostato, allora il socket sar`adi propriet`adello stesso gruppo della directory. Dopo aver impostato Livestatus - o con setup.sh o manualmente - riavviare Nagios. Due cose devono accadere ora:
1. Il socket file `estato creato.
2. Il file di log di Nagios mostra che il modulo `estato caricato.
In nagios.log si avr`ala seguente situazione: [ 1256144866 ] livestatus: Version 1.1.6p1 initializing. Socket path: ’/var/lib/nagios/rw/live’ [ 1256144866 ] livestatus: Created UNIX control socket at / var/lib/nagios/rw/live [ 1256144866 ] livestatus: Opened UNIX socket /var/lib/ nagios/rw/live [ 1256144866 ] livestatus: successfully finished initialization [ 1256144866 ] Event broker module ’/usr/local/lib/mk- livestatus/livestatus.o’ initialized successfully. [ 1256144866 ] Finished daemonizing... (New PID=5363) [ 1256144866 ] livestatus: Starting 10 client threads [ 1256144866 ] livestatus: Entering main loop, listening on UNIX socket
80 APPENDICE B. INSTALLAZIONE MKLIVESTATUS
Livestatus comprende diverse opzioni per nagios.cfg, che possono essere aggiunte alla linea che inizia con broker module:
Opzione Valore di Significato default debug 0 Impostare ad 1 per far si che Livestatus faccia log per ogni interrogazione che viene eseguita in nagios.log max cached 500000 Livestatus accede ai file di log Nagios con- messages tenenti messaggi in memoria. Qui `epossi- bile impostare il numero massimo di messag- gi memorizzati nella cache. Ogni messaggio richiede circa 250 byte (nell’implementazione attuale). max response 104857600 Livestatus costruisce ogni risposta in memo- size ria prima di inviarla ai clienti. Al fine di evitare un incidente in caso di query di di- mensioni consistenti, la dimensione massima della risposta `elimitata. Il limite predefinito `e100 MB. num client 10 Livestatus ha bisogno di un thread per og- threads ni connessione concorrente di client. Un nu- mero fisso di thread si crea quando si avvia Nagios. thread stack size 65536 (Nuovo in 1.1.4) Questo parametro imposta la dimensione dello stack di ciascun thread client. Nelle versioni precedenti alla 1.1.4, la dimensione dello stack era fissata a 8 MB (default pthread). Il nuovo valore predefinito `edi 64 KB. Un piccolo stack riduce l’utiliz- zo della memoria virtuale e permette anche di risparmiare risorse CPU. Per`oun valore troppo piccolo,potrebbe probabilmente man- dare in crash il processo di Nagios. Siete stati avvertiti . . .
81 APPENDICE B. INSTALLAZIONE MKLIVESTATUS query timeout 10000 Questo valore `ein millisecondi. Al fine di evitare di essere sospeso per i clienti rotti, Livestatus impone un limite al tempo per la lettura della query del client. Il valore 0 disabilita il timeout. idle timeout 300000 Questo valore `ein millisecondi. Livestatus resta in attesa al massimo cos`ıtanto tempo per la query successiva. Il valore 0 disabilita il timeout. Tabella B.1: Tabella dei parametri nagios.cfg per Livestatus
Un esempio su come aggiungere parametri (in nagios.cfg) lo puoi trovare: broker module=/usr/local/lib/mk-livestatus/livestatus.o /var/run/nagios/rw/live debug=1
82 Appendice C
Installazione NagVis
Queste istruzioni sono destinate ad una nuova installazione. Se si aggiorna la vecchia versione di NagVis consigliamo vivamente di fare un backup della vostra NagVis Directory e unire i file di configurazione manualmente.
STEP 0: Preparare il sistema Assicurati che il sistema si adatti ai requisiti di sistema.
STEP 1: Download NagVis Scarica NagVis, l’ultima versione la puoi trovare al link www.nagvis.org.
STEP 2: Decomprimere NagVis tar xvzf nagvis-1.5.x.tar.gz
STEP 3: Spostare la directory decompressa di NagVis Posizionare l’albero delle directory NagVis da qualche parte sul vostro sistema. Per la maggior parte dei casi /usr/local/nagvis `eil posto migliore. mv nagvis /usr/local/nagvis Dovreste vedere la lista di directory seguente: # ls -l /usr/local/nagvis etc licence readme share var
83 APPENDICE C. INSTALLAZIONE NAGVIS
Non spostare file o cartelle all’interno della directory NagVis (in realt`asi pos- sono spostare, ma in questo caso `enecessario modificare/aggiungere alcuni parametri e valori nel file di configurazione principale - se tutto `erimasto intatto dovrebbe funzionare out of the box senza cambiamenti nei file di configurazione)
STEP 4: Configurare NagVis Spostati nella nuova directory NagVis cd /usr/local/nagvis Un esempio di file principale di configurazione pu`oessere trovato in etc/nagvis.ini.php-campione. Se volete modificare alcune impostazioni, copiate questo esempio etc/nagvis.ini.php. cp etc/nagvis.ini.php-sample etc/nagvis.ini.php Ora `epossibile modificare questo file con un editor di testo - io uso VI: vi etc/nagvis.ini.php La maggior parte delle righe del nuovo nagvis.ini.php copiato sono commen- tate. Se si desidera immettere diverse impostazioni, si pu`osemplicemente de- commentare la linea e modificarne il valore. Per informazioni sui possibili valori dare un’occhiata alla sezione Main Config Fromat Description del manuale.
STEP 5: Configurare il webserver Dalla versione di NagVis 1,5 `enecessario configurare il server web per essere in grado di utilizzare NagVis. Troverete un file di configurazione di esempio in etc/apache2-nagvis.conf-sample. Basta copiare il file nella directory conf.d del webserver. Per esempio potrebbe essere /etc/apache2/conf.d. cp etc/apache2-nagvis.conf-sample /etc/apache2/conf.d/apache2-nagvis.conf Ora `enecessario aprire il file e modificare a vostro piacimento. E` importante sostituire le macro @NAGVIS WEB@ e @NAGVIS PATH@. In questo esempio `enecessario sostituire @NAGVIS WEB@ con /nagvis e @NAGVIS PATH@ con /usr/local/nagvis/share.
STEP 6: Permessi Questo `emolto importante per un’installazione perfettamente funzionante. Prima controlla quale account utente UNIX viene utilizzato per eseguire il server web (nel mio caso `ewwwrun). Se non si sa su quale utente `ein ese- cuzione il server web allora dare un’occhiata alla configurazione del webserver. In caso di Apache `epossibile farlo con il seguente comando:
84 APPENDICE C. INSTALLAZIONE NAGVIS
Ubuntu grep -e ’USER’ /etc/apache2/envvars SuSE/RedHat/Debian grep -e ’User’^ /etc/apache2/*.conf Se il file di configurazione si trova in un altro percorso che si dovrebbe risolvere questo con il comando precedente. Impostare le autorizzazioni per la directory NagVis (nel mio caso i percorsi sono come i seguenti): chown wwwrun:www /usr/local/nagvis -R chmod 664 /usr/local/nagvis/etc/nagvis.ini.php chmod 775 /usr/local/nagvis/etc/maps chmod 664 /usr/local/nagvis/etc/maps/* chmod 775 /usr/local/nagvis/etc/automaps chmod 664 /usr/local/nagvis/etc/automaps/* chmod 775 /usr/local/nagvis/share/userfiles/images/maps chmod 664 /usr/local/nagvis/share/userfiles/images/maps/* chmod 775 /usr/local/nagvis/var chmod 664 /usr/local/nagvis/var/* chmod 775 /usr/local/nagvis/var/tmpl/cache chmod 664 /usr/local/nagvis/var/tmpl/cache/*
E` possibile impostare le autorizzazioni di livello ancora pi`ubasso per i file, ma per la maggior parte delle configurazioni l’esempio dovrebbe andare bene. Cambiali solo se si sa cosa si sta facendo!
STEP 7: Lo strumento di configurazione grafica (WUI) NagVis ha incluso uno strumento di configurazione grafica basato sul web, chiamato WUI. Se lo si vuole usare utilizza il browser per aprire la pagina: http://
85 APPENDICE C. INSTALLAZIONE NAGVIS
Figura C.1: WUI di NagVis
Il Config Tool non visualizza lo stato corrente degli oggetti Nagios, `esolo per la configurazione! Per ”utilizzare” le mappe che hai configurato vai a vedere lo STEP 8! Se questo nel vostro caso non funziona o se non si desidera utilizzare WUI, si pu`osemplicemente modificare il file di configurazione della mappa nella di- rectory etc/maps/ con il proprio editor di testo preferito. Per i formati ed i valori validi dare un’occhiata alla sezione del manuale Map Config Format Description.
STEP 8: Vedere le mappe Sar`aora possibile visualizzare nel browser le mappe definite, secondo la seguente struttura dell’indirizzo: http://
86 Glossario
Addon Vedi Plugin.
API Acronimo di Application Program Interface. Insieme di funzioni software ad alto livello che attivano a loro volta software di basso livello il quale gestisce l’hardware
CGI Acronimo di Common Gateway Interface, `euna tecnologia standard usata dai web server per interfacciarsi con applicazioni esterne. E` la prima forma di elaborazione lato server implementata.
Frontend Il front end, nella sua accezione pi`ugenerale, `eresponsabile per l’acqui- sizione dei dati di ingresso e per la loro elaborazione con modalit`aconformi a specifiche predefinite e invarianti, tali da renderli utilizzabili dal back end. Il collegamento del front end al back end `eun caso particolare di interfaccia.
Perl Linguaggio di programmazione ad alto livello, dinamico, procedurale e in- terpretato noto come linguaggio per lo sviluppo di CGI.
PHP Acronimo ricorsivo di PHP: Hypertext Preprocessor, `eun linguaggio di script- ing interpretato. Utilizzato principalmente per sviluppare applicazioni web lato server, per scrivere script a riga di comando o applicazioni standalone con interfaccia grafica.
Plugin In campo informatico, `eun programma non autonomo che interagisce con un altro programma per ampliarne le funzioni.
87 Glossario Glossario
SNMP Acronimo di Simple Network Management Protocol, protocollo Internet che opera al livello 7 del modello OSI, consente la gestione e la supervisione di apparati collegati in una rete, rispetto a tutti quegli aspetti che richiedono azioni di tipo amministrativo.
Wizard Procedura generalmente inglobata in una applicazione pi`ucomplessa, che permette all’utente di eseguire determinate operazioni (solitamente comp- lesse) tramite una serie di passi successivi.
88 Bibliografia
[1] Ethan Galstad, Nagios version 3.x Documentation, October 2010, disponibile all’indirizzo http://library.nagios.com/library/products/nagioscore/ manuals/.
[2] NagVis version 1.5 documentation, June 2010, disponibile all’indirizzo http: //docs.nagvis.org/1.5/en_US/index.html.
[3] Mathias Kettner, MKLivestatus version 1.1 documentation, Febru- ary 2010, disponibile all’indirizzo http://mathias-kettner.de/checkmk_ livestatus.html.
[4] Documentazione framework Itil v2, 2001 disponibile all’indirizzo http://www. itil-italia.co.
89