lvps.389ds_server

389ds-server

この役割は、ターゲットマシンに389DSサーバー（LDAPサーバー）をインストールします。

ansible-galaxy install lvps.389ds_server

機能

単一のLDAPサーバーをインストール
ロギングの設定
カスタムスキーマファイルの追加
プラグインの有効化/無効化
UID/GID番号のためのDNAプラグインの設定
TLSの設定
TLSを強制（最低SSFと安全なバインドを要求）またはオプションのTLSに戻す
LDAPIの有効化/無効化
SASL PLAINの有効化/無効化

レプリケーションは別の役割で管理されます。

要件

Ansible 2.10以上。Ansible 2.8および2.9を使用する場合は、この役割の3.1.xリリースを使用
SUSE（OpenSUSEまたはSLES）、CentOS 7、CentOS 8、CentOS 9、またはその他のRHELベースのOS

役割変数

この役割に渡すことができる変数とその簡単な説明は以下の通りです。

dirsrv_product

デフォルト: OS依存 · 変更可能: いいえ

無料の389ディレクトリサーバーとサポートされているRed Hatディレクトリサーバーの2つの主要なブランチがあります。無料のリリースではデフォルト設定を信頼できます。必要に応じてこの値を設定できます。現在のところ、テストされた唯一の非デフォルト値はRed Hat EL8 OSのRed Hat Directory Server 11のための'@redhat-ds:11'です。

dirsrv_port

デフォルト: 389 · 変更可能: いいえ

389dsがリッスンするポート。

dirsrv_suffix

デフォルト: dc=example,dc=com · 変更可能: いいえ

DITのサフィックス。すべてのエントリはこのサフィックスの下に配置されます。通常、会社の主要ドメインのドメインコンポーネント（dc）から作成されます。例：あなたがexample.co.ukに属していて、サーバーがldap-server.example.co.ukにある場合、サフィックスをdc=example,dc=co,dc=ukに設定します。サブドメイン部分（ldap-server）は無関係なので省略します。

dirsrv_bename

デフォルト: userRoot · 変更可能: いいえ

サフィックスの内部データベース名。

dirsrv_othersuffixes

デフォルト: [] · 変更可能: いいえ

他のサフィックス辞書のリスト（形式：{ name: <bename>, dn: <rootDN>}）

dirsrv_rootdn

デフォルト: cn=Directory Manager · 変更可能: いいえ

ルートDNまたは「管理者」アカウントのユーザー名。このDNでバインドすると、すべての認可制御をバイパスできます。

dirsrv_rootdn_password

変更可能: いいえ

ルートDNのパスワード。この変数を定義しなければならず、そうしないと役割は失敗します。

dirsrv_fqdn

デフォルト: {{ansible_nodename}} · 変更可能: いいえ

サーバーのFQDN（例えば、ldap.example.com）。サーバーホスト名がすでにFQDNである場合、デフォルトでそれを取得します。

dirsrv_serverid

デフォルト: default · 変更可能: ¹

サーバーIDまたはインスタンスID。この役割によって構成されたインスタンスに関連するすべてのデータは/etc/dirsrv/slapd-*default*、/var/log/dirsrv/slapd-*default*などに保存されます。会社名を使えます。例えば、Foo Bar, Incの場合、変数をfoobarに設定すると、ディレクトリはslapd-foobarと名付けられます。

dirsrv_listen_host

変更可能: はい

これらのアドレス/ホスト名でリッスンします。設定しない場合（デフォルト）は何もしません。文字列に設定すると、nsslapd-listenhost属性を設定します。[]に設定すると、属性が削除されます。

dirsrv_secure_listen_host

変更可能: はい

dirsrv_listen_hostと同様ですがLDAPS用です。設定しない場合（デフォルト）は何もしません。文字列に設定すると、nsslapd-securelistenhost属性が設定されます。[]に設定すると属性が削除されます。

dirsrv_server_uri

デフォルト: ldap://localhost · 変更可能: ¹

LDAP経由で接続するタスクのためのサーバーURI。タスクは通常389DSと同じサーバー上で実行されるため、ほとんどの場合はlocalhostになりますので、カスタマイズする必要はありません。

dirsrv_factory

デフォルト: false · 変更可能: はい

認証およびロギングパラメータに関する工場デフォルトを維持します。trueの場合、dirsrv_logging, dirsrv_simple_auth_enabled, dirsrv_password_storage_scheme, dirsrv_ldapi_enabled, dirsrv_sasl_plain_enabledは完全に無視されます。

dirsrv_install_examples

デフォルト: false · 変更可能: いいえ

インストール中にサフィックスの下に例のエントリを作成します。

dirsrv_install_additional_ldif

デフォルト: [] · 変更可能: いいえ

デフォルトで何もインストールせず（空の配列）、これらの追加のLDIFファイルをインストールします。これは、389DS <= 1.3のインストールファイル内のInstallLdifFileディレクティブに対応しています。1.4以降は、これをdsconf経由で実行します。

dirsrv_ldif_files_remote

デフォルト: false · 変更可能: はい

ldifファイルがリモートサーバー上にあり、Ansibleコントローラーにはありません。

dirsrv_install_additional_ldif_dir

デフォルト: /var/lib/dirsrv/slapd-{{ dirsrv_serverid }}/ldif · 変更可能: いいえ

dirsrv_install_additional_ldifのためのldifファイルが一時的に保存されるディレクトリ。CentOS/RHEL 8.3以降は、389DSサービスにsystemd PrivateTmpがtrue設定されているため、/tmpにはできません。

dirsrv_logging

デフォルト: 下記参照 · 変更可能: はい

下記参照

dirsrv_plugins_enabled

デフォルト: {} · 変更可能: はい

プラグインを有効または無効にします。詳細は下記参照。デフォルトでは、プラグインは有効でも無効でもありません。

dirsrv_dna_plugin

デフォルト: 下記参照 · 変更可能: はい

DNA（分散数字割り当て）プラグインの設定。

dirsrv_custom_schema

デフォルト: [] · 変更可能: はい

カスタムスキーマファイルへのパス。これらは/etc/dirsrv/slapd-{{ dirsrv_serverid }}/schemaに配置され、何か変更があったときにスキーマのリロードが要求されます。

dirsrv_allow_other_schema_files

デフォルト: false · 変更可能: はい

false（デフォルト値）の場合、この役割は指定されたスキーマファイルを/etc/dirsrv/slapd-{{ dirsrv_serverid }}/schemaに追加し、他のスキーマファイルは99user.ldifを除いて削除します。このディレクトリに他のスキーマファイルがある場合（手動または別のタスクによって追加された場合）、これをtrueに設定しておくと、そのまま残ります。デメリットは、例えば50example.ldifをデプロイし、それを50my_example.ldifに名前変更した場合、役割が再度実行されるとそれを新しいファイルと見なして以前のものをそこに残し、ディレクトリに混乱をもたらすことです。

dirsrv_tls_enabled

デフォルト: false · 変更可能: はい

TLS（LDAPSおよびStartTTLS）を有効にします。すべての"dirsrv_tls"変数は、これが有効な場合のみ影響します。

dirsrv_tls_min_version

デフォルト: '1.2' · 変更可能: はい

最小TLSバージョン：1.0、1.1、または1.2。サポートされている場合は1.3も含めてもよい。SSLv2およびSSLv3は常にこの役割によって無効になります。

dirsrv_tls_certificate_trusted

デフォルト: true · 変更可能: はい

サーバー証明書が公的に信頼されています。開発用（自己署名証明書の場合）にのみfalseに設定してください！

dirsrv_tls_enforced

デフォルト: false · 変更可能: はい

安全なバインドと最低SSFを要求することによってTLSを強制します。

dirsrv_tls_minssf

デフォルト: 256 · 変更可能: はい

最低SSF。dirsrv_tls_enforcedがtrueのときのみ使用されます。128は妥当と思われ、256は非常に強力です。TLSを安全なバインドだけで強制するには、これを0に設定します。

dirsrv_allow_anonymous_binds

デフォルト: 'rootdse' · 変更可能: はい

匿名バインドを許可します：boolean trueははい、boolean falseはいいえ、または'rootdse'です。管理ガイドでは、クライアントがバインドする前に必要なデータを検索するのに役立つため、Noではなくrootdseを使用することを推奨しています。匿名バインドを許可することは、基本的にディレクトリを公開することを意味します。ACIsでアクセスを制限する場合を除きます。

dirsrv_simple_auth_enabled

デフォルト: true · 変更可能: はい

SIMPLE認証を有効にします。おそらくtrueですが、SASL PLAINのみを使用したい場合や他の方法を手動で設定したい場合はfalseに設定することがあります。

dirsrv_password_storage_scheme

デフォルト: [] · 変更可能: はい

単一の値、可能性として文字列 "PBKDF2_SHA256"。デフォルトを維持すれば、カスタム値が削除され、389DSのデフォルトが使用されます。デフォルトは非常に安全です。

dirsrv_ldapi_enabled

デフォルト: false · 変更可能: はい

LDAPIを有効にします。（ldapi:///var/run/dirsrv/slapd-{{ dirsrv_serverid }}.socketでUNIXソケット経由でサーバーに接続します）。これはTLSの強制に従うことに注意してください。TLSはサポートされず、したがってdirsrv_tls_enforcedをtrueに設定すると無意味です。

dirsrv_sasl_plain_enabled

デフォルト: true · 変更可能: はい

SASL PLAIN認証を有効にします：クライアントがTLSなしで認証しようとし、TLSが強制されている場合、この種の認証はプレーンテキストのパスワードを送信する前に停止すべきであり、SIMPLEバインドはパスワードを送信した後、SSFが低すぎるため失敗します。

変数は389DSバージョン1.4.X専用

これらの変数は389DSバージョン1.4.Xのインストールにのみ影響し、先行バージョンで定義されていても効果はありません。

dirsrv_defaults_version

デフォルト: 999999999² · 変更可能: いいえ

デフォルトの設定値は、指定された389DSのバージョンのものになります。形式はXXXYYYZZZで、XXXはメジャーバージョン、YYYはマイナーバージョン、ZZZはパッチレベル（すべての値は3桁の長さに0で埋められます）です。999999999が選択されると、最新バージョンのデフォルトが使用されます。

dirsrv_selfsigned_cert

デフォルト: True² · 変更可能: いいえ

389DSが自己署名証明書を生成して自動的にTLSを有効にするかどうかを決定します。

dirsrv_selfsigned_cert_duration

デフォルト: 24² · 変更可能: いいえ

389DSによって生成された自己署名証明書の有効性（ヶ月）。

dirsrv_create_suffix_entry

デフォルト: False² · 変更可能: いいえ

389DSが指定されたサフィックスでディレクトリにサフィックスエントリを生成するかどうかを決定します：cn={{ dirsrv_suffix }}

dirsrv_rundir

変更可能: いいえ

定義されている場合、db_home_dirのための特定のパスを構成します。

dirsrv_rundir

変更可能: いいえ

定義されている場合、run_dirの特定のパスを設定します。

1.3.Xと1.4.Xの相互運用性

1.3および1.4バージョンの389DSで同じように振舞うプレイブックを持つためには、以下の値を使用する必要があります：

変数	値
dirsrv_defaults_version	001004002³
dirsrv_selfsigned_cert	False
dirsrv_create_suffix_entry	True

注意事項

いくつかの変数は、389DSのインスタンスを作成した後にこの役割によって変更できません（またはまったく変更できません）。これらの変数の1つが変更され、もう一度役割が適用されると、「何もしない」から「役割が失敗する」までの未定義の動作が発生する可能性があります。例えば、ルートDNのパスワードのようなものは手動で変更できます。詳細は管理ガイドを参照してください。

¹この変数を前の実行から変更すると、別のインスタンス（前のものとは完全に別のディレクトリ）が作成されます。これは目的であれば正常に機能します。

²これらは389DSバージョン1.4.2.15時点のデフォルト値であり、以降のバージョンで変更される可能性があります。現在のバージョンのデフォルトを確認するには、dscreate create-templateを実行してください。

³これは、この役割が書かれ、検証されたデフォルトのバージョンです。dirsrv_defaults_versionを設定することは技術的には必須ではありませんが、将来のデフォルトの更新によってプレイブックが壊れるのを防ぐことができますが、389DS 1.3と互換性がなくなる可能性があります。一方で、この変数を設定すると、構成が固定されるため、長い間行うと時代遅れになる可能性があります。注意して使用してください。

すべての変数はdirsrvで接頭辞が付いています。なぜなら、変数名を数字（"389ds"）で始めることはあまり機能しないからです。

dirsrv_logging

これはデフォルト変数です：

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はデフォルトでは辞書をマージしないため、たとえばaudit > enabledをtrueに変更したい場合は、他のすべての変数も定義する必要があります。デフォルトを変更したい場合は、理想的にはこの全ブロックを変数にコピーして、必要なものを調整するのが良いでしょう。

dirsrv_plugins_enabled

cn=MemberOf Plugin,cn=plugins,cn=configにあるMemberOfプラグインを有効にしたい場合は、次のように変数を設定します：

dirsrv_plugins_enabled:
  MemberOf Plugin: true

有効化されていて、無効にしたい場合は、次のように設定します：

dirsrv_plugins_enabled:
  MemberOf Plugin: false

その他のプラグインを有効にしたい場合：

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

リストにプラグインが表示されていない場合、それは現在のステータスのままになります。

cn=Foo,cn=plugins,cn=configの下には、Fooという名前のプラグインが必要です。どのプラグインが利用可能か、またそのステータスを確認するには、cn=plugins,cn=configツリーを参照できます。

dirsrv_dna_plugin

デフォルト値：

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

Ansibleはデフォルトで辞書をマージしないため、uid_maxとgid_maxのみを変更する場合は、_min変数も定義する必要があります。dirsrv_dna_pluginを定義すると、デフォルトの辞書全体が置き換えられます。

この設定は、"Distributed Numeric Assignment Plugin"がdirsrv_plugins_enabledでtrueの場合にのみ適用され、falseの場合は削除されます。触れられない場合、何も実行されません。

dirsrv_replica_roleは、レプリケーションを設定するために定義する必要があります。その変数はlvps/389ds-replication役割でも定義されているため、ドキュメントを参照してください。この役割にとっては、レプリケーションを使用している場合は、値は重要ではなく、その変数が定義されていれば十分です。

dirsrv_certは、ACMEを使用した自動証明書管理に特に便利です：以下の「Let's Encrypt（または他のACMEプロバイダー）を使用したTLS」の例を参照してください。同じタグをすべてのACME関連タスクに追加すれば、定期的にansible-playbook some-playbook.yml --tags dirsrv_certを実行して自動的に証明書を更新できます。

依存関係

なし。

使い方と例

最小限の動作例

- name: An example playbook
  hosts: example
  roles:
    - role: lvps.389ds_server
      dirsrv_rootdn_password: secret

ポート389でDN cn=Directory Managerとパスワードsecretでバインドし、サフィックスはdc=example,dc=localになります。その他はほぼクリーンな389DSインストールと同様です。

Ansible Vaultを使用すると、本番環境でルートDNのパスワードがプレーンテキストで露出するのを避けることができます。

ファイアウォールの設定

この役割の一部ではありませんが、サーバーにリモートでアクセスするためにはLDAPポート（389）を開く必要があります：

- name: Allow ldap port on firewalld
  firewalld: service=ldap permanent=true state=enabled

TLSを有効にしてその代わりに使用する場合、LDAPSポート（636）にも同様のことが必要な場合があります。

例のエントリとカスタマイズの一部

- name: An example 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"

ポート389でDN cn=adminとパスワードsecretでバインドし、389DSによって提供された例のエントリを確認します。

監査ログも有効になり、すべてのログは14日間保持されます（または大きくなるまで）。

MemberOf Pluginも有効になっています。

テスト用のカスタムスキーマファイルはmoleculeディレクトリにあります。有効なスキーマファイルがない場合は、そちらで試してみてください。その部分を削除すれば、すべてのカスタムスキーマファイルを削除します。スキーマのリロードは自動的に行われます。

TLS

- name: An example 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 # すでにリモートホストにファイルがある場合はTrue（例：certbotが提供）
      dirsrv_tls_certificate_trusted: true # それとも自己署名の場合はfalse
      # プレーンLDAPを避け、TLSを強制する場合は、これらの設定も考慮してください：
      dirsrv_tls_enforced: true
      dirsrv_tls_minssf: 256
      # TLSとは無関係ですが、セキュリティを向上させるために次の設定を考慮するかもしれません：
      dirsrv_password_storage_scheme: "PBKDF2_SHA256"
      # デフォルトのパスワードストレージスキームはすでに十分強力ですが。

こちらで389DSで繰り返しテストされた自己署名証明書を生成するスクリプトを見つけることができます。また、役割テストに使用される証明書とキーの例もmoleculeディレクトリ内に見つかります。

ただし、このスクリプトはテスト専用の例として提供されているため、本番環境での使用はお勧めしません。

389DSは、構成を適用するために必要な場合に自動的に再起動されます。LDAPS（ポート636）とStartTLS（ポート389）が両方とも有効になります。

安全な接続に疲れた場合は、dirsrv_tls_enabled: falseに設定しますが、証明書は389DS NSSデータベースに残ります。手動で削除できます。

証明書のロールオーバー（証明書とキーを新しいものに差し替えるプロセス、例えば古いものが失効した場合）は、自己署名やLet's Encrypt証明書で機能するようですが、このプロセスはいまだに非常に複雑で、ハックやワークアラウンドで満ちています。本番環境で使用したい場合は、管理ガイドのセクション9.3やtasks/configure_tls.ymlのコメントを読み、何が起こっているのか、なぜそうなっているのかを理解することをお勧めします。

Let's Encrypt（または他のACMEプロバイダー）を使用したTLS

重要なのは、"fullchain"（サーバー証明書とすべての中間証明書、ルート証明書は含まない）を389ds-server役割に供給する必要があることです。 acme_certificateを使用したhttp-01チャレンジの他の例があまり見つからなかったので、必要なすべてのステップを示すためにこれを追加しました。

- name: An example playbook
  hosts: example
  pre_tasks:
    - name: Ensure ACME account exists
      acme_account:
        # acme_directory: "http://..."  # あなたのプロバイダー。Let's Encryptのステージングディレクトリを使用するにはこれを外してください
        account_key_content: "{{ acme_account_key }}"  # "openssl genrsa 2048"で生成しますが、最新の情報を確認するにはhttps://docs.ansible.com/ansible/latest/modules/acme_account_module.htmlを読んでください
        acme_version: 2
        state: present
        terms_agreed: true
        contact:
          - mailto:[email protected]

    # CSR（証明書署名要求）と秘密鍵が必要です。
    # アカウントキーを再利用しないでください、新しいものを作成してください！
    # 生成します：
    #
    # 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"
    #
    # ドメインのみが重要です。example.keyとアカウントキーの両方は秘密に保持する必要があります。
    # それらをAnsible Vaultに配置し、テンプレートを使用して変数からexample.keyを生成することもできます。
    - name: Copy CSR and private key
      copy:
        src: "{{ item }}"
        dest: "/etc/some/secret/directory"
        owner: root
        group: root
        mode: "400"  # CSRは実際には誰でも読み取り可能ではなく、秘密ではありません
        setype: cert_t
      loop:
        - "path/to/your/example.csr"
        - "path/to/your/example.key"

    - name: Create challenge
      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"
        # remaining_days: 10
      register: acme_challenge

    # HTTPサーバーが稼働中である必要があります。example.comから/var/www/html/example.comを提供するNGINXインスタンスがあるとします。
    # 常に稼働するHTTPサーバーが煩わしいと感じる場合は、"when: acme_challenge is changed"を使用して、
    # チャレンジのためのみ実行し、終了時に停止することができます。
    #
    # 次のタスクは、ディレクトリが存在しないため失敗するので、いくつかのディレクトリが必要になります......
    - name: Create HTTP directories for ACME http-01 challenge
      file:
        name: "{{ item }}"
        state: directory
        owner: root
        group: root
        # これらは秘密にする必要はありません（インターネットからアクセス可能です）。
        # 誰にも書き込み可能にはしないでください。
        mode: "755"
        setype: httpd_sys_content_t  # 読み取り専用
      loop:
        - "/var/www/html/example.com"
        - "/var/www/html/example.com/.well-known"
        - "/var/www/html/example.com/.well-known/acme-challenge"

    - name: Fulfill the http-01 challenge
      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

    # acme_certificateタスクと同じですが、"data"を追加します。
    - name: Do challenge
      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

    # 最適ではありません（このタスクが実行される前の数瞬間に、証明書が
    # 誤った権限を持っている可能性があるため）。
    # このタスクを"state: touch"に設定し、前のものの前に配置することができる可能性があります。
    - name: Ensure permissions for example certificate
      file:
        state: file
        path: "/etc/some/secret/directory/example.fullchain.pem"
        owner: root
        group: root
        mode: "400"
        setype: cert_t

  # この例では、より大きな明瞭さのためにほとんどの変数を使用していませんでした。
  # （つまり、これらの文字列がどのように見えるべきかを示します。私が考案した恣意的な名前ではなく）。
  # ただし、実際のプレイブックではいくつかの変数を使用する方が良いかもしれません。

  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  # 両方のファイルはサーバー上にあります
      dirsrv_tls_certificate_trusted: true  # 証明書のチェックを無効にする必要はありません、やったね！

証明書のロールオーバーはこの役割でサポートされているため、証明書が期限切れになる前に更新するために、定期的にこのプレイブックを実行する必要があります。

レプリケーションについては？

それについては別の役割があります。

テスト

テストは、docker systemctl replacementスクリプトを使用します。このスクリプトは、gdraheimによってEUPLライセンスの下で作成および配布されています。このスクリプトはダウンロードされ、ローカルコンテナにコピーされ、テストが正しく実行されるようにします。このような配布は、gdraheimの作成および公開時の同じライセンスと条件の下で行われます。スクリプトはそのままダウンロードされ、いかなる変更も行われません。ユーザーがテストを実行すると、ダウンロードされたスクリプトを著者の意図したEUPLの条件に従って扱うことに同意します。テスト自体（および役割全体）は、Apache 2ライセンスの下に引き続きライセンスされています。

この役割は、テストのためにmoleculeを使用します。おそらくpipでインストールし、すべてのシナリオをテストします：

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

または、単一のシナリオをテストするには：molecule test -s tls

将来の拡張

できるが、短期的には計画されていないもの

Debian/Ubuntu/FreeBSDまたは389DSがサポートする他のプラットフォームのサポート
有効化/無効化以外の操作を必要とする他のプラグインのサポート
その他のDNA属性のサポート

ライセンス

役割および関連するテストについてはApache 2.0を使用
「docker systemctl replacement」スクリプトについてはgdraheimによるEUPL v 1.2（含まれていませんが、テストを実行するときにダウンロードされます）

著者情報

メンテナー: Ludovico Pavesi
貢献者/元著者: Colby Prior
貢献者/元著者: Artemii Kropachev
Firstyearに感謝します。コメント

プロジェクトについて

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

インストール

ansible-galaxy install lvps.389ds_server

GitHub リポジトリ

25 スター

17 フォーク

5 オープンな問題

ライセンス

apache-2.0

ダウンロード

80.6k

所有者

lvps