Cuando intentaba acceder a una partición NFS de un servidor in lenny desde un cliente en squeeze, obtuve varios “Permission Denied” (Permiso Denegado) al intentar escribir un archivo. Como existen otros clientes NFS que pueden escribir al servidor, no se trataba de configuración sino más bien de la versión del nuevo cliente.

Después de buscar un poco, encontré este bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=492970

Si quieres saber si tu versión tiene este problema, puedes verificarlo con el comando: “cat /proc/mounts” notarás que el NFS tiene un parámetro “sec=null” y es lo que genera el problema.

El arreglo es un fácil:

1. Desmontar todas las particiones NFS (muy importante, en mi caso tenía dos particiones y solo desmonté una e intenté pasar la nueva configuración que no funcionó hasta que desmonté las dos particiones)
2. En /etc/fstab (o al montarlo manualmente)  pasar el parámetro sec=sys para todas las particiones de ese servidor, por ejemplo para fstab:
   example.com:/shared /tmp/shared nfs rw,sec=sys 0 0
   O de forma manual
   mount -t nfs -o "rw,sec=sys" example.com:/shared /tmp/shared
3. Montar todas las particiones de ese servidor

Al verificar nuevamente /proc/mounts verás el parámetro sec=sys en lugar de null

Cuando se desarrolla en un branch de SVN el mayor problema es mantener actualizados los archivos que estamos modificando con los cambios que se hacen en la rama principal (trunk) de SVN. Para hacer más fácil esto, he creado un script que checa los archivos cambiados en nuestro branch y checa con los archivos modificados del principal, la manera de invocarlo es simple:

php changes-branch.php BASE_SVN PROYECTO BRANCH

Así por ejemplo si nuestro svn está en: http://svn.example.com/proyecto y nuestro branch es: http://svn.example.com/proyecto/branches/cambios debemos invocar el programa como:

php changes.branch.php http://svn.example.com proyecto cambios

El sistema mostrará cuales archivos han tenido cambios desde nuestra última actualización de nuestro branch, así como la salida del diff para ver los cambios.

El script también tiene una opción que les permite ver todos los cambios desde que se inició el branch, simplemente agregar un cuarto parámetro, por ejemplo:

php changes-branch.php BASE_SVN PROYECTO BRANCH true

El código completo está aqui: https://github.com/danguer/blog-examples/blob/master/php/svn/changes-branch.php

En un proyecto, estaba utilizando Zend_Date para manejo de horas en diferentes zonas horarias, cuando lo estaba desarrollando empecé a tener un error porque olvidé que la fecha se actualiza cuando cambias un parámetro y el problema surge cuando cambias el mes o día y se encuentra con una fecha inexistente aunque en el código parezca correcta, por ejemplo, supongamos que estamos en el mes de febrero y queremos crear una fecha de marzo (asignaré la fecha para reproducir el error, aunque el error es cuando se utiliza la fecha actual)

include_once("Zend/Date.php");
$fecha_febrero = mktime(0, 0, 0, 2, 1, 2010);
$fecha = new Zend_Date($fecha_febrero);
$fecha->setDay(31);
$fecha->setMonth(3);
print "Fecha Marzo: ".date("d/m/Y", $fecha->getTimestamp());

Uno esperaría que el resultado fuera: 31/03/2010

Pero en su lugar mostrará 03/03/2010

Esto es porque al hacer $fecha->setDay(31) el sistema intenta crear la fecha: 31/02/2010 que no existe, por lo que “recorre” los días restantes para quedar en 03/03/2010, al asignar el mes, no tiene efecto.

La solución es simplemente hacerlo en orden inverso:

include_once("Zend/Date.php");
$fecha_febrero = mktime(0, 0, 0, 2, 1, 2010);
$fecha = new Zend_Date($fecha_febrero);
$fecha->setMonth(3);
$fecha->setDay(31);
print "Fecha Marzo: ".date("d/m/Y", $fecha->getTimestamp());

Eso parecería la solución ideal (y es la recomendada por la documentación), pero no es totalmente cierta, si por ejemplo estamos en enero 31 del 2010 e intentamos asignar una fecha de febrero, siempre obtendremos una fecha de marzo:

include_once 'Zend/Date.php';
$fecha_enero = mktime(0, 0, 0, 1, 31, 2010);
$fecha = new Zend_Date($fecha_enero);
$fecha->setMonth(2);
$fecha->setDay(10);
print "Fecha Febrero: ".date("d/m/Y", $fecha->getTimestamp());

Uno esperaría que mostrara la fecha:
10/02/2010

Pero en realidad muestra
10/03/2010

Esto porque cuando asignamos el mes, el sistema intenta crear la fecha 31/03/2010 que una vez más es incorrecta, por lo que crea la fecha 03/03/2010, pero al asignar la fecha, el resultado es un error en el mes.

Aunque esto no es un error, es muy peligroso porque uno puede suponer que la fecha es correcta porque en el código lo parece, la solución sin embargo es trivial, asignar el primer día de un mes que tenga 31 días y asignar los valores en orden inverso (primero año, luego mes y por último día), así el código sin error sería:

include_once 'Zend/Date.php';
$fecha = new Zend_Date(0, 0, 0, 1, 1, date('Y'));
$fecha->setMonth(2);
$fecha->setDay(10);
print "Fecha Febrero: ".date("d/m/Y", $fecha->getTimestamp());

Resultado (el esperado)
10/02/2010

Esto funciona en la mayoría de los casos; aunque si van a manejar diferentes zonas horarias mediante setTimezone() el código anterior tendrá el mismo error en los casos que la zona horaria sea menor a la zona horaria del servidor, por lo que hay que hacer algo más elaborado:

include_once 'Zend/Date.php';
$fecha = new Zend_Date();
//eliminar "errores"
$fecha->setTimezone('mi_codigo_zona_horaria');
$fecha->setDay(1);
$fecha->setMonth(1);

//nuestro código
$fecha->setMonth(2);
$fecha->setDay(10);
print "Fecha Febrero: ".date("d/m/Y", $fecha->getTimestamp());

Lo peligroso del comportamiento de Zend_Date es que funcionará con errores durante algunos días/meses dependiendo de la manera en como se programe y es un poco difícil de diagnosticar por su misma naturaleza, con esto se elimina cualquier tipo de errores.

Mientras estaba haciendo un pequeño calendario que mostrara fechas con ligas a otras parte del sitio, pensé que la manera más fácil era evitar llamar a strototime:

strtotime("+1 days", $time)

y en su lugar utilizar directamente la suma de 86,400 segundos que es un día:

60 * 60 segundos = 3600 segundos (1 hora) * 24 = 86400

El calendario no tenía ningún problema hasta que noté que tenía repetido dos veces el día 1º de noviembre, los tiempos eran los siguientes (tiempo Unix):

1257051600: 2009-11-01 00:00:00
1257138000: 2009-11-01 23:00:00

Si hacen la suma, observarán que se sumó 86,400 segundos a una fecha y otra; pero el tiempo regresado por PHP (de hecho por el sistema Linux) es de 23 horas y no 24 horas.

Hice algunas pruebas en otros servidores y solo uno imprimió la fecha que esperaba (2009-11-02 00:00:00), la primera idea (por el cansancio) fue que era un error de PHP/Linux. Buscando un posible error, encontré algunas preguntas que como yo habían tenido un problema similar, pero mencionaban algo de la zona horaria, eso me recordó que el 1º de Noviembre en México atrasamos el reloj una hora por lo que en realidad el cálculo era correcto desde la perspectiva de Linux ya que estaba olvidando esa “hora perdida” en mis cálculos, el servidor que regresó bien la fecha estaba en otra zona horaria por lo que no compartían nuestro cambio de horario.

El tiempo Unix correcto es: 1257141600 no es otra cosa que es el día (86400) más la hora “perdida” (3600), este tiempo lo obtuve llamando a strtotime en PHP en lugar de calcularlo por mi cuenta.

Moraleja: Manipular el tiempo Unix de forma directa agregando valores puede ser muy rápido y simplifica la implementación, pero si quieres hacer algo que no tenga errores utiliza siempre las funciones de tiempo de PHP/Linux.

Recientemente tuve que “dumpear” todas las bases de datos de un servidor por lo que utilice un script muy simple para hacerlo:

USER=root;PASS=mi_pass;for database in `echo "SHOW DATABASES" | mysql --user=$USER --password=$PASS | sed '1d'`; do mysqldump --user=$USER --password=$PASS $database > $database.sql; tar jcvf $database.tar.bz2 $database.sql; rm $database.sql; done

Un poco más leible:

USER=root
PASS=mi_pass
for database in `echo "SHOW DATABASES" | mysql --user=$USER --password=$PASS | sed '1d'`
do
    mysqldump --user=$USER --password=$PASS $database > $database.sql
    tar jcvf $database.tar.bz2 $database.sql
    rm $database.sql
done

Básicamente manda todas las bases de datos y quita la linea inicial (que siempre es Databases) y por cada base de datos invoca mysqldump y por último lo comprime con bunzip2 para obtener un archivo muy pequeño y por supuesto elimina las “fuentes” de sql.

Algo muy útil es iniciar/apagar automáticamente dominios XEN cuando se reinicia o apaga el anfitrión (dom0), cuando se instala XEN, por defecto deberemos ver creado un directorio llamado /etc/xen/auto

En este directorio el script /etc/init.d/xendomains buscará las configuraciones de las máquinas virtuales a iniciar/detener estos pueden ser vínculos simbólicos a las verdaderas configuraciones.

Para que todo esto suceda en primer lugar debes de tener el script /etc/init.d/xendomains que se instala junto con /etc/init.d/xend

También debes haber habilitado el inicio de este script con el siguiente comando:

update-rc.d xendomains defaults 21 20

 
El script /etc/init.d/xendomains necesita del archivo de configuración: /etc/sysconfig/xendomains

En este verás una línea que contiene:

XENDOMAINS_AUTO=/etc/xen/auto

Con esto definimos el directorio donde se buscarán los dominios que se auto iniciarán

Usualmente uso el famosímo scp para transferir archivos, el problema es que al parecer scp es muy lento cuando se trata de muchos archivos pequeños. 

rsync es un comando para hacer réplicas de un directorio a otro lugar, lo que hace es checar el comparar los directorios y copiar todos los archivos que hayan sido modificados, que sean nuevos o incluso que hayan sido elminados para hacer una copia exacta.

La gran ventaja de rsync es que aparte de crear una réplica, es sorprendentemente rápido, en especial con archivos pequeños.

El uso es muy simple:

rsync -az -e ssh FUENTE usuario@servidor:DESTINO

Eso es todo, para que funcione ambos servidores deben tener el programa rsync instalado, FUENTE es el directorio local a copiar (o puede ser un archivo), DESTINO es el directorio del servidor remoto a donde se copiará.

La opción -az envia la información compresa y -e ssh indica que hay que usar el programa ssh para transferir los archivos (con esto se puede enviar también mediante ftp, etc)

Otra opción que uso mucho es --delete, de esta manera rsync también borrará los archivos “extra” para que la copia sea exacta. Hay que tener cuidado, porque en algo descuidado se pueden borrar los archivos locales (inversión de parámetros)… algo que me pasó una vez, pero tenía respaldo =).

En Xen, si no configuras de antemano linux verás que después de iniciar varios servidores virtuales te marcará un error que dice: “Failed to find an unused loop device”

Esto significa que linux ya no tiene “lugar” para montar más dispositivos loop (montar tu disco duro virtual o swap), por defecto tienes ochos dispositivos loop permitidos, que son para cuatro máquinas virtuales (debido a que utilizan al menos dos imágnes, una para el swap y otra para el disco duro)

Para aumentar este límite es muy fácil, primero detienes las instancias virtuales de Xen:

/etc/init.d/xendomains stop

Agregas al archivo /etc/modprobe.d/local-loop lo siguiente (o crealo si no existe):

options loop max_loop=64

Después vuelves a cargar el módulo

rmmod loop
modprobe loop

Por último inicias las instancias virtuales

/etc/init.d/xendomains start

Con esto puede tener hasta 32 instancias de Xen sin problemas.

Hace poco instalé un servidor Xen, después para terminar de configurarlo solicitamos IP’s adicionales para que cada servidor virtual tuviera su IP dedicada.

Lamentablemente nos dieron IPs en otra subred, esto puede ocasionar algunos problemas pero aqui está una solución =)

Vamos a suponer que nuestro servidor Xen tiene ip 192.168.1.90 y que nuestras nuevas ips a asignar son 192.168.247.130 y 192.168.247.131, y que el gateway de nuestra máquina anfitrión es 192.168.1.1

Configuración de Xen

Debido a que en mi caso necesitaba rutear los datos entre mi máquina anfitrión (dom0) y mis máquinas virtuales (domU) habilité lo siguiente en xen:

(network-script network-route)
(vif-script vif-route)

Tanto network-script  y vif-script deben ser las únicas configuraciones disponibles (esto es comentar todos los otro network-script y vif-script)

Reiniciamos el servidor Xen:

/etc/init.d/xend restart
/etc/init.d/xendomains restart 

Es muy importante que verifiques si te marca un error, ya que a mi me mandaba un error por un script que no reconocía la interfaz que ibamos a utilizar, así que hice el siguiente cambio en el archivo: /etc/xen/scripts/network-route

dir=$(dirname "$0")

. "$dir/xen-script-common.sh"

evalVariables "$@"

 

#netdev=${netdev:-eth${vifnum}}

netdev=eth0 #definir por defecto la interfaz a utilizar

echo 1 >/proc/sys/net/ipv4/ip_forward
echo 1 >/proc/sys/net/ipv4/conf/${netdev}/proxy_arp

Básicamente lo que hace el script de Xen es habilitar el ruteo en linux y crear unas reglas de iptables (que tu puedes configurar si quieres personalizar el rendimiento o seguridad de tus máquinas virtuales por medio del anfitrión)

Ya por último debes borrar el puente que hace Xen en la configuración por defecto de bridge (usando el comando brctl)

Configuración de la Imagen

Al crear la imagen. proporciona la IP, el gateway de tu máquina anfitrión (dom0) y la máscara de red correspondiente, en nuestro ejemplo 255.255.0.0, ejemplo:

xen-create-image --hostname=misitio.com --ip=192.168.247.130 --netmask=255.255.0.0 --gateway=192.168.1.1 --passwd

Con esto tus máquinas clientes podrán ser vistas y accesar a internet sin problemas.

Recientemente me tocó configurar un servidor para tener máquinas virtuales mediante XEN. Anteriormente sólo había trabajado con un poco con VMWare ESXi y XenServer (la versión “comercial” de XEN), el problema es que se tenía que instalar en un servidor remoto que solo se tiene acceso mediante ssh.

Con algo de trabajo y pruebas (y con las buenas herramientas de ServerBeach, que sólo le faltan una vista a la consola para diagnosticar kernel panics) por fin pude instalarlo.

Debian tiene una versión de Xen, pero es la 3.0.3 que para mi gusto es demasiado vieja (se liberó en 2006) y la versión Lenny (testing) tiene la versión 3.2, pero también algo “inestable” a mi gusto para un servidor de batalla.

Como dije después de hacer varias pruebas logré instalar la versión Xen 3.3 utilizando el kernel que viene en Debian preparado para Xen.

Una breve descripción de Xen, es que está separado en varias partes, en primer lugar Xen tiene un kernel modificado para llevar a cabo la virtualización, la ventaja es que la versión 3.3 utiliza la versión 2.6.18 que es la que viene con Debian.

Después la parte “fuerte” de Xen es el denominado hypervisor que es un servidor que se encarga de hacer la virtualización propiamente dicha. Después vienen las máquinas virtuales que utilizan por lo general otro kernel que se denomina domU (y el kernel de la máquina base se denomina dom0).

Pues bien, para lograr esto simplemente primero instalé la imagen del kernel apropiado y compilar solamente el hypervisor de Xen 3.3

En pasos simples:

#Instalar la imagen del kernel con parche para xen
apt-get install linux-image-2.6.18-6-xen-amd64

#Descargar el código fuente de xen
wget http://bits.xensource.com/oss-xen/release/3.3.0/xen-3.3.0.tar.gz
tar zxvf xen-3.3.0.tar.gz
cd xen-3.3.0

#Compilar solamente el hypervisor
make xen
make install-xen

#Compilar los archivos ejecutables como xm y herramientas de red
make tools
make install-tools

#Hacer que Debian cree las entradas correspondientes en los rc.X
#para que cuando el servidor se inicie ejecute los servidores de Xen
update-rc.d xend defaults 20 21
update-rc.d xendomains defaults 21 20

#Hacer que grub reconozca el nuevo kernel con la configuración de Xen 3.3.0
update-grub

Con eso deberían de ver una entrada en el grub como:

title           Xen 3.3.0 / Debian GNU/Linux, kernel 2.6.18-6-xen-amd64
root            (hd0,0)
kernel          /xen-3.3.0.gz
module          /vmlinuz-2.6.18-6-xen-amd64 root=/dev/sda6 ro console=tty0
module          /initrd.img-2.6.18-6-xen-amd64
savedefault

Que debería de bootear con el hypervisor 3.3

Incluyo algunas ligas de sitios (en inglés) que me ayudaron muchísimo para entender algo más de Xen

• http://www.howtoforge.com/debian_etch_xen_3.1_p5 (muy buen documento)
• http://27smiles.com/2008/08/08/setting-up-xen-on-debian-etch-64bit/ (para instalar Xen con las versiones estables de Debian)
• http://www.nabble.com/Xen-3.3-install-from-source-on-centos-5.2-td19761354.html (Otra versión de como compilar Xen, incluye copiar la configuración actual, en el ejemplo de CentOS pero puede ser de Debian, algo que no solucionó mi problema, pero es buena idea)
• http://xen-tools.org/software/xen-tools/releases.html (Herramientas de ayuda para Xen, descárguenla, ya que la versión estable de Debian es vieja y no necesita muchas cosas, si les pide algo chequen la primera liga)