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!

    Comments 1 Comentario »

    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!

    Comments 1 Comentario »

    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.

     

    Lee el resto de esta entrada »

    Comments 2 Comentarios »

    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!

    Comments 1 Comentario »

    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.

    Comments 2 Comentarios »

    Con el comienzo del nuevo curso académico 2017/18, las nuevas peticiones de software de los laboratorios (con nuevas aplicaciones y/o nuevas versiones de programas del curso pasado), procede actualizar el fichero VDI asociado a la máquina virtual del curso anterior:

    Virtual Ubuntu EPS 2016 (VDI) (y 2)

    Al nuevo virtual le llamaremos Virtual Ubuntu EPS 2017.

    Para la obtención del mismo, tendremos que realizar su descarga accediendo a esta URL (nos pedirá previamente, aceptar el certificado y luego introducir el usuario y contraseña de la EPS):

    https://maktub.eps.ua.es/ubuntuepsvirtual/Ubuntu-VDI-EPS-16_04-2017.vdi

    Desde ella, pincharemos en el enlace que aparece para proceder a la descarga del fichero Ubuntu-VDI-EPS-16_04-2017.vdi

    El archivo ocupa 25.8 GB. Es decir, donde descarguemos el mismo, hemos de estar seguros de disponer de algo más de esos casi 26 GB. La duración de la descarga dependerá de la conexión a Internet que tengamos. Con una conexión relativamente modesta, en poco más de 1 hora debería estar descargado.

    Sigue estando basado en Ubuntu 16.04 LTS x86_64 (64 bits) pero con las actualizaciones pertinentes (en él hemos eliminado programas que ya no se han solicitado, versiones obsoletas y añadido programas y versiones nuevas acorde con el nuevo curso que comienza).

    La nueva imagen del Escritorio es ésta:

    Escritorio de VDI Ubuntu EPS 2017 (Ubuntu 16.04 LTS x86_64)

     

    Cambios realizados y listado de SW

    El SW que aparece en esta máquina virtual es, en un 90%, el que hay para GNU/Linux en los laboratorios de la EPS (entre los de Politécnica I, Politécnica IV, laboratorio LTV, laboratorio LELEC y laboratorio LROB1).

    El que sea un 90% atiende a razones de no generar problemas entre ciertas librerías y programas muy particulares pero, sobre todo, a que hay aplicaciones que tienen sentido en los laboratorios pero que en un uso en casa (o fuera de los laboratorios de la EPS), no tienen mucho sentido, por ejemplo iTalc o máquinas virtuales que sí existen en los laboratorios pero que ponerlas, a su vez, dentro de otro virtual, además de cargar demasiado éste, se ejecutarían muy ralentizadas, y tampoco tiene mucho sentido (pues pueden funcionar, de manera independiente, en cualquier arquitectura nativa de GNU/Linux, Windows y Macintosh que tenga instalada la plataforma VirtualBox).

    La lista (resumida) de programas y librerías, sería la siguiente:

    • ansible-2.0.0.2
    • atom-1.18.0-1
    • bison++-1.21.11-3.1
    • bower-1.8.0
    • caffe-master (1.0.0)
    • cmake-3.5-1
    • composer
    • docker-ce-17.06.0
    • docker-compose-1.15.0
    • Eclipse C++ 4.6 Neon, Eclipse C++ 4.7 Oxygen
    • Eclipse JEE 4.6 Neon, Eclipse JEE 4.7 Oxygen
    • firefox-47.0
    • flex-2.6.0
    • freeglut3 (2.8.1-2), freeglut3-dev (2.8.1-2)
    • gawk-4.1.3
    • gcc-5.3.1, g++-5.3.1
    • gulp-cli
    • g++-arm-linux-gnueabihf, gcc-arm-linux-gnueabihf, gdb-multiarch, pip matplotlib
    • heroku-6.13.1
    • JDK-1.8.0 Update 131, JDK-1.8.0 Update 131 APIDocs
    • jhipster-4.6.2
    • joe-4.1-2
    • laravel-5.4
    • libasound2-dev-doc-1.1.0
    • libsfml-dev-2.3.2
    • libsvm-3.22
    • make-4.1-6
    • MySQL-Server-5.7.11, MySQL-Common-5.7.11, MySQL-Connector-Java-CPP-Python
    • Netbeans-8.2
    • nlwrap-0.41
    • nodejs-4.8.4, nodejs-6.9.4, nodejs-legacy-4.2.6
    • npm-2.15.11, npm-3.10.10
    • opencv-3.3 (+ dependencias asociadas)
    • php7.0, php7.0-mysql
    • postman (5.2.1)
    • robo3t-1.1.1
    • python-2.7.11+, python-3.5.2, python-3.6
    • qemu, qemu-system-arm, qemu-user, qemu-user-static
    • ruby-dev (2.3)
    • valgrind-3.11.0
    • VirtualBox-5.1.24-117012
    • vscode-1.15.1
    • sqlitebrowser-3.7.0-1
    • sts-3.9.0
    • sublime-text-3126-prolog
    • swi-prolog-7.2.3
    • yarn-0.27.5
    • yo (yeoman) 2.0.0

     

    Aspectos a tener en cuenta para la puesta en marcha de la máquina virtual

    Se crea de forma similar a la descrita para el VDI del curso anterior (que, de momento, mantendremos también descargable durante un tiempo). Más que sustituir la máquina del curso pasado, es recomendable mantener aquélla y, para la de este curso, crear una máquina virtual totalmente nueva.

    – Habilitar bit de Virtualización en la BIOS:

    Muchos portátiles y PCs, tienen deshabilitado, por defecto, en la BIOS, el bit de Virtualización (VTx). Es fundamental que esté HABILITADO (Enabled) pues, de lo contrario, aunque podamos instalar la plataforma VirtualBox en nuestro equipo, al intentar lanzar cualquier máquina virtual, nos dará un error.

     

    – Configuración al crear la máquina virtual  (a tener muy en cuenta):

    • Memoria RAM: mínimo 2048MB.
    • Memoria de vídeo: 128 MB.
    • NO habilitar la aceleración 3D (ya que ello provocaría que los paquetes de OpenGL instalados no funcionaran bien y que programas como Postman no funcionaran correctamente).
    • NO habilitar la aceleración 2D.

     

    – Instalar Oracle VM VirtualBox Extension Pack:

    Cuando instalemos la plataforma VirtualBox (actualmente en su versión 5.1.28 y descargable desde la página https://www.virtualbox.org/wiki/Downloads), no debemos olvidar, una vez instalado, descargar el paquete de extensiones Oracle VM VirtualBox Extension Pack. Una vez descargado, abriremos la plataforma VirtualBox, iremos al menú Archivo -> Preferencias -> Extensiones y añadiremos a la plataforma el fichero con extensión vbox-extpack.

    Sin estas extensiones, no podremos conectar ni hacer attach de dispositivos USB a mayor velocidad que marca el estándar 1.1 (muy poco actualmente, donde lo normal son dispositivos estándar 2.0 y, sobre todo, 3.0).

    Instalación de Oracle VM VirtualBox Extension Pack

     

    – Instalar las Guest Additions en la máquina virtual:

    Una vez lancemos el virtual y éste esté funcionando, si la versión de VirtualBox nuestra no coincide con la de las Guest Additions del VDI, tendremos que instalar las Guest Additions de nuestra versión de VirtualBox (en dicho VDI).

    Para ello, ya con el virtual arrancado y viendo el escritorio de Ubuntu, iremos al menú Dispositivos de la ventana de VirtualBox y seleccionaremos la opción de más abajo donde pone “Imagen CD Guest Additions“. Con esto, haremos attach de dicha imagen al VDI (como si metiéramos un CD físico en la unidad de CD de la máquina virtual) y podremos proceder a instalar las citadas Additions en el virtual.

    Podremos funcionar sin las Additions, pero el funcionamiento del virtual no será tan bueno y la fluidez de paso del foco de ratón y el teclado entre el virtual y el anfitrión y viceversa, será bastante menos eficiente.

    Dicha instalación puede realizarse de forma gráfica desde el citado menú, para lo cual se nos solicitará la contraseña de root (que es “alu” sin las comillas) y seguiremos los pasos pertinentes:

    Añadir Guest Additions método GUI

    O bien, también es posible realizarlo desde una terminal de root (accesible con el comando sudo su y poniendo la contraseña alu) siempre que antes hayamos hecho attach del CD desde el menú Dispositivos del virtual.

    Una vez alcanzada la terminal de root ejecutaremos estos comandos:

    # cd /media/alu/VBOXADDITIONS_5.1.26_117224

    # ./VBoxLinuxAdditions.run

    Ejecutar VBoxLinuxAdditions.run desde terminal de texto

    Ejecución de VBoxLinuxAdditions.run desde terminal de texto

    Ejecutada la instalación de las Guest Additions desde terminal de texto

     

    Comments No Hay Comentarios »

    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 1 Comentario »

    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 1 Comentario »

    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 1 Comentario »

    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 1 Comentario »