wiki:Reunion121213

Videoconferencia 12 de diciembre de 2013

Asisten: Huelva, Málaga, Barcelona y Sevilla.

Próxima reunión: 16 enero de 2014

Huelva

Los compañeros de Huelva nos comentan que no van a poder seguir trabajando en el proyecto.

Su trabajo hasta ahora ha sido muy importante para el desarrollo de opengnsys y los vamos a echar mucho de menos.

Esperemos que sea una ausencia provisional y que podamos seguir contando con ellos lo antes posible.

Versión 1.0.5

Script de restauración

Se han modificado los script de restauración para que se comporten igual tanto si se realiza desde la consola como desde la línea de comandos.

El equivalente a la restauración desde la consola lo realiza el script deployImage, pasos que realiza:

  • updateCache: sólo si es necesario bajarse la imagen a cache.
  • restoreImagen: dándole como origen la ip del repositorio, que puede ser la cache del propio equipo u otro.
  • configureOs.

Se harán pruebas con todos los protocolos y se sacará la beta.

Imágenes diferenciales.

Una imagen de windows: desde cache tarda unos 2 o 3 minutos, desde el repositorio unos 5min.

La restauración de las acl se hace con ntfs-3g.secaudit y tarda mucho. Se realiza con la partición desmontada y hay que hacerla de la totalidad de la imagen. Habría que buscar la manera de realizarla sólo sobre los ficheros que se han modificado.

Al crear las imágenes diferenciales se utiliza el listado de los ficheros que cambian para filtrar el archivo de backup de las acl, de forma que al restaurar sólo se modifican las acl de los ficheros que han cambiado. El proceso de filtrar las acl es muy lento, por lo que es viable utilizarlo al crear una imagen pero en el momento de restaurar.

Convendría tener un script de servidor que cambiará de imágenes de partclone a imágenes sincronizables. Puede que en windows no sea posible debido a las acl.

En el caso de tener una imagen básica y una diferencial. Se plantea si al actualizar la imagen básica sigue siendo compatible con la diferencial. Esto dependerá de si la básica modifica algún fichero que pertenezca a la diferencial, en este caso será incompatible. Esto es particularmente importante con el registro de windows, no tenemos herramientas que nos permitan modificar el registro de forma fácil y sobre todo rápida, por lo que cualquier cambio en el registro hace que se copie el archivo entero en la diferencial.

En el formulario de creación o restauración de las imágenes sincronizadas encontramos tres opciones:

  • w (whole): el algoritmo incremental rsync no se usa y se envía todo el archivo. La transferencia puede ser más rápida cuando el ancho de banda entre las máquinas de origen y de destino es mayor que el ancho de banda en el disco. Se usa por defecto cuando se especifican el origen y destino caminos locales.
  • e (eliminar): Se compara el destino con el origen y se borran los ficheros que no estuvieran en el primero. En caso de que queramos mantener los archivos que han creado los usuarios, quitamos la opción eliminar.
  • c (comprimir): comprime los datos durante la transferencia.

Tickets

La mayoría están hechos ya.

  • Arranque con kernel 3.8 → se pasa a la próxima versión.
  • Script de instalación interactivo (pide las variables) → hecho.
  • Imágenes diferenciales → hecho.
  • Agente de Windows → parece que se ha corregido el error. En la beta se descomenta su instalación en el configureOs.
  • Conexiones de los clientes con el ogAdmServer que no se cerraban → está corregido.

Mejoras para la versión siguiente:

Checksum.

Para garantizar que la transferencia de una imagen del repositorio a cache a sido correcta se utilizan sumas de comprobación, actualmente se comprueban los 100Mb últimos. Normalmente esto es suficiente, pero en algunos casos la imagen se ha corrompido a mitad pero la transferencia a continuado y no se detecta el error.

Realizar la suma de comprobación de la totalidad de la imagen requiere mucho tiempo (del orden de 8 minutos)

Para la próxima versión se podrían tener dos sumas de comprobación, una del final y otra de la totalidad del fichero.

Varios clientes de opengnsys.

Queremos tener varios cliente opengnsys en un mismo servidor, de forma que ha cada equipo se le envíe el más apropiado. Por ejemplo, permitiría gestionar equipos pc y mac con un mismo servidor. Hasta ahora no era posible,porque el procedimiento que se utiliza para el “updateinitrd” el PXE exigía que el cliente estuviera en el raíz de directorio tftpboot.

Para El proceso de actualización del initrd habrá que ver cómo identifica el equipo cúal es el ogclient que le corresponde. Quizás baste incluir la versión exacta del oglive.

Mac.

Málaga particiona los equipos y después de esto no pueden activar el journaling en el sistema de fichero. Están interesados en redimensionar el sistema de fichero hfs+, hasta ahora no se ha encontrado la forma. Serían necesario probar un cliente de opengnsys con otros kernel. Arrancan el sistema operativo desde el cliente OG reiniciando. Están intentando meter el grub en la partición de mac.

Se pondrá la imagen iso del usb de arranque de mac disponible para descargar. Es demasiado grande para tenerla en el trac, se pondrá en un “drive” de Google y se enlazarla a la web del proyecto.

Consola.

En el formulario de propiedades del aula hay que introducir los datos de la red en casillas de texto. Se podría crear una tabla con los distintos perfiles de red y en la tabla de aulas sólo asignarlos.

Last modified 2 years ago Last modified on Jul 14, 2017, 1:07:08 PM