monitorizando tu bes

1 de agosto de 2010

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

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

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

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

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

certificados caducados en openvpn

27 de junio de 2010

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

#/bin/bash

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

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

}

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

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

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

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


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

25 de junio de 2010

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

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

Veamos como lo lanzamos en modo servidor desde A:

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

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

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

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

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

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

tomando temperatura al cpd

23 de junio de 2010

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

una vez conocí a richard stallman

22 de junio de 2010

Libertad 0: Es “libertad” para ejecutar el programa con cualquier propósito.
Libertad 1: Es “libertad” para estudiar y modificar el programa.
Libertad 2: Es “libertad” de copiar el programa y ayudar con él a tu vecino.
Libertad 3: Es “libertad” de mejorar el programa, y hacer públicas tus mejoras, de forma que se beneficie toda la comunidad.

navegación autenticada con Squid

7 de junio de 2010

El siguiente post muestra un ejemplo de cómo permitir que alguien pueda navegar por Internet solo si se ha autenticado. Es un ejemplo real donde todos los usuarios reciben una IP por DHCP (192.168.1.0/24) y los usuarios "invitados" reciben por DHCP una IP de un rango concreto (192.168.10.0/24).

Dado que todos los usuarios acceden a Internet vía Squid utilizaremos las opciones de autentificación (auth_parm) para logear a los usuarios. Primero de todo creamos un archivo con los usuarios y passwords de los invitados:

# touch /etc/squid/squid.users
# htpasswd /etc/squid/squid.users invitado1
# htpasswd /etc/squid/squid.users invitado2
...

Ahora editamos el archivo de configuración de Squid y configuramos los parámetros auth_parm:
auth_param basic children 3
auth_param basic realm Acceso a Internet restringido. Introduzca su usaurio y 
   contraseña...
auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/squid.users
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive off

Esta es la descripción de los parámetros anteriores:

+ auth_parm basic children: numero de procesos/daemons que realizaran la autentificación. Dependerá un poco del número total de usuarios que puedan acceder a Internet en un momento dado.
+ auth_parm basic real: es el mensaje que saldrá en la ventana de login de tú navegado.
+ auth_parm basic program: definimos el sistema de autentificación y dónde debe buscar los usuarios. + auth_parm basic credentialsttl: especifica el tiempo que estará validado el usuario antes de volverle a pedirle el login.
+ auth_parm basic casesensitive: define si el nombre de usuario es case-sensitive.

Creamos ahora la ACL para decirle sobre que rango debe Squid pedir un login:
acl ip_invitados src 192.168.10.0/24
acl ip_lan src 192.168.1.0/24
acl auth_invitados proxy_auth REQUIRED
...
http_access allow ip_invitados auth_invitados
http_access allow ip_lan
http_access deny all

Básicamente lo que se necesita son dos listas de accesos. Una para definir las IPs que queremos logear (ip_invitados) y otra para definir el requisito de una autentificación (auth_invitados).

Existen varios métodos de autentificación cómo Basic, Digest, NTLM, Negotiate, cada uno de ellos pudiendo atacar contra un backend diferente: LDAP, MySQL, Radius, Active Direcotory, etc. Aquí hay algunos ejemplo con diferentes configuraciones.

wavecom wmod2a (parte ii de ii)

23 de mayo de 2010

Una vez tenemos las tools de Gammu funcionando es hora de montar nuestro gateway. El gateway tendrá un daemon que escuchará el módem y meterá los SMS en una BBDD. Para enviar utilizaremos el comando gammu tal como hemos visto en la primera parte del post.

Para facilitar las cosas utiizaremos una pagina Web escrita en PHP.

Instalamos Apache+MySQL+PHP:

# apt-get install apache2 php5 libapache2-mod-php5 
# apt-get install libapache2-mod-auth-mysql php5-mysql mysql-server mysql-client
# apt-get install libmysqlclient15-dev

Los mensajes SMS recibidos al módem SMS irán almacenados en una BBDD MySQL, para ello tendremos que crear un schema con las tablas necesarias para añadir esta info. Dentro de /usr/share/doc/gammu/examples/sql/mysql.sql.gz econtraremos un schema de tablas que podemos utilizar:
# cp /usr/share/doc/gammu/examples/sql/mysql.sql.gz /tmp
# gunzip /tmp/mysql.sql.gz
# mysqladmin -u root -p create sms
# mysql -u root -p sms < /tmp/mysql.sql

Ahora le decimos al Gammu que los mensajes recibidos los guarde en las tablas de MySQL. Para ello editamos la configuración y añadimos estos parámetros a los ya existentes:
# cat /etc/gammurc
...
[smsd]
#service = files
service = MYSQL
logfile = syslog
CheckSecurity = 0
debuglevel = 1
user = root
password = 12345
pc = localhost
database = sms
inboxpath = /var/spool/gammu/inbox/
outboxpath = /var/spool/gammu/outbox/
sentsmspath = /var/spool/gammu/sent/
errorsmspath = /var/spool/gammu/error/

Nota: Podemos utilizar diferentes tipos de backends. En la configuración anterior se puede utilizar MySQL o directamente ficheros planos alojados en /var/spool/gammu.

Para facilitar la lectura de estas tablas MySQL, hay creada una interfaz PHP que nos ayuda a leer los mensajes recibidos:
# cd /var/www
# wget http://www.syednetworks.com/gammu-sms-gateway.zip
# unzip gammu-sms-gateway.zip

Ahora podemos acceder a esta interfaz desde http://127.0.0.1/gammu-sms-gateway/sms.php. Para que el script sms.php acceda a vuestro MySQL deberéis cambiar la password de acceso a la base de datos por la que tengáis puesta:

Para ello editar el sms.php y cambiamos esta linea:
mysql_connect("localhost", "root", "") or die(mysql_error());

Instalamos y arrancamos el daemon que esperará la llegada de los SMSs:
# apt-get install gammu-smsd
# gammu-smsd -c /etc/gammurc &

Si enviamos un SMS a nuestro módem GSM y vamos mirando el log podremos ir viendo como van entrando los mensajes y cómo se van actualizado las tablas:
# tail -f /var/log/syslog
gammu-smsd[5813]: gammu: 3 "OK"
gammu-smsd[5813]: gammu: RECEIVED frametype 0x00/length 0x1B/27
gammu-smsd[5813]: gammu: 41A|54T|2B+|43C|53S|51Q|0D |0D |0A |2B+|43C|53S|51Q|
   3A:|20 |311 AT+CSQ...+CSQ: 1
gammu-smsd[5813]: gammu: 377|2C,|300|0D |0A |0D |0A |4FO|4BK|0D |0A 
   7,0....OK..     
gammu-smsd[5813]: gammu: Signal quality info received
gammu-smsd[5813]: gammu: Parsing +CSQ: 17,0 with +CSQ: @i, @i
gammu-smsd[5813]: gammu: Parsed int 17
gammu-smsd[5813]: gammu: Parsed int 0
gammu-smsd[5813]: gammu: Leaving GSM_GetSignalQuality
gammu-smsd[5813]: Execute SQL: UPDATE `phones` SET `TimeOut`= (NOW() + 
   INTERVAL 10 SECOND)+0, `Battery`= 0, `Signal`= 51 WHERE `IMEI` = 
   '330122330387360'

Por ultimo queda la parte del envío de SMS. Para ello, desde la pagina sms.php encontraremos un link llamado "Send SMS message" que nos permitirá enviar un SMS desde un formulario Web. Este link llama al archivo send-sms.php. Si lo editamos podremos ver como lo único que realiza es una llamada al binario de gammu:
system( 'sudo /usr/bin/gammu --sendsms EMS ' . escapeshellarg( $destination ) . 
' -text ' . escapeshellarg( $message ) );

Es posible que el path de nuestro binario gammu no corresponda con el de la pagina. Tendremos que cambiar /usr/logal/bin/gammu por /usr/bin/gammu.
Notar que también he añadido la ejecución del comando bajo sudo. Esto es debido a que el usuario que hace la llamada a la función system() es www-data y este usuario no tiene permisos para ejecutar comandos como gammu.

Para que el sudo no pregunte password tenemos que editar el /etc/sudoers y añadir esto:
# cat /etc/sudoers
...
%sudo ALL=NOPASSWD: ALL

Es posible que no tengáis permisos para escribir sobre el fichero de sudoers. Hay que poner permisos de escritura y luego dejarlos como estaba.

Finalmente tenemos que decirle quienes son los usuarios que están dentro de sudoers. Para ello editamos el /etc/groups y modificamos el grupo sudo:
# cat /etc/group | grep sudo
sudo:x:27:usuario1,www-data


wavecom wmod2a (parte i de ii)

22 de mayo de 2010

Vamos a montar un gateway para enviar y recibir mensajes SMS. La idea es montar este servicio para poder utilizarlo en Nagios y así poder enviar alertas vía SMS.

En verdad se puede realizar con cualquier teléfono móvil, pero esta vez utilizaré un hardware dedicado y especifico para ello un módem GSM Wavecom modelo wmod2a-g900.

El módem se comunicará con el servidor vía interfaz serie, pero como ya no quedan servidores con puerto de serie utilizaré un conversor USB-to-serial. Por tanto lo primero es ver que se detecta correctamente el conversor:

# dmesg | grep USB
[   77.187320] USB Serial support registered for generic
[   77.187348] usbserial: USB Serial Driver core
[   77.196733] USB Serial support registered for pl2303
[   77.208730] usb 6-2: pl2303 converter now attached to ttyUSB0
[   77.208746] pl2303: Prolific PL2303 USB to serial adaptor driver

Ahora instalaremos el soft básico para acceder al módem. Como todo modem, podríamos acceder a el vía comandos AT, pero tendríamos que leernos la documentación del dispositivo. Utilizaremos las herramientas gratuitas de Gammu:
# apt-get install gammu

Encontraremos un archivo de configuración de ejemplo en /usr/share/doc/gammu/examples/config/gammurc.gz. Nosotros crearemos uno con estos parámetros:
# cat /etc/gammurc
[gammu]
port = /dev/ttyUSB0
connection = at19200
name = wavecom
logformat = textall
logfile = gammu.log
startinfo = yes
use_locking = yes
gammuloc = locfile

Cómo puede verse el dispositivo /dev/ttyUSB0 indica la interfaz donde está conectada el módem GSM.

Una vez encendido el módem veamos si las tools de Gammu son capaces de reconocer el modem. Yo recomiendo quitarle el PIN a la tarjeta SIM para evitar problemas. De esta forma cada ver que reiniciemos el módem este estará listo para enviar SMS:
# gammu -c /etc/gammurc identify
Manufacturer         : Wavecom
Model                : unknown (900P)
Firmware             : 320_G250.53 833584 092499 18:13
IMEI                 : 330142330387360
SIM IMSI             : 214071617085412

Enviemos ahora nuestro primer SMS a otro teléfono y veamos que efectivamente está funcionando:
# echo hola | gammu -c /etc/gammurc sendsms TEXT 6938888888
If you want break, press Ctrl+C...
Sending SMS 1/1....waiting for network answer..OK, message reference=115

Más información:
+ Wavecom AT Commands Guide

montando servidores para pequeñas oficinas

18 de abril de 2010

Tenemos una pequeña oficina en Portugal donde varios de sus usuarios se conectan remotamente vía cliente software de VPN. Ahora que van a mejorar sus comunicaciones (creo que se ponen una linea de simétrica de más de 2Mb) es hora de enviarles un router que genere las VPNs y que los clientes no tengan que hacer nada para acceder a la central que está en España.

Dado que utilizamos Linux y OpenVPN para conectar esta oficina y los usuarios que viajan enviaremos un servidor que genere estas VPNs. La idea es montarles el servidor de OpenVPN en el dispositivo más pequeño que encontremos, enviarlo por correo, que se lo pinchen a la red y listo...

Pues bien, después de mucho buscar he encontrado esta maravilla llamada ARTIGO: placa pico-ITX, CPU VIA, 1 Ethernet, 4 USB y un video. Lo mínimo para montar un router con Linux. Viene todo desmontado como si fuera puzzle para que lo disfrutes montándolo. Sólo tienes que ponerle la memoria DDR que quieras y el disco IDE o SATA que quieras. Yo he optado por un disco solido. Al realizar funciones de router no quiero partes moviles que puendan romperse con el paso del tiempo.
Aquí tenéis un proveedor oficial en españa: http://www.ibertronica.es/artigo.htm.

Por lo que he leido también tiene un kit para añadirle una antena Wifi.


Para quién le guste el mundo de los mini PCs o busque otros modelos para montarse un barebone aquí tiene esta página: http://www.mini-itx.com/

coordinar un cambio de MX

11 de abril de 2010

Esta semana hemos migrado las cuentas de correo de un servidor Postfix en Linux a un servidor Lotus Domino en AIX en una maquina física diferente y en otro centro diferente. Entre todas las cosas que hay que coordinar en esta migración una de ellas es el cambio de los registros MX para que dejen de apuntar a la maquina Postfix y apunten a la nueva maquina Domino.

Dependiendo de la forma de trabajar de cada departamento de IT nosotros hacemos estos cambios un viernes por la tarde de forma que sí algo falla tenemos el fin de semana para arreglar el estropicio y que todo funcione el Lunes… aunque esto depende de cada uno.

Durante un cambio en los servidores, una cosa muy importante que tenemos que controlar es el DNS y en especial los registros MX y TXT. Todos los dominios dados de alta en un DNS tienen un campo asignado donde se indica el TTL (tiempo-de-vida) de los registros.
Este valor en muy importante durante una migración ya que indica el tiempo de caducidad de los registros de nuestro dominio. Por ejemplo, si ponemos un TTL de tres dias y realizamos un cambio en los registros MX , eso querrá decir que el resto del mundo no se enterará que hemos cambiado de MX hasta tres días después. Hasta que no pasen tres dias no volverán a consultar los registros de este dominio.

Aquí tenemos un ejemplo de registro de dominio donde se especifica tres dias de TTL:

$TTL 3D
@               IN      SOA     land-5.com. root.land-5.com. (
                                199609206       ; Serial
                                28800   ; Refresh
                                7200    ; Retry
                                604800  ; Expire
                                86400)  ; Minimum TTL
                        NS      land-5.com.
                        NS      ns2.psi.net.


Por tanto, tres días antes de hacer la migración es aconsejable cambiar este TTL por ejemplo a 5 minitos. El campo TTL se indica en segundos desde 0 a 214748364 (64 años). El 0 indica a los DNS que no cacheen los registros.

Pondríamos un:
$TTL 300

Una vez llegado el día de la migración podemos cambiar los registros MX (o cualquier otro registro) con tranquilidad, sabiendo que nuestro cambio estará disponible a nivel mundial cada 5 minutos. Una vez hecha la migración y hayamos comprobado que ya recibimos correo desde el exterior a nuestro nuevo servidor, podemos volver a dejar el valor por defecto del TTL de nuestro DNS. Cómo reglar general el campo TTL lo utilizan los daemons de DNS para controlar la caducidad pero esto depende mucho de la implementación y la configuración no-estándar que sigan el resto de servidores de DNS.
Para ir comprobando si ya hemos propagado este cambio al resto de DNS podemos utilizar herramientas externas como www.mxtoolbox.com.

Otro de los registros que debemos modificar durante la migración del correo y que siempre se olvida es el registro TXT para aquellos que tengamos o deseemos activar el SPF (Sender Police Framework). Recordar que los registros MX indican las maquinas aceptadas para recibir el correo de un dominio y SPF indica las maquinas aceptadas para el envío de correo de ese dominio. SPF se inventó para combatir el problema del Spam. Cómo históricamente no existía ningún registro SPF en el DNS se optó por utilizar el registro TXT existente que hasta hace poco no servía para nada.

Aquí tenéis un ejemplo del registro TXT:
TXT = "v=spf1 ip4:214.229.188.0/25 ip4:80.34.132.42 mx -all"

Lo que indica esta línea es que las maquinas autorizadas para el envío de correo desde dicho dominio son las maquinas dentro de la red 214.229.188.0/25, la maquina 80.34.132.42, la maquinas especificadas en los MX y ninguna más.