~~ODT~~ ====== Servidores GNU/Linux ====== Estos materiales se licencian bajo la «Creative Commons Reconocimiento-CompartirIgual License España». Para ver una copia de esta licencia, se puede visitar http://creativecommons.org/licenses/by-sa/3.0/es/ **Autores**: * Pablo Boronat Pérez (Universitat Jaume I) * Miguel Pérez Francisco (Universitat Jaume I) * David Rubert Viana (Universitat Jaume I) ====== Introducción ====== * [[http://es.wikipedia.org/wiki/GNU_Linux|GNU/Linux en Wikipedia]] * [[http://www.top500.org/stats/list/36/os|Uso de Linux en los grandes servidores]]. (linux 80% de cuota total). * [[http://news.netcraft.com/archives/2011/06/01/most-reliable-hosting-company-sites-in-may-2011.html|Servidores de hosting más fiables]] (Junio 2011). Los sistemas GNU/Linux son ideales para albergar cualquier tipo de servicio, en nuestro caso para todos aquellos servicios relacionados con el buen funcionamiento de la red (DNS, Web, Correo, etc.). La principal característica de estos sistemas en un entorno de computadores servidor es por un lado la fiabilidad y rendimiento del sistema, y por otro lado la libre disposición de todo tipo de herramientas open-source. La práctica totalidad de servicios que montemos en estas computadores tienen disponibles las fuentes de las aplicaciones en repositorios abiertos, por lo que esto nos facilitará cualquier labor administrativa, como puede ser compilar un pequeño cambio o realizar una configuración del entorno a medida. ====Qué distribución utilizar==== * [[http://es.wikipedia.org/wiki/Distribución_linux]] Una distribución de Linux nos proporciona un kernel de Linux junto con una serie de utilidades administrativas y un sistema de empaquetado de software (binario normalmente), personalizado en función del mercado al que vaya dirigido (escritorio, servidor, portátiles). La distribución que deberemos utilizar es aquella con la que nos sentamos más cómodos. Dependiendo del hardware y de nuestra experiencia pueden ser más o menos recomendables unas distribuciones sobre otras. * [[http://www.debian.org|Debian]]. Distribución por excelencia para servidores. * [[http://www.ubuntu.com/|Ubuntu]] (Server edition). * [[http://fedoraproject.org/|Fedora]]. * [[http://www.archlinux.org/|Arch Linux]]. * [[http://www.gentoo.org/|Gentoo]]. * [[http://www.nslu2-linux.org/wiki/Optware/HomePage|Optware]] + [[https://openwrt.org/|OpenWRT]]. ====Hardware para una distribución UNIX==== La potencia que nos puede proporcionar una distribución Linux, capaz de realizar cualquier tarea de propósito general, en conjunto con una hardware adecuado (bajo consumo, bajo coste) optimizará al máximo la solución a nuestras necesidades. En las imágenes, ponemos como ejemplo hardware de Alix, RaidSonic, Synology o Qnap por tener algunas referencias de hardware específico pensado para funcionar con una distribución Linux, aunque hay que recordar que podemos montar nuestro servidor sobre cualquier PC genérico. ^ Alix ^ Características (Aproximadas) ^ | {{:public:guifinet:cursoinstaladoresguifi2011:servidoresgnulinux:alix.jpg?240}} | **Consumo**: 5W | | ::: | **RAM**: 128 o 256MB | | ::: | **CPU**: 433 o 500Mhz | | ::: | USB, Ethernet, MiniPCI | | ::: | Bajo precio, bajo consumo, rendimiento moderado | [[http://pcengines.ch/alix.htm]] ^ RaidSonic ICY BOX 4220 ^ Características (Aproximadas) ^ | {{:public:guifinet:cursoinstaladoresguifi2011:servidoresgnulinux:icybox.jpg?240 }} | **Consumo**: 25W | | ::: | **RAM**: 256MB | | ::: | **CPU**: 400Mhz | | ::: | USB, Ethernet | | ::: | Bajo precio, bajo consumo, rendimiento adecuado | [[http://nas-4220.org]] ^ Synology 411 ^ Características (Aproximadas) ^ | {{:public:guifinet:cursoinstaladoresguifi2011:servidoresgnulinux:ds411.jpg?240 }} | **Consumo**: 60W | | ::: | **RAM**: 1GB | | ::: | **CPU**: 1,8Gz dual core | | ::: | USB, Ethernet gigabit | | ::: | Alto precio, bajo consumo, alto rendimiento | [[http://www.synology.com/mx/products/DS411+II/index.php]] ^ QNAP 459 ^ Características (Aproximadas) ^ | {{:public:guifinet:cursoinstaladoresguifi2011:servidoresgnulinux:qnap459.jpg?240 }} | **Consumo**: 35W | | ::: | **RAM**: 1GB | | ::: | **CPU**: Atom dual core | | ::: | USB, Ethernet gigabit | | ::: | Alto precio, bajo consumo, alto rendimiento | [[http://www.qnap.com/pro_detail_feature.asp?p_id=144]] ====== Webmin ====== * http://www.webmin.com * http://es.wikipedia.org/wiki/Webmin Webmin es una herramienta de apoyo a la administración/configuración de diferentes servicios del sistema (o incluso el mismo sistema) vía web, facilitándonos el proceso de puesta en marcha de cualquier utilidad gracias a un entorno pensado para enmascarar los detalles más técnicos (diferentes archivos de configuración, diferentes sintaxis, etc). Además nos permite asignar privilegios específicos a usuarios a los que queremos delegar la responsabilidad sobre determinados apartados de nuestro servidor. ===== Configuración ===== La práctica totalidad de configuración de Webmin se realiza vía web, pero hay algunos apartados que no hay más remedio que configurarlos a través de archivos de configuración. Veamos los principales archivos que deberemos modificar para poner en marcha Webmin en nuestro sistema. ==== miniserv.conf ==== En este archivo de configuración definiremos, a través de directivas, el funcionamiento del servicio web a través del cual funcionará **Webmin**. Veamos las más importantes: port=10000 allow=127.0.0.1 192.168.1.0/24 La autenticación de usuarios de Webmin se realiza a través de un archivo de contraseñas, definido mediante la siguiente directiva en miniserv.conf: userfile=/etc/webmin/miniserv.users Podemos cambiar la contraseña o el usuario de administración de Webmin desde línea de comandos utilizando un script llamado **changepass.pl**. /usr/libexec/webmin/changepass.pl /etc/webmin admin foo ==== Capturas de pantalla de Webmin ==== **Login:** {{:public:guifinet:cursoinstaladoresguifi2011:servidoresgnulinux:webmin01.png?700|}} **Página principal:** {{:public:guifinet:cursoinstaladoresguifi2011:servidoresgnulinux:webmin02.png?700|}} **Configuración de Webmin:** {{:public:guifinet:cursoinstaladoresguifi2011:servidoresgnulinux:webmin03.png?700|}} **Configuración del proxy Squid:** {{:public:guifinet:cursoinstaladoresguifi2011:servidoresgnulinux:webmin04.png?700|}} ===== Control de acceso ===== Una de las ventajas de Webmin, además de unificar la administración del sistema en un interfaz web, es que nos permite de manera sencilla delegar determinadas labores de administración a usuarios concretos. Por ejemplo, podríamos crear un usuario encargado únicamente de la gestión del proxy, o del servidor web, del DNS, etc. Esto se realiza desde el apartado de gestión de usuarios de Webmin, que a su vez nos permite definir el tipo de rol que queremos asignarle al usuario. {{:public:guifinet:cursoinstaladoresguifi2011:servidoresgnulinux:webminusers01.png?700|}} {{:public:guifinet:cursoinstaladoresguifi2011:servidoresgnulinux:webminusers02.png?700|}} ===== Módulos adicionales ===== En la distribucion de **Webmin** vienen incluidos una gran cantidad de módulos para gestionar servicios a través de Webmin. Podéis ver una lista completa de módulos "standard" aquí: http://www.webmin.com/standard.html Si no encontramos el servicio/herramienta que queremos gestionar vía **Webmin** en los módulos standard, podemos buscarlo en la lista de módulos desarrollados por terceros: http://www.webmin.com/third.html **Ejercicio 6.1 (Sólo presencial):** Accede a Webmin en la IP: 150.128.49.223, user:root, pass: guifi. Navega por las principales secciones, y añade un usuario Squid que tenga únicamente permisos de administrar el proxy Squid. ====== Proxy web Squid ====== * [[http://www.squid-cache.org/]] * [[http://es.wikipedia.org/wiki/Squid_(programa)]] Squid es un servidor proxy basado en código abierto. La misión de un servidor proxy es hacer de intermediario entre una petición de cliente y un servidor remoto, almacenando (cacheando) la información por si nuevas peticiones de clientes pudieran reaprovecharla. Tuvieron mucho auge hace unos años ya que gracias a ellos se conseguía ahorrar mucho ancho de banda, sobre todo con contenidos estáticos y públicos. Hoy en día que el ancho de banda sobra y los contenidos son muy personalizados para el cliente no tienen tanto sentido, excepto en aquellos sitios en los que se quiere tener una red privada controlada donde todas las máquinas conectan a internet (principalmente la web) a través de un único punto de salida, en este caso el servidor proxy. {{:public:guifinet:cursoinstaladoresguifi2011:servidoresgnulinux:esquema-proxy.jpg?700|}} ===== Los clientes de un servidor proxy ===== Cualquier navegador moderno tiene su apartado de configuración donde permite acceder a internet a través de proxy. Veamos como ejemplo la configuración necesaria en Firefox para acceder a un proxy. {{:public:guifinet:cursoinstaladoresguifi2011:servidoresgnulinux:firefox1.png|}}{{:public:guifinet:cursoinstaladoresguifi2011:servidoresgnulinux:firefox2.png|}} Una de las ventajas de un servidor proxy es que él mismo nos realizará las peticiones de resolución de nombres, por lo que en el ordenador cliente no hará falta que tenga ni siquiera configurado un DNS. ===== Configuración: squid.conf ===== Toda la configuración de squid se centraliza en un archivo: **squid.conf**. El archivo en sí no es complejo pero sí muy extenso, aunque sólo deberemos configurar aquellas preferencias que cambien el comportamiento por defecto. Disponemos de una versión documentada de este archivo donde se nos explicará cada una de las directivas y su sintáxis, además de una página web de referencia donde encontraremos ejemplos de uso de cada una de ellas: [[http:www.squid-cache.org:doc:config]]. Veamos algunas de las opciones más importantes con las que nos encontraremos. ====Puerto de escucha de Squid==== Por defecto, squid escuchará en el puerto 3128. Esta directiva es la que configura esta característica del servidor: http_port 10.228.144.163:3128 ====Directorio de caché de archivos==== # ufs: Formato de almacenamiento de caché # /var/cache/squid: Directorio del sistema donde almacenar la cache # 100: Número de megabytes máximos a utilizar en la caché # 16 256: Número de directorios de primer y segundo nivel aa crear (mejor no cambiar). cache_dir ufs /var/cache/squid 100 16 256 ==== Limitando el acceso al proxy a una subred específica ==== acl ip_acl src 192.168.1.0/24 http_access allow ip_acl http_access deny all ==== Control de acceso ==== Los permisos y restricciones de acceso a nuestro proxy Squid las realizamos a través de ACL's (//Access Control List//). Podemos definir diferentes tipos de ACL's, a las que posteriormente les podremos aplicar, por orden, prioridades de acceso. Tenemos ACL's para controlar, principalmente, acceso a los puertos y acceso por subredes. Hoy en día la navegación web es el principal exponente de Internet, y justamente en un proxy son los puertos de la web los que van a tener más éxito entre nuestros usuarios. Si nuestra política en el proxy va a ser cerrar todos los puertos menos los que queremos abrir (lo más recomendable) utilizaremos la siguiente configuración. acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT # Deny requests to certain unsafe ports http_access deny !Safe_ports # Deny CONNECT to other than secure SSL ports http_access deny CONNECT !SSL_ports Los puertos SSL necesitan una configuración específica, ya que la conexión se debe hacer a través de un túnel utilizando los comandos CONNECT que nos proporciona el protocolo HTTP. ===== El log de squid ===== * [[http://wiki.squid-cache.org/SquidFaq/SquidLogs]] Toda la información relativa al funcionamiento y uso de nuestro servidor proxy irá a parar a los archivos de log de squid, veamos en detalle su sintáxis y cómo tratarlos para extraer la información que nos interesa. ==== logformat ==== Define la sintaxis con la que queremos almacenar el log en el archivo. Lo mejor es utilizar las definiciones que nos vienen por defecto, ya que así podremos utilizar programas de parseo directamente, sin tener que informarle de nuestras modificaciones. logformat squid %ts.%03tu %6tr %>a %Ss/%03>Hs % **Ejercicio 6.2** Accede a la página de http://guifi.net y busca la página donde están especificados todos los servidores proxy montados en Castellon. ¿Cuál es el código ID del proxy del supernodo Castalia? ===== Squid con Webmin ===== La herramienta de configuración de sistema vía web **Webmin** de la que hemos hablado antes nos permite administrar de una manera cómoda todas las funciones principales de **Squid**. Veamos las partes de configuración web más importantes. {{:public:guifinet:cursoinstaladoresguifi2011:servidoresgnulinux:webmin_squid01.png?700|}} ==== Control de acceso ==== Podemos definir los tipos de control de acceso que queremos aplicar, y el orden en el que los queremos aplicar para que unos tengan prioridad sobre otros. {{:public:guifinet:cursoinstaladoresguifi2011:servidoresgnulinux:webmin_squid_acl01.png?700|}} {{:public:guifinet:cursoinstaladoresguifi2011:servidoresgnulinux:webmin_squid_acl02.png?700|}} ==== Usuarios y autenticación básica ==== Si queremos tener una base de datos de usuario/contraseña autorizados para acceder al proxy, y no queremos hacer un montaje de proxies federados, podemos realizar la siguiente configuración desde Webmin. 1. Añadimos un "Programa de autentificación" del tipo "Autenticación básica" , "Por defecto de Webmin". Es decir, vamos a utilizar autenticación básica en el navegador autenticando contra un archivo de usuarios del estilo de Apache. 2. Añadiremos los usuarios en la nueva sección de "Usuarios" que nos aparece. 3. En el control de acceso, añadimos una nueva ACL del tipo "Autentificación Externa" llamada "autenticados". 4. Le damos prioridad a esta ACL, de manera que si el usuario se autentica se le permita conectarse al proxy. {{:public:guifinet:cursoinstaladoresguifi2011:servidoresgnulinux:squid_users04.png?700}} {{:public:guifinet:cursoinstaladoresguifi2011:servidoresgnulinux:squid_users01.png?700}} {{:public:guifinet:cursoinstaladoresguifi2011:servidoresgnulinux:squid_users02.png?700}} {{:public:guifinet:cursoinstaladoresguifi2011:servidoresgnulinux:squid_users03.png?700}} {{:public:guifinet:cursoinstaladoresguifi2011:servidoresgnulinux:squid_users05.png?700}} **Ejercicio 6.3 (presencial)** 1. Configúrate el navegador para acceder a través de proxy, con estos datos: IP: 150.128.49.223, puerto: 3128. 2. Entre todos, vamos a configurar desde Webmin el acceso al proxy autenticado. 3. Crearemos un usuario cada uno de nosotros a los que permitiremos el acceso al proxy. 4. Accederemos de nuevo al proxy, esta vez con el usuario que hemos creado. 5. Finalmente, generaremos un report de accesos que podremos navegar accediendo aquí. http://150.128.49.223/squid-reports ====== Servidor de gráficas ====== * [[http://es.wiki.guifi.net/wiki/Servidor_de_gráficas]] * https://gitorious.org/guifi/snpservices Una de las herramientas más útiles de las que disponemos en la web de guifi.net, es la de poder ver en cada momento el estado de un supernodo gracias a unas gráficas donde se representa el tráfico transferido en cada uno de los interfaces, así como otras gráficas con la latencia del ping. Ejemplos: {{:public:guifinet:cursoinstaladoresguifi2011:servidoresgnulinux:graph01.png?700|}}{{:public:guifinet:cursoinstaladoresguifi2011:servidoresgnulinux:graph02.png?700|}}{{:public:guifinet:cursoinstaladoresguifi2011:servidoresgnulinux:graph03.png?700|}} Estas gráficas nos proporcionan un histórico a 24h, 1 semana, 1 mes o 1 año del estado de nuestro nodo. Pero estas gráficas no se generan directamente desde la web de guifi.net. ¿Cómo es posible que desde Internet podamos ver las gráficas que monitorizan diferentes nodos/supernodos, incluso aquellos ubicados en zonas sobre las que no podemos acceder? Veamos cómo funciona. Para entender cómo llega a funcionar este servicio, tenemos que explicar un poco la infraestructura utilizada. Partimos de las siguientes premisas: * No es un servicio centralizado, sino distribuido. Hay repartidos decenas de servidores de gráficas por toda la geografía. * Cada servidor de gráficas se encarga de una o varias zonas. Para definir de qué zona se encarga cada servidor deberemos tener acceso a la edición de zonas (Castelló de la Plana, Almassora, Atzeneta, etc.) * La máquina que vaya a hacer de servidor de gráficas es muy recomendable que tenga doble pata Internet-guifi.net, de manera que a medida que monitoriza y guarda información sobre los nodos de su zona publicará dicha información en forma de gráficas por la pata de Internet. * Una vez montado el servicio, todos los nuevos nodos que se añadan en las zonas que monitoriza el servidor de gráficas se procesarán automáticamente, sin intervención por nuestra parte. Por tanto, partimos de una máquina con conectividad guifi.net, dispuesta a monitorizar una serie de nodos conectados a su red, y que además tiene conectividad con Internet, donde publicará las gráficas de cada uno de estos nodos que está monitorizando. ¿Qué mejor sistema que un GNU/Linux para llevarlo a cabo? Veamos las herramientas que necesitaremos para llevar a buen puerto el montaje de este servicio. ** Ejercicio 6.4 ** Conéctate a la página de estos dos supernodos: * http://guifi.net/uji * http://guifi.net/ca/node/35901 Uno es el supernodo de la UJI, y otro es el supernodo de Albocasser. Abre las imágenes de gráficas en una nueva ventana. ¿Qué máquina es la que está generando las gráficas? ===== snpservices. Dependencias ===== La herramienta desarrollada desde guifi.net que consigue el propósito que hemos comentado se llama **snpservices**. Esta herramienta tiene dependencia con varios proyectos de software libre que seguro que os suenan y que pasamos a detallar. ==== Apache ==== * http://es.wikipedia.org/wiki/Servidor_HTTP_Apache * http://httpd.apache.org/ Apache es el servidor web de código abierto más utilizado del mundo. ==== PHP ==== * http://es.wikipedia.org/wiki/Php * http://php.net/ PHP es el lenguaje de scripting orientado a la web más utilizado del mundo. ==== RRDtool ==== * http://es.wikipedia.org/wiki/RRDtool * http://oss.oetiker.ch/rrdtool/ **Round Robin Database Tool**. Herramienta de registro y creación de gráficas para datos procesables en series temporales. ==== MRTG ==== * http://es.wikipedia.org/wiki/MRTG * http://oss.oetiker.ch/mrtg/ Herramienta de supervisión y monitorización de hardware de red (típicamente routers), totalmente dependiente de RRDtool. Aunque no tenemos que conocer a fondo cada uno de estos programas, sí que tenemos que saber qué misión cumplen en el conjunto para llegar a dar el servicio de **snpservices**. ==== SNMP ==== * http://es.wikipedia.org/wiki/SNMP Es el protocolo utilizado para intercambiar información de estado entre dispositivos de comunicación. Es perfecto para monitorizar tráfico, estado y disponibilidad de diferentes interfaces de red de un dispositivo. Funciona a través del puerto UDP/161, y aunque la estructura de datos intercambiada es compleja, únicamente deberemos saber cómo habilitarlo en un dispositivo, ya que la faena sucia de consultar, tratar y almacenar los datos la hará por nosotros el mrtg. La única configuración que deberemos realizar en el servicio SNMP es definir la comunidad, en este caso la standard para permitir el acceso en modo lectura a los datos: **public**. ===== Instalando y configurando snpservices ===== Podemos obtener **snpservices** directamente desde el repositorio donde se realiza el desarrollo, o empaquetado para nuestra distribución si utilizamos Debian/Ubuntu. Repositorio GIT del desarrollo principal: * [[https://gitorious.org/guifi/snpservices]] Repositorio GIT del desarrollo del script de empaquetado .deb: * [[https://www.gitorious.org/guifi/snpservices-debian]] Si no queremos complicarnos la vida, podemos añadir directamente un repositorio donde encontramos los binarios empaquetados directamente para Debian/Ubuntu: # vi /etc/apt/sources.list deb http://repo.vic.guifi.net/debian/ ./ # apt-get update # apt-get install snp-services En este artículo del wiki oficial de guifi.net nos lo explican: * [[http://es.wiki.guifi.net/wiki/Servidor_de_gráficas]] ===== Apache ===== Como sabéis, la configuración de Apache se puede complicar extremadamente. En este caso vamos a presuponer que queremos la configuración más sencilla posible, donde tenemos un servidor Apache corriendo en un servidor, y el módulo de PHP5 funcionando en él. Para habilitar la publicación de las gráficas desde Apache deberemos permitir la ejecución de PHP en el directorio /usr/share/snpservices, habilitándola en la URL /snpservices/ de nuestro servidor. Esta sería la directiva que necesitaríamos en el archivo **apache.conf**: Alias /snpservices/ /usr/share/snpservices/ Una vez hecho esto, ya tendremos operativa la URL necesaria para la publicación de gráficas, que tendrá esta pinta: http://direccion-ip-del-servidor/snpservices/graph/graph.php ===== Dar de alta el servicio de gráficas en guifi.net ===== Antes de continuar con la instalación/configuración de snpservices, veamos cómo dar de alta el servicio en guifi.net. Este paso es muy importante, ya que, como sabéis, la integración de la información de la web con la configuración del sistema es vital para que funcionen las cosas en guifi.net. Más si cabe en este servicio. Al dar de alta el nuevo servicio de gráficas, nos va a pedir una información clave, que es la URL donde publica las gráficas este servidor. Tenemos que hacer coincidir esta información con la URL que hemos dado de alta previamente en **Apache**. Además de esto, nos pedirá que asociemos el servicio a un servidor que previamente debemos haber registrado y asignado una IP pública. {{:public:guifinet:cursoinstaladoresguifi2011:servidoresgnulinux:snpgraph01.png?700}} Posteriormente, deberemos indicarle a la zona guifi.net que este nuevo servidor de gráficas será el que se encargará de proporcionar las graficas. Para ello, editaremos la zona y rellenaremos el campo de "servidor de gràfiques per defecte". {{:public:guifinet:cursoinstaladoresguifi2011:servidoresgnulinux:zone01.png?700}} ** Ejercicio 6.5 ** Busca los servicios de "SNP Graph Server" que están funcionando en Castellón. * http://guifi.net/castello * ¿Cuál es la URL donde publica las gráficas el servidor de gráficas de la UJI? * ¿Qué servidor de gráficas se encarga de la zona de Albocàsser? ===== RRDTOOL & MRTG ===== Como ya hemos comentado son unas herramientas escritas en perl, cuya misión es: * RRDTOOL: Almacena datos de cualquier tipo en series progresivas de tiempo y los representa en gráficas. * MRTG: Consulta dispositivos de red, y obtiene y procesa los datos necesarios para almacenarlos en la base de datos de RRDTOOL. Las herramientas son bastante complejas de configurar. Es por esto que el paquete snpservices automatizará la creación de los archivos de configuración por nosotros, además de actualizar constantemente la información sobre los trastos a monitorizar. ===== Configuración de SNPSERVICES ===== Con el ID de servicio de SNP Graph Server que hemos obtenido registrando nuestro servicio previamente en guifi.net, editamos el siguiente archivo para introducir 2 variables: # vi /etc/snpservices/config.php $SNPGraphServerId = 35207; // ID del nodo de nuestro servicio $rootZone = 18688; // ID del nodo de la zona raiz ¿Qué nos falta por configurar? Pues poca cosa más. Expliquemos un poco por encima qué es lo que haría el montaje. Hay un cron ubicado en /etc/cron.d/snpservices, que realiza 2 misiones: * Cada 30 minutos se conecta a la web de guifi.net, y descarga todos los nuevos nodos que hay que monitorizar para las zonas que están asignadas a nuestro servidor de gráficas. Generará el archivo de configuración necesario para MRTG (está ubicado en /var/lib/snpservices/data/mrtg.cfg). * Cada 5 minutos, ejecutará los procesos de monitorización de perl MRTG que se encargarán de ir a consultar cada uno de los cacharros montados en nuestra zona por SNMP, y con la información obtenida guardarla para generar posteriormente las gráficas. Veremos constantemente los siguientes procesos en el sistema: malva-serv:/usr/share/snpservices/data# ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.0 2032 532 ? Ss Jun23 0:15 init [2] root 2 0.0 0.0 0 0 ? S Jun23 0:00 [kthreadd] ... root 32275 1.0 1.6 25760 17060 ? S 18:55 0:00 /usr/bin/perl -w /usr/bin/mrtg /var/lib/snpservices/data/mrtg.cfg --lock-file /var/lock/mrtg root 32276 0.0 1.6 25760 17024 ? S 18:55 0:00 /usr/bin/perl -w /usr/bin/mrtg /var/lib/snpservices/data/mrtg.cfg --lock-file /var/lock/mrtg root 32277 0.0 0.0 1772 560 ? S 18:55 0:00 /bin/ping -c5 -i 0.2 10.228.178.17 -q root 32279 0.0 0.0 1772 556 ? S 18:55 0:00 /bin/ping -c5 -i 0.2 10.228.178.68 -q root 32280 0.0 1.6 25760 17060 ? S 18:55 0:00 /usr/bin/perl -w /usr/bin/mrtg /var/lib/snpservices/data/mrtg.cfg --lock-file /var/lock/mrtg root 32283 0.0 1.6 25760 17024 ? S 18:55 0:00 /usr/bin/perl -w /usr/bin/mrtg /var/lib/snpservices/data/mrtg.cfg --lock-file /var/lock/mrtg root 32284 0.0 1.6 25760 17060 ? S 18:55 0:00 /usr/bin/perl -w /usr/bin/mrtg /var/lib/snpservices/data/mrtg.cfg --lock-file /var/lock/mrtg root 32288 0.0 1.6 25760 17024 ? S 18:55 0:00 /usr/bin/perl -w /usr/bin/mrtg /var/lib/snpservices/data/mrtg.cfg --lock-file /var/lock/mrtg root 32290 0.0 1.5 25760 16520 ? S 18:55 0:00 /usr/bin/perl -w /usr/bin/mrtg /var/lib/snpservices/data/mrtg.cfg --lock-file /var/lock/mrtg root 32292 0.0 1.6 25760 17024 ? S 18:55 0:00 /usr/bin/perl -w /usr/bin/mrtg /var/lib/snpservices/data/mrtg.cfg --lock-file /var/lock/mrtg root 32293 0.0 0.1 2620 1056 ? S 18:55 0:00 /bin/sh /usr/share/snpservices/common/ping.sh 10.228.135.4 root 32295 0.0 0.0 1772 560 ? S 18:55 0:00 /bin/ping -c5 -i 0.2 10.228.135.4 -q root 32296 1.0 1.6 25760 17060 ? S 18:55 0:00 /usr/bin/perl -w /usr/bin/mrtg /var/lib/snpservices/data/mrtg.cfg --lock-file /var/lock/mrtg root 32299 0.0 1.6 25760 17024 ? S 18:55 0:00 /usr/bin/perl -w /usr/bin/mrtg /var/lib/snpservices/data/mrtg.cfg --lock-file /var/lock/mrtg root 32301 0.0 1.6 25760 17024 ? S 18:55 0:00 /usr/bin/perl -w /usr/bin/mrtg /var/lib/snpservices/data/mrtg.cfg --lock-file /var/lock/mrtg root 32302 0.0 1.6 25760 17024 ? S 18:55 0:00 /usr/bin/perl -w /usr/bin/mrtg /var/lib/snpservices/data/mrtg.cfg --lock-file /var/lock/mrtg root 32303 0.0 1.6 25760 17024 ? S 18:55 0:00 /usr/bin/perl -w /usr/bin/mrtg /var/lib/snpservices/data/mrtg.cfg --lock-file /var/lock/mrtg root 32304 3.0 1.6 25760 17096 ? S 18:55 0:00 /usr/bin/perl -w /usr/bin/mrtg /var/lib/snpservices/data/mrtg.cfg --lock-file /var/lock/mrtg root 32331 0.0 0.1 2620 1056 ? S 18:55 0:00 /bin/sh /usr/share/snpservices/common/ping.sh 10.228.135.49 root 32332 0.0 0.0 1772 556 ? S 18:55 0:00 /bin/ping -c5 -i 0.2 10.228.135.49 -q root 32450 0.0 0.1 2620 1056 ? S 18:55 0:00 /bin/sh /usr/share/snpservices/common/ping.sh 10.228.166.7 root 32454 0.0 0.0 1772 556 ? S 18:55 0:00 /bin/ping -c5 -i 0.2 10.228.166.7 -q ===== Habilitar SNMP en nuestro dispositivo ===== Dependiendo del tipo de dispositivo que queramos monitorizar activaremos el demonio SNMP de la manera que nos proporcione el sistema operativo. Por ejemplo, para un router Mikrotik, tenemos la siguiente utilidad: [admin@Castalia] /snmp> print enabled: yes contact: david.rubert@gmail.com location: Castalia engine-id: trap-target: 0.0.0.0 trap-community: public trap-version: 1 ===== Consulta del estado del servicio SNMP ===== Para comprobar el correcto funcionamiento del SNMP en aquellos routers que queramos monitorizar tenemos la herramienta **snmpwalk**. Con dicha herramienta, podemos lanzar una consulta puntual SNMP de diferentes valores del router, asegurándonos así que nuestro servidor de gráficas puede monitorizarlo. Por ejemplo: snmpwalk -c public -v1 10.228.144.161 Este comando nos muestra muchísima información relativa a nuestro nodo en un momento del tiempo determinado. Si un proceso se encarga de consultar esa información a intervalos regulares, podría conseguir el muestreo necesario para generar un histórico de información. Esto es lo que hace mrtg por nosotros. ** Ejercicio 6.6 ** Vamos a acceder a la red de guifi.net Castellón. Para ello, añadid la siguiente ruta a vuestra máquina: # ip route add 10.0.0.0/8 via 150.128.49.223 Utiliza snmpwalk para consultar si funciona SNMP en el mikrotik UJI (10.228.130.1) y en el supernodo de Albocàsser (10.228.251.33). ===== Resolución de problemas típicos ===== Una vez tenemos nuestro servidor de gráficas funcionando, es posible que nos encontremos con casos en que las gráficas funcionan para unos supernodos pero que no funcionen bien para otros (gráficas vacías). Esto es debido a que las consultas que realiza MRTG sobre los dispositivos depende totalmente de cómo se ha dado de alta el router en la web de guifi.net. Por ejemplo, si damos de alta un router del tipo DD-WRT, entonces MRTG irá a consultarle por el interfaz "vlan1", mientras que si damos de alta un router mikrotik con tarjetas inalámbricas, irá a consultarle por los interfaces "wlan1", "wlan2", etc. ====== DNS. Dnsmasq y Powerdns ====== * http://es.wikipedia.org/wiki/Dns * http://www.thekelleys.org.uk/dnsmasq/doc.html * http://www.powerdns.com/ El DNS es uno de los servicios fundamentales en Internet, que pese a su simpleza conceptual mantiene una complejidad técnica de montaje importante, que se acrecenta más todavía cuando queremos utilizarlo sobre guifi.net. El concepto del DNS es, como hemos comentado, muy simple. Se encarga de traducir los nombres de internet a direcciones IP, o las direcciones IP en nombres de Internet. Esta funcionalidad es requerida por casi cualquier aplicación de hoy en día. ===== Arquitectura DNS ===== La arquitectura que se define en el DNS es jerárquica y distribuida. Dado que sería imposible mantener una base de datos con todos los dominios y sus zonas centralizadas en una única máquina a nivel mundial, se van delegando las zonas a diferentes servidores DNS autorizados, en función del nivel jerárquico en el que nos encontremos. Veámoslo en un ejemplo: {{:public:guifinet:cursoinstaladoresguifi2011:servidoresgnulinux:dns1.png|}} Además de esto, el propio RFC del DNS define un sistema de caché que implementan todos los servidores principales, donde se define un tiempo de vida máximo para cada registro consultado, de manera que si un servidor realiza una consulta remota, la guarda durante el tiempo máximo que le indica el servidor autorizado para esa zona. Los dominios de primer nivel (TLDs) los gestiona la ICANN, así como los servidores raiz. Además, determina las empresas registradoras a las que se les permite gestionar las compras de los dominios de segundo nivel hechas por cualquiera de nosotros (Godaddy.com, nic.es). El servicio de DNS funciona en el puerto 53 y el protocolo que utiliza para las consultas es el UDP. ===== Tipos de servidores DNS ===== Por tanto, podemos definir 4 o 5 comportamientos totalmente independientes en un servidor DNS: * **DNS forwarder**. Es el tipo de servidor DNS más simple. Únicamente redirige las peticiones hacia otro servidor DNS más completo. * **DNS recursor**. Servidor recursivo. Es un servidor DNS que acepta consultas de clientes sobre todo tipo de registros (p.e. www.google.es). Si no tiene la información, irá a preguntarla a la infraestructura DNS, y posteriormente cacheará el registro el tiempo autorizado para tener la respuesta preparada ante las siguientes consultas. * **Cache DNS**. Utilizado en conjunto con el servidor recursivo. Almacena todas las consultas de los clientes para tener la respuesta preparada para posteriores solicitudes de resolución. * **Primary DNS**. Servidor maestro de su zona. Es un servidor DNS que tiene la autoridad para decidir a qué IP's resuelve cada uno de los registros de su zona. Puede gestionar una o múltiples zonas. * **Secondary DNS**. Es un servidor que replica la zona de un servidor primario. Se encarga de tener actualizada la zona principal con los últimos cambios que se han producido. ==== Ejemplo teórico de petición de cliente DNS ==== Cuando un cliente Windows/Linux pregunta a su servidor DNS cuál es la IP de www.rediris.es, se desencadena un proceso similar al siguiente: * El DNS que tiene configurado el cliente mira en su caché a ver si tiene el registro y todavía no ha explirado, si lo tiene, responde de inmediato. * Si no tiene el registro, se va a preguntar a los servidores ROOT-DNS quién gestiona la zona de primer nivel .es. * El root DNS responde con la IP del servidor que gestiona esos datos, y nuestro DNS va a preguntarle al nuevo servidor por rediris.es. * El servidor DNS de primer nivel (.es) responde con la IP del servidor DNS de segundo nivel que gestiona el dominio rediris.es. * Este servidor DNS del dominio de segundo nivel (rediris.es) es el maestro de la zona, así que podrá responder con el registro que solicita nuestro DNS, que a su vez responde a su cliente y cachea el registro para posteriores ocasiones. {{:public:guifinet:cursoinstaladoresguifi2011:servidoresgnulinux:dns2.png|}} ===== Implementaciones: DNSMasq ===== DNSMasq es un servidor DNS (y DHCP) muy simple en su concepto. Es un DNS forwarder (no es DNS por sí mismo sino que depende de otros) y es que con una configuración mínima nos va a permitir tener operativo un servidor DNS capaz de resolver cualquier consulta de resolución de nombres. ==== Instalación y configuración ==== Veamos cómo instalarlo para una distribución Debian/Ubuntu, no tiene ningún misterio: # apt-get install dnsmasq # /etc/init.d/dnsmasq restart El servidor de nombres al que irá a preguntar será el que tengamos definido en el archivo /etc/resolv.conf, por ejemplo: nameserver 10.228.130.162 Podemos parametrizar diferentes aspectos del funcionamiento de dnsmasq a través del archivo de configuración /etc/dnsmasq.conf. Os dejo que le echéis un vistazo si queréis cambiar algún funcionamiento en concreto. El servidor DNS que lleva Mikrotik integrado es muy parecido a DNSMasq. Lo configuramos así: [admin@Castalia] > /ip dns print servers: 10.228.144.163 allow-remote-requests: yes max-udp-packet-size: 512 cache-size: 2048KiB cache-max-ttl: 1w cache-used: 17KiB ===== Implementaciones: BIND ===== Servidor DNS más utilizado de Internet, desarrollado actualmente por el ISC. Lleva mucho tiempo en liza y es una apuesta segura, pero tiene una serie de desventajas: * Complejo de configurar para soluciones sencillas. * Almacenamiento de las zonas en archivos de texto. * Desarrollado como un sistema arcaico, poco flexible. BIND puede actuar como servidor DNS del tipo que queramos: recursivo, cache, primario, secundario. Pero para configurarlo en cualquiera de estas modalidades deberemos dedicar mucho tiempo en entender cómo funciona. ===== Implementaciones: PowerDNS ===== PowerDNS es una implementación más moderna que Bind de un servidor DNS, con las siguientes características: * Tiene una implementación independiente de un servidor recursivo (pdns-recursor). * Soporta múltiples backends (mysql, oracle, texto, BerkeleyDB, geo, ldap, odbc, etc.) ==== Instalacion: pdns-recursor ==== Al instalar pdns-recursor estamos instalando un servidor 100% completo, capaz de resolver por sí mismo cualquier consulta y haciendo caché de los resultados. Para instalarlo en Debian/Ubuntu, tenemos un paquete ya a medida en la distribución estándar: # apt-get install pdns-recursor A partir de ese momento ya podemos hacer todo tipo de consultas a nuestro servidor: $ host www.google.es localhost www.google.es is an alias for www.google.com. www.google.com is an alias for www.l.google.com. www.l.google.com has address 74.125.39.104 www.l.google.com has address 74.125.39.103 www.l.google.com has address 74.125.39.147 www.l.google.com has address 74.125.39.99 www.l.google.com has address 74.125.39.106 www.l.google.com has address 74.125.39.105 ==== Instalacion: PowerDNS Full ==== PowerDNS tiene un archivo de configuración extenso pero bastante comprensible, donde seleccionaremos entre otras cosas, el backend donde guardaremos la información de las zonas, si vamos a actuar como DNS recursivo, si vamos a actuar como DNS forwarder, en qué interfaz escucharemos, en qué puerto, etc. La información de la zona podemos almacenarla, por ejemplo, en una base de datos mysql con la siguiente estructura de tablas como ejemplo: {{:public:guifinet:cursoinstaladoresguifi2011:servidoresgnulinux:pdns01.png?700}} {{:public:guifinet:cursoinstaladoresguifi2011:servidoresgnulinux:pdns02.png?700}} {{:public:guifinet:cursoinstaladoresguifi2011:servidoresgnulinux:pdns03.png?700}} ===== Herramientas y ejemplos de DNS ===== Tenemos a nuestra disposición varias herramientas para diagnosticar el correcto funcionamiento de un DNS en la red. Recordemos que el DNS funciona con tráfico UDP por el puerto 53, y que una petición de resolución puede d ==== HOST & DIG ==== Host y Dig son las herramientas de diagnóstico DNS que sustituyen al clásico "nslookup" para consultar registros DNS en un servidor. "Dig" es para realizar consultas más completas y "host" para consultas simples. Sintaxis de uso: $ dig @server hostname type # server: dirección IP del servidor al que queremos consultar # hostname: registro que queremos consultar # type: tipo de registro que queremos consultar (A, CNAME, NS) $ host -t type hostname server # server: dirección IP del servidor al que queremos consultar # hostname: registro que queremos consultar # type: tipo de registro que queremos consultar (A, CNAME, NS) Veamos un ejemplo: malva-serv:/home/dave# dig www.guifi.net ; <<>> DiG 9.7.3 <<>> www.guifi.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28078 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;www.guifi.net. IN A ;; ANSWER SECTION: www.guifi.net. 2746 IN CNAME guifi.net. guifi.net. 944 IN A 109.69.8.5 ;; AUTHORITY SECTION: guifi.net. 944 IN NS ns1.guifi.net. guifi.net. 944 IN NS ns2.guifi.net. ;; ADDITIONAL SECTION: ns1.guifi.net. 2746 IN A 109.69.8.6 ns2.guifi.net. 2746 IN A 87.216.179.57 ;; Query time: 4 msec ;; SERVER: 10.228.130.162#53(10.228.130.162) ;; WHEN: Wed Jul 6 22:14:17 2011 ;; MSG SIZE rcvd: 129 Veamos ahora los ejemplos con host: dave@casa:~$ host castello.guifi.net castello.guifi.net has address 150.128.97.38 dave@casa:~$ host -t NS guifi.net 150.128.98.10 guifi.net name server ns1.guifi.net. guifi.net name server ns2.guifi.net. ==== DNSTRACER ==== Utilizando la herramienta **dnstracer** podemos obtener un resultado visual y real de lo que acabamos de contar. dave@haddock:~$ dnstracer -c -4 -s "." www.rediris.es Tracing to www.rediris.es[a] via A.ROOT-SERVERS.NET, maximum of 3 retries A.ROOT-SERVERS.NET [.] (198.41.0.4) |\___ ns15.communitydns.net [es] (194.0.1.15) Got authoritative answer |\___ ns1.cesca.es [es] (84.88.0.3) | |\___ chico.rediris.es [rediris.es] (130.206.1.3) Got authoritative answer | |\___ sun.rediris.es [rediris.es] (130.206.1.2) Got authoritative answer | |\___ ns02.fccn.pt [rediris.es] (193.136.2.228) Got authoritative answer | |\___ ns15.communitydns.net [rediris.es] (194.0.1.15) Got authoritative answer | \___ scsnms.switch.ch [rediris.es] (130.59.1.30) Got authoritative answer | \___ scsnms.switch.ch [rediris.es] (130.59.10.30) Got authoritative answer |\___ f.nic.es [es] (130.206.1.2) Got authoritative answer |\___ a.nic.es [es] (194.69.254.1) | |\___ ns15.communitydns.net [rediris.es] (194.0.1.15) Got authoritative answer | |\___ ns02.fccn.pt [rediris.es] (193.136.2.228) Got authoritative answer | |\___ scsnms.switch.ch [rediris.es] (130.59.1.30) Got authoritative answer | |\___ scsnms.switch.ch [rediris.es] (130.59.10.30) Got authoritative answer | |\___ chico.rediris.es [rediris.es] (130.206.1.3) Got authoritative answer | \___ sun.rediris.es [rediris.es] (130.206.1.2) Got authoritative answer |\___ ns-ext.nic.cl [es] (200.1.123.14) | |\___ ns15.communitydns.net [rediris.es] (194.0.1.15) Got authoritative answer | |\___ chico.rediris.es [rediris.es] (130.206.1.3) Got authoritative answer | |\___ sun.rediris.es [rediris.es] (130.206.1.2) Got authoritative answer | |\___ scsnms.switch.ch [rediris.es] (130.59.1.30) Got authoritative answer | |\___ scsnms.switch.ch [rediris.es] (130.59.10.30) Got authoritative answer | \___ ns02.fccn.pt [rediris.es] (193.136.2.228) Got authoritative answer |\___ sns-pb.isc.org [es] (192.5.4.1) | |\___ scsnms.switch.ch [rediris.es] (130.59.1.30) Got authoritative answer | |\___ scsnms.switch.ch [rediris.es] (130.59.10.30) Got authoritative answer | |\___ ns02.fccn.pt [rediris.es] (193.136.2.228) Got authoritative answer | |\___ ns15.communitydns.net [rediris.es] (194.0.1.15) Got authoritative answer | |\___ chico.rediris.es [rediris.es] (130.206.1.3) Got authoritative answer | \___ sun.rediris.es [rediris.es] (130.206.1.2) Got authoritative answer \___ ns3.nic.fr [es] (192.134.0.49) |\___ ns15.communitydns.net [rediris.es] (194.0.1.15) Got authoritative answer |\___ sun.rediris.es [rediris.es] (130.206.1.2) Got authoritative answer |\___ ns02.fccn.pt [rediris.es] (193.136.2.228) Got authoritative answer |\___ scsnms.switch.ch [rediris.es] (130.59.1.30) Got authoritative answer |\___ scsnms.switch.ch [rediris.es] (130.59.10.30) Got authoritative answer \___ chico.rediris.es [rediris.es] (130.206.1.3) Got authoritative answer [...] ==== Ejemplo de integración con la web ==== Desde la propia web de castello.guifi.net, tenemos una integración de drupal con PowerDNS, de manera que cualquier usuario registrado puede añadir un registro de dns dentro del subdominio .castello.guifi.net. Gracias a PowerDNS la operación es tan sencilla como añadir un nuevo registro a la base de datos MySQL. {{:public:guifinet:cursoinstaladoresguifi2011:servidoresgnulinux:dns03.png?700}} Podéis probarlo vosotros/as mismos/as: * http://castello.guifi.net/content/gestiona-tus-propios-registros-dns-de-castelloguifinet