Propuestas de subproyectos de OpenGnsys

En esta página queremos definir futuras funcionalidades de OpenGnsys que son lo bastante modulares para abordarlas como un subproyecto independiente. Esto permite que se realicen separadamente por una o varias personas o incluso como proyectos fin de carrera.

Gestión de particiones GPT y arranque tipo UEFI

El hardware de los equipos nuevos vienen con unas características que no son soportados por OpenGnsys.

Es prioritario comenzar a hacer pruebas y incluir las funcionalidades necesarias en el código.

Algunos aspectos:

• El comando bcdboot configura la partición de arranque EFI para que se pueda arrancar el sistema operativo en la partición de sistema.
• Para el arranque UEFI será necesario que el cliente de OpenGnsys esté firmado. Ya hay imágenes de Ubuntu firmadas que podríamos usar.
• Dar instrucciones para editar el fichero de configuración de DHCP definiendo grupos para equipos UEFI y para equipos BIOS.

Arranque de Windows el cliente ogLive sin reiniciar la máquina

Una vez que hemos entrado en el cliente OpenGnsys, ubuntu 11, este nos ofrece la opción de iniciar sesión en los sistemas operativos que tenga instalado el equipo. Se quiere iniciar sesión en windows sin que haya que reiniciar el equipo.

Actualmente se inician de la siguiente manera:

Linux:

Kexec nos permite arrancar un nuevo kernel desde uno que ya se este ejecutando.

kexec -l "/mnt/sdaN/boot/kernel" --append="root=/dev/sdaN" --initrd="/mnt/sdaN/boot/initrd"
kexec -e

Windows:

No podemos arrancar windows sin reiniciar el equipo.

Utilizamos para el arranque remoto PXE con grub4dos. Permite que el menú de arranque que mandamos al equipo busque si existe un archivo concreto en una partición y si es así la inicia.

Esto nos obliga a realizar varios pasos para arrancar:

• Iniciamos el cliente OpenGnsys.
• Al ejecutar el comando de arrancar:
  • Se crean las marcas (archivos) en la partición que queramos iniciar
  • Reiniciarmos el equipo.
• Al iniciar con pxe:
  • Encuentra la marca (archivo), la modifica e inicia la partición.
• Al arrancar Windows
  • Se tendrán que borrar las marcas.

En las primeras versiones de OpenGnsys, Windows se arrancaba utilizando kexec con grub4dos, dejó de funcionar con los discos sata 2. Se copiaba grub2dos a la partición de windows que quisiéramos iniciar y lo cargabamos con kexec:

cp $SERVIDOR/grub4dos/* /mnt/sda1
kexec -l /mnt/sda1/grub.exe --append=--config-file=root (hd0,0); chainloader (hd0,0)/ntldr; tpm --init 
kexec -e

Sustituir clientes de sistemas operativos por agente basado en API REST

Los servicios ogAdmLnxClient y ogAdmWinClient de OpenGnsys 1.0.x están desarrollados en C/C++ y la comunicación entre ellos y el servidor OpenGnsys es persistente a través de un socket de Linux, por lo que, si existe inestabilidad en la red, cualquier microcorte hace que se desconecte del servidor y bloquee el acceso a la red del sistema operativo.

En la versión 1.1.0 se va a sustituir el agente del sistema operativo por nuevos servicios desarrollados en Python y con una comunicación no persistente a través de una API REST, que servirá de punto de partida para desarrollar agentes para otros sistemas operativos y para los demás servicios (ver siguiente sección):

• Información sobre la API REST: contiene un apartado del agente.
• Máquina virtual con el entorno de desarrollo para el ogAgent

Se pretende ampliar la disponibilidad de agentes OGAgent para sistemas operativos macOS, para más distribuciones Linux, etc.

Sustituir cliente instalado en ogLive por agente basado en API REST

Como en el caso anterior, el servicio ogAdmClient instalado en un cliente ogLive está desarrollados en C y mantiene comunicaciones persistentes mediante sockets sin recuperación de la comunicación. La desconexión del servidor de lugar a que el equipo aparezca en estado apagado en la consola, no permitiendo que se envíen comandos.

El nuevo agente para clientes ogLive debe ser desarrollado a partir del código de los nuevos agentes OGAgent, ampliando sus funciones realizando llamadas a los scripts del motor de clonación.

Sustituir servicios ogAdmServer y ogAdmRepo por una API REST

Como en los 2 casos anteriores, los servicios ogAdmServer y ogAdmRepo desarrollados en C/C++ también mantienen comunicaciones persistentes usando sockets, sin recuperación ante cortes de conexión.

Se desea sustituir estos servicios por una API REST implementada sobre el servicio web, pero debe tenerse en cuenta que algunos mensajes (operaciones) pueden depender de otros en secuencia.

Crear paquetes de instalación de OpenGnsys en formato .deb y .rpm

Por prioridad: Ubuntu/Debian, Fedora/Red Hat/CentOS, SuSE.

Se podrán instalar por separado los servicios del servidor de administración y el repositorio.

OpenGnsys se instala con un shell script de instalación que se ejecuta en bash. Los principales pasos que realiza son:

• Configuración de parámetros del instalador: clave root mysql, usuario OpenGnsys para mysql,…
• Detecta datos del equipo para la instalación: según la distribución crea el listado de dependencias.
• Detecta configuración de red del equipo: ip servidor, mascara de red,...
• Instalación de dependencias (paquetes de sistema operativo).
• Configura servicios: dhcp, apache, tftp, samba, mysql.
• Crea la estructura de directorios de OpenGnsys.
• Copia los archivos de OpenGnsys.
• Compila los servicios OpenGnsys y los configura.
• Copia los archivos de la consola de administración web y la configura.
• Crea documentación para la consola web.
• Crea la base de datos de OpenGnsys para la consola web y el usuario.
• Copia los archivos del cliente.
• Crea el cliente OpenGnsys.
• Muestra un resumen de la instalación.

API de virtualización

Interacción de OpenGnsys con VMware/Xen/KVM para gestionar máquinas virtuales de igual manera que se gestionan los equipos físicos.

De igual manera que existen librerías de OpenGnsys para gestionar los distintos aspectos de un equipo físico necesitaríamos unas funciones que nos permitieran:

• Crear una plantilla de máquina virtual a partir de una imagen de OpenGnsys o de un equipo físico (equivalente a crear imagen desde equipo)
• Crear máquina virtual a partir de plantilla. (equivalente a restaurar)
• Obtener información del estado de la máquina.
• Configuración de la máquina virtual: dispositivos.
• Configuración de la máquina virtual: nombre pc, ip, etc (equivalente a la postconfiguraciñon de un sistema operativo después de restaurar una imagen)

Algunas acciones se lanzarían desde el cliente OpenGnsys sobre la máquina virtual (obtener estado máquina) y otras directamente desde la consola de administración (conversión de imagen de OpenGnsys a plantilla de imágenes virtuales).

Inventario compatible con OCS/GLPI

Estudiar la forma de almacenar/exportar los inventarios de hardware y software de los equipos para que sean compatibles con GLPI, usando OCS Inventory en el cliente ogLive o bien creando una slida adecuada.

Autodetección de clientes incorporados a la red

Broker de conexiones propio de OGN

Aprovechando las funcionalidades que ofrece la API REST crear nuestro propio broker de acceso a los recursos que gestiona OGN con las funcionalidades básicas.

El broker podría realizar las siguientes tareas:

• Validar a los usuarios autorizados a acceder al sistema. Inicialmente podría configurarse mediante autenticación LDAP parametrizada con la configuración particular de cada universidad.
• Listar unidades organizativas (/ous). En este punto el sistema podría validar permisos de acceso a unidades organizativas en función de los datos de usuario recibidos del LDAP (p.e. los usuarios de una titulación o centro solo pueden acceder a su ou)
• Mostrar información de la ou (/ous/:id1)
• Listar las aulas de la ou escogida (/ous/:id1/labs) y mostrar información de cada una (/ous/:id1/labs/:id2)
• Escoger un aula y listar máquinas disponibles (/ous/:id1/labs/:id2/clients/:id3/status) incluyendo las imágenes asociadas
• Si se desea acceder a una máquina lanzar la petición (/ous/:id1/images/:id2/reserve o /ous/:id1/images/:id2/reserve?lab=:id3)
• Esperar a recibir la respuesta del agente informando del estado de la máquina una vez ha arrancado (/ous/:id1/labs/:labid/clients/:clntid/events) y (/ogagent/started)
• Conectar mediante RDP u otro protocolo a la IP de la máquina. Estudiar opciones
• Controlar la sesión mediante la comunicación con el agente ( ​https://Cliente:8000/opengnsys/...) y (/ous/:id1/labs/:labid/clients/:clntid/events)
• Si existe timing de reserva enviar aviso y apagar la máquina (/ous/:id1/labs/:labid/clients/:clntid/unreserve)

Si se instala el broker en el mismo servidor de administración de OGN no serían necesarias las funciones de intermediación de Remote PC y se podrían utilizar tanto las funciones REST como propias de OGN para interactuar con los clientes.