Encuentro de administradores

Los días 14 y 15 de Diciembre acudí a la MoodleMoot 2011, celebrada en la encantadora ciudad de Donosti. En ella me encargué de dinamizar el Encuentro de Administradores, que se celebró en la tarde del 14.

Ahora, aprovecho este post para explicar las pautas generales que tratamos en él.

Empezamos en la diferenciación de los tipos de administradores que podemos encontrar, de los que podemos distinguir* los dedicados a:

• Moodle.
• Sistemas.
• Bases de datos.

           * Una persona puede pertenecer a más de un tipo.

Moodle

La principal novedad de esta MoodleMoot es la aparición de la nueva versión 2.x de Moodle, entonces nos centramos en esta versión, y como administradores, debemos analizar como afrontar el cambio.

Inicialmente, con esta versión nos vienen cambios con respecto a la 1.9.x. Además, al expandir las opciones de configuración, conlleva una administración más compleja, con más elementos y más acciones. Otros cambios importantes son los referentes al software, sobretodo la versión de PHP utilizada, que va cambiando continuamente.

Versiones, versiones y más versiones. ¿Cuál elegir?

Prácticamente la mayoría de presentes en el encuentro tiene en producción la versión 1.9, y, además, casi todos ellos está haciendo tests y pruebas con la 2.x.

Un gran compañero de trabajo me enseñó la premisa básica de: “Si funciona, no lo toques”. Entonces, ¿Porqué cambiar de versión si no es estrictamente necesario? En este caso sí que es necesario, ya que la versión 1.9 termina su mantenimiento en Junio de 2012.

Durante la presentación de mis compañeros de CV&A, enfatizaron la necesidad de ir actualizando hasta la última versión. Conociendo Moodle, estoy totalmente convencido de eso, pero hay que ir con cuidado ya que no es la primera vez que lanzarse a la última versión disponible trae más de un dolor de cabeza (recordemos nuestra querida versión 1.7).

Quedó claro, que actualizar a la versión 2.2 (que hacía 5 días que  había sido liberada), era una buena opción. Eso no lo dudo, pero por precaución indagaremos en los foros a ver que tal va, y que dicen de ella. Recomendé, igual que CV&A, que la versión 2.0 no se instalara, por su falta de mantenimiento. Entonces, solo nos queda 2.1 o 2.2 … 2.2 era demasiado reciente, por consiguiente, 2.1 puede ser una buena solución.

Las funcionalidades ya las comentaré en otros posts, o sino, se puede consultar la presentación que hice, que está disponible en la página web de la MoodleMoot.

¿Instalación o actualización?

Depende de cada instalación, podremos realizar una nueva instalación o, en cambio, una actualización de nuestra versión 1.9 hasta la 2.x correspondiente.

El principal inconveniente que mencioné, es que para actualizar, y según la documentación oficial de Moodle, se debe actualizar versión a versión, entonces, si tenemos instalada la versión 1.9.x, debemos actualizar hasta la última 1.9.x disponible, para después actualizar hasta la 2.0, después hasta la 2.1, y así sucesivamente.

Otro problema menor puede ser que algún módulo, plugin, etc, no se actualice bien. No porqué este mal programado, sino por culpa de los cambios a todos los niveles que ha sufrido Moodle en la versión 2.x. Por nombrar algunas, nivel de base de datos (estructura y acceso), programación, paginación, etc.

Por tanto, siempre que se pueda, la recomendación irá encaminada a realizar una nueva instalación.

Aspectos genéricos de configuración

A modo de resumen, todo administrador de Moodle debería revisar la configuración de su instalación (o instalaciones), a continuación listo una serie de recomendaciones (aplicables o no, según necesidad/política):

• Usar SSL en la autenticación de usuarios, y además en modificación de datos sensibles. Si se puede, utilizar siempre.
• Fijar una política de contraseñas.
• “Tener mano izquierda” para que los usuarios no mueran en ello.
• Usar los formularios seguros.
• Deshabilitar el acceso de Google.
• Utilizar la matriculación interna.
• Si permitimos automatricularse, establecer una contraseña para ello.
• Eliminar la ayuda para adivinar la clave de matriculación a un curso.
• Deshabilitar el acceso a usuarios anónimos.
• Evitar la visualización de errores PHP en pantalla.
• Permitir los tags de HTML embed y object.
• Habilitar el filtro .swf, y fijar la versión de flash.
• Evitar los perfiles abiertos.
• Limitar la visualización y/o acceso al lugar.
• A tal efecto, si es posible, obligar a la autenticación de los usuarios.

Sistemas

Otro aspecto a administrar, independiente (o no) de Moodle en sí, es el sistema o conjunto de sistemas sobre los que se ejecuta el software de Moodle.

Independientemente de si la base de datos está ubicada en el mismo sistema, un administrador de sistemas tiene que hacer frente a la gestión de PHP, complementos adicionales necesarios, sistema operativo, además del sistema de ficheros.

A nivel de PHP, se ha comentado en el apartado anterior que Moodle necesita versiones diferentes según su versión. Por ejemplo, 2.0 requiere la versión 5.2.8 o superior, y 2.1 requiere 5.3.2, etc. Así que, según el sistema operativo sobre el que se ejecute la plataforma, eso puede ser un verdadero quebradero de cabeza. Evidentemente estamos hablando de sistemas operativos con soporte, estilo Red Hat, SuSE Enterprise (SLES), Windows Server, etc. Otras distribuciones GNU/Linux, Windows, Mac OX probablemente no tendremos tantos problemas, sobretodo a la hora de requerir soporte por problemas causados por versiones no soportadas.

Actualización, ¿y eso que es?

Actualizar constantemente el software del sistema operativo, sobretodo para intentar evitar los problemas de seguridad. A nivel más de Moodle, es necesario registrarse en moodle.org para recibir los avisos de seguridad y disponibilidad de parches para atajarlos.

Copias de seguridad

Aspecto fundamental y básico en cualquier sistema informático, se debe planificar, ejecutar, y realizar los correspondientes tests de fiabilidad de éstas.

Copias de seguridad se deben hacer de:

• Moodle.
• Aportado por el mismo software, y cuyo rendimiento (en sitios grandes), es patético e inviable.

• Sistema operativo.
• Snapshots semanales, por si tenemos un desastre a este nivel.
• En entornos virtuales, su configuración es mucho más simple que si tratamos con máquinas físicas.

• Sistemas de ficheros.
• La típica copia de seguridad de ficheros.
• Bases de datos.
• Dumps diarios.

Testear fehacientemente  las pruebas de recuperación, a cualquier nivel expuesto en la lista anterior.

Bases de datos

Finalmente, respecto a las bases de datos debemos tener en cuenta la versión mínima soportada por la versión de Moodle instalada. A partir de esa premisa, del conjunto de bases de datos soportadas, ¿cual elegir?

Bases de datos totalmente soportadas:

• MySQL.
• PostgresSQL.
• Oracle.
• MS SQL.

A partir de ahí, debemos hacernos las preguntas de:

1. ¿Utilizo módulos/plugins/etc no oficiales?
2. ¿Tengo hechas modificaciones de código que afectan a sentencias SQL?
3. ¿Dispongo o tengo tendencia a implantar alta disponibilidad en el servicio?.
• ¿Hasta que punto?
4. ¿Sobre que BD tengo conocimientos?
5. ¿Tengo licencia/soporte/etc de alguno de ellos?

De estas 5 preguntas saldrán unas conclusiones, que, como administradores, deberemos satisfacer con la mayor holgura posible.