wiki:Version2/Arquitectura

Version 4 (modified by adelcastillo, 13 years ago) (diff)

--

TOC(heading=Índice)?

Introducción

El sistema trata de simplificar el problema de repetir la operación de instalar una y otra vez, tanto en el mismo ordenador como en distintos ordenadores. Para ello se implementa una interfaz web desde que se pueda controlar que tiene instalado los ordenadores clientes.

Componentes del sistema

Servidor

Consola Web

Demonio OpenGnSys Server

Repositorio

El Repositorio es un servidor auxiliar para no tener que centralizar todo en un mismo ordenador. Su principal función es encender a los clientes por red, permitir que los clientes puedan arrancar por red y almacenar las imágenes que éstos utilizan para reinstalar los sistemas operativos. En la versión actual cada cliente tiene asignado un ÚNICO Repositorio, pero un Repositorio puede dar servicio a más de un cliente. Además puede haber más de un Repositorio y cada uno tendrá un grupo de ordenadores que administrará. Debido a la necesidades del arranque en red y el arranque remoto los Repositorios deben estar en el mismo ámbito de red que sus clientes. Por último recalcar que el Servidor también puede hacer las funciones de Repositorio si se configura adecuadamente.

Servicios

El Repositorio necesita correr unos servicios ajenos a OpenGnSys para que el sistema funcione. Todos están relacionados con el arranque en red de los clientes. Por ahora se usa DHCP, PXE, TFTP y NFS. El servicio DHCP obliga a que el Repositorio esté en la misma red que sus clientes. El DHCP permite coger una IP para arrancar en red, luego lo envía al servidor TFTP. De aquí se descargar el kernel y el initrd que usará para arrancar. El NFS guardará el resto de la distro que se arranca. Además NFS guarda los logs y las imágenes de los clientes. Por ahora OpenGnSys 2.0 no administra los servicios a través de la consola web. En futuras versiones, cuando sí se administren un cliente podrá tener varios Repositorios y cada uno puede tener una función distinta.

Demonio OpenGnSys Repo

Este demonio, por ahora es igual que el del cliente y si se sigue mantienendo general, seguirá siendo así. Simplemente recibe comandos, los ejecuta y manda la salida de vuelta al servidor. En el caso del repositorio puede usarse para configurar los servicios, arrancarlos, pararlos, reiniciarlos, etc. Pero eso será en futuras versiones ya que no está planeado para la versión 2.0. Por ahora sólo se usará para mandar la orden de arrancar ordenadores por red ayudándose del programa wakeonlan.

Más información en: wiki:Version2/Arquitectura/#DemonioOpenGnSysClient.

Cliente

El cliente es cada ordenador que administraremos desde la consola web. Para poder administrarlo completamente deben tener asociado un Repositorio. Principalmente arrancarán por red una distro preparada para realizar todas las funciones que un cliente de OpenGnSys debería hacer. También se trabaja para que esta distro pueda arrancar desde el disco duro y ganar así velocidad. Desde esta distro podremos modificar sus discos duros creando imágenes de sus particiones, restaurandolas, reparticionando, etc. Además también mostrará un menú donde el usuario podrá elegir las operaciones que les gustaría ejecutar, como reinstalar o arrancar un S.O.

OpenGnSys Live

Es una distribución que se ha creado desde el grupo de desarrollo. Se utiliza la tecnología live debian http://live.debian.net/ Actualmente se genera una Ubuntu Lucid. Con está tecnología podemos crear una distribución que tenga:

  • El menor software posible.
  • Los últimos módulos que permitan detectar el hardware más moderno.
  • El software cliente de OpenGnSys.
  • Arranque a través de una interfaz de red.
  • Arranque a través de un disco duro interno o externo.
  • Arranque desde CD-ROM.
  • Un arranque rápido.
  • Una animación en el arranque.

Engine

Actualmente una serie de funciones bash que permiten realizar todo tipo de operaciones de una manera sencilla. Las operaciones van desde saber que IP tiene el cliente, como crear particiones, crear imágenes, arrancar una partición, etc. Para llamar a esas funciones de una manera coherente se han creado scripts que llamaban a esas funciones bash. Muchas veces los scripts son simplemente una llamada a una función, pero otras hacen cosas más complejas y realiza una serie de procesos con diversasa llamadas a funciones.

Se está estudiando como mejorar este sistema ya que presenta limitaciones sobretodo a la hora de las comunicaciones con el Servidor.

Demonio OpenGnSys Client

Los scripts del engine se llaman a través de un servicio creado por nosotros. Este servicio recibe comandos desde el Servidor y los ejecuta. La salida la envía de vuelta al servidor. Este programa no es muy complejo, está hecho en Python. Es un servidor web usando webpy. En este puerto escucha peticiones, las parsea y si llega correctamente lo ejecuta. Si el proceso tarda mucho va mandando mensajes de que el proceso todavía se está ejecutando al Servidor. La salida la va mandando a medida que se va generando para que llegue la mayor información posible al Servidor, de esta forma se ha implementado un progreso para saber cuanto le falta.

Comunicaciones

TODO

Estructuración del código

El código actual de la versión dos se encuentra ahora mismo en el directorio de subversion: source:branches/version2. Allí encontramos varios directorios. Vayamos viendo que encontramos en cada uno.

art

Aquí debemos alojar todo los ficheros artísticos para OpenGnSys. Un ejemplo, creamos una imagen svg que luego para usarlo en la web la exportamos a png a un tamaño determinado para usarla en la web. Pues la imagen png deberá en su parte correspondiente en el código pero la imagen svg debería ir en este directorio para poder reutilizarla posteriormente. También encajarían aquí logo, diseños, sonidos, etc.

client_daemon

Aquí encontramos todo el código referente del demonio que corre en los clientes y también en los repositorios. El fichero principal es client_daemon.py que se ejecuta para correr el servicio. Encontramos además un fichero de configuración config.py. Los archivos acabados en *_tester.py se usan para realizar pruebas. En la carpeta ssl encontramos certificados usados para realizar las pruebas. La carpeta web es el webpy que usa el servicio para ejecutarse.

doc

Este directorio se aloja toda la documentación que no se encuentra en el wiki. Por ahora sólo hay un directorio para alojar diagramas y un web_html, que es el html generado por la herramienta ????? de la documentación python del proyecto. En estos momentos se encuentra muy desactualizada.

live

En éste hallamos los scripts que generan una distribución Ubuntu live mínima incluyendo el software necesario para ejecutar el cliente de OpenGnSys:

  • create_directories.sh: crea los directorios donde se va alojar el live resultante y algunos directorios vacios necesarios para crearlo correctamente en includes.
  • create_config_tree.sh: crea el árbol de configuración inicial de live-build.
  • generate.sh es el principal. Desde él se llama a los demás scripts y además carga la configuración. También descarga los últimos engine, client_daemon y scripts de svn. De esta manera se hará automáticamente.
  • gnsyslive.sh: es antiguo y será borrado próximamente. Es la antigua manera que generamos el live. Se pueden sacar ideas por eso no es borrado todavía.
  • hooks: contiene scripts que se ejecutarán dentro del live antes de ser generado definitivamente. Puedes añadir nuevos para añadir cosas o eliminar cosas de manera sencilla.
  • includes: contiene ficheros que se van a agregar al live directamente en su directorio raíz.
  • packages_lists: contiene ficheros que tienen dentro una lista de paquetes que serán instalados en el live automáticamente.
  • server: encontraremos ficheros de configuración que pueden ser útiles para configurar los servicios necesarios para arrancar el cliente que son por ahora: NFS, DHCP y TFTP. Se da la alternativa de usar dnsmasq solamente o dhcpd3 con tftpd.

sslsockets_examples

El código que encontramos aquí fue creado antes que el client_daemon. Al principio, para el demonio del cliente, íbamos a usar C++ con Qt. Los primeros pasos fueron crear un socket seguro. Como no está claro que todavía que vayamos a quedarnos con python para esta parte, dejamos aquí ese código por si sirve posteriormente.

web

Aquí se encuentra la consola web. #238

Ficheros

  • setup.sh: Se ejecuta para instalar la consola web. Borra todos los datos de la anterior instalación y llama a los siguientes scripts para generar una instalación limpia:
    • db.py: Crea la base de datos principal.
    • i18n_make.sh: Genera las traducciones.
    • i18n_make_plugins.sh: Lo mismo que antes pero para los plugins.
    • fill_data.sh: Rellana algunos datos para poder probar el código.
  • admin.py: Se ejecuta para ejecutar la consola web. Se le puede pasar el puerto por el que se quiere ejecutar. Por defecto es el 8080.
  • config.py: Aquí podemos configurar muchos aspectos de la consola web.
  • i18n_extract.sh y i18n_extract_plugin.sh: Sirve para extraer los mensajes para traducir.
  • decorators.py: Están los decoradores para las funciones donde hay mensajes para traducir.
  • log.py: Este fichero se configura como se guarda el log.
  • runtests.sh: Para correr los tests.
  • utils.py: Funciones que se usan en todo el código y no sabíamos donde colocar.
  • daemon.py: El demonio que debe ser ejecutar para recibir las respuestas de los clientes.

Directorios

  • clientjob: Todo lo referente a envío de trabajos a los clientes y también a los repositorios.
  • dbadmin: Es el formalchemy, que crea a partir de base de datos formularios para poder modificarlos. Todavía no está desarrollado todo lo que debería.
  • i18n: Generado para las traducciones.
  • log : Generado para el log.
  • login: ¿No hay nada?
  • main: La base de datos principal de ordenadores, grupos, repositorios, etc.
  • navigator: Todo lo referente a la pestaña navigator de la consola web.
  • panel: Todo lo refrente a la pestaña panel.
  • pluginmanager: Todo lo referente a la pestaña pluginmanager. Instala, activa, desactiva y elimina plugins. También puede configurar sus opciones.
  • plugins: Aquí está el esqueleto de los plugins. pluginbase.py es el fichero principal y ahí se encuentra mucho código usado por los plugins que heredan de esa clase. En este directorio existen más directorios que son los plugins propiamente dichos que se pueden activar desde pluginmanager. Por ahora ahí:
    • disk_image: Todo lo referente a los discos de los clientes.
    • hardware_inventory: Crea un inventario hardware a los clientes.
  • sessions: Creado para guardar la sesión.
  • ssl: Certificados para conexiones seguras.
  • static: El javascript, css, imagenes, etc. También se enlaza con el material estático con enlaces simbólicos de los plugins cuando se instalan.
  • templates: Todo el sistema de plantillas que se usa en la consola web. Se organiza por carpetas y también se enlaza templates de plugins cuando se instalan.
  • tests: Para crear tests. No está muy desarrollado.
  • user: Aquí vemos todo el código relacionado con los usuarios del sistema.
  • web: El webpy que usa la consola web.