Introducción.

En el presente artículo se trata el tema de crear dos nuevos nodos trabajadores (c-wn3 y c-wn4) también virtualizados con KVM y agregarlos al cluster para aumentar su capacidad de cómputo.

Clonar las nuevas máquinas virtuales.

Gracias a las facilidades que provee la virtualización es posible evitar la necesidad de repetir la gran mayoría de tareas de instalación y configuración de los nodos al clonar a uno de ellos, en este caso crearemos los nuevos nodos a partir del c-wn1.

Desde el servidor de máquinas virtuales ejecutar los siguientes comandos.

ADVERTENCIA: para que la clonación se pueda realizar, la máquina virtual de orígen, en este caso c-wn1 deberá estar apagado.

$ virt-clone --connect=qemu:///system  \
-o c-wn1 \
-n c-wn3 \
-f /u/vms/c-wn3.img

$ virt-clone --connect=qemu:///system  \
-o c-wn1 \
-n c-wn4 \
-f /u/vms/c-wn4.img

Iniciar las máquinas virtuales.

Nuevamente desde el servidor es necesario ejecutar los siguientes comandos para iniciar las máquinas virtuales de los nodos trabajadores para su posterior configuración.

$ virsh start c-wn3

$ virsh start c-wn4

Conectarse a las máquinas virtuales.

Desde el equipo cliente que se utiliza para la administración de las máquinas virtuales ejecute los siguientes comandos.

$ virt-viewer -c qemu+ssh://ivy/system c-wn3

$ virt-viewer -c qemu+ssh://ivy/system c-wn4

Actualizar el hostname.

Editar el archivo /etc/sysconfig/network de cada uno de los nuevos nodos y actualizarlo con su información específica.  Para el nodo c-wn3 utilizar el siguiente contenido.

NETWORKING=yes
NETWORKING_IPV6=no
GATEWAY=192.168.1.1
HOSTNAME=c-wn3.jorgeivanmeza.com

Para c-wn4 utilizar el siguiente contenido.

NETWORKING=yes
NETWORKING_IPV6=no
GATEWAY=192.168.1.1
HOSTNAME=c-wn4.jorgeivanmeza.com

Actualizar la dirección IP.

Editar el archivo /etc/sysconfig/network-scripts/ifcfg-eth0 de cada uno de los nuevos nodos y actualizarlo con su información específica.  Para el nodo c-wn3 utilizar el siguiente contenido.

DEVICE=eth0
BOOTPROTO=static
TYPE=Ethernet
ONBOOT=yes
HWADDR=<dejar la existente>
NETMASK=255.255.255.0
IPADDR=192.168.1.213

Para c-wn4 utilizar la siguiente información.

DEVICE=eth0
BOOTPROTO=static
TYPE=Ethernet
ONBOOT=yes
HWADDR=<dejar la existente>
NETMASK=255.255.255.0
IPADDR=192.168.1.214

Reiniciar las máquinas c-wn3 y c-wn4 para que los cambios en la configuración recién realizados tengan efecto.

Actualizar la configuración de hosts.

Editar el archivo /etc/hosts del servidor c-head y actualizarlo con la información específica de cada uno de los nodos.

# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1    localhost.localdomain localhost
::1          localhost6.localdomain6 localhost6

192.168.1.210    c-head.jorgeivanmeza.com c-head c-nfs.jorgeivanmeza.com c-nfs
192.168.1.211    c-wn1.jorgeivanmeza.com c-wn1
192.168.1.212    c-wn2.jorgeivanmeza.com c-wn2
192.168.1.213    c-wn3.jorgeivanmeza.com c-wn3
192.168.1.214    c-wn4.jorgeivanmeza.com c-wn4

Posteriormente es necesario replicar esta nueva especificación de los hosts a los demás nodos del cluster, para esto es necesario que todos se encuentren en ejecución.

# scp /etc/hosts c-wn1:/etc/hosts

# scp /etc/hosts c-wn2:/etc/hosts

# scp /etc/hosts c-wn3:/etc/hosts

# scp /etc/hosts c-wn4:/etc/hosts

Configurar la autenticación basada en el huésped para root.

En el nodo cabeza (c-head) ejecutar los siguientes comandos para listar las llaves de los hosts conocidos en el cluster.

# cd /root

# ssh-keyscan -t rsa,dsa c-head c-head.jorgeivanmeza.com c-nfs c-nfs.jorgeivanmeza.com c-wn1 c-wn1.jorgeivanmeza.com c-wn2 c-wn2.jorgeivanmeza.com c-wn3 c-wn3.jorgeivanmeza.com c-wn4 c-wn4.jorgeivanmeza.com > ssh_known_hosts

# mv ssh_known_hosts /etc/ssh/ssh_known_hosts

# chown root:root /etc/ssh/ssh_known_hosts

# chmod 644 /etc/ssh/ssh_known_hosts

Propagar el archivo ssh_known_hosts a los nodos trabajadores.

# scp /etc/ssh/ssh_known_hosts c-wn1:/etc/ssh/ssh_known_hosts

# scp /etc/ssh/ssh_known_hosts c-wn2:/etc/ssh/ssh_known_hosts

# scp /etc/ssh/ssh_known_hosts c-wn3:/etc/ssh/ssh_known_hosts

# scp /etc/ssh/ssh_known_hosts c-wn4:/etc/ssh/ssh_known_hosts

Creación del archivo de .shosts.

En el nodo cabeza (c-head) ejecutar los siguientes comandos.

# cut -d’ ‘ -f1 < /etc/ssh/ssh_known_hosts|sort -u | grep -v , > shosts

# mv shosts /root/.shosts

# chown root:root /root/.shosts

# chmod 600 /root/.shosts

Propagar el archivo .shosts a los nodos trabajadores.

# scp /root/.shosts c-wn1:/root/.shosts

# scp /root/.shosts c-wn2:/root/.shosts

# scp /root/.shosts c-wn3:/root/.shosts

# scp /root/.shosts c-wn4:/root/.shosts

Definir los archivos de configuración de Condor para los nuevos nodos del cluster.

En el nodo cabeza (c-head) ejecutar los siguientes comandos para especificar archivos de configuración según los hostnames de los nuevos nodos.

# cd /nfs/condor/condor-etc/

# ln -s condor_config.worker condor_config.c-wn3

# ln -s condor_config.worker condor_config.c-wn4

Establecer las ubicaciones locales necesarias para almacenar la información de registros y colas para los nuevos nodos.

# cd ~condor/hosts

# mkdir -p c-wn3/execute c-wn3/log c-wn3/spool

# mkdir -p c-wn4/execute c-wn4/log c-wn4/spool

# chmod a+rwx c-wn3/execute c-wn4/execute

# chmod +t c-wn3/execute c-wn4/execute

# chown -R condor:condor ~condor/hosts/c-wn3 ~condor/hosts/c-wn4

Se recomienda reiniciar el servicio de Condor o la máquina completa para garantizar que todos las modificaciones recién realizadas sean tenidos en cuenta.

Verificar la inclusión de los nuevos nodos al cluster.

Desde el nodo cabeza del cluster (c-head) ejecutar los siguientes comandos para verificar su pool de nodos.

# condor_status

Name               OpSys      Arch   State     Activity LoadAv Mem   ActvtyTime

c-wn1.jorgeivanmez LINUX      X86_64 Unclaimed Idle     1.780   246  0+00:00:04
c-wn2.jorgeivanmez LINUX      X86_64 Unclaimed Idle     2.410   246  0+00:00:04
c-wn3 .jorgeivanmez LINUX      X86_64 Unclaimed Idle     1.830   246  0+00:00:04
c-wn4 .jorgeivanmez LINUX      X86_64 Unclaimed Idle     2.240   246  0+00:00:04
Total Owner Claimed Unclaimed Matched Preempting Backfill

X86_64/LINUX     4     0       0         4       0          0        0

Total     4     0       0         4       0          0        0

# condor_status -java

Name               JavaVendor Ver    State     Activity LoadAv Mem   ActvtyTime

c-wn1.jorgeivanmez Sun Micros 1.6.0_ Unclaimed Idle     1.780   246  0+00:00:04
c-wn2.jorgeivanmez Sun Micros 1.6.0_ Unclaimed Idle     2.410   246  0+00:00:04
c-wn3 .jorgeivanmez Sun Micros 1.6.0_ Unclaimed Idle     1.830   246  0+00:00:04
c-wn4 .jorgeivanmez Sun Micros 1.6.0_ Unclaimed Idle     2.240   246  0+00:00:04
Total Owner Claimed Unclaimed Matched Preempting Backfill

X86_64/LINUX     4     0       0         4       0          0        0

Total     4     0       0         4       0          0        0

Introducción.

En el presente artículo se especifica la configuración del servicio necsario para asegurar los nodos bajo una infraestructura basada en llaves SSH la cual permitirá al usuario root las siguientes acciones.

• Acceso SSH desde el nodo de adminstración y cada uno de los demás nodos del cluster.
• Acceso SSH entre todos los nodos cabeza del cluster.
• Acceso SSH entre los nodos cabeza y los nodos de trabajo del cluster.

Iniciar los nodos del cluster.

Para realizar las siguientes tareas de configuración es necesario garantizar que todos los nodos del cluster: cabeza y trabajadores, se encuentren activos.  Para hacer esto desde el servidor de máquinas virtuales ejecute los siguientes comandos.

# virsh start c-head

# virsh start c-wn1

# virsh start c-wn2

Configuración general del servicio.

Los pasos de configuración descritos a continuación se deberán realizar en c-head y desde allí serán propagados a los distintos nodos trabajadores.

Realizar una copia de seguridad de la configuración actual del servicio.

# mv /etc/ssh/sshd_config /etc/ssh/sshd_config.orig

Crear el nuevo archivo de configuración del servicio.

# vi /etc/ssh/sshd_config

Protocol 2

# No passwords
PermitRootLogin without-password
## PasswordAuthentication no
PermitEmptyPasswords no
UsePAM no

# Pub keys configuration
RSAAuthentication yes
DSAAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
KerberosAuthentication no
GSSAPIAuthentication no
GSSAPICleanupCredentials no

# Hostbased and pubkey yes
PubkeyAuthentication yes
ChallengeResponseAuthentication no
X11Forwarding no

# Hostbased
HostbasedAuthentication yes
IgnoreRhosts no

#OPTIONALLY DON’T CHECK gethostbyaddr(), TRUST CLIENT
#HostbasedUsesNameFromPacketOnly yes

# chmod 600 /etc/ssh/sshd_config

Propagar el nuevo archivo de configuración a los nodos trabajadores.

# scp /etc/ssh/sshd_config jimezam@c-wn1:/tmp

# scp /etc/ssh/sshd_config jimezam@c-wn2:/tmp

En cada uno de los nodos, c-wn1 y c-wn2, ubique apropiadamente el archivo de configuración recién copiado ejecutando los siguientes comandos.

# mv /tmp/sshd_config /etc/ssh/sshd_config

# chown root:root /etc/ssh/sshd_config

# chmod 400 /etc/ssh/sshd_config

Configurar la autenticación basada en el huésped para root.

En el nodo cabeza (c-head) ejecutar los siguientes comandos.

# cd /root

# ssh-keyscan -t rsa,dsa c-head c-head.jorgeivanmeza.com c-nfs c-nfs.jorgeivanmeza.com c-wn1 c-wn1.jorgeivanmeza.com c-wn2 c-wn2.jorgeivanmeza.com > ssh_known_hosts

# mv ssh_known_hosts /etc/ssh/ssh_known_hosts

# chown root:root /etc/ssh/ssh_known_hosts

# chmod 644 /etc/ssh/ssh_known_hosts

Propagar el archivo ssh_known_hosts a los nodos trabajadores.

# scp /etc/ssh/ssh_known_hosts jimezam@c-wn1:/tmp/ssh_known_hosts

# scp /etc/ssh/ssh_known_hosts jimezam@c-wn2:/tmp/ssh_known_hosts

En cada uno de los nodos, c-wn1 y c-wn2, ubique apropiadamente el archivo de huéspedes conocidos recién copiado ejecutando los siguientes comandos.

# mv /tmp/ssh_known_hosts /etc/ssh/ssh_known_hosts

# chown root:root /etc/ssh/ssh_known_hosts

# chmod 644 /etc/ssh/ssh_known_hosts

Creación del archivo de .shosts.

El archivo .shosts corresponde al listado de huéspedes contenidos en ssh_known_hosts sin sus respectivas llaves.  Este archivo también deberá ser replicado en los demás nodos del cluster.

En el nodo cabeza (c-head) ejecutar los siguientes comandos.

# cut -d’ ‘ -f1 < /etc/ssh/ssh_known_hosts|sort -u | grep -v , > shosts

# mv shosts /root/.shosts

# chown root:root /root/.shosts

# chmod 600 /root/.shosts

Propagar el archivo .shosts a los nodos trabajadores.

# scp /root/.shosts jimezam@c-wn1:/tmp/.shosts

# scp /root/.shosts jimezam@c-wn2:/tmp/.shosts

En cada uno de los nodos, c-wn1 y c-wn2, ubique apropiadamente el archivo de huéspedes confiables recién copiado ejecutando los siguientes comandos.

# mv /tmp/.shosts /root/.shosts

# chown root:root /root/.shosts

# chmod 600 /root/.shosts

Agregar nuevos nodos al cluster.

Si se agregan nuevos nodos al cluster es necesario que estos se conviertan en huéspedes conocidos.  Para hacer esto es necesario actualizar el archivo manipulado en el punto anterior con sus nuevas llaves y propagado a todos y cada uno de los demás nodos.

Para obtener las llaves que deberán concatenarse con las ya existentes se deberá ejecutar el siguiente comando con una lista de los hostnames de los nuevos nodos separados por espacio.

# ssh-keyscan -t rsa,dsa nodo1 nodo2 nodo3 >> /etc/ssh/ssh_known_hosts

De igual manera será necesario que se actualice el archivo .shosts de todos los nodos del cluster de la manera como se describe en el apartado anterior.

Actualizar la configuración de los clientes.

Es necesario indicarle al cliente SSH que confíe en el método de autenticación basado en los huéspedes recién configurado.  Para hacer esto es necesario realizar el siguiente paso en cada uno de los nodos del cluster.

# vi /etc/ssh/ssh_config

HostbasedAuthentication   yes
EnableSSHKeysign          yes

# /etc/init.d/sshd restart

Verificar la autenticación basada en el huésped para root.

Si la configuración de la autenticación basada en el huésped fue exitosa, el usuario root podrá iniciar una sesión SSH en cualquier nodo desde cualquier otro sin necesidad de autenticarse nuevamente con una contraseña.

Por ejemplo, desde el c-wn1 se deberá poder abrir sesiones a c-wn2 y c-head sin que se requiera una contraseña para el usuario root.

# hostname

c-wn1.jorgeivanmeza.com

# ssh root@c-head

Last login: Mon Jun  7 20:44:42 2010 from c-wn1

# hostname

c-head.jorgeivanmeza.com

Configurar la autenticación basada llaves públicas para usuarios sin privilegios.

Esta estrategia permitirá que los usuarios convencionales (no root) puedan acceder a sus respectivas cuentas entre nodos sin necesidad de una nueva autenticación por contraseña.  Inicialmente será necesario replicar los archivos con las llaves públicas de cada uno de los usuarios pero posteriormente este proceso se simplificará ya que el directorio de las cuentas de  usuario (/home) estará compartido por NFS y sólo será necesario que se genere el archivo authorized_keys para cada uno de los archivos que requieran de esta facilidad.

Iniciar sesión con el usuario sin privilegios al cual se le va a configurar la autenticación basada en llave pública.  Por ejemplo: jimezam.  Con el usuario elegido y en cada uno de los nodos crear el directorio .ssh de la siguiente manera.

$ mkdir ~/.ssh/ && cd ~/.ssh/

$ chmod 700 ~/.ssh

Desde uno de los nodos, c-head por ejemplo, ejecutar los comandos descritos a continuación.

$ ssh-keygen -t dsa

Generating public/private dsa key pair.
Enter file in which to save the key (/home/jimezam/.ssh/id_dsa):
Enter passphrase (empty for no passphrase): Romeo
Enter same passphrase again: Romeo
Your identification has been saved in /home/jimezam/.ssh/id_dsa.
Your public key has been saved in /home/jimezam/.ssh/id_dsa.pub.
The key fingerprint is:
98:ef:03:e3:8d:89:2e:7d:d5:b6:2b:5d:a6:11:3d:37 jimezam@c-head.jorgeivanmeza.com

$ cat id_dsa.pub >> authorized_keys

$ chmod 600 authorized_keys

$ chmod 600 id_dsa

Replicar la llave pública del usuario en los demás nodos del cluster.  Este paso será obviado cuando el directorio de cuentas de usuario sea único al estar compartido por NFS.

$ scp authorized_keys jimezam@c-wn1:/home/jimezam/.ssh/

$ scp authorized_keys jimezam@c-wn2:/home/jimezam/.ssh/

$ scp id_dsa jimezam@c-wn1:/home/jimezam/.ssh/

$ scp id_dsa jimezam@c-wn2:/home/jimezam/.ssh/

Verificar la autenticación basada llave primaria para usuarios sin privilegios.

Si la configuración de la autenticación basada en la llave primaria fue exitosa, el usuario sin privilegios podrá iniciar una sesión SSH en cualquier nodo desde cualquier otro sin necesidad de autenticarse nuevamente con una contraseña, sin embargo deberá proporcionar la frase secreta (passphrase) con la que se encriptó su llave durante el proceso de creación (ssh-keygen).

Por ejemplo, desde el c-wn1 se deberá poder abrir sesiones a c-wn2 y c-head sin que se requiera una contraseña para el usuario jimezam.

$ hostname

c-wn1.jorgeivanmeza.com

$ ssh jimezam@c-head

Enter passphrase for key ‘/home/jimezam/.ssh/id_dsa‘: Romeo

Last login: Mon Jun  7 21:19:21 2010 from c-wn2

$ hostname

c-head.jorgeivanmeza.com

Utilizar ssh-agent para recordar las frases secretas.

Es posible minimizar el número de veces que se hace necesario introducir las frases secretas para acceder a las cuentas de un usuario en diferentes nodos según los procedimientos descritos antes en este artículo.  Esto se logra utilizando la aplicación ssh-agent que se encarga de memorizar las frases secretas durante la sesión del usuario así que estas sólo serán solicitadas una vez por sesión.

El aplicativo puede accederse directamente desde la línea de comando o pueden utilizarse versiones GUI mas elaboradas como el GNOME KeyRing que es la versión de este software adaptada al escritorio de GNOME.

Para utilizarlo es necesario que el shell que se está utilizando esté cubierto por el ssh-agent, lo cual puede hacerse de la siguiente manera.

$ ssh-agent /bin/bash

Posteriormente ejecute el comando ssh-add e ingrese las frases secretas que requiera.

$ ssh-add

Enter passphrase for /home/jimezam/.ssh/id_dsa: Romeo
Identity added: /home/jimezam/.ssh/id_dsa (/home/jimezam/.ssh/id_dsa)

A partir de este momento y mientras dure la sesión, la llave podrá ser utilizada sin la necesidad de ingresar manualmente la frase secreta para desencriptarla.

Solución de problemas.

Al intentar ejecutar el comando ssh-add es posible que reciba el siguiente mensaje de error.

Could not open a connection to your authentication agent.

Esto significa que el shell que se está utilizando no fue abierto bajo el ssh-agent y por lo tanto no conoce cual es su proceso.  Para solucionar esto de manera temporal puede ejecutar una de las siguientes dos soluciones.

$ eval `ssh-agent`

o reiniciar el shell bajo el agente.

$ exec ssh-agent bash

Enlaces.

• Cluster configure SSH.
  https://twiki.grid.iu.edu/bin/view/ReleaseDocumentation/ClusterConfigureSSH
• Configuring automatic ssh login between all users of two hosts.
  http://itg.chem.indiana.edu/inc/wiki/software/openssh/189.html
• Using ssh-agent for SSH1 and OpenSSH.
  http://linuxgazette.net/67/nazario2.html
• ssh-add man page.
  http://www.manpagez.com/man/1/ssh-add/

Introducción.

En el presente artículo se especifican los pasos necesarios para crear las máquinas virtuales de los nodos trabajadores (worker nodes) a partir de la máquina virtual de la cabeza del cluster, la cual hasta ahora tiene una configuración básica y general para todos los nodos.

Crear las máquinas virtuales.

Desde el servidor de máquinas virtuales ejecutar los siguientes comandos para crear a los nodos trabajadores como clones inicialmente del nodo cabeza.

ADVERTENCIA: para que la clonación se pueda realizar, la máquina virtual de orígen, en este caso c-head, deberá estar apagada.

$ virt-clone --connect=qemu:///system  \
-o c-head \
-n c-wn1 \
-f /u/vms/c-wn1.img \
--debug --force

$ virt-clone --connect=qemu:///system  \
-o c-head \
-n c-wn2 \
-f /u/vms/c-wn2.img \
--debug --force

Iniciar las máquinas virtuales.

Nuevamente desde el servidor es necesario ejecutar los siguientes comandos para iniciar las máquinas virtuales de los nodos trabajadores para su posterior configuración.

$ virsh start c-wn1

$ virsh start c-wn2

Conectarse a las máquinas virtuales.

Desde el equipo cliente que se utiliza para la administración de las máquinas virtuales ejecute los siguientes comandos.

$ virt-viewer -c qemu+ssh://ivy/system c-wn1

$ virt-viewer -c qemu+ssh://ivy/system c-wn2

Actualizar la configuración de hosts.

Editar el archivo /etc/hosts y actualizarlo con la información específica para cada uno de los nodos.  Para el c-wn1 utilizar el siguiente contenido.

127.0.0.1  localhost.localdomain localhost
::1        localhost6.localdomain6 localhost6

192.168.1.210    c-head.jorgeivanmeza.com c-head c-nfs.jorgeivanmeza.com c-nfs
192.168.1.211    c-wn1.jorgeivanmeza.com c-wn1
192.168.1.212    c-wn2.jorgeivanmeza.com c-wn2

Para c-wn2 utilizar la siguiente información.

127.0.0.1  localhost.localdomain localhost
::1        localhost6.localdomain6 localhost6

192.168.1.210    c-head.jorgeivanmeza.com c-head c-nfs.jorgeivanmeza.com c-nfs
192.168.1.211    c-wn1.jorgeivanmeza.com c-wn1
192.168.1.212    c-wn2.jorgeivanmeza.com c-wn2

Actualizar el hostname.

Editar el archivo /etc/sysconfig/network y actualizarlo con la información específica para cada uno de los nodos.  Para el nodo c-wn1 utilizar el siguiente contenido.

NETWORKING=yes
NETWORKING_IPV6=no
GATEWAY=192.168.1.1
HOSTNAME=c-wn1.jorgeivanmeza.com

Para c-wn2 utilizar la siguiente información.

NETWORKING=yes
NETWORKING_IPV6=no
GATEWAY=192.168.1.1
HOSTNAME=c-wn2.jorgeivanmeza.com

Actualizar la dirección IP.

Editar el archivo /etc/sysconfig/network-scripts/ifcfg-eth0 y actualizarlo con la información específica para cada uno de los nodos.  Para el nodo c-wn1 utilizar el siguiente contenido.

DEVICE=eth0
BOOTPROTO=static
TYPE=Ethernet
ONBOOT=yes
HWADDR=<dejar la existente>
NETMASK=255.255.255.0
IPADDR=192.168.1.211

Para c-wn2 utilizar la siguiente información.

DEVICE=eth0
BOOTPROTO=static
TYPE=Ethernet
ONBOOT=yes
HWADDR=xxx
NETMASK=255.255.255.0
IPADDR=192.168.1.212

Reiniciar.

Reiniciar las máquinas virtuales c-wn1 y c-wn2 para que los cambios recién realizados tengan efecto.

# reboot

Introducción.

En el presente artículo se detalla el procedimiento para crear la máquina virtual de la cabeza (head) del cluster a partir de la máquina virtual genérica creada anteriormente además se realizan ajustes de configuración, incluyendo la red, que son genéricos a todos los demás nodos.

Creación de la máquina virtual para c-head.

Clonar la máquina virtual genérica con la especificación del nuevo nodo.

$ virt-clone --connect=qemu:///system  \
-o scientificlinux-5.5_x64-general \
-n c-head \
-f /u/vms/c-head.img \
--debug --force

Desde el servidor iniciar la máquina virtual recién creada.

$ virsh start c-head

Desde el equipo cliente donde se esté realizando la administración de las máquinas realice la conexión con la máquina recién iniciada.

$ virt-viewer -c qemu+ssh://ivy/system c-head

Inicie una sesión con el usuario root para realizar las siguientes tareas de administración.

Desactivar el inicio del sistema de ventanas.

La siguiente modificación impide que se inicie automáticamente el sistema de ventanas del sistema operativo, esto con el fin de agilizar su inicio y disminuír los riesgos de seguridad relacionados con sus protocolos.  En términos del cluster este paso es opcional y de ser necesario puede omitirse.  De cualquier manera el sistema de ventanas puede ser iniciado manualmente mediante el comando startx.

Modifique el nivel de ejecución por defecto (5) al multiusuario sin ventanas (3).

# vi /etc/inittab

id:3:initdefault:

Desactivar servicios.

Desactivcación del firewall.

La desactivación del firewall es temporal y se realiza mientras se configuran los nodos, posteriormente es necesario restaurarlo previos ajustes a la configuración.  No se recomienda que los nodos permanezcan conectados a una red pública como Internet durante el proceso de instalación, especialmente en esta etapa en la que carecen de firewall.

# chkconfig --list iptables

iptables    0:off    1:off    2:on    3:on    4:on    5:on    6:off

# chkconfig iptables off

Desactivcación de la actualización automática de Yum.

Por su parte la actualización automática del sistema operativo es considerada como un riesgo para el cluster ya que es posible que actualice paquetes críticos a nuevas versiones que no hayan sido probadas y que desestabilicen al servidor.  De cualquier manera, es posible verificar manualmente cuales son los paquetes suceptibles de ser actualizados mediante la ejecución del comando yum check-update y de forzar la actualización manualmente mediante la invocación del comando yum update.

# /etc/init.d/yum stop

# chkconfig --list yum

yum    0:off    1:off    2:on    3:on    4:on    5:on    6:off

# chkconfig yum off

Configuración del archivo de hosts.

La configuración de este archivo es esencial para poder identificar los diferentes nodos del cluster a partir de su nombre, especialmente en etapas tempranas en las que aún no se cuenta con un servicio de DNS que los incluya.

Los nombres de los diferentes nodos que componen el cluster corresponden a la siguiente definición.

• El nodo principal: c-head.
• El nodo que expone el sistema de archivos compartido: c-nfs, corresponderá físicamente con la misma máquina de c-head.
• Los nodos de procesamiento (worker nodes) serán c-wn1 y c-wn2 respectivamente.

# vi /etc/hosts

127.0.0.1  localhost.localdomain localhost
::1        localhost6.localdomain6 localhost6

192.168.1.210    c-head.jorgeivanmeza.com c-head c-nfs.jorgeivanmeza.com c-nfs
192.168.1.211    c-wn1.jorgeivanmeza.com c-wn1
192.168.1.212    c-wn2.jorgeivanmeza.com c-wn2

Configuración del hostname.

# vi /etc/sysconfig/network

NETWORKING=yes
NETWORKING_IPV6=no
GATEWAY=192.168.1.1
HOSTNAME=c-head.jorgeivanmeza.com

El valor de la variable GATEWAY debe ajustarse según la dirección IP de la pasarela real de la red.

Configuración de la dirección IP.

# vi /etc/sysconfig/network-scripts/ifcfg-eth0

DEVICE=eth0
BOOTPROTO=static
TYPE=Ethernet
ONBOOT=yes
HWADDR=<dejar la existente>
NETMASK=255.255.255.0
IPADDR=192.168.1.210

El valor de la variable IPADDR debe coincidir con la dirección IP del servidor según la planeación realizada (ver /etc/hosts).

Reiniciar el servicio de red para tomar en cuenta los cambios recién realizados.

# /etc/init.d/network restart

Configuración de los servicios de nombres a utilizarse.

# vi /etc/nsswitch.conf

#hosts: db files nisplus nis dns
hosts:  files dns

Configuración de los servidores DNS.

En esta sección es necesario que se ajusten las direcciones IP de los servidores DNS que se van a utilizar.  En este caso se van a utilizar los servidores DNS públicos de Google.

# vi /etc/resolv.conf

search jorgeivanmeza.com
nameserver 8.8.8.8
nameserver 8.8.4.4

Detener al servidor.

# halt

Enlaces.

• Grid Colombia 2009
  http://www.ci.uchicago.edu/osgedu/schools/2009/gridcolombia/index.html
• How to disable SELinux.
  http://www.crypt.gen.nz/selinux/disable_selinux.html
• Cluster getting started.
  https://twiki.grid.iu.edu/bin/view/ReleaseDocumentation/ClusterGettingStarted
• Cluster network configuration.
  https://twiki.grid.iu.edu/bin/view/ReleaseDocumentation/ClusterNetworkConfiguration

Introducción.

Para la experimentación con el cluster se utilizan máquinas virtuales basadas en KVM (con libvirt).  Como base para todas las demás máquinas se realiza la instalación de una máquina virtual base con una versión sin paquetes extra de Scientific Linux 5.5.

A continuación se describe el proceso desarrollado para la instalación de la máquina virtual base.

Procedimiento de instalación.

Creación de la máquina virtual base en el servidor de máquinas virtuales KVM.

$ virt-install \
--connect qemu:///system \
-n scientificlinux-5.5_x64-general \
-r 256 \
--os-type linux \
--os-variant generic26 \
--hvm \
--cdrom /u/isos/SL.55.051810.DVD.x86_64.disc1.iso \
--network bridge:br0 \
--disk path=/u/vms/scientificlinux-5.5_x64-general.img,size=7 \
--vnc --noautoconsole \
--accelerate

La máquina virtual se creará con las siguientes características.

• Su nombre será scientificlinux-5.5_x64-general.
• Tendrá 256MB de memoria RAM asignadas.
• Se instalará a partir de la imagen ISO del sistema operativo ubicada en /u/isos/SL.55.051810.DVD.x86_64.disc1.iso.
• La interfaz de red estará en puente (bridge) lo que permitirá que esta obtenga su propia dirección IP desde el servidor DHCP de la red.
• El archivo que representará al disco duro virtual de la máquina se ubicará en /u/vms/scientificlinux-5.5_x64-general.img y tendrá una capacidad de 7GB.

Desde un equipo acceder a la consola de la máquina virtual recién creada para realizar la instalación del sistema operativo.

$ /usr/bin/virt-viewer -c qemu+ssh://ivy/system scientificlinux-5.5_x64-general

Debe tenerse en cuenta que en este caso, el nombre del servidor de máquinas virtuales es ivy y la máquina virtual a la cual se va a realizar la conexión es scientificlinux-5.5_x64-general tal y como se especificó en el paso anterior.

Para la instalación del sistema opertivo se utilizaron los siguientes valores.

Language:
English (English).

Keyboard Layout:
U.S. International

Partition type:
Remove linux partitions on selected drives and create default layout.

Network:
Network devices: eth0 active on boot DHCP -ipv4-
Hostname: manually: sl-55-x64-general.jorgeivanmeza.com

Timezone:
America/Bogota, System clock uses UTC

Paquetes:
+  GNOME Desktop
+  Software development
Seleccionar la casilla de verificación Customize now.

Customize:
SL AddOns
- Misc Scientific Linux Packages
Applications
- Games and Entertainment
- Graphics
- Office/Productivity
- Sound and Video
Base System
- Dialup Networking Support

Procedimiento de post instalación.

Desde el servidor iniciar la máquina virtual.

$ virsh start cientificlinux-5.5_x64-general

Desde un equipo acceder a la consola de la máquina virtual recién instalada  para realizar su administración.

$ /usr/bin/virt-viewer -c qemu+ssh://ivy/system scientificlinux-5.5_x64-general

Ajustar la siguiente configuarción del sistema operativo.

Firewall.
Enabled.
Trusted Services: SSH.

SELinux Settings.
Enforcing.

Date and Time.

Create user.
Username: jimezam
Full name: Jorge Iván Meza Martínez
Password

Autenticarse como el usuario root con la contraseña asignada durante el proceso de instalación.  Abrir un shell para ejecutar los siguientes comandos.

# yum install acpid

# yum update

Enlaces.

• Scientific Linux.
  http://www.scientificlinux.org/
• KVM - Kernel based Virtual Machine.
  http://www.linux-kvm.org/
• LibVirt - Virtualization API.
  http://www.libvirt.org/

Introducción.

De manera análoga a como se realizó anteriormente la instalación de una imagen con CentOS (para Scientific Linux se igual procedimiento) procedimos a crear una máquina virtual KVM con una instalación genérica de Ubuntu Server 9.10 para futuras experimentaciones con un plan de trabajo ligeramente modificado.

1. Actualización de paquetes.
2. Instalar ACPID.
3. Instalación del JDK de Java.
4. Instalación del ambiente de desarrollo C/C++.
5. Instalación del servidor X y IceWM como administrador de ventanas.
6. Depurar el software instalado.

Creación de la máquina virtual para la instalación del sistema operativo.

$ virt-install \
–connect qemu:///system \
-n ubuntuserver-9.10_x64-general \
-r 384 \
–os-type linux \
–os-variant generic26 \
–hvm \
–cdrom /u/isos/ubuntu-9.10-server-amd64.iso \
–network bridge:br0 \
–disk path=/u/vms/ubuntuserver-9.10_x64-general.img,size=7 \
–vnc –noautoconsole \
–accelerate

Conexión remota a la KVM para el proceso de instalación y administración.

$ /usr/bin/virt-viewer -c qemu+ssh://ivy/system ubuntuserver-9.10_x64-general

Actualización de paquetes.

$ sudo aptitude update

$ sudo aptitude safe-upgrade

Instalación de ACPID.

$ sudo aptitude install acpid

Instalación del JDK de Java.

$ sudo aptitude install sun-java6-bin sun-java6-fonts sun-java6-jdk sun-java6-jre sun-java6-plugin

Instalación del ambiente de desarrollo C/C++.

$ sudo aptitude install build-essential

Instalación del servidor X y IceWM como administrador de ventanas.

$ sudo aptitude install xorg icewm icewm-themes

Introducción.

El fin del presente artículo es el de preparar una imagen básica del sistema operativo, en este caso CentOS 5.4 de 64 bits, para futuros usos en experimentos y pruebas.  La infraestructura de virtualización que utilizo para implementarla es KVM.

En términos generales estos son las adecuaciones que tendrá está imagen básica.

1. Actualización de paquetes.
2. Instalar ACPID.
3. Permitir la ejecución de sudo para el usuario jimezam.
4. Bloquear la contraseña del usuario root.
5. Instalación del JDK de Java.
6. Instalación del ambiente de desarrollo C/C++.
7. Depurar el software instalado.

Creación de la máquina virtual para la instalación del sistema operativo.

$ virt-install \
–connect qemu:///system \
-n centos-5.4_x64-general \
-r 384 \
–os-type linux \
–os-variant generic26 \
–hvm \
–cdrom /u/isos/CentOS-5.4-x86_64-bin-DVD.iso \
–network bridge:br0 \
–disk path=/u/vms/centos-5.4_x64-general.img,size=7 \
–vnc –noautoconsole \
–accelerate

Conexión remota a la KVM para el proceso de instalación y administración.

$ /usr/bin/virt-viewer -c qemu+ssh://ivy/system centos-5.4_x64-general

Actualización de paquetes.

# yum check-update

# yum update

Instalación de ACPID.

# yum install acpid

Activar el acceso a sudo para wheel.

# visudo

%wheel     ALL=(ALL)    ALL

# usermod -G wheel jimezam

Bloquear la contraseña del usuario root.

# passwd -l root

Instalación del JDK de Java.

# yum install java-1.6.0-openjdk java-1.6.0-openjdk-devel

Instalación del ambiente de desarrollo C/C++.

# yum install gcc gcc-c++ autoconf automake

Introducción.

A continuación se realizará la instalación de un Linux CentOS 5.4 básico en una máquina virtual basada en KVM utilizando LibVirt.

Preparación preliminar.

• La infraestructura necesaria para la virtualización basada en KVM se encuentra instalada y configurada.
• Se ha descargado la imagen ISO de la última distribución (5.4 en este caso) de Linux CentOS de su sitio web.
  http://www.centos.org/modules/tinycontent/index.php?id=15
• La imagen ISO de Linux CentOS se ha ubicado en /u/isos.
• La imagen del disco duro de la máquina virtual se creará en /u/vms.
• La red de la máquina virtual se implementará sobre una interfaz puente (br0) en el huésped.  Puede utilizarse también la configuración de NAT por defecto de KVM sin nigún problema.
• La máquina virtual (dominio) será identificada por la etiqueta centos-general.
• Se le asignarán 256MB de memoria RAM y un disco duro de 7GB a la máquina virtual.

Creación de la máquina virtual.

$ virt-install \
–connect qemu:///system \
-n centos-general \
-r 256 \
–os-type linux \
–os-variant generic26 \
–hvm \
–cdrom /u/isos/CentOS-5.4-i386-bin-DVD.iso \
–network bridge:br0 \
–disk path=/u/vms/centos-general.img,size=7 \
–vnc –noautoconsole \
–accelerate

Conexión a la interfaz gráfica de la máquina virtual.

$ /usr/bin/virt-viewer -c qemu+ssh://IP_SERVIDOR/system centos-general

• Si la conexión es remota utilice el protocolo qemu+ssh y reemplace la constante IP_SERVIDOR por la dirección IP o nombre FQDN del huésped.
• En caso de realizarse una conexión local utilice el protocolo qemu y obvie la dirección del servidor.

Instalación normal de Linux CentOS.

Realice la instalación habitual de Linux CentOS 5.4 mediante el visor de la máquina virtual recién invocado.

Introducción.

Cuando se instala KVM se crea una red privada por defecto (192.168.122.0) para las máquinas virtuales las cuales sólo son accesibles desde el mismo huésped.

(revisar) Si lo que se desea, como en mi caso, es que las máquinas virtuales obtengan una dirección del servicio de DHCP y puedan ser accedidas desde la red LAN como un servidor real es necesario crear un puente en la interfaz de red del servidor para permitirle a las máquinas virtuales acceder a la red física a través de este.

El procedimiento para hacer esto es simple y se describe a continuación.

Advertencia acerca de la red inalámbrica.

Utilizando el método convencional para la creación de puentes no es posible utilizar interfaces de red inalámbricas ya que sus tarjetas no permiten realizar ip spoofing necesario para su implementación.  Es necesario entonces contar con un acceso alámbrico a la red LAN para poder realizar el procedimiento descrito en este artículo.

Investigando en Internet encontré varios foros en los que se menciona que es posible dar solución a este problema sin utilizar el procedimiento estándar sino utilizando aproximaciones alternativas que no estarían supeditadas a la red alámbrica, sin embargo después de cuatro días de intentos y pruebas no me funcionaron así que tuve que utilizar la red cableada.  Las aproximaciones alternativas que sugieren mayor posibilidad de éxito son las siguientes.

• Establecer un proxy ARP.
  http://savvyadmin.com/virtualbox-wireless-bridging/
• Utilizar parprouted para establecer el puente de red.
  http://www.daryl.mu/2008/08/21/howto-set-up-wireless-networking-between-virtualbox-vms-on-ubuntu-hardy-heron/

En mi caso lo que revisió mayor dificultad para realizar las pruebas de estos procedimientos resultó, mas que la implementación de los mismos que de por si es bastante simple, la configuración de las máquinas KVM (he utilizado libvirt para su manipulación) para que utilicen la nueva interfaz de red ya que los ejemplos mejor descritos que encontré hacían referencia a Virtualbox y para KVM su configuración es notoriamente diferente.

Procedimiento.

Configurar el huésped (servidor de máquinas virtuales).

Instalar el paquete de utilidades para la creación de puentes de red.

$ sudo apt-get install bridge-utils

Editar el archivo de configuración de interfaces de red para agregar la configuración del puente.

$ sudo vi /etc/network/interfaces

Este procedimiento se puede realizar de dos maneras: de manera estática especificando la información precisa de conexión a la red o de manera dinámica permitiendo adquirir la configuración automática desde un servidor DHCP.

De manera estática se realiza de la siguiente manera.

auto br0
iface br0 inet static
address 192.168.1.10
network 192.168.1.0
netmask 255.255.255.0
broadcast 192.168.1.255
gateway 192.168.1.1
bridge_ports eth0
bridge_stp off
bridge_fd 0
bridge_maxwait 0

De manera dinámica se realiza de la siguiente manera.

auto br0
iface br0 inet dhcp
bridge_ports eth0
bridge_stp off
bridge_fd 0
bridge_maxwait 0

En ambos casos se está creando el puente br0 para acceder a la red a través de la interfaz eth0 (red alámbrica).

Reiniciar la configuración de red para tomar en cuenta los cambios recién realizados.

$ sudo /etc/init.d/networking restart

Verificar el estado de los cambios.

$ ifconfig

br0 Link encap:Ethernet  HWaddr 00:24:21:b6:12:11
inet addr:192.168.1.99 Bcast:192.168.1.255  Mask:255.255.255.0
inet6 addr: fe80::224:21ff:feb6:1211/64 Scope:Link
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
RX packets:991 errors:0 dropped:0 overruns:0 frame:0
TX packets:90 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:62573 (62.5 KB)  TX bytes:14537 (14.5 KB)

eth0 Link encap:Ethernet  HWaddr 00:24:21:b6:12:11
inet addr:192.168.1.99 Bcast:192.168.1.255  Mask:255.255.255.0
inet6 addr: fe80::224:21ff:feb6:1211/64 Scope:Link
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
RX packets:991 errors:0 dropped:0 overruns:0 frame:0
TX packets:898 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:77339 (77.3 KB)  TX bytes:67197 (67.1 KB)
Interrupt:27

Nótese como aparece la nueva interfaz de red del puente (br0) que toma igual configuración de red de su destino (eth0).

Configurar el invitado (máquinas virtuales).

Editar la información de especificación de la máquina virtual.

$ virsh edit IDENTIFICADOR_DOMINIO

Modificar la sección de la configuración de red (<interface>) con el siguiente estilo.

<interface type=’bridge’>
<source bridge=’br0‘/>
<model type=’virtio’/>
<mac address=’00:11:22:33:44:55′/>
</interface>

Actualice la información de la máquina virtual en el Hypervisor e iníciela.

$ virsh -c qemu:///system define /etc/libvirt/qemu/IDENTIFICADOR_DOMINIO.xml

$ virsh -c qemu:///system start IDENTIFICADOR_DOMINIO

Para confirmar el éxito de la configuración, en la máquina virtual consulte su dirección IP, la cual deberá coincidir con la especificada durante la configuración (estática) o la proporcionada por el servidor DHCP (dinámica).

Acerca de la dirección MAC de las interfaces virtuales.

Siempre es conveniente especificar una dirección MAC y que esta sea única entre las diferentes máquinas virtuales para evitar cualquier tipo de confusión.  Con respecto a esta dirección se recomienda que el primer valor sea par (como por ejemplo 00).

Para facilitar la generación de direcciones MAC al azar, la documentación de KVM en Ubuntu incluye un script muy útil.

$ sudo apt-get install randomize-lines

$ vi ~/bin/kvmGenMac               # Almacénelo donde desee.

#!/bin/sh
echo -n "54:52:00"
for i in 1 2 3; do
    echo -n ":"
    for j in 1 2; do
        for k in 0 1 2 3 4 5 6 7 8 9 A B C D E F; do
            echo $k
        done|rl|sed -n 1p
    done|while read m; do
        echo -n $m
    done
done
echo

$ chmod +x ~/bin/kvmGenMac

Para ejecutarlo simplemente invoque el shell y obtenga la dirección MAC al azar de la salida estándar.

$ ./bin/kvmGenMac

Enlaces.

• KVM Networking.
  https://help.ubuntu.com/community/KVM/Networking
• libvirt Virtualization API.
  http://libvirt.org/

Introducción.

Haciendo -muchas- pruebas con la configuración de red de las máquinas virtuales utilizando KVM empecé a tener un extraño problema.  La interfaz de red habitual, eth0, empezó a desaparecerse de la máquina virtual en la que estaba haciendo las pruebas.  Después de una inspección rápida a los mensajes del sistema encontré que había sido renombrada la interfaz a eth2.

$ dmesg | grep eth0

udev: renamed network interface eth0 to eth2

El problema.

En las pruebas que había hecho varias veces había cambiado la configuración de red de la máquina virtual, cambiando también la dirección MAC de la tarjeta de red virtual que KVM le asignaba al dominio provocando que al parecer, el sistema operativo se confundiera pensando que tenía todas esas tarjetas y sólo al inicio cuando verificaba las interfaces se daba cuenta cual era la tarjeta activa.

La solución.

$ vi /etc/udev/rules.d/70-persistent-net.rules

Remueva o comente las líneas correspondientes a las tarjetas de red con que ya no cuenta el servidor dejando únicamente la correspondiente a la MAC en uso.

Reinicie el servicio de red, el servidor o máquina virtual si es posible.

Enlaces.

• WTH: eth0 got renamed to eth2 after an upgrade.
  http://tadek.pietraszek.org/blog/2008/03/04/wth-eth0-got-renamed-to-eth2-after-an-upgrade/