Autenticando usuarios de Moodle 1.9 en Adobe Connect 8

Uno de los inconvenientes de la enseñanza online
es la sensación de distancia entre los alumnos y de éstos con profesores y tutores. La mayoría de los LMS (Learning Management Systems) proporcionan un reducido número de herramientas de comunicación síncronas y las típicas, como el chat, dejan mucho que desear a la hora de enriquecer la experiencia formativa. Normalmente se buscan soluciones con herramientas externas a la plataforma, como Messenger, Skype, etc., que se integran con mayor o menor acierto en el LMS de turno.

Una de las herramientas más utilizadas es Adobe Connect. Adobe Connect es una herramienta de web conferencing utilizada muy frecuentemente en ambientes educativos. Además de su función de servidor de conferencia web multipunto, permite la compartición de la pantalla del ordenador del ponente, la visualización de archivos de varios tipos (PDF, Power Point, etc.) , el envío de archivos entre asistentes, dispone de un chat integrado, etc., todo en un entorno muy cómodo construido sobre Flash.

Nuestra experiencia con este software ha sido agridulce... Las posibilidades son enormes, pero hemos tenido problemas al aplicar actualizaciones de Windows o de Connect. En cualquier caso, siempre hemos podido resolverlo.

Después de algún tiempo usando la herramienta de forma puntual hemos decidido dar el siguiente paso: realizar la integración con Moodle para ofrecer Connect de forma más generalizada. En este post explicaré como es el proceso de integración de Moodle y Connect usando el plugin de Remote Learner.

Lo primero, montar nuestro entorno de trabajo

Adobe Connect funciona sobre Windows 2003 Server o superior con MS SQL Server. Como uso linux recurro a VirtualBox para instalar mi servidor Connect de pruebas. Para poder acceder a la máquina virtual de Windows2003 por red usamos "Adaptador puente" en la configuración de red. De esta manera la máquina será accesible por la máquina anfitrión y cualquier otra que se encuentre en la red local. Comprobamos que todo funciona haciendo ping desde la máquina guest hacia la host y al contrario. También podemos comprobar que funciona con otras máquinas de la red local.

Cambiamos el nombre del equipo en la configuración de Windows. Usaremos este nombre al instalar Adobe Connect (hostname). No es mala idea modificar el fichero /etc/hosts de la máquina host y del resto de máquinas que accederán a Connect para evitar fallos de resolución de nombres y hacernos un poco más sencillo todo. Yo la he llamado mini-w2003 y su IP dentro de la red local es 192.168.1.45 así que añado al fichero /etc/hosts la siguiente línea:

192.168.1.45 mini-w2003

Instalar Adobe Connect 8

Descargamos y ejecutamos el instalador de Adobe Connect en la máquina virtual. Este paso quizás sea el más sencillo. Solo hay que seguir las instrucciones del instalador, que acabará abriendo una página de configuración similar a esta:

Comprobamos que Adobe Connect funciona correctamente creando una sala y accediendo a ella y seguimos con la instalación de Moodle.

Instalar y configurar Moodle

Necesitamos un servidor de aplicaciones de tipo Apache+MySQL+PHP, por ejemplo XAMPP, en el que instalamos Moodle. La versión de Moodle que he utilizado es la 1.9.14. Queda pendiente probar con Moodle 2.

Ya tenemos todas las herramientas sobre la mesa. Empezamos el trabajo delicado.

Autenticación de usuarios de Moodle en Adobe Connect usando el módulo

Para la integración he usado el módulo de Remote Learner por ser el más extendido aunque se han desarrollado otros como éste, de la Universitat Rovira i Virgili.

Lo que debemos hacer primero activar la API de WebServices de Adobe Connect. Para ello debemos:

Modificar el archivo [Instalación Connect]\appserv\web\WEB-INF\web.xml. Ojo! la documentación que hay en moodle.org la ruta correspondiente a Connect 7.5 y anteriores.

Debemos descomentar sólo (en la documentación también activan el filtro NtlmAuthenticationFilter), pero esto no es necesario. Copio aquí un extracto del fichero marcando las diferencias con la documentación oficial en Moodle.org:

<filter>

<filter-name>HeaderAuthenticationFilter</filter-name>

<filter-class>com.macromedia.airspeed.servlet.filter.HeaderAuthenticationFilter</filter-class>

<!--

<init-param>

<param-name>ignore-pattern-0</param-name>

<param-value>/api/</param-value>

</init-param>

-->

<init-param>

<param-name>ignore-pattern-1</param-name>

<param-value>/common/</param-value>

</init-param>

<init-param>

<param-name>ignore-pattern-2</param-name>

<param-value>/servlet/gateway/</param-value>

</init-param>

<init-param>

<param-name>ignore-pattern-3</param-name>

<param-value>/servlet/mirror</param-value>

</init-param>

<init-param>

<param-name>ignore-pattern-4</param-name>

<param-value>/servlet/testbuilder</param-value>

</init-param>

<init-param>

<param-name>ignore-pattern-5</param-name>

<param-value>/main</param-value>

</init-param>

</filter>

<filter-mapping>

<filter-name>HeaderAuthenticationFilter</filter-name>

<url-pattern>/*</url-pattern>

</filter-mapping>

</web-app>

Es normal que Connect no consiga arrancar si el fichero el fichero es incorrecto por lo que siempre es recomendable tener copia de seguridad de los archivos web.xml y custom.ini originales. Si después de modificar los archivos y reiniciar los servicios de Connect obtenemos errores de Tomcat al intentar acceder a Connect posiblemente haya algún error en los ficheros que hemos modificado.

También debemos añadir la siguiente línea al fichero [Instalación Connect]\custom.ini

HTTP_AUTH_HEADER=my-user-id

Utilizaremos el valor asignado a HTTP_AUTH_HEADER en la configuración del módulo de Connect en Moodle.

Instalamos el módulo en Moodle descomprimiéndolo en el directorio mod de la instalación entrando como administrador y pulsando en notificaciones para que se inicialicen las estructuras asociadas al módulo.

Acabamos la configuración del módulo abriendo la ventana de configuración del módulo y enlazando con la API de Connect:

Hay que tener especial atención al parámetro Email address login, que controla el nombre de usuario que se usará en Connect. Debemos usar la misma política de nombre de usuario que usa Adobe Connect. En mi caso, como al hacer la instalación de Connect indiqué que se usara el email como nombre de usuario debo marcar esta opción.

Pulsando en el botón "Test connection" el módulo ejecuta varias comprobaciones para verificar la conexión con el servidor de WebMeeting. Debo apuntar que aunque el test se ejecute correctamente puede haber pasos que no se lleguen a realizar. Por ejemplo, en una de nuestras pruebas el módulo conseguía crear la sala y los usuarios en Connect, pero no incluía a los usuarios en la sala recién creada.

Comprobando que todo funciona

Ya tenemos todo listo para crear nuestra primera sala de Connect desde Moodle. El funcionamiento del módulo es similar al de cualquier otra actividad de Moodle. Abrimos un curso, pulsamos en el botón de edición y escogemos "Adobe Connect" en la lista de actividades. Aparecerá una ventana como esta:

Los parámetros de configuración más imortantes son:

• Meeting Title. Es el nombre del recurso en Moodle.
• Meeting URL. El nombre de la sala en Adobe Connect. De manera que si queremos acceder a la sala sin usar Moodle podremos hacerlo usando la dirección http://servidorConnect/meeting-url. Es importante tener en cuenta que este parámetro no puede contener caracteres especiales.
• Meeting Type. El tipo de reunión Connect: pública o privada. En la publica podrá entrar cualquiera que tenga la URL además de los usuarios que Moodle ha registrado. En la privada solo entrarán los usuarios que estén en el curso con el rol correspondiente.
• Meeting Templates. La plantilla en la que queremos basar la sala.

Asignación de roles

Pero ¿qué usuarios entran en la sala? Para controlar el acceso a la sala el módulo crea tres nuevos roles en Moodle: El anfitrión (Adobe Connect Host), el presentador (Adobe Connect Presenter) y el participante (Adobe Connect Participant). Desde la gestión de roles del curso deberemos asignar estos roles para que nuestros usuarios tengan los privilegios adecuados en la sala de Connect.

Me queda pendiente probar el módulo en Moodle v2 y comprobar que los usuarios que acceden a Moodle usando plugins de autenticación (LDAP, p.e.) también son soportados por el módulo.... Pero eso lo dejaré para otra ocasión.

Montando un HP Proliant ML 350

Hoy ha tocado montar un ML 350 G6 con una unidad de cinta Ultrium para las copias de seguridad. La complejidad del trabajo es algo mayor que el de ayer porque esta vez hay que instalar una tarjeta HBA Ultra320 SCSI ya que la unidad Ultrium no se puede conectar directamente a la placa.

Lo primero: abrir la máquina. La apertura es muy similar a la del DL 380. Tiene una especie de palanca en el lateral que desbloquea el panel. Es importante abrir el frontal (puerta) del servidor para poder liberar la palanca. En la imagen tenemos una vista del interior del ML 350.

Pinchamos la tarjeta Ultra 320 en una de las ranuras PCIe del servidor. Las ranuras traseras se liberan desplazando las piezas azules hacia el exterior. Una vez pinchada la tarjeta vemos que no ocupa todo el zócalo. Es normal.

Seguimos instalando el kit de ventilación adicional. En realidad creo que no es necesario ya que como se puede apreciar solamente tiene instalado un procesador y la función de este kit es conducir aumentar el flujo de aire en el procesador adicional y la memoria asociada a éste.

Primero colocamos el ventilador asegurando la parte inferior en las dos muescas del chasis metálico y empujando sobre la superior hasta que suene un clic. El emplazamiento de la carcasa trasparente requiere que apartemos algunos cables y busquemos los puntos de fijación en los que debe encajar.

Instalamos la fuente de alimentación adicional de una forma similar a la del DL 380 y los cuatro discos duros. Para terminar hay que conectar la unidad de cinta. Este paso se nos resiste. Al conectar el cable de alimentación a la parte trasera de la unidad e intentar llevarla a su emplazamiento final nos damos cuenta de que se queda muy justo. Como se ve en la imagen, los cables de alimentación chocan con el chasis, sin duda el único punto negativo que hemos detectado en el diseño de HP.

Montando un HP Proliant DL 380

Hoy hemos recibido un par de máquinas nuevas en el centro. Un servidor "enrackable" DL 380 y otro tipo torre ML 360. En esta entrada mostraré algunas imágenes del interior del DL 380 G6 y como se montan los componentes adicionales que pedimos.

Lo primero, desempaquetar. En la imagen se pueden ver los accesorios de

montaje en rack. El kit de montaje consta de unas guías que se fijan en el rack y unos listones que encajan en ellas de manera que podremos deslizar el servidor fácilmente para sacarlo del armario.

Después de desenvolver todo nos damos cuenta que los discos duros, el lector de DVD y la fuente de alimentación redundante no están instalados así que buscamos todo para montarlo.

Lo más fácil son los discos duros (300GB 10K). Se instalarán 4 discos para montar un RAID 5. La instalación de discos en este tipo de servidores es muy sencilla ya que están preparados para hacer sustitución en caliente ("hot swap"). La controladora de discos se encarga de

toda la gestión de los dispositivos y de la reconstrucción de los grupos RAID si fuese necesario.

El frontal del servidor dispone de 8 ranuras para la instalación de discos. Solo hay que desbloquear la palanca del disco empujando el pulsador rojo, introducir el disco en la ranura hasta que se detenga y después empujar la palanca hasta su posición inicial. Escucharemos un clic que indica que el disco está correctamente insertado.

La unidad de DVD es algo más complicada de montar ya que tenemos que abrir el servidor para hacer las conexiones directamente con la placa base. Este es el interior de un DL 380. En la foto aún no había montado los discos duros.

Hay que retirar la plaquita donde va emplazado el lector del frontal. Lo podemos hacer haciendo palanca con cuidado en el lateral con un destornillador. Después solo hay que deslizar el lector hasta que se siente un clic. El lector queda bloqueado en su receptáculo y ya solo hay que hacer las conexiones.

La unidad de DVD viene con un set de cables para hacer las conexiones dentro del server. Tanto datos como alimentación comparten un único conector. Es importante recoger bien los cables dentro del servidor para que no obstaculice el flujo de aire dentro de la carcasa. La forma correcta sería colocar el cable en la zona inferior, delante de la fila de ventiladores y conducir el cable por el lateral hasta el conector de la placa base.

Por último, la fuente de alimentación redundante. El mecanismo es similar a los discos duros: Se retira la placa protectora y se introduce la fuente de alimentación hasta que encaje en el receptáculo. Debe quedar alineada con la otra fuente.

Y este sería el aspecto final del DL380 montado en el rack.

Ubuntu: arreglar las teclas de cursor en vim / vi

Si estás acostumbrado a utilizar vim en sistemas REDHAT y pasas a Ubuntu puede que te sorprenda el comportamiento de algunas teclas. Por ejemplo, la teclas de cursor hacen aparecer los caracteres D, E,etc., en el documento. También funcionan de manera extraña las teclas inicio/fin y la tecla de backspace.

La solución es bastante fácil. Simplemente hay que indicar a vim que no use el modo compatible usando la orden ":set nocompatible". Si queremos que este comportamiento sea el predeterminado en vim:

• Creamos el archivo .vimrc en nuestro directorio home
• Añadimos la siguiente línea: "set nocompatible"

Cerramos y arrancamos vim de nuevo.

Backup con Data Protector: Estructura del Software e Instalación

Data Protector, como otras soluciones de copia de seguridad, se compone de varios módulos que separan la funcionalidad de la herramienta:

• Cell Manager (CM). Es el componente principal, el más “pesado”. Coordina al resto de componentes y es el único que tiene consciencia de todas las máquinas y dispositivos asociados al sistema de backups.
• Disk Agent (DA). Este agente ha de estar ejecutándose en todas las máquinas que enviarán datos a la copia de seguridad. Es el componente que responde a las llamadas del CM en cada una de las máquinas.
• Media Agent (MA). Responsable de la gestión del dispositivo que de almacenamiento donde seguardarán las copias de seguridad. En nuestro caso una HP MSL2024.
• Installation Server (IS). Componente que se encarga de hacer instalaciones en las distintas máquinas del resto de componentes.
• GUI/JAVAGUI. Podemos instalar una interfaz gráfica para controlar todo el sistema en una o varias maquinas. La verdad es que nos facilitará bastante el trabajo ya que la interfaz “command line” es enorme y bastante compleja (aunque al final siempre necesitas recurrir a ella en ciertos momentos).

La instalación se realiza con la orden:

./omnisetup.sh -cm -is -ma

Indicamos que se instale el Cell Manager, el Installation Server y el Media Agent en la misma máquina.

Hay que tener muy en cuenta que Cell Manager requiere para su instalación un SO de 64bits. Un problema que tuvimos que solucionar reinstalando nuestro REDHAT ya que teníamos un kernel 32bits-PAE. Para el resto de componentes no es necesario, dando bastante flexibilidad a la hora de instalar en distintas plataformas.

Una vez instalado el Installation Server se pueden hacer instalaciones remotas si se indica la IP del cliente y su password siempre que la máquina permita la ejecución remota (rexec-rlogin), no obstante, según el sistema cliente tendremos más o menos problemas para hacer este tipo de instalación. La solución es fácil: instalar con el CD de instalación en cada máquina los componentes deseados y después añadirlos al Cell Manager.

Algo bastante confuso con respecto a la instalación con los Cds es el hecho de que la instalación de la Interfaz Java (javagui) deba hacerse con el CD correspondiente a la versión HP-UX del software. En la versión Linux no se ha incluido este paquete.

La orden instala la gui:

./omnisetup.sh -cc -javagui

Y para las máquinas que enviarán datos a la copia de seguridad en caso de que no se haga la instalación remota usando Installation Server:

./omnisetup.sh -da

Data Protector y GFS2

Primer problema con el software: Informa de un error cuando se intenta incluir en la copia de seguridad una unidad GFS2 montada en el sistema... ¡Pues empezamos bien!

Que malvados estos de HP, GFS2 aparece como sistema de archivos soportado en la documentación, pero si lees la letra pequeña te das cuenta que es mediante un parche que hay que pedir directamente a los ingenieros de HP.

Me pongo en contacto con HP para que me envíe el parche y un amable ingeniero me envía el parche (SSPLNX611_001) que activa el soporte GFS2. Aplicamos el parche y por fin tenemos acceso a la compartición GFS2 que actúa como espacio común de los nodos del cluster.

En esta figura se ve la estructura:

• El servidor con el Cell Manager, Installation Server y Media Agent instalados.
• La unidad de cinta que guarda las copias.
• Tres nodos que comparten un almacenamiento GFS2. Todos ellos con el Disk Agent funcionando, pero tan solo uno de ellos respalda el sistema GFS2.

Dejo aquí el artículo y vuelvo otro día con algunos conceptos sobre copias de seguridad en Data Protector: Los Pools, la programación de copias, etc.