Acta videoconferencia 15 octubre de 2019

Asisten: Valencia, Málaga, Teruel y Sevilla
Próxima reunión: Miércoles 30 de octubre.

Últimos cambios v 1.1.1

Ramas de desarrollo

Las ramas de pjlink y configfile se adelantan con los cambios de la rama devel.

Tokent de seguridad

Los token de seguridad para la comunicación https están situados en los fichero ogAdmServer.cfg y ogAdmRepo.cfg. La consola utiliza los del ogAdmRepo.cfg y el ogAdmServer los de ogAdmServer.cfg

Se modificará el ogAdmServer para que tome los del fichero ogAdmRepo.cfg.

Wol

La función 'reserve' de la API REST solicita el envío los paquetes para levantar a los equipos tanto al server y como al repositorio.

#931 Fallo en el inventario Software

Al enviar el comando desde la consola el ogAdmServer no recibía los parámetros necesarios. Ya está corregido.

También existe un problema de saturación del mysql por la inclusión de software en la base de datos, esto sigue sin modificarse.

REST API for ogAdmServer

Se está modificando el ogAdmServer y la consola para que la comunicación entre ellos sea a través de una API REST. Está muy avanzado.

La nueva versión se instalará en Cádiz la semana que viene. Antes de ello se moverá la rama devel a master para probar también la nueva forma de instalar desde git.

Próxima versión: ogAgent

La consola y el ogAdmServer se comunican con el ogAdmClient para solicitar información al equipo o pedirle que realice una acción. La próxima versión nos centraremos en sustituir el ogAdmClient del ogLive por el ogAgent.

Sería un paso intermedio entre la versión actual y la de la nueva consola.

Ahora la rama de la nueva consola usa un ogAgent con API REST en vez del ogAdmClient, de forma que tiene algunos cambios para la nueva funcionalidad.

Habría un salto en la instalación de los ogLive: ahora el ogAdmClient es compartido por samba en el servidor, en adelante tendrá que instalarse el paquete del ogAgent al generar el ogLive.

Se tendría que mantener el ogAdmClient hasta que el cambio del ogAdmServer y la consola fueran completos. Por lo que puede que haya algunas versiones donde coexistan los dos.

• El agente es el mismo que el de los sistemas operativos al que se añadirían opciones específicas. Se genera en otro directorio porque no necesita la parte del usuario que contiene 'qt' y aumenta mucho el tamaño del agente.

• Si estando en un sistema operativo recibiera la solicitud de un comando de OpenGnsys tendría que devolver un mensaje informando que la función no está disponible en ese estado.

La comunicación vía API REST nos permitirái nuevas funcionalidades:

• Se podría matar un comando en ejecución. En el estado del cliente se pueden mostrar el conjunto de procesos que se están realizando y permitir pararlos.
• El estado del equipo podría devolver más información. ahora sólo nos dice en qué sistema operativo está arrancado y si se ha conectado un usuario. Se podría ampliar la información con la versión del s.o., en nombre del usuario, la carga del sistema, la duración de la sesión actual, etc.

Se podría realizar una reunión presencial sobre el desarrollo del ogAgent. De forma haya más personas que puedan modificarlo y generarlo.

• Hay que definir el paso de mensaje y el formato de los mismos.

• También es necesario definir bien la API REST, ahora tenemos varios la del repositorio, la del server la del ogAgent y la del nuevo ogAdmServer.

El ogAgent de está versión está terminado salo el número de versión en Windows, que no lo toma correctamente.

Pruebas en Málaga

Se está probando la nueva versión con nuevos portatiles y equipos UEFI.

Van a llegar nuevo hardware a distintos centros, si hubiera problemas se pasarán al OpenGnsys central con la nueva versión y los problemas se resolverán en él.

Pruebas con UEFI en Teruel

La versión nueva de Windows 1.9.03 cambia el orden de las particiones:

• partición 1: partición de recuperación
• partición 2: partición EFI
• partición 3: partición reservada de Windows
• partición 4: partición de sistema.

OpenGnsys está preparado para que la partición EFI sea la primera. El estandar te permite que la partición sea cualquiera, pero Windows hasta está versión lo situaba en la partición 1.

• Las funciones de crear y restaurar imagen detecta cual es la parción EFI, por lo que no da error.

• La plantilla PXE de rEFInd busca la configuración en la partición 1. Hay que documentar que si los equipos tiene la partición EFI en otra deben personalizar la plantilla.

• El asistente de particionado si es GPT obliga a que la primera partición sea EFI.

La función ogCopyEfiBootLoader, que se utiliza al crear la imagen para copiar la carpeta del cargador de la partición EFI a la de sistema, busca los distintos cargadores según el sistema operativo. Busca primero si existe la carpeta 'Microsoft' que existe en un sistema recién instalado y luego la de la partición. si existen las dos consideramos que la corracta es la del número de partición haremos al cambio en la función.

Problemas conocidos

Habría que resolverlos antes de sacar la versión:

• El servicio ogAdmServer no separa correctamente al utilizar service opengnsys stop (o systemctl ...)
• Asistente de deploy. conviene revisar también los demás.
• Inventario de software satura mysql
• Al restaurar la imagen si no cabe en cache se sale con error pero guarda la configuración en la base de datos.