lvps.389ds_server

Serveur 389ds

Ce rôle installe le serveur 389DS (serveur LDAP) sur la ou les machines cibles.

ansible-galaxy install lvps.389ds_server

Fonctionnalités

Installer un serveur LDAP unique
Configurer la journalisation
Ajouter des fichiers de schéma personnalisés
Activer/désactiver n'importe quel plugin
Configurer le plugin DNA pour les numéros UID/GID
Configurer TLS
Appliquer TLS (ssf minimum et exigences de connexions sécurisées) ou revenir à TLS optionnel
Activer/désactiver LDAPI
Activer/désactiver SASL PLAIN

La réplication est gérée avec un autre rôle.

Prérequis

Ansible 2.10 ou plus récent, pour Ansible 2.8 et 2.9, utilisez les versions 3.1.x de ce rôle.
SUSE (OpenSUSE ou SLES) ou CentOS 7, CentOS 8, CentOS 9 ou tout autre OS basé sur RHEL.

Variables du rôle

Les variables qui peuvent être passées à ce rôle ainsi qu'une brève description sont les suivantes.

dirsrv_product

Par défaut : dépend du système d'exploitation · Peut être changé : Non

Il y a deux branches principales. Le 389 Directory Server gratuit et le Red Hat Directory Server pris en charge. Avec les versions gratuites, vous pouvez vous fier aux paramètres par défaut. Sinon, vous pouvez configurer cette valeur selon vos besoins. Actuellement, la seule valeur non par défaut testée est '@redhat-ds:11' pour le Red Hat Directory Server 11, disponible dans Red Hat EL8.

dirsrv_port

Par défaut : 389 · Peut être changé : Non

Le port sur lequel 389ds écoute.

dirsrv_suffix

Par défaut : dc=example,dc=com · Peut être changé : Non

Suffixe de l'DIT. Toutes les entrées dans le serveur seront placées sous ce suffixe. Normalement, cela provient des composants de domaine (dc) de votre domaine principal. Par exemple, si vous êtes de example.co.uk et que le serveur sera à ldap-server.example.co.uk, définissez le suffixe sur dc=example,dc=co,dc=uk, en omettant la partie sous-domaine (ldap-server) car elle est hors de propos.

dirsrv_bename

Par défaut : userRoot · Peut être changé : Non

Nom de la base de données interne du suffixe.

dirsrv_othersuffixes

Par défaut : [] · Peut être changé : Non

Liste d'autres suffixes sous forme de dictionnaires { name: <bename>, dn: <rootDN>}

dirsrv_rootdn

Par défaut : cn=Directory Manager · Peut être changé : Non

Root DN, ou nom d'utilisateur du compte "administrateur". Connectez-vous avec ce DN pour contourner tous les contrôles d'autorisation.

dirsrv_rootdn_password

Peut être changé : Non

Mot de passe pour root DN, vous devez définir cette variable sinon le rôle échouera.

dirsrv_fqdn

Par défaut : {{ansible_nodename}} · Peut être changé : Non

FQDN du serveur, par exemple ldap.example.com. Si le nom d'hôte du serveur est déjà un FQDN, le défaut devrait être pris.

dirsrv_serverid

Par défaut : default · Peut être changé : ¹

ID du serveur ou ID d'instance. Toutes les données liées à l'instance configurée par ce rôle seront dans /etc/dirsrv/slapd-default, /var/log/dirsrv/slapd-default, etc... Vous pouvez utiliser le nom de votre entreprise, par exemple pour Foo Bar, Inc définissez la variable sur foobar et les répertoires seront nommés slapd-foobar.

dirsrv_listen_host

Peut être changé : Oui

Écoutez sur ces adresses/nom d'hôtes. Si non défini (par défaut) ne fait rien, si défini sur une chaîne, cela définira l'attribut nsslapd-listenhost. Définissez sur [] pour supprimer l'attribut.

dirsrv_secure_listen_host

Peut être changé : Oui

Identique à dirsrv_listen_host mais pour LDAPS. Si non défini (par défaut) ne fait rien, si défini sur une chaîne, cela définira l'attribut nsslapd-securelistenhost. Définissez sur [] pour supprimer l'attribut.

dirsrv_server_uri

Par défaut : ldap://localhost · Peut être changé : ¹

URI du serveur pour les tâches qui se connectent via LDAP. Comme les tâches s'exécutent sur le même serveur que 389DS, cela sera localhost dans la plupart des cas, pas besoin de le personnaliser.

dirsrv_factory

Par défaut : false · Peut être changé : Oui

Conserver les paramètres par défaut d'authentification et de journalisation. Si true, dirsrv_logging, dirsrv_simple_auth_enabled, dirsrv_password_storage_scheme, dirsrv_ldapi_enabled, dirsrv_sasl_plain_enabled seront complètement ignorés.

dirsrv_install_examples

Par défaut : false · Peut être changé : Non

Créer des entrées d'exemple sous le suffixe lors de l'installation.

dirsrv_install_additional_ldif

Par défaut : [] · Peut être changé : Non

Installer ces fichiers LDIF supplémentaires, par défaut aucun (tableau vide). Cela correspond à la directive InstallLdifFile dans le fichier d'installation inf pour 389DS <= 1.3. À partir de 1.4, cela se fait via dsconf.

dirsrv_ldif_files_remote

Par défaut : false - peut être changé : Oui

Les fichiers ldif sont sur le serveur distant, pas sur le contrôleur ansible.

dirsrv_install_additional_ldif_dir

Par défaut : /var/lib/dirsrv/slapd-{{ dirsrv_serverid }}/ldif · Peut être changé : Non

Répertoire où les fichiers ldif pour dirsrv_install_additional_ldif sont temporairement stockés. Ne peut pas être /tmp car le service 389DS a PrivateTmp de systemd défini sur true à partir de CentOS/RHEL 8.3.

dirsrv_logging

Par défaut : voir ci-dessous · Peut être changé : Oui

Voir ci-dessous

dirsrv_plugins_enabled

Par défaut : {} · Peut être changé : Oui

Activer ou désactiver les plugins, voir ci-dessous pour plus de détails. Par défaut, aucun plugin n'est activé ou désactivé.

dirsrv_dna_plugin

Par défaut : voir ci-dessous · Peut être changé : Oui

Configuration pour le plugin DNA (Attribution Numérique Distribuée).

dirsrv_custom_schema

Par défaut : [] · Peut être changé : Oui

Chemins vers des fichiers de schéma personnalisés. Ils seront déposés dans /etc/dirsrv/slapd-{{ dirsrv_serverid }}/schema et un rechargement de schéma sera demandé lorsque quelque chose changera.

dirsrv_allow_other_schema_files

Par défaut : false · Peut être changé : Oui

Si faux (valeur par défaut), ce rôle ajoutera les fichiers de schéma spécifiés à /etc/dirsrv/slapd-{{ dirsrv_serverid }}/schema, puis supprimera tous les autres fichiers de schéma là-bas sauf 99user.ldif. Si vos fichiers de schéma ne sont gérés que par ce rôle ou dynamiquement (c'est-à-dire à partir de cn=schema, qui écrit dans 99user.ldif), vous pouvez laisser cette variable à sa valeur par défaut de faux. Si vous avez d'autres fichiers de schéma dans ce répertoire (ajoutés manuellement ou par d'autres tâches), définissez cela sur vrai pour les laisser là. L'inconvénient est que si par exemple vous déployez 50example.ldif, puis que vous le renommez en 50my_example.ldif, lorsque le rôle s'exécute à nouveau, il considère que c'est un nouveau fichier et laisse l'ancien, créant des problèmes dans votre annuaire.

dirsrv_tls_enabled

Par défaut : false · Peut être changé : Oui

Activer TLS (LDAPS et StartTTLS). Toutes les variables "dirsrv_tls" n'ont effet que si cela est activé.

dirsrv_tls_min_version

Par défaut : '1.2' · Peut être changé : Oui

Version minimale TLS : 1.0, 1.1 ou 1.2. Possiblement même 1.3, si pris en charge par votre version 389DS. SSLv2 et SSLv3 sont toujours désactivés par ce rôle.

dirsrv_tls_certificate_trusted

Par défaut : true · Peut être changé : Oui

Le certificat du serveur est publiquement de confiance. Définissez sur faux uniquement en développement (pour les certificats auto-signés)!

dirsrv_tls_enforced

Par défaut : false · Peut être changé : Oui

Appliquer TLS en exigeant des connexions sécurisées et un SSF minimum.

dirsrv_tls_minssf

Par défaut : 256 · Peut être changé : Oui

SSF minimum, utilisé uniquement lorsque dirsrv_tls_enforced est vrai. 128 semble raisonnable, 256 devrait être très sécurisé. Définissez ceci sur 0 pour appliquer TLS uniquement avec des connexions sécurisées.

dirsrv_allow_anonymous_binds

Par défaut : 'rootdse' · Peut être changé : Oui

Autoriser des connexions anonymes : boolean true pour Oui, boolean false pour Non, ou 'rootdse'. Le Guide d'administration suggère d'utiliser rootdse au lieu de Non, car cela permet des connexions anonymes pour rechercher certaines données dont les clients pourraient avoir besoin avant de faire une connexion. Autoriser des connexions anonymes rend essentiellement votre annuaire public, à moins que vous ne restreigniez l'accès avec des ACI.

dirsrv_simple_auth_enabled

Par défaut : true · Peut être changé : Oui

Activer l'authentification SIMPLE, probablement vrai à moins que vous ne souhaitiez utiliser uniquement SASL PLAIN ou configurer d'autres méthodes manuellement.

dirsrv_password_storage_scheme

Par défaut : [] · Peut être changé : Oui

Une seule valeur, possiblement "PBKDF2_SHA256". Ou laissez le par défaut, qui supprimera toute valeur personnalisée et utilisera le par défaut de 389DS, qui devrait être assez sécurisé.

dirsrv_ldapi_enabled

Par défaut : false · Peut être changé : Oui

Activer LDAPI (connecter au serveur via un socket UNIX à ldapi:///var/run/dirsrv/slapd-{{ dirsrv_serverid }}.socket). Notez que cela est sujet à l'application de TLS et que TLS n'est pas pris en charge, donc c'est inutile si vous définissez dirsrv_tls_enforced sur vrai.

dirsrv_sasl_plain_enabled

Par défaut : true · Peut être changé : Oui

Activer l'authentification SASL PLAIN : si un client essaie de s'authentifier sans TLS et que TLS est appliqué, ce type d'authentification devrait l'arrêter avant qu'il n'envoie le mot de passe en clair, tandis qu'une liaison SIMPLE enverra le mot de passe et échouera ensuite parce que le SSF est trop bas.

Variables exclusives à la version 1.4.X de 389DS

Ces variables n'ont d'effet que sur les installations de la version 1.4.X de 389DS et n'ont aucun effet sur les versions précédentes même si elles sont définies.

dirsrv_defaults_version

Par défaut : 999999999² · Peut être changé : Non

Les valeurs de configuration par défaut seront celles de la version spécifiée de 389DS. Le format est XXXYYYZZZ, où XXX est la version principale, YYY est la version mineure et ZZZ est le niveau de correctif (les trois valeurs sont complétées par des zéros jusqu'à une longueur de trois). Si 999999999 est sélectionné, la dernière version des valeurs par défaut sera utilisée.

dirsrv_selfsigned_cert

Par défaut : True² · Peut être changé : Non

Détermine si 389DS générera un certificat auto-signé et activera automatiquement TLS.

dirsrv_selfsigned_cert_duration

Par défaut : 24² · Peut être changé : Non

Durée en mois du certificat auto-signé généré par 389DS.

dirsrv_create_suffix_entry

Par défaut : False² · Peut être changé : Non

Détermine si 389DS générera une entrée de suffixe dans l'annuaire avec le suffixe donné : cn={{ dirsrv_suffix }}

dirsrv_rundir

Peut être changé : Non

S'il est défini, configure un chemin spécifique pour db_home_dir.

dirsrv_rundir

Peut être changé : Non

S'il est défini, configure un chemin spécifique pour run_dir.

Interopérabilité entre 1.3.X et 1.4.X

Pour avoir un playbook qui se comporte de la même manière sur les versions 1.3 et 1.4 de 389DS, les valeurs suivantes devraient être utilisées :

Variable	Valeur
dirsrv_defaults_version	001004002³
dirsrv_selfsigned_cert	False
dirsrv_create_suffix_entry	True

Remarques

Certaines variables ne peuvent pas être changées par ce rôle (ou du tout) après la création d'une instance de 389DS. Si l'une d'entre elles est changée et que le rôle est réappliqué, un comportement non défini allant de "rien" à "le rôle échoue" peut se produire. Certaines d'entre elles, par exemple le mot de passe root DN, peuvent être changées manuellement : veuillez consulter le Guide d'administration pour les détails.

¹ Changer cette variable d'un précédent exécution entraînera la création d'une autre instance, un autre répertoire totalement séparé de l'ancien, ce qui devrait fonctionner tant que c'est votre objectif.

² Ce sont les valeurs par défaut de la version 1.4.2.15 de 389DS et peuvent changer pour les versions ultérieures : exécutez dscreate create-template sur votre machine pour voir le défaut pour la version actuelle.

³ C'est la version des valeurs par défaut sur laquelle ce rôle a été écrit et validé. Définir la dirsrv_defaults_version n'est pas techniquement requis, mais peut empêcher de futures mises à jour aux valeurs par défaut de casser le playbook en étant incompatibles avec 389DS 1.3. D'un autre côté, définir la variable "verrouillera" essentiellement la configuration dans le temps et, si ceci est fait pendant une longue période, pourrait la rendre obsolète. Utilisez avec prudence.

Toutes les variables sont préfixées par dirsrv car commencer un nom de variable par un nombre ("389ds") ne fonctionne pas très bien.

dirsrv_logging

Voici la variable par défaut :

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 ne fusionne pas les dictionnaires par défaut, c'est-à-dire que si vous voulez changer uniquement audit > enabled en vrai, vous devez également définir toutes les autres variables. Si vous souhaitez modifier les valeurs par défaut, il est probablement bon de copier tout ce bloc dans les variables et d'ajuster ce dont vous avez besoin.

dirsrv_plugins_enabled

Si vous souhaitez activer le plugin memberof situé à cn=MemberOf Plugin,cn=plugins,cn=config, définissez la variable sur :

dirsrv_plugins_enabled:
  MemberOf Plugin: true

S'il est activé et que vous souhaitez le désactiver, définissez-le sur :

dirsrv_plugins_enabled:
  MemberOf Plugin: false

Si vous souhaitez activer plus de plugins :

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

Si un plugin n'apparaît pas dans la liste, il est laissé dans son statut actuel.

Un plugin nommé Foo devrait avoir une entrée sous cn=Foo,cn=plugins,cn=config, vous pouvez consulter l'arborescence cn=plugins,cn=config pour voir quels plugins sont disponibles et leur statut.

dirsrv_dna_plugin

Valeur par défaut :

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

Ansible ne fusionne pas les dictionnaires par défaut, c'est-à-dire que si vous souhaitez changer uniquement uid_max et gid_max, vous devez également définir les variables _min. Lorsque vous définissez dirsrv_dna_plugin, cela remplace entièrement ce dictionnaire par défaut.

Cette configuration n'est appliquée que si "Distributed Numeric Assignment Plugin" est vrai dans dirsrv_plugins_enabled et est supprimée lorsqu'elle est fausse. Si elle n'est pas mentionnée, rien n'est fait.

dirsrv_replica_role doit être défini pour configurer DNA avec la réplication. Cette variable est également définie dans le rôle lvps/389ds-recplication, donc consultez celui-ci pour la documentation. Pour ce rôle, il suffit qu'elle soit définie si vous utilisez la réplication, la valeur n'a pas d'importance.

Dépendances

Aucune.

Utilisation et exemples

Exemple de fonctionnement minimum

- name: Un exemple de playbook
  hosts: example
  roles:
    - role: lvps.389ds_server
      dirsrv_rootdn_password: secret

Se connecter avec DN cn=Directory Manager et mot de passe secret sur le port 389, le suffixe sera dc=example,dc=local, tout le reste est principalement comme une installation propre de 389DS.

Ansible Vault serait une bonne idée pour éviter d'exposer le mot de passe root DN en clair en production.

Configurer le pare-feu

Pas partie de ce rôle, mais vous devrez peut-être ouvrir le port LDAP (389) pour accéder au serveur à distance :

- name: Autoriser le port ldap sur firewalld
  firewalld: service=ldap permanent=true state=enabled

Cela peut être nécessaire également pour le port LDAPS (636), si vous activez TLS et souhaitez utiliser cela au lieu de StartTLS.

Exemples d'entrées et quelques personnalisations

- name: Un exemple de playbook
  hosts: example
  roles:
    - role: lvps.389ds_server
      dirsrv_suffix: dc=custom,dc=example,dc=com
      dirsrv_rootdn: cn=admin
      dirsrv_rootdn_password: secret
      dirsrv_serverid: customized
      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"

Se connecter avec DN cn=admin et mot de passe secret sur le port 389, regarder les exemples d'entrées fournies par 389DS.

Les journaux d'audit sont également activés, et tous les journaux sont conservés pendant 14 jours (ou jusqu'à ce qu'ils deviennent trop volumineux).

Le plug-in MemberOf est également activé.

Consultez le répertoire molecule pour un fichier de schéma personnalisé qui fonctionne avec 389DS, si vous souhaitez tester cette partie mais n'avez pas de fichier de schéma valide. Supprimez cette partie pour enlever tous les fichiers de schéma personnalisés. Le rechargement de schéma se fait automatiquement.

TLS

- name: Un exemple de playbook
  hosts: example
  roles:
    - role: lvps.389ds_server
      dirsrv_suffix: "dc=example,dc=local"
      dirsrv_serverid: example
      dirsrv_rootdn_password: secret
      dirsrv_tls_enabled: true
      dirsrv_tls_cert_file: example_cert.pem
      dirsrv_tls_key_file: example.key
      dirsrv_tls_files_remote: false # Vrai si les fichiers sont déjà sur l'hôte distant (par exemple fournis par certbot)
      dirsrv_tls_certificate_trusted: true # Ou faux si auto-signé
      # Si vous souhaitez éviter LDAP en clair et appliquer TLS, considérez également ces paramètres :
      dirsrv_tls_enforced: true
      dirsrv_tls_minssf: 256
      # Rien à voir avec TLS, mais pour améliorer la sécurité, vous pouvez envisager :
      dirsrv_password_storage_scheme: "PBKDF2_SHA256"
      # bien que le schéma de stockage de mot de passe par défaut soit déjà suffisamment fort.

Voici un script pour générer des certificats auto-signés qui ont été testés à plusieurs reprises avec 389DS. Ou consultez le répertoire molecule pour un certificat et une clé d'exemple utilisés pour les tests du rôle.

Cependant, gardez à l'esprit que le script est fourni en exemple pour tester uniquement, il n'est pas recommandé pour une utilisation en production.

389DS est redémarré automatiquement si nécessaire pour appliquer la configuration. Les LDAPS (port 636) et StartTLS (port 389) sont activés.

Si vous en avez assez d'avoir une connexion sécurisée, définissez dirsrv_tls_enabled: false, mais le certificat restera dans la base de données NSS de 389DS. Il peut être supprimé manuellement.

Le changement de certificat (remplacement du certificat et de la clé par un nouveau, par exemple parce que les anciens ont expiré) semble fonctionner avec des certificats auto-signés et Let's Encrypt, mais le processus reste très compliqué et plein de hacks et contournements. Si vous souhaitez utiliser cela en production, il est conseillé de lire les parties pertinentes de la section 9.3 du Guide d'administration et les commentaires dans tasks/configure_tls.yml pour comprendre ce qui se passe et pourquoi.

TLS avec Let's Encrypt (ou d'autres fournisseurs ACME)

Le point clé est que vous devez fournir la "chaîne complète" (certificat serveur et tous les intermédiaires, sans certificat racine) au rôle 389ds-server. Comme je n'ai pas pu trouver beaucoup d'autres exemples sur le défi http-01 avec acme_certificate, j'ai ajouté cela ici pour vous donner une meilleure idée de toutes les étapes nécessaires.

- name: Un exemple de playbook
  hosts: example
  pre_tasks:
    - name: Assurez-vous que le compte ACME existe
      acme_account:
        # acme_directory: "http://..."  # Votre fournisseur. Laissez cela de côté pour utiliser le répertoire temporaire de Let's Encrypt
        account_key_content: "{{ acme_account_key }}"  # "openssl genrsa 2048" pour le générer, mais lisez https://docs.ansible.com/ansible/latest/modules/acme_account_module.html pour des informations plus à jour
        acme_version: 2
        state: present
        terms_agreed: true
        contact:
          - mailto:[email protected]

    # Vous avez besoin d'un CSR (demande de signature de certificat). Et d'une clé privée.
    # Ne réutilisez *pas* la clé de compte, faites-en une nouvelle !
    # Générez-les :
    #
    # 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"
    #
    # Seul le domaine est important. Les fichiers example.key et votre clé de compte doivent être gardés secrets,
    # vous pouvez les placer dans Ansible Vault et utiliser un modèle pour créer example.key à partir de la variable.
    - name: Copier CSR et clé privée
      copy:
        src: "{{ item }}"
        dest: "/etc/some/secret/directory"
        owner: root
        group: root
        mode: "400"  # Le csr peut être lisible par tous, en fait, ce n'est pas secret
        setype: cert_t
      loop:
        - "path/to/your/example.csr"
        - "path/to/your/example.key"

    - name: Créer le défi
      acme_certificate:
        acme_directory: "http://..."
        account_key_content: "{{ acme_account_key }}"
        acme_version: 2
        challenge: "http-01"
        # Vous aurez besoin de la chaîne complète (qui contient votre certificat et tous
        # les intermédiaires, mais pas le certificat racine). Cela sera alimenté dans
        # NSS/389DS, qui devrait tous les servir.
        fullchain: "/etc/some/secret/directory/example.fullchain.pem"
        csr: "/etc/some/secret/directory/example.csr"
        # remaining_days: 10
      register: acme_challenge

    # Vous avez besoin d'un serveur HTTP en cours d'exécution. Imaginez qu'il y ait une instance NGINX qui
    # sert des pages sur example.com depuis /var/www/html/example.com
    # Si vous trouvez qu'un serveur HTTP en cours d'exécution en permanence est ennuyeux, "when: acme_challenge est changé"
    # peut être utilisé pour le démarrer pour le défi et l'arrêter à la fin...
    #
    # Vous aurez également besoin de quelques répertoires, sinon la tâche suivante échouera parce qu'ils
    # n'existent pas...
    - name: Créer des répertoires HTTP pour le défi http-01 ACME
      file:
        name: "{{ item }}"
        state: directory
        owner: root
        group: root
        # Ceux-ci ne doivent pas être secrets (ils sont accessibles depuis Internet),
        # ne les rendez simplement pas modifiables par qui que ce soit
        mode: "755"
        setype: httpd_sys_content_t  # lecture seule
      loop:
        - "/var/www/html/example.com"
        - "/var/www/html/example.com/.well-known"
        - "/var/www/html/example.com/.well-known/acme-challenge"

    - name: Répondre au défi 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

    # Identique à la tâche acme_certificate précédente, juste ajouter "data"
    - name: Réaliser le défi
      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

    # Pas optimal (pendant quelques instants avant que cela ne se passe, le certificat a les
    # mauvaises permissions)
    # Il peut être possible de définir cette tâche sur "state: touch" et de la placer avant
    # la précédente, cependant.
    - name: Assurer les permissions pour le certificat exemple
      file:
        state: file
        path: "/etc/some/secret/directory/example.fullchain.pem"
        owner: root
        group: root
        mode: "400"
        setype: cert_t

  # Dans cet exemple, je n'ai presque utilisé aucune variable pour plus de clarté
  # (c'est-à-dire que vous voyez à quoi ces chaînes devraient ressembler, au lieu d'un nom arbitraire
  # que j'ai inventé), mais dans un vrai playbook, il peut être préférable d'utiliser
  # quelques variables.

  roles:
    - role: lvps.389ds_server
      dirsrv_suffix: "dc=example,dc=local"
      dirsrv_serverid: example
      dirsrv_rootdn_password: secret
      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  # Les deux fichiers sont sur le serveur
      dirsrv_tls_certificate_trusted: true  # Pas besoin de désactiver les vérifications de certificat, yay !

Puisque le passage de certificat est pris en charge par ce rôle, vous devez simplement exécuter ce playbook périodiquement pour mettre à jour le certificat lorsqu'il est sur le point d'expirer.

Et la réplication ?

Il y a un autre rôle pour cela.

Tests

Les tests utilisent le remplacement de systemctl docker créé et distribué par gdraheim sous la licence EUPL. Ce script est téléchargé et copié dans un conteneur local pour permettre l'exécution correcte des tests. Une telle distribution se fait sous la même licence et les mêmes conditions que celles sur lesquelles gdraheim a créé et publié son œuvre. Le script est téléchargé tel quel et aucune modification n'y est apportée. En exécutant les tests sur leurs machines, l'utilisateur final accepte de traiter le script téléchargé selon les mêmes termes de l'EUPL que ceux prévus par son auteur. Notez que les tests eux-mêmes (et le rôle dans son ensemble) sont toujours sous licence Apache 2.

Ce rôle utilise molecule pour ses tests. Installez-la probablement avec pip et testez tous les scénarios :

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

Ou pour tester un seul scénario : molecule test -s tls

Extensions futures

Pourrait être fait, mais pas prévu à court terme

Support pour Debian/Ubuntu/FreeBSD ou toute autre plateforme supportée par 389DS
Support pour d'autres plugins qui nécessitent plus qu'activé/désactivé
Support pour d'autres attributs DNA

Licence

Apache 2.0 pour le rôle et les tests associés
EUPL v 1.2 pour le script "remplacement de docker systemctl" par gdraheim (non inclus mais téléchargé lors de l'exécution des tests)

Information sur l'auteur

Mainteneur : Ludovico Pavesi
Contributeur/auteur original : Colby Prior
Contributeur/auteur original : Artemii Kropachev
Merci à Firstyear pour les commentaires

À propos du projet

Installs 389DS LDAP server. Also configures TLS, logging, custom schema files, enable/disable plugins, DNA plugin for UID/GID, LDAPI and SASL PLAIN.

role ldap

Installer

ansible-galaxy install lvps.389ds_server

GitHub référentiel

25 étoiles

17 forks

5 problèmes ouverts

Licence

apache-2.0

Téléchargements

80.6k

Propriétaire

lvps

Serveur 389ds

Fonctionnalités

Prérequis

Variables du rôle

dirsrv_product

dirsrv_port

dirsrv_suffix

dirsrv_bename

dirsrv_othersuffixes

dirsrv_rootdn

dirsrv_rootdn_password

dirsrv_fqdn

dirsrv_serverid

dirsrv_listen_host

dirsrv_secure_listen_host

dirsrv_server_uri

dirsrv_factory

dirsrv_install_examples

dirsrv_install_additional_ldif

dirsrv_ldif_files_remote

dirsrv_install_additional_ldif_dir

dirsrv_logging

dirsrv_plugins_enabled

dirsrv_dna_plugin

dirsrv_custom_schema

dirsrv_allow_other_schema_files

dirsrv_tls_enabled

dirsrv_tls_min_version

dirsrv_tls_certificate_trusted

dirsrv_tls_enforced

dirsrv_tls_minssf

dirsrv_allow_anonymous_binds

dirsrv_simple_auth_enabled

dirsrv_password_storage_scheme

dirsrv_ldapi_enabled

dirsrv_sasl_plain_enabled

Variables exclusives à la version 1.4.X de 389DS

dirsrv_defaults_version

dirsrv_selfsigned_cert

dirsrv_selfsigned_cert_duration

dirsrv_create_suffix_entry

dirsrv_rundir

dirsrv_rundir

Interopérabilité entre 1.3.X et 1.4.X

Remarques

dirsrv_logging

dirsrv_plugins_enabled

dirsrv_dna_plugin

Tags

Dépendances

Utilisation et exemples

Exemple de fonctionnement minimum

Configurer le pare-feu

Exemples d'entrées et quelques personnalisations

TLS

TLS avec Let's Encrypt (ou d'autres fournisseurs ACME)

Et la réplication ?

Tests

Extensions futures

Pourrait être fait, mais pas prévu à court terme

Licence

Information sur l'auteur

Installs 389DS LDAP server. Also configures TLS, logging, custom schema files, enable/disable plugins, DNA plugin for UID/GID, LDAPI and SASL PLAIN.