Importación de datos de configuración¶

Aunque la interfaz de Zentyal facilita enormemente la labor del administrador de sistemas, algunas de las tareas de configuración a través de dicha interfaz pueden resultar tediosas si tenemos que repetirlas un número elevado de veces. Ejemplos de esto serían añadir 100 nuevas cuentas de usuario o habilitar una cuenta de correo electrónico para todos los usuarios de Zentyal.

Estas tareas se pueden automatizar fácilmente a través de la interfaz para la programación que nos proporciona Zentyal. Para ello sólo son necesarios unos conocimientos básicos de lenguaje Perl [1], así como conocer los métodos expuestos por el módulo de Zentyal que queramos utilizar. De hecho, la interfaz Web utiliza la misma interfaz de programación.

A continuación se muestra un ejemplo de cómo crear una pequeña utilidad, haciendo uso del API de Zentyal, para añadir automáticamente un número arbitrario de usuarios definidos en un fichero CSV (Comma Separated Values):

#!/usr/bin/perl

use strict;
use warnings;

use EBox;
use EBox::Global;

EBox::init();
my $usersModule = EBox::Global->modInstance('users');

my @users;
open (my $USERS, 'users');

while (my $line = <$USERS>) {
    chomp ($line);
    my $user;
    my ($username, $givenname, $surname, $password) = split(',', $line);
    $user->{'user'} = $username;
    $user->{'givenname'} = $givenname;
    $user->{'surname'} = $surname;
    $user->{'password'} = $password;
    push (@users, $user);
}
close ($USERS);

foreach my $user (@users) {
    $usersModule->addUser($user, 0);
}

1;

Guardamos el fichero con el nombre bulkusers y le damos permisos de ejecución mediante el comando chmod +x bulkusers.

Antes de ejecutar el script debemos tener un fichero llamado users en el mismo directorio. El aspecto de este fichero debe ser así:

jfoo,John,Foo,jfoopassword,
jbar,Jack,Bar,jbarpassword,

Finalmente nos situamos en el directorio donde lo hayamos guardado y ejecutamos:

sudo ./bulkusers

En esta sección se ha mostrado un pequeño ejemplo de las posibilidades de automatización de tareas con el API de Zentyal, pero estas son prácticamente ilimitadas.

Personalización avanzada de servicios¶

En esta sección se comentan dos posibilidades de personalización del sistema para aquellos usuarios que puedan tener necesidades especiales.

• Personalización de ficheros de configuración de servicios gestionados por Zentyal.
• Ejecución de acciones en el proceso de asentar cambios en la configuración.

Cuando un módulo de Zentyal se encarga de configurar automáticamente un servicio intenta abarcar sus opciones de configuración más comunes. Además, en algunos casos son tantas las posibilidades de configuración que nos ofrecen las herramientas de software libre, que aunque se quisiese sería imposible controlarlas todas con un producto como Zentyal cuyo fin es la simplicidad. Sin embargo, hay usuarios que pueden tener necesidades especiales y desean ajustar alguno de estos parámetros que Zentyal no maneja. Una de las posibilidades es modificando directamente los ficheros de configuración del software en cuestión.

Antes de lanzarnos a modificar un fichero de configuración manualmente, debemos comprender cómo funciona Zentyal internamente. Los módulos, una vez que se han habilitado, se encargan de sobreescribir los ficheros de configuración originales del sistema de aquellos servicios que controlan. Esto lo hacen mediante unas plantillas que contienen fundamentalmente la estructura básica de un fichero de configuración típico para el servicio en cuestión, pero algunas de las partes están parametrizadas mediante variables de sustitución. El valor de estas variables se asigna a la hora de escribir el fichero, en función de los valores de configuración que hayamos establecido a través de la interfaz de Zentyal. Puede quedar más claro con la siguiente imagen:

Cómo funciona el sistema de plantillas de configuración

Por tanto, si queremos que los cambios que realicemos sobre los ficheros de configuración sean persistentes, y no sean sobrescritos cada vez que Zentyal salve cambios, debemos editar las anteriormente mencionadas plantillas en lugar de los ficheros. Estas plantillas se encuentran en /usr/share/ebox/stubs y su nombre coincide con el nombre del fichero de configuración original seguido de la extensión .mas.

Hay que tener en cuenta, que aunque estos cambios que realicemos en las plantillas serán persistentes aunque se modifique la configuración de Zentyal; dejarán de serlo en el momento en que realicemos una actualización. Al instalar una nueva versión de los paquetes se sobreescribirán todos los ficheros .mas. Por tanto, se recomienda hacer una copia de seguridad de las plantillas que modifiquemos, para poder restaurarlas después de una actualización.

Es posible que en lugar de personalizar ficheros de configuración, lo que necesitemos sea ejecutar ciertas acciones adicionales además de las que ejecuta Zentyal cuando guarda los cambios en sus módulos.

Por ejemplo, cuando Zentyal guarda los cambios relativos al cortafuegos, lo primero que hace es eliminar todas las reglas existentes, y posteriormente añade las que tengamos definidas en la configuración. Si tenemos unas necesidades avanzadas que nos llevan a añadir una regla de iptables que no está contemplada en la interfaz de Zentyal, y la añadimos manualmente, en el momento en que el módulo se reinicie la regla desaparecerá. Para evitar esto, Zentyal nos permite ejecutar scripts durante el proceso de aplicación de los cambios en la configuración de los servicios. Existen 6 puntos de entrada para la ejecución de dichos scripts también conocidos como hooks. Dos de ellos son generales y los otros 4 por módulo:

Antes de guardar cambios:

Los scripts con permisos de ejecución situados en el directorio /etc/ebox/pre-save se ejecutarán antes de comenzar el proceso.

Después de guardar cambios:

Se ejecutarán los scripts con permisos de ejecución del directorio /etc/ebox/post-save cuando el proceso haya finalizado.

Antes de guardar la configuración de un módulo:

Escribiendo el fichero /etc/ebox/hooks/<module>.presetconf siendo <module> el nombre del módulo que se quiere personalizar. Se ejecutará antes de sobreescribir la configuración del módulo. Es el sitio ideal para modificar las plantillas de configuración de un módulo.

Después de guardar la configuración de un módulo:

El fichero /etc/ebox/hooks/<module>.postsetconf se ejecutará tras guardar la configuración.

Antes de reiniciar el servicio:

Se ejecutará el fichero /etc/ebox/hooks/<module>.preservice. Este script puede ser útil, por ejemplo, para cargar módulos en el demonio de apache.

Después de reiniciar el servicio:

Se ejecutará el fichero /etc/ebox/hooks/<module>.postservice. Para el ejemplo del cortafuegos, se deberían escribir aquí las reglas personalizadas necesarias que no puedan ser añadidas desde la interfaz de Zentyal.

Como se puede intuir, esto tiene un gran potencial y permite una personalización muy avanzada del funcionamiento y la integración de un servidor Zentyal.

Entorno de desarrollo de nuevos módulos¶

En este capítulo hemos visto como solventar algunas de las limitaciones de configuración que nos ofrecen los módulos de Zentyal. Pero es posible que los módulos que proporciona Zentyal no puedan satisfacer todas nuestras necesidades. Esto no es un grave problema, ya que Zentyal está diseñado precisamente pensando en la extensibilidad y es relativamente sencillo crear nuevos módulos.

Cualquiera con conocimientos del lenguaje Perl puede aprovecharse de las facilidades que proporciona Zentyal para la creación de interfaces Web, y también beneficiarse de la integración con el resto de módulos y las demás características comunes de Zentyal.

El diseño de Zentyal es completamente orientado a objetos y hace uso del patrón Modelo-Vista-Controlador (MVC) [2], de forma que el desarrollador sólo necesita definir qué características desea en su modelo de datos, y el resto será generado automáticamente por Zentyal. Por si esto no fuese suficiente, se dispone de una herramienta llamada zmoddev [3] que facilita más todavía el desarrollo de nuevos módulos, proporcionando plantillas auto-generadas en función de parámetros definidos por el usuario, lo que se traduce en un ahorro de tiempo. Sin embargo, su explicación y desarrollo está fuera del alcance de este curso.

Zentyal está pensado para ser instalado en una máquina dedicada. Esta recomendación es también extensible para el caso del desarrollo de módulos. No se recomienda desarrollar sobre la propia máquina del usuario, en su lugar se recomienda servirse de un entorno virtualizado como se detalla en virt-chapter-ref.

Política de gestión de errores¶

Cada proyecto de software libre tiene su propia política de gestión de defectos, denominados bugs en el argot informático.

En Ubuntu puede existir más de una versión considerada estable y mantenida al mismo tiempo. Esto es, entendemos por mantenida que cuando se arregla un bug previamente detectado se pone oficialmente a disposición del público una actualización que lo corrije. El tema de las actualizaciones será tratado más detenidamente en la siguiente sección.

En el caso de Zentyal, existe una versión estable. Sobre esta versión se van incorporando progresivamente las modificaciones que corrigen los distintos bugs detectados. También se mantiene la anterior versión estable, incorporándole actualizaciones cuando se detectan bugs críticos o de seguridad. Actualmente el ciclo de vida de una versión es de un año como estable y de otro en mantenimiento. Se recomienda utilizar siempre la versión más actualizada, ya que incorpora todas las mejoras y correcciones.

En Zentyal se utiliza la herramienta de gestión de proyectos Trac [4]. Es usada por los desarrolladores para gestionar los bugs y sus tareas, pero también la creación de tickets para reportar problemas está abierta a todos los usuarios. Una vez que el usuario ha creado un ticket, puede realizar un seguimiento del estado del mismo mediante correo electrónico. Se puede acceder al Trac de Zentyal desde http://trac.zentyal.org.

Ubuntu usa Launchpad [5], una herramienta desarrollada y mantenida por Canonical, para la gestión de bugs.

Se recomienda reportar un bug cuando nos hemos asegurado de comprobar que el problema se puede repetir fácilmente. Mejor incluso si proporcionamos instrucciones detalladas para su reproducción. También conviene asegurarse de que lo que nos ocurre es realmente un bug y no un comportamiento esperado del programa bajo determinadas circunstancias. Incluso puede ser de gran utilidad dar una solución para dicho problema, ya sea modificando la aplicación (parche) o mediante instrucciones para evitar el problema temporalmente (workaround).

deb http://security.ubuntu.com/ubuntu/ lucid-security universe main multiverse restricted

Soporte técnico¶

Típicamente, los proyectos de software libre ofrecen soporte técnico a los usuarios de su aplicación a través de distintos medios. Ubuntu y Zentyal no son una excepción.

Tenemos que diferenciar dos tipos de soporte: el soporte proporcionado a la comunidad, que es gratuito, y el soporte comercial que es aquel que ofrece una empresa a cambio de una retribución económica.