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)

• GNU/Linux en Wikipedia
• Uso de Linux en los grandes servidores. (linux 80% de cuota total).
• 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.

• 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.

• Debian. Distribución por excelencia para servidores.
• Ubuntu (Server edition).
• Fedora.
• Arch Linux.
• Gentoo.
• Optware + OpenWRT.

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)
	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)
	Consumo: 25W
	RAM: 256MB
	CPU: 400Mhz
	USB, Ethernet
	Bajo precio, bajo consumo, rendimiento adecuado

http://nas-4220.org

Synology 411	Características (Aproximadas)
	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)
	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

• 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.

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.

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 

Login:

Página principal:

Configuración de Webmin:

Configuración del proxy Squid:

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.

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

• 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.

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.

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: config. Veamos algunas de las opciones más importantes con las que nos encontraremos.

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

# 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

acl ip_acl src 192.168.1.0/24
http_access allow ip_acl
http_access deny all

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.

• 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.

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 %<st %rm %ru %un %Sh/%<A %mt

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 /var/log/squid/access.log squid

Define la localización del archivo de log principal de squid, donde se guardará información general sobre el funcionamiento del proxy.

cache_log /var/log/squid/cache.log

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://sarg.sourceforge.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 “Federación de proxies”. La idea consiste en dar de alta un proxy en la web de guifi.net, y permitir conectar a dicho proxy a aquellos usuarios de guifi.net que nosotros queramos. ¿Cómo hacerlo?

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/contraseña.
• Permitir únicamente a los usuarios que nosotros damos de alta conectar con su usuario/contraseña.

Siguiendo una serie de pasos en la configuración del Squid, y descargando periódicamente una base de datos de usuarios/contraseña que se han dado de alta en la web, podemos crear un sistema controlado de acceso a nuestro proxy, evitando la anonimidad de los accesos.

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 “usuarios”. Ahí pueden dar de alta un nuevo usuario, que será de la forma “nombre.apellidos”. El usuario pasará al estado “Pendiente de revisión”.
• 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/contraseña, ya pueden entrar a cualquier proxy federado de guifi.net.

Esta sería la configuración principal de un servidor Squid para hacerlo funcionar contra el archivo de usuarios/contraseñas de guifi.net.

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 /usr/libexec/ncsa_auth /etc/squid/guifinet_passwd
acl usuaris proxy_auth REQUIRED

# Blocked domains
acl blockeddomain dstdomain "/etc/squid/blocked.domains.acl"

# 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

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://www.guifi.net/es/node/$PROXY_ID/view/federated -qO $TMP
/bin/touch /etc/squid/guifinet_passwd
OK=`/bin/cat $TMP|wc -l`
NEW=`/usr/bin/diff /etc/squid/guifinet_passwd $TMP|wc -l`
if [ $OK != "0" ]; then
  if [ $NEW != "0" ]; then
    /bin/cp $TMP /etc/squid/guifinet_passwd
    /etc/init.d/squid reload
  fi;
fi;
rm -f $TMP

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.

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.

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.

http://150.128.49.223/squid-reports

• 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:

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.

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.

• 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.

• http://es.wikipedia.org/wiki/Php
• http://php.net/

PHP es el lenguaje de scripting orientado a la web más utilizado del mundo.

• 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.

• 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.

• 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.

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

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

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.

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”.

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.

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

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

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.

# ip route add 10.0.0.0/8 via 150.128.49.223

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.

• 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.

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:

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.

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.

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.

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.

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

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.

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.)

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

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:

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 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.

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 

[...]

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.

Podéis probarlo vosotros/as mismos/as:

• http://castello.guifi.net/content/gestiona-tus-propios-registros-dns-de-castelloguifinet