BigBlueButton y Moodle (II)

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)

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/.

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.

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:

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í:

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:

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.

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

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):

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

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

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.

Una china en el autocompletamiento Bash

No una china en el zapato… sino en el autocompletamiento Bash. Los usuarios de la línea de comandos solemos «volar» literalmente mientras escribimos comandos en terminal. Pero usamos un truco: el autocompletamiento Bash. Si quieres ver el contenido del directorio /tmp/algo/muy/largo basta con teclear (donde TAB es el tabulador):

y Bash lo autocompletará así:

Sin embargo, desde la versión de Bash que nos trajo Natty (Ubuntu 11.04), al teclear

el autocompletamiento añadía un espacio en blanco a la derecha del TAB y por tanto se rompía la magia (no es posible seguir tecleando y pulsando TAB a partir de ese espacio)

En este hilo de discusión al respecto de este bug, el usuario Silas da con la clave para arreglar este comportamiento tan errático: basta con editar el fichero /etc/bash_completion, línea 1587 y donde pone -o default poner- o filenames. Guardamos los cambios y a partir de la siguiente terminal que abramos, el problema estará solucionado.