Alertas y acciones en tu servidor a través de SMS

Tal y como he prometido sigo en mi empeño de, como mínimo, dos artículos por semana, así que ahí va el segundo de esta 🙂 .

Hoy veremos cómo aprovechar un móvil que ya no utilicemos para recibir alertas y ejecutar acciones remotamente en nuestros servidores.

Monté un sistema de este tipo por primera vez allá por 2002 y desde entonces lo hago siempre que tengo nuevos servidores que manejar, sobre todo en aquellos que hacen de monitor (Cacti y/o Nagios) y backup.

La idea inicial era recibir alertas de problemas en el servidor sin tener que estar delante de la máquina. En aquél momento no había más opciones que el email, pero si no estabas delante de la máquina no recibirías nada. Posteriormente aparecieron las primeras pasarelas SMS por HTTP (con una llamada HTTP y los parámetros adecuados, envías un SMS), pero aún hoy tienen un inconveniente, si tu máquina se queda sin conectividad (problemas de red, router, ataques DOS..) nunca recibirás alertas y nunca te enterarás de que algo ocurre.

Se me ocurrió entonces que podría utilizar un Nokia 3210 que acababa de jubilar ya que además me había comprado el cable para conectarlo al ordenador por el puerto serie, pero me faltaba lo más importante, el software. Me puse a investigar y encontré lo que buscaba, era lógico, no iba a ser yo el primero al que se le ocurriese esa idea 😉 . La solución se llamaba Gnokii, un software que se comenzó a desarrollar ni más ni menos que a finales de 1998. Por lo que me consta, dejó de actualizarse allá por 2003, aunque probablemente siga funcionando perfectamente en la mayoría de casos, sin embargo hace ya tiempo que apareció un fork de Gnokii, Gammu, que es el que utilizo desde hace ya unos años y sobre el que nos centraremos en este artículo. Además he cambiado la forma de conectar el terminal al ordenador, ya no es por el puerto serie sino por bluetooth.

Podríamos dividir el artículo en cuatro pasos:

  1. Conectando el móvil con el servidor.
  2. Enviando mensajes.
  3. Sistema de mensajería avanzado.
  4. Ejecutando acciones.

Conectando el móvil con el servidor

Comenzaremos por configurar el servidor. No voy a explicar detenidamente los pasos puesto que, aunque hoy en día son sencillos, se salen del alcance del artículo. De todos modos configurar el bluetooth hace cuatro o cinco años era bastante más complicado, hoy todas las distribuciones Linux tienen los paquetes preparados.

Lo primero, obviamente, será tener una antena bluetooth en el servidor, con una USB será suficiente y funciona perfectamente, yo lo tengo así desde hace años.

El siguiente paso será instalar los paquetes necesarios para tener conectividad bluetooth, normalmente son dos, bluez-libs y bluez-utils. Si tu sistema operativo es medianamente moderno probablemente los tengas ya instalados, sino estarán en cualquier repositorio.

Como supondremos que estamos trabajando con servidores, lo más probable es que no tengas entorno gráfico, así que lo configuraremos todo a mano. Si tuvieses entorno gráfico hay paquetes gnome para hacer el emparejamiento automáticamente.

En mi Centos5.0 los archivos de configuración se encuentran en /etc/bluetooth, en el tuyo pueden variar. Tendremos que configurar tres archivos:

  • hcid.conf: configura los servicios que ofrecerá la antena bluetooth.
  • pin: pin de la SIM del móvil para no tener que introducirlo manualmente. Tambien puedes configurar la SIM para que no solicite pin.
  • rfcomm.conf: configura los canales de comunicación.

La verdad es que no recuerdo mucho las distintas opciones de hcid.conf, así que me limitare a copiar mi configuración para que tengáis un punto de inicio.

options {
        autoinit yes;
        security user;
        pairing multi;
        passkey "123";//aqui el pin de acceso a la antena del servidor
}
device {
        name "%h-%d";
        class 0x120104;
        iscan enable; pscan enable;
        lm accept;
        lp rswitch,hold,sniff,park;
}

El archivo pin es muy sencillo, simplemente debes poner el pin de la SIM de tu teléfono.

Finalmente configuramos el canal de conexión con el móvil. Para ello debemos averiguar la dirección bluetooth de tu móvil, sería algo así como la dirección MAC, de hecho tiene una estructura semejante. Para ello, inicia el servicio bluetooth, o reinícialo si lo tienes ya iniciado,

/etc/init.d/bluetooth restart

y ejecuta

hcitool scan

Esto te devolverá la lista de dispositivos bluetooth a tu alcance con el nombre y la dirección que tienen. Si obtienes algo como Device is not available: No such device, tu antena no está iniciada, quizás no se ha detectado correctamente, consulta el log de inicio con dmesg a ver qué ocurre cuando conectas la antena al USB.

Supondremos que todo ha ido bien y tienes la lista de dispositivos. Busca el del móvil que estás utilizando y apunta la dirección, la necesitarás añadir al siguiente fichero, rfcomm.conf.

rfcomm0 {
        bind yes;
        device 00:0E:07:E7:12:27;//aqui la dirección bluetooth de tu movil
        channel 1;
        comment "linea bluetooth";
}

Si todo ha ido bien tenemos el sistema bluetooth preparado y enlazado con el móvil.

Enviando mensajes

Instalamos el paquete Gammu. De nuevo, lo más probable es que haya un binario para tu sistema en los repositorios habituales, sino siempre puedes descargar el fuente y compilarlo tu mismo. Configurarlo es muy sencillo. Para empezar tenemos un sólo archivo:

/etc/gammurc
[gammu]
port=/dev/rfcomm0
connection = at19200
logfile = /var/log/smsdlog
logformat = textall
startinfo = yes

En la primera línea indicamos el canal que vamos a utilizar, que es el que configuramos en el paso anterior y añadimos un log para tener información.

Comprobamos si todo va bien. Para eso preguntamos a nuestro teléfono la hora que tiene su sistema, por ejemplo:

gammu --getdatetime

Nos devolverá la hora del teléfono y tendremos todo preparado. Ya podemos probar a enviar mensajes.

echo "probando el envio de SMS" | gammu --sendsms TEXT NUMERODESTINO

Con este sencillo comando podemos configurar cualquier aplicación que necesite enviar alertas para que nos haga llegar un SMS. Así de fácil.

Sistema de mensajería avanzado

Una vez teníamos el sistema anterior montado caímos en la cuenta de que podríamos utilzarlo para hacer más cosas de las que habíamos pensado, sólo necesitábamos saber cómo 🙂 .

Una de las máquinas que utilizábamos de monitor se encontraba en la oficina, tras una línea ADSL. El router de esta línea tenía algún problema que hacía que bajo ciertas circustancias se colgase y había que reiniciarlo, con lo que había que ir personalmente a la oficina para hacerlo. Se nos ocurrió entonces que, si ya teníamos un sistema de envío de SMS funcionando, ¿por qué no hacer que pueda recibir y ejecutar acciones en base a lo que reciba? Dicho y hecho. En vez de responder a POLI BULERIA 😉 , nuestro sistema respondería a ROUTER, aunque posteriormente fuimos ampliando las acciones, como REBOOT que permite hacer un reinicio limpio del servidor y todas las que posteriormente se te ocurran.

Investigando la ayuda de Gammu descubrimos que hay una forma de poner el sistema en modo demonio y que automáticamente recoja los SMS que lleguen al terminal y envíe los que se le encolen. Este procedimiento requiere modificar un poco el sistema, pero una vez configurado ganarás en robustez y efectividad.

La clave es la opción -smsd de gammu que lo pone automáticamente en modo demonio. Este servicio lo que hace es recoger los SMS que se reciban en el móvil y dejarlos como archivos de texto en un directorio específico mientras que coge los SMS que se quieren enviar y que previamente hemos dejado en otro directorio y los envía. Es decir, en vez de hacer los envíos directamente como veíamos antes, los dejas en archivos de texto y automáticamente el demonio los envia. Veamos primero la configuración necesaria. El archivo que maneja toda la configuración es /etc/smsdrc. De nuevo os copio mi configuración tal cual puesto que tiene mucho tiempo y no recuerdo los parámetros.

[gammu]
port=/dev/rfcomm0
connection = at19200
logfile = /var/log/smsdlog
startinfo = yes[smsd]
PIN = PINDETUSIM
logfile = /var/log/smsdlog
commtimeout = 1
sendtimeout = 10inboxpath = /var/spool/gammu/inbox/
outboxpath = /var/spool/gammu/outbox/
sentsmspath = /var/spool/gammu/sent/
errorsmspath = /var/spool/gammu/error/

No tiene mucha ciencia, el primer sector es igual que en el apartado anterior mientras que en el segundo configuramos el PIN de tu SIM y los directorios donde dejar y recoger los SMS tal como explicábamos antes.

Es importante puntializar el formato de los archivos de texto que dejaremos para enviar mensajes los que recibiremos.

  • Mensajes salientes: en outboxpath dejaremos los archivos con el nombre siguiento el patrón
    OUT<phone number>.txt,
    por ejemplo con el nombre OUT666777888.txt se enviaría al 666777888 el contenido del archivo de texto.
  • Mensajes entrantes: en inboxpath recibiremos los mensajes con el nombre del archivo siguiendo el patrón
    IN<date>_<time>_<serialno>_<phone number>_<sequence>.txt
    ,
    por ejemplo IN20021130_021531_00_+45409000931640979_00.txt. En este caso habríamos recibido el 30/11/2002 a las 02:15:31 un mensaje desde el +45409000931640979. Creo que sobran detalles adicionales.

Teniendo esto claro, podemos lanzar el demonio. Tan simple como

/usr/bin/gammu  --smsd FILES /etc/smsdrc &

Si algo va mal nos devolverá algún error, si no, tendremos nuestro sistema de envío y recepción funcionando. Para probarlo, comprueba la ruta inboxpath, si tenías SMS’s en tu teléfono empezarás a ver como entran los archivos de texto. También puedes probar a crear uno en el outboxpath siguiendo el patrón descrito, verás como lo recibes en el otro teléfono.

Hasta aquí tenemos el nuevo sistema de envío y recepción terminado. Deberás modificar tu sistema de alertas para crear los archivos de texto tal como hemos explicado y lo tendrías automáticamente funcionando. También puedes crear un sencillo script PHP que te permita enviar SMS de una manera cómoda, simplemente dejarás los mensajes en forma de archivos de texto en la cola del directorio y el demonio se encargará de enviarlos.

Ejecutando acciones remotas

Ahora deberemos hacer el script que compruebe los SMS recibidos y decida qué hacer con ellos. Os pondré un ejemplo básico para que tengáis una idea clara de cómo habría que hacerlo, es responsabilidad vuestra asegurar el acceso al sistema de acciones de manera que sólo determinados teléfonos puedan ejecutarlas. Yo, por comodidad, lo haré en PHP, pero podéis hacerlo como queráis, PERL, Python, bash, C,…

<?
$inbox="/var/spool/gammu/inbox/";
$outbox="/var/spool/gammu/outbox/";
$d = dir($inbox);
while (false !== ($entry = $d->read())) {
    if ($entry != "." && $entry != ".." && substr($entry, 0, 2)=="IN"){
        $contenido=file_get_contents($inbox.$entry)
        $palabras=explode(" ", trim($contenido));
        $mensaje=substr($entry, 2, strlen($entry));
        $datos=split("_", $mensaje);
        $fecha=$datos[0];
        $hora=$datos[1];
        $numero=$datos[3];
	//utiliza el numero para decidir si permites el reinicio desde ese cliente

	switch(trim(strtoupper($palabras[0]))){
            case 'ROUTER':
                system("/usr/bin/router.sh");
                $mensaje="El Router ha sido reiniciado";
                break;
            case 'REBOOT':
                system("reboot");
                $mensaje="El servidor se está reiniciando";
                break;
            default:
                $mensaje="La palabra clave enviada no se corresponde con ninguno de nuestros servicios.";
        }
        $serial=date("YmdHis");
        $arch=$outbox."OUTA_".$numero."_".$serial.".txt";
        $fp=fopen($arch, "w");
        fwrite($fp, $mensaje);
        fclose($fp);
        unlink($inbox.$entry);
    }
}
$d->close();
?>

El script es muy sencillo, buscamos los archivos del directorio INBOX, analizamos el nombre para ver el número de origen y separamos el contenido por palabras para decidir la acción. Fijáos que con este sistema es fácil crear acciones con parámetros, simplemente se añaden palabras y en el switch se opera como se necesite. En mi caso, cada acción recibida genera una respuesta en modo de SMS a enviar para que sepamos que la acción ha funcionado.

Y esto es todo amigos. Si has seguido bien las instrucciones tendrás un precioso sistema de envío y recepción de SMS desde tu servidor sin necesidad de tener conectividad a Internet. A través de Gammu puedes enviar también MMS, por si te apetece montar un sistema de seguridad que te envíe una captura de una webcam 😉 , por ejemplo. El límite está en tu imaginación y en tus necesidades.

21 comentarios en “Alertas y acciones en tu servidor a través de SMS

  1. Impresionante artículo.

    Solo una pregunta, supongo que eso lo puedes hacer con servidores que tienes “in house” (en la empresa), pero no para servidores en “The Planet” o cualquier otro hosting, ¿Que se puede hacer en esos casos?

    Supongo que poco a menos que sea el proveedor de hosting el que lo ofrezca.

    Se que hay que se dedican a monitorizar los servidores que les digas y te envían SMS|email|tam-tam|señales de humo cuando algo ocurre.

  2. Buenas Jose!!!

    Veo que me sigues 🙂 .

    Claro, tal como dices tienes que tener acceso al servidor, por eso decía que lo uso en máquinas que hacen de monitor y backup que las solemos tener más accesibles. Si tu hosting está cerca siempre podrías areglarlo con ellos, pero lo más probable es que en el CPD no tengas cobertura de móvil con lo cual no solucionarías mucho.

    Para mi, la solución, es tener tus máquinas remotas bien monitorizadas, no solo la disponibilidad sino también los servicios como he explicado en otro artículo. A partir de ahí que sea el monitor el que se encargue de lanzar las alertas que para eso está. De hecho, la principal es la de disponibilidad y es fácil de detectar en el monitor, las demás puedes enviarlas con cualquier pasarela SMS-HTTP o incluso pasárselas con peticiones HTTP a la máquina monitor para que las envíe a tu teléfono como he descrito. Cada uno escoge su método.

    Si tienes el monitor en el mismo sitio que los servidores de producción nunca vas a detectar problemas de conectividad, con lo cual no te serviría de mucho (esto es por experiencia propia 😛 ). No es buena idea hacerlo.

    Si necesitas minimizar el riesgo también puedes utilizar servicios externos como indicas y tienes dos variables de error a tener en cuenta, tu monitor y el externo. Todas las precauciones son pocas.

    Saludos,
    Osus

  3. Estuvimos un tiempo con el Nagios funcionando, pero nos enviaba tantas falsas alarmas que lo quitamos. Por falta de tiempo, y otras prioridades, para ajustarlo y encima pillamos una época que nuestros proveedor de conexión (ONO) fallaba un par de veces a la semana.

    Si tienes un servidor monitorizando a otros, cosa que realmente me parece buena idea, y recibes una alerta de no disponibilidad general, creo que sería buena idea el que el servidor que monitoriza compruebe que SU conexión a Internet funciona, verificando el acceso a dos o tres servicios (google.com, microsoft.com, yahoo.com) si todos fallan entonces es el monitor el que no tiene conectividad. ¿Que te parece?

    Estoy pensando en montar en una máquina “vieja” un CentOS para eso. Ya contaré.

    Un saludo.

  4. Toda la razón Jose. Poner Nagios a punto no es nada sencillo, hay que dedicarle mucho tiempo.

    Sobre tu segundo comentario, siempre digo lo mismo: ¿quien monitoriza al monitor? 😛 . Desde luego lo que propones es lo más lógico, lo primero es asegurar la disponibilidad del monitor, no creo que haya nada que discutir.

    Te recomiendo que le eches un ojo a http://www.centreon.com tal como me recomienda HOOD en otro de mis artículos, viniendo de él seguro que sabe lo que dice 😉 .

  5. hola me parece muy interesante tu articulo, me gustaria saber donde puedo checar el articulo o la informacion donde realizaste lo mismo pero mediante el puerto serie (conectar el terminal al ordenador por el puerto serie).
    De antemano Gracias x la atencion 🙂

  6. El manual es fantástico. Yo lo he probado en una Ubuntu 7.10 y ha salido todo bien, exceptuando un error extraño que decía “Can’t open specified file. Read only? “, aunque no he tardado mucho en darme cuente de que era el fichero log que no estaba creado.

    Enhorabuena!

  7. Muy interesante el articulo, hace tiempo que quiero implementar un sistema de envio de SMS para recibir informacion la las distintas fallas de los servidores o UPS, etc. La consulta que te queria hacer es dispongo de lagunos sistemas que pueden enviar correo electronico en lugar de mensajes SMS y la idea que tenia es hacer una especie de pasarela de SMS a la cual tambien pueda llegar con mensajes desde el servidor de correo, te parece que es viable ? me podes dar una orientacion si es posible a gragar a lo que planteas aqui una pasarela para correo, supongo que lo habras visto por ejemplo crear un domio interno y enviar correa numerotelef@dominio, Muchas gracias por el articulo nuevamente.
    Bernardo

  8. Hola Bernardo,

    Totalmente viable. Sólo tienes que hacer una tarea que compruebe un buzón de correo y te envíe el contenido o el subjet por sms. Ningún problema.

  9. Gracias Osus por tu pronta respuesta. En cuento tenga un poco de tiempo libre voy a comenzar con las pruebas y una vez que tenga instalado y funcionado lo que planteas en tu articulo, seguramente te molestare nuevamente para que me eches una mano con la configuracion de la tarea para recoger el correo. Por el momento muchas gracias.
    Bernardo

  10. Genial la información, pero he tenido algunos problemas con el modo demonio.

    Usando el gammu –smsd y el archivo de configuracion que has puesto, no conseguía ni enviar ni recibir ningun sms.

    Ahora no lo tengo asi, pero si me acuerdo mañana, posteo mi archivo de configuración válido de /etc/smsdrc, que además creo que tira también del archivo de configuracion para uso normal de /etc/gammurc para el tema de la indicacion del puerto o terminal usado, tipo de transmision, etc

    A los demás que lo hayan probado si los ha funcionado conrrectamente tal y como lo tenia puesto nuestro Osus??

    Un saludo Osus, y muchas gracias por tu post y tu información, ha sido útil. 🙂

  11. Como instalo Gammu lo bajo con .tar y lo compilo pero me da error, ambien no encuentro en el directorio /etc/bluetooth a pin no se si es un archivo o hay que crearlo vacia

  12. Buen tutorial, muchas gracias.
    Yo lo he usado para recibir alertas de cambio de estado de un SAI y todo me funciona perfecto menos el envío de sms.

    en el script tengo
    #!/bin/sh
    /bin/echo “$*” | /usr/bin/gammu –sendsms TEXT 6123456789
    /bin/echo “$*” |mail -s “MENSAJE DEL SAI” [email protected]

    recibo el mail pero no el sms, si copio la linea de gammu en una consola funciona perfectamente.

    alguien me puede ayudar?

  13. @saba01

    Tiene toda la pinta de ser un problema de permisos.
    Prueba el envío desde la línea de comandos con el mismo usuario que utiliza el monitor del sai, a ver si funciona.

  14. buen articulo me gustaría saber si puedo usar este mismo sistema para monitorear una ups montada en un cerro esta ups su modo de monitorio lo hace mediante una tarjeta snmp pero se tiene la necesidad de enviar sms a diferentes celulares para saber que hay algún problema espero puedas ayudarme muchas gracias

  15. @mao.alvarez,

    Si tienes acceso snmp puedes integrarlo sin problemas, el artículo te explica como enviar los mensajes, la integraciópn con el ups ya es cosa tuya 🙂

    Si no quieres complicarte también puedes usar una pasarela de envío de mensajes, cualquier empresa que se dedique al negocio de SMS te la podrá ofrecer.

Responder a madoris Cancelar la respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *