| 1 | [[PageOutline(2-5,Índice)]] |
| 2 | |
| 3 | = Acta videoconferencia 10 junio de 2020 = |
| 4 | |
| 5 | Asisten: Málaga, Valencia, Teruel, Sevilla y Granada \\ |
| 6 | Próxima reunión: 23 de junio a las 11:30. |
| 7 | |
| 8 | == Versión 1.1.1b == |
| 9 | |
| 10 | Ya se ha liberado. |
| 11 | |
| 12 | * Se publica el archivo para la instalación |
| 13 | * Se cambia el archivo que informa de los cambios de las versiones: CHANGELOG.es.txt |
| 14 | * Se publica en la página de usuario y en la principal del wiki de desarrollo. |
| 15 | * En esta última hay una errata que hay que corregir. |
| 16 | |
| 17 | Problema con script de actualización: se bajaba el código de la rama master, que ya tiene muchos cambios de desarrollo. |
| 18 | |
| 19 | Se ha creado una rama 1.1.1c con los cambios del script de actualización. |
| 20 | |
| 21 | == Últimos cambios == |
| 22 | === #519 Consola: gestión de iconos en parte de administración === |
| 23 | La parte de administración de la consola permite modificar los iconos que se muestran en la web. Al gestionarlos hay errores poco importantes. |
| 24 | |
| 25 | Este ticket No se resolverá para está versión de la consola, podría implementarse en una nueva web de administración. |
| 26 | |
| 27 | |
| 28 | === Modo offline === |
| 29 | |
| 30 | Había una pregunta en el foro debido a que se intentaba utilizar el modo offline sin cache. |
| 31 | |
| 32 | Se le ha contestado Esto no es posible ya que en el modo offline en la cache se alojan el cliente de OpenGnsys: el kernel, el initrd y el segundo sistema de ficheros. |
| 33 | |
| 34 | === Pasos para la clonación de un equipo === |
| 35 | En el foro preguntaban si había lista rápida de cómo hay que se clona equipo. Se le ha contestado poniendo los pasos. |
| 36 | |
| 37 | Se podrían añadir algunas tareas como procedimientos predefinidos. |
| 38 | |
| 39 | En Teruel usan una plantilla PXE con menú de opciones. Se puede arrancar de disco duro o desde ogLive. |
| 40 | |
| 41 | Los estudiantes arrancan desde HD directamente. Si va un técnico arranca desde el ogLive |
| 42 | |
| 43 | |
| 44 | === #944 Mostrar la distribución de equipos en el aula === |
| 45 | |
| 46 | En el estado del aula se pueden disponer los equipos en una cuadrícula que represente la situación real en el aula. |
| 47 | |
| 48 | Se crean 2 campos nuevos en la tabla ordenadores que se corresponden con sendos campos del formulario "Propiedades de Ordenador" para indicar la fila y la columna que ocupa cada equipo dentro del aula y se modifica la pantalla de Estado del aula para mostrar la rejilla, si los campos son enteros positivos (si hay valores a 0, se muestra con el formato antiguo). |
| 49 | |
| 50 | Se Ha completado el ticket y se cierra. |
| 51 | |
| 52 | |
| 53 | |
| 54 | === Sustitución del ogAdmClient por ogclient === |
| 55 | Está completado. |
| 56 | |
| 57 | |
| 58 | === Problema con el script de actualización === |
| 59 | Al bajarse el ogAgent no lo encuentra porque busca que tenga la versión 1.1.1c que no existe. Inicialmente se ha subido el tar.gz de la 1.1.1b renombrado. |
| 60 | |
| 61 | Se solucionará de forma definitiva añadiendo al fichero de la versión la información de la versión del ogAgent. |
| 62 | |
| 63 | === #976 ogBootMbrGeneric: mejora en la compatibilidad con GPT === |
| 64 | Era una mejora que sólo afectaba a las particiones tipo GPT en sistemas BIOS. Como está situación es poco común no se resolverá. |
| 65 | |
| 66 | Se cierra. |
| 67 | |
| 68 | === Imágenes sincronizadas === |
| 69 | |
| 70 | Granada estaba restaurado imágenes sincronizadas con Git. Se ha parado bastante con el confinamiento. |
| 71 | |
| 72 | * No se consigue restaurar Windows desde la versión de 1909. |
| 73 | |
| 74 | * Tienen aulas con GIT y otras como forma nativa de OpenGnsys (partclone). |
| 75 | |
| 76 | Por otro lado, no sabemos si se están usando las sincronizadas con rsync, se podría preguntar en la lista de usuarios. |
| 77 | |
| 78 | |
| 79 | === Problema con la clonación de Windows 10 Pro 2004 64 bits. (#432) - Message List === |
| 80 | |
| 81 | Generalizo el gestor de arranque en windows: |
| 82 | |
| 83 | {{{ |
| 84 | bcdedit /set {current} osdevice boot |
| 85 | bcdedit /set {current} device boot |
| 86 | bcdedit /set {bootmgr} device boot |
| 87 | bcdedit /set {memdiag} device boot -> Vale por si se invoca el test de memoria (normalemnte no se usa) |
| 88 | }}} |
| 89 | |
| 90 | La última línea se utiliza si se va a invocar el test de memoria(normalemnte no se usa). |
| 91 | |
| 92 | |
| 93 | Para desactivar el inicio rápido realiza: |
| 94 | {{{ |
| 95 | reg ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet?\Control\Session Manager\Memory Management\PrefetchParameters?" /v EnableSuperfetch? /t REG_DWORD /d 0x3 /f |
| 96 | }}} |
| 97 | Está instrucción es incorrecta, '''NO''' desactiva el inicio rápido |
| 98 | Es lo que está puesto en la documentación. Habría que cambiarla. |
| 99 | |
| 100 | No se ve dónde está situado la carpeta del arranque del sistema. Harían falta más datos para contestarle |
| 101 | |
| 102 | == Erratas versión 1.1.1b == |
| 103 | |
| 104 | Se resolverán antes de sacar la versión. |
| 105 | |
| 106 | __ Mensajes de error__ |
| 107 | |
| 108 | Tras instalar un nuevo servidor de la 1.1.1b en un Ubuntu virtualizado aparecen mensajes de error debido al cron. |
| 109 | |
| 110 | En concreto de los scripts deletepreimage y torrent-tracker. Sería interesante revisar esos scripts. |
| 111 | |
| 112 | |
| 113 | == Open Rlabs == |
| 114 | Granada está interesada en este broker que ha hecho Teruel para el remotePC. |
| 115 | |
| 116 | Toda la información la podemos encontrar en http://www.openrlabs.es |
| 117 | |
| 118 | La consola de Open Rlabs distingue usuario administrador o usuario normal |
| 119 | |
| 120 | El usuario administrador |
| 121 | |
| 122 | * Pueden ver las sesiones abiertas. |
| 123 | * Se ven todas la OU y las aulas en imágenes preparadas con acceso remoto (la información la consulta al servidor OG). |
| 124 | * En las OU hay que configurar el usuario de acceso y su clave. |
| 125 | * Para gestionar los usuarios se pueden incluir archivo CSV o uno a uno. |
| 126 | |
| 127 | |
| 128 | Para el usuario normal aparecen los equipos disponibles. |
| 129 | |
| 130 | |
| 131 | '''Funcionamiento''' |
| 132 | |
| 133 | * Lanza WOL, y Inicio de sesión de OG -> Tarda 4 o 5 min |
| 134 | * En el servidor OG vemos en la cola de acciones el inicio de sesión |
| 135 | * Acceso a los equipos por ahora sólo utiliza RDP |
| 136 | * La autenticación de los usuarios la realizan contra un servidor de correo. |
| 137 | |
| 138 | No usan dominio windows por ahora, pero lo van a poner |
| 139 | |
| 140 | '''Instalación''' |
| 141 | |
| 142 | Es necesario: |
| 143 | |
| 144 | * Configurar apache y guacamole |
| 145 | * Instalar servidor OpenGnsys |
| 146 | * Instalar servidor openRlab |
| 147 | |
| 148 | Para montarlo hay un instalador automatizado, tarda una media hora. |
| 149 | |
| 150 | No está en docker. |
| 151 | |
| 152 | * Hay un contenedor docker de Guacamole, lo está intentado probar Granada pero por ahora está parado. |
| 153 | |
| 154 | '''Limitaciones''' |
| 155 | |
| 156 | No se puede trabajar con equipos que otras subredes, debido a que las peticiones del WOL de OG no dicen a qué subred se dirige. |
| 157 | |
| 158 | Si se lanza desde la consola por broadcast hace una doble llamada, desde el repo y desde el server. En los dos casos manda una petición a la propia subred, si el equipo está en una tercera subred no le llega el paquete. |
| 159 | |
| 160 | A la mayoría de los casos no afectaría esté problema porque los equipos están en la subred de servidor o del repositorio. |
| 161 | |
| 162 | Se solucionaría si en la función del ogAdmServer se añadiera el parámetro de subred. Dejando que el repo siga haciéndola igual. Se puede modificar para está versión. |
| 163 | |
| 164 | |
| 165 | Por otro lado, comunicaciones tiene que dejar pasar la petición de broadcast entre redes. |
| 166 | |
| 167 | == OpenGnsys VDI == |
| 168 | |
| 169 | Hasta ahora cuando los equipos tienen hardware heterogéneo es necesario tener una imagen para cada modelo. OpenGnsys VDI permite virtualización de los equipos cliente: |
| 170 | * Estandariza el hardware del equipo. |
| 171 | * Facilitaría el uso de OpenGnsys para equipos del PAS. |
| 172 | * Facilitaría gestión de aulas con diferentes hardware. |
| 173 | |
| 174 | El objetivo integrar de forma nativa OpenGnsys VDI, sin tener que modificar nada. |
| 175 | |
| 176 | OpenGnsys VDI es un sistema operativo hipervisor que instalaremos en el equipo modelo. Los sistemas operativos que usen los usuarios se instalarán como máquinas virtuales en el hipervisor. |
| 177 | |
| 178 | La tecnología de virtualización es qemu. |
| 179 | |
| 180 | Toda la información la podemos encontrar en https://opengnsys.soleta.eu. |
| 181 | |
| 182 | |
| 183 | '''Requisitos'' |
| 184 | |
| 185 | * BIOS soporte tecnología de virtualización activa. |
| 186 | * Instalación de debian normal. |
| 187 | * Importante que el usuario se llame "opengnsys" con la clave que se quiera. |
| 188 | |
| 189 | '''Funcionamiento''' |
| 190 | |
| 191 | * La operativa con el ogLive es igual. |
| 192 | * Por defecto toma la ip por dhcp. |
| 193 | * En la consola veremos el equipos arrancado en OpenGnsys VDI, hay que determinar un color para este estado. |
| 194 | * Por ahora soporta el despliegue en una sola partición. |
| 195 | |
| 196 | |
| 197 | '''Acceso remoto''' |
| 198 | |
| 199 | Ofrece un acceso remoto a los equipos desde casa sin instalar nada más. |
| 200 | * Se puede acceder por VNC al hipervisor. |
| 201 | * No hay que instalar en VNC en el s.o invitado. |
| 202 | |
| 203 | |
| 204 | == Sincronización git del trac == |
| 205 | En la información del trac aparecen datos que no corresponden con el estado del código. |
| 206 | |
| 207 | Se han subido cambios a git que no aparecen en la web de OpenGnsys pero sí están si realizamos un clone del repositorio. |