• Publicaciones
• Boletín

Félix Sánchez

Resumen

En este trabajo se presenta una migración para una estafeta de correo que use las herramientas tradicionales: Sendmail (como MTA) y Qpopper (como servidor de MUAs distribuidos), de manera que pueda leer las tablas necesarias en un servidor LDAP. Se hace especial énfasis en el uso combinado de Sendmail- LDAP, dado que, normalmente, los MUAs (sea un servidor de POP o IMAP, o mailers locales) son únicos. Sin embargo la configuración de servidores SMTP, especialmente en el modelo propuesto de RedIRIS (central, más un secundario si existe, y otras de niveles inferiores), pueden compartir muchas tablas, que de la manera tradicional debe ser replicada en cada nodo. Con este modelo cada estafeta toma el mapa que necesite de un servidor LDAP que centraliza esta información.

Palabras clave: LDAP, Sendmail, SCEDir, Servidor POP, SMTP

Summary

In this paper is shown the migration process for a mail server which uses the stardard tools: Sendmail (as MTA) and Qpopper (as splited MUA server); so that such server can read the map it needs from an LDAP server. We make special emphasys in the combination Sendmail-LDAP, since MUAs (whether POP or IMAP server, or local mailer) need no replication. But when configuring SMTP servers, in particular those following RedIRIS model (central server, plus secondary if any, and another in lower levels), may share a lot of information, which in the usual way must be repeated in each server. With this model every mail server takes the map it needs from an LDAP server in which information is centralized.

Keywords: LDAP, Sendmail, SCEDir, POP Server, SMTP

1.- Cuestiones previas

1.1.- ¿Porqué el modelo Sendmail-LDAP?

Uno de los objetivos que teníamos marcados en el CICA a medio plazo era la unificación de los passwords de los distintos servicios: correo, acceso remoto (servidor de radius), PAPI (una primera consulta está en: http://www.rediris.es/app/papi/dist/AuthServer.html), y (si fuese el caso) el servicio de supercomputación.

El verano negro de virus y ataques al correo nos obligó a hacer un upgrade de la versión de Sendmail para poder aplicar las soluciones que se había propuesto para frenar estos problemas. Este upgrade de una de las piezas del motor de la estafeta provocó el ya conocido "efecto dominó" de tener que hacer upgrades consecutivos de las otras partes de la mensajería, una de ellas fue el servidor POP. Era la oportunidad de "oro" para desplazar la base de datos de los usuarios de POP a LDAP.

Así lo hicimos. Pero quedaba un fleco que nos parecía poco elegante: nuestro Sendmail tiene (como es común en nuestro entorno) el control de acceso basado en el destinatario. Ello implicaría que, además de la base de datos de usuarios centralizada en LDAP, con un primer uso de comprobación de passwords, nos veríamos obligados a mantener un "mapa" de usuarios en cada una de las estafetas, para uso de cada uno de los Sendmails. Es decir, había que dejar el sistema, en parte, tal como se estaba. El avance parecía "pobre". El objetivo estaba claro: había que "enseñar" a Sendmail a leer del LDAP esa información.

1.2.- ¿Qué hay disponible?

El primer documento que se encuentra al buscar la relación deseada "Sendmail-LDAP" es el debido a Booker Bense, de la Universidad de Stanford (http://www.stanford.edu/~bbense/Inst.html). Este documento da una líneas generales de cómo construir el sistema, pero es bastante parco en ofrecer un camino a seguir. Esto nos parecía una solución bastante incompleta, ya que uno de nuestros objetivos era huir de soluciones demasiado "caseras", de manera que nuestro trabajo pudiese ser usado por otros, y sobre todo, fuese un sistema estable frente a futuros avances y necesidades. Pero su virtud principal para nosotros era saber que era posible, y se había conseguido. Otro documento que ofrece información al interesado en la integración "LDAP implementation HOWTO", (http://www.linuxdoc.org/HOWTO/LDAP-Implementation-HOWTO/sendmail.html ) que en su apartado 6 habla de los MTAs con secciones para Sendmail, Postfix, y Qmail. Es un documento que habla de definiciones, y está bastante más en el plano "teórico" que en el de los "howto" que solemos encontrar, que a veces llegan a ser auténticos recetarios con descripciones paso a paso.

El siguiente documento que se puede encontrar al buscar la relación entre ambas aplicaciones sea el "Sendmail+LDAP Howto" (http://www.iconimaging.net/~jradford/sendmail/sendmail-ldap.html), de Jason Radford de IconImaging. Este documento está escrito pensando en el routing de correo para una intranet, y como tal usa el draft de la IETF llamado LASER. Dicho draft fue desechado, pero se puede encontrar una copia de la propuesta todavía en las páginas de Mr. Radford (http://www.iconimaging.net/~jradford/sendmail/laser.txt). En ese draft se definía la clase de objetos que sería necesaria, así como los atributos respectivos, y hace una llamada a que pueden ser usados en una red privada, pero no en el Internet público. Aún así este "howto" era lo suficientemente clarificador para haberse puesto a trabajar sobre él, y definir un fichero de esquema para LDAP con el que nuestro Sendmail se hubiera "hablado". Pero, resulta que ¡ya existía el proyecto SCEDir!

1.3.- Proyecto SCEDir

Dentro de los PTYOC (http://www.RedIRIS.es/app/ptyoc/) que desarrolla RedIRIS, Javier Domínguez de la ESI Informática de la US, estaba trabajando en un proyecto fin de carrera bajo la dirección de D. R.

López y tutorado por Manuel Valencia, cuyo objetivo era la definición de un sistema tal y como nosotros buscábamos. Y, además, como valor añadido, desde su concepción original contemplaba las distintas particularidades que el modelo de estafetas que propone RedIRIS (http://www.rediris.es/mail/estafeta.es.html). Sus características principales son:

A) Propone un fichero de esquema que contempla la totalidad de los mapas que, en general, usamos en este entorno. Dicho fichero propone unos OIDs para los atributos y para las clases que pueden ser integrados en servidores LDAP en funcionamiento, dado que el numérico de dichos OIDs es imposible que coincida con alguna definición local, si se han seguido las recomendaciones de IANA, ya que pertenecen a los reservados a RedIRIS .

B) Propone, asimismo, formato para los ficheros LDIF con que importar los datos de los distintos mapas de Sendmail. Esto clarifica bastante el trabajo a seguir para la migración.

C) También ofrece una herramientas de "traducción" del fichero de mapas de Sendmail al formato LDIF, que en nuestro caso, preferimos no usar, y desarrollar procedimientos propios, dado que es un paso que solo hay que hacer una vez, y preferíamos tener mayor control en este punto.

D) Una característica que valoramos especialmente, fue la posibilidad de hacer búsquedas secuenciales del mapa de aliases: primero un mapa local en formato estándar, después uno o más de las tablas de LDAP. Esta característica es especialmente importante en muchas estafetas. Así pues, el grueso del trabajo parecía estar hecho. Pero fue sólo gracias a que el proyecto está basado, y cumple, las normas de software abierto que pudimos comprender qué hace en cada momento, cómo y con qué elementos. Porque al tratarse de un sistema que se desarrollaba en esos momentos, a veces había que corregir o sintonizar algunos detalles, que en la versión definitiva del proyecto creemos que están bien.

2.- Puesta en marcha del sistema

2.1.- ¿Qué teníamos?

El objeto fundamental de los cambios estaba en el servidor de correo primario, cuyas características son básicamente las siguientes: un biprocesador SPARC 1000E con 256 Mb, cinco interfaces SBUS SCSI, 18GB en discos (que hubo que aumentar a 31 durante el proceso de actualización por razones ajenas al mismo: simple crecimiento del servicio), 18.000 usuarios directos, dominios virtuales de dos tipos diferentes, servidor SMTP, POP y secundario de DNS. En definitiva, una máquina muy vieja y muy saturada.

El servidor secundario, que también tiene un servidor de listas, es un clon de SUN (Axil) también bastante antiguo. Ambas máquinas, porque la versión 8 de Solaris no soporta parte de la configuración física, están en Solaris 7. Hay que decir en este punto que la documentación que disponemos sobre Solaris 8, y lo que hemos visto en otras máquinas que pudieron ser actualizadas a dicha versión, que la integración del S.O. con PAM y con LDAP parece más consistente que en la versión 7. Pero, los módulos correspondientes son enteramente "propietarios", y es difícil saber si dicha integración es extensible a un servidor LDAP externo a Solaris, como es nuestro caso, que lo tenemos basado en un OpenLDAP.

Las pruebas se realizaron sobre PC con Linux. Ello implica que tras cada prueba había un "salto en el vacío" dadas las claras diferencias que entre un S.O. y otro hay. Especialmente cuando mucha de la documentación generada, incluso en el caso del proyecto SCEDir, está pensada casi únicamente para este S.O., y ya sabemos que Solaris tiene un comportamiento ligeramente diferente.

Tras las primeras pruebas en Linux, el siguiente paso era integrar los cambios en el SMTP secundario, y finalmente en la estafeta central.

2.2.- Pasos

Dado que el primer paso fue la integración de los usuarios de POP en LDAP, vamos a describir este paso brevemente. Esta integración está bien documentada para los casos de Linux, pero para el caso de Solaris, si queremos usar el software de libre distribución, lo primero que debemos hacer es desinstalar las posibles librerías LDAP que el sistema haya puesto, que en una instalación estándar las suele colocar.

El software necesario para que la consulta de passwords de POP se haga mediante LDAP emplea el mecanismo NSS, y PAM. Por tanto es necesario buscar unas librerías que nos permitan estos pasos. La solución que encontramos estaba en www.padl.com, ahí encontramos las librerías pam_ldap y nss_pam, que nos conectan los distintos pasos necesarios. Esta última instala un fichero donde se le especifican los datos de búsqueda en LDAP: servidor, puerto, atributo, etc., mediante los que el servidor POP hace la autentificación.

Si se desea caminar hacia una integración de servicios, debemos llamar la atención en este punto al hecho de que las entradas de cada usuario sean lo suficientemente flexibles como para admitir estos distintos servicios. Dicho de otro modo, cada entrada de usuario necesita campos que definan los distintos servicios (¿distintos objectClass?): puede ser de correo, pero no tener derecho a acceso remoto, y ser usuario de PAPI (en este caso el objectClass del tipo papiUser necesita estar definido), y para este caso nosotros definimos también un grupo de recursos al que el usuario tiene acceso (le ponemos un atributo del tipo papiGroupId con uno de nuestros grupos de servicios). Si no se planifica previamente nos vemos obligados a rehacer toda la tabla de usuarios cuando se quiera integrar un servicio.

El siguiente paso es hacer que Sendmail lea los mapas vía LDAP. Para ello lo primero es compilarlo de manera que admita dichos mapas de LDAP, esto se hace creando un fichero (desde la raíz del fuente de Sendmail)/devtools/Site/site.config.m4 que contenga las siguientes líneas:

Una vez compilado se puede comprobar que admite mapas de LDAP mediante el comando: Sendmail -d0.1 -Bb. roto que nos debe indicar que Sendmail es capaz de consultar LDAP para los mapas. Ahora hay que poner el fichero "scedir.schema" en el servidor LDAP. Este fichero puede ser obtenido en la página de SCEDir en sourceforge (http://scedir.sourceforge.net/). Para que lo admita el servidor LDAP, además de ponerlo en su lugar oportuno, hay que incluirlo en el fichero de configuración "slapd.conf". Podemos comprobar que el servidor LDAP ya admite las definiciones de SCEDir mediante una consulta con gq, para ver si las clases y atributos son admitidas.

El siguiente paso es traducir la información que está contenida en los ficheros de mapas locales a ficheros LDIF que podamos incluir en el servidor LDAP. Aquí hemos preferido desarrollar herramientas locales que nos hagan dicho paso, y que, básicamente constituyen procedimientos de comandos con "grep" y "awk" que, en una versión sencilla podrían tener este aspecto:

Y con el producto de haber ejecutado un procedimiento de este tipo, volcando su salida a un fichero que llamamos authto.ldif, basta con importar dicho fichero mediante un ldapadd. En este punto ya tenemos un Sendmail que sabría leer tablas vía LDAP, y unas tablas que están llenas del contenido que queremos. Queda configurarlo apropiadamente para que el sistema funcionase. Para ello vale la estructura del directorio "./cf" que propone RedIRIS, e incluir en nuestro fichero de configuración (fichero-mc, ver el README correspondiente, que se encuentra en: ftp://ftp.rediris.es/rediris/e-mail/software/iriscf/iriscf-4.2.tar.gz) las siguientes líneas, atención al orden:

O cualquier variante de los parámetros correspondientes, además del resto de FEATURES, y elementos necesarios para configurar la estafeta. Se crea el fichero de configuración mediante el comando correspondiente (ver README aludido). Una manera de comprobar que este Sendmail lee bien, y que sus valores corresponden a lo que deseamos es, por ejemplo:

El sistema está entonces listo para ser puesto en producción, se ha terminado la fase de instalación, queda ajustarlo.

3.- Problemas de sintonización

Hay que llamar la atención sobre algunos aspectos que pueden ayudar a mejorar la productividad del sistema, o incluso a evitar que pueda llegar a ser un desastre.

Indexación. Si las tablas de LDAP no están correctamente indexadas todo el mecanismo puede llegar a ser imposible de implementar. Nuestra primera experiencia, sin indexación y luego con una indexación incorrecta hacía que el servidor de POP acumulara tal número de peticiones a LDAP que hacía que la carga del sistema llegase a estar por encima de valores 25-28. Ello significaba varias cosas: timeouts a los clientes de POP, o en otros casos respuestas del tipo "password inválido"; al convivir el servidor de POP y SMTP, al alcanzar dichos niveles de carga, Sendmail empezaba a rechazar conexiones. Esta misma experiencia con una mala indexación se puede repetir con las otras tablas de Sendmail para un servidor SMTP con alta actividad.

Es decir, en la distribución estándar de openLDAP, el fichero de configuración "slapd.conf" contiene por defecto una línea parecida a: index objectClass eq que indica que indexaremos por "objectClass", exclusivamente. Para el caso de un servidor de POP que busque a los usuarios por el atributo "uid", esta línea debe ser parecida a: index objectClass,uid eq y posteriormente indexar LDAP mediante el comando "slapindex".

Parámetros de TCP. Los parámetros de TCP pueden llegar a jugar un papel importante en el conjunto del sistema. Al estar operando con S.O. diferentes (correo sobre Solaris, LDAP sobre Linux), las conexiones no se cerraban todo lo bien que cabría esperar, dejando unas conexiones en estado "TIME_WAIT" con latencias altas, creando interferencias en el funcionamiento de ambas máquinas. Esto puede ser debido a varios factores, que van desde los programas en sí mismos (Sendmail y LDAP), a los sistemas operativos, y, por supuesto, a los posibles routers, concentradores, etc., que pueda haber por medio.

En este caso, nuestra opción fue minimizar los "hops" entre los nodos más activos (servidores SMTP/POP primario y LDAP). Y después, mediante un ajuste por el método de prueba y error, sintonizar las máquinas para rebajar dichos tiempos. Esto se hace en Solaris mediante el comando "ndd", y en linux mediante el comando "sysctl", con unas líneas parecidas a:

4.- Cuestiones en desarrollo y abiertas a otras contribuciones

Estas propuestas no pretenden ser exhaustivas, sino dar una orientación de algunas posibilidades de por donde se puede seguir trabajando en esta línea, que queda abierta a mucho más de lo aquí expuesto.

Primero
En el momento actual se está trabajando en una réplica de la página del configurador del Sendmail que tiene RedIRIS (http://www.rediris.es/mail/generador/sendconf.es.html). Esta página debería contener los siguiente, al menos: a) Una pregunta inicial si los mapas residen en ficheros locales, o serán consultados vía LDAP. b) Si se opta por LDAP, la siguiente pregunta es el nombre y puerto del servidor, así como el "dn:" del que colgarán los mapas. c) El siguiente paso en común, sea cual sea la opción elegida en "a)", es un página como la actual, donde realmente se configura el Sendmail a la medida de las necesidades de la organización. Si se optó por ficheros locales, este es el último paso. d) Si se optó por LDAP, además de poder ver y/o descargar la configuración, se debe de poder ver y/o descargar una propuesta "genérica" de los mapas necesarios (en formato LDIF) para el servidor LDAP.

Cada organización tiene que llenar estos ficheros LDIF genéricos que se proponen con los datos propios de dicha organización. También debe de preguntar si se desea descargar el fichero "scedir.schema", necesario para el servidor LDAP.

Segundo
Una prolongación casi natural de la primera propuesta es crear una página que pudiese tomar los mapas en formato fichero tradicional de una organización y automatizar el cambio a un formato LDIF. Esto, sin ser propiamente algo de correo o Sendmail, ya que corresponde al "ldapmanager", facilitaría bastante el paso "d)" de la primera propuesta.

Tercero
Habría que rescribir en parte la documentación (fichero README, vid supra) que acompaña a la distribución de la estructura de configuración de Sendmail de RedIRIS, que sirve como apoyo a la página de autoconfiguración (http://www.rediris.es/mail/generador/doc/help-gen.es.html). Si bien dentro del proyecto SCDir hay un primer borrador, consideramos que hay que ampliar el nivel de detalle en algunos puntos.

Cuarto
Sería deseable la creación de un "repositorio nacional" de algunos mapas, como el de "authto" donde se contengan las "listas negras" de organizaciones emisoras de spam. Las entradas de dichas tablas podrían tener campos descriptivos como: fecha de alta, motivo, etc.. Este repositorio puede difundirse (slurpd?) fácilmente entre el resto de organizaciones, que pueden optar por adoptarlo con la tabla propia integra, parcialmente, o no integrarla. Esto sería una primera integración con el proyecto PUAs que actualmente se está desarrollando de una manera paralela.