Category Archives: Trabajo - Page 2

Xen 3.3 y Debian Etch

Recientemente me tocó configurar un servidor para tener máquinas virtuales mediante XEN. Anteriormente sólo había trabajado con un poco con VMWare ESXi y XenServer (la versión “comercial” de XEN), el problema es que se tenía que instalar en un servidor remoto que solo se tiene acceso mediante ssh.

Con algo de trabajo y pruebas (y con las buenas herramientas de ServerBeach, que sólo le faltan una vista a la consola para diagnosticar kernel panics) por fin pude instalarlo.

Debian tiene una versión de Xen, pero es la 3.0.3 que para mi gusto es demasiado vieja (se liberó en 2006) y la versión Lenny (testing) tiene la versión 3.2, pero también algo “inestable” a mi gusto para un servidor de batalla.

Como dije después de hacer varias pruebas logré instalar la versión Xen 3.3 utilizando el kernel que viene en Debian preparado para Xen.

Una breve descripción de Xen, es que está separado en varias partes, en primer lugar Xen tiene un kernel modificado para llevar a cabo la virtualización, la ventaja es que la versión 3.3 utiliza la versión 2.6.18 que es la que viene con Debian.

Después la parte “fuerte” de Xen es el denominado hypervisor que es un servidor que se encarga de hacer la virtualización propiamente dicha. Después vienen las máquinas virtuales que utilizan por lo general otro kernel que se denomina domU (y el kernel de la máquina base se denomina dom0).

Pues bien, para lograr esto simplemente primero instalé la imagen del kernel apropiado y compilar solamente el hypervisor de Xen 3.3

En pasos simples:

#Instalar la imagen del kernel con parche para xen
apt-get install linux-image-2.6.18-6-xen-amd64

#Descargar el código fuente de xen
wget http://bits.xensource.com/oss-xen/release/3.3.0/xen-3.3.0.tar.gz
tar zxvf xen-3.3.0.tar.gz
cd xen-3.3.0

#Compilar solamente el hypervisor
make xen
make install-xen

#Compilar los archivos ejecutables como xm y herramientas de red
make tools
make install-tools

#Hacer que Debian cree las entradas correspondientes en los rc.X
#para que cuando el servidor se inicie ejecute los servidores de Xen
update-rc.d xend defaults 20 21
update-rc.d xendomains defaults 21 20

#Hacer que grub reconozca el nuevo kernel con la configuración de Xen 3.3.0
update-grub

Con eso deberían de ver una entrada en el grub como:

title           Xen 3.3.0 / Debian GNU/Linux, kernel 2.6.18-6-xen-amd64
root            (hd0,0)
kernel          /xen-3.3.0.gz
module          /vmlinuz-2.6.18-6-xen-amd64 root=/dev/sda6 ro console=tty0
module          /initrd.img-2.6.18-6-xen-amd64
savedefault

Que debería de bootear con el hypervisor 3.3

Incluyo algunas ligas de sitios (en inglés) que me ayudaron muchísimo para entender algo más de Xen ;)

Certificación en Zend Framework

Hace poco Zend publicó la certificación de Zend Framework:
http://www.zend.com/en/services/certification/framework/

Estoy algo divergente entre si es una buena opción o no

Buena opción:

  • El Framework está muy bien hecho como para que valga una certificación
  • Tiene tantos componentes que es una buena medida para destacar entre los que han utilizado solamente brevemente el Framework

 

Mala opción

  • Cuesta más que la certificación en PHP ($160 dolares en contra de $125 para la certificación de PHP)
  • Lamentablemente la certificación es en la versión 1.5 y la versión estable es la versión 1.6, si bien la versión 1.5 ya tenía muy estandarizado el modelo del Framework, a menos que tengan un periodo largo de liberar versiones (lo cual puede ser malo ya que ahora hay mucho movimiento) en menos de un año seguramente saldran al menos un par de versiones por lo que ¿se va a certificar en cada version? =P
Tampoco hay guia oficial, solamente está la opción de curso.
Creo que el Zend Framework debe crecer un poco más para estabilizarse en cuestión de características generales y de ahi ya es una opción muy válida de certificación; ya que en el momento hay mucho movimiento en cuestión de nuevas características, por ejemplo la versión 1.6 la principal mejora fue la introducción de Dojo.

 

Como programar (decente) en PHP

El viernes un cliente me pidió un favor de ayudarle a terminar de instalar un script de un amigo en su servidor. 

Todo parecía ser un simple problema con la importación de MySQL por los acentos, aunque eso solucionó parcialmente aún tenía un error en la parte medular del sistema, en cuanto abri el archivo que estaba dando el error me arrepentí de hacerlo y mi mente se volcó a recordar hace cinco años o tal vez seis cuando se programaba de esa manera =)

Con ese ejemplo me vino a la mente una frase célebre de mi buen amigo Nexus en esas épocas cuando estaba aprendiendo a programar en PHP, mi geek interno terco siguió programando con las antiquísimas $HTTP_POST_VARS a pesar de que se habían desalentado utilizar esas variables y se reemplazó por las variables tipo: $_POST ó $_GET

Recuerdo que cuando Nexus vio un código mio que tenía el $HTTP_POST_VARS me dijo en un chat con (me parece Carlos Cortez): “Programas a la manera viejita jajajaja”. Claro por orgullo después de eso nunca volví a tocar $HTTP_POST_VARS

Aqui tengo unos consejos para que no solamente sea fácil programar, depurar y para otros leer tu código. También para evitar que PHP siga siendo visto como un lenguaje de “bajo presupuesto” (por aquello que muchos prefieren Java por lo ‘empresarial’)

 

Tip: PHP dejó de ser un lenguaje de Script hace años

Lo digo en completo tono sarcástico, si bien PHP no se puede compilar no hay razón para meter todo dentro de un solo archivo como print’s con funciones, prácticamente se debe separar de preferencia en un modelo MVC si no puedes hacerlo, entonces al menos hazlo en VE (Vista-Espaguetti donde vas a meter tanto modelo como controlador)

 

Tip: register_globals está muerto

Por eso me dio miedo abrir el archivo, necesitaba register_globals. Para el que no sepa que es register_globals es simplemente que cuando mandamos parámetros a un script como por ejemplo: prueba.php?variable1=hola&variable2=mundo PHP convierte automáticamente esas dos variables en $variable1 y $variable2 con su respectivo contenido.

Qué fácil, ¿No?. Pues en realidad no, cuando el mundo no se percataba del error fatal de hacer esto, parecía que PHP era tan fácil de programar, vaya no necesitabas ni siquiera  vincular los parámetros.

Poco después un balde de agua fria cayó sobre todos nosotros… el problema es que cualquier tipo con algo de sesos puede simplemente pasar variables y asignar valores de la aplicación. En el caso de una aplicación que no inicializara las variables (el 99% para ser sinceros) podía sufrir porque era fácilmente “hackeada” sin necesidad de hacer mucho.

Por eso rápidamente se eliminó register_globals y se dejó como un parámetro opcional, pero muy opcional. Tanto que en PHP 6 va a desaparecer definitivamente. 

register_globals no ayuda, no hace más rápido el desarrollo; simplemente destruye todo lo bueno que podría tener una aplicación, porque en primer lugar es difícil saber cuales variables son parámetros del usuario y cuales son variables internas. También hace fácil explotar un sistema (creo que ya lo había dicho ;) ).

La solución para esto… reescribe tu aplicación.

 

Tip: die() está muerto

¿Alguien se ha preguntado porqué existe esta construcción del lenguaje de PHP?, supongo que es un legado de los viejos días cuando PHP era un lenguaje de script.

die() permite simplemente eso: hace que el script muera. Muchos lo hacían para verificar una situación intolerable como al abrir una conexión a una base de datos y que no se pudiera conectar; como no se pueden mostrar datos entonces simplemente le decimos al usuario: “perdon pero aqui nos detenemos” un ejemplo es el siguiente:

<?php
    mysql_connect($host, $usuario, $password) or die('No pude conectarme a la base de datos');
?>

¿Cuál es el problema?, muy simple la función die funciona tan perfectamente que el script se muere ahi. Por lo que el usuario simplemente verá una pantalla blanca con un texto críptico. En el peor de los casos mostrará una parte de la página y la “cortará” donde se haya ejecutado esta instrucción.

No seas perezoso, utiliza construcciones de if() para separar bloques de instrucciones en vez de suicidarte.
Si aún así quieres hacer un die() o un exit() al menos manda a llamar a una plantilla especial que muestre el error con la mayor parte del mismo estilo de la página que vas a mostrar, te lo agradecerá el usuario.

 

 

Tip: include y require es un arma de dos filos

También un legado de aquellos días es que un script luzca como:

<?php include 'cabecera.php'; ?>
<?php print "Hola mundo 'plantilla'; ?>
<?php include 'pie_pagina.php'; ?>

En aquellos días estas eran nuestras plantillas, cabecera.php mostraba el código inicial de HTML y pie_pagina.php cerraba ese código HTML, qué facil, ¿verdad?

Pues no, el problema de este método es que en primer lugar las variables son globales y compartidas, por lo que si haces el código espaguetti anterior es un total NO.

Por ejemplo es fácil sobreescribir variables dentro de un archivo “plantilla” y el error se propaga a las otras “plantillas”.

Otro problema es que hacen difícil seguir un flujo real de plantillas (si no quieres una parte tienes que reescribir todo en lugar de simplemente cambiar por ejemplo la distribución de los objetos en una plantilla general. También es fácil de romper todo el HTML por una etiqueta fuera de lugar

Una vez más, no seas perezoso y utiliza un manejador de plantillas como Smarty

Ahora bien del lado de programación un include() por lo regular es utilizado para incluir pedazos de código tales como funciones, clases, etc. Pero lamentablemente también es utilizado para incluir pedazos de código que tienen el mismo uso que funciones!!

Eso es algo totalmente prohibido, no se porque no utilizas funciones o mejor aún una clase.

 

Tip: mysql_connect y sus vicios

Un legado también de aquellos días es que se programaba de la siguiente manera:

<?php
include 'configuracion_db.php';
mysql_connect($host, $usuario, $password) or die('No pude conectarme a la base de datos');
?>

donde configuracion_db.php era simplemente:

<?php 
$host = 'localhost';
$usuario = 'mi_usuario';
$password = 'mi_password';
?> 

El primero se incluia prácticamente como cabecera para todas las páginas porque necesitaban acceso a la base de datos, y también se incluia dentro de otros bloques dentro de la misma página.

O peor aún, incluir en cada archivo los parámetros de configuración. Esto último es simplemente un caos y es no saber programar, así que toma un curso de programacion básica en otro lenguaje antes de programar en PHP ;)

Para el primer caso si bien es válido, es simplemente malo debido a que otro script puede fácilmente sobreescribir esas variables (o el mismo script por error). Aunque es utilizado, es muchísimo mejor utilizar un patron de diseño llamado: Singleton

El Singleton es un patron de diseño muy simple, en términos de orientación a objetos es un método estático de una clase que regresa siempre la misma instancia de la clase. Es decir solamente existirá un objeto en todo el sistema y que lo creará ese método estático normalmente llamado: obtenerInstancia()

En lenguaje de funciones es simplemente una función que regresará la misma variable (tendrá la misma dirección de memoria) cada vez que se llame, así que en lugar de hacer el primer ejemplo utiliza este:

<?php
function obtenerConectorMysql() {
     static $conector_mysql = null; 
     if ($conector_mysql == null) {
         //aqui insertar las instrucciones para obtener el host, usuario y password, 
         // por ejemplo de un archivo o simplemente escribirlas aqui
         $conector _mysql = mysql_connect($host, $usuario, $password);
     } 

     return $conector_mysql;
}

 

Esto simplemente crea la primera vez que se llame el conector_mysql, después simplemente lo regresa por lo que no se crean diferentes instancias, es la misma conexión a MySQL

Si lo quieres hacer mediante clases, puedes utilizarlo algo similar como una llamada a una función estática o “envolverlo” en la clase que tengas para manejar la base de datos.

Tip: La seguridad no es para sitios de comercio o bancos solamente

Mucha gente piensa que debe hacer “seguro” un sitio solamente si va a tener operaciones monetarias. Nada más fuera de la realidad. 

Todos los sitios necesitan seguridad para evitar que los ataques logren su resultado: hacer “explotar” la aplicación.

Evitando los errores más comunes tendrás una aplicación que si bien no es tan segura como la de la CIA (lease con sarcasmo) evitará el 90% de los ataques comunes.

  1. Al desarrollar una aplicación, recuerda que el usuario no es de fiar, por lo que todo lo que provenga del usuario puede ser alterado
  2. Siempre verifica la información que el usuario envió mediante parámetros. Si es posible restringe mediante un arreglo de valores válidos, si no es posible entonces haz muchas verificaciones, por ejemplo en el caso de un archivo, elimina caracteres peligrosos como: ‘..’ o ‘/’ que pueden hacer que el sistema lea (o incluso escriba) un archivo muy diferente al planeado.
    Esto se hace indispensable si vas a utilizar una función poderosa como include() o acceso al archivo (como fopen() )
  3. Nunca pongas datos importantes en una cookie, utiliza sesiones. Si lees datos de una cookie nunca asumas que por ser cookie es dificil de alterar
    Si los datos van a “perdurar” más alla de una sesión, entonces deja en la cookie un identificador único y guárdalo en la base de datos, de esta manera el usuario solo debe proveer su identificador y no otra información que pudiera ser alterada. 
  4. Siempre “escapa” las variables que vas a utilizar en una consulta a la base de datos, utiliza funciones como: mysql_escape_string(), si utilizas un framework la mayoría de ellos tienen una función para hacer esto (que terminan llamando a algo similar a la primera función)

 

Tip: PHP5 no es una opción, es obligatorio >=)

No veas a PHP5 como una “extensión” o una versión más. El propósito de PHP5 es hacer una transición entre el mundo de scripts de código espaguetti a un sistema de clases muy bien separadas.

Aunque PHP5 aún permite programar sin clases y con solo funciones; si tienes la oportunidad no dudes en utilizar PHP5 con clases con todo lo nuevo que trae. La guia de estudio de Certificación Zend es un buen inicio. 

PHP5 tiene un gran potencial y está esperando para ser plenamente utilizado, algunos frameworks ya están utilizando plenamente su potencial, entre ellos Zend Framework que es altamente recomendable.

 

Último tip: MVC es lo único para web ;)

Si vas a desarrollar una aplicación en PHP que contenga todo lo que una aplicación web contiene (contenido en HTML, bases de datos, procesamiento, etc) simplemente utiliza un framework que tenga un diseño de MVC; los más conocidos son Zend Framework (mi recomendación nuevamente) y CakePHP, también están otros en rápido ascenso como Simfony y Code Igniter

También son de uso popular los CMS como drupal y joomla/mambo, aunque ellos no proveen directamente el modelo MVC si proveen el modelo Vista-Espaguetti por lo que con un poco de trabajo extra puedes lograr algo similar a MVC

 

En resumen PHP es un lenguaje muy poderoso y con historia; por lo que es fácilmente quedarse con las primeras formas de programar, pero con todos los nuevos desarrollos ahora si se puede empezar a hablar de un PHP a nivel empresarial (ya formalmente ;) )

 

Frameworks en Javascript

Sin duda los frameworks son una gran idea porque nos ayudan a desarrollar más rápido y sobre todo con una interfaz mas amena al usuario, aqui hay algunos de los frameworks que utilizo o he utilizado:

Prototype y script.aculo.us

Uno de los frameworks más viejos y que inicio con el movimiento AJAX y el de la Web 2.0
De hecho prototype parece ser el que “patentó” las abreviaturas como $(…) para acortar el document.getElementById, algo que otros frameworks también tendrán de forma similar

Ventajas: Limpio y fácil de usar, se usan de manera separada
Desventajas: No tiene muchos widgets

Página de Prototype Página de Script.aculo.us

jQuery

jQuery es una de esas librerías que en el momento en que la comienzas a utilizar no la dejarás ;) es muy simple de utilizar y lo que la llevo a la cima fueron los selectores, esta es una manera muy útil de seleccionar en primer lugar elementos DOM que cumplan con una regla, por ejemplo con jQuery $(‘img.miClase’) estamos seleccionando todas las imagenes que tengan como clase la de nombre “miClase”, esto es algo que toma muchas lineas en javascript “normal”, también regresa esto como un arreglo por lo que se puede ir alterando uno a uno o utilizando sus funciones de jQuery

El manejo de AJAX es un muy simple (como en la mayoría de frameworks), y por último se está trabajando en widgets para darle más poder a este framework

Ventajas: Pequeño, muy poderoso, fácil de usar, documentación bien estructurada (en la mayoría de casos)
Desventajas: No hay widgets, la parte jQuery-UI que se encarga de esto aún está en desarrollo y puede resultar en más tipo de prototipo rápido que en aplicaciones robustas

Página de jQuery Página de JQuery-UI

Mootools

Mootools es otra de esas herramientas que generan adicción, sus grandes ventajas están del lado gráfico ya que tiene efectos muy cuidados y algunos widgets que son muy útiles. También extiende algunas clases de uso común como Array o String para añadirle funciones útiles.

Las nuevas versiones también incluyen selectores aunque más básicos que jQuery

Ventajas: Efectos fáciles de utilizar, extiende funciones directamente a clases nativas
Desventajas: Falta de widgets avanzados

Página de mootools

YUI

Una Mega-Librería de Javascript, básicamente es un conjunto de widgets muy bien ensamblados y programados. Si se necesita programar algo a nivel empresarial sin duda YUI es la mejor solución, incluye widgets como autocompletado o el de calendario (que lo catapultaron a la fama), así como manejo de AJAX en una forma un poco más complicada (si se puede decir de esta manera) pero también más uniforme.

Por ejemplo es fácil crear un dialogo que envie la información de un formulario mediante AJAX debido a que fue pensado en muchos patrones de diseño y  programación.

Ventajas: Muchos widgets, uniformidad entre componentes, muy buena documentación y una gran cantidad de ejemplos.
Desventajas: El selector es una característica nueva (BETA), archivos gigantescos (en términos de javascript y que alcanzan un promedio de 500KB para descargar algunos componentes, en espacio de disco puede llegar hasta más de 10 MB si se descomprimen todas las versiones), lamentablemente como muchos componentes están relacionados no hay manera de “cortarlos” (aunque es posible no incluir los elementos adicionales para aliviar un poco la descarga de archivos, pero aún asi la arquitectura debio ser distinta y no incluir todo en un mega-componente)

Página de YUI

Ext-JS

Es una gran librería con muchos widgets de uso para una aplicación empresarial Web 2.0, tiene demos muy interesantes y provee soporte de licencia comercial u open source.

Ventajas: Muchos widgets
Desventajas: No lo he probado ;)

Página de ExtJS

Otras frameworks que prometen saltar a la fama si son llevados a cabo de manera cuidadosa:

Dojo

Aunque siento que Dojo no ha encontrado su “nicho” (a pesar de que está soportado por Zend Framework en la parte de Ajax), este puede ser la parte gráfica desde javascript, por supuesto javascript no puede dibujar sobre el navegador pero si lo puede hacer mediante otros plugins como el caso de SVG, Silverlight o Flash, al parecer ahora solo soporta SVG y Silverlight y no han implementado Flash que es mejor para esto.

Spry

Esta tecnología hay que observarla de cerca porque está madurando y va a ser un modelo a seguir en los próximos años.

Básicamente es un conjunto de widgets que se incrustan mediante xhtml en una página, así en vez del “aburrido” javascript de una vez que se ha cargado el documento asignar variables mediante id’s, nombres, etc; podemos hacer algo como:

<div id="productMenu" spry:region="dsProducts" style="display: none;">
	<table>
		<tr spry:repeat="dsProducts" spry:hover="hover" spry:suggestion="{name}">
			<td><div class="boxshot"><img src="../../demos/products/{boximage}" alt="{name}" /></div><div>{name}</div></td>
		</tr>
	</table>
</div>

Donde claramente se notan partes que serán rendereados en javascript, algo muy innovador.

Página de Spry

Actualización a Zend Framework 1.6

Me acabo de dar cuenta que ya hay una nueva versión estable de Zend Framework, la 1.6.

Al parecer lo más novedoso es la incorporación de Dojo y la incorporación de SOAP. En lo particular no uso Dojo, pero vale la pena probar estos cambios.

No planeaba “actualizar” tan rápidamente, pero me acabo de dar cuenta que hay un bug en las versiones de 1.5.* que cuando Zend_Db lee un campo tipo LONGBLOB trata de reservar en una variable todo el tamaño máximo del longblob (aproximadamente 4GB) algo que hará tronar a PHP y marcará un fatal error.

Como estoy trabajando en un proyecto con LONGBLOB decidí actualizar, más adelante escribiré mis experiencias con los nuevos componentes, que SOAP es algo que tengo que probar =).

Bug de Zend Framework:http://framework.zend.com/issues/browse/ZF-1498

Descargar Zend Framework 1.6

Nota Mental para Drupal – Formularios personalizados

Debido a que muchas veces tengo que personalizar un formulario de Drupal para adaptarlo a un diseño en especial y muchas veces incluso cambiar el botón normal de “Submit” por una imagen, para esto normalmente llamo drupal_render($form['elemento']); desde la plantilla; cuando necesito cambiar el botón de crear por una imagen, pues simplemente incluyo un elemento oculto al final:

<input type="hidden" name="op" value="Submit" />

De esta manera sobreescribe el valor de la imagen (por como maneja PHP las variables enviadas por el navegador); todo funcionaba bien en una aplicación reciente; pero al instalarla en el servidor del cliente dejó de funcionar. después de revisar algunas cosas recordé que el “Submit” es traducido al idioma correspondiente, por lo que el sistema no reconocerá que enviaste el formulario, la solución es muy simple (pero que siempre olvido):

<input type="hidden" name="op" value="<?=t('Submit')?>" />

Decirle a la plantilla que traduzca también el “Submit” ;-)

eWeek

revista eWeekDesde hace algún tiempo he estado suscrito a la edición eWeek digital de forma gratuita; en una de las tantas renovaciones puse que me enviaran de manera impresa la edición; aunque después me informaba que no había subscripciones fuera de Estados Unidos.

Recientemente me llegó un ejemplar de eWeek impreso aunque algo viejo del 19 de Mayo; aunque cabe recordar que nuestro heroico servicio postal no ha cambiado mucho desde la época prehispánica donde incluso era menor el tiempo de entrega y eso que iban a pie.

Me puse a leerlo todo el fin de semana, aunque ya había leido algunas partes en la edición digital; pero es más interesante leerlo en papel que en pantalla.

Ahora la pregunta es si seguirá llegando, no creo que llegue semanalmente aunque sean números atrasados y también sospecho que mi cartero no entrega todas las revistas que he pedido porque a veces cada dos meses llega una. Tal vez sea porque no le he dado su día del cartero ni aguinaldo =P

PHP y msmtp

La mayoría de ISP bloquean el puerto 25 para “evitar” que computadoras infectadas envien SPAM. Este era mi caso por lo que me era imposible probar los correos que enviaba mediante PHP hasta subirlos a mi servidor de pruebas.

Recientemente me encontré con msmtp que es básicamente un cliente SMTP que funciona como proxy para enviar correo mediante otro servidor.
Para instalar msmtp en mi caso debian solo se necesita:

apt-get install msmtp msmtp-mta

Para configurarlo basta crear el archivo /etc/msmtprc con la configuración correspondiente, por ejemplo en mi caso fue:

defaults
tls on
tls_certcheck off

account danguer.com
host mail.danguer.com
port 999
from monitor@danguer.com
auth on
user monitor@danguer.com
password password_cuenta

account default: danguer.com

Lo que dice la configuración es que básicamente utilizará TLS (para mayor seguridad, además de que mi servidor lo requiere).
Creamos una cuenta llamada danguer.com y le decimos el usuario y la contraseña a utilizar, ya por último asignamos la cuenta por defecto que vamos a utilizar.

Con esto deberiamos de poder enviar correos como con sendmail pero utilizando el programa /usr/bin/msmtp por lo que lo único que basta es configurar php para que envie utilizando el programa en vez de sendmail.

En el archivo php.ini pondremos lo siguiente:

sendmail_path=/usr/bin/msmtp -t -i

Reiniciamos apache y ahora cuando utilicemos la funcion mail el sistema lo enviará mediante el servidor que hayamos especificado.

De hecho podemos utilizar una cuenta de gmail para hacerlo pero hay que tener en cuenta que debido a sus filtros anti-spam nuestros mensajes podrían ser rechazados o incluso la cuenta podría ser bloqueada para enviar correos (por defecto acepta un límite de 100 correos por día)

Ejabberd y mod_archive

Hace algo de tiempo conocí ejabberd, es un servidor de Jabber de alto desempeño; inicialmente debo admitir que no me gustó mucho principalmente porque está escrito en Erlang y que tenía poca documentación, además de que cometer un error de configuración mostraba muchisimos datos sin sentido para programadores de Erlang y nada en lenguaje ‘humano’.
Ahora el proyecto ha madurado considerablemente y una de las ventajas por la que sigo utilizando Ejabberd es que es el único servidor Jabber open source en manejar clustering.

Recientemente me pidieron instalar un módulo para almacenar la historia de las conversaciones, algo que hace por ejemplo Google Talk (que está implementado en Jabber), este es el protocolo: XEP-0136 y utilizar la opción de guardar conversaciones automáticamente (sin intervención del usuario para solicitar que se almacene).
Hay diversos modulos para implementar esto en ejabberd, pero buscando me encontré que mod_archive es el mejor y el que se encuentra con desarrollo activo.
El problema es que prácticamente no existe documentación ni información de si por ejemplo funcionaría en Ejabberd 2 que es la versión del servidor que utilizo.

A prueba y error y con algunos pequeños documentos que me encontré descubrí que si funciona en la versión 2.0, a continuación vienen los pasos para hacerlo funcionar con MySQL:

  • Compilar ejabberd para que acepte odbc
    ./configure --enable-odbc
  • Descargar los módulos de ejabberd
    svn co http://svn.process-one.net/ejabberd-modules
  • Compilar el módulo interno de MySQL de los módulos descargados de ejabberd
    cd mysql/trunk
    ./build.sh
    cp ebin/*.beam /directorio_ejabberd/var/lib/ejabberd/ebin/
  • Compilar el módulo de archivo (mod_archive)
    cd mod_archive/trunk
    ./build.sh
    cp ebin/*.beam /directorio_ejabberd/var/lib/ejabberd/ebin/
  • Editar el archivo de configuración de Ejabberd para habilitar odbc
    {odbc_server, {mysql, "direccion_servidor", "base_de_datos", "usuario", "contraseña"}}.
  • Editar el archivo para agregar mod_archive (parte de {modules,…)
    {mod_archive_odbc,  [{database_type, "mysql"},
    {default_auto_save, true},
    {enforce_default_auto_save, false},
    {default_expire, infinity},
    {enforce_min_expire, 0},
    {enforce_max_expire, infinity},
    {replication_expire, 31536000},
    {session_duration, 1800},
    {wipeout_interval, 86400}
    ]},
  • Crear la base de datos utilizando el archivo: ejabberd-modules/mod_archive/trunk/src/mod_archive_odbc_mysql.sql

Hay que hacer notar que el archivo sql es para MySQL 5 y posteriores (para utilizarlo con una versión anterior hay que eliminar la parte de triggers), además el archivo crea una base de datos llamada ejabberd, si se necesita otro nombre editarlo para ya sea eliminar la parte de crear o cambiar el nombre de la base de datos que será creada; utiliza el prefijo archive_ para sus tablas.

Iniciar (o reiniciar) el servicio de ejabberd y a partir de ahora todas las conversaciones serán guardadas en mysql.

CentOS y PHP DOM

Hace mucho tiempo que no utilizaba una versión de Redhat; ya que sólo utilizaba Redhat cuando comence a aprender Linux, luego conocí Debian y no he necesitado otra distribución.

Pero ahora en el trabajo me han pedido configurar algunos servicios en un servidor CentOS y la verdad es que prácticamente a mi gusto Yum está muy atrasado respecto a apt-get pero lo peor que me encontré en CentOS es que la parte de DOM (lo que antes era DomXML) de PHP5 no está compilado!!, y eso que a diferencia de PHP4 la parte de DOM no necesita librerías externas por lo que no se sinceramente porqué esta parte fue omitida.

Para sanar hay dos opciones: instalar una versión recompilada de PHP incluyendo DOM, o compilar el módulo por separado de DOM e instalarlo a la versión actual; yo preferí utilizar esta última.

Para compilar solo el módulo, necesitas descargar la misma versión de PHP que tengas instalada, puedes buscar en internet por: php-VERSION.tar.bz2; por ejemplo: php-5.1.6.tar.bz2

Esta liga tiene varias versiones de PHP: http://museum.php.net/php5/

Después de descargar, simplemente debes hacer:
./configure --enable-dom=shared --enable-xmlreader=shared

Hacer el clásico make y esperar a que compile, una vez terminado verás en la carpeta modules/ dos archivos: dom.so y xmlreader.so, estos se deben copiar al directorio de modulos de php; en CentOS: /usr/lib/php/modules/

Después editar tu /etc/php.ini e incluir lo siguiente:

extension=xmlreader.so
extension=dom.so

Reiniciar apache:
/etc/init.d/httpd restart

Ahora deberás tener PHP5 con DOM funcionando.