Lo primero que hay que saber antes de actualizar un Asterisk es si la versión a la que vamos a actualizar es la más conveniente. Partiremos de la base de que cuanto más avanzada sea una versión, más estable será.
Siempre hemos sido de la opinión que cuando un sistema funciona, no debemos cambiarla a menos que:
– Exista un fallo de seguridad que esté solucionado en la siguiente versión.
– Necesitemos alguna característica que no venga incluida en la versión actual.
Para aquellos que trabajan con Asterisk 1.4 la actualización debería ser siempre a la última disponible (cierto que han existido algunas versiones un poco ‘verdes’ -de la 1.4.23 a la 1.4.26- pero parece ser que cualquier otra versión superior se considerará suficientemente estable para un sistema en producción.
Para aquellos que trabajan con Asterisk 1.6.0 la actualización debe seguir dentro de la misma rama (en un sistema en producción, nunca saltar a la 1.6.1 hasta que se considere estable).
Si realmente estais interesados en actualizar Asterisk por algún motivo, vamos a ver qué tenemos que tener en cuenta y cómo podemos hacerlo.
Lo primero, recordad hacer un backup de los directorios importantes:
/etc/asterisk/
/var/lib/asterisk/
/var/spool/asterisk/
Un comando útil para esto es:
tar cvfj asterisk-backup-`date +%Y%m%d-%H%M%S`.tgz /etc/asterisk /var/lib/asterisk /var/spool/asterisk
De esta forma, tendreis un archivo comprimido con todos los archivos de los directorios más importantes de Asterisk.
Desmintiendo mitos
El kit completo formado por Zaptel o DAHDI, LibPRI, Asterisk, Asterisk-Addons e incluso Asterisk-sounds son paquetes independientes, por lo que siempre podremos actualizar Zaptel sin necesidad de actualizar Asterisk, o actualizar LibPRI sin necesidad de actualizar Asterisk.
Eso sí, en el caso de actualizar LibPRI es necesario, como mínimo, recompilar Asterisk (ya que hace uso de estas librerías para generar el chan_zap o chan_dahdi, pero no es necesario actualizar Asterisk.
Actualizando dentro de la misma rama
El kit de la actualización dentro de la misma rama, es que todas las aplicaciones continuan existiendo (no han sido modificadas ni quedado obsoletas por nuevas), por lo que todo nuestro dialplan y nuestros archivos de configuración seguirán funcionando sin ningún problema.
Lo único que tenemos que tener en cuenta a la hora de actualizar dentro de la misma rama (es decir, de Asterisk 1.2.10 a 1.2.37, o bien de la 1.4.20 a la 1.4.27) es que dentro del proceso de compilación, no ejecutar el comando ‘make samples‘ ya que sobreescribirá nuestros archivos de configuración que tanto nos ha costado preparar:
./configure
make menuconfig
make
make install
make samples <<< ESTE NO!!!
Por lo tanto, si sólo ejecutamos esos 4 comandos y entramos en Asterisk, veremos que seguimos con la misma versión y funcionando sin problemas, ya que hasta que no reiniciemos Asterisk y cargue los nuevos módulos no se aplicarán los cambios de la actualización.
Actualizando de una rama a otra más nueva
Este es el caso más interesante, ya que junto con el cambio de rama, han aparecido nuevas aplicaciones, han desaparecido otras e incluso puede que hayan cambiado los parámetros de otras tarntas, así que en este caso hay que conocer bien los cambios de cada versión si no queremos llevarnos una desagradable sorpresa.
Por ejemplo, para pasar de Asterisk 1.2 a Asterisk 1.4 existen cambios como la utilización de una función llamada CALLERIDNUM() que devuelve el número de la persona que origina la llamada, y que en Asterisk 1.4 pasa a llamarse CALLERID(num). Las bases de datos de Asterisk (DBPUT, DBGET,…) de Asterisk 1.2, han sido reemplazadas por la función DB(), y muchos más cambios de aplicaciones, además de cambios en los archivos de configuración (musiconhold.conf, queues.conf, etc…)
Lo mismo ocurre si trabajamos en Asterisk 1.4 y queremos dar el salto a Asterisk 1.6. Son muchas las aplicaciones que no existen y que han sido sustituidas por otras, a la vez que han aparecido nuevos parámetros en los archivos de configuración que debemos tener en cuenta si queremos que nuestro sistema funcione correctamente.
Por este mismo motivo, el salto de una rama a otra hay que hacerlo con especial cuidado si queremos preservar el comportamiento del sistema antiguo. Aunque hay quien opta por (quizá lo más recomendable para sistemas sencillos) dar el salto y empezar a configurar de cero con la nueva versión.
Si ya es complicado saltar de una rama 1.2 a una 1.4, o de 1.4 a una 1.6, imaginaos cuán complicado puede llegar a ser saltar de 1.0 a 1.4 o de 1.2 a 1.6, es por este motivo por lo que debeis conocer muy bien cómo funciona la versión nueva a la que quereis actualizar. Instalarla en otro sistema, duplicar la configuración y hacer los cambios comprobando que todo funciona correctamente y una vez que tengais una configuración adaptada a la nueva versión, entonces llega el momento de actualizar, teniendo a mano la nueva configuración que según vuestras pruebas funciona correctamente.
Una vez dicho esto, y considerando que no me hago responsable de los daños que pueda ocasionar una mala actualización, tan solo decir que si teneis dudas sobre si podeis o no, entonces mejor, consultar con algún dCap o algún profesional de vuestra confianza para que esteis tranquilos y seguros de que la migración se hará sin problemas.