Ikasten.IO

Introducción a Open edX

Los que leéis este blog ya sabéis qué es un MOOC (Massive Open Online Course). Lo que no se suele tratar tanto es la infraestructura que hay detrás. ¿Qué sistema permite ofrecer cursos masivos online con alta disponibilidad y multitud de características asociadas a estos MOOC (soporte de vídeos, subtítulos, evaluación colaborativa, distintos tipos de ejercicios para distintas áreas de conocimiento, certificados de completamiento, foros con miles de usuarios concurrentes…)?

Open edX es una de esas plataformas. Creada por los ingenieros de edX, una organización sin ánimo de lucro formada por la colaboración de la Universidad de Harvard y el MIT, edX ofrece MOOCs de distintas organizaciones educativas de todo el mundo a través de edx.org. A pesar de que la organización se llama edX y la plataforma que han creado, con licencia abierta Affero GPLv3 se llama Open-edX, la gente habla de edX como sinónimos de ambas cosas y así lo haré yo también de vez en cuando. Por otro lado, al tándem inicial de Harvard y MIT se unieron después (y colaboraron con código a la plataforma), la universidad de Stanford, Google (orientando el trabajo de sus ingenieros en Course Builder a edX), la universidad de Queensland, la universidad de Tsinghua y la universidad de Berkeley.

edX ofrece multitud de características:

Posibilidad de mostrar lecciones grabadas en vídeo con subtítulos e indexación sobre los propios subtítulos (puedes buscar por palabras que aparezcan en los mismos y al pulsar sobre los resultados, ir directamente a la sección de vídeo que los contiene)
Posibilidad de añadir materiales de estudio (organizados como libros, notas o simples ficheros)
Diferentes tipos de tests y exámenes
Laboratorio Virtual con interfaz interactivo (para problemas de electrónica)
Caledandario/Planificación del curso
Soporte multi-idioma
Foros de discusión
Wikis
Informes de progreso
Sistema para implementar Learning Analytics
Diferentes tipos de evaluación de tareas: evaluación entre pares, auto-evaluación, hetero-evaluación, evaluación automática
Sistema de notificación de eventos por correo electrónico
Emisión de certificados de completamiento
Integración con Google Hangouts
Preparado desde el principio para ser escalable

Aprender a instalar edX, configurarlo y usarlo lleva su tiempo. A finales de 2013 estuve trabajando y documentando este sistema para un proyecto dirigido por la Fundación Asmoz. Desde la web del proyecto podréis acceder a los 3 manuales que redacté al respecto. Durante una serie de posts, iré detallando poco a poco en este blog el trabajo realizado con Open edX.

perl: warning: Setting locale failed

Conectamos por ssh contra nuestro servidor, lanzamos un comando erróneo y aparte del mensaje de error el intérprete de comandos nos suelta el siguiente sermón:

# comando erróneo
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
	LANGUAGE = (unset),
	LC_ALL = (unset),
	LC_PAPER = "es_ES.UTF-8",
	LC_ADDRESS = "es_ES.UTF-8",
	LC_MONETARY = "es_ES.UTF-8",
	LC_NUMERIC = "es_ES.UTF-8",
	LC_TELEPHONE = "es_ES.UTF-8",
	LC_IDENTIFICATION = "es_ES.UTF-8",
	LC_MEASUREMENT = "es_ES.UTF-8",
	LC_TIME = "es_ES.UTF-8",
	LC_NAME = "es_ES.UTF-8",
	LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
ERROR: (algo relacionado con el comando erróneo)

Mmmh… ¿por qué? Pues porque en el fichero /etc/ssh/sshd_config tenemos una linea como la siguiente:

AcceptEnv LANG LC_*

Que viene a decir: las variables de entorno relacionadas con el idioma del usuario deben ser exportadas al intérprete de comandos destino de una conexión ssh. En mi caso, el soporte es_ES. El problema es que los paquetes de ese idioma en el servidor destino no están instalados… de ahí que Linux se queje amargamente.
Bueno, para evitarlo hay varias formas. La más sencilla: basta con comentar la línea en cuestión de /etc/ssh/sshd_config (añadiéndole un # por delante) y ¡listo!

Parchear Ubuntu para evitar el bug OpenSSL Heartbleed

Ayer a la tarde se levantó una buena polvareda con el bug Heartbleed de OpenSSL. Básicamente, cualquier usuario podría acceder a una zona de 64Kb de memoria del servidor, cercana a la zona donde se gestionan las operaciones con SSLv3. Esto podría llegar a permitir acceder a información privilegiada, como por ejemplo la clave privada usada para el cifrado. Aunque hay dudas técnicas sobre este aspecto específico (acceso a las claves privadas), los investigadores que descubrieron el bug así lo afirman (como indica el primer link). Conclusión: estás tardando en actualizar OpenSSL en tu servidor 🙂

sudo apt-get update
sudo apt-get install -y libssl1.0.0 openssl
openssl version -a # y confirma que es la nueva versión ("built on" >= 2014-04-07)
sudo lsof -n | grep ssl | grep DEL  # reload de todos los servicios que usen versión vieja

Repite el último paso hasta que no queden servicios usando la versión vieja de openssl.

Gracias a coderanger por los tip.

Update (11/04/2014): como dije, hay serias dudas de que el acceso a las claves privadas sea viable. De hecho, uno de las primeras webs donde se expuso el bug lanza ahora un reto: han puesto un servidor HTTPS vulnerable en marcha y retan a la comunidad a extraer la clave privada usando el bug Heartbleed.

Update (13/04/2014): pues han tardado unas pocas horas en extraer la clave privada. Vaya, vaya…

Resize de volúmenes en LVM

Tenemos un sistema de discos LVM con las siguientes «particiones»:

[juanan@S000161 ~]$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg_s000161-lv_root
                       50G   39G  8.6G  82% /
tmpfs                 5.8G  316K  5.8G   1% /dev/shm
/dev/mapper/ddf1_4c5349202020202080862925000000004711471100001450p1
                      485M   58M  402M  13% /boot
/dev/mapper/vg_s000161-lv_home
                      395G   87G  288G  24% /home

Si nos fijamos, el volumen lógico (lv) asignado a / está al 82% y sólo tiene 8.6GB libres. Por otro lado, el LV /home tiene GB de sobra (288GB libres, con sólo un 24% de utilización).

Vamos a recortar un poco (100GB) de /home para «estirar» / .

Siempre como root, desmontar el volumen, revisar posibles errores, y reducir tanto el sistema de archivos (ext4) como el propio volumen. Estas dos últimas operaciones se pueden hacer de un plumazo con la opción -r de lvreduce.

umount /dev/mapper/vg_s000161-lv_home
e2fsck -f /dev/mapper/vg_s000161-lv_home
lvreduce -r /dev/mapper/vg_s000161-lv_home --size -100G
(ojo, -100, con el menos por delante. Si pones 100G, sin el menos, recortas hasta ese tamaño!!!!)

Ahora que tenemos 100GB disponibles, los usaremos para aumentar la «partición» /.

Asegurarse de que está montado el volumen (sí, ¡montado!) y le damos caña:

lvextend /dev/mapper/vg_s000161-lv_root -r --size +100G

Depurar, editar y guardar ficheros JS en Google Chrome

Receta rápida para los desarrolladores JavaScript interesados, y para retomar el blog tras un parón de unos cuantos meses (he estado ocupado 🙂

La cuestión es: las DevTools de Google Chrome permiten editar y depurar código JavaScript desde el propio navegador. Pero cuando editas un fichero .js y lo intentas guardar, salta el siguiente error:

«Changes to this file were not saved to file system». Vaya… pues qué bien… mmmmhh…. ¿y qué dice StackOverflow al respecto? Que existe una solución 🙂 Vamos allá…

Lo primero: pulsa en el botón de configuración.

Lo segundo, elige la opción Workspaces y añade las carpetas con las que trabajas (las que contienen tu código JS):

Puedes añadir más de una carpeta. Fíjate también que puedes editar mapeos URL –> Carpeta local, pero ahí no me meto (por ahora!)

Ojo, cuando añadas carpetas tendrás que aceptar dar permiso, para cada una, para que DevTools pueda acceder a esos datos en modo lectura/escritura. Esta ventana de solicitud de permisos aparece por debajo, en la ventana de Chrome, así que atento, porque hasta que no la pulses, la carpeta no se añadirá correctamente.

Ya casi está. Si estás usando el protocolo file:// para trabajar con tus ficheros en lugar de http://, ojo, porque en ese caso, deberás abrir tus archivos JS desde la carpeta que acabas de añadir al workspace (no vale abrir el fichero haciendo doble click sobre él desde el escritorio o tecleando la ruta en la barra de direcciones del navegador).

Sino que tendrás que ir a la pestaña «Sources» y hacer doble click sobre los ficheros de las carpetas importadas (ojo, no desde file://)

Y a partir de ahora, cualquier cambio realizado en el panel DevTools podrás guardarlo «automágicamente» en el sistema de archivos local con un simple Ctrl+S.