Migración de Plesk 8.6 a 9 en mismo hardware, cambiando sistema operativo.

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.

Backup Script para Zimbra. Un poco más de tranquilidad.

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

Ñapas para el Qmail del Plesk

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.

Sin miedo

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

PFSense multiwan con DMZ.

Como mañana tengo el examen de comentario de texto, voy a intentar relajarme y practicar un poco de escritura acabando un artículo que tengo desde hace tiempo en el tintero.

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.