Acta día 16 de septiembre de 2015

Asistentes: Barcelona, Zaragoza, Málaga y Sevilla

Próxima reunión: 8 de Octubre de 2015

Agente nuevo

El agente del sistema operativo consta de dos componentes.

• proceso de servidor -> habla con servicio ogAdmServer y con proceso en espacio de usuario.
• proceso en espacio de usuario -> sólo habla con componente servidor.

Cambia la forma de comunicación cliente-servidor.

Notificaciones al ogAdmServer: on, off, login y logout.

Cambio en el server.

• Registra los equipos.
• Consulta estatus: tenemos nuevos estados cuando en el equipo se ha hecho login en Windows o en Linux. Se detecta consultando si está arrancado o no el componente de usuario.
• comandos apagar y reiniciar.

Para las pruebas se esta usando un fichero de registro init.log donde se anota el inicio, parada, etc de cada equipo.

Todo el código está subido en el ticket, sólo falta documentar. Se plantea que en una videoconferencia hagamos "un curso" sobre el nuevo agente, para que los demás podamos participas en el desarrollo más adelante.

Hay un script para generar los paquetes de instalación y desinstalación. Desde linux se crean los instalables para Windows, Linux en formato rpm y deb. Se tiene un paquete diferente para Suse porque los archivos de configuración van en otro sitio.

Hay un archivo tgz en la zona de descargas del proyecto con el siguiente contenido:

• Fichero léeme con las instrucciones.
• El instalable de Windows: es un archivo ejecutable donde sólo hay que dar a siguiente, siguiente.
• El instalable de Linux es un paquete con dependencias que pedirá al instalar.
• En el fichero de configuración hay que configurar la variable remote con la url que la API REST del server.
  • Linux /etc/ogagent/ogagent.cfg y Windows Archivos de Programa/ogagent/ogagent.cfg.

La ip del cliente no va en el archivo de configuración, esto permite instalarlo en el equipo modelo.

El agente de linux se podrá usar como cliente de OpenGnsys para el oglive, aunque aquí no necesitamos la parte de usuario sino sólo la de administración. Queda por construir el resto de las funcionalidades.

Falta seguridad. La API REST del server sí tiene seguridad: el equipo hace login con usuario y clave y el server le envía un token que le sirve para mantener la sesión abierta.

Por si alguien quiere probarlo, para realizar el código se está usando eclipse con los pluging de pydev y pysys (mantiene la compatibilidad entre distintas versiones de python).

Posibles aplicaciones

Barcelona está haciendo un proyecto de inventario al que le puede ser muy util la API REST para consutar los datos necesarios, actualmente le dan derecho de lectura directamente a la BD.

RedIris

El uso de los equipos físicos de las aulas fuera del horario lectivo a través del acceso remoto con UDS se presentará en las próximas jornadas Técnicas de RedIris.

Versión actual: 1.0.6

Fallo en Usb de ogclient para MAC

Funcionaba perfectamente en la versión 1.0.5.

En la instalación de la 1.0.6 sobre Ubuntu 14.04 falla. Hay que seguir probando si es algo puntual o un error en este entorno.

Aula con varios grupos

Al ejecutar comandos sobre el aula falla.

Falla la programación de tareas

Piensan que es de su instalación. Seguirán probando.

Error al crear imagen

En el paso de reducir el sistema de archivos de error y no crea la imagen, además en Windows se corrompe el sistema de archivo del equipo modelo y no se puede arrancar de nuevo.

Pensamos que se debe a que existen datos en el sistema de ficheros que no pueden ser reubicados, debería ir bien si antes de crear la imagen en el equipo modelo se aplican las herramientas de Windows para limpiar el sistema de archivo, defracmentar y hacer un chequeo del disco (checkfs).

Versión 1.1

Consola de administración

En la página de configuración de los equipos se ha añadido el % del uso del sistema de ficheros.

BootOs

El script de arranque bootOs permite pasarle parámetros pare el kernel de linux. Ya está hecho.

Comando pgrep

Ha cambiado el formato de salida en Ubuntu 14.04, hay que revisar qué script lo utilizan y revisar si funcionen bien.

Próximas versiones del oglive

El cliente es de 32bits para que se pueda ejecutar en todos los equipos, por ello el tamaño máximo que puede ocupar el oglive es 2gb. Al generar el cliente estamos rozando ese tamaño, habrá que eliminar cosas.

No sabemos exactamente qué impone el límite, puede que sea el comando schroot.

Arranque de Windows en caliente

Hay unos tipo de hardware que arrancar bien con kexec y grub4dos, pero al cambiar la versión de la BIOS dejan de hacerlo.

Para acortar el tiempo de arranque de los sistemas operativos, se esta buscando un gestor de arranque visual. Con el que se está probando no usa el ratón.

Fecha de la imagen restaurada

Se guarda en la bd al restaurar, pero se borra. Hay que revisar en qué ocasiones y cómo evitarlo. Parece que pasa al iniciar el cliente y regenerar la configuración del mismo.

También se pierde el nombre de la imagen cuando cambia el tipo de Sistema Operativo, ej de WinXP a Win7, pone 0 en las BD y se pierde el nombre de la imagen.

Se creará un ticket para resolverlo.

Propiedades del aula

Hay propiedades que pertenecen a los equipos, en caso de tomar diversos valores en el aula aparece el desplegable vacío que puede dar lugar a confusión. Se mostrará un mensaje informativo.

Si se cambia el valor de la propiedad se cambiará en todos los equipos, pudiendo dejarlo vacío para dejar la propiedad sin configurar. Si se elimina se mostrará un mensaje de alerta.

Torrent

Para imágenes entre 90 y 100Gb varía mucho el tiempo de restauración entre unos equipos y otros (entre una y tres horas). Si los equipos tienen configurado el tiempo de compartir el archivo con un valor bajo dejan el servidor KO. Se está probando que valores son los más adecuados.

Sería bueno que fuera un valor dinámico que dependiera del tamaño de la imagen. En la consola de administración se podría poner esta valor como fijo o como variable, en el segundo caso se calcularía el más conveniente.