El servidor de correo del que voy a hablar es un HP ML110 G4, con un Xeon 1.8Ghz y 4GB de RAM. Tiene instalado Fedora 7, Zimbra 5.13 y Bind9. Hace copias de seguridad regularmente usando el script de Heinzg, explicado en un post anterior, y saca el correo por un smarthost. Hasta aquí nada complicado. El problema viene cuando queremos cambiar las cosas…

Tras montar un equipo de prueba con una configuración de software similar me dispuse a recuperar Zimbra desde los backups. Mi proceso fue el siguiente:

• Instalar el mismo sistema operativo, Fedora 7, y actualizar con yum update.
• Configurar los mismo parámetros de red, tanto IP como archivo /etc/hosts, nombre de host local y servidor DNS. Ésto último solo es necesario si el servidor está detras de un firewall o de nat.
• Instalar misma versión de Zimbra, con la opción -s, para no realizar configuración posterior y solo instalar los rpm.
• Extraer el backup con dar con el comando dar -K clave -x archivo.dar.
• Parar el servicio de Zimbra, zmcontrol stop como usuario zimbra, y sustituir la carpeta /opt/zimbra por la del backup.
• Reparar permisos, como root hay que hacer chown -R zimbra:zimbra /opt/zimbra y ejecutar /opt/zimbra/libexec/zmfixperms.sh
• Inciar el servicio de Zimbra, zmcontrol start como usuario zimbra.

Con esto tuve replicado el servidor y funcionando perfectamente. O eso creía yo. Encontré un error al entrar en la web de administración, concretamente intentado abrir el panel de colas de correo. No funcionaba. Era poco, pero era un fallo. Así que intenté arreglarlo. Se me ocurrió actualizar a la última versión de la rama 5, la 5.18. Tan sencillo como descargar el paquete de instalación, ejecutar el proceso y actualizar. Detectó la configuración anterior y se puso en marcha de nuevo con la versión 5.18. El panel de colas de correo volvió a funcionar perfectamente.

No contento con esto me dispuse a actualizar a la 6 RC1 para echar un ojo a las nuevas funcionalidades en mi buzón. No problem, de nuevo ejecutar la instalación del paquete y todo fue como de costusmbre, igual que cualquier actualización anterior. La única pérdida que ha habido que lamentar en este cambio es la de los datos estadísticos de la zona de adminsitración. Sale el mensaje de no data available pero el caso es que el archivo /opt/zimbra/libexec/zmgengraphs ha desaparecido en esta versión 6. Aunque, al ejecutar zmcontrol status todos los servicios aparecen levantados. A saber…

Una vez dentro del buzón veo algunas diferencias. La lista de amigos aparece en la parte inferior de la página y ya no está en la barra lateral izquierda.

Al redactar un mensaje nuevo ahora existe la opción de añadir emoticonos de lo más variopinto (esa es April, de las tortugas ninja??) y también podremos añadir un attach desde el maletín.

No veo por ningún sitio la nueva opción de las versiones beta para solicitar la confirmación de lectura/recepción. Lo habré soñado?? Ahh no, esto es lo que pasa:

• When composing an email message, users can flag the message for a return read receipt message. When uses compose an email they can
  select Request Read Receipt from Options on the toolbar. The administrator enables/disables this feature by COS or Accounts. Upgrading to 6.0, this feature is not enabled. For new ZCS installs this feature is enabled by default. This feature can be enabled from the administration console, COS/Admins Features Tab. Users can manage whether to send a return receipt when a message is requesting a read receipt, from their Preferences>Mail folder, Read Receipt section. (Bug 7257).

En los apartados de libreta de direcciones, agenda, tareas y notas no veo nada sifnificativo. En el maletín es donde se han añadido novedades que saltan a la vista, como la creación de hojas de cálculo y presentaciones. También encontramos el inverso de añadir archivos del maletín como adjuntos. Se trata de un botón para enviar un archivo o un enlace de share directamente desde el maletín.

En el área de las preferencias seguro que hay más de un cambio, pero lo primero que se aprecia es la nueva vista y el poder activar/desactivar los zimlets en nuestra cuenta.Ahora que todo funciona correctamente vamos a intentar llevarlo un poco más lejos. Instalaremos Fedora 11 con su correspondiente versión de Zimbra 6 RC1.

Con el DVD de Fedora 11 no podremos actualizar desde la versión 7. No detectará la instalación de nuestro sistema operativo y solo nos dará la opción de nueva instalación. Creo que viene a ser por esto. Solución, pasar por la versión 10 antes, ejecutar yum update y luego actualizar a la 11. Durante este “apaño” no deberemos tocar nada relativo a Zimbra ni a otras configuraciones.

Una vez tengamos Fedora 10 instalado y al día, reiniciamos con el DVD de Fedroa 11 para efectuar su instalación. Actualizamos el sistema existente y… vaya! Grub se ha ido a paseo. No sé si será un fallo generalizado o solo m ha pasado a mi. El caso es que si ocurre lo reparamos arrancando desde el DVD de Fedora 11 de nuevo y elegimos la opción rescue system. Una vez en la shell ejecutamos la reinstalación de grub, primero entrando en su intérprete de comandos (ejecutando grub) y luego especificando la unidad de disco y la partición donde dee residir. Primero ejecutamos root (hd0,0) y luego setup (hd0), contando con que queramos instalarlo en el primero disco duro y en la partición de boot.

Solventado este asunto, el sistema debería iniciar correctamente, pero nos encontraremos otro problema derivado de la actualización de 10 a 11. Es muy probable que  yum no nos funcione porque el sistema mantendrá el paquete de Fedora 10. Aquí está la solución, que tan solo consiste en eliminar el paquete viejo e instalar el nuevo a mano. Ahora tan solo debemos instalar el paquete de Zimbra 6 RC1 para Fedora 11. Hay que repasar que tengamos todas las configuraciones de red idénticas a las del momento en que estábamos con Fedora 7 y Zimbra funcionando. Me refiero a la IP, nombre de host local, archivo /etc/hosts y servidor DNS. La instalación no debería dar problemas. Detectará el modo update de versión 6 a versión 6 y nos dejará el entorno funcionando.

Es un fastidio si quieres realizar backups de tus servidores que están en la DMZ, por que claro, a tí no te van a comprar uno de uso exclusivo y no es plan de abrir puertos hacia la LAN… o sí?

Este caso se me planteó hace un tiempo y la mejor solución que pude encontrar se basa en el uso de las reglas temporizadas del firewall. De esta manera, permitiremos comunicación de DMZ hacia LAN solo en los puertos y momentos necesarios.

En este ejemplo usaremos la herramienta de Plesk 9 Backup, un servidor FTP IIS6 y PFSense. A ver que pasa…

Primero de todo tenemos que tener claro qué queremos hacer, en qué sentido van a ir las conexiones, qué puertos vamos a utilizar y a qué hora. Con esta información podemos ponernos manos a la obra.

Queremos que esta comunicación entre redes sea lo más segura posible, por lo que tendremos en cuenta los siguientes aspectos:

• Se supone que se tiene un usuario FTP creado que al loguear con él entramos en nuestro chroot, es decir, no podemos acceder a raiz del sistema ni modificar archivos fuera.
• Aunque este servidor FTP no tenga acceso desde la WAN, configuraremos las tablas de acceso de IPs permitidas.
• Especificaremos manualmente el rango de puertos para las conexiones pasivas usando valores poco comunes. Léase este documento de Microsoft. Lo pongo en Inglés porque el que está en Español se ha autotraducido y tiene fallos.

Vamos ahora con la configuración del PFSense. Primero vamos a definir el horario en que se activarán las reglas que crearemos posteriormente.

Creamos las reglas correspondientes al servicio FTP y al rango de puertos pasivos. Tan solo debemos especificar en el apartado de nuestra DMZ:

Regla 1

• IP origen – Servidor Plesk.
• Protocolo TCP.
• Cualquier puerto de origen.
• IP destino – Servidor FTP.
• Puertos de destino – Puerto 21.

Regla 2

• IP origen – Servidor Plesk.
• Protocolos TCP/UDP.
• Cualquier puerto de origen.
• IP destino – Servidor FTP.
• Puertos de destino -El rango pasivo.

Ahora que ya tenemos ambas reglas creadas definiremos un criterio de temporalidad en el apartado Firewall -> Schedules.  Añadiremos una nueva temporización y nos encontraremos con esta pantalla

En este ejemplo he dado a la regla el nombre “BACKUP_TEMPORIZADO 1″ y he definido un primer criterio que consiste en que se active todos los viernes, haciendo click en el nombre del día (color rojo pálido), y también los días martes 14 y miércoles 15. El horario programado es de 08:00 a 10:00 y el nombre que le he puesto es “por la mañana“. Si hacemos click en Add Time añadiremos esta programación a la lista de horarios de la regla.

Podemos crear reglas temporizadas con todas las programaciones que necesitamos. También es recomendable para paranoicos modificar las reglas cada cierto tiempo para que no sigan un patrón concreto. Hacemos click en Save y veremos como nuestra regla aparece en la lista.

Volvemos a las reglas creadas al principio y en el apartado Schedule seleccionamos la temporización que hemos creado.

Veremos como aparece la programación en la lista de las reglas. Si la programación está activa veremos un icono de pass (flecha verde) si no lo está veremos el icono del cuadrado rojo con la cruz.

Ahora crearemos en el Plesk Backup Manager una programación de backup que coincida con la activación temporal de la regla. Según este ejemplo hemos abierto los puertos durante dos horas. Habría que calcular el tiempo estrictamente necesario para realizar la operación y ajustarlo al máximo para reducir riesgos.

Aquí tenéis el link:

http://www.networkworld.com/reviews/2003/020310gbe.html

Existe un Zimlet bastante práctico que nos da la funcionalidad de “click-to-call” y de enviar SMS a través de la interfaz web de Zimbra. De momento no funciona con Zimbra Desktop. También hay un par de zimlets oficiales que viene con la propia instalación de Zimbra, pero están dentro de la rama experimental. Este por lo menos está bastante probado y según he podido leer por los foros tiene a la gente satisfecha. Vamos al lío…

Descargamos el zimlet de la web oficial de sus desarrolladores. Para instalarlo necesitamos realizar modificaciones tanto en el servidor Zimbra como en el servidor Asterisk. Primero subimos el archivo zip a la carpeta /opt/zimbra/zimlets y lo instalamos usando el comando

zmzimletctl install /opt/zimbra/zimlets/ch_bnc_asterisk.zip

Este comando se encuentra dentro de la carpeta /opt/zimbra/bin. A continuación, extraemos el archivo XML de configuración para editar los parámetros específicos de nuestro servidor Asterisk y lo dejamos en la carpeta /tmp por ejemplo.

zmzimletctl getConfigTemplate
/opt/zimbra/zimlets/ch_bnc_asterisk.zip >
/tmp/ch_bnc_asterisk_config.xml

Editamos el archivo ch_bnc_asterisk_config.xml donde tendremos que cambiar:

• IP o nombre dns de nuestro servidor asterisk.

<property name="astManagerIp">111.111.111.111</property>

• Puerto de Asterisk Manager, por defecto el 5038.

<property name="astManagerPort">5038</property>

• Usuario y contraseña del usuario de Asterisk Manager que ejecutará los comando enviado por el zimlet. Necesita privilegios de call y command. De momento nos lo podemos inventar, ya que lo daremos de alta más adelante.

<property name="astManagerUser">usuario</property>
<property name="astManagerSecret">contraseña</property>

• El contexto. En mi caso, from-internal.

<property name="astDialContext">from-internal</property>

• El tipo de canal en uso por las extensiones para crear correctamente el comando de click-to-call. Si tienes extensiones SIP, pues SIP. Si tienes extensiones analógicas, pues ZAP. No lo he probado con IAX, ahora que lo pienso…

<property name="astDialChannelType">SIP</property>

Estas con las configuraciones básicas para que el invento funcione, pero tiene algunas más relacionadas con el marcado y el uso de prefijos.  El siguiente paso consiste en cargar la nueva configuración para que el zimlet conecte con nuestro servidor Asterisk. Usaremos el mismo comando de antes y luego reiniciaremos el servicio de mailboxd:

zmzimletctl configure /tmp/ch_bnc_asterisk_config.xml

zmmailboxdctl restart

Ahora debemos crear un usuario en el servidor Asterisk con los privilegios necesarios para poder comunicarse con él. El sistema Asterisk Manager consiste en un pequeño servicio que escucha en un puerto TCP para ejecutar comandos remotamente. Se creó entre otras cosas para este tipo de usos, admitir integración sencilla con otras aplicaciones. Más info en VoIP-info.org. Para crear un nuevo usuario de esta plataforma editaremos el archivo /etc/asterisk/manager.conf y añadiremos las siguientes líneas:

[user] #nombre de usuario

secret = pass #contraseña

deny=0.0.0.0/0.0.0.0 #rango de direcciones no admitidas

permit=0.0.0.0/255.255.255.0 #rango de direcciones admitidas

read = system,call,log,verbose,command,agent,user

#permisos de lectura también se puede poner all

write = system,call,log,verbose,command,agent,user

#permisos de escritura también se puede poner all

Si tienes los servidores en diferentes redes, o resulta que el Zimbra está en una DMZ y no se puede comunicar con el Asterisk que está en la LAN puede que hayas pensado… como voy a conectar las llamadas entre redes?? Tendré que permitir tráfico SIP en el firewall?? La respuesta es no. Tan solo has de permitir el puerto de Asterisk Manager entre el servidor Zimbra y el Asterisk. Lo que realmente estamos haciendo es ejecutar comandos en el Asterisk de manera que el servidor llamará a nuestra extensión y al descolgar nos realizará automaticamente la llamada saliente. En otras palabras, no existe tráfico de voz entre el Zimbra y el Asterisk.

Como una imagen vale más que mil palabras, os dejo las siguientes capturas para que os hagáis una idea de la sencillez de la aplicación y de como funciona.

Definiendo nuestra extensión.

Información del servidor Astrerisk.

El menú del zimlet.

Autodetección de números de teléfono con la opción de click-to-call.

Ring Ring!! El zimlet envía el comando de llamada y nuestra extensión suena. Al descolgar nos conmutará con la llamada saliente.

Con ayuda del amigo Vicent, que a veces deja algún comentario por aquí, empecé a darle forma al asunto y en pocos días tuve un proyecto definido. Vamos a definir 5 VLANs para los diferentes chismes que tenemos en la oficina:

• Workstations
• Servers
• VoIP
• IPCams
• WiFi

Intentaremos estar offline el menor tiempo posible, por lo que primero de todo vamos a meternos en el PfSense para definir las VLANs. Este proceso requiere reiniciar el firewall, así que es recomendable hacerlo primero y todo de una vez.

El sistema es sencillo de entender. Bajo una interfaz física vamos a definir interfaces “lógicas” que van a funcionar como si fueran físicas, algo así como las particiones de los discos duros. Cada VLAN tiene un identificar numérico y una descripción en texto. No hay gran misterio en el asunto.

Hemos definido nuevas interfaces y cada una tiene sus opciones:

• IP fija o DHCP.
• Puerta de enlace de la red, para sacar el tráfico por ella en lugar de por la WAN (útil para MultiWAN).
• Modo Bridge…

Ahora debemos hacer lo mismo en el switch. En el caso de la VLAN destinada a tráfico de voz, disponemos de una opción especial de automatización en el modelo de switch que vamos a tratar. Se trata de una funcionalidad que también existe en Cisco y que resulta bastante útil. Pero antes de nada, debemos definir la VLAN. Accedemos a la configuración del switch, en este caso por web, y dentro del menú DEVICE – VLAN creamos las VLAN exactamente igual que en el firewall, dándoles el mismo identificador numérico y de texto.

A continuación configuraremos los puertos del switch que van a pertenecer a cada VLAN. La diferencia entre tagged y untagged se puede resumir sencillamente en que en los puertos tagged se etiquetan los paquetes con su identificador numérico correspondiente, por lo que solamente es necesario definirlos cuando esos puertos van hacia un router o similar.

En el caso de la imagen, tenemos ocho puertos untagged que corresponden al servidor Elastix y a los teléfonos IP. El puerto 24 está configurado como tagged porque está conectado al PFSense. Este puerto pertenecerá y permanecerá como tagged para todas las VLAN que queramos gestionar y que hayamos definido en nuestro Firewall.

La funcionalidad de automatización de la que hablaba antes la encontramos dentro del menú DEVICE – QoS – VOIP Traffic Setting. Consiste en configurar puertos de manera que añadan automáticamente a la red de voz dispositivos específicos, identificados por su OUI (tres primero pares de la MAC). De esta manera, si conectamos un teléfono IP (previa inserción de su OUI en la tabla) a un puerto que no pertenece la VLAN de voz, el switch lo añadirá automáticamente. Está explicado de manera sencilla en el documento oficial de 3Com.

El servidor web estaba pidiendo una actualización a gritos. Se montó bajo Fedora Core 5 64bit hace 3 años y ahora estamos teniendo problemas con las aplicaciones que necesitan PHP 5.2 y que Fedora 5 no soporta “oficialmente”.

Ya de paso he pensado en pasar a Plesk 9, lo que ocurre es que a día de hoy el Plesk Migration Manager que automatiza este proceso no ha sido desarrollado aún para esta nueva versión y hay que hacer el proceso a mano. Ante este problemilla vamos a seguir las instrucciones del artículo 5864 de la knowledge base de Parallels.

En este artículo nos dan tres explicaciones diferentes:

• Migrar servidor completo.
• Migrar cliente.
• Migrar dominio.

En nuestro caso vamos a migrar el contenido completo del servidor. Más adelante se verá que es una muy buena opción, ya que el nuevo sistema de backups de Plesk al basarse en plantillas XML puede restaurar clientes o dominios sueltos desde el bakup completo.

Pues ale, al turrón. Nos logueamos en el servidor, paramos los servicios para no perder información y ejecutamos el script de backup completo:

/usr/local/psa/bin/pleskbackup all archivo.backup

Con esto conseguiremos un solo fichero con todo el contenido de nuestros dominios, bases de datos, configuraciones del servidor y datos de clientes. Ok, ya tenemos los datos vitales del servidor, ahora transferimos el archivo a otra ubicación y ya podemos reinstalar el sistema operativo para cargárnoslo todo! Aunque sería recomendable usar un disco duro diferente .

Yo he elegido Fedora 8 x64 para la nueva plataforma. La versión Core 5 x64 ha funcionado estupendamente mucho tiempo y no tenía ganas de cambiar, aunque se me pasó por la cabeza intentarlo con otra ditribución. El caso es que no quería trastear mucho con experimentos para reducir el downtime del servidor. Tras instalar desde cero con las opciones básicas y actualizar viene el momento de ejecutar el script de instalación automatizado de Plesk 9. Se puede descargar desdehttp://www.parallels.com/download/plesk/products/ creando una cuenta de usuario.

Seleccionamos la instalación por defecto y esperamos a que todos los servicios se pongan en marcha solos. En cuanto acabe la instalación ya podremos entrar al panel de administración a través del navegador con la dirección de siempre, https://localhost:8443. Usuario admin contraseña setup.

Ahora lo que tenemos que hacer es convertir el archivo de backup global de la versión 8.x a la versión 9. Para esta tarea tenemos que usar un script que viene con los paquetes del componente Backup Manager de Plesk 9. Para instalarlo vamos al updater y lo seleccionamos.

En mi caso hubo un problemilla la primera vez que lo intenté instalar. El instalador se hizo un lío con las dependencias y daba un cacho error como este:

Determining the packages that need to be installed.
Unhappy catched; try to resolve again.
The requested package "psa-migration-manager" could not be
installed.
Searching problems for the "psa-migration-manager"
package.
No suitable solutions were found for the "db4-utils"
dependency.
The "db4-utils-4.6.21-2.fc8.x86_64
(u 0x2ec9a00 source=0x18dc800 P:31 R:10)"
package resolves "db4-utils".
Searching problems for the "db4-utils" package.
No suitable solutions were found for the
"db4 = 4.6.21-2.fc8" dependency.
The "db4-4.6.21-2.fc8.i386
(u 0x2ec2b20 source=0x18dc800 P:7 R:17)"
package resolves "db4 = 4.6.21-2.fc8".
Searching problems for the "db4" package.
Packages
"db4-4.6.21-2.fc8.i386
(u 0x2ec2b20 source=0x18dc800 P:7 R:17)" and
"db4-4.6.21-3.fc8.x86_64
(s 0x187a230 source=0x17d9800 P:7 R:11)"
cannot be installed at the same time
because of the conflict on the file
"/usr/share/doc/db4-4.6.21/LICENSE"
The "db4-4.6.21-2.fc8.x86_64
(u 0x2ec33d0 source=0x18dc800 P:7 R:11)"
package resolves "db4 = 4.6.21-2.fc8".
Searching problems for the "db4" package.
Packages
"db4-4.6.21-2.fc8.x86_64
(u 0x2ec33d0 source=0x18dc800 P:7 R:11)" and
"db4-4.6.21-3.fc8.x86_64
(s 0x187a230 source=0x17d9800 P:7 R:11)"
cannot be installed at the same time
because of the conflict on the file "/lib64/libdb-4.6.so"
Could
not add package db4-4.6.21-3.fc8.x86_64
(s 0x187a230 source=0x17d9800P:7 R:11)to the list of
required packages.Problem occured during
searching directly resolved dependencies for
'libdb-4.6.so()(64bit)' ofpackage db4-utils-4.6.21-2.fc8.x86_64
(u 0x2ec9a00 source=0x18dc800 P:31 R:10)

The following could cause the installation failure:
1)Packages
"db4-4.6.21-2.fc8.i386 (u 0x2ec2b20 source=0x18dc800 P:7 R:17)" and
"db4-4.6.21-3.fc8.x86_64 (s 0x187a230 source=0x17d9800 P:7 R:11)"
cannot be installed at the same time
because of the conflict on the file "/usr/share/doc/db4-4.6.21/LICENSE"

2)Packages
"db4-4.6.21-2.fc8.x86_64 (u 0x2ec33d0 source=0x18dc800 P:7 R:11)" and
"db4-4.6.21-3.fc8.x86_64 (s 0x187a230 source=0x17d9800 P:7 R:11)"
cannot be installed at the same time
because of the conflict on the file "/lib64/libdb-4.6.so"

Solución, instalar a mano el paquete db4-utils.x86_64 mediante Yum.

Ahora ya tenemos lo necesario para acabar la tarea. Ah! No… Se me olvidaba una cosa. Tenemos que modificar nuestra key de licencia para poder utilizarla en Plesk 9. Han cambiado el formato y ha pasado de ser un fichero .sh a ser un xml. Tenemos que ir a la web https://register.parallels.com/key_upgrade/ y dar nuestra dirección de correo y el número de clave. Como bien dice en esta web, el proceso vale para pasar de versión 7 a 8 y también de 8 a 9. Es un proceso irreversible y hay que hacerlo de versión en versión, es decir, no se puede pasar de 7 a 9 directamente. Importante, recuerda que tu servidor Plesk está en bragas, no uses un email que resida en él.

Tener la key preparada antes de comenzar la tarea de recuperación de datos es importante porque si no tenemos licencia para recuperar X clientes o dominios, pues no podremos restaurar nada. Ahora es el momento de transferir el archivo de backup completo al servidor y meternos en la consola para teclear:

/usr/local/psa/bin/pre9-backup-convert -v
convert -d /var/lib/psa/dumps/ archivo.backup

Este proceso descomprimirá el archivo y lo meterá en la ruta predefinida de Plesk 9 para sus backups. Mientras tanto, podemos entrar al panel web para instalar la nueva key de licencia que deberíamos haber recibido ya en nuestro (otro) correo. Vamos al menú License Management y hacemos click en el icono Upload Key.

Cuando acabe el proceso de descompresión y reubicación de nuestro  archivo de backup, podremos restaurar su contenido desde el nuevo y mejorado Backup Manager.

Hacemos click sobre el nombre del archivo, en este caso converted_info_0901281531.xml y elegimos en la siguiente pantalla nuestras preferencias de restauración.

Magia! El servidor empezará a restaurar todo el contenido del backup y lanzará un millón de warnings, pero no debería dar errores serios. Cuando acabe tendremos a nuestros clientes dados de alta con sus dominios, bases de datos y cuentas de correo operativas.  En mi caso solo me topé con un problema… el puñetero CubeCart y su sistema de encriptación PHP para que nadie copie su maravilloso y genial código fuente.

CubeCart utiliza Zend Optimizer o IonCube Loader para desencriptar sus archivos PHP protegidos. El problema es que esos archivos deben de subirse al servidor por ftp en modo binario exclusivamente. Puede que en algún momento de todo este proceso se fastidiaran, por lo que la web mostraba el error:

Fatal error: Unable to read xxxxx bytes in /admin_enc_zend.php on line 0

Primero, para instalar Zend Optimizer nos bajamos el instalador correcto para nuestro sistema operativo desde http://www.zend.com/en/products/guard/downloads. Hay que crear una cuenta de usuario. Ejecutamos el instalador con las opciones por defecto y ya lo tenemos listo. En mi caso tuve que cambiar a mano el sistema de encriptación definido para CubeCart en el fichero de configuración, ya que antes usaba IonCube Loader. Nada más sencillo que actualizar la línea:

$glob['encoder'] = 'zend';

dentro de /includes/global.inc.php

Como la versión que restauré de esta tienda CubeCart era la 4.1.1 y van por la 4.3 me decidí por subir la nueva versión completa en modo binario para solucionar el problema. Y así fue.

Hace un par de meses montamos un servidor Windows 2003 para soportar la aplicación de gestión que se usa aquí (CyberMAX) y de paso montar una pasarela Sisky (post relacionado). El caso es que en esta máquina fue donde nos gastamos algo más de pasta en protección de datos metiendo un STARDOM SR2600-2S-S2.

Se trata de un sistema RAID 1 que hace rebuilding en caliente. Cuando llega el finde o vamos a estar varios días sin aparecer por la oficina, sacamos uno de los discos para llevárnoslo a casa y  lo cambiamos por otro. Todo este rollo viene a que decidí que esta máquina (aún siendo Windows) resulta la más apropiada para concentrar el volcado de backups. Así que hice que el Plesk transfiriera a este servidor los backups programados de los clientes web por FTP y ahora le toca al Zimbra.

Vamos a usar el script desarrollado por Heinzg y que funciona correctamente bajo distribuciones basadas en Debian y en RedHat.  Lo descargamos de la web, lo metemos en la carpeta /root/scripts y lo editamos con nuestro editor favorito.

Conociendo ligeramente la lengua inglesa podemos hacernos con las opciones de configuración:

#------- CONFIG -------#
# Edit this part of the script to fit your needs.
#

Lo relativo a directorios seguramente sea del agrado de cualquiera y no necesite cambio alguno:

#--- Directories ---#
# Please add the trailing "/" to directories!
ZM_HOME=/opt/zimbra/
SYNC_DIR=/srv/backup/sync/
ARCHIVEDIR=/srv/backup/dars/
TOO_MEDIA_DIR=/srv/backup/burn/

Lo mismo para el RSync:

#
#--- PROGRAM OPTIONS ---#
RSYNC_OPTS="-aHK --delete --exclude=*.pid"

Aquí se define el nombre de archivo para el backup y prefijos incrementales para los diferenciales:

#
#--- ARCHIVE NAMES ---#
BACKUPNAME="Zimbra_Backup"
BACKUPTYPE_F="FULL"    # name prefix to sort between full and
diff backups
BACKUPTYPE_D="DIFF"
BACKUPDATE=`date +%d-%B-%Y`

Tamaño de los ficheros y nivel de compresión, por si quieres ajustarlos a algún soporte en concreto:

#
#— ARCHIVE SIZE —#
# storage media size
ARCHIVESIZE=”4395M”
COMPRESS=”9″        # valid answers are 1 – 9 ( 9 = best )

Encriptación del archivo y ruta a fichero de claves:

CRYPT="yes"        # valid answers are "yes" or "no"
PASSDIR=/etc/zmbac/
PASSFILE="noread"

Direcciones de email para notificar errores o backups satisfactorios:

#
#--- EMAIL ADDRESS ---#
EMAIL="admin@localhost"
EMAILCC="admin@remotehost"
LOG="/var/log/zim_backup.log"
 

Opción de mandar por SCP a un servidor remoto la copia realizada, especificando usuario y host. Funciona sin contraseña, por lo que debe generar una clave. Veremos como funciona más adelante:

#— SSH REMOTE DR COPY —#
# This option will secure copy you archives to a remote server
via ’scp’
DRCP=”yes”         # valid answers are “yes” or “no”
SSHUSER=”heinzg”
REMOTEHOST=”172.16.184.1″
REMOTEDIR=”/tmp/”

Uso de hacks para solucionar algunos problemillas con los procesos de Zimbra. Se recomienda dejarlo en yes:

#--- USE HACKS !?! ---#
# Built in hacks to fix common problems
#Hack to start Stats, even run zmlogprocess if needed
STATHACK="yes"         # valid answers are "yes" or "no"

A continuación lo ejecutaremos como root con la opción –INSTALL para crear la tarea programada con crontab. Como dice el propio script, hace uso de las aplicaciones apt-get (solo versiones Debian/Ubuntu), cron, dar, dpkg, mailx, md5sum, rsync, ssh, uuencode, wget, zimbra mta… Por lo que si en algún momento necesita usarlas las intentará descargar automáticamente  (solo versiones Debian/Ubuntu). En caso de Fedora/SuSe/RedHat… habrá que instalarlas a mano.

root@localhost#./zmbac.sh --INSTALL

Responderemos no a la instalación de DRCP, ya que lo haremos a mano más adelante y si a la automatización de la tarea con crontab. Nos pedirá que introduzcamos la hora y los minutos en los que deseamos realizar la copia y la ruta donde se encuentra el script (p.e. /root/scripts). Por defecto el script realiza una copia completa semanal y una diferencial diaria.

Ahora vamos a poner en marcha el servidor SSH en la máquina Windows 2003 para crear el repositorio de archivos que serán subidos automáticamente por el script mediante SCP. En mi primer intento fallido usé una versión para Windows de OpenSSH, SSHWindows. El problema es que la distribución binaria de esta aplicación es antigua, hay que hacer muchas modificaciones para que Windows 2003 se entienda con ella y no conseguí hacerla funcionar passwordless usando claves DSA. Una manera más sencilla y con configuraciones más Linuxeras es sin duda la que nos ofrece Cygwin.

Tan solo debemos seguir unas sencillas instrucciones para tenerlo funcionando. Yo seguí las instrucciones de www.netadmintools.com pero sin instalar el paquete rsync. Cuidadito si habéis instalado antes OpenSSH para windows, porque modifica la variable de entorno PATH (p.e. fallo al ejecutar el comando net) y crea un conflicto con la biblioteca cygwin1.dll propia de Cygwin. Así que desintalad y borrad toda huella relacionada con OpenSSH antes de instalar Cygwin.

Si todo ha salido bien tendremos como resultado un servidor SSH funcionando en nuestra máquina Windows 2003 que soporta separación de privilegios y autenticación por clave RSA/DSA. Si alguien se atasca en algo, ya sabe que puede usar los comentarios para preguntar.

Veamos un caso:

- El usuario root que ejecuta el script bajo crontab quiere enviar por SFTP el archivo generado a la ubicación 192.168.1.100 como el usuario zimbra.

- Resulta que no queremos que se guarde el archivo en la carpeta home creada por Cygwin para el usuario al iniciar sesión por primera vez, sino que lo queremos meter en c:/backups/zimbra.

No problem. Primero generamos la clave:

root@localhost# ssh-keygen -t dsa

Luego la copiamos a nuestro directorio home remoto:

root@localhost# scp /.ssh/id_dsa.pub zimbra@192.168.1.100:
/.ssh/authorized_keys2

Ahora desconectamos y veremos que al volver a conectar ya no pide password. Ni por SSH ni por SFTP. Siempre y cuando especifiquemos que queremos conectar con el usuario zimbra.

Ahora editamos el script y vamos a la sección:

#--- SSH REMOTE DR COPY ---#
# This option will secure copy you archives to a remote server
via 'scp'
DRCP="yes"         # valid answers are "yes" or "no"
SSHUSER="zimbra"
REMOTEHOST="192.168.1.100"
REMOTEDIR="/cygdrive/c/backups/zimbra"

Como se puede apreciar, el asunto está en especificar el directorio remoto mediante el mapeo de unidad cygdrive. Claro está que el usuario local zimbra debe existir en la máquina Windows 2003 y debe de tener permiso de escritura en la carpeta especificada.

Cabe matizar que actualmente, la máquina PFSense que gestiona el tráfico consigue alcanzar los 250Mbit/s en transmisiones troughput, es decir, entre diferentes redes. El equipo tiene un Athlon 64 4200+, tarjetas de red PCI gigabit Intel, dos GB de RAM DDR800 y una CompactFlash en lugar de disco duro. Vamos, menos de 200€.

100% 8372MB  26.2MB/s   05:19

]]> http://www.homelesshosting.net/2009/01/26/backup-script-para-zimbra-un-poco-mas-de-tranquilidad/feed/ 0 http://www.homelesshosting.net/2008/06/04/napas-para-el-qmail-del-plesk/ http://www.homelesshosting.net/2008/06/04/napas-para-el-qmail-del-plesk/#comments Wed, 04 Jun 2008 07:28:32 +0000 Ximo http://www.homelesshosting.net/?p=136

Plesk es un sistema que siempre me ha seducido por la secillez con la que trata tareas laboriosas de administración de hosting. Esa frase me delata como Lazy Admin, pero hay que tener tiempo para otras cosas! Los únicos problemas serios que me ha generado en alguna ocasión son los relativos al correo. Plesk utiliza Qmail y ciertas funciones solo pueden modificarse a mano editando sus archivos de configuración. Además, el sistema de tienda que utilizo parece que no se lleva muy bien con este MTA.

- Movida número uno:

Tengo una tienda que genera emails automáticos pero el servidor de correo es otro diferente del que alberga la web.

Pues si el DNS estuviera en su sitio no habría problema al resolver la entrada MX por defecto del dominio (digo yo), pero si el servidor con el Plesk está saliendo a Internet por NAT y tiene una IP privada se resolverá a si mismo. O eso o directamente Qmail entrega localmente, no he tenido el gusto de investigarlo.

Solución: Editar /var/qmail/control/virtualdomains y comentar la entrada correspondiente al dominio que queremos que no entrege el correo en local.

- Movida número dos:

Tengo una tienda CubeCart y no me envía los correos automáticos. Si miro el log del Qmail me sale un error que me refiere a http://cr.yp.to/docs/smtplf.html

Solución: Edita /classes/htmlMimeMail/smtp.php y modifica:

$body = str_replace(CRLF.’.', CRLF.’..’, $this->body);

$body = $body[0] == ‘.’ ? ‘.’.$body : $body;

Por:

$body = preg_replace(‘#(?<!\r)\n#’,CRLF,$this->body);

$body = str_replace(CRLF.’.', CRLF.’..’, $body);

$body = $body[0] == ‘.’ ? ‘.’.$body : $body;

- Movida número tres:

Voy a migrar una máquina con Plesk y quiero que los correos se entreguen en el servidor nuevo para no quedarme tirado mientras se refresquen los DNS, extraído de http://www.thyng.info.

Solución: El supuesto seria el siguiente, tenemos un maquina A ( IP: AA.AA.AA.AA ) que es donde tenemos actualmente el dominio ( dominio.com ) , y lo queremos trasladar a una maquina llamemosle B ( BB.BB.BB.BB ) . Entonces deberiamos crear un el siguiente fichero:

nano -w /var/qmail/control/smtproutes
Y ponemos dentro lo siguiente:
dominio.com:BB.BB.BB.BB

Depues de esto abriremos el fichero de virtualdomains, para que no entregue los correos en local
nano -w /var/qmail/control/virtualdomains

Buscaremos el nombre de nuestro dominio y pondremos una almohadilla por delante:
#dominio.com:1

Una vez hecho esto, reiniciaremos todo el plesk con:
/etc/init.d/psa stopall
/etc/init.d/psa start

Para comprobar que los correos se estan redirigiendo bien, haremos lo siguiente en el servidor viejo:
tail -f /usr/local/psa/var/log/maillog | grep dominio.com ( esto puede cambiar dependiendo de donde tengas los logs del correo )

Si al enviar un correo a tu dominio sale una linea que ponga remote, entonces lo estara enviando al servidor nuevo, como por ejemplo:
Nov 20 13:33:26 localhost qmail: 1195562006.577355 starting delivery 136: msg 262147 to remote miemail@dominio.com
Y de esta forma no perderas ningun correo y la migracion es inmediata.

Hoy bien prontito he actualizado la versión de los paquetes de Zimbra. Tenía en producción la versión 5.0.1 y he subido a la 5.0.5 por los numerosos bugs que se corrigen. Entre ellos el más puñetero era el de cargar en algunas ocasiones incorrectamente las conversaciones al responder un mensaje. Parece que solo afectaba a ciertos sistemas o navegadores, pero a mi me fallaba mucho con Firefox bajo Ubuntu. Así que sin dudarlo me he bajado el tar.gz completo y ale, le he dado a actualizar a lo bruto. No se vosotros, pero si me fio de alguna aplicación dentro del mundo del código abierto es de Zimbra. Dejo el log de lo que ha pasado:

[root@XXXXXX zcs-5.0.5_GA_2201.F7.20080417022547]# ./install.sh

Operations logged to /tmp/install.log.17123
Checking for existing installation…
zimbra-ldap…FOUND zimbra-ldap-5.0.1_GA_1902
zimbra-logger…FOUND zimbra-logger-5.0.1_GA_1902
zimbra-mta…FOUND zimbra-mta-5.0.1_GA_1902
zimbra-snmp…FOUND zimbra-snmp-5.0.1_GA_1902
zimbra-store…FOUND zimbra-store-5.0.1_GA_1902
zimbra-apache…FOUND zimbra-apache-5.0.1_GA_1902
zimbra-spell…FOUND zimbra-spell-5.0.1_GA_1902
zimbra-proxy…FOUND zimbra-proxy-5.0.1_GA_1902
zimbra-archiving…NOT FOUND
zimbra-cluster…NOT FOUND
zimbra-core…FOUND zimbra-core-5.0.1_GA_1902
ZCS upgrade from 5.0.1 to 5.0.5 will be performed.

Saving existing configuration file to /opt/zimbra/.saveconfig

PLEASE READ THIS AGREEMENT CAREFULLY BEFORE USING THE SOFTWARE.
ZIMBRA, INC. (“ZIMBRA”) WILL ONLY LICENSE THIS SOFTWARE TO YOU IF YOU
FIRST ACCEPT THE TERMS OF THIS AGREEMENT. BY DOWNLOADING OR INSTALLING
THE SOFTWARE, OR USING THE PRODUCT, YOU ARE CONSENTING TO BE BOUND BY
THIS AGREEMENT. IF YOU DO NOT AGREE TO ALL OF THE TERMS OF THIS
AGREEMENT, THEN DO NOT DOWNLOAD, INSTALL OR USE THE PRODUCT.

License Terms for the Zimbra Collaboration Suite:

http://www.zimbra.com/license/zimbra_public_eula_2.1.html

Press Return to continue

Checking for prerequisites…
NPTL…FOUND
sudo…FOUND sudo-1.6.8p12-14
libidn…FOUND libidn-0.6.8-4
fetchmail…FOUND fetchmail-6.3.7-2
gmp…FOUND gmp-4.1.4-12.3
bind-libs…FOUND bind-libs-9.4.2-3
vixie-cron…FOUND vixie-cron-4.1-84
libtool-ltdl…FOUND libtool-ltdl-1.5.22-11
/usr/lib/libstdc++.so.6…FOUND
Prerequisite check complete.
Checking for standard system perl…
Checking current number of databases…

Do you want to verify message store database integrity? [Y] Y
Verifying integrity of message store databases.  This may take a while.
mysqld is alive
Generating report
No errors found

Checking for installable packages

Found zimbra-core
Found zimbra-ldap
Found zimbra-logger
Found zimbra-mta
Found zimbra-snmp
Found zimbra-store
Found zimbra-apache
Found zimbra-spell
Found zimbra-proxy

The Zimbra Collaboration Suite appears already to be installed.
It can be upgraded with no effect on existing accounts,
or the current installation can be completely removed prior
to installation for a clean install.

Do you wish to upgrade? [Y] Y

Select the packages to install
Upgrading zimbra-core
Upgrading zimbra-ldap
Upgrading zimbra-logger
Upgrading zimbra-mta
Upgrading zimbra-snmp
Upgrading zimbra-store
Upgrading zimbra-apache
Upgrading zimbra-spell
Upgrading zimbra-proxy
Checking required space for zimbra-core
checking space for zimbra-store

Installing:
zimbra-core
zimbra-ldap
zimbra-logger
zimbra-mta
zimbra-snmp
zimbra-store
zimbra-apache
zimbra-spell
zimbra-proxy

The system will be modified.  Continue? [N] Y

Shutting down zimbra mail

Backing up the ldap database…done.

Removing existing packages

zimbra-ldap…done
zimbra-logger…done
zimbra-mta…done
zimbra-snmp…done
zimbra-store…done
zimbra-spell…done
zimbra-proxy…done
zimbra-apache…done
zimbra-core…done

Removing deployed webapp directories
Installing packages

zimbra-core……zimbra-core-5.0.5_GA_2201.F7-20080417022547.i386.rpm…done
zimbra-ldap……zimbra-ldap-5.0.5_GA_2201.F7-20080417022547.i386.rpm…done
zimbra-logger……zimbra-logger-5.0.5_GA_2201.F7-20080417022547.i386.rpm…done
zimbra-mta……zimbra-mta-5.0.5_GA_2201.F7-20080417022547.i386.rpm…done
zimbra-snmp……zimbra-snmp-5.0.5_GA_2201.F7-20080417022547.i386.rpm…done
zimbra-store……zimbra-store-5.0.5_GA_2201.F7-20080417022547.i386.rpm…done
zimbra-apache……zimbra-apache-5.0.5_GA_2201.F7-20080417022547.i386.rpm…done
zimbra-spell……zimbra-spell-5.0.5_GA_2201.F7-20080417022547.i386.rpm…done
zimbra-proxy……zimbra-proxy-5.0.5_GA_2201.F7-20080417022547.i386.rpm…done

Setting defaults from saved config in /opt/zimbra/.saveconfig/config.save
HOSTNAME=XXXXXX
LDAPHOST=XXXXXX
LDAPPORT=389
SNMPTRAPHOST=XXXXXX
SMTPSOURCE=admin@XXXXXX
SMTPDEST=admin@XXXXXX
SNMPNOTIFY=yes
SMTPNOTIFY=yes
LDAPROOTPW=HyzDGikb
LDAPZIMBRAPW=HyzDGikb
LDAPPOSTPW=HyzDGikb
LDAPREPPW=HyzDGikb
LDAPAMAVISPW=HyzDGikb
Restoring existing configuration file from /opt/zimbra/.saveconfig/config.save…done
Operations logged to /tmp/zmsetup.01001900-0000164402304.log
Starting ldap…done.
Setting defaults…done.
Upgrading from 5.0.1_GA_1902 to 5.0.5_GA_2201
Stopping zimbra services
Verifying /opt/zimbra/conf/my.cnf
Starting mysql
Starting logger mysql
Tue May  6 08:28:37 2008: SELECT value FROM config WHERE name = ‘db.version’
This appears to be 5.0.1_GA
Redolog Version: 1.21 New Redolog Version: 1.22
Tue May  6 08:28:39 2008: Verified redolog version 1.21.
Tue May  6 08:28:39 2008: Updating Redolog schema version from 1.21 to 1.22.
Schema upgrade required
Running /opt/zimbra/libexec/scripts/migrate20080130-ImapFlags.pl
Tue May  6 08:28:41 2008: Verified schema version 50.
Tue May  6 08:28:42 2008: Adding flags column to mboxgroup1.imap_message.
Tue May  6 08:28:42 2008: Adding flags column to mboxgroup10.imap_message.
Tue May  6 08:28:43 2008: Adding flags column to mboxgroup11.imap_message.
Tue May  6 08:28:43 2008: Adding flags column to mboxgroup12.imap_message.
Tue May  6 08:28:44 2008: Adding flags column to mboxgroup13.imap_message.
Tue May  6 08:28:44 2008: Adding flags column to mboxgroup14.imap_message.
Tue May  6 08:28:44 2008: Adding flags column to mboxgroup15.imap_message.
Tue May  6 08:28:45 2008: Adding flags column to mboxgroup16.imap_message.
Tue May  6 08:28:45 2008: Adding flags column to mboxgroup17.imap_message.
Tue May  6 08:28:46 2008: Adding flags column to mboxgroup18.imap_message.
Tue May  6 08:28:46 2008: Adding flags column to mboxgroup19.imap_message.
Tue May  6 08:28:47 2008: Adding flags column to mboxgroup2.imap_message.
Tue May  6 08:28:47 2008: Adding flags column to mboxgroup20.imap_message.
Tue May  6 08:28:48 2008: Adding flags column to mboxgroup21.imap_message.
Tue May  6 08:28:48 2008: Adding flags column to mboxgroup22.imap_message.
Tue May  6 08:28:49 2008: Adding flags column to mboxgroup23.imap_message.
Tue May  6 08:28:49 2008: Adding flags column to mboxgroup24.imap_message.
Tue May  6 08:28:49 2008: Adding flags column to mboxgroup25.imap_message.
Tue May  6 08:28:50 2008: Adding flags column to mboxgroup26.imap_message.
Tue May  6 08:28:50 2008: Adding flags column to mboxgroup3.imap_message.
Tue May  6 08:28:51 2008: Adding flags column to mboxgroup4.imap_message.
Tue May  6 08:28:51 2008: Adding flags column to mboxgroup5.imap_message.
Tue May  6 08:28:52 2008: Adding flags column to mboxgroup6.imap_message.
Tue May  6 08:28:52 2008: Adding flags column to mboxgroup7.imap_message.
Tue May  6 08:28:53 2008: Adding flags column to mboxgroup8.imap_message.
Tue May  6 08:28:53 2008: Adding flags column to mboxgroup9.imap_message.
Tue May  6 08:28:54 2008: Verified schema version 50.
Tue May  6 08:28:54 2008: Updating DB schema version from 50 to 51.
Running /opt/zimbra/libexec/scripts/migrate20080213-IndexDeferredColumn.pl
Tue May  6 08:28:56 2008: Verified schema version 51.
Tue May  6 08:28:56 2008: Adding idx_deferred_count column to Mailbox table.
Tue May  6 08:28:57 2008: Verified schema version 51.
Tue May  6 08:28:57 2008: Updating DB schema version from 51 to 52.
Stopping mysql
Stopping logger mysql
Checking ldap status
Starting ldap
Checking 3.0.M1
Checking 3.0.0_M2
Checking 3.0.0_M3
Checking 3.0.0_M4
Checking 3.0.0_GA
Checking 3.0.1_GA
Checking 3.1.0_GA
Checking 3.1.1_GA
Checking 3.1.2_GA
Checking 3.1.3_GA
Checking 3.1.4_GA
Checking 3.2.0_M1
Checking 3.2.0_M2
Checking 4.0.0_RC1
Checking 4.0.0_GA
Checking 4.0.1_GA
Checking 4.0.2_GA
Checking 4.0.3_GA
Checking 4.0.4_GA
Checking 4.0.5_GA
Checking 4.1.0_BETA1
Checking 4.5.0_BETA1
Checking 4.5.0_BETA2
Checking 4.5.0_RC1
Checking 4.5.0_RC2
Checking 4.5.0_GA
Checking 4.5.1_GA
Checking 4.5.2_GA
Checking 4.5.3_GA
Checking 4.5.4_GA
Checking 4.5.5_GA
Checking 4.5.6_GA
Checking 4.5.7_GA
Checking 4.5.8_GA
Checking 4.5.9_GA
Checking 4.6.1_RC1
Checking 4.5.10_GA
Checking 4.5.11_GA
Checking 5.0.0_BETA1
Checking 5.0.0_BETA2
Checking 5.0.0_BETA3
Checking 5.0.0_BETA4
Checking 5.0.0_RC1
Checking 5.0.0_RC2
Checking 5.0.0_RC3
Checking 5.0.0_GA
Checking 5.0.1_GA
Updating from 5.0.1_GA
Updating attributes for default COS…
Checking 5.0.2_GA
Updating from 5.0.2_GA
Moving postfix queues from 2.4.3.3z to 2.4.3.4z
Moving defer
Moving deferred
Checking 5.0.3_GA
Updating from 5.0.3_GA
Migrating Amavis database directory
Migrating Postfix spool directory
Checking 5.0.4_GA
Updating from 5.0.4_GA
Checking 5.0.5_GA
Updating from 5.0.5_GA
Stopping ldap
Checking ldap status
Starting ldap
Stopping ldap
Upgrade complete
Setting defaults from existing config…done.
Checking for port conflicts
Starting ldap…done.
Setting defaults from ldap…done.
Saving config in /opt/zimbra/config.1221…done.
Operations logged to /tmp/zmsetup.01001900-0000164402304.log
Setting local config values…done.
Setting up CA…done.
Deploying CA to /opt/zimbra/conf/ca …done.
Setting replication password…done.
Setting Postfix password…done.
Setting amavis password…done.
Saving CA in ldap …done.
Creating server entry for XXXXXX…done.
Saving SSL Certificate in ldap …done.
Setting spell check URL…done.
Setting service ports on XXXXXX…done.
Adding XXXXXX to zimbraMailHostPool in default COS…done.
Installing skins…
steel
waves
yahoo
hotrod
bare
sand
bones
lavender
beach
lemongrass
sky
done.
Setting Keyboard Shortcut Preferences…done.
Setting zimbraFeatureIMEnabled=TRUE…done.
Setting zimbraFeatureTasksEnabled=TRUE…done.
Setting zimbraFeatureBriefcasesEnabled=TRUE…done.
Setting zimbraFeatureNotebookEnabled=TRUE…done.
Setting MTA auth host…done.
Setting TimeZone Preference…done.
prov> Creating user spam.it0igdvq@XXXXXX…done.
Creating user ham.glpwnxxn@XXXXXX…done.
Setting spam training accounts…done.
Initializing mta config…done.
Configuring SNMP…done.
Setting services on XXXXXX…done.
Setting up zimbra crontab…done.
Setting up syslog.conf…done.

You have the option of notifying Zimbra of your installation.
This helps us to track the uptake of the Zimbra Collaboration Suite.
The only information that will be transmitted is:
The VERSION of zcs installed (5.0.5_GA_2201_F7)
The ADMIN EMAIL ADDRESS created (admin@XXXXXX)

Notify Zimbra of your installation? [Yes] YES
Notifying Zimbra of installation via http://www.zimbra.com/cgi-bin/notify.cgi?VER=5.0.5_GA_2201_F7&MAIL=admin@XXXXXX

Notification complete

Starting servers…done.
Checking for deprecated zimlets…done.
Installing zimlets…
com_zimbra_date
com_zimbra_email
com_zimbra_local
com_zimbra_cert_manager
com_zimbra_phone
com_zimbra_url
done.
Initializing Documents…done.
Restarting mailboxd…done.

Moving /tmp/zmsetup.01001900-0000164402304.log to /opt/zimbra/log

Configuration complete – press return to exit

Basado en el turorial http://pfsense.iserv.nl/tutorials/policybased_multiwan/policybased_multiwan.pdf

Tener en tu empresa tus propios servidores de correo o tus propias webs/tiendas online resulta comodísmo para trabajar a gran velocidad en red local con tus datos. Evidentemente, si quieres que estas máquinas sean accesibles desde el exterior necesitas un entorno seguro y una conexión a Internet con el caudal adecuado a las necesidades de tus servicios.

El montaje inicial que tenía para mis servidores era un poco problemático porque no gestionaba desde el PFSense la conexión WAN de la DMZ. Tenía una ruta estática para que las dos redes se vieran, pero el rendimiento era bastante bajo. En este entorno el router de Jazztel era la puerta de enlace de los servidores donde estaba configurado todo el NAT (con port mappings) y la ruta hacia la LAN por la Interfaz DMZ del PFSense.

Vamos a ver como configurar el firewall PFSense, ya en su nueva versión 1.2 estable, para tener un entorno sencillo de LAN + WAN + DMZ + WAN de la DMZ. La idea principal es manejar desde PFSense todo lo relativo a NAT y controlar las reglas para el tráfico que se va a mover en nuestra red.

Pongamos que disponemos de 2 IPs públicas y queremos hostear un servidor de correo y otro web. Tenemos una conexión SHDSL de un proveedor (Jazztel) con una configuración NAT sencilla (Zyxel 792H) que será usado exclusivamente para estos servidores. Los usuarios saldrán a Internet a través de la interfaz WAN por defecto (Ono), que en este caso está conectada a un cablemódem.

Para que todo esto funciona necesitamos tener una máquina corriendo PFSense con cuatro tarjetas de red. Dos de ellas para las conexiones WAN, una para la LAN y otra para la DMZ. Si os queréis gastar algo de dinero para ver el potencial real de PFSense, lo ideal es montar una máquina dual core para usar el kernel de multiprocesador de FreeBSD y poner tarjetas Gigabit PCI-Express (preferiblemente Intel).

La configuración se basa en tener cuatro redes diferenciadas y realizar una serie de reglas para que se comuniquen óptimamente entre ellas, utilizando siempre como centro de operaciones para cualquier configuración el PFSense. Vamos a usar el sistema de IPs virtuales para que los servidores residan físicamente en una red (DMZ) pero “existan” también para el router en su propia red (Jazztel).

• Habilitamos las cuatro tarjetas de red.

• Configuramos la interfaz WAN por defecto (Ono) en DHCP. A esta tarjeta de red conectaremos directamente el cablemodem.
• Asignamos IPs a las interfaces LAN y DMZ.
• Asignamos IP a la interfaz JAZZTEL y especificamos la dirección del router por defecto para esta red.

• En la sección Firewall->NAT activamos Manual Outbound NAT rule generation, dentro de la pestaña Outbound. De esta manera podremos elegir como queramos la manera en que cualquier equipo conectado a nuestra red sale a Internet.



• Como probablemente hayamos dejado a nuestros equipos en la LAN sin Internet tras esta operación, tendremos que habilidar la salida LAN hacia la WAN. Esta sección de configuraciones es muy delicada, ya que al activar Advanced Outbound NAT el firewall solo hace caso a las reglas que aquí definamos para sacar tráfico de las diferente redes. Podemos tener también bajo este apartado una serie de reglas desactivadas para casos de failover que activemos cuando sea necesario. Un ejemplo sería crear una regla para direccionar el tráfico de nuestro servidor Asterisk en el puerto IAX2/SIP a través de otra WAN, así no perderíamos la conectividad con nuestro proveedor de voz IP si se cayera la conexión de Ono.



• Suponiendo que hemos configurado el router de la WAN de la DMZ (Zyxel 792h) para que nuestras IPs públicas se comuniquen 1:1 con nuestras IPs privadas todo lo siguiente es pan comido.





• Vamos a tomar como ejemplo el servidor de correo que reside en la LAN con la IP 172.16.15.100 pero está configurado en el router de Jazztel como 172.17.14.100. Esta IP virtual la tenemos que añadir en la sección Firewall->Virtual IPs de la siguiente manera:

• Ahora volvemos a Firewall->NAT y entramos en la pestaña Outbound para añadir una regla que traduzca todo el tráfico saliente de 172.16.15.100 (servidor de correo físico en la DMZ) en 172.16.14.100 (servidor de correo virtual) usando la puerta de enlace predeterminada de la red de destino (172.17.14.0/24) que es 172.16.14.2 (router Jazztel).

• Para finalizar solo nos queda crear una regla en Firewall->Rules para permitir el tráfico desde la DMZ hacia *any* a través de la puerta de enlace que definimos en la red JAZZTEL.

• Ya tenemos configurado el sistema de enrutamiento, pero ahora para que nuestras máquinas se vean desde el exterior tenemos que definir mapeos de puertos. Definiremos la IP local física, la IP virtual y el puerto que queremos direccionar.

No soy ingeniero (aún) ni tengo mucha experiencia en redes avanzadas, pero me parece que este metodo es bastante seguro y expande las funciones que nos da por defecto una conexión semi-profesional. Se agradecerían comentarios y sugerencias.