# rm-rf.es | Administración de sistemas

Blog de un SysAdmin Unix, Gnu/Linux, Windows y lo que haga falta.

cvs commit: Up-to-date check failed for… (rancid)

Si usáis Rancid para tener un control de versiones de las configuraciones de vuestros dispositivos de red, puede llegar un momento en el que por X motivo se genere un problema en el repositorio y recibáis este error en los logs, que además provoca que no se actualice ningún fichero de configuración:

cvs diff: Diffing .
cvs diff: Diffing configs
cvs commit: Examining .
cvs commit: Examining configs
cvs commit: Up-to-date check failed for [...]
cvs commit: Up-to-date check failed for [...]
cvs commit: Up-to-date check failed for [...]
cvs [commit aborted]: correct above errors first!

Para solucionarlo, debemos hacer un update del repositorio con CVS (Concurrent Versions System) para resincronizarlo y que Rancid pueda volver a utilizarlo. Nos tenemos que colocar en la ruta en la que se encuentran los ficheros de configuración de los dispositivos que están dando el problema y ejecutar el update:

rancid@server:~$ cd /var/rancid/.../configs/
rancid@server:~$ cvs update

Si recibís un error de comando no encontrado verificar que el binario cvs se encuentra en el PATH, en caso contrario ejecutadlo con la ruta completa, por ejemplo:

rancid@server:~$ /usr/local/bin/cvs update

Y probamos a ejecutar rancid y verificar que se actualizan las configuraciones:

rancid@server:~$ /usr/local/rancid/bin/rancid-run

Monitorizar Oracle iPlanet Web Server con get-perfdump

Oracle SolarisLa utilidad de monitorización en servidores Web de Sun/Oracle ha mejorado mucho a partir de la versión 7.0. Si bien antes únicamente podíamos acceder a estos datos vía web, ahora podemos hacerlo a través de la shell/CLI wadm, permitiendo acceder a estadísticas a tiempo real de monitorización sin necesidad de hacerlo vía HTTP, con los problemas que conllevaba con el sistema cargado.

La nueva versión, disponible en Sun Java System Web Server, Oracle iPlanet Web Server 7.0 o como lo queráis llamar, añade la posibilidad de ver las Ips y peticiones que se están haciendo a cada instancia y así poder detectar con mayor facilidad el origen de un cuello de botella o sobrecarga del sistema.

Para acceder a wadm nos situamos en la ruta base del servidor web y ejecutamos el siguiente comando indicando usuario y clave de administración:

root@solaris:/opt/oracle/webserver7# ./bin/wadm --user=admin
Indique admin-user-password>
Conexión a localhost:8989
Oracle iPlanet Web Server 7.0.12 B07/01/2011 03:56
wadm>

Una vez dentro, elegimos la instancia y nodo del que queremos ver las estadísticas y tendremos el volcado de información:

wadm> get-perfdump --config solaris --node localhost

La información que recibimos es la siguiente. Tened en cuenta que es un webserver de prueba por lo que no hay apenas información:

wadm> get-perfdump --config solaris --node localhost

Oracle iPlanet Web Server 7.0.12 B07/01/2011 03:56 (SunOS DOMESTIC)

Server started Sat Feb 11 15:24:28 2012
Process 1133 started Sat Feb 11 15:24:29 2012

ConnectionQueue:
-----------------------------------------
Current/Peak/Limit Queue Length            0/4/16384
Total Connections Queued                   20
Average Queue Length (1, 5, 15 minutes)    0,00, 0,00, 0,00
Average Queueing Delay                     10,88 milliseconds

ListenSocket http-listener-1:
------------------------
Address                   https://0.0.0.0:443
Acceptor Threads          1
Default Virtual Server    solaris

ListenSocket http-listener-2:
------------------------
Address                   http://0.0.0.0:80
Acceptor Threads          1
Default Virtual Server    solaris

KeepAliveInfo:
--------------------
KeepAliveCount        6/32768
KeepAliveHits         8
KeepAliveFlushes      0
KeepAliveRefusals     0
KeepAliveTimeouts     6
KeepAliveTimeout      30 seconds

SessionCreationInfo:
------------------------
Active Sessions           0
Keep-Alive Sessions       6
Total Sessions Created    8/129

CacheInfo:
-----------------------
File Cache Enabled       yes
File Cache Entries       14/1024
File Cache Hit Ratio     76/108 ( 70,37%)
Maximum Age              30
Accelerator Entries      0/1024
Acceleratable Requests   18/45 ( 40,00%)
Acceleratable Responses  0/18 (  0,00%)
Accelerator Hit Ratio    0/0 (  0,00%)

Native pools:
----------------------------
NativePool:
Idle/Peak/Limit               1/1/128
Work Queue Length/Peak/Limit  0/0/0

DNSCacheInfo:
------------------
enabled             yes
CacheEntries        0/1024
HitRatio            0/0 (  0,00%)

Async DNS disabled

Performance Counters:
------------------------------------------------
                           Average         Total      Percent

Total number of requests:                     20
Request processing time:    0,0395        0,7899

default-bucket (Default bucket)
Number of Requests:                           20    (100,00%)
Number of Invocations:                       289    (100,00%)
Latency:                    0,0050        0,0999    ( 12,65%)
Function Processing Time:   0,0345        0,6899    ( 87,35%)
Total Response Time:        0,0395        0,7899    (100,00%)

Sessions:
-------------------------------------------------------
Process  Status  Client  Age  VS  Method  URI  Function

Resultan muy interesantes para detectar problemas y optimizar el rendimiento la sección “ConnectionQueue:” y “Sessions:“, en esta última es donde veremos las Ips de acceso, peticiones, URI, etc. Toda la información es bastante descriptiva y comprensible a primera vista. A partir de esta información se pueden generar scripts de recolección de datos, añadir a monitorización tipo Nagios o BigBrother, etc. Los que utilicéis servidores anteriores a la versión 7.0 habréis detectado un gran cambio de la cantidad de información del antiguo perfdump al nuevo.

Configurar un syslog remoto para centralizar logs

Syslogd permite ser configurado para escuchar y aceptar conexiones remotas, lo que implica poder recibir datos y almacenarlos de clientes externos (syslog de otros servidores). Esto es perfecto para crear un servidor syslog central y enviarle todos los logs de otros servidores, con la finalidad de tenerlos y gestionarlos todos en el mismo sitio.

La configuración es bastante sencilla. Vamos a ver los pasos a realizar en el servidor central syslogd y en los clientes.

Syslogd central

En el servidor syslogd que va a recibir todos los logs hay que revisar dos cosas. La primera que esté configurado para aceptar conexiones remotas. Para ello hay que añadir el parámetro “-r” a la línea de arranque. Ya sea en el script de /etc/init.d/syslog o si lo arrancamos a mano. En el script de init.d suele ser en la variable donde se especifican los parámetros:

SYSLOGD_OPTIONS="-r -m 0"

Y si lo arrancaramos a mano:

# syslogd -r -m 0

Una vez arrancado, debería estar escuchando en el puerto UDP 514. Aseguraos que está abierto en el firewall:

syslogd   13819      root    7u     IPv4  660344590      UDP *:syslog

Clientes syslogd

A la hora de configurar los clientes que van a enviar los logs al servidor central, únicamente tenemos que especificar qué logs van a ir al servidor central, lo haremos en el fichero de configuración /etc/syslog.conf.

Una línea estandar es esta por ejemplo, en la que mandamos a /var/log/messages los logs de cron, info, mail, etc:

*.info;mail.none;authpriv.none;cron.none		/var/log/messages

Para que estos logs se dejen de almacenar en el log local y pasen al remoto, únicamente indicamos con @servidor_syslogd el hostname/ip del servidor syslogd. Si por ejemplo el servidor syslogd tiene el hostname syslogd01:

*.info;mail.none;authpriv.none;cron.none	     @syslogd01

Reiniciamos syslogd y comenzaríamos a enviar los logs al servidor central:

# /etc/init.d/syslogd restart

Un ejemplo de como veríamos el log central con varias entradas de distintos servidores (servidor01, servidor02,…):

Aug 12 18:15:58 servidor01 snmpd[27557]: Connection from UDP: [xx.xx.xx.xx]:39892 
Aug 12 18:15:58 servidor01 snmpd[27557]: Received SNMP packet(s) from UDP: [xx.xx.xx.xx]:39892 
Aug 12 18:15:58 servidor02 snmpd[27557]: Connection from UDP: [xx.xx.xx.xx]:56751 
Aug 12 18:15:58 servidor02 snmpd[27557]: Received SNMP packet(s) from UDP: [xx.xx.xx.xx]:56751 
...
...

Comprobar el estado de los mirror de CentOS por país

Normalmente todos tenemos una lista de mirrors de CentOS preferida, ya sea por cercanía geográfica o por su velocidad. Si bien es fácil comprobar de forma manual si un mirror está online u offline, no deja de ser útil esta web en la que podemos ver el estado a tiempo real de los mirror de CentOS separados por países, con gráficas, histórico, reportes, etc.

La aplicación está hecha con el software mirmon. Pinchad en la imagen para acceder  al sitio web:

CentOS mirror status

Exim: monitorizar la cola de correo en Big Brother

Hoy vamos a ver la forma de integrar en el sistema de monitorización Big Brother la supervisión del estado de la cola de correos de exim. Todo ello gracias al script bb-exim.sh creado por Carl C. Inglis.

Es un script fácil de entender, modificar y personalizar a nuestros requerimientos. Lo más básico a conocer es que podemos realizar y monitorizar lo siguiente:

# Tests are:
#               RUN - Test if the daemon is running
#               QUEUE - Check the size of the queue (see below)
#               REJECT - Check to see if the reject log is > 0 bytes long
#               PANIC - Check to see if the panic log is > 0 bytes long
#               FROZEN - Check to see if there are any frozen messages
#                 IGNOREFROZENERRS - Ignore frozen messages with a sender
#                                    of "<>".  (i.e., error responses.)
TESTRUN="y"
TESTQUEUE="y"
TESTREJECT="n"
TESTPANIC="y"
TESTFROZEN="y"
IGNOREFROZENERRS="y"

Como veis, por defecto revisa que el demonio de exim está corriendo, así como el tamaño de la cola de correo, el tamaño de los logs panic y reject (no por defecto para el reject)así como el número de correo en estado frozen o sin destinatario válido. Después, hay dos variables para seleccionar el umbral de aviso para warning y panic con el número de correos en cola:

TESTQUEUEALERT="50"
TESTQUEUEPANIC="100"

Revisad también que la ruta al binario de exim es la correcta, a los logs, etc:

EXIMBINARY="/usr/sbin/exim"
EXIMREJECT="/var/log/exim/rejectlog"
EXIMPANIC="/var/log/exim/paniclog"

La instalación es igual que cualquier extensión de Big Brother, ubicáis el script en la carpeta ext/, le asignais permisos de ejecución para el usuario y después lo añadís en el fichero bb-bbext y reiniciamos Big Brother:

# vim /ruta_a_big_brother/ext/bb-exim.sh
# chmod 0750 /ruta_a_big_brother/ext/bb-exim.sh
# chown usuariobb. /ruta_a_big_brother/ext/bb-exim.sh
# vim /ruta_a_big_brother/etc/bb-bbexttab
localhost :  : bb-exim.sh

Personalmente he realizado unas cuantas modificaciones para adecuarlo a mis necesidades. Entre ellas la necesidad de usar sudo ya que el usuario Big Brother no tiene privilegios, otra de ellas la visualización de la cola de correo. En lugar de mostrar la lista de mensajes como se vería con un exim -bp, la parseo mediante exiqsumm -c para que sea agradable a la vista y más rápido de visualizar y claro:

# exim -bp
 2h  5.9K xx-0000ko-HA 
          xxx_70@xxx.com

 2h  6.0K xx-0000kt-OZ 
          xxx_70@xxx.com

76m  9.3K xx-0003Ee-OO 
          xxx@xxx.org

51m  7.8K xx-0005cQ-Te 
          xxx.xxx@xxx.org
# exim -bp | exiqsumm -c

Count Volume Oldest Newest Domain
----- ------ ------ ------ ------

279 23MB 63h 30m xxx.org
2 12KB 2h 2h xxx.com
2 272KB 14h 12h xxx.com

---------------------------------------------------------------
289 28MB 63h 20m TOTAL

El resultado final, podría ser algo así:

Exim Big Brother

Podéis descargar el script original aquí.

Cacti: arreglar gráficos con cortes intermitentes

Es posible que cuando en Cacti comencéis a tener una cantidad considerable de hosts monitorizandose de repente algunos de los gráficos no se generen de forma correcta y aparezcan cortes intermitentes en los que los datos a monitorizar no se han podido recolectar, ejemplo:

Cacti gráficos con cortes intermitentes

Probablemente el problema radique en que el “Poller” no tiene tiempo suficiente para recolectar los datos de todos los hosts, sobre todo si configuráis el cron cada poco tiempo. En mi caso, con un número considerable de hosts y cada 5 minutos no había manera. Usando el Poller en PHP (cmd.php), no Spine, simplemente aumentando el número de procesos concurrentes de 1 a 5 el problema ha quedado solucionado. En el caso de que uséis Spine simplemente se trata de tunear los parámetros correspondientes.

Para cmd.php, accedéis a Console > Settings > Poller y es la opción:

Maximum Concurrent Poller Processes
The number of concurrent processes to execute. Using a higher number when using cmd.php will improve performance. Performance improvements in spine are best resolved with the threads parameter

 

Gestión y monitorización de servicios con Monit

Creo que todos los administradores de sistemas coincidimos en que un buen sysadmin es aquel que es capaz de conseguir que los sistemas se autogestionen en la mayor parte de lo posible. Esto implica, además de disponer de un buen sistema de monitorización tipo Big Brother, Nagios o Cacti, disponer de herramientas para que cuando un servicio o aplicación falle y se pare, automáticamente intenten reiniciarla sin necesidad del administrador.

Monit es una herramienta muy sencilla de instalar y configurar que se encargará de hacer esta tarea por nosotros. Monit permite monitorizar y gestionar procesos, ficheros, directorios y sistemas de ficheros.

Su instalación es realmente sencilla, podéis utilizar gestores de descargas como YUM o APT o compilarlo desde el código fuente (no tiene ningún misterio). Descarga aquí.

En CentOS o RHEL por ejemplo:

# yum install monit

Una vez instalado, simplemente tenéis que personalizar la configuración, encontraréis el fichero en la ruta /etc/monit.conf. Cada sección o directiva está perfectamente explicada, no obstante las más importantes:

set daemon  60             # check services at 2-minute intervals
     with start delay 240  # optional: delay the first check by 4-minutes (by
#                          # default Monit check immediately after Monit start)

set daemon indica que levantemos monit como demonio, a continuación le especificamos el intervalo de tiempo para el chequeo de servicios, también indicamos un retardo de 4 minutos para que no los chequee nada más arrancar.

 set mailserver localhost               # primary mailserver
set alert xxx@xxx.com/pre>

Con set mailserver indicaremos el servidor de correo a utilizar para el envío de alertas. Set alert especificará la cuenta de correo a la que enviar los avisos.

Ya pasamos a la configuración de servicios y lo que vamos a monitorizar. En primera instancia podemos indicar que nos envíe correos cuando el sistema alcance una determinada carga o uso de CPU, memoria, etc. Descomentar y personalizar según requerimientos:

#  check system myhost.mydomain.tld
#    if loadavg (1min) > 4 then alert
#    if loadavg (5min) > 2 then alert
#    if memory usage > 75% then alert
#    if swap usage > 25% then alert
#    if cpu usage (user) > 70% then alert
#    if cpu usage (system) > 30% then alert
#    if cpu usage (wait) > 20% then alert

También podemos monitorizar cambios en ficheros, permisos, checksum, usuarios y grupos, etc

## Check if a file exists, checksum, permissions, uid and gid. In addition
## to alert recipients in the global section, customized alert can be sent to
## additional recipients by specifying a local alert handler. The service may
## be grouped using the GROUP option. More than one group can be specified by
## repeating the 'group name' statement.
#
#  check file apache_bin with path /usr/local/apache/bin/httpd
#    if failed checksum and
#       expect the sum 8f7f419955cefa0b33a2ba316cba3659 then unmonitor
#    if failed permission 755 then unmonitor
#    if failed uid root then unmonitor
#    if failed gid root then unmonitor
#    alert security@foo.bar on {
#           checksum, permission, uid, gid, unmonitor
#        } with the mail-format { subject: Alarm! }
#    group server

En la parte de servicios podemos configurar servicios como Apache, Exim, FTP, MySQL, etc para que cuando haya un problema y se paren Monit los levante automáticamente, a continuación os dejo el ejemplo para Apache (rutas y demás pueden diferir según la instalación):

  check process apache with pidfile /usr/local/apache/logs/httpd.pid
    start program = "/etc/init.d/httpd start" with timeout 60 seconds
    stop program  = "/etc/init.d/httpd stop"
    if cpu > 60% for 2 cycles then alert
    if cpu > 80% for 5 cycles then restart
    if totalmem > 200.0 MB for 5 cycles then restart
    if children > 250 then restart
    if loadavg(5min) greater than 10 for 8 cycles then stop
    if failed host rm-rf.es port 80 protocol http
       and request "/index.phpsy"
       then restart
    if failed port 443 type tcpssl protocol http
       with timeout 15 seconds
       then restart
    if 3 restarts within 5 cycles then timeout
    #depends on apachectl
    group server

Como véis monitoriza el PID de apache y si no lo encuentra lo reinicia. También monitoriza el uso de CPU y memoria y si es muy elevado en X ciclos de comprobación lo reinicia o avisa al administrador, lo mismo para el SSL, etc.

En la ayuda de Monit encontraréis información sobre como añadir más servicios, aunque simplemente es coger el de apache como base y modificar parámetros. Otro ejemplo para MySQL:

check process mysql with pidfile /var/lib/mysql/mysql.pid
   group database
   start program = "/etc/init.d/mysql start"
   stop program = "/etc/init.d/mysql stop"
   if failed host 127.0.0.1 port 3306 then restart
   if 5 restarts within 5 cycles then timeout

Una vez que tengamos todo configurado, solo queda iniciar el servicio y comprobar su funcionamiento, por ejemplo tirando uno de los servicios monitorizados.

# /etc/init.d/monit start
Starting monit: Starting monit daemon
Monit start delay set -- pause for 240s
                                                           [  OK  ]

Tener Monit instalado es un buen ejemplo de monitorización proactiva en vuestros servidores. Os sirva para evitar tener que levantaros alguna que otra madrugada a levantar un servicio.

Estadísticas de correo, spam y virus con Mailgraph

Mailgraph es un sistema de estadísticas que utiliza como frontend RRDtool y permite recolectar de forma gráfica el número de correos enviados y recibidos en gráficos diarios, semanales, mensuales y anuales. Básicamente tenemos un script en perl corriendo en el servidor, es el encargado de recolectar los datos (rrd), y por otra parte un script cgi a través del cual se generan y visualizan los gráficos vía web.

Instalación de Mailgraph

Mailgraph requiere tener instalado RRDtool y el módulo de Perl File::Tail. RRDTool se puede instalar tanto desde el gestor de paquetes como compilandolo a mano. Lo más rápido, desde YUM o APT:

# yum install rrdtool.i386

El módulo de perl lo podemos instalar desde cPan:

cpan> install File::Tail

Descargamos y descomprimimos la última versión desde el sitio web de mailgraph:

# wget http://mailgraph.schweikert.ch/pub/mailgraph-1.14.tar.gz
#  tar -xzvf mailgraph-1.14.tar.gz
# cd mailgraph-1.14

Ahora vamos a modificar el script base que nos ofrecen para el arranque del demonio en perl (mailgraph-init). Básicamente, tenemos que modificar las siguientes variables:

PATH=/bin:/usr/bin
MAILGRAPH_PL=/usr/local/bin/mailgraph.pl # RUTA DONDE VAMOS A COLOCAR EL SCRIPT
MAIL_LOG=/var/log/maillog # RUTA DE NUESTRO LOG DE CORREO
PID_FILE=/var/run/mailgraph.pid
RRD_DIR=/var/lib/mailgraph # RUTA DONDE ALMACENAR LOS RRD

Una vez realizado esto, movemos el script a init.d, le asignamos permisos de ejecución y lo arrancamos:

# cp mailgraph-init /etc/init.d/mailgraph
#chmod 0755 /etc/init.d/mailgraph
# /etc/init.d/mailgraph start

En este momento el demonio debería estar corriendo:

# ps aux | grep mailgraph
root     13023  1.1  0.2  14132  4128 ?        SNs  17:39   0:27 /usr/bin/perl -w /usr/local/bin/mailgraph.pl -l /var/log/maillog -d --daemon-pid=/var/run/mailgraph.pid --daemon-rrd=/var/lib/mailgraph

Ahora solo nos queda ejecutar el cgi para ver los gráficos generados mediante este script. Lo tendréis que ubicar en una ruta en la que podáis ejecutar CGI, debería tener en apache permitido lo siguiente:

<Directory /carpeta/web/script>
Options ExecCGI
</Directory>

Aseguraos también de que mod_perl está instalado para la ejecución del cgi, y que el handler está configurado en apache:

AddHandler cgi-script .cgi

Esto debería ser todo, ejecutamos el cgi desde el navegador y veremos algo tal que así, en este enlace tenéis una demo a tiempo real.

MailGraph
mailgraph

Instalación de plugin Thold para Cacti

Cacti Graph

Vamos a instalar el plugin Thold para el sistema de monitorización Cacti. Este plugin permite configurar alertas estableciendo unos límites para los valores que se muestran en los gráficos. Se pueden establecer alertas para los valores más altos y los más bajos y enviar avisos por correo electrónico.

Algunos ejemplos de uso podrían ser que nos avisara por correo electrónico en el momento que el tráfico de una interfaz de red superara los 50 mbit durante más de 10 minutos, o que nos avisara cuando el uso de CPU de un determinado servidor se mantuviera por encima del 80% durante 5 minutos.

En este caso, vamos a instalar THOLD sobre la versión 0.8.7.g. Antes de hacerlo, hay que tener en cuenta que este plugin tiene dependencias, antes de instalarlo hemos de instalar lo siguiente:

  • Plugin Architecture
  • Settings

Instalación de Plugin Architecture

La instalación de Plugin Architecture es lo que permite poder instalar posteriormente los plugins. Para instalarlo, debemos bajarlo del siguiente enlace:

http://mirror.cactiusers.org/downloads/plugins/cacti-plugin-0.8.7g-PA-v2.8.tar.gz

Básicamente con esto vamos a modificar el núcleo de código de cacti para poder hacer uso posteriormente del resto de plugins. Esta modificación se puede instalar de dos modos distintos, sobreescribiendo los ficheros de cacti por los que descargamos, o aplicando los ficheros de parche (patch). La primera opción sería la que utilizaríamos en Windows y la segunda es óptima para Linux.

Ante cualquier duda, tenéis aquí la documentación sobre la instalación de Plugin Arch:

Una vez instalado Plugin Architecture y activado tal y como dice el manual (Hay que acceder a User Management y activar el Realm Permission para Plugin Management), ya debería aparecer el el menú de la consola de Cacti la opción Plugin Management.

plugin management cacti

Instalación de settings

La instalación de este plugin es realmente sencilla, únicamente hay que descargarlo y mover la carpeta “settings” a la carpeta “plugins” de nuestro Cacti. Para activar este plugin, y que aparezca como “Activo dentro del Plugin Management” probablemente necesitaréis añadir este código al fichero config.php de Cacti:

/* load up old style plugins here */
$plugins = array();
$plugins[] = 'settings';

Una vez realizado esto ya debería aparecer como activo.

Instalación de Thold

Finalmente instalamos Thold descargandolo:

http://cactiusers.org/downloads/thold.tar.gz

Copiamos la carpeta “thold” a la carpeta de plugins e importamos a la base de datos de cacti el contenido del fichero thold.sql.

mysql -u cactiuser -ppassword -D cacti < thold.sql

Ahora, si accedemos a la sección de Plugin Management debería aparecer la opción de “Activar el plugin”, una vez activado aparecerá una nueva pestaña junto con la de “Console” y “Graphs” llamada THOLD, también aparecerán nuevos apartados en el menú izquierdo donde comenzar a configurar las plantillas de threshold, las alertas específicas por dispositivo, etc.

thold

Si a pesar de esto seguís teniendo dudas, acordaos de revisar los ficheros README de cada uno de los plugins y la documentación que comento en la entrada, sino podéis comentar e intentaremos solucionar el problema.

hpasm “sed: can’t read /etc/init.d/ipmi: No such file or directory”

Instalando hoy en unos nuevos equipos hpasm (Hpasmcli: monitorizar el estado de hardware HP Proliant desde linux) me encontré con el siguiente error al arrancar los servicios:

# /etc/init.d/hpasm restart
Shutting down NIC Agents (cmanic): All agents

Shutting down Storage Agents (cmastor): cmaeventd cmaidad cmafcad cmaided cmascsid cmasasd
   Shutting down Storage Event Logger (cmaeventd):         [  OK  ]
   Shutting down IDA agent (cmaidad):                      [  OK  ]
   Shutting down FCA agent (cmafcad):                      [  OK  ]
   Shutting down IDE agent (cmaided):                      [  OK  ]
   Shutting down SCSI agent (cmascsid):                    [  OK  ]
   Shutting down SAS agent (cmasasd):                      [  OK  ]

Shutting down Server Agents (cmasvr): cmastdeqd cmahealthd cmaperfd cpqriisd cmasm2d cmarackd
   Shutting down Standard Equipment agent (cmastdeqd):     [  OK  ]
   Shutting down Health agent (cmahealthd):                [  OK  ]
   Shutting down Performance agent (cmaperfd):             [  OK  ]
   Already stopped cpqriisd.                               [  OK  ]
   Shutting down RIB agent (cmasm2d):                      [  OK  ]
   Shutting down Rack agent (cmarackd):                    [  OK  ]

Shutting down Foundation Agents (cmafdtn): cmathreshd cmahostd cmapeerd
   Shutting down Threshold agent (cmathreshd):             [  OK  ]
   Shutting down Host agent (cmahostd):                    [  OK  ]
   Shutting down SNMP Peer (cmapeerd):                     [  OK  ]

sed: can't read /etc/init.d/ipmi: No such file or directory
   Using standard Linux IPMI device driver and hpasm-lite
   Shutting down Proliant Standard IPMI based System Health Monitor (hpasmlited):
                                                           [  OK  ]
sed: can't read /etc/init.d/ipmi: No such file or directory
   Using standard Linux IPMI device driver and hpasm-lite
   Starting Proliant Standard IPMI based System Health Moni[  OK  ]smlited):
Starting Foundation Agents (cmafdtn): cmathreshd cmahostd cmapeerd
   Starting Threshold agent (cmathreshd):                  [  OK  ]
   Starting Host agent (cmahostd):                         [  OK  ]
   Starting SNMP Peer (cmapeerd):                          [  OK  ]

Starting Server Agents (cmasvr): cmastdeqd cmahealthd cmaperfd cpqriisd cmasm2d cmarackd
   Starting Standard Equipment agent (cmastdeqd):          [  OK  ]
   Starting Health agent (cmahealthd):                     [  OK  ]
   Starting Performance agent (cmaperfd):                  [  OK  ]
   cpqriisd requires hp_ilo.
                                                           [  OK  ]
   Starting RIB agent (cmasm2d):                           [  OK  ]
   cpqriisd requires hp_ilo.
                                                           [  OK  ]
   Starting Rack agent (cmarackd):                         [  OK  ]

Starting Storage Agents (cmastor): cmaeventd cmaidad cmafcad cmaided cmascsid cmasasd
   Starting Storage Event Logger (cmaeventd):              [  OK  ]
   Starting IDA agent (cmaidad):                           [  OK  ]
   Starting FCA agent (cmafcad):                           [  OK  ]
   Starting IDE agent (cmaided):                           [  OK  ]
   Starting SCSI agent (cmascsid):                         [  OK  ]
   Starting SAS agent (cmasasd):                           [  OK  ]

Starting NIC Agents (cmanic): All agents
   Starting NIC Agent Daemon (cmanicd):   Unable to determine if cmanic successfully started

hpasm:  Server Management is enabled

El problema era no tener instalado OpenIPMI, procedemos a instalarlo desde yum (en este caso era una CentOS 64bits) y problema solucionado

# yum install OpenIPMI.x86_64

Ya podemos reiniciar los servicios hpasm y debería desaparecer el error.