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.
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:
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:
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
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):
Se pretende ampliar la disponibilidad de agentes OGAgent para sistemas operativos macOS, para más distribuciones Linux, etc.
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.
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.
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:
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:
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).
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.
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:
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.