Con el comienzo del nuevo curso académico 2018/19, 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 2017 (VDI)

    Al nuevo virtual le llamaremos Virtual Ubuntu EPS 2018.

    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-2018.vdi

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

    El archivo ocupa alrededor de 36 GB. Es decir, donde descarguemos el mismo, hemos de estar seguros de disponer de algo más de ese tamaño (preferiblemente unos 40 GB). La duración de la descarga dependerá de la conexión a Internet que tengamos. Con una conexión relativamente modesta, en menos de 2 horas debería estar descargado.

    Sigue estando basado en Ubuntu 16.04 LTS x86_64 (64 bits) pero con las actualizaciones pertinentes y añadiendo los nuevos programas y versiones del nuevo curso.

    Al arrancar, en esta ocasión ofrece: bien en modo ventana o bien en pantalla completa (recomendado este último pues, de otra forma, muchos iconos del Escritorio, no se verán bien).

    La nueva imagen del Escritorio es ésta:

     

    Cambios realizados y listado de SW nuevo

    El SW que aparece en esta máquina virtual es, en un 95%, 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 no sea el 100% 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 mucha utilidad, 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 de programas y librerías nuevos (añadidos a otros del curso pasado), sería la siguiente:

    • adobe-air
    • appinventor2-setup-2.3
    • blender-2.76
    • cryptsetup-bin
    • Eclipse Java 4.7 Oxygen (versión no JEE)
    • Eclipse JEE 4.8 Photon
    • exfat, fuse-utils-1.2.3-1
    • firefox-63.0.1
    • gcc-5.4.0, g++-5.4.0
    • gcc-msp430
    • gitkraken
    • go 1.7.4
    • google-chrome-stable-69.0.3497.100
    • ipython-2.4.1-1
    • kernel 4.4.0-98-generic-x86_64 (vmlinuz-4.4.0-98-generic , initrd-4.4.0-98-generic)
    • libsqlite3-dev-3.11.0
    • meson-0.29
    • memtester-4.3.0-3
    • monodevelop, nunit-5.10.0.871-2
    • ninja-1.5.1
    • node-8.11.1
    • nodemon-1.18.4
    • npm-5.8.0, angular_cli-6.0.0
    • npm-6.4.1
    • obs-studio-20.1.0
    • opencv-3.4.3 (+ dependencias asociadas)
    • octave-4.0.0 (icono de Escritorio)
    • qemu-2.5.0
    • qtcreator
    • qt5-default
    • scratch-2-offline-i386
    • smartmontools-6.4
    • swift-3.1
    • sysbench-0.4.12
    • vim-gtk
    • vlc-2.2.2-5
    • xmpi-2.2.3b8-13.2

    Otros programas que por razones de insuficiente soporte gráfico (memoria y capacidad de procesamiento) y la falta de aceleración 3D de la máquina virtual, NO se incluyen son:

    • nvidia-cuda-toolkit
    • ROS Kinetic

    Particularidades de algunos programas:

    • google-chrome-stable-69.0.3497.100:  Al arrancar, nos pedirá con un cuadro un usuario y contraseña en un asunto relacionado con el almacén de claves de sesión. Pasa también en los laboratorios de la EPS. Dándole 3 veces a cancelar (pues saldrá hasta 3 veces), se soluciona y se puede continuar funcionando normalmente con el navegador.

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

    Básicamente, son los mismos que para el VDI del curso anterior:

    • Habilitar el bit de virtualización en la BIOS del equipo anfitrión
    • Configuración HW similar con estas particularidades:
      • Arranque sólo disco duro (ni red ni CD).
      • (2048 MB de RAM o, si se añade más, mejor)
      • Si utilizamos la versión 5.0 (o superior)  de VirtualBox , podremos habilitar soporte para USB 3.0 (xHCI) creando, en el apartado USB, un filtro vacío para admitir dispositivos USB 3.0.
    • Instalar Oracle VM VirtualBox Extension Pack (si no lo teníamos ya instalado en nuestra versión instalada de VirtualBox).
    • Instalar las Guest Additions en la máquina virtual para nuestra misma versión de VirtualBox que tengamos instalada (es decir, si el año pasado teníamos la 5.1.26 y este año tenemos la 5.1.38, deberíamos de instalar la de la 5.1.38). Esto ya se explicaba en este mismo apartado para el Virtual Ubuntu EPS 2017.

     

    Comments No Hay Comentarios »

    Tal com comentarem en una entrada anterior:

    Canviar l’idioma en Firefox Quantum

    En el navegador Firefox es podia canviar l’idioma de la interfície de l’usuari utilitzant l’ordre about:config en la barra d’adreces. La diferència és que les noves versions del Firefox ja no fan servir la mateixa preferència que abans. En versions anteriors s’usava general.useragent.locale, i ara hem de posar intl.locale.requested.

    about-config

    La forma de gestionar i configurar la nova preferència és la mateixa que s’explicava en l’anterior article. Si no existira, la podeu crear de la següent manera:

    • Feu clic amb el botó dret del ratolí en l’espai en blanc que hi ha on apareixen el noms de les preferències.
    • En el menú contextual que apareix, seleccioneu Nou i després el tipus de valor, en aquest cas Cadena.
    • Vos preguntarà el nom de la preferència. Escriviu: int.locale.requested
    • Després s’haurà d’omplir el valor de la cadena. Poseu-hi l’idioma que vulgueu usar. Per exemple, per al  valencià: ca-valencia
    • Accepteu i reinicieu el Firefox perquè s’aplique el nou idioma.

    Recordeu que l’idioma no canviarà si no teniu instal·lat el paquet d’idioma corresponent. En la següent adreça podeu trobar els diccionaris i paquets de la majoria d’idiomes:

    https://addons.mozilla.org/ca/firefox/language-tools/

    Podeu obtenir la variant valenciana des  d’aquest enllaç:

    https://www.softcatala.org/programes/paquet-catala-valencia-per-al-firefox/

    I recordeu, feu còpia de seguretat abans de tocar les configuracions.

    Comments No Hay Comentarios »

    Empezamos un nuevo curso en la Escuela Politécnica y, como siempre (aquí tenéis las entradas de otros cursos: I, II, III,IV, V y VI), os queremos recordar los datos importantes y necesarios para el uso y utilización de los eServices y, en especial, de las prácticas que realizáis en los laboratorios de la EPS.

    Sobre los laboratorios que gestionamos tenéis información en esta página: dónde está, su horario y ocupación, características hardware tienen, normas de uso, software instalado,…

    Durante la primera semana de septiembre hemos renovado los PCs de los laboratorios L13, L14, L15, L16 y L18. Estos nuevos PCs, como en el resto de laboratorios de la EPS, tienen instalado la versión de 64bits tanto de Ubuntu 16.04 como Windows 10, (excepto en la L03, cuyos equipos son iMac). Tanto los Windows como los Mac OS estarán “congelados”. ¿Qué significa esto y en qué te puede afectar? Aquí la respuesta.

    Para utilizar los eServices así como para acceder a los PCs de prácticas de los laboratorios necesitáis vuestro usuario y contraseña de la EPS, y éste NO ES el que habéis utilizado en el Campus Virtual para la matriculación en la UA. Si necesitáis ayuda, esta página os proporcionará más información sobre los usuarios de la EPS. Un detalle que queremos remarcar es que si usáis otro correo distinto al que os proporciona la UA (gmail, hotmail,…) tenéis la opción de redirigir el de la UA al que uséis ya que toda las comunicaciones institucionales se os enviarán a vuestro correo UA.

    Por último, queremos recordaros que tenéis disponible:

    Si tenéis dudas o consultas, podéis encontrar información para resolverlas y de contacto con los técnicos de la EPS aquí, además de poder usas nuestros canales en Facebook, Google +, nuestro canal Youtube, Twitter y, por supuesto, este blog.

    ¡Que tengáis buen curso!

    Comments No Hay Comentarios »

    Firefox

    Navegadors dels laboratoris

    Als laboratoris de l’Escola Politècnica Superior (EPS) se solen instal·lar per omissió els següents navegadors: Internet Explorer (a extingir), Edge i Firefox; també, quan ens ho demana algun professor, instal·lem el Google Chrome. Des del principi, es va decidir instal·lar cada un dels navegadors en una llengua diferent:

    • Castellà: Internet Explorer, Edge i Chrome.
    • Valencià: Mozilla Firefox*

    (*) Al Firefox, encara que l’idioma per omissió siga el valencià, es deixen instal·lats l’anglés, el castellà i el valencià.

    Abans del Firefox Quantum hi havia un complement anomenat Simple Locale Switcher que permetia canviar l’idioma de manera fàcil i ràpida, però a partir d’aquesta versió el complement ja no funciona i la llengua del navegador s’ha de canviar de forma manual.

    No compatible

     

    Canviar l’idioma manualment

    Per canviar l’idioma de forma manual seguirem els següents passos:

    • Obrim el Mozilla Firefox.
    • En la barra de direccions escrivim: about:config
    • Apareix una pàgina advertint-nos del perill que pot suposar canviar paràmetres.
    • Fem clic en el botó per acceptar el risc.
    • En el quadre “Cerca” escrivim: general.useragent.locale
    • Al tall que anem escrivint van filtrant-se les entrades que es mostren, fins que només queda la que volem.
    • Fem doble clic damunt de l’entrada i canviem el paràmetre ca-valencia per es (o en si el volem en anglés). Si heu instal·lat el Firefox en castellà i voleu posar-lo en valencià, simplement heu de fer el contrari, canviar es per ca-valencia o ca.
    • Reiniciem el Firefox i ja apareixerà en el nou idioma.

    about:config

     

    Instal·lar idiomes

    Evidentment, només podreu canviar a un idioma que tingueu instal·lat, açò és fàcil de fer. Des del FTP de Mozilla podeu descarregar els idiomes que vulgueu i instal·lar-los com si fora un complement més.

    L’adreça seria:

    https://ftp.mozilla.org/pub/firefox/releases/<versió>/<sistema operatiu>/xpi/

    Seguent:

    • <versió> la versió del Firefox que teniu. Es pot veure en Ajuda →Quant al Firefox
    • <sistema operatiu> el sistema operatiu que esteu fent servir, per exemple:
      • linux-x86_64 per a Gnu/Linux.
      • mac per al iOS.
      • win32 per al Windows de 32 bits.
      • win64 per al Windows de 64 bits.

    Per exemple, si volem descarregar els idiomes per a la versió 61.0 d’un Firefox instal·lat en un Ubuntu, escriurem:

    https://ftp.mozilla.org/pub/firefox/releases/61.0/linux-x86_64/xpi/

    De la llista d’arxius XPI que apareixen, triarem el corresponen a l’idioma desitjat, per exemple, si volem instal·lar l’anglés, farem clic sobre el fitxer en-GB.xpi, apareixerà un missatge demanant-vos permís per a instal·lar el programari:

    Idiomes del Firefox

    Fem clic en el botó Permet i a continuació s’ens adverteix de que s’instal·larà un complement en el Firefox:

    Afegir complement

    Si tot ha anat bé, apareixerà un missatge indicant-ho i ja tindrem l’idioma instal·lat.

    Si voleu diccionaris i paquets d’idioma aneu a la següent adreça:

    https://addons.mozilla.org/ca/firefox/language-tools/

    Podeu descarregar el Firefox en valencià des d’aquesta adreça:

    https://www.softcatala.org/programes/diccionari-valencia-firefox/

    Quan trobem un complement que faça aquesta tasca ja l’incorporarem a les noves instal·lacions del Firefox, de moment cal fer-ho a mà.
    I com sempre, recordar-vos que abans de canviar res heu de fer una còpia de seguretat, perquè mai se sap el que pot passar.

     

    Comments No Hay Comentarios »

    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.

    Lee el resto de esta entrada »

    Comments No Hay Comentarios »

    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.

    Lee el resto de esta entrada »

    Comments No Hay Comentarios »

    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!

    Comments 2 Comentarios »

    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.

    Lee el resto de esta entrada »

    Comments No Hay Comentarios »

    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 »