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!

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.