Context Navigation

Changes between Version 1 and Version 2 of Reunion090720

Timestamp:: Jul 10, 2020, 1:34:36 PM (4 years ago)
Author:: irina
Comment:: --

Legend:

: Unmodified
: Added
: Removed
: Modified

Reunion090720

-                      v1
+                      v2
 [[PageOutline(2-5,Índice)]]
-= En construcción =
 = Acta videoconferencia 9 de julio de 2020 =
 …
 Asisten: Málaga, Valencia, Teruel, Zaragoza y Sevilla. \\
 Proxima reunión: por determinar en unos 15 días.
+Próxima reunión: por determinar en unos 15 días.
 == Contratación del soporte con Soleta ==
 …
  * Desarrollo para introducir alguna funcionalidad
  * Mixto
 Por ahora Sevilla, Cadíz tienen contratado el soporte con ellos desde hace varios años.
+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 con ldap es mejor UDS
+ * 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 ===
+La semana que viene habrá una videosesión con UDS y las distintas universidades que usan remotePC.  Por nuestra parte podría ser el jueves que viene.
+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...
+ * poder gestionar equipos /mantenimiento
+=== Equipos MAC ===
+ * num máximo para prestar en remoto debe variar, y solicitarse a OG.
+ * Ordenador asignado a UDS antes de darselo a un alumno, hay que comprobar que no es está usando.
+Al haber una agente de OpenGnsys para equipos MAC se plantéa cómo acceder a ellos con remotePC.
+En las aulas habrá que identificar los equipos para que los estudiantes no cojan equipos que estén en remoto: Carteles...
+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.
-Posiblemente los cambios serán mayormente en OG y no en UDS.
 Política de los equipos en Windows para impedir que apagen el equipo y que se cierre automáticamente.
+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.
+Sevilla Teruel
+-> crear aula de mantenimiento y se mueve el equipo
+Entornos mixtos.
+ - marcar pc en mantenimiento.
+ - el acceso eléctronico definido por equipo, no por aula. Aunque aparezca en la zona de propiedades para cambiarlo de forma masiva.
+Habŕia que cambiar la función reserve de OG, poo en UDS
+Cambio en UDS el número de equipos disponibles.
+Cuando un equipo se vaya a asignar para presencial hay que quitarlo de la cache de UDS
+____________
+Cuándo se modifica la configuración de las aulas que compartimos. Cuando tarde UDS en enterarse de esa información.
+        Parce que hay que republicar de nuevo para que actualice los datos.
+        Los que estén ya reservados para acceso remoto, podrían quedarse colado en el campo.
+Puede que OG tenga que decirle a UDS cuando un equipo pasa a presencial, par qe lo quete de la cache.
+        -> y pida la reserva en otro equipo.
+=== Equipos MAC ===
+Para que esto sea posible:
+ *  Que UDS proporcione un transporte compatible con MAC. Creemos existe.
+ *  Es necesario implementar las parte de usuario en el ogAgent para MAC.
+El ogAgent para MAC sólo tiene la parte del agente de root, para uds hace falta la parte de usuario.
+ Es necesario la librería qt 4 para ello.
+ Hay que implementar la parte de usuario y ver si funciona y ver como sería la conectividad desde UDS.
+Esto mejorarñia la gestión de los equipos MAC con OpenGnsys, podría enviar comando 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 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.
+   * 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.
 …
  Hay que mejorar el manejo de errores del script de crear imagen.
 Sería necesario que lo probará alguien más.
+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 de partclone ==
+=== 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.
+ogLive que pudiera tener las dos versiones de partclone.
+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
+ - oglive 4.8. partclone 0.2.8 cogio los binarios de particlone y los copio al ogLive de la 5.
+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 debes traer mejoras
+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'.
+ - el ogLive bionic trae la x.11
+ - La última versión es la 0.3.15 ->
+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.
-ubuntu 20 trae el partclone 3.13.
-changelogs - release of partclone 0.3.11
-This release(unstable) we update:
-this release we update:
-    dd issue
-    xfs
-    exfat
-    bt for clonezilla
 == Problemas con el script de actualización ==
-A partir de una version de mysql no soporta
 Parecía que estaba arreglado, pero ha vuelto a fallar. No muestra el menú de opciones y directamente actualiza a la 1.2.
+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 puede elegir una versión.
+  * Podría preguntar siempre antes de actualizar, aunque sólo se pueda elegir una versión.
+Se hace el cambio en el script de actualización.
+ -> puee que se le escape algún campo que no se ha considerado.
+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.
+== ogAgent para Ubuntu 20.04 ==
+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.
 Sevilla. Ubuntu 20 04 se va a probar
+Se revisará el estado de la base de datos después de la actualización para busca los campos incorrectos.
+ * Agente con qt5 . funciona bien Linux
+== Nuevo ogAgent ==
+ * pero no se consigue instalarlo en Windos. Cambian las librerías visual c. Ahora visual studio build tools -> puede que haya que generarlo en Windows
+En Sevilla se está probando Ubuntu 20 04.
+Incluye el estado extendido. Carga sistema, número de usuarios conectados, versión del agente, etc
+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
+En la consola al pinchar en el ordenador se podría poner el estado extendido. Haciendo una consulta en tiempo real.
+Incluye el estado extendido: carga sistema, número de usuarios conectados, versión del agente, etc
+Se podría tener un procedimiento para que se actualice el agente.
+ * 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.