389ds-server

Este rol instala el servidor 389DS (servidor LDAP) en la(s) máquina(s) objetivo.

ansible-galaxy install lvps.389ds_server

Características

• Instalar un servidor LDAP único
• Configurar el registro
• Agregar archivos de esquema personalizados
• Activar/desactivar cualquier plugin
• Configurar el plugin DNA para números UID/GID
• Configurar TLS
• Habilitar TLS (mínimo SSF y requerir vínculos seguros) o volver a TLS opcional
• Habilitar/deshabilitar LDAPI
• Habilitar/deshabilitar SASL PLAIN

La replicación se gestiona con otro rol.

Requisitos

• Ansible 2.10 o más reciente, para Ansible 2.8 y 2.9 usa las versiones 3.1.x de este rol
• SUSE (OpenSUSE o SLES) o CentOS 7, CentOS 8, CentOS 9 u otro sistema operativo basado en RHEL

Variables del Rol

Las variables que se pueden pasar a este rol y una breve descripción sobre ellas son las siguientes.

dirsrv_product

Predeterminado: Depende del sistema operativo · Puede ser cambiado: No

Hay dos ramas principales. El 389 Directory Server gratuito y el Red Hat Directory Server soportado. Con las versiones gratuitas puedes confiar en la configuración predeterminada. De lo contrario, puedes configurar este valor según tus necesidades. En este momento, el único valor no predeterminado probado es '@redhat-ds:11' para el Red Hat Directory Server 11, disponible en el sistema operativo Red Hat EL8.

dirsrv_port

Predeterminado: 389 · Puede ser cambiado: No

El puerto donde escucha el 389ds.

dirsrv_suffix

Predeterminado: dc=example,dc=com · Puede ser cambiado: No

Sufijo del DIT. Todas las entradas en el servidor estarán bajo este sufijo. Normalmente se compone de los componentes de dominio (dc) de tu dominio principal. Por ejemplo, si eres de example.co.uk y el servidor estará en ldap-server.example.co.uk, establece el sufijo a dc=example,dc=co,dc=uk, dejando fuera la parte del subdominio (ldap-server) ya que es irrelevante.

dirsrv_bename

Predeterminado: userRoot · Puede ser cambiado: No

Nombre de la base de datos interna del sufijo.

dirsrv_othersuffixes

Predeterminado: [] · Puede ser cambiado: No

Lista de otros sufijos en la forma { name: <bename>, dn: <rootDN>}

dirsrv_rootdn

Predeterminado: cn=Directory Manager · Puede ser cambiado: No

DN raíz, o el nombre de usuario de la cuenta "administrador". Vínculate con este DN para omitir todos los controles de autorización.

dirsrv_rootdn_password

Puede ser cambiado: No

Contraseña para el DN raíz, debes definir esta variable o el rol fallará.

dirsrv_fqdn

Predeterminado: {{ansible_nodename}} · Puede ser cambiado: No

FQDN del servidor, por ejemplo ldap.example.com. Si el nombre de host del servidor ya es un FQDN, el valor predeterminado lo recogerá.

dirsrv_serverid

Predeterminado: default · Puede ser cambiado: ¹

ID del servidor o ID de la instancia. Todos los datos relacionados con la instancia configurada por este rol terminarán en /etc/dirsrv/slapd-default, /var/log/dirsrv/slapd-default, etc. Podrías usar el nombre de tu empresa, por ejemplo, para Foo Bar, Inc, establece la variable a foobar y los directorios se llamarán slapd-foobar.

dirsrv_listen_host

Puede ser cambiado: Sí

Escucha en estas direcciones/nombres de host. Si no se establece (predeterminado), no hace nada; si se establece a una cadena, se configurará el atributo nsslapd-listenhost. Establecer a [] para eliminar el atributo.

dirsrv_secure_listen_host

Puede ser cambiado: Sí

Igual que dirsrv_listen_host pero para LDAPS. Si no se establece (predeterminado), no hace nada; si se establece a una cadena, se configurará el atributo nsslapd-securelistenhost. Establecer a [] para eliminar el atributo.

dirsrv_server_uri

Predeterminado: ldap://localhost · Puede ser cambiado: ¹

URI del servidor para tareas que se conectan a través de LDAP. Dado que las tareas se ejecutan en el mismo servidor que 389DS, en la mayoría de los casos esto será localhost, no es necesario personalizarlo.

dirsrv_factory

Predeterminado: false · Puede ser cambiado: Sí

Mantener la configuración predeterminada sobre los parámetros de autenticación y registro. Si true, se ignorarán completamente dirsrv_logging, dirsrv_simple_auth_enabled, dirsrv_password_storage_scheme, dirsrv_ldapi_enabled, dirsrv_sasl_plain_enabled.

dirsrv_install_examples

Predeterminado: false · Puede ser cambiado: No

Crear entradas de ejemplo bajo el sufijo durante la instalación

dirsrv_install_additional_ldif

Predeterminado: [] · Puede ser cambiado: No

Instalar estos archivos LDIF adicionales, por defecto ninguno (matriz vacía). Esto corresponde a la directiva InstallLdifFile en el archivo de instalación inf para 389DS <= 1.3. A partir de la versión 1.4, esto se realiza a través de dsconf.

dirsrv_ldif_files_remote

Predeterminado: false - puede ser cambiado: Sí

Los archivos ldif están en el servidor remoto, no en el controlador ansible.

dirsrv_install_additional_ldif_dir

Predeterminado: /var/lib/dirsrv/slapd-{{ dirsrv_serverid }}/ldif · Puede ser cambiado: No

Directorio donde se almacenan temporalmente los archivos ldif para dirsrv_install_additional_ldif. No puede ser /tmp ya que el servicio 389DS tiene PrivateTmp de systemd establecido en verdadero desde CentOS/RHEL 8.3.

dirsrv_logging

Predeterminado: ver más abajo · Puede ser cambiado: Sí

Ver abajo

dirsrv_plugins_enabled

Predeterminado: {} · Puede ser cambiado: Sí

Habilitar o deshabilitar plugins, ver más abajo para detalles. De forma predeterminada no se habilitan ni deshabilitan plugins.

dirsrv_dna_plugin

Predeterminado: ver abajo · Puede ser cambiado: Sí

Configuración para el plugin DNA (Asignación Numérica Distribuida).

dirsrv_custom_schema

Predeterminado: [] · Puede ser cambiado: Sí

Rutas a archivos de esquema personalizados. Se colocarán en /etc/dirsrv/slapd-{{ dirsrv_serverid }}/schema y se solicitará una recarga del esquema cuando algo cambie.

dirsrv_allow_other_schema_files

Predeterminado: false · Puede ser cambiado: Sí

Si es falso (valor predeterminado), este rol añadirá los archivos de esquema especificados a /etc/dirsrv/slapd-{{ dirsrv_serverid }}/schema, luego eliminará todos los demás archivos de esquema allí, excepto 99user.ldif. Si tus archivos de esquema son gestionados solo por este rol o dinámicamente (es decir, desde cn=schema, que escribe en 99user.ldif), puedes dejar esta variable en su valor predeterminado de falso. Si tienes más archivos de esquema en ese directorio (agregados manualmente u por otras tareas), establece esto en verdadero para dejarlos allí. El inconveniente es que si despliegas, por ejemplo, 50example.ldif, luego lo renombras a 50my_example.ldif, cuando el rol se ejecute nuevamente, lo considerará un archivo nuevo y dejará el anterior allí, causando problemas en tu directorio.

dirsrv_tls_enabled

Predeterminado: false · Puede ser cambiado: Sí

Habilitar TLS (LDAPS y StartTLS). Todas las variables "dirsrv_tls" tienen efecto solo si esto está habilitado.

dirsrv_tls_min_version

Predeterminado: '1.2' · Puede ser cambiado: Sí

Versión mínima de TLS: 1.0, 1.1 o 1.2. Posiblemente incluso 1.3, si es compatible con tu versión de 389DS. SSLv2 y SSLv3 están siempre deshabilitados por este rol.

dirsrv_tls_certificate_trusted

Predeterminado: true · Puede ser cambiado: Sí

El certificado del servidor es públicamente confiable. Establecer en falso solo en desarrollo (para certificados autofirmados).

dirsrv_tls_enforced

Predeterminado: false · Puede ser cambiado: Sí

Imponer TLS requiriendo vínculos seguros y SSF mínimo.

dirsrv_tls_minssf

Predeterminado: 256 · Puede ser cambiado: Sí

SSF mínimo, usado solo cuando dirsrv_tls_enforced es verdadero. 128 parece razonable, 256 debería ser muy seguro. Establecer esto en 0 para imponer TLS solo con vínculos seguros.

dirsrv_allow_anonymous_binds

Predeterminado: 'rootdse' · Puede ser cambiado: Sí

Permitir vínculos anónimos: booleano verdadero para Sí, booleano falso para No, o 'rootdse'. La Guía de Administración sugiere usar rootdse en lugar de No, porque permite vinculaciones anónimas para buscar algunos datos que los clientes pueden requerir antes de hacer un vínculo. Permitir vínculos anónimos, básicamente, hace que tu directorio sea público, a menos que limites el acceso con ACIs.

dirsrv_simple_auth_enabled

Predeterminado: true · Puede ser cambiado: Sí

Habilitar autenticación SIMPLE, probablemente verdadero a menos que quieras usar solo SASL PLAIN o configurar otros métodos manualmente.

dirsrv_password_storage_scheme

Predeterminado: [] · Puede ser cambiado: Sí

Un solo valor, posiblemente la cadena "PBKDF2_SHA256". O dejar el valor predeterminado, que eliminará cualquier valor personalizado y usará el predeterminado de 389DS, que debería ser bastante seguro.

dirsrv_ldapi_enabled

Predeterminado: false · Puede ser cambiado: Sí

Habilitar LDAPI (conectar al servidor a través de un socket UNIX en ldapi:///var/run/dirsrv/slapd-{{ dirsrv_serverid }}.socket). Ten en cuenta que esto está sujeto a la imposición de TLS y TLS no es compatible, por lo que es inútil si estableces dirsrv_tls_enforced en verdadero.

dirsrv_sasl_plain_enabled

Predeterminado: true · Puede ser cambiado: Sí

Habilitar la autenticación SASL PLAIN: si un cliente intenta autenticarse sin TLS y TLS está habilitado, este tipo de autenticación debería detenerlo antes de enviar la contraseña en texto plano, mientras que un vínculo SIMPLE enviará la contraseña y luego fallará porque el SSF es demasiado bajo.

Variables exclusivas para 389DS versión 1.4.X

Estas variables solo afectan a las instalaciones de la versión 1.4.X de 389DS y no tienen efecto en versiones anteriores, incluso si se definen.

dirsrv_defaults_version

Predeterminado: 999999999² · Puede ser cambiado: No

Los valores de configuración predeterminados serán los de la versión especificada de 389DS. El formato es XXXYYYZZZ, donde XXX es la versión principal, YYY es la versión menor y ZZZ es el nivel de parche (los tres valores se rellenan con ceros a la longitud de tres). Si se selecciona 999999999, se usarán los últimos valores predeterminados.

dirsrv_selfsigned_cert

Predeterminado: True² · Puede ser cambiado: No

Determina si 389DS generará un certificado autofirmado y habilitará TLS automáticamente.

dirsrv_selfsigned_cert_duration

Predeterminado: 24² · Puede ser cambiado: No

Validez en meses del certificado autofirmado generado por 389DS.

dirsrv_create_suffix_entry

Predeterminado: False² · Puede ser cambiado: No

Determina si 389DS generará una entrada de sufijo en el directorio con el sufijo dado: cn={{ dirsrv_suffix }}

dirsrv_rundir

Puede ser cambiado: No

Si se define, configura una ruta específica para db_home_dir.

dirsrv_rundir

Puede ser cambiado: No

Si se define, configura una ruta específica para run_dir.

Interoperabilidad entre 1.3.X y 1.4.X

Para que un playbook se comporte de la misma manera en las versiones 1.3 y 1.4 de 389DS, los siguientes valores deben usarse:

Variable	Valor
dirsrv_defaults_version	001004002³
dirsrv_selfsigned_cert	False
dirsrv_create_suffix_entry	True

Notas

Algunas variables no pueden ser cambiadas por este rol (o en absoluto) después de crear una instancia de 389DS. Si se cambia una de ellas y se aplica el rol nuevamente, podría suceder un comportamiento no definido que va desde "nada" hasta "el rol falla". Algunas de ellas, por ejemplo, la contraseña del DN raíz, pueden cambiarse manualmente: consulta la Guía de Administración para más detalles.

¹ Cambiar esta variable desde una ejecución anterior llevará a la creación de otra instancia, otro directorio completamente separado del anterior, que debería funcionar bien si ese es tu objetivo.

² Estos son los valores predeterminados según la versión 1.4.2.15 de 389DS y pueden cambiar para versiones posteriores: ejecuta dscreate create-template en tu máquina para ver la predeterminada para la versión actual.

³ Esta es la versión de los valores predeterminados sobre la cual se ha escrito y validado este rol. No se requiere técnicamente establecer dirsrv_defaults_version, pero puede evitar que futuras actualizaciones a los valores predeterminados rompan el playbook por ser incompatibles con 389DS 1.3. Por otro lado, establecer la variable esencialmente bloqueará la configuración en el tiempo y, si se hace durante un período prolongado, podría volverla obsoleta. Usa con discreción.

Todas las variables están precedidas por dirsrv porque comenzar un nombre de variable con un número ("389ds") no funciona bien.

dirsrv_logging

Esta es la variable predeterminada:

dirsrv_logging:
  audit:
    enabled: false
    logrotationtimeunit: day
    logmaxdiskspace: 400
    maxlogsize: 200
    maxlogsperdir: 7
    mode: 600
  access:
    enabled: true
    logrotationtimeunit: day
    logmaxdiskspace: 400
    maxlogsize: 200
    maxlogsperdir: 7
    mode: 600
  error:
    enabled: true
    logrotationtimeunit: day
    logmaxdiskspace: 400
    maxlogsize: 200
    maxlogsperdir: 7
    mode: 600

Ansible no fusiona diccionarios por defecto, es decir, si deseas cambiar solo audit > enabled a true, debes definir todas las otras variables también. Si deseas cambiar los valores predeterminados, probablemente sea una buena idea copiar todo este bloque en las variables y ajustar lo que necesites.

dirsrv_plugins_enabled

Si deseas habilitar el plugin memberof ubicado en cn=MemberOf Plugin,cn=plugins,cn=config, establece la variable en:

dirsrv_plugins_enabled:
  MemberOf Plugin: true

Si está habilitado y quieres deshabilitarlo, configúralo en:

dirsrv_plugins_enabled:
  MemberOf Plugin: false

Si quieres habilitar más plugins:

dirsrv_plugins_enabled:
  MemberOf Plugin: true
  Distributed Numeric Assignment Plugin: true

Si un plugin no aparece en la lista, se deja en su estado actual.

Un plugin llamado Foo debería tener una entrada bajo cn=Foo,cn=plugins,cn=config, puedes mirar en el árbol cn=plugins,cn=config para ver qué plugins están disponibles y su estado.

dirsrv_dna_plugin

Valor predeterminado:

dirsrv_dna_plugin:
  gid_min: 2000
  gid_max: 2999
  uid_min: 2000
  uid_max: 2999

Ansible no fusiona diccionarios por defecto, es decir, si solo deseas cambiar uid_max y gid_max, debes definir también las variables _min. Cuando defines dirsrv_dna_plugin, reemplaza completamente este diccionario predeterminado.

Esta configuración solo se aplica si "Distributed Numeric Assignment Plugin" es verdadero en dirsrv_plugins_enabled, y se elimina cuando es falso. Si no se menciona, no se hace nada.

dirsrv_replica_role debe ser definido para configurar DNA con replicación. Esa variable también está definida en el rol lvps/389ds-replication, así que consulta ese rol para la documentación. Para este rol, es suficiente que se defina si estás usando replicación, el valor no importa.

Etiquetas

Hay algunas etiquetas disponibles, así que puedes ejecutar, por ejemplo:

ansible-playbook some-playbook.yml --tags dirsrv_schema

y esto solo actualizará los archivos de esquema personalizados, sin cambiar nada más. some-playbook.yml debe aplicar este rol, evidentemente.

Las etiquetas son:

• dirsrv_schema: tareas de esquema personalizado
• dirsrv_tls: todas las tareas de configuración de TLS, incluidos certificados y aplicación
• dirsrv_cert: tareas de certificados TLS, un subconjunto de dirsrv_tls

Todas las etiquetas también incluyen algunas comprobaciones al comienzo de la ejecución y un "flush handlers" al final, ya que 389DS puede necesitar ser reiniciado o puede requerirse una recarga del esquema.

dirsrv_cert es particularmente útil para la gestión automatizada de certificados con ACME: consulta el ejemplo "TLS con Let's Encrypt (o otros proveedores de ACME)" a continuación. Si se agrega la misma etiqueta a todas las tareas relacionadas con ACME, será posible ejecutar ansible-playbook some-playbook.yml --tags dirsrv_cert periódicamente y automáticamente para actualizar los certificados.

Dependencias

Ninguna.

Uso y Ejemplos

Ejemplo mínimo de trabajo

- name: Un ejemplo de playbook
  hosts: example
  roles:
    - role: lvps.389ds_server
      dirsrv_rootdn_password: secreto

Conéctate con DN cn=Directory Manager y contraseña secreto en el puerto 389, el sufijo será dc=example,dc=local, todo lo demás es en su mayoría como una instalación limpia de 389DS.

Usar Ansible Vault sería una buena idea para evitar exponer la contraseña del DN raíz en texto plano en producción.

Configurar firewall

No es parte de este rol, pero puede que necesites abrir el puerto LDAP (389) para acceder al servidor de forma remota:

- name: Permitir puerto ldap en firewalld
  firewalld: service=ldap permanent=true state=enabled

Lo mismo puede ser necesario para el puerto LDAPS (636), si habilitas TLS y deseas usarlo en lugar de StartTLS.

Entradas de ejemplo y personalización

- name: Un ejemplo de playbook
  hosts: example
  roles:
    - role: lvps.389ds_server
      dirsrv_suffix: dc=custom,dc=example,dc=com
      dirsrv_rootdn: cn=admin
      dirsrv_rootdn_password: secreto
      dirsrv_serverid: personalizado
      dirsrv_install_examples: true
      dirsrv_logging:
        audit:
          enabled: true
          logrotationtimeunit: day
          logmaxdiskspace: 400
          maxlogsize: 200
          maxlogsperdir: 14
          mode: 600
        access:
          enabled: true
          logrotationtimeunit: day
          logmaxdiskspace: 400
          maxlogsize: 200
          maxlogsperdir: 14
          mode: 600
        error:
          enabled: true
          logrotationtimeunit: day
          logmaxdiskspace: 400
          maxlogsize: 200
          maxlogsperdir: 14
          mode: 600
      dirsrv_plugins_enabled:
        MemberOf Plugin: true
      dirsrv_custom_schema:
        - "50example.ldif"
        - "60foobar.ldif"

Conéctate con DN cn=admin y contraseña secreto en el puerto 389, mira las entradas de ejemplo proporcionadas por 389DS.

Los registros de auditoría también están habilitados, y todos los registros se mantienen durante 14 días (o hasta que se vuelvan demasiado grandes).

El plugin MemberOf también está habilitado.

Mira en el directorio molecule para un archivo de esquema personalizado que se sabe que funciona con 389DS, si deseas probar esa parte pero no tienes un archivo de esquema válido. Elimina esa parte para quitar todos los archivos de esquema personalizados. La recarga del esquema se realiza automáticamente.

TLS

- name: Un ejemplo de playbook
  hosts: example
  roles:
    - role: lvps.389ds_server
      dirsrv_suffix: "dc=example,dc=local"
      dirsrv_serverid: ejemplo
      dirsrv_rootdn_password: secreto
      dirsrv_tls_enabled: true
      dirsrv_tls_cert_file: example_cert.pem
      dirsrv_tls_key_file: example.key
      dirsrv_tls_files_remote: false # Verdadero si los archivos ya están en el host remoto (por ejemplo, proporcionado por certbot)
      dirsrv_tls_certificate_trusted: true # O falso si es autofirmado
      # Si deseas evitar LDAP en texto plano y aplicar TLS, también considera estas configuraciones:
      dirsrv_tls_enforced: true
      dirsrv_tls_minssf: 256
      # Nada que ver con TLS, pero para mejorar la seguridad puede que consideres:
      dirsrv_password_storage_scheme: "PBKDF2_SHA256"
      # aunque el esquema de almacenamiento de contraseñas predeterminado ya es suficientemente fuerte.

Aquí puedes encontrar un script para generar certificados autofirmados que han sido probados repetidamente con 389DS. O mira en el directorio molecule un ejemplo de certificado y clave que se utiliza para las pruebas del rol.

Sin embargo, ten en cuenta que el script se proporciona como un ejemplo para pruebas solamente, no se recomienda para uso en producción.

389DS se reinicia automáticamente cuando es necesario para aplicar la configuración. Tanto LDAPS (puerto 636) como StartTLS (puerto 389) están habilitados.

Si te cansas de tener una conexión segura, establece dirsrv_tls_enabled: false, pero el certificado permanecerá en la base de datos NSS de 389DS. Se puede quitar manualmente.

La renovación de certificados (reemplazar el certificado y la clave con uno nuevo, por ejemplo, porque los anteriores han expirado) parece funcionar con certificados autofirmados y Let's Encrypt, pero el proceso sigue siendo muy complicado y lleno de hacks y soluciones alternativas. Si deseas usar esto en producción, es recomendable que leas las partes relevantes de la sección 9.3 de la Guía de Administración y los comentarios en tasks/configure_tls.yml para entender qué está sucediendo y por qué.

TLS con Let's Encrypt (o otros proveedores de ACME)

El punto clave es que necesitas alimentar el "fullchain" (certificado del servidor y todos los intermedios, sin el certificado raíz) en el rol de 389ds-server. Dado que no pude encontrar muchos otros ejemplos sobre el desafío http-01 con acme_certificate, lo he agregado aquí para darte una mejor idea de todos los pasos necesarios.

- name: Un ejemplo de playbook
  hosts: example
  pre_tasks:
    - name: Asegurarse de que la cuenta ACME exista
      acme_account:
        # acme_directory: "http://..."  # Tu proveedor. Deja esto fuera para usar el directorio de ensayo de Let's Encrypt
        account_key_content: "{{ acme_account_key }}"  # "openssl genrsa 2048" para generarlo, pero lee https://docs.ansible.com/ansible/latest/modules/acme_account_module.html para información más actualizada
        acme_version: 2
        state: present
        terms_agreed: true
        contact:
          - mailto:[email protected]

    # Necesitas un CSR (solicitud de firma de certificado). Y una clave privada.
    # No reutilices la clave de la cuenta, haz una nueva.
    # Généralas:
    #
    # openssl genrsa 2048 -out example.key
    # openssl req -new -key example.key -out example.csr -subj "/C=/ST=/L=/O=/OU=/CN=your.domain.example.com"
    #
    # Solo el dominio es importante. Tanto example.key como tu clave de cuenta se deben mantener en secreto,
    # podrías colocarlos en Ansible Vault y usar una plantilla para crear example.key a partir de la variable.
    - name: Copiar CSR y clave privada
      copy:
        src: "{{ item }}"
        dest: "/etc/some/secret/directory"
        owner: root
        group: root
        mode: "400"  # El csr podría ser legible por todos, en realidad, no es secreto
        setype: cert_t
      loop:
        - "ruta/a/tu/example.csr"
        - "ruta/a/tu/example.key"

    - name: Crear desafío
      acme_certificate:
        acme_directory: "http://..."
        account_key_content: "{{ acme_account_key }}"
        acme_version: 2
        challenge: "http-01"
        # Necesitarás el full chain (que contiene tu certificado y todos
        # los intermedios, pero no el certificado raíz). Esto se alimentará a
        # NSS/389DS, que debería servir todos ellos.
        fullchain: "/etc/some/secret/directory/example.fullchain.pem"
        csr: "/etc/some/secret/directory/example.csr"
        # remaining_days: 10
      register: acme_challenge

    # Necesitas un servidor HTTP funcionando. Imagina que hay una instancia de NGINX que
    # sirve páginas en example.com desde /var/www/html/example.com
    # Si encuentras que tener un servidor HTTP siempre funcionando es molesto, "cuando: acme_challenge is changed"
    # se puede usar para iniciarlo para el desafío y detenerlo al final...
    #
    # También necesitarás algunos directorios, o la siguiente tarea fallará porque no existen...
    - name: Crear directorios HTTP para el desafío http-01 de ACME
      file:
        name: "{{ item }}"
        state: directory
        owner: root
        group: root
        # Estos no deberían ser secretos (son accesibles desde Internet),
        # solo no los hagas escribibles por nadie
        mode: "755"
        setype: httpd_sys_content_t  # solo lectura
      loop:
        - "/var/www/html/example.com"
        - "/var/www/html/example.com/.well-known"
        - "/var/www/html/example.com/.well-known/acme-challenge"

    - name: Cumplir el desafío http-01
      copy:
        dest: "/var/www/html/example.com/{{ acme_challenge['challenge_data']['example.com']['http-01']['resource'] }}"
        content: "{{ acme_challenge['challenge_data']['example.com']['http-01']['resource_value'] }}"
      when: acme_challenge is changed

    # Igual que la tarea anterior acme_certificate, solo que agrega "data"
    - name: Hacer el desafío
      acme_certificate:
        acme_directory: "http://..."
        account_key_content: "{{ acme_account_key }}"
        acme_version: 2
        challenge: "http-01"
        fullchain: "/etc/some/secret/directory/example.fullchain.pem"
        csr: "/etc/some/secret/directory/example.csr"
        data: "{{ acme_challenge }}"
      when: acme_challenge is changed

    # No es óptimo (durante algunos momentos antes de que esto suceda, el certificado tiene los
    # permisos incorrectos)
    # Puede que sea posible configurar esta tarea a "state: touch" y colocarla antes
    # de la anterior, aunque.
    - name: Asegurar permisos para el certificado de ejemplo
      file:
        state: file
        path: "/etc/some/secret/directory/example.fullchain.pem"
        owner: root
        group: root
        mode: "400"
        setype: cert_t

  # En este ejemplo he usado casi ninguna variable para mayor claridad
  # (es decir, ves cómo deberían lucir estas cadenas, en lugar de un nombre arbitrario
  # que he inventado), pero en un playbook real puede que sea mejor usar
  # algunas variables.

  roles:
    - role: lvps.389ds_server
      dirsrv_suffix: "dc=example,dc=local"
      dirsrv_serverid: ejemplo
      dirsrv_rootdn_password: secreto
      dirsrv_tls_enabled: true
      dirsrv_tls_cert_file: /etc/some/secret/directory/example.fullchain.pem
      dirsrv_tls_key_file: /etc/some/secret/directory/example.key
      dirsrv_tls_files_remote: true  # Ambos archivos están en el servidor
      dirsrv_tls_certificate_trusted: true  # No es necesario deshabilitar las comprobaciones de certificados, ¡bien!

Dado que se admite la renovación de certificados en este rol, solo necesitas ejecutar este playbook periódicamente para actualizar el certificado cuando esté a punto de expirar.

¿Qué pasa con la replicación?

Hay otro rol para eso.

Pruebas

Las pruebas utilizan el script docker systemctl replacement creado y distribuido por gdraheim bajo la licencia EUPL. Este script se descarga y copia a un contenedor local para permitir que las pruebas se ejecuten correctamente. Tal distribución se realiza bajo la misma licencia y términos bajo los cuales gdraheim creó y publicó su trabajo. El script se descarga tal cual y no se altera de ninguna manera. Al ejecutar las pruebas en sus máquinas, el usuario final acepta manejar el script descargado bajo los mismos términos de la EUPL como lo pretendió su autor. Ten en cuenta que las pruebas en sí (y el rol en general) aún están licenciadas bajo la licencia Apache 2.

Este rol usa molecule para sus pruebas. Instálalo probablemente con pip y prueba todos los escenarios:

python -m venv venv
venv/bin/activate
pip install -r requirements.txt
molecule test --all

O para probar un solo escenario: molecule test -s tls

Futuras extensiones

Podría hacerse, pero no está planeado a corto plazo

• Soporte para Debian/Ubuntu/FreeBSD o cualquier otra plataforma que soporte 389DS
• Soporte para otros plugins que necesitan más que solo habilitar/deshabilitar
• Soporte para otros atributos de DNA

Licencia

Apache 2.0 para el rol y las pruebas asociadas
EUPL v 1.2 para el script "docker systemctl replacement" por gdraheim (no incluido pero descargado al ejecutar pruebas)

Información del autor

Mantenedor: Ludovico Pavesi
Contribuyente/autores originales: Colby Prior
Contribuyente/autores originales: Artemii Kropachev
Gracias a Firstyear por los comentarios