Knowledge Does Not Take Place

Loganalyzer es una herramienta que nos permite gestionar nuestros logs de manera eficaz a través de una interfaz Web. Además nos ayuda al analisis de los mismos, generando reportes.


 Instalaremos el aplicativo en una máquina con Debian 6. El procedimiento es el siguiente:

Descargamos la aplicación de la página oficial de adison y lo subimos a nuestra máquina mediante FTP o el método que gustemos.

Descomprimimos el .tar.gz. Si hemos dejado el fichero en /home/usuario hacemos:

cd /home/usuario
tar -xvf loganalyzer-3.4.5.tar.gz

Copiamos el contenido de las carpetas src y contrib que aparecen dentro de la carpeta que genera dentro al descomprimir al directorio /var/www/loganalyzer, que creamos previamente ( o a algún directorio al cual tenga permisos nuestro webserver)

mkdir /var/www/loganalyzer
cp -R /home/usuario/loganalyzer-3.4.5/src/* /var/www/loganalyzer/
cp -R /home/usuario/loganalyzer-3.4.5/contrib/* /var/www/loganalyzer/

 Damos permisos de ejecución al fichero configure.sh (que hemos copiado de la carpeta contrib), y lo ejecutamos para que nos genere el archivo config.php.

Antes de iniciar la configuración a través del navegador web, configuraremos la base de datos donde se guardarán todos los cambios y configuraciones, para ellos tenemos que instalar los siguiente:

apt-get install mysql-server php5-mysql
( y Php5 si no lo tenemos previamente)

Creamos la base de datos y el usuario con permisos sobre la misma, que le pasaremos posteriormente a la configuración de loganalyzer.

mysql -uroot -p
create database loganalyzer;
grant all privileges on loganalyzer.* to 'loganalyzer'@'localhost' identified by "password";
flush privileges;

Con estos comandos, hemos creado la base de datos loganalyzer y el usuario loganalyzer con password "password" con permisos sobre la misma.

Instalamos Apache si no lo tenemos ya, y modificamos el archivo con el virtualhost por defecto, para que el document root apunte a nuestro directorio de loganalyzer.

vi  /etc/apache2/sites-enabled/000-default

#
DocumentRoot /var/www/loganalyzer
.
.
#

Ya estamos en disposición de iniciar la instalación via web. Para ello abrimos nuestro navegador web favorito e introducimos la ip de nuestra máquina, con la modificación del fichero 000-default conseguimos que metiendo la ip nos redireccione a la instalación de loganalyzer directamente.

Seguimos los pasos que nos va mostrando el proceso para completar la instalación, sin olvidarnos de habilitar el uso de la base de datos y eligiendo nuestra fuente de datos.


En posteriores entradas veremos como configurar syslog-ng para que muestre nuestros logs mediante loganalyzer.

OwnCloud es una herramienta open source que nos permite crear nuestra propia nube privada, compartiendo ficheros (Imagenes, música, contactos etc...) y sincronizándolos con todos nuestros dispositivos.

 
Entre las ventajas que presenta está la posibilidad de guardar nuestros ficheros en un servidor de nuestra elección y acceder a ellos a través de un web browser, dispositivo móvil o mediante aplicación de escritorio. Permite también compartir los datos con otros usuarios mediante control de acceso. Además en las últimas versiones, ha introducido mejoras como la encriptación de datos, control de versiones para poder revertir cambios en ficheros etc etc... y todo ello bajo una interfaz totalmente configurable.

Instalación

Para instalar la aplicación se ha recurrido a una máquina con Debian6. Hay que tener en cuenta las capacidades de almacenamiento que necesitaremos (en caso de que el almacenamiento vaya en local), dependiendo del número de usuarios y datos, para hacerse una idea del tamaño del disco duro necesario.

Además hay una serie de paquetes que necesitamos tener instalados para que todo funcione de forma adecuada:

apt-get install apache2 php5 php5-json php-xml php-mbstring php5-zip 

php5-gd
apt-get install php5-sqlite curl libcurl3 libcurl3-dev php5-curl 

php-pdo

Comenzamos. Podemos descargarnos la última versión estable de la página oficial (http://owncloud.org)


y copiamos la carpeta donde están los recursos de nuestro Web Server
cp -r owncloud /var/www/
Una vez hecho esto, modificamos los permisos de nuestro directorio /var/www/owncloud de tal manera que el usuario que tenga el control sobre el la carpeta sea el mismo que ejecuta el apache. En mi caso www-data:

RSyslog te permite no solo configurar los logs en local, donde los recolectaremos y con que prioridad, sino también aceptar conexiones remotas con el fin de recibir  logs de otros equipos y poder centralizar todas estas operaciones de logueo. Configuraremos un escenario simple con dos máquinas Debian, uno hará de cliente y otro de servidor.


Manos a la obra. Por un lado tendremos que configurar la parte del servidor, que a fin de cuentas será aquella que reciba todo los datos. Para permitir que nuestro servidor de logs reciba peticiones, debemos modificar el fichero de configuración de rsyslog, que encontramos normalmente en /etc/rsyslog.conf . En este fichero habilitamos un par de cosillas:

# provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

# provides TCP syslog reception 
$ModLoad imtcp 
$InputTCPServerRun 514 

Estas opciones modifican el parametro de -r de syslog que ya está obsoleto. Una vez modificado, para que el servidor asuma los cambios, reiniciamos el demonio rsyslog.

o

*.*;auth,authpriv.none;\
local0.none;\
local1.none;\
local2.none;\
local3.none;\
local4.none;\
local5.none;\
local6.none;\
local7.none -/var/log/syslog

También hay que evitar que info, notice y warning terminen en /var/log/messages

*.=info;*.=notice;*.=warn;\
auth,authpriv.none;\
cron,daemon.none;\
mail,news.none;
local0.none;\
local1.none;\
local2.none;\
local3.none;\
local4.none;\
local5.none;\
local6.none;\
local7.none -/var/log/messages

y que los mensajes de debugging terminen en /var/log/debug

*.=debug;\
auth,authpriv.none;\
news.none;mail.none;
local0.none;\
local1.none;\
local2.none;\
local3.none;\
local4.none;\
local5.none;\
local6.none;\
local7.none -/var/log/debug

La separación se puede realizar de varias maneras, una es basándose en las facilities. Para ello, a cada tipo de dispositivo se asigna una facility de las "local use" y luego se implementa la configuración en base a esto, de la siguiente manera:

local3.* /var/log/remote/firewalls.log
local4.* /var/log/remote/routers.log
local5.* /var/log/remote/APs.log
local6.* /var/log/remote/switches.log

Hola de nuevo :),

hoy os traigo una herramienta opensource, que permite gestionar la configuración de vuestros elementos de red de una manera sencilla y clara.

Rancid monitoriza la configuración de los routers (y más dispositivos), incluyendo software y hardware (tarjetas, número de serie…) y usa CVS o subversión para mantener el histórico de cambios.
Rancid hace esto mediante el siguiente método:
- Se loguea en cada dispositivo encontrado en la tabla de routers (router.db).
- Corre varios comandos para conseguir la información que será guardada.
- Da formato a la salida, borra oscilaciones o incrementa los datos.
- Envía avisos por mail en caso de cambios.
- Y sube los cambios al control de versiones.



Rancid actualmente soporta Cisco routers,Juniper routers,Catalyst switches,Foundry switches, Redback NASs, ADC EZT3 muxes, MRTd, Alteon switches, and HP Procurve switches.

Una vez que hemos visto una pequeña reseña de la aplicación, podemos ponernos manos a la obra.
Instalaremos la aplicación sobre una máquina virtual con Debian6 de sistema operativo, el resto de requisitos hardware no son nada restrictivos.

Instalación

Para la instalación de la aplicación, se ha recurrido a la versión compilada de las fuentes, que podemos obtener a través de la página (http://www.shrubbery.net/rancid/). La versión instalada es la 2.3.8 que a fecha de hoy es la última estable.
 

Hay algunos prerrequisitos que debemos tener en cuenta:
- Crear usuario rancid: adduser rancid –-home /home/rancid
- Paquetes necesarios antes de la instalación, se pueden encontrar todos en los repositorios de debian sin problema.
        o Build-essential
        o Expect
        o Subversión o CVS
        o Postfix

Descomprimimos el .tar.gz
root@rancid:~/rancid-2.3.8# tar -xvf rancid-2.3.8.tar.gz
Dentro de la carpeta resultante, encontramos los ficheros necesarios para la configuración e instalación. Para instalar ejecutamos los siguiente:

cd /home/rancid/rancid-2.3.8
./configure –prefix =/home/rancid
Make install
Nota: En nuestro caso hemos descomprimido el tar en /home/rancid
 

Este proceso nos crea el árbol de directorios necesarios para manejar la herramienta.
/home/rancid/var -> aqui encontraremos los grupos de rancid y los logs
/home/rancid/bin -> en este directorio están los binarios
/home/rancid/etc -> Aquí encontramos el fichero de configuración de rancid

 

Configuración

Editamos el fichero rancid.conf en /home/rancid/etc:
  CVSROOT=$BASEDIR/CVS
  RCSSYS=svn
Cambiamos el control de versions de cvs a svn y
  LIST_OF_GROUPS = “grupo1 grupo2”
Donde “grupo1 grupo2” son los nombres de los grupos de elementos de red que vamos a crear. Podemos crear un grupo que sea SwitchesPlanta1, con los Switches de la planta 1, o cualquier agrupación que se nos ocurra.
 

Del fichero de configuración principal no tenemos que tocar nada más. Ahora pasamos a crear los usuarios (user/pass) de los switches/routers que vamos a gestionar. Para ello:

  - En /home/rancid/share/rancid encontramos un ejemplo de fichero de autenticación, llamado .cloginrc.sample. Lo copiamos directamente en nuestra carpeta /home/rancid quitándole la extensión .sample.
cp /home/rancid/share/rancid/cloginrc.sample /home/rancid/.cloginrc
 

En este fichero añadimos los switches/routers que queramos gestionar con su usuario y password. Nos fijamos que la información se guarda en texto plano y por lo tanto hay que tener cuidado extremo con el contenido de este fichero. Lo preferible es guardarlo con unos permisos restrictivos (600) y cambiando el owner al propio usuario rancid. Las líneas del fichero, tendrán una forma tal que así.
add user switch0 root
add password switch0 *Password* {*Password enable*}
add autoenable switch0 1
add method switch0 telnet
add cyphertype switch0 3des
root -> Usuario del switch
*Password* -> Password de root
*Password enable* -> En caso de ser necesario hacerse superusuario para ejecutar ciertos comandos.
Method -> telnet o ssh
Cyphertype -> tipo de encriptación.

Una vez modificados los ficheros rancid.conf y .cloginrc ya estamos en disposición de crear el control de versiones que incluirá la información una vez ejecutemos rancid. Para ello ejecutamos el binario rancid-cvs como usuario rancid que nos creará el árbol de subdirectorios para svn.
Una vez hecho esto nos aparecerá un directorio /home/rancid/var/*grupo* donde encontraremos el fichero router.db, en el cual podemos añadir los switches que gestionaremos. El formato de este fichero será:

10.156.1.1:cisco:up

siendo:
10.156.1.1 -> Ip o nombre del switch a gestionar.
Cisco -> marca del switch
Up-> estado del switch

 
Podemos comprobar si las credenciales por acceso remoto funcionan mediante el binario clogin:

/bin$ /home/rancid/bin/clogin 10.156.1.1

10.156.1.1
spawn telnet 10.156.1.1
Trying 10.156.1.1...
Connected to 10.156.1.1.
Escape character is '^]'.

User Access Verification

Password:
Router>enable
Password:
Router#

 
Si la configuración en el fichero .cloginrc es correcta, debería conectarse automaticamente por telnet al switch.

Si la prueba anterior es satisfactoria, podemos proceder a crear el control de versiones, para ello ejecutamos:
/home/rancid/bin/rancid-cvs

 
Este comando creará el árbol de directorios necesario para mantener el control de versiones. Nos aparecerán los siguientes directorios.
/home/rancid/var/CVS. Directorio raíz del repositorio configurado a través de la variable CVSROOT en el fichero rancid.conf
/home/rancid/var/logs. Directorio de los logs de la aplicación, también configurable a través del fichero de configuración rancid.conf. En cada ejecución de rancid, se alamacena un log con el proceso realizado por la aplicación y el estado del mismo.
/home/rancid/var/<NombreGrupo>. Rancid generará un directorio con el nombre de cada grupo que hayamos incluido en el fichero rancid.conf. En este directorio encontramos la siguiente distribución:
          o Directorio configs: aquí almacenará la información de los elementos que estén dados de alta en el fichero router.db, está información será la que muestre el control de versiones.
          o Router.db: en este fichero daremos de alta los elementos que gestionaremos a través de rancid. El formato del fichero es:
          switch0:hp:up
         o Switch0: Nombre o ip del elemento a gestionar
         o Hp: marca del switch
         o Up: estado del switch
         o routers.all: Una vez ejecutado rancid, aquí se mostrará la información de los elementos gestionados, del mismo modo que en router.db, pero sin el estado.
         o routers.down: En caso de no poder conectar con algún elemento rancid lo pondrá como down hasta nueva comprobación.
        o routers.up: en este fichero irá el caso contrario, los elementos que detecte como levandado los almacenará en este fichero.

Ahora ya estamos en disposición de ejecutar rancid. Para ello ejecutamos el binario rancid-run que encontraremos en /home/rancid/bin/
/home/rancid/bin/rancid-run

 
Una vez acabe podemos ver el correcto funcionamiento, mediante los logs y comprobando si en el directorio /home/rancid/var/<NombreGrupo>/config se ha creado el correspondiente fichero con la información buscada. 

Opcionalmente podemos configurar rancid para enviar un mail cuando una configuración ha sido cambiada después de correr el script de rancid. Para hacer esto, instalamos postfix:

apt-get install postfix

Para permitir el envio de correos desde rancid a nuestro servidor de SMTP, configuramos el archivo /etc/postfix/main.cf, modificando la siguiente entrada:
relayhost= FQDN_or_IP_addresse_of_your_smtp_server
reiniciamos postfix:
/etc/init.d/postfix restart

Podemos probar si los correos llegan, de la siguiente manera.

#telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 localhost ESMTP Postfix (Ubuntu)
ehlo mail
250-localhost
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250 8BITMIME
mail from: <test@test.com>
250 Ok
rcpt to: <your_email@yourcompany.com>
250 Ok
data
354 End data with .
Subject: This is a test !
Wake up please!
.
250 Ok: queued as BD8261C01D4
quitConnection closed by foreign host.  

Si comprobamos los logs de correo deberiamos ver nuestro correo.

Por último programamos el crontab para que rancid se ejecute cuando sea necesario.

 crontab -e -u rancid

# run ranid-run script every day at 00:30
30 00 * * * /home/rancid/bin/rancid-run

 Listo!.Con esto tendriamos configurado rancid.

Espero que sea de utilidad.

Saludos,

Víctor. 

Tras ver como funciona heartbeat de modo teórico, pasamos a la parte práctica. El esquema que tendremos será el siguiente:

#
#
#       of scripts to run to "start" or "stop" the given resource.
#
#       The format is like this:
#
#node-name resource1 resource2 ... resourceN
N1 192.168.112.182
Stopping High-Availability services: Done.

Waiting to allow resource takeover to complete:Done.

Starting High-Availability services: IPaddr[1683]: INFO:  Resource is stopped
IPaddr[1723]: INFO:  Resource is stopped
Done.
eth0   inet addr:192.168.112.181  Bcast:192.168.112.255  Mask:255.255.255.0
       
eth0:0   inet addr:192.168.112.182  Bcast:192.168.112.255  Mask:255.255.255.0