Changes between Initial Version and Version 1 of Reunion250315

Timestamp:

Mar 26, 2015, 12:38:57 PM (10 years ago)

Author:

irina

Comment:

--

Reunion250315

@@ +1 @@
+[[TOC(heading=Índice)]]
+= Acta de la videoconferencia de 25 de marzo de 2015 =
+Asisten: Barcelona, Zaragoza, Málaga y Sevilla \\
+Próxima reunión: 14 de Abril de 2015, presencial.
+
+== Versión 1.0.6 ==
+Está casi terminada. 
+
+== Ticket cerrados ==
+=== #702        !UnidadOrganizativaDefault ===
+En la página para entrar en la consola de administración, la lista de selección de unidades organizativas muestra la unidad por defecto en vez de estar vacía.
+
+=== #704        !VentanaLogSeguimiento ===
+Cuando iniciemos Log de Seguimiento la ventana que se abre será de 1024 X 768, con lo que no tendremos que redimensionar la ventana para ver el contenido.
+
+=== #699        !CacheCompleta ===
+Cuando tenemos la cache completa, nos aparece en la configuración en la primera imagen del contenido de la cache un 0 en el inicio del nombre de la imagen.
+
+Por éste motivo el comando Eliminar Imagen Cache Cliente no puede eliminar ésta imagen
+Se ha corrido el error mostrando el mensaje en ROJO y MAYÚSCULAS.
+
+=== #700        Unicast-Aulas ===
+Al lanzan un Deploy Imagen con el método UNICAST sobre el Ámbito Aulas se muestra un mensaje avisando que esto puede provocar que se ralentice la transferencia.
+
+=== #703        Comando-Unicast-Direct ===
+Cuando lanzamos un comando Restaurar imagen con el método UNICAST-DIRECT o UNICAST-CACHE sobre el Ámbito Aulas, aparecerá un panel informativo comunicando ésta acción y advirtiendo que esto puede ralentizar el proceso de transferencia.
+
+=== #707        !EliminarImagenRepositorioDir ===
+El comando Eliminar Imagen Repositorio ya puede eliminar las imágenes basadas en directorios.
+
+=== #705 Eliminar campos de formularios que han dejado de utilizarse ===
+Se han quitado de la consola de administración web y, en su caso, de la base de datos, aquellos campos de los formularios que han dejado de utilizarse en las nuevas versiones de OpenGnSys, tales como:
+
+   - Formulario de propiedades de repositorio: caminos relativos al repositorio.
+   - Formulario de propiedades de menú: coordenadas del menú. 
+
+Con estos cambios se pretende mejorar el uso de los formularios.
+
+== Ticket abiertos que se incluirán en está versión ==
+
+=== #688        cambiar la contraseña del usuario usuog afecta al ogAdmclient.cfg ===
+La contraseña debe cambiarse en varios sitios, se resolverá en versiones posteriores.
+
+En esta versión se pondrá un mensaje informativo explicando que al modificar la clave el cliente OpenGnSys no puede acceder a los menús de inicio.
+
+== Ticket que pasan a la próxima versión ==
+=== #706        ogGetIpAddress() si no puede retornar dirección de red, devuelve código error 1 ===
+Todas las funciones Get deben tener el mismo tratamiento de los errores, ahora las de la librería Net.lib cuando se devuelve la cadena vacía no dan error pero otras sí lo dan.
+
+Se revisarán y se decidirá cual es el mejor comportamiento.
+
+
+== Más adelante ==
+=== Script de arranque ===
+Ubuntu está cambiando el sistema de arranque de los servicios, en próximas versiones habrá que modificar los script de arranque de OpenGnSys.
+
+== Mejoras para la 1.1 ==
+=== System menu ===
+El cliente da un menú de arranque local, tanto en el browser como desde MBR.
+
+=== Modificar registro del Usuario de Windows. ===
+Existen herramientas nuevas que permite modificar el registro de Windows, incluso cargar un fichero .reg
+
+Las funciones que modifican el registro funcionan muy bien, se podrían añadir algunas que permitieran importar desde los fichero .reg. 
+
+Quizás permitirían en las diferenciales modificar el registro de Windows o incluir lo que necesite "camello" para la virtualización de aplicaciones.
+
+
+== Errores ==
+=== Instalación ===
+Al instalar en una máquina virtual con Ubuntu 12.04.5 daba como fallo que no encontraba determinados paquetes. Puede deberse a un error puntual de red, se volverá a probar.
+
+=== Agente Windows ===
+
+En Barcelona siguen sin usar el agente de Windows, ya que sigue bloqueando el cliente. Mejora: Cuando el cliente no pueda comunicarse con el servidor, al pasar un tiempo determinado reinicie el servicio.
+
+!DiskFreeze permite administrar remotamente el pc para las acciones básicas, como apagar o reiniciar, y para comandos de la propia aplicación.
+
+== ogAdmServer central con repositorios por campus ==
+En Zaragoza tienen un servidor OpenGnSys de administración para todos los equipos pero un repositorio para cada campus, esto permite independizar el  tráfico de red de las distintas zonas. Parte del cliente de OpenGnSys es un recurso compartido del servidor y en este caso hay que compartirlo desde el repo. 
+
+La variable ogshare le dice al cliente cual es la ip del servidor que le ofrece este recurso, se le envía con un archivo PXE.
+
+El configurador del servicio PXE se encuentra en: 
+
+ - OpenGnSys 1.0.5=> ogBootServer() en /opt/opengnsys/www/gestores/gestor_pxe.php  
+ - OpenGnSys 1.0.6 => createBootMode() en /opt/opengnsys/includes/tftputils.php  
+
+en estos archivos tienes la configuración  recurso=servidor; por ejemplo el recurso ogshare=$server   indica que el recurso ogshare está en el servidor ogAdministator (base datos, web, pxe)
+
+{{{
+"""" contenido de la función  ogBootServer() o createBootMode()
+$infohost="vga=$vga ".
+          "LANG=$idioma ".
+          "ip=$ip:$server:$router:$netmask:$hostname:$netiface:none" .
+          " group=$group" .
+          " ogrepo=$repo" .
+          " oglive=$repo" .
+          " oglog=$server" .
+          " ogshare=$server";
+""""
+}}}
+En tu caso se debería cambiar    " ogshare=$repo".
+
+== RemotePC == 
+Se quieren utilizar los equipos de las aulas cuando estén libres para ofrecerlos como escritorios remotos. Para ello necesitamos que UDS (broker para máquinas virtuales) pueda hacer consultas al servidor OpenGnSys para saber qué equipos están disponibles y pedirle que los arranque. Hay que definir con UDS qué consultas necesitan realizar y cuál sería el formato.
+
+La disponibilidad horaria de los equipos residiría en UDS, que ya tiene esa funcionalidad.
+
+La comunicación se hará a través de una API rest que está muy avanzada. 
+
+En la base de datos por ahora sólo cambian dos campos:
+ - En la tabla aulas se añade "inremotepc" para indicar si estará disponible para remotepc o no.
+ - En la tabla user se añade "APIkey" que se devolverá después del login del usuario y se utilizará en la cabecera HTTP para autenticarlo.
+
+Las respuestas son en formato JSON.
+
+La API rest también podría usarla el cliente de OpenGnSys para solicitar datos a la BD del servidor.
+
+Málaga tiene integrado UDS con moodle a través de una API rest.
+
+Por otro lado, conviene unificar agentes en los sistemas operativos de las aulas: tendríamos el de OpenGnSys, el de UDS y Málaga tiene uno propio. Esto sobrecarga los sistemas operativos de servicios que arrancan al principio.
+
+El código está en los tickets de la versión 1.1, tiene un instalador que copia los ficheros y hace el cambio en la base de datos.
+
+Las pruebas se pueden realizar con el comando curl, que permite hacer llamadas http.
+
+== Difusión proyecto ==
+Se decide dar mayor difusión al proyecto para intentar aumentar el número de desarrolladores y crear una comunidad en torno a OpenGnSys donde puedan participar personas independientes de la Universidad.
+
+Se dará de alta en la  Free Software Foundation y se incluirá en la incubadora The Apache Software Foundation (ASF). Esto último requiere bastante trabajo. Uno de los primeros pasos es definir la licencia del código de OpenGnSys y revisar la del código de terceros que utilizamos, se podría ver como se hace en una distribución de linux ya que utiliza mucho código de diferentes fuentes.
+
+Habrá que traducir la página del proyecto al inglés.
+
+
+ 
+
+
+
+== Reunión presencial ==
+Se abrirá una página en el wiki para ir recogiendo ideas que debatir en la reunión.