Changes between Initial Version and Version 1 of Reunion210916

Timestamp:

Sep 23, 2016, 11:29:17 AM (8 years ago)

Author:

irina

Comment:

--

Reunion210916

@@ +1 @@
+[[TOC(heading=Índice)]]
+= Acta de la videoconferencia del 21 de septiembre de 2016 =
+
+Asisten: Huelva, Málaga, Teruel, Valencia y Sevilla. \\
+Próxima reunión: 5 de octubre
+
+== Repaso a los ticket abiertos de la versión 1.1 ==
+
+=== #372        comandos y asistentes deberían limitar equipos de operación dentro de ámbito ===
+Es un ticket antiguo. Cuando se realiza una acción sobre un ámbito podemos seleccionar a qué ordenadores queremos mandársela.
+
+Málaga revisar el ticket y lo cerrará.
+
+=== #385        Servicios OG para varias vlan aisladas ===
+Fue un caso puntual. Un servidor con dos tarjetas de red a dos VLAN separadas. Actualmente está en desuso.
+
+La funcionalidad de la transferencia multicast entra varias VLAN, aportaría una solución a este problema.
+
+Se cierra el ticket.
+
+Si hubiera problemas parecidos se crearía un ticket concreto para ellos.
+
+=== #715        revision ogConfigureFstab y #716        revisión ogCleanLinuxDevices ===
+Son funciones de postconfiguracióh de Linux útiles cuando se hace el arranque dual. 
+
+ * ogConfigureFstab: regenera el fichero /etc/fstab con la configuración actual del equipo.
+ * ogCleanLinuxDevices: limpia los dispositivos del equipo de referencia. Interfaz de red ...
+
+No se llaman desde el fichero configureOs. Se incluirán es este script, comentadas y con una descripción de las mismas para que sean fáciles de utilizar.
+
+Se cerrarán los dos tickets.
+
+
+=== #718        Nuevo agente modular con comunicaciones REST ===
+
+En está versión se sustituirá en agente antiguo por el nuevo.
+
+En la consola en las propiedades del pc hay una lista desplegable que permite bajarse los archivos de instalación para los distintos sistemas operativos. El agente se instala en el equipo modelo y hay una función que hay que incluir en la postconfiguración para que cambie los parámetros necesarios, el más importante la ip del servidor de OG.
+
+Se ha creado una función para desinstalar el agente antiguo de los equipos.
+
+La comunicación entre cliente y servidor tiene seguridad, está cifrada y autenticada; Se crea una clave aleatoria que se guarda en la base de datos y se utiliza para garantizar la identidad de los extremos.
+
+El agente comunica al servidor los cambios de estado: arranque y apagado del sistema operativo, inicio y salida de sesión de usuario. El servidor registra todos los mensajes de los clientes.
+
+El servidor puede mandar solicitar información del estado a los clientes y mandar comandos de apagar, reiniciar y ejecutar un comando en python. Con esto se tiene la misma funcionalidad que con el agente antiguo.
+
+Más adelante se pueden incluir otras acciones del servidor. Por ejemplo, mandar mensaje de cierre de sesión en x minutos o solicitar un pantallazo del cliente.
+
+
+
+Málaga ha probado el agente con éxito en Linux, Windows, !MacOs y raspberry. Los dos últimos toman el modulo del linux del agente OG. 
+
+La instalación en !MacOs pide usa serie de dependencias, habría que documentarla.
+
+Aqua puede mandar peticiones al agente. En vez de codificar en el agente un módulo para aqua se ha creado una clase en php que interacción con el agente OG.
+
+Si en el script de python que se le envía al cliente se cargan las clases del sistema operativo se pueden ejecutar comandos del mismo o script que llamen a los comando. Para que el sistema operativo donde se ejecuta el agente sea "transparente" para cada funcionalidad creamos los script de cada sistema operativo con el mismo nombre podemos llamarlos con un script de python desde el comando "ejecutar script". 
+
+La única "limitación" del cliente para aqua, es que obligatoriamente tiene que estar en comunicación con un servidor OpenGnsys.
+
+El agente de OpenGnsys toma como punto de partida el agente de UDS, está pendiente cambiar la información de la licencia.
+
+
+
+=== #708        Crear API REST para integración de OpenGnsys con UDS ===
+
+La API REST nos abre muchas posibilidades, para esta versión la funcionalidad será que necesite RemotePC.
+
+Sólo queda pendiente algo de la seguridad. Ej: En una unidad organizativa se puede preguntar por un repositorio y aunque no pertenezca a la unidad devuelve sus datos.
+
+Sí está realizado que la comunicación vaya cifrada y se autentiquen las partes.
+
+
+=== #139        Documentación y manuales completos. ===
+Es un ticket muy antiguo. Se podría cerrar y crear en cada versión un ticket para la documentación de la misma.
+
+
+
+
+=== #726        Reducir el registro de errores y avisos en algunas operaciones ===
+
+Se modifican las funciones que lanzan mensajes o errores:
+* La función ogRaiseError consulta la variable NODEBUGFUNCTION en el engine.cfg, con el nombre de las funciones que no mostrarán errores si se llaman desde un script, si se llaman desde línea de comandos sí lo harán.
+
+* La función ogEcho consulta si la variable DEBUG="no" para no incluir el fichero de log del cliente en mensajes que incluyen nivel de incidencia. La variable puede incluir dentro de un script. 
+
+Más adelante se podría introducir una variable que defina el nivel de depuración. 
+
+* La función ogRaiseError tendría como parámetro el nivel de debug a partir del cual se muestra el error y consultaría esta variable.
+
+* Esto es muy laborioso, ya que habría que revisar todas las llamadas a esta función. Se deja para la próxima versión.
+
+Se cerrará el ticket.
+
+
+=== #724        Cliente ogLive 1.1.0 basado en Ubuntu 15.10 o Ubuntu 16.04 LTS  ===
+Hay cambios en los comandos de Ubuntu 16.04 que han obligado a modificar las funciones:
+ * Al obtener el tamaño de los sistemas de ficheros mandaba una trama que colgaba el servidor de ogAdmServer. Se debía a que el comando pasó de mostrar un valor numérico  con el tamaño en K a mostrar una cadena poniendo la unidad de Gb, Mb, etc; la base de datos no lo aceptaba porque no era entero y colgaba el servicio.
+ * Al crear las particiones lógicas hay que dejar une espacio de 2048k al principio de la extendida.
+ * En el comando sfdisk cambia la sintaxis y las opciones, ha habido que sustituirlo por otros o modificar los argumentos que se le pasan.
+
+El cliente nuevo se está usando en Sevilla con la versión 1.0.6 por necesidades del hardware, está bastante probado y va bien.
+
+Málaga está interesada en seguía usando el cliente antiguo, se probará con la nueva versión por si es compatible. 
+
+
+
+
+=== engine.cfg ===
+Al actualizar OpenGnsys, sería importante no machacar el archivo engine.cfg para conservar la configuración de la versión anterior. 
+
+Una opción sería al instalar hacer una copia de seguridad de la versión anterior antes de copiar el nuevo fichero. Se informaría al terminar la actualización.
+
+
+=== #736        Mejorar la seguridad del servidor ===
+Se ha creado un script que configura el cortafuegos y SElinux en Ubuntu y Fedora.
+
+Hay que probarlo en distintos entornos para garantizar que no se deja cerrado ningún puerto que necesite OpenGnsys. 
+
+Se podría copiar en la instalación de OpenGnsys pero que se instale posteriormente de forma manual.
+
+Se documentará.
+
+Se incluirá en la versión si da tiempo, pero no se esperará a su finalización para cerrarla.
+
+=== #709        Script para instalar módulos del Kenrel en el cliente ogLive ===
+
+El script automatiza el proceso de instalar módulos previamente compilados para el Kernel del cliente ogLive e incluirlo en su Initrd. Los módulos deben de ser de la misma versión del kernel.
+
+El script debe utilizar un archivo comprimido tar.gz con los ficheros de los drivers compilados (con extensión .ko) y un fichero module.conf con los datos de instalación de los módulos. El formato de este último fichero puede incluir las siguientes clásulas:
+
+{{{
+    module=NombreMódulo
+    file=FicheroMódulo
+    path=CaminoInstalaciónFichero 
+}}}
+
+Se cerrará el ticket.
+
+Más adelante hay que buscar un procedimiento para tener los oglive de producción con los driver más actualizados.
+
+Ej: Directorio para que contenga los driver de un kernel concreto y al instalar que el script de instalación de OpenGnsys los detecte y los instale con el script installmodule
+
+Otra opción es ir incluyendo en el oglive de producción los nuevos driver. Se ve complejo:
+ * Los oglives de nombran con la versión y el número de revisión del proyecto. Los nombres no coincidirían.
+ * El oglive de la versión de estable se prueba mucho antes de sacarlo, cambiarlo puede producir en algunos sistemas errores no detectados.
+
+Hay un script que permite instalar los distintos oglive que están situados en la zona de descarga del proyecto, los nuevos podrán solventar los problemas de driver aunque hay que probar que sean compatibles con la versión del server que tengamos.
+
+Más adelante se quiere ofrecer distintos oglive a los clientes, se pueden abordar las dos cosas de manera conjunta.