Jan 25, 2009

Instalar openSUSE desde una memoria USB

El fin de semana pasado quise probar la distribución de Linux OpenSUSE 11.1 en mi portátil. Debido a que éste no tiene lector de DVDs o CDs, necesitaba crear un LiveCD dentro de un pendrive USB.

Me descargué el LiveCD KDE4 de 64 bits, y probé a crear la memoria auto-arrancable a través de la aplicación usb-creator. La utilidad no me dejó: "This is not a desktop install CD and thus cannot be used by this application". En otras palabras, usb-creator no está hecho para openSUSE, ya que el LiveCD sí que es instalable.

Así que como alternativa me descargué el paquete UNetbootin y lo instalé en mi Kubuntu 8.10. Esta aplicación necesita un par de dependencias que tendremos que instalar previamente: los paquetes syslinux y p7zipfull.

# aptitude install syslinux p7zipfull

# dpkg -i unetbootin_304-1_i386.deb


Para crear el LiveCD a través de UNetbootin necesitaremos una memoria USB con un tamaño mínimo de 1 GB. Primero seleccionaremos la opción de Diskimage, y escogeremos la ISO de openSUSE. A continuación indicaremos dónde se encuentra la memoria extraíble (/dev/sdb1 en mi caso) y pulsaremos sobre el botón OK para iniciar el proceso de creación.


A partir de este momento, para poder instalar openSUSE en nuestro ordenador a través de la memoria USB auto-arrancable que acabamos de crear, tendremos que iniciar el equipo utilizando como primer dispositivo de arranque el interfaz USB (configurable desde la BIOS).

A continuación puede verse una captura de pantalla del Escritorio que obtenemos al instalar openSUSE 11.1.

Jan 22, 2009

Servicio FTP mediante vsftpd

En el artículo anterior, se expuso el desarrollo de un espacio compartido en red mediante GlusterFS. A través de esta aplicación, establecimos un directorio común de trabajo (/var/www/html/) para los servidores Apache de los dos nodos traseros. Este área compartida también será utilizada por el servicio FTP que configuraremos en dichos nodos a través de vsftpd.

Vsftpd es un servidor FTP para los sistemas operativos de tipo GNU/Linux. Vamos a comenzar instalando vsftpd (versión 2.0.7) en ambos nodos traseros (LB1 y LB2).

root@lb1:~# aptitude install vsftpd

root@lb2:~# aptitude install vsftpd


Después vamos a editar su fichero de configuración (/etc/vsftpd.conf), dejando las opciones que vienen por defecto y modificando las mostradas a continuación.

root@lb1:~# cat /etc/vsftpd.conf
...
# El demonio vsftpd permanecerá a la escucha de peticiones de conexión
listen=YES
...
# No permitir el acceso al servicio FTP a usuarios anónimos
anonymous_enable=NO
...
# Permitir el acceso FTP a usuarios locales del sistema
local_enable=YES
...
# Permitir la escritura en el servidor
write_enable=YES
...
# Cambiar a 022 los permisos de los usuarios locales
local_umask=022
...
# Mensaje de bienvenida para los usuarios que se logueen
ftpd_banner=Welcome to LB1 FTP service.
...
# Enjaular a los usuarios que se conecten (sólo podrán moverse por aquellas carpetas para las que tengan permiso)
chroot_local_user=YES


Este fichero de configuración será común para los dos nodos, por eso sólo se ha mostrado el de la máquina LB1. La única diferencia en el fichero de configuración del nodo LB2, será el mensaje de bienvenida para el usuario.

root@lb2:~# cat /etc/vsftpd.conf
...
# Mensaje de bienvenida para los usuarios que se logueen
ftpd_banner=Welcome to LB2 FTP service.
...


El resto de operaciones que quedan por completar, serán similares en ambos nodos. Por dicho motivo sólo se expondrán las del nodo LB1.

A continuación habrá que crear un usuario denominado userftp, el cual utilizaremos para acceder al servicio FTP. A través del fichero /etc/passwd, asociaremos a dicho usuario la carpeta compartida en red (/var/www/html/).

root@lb1:~# adduser userftp

root@lb1:~# cat /etc/passwd

...
userftp:x:1001:1001:,,,:/var/www/html/:/bin/sh

Y el último paso consistirá en otorgar permisos de lectura, escritura y ejecución a dicho directorio. Para que los cambios surjan efecto, reiniciaremos el servicio FTP.

root@lb1:~# chmod 777 /var/www/html/

root@lb1:~# /etc/init.d/vsftpd restart

Jan 13, 2009

Sistema de archivos en red con GlusterFS

Una vez establecidos los parámetros iniciales del cluster, vamos a continuar con la configuración del espacio compartido en disco por los dos nodos traseros (LB1 y LB2) a través de GlusterFS (sistema de archivos distribuido empleado habitualmente para implementar clusters de ficheros a través de varios discos interconectados mediante una arquitectura TCP/IP).

GlusterFS sólo se instalará en estos dos nodos, ya que éstas serán las máquinas que reciban la carga de trabajo por parte de los balanceadores (HA1 o HA2), y dicho directorio empleado por Apache deberá ser el mismo en los dos nodos traseros (un dato guardado por el Apache de uno de los nodos en un momento dado, puede ser requerido por el Apache del otro nodo en otro instante).

GlusterFS utiliza un sistema de ficheros en cluster denominado FUSE, similar a RAID1 (espejo), con el objetivo de poder establecer particiones en red. En el sistema de Alta Disponibilidad y Balanceo de Carga que estamos configurando, GlusterFS montará el directorio /etc/glusterfs/gfs/ en /var/www/html/ (ambas carpetas deberán ser creadas manualmente). De esta forma cuando se escriba sobre dicho directorio del nodo LB1, automáticamente también se escribirá en el mismo directorio pero del nodo LB2, y viceversa.

Si por ejemplo cayera el nodo LB1 y se empezara a utilizar exclusivamente el directorio /var/www/html/ del nodo LB2, cuando se levantase nuevamente el primer nodo, sincronizaría automáticamente su directorio /var/www/html/ con el del nodo LB2.

Todo el proceso de instalación así como los ficheros de configuración, serán idénticos en ambos nodos, por lo tanto sólo se expondrá la parte del nodo LB1.

GlusterFS emplea un cliente y un servidor. El servidor se encargará de gestionar el directorio que declararemos como compartido, y el cliente, se conectará al propio servidor GlusterFS local y remoto, formando con los dos volúmenes custodiados por los servidores un único espacio de almacenamiento final.


Vamos a empezar instalando Apache (versión 2.2.9), y el cliente y el servidor de GlusterFS (versión 1.3.10).

root@lb1:~# aptitude install apache2

root@lb1:~# aptitude install glusterfs-client glusterfs-server

En primer lugar configuraremos la parte del servidor, indicándole que utilice como directorio temporal /etc/glusterfs/gfs/ (lo denominaremos volumen brick), el cual tendremos que crear previamente. También le diremos al servidor que podrá conectarse a este volumen cualquier tipo de dirección IP (option auth.ip.brick.allow *).


root@lb1:~# cat /etc/glusterfs/glusterfs-server.vol
volume brick
type storage/posix
option directory /etc/glusterfs/gfs/
end-volume

volume server
type protocol/server
option transport-type tcp/server
subvolumes brick
option auth.ip.brick.allow *
end-volume

root@lb1:~# mkdir /etc/glusterfs/gfs/

root@lb1:~# mkdir /var/www/html/


Después le tocará el turno a la parte cliente. Para ello haremos que se conecte al propio volumen local (10.0.0.12) y al volumen remoto (10.0.0.13) - para el caso del nodo LB1 -. A continuación formará con esos dos volúmenes, un nuevo volumen llamado bricks-afr de tipo cluster/afr.

root@lb1:~# cat /etc/glusterfs/glusterfs-client.vol
volume brick1
type protocol/client
option transport-type tcp/client
option remote-host lb1
option remote-subvolume brick
end-volume

volume brick2
type protocol/client
option transport-type tcp/client
option remote-host lb2
option remote-subvolume brick
end-volume

volume bricks-afr
type cluster/afr
subvolumes brick1 brick2
end-volume

Modificando el script de arranque del servidor, haremos que una vez lanzado glusterfsd (demonio servidor), se monte el volumen de tipo cluster/afr en /var/www/html/.

root@lb1:~# cat /etc/init.d/glusterfs-server
...
do_start()
{
...
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test > /dev/null return 1
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- $DAEMON_ARGS && sleep 2
for brick in `grep /etc/glusterfs/ /etc/fstab grep glusterfs awk '{print $2}'`; do mount $brick; done return 2
}
...
do_stop()
{
...
start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec $DAEMON
[ "$?" = 2 ] && return 2
# Many daemons don't delete their pidfiles when they exit.
rm -f $PIDFILE
for brick in `grep /etc/glusterfs/ /etc/fstab grep glusterfs awk '{print $2}'`; do umount $brick; done
return "$RETVAL"
}
...

Al ejecutar el comando mount, éste acudirá al fichero /etc/fstab para comprobar cómo debe montar el directorio. Por lo tanto, tendremos que editar dentro de este fichero el sistema de archivos a ser montado (descrito en /etc/glusterfs/glusterfs-client.vol), el punto de montaje (/var/www/html/), el tipo de sistema de archivos (glusterfs) y las opciones de montaje (defaults,noauto 0 0).

root@lb1:~# cat /etc/fstab
...
/etc/glusterfs/glusterfs-client.vol /var/www/html/ glusterfs defaults,noauto 0 0

Una vez establecido el espacio compartido en red a través de GlusterFS, si hacemos la prueba de crear un fichero en el directorio /var/www/html/ de la máquina LB1, podremos ver que automáticamente se habrá replicado al mismo directorio pero del nodo LB2.

root@lb1:/var/www/html# touch fichero

root@lb1:/var/www/html# ls -l
total 0-rw-r--r-- 1 root root 0 2009-01-14 21:54 fichero

root@lb2:/var/www/html# ls -l
total 0-rw-r--r-- 1 root root 0 2009-01-14 21:54 fichero

Jan 8, 2009

Problemas al instalar IE7

Hace poco adquirí un Dell Latitude E4200, el cual venía con una licencia de Windows XP (e Internet Explorer 6 como navegador). Cuando el sistema operativo me informaba de que existían nuevas actualizaciones, dentro de ellas se encontraba también Internet Explorer 7. Al tratar de actualizar a IE7, obtenía el siguiente error al finalizar el proceso de instalación: No se instalaron las siguientes actualizaciones: Windows Internet Explorer 7 para Windows XP.



Windows XP dejaba a continuación un archivo HTML con información sobre cómo solucionar el problema (es decir, como si no dejara nada). Ojeando un poco por Internet pude ver que se trataba de un problema bastante común, y se decía que el problema venía por tratarse de una copia pirata de Windows XP (no es mi caso) y que pusieras Firefox (es el navegador que utilizo habitualmente) en lugar de Internet Explorer. Ya que había sido obligado a desembolsar una gran cantidad de dinero por Windows XP, no me parecía lógico que no pudiera utilizar IE7.

Pues manos a la obra: localizando el archivo de log que deja el proceso de instalación (ie7.log), pude ver las siguientes líneas de error:

2008/12/01 19:36:33.687 (local)
0.266: c:\8581d927d6569eda177cb8f07fca\update\update.exe (version 6.2.29.0)
0.281: Failed To Enable SE_SHUTDOWN_PRIVILEGE
0.281: Hotfix started with following command line: /quiet /norestart /er /log:C:\WINDOWS
0.281: IECUSTOM: Scanning for proper registry permissions...
0.797: IECUSTOM: Unwriteable key HKCR\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D}
0.797: IECUSTOM: Unwriteable key HKCR\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D}\ProxyStubClsid
0.797: IECUSTOM: Unwriteable key HKCR\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D}
0.797: IECUSTOM: Unwriteable key HKCR\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D}\ProxyStubClsid32
0.797: IECUSTOM: Unwriteable key HKCR\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D}
0.797: IECUSTOM: Unwriteable key HKCR\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D}\TypeLib
0.797: IECUSTOM: Unwriteable key HKCR\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D}
0.797: IECUSTOM: Unwriteable key HKCR\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D}\TypeLib
0.797: IECUSTOM: Unwriteable key HKCR\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D}
1.141: IECUSTOM: Scanning for proper registry permissions...1.344: IECUSTOM: Scanning for proper registry permissions...
1.625: IECUSTOM: Unwriteable key HKCR\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D}
1.687: IECUSTOM: Backing up registry permissions...1.703: IECUSTOM: Finished backing up registry permissions...
1.703: IECUSTOM: Setting new registry permissions...
1.703: IECUSTOM: Unable to clear DACLs HKCR\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D}
1.703: IECUSTOM: Finished setting new registry permissions...
1.703: IECUSTOM: An error occured verifying registry permissions. ERROR: 0x800705341.703: DoInstallation: CustomizeCall Failed: 0x3f5
1.703: IECUSTOM: Restoring registry permissions...
1.703: IECUSTOM: Finished restoring registry permissions...1.703: No se puede escribir la clave del Registro de configuraciones.
1.703: La instalación de Internet Explorer 7 no ha finalizado.
1.703: Update.exe extended error code = 0x3f5


Como puede observarse en el log anterior, lo que está fallando es el proceso de escritura en uno de los registros del sistema (Unwriteable key...). A continuación ha tratado de verificar los permisos de dicho registro y ha ocurrido un error (An error occured verifying registry permissions...).

Para solucionar el problema, tenemos que editar el registro de Windows XP (ejecutando el comando regedit) y modificar los permisos del registro que está fallando: HKEY_CLASSES_ROOT\Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D}. Puede verse que el grupo de Administradores tiene activado el permiso de Leer, pero no el de Control total, es decir, poder escribir.

Una vez hecho este cambio, lo único que habría que hacer sería reiniciar el sistema y volver a instalar IE7.

Jan 6, 2009

Parámetros iniciales del cluster

En el artículo anterior, presenté el esquema general del sistema de Alta Disponibilidad y Balanceo de Carga que voy a desarrollar a lo largo de las próximas semanas.

Cada una de las máquinas que componen el cluster va a tener instalado como sistema operativo una Ubuntu Server 8.10. Los dos nodos frontales (HA1 y HA2) dispondrán cada uno de ellos de dos tarjetas de red (eth0 y eth1), y los dos nodos traseros (LB1 y LB2), una única tarjeta de red (eth0).

En primer lugar, vamos a configurar el nombre de cada uno de los nodos a través del fichero /etc/hostname.

root@ha1:~# cat /etc/hostname
ha1

root@ha2:~# cat /etc/hostname
ha2

root@lb1:~# cat /etc/hostname
lb1

root@lb2:~# cat /etc/hostname
lb2


A continuación vamos a especificar en el archivo /etc/hosts de cada una de las máquinas, el nombre y dirección o direcciones IP de cada uno de los equipos involucrados en el cluster.

root@ha1:~# cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 ha1


192.168.1.10 ha1.micasa.com ha1
10.0.0.10 ha1.micasa.com ha1
192.168.1.11 ha2.micasa.com ha2
10.0.0.11 ha2.micasa.com ha2
10.0.0.12 lb1.micasa.com lb1
10.0.0.13 lb2.micasa.com lb2
...


root@ha2:~# cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 ha2


192.168.1.10 ha1.micasa.com ha1
10.0.0.10 ha1.micasa.com ha1
192.168.1.11 ha2.micasa.com ha2
10.0.0.11 ha2.micasa.com ha2
10.0.0.12 lb1.micasa.com lb1
10.0.0.13 lb2.micasa.com lb2
...


root@lb1:~# cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 lb1


10.0.0.10 ha1.micasa.com ha1
10.0.0.11 ha2.micasa.com ha2
10.0.0.12 lb1.micasa.com lb1
10.0.0.13 lb2.micasa.com lb2
...


root@lb2:~# cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 lb2


10.0.0.10 ha1.micasa.com ha1
10.0.0.11 ha2.micasa.com ha2
10.0.0.12 lb1.micasa.com lb1
10.0.0.13 lb2.micasa.com lb2
...


Después vamos a establecer las direcciones IP de cada uno de los nodos, así como el gateway que utilizarán por defecto. Para el caso de los dos nodos traseros, este gateway será la dirección IP 10.0.0.20, es decir, la dirección IP virtual que tendrá levantada el nodo activo (HA1 o HA2) en su interfaz de red eth1.

root@ha1:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static address 192.168.1.10
netmask 255.255.255.0
gateway 192.168.1.1

auto eth1
iface eth1 inet static address 10.0.0.10
netmask 255.255.255.0

root@ha2:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static address 192.168.1.11
netmask 255.255.255.0
gateway 192.168.1.1

auto eth1
iface eth1 inet static address 10.0.0.11
netmask 255.255.255.0

root@lb1:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static address 10.0.0.12
netmask 255.255.255.0
gateway 10.0.0.20

root@lb2:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static address 10.0.0.13
netmask 255.255.255.0
gateway 10.0.0.20

El siguiente paso va a ser habilitar el flujo de paquetes entre los interfaces eth0 y eth1 de los dos nodos frontales. Para ello tendremos que activar el ip_forward dentro del fichero /etc/sysctl.conf.

root@ha1:~# cat /etc/sysctl.conf
...
net.ipv4.ip_forward=1
...

root@ha2:~# cat /etc/sysctl.conf
...
net.ipv4.ip_forward=1
...


Y para hacer que este cambio se quede permanente en las sucesivas veces que arranque el equipo (si no tomaría su valor por defecto, 0, desactivado), ejecutaremos el siguiente comando en ambos nodos.

root@ha1:~# sysctl -p

root@ha2:~# sysctl -p


Y ya por último, sólo nos queda por conseguir que los cuatro nodos del cluster estén siempre sincronizados horariamente. Para ello haremos que actualicen su hora periódicamente contra un servidor NTP externo. Dentro del fichero /etc/crontab definiremos una tarea que se ejecutará cada 60 minutos y que básicamente lo único que hará será actualizar la hora del sistema mediante el comando ntpdate.

root@ha1:~# cat /etc/crontab
...
0 * * * * root ntpdate pool.ntp.org

root@ha2:~# cat /etc/crontab
...
0 * * * * root ntpdate pool.ntp.org

root@lb1:~# cat /etc/crontab
...
0 * * * * root ntpdate pool.ntp.org

root@lb2:~# cat /etc/crontab
...
0 * * * * root ntpdate pool.ntp.org