Internet Week 2005
Internet Week 2005
space
space
space Internet Week 2005「T24:LDAP入門」補足資料



Internet Week 2005のチュートリアル、T24「LDAP入門- OpenLDAPで構築するエンタープライズレベルの認証システム」(講師:我妻 佳子氏)の中で、質問に未回答であった次の内容について、回答を掲載いたしました。
スレーブサーバが停止している間に slapd が更新を受け取った場合、更新情報はどうなりますか?
ldapadd と ldapmodify はどのように違いますか?
分散ディレクトリの動きについて説明して欲しい。
当初は講演内容と資料が異なるため後日掲載ということでしたが、講演中に質問の出ました上記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 という2つのエントリをダンプした LDIF の例です。
   

dn: cn=Barbara J Jensen,dc=example,dc=com
cn: Barbara J Jensen
cn: Babs Jensen
objectclass: person
description:< file:///tmp/babs
sn: Jensen
 
dn: cn=Bjorn J Jensen,dc=example,dc=com
cn: Bjorn J Jensen
cn: Bjorn Jensen
objectclass: person
sn: Jensen
 

    以下は変更レコードを記述した LDIF の例です。cn=Modify Me,dc=example,dc=com というエントリに対し、mail 属性を modme@example.com に変更し、title: Grand Poobah という属性を追加し、file:///tmp/modme.jpeg の内容からなる jpegPhoto 属性を作成し、description という属性を削除しています。
   

dn: cn=Modify Me,dc=example,dc=com
changetype: modify
replace: mail
mail: modme@example.com
-
add: title
title: Grand Poobah
-
add: jpegPhoto
jpegPhoto:< file:///tmp/modme.jpeg
-
delete: 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 のデフォルトゲートウェイ情報、下位知識情報は実際のルーティングテーブルに対応付けて考えるとイメージしやすいでしょう。
     
Copyright 2005 Internet Week 2005. All Rights Reserved.