Monitorizaci´ on del Sistema

debmirror que versiones queremos replicar as´ı como qu´e secciones y ramas de desarrollo. Lo vemos en las siguientes l´ıneas:

En el caso de Ubuntu, podemos usar la orden de comando mostrada en el listado 4.58. Listado 4.58: Descargando la r´eplica de Ubuntu usando el comando debmirror

d e b m i r r o r -- n o s o u r c e -m -- passive -- host = archive . u b u n t u l i n u x . org -- root = ubuntu /

-- method = ftp -- p r o g r e s s -- dist = dapper , dapper - backport s , dapper - security , dapper - updates , dapper - proposed , edgy , edgy - backports , edgy - security , edgy - updates , edgy - proposed ,

feisty , feisty - backports , feisty - proposed , feisty - secu rity , feisty - updates , gutsy , gutsy - backports , gutsy - proposed , gutsy - security , gutsy - updates , hardy , hardy - backports ,

hardy - proposed , hardy - security , hardy - updates -- sectio n = main , multiverse , universe , r e s t r i c t e d -- arch = i386 / disks / raid / ubuntu - mirror / -- ignore - relea se - gpg -- n o c l e a n u p

En la cual se indica que el mirror principal a trav´es del cual se replicar´a la informaci´on es archive.ubuntulinux.org, que se usar´a el m´etodo ftp, y que se replicar´an las versiones de Ubuntu dapper, edgy, feisty, gutsy, y hardy. Adem´as, en cada versi´on se replicar´an las secciones main, universe, multiverse y restricted. Por ´ultimo, le indicamos que la ´unica arquitectura que se deber´a replicar es la aquitectura Intel x86 y que se deber´an ignorar las advertencias relativas a las firmas PGP.

El caso de Debian es m´as simple, puesto que tanto el n´umero de versiones como las ramas y secciones es mucho menor, tal y como muestra la llamada a debmirror del listado 4.59.

Listado 4.59: Descargando la r´eplica de Debian usando el comando debmirror

d e b m i r r o r / disks / raid / debian - mirror / -- host = ftp . redir is . es -- root =/ debian -- dist = testing , stable , unstable , e x p e r i m e n t a l -- sectio n = main , contrib , non - free -- arch = i386 -- p r o g r e s s -- method = ftp -- n o s o u r c e -- ignore - release - gpg

En la que se indica que ´unicamente se deber´an replicar las versiones de Debian testing, stable, unstable y experimental, las secciones main, contrib y non-free en la arquitectura Intel x86.

Una vez que hemos configurado el servidor de paquetes como r´eplica para Ubuntu y Debian, configurar los clientes para que usen este mirror es trivial. Para ello, editamos el fichero /etc/apt/sources.list. Como comentamos en el cap´ıtulo Dise˜no, la m´aquina peloto ser´a la encargada de albergar el mirror de Ubuntu y de Debian en el Laboratorio, por tanto, en el caso de Ubuntu, el contenido del fichero podr´ıa ser el mostrado en el listado 4.60.

Listado 4.60: Contenido del fichero /etc/apt/sources.list usando la r´eplica del Laboratorio

deb http :// peloto . escet . urjc . es / ubuntu feisty main r e s t r i c t e d u n i v e r s e m u l t i v e r s e

2 deb http :// peloto . escet . urjc . es / ubuntu feisty - s e c u r i t y main r e s t r i c t e d u n i v e r s e m u l t i v e r s e

deb http :// peloto . escet . urjc . es / ubuntu feisty - b a c k p o r t s main r e s t r i c t e d u n i v e r s e m u l t i v e r s e

4 _{deb http :// peloto . escet . urjc . es / ubuntu feisty - updates main r e s t r i c t e d u n i v e r s e m u l t i v e r s e}

Suponiendo que queremos que nuestro sistema se encuentre en la versi´on feisty de Ubuntu. Para el caso de Debian, el contenido del fichero es pr´acticamente el mismo, y por tanto no ser´a mostrado a continuaci´on.

4.4.

Monitorizaci´on del Sistema

Una vez que todo el sistema est´a implantado y se ha comprobado el correcto funcionamiento de todos los objetivos que nos plante´abamos, la monitorizaci´on del mismo es un aspecto fundamental. Es muy importante conocer en todo momento el estado tanto de los hosts que forman nuestra

CAP´ITULO 4. IMPLANTACI ´ON

red como de los servicios que ofrecen. En particular, ser´a muy importante conocer el estado de aquellas m´aquinas que ofrecen servicios que resultan cr´ıticos para el correcto funcionamiento de los laboratorios, es decir, los servidores.

La monitorizaci´on de las estaciones de trabajo es algo importante, pero en todo caso, el que una estaci´on de trabajo no funcione en un momento dado, no origina que el resto de estaciones del laboratorio dejen de funcionar, como es el caso de los servidores. En cualquier caso, ver que todas las estaciones de una sala no funcionan, desde luego puede levantar nuestras sospechas de que algo extra˜no est´a ocurriendo y requiere nuestra atenci´on.

Existen numerosas aplicaciones que prestan funcionalidad de monitorizaci´on de servicios y m´aquinas en una red local. Como vimos en el cap´ıtulo Estado del arte, hemos elegido la herramienta Nagios para la monitorizaci´on b´asica de estaciones, servidores y servicios en cada una de ellas (alertar de posibles ca´ıdas en m´aquinas y/o servicios y env´ıo de mensajes). Por otro lado, hemos elegido la herramienta Munin para recolectar informaci´on m´as elaborada acerca del funcionamiento de cada uno de los servidores. Esta informaci´on ser´a representada a trav´es de gr´aficas que podremos visualizar a trav´es de nuestro navegador web favorito.

Por otro lado, utilizaremos un script muy sencillo que informar´a del estado de las estaciones de cara a los usuarios del mismo (principalmente, los alumnos). Esta utilidad volcar´a en una p´agina web el estado de todas las estaciones, para las que se identificar´an tres estados posibles: la m´aquina est´a apagada, la m´aquina est´a encendida pero solo responde al ping y por ´ultimo, la m´aquina est´a encendida y responde al ping (est´a disponible). A esta utilidad la llamaremos parte de guerra y estar´a disponible tanto en el campus de M´ostoles y de Fuenlabrada. A continuaci´on vamos a ver de forma m´as detallada el proceso de monitorizaci´on de los servidores y de las estaciones.

4.4.1. Monitorizaci´on de servidores

Como ya se ha comentado, para la monitorizaci´on de los servidores usaremos dos aplicaciones principalmente. Utilizaremos Nagios para la monitorizaci´on b´asica de m´aquinas y servicios (esto es, saber si las m´aquinas y los servicios est´an o no disponibles) y de forma m´as avanzada, utilizaremos Munin para una monitorizaci´on m´as avanzada de los servidores. Munin proporciona informaci´on m´as detallada y extensa de una m´aquina en concreto, representada a trav´es de gr´aficas, que se pueden ver a trav´es del navegador web. Munin est´a compuesto de dos aplicaciones principales: el cliente, que env´ıa informaci´on de la m´aquina al servidor Munin, y el servidor, que recolecta la informaci´on que le env´ıan los clientes y la representa a trav´es de gr´aficas clasificadas en diferentes ´areas. Ser´a muy interesante obtener a trav´es de Munin la informaci´on del uso de CPU, memoria, procesos, uso de la red, uso del servidor NFS en una m´aquina en concreto.

La m´aquina que usaremos como vig´ıa de toda esta informaci´on (tanto Nagios como Munin) ser´a la m´aquina espatula, como ya se estudi´o en el cap´ıtulo Especificaci´on y Dise˜no.

Instalaci´on de Nagios

La instalaci´on de Nagios usando apt-get es realmente sencilla, mostr´andose en el listado 4.61. Listado 4.61: Instalaci´on de la herramienta Nagios con apt-get

$ apt - get install nagios - text

Nagios est´a disponible en diferentes paquetes. En concreto usaremos ´este, que almacena la informaci´on en ficheros de texto. Otros paquetes de Nagios almacenan la informaci´on de las m´aquinas monitorizadas en bases de datos MySQL. Por no a˜nadir otro servicio a la instalaci´on,

4.4. MONITORIZACI ´ON DEL SISTEMA

decidimos usar la versi´on de nagios que no necesita de ning´un sistema gestor para poder funcionar adecuadamente.

Una vez que la herramienta ha sido instalada, ´esta debe ser configurada. En el directorio /etc/nagios existen numerosos ficheros de configuraci´on que es necesario editar al gusto para que la herramienta funcione seg´un nuestras necesidades. La configuraci´on de nagios puede resultar un tanto tediosa si no se automatiza apoy´andonos en scripts de automatizaci´on. Es muy recomendable disponer de un fichero de texto en el que se encuentren reflejadas todas las IPs que se desean monitorizar, as´ı como el nombre de cada m´aquina. A trav´es de este fichero y usando scripts b´asicos de shell, la configuraci´on resulta muy sencilla. Vamos a comentar a continuaci´on los ficheros principales de Nagios que es preciso editar para que funcione correctamente:

/etc/nagios/hosts.cfg: almacena la informaci´on de las m´aquinas que se desean monitorizar (b´asicamente, la direcci´on IP y el nombre de la m´aquina).

/etc/nagios/hostgroups.cfg: agrupa las m´aquinas a˜nadidas en el fichero de configuraci´on anterior en grupos de m´aquinas. En nuestro caso, resulta aconsejable agrupar las m´aquinas de cada aula en un grupo diferente, y crear otro para los servidores.

/etc/nagios/contacts.cfg: contiene la informaci´on de las personas de contacto para los avisos autom´aticos de la aplicaci´on. La informaci´on reflejada en este fichero consta de nombre de la persona de contacto, correo electr´onico, tel´efono, etc´etera.

/etc/nagios/contactgroups.cfg: agrupa las personas de contacto anterior en grupos. Esta funcionalidad tiene como objetivo separa los contactos en grupos, en caso de que la administraci´on de cada m´aquina estuviera separada. En nuestro caso (debido a que el equipo t´ecnico es m´as bien peque˜no) no se usar´a, y ´unicamente existir´a un grupo.

/etc/nagios/services.cfg: este fichero almacen la informaci´on de los servicios que se desean monitorizar de una m´aquina o de un grupo de m´aquinas en concreto. Por ejemplo, monitorizar que la m´aquina est´a disponible (servicio check ping), que la m´aquina tiene el servicio SSH ejecutando (servicio check ssh), etc´etera.

Una vez que todos los ficheros han sido configurados, es necesario reiniciar el servico nagios, para que la configuraci´on se actualice y todo empiece a funcionar adecuadamente. Existen diferentes otros ficheros de configuraci´on que no son exactamente relativos a Nagios, como son la configuraci´on de Apache, los usuarios que pueden acceder a la informaci´on, etc´etera.

Una vez que est´a todo funcionando, podemos acceder al sistema de monitorizaci´on32

. En la imagen 4.14 se pude observar la p´agina principal del estado de los servicios en Nagios. Podemos ver las m´aquinas del Laboratorio de M´ostoles agrupadas por aula (106, 108, 109 y 111) y los servidores. Por cada grupo, se puede observar las m´aquinas que est´an disponibles y el estado de los servicios que se monitorizan en esas m´aquinas. Podemos ver que en todas las aulas todas las m´aquinas est´an disponibles (estado OK) menos en el aula 108, que hay dos que no lo est´an, y que en principio la mayor´ıa de los servicios est´an disponibles (excepto de las m´aquinas que est´an apagadas, por supuesto). Por cada m´aquina se monitorizan como m´ınimo dos servicios: servicio ping y servicio ssh. Para los servidores, se monitorizan m´as cosas. Por ejemplo, en pantuflo nos interesar´a saber que los servidores web (HTTP) y correo (SMTP, POP3s e IMAPs) est´an disponibles.

En la parte de la izquierda de la p´agina se muestra el men´u de opciones de Nagios (que son bastantes). La parte m´as interesante ser´a saber los problemas de los servicios que haya en algunas m´aquinas. Podemos acudir a la opci´on service problems para ver los problemas que hay en las

32

CAP´ITULO 4. IMPLANTACI ´ON

Figura 4.14: La p´agina de resumen de estado de Nagios para el Laboratorio de M´ostoles.

Figura 4.15: La p´agina de problemas de Nagios muestra los problemas en algunas m´aquinas.

m´aquinas que se monitorizan. En la imagen 4.15 podemos ver la informaci´on contenida en esta secci´on, las m´aquinas que tienen problemas, la duraci´on del mismo y cuando se comprob´o por ´

ultima vez.

Adem´as de esta informaci´on, por supuesto, los problemas que pueda tener una m´aquina en concreto se pueden enviar por correo electr´onico. Para ello, es preciso configurar los ficheros que se comentaban anteriormente. Es necesario observar que las alertas de problemas en las estaciones pueden ocasionar mucho ruido: tenemos 160 estaciones en el campus de M´ostoles, y 100 en el campus de Fuenlabrada. A cada reinicio de m´aquina, tendremos dos mensajes de correo electr´onico (servicio DOWN y servicio UP). Esto puede ocasionar demasiados mensajes y producir un efecto rebote, que nos haga prescindir de esta informaci´on. En nuestro caso, los mensajes de alerta de las estaciones se enviar´an a una direcci´on de correo y los de los servidores (ya que requieren mucha m´as atenci´on) se enviar´an a otra.

Instalaci´on de Munin

Vamos a utilizar Munin como sistema de recolecci´on de informaci´on para los servidores ´

unicamente. Como hemos visto, Munin se compone de un servidor que representa la informaci´on de los clientes, y los nodos que env´ıan la informaci´on al servidor. La instalaci´on de Munin es muy sencilla en un sistema Debian o basado en la herramienta apt-get:

En el servidor:

4.4. MONITORIZACI ´ON DEL SISTEMA

Listado 4.62: Instalaci´on de la herramienta Munin (servidor) con apt-get

$ apt - get install munin

En los clientes:

Listado 4.63: Instalaci´on de la herramienta Munin (cliente) con apt-get

$ apt - get install munin - node

En los clientes, ´unicamente ser´a necesario indicar qu´e servidor puede conectarse al puerto de escucha de Munin y obtener la informaci´on de la m´aquina. Esto se puede indicar editando el fichero /etc/munin/munin-node.conf :

Listado 4.64: Instalaci´on de la herramienta Munin (cliente) con apt-get

h o s t _ n a m e lechuzo allow ^ 2 1 2 \ . 1 2 8 \ . 4 \ . 9 $

Los par´ametros m´as importantes son el nombre que se mostrar´a en la p´agina de Munin, y la IP que puede acceder al nodo para recopilar la informaci´on. Este par´ametro obviamente depender´a de la m´aquina que recoja los datos de los clientes de Munin.

4.4.2. Monitorizaci´on de estaciones

La monitorizaci´on de estaciones de cara a los usuarios del sistema se llevar´a a cabo a trav´es de un script muy simple que informa de las estaciones que se encuentran disponibles. Normalmente, los usuarios del laboratorio, suelen conectarse a las estaciones del laboratorio para poder realizar sus pr´acticas.

Figura 4.16: El parte de guerra de M´ostoles muestra el estado de las estaciones.

En la imagen 4.16 puede observarse la visualizaci´on del parte de guerra para el campus de M´ostoles33

. Como se puede observar, para cada estaci´on se representa mediante el color verde

33

CAP´ITULO 4. IMPLANTACI ´ON

el que la m´aquina tenga el servicio disponible (ping o ssh) y rojo en caso contrario. De esta forma, los alumnos saben en cada momento a qu´e estaci´on se pueden conectar para realizar sus tareas. Alternativamente, se aplica el mismo script para el campus de Fuenlabrada34

. La salida de esta p´agina es bastante similar a la mostrada en la imagen 4.16. El parte de guerra se actualiza aproximadamente cada tres minutos mediante una tarea de cron en las m´aquinas pantuflo.escet.urjc.es y bilo.cct.urjc.es.

En el ap´endice adjunto al documento pueden consultarse los scripts que producen la salida correspondiente para ambos partes de guerra.