Configuración de cuentas de Office 365 en Moodle

Para configurar una cuenta de correo en Moodle por SMTP, para que envíe correo desde esa cuenta, tienes que ir a Administración del sitio->Servidor->Correo Electrónico-> Configuración de correo saliente .

Pero la configuración de Office 365 tiene alguna peculiaridad. Os dejamos la que nos funcionó para que lo probéis. Estos son los datos que tenéis que poner:

  • Servidores SMTP (smtphosts) : smtp.office365.com:587
  • Seguridad SMTP (smtpsecure) : TLS
  • SMTP Auth Type (smtpauthtype) : LOGIN
  • Nombre de usuario SMTP (smtpuser): usuario@tudominiodeoffice365.com
  • Contraseña SMTP (smtppass): tucontraseña

Salvo el puerto, estos detalles son bastante comunes. PERO no funciona sólo con esto. La clave es que las restricciones de Office365 obligan a estas modificaciones (para que la cuenta saliente sea igual a la que lo envía).

  • Dirección ‘no-reply’ (noreplyaddress): tiene que ser la misma que smtpuser de arriba
  • Tienes que bajar en esta misma página hasta donde pone Información de origen en el asunto (emailfromvia) tiene que poner NUNCA.
  • Por último tenemos que ir a Administración del sitio->Servidor-> Contacto de soporte y donde pone Email de soporte (supportemail) tiene que poner lo mismo que en smtpsecure arriba.

Tu cuenta de correo tiene que estar en smtpuser, noreplyaddress y supportemail.

Con esto ya debería funcionar.

Puedes hacer las pruebas desde la página de Administración del sitio->Servidor->Correo Electrónico-> Configuración de correo saliente

Si tienes más problemas, existe un plugin (que no hemos probado), Email Test, que te permite hacer un análisis de dónde puede estar fallando el SMTP y te ayuda a intentar encontrar el error.

Greenlight de Big Blue Button. Fallo al actualizar y comandos útiles de docker.

Ayer queríamos crear un nuevo usuario de Greenlight por línea de comandos y, como nuestra versión no permitía esta opción, actualizamos. ¿Conclusión? Error en Greenlight:

Greenlight encountered a database migration error.
This may be because you haven’t updated to Greenlight 2.0.
If you are not an administrator, please contact one.
We’ve released a new version of Greenlight, but your database isn’t compatible.

Hoy os explicamos cómo lo solucionamos, junto a algunos comandos útiles usando docker.

Cómo actualizar Greenlight.

Para las últimas versiones (a fecha del artículo) la actualización es bastante sencilla. La documentación dice ejecutar
$ docker pull bigbluebutton/greenlight:v2 aunque si quieres más opciones puedes elegir cualquier de las “releases” desde Dockerhub.

Aquí fue donde nos falló, tras la actualización daba el error mencionado arriba. Por más que paráramos Greenlight con $ docker-compose down para levantarlo luego con $ docker-compose up -d

Obviamente el mensaje no tenía sentido. Veníamos de una versión 2.2 a una 2.4. Pero creo que ponen un mensaje genérico que no indica mucho.

Qué estaba pasando.

Investigando pudimos ver que ejecutando
docker exec greenlight-v2 bundle exec rake db:migrate nos decía que nos faltaba una tabla, role_permissions , en la base de datos (que se encuentra en el directorio root/greenlight/db/production).

Además, ejecutando docker exec greenlight-v2 bundle exec rake db:migrate:status nos decía que quedaban 3 pasos de la migración por completar.

Teníamos 2 opciones, intentar añadir esta tabla manualmente, y luego volver a ejecutar el comando con db:migrate para que continuara con la migración (o con posteriores errores) o recrear la base de datos. Como nosotros no tenemos grabaciones, y básicamente 3 o cuatro usuarios, decidimos optar por la segunda opción.

Para ello:

  • renombramos la base de datos para poder tener copia.
  • Paramos Greenlight con $ docker-compose down
  • Ejecutamos docker exec greenlight-v2 bundle exec rake db:setup que básicamente recrea la base de datos vacía. Te indica en línea de comandos el usuario administrador.
  • Entramos, cambiamos los datos (nombre y contraseña) del administrador.
  • Añadimos los usuarios que nos faltaba siguiendo la documentación con
    $ docker exec greenlight-v2 bundle exec rake user:create["name","email","password","user"]
    para usuarios normales y
    $ docker exec greenlight-v2 bundle exec rake user:create["name","email","password","admin"] para administradores.

Y resuelto.

Tenemos que recordar que, al ser Greenlight un front-end de Big Blue Button, el servicio de videoconferencias es independiente y sigue activo en todo este proceso (afortunadamente).


Error en los cron job de Moodle: undefined function current_language().

Hace unos días, tras actualizar Moodle y cambiar/actualizar las versiones de php del hosting, nos dimos cuenta que los cron job de ese Moodle no estaban funcionando.
En el backend simplemente decía que “el script de tareas cron no se ha ejecutado en más de X horas”. No daba más información.
Pero mirando los logs del servidor, o cuando intentabas ejecutar el script a mano, nos dimos cuenta que salía un error que, entre otras cosas, decía “undefined function current_language()“.
Os decimos cómo solucionarlo.

Solución a undefined function current_language() en los cron job de Moodle.

Básicamente lo que ha pasado es que Moodle ha actualizado sus scripts. Recordad que antes era un ejecutable por web pero ahora es un script del servidor que hay que ejecutar desde el mismo. Y seguramente lo que ocurra es que estás ejecutando el script con una versión más antigua de php de la requerida por el miso.
Los servidores tienen una versión de php “por defecto”. Y cuando ejecutas el script con php -q /rutademoodle/admin/cli/cron.php
se ejecuta con la versión por defecto. Y no es compatible con el script.

Tienes que ejecutarlo con la versión compatible más actualizada que tienes en tu servidor. Por ejemplo con:
php72 -q /rutademoodle/admin/cli/cron.php
o
php73 -q /rutademoodle/admin/cli/cron.php

Nota: la versión y comando a usar depende de tu servidor. Puedes poner php en el cli y darle al tabulador para ver las versiones soportadas. Y probar desde cli con alguna. Luego establecer la que funcione en el cron job.
En algunos hosting (mal configurados) habrá que ejecutar el comando desde la carpeta de php72 ( la que sea).

Dónde descargar versiones anteriores de Moodle

Es difícil tener Moodle actualizado a la ultimísima versión, porque la actualización no es “hacer un clic”. De hecho tampoco es recomendable porque los temas y addons no se actualizan tan rápido como el core, y porque pueden surgir problemas con la última versión.

Así que cuando quieres actualizar Moodle te encuentras con que tienes que descargar versiones que no están en su página web.

Aquí os dejamos los enlaces para descargar todas las versiones de Moodle.

Desde estos enlaces puedes encontrar la versión o versiones que necesitas y actualizar tu Moodle a la penúltima versión (no recomiendo la última).

Error Call to undefined function current_language() al correr el cron de Moodle

Otro de los errores típicos que nos encontramos al dar soporte a los clientes.

En este caso se trata al ejecutar el cron que necesita Moodle para las tareas de mantenimiento y limpieza. En el manual de Moodle indica que hay que ejecutar:

/usr/bin/php /ruta/hacia/moodle/admin/cli/cron.php

Este comando (con versiones actuales de Moodle, y dependiendo de la versión que tengas en tu servidor) puede dar el siguiente error:

Call to undefined function current_language() in /var/www/clients/client10/web87/web/lib/setuplib.php:713

Causa.

La causa de este error es que el script cron.php de las nuevas versiones de Moodle tienen comandos que no son compatibles con versiones anteriores a la 7.2 y tu servidor está ejecutando (al menos esa instancia) con una versión anterior.

Solución.

La solución es cambiar el comando que recomiendan y ejecutar la 7.2 (o superior). Así:

/usr/bin/php7.2 /ruta/hacia/moodle/admin/cli/cron.php

Si te da error ve a /usr/bin/ a ver que versiones tienes. Si no tienes superior a la 7.1 te toca instalar o pedir que te instalen una versión superior.

Una vez que veas que funciona en cli, puedes ponerlo en un cron job.

Nota: los números que he usado son actuales. Con problemas futuros habrá que probar con otras versiones, siempre superiores a la que te da el error.

Cómo actualizar un Moodle a la siguiente versión.

Como hemos dicho muchas veces, los artículos en el blog no son sólo para ayudar a gente que pueda tener los fallos que encontramos y arreglamos, sino que los usamos como “knowledge base”, como repositorio de soluciones. Cuando necesitamos hacer lo mismo en un futuro, lo miramos en el blog.

Este es un caso clarísimo de este tipo de artículos: cómo actualizar un Moodle a la siguiente versión. Ponemos aquí los pasos a modo de referencia rápida.

Pasos para actualizar un Moodle a la siguiente versión.

Si quieres información adicional sobre este proceso puedes ver este enlace, y las FAQ. Os resumimos los pasos:

  • Puedes comprobar tu versión de Moodle, y las actualizaciones existentes en Configuraciones > Administración del sitio > Notificaciones
  • No puedes actualizar de golpe. La actualización debe ser de versión estable a versión estable. La secuencia ahora mismo es:
    1.x -> 1.9.19+ -> 2.2.11 -> 2.7.20 -> 3.0.10 ->3.2-> 3.4 ->3.7
    Por lo tanto descarga la siguiente versión estable y haz la actualización entre varias escalonada.
  • En cada versión estable, actualiza también todos los módulos (y temas) y asegúrate que funcionan correctamente.
  • Comprueba que tienes activada la Clave al Actualizar.
  • Haz una copia de seguridad antes de actualizar. Tanto de ficheros como de base de datos. Y de la carpeta Moodle Data.
  • Lo ideal sería hacer la actualización antes en un sitio de prueba (aunque entendemos que no pueda hacerse siempre, y por eso la copia de seguridad).
  • Comprueba si tu servidor cumple los requisitos de la versión que quieres instalar. Para ello ve a Configuraciones > Administración del sitio > Servidor > Entorno. Si todo está ok puedes actualizar. Si no, tienes que solucionar esos problemas primero.
  • Pon tu sitio en Modo Mantenimiento, para que no entre gente. Administración del sitio > Servidor > Modo de mantenimiento
  • Copia todos los ficheros y directorios de tu Moodle a una subcarpeta en el directorio raíz. Llámala, por ejemplo, moodleold.
  • Sube todos los ficheros de la nueva versión de Moodle a la carpeta raíz. No debes sobreescribir los antiguos, en Moodle esto no es buena idea.
    Tienes que tener entonces en la raíz los ficheros y directorios de la nueva versión y una carpeta (moodleold por ejemplo) con lo antiguo.
  • Copia desde moodleold el fichero config.php a la raíz. Así tiene la configuración para conectarse a tu base de datos.
  • Copia el tema que tuvieras desde moodleold/theme a la carpeta theme de la raíz. Para que tenga tu tema.
  • Copia también cualquier plugin que hayas instalados. Están en diversas carpetas, como en la carpeta course (para los formatos de cursos) o en mod. Pero si se te olvida alguno no te preocupes, ahora la actualización te lo dice.
  • Ahora intenta entrar en tu web Moodle, te pedirá la Clave de Actualización. Después de aparecerá un aviso que está actualizando a la nueva versión para aceptarlo.
    Después de informará de nuevo sobre las compatibilidades, y luego una pantalla sobre los plugins que va a instalar o actualizar.
    En esta última conviene que actualices los que te ponga que tienes que actualizar.
  • Dale a continuar un par de pantallas y ya debería pedir tu usuario y contraseña de Moodle, y aceptar las últimas configuraciones (las de las novedades).
  • Con eso deberías tenerlo actualizado.

Añadir una “Clave al Actualizar” en Moodle.

La versión 3.0 de Moodle vino con una nueva funcionalidad de seguridad que es importante activar. Sobre todo para cuando vamos a actualizar. Es la llamada Clave al Actualizar.

Parece ser que cuando actualizamos Moodle, tanto el core como los plugins, los mecanismos de autentificación no son muy fiables. Y alguien podría entrar en nuestro sistema. Esta nueva clave añade una seguridad extra en esos momentos, y cualquier persona que quiera entrar en nuestro sistema debe saber dicha clave.

Cómo añadir una Clave al Actualizar en Moodle.

Para activar esta funcionalidad debemos (si tenemos versiones posteriores a la 3.0), editar el fichero config.php y añadir la siguiente línea:

$CFG->upgradekey = ‘ponga_aquí_una_clave_secreta‘;

Donde ponga_aquí_una_clave_secreta es una clave que recomendamos sea complicada y distinta a cualquiera del Moodle (y, por supuesto, no la de administración).

Guardamos el fichero y, a partir de entonces, el sistema pedirá esta clave a todo usuario que quiera registrarse mientras el sistema se está actualizando.

Muy útil, hacedlo cuanto antes.

OpenBoard: software tipo pizarra para tabletas gráficas usado en educación.

Llevo un tiempo buscando un software de este tipo. En una de las empresas tenemos tabletas gráficas que usamos para formación, pero esas tabletas tienen que “pintar” en algo. En una “pizarra digital” para ordenadores, y no en programas de edición gráfica tipo GIMP, porque no se van a usar para eso
Y preferiblemente que se puedan cambiar los fondos, porque escribir con estar tabletas gráficas es difícil, y se agrede de la ayuda de hojas con líneas.

OpenBoard.

OpenBoard es precisamente lo que buscábamos. Un software de código abierto ( GPLv3 License ) pensado para academias y colegios. Compatible con Windows, Linux y Mac.

Pero además nos ha sorprendido por lo bien que está hecho el programa. Por lo fácil que es de manejar, lo claro de su interfaz y la rapidez de respuesta.

Os dejamos un vídeo explicativo:

Crear un usuario administrador para Greenlight, el interfaz gráfico de Big Blue Button.

Una de las primeras cosas que me faltaron cuando instalé Big Blue Button con Greenlight era tener un usuario administrador para poder gestionar la creación de usuarios, y alguna personalización de la interfaz gráfica.
Bueno, ya lo han remediado y os enseñamos a activarlo.

Paso 1. Actualizar Greenlight.

Lo primero es actualizar Greenlight, porque esta característica está en las “nuevas versiones” y si lo intentas en las anteriores dará error (no reconoce admin:create ). Pero esto es fácil, entra por ssh a tu servidor BBB y escribe lo siguiente.

docker pull bigbluebutton/greenlight:v2

Paso 2. ¿Has pasado de docker run a docker compose?

Los anteriores sistemas de Greenlight se ejecutaban con docker run. Pero eso no está admitido ya y hay que pasar a ejecutarlo con docker compose. Para hacerlo tienes que seguir estos pasos, que consisten en (más info):


Si no has actualizado (si lo has hecho no hace falta) limpia la instancia anterior con:

docker stop greenlight-v2
docker rm greenlight-v2
  • Instala docker-compose en tu servidor. No vale con la versión de la distribución, necesitas una más reciente. Así que sigue los pasos aquí.
    Comprueba que está con docker-compose -v

Paso 3. Arranca Greelight con Docker Compose.

  • Desde el directorio greenlight ejecuta:
    docker run --rm bigbluebutton/greenlight:v2 cat ./docker-compose.yml > docker-compose.yml
  • Ahora arranca Greenlight con docker-compose up -d
  • Puedes pararlo a partir de ahora con docker-compose down (más fácil que antes).

Paso 4. Ahora crea el usuario administrador.

Para ello ejecuta el siguiente comando desde el directorio greenlight:
docker exec greenlight-v2 bundle exec rake admin:create["name","email","password"]

Donde tienes que cambiar name, email y password por lo que quieras (puedes no poner los valores entre [] y el creará los datos por defecto y te los pasará en pantalla.

Con esto ya tendréis usuario administrador en Greenlight.

El usuario administrador es útil porque puedes usarlo para crear otros usuarios, borrarlos, promocionarlos a administrador, y algunas opciones de personalización del frontend como logo y colores.
Para ello pincha en tu perfil, y en Organización.

Nota: si has actualizado, cuando entres como administrador, revisa las opciones de creación de cuentas porque se habrá modificado. Pero con ese usuario se puede cambiar rápidamente.

Big Blue Button: problemas con la cámara en ciertos móviles. Error 2203: Server could not find an appropriate codec.

Llevamos un tiempo trabajando con Big Blue Button para las videoconferencias. Recientemente hemos descubierto un problema con ciertos móviles, específicamente con algunos (no todos) móviles chinos. Si intentas compartir la cámara, tras unos momentos da un error.
Los errores pueden ser varios, pero se suelen referir a los codecs o a permisos. El más habitual:

Error 2203: Server could not find an appropriate codec

Hemos investigado el problema y encontrado una posible solución.

Solución al error de la cámara en algunos móvies.

La causa parece ser por el codec de video h264 , el que usa Big Blue Button por defecto para el vídeo. Este codec no es gratuito, tiene un pequeño coste. Algunos fabricantes chinos prefieren ahorrarse ese gasto por terminal y no incluir lo en sus teléfonos. Por eso ciertos Android chinos no pueden compartir la pantalla.

Big Blue Button usa H264 porque iOS (iPhone etc) sólo admite este codec.
Hay otro codec gratuito que se puede usar, VP8, pero entonces Big Blue Button tiene que “transcodear” cada emisión de vídeo de móviles Android con conexiones de móviles iOS (porque iOS no tiene VP8), y eso gasta CPU.

Así que estamos ante una decisión, o no permitir ciertos móviles Android chinos (según hemos probado muchos, con marcas como Asus o Huawei), o activar VP8 y que a veces use más recursos del servidor. Como los recursos se pueden dimensionar, y no queremos problemas de compatibilidad, nosotros elegimos esta segunda opción.

Cómo activar VP8 por defecto.

La manera de activar VP8 la encontramos aquí, aunque es de una versión antigua y las rutas y lo que hay que comentar varía ahora. Os indicamos las nuevas.
Activando VP8 lo que hacemos es que use este por defecto (con el posible gasto de CPU indicado arriba) si lo tiene, si no usará H264. Si se conectan móviles iOS, Big Blue Button tendrá que trascodear las conexiones VP8 de los Android.

El fichero a editar es
/usr/local/bigbluebutton/bbb-webrtc-sfu/config/default.yml

Ahí buscamos unas líneas que ponen:
codec_video_main: H264
codec_video_content: H264


Y cambiarlas por
codec_video_main: ANY
codec_video_content: ANY

Después activamos esta nueva configuración en BBB con
sudo bbb-conf –restart

Con esto ya nos funciona el vídeo en todos los dispositivos.