Cómo verificar tu Asterisk para una instalación en producción
Poco más de un año han tardado los desarrolladores en hacer realidad una petición bastante interesante que hicieran nuestros compañeros Jon Bonilla y Saúl Ibarra cuando, cansados de que cada nueva versión de Asterisk 1.4 que añadía una nueva característica, volvían a aparecer antiguos bugs que ya habían sido solucionado, las conocidas «regresiones» que aparecían en 1.4 y más intensamente en 1.6.
El objetivo principal del debate era una crítica constructiva sobre el futuro del desarrollo de Asterisk y más concretamente la forma de publicación de versiones que defendía Russell Bryant de forma que varias ramas estuviesen en producción de forma simultaneamente como lo está haciendo la versión de Asterisk 1.6, así podemos ver Asterisk 1.6.0.26, 1.6.1.18 y 1.6.2.6 como versiones supuestamente estables.
Finalmente se optó para la rama 1.8 como versión LTS (Long Term Support) quedando como única rama lo que hará que «en teoría» pasará a ser mucho más estable, pero mientras tanto, se siguió pensando en nuevos mecanismos que permitieran obtener versiones de Asterisk mucho más estables para entornos en producción.
Tras esta discusión en la que participaron muchos desarrolladores explicando el porqué de la política de versiones que sigue Asterisk 1.6, y que era necesario algún cambio para evitar esas «regresiones» en futuras versiones, decidieron crear una API especial para que el sistema se testeara de forma automática para verificar que todas las características que funcionan en una versión, sigan funcionando en la siguiente.
Poco más de un año ocurrió desde el primer mensaje, y se ve que han estado trabajando en ello porque ayer Leif Madsen ha publicado en el blog de Asterisk un ejemplo práctico sobre cómo ejecutar esos auto-tests para verificar que las características / servicios de las nuevas versiones sigan funcionando, así que ni cortos ni perezosos nos hemos puesto a probarlo nosotros mismos y verificar que realmente funciona como dice…
Para comprobar una versión estandar, Leif ha escogido la versión 1.6.2 y ha instalado todas las dependencias que hacen falta para ejecutar este sistema de auto-verificación:
apt-get install libxml2-dev build-essential subversion libncurses5-dev python-yaml apt-get install lua5.1 liblua5.1-0-dev libpcap-dev libpcap0.8-dev gcc g++ libxml2-dev; Instalamos el starpy cd /usr/src/ wget "http://downloads.sourceforge.net/project/starpy/starpy/ 1.0.0a13/starpy-1.0.0a13.tar.gz?use_mirror=kent" tar xvfz starpy-1.0.0a13.tar.gz cd starpy-1.0.0a13 python setup.py install; Instalamos el sipp cd /usr/src wget http://sipp.sourceforge.net/snapshots/sipp.2009-07-29.tar.gz tar zxvf sipp.2009-07-29.tar.gz cd sipp.svn make pcapplay cp sipp /usr/bin/
; Instalamos Asterisk utilizando subversion pero la rama "estable" 1.6.2 cd /usr/src mkdir asterisk-complete cd asterisk-complete mkdir asterisk cd asterisk svn co http://svn.asterisk.org/svn/asterisk/branches/1.6.2 1.6.2-vanilla cd 1.6.2-vanilla svn co http://svn.asterisk.org/svn/testsuite/asterisk/trunk testsuite ./configure make && make install ; Esto no será necesario, pero por si acaso hace falta... if [ ! -e /etc/asterisk ]; then make samples; fi
Esto debería ejecutarse correctamente y sin darnos ningún error.
En el caso en que nos dé algún error de que nos falta alguna librería, necesitaremos instalarla y volver a ejecutar el ./configure
Continuaremos en el directorio testsuite:
cd testsuite cd asttest make && make install cd .. ./runtests.py
Una vez ejecutado esta aplicación python, podremos irnos a tomar un café mientras el sistema empieza con sus tests con las herramientas que hemos instalado y que utilizará para hacer toda clase de pruebas.
Cuando volvamos unos minutos después (depende de la velocidad de nuestro sistema), y si todas las dependencias han sido instaladas correctamente y no hay mensajes que indiquen lo contrario, deberíamos ver el resultado de las pruebas una a una.
Leif comenta que el test completo debe tardar poco más de unos 2 minutos, aunque unos mensajes de timeout en la conexión con el AMI nos relentiza la salida además que nos devuelve unos mensajes extraños:
... Installing Asterisk … Installing sample configuration … Running ['tests/cdr/console_fork_after_busy_forward/run-test', '-v', \ 'SVN-branch-1.6.2-r260441'] … AMI Login attempt #1 AMI Login attempt #2 AMI Login attempt #3 AMI Login attempt #4 AMI Login attempt #5 AMI login failed after 20 second timeout ??????? –> Running test ‘cdr/console_fork_before_dial’ ...
Aunque estos mensajes salen por unos motivos desconocidos, el resto de pruebas deben salir satisfactorias y deben aparecer con el mensaje: test passed. No obstante la salida es tan larga que no tiene sentido ponerla entera aquí, así que pondré algún trozo según lo que me ha ido saliendo:
--> Running test 'manager-action-events-response' ... Uninstalling Asterisk ... Installing Asterisk ... Installing sample configuration ... Running ['tests/manager-action-events-response/run-test', '-v', \ 'SVN-branch-1.6.2-r260441'] ... testing with brokeneventsaction off (default) sending 'EventMask: ' sending 'EventMask: ON' sending 'EventMask: yes' sending 'EventMask: all' sending 'EventMask: all,user' sending 'EventMask: system,user,agent' sending 'EventMask: off' sending 'EventMask: none' sending 'EventMask: yeah whatever' sending 'EventMask: 1' testing with brokeneventsaction on sending 'EventMask: ' sending 'EventMask: ON' sending 'EventMask: yes' sending 'EventMask: all' sending 'EventMask: all,user' sending 'EventMask: system,user,agent' sending 'EventMask: off' sending 'EventMask: none' sending 'EventMask: yeah whatever' sending 'EventMask: 1' test passed
Cada vez que se ejecuta un test diferente, el sistema borra toda la configuración y la vuelve a crear con los parámetros que le hace falta, por lo que es interesante tener a buen recaudo la configuración original que hayamos hecho o nos quedaremos sin ella.
Así que, esto va tomando forma ¿o no?
Basado en el artículo de Leif Madsen en Digium
