Plataforma de monitorizacion y gestion de correos

Comencé hace dos años ya un trabajo para una pequeña empresa de mi ciudad. Esta empresa dedicada al alquiler de sistemas de copia digital ha funcionado, a mi entender, con unos perfiles técnicos muy básicos.

La tele-gestión del parque de copiadoras digitales es inexistente, y son más de 1000 máquinas. No existe tan siquiera la capacidad humana de implantarla de una forma coherente.

Planteé un modelo de pequeños dispositivos , basados en raspberry-pi, conectados a través de una VPN a un nodo central y en este residiera la herramienta de gestión de la monitorización. Estos pequeños dispositivos albergarían un agente de monitorización que sondearia por snmp el estado de la máquina y lo comunicaría al nodo central en caso de algún estado gracias a los traps de snmp.

El modelo funcionó pero ante la desidia de la dirección por no querer comprar dispositivos de menos de 30€ la plataforma se abandono y la experiencia solo ha quedado para mí.

Ahora el planteamiento es el siguiente. Todas las máquinas poseen la capacidad de enviar correos electrónicos en respuesta a los traps. Pues vamos a centralizar esos correos y con un sistema de scripts los vamos a analizar y gestionar de forma que nuestros sufridos técnicos y administrativos  tengan una vida mas tranquila y organizada.

Para ello hemos montado un piloto con Proxmox y dos máquinas virtuales y un container de debian 7. Comenzaremos por el host de las máquinas virtuales. 

Su descripción técnica es:

1. PC Clónico con Intel Quad Core a 2,66Ghz, 4GB de RAM, 80GB de HDD(PATA) y dos NIC (un 10/100 y otra 10/100/1000).

Se le ha instalado Proxmox VE v3.3 en la máquina y se ha retocado la configuración de red para que quede de esta forma:

• 1. Se crea un bridge de tarjetas de red , con nombre bond0, para abstraer a las máquinas virtuales el hardware a la par que damos una configuración de balanceo con TLB, que mantiene la persistencia de la conexiones con las MAC origen destino y la MAC de la tarjeta que lo gestiona. 
• Se crea un vmbr0 asociado a ese bond0 para que las máquinas virtuales salgán a la red,
• Se crean dos bridges virtuales más sin estar asociados a ningún tarjeta de red para aislar dentro del host el tráfico de red, no es un tema de seguridad sino simplemente de que no salga nada desde estás máquinas virtuales y no la "lie parda" con la infraestructura del cliente.

La configuración para ello, sacada de internet con lo cual no hay nada nuevo bajo el cielo, es la siguiente:

contenido /etc/modprobe.d/bonding.conf

alias bond0 bonding

options bonding mode=balance-tlb miimon=100 downdelay=100 updelay=100 

El contenido del archivo /etc/network/interfaces es:

auto lo

iface lo inet loopback

auto bond0

iface bond0 inet manual

        up ifconfig bond0 0.0.0.0 up

        slaves eth0 eth1

auto vmbr0

iface vmbr0 inet static

       address 192.168.100.4

       netmask 255.255.255.0

       bridge_ports bond0

       bridge_stp off

       bridge_fd 0

auto vmbr1

iface vmbr1 inet static

       address 192.168.10.4

       netmask 255.255.255.0

       bridge_ports none

       bridge_stp off

       bridge_fd 0

auto vmbr2

iface vmbr2 inet static

      address 192.168.20.4

      netmask 255.255.255.0

      bridge_ports none

      bridge_stp off

      bridge_fd 0

Una vez realizado esto he creado dos máquinas virtuales con diferentes funciones, y un container de OpenVz. 

Describimos el container primeramente ya que es la máquina más importante al ser el contenedor de la herramienta de monitorización Pandora_FMS, ved aquí la web de la wiki del proyecto que os será de gran utilidad. Está configurado este container con una imagen de Debian 7.0  con una quota de disco de 16GB y dos tarjetas virtuales de red montadas cada una en el vmbr0 y en vmbr1. Esto es para que podamos recibir las conexiones a los puertos 161 y 162 por parte de agentes y servidores snmp que envíen los traps. 

Describimos ahora las dos máquinas virtuales que hemos creado.

La primera de ellas es la que vamos a usar de FW además de servidor DNS y DHCP, y en un futuro de servidor VPN si fuera necesario.

 Esta máquina tiene configurado 1 Core, 1GB de RAM, 1 disco virtual de 16GB, además de dos tres NICS de las cuales la eth0 y eth1 están asociada al vmbr0 y la eth2 al vmbr1.

El por qué de estas asociaciones viene dado a que las eth0 y eth1 son las abstracciones de las diferentes subredes donde esta máquina virtual ha de desarrollarse. Al ser vmbr0 nuestro switch virtual donde conectamos con el exterior, las eth0 y 1 son las interfaces para poder dialogar con las diferentes subredes ajenas a mi plataforma de monitorización. Con ello tras un pequeño cambio de configuración, que supone añadir una interfaz más o menos, permite comunicarnos con subredes diferentes tales como las 192.168.0.0/24 o las 192.168.100.0/24 o 192.168.254.0/24 según sea la configuración para esa nueva tarjeta y nos permite salir a Internet. 

Este servidor tiene instalado la distro Zentyal 4.0, una distribución orientada a las PYMES que les permite tener un/variso servidore/s para los diferentes servicios como son DHCP, DNS, FW, QoS, VPN, Acitve Directory (como PDC o secundario), plataforma de correo, groupware, etc. Os dejo aquí el enlace a su Wiki que me parece muy útil. 

En nuestro caso se ha instalado los módulos: FireWall, DNS y DHCP; en un futuro es más que probable que también se instale otros módulos como VPN. Con ellos gobernamos todas las comunicaciones entre el anterior Container y la otra máquina virtual.

Ya por último la máquina virtual menos importante de todas una máquina virtual con SO de escritorio para poder acceder via Web a través de Remote Desktop a toda la plataforma sin graves complicaciones de software e infraestructura. Un Win 7 mondado y pelado con Chrome, Remote Desktop, Putty y como mucho tendrás libreoffice para documentación sino accedo desde el mismo a este blog o a Drive(tm) de Google. Y usaré además Notepad++ para el desarrollo de los scripts y git-hub para subir este código a internet.

Bueno esta es la primera fase de mi aventura. Ahora solo queda dejarlo en la oficina del cliente y ver que tal se me dá programar en Perl o Python para analizar los correos electrónicos que envíen las máquinas. 

Un saludo.

(Actualizacion)

Este modelo es demasiado complejo para funcionar de forma cómoda. Asi que he decidido otro modelo más simple, que describo aqui: