A comienzos de 2003 teníamos un sistema de correo CriticalPath bajo Solaris x86 y una máquina Redhat para SMTP, Radius y DNS. Los servicios de DNS y Radius se caían constantemente y estábamos luchando con colas enormes de correo electrónico. Hubo un intento de instalar CriticalPath para Linux en Redhat en una máquina Intel con una tarjeta Megaraid, pero la latencia del disco era enorme y la aplicación de correo no llegó a funcionar.
El primer paso realizado hacia la “solución FreeBSD” consitió en migrar este hardware y software comercial a FreeBSD 4.8 con la ayuda de la emulación Linux.
El sistema operativo FreeBSD goza de una merecida fama de por su gran estabilidad, junto con su pragmatismo y sentido común a la hora de poner aplicaciones “on-line” gracias a su excelente colección de Ports. Nosotros consideramos su proceso de generación de releases muy sencillo de entender, además de que la comunidad de usuarios de las listas oficiales de correo electrónico mantiene un estilo educado y civilizado cuando ayudan o leen los problemas de otros usuarios y sus soluciones.
Otra característica importante es su rápida implantación. Afortunadamente pudimos establecer nuestra política de instalación de SO alrededor de las capacidades predefinidas de FreeBSD. En una compañía pequeña algunas veces necesitas ir corriendo a un centro de datos y rápidamente levantar un servidor para proporcionar algún servicio. En los dos últimos años, Argentina.Com adquirió alrededor de cuarenta servidores, la mayoría Pentium IV pero también varios Xeon duales y unos cuantos Opteron duales para ubicarlos en los centros de datos donde tenemos los contratos de operaciones de “hosting” y de acceso telefónico a redes. Todos ellos ejecutan FreeBSD, desde 4.8 (un par de ellos con dos años de “uptime” y cero problemas) hasta 6.0-BETA2.
La política general que tenemos para con el sistema operativo consiste en intentar llevar a todos los servidores a la rama de código estable de una forma periódica utilizando RELENG_4, RELENG_5 y ahora RELENG_6. Estas operaciones nos permiten estar más preparados ante posibles amenazas de seguridad a nivel del sistema operativo o del software base del mismo, especialmente en los servidores web.
El prime paso de reingeniería fue poner en funcionamiento dos máquinas FreeBSD 4.8 cuya única tarea iba a consistir en ser DNS autorizados para todos nuestros dominios. El software elegido resultó ser BIND9. Estas máquinas se ubicaron en diferentes centros de datos, cuidándonos de asegurar una buena latencia entre ellos para evitar problemas en transferencias de zonas, haciendo posible tratar con TTLs entre 60 y 600 segundos para así poseer unos mejores márgenes de reacción en caso de problemas.
El segundo paso consistió en desplegar dos máquinas más del mismo tipo, también en distintos centros de datos, para sólo servir Radius y DNS recursivo. Los servidores de acceso de red (“Network Access Servers” o NAS) de los operadores de telecomunicaciones se configuraron para enviar las peticiones de autorizació y “accounting” de Radius hacia los nuestros, y también para asignar dichos DNS recursivos a nuestros usuarios de acceso telefónico.
La tercera “regla de oro” consiste en no poner jamás en la misma máquina el servicio de entrada y salida de correo SMTP. Desplegamos máquinas FreeBSD distintas utilizando Postfix tanto para la entrada como para la salida.
La migración del correo requería una planificación cuidadosa debido al hecho de que íbamos a a migrar tanto los frontales como los “backends”. El primer paso fue construir un sistema perimetral antispam y antivirus con FreeBSD 4.x y 5.x basado en postfix, amavisd-new, clamav y SpamAssassin. Estos sistemas iban a entregar correos tanto a los antiguos sistemas como a los nuevos hasta que el nuevo “backend” estuviera en funcionamiento. Entre tanto añadimos pequeñas máquinas FreeBSD para incrementar el “spool” de correo de CriticalPath sin ningún problema.
En la primera línea de la entrada de correo pusimos varios MX del dominio Argentina.com para filtrar ataques de diccionario (intentos de reenviar correo a usuarios no existentes) además de una lista negra derivada de SURBL que resultó no dar casi ningún falso positivo. Los correos eran multiplexados hacia un cluster de Xeon duales y Opteron duales donde ejecutábamos amavisd-new junto con un filtrado basado en listas blancas y negras basado en MySQL. Descartamos el uso de Bayes y Autowhitelisting en un nivel global debido a las grandes cantidades de falsos positivos y de falsos negativos que proporcionaban. En su lugar definimos unos cuantos niveles de spam de menos a más tolerante, cada uno con niveles de corte y de descarte. A cada correo electrónico recibido el sistema le asigna una determinada puntuación. Los correos con una puntuación por debajo de la puntuación asociada con el nivel de corte establecido por el nivel de spam pueden continuar hasta la bandeja de entrada del usuario. Los correos entre el nivel de corte y el nivel de descarte se envían a una carpeta del usuario denominada Spam, y por último aquellos correos por encima del nivel de corte se descartan porque se considera una situación muy evidente de spam. En aras de la simplicidad, se asocian de forma transparente los correos almacenados en la libreta de direcciones con el sistema antispam, colocándolos en las “listas blancas” de forma automática.
Con la introducción de Spamassassin 3.x, el tráfico de DNS utilizado para preguntar a las listas negras de correo creció considerablemente, de tal forma que firmamos acuerdos con SpamCop, Spamhaus y SURBL para instalar réplicas públicas de sus bases de datos en nuestro equipo FreeBSD. Gracias a estas réplicas, que nos costaron entre 1 y 2Mbps de tráfico, fuimos capaces de reducir drásticamente la latencia de Spamassassin.
En un tercer nivel nos encontramos con la entrega a los buzones de correo de los usuarios. Tan pronto como nos pusimos a contruir el nuevo “backend” Cyrus-Imap con autentificación MySQL, nos dimos cuenta de que necesitábamos multiplexar el correo de entrada a los usuarios en los formatos de los buzones nuevos y antiguos. Finalmente, conseguimos migrar cientos de miles de correos hacia la nueva arquitectura Cyrus utilizando una fenomenal herramienta denominada imapsync, que se puede instalar directamente desde los ports. También instalamos perdition (un proxy de POP3 y de IMAP) entre medias para asegurar una migraci´n transparente y permitir la distribución entre distintos servidores de los buzones. En resumen, toda la información de localización de un buzón de usuario está en MySQL, y dicha información se encuentra disponible para todo el software que forma parte de la cadena.
Respecto al hardware para el espacio de disco, actualmente utilizamos siete máquinas FreeBSD con Cyrus-Imap de distinto hardware. El mayor es un Pentium IV con 4G de RAM y tarjetas 3ware con 12 bahías extraíbles en caliente, organizadas en 3 unidades RAID-5 de 1 Terabyte cada una. El software 3ware envía un correo electrónico al administrador cuando el RAID se degrada (en la mayoría de los casos se trata de errores de disco) y es posible reconstruir el RAID con el sistema a pleno rendimiento. Utilizamos smartmontools en los casos en los que hay menor redundancia, para disponer inmediatamente de alertas de discos con problemas de temperatura o de fallos de “selftests”.
Como software de correo web elegimos un producto comercial denominado Atmail, disponible con sus fuentes en perl y que utiliza mod_perl. Bajo FreeBSD resulta extremadamente sencillo gestionar los módulos de perl y no es necesario usar la “shell” de CPAN; únicamente hay que seleccionar el port correcto y ejecutar “make install”. Tras varios meses de trabajo de integración pudimos integrar la parte cliente de Atmail que habla IMAP con nuestros “backends”. Tuvimos que modificar algunas partes del código para adaptar el producto a nuestro entorno libre y para hacerlo compatible con nuestro perímetro antispam antivirus, además de aplicar nuestras personalizaciones y traducciones.
Con la adopción de FreeBSD no hubo que realizar ningún esfuerzo adicional para tener en ejecució en cuestion de minutos los entornos de Apache, PHP y MySQL. Incluso las actualizaciones de PHP4 a PHP5 se efectuaron sin problemas. El sistema de ports nos resultó una vez más extremadamente útil y nos permitió hacer cosas como comprimir los contenidos de texto y de html de Apache utilizando unas pocas líneas de documentación. Además, hemos experimentado un rendimiento excelente y una estabilidad y “uptimes” extraordinarios.
Puede descargar éste y muchos otros documentos desde ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
Si tiene dudas sobre FreeBSD consulte la documentación antes de escribir a la lista
<questions@FreeBSD.org>.
Envíe sus preguntas sobre la documentación a <doc@FreeBSD.org>.