Resumen reunión presencial del 14 de abril de 2015

Asisten: Barcelona, Zaragoza, Málaga y Sevilla.

El objetivo de la reunión es poner las bases para las próximas versiones de OpenGnSys y el buen funcionamiento del proyecto a largo plazo.

Evolución del proyecto

Pendiente de realizar

Versión 1.0.6

Ticket Pendientes

#688 cambiar la contraseña del usuario usuog afecta al ogAdmclient.cfg

Esta terminado, sólo falta integrarlo.

#701 torrent-creator falla si el fichero-imagen a procesar no es valido.

Se realizará si da tiempo, si se acaba antes el ticket 688 se pasará a la próxima versión.

#705 Eliminar campos de formularios que han dejado de utilizarse

Está terminado, sólo falta cerrarlo.

Otros

Agente de Windows/linux no se instalará por defecto

Cuando hay cortes de red aunque sean pequeños se desconecta el agente del sistema operativo del servidor y bloquea la salida a internet. Según la calidad de la red puede dar problemas o no.

Se podrá configurar en engine.cfg si queremos incluirlo en la postconfiguración o no. La opción por defecto será que no se instale el agente OpenGnSys. Hay que documentar el engine.cfg.

Por otro lado, el servicio ogAdmServer se cae si recibe una trama incorrecta, probando la API rest al mandar un comando incorrecto se paraba el servicio. En el uso normal de OpenGnSys no pasa.

Coherencia partición - sistema de ficheros

El tipo de partición es sólo informativo, es decir se puede instalar un linux con sistema de fichero ext4 sobre una partición ntfs y windows no es posible porque el sistema comprueba el dato.

Málaga después de restaurar, en la postconfiguración comprueba la coherencia entre el tipo de el sistema de ficheros y el tipo de partición para cambiar está última si es necesario.

Dato del equipo: imagen restaurada

En la configuración del equipo de la consola aparece el dato de la última imagen restaurada, en algunas ocasiones se pierde. Es muy importante para la funcionalidad remotePC de la versión 1.1, hay que intentar determinar en qué situaciones desaparece para tratar de solucionarlo.

Nombre del proyecto

Cambio de la forma de escribir el nombre del proyecto en la versión 3.0: Se pone en minúscula la s:OpenGnsys Logo OpenGnsys vectorial -> cambiar S a minúscula.

Documentación 1.0.6

Se tomará como partida la documentación de la 1.0.5 del wiki, está a su vez se inició con el contenido del curso de la 1.0.4 y se le han añadido la mayoría de los comportamientos de la 1.0.5.

Se crea la página "Documentación de Usuario de OpenGnSys 1.0.6" con el índice del tema del curso.

Se reparten los temas para revisarlos y completarlos con las nueves funcionalidades:

1. Introducción a OpenGnSys (Jonathan)
2. Instalación, actualización y desinstalación (Ramón)
3. Administración web (Delia y Juan Carlos)
   • Componentes de OpenGnSys para gestión
   • Administración de la consola web
   • Administración de una unidad organizativa
4. Ámbito de aplicación (Jonathan)
5. Particionado de discos (Jonathan)
6. Gestión de imágenes (Irina)
   • Creación y eliminación de imágenes
   • Restauración y despliegue de imágenes
   • Gestión de imágenes básicas e incrementales
7. Acciones y menús de usuario (Ramón)

Sevilla creará un entorno virtual con dirección ip pública para que todos podamos acceder y las capturas de las imágenes partan del mimo ejemplo.

Curso Gestión avanzada de OpenGnSys

Se ha organizado un curso presencial en la Universidad de Sevilla “Gestión avanzada con OpenGnSys” en el que pueden inscribirse personal de otras universidades. La fecha es 11, 12, 13, 14 de Mayo de 16:00 a 21:00

Se repasa el temario previsto y se comentan temas a añadir:

• Configuración del protocolo multicast entre distintas subredes: ttl, ip servidor repositorio,...
• Arranque de ogclient Desde Cache.
• Varios repositorios en un mismo server (se nombró pero no se decidió si se trataba o no)

Revisión de la lista de deseos de red iris.

En los grupos de trabajos de redIris de 2011 en Barcelona se creó entre las universidades presentes una lista de funcionalidades que se querían ver cubiertas a corto, medio y largo plazo. Se repasan el estado de cada una de ella, se marcan con color verde las implementadas, en amarillo las que están conseguidas en parte, en rojo las que no están realizadas y se tachan los comportamientos que se han descartado.

Necesidades - Corto plazo

Consola de Administración: al hacer un cambio se refleje en el estado del equipo

Time out en la pantalla del cliente

Documentación . Gestor: explicaciones, mapa de directorios, programas comentados, módulos e interconexión. Listado de funciones y errores (existe pero es difícil de encontrar)

Postconfiguración Windows: registro, incluir en dominio de forma automática, active directory, sysprep

Autenticación ldap/active directory

Imágenes: sincronizar imagen-partición, no monolíticas, que trabaje por FS y no por sectores, imágenes incrementales, añadir o eliminar ficheros de una imagen.

Configuración cliente parámetros de inicio: acpi, modos, pxe, sata

Consola que maneje particiones extendidas

Consola las acciones sean con seguimiento por defecto (ahora sólo procedimientos y tareas)

Menú offline. Si hay red online, sino offline

Consola: comando para la clonación mbr (el MBR se regenera)

Consola: acciones sobre los grupos y no sobre ámbitos.

Línea de trabajo: que no se complique, siga siendo práctico, sencillo e intuitivo

Mejoras - Medio plazo

Agente opengnsys en sistemas operativos

Virtualización: tratamiento discos virtuales,

Descarga cliente a cliente por torrent

Integración PXE externo y/o centralizado (que se modifique desde la consola)

Equipos biblioteca: poder ejecutar un núcleo de linux almacenado en equipo remoto, el equipo usará sólo un par de directorios (ej:/tmp) en la partición local, el resto por nfs

Deseos - Largo plazo

Grupo estable de soporte (interuniversitario y/o por turnos)

Cliente: pantalla de inicio imagen, no líneas de linux (seguridad)

Facilitar las colaboraciones en el desarrollo. (Que, siendo modular y claramente definidos con sus interrelaciones, cualquiera pueda desarrollar, uno o varios por su cuenta sin alterar los demás y que las colaboraciones prosperen)

Volcar imágenes sin PXE

Disminuir tiempo de arranque del cliente

Servidor en otras distribuciones: redhat, fedora,...

Inventario de software con otro formato

Consola: menú de opciones postconfiguración

Imágenes PAS: que respete los datos de los usuarios

Alta equipos: dhcp ofrece ip temporal, en el cliente pantalla por defecto para dar de alta: se podrán meter todos los datos de los equipos y modificará el dhcp.

Versión 1.1

Remote PC

Los equipos de las aulas quedan sin uso cuando no hay clase o por la noche. Se plantea ofrecerlos por escritorio remoto de igual forma que podría accederse a una máquina virtual.

Las máquinas virtuales se gestionan a través de UDS, que hace el papel de broker, y kvm como hipervisor, en la nueva estructura tendríamos UDS+ OpenGnSys.

Para la comunicación de UDS con OpenGnSys se está creando una API REST que permitirá consultar el estado y características de los equipos y arrancar e iniciar sesión en la partición deseada. La descripción de la API pude consultarse aquí.

La API REST abre la posibilidad de establecer un nuevo mecanismo de comunicación entre el cliente o el repositorio con el server que son muy útiles para la versión de OpenGnSys 3.0.

El paso de mensaje se está haciendo en formato JSON.

Unificación de los agentes: nos vamos a encontrar el agente de UDS, el ogclient y en algunas universidades otro agente más. Sería conveniente tener un único agente que integrara los distintos comportamientos.

Varios repositorios

El cliente de OpenGnSys tendrá un repositorio por defecto, pero podrá restaurar y crear imágenes de otros diferentes. Se basa en montar en el recurso /opt/opengnsys/images el recurso remoto del repositorio que deseamos.

Se ha probado con los script deployImagen y updateCache y va todo bien.

La base es la función ogChangeRepo recibiendo la ip de un repositorio comprueba se es el que está montado y si no es así lo cambia. También admite la constante "REPO" para montar el repositorio por defecto. Los script llaman a la función al principio.

El resto de las funciones no han necesitado ningún cambio porque todos los datos, incluso la ip del repositorio, lo toman a través del recurso remoto ogimages que tienen montado.

Más información aquí.

Varias unidades organizativas en un repo

Las imágenes de las distintas unidades organizativas se guardarán en subdirectorios de /opt/opengnsys/images. Se basa en montar en el recurso /opt/opengnsys/images el recurso remoto que apunta al subdirectorio de la unidad organizativa.

Versión 3.0

Nuevas funcionalidades

Mover imágenes de un repositorio a otro.

Es más fácil si se hace en dos pasos, primero se copia y luego se borra.

El usuario sólo podrá moverlas entre unidades organizativas donde tenga permisos.

Es necesario que haya comunicación entre un server y un repositorio remoto, ahora mismo no la tenemos. Esto también permitiría eliminar imágenes del repositorio remoto.

Exportar/importar los datos de un server a otro

En una estructura de un server con varios repos, al instalar un nuevo repositorio nos puede interesar tener un server local en principio y luego pasar esos datos al servidor centralizado. Sería necesario la funcionalidad de exportar/importar los datos de un server a otro.

Recursos

Los recursos son grupos de ordenadores: ou, aulas, grupos,...

Aparece el nuevo recurso listas: es un conjunto de equipos que cumple una condición concreta (la imagen restaurada, un hardware específico,etc). Las listas pueden ser estáticas o dinámicas, según se guarden los identificadores de los equipos en el momento de crearlas o en el momento de ejecutarlas. En el primer caso la lista estará compuesta de un conjunto de identificadores de los pc y en el otro de la condición para seleccionarlos. Empezaremos sólo con las listas estáticas por ser más fáciles de implementar.

Cómo estructurar los equipos: Se mantiene la estructura en niveles ou -> grupos de aulas -> aulas -> grupos de ordenadores -> ordenadores y además las listas. Para dotar de más flexibilidad se permitirán varios niveles de agrupamiento, es decir podemos tener grupos de aulas/ordenadores unos dentro otros.

Módulos de inventario

Tendríamos un inventario básico que sería como el actual. Se guardaría en la base de datos de OpenGnSys, es necesario entre otras cosas para el uso de "remotePC".

Tendríamos otro módulo que permitirá mandar los datos a ocs y glpi. Se podría tener instalado el agente ocs en el ogclient para el inventario de hardware, el de software es más complejo ya que habría que ejecutarlo en cada sistema operativo. Hay que tener en cuenta que los datos se envían directamente al servidor y no se pueden aprovechar para que los guarde OpenGnSys.

Publicar imagen

Las imágenes publicadas (o activas) serán las que se puedan restaurar.

Al crear una imagen podrá publicarse o no, para hacer pruebas de que la imagen esté bien creada. Una vez probada se publicará para que pueda restaurarse.

Para que a los usuarios de versiones anteriores no les suponga un cambio complicado se resaltará el paso "publicar imágenes" en la documentación y al crear la imagen se dará la opción de publicación inmediata.

En el caso de publicación inmediata, el sistema esperará hasta que estén realizados los archivos de suma de comprobación y los torrent.

Consola y módulos

La versión 3.0 será modular, al instalar OpenGnSys se instalará el núcleo de la aplicación y los módulos que necesarios para dar la funcionalidades de la versión anterior. Se podrán instalar otros módulos para obtener comportamientos "avanzados".

El listado de los módulos con detalle se puede consultar aquí.

Cuando se actualice un módulo tendrá que revisar las dependencias de otros módulos con sus versiones correspondientes.

Procedimiento
Que permitan decidir si queremos seguimiento o no.

Seguimiento
Que tenga una caducidad, es decir que podamos decidir que si en X horas no se ha realizado se descarte. En caso de lanzar una restauración y no realizarse por algún motivo, este comportamiento evitaría que al día siguiente cuando el alumno encienda el equipo se ponga a restaurar automáticamente.

Es un modulo independiente de los comandos, de esta forma se puede aplicar a otras acciones por ejemplo eliminar imagen del repositorio, etc.

Alarmas/Avisos
Si queda algo pendiente en la cola de acciones que se muestre al entrar en un aula, por ejemplo como al picar en el aula aparece el estado que se muestre en está página un aviso de la cola de acciones. También se podría mandar un correo o avisar por otro medio.

Archivos PXE
Se repasa donde se sitúan los recursos que comparten los servidores Server y Repo. En el server se sitúa la primera parte del ogClient (kernel + initrd + archivo PXE), sería mejor que estuviera en el repositorio.

Se guardan en el Server porque la consola de administración no puede escribir en el repositorio cuando es remoto.

Inteligencia de Repositorio
La base de datos debe estar centralizada en el server, para evitar duplicar los datos. Es necesario que el repositorio pueda realizar ciertas acciones y se comunique son el server para pedir datos, recibir comandos, etc.

Instalación de módulos
Cuando se instale un modulo en el server puede implicar también cambios en el repo, los archivos de instalación se podrían enviar por rsync y es necesario que el server le pueda pedir al repo que instale el modulo.

Comparativa entre php/Symfony y python/Django
Al ser un cambio tan grande, que implica como primer paso la consola pero más adelante los distintos servicios de OpenGnSys conviene elegir la tecnología que mejor se adapte a las funcionalidades que queremos cubrir.

Se realizará una comparativa entre php/Symfony y python/Django se intentará elegir en la próxima reunión presencial. Es importante elegirla pronto para intentar realizar un curso en junio.