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.

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.

En la dirección https://github.com/tmas0/moodle-block_eMail encontrareis el código de correo interno, así como su evolución. Ahora mismo solo está disponible la versión aplicable a Moodle 1.9. A lo largo de esta semana iré avanzando con el tema.

Inicialmente, he considerado 5 grandes tareas, cuya principal será la adaptación del código a la versión 2.x de Moodle. A continuación os dejo el diagrama de Gantt correspondiente.

eMail List

Dichas tareas son:

• Adaptar el código a la versión 2.x de Moodle.
• Solucionar errores de seguridad.
• Solucionar errores de código/funcionalidad.
• Evolucionar la usabilidad.
• Incorporar nuevas funcionalidades.

Ahora, el proyecto renace, como el ave Fénix, a nivel totalmente personal, y ya fuera del ámbito del Centro de Tecnologías de la Información de la Universitat de les Illes Balears. Todo y este nuevo rol, cabe mencionar que su rendimiento en entornos de elevada carga, se mantendrá e incluso se intentará mejorar.

Su supervivencia será a base de vuestras donaciones, cuyo botón podéis encontrar a vuestra derecha.

Para informar de problemas, sugerencias, mejoras, etc, se podrá utilizar el tracker de Moodle, así como este blog, que pasa a ser oficial.

Una de las problemáticas de tener un clúster de Moodle es el cron que hace el mantenimiento de él. Al tener el clúster, y con ello la alta disponibilidad, hace aparecer la necesidad de ejecutar el cron pero por temas de eficiencia y coherencia sólo en uno de ellos.

La delegación de esta tarea se puede hacer de tres formas diferentes:

1. Dedicar un servidor a ello. El problema surge cuando tenemos problemas de disponibilidad con él, entonces no es un solución idónea.
2. Si tenemos un solo servidor del SGBD, se puede utilizar éste para ejecutar el cron.
3. Habilitar una tarea del SGBD para que ejecute periódicamente el cron de Moodle.

Las dos primeras soluciones son similares, pero la segunda tiene ventajas que la primera no tiene, sobretodo porque el mantenimiento y vigilancia del segundo será mucho mayor que el primero, entonces, con el mismo esfuerzo mantendremos las dos tareas.

Para estas dos primeras soluciones debemos utilizar el cron del sistema operativo, suponiendo que estamos utilizando un sistema operativo GNU/Linux, u otro que pueda implementar trabajos automáticos.

En el cron enlazaremos el siguiente script hecho en Bash.

#!/bin/sh

# Autor: Toni Mas - 28/06/2010

# SERVER's del cluster
SERVERS="servidor1.host.es servidor2.host.es"

# Sites de Moodle que hemos de ejecutar el cron
SITES="mdl"

# Directorio donde se almacenarán los logs.
LOGDIR=/home/usuario/cronMoodle/logdir

# Buscamos el nodo del clúster que este disponible
for SERVER in $SERVERS
 do
 ping -c 1 -w 5 $SERVER &>/dev/null
 if [ $? -ne 0 ] ; then
 HOST=$SERVER
 fi
done

# Comprobamos que el directorio de logs este creado
if [ ! -e "$LOGDIR" ]
 then
 mkdir -p "$LOGDIR"
fi

# Para cada uno de los sites, ejecutaremos el CRON
for SITE in $SITES
 do
 wget -q "http://$SERVER/$SITE/admin/cron.php?password=MyPassword" -O "$LOGDIR/$SITE-`date '+%Y-%m-%di_%H:%M:%S'`.log"
done

Para dejar claro las premisas que se han tenido en cuenta, en el anterior script se suponen:

1. Se escriben específicamente los nombres DNS de cada uno de los servidores del clúster, para así comprobar la disponibilidad de ellos.
2. Se escriben específicamente los nombres de cada uno de los sitios Moodle que tengamos instalados, así cabe tener en cuenta que se habilita la ejecución vía web del cron. Al darse esta casuística, y para evitar problemas de seguridad, se tienen que definir reglas en el firewall para evitar que cualquier usuario de por internet pueda ejecutarlo.
3. Un tema pendiente, es hacer un borrado asiduamente de los logs que va dejando la ejecución del cron.

La tercera solución es fácilmente implementable cuando tenemos un SGBD diferente a MySQL, ya que simplemente realizaremos un procedimiento en PL que haga la/las llamadas correspondientes. Por el contrario, si tenemos MySQL, como es nuestro caso, no dispone de ninguna utilidad para realizar peticiones HTTP hacia servidores web, a no ser que tengamos la posibilidad de instalar el patch para empotrar lenguajes de programación, y allí si podríamos realizar estas llamadas.

Las principales líneas son:

Integración de Ajax

Ya se han dado los primeros pasos para integrar dicha funcionalidad a la hora de seleccionar los usuarios a los que se les envía un mensaje, pero actualmente tiene unos pequeños fallos, aparte de que falta alguna que otra subfuncionalidad. La idea es hacer que dicha selección sea similar a la que tiene Facebook, ya que la encuentro muy práctica y usable. Desarrollar esta funcionalidad va a llevar bastante trabajo, debido sobretodo a la complejidad de integrar las YUI con los formularios estándar de Moodle, y a su vez dejar una interfaz como la que he mencionado.

La otra parte que se vera afectada es la gestión de carpetas. Aún no tengo muy claro todas las partes, pero, como mínimo.  seguro que afecta a la asignación y cambio de carpeta/s padre.

Revisión de todo el código

Más conocido como Refactoring, va a ser una de las principales tareas, debido a que no se quiere perder la eficiencia conseguida hasta ahora, y a que, muchas funciones han sido modificadas.
También se va a revisar todos los procedimientos para, primero, conseguir independizar totalmente dichos procedimientos a cualquier base de datos (actualmente se tiene constancia de problemas con ciertos SGBD), y segundo, revisar que el conjunto de acciones transaccionales, realmente lo sean, para así evitar ciertos problemas esporádicos que se han detectado.

Revisión y mejora del sistema de búsquedas

Con el fin de mejorar las búsquedas, se tiene que hacer una revisión del sistema actual para así atajar los pequeños errores existentes, así como también ampliar el rango de campos para las búsquedas avanzadas. Con esta revisión, se tiene que hacer un estudio de si la forma actualmente implementada es la más correcta y adecuada. Según el resultado que salga, añadirá algún grado más  complejidad a la realización de esta tarea.

Filtros de los mensajes entrantes

Por enésima vez, se va a intentar implementar dicha funcionalidad. Se intentará que sea lo más intuitiva posible.

Integración con un sistema externo de gestión de correo electrónico

Esta línea es la panacea, pero existe la voluntad de realizar un bridge con algún webmail libre, seguramente Horde.
Inicialmente se implementará la posibilidad de enviar mensajes de correo a cuentas de correo electrónico externas, así como la dualidad (tanto interno como externo). La idea es ofrecer la  funcionalidad para que los usuarios de un curso puedan escribir un mensaje al correo electrónico de los otros participantes del curso, dando la posibilidad de que cada usuario, en sus preferencias, pueda bloquear esta funcionalidad.
Una vez implementada esta primera parte, se empezará a estudiar, diseñar e implementar la segunda parte, siempre respetando los principios básicos de eMail List.

Redefinición de estilos y pantallas

Esta última línea va encaminada a diseñar e implementar un sistema de estilos (CSS) fácil de modificar por los usuarios, que pueda haber tantos como estilos tenga el propio Moodle, y que no tenga dependencias externas.
A la vez, se replanteará la visión general de todas las bandejas de todos los cursos, para así evitar confusiones, y mejorar su comprensión y uso.

Para acabar

Hay muchas más ideas, pero después de revisarlas, se ha optado por las que se han expuesto. Eso no quiere decir que alguna de ellas se amplíe, elimine o modifique, y hasta se añadan de nuevas.

Unos cuantos días antes, y con perspectiva a los nuevos tiempos de eMal, fui incluido como desarrollador oficial de Moodle (pero solo de la parte de eMail).

Los cambios que se han aplicado al correo:

1. Se convierte en Bloque de Moodle, así su instalación o actualización es muchísimo más sencilla.
2. La documentación oficial de eMail cuelga de DocsMoodle.
3. La versión 1.6 de Moodle deja de estar soportada.
4. Gracias a la colaboración de ISU y MoodleRooms ya se ha añadido la posibilidad de imprimir los correos, y pronto se podrá realizar copias de seguridad y restauración.
5. Muy Importante: Estos cambios aún no se han aplicado a ninguna versión definitiva de eMail, SOLO esta disponible para versión latest.
6. El foro de discusión se ha cambiado. Ahora se utiliza el de Contributed modules and plugins,específicamente la discusión llamada eMail plugin – block:email_list.

Actualización punto 6: Hace un par de días han creado un foro dedicado al eMail plugin. Podéis acceder a él mediante el siguiente enlace.

Con este paso, conseguimos que eMail se autoregenere diariamente (si se han aplicado cambios), y todo de forma automática desde Moodle.org. También se puede consultar el CVS de cambios diarios que sufre el código de eMail. Además, en Issue Moodle disponéis de una sección (Email_list) para poner vuestros problemas y peticiones sobre el correo.

Entonces, los usuarios que actualmente ya usáis eMail os quedará la duda, cony! ¿que pasa con mi instalación de eMail?, ¿como afectan estos cambios? etc. No os asustéis, eMail no ha sufrido ningún cambio radical ni nada parecido, y es totalmente compatible con vuestras instalaciones en producción. A modo de FAQ, os voy contando las cosas.

¿Como actualizo a la última versión de eMail?
Primero, tienes que borrar TODOS los ficheros de la versión antigua, y después copia la nueva estructura, hazlo de la siguiente forma:

1. Borra la carpeta email. (moodle/email/)
2. Borra los ficheros de lenguaje (dentro de las carpetas ca_utf8, es_utf8 o en_utf8).
3. Borra la carpeta email_list (moodle/blocks/email_list).
4. Bájate y descomprime la última versión de eMail.
5. Copia la carpeta email_list (eMail/blocks/email_list) dentro de la carpeta de bloques (moodle/blocks/).
6. A disfrutar con eMail

Para ser más explicativos, toda la antigua estructura (email, lang y email_list) se ha movido dentro del bloque email_list, entonces ahora solo basta con copiar o sobrescribir esta carpeta para instalar o actualizar el correo. Así es muchísimo más fácil y sencillo).

Al actualizar, puede que os pida haga alguna actualización en la base de datos, entonces es conveniente que una vez copiada la carpeta, entremos como administrador y pulsamos sobre el enlace de “Notificaciones” del bloque administrador, ya que he detectado que alguna que otra instalación han surgido problemas de actualizaciones no aplicadas.

¿Como instalo el correo?

1. Descargarte y descomprime la última versión.
2. Copia la carpeta email_list (eMail/blocks/email_list) dentro de la carpeta de bloques (moodle/blocks/).
3. Entra como administrador y pulsa sobre el enlace “Notificaciones” del bloque administrador.

En otros artículos más …

Han estat 8 errades de seguretat, algunes d’elles realment molt greus. Les podeu trobar detallades a Moodle Security.
Es molt recomenable que actualitzeu tots els llocs on l’emprau, per així evitar problemes.

A més, també informen d’uns problemes amb el PHPMyAdmin, que també recomanen la seva actualització, si es que l’emprau.

La intenció d’aquest post és el de donar a conèixer el grup i animar-vos a que si sou usuaris, sigui al nivell que sigui (alumnes, professors, desenvolupadors, administradors, etc) us animeu a unir-vos al grup que té un nom molt fàcil “Usuaris de Moodle a les Illes Balears“.

Formato tar.gz:eMail

Formato zip: eMail

Es una versión muy inicial, así que serán bienvenidas todas las aportaciones