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

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

スレーブサーバの設定

　次は、スレーブサーバの設定です。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="[e-mail]" authzid="[e-mail]" 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クライアントの実装次第です。