レプリケーションで冗長構成：OpenLDAPで始めるディレクトリサーバ構築（5）（2/3 ページ）

» 2009年05月01日 00時00分公開

[菊池研自，伊藤忠テクノソリューションズ株式会社]

スレーブサーバの設定

　次は、スレーブサーバの設定です。slapd.confのグローバルセクションにはユーザーのアクセス制御に必要となる「access to」ディレクティブと、動作確認時に利用するログを出力するための「loglevel」ディレクティブを追加します。

[root@slave]# vi /etc/openldap/slapd.conf

  include         /etc/openldap/schema/core.schema

  include         /etc/openldap/schema/cosine.schema

  include         /etc/openldap/schema/inetorgperson.schema

  include         /etc/openldap/schema/nis.schema

  ……[略]……

  access to dn.subtree="ou=People,dc=my-domain,dc=com" attrs=shadowLastChange

  by self write

  by * read



access to dn.regex=".*,ou=(People|Group),dc=my-domain,dc=com$" attrs=userPassword

  by self write

  by anonymous auth



access to dn.subtree="dc=my-domain,dc=com"

  by * read

  ……[略]……

  loglevel stats sync

　続いて、データベースセクションに、「index」ディレクティブ、マスタサーバへの接続を定義する「syncrepl」ディレクティブ、スレーブサーバへ直接の更新リクエストがあった場合にリクエスト元のクライアントへ更新可能なマスタサーバを伝える「updateref」ディレクティブを追加します。

[root@slave]# vi /etc/openldap/slapd.conf

  ……[略]……

  database        bdb

  suffix          "dc=my-domain,dc=com"

  rootdn          "cn=Manager,dc=my-domain,dc=com"

  rootpw          secret

  directory       /var/lib/ldap

  ……[続き]……

  index objectClass                       eq,pres

  index ou,cn,mail,surname,givenname      eq,pres,sub

  index uidNumber,gidNumber,loginShell    eq,pres

  index uid,memberUid                     eq,pres,sub

  index entryCSN,entryUUID         eq            ←複製処理にインデックスを利用



syncrepl rid=123                                   ←レプリカIDは、123

    provider=ldap://192.168.1.10:389/           ←接続先のマスタサーバ

    type=refreshAndPersist retry="60 3 300 +" ←複製方式と再接続時のタイミング

    searchbase="dc=my-domain,dc=com"            ←検索方式

    bindmethod=sasl saslmech=DIGEST-MD5         ←認証方式

    authcid=repl credentials=password           ←複製ユーザーとパスワード

  

  updateref       ldap://192.168.1.10:389/       ←更新リクエストには、マスタを案内

　また、後の動作確認でログファイルを利用しますので、このタイミングで、連載第2回にて説明したように、syslog.confを編集した後syslogdを再起動し、OpenLDAPからのログを「/var/log/ldap.log」へ出力するように設定しておいてください。

レプリケーションの開始

　スレーブサーバのslapd.conf編集後は、スレーブサーバを起動することでsyncprovモジュールがマスタサーバへの接続を開始します。接続が確立した時点でマスタサーバが検索され、スレーブサーバへデータが転送されます。

[root@slave]# service ldap start

  [root@slave]# lsof -n -i tcp:ldap

  COMMAND   PID USER?? FD   TYPE   DEVICE SIZE NODE NAME

  slapd   30611 ldap   7u  IPv6 144589558       TCP *:ldap (LISTEN)

  slapd   30611 ldap   8u  IPv4 144589559       TCP *:ldap (LISTEN)

  slapd   30611 ldap  16u  IPv4 144589591       TCP 192.168.1.20:53677->192.168.1.10:ldap (ESTABLISHED)

　ここまでの設定どおりにレプリケーションが成功すると、マスタサーバのログに、以下のようにスレーブサーバからSASL認証を用いて接続した「repl」ユーザーが検索処理を実行したログが確認できるはずです。反対にレプリケーションが失敗する場合は、このログに記録された情報を手掛かりに、原因を追究することになります。

[root@master]# tail -f /var/log/ldap.log

  ……[略]……

  conn=1 fd=15 ACCEPT from IP=192.168.1.20:53675 (IP=0.0.0.0:389)

  conn=1 op=0 BIND dn="" method=163

  conn=1 op=0 RESULT tag=97 err=14 text=

  conn=1 op=1 BIND dn="" method=163

  conn=1 op=1 BIND authcid="repl@my-domain.com" authzid="repl@my-domain.com"

  conn=1 op=1 BIND dn="cn=repl,dc=my-domain,dc=com" mech=DIGEST-MD5 ssf=128

  conn=1 op=1 RESULT tag=97 err=0 text=

  conn=1 op=2 SRCH base="dc=my-domain,dc=com" scope=2 deref=0 filter="(objectClass=*)"

  conn=1 op=2 SRCH attr=* +

レプリケーション動作の確認

　次は、マスタサーバに更新リクエストを送り、スレーブサーバに更新が伝播することを確認しましょう。今回は、連載第3回で説明した手順でユーザーエントリを登録し、LDAPクライアント認証を設定しているマスタサーバ上でtest1000ユーザーのパスワードを変更することで動作確認とします。

[root@master]# su - test1000

  [test1001@master]$ passwd

  Changing password for user test1000.

  Enter login(LDAP) password:test1000

  New UNIX password:1qazxsw2

  Retype new UNIX password:1qazxsw2

  LDAP password information changed for test1000

  passwd: all authentication tokens updated successfully.

　このとき、マスタサーバ、スレーブサーバのログを参照することで動作確認はスムーズに行えます。まずは、マスタサーバのログでuserPasswordに関連する属性が2つ変更されることを確認しておきましょう。

[root@master]# tail -f /var/log/ldap.log

  ……[略]……

  conn=5 op=5 MOD dn="uid=test1000,ou=People,dc=my-domain,dc=com"

  conn=5 op=5 MOD attr=userPassword

  conn=5 op=5 RESULT tag=103 err=0 text=

  conn=5 op=6 MOD dn="uid=test1000,ou=People,dc=my-domain,dc=com"

  conn=5 op=6 MOD attr=shadowLastChange

  conn=5 op=6 RESULT tag=103 err=0 text=

　次は、スレーブサーバのログを確認してみましょう。

[root@slave]# tail -f /var/log/ldap.log

  ……[略]……

  syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY)

  syncrepl_entry: be_search (0)

  syncrepl_entry: uid=test1000,ou=People,dc=my-domain,dc=com

  syncrepl_entry: be_modify (0)

  syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY)

  syncrepl_entry: be_search (0)

  syncrepl_entry: uid=test1000,ou=People,dc=my-domain,dc=com

  syncrepl_entry: be_modify (0)

　スレーブサーバでも対象DN「uid=test1000,ou=People,dc=my-domain,dc=com」のエントリに含まれる属性が2つ変更されていることが確認できるはずです。

updateref動作の確認

　次は、スレーブサーバでLDAPクライアントから直接の更新リクエストが許可されないことを確認します。先ほど、マスタサーバからパスワードを変更したユーザーと同一の「test1000」のuserPassword属性をスレーブサーバ上で、ldappasswdコマンドを用いて変更してみましょう。

[root@slave]# ldappasswd -x -D uid=test1000,ou=people,dc=my-domain,dc=com -w 1qazxsw2

  Result: Referral (10)

  Referral: ldap://192.168.1.10:389

　LDAPクライアントへ、エラー番号10のメッセージとともに、slapd.confの「updateref」ディレクティブに指定した更新可能なマスタサーバのURLが返されることが確認できたでしょうか。更新可能なLDAPサーバのURLが返されたクライアントがそのまま処理を継続するか、またはこの時点で処理を停止するかは、LDAPクライアントの実装次第です。

クライアントの設定

前のページへ 1|2|3 次のページへ