Acta videoconferencia del 26 de abril de 2016

Asisten: Valencia, Barcelona, Huelva, Málaga y Sevilla
Próxima reunión: 11 de mayo a las 11:30.

Versión 1.0 últimas modificaciones

#740 Clonar disco completo en modo "raw"

Se crean las funciones para crear la imagen de disco completo. Por ahora no se han incluido en la consola.

Habría que probarlas en profundidad, parece que en algunos casos no funcionan bien.

OGAgent: agente OpenGnsys para sistema operativo

Se crea documentación sobre el nuevo agente para los sistemas operativos. Incluye:

• Instalación en los distintos Sistemas Operativos.
• Mensajes entre OpenGnsys Server y OGAgent (API REST)
• Pruebas en los distintos Sistema Operativos.

Entornos de desarrollo estandarizados

Se crea la documentación para crear entornos de desarrollo estandarizados.

La ventaja es que se estandariza el entorno por lo que todos trabajaremos en las mismas condiciones.

En Windows no funciona bien vagrant con VirtualBox: se intenta conectar al la máquina por ssh y no puede. No parece que merezca la pena invertir tiempo en adaptar el fichero, simplemente se tendrán que hacer los desarrollos sobre linux.

Teniendo Vagrant y VirtualBox los ficheros vagrant te permiten crear un entorno de desarrollo de forma automática. Se han creado varios para entornos diferentes.

Fichero	Entorno	Recomendado para
Vagrantfile-trunk-vbox	Vagrantfile para la versión oficial de OpenGnsys (1.0.x).	Pruebas en general
Vagrantfile-devel-vbox	Vagrantfile para la versión de desarrollo de OpenGnsys (1.1.x).	Pruebas y desarrollo general
Vagrantfile-boottools-vbox	Vagrantfile para preparar el entorno de generación del cliente ogLive	Desarrolladores experimentados
Vagrantfile-browser-vbox	Vagrantfile para preparar el entorno de compilación del Browser del cliente	Miembros del grupo de desarrollo
Vagrantfile-ogagent-vbox	Vagrantfile para preparar el entorno de desarrollo del agente OGAgent	Miembros del grupo de desarrollo

Vagrantfile-boottools-vbox

Prepara el entorno para crear el minilinux que es el sistema operativo ce OpenGnsys.

Crea la máquina virtual con el sistema operativo limpio. Se descarga el código necesario y el script para crear el OGlive, que tiene que ser ejecutado por el usuario de forma que puede modificarlo si fuera necesario.

No hay red virtual en estos entornos, por lo que hay que pasar los archivos de cliente de OpenGnsys primero al hipervisor y de allí a donde queramos.

Vagrantfile-browser-vbox

Crear el entorno de desarrollo para el browser que utiliza el cliente de OpenGnsys.

El browser está hecho en c++ y qt. Al crear el entorno se compila el qt, este proceso tarda unas dos horas en terminar. Luego compila el browser con el código actual de la distribución.

Si se quieren realizar pruebas se pueden modificar el código y volver a recompilar.

Vagrantfile-ogagent-vbox

La máquina virtual es una distribución de Fedora porque las dependencias del Wine funcionan mejor. (El Wine es necesario para crear el instalador de Windows)

Se instala:

• Eclipse con las dependencias de python
• Entorno gráfico: necesario para Wine, cuando generamos el cliente de Windows hace algunas preguntas interactivas.

Hay que definir el proyecto del eclipse en el directorio donde está el código de OgAgent.

Modificaciones en el browser.

Se corrige un error que no permitía utilizar el browser en modo administración. Se debía a que los nuevos kernel utilizan una variable que utilizaba OpenGnsys para pasar la información del modo de trabajo del browser, se ha cambiado la variable por la que se le envía por PXE.

Por la necesidad del cambio anterior se crea el archivo Vagrant para automatizar el entorno de trabajo y se hacen las siguientes mejoras:

• Se incluye un reloj digital en la barra de estado.
• Se internacionaliza el browser utilizando gettext.

Uso del gettext

Se utiliza en todos los mensajes de texto.

Para la traducción se crean automáticamente unos archivos de extensión .po donde están los mensajes en el idioma original y debajo deben ponerse en el idioma final. Los textos que no estén traducidos se mostrarán en el idioma de partida.

Estos fichero se compilan (.mo) y se guardan en el directorio /lib/locale del cliente que es donde el binario del browser los buscará.

Se ha probado y funciona bien.

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

Se obtiene información del repositorio desde el servidor.

• repository/poweron: permite solicitar al repositorio que arranque clientes.
• repository/images: devuelve las imágenes del repositorio -> se podrá mostrar en la consola de administración.

Se ha creado un fichero independiente para la API REST del repositorio: www/rest/repository.php.

No ha necesario sido modificar las reglas de reescritura del apache, ha funcionado sin cambios.

Se ha introducido un nuevo parámetro "apiToken" en el ogAdmRepo.cfg, de manera que desde la consola web podamos indicar dicho token para comunicación con el repositorio.

• Se ha modificado la consola para mostrar información remota del repositorio siempre que se guarde el token del mismo en las opciones del repositorio.
• Se ha modificado el comando arrancar para que detecte si el ordenador a arrancar pertenece a un repositorio en una red distinta y cuenta con un token, se use el webservice para el comando arrancar.

Versión 2.0: nueva consola

Se decide implementar la consola web con angularjs, independizándola completamente del servidor y haciendo uso exclusivamente de la api REST proporcionada por opengnsys.

Ventajas de angularjs:

• Es un framework de Google, lo utilizaríamos para la parte del cliente.
• La versión movil sería directa, sólo cambiaría la presentación.
• Mejora el mantenimiento.

En el caso de procesos que tarden mucho (ej: reestauración) angularjs posee una clase que maneja respuestas asíncronas, cuando llegan devuelve error o la respuesta.

La parte de servidor se implementará inicialmente con el mismo framework que se está haciendo la API REST (Slim) y posteriormente puede pasarse a Symfony 2 o cualquier otro framework que se quiera. El único requisito que las rutas sean siempre las mismas y los parámetros de entrada y salida no cambien.

De esta forma la consola web, mostrará y modificará información y ejecutará comandos haciendo uso del webservice, y será el servidor quien realice las operaciones y devuelva el resultado.

La API rest del servidor podría sustituir el servicio actual de ogAdmServer.

El primer paso sería que implementar todos los "end points" del webservice necesarios para obtener toda la funcionalidad actual de la consola web de opengnsys. Para ello sería necesario ir documentando todas las rutas con sus parámetros de entrada y la salida.

Huelva se ofrece a ir solicitando (o incluso implementando) los "end points" del web service que fuesen haciendo falta e ir haciendo la nueva consola web.

Para la documentación del la API REST se puede utilizar swagger que partiendo de un fichero yaml y le da un formato adecuado. Si symfony utiliza alguna otra forma de documentar el código se podría mirar para que luego fuera aprovechable.

Se integrará el código que hay en la rama de ticket en la de la versión de desarrollo de la 1.1.

En la versión 1.1.1 queremos que el OgAgent nuevo sustituya servicio ogAdmClient que utiliza el cliente de OpenGnsys.

Otros

Borrar Clave de registro

La función actual para borrar una clave de registro sólo la borra si está vacía. Se creará otra que permita crear una clave con lo que tenga en su interior, manteniendo la existente con el comportamiento actual para evitar errores.

Tenemos la función ogDeleteTree que borra un subárbol de directorios, se podría llamar de alguna forma parecida.

Hardware nuevo: i229 Intel

No va bien con el cliente actual (que es el mismo que en la 1.0.5).

Le falta un driver. Lo tienen el driver compilado, por lo que se puede utilizar existe un script para instalar un script en el OGlive: en /opt/opengnsys/bin/installmodule

La ayuda del script nos muestra su comportamiento:

installmodule: installs kernel module into ogLive image (initrd).

Format: installmodule moduletarfile

moduletarfile must be a tar.gz archive with 2 files:
 - *.ko: compiled module
 - module.conf: configuration file

Configuration file format:
	module=ModuleName
	file=ModuleFile
	path=ModulePath

ModuleName must be a single word.
ModuleFile must be a kernel compiled module file (*.ko).
ModulePath must be the kernel target directory, started by "kernel/".

Claves de registro

Cuando la cadena es múltiple no se tratan bien. La función no lo tiene en cuenta, el cambio es complejo.

Boonding en el servidor de OpenGnsys

Barcelona quiere utilizar un servidor con bounding para OpenGnsys, en Sevilla se está utilizando y va bien. Sí es necesario configurar el switch para que reconozca esta configuración de la red.

Bloqueo de disco

Se ha creado una nueva función para crear un bloqueo el disco. Las funciones de bloqueo de partición lo van a tener en cuenta: si el disco está bloqueado la partición también se considera bloqueada.

Asistente de particionado:

Actualmente para particiones GPT siempre se pone la primera tipo EFI aunque el usuario hay a elegido otra cosa. Hay que ver cuales son las restricciones para este tipo de particiones y mostrar un mensaje de aviso en la consola de administración.

Nuevo OGclient

Se están probando nuevas versiones de ogclient.

La última tiraba al servicio del servidor al arrancar el equipo, se debía a un cambio en el formato en un comando que utiliza el script que obtiene la configuración del cliente.