<- Ritorniamo... - Indice Generale - Copertina - flex: Fast Lexical Analyzer -> |
Sistemi Liberi
Monitoraggio di sistemi - Parte 5: l'inventarioDopo aver affrontato il modo per monitorare i guasti in rete e dopo aver capito come effettuare le misure sulla stessa, affrontiamo il problema della gestione delle sue risorse. |
Negli ultimi quattro numeri del PLUTO Journal ho illustrato vari sistemi atti al monitoraggio della rete, al fine della individuazione dei guasti o della rilevazione di misure sulla stessa. La gestione dei sistemi informativi di una azienda, nella sua accezione più ampia, deve però includere anche altre modalità di monitoraggio delle risorse, sia ai fini di una localizzazione rapida delle stesse, sia per necessità di tipo amministrativo, sia per ottimizzarne lo sfruttamento.
Tali attività vengono solitamente indicate con il termine
inglese di inventory, che può essere letteralmente tradotto in
italiano come inventario. Lo scopo è, appunto, di inventariare
le risorse: PC, server, stampanti, apparecchiature varie, con le
loro caratteristiche e l'eventuale software in esse contenuto. Se
possibile, è utile che tali elenchi vengano mantenuti
allineati con l'elenco degli utilizzatori di ciascuna risorsa in modo
quanto più possibile automatico.
A tale scopo si
utilizzano, per le apparecchiature collegate in rete, dei software
che automatizzano il più il processo di raccolta e
aggiornamento di tali informazioni e che conservano tali dati in un
database per future consultazioni e analisi: è proprio di uno di
tali software che andremo a parlare.
Il contesto operativo che verrà descritto è quello comune a molte aziende italiane nelle quali si opera all'interno di un Dominio con un Primary Domain Controller con Sistema Operativo (S.O.) Microsoft. La maggior parte dei client sono dotati di un S.O. dello stesso produttore (i client Open Source sono quasi sempre una minoranza, quando non sono addirittura assenti) e vi sono una serie di server aggiuntivi, quasi sempre con S.O. Open Source (molto spesso GNU/Linux), che sono in genere server applicativi. Chiudono l'elenco una serie di dispositivi di rete quali ad esempio stampanti, switch, print server, firewall, etc.
Il primo programma provato, H-Inventory,
pur avendo maggiori funzionalità di gestione e migliori
report (rispetto allo strumento scelto) non permette di
personalizzare "al volo" la home page, e una delle nostre
necessità era che gli indirizzi IP dei computer inventariati
fossero immediatamente disponibili. Inoltre H-Inventory prevede la
rilevazione/trasmissione dei dati tramite condivisione di una
cartella (smb) sul server o via FTP. Entrambi i servizi non erano e
non sono disponibili nella macchina da noi prescelta per
l'installazione del server di amministrazione e questo ha contribuito
a far scegliere OCSInventory NG come alternativa.
OCSInventory
NG ovvero Open Computer and Software Inventory Next Generation è
un programma distribuito sotto licenza GPL v2 che permette di
inventariare i computer della rete raccogliendo informazioni
sull'hardware, sul sistema operativo e sul software installato, di
distribuire software e di esplorare la rete alla ricerca di
dispositivi.
Prevede un'architettura client-server con un server centrale di
raccolta dati (di fatto un server web) e un programma detto Agent che
gira come servizio sui client.
Per
il server i prerequisiti richiesti sono: un web-server Apache
(v.1.3.33 o maggiore) con supporto a PHP (v.4.3.2 o maggiore) e MySQL
4.1.0 (o successiva) oltre ad un certo numero di moduli PERL come da
manuale di installazione.
L'installazione (dopo avere soddisfatto
le dipendenze) consiste semplicemente nel decomprimere il file
.tar.gz in una directory del server web (nel percorso del server HTTP
ovviamente): nel nostro esempio il file è stato decompresso
nella web-root e la directory si chiama ocsreports. Fatto questo ci
si porta all'interno di essa e si richiama il programma setup.sh. Il
tutto è descritto in maniera chiara nel manuale,
per cui ritengo opportuno evitare di riscrivere questi passaggi.
Dopo l'installazione in un browser digitate l'indirizzo della directory nella quale avete eseguito l'installazione (nell'esempio: http://miositoweb/ocsreport/) e vi verrà richiesto di autenticarvi con login e password prescelti.
Una volta loggati vi si aprirà la finestra principale nella
quale ovviamente non è ancora riportato alcun dato:
Per trasmettere i dati di inventario dalla workstation al server, OCSInventory usa un programma agent. Esistono agent sia per Windows che per Linux.
Visto che uno degli obiettivi, di
questo tipo di gestione, è quello di ridurre al minimo le
operazioni manuali, sono state previste varie modalità per la
distribuzione degli agent, evitando di dover effettuare
l'installazione su ogni singolo computer.
Per l'installazione
dell'agent in un dominio con un Primary Domain Controller Microsoft,
la modalità più semplice è depositare il
programma di installazione in una cartella condivisa e poi lanciare
dallo script di logon l'apposito programma OcsLogon.exe che eseguirà
l'installazione. Tale programma va preventivamente rinominato con il
nome canonico del server sul quale risiede il programma di
amministrazione o con il suo indirizzo IP. Ad esempio, ipotizzando di
avere il programma di amministrazione installato, sul server,
all'indirizzo 172.20.1.4 il programma OcsLogon.exe verrà
rinominato in 172.20.1.4.exe ed il comando da inserire nello script
di login sarà qualcosa tipo
"\\server\shared_dir\172.20.1.4.exe /DEBUG /NP /INSTALL" |
I parametri in coda hanno il seguente significato:
/DEBUG=
traccia su un file le operazioni eseguite (utile in caso di problemi)
/NP=
impone di non utilizzare il proxy della connessione HTTP (si suppone che il server di amministrazione sia in rete locale)
/INSTALL=
esegue l'installazione dell'agente come servizio se ancora non è installato, altrimenti avvia solamente il servizio.
Da notare che l'eseguibile per l'installazione dell'agent,
OcsAgentSetup.exe, scaricato dal sito non è immediatamente
distribuibile "così com'è" ma ne va creata
una versione "pacchettizzata" che va preventivamente
predisposta, parametrizzata e caricata sul server di
amministrazione.
Infatti il programma OcsLogon.exe,
appena visto, non riesce a passare alcun parametro al programma di
installazione dell'agent se non la locazione del pacchetto e,
indirettamente, tramite l'aver rinominato l'eseguibile, l'indirizzo
del server di amministrazione.
Per la preparazione del pacchetto
da distribuire si utilizza un altro programma distribuito con la
suite: ocspackage.exe. Questo programma per Windows dopo l'avvio
chiede il nome dell'eseguibile che va usato per il setup dell'agent
(OcsAgentSetup.exe), il percorso per un eventuale certificato, il
nome e la password dell'amministratore di dominio (per conto del
quale verrà eseguita l'operazione di installazione) e i
parametri con i quali viene lanciato il setup.
Nel nostro caso i
parametri di setup scelti sono
/S /NP /DEBUG /SERVER:172.20.1.4 |
Il parametro S server per il "silent mode" in modo da non "disturbare" l'utente durante l'installazione, gli altri parametri hanno lo stesso significato di quelli omonimi dell'OcsLogon.
L'intera sequenza, spiegata a parole, risulta abbastanza caotica
per cui penso sia opportuno riassumere il tutto graficamente:
La frequenza con la quale l'agente comunica i dati al server è
un parametro settato sul server, nella pagina di amministrazione del
programma, che si chiama PROLOG_FREQ=xx.
Tale
parametro viene utilizzato come seme per ottenere un valore random
con xx come massimo (nell'immagine di esempio xx=6 ore). Lo scopo
della randomizzazione è evitare che tutti i client vadano ad
inviare contemporaneamente i dati al server congestionando il
sistema. Al primo collegamento l'agente scarica tale valore e lo
sincronizza in locale. Il valore xx rappresenta il tempo massimo in
ore entro il quale l'agente invierà i dati.
Per verificare
che l'agente sia operativo è sufficiente verificare il file
service.ini nella directory del programma. Tale programma riporta nel
parametro TTO_WAIT=yyyy il valore in secondi mancante all'invio dati
al server. E' semplice verificare a pochi secondi di distanza se tale
parametro è variato del valore atteso (il valore iniziale meno
i secondi trascorsi, ovviamente). Quando il conteggio scende a zero
l'agent, tramite il protocollo HTTP, invia i dati al server che li
memorizza nel database.
A questo punto è possibile accedere al server e
visualizzare i dati raccolti.
In una rete, ovviamente, non ci sono solo i PC client ma anche una
serie di dispositivi sui quali l'agent non può essere
installato. Per catalogare tali dispositivi entrano in gioco le
funzionalità di "discovery" di OCSInventory. E'
sufficiente settare su ON il parametro IPDISCOVER nella pagina di
amministrazione sul server. Accanto a tale parametro è
riportato un numero che indica, come vedremo meglio di seguito, il
numero di client che verranno coinvolti nell'operazione di
discovery.
In pratica il server centrale, basandosi sulla
assiduità con la quale inviano informazioni, incarica il
numero indicato di client di scandagliare le reti definite. Qualora
un IP risponda all'interrogazione viene memorizzato come IP da
identificare.
Quindi i passi da eseguire per attivare la
rilevazione sono:
Definire le reti da rilevare
Abilitare il parametro IPDISCOVER nella finestra di amministrazione del server
Attendere il rilevamento
Identificare gli IP rilevati che vengono classificati come
non inventariati nella finestra delle informazioni di rete
(nell'immagine seguente sono 11)
Vista la sua semplicità non vorrei dilungarmi oltre nella descrizione di questo programma supportato, oltretutto, da un buon manuale in inglese. Lo scopo dell'articolo era di portare alla vostra attenzione uno strumento che riguarda un'attività molto spesso trascurata da noi informatici ovvero l'inventario delle proprie risorse.
Come ho premesso fin dall'inizio ritengo però che una corretta gestione delle risorse disponibili possa rappresentare quel "di più" che fa la differenza fra una gestione professionale ed una "improvvisata" di un dipartimento informatico.
Il manuale di installazione e amministrazione.
L'autoreRudi Giacomini Pilon, programmatore dall'età di 14 anni, ex progettista elettronico, ex hardwarista e sistemista presso un Microsoft Solution Provider, ex esperto di reti e programmatore in una concessionaria IBM, incontra Linux nel 1994 e da allora vede pinguini ovunque. Dal 1999 è responsabile EDP in una SpA ove affronta l'informatica a 538 gradi (360 erano pochi). |
<- Ritorniamo... - Indice Generale - Copertina - flex: Fast Lexical Analyzer -> |