Facoltà di Scienze Matematiche Fisiche e Naturali. Corso di Laurea in Informatica

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Facoltà di Scienze Matematiche Fisiche e Naturali. Corso di Laurea in Informatica"

Transcript

1 Università degli Studi di Napoli Federico II Facoltà di Scienze Matematiche Fisiche e Naturali Corso di Laurea in Informatica Tesi Sperimentale di Laurea Triennale Il monitoraggio di un DataCenter: Implementazione di funzioni per le risorse locali di nodi remoti Relatori Candidato Prof. G. Russo Dr. D. Del Prete Esposito Paolo Matr. 566/2008 Anno accademico 2009/2010

2 I Indice generale Introduzione Enterprise Information Portal: Liferay Caratteristiche Organizzazione Delle Portlet Permessi E Sicurezza Panoramica sull'applicazione NAGIOS Caratteristiche E Requisiti Installazione Automatica Installazione Manuale Configurazione Di NAGIOS Configurazione Di Apache Interfaccia Web L'addon NRPE Nagios Remote Plugin Executor Tipologia Dei Nodi Della Rete Installazione E Configurazione Del NRPE Risoluzione Dei Problemi Configurazione dei plugin Contenuto Del File Nrpe.cfg Descrizione Dei Plugin Script Utilizzati Per Gli Host Il Protocollo SNMP Script Per UPS, Switch E CMC Considerazioni Scheduler E Resource Manager Problematiche Aggiunta dei servizi con Centreon Host E Host Group Aggiungere Un Comando Creare Un Servizio Centreon Come Tool Di Monitoraggio Creazione delle mappe con Nagvis Inserire Una Mappa Editor Di Mappe Url E Web Management Conclusioni Appendice File Di Configurazione Delle Mappe Mappe Bibliografia...158

3 Introduzione Con l'aumento della complessità delle reti e l'accrescere del numero di macchine e apparati collegati, diventa sempre più complicato monitorare il corretto funzionamento degli stessi. Quello di cui ha bisogno un amministratore di sistema per svolgere, in maniera ottimale, il proprio lavoro è il controllo di tutte le risorse che deve gestire. Dato il gran numero di macchine presenti sulla rete, controllare ogni singolo apparato collegandosi volta per volta ed eseguendo determinati script, è un metodo lento e poco funzionale. Spesso, poi, si tratta di macchine adibite a compiti diversi che necessitano il monitoraggio di parametri e funzionalità differenti. Non si può prescindere quindi da un sistema di monitoraggio centralizzato che sia in grado di controllare, in modo rapido ed efficiente, lo stato della rete e rilevare eventuali problematiche. Un sistema di monitoraggio ha il compito di controllare continuamente, ed ad intervalli prestabiliti, le risorse degli host ed apparati attivi che compongono la rete. Questo tramite una interfaccia messa a disposizione dell'amministratore. L'amministratore di rete, in questo modo, può individuare tempestivamente un problema e provvedere alla sua risoluzione. Questo lavoro di tesi è svolto sulla rete di calcolo del Tier2-Napoli, sulla quale è già presente un sistema di monitoraggio funzionante basato sul software open source NAGIOS. La funzione principale di NAGIOS è quella di controllare nodi, reti e servizi specificati, avvertendo quando questi non garantiscono il loro servizio, quando vengono spenti e quando ritornano attivi. NAGIOS è stato installato tramite il FAN (Fully Automated NAGIOS), che include Pagina 1 di 148

4 diversi tool per la configurazione tra i quali, sono stati utilizzati, Centreon e Nagvis. È stato inserito all'interno di una portlet del portale web di Tier2. Il portale è Liferay, un EIP (Enterprise Informazion Portal) opern source basato sul linguaggio java. L'obiettivo di questo lavoro di tesi è organizzare logicamente tutti gli host ed apparati della rete di calcolo di Tier 2 ATLAS, classificandoli per tipologia, e definire per ognuno di questi i servizi da monitorare visualizzandoli graficamente tramite una mappa navigabile. Il mio lavoro di tesi si è sviluppato nelle seguenti fasi: Installazione e configurazione dell'addon NRPE su 80 macchine. L'addon NRPE è progettato per permettere l'esecuzione di NAGIOS su macchine remote linux. Il principale motivo è quello di permettere a NAGIOS di monitorare risorse locali come, per esempio, il caricamento della CPU o l'utilizzo di memoria. Inserimento degli host e configurazione di 19 servizi nel tool Centreon. Centreon è usato come interfaccia grafica di NAGIOS e permette di inserire host, classificarli in host group e definire dei servizi su essi. Si possono testare i servizi su determinati host ed, una volta completata la configurazione, esportare il file di configurazione per NAGIOS. Inserimento ed editing delle 12 mappe delle infrastrutture di rete con l'addon Nagvis. Nagvis è usato per visualizzare i dati di NAGIOS. Permette di caricare mappe in formato png e inserire su queste oggetti come le icone per gli host che visualizzeranno informazioni riguardanti gli host e lo stato dei servizi attivi. Organizzare le mappe in modo da favorire la navigabilità e individuare agevolmente le anomalie. È possibile in questo modo partire da una panoramica generale della rete, visualizzare gli apparati classificati per tipologia, ed entrare nel dettaglio visualizzando i servizi di un singolo host ed accedere alla sua web management. Pagina 2 di 148

5 Queste fasi hanno portato alla realizzazione di un sistema di monitoraggio centralizzato, all'interno di un portale Liferay, in grado di monitorare le risorse locali di host remoti. Il sistema è utilizzabile tramite una interfaccia grafica accessibile da un qualunque Web Browser e il suo funzionamento è stato testato per tutta la durata del tirocinio risolvendo, di volta in volta, le problematiche che si sono presentate. 1. Enterprise Information Portal: Liferay Liferay è un Enterprise Portal Server Open Source basato sul linguaggio java che utilizza le ultime tecnologie del Web 2.0. I portal server nascono in un ambiente aziendale, per venire incontro alla necessità di aggregare i servizi offerti da Legacy System aziendali. Il portale svolge la funzione di Web Container. Una pagina può essere considerata una aggregazione di moduli web, chiamati portlet, destinati a contenere applicazioni. La scelta è ricaduta su Liferay in quanto offre una grande quantità di servizi integrati di qualità ed un'ottima flessibilità. Tutto questo si va ad aggiungere ad una grande capacità di organizzare e supportare la collaborazione. Liferay infatti è un portale open source che offre un sistema potente ed integrato di funzioni di collaborazione tra le quali: Wiki: Ogni gruppo può condividere una propria Wiki con propri e differenziati insiemi di autorizzazioni. Ogni utente con i diritti necessari può contribuire alla crescita del repository di conoscenza condiviso. I contenuti vengono inseriti semplicemente con un editor WISWYG, le pagine possono essere raggruppate in gerarchie con tag di sistemi a vocabolario multipo (taxonomy e/o folksonomy). Bacheca elettronica: Un sistema di message boeard che permette di condividere idee e annunci all'interno di una organizzazione o una community. Mette a disposizione report sull'attività svolta nella bacheca, riportando i post recenti e Pagina 3 di 148

6 gli utenti attivi. Ogni thread è visibile via feed RSS, ogni post può inviare una mail di avviso che permetti di rispondere al post del client di posta. Come per tutte le altre portlet, anche quella della bacheca è sottoposta al sistema di gestione degli accessi e autorizzazioni che garantisce i controllo utilizzando i ruoli. RSS: Permette di condividere tutte le tipologie di contenuto tramite feeding RSS Blog: Un sistema ricco di funzionalità reso più efficace dalla natura sociale del portale nel suo complesso. Tra le funzionalità più importanti l'editor WYSWYG, social bookmarking, notifiche per i contributi e i commenti, sistemi di rating dei contributi, subscription via RSS, scheduling delle pubblicazioni Tracking delle attività: tiene traccia delle attività più recenti effettuate sul portale. Instant messaging: Comprende delle funzioni di instant messaging. Tramite la lista degli amici vengono automaticamente visualizzati i nomi degli amici collegati. L'accesso al servizio è inserito in una barra in fondo alla videata e segue l'utente lungo la navigazione all'interno del portale rimandendo sempre disponibile. Calendari: È possibile impostare e utilizzare calendari di gruppo basati sulle community. Gli eventi possono essere condivisi e gli alert possono essere settati per un avviso via o instant messaging. Avvisi: È possibile inviare messaggi di tipo broadcast a gruppi di utenti, ogni utente può impostare le modalità di ricezione degli avvisi. Sondaggi: Sono disponibili delle portlet per l'impostazione, la presentazione e la raccolta dati di sondaggi. Possono essere configurati e pubblicati più sondaggi in contemporanea con visibilità differenziate rispetto ai gruppi. Pagina 4 di 148

7 figura 1 : Schermata di prova con alcune portlet Liferay è conforme alle specifiche SOA (Service Oriented Architecture) per una robusta integrazione applicativa. Integra OpenSSO (Single Sign On) e può cooperare con standard quali Shibbolet, Liberty Alliance, Open ID, CAS. Qualunque applicazione sviluppata su Liferay beneficia di tutte le possibilità tipiche di un Portal Server Enterprise: Multi-Tier, Limitess Clustering, High Avaibility, Page Caching, ect. Supporta standard molto importanti e diffusi: Portlet Specification and API 1.0 (JSR-168) JSR-252 (Java Server Faces) 1.2 JMX (Java Management Extension) 1.2 WSRP (Web Services for Remote Portlets) 1.0 Full J2EE 1.4 compliance quando usato con JBoss AS Pagina 5 di 148

8 Alcune delle sue caratteristiche che lo contraddistinguono sono: Elevata dinamicità che permette di creare, rimuovere e modificare portlet, temi, layout, finestre e impostazioni di sicurezza a runtime. IPC (Interportlet Comunication) notevolmente irrobustita attraverso un'organizzazione gerarchica delle portlet Caratteristiche Liferay si può definire come un Portlet Engine. Viene distribuito anche come EAR (Enterprise Archive) all'interno della Application Server JBoss. JBoss implementa l'intera suite di servizi che si basano sulla Java Enterprise Edition. Sono legati a JBoss tanti altri progetti open source che vengono racchiusi tutti sotto il marchio della JBoss Enterprise Middleware Suite (JEMS) In questo modo Liferay si può avvalere di tutti i vantaggi apportati dalla suite JEMS: Disponibilità del servizio Object-Relational Mapping (ORM) fornito dalla piattaforma per lo sviluppo di applicazioni Hibernate. Utilizzo del Java Authentication and Authorization Service (JAAS) per la gestione degli accessi alle risorse. Caching per ridurre l'uso della banda e il tempo di accesso al sito. Architettura cluster realizzando il sistema su un insieme di macchine nascondendo la struttura alla vista del client. Hot deployment delle portlet in modo da aggiungere applicazione war senza far ripartire il server. Single Sign On (SSO) e Lightweight Directory Access Protocol (LDAP) per ottenere un'unica autenticazione e accedere alle risorse a lui consentite. Business Process Management & Business Rules per ottimizzare, gestire e monitorare i processi aziendali. Gestire le transazioni distribuite su più server adibiti alla gestione delle risorse, tramite un gestore delle transazioni. Pagina 6 di 148

9 Utilizzo dell' Enterprise Messaging System (EMS) per permettere alle organizzazioni di inviare messaggi tra i vari sistemi. Di seguito una panoramica generale delle varie caratteristiche: Out-of-the-box tools: Grazie ad una community molto estesa, Liferay Portal Server fornisce un grandissimo numero di portlet già integrate. SOA Framework: Liferay Portal Server è stato sviluppato utilizzando l'architettura orientata ai servizi SOA Service Oriented Architecture che lo rende la scelta ottimale per soluzioni Enterprise Application Integration in tecnologia Web 2.0 tramite Web Services. Dynamic drag & drop: Liferay Portal Server offre la funzionalità di drag & drop delle portlet. Gli utenti possono spostare gli elementi nel portale semplicemente trascinando e rilasciando il mouse. Secure Single Sign On (SSO): Per accedere ai contenuti e alle applicazioni da un punto unico di accesso. Liferay Portal Server può aggregare diversi sistemi applicativi e renderli disponibili accedendo una volta sola con il massimo della riservatezza tramite il Single Sign On. Granular, Role-Based Authorizations: Per garantire che le persone accedano con diritto alle sole informazioni per le quali sono autorizzate. Gli amministratori del portale possono assegnare ai singoli utenti o gruppi di utenti diversi "ruoli" per attribuire loro differenti livelli di accesso e differenti diritti di modifica. Ad esempio, un "direttore vendite" può visualizzare e modificare tutti i documenti di vendita, ma un "Assistente di vendita" può solo visualizzarli. Personal User Pages : Tutti gli utenti abilitati potranno avere un spazio personale dove immettere proprie informazioni. Potranno decidere se renderle pubbliche o tenerle private. È possibile personalizzare lo spazio messo a disposizione tramite il drag & drop delle portlet. Gestione contenuti: Il CMS integrato all'interno di Liferay Portal Server fornisce un insieme esteso di funzionalità fortemente integrate con le funzioni Pagina 7 di 148

10 di collaborazione e fornisce un repository centralizzato per conservare e gestire contenuti da visualizzare sul web. Ciascuna community e ciascuna organization hanno a disposizione una propria separata document library e image gallery. Il CMS è implementato tramite Liferay Journal, un contenuto instrinseco (builtin) del portale Liferay che abilita una serie di funzionalità di gestione contenuti: Web Publishing: E' un sistema che può essere usato per creare pagine web in modo veloce usando dei contenuti riusabili, dei modelli (Template) per il layout flessibili. Flexibile Template Mechanism (XSL/VM): I modelli creati per gli Articoli possono essere fatti in XSL o Velocity (VM) dando cosi agli sviluppatori la flessibilità di disegnare le pagine web. Document Library: Provvede un deposito centralizzato per i servizi della Library, fatto con JCR-170 Java Content Repository (Jackrabbit) per trattare diversi documenti (PDF, DOC...) che possono essere salvati sotto una unica URL (vedi DocManagement). Image Gallery: Provvede un deposito centralizzato per immagini. Portal Publishing & Staging: Publishing permette di modificare pagine web in tempo reale però senza pubblicare subito il cambiamento, solo quando si decide di farlo. Invece Staging per creare varie copie di modifica della stessa pagina e testarle senza toccare le pagine correnti sul Portale 1.2. Organizzazione delle Portlet Liferay mette a disposizione tre tipologie di Portlet di amministrazione: Enterprise, Organization e Location.. La Portlet di tipo Enterprise ha il livello più alto di funzioni amministrative ed ha accesso alle altre due Portlet amministrative e a quelle degli utenti. La Portlet Organization può accedere, oltre che alle proprie informazioni, anche a tutte quelle delle Location e degli utenti che appartengono ad essa. Pagina 8 di 148

11 La Portlet Location, di conseguenza, accede alle proprie informazioni e a quelle dei propri utenti. Organization e Location rappresentano una gerarchia societaria. Organization rappresenta la corporazione padre e può avere un qualunque numero di Location che rappresentano invece le corporazioni figlie. Un utente può appartenere solo ad una singola Organization e Location. Gli utenti invece (Users) sono agglomerati in gruppi e assegnati, dagli amministratori, in base ai permessi e ruoli. Un utente può appartenere ad un qualunque numero di gruppi. figura 2 : Vista della schermata Location Come si vede dalla figura 1, le varie tipologie sono organizzate in tab. Per ognuna di esse è possibile cercare oppure aggiungere. Cercare per esempio tutte le Location che appartengono ad una determinata Organization, oppure aggiungere una Location inserendo le informazioni necessarie. Pagina 9 di 148

12 1.3. Permessi e sicurezza Liferay ha un modello di sicurezza che include un sistema di permessi granulare che da agli amministratori il pieno controllo sugli accessi e privilegi sulle Portlet ed oggetti all'interno del portale. Per comprendere questo modello di sicurezza è necessario prima capire tutte le entità che lo compongono. Risorsa è un termine generico per qualunque oggetto rappresentato in un portale. Risorse sono, per esempio, Portlet, classi Java e File. Le risorse possono avere una delle tre seguenti competenze: Enterprise, Community e Individual. Enterprise racchiude tutti gli oggetti all'interno del portale. I permessi possono essere definiti come azioni da compiere su una risorsa. Con i permessi di visualizzazione, per esempio, un utente può leggere qualunque topic. Se i permessi sono assegnati ad una Community, Organization o Location, allora tutti gli utenti che sono membri di questa entità riceveranno questi permessi. Un ruolo è una collezione di permessi. Non ha nessuna altra utilità o scopo se non quello di contenere i permessi a lui assegnati. Un ruolo può essere assegnato anche ad una delle entità sopra descritte. In questo modo, tutti gli utenti che fanno parte di quei gruppi, riceveranno i permessi di quel ruolo. Un utente, in generale, è una persona che esegue operazioni sul portale. A seconda di Pagina 10 di 148

13 quali saranno i privilegi e i ruoli a lui assegnati, avrà o non avrà i permessi per eseguire determinate operazioni. Prima di effettuare il login sul portale, l'utente è considerato un ospite (Guest) e in quanto tale avrà il proprio set di permessi di default per gli oggetti del portale. Solamente una volta autenticato sarà riconosciuto come un utente registrato. Un utente registrato quindi, riassumendo quanto detto sopra, può ricevere i permessi nel seguente modi: Permessi direttamente assegnati all'utente Permessi assegnati alla Community di appartenenza dell'utente Permessi assegnati alla Organization alla quale l'utente appartiene Permessi assegnati alla Location dell'utente Permessi appartenenti al ruolo assegnato all'utente Permessi di appartenenza al ruolo della Community dell'utente Permessi di appartenenza al ruolo della Organization dell'utente Permessi di appartenenza al ruolo della Location dell'utente Pagina 11 di 148

14 figura 3 : Schermata dei ruoli con le azioni associate 2. Panoramica sull'applicazione NAGIOS NAGIOS è una applicazione open source per il monitoraggio delle reti locali. Un sistema di monitoraggio si occupa di controllare risorse delle macchine (carico della CPU, memoria utilizzata, numero di processi attivi, ect.), e la disponibilità dei servizi che i server offrono. NAGIOS è l'acronimo di Notice Any Glitches In Our System, cioè notifica qualsiasi malfunzionamento nel nostro sistema. Tra le varie funzionalità infatti c'è anche la possibilità di abilitare le notifiche che ci saranno inviate, tramite o sms, nel caso si presenti un problema. Sul mercato sono presenti altre soluzioni per il controllo dei sistemi. La HP (Hewlett Packard) per esempio, distribuisce OpenView. OpenView è un programma modulare che, grazie alla sua modularità, permette di caricare solo il modulo relativo a quello che si vuole controllare, senza quindi appesantire troppo il sistema. Pagina 12 di 148

15 Un'altra alternativa è il Tivoli-netview della IBM che ha funzionalità dello stesso livello di OpenView. Entrambi però hanno un costo molto alto e presentano alcuni lati negativo. Openview per esempio non dispone di una interfaccia web e può visionare lo stato dei sistemi solo dal pc sul quale è installato. Nonostante siano programmi più che buoni, considerando anche il costo, si preferisce l'alternativa open source Caratteristiche e requisiti NAGIOS è un demone, un programma sempre attivo eseguito in background e residente in memoria. Nei file di configurazione sono specificate le modalità di controllo e, in caso di malfunzionamenti, invia le notifiche a tutti gli utenti interessati. NAGIOS si serve dei plugin per effettuare le interrogazioni ai servizi. Questi plugin altro non sono che programmi i quali, una volta lanciati, interrogano i servizi e restituiscono uno status e un output. L'interfaccia web mette a disposizione una elevata quantità di dettagli mostrando lo stato di tutti i servizi e tutto quello che è stato deciso debba essere controllato. I requisiti necessari per la compilazione e il funzionamento di NAGIOS sono: Un compilatore C utilizzato per la compilazione del programma e di tutti i plugin relativi. Una macchina che funga da web server che venga configurata affinché Pagina 13 di 148

16 visualizzi l'interfaccia web. Deve supportare la tecnologia standard CGI usata per interfacciarsi con applicazioni esterne. La Graphics Library GD necessaria per generare, nell'interfaccia web, grafici e disegni. In ogni caso, al momento della configurazione di NAGIOS, qualunque requisito manchi viene segnalato Installazione automatica L'installazione di NAGIOS può essere fatta in due modi: Automatica e Manuale. Ho eseguito entrambe le installazioni, la prima per il sistema definitivo sul server e la seconda inizialmente come sistema di prova su una macchina locale. Il primo modo, che è anche quello più semplice per chi voglia installare rapidamente un sistema di monitoraggio completo di tool di configurazione, consiste nell'installazione tramite FAN (Fully Automated NAGIOS). Questa installazione è completamente automatica e si può completare in pochi semplici passi. Per prima cosa recarsi all'indirizzo: Pagina 14 di 148

17 Da questa pagina è possibile scaricare la iso dell'ultima versione di FAN, attualmente la FAN 2.0. La iso successivamente deve essere masterizzata su un cd. L'installazione dal cd è guidata e necessita di risposte ad alcune domande. Completata la procedura di installazione, si può accedere all'interfaccia di FAN tramite un browser web, inserendo l'indirizzo IP della macchina. Nel nostro caso, si può accedere alla pagina visualizzata nella figura 4, dall'indirizzo: Da questa interfaccia sono raggiungibili i vari tool di configurazione, come si può osservare appunto dalla figura. figura 4 : Schermata principale di FAN Pagina 15 di 148

18 2.3. Installazione manuale L'altro modo per installare NAGIOS è la procedura manuale. A questo proposito è necessario scaricare, dal sito ufficiale i file sorgenti. I file che ci interessano sono il Nagios Core e il Nagios Plugins. L'ultima versione di questi file è rispettivamente: nagios tar.gz e nagios-plugins tar.gz. Prima di iniziare l'installazione è necessario creare un nuovo utente il quale avvierà il demone. Quello di default è nagios, ma è possibile cambiarlo in fase di compilazione: # adduser nagios Una volta scaricati i file, estrarre il primo: # tar -xzvf nagios tar.gz Supponiamo che il file sia stato estratto nella directory /usr/local, in questa viene creata una directory, di nome nagios-3.2.3, nella quale è contenuto il programma. Entrando in questa directory si può iniziare l'installazione. Il primo comando da lanciare è./configure. Questo comando è seguito da una serie di parametri. Non specificando alcun parametro vengono utilizzati quelli di default. Nell'esempio seguente vengono specificati proprio i parametri di default, unicamente per far capire come personalizzare ulteriormente la propria installazione: #./configure --prefix=/usr/local/nagios --with-cgiurl=/nagios/cgi-bin --with Pagina 16 di 148

19 htmurl=/nagios/ --with- nagios-user=nagios with-nagios-grp=nagios Questa configurazione potrebbe non andare a buon fine nel caso mancassero determinati pacchetti necessari all'installazione. In tal caso un messaggio di errore indica quali pacchetti mancano, quindi installare questi pacchetti ed eseguire nuovamente il comando. Completata la configurazione dell'installazione, si può procedere con la compilazione, seguita dall'installazione del programma: # make all # make install Si procede poi con l'installazione dello script init, necessario per avviare automaticamente il programma durante il boot del sistema e controllarne il corretto funzionamento. In pratica controlla le operazioni di start, stop, restart e reload del servizio. # make install-init Per completare l'installazione, installare i file di esempio utili per orientarsi durante la prima configurazione: # make install-config Installiamo ora i plugin scaricati con l'altro file. # tar -xzvf nagios-plugins tar.gz Pagina 17 di 148

20 Spostarsi nella cartella creata e far partire la configurazione dell'installazione. #./configure --prefix=/usr/local/nagios --with-nagios-user=nagios --with-nagiosgroup=nagios # make all # make install A questo punto l'installazione può dirsi terminata e la directory /user/local/nagios/ ha il seguente contenuto: bin etc libexec sbin share var Di seguito una breve descrizione del contenuto di queste cartelle: bin: contiene il file eseguibile nagios etc: i file di esempio e i file effettivi di configurazione libexec: i file eseguibili dei plugin sbin: gli script CGI per l'interfacia web share: le pagine web statiche e la documentazione var: le informazioni di esecuzione di nagios Ultimata l'installazione non resta che la configurazione 2.4. Configurazione di NAGIOS La configurazione di NAGIOS è un processo molto importante in quanto permette di personalizzarlo tenendo conto di tutte le necessità. Pagina 18 di 148

21 Proprio per questo motivo la configurazione non è un processo standard, ma varia a seconda di quello che si vuole monitorare. L'esempio seguente prende in considerazione il monitoraggio dello stato di una sola risorsa, la macchina local_pc. Per tutti i file di configurazione si può ovviamente prendere spunto dai file di esempio precedentemente installati. Prendere quindi il file hosts.cfg-sample e crearne uno uguale di nome hosts.cfg. In questo file vengono specificate le informazioni di tutti gli host che devono essere monitorati. Il contenuto del file è il seguente: figura 5 : Contenuto del file hosts.cfg La definizione è abbastanza intuitiva in quanto ogni parametro è auto-esplicativo. Il parametro più importante è address, cioè l'indirizzo della macchina. Può essere sia un indirizzo locale che un indirizzo esterno. Pagina 19 di 148

22 Il file hostgroups.cfg definisce invece i gruppi di host e il gruppo di contatto che sarà allertato in caso di malfunzionamento. figura 6 : Contenuto del file hostgroups.cfg I contatti di riferimento invece sono organizzati in gruppi nel file contactgroups.cfg, come è visibile in figura 7. figura 7 : Contenuto del file contactgroups.cfg I dettagli relativi ai contatti invece sono definiti nel file contact.cfg Pagina 20 di 148

23 figura 8 : Contenuto del file contact.cfg L'ultimo file di configurazione rimasto è quello relativo ai servizi service.cfg. Anche in questo caso è presente un template definito come generic-service che va obbligatoriamente incluso in testa al file. Sotto a questa definizione vengono inserite le dichiarazioni dei servizi che si vogliono monitorare. Nella figura 9 si può vedere la definizione del servizio ping. Osservando la dichiarazione del servizio si può capire come possa può capire come possa essere regolato qualsiasi dettaglio, come il periodo di tempo (la cui definizione è indicata nel file time.periods.cfg) di ventiquattro ore per sette giorni a settimana, il numero massimo di tentativi prima di inviare la segnalazione di malfunzionamento, dove inviare la notifica, ect. Il parametro che indica il comando che viene eseguito per effettuare il controllo è check_command, dove viene specificato il nome del plugin da utilizzare. Nella figura 9 si può vedere anche come passare dei parametri al plugin, utilizzando il punto esclamativo. Pagina 21 di 148

24 figura 9 : Contenuto del file service.cfg Come inserire nuovi plugin è spiegato nei capitoli successivi dove si parlerà dell'addon NRPE e dei suoi plugin. Il file dove sono indicate le opzioni per la gestione dei CGI, per l'utilizzo dell'interfaccia web, è cgi.cfg. I CGI sono una serie di programmi che NAGIOS utilizza per visualizzare nelle pagine web le più svariate informazioni. Questi si trovano nella sottodirectory sbin. In questo file vengono abilitate le linee relative ai permessi d'accesso. Può essere utile definire, per esempio, l'utente che potrà accedere alla consultazione di tutte le informazioni di NAGIOS, tramite browser. In questo caso si deve specificare l'utente alla riga: authorized_for_system_information = Pagina 22 di 148

25 Tra i file rimanenti dependencies.cfg che contiene le dipendenze dei servizi al suo interno. Si deve indicare, per esempio, che il sito non può funzionare senza l'esecuzione del web server. Un altro file è escalations.cfg nel quale vengono definite il numero totale di volte in cui una notifica deve essere segnalata. Altri file di configurazione verranno spiegati più avanti, quando si parlerà di NRPE. Per ultimare la fase di installazione bisogna configurare il Server Web 2.5. Configurazione di Apache Prima di avviare il programma è necessario predisporre il nostro Server Web Apache, per il funzionamento di NAGIOS. Quindi nel file httpd.cfg devono essere aggiunge le righe mostrate in figura 10: Pagina 23 di 148

26 figura 10 : Contenuto del file httpd.cfg In questo modo vengono dichiarate e protette le directory di NAGIOS. Il discorso autenticazione si completa con la creazione del file.htaccess nella cartella cgi, con il contenuti mostrato in figura 11: figura 11 : Contenuto del file.htaccess Così facendo, la consultazione dei dati relativi allo stato dei servizi, è protetta. Accedendo quindi alla pagina di Nagios, viene richiesta l'autenticazione con il nome utente e password. Pagina 24 di 148

27 Con il comando htpasswd si crea il file htpasswd.users che indica ad apache dove sono inclusi i dati di accesso. Il comando è il seguente: # htpasswd -c /usr/local/nagios/etc/ htpasswd.users local_user_1 Il file così viene creato e viene chiesto di inserire la password per l'utente specificato. L'opzione -c serve per creare il file, quindi nel caso si vogliano aggiungere altri utenti si potrà anche omettere. La fase di configurazione è completata. Per avviare il demone di NAGIOS si deve andare nella cartella /etc/xinetd/ e lanciare il seguente comando: # nagios start La maggior parte delle operazioni descritte sopra sono automatizzate utilizzando FAN. Come verrà spiegato più avanti, nel capitolo riguardante Centreon, tutta la fase di aggiunta di host, host group e servizi, così come fermare, avviare, riavviare e ricaricare NAGIOS, può essere gestita tramite l'interfaccia di Centreon Interfaccia Web In questo capitolo viene descritta l'interfaccia di NAGIOS e vengono spiegate tutte le sue funzionalità accessibili dal suo menù. Nella figura seguente si può vedere l'interfaccia di Nagios, in particolare il suo menù, Pagina 25 di 148

28 alla quale si accede dall'indirizzo figura 12 : Menu di Nagios Nella seguente lista invece vengono elencate e descritte le varie voci del menù con le rispettive funzionalità: Tactical Overview Per monitorare tutte le attività di monitoraggio della rete. Permette di vedere rapidamente le interruzioni della rete, lo stato degli host e dei servizi distinguendo tra i problemi che sono stati gestiti in qualche modo e quelli invece che non sono stati gestiti e richiedono un intervento. Nagvis Overview Collegamento a Nagvis NaReTo Overview Pagina 26 di 148

29 Collegamento a NaReTo Service Detail Visualizza una lista dove sono mostrati tutti i servizi e i relativi dettagli sul loro stato. Host Detail Visualizza una lista dove sono mostrati tutti gli host e i relativi dettagli sul loro stato. Hostname È un form di ricerca che permette di ricercare un determinato host. La ricerca mostra tutti i servizi sul host cercato. Host Group Visualizza un sommario di tutti gli host group con il sommario sullo stato dei relativi host e servizi. Service Group Status Map Per visualizzare una mappa creata automaticamente di tutti gli host che sono stati definiti sulla rete. Service Problems Per visualizzare una lista di tutti i problemi relativi ai servizi, per ogni host. È possibile visualizzare tutti i problemi oppure solo quelli non gestiti e risolti. Host Problems Per visualizzare una lista di tutti gli host che hanno problemi. Così come i Service Problem, anche qui si possono visualizzare tutti gli host che hanno problemi oppure solo quelli che hanno problemi che non sono stati risolti. Comments Permette di inserire, quindi anche di visualizzare, commenti relativi ad un determinato host o servizio. Downtime Pagina 27 di 148

30 Visualizza, nel caso ce ne siano, gli host o i servizi che attendono di essere schedulati. Trends Per visualizzare un grafico, creato automaticamente, sullo stato di host e servizi su un prefissato periodo di tempo. Availability Per visualizzare la disponibilità di determinati host e servizi in un determinato periodo di tempo, il tutto tramite parametri specificati dall'utente. Alerts Per visualizzare la cronologia dei problemi, per uno specifico host oppure per tutti gli host. Si può anche filtrare le informazioni visualizzando solamente un determinato tipo di problema. Notifications Per visualizzare le notifiche degli host e dei servizi che sono state mandate ai contatti designati. Così come per la cronologia dei problemi, anche qui si può filtrare le informazioni visualizzando solamente un determinato tipo di notifica. Event Log Mosta semplicemente il log file. Performance Visualizza statistiche relative agli host e servizi controllati in determinati intervalli di tempo. View Config Visualizza qualsiasi file di configurazione scelto dall'utente. 3. L'addon NRPE I servizi standard di una macchina possono essere controllati da remoto tramite Pagina 28 di 148

31 l'interrogazione delle porte TCP. Allo stesso modo però non possono essere controllate le risorse locali quali caricamento cpu, uso memoria, capienza del disco, processi in esecuzione o numero di utenti collegati. NRPE è stato progettato proprio per risolvere questo problema e permettere l'esecuzione di NAGIOS su macchine remote linux. E' possibile eseguire il NAGIOS plugin, su macchine remote linux, attraverso SSH. C'è infatti un plugin chiamato check_by_ssh che permette di fare tutto questo. Usare SSH è più sicuro che usare l'addon NRPE ma comporta un maggiore overhead sia sulla macchina di monitoraggio che su quella remota. Questo può diventare un problema quando si inizia a monitorare centinaia o migliaia di macchine. Proprio per questo motivo molti preferiscono utilizzare l'addon NRPE 3.1. Nagios Remote Plugin Executor L'addon di NRPE consiste di 2 componenti: Il plugin check_nrpe, sulla macchina adibita al monitoraggio. Dove quindi è presente NAGIOS. Il demone nrpe che gira sulla macchina remota linux, dove si vuole effettuare il controllo. Quando NAGIOS ha bisogno di monitorare una risorsa su una macchina remota, la logica di funzionamento è la seguente: NAGIOS esegue il plugin check_nrpe e gli comunica che servizio ha bisogno di essere controllato passando come parametro il nome del plugin remoto che si vuole lanciare e il nome della macchina remota. il plugin check_nrpe contatta il demone NRPE, in ascolto su una determinata Pagina 29 di 148

32 porta (di solito la porta 5666), sul host remoto in questione, eventualmente con una connessione protetta SSL. Il demone NRPE esegue il plugin locale appropriato per controllare il servizio o la risorsa. Il risultato dal controllo del servizio è restituito dal demone NRPE al plugin check_nrpe che lo ritorna al processo NAGIOS. figura 13 : Schema del collegamento tra il plugin check_nrpe e il demone NRPE Il demone NRPE richiede quindi che il plugin NAGIOS sia installato sulla macchina remota. Senza il demone non è in grado di monitorare niente. L'uso più diffuso dell'addon NRPE è monitorare risorse locali o private su una macchina remota linux come caricamento cpu, memoria usata, swap usata, utenti correnti, dischi usati, stato dei processi, ect. figura 14 : Utilizzo diretto del NRPE Si può anche usare NRPE per controllare indirettamente servizi pubblici e risorse di un Pagina 30 di 148

33 server remoto che non possono essere raggiungibili direttamente dal host di monitoraggio. Se un host remoto con il demone NRPE e i plugin può comunicare con un web server remoto, ma la macchina di monitoraggio no, si può configurare il demone NRPE per monitorare il web server remoto indirettamente. figura 15 : Utilizzo indiretto del NRPE Pagina 31 di 148

34 3.2. Tipologia dei Nodi della rete Prima di iniziare a installare NRPE su tutte le macchine è necessario avere una visione completa di come è strutturata la rete, in particolare il data center, e le tipologie di macchine che lo compongono. Il datacenter SCoPE è situato nei pressi del dipartimento di Biologia, non molto lontano dalla Control Room. Tutti quanti gli apparati sono raccolti all'interno dei rack, come è visibile nella seguente figura: figura 16: Rack del centro di calcolo. Diventa fondamentale quindi distinguere il tipo di macchina, quali sono i suoi compiti e quali sue risorse ci interessa monitorare. Più in avanti si avrà una visione globale, attraverso le mappe, di quali e quanti Pagina 32 di 148

35 componenti sono contenuti all'interno di ogni rack. È importante però ora fare una distinzione in base alla tipologia delle macchine. Di seguito un elenco, con una descrizione riguardante l' utilizzo, di tutti gli apparati e macchine presenti: Worker Node: è un nodo che esegue i calcoli elaborando i dati contenuti all'interno degli Storage Element. Tra le varie risorse che può essere utile monitorare c'è la quantità di memoria libera, lo spazio sul disco o il carico della CPU. Storage Element: è un nodo che ha come compito principale la memorizzazione e l'accesso ai dati, che devono essere elaborati dai Worker Node. Le risorse che può essere utile monitorare sono le stesse dei Worker Node. Service Node: è un nodo che ha il compito di smistare i job che devono essere eseguiti sui Worker Node. Fa parte di questa tipologia anche il Computing Element, macchina che deve gestire le code e che quindi deve avere uno scheduler e un gestore delle risorse. In questo caso, oltre alle solite risorse, diventa fondamentale monitorare anche le code. Switch: apparati adibiti alla gestione del traffico. Poiché il trasferimento dei dati è un parametro fondamentale per gli switch può essere utile controllare il traffico oppure da quanto tempo lo switch è up. CMC (Central Management Console ): apparati presenti in tutti i rack che hanno il compito di controllare informazioni quali la temperatura, temperatura dell'acqua o la velocità delle ventole. Questi quindi sono informazioni che vanno monitorate per questa tipologia. UPS (Uninterruptible Power Supply ): sono dei gruppi di continuità che entrano in funzione quando manca la corrente e assicurano una determinata autonomia in questi casi. Oltre al tempo di autonomia può essere utile Pagina 33 di 148

36 monitorare anche la carica. Queste quindi sono le varie tipologie di apparati presenti nel centro di calcolo. È stato descritto brevemente quali sono le risorse locali che può essere utile monitorare. Per ogni risorsa è presente un relativo plugin (script) eseguibile localmente o da remoto. In seguito si vedrà come utilizzare questi plugin, in particolare per il controllo remoto delle risorse Installazione e configurazione del NRPE Nel caso non siano stati installati ancora i plugin, si possono scaricare, conoscendo l'indirizzo del file, direttamente con il comando wget: # wget Per procedere con l'installazione è necessario scaricare l'addon NRPE. Sia il plugin che il demone si trovano in un unico pacchetto. Conoscendo già l'indirizzo del file da scaricare, utilizziamo il comando wget per scaricarlo: # wget Per estrarre i file ed entrare nella cartella: # tar xzf nrpe-2.12.tar.gz # cd nrpe-2.12 Configurare l'addon nrpe con il seguente comando: #./configure La configurazione potrebbe non andare a buon fine ritornando il seguente messaggio Pagina 34 di 148

37 di errore: checking for SSL headers... configure: error: Cannot find ssl headers Questo significa che non sono state trovate le librerie relative al SSL. SSL è l'acronimo di Secure Sockets Layers, letteralmente Livello di Socket Sicuri, ed è un protocollo che permette una comunicazione sicura su reti TCP. Per ovviare a questa mancanza, ci sono due modi per procedere. Il primo modo prevede di installare le librerie in questione e ricompilare: # yum install libssl-dev Il secondo modo prevede invece di continuare la configurazione disabilitando lo SSL. Quindi eseguo di nuovo la configurazione senza SSL e compilo: #./configure disable-ssl # make all Alla fine di questo processo viene visualizzato a video il messaggio visibile nella figura 17: Pagina 35 di 148

38 figura 17 : Messaggio dopo la compilazione Queste sono fondamentalmente le istruzioni per proseguire. La procedura completa verrà però descritta di seguito. Installare alcuni plugin che utilizzerò per il test, il demone e file di esempio per la configurazione demone: # make install-plugin # make install-daemon # make install-daemon-config Installare il demone nrpe come un servizio sotto xinetd # make install-xinetd XINETD sta per extended InterNET services Daemon, e ha preso il posto di INETD per ragioni di sicurezza. INETDT è un demone che resta in ascolto sulle porte specificate nel suo file di configurazione e si occupa di avviare il relativo servizio nel momento in cui viene fatta una richiesta. Viene chiamato super demone per la sua funzione di controllo di altri demoni. I vantaggi nell'usarlo sono evidenti. In questo modo si ottimizzano le risorse del sistema avviando un programma relativo ad un determinato servizio solo quando ci sono effettive richieste. Il file nel quale vengono assegnati i servizi alle relative porte è /etc/services, un file utilizzato anche da altri programmi. Per proseguire nella configurazione quindi è necessario aggiungere anche nrpe tra i suoi servizi. Aprire quindi il file /etc/services e metterlo in ascolto sulla porta 5666 aggiungendo la seguente riga: nrpe 5666/tcp # NRPE Pagina 36 di 148

39 Altro file di configurazione da modificare è il file /etc/xinetd.d/nrpe. Il contenuto del file è mostrato nella figura 18. figura 18 : Contenuto del file /etc/xinetd.d/nrpe Di default questo file è disabilitato, quindi la voce disable è impostata a yes. Per utilizzare però NRPE sotto xinetd è necessario abilitare questo file di configurazione e impostare disable a no. Questa operazione va accompagnata con quella fatta precedentemente aggiungendo la riga nel file /etc/services. Nella figura 18 possiamo notare che alla voce only_from c'è indirizzo IP. In particolare only_from indica gli indirizzi abilitati alla comunicazione con il demone. L'indirizzo IP della figura 18 è quello del server di monitoraggio e quindi dovrà essere impostato proprio come mostrato in figura. Inizialmente però, per fare dei test in locale, mettiamo come indirizzo quello del localhost, quindi : only_from = Riavviare il servizio xinetd per rendere valide le modifiche: Pagina 37 di 148

40 # service xinetd restart Per testare se il demone nrpe è stato installato e configurato con successo, possiamo testarlo quindi prima in locale. Possiamo, a questo scopo, utilizzare alcuni script di prova installati precedentemente. Prima di tutto assicuriamoci che il demone stia girando sotto xinetd. Utilizziamo netstat che ci permette di vedere lo stato delle connessioni sul computer, con le opzioni -at che ci permettono rispettivamente di vedere anche lo stato dei socket non attivi in quel momento e di prendere solo le connessioni tcp: # netstat -at grep nrpe Con il grep prendiamo solo le righe dove compare nrpe. L'output dovrebbe mostrare un nrpe in ascolto. Il risultato di questo comando dovrebbe essere quello nella figura 19 figura 19 : Output del comando netstat -at grep nrpe Il secondo test che facciamo ci assicura che il demone nrpe funziona correttamente. Utiliziamo sempre uno dei plugin installati precedentemente. Spostiamoci nella cartella dove è istallato check_nrpe, che dovrebbe essere /usr/local/nagios/libexec/ (in alternativa cercare in /usr/lib64/nagios/plugins o qualcosa di simile), e lanciamo lo script: #./check_nrpe -H localhost Questo comando dovrebbe restituire la versione installata di nrpe: NRPE v2.12 L'opzione -H serve per specificare il nome del host. Un'altra opzione del comando Pagina 38 di 148

41 check_nrpe è -c che viene utilizzata per l'esecuzione di un plugin e verrà spiegata più in avanti. A questo punto si dovrebbe controllare se il firewall sulla macchina permette l'accesso al demone nrpe ai servizi remoti. Con il comando iptables -L vediamo l'attuale situazione del firewall. Nel caso siano permessi tutti gli accessi, come in figura 20, si può proseguire, altrimenti si deve creare una eccezione. figura 20 : Output del comando iptables -L Questa procedura di configurazione, compresi i passaggi per Xinetd, è stata adottata sui Storage Element, Worker Node e Service Node. La correttezza della procedura è assicurata dai 2 test che vengono eseguiti. Ci sono state alcune complicazioni che hanno portato a delle varianti nella configurazione. La prima complicazione ha riguardato gli Storage Element per i quali alla voce only_from, della figura 18, c'è stato bisogno di specificare un altro indirizzo. L'indirizzo in questione è quello esterno di tier2-nagios.na.infn.it: only_from = L'ultimo file di configurazione rimasto è nrpe.cfg, dove sono definiti i vari comandi per lanciare gli script di prova. Questo file verrà descritto nel prossimo capitolo, riguardante la configurazione dei plugin. Per concludere invece questo capitolo vediamo una panoramica sulle problematiche che si possono presentare. Pagina 39 di 148

42 3.4. Risoluzione dei problemi Di seguito una serie di errori che possono essere ritornati dall'esecuzione del plugin check_nrpe, con il relativo significato. CHECK_NRPE: Socket timeout after 10 seconds" or "Connection refused or timed out": Questo errore può indicare che il comando che è stato chiesto di lanciare al demone NRPE ha preso più di 10 secondi per essere eseguito. Questa è la causa più comune di questo errore. In questo caso si può utilizzare l'opzione -t dalla linea di comando per specificare un tempo più lungo per il plugin check_nrpe. L'esempio seguente incrementa incrementa il tempo portandolo a 30 secondi: # check_nrpe -H localhost -c generic_command -t 30 Un'altra causa di questo problema può essere che il demone NRPE non sia installato o non stia girando sulla macchina remota. Bisogna quindi verificare che il demone stia girando, come un demone indipendente oppure come sotto inetd/xinetd. Si può controllare con i seguenti comandi: # ps axuw grep nrpe # netstat -at grep nrpe L'ultima causa di questo problema può essere il firewall che blocca la comunicazione tra il server di monitoraggio, dove è stato lanciato il plugin check_nrpe, e la macchina remota sulla quale gira il demone NRPE. In questo caso di devono verificare le regole del firewall, come detto già precedentemente utilizzando il comando iptables, e controllare che non ci sia un firewall fisicamente posizionato tra le due macchine. "CHECK_NRPE: Received 0 bytes from daemon. Check the remote server logs for an error message." : La prima cosa che si dovrebbe controllare, come suggerisce il messaggio Pagina 40 di 148

43 dell'errore, è il log del server remoto. Il messaggio del log dovrebbe dare qualche indicazione a riguardo. Controllare la versione del OpenSSL su entrambe le macchine. Se si sta usando una versione commerciale di SSL sul host remoto, ci potrebbero essere problemi di compatibilità. "NRPE: Unable to read output": Questo errore indica che il comando lanciato dal demone NRPE non ha ritornato nessun carattere in output. Questo può significare che la definizione del comando, nel relativo file, è incorretta oppure che il plugin cui fa riferimento il comando è mal funzionante. In questo caso si deve lanciare il plugin direttamente da linea di comando, senza il check_nrpe, per controllarne il funzionamento. CHECK_NRPE: Error - Could not complete SSL handshake Questo errore indica che non si riesce a stabilire la connessione tra le due macchine. Questo problema dipende dalla macchina remota con il demone in ascolto. Può capitare che la macchina funzioni in determinati momenti e in altri momenti no, in particolare quando il carico della CPU tocca soglie elevate. Questa eventualità si verifica lì dove NRPE gira in modalità standalone e non sotto Xinedt. "NRPE: Command 'x' not defined": Questo errore significa che non è stato definito il comando x nel file di configurazione sul host remoto. Corretto il comando, è necessario, in caso il demone stia girando indipendentemente e non sotto inetd o xinetd, riavviare il servizio. "NRPE: Command timed out after x seconds": Questo errore indica che il comando che è stato lanciato dal demone NRPE non ha finito la sua esecuzione nei tempi specificati. Si può incrementare questo tempo nel file di configurazione, dove sono definiti i comandi, modificando il valore della variabile command_timeout. Così come nel caso precedente è necessario riavviare il servizio per rendere attiva questa modifica. Pagina 41 di 148

44 Nel caso ci siano altri problemi può essere utile attivare il debug. Nel file di configurazione modificare il valore del parametro debug portandolo ad 1 e riavviare il servizio. Eseguendo di nuovo il plugin check_nrpe si dovrebbero avere delle informazioni di debuggin, nel file di log, sulla macchia remota. Leggendo attentamente il file di log si dovrebbero trovare degli indizi su dove persiste il problema. I file di log di Nagios si trovano nella cartella /usr/local/nagios/var suddivisi in differenti file. Il più importante è sicuramente nagios.log nel quale sono salvati tutti i log in generale. Questo file viene salvato, ogni giorno, con la data corrispondente nella sottodirectory archives. Così facendo si possono consultare i vecchi log, suddivisi per data, e controllare eventualmente la causa di qualche malfunzionamento. In questo file di log sono visualizzabili tutti i risultati dei controlli che vengono ritornati al server di monitoraggio e tutte le informazioni sui malfunzionamenti. Altri file di configurazione sono comment.log, downtime.log, status.sav e nagios.lock. Comment.log contiene tutti commenti generati automaticamente da Nagios o che sono stati scritti da un utente per descrivere un determinato malfunzionamento che si è presentato su un host o un servizio. Downtime.log contiene i periodi nei quali il monitoraggio di un determinato servizio o host è stato sospeso con la relativa motivazione. Si può voler sospendere un servizio che presenta un malfunzionamento per un determinato periodo in modo da evitare che venga ripetutamente notificato. Status.sav contiene lo stato che hanno gli host prima di terminare un determinato processo. Nagios.lock utilizzato quando Nagios, avendo molti servizi da monitorare, tende a creare molti processi figli, quindi è necessario memorizzare l'id del processo padre. Pagina 42 di 148

45 Questo file viene utilizzato anche quando si intende arrestare l'esecuzione di nagions e quindi fermare il processo padre e tutti i suoi processi figlio. 4. Configurazione dei plugin Nei precedenti capitoli sono stati installati il nucleo del programma di monitoraggio NAGIOS e il suo addon NRPE per l'esecuzione remota del plugin. È stato installato anche il pacchetto nagios-plugins che, come si intuisce dal nome del pacchetto, contiene una collezione di plugin che possono essere utilizzati per il monitoraggio. Di solito i plugin sono posizionati nella cartella omonima nella diretcory di installazione di NAGIOS. Altre volte può capitare che, con una installazione differente, siano posizionati invece nella cartella libexec. Importante è non trascurare il percorso di questa directory, che potrebbe essere causa del l'errore "NRPE: Unable to read output" in quanto, con un percorso errato, non verrebbe trovato il plugin e l'esecuzione del plugin check_nrpe non produrrebbe alcun output con conseguente errore. Precedentemente è stato già accennato l'utilizzo del plugin check_nrpe. Questo plugin è eseguito sul server di monitoraggio e richiede diverse opzioni. L'uso del plugin a linea di comando è nel seguente formato: # check_nrpe -H <host> [-n] [-u] [-p <port>] [-t <timeout>] [-c <command>] [-a <arglist...>] Le opzioni racchiuse tra parentesi quadre sono obbligatorie. Di seguito una breve descrizione di quello che queste opzioni specificano: -H: Indirizzo dell'host sul quale gira il demone NRPE. -n: Non usare SSL -u: Per far ritornare lo stato Unknown invece che Critical, quando scade il tempo di attesa per il socket. Pagina 43 di 148

46 -p: La porta sulla quale il demone sta girando. Per specificarne una diversa da quella 5666 di default. -t: Numero di secondi prima che il tempo della connessione scada. In questo modo si specifica un valore diverso da quello standard di 10 secondi. -c: Il nome del comando che il server remoto deve lanciare. -a: Lista di argomenti che vengono passati al plugin specificato dal comando. L'opzione -c è quella più importante in quanto specifica indirettamente il plugin che deve essere eseguito. Per ogni plugin che voglia essere eseguito, sulla macchina remota, si deve creare un comando nel file di configurazione. Il file di configurazione nel quale vengono specificati questi comandi, nelle ultime versioni di nagios, prende il nome di nrpe.cfg. Nelle versioni precedenti invece si chiamava command.cfg. Questo file si trova, a meno che non sia stato specificato un percorso diverso in fase di installazione, nella cartella /ect/nagios. La definizione di un comando ha il formato seguente: command[<command_name>]=<command_line> Quando il demone riceve la richiesta di ritornare il risultato di command_name, eseguirà il comando specificato con la command_line. Questa richiesta fatta al demone è proprio l'opzione -c seguita dal nome del comando, cioè il command Contenuto del file nrpe.cfg Il file nrpe.cfg è un file di configurazione campione per il demone NRPE, quindi ha bisogno di essere posizionato sul host remoto nel quale gira il demone e non sul host da quale il client check_nrpe è stato eseguito. Di seguito viene mostrato il contenuto del file, descritto riga per riga: Pagina 44 di 148

47 log_facility=daemon #Specifica il servizio che si occupa dei messaggi di log al momento dell'autenticazione. La facility di default è daemon, cioè il demone syslogd. pid_file=/var/run/nrpe.pid #Il nome del file nel quale il demone NRPE scrive il suo numero ID del suo processo. Il file è scritto solo se il demone è avviato dall'utente root e in modalità indipendente. Quindi non viene creato alcun file in quanto il demone gira come servizio sotto xinetd. server_port=5666 #Porta sulla quale il demone aspetta per le connessioni. server_address= #Questo indirizzo è utile per specificare una particolare interfaccia, nel caso ce ne siano diverse, per il bind, assegnando questo indirizzo alla socket. nrpe_user=nagios nrpe_group=nagios #Queste due voci determinano rispettivamente l'utente e il gruppo con cui dovrebbe girare il demone. Si può specificare un nome utente (nome di un gruppo nel secondo caso) oppure un ID (GID) allowed_hosts= #Questa è una opzionale lista di indirizzi IP (oppure hostname), separati da una virgola, che indica quali host sono abilitati a comunicare con il demone. Questo fa solo un controllo elementare sull'indirizzo IP del client. Quindi è altamente consigliato, nel caso si voglia limitare la comunicazione a determinati host, utilizzare il file /etc/hosts.allow per specificare gli host abilitati alla connessione sulla porta sulla quale sta girando il demone. Tutta le opzioni presenti fino a questo punto del file sono ignorate nel caso il demone giri sotto xinetd. Quindi vengono specificate in un altro file, cioè il file nrpe nella directory /etc/xinetd.d/, che verrà visto dettagliatamente in seguito. dont_blame_nrpe=0 #Questa opzione determina se permettere o meno ai client di specificare gli argomenti dei comandi che stanno eseguendo. Questa opzione Pagina 45 di 148

48 è disabilitata di default ovviamente per questioni di sicurezza. Questa opzione, per funzionare, necessita anche che, in fase di configurazione, sia con la seguente opzione: --enable-command-args Un'altra opzione disabilitata di default per questione di sicurezza è la seguente: command_prefix=/usr/bin/sudo #Questa opzione permette di inserire come prefisso a tutti i comandi una stringa inserita dall'utente. Uno spazio è automaticamente aggiunto tra la stringa specificata come prefisso e la linea di comando definita. L'esempio specificato (/usr/bin/sudo) è solo un possibile scenario d'uso. In questo modo si restringe l'esecuzione dei comandi con l'utilizzo di sudo. Per far questo è necessario aggiungere l'utente nagios nel file /etc/sudoers. Per esempio si potrebbe aggiungere questa riga, per permettere l'esecuzione dei plugin in quella cartella: nagios ALL=(ALL) NOPASSWD: /usr/lib/nagios/plugins/ Questo fa in modo che gli utenti nagios possano lanciare tutti e soli i comandi di quella directory senza password. Ovviamente non si deve assolutamente dare agli utenti generici i permessi di scrittura su questa directory o ai suoi contenuti. debug=0 #con questa opzione si possono aggiungere anche i messaggi di debug ai log di sistema. Utile nel caso sia presente un malfunzionamento e si voglia qualche informazione in più sulla causa. command_timeout=60 #questa specifica il massimo numero di secondi consentito ai plugin per finire la loro esecuzione. Dopo il tempo specificato il demone ucciderà il processo. connection_timeout=300 #questa specifica il massimo numero di secondi che il demone aspetterà per una connessione che si sta stabilendo, prima di uscire. Spesso viene visto come un problema di rete che ferma la SSL prima che sia stabilita nonostante tutte le sessioni di rete siano connesse. Questo causa un accumulo che può consumare le risorse del sistema, quindi si consiglia di non mettere valori troppo bassi. allow_weak_random_seed=1 #questa direttiva, disabilitata di default, permette di Pagina 46 di 148

49 usare SSL anche se non sono presenti i file /dev/random e /dev/urandom, file speciali utilizzati per la generazione casuale di numeri. La generazione di numeri casuali viene fata da un file il quale è un puntatore alla variabile d'ambiente $RANDFILE oppure $HOME/.rnd. Se nessuna delle due esiste viene messo uno pseudo numero e un segnale di warning viene inviato. include=<somefile.cfg> # questa opzione, disabilitata per default, permettere di includere le definizioni da un file di configurazione esterno. include_dir=<somedirectory> #questa direttiva permette di includere file di configurazione da una o più directory ricorsivamente. Il resto del file consiste nella parte più importante per il funzionamento dei plugin, cioè la definizione dei comandi che il demone lancerà. La definizione è scritta nel formato seguente: command[<command_name>]=<command_line> La linea di comando per ogni plugin utilizzato verrà mostrata e descritta nel successivo capitolo. Come si è visto, molte delle opzioni del file nrpe.cfg sono ignorate in quanto l'addon nrpe è stato configurato in modo da girare sotto il demone xinetd. In questo caso è necessario dare uno sguardo al contenuto del file (figura 16). Come si può intuire molte delle opzioni che troviamo qui sono le stesse del file nrpe.cfg, le stesse opzioni che in quel file vengono ignorate. Di default questo file è disabilitato, quindi per abilitarlo si deve settare la relativa voce a yes. La voce only_from indica l'indirizzo del server di monitoraggio. Il servizio, come possiamo notare dalla prima voce, prende il nome di nrpe, stesso nome che è stato dato al servizio nel file etc/services. Pagina 47 di 148

50 Si è visto come avviare NRPE sotto il demone xinetd. Nel caso si voglia invece avviarlo in modalità standalone è sufficiente andare nella sottocartella sbin ed eseguire il seguente comando: # nrpe c /etc/nagios/nrpe.cfg -d Per avviarlo automaticamente al boot del sistema invece, si devono aggiungere le seguenti righe nel file /etc/rc.local: if [ -x /usr/local/nagios/sbin/nrpe ]; then echo -n ' nrpe' /usr/local/nagios/sbin/nrpe -c /etc/nagios/nrpe.cfg -d fi 4.2. Descrizione dei plugin Nel precedente capitolo è stata vista la forma della definizione di un comando. Se per esempio i plugin stessero nella cartella /usr/lib64/nagios/plugins/ la linea di un comando avrebbe la seguente definizione: command[nome_comando_plugin]=/usr/lib64/nagios/plugins/script I vari plugin utilizzati, quelli che nella linea di comando precedente sono stati generalizzati con il nome script, sono da distinguere in 2 tipologie. La prima tipologia è composta dai plugin base di NAGIOS, quelli cioè scaricati e scompattati precedentemente. La seconda tipologia invece comprende tutti gli script esterni, creati da terzi. Molti di questi sono fatti dal gruppo ATLASItalia e sono scaricabili dal relativo sito web. Pagina 48 di 148

51 Non tutti i plugin base installati con NAGIOS sono stati utilizzati in questo lavoro. Per completezza però vengono ugualmente spiegati nel caso si debba utilizzarli. Di seguito vengono descritti brevemente tutti quelli di base, per maggiori informazioni si può consultare il man. I plugin effettivamente utilizzati invece verranno spiegati dettagliatamente nel prossimo capitolo. I plugin vengono scritti nella forma /nome_plugin, cioè come compaiono nel file nrpe.cfg nella definizione dei comandi (dopo il relativo percorso). Gli stessi plugin possono ovviamente essere eseguiti da linea di comando come eseguibili, quindi nella forma:./nome_plugin. /check_apt È utilizzabile nei sistemi che usano apt-get come software per la gestione dei pacchetti e controlla se sono presenti degli aggiornamenti software. Nel caso si usino le opzioni di default non è necessario avere i privilegi di root. Si può decidere se fare l'update o l'upgrade, se filtrare la ricerca per una determinata stringa o se fare l'avanzamento di versione /check_breeze Controlla la potenza del segnale di apparecchi wireless di tipo breezecom. /check_by_ssh Utilizza SSH per eseguire un comando su un host remoto. È necessario specificare il nome del host e il nome del comando da eseguire. Si può specificare il protocollo da utilizzare, se utilizzare un ipv4 o un ipv6 oppure specificare l'username per il login sul host remoto. Utile per installare i plugin su macchine remote controllando tutto da un server di monitoraggio. /check_clamd Controlla le connessioni CLAMD, quindi di un server clamd, specificando un Pagina 49 di 148

52 host oppure un socket. Come nel caso precedente si può specificare se utilizzare ipv4 o ipv6. Opzionalmente si può utilizzare la connessione SSL. /check_cluster Controlla lo stato dei cluster per un servizio o per un host specificando le soglie di warning e critical per un certo numero di host o servizi. /check_dhcp Controlla la presenza del server DHCP su una rete. Si può specificare l'indirizzo IP del server. /check_dig Controlla il servizio DNS di un host specificato utilizzando il comando dig. Si possono specificare le soglie di warning e critical su determinati tempi di risposta oppure controllare la correttezza dell'output. /check_disk_smb Controlla lo spazio di condivisione del protocollo SMB utilizzato per la condivisione di risorse e file. /check_dns Utilizza, a differenza di dig, nslookup per ottenere l'indirizzo IP di un dato host o dominio. Si può specificare facoltativamente un server DNS da utilizzare. Di default viene utilizzato il server specificato in /etc/resolv.conf. /check_dummy Ritorna semplicemente lo stato specificato a riga di comando. /check_file_age Controlla che un file non sia vuoto ed effettua controlli sulla data di ultimo accesso o modifica specificando un periodo di tempo. /check_flexlm Pagina 50 di 148

53 Controlla la presenza del gestore delle licenze flexlm. /check_fping Controllo di un host con il comando fping. /check_ftp Controlla una connessione FTP con un host o socket specificato. Si può fare opzionalmente anche un controllo sulla correttezza dell'output. /check_game Controlla un game server con il comando qstat /check_hpjd Controlla lo stato di una stampante HP JetDirect. Nella macchina sulla quale gira il plugin deve essere installato Net-snmp /check_http Controlla il servizio HTTP su un host specificato. Può controllare anche tempi di connessione e certificati scaduti. /check_icmp Effettua dei controlli sul protocollo ICMP, utilizzato per trasmettere informazioni riguardati malfunzionamenti dei componenti di una rete. /check_ide_smart Controlla, utilizzando l'interfaccia SMART, lo stato di un hard disk di tipo ide. /check_ifoperstatus Controlla lo stato di una determinata interfaccia di rete, di un determinato host, utilizzano snmp. /check_ifstatus Controlla, a differenza del precedente, lo stato di tutte le interfacce. Pagina 51 di 148

54 /check_imap Controlla le connessioni IMAP di un host o socket specificato ed eventualmente si autentica. /check_ircd Controlla un IRC Server /check_jabber Controlla una connessione JABBER su un host o socket specificato. /check_ldap e /check_ldaps Controllano un server LDAP /check_log Controlla un file di log su un determinato percorso. /check_mailq Controlla la lunghezza della coda delle . /check_mrtg Controlla nel log file MRTG il valore medio o il valore massimo di una delle variabili memorizzate al suo interno. /check_mrtgtraf Controlla il transfer rate in entrata e in uscita da un router o uno switch memorizzato in un file di log MRTG. Se il nuovo valore è più vecchio di expire minutes allora viene ritornato uno stato di warning. Se sia il traffico in entrata che in uscita eccede le relative soglie allora viene ritornato uno stato di critical. /check_mysql Controlla la connessione di un server MySQL Pagina 52 di 148

55 /check_mysql_query Controlla la connessione di un server MySQL con l'ausilio dei risultati di una query. /check_nagios Controlla lo stato del processo NAGIOS sulla macchina locale. Si assicura che il file di log non sia più vecchio di quello specificato nell'opzione che specifica la scadenza in minuti. Fa anche uno controllo sulla tabella dei processi con un confronto con gli argomenti dei comandi. /check_nntp e /check_nntps Controllano la connessione, rispettivamente NNTP e NNTPS per un determinato host o socket. /check_nrpe Utilizzato per controllare l'installazione dell'addon NRPE e per eseguire i plugin in remoto. /check_nt Raccoglie dai dal servizio Nsclient che gira su una macchina con windows server nt/2000/2003/xp. /check_ntp, /check_ntp_peer, /check_ntp_time Effettuano controlli sul server ntp specificato /check_nwstat Contatta il MRTGEXT NLM che gira su un server Novel per ottenere varie informazioni. /check_oracle Effettua l'autenticazione su un server Oracle. Pagina 53 di 148

56 /check_overcr Contatta il demone Over-CR, che gira su un server remoto unix, per ottenere le informazioni richieste. /check_pgsql Contatta un server PostgreSQL per vedere se accetta connessioni, prova l'autenticazione e le query. /check_ping Usa il ping per controllare statistiche sulla connessione di un host remoto. /check_pop Controlla la connessione POP specificando un host o un socket. /check_procs Controlla tutti i processi e genera stati di warning e critical se le metriche specificate superano le soglie richieste. /check_radius Controlla se il server radius accetta connessioni. /check_real Controlla il servizio REAL su un host specificato. /check_rpc Controlla se c'è un servizio RPC su un server remoto. /check_sensors Utilizzando i sensori lm-sensors controlla lo stato del hardware. /check_simap Controlla una connessione SIMAP su un host o socket specificato Pagina 54 di 148

57 /check_ssmtp Cerca di aprire una connessione SSMTP con un host specificato. /check_swap Controlla lo spazio swap su un host. /check_tcp Controlla una connessione TCP su un host o socket specificato /check_time Controlla l'ora su un host specificato. /check_udp Controlla la connessione UDP su un host o socket specificato /check_ups Controlla lo stato degli UPS con i Network UPS Tools /check_users Controlla il numero di utenti autenticati, in quel momento, nel sistema locale e genera un errore se il numero degli utenti supera le soglie specificate. /check_wave Controlla la potenza di un segnale ricevuto. Questa lista comprende tutti i plugin base che fanno parte del pacchetto Nagios-Plugin. Non sono stati inseriti quelli effettivamente aggiunti come servizi che verranno invece descritti dettagliatamente, insieme a tutti gli altri script utilizzati, nel prossimo capitolo. Pagina 55 di 148

58 4.3. Script utilizzati per gli Host I primi script utilizzati in questo lavoro di tesi, che vengono analizzati, sono quelli che fanno parte del plugin di base di NAGIOS, in particolare check_disk, check_load e check_ssh. Check_disk è un plugin che controlla la quantità di spazio occupata su un disco di un file system montato e genera degli avvertimenti se lo spazio libero è minore della soglia specificata. Questo plugin prende due opzioni obbligatorie che sono le soglie di warning e di critical. Per tutti gli host sono state inserite le stesse soglie, rispettivamente 5% e 1%. Finchè lo spazio libero è superiore al 5% lo stato ritornato dal plugin è OK. Appena scende sotto il 5% lo stato diventa warning e quando arriva al 1%, cioè quasi tutto il disco è occupato, lo stato diventa critical. Se non si inserisce nessuna altra opzione il plugin fa un controllo su tutte le partizioni disponibili. Questo però può essere un problema in quanto, sul alcuni host, è presente una partizione opt che è quasi del tutto occupata. Lo spazio libero della partizione opt è costantemente è al di sotto del 5%, quindi comporterebbe un perenne stato di Pagina 56 di 148

59 warning. Fortunatamente il plugin check_disk permette anche di specificare la partizione sulla quale effettuare il controllo con l'ausilio dell'opzione -p. Lì dove non c'è stato bisogno di distinguere le partizioni, il comando inserito nel file di configurazione prende il nome di check_all_disk e ha questa forma: command[check_all_disk]=/usr/lib64/nagios/plugins/check_disk -w 5% -c 1% Gli host in questione sono tutti gli Storage Element. Per gli altri host, dove c'era bisogno di non considerare la partizione opt, è stato creato un comando per ogni partizione. È possibile vedere le partizioni di una macchina con il comando: # df Sui Worker Node sono presenti solo 2 partizioni, una di queste è proprio opt. Quindi è stato creato un comando di nome check_disk che controlla solo l'altra partizione (/dev/sda1): command[check_disk]=/usr/lib64/nagios/plugins/check_disk -w 5% -c 1% -p /dev/sda1 Sui Service Node la situazione invece cambia da host in host. Su atlas-squid, monitor e t2-hlr-01 è stato utilizzato check_all_disk. Su atlasui01, atlasui02 e atlasce01 invece sono stati usati check_disk1 e check_disk2 per le 2 rispettive partizioni. Di seguito i due comandi per le due partizioni di atlasce01: command[check_disk1]=/usr/lib/nagios/plugins/check_disk -w 5% -c 1% -p /dev/sda1 command[check_disk3]=/usr/lib/nagios/plugins/check_disk -w 5% -c 1% -p /dev/sda3 Check_load è un plugin che controlla il carico medio della CPU di un host. Anche in Pagina 57 di 148

60 questo caso è necessario specificare delle soglie di warning e critical. Essendo però un calcolo medio ogni soglia prende non uno ma tre valori che rappresentano rispettivamente il carico negli ultimi 1, 5 e 15 minuti. La soglia si considera superata se uno qualunque dei tre valori di carico supera i valori specificati nell'opzione. I valori vengono calcolati con una media pesata del carico durante il periodo di riferimento in modo da dare più importanza ai valori più recenti. Praticamente ogni CPU parte da uno stato di idle, uno stato nel quale non sta eseguendo nessun processo. In questo stato ha un carico pari a 0. Ogni processo che è in uno stato di running o di waiting sulla CPU aggiunge al carico un valore di 1. Spesso si considerano anche processi in attesa sull' I\O e questo comporta ovviamente un aumento del carico della CPU. Tutte le macchine in questione hanno 2 o 4 CPU core, quindi si deve ripartire il carico per ogni CPU dividendo il carico totale per il numero delle stesse. Per questo motivo le soglie sono state aumentate e moltiplicate per il numero di core. Per conoscere informazioni riguardanti la CPU del sistema si può eseguire il seguente comando: # cat /proc/cpuinfo Questo script, pur controllando solo il carico della CPU, ha due scopi di utilizzo fondamentalmente diversi. Ci sono determinate macchine, in particolare i Worker Node, che devono sempre lavorare, quindi lo scopo di check_load in questo caso è controllare appunto che stiano lavorando. Uno eventuale stato di warning quindi è da prendere positivamente. Negli altri casi invece, la funzione di check_load è di controllare che succeda l'esatto contrario, cioè che le macchine non siano troppo sotto sforzo e il carico della cpu non sia eccessivamente elevato. In questo caso quindi un eventuale warning deve essere preso negativamente, Di seguito la definizione dei comandi del plugin check_load adattate al numero di CPU core presenti nel sistema: Pagina 58 di 148

61 command[check_load]=/usr/lib64/nagios/plugins/check_load -w 15,10,5 -c 30,25,20 command[check_load]=/usr/local/nagios/libexec/check_load -w 30,20,10 -c 60,50,40 Check_ssh è un plugin che controlla la connessione SSH (Secure Shell) su una determinata porta e host. La porta di default sulla quale gira il demone è la 22. L'unica opzione che deve essere obbligatoriamente specificata è l'host name. Il plugin viene eseguito da remoto, ma il controllo del SSH deve essere fatto localmente, quindi come host si inserisce localhost. Un'altra opzione che deve essere settata è se usare una connessione ipv4 o ipv6. In questo caso si utilizza la prima. Già è stato detto che la porta di default è la 22, su alcune macchine però il demone è attivo su una porta diversa, la 5022, quindi si deve utilizzare l'opzione -p per specificare una porta che non si quella di default. La connessione viene provata per 10 secondi dopo i quali la richiesta scade. Anche questo è un valore di default, si può specificare un tempo diverso con l'opzione -t. Di seguito la definizione del comando per atlasce01.na.infn.it: command[check_ssh]=/usr/lib/nagios/plugins/check_ssh -4 -t 10 -p 22 localhost Oltre a questi plugin sono stati aggiunti anche altri script, scritti in perl, messi a disposizione da ATLASItalia: check_memory, check_nfs_stale. check_df, check_pbs, check_cert, check_pbs_all, check_0queue. Per far funzionare questi script in perl, oltre ad aver installato sul sistema il perl c'è bisogno di un particolare modulo di nagios relativo al perl. Infatti già provando gli script in perl senza nrpe, se non è presente questo modulo, viene restituito un errore del seguente tipo: Can't locate Nagios/Plugin.pm contains:...) at./check_memory.pl line 46. BEGIN failed--compilation aborted at./check_memory.pl line 46. Pagina 59 di 148

62 Si può installare il modulo mancante in due modi. Il primo modo è direttamente tramite il perl, eseguendo questo comando: # perl -MCPAN -e 'install Nagios::Plugin' L'altro modo è installare il pacchetto tramite il gestore di pacchetti della distribuzione utilizzata (in questo caso yum). Quindi, se presente nei repository, si può fare: # yum install perl-nagios-plugin Check_memory è uno script che controlla la quantità di memoria centrale libera. Prende come valori 2 soglie, rispettivamente per il warning e per il critical. I valori delle soglie devono essere in percentuale. Sono stati inserite le stesse soglie utilizzate per il plugin check_disk, cioè 5% per il warning e 1% per il critical. La definizione del comando è la stessa per tutti gli host, prendiamo come esempio quella di atlasce01.na.infn.it: command[check_memory]=/usr/lib/nagios/plugins/check_memory.pl -w 5% -c 1% Check_nfs_stale è uno script che controlla presenza, ed eventualmente cerca di risolvere, l'errore NFS: Stale file handle sulle macchine che montano l'area software via NFS. Lo script ha bisogno dei permessi di scrittura sui file temporanei $temp_file per montare e smontare i comandi senza la richiesta della password. Questo script, per il momento, non è stato aggiunto come comando e quindi neanche come servizio. Restituisce critical se il problema NFS è stato trovato e lo script non è riuscito a risolverlo, warning se è stato trovato il problema ma lo script lo ha risolto e OK nel caso in cui non sia stato trovato. Check_df è uno script che controlla, tramite il comando df, se il file system passato come parametro è montato correttamente. L'unico parametro obbligatorio da specificare ovviamente è il nome del file system da controllare. Anche questo script, Pagina 60 di 148

63 come il precedente, non è stato aggiunto temporaneamente né ai comandi né ai servizi. Ritorna OK se il path passato è stato trovato, critical in tutti gli altri casi. Check_pbs è uno script che controlla le code con il comando qstat -q. Esegue controllo su soft limit ed hard limit di tutte le code ed esegue un controllo sulla cosa cert che non ha soft ed hard limit definiti in maui.cfg. Prende due parametri opzionali, il percorso del file maui.cfg e il percorso dell'output. Un parametro interno invece, di nome max_runnable_job, deve essere settato con il numero massimo di job che possono essere eseguiti contemporaneamente. Questo script è usato sul CE, di seguito la definizione del comando: command[check_pbs]=/usr/lib/nagios/plugins/check_pbs.pl Questo script ha bisogno di uno scheduler di cluster per funzionare, in particolare del Maui. I controlli che fa sono i seguenti: Controllo sui soft limit: controlla le code con i job in coda e i job che stanno girando al di sotto del soft limit e che il numero totale di job sul CE al di sotto del proprio limiti. Controllo sugli hard limit: controlla le code con i job in coda e i job che stanno girando al di sotto del hard limit e che il numero totale di job sul CE al di sotto del proprio limiti. Questo controllo è effettuato solo se il precedente controllo non ha trovato nessuna coda che rispecchia le sue condizioni, quindi si può assumere che tutte le code hanno un numero di job che stanno girando maggiore del soft limit. Controllo della coda cert: controlla se la coda cert ha dei job in coda e che il numero totale di job che stanno girando sul CE è minore del proprio limite. Questo controllo deve essere fatto separatamente dagli altri due in quanto la coda cert non ha soft limit e hard limit definiti in maui.cfg,. In ogni caso, commentando determinate righe che si riferiscono al cert, nel file di Pagina 61 di 148

64 configurazione, si può far in modo che anche questa coda abbia i soft e hard limit e venga trattata come tutte le altre. I primi due controlli sono mirati a controllare se il sistema di code PBS è sottoutilizzato. Per esempio se ci sono dei job in coda che per qualche motivo non stanno girando. Il controllo numero 3 è uguale ai precedenti solo che è per la coda cert. Questo script ritorna critical se almeno uno dei 3 controlli è verificato, altrimenti ritorna lo stato OK. Check_cert è uno script che controlla se la coda cert ha dei job in coda ma nessuno di questi sta girando, questo indipendentemente dal numero di job totali, parametro che invece viene considerato nello script check_pbs. Questo script è utile quando si vuole essere certi che la coda cert giri sempre. L'unico parametro che prende, per'altro opzionale, è il nome della coda cert. Anche questo script è utilizzato sul CE, di seguito la definizione del comando: command[check_cert]=/usr/lib/nagios/plugins/check_cert.pl Ritorna lo stato di critical se uno dei controllo si verifica, in tutti gli altri casi invece ritorna lo stato OK. Check_pbs_all è uno script che esegue contemporaneamente check_pbs e check_cert. Questo script può essere usato nel caso non si abbia la necessità di gestire separatamente i due script, per esempio se non si ha la necessità di specificare un tempo di timeout diverso. Vediamo sempre la definizione del comando sul CE: command[check_pbs_all]=/usr/lib/nagios/plugins/check_pbs_all.pl Ritorna lo stato di critical se uno dei controllo si verifica, in tutti gli altri casi invece ritorna lo stato OK. Pagina 62 di 148

65 Check_0queue è l'ultimo script rimasto, lasciato per ultimo in quanto è l'unico di questi a non essere scritto in perl, ma è uno script shell. Controlla semplicemente se sulla coda passata come parametro sono presenti o meno dei job in coda. Utile quando si vuole essere certi che la coda abbia sempre qualche job che sta girando. E' usata per la coda atlas. Anche questo script utilizza il comando qstat -q. Di seguito la definizione del comando sul CE: command[check_0queue]=/usr/lib/nagios/plugins/check_0queue atlas Ritorna lo stato OK se la coda specificata è abilitata e ci sono dei job in coda. Ritorna lo stato di warning se la coda specificata è disabiltiata a prescindere dal numero di job in coda. Ritorna lo stato critical se la coda specificata è abilitata e non ci sono job in coda Il protocollo SNMP Non tutti i nodi della rete sono macchine, con un sistema operativo che gestisce le risorse. Senza un sistema operativo non si può ovviamente utilizzare l'addon nrpe per controllare le risorse locali di un nodo remoto. In questi casi si può usare per il monitoraggio il protocollo SNMP (Simple Network Managment Protocol ), usato di solito sulle reti TCP/IP, un protocollo utilizzato per la gestione di infrastrutture di rete. SNMP permette il monitoraggio e il controllo di dispositivi di rete quali Router, Switch o Hub, permettendo di conoscere informazioni di tipo prestazionali o sullo stato del sistema. Un framework SNMP è composto da un sistema gestito (managed object), un agente di gestione (management agent) e un sistema di gestione (manager). Un sistema gestito, come un generico nodo o uno switch per esempio, ospita un agente di gestione ed un certo numero di subagent. L'agente di gestione funge da intermediario tra il sistema di gestione e i subagent. Quando un sistema di gestione Pagina 63 di 148

66 interroga l'agente di gestione, questo invia le informazioni richieste sul dispositivo del quale si occupa. Ogni subagent prende le decisioni di gestione per quanto concerne nei propri compiti, in un determinato sottosistema o aspetto del sistema. In sistemi con una gestione più semplice, l'agente di gestione e i sottoagenti possono costituire un'unica struttura, chiamata semplicemente agente, in grado di dialogare con il sistema di gestione e prendere decisioni. Di solito gli agenti, in un dispositivo di rete, sono implementati proprio nel firmware del dispositivo oppure, nel caso dei server, all'interno di servizi software. SNMP utilizza una chiara separazione tra il protocollo di gestione e la struttura dell'oggetto gestito. In questa architettura, per ogni sottosistema, è definito un database di nome MIB (Management Information Base), gestito dal corrispondente subagent il quale rappresenta lo stato del sottosistema gestito, limitato ai soli aspetti dei quali si vuole consentire la gestione. Gli oggetti gestiti dagli agent, quindi tutti gli attributi che si possono monitorare, sono contenuti in questa MIB, secondo la struttura definita nella SMI (Structure Management Information). Il MIB ha una struttura ad albero ed ogni oggetto è identificato all'interno di questa struttura tramite un OID (Object Identification). Un oggetto ha anche una etichetta associata, quindi può essere identificato o tramite il suo ID o tramite la sua etichetta. Ogni modifica a questa MIB causa un un cambiamento dello stato del corrispondente sistema che rappresenta. Questa è una proprietà delle MIB che viene garantita da un subagent. Si accede alla MIB tramite un'interfaccia messa a disposizione del sistema di gestione. Pagina 64 di 148

67 Ogni MIB, cambia nei propri contenuti, ma mantiene la stessa struttura generale e gli stessi meccanismi di accesso ai dati, in lettura e scrittura, da parte del sistema di gestione. Sulle macchine da monitorare è già installato, tramite il pacchetto snmpd, il demone SNMP. SNMP utilizza come protocollo di trasmissione UDP in modo da ottenere migliori performance e minore overhead della rete. In particolare viene utilizzata la porta UDP 161 per le interrogazioni e le risposte, e la porta UDP 162 come destinazione dei messaggi trap SNMP generate dagli agent SNMP. Gli apparati di rete gestiti da SNMP sono organizzati in una comunità (community). La comunità rappresenta un identificativo che permette di garantire la sicurezza delle interrogazioni SNMP. Un agente SNMP risponde solo alla richieste di informazioni effettuate da un sistema di gestione appartenente alla stessa comunità. I nomi di comunità sono formati da 32 caratteri e sono di tipo case sensitive. Esistono tre tipi di comunità: monitor, che permette di lavorare in sola lettura, quindi di effettuare solamente interrogazioni agli agenti (il cui nome di comunità deve corrisponde a quello del sistema di gestione che ne ha fatto la richiesta). Il control, che permette tramite gli agenti SNMP di effettuare delle operazioni in lettura/scrittura sul dispositivo, quindi di variarne delle impostazioni sempre previo controllo di sicurezza. Il trap, che permette ad un agente di inviare un messaggio trap SNMP al sistema di gestione secondo la propria configurazione. Spesso i nomi di community di default predefiniti sono public per le comunità di sola lettura e write o private per quelle in lettura/scrittura. Ovviamente è bene modificare queste impostazioni di default per motivi di sicurezza. Pagina 65 di 148

68 SNMP utilizza sei tipi di messaggi di base per svolgere il proprio lavoro. Ogni messaggio è definito in PDU (Protocol Data Unit) separate, e precisamente: GetRequest: è utilizzata per interrogare un MIB su un agent SNMP. GetNextRequest: è utilizzata per leggere in modo sequenziale un MIB. GetBulk: permette di leggere un MIB con un unica richiesta anzichè utilizzare più messaggi GetNextRequest. SetRequest: modifica il valore all'interno di un MIB acceddibile in lettura/scrittura. GetResponse: identifica la risposta da parte di un agent SNMP ad un'interrogazione di una management station. Trap: permette all'agent di inviare un messaggio al verificarsi di un determinato evento. Alcune trap sono predefinite: coldstart: generata quando l'agente SNMP si reinizializza e la configurazione è stata cambiata (Es. reboot del sistema). warmstart: generata quando l'agente SNMP si reinizializza ma senza cambiamenti nella configurazione. linkdown: generata quando il collegamento con l'agent non funziona correttamente. linkup: generata quando il collegamento con l'agent viene ripristinato. authenticationfailure: generata da un'autenticazione con l'agent non andata a buon fine (Es. nome di comunità errato). egpneighborloss: generata da problemi di EGP (Exterior Gateway Protocol utilizzato dai router). Pagina 66 di 148

69 enterprisespecific: evento definito dal produttore del device. La SMI (Structure Mangement Information) definisce in modo standard come devono essere strutturate le informazioni e la loro gerarchia per essere inserite nel database MIB e quindi gestite da una manager SNMP. La gerarchia degli oggetti, è ad albero: [root] [ccit(0)][iso(1)][joint-iso-ccitt(2)] [org(3)] [dod(6)] [internet(1)] [directory(1)][management(2)][experimental(3)][private(4)] [mib(ii)][enterprise(1)] [System(1)][Interfaces(2)][Address Translation(3)][Ip(4)][Icmp(5)][Tcp(6)][Udp(7)] [Egp(8)][Snmp(9)] Ogni oggetto della gerarchia viene identificato in modo univoco, attraverso il suo percorso nell'albero, la variabile Hostname per esempio è identificata da: iso.org.dod.internet.management.mib.system.sysdescr oppure Gli oggetti sono definiti tramite la sinstassi ASN.1 (Abstract Syntax Notation One), la quale permette di non avere ambiguità tra funzioni e proprietà dell'oggetto definito. La management Information Base, è una base di dati contenente tutte le informazioni gestite dall'agent SNMP che è in funzione sulla device monitorata. Gli oggetti all'interno di una MIB vengono definiti in base alle strutture SMI. Attualmente lo standard utilizzato è la MIB-II. All'interno di ogni MIB gli oggetti sono suddivisi in categorie, in particolare: System: contiene informazioni di carattere generale sul device di rete. Pagina 67 di 148

70 Interfaces: contiene le informazioni relative alle interfacce di rete. Address Translation: contiene informazioni relative alla conversioni degli indirizzi (Es. da logico a fisico), esiste per compatibilà con MIB-I. Ip: contiene informazioni relative al protocollo IP. Icmp: contiene informazioni relative al protocollo ICMP. Tcp: contiene informazioni relative al protocollo TCP. Gli oggetti di questo gruppo esistono solo per la durate della sessione TCP. Udp: contiene informazioni relative al protocollo UDP. Egp: contiene informazioni relative al protocollo EGP (protocollo utilizzato da un router per scambiare informazioni tra Autonomous System). Transmission: sperimentale, contiene informazione sui mezzi trasmissione utilizzato da ogni interfaccia di rete. Snmp: contiene informazioni relative al protocollo SNMP Script per UPS, Switch e CMC Tutti gli script che seguiranno fanno uso del SNMP. Questi script, considerando la loro natura, sono presenti solo sul server e non si deve fare alcun tipo di configurazione, ma possono essere utilizzati semplicemente eseguendo il plugin dal server e specificando il dns dell'apparato: Water Temperature: Si utilizza il plugin check_snmp per controllare la temperatura dell'acqua dell'impianto di raffreddamento, tramite i CMC. Tra i vari parametri da passare ci sono le soglie di warning e critical, il dns del CMC e l'unità di misura della temperatura. Il comando da lanciare dal server è il seguente: check_snmp -H cmc.na.infn.it -C public -o w Pagina 68 di 148

71 40 -c 60 -l 'Temperature' -u ' C' Temperature: Si utilizza il plugin check_snmp per controllare la temperatura dell'ambiente all'interno dei rack, sempre tramite i CMC. I parametri da passare sono gli stessi del precedente script. /check_snmp -H cmc.na.infn.it -C public -o w 35 -c 60 -l 'Temperature' -u ' C' Fan Speed: Si utilizza uno script denominato check_snmp_fanspeed per controllare la velocità delle ventole. Anche in questo caso si utilizzano i CMC e si inseriscono soglie di warning o critical che si riferiscono alla velocità. /check_snmp_fanspeed.sh cmc.na.infn.it Uptime: Tramite il plugin check_snmp si controlla da quanto tempo è up l'apparato. Questo script può essere utilizzato sia per i CMC che per i Switch e UPS. La definizione del comando è la seguente: check_snmp cmc.na.infn.it -C public -o sysuptime.0 Traffic: Uno dei parametri più importanti che interessano degli Switch, cioè la percentuale di banda utilizzata. Si utilizza uno script chiamato traffico_link: /traffico_link.sh switch.na.infn.it Descrption: Tramite il plugin check_snmp, per tutti gli apparati, è possibile ottenere come informazione la descrizione dell'apparato. La definizione del comando è la seguente: /check_snmp switch.na.infn.it -C public -o sysdescr.0 UPS Charge: tramite lo script check_snmp_ups_charge si può controllare la carica rimanente di un UPS: /check_snmp -H upsmon.na.infn.it -o UPSMIB::upsEstimatedChargeRemaining.0 -C!n0npublic -w 80:50 -c 49:0 Pagina 69 di 148

72 UPS Autonomy: Tramite lo script check_snmp si può conoscere qual'è il tempo rimanente della carica della batteria prima che si esaurisca. Anche questo viene utilizzato per gli UPS e la definizione del comando è: /check_snmp -H upsmon.na.infn.it -o UPSMIB::upsEstimatedChargeRemaining.0 -C!n0npublic -w 80:50 -c 49:0 UPS Status: Questo script chiamato check_ups_status, che controlla lo stato degli ups, è definito come segue: /check_ups_status.pl -H upsmon.na.infn.it -C!n0npublic 4.6. Considerazioni In questi capitoli si è visto come installare il software di monitoraggio NAGIOS sul server, l'addon NRPE sugli host per il monitoraggio, da remoto, delle risorse locali e come configurare i plugin sulle varie macchine. I plugin eseguiti tramite NRPE possono essere testati prima localmente, mettendo localhost come indirizzo del server, poi da remoto, eseguendoli direttamente dal server tier2-nagios. Tutti gli accessi remoti alle macchine sono stati fatti con SSH, quasi sempre sulla porta 22. Per accedere ad una macchina tramite ssh si può eseguire il seguente comando: # ssh Pagina 70 di 148

73 Per accedere viene chiesta anche la password dell'username specificato. L'installazione e la configurazione di queste componenti è stata fatta prima manualmente, poi automatizzata il più possibile. L'applicazione NAGIOS è stata installata dal cd con il FAN, che automaticamente installa anche Centreon e Nagvis, che verranno visti in seguito. L'installazione del NRPE su tutte le macchine invece è stata fatta tramite i pacchetti rpm aggiornando i repository. La configurazione dei file del NRPE è stata fatta prima semi-automatica, con l'utilizzo di una macchina lxlupo per copiare un file di configurazione, di una macchina configurata correttamente, su tutte le altre macchine non ancora configurate. Successivamente è stata automatizzata anche questa procedura in modo che, quando è installato NRPE su una macchina, questa sia già configurata. I repository sono stati aggiornati su molte macchine in modo da includere anche il perl-nagios-plugin, che prima non era presente, necessario per il funzionamento degli script in perl. Questo lavoro di tesi, come già accennato precedentemente, è stato fatto su un sistema di monitoraggio NAGIOS già esistente. Per provare prima in locale la configurazione NAGIOS-NRPE è stato necessario installare localmente un'altra copia di NAGIOS. Localmente si dovevano provare anche gli script della macchina CE, prima di caricarli con il file di configurazione su questa macchina. La macchina CE è adibita al controllo delle code e prende il nome di atlasce01.na.infn.it. Per provare quindi gli script relativi alle code devono essere presenti uno scheduler di cluster e un gestore delle risorse. Entrambi ovviamente sono già presenti su atlasce01. Per provare gli script localmente si devono installare anche sulla macchina locale. Sono stati scelti, come scheduler il Maui e come gestore delle risorse il Torque compatibile con Maui. Pagina 71 di 148

74 4.7. Scheduler e Resource Manager Il Maui è uno scheduler di cluster avanzato, usato per migliorare il controllo e l'efficienza dei cluster e delle risorse dei supercomputer. Questa mini-guida evidenzia i passi chiave e le considerazioni coinvolte nell' installazione, la costruzione, la configurazione e il testing del Maui su nuovi sistemi. Il primo passo è la comprensione di cos'è il Maui. Il Maui è uno scheduler, prende decisioni riguardo a dove, quando e come far girare i job tramite un insieme di politiche configurabili, priorità e limiti. Prende le sue decisioni interrogando e controllando un sistema di gestione delle risorse come OpenPBS, PBSPro, Torque, LoadLeveler, SGE, ect. Per far girare il Maui sono richiesti tra i 20 e i 50 mb di RAM e almeno 20 MB di spazio sul disco per tenere sorgenti, file binari, statistiche e log file. Richiede che un manager di risorse sia installato ed operativo. Maui deve girare sotto un user id con accesso da amministratore al manager delle risorse che viene usato. L'installazione e configurazione del Maui deve essere condotta sotto questo user id. Prima di tutto devono essere determinate l'host e la home directory che ospiteranno il Maui. Spesso l'host sarà lo stesso della macchina sulla quale gira il manager delle risorse. La Home directory invece sarà la locazione standard local, per esempio /usr/local/src. Per prima cosa è necessario andare sul sito Qui sarà possibile scaricare il file tar solo dopo aver effettuato la registrazione. Una volta scaricato il file maui-3.3.tar.gz sul desktop spostarlo in una cartella appropriata: # mv /root/desktop/maui-3.3.tar.gz /usr/local/src/ Estrarre ed entrare nella cartella estratta: # gtar -xzvf maui-3.3.tar.gz Pagina 72 di 148

75 # cd maui-3.3 A questo punto, se si lancia./configure si vede che l'operazione non va a buon fine, con il seguente errore: configure: WARNING: Resource Manager not specified - attempting build with pbs configure: error: can't find pbs-config or libpbs.a Come si evince dall'errore manca proprio un Resorce Manager. È stato scelto e installato TORQUE come gestore delle risorse affiancato dal Maui come scheduler. TORQUE è un manager delle risorse anche conosciuto con il suo nome storico: PBS (Portable Batch System). Scaricare Torque: # cd /usr/local/src # wget Estrarre ed entrare nella cartella creata: # tar -xzvf torque tar.gz # cd torque Compilare e Inizializzare: #./configure # make # make install TORQUE richiede solo pochi passi per inizializzare, configurare e far girare il sistema. Per prima cosa il server ha bisogno di conoscere di quali computer node può fidarsi. Pagina 73 di 148

76 In secondo luogo il server deve essere inizializzato e configurato. Infine ogni computer node ha bisogno di sapere dove è posizionato il pbs_server. Per configurare il pbs_server lanciare il comando torque.setup <USER>, dove user è l'utente che sarà l'admin di TORQUE: #./torque.setup root Una alternativa è fare: # pbs_server -t create Se non si è specificato durante il configure una cartella diversa, il pbs_server e il pbs_mom vengono messi nella cartella /usr/local/sbin Per vedere la configurazione lanciare il comando: # qmgr -c 'p s' l'output del comando è è il seguente: # # Set server attributes. # set server acl_hosts = pc10.scope.unina.it set server log_events = 511 set server mail_from = adm set server scheduler_iteration = 600 set server node_check_rate = 150 set server tcp_timeout = 6 A questo punto l'installazione e la configurazione di TORQUE è terminata. Possiamo utilizzare il comando qstat -q e controllare che ci sia una coda fittizia, creata da Pagina 74 di 148

77 torque.setup, chiamata batch. Possiamo proseguire anche la configurazione del Maui da dove era stata interrotta e provare gli script, alcuni dei quali richiedono proprio la posizione del file maui.cfg Problematiche Durante questa parziale fase del lavoro ho riscontrato e risolto alcune problematiche. Una prima problematica riguarda il file di log /var/log/messages. Ogni volta che viene fatta una interrogazione al demone nrpe, da parte del server, 2 righe di codice vengono scritte nel file di log del sistema, in particolare le seguenti righe: Nov 3 10:58:15 pc01 xinetd[2940]: START: nrpe pid=25903 from=172.xxx.xxx.xxx Nov 3 10:58:16 pc01 xinetd[2940]: EXIT: nrpe status=0 pid=25903 duration=1 Su una macchina vengono eseguiti mediamente 5 script ogni 5 minuti. Questo significa 2 righe di file log ogni minuto, 120 righe ogni ora, 2880 righe al giorno nel file di log. Questo è un problema sia dal punto di vista dello spazio occupato all'interno del file, sia dal punto di vista della grandezza del file stesso. Il file ovviamente viene svuotato periodicamente. Questa situazione quindi, di per se, no sarebbe un problema se non fosse che il file di log, su alcune macchine, è utilizzato da altre persone per altri scopi. È necessario quindi spostare i log del demone xinetd da qualche altra parte in modo da liberare il file di log del sistema. Per fare questo è sufficiente andare nel file di configurazione di xinetd, xinetd.conf, che si trova nella directory etc. Alla voce log_type è impostato il valore SYSLOG daemon info che fa appunto copiare il log nel file di sistema. Sostituire il valore come segue: log_type = SYSLOG authpriv Pagina 75 di 148

78 In questo modo i log di xinetd vengono messi in un file di log diverso, in particolare /var/log/secure. Il problema quindi è stato risolto Altri problemi che si sono presentati sono emersi quando sono stati provati gli script che utilizzano SNMP. Provando check_ups_autonomy, tramite check_snmp, usciva il seguente errore: External command error: UPS-MIB::upsEstimatedMinutesRemaining.0: Unknown Object Identifier Non riusciva quindi ad identificare l'oggetto all'interno della MIB. Questo richiedeva che i MIB venissero aggiornati. Questo aggiornamento è stato fatto anche per gli altri apparati che usano SNMP. Un altro problema è sorto con l'altro script per gli ups, check_ups_charge. In particolare lanciando questo script viene ritornato l'errore seguente: Range format incorrect Dopo alcune ricerche si è ipotizzato che questo errore possa essere dovuto ad un bug presente in check_snmp nella versione nagios-plugins Questa ipotesi è stata fatta in quanto ci sono altri precedenti sui forum di persone che hanno avuto lo stesso problema e hanno risolto passando ad una versione precedente. L'ipotesi è avvalorata dal fatto che questo script, su una versione vecchia di FAN, quindi con una versione vecchia del nagios-plugin, funzionava. Il problema non è stato risolto, quindi lo script attualmente non funziona. Piuttosto che fare un downgrade della versione del nagios-plugin, in questi giorni è uscita una nuova versione: nagios-plugins Pagina 76 di 148

79 Si potrebbe quindi provare ad fare un upgrade per vedere se il problema si risolve. 5. Aggiunta dei servizi con Centreon Centreon è un tool di monitoraggio che configura e controlla Nagios tramite una interfaccia web e memorizza l'output dei plugin di Nagios all'interno di un database MySQL. Questi dati sono utilizzati per mostrare lo stato degli Host e Servizi, proprio come fa Nagios, e vengono utilizzati per la creazione di grafici. Centreon, così come Nagios e Nagvis è compreso nel pacchetto di installazione di FAN. Poiché Centreon è già installato, quindi perfettamente funzionante e integrato con Nagios, in questo capitolo vengono affrontate solo le funzionalità di Centreon, in particolare quelle necessarie per aggiungere i servizi sugli host da monitorare in nagios. Pagina 77 di 148

80 L'installazione di Centreon si può raggiungere, tramite interfaccia web e previa autenticazione, dall'indirizzo: figura 21 : Home di Centreon con sommario della situazione degli Host e Servizi Una volta effettuata l'autenticazione si accede alla pagina principale di Centreon. La prima schermata che si vede è Tactical Overview, un sommario con la situazione generale di tutti gli host e servizi, lo stesso Tactical Overview che si vede in Nagios ma con una interfaccia nettamente migliore Host e Host Group Il primo passo nella procedura di configurazione è aggiungere un Host. Per fare questo andare in: Configuration Hosts Nel menu a tendina sono disponibili tutte le possibili azioni da fare su un determinato host, come duplicarlo, cancellarlo o disabilitarlo. Quella che interessa però è l'azione add che permette di aggiungere un host. Premendo il tasto add si apre la schermata, con un form da compilare, visualizzata in figura 22. Pagina 78 di 148

81 figura 22 : Form per l'aggiunta di un nuovo host Prendiamo come esempio, di un host da inserire, atlasse04.na.infn.it. Le informazioni necessarie sono il nome del Host, un alias e il suo indirizzo IP: Host Name = atlasse04.na.infn.it Alias = Storage Element 04 IP Address = Altre informazioni non sono necessarie in questo momento in quanto, verranno aggiunge successivamente, con l'aggiunta di host group, command e service. Quindi si può già salvare il nuovo Host creato. Pagina 79 di 148

82 Aggiungere qui informazioni, come il periodo di controllo, significherebbe fare una distinzione tra i vari host. Queste informazioni invece sono comuni a tutti gli host che hanno un particolare servizio e vengono specificate nel template del servizio come si vedrà più avanti. Gli stessi servizi non vengono associati a singoli host ma a gruppi di host della stessa tipologia. A questo scopo tutti gli host sono stati raggruppati in 2 modi: per il rack di appartenenza e per la funzionalità. Per quelli raggruppati per funzionalità è stata fatta una ulteriore distinzione per la loro locazione (Scope o Atlas). Per creare un Host Group, sempre nella sezione Hosts, selezionare Hosts Group nel menu a sinistra (che visualizza la lista di tutti gli Host Group) e selezionare add. Si aprirà un form come quello visibile nella seguente figura: figura 23 : Form per l'aggiunta di un nuovo host group Pagina 80 di 148

83 Supponiamo di voler creare un gruppo nel quale sono contenuti i CMC di Atlas, allora si inserisce come nome del gruppo e alias CMC_atlas. Più sotto, dove compare la lista di tutti gli host, si deve specificare quali host fanno parte di questo gruppo, selezionarli e premere il pulsante Add Quindi selezionare cmcatlas1, cmcatlas2, cmcatlas3, cmcatlas4 e salvare il gruppo. In questo capitolo non vengono descritti tutti gli host e host group creati in quanto saranno visibili chiaramente nelle mappe più in avanti Aggiungere un comando Una volta aggiunti tutti gli Host ed raggruppati in Host Group, si devono aggiungere i comandi relativi all'esecuzione dei plugin. Nella sezione Commands si può visualizzare la lista di tutti i comandi già aggiunti ed aggiungerne altri con add. Il form per l'aggiunta di un nuovo comando è visibile in figura 24: figura 24 : Form per l'aggiunta di un nuovo comando Pagina 81 di 148

84 Per creare il comando per l'esecuzione dello script check_memory è necessario inserire un nome per il comando e la linea del comando da eseguire. Come nome del comando si può inserire qualcosa che risalti l'utilizzo di nrpe, per esempio check_memory_nrpe. In questo modo, quando si visualizza la lista dei comandi, tramite il form di ricerca, si possono filtrare i comandi in modo da visualizzare solo quelli eseguiti tramite NRPE. La linea di comando invece è quella che è stata eseguita dalla shell del server per l'esecuzione di un plugin remoto, quindi: $USER1$/libexec/check_nrpe -H $HOSTADDRESS$ -c check_memory USER1 e HOSTADDRESS sono due variabili che, di volta in volta, contengono l'utente che sta eseguendo il comando e l'indirizzo del host remoto, quando si esegue il comando su un determinato host. È possibile comporre la linea di comando in modo più rapido e senza errori aggiungendo direttamente le variabili o lo script, selezionando quello che interessa aggiungere nei menu a tendina sulla destra. A questo punto il comando si può anche salvare. È presente però un'altra funzionalità molto importante che permette di testare il plugin. Subito sotto la linea di comando si può inserire l'indirizzo di un host e testare il plugin per vedere se funziona. Questa funzionalità, non presente nelle precedenti versioni di Centreon, è utilissima per capire se il comando è stato scritto correttamente. Ad ogni comando corrisponde un plugin da eseguire e corrisponderà un servizio. Tutti i plugin, che sono stati descritti già precedentemente, vengono richiamati da check_nrpe il quale specifica il nome del Host e il nome del Comando. La linea di comando, per ogni plugin, deve essere scritta nella stessa forma vista per il comando check_memory. Fanno eccezione i comandi per i plugin che utilizzano SNMP. In questo caso non si Pagina 82 di 148

85 deve utilizzare check_nrpe, ma check_snmp. Questo comando richiede anche altri parametri, gli stessi presenti nella descrizione dei relativi plugin nel capitolo Creare un servizio Il passo finale di questa procedura è l'aggiunta di un servizio. Ogni servizio esegue un determinato comando, di quelli descritti precedentemente. Prima di creare un servizio si deve creare un template per il servizio. Selezionare quindi la Tab Services, tra le voci del menu di sinistra c'è anche quella relativa ai Template. Qui è possibile vedere la lista dei template già creata oppure creare un nuovo template cliccando su add. Si aprirà un form per la creazione del servizio così come si può vedere nella figura 25. figura 25 : Form per l'aggiunta di un nuovo template per i servizi Pagina 83 di 148

86 Le prime informazioni necessarie da inserire sono il nome del template e l'alias. È necessario poi impostare i parametri relativi ai tempi dei controlli. Una impostazione tipo potrebbe essere: Check Period = 24x7 Max Check Attempts = 3 Normal Check Interval = 5 * 60 sec Retry Check Interval = 1 * 60 sec In questo modo si imposta il controllo per 24 ore, 7 giorni a settimana. Il massimo numero di tentativo è impostato a 3. Ogni controllo viene fatto ad intervalli di 5 minuti e in caso di errore viene riprovato dopo 1 minuto. Nella parte bassa del template si possono attivare anche le notifiche, che vengono inviate all'amministratore del sistema. Si possono impostare le notifiche per 24 ore, 7 giorni a settimana, proprio come sopra, in modo da renderle attive per tutto il periodo di controllo. Si deve poi scegliere il motivo per il quale ricevere la notifica, se per un warning, un critical, un recovery, ect. Queste sono le impostazioni più importanti per un template. Fatto questo si può passare alla creazione di un servizio. I servizi possono essere creati per un determinato Host oppure per un gruppo di Host. Precedentemente gli Host sono stati raggruppati proprio per questo motivo. Raggruppare gli Host della stessa tipologia fa in modo che si possa creare un servizio per quel gruppo di host. Pagina 84 di 148

87 A questo scopo andare in Services by hosts group per aggiungere un nuovo servizio su un Host Group. Qui ovviamente sarà visibile la lista di tutti gli Host Group con i relativi servizi. Tra le varie informazioni consultabili in questa schermata, per ogni servizio, c'è il periodo di controllo (e di retry), il template utilizzato e lo stato del servizio, cioè se è abilitato o disabilitato. Da qui è possibile anche disabilitarlo, disabilitandolo però anche per tutti gli altri host group. Sempre selezionando add si può aggiungere un nuovo servizio. Il form per la creazione di un nuovo servizio è quello della figura seguente: figura 26 : Form per l'aggiunta di un nuovo servizio per host group Pagina 85 di 148

88 Precedentemente si è visto come aggiungere un comando per il plugin check_memory. Se si volesse creare un servizio che implementi questo controllo, alla voce check command, selezionare dal menu a tendina lo script check_memory. Nelle informazioni generali inserire un nome del servizio che ricordi il comando utilizzato e selezionare il template precedentemente creato. Le altre informazioni sottostanti possono essere lasciate vuote in quanto sono già comprese nel template. Nel caso che si specifichi un valore diverso in questi campi sarà preso in considerazione al posto di quello presente nel template. Le informazioni di base per il servizio sono state inserite, non resta che specificare gli host group sul quale renderlo attivo. Per far ciò si deve passare alla tab relations. Per creare il collegamento tra il servizio e il gruppo di host, nella schermata Linked with HostGroup si deve aggiungere il gruppo\i dalla lista di quelli disponibili. Fatto questo non resta che salvare il servizio creato. Con la creazione del servizio il processo di configurazione con Centreon è terminato, non resta che esportare la configurazione per il Nagios. Per esportare la configurazione e rendere attivi le modifiche andare alla voce nagios, mettere una spunta a move export file e restart nagios, selezionare come metodo reload e premere sul tasto export. Dopo pochi secondi dovrebbe uscire un riepilogo delle operazioni fatte ed eventualmente dei warning e critical. I warning solitamente si riferiscono a degli host che non hanno associato alcun servizio. Questo host vengono anche specificati. I critical invece se quanto fatto non è stato fatto correttamente. Pagina 86 di 148

89 La verifica delle operazioni fatte può essere visualizzata in Nagios, ma così come in Nagios può essere vista anche in Centreon in quanto è esso stesso un tool di monitoraggio. Nel prossimo paragrafo viene illustrata questa funzionalità di monitoraggio Centreon come Tool di monitoraggio Una volta esportato il file di configurazione per nagios è possibile monitorare lo stato dei servizi anche da Centreon. Nell'introduzione di questo capitolo si è visto che, nella home di Centreon, è visibile la Tactical Overview per un sommario sullo stato dei servizi e degli host. Del resto è la stessa che è visualizzabile da Nagios. Nel menu principale, subito dopo la voce Home, c'è Monitoring. Il monitoraggio è diviso in 3 sezioni: Services, Hosts e Event Log. Come è intuibile dal nome la prima permette di monitorare tutto quello che riguarda i Servizi, la seconda quello che riguarda gli Host e l'ultima il log degli eventi. La sezione Services permette di vedere: Services Problems Visualizza tutti i servizi che hanno problemi. In particolare per ogni servizio non funzionante si può vedere l'host sul quale ha un problema, lo stato del servizio (warning, critical, unknown), la durata del servizio, quando è stato effettuato l'ultimo controllo, quante volte è stato provato e in fine l'output dell'errore. Si possono questi servizi per lo stato del servizio visualizzando solo quelli che hanno un warning, un critical o un unknown. Passando il mouse sul Pagina 87 di 148

90 nome del servizio si possono visualizzare informazioni più dettagliate come quando ci sarà il prossimo controllo oppure la latenza. Si può anche cliccare sul servizio in modo da vedere la schermata dei dettagli All Services A differenza del precedente qui vengono visualizzati tutti i servizi. Le informazioni a disposizione sono le stesse visibili in Services Problems, anche qui passando il puntatore sopra il nome del servizio si vedono informazioni dettagliate. L'unico filtraggio che si può fare in questa voce è quello dei servizi funzionanti. Si possono vedere quindi tutti i servizi che ritornano lo stato OK. Grids Un elenco di tutti gli host, per ogni host una lista di tutti i servizi attivi, con relativo colore che indica lo stato del servizio. Anche qui si può cliccare su un servizio per vederne i dettagli. È possibile filtrare visualizzando solo quelli che hanno problemi. Overview Simile a Grids con l'aggiunta di un'unica informazione: Lo stato del Host. Summary Un elenco di tutti gli host, raggruppati per Host Group. Per ogni host c'è il numero di servizi che funzionano, il numero di quelli che hanno un warning o il numero di quelli che hanno un critical. Si possono filtrare vedendo solo quelli che hanno problemi. In aggiunta alla versione precedente di Centreon c'è anche una funzionalità che permette la creazione dei grafici per ogni servizio. In tutte le voci elencate sopra, di fianco ad ogni servizio, c'è un'icona che rappresenta il grafico. Si può visualizzare il grafico semplicemente passando con il puntatore sopra Pagina 88 di 148

91 l'icona, oppure entrando nei dettagli del servizio selezionando il nome del servizio. C'è proprio una voce del menu dedicata al visualizzazione dei grafici, chiamata Views. Qui si possono vedere tutti i grafici specificando un intervallo di due periodi di tempo (data e ora), oppure si può entrare nello specifico selezionando un determinato Host Group, Host o Servizio e vedere tutti i grafici. Selezionando un Host Group si vedono tutti i grafici di tutti i servizi di tutti gli Host di quel gruppo. Selezionando un Host si vedono tutti i grafici di tutti i servizi di quel Host. Selezionando invece un Servizio si vede solo il grafico relativo a quel servizio. figura 27 : grafico per il servizio check_memory su atlasce01 Nella figura precedente si vede il grafico del servizio check_memory attivo sul host atlasce01. Il grafico fa riferimento ad un periodo di 3 giorni I grafici generalmente vengono generati in automatico prendendo i parametri di output dagli script. Non tutti gli script però hanno un grafico. Questo perchè i grafici vengono costruiti su dei dati ritornati dagli script. Questi dati prendono il nome di perfdata (performance data). Se uno script non ha dei perfdata, ma solo uno stato, allora Centreon non ha modo di costruire un grafico. Pagina 89 di 148

92 6. Creazione delle mappe con Nagvis Tutto quello che è stato fatto fin'ora permette di visualizzare lo stato dei servizi all'interno di una tabella che elenca gli stessi e gli host sui quali sono attivi. Sicuramente quanto fatto è sufficiente ad avere una panoramica generale delle risorse dei nodi in quanto le informazioni ottenute sono complete ed esaurienti. È anche vero però che visualizzare le informazioni in questa forma tabellare non è il massimo dell'efficienza. Viene in aiuto agli amministratori del sistema un altro addon di Nagios installato, così come Centreon, nel pacchetto FAN 2.0: Nagvis. Nagvis è usato per dare una visuale grafica ai dati di Nagios con la possibilità di aggiungere mappe in formato png. Su ogni mappa c'è la possibilità di inserire delle service icon che fanno riferimento ad i servizi e cambiano icona e colore a seconda dello stato degli stessi. Precedentemente tutti gli apparati della rete sono stati raggruppati per tipologia e rack di appartenenza, per poi essere suddivisi tra quelli che appartengono a SCoPE Pagina 90 di 148

93 Datacenter e quelli che appartengono invece a ATLAS Datacenter. Tutto questo lavoro di raggruppamento è stato fatto principalmente per poter essere utilizzato in Nagvis. Si parte da una mappa generale, visibile in figura 28, nella quale sono rappresentati tutte le tipologie di apparati: Storage Elements, Worker Nodes, Service Nodes, CMC, Switch, Router e UPS. Per alcuni di essi c'è la distinzione (L1 e L2) tra la locazione nel datacenter, come spiega la legenda in basso alla mappa. Per ogni tipologia c'è una icona che si riferisce al gruppo, ai suoi host e ai servizi attivi su essi. figura 28 : mappa principale visibile dalla home di tier2.na.infn.it Questa mappa è visualizzabile dalla home del portale di Liferay, raggiungibile dall'indirizzo tier2.na.infn.it. Pagina 91 di 148

94 L'obbiettivo è quello di visualizzare, da questa mappa, la stato generale dei servizi per ogni tipologia di apparato, in modo da inquadrare più velocemente il problema che si presenta. L'icona verde indica che tutti i servizi relativi a quella tipologia restituiscono uno stato di OK. L'icona gialla indica che almeno un servizio di quella tipologia restituisce un warning. L'icona rossa indica che almeno un servizio di quella tipologia restituisce lo stato critical. L'icone grigia invece indica che almeno un servizio restituisce lo stato unknown. Portando il puntatore del mouse su una di queste icone, si visualizza un elenco (ridotto) degli apparati che fanno parte di quella tipologia, con il relativo stato del host, stato del servizio e numero dei servizi che sono in quello stato, come si vede in figura 29. Pagina 92 di 148

95 figura 29 : mappa principale, sommario servizi sui Service Node Questa mappa è stata resa anche navigabile. Selezionando infatti una delle icone, si accede ad una mappa più dettagliata nella quale sono visibili i singoli apparati all'interno dei rack. Nella figura 30 c'è la mappa dei Service Node. Quasi tutte le icone visibili nella mappa generale sono navigabili nel dettaglio. Anche nella legenda sotto a questo riquadro ci sono 2 icone navigabili, che si riferiscono però a tutti gli apparati del datacenter di SCoPE e di ATLAS. Quindi, in Centreon, sono stati creati anche questi due gruppi. Non sono navigabili invece le icone degli UPS. Nella mappa dettagliata ci sono altre icone, questa volta si riferiscono al singolo host. Passando il mouse su queste icone si vede, in dettaglio, lo stato di tutti i servizi attivi su quel host più altre informazioni generali sullo stato del host. Nella figura 30 c'è il dettaglio dei servizi per atlasce01. Pagina 93 di 148

96 figura 30 : mappa nel dettaglio dei Service Node Si può ancora scendere nel dettaglio selezionando il singolo host. In questo caso si accede direttamente alla Web Management dell'apparato. Si apre in una nuova pagina la home della web management con la schermata di autenticazione. Nella figura seguente la Web Management di atlasce01. Pagina 94 di 148

97 figura 31 : web management di atlasce01 Queste mappe costituiscono l'obiettivo finale del lavoro di tesi e sono da considerarsi il risultato finale di tutto il lavoro fatto con NAGIOS, NRPE e Centreon. I precedenti capitoli infatti descrivono tutto il lavoro che c'è dietro. Le mappe sono state ottenute con una procedura che viene spiegata dettagliatamente nei prossimi paragrafi. In questo capitolo vengono illustrate solo alcune mappe allo scopo di spiegare il risultato ottenuto e i passi necessari per ottenerlo. Tutte le mappe sono incluse nel capitolo dell'appendice. Pagina 95 di 148

98 6.1. Inserire una mappa Per la creazione di una mappa con Nagvis si deve partire da una base, una immagine png esterna da importare in Nagvis. Le immagini delle mappe generali, visualizzabili entrando nel dettaglio dalla legenda in basso, sono state create per un'altra tesi (Un sistema di monitoraggio per una rete ad alte prestazioni e ad alte affidabilità). Quindi il lavoro è stato fatto con l'ausilio di queste mappe. Da queste mappe sono state create infatti quelle specifiche per ogni tipologia di apparato. Per importare una mappa in Nagvis è necessario fare 2 operazioni: La prima operazione è quella di caricare, sul server di tier2-nagios, l'immagine in formato png. La seconda operazione è invece quella di creare, per ogni immagine, un file di configurazione omonimo con estensione cfg. Le immagini png sono tutte della stessa risoluzione (900x704) tranne quella principale nella home. I file png devono essere caricati su tier2-nagios, nella directory: /usr/share/nagios/nagvis/nagvis/images/maps/ Inserito questo file png nella directory delle mappe, si deve creare un file di configurazione nella directory: /usr/share/nagios/nagvis/etc/maps/ Carichiamo per esempio l'immagine Tier2_INFN_SN.png, quella utilizzata per la mappa della figura 30. Nel percorso per i file di configurazione delle mappe si deve creare un file Tier2_INFN_SN.cfg. Questo file, inizialmente vuoto, deve avere una struttura iniziale definita così: define global { Pagina 96 di 148

99 allowed_user=everyone allowed_for_config=everyone iconset=std_medium map_image=tier2_infn_sn.png Qui si devono specificare gli utenti che possono visualizzare e modificare la mappa, la grandezza dell'icona e il file png di riferimento. Sono sufficienti queste poche informazioni per creare una mappa. La mappa ovviamente è inizialmente vuota e mostra semplicemente l'immagine png. Per accedere alla mappa tramite Nagvis e modificarla si può andare direttamente all'indirizzo: Da qui si può, con il tasto destro del mouse, aprire una delle mappe caricate, per esempio, Tier2_INFN_SN, della quale è stato creato il file di configurazione precedentemente. Pagina 97 di 148

100 6.2. Editor di mappe Come si è visto nel paragrafo precedente, per creare una mappa sono sufficienti poche righe di codice nel suo file di configurazione, per specificare il nome della mappa e il nome del file png. Questo file di configurazione però corrisponde a quello di una mappa vuota. Aggiungendo oggetti sulla mappa, per ogni oggetto, viene creata una nuova struttura all'interno del file. Si parla di oggetti da aggiungere alla mappa, definiamo quindi cosa sono questi oggetti. Ci sono 3 tipologie di oggetti che si possono aggiungere: icone, line e oggetti speciali. Per adesso gli oggetti speciali sono solo due: campi di testo e pulsanti di collegamento. I pulsanti di collegamento possono (e vengono) utilizzati come pulsanti utili per tornare alla pagina precedente. Questi pulsanti sono stati aggiunti su ogni mappa, di fianco al titolo in alto, e hanno una forma a freccia, indirizzata verso sinistra, che sta ad indicare appunto la sua funzionalità. Nella figura 32 si può vedere come è fatto questo pulsante. Ogni volta che si aggiunge un oggetto, questo inizialmente prende dimensioni, aspetto e funzionalità di default. Passando con il mouse sull'oggetto in questione, compare un menù con un elenco di tutti i parametri modificabili dell'oggetto e con due possibili opzioni: eliminare l'oggetto e modificarlo. I parametri dipendono dal tipo di oggetto creato. Cliccando su modifica si possono ovviamente modificare tutti i parametri e personalizzare quindi l'oggetto. I parametri già personalizzati sono quelli evidenziati in nero, sotto la voce Configured. Quelli grigi invece hanno i valori di default e si trovano sotto la voce Inherited. Di seguito il menù per il tasto che porta alla pagina precedente: Pagina 98 di 148

101 figura 32 : parametri per gli oggetti Questo tipo di oggetto è chiamato Shape. Come detto la creazione di questo oggetto genera una nuova struttura nel file di configurazione, che contiene solo i parametri Configured. Infatti, sotto quella inizialmente creata per il caricamento della mappa, c'è quella appena aggiunta: define shape { icon=b-dietro.png x=677 y=5 url=index.php?map=atlas Qui possiamo notare 4 parametri. Il primo è l'immagine png utilizzata per questo collegamento, immagine aggiunta successivamente quindi non di default. Il secondo e il terzo parametro indicano la posizione del pulsante sullo schermo. Pagina 99 di 148

102 L'ultimo parametro invece il collegamento del pulsante. In questo caso è stata scelta la mappa principale. Da questo si può fare una considerazione. Se si può aggiungere un oggetto graficamente personalizzandolo e si crea così una nuova voce nel file di configurazione, allora si può anche l'opposto. Si può aggiungere direttamente la voce nel file di configurazione e vedere così, graficamente l'oggetto creato. L'altra tipologia di oggetto utilizzata, come si è visto nelle figure 28,29 e 30, sono le icone. Le icone possono far riferimento ad un Host, Servizio, gruppo di Host, gruppo di Servizi e Mappa. L'icona di Host, la più usata in questo lavoro, oltre a mostrare le informazioni generali sullo stato del host, mostra anche un sommario sullo stato dei servizi ed un elenco con tutti i servizi con relativo stato e output. Icone per host sono tutte quelle della figura 30, nella quale si vede lo stato dei servizi della macchina atlasce01. Nella figura 29 invece si vedono tutte le icone di gruppi di Host. Anche le due icone della legenda (figura 28) sono riferite a gruppi di host. Le icone degli UPS sono icone di host. Quella invece in alto è una icona del tipo mappa. L'unica icona non utilizzata è quella per i singoli servizi. Si è visto nel dettaglio l'oggetto special di tipo Shape. L'oggetto icon di tipo Host ha molti parametri in più che possono essere modificati. Nella figura 33 si vedono i parametri per la Icon Host di atlasce01 Pagina 100 di 148

103 figura 32 : parametri dell'icona di atlasce01 Vediamo anche cosa viene aggiunto nel file di configurazione: address=http://atlasce01.na.infn.it host_name=atlasce01.na.infn.it x=592 y=320 Pagina 101 di 148

Tutto quello di cui un amministratore di sistema necessita

Tutto quello di cui un amministratore di sistema necessita NAGIOS: Una rete sotto controllo Parte 1: Installazione e configurazione Controllare e monitorare adeguatamente un sistema informativo non è mai molto semplice, ma con Nagios è possibile farlo anche nel

Dettagli

GFI Product Manual. ReportPack

GFI Product Manual. ReportPack GFI Product Manual ReportPack http://www.gfi.com info@gfi.com Le informazioni contenute nel presente documento sono soggette a modifiche senza preavviso. Salvo se indicato diversamente, le società, i nomi

Dettagli

Installazione e guida introduttiva. Per WebReporter 2012

Installazione e guida introduttiva. Per WebReporter 2012 Per WebReporter 2012 Ultimo aggiornamento: 13 settembre, 2012 Indice Installazione dei componenti essenziali... 1 Panoramica... 1 Passo 1 : Abilitare gli Internet Information Services... 1 Passo 2: Eseguire

Dettagli

NAL DI STAGING. Versione 1.0

NAL DI STAGING. Versione 1.0 NAL DI STAGING Versione 1.0 14/10/2008 Indice dei Contenuti 1. Introduzione... 3 2. Installazione NAL di staging... 3 VMWare Server... 3 Preistallazione su server linux... 6 Preinstallazione su server

Dettagli

Introduzione ai servizi di Linux

Introduzione ai servizi di Linux Introduzione ai servizi di Linux Premessa Adios è un interessante sistema operativo Linux basato sulla distribuzione Fedora Core 6 (ex Red Hat) distribuito come Live CD (con la possibilità di essere anche

Dettagli

BIMPublisher Manuale Tecnico

BIMPublisher Manuale Tecnico Manuale Tecnico Sommario 1 Cos è BIMPublisher...3 2 BIM Services Console...4 3 Installazione e prima configurazione...5 3.1 Configurazione...5 3.2 File di amministrazione...7 3.3 Database...7 3.4 Altre

Dettagli

CORSO WEB SERVER, DBMS E SERVER FTP

CORSO WEB SERVER, DBMS E SERVER FTP CORSO WEB SERVER, DBMS E SERVER FTP DISPENSA LEZIONE 1 Autore D. Mondello Transazione di dati in una richiesta di sito web Quando viene effettuata la richiesta di un sito Internet su un browser, tramite

Dettagli

Manuale LiveBox WEB ADMIN. http://www.liveboxcloud.com

Manuale LiveBox WEB ADMIN. http://www.liveboxcloud.com 2014 Manuale LiveBox WEB ADMIN http://www.liveboxcloud.com LiveBox Srl non rilascia dichiarazioni o garanzie in merito al contenuto o uso di questa documentazione e declina qualsiasi garanzia espressa

Dettagli

Mash Up applicativo con l'opensource per l'accesso ai servizi aziendali

Mash Up applicativo con l'opensource per l'accesso ai servizi aziendali Mash Up applicativo con l'opensource per l'accesso ai servizi aziendali Marco Celotti m.celotti@tecnoteca.com Davide Pavan - d.pavan@tecnoteca.com 2 Mashup applicativo Una esigenza aziendale sempre più

Dettagli

Manuale LiveBox WEB ADMIN. http://www.liveboxcloud.com

Manuale LiveBox WEB ADMIN. http://www.liveboxcloud.com 2014 Manuale LiveBox WEB ADMIN http://www.liveboxcloud.com LiveBox Srl non rilascia dichiarazioni o garanzie in merito al contenuto o uso di questa documentazione e declina qualsiasi garanzia espressa

Dettagli

Tekla Structures Guida dell'amministratore licenze. Versione del prodotto 21.1 settembre 2015. 2015 Tekla Corporation

Tekla Structures Guida dell'amministratore licenze. Versione del prodotto 21.1 settembre 2015. 2015 Tekla Corporation Tekla Structures Guida dell'amministratore licenze Versione del prodotto 21.1 settembre 2015 2015 Tekla Corporation Indice 1 Sistema di licenze Tekla Structures... 5 1.1 Lista di controllo consegne Tekla

Dettagli

Linux Day 2014. Network Monitoring. Nagios. Alessandro Costetti alle@costetti.it. Luca Ferrarini luca@ferrarini.info 25/10/2014

Linux Day 2014. Network Monitoring. Nagios. Alessandro Costetti alle@costetti.it. Luca Ferrarini luca@ferrarini.info 25/10/2014 Linux Day 2014 Network Monitoring Nagios Alessandro Costetti alle@costetti.it Luca Ferrarini luca@ferrarini.info 25/10/2014 Network Monitoring può essere definito come l insieme dei controlli che è necessario

Dettagli

Console di Amministrazione Centralizzata Guida Rapida

Console di Amministrazione Centralizzata Guida Rapida Console di Amministrazione Centralizzata Contenuti 1. Panoramica... 2 Licensing... 2 Panoramica... 2 2. Configurazione... 3 3. Utilizzo... 4 Gestione dei computer... 4 Visualizzazione dei computer... 4

Dettagli

Corso di Web programming Modulo T3 A2 - Web server

Corso di Web programming Modulo T3 A2 - Web server Corso di Web programming Modulo T3 A2 - Web server 1 Prerequisiti Pagine statiche e dinamiche Pagine HTML Server e client Cenni ai database e all SQL 2 1 Introduzione In questa Unità si illustra il concetto

Dettagli

FileMaker Pro 12. Guida di FileMaker Server

FileMaker Pro 12. Guida di FileMaker Server FileMaker Pro 12 Guida di FileMaker Server 2007 2012 FileMaker, Inc. Tutti i diritti riservati. FileMaker, Inc. 5201 Patrick Henry Drive Santa Clara, California 95054 FileMaker è un marchio di FileMaker,

Dettagli

Centro Nazionale per l Informatica nella Pubblica Amministrazione. Gara a procedura aperta n. 1/2007. per l appalto dei

Centro Nazionale per l Informatica nella Pubblica Amministrazione. Gara a procedura aperta n. 1/2007. per l appalto dei Centro Nazionale per l Informatica nella Pubblica Amministrazione Gara a procedura aperta n. 1/2007 per l appalto dei Servizi di rilevazione e valutazione sullo stato di attuazione della normativa vigente

Dettagli

Messa in esercizio, assistenza e aggiornamento di una Piattaform Open Source Liferay plug-in per ARPA

Messa in esercizio, assistenza e aggiornamento di una Piattaform Open Source Liferay plug-in per ARPA Messa in esercizio, assistenza e aggiornamento di una Piattaform Open Source Liferay plug-in per ARPA Pag. 1 di 16 Redatto da F. Fornasari, C. Simonelli, E. Croci (TAI) Rivisto da E.Mattei (TAI) Approvato

Dettagli

Acronis Backup Advanced Version 11.5 Update 6

Acronis Backup Advanced Version 11.5 Update 6 Acronis Backup Advanced Version 11.5 Update 6 SI APPLICA AI SEGUENTI PRODOTTI Advanced for Windows Server Advanced for PC Per Windows Server Essentials GUIDA INTRODUTTIVA Informazioni sul copyright Copyright

Dettagli

Informazioni generali sul corso

Informazioni generali sul corso abaroni@yahoo.com Informazioni generali sul corso Introduzione a BusinessObjects Enterprise XI - Release 2 Chi sono. Io? Adolfo Baroni E-mail: abaroni@yahoo.com 2 Pagina 1 Obiettivi del corso hamministrazione

Dettagli

Petra Provisioning Center, rel 3.1

Petra Provisioning Center, rel 3.1 Petra Provisioning Center, rel 3.1 Petra Provisioning Center, rel 3.1 Copyright 1996,2006Link s.r.l. 1 Questo documento contiene informazioni di proprietà riservata, protette da copyright. Tutti i diritti

Dettagli

Ambiente Virtuale Inclusivo per la Persona Autistica MANUALE OPERATORE. Release 1.0-13/10/09. Copyright Lynx 2009 http://www.lynxlab.

Ambiente Virtuale Inclusivo per la Persona Autistica MANUALE OPERATORE. Release 1.0-13/10/09. Copyright Lynx 2009 http://www.lynxlab. MANUALE OPERATORE Release 1.0-13/10/09 Copyright Lynx 2009 http://www.lynxlab.com Indice generale MANUALE OPERATORE...1 1.1 Definizioni...3 1.2 Ambienti...3 1.3 Release e copyright...3 2. Utenti...4 2.1

Dettagli

Istruzioni di installazione di IBM SPSS Modeler Server 15per UNIX

Istruzioni di installazione di IBM SPSS Modeler Server 15per UNIX Istruzioni di installazione di IBM SPSS Modeler Server 15per UNIX IBM SPSS Modeler Server può essere installato e configurato per l esecuzione in modalità di analisi distribuita insieme ad altre installazioni

Dettagli

WE500 APPLICATION NOTES GESTIONE DELLE ACQUE

WE500 APPLICATION NOTES GESTIONE DELLE ACQUE WE500 APPLICATION NOTES GESTIONE DELLE ACQUE 1 INTRODUZIONE I sistemi di telecontrollo ed il monitoraggio diventano sempre più importanti nell'ampliamento delle reti di distribuzione idrica ed in particolar

Dettagli

Manuale utente. ver 1.0 del 31/10/2011

Manuale utente. ver 1.0 del 31/10/2011 Manuale utente ver 1.0 del 31/10/2011 Sommario 1. Il Servizio... 2 2. Requisiti minimi... 2 3. L architettura... 2 4. Creazione del profilo... 3 5. Aggiunta di un nuovo dispositivo... 3 5.1. Installazione

Dettagli

Installazione Client/Server

Installazione Client/Server Installazione Client/Server Sommario 1. Moduli di BIM...3 2. Installazione della suite...5 3. Configurazione moduli...9 3.1. BIMVision / BIMReader...9 3.1.1. Configurazione file di amministrazione...9

Dettagli

Il programma di installazione per l'applicazione SanDisk +Cloud si trova sull'unità flash SanDisk.

Il programma di installazione per l'applicazione SanDisk +Cloud si trova sull'unità flash SanDisk. Installazione Il programma di installazione per l'applicazione SanDisk +Cloud si trova sull'unità flash SanDisk. Assicurarsi che il computer sia collegato ad internet. Successivamente, collegare l'unità

Dettagli

Internet Architettura del www

Internet Architettura del www Internet Architettura del www Internet è una rete di computer. Il World Wide Web è l insieme di servizi che si basa sull architettura di internet. In una rete, ogni nodo (detto host) è connesso a tutti

Dettagli

CONFIGURARE SAMBA 3 SU SUSE LINUX 9.1/9.2

CONFIGURARE SAMBA 3 SU SUSE LINUX 9.1/9.2 CONFIGURARE SAMBA 3 SU SUSE LINUX 9.1/9.2 1. INTRODUZIONE In questa guida si illustra la procedura di configurazione di samba 3 su SuSE Linux 9.1 e su SuSE Linux 9.2. Saranno brevemente illustrate le operazioni

Dettagli

DNNCenter. Installazione standard di DotNetNuke 5. per Windows Vista. Installazione Standard DotNetNuke 5 per Windows Vista

DNNCenter. Installazione standard di DotNetNuke 5. per Windows Vista. Installazione Standard DotNetNuke 5 per Windows Vista DNNCenter Installazione standard di DotNetNuke 5 per Windows Vista Copyright OPSI Srl www.opsi.it Pag. 1 of 28 INDICE 1. INTRODUZIONE... 3 1.1. Pre-requisiti... 3 2. DOWNLOAD DOTNETNUKE... 4 2.1. Download

Dettagli

Portale AOT Lab Guida all utilizzo

Portale AOT Lab Guida all utilizzo 2007 Progetto realizzato presso l Università degli Studi di Parma per i corsi di Sistemi Distribuiti e ad Agenti ( prof. A. Poggi ) e Sistemi Orientati ad Internet ( prof.ssa P. Turci ). longari@ce.unipr.it

Dettagli

Getting started. Creare una applicazione con supporto Web Server

Getting started. Creare una applicazione con supporto Web Server Getting started Creare una applicazione con supporto Web Server Revisioni del documento Data Edizione Commenti 10/03/2010 1.0 - Sielco Sistemi srl via Roma, 24 I-22070 Guanzate (CO) http://www.sielcosistemi.com

Dettagli

BitDefender Client Security e Soluzioni BitDefender Windows Server

BitDefender Client Security e Soluzioni BitDefender Windows Server BitDefender Client Security e Soluzioni BitDefender Windows Server Guida Rapida all'installazione Diritto d'autore 2010 BitDefender; 1. Panoramica dell'installazione Grazie per aver scelto le soluzioni

Dettagli

Il tuo manuale d'uso. F-SECURE PSB http://it.yourpdfguides.com/dref/2859693

Il tuo manuale d'uso. F-SECURE PSB http://it.yourpdfguides.com/dref/2859693 Può anche leggere le raccomandazioni fatte nel manuale d uso, nel manuale tecnico o nella guida di installazione di F-SECURE PSB. Troverà le risposte a tutte sue domande sul manuale d'uso (informazioni,

Dettagli

Guida introduttiva. Versione 7.0.0 Software

Guida introduttiva. Versione 7.0.0 Software Guida introduttiva Versione 7.0.0 Software Installazione del software - Sommario Panoramica sulla distribuzione del software CommNet Server Windows Windows Cluster - Virtual Server Abilitatore SNMP CommNet

Dettagli

Acronis Backup & Recovery 10 Server for Linux. Update 5. Manuale d'installazione

Acronis Backup & Recovery 10 Server for Linux. Update 5. Manuale d'installazione Acronis Backup & Recovery 10 Server for Linux Update 5 Manuale d'installazione Sommario 1 Prima dell'installazione... 3 1.1 Componenti di Acronis Backup & Recovery 10... 3 1.1.1 Agente per Linux... 3 1.1.2

Dettagli

NetEye Release Notes 2013

NetEye Release Notes 2013 NetEye Release Notes 2013 Version 3.4. Questo documento fornisce una panoramica sulle funzionalità e miglioramenti rilasciati con la nuova versione 3.4 di WÜRTHPHOENIX NetEye. Comandi più complessi per

Dettagli

Guida di Active System Console

Guida di Active System Console Guida di Active System Console Panoramica... 1 Installazione... 2 Visualizzazione delle informazioni di sistema... 4 Soglie di monitoraggio del sistema... 5 Impostazioni di notifica tramite e-mail... 5

Dettagli

Una soluzione per il Provisioning e la Software Distribution

Una soluzione per il Provisioning e la Software Distribution Una soluzione per il Provisioning e la Software Distribution Scenario Svariati server, con funzione in base all'area di competenza, dislocati nel territorio su Nodi Periferici collegati in rete (VPN) Un

Dettagli

Installazione di IBM SPSS Modeler 14.2 Client (licenza di rete)

Installazione di IBM SPSS Modeler 14.2 Client (licenza di rete) Installazione di IBM SPSS Modeler 14.2 Client (licenza di rete) Le seguenti istruzioni sono relative all installazione di IBM SPSS Modeler Client versione 14.2 con licenza di rete. Questo documento è stato

Dettagli

Manuale LiveBox WEB AMMINISTRATORE DI SISTEMA. http://www.liveboxcloud.com

Manuale LiveBox WEB AMMINISTRATORE DI SISTEMA. http://www.liveboxcloud.com 2015 Manuale LiveBox WEB AMMINISTRATORE DI SISTEMA http://www.liveboxcloud.com LiveBox Srl non rilascia dichiarazioni o garanzie in merito al contenuto o uso di questa documentazione e declina qualsiasi

Dettagli

Aggiornamento a edizioni avanzate di Acronis Backup & Recovery 11

Aggiornamento a edizioni avanzate di Acronis Backup & Recovery 11 Aggiornamento a edizioni avanzate di Acronis Backup & Recovery 11 Si applica alle seguenti edizioni: Advanced Server Virtual Edition Advanced Server SBS Edition Advanced Workstation Server for Linux Server

Dettagli

Programmabilità di rete con l'infrastruttura Cisco basata sulle applicazioni

Programmabilità di rete con l'infrastruttura Cisco basata sulle applicazioni White paper Programmabilità di rete con l'infrastruttura Cisco basata sulle applicazioni Panoramica Questo documento analizza il supporto alla programmabilità nell'infrastruttura ACI (Application Centric

Dettagli

SIDA Multisede online

SIDA Multisede online SIDA Multisede online Manuale tecnico per uso esclusivo dei tecnici installatori e della rete commerciale Sida By Autosoft Versione 2009.1.1 Revisione 1, 11 maggio 2009 Tutti i diritti sono riservati dagli

Dettagli

RRF Reply Reporting Framework

RRF Reply Reporting Framework RRF Reply Reporting Framework Introduzione L incremento dei servizi erogati nel campo delle telecomunicazioni implica la necessità di effettuare analisi short-term e long-term finalizzate a tenere sotto

Dettagli

License Service Manuale Tecnico

License Service Manuale Tecnico Manuale Tecnico Sommario 1. BIM Services Console...3 1.1. BIM Services Console: Menu e pulsanti di configurazione...3 1.2. Menù Azioni...4 1.3. Configurazione...4 1.4. Toolbar pulsanti...5 2. Installazione

Dettagli

Problematiche SimulAtlas e Flash Player

Problematiche SimulAtlas e Flash Player Problematiche SimulAtlas e Flash Player Requisiti di sistema SimulAtlas Per la corretta visualizzazione del SimulAtlas, assicuratevi che il vostro PC risponda ai seguenti requisiti: - Pentium III 800 MHz.

Dettagli

SICE.NET Servizio Informativo Casse Edili

SICE.NET Servizio Informativo Casse Edili SICE.NET Servizio Informativo Casse Edili http://213.26.67.117/ce_test Guida all uso del servizio Internet On-Line CASSA EDILE NUOVA INFORMATICA Software prodotto da Nuova Informatica srl Pag. 1 Il Servizio

Dettagli

Proteggi ciò che crei. Guida all avvio rapido

Proteggi ciò che crei. Guida all avvio rapido Proteggi ciò che crei Guida all avvio rapido 1 Documento aggiornato il 10.06.2013 Tramite Dr.Web CureNet! si possono eseguire scansioni antivirali centralizzate di una rete locale senza installare il programma

Dettagli

Manuale Utente Archivierete Novembre 2008 Pagina 2 di 17

Manuale Utente Archivierete Novembre 2008 Pagina 2 di 17 Manuale utente 1. Introduzione ad Archivierete... 3 1.1. Il salvataggio dei dati... 3 1.2. Come funziona Archivierete... 3 1.3. Primo salvataggio e salvataggi successivi... 5 1.4. Versioni dei salvataggi...

Dettagli

Novell Vibe 3.3. Novell. 5 giugno 2012. Riferimento rapido. Avvio di Novell Vibe

Novell Vibe 3.3. Novell. 5 giugno 2012. Riferimento rapido. Avvio di Novell Vibe Novell Vibe 3.3 5 giugno 2012 Novell Riferimento rapido Quando si inizia a utilizzare il software Novell Vibe, è innanzitutto necessario configurare lo spazio di lavoro personale e creare uno spazio di

Dettagli

AdRem Free itools 2006. - L importanza degli strumenti di diagnostica -

AdRem Free itools 2006. - L importanza degli strumenti di diagnostica - AdRem Free itools 2006 - L importanza degli strumenti di diagnostica - Introduzione La capacità di configurare, gestire e risolvere i problemi relativi alle reti TCP/IP è parte fondamentale dell attività

Dettagli

Versione 1.0 gennaio 2011. Xerox Phaser 3635MFP Extensible Interface Platform

Versione 1.0 gennaio 2011. Xerox Phaser 3635MFP Extensible Interface Platform Versione 1.0 gennaio 2011 Xerox Phaser 3635MFP 2011 Xerox Corporation. XEROX e XEROX and Design sono marchi di Xerox Corporation negli Stati Uniti e/o in altri paesi. Questo documento è soggetto a modifiche

Dettagli

Sophos Endpoint Security and Control Guida di avvio per computer autonomi

Sophos Endpoint Security and Control Guida di avvio per computer autonomi Sophos Endpoint Security and Control Guida di avvio per computer autonomi Sophos Endpoint Security and Control versione 9 Sophos Anti-Virus per Mac OS X, versione 7 Data documento: ottobre 2009 Sommario

Dettagli

Guida Moderatori e Conduttori

Guida Moderatori e Conduttori STEP ONE: Login to OnSync Guida Moderatori e Conduttori Guida Moderat ori e Condutt ori pag. Ultimo aggiornamento 10/2012 STEP ONE: Login to OnSync Cap. I - Quick Start Guide Guida Moderat ori e Condutt

Dettagli

Manuale TeamViewer Manager 6.0

Manuale TeamViewer Manager 6.0 Manuale TeamViewer Manager 6.0 Revisione TeamViewer 6.0-954 Indice 1 Panoramica... 2 1.1 Informazioni su TeamViewer Manager... 2 1.2 Informazioni sul presente Manuale... 2 2 Installazione e avvio iniziale...

Dettagli

VERITAS Backup Exec 9.1 for Windows Servers Manuale di installazione rapida

VERITAS Backup Exec 9.1 for Windows Servers Manuale di installazione rapida VERITAS Backup Exec 9.1 for Windows Servers Manuale di installazione rapida N109548 Dichiarazione di non responsabilità Le informazioni contenute nella presente pubblicazione sono soggette a modifica senza

Dettagli

Archiviare messaggi da Microsoft Exchange 2003

Archiviare messaggi da Microsoft Exchange 2003 Archiviare messaggi da Microsoft Exchange 2003 Nota: Questo tutorial si riferisce specificamente all'archiviazione da Microsoft Exchange 2003. Si dà come presupposto che il lettore abbia già installato

Dettagli

Monitoraggio e gestione dell IDoc per i sistemi SAP

Monitoraggio e gestione dell IDoc per i sistemi SAP Libelle EDIMON Monitoraggio e gestione dell IDoc per i sistemi SAP Versione documento: 3.0 Un operazione IDoc correttamente funzionante e senza interruzioni è una parte essenziale dell esecuzione dei processi

Dettagli

Virtualizzazione e Network management

Virtualizzazione e Network management Open Source per le infrastrutture IT aziendali Virtualizzazione e Network management Marco Vanino Spin S.r.l. Servizi IT aziendali File/Printer Server ERP CRM EMail Doc Mgmt Servizi IT aziendali File/Printer

Dettagli

Intel Server Management Pack per Windows

Intel Server Management Pack per Windows Intel Server Management Pack per Windows Manuale dell'utente Revisione 1.0 Dichiarazioni legali LE INFORMAZIONI CONTENUTE IN QUESTO DOCUMENTO SONO FORNITE IN ABBINAMENTO AI PRODOTTI INTEL ALLO SCOPO DI

Dettagli

LEZIONE 3. Il pannello di amministrazione di Drupal, configurazione del sito

LEZIONE 3. Il pannello di amministrazione di Drupal, configurazione del sito LEZIONE 3 Il pannello di amministrazione di Drupal, configurazione del sito Figura 12 pannello di controllo di Drupal il back-end Come già descritto nella lezione precedente il pannello di amministrazione

Dettagli

Istruzioni di installazione di IBM SPSS Modeler Server 15per Windows

Istruzioni di installazione di IBM SPSS Modeler Server 15per Windows Istruzioni di installazione di IBM SPSS Modeler Server 15per Windows IBM SPSS Modeler Server può essere installato e configurato per l esecuzione in modalità di analisi distribuita insieme ad altre installazioni

Dettagli

Guida rapida alle Istruzioni per l'uso

Guida rapida alle Istruzioni per l'uso RICOH TotalFlow Print Manager Guida rapida alle Istruzioni per l'uso Guida rapida Version 3.0.0 Per le informazioni non presenti in questo manuale, fare riferimento alla Guida del prodotto in uso. Leggere

Dettagli

CA ARCserve Backup Patch Manager per Windows

CA ARCserve Backup Patch Manager per Windows CA ARCserve Backup Patch Manager per Windows Guida per l'utente r16.5 La presente documentazione, che include il sistema di guida in linea integrato e materiale distribuibile elettronicamente (d'ora in

Dettagli

Installazione del software - Sommario

Installazione del software - Sommario Guida introduttiva Installazione del software - Sommario Panoramica sulla distribuzione del software CommNet Server Windows Cluster Windows - Virtual Server CommNet Agent Windows Cluster Windows - Virtual

Dettagli

Istruzioni di installazione di Intel Utilities

Istruzioni di installazione di Intel Utilities Istruzioni di installazione di Intel Utilities Queste istruzioni spiegano come installare Intel Utilities dal CD n. 1 di Intel System Management Software (per i due CD della versione solo in inglese) o

Dettagli

Progettazione: Tecnologie e ambienti di sviluppo

Progettazione: Tecnologie e ambienti di sviluppo Contratto per l acquisizione di servizi di Assistenza specialistica per la gestione e l evoluzione del patrimonio software della Regione Basilicata. Repertorio n. 11016 del 25/09/2009 Progettazione: Tecnologie

Dettagli

Web Intelligence. Argomenti 10/5/2010. abaroni@yahoo.com

Web Intelligence. Argomenti 10/5/2010. abaroni@yahoo.com Web Intelligence Argomenti Cap.1 Introduzione Cap.2 Creazione/Modifica di QUERY (semplici,custom,unioni) Cap.3 Uso dei Filtri e delle Condizioni Slide 2 - Copyright 2007 Business Objects SA - All Rights

Dettagli

Realizzazione di un cluster Condor su macchine virtuali

Realizzazione di un cluster Condor su macchine virtuali Realizzazione di un cluster Condor su macchine virtuali Davide Petturiti Sistemi Operativi Avanzati Prof. Osvaldo Gervasi A.A. 2007/2008 Corso di Laurea Specialistica in Informatica Facoltà di Scienze

Dettagli

Titolo Perché scegliere Alfresco. Titolo1 ECM Alfresco

Titolo Perché scegliere Alfresco. Titolo1 ECM Alfresco Titolo Perché scegliere Alfresco Titolo1 ECM Alfresco 1 «1» Agenda Presentazione ECM Alfresco; Gli Strumenti di Alfresco; Le funzionalità messe a disposizione; Le caratteristiche Tecniche. 2 «2» ECM Alfresco

Dettagli

CONTENT MANAGEMENT SYSTEM

CONTENT MANAGEMENT SYSTEM CONTENT MANAGEMENT SYSTEM P-2 PARLARE IN MULTICANALE Creare un portale complesso e ricco di informazioni continuamente aggiornate, disponibile su più canali (web, mobile, iphone, ipad) richiede competenze

Dettagli

UBUNTU: gli strumenti di condivisione risorse

UBUNTU: gli strumenti di condivisione risorse UBUNTU: gli strumenti di condivisione risorse condivisione 1o1 a cura di Danio Campolunghi La condivisione di risorse Verranno qui proposti gli strumenti grafici di serie messi a disposizione da Ubuntu

Dettagli

Guida dell'amministratore di JMP 8 alle versioni con licenza annuale per Windows, Macintosh e Linux

Guida dell'amministratore di JMP 8 alle versioni con licenza annuale per Windows, Macintosh e Linux Guida dell'amministratore di JMP 8 alle versioni con licenza annuale per Windows, Macintosh e Linux Gli estremi corretti per la citazione bibliografica di questo manuale sono i seguenti: SAS Institute

Dettagli

Servizi remoti Xerox Un passo nella giusta direzione

Servizi remoti Xerox Un passo nella giusta direzione Servizi remoti Xerox Un passo nella giusta direzione Diagnosi dei problemi Valutazione dei dati macchina Problemi e soluzioni Garanzia di protezione del cliente 701P41696 Descrizione generale di Servizi

Dettagli

Software della stampante

Software della stampante Software della stampante Informazioni sul software della stampante Il software Epson comprende il software del driver per stampanti ed EPSON Status Monitor 3. Il driver per stampanti è un software che

Dettagli

Note legali. Marchi di fabbrica. 2013 KYOCERA Document Solutions Inc.

Note legali. Marchi di fabbrica. 2013 KYOCERA Document Solutions Inc. Note legali È proibita la riproduzione, parziale o totale, non autorizzata di questa Guida. Le informazioni contenute in questa guida sono soggette a modifiche senza preavviso. Si declina ogni responsabilità

Dettagli

Approfondimenti tecnici su framework v6.3

Approfondimenti tecnici su framework v6.3 Sito http://www.icu.fitb.eu/ pagina 1 I.C.U. "I See You" Sito...1 Cosa è...3 Cosa fa...3 Alcune funzionalità Base:...3 Alcune funzionalità Avanzate:...3 Personalizzazioni...3 Elenco Moduli base...4 Elenco

Dettagli

Articolo di spiegazione FileMaker Replica di un ambiente di autenticazione esterna per lo sviluppo

Articolo di spiegazione FileMaker Replica di un ambiente di autenticazione esterna per lo sviluppo Articolo di spiegazione FileMaker Replica di un ambiente di autenticazione esterna per lo sviluppo Pagina 1 Replica di un ambiente di autenticazione esterna per lo sviluppo La sfida Replicare un ambiente

Dettagli

Installazione ed attivazione della "SUITE OFFIS" versione SERVER

Installazione ed attivazione della SUITE OFFIS versione SERVER Installazione ed attivazione della "SUITE OFFIS" versione SERVER Premessa La versione server di OFFIS può essere installata e utilizzata indifferentemente da PC/Win o Mac/Osx e consente l'accesso contemporaneo

Dettagli

Modulo 8. Strumenti di produzione Strumenti. Gli strumenti più utilizzati per produrre pagine Web sono essenzialmente due:

Modulo 8. Strumenti di produzione Strumenti. Gli strumenti più utilizzati per produrre pagine Web sono essenzialmente due: Pagina 1 di 6 Strumenti di produzione Strumenti Gli strumenti più utilizzati per produrre pagine Web sono essenzialmente due: 1. Netscape Composer, gratuito e scaricabile da netscape.org assieme al browser

Dettagli

Server E-Map. Installazione del Server E-Map. Finestra del Server E-Map

Server E-Map. Installazione del Server E-Map. Finestra del Server E-Map Manuale d uso per i programmi VS Server E-Map Con E-Map Server, si possono creare mappe elettroniche per le telecamere ed i dispositivi I/O collegati a GV-Video Server. Usando il browser web, si possono

Dettagli

Gestione sistemi - Advanced Job Scheduler

Gestione sistemi - Advanced Job Scheduler Sistemi IBM - iseries Gestione sistemi - Advanced Job Scheduler Versione 5 Release 4 Sistemi IBM - iseries Gestione sistemi - Advanced Job Scheduler Versione 5 Release 4 Nota Prima di utilizzare le presenti

Dettagli

Creazione di una Azure Web App

Creazione di una Azure Web App Creazione di una Azure Web App Introduzione Oggi le aziende hanno sempre più la necessità di avere uno strumento per interagire con i propri clienti. La presenza sul web dell azienda diventa sempre di

Dettagli

Controllo remoto di SPEEDY

Controllo remoto di SPEEDY UNIVERSITÀ DI BRESCIA FACOLTÀ DI INGEGNERIA Dipartimento di Elettronica per l Automazione Laboratorio di Robotica Avanzata Advanced Robotics Laboratory Corso di Robotica (Prof. Riccardo Cassinis) Controllo

Dettagli

CORSO LINUX Sul Sistema RedHat Installazione Nagios Versione 1.0

CORSO LINUX Sul Sistema RedHat Installazione Nagios Versione 1.0 CORSO LINUX Sul Sistema RedHat Installazione Nagios Versione 1.0 Presentazione di: Ing. Introduzione a Nagios Situazione sotto controllo OpenSource e programmi affidabili Realtà distribuita Plugins e programmi

Dettagli

Chi ha già scelto nel mondo la nostra soluzione

Chi ha già scelto nel mondo la nostra soluzione InterMapper è un software di Network Monitoring, pensato per analizzare il traffico di rete. Le reti sono in continua evoluzione ed InterMapper rende la loro gestione più facile. Il monitoraggio, la mappatura

Dettagli

2009. STR S.p.A. u.s. Tutti i diritti riservati

2009. STR S.p.A. u.s. Tutti i diritti riservati 2009. STR S.p.A. u.s. Tutti i diritti riservati Sommario COME INSTALLARE STR VISION CPM... 3 Concetti base dell installazione Azienda... 4 Avvio installazione... 4 Scelta del tipo Installazione... 5 INSTALLAZIONE

Dettagli

Archiviare messaggi da Microsoft Office 365

Archiviare messaggi da Microsoft Office 365 Archiviare messaggi da Microsoft Office 365 Nota: Questo tutorial si riferisce specificamente all'archiviazione da Microsoft Office 365. Si dà come presupposto che il lettore abbia già installato MailStore

Dettagli

Software Intel per la gestione di sistemi. Manuale dell'utente di Intel Modular Server Management Pack

Software Intel per la gestione di sistemi. Manuale dell'utente di Intel Modular Server Management Pack Software Intel per la gestione di sistemi Manuale dell'utente di Intel Modular Server Management Pack Dichiarazioni legali LE INFORMAZIONI CONTENUTE IN QUESTO DOCUMENTO SONO FORNITE IN ABBINAMENTO AI PRODOTTI

Dettagli

Novell ZENworks Configuration Management in ambiente Microsoft * Windows *

Novell ZENworks Configuration Management in ambiente Microsoft * Windows * Guida GESTIONE SISTEMI www.novell.com Novell ZENworks Configuration Management in ambiente Microsoft * Windows * Novell ZENworks Configuration Management in ambiente Microsoft Windows Indice: 2..... Benvenuti

Dettagli

Symantec Backup Exec 12.5 for Windows Servers. Guida rapida all'installazione

Symantec Backup Exec 12.5 for Windows Servers. Guida rapida all'installazione Symantec Backup Exec 12.5 for Windows Servers Guida rapida all'installazione 13897290 Installazione di Backup Exec Il documento contiene i seguenti argomenti: Requisiti di sistema Prima dell'installazione

Dettagli

List Suite 2.0. Sviluppo Software Il Telefono Sas 10/06/2010

List Suite 2.0. Sviluppo Software Il Telefono Sas 10/06/2010 2010 List Suite 2.0 Sviluppo Software Il Telefono Sas 10/06/2010 List Suite 2.0 List Suite 2.0 è un tool software in grado di archiviare, analizzare e monitorare il traffico telefonico, effettuato e ricevuto

Dettagli

Convertitore PDF (WSO2PDF) Manuale Sistemista

Convertitore PDF (WSO2PDF) Manuale Sistemista Convertitore PDF (WSO2PDF) Manuale Sistemista Pagina 1 di 12 SOMMARIO 1 Introduzione 3 2 Moduli dell applicazione 3 3 Installazione 4 3.1 Installazione da Setup Manager 4 3.2 Installazione da pacchetto

Dettagli

Guida rapida dell'utente di Polycom RealPresence Content Sharing Suite

Guida rapida dell'utente di Polycom RealPresence Content Sharing Suite Guida rapida dell'utente di Polycom RealPresence Content Sharing Suite Versione 1.2 3725-69878-001 Rev. A Novembre 2013 In questa guida, vengono fornite le istruzioni per condividere e visualizzare il

Dettagli

TeamViewer 9 Manuale Manager

TeamViewer 9 Manuale Manager TeamViewer 9 Manuale Manager Rev 9.1-03/2014 TeamViewer GmbH Jahnstraße 30 D-73037 Göppingen teamviewer.com Panoramica Indice Indice... 2 1 Panoramica... 4 1.1 Informazioni su TeamViewer Manager... 4 1.2

Dettagli

Impostazione di Scansione su e-mail

Impostazione di Scansione su e-mail Guida rapida all'impostazione delle funzioni di scansione XE3024IT0-2 Questa guida contiene istruzioni per: Impostazione di Scansione su e-mail a pagina 1 Impostazione di Scansione su mailbox a pagina

Dettagli

IBM SPSS Modeler Social Network Analysis 16 Guida all'installazione e alla configurazione

IBM SPSS Modeler Social Network Analysis 16 Guida all'installazione e alla configurazione IBM SPSS Modeler Social Network Analysis 16 Guida all'installazione e alla configurazione Indice Capitolo 1. Introduzione a IBM SPSS Modeler Social Network Analysis.... 1 Panoramica di IBM SPSS Modeler

Dettagli