CARACTERÍSTICAS DEL SERVIDOR LICENCIA FUNCIONAMIENTO VENTAJAS IMPACTO EN EL MERCADO LENGUAJE UTILIZADO SISTEMAS OPERATIVOS SOPORTADOS SERVIDOR WEB VIRTUAL

VIRTUAL HOSTS MÚLTIPLES DOMINIOS

Creación del sitio web. Redirección local Configuración del VirtualHost Reiniciar el servidor

MÚLTIPLES DIRECCIONES Host virtual basado en puertos

SERVIDOR WEB CON RESTRICCIONES DE USUARIOS Autenticación Básica

SERVIDOR WEB CON BALANCEO DE CARGA SERVIDOR WEB CON SEGURIDAD HTTPS

MONITOREO DE RECURSOS CON MUNIN ESTRUCTURA DE MUNIN INSTALACIÓN Y CONFIGURACIÓN INSTALACIÓN DE PLUGINS PRUEBAS Y RESULTADOS

1

SERVIDOR WEB HTTP-HTTPS Apache es el servidor web más usado en sistemas Linux. Los servidores web se usan para servir páginas web solicitadas por equipos cliente. Los clientes normalmente solicitan y muestran páginas web mediante el uso de navegadores web como Firefox, Opera, Safari, Chrome, etc. Los usuarios introducen un Localizador de Recursos Uniforme (Uniform Resource Locator, URL) para señalar a un servidor web por medio de su Nombre de Dominio Totalmente Cualificado (Fully Qualified Domain Name, FQDN) y de una ruta al recurso solicitado. Por ejemplo, para ver la página web del sitio web de Ubuntu, un usuario debería introducir únicamente el FQDN. Para solicitar información específica acerca del soporte de pago, un usuario deberá introducir el FQDN seguido de una ruta. El protocolo más comúnmente utilizado para ver páginas Web es el Hyper Text Transfer Protocol (HTTP). Protocolos como el Hyper Text Transfer Protocol sobre Secure Sockets Layer (HTTPS), y File Transfer Protocol (FTP), un protocolo para subir y descargar archivos, también son soportados.El protocolo utilizado para la transferencia de hipertexto es HTTP (HiperText Transfer Protocol) que está basado en el envío de mensajes y establece el conjunto de normas mediante las cuales se envían las peticiones de acceso a una web y la respuesta de esa web.

La arquitectura utilizada es cliente/servidor, es decir, el equipo cliente hace una solicitud o petición al equipo servidor y éste la atiende.

En el equipo cliente se ejecuta una aplicación llamada 'navegador o cliente web' que:

Sirve de interfaz con el usuario: atiende sus peticiones, muestra los resultados de las consultas y proporciona al usuario un conjunto de herramientas que facilitan su comunicación con el servidor.

Se comunica con el servidor web: transmite las peticiones de los usuarios.

2

CARACTERÍSTICAS DEL SERVIDOR Servidor de Archivos estáticos. Soporte SSL. Soporte Host Virtuales. Proxy inverso. Balanceo de Carga. Controles de Acceso. Reescritura URL. Autentificación mediante Digest. Soporte para lenguajes perl, python, php. Modulos de autentificación.

LICENCIA Apache License La licencia Apache es una licencia de software libre creada por la Apache Software Foundation (ASF). La licencia Apache requiere la conservación del aviso decopyright y el disclaimer, pero no es una licencia copyleft, ya que no requiere la redistribución del código fuente cuando se distribuyen versiones modificadas. Como cualquier otra de las licencias de software libre, la Licencia Apache permite al usuario del software la libertad de usarlo para cualquier propósito, distribuirlo, modificarlo, y distribuir versiones modificadas de ese software. La Licencia Apache no exige que las obras derivadas (versiones modificadas) del software se distribuyan usando la misma licencia, ni siquiera que se tengan que distribuir como software libre/open source. La Licencia Apache sólo exige que se mantenga una noticia que informe a los receptores que en la distribución se ha usado código con la Licencia Apache. Así, en contraste a las licencias copyleft, quienes reciben versiones modificadas de código con Licencia Apache no reciben necesariamente las mismas libertades. Se deben añadir dos archivos en el directorio principal de los paquetes de software redistribuidos:

LICENSE ­ Una copia de la licencia NOTICE ­ Un documento de texto, que incluye los "avisos" obligatorios del

software presente en la distribución.

3

FUNCIONAMIENTO El funcionamiento de Apache es a través de servicios (Windows) o bien “daemons” (demonios) en ambientes UNIX, estos servicios son ejecutables que toman el nombre del protocolo HTTP (Hyper Text Transfer Protocol) y se llaman httpd. Estos servicios se encargan de atender las peticiones (request) de los usuarios las cuales generalmente solicitan algún tipo de recurso al servidor, ya sea un elemento html, un elemento multimedia (imagenes, video, etc), un applet etc., estas peticiones son enviadas a través de la red que puede ir desde una red local hasta la internet y el que las envía generalmente es un navegador web. El navegador (cliente) solicita el recurso de acuerdo al protocolo HTTP y una vez que le llego esta petición al servidor apache, este se encarga de resolver la petición, mandando una respuesta de igual manera conforme al protocolo y envía el recurso, en caso de que no existe o el cliente no puede tener acceso a el, entonces también apache es el encargado de informar al cliente que no se puede atender esa petición. Las peticiones (requests) se mandan a través de comandos: Comando Descripción

GET Solicita el recurso ubicado en la URL especificada

HEAD Solicita el encabezado del recurso ubicado en la URL especificada

POST Envía datos al programa ubicado en la URL especificada

PUT Envía datos a la URL especificada

DELETE Borra el recurso ubicado en la URL especificada

Las respuestas enviadas al cliente tienen un codigo de respuesta: Código Mensaje Descripción

10x Mensaje de información Estos códigos no se utilizan en la versión 1.0 del protocolo

20x Éxito Estos códigos indican la correcta ejecución de la transacción

200 OK La solicitud se llevó a cabo de manera correcta

201 CREATED Sigue a un comandoPOST e indica el éxito, la parte restante del cuerpo indica la dirección URL donde se ubicará el documento creado recientemente.

4

202 ACCEPTED La solicitud ha sido aceptada, pero el procedimiento que sigue no se ha llevado a cabo

203 PARTIAL INFORMATION Cuando se recibe este código en respuesta a un comando de GET indica que la respuesta no está completa.

204 NO RESPONSE El servidor ha recibido la solicitud, pero no hay información de respuesta

205 RESET CONTENT El servidor le indica al navegador que borre el contenido en los campos de un formulario

206 PARTIAL CONTENT Es una respuesta a una solicitud que consiste en el encabezadorange. El servidor debe indicar el encabezado content­Range

30x Redirección Estos códigos indican que el recurso ya no se encuentra en la ubicación especificada

301 MOVED Los datos solicitados han sido transferidos a una nueva dirección

302 FOUND Los datos solicitados se encuentran en una nueva dirección URL, pero, no obstante, pueden haber sido trasladados

303 METHOD Significa que el cliente debe intentarlo con una nueva dirección; es preferible que intente con otro método en vez de GET

304 NOT MODIFIED Si el cliente llevó a cabo un comando GET condicional (con la solicitud relativa a si el documento ha sido modificado desde la última vez) y el documento no ha sido modificado, este código se envía como respuesta.

40x Error debido al cliente Estos códigos indican que la solicitud es incorrecta

400 BAD REQUEST La sintaxis de la solicitud se encuentra formulada de manera errónea o es imposible de responder

401 UNAUTHORIZED Los parámetros del mensaje aportan las especificaciones de formularios de autorización que se admiten. El cliente debe reformular la solicitud con los datos de autorización correctos

402 PAYMENT REQUIRED El cliente debe reformular la solicitud con los datos de pago correctos

403 FORBIDDEN El acceso al recurso simplemente se deniega

404 NOT FOUND Un clásico. El servidor no halló nada en la dirección especificada. Se ha abandonado sin dejar una dirección para redireccionar... :)

50x Error debido al servidor Estos códigos indican que existe un error interno en el servidor

500 INTERNAL ERROR El servidor encontró una condición inesperada que le impide seguir con la solicitud (una de esas cosas que les suceden a los servidores...)

501 NOT IMPLEMENTED El servidor no admite el servicio solicitado (no puede saberlo todo...)

502 BAD GATEWAY El servidor que actúa como una puerta de enlace o proxy ha recibido una respuesta no válida del servidor al que intenta acceder

5

503 SERVICE UNAVAILABLE El servidor no puede responder en ese momento debido a que se encuentra congestionado (todas las líneas de comunicación se encuentran congestionadas, inténtelo de nuevo más adelante)

504 GATEWAY TIMEOUT La respuesta del servidor ha llevado demasiado tiempo en relación al tiempo de espera que la puerta de enlace podía admitir (excedió el tiempo asignado...)

Ahora apache2 tiene mejor rendimiento en windows en comparación a sus versiones anteriores, gracias al modulo mpm_winnt ya que puede implementar funciones de red de manera nativa y no usar la capa de POSIX del sistema operativo, en UNIX implementa threadpool, worker, leader y MPM (módulos de multiprocesamiento). Además, Apache2 también permite múltiples configuraciones para administrar los dominios, para ello se hace uso de Virtual Hosts, que permiten correr en un solo servidor varios dominios. Entre las múltiples configuraciones de los virtualhost tenemos:

Ejecutar múltiples sitios web basados en nombre, en una sola dirección IP. Host basados en nombre en más de una dirección IP. Correr múltiples sitios en diferentes puertos. Hosting virtual basado en IP Hosting basado en IP y puertos. Balanceo de carga a través de mod_ proxy.

VENTAJAS Entre las múltiples ventajas que tiene el servidor apache podemos encontrar:

Configuración por modulos Permite crear servidores virtuales Permite crear servidores seguros https Permite crear sitios privados Creación de sitios de usuario Multiplataforma, sistemas UNIX, OS X, Windows Soporte Código abierto

6

IMPACTO EN EL MERCADO Según la página oficial del proyecto http://httpd.apache.org/, apache es el servidor número uno en Internet. En el concurso de la revista difundida a nivel mundial Linux Journal, en el año 2009, apache fue el ganador por los lectores, siendo el servidor web preferido por el 89% de los mismos.

LENGUAJE UTILIZADO Apache Web Server es un proyecto desarrollado en C, Forth y XML.

SISTEMAS OPERATIVOS SOPORTADOS Apache es un servidor web que tiene soporte multiplataforma para sistemas UNIX, FreeBDS y Windows.

SERVIDOR WEB VIRTUAL Para la configuración del servidor virtual utilizamos el programa VMWARE para la virtualización del mismo. Sus características son las siguientes:

Sistema Operativo: Ubuntu 12.04 LTS 15 GB HDD 1 GB RAM Servidor web: apache2

Para los nodos que participan como los backends en el balanceo de carga, se tienen las siguientes características: Nodo 1:

Sistema Operativo: MAC OS X 10.9.2 Mavericks 500GB HDD

7

4GB RAM Servidor web: Apache Tomcat 7 Procesador Intel Corei5 2.4 GHz

Nodo 2:

Sistema Operativo: Ubuntu 12.04 LTS (Virtualizado VMWARE) 15 GB HDD 1 GB RAM Servidor web: Apache Tomcat 7

VIRTUAL HOSTS Trabajar con Hosts Virtuales consiste en ejecutar más de un sitio web en el mismo servidor.

Mediante los hosts virtuales, Apache2 permite la posibilidad de alojar varios dominios en unasola máquina. De esa forma, cuando una petición entra en el servidor Apache2 desde un navegador web a través de una IP dada, Apache2 comprueba el nombre de dominio que se está solicitando y muestra el contenido asociado a dicho nombre de dominio.

La utilización de hosts virtuales tiene como ventajas la versatilidad para crear diferentes sitios web configurables; el precio, ya que se necesita sólo una máquina para alojar varios servidores web; una configuración del sistema sirve para todos los servidores web; se actualiza sólo una vez y no requiere ningún software ni hardware adicional.

Apache soporta dos tipos de hosts virtuales:

Hosts virtuales basados en nombres Permiten alojar varios nombres de host (o dominios) en una misma máquina (IP). Todos

los hosts virtuales que comparten la misma IP deben declararse mediante la directiva NameVirtualHost.

Hosts virtuales basados en IP Una máquina responde de diferente manera a diferentes direcciones IP. Es decir, tenemos

múltiples IPs asignadas al sistema y queremos que cada una de ellas soporte un sitio web.

8

Para la definición de hosts virtuales se utiliza la sección <VirtualHost> y en ella se incluyen las directivas que se aplican a un determinado host virtual. Como mínimo debe incluir la directiva DocumentRoot y ServerName.

MÚLTIPLES DOMINIOS

Creación del sitio web. Como primer paso realizaremos la creación de nuestro sitio web, el cual pondremos en la siguiente dirección:

/var/www Se debe crear una carpeta dentro de la dirección anterior, en la cual se almacenará las páginas web que mostraremos.

mkdir ajedrez.org Para realizar la prueba simplemente escribiremos un archivo html, dentro de la carpeta “ajedrez.org”, con el nombre de index.html.

Redirección local Para que el navegador no busque por internet nuestro sitio, y lo localice localmente es necesario que editemos el archivo siguiente:

/etc/hosts Dentro de este archivo pondremos lo siguiente, para que busque en nuestra máquina o en la máquina donde esté el servidor apache.

IP www.ajedrez.org 127.0.0.1 www.ajedrez.org (Local)

Configuración del VirtualHost Por cada VirtualHost que necesitemos tener es necesario realizar lo siguiente:

Ir a la dirección /etc/apache2/sites­available

Crear el archivo de configuración, para nuestro ejemplo será ajedrez.org touch ajedrez.org

9

Editar el archivo creado en el paso anterior, agregando lo siguiente. nano ajedrez.org

<VirtualHost *:80>

ServerName www.ajedrez.org DocumentRoot /var/www/ajedrez.org

</VirtualHost> Habilitar VirtualHost Una vez creado el archivo de configuración correspondiente a nuestro VirtualHost es necesario habilitarlo, para que apache sepa que está disponible. Para ello es necesario ejecutar lo siguiente:

a2ensite ajedrez.org

Reiniciar el servidor Finalmente se requiere reiniciar el servidor apache, para que cargue la nueva configuración que hemos realizado, para ello ejecutamos:

/etc/init.d/apache2 reload

Y podremos acceder al navegador y ejecutar la dirección www.ajedrez.org, el cual nos mostrará lo que hayamos puesto en nuestro documento index.html.

MÚLTIPLES DIRECCIONES Si se tiene un sistema que dispone de varias direcciones IP y se quiere que cada una de ellas soporte un sitio web se deberá crear una sección virtual para cada dirección IP.

En este caso los servidores virtuales definidos reciben las solicitudes en función de la IP requerida, no del nombre del servidor.

Si no se dispone de un equipo con varias interfaces de red se puede probar creando alias de la tarjeta disponible.

Para ello hay que editar el archivo interfaces añadiendo lo siguiente:

/etc/network/interfaces

10

auto eth0:0 iface eth0:0 inet static address IP_nueva por ejemplo 192.168.1.2 netmask 255.255.255.0 network 192.168.1.0

Se está creando un alias de la tarjeta ethernet eth0 y se le asigna la IP 192.168.1.2. Se supone que la tj eth0 tiene IP 192.168.1.1.

A partir de este momento el sistema ya dispone de 2 interfaces de red, una real y un alias que permite definir un host virtual alojado en el mismo servidor web.

Para realizar esta configuración repetimos el proceso de la creacion de un HostVirtual descrita anteriormente pero ahora el archivo de configuración dentro de sites­available:

<VirtualHost 192.168.1.2>

ServerName virtual.dominio.com DocumentRoot /var/www/virtual ErrorLog /var/log/apache2/virtual­error.log

</VirtualHost>

También es posible configurar hosts virtuales mixtos, es decir basados en nombres y en IP.

Host virtual basado en puertos

Vamos a suponer que, para una misma dirección IP, el servidor web quiere mostrar diferente contenido según el puerto en el que se realiza la conexión HTTP.

Para ello habrá que indicar en la sección <VirtualHost> y en NameVirtualHostel puerto asociado y todos los puertos utilizados para atender peticiones deben estar Listen.

NameVirtualHost 192.168.1.1:80 <VirtualHost 192.168.1.1:80> ServerName servidor.dominio.com DocumentRoot /var/www/servidor80 </VirtualHost> <VirtualHost 192.168.1.1:443> ServerName servidor.dominio.com DocumentRoot /var/www/servidor443

11

</VirtualHost> En este caso el acceso al servidor web, si se llama igual, debe incluir el puerto por el cual se realiza la petición HTTP. En la URL habrá que escribir:

http://servidor.dominio.com:443/ Si se utiliza un puerto diferente al 80 (por defecto) hay que revisar el archivo /etc/apache2/ports.conf e incluir las líneas Listen correspondientes a los nuevos puertos de escucha de Apache2.

SERVIDOR WEB CON RESTRICCIONES DE USUARIOS Respecto al proceso de Autenticación de usuarios en Apache 2 existen dos métodos:

Básico o Simple: el usuario en el navegador web introduce su login o nombre de usuario y contraseña y se envían al servidor sin cifrar.

Digest: el usuario en el navegador web introduce su login y contraseña y se envían al servidor cifrados.

Estos dos métodos sólo autentican al usuario cuando intenta acceder a un recurso. Pero en ninguno de los dos métodos los datos que a continuación se envían del navegador web al servidor o viceversa van cifrados. Son métodos que controlan el acceso a los recursos, pero no protegen la información intercambiada en la comunicación cliente­servidor una vez se ha comprobado que el acceso es válido.

Autenticación Básica Esta autenticación guarda los usuarios y sus contraseña encriptadas en un archivo. Los usuarios y contraseñas se tienen que ir metiendo uno a uno. Este módulo de apache viene activado por defecto. Para utilizarlo en nuestra página añadiremos las siguientes líneas al archivo de configuración en

/etc/apache2/sites­available AuthType basic AuthName “Identifiquese” AuthUserFile /etc/apache2/passwd/passwords Require valid­user

12

Un ejemplo de integración sería el siguiente: <VirtualHost *:80>

ServerName www.ajedrez.org DocumentRoot /var/www/ajedrez.org

<Directory /var/www/ajedrez.org>

AuthType basic AuthName “Identifiquese” AuthUserFile /etc/apache2/passwd/passwords Require valid­user

</Directory> </VirtualHost> AuthType basic: Le especificamos que es autenticación básica. AuthName “Identifíquese” : Este será el mensaje que nos aparecerá al pedir la contraseña. AuthUserFile: Esta es la ubicación del fichero con los usuarios y sus contraseñas. Require valid­user: Le indicamos que requiere un usuario válido. También se podría poner uno o varios usuarios poniendo por ejemplo “Require user juan, jose, maria”. Por último para crear el archivo donde se guardan los passwords, utilizamos el comando “htpasswd”. La primera vez que lo utilicemos tenemos que ponerle la opción ­c, para crear el archivo. Agregamos el usuario mediante:

htpasswd ­c /etc/apache/passwd/passwords usuario New password: Re­type new password: Si queremos añadir otro usuario no le pondremos la opción ­c. Si ahora intentamos acceder a nuestra página nos se nos solicitará el usuario y la contraseña señalada.

13

SERVIDOR WEB CON BALANCEO DE CARGA El balanceo de carga en un servidor web permite crear un sistema de alta disponibilidad que evita las caídas de los servicios con el objetivo de estar el máximo tiempo posible activos para los usuario. Cuando una pagina o aplicacion web comienza a recibir un gran número de visitantes es importante repartir la carga de trabajo en dos o más servidores, gracias al balanceo de carga que ofrece Apache, el cual integra soporte de sesión de cada usuario(esto es que si un usuario es redireccionado a otro servidor del sistema no cambia aleatoriamente a otros servidores). se utilizan diversos algoritmos de organización pero los más utilizados son :

ROUND ROBIN: los usuarios son repartidos aleatoriamente por los servidores que componen el sistema

IPHASH: las direcciones ip de los visitantes son comparadas con una tabla definida en el servidor y dependiendo de su existencia son redirigidos

LEAST CONNECTIONS: el recurso de cada servidor es detectado automáticamente y se efectúa un redireccionamiento de cada usuario al servidor com mas recursos disponibles.

Desde la versión 2.2 de Apache tiene el módulo proxy_balancer destinado a crear un sistema de balanceo de carga, para ello es necesario activar: 1) a2enmod proxy: habilita el uso de un proxy destinado al direccionamiento de los visitantes a los servidores web. 2) a2enmod proxy_balancer: implementa el funcionamiento para el balanceo de carga. 3) a2enmod proxy_http:añade soporte al proxi para las peticiones http. Un vez instalado y activado el modulo en apache, necesitamos realizar la configuración para realizar el balanceo (/etc/apache2/sites­available) dentro de un VirtualHost. Teniendo la estructura como sigue: <VirtualHost *:80>

14

Servername www.balanceo.com ProxyRequests Off ProxyPassReverse / http://192.168.189.155:8080 ProxyPassReverse / http://192.168.1.65:8080 <Proxy balancer://testcluster> BalancerMember http://192.168.189.155:8080/balanceo route=nodo1 BalancerMember http://192.168.1.65:8080/balanceo route=nodo2 ProxySet lbmethod=byrequests </Proxy> ProxyPass /balancer­manager ! ProxyPass / balancer://testcluster/ nofailover=On <Location /balancer_manager> SetHandler balancer­manager Order deny,allow Allow from all </Location> </VirtualHost> Para configurar cada uno de los servidores es necesario configurar el archivo server.xml ubicado en el directorio conf de cada servidor tomcat. Primero es necesario habilitar la siguiente línea

<Engine name=”Catalina” defaultHost=”localhost” jvmRoute=”nodo1″>

donde nodo1 es la ruta del protocolo jvm para el balanceador. Para el tomcat2 será nodo2. Luego es necesario desactivar la línea de la implementación del clúster del servidor

<Cluster className=”org.apache.catalina.ha.tcp.SimpleTcpCluster”/>

Por último se guarda el archivo y se reinicia el servidor.

15

SERVIDOR WEB CON SEGURIDAD HTTPS Apache nos permite crear sitios con seguridad https, esto es, que el cliente que envía datos a través de la red estén cifrados y no sean susceptibles a que si alguna tercera persona logra capturarlos pueda hacer uso malintencionado de los mismos. Para la implementación, necesitamos habilitar el módulo SSL (Secure Sockets Layer) para apache y obtener un certificado que esté firmado con el fin de poder distribuir una llave pública. Este certificado debe de tener una firma que en nuestro caso será autofirmada, pero se puede pagar la firma de nuestro propio certificado a empresas como VeriSign para que sea reconocido en los navegadores web modernos. Creando el certificado Para la creación del certificado haremos uso de la aplicación open ssl, en la terminal ejecutamos lo siguiente: openssl genrsa ­out ca.key 1024 En la cuál estamos indicando en genrsa que utilice el algoritmo RSA con 1024 bits. Ahora generamos el CSR (Certificate Signing Request), que crea una entidad para pedirle a una tercera que lo firme, verificando así que los datos de la primera entidad son correctos. En consola: openssl req ­new ­key ca.key ­out ca.csr Debido a que no contamos con recursos para pagar la firma del certificado, nos lo autofirmamos: openssl x509 ­req ­days 365 ­in ca.csr ­signkey ca.key ­out ca.crt Donde el parámetro days especifica el tiempo de validez del certificado, en este caso un año. Ahora, procedemos a mover los archivos creados a la ruta donde serán lozalizados con apache: mv ca.crt /etc/ssl/certs mv ca.key /etc/ssl/private/ca.key mv ca.csr /etc/ssl/private/ca.csr

16

En el servidor apache hay que activar el módulo SSL, para ello nos movemos a la carpeta sites­available de apache y creamos un archivo con la configuración que se describe abajo. cd /etc/apache2/sites­available touch ssl­conf nano ssl­conf En el archivo ss­conf: NameVirtualHost *:443 <VirtualHost *:443> SSLEngine on SSLCertificateFile /etc/ssl/certs/ca.crt SSLCertificateKeyFile /etc/ssl/private/ca.key AllowOverride All DocumentRoot /var/www/sitiohttps ServerName sitiohttps.com </VirtualHost> Guardamos y cerramos el archivo y lo habilitamos: en2site ss­conf Por último reiniciamos el servicio: sudo /etc/init.d/apache2 restart Con esto podemos entrar al navegador e introducir el dominio de nuestro sitio con el prefijo https:// . Cabe señalar que al abrir la página nos saldrá un mensaje de aviso sobre el certificado ya que, como es autofirmado el navegador no lo reconoce y lo interpreta como no válido.

MONITOREO DE RECURSOS CON MUNIN Munin es una herramienta multiplataforma basada en web, utilizada en el monitoreo

de los recursos en red. Las principales características de esta herramienta son las siguientes:

17

Cuenta con una interfaz web que muestra el uso de recursos históricamente. Monitorea cada máquina configurada en el archivo munin.conf. Los principales recursos monitoreados son disco, red,CPU, RAM, entre otros. Genera gráficas por día, semana, mes y año de cada uno de los recursos

monitoreados. Es posible configurar umbrales de alerta para estado de advertencia y crítico.

La herramienta de munin esta desarrollada bajo el lenguaje de programación perl,

utilizando RRDtool para la construcción de gráficas; este software tiene una licencia GNU.

ESTRUCTURA DE MUNIN Munin se encuentra conformado por tres componentes principales.

Servidor: Un demonio que corre en todas las máquinas monitoreadas, por default en el puerto 4949. Su función es configurar y llamar a los plugins. Cuando se habla de munin­node, se refiere al servidor.

Plugins: Cada uno de los agentes de recolección de datos que son invocados

por munin­node. Dan la información que monitorean, y son también capaces de describir su función y configuración.

Cliente: Proceso que corre periódicamente (normalmente cada 5 minutos)

desde un nodo central, interrogando a cada uno de los servidores munin­node, y generando las páginas Web.

INSTALACIÓN Y CONFIGURACIÓN

Ya que se ha hablado acerca de apache y su configuración, realizaremos un monitoreo de los recursos que este ocupa utilizando esta herramienta; como ya tenemos instalado apache en nuestra máquina solo queda la instalación de los paquetes de munin, que se realizará con el siguiente comando, tomando en cuenta que se esta trabajando con el superusuario root.

apt­get install munin munin­node Con esto tendremos listo el Servidor y un nodo que representa a la estructura cliente.

18

Despues pasamos a la configuración de la herramienta, como primera configuración editaremos el archivo /etc/munin/munin.conf de tal manera que se aproxime a lo siguiente: dbdir /var/lib/munin htmldir /var/cache/munin/www logdir /var/log/munin rundir /var/run/munin # # Where to look for the HTML template tmpldir /etc/munin/templates # a simple host tree [server.org] address 192.168.1.65 use_node_name yes Esto es necesario ya que se le indica a Munin los directorios de trabajo. Luego especificamos las direcciones ip de los nodos a monitorear. Para configurar nuestro nodo, es decir, la parte de Munin que recoge los datos, editaremos el fichero /etc/munin/munin­node.conf. log_level 4 log_file /var/log/munin/munin­node.log pid_file /var/run/munin/munin­node.pid background 1 setsid 1 user root group root ignore_file ~$ ignore_file DEADJOE$ ignore_file \.bak$ ignore_file %$ ignore_file \.dpkg­(tmp|new|old|dist)$ ignore_file \.rpm(save|new)$ ignore_file \.pod$ host_name host.mydomain.com allow ^127\.0\.0\.1$ allow ^192\.168\.1\.65$ allow ^192\.168\.1\.21$ host *

19

host 127.0.0.1 host 192.168.1.65 host 192.168.1.21 port 4949 Este es nuestro archivo configurado con los nodos correspondientes. Despues de haber realizado la configuración del servidor, solo queda dar inicio al

servicio, esto se realizará mediante el siguiente comando:

service munin­node start

Para reiniciar el servicio tenemos el siguiente comando:

service munin­node restart

Para detener el servicio basta con teclear lo siguiente: service munin­node stop

Para añadir otros clientes solo tenemos que instalar el nodo de la siguiente manera en la máquina que se desea monitorear.

apt­get install munin­node Ahora tan solo tenemos que editar el archivo munin­node.conf de la siguiente forma: log_level 4 log_file /var/log/munin/munin­node.log pid_file /var/run/munin/munin­node.pid background 1 setsid 1 user root group root # Regexps for files to ignore ignore_file ~$ #ignore_file [#~]$ # FIX doesn't work. '#' starts a comment ignore_file DEADJOE$ ignore_file \.bak$ ignore_file %$ ignore_file \.dpkg­(tmp|new|old|dist)$ ignore_file \.rpm(save|new)$ ignore_file \.pod$ # Set this if the client doesn't report the correct hostname when

20

# telnetting to localhost, port 4949 # host_name server.org # A list of addresses that are allowed to connect. This must be a # regular expression, since Net::Server does not understand CIDR­style # network notation unless the perl module Net::CIDR is installed. You # may repeat the allow line as many times as you'd like #allow ^127\.0\.0\.1$ allow ^192\.168\.1\.65$ # If you have installed the Net::CIDR perl module, you can use # multiple cidr_allow and cidr_deny address/mask patterns. A # connecting client must match any cidr_allow, and not match any # cidr_deny. Example: # cidr_allow 127.0.0.1/32 # cidr_allow 192.0.2.0/24 # cidr_deny 192.0.2.42/32 # Which address to bind to; #host * host 192.168.1.21 # And which port port 4949 En ‘allow’ ponemos la ip del servidor munin En ‘host’ ponemos la ip de este nodo Ahora vamos de vuelta otra vez al servidor y definimos en el archivo munin.conf este

nodo: [server2.org] address 192.168.1.21 use_node_name yes reiniciamos con:

service munin­node restart

Ahora resta obtener los datos del servidor apache, para esto es necesario crear un virtualhost de la siguiente manera: Primero creamos un directorio en el servidor de apache:

mkdir /var/www/server.org

Luego escribimos el host en el archivo /etc/hosts de la siguiente manera:

21

192.168.1.65 server.org

Ahora vamos a crear el archivos de configuración para cada el VirtualHost. Lo crearemos dentro de /etc/apache2/sites­available con el nombre de la página para distinguirlos fácilmente en este caso sera server.org dentro de este archivo escribiremos lo siguiente: <VirtualHost *:80> ServerAdmin webmaster@server.org ServerName server.org DocumentRoot /var/cache/munin/www <Directory /> Options FollowSymLinks AllowOverride None </Directory> LogLevel notice CustomLog /var/log/apache2/access.log combined ErrorLog /var/log/apache2/error.log ServerSignature On </VirtualHost> Una vez que hemos creado el archivo VirtualHost solamente nos queda habilitarlo;

para ello utilizaremos el comando a2ensite server.org dentro de la carpeta /etc/apache2/sites­available. FInalmente se ejecuta lo siguiente para cargar los datos en apache:

service apache2 reload Ahora asignaremos el tiempo que tardará munin para obtener los datos y graficarlos,

para esto ejecutaremos el siguiente comando

sudo ­u munin crontab ­e

Y agregaremos la siguiente línea, con la cual obtendremos estos datos cada 5 minutos. #m h dom mon dow command */5 * * * * munin­cron

22

Realizado lo anterior ya se puede ingresar al directorio de munin en el servidor de apache ingresando a la siguiente dirección:

http://dirección_ip/munin

En la dirección se mostrará un resultado parecido a lo mostrado en la Figura 1, con esto ya tenemos instalada la herramienta, para trabajar con ella.

Figura 1. Herramienta Munin en Apache.

INSTALACIÓN DE PLUGINS Para realizar el mejor monitoreo posible con esta herramienta existe los complementos extra, estos son los plugins que nos permite incrementar las características de munin, estos se pueden encontrar en la web o se pueden realizar en el lenguaje perl; por otra parte para instalarlos es necesario seguir los siguientes pasos: Primero se creará el archivo con el nombre del plugin en el directorio

/usr/share/munin/plugins/plugname con el codigo de ejecucion, luego se creará un enlace simbólico a la carpeta /etc/munin/plugins/plugname con el comando ln ­s quedando de la siguiente forma:

ln ­s /usr/share/munin/plugins/plugname /etc/munin/plugins/plugname Después de crear el enlace simbólico procedemos a la asignación de permisos de la

siguiente manera:

23

chmod 755 /etc/munin/plugins/plugname

Luego procederemos a ingresar los siguientes datos en el archivo de configuración

/etc/munin/plugin­conf.d/munin­node. [plugname] user root env.warning 50 env.critical 65 #options env.procs, env.USERS, etc…

Como se puede observar el plugin se puede configurar con distintas opciones, en este caso existen dos muy importante las cuales nos generan avisos acerca de un consumo excesivo de recursos, tales opciones son env.warning y env.critical. Después ejecutaremos el siguiente comando con el cual configuraremos el plug,

algunos plugins no necesitan los parámetros autoconf o config, pero otros siguen el siguiente formato:

/etc/munin/plugins/plugname config /etc/munin/plugins/plugname autoconf

Finalmente se reinician los servicios de munin y apache, ahora solo queda esperar un poco de tiempo para que munin obtenga los recursos que el plugin esta monitoreando.

service munin­node restart

service apache2 restart

PRUEBAS Y RESULTADOS Como primeras pruebas se ha utilizado la aplicación ApacheBench la cual es una herramienta que nos permite medir el rendimiento de su servidor, de tal forma que crearemos un pool de conexiones al servidor apache, para que munin capture los datos de consumo de recurso, para realizar esto ejecutaremos lo siguiente:

ab ­n 8000000 ­c 10 http://192.168.1.65/

24

Con esto lo que estamos realizando es una conexión de 8 000 000 de clientes en 10 hilos a la direccion http://192.168.1.65/ donde tenemos alojada nuestra pagina WEB, después de haber realizado esto tenemos la figura 2 donde se muestra los accesos por dia al servidor apache, que es aproximado a las peticiones que hemos hecho con ApacheBench.

Figura 2. Accesos por día al servidor Apache. En la figura 3 se muestra los datos obtenidos por munin correspondiente a la cantidad

de procesos de apache en un determinado tiempo, se observa un pequeño periodo de una cantidad considerable de procesos esto es a causa de las peticiones creadas por parte de ApacheBench.

25

Figura 3. Procesos de Apache con peticiones de conexión.

Ahora en la figura 4 se observa el porcentaje de uso del cpu por parte de los

procesos de apache; en el periodo de tiempo en donde se ven altos porcentajes de uso de cpu es debido a los clientes generados por ApacheBench.

Figura 4. Porcentaje de uso del CPU por parte de Apache.

26

Por otra parte otro recurso monitoreado es el consumo de memoria RAM, el cual se muestra en la figura 5, se muestra únicamente el uso de memoria por parte del servidor apache2 que crece en porcentajes de uso debido a las peticiones creadas por parte de ApacheBench.

Figura 5. Segmento de Memoria Ram utilizada por Apache. FInalmente se muestra en la figura 6 los paquetes recibidos por parte de la tarjeta de

red correspondiente al firewall de apache.

Figura 6. Paquetes recibidos y enviados por minuto por Apache.

27

Para realizar la correcta configuración de los niveles críticos y de warnings en el servidor, se ha de configurar el archivo/etc/munin/munin.confagregando la direccion de correo electronico a la cual enviará la notificación, por otra parte se asignaran los niveles de warning y critical siguiendo el siguiente formato pluname.variable.critical,warning valor, para el correo se agregaran las siguientes lineas al archivo: contact.me.command mail ­s "Munin notification $var:host" user@host.tld contact.me.always_send warning critical Finalmente nos hemos tomado la tarea de llevar el servidor a un punto crítico, para

que la herramienta Munin nos de un aviso, para esto hemos de crear 15 hilos con 10 000 000 de clientes en ApacheBench; tomando como recurso el porcentaje de uso de cpu, colocando un nivel de warning del 160% y un nivel crítico del 180%.Los resultados obtenidos se muestran en la figura 7, en la cual se muestra que se ha superado niveles warning y en la figura 8 se muestra la notificación de un warning en el uso del cpu por el servidor de apache.

Figura 7. Servidor superando uso de recursos.

28

Figura 8. Notificaciones de warning.

29