Acta de la videoconferencia del 4 de julio de 2013

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

Próxima reunión: jueves 18 de julio de 2013.

Estado de la versión 1.0.5.

El asistente de particionado no informa al servidor cuando termina la acción.

Se decide que el comando reboot, que tiene un sleep por defecto de 5, admita un parámetro que sea el valor del sleep.

En el caso de Huelva con un sleep de 10 segundos funciona bien el asistente.

Arrancar equipos con wake on lan usando unicast.

Si el cliente de opengnsys se apaga automáticamente por ahorro de energía no enciende luego con Wake on lan. Sí enciende si apaga desde el sistema operativo linux y windows o con el comando apagar lanzado desde la consola. No se ha probado si se usa el enlace del menú por defecto.

También se ha observado que si se pone la espera para apagar por ahorro de energía en 600, los equipos se apagan antes.

Log en tiempo real.

Para seguir el progreso de la restauración multicast se ha cambiado el script que filtra la información de los comandos para mostrarlos en el log en tiempo real.

Es un script que depende completamente de la salida de los distintos comandos. Se plantea para la próxima versión cambiar la forma de mostrar los log. Actualmente, para ejecutar un comando y mandarlo a la zona de sesión se ejecuta:

comando parámetros | tee -a $OGLOGSESSION

Se propone crear una función que haga ésto un poco más legible, de esta manera:

ogExecAndLog SESSION comando parámetros

Diferenciales con cliente 1.0.4.

No se podría usar la versión 2 de sincronizadas, porque necesita el sistema de ficheros btrfs, pero sí la uno, que almacena los datos de la imagen en un directorio.

El fichero necesario para conectar con el servicio rsync del repositorio se crea al usar el comando "setsmbpass" de la versión nueva del server.

Cliente opengnsys.

Seguimos teniendo el problema del inicio de sesión de windows directo. Sí funciona en las máquinas virtuales.

Dificultades:

Los cambios en el kernel
3.7 cambia el vídeo.
3.8 cambia la arquitectura para poder soportar más dispositivos y dejan de soportar los 3.86

Grub4dos detecta los datos de la bios para acceder al disco duro. No conseguimos que con este kernel los detecte. Podría deberse a un parámetro que haya que pasarle al kernel.

Se plantea hacer dos clientes de prueba:

• un cliente 3.8 desde cero, por si se ha olvidado algo.
• actualizar el cliente de la versión 1.0.4.

Error en las tareas programadas.

Al crear una tarea se ejecuta bien si elegimos "ejecutar inmediatamente" funciona bien, pero si realizamos una programación el cliente o muestra el log en tiempo real y se queda esperando un comando o se cuelga. La siguiente vez que se arranca el cliente no se inicia el browser.

Mejora: compatibilidad con otros dispositivos.

Se creará un nuevo ticket para que la consola sea compatible con las tablet, móviles, etc.

En estos dispositivos no podemos utilizar el botón derecho del ratón, se podrá acceder a los mismos comportamientos con el botón izquierdo. Afectan a varias páginas que aparecen en el marco izquierdo de la consola web.

Para no modificar las páginas se crean nuevas páginas con "extensión" .device.php que se llamarán cuando se detecte que es un dispositivo de este tipo.

Página nada.php: se muestra al entrar en opengnsys. Actualmente en blanco, se ha pensado mostrar la versión de opengnsys y otor datos de interés. Cuando se ponga en el ticket se valorará el resultado.

Base de datos nueva.

Se ha mandado la última versión de la base de datos con los cambios que se han comentado. Habría que revisarla de nuevo. Cuando esté definitiva se seguirá modelando los procedimientos, las tareas, etc.

• La tabla grupo permite agrupar entidades iguales, uno de los campos en un identificador de tipo de entidad. Habrá que crear una tabla con los distintos tipos.

• Unidades organizativas con o sin acceso. Se ha resuelto asignado unidades a los usuarios que pueden acceder a ellas, que tendrá permiso en la unidad y en todos sus hijos.

• Posibilidad de incluir pluging que modifiquen la base de datos: con Symphony puedes hacer un modulo con unos determinados objetos que tomen como base los objetos del "núcleo principal".

• Posibilidad de comunicar con con otras bases de datos (ej. glpi): no debe haber problema, basta definir la conexión a la otra base de datos.

• Permisos de distintos usuarios: Symphony permite establece roles y aplicarles permisos de acceso a distintas url. El tema de la seguridad se realizará un poco más adelante.

Esto nos permitirá tener distintos perfiles: operador, administrador,... a los que se le asociará unas unidades administrativas y unos determinados roles dentro de las mismas.

• Compatibilidad con Drupal: drupal 8 está programado con Symphony, cualquier módulo programado con Symphony se convierte automáticamente en un módulo de drupal.

Instalación de ticket.

Hay que tener cuidado, un ticket perteneciente a una versión posiblemente no funcionará en otra.

Antes de crear un script de intalación conviene comprobar que es compatible con nuestra versión.

Cómo cerrar los ticket.

El trac cierra los ticket asignádoles un estado. Se redefinen los estados y su significado:

• resuelto: Esta terminado e integrado en la rama principal de desarrollo.
• por integrar: Está terminado, en la rama de los ticket y queda probarlo antes de integrarlo en la rama principal de desarrollo.
• opcional: Está terminado, en la rama de los ticket. No se integrará en la rama principal de desarrollo porque es un comportamiento opcional de openGnSys.

Al cerrar los tickets se documentará en el wiki las pruebas realizadas. Como los tickets pertenecen a una versión concreta de openGnSys la información se situará en el banco de prueba de esa versión, preferentemente en una página dedicada a ticket. En la versión 1.0.5 tenemos Banco de pruebas por ticket versión 1.0.5

Curso Online: documento de terminación de curso.

Nosotros no podemos certificar.

El equipo de desarrollo de opengnsys informará de la realización del curso.

Se establece que la duración del curso equivale a 50 horas, aunque se cree que en realidad es superior.

Se pondrán en la carpeta de dropbox certificados que tengamos de otros cursos que hayamos hecho para tomarlos como ejemplo.

Versión Beta.

Se propone sacar una versión beta cuando al menos tengamos comprobado que funcionan los comportamientos de la 1.0.4.

Zaragoza podrá realizar pruebas en la segunda quincena de julio.

Gestión de MAC con cliente 3.8.

En MAC no existe PXE. El arranque se realiza en local, el grub nos redirige a un kernel que busca el servidor PXE y este nos envía el cliente opengnsys.

Luego se le puede ordenar que reinicie en local para arrancar el sistema operativo MACOS.

Problemas para clonar la partición EFI, la reconoce pero no permite clonarla. Solo habría que modificar un parámetro de la base de datos "clonable" de 1 a 0 (creo, quizás es al revés).

En internet se ha encontrado que se utiliza PXE con MAC, parece que es verdad para las versiones antiguas.

Otras distribuciones de linux.

Puede que tengamos problemas, por ejemplo openSuse marca la partición GPT como Windows y crea un sistema de ficheros btrfs. Habrá que revisar que no quede ningún script que al detectar el contenido de la partición se base en el tipo de partición y no en el sistema de fichero.