Manual Zim Bra Comando s

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

Por Jaume Sabater, publicado el 1 de octubre de 2008.

Artículo distribuido bajo licencia Creative Commons by-nc-sa.

Índice

Introducción1.

Arquitectura2.

Componentes de la arquitectura

Zimbra Core1.

Zimbra LDAP2.

Zimbra MTA3.

Zimbra Store4.

Zimbra SNMP y Zimbra Logger5.

3.

El cliente web4.

El servidor Zimbra5.

Network Edition6.

Requerimientos7.

Seguridad8.

Instalación en Debian Etch9.

Mejoras en el sistema antispam10.

Whitelisting11.

Instalaciones distribuidas (multiservidor)12.

Instalación de un sistema multiservidor

Instalación de LDAP, SNMP y Proxy1.

Instalación de Store, Logger y Spell2.

Instalación de Zimbra MTA3.

Ajustes finales4.

13.

Problemas con Zimbra Logger14.

Uso de memoria RAM y swap15.

Bibliografía16.

Historial de revisiones17.

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.

Zimbra 5, suite de mensajería y colaboración http://linuxsilo.net/articles/zimbra.html

1 de 20 21/08/11 14:23

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

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

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

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.1.

Construir, de manera gráfica, búsquedas avanzadas y guardarlas para su posterior reutilización.2.

Etiquetar contenidos.3.

Ver documentos adjuntos sin necesitar ninguna aplicación externa.4.

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

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

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

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 5.0.7 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

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:

127.0.0.1 localhost.localdomain localhostx.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.1.

Y que el registro MX del dominio midominio.com apunte a dicha dirección IP.2.

zimbra.midominio.com. IN A x.y.z.tzimbra.dominio.com. IN MX 20 zimbra.dominio.com.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 5.0.9 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

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: Enabled3. zimbra-store: Enabled * Create Admin User: yes * Admin user to create: [email protected] * Admin Password: * Enable automated spam training: yes * Spam training user: [email protected] * Non-spam(Ham) training user: [email protected] * Global Documents Account: [email protected] * 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: http://zimbra.midominio.com:7780/aspell.php4. zimbra-mta: Enabled5. zimbra-snmp: Enabled6. zimbra-logger: Enabled7. zimbra-spell: Enabled8. Default Class of Service Configuration.r. Start servers after configuration: yess. Save config to filex. Expand menuq. Quit

A partir de este momento ya deberíamos ser capaces de acceder al webmail de Zimbra en:

https://zimbra.midominio.com

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

/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:127.0.0.1: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

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

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_accesscheck_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:127.0.0.1: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:

# Email/dominio Valor [email protected] OK Reservas proveedor [email protected] 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 Comentariox.y.z.t OK Proveedor Aa.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

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

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 menu1. Common Configuration2. zimbra-ldap: Enabled3. zimbra-snmp: Enabledr. Start servers after configuration yess. Save config to filex. Expand menuq. 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 menu1. Common Configuration: 1. Hostname: zimbra.midominio.com 2. Ldap master host: zimbra.midominio.com 3. Ldap port: 389 4. 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

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

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

$ sudo su – zimbra$ logmysql zimbra_loggermysql> show tables; +-------------------------+ | Tables_in_zimbra_logger | +-------------------------+ | amavis | | amavis_aggregate | | config | | disk_aggregate | | disk_status | | mta | | mta_aggregate | | processing_history | | raw_logs | | service_status | +-------------------------+ 10 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 8482310 keys of 11353731 | | zimbra_logger.mta | check | error | Corrupt | +-------------------+-------+----------+---------------------------------------------------+ 3 rows in set (5 min 26.80 sec)

mysql> repair table mta; +-------------------+--------+----------+----------+ | Table | Op | Msg_type | Msg_text | +-------------------+--------+----------+----------+ | zimbra_logger.mta | repair | status | OK | +-------------------+--------+----------+----------+ 1 row in set (6 hours 34 min 51.95 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 prop| zimbra_logger.processing_history | check | status | OK +----------------------------------+-------+----------+-----------------------------------------------------2 rows in set (0.00 sec)

mysql> repair table processing_history; +----------------------------------+--------+----------+----------+ | Table | Op | Msg_type | Msg_text | +----------------------------------+--------+----------+----------+ | zimbra_logger.processing_history | repair | status | OK | +----------------------------------+--------+----------+----------+ 1 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

/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 (autom

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=40zmlocalconfig -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

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

2008-10-01 1.0 Documento inicial.

2008-10-10 1.0.1

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