Software Libre en la Universidad: 2011 (I)

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.

Recuperando espacio en el buzón Gmail

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: una introducción para los viejos rockeros de init

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.

Katayunos y MerenDojos

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«

Trabajando en la nube Amazon desde la línea de comandos (I)

Hello World! Sí, tras un parón de casi 2 meses sigo vivo 🙂 ¿En qué he estado divirtiéndome todo este tiempo? En redactar mi tesis (y lo que te rondaré, morena), en leer -mucho- sobre análisis de datos con R -y el maravilloso entorno RStudio-, en seguir con el desarrollo de Babelium – API, HTML5, integración con Moodle… – y sus implantaciones en distintos cursos universitarios. Usando para esto último la nube de Amazon (AWS, Amazon Web Services).

Precisamente de AWS quería hablar un poco hoy. Hacía tiempo que no disfrutaba tanto con alguna novedad informática. Desde la línea de comandos puedes lanzar máquinas virtuales (instancias), asignarles IP, cambiarles el disco, ampliar la memoria, la CPU… todo desde la terminal y tu intérprete (ba)sh favorito (o desde scripts en PHP, Python, Perl, Ruby, Java…).

Basta con definir 3 variables de entorno

export EC2_PRIVATE_KEY=/opt/juanan/pk-6OZ6AAAAAAUUXZGNIAAWE63AMBBBBBB.pem
export EC2_CERT=/opt/juanan/cert-6OZ6AAAAAAUUXZGNIAAWE63AMOBBBBBB.pem
export EC2_URL=http://eu-west-1.ec2.amazonaws.com

La primera y la segunda forman tus credenciales (clave privada y certificado X.509).

(sáltate el siguiente párrafo si no quieres saber para qué quiere Amazon estas credenciales, porque no es necesario saberlo para usar el API)

Las consultas/peticiones al API de Amazon se firman con la clave privada. Estas consultas van acompañadas del certificado X.509. Cuando la petición llega a Amazon, el sistema extrae la clave pública de dicho certificado y descifra la firma digital que has realizado con tu clave privada. Si todo va bien, comprueba además que el certificado coincide con el que Amazon tiene guardado y asignado a tu persona (al que firma la petición). Menudo tinglado para una llamada al API, eh? Puedes ver más info en la ayuda de AWS.

La tercera variable de entorno, EC2_URL, sirve para indicar que tus máquinas virtuales (instancias, en terminología Amazon) quieres tenerlas «alojadas», por defecto, en la región de Europa Occidental. Las regiones son: US East – Northern Virginia, US West (Northern California), EU (Ireland), Asia Pacific (Singapore) y Asia Pacific (Tokyo). Hay varias zonas en cada región (realmente hay una región más: AWS GovCloud, destinada en exclusiva a las necesidades del gobierno de EEUU).

Los precios por tener una instancia en marcha varían dependiendo de la región, del tipo de instancia y características que pongas en marcha y del tiempo que estén lanzadas. Supuestamente habría que tener en cuenta no sólo el precio, sino la velocidad de respuesta de las instancias al cliente. Se supone que los clientes de Europa recibirán respuesta más rápida desde instancias alojadas en esa zona… pero tampoco es que lo haya comprobado empíricamente. Por otro lado, por cuestiones de disponibilidad, conviene no dejar todos los huevos (instancias) en el mismo cesto (región y zona), sino diversificar.

Declaradas dichas variables de entorno, ya podemos lanzar nuestra primera orden en la línea de comandos (una simple descripción de regiones disponibles):

$ ec2-describe-regions
REGION	eu-west-1	ec2.eu-west-1.amazonaws.com
REGION	us-east-1	ec2.us-east-1.amazonaws.com
REGION	ap-northeast-1	ec2.ap-northeast-1.amazonaws.com
REGION	us-west-1	ec2.us-west-1.amazonaws.com
REGION	ap-southeast-1	ec2.ap-southeast-1.amazonaws.com

Otro ejemplo, para ver las zonas disponibles para la región eu-west-1:

$ ec2-describe-availability-zones --region=eu-west-1
AVAILABILITYZONE	eu-west-1a	available	eu-west-1	
AVAILABILITYZONE	eu-west-1b	available	eu-west-1	
AVAILABILITYZONE	eu-west-1c	available	eu-west-1

Sin embargo, los ejemplos anteriores son un poco pobres. Veamos un ejemplo final más interesante para finalizar esta primera parte:

$ ec2-run-instances  ami-359ea941  --instance-count 1 --instance-type t1.micro --key juanan --group default

Aquí hemos lanzado una instancia EC2 (una máquina virtual en la nube Elastic Cloud de Amazon) usando como base la AMI con identificador ami-359ea941. Una AMI, o Amazon Machine Image, es una especie de plantilla de máquina virtual. En términos de Prog. Orientada a Objetos, sería una Clase que puede ser instanciada y generar… je :-), instancias. AWS tiene su propio buscador de imágenes pero yo recomiendo éste otro catálogo: http://thecloudmarket.com/. Por cierto, la ami-359ea941 es una AMI oficial de Ubuntu, y tiene una «plantilla» con Ubuntu 11.04 en arquitectura x86 de 32 bits, para la región eu-west-1.

Siguiendo con la línea de lanzamiento de nueva instancia, la parte «–instance-count 1» indica que sólo queremos una unidad (puedes lanzar hasta 20 de este tipo a la vez…). La parte «–instance-type t1.micro» indica el tipo de máquina virtual que quieres: t1.micro es lo más pequeño que hay (y gratis por un año!). A partir de ahí, puedes tener gigantescos monstruos a 1 click de distancia.

La parte «–key juanan» indica que quieres acceder vía SSH a tu instancia con una clave privada SSH que lleva asociado este nombre. Al lanzar la instancia, Amazon deja la parte pública de esa clave SSH en el archivo .ssh/authorized-keys y sólo si tienes la parte privada en tu PC podrás acceder a esa instancia.

Finalmente, la parte «–group default» identifica la lista que define qué puertos TCP/UDP quieres tener abiertos o cerrados. Como sólo tengo una, especifico default (sin poner el nombre en concreto)

Nota: todo lo que indico sólo funcionará si tienes instalado el paquete ec2-api-tools de Ubuntu.

Ale, cierro el post, y sigo otro día con el tema AWS que da mucho, pero que mucho juego. Espero que os sea de utilidad.