wiki:Reunion090217

Version 2 (modified by irina, 7 years ago) (diff)

--

TOC(heading=Índice)?

Acta videoconferencia 9 de febrero de 2017

Asisten: Zaragoza, Teruel, Málaga y Sevilla
Próxima reunión: 22 de febrero a las 11:30

Arranque PXE: Grub4dos versus syslinux

El proyecto Grub4dos ha dejado de actualizarse hace varios años. Seguimos utilizándolo para al arrancar un equipo por PXE porque permite mirar dentro de las particiones buscar un fichero, modificarlo o borrarlo, esto nos facilita:

  • Tener el kernel y el initrd en cache. Esto independiza el tiempo de arranque del número de clientes. Con syslinux el servidor enviaba el kernel y el initrd a todos los clientes, el primer equipo podía arrancar en unos 30s y el último tardar varios minutos.
  • Buscar si una partición tiene un fichero a modo de marca y arrancarla.

No sabemos si el syslinux tiene esta funcionalidad actualmente.

En el tftpboot están los directorios de grub4dos y del syslinux, aunque este último no se usa. Se mantiene por si alguien lo necesita.

Curso Online

Hay 400 inscritos.

Se activará el Open Badges para que puedan certificar el curso de esta forma.

A todos los pdf de la documentación del curso se le pondrá licencia Creative Common BY (atribución) SA (compartir igual)

Posibles colaboraciones

Para facilitar las colaboraciones se creará una página en el wiki donde se describan subproyectos de OpenGnsys que puedan desarrollarse de forma independiente. En la reunión se mencionan los siguientes:

  • Arranque en caliente de Windows.
  • Traducir la base de datos actual a unmotor transaccional.
  • Sustituir los servicios por API REST: ogAdmClient
  • Sustituir los servicios por API REST: ogAdmServer
  • Gestión de particiones GPT y UEFI.
  • Migración de SVN a GIT
    • Un compañero de Málaga nos puede dar una introducción sobre cómo realizar la migración.
  • Módulos para la consola web. La consola consta de dos partes:
    • desde el cliente se usará el framework de javascript angular.
    • desde el servidor usaremos el framework de php symfony (ahora se está usando slim).

Animamos a todos los miembros del proyecto a que aporten sus ideas en esta página.

OpenGnsys - UDS

Ha habido una reunión con UDS y se ha quedado en incluir algunas rutas más para que OpenGnsys sea proveedor de UDS:

  • Reservar un PC con una imagen instalada para que sea iniciado en ese SO
  • Registrar URLs para notificar a UDS los eventos de login y logout, para que OpenGnsys sirva de intermediario entre el agente del SO y UDS.
  • Liberar un PC, quitando la reserva de uso remoto y apagando el equipo
  • Establecer hora de logout obligatorio en que OpenGnsys debe enviar orden de apagado al PC

Ellos están haciendo los cambios que necesita su parte. Se les ha enviado un logo para representar a OpenGnsys dentro de UDS.

Hemos probado con éxito:

  • Arrancar un equipo con una imagen en concreto:
    • Se arranca el equipo con WOL.
    • Se registra el la cola de acciones el inicio de sesión. El cliente cuando arranca OpenGnsys consulta la cola e inicia el sistema operativo.
    • Al iniciarse sistema operativo se arranca el ogAgent y manda un mensaje al servidor diciendo que está activo.
  • Mandar el comando apagar al agente cuando se acaba la reserva.

Se podría probar con un prototipo que sustituyera a UDS.

Málaga ha terminado el módulo de moodle para integrarlo con UDS. Esté módulo permite que a una actividad se le asocie una máquina virtual que sólo es accesible desde la enseñanza virtual.

Congelar los equipos

Málaga está interesada en congelar los equipos y están haciendo pruebas.

En el foro hay un mensaje explicando cómo compatibilizar OpenGnsys con ToolWiz Time Freeze: Integración con herramientas de congelado (#265)

La primera vez que se arranca con OpenGnsys no está congelado, por lo que puede reconocer los drivers; entonces es cuando cambia la configuración a congelado en el siguiente arranque.

Con el agente se podría congelar y descogelar el equipo aunque estuviera arrancado.

Ticket pendientes versión 1.1.0

#771 Crear imagen no muestra correctamente el espacio necesario y disponible

Hay que cambiar la función ogGetSizeParameters. El cambio es fácil pero hay que cambiar los script que llaman a la función.

#528 busybox tftp ogLive con acceso subdirectorio contenedor tftpd del server

Está casi terminado.

Falta modificar el script setsmbpass para que busque dentro de los distintos subdirectorios al cambiar la clave. En el ticket está documentada la línea que hace falta.

Las plantillas PXE deben incluir esta variable para que el cliente sepa qué directorio montar.

#767 Revisar estabilidad del asistente de particionado

El código del asistente de particionado es diferente en la versión 1.1 y la 1.0.6b, hay que comprobar que funciona bien en todas las situaciones posibles.

#772 Módulo de administración web para dispositivos smartphones y tablets

Se trata de un desarrollo web para unirlo a modo de plugin con la consola web de administración y poder gestionar las aulas a través de un dispositivo móvil o tablet.

Está hecho en el mismo lenguaje que la consola (php) y utiliza la misma base de datos (Mysql). Se ha decidido por sencillez y rapidez no crear una web adaptativa de la consola principal, sino varias páginas que usan las mismas librerias, pero hojas de estilo distintas que ajustan la visualización a una pantalla de pequeñas dimensiones.

#718 Nuevo agente modular con comunicaciones REST

Parece que está terminado.

Los archivos de instalación del ogAgent para los distintos sistemas operativos no está subidos al svn porque ocupan mucho, se pondrá en el Google Drive en una carpeta.

La instalación se realiza en el equipo modelo:

  1. Hay que desinstalar el agente antiguo
  2. Los instalables de pueden bajar de la consola de administración el la página de propiedades del equipo.
  3. Al restaurar la postconfiguración configura el agente en el equipo cliente. Si no lo encuentra instalará el agente antiguo, si así está configurado en el engine.cfg

La comunicación entre el cliente y el servidor se realiza con un token de seguridad para que no pueda recibir ordenes de otros equipos desconocidos.

La página del wiki sobre la API REST incluye un apartado con las rutas del ogAgent.

La API REST de un agente OpenGnsys para sistemas operativos estará bajo la URL https://IPCliente:8000/opengnsys.

  • /logoff Lanzar un proceso para cerrar la sesión del usuario matando todos sus procesos.
  • /popup Lanzar un proceso para mostrar una ventana emergente con un mensaje en la sesión del usuario activo
    (la ventana se mostrará como mucho durante 1 minuto).
  • /poweroff Lanzar un subproceso para apagar el sistema.
  • /reboot Lanzar un subproceso para reiniciar el sistema.
  • /script Lanzar un subproceso para ejecutar un script en el cliente (codificado en Base64).
  • /status Muestra el estado actual del sistema.

El agente envía mensajes al servidor en las siguientes acciones:

  • iniciar: started
  • apagar: stoped
  • al iniciar sesión de usuario: login
  • al cerrar la sesión de usuario: logout

#708 Crear API REST para integración de OpenGnsys con UDS

Está casi terminado.

Para seguir avanzando es necesario que lo repasemos todos para ver si falta alguna funcionalidad y determinar qué requisitos de seguridad queremos.

Al instalar OpenGnsys la API REST se situa en la consola web a partir de la url: $IPSERVER/opengnsys/rest

  • En la propia url encontramos la documentación de la misma realizada con swager.
  • El formato de las rutas es largo, conteniendo varias id's que permiten hacer comprobaciones de que el resultado es correcto.
  • La solicitudes que se reciben se van registrando en el log de apache.

#743 Función en el webservice api rest para wakeonlan

Es muy interesante que el servidor de repositorio tenga una API REST. Posibles aplicaciones:

  • Eliminar imagen del repositocio desde la consola web, actualmente sólo si el repo y el server están en la misma máquina.
  • Funciones que realice el ogAdmRepoAux, por ejemplo iniciar una transferencia multicast cuando el cliente la solicite.
  • La semilla del torrent no se tendría que iniciar para todas las imágenes sino bajo demanda cuando se quiera realizar una restauración.

Personalizando el inicio de sesión

Se decide crear un script bootOsCustom para personalizar el inicio de sesión. Al igual que con el configureOs se ofrecerá una plantilla, bootOsCustom.template, con ejemplos que habrá que modificar y renombrar.

El script bootOs llamará al script bootOsCustom antes de desmontar las particiones.

#770 Imágenes sincronizadas: transferencia multicast

Se utiliza la idea del proyecto mrsync: Los ficheros se envían por multicast y el resto de las propiedades sí se sincronizan con rsync.

Sólo se utiliza para restaurar, ya que para crear la imagen el servidor tiene que recibir una transferencia multicast que podría ser un problema de seguridad.

El proceso de restauración:

  • Con rsync se crea el listado de las diferencias y los archivos que hay que restaurar.
  • Si el protocolo es multicast se utiliza el listado y se envían estos ficheros desde el repositorio a la partición. Se han modificado algunas funciones de multicast para que permitan enviar un conjunto de ficheros.
  • Se sincroniza con rsync, utilizando el listado. Después del multicast sólo quedan pendientes las diferencias en los atributos y los enlaces.

#726 Reducir el registro de errores y avisos en algunas operaciones

Se podría incluir una variable de "nivel de depuración" en las propiedades del equipo, de forma que si el debug es alto salgan todos los mensajes y si se disminuyen salgan menos según importancia.

En muy minuciono.

Se creará una página en el wiki donde se vayan recogiendo los mensages que son falsos positivos y que habría que eliminar o mostrar en un nivel de debug alto.

#745 Depurar ogAdmServer

Se incluyeron las mejoras que propuso Zaragoza.

Parece que está terminado, sólo falta probarlo.

#769 ogLive amplia el espacio de memoria reservada para instalar software en "caliente"

Se realizará en la próxima versión.