agente nagios para linux

29 de abril de 2011

Si tenemos Nagios, podemos monitorizar maquinas remotas utilizando el agente de Nagios para Linux o para Windows.
Si la maquina remota es un Windows, podemos instalar el NSClient++. Si la maquina es un Linux, podemos instalar el NRPE. Explicaré cómo se instala el NRPE y cómo se configura Nagios para hacer consultas a esta maquina remota.

Tenemos que tener presente dos tipos de maquinas: la maquina con Nagios Server (por ejemplo 192.168.1.2) y la maquina remota (por ejemplo 192.168.1.3). El funcionamiento es el siguiente: en los dos extremos hay que instalar un NRPE de forma que el daemon de la maquina remota ejecutará los comandos que nosotros definamos, por ejemplo check_disck, check_swap, check_users, check_oracle, etc.

En la maquina remota hacemos:

# wget http://prdownloads.sourceforge.net/sourceforge/nagiosplug/nagios-plugins-1.4.15.tar.gz
# wget http://prdownloads.sourceforge.net/sourceforge/nagios/nrpe-2.12.tar.gz

# useradd nagios
# passwd nagios
Nota: recomiendo editar el /etc/passwd y ponerle un Shell /bin/false a este usuario para que no pueda hacer Login en el sistema.
# tar -xzvf nagios-plugins-1.4.15.tar.gz
# cd nagios-plugins-1.4.15
# export LDFLAGS=-ldl
# ./configure --with-nagios-user=nagios --with-nagios-group=nagios
# make
# make install 
# chown nagios.nagios /usr/local/nagios
# chown -R nagios.nagios /usr/local/nagios/libexec/

# apt-get install xinetd libssl-dev
# tar xvfz nrpe-2.12.tar.gz
# cd nrpe-2.12

# ./configure
# make all
# make install-plugin
# make install-daemon
# make install-daemon-config
# make install-xinetd
Editar /etc/xinetd.d/nrpe para aceptar peticiones solo de nuestro Nagios Server:
only_from       = 127.0.0.1 192.168.1.2
La IP 192.168.1.2 es la de nuestra maquina Nagios Server.
# /etc/init.d/xinetd restart
Pruebas de funcionamiento:
# netstat -ant | grep 5666
tcp        0      0 0.0.0.0:5666            0.0.0.0:*               LISTEN  
# /usr/local/nagios/libexec/check_nrpe -H localhost
NRPE V2.12
Modificar los comandos disponibles para nuestra maquina remota. Editar el /usr/local/nagios/etc/nrpe.cfg y modificar los comandos a nuestro gusto. Yo he creado una consulta llamada check_disk que me dirá el estado de disco /dev/sda1:
command[check_disk]=/usr/local/nagios/libexec/check_disk -w 20% -c 10% -p /dev/sda1
En la maquina Nagios Server hacemos:
# wget http://prdownloads.sourceforge.net/sourceforge/nagios/nrpe-2.12.tar.gz
# apt-get install libssl-dev
# cd nrpe-2.1.2
# ./configure
# make all
# make install-plugin
Prueba de funcionamiento:
# /usr/local/nagios/libexec/check_nrpe -H 192.168.1.3
NRPE V2.12
# /usr/local/nagios/libexec/check_nrpe -H 192.168.1.3 -c check_disk
DISK OK - free space: / 33010 MB (96% inode=97%);| /=1126MB;28771;32367;0;35964
Ahora solo queda configurar nuestro Nagios Server para que utilice el comando check_nrpe:
define service{
   use generic-service
   host_name remotehost
   service_description Current Users
   check_command check_nrpe!check_disk
}
Más informacion:
+ http://nagios.sourceforge.net/docs/nrpe/NRPE.pdf

caida ldap

13 de abril de 2011

Hoy se ha ido la luz y nos ha echado abajo el servidor de Samba. Como consecuencia al reiniciar el servidor se ha quedado corrupto el LDAP con el siguiente error:

[root@fileserver]# /etc/init.d/ldap start
Checking configuration files for slapd: bdb_db_open: unclean shutdown detected; attempting recovery.
bdb_db_open: Recovery skipped in read-only mode. Run manual recovery if errors are encountered.
bdb_db_open: Database cannot be opened, err 13. Restore from backup!
bdb(dc=XXXXXX,dc=com): DB_ENV->lock_id_free interface requires an environment configured for the locking subsystem
backend_startup_one: bi_db_open failed! (13)
slap_startup failed (test would succeed using the -u switch)
[FAILED]
stale lock files may be present in /var/lib/ldap [WARNING]
Antes de restaurar el backup hemos probado un: http://www.blogger.com/img/blank.gif
[root@fileserver]# /usr/sbin/slapd_db_recover -v -h /var/lib/ldap
Finding last valid log LSN: file: 1 offset 5315883
Recovery starting from [1][5315755]
Recovery complete at Sun Jul 30 11:31:56 2006
Maximum transaction ID 8000040d Recovery checkpoint [1][5315883]

Para restauraciones más críticas podemos hacer un backup en texto de tú arbol LDAP, corregir los errores y volver a recrear el arbol de LDAP. En este post hay un buen ejemplo: http://blog.mydream.com.hk/howto/linux/openldap-recovery-howto

envolviendo el vsftp

4 de abril de 2011

Al intentar poner un servicio público en Internet, te das cuenta de la cantidad de intentos de acceso que hay al cabo de un día. Al final, te queda la duda de si pueden o no llevar buen puerto.
Si eres de esos de que leen los Logs cada día o de lo que reciben su Logwatch oportuno, te darás cuenta de estos intentos:

--------------------- pam_unix Begin ------------------------ 
 vsftpd:
    Unknown Entries:
       check pass; user unknown: 168 Time(s)
       authentication failure; logname= uid=0 euid=0 tty=ftp ruser=administrator rhost=thirdeyemedia.net : 82 Time(s)
       authentication failure; logname= uid=0 euid=0 tty=ftp ruser=administrador rhost=thirdeyemedia.net : 59 Time(s)
       authentication failure; logname= uid=0 euid=0 tty=ftp ruser=anonymous rhost=host217-40-235-141.in-addr.btopenworld.com : 17 Time(s)
       authentication failure; logname= uid=0 euid=0 tty=ftp ruser=Administrator rhost=113.107.101.249 : 168 Time(s)
       check pass; user unknown: 168 Time(s)
Para bannear estas IPs, lo puedes realizar de dos formas diferentes: o las cierras directamente en tú firewall perimetral, o lo cierras en el firewall del propio servidor o lo cierras con tcpwrappers.

El concepto de tcpwrappers consiste en envolver tú daemon TCP/UDP en un envoltorio el cual analiza el paquete de red antes de enviárselo a tú daemon. Tcpwrapper permite controlar los accesos a los servicios ofrecidos por el sistema ya sea por máquina, por servicio o por combinaciones de ambos. Para ello el daemon de tcpwrapper llamado “tcpd” lee los archivos de configuración /etc/hosts.allow y /etc/hosts.deny. El primer archivo contie las reglas que especifican las máquinas y servicios que están autorizados y el segundo las maquinas y servicios que no están autorizados.
Personalmente me gusta este sistema porque es posible denegar estas conexiones por un administrador que no tiene acceso a su Firewall porque este está administrador por otro conjunto de personas y además no es necesario rebotar nigún servicio.


En este ejemplo real vamos a denegar los accesos de 113.107.101.249, 217.40.235.141 y 64.40.107.210, que corresponden a diferentes ataque al servicio FTP. Primero de todo verificaremos que el servicio de FTP está compilidado para poder utilizar TCPWrappers:
# whereis vsftpd
vsftpd: /usr/sbin/vsftpd /etc/vsftpd /usr/share/man/man8/vsftpd.8.gz
# ldd /usr/sbin/vsftpd | grep libwrap
        libwrap.so.0 => /lib/libwrap.so.0 (0x0046c000)
Una vez vemos que la librería está cargada, podemos editar el /etc/hosts.deny y meter todas las IP necesarias:
vsftpd: 113.107.101.249, 217.40.235.141, 64.40.107.210
Podemos bloquear también por rangos o por subredes:
vsftpd: 113.107.101.0/255.255.255.0
Podemos denegar todos los accessos a cualquier servicio:
ALL: 113.107.101.0/255.255.255.0
O incluso podemos dejar un mensajito:
vsftpd : .elhacker.net \
: twist /bin/echo "421 %h has been banned from this server!"
Si queremos ver todos los servicios TCP que están compilados para utilizar TCPWrappers, podemos hacer:
# strings -f /usr/sbin/* | grep hosts_access
/usr/sbin/rpc.mountd: hosts_access
/usr/sbin/sshd: hosts_access
/usr/sbin/stunnel: hosts_access
/usr/sbin/stunnel: See hosts_access(5) manual for details
/usr/sbin/tcpd: hosts_access_verbose
/usr/sbin/vsftpd: hosts_access
Más información:
+ http://linux.web.cern.ch/linux/scientific4/docs/rhel-rg-en-4/s1-tcpwrappers-access.html

migrando a mpls

7 de diciembre de 2010

cuantas visitas tendre

27 de noviembre de 2010

Acabo de leer un artículo muy interesante sobre las tendencias de las personas al hacer click sobre los resultados aparecidos en Google al realizar una búsqueda.

La Universidad de Cornell ha realizado un estudio llamado "Eye-Tracking Analysis of User Behavior in WWW Search" en el cual se concluye que si tú pagina aparece en la primera posición del buscador tendrás un 56% de posibilidades que finalmente esa persona clique sobre tú Web. Para cualquier SEO este estudio puede ser muy interesante porque le puede ayudar a que un cliente comprenda cuantas visitas puede llegar a recibir si se encuentra bien situado en las búsquedas de Google.

En la siguiente imagen se muestra cómo mira el ojo humano la pagina de Google tras realizar un búsqueda:

La siguiente muestra el % de clicks que se llevaría una pagina si el usuario escogiera esa opción.

Pongamos un ejemplo. Supongamos que mi pagina Web es www.amperisblog.com y que he escrito un articulo que explica cómo bloquear el programa Ultrasurf. Supongamos también que con mi estudio de SEO y con varios meses de trabajo he conseguido posicionar mi página para que aparezca en las primeras posiciones cuando la gente realiza la busqueda “bloquear ultrasurf”. Cómo veis mí pagina aparece en tercera opción (aun me queda un duro trabajo de SEO para posicionarme más arriba).


Ahora veamos desde la utilidad Google Adwords (Herramientas para palabras clave) que la busqueda “bloquear ultrasurf” se realiza 2.400 veces al mes en todo el mundo.


Por tanto: (2400 * 9,82) / 100 = 235 visitas.

Es decir, que cada mes mí página recibirá (aproximadamente) 235 visitas por aparecer en la tercera opción.

Ahora supongamos que soy el dueño de la Web www.softonic.com (creo nadie la cononoce ¿no?). Supongamos que con mi estudio de SEO me he podido posicionar en primera opción cuando alguien busca “descargar software gratis”.
Si miramos en Google Adword, vemos que esta búsqueda se hace un millón de veces al mes.

Por tanto: (1000000 * 56,36) / 100 = 563600 visitas.

Cada mes, Softonic recibe una media de 560.000 visitas cuando la gente busca el termino “descargar software gratis”.

atenuación y ruido

31 de octubre de 2010

Cuando nos instalan una ADSL, SDSL o una ADSL2+ los valores de atenuación y ruido son los que nos marcan la velocidad final de esta.
La mayoría de routers tienen acceso a la consulta de estos dos valores. Cuando un técnico nos coloca una xDSL lo primero que mira son estos valores y nos dice: "uff estás un poco lejos de la central y no te daremos la velocidad que has contratado". Naturalmente el router muestra valores aproximados de la atenuación y ruido ya que no son dispositivos pensados para este fin. Existen dispositivos específicos de telecomunicaciones que inyectan señales sinusoidales a diferentes frecuencias y potencias para medir la atenuación final del cable.

La atenuación es la pérdida de señal sufrida al trasmitirse esta por el cable. Características como la distancia del cable (por ejemplo el bucle del abonado), resistencia del cable, tipo de cable, empalmes, vejez del cable, etc, hacen que tengamos una mayor o menor atenuación. La atenuación la encontraremos medida en decibelios (dB). Contra más grande es esta medida peor será nuestra velocidad final.

Tenemos que tener presente también que al pasar de ADSL a ADSL2+ sufriremos mayor atenuación debido a que ADSL funciona a 0,5Mhz y ADSL2+ a 4,4Mhz.
Este aumento de la frecuencia de la señal provoca un aumento de la impedancia del cable y por tanto una mayor resistencia de este.

Los valores óptimos de atenuación según la velocidad que hayamos contratado con el proveedor son:

+ Para 256kbps: 64dB
+ Para 512kbps: 55dB
+ Para 1Mbps (ADSL): 41dB
+ Para 6Mbps (ADSL): 30dB
+ Para 20Mbps (ADSL2+): 20dB

El caso del ruido serán todas las señales externas que perturben nuestra señal útil de la xDSL. Por la propia naturaleza del ruido, este será imposible eliminarlo, pero si podemos reducirlo haciendo una buena instalación. Lo que miden los routers no es exactamente el ruido sino la relación/margen entre la señal y el ruido. El SNR o Signal to noise ratio es el margen que hay entre la potencia de la señal que se quiere transmitir y la potencia del ruido que corrompe nuestra señal. Este margen también se mide en dB y contra más grande mejor para nuestra xDSL.

Los valores óptimos de SNR según la velocidad que hayamos contratado con el proveedor son:

+ 6dB o menos: conexión inexistente
+ Entre 7db y 10 dB: conexión y desconexiones u otros problemas
+ Entre 11 y 20 dB: Señal optima
+ 21 o más dB: Señal excelente

En el caso de un router Cisco, podemos utiliza el comando "show dsl interface atm" para consultar estos valores.

A continuación un ejemplo real de una ADSL2+ de 20Mbps (que no llega, se quedaría en unos 15Mbps).

monitorizando tu bes

1 de agosto de 2010

La "Blackberry Enterprise Sever Resource Kit" son unas utilidades que nos pueden permitir leer de forma más clara los ficheros de Logs que genera el BES. Explicaré algunas utilidades que estoy utilizando últimamente y que pueden hacer la vida más fácil a quien no esté familiarizado con la administración de un BES.

Para instalar el Resource Kit basta con descargarlo de Downloads y descomprimirlo en la propia carpeta de instalación de BES. Como veréis es un fichero comprimido y en cada carpeta hay una tool diferente. También hay que tener claro donde se están almacenando los Logs del BES. Para este post supondremos que están guardados en "c:\bes\logs\20100801" y que estoy utilizando un BES 4 para Lotus Domino.

+ Controlar el estado de activación de un smartphone: Lo que más hago con el BES es dar de alta smartphones. Para ello lo mando por mensajero y es el propio usuario que la activa. Para controlar el proceso de activación tenemos la utilidad eastatus. Para controlar el estado de activación del usuario "Alejandro Moreno" haremos lo siguiente:

> EASTatus -l "C:\bes\logs\20100801" -p D -u "Alejandro Moreno/It/miempresa"
Como resultado obtendremos un fichero de texto .csv con el siguiente contenido:
Server,User,Step,Step Info,Time
CN=midomino/O=miempresa,"Alejandro Moreno /It/miempresa",Step01,AGENT- Enterprise Activation message has been picked up by the BlackBerry Enterprise Server,22:24:12
CN=midomino/O=miempresa,"Alejandro Moreno /It/miempresa",Step02,AGENT- Encryption Key is being generated,22:24:12
CN=midomino/O=miempresa,"Alejandro Moreno /It/miempresa",Step03,AGENT- Sending Service Book request to the Policy Server,22:24:14
CN=midomino/O=miempresa,"Alejandro Moreno /It/miempresa",Step04,POLICY- Policy Server sent the IT Policy to the BlackBerry device,22:24:16
CN=midomino/O=miempresa,"Alejandro Moreno /It/miempresa",Step05,POLICY- IT Policy was successfully delivered to the BlackBerry device,22:24:28
CN=midomino/O=miempresa,"Alejandro Moreno /It/miempresa",Step06,POLICY- Policy Server sent the Service Books to the BlackBerry device,22:24:28
CN=midomino/O=miempresa,"Alejandro Moreno /It/miempresa",Step08,AGENT- The BlackBerry device should be active and able to send and receive messages,22:24:30
CN=midomino/O=miempresa,"Alejandro Moreno /It/miempresa",Step08,AGENT- The BlackBerry device should be active and able to send and receive messages,22:24:30
CN=midomino/O=miempresa,"Alejandro Moreno /It/miempresa",Step10,SYNC- The Slow-Sync Process has been initiated by the BlackBerry device,22:25:00
CN=midomino/O=miempresa,"Alejandro Moreno /It/miempresa",Step11,SYNC- The Slow-Sync Process has completed and the enterprise activation should be complete,22:35:38
+ Ver los mensajes que han pasado por el BES: esta tools es útil si detectamos que el BES parece que no está enviado o recibiendo mensajes.
> messageflow -l "C:\bes\logs\20100801" -p D -u all
Observar las columnas "Posted" que indica la fecha en que el mensaje fue depositado en el buzón del usuario y la "Satus time" que indica la fecha en la que ese mensaje se fue mandado al smartphone del usuario.

+ Ver los mensajes pendientes de enviar: esta es otra manera de ver que algo no está funcionando bien. Si tenemos muchos mensajes en la cola de pendientes de enviar es o porque nos hemos quedado sin conectividad con los servidores de RIM o porque tenemos muchos usuarios que no tienen cobertura en sus smartphones (o las tienen apagadas).
> pending -l "C:\bes\logs\20100801" -p D -u all

certificados caducados en openvpn

27 de junio de 2010

Cuando tienes más de 100 usuarios que pueden entrar por VPN a tú empresa es difícil controlar cuando les caducan sus certificados. El siguiente script muestra todos los certificados que caducan este año. Ahora ya puedes decidir si quieres renovarle o no el certificado al usuario.

#/bin/bash

list=`ls /etc/openvpn/keys/*.crt`
actual=`date '+%Y'`

list () {
   for i in $list ; do
      fecha=`cat $i | grep After`
      fecha="${fecha/Not After :/}"
      fecha="${fecha/GMT/}"
      if [ "$1" != full ]; then
        if [ "$fecha" != "${fecha/$actual/}" ]; then
            echo $i : $fecha
         fi
      else
         echo $i : $fecha
      fi
   done

}

ayuda () {
   echo "listcert v0.1b, por amperis"
   echo
   echo "Uso: listcert [opcion]"
   echo
   echo "-f, --full    Lista la fecha de todos los certificados"
   echo "-e, --expire  Lista los certificados que caducan este año"
   echo "--help        Muestra esta misma ayuda"
   echo
}

case $1 in
   -f | --full)
      list full
      ;;

   -e | --expire)
      list expire
      ;;
   *)
      ayuda
      ;;
esac

Ahora puede programar un cron para que te envie un report cada mes:
root@vpn:~# crontab -l
@monthly /etc/openvpn/keys/listcerts.sh -e | mail -s "Usuarios VPN que caducan proximamente" sysadmin@miempresa.com


test de velocidad entre dos puntos de red (for linux)

25 de junio de 2010

Hace ya un tiempo escribí como calcular la velocidad de red entre dos puntos con una aplicación para Windows. Ahora le toca el turno al mismo concepto, pero con una aplicación para Linux. Esta aplicación es: el neterf.

Funciona exactamente igual que el anterior. Tenemos arrancado esta tool en modo server desde el punto A y desde otro punto B lo lanzamos como cliente.

Veamos como lo lanzamos en modo servidor desde A:

[root@A]# apt-get install iperf
...
[root@A]# iperf -s -f K
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.26.2 port 5001 connected with 192.168.1.191 port 60697
[  4]  0.0-180.4 sec  35400 KBytes    196 KBytes/sec

Observar que quiero el formado de salida en KBytes/sec.

Ahora lanzamos el cliente desde un punto B remoto:
[root@B]# apt-get install iperf
...
[root@B]# iperf -c 192.168.26.2 -f K -t 180
------------------------------------------------------------
Client connecting to 192.168.26.2, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.191 port 60697 connected with 192.168.26.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-180.4 sec  35400 KBytes    196 KBytes/sec

Ver como le indicamos la dirección IP donde se encuentra nuestro servidor, el formato del resultado en KBytes/sec y por ultimo queremos una prueba que dure 180 segundos. Es importante controlar correctamente el tiempo de la prueba, ya que una prueba más larga obtendrá un valor más real.

Este comando lo estoy utilizando para realizar un cambio de operador. Tomo las medidas con el operador antiguo y luego con el nuevo operador. Una vez migrado al nuevo operador veremos cuanto hemos mejorado en las comunicaciones.

Más información:
+ Welcome to the Neterf homepage

tomando temperatura al cpd

23 de junio de 2010

IPMI (Intelligent Platform Management Interface) es una especificación de Intel para el monitoreo a nivel físico de un hardware. Fue impulsado por Dell, HP, Intel y NEC. Sus especificaciones y funcionamiento son independientes del sistema operativo y hardware de la maquina. Nos permite controlar valores como la temperatura de diferentes componentes del servidor, velocidad de los ventiladores, apertura del chasis, voltajes, etc.

El firmware del IPMI se encuentra en la propia placa madre y es totalmente independiente del SO, por tanto es posible monitorizar la maquina aún cuando su sistema operativo está colgado. Dado que se trata de una interfaz para monitorizar podemos utilizar herramientas como clientes SNMP, Nagios o OpenView.

Vamos a describir cómo utilizar un servidor DELL para controlar la temperatura del CPD y enviar un mail en caso de que la temperatura salga de lo habitual.

Primero de todo instalaremos las tools de IPMI. En mi servidor con RedHat es el paquete:

# rpm -q -a | grep IPMI
OpenIPMI-tools-1.4.14-1.4E.13

Una vez rebotado el sistema deberíamos tener arrancados los siguientes módulos en el Kernel. Si no los tenemos arrancados no podremos acceder a la interfaz de IPMI.
# lsmod | grep ipmi
ipmi_devintf           13064  2 
ipmi_si                36648  1 
ipmi_msghandler        31720  2 ipmi_devintf,ipmi_si

También deberíamos tener un dispositivo llamado ipmidev:
# cat /proc/devices | grep ipmi  
252 ipmidev

Consultemos ahora todos los valores que podemos leer con IPDMI:
# ipmitool -I open sensor list
Temp             | 31.000     | degrees C  | ok    | na        | na        | na        | 85.000    | 90.000    | na        
Temp             | 50.000     | degrees C  | ok    | na        | na        | na        | 85.000    | 90.000    | na        
Temp             | 40.000     | degrees C  | ok    | 64.000    | na        | -128.000  | -128.000  | na        | na        
Temp             | 40.000     | degrees C  | ok    | 64.000    | na        | -128.000  | -128.000  | na        | na        
Ambient Temp     | 20.000     | degrees C  | nc    | na        | 3.000     | 8.000     | 20.000    | 47.000    | na        
CMOS Battery     | 0x0        | discrete   | 0x0080| na        | na        | na        | na        | na        | na        
ROMB Battery     | 0x0        | discrete   | 0x0080| na        | na        | na        | na        | na        | na        
VCORE            | 0x0        | discrete   | 0x0180| na        | na        | na        | na        | na        | na        
VCORE            | 0x0        | discrete   | 0x0180| na        | na        | na        | na        | na        | na        
CPU VTT          | 0x0        | discrete   | 0x0180| na        | na        | na        | na        | na        | na        
1.5V PG          | 0x0        | discrete   | 0x0180| na        | na        | na        | na        | na        | na        
1.8V PG          | 0x0        | discrete   | 0x0180| na        | na        | na        | na        | na        | na        
3.3V PG          | 0x0        | discrete   | 0x0180| na        | na        | na        | na        | na        | na        
5V PG            | 0x0        | discrete   | 0x0180| na        | na        | na        | na        | na        | na        
Backplane PG     | 0x0        | discrete   | 0x0180| na        | na        | na        | na        | na        | na        
Flexbay PG       | 0x0        | discrete   | 0x0180| na        | na        | na        | na        | na        | na        
Linear PG        | 0x0        | discrete   | 0x0180| na        | na        | na        | na        | na        | na        
0.9V PG          | 0x0        | discrete   | 0x0180| na        | na        | na        | na        | na        | na        
1.5V ESB2 PG     | 0x0        | discrete   | 0x0180| na        | na        | na        | na        | na        | na        
0.9V Over Volt   | 0x0        | discrete   | 0x0180| na        | na        | na        | na        | na        | na        
CPU Power Fault  | 0x0        | discrete   | 0x0180| na        | na        | na        | na        | na        | na        
FAN 1 RPM        | 2475.000   | RPM        | ok    | na        | 1275.000  | na        | na        | na        | na        
FAN 2 RPM        | 2550.000   | RPM        | ok    | na        | 1275.000  | na        | na        | na        | na        
FAN 3 RPM        | 2550.000   | RPM        | ok    | na        | 1275.000  | na        | na        | na        | na        
FAN 4 RPM        | 2550.000   | RPM        | ok    | na        | 1275.000  | na        | na        | na        | na        
FAN 5 RPM        | 2550.000   | RPM        | ok    | na        | 1275.000  | na        | na        | na        | na        
FAN 6 RPM        | 2550.000   | RPM        | ok    | na        | 1275.000  | na        | na        | na        | na        
FAN 7 RPM        | 4500.000   | RPM        | ok    | 14400.000 | na        | 0.000     | 0.000     | na        | na        
FAN 8 RPM        | 4500.000   | RPM        | ok    | 14400.000 | na        | 0.000     | 0.000     | na        | na        
Presence         | 0x0        | discrete   | 0x0180| na        | na        | na        | na        | na        | na        
...      
Memory Mirrored  | na         | discrete   | na    | na        | na        | na        | na        | na        | na        
Memory RAID      | na         | discrete   | na    | na        | na        | na        | na        | na        | na        
Memory Added     | na         | discrete   | na    | na        | na        | na        | na        | na        | na        
Memory Removed   | na         | discrete   | na    | na        | na        | na        | na        | na        | na        
Memory Cfg Err   | na         | discrete   | na    | na        | na        | na        | na        | na        | na        
Mem Redun Gain   | na         | discrete   | na    | na        | na        | na        | na        | na        | na        
PCIE Fatal Err   | na         | discrete   | na    | na        | na        | na        | na        | na        | na        
Chipset Err      | na         | discrete   | na    | na        | na        | na        | na        | na        | na        
Err Reg Pointer  | na         | discrete   | na    | na        | na        | na        | na        | na        | na        
Mem ECC Warning  | na         | discrete   | na    | na        | na        | na        | na        | na        | na        
Mem CRC Err      | na         | discrete   | na    | na        | na        | na        | na        | na        | na        
USB Over-current | na         | discrete   | na    | na        | na        | na        | na        | na        | na        
POST Err         | na         | discrete   | na    | na        | na        | na        | na        | na        | na        
Hdwr version err | na         | discrete   | na    | na        | na        | na        | na        | na        | na        
Mem Overtemp     | na         | discrete   | na    | na        | na        | na        | na        | na        | na        
Mem Fatal SB CRC | na         | discrete   | na    | na        | na        | na        | na        | na        | na        
Mem Fatal NB CRC | na         | discrete   | na    | na        | na        | na        | na        | na        | na        
CPU Temp Interf  | na         | discrete   | na    | na        | na        | na        | na        | na        | na  

Miremos ahora el log de problemas:
# ipmitool -I open sel list      
   1 | 10/16/2006 | 21:02:21 | Event Logging Disabled #0x72 | Log area reset/cleared | Asserted
   2 | Pre-Init Time-stamp   | Power Supply #0x74 | Redundancy Lost
   3 | Pre-Init Time-stamp   | Power Supply #0x64 | Failure detected | Asserted
   4 | Pre-Init Time-stamp   | Power Supply #0x64 | Power Supply AC lost | Asserted
   5 | 06/09/2009 | 17:35:09 | Drive Slot #0x81 | Drive Present | Deasserted
   6 | 06/09/2009 | 17:37:54 | Drive Slot #0x81 | Drive Present | Asserted
   7 | 06/21/2010 | 15:16:47 | Temperature #0x08 | Upper Non-critical going high

Miremos ahora las alarmas:
# ipmitool -I open sdr list
Temp             | 32 degrees C      | ok
Temp             | 50 degrees C      | ok
Temp             | 40 degrees C      | ok
Temp             | 40 degrees C      | ok
Ambient Temp     | 20 degrees C      | nc
CMOS Battery     | 0x00              | ok
ROMB Battery     | 0x00              | ok
VCORE            | 0x01              | ok
VCORE            | Not Readable      | ns
CPU VTT          | 0x01              | ok
1.5V PG          | 0x01              | ok
1.8V PG          | 0x01              | ok
3.3V PG          | 0x01              | ok
5V PG            | 0x01              | ok
Backplane PG     | 0x01              | ok
Flexbay PG       | 0x01              | ok
Linear PG        | 0x01              | ok
0.9V PG          | 0x01              | ok
1.5V ESB2 PG     | 0x01              | ok
0.9V Over Volt   | 0x01              | ok
CPU Power Fault  | 0x01              | ok
FAN 1 RPM        | 2475 RPM          | ok
FAN 2 RPM        | 2475 RPM          | ok
FAN 3 RPM        | 2550 RPM          | ok
FAN 4 RPM        | 2550 RPM          | ok
FAN 5 RPM        | 2550 RPM          | ok
FAN 6 RPM        | 2550 RPM          | ok
FAN 7 RPM        | 4500 RPM          | ok
FAN 8 RPM        | 4500 RPM          | ok
Presence         | 0x01              | ok
Presence         | 0x02              | ok
Presence         | 0x01              | ok
Presence         | 0x01              | ok
Presence         | 0x01              | ok
PFault Fail Safe | Not Readable      | ns
Status           | 0x80              | ok
Status           | 0x00              | ok
Status           | 0x01              | ok
Status           | 0x01              | ok
RAC Status       | 0x00              | ok
OS Watchdog      | 0x00              | ok
SEL              | Not Readable      | ns
Intrusion        | 0x00              | ok
PS Redundancy    | 0x01              | ok
Fan Redundancy   | 0x01              | ok
Drive            | 0x01              | ok
Cable SAS A      | 0x01              | ok
Cable SAS B      | 0x01              | ok
Cable SAS FB     | Not Readable      | ns
Cable Power FB   | Not Readable      | ns
...
Mem ECC Warning  | Not Readable      | ns
Mem CRC Err      | Not Readable      | ns
USB Over-current | 0x01              | ok
POST Err         | Not Readable      | ns
Hdwr version err | 0x01              | ok
Mem Overtemp     | 0x01              | ok
Mem Fatal SB CRC | 0x01              | ok
Mem Fatal NB CRC | 0x01              | ok
CPU Temp Interf  | Not Readable      | ns

Una vez que sabemos de que van estos comandos podemos ver que el valor que nos interesa es el marcado por el sensor de temperatura llamado “Ambient Temp”. Este valor marca el valor de la temperatura fuera del servidor con un error de +-2Cº.

Si lanzamos el siguiente comando de shell obtendremos la temperatura ambiente:
# ipmitool sdr type Temperature | grep "Ambient Temp" |awk '{ print $10 }' | grep -v  "na" | sed 's/\..*//g' | head -n1

Ahora nos hacemos un script que lea la temperatura y la compare con un máximo. Si se supera ese máximo enviará un mail:
# cat /usr/share/ipmitool/control_temp.sh
#!/bin/bash

TEMPWARNING="31"
TEMPCRITICAL="35"
MAIL="sysadmin@miempresa.com"
LOG=/var/log/control_temp.log

TEMPERATURA=$(/usr/bin/ipmitool sdr type Temperature | grep "Ambient Temp" |awk '{ print $10 }' | grep -v  "na" | sed 's/\..*//g' | head -n1)

if [ -z "$TEMPERATURA"  ];
then
        echo UNKNOWN
        exit 3
fi

if   [ $TEMPERATURA -ge $TEMPCRITICAL ];
then
        echo `date` CRITICAL temperatura ${TEMPERATURA}C >> $LOG
        echo "CRITICAL temperatura ${TEMPERATURA}C" | mail -s "Temperatura CPD CRIT" ${MAIL}
        exit 2
elif [ $TEMPERATURA -ge $TEMPWARNING  ];
then
        echo `date` WARNING temperatura ${TEMPERATURA}C >> $LOG
        echo "WARNING temperatura ${TEMPERATURA}C" | mail -s "Temperatura CPD WARN" ${MAIL}
        exit 1
fi

echo `date` OK temperatura ${TEMPERATURA}C >> $LOG
exit 0

Finalmente programamos este script para que se ejecute cada 15 minutos y compruebe la temperatura:
# crontab -l
0,15,30,45 * * * * /usr/share/ipmitool/control_temp.sh > /dev/null 2>&1

Más información:
+ http://www.intel.com/design/servers/ipmi/
+ http://en.wikipedia.org/wiki/Power_usage_effectiveness