wiki:Reunion160618

Version 3 (modified by irina, 4 months ago) (diff)

--

Acta de la Videoconferencia del 26 de junio de 2018

Asistentes: Zaragoza, Teruel, Málaga Huelva y Sevilla

Lista de necesidades y deseos

En las Jornadas de Málaga se realizó entre los asistentes una lista de nuevas funcionalidades de OpenGnsys que se consideran necesarias en un plazo menor o mayor.

Pasamos a revisarlas para ver cómo se les da cabida en el proyecto:

Documentación de comandos

La documentación de las funciones se está realizando con doxigen, que permite obtenerla automáticamente tratando el comentario que se pone delante de las mismas.

1) En las primeras versiones se seguía mejor el formato que necesita doxigen, pero en las últimas versiones existen fallos y no se muestra correctamente.

Revisar las sintaxis de los comentarios y incluso el código de las de las funciones.
Crear unos ejemplos de buenas prácticas para el uso de doxigen.

2) Ver si existe una nueva versión que sea más compatible con bash.

Otra opción sería cambiar de programa de autodocumentación (ej: bashdoc), el problema es que habría que revisar todo el código.

3) Actualmente la documentación se genera en la instalación, lo que requiere instalar doxigen y alguna dependencia. Se plantea la posibilidad de generarla al liberar la versión y que al instalar simplemente se baje la documentación.

Cuando existe un paquete debian podría guardarse dentro del paquete, ahora que la instalación se realiza con un script no hay lugar donde guardarla.
Cuando se actualiza en una versión de desarrollo la documentación va cambiando y no podría generarse por anticipado.

4) No se está generando la documentación de los script.

Habría que incluirlos en la configuración del doxigen para que los procese: los del cliente y los del servidor.
Habría que revisar los comentarios de los script para que cumplan el formato.

Se creará un ticket para este tema. La pestaña ayuda de la consola se cambiará, de forma que incluya:

  • La documentación de doxigen.
  • El manual de usuario.
  • El apartado "a cerca de".
  • Contenido del engine.cfg (sólo lectura).

Cuando al clonar usando la cache no hay espacio en la misma, no tirar por UNICAST directamente

Cuando se restaura un aula y no hay espacio en cache se realiza la acción definida en la variable RESTOREPROTOCOLNOTCACHE de engine.cfg.

Por defecto el valor de está variable es UNICAST lo que da lugar a un problema saturación en el servidor haciendo que el aula tarde mucho en restaurarse.

Se pondrá el valor por defecto a NONE con lo que los equipos acabarán la operación con error y permitirá elegir si queremos hacerlo por UNICAST o vaciar antes la cache.

Página de bienvenida

Se podría aprovechar para poner mensajes para a los usuarios:

  • "Tip" del día.
  • Registro de la lista de correo de usuarios.
  • Recetas de distintos usuarios.
  • Trucos, ...

La lista de correo tiene pocas personas apuntadas, habría que darle publicidad.

Borrar cache

Había dos propuestas:

  • Ofrecer la posibilidad de limpiar la cache.
  • Al borrar imágenes de la cache, permitir seleccionar más de un a la vez.

En la misma página de borrar imágenes se podría incluir un botón que formatee la cache.

Al formatear se incluye el kernel y el initrd en la cache.

El seleccionar varias imágenes para borrar a la vez es un poco complejo debido a la forma en que se realiza.

Consola web

La consola nueva y la actual pueden convivir.

Por ahora sigue siendo necesaria la consola actual para comunicarse con el ogAdmClient, cuando se cambie el agente en el ogLive se podrá prescindir de ella.

El script de instalación está casi terminado, la parte de Angular está completa y para la de Symfony falta poco.

Transición de la consola actual a la nueva:

  • Al instalar se instalarán las dos consolas.
  • Se modifica en /client/etc/init/default.sh para que se utilice la consola nueva.
  • La consola nueva no puede escribir datos en la actual, por lo que primero habría que incluir los equipos en la consola actual (para el uso del ogAdmClient) y luego migrar los datos a la nueva. A partir de entonces sólo es necesario utilizar la consola nueva.

Se podría incluir en las propiedades del aula qué consola se está utilizando.

Instalación del servicio de repositorio de manera independiente sin incluir el resto de los módulos

Cada universidad trabaja con los servidores estructurados de forma diferente. Como ejemplo citamos dos diferentes:

En Málaga:

  • Cada centro tiene un servidor OpenGnsys completo, con su repositorio y su server.
  • Además hay un servidor OpenGnsys central como respaldo que puede usarse desde cualquier aula.
  • También existen centros que confían entre ellos.

En Zaragoza y Teruel:

  • Hay repositorios tontos sin web ni dhcp.
  • Hay servidor central en alta disponibilidad que controla los distintos repositorios.

Hacer la información de la separación de servicios en el repo, el server y la parte común que tenemos actualmente para tomarla como punto de partida y revisar si es lo que queremos.

Para la instalación se crearán distintos paquetes: común, servidor de administración y repositorio.

Gestión encendido y apagado de cañones de video

Algunos cañones de vídeo aceptan el protocolo pjlink que permite comunicarse con el cañón a través de una API.

Ya hay un ticket creado para integrar en la consola está funcionalidad.

Permitiría desde la consola de OpenGnsys saber el estado del proyector, las horas de la lámpara, encenderlo y apagarlo.

Se ha incluido en las propiedades del aula la opción de dar da alta un proyector. Permite varios tipos, si es pjlink permitirá poner la IP del mismo.

Hay que ver si es interesante asociar el proyector sólo al aula o también a un equipo (ej: el de profesor) para que pueda gestionarlo desde el pc.

Geolocalizar las descargas de OpenGnsys (awstats)

Sería interesante saber desde dónde se realizan las descargas de OpenGnsys para tener información de quién lo utiliza.

Como ahora el código está en GitHub se mirará si tienen está información.

RemotePC gratuito

La funcionalidad de remotePc surge de la colaboración de UDS con OpenGnsys.

Para tener remotePc gratuito es necesario utilizar un broker de software libre gratuito.

Si alguna universidad está usando un broker de este tipo, se podría colaborar para que se comunique con la API de OpenGnsys para remotePc. Pudiendo modificar algunos aspectos de OpenGnsys para que fuera compatible.

Imágenes sincronizadas

Granada ha presentado en las Jornadas de Málaga unas imágenes sincronizadas realizadas con git.

Nos hemos puesto en contacto para colaborar en la integración de está propuesta de sincronizadas en OpenGnsys.

Agente para ogLive y nueva consola

Se está modificando el ogAgent para poderlo utilizar en el ogLive.

Ya realiza el inventario de hardware y de software. Al terminar el comando envía al servidor que ha finalizado.

Hay que decidir de qué manera queremos enviar los parámetros al cliente. Por ejemplo:

  • En la url: .../software/$DISCO/$PART
  • Por get: .../software?disco=$DISCO&part=$PART
  • Por post: {disco=$DISCO, part=$PART} .../software

La consola nueva está enviando los parámetros por post, el cliente los aceptará de esa forma.

Cuando la consola nueva envía una tarea al cliente realiza varios pasos:

  • Incluye la tarea en la base de datos, obteniendo un id de la misma.
  • Envía al cliente el comando ejecutar_script con los parámetros por post: idtarea, script, url_resultado.
  • Al terminar la tarea el cliente devuelve: idtarea, salida, salida de error, código de salida.

Para la url_resultado, url donde debe devolver el resultado del script, no se utiliza una fija para que sea más flexible.

El agente nuevo ejecutará el script con permiso de root.

Actualmente el ogAdmClient lanza el browser que llama a la página de inicio del cliente.

Hay que decidir si va a ser el ogAgent quién lance el browser.