Blog de Iván López: febrero 2008

Cuando utilizaba RedHat, SuSE o Slackware hace algún tiempo para probar y cacharrear o simplemente para hacer las prácticas de la facultad y tenía que instalar algún programa no tenía ningún problema en compilarlo e instalarlo "a lo loco" e incluso trabajar como root. Por aquel entonces, aunque linux me gustaba sólo lo utilizaba como una ayuda durante la carrera para no tener que pasarme las horas en el centro de cálculo pegándome por un terminal VT100 de fósforo verde que me destrozaba la vista. Qué tiempos aquellos... y eso que "sólo" han pasado 10 años desde aquel 1997 en que empecé la carrera (que por cierto ya terminé).

En fin, que compilaba, hacía make install y no me preocupaba de desinstalar ni de cómo podía quedar el sistema después de eso (total, lo reinstala y punto, no me suponía demasiado). Ahora, desde que utilizo linux como mi sistema operativo principal me preocupa que si me pongo a compilar e instalar compulsivamente o simplemente quiero probar algo, luego me resulte complicado mantener el control de lo que está instalado, desinstalarlo con facilidad,... Aunque con el magnífico apt este problema desaparece para cualquier paquete que descarguemos, en el caso de las compilaciones o de utilidades de las que no existan paquetes .deb la cosa es más compleja. Así, he descubierto un par de utilidades que me van a hacer la vida aún más fácil: alien y checkinstall.

Alien: En ocasiones no hay paquetes en formato .deb pero sin embargo sí existen en formato .rpm. Con esta utilidad los podemos convertir a nuestro formato favorito.

Checkinstall: Cuando compilamos un programa, el paso final suele ser make install que instala los binarios, las librerías, la ayuda del man,... En muy pocas ocasiones viene con un target uninstall del make, por lo que una posterior tarea de desinstalación suele ser algo tediosa. Checkinstall sirve para crear paquetes .deb a partir del código compilado, por lo que si posteriormente queremos desinstalar algo sólo hay que hacer un simple apt-get remove paquete.

Instalarlos es algo tan sencillo como:

ivan@doraemon:~$ sudo apt-get install checkinstall alien

Para convertir los paquetes con alien hacemos:

ivan@doraemon:~$ sudo alien -d paquete.rpm

Y una vez convertido lo podemos instalar como siempre:

ivan@doraemon:~$ sudo dpkg -i paquete.deb

Si por el contrario tenemos el código fuente para compilarlo utilizaremos checkinstall, para ello hacemos:

ivan@doraemon:~$ tar zxvf paquete.tar.gz
ivan@doraemon:~$ cd paquete
ivan@doraemon:~/paquete $ ./configure
ivan@doraemon:~/paquete $ make
ivan@doraemon:~/paquete $ sudo checkinstall

Y después de unas cuantas preguntas tendremos creado nuestro paquete.deb listo para instalar y mantener.

Nagios es un sistema de código abierto de monitorización de redes, máquinas, servicios, sistemas, filesystems... muy flexible que permite definir distintos tipos de alertas en función de la disponibilidad de los objetos monitorizados.

En mi anterior trabajo lo instalé y configuré para monitorizar distintos entornos que gestionábamos y también para la monitorización remota de filesystems. He rescatado el pequeño documento que hice en su momento y este es el resultado después de completarlo con explicaciones más detalladas, ejemplos y alguna captura.

Lo primero que debo aclarar es que está basado en la versión 2.4 de Nagios, siendo la versión estable actual la 2.10. No debería haber muchas diferencias por lo que supongo que todo lo que voy a contar funcionará sin problemas. La máquina en la que monté el servidor Nagios es una Sun Fire 280R con Solaris 8 y obviamente no tenía permisos de root, por lo que la instalación está hecha con un usuario normal (vtprov) siendo su home /internet/vtprov. Además, al ser una máquina con Solaris no hay paquetes de binarios ya compilados, por lo que toca compilar desde el código fuente. El caso de la instalación para Linux debería ser similar.

Instalación
Después de descargar y desempaquetar el .tar generamos el fichero Makefile:

$ ./configure --prefix=PREFIX --with-nagios-user=SOMEUSER --with-nagios-group=SOMEGROUP

Donde: PREFIX es la ruta en donde queremos instalar y que llamaremos $NAGIOS_HOME.
SOMEUSER es el usuario que ejecutará Nagios.
SOMEGROUP es el grupo del usuario que ejecutará Nagios.
Después simplemente compilamos:

$ make all

Y finalmente instalamos en la ruta que hayamos configurado anteriormente:

$ make install

   Para comprobar el estado de los servicios, sistemas,... Nagios utiliza diversos plugins programados en C. Es necesario descargar y compilar dichos plugins e instalarlos en Nagios. La utilización de plugins hace que Nagios sea muy potente respecto a los sistemas que puede monitorizar puesto que si no existe ningún plugin que nos interese, siempre es posible crear uno a medida.
   La compilación de los plugins es exáctamente igual a la de Nagios y una vez compilados deben almacenarse en el directorio $NAGIOS_HOME/libexec.

Configuración
   Nagios se configura mediante archivos de texto que se encuentran en $NAGIOS_HOME/etc. Los principales archivos son:

nagios.cfg: Es el archivo principal de Nagios. En él, además de diversas opciones de configuración se definen las rutas del resto de archivos de configuración. Podemos elegir si queremos un archivo con toda la configuración o múltiples archivos más pequeños. En mi caso elegí un único archivo.

checkcommands.cfg: En este archivo se define el nombre lógico y físico de los comandos de monitorización que se utilizarán así como los parámetros de reciben.

misccommands.cfg: Se definen las plantillas que se utilizarán para los emails de notificación.

bigger.cfg: Archivo principal en el que se configuran los servicios que se desean monitorizar, notificaciones, comandos para la monitorización, agrupación de servicios,...

A continuación muestro con un poco más de detalle los archivos de configuración y añado ejemplos de configuración. Sólo he seleccionado algunas partes concretas puesto que algunos son muy grandes y tienen muchas opciones. Cada una de ellas viene con una pequeña explicación sobre su utilización.

nagios.cfg
Hay que prestar especial atención a la opción check_external_commands puesto que sin habilitarla no podremos comprobar el estado de un servicio que deseemos en un momento determinado, sino que sólo se ejecutará la comprobación según se haya planificado.

# OBJECT CONFIGURATION FILE(S)

# Plugin commands (service and host check commands)
cfg_file=/internet/vtprov/nagios/etc/checkcommands.cfg

# Misc commands (notification and event handler commands, etc)
cfg_file=/internet/vtprov/nagios/etc/misccommands.cfg

# You can split other types of object definitions across several
# config files if you wish (as done here), or keep them all in a
# single config file.
cfg_file=/internet/vtprov/nagios/etc/bigger.cfg

# NAGIOS USER
nagios_user=vtprov

# NAGIOS GROUP
nagios_group=users

# EXTERNAL COMMAND OPTION
# This option allows you to specify whether or not Nagios should check
# for external commands (in the command file defined below).  By default
# Nagios will *not* check for external commands, just to be on the
# cautious side.  If you want to be able to use the CGI command interface
# you will have to enable this.  Setting this value to 0 disables command
# checking (the default), other values enable it.

check_external_commands=1
[...]

checkcommands.cfg
   Estos son algunos de los comandos (plugins) que podemos usar para comprobar el estado de los servicios. Por ejemplo, el comando check_http realiza una simple llamada GET a la máquina definida en el parámetro $ARG1$, al puerto $ARG2$ y a la URL $ARG3$. Esta llamada la usábamos para comprobar el estado de diversos servlets que estaban corriendo en distintas instancias de servidores tomcat.
   El comando check_http_wm es una personalización del anterior (fijaos que el command_line es el mismo) pero se conecta con un usuario y password que pasamos como parámetro.
   También muestro el ejemplo del ping y también el comando check_nrpe que veremos posteriormente para ejecutar scripts en máquinas remotas y en función del resultado lanzar o no una alarma.

define command{
    command_name    check_ping
    command_line    $USER1$/check_ping -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$ -p 5
}

define command{
    command_name    check_http
    command_line    $USER1$/check_http -H $ARG1$ -p $ARG2$ --url=$ARG3$
}

define command{
    command_name    check_http_wm
    command_line    $USER1$/check_http -H $ARG1$ -p $ARG2$ -a USER:PASSWD
} 
        
define command{
    command_name    check_nrpe
    command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -p $ARG1$ -c $ARG2$ -a $ARG3$ $ARG4$ $ARG5$
}

misccommands.cfg
En mi caso cambié el command_line que venía por defecto por el que muestro a continuación puesto que así se envía más información en la alerta que nos llega por email.

# 'notify-by-email' command definition
define command{
 command_name notify-by-email
 command_line /usr/bin/printf "Subject: ** $NOTIFICATIONTYPE$ alert - $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ ** %b\n\n ***** Nagios  *****\n\nNotification Type: $NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $LONGDATETIME$\n\nAdditional Info:\n\n$SERVICEOUTPUT$" | /usr/bin/mail $CONTACTEMAIL$
}

bigger.cfg
Como ya he comentado este es el archivo de configuración en el que damos de alta todos los servicios que queremos monitorizar. Además, también definimos los periodos de monitorización, usuarios, agrupamos los servicios,...

Definición de periodos en los cuales se notifican los cambios de estado de los servicios. En este caso definimos dos: 24x7 y Workhours. Luego, al dar de alta un servicio para monitorizar le asociamos uno de estos periodos, de tal forma que sólo se envían notificaciones si estamos en el periodo definido.

# '24x7' timeperiod definition
define timeperiod{
    timeperiod_name   24x7
    alias             24 Hours A Day, 7 Days A Week
    sunday            00:00-24:00
    monday            00:00-24:00
    tuesday           00:00-24:00
    wednesday         00:00-24:00
    thursday          00:00-24:00
    friday            00:00-24:00
    saturday          00:00-24:00
}

# 'workhours' timeperiod definition
define timeperiod {
    timeperiod_name   Workhours
    alias             "Normal" Working Hours
    monday            08:00-19:00
    tuesday           08:00-19:00
    wednesday         08:00-19:00
    thursday          08:00-19:00
    friday            08:00-15:00
}

Definición de grupos de notificación. Los emails a los que notificar separdados por comas y el periodo de notificación definido anteriormente.

# 'vt-prov' contact definition
define contact {
    contact_name                    vt-prov
    alias                           Nagios Admin
    service_notification_period     24x7
    host_notification_period        24x7
    service_notification_options    w,u,c,r
    host_notification_options       d,u,r
    service_notification_commands   notify-by-email
    host_notification_commands      host-notify-by-email
    email                           user1@empresa.com,user2@empresa.com
}

Definición de máquinas y agrupación de las mismas.

# 'host1' host definition
define host{
    use                     generic-host
    host_name               host1
    alias                   Servidor host1
    address                 172.24.88.169
    check_command           check-host-alive
    max_check_attempts      10
    check_period            24x7
    notification_interval   120
    notification_period     24x7                 
    notification_options    d,u,r                
    contact_groups          vt-prov              
}                                                
                                                 
# 'solaris-servers' host group definition        
define hostgroup{                                
    hostgroup_name   solaris-servers             
    alias            Solaris Servers             
    members          host1,host2,host4,host6     
}

Definición de servicios a monitorizar: Esta es la parte más importante y es donde realmente damos de alta todos los servicios que deseamos monitorizar. Como ejemplo muestro el ping para saber si la máquina está activa, la comprobación de un servicio corriendo en un tomcat y la ocupación de un filesystem:
Ping

define service{                             
    use                    generic-service                          
    host_name              host1                               
    service_description    PING
    is_volatile            0
    check_period           24x7
    max_check_attempts     4
    normal_check_interval  1
    retry_check_interval   1
    contact_groups         vt-prov
    notification_interval  120
    notification_period    24x7
    notification_options   w,u,c,r
    check_command          check_ping!100.0,20%!500.0,60%
}

Servlet en Tomcat

define service{
    use                    generic-service
    host_name              host2
    service_description    ENTORNO1 - Servicio2
    is_volatile            0 
    check_period           24x7
    max_check_attempts     1
    normal_check_interval  5
    retry_check_interval   1
    contact_groups         vt-prov
    notification_interval  10
    notification_period    24x7
    notification_options   w,u,c,r
    check_command          check_http!host2!10102!/servicio/jsp/autent/login.jsp
}

Ocupación Filesystem

define service{
    use                    generic-service
    host_name              host2
    service_description    host2 - /var
    is_volatile            0 
    check_period           24x7
    max_check_attempts     1
    normal_check_interval  5
    retry_check_interval   1
    contact_groups         vt-prov
    notification_interval  120
    notification_period    24x7
    notification_options   w,u,c,r
    check_command          check_nrpe!7997!check_disk!7!5!/var
}

Agrupación de servicios en un grupo: De esta forma se actua sobre todo el grupo a la vez. Esto es útil cuando por ejemplo hay una intervención en una máquina o se está actualizando un entorno completo y se quieren deshabilitar todas las alarmas de ese entorno a la vez.

define servicegroup{
    servicegroup_name      ENTORNO1 - TOMCATs
    alias                  ENTORNO1 - TOMCATs
    members                host2,ENTORNO1 - Servicio2,host2,ENTORNO1 - Servicio3,host2,ENTORNO1 - Servicio8
}

Una vez definidos los servicios que deseamos monitorizar, podemos verificar si el archivo de configuración es correcto o contiene algún error. Desde el directorio $NAGIOS_HOME/bin:

$ nagios -v ../etc/nagios.cfg
Nagios 2.4
Copyright (c) 1999-2006 Ethan Galstad (http://www.nagios.org)
Last Modified: 05-31-2006
License: GPL

Reading configuration data...

Running pre-flight check on configuration data...

Checking services...
        Checked 82 services.
Checking hosts...
        Checked 5 hosts.
Checking host groups...
        Checked 1 host groups.
Checking service groups...
        Checked 16 service groups.
Checking contacts...
        Checked 1 contacts.
Checking contact groups...
        Checked 1 contact groups.
Checking service escalations...
        Checked 0 service escalations.
Checking service dependencies...
        Checked 0 service dependencies.
Checking host escalations...
        Checked 0 host escalations.
Checking host dependencies...
        Checked 0 host dependencies.
Checking commands...
        Checked 26 commands.
Checking time periods...
        Checked 4 time periods.
Checking extended host info definitions...
        Checked 0 extended host info definitions.
Checking extended service info definitions...
        Checked 0 extended service info definitions.
Checking for circular paths between hosts...
Checking for circular host and service dependencies...
Checking global event handlers...
Checking obsessive compulsive processor commands...
Checking misc settings...

Total Warnings: 0
Total Errors:   0

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

Como no hay ningún error podemos arrancar Nagios:

$ nagios -d ../etc/nagios.cfg

En este momento se empezarían a monitorizar los sistemas que tengamos definidos y se enviarían notificaciones por email si se han configurado.

Interfaz Web
Para poder interactuar con el sistema y ver todo de un modo gráfico es necesario configurar la consola web de Nagios. Para ello es necesario un servidor Apache. Instalamos el servidor y en el archivo httpd.conf añadimos lo siguiente:

ScriptAlias /nagios/cgi-bin "/internet/vtprov/nagios/sbin/"
    <Directory "/internet/vtprov/nagios/sbin">
        AllowOverride AuthConfig
        Options +ExecCGI
        Order allow,deny
        Allow from all
    </Directory>

    Alias /nagios "/internet/vtprov/nagios/share"
    <Directory "/internet/vtprov/nagios/share">
        Options None
        AllowOverride AuthConfig
        Order allow,deny
        Allow from all
    </Directory>

Reiniciamos apache y ya nos deberíamos poder conectar a la consola de administración:

Control de Acceso
Se pueden definir distintos usuarios para conectarse a Nagios con diferentes permisos y que verán únicamente los servicios en los que se hayan añadido como contacto. Para ello utilizamos las opciones de autenticación que ofrece Apache.
Creamos el archivo .htaccess en los directorios share y sbin con el siguiente contenido:

AuthName "Acceso a Nagios"
AuthType Basic
AuthUserFile /internet/vtprov/nagios/etc/htpasswd.users
require valid-user

Y creamos el archivo de passwords desde el directorio bin de la instalación de Apache añadiendo el usuario nagios.

$ htpasswd -c /internet/vtprov/nagios/etc/htpasswd.users nagios

Ahora al conectarnos a Nagios nos aparecerá la típica ventana solicitando nuestro usuario y password.

Comandos remotos
Para poder ejecutar scritps en máquinas remotas, como por ejemplo, para comprobar el tamaño de los filesystems de otras máquinas, necesitamos instalar un pequeño servidor en dichas máquinas. Este servidor se llama NRPE (Nagios Remote Plugin Executor). Es necesario descargarlo y compilarlo tal y como hemos hecho con Nagios.

La configuración es muy sencilla: En cada máquina que queramos monitorizar la ocupación de sus filesystems debemos configurar el archivo nrpe.cfg en el que básicamente hay que indicar el puerto en el que queremos levantar el servidor, el usuario y el grupo que lo ejecutan y activar la opción para permitir recibir comandos remotos con parámetros. El fichero de configuración tiene el siguiente aspecto (como antes, incluyo sólo lo más importante).

# PORT NUMBER
server_port=7997

# SERVER ADDRESS
server_address=172.24.88.169

# ALLOWED HOST ADDRESSES
# This is a comma-delimited list of IP address of hosts that are allowed
# to talk to the NRPE daemon.
allowed_hosts=127.0.0.1,172.24.86.11

# NRPE USER
nrpe_user=nrpe

# NRPE GROUP
nrpe_group=users

# COMMAND ARGUMENT PROCESSING
# This option determines whether or not the NRPE daemon will allow clients
# to specify arguments to commands that are executed.  This option only works
# if the daemon was configured with the --enable-command-args configure script
# option.  
#
# *** ENABLING THIS OPTION IS A SECURITY RISK! *** 
# Read the SECURITY file for information on some of the security implications
# of enabling this variable.
#
# Values: 0=do not allow arguments, 1=allow command arguments
dont_blame_nrpe=1

# COMMAND DEFINITIONS
command[check_disk]=/home/user/nrpe/check_disk.sh $ARG1$ $ARG2$ $ARG3$

   Hay que destacar la opción dont_blame_nrpe ya que tal y como se indica activarla puede representar un problema de seguridad porque estamos aceptando parámetros y podría realizarse algún tipo de ataque a la máquina por este medio. En mi caso lo habilité porque el script que comprueba el tamaño del filesystem necesita dichos parámetros y no representaba ningún problema de seguridad.
   Al final también hemos añadido el comando remoto que se ejecutará (check_disk) y la llamada al script con los parámetros necesarios. Este script debe existir en la máquina de la que deseamos monitorizar los filesystems.

   Recordemos que antes definimos la ejecución del script check_disk (para un filesystem y máquina concretos) como:

check_nrpe!7997!check_disk!7!5!/var

En esta llamada 7997 es el puerto del nrpe en la máquina remota, check_disk es el nombre lógico del script y 7, 5 y /var son los parámetros del script. Éste comprueba el porcentaje de espacio libre del filesystem que recibe como parámetro y lo compara con los dos umbrales que le pasamos. Si es menor de un 7% genera un warning y si es menor de un 5% genera un error crítico.

El script check_disk.sh que acabamos de ver y que definíamos anteriormente en el archivo bigger.cfg es el siguiente:

#!/bin/ksh
# check_disk.sh: Comprueba el tamaño de un filesystem y 
# devuelve el estado en función de dos umbrales definidos.
#
# Iván López Martín

warning=$1
critical=$2
filesystem=$3

STATE_OK=0
STATE_WARNING=1
STATE_CRITICAL=2

size=`df -k $filesystem | grep $filesystem | awk '{print $4}'`
sizeMB=`echo "$size/1024" | bc`
percentage=`df -k $filesystem | grep $filesystem | awk '{print $5}' | sed -e s/%//g`
freePercentage=`echo "100-$percentage" | bc`

if [ "$freePercentage" -le "$critical" ]; then
   echo "DISK CRITICAL - free space: "$filesystem" $sizeMB MB"
   return $STATE_CRITICAL
fi
if [ "$freePercentage" -le "$warning" ]; then
   echo "DISK WARNING - free space: "$filesystem" $sizeMB MB"
   return $STATE_WARNING
fi

echo "DISK OK - free space: "$filesystem" $sizeMB MB"
return $STATE_OK

Con los scripts remotos configurados arrancamos el demonio nrpe:

$ nrpe -c nrpe.cfg -d

   Como veis, me he hecho mi propio script para comprobar remotamente los filesystems de las distintas máquinas. Aunque dije inicialmente que los plugins que vienen con Nagios están escritos en C, se puede utilizar cualquier lenguaje que soporte la máquina para comprobar el estado del servicio que deseemos.

   Este script nos era especialmente útil sobre todo para comprobar la ocupación del filesystem /var. Cuando veíamos que estaba bastante lleno sólo teníamos que enviar un email a administración Unix para que borrasen logs antiguos y nos liberaran algo de espacio.

Interfaz gráfica
   A continuación muestro una serie de capturas de pantalla de la interfaz gráfica con todos los servicios que teníamos configurados en su momento.


Servicios	Máquinas


Agrupación de servicios	Opciones de servicios

Conclusiones
Lo que más me gusta de Nagios es que es muy sencillo de configurar y que con el simple hecho de dar de alta un servicio, automáticamente ya lo estamos monitorizando.
En su momento también probé herramientas como Hyperic HQ y aunque visualmente son más bonitas, descubren automáticamente los servicios que hay corriendo en las máquinas,... al final son más engorrosas. En mi caso, en algunas máquinas descubría "demasiados" servicios y había que estar eliminando todos los que no queríamos monitorizar. Además, había que definir una a una las alarmas para cada uno de esos servicios. Al final, después de probarla durante un tiempo la descarté y me quedé con Nagios.

Blog de Iván López

miércoles, 27 de febrero de 2008

El código Geek

miércoles, 20 de febrero de 2008

Crear paquetes deb desde otros formatos

lunes, 11 de febrero de 2008

Monitorizando sistemas con Nagios

martes, 5 de febrero de 2008

Primer Viernes Técnico de OpenSolaris