Archivo de la Categoría “Sistemas”

    Las copias de seguridad son un elemento importante dentro de las técnicas de seguridad pasiva que nos permiten, ante un incidente de seguridad, recuperarnos de él minimizando el riesgo de pérdida de información. Básicamente consisten en decidir de qué queremos guardar una copia y cada cuánto tiempo (y por cuánto tiempo la mantendremos). Las repuestas a estas preguntas dependen de la importancia de los datos, de la frecuencia de cambio y de los recursos que tengamos para almacenar las copias. Una vez tomadas estas decisiones, deberemos ejecutar el plan de copias, con la herramienta elegida (en nuestro caso, Bacula) en todos y cada uno de los equipos (servidores o no) afectados por el plan.

    Bacula es una herramienta de copias de seguridad compuesta por diversos elementos que deben configurarse y, en concreto, Bacula-file debe instalarse en todos los nodos en los que se quiera realizar copias. En otra entrada posterior (la que hace referencia el playbook common) se explicará cómo se realiza dicha instalación. Para minimizar las tareas de administración y gestión del sistema de copias de seguridad, en la infraestructura IT de la EPS hemos desarrollado el playbook de Ansible baculaAdmon (baculaAdmon.yml) de la infraestructura de ejemplo descrita aquí y aquí. Este playbook permite realizar la configuración del servicio Bacula de manera centralizada para todos los elementos que intervienen en el servicio, además de poder:

    • realizar los cambios una sola vez (en lugar de realizarlo para cada servidor) y
    • comprobar la sintaxis antes de ejecutarlo en cada servidor y en caso de error, deshacer los cambios y continuar ejecutando la configuración anterior.

    Lee el resto de esta entrada »

    Comments No Hay Comentarios »

    En la administración de sistemas y servicios existen muchas tareas repetitivas y periódicas cuya ejecución programamos haciendo uso del crontab. Muchas de estas, como las copias de seguridad, debemos hacerla en todos y cada uno de los servidores que administramos. Dentro de la gestión automatizada de la infraestructura IT de la EPS hemos automatizado esta tarea (la de programar tareas del cron) con el playbook crontab.yml (no se debe confundir con programar las tareas de Ansible que vimos en esta entrada)

    Este playbook permite realizar la configuración de las tareas de cualquier usuario para cualquiera de los servidores (excepto los que aparezcan en el grupo nocrontab) de manera centralizada y, además de poder realizar los cambios una sola vez (en lugar de realizarlo para cada servidor) también es posible modificar solo un servidor o un grupo (utilizando el parámetro –limit nombreServidor o nombreGrupo).

    La información de este playbook reside en el fichero crontab.yml y tiene la siguiente estructura:

    Lee el resto de esta entrada »

    Comments No Hay Comentarios »

    Como vimos en el primer post dedicado a la gestión automatizada de infraestructua IT de la EPS disponemos de una colección de playbooks de Ansible que se encargan, cada uno de ellos, de realizar una serie de tareas concretas (sobre 1, todos o cualquier subconjunto de servidores). La ejecución de estos playbooks se realiza periódicamente para lo cual necesitaremos añadir las tareas al cron del servidor Ansible que gestiona la infraestructura (ver este ejemplo de infraestructura).
    En este post vamos explicar cómo realizamos esta tarea con Ansible y que, para nuestro ejemplo, será el playbook cron.

    Lee el resto de esta entrada »

    Comments No Hay Comentarios »

    Como vimos en la entrada anterior, AnsibleEPS es una colección de playbooks de Ansible de la EPS que permite centralizar y automatizar las configuraciones de la infraestructura IT del centro. Para su instalación lo primero que debemos realizar es la descarga del contenido del directorio install El contenido del fichero ansibleEPS.tgz es el mismo que encontramos en el directorio de la aplicación en el repositorio  El fichero install.py es un guión de Python que nos permitirá instalar los playbooks de Ansible en nuestro equipo que actuará de servidor central de configuraciones que mencionábamos anteriormente (servidor Ansible).

    Lee el resto de esta entrada »

    Comments No Hay Comentarios »

    AnsibleEPS es una colección de playbooks de Ansible desarrollada en la Unidad de Laboratorios de la EPS para automatizar la infraestructura IT del centro. Nos permite gestionar la gran cantidad de servicios y servidores que tenemos, automatizando las principales tareas de administración de sistemas y centralizando toda la información relacionada con configuraciones en un único repositorio.

    Figura 1. Esquema de funcionamiento de AnsibleEPS

    Lee el resto de esta entrada »

    Comments No Hay Comentarios »

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

    Lee el resto de esta entrada »

    Comments No Hay Comentarios »

    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.

    Lee el resto de esta entrada »

    Comments No Hay Comentarios »

    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

    Comments No Hay Comentarios »

    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

    Comments No Hay Comentarios »

    Hemos tenido problemas con el gestor de sesiones para X Windows System que utilizamos en los laboratorios de la EPS para permitir, a los usuarios que se identifican, elegir el tipo de teclado e idioma. Cómo hemos resuelto el que, por ejemplo, alumnos de Erasmus puedan elegir inglés como idioma de la sesión y teclado, es lo que os queremos contar en esta entrada.

    Lee el resto de esta entrada »

    Comments No Hay Comentarios »