gihyo.jpサイトのロゴ

そろそろLDAPにしてみないか？

第20回OpenLDAPの冗長化対策【2】

2009-04-02

最初に

前回「基本形」としてお伝えしていたOpenLDAPのsyncrepl機能ですが、まずは記事の内容で少し補足です。

これまで「マスターとなるサーバはサプライヤ、スレーブとなるサーバはコンシューマ」と記述していましたが、OpenLDAPの場合はそれぞれ、プロバイダ、コンシューマと呼ぶのが一般的でした。サプライヤという用語も間違いでは無いのですが、こちらは主にSun Java Directory ServerやRed Hat Directory Serverなどで使用されている用語ですので、OpenLDAPに合わせるためここからは「プロバイダ」に統一するようにします。

syncreplが提供するレプリケーション

一般的なデータベースの冗長構成ではデータの完全同期が期待さることが多いかもしれません。たとえば、2台のDBサーバが存在したとして、完全同期のレプリケーションでは、クライアントが一方のサーバに新規データを登録した瞬間に最新のデータが2台のDBサーバ上に作成されていると保証されますので、すべてのクライアントはどのDBサーバに接続しても常に同じ結果を得ることができます。

一方、非同期のレプリケーションでは常に同じデータが全サーバに保存されているとは限らないため、DB登録の1分後に最新データがもう一方のDBサーバに反映される可能性もあります。

OpenLDAPのsyncrepl機能もまた非同期のレプリケーションですが、設定次第で

  • 極力リアルタイムにレプリケーションを行う
  • 適度なインターバルをもってレプリケーションを行う

といったことが可能です。通常の用途では前者を選択することが多いと思いますが、たとえばデータの更新頻度が少ない環境で、1時間など長めのインターバルを持たせておくことにより、サーバ負荷の軽減につながるのはもちろんのこと、誤ってプロバイダ側のデータを削除してしまった場合でも、最大1時間以内であればコンシューマ側に以前のデータが残っているため随時ロールバックを行うことができるようになるという特徴もあります（運悪く、事故発生直後に同期が行われてしまうとロールバックもできませんが…⁠）⁠。

refreshOnlyとrefreshAndPersist

前述の2通りのレプリケーションですが、具体的にはslapd.conf中のrefreshOnlyとrefreshAndPersistという項目が設定の鍵になります。

refreshOnlyを指定する場合、コンシューマは定期的にプロバイダの389/tcpにTCPセッションを張ることでデータの同期を試みます（polling方式⁠）⁠。

一方、refreshAndPersistの場合は文字通り接続の維持が行われるため、コンシューマはプロバイダの389/tcpにセッションを張り続け、更新データの有無をリアルタイムにプロバイダから受け取ることができます（listening方式⁠）⁠。では、それぞれの具体的な設定を見ていきましょう。

まず、プロバイダ側で準備する内容はリスト1の通りで、それほど特別な設定は必要ありません。

リスト1　プロバイダ側の/etc/openldap/slapd.conf
# レプリケーションのためのインデックス（後述）
index entryCSN,entryUUID eq 
index objectClass        eq,pres

# syncrepl用のモジュールをロード
overlay         syncprov

次に、コンシューマ側はリスト2、3のようになります（わかりやすいよう各所にコメントを入れていますが、実際にはこの場所にコメントは許されていないため注意してください⁠）⁠。

リスト2　refreshOnly時の設定（5分間隔で同期を行う）
syncrepl rid=100                        # コンシューマ識別ID（数字3桁）
  provider=ldap://10.0.100.21:389       # プロバイダの接続先とポート
  type=refreshOnly                      # レプリケーション方式（定期的な更新確認）
  interval=00:00:05:00                  # 接続間隔（5分）
  searchbase="dc=example,dc=com"        # 同期を行う対象の検索ベース
  bindmethod=simple                     # 認証モード
  binddn="cn=Manager,dc=example,dc=com" # バインドDN
  credentials=secret                    # バインドパスワード
リスト3　refreshAndPersist時の設定（なるべくリアルタイムに同期を行う）
syncrepl rid=100                        # コンシューマ識別ID（数字3桁）
  provider=ldap://10.0.100.21:389       # プロバイダの接続先とポート 
  type=refreshAndPersist                # レプリケーション方式（接続維持を行う）
  retry="5 10 300 +"                    # 接続失敗した場合のリトライ間隔
  searchbase="dc=example,dc=com"        # 同期を行う対象の検索ベース
  bindmethod=simple                     # 認証モード
  binddn="cn=Manager,dc=example,dc=com" # バインドDN
  credentials=secret                    # バインドパスワード

これらの挙動の違いをさらに理解するために、tcpdumpによりパケットをキャプチャしつつプロバイダ側に新規データを登録し、一連の様子を見てみます。

リスト4　refreshOnly時のキャプチャ結果
01:55:32.035247 IP 10.0.100.22.51995 > 10.0.100.21.389: S 2972302010:2972302010(0) win 5840 <mss 1460,sackOK,timestamp 66828619 0,nop,wscale 6> 
01:55:32.035493 IP 10.0.100.21.389 > 10.0.100.22.51995: S 2447691039:2447691039(0) ack 2972302011 win 5792 <mss 1460,sackOK,timestamp 217778436 66828619,nop,wscale 7> 
01:55:32.035510 IP 10.0.100.22.51995 > 10.0.100.21.389: . ack 1 win 92 <nop,nop,timestamp 66828619 217778436> 
01:55:32.035644 IP 10.0.100.22.51995 > 10.0.100.21.389: P 1:49(48) ack 1 win 92 <nop,nop,timestamp 66828619 217778436> 
01:55:32.035780 IP 10.0.100.21.389 > 10.0.100.22.51995: . ack 49 win 46 <nop,nop,timestamp 217778436 66828619> 
01:55:32.036386 IP 10.0.100.21.389 > 10.0.100.22.51995: P 1:15(14) ack 49 win 46 <nop,nop,timestamp 217778436 66828619> 
01:55:32.036394 IP 10.0.100.22.51995 > 10.0.100.21.389: . ack 15 win 92 <nop,nop,timestamp 66828619 217778436> 
01:55:32.036534 IP 10.0.100.22.51995 > 10.0.100.21.389: P 49:206(157) ack 15 win 92 <nop,nop,timestamp 66828619 217778436> 
01:55:32.036913 IP 10.0.100.21.389 > 10.0.100.22.51995: P 15:66(51) ack 206 win 54 <nop,nop,timestamp 217778436 66828619> 
01:55:32.036958 IP 10.0.100.22.51995 > 10.0.100.21.389: P 206:213(7) ack 66 win 92 <nop,nop,timestamp 66828619 217778436> 
01:55:32.037007 IP 10.0.100.22.51995 > 10.0.100.21.389: F 213:213(0) ack 66 win 92 <nop,nop,timestamp 66828619 217778436> 
01:55:32.037212 IP 10.0.100.21.389 > 10.0.100.22.51995: F 66:66(0) ack 213 win 54 <nop,nop,timestamp 217778436 66828619> 
01:55:32.037220 IP 10.0.100.22.51995 > 10.0.100.21.389: . ack 67 win 92 <nop,nop,timestamp 66828619 217778436> 
01:55:32.037228 IP 10.0.100.21.389 > 10.0.100.22.51995: . ack 214 win 54 <nop,nop,timestamp 217778436 66828619> 

02:00:32.037537 IP 10.0.100.22.40337 > 10.0.100.21.389: S 3389899619:3389899619(0) win 5840 <mss 1460,sackOK,timestamp 66903620 0,nop,wscale 6> 
02:00:32.037821 IP 10.0.100.21.389 > 10.0.100.22.40337: S 2858513305:2858513305(0) ack 3389899620 win 5792 <mss 1460,sackOK,timestamp 217808436 66903620,nop,wscale 7> 
02:00:32.037838 IP 10.0.100.22.40337 > 10.0.100.21.389: . ack 1 win 92 <nop,nop,timestamp 66903620 217808436> 
02:00:32.037917 IP 10.0.100.22.40337 > 10.0.100.21.389: P 1:49(48) ack 1 win 92 <nop,nop,timestamp 66903620 217808436> 
02:00:32.038052 IP 10.0.100.21.389 > 10.0.100.22.40337: . ack 49 win 46 <nop,nop,timestamp 217808436 66903620> 
02:00:32.038730 IP 10.0.100.21.389 > 10.0.100.22.40337: P 1:15(14) ack 49 win 46 <nop,nop,timestamp 217808436 66903620> 
02:00:32.038738 IP 10.0.100.22.40337 > 10.0.100.21.389: . ack 15 win 92 <nop,nop,timestamp 66903620 217808436> 
02:00:32.038827 IP 10.0.100.22.40337 > 10.0.100.21.389: P 49:206(157) ack 15 win 92 <nop,nop,timestamp 66903620 217808436> 
02:00:32.040482 IP 10.0.100.21.389 > 10.0.100.22.40337: P 15:694(679) ack 206 win 54 <nop,nop,timestamp 217808436 66903620> 
02:00:32.040492 IP 10.0.100.21.389 > 10.0.100.22.40337: P 694:1299(605) ack 206 win 54 <nop,nop,timestamp 217808436 66903620> 
02:00:32.040497 IP 10.0.100.22.40337 > 10.0.100.21.389: . ack 1299 win 134 <nop,nop,timestamp 66903620 217808436> 
02:00:32.040501 IP 10.0.100.21.389 > 10.0.100.22.40337: P 1299:1904(605) ack 206 win 54 <nop,nop,timestamp 217808436 66903620> 
02:00:32.040724 IP 10.0.100.21.389 > 10.0.100.22.40337: P 1904:2006(102) ack 206 win 54 <nop,nop,timestamp 217808436 66903620> 
02:00:32.040733 IP 10.0.100.22.40337 > 10.0.100.21.389: . ack 2006 win 153 <nop,nop,timestamp 66903620 217808436> 
02:00:32.055063 IP 10.0.100.22.40337 > 10.0.100.21.389: P 206:213(7) ack 2006 win 153 <nop,nop,timestamp 66903624 217808436> 
02:00:32.055077 IP 10.0.100.22.40337 > 10.0.100.21.389: F 213:213(0) ack 2006 win 153 <nop,nop,timestamp 66903624 217808436> 
02:00:32.055326 IP 10.0.100.21.389 > 10.0.100.22.40337: F 2006:2006(0) ack 214 win 54 <nop,nop,timestamp 217808438 66903624> 
02:00:32.055334 IP 10.0.100.22.40337 > 10.0.100.21.389: . ack 2007 win 153 <nop,nop,timestamp 66903624 217808438> 

02:05:32.040132 IP 10.0.100.22.56558 > 10.0.100.21.389: S 3801473658:3801473658(0) win 5840 <mss 1460,sackOK,timestamp 66978620 0,nop,wscale 6> 
02:05:32.040392 IP 10.0.100.21.389 > 10.0.100.22.56558: S 3269951867:3269951867(0) ack 3801473659 win 5792 <mss 1460,sackOK,timestamp 217838436 66978620,nop,wscale 7> 
02:05:32.040412 IP 10.0.100.22.56558 > 10.0.100.21.389: . ack 1 win 92 <nop,nop,timestamp 66978620 217838436> 
02:05:32.040441 IP 10.0.100.22.56558 > 10.0.100.21.389: P 1:49(48) ack 1 win 92 <nop,nop,timestamp 66978620 217838436> 
02:05:32.040664 IP 10.0.100.21.389 > 10.0.100.22.56558: . ack 49 win 46 <nop,nop,timestamp 217838436 66978620> 
02:05:32.041292 IP 10.0.100.21.389 > 10.0.100.22.56558: P 1:15(14) ack 49 win 46 <nop,nop,timestamp 217838436 66978620> 
02:05:32.041300 IP 10.0.100.22.56558 > 10.0.100.21.389: . ack 15 win 92 <nop,nop,timestamp 66978620 217838436> 
02:05:32.041398 IP 10.0.100.22.56558 > 10.0.100.21.389: P 49:206(157) ack 15 win 92 <nop,nop,timestamp 66978620 217838436> 
02:05:32.041893 IP 10.0.100.21.389 > 10.0.100.22.56558: P 15:66(51) ack 206 win 54 <nop,nop,timestamp 217838436 66978620> 
02:05:32.041937 IP 10.0.100.22.56558 > 10.0.100.21.389: P 206:213(7) ack 66 win 92 <nop,nop,timestamp 66978621 217838436> 
02:05:32.042001 IP 10.0.100.22.56558 > 10.0.100.21.389: F 213:213(0) ack 66 win 92 <nop,nop,timestamp 66978621 217838436> 
02:05:32.042186 IP 10.0.100.21.389 > 10.0.100.22.56558: F 66:66(0) ack 213 win 54 <nop,nop,timestamp 217838437 66978621> 
02:05:32.042194 IP 10.0.100.22.56558 > 10.0.100.21.389: . ack 67 win 92 <nop,nop,timestamp 66978621 217838437> 
02:05:32.042202 IP 10.0.100.21.389 > 10.0.100.22.56558: . ack 214 win 54 <nop,nop,timestamp 217838437 66978621>

コンシューマ側のslapdを起動すると、まずは最新データ同期のためにプロバイダへの接続が行われます（赤字部分⁠）⁠。この最終行を見ると、FINフラグによりTCP接続が一旦切られていることが分かります。その後intervalで指定した5分が経過すると、コンシューマはプロバイダに対して新たなTCPセッションを確立し、データの同期確認と要求を行っています。このように、同期確認の度にTCPセッション張り直すのがrefreshOnlyの特徴です。

次はrefreshAndPersist時の結果です。

リスト5　refreshAndPersist時のキャプチャ結果
01:29:10.377858 IP 10.0.100.22.36157 > 10.0.100.21.389: S 3928508035:3928508035(0) win 5840 <mss 1460,sackOK,timestamp 66433204 0,nop,wscale 6> 
01:29:10.378147 IP 10.0.100.21.389 > 10.0.100.22.36157: S 3406805294:3406805294(0) ack 3928508036 win 5792 <mss 1460,sackOK,timestamp 217620270 66433204,nop,wscale 7> 
01:29:10.378165 IP 10.0.100.22.36157 > 10.0.100.21.389: . ack 1 win 92 <nop,nop,timestamp 66433205 217620270> 
01:29:10.378226 IP 10.0.100.22.36157 > 10.0.100.21.389: P 1:49(48) ack 1 win 92 <nop,nop,timestamp 66433205 217620270> 
01:29:10.378417 IP 10.0.100.21.389 > 10.0.100.22.36157: . ack 49 win 46 <nop,nop,timestamp 217620270 66433205> 
01:29:10.379048 IP 10.0.100.21.389 > 10.0.100.22.36157: P 1:15(14) ack 49 win 46 <nop,nop,timestamp 217620270 66433205> 
01:29:10.379056 IP 10.0.100.22.36157 > 10.0.100.21.389: . ack 15 win 92 <nop,nop,timestamp 66433205 217620270> 
01:29:10.379228 IP 10.0.100.22.36157 > 10.0.100.21.389: P 49:206(157) ack 15 win 92 <nop,nop,timestamp 66433205 217620270> 
01:29:10.379588 IP 10.0.100.21.389 > 10.0.100.22.36157: P 15:52(37) ack 206 win 54 <nop,nop,timestamp 217620270 66433205> 
01:29:10.421379 IP 10.0.100.22.36157 > 10.0.100.21.389: . ack 52 win 92 <nop,nop,timestamp 66433215 217620270> 

01:29:19.877158 IP 10.0.100.21.389 > 10.0.100.22.36157: P 52:711(659) ack 206 win 54 <nop,nop,timestamp 217621220 66433215> 
01:29:19.877173 IP 10.0.100.22.36157 > 10.0.100.21.389: . ack 711 win 112 <nop,nop,timestamp 66435579 217621220> 
01:29:24.507106 IP 10.0.100.21.389 > 10.0.100.22.36157: P 711:1370(659) ack 206 win 54 <nop,nop,timestamp 217621683 66435579> 
01:29:24.507118 IP 10.0.100.22.36157 > 10.0.100.21.389: . ack 1370 win 133 <nop,nop,timestamp 66436737 217621683> 

01:29:28.850948 IP 10.0.100.22.36157 > 10.0.100.21.389: P 206:213(7) ack 1370 win 133 <nop,nop,timestamp 66437823 217621683> 
01:29:28.850966 IP 10.0.100.22.36157 > 10.0.100.21.389: F 213:213(0) ack 1370 win 133 <nop,nop,timestamp 66437823 217621683> 
01:29:28.851690 IP 10.0.100.21.389 > 10.0.100.22.36157: F 1370:1370(0) ack 214 win 54 <nop,nop,timestamp 217622117 66437823> 
01:29:28.851703 IP 10.0.100.22.36157 > 10.0.100.21.389: . ack 1371 win 133 <nop,nop,timestamp 66437823 217622117>

まず、OpenLDAPを起動すると先ほど同様、最新データ同期のため赤字部分の通信が発生します。しかし赤字部分の最終行を見れば分かるとおり、389/tcpへの接続は維持されたままです。

次に、プロバイダ側に新規データを2件追加すると、青字部分のパケットが発生します。プロバイダからコンシューマに向けてデータがプッシュされていることが分かるはずです。最後に、コンシューマ側のslapdを停止させると、レプリケーションのために接続維持されていたプロバイダ側への接続が緑時部分で失われています。

注意点としては、接続維持中にプロバイダ側を再起動してしまうと、コンシューマの接続維持が失われてしまい、それ以降データの同期が行われなくなってしまいます。そのためには、retryパラメータを使って定期的にリトライを行うようにします。この例では5秒間隔で10回の接続を試行し、それでも接続できない場合は300秒（5分）おきにリトライを繰り返すようになります。

このように、常にコンシューマがプロバイダに対してセッションを張りっぱなしにしておくのがrefreshAndPersistの特徴です。

同期対象エントリの把握

2通りのレプリケーションがあることはわかりましたが、それぞれの方法でコンシューマはどのようにして同期対象のデータを把握し取得するのか見ていきましょう。

まずキーワードとなるのはentryCSN（Change Sequence Number）というLDAP属性です。この値は、通常ldapsearchコマンドで見かけることは無いかもしれませんが、次のように属性を指定すればクライアントから確認することができます。

図1　entryCSN属性の確認
% ldapsearch -x -D "cn=Manager,dc=example,dc=com" -w secret -b "dc=example,dc=com" "objectClass=*" entryCSN 

# example.com 
dn: dc=example,dc=com 
entryCSN: 20090328154606.075631Z#000000#000#000000 

# Group, example.com 
dn: ou=Group,dc=example,dc=com 
entryCSN: 20090328154606.151415Z#000000#000#000000

内容から容易に想像できるように、entryCSN属性は日付をベースにした識別値です。この値はエントリを追加した際、または更新した際に新たに付与されるもので、他のDNにはないユニークな値となっています。

まずは、コンシューマ側に何もデータが無い状態で、これから初めてレプリケーションを行うものとします。コンシューマはまず、slapd.confに指定されたバインドDNやパスワード、検索ベースなどを用いて、プロバイダ側に接続し、エントリを全て取得し、ダウンロードします。

このとき、コンシューマはプロバイダ側から得られた最新のentryCSNを取得、記憶しておきます。そして次回以降の同期要求の際には、バインドDN、パスワード、検索ベースなどと同様、このentryCSNを検索条件に加え、前回取得したCSNよりも大きな値が見つかった場合にはそのエントリを取得し同期する（エントリ削除の場合は削除メッセージを受け取る⁠）⁠、という挙動でレプリケーションを実現しています。

コンシューマに対する更新要求

同期のタイミングを考慮しないものとすれば、基本的に両サーバにはいつでも最新のデータが保存されているため、クライアントはプロバイダ、コンシューマ、どちらに接続しても同じ検索結果を得ることができます。つまり、複数のクライアントを複数のサーバに接続させることで、検索の負荷分散を行うことができるようになっています。しかしデータの更新についてはどうでしょうか？コンシューマに無理矢理データを登録しようとすると次のようなエラーが発生します。

図2　コンシューマにデータを登録しようとしたときのメッセージ
adding new entry "ou=1238266045,dc=example,dc=com" 
ldap_add: Server is unwilling to perform (53) 
	additional info: shadow context; no update referral

これは当然のことで、仮にプロバイダではなくコンシューマのデータだけが更新されてしまうと、データの整合性が保たれなくなってしまいます。従って、更新要求が発生した場合には、正しい更新先をupdate referralという形でクライアントに伝える必要があるのです。

そのため、slapd.confに次のような設定を加え、コンシューマへの更新要求はプロバイダにリダイレクトするようにしておきます。

リスト6
# 更新のためにプロバイダを使用する
updateref ldap://10.0.100.21:389

こうすることによってエラー内容が次のように変わります。

図3　コンシューマにデータを登録
adding new entry "ou=1238266045,dc=example,dc=com" 
ldap_add: Referral (10) 
	referrals: 
		ldap://10.0.100.21:389/ou=1238266192,dc=example,dc=com

やはりエラーにはなってしまうのですが、その中には「ldap://10.0.100.21:389/でデータの登録を行うように」と指定されているため、賢いクライアントであれば、ユーザにエラーを表示することなくプロバイダ側のデータを更新することができます。

ちなみに、コンシューマから返されたこのメッセージをエラーとしてユーザに見せるのか、または親切にリダイレクト先を更新するのか、はクライアント側のソフトウェアの実装次第です。

セキュアなレプリケーション用DN

refreshOnly、refreshAndPersist、どちらを選択するにせよ、Web上の多くの文献では、

「レプリケーション用にcn=Manager,dc=example,dc=comを使用していますが、実際にはセキュリティを考慮してレプリケーションの専用DNを使ってください」

といった記述を見かけます。事実筆者も今まで多くの場合このような解説をしてきました。ですが、たまには実用性を考慮して、専用DNを作成することでセキュリティの向上につなげたいと思います。今回は

dn: cn=replication,dc=example,dc=com

というDNをレプリケーション専用のDNとすることにしましょう。まずはプロバイダ側でエントリの作成です（userPasswordの値はabc123という文字列を暗号化したもので、slappasswdコマンドによって作成しています⁠）⁠。

リスト7　replication.ldif
dn: cn=replication,dc=example,dc=com 
objectClass: person 
cn: replication 
sn: replication account 
userPassword: {SSHA}+cGs2GJzG38V76E3KZIu3W0ZsZWTZTLh

ではいつものようにエントリを登録します。

図4
% ldapadd -x -D "cn=Manager,dc=example,dc=com" -w secret -f replication.ldif                  
adding new entry "cn=replication,dc=example,dc=com"

次に、このDNを用いてレプリケーションを行うことができるよう、プロバイダ側のslapd.confで適切なACLを設定します。単に

access to *
  by dn="cn=replication,dc=example,dc=com" write

としてしまっては、万が一レプリケーション用のパスワードが漏洩した場合にプロバイダのエントリが漏洩、または改ざんされてしまう可能性もありますので、

  • cn=replication用の権限は全エントリの閲覧のみ（データ更新の必要はない）
  • cn=replicationはコンシューマからのみ利用される（接続元を指定）

を実現することで、レプリケーション用DNはコンシューマからのみ安全に利用できるようになります。

リスト8　slapd.confの一部
access to attrs=userPassword 
  by self write 
  by dn="cn=replication,dc=example,dc=com" peername.ip=10.0.100.22 read 
  by dn="cn=replication,dc=example,dc=com" peername.ip=0.0.0.0%0.0.0.0 none 
  by anonymous auth 
  by * none 
access to * 
  by dn="cn=replication,dc=example,dc=com" peername.ip=10.0.100.22 read 
  by dn="cn=replication,dc=example,dc=com" peername.ip=0.0.0.0%0.0.0.0 none 
  by self write 
  by * read

まとめ

今回はOpenLDAPの基本形となる2通りのレプリケーション方法を解説してきました。2台以上のLDAPサーバを立て、クライアントが複数のサーバを参照することで、障害時の冗長性はもちろんのこと、サービスの負荷分散を実現することができます。

しかし実際には様々な課題が存在します。まずはこの方式で冗長性を実現させるためには、クライアントに複数のLDAPサーバを指定する必要があります。たとえば、Linux OSでLDAP認証を実現させるための/etc/ldap.confでは

uri ldap://接続先1/ ldap://接続先2/

というフォーマットが許可されています。しかし、ソフトウェアによっては接続先が1つか指定できない場合があります。その場合にはクライアントが複数のサーバを選択するクライアント方式ではなく、ロードバランサ＋仮想IPを用いてサーバ側で接続先のコントロールを行う必要があります。

それ以外でも、更新頻度の多いLDAPサーバの場合は書き込みの負荷分散や冗長性を保つことができないため、さらなる対策が必要です。これらの課題については次回以降触れていくことにしましょう。

設定ファイル

今回の設定ファイル全体を貼り付けておきますので、参考にしてみてください。

リスト9　プロバイダ
include		/etc/openldap/schema/core.schema 
include		/etc/openldap/schema/cosine.schema 
include		/etc/openldap/schema/inetorgperson.schema 
include		/etc/openldap/schema/nis.schema 

pidfile		/var/run/openldap/slapd.pid 
argsfile	/var/run/openldap/slapd.args 

database	bdb 
suffix          "dc=example,dc=com" 
rootdn          "cn=Manager,dc=example,dc=com" 
rootpw		secret 
directory	/var/lib/ldap 
loglevel        256 
 
index objectClass         eq,pres 
index entryCSN,entryUUID  eq 

access to attrs=userPassword 
  by self write 
  by dn="cn=replication,dc=example,dc=com" peername.ip=10.0.100.22 read 
  by dn="cn=replication,dc=example,dc=com" peername.ip=0.0.0.0%0.0.0.0 none 
  by anonymous auth 
  by * none 
access to * 
  by dn="cn=replication,dc=example,dc=com" peername.ip=10.0.100.22 read 
  by dn="cn=replication,dc=example,dc=com" peername.ip=0.0.0.0%0.0.0.0 none 
  by self write 
  by * read 

overlay syncprov
リスト10　コンシューマ
include		/etc/openldap/schema/core.schema 
include		/etc/openldap/schema/cosine.schema 
include		/etc/openldap/schema/inetorgperson.schema 
include		/etc/openldap/schema/nis.schema 

pidfile		/var/run/openldap/slapd.pid 
argsfile	/var/run/openldap/slapd.args 

database	bdb 
suffix          "dc=example,dc=com" 
rootdn          "cn=Manager,dc=example,dc=com" 
rootpw		secret 
directory	/var/lib/ldap 
loglevel        256 

index objectClass         eq,pres 
index entryCSN,entryUUID  eq 

access to attrs=userPassword 
  by self write 
  by dn="cn=replication,dc=example,dc=com" peername.ip=0.0.0.0%0.0.0.0 none 
  by anonymous auth 
  by * none 
access to * 
  by dn="cn=replication,dc=example,dc=com" peername.ip=0.0.0.0%0.0.0.0 none 
  by self write 
  by * read 

# 即時レプリケーションを行う場合
syncrepl rid=100 
  provider=ldap://10.0.100.21:389 
  type=refreshAndPersist 
  retry="5 10 300 +" 
  searchbase="dc=example,dc=com" 
  bindmethod=simple 
  binddn="cn=Manager,dc=example,dc=com" 
  credentials=secret

# 定期的にレプリケーションを行う場合
#syncrepl rid=100 
#  provider=ldap://10.0.100.21:389 
#  type=refreshOnly 
#  interval=00:00:60:00 
#  searchbase="dc=example,dc=com" 

#  bindmethod=simple 
#  binddn="cn=Manager,dc=example,dc=com" 
#  credentials=secret 

updateref ldap://10.0.100.21:389

おすすめ記事

記事・ニュース一覧