Licencia

Copyright (C)  2022  Soleta Networks
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.

https://www.gnu.org/licenses/fdl-1.3.txt

1. Introducción a OpenGnsys

Esta introducción a OpenGnsys explica qué es OpenGnsys como proyecto y para qué sirve. También se aclara la existencia de OpenGnsys Enterprise y su aporte al proyecto, donde se hace un repaso de la arquitectura y componentes.

1.1. ¿Qué es OpenGnsys?

OpenGnsys es un software de código abierto para la clonación y gestión de equipos de escritorio en entornos virtuales y "bare metal". OpenGnsys proporciona un panel de control centralizado que permite a los administradores de sistemas desplegar imágenes de sistemas operativos de manera masiva.

OpenGnsys incluye una solución para el arranque de los equipos mediante Wake-on-LAN (WoL) y la descarga de un sistema operativo "live" (que se carga en memoria RAM) mediante PXE y TFTP que permite la realización de tareas administrativas sobre los equipos de escritorio de manera remota.

1.2. ¿Qué incluye OpenGnsys Enterprise?

OpenGnsys Enterprise proporciona un entorno listo para producción que incluye las últimas características y correcciones de errores para OpenGnsys. OpenGnsys Enterprise simplifica el despliegue de OpenGnsys y ayuda a mantenerlo actualizado de forma incremental gracias al uso del gestor de paquetes APT.

1.2.1. Arquitectura y componentes en OpenGnsys Enterprise

image

La arquitectura de OpenGnsys Enterprise concentra la gestión de las comunicaciones en un servidor principal, intermediario entre los usuarios y los equipos a gestionar.

ogServer es el servidor principal de OpenGnsys Enterprise. Expone una API REST HTTP para su integración con los distintos front-ends. También establece un canal de comunicación con los clientes. Se encarga de gestionar todas las comunicaciones con la base de datos.

Las operaciones sobre la base de datos pasan a ser única responsabilidad del ogServer. Al iniciar ogServer se comprueba la versión de la BD y se aplican los cambios necesarios en caso de no estar actualizada. No es necesario el mantenimiento por separado de ficheros SQL con diferencias entre versiones.

Los usuarios pueden usar diferentes interfaces gracias a que ogServer expone su funcionalidad mediante una API REST HTTP. Esto también permite que una misma interfaz se pueda conectar a varios ogServers. La distribución del servidor en varios puntos de conexión evita que un fallo en un servidor pueda dejar inoperativa a toda una institución.

ogLive es una distribución Linux usada en OpenGnsys en el arranque por red (PXE). Se ejecuta en la memoria RAM por lo que permite la ejecución de tareas administrativas sobre los discos de los clientes (particionar, formatear, clonar y restaurar).

ogClient es un demonio que se ejecuta en los clientes para su control. Se comunica con el ogServer y soporta Linux y Windows. Se encarga de ejecutar las tareas administrativas sobre los clientes y reportar su estado de vuelta al servidor.

ogCP es una interfaz web (front-end). Está escrito usando el framework web Flask, que destaca por su simpleza y flexibilidad. Soporta la comunicación con múltiples ogServer, unificando toda la información y capacidad de gestión en un único panel administrativo.

ogCLI se ofrece como interfaz alternativa a la web, permite realizar tareas administrativas desde una terminal y aumenta la programabilidad del entorno. Posibilita la creación de scripts personalizados, por ejemplo para su ejecución desatendida. Su salida por pantalla es JSON válido que puede ser consumido por otras aplicaciones y puede servir como punto de partida para programar tareas administrativas más complejas.

tiptorrent es un nuevo método de transferencia distribuido que se desarrolla para solventar los errores y limitaciones existentes con multicast y BitTorrent. Al contrario que Multicast, tiptorrent es unicast, facilitando su uso sin requerir una configuración previa de la infraestructura de red. El método de distribución es más sencillo que el enfoque P2P puro que usa BitTorrent gracias a que es un servidor principal el que se encarga de orquestar como los clientes comparten las imagenes entre ellos.

python-libfdisk un proyecto que provee bindings de la biblioteca libfdisk para Python. Permite trabajar con la biblioteca libfdisk directamente desde Python. Mejora la integración con Python, exponiendo la biblioteca y sus estructuras dentro de Python como clases y métodos. Es una mejora frente a la invocación de subprocesos de aplicaciones que utilizan dicha biblioteca. Además, python-libfdisk puede ser usado fuera del entorno de OpenGnsys.

2. Instalación y actualización de OpenGnsys Enterprise

Recomendaciones, requisitos, y pasos para la instalación y actualización de OpenGnsys.

2.1. Recomendaciones previas a la instalación de OpenGnsys Enterprise

Las siguientes recomendaciones sirven para disponer de un entorno más profesional y adecuado sobre el que desplegar OpenGnsys Enterprise.

2.1.1. Virtualización: QEMU, KVM y LibVirt

Recomendamos la instalación del servidor de OpenGnsys en un entorno virtualizados basados en las tecnologías Open Source Libvirt/QEMU/KVM junto con técnicas modernas y maduras de paravirtualización VirtIO para aceleración de la Entrada/Salida por software. Libvirt/QEMU/KVM ofrece una alternativa OpenSource robusta y fiable a las tecnologías de virtualización no libres.

Libvirt ofrece un front-end gráfico y de línea de comandos de fácil uso que facilita la interacción con el software de máquina virtual QEMU sobre el que se despliega. KVM provee la aceleración de las máquinas virtuales por hardware.

El despliegue del servidor de OpenGnsys en un entorno virtualizado trae consigo beneficios importantes:

  • Realización de "snapshots" de las máquinas virtuales. Permite copias de seguridad en caliente,con la VM encendida, y en frio, con la VM apagada.

  • Migraciones de la máquina virtual a un nuevo hardware cuando esté disponible sin tener que instalar de nuevo el servidor de OpenGnsys.

  • Creación de una segunda máquina virtual de preproducción para el despliegue inicial de actualizaciones de OpenGnsys sobre una serie de aulas de pruebas para validar la correcta operatividad antes de la puesta en producción.

2.2. Requisitos de OpenGnsys Enterprise

A continuación se listan los requisitos indispensables para poder instalar y desplegar OpenGnsys Enterprise.

2.2.1. Sistema Operativo: Ubuntu 20.04

El servidor de OpenGnsys Enterprise requiere Ubuntu 20.04 LTS (Focal) para su despliegue.

2.3. Instalación de OpenGnsys Enterprise

La instalación y puesta a punto de OpenGnsys Enterprise se realiza a través de un instalador ofrecido en la web de OpenGnsys Enterprise. El instalador hace uso de los paquetes .deb creados por Soleta Networks.

Una vez descargado el instalador de la web de OpenGnsys Enterprise (https://opengnsys.soleta.eu/download) procederemos a su ejecución:

$ wget https://opengnsys.soleta.eu/installer.sh
# bash installer.sh

El script de instalación solicita al usuario:

  • Usuario y contraseña del administrador de OpenGnsys

  • Contraseña del servidor de SAMBA

  • Interfaz de red del servidor de OpenGnsys

  • Dirección IP del servidor de OpenGnsys

Solicitud de usuario y contraseña de ogCP durante la ejecución del instalador
Specify your ogCP user name:
Specify your ogCP password:
Solicitud de usuario y contraseña de web de administración "legacy"
Specify your legacy web console user name:
Specify your legacy web console password:
Solicitud de configuración del servidor de SAMBA
Specify password for your SAMBA server:

A continuación se solicita la interfaz de red del servidor de OpenGnsys, se muestra un listado con las interfaces disponibles en el sistema, en el ejemplo se muestra la interfaz ens3 está disponible.

Solicitud de configuración del servidor de OpenGnsys
Detected network interfaces: ens3
Introduce the default network interface:

Tras esto, se muestran las direcciones IP asociadas a la interfaz seleccionada y se solicita al usuario que especifique la dirección IP a utilizar.

Solicitud de configuración del servidor de OpenGnsys
Configured addresses in network device ens3: 192.168.122.78
Introduce your default OpenGnsys server IPv4 address:

Finalmente, se muestra la configuración previa a la instalación, solicitando confirmación al usuario.

Solicitud de confirmación de configuración
Please, verify that your configuration below is correct.

===================================
- ogCP user name: admin
- ogCP password: test123
- legacy web console user name: usuog
- legacy web console password: passusuog
- SAMBA server password: og
- Default network device: ens3
- Server IP address:  192.168.122.78

Would you like to proceed with this installation of OpenGnsys Enterprise (y/n)?
Repositorios APT de Soleta Networks

El instalador de OpenGnsys Enterprise deja configurado el repositorio de APT alojado en los servidores de Soleta Networks.

Fichero de configuración de APT con el repositorio adicional de Soleta Networks
$ cat /etc/apt/sources.list.d/soleta.list deb
[trusted=yes] https://opengnsys.soleta.eu/ubuntu-focal/ /

2.4. Actualización de OpenGnsys Enterprise

Los paquetes tienen como objetivo facilitar no solo el proceso de instalación de OpenGnsys, sino también la actualización de los distintos componentes a través de APT.

De manera que el administrador sólo tenga que ejecutar en la terminal:

# apt update

# apt upgrade

para mantener su instalación de OpenGnsys actualizada.

2.5. Exportar e importar datos de una instalacion de OpenGnsys 1.1.1c

Cuando es necesario conservar los datos de una instalación anterior de OpenGnsys se pueden llevar a cabo los pasos que se indican a continuación para migrar a OpenGnsys Enterprise.

En https://github.com/opengnsys/OpenGnsys/tree/master/installer encontramos los scripts opengnsys_export.sh y opengnsys_import.sh que nos permiten guardar los datos de nuestro servidor antiguo en un archivo tgz e importarlos en el nuevo.

En la exportación se guardan la configuración de DHCP, los archivos y plantillas PXE, las páginas de inicio y la configuración de la consola. Además, irá incluida una copia de la base de datos.

Para asegurarnos de tener la versión apropiada del esquema de la base de datos para OpenGnsys Enterprise se recomienda usar opengnsys_export.sh. Si bien conviene revisar los procedimientos que se hayan podido crear con anterioridad puesto que cambios en los comandos puede repercutir en su funcionamiento.

Para exportar los datos de un servidor se utiliza el script opengnsys_export.sh:

/opt/opengnsys/lib/opengnsys_export.sh nombre_backup.tgz
No es conveniente situar el fichero de backup dentro de /opt/opengnsys ya que la carpeta se borrará en caso de desinstalar OpenGnsys (opengnsys_uninstall.sh).

Para importar los datos al nuevo servidor se utiliza el script opengnsys_import.sh tal y como se muestra en el ejemplo:

/opt/opengnsys/lib/opengnsys_import.sh nombre_backup.tgz

El script de importación de comunidad además actualiza el esquema de base de datos para estar en la última versión de comunidad. Una vez completa la importación se debe revisar la configuración de los siguientes componentes:

  • Servidor DHCP.

  • Configuración de ips de repositorios y otros servicios como NTP, (para la consola web clásica).

  • Regenerar las plantillas de arranque por red de los equipos.

3. Componentes en OpenGnsys Enterprise

A continuación se detallan los componentes que forman OpenGnsys Enterprise, explicando su función en el ecosistema y su uso.

3.1. ogServer: Servidor principal de OpenGnsys Enterprise

El ogServer es el componente de orquestación que ofrece una API REST HTTP para recibir órdenes administrativas y las envía a los equipos clientes conectados a OpenGnsys. El ogServer mantiene las información los clientes y su estado, tales como la velocidad de enlace y el resultado del último comando ejecutado.

Los front-ends de administración se comunican con el ogServer a través de una API REST HTTP. Para el cuerpo de las peticiones se usan el formato JSON. ogServer utiliza una base de datos MySQL para el almacenamiento de toda la información relacionada con la gestión con OpenGnsys. Por ejemplo, en la base de datos se guarda todo el esquema de centros, aulas y equipos que hemos definido.

3.1.1. Fichero de configuración: ogserver.json

El archivo de configuración para ogServer se encuentra en /opt/opengnsys/etc/ogserver.json. Permite indicar la IP, puerto, token donde escuchará el proceso de ogServer, autenticación para la conexión a la base de datos, además de interfaz por defecto para Wake On Lan y directorio donde guardar imágenes creadas por los clientes (también denominado repositorio).

{
        "rest" : { (1)
                "ip" : "127.0.0.1",
                "port" : "8888",
                "api_token": "5a5ca1172136299640a9f47469237e0a"
        },
        "database" : { (2)
                "ip" : "127.0.0.1",
                "port" : "3306",
                "name" : "opengnsys",
                "user" : "mysql",
                "pass" : "mysql"
        },
        "wol" : { (3)
                "interface" : "lo"
        },
        "repository" : { (4)
                "directory" : "/opt/opengnsys/images"
        }
}
1 Configuración de red para el proceso de ogServer: IP, puerto y valor del token para autenticar peticiones de otras aplicaciones que traten de comunicarse con ogServer.
2 Autenticación para la base de datos: IP y puerto donde escucha MySQL, nombre de la base de datos, usuario y contraseña.
3 Interfaz por defecto para el envío de paquetes WakeOnLan. Aplicable cuando el servidor donde se ejecuta ogServer posee más de una interfaz de red.
4 Configuración del repositorio de imágenes. Indica la carpeta donde se almacenan y sirven las imágenes para los clientes.

3.2. ogClient: Cliente de OpenGnsys para ogLive, Linux y Windows

ogClient es un proceso que se ejecuta sobre los clientes que queremos administrar. Se encarga de recibir y procesar las peticiones del ogServer. ogClient ejecuta tareas administrativas en base a las peticiones del ogServer. Por ejemplo, particionar y formatear un cliente, clonar un cliente o restaurar un cliente.

Actualmente, ogClient implementa parte de la funcionalidad administrativa en Python y otra parte en Bash. Futuras versiones de ogClient implementarán toda la funcionalidad en Python. Para conseguir esto se han desarrollado una primera versión de bindings en python para la biblioteca libfdisk, permitiendo hacer uso directo de la biblioteca desde Python y evitando la invocación de subprocesos de aplicaciones que utilizan la biblioteca.

Además de la ejecución de comandos, con ogClient los clientes reportan información adicional sobre su estado, el éxito del último comando ejecutado o su velocidad de enlace.

ogClient es una aplicación multiplataforma y permite la administración de clientes ogLive, Linux y Windows. La funcionalidad de ogClient sobre Linux y Windows es limitada porque no se puede realizar modificaciones sobre los discos.

Los clientes puede funcionar de distintos modos según la plataforma. Cada modo expone un conjunto distinto de operaciones administrativas. Los modos soportados actualmente son:

  • live: ejecutado en ogLive, soporta operaciones administrativas sobre los discos.

  • linux: ejecutado en sistemas operativos GNU/Linux.

  • windows: soporta Windows 10 y 11.

3.2.1. Fichero de configuración: ogclient.json

El archivo de configuración para ogClient se encuentra en /opt/opengnsys/client/ogClient/cfg/ogclient.json. Permite indicar la IP y puerto donde el ogServer espera la conexión de los clientes, el nivel de log, el modo de funcionamiento y las credenciales de samba.

{
        "opengnsys": {(1)
                "ip": "192.168.56.10",
                "port": 8889,
                "log": "DEBUG",
                "mode": "live",
                "url": "https://192.168.56.10/opengnsys/varios/menubrowser.php",
                "url_log": "http://localhost/cgi-bin/httpd-log.sh"
        },
        "samba": {(2)
                "activate": true,
                "user": "opengnsys",
                "pass": "og"
        },
        "vnc": {(3)
                "activate": true,
                "pass": "ogvnc"
        }
}
1 Conexión con el ogServer y funcionamiento del ogClient: IP y puerto para la conexión con el ogServer, nivel de logging (DEBUG, INFO, WARNING, ERROR y CRITICAL), modo de operación (live, linux, windows y virtual) y los dos últimos enlaces sirven para obtener el menú de inicio de sesión y el log en tiempo real.
2 Credenciales del servidor samba para el modo ogLive.
3 (Solo VDI) Opciones para escritorio remoto.

3.2.2. Instalación en Linux

ogClient para Linux está soportado en versiones de Ubuntu iguales o superiores a 20.04. ogClient para Linux requiere el paquete python3-psutil que debe de instalar previamente.

apt install python3-psutil

Descargue el fichero .deb de ogClient para Linux en la web de OpenGnsys Enterprise en la dirección https://opengnsys.soleta.eu/download

A continuación se enumeran los pasos para su instalación:

  1. Descargar el paquete .deb de ogClient para Linux.

  2. Instalar en el sistema con el comando sudo dpkg -i {paquete} (sustituyendo {paquete} por el nombre del paquete de ogClient para linux)

    ogclient lin dpkg

  3. Durante la instalación especificar la IP del ogServer

    ogclient lin ogserver

  4. Para reportes de inicio de sesión activar el servicio de usuario de la siguiente manera:

    ogclient lin ses service

3.2.3. Instalación en Windows

Existe un instalador para Windows disponible en la sección de descargas de la web de OpenGnsys Enterprise en https://opengnsys.soleta.eu/download

ogclient win download

Para su instalación basta con ejecutar el instalador. Durante el proceso se solicita al usuario indicar la ip del ogServer al cual ogClient para Windows se conectará.

Una vez finalizado el proceso de instalación ogClient para Windows está listo y funcionando como un servicio del sistema. Además reporta inicios y cierres de sesión de usuario.

4. Integración con el servidor de DHCP

En este apartado se describe la integración de OpenGnsys con el servidor de DHCP ISC.

4.1. Añadir un equipo cliente al servidor DHCP

Es necesario asignar una IP a los equipos clientes a través del servidor DHCP para habilitar el arranque por red (PXE), puedes leer más detalles en esta sección.

A continuación se describen los pasos para asignar una dirección IP estática para un equipo cliente a través de la configuración del servidor DHCP (dhcpd.conf)

Para ello bastará con incluir en el fichero /etc/dhcp/dhcpd.conf una entrada host con los datos del cliente: un nombre, dirección MAC y dirección IP a asignar.

A continuación se encuentra una entrada de ejemplo para un equipo con MAC 00:26:b0:e6:bc:18 al cual se le asigna la dirección IP 10.141.10.106.

host nombre_cliente { hardware ethernet 00:26:b0:e6:bc:18; fixed-address 10.141.10.106; }

Una vez actualizada la configuración del servidor DHCP debemos reiniciar el servicio ejecutando:

systemctl restart isc-dhcp-server.service

Para asegurarte de que el servidor de DHCP se inicia la próxima vez que hagas un reinicio del servidor, activa el servicio:

systemctl enable isc-dhcp-server.service

4.2. Depuración de problemas del servidor de DHCP

A continuación se listan mensajes de error o avisos habituales que se pueden encontrar en el log del servidor DHCP.

Puedes consultar el log del servidor DHCP ejecutando journalctl -u isc-dhcp-server

4.2.1. "DHCPDISCOVER from …​ : no free leases"

Si nos encontramos en el log del servidor DHCP mensajes como el siguiente:

DHCPDISCOVER from d0:bf:9c:03:3b:40 via eth0: network 10.1.0.0/16: no free leases

En tal caso se ha recibido una petición de un cliente cuya dirección física (MAC) no tiene asignada una dirección IP estática.

Asegúrate de:

  • La configuración del servidor DHCP incluye una asignación de IP estática para la MAC del cliente.

  • Reiniciar el servidor después de haber realizado cambios en la configuración del servidor DHCP.

5. ogCLI: interfaz de línea de comandos para OpenGnsys Enterprise

ogCLI es la interfaz de línea de comandos para OpenGnsys Enterprise. Ofrece un alternativa al panel de control web y permite al usuario ejecutar las tareas de administración de los equipos clientes de manera programática.

¿Por qué administrar desde la línea de comandos?

El uso de la línea de comandos tiene una serie de ventajas respecto a interfaces gráficas en términos de programabilidad, repetición y ejecución no supervisada.

Se pueden definir tareas complejas con scripts, y programar su ejecución de forma no supervisada usando soluciones como cron.

5.1. Instalación de ogCLI

ogCLI se instala por defecto en OpenGnsys Enterprise al usar el script de instalación disponible en https://opengnsys.soleta.eu/download

ogCLI se encuentra empaquetado en los repositorios APT de Soleta Networks. Su instalación es sencilla, ejecutando el siguiente comando:

# apt install ogcli

5.2. Fichero de configuración: ogcli.json

El fichero de configuración reside en /opt/opengnsys/etc/ogcli.json. Este fichero permite indicar la dirección IP, el puerto y el API token del ogServer al que queremos conectarnos.

La API token de ogServer puede consultarse en su fichero de configuración 
{
	"api_token" : "XIW5aYT7sO58YQPn0GIvmo6YJiW0WWWkb", (1)
	"ip": "192.168.56.10", (2)
	"port": 8888 (3)
}
1 API token de ogServer.
2 Dirección IP de ogServer.
3 Puerto donde escucha el ogServer, por defecto 8888.

5.3. Obtener ayuda para los comandos en ogCLI

La mayoría de los comandos que podemos ejecutar en ogCLI disponen de la opción --help para mostrar opciones específicas y subcomandos disponibles.

Podemos obtener todos los comandos disponibles con ogcli --help. Si un comando requiere indicar un subcomando adicional, estos pueden obtenerse a través de ogcli [comando] --help.

El siguiente ejemplo muestra los comandos disponibles en ogCLI
$ ogcli --help
usage: ogcli [-h] [{create,list,restore,request,set,setup}]

positional arguments:
  {create,list,restore,request,set,setup}
                        Subcommand to run

optional arguments:
  -h, --help            show this help message and exit
El siguiente ejemplo muestra los Subcomandos disponibles para ogcli list
$ ogcli list --help
usage: ogcli list [-h] {clients,scopes,modes,hardware,client,images,disks}

positional arguments:
  {clients,scopes,modes,hardware,client,images,disks}

optional arguments:
  -h, --help            show this help message and exit

5.4. Ejemplos de uso de ogCLI

A continuación se muestran ejemplos de los comandos de ogCLI junto a su salida por pantalla.

5.4.1. Listado del árbol de ámbitos: equipos, carpetas, aulas y centros.

Este comando permite solicitar a ogServer una lista con todos los ámbitos registrados en la base de datos. Un ámbito puede ser un centro, un aula, un equipo o una carpeta. Las carpetas son agrupaciones de aulas o equipos.

Ejemplo para obtener el árbol completo de ámbitos: todos los centros, salas y equipos presentes en la base de datos.
ogcli list scopes

Salida de ejemplo:

{
  "scope": [{(1)
      "id": 1,(2)
      "name": "Unidad Organizativa (Default)",(3)
      "scope": [{(4)
          "id": 1,
          "name": "Soleta",
          "scope": [{
              "id": 1,
              "name": "uefi",
              "scope": [{
                  "id": 2,
                  "ip": "10.141.10.101",
                  "name": "Robertorre",
                  "scope": [],
                  "type": "computer"
                }],
              "type": "folder"
            }],
          "type": "room"
        }],
      "type": "center"(5)
    }]
}
1 Comienzo del listado de ámbitos.
2 ID del ámbito.
3 Nombre del ámbito.
4 Ámbitos descendientes.
5 Tipo de ámbito (Centro, aula, equipo o carpeta).

5.4.2. Listar clientes conectados a ogServer

Con este comando, ogCLI envía una petición a ogServer para recibir una lista con todos los clientes que estén conectados en ese momento.

Como resultado, imprime por pantalla un JSON con la información de los clientes conectados. Incluyendo dirección, modo de operación, resultado del último comando y velocidad de enlace.

Ejemplo para obtener lista con los clientes conectados al ogServer e información sobre su estado
ogcli list clients
Salida de ejemplo: En este ejemplo podemos encontrar dos equipos conectados desde ogLive. Ambos han negociado un canal de comunicación de máximo 1Gbps, además, uno de ellos no ha terminado exitosamente el último comando ejecutado.
{
  "clients": [(1)
    {
      "addr": "192.168.56.11",(2)
      "last_cmd": {
        "result": "success"(3)
      },
      "speed": 1000,(4)
      "state": "OPG"(5)
    },
    {
      "addr": "192.168.56.12",
      "last_cmd": {
        "result": "failure"
      },
      "speed": 1000,
      "state": "OPG"
    }
  ]
}
1 Array JSON con los clientes.
2 Dirección IP del cliente.
3 Resultado de la última operación.
4 Velocidad de enlace del cliente (Mbit/s).
5 Estado del cliente (ogLive: OPG, Linux: LNX, Windows: WIN, ogVDI: VDI, Cliente ocupado: BSY, Intento de arranque por red: WOL_SENT)

5.4.3. Listar detalles de un cliente concreto

Con este comando, ogCLI envía una petición a ogServer para recibir los datos que figuran en la base de datos respecto a un cliente.

Como resultado, imprime por pantalla un JSON con dicha información donde podremos comprobar datos como nombre, dirección MAC, modo de arranque, entre otros.

En este ejemplo buscamos la información del cliente identificado por la ip 192.168.56.11
ogcli list client --client-ip 192.168.56.11
Salida de ejemplo: Obtendremos un JSON con los datos que figuran en la base de datos para tal cliente
{
  "boot": "pxe",
  "center": 1,
  "hardware_id": 0,
  "id": 1,
  "ip": "192.168.56.11",
  "livedir": "ogLive",
  "mac": "0800270E6511",
  "maintenance": true,
  "name": "pc11",
  "netdriver": "generic",
  "netiface": "eth0",
  "netmask": "255.255.255.0",
  "remote": false,
  "repo_id": 1,
  "room": 1,
  "serial_number": ""
}

5.4.4. Listar modos de arranque por red disponibles

Con este comando, ogCLI envía una petición a ogServer para recibir una lista con todos los modos de arranque por red que se han configurado en el servidor.

Imprime por pantalla un listado JSON los nombres de los diferentes modos de arranque.

Este nombre se usa en ogcli set mode.

En el siguiente ejemplo obtendremos la lista de todos los modos de arranque disponibles
ogcli list modes
Salida de ejemplo: La salida es un JSON que incluye los identificadores de los distintos modos de arranque

soportados en la instalación de OpenGnsys.

{
  "modes": [
    "disk1-part2",
    "oglive",
    "disk1",
    "disk1-part3",
    "ogrelive",
    "memtest-pxe",
    "disk1-part1",
    "oglive-admin",
    "unknown"
  ]
}

5.4.5. Cambiar el modo de arranque por red de los clientes

Este comando envía una petición para cambiar la configuración de arranque por red de uno o varios clientes.

Ejemplo para cambiar el modo de arranque a ogLive de todos los equipos del aula con ID 22
ogcli set mode --mode oglive --room-id 22

Para obtener el id del aula se utiliza el comando ogcli list scopes

Salida de ejemplo: Sin errores, no hay salida por pantalla. Podremos comprobar preliminarmente que el modo de arranque ha cambiado consultado los detalles de los clientes con ogcli list client.

5.4.6. Encender equipos por red: Wake On Lan.

Este comando solicita al ogServer el envío del paquete mágico Wake on Lan a los clientes especificados para arrancarlos por red.

ogServer pondrá en estado WOL_SENT a los clientes que no estuvieran conectados a él. Para comprobar que el equipo en efecto ha arrancado podremos comprobar su estado con el comando ogcli list clients.

Arranque por red del equipo con dirección IP 192.168.56.11.
$ ogcli request wol --client-ip 192.168.56.11
Arranque por red del aula con ID 8.
$ ogcli request wol --room-id 8
Arranque por red del centro con ID 26.
$ ogcli request wol --center-id 26

Salida de ejemplo: Sin errores, no hay salida por pantalla.

5.4.7. Particionado y formateo

Este comando sirve para definir el esquema de particiones y formatearlas con el fin de prepararlo para la restauración de imágenes.

Particionado y formateo del primer disco con esquema MBR, una partición linux y otra cache, para el equipo con IP 192.168.56.11.
$ ogcli setup disk \
        --type dos \ (1)
        --num 1 \ (2)
        --part 1,LINUX,EXT4,40G \ (3)
        --part 4,CACHE,CACHE,10G \ (3)
        --client-ip 192.168.56.11 (4)
1 Esquema de partición que queremos que tenga el disco. Se puede elegir el tipo MBR o GPT: --type dos o --type gpt
2 Número del disco objetivo (por defecto 1). Sirve para seleccionar el disco sobre el que queremos trabajar en caso de que el equipo tenga varios.
3 Datos específicos de la partición. Se define el número de la partición, el tipo (EFI, WINDOWS, LINUX o CACHE), el sistema de ficheros (FAT32, NTFS, EXT4 o CACHE) y el tamaño de la partición (M: Megabytes, G: Gigabytes, y T: Terabytes): NUM,TIPO,FS,TAM
4 Cliente(s) objetivo. Se puede mandar esta orden a centro, aulas y clientes.

Salida de ejemplo: Sin errores, no hay salida por pantalla

5.4.8. Listar imágenes del repositorio

Con este comando se solicita al ogServer una lista de imágenes presentes en la carpeta destinada al repositorio de imágenes (Normalmente /opt/opengnsys/images).

ogCLI obtiene las imágenes del servidor donde se encuentra el ogServer. En caso de querer un listado de imágenes de otro repositorio es necesario cambiar la configuración de ogCLI para conectarse al ogServer presente en dicho repositorio.
Ejemplo para listar las imágenes presentes en la carpeta /opt/opengnsys/images.
$ ogcli list images
Salida de ejemplo: Obtendremos información respecto al espacio disponible en el repositorio y un listado de las imágenes presentes.
{
  "disk": {(1)
    "free": 7406645248,
    "total": 52573995008
  },
  "images": [(2)
    {
      "datasize": 5939200000,
      "id": 9,
      "modified": "Thu Jul 28 15:02:47 2022",
      "name": "imgprueba",
      "permissions": "744",
      "repo_id": 1,
      "size": 1869968426,
      "software_id": 1,
      "type": 1
    },
    ...
}
1 Apartado con información sobre el espacio total y disponible de la partición donde está montada la carpeta /opt/opengnsys/images.
2 Array JSON con la información de las imágenes presentes en el repositorio. Los datos de mayor interés son el nombre e ID de la imagen, su tamaño (comprimido y sin comprimir en bytes), fecha de la última modificación e ID del repositorio en el que se encuentra.

5.4.9. Crear imagen de la partición de un cliente modelo

Con este comando podemos iniciar la creación de una imagen de un sistema operativo de un equipo modelo.

Creación de la imagen a partir del primer disco y la primera partición del equipo con IP 192.168.56.11. La imagen tiene el nombre "matematicas1" y la descripción "Windows 10 con Sage", y se guarda en el repositorio con ID 1.
$ ogcli create image --disk 1 --part 1 --name matematicas1 --desc "Windows 10 con Sage"  --repo-id 1 --client-ip 192.168.56.11

Salida de ejemplo: Sin errores no hay salida por pantalla.

5.4.10. Actualizar imagen existente en base a la partición de un cliente modelo

Con este comando podemos realizar la actualización de una imagen creada anteriormente. Este comando debe usarse cuando se quiere sobreescribir una imagen.

Actualización de la imagen con ID 20 a partir de la primera partición y primer disco del equipo con IP 192.168.56.11.
$ ogcli update image --disk 1 --part 1 --id 20 --client-ip 192.168.56.11

Salida de ejemplo: Sin errores no hay salida por pantalla.

5.4.11. Restaurar imagen de sistema operativo en cliente

Con este comando podemos iniciar la restauración de una imagen sobre uno o varios clientes indicados.

Restauración de la imagen con ID 1 sobre la primera partición y disco del cliente con IP 192.168.56.11.
$ ogcli restore image --id 1 --disk 1 --part 1 --client-ip 192.168.56.11

Salida de ejemplo: Sin errores no hay salida por pantalla.

Post configuración personalizada: configureOsCustom

Existe un mecanismo que permite la ejecución de un shell script personalizado en `bash' tras la restauración de una imagen (también referido como script de post-configuración) en `/opt/opengnsys/client/scripts/configureOsCustom.

Si se crea un shell script en la ruta indicada, se invocará en la fase de post-configuración, tras la restauración de un sistema operativo. Este shell script se ejecuta únicamente en el modo ogLive, por lo que no se ejecuta durante el arranque del sistema operativo restaurado en cuestión.

6. ogCP: nuevo panel de administración web

ogCP (OpenGnsys Control Panel) es una interfaz web para OpenGnsys Enterprise. Presenta un panel con estadísticas de uso y el estado general del despliegue, así como secciones para la gestión de los ordenadores administrados.

6.1. Instalación de ogCP

ogCP viene instalado por defecto en instalaciones de OpenGnsys Enterprise al usar el instalador disponible en https://opengnsys.soleta.eu/download. En caso de requerir una instalación manual, ogCP está empaquetado en los repositorios APT de Soleta Networks y pueden ser instalados ejecutando:

# apt install ogcp

6.2. Acceso a ogCP: dirección del servicio

Puedes acceder al portal de login de ogCP a través del puerto 5000. Por tanto puedes acceder a ogCP en la dirección http://(ip):5000/, sustituyendo (ip) por la dirección de la máquina que ejecuta ogCP.

Por ejemplo, si el servidor de OpenGnsys tiene una interfaz de red configurada con la dirección 10.141.0.1 entonces puedes acceder a ogCP a través de la dirección: http://10.141.0.1:5000

6.3. Integración de ogCP con systemd

ogCP dispone de una unit file para systemd que lanza el servicio ogCP tras la instalación. Es posible realizar modificaciones en dicho unit file para restringir el acceso a ogCP a una cierta dirección IP y activar el soporte de HTTPS.

Para ello hay que definir un override en el unit file de ogcp para systemd, Hace uso del mecanismo de override del unit file que ofrece el paquete es conveniente, puesto que no se recomienda la edición a mano del fichero del fichero /lib/systemd/system/ogcp.service ya que los cambios realizados manualmente se pierden tras una actualización de paquete ogcp.

Para definir un override del unit file que se instala en el paquete ogcp se invoca el siguiente comando que abre un editor:

systemctl edit ogcp.service

En caso de querer exponer el acceso a ogCP desde una dirección IP específica hay que hacer uso del parámetro --host, por ejemplo, si solo se quiere exponer el servicio a través de la interfaz `10.141.10.1

[Service]
ExecStart=
ExecStart=-/opt/opengnsys/ogcp/flask/bin/python3 -m flask run --host=10.141.10.1

Tras este cambio, es necesario relanzar el servicio ogCP:

# systemctl restart ogcp.service
Activación del certificado autofirmado snakeoil

Para activar el soporte de HTTPS es posible hacer uso del certificado digital autofirmado snakeoil que se genera mediante la siguiente invocación:

make-ssl-cert generate-default-snakeoil

que genera los ficheros:

/etc/ssl/private/ssl-cert-snakeoil.key
/etc/ssl/certs/ssl-cert-snakeoil.pem

Al tratarse de un certificado autofirmado, el usuario obtendrá un aviso en el navegador que indica que el certificado no es fiable, para que dé su consentimiento.

Por ello, consideramos que lo más conveniente generar certificados digital generados por una autoridad de certificación, tales como los ofrecido por Fábrica Nacional de Moneda y Timbre (FNMT) o el proyecto Let’s Encrypt.

Para la activación de HTTPS, se puede emplear de nuevo la funcionalidad de override que ofrece systemd:

systemctl edit ogcp.service

y hay que incluir los parámetros --key y --cert, tal y como se muestra en el ejemplo:

[Service]
ExecStart=
ExecStart=-/opt/opengnsys/ogcp/flask/bin/python3 -m flask run --cert=/etc/ssl/certs/ssl-cert-snakeoil.pem --key=/etc/ssl/private/ssl-cert-snakeoil.key --host=0.0.0.0

Tras este cambio, es necesario relanzar el servicio ogCP:

# systemctl restart ogcp.service

Una vez activado HTTPS, el acceso al portal de login de ogCP a través del puerto 5000 se puede realizar a través de https://(ip):5000/, sustituyendo (ip) por la dirección de la máquina que ejecuta ogCP.

6.4. Descripción de los apartados de ogCP

A continuación se detallan todos los elementos que presenta los apartados de ogCP. Estos se localizan en la barra de navegación de la parte superior de la web. Los botones son: Panel principal, Comandos, Imágenes, Gestión de ámbitos, Servidores y Usuarios.

6.4.1. Validación de usuario: Login/Ingreso

ogcp login

Lo primero que muestra el ogCP al entrar por primera vez es la vista de Login. Para ingresar basta con introducir alguno de los usuarios y contraseñas que hemos configurado.

Si tienes problemas para acceder al panel de configuración, revisa el fichero de configuración y asegúrate de que los usuarios están definidos correctamente.

6.4.2. Panel principal: información y estadísticas generales de los servidores

ogcp dashboard

En esta sección los usuario puede consultar rápidamente información general de uso de los diferentes ogServer que la instancia de ogCP esta gestionando.

Los datos que se pueden consultar son los siguiente:

  • Información general

    • Fecha y hora de los servidores donde se encuentran los ogServer

    • Tiempo de actividad de los servidores

    • Tiempo de actividad de los ogServer

    • Número de clientes conectados

    • Número de imágenes almacenadas

  • Información sobre el almacenamiento, RAM y swap

    • Tamaño total en gigabytes

    • Cantidad en uso en gigabytes

    • Cantidad libre en gigabytes

  • Últimas imágenes creadas

  • Versiones de ogLive disponibles

6.4.3. Comandos: gestión habitual de los equipos

ogcp commands

En esta sección los usuarios pueden realizar todas las tareas relacionadas con la gestión y mantenimiento de los equipos/clientes. Es decir, pueden realizar todas las tareas necesarias para dejar un ordenador listo para su uso.

Las tareas que podemos realizar son las siguientes:

  • Comandos misceláneos sobre los clientes

    • Refrescar la información de los clientes

    • Iniciar alguno de los sistemas operativos instalados

    • Consultar los detalles de un cliente

  • Configuración de los clientes

    • Configurar el modo de arranque

    • Configurar la versión de ogLive asignada

    • Configurar el esquema de disco y particiones

  • Opciones de energía de los clientes

    • Encender equipos

    • Apagar equipos

    • Reiniciar equipos

  • Gestión de imágenes en los clientes

    • Crear una imagen

    • Actualizar una imagen

    • Restaurar una imagen

  • Gestión del inventario de los clientes

    • Ver o actualizar el inventario software de un equipo

    • Ver o actualizar el inventario hardware de un equipo

  • Logs de los clientes

    • Consultar el log histórico de un equipo

    • Consultar el log en tiempo real de un equipo

6.4.4. Imágenes: gestión del repositorio de imágenes

ogcp images

En esta sección los usuarios pueden realizar todas las tareas relacionadas con la gestión y almacenamiento de imágenes.

Las tareas que podemos realizar son las siguientes:

  • Consultar las imágenes existentes

  • Consultar los detalles de la imágenes

  • Eliminar una imagen

6.4.5. Gestión de ámbitos: Crear y eliminar centros, aulas y equipos

ogcp scopes

eEn esta sección los usuarios pueden gestionar todo lo relacionado con la estructura de ámbitos. Definimos como ámbitos todos los centros, aulas y equipos sobre los que trabaja OpenGnsys.

Las tareas que podemos realizar son las siguientes:

  • Sobre los clientes

    • Añadir un cliente

    • Importar clientes

      • Los clientes se importan en formato DHCPd.conf

    • Eliminar un cliente

  • Sobre las aulas

    • Añadir un aula

    • Eliminar un aula

  • Sobre los centros

    • Añadir un centro

    • Eliminar un centro

6.4.6. Servidores: gestión de los ogServer

ogcp servers

En esta sección los usuarios pueden realizar todas las tareas relacionadas con la gestión servidores/ogServers están conectados con el ogCP.

Solo los usuarios de tipo administrador pueden acceder a esta sección.

Las tareas que podemos realizar son las siguientes:

  • Consultar los servidores existentes

  • Añadir un servidor

  • Eliminar un servidor

6.4.7. Usuarios: gestión de las cuentas

ogcp users

En esta sección los usuarios pueden realizar todas las tareas relacionadas con la gestión usuarios.

Solo los usuarios de tipo administrador pueden acceder a esta sección.

Las tareas que podemos realizar son las siguientes:

  • Consultar los usuarios existentes

  • Añadir un usuario

  • Editar los datos de un usuario

  • Eliminar un usuario

6.5. Pasos para la administración de equipos con ogCP

A continuación se describe el uso de la interfaz web de ogCP.

6.5.1. ¿Cómo encender uno o varios equipos?

ogcp wol

  1. Seleccionar el apartado de "Comandos".

  2. Seleccionar los equipos a encender en el árbol de ámbitos izquierdo.

  3. Seleccionar opción "Encendido (WoL)" en el subapartado "Power".

  4. En la pantalla de confirmación se pueden revisar los clientes objetivo y el tipo WoL a utilizar ("Broadcast", "Unicast"). Para confirmar, pulsar el botón Enviar.

6.5.2. ¿Cómo apagar uno o varios equipos?

ogcp poweroff

  1. Seleccionar el apartado de "Comandos".

  2. Seleccionar los equipos a apagar en el árbol de ámbitos izquierdo.

  3. Seleccionar opción "Apagado" en el subapartado "Power".

  4. En la pantalla de confirmación se puede revisar los clientes objetivo. Para confirmar, pulsar el botón Enviar.

6.5.3. ¿Cómo reiniciar uno o varios equipos?

ogcp reboot

  1. Seleccionar el apartado de "Comandos".

  2. Seleccionar los equipos a reiniciar en el árbol de ámbitos izquierdo.

  3. Seleccionar opción "Reiniciar" en el subapartado "Power".

  4. En la pantalla de confirmación se puede revisar los clientes objetivo. Para confirmar, pulsar el botón Enviar.

6.5.4. ¿Cómo particionar y formatear uno o varios equipos?

ogcp partition

  1. Seleccionar el apartado de "Comandos".

  2. Seleccionar los equipos a configurar en el árbol de ámbitos izquierdo.

  3. Seleccionar la opción "Particionar y Formatear" en el subapartado "Configurar".

  4. En caso de seleccionar varios equipos se debe seleccionar el equipo base, a usar como plantilla en la próxima pantalla.

  5. Primero seleccionar el disco objetivo (en caso de existir múltiples). Posteriormente elegir el esquema de particiones (MBR, GPT),

  6. Añadir las particiones (botón "Añadir una nueva partición") eligiendo su tipo de partición y sistema de ficheros. Si se desea reformatear la partición exista o no ya una partición con la misma configuración se debe marcar la opción "reformatear", de esta forma se asegura tener la partición limpia.

  7. Para confirmar, pulsar en el botón Aceptar.

6.5.5. ¿Cómo crear una imagen en base a un equipo modelo?

ogcp create image

  1. Seleccionar el apartado de "Comandos".

  2. Seleccionar el equipo modelo en el árbol de ámbitos izquierdo.

  3. Seleccionar la opción "Crear imagen" en el subapartado "Imagen".

  4. Seleccionar disco y partición dentro de las opciones disponibles.

  5. Especificar nombre de la imagen, descripción de la imagen, y el repositorio donde guardar la nueva imagen.

  6. Para confirmar, pulsar el botón Crear.

6.5.6. ¿Cómo actualizar una imagen en base a un equipo modelo?

ogcp update image

  1. Seleccionar el apartado de "Comandos".

  2. Seleccionar el equipo modelo en el árbol de ámbitos izquierdo.

  3. Seleccionar la opción "Actualizar imagen" en el subapartado "Imagen".

  4. Seleccionar disco y partición dentro de las opciones disponibles.

  5. Seleccionar la imagen que se quiere actualizar.

  6. Para confirmar, pulsar el botón Actualizar.

6.5.7. ¿Cómo restaurar una imagen en uno o varios equipos?

ogcp restore image

  1. Seleccionar el apartado de "Comandos".

  2. Seleccionar el/los equipo/s en el árbol de ámbitos izquierdo. Para múltiples equipos deben compartir el mismo esquema de particiones.

  3. Seleccionar la opción "Restaurar imagen" en el subapartado "Imagen".

  4. Seleccionar disco y partición dentro de las opciones disponibles.

  5. Seleccionar la imagen que se quiere restaurar y el método de transferencia (tiptorrent o unicast).

  6. Para confirmar, pulsar el botón Restaurar.

6.5.8. ¿Cómo cambiar el modo de arranque por red de los equipos?

ogcp boot mode

  1. Seleccionar el apartado de "Comandos".

  2. Seleccionar el/los equipo/s en el árbol de ámbitos izquierdo.

  3. Seleccionar la opción "Seleccionar modo de arranque" en el subapartado "Configurar".

  4. Seleccionar un modo de arranque de los disponibles.

  5. Para confirmar, pulsar el botón OK.

6.5.9. ¿Cómo añadir centros?

ogcp add center

  1. Seleccionar el apartado de "Ámbitos".

  2. Seleccionar la opción "Añadir centro" dentro del subapartado "Centro".

  3. Seleccionar el ogServer donde se desea añadir este centro.

  4. Especificar el nombre.

  5. Si se desea se puede añadir un comentario.

  6. Para confirmar, pulsar el botón Enviar.

6.5.10. ¿Cómo añadir salas (aulas)?

ogcp add room

  1. Seleccionar el apartado de "Ámbitos".

  2. Seleccionar el centro donde se quiere añadir la sala en el árbol de ámbitos izquierdo.

  3. Seleccionar la opción "Añadir sala" dentro del subapartado "Sala".

  4. Especificar el nombre y máscara de red.

  5. Para confirmar, pulsar el botón Enviar.

6.5.11. ¿Cómo añadir ordenadores?

ogcp add computer

  1. Seleccionar el apartado de "Ámbitos".

  2. Seleccionar la sala donde se quiere añadir el ordenador (en el árbol de ámbitos izquierdo).

  3. Seleccionar la opción "Añadir cliente" dentro del subapartado "Cliente".

  4. Especificar el nombre, IP, MAC, máscara de red, número de serie (opcional)

  5. Elegir la versión de ogLive para este equipo.

  6. Las casillas de mantenimiento y remotePC existen para dar soporte.

  7. La interfaz de red a utilizar durante el arranque por red para ogLive. (eth0: la primera tarjeta detectada)

  8. Seleccionar repositorio por defecto.

  9. Especificar el modo de arranque.

  10. Para confirmar, pulsar el botón Crear.

6.6. Configuración de ogCP

ogCP ya viene configurado por defecto si ha realizado una instalación de OpenGnsys Enterprise por lo que el usuario no tiene que realizar ningún ajuste más. No obstante, el fichero de configuración de ogCP incluye la siguiente información.

ogCP tiene un único fichero de configuración donde debemos introducir los siguientes datos: idioma en el que queremos usar ogCP, usuarios de los que queremos disponer y servidores que queremos administrar.

Las configuraciones de idioma se debe escribir manualmente en el fichero con un editor de texto. Los idiomas soportados actualmente son ingles, castellano y catalán.

La configuración de los usuarios se puede hacer desde la propia interfaz web del ogCP. Solo los usuarios administradores tiene la capacidad de acceder a esta funcionalidad. En caso de necesitar realizarla a mano debemos introducir las contraseñas como un hash SHA512. Una manera de obtener el hash es con los siguiente comandos en bash: echo -n "contraseña deseada" | sha512sum

La configuración de los servidores/ogServers a administrar también se puede hacer desde la propia interfaz web del ogCP. Solo los usuarios administradores tiene la capacidad de acceder a esta funcionalidad.

Los usuarios que trae por defecto la instalación del ogCP son los que hayas introducido durante la ejecución del script de instalación de OpenGnsys Enterprise.

Todos los cambios hechos manualmente en el fichero de configuración requieren que el usuario reinicie el servicio del ogCP. Lo podemos reiniciar con el siguiente comando:

# systemctl restart ogcp.service

6.7. Ejemplo de fichero de configuración

{
	"LANG": "en", (1)
	"USERS": [ (2)
		{
			"USER": "admin", (3)
			"PASS": "5b722b307fce6c944905d132691d5e4a2214b7fe92b738920eb3fce3a90420a19511c3010a0e7712b054daef5b57bad59ecbd93b3280f210578f547f4aed4d25", (4)
			"ADMIN": true, (5)
			"SCOPES": [ ] (6)
		},
		{
			"USER": "user",
			"PASS": "5b722b307fce6c944905d132691d5e4a2214b7fe92b738920eb3fce3a90420a19511c3010a0e7712b054daef5b57bad59ecbd93b3280f210578f547f4aed4d25",
			"ADMIN": false,
			"SCOPES": [
				"Unidad Organizativa (Default)"
			]
	],
	"SERVERS": [ (7)
		{
			"NAME": "Server 1", (8)
			"IP": "127.0.0.1", (9)
			"PORT": 8888, (10)
			"API_TOKEN": "a0e9ab768cbe93dab5b1998e952bcdb7" (11)
		},
		{
			"NAME": "Server 2",
			"IP": "127.0.0.1",
			"PORT": 18888,
			"API_TOKEN": "e4c8gh913dph32nxm6q2768c427jrsj1"
		}
	]
}
1 Parámetro de configuración del idioma. Soporta las cadenas "en", "es" y "ca".
2 Lista con todos los usuarios disponibles.
3 Nombre de usuario. Este es el nombre que utilizaremos en el formulario de login.
4 Hash de la contraseña que usaremos para autenticarnos.
5 Valor booleano que establece si un usuario tiene el rol de administrador.
6 Ámbitos sobre los que el usuario tiene permisos.
7 Lista con todos los servidores/ogServer a gestionar.
8 Nombre del servidor. Campo puramente visual que ayuda a los usuarios a identificar el servidor en el que están trabajando.
9 Dirección IP del servidor.
10 Puerto al que escucha ogServer.
11 Clave que requiere el ogCP para autenticarse contra el ogServer.

7. tiptorrent: método de transferencia de imágenes distribuido

7.1. ¿Qué es tiptorrent?

tiptorrent es una solución para la transferencia de ficheros de gran tamaño en una red mediante transmisiones unicast capaz de evitar una sobrecarga del servidor central a través de redirecciones entre los propios clientes.

Resulta de utilidad cuando el canal entre servidor y los clientes no escala para manejar múltiples transferencias directas con los clientes.

7.2. ¿Cómo funciona tiptorrent en OpenGnsys Enterprise?

image

Figure 1. Diagrama básico de tiptorrent en OpenGnsys

tiptorrent sigue un modelo híbrido entre cliente/servidor y P2P. Un servidor inicial sirve el fichero a un máximo de clientes en paralelo, estos clientes al terminar la descarga comparten el fichero con otros clientes pendientes para aliviar el canal entre servidor y clientes.

Esto implica que los clientes ejecutan tanto el cliente como el servidor (para compartir a otros clientes).

El fichero compartido por el servidor de tiptorrent se divide a nivel lógico en un número de partes que favorece que los clientes compartan estas partes con rapidez, en vez de esperar a la descarga del fichero completo para empezar a compartir.

7.2.1. Servidor (tiptorrent)

El servidor de tiptorrent se encarga de procesar las peticiones de descarga de ficheros y de redirigir estas peticiones en caso de ser posible. Inicia la transferencia con un máximo de clientes, aquellos que no pueda redirigir a otro servidor quedan en espera. 
tiptorrent [--root,-t /path/to/serving/folder](1)
           [--redirect,-r X](2)
           [--max-clients,-n Y](3)
1 Con esta opción indicamos la carpeta que contiene las imágenes que queremos servir con tiptorrent. Lo normal es que esta ruta sea /opt/opengnsys/images.
2 El número de redirecciones que queremos que haga tiptorrent. Por ejemplo, si ponemos tres redirecciones, cada cliente que descargue una parte parte del servidor luego la servirá a otros tres clientes.
3 El número máximo de clientes que pueden estar descargando simultáneamente del servidor tiptorrent. El resto de clientes serán puesto en espera hasta que termine alguna de las descargas.

El servidor de tiptorrent es una implementación minimalista de un servidor HTTP que procesa peticiones GET y POST. Además, el servidor de tiptorrent es capaz de recibir mensajes de clientes notificando que ya han descargado algún archivo. Siendo capaz de redirigir futuras peticiones de ese mismo archivos a aquellos clientes que han notificado haberlo descargado ya.

Con la opción --root el servidor de tiptorrent sirve los ficheros que se encuentran en la carpeta donde se ha ejecutado o se puede especificar una ruta especifica.

La redirección a otros clientes puede activarse o no usando la opción --redirect. Sirve como máximo de veces que un mismo cliente recibirá redirecciones para las diferentes partes de la imagen.

Con --max-clients se puede controlar el máximo número de transferencias activas en paralelo.

7.2.2. Cliente (tiptorrent-client)

tiptorrent-client es un pequeño cliente HTTP creado para pedir partes de un fichero a un servidor de tiptorrent. Actualmente el número de partes son 64.

El cliente de tiptorrent solicita un fichero (todas las partes) a un servidor de tiptorrent, y en caso de ser redirigido repite la misma solicitud al servidor indicado. 
tiptorrent-client IP_servidor nombre_fichero (1) (2)
1 La dirección IP del servidor que está ejecutando el servidor tiptorrent y donde está la imagen que queremos descargar.
2 El nombre de la imagen que queremos descargar.

7.3. ¿Cómo se integra tiptorrent con OpenGnsys?

tiptorrent se encuentra disponible como método de transferencia para imágenes de sistemas operativos en OpenGnsys Enterprise.

Para poder utilizar tiptorrent como método de transferencia el cliente objetivo debe disponer de partición de caché.

El servidor repositorio de OpenGnsys ejecuta exclusivamente el servidor para servir las imágenes, mientras que los clientes de OpenGnsys ejecutan tanto el cliente como el servidor de tiptorrent con redirecciones deshabilitadas.

7.3.1. ¿Cómo restaurar una imagen con tiptorrent desde ogCP (interfaz web)?

Se añade en la pantalla de Restaurar Imagen una nueva opción para realizar la transferencia de la imagen usando tiptorrent. (Falta añadir una imagen)

7.3.2. ¿Cómo instalar tiptorrent en OpenGnsys?

La instalación de OpenGnsys Enterprise ya incluye tiptorrent y lo configura automáticamente para poder trabajar con el sin necesidad de ninguna intervención manual.

Soleta Networks distribuye paquetes .deb de tiptorrent a través de su repositorio APT. Este repositorio se encuentra ya activo en entornos con despliegue de Opengnsys Enterprise

  • El servidor se encuentra empaquetado en: tiptorrent-static

  • El cliente se encuentra empaquetado en: tiptorrent-client-static

Para instalar cualquiera de los componentes basta con ejecutar apt install {componente} con permisos de administrador. Asumimos instalación sobre Ubuntu 18.04 en el caso de OpenGnsys.

# apt install tiptorrent-static tiptorrent-client-static

7.3.3. Integración del servidor de tiptorrent con systemd

El instalador de OpenGnsys Enterprise se encarga de configurar y activar el servicio de systemd de tiptorrent. No hace falta que el usuario intervenga para disponer del servidor de tiptorrent listo para operar con OpenGnsys.

En el caso del servidor, si instalamos manualmente el paquete APT no es suficiente para la puesta en marcha del servidor de tiptorrent. Necesitamos ejecutarlo. Para ello se ha creado una plantilla de systemd (tiptorrent@.service) para poder ejecutar instancias de tiptorrent como un servicio. Gracias a la flexibilidad de la plantilla podremos especificar la carpeta a servir directamente en el nombre del servicio. Siendo /opt/opengnsys/images la ruta típica donde se guardan las imágenes, podemos generar el nombre de la instancia para la plantilla de la siguiente manera:

systemd-escape --template=tiptorrent@.service -p /opt/opengnsys/images

> tiptorrent@opt-opengnsys-images.service

Finalmente para crear y ejecutar inmediatamente el servicio usamos systemctl:

systemctl enable --now tiptorrent@opt-opengnsys-images.service

Podemos usar systemctl status para conocer el estado del servicio:

soleta@opengnsys-server:~$ systemctl status
tiptorrent@opt-opengnsys-images.service

● tiptorrent@opt-opengnsys-images.service - tiptorrent server with root
folder at /opt/opengnsys/images

Loaded: loaded (/lib/systemd/system/tiptorrent@.service; indirect;
vendor preset: enabled)

Active: active (running) since Fri 2021-10-01 09:23:40 CEST; 1 weeks 0
days ago

Main PID: 25847 (tiptorrent)

Tasks: 1 (limit: 4644)

CGroup:
/system.slice/system-tiptorrent.slice/tiptorrent@opt-opengnsys-images.service

└─25847 /usr/bin/tiptorrent --redirect --root /opt/opengnsys/images

7.3.4. Consulta de logs de tiptorrent

El logging de tiptorrent también está integrado en systemd, a través de journalctl. Para consultar los logs del servidor de tiptorrent basta con ejecutar el comando journalctl como se muestra a continuación.

journalctl -u tiptorrent@opt-opengnsys-images.service (1)
           --since "10 min ago" (2)

nov 03 12:53:07 monstruo tiptorrent[19381]: Starting tiptorrent server, max_clients=3 redirection=3 root=/opt/opengnsys/images
nov 03 12:55:24 monstruo tiptorrent[19291]: accepting client connection from 10.141.10.2:52598
nov 03 12:55:24 monstruo tiptorrent[19291]: closing connection with 10.141.10.2:52598
nov 03 12:55:24 monstruo tiptorrent[19291]: accepting client connection from 10.141.10.2:52604
nov 03 12:55:24 monstruo tiptorrent[19291]: no client redirections are available for 10.141.10.2:52604
nov 03 12:55:24 monstruo tiptorrent[19291]: client 10.141.10.2:52604 starts download for TEST.19
nov 03 12:55:24 monstruo tiptorrent[19291]: client 10.141.10.2:52604 finished to download successfully
nov 03 12:55:24 monstruo tiptorrent[19291]: adding client redirection to 10.141.10.2:9999 for TEST.19
nov 03 12:55:24 monstruo tiptorrent[19291]: closing connection with 10.141.10.2:52604
[...]
1 -u permite filtrar los logs por nombre del servicio
2 --since permite indicar un punto inicial del que obtener logs

8. ogLive: distribución Linux para las tareas administrativas de los equipos

ogLive es la distribución Linux que se envía a los equipo mediante el arranque por red. Esta distribución se carga en memoria RAM y nos permite realizar tareas administrativas sobre los discos del equipo sin ninguna limitación.

El arranque por red de ogLive se lleva a cabo siguiendo la especificación de PXE, que se define más adelante. Este método de arranque tiene diferente etapas que se enumeran a continuación.

Después de describir el proceso del arranque por red, se incluye una sección con los pasos para poder generar una imagen de este sistema operativo.

8.1. ogLive distribuido con OpenGnsys Enterprise

Durante la instalación de OpenGnsys Enterprise se instalan el siguiente ogLive para el arranque de los clientes: ogLive-focal-5.4.0-42. Esta distribución se basa en Ubuntu Focal y está preparada para ser arrancado por red.

La distribución de ogLive que se incluye con OpenGnsys Enterprise está hecha para su correcto funcionamiento dentro del ecosistema de OpenGnsys en su rama de desarrollo versión 1.2 en adelante.

En caso de encontrar un equipo cliente que no soporte el arranque de este ogLive por favor ponte en contacto con nosotros a través de la dirección de correo electrónico: opengnsys@soleta.eu

Distribuciones de ogLive heredadas y basadas en Ubuntu Bionic o anteriores no están soportadas.

8.2. Descripción del proceso de arranque por red de ogLive

Antes de comenzar el proceso de arranque por red es necesario que el equipo cliente sea configurado para arrancar usando este método. Para ello es necesario cambiar el modo de arranque en el firmware (BIOS) del cliente.

Los equipos actuales incluyen en la ROM de la tarjeta de red la implementación de la especificación de un cliente PXE. Un cliente PXE contiene un conjunto de protocolos estándares establecidos en la industria.

8.2.1. Arranque del equipo: Configuración de red con DHCP y opciones adicionales para PXE

Una vez configurados para arrancar por PXE, el primer paso que llevan a cabo los equipos es obtener configuración de red a través del protocolo DHCP. En el arranque por red, PXE añade una par de opciones para indicar la dirección de un servidor TFTP y el nombre de un fichero (NBP).

Estas opciones son next-server y filename. Podemos encontrarlas en el fichero de configuración del servidor de DHCP en OpenGnsys Enterprise (/etc/dhcp/dhcpd.conf).

pxe dhcp
Ejemplo de configuración de DHCP en OpenGnsys Enterprise
ddns-update-style none;
option arch code 93 = unsigned integer 16;
option domain-name "example.org";
log-facility local7;
not-authoritative;

subnet 192.168.56.0 netmask 255.255.255.0 {
    option domain-name-servers 192.168.121.1;
    option broadcast-address 192.168.56.255;
    default-lease-time 600;
    max-lease-time 7200;
    next-server 192.168.56.10; (1)
    # 0007 == x64 EFI boot
    if option arch = 00:07 { (2)
        filename "shimx64.efi.signed"; (3)
    } else {
        filename "grldr"; (4)
    }
    use-host-decl-names on;
    option routers 192.168.56.1;

host pc14 { hardware ethernet 08:00:27:0E:65:14; fixed-address 192.168.56.14; }
host pc13 { hardware ethernet 08:00:27:0E:65:13; fixed-address 192.168.56.13; }
host pc12 { hardware ethernet 08:00:27:0E:65:12; fixed-address 192.168.56.12; }
host pc11 { hardware ethernet 08:00:27:0E:65:11; fixed-address 192.168.56.11; }
}
1 Esta opción es la que indica a los equipos la dirección IP a la que tienen que solicitar los ficheros de arranque.
2 Según la arquitectura del equipo (UEFI o BIOS) se descarga un NBP distinto.
3 Este es nombre del fichero de arranque que descargan los equipo UEFI.
4 Este es nombre del fichero de arranque que descargan los equipo Legacy.

8.2.2. NBP y plantillas de arranque

Una vez se obtiene la dirección IP del servidor TFTP y nombre del NBP, el cliente PXE procede a descargarlo. El NBP se trata de un pequeño bootloader que se carga en memoria RAM y se encarga de interpretar una plantilla de arranque que buscará en el servidor TFTP.

TFTP es un protocolo muy simple. Se apoya sobre UDP y no incluye ningún tipo de mecanismo de control de congestión. Para ver más información respecto a TFTP puedes visitar el siguiente enlace.
pxe nbp
Figure 1. Captura de ejemplo en Wireshark de la solicitud de descarga de un NBP (grldr) a través de TFTP.
pxe template
Figure 2. Captura de ejemplo en Wireshark de la descarga de la plantilla de un equipo.

Esta plantilla de arranque es un fichero de texto que debe estar presente en el servidor TFTP, en caso contrario el arranque por PXE no podrá continuar. En esta plantilla se indica el programa a dar paso para continuar con el arranque, además de indicar parámetros adicionales que pudiera admitir.

El NBP busca la plantilla para el equipo usando su dirección física (MAC). En el caso de OpenGnsys se usan plantillas distintas para UEFI (/opt/opengnsys/tftpboot/grub) y para BIOS (/opt/opengnsys/tftpboot/menu.lst).

Los equipos configurados para arrancar en ogLive descargan por TFTP dos elementos: * ogvmlinuz: Kernel del ogLive a iniciar. * oginitrd.img: Ramdisk inicial para la ejecución del núcleo (incluye drivers y otros binarios fundamentales para el arranque del sistema operativo).

8.2.3. Fin de PXE e inicio de ogLive

Una vez el equipo dispone del núcleo y ramdisk se inicia propiamente el arranque de ogLive y se termina con el proceso pertinente a la especificación de PXE.

En el contexto de ogLive faltan por transferir otros elementos, entre ellos siendo el más importante el sistema de ficheros de ogLive (ogclient.sqfs). Para ello ya no se utiliza TFTP y se pasa a usar otro método de transferencia más fiable. En el caso de OpenGnsys se usa Samba, una implementación libre del protocolo SMB.

oglive wshark smb

Dentro de ogclient.sqfs se encuentra todo el sistema de ficheros de ogLive. Este sistema de ficheros se monta en RAM. También durante el inicio de ogLive se montan por Samba diferentes carpetas del servidor de OpenGnsys:

* /var/lib/tftpboot (1)
* /opt/opengnsys/client (2)
* /opt/opengnsys/log/clients (3)
* /opt/opengnsys/images (4)
1 Carpeta con todos los archivos relacionados con el arranque de los clientes.
2 Carpeta con el "motor de clonación": está formado por una colección de scripts en Bash. Además incluye el ogClient.
3 Carpeta con todos los logs de los clientes: se monta para que el motor de clonación pueda mandar sus logs al servidor.
4 Carpeta con todas las imágenes del repositorio.

Estas carpetas incluyen todos los archivos necesarios para el arranque de ogClient y funcionamiento normal a la hora de administrar el equipo cliente.

8.3. Generación de ogLive

Algunos equipos pueden presentar problemas de compatibilidad, por ejemplo al necesitar alguna versión concreta del kernel de Linux o la necesidad de incluir algún driver en el initrd para el arranque correcto de ogLive. Es importante poder disponer de un mecanismo para poder introducir cambios sobre ogLive para poder soportar nuevo equipamiento que pueda presentar este tipo de problemas.

A continuación se describen los pasos para poder crear una nueva imagen de ogLive que pueda ser distribuida en el arranque por red de los equipos en OpenGnsys.

8.3.1. Preparación del entorno de generación ogLive con Vagrant

Para generar un ogLive hace falta un entorno relativamente complejo. La manera más sencilla de disponer de tal entorno es usando el Vagrantfile que facilita OpenGnsys. Lo podemos encontrar en: https://github.com/opengnsys/OpenGnsys/blob/main/installer/vagrant/Vagrantfile-boottools-vbox.

Antes de realizar el proceso que se describe a continuación es conveniente entender como funciona Vagrant. Podemos aprender sobre Vagrant en el siguiente enlace: https://developer.hashicorp.com/vagrant/tutorials/getting-started/getting-started-index.

El proceso para levantar el entorno de generación del ogLive es el siguiente:

  1. Descargar el Vagrantfile a alguna carpeta.

  2. Asegurar que el directorio activo es la carpeta donde se descargó el Vagrantfile.

  3. Ejecutamos vagrant up.

  4. Ejecutar vagrant ssh para conectarnos a la máquina virtual que se ha creado.

Una vez realizados estos pasos, ya tenemos acceso a un Ubuntu Server 16 desde el que podemos generar imágenes de ogLive. Los scripts de generación se guardan en la ruta /tmp/opengnsys_installer/opengnsys/client/boot-tools.

8.3.2. Personalización previa del ogLive

La personalización previa a la generación del ogLive es opcional, y solo se suele realizar cuando el ogLive generado por defecto no funciona con algún hardware en concreto o porque se quiere instalar algún paquete concreto.

Configurar una versión más nueva del kernel

Si la personalización se debe a problemas de compatibilidad del kernel de Linux con el hardware de los equipos, es recomendable consultar la compatibilidad con la web https://linux-hardware.org/. En esta web introducimos el VENDOR ID y el DEVICE ID del componente que creemos que puede estar dando problemas y consultamos sus reportes de compatibilidad. Podemos consular el VENDOR ID y DEVICE ID desde Linux y Windows, desdes Linux se obtienen con lspci -nnn y en Windows se pueden ver desde el Administrador de Dispositivos.

Para cambiar la versión del kernel hay conectarse a la máquina virtual preparada anteriormente y editar el fichero /tmp/opengnsys_installer/opengnsys/client/boot-tools/boottoolsfunctions.lib, en concreto la variable OSRELEASE correspondiente a la versión de Ubuntu sobre la que vamos a generar el ogLive. A la variable tenemos que darle el valor de un kernel que este disponible en los repositorios de esa versión.

Mover módulos al initrd

Cuando un equipo no arranque en ogLive, el problema más común es que la tarjeta de red no está funcionando porque el módulo que necesita no está en el initrd. Para solucionar esto basta con conectarse a la máquina virtual preparada anteriormente y editar el fichero /tmp/opengnsys_installer/opengnsys/client/boot-tools/includes/etc/initramfs-tools/modules y añadir los módulos que queramos tener en el initrd.

Instalar paquetes deb

Para incluir software hay conectarse a la máquina virtual preparada anteriormente y editar el fichero /tmp/opengnsys_installer/opengnsys/client/boot-tools/includes/usr/bin/boot-tools/listpackages/sw.basic e incluir una línea nueva por cada paquete que queramos tener instalado en el ogLive. La línea debe seguir el formato install $package, donde $package es el nombre del paquete que queremos instalar.

Los paquetes que queramos instalar deben estar disponibles en los repositorios de Ubuntu, en concreto, en los repositorio de la versión en la que nos vayamos a basar para generar el paquete. Por ejemplo, si queremos instalar vim en un ogLive basado en Ubuntu Focal, tenemos que asegurarnos que el paquete vim esta en los repositorios de Ubuntu Focal (https://packages.ubuntu.com/).

8.3.3. Pasos para la generación de ogLive

Una vez conectados a la máquina virtual, navegamos hasta la ruta /tmp/opengnsys_installer/opengnsys/client/boot-tools. En esta ruta se encuentra el script que se debe ejecutar para generar un ogLive. Este script permite generar ogLives con diferentes versiones de Ubuntu. La versión de Ubuntu se puede indicar a través de un parámetro con el nombre de la versión.

Por ejemplo, para generar un ogLive basado en Ubuntu focal tenemos que escribir ./boottoolsgenerator.sh focal.

El proceso de generación requiere una cantidad de tiempo notable. Además, durante la ejecución es necesaria la intervención del usuario para elegir entre algunas opciones de configuración.

Información requerida al usuario durante la generación de ogLive

  • Grup-pc

    • No marcar ningún disco para instalar Grub → <OK>

    • Continuar sin instalar Grub → <Yes>

  • SSH

    • Fichero de configuración ssh_config → Pulsar Intro

  • Console-data

    • Pulsar Select keymap from full list → Pulsar pc / qwerty / Spanish / Standard / Standard

  • Instalación de paquetes

    • Si se produce algún error al instalar un paquete de software, pulsar Intro y continuar.

Una vez el script haya terminado, podemos encontrar el ogLive generado en la ruta /opt/opengnsys/tftpboot/ogclient. De esta carpeta nos interesa el archivo con extensión .iso. Vamos a mover este archivo al servidor, donde está instalado OpenGnsys, a la ruta /opt/opengnsys/lib.

OpenGnsys ofrece una herramienta para gestionar los ogLive en OpenGnsys: oglivecli. Se encuentra en la ruta /opt/opengnsys/bin. Podemos conocer todas las funcionalidades de esta herramienta ejecutando oglivecli help con permiso root. Para instalar el ogLive generado, debemos ejecutar oglivecli install XXX.iso (donde XXX es el nombre del ogLive generado). Tras la instalación, podemos ir a la web y asignar ogLive a los equipos que así lo requieran.

9. Depuración de OpenGnsys Enterprise

En esta sección se describen los distintos servicios que forman parte de OpenGnsys Enterprise, así como los distintos mecanismos para consultar mensajes de log que emiten estos servicios.

Además de los distintos servicios en OpenGnsys, también se describen los pasos para depurar OpenGnsys Enterprise con otras herramientas que permiten al usuario realizar un buen diagnóstico y reporte de incidencias.

9.1. Servicios en OpenGnsys y systemd

Los distintos componentes que forman parte de una instalación de OpenGnsys son ejecutados en segundo plano (por ejemplo, la base de datos, ogServer, DHCP, TFTP). Estos procesos en segundo plano son ejecutados como servicio a través de systemd.

En el contexto de OpenGnsys Enterprise, systemd es un gestor de servicios que nos permite iniciar, parar o monitorear este tipo de procesos en segundo plano.

9.1.1. Inicio, parada y consulta del estado de servicios en systemd

systemd cuenta con la herramienta systemctl para gestionar los servicios. Todo servicio en systemd debe tener un nombre que lo identifica que generalmente acaba con el sufijo .service.

A continuación se listan distintos ejemplos de inicio, parada, consulta y la posibilidad de habilitar un servicio (inicio automático del servicio al arrancar el sistema).

Inicio o parada de un servicio de ejemplo foobar.service con systemctl
systemctl start foobar.service  # Iniciar el servicio
systemctl stop foobar.service   # Parar el servicio

Si queremos que el inicio de un servicio sea automático al arrancar el sistema debemos habilitarlo.

Ejemplos de comandos para habilitar o deshabilitar el servicio ogserver.service.
systemctl enable --now ogserver.service  # Habilitar el servicio inmediatamente (1)
systemctl stop --now ogserver.service    # Deshabilitar el servicio inmediatamente (1)
1 enable/disable por defecto no inicia o para el servicio, para ello debemos usar la opción --now.

La consulta del estado de un servicio nos permite conocer si se encuentra en ejecución, si está habilitado y nos muestra una pequeña porción de los logs asociados a ese servicio.

Consulta del estado del servicio ogserver.service
systemctl status ogserver.service

root@galatea:~# systemctl status ogserver
● ogserver.service - OpenGnsys server
   Loaded: loaded (/lib/systemd/system/ogserver.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2022-11-15 09:38:40 CET; 1 weeks 6 days ago
     Docs: https://opengnsys.es/trac/wiki/En%3ADocumentacionUsuario
 Main PID: 1495 (ogserver)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/ogserver.service
           └─1495 /opt/opengnsys/sbin/ogserver -f /opt/opengnsys/etc/ogserver.json

nov 29 08:39:05 galatea ogserver[1495]: Sent refresh to: 10.162.94.114
nov 29 08:39:11 galatea ogserver[1495]: Sent refresh to: 10.162.94.123
nov 29 08:39:16 galatea ogserver[1495]: Sent refresh to: 10.162.94.122
nov 29 08:39:22 galatea ogserver[1495]: Sent refresh to: 10.162.94.124
nov 29 08:43:34 galatea ogserver[1495]: Sent refresh to: 10.162.94.124
nov 29 08:46:56 galatea ogserver[1495]: Sent refresh to: 10.162.94.120
nov 29 08:52:41 galatea ogserver[1495]: Sent refresh to: 10.162.94.120

9.1.2. Servicios de systemd relevantes en OpenGnsys

A continuación se listan los nombres de los servicios más relevantes para el funcionamiento de OpenGnsys Enterprise:

  • ogserver.service: Servicio asociado a ogServer

  • mysql.service: Servicio de MySQL para el servidor de la base de datos

  • smbd.service: Servicio asociado al servidor de Samba

  • apache2.service: Servicio asociado al servidor HTTP Apache usado en la consola web clásica

  • isc-dhcp-server.service: Servicio asociado al servidor DHCP

  • tftpd-hpa.service: Servicio asociado al servidor TFTP

  • tiptorrent@opt-opengnsys-images.service: Servicio asociado al servidor de tiptorrent que por defecto sirve el directorio /opt/opengnsys/images

  • ogcp.service: Servicio asociado a ogCP

9.2. ¿Cómo usar syslog y systemd-journal para depurar OpenGnsys Enterprise?

Durante la ejecución de los servicios de OpenGnsys es útil consultar los mensajes de logs que éstos han podido generar. Ya sea para depurar un error o consultar el estado de un servicio. A continuación se introduce syslog y systemd-journal, qué son y cómo utilizarlos para poder consultar los mensajes de log de los servicios de OpenGnsys.

9.2.1. ¿Qué es syslog?

Es una aplicación/demonio responsable de recolectar los mensajes de servicio que provienen de aplicaciones y el núcleo de Linux para luego distribuirlos en archivos de registros.

Fuente: https://debian-handbook.info/browse/es-ES/stable/sect.syslog.html

Por defecto, en Ubuntu se pueden consultar los logs de syslog en /var/log/syslog.

9.2.2. ¿Qué es systemd-journal?

systemd tiene su propio sistema de logging llamado systemd-journal. Por defecto, en Ubuntu Server 20.04 LTS, syslog y systemd-journal están integrados de manera que los servicios de systemd que escriban en syslog también se pueden consultar desde systemd-journal.

systemd proporciona la herramienta de línea de comandos journalctl para la consulta de los mensajes de log de los servicios de systemd.

Para consultar los logs de un servicio en específico hay que ejecutar journalctl con el parámetro -u, que sirve para indicar el nombre del servicio del cual queremos consultar los mensajes de log.

journalctl -u [nombre del servicio de systemd]

Si añadimos la opción -b, nos mostrará los desde el último reinicio del servidor:

journalctl -u [nombre del servicio de systemd] -b

Las opciones --since y --until sirven para consultar los logs de un rango en concreto de tiempo. Se pueden usar diferentes sintaxis para expresar las fechas:

journalctl -u [nombre del servicio de systemd] --since=2010-10-15 --until="2011-10-16 23:59:59"

La opción -f sirve para hacer un seguimiento activo de los logs que está escribiendo un servicio. Es decir, ver en tiempo real todos los mensajes que está escribiendo el software:

journalctl -u [nombre del servicio de systemd] -f

9.2.3. Pasos para depurar ogServer con syslog

Una de las nuevas funcionalidades de ogserver es el uso de syslog. La intención es ofrecer un sistema sencillo para conocer el estado y los fallos que pueda tener. Para comprobar el correcto funcionamiento de ogserver una buena opción es consultar syslog.

Bastaría con hacer lo siguiente para recibir información en tiempo real del ogServer.

$ journalctl -u ogserver -f

9.2.4. Syslog en ogclient

Igual que ogserver, ogclient implementa syslog para la recolección de logs. Para seguir el funcionamiento y depurar el ogclient podemos consular syslog.

Podemos consultarlo haciendo SSH al cliente y leyendo el archivo /var/log/syslog.

$ tail -f /var/log/syslog | grep ogserver

Aquí verás las conexiones que abre y cierra el ogserver, las peticiones que envía y recibe y mensajes de errores que se produzcan.

9.3. Valgrind: análisis de problemas de memoria

Valgrind es un conjunto de herramientas libres que ayuda en la depuración de problemas de memoria y rendimiento de programas. La herramienta más usada es Memcheck. Memcheck introduce código de instrumentación en el programa a depurar, lo que le permite realizar un seguimiento del uso de la memoria y detectar los siguientes problemas:

  1. Uso de memoria no inicializada.

  2. Lectura/escritura de memoria que ha sido previamente liberada.

  3. Lectura/escritura fuera de los límites de bloques de memoria dinámica.

  4. Fugas de memoria.

  5. Otros.

Fuente: https://es.wikipedia.org/wiki/Valgrind

9.3.1. Depuración de ogserver con Valgrind

Por defecto, ogserver se lanza automáticamente como servicio de systemd. Si queremos depurarlo con Valgrind, tenemos que asegurarnos de que el ogserver este parado.

$ systemctl status ogserver (1)
$ systemctl stop ogserver (2)
1 Comprobamos el estado de ogserver.
2 Paramos en caso de estar encendido.

Ahora, ya podemos lanzar ogserver con Valgrind para depurar los errores de memoria que pueda tener.

$ valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes --verbose --log-file=/tmp/valgrind-out.log /opt/opengnsys/sbin/ogserver -f /opt/opengnsys/etc/ogserver.json

9.4. Tcpdump / Wireshark: análisis del tráfico de red

Tcpdump y Wireshark son herramientas de análisis del trafico de la red. Sirven para inspeccionar y estudiar las comunicaciones que realizan las aplicaciones.

9.4.1. Tcpdump: herramienta de línea de comandos

Herramienta para línea de comandos cuya utilidad principal es analizar el tráfico que circula por la red. Permite al usuario capturar y mostrar en tiempo real los paquetes transmitidos y recibidos por la red a la que el ordenador está conectado.

Fuente: https://es.wikipedia.org/wiki/Tcpdump.

Ejemplo
tcpdump /
	-i eth1 / (1)
	-w /tmp/captura.pcap / (2)
	host 192.168.2.11 port 8889 (3)
1 Indicamos la interfaz a escuchar.
2 Guardamos la captura en un archivo.
3 Filtramos los paquetes por dirección y puerto, tanto de entrada como salida.

Podemos ver más ejemplos con curl cheat.sh/tcpdump.

9.4.2. Wireshark: herramienta gráfica

Wireshark, antes conocido como Ethereal, es un analizador de tráfico utilizado para realizar diagnósticos en redes de comunicaciones, análisis de datos y protocolos, y como una herramienta didáctica. Cuenta con todas las características estándar de un analizador de protocolos de forma únicamente hueca.

La funcionalidad que provee es similar a la de Tcpdump, pero añade una interfaz gráfica y muchas opciones de organización y filtrado de información. Así, permite ver todo el tráfico que pasa a través de una interfaz de red (usualmente una red Ethernet, aunque es compatible con algunas otras) estableciendo la configuración en modo promiscuo. También incluye una versión basada en texto llamada tshark.

Fuente: https://es.wikipedia.org/wiki/Wireshark.

9.4.3. Comunicación web y ogserver

Ogserver expone una API REST para recibir todas la comunicaciónes necesarias para el uso de OpenGnsys. Con las diferentes llamadas de la API podemos manejar de nuestra organizacion y mandar diferentes órdenes a los clientes.

9.4.4. Comunicación ogserver y ogclient

Ogclient tambien expone una API REST para recibir las comunicaciones. Contrario al ogserver, la API de ogclient NO está pensada para usarse como se quiera, únicamente el ogserver debe hacer uso de la API. Con las diferentes llamadas de la API, ogserver intercambia información con los clientes y les manda órdenes.

9.5. Comprobación de la memoria RAM (memtest86+)

La restauración de imágenes es un proceso fundamental en la operativa de OpenGnsys, donde la imagen a restaurar se escribe directamente a disco o primero se guarda en la partición de caché de OpenGnsys. Es además el proceso más intensivo desde el punto de vista de E/S y uso de memoria.

Cuando la memoria RAM no funciona correctamente pueden aparecer fallos aleatorios y difíciles de reproducir. En concreto, el proceso de restauración de imágenes a disco hace un uso intensivo de la memoria RAM. La memoria RAM defectuosa resulta en ficheros de imagénes corruptos, cuyo checksum no coincide con el fichero imagen original disponible en el servidor. OpenGnsys ofrece una solución que permite el arranque por red de pruebas de memoria, este tipo de programa también es conocido como memtest.

Un memtest es un programa cuyo objetivo es comprobar el estado de la memoria del equipo donde se ejecuta. Para comprobar de forma exhaustiva la memoria de un equipo es recomendable arrancar el equipo directamente al memtest, en contraposición a ejecutarlo como un programa más de un sistema operativo típico (Windows o Linux). Esto se debe a que toda la memoria que esté siendo ocupada por otros elementos críticos como el núcleo no podrían ser comprobados.

memtest

Errores asociados a memoria en mal estado

Un fallo característico asociado a memoria en mal estado son los conocidos como bitflips. Donde ficheros o programas cargados en memoria RAM sufren cambios en los valores de bytes debido a componentes de la memoria en mal estado. La memoria de los equipos típicos no contiene ningún tipo de detección de errores (comercializado normalmente como no-ECC), por lo que estos fallos son propagados al volcarse la información de memoria a disco.

En el contexto de OpenGnsys, una imagen de sistema operativo transferida por red pasa por la memoria RAM antes de ser escrita a disco. En caso de existir memoria RAM en mal estado en el cliente, la imagen escrita en disco estará corrupta por esto presentando múltiples bitflips.

Un memtest suele detectar muy rápido aquellos equipos que tienen memoria RAM defectuosa. Suele reportar los errores en los primeros minutos al iniciar el proceso. No obstante, memtest puede operar durante un tiempo prolongado si se quiere garantizar que el estado de memoria de los equipos es correcto.

Es recomendable ejecutar memtest con cierta periodicidad sobre servidor y clientes.

OpenGnsys Enterprise hace uso de memtest86+: memtest86+. En la sección de descargas cualquier usuario puede descargar la ISO, volcar en un USB y arrancar el memtest.

OpenGnsys Enterprise evita la necesidad de crear un medio arrancable de memtest86+ (por ejemplo un pendrive) ya que pone a disposición del administrador la posibilidad de arrancarlo red. A continuación se indica cómo arrancar por red memtest86+:

Arranque por red de memtest86+

En los repositorios APT de Soleta Networks se encuentra el paquete oge-memtest, que ofrece todos los elementos necesarios para el arranque por red de memtest86+. Es instalado por defecto en el instalador de OpenGnsys Enterprise, y también puede ser instalado manualmente ejecutando:

sudo apt install oge-memtest

Una vez oge-memtest es instalado, la plantilla memtest-pxe está disponible en los modos de arranque de cualquier cliente.

memtest pxe template
Figure 3. Opción memtest-pxe seleccionable al cambiar modo de arranque de un cliente en ogCP

Podemos encontrar la plantilla PXE en /opt/opengnsys/tftpboot/menu.lst/templates/memtest-pxe (UEFI) y /opt/opengnsys/tftpboot/grub/templates/memtest-pxe (BIOS).

$ cat /opt/opengnsys/tftpboot/grub/templates/memtest-pxe
##NO-TOCAR-ESTA-LINEA memtest-pxe
set timeout=0
set timeout_style=hidden

insmod linux

menuentry "Start PCMemTest using 'linux' command" {
    linux (tftp)/memtest/memtest.efi
    boot
}
$ cat /opt/opengnsys/tftpboot/menu.lst/templates/memtest-pxe
##NO-TOCAR-ESTA-LINEA memtest-pxe
default saved
timeout 1
hiddenmenu
fallback 1 2 3 4

title memtest
kernel (pd)/memtest/memtest.bin
boot

De esta manera OpenGnsys Enterprise permite lanzar memtest de manera simultánea en uno o más equipos clientes, sin embargo:

  • El administrador debe inspeccionar visualmente el resultado de memtest en cada uno de los equipos cliente, uno por uno.

  • No hay manera automática de apagar el proceso memtest. El administrador debe de manualmente acudir a cada equipo cliente, uno por uno.

9.6. Copia de seguridad de la base de datos

OpenGnsys Enterprise incluye un script para la creación diaria de una copia de seguridad de la base de datos. Este script se encuentra en /etc/cron.daily/oge-db-backup.

Este script es distribuido a través del paquete opengnsys-extra en su versión 1.2.0-11.

Las copias de seguridad se guardan en la carpeta /var/backups/oge/ogAdmBD, con antigüedad de hasta 30 días.

Ejemplo de copia de seguridad de la base de datos de OpenGnsys para el día 21/09/2023
# ls -lah /var/backups/oge/ogAdmBD
...
-rw-r--r-- 1 root root  81K Sep 21 12:10 ogAdmBD.20230921.bz2

Para restaurar la copia de seguridad es suficiente con descomprimir usando bzip2 y mysql como figura en el ejemplo a continuación.

Ejemplo de restauración de la copia de seguridad anterior
# systemctl stop ogserver
# bzip2 --decompress ogAdmBD.20230921.bz2
# mysql ogAdmBD < ogAdmBD.20230921
# systemctl start ogserver

10. Soporte VLAN

La siguiente sección es útil para gestionar su servidor de OpenGnsys Enterprise dentro de una red con VLAN. A continuación, se describe la configuración necesaria en OpenGnsys Enterprise para la correcta conexión de clientes en distintas VLAN con el servidor.

Esta sección no describe la configuración de interfaces VLAN en Linux, sino los pasos necesarios para que los clientes puedan conectar al servidor desde diferentes segmentos de red VLAN.
El soporte VLAN está unicamente disponible a través de la herramienta OgCLI, esta opción de configuración no está disponible a través de la interfaz de administración web ogCP.

10.1. Ejemplo de despliegue VLAN

Los ejemplos descritos en esta sección suponen la siguiente topología de red:

  • Servidor con dos interfaces VLAN con dirección:

    • 10.141.0.1 (vlan 1) en la red 10.141.0.0/24

    • 10.141.10.1 (vlan 2) en la red 10.141.10.0/24

  • El objetivo de los ejemplos mostrados a continuación configuran un aula (con id: 2 y nombre: "aula2") en la vlan 2 para que pueda conectarse a ogServer a través de la dirección del servidor en dicha vlan.

10.1.1. Plantillas PXE y VLAN

Para que el servidor de OpenGnsys sea accesible desde el segmento de red VLAN correspondiente es necesario registrar en la base de datos cada una de las direcciones IP por las cuales se puede alcanzar al servidor de OpenGnsys (ogServer) desde los diferentes segmentos VLAN existentes.

Durante la instalación de OGE se indica una dirección para el servidor, esta dirección queda registrada como la única dirección del servidor. Para que el servidor de OpenGnsys pueda ser empleado desde los segmentos VLAN existentes, hay que añadir las direcciones IP asociadas a las interfaces VLAN. Para añadir la dirección del servidor de ejemplo en su vlan 2 bastaría con ejecutar:

$ ogcli add server --address '10.141.10.1'
{"id", "2"}

Podemos listar las direcciones IP de ogServer registradas con la siguiente orden:

$ ogcli list servers

{
  "servers": [
    {
      "address": "10.141.0.1",
      "id": 1
    },
    {
      "address": "10.141.10.1",
      "id": 2
    }
  ]
}

El listado ofrece un ID que identifica de manera única a las IPs asociadas al servidor de OpenGnsys y que se emplea en sucesivas invocaciones a ogCLI.

Una vez confirmado que la nueva dirección de ogServer ha sido añadida correctamente asignamos a un aula completa la nueva dirección IP introducida con el siguiente comando:

$ ogcli set server --id 2 (1)
                   --room-id 2 (2)
1 Identificador de la dirección IP del servidor que se desea asignar, en este caso 2.
2 Identificador del aula que agrupa todos los equipos que pertenecen a la vlan 2 de este ejemplo (podemos obtener el identificador de un aula con ogcli list scopes)

Para comprobar que el cambio ha sido efectuado con éxito basta comprobar los detalles de cualquier equipo del aula objetivo usando ogcli list client. En el JSON de la respuesta encontraremos el campo server_id

$ ogcli list client --client-ip 10.141.10.100

{
  "boot": "oglive",
...
  "server_id": 1
}

Una vez estamos seguros de que tanto la nueva dirección ha quedado registrada como que los equipos pertinentes han sido asignados con esta nueva dirección podemos proceder a regenerar las plantillas PXE para el arranque en ogLive:

$ ogcli set mode --mode pxe --room-id 2

Con todos estos cambios hemos asegurado que durante el inicio del arranque (antes de la ejecución de ogClient en ogLive) los equipos del aula con identificador 2 configuren su interfaz de red usando la dirección de su VLAN correspondiente.

Tras esto el usuario estaría preparado para pasar a la siguiente fase: la creación de un fichero de configuración JSON de ogClient específica para el aula.

10.2. ogClient

Esta última parte trata sobre la creación de un fichero de configuración JSON específica para un aula. Este fichero de configuración personalizado será el utilizado por el cliente durante el arranque de ogLive, permitiendo la conexión al servidor de OpenGnsys a través del segmento VLAN al que pertenece.

Primero hay que crear un fichero de configuración cuyo nombre siga el siguiente formato.

ogclient-{ip_ogserver}.json

Este nombre requiere añadir el sufijo -{ip} el cual hace referencia a la dirección IP de ogServer en el segmento de red VLAN correspondiente.

En el caso de este ejemplo para la VLAN 2 se requeriría la creación del fichero /opt/opengnsys/client/ogClient/cfg/ogclient-10.141.10.1.json. Este fichero de configuración será utilizado por cualquier cliente que tenga asignada la dirección de ogServer en la VLAN 2, por tanto debe incluir la dirección de ogserver en dicha VLAN (10.141.10.1) dentro de los campos "ip" y "url" en la sección "opengnsys".

Fichero de configuración ogclient-10.141.10.1.json
{
	"opengnsys": {
		"ip": "10.141.10.1", (1)
		"port": 8889,
		"log": "DEBUG",
		"mode": "live",
		"url": "https://10.141.10.1/opengnsys/varios/menubrowser.php", (1)
		"url_log": "http://localhost/cgi-bin/httpd-log.sh"
	},
...
}
1 La dirección ip que figura en estos apartados corresponde con la vlan 2

En la carpeta /opt/opengnsys/client/ogClient/cfg/ se guardan los distintos ficheros de configuración que podría utilizar ogClient al ser iniciado durante el arranque de un cliente en ogLive.

10.3. Resumen

  1. Registrar en la base de datos una nueva dirección IP de ogServer con ogcli add server --address 10.141.10.1

  2. Comprobar direcciones registradas con ogcli list servers

  3. Asignar a uno o varios clientes una dirección de ogServer dado un identificador ogcli set server --id 2 --room-id 2

  4. Comprobar dirección del servidor asociado a un cliente con ogcli list client --client-ip 10.141.10.100

  5. Crear fichero de configuración específico para el aula dentro de /opt/opengnsys/client/ogClient/cfg/

11. Soporte

Soleta Networks ofrece cursos de formación y/o soporte comercial de OpenGnsys Enterprise. Cuenta con clientes que despliegan el software de servidor de OpenGnsys Enterprise sobre Libvirt/QEMU/KVM con éxito y dispone de los recursos para asistir en la instalación del servidor de OpenGnsys sobre un entorno virtualizado.

Si está interesado en recibir una oferta de soporte y/o cursos de formación, visite la web: https://opengnsys.soleta.eu/support para obtener más información.

12. Código fuente

El código fuente de los componentes ogServer, ogClient, ogCLI y ogCP puede encontrarse en el repositorio de OpenGnsys:

Por otro lado, el código fuente de tiptorrent, tiptorrent-client y python-libfdisk puede ser obtenido a través de: