Otros servicios disponibles

Figura 4.11: Webmail de pantuflo

unos retoques adicionales a las plantillas HTML de ambos webmails, donde se indica el nombre del laboratorio y unas instrucciones para poder acceder al mismo. El resultado lo podemos observar en las im´agenes 4.11 para el webmail de la m´aquina pantuflo y 4.12 para el webmail de la m´aquina bilo.

Sobre esta configuraci´on pueden realizarse mejoras adicionales, como dotar al sistema de un servicio de agenda, calendario, libreta de direcciones, e incluso acceso a las cuentas de usuario (ficheros personales de cada cuenta) a trav´es del navegador web. En nuestro caso, todos estos servicios se implementan junto al servicio webmail: agenda, libreta de direcciones y acceso a las cuentas a trav´es del navegador web.

4.3.

Otros servicios disponibles

En la siguiente secci´on se comentar´an una serie de servicios que, aunque no son imprescindibles para que el correcto funcionamiento del Laboratorio, resultan m´as que interesantes para un funcionamiento m´as eficiente. En concreto, vamos a comentar brevemente la instalaci´on de listas de correo para la comunicaci´on entre administradores y usuarios del sistema (algo fundamental, debido a que no tenemos m´as datos de los usuarios que su direcci´on de correo en el sistema) as´ı como la instalaci´on de una r´eplica de paquetes de software tanto para Debian como para Ubuntu, para aumentar la rapidez con la que se instalan los paquetes en el Laboratorio.

4.3.1. Listas de correo

Un aspecto muy importante del sistema es tener un canal de comunicaci´on entre los usuarios y los administradores o responsables t´ecnicos del mismo. En nuestro caso, debido a que la autenticaci´on en nuestros laboratorios no se basa en el dominio ´unico que provee la Universidad, no disponemos de m´as datos de los usuarios que la direcci´on de correo que poseen en el momento en el que se abre la cuenta (la direcci´on de correo con dominio @pantuflo.escet.urjc.es. Por supuesto ser´a responsabilidad del usuario leer este correo o redireccionarlo a una direcci´on que lea con asiduidad para poder estar al tanto de los acontecimientos que se suceden en el servidor, as´ı como de cualquier otro asunto que sea relativo a su cuenta.

CAP´ITULO 4. IMPLANTACI ´ON

Figura 4.12: Webmail de bilo

Para la gesti´on de la comunicaci´on entre los administradores del laboratorio y los usuarios, instalaremos la herramienta de listas de correo mailman. Para la comunicaci´on entre los administradores del sistema y los usuarios del mismo, creamos dos listas, cuya funci´on ser´a la siguiente:

Figura 4.13: Gesti´on de listas de correo en pantuflo con Mailman.

Una lista para la comunicaci´on entre los administradores y los usuarios del sistema en el campus de M´ostoles, a la que llamaremos lista pantuflo-todos.

Una lista para la comunicaci´on entre los administradores y los usuarios del sistema en el campus de Fuenlabrada, a la que llamaremos lista bilo-todos.

4.3. OTROS SERVICIOS DISPONIBLES

La primera lista, obviamente ser´a gestionada en uno de los servidores del campus de M´ostoles. Como vimos en el Cap´ıtulo de Especificaci´on y Dise˜no, este servidor ser´a la m´aquina pantuflo.escet.urjc.es. Uno de los motivos que lleva a que sea esta m´aquina la que albergue las listas de correo para el campus de M´ostoles es el dominio de salida de los correos, la m´aquina visible al resto de los usuarios @pantuflo.escet.urjc.es.

De la misma forma, la segunda lista, destinada a la comunicaci´on entre los administradores y los usuarios del sistema en el campus de Fuenlabrada, estar´a albergada en la m´aquina bilo.cct.urjc.es, que es la m´aquina destinada a albergar la gesti´on de la p´agina web del Laboratorio y el correo electr´onico, entre otros.

Existen otras listas que pueden resultar de utilidad para la gesti´on interna del laboratorio. Estas listas reciben mensajes de alertas variados, como por ejemplo, avisos de errores en discos duros, el reporte diario de uso de disco del sistema, las alertas por caidas en el servicio, etc´etera. Comentamos alguna a continuaci´on.

La lista pantuflo-local tiene como funci´on la comunicaci´on interna entre profesores y administradores del laboratorio.

La lista pantuflo-backups recibe las alertas de las copias de seguridad que se ejecutan peri´odicamente en el sistema (en ambos campus).

La lista pantuflo-nagios-estaciones recibe las alertas por caidas en las estaciones de usuario, enviadas autom´aticamente por la herramienta nagios.

La lista pantuflo-nagios-servidores recibe las alertas por caidas en los servidores, enviadas autom´aticamente por la herramienta nagios.

La lista pantuflo-raids recibe notificaciones autom´aticas del estado de los raids en todas las m´aquinas que los usan.

La lista pantuflo-hd-alerts recibe notificaciones de alertas que se puedan producir en los discos duros de las m´aquinas cr´ıticas (servidores principalmente).

Debido a que la gesti´on del laboratorio (tanto del campus de Fuenlabrada como el de M´ostoles) se suelen hacer f´ısicamente desde M´ostoles, todas estas listas estar´an albergadas en la m´aquina pantuflo.escet.urjc.es.

Gesti´on de listas

La gesti´on de listas a trav´es de la herramienta mailman es realmente sencilla. Como hemos visto, la gesti´on de estas listas se llevar´a a cabo en las m´aquinas pantuflo.escet.urjc.es y bilo.cct.urjc.es, en las que est´a instalado Debian GNU/Linux. Por tanto, la instalaci´on se puede llevar a cabo usando el gestor de paquetes apt-get:

Listado 4.55: Instalaci´on de mailman usando apt-get

$ apt - get install mailman

Durante la instalaci´on, es probable que el gestor de paquetes realice alguna pregunta relativa a la post configuraci´on del mismo. Una vez instalado, es necesario que se cree una primera lista para que mailman comience a funcionar correctamente. Esta lista es la lista con nombre mailman, y la podemos crear de la siguiente forma:

Listado 4.56: Creaci´on de una nueva lista de mailman usando el comando newlist

CAP´ITULO 4. IMPLANTACI ´ON

Despu´es de responder a algunas preguntas relativas a la gesti´on de la lista (persona que la gestiona, contrase˜na inicial, etc´etera) ser´a necesario a˜nadir la informaci´on de salida del comando al fichero /etc/aliases. La informaci´on que el fichero contendr´a por tanto, es parecida a esta:

mailman : "|/ var / lib / mailman / mail / mailman post mailman " mailman - admin : "|/ var / lib / mailman / mail / mailman admin m ailman " mailman - bounces : "|/ var / lib / mailman / mail / mailman boun ces mailman " mailman - confirm : "|/ var / lib / mailman / mail / mailman conf irm mailman " mailman - join : "|/ var / lib / mailman / mail / mailman join mai lman " mailman - leave : "|/ var / lib / mailman / mail / mailman leave m ailman " mailman - owner : "|/ var / lib / mailman / mail / mailman owner m ailman " mailman - request : "|/ var / lib / mailman / mail / mailman requ est mailman " mailman - s u b s c r i b e : "|/ var / lib / mailman / mail / mailman s u b s c r i b e mailman " mailman - u n s u b s c r i b e : "|/ var / lib / mailman / mail / mailman u n s u b s c r i b e mailman "

Es importante rese˜nar que despu´es de haber modificado el contenido de este fichero es necesario ejecutar el comando newaliases. Si no se hace, no se har´a visible ninguna modificaci´on que se haya hecho de cara al gestor de correo y a mailman.

Una vez que las listas est´an correctamente instaladas, la gesti´on de ellas se puede realizar ´

unicamente utilizando un navegador. Solamente es necesario crearlas con el comando newlist, ya que toda su gesti´on puede realizarse mediante el interfaz web de mailman. En la figura 4.13 podemos observar la pantalla de administraci´on de la listas de correo de mailman (para la m´aquina pantuflo).

4.3.2. Mirror de Debian y Ubuntu

Debido a que, como se coment´o en anteriores cap´ıtulos, en las estaciones del Laboratorio tenemos instalada la ditribuci´on Ubuntu Linux, resulta realmente interesante tener disponible de forma interna a la red un mirror o espejo que nos sirva para poder instalar paquetes de una forma m´as eficiente. Sin duda la capacidad de la red es bastante alta, y en ese sentido, la instalaci´on de paquetes no resulta para nada lenta en ning´un caso. Sin embargo, siempre resulta m´as eficiente de cara al tr´afico de la red descargar los paquetes una ´unica vez y luego replicarlo en todas aquellas m´aquinas en las que sea necesario.

Por ello, se decide llevar a cabo la instalaci´on (o mejor dicho, la r´eplica) de un servidor de paquetes tanto para Ubuntu, como para Debian. En el caso de Debian la necesidad no es tan alta, puesto que esta distribuci´on ´unicamente se usa en los servidores. Adem´as, la red Rediris provee de un mirror o espejo de paquetes para esta distribuci´on, por tanto la penalizaci´on de tr´afico por descarga no ser´ıa tan alta en este caso.

Para la instalaci´on de un mirror local usamos la herramienta debmirror, la cual descargar´a todos los paquetes necesarios para consolidar la r´eplica local de una determinada versi´on de Debian (o de Ubuntu), con sus correspondientes ramas y secciones. La herramienta debmirror se encuentra disponible tanto en Debian GNU/Linux como en Ubuntu como paquete, y con una ´unica llamada al gestor de paquetes puede ser instalada.

Listado 4.57: Instalaci´on de la herramienta debmirror usando apt-get

$ apt - get install d e b m i r r o r

Una vez que ha sido instalada, debe ser configurada para ser ejecutada peri´odicamente (lo m´as normal, es que se ejecute una vez al d´ıa). Lo m´as f´acil para llevar a cabo esta tarea es usar una l´ınea de cron, para asegurar que este comando se ejecuta peri´odicamente. Como es sabido , las distribuciones que nos ocupan (Debian y Ubuntu) se dividen en versiones. A su vez estas versiones, est´an divididas en secciones. Por tanto, deberemos indicarle a la herramienta