Squirrelmail para multiples dominios

Usar un Squirrelmail, para servir múltiples dominios, es un problema que ya había resuelto hace varios años atras, pero con la movida de mi servidor, uno de los directorios que me olvide respaldar fue justamente el del webmail. Así que tuve nuevamente que reinventar la rueda. Pero para que  no me vuelva ha pasar voy a poner en éste blog los cambios, así además de quedar en un lugar del que siempre voy ha tener un back up, también compartiré el pequeño cambio que hice para que le sirva a todo aquel que lo necesite.

El problema es sencillo, que pasa si se tiene en un servidor varios dominios, hacer varias instalaciones de squirrelmail, una para cada uno de ellos no parece ser la solución más inteligente, pues cualquier actualización requeriría ser replicada en tantos directorios como dominios se tenga en ese server. Así que la solución más obvia es tener una sóla intalación y aprovechar la directiva "ServerAlias" del Apache. Para ello creamos un servidor virtual con un alias para todo dominio que comience con la palabra webmail, la configuración del Apache es ésta:

<VirtualHost 1.2.3.4>
    ServerAdmin  webmaster@undominio.com
    DocumentRoot /usr/share/squirrelmail
    ServerName   webmail
    ServerAlias  webmail.*
    DirectoryIndex index.html index.htm index.php index.cgi index.html.var
    ErrorLog  /var/squirrelmail/logs/error_log
    CustomLog /var/squirrelmail/logs/access_log common
</VirtualHost>

Con la configuración anterior no importa cuál sea el nombre de dominio, mientras éste comience con webmail será redireccinado por el apache al directorio /usr/share/squirrelmail (directorio por defecto donde se instala el Squirrelmail en debian). Ojo debe reemplazar 1.2.3.4 por el IP que tiene en su servidor.

Pero eso deja sin resolver otro problema, que cada vez que un usuario quiere leer su correo web debe de tipear la direccion de correo completa es decir: "usuario@dominio.com"

Ésto puede ser incómodo y hasta frustrante para muchos usuarios, así que lo mejor es hacerlo automático, para ello aprovecho una de las variables que nos ofrece PHP y que es $_SERVER[‘HTTP_HOST’], en ella siempre podemos encontrar el nombre de dominio completo del servidor web en el que estamos corriendo el script.

Todo el truco esta en agregar unas cuantas líneas al script redirect.php del squirrelmail que suele estar en /usr/share/squirrelmail/src/redirect.php, busque esta líneas:

/* get globals we me need */
sqGetGlobalVar(‘login_username’, $login_username);
sqGetGlobalVar(‘secretkey’, $secretkey);

Inmediatamente después de ellas copie y pegue estos cambios:

/* Modificado por mi para permitir multiples dominios */
$hostname = $_SERVER["HTTP_HOST"];
$str_len = strlen($hostname);
$diff = $str_len – 8;
$domain_name = substr($hostname, 8, $diff);
$email_completo = $login_username . "@" . $domain_name;
$login_username = $email_completo;
/* Fin de los cambios */

Las lineas que se añaden hacen toda la magia, extraen el nombre de dominio de la variable $_SERVER[‘HTTP_HOST’], le remueve la pablabra webmail y finalmente le pega el login y el "@" y lo reemplaza en la variable $login_username que usa squirrelmail para validar al usuario. Ésta es una solución simple y limpia, claro que descubrir donde hacer los cambios me tomo buen tiempo la primera vez, al menos esta vez ya sabía que era en redirect.php donde debía hacer los cambios. Sólo tuve que hacer un poco de memoria y creo que esta segunda vez hice un addendum de código mucho más limpio que la vez anterior, así que no estuvo del todo mal que perdiera los cambios anteriores.

Espero que esta información les haya sido de utilidad, y espero sus comentarios.

Adobe planea convertir FLV en estándar

El popular formato FLV (Flash Video), propiedad de Adobe Corporation, al igual que su popular formato para animaciones SWF seran parte de una inciativa tomada por Adobe y un grupo de grandes compañías del medio, entre ellas Cisco, Intel, Samsumg, NTT Docomo y varias más para crear el Open Screen Project, que no es otra cosa más que usar los conocidos formatos propietarios de Adobe como la base para el nuevo estándar de streaming de video a través de la red.

¿Por qué no se protesta contra esto de la misma manera a como se protestó contra el OOXML de Microsoft?, básicamente porque el formato FLV es un estándar de facto y Adobe ha sido cuidadosa de no crear anticuerpos en el mercado, a la vez de que mal que bien el protocolo esta 100% implementado actualmente y hasta hay implementaciones OpenSource del mismo, sin que ésto haya motivado a que Adobe tome acciones legales. En pocas palabras Adobe se comporta mucho mejor que Microsoft.

La idea que más me atrae es que si el formato FLV, se vuelve abierto los fabricantes de dispositivos de visionado de video portable, algunos los llaman erroneamente MP4, ya no tendran que trabajar con formatos propietarios desarrollados por ellos mismos, que dificultan el intercambio entre personas que no tienen el mismo tipo de dispositivo. En pocas palabras, la estandarización del FLV hara más fácil intercambiar videos. Además de que sera posible que todo fabricante de celulares lo incluya en su equipo pues no habra que pagar royalties y nuestros celulares incluiran ahora no sólo la característica de tocar música almacenada en ellos en formato MP3, sino que además permitirá el visionado de videos en formato FLV.

Definitivamente para mi ésta es una buena noticia, aunque definitivamente no creo que lo sea para los grandes estudios, que supongo ahora se uniran a las disqueras para protestar contra las redes P2P de intercambio de formatos digitales, pero así es la vida no todos se sienten complacidos con el avance de la tecnología.

Segundo Encuentro de Usuarios Linux Chiclayo

En forma paralela al FLISOL en Chiclayo, el pasado sábado 26 de abril, se ha organizado el  "Segundo Encuentro de Usuarios Linux Chiclayo", en el cuál participé remotamente haciendo uso de un servicio de video-conferencia que ya he comentado en éste blog anteriormente llamado Dim Dim.

Durante la charla ofrecí poner en éste blog la presentación que se uso, para que nadie se sienta discriminado, he incluido la misma presentación en los tres formatos más populares (Power Point, OpenOffice, PDF), aquí los archivos para que los descarguen.

Gracias a todos los que participaron en el evento.

Hackontest, maratón de hacking.

¿Estaría Ud. dispuesto a participar en una maratón de programación de 24 horas en su proyecto OpenSource favorito?, pues les hablaré sobre Hackontest, el último proyecto de promoción del Open Source promovido por Google. El principal objetivo de los creadores de Hackontest, es mejorar los proyectos Open Source en base a las necesidades de los usuarios, y hacer público la manera cómo se desarrolla Open Source de una manera bastente entusiasta.

Durante la actual fase  de selección del proyecto Hackontest, los usuarios y desarrolladores de proyectos Open Source están enviando solicitudes de nuevas características, votando por las ya propuestas o comentándolas, todo muy web 2.0. El 1 de agosto de éste año, el jurado seleccionará los tres equipos más prometedores, cada uno de los cuales recibirá un viaje todo pagado a Suiza los días 24 y 25 de setiembre para participar en la competencia final ha realizarce en la ciudad de Zurich.

La competencia final sera dentro del Mission Eternity Sarcophagus (Sarcófago Misión Eternidad), desarrollado por eToy, y que es de 6 metros de largo, 2.4 metros de ancho, y 2.6 metros de alto. Donde los desarrolladores estaran por 24 horas trabajando sobre su proyecto Open Source, y su única comunicación con el mundo exterior será su comunidad virtual. Durante esas 24 horas los equipos en la final deberán implementas las características seleccionadas por el jurado, de todas la enviadas durante la fase de selección on-line. El equipo ganador recibirá un premio de U.S.$ 8,500.

Una interesante idea, y sobre todo que muestra que el Open Source no es un fenómeno de un puñado de desarrolladores, sino el esfuerzo conjunto de una comunidad que hace uso de los programas y que propone nuevas características, las implementa, prueba y añade al proyecto de forma orgánica.

Asus libera el SDK para el eeePC bajo licencia OpenSource

El fabricante Taiwanes de laptops Asus, ha  liberado el SDK para el eeePC, a la par de una imagen virtual del sistema operativo de la eeePC que puede correr en VMWare o el más alineado con el OpenSource VirtualBox, de esa forma los interesados en desarrollar aplicaciones para el popular laptop eeePC, que aparentemente pronto tendra también una versión desktop, podran hacerlo sin problemas pues tendran acceso a todas las herramientas de software necesarias para la plaforma.

El website con todas las herramientas de desarrollo está en SourceForge, y es una prueba del fuerte apoyo que está dando Asus al OpenSource. Si Asus consigue posicionar su modelo cómo el estándar de facto en el sector de laptops ultra portátiles, pues habra creado una nueva categoría de latops y todo un ecosistema alrededor de ella. Por el momento el SDK que se ofrece sólo soporta C/C++, pero es de lejos una oferta mucho más organica que el actual SDK para el proyecto OLPC, donde al parecer no les interesa mucho el aporte de la comunidad.

Como dijera Erick Raymond, en su popular ensayo, "La catedral y el bazar", al parecer el proyecto OLPC sigue la aproximación de los constructores de catedrales, para ser desarrollador para la plataforma OLPC se necesita hacer muchos compromisos, mientras que Asus y su eeePC, está apostando claramene al desarrollo tipo bazar, que es justamente el paradigma del software libre, cualquiera simplemente descarga el SDK y se pone a desarrollar o hackear el eeePC.