Archivo de la categoría: Sistemas

Error con el smtp autentificado con los clientes de Nokia a través de Qmail

General, Móvil, Negocios, Sistemas, Técnico, , , , ,

Como os decía hace unos días, recientemente he cambiado el Nokia N70 que llevaba desde hace algo más de dos años por un Nokia E51. La característica más importante de este nuevo terminal es la disponibilidad de conexión WIFI, con lo cual, si tienes un poco de suerte y encuentras un punto de acceso abierto, puedes tener acceso a tu correo desde cualquier punto. No he tenido muchos problemas para encontrar puntos de acceso y habitualmente he podido leer el correo. El problema llega a la hora de enviarlo ya que siempre obtengo un error en el envío. Cansado de no saber qué ocurría y dado que voy a estar unos días fuera de casa, decidí investigar un poco.

Comencé por ver cual era la comunicación del cliente de correo con mi servidor. Para ello lancé un sniffer en mi máquina, en este caso Wireshark, nombre actual del Ethereal de toda la vida. Para no volverme loco con todo el tráfico que iba a ver añadí un filtro, de manera que sólo se mostraría el tráfico que venía desde la IP de mi conexión ADSL (11.22.33.44), así sólo vería lo que estaba generando mi propio móvil.

tshark -i2 -f "src host 111.222.333.444"

Y este fué el resultado:

3.197223 11.22.33.44 -> 55.66.77.88 TCP 49537 > smtp [SYN] Seq=0 Win=64240 Len=0 MSS=1460 TSV=1218449730 TSER=0 WS=0
3.197263 55.66.77.88 -> 11.22.33.44 TCP smtp > 49537 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=389435772 TSER=1218449730 WS=7
3.347274 11.22.33.44 -> 55.66.77.88 TCP 49537 > smtp [ACK] Seq=1 Ack=1 Win=64240 Len=0 TSV=1218663480 TSER=389435772
3.356257 55.66.77.88 -> 11.22.33.44 SMTP Response: 220 servidor ESMTP
3.509426 11.22.33.44 -> 55.66.77.88 SMTP Command: EHLO
3.509451 55.66.77.88 -> 11.22.33.44 TCP smtp > 49537 [ACK] Seq=29 Ack=22 Win=5888 Len=0 TSV=389436084 TSER=1218828105
3.509490 55.66.77.88 -> 11.22.33.44 SMTP Response: 250-servidor
3.663467 11.22.33.44 -> 55.66.77.88 SMTP Command: AUTH CRAM-MD5
3.813384 11.22.33.44 -> 55.66.77.88 SMTP Command: amlxxxxxxWFzIDkxNTM4MxxxxxxyYjVjOTdmYxxxxxxxDFhZDg2MjEw
3.853554 55.66.77.88 -> 11.22.33.44 TCP smtp > 49537 [ACK] Seq=197 Ack=95 Win=5888 Len=0 TSV=389436428 TSER=1219132230
8.817212 55.66.77.88 -> 11.22.33.44 SMTP Response: 535 authorization failed (#5.7.0)

Es decir, me estaba fallando la autentificación a través de CRAM-MD5 a pesar de que en el programa de correo del móvil tenía correctamente introducidos el usuario y la clave y el servidor, obviamente, se presentaba diciendo que soportaba este método.

[osus@servidor ~]# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
220 servidor ESMTP
ehlo
250-servidor
250-AUTH LOGIN CRAM-MD5 PLAIN
250-PIPELINING
250 8BITMIME

Investigando un poco averigué que para habilitar la autentificación CRAM-MD5 en Qmail, el MTA de correo que utilizo, además de instalar el parche qmail-smtp-auth es necesario sustituir el original checkpasswd  por cmd5checkpw. Con este argumento caí en la cuenta de que nunca jamás he tenido esta autentificación funcionando en mis servidores 😀 , el servidor indicaba que sí pero la realidad era que no 😛 . Ocho años utilizando Qmail y ahora me doy cuenta de que no funcionaba.

No quería complicarme mucho así que, si hasta ahora no la tenía, tampoco me importaba seguir así. Pensé entonces que, si en vez de responder a los clientes que soportaba CRAM-MD5, no se lo decía, el cliente del E51 escogería el AUTH LOGIN de toda la vida y funcionaría. ¿Cómo hacer esto? Sencillo, Qmail es de código abierto y tenemos el código fuente a nuestra disposición.

Parcheando Qmail

En los fuentes de mi Qmail (con todos sus parches) busqué la cadena en cuestión:

grep  CRAM-MD5 *

Y ahí me apareció el objetivo de nuestro parche, qmail-smtpd.c.

Dicho y hecho, abrimos el archivo con vi y buscamos la cadena en cuestión (:/CRAM-MD5) llegando a:

out("rn250-AUTH LOGIN CRAM-MD5 PLAIN");

Esto va a ser sencillo. Modificamos esa/s línea/s de manera que quede/n:

out("rn250-AUTH LOGIN PLAIN");

De este modo, cuando el cliente pregunte le diremos que soportamos LOGIN y PLAIN, pero no CRAM-MD5. He explicado esto en plural porque es más que probable que tengas dos líneas iguales y no sólo una. Puedes dejar sólo una modificada como he indicado o modificar las dos.

Compilamos ahora con un simple make. Como sólo hemos  modificado este archivo únicamente se compilará este. Hacemos una copia de seguridad de nuestro /var/qmail/bin/qmail-smtpd (por si algo no va bien) y copiamos el nuevo a esta ruta dejando los permisos, owner y group igual que tenía el que había.

Si ahora pruebas a enviar un email desde el Nokia E51 comprobarás que funciona correctamente, el cliente del teléfono escoge otro de los sistemas. Utilizando de nuevo el sniffer verás que ahora escoge AUTH LOGIN como método de autentificación.

Ya puedo enviar correo desde mis servidores con el teléfono. Gracias a un sencillo ejercicio de escucha del tráfico de red hemos averiguado cual era el problema.

Conexiones VPN entre máquinas Linux y Windows con autentificación a través de servidor Radius y MySQL

General, Sistemas, Técnico, , , ,

Un día, harto de tener que abrir puertos y más puertos para cada cosa que quería hacer con el servidor Linux que tengo en casa, se me ocurrió hacer algo para poder conectarme directamente a ésa máquina y tener todos los servicios a mi disposición sin tener que crearlos uno a uno. La solución estaba clara, establecer una VPN contra ese servidor y automáticamente tendría acceso a todos los servicios disponibles. El problema principal a la hora de establecer esta red virtual era que tenía que ser sencilla, rápida de crear y, sobre todo, no necesitar software adicional ya que así podría utilizarla desde cualquier ordenador en cualquier localización. Es más, si me lo montaba bien tendría un sistema perfecto para dar soporte remoto a mis hermanas a través de VNC sin tener que abrirles esos puertos 😉 .

Por defecto todos los equipos Windows traen de serie un cliente VPN que puede contectarse a redes privadas virtuales, pero no de cualquier tipo, sólo PPTP. Podríamos haber escogido otro sistema basado en IPsec o incluso OpenVPN, pero necesitaríamos software adicional además de cerficados en ámbos extremos de la VPN, lo que no cumpliría los requisitos que nos habíamos impuesto. PPTP es un protocolo desarrollado por Microsoft (por eso viene de serie con Windows) y, gracias a eso, ha tardado mucho en haber un cliente (y más aún un servidor) que funcione bajo Linux. No es el más seguro de los protocolos de VPN 😛 pero dejémoslo en que cumple sus funciones.

La idea es, por tanto, montar un servidor PPTP bajo Linux. Una vez tengamos el servidor veremos como conectar tanto desde Linux como desde Windows. Aunque la idea de este artículo parte de un entorno doméstico es completamente aplicable a pequeñas empresas que necesiten dar acceso remoto a sus empleados sin complicarles la vida ni realizar grandes desembolsos en routers dedicados o en un servidor Windows (entendiendo esto como una máquina con algún Windows Server 😉 .

Servidor PPTP bajo Linux

Vamos a enrevesar un poco más nuestro servidor. Para da más versatilidad haremos que la autentificación de los usuarios se realice a través de un servidor Radius que posteriormente podemos utilizar para autenticar cualquier otro servicio que se nos ocurra (ftp, email, hotspot inalámbrico…).

Creo que aún es muy sencillo, vamos a complicarlo más aún. El servidor Radius autenticará, así mismo, contra una base de datos MySQL, con lo que tendremos un sistema muy facil de administrar sin tener que estar tocando archivos de texto para crear usuarios nuevos. El escenario es, por tanto PPTP+Radius+MySQL.

Como software vamos a utilizar:

  • Servidor Linux, Centos 5.2 en mi caso.
  • PopTop, servidor PPTP bajo Linux.
  • PPTP Client, cliente PPTP bajo Linux.
  • FreeRadius como servidor Radius.
  • Radiusclient como cliente Radius, para que PopTop pueda consultar el servidor Radius.

Para instalar el software, en mi caso, nada más sencillo. Primero instalamos el repositorio yum de PopTop:

rpm -Uvh http://poptop.sourceforge.net/yum/stable/fc7/pptp-release-current.noarch.rpm

Y ya podemos instalar todo el software:

yum --enablerepo=poptop-stable install freeradius freeradius-mysql radiusclient pptp pptpd

Creo que con eso sería suficiente y tendríamos todo lo necesario. Asumimos, por supuesto, que ya tienes MySQL instalado.

Antiguamente era más complicado instalar PopTop ya que había que parchear el kernel, pero hoy en día, si tu núcleo es superior a 2.6.15 (si no lo es, ¿a qué esperas para actualizarlo?), no es necesario este paso. De todos modos, si tuvieses que hacerlo, es totalmente seguro, yo mismo lo hice durante mucho tiempo. En la web de PopTop tienes las instrucciones para hacerlo.

Suponiendo que hemos instalado correctamente todo el software sin ningún problema, ya sólo nos queda configurar todos y cada uno de los pasos que conforman nuestro servidor VPN.

Configurando PopTop

Lo primero que debes hacer es decidir que direccionamiento utilizarás en tu VPN. En mi caso tengo uno independiente de todo lo demás (192.168.3.0), así puedo gestionarlo a mi antojo, permitiendo o denegando lo que se me ocurra de una manera sencilla. A continuación indico los archivos de configuración a toquetear y como tengo los míos.

/etc/pptpd.conf

[osus@servidor ~]# cat /etc/pptpd.conf
option /etc/ppp/options.pptpd
localip 192.168.3.1-5
remoteip 192.168.3.6-10

El parámetro localip tendrá las IP’s que utilizará tu servidor como locales cada vez que reciba una conexión mientras que en remoteip indicarás las que va a dar dinámicamente a los clientes. Tendrás que poner un rango lo suficientemente amplio como para cubrir las posibles conexiones simultáneas que puedas tener.

/etc/ppp/options.pptpd

[osus@servidor ~]# cat /etc/ppp/options.pptpd
name pptpd
refuse-pap
refuse-chap
refuse-mschap
require-mschap-v2
require-mppe-128
proxyarp
lock
nobsdcomp
novj
novjccomp
nologfd
plugin radius.so

Sería recomendable que consultases las páginas man para saber qué hace cada parámetro.

Como véis, al final de todo indicamos al servidor PPTP que utilice el pluggin para Radius, así que configuremos todo lo relativo a Radius.

Configurando FreeRadius

/etc/raddb/clients.conf

[osus@servidor ~]# cat /etc/raddb/clients.conf
client 127.0.0.1 {
        secret          = TUCLAVESECRETA
        shortname       = localhost
}

Debemos indicar, para cada servidor Radius que tenemos, una clave de conexión y el nombre del mismo. La clave deberán utilizarla los clientes radius para consultar al servidor. Lo normal en un entorno como el nuestro es que el servidor Radius sea el mismo donde reside el servidor VPN.

El siguiente archivo es el más importante ya que se indica a FreeRadius que autentifique las peticiones contra un servidor MySQL. Como es muy largo pondré solamente las partes relevantes:

/etc/raddb/radiusd.conf

mschap {
 authtype = MS-CHAP
 use_mppe = yes
 require_strong = yes
}

authorize {
        preprocess
        mschap
        suffix
        eap
        sql
}

authenticate {
        Auth-Type MS-CHAP {
                mschap
        }
        eap
}

preacct {
        preprocess
        suffix
        files
}

accounting {
        detail
        acct_unique
        sql
}

session {
       sql
}

En /etc/raddb/sql.conf  debes configurar correctamente el acceso a tu base de datos MySQL, servidor, usuario, clave y base de datos que veremos un poco más adelante.

Configurando el cliente Radius

/etc/radiusclient/servers

[osus@servidor ~]# cat /etc/radiusclient/servers
localhost       TUCLAVESECRETA

Donde la clave es la misma que pusiste en /etc/raddb/clients.conf y localhost la dirección de tu servidor si es distinto al que tiene el pptpd.

En /etc/radiusclient debes tener el archivo dictionary.microsoft. Creo recordar que tuve algunos problemas con él, por si acaso dejo el que tengo ahora mismo que no es el que venía por defecto.

En /etc/radiusclient/radiusclient.conf asegurate que tienes los siguientes parámetros apuntando a la IP de tu servidor Radius si no es el mismo donde reside el servidor VPN:

authserver      localhost
acctserver      localhost

Si son distintos a localhost, no te olvides de configurarlos aquí.

Creando la base de datos MySQL

Llegamos al último paso.

Crea una nueva base de datos (create database radius) y un usuario con permisos sobre ella. Recuerda configurar ahora /etc/raddb/sql.conf  con estos datos.

Ahora crea la estructura de la base de datos. Con el paquete FreeRadius viene la estructura que necesitas.

mysql radius < /usr/share/doc/freeradius-1.1.3/examples/mysql.sql

El paso que viene a continuación siempre lo ignoran cuando alguien explica cómo configurar FreeRadius contra MySQL y creedme que no es nada intuitivo.

¿Cómo se rellenan las tablas de autentificación?

Buena pregunta Manel 😛 .

  • Tabla radcheck: mantiene las cuentas de usuario con los siguientes campos:
    • UserName: nombre de usuario.
    • Attribute: Password (literalmente, no la clave del usuario sino la palabra Password).
    • op: == (dos signos de igual).
    • Value: clave del usuario.
  • Table radreply: contiene parámetros de inicialización de los clientes que se conectan. Aquí yo configuro las IP’s que quiero dar a determinados clientes por cuestiones de comodidad.  Además indico que sólo voy a permitir una conexión simultánea con el mismo usuario.
    • UserName: nombre de usuario que estás configurando (según lo introducido en la tabla radcheck).
    • Attribute: la palabra Framed-IP-Address ó Simultaneous-Use, según indiques la IP a asignar a ese usuario o el número máximo de sesiones con el mismo nombre.
    • op: = (un sólo signo igual)
    • Value: 192.168.3.99 (la IP que quieras) ó el número máximo de conexiones simultáneas con el mismo usuario.
  • Table usergroup: agrupa los usuarios en grupos.
    • UserName: nombre de usuario
    • GroupName: nombre de grupo.

La tabla radact contiene el log de actividad del servidor, sesiones iniciadas, duración, etc.

Últimos pasos

Recuerda que debes abrir en tu router y/o firewall el puerto 1723 para que permita conexiones entrantes ya que es el usado por el protocolo PPTP.

Aunque como veremos más adelante podemos auditar las conexiones al servidor Radius (y por ende al servidor VPN) puede ser interesante tener un mecanismo de aviso de que un cliente se ha conectado. Una forma de hacerlo es consultando las interfaces de red disponibles en el servidor (ifconfig), habrá tantos pppX como usuarios activos. Pero hay otro método que te permite recibir, por ejemplo por email, un aviso cada vez que un usuario conecta o desconecta.

Cada vez que se levanta una interfaz ppp se ejecuta el script /etc/ppp/ip-up.local con todos los parámetros relativos a esa conexión, ip remota, local, interfaz… Igualmente cuando se desconecta se lanza /etc/ppp/ip-down.local. Solo debemos adaptar este script a nuestras necesidades. Estos scripts reciben todos los parámetros necesarios para identificar al usuario. Haríamos algo así, por ejemplo para ip-up.local.

#!/bin/sh
if [ "$5" == "192.168.3.10" ]
then
        cliente="pepito"
fi
echo  "Conexion VPN
Interfaz: $1
VPN Local: $4
VPN Remota: $5
IP Remota: $6
1: $1
2: $2
3: $3
4: $4
5: $5
6: $6
"  | mail -s "Conexion VPN - $cliente" [email protected]

De este modo recibirías un email cada vez que un usuario  levanta un tunel VPN con tu servidor y sabrías qué ip tiene el usuario y, si le has otorgado una IP fija en la configuración de Radius, sabrás qué usuario es, en este caso “pepito“.

Con ip-down.local harías un script semejante sólo que en vez de Conexión VPN en el asunto del email pondríamos Desconexión VPN. Los parámetros son exactamente los mismos.

Estos scripts podemos aprovecharlos también para crear/modificar/eliminar determinadas rutas en función de los túneles creados.

El propio paquete pptpd te habrá instalado el script de inicio necesario, en mi caso /etc/init.d/pptpd. Sólo debo añadirlo a la secuencia de arranque del runlevel de mi servidor y automáticamente estará siempre disponible el servicio.

En teoría, todas las vpn’s que se hagan contra el servidor tienen enrutamiento entre sí, es decir, podrías llegar desde un cliente a otro pasando por el servidor sin toquetear nada más. Digo en teoría porque esa es la función del parámetro proxyarp que configuramos hace un rato. Puede que este enrutamiento no sea suficiente y que necesites que los clientes VPN puedan acceder a otras subredes de tu infraestructura. Puedes hacerlo como quieras, incluso configurar un bridge, pero para estas cosas nada mejor que iptables.

Supongamos un escenario en el que tenemos una lan local de la que forma parte nuestro servidor (direccionamiento 192.168.0.0) y la nueva red que creamos para las VPN’s (direccionamiento 192.168.3.0). Para permitir el enrutamiento completo entre las dos redes haríamos algo como:

#!/bin/sh
echo 1 >/proc/sys/net/ipv4/ip_forward
LAN="192.168.0.0/16"
VPN2="192.168.3.0/24"
iptables -A FORWARD -s $LAN -d $VPN2 -j ACCEPT
iptables -A FORWARD -s $VPN2 -d $LAN -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -d $VPN2 -j MASQUERADE

Sencillo. Si sólo quisiésemos que ciertos usuarios accediesen a la red local modificaríamos la variable VPN2 por la IP que radius le da al usuario.

FreeRadius desde un  entorno web, dialup_admin

Vale, es cierto, es un auténtico coñazo gestionar FreeRadius y todos sus parámetros, así que, que mejor que un sencillo entorno web para la gestión de usuarios y visualización de actividad y log del sistema. Esta utilidad es dialup_admin. No me detendré en su instalación ya que creo que se sale fuera de este artículo y, además, es una sencilla aplicación web sin mucha dificultad.

 radiusweb.gif

Con esta herramienta será mucho más sencillo crear usuarios y sus propiedades y hacer un seguimiento de los que están conectados, periodos de conexión que han tenido, etc.

Estableciendo la VPN desde Windows

Sencillísimo. Desde Conexiones de red, se crea una conexión nueva, escoges Conectarse a la red de mi lugar de trabajo y prácticamente sólo queda introducir el host o IP de tu sevidor VPN y  conectarse. Recomiendo desmarcar la opción Usar puerta de enlace predeterminada en la red remota en las propiedades de esta nueva conexión, Funciones de red, Protocolo TCP/IP, Opciones avanzadas, de otro modo todo el trafico de Internet normal lo harás a través de la VPN.

Si todo va bien conectarás a tu servidor y tendrás acceso al mismo como si estuvieses en tu propia red local.

Estableciendo la VPN desde Linux

Desde Linux es un pelín más complicado ya que, como casi siempre, hay que hacer la configuración a mano. Existe una utilidad gráfica que permite crear las conexiones de un modo similar a Windows, pero prefiero explicar cómo hacerlo desde la consola por si tu máquina no tiene entorno gráfico.

[osus@servidor ~]# cat /etc/ppp/options.pptp
lock
noauth
refuse-eap
refuse-chap
refuse-mschap
nobsdcomp
nodeflate

Ahora indicamos el usuario y la contraseña que se utilizará para conectar. IdentificadorRed será el nombre que le demos a la conexión, puede ser lo que quieras.

[osus@servidor ~]# cat /etc/ppp/chap-secrets
usuario IdentificadorRed clave *

Ahora creamos la configuración para la conexión que vas a crear con el IdentificadorRed que comentamos antes. En TUIP debes poner el host o ip de tu servidor VPN.

[osus@servidor ~]# cat /etc/ppp/peers/IdentificadorRed
remotename IdentificadorRed
linkname IdentificadorRed
ipparam IdentificadorRed
pty "pptp TUIP --nolaunchpppd "
name usuario
require-mppe
require-mschap-v2
refuse-eap
refuse-pap
refuse-chap
refuse-mschap
#demand
holdoff 5
persist
maxfail 0
ipcp-accept-remote
ipcp-accept-local
noauth
192.168.3.1:192.168.3.254

Aquí hay dos opciones interesantes:

  • persist: vuelve a crear el tunel automáticamente si se cortase por alguna razón de manera que permanece siempre activo.
  • demand: crea automáticamente el tunel cuando se accede a la IP del servidor o a alguna otra que esté enrutada a través de este tunel,  mientras no se necesite permanece inactivo. Obviamente no debe estar en modo persist, de otro modo estará siempre activa.

Finalmente creamos un sencillo script de arranque para poder lanzarla automáticamente o simplemente para no tener que recordar los parámetros.

[osus@servidor ~]# cat /etc/init.d/IdentificadorRed
#!/bin/sh
  case "$1" in
      start)
            echo -n "Iniciando VPN IdentificadorRed "
            echo
            touch /var/lock/subsys/pptpd
            /usr/sbin/pppd call IdentificadorRed logfd 1 updetach &
            ;;
      stop)
            echo -n "Parando VPN IdentificadorRed: "
            echo
            kill -TERM `head -n 1  /var/run/ppp-IdentificadorRed.pid`
            ;;
      *)
            echo "Usage: $0 {start|stop}"
            exit 1
  esac
exit 0

Y eso es todo amigos. Me ha costado bastante más de lo previsto escribir este artículo ya que a medida que lo iba redactando me iba saltando nuevos recuerdos sobre detalles que se deberían nombrar.

Tened en cuenta que mi experiencia con PPTP se remonta cinco años atrás con lo que puede ser que algún detalle haya cambiado los últimos años. Después de aquel primer servidor VPN el año pasado migramos el sistema operativo a Centos5 y al configurar de nuevo el servidor VPN dejamos prácticamente todos los parámetros como estaban. No creo que tengáis ningún problema a la hora de solucionar algún pequeño detalle que pueda surgir.

Haciendo streaming de vídeos a móviles

Proyectos, Sistemas, Técnico, , , ,

Antes de comenzar este artículo, y para que nadie se haga ilusiones, aclararé que no es posible hacer streaming por tu cuenta a través de las conexiones de datos de las operadoras tradicionales. Tienen esos puertos bloqueados para que sólo ellas o quien ellas quieran pueda ofrecer este servicio, de ahí la exclusividad de los canales de televisión en el móvil que tanto promocionan y que no son más que servicios de streaming. Si cualquiera pudiese hacerlo se les terminaría el chollo, aunque siempre queda el asunto del tráfico de datos, a ti te lo cobrarían íntegramente mientras que en sus canales no, ya pagas la suscripción mensual.

No lo he probado con las nuevas operadoras virtuales ni con Yoigo, aunque es posible que con éstas sí que funcione. De todos modos, con la proliferación de terminales con wifi se abre un nuevo mundo de posibilidades sin límite, entre ellos el streaming.

En esta ocasión utilizaremos un servidor Linux (Centos5.2) y como servidor de streaming, Darwin Stream Server.

Darwin es la versión Open Source del QuickTime Streaming Server de Apple, sí, habéis oído bien, Apple, la del iPod y la del iPhone, y permite enviar streamings a través de los protocolos estandar RTP y RTSP. Pero lo que hace más interesante a Darwin sobre otros servidores de streaming es que maneja perfectamente archivos MPEG4 y 3gpp, algo imprescindible si queremos enviarlos a dispositivos móviles

Puedes descargar aquí el archivo de instalación para Linux. Una vez lo descomprimes, la instalación es extramadamente sencilla, sólo debes ejecutar el archivo Install y un asistente te guiará. Cuando haya terminado tendrás tu servidor de streaming funcionando. Vamos a probarlo

La instalación deja todos los archivos de configuración en /etc/streaming y algunos vídeos de ejemplo en /usr/local/movies, ruta por defecto para los archivos. Puedes modificar esta ruta en el archivo /etc/streaming/streamingserver.xml buscando el parámetro de nombre “movie_folder”. Lo dejaremos como viene por defecto.

Si no has iniciado todavía tu servidor, hazlo con el siguiente comando:

/usr/bin/perl /usr/local/sbin/streamingadminserver.pl

Si todo ha ido bien puedes probar los vídeos de ejemplo. Abre tu Quicktime Player y abre la url:

rtsp://tuip/sample_h264_300kbit.mp4

Si has seguido bien los pasos verás un vídeo de muestra de QuickTime. Tu servidor de streaming ya está funcionando.

Prueba ahora alguno de tus vídeos 3gpp. Copialos a la ruta correspondiente de tu servidor, /usr/local/movies y llámalos con la url anterior cambiando el nombre del archivo:

rtsp://tuip/nombre.3gp

Deberías ver tu vídeo en el Quicktime Player. Prueba ahora desde tu móvil. Abre el Real Player (o el software que traiga para visualizar vídeos por streaming) e introduce esa dirección.

Cierto, no funciona 😛 . No podía ser tan simple 🙂 …

Preparando los archivos para visualizar en el móvil

Para visualizar los vídeos 3gpp y mp4 en el móvil a través de Darwin han de someterse a un proceso denominado hint.

Necesitaremos una nueva herramienta que haga este proceso, en este caso será el paquete gpac. Descargamos e instalamos el software y tendremos el programa que necesitamos, MP4Box. Ahora simplemente debemos ejecutar la siguiente instrucción en todos nuestros vídeos:

/usr/local/bin/MP4Box -3gp -mtu 1450 -hint video.3gpp

Ya está. Si vuelves a intentar ver el vídeo en tu móvil comprobarás como ahora sí que se visualiza.

Creando gráficas del servidor Darwin en Cacti

Hace algunos meses os conté como monitorizar tu servidor con Cacti. Vamos pues a añadir gráficas de nuestro servidor de streaming para poder monitorizar la actividad del mismo.

Graficas Cacti Darwin Stream Server

Lo primero que debemos hacer será habilitar el acceso remoto desde la IP de nuestro monitor Cacti a la consola de administración del servidor, el “remote admin”. Para ello editamos /etc/streaming/streamingserver.xml, localizamos el módulo QTSSAdminModule y en el parámetro IPAccessList introducimos la IP correspondiente, ponemos a false LocalAccessOnlyenable_remote_admin y a true. Habrá que reiniciar el servidor. Quedaría tal que así.

<MODULE NAME="QTSSAdminModule" >
<PREF NAME="IPAccessList" >XXX.XXX.XXX.XXX</PREF>
<PREF NAME="Authenticate" TYPE="Bool16" >true</PREF>
<PREF NAME="LocalAccessOnly" TYPE="Bool16" >false</PREF>
<PREF NAME="RequestTimeIntervalMilli" TYPE="UInt32" >50</PREF>
<PREF NAME="enable_remote_admin" TYPE="Bool16" >true</PREF>
<PREF NAME="AdministratorGroup" >admin</PREF>
</MODULE>

Ya tenemos el servidor de streaming listo, ahora tocaremos en el servidor Cacti. Aquí está todo explicado, pero lo repasaremos. Creo recordar que no me funcionaban tal cual las plantillas, así que os dejo las que tengo en funcionamiento. En el archivo encontrarás dos scripts python y dos plantillas. Los scripts debes copiarlos a la carpeta “scripts” de tu instalación Cacti. Los “templates” debes importarlos desde “Import templates” de la inferfaz web.

Con esto  ya sólo tendremos que añadir las gráficas correspondientes a la máquina que vamos a monitorizar, DSS Current Bandwidth  y DSS – Current Connection Count. Nos solicitará rellenar algunos datos:

  • Servidor: ip de la máquina con el Darwin.
  • Puerto: si no has cambiado nada, el 554.
  • Usuario: usuario de administración del servidor Darwin que hayas configurado al instalarlo.
  • Clave: la contraseña del usuario anterior.

Tendremos dos gráficas, número de conexiones y ancho de banda consumido.

No me hago responsable del gasto  en tráfico de datos con tu operadora que te suponga probar lo expuesto en este artículo 😛 . Otro día veremos como generar vídeos 3gpp bajo demanda a partir de casi cualquier otro formato.

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

General, PHP, Programación, Sistemas, Técnico, , , , , , ,

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.

Sobre incendios, CPD’s y otros desastres naturales

General, Negocios, Proyectos, Sistemas, Técnico, , , ,

Supongo que a estas alturas ya la mayoría os habréis enterado del incendio ocurrido en uno de los CPD’s (centro de proceso de datos) que The Planet tiene en Houston, Texas. Al parecer la causa del incendio fué la explosión de uno de los transformadores que dan servicio al CPD. Debido al incendio se tuvo que cortar completamente sl suministro eléctrico del centro provocando con ello el apagado de unos 9.000 servidores, entre ellos los DNS principales de la antigua EV1, había servicio de respaldo pero los bomberos obligaron al corte completo como medida de seguridad. Creo que han tardado algo más de 24h en restaurar completamente el servicio, desde el foro se pudo seguir la evolución de la incidencia.

El CPD en cuestión era uno de los que EV1 Servers tenía cuando fue adquirida por The Planet hace un par de años y el más antiguo de la compañía.

Pues bien, nosotros tenemos servidores en The Planet desde 2002, de hecho teníamos servidores en ese CPD de EV1 hasta agosto del año pasado cuando, gracias a unas buenas ofertas, los migramos a nuevas máquinas y con ello cambiamos de centro de datos, ahora estamos en Dallas, sino ahora mismo seríamos uno de los afectados.

He leído mucho estos días acerca de lo ocurrido. He llegado a leer si realmente vale la pena llevarte la infraestructura a USA cuando puede ocurrir esto que ha ocurrido. Y yo me pregunto, ¿acaso esto no podría ocurrir en España? Esto y mucho más 😉 , los problemas son independientes del lugar, si no es un transformador el que explota es una regleta que se quema, una fuente estropeada o un router colgado. También podría ser otra máquina con la que compartes RACK y/o router que ha sido atacada o mil historias más, ¿verdad Raúl?, pero problemas los hay en todas partes. ¿Acaso por tener tus máquinas en un CPD de Logroño estando tú en Valencia vas a resolver algo que no podrías resolver si están en USA? La respuesta es obvia a no ser que tengas enchufe y te vayan a tratar antes y mejor por ser tú, cosa poco probable para la mayoría. Lo que debes pensar es en tener gente detrás que vaya a solucionarte los problemas que tengas y que no puedas solucionar tú.

Nuestra experiencia, tanto en EV1 primero como en The Planet después, es inmejorable. Rápida respuesta a los pocos problemas que nos han dado, avisos con semanas de antelación de ventanas de actuaciones, soporte rápido y eficaz, etc. Cuando hemos tenido algún problema más grave han hecho las cosas con profesionalidad y siempre preguntando primero, reinicios manuales, fsck’s controlados, cambios de cables de discos defectuosos que estaban provocando problemas, etc. En una ocasión incluso se hizo el cambio de un disco defectuoso con dos parones de unos 5 minutos cada uno, el disco no había dejado de funcionar, simplemente lanzaba errores esporádicos de lectura/escritura. En una parada añadieron un disco duro para que lo preparásemos todo y en la siguiente reemplazaron el original por la copia. Todo funcionó a la perfección y en 24h se cambió un discon sin afectar al servicio. Reconozco que también puede ser que hayamos tenido algo de suerte 🙂 .

Profundizando un poco más en el asunto, el incendio de The Planet es sólo uno de los problemas que pueden ocurrir y ante los que apenas hay opciones de protección. Recordemos casos como el del Edificio Windsor de Madrid donde había ni más ni menos que un CPD de Colt Telecom, o las inundaciones en Louisiana tras el Katrina donde todo quedó arrasado y devastado. Nadie ni nada puede asegurar que sus servidores estarán seguros 100% y que nunca ocurrirá nada. Por contra, tú si que puedes asegurar que estarás protegido ante estas situaciones y así poder minimizar los efectos. En función del presupuesto de que dispongas podrás estar mejor o peor preparado, pero lo básico es muy barato y sencillo.

Si tu presupuesto lo permite, lo mejor es, sin duda, tener siempre un CPD de respaldo con toda tu infraestructura de producción duplicada, actualizada y preparada para entrar en producción cuando la principal se venga abajo. Obviamente esto es un gasto que casi nadie va a ser capaz de justificar ante sus superiores.

Si, como la mayoría, no puedes permitirte un CPD de respaldo, mantén una buena política de copias de seguridad y un plan de contingencia bien documentado y actualizado. Si lo haces bien, en apenas unas horas podrás tener levantado desde cero una máquina que haya fallado. NO, repito, NO confíes en los RAID1 (espejo) y ve con cautela con los RAID5, he visto muchos servidores completamente perdidos por culpa de la controladora RAID. ¿De qué sirve tener un RAID1 bien chulo si al petar la controladora se van los dos discos a paseo? A la hora de hacer tus backups ten en cuenta que no sólo necesitas los datos propiamente dichos, sé previsor y guarda todos los archivos de configuración y scripts que te has ido haciendo con los años y que sigues utilizando. Documenta en el plan de contingencia cada detalle que estimes oportuno para restaurar el servicio. Apunta cada cambio que haces en la configuración de cada servicio. ¿De qué te va a servir tener todos tus datos si no has guardado la configuración de Apache y ahora tienes que crear uno a uno todos los Virtual Hosts?

Finalmente, aunque parece evidente, llegado el momento muchos se olvidan. Distribuye tus copias de seguridad. NO tengas el backup en el mismo CPD y mucho menos en la misma máquina. A ser posible almacena los backups en varios sitios. A mi me gusta hacerlo en otro CPD bien alejado del de producción y en tus oficinas.

Como último consejo, pon en marcha el plan de contingencia al menos una vez al año. Coge una máquina limpia, tu plan de contingencia y mide el tiempo que tardas en tenerlo todo online y revisa los problemas que te van surgiendo. Alimenta con esta experiencia tu plan de contingencia para hacer frente a posibles imprevistos llegado el momento.

Eso es todo amigos, ojalá nunca tengáis que poner en práctica el plan de contingencia 😛 .

Urchin vs. Analytics, la batalla se libra en casa

General, Negocios, Proyectos, Sistemas, Técnico, , , , ,

Webalizer (con su excelente fork continuado awffull) y awstats han tenido históricamente fama de contar visitas y páginas de más, sobre todo desde que Google abrió al público su Analytics y ya nada volvió a ser lo mismo. Hace años tuvimos alguno de nuestros proyectos auditado por OJD y la diferencia con webalizer era mínima, sin embargo las distancias con Analytics son abismales.

Analitycs surge de la compra de Urchin por parte de Google en 2005, otro clásico del software para estadísticas web. Analytics se lanzó primero en beta muy cerrada y bastante después la abrieron completamente al público. Desde el primer día todos nos hemos dado cuenta de las enormes diferencias de datos que había entre lo que contaban nuestros analizadores de logs y lo que contaba Analytics.

Recientemente necesitaba valorar las estadísticas de acceso a distintos proyectos móviles y la única herramienta de la que disponía era el querido webalizer, pero ¡cómo fiase de sus datos!. Analytics no es una opción en este entorno ya que la inmensa mayoría de terminales no soportan Javascript, con lo cual no va a funcionar la contabilización de páginas. Se me ocurrió entonces probar Urchin Software, la última versión del software comprado por Google y que ellos mismos distribuyen y en el que, se supone, se basa Analytics. Aunque el precio de la licencia sea posiblemente prohibitivo para la mayoría, tenemos una versión de prueba de 3 meses, así que dicho y hecho, la descargamos la instalamos y comenzamos a monitorizar nuestros sites móviles. La sorpresa fue mayúscula al cabo de un par de días cuando comprobamos que el resultado es prácticamente el mismo que con webalizer. No nos lo podíamos creer, así que decidimos monitorizar sites también controlados por Analytics para comparar, comenzando por el blog Restaurantes en Madrid. Al cabo de unos días volvimos para comparar el resultado y nos sorprendimos de nuevo. Resultados semejantes a webalizer y completamente distantes de Analytics. Pero ahora la diferencia era enorme, estamos hablando del doble con creces de visitas y páginas que nos muestra Urchin respecto a Analytics.

Urchin (o webalizer, o awstats) se basa en el análisis de logs de acceso del servidor web, mientras que Analytics lo hace a través de Javascript. No cabe duda alguna de que el primer método ha de ser, por fuerza, mucho más creíble y eficaz ya que se basa en peticiones HTTP recibidas de verdad, mientras que el segundo método confía en que el cliente tenga Javascript. Pero ¿qué ocurre con clientes sin Javascript?, más aún, ¿qué pasa con los accesos a feeds?, ¿son visitas no contabilizadas y perdidas? Pues sí. Osea, la herramienta de estadísticas web por excelencia está contabilizando, al menos, un 20% (según he leído en algún sitio) de tráfico menos de lo que en realidad tienes y aún así se ha convertido en el estandar, no lo puedo entender. ¿Los que te leen por RSS no son visitantes también? Se ve que no… La única razón que se argumenta en favor de Analytics es que así no cuenta tráfico proveniente de los robots de los buscadores, pero no dicen nada de los efectos colaterales.

Las críticas que se puedan aplicar a webalizer o a awstats son exactamente las mismas que puedes echar sobre Urchin, con la diferencia de que este último cuesta la nada desdeñable cifra de 3.000 euros. Sin embargo te habrás gastado este dineral para obtener unas cifras nada parecidas a Analytics. Cuando vayas a vender tus espacios publicitarios qué datos vas a enseñar, los de Urchin o los de Analytics, o mejor aún, cuales te van a pedir tus anunciantes?.

Monitorizando servidores con Cacti

Negocios, Proyectos, Sistemas, , , , ,

A nadie le cabe duda hoy por hoy que una de las tareas más importantes y necesarias en el trabajo de los departamentos de sistemas es la monitorización, tanto de máquinas como de servicios.

Hoy en día está de moda Nagios, no es la primera oferta de trabajo que veo donde buscan desarrolladores de plugins para Nagios. Antes fue Big Brother, todo un clásico de la monitorización. Ámbas son muy semejantes y su funcionalidad es parecida, la diferencia está en que Nagios es Open Source y Big Brother es comercial. En general, su utilidad es comprobar la disponibilidad de servicios en los servidores (http, pop, smtp…). Si en un periodo de tiempo determinado no hay acceso a un determinado servicio (es decir, se ha intentado varias veces sin éxito), se lanza una alerta puesto que se supone que puede haberse caído. Las alertas son ampliamente configurables, se pueden crear grupos de usuarios que la recibirán y pueden ser de distinto tipo (email, pager, sms…). Como herramienta de alertas es perfecta, sin embargo, como herramienta de monitorización se limita a ser un almacén de semáforos, mientras todos están en verde, no hay problemas, cuando uno se pone en rojo, salta a alarma. Así de sencillo. Sin embargo no nos responde a algunas de las preguntas más interesantes:

  • ¿Por qué se ha caído el servicio?
  • ¿Qué estaba ocurriendo en la máquina cuando se cayó?
  • ¿Qué otros servicios de esa máquina podrían estar influyendo en el problema?

Nos informa de la disponibilidad pero no de las posibles causas.

Cacti responde a esas cuestiones de un modo muy eficaz. Cacti es otro concepto de monitorización. Si conoces MRTG sabes de lo que hablamos. Cacti también se base en rrdtool para generar gráficos de actividad periódica. El día que tenga ganas jugaremos con rrdtool puesto que es una experiencia interesantísima, aunque hace ya tres o cuatro años que no lo toco.

Veamos un ejemplo para ir entendiendo sus ventajas. Aquí tenemos una gráfica de uso de CPU con bastante detalle.

Gráfico de actividad con 1 CPU

Alguno dirá, bueno, está bien, pero con mrtg hago cosas parecidas. Vale, veamos el segundo ejemplo, ahora con dos CPU’s, gráficas independientes y combinada.

2cpu.jpg

Vale tío, pero no me has enseñado nada nuevo, se puede hacer con otras herramientas algo parecido. Seguro, pero no con la facilidad de Cacti. Pero mira lo que te voy a enseñar ahora:

Monitorización de servicios con Cacti

No se vayan todavía, aún hay más…

Monitorización de servicios con Cacti 2

Si a estas alturas no estás sorprendido creo que no deberías seguir leyendo :P.

Como veis, podemos llegar a tener gran cantidad de información de cada uno de los servicios que tenemos corriendo en el servidor, no sólo tráfico de red o actividad de CPU. Ahora podemos responder a muchas más preguntas en caso de error:

  • ¿Qué actividad de Apache había?
  • ¿Y de MySQL?
  • ¿Cómo íbamos de tráfico de correo?
  • ¿Y de DNS? A ver si vamos a estar teniendo un DoS a través del DNS…

Más aún…

  • ¿Será un fallo hardware por la temperatura o los ventiladores de la máquina?
  • ¿Falta de espacio en disco?
  • ¿Nos hemos quedado sin memoria?
  • Por curiosidad… ¿como vá el SAI de nuestra máquina?

Con un sólo vistazo a las gráficas respondes a todas las preguntas de golpe.

¿Qué servicio está provocando el incremento de CPU? No hay más que revisar las gráficas de actividad de los principales servicios y ver cual tiene una actividad por encima de lo normal.

Conocí Cacti hará unos cuatro años y desde entonces no puedo vivir sin el. Pero Cacti es mucho más que eso. Llegados a este punto, pensarás:

Si tenemos comprobaciones periódicas de los servicios, ¿por qué no ofrecer una funcionalidad semejante a Nagios en cuanto a disponibilidad?

Voila, parece que alguien ya lo había pensado antes y tenemos un plugin para Cacti que nos ofrece los famosos semáforos verde/rojo.

Semáforos en Cacti

Bueno vale, pero ¿qué pasa con las alertas?. Sencillo, tenemos otro plugin para lanzar alertas al más puro estilo Nagios.

Según mi experiencia, la combinación Cacti/Nagios roza la perfección y se complementan entre ellos.

Hay cientos de plugins para comprobar y registrar servicios desde Cacti, prácticamente todos los servicios conocidos tienen algún plugin, y, si no encuentras lo que necesitas, siempre puedes hacértelo tú mismo. Puedes incluso crear un pequeño script en tu servidor que genere los datos que necesites y configurar un trap snmp que los lea y los devuelva a una llamada remota, de esta forma integras a la perfección tus registros personalizados con un estándar como es snmp con el que Cacti se comunica a la perfección.

Si aún no monitorizas tus servidores… tarde o temprano vas a pasarlo mal :).