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!

Inicio curso 2010-2011

Comienza un nuevo curso y, este año, con la incorporación de los nuevos títulos de grado. Independientemente del tipo de titulación, nuestros usuarios (alumnos y profesores) necesitan conocer cierta información como requisito para el uso y utilización de los eServices y de los Laboratorios de la EPS. Por ejemplo, necesitamos:

  • Usuario y contraseña de la EPS. NO ES la que hemos utilizado en el Campus Virtual para la matriculación en la UA. En esta página de ayuda tenemos todo sobre los usuarios de la EPS.
  • Los horarios de laboratorio y teoría los puedo consultar aquí
  • Excepto los alumnos de las titulaciones de grado a los que ya se les ha asignado los turnos de prácticas desde el centro, el resto pueden, siguiendo las instrucciones de sus profesores, usar el sistema de matriculación de la EPS.  ¿Dónde se puede consultar la información referente a la matriculación a prácticas? Aquí
  • Además de estos servicios que, casi seguro, vais a utilizar desde los primeros días, la EPS también proporciona otros cuya utilidad la encontraréis conforme vaya avanzando el curso. Por ejemplo, para completar prácticas al margen de las horas de los grupos de prácticas que tenéis asignados, la EPS dispone de:

    • 2 laboratorios especiales: uno físico y otro virtual y remoto.
    • DVD con la misma distribución que existe en los laboratorios y que podéis utilizar en cualquier otro ordenador.
    • Convenio con Microsoft que permite la descarga y uso del software que se utiliza en prácticas (excepto Office) y que podéis instalar en vuestro PC.

    En general, si queréis informaros sobre los recursos que os proporciona la EPS como apoyo para vuestros estudios, podéis consultar  esta página que dispone de información más completa. ¡Ah! Recordad que, si usáis otro correo distinto al que os proporciona la UA (gmail, hotmail,…) debéis redirigir el de la UA al que uséis ya que toda las comunicaciones institucionales se os enviarán a vuestro correo UA.

    Para informaros sobre qué pasa en la EPS, tenemos diversos canales: nuestro web, la revista de la EPS, Facebook, nuestro canal Youtube, Twitter (para saber qué estamos haciendo) y, por supuesto, este blog.

    ¡¡¡¡Buen curso a todos/as !!!!

    Empezamos un nuevo curso

    Con el nuevo curso, algunos, sobre todo los/las que tenemos mala memoria, nos encontramos con que de nuestra cabeza ha desaparecido información que, justo en estos momentos, nos interesa para el inicio del curso.

  • ¿Cuál era mi contraseña? Se me ha olvidado. Pues la página de ayuda que tenemos sobre los usuarios de la EPS (recordad que es el mismo tanto para el acceso al Web como a los equipos de laboratorio) se encuentra aquí.
  • ¿Dónde puedo consultar los horarios de laboratorio? Aquí
  • ¿La información referente a la matriculación a prácticas? Aquí
  • ¿Qué laboratorios tengo disponibles para realizar prácticas extras? Son dos: uno físico y otro virtual y remoto.
  • En general, qué recursos me proporciona la EPS para mis estudios: la información aquí.
  • Cómo puedo informarme sobre qué pasa en la EPS. Pues tenemos diversos canales: nuestro web, la revista de la EPS, Facebook, nuestro canal Youtube, Twitter (para saber qué estamos haciendo) y, por supueto, este blog.
  • Infraestructura de gestión de usuarios en la EPS.

    En la Escuela Politécnica Superior, desde hace más de 6 años, se identifica, autentica y autoriza (AAA) a los usuarios para acceder a los equipos de los laboratorios (así como a muchos de los servicios disponibles en la web). La base del proceso AAA de la EPS está en el manejo de directorios y el protocolo LDAP.

    El número elevado de autenticaciones concurrentes, así como la necesidad de encriptar las comunicaciones, requiere de una infraestructura dedicada exclusivamente a garantizar el correcto y rápido funcionamiento del servicio.

    En la gráfica siguiente se muestra el esquema utilizado para la autenticación de los laboratorios de la EPS, tanto los de Politécnica I como los de Politécnica IV:

    Esquema de autenticación de usuarios en la EPS

    Arquitectura para AAA en la EPS

    Politécnica I
    El acceso al sistema desde los clientes de laboratorios realiza la autenticación mediante LDAPS (LDAP+SSL)
    Para ello se dispone de seis servidores (Stunnel1, Stunnel1, Stunnel2, Stunnel3, Stunnel4, Stunnel5) que se encargan de desencriptar la comunicación SSL de los clientes (mediante una aplicación GNU llamada stunnel), obtener las peticiones y enviar la petición sin SSL a los servidores LDAP (Slave1-P1, Slave2-P1, Slave3-P1, Slave4-P1).

    Se realiza de esta manera en lugar de acceder directamente a los servidores LDAPS, por el elevado consumo de recursos necesarios para la desencriptación. Éste fue el motivo que nos llevó a separar las tareas de desencriptación y consulta en la base de datos del directorio LDAP: el objetivo era disponer de un mayor número de servidores, aunque fueran menos potentes, y balancear las peticiones entre ellos.

    Con el fin de conseguir alta disponibilidad y reparto de carga, se utiliza el router de planta para balancear los servicios. Así, los clientes no realizan las peticiones encriptadas con SSL (a través del programa stunnel instalado en cada cliente que encripta las peticiones) directamente a los servidores SSL (Stunnel1 a Stunnel5), sino que las realizan a una dirección IP gestionado por el router de planta que se encarga de balancear la petición entre los servidores Stunnel. De la misma manera, una vez desencriptada cada petición, tampoco se envía directamente a los servidores LDAP, sino que se vuelve a enviar a otra dirección IP gestionada por el router para que la balancee entre los distintos servidores LDAP en función de la carga soportada.

    Con este sistema montado para la Politécnica I (donde hay 16 laboratorios con más 500 PCs) se consiguen 2 objetivos: mejorar la respuesta ante picos de concurrencia y alta disponibilidad (si cae un servidor, el router lo elimina del balanceo sin que el servicio se vea perjudicado).

    Según el monitor Nagios que vigila los servicios y sistemas de la EPS, la disponibilidad de este servicio durante el año 2008 fue de 99% del tiempo. Es más, si sólo se tiene en cuenta los periodos lectivos, este porcentaje sube al 99’99%, es decir, prácticamente sin periodos de inactividad que afecte a los laboratorios.

    Politécnica IV
    Los clientes de la politécnica IV no se conectan a los servidores de la Politécnica I para realizar la autenticación. Para acelerar la respuesta, disponen de sus propios servidores con Stunnel y LDAP.

    En este caso, los clientes se conectan del mismo modo a la dirección del router de la PIV. El router balancea las peticiones SSL entre los servidores de la PIV (Slave1-P4 y slave2-P4), que una vez desencriptadas, envía las peticiones LDAP (sin SSL) al servidor LDAP destinado, en lugar de hacerlo al router como en la PI (ya que sólo se dispone de dos servidores, y el reparto de carga ya está realizado con el primer balanceo).