Changes between Initial Version and Version 1 of Reunion140415

Timestamp:

Apr 16, 2015, 2:46:06 PM (9 years ago)

Author:

irina

Comment:

--

Reunion140415

@@ +1 @@
+[[TOC(heading=Índice)]]
+{{{
+#!div style="width:50%; background: #ffd; font: bold italic large sans-serif"> 
+En preparación.
+}}}
+
+= Resumen reunión presencia del 14 de abril de 2015 =
+
+Por lo largo de la reunión no es un acta exhaustiva, si alguien considera que falta algo de lo comentado que lo añada si puede.
+
+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 XXX se creo entre todas 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:
+
+'''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 gestiona a través de UDS, que hace el papel de broker???, y kvm como hipervisor, en la nueva estructura tendriamos UDS+ OpenGnSys.
+
+Para la comunicación de UDS con OpenGnSys se está creando una API REST que permitirá consultar el estado y caracteristicas de los equipos y arrancar e iniciar sesión en la partición deseada.
+
+La descripción de la API pude consultarse en: 
+
+La API REST abre la posibilidad de establecer un mecanismos de comunicación entre el cliente o el repositorio con el server que son muy utiles para la versión de OpenGnSys 3.0
+
+El paso de mensaje se está haciendo en formato JSON.
+
+Unificación delos 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 integrará los distintos comportamientos.
+
+=== Varios repositorios ===
+El cliente de OpenGnSys tendrá un repositorio por defecto, pero podrá restaurar y crear imágenes de otros diferente. 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.
+
+=== 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.
+
+Más información:   
+
+
+
+
+
+
+
+ 
+
+
+== Version 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 estructuta 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 especifico,etc). Las listas pueden ser estárticas o dinámicas, según se guarde los identificadores de los equipos en elmomento de crearlas o en el momendo de ejecutarlas. En el primer 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 se más faciles 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 permitiran varios niveles de agrupamiento, es decir podemos tener grupos de aulas/ordenadores unos dentro otros.
+
+== Modulos 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 permitierá mandar los datos a ocs y glpi. Se podría tener instalado el agente ocs en el ogclient para el invertario 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 imágen podrá crearse y no publicarse, 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 suponga un cambio complicado se resaltará el  paso "publicar imagenes" en la documentación y al crearse 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 modulos ==
+Cuando se actualice un módulo tendrá que revisar las dependiencias de otros módulos con sus versiones correspondientes.
+
+Procedimientos: 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 modulos.
+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. 
+
+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 fucnionalidades 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.
+