Administrando un proyecto 4

30 09 2007

Para contribuir a la metodología que queremos usar podemos añadir otra herramienta a la ayuda. Normalmente si quisiéramos tener un grupo de aplicaciones por defecto instaladas en las pc’s podríamos ir una por una instalándolas y configurándolas. Esta forma de trabajo aunque no es errada se complica para cuando tenemos un número considerable de máquinas.

Mostraremos entonces una propuesta de cómo distribuir el contenido de programas y configuraciones a todas las pc’s para mantener el grupo de herramientas con que trabajamos usualmente con el uso de qemu y udpcast

Antes de comenzar explicaremos algunos elementos para ganar en claridad. Como exportaremos este compendio para varias pc’s, las cuales probablemente tengan diferente hardware entre sí, diseñaremos el particionado para lograr esta tarea. Quedaría de esta forma:


Como podemos apreciar, para abstraer al grupo de aplicaciones del hardware específico de cada pc, dividiremos nuestro sistema en al menos estas particiones:

/boot Almacenará los núcleos de cada pc
/ Raíz del sistema
...
..
. Algún otro esquema personalizado, incluyendo si deseamos tener swap o no

Instalación

Comenzaremos instalando qemu para luego configurar una máquina virtual. Como usaremos el udpcast necesitaremos soporte para red en la máquina:

# apt-get install qemu qemu-launcher

También necesitaremos el acelerador del núcleo kqemu que nos brinda mejores prestaciones de rendimiento para nuestra máquina virtual. Debemos buscar en el repositorio para ver si existe una versión compilada para el núcleo que se usará, de no ser así se compilaría desde fuente. Por ejemplo para un núcleo 2.6.18-4-686:

# apt-get install kqemu-modules-2.6.18-4-686 kqemu-source

Lo próximo que debemos comprobar es que el núcleo tenga soporte para dispositivos TUN/TAP que instrumenten por software la red que usará la máquina virtual:

# cat /boot/config-2.6.18-4-686 | grep TUN

De no tenerlo debemos recompilar el núcleo para que tenga soporte o instalar uno que ya lo traiga por defecto. Esta funcionalidad es soportada a partir de la versión 2.1.60 del núcleo de linux.

Añadiremos entonces los módulos kqemu y tun para que levanten con el sistema:

# echo "kqemu" >> /etc/modules
# echo "tun" >> /etc/modules

Para cargarlos inmediatamente emitimos:

# modprobe tun
# modprobe kqemu

Creación del puente de red

Para que nuestra máquina virtual tenga soporte de red es necesario configurarla con un puente el cual emulará por software distintas interfaces que se transmitirán por un punto físico:

# apt-get install bridge-utils uml-utilities

Luego creamos la interfaz del puente ( br0 en este caso ), le damos a la interfaz actual que se esté ejecutando ( en el ejemplo eth0 ) un IP neutro y la añadimos al puente:

# brctl addbr br0
# ifconfig eth0 0.0.0.0
# brctl addif br0 eth0

Configuración del sistema

Luego debemos editar el fichero de configuración de las interfaces del sistema (redes) /etc/network/interfaces. Lo modificamos para que quede comentada la configuración anterior y que quede activa la nueva. El ejemplo es para configurar una red de forma dinámica. La estática quedaría con las mismas directivas address, gateway y netmask:

auto br0
iface br0 inet dhcp
bridge_ports eth0
bridge_fd 1
bridge_hello 1
bridge_stp off

Reiniciamos el servicio de red:

# /etc/init.d/networking restart

Creación de la red virtual para el sistema cliente

Antes de continuar comprobemos con ifconfig que la interfaz br0 esté activa y configurada.

# ifconfig br0

Luego configuraremos la red virtual para nuestra máquina huésped. Le daremos permisos al dispositivo de red virtual sólo a usuarios permitidos:

# tunctl -u teratux -t tun0
# chgrp proyecto /dev/net/tun
# chmod g+w /dev/net/tun
# chmod ug+x /etc/qemu-ifup

Luego editamos el fichero /etc/qemu-ifup para que quede así:

#!/bin/sh
echo "Executing /etc/qemu-ifup"
echo "Bringing up $1 for bridged mode..."
sudo /sbin/ifconfig $1 0.0.0.0 promisc up
echo "Adding $1 to br0..."
sudo /usr/sbin/brctl addif br0 $1
sleep 2

El qemu se vale de sudo para configurar las interfaces de red. Añadimos a la sección de configuración de alias de comando en /etc/sudoers:

Cmnd_Alias QEMU=/sbin/ifconfig,/usr/sbin/brctl

Añadimos a la especificación de permisos de usuarios en sudo:

%proyecto ALL=NOPASSWD:QEMU

Reiniciamos el servicio sudo:

# /etc/init.d/sudo restart

Configuración del qemu-launcher


Una vez aquí sólo nos resta terminar de configurar la interfaz TUN/TAP para la máquina virtual. Vamos a la opción de red y marcamos la opción de “abrir un dispositivo TUN/TAP”. Luego especificamos la ruta del fichero de configuración: /etc/qemu-ifup y más abajo en el de dispositivos encargado de la red virtual: tun0

Creamos un disco duro en la sección inferior. Especificamos cuanta memoria necesitamos en la pc virtual, normalmente con 128Mb o 256Mb nos alcanzará. Declaramos luego la ubicación de un medio de instalación por floppy o CDRom y arrancamos la máquina virtual. Para más información sobre cómo configurar una máquina virtual consulte el sitio de qemu. Recuerde tener en cuenta el esquema de particionado que explicamos al principio.

Distribución de la imagen

Aunque al comienzo el proceso era tedioso ya que requería de reconfigurar una estación de trabajo desde cero, ahora ya lo tenemos controlado desde una máquina virtual. Una vez que tengamos lista la imagen que pasaremos debemos tomar en cuenta algunos aspectos.

Primeramente hay que definir los ficheros de configuración que se transmitirán ya que al formar parte de la imagen, llegarán a destinos donde el hardware es diferente. Por ejemplo, el fichero de configuración del servidor gráfico ( Xorg por poner un ejemplo ), es diferente en dos máquinas con tarjetas gráficas diferentes, al igual que las interfaces de red en dos máquinas donde por ejemplo sean una inalámbrica y otra por UTP.

Para resolver el problema en la máquina virtual creamos un script donde
hacemos un cambio de todos los ficheros de configuración que necesitemos por los del tipo de estación de trabajo hacia donde se transmitirá. Quizás un script llamado transmitir_pc_tipo1.sh pudiera tener:

#!/bin/bash
cp /home/teratux/scripts_cambio/pc_tipo1/fstab /etc/fstab
cp /home/teratux/scripts_cambio/pc_tipo1/xorg.conf /etc/X11
cp /home/teratux/scripts_cambio/pc_tipo1/interfaces /etc/network/
..
. Más los que definamos

Siempre debemos tener un script que nos restablezca las configuraciones de la máquina virtual, un restaurar_qemu.sh quizás:

#!/bin/bash
cp /home/teratux/scripts_cambio/qemu/fstab /etc/fstab
cp /home/teratux/scripts_cambio/qemu/xorg.conf /etc/X11
cp /home/teratux/scripts_cambio/qemu/interfaces /etc/network/
..
. Más los que definamos

Ya con esto tenemos preparado el mecanismo de transmisión a las pc’s.

Configurando el udpcast

Para crear el programa que nos enviará la información hacia las estaciones cliente, necesitamos configurar el udpcast para que soporte harware específico en esa pc. Pudiésemos, en dependencia del medio donde se almacenará el programa, crear una versión de udpcast con todas las configuraciones específicas de cada máquina o crear una versión por cada una. Para ello, iremos al sitio udpcast personalización. Debemos también crear uno para nuestra máquina virtual qemu que será nuestra emisora.

Para consultar el tipo de hardware de nuestra máquina:

# lspci

Esto nos mostrará un listado con todo lo que dispone nuestra pc.

Desde el sitio se descargará un fichero imagen que tendremos que montar en un medio. En el ejemplo lo montaremos en un floppy:

# dd if=boot.img of=/dev/fd0

Para comenzar la transmisión tomamos el medio que preparamos para la máquina cliente y arrancamos por él.


Luego de seleccionar el idioma en que visualizaremos la instalación, pasaremos a especificar el controlador de red que usaremos. Luego si usaremos un IP por DHCP o estático. Luego el puerto de transmisión que por defecto es el 9000. Próximamente saldrá un listado con los dispositivos a transmitir. En esta sección es importante que tanto los del emisor como los del receptor sean los mismos en número al menos. Por ejemplo en un emisor PATA la primera partición del primer disco duro pudiera ser /dev/hda1 y en un receptor SATA la misma partición se reconocería como /dev/sda1 y corresponden a la misma. Pudiéramos transmitir igualmente el disco completo con sólo seleccionar la primera opción, por ejemplo /dev/hda. Luego especificamos el modo de compresión. Pueden probar con varios, siempre asegurándose que sean los mismos en ambos extremos. Y por último el modo ( receptor, emisor ). Para que funcione bien, es necesario poner a escuchar primero a los receptores y por último al emisor. Y listo, transmitimos !!!

Este método da buenas prestaciones. En una prueba sin compresión ( que es más rápido ), se transmitieron 20 Gb en menos de 30 min.

Advertisements

Actions

Information

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s




%d bloggers like this: