Laboratorio Docente de Computación.
Ciro José Durán Ostos (ciro@ldc.usb.ve)
29 de junio de 2005
La instalación de un nuevo servidor de correo es una tarea bastante sencilla y requiere hacer un poco de investigación. La migración de un servidor de correo de alto tráfico y con varios usuarios no lo es. A la tarea de migración se suma también la de preguntarse si vale la pena cambiar algún componente del sistema, o si es mejor actualizar la versión solamente.
En este coloquio se indican los pasos que se siguieron para poder realizar la migración del servidor de correo y del manejador de listas de correo del LDC, los cuales se pusieron en producción el 25 de junio de 2005. En este documento encontrarán, en orden, la motivación que llevó a hacer la migración, un resumen de las características de ambos servidores, la evaluación que se realizó de las posibles soluciones que podíamos utilizar para el nuevo servidor, la estrategia que se utilizó para realizar la migración, los problemas que se encontraron a la hora de migrar, los resultados de este proceso, y algunas tareas futuras que se pueden realizar para complementar el servidor.
Una de las principales motivaciones para realizar la migración del servidor de correo fue la evidente sobrecarga que presentaba el servidor anterior, el cual se notaba por las constantes operaciones de lectura de disco duro que hacía, la lentitud con la que se realizaban las operaciones de transferencia, y las constantes sospechas de pérdidas de correos enviados.
Debido a ser una migración de servidor, no se consideró la posibilidad de cambiar de MTA, por lo que no se evaluaron otras alternativas.
Para la migración se consideró cambiar de servidor de IMAP como una forma de probar otras alternativas. Se consideraron tres alternativas: el servidor Cyrus de IMAP, el servidor Dovecot, el servidor Courier IMAP y el servidor IMAP de la Universidad de Washington (UW-IMAP). Se escogió seguir con el servidor UW-IMAP.
Durante los días anteriores a la migración hubo un particular interés en instalar Cyrus como nuevo servidor de IMAP, debido a sus mecanismos de autenticación. De hecho, en el primer intento de migración se instaló el servidor, pero nos dimos cuenta entonces de la forma de almacenaje de Cyrus, que está diseñado para servidores que maneje cuentas de correo que no correspondan con una cuenta UNIX, lo cual sería adecuado si el laboratorio proveyera solamente cuentas de correo.
Se tomó en consideración también el servidor Dovecot para IMAP y POP, el cual es considerado por el autor, como un servidor compatible con los formatos de correo mbox y maildir y con los servidores UW-IMAP y Courier, pero escrito con la seguridad de datos como prioridad, debido a las técnicas de código que describen en la página.
Una ventaja importante con respecto a UW-IMAP es el hecho de que el CD de RHEL 4 trajera el RPM de Dovecot y no el de UW-IMAP, además de su compatibilidad con los formatos mbox y maildir, ya que existe interés en el laboratorio de evaluar el desempeño del servidor utilizando el formato maildir 1.
Sin embargo, tres serias desventajas previnieron la adopción de este servidor para ser utilizado. La primera de ellas tiene que ver con el directorio de acceso al correo, la segunda con el nombre del archivo que contiene las carpetas de IMAP de la cuenta, y la tercera con una capacidad de UW-IMAP tiene que Dovecot no posee todavía.
La primera fue el hecho de que mientras UW-IMAP permite acceso a todo el directorio home, y por defecto los correos guardados en la cuenta de una persona se almacenan en el directorio mail/, mientras que Dovecot accede por defecto al directorio /mail directamente, por lo tanto, la configuración actual de los clientes estaría orientada a entrar al directorio /mail/mail/, lo cual no sería correcto. Para poder completar una migración, habría que modificar todos los clientes de IMAP para que accedieran al directorio correcto. Dada la cantidad de usuarios que poseemos este procedimiento sería complicado.
La segunda desventaja tiene que ver con el nombre del archivo que contiene los nombres de las carpetas a las que accede la cuenta. En UW-IMAP este archivo se llama .mailboxlist mientras que en Dovecot se llama .suscriptions. Existen dos posibles arreglos para esto: uno es renombrar el archivo .mailboxlist a .suscriptions en todas las cuentas de usuario, y otro es modificar la definición de la macro SUBSCRIPTION_FILE_NAME en el directorio src/lib-storage/ subscription-file/subscription-file.c para la versión 0.9, lo cual obviamente implicaría meterse en el código fuente y cambiarlo.
La tercera desventaja tiene que ver con que UW-IMAP cuando detecta que existe el archivo /mbox, el servidor mueve todo el correo de /var/mail/$USER a ese archivo, una característica que no presenta Dovecot, y que según el documento de migración en [3], no se planea incorporar en un futuro cercano. En el laboratorio se conoce la existencia de varios usuarios que poseen este archivo en sus cuentas, razón final por la cual no se adoptó el uso de este servidor.
El servidor Courier IMAP se conoce por utilizar el formato maildir para el almacenamiento de correos. No fue evaluado realmente, por preferirse la utilización del formato mbox. Sin embargo, la evaluación del formato maildir queda pendiente para trabajo futuro.
La principal desventaja que presentó la adopción de este servidor fue que Red Hat quitó del CD de RHEL release 4 el RPM de UW-IMAP, lo cual obligó a buscar el RPM del release anterior de este sistema operativo. Se continuó con la utilización de este servidor debido a que se utilizan características que ofrece que no tienen otros servidores y, en particular, esta versión debido a los parches de seguridad y estabilidad que venían incluídos en ella.
En un pasado se utilizó el manejador de listas Majordomo, y por alguna razón desconocida se cambió a Mailman. Hoy en día Mailman es el manejador de listas más popular en la comunidad de software libre en Internet. Para esta migración se realizaron dos actividades: actualizar la versión de Mailman a 2.1.5, y dar a Mailman su propio servidor web, para separarlo del servidor web del portal, webmail y páginas de usuarios.
Es de notar que la actualización de Mailman tuvo un par de detalles que valen la pena resaltar, pues complicaron este proceso.
El día de la migración se siguió el orden de actividades presentado a continuación:
Este mensaje en los logs de correo es uno de los más comunes cuando Postfix no está bien configurado. La causa principal reside en que la máquina no tiene más direcciones para enviar el correo, pero no está configurado para ser receptor de ese correo. Se manifiesta en dos casos: cuando los registros MX de DNS para las máquinas no están configurados correctamente (digamos, por ejemplo, que la máquina foo.ldc.usb.ve tiene el registro MX puesto para que envíe a foo.ldc.usb.ve, y esa máquina no recibe correo para ldc.usb.ve, entonces la máquina descarta el correo y pone en su log el error de loops back to myself), caso improbable debido a que las máquinas del LDC ya están configuradas correctamente. El otro caso está cuando efectivamente en el archivo /etc/postfix/main.cf el parámetro mydestination no incluye el dominio para el cual debe recibir correos. En nuestro caso habíamos olvidado incluir la variable $mydomain como valor en ese parámetro.
La actualización de Mailman fue complicada debido a los problemas que se presentaron con el script de upgrade. El principal problema fue un error de pickling, un método de Python para guardar información de un objeto en un archivo. Fue necesario buscar un parche en Internet que pudiera arreglar este problema, que tenía que ver con la versión de pickling que se estuviese utilizando.
Debido a que se instaló la versión 2.1.5, fue necesario incluir un parche de seguridad para evitar un recorrido de directorios que se puede hacer a través de los CGIs de Mailman. El parche aplicado se puede conseguir en la página de seguridad de Mailman en [8].
Un problema que se presentó a la hora de actualizar fue uno relacionado con la lista cs que tenemos, correspondiente a la lista de profesores de computación. Por cuestiones de uso de directorios, se presume que en versiones anteriores el directorio /usr/lib/mailman/templates se utilizaba para guardar listas. Actualmente en este directorio se guardan las plantillas de las páginas de acceso público de las listas, y cs corresponde al idioma hablado en Serbia y Montenegro. Cuando se realizaba la actualización, este nombre hacía conflicto, haciendo que el script buscara una lista donde no lo había. El problema fue solucionado renombrando temporalmente el directorio /usr/lib/mailman/templates/cs y ejecutando el script de actualización.
Podemos afirmar que la migración del servidor de correo ha sido exitosa. Algunos usuarios (profesores) se quejaron de la interrupción del servicio extendida durante la migración (que fue de 7 horas), y se han presentado algunos problemas no fatales con algunas configuraciones. Pero, en general, estos problemas han sido resueltos rápidamente, y la impresión de los usuarios ha sido de una mejora en la velocidad de acceso al correo, y han estado colaboradores en reportar errores y advertencias del servidor.
Quedan pendientes algunos asuntos como la incorporación de SSL para el servidor, que serán resueltas en los días siguientes, pero la parte delicada del trabajo ha sido realizada. Espero que las tareas futuras que presento a continuación sean realizadas con el objetivo de mejorar el nivel de servicio del laboratorio.
Afortunadamente, la migración del servidor de correo ha generado mucho trabajo a futuro, que en algunos casos es importante realizar, y en otros vale la pena explorar:
Todas estas referencias fueron revisadas el 28 de junio de 2005.
This document was generated using the LaTeX2HTML translator Version 2002-2-1 (1.70)
Copyright © 1993, 1994, 1995, 1996,
Nikos Drakos,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999,
Ross Moore,
Mathematics Department, Macquarie University, Sydney.
The command line arguments were:
latex2html -split 0 correo-rudo.tex
The translation was initiated by LDC - Ciro Duran on 2005-06-29