Tareas de administración y configuración mediante Roles de Sistema en RHEL

Red Hat Enterprise Linux 8

Aplicación de Roles de Sistema RHEL utilizando playbooks de Red Hat Ansible Automation Platform para realizar tareas de administración de sistemas

Resumen

Este documento describe la configuración de roles de sistema utilizando Ansible en Red Hat Enterprise Linux 8. El título se centra en: los Roles de Sistema RHEL son una colección de roles, módulos y playbooks de Ansible que proporcionan una interfaz de configuración estable y consistente para gestionar y configurar Red Hat Enterprise Linux. Están diseñados para ser compatibles con las principales versiones de Red Hat Enterprise Linux 8.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a sustituir el lenguaje problemático en nuestro código, documentación y propiedades web. Estamos empezando con estos cuatro términos: maestro, esclavo, lista negra y lista blanca. Debido a la enormidad de este esfuerzo, estos cambios se implementarán gradualmente a lo largo de varias versiones próximas. Para más detalles, consulte el mensaje de nuestro CTO Chris Wright.

Proporcionar comentarios sobre la documentación de Red Hat

Agradecemos su opinión sobre nuestra documentación. Por favor, díganos cómo podemos mejorarla. Para ello:

  • Para comentarios sencillos sobre pasajes concretos:

    1. Asegúrese de que está viendo la documentación en el formato Multi-page HTML. Además, asegúrese de ver el botón Feedback en la esquina superior derecha del documento.
    2. Utilice el cursor del ratón para resaltar la parte del texto que desea comentar.
    3. Haga clic en la ventana emergente Add Feedback que aparece debajo del texto resaltado.
    4. Siga las instrucciones mostradas.
  • Para enviar comentarios más complejos, cree un ticket de Bugzilla:

    1. Vaya al sitio web de Bugzilla.
    2. Como componente, utilice Documentation.
    3. Rellene el campo Description con su sugerencia de mejora. Incluya un enlace a la(s) parte(s) pertinente(s) de la documentación.
    4. Haga clic en Submit Bug.

Capítulo 1. Introducción a los roles de sistema de RHEL

En esta sección se explica qué son los roles de sistema de RHEL. Además, se describe cómo aplicar un rol particular a través de un playbook de Ansible para realizar varias tareas de administración del sistema.

1.1. Introducción a los roles del sistema RHEL

RHEL System Roles es una colección de roles y módulos de Ansible. RHEL System Roles proporciona una interfaz de configuración para gestionar de forma remota varios sistemas RHEL. La interfaz permite gestionar las configuraciones del sistema en varias versiones de RHEL, así como adoptar nuevas versiones principales.

En Red Hat Enterprise Linux 8, la interfaz consta actualmente de los siguientes roles:

  • kdump
  • red
  • selinux
  • almacenamiento
  • certificado
  • kernel_settings
  • registro
  • métrica
  • nbde_client y nbde_server
  • timesync
  • tlog

Todos estos roles son proporcionados por el paquete rhel-system-roles disponible en el repositorio AppStream.

Recursos adicionales

1.2. Terminología de los roles del sistema RHEL

Puede encontrar los siguientes términos en esta documentación:

Terminología de los roles del sistema

Libro de jugadas de Ansible
Los playbooks son el lenguaje de configuración, despliegue y orquestación de Ansible. Pueden describir una política que desea que sus sistemas remotos apliquen, o un conjunto de pasos en un proceso general de TI.
Nodo de control
Cualquier máquina con Ansible instalado. Puedes ejecutar comandos y playbooks, invocando /usr/bin/ansible o /usr/bin/ansible-playbook, desde cualquier nodo de control. Puedes usar cualquier ordenador que tenga Python instalado como nodo de control: ordenadores portátiles, escritorios compartidos y servidores pueden ejecutar Ansible. Sin embargo, no puedes usar una máquina Windows como nodo de control. Puedes tener varios nodos de control.
Inventario
Una lista de nodos gestionados. Un archivo de inventario también se llama a veces "archivo de host". Su inventario puede especificar información como la dirección IP para cada nodo gestionado. Un inventario también puede organizar los nodos gestionados, creando y anidando grupos para facilitar el escalado. Para obtener más información sobre el inventario, consulte la sección Trabajar con el inventario.
Nodos gestionados
Los dispositivos de red, servidores, o ambos, que gestionas con Ansible. Los nodos gestionados también se denominan a veces "hosts". Ansible no se instala en los nodos gestionados.

1.3. Aplicar un papel

El siguiente procedimiento describe cómo aplicar un rol particular.

Requisitos previos

  • El paquete rhel-system-roles está instalado en el sistema que se quiere utilizar como nodo de control:

    # yum install rhel-system-roles
  • El repositorio del motor Ansible está habilitado y el paquete ansible está instalado en el sistema que desea utilizar como nodo de control. Necesita el paquete ansible para ejecutar playbooks que utilicen RHEL System Roles.

    • Si no dispone de una suscripción a Red Hat Ansible Engine, puede utilizar una versión soportada limitada de Red Hat Ansible Engine proporcionada con su suscripción a Red Hat Enterprise Linux. En este caso, siga estos pasos:

      1. Habilite el repositorio del motor Ansible de RHEL:

        # subscription-manager refresh
        # subscription-manager repos --enable ansible-2-for-rhel-8-x86_64-rpms
      2. Instale el motor Ansible:

        # yum install ansible
    • Si tiene una suscripción a Red Hat Ansible Engine, siga el procedimiento descrito en ¿Cómo descargo e instalo Red Hat Ansible Engine?
  • Puedes crear un playbook de Ansible.

    Los playbooks representan el lenguaje de configuración, despliegue y orquestación de Ansible. Mediante el uso de playbooks, puedes declarar y gestionar configuraciones de máquinas remotas, desplegar múltiples máquinas remotas u orquestar pasos de cualquier proceso manual ordenado.

    Un playbook es una lista de uno o más plays. Cada play puede incluir variables, tareas o roles de Ansible.

    Los libros de jugadas son legibles para las personas y se expresan en el formato YAML.

    Para más información sobre los playbooks, consulte la documentación de Ansible.

Procedimiento

  1. Cree un playbook de Ansible que incluya el rol requerido.

    El siguiente ejemplo muestra cómo utilizar los roles a través de la opción roles: para un determinado play:

    ---
    - hosts: webservers
      roles:
         - rhel-system-roles.network
         - rhel-system-roles.timesync

    Para más información sobre el uso de roles en los playbooks, consulte la documentación de Ansible.

    Consulte los ejemplos de Ansible para ver ejemplos de playbooks.

    Nota

    Cada rol incluye un archivo README, que documenta cómo usar el rol y los valores de los parámetros soportados. También puede encontrar un ejemplo de libro de jugadas para un rol en particular en el directorio de documentación del rol. Este directorio de documentación se proporciona por defecto con el paquete rhel-system-roles, y se puede encontrar en la siguiente ubicación:

    /usr/share/doc/rhel-system-roles/SUBSYSTEM/

    Sustituya SUBSYSTEM por el nombre del rol requerido, como selinux, kdump, network, timesync, o storage.

  2. Verifique la sintaxis del libro de jugadas:

    # ansible-playbook --syntax-check name.of.the.playbook

    El comando ansible-playbook ofrece una opción --syntax-check que puede utilizar para verificar la sintaxis de un libro de jugadas.

  3. Ejecute el libro de jugadas en los hosts seleccionados ejecutando el comando ansible-playbook:

    # ansible-playbook -i name.of.the.inventory name.of.the.playbook

    Un inventario es una lista de sistemas con los que trabaja Ansible. Para más información sobre cómo crear un inventario y cómo trabajar con él, consulte la documentación de Ansible.

    Si no tiene un inventario, puede crearlo en el momento de ejecutar ansible-playbook:

    Si sólo tiene un host de destino contra el que desea ejecutar el libro de jugadas, utilice:

    # ansible-playbook -i host1, name.of.the.playbook

    Si tiene varios hosts de destino contra los que desea ejecutar el libro de jugadas, utilice:

    # ansible-playbook -i host1,host2,....,hostn name.of.the.playbook

Recursos adicionales

  • Para obtener información más detallada sobre el uso del comando ansible-playbook, consulte la página de manual ansible-playbook.

1.4. Recursos adicionales

Capítulo 2. Instalación de los roles del sistema RHEL

Antes de empezar a utilizar los Roles del Sistema, debe instalarlos en su sistema.

2.1. Instalación de RHEL System Roles en su sistema

Este párrafo es la introducción del módulo del procedimiento: una breve descripción del procedimiento.

Requisitos previos

Procedimiento

  1. Instale el paquete rhel-system-roles en el sistema que desea utilizar como nodo de control:

    # yum install rhel-system-roles

    Si no dispone de una suscripción a Red Hat Ansible Engine, puede utilizar una versión soportada limitada de Red Hat Ansible Engine proporcionada con su suscripción a Red Hat Enterprise Linux. En este caso, siga estos pasos:

    1. Habilite el repositorio del motor Ansible de RHEL:

      # subscription-manager refresh
      
      # subscription-manager repos --enable ansible-2-for-rhel-8-x86_64-rpms
    2. Instale el motor Ansible:

      # yum install ansible

Como resultado, puede crear un libro de jugadas de Ansible.

Recursos adicionales

  • Para obtener una visión general de las funciones del sistema RHEL, consulte las funciones del sistema Red Hat Enterprise Linux (RHEL)
  • Para obtener información más detallada sobre el uso del comando ansible-playbook, consulte la página man de ansible-playbook.

Capítulo 3. Uso de los roles de Ansible para configurar permanentemente los parámetros del kernel

Como usuario experimentado con buenos conocimientos de Red Hat Ansible Engine, puede utilizar el rol kernel_settings para configurar los parámetros del kernel en varios clientes a la vez. Esta solución:

  • Ofrece una interfaz amigable con una configuración de entrada eficiente.
  • Mantiene todos los parámetros del kernel previstos en un solo lugar.

Después de ejecutar el rol kernel_settings desde la máquina de control, los parámetros del kernel se aplican a los sistemas gestionados inmediatamente y persisten a través de los reinicios.

3.1. Introducción a la función de configuración del núcleo

RHEL System Roles es una colección de roles y módulos de Ansible Automation Platform que proporcionan una interfaz de configuración consistente para gestionar remotamente múltiples sistemas.

Los roles de sistema de RHEL se introdujeron para las configuraciones automatizadas del kernel utilizando el rol de sistema kernel_settings. El paquete rhel-system-roles contiene este rol de sistema, así como la documentación de referencia.

Para aplicar los parámetros del kernel en uno o más sistemas de forma automatizada, utilice el rol kernel_settings con una o más de sus variables de rol de su elección en un playbook. Un libro de jugadas es una lista de una o más jugadas que son legibles para los humanos, y están escritas en el formato YAML.

Puede utilizar un archivo de inventario para definir un conjunto de sistemas que desea que el motor Ansible configure de acuerdo con el libro de jugadas.

Con el rol kernel_settings se puede configurar:

  • Los parámetros del núcleo utilizando la variable de rol kernel_settings_sysctl
  • Varios subsistemas del kernel, dispositivos de hardware y controladores de dispositivos que utilizan la variable de rol kernel_settings_sysfs
  • La afinidad de la CPU para el gestor de servicios systemd y los procesos que bifurca utilizando la variable de rol kernel_settings_systemd_cpu_affinity
  • El subsistema de memoria del kernel transparente hugepages utilizando las variables de rol kernel_settings_transparent_hugepages y kernel_settings_transparent_hugepages_defrag

Recursos adicionales

  • Para una referencia detallada sobre las variables de rol de kernel_settings y para los playbooks de ejemplo, instale el paquete rhel-system-roles, y vea los archivos README.md y README.html en el directorio /usr/share/doc/rhel-system-roles/kernel_settings/.
  • Para más información sobre los playbooks, consulte Trabajar con playbooks en la documentación de Ansible.
  • Para obtener más información sobre la creación y el uso de inventarios, consulte Cómo crear su inventario en la documentación de Ansible.

3.2. Aplicación de los parámetros del núcleo seleccionados mediante la función de configuración del núcleo

Siga estos pasos para preparar y aplicar un playbook de Ansible para configurar remotamente los parámetros del kernel con efecto persistente en varios sistemas operativos gestionados.

Requisitos previos

  • Su suscripción a Red Hat Ansible Engine está adjunta al sistema, también llamado control machine, desde el cual desea ejecutar el rol kernel_settings. Consulte el artículo Cómo descargar e instalar Red Hat Ansible Engine para obtener más información.
  • El repositorio del motor Ansible está habilitado en la máquina de control.
  • El motor Ansible está instalado en la máquina de control.

    Nota

    No es necesario tener instalado el motor de Ansible en los sistemas, también llamados managed hosts, en los que se desea configurar los parámetros del kernel.

  • El paquete rhel-system-roles está instalado en la máquina de control.
  • En la máquina de control hay un inventario de hosts gestionados y el motor Ansible puede conectarse a ellos.

Procedimiento

  1. Opcionalmente, revise el archivo inventory a modo de ilustración:

    #  cat /home/jdoe/<ansible_project_name>/inventory
    [testingservers]
    pdoe@192.168.122.98
    fdoe@192.168.122.226
    
    [db-servers]
    db1.example.com
    db2.example.com
    
    [webservers]
    web1.example.com
    web2.example.com
    192.0.2.42

    El archivo define el grupo [testingservers] y otros grupos. Permite ejecutar el motor Ansible de forma más eficaz contra un conjunto específico de sistemas.

  2. Crear un archivo de configuración para establecer los valores predeterminados y la escalada de privilegios para las operaciones del motor Ansible.

    1. Cree un nuevo archivo YAML y ábralo en un editor de texto, por ejemplo:

      #  vi /home/jdoe/<ansible_project_name>/ansible.cfg
    2. Inserte el siguiente contenido en el archivo:

      [defaults]
      inventory = ./inventory
      
      [privilege_escalation]
      become = true
      become_method = sudo
      become_user = root
      become_ask_pass = true

      La sección [defaults] especifica una ruta al archivo de inventario de los hosts gestionados. La sección [privilege_escalation] define que los privilegios de usuario sean cambiados a root en los hosts administrados especificados. Esto es necesario para la configuración exitosa de los parámetros del kernel. Cuando se ejecute el playbook de Ansible, se le pedirá la contraseña del usuario. El usuario cambia automáticamente a root mediante sudo después de conectarse a un host gestionado.

  3. Cree un libro de jugadas de Ansible que utilice el rol kernel_settings.

    1. Cree un nuevo archivo YAML y ábralo en un editor de texto, por ejemplo:

      #  vi /home/jdoe/<ansible_project_name>/kernel_roles.yml

      Este archivo representa un libro de jugadas y normalmente contiene una lista ordenada de tareas, también llamadas plays, que se ejecutan contra hosts gestionados específicos seleccionados de su archivo inventory.

    2. Inserte el siguiente contenido en el archivo:

      ---
      - name: Configure kernel settings
        hosts: testingservers
      
        vars:
          kernel_settings_sysctl:
            - name: fs.file-max
              value: 400000
            - name: kernel.threads-max
              value: 65536
          kernel_settings_sysfs:
            - name: /sys/class/net/lo/mtu
              value: 65000
          kernel_settings_transparent_hugepages: madvise
      
        roles:
          - linux-system-roles.kernel_settings

      La clave name es opcional. Asocia una cadena arbitraria a la obra como etiqueta e identifica para qué sirve la obra. La clave hosts en la obra especifica los hosts contra los que se ejecuta la obra. El valor o los valores de esta clave pueden proporcionarse como nombres individuales de hosts gestionados o como grupos de hosts definidos en el archivo inventory.

      La sección vars representa una lista de variables que contienen los nombres de los parámetros del núcleo seleccionados y los valores a los que deben ajustarse.

      La clave roles especifica qué rol del sistema va a configurar los parámetros y valores mencionados en la sección vars.

      Nota

      Puede modificar los parámetros del núcleo y sus valores en el libro de jugadas para adaptarlos a sus necesidades.

  4. Opcionalmente, verifique que la sintaxis de su obra es correcta.

    #  ansible-playbook --syntax-check kernel-roles.yml
    
    playbook: kernel-roles.yml

    Este ejemplo muestra la verificación exitosa de un libro de jugadas.

  5. Ejecuta tu libro de jugadas.

    #  ansible-playbook kernel-roles.yml
    BECOME password:
    
    PLAY [Configure kernel settings]  ... PLAY RECAP **
    fdoe@192.168.122.226       : ok=10   changed=4    unreachable=0    failed=0    skipped=6    rescued=0    ignored=0
    pdoe@192.168.122.98        : ok=10   changed=4    unreachable=0    failed=0    skipped=6    rescued=0    ignored=0

    Antes de que el motor de Ansible ejecute su libro de jugadas, se le pedirá su contraseña y para que un usuario en los hosts administrados pueda ser cambiado a root, lo cual es necesario para configurar los parámetros del kernel.

    La sección de recapitulación muestra que la reproducción ha finalizado con éxito (failed=0) para todos los hosts gestionados, y que se han aplicado 4 parámetros del kernel (changed=4).

  6. Reinicie sus hosts gestionados y compruebe los parámetros del kernel afectados para verificar que los cambios se han aplicado y persisten a través de los reinicios.

Recursos adicionales

  • Para obtener más información sobre las funciones del sistema RHEL, consulte Introducción a las funciones del sistema RHEL.
  • Para más información sobre todas las variables actualmente soportadas en kernel_settings, consulte los archivos README.html y README.md en el directorio /usr/share/doc/rhel-system-roles/kernel_settings/.
  • Para más detalles sobre los inventarios de Ansible, consulte la documentación sobre el trabajo con el inventario en Ansible.
  • Para más detalles sobre los archivos de configuración de Ansible, consulte Configuración de Ansible en la documentación de Ansible.
  • Para más detalles sobre los playbooks de Ansible, consulte Trabajar con playbooks en la documentación de Ansible.
  • Para más detalles sobre las variables de Ansible, consulte la documentación sobre el uso de variables en Ansible.
  • Para más detalles sobre los roles de Ansible, consulte la documentación de Roles en Ansible.

Capítulo 4. Uso de los roles del sistema para configurar las conexiones de red

El rol de sistema network en RHEL permite a los administradores automatizar las tareas de configuración y gestión relacionadas con la red utilizando Ansible.

4.1. Configurar una conexión Ethernet

Esta sección describe diferentes formas de configurar una conexión Ethernet con direcciones IP estáticas y dinámicas.

4.1.1. Configuración de una conexión Ethernet estática mediante RHEL System Roles

Este procedimiento describe cómo utilizar los roles del sistema RHEL para añadir de forma remota una conexión Ethernet para la interfaz enp7s0 con la siguiente configuración mediante la ejecución de un libro de jugadas de Ansible:

  • Una dirección IPv4 estática - 192.0.2.1 con una máscara de subred /24
  • Una dirección IPv6 estática - 2001:db8:1::1 con una máscara de subred /64
  • Una pasarela por defecto IPv4 - 192.0.2.254
  • Una pasarela por defecto IPv6 - 2001:db8:1::fffe
  • Un servidor DNS IPv4 - 192.0.2.200
  • Un servidor DNS IPv6 - 2001:db8:1::ffbb
  • Un dominio de búsqueda DNS - example.com

Ejecute este procedimiento en el nodo de control de Ansible.

Requisitos previos

  • Los paquetes ansible y rhel-system-roles se instalan en el nodo de control.
  • Si utiliza un usuario remoto diferente a root cuando ejecuta el libro de jugadas, este usuario tiene los permisos apropiados de sudo en el nodo gestionado.
  • El host utiliza NetworkManager para configurar la red.

Procedimiento

  1. Si el host en el que desea ejecutar las instrucciones del libro de jugadas aún no está inventariado, añada la IP o el nombre de este host al archivo de inventario de Ansible /etc/ansible/hosts:

    node.example.com
  2. Cree el libro de jugadas ~/ethernet-static-IP.yml con el siguiente contenido:

    ---
    - name: Configure an Ethernet connection with static IP
      hosts: node.example.com
      become: true
      tasks:
      - include_role:
          name: linux-system-roles.network
    
        vars:
          network_connections:
            - name: enp7s0
              type: ethernet
              autoconnect: yes
              ip:
                address:
                  - 192.0.2.1/24
                  - 2001:db8:1::1/64
                gateway4: 192.0.2.254
                gateway6: 2001:db8:1::fffe
                dns:
                  - 192.0.2.200
                  - 2001:db8:1::ffbb
                dns_search:
                  - example.com
              state: up
  3. Ejecuta el libro de jugadas:

    • Para conectarse como usuario de root al host gestionado, introduzca:

      # ansible-playbook -u root ~/ethernet-static-IP.yml
    • Para conectarse como usuario al host gestionado, introduzca:

      # ansible-playbook -u user_name --ask-become-pass ~/ethernet-static-IP.yml

      La opción --ask-become-pass asegura que el comando ansible-playbook solicite la contraseña sudo del usuario definido en la opción -u user_name opción.

    Si no se especifica la opción -u user_name ansible-playbook se conecta al host gestionado como el usuario que ha iniciado la sesión en el nodo de control.

Recursos adicionales

  • Para obtener detalles sobre los parámetros utilizados en network_connections y para obtener información adicional sobre el rol del sistema network, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.network/README.md.
  • Para obtener más información sobre el comando ansible-playbook, consulte la página de manual ansible-playbook(1).

4.1.2. Configuración de una conexión Ethernet dinámica mediante RHEL System Roles

Este procedimiento describe cómo utilizar RHEL System Roles para añadir remotamente una conexión Ethernet dinámica para la interfaz enp7s0 ejecutando un playbook de Ansible. Con esta configuración, la conexión de red solicita la configuración IP para esta conexión a un servidor DHCP. Ejecute este procedimiento en el nodo de control de Ansible.

Requisitos previos

  • Hay un servidor DHCP disponible en la red.
  • Los paquetes ansible y rhel-system-roles se instalan en el nodo de control.
  • Si utiliza un usuario remoto diferente a root cuando ejecuta el libro de jugadas, este usuario tiene los permisos apropiados de sudo en el nodo gestionado.
  • El host utiliza NetworkManager para configurar la red.

Procedimiento

  1. Si el host en el que desea ejecutar las instrucciones del libro de jugadas aún no está inventariado, añada la IP o el nombre de este host al archivo de inventario de Ansible /etc/ansible/hosts:

    node.example.com
  2. Cree el libro de jugadas ~/ethernet-dynamic-IP.yml con el siguiente contenido:

    ---
    - name: Configure an Ethernet connection with dynamic IP
      hosts: node.example.com
      become: true
      tasks:
      - include_role:
          name: linux-system-roles.network
    
        vars:
          network_connections:
            - name: enp7s0
              type: ethernet
              autoconnect: yes
              ip:
                dhcp4: yes
                auto6: yes
              state: up
  3. Ejecuta el libro de jugadas:

    • Para conectarse como usuario de root al host gestionado, introduzca:

      # ansible-playbook -u root ~/ethernet-dynamic-IP.yml
    • Para conectarse como usuario al host gestionado, introduzca:

      # ansible-playbook -u user_name --ask-become-pass ~/ethernet-dynamic-IP.yml

      La opción --ask-become-pass asegura que el comando ansible-playbook pida la contraseña sudo del usuario definido en la opción -u user_name opción.

    Si no se especifica la opción -u user_name ansible-playbook se conecta al host gestionado como el usuario que ha iniciado la sesión en el nodo de control.

Recursos adicionales

  • Para obtener detalles sobre los parámetros utilizados en network_connections y para obtener información adicional sobre el rol del sistema network, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.network/README.md.
  • Para obtener más información sobre el comando ansible-playbook, consulte la página de manual ansible-playbook(1).

4.2. Configuración del etiquetado VLAN

Esta sección describe cómo configurar una red de área local virtual (VLAN). Una VLAN es una red lógica dentro de una red física. La interfaz VLAN etiqueta los paquetes con el ID de la VLAN cuando pasan por la interfaz, y elimina las etiquetas de los paquetes que vuelven.

Se crea una interfaz VLAN sobre otra interfaz, como un dispositivo Ethernet, bond, team o bridge. Esta interfaz se denomina parent interface.

4.2.1. Configurar el etiquetado de VLANs mediante los roles del sistema

Puede utilizar el rol de sistema networking RHEL para configurar el etiquetado de VLAN. Este procedimiento describe cómo añadir una conexión Ethernet y una VLAN con ID 10 que utiliza esta conexión Ethernet. Como dispositivo principal, la conexión VLAN contiene las configuraciones de IP, puerta de enlace predeterminada y DNS.

Dependiendo de su entorno, ajuste la obra en consecuencia. Por ejemplo:

  • Para utilizar la VLAN como un puerto en otras conexiones, como un enlace, omita el atributo ip y establezca la configuración IP en la configuración principal.
  • Para utilizar dispositivos de equipo, puente o enlace en la VLAN, adapte los atributos interface_name y type de los puertos que utilice en la VLAN.

Requisitos previos

  • Los paquetes ansible y rhel-system-roles se instalan en el nodo de control.
  • Si utiliza un usuario remoto diferente a root cuando ejecuta el libro de jugadas, este usuario tiene los permisos apropiados de sudo en el nodo gestionado.

Procedimiento

  1. Si el host en el que desea ejecutar las instrucciones del libro de jugadas aún no está inventariado, añada la IP o el nombre de este host al archivo de inventario de Ansible /etc/ansible/hosts:

    node.example.com
  2. Cree el libro de jugadas ~/vlan-ethernet.yml con el siguiente contenido:

    ---
    - name: Configure a VLAN that uses an Ethernet connection
      hosts: node.example.com
      become: true
      tasks:
      - include_role:
          name: linux-system-roles.network
    
        vars:
          network_connections:
            # Add an Ethernet profile for the underlying device of the VLAN
            - name: enp1s0
              type: ethernet
    	  interface_name: enp1s0
    	  autoconnect: yes
              state: up
    	  ip:
    	    dhcp4: no
    	    auto6: no
    
            # Define the VLAN profile
            - name: vlan10
              type: vlan
              ip:
                address:
                  - "192.0.2.1/24"
                  - "2001:db8:1::1/64"
                gateway4: 192.0.2.254
                gateway6: 2001:db8:1::fffe
                dns:
                  - 192.0.2.200
                  - 2001:db8:1::ffbb
                dns_search:
                  - example.com
              vlan_id: 10
    	  parent: enp1s0
              state: up

    El atributo parent del perfil VLAN configura la VLAN para que funcione sobre el dispositivo enp1s0.

  3. Ejecuta el libro de jugadas:

    • Para conectarse como usuario de root al host gestionado, introduzca:

      # ansible-playbook -u root ~/vlan-ethernet.yml
    • Para conectarse como usuario al host gestionado, introduzca:

      # ansible-playbook -u user_name --ask-become-pass ~/vlan-ethernet.yml

      La opción --ask-become-pass asegura que el comando ansible-playbook solicite la contraseña sudo del usuario definido en la opción -u user_name opción.

    Si no se especifica la opción -u user_name ansible-playbook se conecta al host gestionado como el usuario que ha iniciado la sesión en el nodo de control.

Recursos adicionales

  • Para obtener detalles sobre los parámetros utilizados en network_connections y para obtener información adicional sobre el rol del sistema network, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.network/README.md.
  • Para obtener más información sobre el comando ansible-playbook, consulte la página de manual ansible-playbook(1).

4.3. Configurar un puente de red

Un puente de red es un dispositivo de capa de enlace que reenvía el tráfico entre redes basándose en una tabla de direcciones MAC. El puente construye la tabla de direcciones MAC escuchando el tráfico de la red y aprendiendo así qué hosts están conectados a cada red. Por ejemplo, puede utilizar un puente de software en un host Red Hat Enterprise Linux 8 para emular un puente de hardware o en entornos de virtualización, para integrar máquinas virtuales (VM) a la misma red que el host.

Un puente requiere un dispositivo de red en cada red que el puente deba conectar. Cuando se configura un puente, éste se llama controller y los dispositivos que utiliza ports.

Puedes crear puentes en diferentes tipos de dispositivos, como:

  • Dispositivos Ethernet físicos y virtuales
  • Bonos de red
  • Equipos de la red
  • Dispositivos VLAN

Debido al estándar IEEE 802.11 que especifica el uso de tramas de 3 direcciones en Wi-Fi para el uso eficiente del tiempo de aire, no se puede configurar un puente sobre redes Wi-Fi que operen en modo Ad-Hoc o Infraestructura.

4.3.1. Configuración de un puente de red con RHEL System Roles

Puede utilizar el rol de sistema networking RHEL para configurar un puente Linux. Este procedimiento describe cómo configurar un puente de red que utiliza dos dispositivos Ethernet, y establece las direcciones IPv4 e IPv6, las puertas de enlace predeterminadas y la configuración de DNS.

Nota

Establezca la configuración IP en el puente y no en los puertos del puente Linux.

Requisitos previos

  • Los paquetes ansible y rhel-system-roles se instalan en el nodo de control.
  • Si utiliza un usuario remoto diferente a root cuando ejecuta el libro de jugadas, este usuario tiene los permisos apropiados de sudo en el nodo gestionado.
  • Dos o más dispositivos de red físicos o virtuales están instalados en el servidor.

Procedimiento

  1. Si el host en el que desea ejecutar las instrucciones del libro de jugadas aún no está inventariado, añada la IP o el nombre de este host al archivo de inventario de Ansible /etc/ansible/hosts:

    node.example.com
  2. Cree el libro de jugadas ~/bridge-ethernet.yml con el siguiente contenido:

    ---
    - name: Configure a network bridge that uses two Ethernet ports
      hosts: node.example.com
      become: true
      tasks:
      - include_role:
          name: linux-system-roles.network
    
        vars:
          network_connections:
            # Define the bridge profile
            - name: bridge0
              type: bridge
              interface_name: bridge0
              ip:
                address:
                  - "192.0.2.1/24"
                  - "2001:db8:1::1/64"
                gateway4: 192.0.2.254
                gateway6: 2001:db8:1::fffe
                dns:
                  - 192.0.2.200
                  - 2001:db8:1::ffbb
                dns_search:
                  - example.com
              state: up
    
            # Add an Ethernet profile to the bridge
            - name: bridge0-port1
              interface_name: enp7s0
              type: ethernet
              master: bridge0
              slave_type: bridge
              state: up
    
            # Add a second Ethernet profile to the bridge
            - name: bridge0-port2
              interface_name: enp8s0
              type: ethernet
              master: bridge0
              slave_type: bridge
              state: up
  3. Ejecuta el libro de jugadas:

    • Para conectarse como usuario de root al host gestionado, introduzca:

      # ansible-playbook -u root ~/bridge-ethernet.yml
    • Para conectarse como usuario al host gestionado, introduzca:

      # ansible-playbook -u user_name --ask-become-pass ~/bridge-ethernet.yml

      La opción --ask-become-pass asegura que el comando ansible-playbook solicite la contraseña sudo del usuario definido en la opción -u user_name opción.

    Si no se especifica la opción -u user_name ansible-playbook se conecta al host gestionado como el usuario que ha iniciado la sesión en el nodo de control.

Recursos adicionales

  • Para obtener detalles sobre los parámetros utilizados en network_connections y para obtener información adicional sobre el rol del sistema network, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.network/README.md.
  • Para obtener más información sobre el comando ansible-playbook, consulte la página de manual ansible-playbook(1).

4.4. Configuración de la unión de redes

Esta sección describe los fundamentos de la vinculación de redes, las diferencias entre vinculación y teaming y cómo configurar una vinculación de redes en Red Hat Enterprise Linux 8.

Puedes crear bonos en diferentes tipos de dispositivos, como:

  • Dispositivos Ethernet físicos y virtuales
  • Puentes de red
  • Equipos de la red
  • Dispositivos VLAN

4.4.1. Configuración de un enlace de red usando RHEL System Roles

Puede utilizar el rol de sistema network RHEL para configurar un enlace de red. Este procedimiento describe cómo configurar un enlace en modo de respaldo activo que utiliza dos dispositivos Ethernet, y establece una dirección IPv4 e IPv6, puertas de enlace predeterminadas y la configuración de DNS.

Nota

Establezca la configuración IP en el puente y no en los puertos del puente Linux.

Requisitos previos

  • Los paquetes ansible y rhel-system-roles se instalan en el nodo de control.
  • Si utiliza un usuario remoto diferente a root cuando ejecuta el libro de jugadas, este usuario tiene los permisos apropiados de sudo en el nodo gestionado.
  • Dos o más dispositivos de red físicos o virtuales están instalados en el servidor.

Procedimiento

  1. Si el host en el que desea ejecutar las instrucciones del libro de jugadas aún no está inventariado, añada la IP o el nombre de este host al archivo de inventario de Ansible /etc/ansible/hosts:

    node.example.com
  2. Cree el libro de jugadas ~/bond-ethernet.yml con el siguiente contenido:

    ---
    - name: Configure a network bond that uses two Ethernet ports
      hosts: node.example.com
      become: true
      tasks:
      - include_role:
          name: linux-system-roles.network
    
        vars:
          network_connections:
            # Define the bond profile
            - name: bond0
              type: bond
              interface_name: bond0
              ip:
                address:
                  - "192.0.2.1/24"
                  - "2001:db8:1::1/64"
                gateway4: 192.0.2.254
                gateway6: 2001:db8:1::fffe
                dns:
                  - 192.0.2.200
                  - 2001:db8:1::ffbb
                dns_search:
                  - example.com
              bond:
                mode: active-backup
              state: up
    
            # Add an Ethernet profile to the bond
            - name: bond0-port1
              interface_name: enp7s0
              type: ethernet
              master: bond0
              state: up
    
            # Add a second Ethernet profile to the bond
            - name: bond0-port2
              interface_name: enp8s0
              type: ethernet
              master: bond0
              state: up
  3. Ejecuta el libro de jugadas:

    • Para conectarse como usuario de root al host gestionado, introduzca:

      # ansible-playbook -u root ~/bond-ethernet.yml
    • Para conectarse como usuario al host gestionado, introduzca:

      # ansible-playbook -u user_name --ask-become-pass ~/bond-ethernet.yml

      La opción --ask-become-pass asegura que el comando ansible-playbook solicite la contraseña sudo del usuario definido en la opción -u user_name opción.

    Si no se especifica la opción -u user_name ansible-playbook se conecta al host gestionado como el usuario que ha iniciado la sesión en el nodo de control.

Recursos adicionales

  • Para obtener detalles sobre los parámetros utilizados en network_connections y para obtener información adicional sobre el rol del sistema network, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.network/README.md.
  • Para obtener más información sobre el comando ansible-playbook, consulte la página de manual ansible-playbook(1).

4.5. Autenticación de un cliente RHEL en la red mediante el estándar 802.1X

Los administradores utilizan con frecuencia el Control de Acceso a la Red (NAC) basado en el estándar IEEE 802.1X para proteger una red de clientes LAN y Wi-Fi no autorizados. Los procedimientos de esta sección describen diferentes opciones para configurar la autenticación de la red.

4.5.1. Configuración de una conexión Ethernet estática con autenticación de red 802.1X mediante RHEL System Roles

Utilizando RHEL System Roles, puede automatizar la creación de una conexión Ethernet que utilice el estándar 802.1X para autenticar al cliente. Este procedimiento describe cómo añadir remotamente una conexión Ethernet para la interfaz enp1s0 con la siguiente configuración mediante la ejecución de un playbook de Ansible:

  • Una dirección IPv4 estática - 192.0.2.1 con una máscara de subred /24
  • Una dirección IPv6 estática - 2001:db8:1::1 con una máscara de subred /64
  • Una pasarela por defecto IPv4 - 192.0.2.254
  • Una pasarela por defecto IPv6 - 2001:db8:1::fffe
  • Un servidor DNS IPv4 - 192.0.2.200
  • Un servidor DNS IPv6 - 2001:db8:1::ffbb
  • Un dominio de búsqueda DNS - example.com
  • 802.Autenticación de red 1X mediante el protocolo de autenticación extensible (EAP) TLS

Ejecute este procedimiento en el nodo de control de Ansible.

Requisitos previos

  • Los paquetes ansible y rhel-system-roles se instalan en el nodo de control.
  • Si utiliza un usuario remoto diferente a root cuando ejecute el libro de jugadas, debe tener los permisos apropiados de sudo en el nodo gestionado.
  • La red es compatible con la autenticación de red 802.1X.
  • El nodo gestionado utiliza NetworkManager.
  • Los siguientes archivos necesarios para la autenticación TLS existen en el nodo de control:

    • La clave del cliente almacenada en el archivo /srv/data/client.key.
    • El certificado del cliente almacenado en el archivo /srv/data/client.crt.
    • El certificado de la Autoridad de Certificación (CA) almacenado en el archivo /srv/data/ca.crt.

Procedimiento

  1. Si el host en el que desea ejecutar las instrucciones del libro de jugadas aún no está inventariado, añada la IP o el nombre de este host al archivo de inventario de Ansible /etc/ansible/hosts:

    node.example.com
  2. Cree el libro de jugadas ~/enable-802.1x.yml con el siguiente contenido:

    ---
    - name: Configure an Ethernet connection with 802.1X authentication
      hosts: node.example.com
      become: true
      tasks:
        - name: Copy client key for 802.1X authentication
          copy:
            src: "/srv/data/client.key"
            dest: "/etc/pki/tls/private/client.key"
            mode: 0600
    
        - name: Copy client certificate for 802.1X authentication
          copy:
            src: "/srv/data/client.crt"
            dest: "/etc/pki/tls/certs/client.crt"
    
        - name: Copy CA certificate for 802.1X authentication
          copy:
            src: "/srv/data/ca.crt"
            dest: "/etc/pki/ca-trust/source/anchors/ca.crt"
    
        - include_role:
            name: linux-system-roles.network
          vars:
            network_connections:
              - name: enp1s0
                type: ethernet
                autoconnect: yes
                ip:
                  address:
                    - 192.0.2.1/24
                    - 2001:db8:1::1/64
                  gateway4: 192.0.2.254
                  gateway6: 2001:db8:1::fffe
                  dns:
                    - 192.0.2.200
                    - 2001:db8:1::ffbb
                  dns_search:
                    - example.com
                ieee802_1x:
                  identity: user_name
                  eap: tls
                  private_key: "/etc/pki/tls/private/client.key"
                  private_key_password: "password"
                  client_cert: "/etc/pki/tls/certs/client.crt"
                  ca_cert: "/etc/pki/ca-trust/source/anchors/ca.crt"
                  domain_suffix_match: example.com
                state: up
  3. Ejecuta el libro de jugadas:

    • Para conectarse como usuario de root al host gestionado, introduzca:

      # ansible-playbook -u root ~/enable-802.1x.yml
    • Para conectarse como usuario al host gestionado, introduzca:

      # ansible-playbook -u user_name --ask-become-pass ~/ethernet-static-IP.yml

      La opción --ask-become-pass asegura que el comando ansible-playbook solicite la contraseña sudo del usuario definido en la opción -u user_name opción.

    Si no se especifica la opción -u user_name ansible-playbook se conecta al host gestionado como el usuario que ha iniciado la sesión en el nodo de control.

Recursos adicionales

  • Para obtener detalles sobre los parámetros utilizados en network_connections y para obtener información adicional sobre el rol del sistema network, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.network/README.md.
  • Para más detalles sobre los parámetros 802.1X, consulte la sección ieee802_1x en el archivo /usr/share/ansible/roles/rhel-system-roles.network/README.md.
  • Para obtener más información sobre el comando ansible-playbook, consulte la página de manual ansible-playbook(1).

4.6. Gestión de la configuración de la pasarela por defecto

La pasarela por defecto es un router que reenvía los paquetes de red cuando ninguna otra ruta coincide con el destino de un paquete. En una red local, la pasarela por defecto suele ser el host que está un salto más cerca de Internet.

4.6.1. Configuración de la puerta de enlace predeterminada en una conexión existente mediante las funciones del sistema

Puede utilizar la función del sistema networking RHEL para establecer la puerta de enlace predeterminada.

Importante

Cuando se ejecuta una obra que utiliza el rol de sistema networking RHEL, el rol de sistema anula un perfil de conexión existente con el mismo nombre si la configuración no coincide con la especificada en la obra. Por lo tanto, especifique siempre toda la configuración del perfil de conexión de red en la obra, incluso si, por ejemplo, la configuración de IP ya existe. De lo contrario, la función restablece estos valores a sus valores por defecto.

Dependiendo de si ya existe, el procedimiento crea o actualiza el perfil de conexión enp1s0 con la siguiente configuración:

  • Una dirección IPv4 estática - 198.51.100.20 con una máscara de subred /24
  • Una dirección IPv6 estática - 2001:db8:1::1 con una máscara de subred /64
  • Una pasarela por defecto IPv4 - 198.51.100.254
  • Una pasarela por defecto IPv6 - 2001:db8:1::fffe
  • Un servidor DNS IPv4 - 198.51.100.200
  • Un servidor DNS IPv6 - 2001:db8:1::ffbb
  • Un dominio de búsqueda DNS - example.com

Requisitos previos

  • Los paquetes ansible y rhel-system-roles se instalan en el nodo de control.
  • Si utiliza un usuario remoto diferente a root cuando ejecuta el libro de jugadas, este usuario tiene los permisos apropiados de sudo en el nodo gestionado.

Procedimiento

  1. Si el host en el que desea ejecutar las instrucciones del libro de jugadas aún no está inventariado, añada la IP o el nombre de este host al archivo de inventario de Ansible /etc/ansible/hosts:

    nodo.ejemplo.com
  2. Cree el libro de jugadas ~/ethernet-connection.yml con el siguiente contenido:

    ---
    - name: Configure an Ethernet connection with static IP and default gateway
      hosts: node.example.com
      become: true
      tasks:
      - include_role:
          name: linux-system-roles.network
    
        vars:
          network_connections:
            - name: enp1s0
              type: ethernet
              autoconnect: yes
              ip:
                address:
                  - 198.51.100.20/24
                  - 2001:db8:1::1/64
                gateway4: 198.51.100.254
                gateway6: 2001:db8:1::fffe
                dns:
                  - 198.51.100.200
                  - 2001:db8:1::ffbb
                dns_search:
                  - example.com
              state: up
  3. Ejecuta el libro de jugadas:

    • Para conectarse como usuario de root al host gestionado, introduzca:

      # ansible-playbook -u root ~/ethernet-connection.yml
    • Para conectarse como usuario al host gestionado, introduzca:

      # ansible-playbook -u user_name --ask-become-pass ~/ethernet-connection.yml

      La opción --ask-become-pass asegura que el comando ansible-playbook solicite la contraseña sudo del usuario definido en la opción -u user_name opción.

    Si no se especifica la opción -u user_name ansible-playbook se conecta al host gestionado como el usuario que ha iniciado la sesión en el nodo de control.

Recursos adicionales

  • Para obtener detalles sobre los parámetros utilizados en network_connections y para obtener información adicional sobre el rol del sistema network, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.network/README.md.
  • Para obtener más información sobre el comando ansible-playbook, consulte la página de manual ansible-playbook(1).

4.7. Configuración de rutas estáticas

Por defecto, y si se configura una puerta de enlace por defecto, Red Hat Enterprise Linux reenvía el tráfico para las redes que no están directamente conectadas al host a la puerta de enlace por defecto. Usando una ruta estática, puede configurar que Red Hat Enterprise Linux reenvíe el tráfico para un host o red específica a un enrutador diferente a la puerta de enlace por defecto. Esta sección describe diferentes opciones de cómo configurar rutas estáticas.

4.7.1. Configuración de una ruta estática mediante RHEL System Roles

Puede utilizar el rol de sistema networking RHEL para configurar rutas estáticas.

Importante

Cuando se ejecuta una obra que utiliza el rol de sistema networking RHEL, el rol de sistema anula un perfil de conexión existente con el mismo nombre si la configuración no coincide con la especificada en la obra. Por lo tanto, especifique siempre toda la configuración del perfil de conexión de red en la obra, incluso si, por ejemplo, la configuración de IP ya existe. De lo contrario, la función restablece estos valores a sus valores por defecto.

Dependiendo de si ya existe, el procedimiento crea o actualiza el perfil de conexión enp7s0 con la siguiente configuración:

  • Una dirección IPv4 estática - 198.51.100.20 con una máscara de subred /24
  • Una dirección IPv6 estática - 2001:db8:1::1 con una máscara de subred /64
  • Una pasarela por defecto IPv4 - 198.51.100.254
  • Una pasarela por defecto IPv6 - 2001:db8:1::fffe
  • Un servidor DNS IPv4 - 198.51.100.200
  • Un servidor DNS IPv6 - 2001:db8:1::ffbb
  • Un dominio de búsqueda DNS - example.com
  • Rutas estáticas:

    • 192.0.2.0/24 con puerta de enlace 198.51.100.1
    • 203.0.113.0/24 con puerta de enlace 198.51.100.2

Requisitos previos

  • Los paquetes ansible y rhel-system-roles se instalan en el nodo de control.
  • Si utiliza un usuario remoto diferente a root cuando ejecuta el libro de jugadas, este usuario tiene los permisos apropiados de sudo en el nodo gestionado.

Procedimiento

  1. Si el host en el que desea ejecutar las instrucciones del libro de jugadas aún no está inventariado, añada la IP o el nombre de este host al archivo de inventario de Ansible /etc/ansible/hosts:

    nodo.ejemplo.com
  2. Cree el libro de jugadas ~/add-static-routes.yml con el siguiente contenido:

    ---
    - name: Configure an Ethernet connection with static IP and additional routes
      hosts: node.example.com
      become: true
      tasks:
      - include_role:
          name: linux-system-roles.network
    
        vars:
          network_connections:
            - name: enp7s0
              type: ethernet
              autoconnect: yes
              ip:
                address:
                  - 198.51.100.20/24
                  - 2001:db8:1::1/64
                gateway4: 198.51.100.254
                gateway6: 2001:db8:1::fffe
                dns:
                  - 198.51.100.200
                  - 2001:db8:1::ffbb
                dns_search:
                  - example.com
                route:
                  - network: 192.0.2.0
                    prefix: 24
                    gateway: 198.51.100.1
                  - network: 203.0.113.0
                    prefix: 24
                    gateway: 198.51.100.2
              state: up
  3. Ejecuta el libro de jugadas:

    • Para conectarse como usuario de root al host gestionado, introduzca:

      # ansible-playbook -u root ~/add-static-routes.yml
    • Para conectarse como usuario al host gestionado, introduzca:

      # ansible-playbook -u user_name --ask-become-pass ~/add-static-routes.yml

      La opción --ask-become-pass asegura que el comando ansible-playbook solicite la contraseña sudo del usuario definido en la opción -u user_name opción.

    Si no se especifica la opción -u user_name ansible-playbook se conecta al host gestionado como el usuario que ha iniciado la sesión en el nodo de control.

Pasos de verificación

  • Muestra la tabla de enrutamiento:

    # ip -4 route
    default via 198.51.100.254 dev enp7s0 proto static metric 100
    192.0.2.0/24 via 198.51.100.1 dev enp7s0 proto static metric 100
    203.0.113.0/24 via 198.51.100.2 dev enp7s0 proto static metric 100
    ...

Recursos adicionales

  • Para obtener detalles sobre los parámetros utilizados en network_connections y para obtener información adicional sobre el rol del sistema network, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.network/README.md.
  • Para obtener más información sobre el comando ansible-playbook, consulte la página de manual ansible-playbook(1).

4.8. Configuración de las funciones de descarga de ethtool

Las tarjetas de interfaz de red pueden utilizar el motor de descarga TCP (TOE) para descargar el procesamiento de ciertas operaciones al controlador de red para mejorar el rendimiento de la red.

Esta sección describe cómo configurar las funciones de descarga.

4.8.1. Uso de los roles del sistema para establecer las características de ethtool

Puede utilizar el rol de sistema networking RHEL para configurar las características de ethtool de una conexión NetworkManager.

Importante

Cuando se ejecuta una obra que utiliza el rol de sistema networking RHEL, el rol de sistema anula un perfil de conexión existente con el mismo nombre si la configuración no coincide con la especificada en la obra. Por lo tanto, especifique siempre toda la configuración del perfil de conexión de red en la obra, incluso si, por ejemplo, la configuración de IP, ya existe. De lo contrario, el rol restablece estos valores a sus valores por defecto.

Dependiendo de si ya existe, el procedimiento crea o actualiza el perfil de conexión enp1s0 con la siguiente configuración:

  • Una dirección IPv4 estática - 198.51.100.20 con una máscara de subred /24
  • Una dirección IPv6 estática - 2001:db8:1::1 con una máscara de subred /64
  • Una pasarela por defecto IPv4 - 198.51.100.254
  • Una pasarela por defecto IPv6 - 2001:db8:1::fffe
  • Un servidor DNS IPv4 - 198.51.100.200
  • Un servidor DNS IPv6 - 2001:db8:1::ffbb
  • Un dominio de búsqueda DNS - example.com
  • ethtool características:

    • Descarga de recepción genérica (GRO): desactivada
    • Descarga de segmentación genérica (GSO): activada
    • Segmentación del protocolo de control de transmisión de flujos (SCTP): desactivada

Requisitos previos

  • Los paquetes ansible y rhel-system-roles se instalan en el nodo de control.
  • Si se utiliza un usuario remoto diferente a root cuando se ejecuta el libro de jugadas, este usuario tiene los permisos apropiados de sudo en el nodo gestionado.

Procedimiento

  1. Si el host en el que desea ejecutar las instrucciones del libro de jugadas aún no está inventariado, añada la IP o el nombre de este host al archivo de inventario de Ansible /etc/ansible/hosts:

    nodo.ejemplo.com
  2. Cree el libro de jugadas ~/configure-ethernet-device-with-ethtool-features.yml con el siguiente contenido:

    ---
    - name. Configure an Ethernet connection with ethtool features
      hosts: node.example.com
      become: true
      tasks:
      - include_role:
          name: linux-system-roles.network
    
        vars:
          network_connections:
            - name: enp1s0
              type: ethernet
              autoconnect: yes
              ip:
                address:
                  - 198.51.100.20/24
                  - 2001:db8:1::1/64
                gateway4: 198.51.100.254
                gateway6: 2001:db8:1::fffe
                dns:
                  - 198.51.100.200
                  - 2001:db8:1::ffbb
                dns_search:
                  - example.com
              ethtool:
                feature:
                  gro: "no"
                  gso: "yes"
                  tx_sctp_segmentation: "no"
              state: up
  3. Ejecuta el libro de jugadas:

    • Para conectarse como usuario de root al host gestionado, introduzca:

      # ansible-playbook -u root ~/configure-ethernet-device-with-ethtool-features.yml
    • Para conectarse como usuario al host gestionado, introduzca:

      # ansible-playbook -u user_name --ask-become-pass ~/configure-ethernet-device-with-ethtool-features.yml

      La opción --ask-become-pass asegura que el comando ansible-playbook solicite la contraseña sudo del usuario definido en la opción -u user_name opción.

    Si no se especifica la opción -u user_name ansible-playbook se conecta al host gestionado como el usuario que ha iniciado la sesión en el nodo de control.

Recursos adicionales

  • Para obtener una lista completa de las características de ethtool y detalles sobre los parámetros utilizados en network_connections, y para obtener información adicional sobre el rol del sistema network, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.network/README.md.
  • Para obtener más información sobre el comando ansible-playbook, consulte la página de manual ansible-playbook(1).

Capítulo 5. Configuración de SElinux mediante roles de sistema

5.1. Introducción al rol del sistema SELinux

RHEL System Roles es una colección de roles y módulos de Ansible que proporcionan una interfaz de configuración consistente para gestionar remotamente múltiples sistemas RHEL. El rol de sistema SELinux permite las siguientes acciones:

  • Limpieza de las modificaciones de las políticas locales relacionadas con los booleanos de SELinux, los contextos de archivos, los puertos y los inicios de sesión.
  • Configuración de booleanos de la política SELinux, contextos de archivos, puertos e inicios de sesión.
  • Restauración de contextos de archivo en archivos o directorios especificados.

La siguiente tabla proporciona una visión general de las variables de entrada disponibles en el rol del sistema SELinux.

Tabla 5.1. Variables de rol del sistema SELinux

Variable de rolDescripciónAlternativa CLI

selinux_policy

Elige una política de protección de procesos específicos o una protección de seguridad multinivel.

SELINUXTYPE en /etc/selinux/config

selinux_state

Cambia los modos de SELinux. Ver ansible-doc selinux

setenforce y SELINUX en /etc/selinux/config.

selinux_booleans

Activa y desactiva los booleanos de SELinux. Véase ansible-doc seboolean.

setsebool

selinux_fcontextos

Añade o elimina una asignación de contexto de archivo SELinux. Véase ansible-doc sefcontext.

semanage fcontext

selinux_restore_dirs

Restaura las etiquetas de SELinux en el árbol del sistema de archivos.

restorecon -R

selinux_ports

Establece las etiquetas SELinux en los puertos. Véase ansible-doc seport.

semanage port

selinux_logins

Establece los usuarios en el mapeo de usuarios de SELinux. Véase ansible-doc selogin.

semanage login

El libro de jugadas de ejemplo /usr/share/doc/rhel-system-roles/selinux/example-selinux-playbook.yml instalado por el paquete rhel-system-roles demuestra cómo establecer la política dirigida en modo de aplicación. El libro de jugadas también aplica varias modificaciones de la política local y restaura los contextos de los archivos en el directorio /tmp/test_dir/.

Recursos adicionales

  • Para una referencia detallada sobre las variables de rol de SELinux, instale el paquete rhel-system-roles, y vea los archivos README.md o README.html en el directorio /usr/share/doc/rhel-system-roles/selinux/.
  • Para obtener más información sobre las funciones del sistema RHEL, consulte Introducción a las funciones del sistema RHEL

5.2. Uso del rol de sistema SELinux para aplicar la configuración de SELinux en varios sistemas

Siga los pasos para preparar y aplicar un playbook de Ansible con su configuración de SELinux verificada.

Requisitos previos

Procedimiento

  1. Habilitar el repositorio RHEL Ansible, por ejemplo:

    # subscription-manager repos --enable ansible-2-for-rhel-8-x86_64-rpms
  2. Instale el motor Ansible:

    # yum install ansible
  3. Instalar los roles del sistema RHEL:

    # yum install rhel-system-roles
  4. Aplique su libro de jugadas con un rol de sistema SELinux.

    El siguiente comando aplica un playbook de ejemplo, que forma parte del paquete rhel-system-roles. Puede utilizar este libro de jugadas como plantilla:

    # ansible-playbook -i host1,host2,host3 /usr/share/doc/rhel-system-roles/selinux/example-selinux-playbook.yml

Recursos adicionales

  • Para más información, instale el paquete rhel-system-roles y consulte los directorios /usr/share/doc/rhel-system-roles/selinux/ y /usr/share/ansible/roles/rhel-system-roles.selinux/.

Capítulo 6. Uso de la función de sistema de registro

Como administrador del sistema, puede utilizar el rol de sistema de registro para configurar un host RHEL como servidor de registro para recoger los registros de muchos sistemas cliente.

6.1. La función del sistema de registro

Con el rol de sistema de registro, puede desplegar configuraciones de registro en hosts locales y remotos.

Para aplicar un rol de sistema de registro en uno o más sistemas, se define la configuración de registro en un playbook. Un libro de jugadas es una lista de una o más jugadas. Los playbooks son legibles por humanos y están escritos en formato YAML. Para más información sobre los playbooks, vea Trabajar con playbooks en la documentación de Ansible.

El conjunto de sistemas que quiere que Ansible configure según el libro de jugadas se define en un inventory file. Para obtener más información sobre la creación y el uso de inventarios, consulte Cómo construir su inventario en la documentación de Ansible.

Las soluciones de registro proporcionan múltiples formas de leer los registros y múltiples salidas de registro.

Por ejemplo, un sistema de registro puede recibir las siguientes entradas:

  • archivos locales,
  • systemd/journal,
  • otro sistema de registro a través de la red.

Además, un sistema de registro puede tener las siguientes salidas:

  • los registros se almacenan en los archivos locales del directorio /var/log,
  • los registros se envían a Elasticsearch,
  • los registros se envían a otro sistema de registro.

Con el rol de sistema de registro, puedes combinar las entradas y salidas para adaptarlas a tus necesidades. Por ejemplo, puede configurar una solución de registro que almacene las entradas de journal en un archivo local, mientras que las entradas leídas de los archivos se reenvían a otro sistema de registro y se almacenan en los archivos de registro locales.

6.2. Parámetros de la función del sistema de registro

En un playbook de Logging System Role, se definen las entradas en el parámetro logging_inputs, las salidas en el parámetro logging_outputs y las relaciones entre las entradas y salidas en el parámetro logging_flows. El rol de sistema de registro procesa estas variables con opciones adicionales para configurar el sistema de registro. También puede habilitar la encriptación.

Nota

Actualmente, el único sistema de registro disponible en el rol de sistema de registro es Rsyslog.

  • logging_inputs - Lista de entradas para la solución de registro.

    • name - Nombre único de la entrada. Se utiliza en la lista de entradas de logging_flows y forma parte del nombre del archivo generado de config.
    • type - Tipo del elemento de entrada. El tipo especifica un tipo de tarea que corresponde a un nombre de directorio en roles/rsyslog/{tasks,vars}/inputs/.

      • basics - Entradas que configuran las entradas desde el diario systemd o el zócalo unix.

        • kernel_message - Cargar imklog si se ajusta a true. Por defecto, false.
        • use_imuxsock - Utilice imuxsock en lugar de imjournal. Por defecto, false.
        • ratelimit_burst - Número máximo de mensajes que se pueden emitir dentro de ratelimit_interval. Por defecto es 20000 si use_imuxsock es falso. Por defecto a 200 si use_imuxsock es verdadero.
        • ratelimit_interval - Intervalo para evaluar ratelimit_burst. Por defecto, 600 segundos si use_imuxsock es falso. Por defecto es 0 si use_imuxsock es verdadero. 0 indica que la limitación de velocidad está desactivada.
        • persist_state_interval - El estado del diario se mantiene cada value mensajes. Por defecto es 10. Sólo es efectivo cuando use_imuxsock es falso.
      • files - Entradas que configuran las entradas de los archivos locales.
      • remote - Entradas que configuran las entradas del otro sistema de registro a través de la red.
    • state - Estado del archivo de configuración. present o absent. Por defecto, present.
  • logging_outputs - Lista de salidas para la solución de registro.

    • files - Salidas que configuran las salidas a los archivos locales.
    • forwards - Salidas que configuran las salidas a otro sistema de registro.
    • remote_files - Salidas que configuran salidas de otro sistema de registro a archivos locales.
  • logging_flows - Lista de movimientos que definen las relaciones entre logging_inputs y logging_outputs. La variable logging_flows tiene las siguientes claves:

    • name - Nombre único del flujo
    • inputs - Lista de valores del nombre logging_inputs
    • outputs - Lista de valores del nombre logging_outputs.

Recursos adicionales

  • Documentación instalada con el paquete rhel-system-roles en /usr/share/ansible/roles/rhel-system-roles.logging/README.html

6.3. Aplicación de un rol de sistema de registro local

Siga estos pasos para preparar y aplicar un playbook de Red Hat Ansible Engine para configurar una solución de registro en un conjunto de máquinas separadas. Cada máquina registrará los registros localmente.

Requisitos previos

  • Tiene instalado Red Hat Ansible Engine en el sistema desde el que desea ejecutar el libro de jugadas.

    Nota

    No es necesario que tenga instalado Red Hat Ansible Engine en los sistemas en los que desee implementar la solución de registro.

  • Tiene el paquete rhel-system-roles en el sistema desde el que quiere ejecutar el libro de jugadas.

    Nota

    No es necesario tener instalado rsyslog, porque el rol de sistema instala rsyslog cuando se despliega.

  • Tiene un archivo de inventario que enumera los sistemas en los que desea configurar la solución de registro.

Procedimiento

  1. Cree un libro de jugadas que defina el rol requerido:

    1. Cree un nuevo archivo YAML y ábralo en un editor de texto, por ejemplo:

      # vi logging-playbook.yml
    2. Inserte el siguiente contenido:

      ---
      - name: Deploying basics input and implicit files output
        hosts: all
        roles:
          - linux-system-roles.logging
        vars:
          logging_inputs:
            - name: system_input
              type: basics
          logging_outputs:
            - name: files_output
              type: files
          logging_flows:
            - name: flow1
              inputs: [system_input]
              outputs: [files_output]
  2. Ejecutar el libro de jugadas en un inventario específico:

    # ansible-playbook -i inventory-file /path/to/file/logging-playbook.yml

    Dónde:

    • inventory-file es el archivo de inventario.
    • logging-playbook.yml es el libro de jugadas que utilizas.

Verificación

  1. Pruebe la sintaxis del archivo /etc/rsyslog.conf:

    # rsyslogd -N 1
    rsyslogd: version 8.1911.0-6.el8, config validation run (level 1), master config /etc/rsyslog.conf
    rsyslogd: End of config validation run. Bye.
  2. Compruebe que el sistema envía mensajes al registro:

    1. Envía un mensaje de prueba:

      # logger test
    2. Vea el registro de /var/log/messages, por ejemplo:

      # cat /var/log/messages
      Aug  5 13:48:31 hostname root[6778]: test

      Donde `hostname` es el nombre del host del sistema cliente. Tenga en cuenta que el registro contiene el nombre del usuario que introdujo el comando del registrador, en este caso root.

6.4. Aplicación de una solución de registro remoto mediante el rol de sistema de registro

Siga estos pasos para preparar y aplicar un libro de jugadas de Red Hat Ansible Engine para configurar una solución de registro remoto. En este libro de jugadas, uno o más clientes toman los registros de systemd-journal y los envían a un servidor remoto. El servidor recibe la entrada remota de remote_rsyslog y remote_files y envía los registros a archivos locales en directorios nombrados por nombres de hosts remotos.

Requisitos previos

  • Tiene instalado Red Hat Ansible Engine en el sistema desde el que desea ejecutar el libro de jugadas.

    Nota

    No es necesario que tenga instalado Red Hat Ansible Engine en los sistemas en los que desee implementar la solución de registro.

  • Tiene el paquete rhel-system-roles en el sistema desde el que quiere ejecutar el libro de jugadas.

    Nota

    No es necesario tener instalado rsyslog, porque el rol de sistema instala rsyslog cuando se despliega.

  • Tienes al menos dos sistemas:

    • Al menos uno será el servidor de registro.
    • Al menos uno será el cliente de registro.

Procedimiento

  1. Cree un libro de jugadas que defina el rol requerido:

    1. Cree un nuevo archivo YAML y ábralo en un editor de texto, por ejemplo:

      # vi logging-playbook.yml
    2. Inserte el siguiente contenido en el archivo:

      ---
      - name: Deploying remote input and remote_files output
        hosts: server
        roles:
          - linux-system-roles.logging
        vars:
          logging_inputs:
            - name: remote_udp_input
              type: remote
              udp_ports: [ 601 ]
            - name: remote_tcp_input
              type: remote
              tcp_ports: [ 601 ]
          logging_outputs:
            - name: remote_files_output
              type: remote_files
          logging_flows:
            - name: flow_0
              inputs: [remote_udp_input, remote_tcp_input]
              outputs: [remote_files_output]
      
      - name: Deploying basics input and forwards output
        hosts: clients
        roles:
          - linux-system-roles.logging
        vars:
          logging_inputs:
            - name: basic_input
              type: basics
          logging_outputs:
            - name: forward_output0
              type: forwards
              severity: info
              target: host1.example.com
              udp_port: 601
            - name: forward_output1
              type: forwards
              facility: mail
              target: host1.example.com
              tcp_port: 601
          logging_flows:
            - name: flows0
              inputs: [basic_input]
              outputs: [forward_output0, forward_output1]
      
      [basic_input]
      [forward_output0, forward_output1]

      Donde host1.example.com es el servidor de registro.

      Nota

      Puede modificar los parámetros del libro de jugadas para adaptarlos a sus necesidades.

      Aviso

      La solución de registro sólo funciona con los puertos definidos en la política SELinux del sistema servidor o cliente y abiertos en el cortafuegos. La política SELinux por defecto incluye los puertos 601, 514, 6514, 10514 y 20514. Para utilizar un puerto diferente, modifique la política SELinux en los sistemas cliente y servidor . La configuración del cortafuegos a través de los roles del sistema aún no está soportada.

  2. Cree un archivo de inventario que enumere sus servidores y clientes:

    1. Cree un nuevo archivo y ábralo en un editor de texto, por ejemplo:

      # vi inventory.ini
    2. Inserte el siguiente contenido en el archivo de inventario:

      [servers]
      server ansible_host=host1.example.com
      [clients]
      client ansible_host=host2.example.com

      Where: * host1.example.com is the logging server. * host2.example.com is the logging client.

  3. Ejecute el libro de jugadas en su inventario.

    # ansible-playbook -i /path/to/file/inventory.ini /path/to/file/_logging-playbook.yml

    Dónde:

    • inventory.ini es el archivo de inventario.
    • logging-playbook.yml es el libro de jugadas que has creado.

Pasos de verificación

  1. Tanto en el sistema cliente como en el servidor, compruebe la sintaxis del archivo /etc/rsyslog.conf:

    # rsyslogd -N 1
    rsyslogd: version 8.1911.0-6.el8, config validation run (level 1), master config /etc/rsyslog.conf
    rsyslogd: End of config validation run. Bye.
  2. Compruebe que el sistema cliente envía mensajes al servidor:

    1. En el sistema cliente, envíe un mensaje de prueba:

      # logger test
    2. En el sistema del servidor, vea el registro /var/log/messages, por ejemplo:

      # cat /var/log/messages
      Aug  5 13:48:31 host2.example.com root[6778]: test

      Donde host2.example.com es el nombre del host del sistema cliente. Tenga en cuenta que el registro contiene el nombre del usuario que introdujo el comando del registrador, en este caso root.

Recursos adicionales

6.5. Recursos adicionales

Capítulo 7. Utilización de las funciones del sistema de horquilla y de Tang

7.1. Introducción a las funciones del sistema de horquilla y Tang

RHEL System Roles es una colección de roles y módulos de Ansible que proporcionan una interfaz de configuración consistente para gestionar remotamente múltiples sistemas RHEL.

RHEL 8.3 introdujo los roles de Ansible para el despliegue automatizado de soluciones de descifrado basado en políticas (PBD) utilizando Clevis y Tang. El paquete rhel-system-roles contiene estos roles de sistema, los ejemplos relacionados y también la documentación de referencia.

El rol de sistema nbde_client le permite desplegar múltiples clientes Clevis de forma automatizada. Tenga en cuenta que el rol nbde_client sólo admite enlaces Tang, y no puede utilizarlo para enlaces TPM2 por el momento.

El rol nbde_client requiere volúmenes que ya están encriptados usando LUKS. Esta función permite vincular un volumen cifrado con LUKS a uno o más servidores vinculados a la red (NBDE) - servidores Tang. Puede conservar el cifrado del volumen existente con una frase de contraseña o eliminarla. Una vez eliminada la frase de contraseña, puede desbloquear el volumen sólo con NBDE. Esto es útil cuando un volumen está inicialmente encriptado utilizando una clave o contraseña temporal que debe eliminar después de aprovisionar el sistema.

Si proporciona tanto una frase de contraseña como un archivo de claves, el rol utiliza lo que ha proporcionado primero. Si no encuentra ninguno de ellos válido, intenta recuperar una frase de contraseña de un enlace existente.

PBD define una vinculación como una asignación de un dispositivo a una ranura. Esto significa que se pueden tener varios enlaces para el mismo dispositivo. La ranura por defecto es la ranura 1.

El rol nbde_client proporciona también la variable state. Utilice el valor present para crear un nuevo enlace o actualizar uno existente. Al contrario que el comando clevis luks bind, puede utilizar state: present también para sobrescribir un enlace existente en su ranura de dispositivo. El valor absent elimina un enlace especificado.

Utilizando el rol nbde_server, puede desplegar y gestionar un servidor Tang como parte de una solución de encriptación de disco automatizada. Este rol soporta las siguientes características:

  • Llaves Tang giratorias
  • Despliegue y copia de seguridad de las llaves Tang

Recursos adicionales

  • Para una referencia detallada sobre las variables de rol Network-Bound Disk Encryption (NBDE), instale el paquete rhel-system-roles, y vea los archivos README.md y README.html en los directorios /usr/share/doc/rhel-system-roles/nbde_client/ y /usr/share/doc/rhel-system-roles/nbde_server/.
  • Para ver ejemplos de playbooks de system-roles, instale el paquete rhel-system-roles, y vea los directorios /usr/share/ansible/roles/rhel-system-roles.nbde_server/examples/.
  • Para obtener más información sobre las funciones del sistema RHEL, consulte Introducción a las funciones del sistema RHEL

7.2. Uso del rol de sistema nbde_server para configurar múltiples servidores Tang

Siga los pasos para preparar y aplicar un playbook de Ansible que contenga la configuración de su servidor Tang.

Requisitos previos

Procedimiento

  1. Habilitar el repositorio RHEL Ansible, por ejemplo:

    # subscription-manager repos --enable ansible-2-for-rhel-8-x86_64-rpms
  2. Instale el motor Ansible:

    # yum install ansible
  3. Instalar los roles del sistema RHEL:

    # yum install rhel-system-roles
  4. Prepare su libro de jugadas con la configuración de los servidores Tang. Puede empezar desde cero o utilizar uno de los libros de juego de ejemplo del directorio /usr/share/ansible/roles/rhel-system-roles.nbde_server/examples/.

    # cp /usr/share/ansible/roles/rhel-system-roles.nbde_server/examples/simple_deploy.yml ./my-tang-playbook.yml
  5. Edite el libro de jugadas en un editor de texto de su elección, por ejemplo:

    # vi my-tang-playbook.yml
  6. Añada los parámetros necesarios. El siguiente ejemplo de libro de jugadas asegura el despliegue de su servidor Tang y una rotación de llaves:

    ---
    - hosts: all
    
      vars:
        nbde_server_rotate_keys: yes
    
      roles:
        - linux-system-roles.nbde_server
  7. Aplicar el libro de jugadas terminado:

    # ansible-playbook -i host1,host2,host3 my-tang-playbook.yml

Recursos adicionales

  • Para más información, instale el paquete rhel-system-roles y consulte los directorios /usr/share/doc/rhel-system-roles/nbde_server/ y usr/share/ansible/roles/rhel-system-roles.nbde_server/.

7.3. Uso de la función del sistema nbde_client para configurar varios clientes Clevis

Siga los pasos para preparar y aplicar un libro de jugadas de Ansible que contenga su configuración de Clevis-client.

Nota

El rol de sistema nbde_client sólo admite enlaces Tang. Esto significa que, por el momento, no se puede utilizar para los enlaces TPM2.

Requisitos previos

  • Su suscripción a Red Hat Ansible Engine está conectada al sistema. Consulte el artículo Cómo descargar e instalar Red Hat Ansible Engine para obtener más información.
  • Sus volúmenes ya están encriptados por LUKS.

Procedimiento

  1. Habilitar el repositorio RHEL Ansible, por ejemplo:

    # subscription-manager repos --enable ansible-2-for-rhel-8-x86_64-rpms
  2. Instale el motor Ansible:

    # yum install ansible
  3. Instalar los roles del sistema RHEL:

    # yum install rhel-system-roles
  4. Prepare su libro de jugadas con la configuración de los clientes de Clevis. Puede empezar desde cero o utilizar uno de los libros de juego de ejemplo del directorio /usr/share/ansible/roles/rhel-system-roles.nbde_client/examples/.

    # cp /usr/share/ansible/roles/rhel-system-roles.nbde_client/examples/high_availability.yml ./my-clevis-playbook.yml
  5. Edite el libro de jugadas en un editor de texto de su elección, por ejemplo:

    # vi my-clevis-playbook.yml
  6. Añada los parámetros necesarios. El siguiente ejemplo de libro de jugadas configura los clientes Clevis para el desbloqueo automático de dos volúmenes cifrados con LUKS cuando al menos uno de los dos servidores Tang está disponible:

    ---
    - hosts: all
    
      vars:
        nbde_client_bindings:
          - device: /dev/rhel/root
            encryption_key_src: /etc/luks/keyfile
            servers:
              - http://server1.example.com
              - http://server2.example.com
          - device: /dev/rhel/swap
            encryption_key_src: /etc/luks/keyfile
            servers:
              - http://server1.example.com
              - http://server2.example.com
    
      roles:
        - linux-system-roles.nbde_client
  7. Aplicar el libro de jugadas terminado:

    # ansible-playbook -i host1,host2,host3 my-clevis-playbook.yml

Recursos adicionales

  • Para obtener detalles sobre los parámetros e información adicional sobre la función nbde_client, instale el paquete rhel-system-roles y consulte los directorios /usr/share/doc/rhel-system-roles/nbde_client/ y /usr/share/ansible/roles/rhel-system-roles.nbde_client/.

Capítulo 8. Solicitud de certificados mediante RHEL System Roles

Con la función de sistema de certificados, puede utilizar Red Hat Ansible Engine para emitir y gestionar certificados.

Este capítulo abarca los siguientes temas:

8.1. La función del sistema de certificados

Utilizando el rol de sistema de certificados, puede gestionar la emisión y renovación de certificados TLS y SSL utilizando Red Hat Ansible Engine.

El rol utiliza certmonger como proveedor de certificados, y actualmente soporta la emisión y renovación de certificados autofirmados y el uso de la autoridad de certificados (CA) integrada en IdM.

Puede utilizar las siguientes variables en su libro de jugadas de Ansible con la función de sistema de certificados:

  • certificate_wait para especificar si la tarea debe esperar a que se emita el certificado.
  • certificate_requests para representar cada certificado a emitir y sus parámetros.

Recursos adicionales

  • Para obtener detalles sobre los parámetros utilizados en la variable certificate_requests e información adicional sobre la función del sistema certificate, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.certificate/README.md.
  • Para más detalles sobre los Roles de Sistema de RHEL y cómo aplicarlos, vea Introducción a los Roles de Sistema de RHEL.

8.2. Solicitud de un nuevo certificado autofirmado mediante la función de sistema de certificados

Con la función de sistema de certificados, puede utilizar Red Hat Ansible Engine para emitir certificados autofirmados.

Este proceso utiliza el proveedor certmonger y solicita el certificado a través del comando getcert.

Nota

Por defecto, certmonger intenta renovar automáticamente el certificado antes de que caduque. Puede desactivar esto estableciendo el parámetro auto_renew en el libro de jugadas de Ansible como no.

Requisitos previos

  • Tiene instalado Red Hat Ansible Engine en el sistema desde el que desea ejecutar el libro de jugadas.

    Nota

    No es necesario tener Ansible instalado en los sistemas en los que se desea desplegar la solución certificate.

  • Tienes el paquete rhel-system-roles instalado en el sistema desde el que quieres ejecutar el playbook.

    Para más detalles sobre los Roles de Sistema de RHEL y cómo aplicarlos, vea Introducción a los Roles de Sistema de RHEL.

Procedimiento

  1. Optional: Crear un archivo de inventario, por ejemplo inventory.file:

    $ touch inventario.archivo
  2. Abra su archivo de inventario y defina los hosts en los que desea solicitar el certificado, por ejemplo:

    [webserver]
    server.idm.example.com
  3. Cree un archivo de playbook, por ejemplo request-certificate.yml:

    • Configure hosts para incluir los hosts en los que desea solicitar el certificado, como por ejemplo webserver.
    • Establezca la variable certificate_requests para incluir lo siguiente:

      • Establezca el parámetro name con el nombre deseado para el certificado, como por ejemplo mycert.
      • Establezca el parámetro dns con el dominio que se incluirá en el certificado, como por ejemplo *.example.com.
      • Ajuste el parámetro ca a self-sign.
    • Establezca la función rhel-system-roles.certificate en roles.

      Este es el archivo del libro de jugadas para este ejemplo:

      ---
      - hosts: webserver
      
        vars:
          certificate_requests:
            - name: mycert
              dns: *.example.com
              ca: self-sign
      
        roles:
          - rhel-system-roles.certificate
  4. Guarda el archivo.
  5. Ejecuta el libro de jugadas:

    $ ansible-playbook -i inventory.file request-certificate.yml

Recursos adicionales

  • Para obtener detalles sobre los parámetros utilizados en la variable certificate_requests e información adicional sobre la función del sistema certificate, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.certificate/README.md.
  • Para obtener más información sobre el comando ansible-playbook, consulte la página de manual ansible-playbook(1).

8.3. Solicitud de un nuevo certificado a la CA de IdM mediante la función de sistema de certificados

Con la función de sistema de certificados, puede utilizar Red Hat Ansible Engine para emitir certificados mientras utiliza un servidor IdM con una autoridad de certificados (CA) integrada. Por lo tanto, puede gestionar de manera eficiente y consistente la cadena de confianza de certificados para múltiples sistemas cuando se utiliza IdM como CA.

Este proceso utiliza el proveedor certmonger y solicita el certificado a través del comando getcert.

Nota

Por defecto, certmonger intenta renovar automáticamente el certificado antes de que caduque. Puede desactivar esto estableciendo el parámetro auto_renew en el libro de jugadas de Ansible como no.

Requisitos previos

  • Tiene instalado Red Hat Ansible Engine en el sistema desde el que desea ejecutar el libro de jugadas.

    Nota

    No es necesario tener Ansible instalado en los sistemas en los que se desea desplegar la solución certificate.

  • Tienes el paquete rhel-system-roles instalado en el sistema desde el que quieres ejecutar el playbook.

    Para más detalles sobre los Roles de Sistema de RHEL y cómo aplicarlos, vea Introducción a los Roles de Sistema de RHEL.

Procedimiento

  1. Optional: Crear un archivo de inventario, por ejemplo inventory.file:

    $ touch inventario.archivo
  2. Abra su archivo de inventario y defina los hosts en los que desea solicitar el certificado, por ejemplo:

    [webserver]
    server.idm.example.com
  3. Cree un archivo de playbook, por ejemplo request-certificate.yml:

    • Configure hosts para incluir los hosts en los que desea solicitar el certificado, como por ejemplo webserver.
    • Establezca la variable certificate_requests para incluir lo siguiente:

      • Establezca el parámetro name con el nombre deseado para el certificado, como por ejemplo mycert.
      • Establezca el parámetro dns con el dominio que se incluirá en el certificado, como por ejemplo www.example.com.
      • Establezca el parámetro principal para especificar la entidad principal de Kerberos, como HTTP/www.example.com@EXAMPLE.COM.
      • Ajuste el parámetro ca a ipa.
    • Establezca la función rhel-system-roles.certificate en roles.

      Este es el archivo del libro de jugadas para este ejemplo:

      ---
      - hosts: webserver
        vars:
          certificate_requests:
            - name: mycert
              dns: www.example.com
              principal: HTTP/www.example.com@EXAMPLE.COM
              ca: ipa
      
        roles:
          - rhel-system-roles.certificate
  4. Guarda el archivo.
  5. Ejecuta el libro de jugadas:

    $ ansible-playbook -i inventory.file request-certificate.yml

Recursos adicionales

  • Para obtener detalles sobre los parámetros utilizados en la variable certificate_requests e información adicional sobre la función del sistema certificate, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.certificate/README.md.
  • Para obtener más información sobre el comando ansible-playbook, consulte la página de manual ansible-playbook(1).

8.4. Especificación de los comandos que se ejecutan antes o después de la emisión del certificado mediante la función de sistema de certificados

Con la función de sistema de certificados, puede utilizar Red Hat Ansible Engine para ejecutar un comando antes y después de la emisión o renovación de un certificado.

En el siguiente ejemplo, el administrador se asegura de detener el servicio httpd antes de que se emita o renueve un certificado autofirmado para www.example.com, y de reiniciarlo después.

Nota

Por defecto, certmonger intenta renovar automáticamente el certificado antes de que caduque. Puede desactivar esto estableciendo el parámetro auto_renew en el libro de jugadas de Ansible como no.

Requisitos previos

  • Tiene instalado Red Hat Ansible Engine en el sistema desde el que desea ejecutar el libro de jugadas.

    Nota

    No es necesario tener Ansible instalado en los sistemas en los que se desea desplegar la solución certificate.

  • Tienes el paquete rhel-system-roles instalado en el sistema desde el que quieres ejecutar el playbook.

    Para más detalles sobre los Roles de Sistema de RHEL y cómo aplicarlos, vea Introducción a los Roles de Sistema de RHEL.

Procedimiento

  1. Optional: Crear un archivo de inventario, por ejemplo inventory.file:

    $ touch inventario.archivo
  2. Abra su archivo de inventario y defina los hosts en los que desea solicitar el certificado, por ejemplo:

    [webserver]
    server.idm.example.com
  3. Cree un archivo de playbook, por ejemplo request-certificate.yml:

    • Configure hosts para incluir los hosts en los que desea solicitar el certificado, como por ejemplo webserver.
    • Establezca la variable certificate_requests para incluir lo siguiente:

      • Establezca el parámetro name con el nombre deseado para el certificado, como por ejemplo mycert.
      • Establezca el parámetro dns con el dominio que se incluirá en el certificado, como por ejemplo www.example.com.
      • Establezca el parámetro ca en la CA que desea utilizar para emitir el certificado, como por ejemplo self-sign.
      • Establezca el parámetro run_before con el comando que desea ejecutar antes de que se emita o renueve este certificado, como systemctl stop httpd.service.
      • Establezca el parámetro run_after con el comando que desea ejecutar después de que se emita o renueve este certificado, como systemctl start httpd.service.
    • Establezca la función rhel-system-roles.certificate en roles.

      Este es el archivo del libro de jugadas para este ejemplo:

      ---
      - hosts: webserver
        vars:
          certificate_requests:
            - name: mycert
              dns: www.example.com
              ca: self-sign
              run_before: systemctl stop httpd.service
              run_after: systemctl start httpd.service
      
        roles:
          - linux-system-roles.certificate
  4. Guarda el archivo.
  5. Ejecuta el libro de jugadas:

    $ ansible-playbook -i inventory.file request-certificate.yml

Recursos adicionales

  • Para obtener detalles sobre los parámetros utilizados en la variable certificate_requests e información adicional sobre la función del sistema certificate, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.certificate/README.md.
  • Para obtener más información sobre el comando ansible-playbook, consulte la página de manual ansible-playbook(1).

Capítulo 9. Configuración de kdump mediante los roles de sistema de RHEL

Para gestionar kdump mediante Ansible, puede utilizar el rol kdump, que es uno de los roles de sistema RHEL disponibles en RHEL 8.

El uso de kdump permite especificar dónde guardar el contenido de la memoria del sistema para su posterior análisis.

Para más información sobre los Roles del Sistema RHEL y cómo aplicarlos, vea Introducción a los Roles del Sistema RHEL.

9.1. El rol del sistema kdump RHEL

El rol de sistema kdump le permite establecer los parámetros básicos de volcado del núcleo en varios sistemas.

9.2. Parámetros de la función Kdump

Los parámetros utilizados para el kdump RHEL System Roles son:

Variable de rolDescripción

kdump_path

La ruta en la que se escribe vmcore. Si kdump_target no es nulo, la ruta es relativa a ese destino de volcado. De lo contrario, debe ser una ruta absoluta en el sistema de archivos raíz.

Recursos adicionales

  • Consulte la página de manual de makedumpfile(8).
  • Para obtener detalles sobre los parámetros utilizados en kdump e información adicional sobre la función del sistema kdump, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.tlog/README.md.

9.3. Configuración de kdump mediante los roles de sistema de RHEL

Puede establecer los parámetros básicos de volcado del núcleo en varios sistemas utilizando el rol de sistema kdump ejecutando un libro de jugadas de Ansible.

Aviso

El rol kdump reemplaza la configuración de kdump de los hosts gestionados por completo, sustituyendo el archivo /etc/kdump.conf. Además, si se aplica el rol kdump, también se reemplazan todas las configuraciones anteriores de kdump, incluso si no están especificadas por las variables del rol, reemplazando el archivo /etc/sysconfig/kdump.

Requisitos previos

  • Tiene instalado Red Hat Ansible Engine en el sistema desde el que desea ejecutar el libro de jugadas.

    Nota

    No es necesario tener Red Hat Ansible Automation Platform instalado en los sistemas en los que se desea implementar la solución kdump.

  • Tienes el paquete rhel-system-roles instalado en el sistema desde el que quieres ejecutar el playbook.
  • Dispone de un archivo de inventario que enumera los sistemas en los que desea desplegar kdump.

Procedimiento

  1. Cree un nuevo playbook.yml archivo con el siguiente contenido:

    ---
    - hosts: kdump-test
      vars:
        kdump_path: /var/crash
      roles:
        - rhel-system-roles.kdump
  2. Opcional: Verificar la sintaxis del libro de jugadas.

    # ansible-playbook --syntax-check playbook.yml
  3. Ejecute el libro de jugadas en su archivo de inventario:

    # ansible-playbook -i inventory_file /path/to/file/playbook.yml

Recursos adicionales

  • Para una referencia detallada sobre las variables de rol de kdump, consulte los archivos README.md o README.html en el directorio /usr/share/doc/rhel-system-roles/kdump.
  • Véase Sección 1.3, “Aplicar un papel”.
  • Documentación instalada con el paquete rhel-system-roles /usr/share/ansible/roles/rhel-system-roles.kdump/README.html

Capítulo 10. Gestión del almacenamiento local mediante los roles de sistema de RHEL

Para gestionar LVM y sistemas de archivos locales (FS) mediante Ansible, puede utilizar el rol storage, que es uno de los roles de sistema RHEL disponibles en RHEL 8.

El uso del rol storage le permite automatizar la administración de sistemas de archivos en discos y volúmenes lógicos en múltiples máquinas y en todas las versiones de RHEL a partir de RHEL 7.7.

Para más información sobre los Roles del Sistema RHEL y cómo aplicarlos, vea Introducción a los Roles del Sistema RHEL.

10.1. Introducción a la función de almacenamiento

La función storage puede gestionar:

  • Sistemas de archivos en discos que no han sido particionados
  • Grupos de volúmenes LVM completos, incluyendo sus volúmenes lógicos y sistemas de archivos

Con el rol storage puede realizar las siguientes tareas:

  • Crear un sistema de archivos
  • Eliminar un sistema de archivos
  • Montar un sistema de archivos
  • Desmontar un sistema de archivos
  • Crear grupos de volúmenes LVM
  • Eliminar grupos de volúmenes LVM
  • Crear volúmenes lógicos
  • Eliminar volúmenes lógicos
  • Crear volúmenes RAID
  • Eliminar volúmenes RAID
  • Crear pools LVM con RAID
  • Eliminar pools LVM con RAID

10.2. Parámetros que identifican un dispositivo de almacenamiento en el rol de sistema de almacenamiento

La configuración de su rol en storage afecta sólo a los sistemas de archivos, volúmenes y pools que se enumeran en las siguientes variables.

storage_volumes

Lista de sistemas de archivos en todos los discos no particionados que se van a gestionar.

Actualmente, las particiones no son compatibles.

storage_pools

Lista de piscinas a gestionar.

Actualmente el único tipo de pool soportado es LVM. Con LVM, los pools representan grupos de volúmenes (VGs). Bajo cada pool hay una lista de volúmenes que deben ser gestionados por el rol. Con LVM, cada volumen corresponde a un volumen lógico (LV) con un sistema de archivos.

10.3. Ejemplo de playbook de Ansible para crear un sistema de archivos XFS en un dispositivo de bloques

Esta sección proporciona un ejemplo de libro de jugadas de Ansible. Este libro de jugadas aplica el rol storage para crear un sistema de archivos XFS en un dispositivo de bloques utilizando los parámetros predeterminados.

Aviso

El rol storage puede crear un sistema de archivos sólo en un disco entero no particionado o en un volumen lógico (LV). No puede crear el sistema de archivos en una partición.

Ejemplo 10.1. Un playbook que crea XFS en /dev/sdb

---
- hosts: all
  vars:
    storage_volumes:
      - name: barefs
        type: disk
        disks:
          - sdb
        fs_type: xfs
  roles:
    - rhel-system-roles.storage
  • El nombre del volumen (barefs en el ejemplo) es actualmente arbitrario. El rol storage identifica el volumen por el dispositivo de disco listado bajo el atributo disks:.
  • Puede omitir la línea fs_type: xfs porque XFS es el sistema de archivos por defecto en RHEL 8.
  • Para crear el sistema de archivos en un LV, proporcione la configuración de LVM bajo el atributo disks:, incluyendo el grupo de volúmenes que lo rodea. Para obtener más detalles, consulte Ejemplo de libro de jugadas de Ansible para gestionar volúmenes lógicos.

    No proporcione la ruta de acceso al dispositivo LV.

Recursos adicionales

  • Para más detalles sobre los parámetros utilizados en el rol de sistema storage, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.storage/README.md.

10.4. Ejemplo de playbook de Ansible para montar persistentemente un sistema de archivos

Esta sección proporciona un ejemplo de libro de jugadas de Ansible. Este libro de jugadas aplica el rol storage para montar de forma inmediata y persistente un sistema de archivos XFS.

Ejemplo 10.2. Un playbook que monta un sistema de archivos en /dev/sdb a /mnt/data

---
- hosts: all
  vars:
    storage_volumes:
      - name: barefs
        type: disk
        disks:
          - sdb
        fs_type: xfs
        mount_point: /mnt/data
  roles:
    - rhel-system-roles.storage
  • Este libro de jugadas añade el sistema de archivos al archivo /etc/fstab, y monta el sistema de archivos inmediatamente.
  • Si el sistema de archivos del dispositivo /dev/sdb o el directorio del punto de montaje no existen, el libro de jugadas los crea.

Recursos adicionales

  • Para más detalles sobre los parámetros utilizados en el rol de sistema storage, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.storage/README.md.

10.5. Ejemplo de libro de jugadas de Ansible para gestionar volúmenes lógicos

Esta sección proporciona un ejemplo de libro de jugadas de Ansible. Este libro de jugadas aplica el rol storage para crear un volumen lógico LVM en un grupo de volúmenes.

Ejemplo 10.3. Un libro de jugadas que crea un volumen lógico mylv en el grupo de volúmenes myvg

- hosts: all
  vars:
    storage_pools:
      - name: myvg
        disks:
          - sda
          - sdb
          - sdc
        volumes:
          - name: mylv
            size: 2G
            fs_type: ext4
            mount_point: /mnt
  roles:
    - rhel-system-roles.storage
  • El grupo de volúmenes myvg está formado por los siguientes discos:

    • /dev/sda
    • /dev/sdb
    • /dev/sdc
  • Si el grupo de volumen myvg ya existe, el libro de jugadas añade el volumen lógico al grupo de volumen.
  • Si el grupo de volumen myvg no existe, el libro de jugadas lo crea.
  • El libro de jugadas crea un sistema de archivos Ext4 en el volumen lógico mylv, y monta persistentemente el sistema de archivos en /mnt.

Recursos adicionales

  • Para más detalles sobre los parámetros utilizados en el rol de sistema storage, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.storage/README.md.

10.6. Ejemplo de libro de jugadas de Ansible para activar el descarte de bloques en línea

Esta sección proporciona un ejemplo de libro de jugadas de Ansible. Este libro de jugadas aplica el rol storage para montar un sistema de archivos XFS con el descarte de bloques en línea activado.

Ejemplo 10.4. Un libro de jugadas que permite descartar bloques en línea en /mnt/data/

---
- hosts: all
  vars:
    storage_volumes:
      - name: barefs
        type: disk
        disks:
          - sdb
        fs_type: xfs
        mount_point: /mnt/data
        mount_options: discard
  roles:
    - rhel-system-roles.storage

Recursos adicionales

  • Para más detalles sobre los parámetros utilizados en el rol de sistema storage, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.storage/README.md.

10.7. Ejemplo de playbook Ansible para crear y montar un sistema de archivos Ext4

Esta sección proporciona un ejemplo de libro de jugadas de Ansible. Este libro de jugadas aplica el rol storage para crear y montar un sistema de archivos Ext4.

Ejemplo 10.5. Un playbook que crea Ext4 en /dev/sdb y lo monta en /mnt/data

---
- hosts: all
  vars:
    storage_volumes:
      - name: barefs
        type: disk
        disks:
          - sdb
        fs_type: ext4
        fs_label: label-name
        mount_point: /mnt/data
  roles:
    - rhel-system-roles.storage
  • El libro de jugadas crea el sistema de archivos en el disco /dev/sdb.
  • El libro de jugadas monta persistentemente el sistema de archivos en el directorio /mnt/data directorio.
  • La etiqueta del sistema de archivos es label-name.

Recursos adicionales

  • Para más detalles sobre los parámetros utilizados en el rol de sistema storage, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.storage/README.md.

10.8. Ejemplo de playbook de Ansible para crear y montar un sistema de archivos ext3

Esta sección proporciona un ejemplo de libro de jugadas de Ansible. Este libro de jugadas aplica el rol storage para crear y montar un sistema de archivos Ext3.

Ejemplo 10.6. Un playbook que crea Ext3 en /dev/sdb y lo monta en /mnt/data

---
- hosts: all
  vars:
    storage_volumes:
      - name: barefs
        type: disk
        disks:
          - sdb
        fs_type: ext3
        fs_label: label-name
        mount_point: /mnt/data
  roles:
    - rhel-system-roles.storage
  • El libro de jugadas crea el sistema de archivos en el disco /dev/sdb.
  • El libro de jugadas monta persistentemente el sistema de archivos en el directorio /mnt/data directorio.
  • La etiqueta del sistema de archivos es label-name.

Recursos adicionales

  • Para más detalles sobre los parámetros utilizados en el rol de sistema storage, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.storage/README.md.

10.9. Configuración de un volumen RAID mediante el rol de sistema de almacenamiento

Con el rol de sistema storage, puede configurar un volumen RAID en RHEL utilizando Red Hat Ansible Automation Platform. En esta sección aprenderá a configurar un playbook de Ansible con los parámetros disponibles para configurar un volumen RAID que se adapte a sus necesidades.

Requisitos previos

  • Tiene instalado Red Hat Ansible Engine en el sistema desde el que desea ejecutar el libro de jugadas.

    Nota

    No es necesario tener Red Hat Ansible Automation Platform instalado en los sistemas en los que se desea implementar la solución storage.

  • Tienes el paquete rhel-system-roles instalado en el sistema desde el que quieres ejecutar el playbook.
  • Tienes un archivo de inventario que detalla los sistemas en los que quieres desplegar un volumen RAID usando el rol de sistema storage.

Procedimiento

  1. Cree un nuevo playbook.yml archivo con el siguiente contenido:

    - hosts: all
      vars:
        storage_safe_mode: false
        storage_volumes:
          - name: data
            type: raid
            disks: [sdd, sde, sdf, sdg]
            raid_level: raid0
            raid_chunk_size: 32 KiB
            mount_point: /mnt/data
            state: present
      roles:
        - name: rhel-system-roles.storage
    Aviso

    Los nombres de los dispositivos pueden cambiar en determinadas circunstancias; por ejemplo, cuando se añade un nuevo disco a un sistema. Por lo tanto, para evitar la pérdida de datos, no se recomienda utilizar nombres de discos específicos en el libro de jugadas.

  2. Opcional. Verificar la sintaxis del libro de jugadas.

    # ansible-playbook --syntax-check playbook.yml
  3. Ejecute el libro de jugadas en su archivo de inventario:

    # ansible-playbook -i inventory.file /path/to/file/playbook.yml

Recursos adicionales

  • Para obtener más información sobre RAID, consulte Gestión de RAID.
  • Para obtener detalles sobre los parámetros utilizados en el rol del sistema de almacenamiento, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.storage/README.md.

10.10. Configuración de un pool LVM con RAID utilizando el rol de sistema de almacenamiento

Con el rol de sistema storage, puede configurar un pool LVM con RAID en RHEL utilizando Red Hat Ansible Automation Platform. En esta sección aprenderá a configurar un playbook Ansible con los parámetros disponibles para configurar un pool LVM con RAID.

Requisitos previos

  • Tiene instalado Red Hat Ansible Engine en el sistema desde el que desea ejecutar el libro de jugadas.

    Nota

    No es necesario tener Red Hat Ansible Automation Platform instalado en los sistemas en los que se desea implementar la solución storage.

  • Tienes el paquete rhel-system-roles instalado en el sistema desde el que quieres ejecutar el playbook.
  • Tienes un archivo de inventario que detalla los sistemas en los que quieres configurar un pool LVM con RAID utilizando el rol de sistema storage.

Procedimiento

  1. Cree un nuevo playbook.yml archivo con el siguiente contenido:

    - hosts: all
      vars:
        storage_safe_mode: false
        storage_pools:
          - name: my_pool
            type: lvm
            disks: [sdh, sdi]
            raid_level: raid1
            volumes:
              - name: my_pool
                size: "1 GiB"
                mount_point: "/mnt/app/shared"
                fs_type: xfs
                state: present
      roles:
        - name: rhel-system-roles.storage
    Nota

    Para crear un pool LVM con RAID, debes especificar el tipo de RAID utilizando el parámetro raid_level.

  2. Opcional. Verificar la sintaxis del libro de jugadas.

    # ansible-playbook --syntax-check playbook.yml
  3. Ejecute el libro de jugadas en su archivo de inventario:

    # ansible-playbook -i inventory.file /path/to/file/playbook.yml

Recursos adicionales

  • Para obtener más información sobre RAID, consulte Gestión de RAID.
  • Para obtener detalles sobre los parámetros utilizados en el rol del sistema de almacenamiento, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.storage/README.md.

10.11. Creación de un volumen encriptado LUKS utilizando el rol de almacenamiento

Puede utilizar el rol storage para crear y configurar un volumen encriptado con LUKS ejecutando un playbook de Ansible.

Requisitos previos

  • Tiene instalado Red Hat Ansible Engine en el sistema desde el que desea ejecutar el libro de jugadas.

    Nota

    No es necesario tener Red Hat Ansible Automation Platform instalado en los sistemas en los que se desea crear el volumen.

  • Tiene el paquete rhel-system-roles instalado en el controlador Ansible.
  • Dispone de un archivo de inventario en el que se detallan los sistemas en los que desea desplegar un volumen encriptado LUKS mediante el rol de sistema de almacenamiento.

Procedimiento

  1. Cree un nuevo playbook.yml archivo con el siguiente contenido:

    - hosts: all
      vars:
        storage_volumes:
          - name: barefs
            type: disk
            disks:
             - sdb
            fs_type: xfs
            fs_label: label-name
            mount_point: /mnt/data
            encryption: true
            encryption_password: your-password
      roles:
       - rhel-system-roles.storage
  2. Opcional. Verificar la sintaxis del libro de jugadas:

    # ansible-playbook --syntax-check playbook.yml
  3. Ejecute el libro de jugadas en su archivo de inventario:

    # ansible-playbook -i inventory.file /path/to/file/playbook.yml

Recursos adicionales

  • Para más información sobre LUKS, véase 17. Cifrado de dispositivos de bloque mediante LUKS..
  • Para más detalles sobre los parámetros utilizados en el rol de sistema storage, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.storage/README.md.

Recursos adicionales

  • Para más información, instale el paquete rhel-system-roles y consulte los siguientes directorios:

    • /usr/share/doc/rhel-system-roles/storage/
    • /usr/share/ansible/roles/rhel-system-roles.storage/

Capítulo 11. Configuración de la sincronización horaria mediante los roles de sistema de RHEL

Con la función timesync RHEL System Role, puede gestionar la sincronización horaria en múltiples máquinas de destino en RHEL utilizando Red Hat Ansible Automation Platform.

11.1. La función del sistema timesync

Puede gestionar la sincronización de la hora en varios equipos de destino utilizando el rol de sistema timesync RHEL.

El rol timesync instala y configura una implementación NTP o PTP para operar como cliente NTP o réplica PTP para sincronizar el reloj del sistema con servidores NTP o grandes maestros en dominios PTP.

Tenga en cuenta que el uso del rol timesync también facilita la migración a chrony, porque puede utilizar el mismo libro de jugadas en todas las versiones de Red Hat Enterprise Linux a partir de RHEL 6 independientemente de si el sistema utiliza ntp o chrony para implementar el protocolo NTP.

11.2. Aplicación del rol de sistema timesync para un único grupo de servidores

El siguiente ejemplo muestra cómo aplicar la función timesync en una situación con un solo grupo de servidores.

Aviso

El rol timesync reemplaza la configuración del servicio del proveedor dado o detectado en el host gestionado. Las configuraciones anteriores se pierden, incluso si no están especificadas en las variables del rol. La única configuración conservada es la elección del proveedor si la variable timesync_ntp_provider no está definida.

Requisitos previos

  • Tiene instalado Red Hat Ansible Engine en el sistema desde el que desea ejecutar el libro de jugadas.

    Nota

    No es necesario tener Red Hat Ansible Automation Platform instalado en los sistemas en los que se desea implementar la solución timesync.

  • Tienes el paquete rhel-system-roles instalado en el sistema desde el que quieres ejecutar el playbook.
  • Usted tiene un archivo de inventario que enumera los sistemas en los que desea desplegar timesync System Role.

Procedimiento

  1. Cree un nuevo playbook.yml archivo con el siguiente contenido:

    ---
    - hosts: timesync-test
      vars:
        timesync_ntp_servers:
          - hostname: 2.rhel.pool.ntp.org
            pool: yes
            iburst: yes
      roles:
        - rhel-system-roles.timesync
  2. Opcional: Verificar la sintaxis del libro de jugadas.

    # ansible-playbook --syntax-check playbook.yml
  3. Ejecute el libro de jugadas en su archivo de inventario:

    # ansible-playbook -i inventory_file /path/to/file/playbook.yml

11.3. Timesync Variables de funciones del sistema

Puede pasar la siguiente variable a la función timesync:

  • timesync_ntp_servers:
Ajustes de la variable de funciónDescripción

nombre de host: host.ejemplo.com

Nombre o dirección del servidor

minpoll number

Intervalo mínimo de sondeo. Por defecto: 6

maxpoll number

Intervalo máximo de sondeo. Por defecto: 10

iburst: sí

Bandera que permite la sincronización inicial rápida. Por defecto: no

piscina: sí

Bandera que indica que cada dirección resuelta del nombre de host es un servidor NTP independiente. Por defecto: no

Recursos adicionales

  • Para una referencia detallada sobre las variables de rol de timesync, instale el paquete rhel-system-roles, y vea los archivos README.md o README.html en el directorio /usr/share/doc/rhel-system-roles/timesync.

Capítulo 12. Supervisión del rendimiento mediante RHEL System Roles

12.1. Introducción a la función del sistema de métricas

RHEL System Roles es una colección de roles y módulos de Ansible que proporcionan una interfaz de configuración consistente para gestionar remotamente múltiples sistemas RHEL. El rol de sistema de métricas configura los servicios de análisis de rendimiento para el sistema local y, opcionalmente, incluye una lista de sistemas remotos que deben ser supervisados por el sistema local. El rol de sistema de métricas le permite utilizar pcp para supervisar el rendimiento de sus sistemas sin tener que configurar pcp por separado, ya que la configuración y el despliegue de pcp son gestionados por el libro de jugadas.

Tabla 12.1. Variables de rol del sistema de métricas

Variable de rolDescripciónEjemplo de uso

metrics_monitored_hosts

Lista de hosts remotos que serán analizados por el host de destino. Estos hosts tendrán métricas registradas en el host de destino, así que asegúrese de que existe suficiente espacio en disco debajo de /var/log para cada host.

metrics_monitored_hosts: ["webserver.example.com", "database.example.com"]

metrics_retention_days

Configura el número de días de retención de datos de rendimiento antes de su eliminación.

metrics_retention_days: 14

servicio_gráfico_métrico

Una bandera booleana que permite que el host se configure con servicios para la visualización de datos de rendimiento a través de pcp y grafana. Por defecto, se establece como falso.

metrics_graph_service: false

metrics_query_service

Un indicador booleano que permite configurar el host con servicios de consulta de series temporales para consultar las métricas registradas de pcp a través de redis. Por defecto se establece como falso.

metrics_query_service: false

metrics_provider

Especifica qué colector de métricas se utilizará para proporcionar métricas. Actualmente, pcp es el único proveedor de métricas soportado.

metrics_provider: "pcp"

Recursos adicionales

  • para obtener detalles sobre los parámetros utilizados en metrics_connections e información adicional sobre el rol del sistema de métricas, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.metrics/README.md.

12.2. Uso de la función de sistema de métricas para supervisar su sistema local con visualización

Este procedimiento describe cómo utilizar el rol de sistema RHEL de métricas para supervisar su sistema local y, al mismo tiempo, aprovisionar la visualización de datos a través de grafana.

Requisitos previos

  • Tiene instalado Red Hat Ansible Engine en la máquina que desea supervisar.
  • Tiene el paquete rhel-system-roles instalado en la máquina que desea supervisar.

Procedimiento

  1. Configure localhost en el inventario de /etc/ansible/hosts Ansible añadiendo el siguiente contenido al inventario:

    localhost ansible_connection=local
  2. Cree un playbook de Ansible con el siguiente contenido:

    ---
    - hosts: localhost
      vars:
        metrics_graph_service: yes
      roles:
        - rhel-system-roles.metrics
  3. Ejecute el libro de jugadas de Ansible:

    # ansible-playbook name_of_your_playbook.yml
    Nota

    Dado que el booleano metrics_graph_service está configurado con el valor="sí", grafana se instala y aprovisiona automáticamente con pcp añadido como fuente de datos.

  4. Para ver la visualización de las métricas que se recopilan en su máquina, acceda a la interfaz web grafana como se describe en Acceso a la interfaz web de Grafana.

12.3. Utilizar el rol de sistema de métrica para configurar una flota de sistemas individuales que se supervisen a sí mismos

Este procedimiento describe cómo utilizar el rol de sistema de métricas para configurar una flota de máquinas para que se monitoreen a sí mismas.

Requisitos previos

  • Tiene instalado Red Hat Ansible Engine en la máquina que desea utilizar para ejecutar el libro de jugadas.
  • Tienes el paquete rhel-system-roles instalado en la máquina que quieres usar para ejecutar el playbook.

Procedimiento

  1. Añada el nombre o la IP de las máquinas que desea supervisar a través del libro de jugadas al archivo de inventario de Ansible /etc/ansible/hosts bajo un nombre de grupo identificativo encerrado entre paréntesis:

    [remotes]
    webserver.example.com
    database.example.com
  2. Cree un playbook de Ansible con el siguiente contenido:

    ---
    - hosts: remotes
      vars:
        metrics_retention_days: 0
      roles:
        - rhel-system-roles.metrics
  3. Ejecute el libro de jugadas de Ansible:

    # ansible-playbook name_of_your_playbook.yml

12.4. Uso del rol de sistema de métrica para supervisar una flota de máquinas de forma centralizada a través de su máquina local

Este procedimiento describe cómo utilizar el rol de sistema de métricas para configurar su máquina local para supervisar de forma centralizada una flota de máquinas, a la vez que proporciona la visualización de los datos a través de grafana y la consulta de los datos a través de redis.

Requisitos previos

  • Tiene instalado Red Hat Ansible Engine en la máquina que desea utilizar para ejecutar el libro de jugadas.
  • Tienes el paquete rhel-system-roles instalado en la máquina que quieres usar para ejecutar el playbook.

Procedimiento

  1. Cree un playbook de Ansible con el siguiente contenido:

    ---
    - hosts: localhost
      vars:
        metrics_graph_service: yes
        metrics_query_service: yes
        metrics_retention_days: 10
        metrics_monitored_hosts: ["database.example.com", "webserver.example.com"]
      roles:
        - rhel-system-roles.metrics
  2. Ejecute el libro de jugadas de Ansible:

    # ansible-playbook name_of_your_playbook.yml
    Nota

    Dado que los booleanos metrics_graph_service y metrics_query_service están configurados con el valor="sí", grafana se instala automáticamente y se aprovisiona con pcp añadido como fuente de datos con el registro de datos pcp indexado en redis, lo que permite utilizar el lenguaje de consulta pcp para realizar consultas complejas de los datos.

  3. Para ver la representación gráfica de las métricas que se recopilan de forma centralizada por su máquina y para consultar los datos, acceda a la interfaz web grafana como se describe en Acceso a la interfaz web de Grafana.

Capítulo 13. Configuración de un sistema para la grabación de sesiones utilizando el tlog RHEL System Roles

Con el rol de sistema tlog RHEL, puede configurar un sistema para la grabación de sesiones de terminal en RHEL utilizando Red Hat Ansible Automation Platform.

13.1. La función del sistema tlog

Puede configurar un sistema RHEL para la grabación de sesiones de terminal en RHEL utilizando el rol de sistema tlog RHEL. El paquete tlog y su reproductor de sesiones de consola web asociado le proporcionan la capacidad de grabar y reproducir las sesiones de terminal de los usuarios.

Puede configurar la grabación para que tenga lugar por usuario o grupo de usuarios a través del servicio SSSD. Todas las entradas y salidas del terminal se capturan y se almacenan en formato de texto en el diario del sistema.

Recursos adicionales

13.2. Componentes y parámetros del sistema tlog Roles

La solución Session Recording está compuesta por los siguientes componentes:

  • La utilidad tlog
  • Demonio de servicios de seguridad del sistema (SSSD)
  • Opcional: La interfaz de la consola web

Los parámetros utilizados para el tlog RHEL System Roles son:

Variable de rolDescripción

tlog_use_sssd (por defecto: sí)

Configurar la grabación de sesiones con SSSD, la forma preferida de gestionar los usuarios o grupos grabados

tlog_scope_sssd (por defecto: ninguno)

Configurar el ámbito de grabación de SSSD - todos / algunos / ninguno

tlog_users_sssd (por defecto: [])

Lista YAML de usuarios a registrar

tlog_groups_sssd (por defecto: [])

Lista YAML de grupos a registrar

  • Para obtener detalles sobre los parámetros utilizados en tlog e información adicional sobre la función del sistema tlog, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.tlog/README.md.

13.3. Despliegue del rol de sistema tlog RHEL

Siga estos pasos para preparar y aplicar un libro de jugadas de Ansible para configurar un sistema RHEL para registrar datos de grabación en el diario systemd.

Requisitos previos

  • Ha establecido claves SSH para el acceso desde el nodo de control al sistema de destino donde se configurará el rol de sistema tlog.
  • Tienes un nodo de control, que es un sistema desde el que el motor Ansible configura los otros sistemas.
  • Usted tiene Red Hat Ansible Engine instalado en el nodo de control, desde el cual desea ejecutar el libro de jugadas.
  • Tienes el paquete rhel-system-roles instalado en el nodo de control desde el que quieres ejecutar el playbook.
  • Tiene al menos un sistema en el que desea configurar el rol de sistema tlog. No es necesario que Red Hat Ansible Automation Platform esté instalado en los sistemas en los que desea implementar la solución tlog.

Procedimiento

  1. Cree un nuevo playbook.yml archivo con el siguiente contenido:

    ---
    - name: Deploy session recording
      hosts: all
      vars:
        tlog_scope_sssd: some
        tlog_users_sssd:
          - recordeduser
    
      roles:
        - rhel-system-roles.tlog

    Dónde,

    • tlog_scope_sssd:

      • some especifica que se quiere grabar sólo a ciertos usuarios y grupos, no a all o none.
    • tlog_users_sssd:

      • recordeduser especifica el usuario del que quieres grabar una sesión. Ten en cuenta que esto no añade el usuario por ti. Debes establecer el usuario por ti mismo.
  2. Opcionalmente, verifique la sintaxis del libro de jugadas.

    # ansible-playbook --syntax-check playbook.yml
  3. Ejecute el libro de jugadas en su archivo de inventario:

    # ansible-playbook -i IP_Address /path/to/file/playbook.yml -v

Como resultado, el libro de jugadas instala el rol tlog en el sistema que usted especificó. También crea un archivo de caída de configuración de SSSD que puede ser utilizado por los usuarios y grupos que usted defina. SSSD analiza y lee estos usuarios y grupos para superponer la sesión de tlog como usuario del shell. Además, si el paquete cockpit está instalado en el sistema, el libro de jugadas también instala el paquete cockpit-session-recording, que es un módulo Cockpit que permite ver y reproducir grabaciones en la interfaz de la consola web.

Pasos de verificación

Para verificar que el archivo de caída de configuración de SSSD se ha creado en el sistema, realice los siguientes pasos:

  1. Navegue hasta la carpeta en la que se ha creado el archivo drop de configuración de SSSD:

    # cd /etc/sssd/conf.d
  2. Comprueba el contenido del archivo:

    # cat /etc/sssd/conf.d/sssd-session-recording.conf

Puedes ver que el archivo contiene los parámetros que has establecido en el playbook.

13.4. Grabación de una sesión utilizando el rol de sistema tlog desplegado en la CLI

Una vez que haya desplegado el rol de sistema tlog en el sistema que haya especificado, podrá grabar una sesión de terminal de usuario utilizando la interfaz de línea de comandos (CLI).

Requisitos previos

  • Ha desplegado el rol de sistema tlog en el sistema de destino.
  • El archivo de caída de la configuración SSSD fue creado en el archivo /etc/sssd/conf.d.

Procedimiento

  1. Cree un usuario y asigne una contraseña para este usuario:

    # useradd recordeduser
    # passwd recordeduser 
  2. Vuelva a conectarse al sistema como el usuario que acaba de crear:

    # ssh recordeduser@localhost
  3. Escriba "sí" cuando el sistema le pida que escriba sí o no para autenticarse.
  4. Introduzca la contraseña de recordeduser’s.

    El sistema le mostrará un mensaje para informarle de que su sesión está siendo grabada.

    ATENCIÓN! Su sesión está siendo grabada!
  5. Una vez que haya terminado de grabar la sesión, escriba:

    # exit

    El sistema cierra la sesión del usuario y la conexión con el localhost.

Como resultado, la sesión del usuario se graba, se almacena y se puede reproducir mediante un diario.

Pasos de verificación

Para ver su sesión grabada en el diario, realice los siguientes pasos:

  1. Ejecute el siguiente comando:

    # journalctl -o verbose -r
  2. Busque el campo MESSAGE del asiento registrado en tlog-rec.

13.5. Ver una sesión grabada mediante la CLI

Puede reproducir la grabación de una sesión de usuario desde un diario utilizando la interfaz de línea de comandos (CLI).

Procedimiento

  1. En el terminal CLI, reproduzca la grabación de la sesión de usuario:

    # journalctl -o verbose -r
  2. Busque la grabación de tlog:

    $ /tlog-rec

    Puedes ver detalles como:

    • El nombre de usuario para la grabación de la sesión de usuario
    • El campo out_txt, una codificación de salida en bruto de la sesión grabada
    • El número de identificación TLOG_REC=ID_number
  3. Copie el número de identificador TLOG_REC=ID_number.
  4. Reproduzca la grabación utilizando el número de identificación TLOG_REC=ID_number.

    # tlog-play -r journal -M TLOG_REC=ID_number

Como resultado, se puede ver la salida del terminal de grabación de la sesión de usuario que se está reproduciendo.