Segunda y última parte de la entrevista, tal como se prometió, sobre un caso de éxito llevado a cabo en una empresa de Argentina en la que decidieron reemplazar un servidor Microsoft Exchange por una combinación de productos GNU como servidor de correo electrónico.

En esta última entrega, podrán leer sobre como fue el proceso decisorio llevado a cabo, qué problemas se tuvieron que sortear, qué y por qué se hizo y no se hizo, cuando y como, etc., en una compañía de seguros de Argentina, Alba Compañía Argentina de Seguros S.A., para el proyecto de reemplazo del servidor Exchange por otro GNU que resultó de la combinación de Postfix, Courier, ClamAV, Horde, Turba, OpenLDAP, Kronolith, Ingo, Nag, Mnemo e IMP, obviamente todo corriendo en un servidor GNU/Linux.

Debo aclarar que en honor a la espontaneidad y para intentar transmitir esa frescura que predominó durante toda la charla, en lugar de publicar una nota editada en base a la entrevista me pareció adecuado transcribirla tal como resultó. Tal vez el lector observe varios defectos en la misma, pero estoy seguro que podrá encontrar varios puntos interesantes, sobre todo por el lado tecnológico, en la experiencia relatada.

GR: Y cómo fue el proceso de análisis de alternativas ?

A: No fue fácil. Primero consideramos tres opciones pero con el asesoramiento de TFS más búsquedas propias finalizamos comparando seis soluciones entre sí.

De las cinco, hubo dos que quedaron descartadas de inicio por ser desarrollos que recién comenzaban. Es decir, proyectos que aún no estaban maduros y no encontramos una base instalada representativa.

Luego evaluamos y hasta probamos, instalando oportunamente cada uno en un servidor, Merak y Scalix, ambos licenciados. Al primero lo descartamos porque estaba más orientado a un perfil de ISP y al segundo porque encontramos que, a pesar de parecernos muy bueno y completo, nos generaría cierta dependencia con Scalix y esta empresa no tenía en ese entonces ninguna representación técnico comercial en Argentina, teníamos que tratar todo vía Inglaterra o Alemania, además de no soportar caracteres latinos como ñ, vocales acentuadas, etc.

Eso nos dejo con dos alternativas posibles: MS Exchange 2003 y la combinación de productos GNU.

GR: Como ya se cómo terminó la historia, contame cuáles fueron los factores que inclinaron la balanza para la solución elegida, como para tener una idea de qué se evaluó, cómo y por qué.

A: Si. Esta fue, para mi, la parte mas difícil porque nos estábamos jugando el éxito o el fracaso de todo el proyecto. Nos estábamos tirando a una pileta sin saber si estaba llena o vacía y justo aquí fue donde el apoyo de Technology for Solutions (http://www.tfsla.com) jugó un papel importantísimo ya que nos sentimos bien acompañados, como para hacerle frente a lo que venga y que nos saliera bien.

Teníamos por un lado Exchange 2003 con gran cantidad de mejoras que nos obligaban a migrar los Office a la versión 2003, incorporar un servidor importante para correr el Exchange, recapacitación técnica y el costo de todas las licencias para acceder a esos beneficios. Por el otro, una solución GNU totalmente personalizable y mantenible por nosotros mismos al contar con los fuentes, que no poseía las mismas mejoras funcionales que prometía Exchange 2003 con todos sus requerimientos, pero que tampoco era para despreciar ya que, frente a lo que estábamos usando en ese momento, representaba un gran avance, no nos obligaba a migrar las versiones en uso de Office, no necesitábamos un servidor dedicado de mediano/gran porte y nos brindaba un esquema de alta disponibilidad rápido, simple y eficiente. Además esta alternativa nos permitiría mantener al día no sólo las versiones estables que fueran saliendo sino también todos los parches de seguridad. Aquí hay que recordar que para Microsoft un Exchange 2000 es un producto y el Exchange 2003 otro distinto, para lo cual hay un cargo adicional para estar actualizado.

Pero más allá de todo esto, lo que terminó por inclinar la balanza fue que funcionalmente contábamos con mejoras para los usuarios: No había curva de aprendizaje pronunciada ni prolongada ya que continuaban utilizado la misma versión de Outlook, se mejoraba profundamente el control antispam y antivirus, se mejoraba profundamente el servicio de webmail posibilitando funcionalidad groupware en ese ámbito, incorporamos IMAP4 como alternativa para usuarios ubicuos/móviles, contábamos con un servidor que adhería totalmente a los estándares de la industria respecto de protocolos de mensajería, los límites respecto de cantidad de cuentas y almacenamiento estaban marcados por las capacidades físicas del hardware, había instalaciones similares en el país, la UTN cuenta con una implementación similar, por mencionar una que recuerdo en este momento. A esto hay que agregar el esquema de alta disponibilidad y una mejora sustancial en cuanto a seguridad ya que toda la comunicación desde y hacia el mailserver viaja encriptada, inclusive y fundamentalmente en el webmail.

GR: Y qué inconvenientes tuvieron que superar, o fue todo «color rosa» ?

A: Color rosa !! Noooo, para nada !! Nos encontramos con varios problemas que tuvimos que resolver sobre la marcha, principalmente durante la migración y debido a cuestiones muy específicas. Por ejemplo, el Outlook 2000 no trabajaba adecuadamente con IMAP4, entender como funcionaba LDAP y acostumbrarnos a una operación sutilmente distinta cuando se busca un contacto, administrar los falsos positivos del antispam, manejar la lista blanca de direcciones y otras cosas a las no estábamos acostumbrados.

Por el lado de los usuarios también tuvimos algunas sorpresas inesperadas, particularmente con el cache de contactos que utiliza Outlook y que generó gran cantidad de mensajes no entregados porque traía la dirección para el Exchange y no para el nuevo servidor. Fué todo un proceso en sí mismo.

También nos encontramos con una realidad que el hecho del spam nos ocultaba: La gran cantidad de mensajes promedio «per cápita» que se generan internamente superó nuestras estimaciones y tuvimos que introducir algunos cambios apenas pusimos en producción al servidor. Por ejemplo, modificamos el tipo de file system que usamos para almacenar los mensajes ya que la gran mayoría ocupan poco lugar pero son muchos, de esta forma intentamos optimizar el aprovechamiento del espacio en disco y la velocidad de respuesta al guardar y recuperar mensajes.

Otro factor que modificamos fue el adaptador de red. Pusimos una placa para servidores porque la placa que estábamos utilizando no era suficiente para manejar adecuadamente todo el tráfico de red desde y hacia el servidor. Y todavía nos quedan algunas mejoras para introducir que confiamos mejorarán aun más la respuesta.

Una funcionalidad que nos obligo a generar un proyecto aparte fue la que en Exchange se conoce como Carpetas Públicas. Ahí aprovechamos que teníamos que hacer un desarrollo nuevo e incorporamos la filosofía de Base de Conocimientos. Todo desarrollado en PHP, también junto a la gente de TFS, y que nos permitirá apoyar nuevos servicios internos, más allá del uso que antes se le daban a las Carpetas Públicas, lo cual también representa una mejora a lo que teníamos.

Así y todo no llegamos a invertir todo el dinero que exigía el proyecto con Exchange 2003 e incorporamos nuevos conocimientos y habilidades, materia fundamental en la Visión de la compañía, no sólo en lo referido a un servidor de e-mail sino también a virtualización, uso de base de datos con MySQL, seguridad, manejo de certificados digitales, etc. Todo esto como base necesaria para mejorar la oferta y calidad de nuestros servicios al cliente.

GR: Además de este proyecto y luego de la experiencia lograda con él, han encarado algún otro basado en software Open Source ?

A: Si, varios. Un nuevo Firewall, nuevos servidores DNS y DHCP internos, más servidores especificos virtualizados, etc.

GR: Bueno, pero por lo que mencionás, creo que dá para otras notas futuras, qué te parece ? Además me quedan varias preguntas para hacerte, cómo es el esquema de alta disponibilidad es una de ellas.

A: Si, ningún inconveniente y con mucho gusto podemos volver a reunirnos para que te comente qué hicimos y cómo nos fue en cada uno de ellos. El esquema de alta disponibilidad basado en virtualizacion es muy interesante por su efectividad, sencillez y practicidad.

GR: Ok. Muchas gracias por tu excelente y desinteresada buena predisposición y ya nos estaremos volviendo a ver por los demás proyectos para contarles a los lectores de Geeksroom más casos como este.

Esta fue la experiencia vivida dentro de Alba Compañía Argentina de Seguros S.A. relatada por su responsable de Redes y Servidores, Ariel Sliwkin.