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

Ubuntu 8.04: Carga automáticamente aplicaciones en diferentes workspaces

Al iniciar los thin clients de la empresa tenía claro que quería que apareciese automáticamente todo lo que el usuario necesita para trabajar. El brusco cambio de Windows a Linux a veces es duro para los usuarios porque no “encuentran las cosas”.

Arrancar aplicaciones al inicio de Gnome es una tarea sencilla. Basta con añadir entradas al menú Sistema->Preferencias->Sesiones. El problema es que al ser rdesktop una de esas aplicaciones prefería que los demás programas (Evolution, aMSN, X-Lite…) se iniciaran en otro escritorio.

Para esto existe una pequeña aplicación para Gnome llamada Devil’s Pie. La instalamos haciendo:

sudo apt-get instal devilspie

Y creamos en nuestra carpeta de usuario el directorio /.devilspie. Dentro de ese directorio tenemos que crear los archivos .ds para cada aplicación. La sintaxis no es muy complicada, por ejemplo, yo uso para Evolution:

#evolution.ds

(if
(is (application_name) "Firefox")
(begin
(set_workspace 2)
(maximize)
)
)

Para que funcione al iniciar sesión hay que añadir la aplicación devilspie al inicio de Gnome a través del menú anteriormente citado: Sistema->Preferencias->Sesiones

Al rico parche

Si se te fue la mano al actualizar el kernel en tu Fedora 8 y ahora no puedes recompliar los módulos de VMWare, en HowToForge tienen un tutorial y un parche para solucionarlo.

http://howtoforge.com/vmware-server-1.0.4-fedora8-kernel-2.6.24