Archivi tag: windows

NRPE_NT e Nagios: script PowerShell per il controllo dell’uptime su Windows Server 2008 R2

Tenere sotto controllo l’uptime dei nostri server è molto importante, soprattutto se si ha a che fare con macchine in produzione. Per ciò che concerne i sistemi operativi di casa Microsoft (sia client che server), esiste un comando che può tornarci molto utile allo scopo, ovvero:

net stats srv

il quale, basandosi sul servizio Server di Windows, colleziona e fornisce tutta una serie di informazioni associate alla nostra macchina, tra cui, per l’appunto, il suo tempo di attività:

Statistics since 7/11/2016 9:21:08 AM

powershellAffinchè il suddetto task possa essere effettuato in automatico dal nostro NMS (Nagios), è necessario utilizzare uno scrip (get_uptime.ps1, creato da me allo scopo) da integrare al servizio NRPE_NT. Per ragioni di semplicità e comodità ho deciso di avvalermi di Windows PowerShell per la stesura dello stesso, il cui contenuto è il seguente:

$critical = $Args[0]
$warning = $Args[1]

if ($warning -and $critical) #both variable are defined and not empty
{
    if ($critical -lt $warning)
    {
        $os = Get-WmiObject win32_operatingsystem
        $uptime = (Get-Date) - ($os.ConvertToDateTime($os.lastbootuptime))
        $minutes_to_seconds = $Uptime.Minutes*60
        $hours_to_seconds = $Uptime.Hours*3600
        $days_to_seconds = $Uptime.Days*86400
        $uptime_in_seconds = $minutes_to_seconds + $hours_to_seconds + $days_to_seconds
        if ($uptime_in_seconds -gt $critical -and $uptime_in_seconds -gt $warning)
        {
            $Display = "OK: System Uptime is " + $Uptime.Days + " days, " + $Uptime.Hours + " hours, " + $Uptime.Minutes + " minutes"
            Write-Output $Display
            exit 0
        }
        elseif ($uptime_in_seconds -gt $critical -and $uptime_in_seconds -le $warning)
        {
            $Display = "WARNING: System Uptime is " + $Uptime.Days + " days, " + $Uptime.Hours + " hours, " + $Uptime.Minutes + " minutes"
            Write-Output $Display
            exit 1
        }
        else
        {
            $Display = "CRITICAL: System Uptime is " + $Uptime.Days + " days, " + $Uptime.Hours + " hours, " + $Uptime.Minutes + " minutes"
            Write-Output $Display
            exit 2
        }
    }
    else
    {
        $Usage = "Usage: .\get_uptime.ps1 <critical threshold in seconds> <warning threshold in seconds>"
        $Error1 = "Warning threshold must be greater then the critical one"
        Write-Output $Usage
        Write-Output $Error1
        exit 3
    }
}
else
{
    $Usage = "Usage: .\get_uptime.ps1 <critical threshold in seconds> <warning threshold in seconds>"
    $Error2 = "Warning threshold and critical threshold must be defined"
    Write-Output $Usage
    Write-Output $Error2
    exit 3
}

In soldoni, il suddetto scrip riceve due argomenti da linea di comando, ovvero la soglia critica e quella di warning, espresse entrambe in secondi. Ovviamente, trattandosi di tempo di attività, la prima deve essere strettamente minore della seconda.

Configurazione di NRPE_NT

Salviamo tale scrip all’interno della directory C:\nrpe\Plugins\V2 e successivamente editiamo il file C:\nrpe\Plugins\V2\V2_nrpe_commands.cfg, aggiungendo la seguente direttiva:

# =================================
# Windows System Uptime checks
# =================================

command[get_system_uptime]=cmd.exe /c echo C:\nrpe\Plugins\V2\get_uptime.ps1 "$ARG1$" "$ARG2$" | powershell.exe -ExecutionPolicy Bypass -NoLogo -NonInteractive -NoProfile -command -

In particolare, stiamo definendo il comando get_system_uptime che si avvarrà di get_uptime.ps1 per l’individuazione del tempo di attività.

Occorre precisare che l’esecuzione dello scrip non può avvenire richiamando direttamente l’eseguibile powershell.exe, ma deve prima passare per cmd.exe (il cui output, mediante pipe, viene dato in pasto a PowerShell grazie alla direttiva -command –, dove il finale rappresenta “tutto ciò che proviene dal pipe”). Inoltre, si rende indispensabile bypassare l’executionpolicy di PowerShell, consentendo ad NRPE_NT di lanciare get_uptime.ps1 senza restrizioni.

Infine, riavviamo NRPE_NT per rendere effettive le suddette modifiche:

C:\Users\Administrator> net stop nrpe_nt
C:\Users\Administrator> net start nrpe_nt

Configurazione di Nagios

Per prima cosa è necessario creare un apposito comando all’interno del file /etc/nagios/object/commands.cfg:

# nagios-Windows-uptime check command definition

define command {
        command_name    check_Windows_uptime
        command_line    /usr/lib64/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -t $ARG1$ -c get_system_uptime -a $ARG2$ $ARG3$
        }

Successivamente, all’interno del file che rappresenta l’host da monitorare, è necessario aggiungere un servizio specifico che si avvale del suddetto comando:

define service{
        use                             generic-service         ; Name of service template to use
        host_name                       Windows-Server
        service_descripion             query Windows System Uptime for Microsoft Windows Machine
        check_command                   check_Windows_uptime!30!60!900
        }

Ricarichiamo la configurazione di Nagios:

[root@linuxbox ~]# service nagios reload

ed abbiamo finito.

Alla prossima.

NRPE_NT e Nagios: tenere sotto controllo gli aggiornamenti di Windows

Installare prontamente gli aggiornamenti di Windows, soprattutto se si ha a che fare con i security update, è sempre cosa buona e giusta. Spesso, però, capita che l’amministratore di sistema debba gestire N macchine e non abbia il tempo materiale di loggarsi su ciascuna di esse e constatare l’eventuale disposnibilità di aggiornamenti. Personalmente credo che non li si debba mai scaricare nè tantomeno installare automaticamente sulla macchina ospite, soprattutto se si ha a che fare con dei sistemi in produzione.

Cosa fare dunque per automatizzare tale task di verifica della disponibilità degli aggiornamenti? Semplice, utilizzare il nostro NMS preferito, ovvero Nagios.

nagiosIngredienti

Per prima cosa è necessario che sulla macchina da monitorare sia installato (ed attivo) il servizio NRPE_NT. Inoltre, ai plugin utilizzati dal servizio in questione, occorre aggiungere uno scrip PowerShell creato appositamente. Infine,  occorre creare su Nagios un comando ed un servizio specifico, in modo che il nostro NMS sia in grado di effettuare il controllo degli aggiornamenti in modo automatico e ad intervalli di tempo regolari.

Configurazione di NRPE_NT

Poichè la verifica della disponibilità degli aggiornamenti è un’operazione che può richiedere parecchio tempo, è necessario fare in modo che il timeout di NRPE_NT venga appositamente incrementato, editando la direttiva command_timeout presente all’interno del file nrpe.cfg (nel mio caso ho impostato una soglia pari a 600 secondi):

command_timeout= 600

Per ciò che concerne lo scrip PowerShell, esso può essere scaricato da qui, per poi posizionarlo all’interno della directory Plugins di NRPE_NT. A questo punto, sempre lato NRPE_NT, è possibile creare un comando specifico che si occuperà di verificare la disponibilità degli aggiornamenti di Windows. Tale definizione va inserita all’interno del file V2_nrpe_commands.cfg e presenta la seguente struttura:

command[get_windows_updates]=cscrip.exe //nologo //T:600 c:\nrpe\plugins\v2\check_windows_updates.wsf /w:0 /c:1

Restartiamo infine il servizio NRPE_NT mediante i comandi:

net stop NRPE_NT
net start NRPE_NT

e passiamo alla configurazione di Nagios.

Configurazione di Nagios

Come già affermato in precedenza, la configurazione dell’NMS si basa su due passaggi: la creazione del comando e l’assegnazione del check che ne fa uso ad un servizio legato all’host da monitorare.

Di seguito riporto il comando (da inserire nel file commands.cfg presente in /etc/nagios/objects):

# nagios-WMI-windows-updates check command definition

define command {
        command_name    check_WMI_windows_updates
        command_line    /usr/lib64/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -t $ARG1$ -c get_windows_updates
        }

Mentre il servizio è così definito:

define service{
        use                             generic-service         ; Name of service template to use
        host_name                       Windows-Machine
        service_description             query WMI Updates for Microsoft Windows Machine
        check_command                   check_WMI_windows_updates!600
        normal_check_interval           120
        }

Da notare che l’unico parametro passato al comando riguarda il numero di secondi di attesa (600) prima del timeout. Inoltre, ho fatto in modo che i check vengano eseguiti a distanza di 2 ore l’uno dall’altro (normal_check_interval 120).

A configurazione ultimata riavviamo Nagios per rendere effettive le modifiche:

[root@NMS ~]# service nagios reload

In caso di disponibilità di aggiornamenti, il cruscotto dell’NMS ci apparirà in un modo simile al seguente:

cruscotto_nagios

Alla prossima.

Installare e configurare NFS

L’acronimo NFS sta per Network File System ed è un sistema di sharing utilizzato in ambiente Linux. A differenza di Samba, che consente ad un sistema *nix di fungere da file server per macchine Windows, NFS è riservato solo ed esclusivamente ai sistemi operativi Unix-like.

linux, windows, samba, nfs, sharing, file server, rpc, portmap, ACL, fstab, mount

Configurarlo e farlo funzionare non è banale, in quanto, oltre alla configurazione del server, occorre lavorare anche sui client, facendo in modo che possano accedere alle directory condivise.

Configurazione del server

Per fare in modo che una macchina Linux possa funzionare da server NFS è necessario installare i seguenti pacchetti:

[root@server ~]# yum install nfs-server
[root@server ~]# yum install portmap

Il primo, ovviamente, è il demone che tira su il servizio NFS vero e proprio; il secondo, invece, serve a gestire le chiamate RPC.

Una volta installati i suddetti pacchetti, passiamo alla configurazione di NFS. Per fare ciò occorre editare il file /etc/exports:

[root@server etc]#nano exports

aggiungendo la directory da condividere (con pathname assoluto) e relativa ACL. Quest’ultima permetterà di fare una distinzione tra le macchine che possono avere accesso alle risorse condivise e quelle a cui l’accesso è stato negato.

/var/www/html/share                192.168.49.0/255.255.255.24 (rw,sync)

Le ultime due flag indicano che le macchine a cui è consentito l’accesso possono operare sia in lettura che in scrittura (rw) e che il contenuto della directory deve essere costantemente sincronizzato tra client e server (sync). Ovviamente, la directory da sharare deve essere esistente, dunque, se ancora non l’avete creata, fatelo mediante un banale mkdir <nomedirectory>.

Inoltre, poichè il meccanismo di controllo degli accessi definito in precedenza è abbastanza blando (si basa sulo ed esclusivamente sull’indirizzo IP delle macchine che vogliono accedere agli share), è opportuno fare in modo che tali servizi non vengano esposti all’esterno, facendo uso di un firewall o di un dispositivo che implementa il NAT/PAT.

Bene, non ci resta che avviare i servizi nfs e portmap:

[root@server etc]# service portmap start
[root@server etc]# service nfs start

Se tutto è andato a buon fine, lanciando un netstat -anp, dovrebbero risultare in ascolto le seguenti porte:

111 UDP (portmap)

2049 TCP/UDP (NFS)

Abilitiamo l’avvio automatico dei suddetti servizi:

[root@server etc]# chkconfig --levels 2345 nfs on
[root@server etc]# chkconfig --levels 2345 portmap on

e lato server abbiamo finito.

Configurazione dei client

Come primo step, è necessario installare il seguente pacchetto:

[root@client ~]# yum install nfs-utils

Successivamente, la cosa più semplice da fare per consentire ai client di accedere alle directory condivise, consiste nell’editare il file /etc/fstab:

[root@client ~]# nano /etc/fstab

aggiungendo una entry del tipo:

<IP LAN server>:/var/www/html/share    /var/www/html/share    nfs    hard,intr,rw,sync 0 0

In particolare, in questa direttiva sono presenti i seguenti campi:

1) share remota;

2) punto di mount locale (che deve essere una directory esistente);

3) tipo di file system;

4) ulteriori flag.

Per montare la share appena creata possiamo lanciare il seguente comando:

[root@linux ~]# mount -a

che monta tutte le partizioni definite nel file fstab, compresa quella NFS.

Per verificare che la share sia effettivamente up, basta digitare il comando mount (che per default mostra tutte le partizioni già montate).

Infine, se si aggiunge una nuova share e la si vuole rendere subito disponibile (senza un restart del demone NFS), è sufficiente lanciare sul server il seguente comando:

[root@server etc]# exportfs -a

Alla prossima.

 

Tracert e traceroute messi a confronto

I comandi tracert (di casa Microsoft) e traceroute (di casa *nix) vengono utilizzati per enumerare gli hop (dispositivi di rete di livello 3, solitamente router) che attraversa un pacchetto fino a giungere a destinazione.

Ad esempio, se volessi individuare il percorso intrapreso da un pacchetto verso una data destinazione, posso lanciare il comando:

C:\Users\eldo>tracert 4.2.2.2

Traccia instradamento verso b.resolvers.Level3.net [4.2.2.2]
su un massimo di 30 punti di passaggio:

  1     3 ms     1 ms     2 ms  192.168.*.*
  2     *        *        *     Richiesta scaduta.
  3    14 ms    18 ms    17 ms  151.6.185.105
  4    32 ms    33 ms    31 ms  151.6.5.15
  5   124 ms   208 ms   218 ms  151.6.1.89
  6    45 ms    45 ms    45 ms  151.6.0.174
  7   117 ms   216 ms    51 ms  212.73.241.161
  8    52 ms    53 ms    54 ms  ae-14-14.ebr1.Frankfurt1.Level3.net [4.69.142.19]
4]
  9    59 ms    54 ms    55 ms  ae-61-61.csw1.Frankfurt1.Level3.net [4.69.140.2]

 10     *        *        *     Richiesta scaduta.
 11    55 ms    54 ms    54 ms  b.resolvers.Level3.net [4.2.2.2]

Traccia completata.

Gli hop non identificati (quelli caratterizzati dall’errore Richiesta Scaduta), non consentono un deteterminato tipo di traffico, nella fattispecie quello ICMP.

Infatti, il comando tracert basa il suo funzionamento sul suddetto protocollo.

Discorso diverso riguarda, invece, il comando traceroute:

 1  vodafone.station (10.*.*.*)  1.269 ms  1.247 ms  1.224 ms
 2  * * *
 3  * * *
 4  83.224.40.185 (83.224.40.185)  76.238 ms  76.338 ms  77.658 ms
 5  85.205.14.105 (85.205.14.105)  88.192 ms  81.755 ms  82.662 ms
 6  212.73.241.21 (212.73.241.21)  120.408 ms  102.599 ms  102.517 ms
 7  ae-0-11.bar2.Milan1.Level3.net (4.69.142.190)  72.483 ms  70.973 ms  69.436 ms
 8  ae-14-14.ebr1.Frankfurt1.Level3.net (4.69.142.194)  77.455 ms  76.717 ms  76.729 ms
 9  ae-61-61.csw1.Frankfurt1.Level3.net (4.69.140.2)  77.707 ms ae-71-71.csw2.Frankfurt1.Level3.net (4.69.140.6)  79.677 ms ae-61-61.csw1.Frankfurt1.Level3.net (4.69.140.2)  77.714 ms
10  * * *
11  b.resolvers.Level3.net (4.2.2.2)  76.517 ms  77.154 ms  76.688 ms

tracert,traceroute,hop,icmp,ttl,windows,unix,linux,udp

Esso, infatti, basa il proprio funzionamento sul protocollo UDP (porta compresa tra 33434 e 33454). Esiste comunque un’opzione per fare in modo che il suddetto comando utilizzi il protocollo ICMP, ovvero -I:

nightfly@nightbox:~$ sudo traceroute -I 4.2.2.2
traceroute to 4.2.2.2 (4.2.2.2), 30 hops max, 60 byte packets
 1  vodafone.station (10.1.1.1)  6.259 ms  6.270 ms  6.272 ms
 2  * * *
 3  * * *
 4  83.224.40.185 (83.224.40.185)  75.660 ms  76.495 ms  77.516 ms
 5  85.205.14.105 (85.205.14.105)  84.951 ms  85.111 ms  85.128 ms
 6  212.73.241.21 (212.73.241.21)  81.020 ms  68.027 ms  68.200 ms
 7  ae-0-11.bar2.Milan1.Level3.net (4.69.142.190)  74.880 ms  68.066 ms  68.426 ms
 8  ae-14-14.ebr1.Frankfurt1.Level3.net (4.69.142.194)  77.336 ms  76.738 ms  79.799 ms
 9  ae-71-71.csw2.Frankfurt1.Level3.net (4.69.140.6)  78.400 ms  78.500 ms  90.106 ms
10  ae-2-70.edge5.Frankfurt1.Level3.net (4.69.154.73)  78.688 ms  76.939 ms  76.813 ms
11  b.resolvers.Level3.net (4.2.2.2)  76.679 ms  76.707 ms  76.957 ms

Come potete notare, in quest’ultimo caso il decimo hop ha risposto, proprio perchè su di esso è consentito il traffico ICMP e non quello UDP.

Traceroute come footprinting

Il comando traceroute può essere utilizzato con finalità di footprinting. Ad esempio, se un dato hop non risponde nè al protocollo ICMP nè a quello UDP su una porta alta (compresa nel range che ho riportato in precedenza), si può specificare una determinata porta di destinazione mediante la flag -p. Supponendo che sull’host sia attivo un demone DNS, il comando da utilizzare potrebbe essere il seguente:

nightfly@nightbox:~$ sudo traceroute -p 53 10.1.2.14

Alla prossima.

Wake on LAN su minipc ASUS at-3iont-i

Premesso che il BIOS installato sulla mobo in questione presenta numerose limitazioni, ho deciso comunque di provare ad abilitare il Wake On LAN sul mio server casalingo (Debian).

Per prima cosa, ho provato ad individuare la voce del BIOS che mi consentisse di abilitare la suddetta funzionalità. Purtroppo però, la specifica versione di software presente sulla mia scheda madre non consente di attivare esplicitamente il WOL dalla scheda Gigabit Ethernet integrata, cosa che mi ha lasciato a dir poco sbalordito.

Nonostante ciò è comunque possibile:

1) abilitare il Wake dopo la pressione di un determinato tasto della keyboard PS2 (funzione testata da me personalmente e funzionante);

2) abilitare il Wake da mouse PS2;

3) abilitare il Wake da interfaccia PCI-Express;

4) schedulare il Wake in una data/ora ben precisa.

Ma queste opzioni non includono, ovviamente, il WOL da scheda di rete integrata.

Ho dunque creato uno scrip che consentisse di attivare la suddetta funzione, utilizzando un tool esterno, ovvero ethtool.

Per installarlo è sufficiante digitare:

nightfly@nightbox:~$ sudo apt-get install ethtool

Ad installazione completata, creiamo un file di testo vuoto:

nightfly@nightbox:~$ sudo nano autowol

il cui contenuto dovrà essere:

#!/bin/bash
ethtool -s eth0 wol g
exit 0

salviamo il file e rendiamolo eseguibile:

nightfly@nightbox:~$ sudo chmod a+x autowol

Lanciamo lo scrip e verifichiamo che il WOL mediante magic packet (g) sia effettivamente attivo:

nightfly@nightbox:~$ sudo ethtool eth0

Lo stralcio di output che ci interessa dovrà essere simile al seguente:

Supports Wake-on: pumbg
        Wake-on: g

La prima riga ci conferma che la scheda eth0 supporta il WOL, la seconda riga, invece, ci fornisce informazioni sul tipo di WOL attivo (magic packet).

Fatto ciò, è necessario che tale opzione venga attivata automaticamente ad ogni avvio del sistema (e prima dello spegnimento). Per fare questo si può copiare il suddetto scrip nella directory /etc/init.d e successivamente usare il comando:

nightfly@nightbox:/etc/init.d$ update-rc.d -f autowol defaults

Bene, a questo punto ho deciso di dare inizio ai miei test. Per prima cosa ho scaricato un software gratuito (per ambienti Windows e dotato di GUI) in grado di forgiare i magic packet. Il tool a cui mi riferisco è questo:

http://www.depicus.com/downloads/WakeOnLanGui.zip

La cosa bella di questo software è che ci permette di scegliere la porta (UDP) su cui inoltrare il magic packet, riuscendo dunque ad aggirare eventuali restrizioni imposte dal PAT (in questo modo potremo utilizzare il WOL anche da remoto).

wolgui.jpg

Per accendere il nostro server da remoto sarà sufficiente riempire i campi richiesti dal suddetto tool, ovvero:

1) MAC address della macchina che si vuole avviare;

2) indirizzo IP (oppure hostname) pubblico della macchina;

3) porta (UDP).

Solitamente il WOL si avvale della porta 7 o 9 (UDP) ma vi consiglio di forwardare porte più alte in modo da complicare la vita ad eventuali scrip kiddie (sai che piacere lasciare il server spento e ritrovarselo accesso di punto in bianco?).

In definitiva, i test hanno dato questo esito:

1) se il server è spento (S5) il WOL non funziona;

2) se il server è sospeso (S3, con RAM alimentata), il WOL funziona;

3) se il server è ibernato (S4), ovvero il dump della RAM si trova nell’area swap dell’HD, il WOL non funziona.

Quindi, così come stanno le cose il WOL è quasi inutile. Nei prossimi giorni vedrò di aggiornare il BIOS ed eventualmente di acquistare una scheda Ethernet PCI-Express.

Speriamo bene.

PS: per maggiori dattagli sui power state ACPI potete consultare questa pagina.

PPS: potete operare con i power state direttamente da CLI utilizzando il comando pmi action <stato>.

AGGIORNAMENTO del 16/04/2020

Finalmente ho trovato un po’ di tempo per lavorarci e credo di aver risolto il problema. E’ stato sufficiente modificare un’opzione del BIOS, ovvero:

Power -> Control EuP

portandola da “Enabled” a “Disabled”.

In soldoni, tale opzione (Energy Using Products), se abilitata, disattiva il WOL quando il sistema si trova in S4 (hibernate) oppure in S5 (spento).

Ergo, adesso il WOL funziona anche a PC spento.

YUMI: creare facilmente USB bootabili

Avete necessità di rendere bootabile la vostra pennetta USB, magari mettendoci dentro una distro Linux live?

yumi.jpg

Niente paura, questo è il tool che fa per voi:

http://www.pendrivelinux.com/yumi-multiboot-usb-creator/

Inutile dilungarmi in spiegazioni superflue, trovate tutta la documentazione necessaria nel link che vi ho postato.

Enjoy.

Query WMI clientless mediante Nagios ed NRPE_NT

Premessa

Prima di introdurre questa piccola guida, occorre spiegare cosa s’intende per WMI. Nella fattispecie, tale acronimo sta per Windows Management Instrumental, ovvero un’estensione del Win32 driver model, grazie alla quale è possibile monitorare e gestire le macchine (sia client che server) su cui è installato il sistema operativo di casa Microsoft (da Windows 2000 in poi).

Inulte dire che esistono già delle piattaforme sviluppate ad hoc che supportano le query WMI (tra cui SCOM), ma la cosa veramente interessante consiste nel poter sviluppare i propri sistemi di monitoraggio basati su scrip custom editati in VBscrip o PowerShell.

Ora, nel caso in cui si voglia allestire un sistema di monitoraggio che supporti le query WMI in ambiente open source, la scelta ricade necessariamente su nagios3. Inoltre, poichè nagios3 non supporta in modo nativo le query WMI, si rende indispensabile l’utilizzo di un tool che funge da tramite tra il server di monitoraggio e le macchine che verranno interrogate. Tale tool prende il nome di NRPE_NT (potete scaricarlo da qui, è gratuito).

nrpe.png

 

Come si può capire dall’immagine precedente, nagios3, attraverso il comando check_nrpe, invia una query ad NRPE_NT (installato su una macchina Windows), il quale la inoltrerà (comportandosi come un vero e proprio proxy) all’host Microsoft di destinazione.

Ricapitolando, abbiamo bisogno dei seguenti elementi per mettere in piedi il nostro sistema di monitoraggio WMI:

1) nagios3;

2) il plugin check_nrpe;

2) NRPE_NT;

3) i plugins V2 per NRPE_NT (potete scaricarli da qui).

Installazione di check_nrpe e configurazione di nagios3

Partendo dal presupposto che nagios3 sia già presente sulla nostra linux box, procediamo con l’installazione del plugin check_nrpe. Per fare ciò occorre digitare:

nightfly@nightbox:~$ sudo apt-get install nagios-nrpe-plugin

Adesso possiamo definire alcuni comandi custom da inviare alla macchina Windows su cui è installato NRPE_NT, affinchè quest’ultima possa inoltrare la query all’host di destinazione. In particolare, creiamo il file wmi.cfg all’interno della directory /etc/nagios-plugins/config, il cui contenuto sarà:

# nagios-WMI-cpu check command definition

define command {

command_name check_WMI_cpu

command_line /usr/lib/nagios/plugins/check_nrpe -H <IP macchina NRPE_NT> -c get_cpu -a $HOSTADDRESS$ $ARG1$ $ARG2$

}

# nagios-WMI-disk check command definition

define command {

command_name check_WMI_disk

command_line /usr/lib/nagios/plugins/check_nrpe -H<IP macchina NRPE_NT> -c get_disk -a $HOSTADDRESS$ $ARG1$ $ARG2$

}

# nagios-WMI-mem check command definition

define command {

command_name check_WMI_mem

command_line /usr/lib/nagios/plugins/check_nrpe -H<IP macchina NRPE_NT> -c get_mem -a $HOSTADDRESS$ $ARG1$ $ARG2$

}

Ovviamente esistono altri comandi di cui si può usufruire, una lista a cui far riferimento la trovate qui.

Bene, adesso definiamo i servizi da monitorare per i nostri host Windows. Un file di configurazione da utilizzare come template e da posizionare nella directory /etc/nagios3/conf.d è il seguente:

define host {
host_name   hostWindows
alias       nightflyclient
address     192.168.1.11
use         generic-host
}

define service{
use                             generic-service         ; Name of service template to use
host_name hostWindows
service_descripion             query WMI CPU for Microsoft Windows Machine
check_command                   check_WMI_cpu!CPU0!80,90
}

define service{
use                             generic-service         ; Name of service template to use
host_name hostWindows
service_descripion             query WMI Disk for Microsoft Windows Machine
check_command                   check_WMI_disk!C:!80,90
}

define service{
use                             generic-service         ; Name of service template to use
host_name hostWindows
service_descripion             query WMI Memory for Microsoft Windows Machine
check_command                   check_WMI_mem!_TOTAL!80,90
}

Salviamo il file appena creato e passiamo all’installazione di NRPE_NT sulla macchina Windows che fungerà da proxy per le query WMI.

Installazione di NRPE_NT

Per prima cosa scompattiamo il file nrpe_nt.0.8b-bin.rar e salviamone il contenuto all’interno della directory NRPE_NT presente in C:

Creiamo inoltre, sempre all’interno della directory NRPE_NT, la cartella Plugins ed all’interno di quest’ultima creiamo un’ulteriore cartella che chiameremo V2, nella quale salveremo il contenuto del file wmi-1.3.rar.

A questo punto editiamo il file nrpe.cfg presente nella directory bin, che si trova dentro la cartella NRPE_NT.

I punti da modificare sono sostanzialmente tre, ovvero:

allowed_hosts=<IP della linux box su cui è installato nagios3>

(in modo da consentire a nagios di connettersi ad NRPE_NT per usarlo come proxy);

dont_blame_nrpe=1

(in modo da consentire l’esecuzione di comandi da remoto);

include=C:\NRPE_NT\Plugins\V2\V2_nrpe_commands.cfg

(per dare in pasto ad NRPE_NT alcuni comandi aggiuntivi di monitoraggio).

Una volta configurato NRPE_NT passiamo alla sua installazione. Per fare ciò apriamo il prompt (start->esegui->cmd), posizioniamoci in C: e successivamente nella dir bin presente in NRPE_NT.

cmd.jpg

A questo punto lanciamo il comando:

nrpe_nt.exe -i

dove la flag -i sta per install.

NB: nel caso in cui stiate utilizzando una macchina su cui è installato Windows 7, prima di procedere con l’installazione di NRPE_NT dovete modificare le impostazioni di controllo dell’account utente:

controllo.png

Una volta installato il servizio NRPE_NT occorre avviarlo mediante il comando net start nrpe_nt oppure attraverso pannello di controllo -> strumenti di amministrazione -> servizi.

Controlliamo ora che NRPE_NT sia in ascolto sulla nostra macchina digitando:

netstat -ano | find ":5666"

il cui output dovrà essere simile al seguente:

TCP    0.0.0.0:5666           0.0.0.0:0              LISTENING       1976

NB: affinchè la macchina su cui è installato nagios3 possa connettersi ad NRPE_NT occorre disabilitare il Firewall di Windows.

Test per verificare il corretto funzionamento di NRPE_NT

Per verificare il corretto funzionamento di NRPE_NT effettuiamo il login sulla nostra linux box e posizioniamoci nella directory /usr/lib/nagios/plugins. A questo punto lanciamo il comando:

nightfly@nightbox:/usr/lib/nagios/plugins$ ./check_nrpe -H <IP della macchina Windows su cui è installato NRPE_NT>

Se l’output immediatamente successivo sarà:

NRPE_NT v0.8b/2.0

vuol dire che NRPE_NT funziona correttamente.

Infine, riavviamo nagios3 per rendere effettive le modifiche della sua configurazione messe in atto nella prima parte di questa guida:

nightfly@nightbox:~$ sudo service nagios3 restart

Adesso sarà possibile monitorare gli host Windows mediante nagios3 ed NRPE_NT.

See ya.