public:guifinet:cursoinstaladoresguifi2011:servidoresgnulinux:start
Diferencias
Muestra las diferencias entre dos versiones de la página.
Ambos lados, revisión anteriorRevisión previaPróxima revisión | Revisión previa | ||
public:guifinet:cursoinstaladoresguifi2011:servidoresgnulinux:start [2011/07/07 16:13] – boronat | public:guifinet:cursoinstaladoresguifi2011:servidoresgnulinux:start [2011/09/25 20:48] (actual) – drubert | ||
---|---|---|---|
Línea 1: | Línea 1: | ||
+ | ~~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:// | ||
+ | |||
+ | **Autores**: | ||
+ | |||
+ | * Pablo Boronat Pérez (Universitat Jaume I) | ||
+ | * Miguel Pérez Francisco (Universitat Jaume I) | ||
+ | * David Rubert Viana (Universitat Jaume I) | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ====== Introducción ====== | ||
+ | |||
+ | |||
+ | |||
+ | * [[http:// | ||
+ | * [[http:// | ||
+ | * [[http:// | ||
+ | |||
+ | 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, | ||
+ | |||
+ | |||
+ | ====Qué distribución utilizar==== | ||
+ | |||
+ | * [[http:// | ||
+ | |||
+ | 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), | ||
+ | |||
+ | 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:// | ||
+ | * [[http:// | ||
+ | * [[http:// | ||
+ | * [[http:// | ||
+ | * [[http:// | ||
+ | * [[http:// | ||
+ | |||
+ | |||
+ | ====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) | ||
+ | | {{: | ||
+ | | ::: | **RAM**: 128 o 256MB | | ||
+ | | ::: | **CPU**: 433 o 500Mhz | ||
+ | | ::: | USB, Ethernet, MiniPCI | ||
+ | | ::: | Bajo precio, bajo consumo, rendimiento moderado | | ||
+ | [[http:// | ||
+ | |||
+ | |||
+ | ^ RaidSonic ICY BOX 4220 ^ Características (Aproximadas) | ||
+ | | {{: | ||
+ | | ::: | **RAM**: 256MB | | ||
+ | | ::: | **CPU**: 400Mhz | ||
+ | | ::: | USB, Ethernet | ||
+ | | ::: | Bajo precio, bajo consumo, rendimiento adecuado | | ||
+ | [[http:// | ||
+ | |||
+ | |||
+ | ^ Synology 411 ^ Características (Aproximadas) | ||
+ | | {{: | ||
+ | | ::: | **RAM**: 1GB | | ||
+ | | ::: | **CPU**: 1,8Gz dual core | | ||
+ | | ::: | USB, Ethernet gigabit | ||
+ | | ::: | Alto precio, bajo consumo, alto rendimiento | | ||
+ | [[http:// | ||
+ | |||
+ | ^ QNAP 459 ^ Características (Aproximadas) | ||
+ | | {{: | ||
+ | | ::: | **RAM**: 1GB | | ||
+ | | ::: | **CPU**: Atom dual core | | ||
+ | | ::: | USB, Ethernet gigabit | ||
+ | | ::: | Alto precio, bajo consumo, alto rendimiento | | ||
+ | [[http:// | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ====== Webmin ====== | ||
+ | * http:// | ||
+ | * http:// | ||
+ | |||
+ | Webmin es una herramienta de apoyo a la administración/ | ||
+ | |||
+ | ===== 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, | ||
+ | |||
+ | port=10000 | ||
+ | allow=127.0.0.1 192.168.1.0/ | ||
+ | | ||
+ | |||
+ | |||
+ | La autenticación de usuarios de Webmin se realiza a través de un archivo de contraseñas, | ||
+ | |||
+ | | ||
+ | userfile=/ | ||
+ | | ||
+ | Podemos cambiar la contraseña o el usuario de administración de Webmin desde línea de comandos utilizando un script llamado **changepass.pl**. | ||
+ | | ||
+ | / | ||
+ | | ||
+ | | ||
+ | |||
+ | |||
+ | ==== Capturas de pantalla de Webmin ==== | ||
+ | |||
+ | **Login:** | ||
+ | |||
+ | {{: | ||
+ | |||
+ | **Página principal: | ||
+ | |||
+ | {{: | ||
+ | |||
+ | **Configuración de Webmin:** | ||
+ | |||
+ | {{: | ||
+ | |||
+ | **Configuración del proxy Squid:** | ||
+ | |||
+ | {{: | ||
+ | |||
+ | |||
+ | ===== 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. | ||
+ | |||
+ | {{: | ||
+ | {{: | ||
+ | |||
+ | |||
+ | ===== 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 " | ||
+ | |||
+ | http:// | ||
+ | |||
+ | |||
+ | Si no encontramos el servicio/ | ||
+ | |||
+ | http:// | ||
+ | |||
+ | |||
+ | < | ||
+ | |||
+ | Accede a Webmin en la IP: 150.128.49.223, | ||
+ | </ | ||
+ | |||
+ | ====== Proxy web Squid ====== | ||
+ | |||
+ | * [[http:// | ||
+ | * [[http:// | ||
+ | |||
+ | 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. | ||
+ | |||
+ | |||
+ | {{: | ||
+ | |||
+ | ===== 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. | ||
+ | |||
+ | |||
+ | {{: | ||
+ | |||
+ | |||
+ | 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: | ||
+ | |||
+ | 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: | ||
+ | |||
+ | ====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: | ||
+ | |||
+ | ====Directorio de caché de archivos==== | ||
+ | |||
+ | # ufs: Formato de almacenamiento de caché | ||
+ | # / | ||
+ | # 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 / | ||
+ | |||
+ | ==== Limitando el acceso al proxy a una subred específica ==== | ||
+ | |||
+ | |||
+ | acl ip_acl src 192.168.1.0/ | ||
+ | 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, | ||
+ | |||
+ | 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 | ||
+ | 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, | ||
+ | |||
+ | ===== El log de squid ===== | ||
+ | * [[http:// | ||
+ | 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, | ||
+ | |||
+ | | ||
+ | logformat squid %ts.%03tu %6tr %>a %Ss/ | ||
+ | | ||
+ | |||
+ | ==== access_log ==== | ||
+ | Define dónde se ubica el archivo de log de accesos a Squid, donde se almacenarán los accesos de nuestros clientes al proxy. Toma como parámetro el archivo en nuestro sistema de ficheros, y el tipo de formato de log que queremos aplicarle. | ||
+ | |||
+ | | ||
+ | access_log / | ||
+ | | ||
+ | | ||
+ | ==== cache_log ==== | ||
+ | Define la localización del archivo de log principal de squid, donde se guardará información general sobre el funcionamiento del proxy. | ||
+ | |||
+ | | ||
+ | cache_log / | ||
+ | | ||
+ | |||
+ | ===== Utilidades de mantenimiento ===== | ||
+ | |||
+ | ==== Generador de estadísticas ==== | ||
+ | |||
+ | El log de Squid contiene mucha información interesante que puede ayudarnos a conocer mejor cuál es el uso del proxy que se hace día día por nuestros usuarios. **Sarg** es un programa que se encargará de parsear el log de squid y generar una serie de reports diarios, semanales, o mensuales. | ||
+ | |||
+ | * [[http:// | ||
+ | |||
+ | {{: | ||
+ | {{: | ||
+ | |||
+ | ===== Proxies en guifi.net ===== | ||
+ | |||
+ | Dentro de guifi.net, justamente cobra sentido un servidor proxy, donde los clientes que conectan a través de él no tienen conexión directa a internet, por lo que pueden utilizarlo como pasarela centralizada a Internet. Con una única conexión a Internet podemos dar acceso a mucha gente, teniendo un control absoluto de lo que se permite hacer. | ||
+ | |||
+ | Una de las implementaciones más exitosas dentro de la red guifi.net es la llamada " | ||
+ | |||
+ | Primero que nada, deberemos decidir a qué grupo de usuarios queremos permitir el acceso a Internet a través de nuestro proxy. Tenemos 2 opciones: | ||
+ | * Permitir a cualquier usuario que se ha dado de alta en guifi.net conectar a través de nuestro proxy con su usuario/ | ||
+ | * Permitir únicamente a los usuarios que nosotros damos de alta conectar con su usuario/ | ||
+ | |||
+ | Siguiendo una serie de pasos en la configuración del Squid, y descargando periódicamente una base de datos de usuarios/ | ||
+ | |||
+ | |||
+ | {{: | ||
+ | |||
+ | Los usuarios de los proxies federados pueden darse de alta ellos mismos en la web de guifi.net, siguiendo estos pasos: | ||
+ | |||
+ | * Primero que nada, deberán tener dado de alta un nodo con una antena cliente operativa. | ||
+ | * En la página de su nodo, hay una sección de " | ||
+ | * Alguien de guifi.net revisa constantemente esa lista de usuarios, y aprobará aquellos usuarios que están en la cola de pendientes. | ||
+ | * Con ese usuario/ | ||
+ | |||
+ | {{: | ||
+ | {{: | ||
+ | |||
+ | ==== Configuración principal de Squid para integrarse con los proxies federados ==== | ||
+ | Esta sería la configuración principal de un servidor **Squid** para hacerlo funcionar contra el archivo de usuarios/ | ||
+ | |||
+ | | ||
+ | acl SSL_ports port 443 | ||
+ | acl Safe_ports port 80 # http | ||
+ | acl Safe_ports port 443 # https | ||
+ | acl CONNECT method CONNECT | ||
+ | | ||
+ | # Autenticacio | ||
+ | auth_param basic program / | ||
+ | acl usuaris proxy_auth REQUIRED | ||
+ | | ||
+ | # Blocked domains | ||
+ | acl blockeddomain dstdomain "/ | ||
+ | | ||
+ | # Access priority | ||
+ | http_access deny CONNECT !SSL_ports | ||
+ | http_access deny !Safe_ports | ||
+ | http_access deny blockeddomain | ||
+ | http_access allow usuaris | ||
+ | http_access deny all | ||
+ | | ||
+ | | ||
+ | |||
+ | ==== Script de actualización de los usuarios de los proxies federados de guifi.net ==== | ||
+ | |||
+ | Si tenemos montado un proxy federado y queremos que la lista de autorizados se actualice en función de la información que se va generando en la web, deberemos utilizar un script que obtenga la lista de usuarios autorizados en nuestro proxy, la guarde, y reinicie squid. Este script es conveniente ejecutarlo a intervalos regulares de tiempo (por ejemplo, cada 30min.) en un cron. | ||
+ | |||
+ | | ||
+ | #!/bin/bash | ||
+ | | ||
+ | PROXY_ID=31803 | ||
+ | TMP=$(mktemp) | ||
+ | | ||
+ | /bin/wget --timeout=240 http:// | ||
+ | /bin/touch / | ||
+ | OK=`/ | ||
+ | NEW=`/ | ||
+ | if [ $OK != " | ||
+ | if [ $NEW != " | ||
+ | /bin/cp $TMP / | ||
+ | / | ||
+ | fi; | ||
+ | fi; | ||
+ | rm -f $TMP | ||
+ | | ||
+ | |||
+ | |||
+ | |||
+ | < | ||
+ | **Ejercicio 6.2** | ||
+ | |||
+ | Accede a la página de http:// | ||
+ | | ||
+ | ¿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. | ||
+ | |||
+ | {{: | ||
+ | |||
+ | ==== 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. | ||
+ | |||
+ | {{: | ||
+ | {{: | ||
+ | |||
+ | ==== Usuarios y autenticación básica ==== | ||
+ | Si queremos tener una base de datos de usuario/ | ||
+ | |||
+ | 1. Añadimos un " | ||
+ | |||
+ | 2. Añadiremos los usuarios en la nueva sección de " | ||
+ | |||
+ | 3. En el control de acceso, añadimos una nueva ACL del tipo " | ||
+ | |||
+ | 4. Le damos prioridad a esta ACL, de manera que si el usuario se autentica se le permita conectarse al proxy. | ||
+ | |||
+ | {{: | ||
+ | {{: | ||
+ | {{: | ||
+ | {{: | ||
+ | {{: | ||
+ | |||
+ | < | ||
+ | **Ejercicio 6.3 (presencial)** | ||
+ | |||
+ | 1. Configúrate el navegador para acceder a través de proxy, con estos datos: IP: 150.128.49.223, | ||
+ | 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:// | ||
+ | |||
+ | </ | ||
+ | |||
+ | ====== Servidor de gráficas ====== | ||
+ | * [[http:// | ||
+ | * https:// | ||
+ | |||
+ | 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: | ||
+ | |||
+ | |||
+ | {{: | ||
+ | |||
+ | 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/ | ||
+ | |||
+ | 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, | ||
+ | * 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, | ||
+ | * 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, | ||
+ | |||
+ | 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:// | ||
+ | * http:// | ||
+ | |||
+ | 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:// | ||
+ | * http:// | ||
+ | |||
+ | Apache es el servidor web de código abierto más utilizado del mundo. | ||
+ | |||
+ | ==== PHP ==== | ||
+ | * http:// | ||
+ | * http:// | ||
+ | |||
+ | PHP es el lenguaje de scripting orientado a la web más utilizado del mundo. | ||
+ | |||
+ | ==== RRDtool ==== | ||
+ | * http:// | ||
+ | * http:// | ||
+ | |||
+ | **Round Robin Database Tool**. Herramienta de registro y creación de gráficas para datos procesables en series temporales. | ||
+ | |||
+ | ==== MRTG ==== | ||
+ | * http:// | ||
+ | * http:// | ||
+ | |||
+ | 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 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, | ||
+ | |||
+ | 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/ | ||
+ | |||
+ | Repositorio GIT del desarrollo principal: | ||
+ | |||
+ | * [[https:// | ||
+ | |||
+ | Repositorio GIT del desarrollo del script de empaquetado .deb: | ||
+ | |||
+ | * [[https:// | ||
+ | |||
+ | Si no queremos complicarnos la vida, podemos añadir directamente un repositorio donde encontramos los binarios empaquetados directamente para Debian/ | ||
+ | |||
+ | # vi / | ||
+ | deb http:// | ||
+ | # apt-get update | ||
+ | # apt-get install snp-services | ||
+ | | ||
+ | En este artículo del wiki oficial de guifi.net nos lo explican: | ||
+ | * [[http:// | ||
+ | |||
+ | |||
+ | ===== 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 / | ||
+ | |||
+ | | ||
+ | Alias / | ||
+ | | ||
+ | |||
+ | Una vez hecho esto, ya tendremos operativa la URL necesaria para la publicación de gráficas, que tendrá esta pinta: | ||
+ | |||
+ | | ||
+ | http:// | ||
+ | | ||
+ | |||
+ | ===== Dar de alta el servicio de gráficas en guifi.net ===== | ||
+ | |||
+ | Antes de continuar con la instalación/ | ||
+ | |||
+ | 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. | ||
+ | |||
+ | {{: | ||
+ | |||
+ | Posteriormente, | ||
+ | |||
+ | {{: | ||
+ | |||
+ | < | ||
+ | ** Ejercicio 6.5 ** | ||
+ | Busca los servicios de "SNP Graph Server" | ||
+ | |||
+ | * http:// | ||
+ | |||
+ | * ¿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 / | ||
+ | $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 / | ||
+ | |||
+ | * 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 / | ||
+ | * 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:/ | ||
+ | USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND | ||
+ | root | ||
+ | root | ||
+ | ... | ||
+ | root | ||
+ | root | ||
+ | root | ||
+ | root | ||
+ | root | ||
+ | root | ||
+ | root | ||
+ | root | ||
+ | root | ||
+ | root | ||
+ | root | ||
+ | root | ||
+ | root | ||
+ | root | ||
+ | root | ||
+ | root | ||
+ | root | ||
+ | root | ||
+ | root | ||
+ | root | ||
+ | root | ||
+ | root | ||
+ | |||
+ | ===== 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 | ||
+ | | ||
+ | | ||
+ | location: Castalia | ||
+ | | ||
+ | | ||
+ | trap-community: | ||
+ | trap-version: | ||
+ | | ||
+ | |||
+ | ===== 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, | ||
+ | | ||
+ | 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, | ||
+ | |||
+ | Por ejemplo, si damos de alta un router del tipo DD-WRT, entonces MRTG irá a consultarle por el interfaz " | ||
+ | |||
+ | ====== DNS. Dnsmasq y Powerdns ====== | ||
+ | |||
+ | * http:// | ||
+ | * http:// | ||
+ | * http:// | ||
+ | |||
+ | |||
+ | 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, | ||
+ | |||
+ | {{: | ||
+ | |||
+ | |||
+ | Además de esto, el propio RFC del DNS define un sistema de caché que implementan todos los servidores principales, | ||
+ | |||
+ | 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, | ||
+ | |||
+ | 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, | ||
+ | * **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/ | ||
+ | |||
+ | * 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. | ||
+ | {{: | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ===== Implementaciones: | ||
+ | |||
+ | 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/ | ||
+ | |||
+ | | ||
+ | # apt-get install dnsmasq | ||
+ | # / | ||
+ | |||
+ | El servidor de nombres al que irá a preguntar será el que tengamos definido en el archivo / | ||
+ | |||
+ | | ||
+ | nameserver 10.228.130.162 | ||
+ | | ||
+ | Podemos parametrizar diferentes aspectos del funcionamiento de dnsmasq a través del archivo de configuración / | ||
+ | |||
+ | 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: | ||
+ | max-udp-packet-size: | ||
+ | | ||
+ | cache-max-ttl: | ||
+ | | ||
+ | | ||
+ | |||
+ | ===== Implementaciones: | ||
+ | |||
+ | 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 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: | ||
+ | |||
+ | 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/ | ||
+ | | ||
+ | # 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 tiene un archivo de configuración extenso pero bastante comprensible, | ||
+ | |||
+ | La información de la zona podemos almacenarla, | ||
+ | |||
+ | {{: | ||
+ | {{: | ||
+ | {{: | ||
+ | |||
+ | ===== 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 " | ||
+ | |||
+ | 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:/ | ||
+ | | ||
+ | ; <<>> | ||
+ | ;; global options: +cmd | ||
+ | ;; Got answer: | ||
+ | ;; ->> | ||
+ | ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2 | ||
+ | | ||
+ | ;; QUESTION SECTION: | ||
+ | ; | ||
+ | | ||
+ | ;; 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# | ||
+ | ;; WHEN: Wed Jul 6 22:14:17 2011 | ||
+ | ;; MSG SIZE rcvd: 129 | ||
+ | | ||
+ | | ||
+ | Veamos ahora los ejemplos con host: | ||
+ | | ||
+ | dave@casa: | ||
+ | castello.guifi.net has address 150.128.97.38 | ||
+ | | ||
+ | dave@casa: | ||
+ | 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: | ||
+ | Tracing to www.rediris.es[a] via A.ROOT-SERVERS.NET, | ||
+ | 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) | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |\___ f.nic.es [es] (130.206.1.2) Got authoritative answer | ||
+ | |\___ a.nic.es [es] (194.69.254.1) | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |\___ ns-ext.nic.cl [es] (200.1.123.14) | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |\___ sns-pb.isc.org [es] (192.5.4.1) | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | \___ 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, | ||
+ | |||
+ | {{: | ||
+ | |||
+ | Podéis probarlo vosotros/as mismos/as: | ||
+ | |||
+ | * http:// |