OpenShift Express es una plataforma (PaaS) gratuita para el despliegue de aplicaciones en la nube proporcionada por RedHat. En ella podremos desplegar aplicaciones Java, Perl, PHP, Python y Ruby.  Además, permite la instalación (también gratuita) de un servidor de bases de datos como MySQL, Postgres o MongoDB.  El procedimiento es bastante simple: al abrir una cuenta, OpenShift te generará una URL única para tu aplicación y un repositorio git asociado.  Tus desarrollos se guardarán en git de tal forma que al hacer git push , automáticamente, aparte de subir tus cambios al repositorio remoto, estarás dando una orden de despliegue de la aplicación (internamente lo hace a través de hooks o ejecución de scripts ante eventos como un git push)

Dejo esbozados aquí los pasos necesarios para crear una cuenta, desplegar tu propia BBDD MySQL y subir un pequeño script PHP que hace uso de dicha base de datos:

1) Darte de alta en OpenShift Express (existe otra modalidad de pago, llamada Openshift Flex, para usuarios con necesidades más avanzadas)

2) Entrar en el panel de control de Express

3) Crear un namespace (la URL de tus aplicaciones siempre serán del tipo  nombreaplicacion-namespace.rhcloud.com). En la imagen superior he creado un namespace = babelium

4) Crear una aplicación de tipo Java, PHP, Python, Ruby o Perl. En mi ejemplo el nombre de la aplicación es “demo” (tras mucho estrujarme los sesos ;-) y se trata de una aplicación PHP.

Como puede verse en la imagen, tras el paso 4 se creará un repo git en la dirección ssh://xxxxxx@demo-babelium.rhcloud.com/~/git/demo.git/

5) Opcional: para poder acceder por ssh a nuestra instancia (sí! tenemos acceso ssh gratuito!) subimos la parte pública de nuestra clave RSA ( normalmente la tendrás situada en  ~/.ssh/rsa_id.pub )

6) Clonamos el repo git del paso 4

$ cd /opt
$ git clone ssh://xxxxxx@demo-babelium.rhcloud.com/~/git/demo.git
$ ls -al demo
-rw-r--r--  1 juanan juanan      0 2012-01-25 17:43 deplist.txt
drwxr-xr-x  8 juanan juanan   4096 2012-01-25 17:43 .git
drwxr-xr-x  2 juanan juanan   4096 2012-01-25 17:43 libs
drwxr-xr-x  2 juanan juanan   4096 2012-01-25 17:43 misc
drwxr-xr-x  4 juanan juanan   4096 2012-01-25 17:43 .openshift
drwxr-xr-x  2 juanan juanan   4096 2012-01-25 17:43 php
-rw-r--r--  1 juanan juanan   1315 2012-01-25 17:43 README

Bien… ¿me sigues? Ok, los pasos que he comentado hasta ahora (crear namespace, nombre de aplicación, asociar la aplicación a un entorno PHP, etc. se puede hacer desde la línea de comandos. Para ello, debes instalar las utilidades rhc (RedHat Cloud) que son scripts en Ruby (gemas) para control remoto de las aplicaciones en Openshift. Desde Ubuntu basta con que hagas:

sudo gem install rhc
PATH=$PATH:/usr/lib/ruby/gems/1.9.2/gems/rhc-0.84.15/bin/

Ojo con el path, igual en tu máquina las gemas rhc no se instalan exactamente en la misma ruta, ¡échale un vistazo antes!

¿Por dónde íbamos? Ah! sí, por el paso 7 :-)

7) Bien, vamos a instalar soporte MySQL en nuestro entorno. Para ello, ahora sí desde la línea de comandos, porque el panel de control por ahora no ofrece la opción de hacerlo vía point&click:

/opt/demo$ rhc-ctl-app -a "demo" -e add-mysql-5.1 -l usuario@dominio.com

RESULT: Mysql 5.1 database added.  
Please make note of these credentials:    
Root User: xxxxxxxx  
Root Password: xxxxxxxxxxx   
Database Name: demo 
Connection URL: mysql://127.1.48.1:3306/ 
You can manage your new Mysql database by also embedding phpmyadmin-3.4.

Olé! MySQL 5.1 instalado por la patilla… y ¿qué es eso de que incruste phpmyadmin? No me digas que también lo tengo por el mismo precio! Pues así es amigos… :-) De hecho, tengo varios cartuchos (cartridges le llaman en RHC) disponibles:

$ rhc-ctl-app -a "demo" -L
List of supported embedded cartridges:
 
Obtaining list of cartridges (please excuse the delay)...
postgresql-8.4, metrics-0.1, mysql-5.1, jenkins-client-1.4, 10gen-mms-agent-0.1, phpmyadmin-3.4, rockmongo-1.1, mongodb-2.0

Olé y olé… jenkins… mmmmmhhh… eso lo dejo para otro día :-) Por ahora vamos a instalar phpmyadmin.

$ rhc-ctl-app -a "demo" -e add-phpmyadmin-3.4 -l usuario@dominio.com

Acabamos de enganchar a nuestra aplicación demo un phpmyadmin-3.4 . Para los que se acuerden de artículos anteriores de DiarioLinux, esa sintaxis le sonará al entorno juju de Ubuntu. El login y pass será el mismo que te han dado para MySQL. La URL de acceso también la tendrás al ejecutar el comando anterior.

Nota: teniendo phpMyAdmin, crear las tablas en la BBDD es trivial. Pero existen otras formas de hacerlo (sin usar phpMyAdmin). Una de ellas en entrar por ssh a tu instancia y crear las tablas desde la línea de comandos mysql, pero otra forma más elegante es usar un hook de git. En concreto, en tu repo tendrás un directorio .openshift, y dentro del mismo un subdirectorio llamado action_hooks. Lo que hay ahí son scripts que se ejecutan en distintos momentos tras hacer un git push. El script deploy es el más adecuado para generar tus tablas y poblar con tuplas las mismas. Edita ese script (/opt/demo/.openshift/action_hooks) así (gracias a schabell.org por enseñarnos a hacerlo):

#!/bin/bash
# This deploy hook gets executed after dependencies are resolved and the
# build hook has been run but before the application has been started back
# up again.  This script gets executed directly, so it could be python, php,
# ruby, etc.
set -e
 
if [ -z $OPENSHIFT_DB_HOST ]
then
    echo 1>&2
    echo "Could not find mysql database.  Please run:" 1>&2
    echo "rhc-ctl-app -a $OPENSHIFT_APP_NAME -e add-mysql-5.1" 1>&2
    echo "then make a sample commit (add whitespace somewhere) and re-push" 1>&2
    echo 1>&2
    exit 5
fi
 
# check for database.
if ! /usr/bin/mysql -u "$OPENSHIFT_DB_USERNAME" --password="$OPENSHIFT_DB_PASSWORD" -h "$OPENSHIFT_DB_HOST" -e "show tables;" $OPENSHIFT_APP_NAME > /dev/null
then
    echo 1>&2
    echo "Could not find mysql database. " 1>&2
    echo "Creating database for application named: $OPENSHIFT_APP_NAME." 1 >&2
    /usr/bin/mysqladmin -u "$OPENSHIFT_DB_USERNAME" --password="$OPENSHIFT_DB_PASSWORD" -h "$OPENSHIFT_DB_HOST" create "$OPENSHIFT_APP_NAME"
fi
 
# Confirm database exists, if not create it
if ! /usr/bin/mysql -u "$OPENSHIFT_DB_USERNAME" --password="$OPENSHIFT_DB_PASSWORD" -h "$OPENSHIFT_DB_HOST" -e "select * from guesses;;" "$OPENSHIFT_APP_NAME" > /dev/null
then
    echo
    echo "Schema not found!  Importing schema from .openshift/action_hooks/baby.sql"
    echo
    /usr/bin/mysql -u "$OPENSHIFT_DB_USERNAME" --password="$OPENSHIFT_DB_PASSWORD" -h "$OPENSHIFT_DB_HOST" "$OPENSHIFT_APP_NAME" < "$OPENSHIFT_REPO_DIR/.openshift/action_hooks/baby.sql"
    echo
    echo "done."
else
    echo "Database found, skipping import."
fi

Como ves existen algunas variables de entorno predefinidas: $OPENSHIFT_DB_HOST (dirección del host que alberga tu MySQL), $OPENSHIFT_DB_NAME (nombre de la base de datos de tu aplicación), etc. Como digo son variables predefinidas, ya tienen el valor correcto asignado sin que tú hagas nada. El script bash anterior, lo que hace es comprobar que tienes mysql instalado en OpenShift (y en caso de no tenerlo lo instala), que tienes la BD instalada (si no, la crea también) y que la has cargado con tuplas (y si no, la carga, leyendo del dump baby.sql situado en el mismo directorio que el script). El dump baby.sql lo tienes que crear previamente, claro, con instrucciones SQL de creación de tablas e inserción de tuplas. Por ejemplo:

USE babygame;

DROP TABLE IF EXISTS guesses;
CREATE TABLE guesses
(
	timestamp timestamp,
	name varchar(50) NOT NULL,
	email varchar(50) NOT NULL,
	birthdate timestamp,
	birthsex varchar(4) NOT NULL,
	babyname varchar(100),
	PRIMARY KEY (timestamp, name)
);

Tus scripts en PHP serán como siempre han sido, no hay ningún cambio salvo las variables de entorno predefinidas que en un entorno php “normal” no existen y en Openshift sí. Por tanto, en la carpeta /opt/demo/php podrías crear un script php para conectar con tu BBDD:

define( "DB_SERVER",    $_ENV['OPENSHIFT_DB_HOST'] );
define( "DB_USER",      $_ENV['OPENSHIFT_DB_USERNAME'] );	
define( "DB_PASSWORD",  $_ENV['OPENSHIFT_DB_PASSWORD'] );	
define( "DB_DATABASE",  "demo" );	
$connect = mysql_connect( DB_SERVER, DB_USER, DB_PASSWORD );
@mysql_select_db( DB_DATABASE, $connect ) or die( "Unable to select database");
// etc...

Ahora, desde la línea de comandos lanzas un “git push” y verás como el servidor despliega tu aplicación, ejecuta el script de creación de tablas y tuplas mysql (creándolas en caso necesario) y te deja la URL lista para ser usada: http://demo-babelium.rhcloud.com/

Espero que no os guste demasiado este post, no vaya a ser que OpenShift se sature ;-)
[Nota: ha sido un post largo y con aplicación práctica inmediata, para compensar el mes largo sin actualizaciones ;-) ]

Breve noticia aprovechando que el 28 y 29 será el bug hunting day para cazar fallos en la beta de LibreOffice 3.5, he revisado por encima las novedades y me ha sorprendido que ya hayan integrado el soporte de importación de ficheros VSD (MS Visio) en LibreOffice Draw. Gran trabajo de LA hacker Eilidh McAdam’s, desarrollado dentro de la iniciativa Google Summer of Code 2011.

PD: que paséis un buen solsticio de invierno ;-)

Tercera ley de Clarke: “Cualquier tecnología lo suficientemente avanzada es indistinguible de la magia”. Eso es lo que me pasó por la cabeza la primera vez que ví éste vídeo sobre JuJu:

En 5 minutos y un puñado de comandos, JuJu permite ensamblar, desplegar y escalar un sistema MediaWiki de dos unidades, con la capa de persistencia en un cluster MySQL, dos instancias memcached para acelerar las peticiones y HAProxy como balanceador de carga. Y eso es sólo un ejemplo… Podríamos definir JuJu (antes conocido como Ensemble) como una mezcla entre gestor de paquetes para lanzar aplicaciones en la nube y un sistema de orquestación de servicios (una especie de domador con látigo que pone a cada servicio en su sitio y los junta/ensambla con otros animales/servicios ;-) Este software ha sido desarollado por Canonical bajo licencia AGPL y es un paso más en los movimientos de Canonical por situarse en el territorio cloud.

Para que JuJu funcione, hace uso de “encantamientos” o charms, que son simples recetas en un lenguaje de scripting que permiten instalar, configurar y enlazar servicios. Hay ya una bonita colección de charms disponibles, pero todavía quedan muchos por hacer. Usando estos charms, podemos lanzar un WordPress en la nube con MySQL como Base de Datos, con 4 comandos:

$ juju deploy –repository=. wordpress myblog
$ juju deploy –repository=. mysql mydb
$ juju add-relation mydb:db myblog
$ juju expose wordpress

Bonito, ¿eh? Pues ahora piensa que con el comando add-unit puedes lanzar otra unidad WordPress y comenzar el escalado horizontal a partir de comandos juju, como se muestra en el vídeo :-) ¿Magia?

Te recomiendo éste post en castellano con un ejemplo más elaborado del uso de JuJu, o si estás interesado, esta presentación en PDF para que revises el funcionamiento interno de esta tecnología.

Seguimos comentando algunas de las charlas de la SLUN 2011 que más me llaman la atención. Unai Gangoiti nos hablará sobre FOG, una herramienta de clonado de equipos bajo licencia libre GPL (no he encontrado la versión exacta). Hasta ahora en la UPV/EHU se usaba Rembo, pero al parecer daba problemas con las últimas versiones de ext3/ext4 y las capacidades de disco cada vez más altas. Cuando tienes que desplegar una solución para el clonado de miles de equipos empiezas a adquirir experiencia “de verdad”, así que será un placer escuchar lo que Unai nos cuente.

Otra ponencia inusual es la que nos contará Alberto Alonso, bajo el título “Experiencia en el desarrollo de un proyecto libre (Multi Theft Auto)”. No conocía el proyecto hasta hacer un par de días, pero cuando me lo contaron me sorprendió: se trata de una modificación del juego “Grand Theft Auto : San Andreas”, escrita en C++ y con licencia GPL, que añade soporte multijugador a un juego que originalmente no lo tenía. La gracia del asunto es que la modificación se ha hecho a partir del binario del juego, es decir, sin el código fuente original. O dicho de otra forma, por ingeniería inversa. Esta técnica la había visto en el mundo de la seguridad informática (cracks, parches, análisis de cambios en patchs binarios, análisis forense en imágenes infectadas…), incluso para modificar una aplicación (es el caso de la agenda/PIM Ecco Pro, una aplicación de 1993! con miles de usuarios que siguen usándola gracias a hacks como éste), pero nunca para modificar un juego al nivel de MTA.

Así que quieres integrar BigBlueButton en Moodle. La gente de Blindside Networks ha desarrollado un módulo de BBB para Moodle (módulo de tipo activity) que permite planificar videoconferencias BBB a través de Moodle (2.0 y 2.1). Con más detalle, ésto es lo que permite:

• crear mensajes de bienvenida que aparecen en la ventana de chat cuando los usuarios entran en la videoconferencia BBB

• especificar fechas de apertura/cierre de sala de videoconferencia (fechas que aparecerán en el calendario Moodle)
• lanzar BBB en su propia ventana
• Grabación y playback de las clases que emitas por videoconferencia (esto requiere una versión >=BigBlueButton 0.8-beta )
• Gestionar las clases grabadas (publicar & (des)publicar y borrar)

Hay un vídeo que explica paso a paso la instalación:

Pero es bien sencilla: se descomprime el .zip del módulo en /var/www/moodle/ y veremos que dentro de mod/ creará dos nuevas carpetas, bigbluebuttonbn y recordingsbn. Al entrar como administrador en Moodle, el plugin se activará y nos pedirá que configuremos dos variables: una apuntando a la dirección http del servidor con BBB. Otra donde nos pedirá que introduzcamos el valor SALT de nuestro server BBB. Ese valor (único para cada server BBB), se obtiene así:

(en el servidor BBB)

$ cat  /var/lib/tomcat6/webapps/bigbluebutton/WEB-INF/classes/bigbluebutton.properties | grep -i salt 
# Salt which is used by 3rd-party apps to authenticate api calls 
securitySalt=XXXXXXXXXXXXXXXXXXXXXXXXX

Una vez configuradas esas variables, ya podrás crear videoconferencias BBB desde Moodle y albergar las grabaciones de tus clases/tutorías (tal y como se ve en la imagen de la izquierda)

¡Ojo! Las grabaciones NO albergarán lo que ocurra con las webcam ni lo que veas al compartir escritorio entre usuarios (sólo graba, de serie, las “diapositivas” que vayas pasando en la pizarra, el chat y la voz de los participantes). “¿Y si quiero grabar también la webcam y la compartición de escritorio?” Ah… entonces tendrás que echar mano de Matterhorn e integrarlo con BBB, tal y como comentaré en el próximo post… ¿cómo? ¿que quieres empezar ya a salsear? ooook… puedes empezar por aquí. IMPORTANTE: cuando en las instrucciones de Matterhorn te pide que instales Apache Felix, no descargues la última estable (la 4.x) porque NO te funcionará. Instala la 3.2.2, que puedes encontrar en este mirror http://ftp.udc.es/apache-dist/felix/.

En la home de BigBlueButton (BBB) resumen así el objetivo principal de la aplicación: “BBB permite a universidades e instituciones educativas ofrecer experiencias de aprendizaje de alta calidad a estudiantes remotos”. Es en la última palabra donde reside el quid de la cuestión. Efectivamente, BBB permite plantear reuniones online a través del navegador, con soporte de compartición de webcam, micro, pizarra digital, escritorio y chat. La última versión 0.8 permite también grabar la sesión (con algunos “peros” que luego comentaré). BBB es software libre, con la parte cliente desarrollada en ActionScript (usando el framework open source Flex SDK) y en la parte servidor un numeroso conjunto de módulos, bibliotecas y servidores de código abierto: Red5, Asterisk o FreeSWITCH, ActiveMQ, Tomcat, OpenOffice.org, MySQL…

Ayer mismo BBB anunciaba que entraba a formar parte de MozillaFWD, el programa de la fundación Mozilla para la innovación abierta, que tiene como objetivo crear una comunidad de proyectos opensource innovadores para ayudar a extender la web. Bonita frase que viene a traducirse en infraestructura, soporte y publicidad a través de la fundación Mozilla (suena muy parecido a la fundación Apache)

Realmente veo una fuerte competencia entre dos grandes: OpenMeetings y BBB. Los más veteranos recordaréis que ya hablamos sobre OpenMeetings en DiarioLinux, ahora le toca el turno a BBB.

La instalación de BBB es un poco tiquismiquis en los requerimientos: necesita un Ubuntu 10.04 de 32 o 64 bits. ¿Se puede instalar en algo más moderno, digamos Ubuntu 11.04 o 11.10? Bueno, yo lo he intentado y me surgían tantas incompatibilidades (empezando por la versión de Ruby que pide) que desistí y lo instalé directametne en la 10.04. Ahí la instalación ha ido bien, siguiendo las instrucciones recto hasta el final :-) El servidor requiere 2 GB de memoria RAM y acceso root. Los 5G de espacio libre en disco tampoco son moco de pavo.

Ah! y el puerto 80 (sí, ese que usas en tu Apache local) tiene que estar disponible. ¿Por qué? Porque BBB usa en el backend el servidor proxy nginx. Éste enruta las peticiones del cliente a dos módulos: bbb-web (las peticiones HTTP) o bbb-aps (las peticiones RTMP). La arquitectura interna del servidor BBB está documentada y ahí puede verse todo el “sarao” que se monta :-) Más sobre esto en el siguiente post, pero puedes ir leyendo aquí una serie de 4 posts en inglés sobre los fundamentos de la arquitectura BBB.

En las pruebas para esta serie de artículos he usado una instancia Amazon EC2 con un Ubuntu 10.04 pelado y a partir de ahí he ido siguiendo las instrucciones de instalación sin problemas (salvo éste bien documentado). Realmente en 15 minutos puedes tener la máquina online y funcionando (a falta de pulir algunos detalles).

La calidad de la videoconferencia es buena, aunque el audio viene con algo de retardo en comparación a OpenMeetings. Por otro lado, el soporte de grabación en BBB es recientito (estamos en la 0.8 beta 3 y empezó en la 0.8!). Además, de serie sólo graba lo que hayas emitido por la pizarra compartida, tu voz y el chat de texto. Eso sí, emite a través de HTML5 (sin necesidad de plugin Flash), gracias a la biblioteca popcorn.js. Como digo, echo en falta la posibilidad de ver las webcam de los usuarios en la grabación, y también hecho en falta la posibilidad de descargar en formato .avi el vídeo (algo que OpenMeetings sí ofrece). ¡Ojo! BBB desde la versión 0.8 (septiembre 2011!) también puede grabar las webcams de los usuarios, incluso la ventana de compartición de escritorio remoto, siempre y cuando uses por detrás Matterhorn. También he instalado Matterhorn en otra máquina (más complejo de instalar que BBB) y comentaré mi experiencia en otro post, que éste está quedando largo.

BBB hace uso de OpenOffice.org y SWFTools para convertir cualquier documento .doc, .odt, .pdf o gráficos (.jpg, .png, .gif…) a formato Flash y compartirlos luego a través de la pizarra digital. Ideal para mostrar una presentación a un conjunto de alumnos. La presentación subida permite ser “garabateada” con distintos lápices de colores que ofrece la pizarra. Una cosa que he echado en falta (respecto a OpenMeetings) es la opción de mostrar vídeo dentro de la pizarra.

Dos cosas más antes de cerrar por hoy: BBB es multi-idioma (incluyendo el euskera :-) y tiene un plugin para ser integrado con Moodle. Mañana más, ahora toca dormir un rato ;-)

La Jornada Software Libre en la Universidad 2011 está a 15 días vista. El aforo de la sala es limitado, así que si estás pensando en acudir, más vale que te apuntes cuanto antes. Avisados quedáis :-)
¿Por qué creo que merece la pena este evento? Primero, porque es el lugar donde se reunirá todo aquel interesado por el software libre de Euskadi. No sólo universitarios, sino también gente del mundo empresarial (como puede verse en el programa de ponencias). Segundo, porque este año las ponencias previstas son magníficas, en serio, no es una frase hecha (Full Disclaimer: espero que la de un servidor cumpla con las expectativas ;-). Y tercero, por el “networking” social organizado: por 10€ podremos disfrutar de un lunch en el propio evento y las sesiones de café: a los alumnos que aún están pensando si acudir o no, les diría algo que he oído por Twitter: “si quieres buscar trabajo, usa webs de trabajo online. Si quieres encontrarlo, usa tu agenda de contactos”. Y los contactos hay que ir a buscarlos ;-)

Me gustaría escribir en distintos posts sobre algunas de las ponencias que disfrutaremos en la SLUN2011 (por eso he puesto el I en el título del post… espero tener tiempo para al menos un II !) La primera ponencia lleva por título: “Auto grabación de clases, Proyecto europeo OpenCast/Matterhorn“, por Vicente Goyanes, de la Universidad de Vigo. Este proyecto de software abierto tiene como uno de sus objetivos la grabación automatizada de clases, gestión y distribución de vídeo por Internet. Puedes ver un artículo en castellano en el boletín de RedIris.

Recientemente Matterhorn se alió con la gente de BigBlueButton (BBB es otro proyecto de software libre que permite realizar videoconferencias soft. con compartición de pizarra, chat, grabación de escritorio, entre otras cosas) para conseguir que las reuniones online que se hagan en BBB (con audio, vídeo, diapositivas, etc.) se graben y se publiquen en Matterhorn para su posterior visualización.

Finalmente, el ponente tiene también experiencia empresarial, dado que ha fundado una empresa spin-off de la U. de Vigo (Teltek) para dar soporte comercial a los clientes interesados en implantar Matterhorn.

Como veis, ya sólo por la primera ponencia, merece la pena participar en SLUN :-) Y aún quedan todas las demás, ¡igual o más interesantes! Anímate a participar.

Guardo correo en GMail desde el 14 de Junio de 2004. Sabiendo que Gmail salió al mercado el 15 de Abril de ese mismo año… se entiende que esté a punto de llenar el buzón, a pesar de tener más de 7GB de espacio (y subiendo, poquito a poquito)

Hace tiempo también que tomé la decisión de hacer un backup vía POP3 del correo de GMail (cuando ví que a algunos usuarios les bloqueaban la cuenta por uso indebido – realmente por usar cosas como GMailFS)

Sin embargo, el problema ahora es que quiero liberar espacio para no saturar esos 7 GB. Además, estoy seguro de que tengo muchos mensajes con adjuntos enormes que podría borrar. ¿Pero cómo ordenar los mensajes en función de lo que ocupan? A pesar de que Google ES realmente una empresa que surgió y sigue brillando por la excelencia de su buscador, en lo que se refiere a la búsqueda de mensajes en GMail, brilla por su ausencia la opción de buscar y ordenar mensajes por tamaño :-\

Pero hay una solución: basta con activar el soporte IMAP
. A partir de ahí, hay que crear una nueva cuenta IMAP en Thunderbird (lo pongo como ejemplo, dado que este cliente tiene un asistente para autoconfigurar una cuenta IMAP en GMail)

Al abrir las cabeceras de los mensajes (sólo se descargan las cabeceras hasta que pulsas en el detalle de cualquiera de ellos), podrás seleccionar un nuevo campo a visualizar: “Size” o tamaño.

Fin del problema. Ya puedes ordenar tus mensajes por esa columna (Size) y descubrir dónde estás malgastando MBs en tu cuenta GMail.

Actualización: una vez eliminados los mensajes pesados desde el cliente IMAP, recuerda que GMail guarda temporalmente todo lo borrado en “Trash”. Si quieres ver cómo desciende tu cuota de utilización de espacio, entra en Trash, selecciona todos los mensajes y bórralos definitivamente.

Upstart es el sistema que muchas distribuciones Linux utilizan para gestionar las tareas a realizar en el arranque. Para los más veteranos del lugar, Upstart tiene como objetivo reemplazar los daemons tradicionales de SystemV que gestionan las tareas a ejecutar en el arranque, la parada y puesta en marcha de servicios.

Upstart busca sustituir al daemon init, el primer proceso que se lanza en Linux tras cargar el kernel y que se encarga de arrancar el resto. init es el proceso padre de todos aquellos procesos que hayan perdido a su padre (es el padre de todos los daemons). El comando pstree permite ver esto gráficamente.

Por qué Upstart
init es un proceso síncrono que bloquea la ejecución de tareas hasta terminar con la actual. Las tareas que init debe ejecutar han de ser definidas con antelación y éstas sólo se ejecutan cuando init cambia su estado (generalmente porque la máquina se ha encendido, se está apagando o se está reiniciando). El daemon init decide qué tareas ejecutar al cambiar su estado (RUNLEVEL) mirando en el directorio /etc/rcX.d/, donde X indica el RUNLEVEL actual.
Este hecho impide que init gestione correctamente otras tareas que son necesarias ejecutar NO al cambiar de RUNLEVEL sino cuando se generan ciertos eventos, como por ejemplo, las siguientes:

* se quiere ejecutar un backup del servidor de la base de datos en cuanto se detecte que dicho servicio se ha parado
* se conecta en caliente un dispositivo USB o disco externo
* se quiere realizar un sondeo de los dispositivos de almacenamiento disponibles sin que se bloquee el sistema (especialmente cuando el disco a sondear está en estado stand-by y se enciende al detectar el sondeo)
* se quiere ejecutar un script cada hora pero sólo si la ejecución anterior ya ha terminado

Hay más ejemplos y casos de uso en la discusión para reemplazar init en Ubuntu.

El modelo basado en eventos de Upstart permite responder de forma asíncrona a eventos como los mencionados, en cuanto éstos ocurren. La asincronía permite poder ejecutar en paralelo distintas tareas con el objetivo de minimizar el tiempo de arranque.

Evolución de Upstart
Desde su introducción en Ubuntu 6.10 (2006) Upstart ha ido paulatinamente reemplazando a SystemV (la migración por pasos siempre fue un objetivo). Los scripts de arranque y parada de servicios han sido migrados, si no todos, si una buena parte. El fichero /etc/inittab que indicaba al proceso init qué RUNLEVEL arrancar por defecto y cuáles eran los scripts rc que había que arrancar en cada nivel, ha sido eliminado.

En las primeras versiones de Upstart, la definición de jobs (trabajos a realizar cuando se detecten ciertos eventos) se hacía en el directorio /etc/event.d. En Karmic Koala (9.10), Canonical decidió cambiar esa localización a /etc/init.

En Agosto de 2011, Red Hat decidió también adoptar Upstart, dejando de lado SystemV init.

Trabajos, eventos, tareas y servicios
Los trabajos (o jobs, en terminología Upstart) pueden ser tareas o servicios. Las tareas son simples scripts que se ejecutan y terminan su trabajo en un breve lapso de tiempo. Los servicios son procesos que se quedan en ejecución (daemons). Para que un job pueda ponerse en marcha o pararse, deben darse ciertas condiciones. Normalmente estas condiciones vienen dadas por la detección o no de ciertos eventos. Por poner un ejemplo gráfico, veamos el job /etc/init/mysql.conf que permite lanzar o parar mysql en función de la detección de ciertos eventos.

# MySQL Service
 
description     "MySQL Server"
author          "Mario Limonciello <superm1@ubuntu.com>"
 
start on (net-device-up
          and local-filesystems
	  and runlevel [2345])
stop on runlevel [016]
 
[...]
exec /usr/sbin/mysqld
[...]

En resumidas cuentas, el job mysql viene a decir que el daemon mysqld se pondrá en marcha cuando se detecte red (net-device-up), el sistema de ficheros haya sido montado (local-filesystems) y el nivel de ejecución sea uno entre 2 y 5 (Ubuntu en modo gráfico arranca por defecto en el nivel 2). Si se detecta un evento runlevel 0 ó 1 ó 6 entonces el daemon mysqld se parará.

En Ubuntu Natty, Upstart introdujo el comando initctl2dot, que permite ver gráficamente estas dependencias (además de ayudarnos a detectar quién emite cada evento en cuestión).
Por ejemplo, tecleando:

initctl2dot -r mysql -o - | dot -Tpng -o upstart.png

Obtenemos la siguiente imagen:

Los jobs se muestran en cajas grises. Las líneas azules apuntan a los eventos cuya emisión arrancarían el job. Las líneas rojas indican qué eventos provocarían la parada de mysql. Las líneas verdes unen un evento con el job que lo emite.

Si te preguntas quién emite net-device-up (en el diagrama no hay ningún job que lo emita), puedes realizar una búsqueda desde /etc así:

/etc/$  grep -irn "net-device-up" *

y verás que lo hace el script if-up cada vez que se activa una tarjeta de red.

Emitir manualmente un evento
Tal y como se aprecia en la imagen anterior, es posible forzar la emisión de un evento. Para ello, desde la línea de comandos, basta con ejecutar:

$  sudo  initctl emit nombre_del_evento

Curiosidades
El primer evento que Upstart genera es startup.
Upstart tiene como uno de sus objetivos ser compatible con SysV init. Por ello, simula eventos runlevel y establece un DEFAULT_RUNLEVEL a través del job /etc/init/rc-sysinit.conf.

Muy interesante esta iniciativa de la que nos informa @penguinjournals: “Oye, te escribo para ver si me ayudas a esparcir un poco la semillita de nuestra iniciativa. A lo largo del año pasado, desde programania hemos estado promoviendo los Katayunos encuentros en los que coders nos juntamos para practicar por parejas TDD enfrentándonos a pequeños desafíos de código donde el objetivo no es resolverlo “sin más” sino hacerlo utilizando TDD y otra serie de buenas prácticas (pairing, clean code, control de versiones…).

Los eventos no tienen formato curso sino mas bien son del tipo “sentarse a cacharrear”. No se puede asistir en modo lurker ya que se realizan iteraciones de 45 minutos tras los cuales se anima a la gente a cambiar de pareja, cambiando normalmente también de lenguaje de programación. Pero lo importante es el aprendizaje por participación, luchando un poco contra el formato “clase magistral” al que estamos generalmente habituados.

Este curso nos hemos venido arriba con gente de agile-zona norte y los Katayunos van a pasar a organizarse en Bilbo, Vitoria, Donostia y Pamplona, éste primer Katayuno del día 24 de este mes es el único que se celebrará en las 4 simultaneamente y que tendrá un formato introductorio al TDD, esto no quiere decir que vaya a ser un curso de TDD sino que habrá una introducción que en meses posteriores ya no se hará (no pretendemos ser una academia de programación ;-)”

Así pues, invitados quedáis, amigos lectores, la entrada es gratuita y ya está anunciada la primera Kata, “String Calculator“