389ds-replication

389DSサーバー（LDAPサーバー）インスタンス間でのレプリケーションを設定します。

ansible-galaxy install lvps.389ds_replication

要件

• Ansibleバージョン: 2.7以上
• OS: CentOS 7

ldap_attrsモジュールがサポートされていない場合、古いコレクションのバージョンを使用していますが、このロールの1.0.xバージョンを試すことができます。

ロール変数

変数名	デフォルト	説明	変更可否	ロール
dirsv_replication_role		このサーバーの役割: 'supplier'（供給者）、'consumer'（消費者）、または'both'（マスター）。ハブはサポートされていません。	いいえ
dirsrv_server_uri	"ldap://localhost"	設定するサーバーのURI。Ansibleターゲット上で実行されるため、localhostで問題ありません。TLSを使用するにはldaps://localhostに設定可能です。		CSB
dirsrv_rootdn	"cn=Directory Manager"	ルートDN（管理者アカウントのユーザー名）		CSB
dirsrv_rootdn_password	secret	ルートDNアカウントのパスワード		CSB
dirsrv_use_starttls	true	サーバーに接続するためにStartTLSを使用する		CSB
dirsrv_tls_certificate_trusted	true	TLS証明書が信頼できるCAからのものである場合は真、自己署名またはプライベートCAの場合は偽。TLSを使用していない場合は未使用。		CSB
dirsrv_serverid	default	サーバーID（インスタンスID）、例えばサーバーがdirsrv/slapd-exampleディレクトリにインストールされている場合、「example」がサーバーIDになります。		CSB
dirsrv_suffix	dc=example,dc=local	ルートサフィックス		CSB
dirsrv_supplier_replica_id	1	1から65534の間で番号を選択します。他のサーバーに割り当てないでください。問題が発生する可能性があります。	いいえ	SB
dirsrv_consumer_uri	"ldap://consumer.example.com:389/"	供給者が接続して変更をプッシュするフルURI（ポートを含む）。	いいえ	SB
dirsrv_replication_user_remote	Replication Manager	消費者に存在するユーザーアカウント。供給者はこのアカウントでバインドしてレプリケーションを行います。「Replication Manager」は、アカウントが「cn=Replication Manager,cn=config」の意味です。	はい	SB
dirsrv_replication_user_password_remote		レプリケーションユーザー（Replication Manager）アカウントのパスワード	はい	SB
dirsrv_replica_bind_method	"PLAIN"	供給者が消費者に接続するために使用するバインド方法(SIMPLE, PLAIN, SASL)。	はい	SB
dirsrv_changelog_max_age	"10d"	nsslapd-changelogmaxageの値を設定します。	はい	SB
dirsrv_replica_attributes_list	"(objectclass=*) $ EXCLUDE authorityRevocationList accountUnlockTime memberof"	nsds5ReplicatedAttributeListの値を設定します。この変数のデフォルトは、ドキュメント内の例で使用されます。	はい	SB
dirsrv_replica_attributes_list_total	"(objectclass=*) $ EXCLUDE accountUnlockTime"	nsds5ReplicatedAttributeListTotalの値を設定します。この変数のデフォルトもドキュメントの例で使用されます。	はい	SB
dirsrv_replication_user	Replication Manager	消費者に作成されるユーザーアカウント。このアカウントは供給者によってこのサーバー（消費者）にバインドするために使用されます。「Replication Manager」はアカウントが「cn=Replication Manager,cn=config」に作成されることを意味します。	はい	CB
dirsrv_replication_user_password		このアカウントのパスワード。	はい	CB
dirsrv_begin_replication_immediately	true	ブール値、レプリケーション契約内のnsds5ReplicaEnabledを「on」または「off」に設定します。安全なはずです。新しいサーバーを追加しても、別の世代IDを持っているため、空のデータベースを他のサーバーにプッシュすることはありません。しかし、より安全にするため、またはレプリケーション契約にカスタマイズを加えたい場合は、これを偽に設定します。	いいえ	CB
dirsrv_consumer_referral_to_supplier	"ldap://supplier.example.com:389/"	フルLDAP URI（ポートを含む）。クライアントが読み取り専用の消費者に書き込もうとすると、このサーバー（書き込みを受け入れる供給者）にリダイレクトします。	はい	C

最初にサーバーが供給者、消費者、または両方のいずれかを選択し、dirsv_roleを適切に設定します。それに関連する変数を設定します。ロールカラムでCは消費者、Sは供給者、Bは両方を意味します。

一度設定された変数は変更できない場合があります。変更すると予期しない結果（「何も起こらない」から「ロールが失敗する」まで）を引き起こす可能性があります。他の変数（認証情報、サフィックスなど）は、サーバーに適した値に設定する必要があり、意味のある範囲で変更できます。例えば、root DNパスワードを変更した場合、dirsrv_rootdn_passwordを変更して正しく認証できるようにすることができますが、同じサーバーでの実行間でdirsrv_suffixを変更することは無意味です。

以下の変数は、389ds-serverロールと同じ名前と意味を持っているため、同じプレイブックで両方のロールを使用する場合は、一度だけ定義できます。

• dirsrv_rootdn
• dirsrv_rootdn_password
• dirsrv_tls_certificate_trusted
• dirsrv_serverid
• dirsrv_suffix

依存関係

なし。

ただし、このロールは389DSが既に稼働していることを前提としています。他のサーバー間のレプリケーションを構成するだけです。

例プレイブック

389DSを最初からインストールし、それをテストするために必要なVagrant設定を含むさらなる例は、389ds-examplesリポジトリで利用可能です。

通常、レプリケーションはすぐには開始されないことに注意してください。これは、サーバー間で"レプリカ生成"が異なるためです。これを解決するには、「レプリカリフレッシュ」手順が必要で、これはたとえば、管理ガイドのセクション15.2.5で説明されています。供給者または両方のロールを持つサーバーで実行する必要があります。

基本的に、「レプリカリフレッシュ」を実行すると、1つの供給者から消費者にデータベースが強制的にプッシュされ、以前の消費者データベースが置き換えられます。この手順は、最初に1つの供給者から始めて、他の供給者に向かって徐々に進めてください。ただし、プロダクションデータベースを新しくインストールされたサーバーの空のデータベースで上書きしないように注意してください。2つのサーバーがまったく同じデータベースを持っていると、レプリケーションが自動的に開始されます。

この手順についての詳細は、389ds-examplesリポジトリでも説明されています。

消費者と供給者

まず消費者を構成します。このサーバーにはデータベースの読み取り専用コピーが含まれます：

- hosts: consumer
  become: true

  roles:
    -
      role: lvps.389ds_replication
      dirsrv_replica_role: consumer
      dirsrv_suffix: "dc=example,dc=local"
      dirsrv_server_uri: "ldap://localhost"
      dirsrv_rootdn_password: secret
      dirsrv_replication_user_password: foo # このパスワードでcn=Replication Manager,cn=configを作成します
      dirsrv_consumer_referral_to_supplier: "ldap://supplier.example.local:389/"

次に供給者を構成します。このサーバーは書き込みを受け入れ、すべての変更を消費者にプッシュします：

- hosts: supplier
  become: true

  roles:
    -
      role: lvps.389ds_replication
      dirsrv_replica_role: supplier
      dirsrv_suffix: "dc=example,dc=local"
      dirsrv_server_uri: "ldap://localhost"
      dirsrv_rootdn_password: verysecret
      dirsrv_replication_user_password_remote: foo # 他のサーバーでcn=Replication Manager,cn=configにこのパスワードでバインドします
      dirsrv_consumer_uri: "ldap://consumer.example.local:389/" # 上記で定義した消費者
      dirsrv_supplier_replica_id: 123

マルチマスター環境の構成

- hosts: mm1
  become: true
  roles:
    -
      role: lvps.389ds_replication
      dirsrv_replica_role: 'both'
      dirsrv_suffix: "dc=example,dc=local"
      dirsrv_server_uri: "ldap://localhost"
      dirsrv_rootdn_password: secret1
      dirsrv_replication_user_password: "aaaaaa"
      dirsrv_replication_user_password_remote: "bbbbbb" # 他のサーバーで
      dirsrv_consumer_uri: "ldap://mm2.example.local:389/" # 他のサーバー
      dirsrv_supplier_replica_id: 1

- hosts: mm2
  become: true
  roles:
    -
      role: lvps.389ds_replication
      dirsrv_replica_role: 'both'
      dirsrv_suffix: "dc=example,dc=local"
      dirsrv_server_uri: "ldap://localhost"
      dirsrv_rootdn_password: secret2
      dirsrv_replication_user_password: "bbbbbb"
      dirsrv_replication_user_password_remote: "aaaaaa" # 他のサーバーで
      dirsrv_consumer_uri: "ldap://mm1.example.local:389/" # 他のサーバー
      dirsrv_supplier_replica_id: 2

既知のバグ

dirsrv_replication_user_passwordが変更されると、変更が報告されません。これは、パスワードが実際には毎回変更されるためです（Ansibleは以前のハッシュ化されたパスワードが新しいものと同じかどうかを判断できないため、変更されて再ハッシュ化されます）が、changed_when: falseというオプションでその詳細が隠されています。

ライセンス

MIT。