Zimbra 5, suite de mensajería y colaboración

Transcripción

1 Zimbra 5, suite de mensajería y colaboración Por Jaume Sabater, publicado el 1 de octubre de Artículo distribuido bajo licencia Creative Commons by-nc-sa. Índice Introducción Arquitectura Componentes de la arquitectura 1. Zimbra Core 2. Zimbra LDAP 3. Zimbra MTA 4. Zimbra Store 5. Zimbra SNMP y Zimbra Logger El cliente web El servidor Zimbra Network Edition Requerimientos Seguridad Instalación en Debian Etch Mejoras en el sistema antispam Whitelisting Instalaciones distribuidas (multiservidor) Instalación de un sistema multiservidor 1. Instalación de LDAP, SNMP y Proxy 2. Instalación de Store, Logger y Spell 3. Instalación de Zimbra MTA 4. Ajustes finales Problemas con Zimbra Logger Uso de memoria RAM y swap Bibliografía Historial de revisiones Introducción Zimbra Collaboration Suite (ZCS) es una innovadora suite de mensajería y colaboración de código abierto. Se ofrece bajo la licencia Yahoo! Public License (YPL), versión 1.1, en forma de una versión de código abierto, sin coste de licencias alguno, y otra versión de pago con varios componentes extras de código cerrado y con coste de licencias. Está disponible para diversas plataformas y distribuciones de Linux y para MacOS X. En muy poco tiempo, Zimbra se ha convertido en la solución de código abierto líder a nivel mundial tanto para empresas como para proveedores de servicio, centros educativos y administraciones públicas. La clave de este éxito se basa en el uso de tecnologías de código abierto y protocolos de comunicación e intercambio de datos estándares y ya consolidados, que han combinado de manera adecuada y completado con características que no estaban cubiertas pero que son claves para las empresas. Una completa documentación y un amplio abanico de comandos de consola específicos dotan a esta suite de enormes capacidades de integración con entornos existentes. Cuatro son los pilares de la arquitectura del producto: Flexibilidad: fácil personalización según las necesidades de la organización. Libertad: uso de cualquier navegador web y de aplicaciones de escritorio tradicionales. Durabilidad: servidor de correo electrónico y calendario extraordinariamente fiable y ampliable. Bajo coste de mantenimiento: gestión muy sencilla, tanto mediante una interfaz gráfica como desde la consola. ZCS se divide en tres módulos principales: Cliente web. Servidor. 1 de 20 21/08/11 14:23

2 Extras. A continuación se explicarán las características de la Open Source Edition de Zimbra para pasar luego a añadir aquellas propias únicamente de las versiones de pago. Arquitectura Zimbra Collaboration Suite está formada por un conjunto de componentes que trabajan juntos para formar una solución completa. El núcleo del servidor está escrito en Java, utilizándose Jetty como servidor de aplicaciones. El servidor se integra con otros sistemas como el MTA, la base de datos y los paquetes de seguridad. El agente de transferencia de correos (del inglés, Mail Transfer Agent o MTA) enruta los mensajes de correo al servidor de Zimbra. Este servicio está basado en el popular Postfix. Integrado a través de Postfix, Zimbra incorpora varios filtros de seguridad, como antivirus y antispam, entre otros. Asimismo, el MTA puede integrarse con otras tecnologías, como Postgrey para greylisting o Spamhaus para DNSBL, u otras soluciones de seguridad comerciales, como los AV/AS de Barracuda Networks. Asimismo, soporta por defecto los protocolos principales de cifrado de canal, SSL y TLS. Los filtros en el lado del servidor mediante James/Sieve le ponen la guinda al pastel. También incluido en Zimbra Collaboration Suite hay diversos almacenes de datos para la información de los usuarios: OpenLDAP proporciona la autenticación, MySQL guarda las preferencias y metadatos de los mensajes y el sistema de ficheros guarda directamente los mensajes de correo. Otro componente integrado en Zimbra es Lucene, un potente motor de indexación y búsquedas que permite a los usuarios y administradores buscar mensajes a través de múltiples carpetas de correo, tanto metadatos como contenidos en el cuerpo del mensaje. 2 de 20 21/08/11 14:23

3 En términos generales, las funcionalidades ofrecidas por Zimbra son muy similares a las de Microsoft Exchange, aunque está mejor preparado para ser utilizado por proveedores de hosting y tiene algunas características de colaboración que Exchange no tiene. Además, una gran diferencia la marcan los bindings de SOAP que permiten integraciones de terceros que amplien las funcionalidades de Zimbra. Componentes de la arquitectura La arquitectura del sistema está formada por los siguientes componentes: Zimbra Core Zimbra Core incluye las librerías, utilidades, herramientas de monitorización y ficheros básicos de configuración. Zimbra LDAP 3 de 20 21/08/11 14:23

4 Dada la gran diversidad de servicios y aplicaciones asociadas a los servicios de que suele disponerse hoy en día, tener un directorio de usuarios basado en LDAP es, de cada vez más, una necesidad. Zimbra Collaboration Suite utiliza por defecto OpenLDAP para almacenar y gestionar el almacén de usuarios, integrando de serie el soporte para la replicación. Además, permite fácilmente su configuración para el uso de directorios LDAP externos, incluyendo Active Directory de Microsoft o edirectory de Novell, entre otros. El esquema LDAP de Zimbra está disponible por si deseamos utilizarlo en una instalación LDAP ya existente, facilitando de esta manera la gestión centralizada de las cuentas de usuario de nuestra instalación. Cada cuenta tiene un identificador único de buzón de correo, que representa el punto principal de identificación en todo el sistema. El esquema de OpenLDAP ha sido modificado para adaptarlo a las necesidades de ZCS. Zimbra MTA Uno de los componentes claves de cualquier solución de mensajería hoy en día, el servidor de correo electrónico de Zimbra está formado, como es habitual, de diversas partes: Un MTA (del inglés, Mail Transport Agent). Un almacén de buzones de correo accesible por IMAP4 y POP3, con soporte para cifrado del canal mediante (SSL). Unos filtros de contenidos (antivirus y antispam). Zimbra utiliza Amavis como filtro de contenidos y, por defecto, SpamAssassin y ClamAV como filtros antispam y antivirus, respectivamente. De todos modos, es posible configurarlo para que utilice cualquier otro filtro antispam, como Dspam, o antivirus. El correo se recibe mediante SMTP, se enruta mediante una tabla de transportes y se entrega al almacén de correo haciendo uso del protocolo LMTP. Zimbra Store Zimbra Store, utilizando Jetty como contenedor de servlets, almacena el correo electrónico. Cada cuenta se configura en un servidor, y esta cuenta está asociada con un buzón de correo que contiene todos los mensajes y ficheros adjuntos. El servidor de buzones está formado por: El almacén de datos. El almacén de mensajes. El almacén de índices. Las utilidades de conversión de adjuntos a HTML. Cada servidor de Zimbra tiene su propio almacén de datos, almacén de mensajes y almacén de índices para los buzones de ese servidor. En cuanto llega un correo, el servidor de Zimbra crea un nuevo proceso para indexar el mensaje. También se crea un hilo para la conversión de adjuntos a formato HTML, que a su vez es indexado por otro hilo. El almacén de datos es una base de datos MySQL en la cual los los identificadores de mensajes son enlazados con las cuentas de usuario. El almacén de datos relaciona el identificador del buzón con la cuenta de usuario a la que pertenece en el directorio LDAP. Esta base de datos contiene el conjunto de etiquetas definido por el usuario, las carpetas, las citas del calendario y los contactos de los usuarios, así como el estado de cada mensaje de correo (leídos, no leídos, etiquetas asociadas a cada mensaje y la carpeta en la cual reside el mensaje). El almacén de mensajes guarda todos los mensajes y sus adjuntos en formato MIME (del inglés, Multipart Internet Mail Extension). Los mensajes enviados a múltiples destinatarios dentro del mismo servidor sólo son almacenados una vez. La tecnología necesaria para indexar y buscar la proporciona Lucene. Se mantienen índices sobre cada buzón. Zimbra SNMP y Zimbra Logger La instalación de ambos paquetes es opcional, pero muy recomendada. En cada servidor donde esté instalado, Zimbra SNMP recoge información periódica del estado del sistema. Además, utiliza Swatch para analizar la salida del syslog y generar los traps de SNMP. Por su parte, Zimbra Logger instala herramientas de agregación de logs, informes y seguimiento de mensajes. Sin este paquete no se podrán utilizar las funcionalidades de seguimiento de mensajes y estadísticas del servidor de la consola gráfica de administracion. 4 de 20 21/08/11 14:23

5 El cliente web Zimbra incorpora un cliente web que hace un uso extensivo de AJAX (del inglés, Asynchronous Javascript and XML) y que se ejecuta en la mayoría de los navegadores web más habituales, como Firefox, Safari e Internet Explorer. Debido al uso intensivo de Javascript, las diferencias en la experiencia del usuario son enormes dependiendo del navegador, siendo Opera y Safari los mejores e Internet Explorer 6 el peor. En cualquier caso, el cliente web de Zimbra permite utilizar una versión sólo con HTML que es muy recomendable para equipos antiguos pero que, asimismo, ofrece una usabilidad muy buena. El cliente web de Zimbra ofrece unas avanzadas funcionalidades, casi al mismo nivel que una aplicación de escritorio, pero con la ventaja de poder utilizarlo desde cualquier lugar y desde casi cualquier navegador. Su gestor de correo permite, entre otros: Agrupar los correos por conversación, ahorrando así espacio en la pantalla. Construir, de manera gráfica, búsquedas avanzadas y guardarlas para su posterior reutilización. Etiquetar contenidos. Ver documentos adjuntos sin necesitar ninguna aplicación externa. La gestión de contactos de Zimbra es muy completa, ya que soporta múltiples libretas de direcciones (tanto personales como de cuentas del sistema), compartición de contactos, autocompletado y creación de listas de distribución personales. El calendario compartido es una de las características más destacadas de Zimbra, con capacidad para detectar, visualizar y corregir solapamientos. Permite gestión de recursos (salas de reuniones, proyectores, etc.), programación de reuniones en grupo con delegación del aceso, compartición y publicación del calendario con otros usuarios y suscripción a calendarios remotos en formato ical. Zimbra incorpora una gestión documental en línea. Mediante una interfaz WYSIWYG es posible crear documentos en un formato de texto tipo RTF a los que adjuntar, por ejemplo, hojas de cálculo o imágenes mediante la tecnología ALE (del inglés, AJAX L nking and Embedding). Esta gestión documental puede adquirir la forma de un wiki, permitiendo que los documentos sean creados, actualizados y compartidos entre todos los usuarios. La publicación y compartición de contenidos es homogénea en todo el sistema tanto para contactos, como para el calendario o los documentos. Esta compartición puede realizarse con usuarios internos y externos del sistema. El cliente de correo permite la gestión de varias identidades y de varias cuentas de correo, incluyendo la agregación de cuentas externas mediante POP3. La gestión unificada de los mensajes permite una fácil integración con sistemas de telefonía de voz sobre IP para llamadas, conferencias y acceso a buzones de voz. Esto se consigue mediante Zimlets, un potente sistema de Zimbra para extender sus capacidades mediante plug-ins y permitir la integración con otros softwares externos mediante el uso de SOAP y Web 5 de 20 21/08/11 14:23

6 Services. Otros ejemplos de integraciones son Yahoo Maps, traductores de idiomas o consultas a bases de datos de la empresa (por ejemplo de un CRM o un ERP). Zimbra permite personalizar el entorno, incluyendo soporte para temas y una versión sólo HTML para aquellos PCs antiguos o entornos que no puedan hacer uso de Javascript. Además permite la personalización de logos, textos y mensajes (en inglés, branding). El servidor Zimbra Zimbra Server (o Zimbra Store) es el núcleo de Zimbra Collaboration Suite. Está diseñado sobre una arquitectura extremadamente estable y modular usando tecnologías de código abierto contrastadas. Este servidor incluye soporte para multitud de protocolos estándares que le permiten interactuar con los clientes de software más populares. El servidor de Zimbra empaqueta todos los componentes principales en un simple instalador y utiliza, entre otras, tecnologías como Linux, Jetty, Postfix, MySQL, OpenLDAP y Lucene y soporta, entre otros, protocolos tales como SMTP, LMTP, SOAP, XML, IMAP, POP, ical y CalDAV. Zimbra es un servidor muy rápido y eficiente que, además, permite escalar de manera horizontal, pues cada host incluye su propio almacén de buzones de correo y de datos de configuración. Zimbra puede crecer añadiendo más máquinas con subdominios diferentes y mantener una gestión centralizada dentro del mismo dominio principal. Zimbra, por supuesto, soporta múltiples dominios y también perfiles de usuarios, que denomina COS (del inglés, Class Of Service). En estas clases de servicio se pueden definir las cuotas de almacenamiento y las características a las cuales tendrán acceso los usuarios. La siguiente lista presenta las más destacadas en su versión actual: Correo electrónico. Libreta de direcciones. Calendario de citas. Tareas. Documentos. Maletín. Mensajería instantánea. Preferencias. Etiquetado. Compartición. Cambio de contraseña. Elección de tema. Redacción de correos en formato HTML. Atajos de teclado. Acceso al Global Address List (GAL). 6 de 20 21/08/11 14:23

7 Acceso externo por IMAP4/POP3. Creación de una dirección de reenvío automático del correo. Creación de una respuesta automática a la recepción de correos. Filtros de correo. Gestión de calendarios de grupos. Búsquedas avanzadas. Guardar búsquedas. Network Edition En su versión Network Edition, Zimbra incluye toda una serie de características añadidas respecto de la Open Source Edition, como la alta disponibilidad mediante clustering y journaling a nivel de aplicación, las copias de seguridad incrementales y completas con restauración detallada (hasta el nivel de un correo electrónico de una cuenta específica, todo desde la consola gráfica de administración) o el archivado de correos entrantes y salientes (para su posterior consulta o por requerimientos legales) mediante Zimbra Archiving and Discovery. Otras características que también son exclusivas de su Network Edition son la gestión nativa de la jerarquía de almacenamiento, que le permite mover datos de una cierta antigüedad a otros volúmenes de datos pero presentarlos en conjunto al usuario. Esto permite la clásica configuración de discos SCSI como almacenamiento principal y discos SATA (más lentos pero también más baratos) como almacenamiento secundario. O configuraciones con SAN (del inglés, Storage Area Network) o NAS (del inglés, Network Attached Storage) de ambos tipos de discos. Respecto del soporte para múltiples dominios, en su versión Network Edition, Zimbra permite la personalización de los logos y textos para cada dominio, así como usuarios administradores diferentes para cada dominio (y usuarios superadministrador) para gestionar el servidor completo. Gracias a Zimbra Mobile, ZCS consigue la conexión con dispositivos móviles sin cables (bien a través del carrier de telefonía, bien a través de Wi-Fi). Soporta los protocolos Active Sync de Windows y Palm, isync de Apple y SyncML de Symbian. Otras herramientas como Sync4j/Funambol permiten expandir aún más este tipo de integraciones. Para BlackBerry, Zimbra proporciona un conector para BlackBerry Enterprise Server (BES) que se instala en el servidor y permite la afamada sincronización bidireccional a través del carrier de telefonía móvil. Hablando de más integraciones, Zimbra proporciona sendos conectores para Outlook de Microsoft e imail de Apple, con los que se consigue una integración completa y transparente con el servidor. Evolution también tiene un conector, en este caso gratuito. Finalmente, mediante el uso de Verity, Zimbra Network Edition es capaz de convertir prácticamente cualquier adjunto de correo en HTML y mostrarlo en el mismo cliente web de correo. De este modo es posible evitar la dependencia en aplicaciones externas que pueden o no estar instaladas en el sistema. Requerimientos Los requerimientos de Zimbra Collaboration Suite son, en comparación con otros productos similares, bastante bajos. Para entornos de evaluación (hasta 50 cuentas) la siguiente configuración debería ser suficiente: CPU Intel/AMD de 32bits a 1.5 GHz o superior. 1 GB de RAM. 5 GB de espacio libre en disco para el software y los logs (es posible realizar la instalación con menos espacio disponible usando el parámetro skipspacecheck del script de instalación install.sh). Espacio adicional para el almacenamiento del correo y las bases de datos (depende del número de cuentas y de la cuota de disco asignada a cada una). Para un sistema en producción se recomienda la siguiente configuración: CPU Intel/AMD de 32 bits a 2.0GHZ o superior. Mínimo 2 GB de RAM. 10 GB de disco duro para actualizaciones, logs y software, con RAID para redundancia de datos. Espacio de disco adicional para el almacenamiento de los buzones de correo y las bases de datos. Se recomiendan CPU (del inglés, Central Processing Unit) de doble núcleo o superior, y preferiblemente doble CPU, pues se hará buen uso de éstos por parte de la máquina virtual de Java y por parte de Amavis, SpamAssassin y ClamAV. 7 de 20 21/08/11 14:23

8 Para instalaciones de más de 2000 cuentas de usuario, se recomienda CPU de 64 bits, lo que lleva a la necesidad de duplicar la RAM (mínimo 4 GB). El uso de discos SCSI es siempre recomendado frente a SATA por su fiabilidad y rendimiento. En general, y Zimbra no es una excepción, a mayor cantidad de RAM, mayor rendimiento general debido a la caché del kernel, y mayor fiabilidad. Finalmente, el uso de una SAN o NAS, si es pertinente y económicamente posible, es siempre bienvenido dado el uso masivo que se hace del correo hoy en día y de la criticidad de este servicio en las empresas. Por supuesto, todos estos valores son orientativos y únicamente útiles en un caso estándar. Es muy posible que sea preciso aumentarlos en función de los picos de carga que se prevean (por ejemplo si un cierto número, muy elevado, de usuarios acceden a la misma hora a comprobar el correo). Seguridad Respecto de la seguridad, en la documentación de Zimbra se aconseja desactivar SELinux (del inglés, Security Enhanced Linux) y el cortafuegos. Desactivar SELinux no tiene porqué suponer un problema, pero trabajar sin un cortafuegos en una máquina con dirección IP pública no es algo que uno pueda o quiera permitirse. La documentación de Zimbra presupone que el servidor se encuentra tras un router que hace NAT de los puertos, pero éste no tiene porqué ser siempre el caso y, aún así, la seguridad no debe enfocarse únicamente hacia el exterior. Debido a que este tema es susceptible de largas discusiones, además de dependiente de cada caso y organización particular, por no hablar de cómo configurar en sí un cortafuegos, a continuación se facilita una lista de puertos que deberán dejarse abiertos para el correcto funcionamiento de Zimbra y se deja a discreción del usuario su uso y su aplicación. SMTP, puerto 25 TCP. HTTP, puerto 25 TCP. HTTPS, puerto 443 TCP. POP3, puerto 110 TCP. POP3 sobre SSL (POP3S), puerto 995 TCP. IMAP4, puerto 143 TCP. IMAP4 sobre SSL (IMAPS), puerto 993 TCP. LDAP, puerto 389 TCP. LDAP sobre SSL (LDAPS), puerto 636 TCP. Administración de Zimbra, puerto 7071 TCP. El acceso a los puertos 389 y 686 permite consultas al GAL de Zimbra, pero no debería abrirse al exterior (quizás filtrarlo sólo a la red local o a la IP pública del gateway/router de la oficina) pues OpenLDAP permite consultas anónimas por defecto. Zimbra es la primera versión que incluye la posibilidad de permitir sólo consultas autenticadas a LDAP sobre la IP pública, a través de SSL, y que las consultas internas se realicen por la interfaz local. El acceso al puerto 7071 quizás quiera restringirse también a ciertos direcciones IP. En el caso de utilizar Zimbra Proxy, también se hará uso de los siguientes puertos: Route Lookup Handler, puerto 7072 TCP. IMAP, puerto 7143 TCP. IMAP sobre SSL, puerto 7993 TCP. POP3, puerto 7110 TCP. POP3 sobre SSL, puerto 7995 TCP. A menos que el administrador tenga un motivo específico, no será necesario abrir estos puertos al exterior pues sólo se hace uso de ellos internamente. Instalación en Debian Etch Las siguientes instrucciones toman como punto de partida un sistema Debian Etch funcional, plataforma i386 de 32 bits, con las últimas actualizaciones de seguridad y el kernel precompilado de Debian en su versión 686. No se seleccionó ninguna tarea en el selector de tareas durante la instalación. Se configuró la IP estática x.y.z.t durante la instalación. Se tomó zimbra como nombre del equipo (hostname) y zimbra.midominio.com como FQDN (del inglés, Fully Qualified Domain Name). Todas las sentencias deben ejecutarse como usuario root o mediante sudo, a menos que se indique lo contrario (comandos que se ejecutarán con el usuario zimbra). El primer paso será desinstalar Exim: 8 de 20 21/08/11 14:23

9 apt-get remove --purge exim4 exim4-base exim4-config exim4-daemon exim4-daemon-light Acto seguido nos aseguraremos de que el fichero /etc/hosts esté configurado correctamente. Debería tener, al menos, las dos entradas siguientes: localhost.localdomain localhost x.y.z.t zimbra.midominio.com zimbra A continuación nos cercioraremos de que los registros A y MX de la zona de DNS correspondiente al servidor estén bien configurados. Esto puede variar en función de si nos encontramos en una máquina con IP pública o en una máquina con IP privada (tras un router que haría NAT). Además, puede que usemos un servidor de DNS local con vistas, o directamente uno externo. En cualquier caso, los objetivos son dos: Que zimbra.midominio.com se traduzca correctamente a la dirección IP configurada. Y que el registro MX del dominio midominio.com apunte a dicha dirección IP. zimbra.midominio.com. zimbra.dominio.com. dominio.com. IN A x.y.z.t IN MX 20 zimbra.dominio.com. IN MX 20 zimbra.dominio.com. Estos aspectos de configuración de DNS son requerimientos de Zimbra para su instalación. Es conveniente, asimismo, tener bien configurado el registro PTR de la dirección IP donde se vaya a instalar Zimbra. Como último paso antes de iniciar el instalador de ZCS, instalaremos una serie de paquetes que son dependencias necesarias para el correcto funcionamiento (algunos son dependencias de los paquetes DEB de Zimbra, otros son opcionales pero de facto necesarios si queremos que todas las funcionalidades de Zimbra estén activas). También se incluyen paquetes de propósito general de instalación obligada en cualquier servidor: aptitude install curl sudo libidn11 fetchmail libgmp3c2 libxml2 \ libstdc++5 libstdc++6 openssl libltdl3 libssl0.9.7 libdb3 \ libexpat1 libltdl3 libio-socket-ssl-perl libmail-imapclient-perl \ libmail-pop3client-perl libpcre3 file psmisc libgetopt-mixed-perl \ libmime-explode-perl sysstat rar lha arj unrar zoo nomarch cpio \ lzop cabextract zip unzip bzip2 gzip lsof tcpdump sysstat procps \ pstack strace Descargamos la última versión disponible de Zimbra (en el momento de escribir este artículo, la 5.0.9), por ejemplo al directorio /usr/local/src/. Para escribir este artículo se ha utilizado la versión de la Open Source Edition. En el caso de la Network Edition, el procedimiento para una instalación monoservidor es idéntico pero con la posibilidad de instalar más paquetes (aparecen más opciones a las que decir sí durante la instalación). Tras descomprimir el archivo TGZ, encontraremos en su interior un fichero install.sh, que ejecutaremos. Debian Etch por defecto no instala SELinux pero, en el caso de que se hubiera hecho, será necesario cambiarlo a modo permissive o disabled para el correcto funcionamiento de Zimbra (SELINUX=permissive en /etc/selinux/config) y reiniciar el servidor para que el cambio surja efecto. El instalador realizará diversas preguntas, todas muy sencillas de responder. Para unas pruebas iniciales, se recomienda instalar todos los paquetes excepto Zimbra Proxy. Install zimbra-ldap [Y] Install zimbra-logger [Y] Install zimbra-mta [Y] Install zimbra-snmp [Y] Install zimbra-store [Y] Install zimbra-apache [Y] Install zimbra-spell [Y] Install zimbra-proxy [N] Nota: la versión Network Edition preguntará, además, por la instalación de Zimbra Archiving (estaríamos usando la versión para Ubuntu 6 y deberemos confirmar al instalador que somos conscientes de estar instalando sobre Debian 4 y que 9 de 20 21/08/11 14:23

10 queremos proceder). Al final de la instalación se mostrará un menú de texto con varios puntos pendientes (marcados con asterisco). Será necesario corregir estos puntos antes de aplicar los cambios y terminar el proceso. Como mínimo será necesario ir a la opción 3 para establecer la contraseña de administrador y cambiar el modo del servidor web a https). El resultado final debería de ser el siguiente: 1. Common Configuration. 2. zimbra-ldap: Enabled 3. zimbra-store: Enabled * Create Admin User: yes * Admin user to create: admin@zimbra.midominio.com * Admin Password: * Enable automated spam training: yes * Spam training user: spam.n2xvfp2a@zimbra.midominio.com * Non-spam(Ham) training user: ham.htr37bbj@zimbra.midominio.com * Global Documents Account: wiki@zimbra.midominio.com * SMTP host: zimbra.midominio.com * Web server HTTP port: 80 * Web server HTTPS port: 443 * Web server mode: https * IMAP server port: 143 * IMAP server SSL port: 993 * POP server port: 110 * POP server SSL port: 995 * Use spell check server: yes * Spell server URL: 4. zimbra-mta: Enabled 5. zimbra-snmp: Enabled 6. zimbra-logger: Enabled 7. zimbra-spell: Enabled 8. Default Class of Service Configuration. r. Start servers after configuration: yes s. Save config to file x. Expand menu q. Quit A partir de este momento ya deberíamos ser capaces de acceder al webmail de Zimbra en: Zimbra es una herramienta muy completa y potente, por lo que lleva su tiempo acostumbrarse, ver de qué es capaz y empezar a sacarle verdadero provecho más allá del uso básico como servidor de correo, anotación de citas y gestión de contactos. A continuación se presentan una serie de utilidades varias que son de frecuente uso (todas deberán ejecutarse como usuario zimbra, normalmente accedido mediante sudo su zimbra al hacer login: zmcontrol status: obtener el estado de los diversos daemons que forman el sistema Zimbra. zmcontrol start/stop: arrancar/parar el sistema Zimbra. zmcontrol -v: mostrar la versión (en este artículo, Release 5.0.9_GA_2533.DEBIAN4.0 DEBIAN4.0 FOSS edition). zmtlsctl [mixed both http https redirect]: cambiar el tipo de acceso permitido al webmail. mixed realizará la validación sobre HTTPS y luego volverá al modo HTTP. both permitirá indistintamente uno y otro. redirect cambiará al usuario al modo https y lo mantendrá en ese modo (recomendado). http forzará que se trabaje sólo sobre HTTP. https forzará que se trabaje únicamente sobre HTTPS (recomendado). El fichero de configuración principal de Zimbra es /opt/zimbra/conf/localconfig.xml. Cualesquiera cambios que querramos hacer sobre el sistema para que sobrevivan a las actualizaciones deberán realizarse en éste fichero y en los demás dentro del directorio /opt/zimbra/conf. zmzimletctl listzimlets: mostrará un listado de los Zimlets instalados. zmzimletctl deploy zimlet.zip: instalrá el Zimlet zimlet.zip, que deberá encontrarse dentro del subdirectorio /opt/zimbra 10 de 20 21/08/11 14:23

11 /zimlets-extra/. zmlocalconfig: permite realizar cambios sobre la configuración local guardada en el fichero /opt/zimbra /conf/localconfig.xml. zmprov: aprovisionamiento de cuentas. zmprov es un comando que permite interactuar con casi cualquier parte del sistema desde la consola de comandos, por ejemplo para crear o borrar cuentas desde un script. Puede actuar sobre los siguientes sistemas: Cuentas. Calendario. Configuración. COS (Class Of Service). Dominios. Listas de distribución. Buzones de correo. Wiki. Búsquedas. Servidores. Otros (misceláneos). Los comandos de consola disponibles se encuentran en /opt/zimbra/bin. Además, un gran conjunto de utilizadades del sistema en forma de scripts de Perl están disponibles en /opt/zimbra/libexec. Mejoras en el sistema antispam Zimbra viene por defecto con SpamAssassin como filtro antispam. Si bien la efectividad de SpamAssassin es elevada, su consumo de CPU también lo es. Además, existen maneras más eficientes, con menor consumo tanto de CPU como de ancho de banda, para combatir el spam que, en conjunción con SpamAssassin, disparan la eficiencia del sistema en esta lucha. A continuación se explica como instalar Postgrey, un conocido sistema de greylisting, y como enlazar el Postfix de Zimbra con Spamhaus. Además, se añaden algunas restricciones más a Postfix. En primer lugar, como root, instalaremos Postgrey en la máquina: aptitude install postgrey En segundo lugar, como usuario zimbra, editaremos el fichero /opt/zimbra/conf/postfix_recipient_restrictions.cf: reject_non_fqdn_recipient reject_unknown_recipient_domain permit_sasl_authenticated permit_mynetworks reject_unauth_destination reject_unlisted_recipient %%contains VAR:zimbraMtaRestriction reject_invalid_hostname%% %%contains VAR:zimbraMtaRestriction reject_non_fqdn_hostname%% %%contains VAR:zimbraMtaRestriction reject_non_fqdn_sender%% %%contains VAR:zimbraMtaRestriction reject_unknown_client%% %%contains VAR:zimbraMtaRestriction reject_unknown_hostname%% %%contains VAR:zimbraMtaRestriction reject_unknown_sender_domain%% %%contains VAR:zimbraMtaRestriction reject_rbl_client dnsbl.njabl.org%% %%contains VAR:zimbraMtaRestriction reject_rbl_client cbl.abuseat.org%% %%contains VAR:zimbraMtaRestriction reject_rbl_client bl.spamcop.net%% %%contains VAR:zimbraMtaRestriction reject_rbl_client sbl.spamhaus.org%% %%contains VAR:zimbraMtaRestriction reject_rbl_client xbl.spamhaus.org%% %%contains VAR:zimbraMtaRestriction reject_rbl_client sbl-xbl.spamhaus.org%% %%contains VAR:zimbraMtaRestriction reject_rbl_client relays.mail-abuse.org%% reject_rbl_client zen.spamhaus.org check_policy_service inet: :60000 permit Finalmente, también como usuario zimbra, recargaremos Postfix con postfix reload para que surjan efecto los cambios. 11 de 20 21/08/11 14:23

12 Whitelisting En un plano teórico, los seis checkboxes que aparecen en la opción de "Configuración general: MTA" de la consola gráfica de administración de Zimbra deberían de estar marcados. Estas seis restricciones no deberían de causar problema alguno con servidores de correo bien configurados, pero esto no siempre es posible, sobre todo en empresas que dependen del correo para trabajar y cuyos proveedores tienen servidores de correo mal configurados. Estas comprobaciones se reparten en dos grupos, de protocolo y de DNS. Las de protocolo son las siguientes: reject_invalid_hostname (el nombre del servidor en el inicio de la comunicación infringe RFC). Si está activa, Postfix rechazará las peticiones de los clientes cuyos comandos HELO o EHLO tengan una sintaxis incorrecta del nombre de host. El valor por defecto del error que se devuelve es el 501 (definible con invalid_hostname_reject_code). reject_non_fqdn_hostname (el cliente debe iniciar la comunicación con un nombre de servidor totalmente cualificado). Si está activa, Postfix rechazará las peticiones de los clientes cuyo nombre de host en el comando HELO o EHLO no sea un FQDN. El valor por defecto del error que se devuelve es el 504 (definible con non_fqdn_reject_code). reject_non_fqdn_sender (la dirección del remitente debe estar totalmente cualificada). Si está activa, Postfix rechazará las peticiones de los clientes que no faciliten un FQDN en el comando MAIL FROM durante la conexión. El valor por defecto del error que se devuelve es el 504 (definible con non_fqdn_reject_code). Y las de DNS son las siguientes: reject_unknown_client (dirección IP del cliente). Si está activa, Postfix rechazará las peticiones de los clientes cuyas direcciones IP no tengan un registro PTR configurado, o si dicho registro PTR no tiene un registro A configurado que coincida (es decir, que coincida con el FQDN aportado en el comando HELO o EHLO). El valor por defecto del error que se devuelve es el 450 (definible con unknown_client_reject_code). reject_unknown_hostname (nombre del servidor en el inicio de la comunicación). Si está activa, Postfix rechazará las peticiones de los clientes cuyos nombres de host presentados en el comando HELO o EHLO no tengan un registro de DNS tipo A o tipo de MX. El valor por defecto del error que se devuelve es el 450 (definible con unknown_hostname_reject_code). reject_unknown_sender_domain (dominio del remitente). Si está activa, Postfix rechazará las peticiones de los clientes que, al mandar el comando MAIL FROM, aporten un nombre de dominio en la dirección de correo que no tenga un registro de DNS de tipo A o de tipo MX. El valor por defecto del error que se devuelve es el 450 (definible con unknown_address_reject_code). En el caso de un error temporal de resolución en el DNS, el error retornado es siempre el 450. Como puede observarse, estas restricciones no son, en absoluto, tan restrictivas como se pueda pensar. Ahora bien, la realidad es la que es y no siempre se puede hacer lo que se debe. Para poder mantener estas seis restricciones activas pero poder trabajar con un cierto número de servidores de los cuales dependamos o confiemos, podemos utilizar las listas blancas. Las listas blancas (del inglés, whitelists), son unas listas con direcciones de remitentes o dominios completos para los cuales Postfix se saltará estas comprobaciones. Para activarlas, editaremos el fichero /opt/zimbra/conf/postfix_recipient_restrictions de forma que quede como sigue: 12 de 20 21/08/11 14:23

13 reject_non_fqdn_recipient reject_unknown_recipient_domain permit_sasl_authenticated permit_mynetworks reject_unauth_destination reject_unlisted_recipient check_client_access hash:/opt/zimbra/conf/postfix_client_access check_sender_access hash:/opt/zimbra/conf/postfix_sender_access %%contains VAR:zimbraMtaRestriction reject_invalid_hostname%% %%contains VAR:zimbraMtaRestriction reject_non_fqdn_hostname%% %%contains VAR:zimbraMtaRestriction reject_non_fqdn_sender%% %%contains VAR:zimbraMtaRestriction reject_unknown_client%% %%contains VAR:zimbraMtaRestriction reject_unknown_hostname%% %%contains VAR:zimbraMtaRestriction reject_unknown_sender_domain%% %%contains VAR:zimbraMtaRestriction reject_rbl_client dnsbl.njabl.org%% %%contains VAR:zimbraMtaRestriction reject_rbl_client cbl.abuseat.org%% %%contains VAR:zimbraMtaRestriction reject_rbl_client bl.spamcop.net%% %%contains VAR:zimbraMtaRestriction reject_rbl_client sbl.spamhaus.org%% %%contains VAR:zimbraMtaRestriction reject_rbl_client xbl.spamhaus.org%% %%contains VAR:zimbraMtaRestriction reject_rbl_client sbl-xbl.spamhaus.org%% %%contains VAR:zimbraMtaRestriction reject_rbl_client relays.mail-abuse.org%% reject_rbl_client zen.spamhaus.org check_policy_service inet: :60000 permit A continuación, como usuario zimbra, haremos un postfix reload para que se hagan efectivos los cambios. Si decidimos marcar o desmarcar algunos de los checkboxes arriba mencionado, basta con pulsar sobre el botón guardar y el propio Zimbra ya se encarga de hacer dicha recarga de los parámetros de configuración. Luego deberemos crear el fichero /opt/zimbra/conf/postfix_sender_access, asegurándonos de que el usuario zimbra tiene permisos de lectura sobre el mismo, y añadirle el contenido que queramos, del estilo de lo que sigue: # /dominio Valor Comentario reservas@proveedor.es OK Reservas proveedor OK Todo el dominio del proveedor B Acto seguido deberemos crear el fichero /opt/zimbra/conf/postfix_client_access, asegurándonos de que el usuario zimbra tiene permisos de lectura sobre el mismo, y añadirle el contenido que queramos, del estilo de lo que sigue: # Direccion IP Valor Comentario x.y.z.t OK Proveedor A a.b.c.d OK Proveedor B Finalmente, como usuario zimbra, ejecutaremos el comando postmap /opt/zimbra/conf/postfix_whitelist, que creará el fichero /opt/zimbra/conf/postfix_whitelist.db y hará efectivos los cambios en el Postfix en ejecución. Nótese que sólo se han aplicado las listas blancas a Postfix, no a Amavis ni a SpamAssassin. El motivo es que, en mi opinión particular, si bien es cierto que ambos pueden llegar a consumir muchísima CPU, por un lado nadie puede asegurarnos de los PCs tras esas direcciones no puedan estar algún día infectados y, por otro, la cantidad de correos que pasan las seis restricciones, el greylisting y la consula a Spamhaus es tan pequeño que vale la pena dejar que SpamAssassin y Clam AntiVirus verifiquen todos los correos. Instalaciones distribuidas (multiservidor) Además de la solución de clustering con Red Hat Enterprise, Zimbra soporta una instalación distribuida de cada uno de los dominios que hospede, centralizando la administración en una sola consola gráfica y ofreciendo un punto de entrada único a los usuarios. Para lograrlo se instalan 2 o más sistemas con Zimbra, todos con un subdominio diferente del mismo dominio. Uno de los servidores actúa como maestro y los demás como esclavos de éste. Durante la instalación, que se empezará, como es lógico, 13 de 20 21/08/11 14:23

14 por el maestro, se especifica en cada esclavo los datos del maestro que debe replicar. Las características principales de este tipo de instalación serían las siguientes: Gestión centralizada de las cuentas de los usuarios en el servidor maestro. Replicación del directorio LDAP del maestro a los esclavos. Esto permite mantener copias locales de las cuentas que cada nodo gestiona y el acceso al GAL (del inglés, Global Address List) completo de empleados. Ejecución remota de comandos en los servidores esclavos mediante el uso de un par de claves SSH. Monitorización del estado de todos los nodos a través de SNMP y presentación de los datos estadísticos en el maestro (en la consola gráfica de administración). Cada nodo tendrá su registro de DNS tipo A y tipo MX. Mediante la tabla de transportes de Postfix, el correo se enrutará al host pertinente. Mediante el uso del proxy de Zimbra (basado en Nginx y Memcached) se distribuirán las conexiones HTTP, IMAP y POP3 (y sus equivalentes sobre canal cifrado). Cada cuenta de usuario de un dominio pertenece a un servidor concreto, permitiendo un acceso más eficiente a los usuarios. Un caso donde este modelo tiene una gran aplicación práctica es el de una empresa con diversas delegaciones distribuidas geográficamente. Con este modelo se consigue que los usuarios de cada delegación tengan un acceso local a sus datos, mejorando la experiencia de usuario, pero a la vez la gestión del sistema se hace de manera centralizada, reduciendo los costes. Además, en el caso de caída de alguno de los nodos del sistema, el resto de nodos pueden seguir trabajando con normalidad (los correos destinados a los usuarios del nodo caído quedarían a la espera de ser entregados). Por ejemplo, para la empresa "Mi empresa" con dominio miempresa.com y sedes en Madrid, Barcelona y Sevilla, obtendríamos una configuración con tres subdominios, madrid.miempresa.com, barcelona.miempresa.com y sevilla.miempresa.com, y un único punto de entrada para los usuarios zimbra.miempresa.com (HTTP, IMAP y POP3). Para las peticiones externas, el flujo de información para el acceso de los usuarios sería el siguiente: El cliente final se conecta al proxy de Zimbra usando los puertos estándar de IMAP y POP3. Cuando el proxy de Zimbra recibe una conexión, Nginx manda una petición HTTP al componente de Zimbra encargado de encontrar la ruta adecuada (Zimbra Proxy Route Lookup Handler). Éste encuentra la información de la ruta a seguir para encontrar la cuenta y la devuelve a Nginx. El componente Memcached almacena la información para que no tenga que volver a consultarse mientras no caduque la caché (por defecto la guarda una hora). Nginx usa esta información para acceder al buzón del usuario. El proxy de Zimbra se conecta al buzón de correo e inicia la sesión de proxy de correo. El cliente final se comporta como si se estuviera conectando directamente a su buzón. Instalación de un sistema multiservidor En este apartado se hace un breve resumen de los principales pasos a seguir para la instalación distribuida de un sistema Zimbra. La instalación es muy directa y sencilla de llevar a cabo. Se ejecuta el mismo script de instalación en cada servidor, empezando por el maestro, se seleccionan los componentes adecuados y se utiliza el menú para configurar el sistema. Las instalaciones se realizarán sobre un sistema base idéntico al descrito en el apartado de instalación de un servidor estándar 14 de 20 21/08/11 14:23

15 de este artículo. Tras la instalación se deberán ejecutar dos pasos adicionales, uno para habilitar el par de claves SSH, el otro para habilitar la funcionalidad de monitorización del sistema. Es muy importante instalar los servidores siguiendo este orden: Servidor LDAP. Servidores de mailboxes de Zimbra (Zimbra Store). Servidores de Zimbra MTA. Puede instalarse Zimbra Proxy en cualquiera de los servidores, o instalarlo en un servidor aparte. En este ejemplo de instalación se instalará Zimbra Proxy en el mismo servidor que el LDAP maestro. Es importante verificar que los relojes de los diferentes servidores estén sincronizados. Para ello se recomienda el uso del daemon NTP. Instalación de LDAP, SNMP y Proxy El primer paso de la instalación, como se ha dicho anteriormente, será arrancar el instalador de Zimbra y seleccionar únicamente el paquete Zimbra LDAP, el paquete Zimbra Proxy y el paquete Zimbra SNMP. Zimbra Core se instalará como dependencia. Una vez instalados los paquetes, llegaremos al menú de texto del final del proceso de instalación, donde deberemos configurar el sistema a nuestra medida. La configuración se hace de la misma manera que se ha descrito en el apartado de instalación de este artículo, salvo por la configuración de LDAP. Main menu 1. Common Configuration 2. zimbra-ldap: Enabled 3. zimbra-snmp: Enabled r. Start servers after configuration yes s. Save config to file x. Expand menu q. Quit Usaremos la opción "1" para acceder al submenú y luego la opción "4" para configurar la contraseña de administrador de LDAP. Será necesario anotar el nombre de host, el puerto y la contraseña ya que deberemos usarla cuando instalemos el Zimbra Store y el Zimbra MTA más adelante. Main menu 1. Common Configuration: 1. Hostname: zimbra.midominio.com 2. Ldap master host: zimbra.midominio.com 3. Ldap port: Ldap Admin password: set 5. TimeZone: (GMT+01.00) Brussels / Copenhagen / Madrid / Paris 6. Require secure interprocess communications: Yes Con la opción "5" podremos cambiar la zona horaria. Luego volveremos atrás con la opción "r" y entraremos en la opción "2" para cambiar los ajustes de LDAP. Cambiaremos también las contraseñas de replicación de LDAP, de Amavis y de Postfix, si así lo queremos. La contraseña de administrador de LDAP, de Postfix y de Amavis debe ser la misma. Cuando el servidor LDAP ya esté configurado, volveremos al menú principal usando la opción "r" y aplicaremos los cambios usando la opción "a". Y finalizaremos la instalación con la opción "q". Instalación de Store, Logger y Spell Llega la hora de instalar el Zimbra Mailbox Server, que puede hacerse sobre la misma máquina o sobre una máquina diferente. Se puede tener más de un servidor de buzones de correo y se pueden añadir nuevos servidores siempre que se quiera. Nota: Zimbra Logger se instala en la máquina donde se instale el primer Zimbra Store. 15 de 20 21/08/11 14:23

16 Ejecutaremos de nuevo el instalador y, a la hora de elegir los paquetes a instalar, seleccionaremos únicamente zimbra-store, zimbra-logger y zimbra-spell (como dependencias se instalarán también zimbra-apache y zimbra-core). Seguiremos el proceso habitual hasta llegar al menú del final de la instalación, donde aparecerán varios puntos con asteriscos (sin configurar). Para expandir el menú podemos usar la opción "x". Además de puntos anteriormente configurados, como la zona horaria, que deberán volver a configurarse si se trata de una máquina diferente, los siguientes puntos deberán forzosamente ajustarse adecuadamente. En la configuración de LDAP tendremos que introducir el valor del nombre de host y de contraseña introducidos en la instalación anterior del paquete zimbra-ldap. El servidor intentará contactar inmediatamente con el servidor LDAP y, si no le es posible, no nos dejará seguir. El siguiente paso será configurar la contraseña de la cuenta de administrador, el host SMTP y establecer el modo del servidor web (http, https, both, redirect o mixed). Las opciones a usar son la "4", la "9" y la "10". Si se instaló zimbra-proxy en la vez anterior, ahora deberemos habilitarlo. Para ello iremos a la opción "13". Al habilitar el proxy sobre los puertos POP3 e IMAP, tanto éstos como los propios puertos del proxy se cambian a los valores por defecto de Zimbra (ver apartado de seguridad y cortafuegos en este mismo artículo). Volveremos atrás con la opción "r", aplicaremos los cambios y finalizaremos la instalación igual que la vez anterior. Instalación de Zimbra MTA Es necesario que, al empezar la instalación de zimbra-mta, sepamos ya el nombre de host, el puerto y la contraseña de administrador del LDAP. Sino, el MTA no será capaz de contactar con el LDAP y no se podrá finalizar la instalación. Los pasos iniciales son los mismos que las veces anteriores, debiéndose, en esta ocasión marcar únicamente el paquete zimbra-mta y el paquete zimbra-snmp y dejar desmarcados todos los demás. Al llegar al menú del final de la instalación, será preciso que modifiquemos, al menos, los valores "LDAP master host" y "LDAP admin password" de la opción "1", y "MTA auth host", "Bind password for Postfix LDAP user" y "Bind password for Amavis ldap user" en la opción "2". Todos estos valores los obtendremos de las instalaciones anteriores. La contraseña de administrador de LDAP, de Postfix y de Amavis debe ser la misma. Una vez configurados estos valores, aplicaremos la configuración y finalizaremos la instalación de la misma manera que en las ocasiones anteriores. Ajustes finales Una vez el servidor de LDAP, de buzones y el MTA están instalados y configurados en una instalación multinodo, quedan dos funciones pendientes de configurar: Para que la gestión remota y el acceso a las colas de correo funcione, es necesario propagar manualmente el par de claves a todos los nodos. Si se ha instalado el logger, habrá que configurar los ficheros del syslog en cada servidor para habilitar las estadísticas que se muestran en la consola de administración, y luego habilitar el host donde se ha instalado Zimbra Logger. Para propagar el par de claves, en cada nodo ejecutaremos, como usuario zimbra (su - zimbra o sudo su zimbra), el comando zmupdateauthkeys. La clave se actualiza en el fichero /opt/zimbra/.ssh/authorized_keys. Para que se muestren las estadísticas en la consola de administración, hay que modificar los ficheros de configuración del syslog. En cada servidor, como usuario root, ejecutaremos /opt/zimbra/bin/zmsyslogsetup. En el host donde se haya instalado Zimbra Logger (en este artículo, en el host maestro), debemos habilitar la recogida de logs de máquinas externas. Para ello, como usuario root: Editamos el fichero /etc/default/syslogd y modificamos la variable SYSLOGD para que quede tal que SYSLOGD="-r -m 0". Paramos el daemon con /etc/init.d/syslog stop. Arrancamos de nuevo el daemon con /etc/init.d/syslog start. Para verificar que cada nodo instalado está funcionando correctamente, entraremos en cada nodo y, como usuario zimbra, ejecutaremos zmcontrol status. 16 de 20 21/08/11 14:23

17 Problemas con Zimbra Logger De vez en cuando Zimbra Logger deja de generar las estadísticas visibles en la consola gráfica de administración. Las causas principales suelen ser algún daemon que no se cerró o no arrancó adecuadamente durante una parada del sistema o una actualización, o la corrupción de tablas en la base de datos de MySQL. A continuación se detallan algunos procedimientos útiles a seguir en caso de encontrarse en tal situación. Para comprobar si tenemos tablas corruptas, como usuario zimbra entraremos en la consola de MySQL de la base de datos zimbra_logger y, una vez dentro, visualizaremos las tablas, comprobaremos su estado y ejecutaremos un repair table en todas aquellas que nos den errores. El siguiente código ilustra este caso (el código no muestra los checks hechos sobre tablas que no retornaron error): 17 de 20 21/08/11 14:23

18 $ sudo su zimbra $ logmysql zimbra_logger mysql> show tables; Tables_in_zimbra_logger amavis amavis_aggregate config disk_aggregate disk_status mta mta_aggregate processing_history raw_logs service_status rows in set (0.00 sec) mysql> check table mta; Table Op Msg_type Msg_text zimbra_logger.mta check warning Table is marked as crashed and last repair failed zimbra_logger.mta check error Found keys of zimbra_logger.mta check error Corrupt rows in set (5 min sec) mysql> repair table mta; Table Op Msg_type Msg_text zimbra_logger.mta repair status OK row in set (6 hours 34 min sec) mysql> check table processing_history; Table Op Msg_type Msg_text zimbra_logger.processing_history check warning 2 clients are using or haven't closed the table pr zimbra_logger.processing_history check status OK rows in set (0.00 sec) mysql> repair table processing_history; Table Op Msg_type Msg_text zimbra_logger.processing_history repair status OK row in set (0.00 sec) En el caso de ejecutar un zmcontrol status y resultar que alguno de los componentes del logger no se está ejecutando, deberemos revisar lo siguiente: Si no se está ejecutando logmysql.server, revisar que exista /opt/zimbra/logger/db/mysql.pid y que el proceso /opt/zimbra/logger/mysql/libexec/mysqld se está ejecutando. Si no se está ejecutando zmlogswatchctl, revisar que exista /opt/zimbra/log/logswatch.pid y que hay un único proceso 18 de 20 21/08/11 14:23

19 /opt/zimbra/libexec/logswatch ejecutándose. Si el logger se está ejecutando, verificar entonces que la conexión a la base de datos de MySQL es posible y realizar las comprobaciones sobre las tablas anteriormente mencionadas. Podemos parar y arrancar el logger a voluntad mediante el comando zmloggerctl start/stop como usuario zimbra. El log del MySQL del logger se encuentra en /opt/zimbra/logger/db/data/zimbra.midominio.com.err. Síntomas inequívocos de que hay tablas corruptas serán mensajes del estilo: [ERROR] /opt/zimbra/logger/mysql/libexec/mysqld: Table '<nombre_tabla>' is marked as crashed and last (aut La actualización de los logs se produce brevemente cada cinco minutos y durante la noche de forma masiva, pero asimismo tenemos la posibilidad de lanzar manualmente el proceso de análisis de los logs mediante la ejecución del comando /opt/zimbra/libexec/zmlogprocess. La generación de las estadísticas la realiza el script de Perl /opt/zimbra/libexec /zmgengraphs. Aún así es posible que no seamos capaces de recuperar un estado consistente y fiable de los logs, las estadísticas y los procesos relacionados con Zimbra Logger. Como último recurso tendremos entonces que reiniciar la base de datos de información acumulada. Para ello seguiremos estos pasos. su - zimbra zmloggerctl stop mv /opt/zimbra/logger/db /opt/zimbra/logger/db.bak source /opt/zimbra/bin/zmshutil zmsetvars (nos aseguraremos de que no haya proceso alguno de MySQL ejecutándose) /opt/zimbra/libexec/zmloggerinit zmlogswatchctl start Tras cualquiera de los ajustes realizados en este apartado del artículo deberemos esperar entre varios minutos y la llegada de la siguiente mañana para poder ver las correcciones o recreaciones sobre las estadísticas. Uso de memoria RAM y swap El servidor Java de los mailboxes hace un uso extensivo de la caché con el fin de mejorar el rendimiento evitando accesos a disco. Por defecto, Zimbra viene configurado para reservar un 40% de la RAM disponible para este proceso, y un 30% de la RAM para MySQL. En sistemas con más de 4 GB de RAM pueden cambiarse estos valores y reservar una mayor cantidad. La variable de la configuración local que representa el porcentaje de memoria se convierte en la opción -Xmx de la máquina virtual de Java al arrancarla. En el caso de un sistema pequeño, con pocos dominios, buzones y RAM (1 GB), es también posible que nos encontremos que el sistema usa la swap. Para evitar esto, podemos usar estas mismas variables de configuración para reducir el uso. Como usuario zimbra ejecutaremos los siguientes comandos con el valor deseado: zmlocalconfig -e mailboxd_java_heap_memory_percent=40 zmlocalconfig -e mysql_memory_percent=30 Tras estos comandos deberemos reiniciar el servidor de buzones. Bibliografía Performance Tuning Guidelines for Large Deployments LDAP Mapped Attributes Logger Monitoring Zimbra Servers Managing domains Mail backup options for end users User Migration Firewall Configuration Working with Zimbra Proxy Full Backups and Restore procedure 19 de 20 21/08/11 14:23

20 Zindus Zimbra Directory Service (LDAP) Outlook to ical Export Utility for Windows Zimbra Collaboration Suite Single Server Installation Network Edition ZCS Administrator's Guide Mail Queue Monitoring Split Domain GAL not working with Active Directory Improving Anti-spam system CLI zmlocalconfig (Local Configuration) Open Source Edition Backup Procedure Migration Wizard Troubleshooting Right place for Postfix transport map Zimbra + Mailman Howto Commercial Certificates Historial de revisiones Fecha Versión Cambios Documento inicial En el apartado Instalación en Debian Etch, cambiado el uso de aptitude por apt-get al eliminar exim4, añadidos varios paquetes de propósito general en la instalación de dependencias y cortada la línea de instalación de dependencias para que quepa en 80 columnas y facilitar así la impresión del documento. Volver a la página de inicio 20 de 20 21/08/11 14:23