Acta videoconferencia 9 de julio de 2020

Asisten: Málaga, Valencia, Teruel, Zaragoza y Sevilla.
Próxima reunión: por determinar en unos 15 días.

Contratación del soporte con Soleta

Algunas universidades se están planteando contratar el soporte de OpenGnsys con Soleta. Existen varias modalidades.

• Soporte para problemas en el funcionamiento.
• Desarrollo para introducir alguna funcionalidad
• Mixto

Por ahora Sevilla y Cádiz tienen contratado el soporte con ellos desde hace varios años.

Salamanca está en proceso de contratarlo.

Acceso remoto

La semana que viene habrá una videosesión con UDS y las distintas universidades que usan remotePC.

OpenRlads vs UDS

Teruel utiliza actualmente OpenRlads, un broker de desarrollo propio que está muy bien para entornos pequeños.

• Para una infraestructira más grande, por ejemplo con la autenticación contra ldap es mejor UDS.
• Para implantarlo en toda la Universidad de Zaragoza necesita UDS. Se ha comprado y se está configurando para el curso que viene.

Entornos mixtos presencial - remoto

Este tipo de entorno va a necesitar que las definiciones de remotePC sean más granulares, a nivel de equipo y no sólo de aula, y dinámicas, consultando el estado real del equipo antes de operar con él.

Actualmente para solucionar estos problemas se crea un aula ficticia y se mueve a ella los equipos que queremos excluir de remotePC. La gestión es "aparatosa" y cuando un equipo está en el aula ficticia no tenemos información de cuál es el aula a la que hay que devolverlo.

Situaciones que hay que resolver. Las dividimos según quién inicia la comunicación:

• UDS solicita información a OpenGnsys:
  • Consultar a OpenGnsys el número máximo de equipos disponibles, ya que puede variar según los equipos que están usándose en presencial.
  • Comprobar el estado de un ordenador antes de utilizarlo para la cache o asignarlo a un alumno.

• OpenGnsys informa a UDS de un cambio:
  • Poder incluir/excluir equipos de remotePC, para realizar mantenimiento o usar de forma presencial. UDS tendrá que lo quitarlo de la cache de UDS y pedir la reserva en otro equipo.

Se comentan dos vías para solucionar el problema.

• Marcar pc en mantenimiento.
• El acceso remoto definido por equipo, no por aula. Aunque puede mostrarse en las propiedades del aula en la zona para modificar ordenadores de forma masiva.

Posiblemente los cambios serán mayormente en OG y no en UDS.

• Habría que cambiar la función reserve de OG.

Actualización de la información de UDS

No sabemos cuanto tarde UDS en enterarse cuando se modifica la configuración de las aulas que compartimos.

• Parece que hay que republicar de nuevo para que actualice los datos.
• Los que estén ya reservados para acceso remoto, podrían quedarse colgados en la cache.

Por otro lado, en las aulas habrá que identificar los equipos de acceso remoto para que los estudiantes no los utilicen: Carteles...

Equipos MAC

Al haber una agente de OpenGnsys para equipos MAC se plantéa cómo acceder a ellos con remotePC.

Para que esto sea posible es necesario:

• Que UDS proporcione un transporte compatible con MAC. Creemos existe.
• Implementar la parte de usuario en el ogAgent para MAC, ya que hasta ahora sólo tiene la parte de 'root' Para ello es necesario la librería qt 4.

Esto mejoraría la gestión de los equipos MAC con OpenGnsys, desde la consola se podrían enviar comandos y mensajes. Hasta ahora sólo podemos ver el estado, reiniciar y apagar.

Problemas con partclone

Errores con Windows 10

Windows 10 20.04 falla con partclone 0.3.11 el anterior sí va bien.

• Como solución temporal se puede crear con la versión anterior, y restaurarla con la nueva.
• No es de la API de OpenGnsys. Lanzando el comando de partclone, falla igual.
• Parecía que el parámetro "-I" de partclone resolvía el error. Pero en este caso tampoco va.

Las pruebas se habían hecho con Windos 19.04 actualizada a 20.04. Instalada desde cero la 20.04 sí se clona bien.

El script de crear imagen no muestra el error.

• Hay que mirar bien el log del histórico para comprobarlo.
• El problema se detecta al restaurar.

Hay que mejorar el manejo de errores del script de crear imagen.

Sería necesario que lo probará alguien más, para saber si el problema es general de esa versión de Windows o de la imagen concreta que se está clonando.

Problema entre versiones

Ya se habían detectado problemas entre las distintas versiones de partclone, de forma que las imágenes creadas con la última versión 3.11 (ogLive bionic) no se podían restaurar con la anterior.

En Málaga se estaba probando que un ogLive pudiera tener las dos versiones de partclone. Para las primeras pruebas se copiaron los binarios del partclone 0.2.8 del ogLive 4.8. al ogLive 5.0

Hay que valorar si nos interesa tener un ogLive con las dos versiones de partclone o tener instalada sólo la 0.2.8

La nueva versiones debe traer mejoras:

• Habría que probar si mejora los tiempo de creación y restauración.
• Según la página del proyecto los cambio son para los sistemas de fichero xfs, exfat y algún uso del 'dd'.

Ubuntu 20 trae el partclone 3.13.

• También podría probarse.
• Para crear un ogLive partiendo de está distribución es necesario hacer algunas modificaciones en el script de creación del ogLive.

Problemas con el script de actualización

Al ejecutar el script debe mostrar un menú con las distintas versiones de OpenGnsys superiores a la que está instalada. Sin embargo no muestra el menú de opciones y directamente actualiza a la 1.2.

• Puede que no encuentre la versión de OpenGnsys, en ese caso actualiza al master.
  • Es el comportamiento que ha tenido siempre. Pero antes el master era estable.
• Podría preguntar siempre antes de actualizar, aunque sólo se pueda elegir una versión.

Al actualizar desde la versión 1.1.0 con Ubuntu 16 a la 1.1.1c en la base de datos se quedan algunos campos con valor por defecto NULL, esta definición no se soporta por la versión de mysql dando problemas en la consola.

Se revisa que el cambio se hace en el script de actualización.

• Consulta la estructura de las tablas de la base de datos y modifica los campos con valores por defecto incorrectos.
• Según el tipo de campo se le asigna un valor por defecto u otro. Puede que se le escape algún tipo de campo que no se ha considerado.

Se revisará el estado de la base de datos después de la actualización para busca los campos incorrectos.

Nuevo ogAgent

En Sevilla se está probando Ubuntu 20 04.

Se ha creado un agente nuevo con python 3 y qt5:

• Funciona bien en Linux.
• No se consigue instalar en Windos.
  • Cambian las librerías que utiliza, antes eran visual c y ahora visual studio build tools
  • Puede que haya que generarlo en Windows

Incluye el estado extendido: carga sistema, número de usuarios conectados, versión del agente, etc

• En la consola al pinchar en el ordenador se podría mostrar el estado extendido. Haciendo una consulta en tiempo real.
• Al tener la información de la versión se podría tener un procedimiento para que se actualice el agente.