Mostrando entradas con la etiqueta Monitoreo. Mostrar todas las entradas
Mostrando entradas con la etiqueta Monitoreo. Mostrar todas las entradas

jueves, 15 de marzo de 2018

Monitorear si una maquina virtual tiene snapshots en VMware ESXi



Este script corre con el usuario nagios, el ESXServer lo cambian por el hostname de su ESX ó por la ip del mismo, Storage-01 es el nombre del datastore del vmware en mis servidores.

Va a llegar una alarma de nagios en caso que exista alguna virtual con al menos un snapshot en cualquier máquina virtual.

Script: /usr/local/apps/nagios/libexec/check_VM_snapshots


 # Autor Hernan Tirado
 # blog: redes-seguridad.blogspot.com
 # Creado el: 15-03-2018
 #
 # Uso: /usr/local/apps/nagios/libexec/check_VM_snapshots

CANT_SNAP=`ssh root@ESXserver-x ls -latR /vmfs/volumes/Storage-01/|grep -i snap |awk '{ print $6" "$7" "$9}'|sort|uniq|wc -l`

if [ $CANT_SNAP = 0 ];then
 echo "OK - Virtuales SIN Snapshots en Storage-01."
 exit 0
else
 echo "CRITICAL - Virtuales con Snapshots en Storage-01: $CANT_SNAP"
 ssh root@ESXserver -x ls -latR /vmfs/volumes/Storage-01/|grep -i snap |awk '{ print $6" "$7" "$9}'|sort|uniq
 exit 2
fi

fi
Tener en cuenta que tiene que tener habilitado el SSH en el server ESXi y también copiar la key de nagios en el autorized_key del server ESX.

jueves, 26 de mayo de 2016

Instalar Microsoft .NET 3.5 en Windows Server 2012 R2

Al querer instalar el NC_net (cliente que utiliza el nagios en windows) me arrojaba el siguiente error:


Me decía que no tenía instalada la versión del .Net Framework version 3.5.


Al ir al Server Manager para instalarla aparecía grisada, asi que buscando un poco llegué a que hay que instalar el siguiente update: http://go.microsoft.com/fwlink/?LinkId=513775

Luego de descargarlo lo instalamos como administrador:



Una vez instalado el update vamos a habilitar el rol desde el server manager:



Click en "Manage" -> "Add Roles and Features":



Next:


"Role based on feature-based installation" -> "Next":



Así como está -> "Next":



Sin agregar ni tildar nada -> "Next":



Tilamos las siguientes opciones de .Net 3.5 -> "Next":



Tener en cuenta que debemos especificar el source path de instalación:



Dejamos esto momentaneamente acá y abrimos la iso de la instalación con el WinRAR, vamos a la carpeta sources:


Y copiamos la carpeta sxs en una ubicación deseada por nosotros, en mi caso usé: G:\Sources


Volvemos donde habíamos dejado la instalación del .Net y colocamos en el path donde copiamos recién los fuentes, en: G:\Sources\sxs y damos ok:



Finalizada la instalación -> "Close":



Esta vez volví a ejecutar el instalador y completó la instalación con el .NET 3.5 ya instalado:



FUENTE: https://support.microsoft.com/en-us/kb/3005628

miércoles, 26 de noviembre de 2014

Balanceo de Carga y Alta Disponibilidad en un Webserver con Apache y Perl (versión 2)



En este enlace http://redes-seguridad.blogspot.com.ar/2014/07/balanceo-de-carga-y-alta-disponibilidad.html les mostré como hacer el balanceo aleatorio entre 2 webservers, detectaba si uno de ambos estaba caído enviaba las peticiones web's al otro:

Pero quedaba pendiente verificar el "CPU load" antes de hacer la redirección y basarse en la carga en vez de redireccionar aleatoria-mente. Con esta última versión del script cubrimos ese tema:


Escenario:

Tenemos 2 servidores web, cada uno escuchando en el mismo puerto la misma aplicación.

El script irá distribuyendo al webServer que tenga menor "Carga de CPU", en caso que alguno tenga el puerto bajo, es decir que la aplicación esté baja reenviará las peticiones al webserver que esté arriba.

Es decir, pueden ocurrir las diferentes situaciones:

1) Ambos servidores UP y con la aplicación ok, testea al de menor uso de CPU y redirige la petición a este.
2) Servidor1 caído ó la aplicación DOWN => redirecciona al Servidor2.
3) Servidor2 caído ó la aplicación DOWN => redirecciona al Servidor1.
4) Ambos Servidores caidos, en mi caso no hago nada, pero puedo mostrar algún mensaje que deseen.



Script:


#!/usr/bin/perl

##Descomentar la siguiente linea si desea ver lo que hace en vez de ejecutar la redirección:
#print "content-type: text/html \n\n";

##Escanea al WebServer1 el puerto 80 y verifica si está abierto, guarda en la variable $VAL1 si el comando fue correcto ó no:
$result1 = `nmap -sT -P0 WebServer1-p 80|grep open`;
$VAL1=$?;

##Escanea al WebServer2 el puerto 80 y verifica, idem al anterior, pero guarda el valor en $VAL2:
$result2 = `nmap -sT -P0 WebServer2 -p 80|grep open`;
$VAL2=$?;

##Concatena los valores de $VAL1 y $VAL2 en $VAL:
$VAL=$VAL1.$VAL2;

##Descomento las siguientes líneas si deseo ver los valores que obtienen las variables, recuerde que también debe descomentar la línea del conten-type que aparece al inicio del script:
#print "VAL1: ", $VAL1, "";
#print "VAL2: ", $VAL2, "";
#print "VAL:   ", $VAL,   "";

##Para pruebas hardcodeadas modificar y descomentar las siguientes variables:
## El valor 00     => ambos servidores escuchan, ver por CPU cual es el de menor uso
## El valor 0256   => redirige a WebServer01 (WebServer01 caido)
## El valor 2560   => redirige a WebServer02 (JDE05 caido)
## El valor 256256 => ambos webservers caido
#$VAL="00";
use Switch;
switch ($VAL)
{
 case "00"
 {
  ##Tener en cuenta que con el usuario de root no funciona, por eso utilicé el de apache, recuerde generar las keys ssh para el usuario www-data:
  my $CPU_SERVER1 = `ssh www-data'\@'ServerNagios /ruta/al/script/de/nagios/libexec/check_nt -H WebServer1 -v CPULOAD -l 5,80,90 | cut -d' ' -f3 | cut -d'%' -f1`;

  my $CPU_SERVER2 = `ssh www-data'\@'ServerNagios /ruta/al/script/de/nagios/libexec/check_nt -H WebServer2 -v CPULOAD -l 5,80,90 | cut -d' ' -f3 | cut -d'%' -f1`;

  ##Descomentar si desea ver valores, recuerde descomentar la content-type al inicio del script
  #print "SERVER1: ", $CPU_SERVER1, " ";
  #print "SERVER2: ", $CPU_SERVER2, " ";

  ##Evalua quien tene menor uso de CPU: 
  if ( $CPU_SERVER1 > $CPU_SERVER2)
  {
   ##Tener en cuenta que esto redirecciona, si descomenta el content-type lo mostrará por pantalla   
   print "Location: http://WebServer2:80/aplicacion\n\n";
  }
  else
  {
   ##Tener en cuenta que esto redirecciona, si descomenta el content-type lo mostrará por pantalla   
   print "Location: http://WebServer1:80/aplicacion\n\n";
  }
 }
 case "0256"    { print "Location: http://WebServer1:80/aplicacion\n\n"; }
 case "2560"    { print "Location: http://WebServer2:80/aplicacion\n\n"; }
 case "256256"  { print "Ningun webserver (WebServer1 y WebServer2) escucha en el puerto 80" }
 else           { print "Valor no contemplado en el Perl de Load Balance" }
}

viernes, 29 de agosto de 2014

Time Out on check_esxi_hardware.py for VMware Sensors

Empecé a recibir alarmas del nagios que no podía monitorear el hardware de uno de mis servidores dell. Utilizaba el mismo script para otros servidores y en este mismo estaba funcionando.

Luego de buscar un poco llegué a que al check_esxi_hardware.py puedo pasarle el parámetro -v para obtener más info y me topé con lo siguiente:



Los sensores de VMware en vez de normal aparecían como unknown:



En el vCenter aparecía este mensaje en la solapa de "Hardware Status":

"Hardware monitoring service on this host is not responding or not available"



Intenté reiniciarlos desde el botón reset the sensors y tampoco respondía. 

Finalmente reinicié el servicio desde el vCenter y funcionó perfectamente, tener en cuenta que el "restart" no funcionaba aparecía servicio demorado, así que primero dí "stop" y luego "start":



miércoles, 23 de julio de 2014

Balanceo de Carga y Alta Disponibilidad en un Webserver con Apache y Perl

Tenemos 2 servidores webs cada uno escuchando en el mismo puerto la misma aplicacion.

El script irá distribuyendo aleatoriamente entre ambos servidores, en caso que alguno tenga el puerto bajo, es decir que la aplicación esté baja reenviará las peticiones al webserver que esté arriba.

En el index por default del apache configuramos lo siguiente (quitar los espacios después del signo <)

ServerBalance# vi /var/www/index.html
< html>
< FORM ACTION="/cgi-bin/index.cgi">
< /html>

Verificamos que en el VirtualHost de apache tengamos habilitada la ejecución de scripts cgi:

ServerBalance# vi /etc/apache2/sites-available/default
....
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
....

Reiniciamos el apache:

ServerBalance# /etc/init.d/apache2 reload


Creamos un script en perl en la ruta donde tenemos el cgi-bin y ponemos lo siguiente:

ServerBalance# vi /usr/lib/cgi-bin/redirect.pl
#!/usr/bin/perl
$lower_limit = 1;
$upper_limit = 3;
my $random_number = int(rand($upper_limit-$lower_limit)) + $lower_limit;
if ($random_number == 1)
{
  $result = `nmap -sT -P0 server01 -p 80|grep open`;
  if ($? == 0)
  {
   print "Location: http://server01:80/app\n\n";
  }
   else
   {
    print "Location: http://server02:80/app\n\n";
   }
}
else
{
  $result = `nmap -sT -P0 server02 -p 80|grep open`;
  if ($? == 0)
  {
   print "Location: http://server02:80/app\n\n";
  }
   else
  {
   print "Location: http://server01:80/app\n\n";
  }
}


lunes, 16 de junio de 2014

Nagios y Apache Autenticando en Active Directory



Debe resolver el dominio:

[root@server~]# cat /etc/hosts|grep dominio
192.168.0.1 mi.dominio.net server_ad


Configuramos el apache, cambie los datos en rojo según su dominio:

[root@server~]# vi /ruta/del/apache/conf/extra/nagios.conf
ScriptAlias /nagios/cgi-bin "/ruta/del/nagios/nagios/sbin"


AuthBasicProvider ldap
AuthType Basic
AuthName "Auth Active Directory"
AuthLDAPURL "ldap://mi.dominio.net:389/DC=mi,DC=dominio,DC=net?sAMAccountName?sub?(objectClass=user)" NONE
AuthLDAPBindDN "usuario@mi.dominio.net"
AuthLDAPBindPassword "ACA VA EL PASSWORD DEL USER DE ARRIBA"
require ldap-attribute objectClass=user


Alias /nagios "/ruta/del/nagios/nagios/share"


AuthBasicProvider ldap
AuthType Basic
AuthName "Auth Active Directory"
AuthLDAPURL "ldap://mi.dominio.net:389/DC=mi,DC=dominio,DC=net?sAMAccountName?sub?(objectClass=user)" NONE
AuthLDAPBindDN "usuario@mi.dominio.net"
AuthLDAPBindPassword "ACA VA EL PASSWORD DEL USER DE ARRIBA"
require ldap-attribute objectClass=user


Reiniciamos Apache:

[root@server~]# /etc/init.d/httpd stop

[root@server~]# /etc/init.d/httpd start


Agregamos el usuario en nagios:

[root@Server~]# vi /ruta/del/nagios/etc/cgi.cfg

authorized_for_system_information=admin,usuario .....


Testeamos la config y reiniciamos nagios:

[root@Server~]# /ruta/del/nagios/bin/nagios -v /ruta/del/nagios/etc/nagios.cfg

Total Warnings: 0
Total Errors:   0

Things look okay - No serious problems were detected during the pre-flight check

[root@Server~]# /etc/init.d/nagios reload
Running configuration check...done.
Reloading nagios configuration...done


jueves, 22 de mayo de 2014

Monitoreando Procesos Zombies

Verificamos que no hay zombies:

root@server # ps -el |grep 'Z'
 F S    UID   PID  PPID   C PRI NI     ADDR     SZ    WCHAN TTY         TIME CMD
root@server #


Armamos un zombie en C:

root@server # vi zombie.c
#include
#include
#include
int main ()
{
  pid_t child_pid;
  child_pid = fork ();
  if (child_pid > 0) {
    sleep (60);
  }
  else {
    exit (0);
  }
  return 0;
}


Lo compilamos:

root@server # /usr/sfw/bin/gcc zombie.c


Lo ejecutamos:

root@server # ./a.out


Verificamos que ahora está el zombie: ()

root@server # ps -el |grep 'Z'
 F S    UID   PID  PPID   C PRI NI     ADDR     SZ    WCHAN TTY         TIME CMD
 0 Z      0 17100 17099   0   0  -        -      0        - ?           0:00
root@server #


Creamos un script para testear zombies con nagios:

root@server # vi check_zombie
#!/bin/bash
CANT_ZOMBIES=`ps -el |grep 'Z'|grep -v PPID|wc -l`
#echo $CANT_ZOMBIES
if [ $CANT_ZOMBIES -eq 0 ]
then
 echo "$CANT_ZOMBIES Zombies"
 exit 0
fi
if [ $CANT_ZOMBIES -eq 1 ]
then
 echo "$CANT_ZOMBIES Zombies"
 exit 1
fi
echo "$CANT_ZOMBIES Zombies"
exit 2


En la config del NRPE agregamos lo siguiente:

root@server # vi /usr/local/nagios/etc/nrpe.cfg
command[check_zombie_procs]=/usr/local/nagios/libexec/check_zombie

Matamos el nrpe:

root@server # ps -efa |grep nrpe
  nagios 18369     1   0 13:02:52 ?           0:00 /usr/local/nagios/bin/nrpe -c /usr/local/nagios/etc/nrpe.cfg -d
    root 18543 15868   0 13:06:54 pts/1       0:00 grep nrpe
root@server # kill -9 18369

Volvemos a iniciarlo:

root@server # /usr/local/nagios/bin/nrpe -c /usr/local/nagios/etc/nrpe.cfg -d


martes, 28 de enero de 2014

Monitoring IBM TS3100 Tape Library with Nagios



Descargué el "check_ibm_ts_tape.pl" del siguiente enlace: http://www.claudiokuenzler.com/nagios-plugins/check_ibm_ts_tape.php en la ruta donde guardo los scripts de nagios (en mi caso /ruta-nagios/libexec):

# wget http://www.claudiokuenzler.com/nagios-plugins/check_ibm_ts_tape.pl
--2014-01-28 17:06:08--  http://www.claudiokuenzler.com/nagios-plugins/check_ibm_ts_tape.pl
Resolving www.claudiokuenzler.com... 144.76.83.23
Connecting to www.claudiokuenzler.com|144.76.83.23|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 7078 (6.9K) [text/x-perl]
Saving to: `check_ibm_ts_tape.pl'
100%[=======================================================================================================================================>] 7,078       30.9K/s   in 0.2s
2014-01-28 17:06:10 (30.9 KB/s) - `check_ibm_ts_tape.pl' saved [7078/7078]
#


Damos permisos de ejecución:


# chmod a+x check_ibm_ts_tape.pl


Lo ejecutamos sin parámetros y nos muestra que library's están disponibles:


# ./check_ibm_ts_tape.pl
Model must be either ts3100 or ts3200.


Si le damos --help nos muestra la ayuda:


# ./check_ibm_ts_tape.pl --help
check_ibm_ts_tape.pl (c) 2012 Claudio Kuenzler (published under GPL License)
Version: 20120901
Usage: ./check_ibm_ts_tape.pl -H host [-C community] -m model -t checktype
Options:
-H      Hostname or IP address of tape library.
-C      SNMP community name (if not set, public will be used).
-m      Model of the tape library. Must be either ts3100 or ts3200.
-t      Type to check. See below for valid types.
--help  Show this help/usage.
Check Types:
info -> Show basic information of the tape library (hostname, serial number, etc)
status -> Checks the current status and outputs error codes if status is not ok
clean -> Checks all drives of tape library if cleaning is required



Ejecutamos el comando completo (Donde 192.168.0.100 es la ip de la Library, la Comunidad la especificamos con el -C, el modelo con el -m y lo que deseamos chequear con el -t, en este caso uso el info):

# ./check_ibm_ts_tape.pl -H 192.168.0.100 -C Comunidad -m ts3100 -t info
server.dominio (IBM TS3100) - Product-No: XXXX-TL - S/N: XXXXXXXX - running on Firmware X.XX


Ejecutamos el mismo comando, pero ahora con el check de status y luego el de clean:


# ./check_ibm_ts_tape.pl -H 192.168.0.100 -C Comunidad -m ts3100 -t info
ts3100 WARNING - Current status is: non-critical - No error (error code: 0) 
# ./check_ibm_ts_tape.pl -H 192.168.0.100 -C Comunidad -m ts3100 -t clean
ts3100 WARNING - 1 tape drive needs to be cleaned


Editamos el commands.cfg del nagios y agregamos lo siguiente:

# vi /ruta-del-nagios/commands.cfg
define command{
command_name check_library
command_line $USER1$/check_ibm_ts_tape.pl -H $HOSTADDRESS$ -C Comunidad -m ts3100 -t $ARG1$
}


Editamos el hosts.cfg y el services.cfg de la ruta del nagios y agregamos lo siguiente:

# vi /ruta-del-nagios/hosts.cfg
define host{
        host_name         Tape_Library
        alias                   Tape_Library
        address              192.168.0.100
        }
# vi /ruta-del-nagios/services.cfg
define service{
use                             generic-service,srv-pnp
host_name                  Tape_Library
service_description      Clean
check_command         check_library!clean
}
define service{
use                             generic-service,srv-pnp
host_name                  Tape_Library
service_description      Info
check_command         check_library!info
}
define service{
use                             generic-service,srv-pnp
host_name                  Tape_Library
service_description      Status
check_command         check_library!status
}


Verificamos la configuración del nagios antes de reiniciarlo:

#/ruta-del-nagios/bin/nagios -v /ruta-del-nagios/etc/nagios.cfg


Si devuelve 0 warnings y 0 errors reiniciamos el servicio con:


# /etc/init.d/nagios reload

jueves, 9 de enero de 2014

Logins erroneos en Windows Event Viewer

Inicio -> Ejecutar y tipeamos gpedit.msc


Local Computer Policy -> Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Audit Policy.

Sobre el panel derecho clickeamos sobre "Audit logon events":


En la solapa "Local Security Setting" tildamos "Success" y "Failure":


Probamos conectarnos al servidor con un password incorrecto y nos aparecerá "Failure Audit" en la solapa Security del Visor de Eventos, como muestra el cuadro en rojo:



viernes, 3 de enero de 2014

Chequear Visor de Sucesos Windows con Nagios

Descargué el script check_wmi_eventid de:
 http://exchange.nagios.org/directory/Plugins/Operating-Systems/Windows/WMI/Check-eventlog-2Feventid-by-WMI/details


Damos permisos de ejecución al script:
# chmod a+x ./check_wmi_eventid


Lo ejecutamos sin parámetros para ver la ayuda:

# ./check_wmi_eventid
usage: ./check_wmi_eventid options
check_wmi_eventid is a script to check windows event log , for a certian eventid..
Simple example : check application log , for eventtype error(-t) and  eventid 9003(-e) with in the last 60 mins(-m60),
set warning (-w) if greater than 1 ,and set error(-c) if greater than 3
check_wmi_eventid  -H 172.10.10.10 -u domain/user -p password -l application -e 9003  -w 1 -c 3  -t1 -m60
Adv. example : same as above , but with arguments -O -W -C, these are custom plugin output for OK,Warning and Critical
Marco ITEMCOUNt,LASTSTR , can be used!!
check_wmi_eventid  -H 172.10.10.10 -u domain/user -p password -l application -e 9003  -w 1 -c 3  -t1 -m60 -O "Every thing is OK"
-W "Warning : something is not right" -C "It is totaly bad , found ITEMCOUNT events"
Try it out :)
If you find any error , please let me know
OPTIONS:
   -h      Show this message
   -H      Host/Ip
   -u      Domain/user
   -p      password
   -l      Name of the log eg "System" or "Application" or any other Event log as shown in the Windows "Event Viewer".
   -t      Eventtype: # 1=error , 2=warning , 3=Information,4=Security Audit Success,5=Security Audit Failure
   -e      Eventid
   -s      Sting search for string in message
   -m      Number of past min to check for events.
   -w      Warning
   -W      Custom waring string    - ITEMCOUNT,LASTSTR marco can be used  ex. -W "ITEMCOUNT Wanings  with in the LASTSTR"
   -c      Critical
   -C      Custom critical string  - ITEMCOUNT,LASTSTR marco can be used  ex. -W "ITEMCOUNT Critical  with in the LASTSTR"
   -O      Custom ok sting         - ITEMCOUNT,LASTSTR marco can be used  ex. -W "Everything ok with in the LASTSTR"
   -U      CUstom unknown string   - ITEMCOUNT,LASTSTR marco can be used  ex. -W "ITEMCOUNT  Unknowns  with in the LASTSTR"
   -d      Debug
   -v      Version


Eligiendo los parámetros, ejecuté lo siguiente y me aparecía que no encontraba el cliente de WMI (wmic)


# ./check_wmi_eventid -H hostname -u administrator -p password -l application -e 9003 -w 1 -c 3 -t1 -m60
WMIC ERROR : ./check_wmi_eventid: line 252: /bin/wmic: No such file or directory


Descargamos WMIC del siguiente enlace:

http://sourceforge.net/projects/pandora/files/Tools%20and%20dependencies%20%28All%20versions%29/RPM%20CentOS%2C%20RHEL/wmic-4.0.0SVN-2.1.el5.centos.noarch.rpm/download


Lo instalamos con rpm:


# rpm -hiv wmic-4.0.0SVN-2.1.el5.centos.noarch.rpm
warning: wmic-4.0.0SVN-2.1.el5.centos.noarch.rpm: Header V3 DSA signature: NOKEY, key ID 155987ef
Preparing...                ########################################### [100%]
   1:wmic                   ########################################### [100%]


Lo ejecutamos si parámetros para ver los parametros requeridos:


# wmic
Usage: [-?] [-?] [-?] [-?NP] [-?NPV] [-?|--help] [--usage] [-d|--debuglevel DEBUGLEVEL]
        [--debug-stderr] [-s|--configfile CONFIGFILE] [--option=name=value]
        [-l|--log-basename LOGFILEBASE] [--leak-report] [--leak-report-full]
        [-R|--name-resolve NAME-RESOLVE-ORDER]
        [-O|--socket-options SOCKETOPTIONS] [-n|--netbiosname NETBIOSNAME]
        [-S|--signing on|off|required] [-W|--workgroup WORKGROUP]
        [--realm=REALM] [-i|--scope SCOPE] [-m|--maxprotocol MAXPROTOCOL]
        [-U|--user [DOMAIN/]USERNAME[%PASSWORD]] [-N|--no-pass]
        [--password=STRING] [-A|--authentication-file FILE] [-P|--machine-pass]
        [--simple-bind-dn=STRING] [-k|--kerberos STRING] [-V|--version]
        [--namespace=STRING]
        //host query

Example: wmic -U [domain/]adminuser%password //host "select * from Win32_ComputerSystem"



Una vez instalado al querer ejecutar nuevamente el comando, nos tiraba error que no lo encontraba:


# ./check_wmi_eventid -H hostname -u administrator -p password -l application -e 9003 -w 1 -c 3 -t1 -m60
 WMIC ERROR : ./check_wmi_eventid: line 252: /bin/wmic: No such file or directory


Viendo donde fue instalado, vemos que no encontraba la ruta:


# which wmic
/usr/bin/wmic



Editamos el script que descargamos (check_wmi_eventid):


# vim check_wmi_eventid
Cambiar:
WMIC=/bin/wmic
Por:
WMIC=/usr/bin/wmic



Ahora ejecutando el comando nuevamente, todo me devolvía el mismo valor, siempre era = 12:


# ./check_wmi_eventid -H server_name-u administrator -p password -l application -e 9003 -w 20 -c 30 -t1 -m60
OK 12 with Severity Level Error in application with in the last 1 hour|eventid9003=12;20;30;;

# ./check_wmi_eventid -H server_name-u administrator -p password -l security -e 4625 -w 20 -c 30 -t1 -m60
OK 12 with Severity Level Error in application with in the last 1 hour|eventid9003=12;20;30;;



Entonces decidí hacer mi propio script con WMIC, con el siguiente comando (cambiando las variables en rojo por los valores correspondientes):


# wmic -U USUARIO%PASWORD //HOSTNAME "select EventCode,EventIdentifier,EventType,TimeGenerated from Win32_NTLogEvent"


Obtenía algo como lo siguiente:

CLASS: Win32_NTLogEvent
EventCode|EventIdentifier|EventType|Logfile|RecordNumber|TimeGenerated
.....
.....
902|1073742726|0|Application|4506|20100615130231.000000-000
5615|3221231087|0|Application|4507|20100615130239.000000-000
5617|3221231089|0|Application|4508|20100615130243.000000-000
34|1073872930|3|Application|4509|20100615130247.000000-000
4|1073872900|3|Application|4510|20100615130250.000000-000
5|1073872901|3|Application|4511|20100615130251.000000-000
5|1073872901|3|Application|4512|20100615130251.000000-000
5|1073872901|3|Application|4513|20100615130251.000000-000
5|1073872901|3|Application|4514|20100615130251.000000-000
5|1073872901|3|Application|4515|20100615130251.000000-000
5|1073872901|3|Application|4516|20100615130251.000000-000
5|1073872901|3|Application|4517|20100615130251.000000-000
5|1073872901|3|Application|4518|20100615130251.000000-000
5|1073872901|3|Application|4519|20100615130251.000000-000
5|1073872901|3|Application|4520|20100615130251.000000-000
5|1073872901|3|Application|4521|20100615130251.000000-000
34|1073872930|3|Application|4522|20100615130251.000000-000
34|1073872930|3|Application|4523|20100615130251.000000-000
.....

Modificando un poco la query que hacía al server por WMI llegué a obtener todos los Eventos del visor de sucesos de un windows que tuvieran id=4625 (loguin erroneo) del registro de seguridad:

# wmic -U USUARIO%PASSWORD //HOSTNAME "select EventCode,EventIdentifier,EventType,TimeGenerated from Win32_NTLogEvent where EventCode='4625' AND Logfile='security'" 


Pero yo en nagios quería monitorear los loguins erroneos del día actual, entonces quedó así:


#HOY=`date +%d/%m/%Y` 
# wmic -U USUARIO%USUARIO //HOSTNAME "select EventCode,EventIdentifier,EventType,TimeGenerated from Win32_NTLogEvent where EventCode='4625' AND Logfile='security' AND TimeGenerated>='$HOY'"


Inicialmente la consulta comenzaba pero se cortaba, así que borré el visor de sucesos de seguridad de windows e hice un par de logueos erroneos para que aparezcan y aparecieron correctamente:

CLASS: Win32_NTLogEvent
EventCode|EventIdentifier|EventType|Logfile|RecordNumber|TimeGenerated
4625|4625|5|Security|2774019|20140103151300.184621-000
4625|4625|5|Security|2774020|20140103151325.320732-000
4625|4625|5|Security|2774027|20140103151335.353332-000
4625|4625|5|Security|2774047|20140103153339.520120-000
4625|4625|5|Security|2774048|20140103153339.535719-000


Una vez obtenido el comando correcto armamos el script para testear los visores de sucesos de windows con nagios:


# vi check_wmi_eventWindows.sh

#!/bin/bash
#
# Script creado el 03-01-2013 por Hernán Tirado
# Descripción: Chequea por WMI el visor de sucesos de windows del día actual
#              Verifica si hay mas de 10 loguins erroneos en el visor de sucesos => Critical
#              Verifica si hay mas de 5 loguins erroneos en el visor de sucesos => Warning
#
# NOTA:
#       Tener en cuenta que si el visor de suscesos es muy largo la query tarda y se corta
#
#       Setear las variables de entorno antes de ejecutarlo.

################## INICIO DE CONFIGURACION DE VARIABLES
# Ruta de ubicación del comando wmic:
WMIC=/usr/bin/wmic
# Fecha de HOY:
HOY=`date +%d/%m/%Y`
# Usuario administrador del windows:
USER=
# Contraseña del usuario administrador de windows:
PASSWORD=
# Nombre de host ó ip del windows:
HOST=jdeenterprise
# Tipo de Visor de Suceso (Application, Security, Setup, System):
EVENT_TYPE='security'
# Tipo de Evento (Ej: 4625 testea loguins erroneos):
ID_EVENTO=4625
################## FIN DE CONFIGURACION DE VARIABLES

# Ejecución del comando WMIC:
CANT_ERRONEA=`$WMIC -U $USER%$PASSWORD //$HOST "select EventCode,EventIdentifier,EventType,TimeGenerated from Win32_NTLogEvent where EventCode='$ID_EVENTO' AND Logfile='$EVENT_TYPE' AND TimeGenerated>='$HOY'" | grep -v CLASS | grep -v Event | wc -l`
# Testeamos los valores que devuelve, si:
# CANT_ERRONEA <= 5   =>  OK       (exit 0)
# CANT_ERRONEA  > 5   =>  WARNING  (exit 1)
# CANT_ERRONEA  > 10  =>  CRITICAL (exit 2)

if [ $CANT_ERRONEA -lt 5 ]; then
{
 echo OK - Cantidad de Logins Erroneos = $CANT_ERRONEA;
 exit 0;
}
fi
if [ $CANT_ERRONEA -gt 10 ]; then
{
 echo CRITICAL - Cantidad de Logins Erroneos = $CANT_ERRONEA;
 exit 1;
}
fi
if [ $CANT_ERRONEA -gt 4 ]; then
{
 echo WARNING - Cantidad de Logins Erroneos = $CANT_ERRONEA;
 exit 1;
}
fi


En el commands de nagios agregamos lo siguiente:

# vi /etc/nagios/commands.cfg

define command{
command_name check_wmi_eventWindows.sh
command_line $USER1$/check_wmi_eventWindows.sh
}


En el services de nagios agregamos lo siguiente:

# vi /etc/nagios/services.cfg:

define service{
use                                     generic-service,srv-pnp
host_name                          nombre_de_host
service_description             Check_Bad_Logins
check_command                 check_wmi_eventWindows.sh
}


Chequeamos la config de nagios y si no da errores, reiniciamos el servicio:

# bin/nagios -v /etc/nagios.cfg
...
Total Warnings: 0
Total Errors:   0
...

# /etc/init.d/nagios reload
Running configuration check...done.
Reloading nagios configuration...done


NOTA: Tener en cuenta que en Windows debe estar habilitada la auditoría de logins erroneos. En esta entrada del blog les dejo como habilitarlo: http://www.redes-seguridad.com.ar/2014/01/logins-erroneos-en-windows-event-viewer.html


lunes, 23 de diciembre de 2013

Script que testea intentos fallidos de SSH

Script en Bash: 
#!/bin/bash
# Script que testea intentos fallidos de
# 0=OK
# 1=WARNING
# 2=CRITICAL
# 3=UNKNOWN
HOY=`date "+%b %d"`
LOG=/var/log/auth.log
CANT_FALLIDOS=`cat $LOG |grep "Authentication failed"|grep "$HOY" | wc -l`
if [ $CANT_FALLIDOS -gt 15 ]; then
{
 echo "CRITICAL - Intentos fallidos:$CANT_FALLIDOS";
 exit 2;
}
fi
if [ $CANT_FALLIDOS -gt 10 ]; then
{
 echo "WARNING - Intentos fallidos:$CANT_FALLIDOS";
 exit 1;
}
fi
echo "OK - Intentos fallidos:$CANT_FALLIDOS";
exit 0;

Monitoreamos NRPE, editamos el services.cfg del server de nagios:

vi /etc/nagios/services.cfg
define service{
use                             generic-service
host_name                  ar-stf-vm-xen-1-crp-3
service_description     SSH_Fail_Login
check_command        check_nrpe!check_ssh_auth
}

Editamos en el server que queremos monitorear el nrpe.conf y luego reiniciamos el servicio:

vi /usr/local/apps/nagios/etc/nrpe.cfg
command[check_ssh_auth]=/usr/local/apps/nagios/libexec/check_ssh_auth

miércoles, 25 de septiembre de 2013

Disk Storage IBM Storwize V3700 Monitoring with Nagios:


Descargué el plugin llamado check_ibm_v7000.sh de:

http://exchange.nagios.org/components/com_mtree/attachment.php?link_id=3157&cf_id=24


Probé primero que funcione desde el bash ejecutando, lo siguiente, donde -M es la ip del storage, -U user (debe existir en el storage) y -Q la consulta:

# /ruta/del/plugins/check_ibm_v7000.sh -M 192.168.0.100 -U nagios -Q lsdrive
Password:


En este caso me devolvió que tengo el disco 9 dañado en el storage:

CRITICAL: Disk OFFLINE
 OK: Drive 0 is online
 OK: Drive 1 is online
 OK: Drive 2 is online
 OK: Drive 3 is online
 OK: Drive 4 is online
 OK: Drive 5 is online
 OK: Drive 6 is online
 OK: Drive 7 is online
 OK: Drive 8 is online
 ATTENTION: Disk 9
status:
role: failed
type: sas_hdd
capacity: 558.4GB
enclosure:
slot:   OK: Drive 10 is online
 OK: Drive 11 is online
 OK: Drive 12 is online
 OK: Drive 13 is online
 OK: Drive 14 is online
 OK: Drive 15 is online
 OK: Drive 16 is online
 OK: Drive 17 is online
 OK: Drive 18 is online
 OK: Drive 19 is online
 OK: Drive 20 is online
 OK: Drive 21 is online
 OK: Drive 22 is online
 OK: Drive 23 is online
 OK: Drive 24 is online
 OK: Drive 25 is online
 OK: Drive 26 is online
 OK: Drive 27 is online
 OK: Drive 28 is online
 OK: Drive 29 is online
 OK: Drive 30 is online
 OK: Drive 31 is online
 OK: Drive 32 is online
 OK: Drive 33 is online
 OK: Drive 34 is online
 OK: Drive 35 is online
 OK: Drive 36 is online
 OK: Drive 37 is online
 OK: Drive 38 is online
 OK: Drive 39 is online
 OK: Drive 40 is online
 OK: Drive 41 is online
 OK: Drive 42 is online
 OK: Drive 43 is online
 OK: Drive 44 is online
 OK: Drive 45 is online
 OK: Drive 46 is online
 OK: Drive 47 is online


Nos logueamos al server donde tenemos instalado nagios con el usuario nagios y generamos las keys para que no nos pida password:

# su - nagios
$ cd /home/nagios/.ssh/
$ ssh-keygen
$ ls
id_rsa  id_rsa.pub  known_hosts


Copiamos la llave pública por winscp a nuestro equipo: id_rsa.pub para luego importarla al storage por web, vamos a usuarios:



Creamos un nuevo usuario en el grupo monitor:


Le asignamos un nombre, en mi caso nagios, que use autenticación local:


Importamos la llave pública generada en el server de monitoreo para el usuario nagios:


Quedándonos así:



Agregamos el host al nagios:

# vim /ruta/del/nagios/hosts.cfg
define host{
        use                     linux-server
        host_name               STORAGE
        alias                   STORAGE
        address                 192.168.0.100
        }


Parametrizamos el comando:

# vim /ruta/del/nagios/commands.cfg
define command{
command_name check_storage
command_line $USER1$/check_ibm_v7000.sh -M $HOSTADDRESS$ -U $ARG1$ -Q $ARG2$
}


Configuramos el Servicio:

# vim /ruta/del/nagios/services.cfg
define service{
use                             generic-service
host_name                       STORAGE
service_description             STORAGE_DISKs
check_command                   check_storage!nagios!lsdrive
}

viernes, 5 de julio de 2013

You must use the Role Management Tool to install or configure Microsoft .NET Framework 3.5.

Para instalar en Windows 2008 el NC_Net (Cliente para Monitoreo Nagios en windows) requiere
el .NET Framework 3.5 y me aparecía el siguiente error.

"You must use the Role Management Tool to install or configure Microsoft .NET Framework 3.5.":


Vamos a agregar el feature, haciendo botón derecho en "Computer" -> "Manage":


Seleccionamos "Features" y agregamos la feature mediante "Add Features":


Desplegamos el menú de ".NET Framework 3.5.1 Features" y tildamos ".NET Framework 3.5.1 Features" luego "Next":


"Install":


"Close":



miércoles, 3 de julio de 2013

Monitoreo de Hardware Dell R710 con Nagios

En servidor de monitoreo nagios:

Descargamos e instalamos el plugin del openmanage:

# cd /root
# tar xzvf check_openmanage-3.7.9.tar.gz
# cd /root/check_openmanage-3.7.9
# ./install.sh
Plugin dir [/usr/lib64/nagios/plugins]: /usr/local/apps/nagios/libexec/
Man page dir [/usr/share/man]:
done.

En el server Dell con Windows tenemos que tener en cuenta instalar el OMSA y el SNMP, configurar la comunity SNMP y reiniciar el servicio.


Luego nuevamente desde el nagios ejecutamos el chequeo por linea de comandos:


# /usr/local/apps/nagios/libexec/check_openmanage -H 159.234.148.2 -C Nombre_Comunidad_SNMP


Obtenemos como resultado:

OK - System: 'PowerEdge R710', SN: '6B1UMT2', 16 GB ram (0 dimms), 1 logical drives, 4 physical drives



Agregamos en el hosts.cfg lo siguiente en el nagios:

define host{
        use                     windows-server,host-pnp            ; Name of host template to use
        host_name          DelR710
        alias                    Hardware DelR710
        address               192.168.0.99
        }


En el services.cfg del nagios lo siguiente, no olvidar de reemplazar "Nombre_Comunidad" por su propia comunity de windows. 

define service{
use                             generic-service
host_name                  DelR710
service_description     OpenManager
check_command        check_openmanage!Nombre_Comunidad
}

Testeamos la config y reiniciamos el nagios:

# /ruta/del/binario/de/nagios -v /ruta/de/la/config/de/nagios/nagios.cfg
# /etc/init.d/nagios reload

viernes, 22 de marzo de 2013

Monitoreo espacio DBspaces en Informix

Aclaración:

Tener en cuenta que este script fue creado particularmente para el DBspace datadb de un especifico server para el chunk: 1ec9a2038


Creamos un archivo para el script y colocamos lo siguiente:

vim check_informix_dbspace_morsa
#!/bin/bash
SIZE_DATADB_DBSPACE=`onstat -d | grep 1ec9a2038 | awk '{print $6}'`
if test $SIZE_DATADB_DBSPACE -lt 206431
then
  echo CRITICAL - DBspace is $SIZE_DATADB_DBSPACE
  exit 2
else
  if test $SIZE_DATADB_DBSPACE -lt 306431
  then
    echo WARNING - DBspace is $SIZE_DATADB_DBSPACE
    exit 1
  else
    echo OK - DBspace is $SIZE_DATADB_DBSPACE
    exit 0
  fi
fi


Agregarlo al Nagios con NRPE:

Si queremos agregar el monitoreo al nagios con NRPE nos basamos en este enlace que ya fue explicado:

Monitoreo Base de Datos Infomix con Nagios y NRPE

Creamos el script:

Lo llamamos como queremos, en mi caso le puse: check_informix.sh y colocamos lo siguiente dentro:

# vim /ruta/al/script/check_informix.sh

#!/bin/bash
sudo /usr/local/apps/informix/bin/onstat |grep On-Line > /tmp/informix-nagios.log
if test $? -eq 0
then
echo OK - DB On-Line
/usr/bin/rm /tmp/informix-nagios.log
exit 0
else
echo CRITICAL - DB Off-Line
exit 2
fi


Como llamarlo del NRPE:

Editamos el nrpe.conf con lo siguiente:

# vim /ruta/a/la/configuracion/del/nrpe/nrpe.cfg

command[check_stateDB]=/ruta/al/script/check_informix.sh


Reiniciamos el demonio del NRPE:

# ps -efa | grep nrpe

# kill -9 pid_del_proceso_nrpe

# /ruta/al/nrpe/folder/bin/nrpe -c /ruta/al/nrpe/folder/etc/nrpe.cfg -d


Lo agregamos en el services del nagios:

# vim /ruta/al/folder/de/nagios/etc/services.cfg

define service{
use                             generic-service
host_name                       Informix Server
service_description             Informix_State
check_command                   check_nrpe!check_stateDB
}

miércoles, 1 de agosto de 2012

Monitoreando Informix con Nagios

Server donde está instalado el informix:

1) Creamos el script para monitoreo:

# vim /ruta-de-nagios/nagios/libexec/check_informix.sh
#!/bin/bash
sudo /ruta-de-informix/informix/bin/onstat |grep On-Line > /tmp/informix-nagios.log
if test $? -eq 0
then
echo OK - DB On-Line
/usr/bin/rm /tmp/informix-nagios.log
exit 0
else
echo CRITICAL - DB Off-Line
exit 2
fi


2) Agregar al sudo el usuario nagios para que pueda ejecutar el comando onstat, ya que no puede ejecutarlo un user sin privilegios. Editamos el sudoers:

# vim /etc/sudoers
...
# Control de Accesos
User_Alias NAGIOS = nagios
...
# Cmnd alias specification
Cmnd_Alias CMD_ONSTAT = /ruta-del-informix/informix/bin/onstat
...
# User privilege specification
NAGIOS          ALL = NOPASSWD: CMD_ONSTAT


3) Configuramos en el archivo del NRPE el comando para ejecucion del script:

# vim /ruta-del-nagios/nagios/etc/nrpe.cfg
...
command[check_stateDB]=/ruta-del-nagios/nagios/libexec/check_informix.sh

Matamos el proceso del NRPE:
# ps -efa |grep nrpe
  nagios  2945   701   0   Jul 28 ?           0:36 /ruta-del-nagios/nagios/bin/nrpe -c /ruta-del-nagios/nagios/etc/nrpe.cfg -d

# kill -9 2945  

Volvemos a iniciarlo:
# /ruta-del-nagios/nagios/bin/nrpe -c /ruta-del-nagios/nagios/etc/nrpe.cfg -d

Chequeamos con el check_nrpe que este instalado correctamente y luego chequeamos con el comando creado:

# /ruta-del-nagios/nagios/libexec/check_nrpe -H localhost
NRPE "Muestra la versión instalada"

# /ruta-del-nagios/nagios/libexec/check_nrpe -H localhost -c check_stateDB
OK - DB On-Line


En el Servidor donde tenemos instalado el NAGIOS:

4) Lo agregamos al nagios, editando primero el host y luego el servicio:

# vim /ruta-del-nagios/nagios/etc/hosts.cfg
...
define host{
        use                     server            ; Name of host template to use
        host_name               informix_server
        alias                   informix_server
        address                 172.16.72.100  ; Ip del informix
        }
...

# vim /ruta-del-nagios/etc/services.cfg
...
define service{
use                             generic-service
host_name                       informix_server
service_description             Informix_State
check_command                   check_nrpe!check_stateDB
}
...

5) Chequeamos que no nos devuelva ningun error, ni ningun warning y reiniciamos el nagios:

# /ruta-del-nagios/nagios/bin/nagios -v /ruta-del-nagios/nagios/etc/nagios.cfg

# /etc/init.d/nagios reload

6) Chequeamos con el check_nrpe desde la CLI del server del nagios, especificando la ip del equipo del nagios y vemos que devuelve que el estado es OK. Si luego paramos el servicio del informix y volvemos a chequearlo nos devolvera CRITICAL.

# /ruta-del-nagios/nagios/libexec/check_nrpe -H 172.16.72.100 -c check_stateDB
OK - DB On-Line

martes, 3 de julio de 2012

Forzar apagado desde XenCenter

Hoy llego a la empresa y uno de las máquinas virtuales estaba baja, aparecía prendida pero cuando iba a la solapa de la consola veía todo en blanco, intento reiniciarla desde el XenCenter y me tira el siguiente error:

Error: "Another operation involving the object is currently in progress"


Ya me ha ocurrido otra vez y lo solucioné reiniciar la máquina base, ya que reiniciando la virtual ó forzando el apagado no me lo solucionaba.

 Hoy me volvió a ocurrir y llegué a la siguiente solución que encontré en el siguiente blog: http://hafizpariabi.blogspot.com.ar


Listamos las máquinas virtuales que corren en el XenServer:

# xe vm-list
uuid ( RO)           : 97221593-e4dc-ddc2-c7e2-fada7ff29dac
  name-label ( RW): VM-001
  power-state ( RO): running


Listamos los dominios para saber el ID:

# list_domainsid |                                 uuid |  state 1 |  97221593-e4dc-ddc2-c7e2-fada7ff29dac  |      H


Forzamos el apagado con el siguiente comando, donde -domid es el ID del comando previo:

# /opt/xensource/debug/destroy_domain -domid 1


Volvemos a listar los dominios y ahora veremos que no aparece:

# list_domains
id |                                 uuid |  state


Forzamos el reboot de la virtual, donde el uiid es el que obtenemos del primer comando ejecutado:

# xe vm-reboot uuid=97221593-e4dc-ddc2-c7e2-fada7ff29dac --force


FUENTE: http://hafizpariabi.blogspot.com.ar/2011/09/unable-to-shutdown-hang-vm-on-xenserver.html


lunes, 4 de junio de 2012

Testear un Servicio en Nagios sólo en horas laborales

Editamos el archivo timeperiods.cfg y colocamos lo siguiente dentro:

# vim /etc/nagios/timeperiods.cfg
define timeperiod{
        timeperiod_name HorasLaborales
        alias           "Trabajo" Horas Laborales
        monday          09:00-18:00
        tuesday         09:00-18:00
        wednesday       09:00-18:00
        thursday        09:00-18:00
        friday          09:00-18:00
        }


Editamos el archivo de servicios en el cuál deseamos sólo testear en horas laborales y agregamos la línea resaltada en rojo:

# vim /etc/nagios/services.cfg
define service{
use                             generic-service
host_name                       servidor
service_description             Mi_descripción
check_period                    HorasLaborales
check_command                   check_ping
}


Testeamos el archivo de configuración antes de reiniciar el nagios:

# /bin/nagios -v /etc/nagios/nagios.cfg
Total Warnings: 0
Total Errors:   0


Si el resultado del comando anterior nos dá como resultado 0 warnings y 0 errores reiniciamos el nagios con el siguiente comando:

# /etc/init.d/nagios reload

domingo, 20 de mayo de 2012

Monitorear con Nagios un proceso Python

En el Server que corre el Python (192.168.0.100):


Creamos el script para chequear el python:

server# vim /usr/local/apps/nagios/libexec/check_miPython
#!/bin/bash
/usr/bin/ps -efa |grep mi_python.py|grep -v grep > /tmp/mi_python.py.log
if test $? -eq 0
then
echo OK - Python mi_python.py is RUNNING
/usr/bin/rm /tmp/mi_python.py.log
exit 0
else
echo CRITICAL - Python mi_python.py is NOT RUNNING !!!
/usr/bin/rm /tmp/mi_python.py.log
exit 2
fi
NOTA: el 0 devuelve OK, el 1 WARNING y el 2 CRITICAL


Damos permisos de ejecución:
server# chmod a+x /usr/local/apps/nagios/libexec/check_miPython.sh


Editamos la configuración del NRPE y lo agregamos en la sección de comandos customizados:
server# vim /usr/local/apps/nagios/etc/nrpe.cfg
command[check_miPython]=/usr/local/apps/nagios/libexec/check_miPython


Matamos y volvemos a correr el nrpe:
server# ps -efa |grep nrpe
  nagios 24497     1   0 12:47:49 ?           0:00 /usr/local/nagios/bin/nrpe -d -c /usr/local/nagios/etc/nrpe.cfg
    root 24920 24763   0 12:57:59 pts/22      0:00 grep nrpe
server# kill -9 24497
server# /usr/local/nagios/bin/nrpe -d -c /usr/local/nagios/etc/nrpe.cfg


Lo testeamos:
server# /usr/local/nagios/libexec/check_miPython
OK - Python miPython is RUNNING


Cambiamos en el script el nombre del proceso para ver que realmente funciona y nos devuelve critical:
server# vim /usr/local/nagios/libexec/check_miPython
#Cambiamos mi_python.py por mi_piton.py
#en la línea: /usr/bin/ps -efa |grep mi_python.py|grep -v grep > /tmp/mi_python.py.log


Volvemos testear y ahora nos devuelve CRITICAL:
server# /usr/local/nagios/libexec/check_miPython
CRITICAL - Python miPython is NOT RUNNING !!!

Volvemos a cambiarlo para que funcione correctamente como estaba anteriormente.


Ahora vamos al server del nagios para agregar al monitoreo:



Testeamos el servicio mediante el check_nrpe:
nagios# /usr/local/nagios/libexec/check_nrpe -H 192.168.0.100 -c check_miPython
OK - Python miPython is RUNNING


Editamos el archivo services.conf:
nagios# vim /usr/local/nagios/etc/services.cfg
..... define service{
use                             generic-service
host_name                       pythonServer
service_description             mi_Python
check_command                   check_nrpe!check_miPython
}
        .....


Checkeamos la config del nagios:
nagios# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg


Reiniciamos el servicio de nagios:
nagios# /etc/init.d/nagios reload