Elegí esta tableta en particular porque traía Android, el sistema operativo más libre (y popular) que conozco para dispositivos móviles… sí, ya sé que está algo lejos de ser bastante libre, pero bueh…

Al tiempo de usarla empezó a tener problemas de software, el cliente de correo que trae crasheaba demasiado seguido y no era la única aplicación que explotaba. Revisando por internet encontré que había dos releases más modernos publicados por Google y mi tableta no los tenía. Lo primero que pensé es que Personal no los había liberado aún, esto fue más bien por desconocimiento del funcionamiento de las actualizaciones en el ambiente Android (sigo sin saber muy bien cómo es, si es que Google libera en su repositorio y todos los dispositivos se actualizan o si esto puede ser manipulado por la compañía de teléfonos o distribuidor del aparato). En fin… la realidad es que estaba clavado en Android 3.0 y ya estaba dando vueltas Android 3.1 e incluso 3.2.

Dado que la tableta es un dispositivo no esencial para mi vida me decidí a actualizarla a manopla.

Como estuve una buena cantidad de horas con esto pensé en escribir un artículo técnico para que otro pudiera hacerlo más velozmente.

Todas estas explicaciones técnicas son para hacer desde un Linux, los usuarios de otros sistemas operativos les puede servir la explicación de cómo funcionan estas cosas.

La tableta parece tener –como las computadoras comunes– dos instancias de booteo, primero ejecutan un software que vendría a ser un “BIOS” y luego cargan el sistema operativo. El “BIOS” de la Xoom está en una región de memoria no escribible fácilmente (por lo menos no encontré cómo, pero eso es bueno, porque de sobrescribir mal esta sección brickeas la tableta y fuiste), este software tiene unas pocas opciones que te permiten:

• Acceder a la imagen de recuperación (esto es un software que se puede modificar)
• Ponerla en modo de Fastboot Protocol (esto sirve para cambiar el sistema operativo que bootea la tableta)
• Y hay un modo RSD que no sé qué es, ni para qué sirve.

El cómo…

Lo primero que hay que hacer es tener un cable USB para la tableta que funcione bien (si no tenes uno podes usar el de los teléfonos BlackBerry o Nexus1), también preparar el Linux para que detecte la tableta al conectarla por el cable USB.

Preparación de Linux

La preparación del Linux es simple:

sudo touch /etc/udev/rules.d/51-android.rules
echo "SUBSYSTEM==\"usb\", SYSFS{idVendor}==\"22b8\", MODE=\"0666\"" |sudo tee -a /etc/udev/rules.d/51-android.rules
sudo /etc/init.d/udev restart

Con esto Linux ya debería ver la tableta al enchufar el USB, más información y con más detalle sobre esto acá.

Herramienta para cargar ROMs

Luego hay que bajar el software de fastboot para Linux. Hay otro que se llama ‘adb‘ que es muy útil, pero está pensado para hacer bastantes más cosas y para quienes desarrollan aplicaciones para Android.

Como solo se necesita fastboot, lo podes descargar de esta página (que te lo dan todo compiladito). Alternativamente podes bajar tooooodo el SDK de Android para Linux (con sus prerequisitos) y luego compilar los fuentes de fastboot.

Bajar ROMs

Motorola publica las diferentes versiones que tiene de Android para tabletas Xoom aća. Yo probé casi todas las ROMs que publican y todas funcionaron en mi Motorola Xoom de Personal (que viene con 3G y wifi), menos la de Verizon. Lo que no sé es si todas las Xoom son iguales a nivel hardware y es el software quien activa el 3G o el wifi. Incluso te da las instrucciones para cambiar las ROM en esa página.

Cada ROM viene con 4 archivos dentro (recovery.img, system.img, userdata.img y boot.img).

Para cargar la ROM lo que hay que hacer es reiniciar la tableta y cuando está prendiendo apretar el botón de “bajar volúmen” (el que está sobre el contorno izquierdo del dispositivo). Cuando aparece la leyenda “Starting Fastboot protocol support.” ya se pueden empezar a ejecutar estos comando:

El clásico WARNING: Aća es donde borras todo y perdes la garantía que tenes del aparato, sabelo porque es exactamente lo que estás por hacer. Además… a no venir con reclamos, si no funciona es tu culpa por hacer cosas que no debes (como no hacerle caso al fabricante ) y no es mi culpa. A quién se le ocurre??? andar hackeando cosas… no hacer lo que le dicen que hay que hacer y caminar por otra senda que la indicada.

Entonces, primero descomprimis el archivo que contiene la ROM (el que trae los cuatro archivos .img) y luego en modo fastboot protocol ejecutas:

fastboot oem unlock

(y seguís las instrucciones de la pantalla de la xoom, luego se reiniciará nuevamente, de nuevo tenes que apretar el botón para bajar el volúmen y cuando esté de nuevo en modo fastboot protocol ejecutas: )

fastboot flash boot boot.img
fastboot flash system system.img
fastboot flash recovery recovery.img
fastboot flash userdata userdata.img
fastboot erase cache
fastboot erase userdata
#fastboot oem lock (esto no es obligatorio)
fastboot reboot

Al reiniciar va a ejecutar el nuevo sistema operativo y te va a pedir todos los datos que te pidió cuando la compraste y prendiste por primera vez.

Hasta ahora NADA nuevo, porque estas ROMs son las que vienen con la XOOM de fabrica. Si queres la ROM que te permite actualizar (por vía normal, o sea, desde Google) a Android 3.2 tenes que bajarte la ROM del Build HWI69 de esta página. Esta ROM viene con Android 3.0, pero al registrar tu Xoom con tu cuenta de Google empieza a bajarte las actualizaciones (a 3.1 primero y luego a 3.2), pero esta ROM solo es para wifi.

Con esa ROM vas a tener Android 3.2 pero solamente con wifi.

La alternativa a esto es utilizar la ROM de la gente de Tiamat. Usando esta ROM vas a tener Android 3.2 y además ya está rooteada, por lo que no será necesario poner otros boot.img para permitir ejecutar comandos como root.

Para trabajar con esta ROM hay que hacer algo previo que es cambiar la imagen de recovery (recovery.img). La imagen de recovery no es un backup de tu imagen en uso (que te permite restaurar lo que tenías de fábrica), sino que es un “sistema operativo” que te permite instalar otras ROMs, formatear todo, borrar todos los datos de usuario, básicamente te permite tratar de recuperar el sistema.

Hay un “sistema operativo” de recovery que se llama ClockWorkMod que extiende las posibilidades y te permite hacer cosas como instalar una ROM leyendo la microSD (un disco flash que podes poner y sacar de la tableta y no tener que usar el cable USB), algo indispensable para instalar la ROM de la gente de Tiamat utilizando el archivo .ZIP y no el .IMG (que se usa si lo haces en modo fastboot con la herramienta).

Seguí las instrucciones de esta página y vas a poder cambiar el “sistema operativo” de recovery. Una vez hecho booteas en modo recovery (apretas el botón para bajar el volumen 3 segundos después de que aparece el primer logo al iniciar) y desde este nuevo recovery instalas la ROM de Tiamat.

La ROM de Tiamat no reemplaza toooodo, sino que cambia el kernel y algunas cosas más. Si vas a instalar la ROM de Tiamat hacelo teniendo instalado la ROM de fábrica. A mi me pasó que instalando la ROM de Tiamat no tenía forma de conectarme al 3G de Personal. Esto era porque instalé la ROM modificando una base de ROM de Motorola solo para wifi (que no tiene la posibilidad de configurar 3G). Volví todo atrás, puse la versión de Motorola que tiene 3G y wifi para LATAM y al modificar esa base con la ROM de Tiamat pude usar 3G sin problemas.

Todo muy lindo… pero luego de todo esto, todo este tiempo probando cosas y aprendiendo cómo funcionan y bootean estos dispositivos y teniendo Android 3.2 con todos los chiches… el cliente de correo sigue explotando . Pero ya no me importa tanto.

Suerrrrrte! Espero que te sea útil.

Páginas útiles:

http://yosoyandroid.com/?p=6957

http://forum.xda-developers.com/archive/index.php/t-1049485.html

Para el que no está acostumbrado a tener un smart phone, la primer experiencia de uso es molesta, uno lo ve como un teléfono, pero en realidad lo tiene que ver como una computadora o PDA, porque sino las ganas de tirarlo por la ventana son bastante fuertes.

—Pero si yo antes, para hacer una simple llamada, apretaba el botón verde, buscaba en contacto usando los números (único teclado de cualquier telefono) y listo!

Ahora, queridísimo y flamante usuario de smartphone, no es tan sencillo. Por lo menos con el HTC G1 tenes que:

1. Apretar el botoncito verde
2. Elegir la solapa correspondiente (tenes cuatro: Dialer -para usar los números presionandolos desde la pantalla-, Call log -que te dice las llamadas entrantes/salientes/perdidas, Contacts -listado de contactos- y Favorites -que se va llenando sola con los números más utilizados-)
3. Al elegir Contacts te aparecen todos los contactos, podes: a) abrir el teclado y tipear el nombre -hace búsqueda incremental- o b) mover la lista de contactos con el dedo para elegir a quien llamar.
4. Luego de elegir podes apretar el botón verde nuevamente y llama al primer número de ese contacto o elegir otro de los números de ese contacto y así llamar a su “Work” por ejemplo.

No es tan fácil como antes, claro que ahora tengo la dirección de mail de los contactos (no solamente como dato ya que puedo usarla para enviarle un correo), multiples datos asignables al contacto como cualquier agenda y la foto de cada contacto descargada directamente de facobook, porque hay una aplicacioncita para android que se conecta a tu FB, se fija si hay contactos con datos similares (nombre, email) y descarga la foto que tiene de su perfil ese contacto y la ubica en tu agenda telefónica.

Pros y contras, como siempre. Igualmente el teléfono inteligente está mejor que mi teléfono para llamar únicamente que tenía antes. Usa Android -que es software libre- y a pesar de sus DRMs muy a la vista, hay muchas aplicaciones (libres) portadas a Android, como un cliente de OpenSSH, cliente de correo a elección y además muchas aplicancioncitas que te hacen la vida más fácil.

Desgraciadamente solo funciona en modo EDGE y no 3G (me cansé de buscar por qué ya que tiene el mismo hardware de conectividad que el HTC TyTN y sí funciona en 3G de Movistar), por lo que la conectividad a inet es lenta.

Para aquellos que estén pensando en cambiar a un smartphone piensen si les sirve tener tanta información (agenda y datos) en un aparato móvil y que tener todo esto implicará mayor complejidad de uso.

Ah! Y otra cosa muy importante, si sos medio reacio a enviar tus datos privados a grandes empresas como Google, no te compres estas cosas porque están pensados para que todo el mundo confíe plenamente en grandes corporaciones (no es mi caso, pero soy geek y creo saber como evitar que esto ocurra).

Lástima que no tengo este reloj, sino me sentaría a ver pasar los segundos y preparar una cámara para sacarle una fotito.

Me tendré que conformar con escribir

watch -n 1 "perl -e \"print time() . \\\"\n\\\"\""

en una laptop y mirar el monitor sin pestañar.

Salud a todos los geeks que -como yo- nos juntaremos para vernos las caras y decir “No podeeeeeessss ser tan geek”

Hace algunos años, muchos desgraciadamente, no podía irme a dormir si no había terminado de configurar ese programa, esa aplicación o esa configuración que hace aquello tan maravilloso. Recuerdo hasta momentos donde me desperté soñando la solución a un bug o una forma diferente de encarar una funcionalidad nueva. Esos tiempos han pasado y ya hace tiempo. Ahora, que estoy más viejo, quiero que las cosas funcionen de una, nada de andar configurando esto para que ande esto otro que justamente es lo que necesita el sistema que (tan solo) quiero probar.

Lógicamente apoyo esto de no tener que reinventar la rueda todo el tiempo ¿Para qué hacer una aplicación accesible vía browser y programar (primero) un servidor web? (existiendo apache) Claro que es un ejemplo burdo, pero hay muuuuchos sistemas, compañías y programadores que caen en esta trampa, generalmente porque no conocen el software libre, su software es software privativo y creen cosas de lo más estúpidas como: si no hay que pagarlo seguramente es una porquería (o algo cercano a ello), si uso un software libre mi software entonces tiene que ser libre también, etcétera, etcétera, etcétera.

Pero es tan lindo cuando uno instala un software de servidor e instantáneamente se lo puede probar. El caso de openfire es uno de ellos, instalas el paquete, levantas el servicio y guala! todo anda. Accedes desde el browser a la interfaz de administración, te bajas el cliente XMPP (Spark) o cualquier otro y lo podes probar, queres ver qué onda alguna de sus extensiones y desde la interfaz web la instalas (el sistema la baja de sitio web correspondiente), la activas y ya está. Ningún shell, ningún comando.

No hay que configurar ningún otro demonio, ninguna base de datos, crear ningún usuario (bueno, lo hace el instalador del paquete) ni preparar nada. Ah! no, miento, hay que tener un JRE disponible (porque está escrito en JAVA).

Este tipo de facilidades solo las he visto en aplicaciones (libres) para el escritorio. Firefox, Thunderbird, OpenOffice.org y muchos otros no requieren más que eso… instalarlos, para empezar a usarlos.

Claro, openfire resuelve algo que está relativamente aislado en lo que se refiere a subsistemas necesarios, es un servidor XMPP. Solo es necesario implementar el protocolo, brindar una interfaz de administración y listo, pero igualmente hay otros servidores XMPP que son muy diferentes en lo que refiere administración e instalación.

Lo pudieron haber escrito en J2EE, como tantas aplicaciones libres escritas hoy (lo que hace muy incomodo de probar algún sistema) o la interfaz web la pudieron haber escrito en PHP y así requerir que apache esté configurado con su VirtualHost correspondiente, lógicamente se requiere guardar algún dato en alguna parte y qué mejor que usar una base de datos MySQL (claro que para eso hay que tener un usuario para esa base y darle los permisos necesarios).

Nada de todo esto es imposible de hacer, siempre está el archivo INSTALL que te dice como hacerlo “en dos patadas”, pero cansa. Si uno está evaluando software para ver si lo evalúa con mayor énfasis generalmente se baja todo lo que parece que hace lo que uno necesita. Si ya para instalarlo hay que dar algunas vueltas, preparar tantas cosas el listado de software posible se va reduciendo solo y las expectativas del testeador bajan.

Para mi una aplicación libre tiene muchas más posibilidades de ser popular si su método de instalación y administración está bien pensado, bien fácil, bien APB (y también tener un modo avanzado para hacer las cosas como se debe sin tantos defaults). Sino se tiene que hacer popular de la manera tradicional, mostrando lo buena que es técnicamente y que la gente (poca inicialmente) hable bien de ella. El camino largo, pero no necesariamente mejor (técnicamente hablando) que el propuesto.

Gracias a la gente de Openfire y espero que muchos programadores de software libre aprendan de esta experiencia.

El método básicamente es el agregar un encabezado SMTP cuando se envía el mail con un hash (firma) creado con la parte privada de la clave RSA. Cuando el MTA receptor recibe este correo, hace una consulta DNS, obtiene la clave pública del dominio del cual fue enviado el correo y verifica la autenticidad del hash.

En este post voy a describir cómo lo implementé en un debian etch.

Implementación

Para implementarlo finalmente elegimos usar dk-milter o dk-filter (que es lo mismo).
Debian trae un paquete en lenny, por lo que me baje los fuentes con:

apt-get -t lenny source dk-milter

y después lo compilé (con dpkg-buildpackage)

Lo primero que hay que hacer es armar los certificados. El paquete trae un comandito para hacerlo gentxt.csh, este comando se ejecuta pasandole dos argumentos, el “selector” que es un nombre (yo le mandé “calculin”) y el nombre del dominio al que pertenece el certificado, en este caso fue “cafelug.org.ar”.

Genera dos archivos:

• calculin.public
• calculin.private

El archivo privado es el más importante y hay que ponerlo en alguna parte que después lea el demonio, yo lo mandé en /etc/postfix/domainkeys.

Luego hay que configurar el DNS y también algunos parámetros del dk-filter.

El dk-filter se configura tocando el archivo /etc/default/dk-filter y así quedó:

# Sane defaults: log to syslog
DAEMON_OPTS="-l -m smtpd,postfix"
# Sign for example.com with key in /etc/mail/domainkey.key using
# selector '2007' (e.g. 2007._domainkey.example.com)
DAEMON_OPTS="$DAEMON_OPTS -d cafelug.org.ar -s /etc/postfix/domainkeys/dk_cafelug.org.ar.pem -S calculin"
# See dk-filter(8) for a complete list of options
#
# Uncomment to specify an alternate socket
#SOCKET="/var/run/dk-filter/dk-filter.sock" # default
#SOCKET="inet:54321" # listen on all interfaces on port 54321
SOCKET="inet:1025@localhost" # listen on loopback on port 12345
#SOCKET="inet:12345@192.0.2.1" # listen on 192.0.2.1 on port 12345


Entre las opciones esta -l que es para que mande los logs a través de syslog, -m smtpd,postfix no sé si es necesario (entre las pruebas que hice quedó). Las otras son más importantes:

• -d cafelug.org.ar (el dominio del certificado, se pueden poner más dominios)
• -s /etc/postfix/domainkeys/dk_cafelug.org.ar.pem (el lugar donde está la clave privada)
• -S calculin (el “selector”).

Y la parte que me volvió un poco loco fue la opción de SOCKET=, postfix corre en chroot, por lo que la opción SOCKET="/var/run/dk-filter/dk-filter.sock" me tiraba ”’file not found”’… estuve un rato para acordarme y darme cuenta que no lo encontraba porque no estaba dentro del jail. En fin, lo deje escuchando en un puerto y así no da problemas.

Configuración de DNS

La configuración de DNS es ”tricky”, la documentación que encontré no es muy específica. La forma de correcta de setearlo es poniendo ”’dos”’ entradas de tipo ”TXT” en la zona:

calculin._domainkey.cafelug.org.ar. TXT "k=rsa; t=y; p=MFwwDQYJ[...]xfS+g/UlcszvzvY3UPFNEVGEecCAwEAAQ=="

_domainkey.cafelug.org.ar. TXT "t=y; o=-"

La primera indica la clave pública (encodeada en Base64) para el selector ”calculin” (que use con el gentxt.csh) y es importante que esté con el selector adelante y seguido de un ”.” (punto). O sea ”<selector>._domainkey.<dominio>”, las demás opciones (”’k=”’ y ”’t=”’) están claramente documentadas en la RFC 4870.

La segunda entrada indica cómo deben ser tratados los mails que llegan de este dominio, ”’t=”’ indica que el dominio está en ”test-mode” (esto se saca una vez que lo pasamos a producción), luego la opción ”’o=”’ tiene varios valores, ”~” indica que los mails pueden ser firmados o no, en cambio ”-” indica que todos los mails enviados van a salir firmados.

Configuración de postfix

La configuración de postfix es simple, lo único que hay que tener en cuenta es la versión de postfix. Esto está soportado desde la versión 2.3.

smtpd_milters = inet:127.0.0.1:1025
non_smtpd_milters = inet:127.0.0.1:1025


smtpd_milters indica donde encuentra los ”milters” definidos (ojo con la sintaxis, no es la misma que usa el dk-milter, intercambia la posición del ”host” y ”puerto”, así que no hay que hacer cut&paste).

non_smtpd_milters es para los mails generados localmente.

Probando la configuración

Para probar si todo quedó bien se pueden enviar mails a una cuenta de Yahoo! que hace el chequeo (aparece una leyenda debajo del “From:” visible desde la interfaz web (sin tener que ver los encabezados completos). La otra forma es enviando un mail a una cuenta que responde automáticamente diciendo el estado del tema. Esta cuenta es autorespond e@n dk.elandsys.com

Lo que hay que tener muy en cuenta es que tanto Yahoo! como el servidor que recibe el mail de la dirección de testeo tienen que tener la zona de nuestro dominio actualizada. Generalmente van a tenerla en un cache (si es que ya mandaron algun mail al dominio en cuestión), por lo que el test puede darnos que falló, cuando en realidad solo hay que tener paciencia y esperar a que nuestra zona expire en el DNS cache que leen estos MTA.

Conocer los inicios de los proyectos de software siempre es bueno, porque da una visión sobre el futuro del proyecto y de su estado actual, especialmente en software libre.

Xen fue inicialmente un proyecto de investigación de la Universidad de Cambridge (la primer versión del software fue publicada a fines de 2003). Este proyecto de investigación fue liderado por Ian Pratt, quien luego formó una empresa -junto con otras personas- para dar servicios de valor agregado como soporte, mantenimiento y capacitación sobre Xen en Enero de 2005. Esta empresa es Xensource Inc., recibió fondos por millones de dolares de diferentes inversores y actualmente mantiene Xen (junto con otras empresas y la comunidad), también se dedica a programar aplicaciones adicionales no libres para facilitar el uso, instalación y mantenimiento de Xen.

Dado que Xen está licenciado bajo GPL el código no puede cerrarse, y no es solo Xensource quien mantiene el código, sino que varias empresas importantes como IBM, Sun, HP, Intel, AMD, RedHat, Novell están sumamente involucradas en el desarrollo asignando programadores al mantenimiento de este software.

Paravirtualización

En las computadoras que estamos acostumbrados a utilizar a diario el sistema operativo es el software mas poderoso, ya que controla todos los recursos del CPU, como el uso compartido del mismo entre las aplicaciones, memoria virtual, I/O a dispositivos, entre otras cosas. Estas tareas las puede realizar gracias a que los procesadores modernos soportan niveles de privilegios o rings. El sistema operativo, el supervisor, corre en el ring 0 (más privilegiado) y las aplicaciones en ring 3 (menos privilegiado). ¿Cómo se adapta Xen a este esquema?, utiliza una técnica llamada “ring deprivileging”, donde el sistema operativo es modificado para poder ejecutarse en ring 1 dejando el ring 0 para el Xen, el cual es conocido como Hypervisor. Este mecanismo le permite a Xen tener más poder que el sistema operativo controlando los recursos a los cuales este puede acceder. Este esquema de usos de rings es lo que se llama “paravirtualización”. A diferencia de lo que dice Xensource en su página web, ellos no fueron los que inventaron el concepto, sino que existe desde hace ya algunos años.

La modificación que deben sufrir los sistemas operativos para ser virtualizados en principio presenta una limitación, ya que esto solo puede realizarse en software abierto (o por el fabricante del software, en el caso del software propietario). Sin embargo, esta limitación es eliminada con las nuevas tecnologías de virtualización de Intel y AMD, que permiten ejecutar sistemas operativos en ring 0 sin necesidad de modificación alguna, dejando un nivel de privilegio especial para el Hypervisor. Este nivel de privilegio especial se llama root-mode, el resto de los componentes corren en non-root-mode.

El rendimiento superior de Xen es una de sus características principales, ya que los sistemas virtualizados corren directamente sobre el procesador, sin emulación. Sistemas de virtualización como VMWARE y Virtual PC o Virtual Server de Microsoft utilizan una técnica conocida como “binary translation”, donde las instrucciones privilegiadas son reemplazadas con fragmentos de código que simulan las mismas.

Usos de Xen (o de la virtualización en general)

Xen es extremedamente util para hacer un mejor uso del hardware disponible en una empresa. Generalmente el hardware que se utiliza para un servidor de páginas web, servidor de correo u otros servicios de red no es utilizado en la totalidad de su capacidad.
Al migrar estos servicios a máquinas virtuales, el hardware se utiliza mejor ya que es compartido por todas las máquinas virtuales (y se achican los espacios físicos que se necesitan en los datacenters).
Adicionalmente al mejor uso del hardware, se agrega la posibilidad de tener máquinas virtuales para usarlas como respaldo de equipos en producción. Si un equipo crítico de producción tiene un problema de hardware se puede activar una máquina virtual (ya preparada) para que tome el control de este servicio mientras se repara -con más tiempo y tranquilidad- el problema de hardware.
Otra posibilidad muy interesante es la posibilidad de liberarse de equipos viejos que están brindando un servicio desde hace años, muchas veces trabajan sobre equipamiento obsoleto (y que generalmente son grandes en uso de espacio físico). Estos equipos se pueden migrar a máquinas virtuales tranquilamente.
Por último, la virtualización es muy útil para empresas que desarrollan software, ya que es común encontrarse con la necesidad de los programadores de probar algun software nuevo (bibliotecas de funciones, nuevos compiladores, etc.) que pueden perjudicar el trabajo de otros programores. En estos casos, solo basta con activar una nueva máquina virtual, instalar las cosas que se necesitan, hacer las pruebas, extraer las conclusiones y luego borrar todo.

Soporte de distribuciones Linux y otros ss.oo.

Las grandes empresas de distribuciones Linux (RedHat y Novell) están sacando versiones de sus distribuciones ya preparadas para Xen, muchas otras distribuciones como Debian, Fedora y otras también tienen kernels disponibles para poder ser virtualizados o que actúen como “host” de máquinas virtuales (domain 0).

Existen otros sistemas operativos que se pueden utilizar para trabajar como domain 0 y también ejecutarse dentro de una máquina virtual, por ejemplo NetBSD y Opensolaris. Dado que Xen implementa paravirtualización, para que un sistema operativo se ejecute dentro de una máquina virtual Xen éste debe ser modificado. Siempre y en cuanto el equipo donde corre Xen es un equipo de arquitectura x86 común. En el caso de utilizar un equipo con la nueva tecnología de Intel (Intel-VT) o AMD (AMD-V), Xen puede ejecutar máquinas virtuales de sistemas operativos propietarios (sin necesidad de modificar esos sistemas operativos) como Microsoft Windows.

El uso de estos nuevos procesadores de Intel y AMD abre enormemente el mercado donde se puede implementar Xen, esto, sumado al rendimiento superior que se logra al utilizar paravirtualización, hace de Xen un software competitivo y muy tentador a la hora de seleccionar un hypervisor.

En lo que respecta a distribuciones que venden las suscripciones para obtener mantenimiento, RedHat sacará sus suscripciones permitiendo usar una suscripción para todas las máquinas virtuales que ejecuten RHEL dentro de un mismo hardware. Reduciendo aún más los costos al utilizar virtualización.

Interfaces de administración

Dado que Xen es software libre constantemente se van conociendo nuevas interfaces de administración para el producto.
Actualmente las más destacadas son Enomalism (escrita en python) y Xenman (gtk). RedHat por su parte está desarrollando una intefaz de administración para Xen llamada virt-manager. Y por último Xensource vende un producto (Xen Enterprise) que trae una interfaz de administración, monitoreo que también algunas herramientas útiles para instalar más fácilmente diferentes sistemas operativos en las máquinas virtuales.
Todas las interfaces (exceptuando la de Xensource) están en estado beta y no todas son fáciles de instalar. La más compleja es Enomalism por su metodología de autenticación de usuarios. Para autenticar usuarios utiliza FDS (Fedora Directory Service) que es un producto (libre) para manejar varios directorios (LDAP) en forma centralizada. FDS es un producto pensado para empresas muy grandes o sistemas de directorios complejos, y si bien sus pantallas son todas gráficas, no es muy intuitivo para usarlo.
De todas formas los comandos que provee Xen para interactuar con las máquinas virtuales son muy fáciles de usar y no son muchos.

Características de Xen

Entre las características de Xen se destaca su velocidad, lo pequeño de su código fuente (menos de 50.000 lineas de código), un excepcional particionamiento de recursos de E/S de bloques y red, CPU y memoria. La posibilidad de “mover en caliente” máquinas virtuales de un equipo de hardware a otro. Un excelente rendimiento (entre 0.1% y 3% de overhead). Tiene soporte de hasta 32 procesadores en paralelo (SMP), soporta PAE (Physical Address Extension) para servers de 32 bits con más de 4Gb. de memoria RAM y tiene soporte para hardware de virtualización Intel VT y AMD Pacifica.

Detalles técnicos
La instalación de Xen no requiere más que un kernel con el parche de Xen y las herramientas de usuario para poder crear, destruir y modificar los valores de las máquinas virtuales en caliente (cantidad de memoria, parámetros del algorítmo de particionamiento de CPU que esté utilizando la máquina virtual) entre otras herramientas.
Los archivos de configuración de las máquinas virtuales de Xen son muy simples. Un ejemplo sería el siguiente:

kernel = “/boot/vmlinuz-2.6-xen”
ramdisk = “/boot/initrd-2.6-xen.img”
memory = 128
name = “mv01″
vif = ['mac=52:54:00:12:34:56','bridge=xenbr0']
disk = ['phy:vg/vg01,hda1,w','phy:vg/vg01swap,hda2,w']
root = “/dev/hda1 ro”
vcpus = 2
cpus = “0-3,5,^1″
pae = 0
acpi = 0
cdrom=”/dev/cdrom”

Los archivos de kernel y ramdisk residen en el disco del domain 0, “memory” indica la cantidad de memoria en megabytes que se le da inicialmente a la máquina virtual. “vif” indica los parámetros de la interfaz de red, su MAC Address y también el nombre que tiene la interfaz (del domain 0) que actúa haciendo un bridge entre el domain 0 y la intefaz de red virtual de la máquina virtual. Por defecto Xen crea un bridge para enviarle los paquetes que llegan a la placa física de red que están destinados a una u otra máquina virtual.
“disk” indica los dispositivos físicos donde están los discos (o particiones) que usa esa máquina virtual, generalmente se utiliza LVM (Logical Volumen Manager) para darle más flexibilidad al espacio que puede utilizar la máquina virtual. “root” es un parámetro que solo se usa en máquinas virtuales Linux que indica qué dispositivo (visto desde la máquina virtual, por eso el dispositivo es /dev/hda1) y cómo va a montarlo inicialmente, generalmente es modo solo lectura (ro). Con “vcpus” se puede simularle a la máquina virtual que tiene más procesadores de los que en realidad tiene (muy práctico para programación de aplicaciones que usen varios procesadores). El valor de “cpus” indica sobre qué CPU (físicas) va a correr esta máquina virtual, en este caso correrá sobre el procesador 0, 2, 3 y 5.
Los parámetros de acpi=0 y pae=0 indican que no se utilizará ACPI ni PAE en esta máquina virtual.
En el caso del valor de “cdrom” se le indica el dispositivo asignado a la lectora de CD, el valor de este parámetro puede ser el nombre de un archivo del disco (del domain 0), por ejemplo “/mnt/images/w2000server.iso” que puede ser util para la instalación de la máquina virtual.
Con este archivo creado y el disco indicado (“/dev/vg/vg01″ en el ejemplo) con el sistema operativo ya instalado se puede levantar o activar la máquina virtual utilizando el comando “xm create -c mv01″.

Otros comandos de Xen

- xm top (muestra el uso de recursos de cada máquina virtual)
- xm mem-set (ajusta la cantidad de memoria que puede utilizar la máquina virtual en caliente)
- xm migrate (mueve en caliente la máquina virtual para que siga ejecutandose en otro equipo)
- xm shutdown (ejecuta el proceso de apagado de la máquina virtual)
- xm list (lista todas las máquinas virtuales en funcionamiento)

Conclusiones
Xen es un producto probado, utilizado y listo para usar en producción. El hecho de que esté licenciado bajo GPL no solo baja mucho los costos, sino que también le da mucha flexibilidad y proyección a futuro (en la vida del proyecto).
Este producto combinado con sistemas de storage propietarios o libres (utilizando LVM -Logical Volumen Manager, mdadm -manejo de RAID por software para Linux-, IET -iSCSI Enterprise Target- y GFS -Global FileSystem-) puede dar excelentes resultados, alta disponibilidad y una escalabilidad sorprendente.
Mi recomendación es probarlo, aunque sea para virtualizar sistemas operativos libres y luego avanzar sobre Xen en hardware que soporte la separación de privilegios (rings).

Agradecimientos

• A Diego Woitasen por ayudarme con la escritura del artículo.

Referencias y lectura adicional
http://en.wikipedia.org/wiki/Xen
http://www.xensource.com
http://www.enomalism.com
http://xenman.sourceforge.net
http://www.linuxjournal.com/article/8540
http://iscsitarget.sourceforge.net/

Años más tarde, o sea, ahora … me encuentro con que quiero hacer algunas cosas básicas en otra distribución (que no sea Debian) y me vuelvo algo loco…

Por ejemplo, ¿Es necesario que me tenga que recorrer todo google para encontrar cómo catzo se hace para recompilar locales en Fedora? Tan fácil es en Debian ejecutar “dpkg-reconfigure locales´´ que uno se imagina que en otras distribuciones tiene que haber algo similar.

¿Cómo hago en Fedora para tener disponible otro idioma si cuando lo instalé no marqué en “Idiomas disponibles” al Español?

Bueno, no sé si realmente ésta es la aplicación correcta en Fedora, pero finalmente logré resolver el inconveniente ejecutando “build-locales-archive”. Un binario que viene (creo) dentro del paquete de la glibc.

Para colmo de males, la aplicación que quería que apareciera en castellano sigue sin aparecer en nuestro hermoso idioma por el simple hecho de que no está traducida, así que ahora no sé si los locales estaban realmente compilados en este fedora o no, pero definitivamente no me funcionaban.

En fin … lo dejo acá escrito por si a alguien le pasa lo mismo, con suerte el tío google pasa por estos lares e indexa las palabras “cambiar” “locales” en fedora, o “reconfigure” “locales” en fedora, o algo que ayude a no perder varias páginas de navegación innecesariamente.

Lo fantástico del uso de estas plantillas es que tienen un reducido (pero muy util) set de funciones e intrucciones que se pueden poner dentro de al plantilla, para darle algo de “inteligencia”.

En el sitio de smarty hay un (muy bien armado) Crash Course, que muestra rápidamente cómo se utilizan.

Lo que más me gustó fue cuando tuve que hacer dos cosas:

1. Internacionalizar la interfaz
2. Cambiar el content-type de la salida de un formulario para que en vez de mostrarlo en HTML, haga que el navegador pida ejecutar otra aplicación para editar el archivo enviado (en este caso, la salida era un archivo CSV que es editable con casi cualquier planilla de cálculo)

Para internacionalizar la interfaz utilicé un hack de un tal André Rabold que extendió la clase de Smarty, para permitir cambiar ciertos strings definidos en un archivo de idioma por su significado en el idioma que se desea mostrar. El hack se llama SmartyMultilanguageSupport, y además de ser muy útil, detecta el idioma con el que esta seteado el navegador, permitiendo que el usuario vea la interfaz en su idioma natal.

Para resolver lo segundo, utilicé algo muy sencillo que es la función header() de PHP, dependiendo el botón que haya apretado el usuario (botones disponibles: “Recuperar Archivo” o “Aceptar” … para pedir que la información requerida en el formulario se muestre en el navegador) defino qué plantilla se va a utilizar y le aplico (o no) la función header().

Por ejemplo:

if (!$csvoutput) {
$smarty->assign(“tpl_name”, “drr.tpl”);
$smarty->display(‘main.tpl’);
} else {
$fdate = strftime(“%Y-%m-%d”,$sdate);
header(“Content-Type: text/csv”);
header(“Content-Disposition: inline; filename=dayreport-$fdate.csv “);
$smarty->display(‘drr-csv.tpl’);
}
Dentro del directorio templates, la plantilla drr-csv.tpl contiene:

##POSITION##,##HOST##,##CONNECTIONS##,##BYTES##
{foreach key=sid item=site from=$sites}
{counter assign=”count”} {$count},{$site.host},{$site.conns},{$site.total_bytes}{/foreach}
En el caso de la misma plantilla pero para HTML, tiene básicamente lo mismo pero todo lleno de tags HTML (obviamente).

De no haber hecho esta interfaz utilizando Smarty creo que todavía estaría escribiendo código y me volvería loco para internacionalizarla y poder cambiar content-type(s) tan fácilmente.

Recomiendo su uso para todo interfaz desarrollada en PHP.

Suerte!

dax///