Changes between Initial Version and Version 1 of Reunion210317

Timestamp:

Mar 29, 2017, 11:40:37 AM (8 years ago)

Author:

irina

Comment:

--

Reunion210317

@@ +1 @@
+[[TOC(heading=Índice)]]
+= Acta videoconferencia 21 de marzo de 2017 =
+Asisten: Teruel, Málaga, Huelva y Sevilla \\
+Próxima reunión: 4 de abril a las 11:30
+
+Nota: En algunos temas se repasa la reunión anterior.
+
+== Máquina virtual para entorno de desarrollo ==
+
+=== Instalación de la nueva consola ===
+Se ha incluido en el vagrantfile el código para que instale todo lo necesario para la consola web nueva. Hay que descomentarlo. 
+
+Realiza los siguientes pasos:
+ * Instala los requisitos.
+ * Instala Angular.
+ * Instala algunas dependencias que faltaban (provisional).
+ * Copia el código de la nueva web.
+
+
+=== Cómo crear una máquina virtual con vagrant ===
+
+ * Renombrar el fichero [source:branches/version1.1/installer/vagrant/Vagrantfile-devel-vbox Vagrantfile-devel-vbox] a Vagrantfile.
+ * vagrant up → despliega el servidor por ser la máquina por defecto.
+ * vagrant up ogclient01 → equipo modelo con Ubuntu 16.04.
+ * vagrant up ogclient0N → crea cliente número N como equipo vacío.
+
+
+
+=== Variables que se pueden configurar ===
+{{{
+# Number of OpenGnsys clients (accepted values: from 2 to 9).
+NCLIENTS = 4
+# Repository virtual disk: file and size (GB).
+REPODISK = "ogRepo.vdi" 
+REPOSIZE = 50
+# Amount of memory for server and clients (MB)
+SERVERMEM = 1024        # Minimum: 512
+CLIENTMEM = 512         # Minimum: 256
+# Clients MAC address prefix.
+MACPREFIX = "08:00:27:0E:65:"
+NETPREFIX = "192.168.2."
+# Local port to access OpenGnsys Server. (1)
+LOCALWEBPORT = 8443
+}}}
+
+(1) El servidor no tiene instalado entorno gráfico. !VirtualBox permite redirigir un puerto de una máquina virtual a uno del hipervisor. Para ver la consola web de administración redirigimos el puerto 80 al $LOCALWEBPORT.
+
+La direcciones IP de las máquinas son el NETPREFIX.1N, siendo N el número del cliente. Para el servidor en NETPREFIX.10.
+
+=== Creación de la máquina ogAdministrator ===
+Pasos de este proceso:
+ * Toma como base un sistema operativo Ubuntu 14.04.
+ * Instala opengnsys versión 1.1.
+ * Utiliza setserveraddr para cambiar la ethernet del servidor que ha tomado la instalación por la correcta.
+ * Incluye clientes en el dhcp.
+
+Opcional (Hay que descomentar el código):
+ * Incluye cliente en la base de datos.
+ * Genera la configuración de arranque PXE para los clientes: ogClient01 con usuario administrador y el resto como usuario sin privilegios.
+ * Instala entorno de desarrollo de Angular.
+
+Al final muestra un mensaje informando de las url's para ver la consola web actual y la nueva realizada con angular.
+
+Manualmente hay que modificar en virtualbox las máquinas virtuales de los clientes deshabilitando la primera tarjeta de red (NAT), de esta forma la segunda arrancará por PXE.
+
+=== Instalación del equipo modelo ===
+
+En la  máquina del equipo modelo se puede instalar el nuevo agente de forma opcional:
+ * Instala dependencias.
+ * Instala nuevo agente.
+ * Parchea la configuración con la IP del servidor.
+
+== Cambios en la versión 1.1 ==
+=== !OgLive 64bits ===
+Los portátiles Lenovo no funcionan con el ogLive actual debido a que está basado en Ubuntu 32bit. Se crea un ogLive de 64bits que resuelve el problema.
+
+ * Hay que generarlo de nuevo, porque contiene una errata.
+ * Ocupa un poco más que el anterior, ya que a demás de las librerías 64bits hay que incluirle el paquete de las librerías de 32 bits para que se pueda ejecutar el browser.
+ * Al montar el segundo sistema de ficheros con unionfs hay que añadir una carpeta más para las "lib32".
+
+Está poco probado, por ahora ha ido bien.
+
+=== HTTPS ===
+En el archivo de configuración de apache se incluye una regla de reescritura para obligar a que el acceso a la consola y a la API REST sea por http.
+
+En la página de inicio de la consola se elimina la redirección que se hacía en las cabecera con el mismo objetivo.
+
+=== Directorio para los grupos ===
+En el script de instalación crea un directorio groups dentro del directorio images. Dentro de él se pueden crear los subdirectorios de cada uno de los grupos (aulas).
+
+Existen dos funciones para facilitar la postconfiguración según el grupo del equipo:
+ * ogGetGroupName devuelve el nombre del grupo del equipo.
+ * ogGetGroupDir  devuelve el directorio del grupo con el formato: /opt/opengnsys/images/groups/$nombre_grupo.
+
+=== Script actualización e imágenes sincronizadas ===
+Uno de los pasos de la actualización es comprobar los permisos del directorio de OpenGnsys, se ha modificado para que no cambien los permisos del contenido de las imágenes sincronizadas (tipo directorio).
+
+Al crear las sincronizadas se utiliza la opción de rsync --numeric-ids, que transfiere los archivos identificando a su propietario por el identificador numérico (no teniendo que ser usuarios existentes en el servidor).
+
+=== Imágenes sincronizadas ===
+
+==== Espacio en disco: Btrfs y cloneImage ====
+
+Se han hecho pruebas con zfs, pero al realizar una actualización de la cache el cliente se quedaba completamente colgado. 
+
+Para comprimir las imágenes sincronizadas se va a usar el sistema de ficheros btrfs para la cache. 
+ * Permite montarlo con compresión, realizándose de forma transparente al leer o escribir en el disco. 
+ * Si posteriormente se monta sin compresión los archivos siguen siendo accesibles, pero los que se escriban en este momento no serán comprimidos.
+ * Comprimiendo con zlib se alcanza casi un 50% de compresión.
+
+No podremos saber cuando ocupa una imagen en cache.
+ * El comando du da la información de lo que ocuparían los datos sin comprimir.
+ * El comando df sí da la información del uso de sistema de fichero teniendo en cuenta la compresión.
+
+
+Por otro lado, hasta ahora para crear una imagen se partía de un directorio vacío en el repositorio y se sincronizaba con la partición del equipo modelo. Nota: el sistema de ficheros estaba empaquetado en archivo que se montaba al crear o restaurar la imagen.
+
+Ahora antes de sincronizar si existe una imagen del mismo sistema operativo se crea una copia con enlaces duros, por lo que no ocupa en espacio en disco. Después al sincronizar sólo ocuparán los archivos que cambien.
+
+Para ello se han creado:
+ * el script de servidor '''cloneimage''':
+{{{
+cloneimage: Copia con enlaces "duros" una imagen sincronizada tipo directorio.
+     Formato: cloneimage image_name new_image_name
+     Ejemplo: cloneimage Windows7 Win7Office
+}}}
+ * la función '''ogInitImage''':
+{{{
+ogInitImage: Inicializa la imagen tipo directorio: clona una similar o crea un directorio vacío.
+     Formato: ogInitImage [ REPO | CACHE ] image [ num_disk ] [ num_part ]
+     Ejemplo: ogInitImage REPO Ubuntu16 1 1
+     Ejemplo: ogInitImage CACHE Windows10
+}}}
+
+ ogInitImage Antes de clonar la imagen elige la más parecida: busca si hay alguna del mismo sistema operativo y si son varias clona la del tamaño más parecido.
+   - Al crear la imagen toma los datos de tamaño y tipo de sistema operativo de la partición de origen. 
+   - Al actualizar la cache toma estos valores de la imagen del repositorio.
+
+Habría que crear una función ogCloneImage similar al script de servidor para que la elección de la imagen a clonar se pueda realizar manualmente.
+
+Las pruebas se ha documentado en [wiki:SyncronizeZfs#PruebasconBtrfs Pruebas con Btrfs]
+
+==== Transferencia multicast ====
+Para aumentar la velocidad de restauración se está probando la transferencia multicast de las imágenes sincronizadas. El proceso tiene tres pasos:
+ * En cada cliente con rsync se crea un listado con los ficheros que hay que modificar y se envían al servidor (unificándolo con los que ya se hayan mandado).
+ * El servidor envía a todos los clientes los ficheros del listado por multicast.
+ * Cada cliente vuelve a ejecutar rsync para comparar los atributos y enlaces. 
+
+En el segundo paso el conjunto de ficheros que se envían se empaquetan en un tar, de forma que sólo se envía un archivo que se desempaqueta en el destino.
+
+Hay un punto débil que es que cada cliente crea el listado de los ficheros que necesitan y luego los manda al servidor. En el momento que se inicia la transferencia multicast en el servidor si algún cliente no ha mandado su listado puede que le falten archivos. No habría problema, sólo supondría que el paso tercero con rsync tardaría más tiempo.
+
+=== API REST ===
+
+En los datos de configuración de los discos del cliente, en la información de cada partición se incluye el número de disco. Hasta ahora calculaba el número de disco por el orden de los datos que envía el cliente, pero en el formato JSON los datos no tienen que estar ordenados.
+
+En la ruta para solicitar el estatus de los clientes se incluyen dos estado nuevos: 
+ * macos: cuando el equipo está con el agente de macOs.
+ * unknow: cuando no ha devuelto información. Por ejemplo en un fallo de las comunicaciones.
+
+Se cambiarán la denominación "ogclient" por "oglive" en todos los lugares donde aparezca.
+
+=== ogAgent ===
+Funcionalidades: Permiten apagar, reiniciar, solicitar el estado y, en Linux y Windows, ejecutar un script.
+
+En Windows hay que tener en cuenta que hay que escapar las contrabarras para que el código se ejecute correctamente.
+
+__Para Mac__
+
+Crear el entorno de desarrollo tarda mucho, pero lo que es la creación del paquete para la instalación es rápida.
+
+Para realizar la instalación en el equipo modelo:
+{{{
+   - Instalar dependencias (la instalación debe realizar estas operaciones):
+        sudo easy_install pip
+        sudo pip install netifaces requests six
+   - Descargar el fichero e instalar el agente:
+        sudo installer -pkg OGAgentInstaller-Version.pkg -target /
+   - Configurar el agente:
+        sudo sed "/remote=/ s,remote=.*,remote=https://IPServidorOpenGnsys/opengnsys/rest/," /Applications/OGAgent.app/cfg/ogagent.cfg > /tmp/ogagent.cfg
+        sudo mv /tmp/ogagent.cfg /Applications/OGAgent.app/cfg/ogagent.cfg
+   - Iniciar el servicio (se iniciará automáticamente en el proceso de arranque):
+        sudo ogagent start
+}}}
+
+Cuando se hayan hecho más pruebas con el cliente nuevo se decidirá si en está versión se ofrece sólo el agente nuevo o si también se mantiene el antiguo. 
+
+El agente actual, al ser la comunicación persistente, si hay algún microcorte en la red puede a dejar el sistema operativo sin acceso a internet. El nuevo agente no tiene esté problema.
+=== Cambio de grub4dos a grub2 ===
+
+Se está probando a arrancar los equipos por pxe con grub2, por ahora hemos encontrado las siguientes ventajas.
+
+   * Soporta UEFI. La mayoría de los equipos nuevos viene con está característica y tenemos que ponerlo en modo "heredado" para que funcionen con OpenGnsys.
+   * Está actualizado. Grub4dos no se mantiene desde hace 7 u 8 años. 
+
+Trae muchos módulos para reconocer discos, sistemas de archivos, ...
+
+Preparar el servidor para utilizar grub2 cpn PXE se realiza con un solo comando.
+
+El formato de la configuración del arranque de los clientes varía, por lo que habrá que modificar las plantillas. Los archivos PXE se almacenarán en un directorio diferente de  las de grub4dos, /opt/opengnsys/tftpboot/boot, que dentro contendrá un subdirectorio templates.
+
+También se probará si es posible el arranque en caliente de Windows, que desde el kernel 3.7 no es posible con grub4dos. 
+
+Aunque se ve avance muy importante, no se esperará a que este acabado este ticket para sacar la versión.
+
+=== Foro: ogCreateMbrImage ===
+Hay [message:662 una pregunta] sobre un error de la función ogCreateMbrImage con Windows 10. 
+
+Aparentemente se debe a que no tiene permisos de escritura en el repositorio. Se responde al mensaje.
+
+== Errores detectados ==
+
+=== Imagen duplicada ===
+
+En Sevilla tenemos problemas cuando un equipo además del monitor tiene conectado un videoproyector o una pizarra interactiva, a veces no duplica la pantalla o incluso no se enciende el monitor si no está arrancado el proyector. Huelva también tiene el mismo problema. Hay que probar si cargando los módulos de vídeo de grub2 se soluciona.
+
+=== ogSetPartitionId ===
+Da error cuando el equipo tiene una única partición y no realiza el cambio.
+
+Se debe a que se manda un sentencia al comando fdisk, que en caso de ser una única partición necesita un dato menos, y el comando no la entiende, saliéndose con error.
+
+=== Configuración PXE ===
+En la mayoría de las propiedades que afectan el arranque del equipo, cuando son cambiadas se regenera el archivo PXE. Cuando se mueve un equipo de grupo no se realiza el cambio.
+
+Hay que revisarlo.
+
+=== default.sh y variable OG_IP ===
+El fichero /opt/opengnsys/client/etc/preinit/default.sh permite cargar un script de arranque personalizado atendiendo a la IP o el grupo del cliente. Para el primer valor se usa la variable OG_IP que parece que no está definida en ningún lugar.
+
+Se definirá en /opt/opengnsys/client/etc/locadenviron.sh.
+
+La función ogGetIpAddress utiliza la variable IPV4ADDR, si existe toma este valor y si no utiliza el comando ip para obtenerla. Se plantea utilizar está variable en default.sh para que no haya dos variables con el mismo significado.
+
+== ogLive ==
+El ogLive tiene una serie de recursos compartidos. Habría que revisar su uso y realizar un reestructuración de los mismos. 
+
+== Imágenes de sólo lectura ==
+Interesaría poder marcar la imagen como sólo lectura, de forma que no se pudiera modificar.
+
+Es útil en el caso de un servidor en cada centro (OU) con las imágenes del mismo más un servidor de imágenes básicas que es accesible por todos los centros pero que no permitiera modificarlas.
+
+Aspectos a tener en cuenta:
+ * Desde la consola ¿quién marcaría la imagen como sólo lectura? ¿los usuarios/OU's tendrían permisos diferenciados: unos de sólo lectura y otros de lectura y escritura? Esto sólo se podrá realizar la consola permita distintos perfiles de usuario.
+ * Para la línea de comando podríamos tener un fichero "readOnly" donde esté el listado de las imágenes que son sólo lectura, de forma que los comandos que modifican la imagen lo consulten antes de empezar.
+ * Una opción rápida, y provisional, es tener el directorio de las imágenes, o cada imagen concreta, con permisos de sólo lectura para el usuario de OpenGnsys.
+ * El repositorio podría tener dos partes, una compartida con las demás OU, y otra sólo local para los equipos de mi OU.
+
+De este entorno también surge el ticket de que puedan existir imágenes con igual nombre canónico en distintas unidades organizativas.
+
+
+
+
+