SmartOS, una introducción

Hoy vamos a probar SmartOS. SmartOS es el sistema operativo de Joyent para aplicaciones cloud. Usa un kernel illumos (fork de OpenSolaris cuando Oracle cerró el proyecto, a nivel técnico comparte mucho con Solaris 10) y usa extensivamente características únicas de Solaris. Además, es el único illumos que tiene KVM, una característica de Linux para permitir virtualización de alto rendimiento.

Descargando SmartOS

Lo primero que tenemos que hacer para probar SmartOS es descargarlo. Lo podemos descargar desde SmartOS.org. Allí encontraremos un enlace a la wiki donde está alojada la descarga. En SmartOS no se habla de versiones, hay versiones nuevas cada 2 semanas y se identifican las descargas con las fechas. La descarga está disponible en varios formatos. El formato recomendado es USB, pero para este post vamos a descargar la imagen de VMware. La descarga no es muy grande (~250 MB) y cuando lo tengamos lo descomprimimos en alguna carpeta. Abrimos VMware Player (o VMware Fusion o VMware Workstation, el que te guste más) y desde allí abrimos la máquina virtual. Nos preguntará que si la hemos movido o copiado. Decimos que la hemos copiado. Ahora tenemos que arrancarla. Antes de nada comprueba que tu ordenador puede ejecutar máquinas virtuales de 64 bits, ya que SmartOS solo es de 64 bits. Una vez lo hemos arrancado nos aparecerá una imagen de GRUB. Seleccionamos la primero opción Live 64-bit (text). Si tienes experiencia instalando sistemas operativos verás que aquí no hay ninguna entrada para instalar. Esto es porque SmartOS no se instala, se configura.

Configurando SmartOS

Ahora nos saldrá un asistente con una serie de preguntas. Respondemos a ellas. En el tema de la conexión yo elegí DHCP y tenía configurada la máquina virtual para conectarse usando NAT. En el apartado de discos destacar que solo podemos seleccionar el último. Si elegimos el primer disco que se nos ofrece estaremos sobreescribiendo la imagen Live de SmartOS y la suiente vez no arrancará. Cuando hayan terminado las preguntas se reiniciará y en GRUB seleccionamos la misma opción. Ahora veremos un curioso login con el símbolo de Joyent. En este momento el sistema ya está configurado para empezar a trabajar dentro de él. Podemos usar SSH o la terminal del ordenador.

Creando la SmartMachine

Ahora vamos a crear una SmartMachine. ¿Qué es una SmartMachine? Es una zona dentro de SmartOS autocontenida que no puede interactuar con el exterior. Es una manera de virtualización que ofrece SmartOS (la otra es KVM). En las SmartMachines será el único lugar donde podremos instalar software (realmente sí se puede instalar fuera de una zone con un instalador manual, pero no es recomendable). Bien, ahora debemos actualizar la lista de imágenes base para las SmartMachines.

imgadm update

Ahora buscamos la que más se adecue a lo que buscamos.

imgadm avail

En mi caso buscaba algo que tuviese ya Node.js e hice esto.

imgadm avail | grep node

Y la descargamos con

imgadm import UUID_DE_LA_IMAGEN

Es importante ver que en SmartOS el uso de los UUID está muy presente como veremos

Ahora que ya tenemos la base vamos a definir nuestra SmartMachine mejor. Así pues creamos un fichero JSON tal que así. Yo lo he decidido guardar en /tmp/node-zone.json

{
"brand" : "joyent",
"dataset_uuid": "NUESTRO_UUID",
"resolvers" : ["8.8.8.8"],
"nics" : [
"nic_tag" : "dhcp",
"ip" : "dhcp"
],
"autoboot" : true,
"ram" : 512
}

Y en hay muchísimas más opciones. Puedes verlas todas en el manual de vmadm

man vmadm

Ahora creamos una nueva zone basada en nuestra imagen base con:

vmadm create -f /tmp/node-zone.json

Ahora podemos encontrar las zonas que estan activas:

zoneadm list -civ

Como vemos hay dos zonas activas, una es la global, en la que estamos trabajando. La otra es la que acabamos de crear y que tiene un nuevo UUID asignado. Mencionar que las zonas las podemos encender y apagar con vmadm también:

vmadm stop UUID && vmadm start UUID

Bien, para entrar a las zonas podemos hacerlo con zlogin

zlogin UUID

y estaremos dentro de una zona. En mi caso se puede comprobar que ya tengo Node.js instalado con

node -v && npm -v

Dentro de la SmartMachine

Ahora podemos instalar paquetes para la zona con pkgin. Por ejemplo digamos que quiero instalar CMake.

pkgin update && pkgin install cmake

Ahora debemos ajustar todo para la aplicación que deseemos probar. Una buena manera para empezar sería clonar un repositorio Git en la carpeta dentro del usuario de la carpeta /home. Luego instalaríamos todo con

npm install

Ahora crearemos el servicio. Creamos un fichero XML parecido a este:

<?xml version="1.0"?>
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">
<service_bundle type="manifest" name="sonzono">
<service name="site/sonzono" type="service" version="1">

<create_default_instance enabled="true"/>

<single_instance/>

<dependency name="network" grouping="require_all" restart_on="refresh" type="service">
<service_fmri value="svc:/milestone/network:default"/>
</dependency>

<dependency name="filesystem" grouping="require_all" restart_on="refresh" type="service">
<service_fmri value="svc:/system/filesystem/local"/>
</dependency>

<method_context working_directory="/home/admin/sonzono">
<method_credential user="admin" group="staff" privileges='basic,net_privaddr'  />
<method_environment>
<envvar name="PATH" value="/home/admin/local/bin:/usr/local/bin:/usr/bin:/usr/sbin:/bin"/>
<envvar name="HOME" value="/home/admin"/>
</method_environment>
</method_context>

<exec_method
type="method"
name="start"
exec="/opt/local/bin/node /home/admin/sonzono/app.js"
timeout_seconds="60"/>

<exec_method
type="method"
name="stop"
exec=":kill"
timeout_seconds="60"/>

<property_group name="startd" type="framework">
<propval name="duration" type="astring" value="child"/>
<propval name="ignore_error" type="astring" value="core,signal"/>
</property_group>

<property_group name="application" type="application">

</property_group>


<stability value="Evolving"/>

<template>
<common_name>
<loctext xml:lang="C">node.js sonzono</loctext>
</common_name>
</template>
</service>
</service_bundle>

Lo guardamos dentro de la configuración con.

svccfg import sonzono.xml

Y ya podemos activar el servicio

svcadm enable sonzono

Podemos ver los logs de todos los servicios en /var/svc/log/

Y con esto creo que ya teneis suficiente información acerca de SmartOS como para ir jugueteando con él. Quiero mencionar que SmartOS es un sistema operativo con muy poco soporte pero que poco a poco se va haciendo más importante.

Referencias

https://github.com/isaacs/joyent-node-on-smart-example

http://docs.instantservers.telefonica.com/display/isc2/Developing+a+Node.js+Application

http://wiki.smartos.org/display/DOC/How+to+create+a+zone+%28+OS+virtualized+machine+%29+in+SmartOS

http://www.machine-unix.com/beginning-with-smartos/

loading...

La mística relación entre el 9N y Firefox

Si habeis leído el título pudiera parecer que he empezado a tomar drogas o alguna sustancia estupefaciente variada. Sin embargo nada más lejos de la realidad, la mística relación entre el 9N (la consulta catalana) y Firefox se abrió ante mis ojos cuando vi esta valoración de mi complemento en el sitio de complementos de Firefox.

9N-Firefox

He intentado por tres golpes instalar este complemento, pero, como ya es fuerza normal, si no eres de MADRID (“Villa y Corte”) no funciona. Puedes entrar a “Opciones”, pero el identificador de municipio NO ADMITE un primer número que sea el “0”. Por lo tanto, Barcelona, que es id 08019 , no funciona. SIEMPRE IGUAL. 9N. (Traducción hecha por Apertium)

Os pongo en situación. El comentario en cuestión se refiere al complemento El Tiempo en España y la valoración anterior (solo había una antes) le daba 5 estrellas sobre 5. ¿Qué ha pasado? Resulta que cuando hice el complemento (es bastante viejo) use el control numérico que ofrece XUL y almacené la preferencia como un entero. Esto funcionaba con todos los códigos que había probado pero fallaba con los que empezaban con 0. ¿Por qué? La respuesta es muy sencilla y es que al estar en un control numérico al introducir un número a la izquierda este se nos quita tan rápidamente como introdujamos la siguiente cifra. El código de Barcelona empieza por 0 y claro, en esa ciudad no funcionaba el complemento. En eso le doy la razón al autor de la valoración. Pero de ahí a relacionar el que no funcione con un compot contra los catalanes por parte de Madrid me parece excesivo y un sin sentido. ¿Cómo alguien puede relacionar un bug con un complot político? (encima de un complemento que es open source)

Lumtumo ya es open source

Si miramos la fecha del calendario descubriremos que cuando he publicado este artículo era el día 25 de septiembre. Como todos los que me conocen saben normalmente publico siempre algo el día 25 de septiembre, ya que es un manera de celebrar mi cumpleaños. Durante un tiempo publicaba Azpazeta, este año sin embargo voy a publicar Lumtumo. Básicamente comentar que Azpazeta no está en desarrollo y sí otro tipo de juegos como Lumtumo que según puedo observar en BitBucket el último commit es de abril de este año. Realmente Lumtumo ya había sido publicado y se podía adquirir previo pago. Sin embargo, a partir de ahora Lumtumo tendrá una licencia open-source auténtica. Concretamente va a tener la GNU GPLv2 y seguirá alojado en BitBucket, aunque ahora el repositorio será abierto.

Lumtumo

En Lumtumo tenemos que ir destruyendo las naves enemigos que se opongan a nosotros. Para ellos podremos lanzar misiles y tendremos un tiempo para acabar con todos antes de que lleguen refuerzos. ¿Serás capaz de mantener a las naves alienígenas fuera de nuestro planeta?

Así pues ya puedes descargar el código fuente original: http://bitbucket.org/AdrianArroyoCalle/lumtumo

La Odisea de una aplicación comercial hecha en Ogre y CEGUI

Últimamente he estado concentrado en una tarea que considero extenuante, por la falta de información, y por la abundancia de respuestas que no aportan nada al caso. El dilema en cuestión es la distribución de binarios en Linux de una aplicación privativa, concretamente un juego hecho en OGRE y CEGUI. Y la verdad es que la odisea es larga. Así que he decidido comparar todas las opciones, sus pros y sus contras.

OGRE

Opciones

Las opciones que he valorado para comparar son:

  • Paquetería nativa DEB, RPM y TAR.XZ
  • Distribuir un TAR.GZ binario
  • Estatificar (palabro inventado) el binario
  • Paquetería multi-distro, Autopackage, Listaller

Paquetería nativa DEB, RPM y TAR.XZ

Esta opción, es a priori la más conveniente. El usuario dispondrá de un bonito paquete nativo (que se podrá actualizar) y se le gestionarán las dependencias, por ello ahorrará espacio en disco. Además tendrá una integración real con el sistema, lo podrá desinstalar desde donde acostumbra a desinstalar y el juego le aparecerá en los menús. Sin embargo los problemas salen enseguida, por una parte tienes que centrarte en ofrecer varios sistemas de distribución. Por otra parte, los paquetes nativos suelen no llevarse muy bien con otros paquetes de otras arquitecturas, ya que en algunos casos se nos pedirá instalar prácticamente el sistema de 32 bits encima del de 64, cuando realmente no es necesario. Además el tema de las dependencias es un arma de doble filo, pues en el caso de OGRE y CEGUI, o no hay, o están desfasadas. Así pues nuestro paquete puede quedarse inservible pronto. Y una peculiaridad de OGRE, resulta que tenemos que definir en plugins.cfg la localización de los plugins que usemos (normalmente con definir el de OpenGL ya sirve), pero la localización de esos plugins puede estar dispersa entre sistemas y arquitecturas. Con lo que deberíamos modificar el fichero plugins.cfg en cada sistema y arquitectura.

Distribuir un TAR.GZ binario

Visto lo anterior, parece ser más cómodo distribuir un TAR.GZ binario. Muchas aplicaciones como Oracle Java o Mozilla Firefox son distribuidas desde el sitio oficial usando este sistema. Sin embargo, y aunque pueda parecer una buena idea, tiene algún que otro inconveniente. En primer lugar debemos intentar usar librerías estáticas. Si las librerías que usamos tienen esa opción, correcto. Puede que esas librerías dependan en otras que no puedan ser estáticas, y aunque lo fueran, añadirían más carga al ejecutable y complejidad en la compilación. Si dependemos de librerías compartidas las podemos poner en una carpeta que tengamos dentro del TAR.GZ y usar RPATH con $ORIGIN o LD\_LIBRARY\_PATH. El caso es que hay ciertas herramientas que nos pueden servir para ello. Por ejemplo cpld nos puede servir para copiar todas las dependencias. El problema es que el proceso no puede ser automatizado completamente ya que el script no puede diferenciar una dependencia base de Linux de una que realmente debamos distribuir. Así que despúes de usar la herramienta nos tocará volver a revisar los ficheros que ha copiado ya que habrá copiado libc, libm, libpthread, libX11 y otras que posiblemente no necesitemos. Pero si no las copiamos podríamos tener problemas en sistemas de 64 bits. Una solución efectiva consiste en hacer un pequeño script que cargue las librerías según el sistema en el que estemos, habiendo usado el script en un sistema de 32 bits y en otro de 64 bits. Esto puede parecer razonable, pero tanto OGRE como CEGUI usan una arquitectura basada en plugins. Estos plugins no pueden ser analizados por ninguna herramienta y deberemos saber manualmente que plugins tendremos que pasar a  el comprimido. Por supuesto debemos separar las dos arquitecturas. En OGRE es fácil pasar los plugins ya que por defecto se usa el fichero plugins.cfg para leer los plugins, pero CEGUI no tiene esa característica (o yo no la he encontrado). Sin embargo es una alternativa muy sólida.

Estatificar

Una opción que encontré mientras buscaba una solución se puede llamarla como estatificar. Es un método poco común que coge las dependencias compartidas y las empaqueta en un único binario. No se debe confundir con compilación estática ya que estatificar requiere un binario ya compilado con dependencias. Únicamente hay dos aplicaciones que hacen esta función, y las dos son del mismo creador, aunque difieren en el funcionamiento de base. Por un lado Statifier, open source y gratuita, trabaja a un modo más rudimentario; por otro lado, Magic Ermine, trabaja con un sistema más perfeccionado, es de pago pero tiene una demo gratuita para probar. Los resultados no eran muy buenos, Statifier modificó el binario de manera que ya no arrancaba, por otro lado Magic Ermine funcionaba correctamente, pero el plugin de OpenGL de OGRE usa libGL.so, y como es cargada dinámicamente, Magic Ermine no sabe que tenía que empaquetarla y como consecuencia falla con un bonito error.

Paquetería multidistro

Autopackage, Listaller, 0install, … Prometen mucho pero no funcionan bien. Autopackage ha sido descontinuado en favor de Listaller, Listaller se tiene que integrar con AppStream y PackageKit, pero esos mismos componentes no están finalizados, Listaller falla más que una escopeta de feria en la práctica y la documentación es pésima. Realmente espero que mejoren ya que prometen mucho, pero no se cuando será realmente usable. 0install trabaja de otra manera y al menos en mi caso, fallaba y no podía siquiera empaquetar una simple aplicación. Esta opción quizá en otro momento, pero ahora no.

Conclusión

Hemos visto 4 opciones. Dos de ellas no funcionaban bien en la práctica (estatificar y la paquetería multidistro), las otras dos eran tediosas, pero si se estudia al detalle puede funcionar bien. Así pues podemos elegir entre la paquetería nativa y el TAR.GZ binario con scripts de dependencias. Así pues cada cuál elija la que más le guste.