[[PageOutline(2-5,Índice)]] = Acta videoconferencia de 17 de febrero de 2016 = Asisten: Málaga, Huelva y Sevilla \\ Próxima reunión: jueves 10 de marzo a las 11:30 == Versión 1.0.6a == Se revisan los cambios desde la última reunión: === #732: Integrar cambios básicos para ampliar calendario en versión 1.0.6a. === Permite crear tareas programadas hasta 2017, en la versión 1.1 se ampliará hasta 2025. === #721 Consola Restaurar Imagen: falla el filtro de equipos === Existían dos problemas: * En algunas aulas al lanzar el comando restaurar no se enviaba la acción a los equipos. * En aulas con equipos con distintas particiones la selección del tipo de particionado no funcionaba, y se mandaba la acción a todos los equipos del aula. Se debía a una inconsistencia entre el filtro por equipos y el filtro por grupos de ordenadores. === #733 No se genera tabla de partición en discos vacíos === Si se particiona un disco nuevo sin tabla de particiones, se produce un error a la hora de crear una tabla de tipo MSDOS y no se ejecuta la operación. Se adapta la generación de una nueva tabla MSDOS, creando y borrando una partición antes de guardar la información. === ogUnmountAll === Se ha corregido la función ogUnmountAll, dejaba montada la cache. === Postconfiguracion de Windows 10. === Se incluyen las opciones necesarias para la postconfiguración de Windows 10. === #734 Liberar versión de mantenimiento OpenGnsys 1.0.6a en rama principal === === Se comienza el periodo de prueba === Se considera que todas las correcciones están realizadas y sólo queda probar la versión para sacarla lo antes posible. == Versión 1.1. ticket pendientes == === Particionado con sectores de 4096 === Los discos nuevos no admiten los sectores de 512, se soluciona cambiando el tamaño de los sectores a 4096. Se incluirá en la versión 1.1 y no en la 1.0.6 porque el cambio provocaría que al modificar una única partición de un disco duro se perderían todas las demás (por no coincidir el tamaño de los sectores del particionado anterior y el nuevo) === Pasar parámetros del kernel en el arranque de Linux === El sript bootOs permite que se le pasen los parámetros del kernel como argumentos. No está implementado en la consola, aunque sí se podría realizar con el comando "ejecutar script" === !OgLive basado en 15.05 con paquetes para la resolución de vídeo === Al cliente anterior le faltaban los paquetes que permiten configurar la resolución de vídeo por lo que no tomaba los parámetros del kernel que se le pasaban en el arranque PXE. === #731 Soporte para cualquier versión de Windows === Intentar generalizar los cambios para que se pueda soportar el arranque y la postconfiguración de cualquier versión de Windows (incluido Windows Server). Buscar patrones para poder distinguir cual es la versión de Windows que tiene el equipo. == Repositorios con servicios Web. == Se plantea a partir de la necesidad de arrancar los clientes de !OpenGnsys desde el repositorio. Huelva tiene los equipos en distintas subredes por lo que el arranque por Wake On Lan necesitan hacerlo desde los repositorios (situados en cada subred) en vez de hacerlo desde el server. Análogamente la idea de la API REST del server, podrían usarse Servicios Web en el repositorio para que el server le envíe la solicitud de arranque de los clientes. Inicialmente esta será la única función de este servicio. Aspectos a tener en cuenta: * Comunicación segura entre el server y el repo. En el caso de la API REST del server a los usuarios se les añade una clave de acceso, al hacer login el servidor le manda la clave que debe incluirse en las cabeceras de autorización en cada transferencia. * Existen dos escenarios: el server y el repo separados o ambos en la misma máquina. Esta funcionalidad se incluirá en la versión 1.1.0 El servicio ogAdmRepo no se está utilizando actualmente. Se decide quitarlo de la próxima versión. También se podría tener API REST en los equipos, como la comunicación es por http los mensajes pasarían de una subred a otra. == Alta disponibilidad == En Huelva tanto el server como el repo están replicados en máquinas idénticas a cada uno de ellos. Los dos server comparten una ip virtual y utilizan heartbeat. El repositorio se conecta a la ip virtual. Al instalar opengnnsys toma mal la IP, se modificará el instalador para que al encontrar dos IP (local y virtual) pregunte al usuario qué poner. Hay que incluir en la consola la configuración de heartbeat. == Pruebas con ansible == Ansible permite mandar lista de tareas para que se ejecuten en un conjunto de equipos remotos. Se puede valorar si interesa incluirlo en OpenGnsys, aporta muchos módulos que permiten realizar instalaciones y configuraciones de los sistemas operativos. En la consola se podría incluir un "ejecutar playbook" análogo al comando "ejecurar script". == Hardware nuevo == No funcionan los USB. Se puede probar la última versión de ogLive que trae un kernel más nuevo y soporta dispositivos más recientes. == updateInitrd == updateinitrd es una función que se ejecuta al arranque el cliente de opengnsys. Consulta si existe el parámetro del kernel ogupdateinitrd con valor true y en este caso si existe cache copia el kernel y el initrd del cliente a la misma, ya sea actualizándolo o instalándolo por primera vez. Parece que la última versión ha cambiado, hay que comprobar que el funcionamiento es el correcto == API REST == Málaga va a empezar a probar la versión 1.1., incluida la API REST Script para crear el entorno de programación: /opt/svn/branches/version1.1-tickets/OGAgent-ticket718/installer/ogagent-devel-installer.sh. Construye el entorno Wine, necesario para el agente de Windows y genera los paquetes instalables de los agentes para los sistemas operativos (!Windows/Linux) En los sistemas operativos se tienen que instalar estos paquetes. Tienen un fichero de configuración con la ip del servidor. No contiene la IP del cliente, esto permite instalar en el agente en el equipo modelo antes de hacer la imagen, no teniendo que realizarlo en la postconfiguración. Al arrancar el agente informa al server. En la consola se ha cambiado la página de status para que detecte los clientes antiguos y los nuevos. El agente de linux puede utilizarse en el cliente de OpenGnsys, aunque actualmente tiene un funcionalidad muy básica. Esto ha conllevado el cambio en el script de arranque del cliente de opengnsys (default.sh) que comprueba si no existe el cliente antiguo y inicia el nuevo agente.