Configuración de servidor web SAGE notebook

SAGE es una interface Python para utilizar una gran cantidad de paquetes de software matemático. Provee de un servidor web llamado notebook para poder trabajar desde un navegador.

SAGE es GPL.

La version de SAGE utilizada es la 5.3

El objetivo de SAGE es crear una alternativa viable, libre y de código abierto a: Magma, Maple, Mathematica y Matlab.

En este artículo voy a contar como configurar el servidor notebook de SAGE.

Voy a centrarme solamente en la configuración de SAGE necesaria para poderlo utilizar de forma aceptable en un equipo con pocos recursos.

Se supondrá que SAGE ya esta correctamente instalado.

La mejor documentación para compilar SAGE se encuentra en:

          http://www.sagemath.org/doc/installation/source.html

También existe un paquete precompilado para Ubuntu.

1-Recursos y rendimiento:

En la actualidad el servidor esta montado sobre una máquina con:

• S.O: Debian 6.0 con kernel 2.6.32-5-amd64
• CPU: Intel Xeon 1.6 Ghz 64 bits
• RAM: 2 GB
• Disco duro disponible: 18GB
• Nº de usuarios simultáneos tranbajando con SAGE:  20 usuarios.

2-Sobre usuarios de sistema y usuarios de la aplicación web notebook:

Es importante comprender que una cosa es el usuario del sistema que lanza el proceso "sage notebook" y otra los usuarios de la aplicación web de notebook.

Puesto que SAGE puede trabajar en linea de comandos desde el shell o mediante el servidor web, es posible tener varios usuarios de sistema que arranquen su propio servidor web notebook en la misma máquina (usando diferentes puertos).

Para nuestro escenario de servidor de prácticas, necesitamos un solo usuario del sistema que arranque el servidor web. Los distintos usuarios de la aplicación web notebook se darán de alta desde la propia aplicación web (también es posible hacerlo desde la shell, ver manual).

3-Configurando correctamente el SO:

  3.1- Configurar usuario del sistema:

Puesto que nosotros unicamente utilizamos SAGE desde el servidor web Notebook, tan solo necesitaremos un usuario de sistema que lance el servidor web.

Este usuario debe poder acceder mediante ssh sin password. Al arrancar el servidor, se le comunica que usuario de sistema se usa (mediante el parametro server_pool, ver mas adelante), y las restricciones a aplicar a sus trabajos o worksheet (mediante ulimit, ver mas adelante).

Crear usuario, en nuestro caso sageuser:

                mimaquina:~$adduser sageuser    (creara el home /home/sageuser/)

Crear claves ssh:

               mimaquina:~$su sageuser

               sageuser@mimaquina:~$ssh-keygen     (Ojo dejar la passphrase en empty).

                Este comando genera las claves rsa y las almacena en /home/sageuser/.ssh/

       

              sageuser@mimaquina:~$cp /home/sageuser/.ssh/id_rsa.pub /home/sageuser/.ssh/authorized_keys

Comprobar acceso funciona correctamente:

              mimaquina:~$su sageuser

              sageuser@mimaquina:~$ssh localhost

Si da error investigar el problema lanzando el servidor sshd en modo debug y el cliente ssh en modo verbose:

      Cliente:            sageuser@mimaquina:~$ssh -vvv localhost

      Servidor:          mimaquina:~$sshd -d

  3.2-Configurar el servidor sshd:

Puesto que la aplicación web notebook realiza una conexión ssh por cada usuario de aplicación conectado, será necesario configurar el servidor para:

• Permitir mas de 20 conexiónes simultaneas (queremos dar soporte a 20 usuarios).
• Terminar las conexiones ssh una vez que han abandonado la aplicación (si no lo hacen correctamente y simplemente cierran el navegador, las sesiones quedan abiertas.)

Para ello en el fichero /etc/ssh/sshd_config necesitamos los siguientes parámetros:

         MaxSessions 40   (nº maximo de conexiones simultaneas)

         MaxStartups  40  (nº maximo de autenticaciones simultaneas)

         ClientAliveInterval  1800    (tiempo en segundos de inactividad antes de petición de respuesta)

         CleintAliveCountMax 0      (nº de intentos fallidos de obtener respuesta antes de cerrar conexion).

4-Arrancar el servidor web notebook:

  4.1-Primer arranque:

En el primer arranque del servidor se debe configurar la cuenta del usuario "admin" de la aplicación web notebook.

Para ello es necesario acceder a sage como el usuario del sistema (en nuestro caso sageuser) y hacer lo siguiente:

       sageuser@mimaquina:~$sage               (entramos en sage)

       sage:  notebook(reset=True)                 (arrancara servidor notebook y nos pedirá contraseña para admin).

       sage: exit

  4.2-Arranque normal:

La aplicación web notebook cuando intenta conectarse mediante ssh busca las claves ssh en la carpeta .ssh/ del home del usario que lo ha lanzado, por ejemplo:

         Lanzo el servidor como:

                               Usuario:  root   =>     Directorio: /root/.ssh

                               Usuario: sageuser => Directorio: /home/sageuser/.ssh

Por tanto la aplicación deberá lanzarse con el usuario de sistema pasado en el parámetro server_pool.

En mi caso, el comando utilizado para lanzar el servidor SAGE es:

          sageuser@mimaquina:~$sage -c "notebook(interface="practicas.miservidor.com", port=8000, accounts=True, timeout=7200, server_pool=['sageuser@localhost'], ulimit='-v 90000')"

Para conseguir que 20 usuarios puedan trabajar con solo 2GB de RAM se han utilizado los siguientes parámetros:

• timeout: Cantidad de segundos hasta que una sesión de trabajo (worksheet) inactiva es terminada.
• ulimit: mediante la opción -v,  limita la cantidad máxima de RAM utilizada por cada trabajo (worksheet).

El parámetro ulimit (¿user limit?) funcionara solamente si va asociado a uno o mas usuarios del sistema. Estos usuarios se indican mediante el parámetro server_pool.

IMPORTANTE: El usuario de sistema incluido en la lista server_pool, deberá poder acceder mediante ssh al servidor sin contraseña. De no ser así cuando el usuario web realice una operación no se mostraran los resultados.

NOTA: no confundir los usuarios de la aplicación web notebook (proceso que se puede realizar una vez conectados a la web) con el usuario de sistema que lanzara el servidor web.

5- Parada del servidor sage notebook:

Para parar el servidor es necesario matar el proceso cuyo PID se almacena en el fichero twistd.pid del directorio home del usuario. En nuestro caso:

          sageuser@mimaquina:~$kill -9 $(cat /home/sageuser/.sage/sage_notebook.sagenb/twistd.pid)

rtai 3.8.1 y ubuntu 10.04 LTS con kernel 2.6.32 en Atom

 A continuación voy a mostrar como compilar e instalar rtai 3.8.1 con un kernel 2.6.32 en una distribución de ubuntu 10.04 LTS.

El kernel se ha configurado para correr en un PC industrial con un Atom dual core. Si se requiere otra CPU solo hay que cambiar la selección en el paso de configuración del kernel.

Nota: Por cuestiones de velocidad y espacio en disco (nuestro PC tiene una compact flash de 8GB), la compilación del kernel se puede realizar en cualquier máquina (a ser posible con la misma distribución que la maquina de destino y luego solo hará falta compilar el rtai en la máquina de destino).

Paquetes necesarios:
    
      linux-2.6.32.11.tar.gz
      rtai-3.8.1.tar.bz2

Pasos a realizar:

---  En cualquier maquina potente ---

 0- cd /usr/src/

 1-  tar zxvf linux-2.6.31.11.tar.gz

 2-  ln -s linux-2.6.31.11 linux 
     
 3-  tar xvf rtai-3.8.1.tar.bz2

 4-  cd  /usr/src/linux

            (parcheamos el kernel con el patch de rtai)

 5-  patch -p1 -b < ../rtai-3.8/base/arch/x86/patches/hal-linux-2.6.32.11-x86-2.6-03.patch
        
       (instalamos los paquetes necesarios para compilar y crear paquetes .deb)

 6- aptitude update && apt-get install kernel-package libncurses5 libncurses5-dev zlib1g zlib1g-dev build-essential 

 7- cd /usr/src/linux  
                      
            (copiamos el fichero de configuración base) 

 8- cp /boot/config-2.6.32-24-generic .config

 9- make oldconfig 

            (damos al enter para que tome opciones por defecto hasta que finalize) 

            (configuramos el kernel)

 10- make menuconfig

 Enable loadable module support ---> enabled [*]
 Loadable module support ---> Module versioning support ---> disabled

 Loadable module support ---> Source checksum for all modules ---> disabled
 Processor type and features ---> Support sparse irq numbering ---> disabled
 Processor type and features ---> HPET Timer Support ---> disabled
 Processor type and features ---> Interrupt pipeline ---> enabled [*]
 Power management and ACPI options ---> ACPI (Advanced Configuration and Power Interface) Support ---> enabled [*]
 Power management and ACPI options ---> ACPI (Advanced Configuration and Power Interface) Support ---> Deprecated /proc/acpi files ---> disabled
 Power management and ACPI options ---> ACPI (Advanced Configuration and Power Interface) Support ---> Deprecated power /proc/acpi directories ---> disabled
 Power management and ACPI options ---> ACPI (Advanced Configuration and Power Interface) Support ---> Future power /sys interface ---> disabled
 Power management and ACPI options ---> ACPI (Advanced Configuration and Power Interface) Support ---> Deprecated /proc/acpi/event support ---> disabled
 Power management and ACPI options ---> ACPI (Advanced Configuration and Power Interface) Support ---> AC Adapter ---> disabled
 Power management and ACPI options ---> ACPI (Advanced Configuration and Power Interface) Support ---> Battery ---> disabled
 Power management and ACPI options ---> ACPI (Advanced Configuration and Power Interface) Support ---> Button ---> disabled
 Power management and ACPI options ---> ACPI (Advanced Configuration and Power Interface) Support ---> Video ---> module [M]
 Power management and ACPI options ---> ACPI (Advanced Configuration and Power Interface) Support ---> Fan ---> disabled
 Power management and ACPI options ---> ACPI (Advanced Configuration and Power Interface) Support ---> Dock ---> enabled [*]
 Power management and ACPI options ---> ACPI (Advanced Configuration and Power Interface) Support ---> Processor ---> disabled
 Power management and ACPI options ---> ACPI (Advanced Configuration and Power Interface) Support ---> Disable ACPI for systems before Jan 1st this year ---> 0
 Power management and ACPI options ---> ACPI (Advanced Configuration and Power Interface) Support ---> Debug Statements ---> disabled
 Power management and ACPI options ---> ACPI (Advanced Configuration and Power Interface) Support ---> PCI slot detection driver ---> disabled
 Power management and ACPI options ---> ACPI (Advanced Configuration and Power Interface) Support ---> Container and Module Devices ---> disabled
 Power management and ACPI options ---> ACPI (Advanced Configuration and Power Interface) Support ---> Smart Battery System ---> disabled
 Power management and ACPI options ---> APM (Advanced Power Management) BIOS support ---> disabled
 Power management and ACPI options ---> CPU Frequency scaling ---> disabled

      En nuestro caso:  
                  Processor type and features ---> Processor family --> Atom

11- make-kpkg --initrd --revision=rtaiAtom386 kernel_image kernel_headers modules_image


12- Cafe....

-- Pasos en la maquina destino--

13- cd /usr/src

14- dpkg -i linux-image-2.6.32.11_rtaiAtom386_i386.deb

15- dpkg -i linux-headers-2.6.32.11_rtai386_i386.deb

16- reboot
           (arranca directamente con el kernel recién instalado,
            para acceder al menú grub: ctrl+shift).

            (enlazamos las cabeceras que se necesitarán para compilar rtai)

17- ln -s linux-headers-2.6.32.11 linux

18- cd /usr/src/rtai-3.8

            (configuramos rtai de acuerdo a nuestras necesidades) 

19- make menuconfig

               Parámetros RTAI para nuestras necesidades especificas:
                   Base system --> Supported services --> Use RTNet --> enable 
                   Base system --> Other features --> Mathfuns support in kernel --> enabled
                   Add-ons --> Real-Time Driver Model over RTAI --> enabled 
                   Add-ons --> Enable select multiplexing for RTDM services 
                   Add-ons --> Shared interrups   
                   Add-ons --> Drivers --> RTDM based 16550A driver support --> enabled

20- make
21- make install
22- reboot


               (Reboot porque sino, da error al ejecutar /usr/realtime/testsuite/user/).

En principio con esto ya estaría, salvo que se quieran añadir los módulos rtai al árbol de módulos del kernel y así poder usar modprobe, en vez de:

    insmod /usr/realtime/modules/rtai_hal.ko 
    insmod /usr/realtime/modules/rtai_sched.ko

y al terminar la aplicación: 

    rmmod /usr/realtime/modules/rtai_sched.ko 
    rmmod /usr/realtime/modules/rtai_hal.ko

Nota: Al ejecutar los test se cargan y descargan los módulos necesarios sin necesidad de hacer insmod/rmmod.

Modifying sysprep in Windows 7 after cloning

If you are using clonezilla, rembo, fog or other cloning tool, the normal thing is to clone the image on the target computer, parsing the sysprep answer file on the target computer and boot the computer to run sysprep.

In Windows 7, When you run sysprep on the source computer using a response file (for example sysprep.xml), it automatically creates another file that contains the parameters for pass specialize (as ComputerName).

This file is stored in:

%WINDIR%\Panther\

So once cloned the image on the target computer and before starting and sysprep is done, we will have to parse the file:

%WINDIR%\Panther\unattend.xml

Modificando sysprep en windows 7 despues de clonar.

Si estamos utilizando clonezilla, rembo, fog o cualquier otra herramienta de clonado de aulas. Lo normal es clonar la imagen en el equipo destino, parsear el fichero de respuesta de sysprep con los datos (nombre del equipo, dominio...etc) del equipo destino y arrancar el equipo para que se ejecute sysprep.

En Windows 7, al ejecutar sysprep en el equipo de origen, utilizando un fichero de respuesta xml (por ejemplo sysprep.xml), automaticamente se  crea otro fichero que contiene los parametros correspondientes a la fase specialize (como el ComputerName).

Este fichero se almacena en:

%WINDIR%\Panther\

Por lo que una vez clonada la imagen en el equipo destino y antes de que arranque y se realize el sysprep, habra que parsear el fichero:

%WINDIR%\Panther\unattend.xml

Clonar Compact Flash

En esta ocasión voy a contar como clonar tarjetas Compact Flash.

Concretamente tarjetas que se utilizan como discos duros en PC's industriales.

Había probado varios programas de clonación y no funcionaban bien.

Por otro lado,al intentar usar fdisk o cfdisk se hacen un lio y no podia crear particiones que luego fueran booteables.

Por supuesto con el comando  dd  si se podía hacer. Pero no me interesaba clonar una CF de 8GB con dd si el sistema instalado ocupaba la mitad.

Al final consegui crear las particiones con parted y luego clonar el sistema con tar.

Paso 1: Copiar Sistema de Ficheros origen a fichero backup.

Se va a suponer que el dispositivo CompactFlash (en adelante CF) es reconocido por el sistema como /dev/sdc.

 1.1: Montar sistema de ficheros origen: 
    mount /dev/sdc1 /mnt/disk
 1.2: Copiar sistema de archivos a un fichero comprimido: 
    tar cvpzf CFBackup.tgz /mnt/disk 1 

Paso 2: Crear particiones en nueva CF.

 2.1: Si existen, borrar particiones existentes (suponemos existen 2 particiones):
    parted /dev/sdc rm 1
    parted /dev/sdc rm 2...
 2.2: Crear nuevas particiones:
  2.2.1: Para sistemas ext3:
    parted /dev/sdc mklabel msdos
    parted /dev/sdc mkpart primary ext3 0 3500
    mkfs -t ext3  /dev/sdc1
    parted /dev/sdc set 1 boot on
  2.2.2: Para sistemas ext2:
    parted /dev/sdc mkpartfs primary ext2 0 3500
    parted /dev/sdc set 1 boot on
  2.2.3: Para sistemas ext2:
    parted /dev/sdc mkpartfs primary linux-swap 3501 4000

Paso 3: Restaurar Sistema de Ficheros:

            3.1: Se monta el dispositivo CF:
                    mount /dev/sdc1 /mnt/disk
            3.2: Se copia sistema de ficheros al dispositivo CF:
                    tar xvpzf CFBackup.tgz -C /

Paso 4: Prepara Sistema de Ficheros nuevo:

            4.1: Modificamos fstab para que coincida con las nuevas particiones.
                   Por ejemplo: Si la partición swap es /dev/hda5 ahora será /dev/hda2.
            4.2: Actualizar el sistema de ficheros ram de inicio:
                        chroot /mnt/disk
                        update-initramfs -u
            4.3: Crear el nuevo sector de arranque (mbr) en la CF:
                        umount /media/disk

                       grub
                       grub> device (hd2) /dev/sdc
                       grub> root (hd2,0)
                       grub> setup (hd2)
                       grub> quit
                       sync

1Sistema origen aprox. 900MB. Fichero .tgz 441 MB

Mantenimiento de Aulas. Un enfoque virtualizado. (Parte 2/3)

Ok, ya tenemos un sistema mínimo, sin entorno gráfico ni nada. Tan solo el servidor de xorg y aplicaciones de sistema.

Lo hemos configurado para tener un arranque por grub con el menú que nos permitirá lanzar las VM deseadas o entrar al sistema host.


Lo primero que tenemos que hacer es crearnos las máquinas virtuales. Para ellos se puede arrancar VirtualBox en modo gráfico:

Misuario@Equipo:~$xinit VirtualBox

Yo tengo equipos nuevecitos con 4 núcleos  y 4GB de RAM, así que a mis VM les he puesto los 4 núcleos y 3GB de RAM, ya que el sistema host no va ha hacer nada mas que servir de virtualizador.

En mi caso, las máquinas se encuentran en:

/home/MiUsuario/.VirtualBox

He creado una VM con Windows7 que he llamado Windows7Guest y otra con Linux que he llamado LinuxGuest.

La idea es que una vez instalados y configurados los sistemas tomo una instantánea de cada uno que llamare "inicio" y que podre restaurar antes de levantar la VM para que el sistema siempre este limpio.

Para arrancarlas ejecuto los siguientes scripts como MiUsuario: StartW7.sh t StartLinux.sh.

StartW7.sh:

#!/bin/sh

VBoxManage snapshot W7Guest restore inicio &&
xinit /usr/bin/VBoxSDL -startvm W7Guest --hwvirtex --fullscreen
sudo /sbin/poweroff

StartLinux.sh:

#!/bin/sh

VBoxManage snapshot LinuxGuest restore inicio &&
xinit /usr/bin/VBoxSDL -startvm LinuxGuest --hwvirtex --fullscreen
sudo /sbin/poweroff

Con este script lanzamos ls VM sin necesidad de lanzar las X's y además cuando apagamos la VM se apaga la máquina host.

Para ello, es necesario modificar el fichero /etc/sudoers para que permita ejecutar el comando poweroff sin pedir password. Basta con añadir un linea como la siguiente:

MiUsusario     ALL = NOPASSWD: /sbin/halt,/sbin/poweroff,/usr/bin/vdfuse

Otra cosa interesante es la necesidad de que funcionen los USB en las VM's de forma transparente al usuario. Para ello, desde VirtualBox  (xinit VirtualBox) habilitamos los USB's y creamos un "filtro vacío" (mirar la documentación del VirtualBox si no sabéis de lo que hablo).

Para que se enlacen los dispositivos usb a la VM necesitamos crear una regla en el udev. Esto lo podemos hacer poniendo la regla 90-usb-virtualbox.rules en /etc/udev/rules.d/

90-usb-virtualbox.rules:

SUBSYSTEM=="usb", ACTION=="add", RUN+="/usr/local/sbin/usb-virtualbox.sh" 

Donde  usb-virtualbox.sh es un script creado por nosotros y hemos situado en /usr/local/bin/

usb-virtualbox.sh:

#!/bin/bash
U=MiUsuario
A=$(env | grep DEVPATH | cut -f 5-6 -d /)
S=$(su $U -c "VBoxManage list usbhost" | grep "$A" | awk '{print $2}' )
su $U -c "VBoxManage controlvm W7Guest usbattach $S"
su $U -c "VBoxManage controlvm LinuxGuest usbattach $S"

Con todo esto ya tenemos un sistema host que arranca directamente las VM que seleccionamos desde el menu de inicio de grub.

Que las VM's reconozcan los dispositivos USB de forma transparente al usuario de la VM.

Y que la máquina física se apage al apagar la VM.

En la próxima 3ª parte nos meteremos en como automatiza la clonación de estos equipos virtualizados.

Mantenimiento de Aulas. Un enfoque virtualizado. (Parte 1/3)

Fueron varias las preguntas que surgieron cuando considere la posibilidad de utilizar Máquinas Virtuales en equipos de laboratorio:

• ¿para que?¿que ventajas ofrece si ya tengo un sistema de clonación?
• ¿Podre clonar las máquinas virtuales utilizadas y desplegarlas con multicast?
• ¿Podre clonar Windows7 y ejecutar el sysprep para preparar el sistema (incluirlo en Active Directory y darle un nombre, ...etc)?

Después de investigar un poco y realizar varias pruebas, las respuestas fueron afirmativas.

¿Para que?¿Que ventajas ofrece? 

Encontré varios motivos para adoptar este enfoque, pero el decisivo, fue el uso de las instantáneas del sistema o snapshot. Las snapshot permiten restaurar el sistema automáticamente antes de cada arranque y de forma casi instantánea. Con lo que el usuario siempre se encuentra un sistema limpio y en perfecto estado.

Las otras ventajas eran:

• Independencia del hardware.
• Actualización de los sistemas virtuales usando multicast.
• Posibilidad de redimensionar los discos virtuales.
• Flexibilidad para realizar casi cualquier cosa.

 Desventajas:

• Posible perdida de rendimiento con respecto al uso directo del hardware del equipo. Pero he realizado el test de configuración de Windows 7 y los resulados son:
• CPU 6.4
• RAM 6.7
• Video 1 (no soporta aceleración 3D)
• Disco 6

       Teniendo en cuenta que W7 puntua de 1 a 7.9 me parecio mas que suficiente.
        El problema de la aceleración 3D tampoco supone gran cosa mientras no se vayan a usar los equipos para render o juegos.


¿Podre Clonar las VM?

Esto en importante porque de forma regular es necesario instalar nuevas aplicaciones o actualizar las ya instaladas.

A priory Existe la posibilidad de usar dos métodos:

• Clonar todo el disco o partición del sistema mediante el sistema de clonado que usemos de forma habitual (recomiendo Clonezilla SE).
• Copiar el disco virtual (fichero vdi) actualizado a los clientes.

Ambos enfoques son válidos.

Puesto que existe la posibilidad de enviar ficheros desde un servidor a varios clientes usando multicast (mediante la herramienta udp-cast de Linux), parece que transferir los ficheros vdi nos permitiría actualizar las distintas VM de forma independiente (con el consiguiente ahorro de tiempo).

Sin embargo, también es posible crear una partición para alojar cada fichero vdi y así utilizar el método de clonado de discos (o particiones) que usemos habitualmente (¿Clonezilla SE?).

Yo adoptare la transferencia de ficheros vdi con udp-cast, me parece más flexible y así lo pruebo.

¿Podré usar Sysprep con Windows7?


Gracias al programa vdfuse-v82 (ojo tiene un bug para discos VMDK), es posible montar los discos vdi en el sistema de ficheros anfitrión, con lo que podremos parsear el fichero sysprep.xml con los datos que queramos y ponerlo en la VM con Windows7 para ejecutar el sysprep al arrancar.

Por supuesto también permite acceder al disco de la VM con Linux.

Nota:He conseguido que lo ejecute y funcione, pero al parsearlo, no me hace el cambio de nombre. Seguiremos informando.

¿Vale, pero como lo hago?

La idea es montar un sistema anfitrión con Linux y usar VirtualBOX para levantar las máquinas virtuales  (en adelante VM).

Una vez instalado todo y configurado, los equipos arrancan con Grub y se muestra un menú para seleccionar el S.O a utilizar, así como la opción de mantenimiento (para la que se requiere de contraseña).

Como sistema host he utilizado ubuntu 10.4.1 server versión de 64bits. Instalado con la opción de "sistema mínimo" y sin seleccionar ningún paquete durante el proceso de instalación.

Como virtualizador he utilizado VirtualBOX versión 3.2, por que es el paquete que viene en la distro y parece que va mas ligero que la versión 4.

Para poder montar los discos vdi en el sistema de archivo del host y hacer cosas como parchear el sysprep.xml para Windows7, he utilizado vdfuse-v82 (que es posible compilarlo utilizando las headers de la versión ose del VirtualBox).

Que sí, que sí, pero ¿como?

Para abreviar, partiremos de la base de que ya hemos instalado ubuntu 10.4.1 server, sistema mínimo y sin ningún paquete seleccionado y virtualbox-3.2. El que tenga dudas ya sabéis, internet lo sabe todo, a buscar que hay mucha documentación.

Lo primero que hay que hacer es cambiar grub2 por grub1.5, más fácilmente configurable.

La idea es crear un fichero de configuración con menús para arrancar las distintas VM más un menú de configuración protegido por contraseña. Ejemplo del fichero menu.lst:

title        Windows 7

kernel        /boot/vmlinuz-2.6.35-020635-generic root=/dev/sda1 ro quiet VM=W7

initrd        /boot/initrd.img-2.6.35-020635-generic

quiet

title        Linux

kernel        /boot/vmlinuz-2.6.35-020635-generic root=/dev/sda1 ro quiet VM=Linux

initrd        /boot/initrd.img-2.6.35-020635-generic

quiet

title        Linux Practicas

kernel        /boot/vmlinuz-2.6.35-020635-generic root=/dev/sda1 ro quiet VM=Linux2

initrd        /boot/initrd.img-2.6.35-020635-generic

quiet

title        Mantenimiento

password --md5 $1$PZgknzmNqPTYhVU/kiCW0

kernel        /boot/vmlinuz-2.6.35-020635-generic root=/dev/sda1 ro quiet

initrd        /boot/initrd.img-2.6.35-020635-generic

quiet

 

La variable de la linea del kernel "VM", la utilizo para evaluar que menú ha sido seleccionado y arrancar la VM correspondiente.

He creado un script que se ejecuta al arrancar llamado VMboot.sh que esta en /etc/init.d :

#!/bin/bash

VM=`cat /proc/cmdline | awk -F 'VM=' '{print $2}' | awk '{print $1}'`
case "$VM" in
    'W7')
    su MiUsuario -c /home/MiUsuario/StartW7.sh;;
    'Linux')
    su MiUsuario -c /home/MiUsuario/StartLinux.sh;;
    'PrimerArranque')
    /home/MiUsuario/PrimerArranque.sh;;      
esac

Este script lanza los scripts que levantan la máquina virtual correspondiente. La opción de "PrimerArranque"  la utilizo para hacer tareas de postclonado que veremos más adelante.