EPSMS: Instalación y configuración

Como comentábamos en una entrada anterior, EPSMS es una herramienta de administración de sistemas, que incluye varias utilidades para monitorizar alertas, visualizar gráficas de rendimientos, gestionar inventarios hardware/software y chequear vulnerabilidades.

Existe una demo online disponible en https://epsms.eps.ua.es (usuario: epsms contraseña: epsms) y una versión descargable desde Github https://github.com/EPSAlicante/EPSMS

En esta entrada explicaremos cómo instalar y configurar EPSMS para monitorizar un entorno de equipos como el de la Demo.

 

Continue reading “EPSMS: Instalación y configuración”

EPS Monitoring System: la herramienta imprescindible para cualquier administrador

Ya tenemos instalados nuestros servidores, y los servicios están configurados y funcionando. ¿Y ahora qué?

  • Sería muy interesante disponer de un sistema de monitorización de sistemas y servicios como Nagios, que detecte y avise de cualquier problema, haciendo que podamos solucionarlos antes de que los clientes puedan verse afectados.
  • También nos sería muy útil unas gráficas de rendimiento de los sistemas (CPU, memoria, red, discos, etc) como Munin, para poder comprobar el óptimo funcionamiento de nuestros servicios, y analizar problemas de rendimiento con datos actuales e históricos.
  • Mejor aún si además disponemos de un sistema de generación de cuadros de mando como Grafana, preconfigurado con la información obtenida de Nagios y Munin.
  • Igualmente útil, casi imprescindible, sería tener un inventario exhaustivo de todos nuestros servidores a nivel hardware, software y seguridad. Por supuesto dicho inventario tendría que realizarse de manera automática y permitir un acceso sencillo y personalizable, tanto a la información actual como a todos los cambios que se vayan produciendo.
  • A nivel de seguridad, necesitaremos un escaneador de vulnerabilidades como Openvas, con el que poder comprobar la seguridad de nuestros sistemas y servidores.

Todo esto lo realiza EPSMS: centraliza, gestiona, configura y controla todos estos sistemas tan necesarios para el control del correcto funcionamiento de nuestros servidores.

¿Puedo verlo en funcionamiento? Por supuesto, en la URL https://epsms.eps.ua.es (usuario: epsms contraseña: epsms) podemos acceder con el usuario indicado, con permisos de lectura y comprobarlo por nosotros mismos. Se trata de una instalación del software EPSMS en una red real, que nos muestra toda la información obtenida de la misma.

 

 

Podemos descargarnos el software EPSMS desde GitHub: https://github.com/EPSAlicante/EPSMS y seguir las instrucciones para ponerlo en funcionamiento con una sencillez sorprendente.

Balanceo de servicios con Haproxy

¿Quieres aumentar el rendimiento de tus servicios y además hacerlos más tolerantes a fallos?
El balanceo de servicios aumentará el rendimiento de los mismos al permitir un número mayor de accesos simultáneos. Además aumentará la tolerancia a fallos del servicio, ya que el balanceador eliminará del balanceo aquel servidor cuyo servicio haya dejado de funcionar.

Existen muchos balanceadores de servicios, unos de los más rápidos y sencillos es Haproxy. Veamos como utilizarlo.

Continue reading “Balanceo de servicios con Haproxy”

Alta disponibilidad con Nagios

En una entrada anterior ya explicamos brevemente el funcionamiento de Nagios para monitorizar el estado de nuestros servidores y servicios, y recibir alertas ante cualquier problema detectado.

También hablamos del software NRPE (Nagios Remote Plugin Executor) que complementaba el uso de Nagios para poder realizar los chequeos internamente. Es decir, Nagios no sólo comprueba el servicio desde fuera (conectándose al servicio), sino que puede conectarse al software NRPE del servidor chequeado, y una vez dentro realiza comprobaciones internas utilizando cualquier lenguaje de programación o scripting.

Utilizando estas dos herramientas tenemos un completo sistema de monitorización que nos avisa casi inmediatamente de cualquier error que se produzca. De esta manera reducimos los tiempos de caída de nuestros servicios, al detectar los problemas con mayor rapidez.

Además, con Nagios, podemos ir un poco más allá y configurarlo de tal manera que sea el propio Nagios (con ayuda de NRPE) el que responda automáticamente ante un problema de un servicio, y esté programado para resolverlo inmediatamente de manera desatendida.

Continue reading “Alta disponibilidad con Nagios”

Crea tus propias gráficas con Munin

Como ya comentábamos en una entrada anterior sobre Munin, podemos personalizar las gráficas de Munin creándolas según nuestras necesidades; es realmente sencillo, pudiendo utilizar cualquier lenguaje de scripting o programación para generarlas.

Como ejemplo usaremos un script hecho en bash para la generación de una gráfica que nos muestre la cantidad de procesos stunnel (software para el cifrado de comunicaciones) en un momento dado, y la cantidad de conexiones que tenemos al puerto 636 (utilizamos stunnel para cifrar las comunicaciones mediante este puerto) en un servidor con GNU/Linux.

La programación de las gráficas se componen de dos partes bien diferenciadas: una primera que genera el formato de la gráfica, y una segunda para la obtención de los valores a mostrar.

(1) Formato de la gráfica

Sirve para definir cómo vamos a mostrar los datos, tipos de gráfica, medidas, etc

Una posible configuración podría ser:

if [ “$1” = “config” ]; then

          echo ‘graph_title Stunnel4’
          echo ‘graph_args –base 1000 -l 0’
          echo ‘graph_vlabel procesos y conexiones Stunnel4’
          echo ‘graph_category Stunnel’
          echo ‘procesos.label Procesos stunnel’
          echo ‘procesos.draw LINE2’
          echo ‘procesos.min 0’
          echo ‘procesos.warning 100’
          echo ‘procesos.critical 200’
          echo ‘conexiones.label Conexiones stunnel’
          echo ‘conexiones.min 0’
          echo ‘conexiones.draw LINE2’
          echo ‘conexiones.warning 150’
          echo ‘conexiones.critical 250’
          exit 0

fi

La primera parte define el formato general de la gráfica:

  • graph_title define el título de la gráfica como ‘Stunnel4’
  • graph_args define la escala en base 1000 y configura el límite menor en 0 (si no se especifican los límites, estos serán configurados dinámicamente por munin según los valores a mostrar)
  • graph_vlabel define la etiqueta vertical (situada a la izquierda de la gráfica) como ‘procesos y conexiones Stunnel4’
  • graph_category define la categoría (las gráficas se agrupan en categorías a las que se puede acceder directamente desde un enlace en la página general)

La parte final configura el formato con el que se mostrarán cada uno de los conjuntos de valores, en este caso el que corresponde a los procesos y las conexiones:

  • procesos.label define la etiqueta que tendrá la leyenda bajo la gráfica para los datos de procesos
  • procesos.draw define el formato de representación (líneas, áreas, etc.) de los datos de procesos como ‘LINE2’ (se corresponde a una línea de un grosor medio)
  • procesos.min define el valor mínimo de los datos recogidos de los procesos
  • procesos.warning define el umbral de warning de los datos recogidos de los procesos (una vez superado éste, el enlace a la gráfica desde la página general se mostrará en color amarillo)
  • procesos.critical define el umbral de error de los datos recogidos de los procesos (una vez superado éste, el enlace a la gráfica desde la página general se mostrará en color rojo)

Estas características se definen para cada uno de los conjuntos de datos recogidos (en este caso se realizará también para los datos de conexiones).

(2) Obtención de valores de procesos y conexiones

Hasta ahora hemos definido la gráfica y la representación de los datos recogidos pero todavía no hemos indicado cómo vamos a obtener los datos de procesos y conexiones.

Para obtener el número de procesos stunnel, añadiremos a nuestro script:

echo -n “procesos.value ”
ps xau|grep “/usr/bin/stunnel”|grep -v “grep”|wc -l

De la misma manera, para obtener el número de conexiones establecidas al puerto 636, añadiremos al script:

echo -n “conexiones.value ”
netstat -an|grep “ESTABLISHED”|grep ESTABLISHED|tr -s ‘ ‘|cut -d’ ‘ -f4|cut -d’:’ -f2|grep ‘^636$’|wc -l

Una vez terminado el script, lo copiaremos al directorio de los plugins ‘/usr/share/munin/plugins’ con permiso de ejecución, creamos el enlace desde ‘/etc/munin/plugins’ al fichero creado, y reiniciamos el cliente de munin: munin-node.

La gráfica no estará disponible hasta unos minutos después (cuando el servidor Munin se conecte al equipo para recoger los datos). La gráfica que obtendremos tendrá un aspecto similar a esta:
munin-stunnel
Sin embargo, si queremos probarlo antes (o si hay algún problema y queremos verificar el correcto funcionamiento del plugin), realizaremos los siguientes pasos:

(1) Primero probaremos la ejecución desde el mismo equipo para comprobar que no hay errores en la programación del plugin

  • Para probar la información de configuración de la gráfica teclearemos munin-run stunnel config
  • Para probar la obtención de valores teclearemos munin-run stunnel

(2) Finalmente probaremos la ejecución desde el servidor Munin, ya que puede haber algún problema de falta de permisos o comunicación con el equipo

  • Dentro del servidor Munin abriremos una sesión telnet al puerto 4949 del equipo: telnet equipo 4949
  • Podemos ver la lista de plugins (nombres de los enlaces creado en ‘/etc/munin/plugins’) tecleando list
  • Obtendremos el formato de la gráfica tecleando config stunnel
  • Obtendremos los datos del plugins tecleando fetch stunnel
  • Cerraremos la conexión tecleando quit

 

Más información sobre la personalización de los plugins en la web oficial de Munin

TABLAS FEDERADAS EN MYSQL

En ocasiones puede ocurrir que necesitemos acceder a ciertas tablas de nuestra base de datos desde una red poco segura. Por supuesto, siempre podemos crear una base de datos con las tablas replicadas que necesitemos. De esta manera podremos leer toda la información de esas tablas sin necesidad de acceder a la base de datos central.

¿Pero qué ocurre si además de poder leer esas tablas necesitamos insertar o actualizar datos?

Siempre podríamos hacer una doble replicación, pero el sistema se vuelve demasiado complicado, además de de no tener toda la información ‘de primera mano’ en la base de datos central, ya que parte de la información viene ‘replicada’, con lo que no podremos replicar toda la base de datos a otro lugar (por ejemplo para tener una copia como espejo, o simplemente para balancear las lecturas entre varias bases de datos).
No es muy aconsejable realizar una doble replicación a no ser que sea absolutamente necesario y no haya otra posibilidad.

Pero hay otra posibilidad mucho más sencilla y elegante. Se trata de las tablas federadas, un tipo de motor de Mysql ‘FEDERATED’ en las que se crea un enlace entre la tabla ‘federada’ y la tabla principal de la base de datos central. Es por ello que esta tabla no contiene datos, sólo el enlace mencionado.

Por ejemplo si tenemos en la base de datos central (de un servidor principal) una tabla:

CREATE TABLE prueba (
idTabla INT(5) NOT NULL AUTO_INCREMENT,
dato VARCHAR(20) NOT NULL DEFAULT ”,
PRIMARY KEY (idTabla)
)
ENGINE=MyISAM

En la base de datos secundaria (de otro servidor) la tabla federada sería:

CREATE TABLE prueba (
idTabla INT(5) NOT NULL,
dato VARCHAR(20) NOT NULL DEFAULT ”
)
ENGINE=FEDERATED
CONNECTION=’mysql://usuario_de_conexión@IP_del_servidor:3306/base_de_datos/prueba’;

Evidentemente, la tabla principal y la tabla federada tendrán la misma estructura, aunque la tabla federada no necesita AUTO_INCREMENT ni índices, ya que no almacena datos, sólo funciona como una interfaz.

¿Cómo funciona exactamente una tabla federada?

se-federated-structure

Imaginemos que tenemos una base de datos central en un servidor principal, y otra base de datos secundaria en otro servidor donde crearemos nuestra tabla federada. En este caso, la cadena ‘CONNECTION’ de la tabla federada apuntará a la tabla real de la base de datos central (necesitaremos un usuario de conexión que se creará en la base de datos central para tal menester).

Cuando se lleva a cabo una operación de escritura en la tabla federada, ésta se conectará a la base de datos central, y le enviará la operación a realizar sobre la tabla real. La base de datos central realizará la operación y devolverá el resultado a la base de datos secundaria que informará al usuario.

El uso de tablas federadas es totalmente transparente para el usuario (el funcionamiento es igual que si fuese real), y de esta manera nos permite crear bases de datos secundarias sólo con las tablas necesarias y con posibilidad de escritura.

Más información en la web de Mysql

Distribuciones GNU/Linux utilizadas en los Servidores de la EPS

La unidad de laboratorios de la EPS ha utilizado a lo largo de estos años (y sigue utilizando) GNU/Linux como el sistema operativo principal para la gran mayoría de servidores a su cargo. Hemos usado diferentes distribuciones, según sus características y las necesidades propias del servicio en ese momento, pero intentando que hubiese una distribución ‘base’ que estuviese instalada en la mayoría de servidores, para facilitar así su administración.

La primera distribución utilizada, allá por 1996 fue la Slackware 3.1 (también llamada Slackware 96). Slackware es una de las distribuciones más antiguas (todavía sigue vigente), y era por entonces una de las distribuciones más importantes (si no la más).

Continue reading “Distribuciones GNU/Linux utilizadas en los Servidores de la EPS”

No recuerdo la contraseña de root de Mysql!!!

Si eres usuario de esta Mysql puede que en algún momento te hayas olvidado de la contraseña de tu usuario. No hay problema, siempre puedes acceder como root (o pedir al usuario root que acceda al mysql) y cambiar la contraseña. Pero ¿qué pasa si el usuario root olvida su contraseña?

Mysql deja una puerta trasera (realmente hay más de una) por la que poder acceder y resolver este tipo de problema. Estos son los pasos a seguir para poder cambiar la contraseña de root de mysql bajo Linux (en Windows los pasos son muy similares):

  • El primer paso será acceder al equipo como usuario root del sistema.
  • Escribimos el comando de cambio de contraseña. Por ejemplo:

SET PASSWORD FOR ‘root’@’localhost’ = PASSWORD(‘nuevo password’);

y lo guardamos en un fichero de texto con cualquier nombre (por ejemplo nuevopasswd.sql), teniendo en cuenta que debemos darle permiso de lectura al usuario mysql que es el que ejecuta el servicio mysql.

  • Modificamos el fichero de configuración de mysql (my.cnf) para añadirle en el apartado [mysqld] la opción:

init-file = /path_al_fichero/nuevopasswd.sql

Esta opción hará que Mysql ejecute el comando del fichero en el arranque, antes de permitir ninguna conexión.

  • Reiniciamos el servicio mysql y comprobamos que ya podemos conectarnos como root con la nueva contraseña.
  • El último paso será borrar el fichero de texto con la nueva contraseña así como la línea ‘init-file’ de my.cnf, para que no la tenga en cuenta en futuros reinicios.

De esta sencilla manera podemos solucionar un grave problema de una manera rápida y segura, con tan sólo un reinicio del servicio.

Servidores de EPSAlicante en cifras

La Escuela Politécnica Superior de la Universidad de Alicante ha ido creciendo en todos los aspectos desde que entramos en el siglo XXI. Detrás de todos los laboratorios y servicios que prestamos, hay una infraestructura de soporte que ni se ve, ni se nota (y eso es bueno).  Conforme ha ido creciendo la Unidad de Laboratorios, también lo ha hecho esta infraestructura (tanto en complejidad como en cantidad) y cómo no, la cantidad de servidores utilizados para prestar todos los servicios actuales.

En la gráfica se puede apreciar el aumento de servidores desde 1999 hasta la actualidad, y cómo ésta crece drásticamente con el comienzo del uso de la virtualización de servidores en 2007, y aplicando el principio de mínimo punto de exposición y el balanceo de servicios.

ServidoresEPS

No todos son servidores “reales”, sino que también se reutilizan como tales, equipos retirados de laboratorios, que prestan servicios balanceados y de pocos requerimientos. En la gráfica podemos observar la antigüedad de los servidores, tanto los verdaderos, como los PCs reutilizados como servidores.

Servidores-PC

Es esta otra gráfica podemos observar la cantidad de servidores utilizados según el tipo de servicio. Lógicamente, hay servidores que prestan más de un servicio, así como distintos servidores que realizan los mismos servicios en diferentes emplazamientos (se dan prácticas docentes con PCs en 26 laboratorios situados en cuatro edificios del campus).

ServidoresPorTipo

Por último podemos ver la relación entre los anfitriones de virtualización utilizados y los virtuales que soportan. Como se aprecia en la gráfica, el ratio de virtuales por anfitrión es mucho menor en el caso de los PCs reutilizados como anfitriones.

VirtualesPorHost

¿Necesitas configurar varias máquinas, todas iguales? Hazlo con Puppet

¿Trabajas con varios equipos con Linux? ¿Te gustaría que los equipos se pudieran configurar ‘solos’? No podemos decir que se configurarán sin que tengamos que hacer nada, pero sí que realizaremos la gestión una sola vez y nos valdrá para todas las máquinas que queramos administrar, y que ellas mismas se encargarán de comprobar si están correctamente configuradas, y de actualizarse si no es así.

Puppet Open Source es un software cliente/servidor. Debemos instalar el software maestro en una máquina desde la que controlaremos la configuración del resto de máquinas (incluso de ella misma), e instalar el software cliente en cada una de las máquinas que queremos que sean auto-administradas (pueden ser Linux, Unix o incluso Windows).

Continue reading “¿Necesitas configurar varias máquinas, todas iguales? Hazlo con Puppet”