Un módulo eBox típico maneja la configuración de un demonio, pudiendo integrarse también con otros módulos de eBox. El desarrollador será quien decida la forma en la que el usuario podrá configurar el demonio, que no será necesariamente una relación directa entre las del módulo y las que admita el demonio. El desarrollador podrá elegir el valor, por defecto, más adecuado para la mayoría de las opciones y esconderlas de cara al usuario, mostrándole sólo las que se consideren realmente importantes. De igual forma, el cambio de una opción por parte del usuario mediante el interfaz web, puede causar cambios de configuración en varios parámetros de configuración del demonio, o en varios módulos de eBox. El principal objetivo es mantener un interfaz de usuario sencillo, facil de usar e integrado lo más posible, mientras se ofrece un conjunto de parámetros de configuración lo más rico posible.
Sin embargo, puede haber módulos que no manejen la configuración de un servicio de red. Un ejemplo de un módulo de este tipo es el módulo de "sysinfo" del sistema base, se encarga de recoger la información del sistema a ser mostrada en la página de Resumen y ofrece unas entradas de menú para características que no pertenecen a ningún módulo en particular. La clase padre del módulo define varios métodos abstractos que los módulos reales pueden dejar sin implementar, así un módulo puede simplemente mantener información en la página de Resumen, añadir nuevas entradas de menú, manejar un servicio de red o todo lo anterior.
El caso normal, y mas interesante, es el del módulo descrito en el primer parrafo. Este módulo tiene tres partes.
Una que define e implementa una API que permitirá a la GUI, a otros módulos o scripts en perl configurar el demonio que van a manejar.
La segunda es la GUI, la cual integra una serie de CGIs que muestran la configuración en ése momento al usuario y le permiten cambiarla, estos CGIs usan la API definida anteriormente para obtener la información de la configuración y realizar cambios sobre ella.
La tercera parte del módulo es mas pequeña normalmente, traduce toda la información sobre configuración almacenada en GConf en reglas del firewall, ficheros de configuración y comandos que hacen que el servicio de red se comporte como el usuario espera. También se hace cargo del inicio, parada o reinicio del sistema cuando sea necesario.
Esta separación de la GUI y el backend abre la posibilidad de de cambiar la configuración por otras vías. Una de estas otras vías es a través de scripts, esto es muy útil cuando se realizan paquetes para una distribución, el mantenedor del paquete puede escribir un script sencillo para importar la configuración actual del sistema a eBox, o establecer unos valores por defecto. Otro uso de la API la puede realizar otro módulo diferente, por ejemplo el módulo del firewall es uno de los casos mas habituales de este uso, casi todos los módulos necesitan "decirle" al firewall que abra algunos puertos para ellos. En el futuro puede que se desarrolle un wrapper sobre estas APIs para publicarlas a través de web-services, esto podría hacer a la configuración de eBox programable sobre la red.
Tenemos una API que ofrece ciertas características configurables de un servicio, y una GUI que permite al usuario manipular la configuración. La tercera parte del módulo es normalmente mas pequeña, traduce toda la informacón acerca de la configuracón almacenada en gconf en reglas para el firewall, ficheros de configuración y comandos que hacen que el servicio de red se comporte como el usuario espera. También se encarga del lanzamiento, parada y relanzamiento del servicio cuando sea necesario.
Además de estas tres partes, el módulo tiene otras funcionalidades menores, como su parte de información en la página de Resumen de la interfaz web, las entradas de menú, la declaración de dependencias, backups de las partes de la configuración no almacenadas en gconf, etc...
Esto es todo lo que hay, crear un módulo es tan simple como seguir los siguientes pasos:
Decidir qué demonio va a manejar tu módulo y aprender cómo trabaja y cómo configurarlo.
Planear que opciones vas a ofrecer a los usuarios a través de la interface web, y cómo pueden interactuar con otros módulos eBox.
Definir e implementar la API que va a permitir a la
GUI manipular las opciones necesarias de configuración.
La clase principal de tu módulo debe heredar de
EBox::GConfModule, esta clase envuelve la
API de gconf e implementa algunas características útiles que
todos los módulos eBox necesitan tener de manera transparente.
Crear los CGIs y plantillas HTML que permitirán al usuario
interactuar con el módulo. Los CGIs deben heredar de la clase
EBox::CGI::Base la cual ofrece, de nuevo,
algunas características a todas sus clases hijas de manera
transparente.
Escribir el código necesario para hacer que el
demonio funcione, posiblemente generar algun fichero de
configuración y establecer alguna regla de firewall usando la
clase EBox::Firewall. Los ficheros de
configuración son generados de manera trivial con mason, que es el
sistema de plantillas usado también para generar las páginas HTML
para la GUI.
El tamaño y complejidad de un módulo depende directamente de la complejidad del servicio involucrado y de la cantidad de parámetros configurables sobre el servicio que ofrecemos al usuario. El trabajo necesario para hacer un módulo eBox pequeño es mínimo, tomando como ejemplo el módulo DNSCache, sus CGIs tienen 49 lineas de código y el módulo en sí 134.
La estructura de directorios de un módulo eBox puede parecer un poco compleja a primera vista. Un módulo eBox normal debería tener el siguiente aspecto:
AUTHORS configure.ac INSTALL Makefile.am README stubs/ autogen.sh COPYING NEWS schemas/ tools/ ChangeLog debian/ m4/ po/ src/ www/
Los directorios más importantes son src/,
schemas/, www/ y
stubs/.
El directorio src/ contiene el código fuente
del módulo. Dentro de él encontramos dos subdirectorios:
EBox y templates.
En el directorio EBox se encuentran los ficheros
fuente Perl, incluyendo el subdirectorio CGI con la interfaz web del
módulo. El directorio templates se utiliza para
almacenar las plantillas Mason, que serán utilizadas para generar la
salida HTML.
El directorio schemas/ contiene esquemas
gconf, utilizados para definir las opciones de configuración de los
módulos y opcionalmente proporcionar valores por defecto para algunas
de ellas.
El directorio www/ contiene imágenes y
hojas de estilo CSS que son utilizadas por la interfaz web.
En stubs/ se almacenan las plantillas Mason
utilizadas para generar los ficheros de configuración para los
servicios del módulo.