Internet Week 2005のチュートリアル、 T24「LDAP入門- OpenLDAPで構築するエンタープライズレベルの認証システム」(講師：我妻 佳子氏)の中で、 質問に未回答であった次の内容について、 回答を掲載いたしました。
当初は講演内容と資料が異なるため後日掲載ということでしたが、 講演中に質問の出ました上記3項目についての補足資料を樽石将人氏(Debian Project)のご協力で作成していただきました。 どうぞご参照ください。
| Q&A | ||
 |
Q. スレーブサーバが停止している間にslapdが更新を受け取った場合、更新情報はどうなりますか? | |
|
slurpdデーモンは更新情報をログファイルで管理しています。 そのため、スレーブサーバが停止していても更新情報は保持されており、 スレーブサーバが復活した時点で自動的に最新の状態に追従されます。 | |
|
Q. ldapaddとldapmodifyはどのように違いますか? | |
|
ldapaddとldapmodifyは入力として受け取るファイルの書式が異なるだけで内部的には同じ動作を行います
(実際、OpenLDAPのコマンドラインプログラムではこれらふたつのプログラムの実態は同じで、
ファイル名が異なるだけになっています)。
ふたつのプログラムが存在する理由は、
LDIFにはエントリをダンプする書式と、
変更レコード(changerecord)
を記述する書式のふたつが存在するからです
(RFC2849)。
エントリをダンプしたLDIFファイルを入力として渡す場合はldapaddを、
変更レコードを記述したLDIFファイルを入力として渡す場合はldapmodifyを利用します。
エントリダンプは記述が簡単ですが、
エントリの追加以外はできません。
一方、変更レコードを渡す場合は、追加も含め、
多彩な処理を記述できますが、書式が複雑になります。
以下は cn=Barbara J Jensen,dc=example,dc=com と cn=Bjorn J Jensen,dc=example,dc=com という２つのエントリをダンプしたLDIFの例です。 |
||
|
||
| 以下は変更レコードを記述したLDIFの例です。 cn=Modify Me,dc=example,dc=comというエントリに対し、 mail属性をmodme@example.comに変更し、 title: Grand Poobahという属性を追加し、 file:///tmp/modme.jpegの内容からなるjpegPhoto属性を作成し、 description という属性を削除しています。 | ||
|
||
| なお、ldapmodifyに-aオプションを指定するとldapaddと同じ動作をします (逆に言うとldapaddはldapmodify -aの別名です)。 | ||
| Q. 分散ディレクトリの動きについて説明して欲しい。 | ||
| LDAPの分散ディレクトリは、 「紹介(Referral)」機構により実現されています。 Referralとは、 クライアントの要求を受け取ったサーバが「その要求は他のサーバで行ってほしい」と別のサーバを紹介する仕組みです。 Referralを受け取ったクライアントは、 紹介された別のサーバへ接続しなおし、同じ処理を再度実施します。 例えばいまサーバ1とサーバ2という二つのサーバが存在し、 クライアントがサーバ1に対して検索操作を行ったとします。 サーバ1は「サーバ2を参照して欲しい」というReferral情報をクライアントに返します。 Referral結果を受け取ったクライアントはサーバ2に対して再接続し、 サーバ1に行ったのと同じ検索操作をサーバ2に対して行います。 | ||
 |
||
|
Referralは分散ディレクトリに利用する以外にも負荷分散や更新専用サーバを紹介する場合にも利用できます。
ただし、注意する点としてサーバはReferralを返した後のクライアントの動きには一切感知しないという点があります。
したがって、分散ディレクトリを実現するにはReferralを返した後に別のサーバへ処理を行なう機構をクライアントが実現しなければいけません。
これはクライアント作成者がこの機能を実装しなければならないことを意味します。
ただし、サーバの動きが単純になるためシステム障害に強くなるという利点があります。
OpenLDAPのクライアントコマンドでは、 -CオプションをつけることでReferral機能の処理をハンドリングします。 -Cをつけない場合は、紹介情報だけが結果として得られます。 分散ディレクトリを実現するには、 「上位知識情報(Superior Knowledge Information)」と「下位知識情報(Subordinate Knowledge Information)」というふたつのReferral情報を利用します。 上位知識情報は、 そのサーバの感知しない識別名(DN)が得られた場合に利用する紹介情報で、 下位知識情報は階層関係が下位のエントリで実態は別のサーバが管理しているエントリの紹介情報です。 |
||
 |
||
|
（↑図をクリックすると拡大してご覧いただくことができます。）
親サーバは、 図のように「下位知識情報」を自分自身のディレクトリツリーのエントリとして保持します。 これにより、 分散ディレクトリの階層情報をLDAPプロトコルを用いて管理することができます。 「下位知識情報」は通常のエントリのように見えますが、 referralという特別なobjectClassをを用い、 ref属性に分散先子サーバのURIを記述します。 この場合ですと、 親サーバのou=東京,dc=example,dc=comというエントリには |
||
ref: ldap://LDAPサーバ東京/ou=東京,dc=example,dc=com
|
||
|
という属性が付加されています。
一方、子サーバは、
ou=東京,dc=example,dc=comを実際に保持しているため、
親サーバの紹介によって再接続してきたクライアントは、
ここで実際のエントリ情報を取得することができるわけです。
子サーバの「上位知識情報」はOpenLDAPの場合、 ディレクトリのエントリではなく、 slapd.confのreferralというディレクティブに記述します。 「上位知識情報」は自分の管理するエントリでない要求がきた場合に、 別のサーバを紹介するサーバ情報です。 例えば、クライアントがLDAPサーバ東京からou=大阪,dc=example,dc=comの情報を取得しようとすると、 LDAPサーバ東京はこの情報を提供できないため、 上位知識情報に基づいて親サーバを紹介します。 次に、クライアントは親サーバに対して、 ou=大阪,dc=example,dc=com 情報の取得を要求しますが、 これは親サーバの「下位知識情報」に基づいて、 LDAPサーバ大阪が紹介されます。 したがってクライアントは最終的にLDAPサーバ大阪に接続し、 必要な情報を取得することになります。 分散ディレクトリの動きはIPのルーティング機構と非常によく似ており、 上位知識情報はIPのデフォルトゲートウェイ情報、 下位知識情報は実際のルーティングテーブルに対応付けて考えるとイメージしやすいでしょう。 |
||
