Hoy veremos lo sencillo que puede resultar compartir nuestros archivos con los hosts *ix de nuestra red.

Introducción

A muchos de nosotros no nos alcanza con una sola PC, y es probable que tengamos dos o más corriendo Linux dentro de la misma red. En más de una oportunidad, será necesario llevar archivos de una a otra. Para eso fue pensado el Network File System (NFS), gracias al cual podremos montar unidades compartidas por sistemas remotos, tal como lo haríamos con nuestras unidades locales. Si bien es cierto la implementación de un servicio con estas características supone una brecha en la seguridad del sistema, discutiremos al respecto más adelante.

Además de NFS existen otros sistemas para compartir archivos: el AFS de IBM, Samba -del que ya habláramos oportunamente- -, Coda File System, etc. Pero NFS se ha convertido en el sistema más popular, sencillo y maduro de todas las plataformas en las que tiene soporte.

Requisitos de Software

Voy a basar mi descripción en un sistema Red Hat típico, pero no deberían tener mayores inconveniente en ninguna otra distribución.

* Kernel: Para poner a funcionar NFS sobre nuestro sistema necesitaremos en primer lugar un kernel con soporte NFS. La mayoría de los kernels que se instalan la primera vez, al ser modulares incluirán el modulo NFS correspondiente y lo cargarán en memoria cuando haga falta. Si no es este el caso, podremos recompilarlo habilitando el soporte de sistema de archivos NFS, y si además queremos que nuestro host sea servidor NFS habilitaremos el soporte correspondiente en el kernel. Aquí cabe hacer algunas salvedades en cuanto a la versión de kernel que utilicen, y el tipo de servicio NFS que pretendan poner en funcionamiento, pero en general sobre núcleos 2.x o superiores, podremos cubrir las necesidades más comunes. Para más detalles, refiéranse a la documentación de NFS.
* Aplicaciones: También necesitaremos instalar portmap, y nfs-utils, que contiene todo lo necesario para poner en funcionamiento y administrar el sistema de archivos compartidos. Estos paquetes casi siempre estan incluido en el CD de nuestra distro, pero en caso de no tenerlos a mano pueden bajase de nfs.sourceforge.net, donde además encontraremos los fuentes, parches para el kernel, otros paquetes relacionados a NFS y toda la documentación necesaria.

Configuración

Desde ya, vamos a suponer que todo este tiempo hemos hablado de un sistema Linux corriendo correctamente, con hardware de red convenientemente configurado, y con soporte TCP/IP. Vamos a suponer también que la caja Linux en cuestión va a comportarse como servidor y cliente. Para empezar será necesario agregar una entrada por cada recurso que queramos compartir en el archivo /etc/exports de la forma:

/compartido
192.168.0.0/255.255.255.0(no_root_squash)
/pub
esclava1.net(ro,insecure,all_squash)
esclava2(rw,insecure,all_squash)

y más generalmente:

/directorio
maquina1(opción1-1,opción1-2)
maquina2(opción2-1,opción2-2)

Donde: directorio es el recurso a compartir, y todos los subdirectorios que pendan de aquel también serán compartidos; máquinax es cada uno de los clientes a los que se garantiza acceso al recurso con las opciones de seguridad que se indican al lado. Estas máquinas pueden identificarse indistintamente por su nombre o por su IP, pero hacerlo de la segunda forma es más confiable. Finalmente las opciones podrán ser -entre otras-- ro para sólo lectura, rw para lecto-escritura, no_root_squash para garantizar al root remoto los mismos privilegios que root local.

Hecho esto y reiniciando al servidor NFS con la orden:

/etc/rc.d/init.d/nfs restart

ya deberíamos tener nuestro servidor NFS, dispuesto a compartir los directorios que le indicáramos. Para tener una idea respecto al estado del servidor, podemos intentar: rpcinfo -p

A la vuelta de este comando, tendremos en pantalla, la información sobre los servicios que estén corriendo en ese momento (ver captura). Deberán figurar al menos portmapper, nfs, mountd, quizás rpc.statd, nlockmgr, y dependiendo de la versión de NFS, unos más o menos. Por supuesto que ante cada cambio que se realice al archivo exports, habrá que reiniciar el servicio, como se indicó más arriba, o bien con:

exportfs -ra

Este comando, sin parámetros, muestra los recursos que están siendo compartidos en un momento dado, y es el que sincroniza la información de /etc/exports, con la requerida por mountd, y que se ubica en /var/lib/nfs.

Ahora charlaremos sobre los demonios que deberían estar corriendo. Teniendo nuestro kernel con soporte, será obligación tener corriendo los servicios de portmap, (hay un script con ese nombre en /etc/rc.d/init.d, o sino puede correrse el binario directamente en /sbin/portmap), rpc.nfsd, rpc.mountd, y eventualmete rpc.quotad, rpc.lockd y rpc.statd, que pueden hallarse normalmente en /usr/sbin o /sbin. Nótese que en la mayoría de los casos, todos los servicios se arrancan automáticamente en los scripts de inicio de /etc/rc.d/init.d, por lo que será suficiente con marcarlos en la sección System Services de setup, en caso de que contemos con él.

Si todo está corriendo hasta aquí, los clientes ya estarán en condiciones de acceder a nuestros directorios compartidos, así que podremos pasar al uso de nuestra PC como cliente NFS. Para acceder a los recursos que comparte algún servidor NFS de la red, debemos tener corriendo portmapper, y si nos interesa el servicio de traba de archivos, lockd y statd. Luego, podemos montar los discos remotos con el mismo comando de los sistemas locales: mount.

# mount 192.168.0.2:/compartido /mnt/nfs/compartido

Luego, para desmontar el recurso, se usará umount.

# umount /mnt/nfs/compartido

Por último, también podremos agregar entradas de tipo nfs a nuestro archivo /etc/fstab, para montar sistemas remotos de disco, al arrancar la sesión. Aquí agregaremos el directorio que compartimos más arriba, en el archivo fstab de la esclava, para que se monte al encenderla:

#archivo: /etc/fstab
#recurso:
192.168.0.2:/compartido /mnt/nfs/compartido nfs rw 0 0< P CLASS=normal>La seguridad con NFS

El sistema más seguro de todos, es el apagado. Le siguen el aislado, y la red mantenida con paranoia o entre amigos, sin conexión alguna al exterior. De cualquier modo, veremos las medidas más simples para evitar que alguien abuse de nuestro servidor NFS recién instalado.

NFS necesita el servicio portmap para correr. Y las cosas funcionan mas o menos asi:

Cliente: Hola servidor! Soy 10.10.1.1, está portmapper en tu puerto 111?
-Servidor (por inetd): espere...
[el servidor busca la IP en /etc/hosts.deny, y luego en /etc/hosts..allow]
-Servidor(luego de verificar): Si, ya le paso...
-Servidor(atiende portmapper): Hola, quien seas: Tenemos en 2049/udp: nfs, en 1127/udp y 1694/tcp nuestro nlockmgr, en.... [la lista sigue]

Siendo asi de simple el diálogo, habrá que restringir el acceso a nuestro portmapper y a nuestro NFS, contra el mundo exterior, y garantizarlo solamente para nuestras compañeras de red. Comenzaremos modificando los archivos /etc/hosts.deny y /etc/hosts.allow. En ellos, se indica qué servicios se niegan, y se permiten a quién, respectivamente. Con estos dos archivos, podemos comenzar a definir cláusulas de prestación de servicios, que nos darán algo de tranquilidad. Un ejemplo de estos dos archivos podría ser:

#en /etc/hosts.deny
# declaramos que nadie puede usar nuestro portmap
portmap: ALL
#luego, en /etc/hosts.allow
#diremos quienes sí pueden hacerlo:
portmap: 192.168.0.0/255.255.255.0
#en el ejemplo, toda nuestra red local puede usar portmap, aunque tambien podria ser solo un host:
#portmap: 192.168.0.10/255.255.255.255

En cualquier caso, y no solamente para éste sino para cualquier otro servicio que deseemos asegurar, lo mejor será confiar en un firewall, y utilizar Ipchains o Iptables, según el kernel. Pero ese es un tema aparte, del que no hablaremos para no prolongar la nota, más allá de su interés.

Conclusión

Como habrán podido notar, el procedimiento de compartir archivos, es realmente muy sencillo, y combinado con buenas medidas de seguridad, puede utilizarse sin temor. Para quienes quieran completar NFS para volverlo más seguro o más versatil, a continuación refiero algunas aplicaciones que podrán resultarles de interés:

* JNFSD, un servidor NFS en Java para Linux, Solaris y Winx.
* Secure Export System, autenticacion de sesiones NFS mediante Kerberos.
* Sharity-Light y Sharity, para montar unidades compartidas por SMB, OS2, AppleShare u otros, pero a la NFS.

__________________

"El arte por el arte es lo único que dignifica al hombre artista"

Administración y Mantenimiento de Redes con Linux

Introducción

En el mundo actual, en el que la informática gira en torno al concepto de red, el trabajo de los administradores de sistemas es muy complejo. Su misión consiste en mantener en funcionamiento recursos tales como encaminadores (routers), concentradores (hubs), servidores, así como cada dispositivo crítico que conforma la red.

Hay gran cantidad de motivos por los cuales un administrador necesita monitorizar entre otros : la utilización del ancho de banda, el estado de funcionamiento de los enlaces, la detección de cuellos de botella, detectar y solventar problemas con el cableado, administrar la información de encaminamiento entre máquinas, etc. La monitorización de la red es también un buen punto desde el que comenzar el estudio de los problemas de seguridad.

En muchos casos, la red de una organización está enlazada mediante costosos enlaces a redes de área extensa (WAN) o con la Internet, y cuyos costes dependen del volumen de tráfico. Es muy importante mantener un registro estadístico del tráfico que circula por estos enlaces. Ésta situación es bastante común en Europa, donde los enlaces X.25 son todavía de uso corriente. La tarificación de este tipo de líneas se realiza en función del número de paquetes enviados y recibidos.

Otros tipos de enlaces, como los punto a punto (Frame relay), son de tarifa plana. En éstos la compañía telefónica ha de garantizar un ancho de banda, el cual es importante monitorizar.

LASS=normal>En la última parte de este artículo, se presenta una herramienta que permite hacer un seguimiento gráfico del tráfico en los encaminadores (router). Ésta es fácilmente configurable para poder monitorizar otras clases de información de la red.

¿ Qué es SNMP ?

La respuesta a todas las necesidades antes expuestas, es el protocolo llamado Simple Network Management Protocol (SNMP). Diseñado en los años 80, su principal objetivo fue el integrar la gestión de diferentes tipos de redes mediante un diseño sencillo y que produjera poca sobrecarga en la red.

SNMP opera en el nivel de aplicación, utilizando el protocolo de transporte TCP/IP, por lo que ignora los aspectos específicos del hardware sobre el que funciona. La gestión se lleva a cabo al nivel de IP, por lo que se pueden controlar dispositivos que estén conectados en cualquier red accesible desde la Internet, y no únicamente aquellos localizados en la propia red local. Evidentemente, si alguno de los dispositivos de encaminamiento con el dispositivo remoto a controlar no funciona correctamente, no será posible su monitorización ni reconfiguración.

El protocolo SNMP está compuesto por dos elementos: el agente (agent), y el gestor (manager). Es una arquitectura cliente-servidor, en la cual el agente desempeña el papel de servidor y el gestor hace el de cliente.

El agente es un programa que ha de ejecutase en cada nodo de red que se desea gestionar o monitorizar. Ofrece un interfaz de todos los elementos que se pueden configurar. Estos elementos se almacenan en unas estructuras de datos llamadas "Management Information Base" (MIB), se explicarán más adelante. Representa la parte del servidor, en la medida que tiene la información que se desea gestionar y espera comandos por parte del cliente.

El gestor es el software que se ejecuta en la estación encargada de monitorizar la red, y su tarea consiste en consultar los diferentes agentes que se encuentran en los nodos de la red los datos que estos han ido obteniendo.

Hay un comando especial en SNMP, llamado trap, que permite a un agente enviar datos que no han sido solicitados de forma explícita al gestor, para informar de eventos tales como: errores, fallos en la alimentación eléctrica, etc.

En esencia, el SNMP es un protocolo muy sencillo puesto que todas las operaciones se realizan bajo el paradigma de carga-y-almacenamiento (load-and-store), lo que permite un juego de comandos reducido. Un gestor puede realizar sólo dos tipos diferentes de operaciones sobre un agente: leer o escribir un valor de una variable en el MIB del agente. Estas dos operaciones se conocen como petición-de-lectura (get-request) y petición-de-escritura (set-request). Hay un comando para responder a una petición-de-lectura llamado respuesta-de-lectura (get-response), que es utilizado únicamente por el agente.

La posibilidad de ampliación del protocolo está directamente relacionado con la capacidad del MIB de almacenar nuevos elementos. Si un fabricante quiere añadir un nuevo comando a un dispositivo, como puede ser un encaminador, tan sólo tiene que añadir las variables correspondientes a su base de datos (MIB).

Casi todos los fabricantes implementan versiones agente de SNMP en sus dispositivos: encaminadores, hubs, sistemas operativos, etc. Linux no es una excepción, existen varios agentes SNMP disponibles públicamente en la Internet.

La cuestiónde la seguridad

SNMP ofrece muy poco soporte para la autentificación. Tan sólo ofrece el esquema de dos palabras clave (two-passwords). La clave pública permite a los gestores realizar peticiones de valores de variables, mientras que la clave privada permite realizar peticiones de escritura. A estas palabras clave se les llama en SNMP communities. Cada dispositivo conectado con una red gestionada con SNMP, ha de tener configuradas estas dos communities.

Es muy común tener asignando por defecto el valor "public" al community público, y "private" al privado. Por lo que es muy importante cambiar estos valores para proteger la seguridad de tu red.

¿ Quées el MIB ?

SNMP define un estándar separado para los datos gestionados por el protocolo. Este estándar define los datos mantenidos por un dispositivo de red, así como las operaciones que están permitidas. Los datos están estructurados en forma de árbol; en el que sólo hay un camino desde la raíz hasta cada variable. Esta estructura en árbol se llama Management Information Base (MIB) y se puede encontrar información sobre ella en varios RFC's.

La versión actual de TCP/IP MIB es la 2 (MIB-II) y se encuentra definida en el RFC-1213. En ella se divide la información que un dispositivo debe mantener en ocho categorías (ver Tabla 1). Cualquier variable ha de estar en una de estas categorías.

Tabla 1. Categorías TCP/IP Categoría Información
system Información del host del sistema de encaminamiento
interfaces Información de los interfaces de red
addr-translation Información de traducción de direcciones
ip Información sobre el protocolo IP
icmp Información sobre el protocolo ICMP
tcp Información sobre el protocolo TCP
udp Información sobre el protocolo UDP
egp Información sobre el protocolo (Exterior Gateway)

La definición de un elemento concreto MIB implica la especificación del tipo de dato que puede contener. Normalmente, los elementos de un MIB son enteros, pero también pueden almacenar cadenas de caracteres o estructuras más complejas como tablas. A los elementos de un MIB se les llama "objetos". Los objetos son los nodos hoja del árbol MIB, si bien, un objeto puede tener más de una instancia, como por ejemplo un objeto tabla. Para referirse al valor contenido en un objeto, se ha de añadir el número de la instancia. Cuando sólo exista una instancia del objeto, está es la instancia cero.

Por ejemplo, el objeto ifNumber de la categoría "interfaces" es un entero que representa el número de interfaces presentes en el dispositivo; mientras el objeto ipRoutingTable de la categoría "ip" contiene la tabla de encaminamiento del dispositivo.

Hay que acordarse de utilizar el número de la instancia para leer el valor de un objeto. En este caso, el número de interfaces presentes en un encaminador puede ser observado mediante la instancia ifNumber.0.

En el caso de ser un objeto tabla, se ha de utilizar el índice a la tabla como último número para especificar la instancia (fila de la tabla).

Existe otro estándar que define e identifica las variables MIB, llamado "Structure of Management Information" (SMI). SMI especifica las variables MIB, éstas se declaran empleando un lenguaje formal ISO llamado ASN.1, que hace que tanto la forma como los contenidos de estas variables sean no ambiguos.

El espacio de nombres ISO (árbol) está situado dentro de un espacio de nombres junto con otros árboles de otros estándares de otras organizaciones. Dentro del espacio de nombres ISO hay una rama específica para la información MIB. Dentro de esta rama MIB, los objetos están a su vez jerarquizados en subárboles para los distintos protocolos y aplicaciones, de forma que esta información puede representarse unívocamente.

La Figura 1 muestra el espacio de nombres del MIB del TCP/IP, éste está situado justo bajo el espacio del IAB "mgmt". La jerarquía también específica el número para cada nivel.


Figura 1. TCP/IP Organizational Tree Tree

Es importante constatar que la mayor parte del software necesita el punto raíz (.) para localizar el objeto en el MIB. Si no se incluye el punto raíz, se asume que el path es relativo desde .iso.org.dod.internet.mgmt.mib-2.

De esta forma, el objeto ifNumber de la categoría "interfaces" se puede llamar:

.iso.org.dod.internet.mgmt.mib-2.interfaces.ifnumber

o el equivalente numérico:

.1.3.6.1.2.1.2.1

y la instancia es:

.iso.org.dod.internet.mgmt.mib-2.interfaces.ifnumber.0

o el equivalente numérico:

.1.3.6.1.2.1.2.1.0

Adicionales MIB se pueden añadir a este árbol conforme los vendedores definen nuevos objetos y publican los correspondientes RFC.

__________________

"El arte por el arte es lo único que dignifica al hombre artista"

¿ Cuál es el futuro de SNMP ?

Una nueva especificación llamada SNMPv2 está actualmente en rápido desarrollo. Esta versión trata de solucionar la laguna existente en cuestiones de seguridad del protocolo actual mediante mecanismos que se centran en la privacidad, la autentificación y el control de acceso. También permitirá un complejo mecanismo de especificación de variables, así como algunos comandos nuevos. El problema del SNMPv2 es que aún no es un estándar ampliamente aceptado, a diferencia del SNMPv1. No es fácil encontrar versiones de SNMPv2 de agentes ni de software que haga uso de los nuevos comandos. Dejemos que pase el tiempo y ya veremos que sucede en el futuro próximo...

SNMP en Linux

Uno de los paquetes más populares de SNMP es el CMU-SNMP. Diseñado originalmente en la Universidad de Carnegie Mellon, ha sido transportado a Linux por Juergen Schoenwaelder y Erik Schoenfelder. Es completamente compatible con el estándar SNMPv1 e incluye algunas de las nuevas funcionalidades de SNMPv2.

La distribución contiene algunas herramientas de gestión que permiten, desde la línea de comandos, enviar peticiones a dispositivos que ejecuten agentes SNMP. También contiene un programa agente SNMP, diseñado para ejecutarse sobre Linux, que ofrece a gestores ejecutándose en la red (o en el propio sistema), información sobre el estado de los interfaces, tablas de encaminamiento, instante de inicio (uptime), información de contacto, etc.

Una valiosa característica añadida que viene con CMU-SNMP es un SNMP C-API, que permite a los programadores construir complejas herramientas de gestión basadas en las capacidades de red de la distribución.

La instalación en un sistema Linux es sencilla, si bien algo diferente de la instalación original. Existe una distribución con los ejecutables pre-compilados de las herramientas de gestión, el demonio y la biblioteca API.

Lo primero que se ha de hacer es decidir si "bajarse" la distribución con los fuentes, o la distribución con los ejecutables. No es difícil encontrar este paquete en la Internet. La distribución binaria se instala y ejecuta sin problema alguno en los Linux que soporten ELF. Si bien explicaremos cómo instalar la distribución binaria, es una buena práctica el bajarse las distribuciones binarias únicamente de servidores Internet de confianza para evitar caballos de Troya y otros problemas de seguridad.

Copia el fichero cmu-snmp-linux-3.4-bin.tar.gz en el directorio raíz (/). Descomprímelo y extrae los fichero del tar con con la siguiente orden:

tar zxvf cmu-snmp-linux-3.4-bin.tar.gz

Ahora tendrás todas las utilidades y bibliotecas correctamente instaladas en el sistema, a excepción del fichero de configuración del agente: /etc/snmpd.conf. Lo puedes crear ejecutando el siguiente "script":

/tmp/cmu-snmp-linux-3.4/etc/installconf

con los siguientes parámetros:

/tmp/cmu-snmp-linux-3.4/etc/installconf -mini password

donde password es la palabra clave pública (community) que se vaya a utilizar. Ahora se puede editar el nuevo fichero de configuración /etc/snmpd.conf. En él, se pueden cambiar el valor de puerto UDP empleado por el agente, las variables systemContact, sysLocation y sysName, así como los parámetros de velocidad del interface para las tarjetas de red y los puertos PPP.

Las herramientas más importantes de gestión de este paquete son:

* /usr/bin/snmpget Un programa diseñado para consultar un valor concreto a un agente MIB de la red (una encaminador, un hub, etc).
* /usr/bin/snmpgetnext Permite leer el siguiente objeto de un árbol MIB sin necesidad de conocer el nombre.
* /usr/bin/snmpset Una herramienta para escribir valores en los objetos de agentes remotos.
* /usr/bin/snmpwalk Herramienta que lee un objeto completo o una serie de objetos sin necesidad de especificar la instancia exacta. Es útil para pedir objetos tipo tabla.
* /usr/bin/snmpnetstat
* /usr/bin/snmptrapd Demonio que escucha los "traps"de los agentes.
* /usr/bin/snmptest Herramienta interactiva diseñada para demostrar las posibilidades del API.

El agente se encuentra en el directorio /usr/sbin/snmpd.

CMU_SNMP también instala un fichero MIB en /usr/lib/mib.txt. Éste es un buen lugar en donde buscar qué tipo de información se le puede pedir a un dispositivo de red.

El agente se tiene que lanzar a ejecución cuando se pone en marcha la máquina. Ésto se puede hacer añadiendo el siguiente comando en alguno de los ficheros de arranque (por ejemplo en /etc/rc.f/rc.local):

/usr/sbin/snmpd -f ; echo 'Arrancando snmpd'

Una vez se tiene el agente SNMP en ejecución en la máquina Linux, se puede comprobar su funcionamiento con alguna de las herramientas de gestión, por ejemplo:

/usr/bin/snmpget localhost public interfaces.ifNumber.0

la cual retornará el número de interfaces configurados en el sistema, y:

/usr/bin/snmpwalk localhost public system

devuelve todos los valores en el subárbol "system" del MIB. (Véase en la Figura 2 el resultado de esta orden).
Figura 2 dragon:~$ /usr/bin/snmpwalk

usage: snmpwalk gateway-name community-name object-identifier

dragon:~$ /usr/bin/snmpwalk localhost public system

system.sysDescr.0 = "Linux version 2.0.24 (root@dragon)
(gcc version 2.7.2) #6 Mon Nov 25 15:08:40 MET 1996"
system.sysObjectID.0 = OID: enterprises.tubs.ibr.linuxMIB
system.sysUpTime.0 = Timeticks: (39748002) 4 days, 14:24:40
system.sysContact.0 = "David Guerrero"
system.sysName.0 = "dragon "
system.sysLocation.0 = "Madrid (SPAIN)"
system.sysServices.0 = 72
system.sysORLastChange.0 = Timeticks: (39748006) 4 days, 14:24:40
system.sysORTable.sysOREntry.sysORID.1 = OID: enterprises.tubs.ibr.linuxMIB.linuxAgents.1
system.sysORTable.sysOREntry.sysORDescr.1 = "LINUX agent"
system.sysORTable.sysOREntry.sysORUpTime.1 = Timeticks: (39748007) 4 days, 14:24:40

dragon:~$

El C-API está en el directorio /lib/libsnmp.so.3.4.

Se pueden ojear los ficheros de cabecera relacionados con la biblioteca en :

* /usr/include/snmp/snmp.h
* /usr/include/snmp/snmp_impl.h
* /usr/include/snmp/asn1.h
* /usr/include/snmp/snmp_api.h

Se puede encontrar más información en las páginas del manual snmp_api(3) y varibles(5).

Existe también un módulo Perl de interface con CMU C_API con el que se pueden realizar fácilmente llamadas a esta biblioteca desde programas Perl (Perl-scripts).

__________________

"El arte por el arte es lo único que dignifica al hombre artista"

MRTG: Multi Router Traffic Grapher

MRTG es una avanzada utilidad gráfica escrita por Tobias Oetiker y Dave Rand para representar gráficamente los datos que los gestores SNMP leen de los agentes SNMP. Produce unas vistosas págimas HTML con gráficos GIF sobre el tráfico entrante y saliente en los interfaces de red prácticamente tiempo real. Con esta herramienta se evita el tener que trabajar directamente con las utilidades CMU-SNMP mediante línea de comandos. Ésta es la herramienta más potente y fácil de utilizar que he encontrado en la Internet.

MRTG utiliza una implemantación de SNMP escrita completamente en Perl, por tanto, no es necesario instalar otros paquetes. El programa principal está escrito en "C" para acelerar el proceso de toma de muestras y la generación de imágenes GIF. Los gráficos son generados con la ayuda de la biblioteca GD escrita por Thomas Boutell, autor de la FAQ WWW.

El paquete contiene algunas utilidades para analizar los interfaces de enlace, extraer sus características y generar los ficheros de configuración base, que luego se pueden modificar para adaptarlos a las necesidades concretas.

Otra característica interesante del MRTG es la cantidad de información que produce. Permite cuatro niveles de detalle para cada interface: tráfico en las últimas 24 horas, la última semana, el último mes y un gráfico anual. Ésto permite recoger información para realizar estadísticas. Guarda toda esta información en una base de datos utilizando un algoritmo de consolidación que impide que los ficheros crezcan de forma desmesurada.

También genera una página principal que contiene las imágenes GIF de los detalles diarios de cada interface del encaminador, lo que permite hacerse una idea general de qué es lo que está pasando en el encaminador con un sólo vistazo. Se puede ver la página principal generada por MRTG en las Figuras 3 y 4.


Figura 3. Interfaz de la página principal


Figura 4. Interfaz de la página detallada del interface

Veamos el procedimiento básico de instalación. Lo primero que se necesita es la distribución. En el momento de escribir este artículo, la última versión es la 2.5.1 (está disponible en castellano (español) y pre-compilada); puedes encontrar la dirección URL del servidor principal al final de este artículo.

Antes de comenzar la instalación del MRTG es necesario instalar la biblioteca GD la dirección URL también está al final del artículo. La versión actual es la 1.2 y no deberían haber problemas en compilarla e instalarla. Sencillamente hay que ejecutar make en el directorio en el que se ha desempaquetado la distribución y se genera como resultado el fichero llamado libgd.a. Se copia este fichero al directorio /usr/local/lib y los ficheros con extensión .h al directorio /usr/local/include/gd.

En este punto el paquete GD debe estar correctamente instalado. Ahora se puede compilar el paquete MRTG. Extrae la distribución y edita el fichero Makefile para indicar donde se encuentra la biblioteca y los archivos de cabecera de GD, así como cual es el fichero ejecutable Perl 5.003: normalmente se encuentra en /usr/bin/perl o en /usr/local/bin/perl.

Construye el programa principal tecleando make rateup; cuando termine la compilación, teclea make substitute para incluir el path correcto del interprete de Perl en los scripts de Perl que utiliza MRTG.

Copia los siguientes ficheros su directorio destino final (por ejemplo: /usr/local/mrtg): BER.pm, SNMP_Session.pm, mrtg y rateup. También se han de copiar en este directorio los dos ficheros de configuración: indexmaker y cfgmaker.

Asegúrese que todos los programas tienen permiso de ejecución. Ya está todo listo para crear un fichero de configuración sencillo. Es necesario tener acceso SNMP de lectura al encaminador. Para un encaminador de la marca Cisco, las líneas de configuración que dan permiso son:

access-list 99 permit 193.147.0.8
access-list 99 permit 193.147.0.9
access-list 99 permit 193.147.0.130
snmp-server community public RO 99>

Esto permite peticiones de sólo lectura desde las direcciones especificadas en la lista 99, empleando la palabra clave "public" como community. Si lo que se quiere es permitir el acceso desde cualquier máquina en modo sólo lectura al encaminador, entonces la línea ha de ser la siguiente:

snmp-server community public RO

Si el encaminador de la red es de otra marca, entonces se ha de consultar el manual para determinar cómo permitir el acceso SNMP.

El script cfgmaker simplifica mucho la tarea de construir el fichero de configuración. Todo lo que hay que hacer es ejecutarlo con los siguientes parámetros:

cfgmaker @

Por ejemplo:

cfgmaker public @ mec-router.rediris.es > mrtg.cfg

Localizará todos los interfaces del encaminador mec-router.rediris.es y escribirá una sección en el fichero con las especificaciones del número de interfaces, velocidad máxima, descripción, etc., junto con algunas etiquetas HTML para que puedan ser incluidas en la página detallada. Es posible editar este fichero HTML para traducirlo al idioma y preferencias propias. Se puede ver en la Figura 5 la salida de uno de los interfaces de mi encaminador.
Figura 5 Target[mec-router.1]: 1ublic @ mec-router
MaxBytes[mec-router.1]: 1250000
Title[mec-router.1]: mec-router.rediris.es (mec-router.mec.es): Ethernet0
PageTop[mec-router.1]:
Estadisticas del puerto Ethernet0
Red del MEC (MECNET)

System: mec-router.rediris.es en RedIRIS
Maintainer: david@mec.es
Interface: Ethernet0 (1)
IP: mec-router.mec.es (193.147.0.1)
Max Speed: 1250.0 kBytes/s (ethernetCsmacd)

Ahora se puede ejecutar el programa mrtg por primera vez. Sencillamente ejecuta:

./mrtg mrtg.cfg

Si todo va bien, el programa se pondrá en contacto con el encaminador, pedirá algunos valores y generará algunos ficheros de registro y algunos ficheros GIF en el directorio actual. No hay que sorprenderse por las quejas respecto los ficheros de registro y de gráficos que no ha encontrado, esto sólo sucede la primera vez que se ejecuta. Elimina los ficheros de gráficos que genera y vuelve a ejecutar el programa otra vez. El gráfico generado mostrará el tráfico producido en el intervalo desde la última ejecución del programa. También genera páginas HTML para cada interface.

Ahora vamos a indicarle a MRTG como ejecutarse adecuadamente en el sistema. Primero se ha de crear un directorio dentro del directorio principal del web servidor (suponiendo que en el sistema haya un servidor web en funcionamiento) para contener las páginas y gráficos que MRTG generará cada vez que se ejecute. Añade este directorio en la cabecera del fichero de configuración con la directiva WorkDir: /usr/local/web/mrtg (suponiendo que el directorio raíz está situado en /usr/local/web). La próxima vez que MRTG se ejecute, creará los ficheros de registro y de gráficos en este directorio, pudiendo accederse vía your_host.domain/mrtg.

Ahora vamos a construir la página principal para todos los interfaces como la que aparece en la Figura 3. Ésto se puede llevar a cabo con la utilidad indexmaker. Ejecuta:

indexmaker mrtg.cfg > /usr/local/web/mrtg/index.html

Se generará un documento HTML con gráficos diarios de aquellos interfaces cuyo nombre de encaminador coincida con la expresión regular anterior y los enlaza con la página individual detallada.

Como se puede imaginar, el programa MRTG se ha de ejecutar a intervalos regulares para recoger datos en cada intervalo y generar los gráficos periódicamente, de forma que de la impresión de ser una monitorización en tiempo real. Esto se puede conseguir mediante la siguiente línea en el fichero /etc/crontab (suponiendo /usr/local/mrtg-bin como el directorio donde reside el programa mrtg):

0,5,10,15,20,25,30,35,40,45,50,55 * * * * \
/usr/local/mrtg-bin/mrtg \
/usr/local/mrtg-bin/mrtg.cfg > \
/dev/null 2>&1

En caso de tratarse de una distribución Red Hat, la línea que se tendría que añadir sería:

0,5,10,15,20,25,30,35,40,45,50,55 * * * * root \
/usr/local/mrtg-bin/mrtg \
/usr/local/mrtg-bin/mrtg.cfg > \
/dev/null 2>&1

Si no se ha producido ningún problema, ahora se puede dedicar algún tiempo para acabar de configurar y ajustar la página índice HTML. Una buena mejora consiste en incluir en la sección de cabecera de esta página un código para obligar al visor web a recargar la información cada 300 segundos.

Otra mejora que se puede incluir en el fichero de configuración es la directiva WriteExpire, que fuerza a MRTG a crear ficheros ".meta" para cada fichero GIF y página HTML, eliminando innecesarias operaciones de "cache" tanto en los servidores proxy como en los propios visores web. Para ello también es necesario configurar el servidor Apache (suponiendo que sea éste el servidor) para que lea estos ficheros ".meta" y envíe correctamente las cabeceras "Expire" con la directiva MetaDiren el fichero XXXX.

Se pueden encontrar más directivas en el fichero de configuración ejemplo que viene con la distribución; que por cierto, está muy bien documentado. Es posible modificar la disposición de las imágenes generadas por MRTG.

Espero que te guste este programa, si es así, enviarle a los autores una tarjeta; puedes encontrar su dirección en la página web de MRTG.

Otros Programas

Existe un programa similar llamado Router-Stats, escrito por Iain Lea, el autor del famoso programa lector de correo "tin". Router-Stats actualiza los gráficos una vez al día y muestra información estadística muy interesante sobre la utilización por horas y otros aspectos. El único problema es que se apoya en muchos programas externos. (SMU-SNMP para las tareas con SNMP, GNUPLOT para trazar gráficos, NetPBM y GIFTOOL para trabajar con gráficos).

Hay otra categoría de software que da un paso más allá en la tarea de gestión de redes, ofreciendo una solución completa tanto para monitorizar como para configurar toda la red. Este tipo de solución permite obtener una compleja representación gráfica de la red y ojear fácilmente los nodos que la componen, verificando detalles de configuración específicos y otras cuestiones de interés.

A este nivel podemos hablar de dos soluciones comerciales ampliamente utilizadas: "HP-OpenView" de Hewlett-Packard y "SunNet Manager" de Sun. Estas herramientas ofrecen una plataforma integrada para la gestión de los recursos de red, a través de impresionantes interfaces gráficos. Entre otras utilidades, disponen de herramientas para localizar los nodos de la red en los que se están ejecutándo agentes SNMP. Otra característica importante es la capacidad de integrar productos de otros fabricantes, como el CiscoWork de Cisco, que permite al administrador mantener una base de datos con todas las configuraciones de los encaminadores e incluso monitorizar gráficamente los paneles traseros de los encaminadores con todas sus conexiones.

Los dos inconvenientes fundamentales de estos productos es que son comerciales y no están disponibles para Linux. Pero por supuesto que existen soluciones disponibles públicamente con una funcionalidad más o menos similar. Uno de los paquetes que he encontrado es el Scotty. Scotty es un paquete basado en TCL que permite crear programas específicos a las necesidades de la red propia, empleando un API de alto nivel de cadenas de caracteres. Un paquete similar es el Tkined. Es un editor de red que ofrece extensiones para crear un entorno de trabajo completo, integrando algunas herramientas para localizar redes IP, soporte para el proceso de instalación de la red o resolución de problemas en redes IP utilizando SNMP en combinación con otras utilidades estándar (por ejemplo traceroute). Scotty también incluye un visor gráfico MIB que permite explorar fácilmente información MIB.

Puedes encontrar referencias tanto de paquetes comerciales como de software libre al final del artículo.

Conclusiones

SNMP es un protocolo sencillo pero potente que puede ayudar a monitorizar los recursos de red sin sobrecargar mucho la red. Quizás las extensiones que se están llevando a cabo actualmente incrementarán la complejidad y las posibilidades de esta herramienta pero a cambio incrementará los recursos necesarios para implementarla.

En este artículo, se han presentado dos herramientas que se pueden encontrar en la Internet. Existe una multitud de herramientas que se están desarrollando continuamente. Consulta el grupo de noticias de Usenet comp.protocols.snmp para estar al tanto sobre anuncios sobre nuevo software y MIBs.

__________________

"El arte por el arte es lo único que dignifica al hombre artista"