Nagios y Ansible II: nrpe

Continuando con nuestros playbooks de gestión de sistermas y servicios y, en concreto, con la monitorización de ellos con Nagios, vamos a ver cómo configuramos nrpe. Este es un demonio al que se conectará el servidor de Nagios para obtener el estado del servicio a comprobar.

El playbook nrpe.yml  es el que nos permite configurar los chequeos NRPE para todos los servidores (excepto los que aparezcan en el grupo nonrpe) de manera centralizada. Como hemos indicado en todas las entradas dedicadas a Ansible, el gestionar de esta forma este servicio, nos permite realizar los cambios una sóla vez ,en lugar de realizarlo para cada servidor y con comprobación de errores sintácticos. También, además, es posible modificar sólo un servidor o un grupo, con el parámetro –limit nombreServidor o nombreGrupo.

Continue reading “Nagios y Ansible II: nrpe”

Nagios y Ansible

Como comentábamos en la entrada anterior, utilizamos varias herramientas de monitorización cuya configuración hemos automatizado con Ansible. Además de Munin, también monitorizamos nuestros servicios con Nagios (aquí y aquí explicamos un poco de este software de monitorización) para el que hemos desarrollado dos playbooks: nagios.yml y nrpe.yml, con los que realizamos la configuración de este servicio de monitorización en todos los servidores donde se ejecuta dicho software de monitorización y para los monitorizar los servidores que lo consideremos (normalmente, todos).

Como en todos los playbooks de AnsibleEPS para nuestra infraestructura, este nos permite realizar de manera centralizada, para todos los servidores que realizan el servicio, las tareas de configuración asociadas a él,  realizándose los cambios una sola vez (en lugar de realizarlo para cada servidor) y, antes de ejecutarlo en cada servidor, comprueba la sintaxis, avisando de errores producidos si es el caso (aunque para estos playbooks no se vuelve a la versión anterior).

En esta entrada vamos a ver el primero de los playbooks:nagios.yml, el encargado de configurar el/los servidor(es) Nagios que tengamos en nuestra infraestructura.

Continue reading “Nagios y Ansible”

Automatización de la herramienta de monitorización Munin con AnsibleEPS

En nuestra unidad, utilizamos varias herramientas de monitorización libres cuya configuración automatizamos con Ansible. Uno de ellos es Munin (para quien quiera conocer más sobre Munin, aquí tiene una guía de inicio). En esta entrada, vamos a ver cómo funciona y cómo podemos configurar el playbook de AnsibleEPS para Munin.

Como en todos los playbooks de AnsibleEPS para nuestra infraestructura, este nos permite realizar de manera centralizada, para todos los servidores que realizan el servicio, las tareas de configuración asociadas a él. En el caso de Munin: la configuración de la lista de clientes munin.

Lo primero que debemos tener en cuenta es que el playbook common.yml se encarga (entre otras muchas tareas: más información sobre este playbook aquí) de instalar y configurar el software de los clientes (munin-node). Además permitirá el acceso desde los servidores del grupo munin.

¿Cómo se realizan los cambios para Munin? Mediante  el fichero situado en roles/munin/templates/etc/munin/conf.d/hosts.j2  Dicho template no es mas que el fichero de configuración hosts del servidor Munin con la lista de clientes munin. El template obtiene todos los equipos del inventario excepto los del grupo nomunin y los introduce en la lista. Si queremos tener otros clientes munin que no se encuentren en el inventario, se creará a mano un fichero con la lista dentro del mismo directorio (ya existe un fichero así llamado hosts-outsiders).

La ejecución del playbook se realiza con la orden:  ansible-playbook munin.yml que afectará a todos los servidores incluidos en el grupo munin. Tras la ejecución de esta orden, tendríamos configurado en los servidores del grupo munin la recolección de datos de todos nuestros servidores excepto de aquellos que hayamos incluido en el grupo nomunin.

Si queremos que todo sea automático (hasta la inclusión de los servidores) disponemos de una aplicación de monitorización genérica que llamamos EPS-MS (el software está en Github) que descubre todos los servidores de la red que le indiquemos. Así, la diferencia entre ambos es que, mientras con EPS-MS los servidores se localizan automáticamente por la aplicación, en  AnsibleEPS los servidores los introduce el administrador en el inventario pero el resultado es que tendremos nuestro servidor/servidores de Munin monitorizando los servidores de nuestra infraestructura de los que necesitemos tener información (para nosotros, todos 😉 ).

¡Esperamos que os sea útil!

Automatizando los filtros iptables con Ansible

Dentro de nuestra colección de playbooks de Ansible  para automatizar la gestión de la infraestructura IT del centro,uno muy importante e interesante es el que nos permite configurar los filtros de red que aplicamos a todos los elementos de nuestra infraestructura. En nuestro caso, independientemente de qué filtros se realicen en el equipamiento de red, en nuestros servidores se filtra desde dónde se puede enviar y recibir paquetes (tanto desde qué redes/equipos como puertos TCP/UDP). Estos filtros los implementamos con iptables:  utilidad integrada en el núcleo de Linux que nos permite realizar filtros de red con este sistema operativo.

Continue reading “Automatizando los filtros iptables con Ansible”

Automatización de los cambios del fichero /etc/hosts

Dentro de los distintos sistemas de resolución de nombres con lo que contamos en servidores basados en GNU/Linux disponemos del basado en el contenido del fichero /etc/hosts, que en condiciones normales es el primero en comprobarse y utilizarse. Aunque no es habitual introducir en él múltiples datos, sí lo es añadir aquellos que queremos que se resuelvan de forma específica para un servidor en concreto (y con menor latencia al ser un proceso local). Suelen contener, como mínimo, la resolución local (para el nombre localhost, la IP 127.0.0.1) aunque, dependiendo de las necesidades, puede contener más asociaciones nombre-ip. Cuando el número de servidores de tu infraestructura es de cierto tamaño, cambiar un datos de este fichero (o incluso simplemente tener “controlado” su contenido) puede ser un proceso largo y tedioso.

Dentro de nuestra colección de playbooks de Ansible  para automatizar la infraestructura IT del centro, tenemos uno, hostsFile.yml, que permite modificar la configuración del fichero /etc/hosts de todos los servidores, excepto aquellos que aparezcan en el grupo nohostsFile (con Ansible, recordemos, esto se realiza de manera centralizada y en un solo paso). Con este playbook podemos modificar todos los servidores, solo uno o un grupo, con el parámetro –limit nombreServidor o nombreGrupo. Como siempre, antes de ejecutar el playbook en cada servidor, se comprueba la sintaxis y, en caso de error, deshace los cambios y continua ejecutando la configuración anterior. Los cambios se realizan modificando unas variables que (a través de un template) terminarán generando el fichero de configuración /etc/hosts para cada servidor. La orden para ejecutar este playbook es: ansible-playbook hostsFile.yml

Las variables se declaran en el fichero general group_vars/all/hostsFile (aunque es posible sobreescribir los valores en los ficheros por grupo o por host, no es lo normal ya que en el fichero general existen variables para grupos y servidores específicos):

  • hostsFileGlobal -> Configuración de /etc/hosts para todos los servidores. Se trata de una lista con atributos para definir las entradas del fichero con la IP el nombre completo del servidor (FQDN) y los alias. Cada item de la lista puede tener estos atributos:
    • label -> Este atributo tiene una doble función: por un lado servirá de comentario en el fichero, y por otro lado es la clave del item. Esto quiere decir que si más adelante queremos hacer referencia a una entrada (para eliminarla o sobreescribirla), lo haremos por este atributo.
    • host -> Se trata de una cadena de texto con el hostname de la entrada. Hay una excepción a la regla: si escribimos la cadena hostname, se escribirá el nombre del servidor (variable inventory_hostname) en la entrada.
    • IP -> Se trata de una cadena de texto con la dirección IP de la entrada. Este atributo es opcional, si no está definida se obtendrá la cadena del resultado de ejecutar el comando host al nombre del servidor (inventory_hostname).
    • fqdn -> Se trata de una cadena de texto con el nombre completo de la entrada. Este atributo es opcional, si no está definida se obtendrá la cadena a partir del atributo host más el dominio DNS (variable global domain). Si el atributo host tiene el valor hostname, se obtendrá la cadena del resultado de ejecutar el comando host al nombre del servidor (inventory_hostname).
    • extra -> Se trata de una cadena de texto con el resto de alias que quieran añadirse en la entrada (si no es suficiente con los campos anteriores). Este atributo es opcional.

Los atributos label y host son obligatorios y deben existir ya que si no la entrada no se pasará al fichero de configuración. Un ejemplo de configuración de esta variable es:

hostsFileGlobal:
- label: Localhost
  host: localhost
  fqdn: localhost.locadomain
  IP: 127.0.0.1
- label: IP local
  host: hostname
  • hostsFileGroup -> Configuración de /etc/hosts para un grupo específico. Se trata de una lista de variables, cada una de ellas con dos atributos. Un primer atributo llamado group con el nombre del grupo al que se le aplicarán las declaraciones, y otro atributo que incluye las entradas a aplicar (este atributo en en realidad una lista). La lista de entradas incluye para cada item cinco atributos idénticos a los que existían en la variable hostsFileGlobal (labelhostIPfqdn y extra), y que se comportan de idéntica manera. Podemos sobreescribir o eliminar las entradas globales desde esta variable (en esta lista de entradas por grupo). Para realizar estas operaciones habrá que:
    • Sobreescribir entradas globales -> Declaramos el atributo label con el mismo texto que el atributo global, y definimos el resto de atributos con los valores que queramos en este caso concreto.
    • Eliminar entradas globales -> Declaramos el atributo label con el mismo texto que el atributo global, y no declaramos el resto de atributos (no quiero decir que se declaran con valor nulo, sino que en la entrada sólo existirá el atributo ‘label’)

El resto de entradas que se escriban (y no coincida el label con ninguna ‘global’) se añadiran en el fichero a las globales. Ejemplo de configuración:

hostsFileGroup:
- group: serversP1
  rules:
  - label:alias dns server
    host: server_11
    IP: 172.20.1.11
- group: serversP2 
  rules: 
  - label: alias dns server
    host: server_21 
    IP: 172.20.2.21
  • hostsFileHost -> Configuración de /etc/hosts para un servidor específico y al igual que la anterior, es una lista de variables, cada una de ellas con dos atributos, donde el primer atributo (host) se corresponde con el nombre del servidor al que se le aplicarán las declaraciones. El otro incluye las entradas a aplicar y, al igual que ocurre con el segundo atributo de hostsFileGroup, para cada item disponemos de cinco atributos (labelhostIP’fqdn y extra) que se comportan de idéntica manera. Ejemplo de configuración de esta variable:
HostsFileHost:
- host: ansible_server
  rules:
  - label:sentinel
    host:sentinel
    IP: 172.20.1.15

¡Esperamos que os sea útil!

Automatización de la configuración de servidores DHCP con Ansible

Dentro de la colección de playbooks que tenemos programados para la gestión de servidores de la EPS y, continuando con AnsibleEPS, en esta entrada nos vamos a centrar en la automatización de la configuración de servidores DHCP, tomando como base la infraestructura de ejemplo descrita aquí y aquí.

Figura 1.- Infraestructura de ejemplo

La automatización del DHCP se hace en el playbook dhcp.yml el cual permite realizar la configuración del servicio DHCP para todos los servidores que tienen instalado este servicio. Estos cambios se realizan, como ya hemos comentado en entradas anteriores sobre Ansible, de forma centralizada y, además permite realizar los cambios una sola vez (en lugar de realizarlo para cada servidor) y, antes de ejecutarlo en cada servidor, comprueba la sintaxis, deshaciendo los cambios y ejecutando la configuración anterior en caso de error.

Los cambios se realizan modificando ficheros estáticos (sin variables), ya que estos ficheros son idénticos para cada servidor a configurar, dentro del directorio roles/dhcp/files. En este directorio tendremos un subdirectorio etc/dhcp/ con los ficheros de configuración por edificio de la infraestructura: dhcpd-P1.conf, dhcpdP2.conf y dhcpd-P3.conf (son ficheros de configuración normales de DHCP)

Por otra parte, en el directorio taks tenemos definidas las tareas, también una por edificio de la infraestructura: dhcpP1.yml, dhcpP2.ymldhcpP3.yml. Al igual que con el resto de playbooks, este lo podemos lanzar con la opción correspondiente en el menú (/etc/ansibleEPS/menu.py) o con la orden ansible-playbook dhcp.yml

¡Esperamos que os sea útil!

Configuración básica de servidores con Ansible

En esta entrada vamos a ver cómo automatizar con Ansible información básica de servidores como la gestión de usuarios, grupos, etc (ver tabla 1). Todas estas tareas, en nuestro ejemplo, se realiza con el playbook common. common.yml se encarga de realizar la configuración básica de todos los servidores (excepto los que aparezcan en el grupo nocommon) de manera centralizada y, además, de poder realizar estos cambios de una sóla vez (en lugar de realizarlo para cada servidor, aunque también es posible modificar sólo un servidor o un grupo, con el parámetro –limit nombreServidor o nombreGrupo). De las tareas a realizar se encargan los ficheros de la tabla 1.

Tarea Descripción
manager.yml Gestión del usuario manager. Comprueba su existencia y lo crea y añade a grupos específicos (variable managerGroups), si es necesario.
group.yml Gestión de grupos. Añade grupos de trabajo y los configura con los usuarios de la variable groupRoot
repos.yml Gestión de los repositorios Con reposUpdate=y añadirá los repos necesarios para el sistema
dselect.yml Instalación de dselect (en debian)
concurrency.yml Asignación de concurrency=NONE (en debian)
services.yml  Parada de servicios no requeridos indicados por la variable stopServices
resolv.yml Gestión del cliente DNS /etc/resolv.conf para añadir el valor de domain, search y nameserver, usando respectivamente, las variables domain, search y nameservers.
nscd.yml Instalación y configuración del servicio NSCD
securetty.yml Gestión de los permisos de acceso /etc/securetty a partir del fichero estático files/etc/securetty
locales.yml Gestión de las locales. Configura el fichero apropiado a cada distribución a partir de ficheros estáticos situados dentro de files/etc
profile.yml Gestión del profile general /etc/profile según la variable profileEtc
nvi.yml Instalación de nvi y configuración por defecto como vi
utils.yml Instalación de software adicional
pam-ldap.yml Instalación y configuración de las PAM con LDAP a partir de templates situados en el directorio templates/etc/ y las variables ldapA, ldapB y ldapC que indican 3 servidores LDAP diferentes
syslog.yml Configuración del envío de logs a servidores remotos utilizando la variable syslog
sshd.yml Configuración del servicio sshd usando la variable sshdConfig y sus atributos: permitRootLogin, clienteAliveInterval, clientAliveCountMax, matchGroup, logLvel y subsystemSftp.
ntp.yml Instalación y configuración del servicio NTP
muni-node.yml Instalación y configuración del cliente Munin-Node utilizando la variable muninMaster para indicar la lista de IPs de los servidores maestros de Munin.
nrpe.yml  Instalación y configuración del cliente Nagios-NRPE, configurando /etc/hosts.allow a partir de la variable nagiosMaster
bacula-df.yml  Instalación y configuración del cliente Bacula-FD a partir del template templates/etc/bacula/bacula.conf.XX.j2 y /etc/hosts.allow a partir de la variable baculaMaster
ossec.yml  Instalación y configuración del cliente Ossec utilizando la variable ossecMaster y el template templates/var/ossec/etc/ossec.conf.XX.j2

Tabla 1.- Lista de tareas del playbook common

Los cambios se realizan modificando las variables apropiadas que, a través de las tareas correspondientes, terminarán realizando las operaciones necesarias para cumplir su función. Las variables para todas las tareas se declaran principalmente en el fichero general group_vars/all, aunque se pueden sobreescribir los valores en los ficheros de grupo o de host, según las necesidades específicas de cada servidor. Así mismo, si las variables dependen de la distribución, pueden estar declaradas en los ficheros específicos de cada distribución y versión.

¡Esperamos que os sea útil!

Playbook de Ansible para configurar copias de seguridad con Bacula

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.

Continue reading “Playbook de Ansible para configurar copias de seguridad con Bacula”

Automatización de la programación de tareas del crontab de nuestros servidores con Ansible

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:

Continue reading “Automatización de la programación de tareas del crontab de nuestros servidores con Ansible”

Configuración del crontab del servidor Ansible para lanzar todos los playbooks diariamente.

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.

Continue reading “Configuración del crontab del servidor Ansible para lanzar todos los playbooks diariamente.”