[[PageOutline(2-5,Índice)]] = Acta videoconferencia 23 de Mayo = Asisten: Hueva, Málaga, Teruel, Zaragoza y Sevilla. \\ Próxima reunión: 6 de junio a las 11:30 == Pruebas UEFI == En Teruel se están haciendo pruebas con equipos con UFI. Los resultado iniciales los vemos en la siguiente tabla: [[Image(UEFI.png)]] __Arranque PXE__ En modo legacy funciona correctamente con la imagen PXE que tenemos. En modo seguro como no tenemos una imagen firmada UEFI no lo reconoce. Se han probado con dos imágenes que se sitúan en el directorio tftpboot: || Fichero || Instalado como || Origen || Resultado || || shim.efi || bootx64.efi || firmado en el paquete de las fuentes shim-signed || BIEN en el modo seguro || || grubnetx64.efi || grubx64.efi || firmado en el paquete de la fuentes de grub2 || MAL en el modo seguro || Hay que configurar el servidor DHCP para que discrimine los equipos que arrancan en modo BIOS o en modo UEFI con el fin de enviarles la imagen de arranque TFTP apropiada. Hay varias formas de hacerlo. Una de ellas: {{{ # en opciones generales option arch code 93 = unsigned integer 16; # dentro de la subred de OGN # 0000 == IA x86 PC (BIOS boot) # 0006 == x86 EFI boot # 0007 == x64 EFI boot if option arch = 00:07 { filename "bootx64.efi"; } else { filename "grldr"; } next-server x.x.x.x; }}} Archivo de arranque PXE del cliente. Por ahora no se ha conseguido que tengan el mismos nombre: toma la MAC y separa los caracteres por ":" en vez de por "-". En Sevilla se habían hecho pruebas con grub2 y PXE y hay una expresión regular que se pone en el fichero de configuración del grub2 en tftp que permite que el grub reconozca el nombre de fichero que tenemos. __Arranque de Windows con reinicio__ Las marcas del arranque de Windows * No las puede modificar el grub2. * Se podrían sustituir por la función setBootMode. El tiempo de reboot se podría bajar para que no tardara tanto. * Los gestores de arranque pueden llamarse uno a otro. Si grub2 no tiene una funcionalidad podría llamar a grub4dos. * Tenían varios propósitos además del inicio con reinicio era el seguimiento después de la restauración Si usamos setBootMode habría que tener plantillas PXE para arrancar cualquier partición (en todas las que haya un Windows instalado). Dos opciones posibles * Se podría crear la plantilla temporal desde el comando setclientMode. * Podríamos tener dos tipos de plantillas: ocultas o visibles a la consola. == Últimos cambios versión 1.1 == === Arranque personalizado === En el script /opt/opengnsys/client/etc/preinit/default.sh se utilizaba una variable inexistente (OG_IP) para identificar el arranque de un host concreto según su IP. Se cambia a la variable IPV4ADDR que sí está definida en esa etapa del arranque del equipo. IPV4ADDR es una variable del kernel, por lo que siempre que la tarjeta de red tenga asignada una ip la variable existirá. === Instalación del Grub en el cliente === Se utiliza el script '''/opt/opengnsys/client/scripts/grubSyntax''' que tomaba el valor de variable definidas en el entorno y fallaba. Se ha solucionado inicializando las variables DISK y PART a un valor vacío. Además se tiene en cuanta la arquitectura del sistema (32bits o 64bits) para definir el grub_probe que se utiliza. === Efecto colateral de variables no locales === Cuando en una función no definimos la variable como local queda en las variables de entorno de los siguientes script que se ejecutan. Se ha encontrado el comando '''shellcheck''' que nos permite revisar los script bash y hace recomendaciones de mejoras posibles. === setBootAvanzado === Se modifica la ayuda, poniendo la nomenclatura correcta de la plantilla (nombre de la columna en !NetBootAvanzado) y el parámetro que define si el cambio es definitivo o temporal === oglivecli === En la opción setdefault, que permite definir cuál es el cliente por defecto, daba error porque había un "exit" utilizado en las pruebas. Ya está corregida. === ogAgent === En la API rest faltaba una "," en una sentencia SQL. Ya está corregida. === Configuración mysql === Al hacer el curso con Ubuntu16, las opciones que trae el servicio mysql por defecto no permiten que se vea bien la configuración de la tabla de particiones. Ha habido que eliminar una limitación a las sentencias GRUPOBY. === Backup de disco externo === En el nuevo cliente fallaba porque cambia la versión de partclone. Las funciones restoresImageSintax y createImageSintax utilizaban partclone.dd que en los cliente nuevos pasa a llamarse partclone.image. Se han modificado para que vayan bien en todos los cliente: === Doxigen === En las páginas de ayuda generadas por doxigen no aparecen todas las funciones; Posiblemente en los comentarios habrá algo que esté mal. Se puede ejecutar desde la línea de comandos y si existen errores mostrará mensajes informativos. == Servicios de OpenGnsys == Se incluyó la optimización de la memoria que propuso Zaragoza. Se ha modificado el servicio encargado de las tareas programadas, hay que probarlo exhaustivamente. Se había planteado sacar una versión de mantenimiento con el cambio de los servicios de OpenGnsys y el nuevo agente de sistema operativo, pero si la 1.1 sale pronto no se considera necesario. == Ticket pendientes == === #773 Incluir script personalizado para bootOs === Sólo falta incluir en el arranque del cliente que borre las marcas de arranque de Windows que puedan existir. Antes estaba en el script de inicio de sesión pero no era el sitio correcto. === #768 Ofrecer diferentes ogLive a los clientes === Hay que revisar el script {{{setsmbpassword}}} para asegurarnos que cambia las claves de los clientes que están dentro de los directorios. __Recursos remotos de ogLive__ Las distintas etapas del cliente de opengnsys se encuentran en: * 1ª fase (kernel e initrd) en el server * 2ª fase (segundo fs) en el repositorio Para una arquitectura distribuida es complejo. Se modificará de forma que la segunda fase también esté en el server. En las plantillas PXE en la variable oglive hay que cambiar la IP del repositorio por la del server. __oglive con kernel 3.2__ Se generará un nuevo cliente con kernel 3.2 que permita actualizar el kernel y el initrd en cache estando en el servidor dentro de un subdirectorio de tftpboot. El cambio principal reside en el script ogfunctions en la función que actualiza la cache. === Consola: página de "Ayuda" === Incluir la información de que estamos en el directorio de la "Free Software Fundation" y que seguimos el "Berlín Code of Conduct" == Ejemplo de páginas de inicio == Se ha creado un [forum:13 foro] para que se puedan compartir los menús de inicio personalizado. La idea surgió en el curso de Barcelona, después de ver algunos muy elaborados. Animamos a poner en común los menús que utilicemos para que los puedan aprovechar las demás universidades. == Foro versión 1.1.0 == Se creará cuando esté el tgz de la versión beta. == Presentación !RedIris == Se presentará la * Versión 1.1.0 beta. * Remote pc. === Remote pc === * En las propiedades del aula y de las imágenes se puede seleccionar el uso para remote PC. * Los sistemas operativos de los clientes deben tener instalado el agente nuevo. En UDS (broker) definimos: * Un proveedor de servicios. Con los datos para conectar UDS al servidor de Opengnsys: IP, puerto, url y usuario. * Un servicio. Con los datos de la imagen, el aula, la unidad organizativa a que pertenece y el tiempo máximo de reserva. \\ Si el valor del aula está vacío se utilizará cualquier equipo que tenga esa imagen. * Datos del despliegue: número máximo de equipos disponibles, número de equipos arrancados y horario en el que están disponible (hora de inicio, duración, ...) Paso de mensajes: [[Image(remotePC_mensajes.png)]] == Curso avanzado == Los participantes ya usaban OpenGnsys y estaban muy interesados. Se ha realizado con el servidor sobre Ubuntu16.04, con la versión 1.1 y con el ogLive con kernel 4.8. En general ha ido muy bien pero se han detectado algunos errores. === Curso de la API REST === Uno de los participantes pidió que se hiciera un curso sobre la API REST. Ha realizado un aplicación en angular que permite controlar los cañones de video de las aulas, si las pantallas tuvieran arduino y fueran controlables por la red también se podrían gestionar. Le interesa acceder a la API REST para encender el equipo del profesor. También se comenta la posibilidad de hacer plugins para ocs, etc. == Mejora de la consola de administración == En próximas versiones se crearán dos ticket para mejorar la consola: __Mejora interprete php__ Se utilizará el servicio php-fpm en vez del módulo de apache. * mejora el rendimiento. * permite subprocesos. En el wiki en la lista de compatibilidad de la versión se podría poner un apartado para optimizar el servidor con un enlace a la documentación de cómo se realiza el cambio. __mysql motor de almacenamiento__ Se cambiará myisam por innodb, que permite integridad referencial. == Mejora en la configuración del cliente == Sería interesante que el archivo engine.cfg se pudiera personalizar para un aula o equipo concreto. Puede que sea suficiente incluir abajo unas líneas que carguen fichero de configuración personalizados. Al estar al final se reescribirían los valores generales. Por ejemplo: {{{ # Personalización por grupo [ -f $OGETC/engine-${OGGROUP}.cfg ] && source $OGETC/engine-${OGGROUP}.cfg # Personalización por IP del equipo [ -f $OGETC/engine-${IPV4ADDR}.cfg ] && source $OGETC/engine-${IPV4ADDR}.cfg }}} == Página web amigable == Se propone hacer una página web que facilita el acceso a OpenGnsys. Tendría la información básica para poder utilizarlo: descarga de la última versión, manual de usuario en pdf, enlace al foro. Sería una "capa" por encima de la página actual, que seguiría existiendo. En el curso de Barcelona una persona se ofreció a ayudarnos con la usabilidad de la página del proyecto, habría que ponerse en contacto con ella.