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)

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

BigBlueButton (I)

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 😉

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.