[[PageOutline(2-5,Índice)]] = Acta videoconferencia del 20 de julio de 2020 = Asisten; Málaga, Zamora, Valencia, Teruel, Huelva, Zaragoza. \\ Próxima reunión: en septiembre == Remote pc == Hacer un comando para poder compartir o no el aula. === Permisos === En los calendarios de UDS hay que dar permisos a todos los usuarios. Se pueden dar permisos limitados a usuarios para un pull concreto: leer el calendario o gestionarlo. __Como asignar permisos__ Selecciona pull -> permisos - autenticador -> usuario o grupos definidos. === Directivas de Windows === Las directirvas de Windos para uds funciona muy bien. Reunión con UDS: Implemntar Nuevo campo en prop de pc Agente que notifique tipo de session del s.o. W RDP o LOCAL. Linux más opciones para local. modo texto y modo grafico Si contiene la cadena RDP es remoto. Es el patrón que se repite. API rest remotePc. par que un pc particular inicie sesión en la partición indicada. Si un pc que estuviera reservado se apagará. -> parámetro opcional del pull de servicio. -> si al conectarse el user el estado es apagado puede inicar el pc o marcarlo como no válido * Cuando un usuario presencial entra. OG tendrá que recisar si el pc está reservado y si es así informar a UDS. * Cuando quitamos marca de acceso remoto al equipo lo mismo. El agente tiene los cambios pero da problemas a crear el instalador para Windows con python3 64 bits con qt5. No se puede generar en una máquina linux, es necesario una máquina Wíndows. === Compatibilidad actualización UDS === Los cambios que haga UDS deben ser compatibles con las versiones anteriores de OpenGnsys. Al menos las últimas. * Si UDS manda parámetros de más la API REST de OG no tendrá problemas. * Si UDS necesita que le notifiquen más parámetros no será posible con las versiones anteriores. =============================== Poner equipo en modo mantenimiento. Se puede seleccionar el modo mantenimiento para que el equipo no se utlice por UDS. == Drivers de Windows == Imagen Windows al restaurarla buscan todos los driver, tardando bastante. En Granada en la postconfiguración se restaura el registro con la rama de hardware para equipo concreto. En otras universidades las imágenes tienen todos los hardware, Windows al arrancar es quien seleccionen. El perfil hardware ahora mismo es informativo, podría usarse para restaurar el perfil de hardware correspondiente al equipo. Ahora se le pasa por pxe la variable del perfil de hardware, si el nombre del archivo de registro está asociado al nombre del perfil de hardware en la postconfiguración se puede restaurar. Sólo es necesario un script que lo realice, pero no se necesario cambiar nada más. Podría ser una mejora. == Liberar versión 1.2 == Los cambios principales de la versión 1.2 ya se han realizado: - Se reescribe el código del ogAdmServer introduciendo muchas mejoras, pasando a llamarse ogServer - Se recodifica en python el ogAdmClient pasando a llamarse ogClient. - La comunicación entre el ogClient y el ogserver se realiza a través de una API REST. - ogcli script de servidor para comunicarse con el ogserver, aportando una alternativa a la interfaz web. - Cambios en remotePC fruto cde la puesta en marcha en estos meses. No se van a añadir más funcionalidades; Pasamos a la fase de estabilización Arranque del un pc para remotePC Llamada ogrepo mete un elemento en tabla acciones. -> la tablas sólo las tocará el ogServer == Problemas actualización == En Málaga al actualizar desde la versión 1.1.0a con Ubuntu 16 a la 1.1.1c en la base de datos se quedan algunos campos con valor por defecto NULL, esta definición no se soporta por la versión de mysql dando problemas en la consola. == Problemas con la información de la imagen == En Zamora se sique con el problema al crear la imagen. se crea bien el fichero de partclone pero la información de la imagen no se guarda en el repoinfo.json Parece un problema en la ejecución del script checkrepo por el cron. Puede deberse a los permisos de los ficheros de información de la imagen.