Changes between Initial Version and Version 1 of Reunion160618


Ignore:
Timestamp:
Jul 12, 2018, 11:23:27 AM (6 years ago)
Author:
irina
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Reunion160618

    v1 v1  
     1[[PageOutline(2-5,Índice)]]
     2
     3= En construcción =
     4
     5== Acta de la Videoconferencia del 26 de junio de 2018 ==
     6
     7Asistentes: Zaragoza, Teruel, Málaga Huelva y Sevilla
     8
     9== Lista de necesidades y deseos ==
     10En las Jornadas de Málaga se realizó entre los asistentes una [wiki:ListaDeseos2018 lista de nuevas funcionalidades de OpenGnsys] que se consideran necesarias en un plazo menor o mayor.
     11
     12Pasamos a revisarlas para ver como se les da cabida en el proyecto:
     13
     14=== Documentación de comandos ===
     15La documentación de las funciones se está realizando con doxigen, que permite obtenerla automáticamente tratando el comentario que se pone delante de las mismas.
     16
     171) En las primeras versiones se seguía mejor el formato que necesita doxigen, pero en las últimas versiones existen fallos y no se  muestra correctamente.
     18  Revisar las sintaxis de los comentarios y incluso el código de las de las funciones. \\
     19  Crear unos ejemplos de buenas prácticas para el uso de doxigen.
     20
     212) Ver si existe una nueva versión que sea más compatible con bash.
     22
     23  Otra opción sería cambiar de programa de autodocumentación (ej: bashdoc), el problema es que habría que revisar todo el código.
     24
     253) Actualmente la documentación se genera en la instalación, lo que requiere instalar doxigen y alguna dependencia. Se plantea la posibilidad de generarla al liberar la versión y que al instalar simplemnte se baje la documentación.
     26  Cuando existe un paquete debian podría guardarse dentro del paquete, ahora que la instalación se realiza con un script no hay lugar donde guardarla. \\
     27  Cuando se actualiza o en una versión de desarrollo la documentación va cambiando y no podría generarse por anticipado.
     28
     294) No se está generando la documentación de los script:
     30  Habría que incluirlos en la configuración del doxigen para que los procese: los del cliente y el servidor. \\
     31  Habría que revisar los comentarios de los script para que cumplan el formato.
     32
     33Se creará un ticket para este tema.
     34
     35La pestaña ayuda de la consola se cambiará, de forma que incluya:
     36
     37 * La documentación de doxigen.
     38 * El manual de usuario.
     39 * El apartado "a cerca de".
     40 * Contenido del engine.cfg (sólo lectura).
     41
     42=== Cuando al clonar usando la cache no hay espacio en la misma, no tirar por UNICAST directamente ===
     43Cuando se restaura un aula y no hay espacio en cache se realiza la acción definida en la variable RESTOREPROTOCOLNOTCACHE de engine.cfg.
     44
     45Por defecto el valor de está variable es UNICAST lo que da lugar a un problema saturación en el servidor haciendo que el aula tarde  mucho en restaurarse.
     46
     47Se pondrá el valor por defecto a NONE con lo que los equipos acabarán la operación con error y permitirá elegir si queremos hacerlo por UNICAST o vaciar antes la cache.
     48
     49=== Página de bienvenida ===
     50Se podría aprovechar para poner mensajes para a los usuarios:
     51 - "Tip" del día.
     52 - Registro de la lista de correo de usuarios.
     53 - Recetas de distintos usuarios.
     54 - Trucos, ...
     55
     56La lista de correo tiene pocas personas apuntadas, habría que darle publicidad.
     57
     58=== Borrar cache ===
     59Había dos propuestas:
     60 - Ofrecer la posibilidad de limpiar la cache. \\
     61 - Al borrar imágenes de la cache, permitir seleccionar más de un a la vez.
     62
     63En la misma página de borrar imágenes se podría incluir un botón que formatee la cache.
     64  Al formatear se incluye el kernel y el initrd en la cache.
     65
     66El seleccionar varias imágenes para borrar a la vez es un poco complejo debido a la forma en que se realiza.
     67
     68
     69=== Consola web ===
     70La consola nueva y la actual pueden convivir
     71
     72Por ahora sigue siendo necesaria la consola actual para comunicarse con el ogAdmClient, cuando se cambie el agente en el ogLive se podrá prescindir de ella.
     73
     74El script de instalación está casi terminado, la parte de Angular está completa y para la de Synfony falta poco.
     75
     76Transición de la consola actual a la nueva:
     77
     78 - Al instalar se instalarán las dos consolas.
     79 - Se modifica en /client/etc/init/default.sh para que se utilice la consola nueva.
     80 - La consola nueva no puede escribir datos en la actual, por lo que primero habría que incluir los equipos en la consola actual (para el uso del ogAdmClient) y luego migrar los datos a la nueva. A partir de entonces sólo es necesario utilizar la consola nueva.
     81
     82Se podría incluir en las propiedades del aula qué consola se está utilizando.
     83
     84
     85
     86=== Posibles arquitecturas ===
     87
     88En Málaga cada centro tiene un servidor penGnsys completo, con su repositorio y su server. Además tiene un servidor OpenGnsys central com oresplado que puede usarse desde cualquier aula.
     89
     90También existen centros que confían entre ellos.
     91
     92Hacer información de la separación de servicios en el repo, el server y la parte comun para tomar la como punto de partida y reviar si es lo que queremos.
     93
     94Distintos paquetes: común, servidor de administración y repositorio.
     95
     96
     97Server
     98dhcp
     99tftpd
     100maria db
     101pxe
     102oglive
     103
     104Repo
     105Motor clonación
     106
     107Común
     108apache
     109API REST
     110Servicio Web
     111
     112tftp y ogLive en el servidor central para facilitar la gestión del ogLive con la consola web (archivo de configuración PXE).
     113
     114
     115=== Gestión encendido y apagado de cañones de video ===
     116Algunos cañones de vídeo aceptan el protocolo pjlink que permite comunicarse con el cañon a través de una API.
     117
     118Ya hay un ticket creado para integrar en la consola está funionalidad.
     119
     120 Permitiría desde la consola de OpenGnsys saber el estado del proyector y las horas de la lampara, encenderlo y apagarlo
     121
     122 Se ha incluido en las propiedades del aula la opción de dar da alta un proyector. Permite varios tipos, si es pjlink permitirá poner la IP del mismo.
     123
     124Hay que ver si es interesante asociar el proyector sólo al aula o también a un equipo (ej: el de profesor) para que pueda gestionarlo desde el pc.
     125
     126=== Geolocalizar las descargas de OpenGnsys (awstats) ===
     127Sería interesante poder saber desde dónde se realizan las descargas de OpenGsnsys para saber quién lo utiliza.
     128
     129Como ahora el código está en GitHub se mirará si tienen está información.
     130 
     131=== RemotePC gratuito ===
     132La funcionalidad de remotePc surge de la colaboración de UDS con OpenGnsys.
     133
     134Para tener remotePc gratuito es necesario que utilizar un broker de software libre gratuito.
     135
     136Si alguna universidad está usando un broker de este tipo, se podría colaborar para que se comunique con la API de OpenGnsys para remotePc. Pudiendo modificar algunos aspectos de OpenGnsys para que fuera compatible.
     137
     138=== Imágenes sincronizadas ===
     139Granada ha presentado en las Jornadas de Málaga unas imágenes sincronizadas realizadas con git.
     140
     141Se integrará la propuesta de Granada de sincronizadas con git.
     142
     143
     144== Agente para ogLive y nueva consola ==
     145Se está modificando el ogAgent para poderlo utilizar en el ogLive.
     146 Ya realiza el inventario de hardware y de software.
     147 Al terminar el comando envia al servidor que ha finalizado y el servidor lo lee en el fichero de log.
     148
     149Hay que decidir de qué manera queremos enviar los parámetros al cliente. Por ejemplo:
     150 - En la url: .../software/$DISCO/$PART
     151 - Por get: .../software?disco=$DISCO&part=$PART
     152 - Por post: {disco=$DISCO, part=$PART} .../software
     153
     154La consola nueva está enviando los parámetros por post, el cliente los aceptará de esa forma.
     155
     156
     157Cuando la consola nueva envía una tarea al cliente:
     158 - La incluye en la base de datos, obteniendo un id de la tarea.
     159 - Envía al cliente el comando ejecutar_script con los parametros por post: idtarea, script, url_resultado
     160 - Al terminar la tarea el cliente devuelve: idtarea, salida, salida de error, codigo de salida.
     161
     162Para la url donde debe devolver el resultado del script no se utiliza una fija para que sea más flexible.
     163
     164El agente nuevo ejecutará el script con permiso de root
     165
     166actualmente el ogAdmClient lanza el browser que llama a la página de  inicio del cliente. Hay que decidir si va a ser el ogAgent quién lance el browser.
     167
     168
     169