|
| Sun ONE Directory Server 5.2 配備ガイド |
第 2 章で実施したサイト調査により、ディレクトリに格納しようと計画しているデータについての情報を収集できました。次に、このデータの表現方法を決める必要があります。ディレクトリスキーマは、ディレクトリに格納できるデータのタイプを表します。スキーマの設計時には、各データ要素を LDAP 属性に割り当て、関連する要素を集めて LDAP オブジェクトクラスに入れます。スキーマを適切に設計することで、ディレクトリに格納するデータ連鎖サフィックスの整合性を維持できます。
この章では、適切なスキーマを設計する方法について説明します。この章には次の節があります。
Directory Server のオブジェクトクラスと属性、およびスキーマファイルとディレクトリ設定属性については、『Sun ONE Directory Server Reference Manual』を参照してください。サーバー間でのスキーマのレプリケーション方法については、「スキーマのレプリケーション」を参照してください。
Sun ONE Directory Server のスキーマ
ディレクトリスキーマは、データ値のサイズ、範囲、および形式に制限を課すことにより、ディレクトリに格納されるデータの整合性を維持します。設計者は、ディレクトリに含まれるエントリの種類 (ユーザー、デバイス、組織など) と各エントリで使用できる属性を決めます。
Directory Server に事前に定義されているスキーマには、標準の RFC LDAP スキーマ、サーバーの機能をサポートするための追加アプリケーション固有のスキーマ、および Directory Server に固有のスキーマ拡張が含まれます。定義済みのスキーマは大半のディレクトリの要件を満たしますが、ユーザー独自の要件にも対応できるように、このスキーマを拡張して新しいオブジェクトクラスと属性を追加する必要がある場合もあります。スキーマの拡張方法については、「スキーマのカスタマイズ」を参照してください。
Directory Server は、LDAP プロトコルバージョン 3 (LDAPv3) のスキーマ形式に準拠しています。このプロトコルでは、ディレクトリサーバーが LDAP 自体を通じてスキーマを公開することによって、ディレクトリクライアントアプリケーションがプログラムを使用してスキーマを検索し、検索したスキーマに基づいて自分の動作を調整できるようにする必要があります。Directory Server のグローバルスキーマセットは、cn=schema というエントリに含まれています。
Directory Server のスキーマは、RFC 2256 のコア LDAPv3 スキーマだけでなく、多数の一般的なスキーマもサポートしています。また、Directory Server はスキーマエントリ内で X-ORIGIN という非公開フィールドを使用します。このフィールドは、スキーマエントリの定義元を示します。たとえば、スキーマエントリが標準 LDAPv3 スキーマで定義されている場合、X-ORIGIN フィールドの値は RFC 2252 になります。スキーマエントリが、Directory Server 用に Sun ONE で定義されている場合は、X-ORIGIN フィールドに Sun ONE Directory Server という値が入ります。
たとえば、標準の person オブジェクトクラスはスキーマ内で次のように示されます。
objectclasses: ( 2.5.6.6 NAME 'person' DESC 'Standard Person
Object Class' SUP top MUST (objectlass $ sn $ cn) MAY (description $ seealso $ telephoneNumber $ userPassword) X-ORIGIN 'RFC 2252' )このスキーマエントリは、クラスのオブジェクト識別子 (OID) (2.5.6.6)、オブジェクトクラス名 (person)、クラスの説明 (Standard Person Object Class)、必須の属性 (objectclass、sn、および cn)、および許可された属性 (description、seealso、telephoneNumber、および userPassword) を示しています。
Sun ONE Directory Server のすべてのスキーマと同様に、オブジェクトクラスは直接 Directory Server で定義され、格納されています。これは、ディレクトリのスキーマを標準の LDAP 操作で問い合わせたり、変更したりできるということです。
スキーマ設計の概要
スキーマの設計時には、Directory Server によって格納されるエントリを表すのに使用するオブジェクトクラスと属性を選択および定義します。スキーマの設計は、次の手順で行います。
- できるかぎり多くの要件を満たす、定義済みのスキーマを選択する
- Directory Server の標準スキーマを拡張して、残りの要件を満たす新しい要素を定義する
- スキーマの保守を計画する
最善の方法は、Directory Server が提供する標準スキーマに定義されている既存のスキーマ要素を使用することです。標準スキーマの要素を選択すれば、ディレクトリを使用するアプリケーションとの互換性を保証できます。また、スキーマは LDAP 標準に基づいているので、多くのディレクトリユーザーによってレビューされ、承認されています。
デフォルトスキーマへのデータの割り当て
「サイト調査の実施」で説明したように、サイト調査で識別したデータを既存のデフォルトディレクトリスキーマに割り当てる必要があります。この節では、既存のデフォルトスキーマを表示する方法と、適切な既存のスキーマ要素にデータを割り当てる方法について説明します。
既存のデフォルトスキーマとマッチしない要素が独自のスキーマ内にある場合は、カスタマイズしたオブジェクトクラスと属性を作成する必要があります。詳細は、「スキーマのカスタマイズ」を参照してください。
デフォルトのディレクトリスキーマの表示
Sun ONE Directory Server 5.2 で提供されるスキーマは、次のディレクトリに保存される一連のファイルに記述されています。
ServerRoot/slapd-serverID/config/schema
このディレクトリには、Sun ONE 製品のすべての共通スキーマが入っています。LDAPv3 標準のユーザースキーマと組織スキーマは、 00core.ldif ファイルに記述されています。旧バージョンのディレクトリで使用された設定スキーマは、50ns-directory.ldif ファイルに記述されています。
注 サーバーの稼動中は、このディレクトリ内のファイルを絶対に変更しないでください。
また、手動で加えた変更は、LDAP または Directory Server コンソールを使用して別の変更を加えるまでレプリケートされないことにも注意する必要があります。
データとスキーマ要素の対応付け
サイト調査で識別したデータを既存のディレクトリスキーマに割り当てる必要があります。この作業は、次の手順で行います。
- データを表すオブジェクトのタイプを識別する
サイト調査に記載されているデータにもっとも適したオブジェクトを選択します。データで複数のオブジェクトを記述できる場合があります。必要に応じて別の要素をディレクトリスキーマに入れるかどうかを決める必要があります。たとえば、電話番号に社員の電話番号と会議室の電話番号を記述できます。これらの電話番号データを、ディレクトリスキーマで異なるオブジェクトとみなすかどうかは設計者が決めます。
- デフォルトスキーマから類似のオブジェクトクラスを選択する
最善の方法は、groups、people、organizations などの共通オブジェクトクラスを使用することです。
- 対応するオブジェクトクラスから類似の属性を選択する
対応するオブジェクトクラスから、サイト調査で識別したデータにもっとも適した属性を選択します。
- サイト調査で収集したデータの中で対応しないデータを識別する
デフォルトのディレクトリスキーマで定義されているオブジェクトクラスと属性に対応しないデータがある場合は、スキーマをカスタマイズする必要があります。詳細は、「スキーマのカスタマイズ」を参照してください。
次の表に、ディレクトリスキーマの要素を第 2 章のサイト調査で識別したデータに割り当てた例を示します。
表では、個人を社員名で表しています。デフォルトのディレクトリスキーマには、top オブジェクトクラスから継承する person オブジェクトクラスがあります。このオブジェクトクラスには複数の属性が許可されており、その中に個人の氏名を記述する cn (commonName ) という属性があります。この属性は、社員名データを入れる目的にもっとも適しています。
ユーザーパスワードも person オブジェクトに関連付けることができます。person オブジェクトの許可された属性に userPassword が含まれています。
自宅の電話番号は、特定の個人のある側面を表すものです。しかし、person オブジェクトクラスに関連するリストには、該当する属性がありません。自宅の電話番号をより本質的に分析してみますと、これは、組織的な企業ネットワークにおいて、特定の個人を表すものだといえます。このためこのオブジェクトは、ディレクトリスキーマの inetOrgPerson オブジェクトクラスに対応します。inetOrgPerson オブジェクトクラスは organizationalPerson オブジェクトクラスから継承し、organizationalPerson オブジェクトクラスは person オブジェクトクラスから継承します。inetOrgPerson オブジェクトの許可された属性の中に、社員の自宅の電話番号を入れるのに適した homePhone 属性があります。
スキーマのカスタマイズ
標準スキーマの制限が多すぎて、ディレクトリの要件に対応できない場合は、標準スキーマを拡張できます。Directory Server コンソールは、スキーマ定義の管理に役立ちます。詳細については、『Sun ONE Directory Server 管理ガイド』の第 9 章「Extending the Directory Schema」を参照してください。
スキーマをカスタマイズするときは、次の規則に留意してください。
- できるかぎり既存のスキーマ要素を再利用する。既存のすべてのスキーマ要素のリストは、『Sun ONE Directory Server Reference Manual』の「Directory Server Schema」に記載されています。
- 各オブジェクトクラスに定義する必須の属性の数を最小限にする
- 同じ目的で複数のオブジェクトクラスまたは属性を定義しない
- できるかぎりスキーマを簡潔にする
注 スキーマをカスタマイズする場合は、標準スキーマの属性またはオブジェクトクラスの既存の定義の変更、削除、および置換は行わないでください。標準スキーマを修正すると、ほかのディレクトリや LDAP クライアントアプリケーションとの互換性に問題が生じます。
カスタムのオブジェクトクラスと属性は、次のファイル内に定義されます。
ServerRoot/slapd-serverID/config/schema/99user.ldif
次の項目ごとに、ディレクトリスキーマのカスタマイズについて詳しく説明します。
- スキーマの拡張が必要な場合
- オブジェクト識別子の取得と割り当て
- 属性とオブジェクトクラスの命名
- 新しいオブジェクトクラスの定義戦略
- 新しい属性の定義方法
- スキーマ要素の削除
- カスタムスキーマファイルの作成 - 最良の事例と落とし穴
スキーマの拡張が必要な場合
Directory Server が提供するオブジェクトクラスと属性は、ユーザーのほとんどの要件を満たしますが、既存のオブジェクトクラスによっては組織の特殊な情報を格納できない場合もあります。また、LDAP 対応アプリケーションの独自のデータ要件に適したオブジェクトクラスや属性をサポートできるように、スキーマを拡張しなければならない場合もあります。
オブジェクト識別子の取得と割り当て
各 LDAP オブジェクトクラスまたは属性には、一意の名前とオブジェクト識別子 (OID) が割り当てられている必要があります。スキーマを定義するときは、組織に固有の OID が必要です。1 つの OID ですべてのスキーマ要件に対応できます。別の階層レベルを追加するだけで、属性とオブジェクトクラスに新しい分岐を作成できます。OID の取得とスキーマでの割り当ては、次の手順で行います。
- IANA (Internet Assigned Numbers Authority) または国内の機関から組織の OID を取得する
国によっては、企業にすでに OID が割り当てられてます。所属する組織がまだ OID を持っていない場合は、IANA から取得できます。詳細は、IANA の Web サイト http://www.iana.org/cgi-bin/enterprise.pl を参照してください。
- OID の割り当てを追跡できるように、OID レジストリを作成する
OID レジストリは、ディレクトリスキーマで使用する OID と OID の説明を提供するリストで、作成者が保持します。このレジストリにより、OID が複数の目的に使用されないようにすることができます。次に、スキーマで OID レジストリを公開する必要があります。
- スキーマ要素を入れるために、OID ツリーに分岐を作成する
OID 分岐またはディレクトリスキーマの下に少なくとも 2 つの分岐 (1 つは属性用の OID.1、もう 1 つはオブジェクトクラス用の OID.2) を作成します。独自のマッチングルールや制御を定義する場合は、必要に応じて OID.3 などの新しい分岐を追加できます。
属性とオブジェクトクラスの命名
新しい属性やオブジェクトクラスに名前を付けるときは、できるかぎりわかりやすいものにします。わかりやすい名前にすると、Directory Server の管理者がスキーマを使いやすくなります。
作成するすべての要素に固有の接頭辞を付けて、作成したスキーマ要素と既存のスキーマ要素間での名前の衝突を防ぎます。たとえば、Example.com 社では、各カスタムスキーマ要素の前に Example という接頭辞を追加しています。また、ディレクトリ内の Example.com 社員を識別するために ExamplePerson という特別なオブジェクトクラスを追加しています。
新しいオブジェクトクラスの定義戦略
新しいオブジェクトクラスを作成するには、次の 2 つの方法があります。
- 属性を追加するオブジェクトクラス構造ごとに 1 つずつ、多数の新しいオブジェクトクラスを作成する
- ディレクトリ用に作成するすべての属性を含む 1 つのオブジェクトクラスを作成する。このオブジェクトクラスは AUXILIARY オブジェクトクラスとして定義して作成する
2 つの方法を併用するのがもっとも簡単です。
たとえば、サイトに ExampleDepartmentNumber と ExampleEmergencyPhoneNumber という属性を作成するとします。これらの属性にいくつかのサブセットを許可する複数のオブジェクトクラスを作成できます。ExamplePerson というオブジェクトクラスを作成し、そのオブジェクトクラスが ExampleDepartmentNumber と ExampleEmergencyPhoneNumber を許可するようにします。ExamplePerson の親は inetOrgPerson であるとします。ExampleOrganization というオブジェクトクラスを作成し、そのオブジェクトクラスが ExampleDepartmentNumber と ExampleEmergencyPhoneNumber を許可するようにします。ExampleOrganization の親は organization オブジェクトクラスであるとします。
新しいオブジェクトクラスは、LDAPv3 スキーマ形式では次のようになります。
objectclasses: ( 1.3.6.1.4.1.42.2.27.999.1.2.3 NAME 'ExamplePerson' DESC 'Example Person Object Class' SUP inetorgPerson STRUCTURAL MAY (ExampleDepartmentNumber $ ExampleEmergencyPhoneNumber) )
objectclasses: ( 1.3.6.1.4.1.42.2.27.999.1.2.4 NAME 'ExampleOrganization' DESC 'Example Organization Object Class' SUP organization STRUCTURAL MAY (ExampleDepartmentNumber $ ExampleEmergencyPhoneNumber) )
このようにする代わりに、これらの属性のすべてを許可する 1 つのオブジェクトクラスを作成して、これらの属性を使用する任意のエントリでこのオブジェクトクラスを使用できるようにします。1 つのオブジェクトクラスは、次のようになります。
objectclasses: (1.3.6.1.4.1.42.2.27.999.1.2.5 NAME 'ExampleEntry' DESC 'Example Auxiliary Object Class' SUP top AUXILIARY MAY
(ExampleDepartmentNumber $ ExampleEmergencyPhoneNumber) )新しい ExampleEntry オブジェクトクラスには、構造上のオブジェクトクラスに関係なく任意のエントリで使用できることを示す AUXILIARY が付いています。
注 この例の新しいオブジェクトクラスの OID は、Sun ONE OID 接頭辞に基づいており、配備した製品内では使用できません。独自の新しいオブジェクトクラスを作成するには、独自の OID を取得する必要があります。詳細については、「オブジェクト識別子の取得と割り当て」を参照してください。
目的に合った、新しいオブジェクトクラスを定義する方法を選択してください。新しいオブジェクトクラスを実装する方法を決めるときは、次の点に留意します。
- 複数の STRUCTURAL オブジェクトクラスを作成すると、作成および管理するスキーマ要素の数も増える
一般に、要素の数が少なければ、管理の手間も少なくて済みます。しかし、スキーマに 2 〜 3 つのオブジェクトクラスを追加する場合は、1 つのオブジェクトを使用する方が簡単です。
- 複数の STRUCTURAL オブジェクトクラスを作成する場合は、より厳密かつ注意深いデータ設計が必要となる
データを厳密に設計するには、個々のデータを配置するオブジェクトクラス構造を考慮する必要があります。この手間を有用と思う人もいれば、面倒だと思う人もいます。
- 複数のタイプのオブジェクトクラス構造に入れたいデータがある場合は、1 つの AUXILIARY オブジェクトクラスを使用した方がデータ設計が簡単になる
たとえば、preferredOS 属性を人のエントリとグループエントリの両方に設定するとします。このような場合は、1 つのオブジェクトクラスを作成して、そのクラスでこの属性が許可されるようにします。
- 意味のあるグループを構成する実際のオブジェクトとグループ要素に関連するオブジェクトクラスを設計する
- 新しいオブジェクトクラスに必須の属性を設定しない
必須の属性を設定するとスキーマに柔軟性がなくなります。新しいオブジェクトクラスを作成する場合は、必須の属性より許可の属性にするようにします。
新しいオブジェクトクラスを定義したら、そのオブジェクトクラスの許可された属性と必須の属性、および継承するオブジェクトクラスを決める必要があります。
新しい属性の定義方法
ディレクトリのエントリに格納する必要がある情報の中に既存のオブジェクトクラスがサポートしていないものがある場合は、新しい属性とオブジェクトクラスを追加します。
できるかぎり、標準属性を使用するようにします。デフォルトのディレクトリスキーマにある属性を探し、それらを新しいオブジェクトクラスに関連付けて使用します。対応する属性がデフォルトのディレクトリスキーマにない場合は、新しい属性を作成します。
たとえば、person、organizationalPerson、または inetOrgPerson の各オブジェクトクラスがサポートしている以外の情報を、個人のエントリに格納したい場合があります。ディレクトリに生年月日を格納する場合、Sun ONE Directory Server の標準スキーマには対応する属性がありません。したがって、dateOfBirth という新しい属性を作成し、この属性を許可する新しい補助クラスを定義して、個人を表すエントリでこの属性を使用できるようにします。
スキーマ要素の削除
Directory Server に含まれているスキーマ要素は削除しないでください。未使用のスキーマ要素は、Directory Server の動作や管理において、オーバーヘッドになることはありません。ただし、標準 LDAP スキーマの一部を削除すると、将来提供される新しいバージョンの Directory Server や LDAP 対応アプリケーションとの互換性に問題が生じる可能性があります。
拡張したスキーマの新しい要素を使用しないときは、その不要要素を削除してもかまいません。スキーマ要素を削除する前に、ディレクトリ内のどのエントリもそれを使用しないことを確認してください。削除しようとしているスキーマ要素を使用するエントリがないことを確認する最も簡単な方法は、そのスキーマ要素を含むすべての要素を返す ldapsearch を実行することです。たとえば、myObjectClass というオブジェクトクラスを削除する前に、次の ldapsearch コマンドを実行します。
ldapsearch -h host -p port -s base "objectclass=myObjectClass"
これに該当するエントリが見つかった場合は、それを削除するか、スキーマから消去される部分を削除することができます。あるスキーマ定義を使用するエントリを削除する前にそのスキーマ定義を削除すると、その定義を使用するエントリを後から変更できなくなることがあります。不明な値をエントリから削除しない限り、変更されたエントリに関するスキーマ検査も失敗します。
カスタムスキーマファイルの作成 - 最良の事例と落とし穴
Directory Server に含まれている 99user.ldif ファイルのほかに、独自のカスタムスキーマファイルを作成できます。ただし、カスタムスキーマファイルを作成するとき、特にレプリケーションが関連する場合は、次に示すいくつかの点に注意する必要があります。
- 新たに追加したスキーマ要素をオブジェクトクラスで使用するためには、事前にすべての属性が定義されている必要があります。属性とオブジェクトクラスは同じスキーマファイル内で定義できます。
- 作成する各カスタム属性またはオブジェクトクラスは、1 つのスキーマファイル内でだけ定義されている必要があります。これにより、サーバーが最新のスキーマを読み込むときに、前の定義を上書きするのを防ぐことができます (サーバーが最初に数字順、次にアルファベット順にスキーマを読み込むため)。
- 新しいスキーマ定義を手動で作成するときは、その定義を 99user.ldif ファイルに追加する方法が最も適しています。
LDAP を使用するスキーマ要素を更新すると、新しい要素が自動的に 99user.ldif ファイルに書き込まれます。このため、カスタムスキーマファイルに加えたそれ以外のスキーマ定義の変更が上書きされる可能性があり、すべてのスキーマ定義を 99user.ldif ファイルに追加する方法が推奨されます。この場合、スキーマ要素が重複する可能性と、スキーマの変更が後から上書きされる危険を回避できます。
- Directory Server がスキーマファイルを英数字順にロードする場合、つまり、数字が小さいものから先にロードする場合、カスタムスキーマファイルの名前を次のように指定する必要があります。
[00-99]yourname.ldif
この数字は、すでに定義されているどのディレクトリ標準スキーマよりも大きな値にする必要があります。
標準スキーマファイルより小さな値をスキーマファイル名に付けた場合、スキーマのロード時にサーバーでエラーが発生し、さらに、カスタムスキーマ要素のロードが完了するまで、すべての標準属性とオブジェクトクラスがロードされなくなります。
- 作成するカスタムスキーマのファイル名は、数値やアルファベットの順序で "99user.ldif" を超えないよう、注意してください。なぜなら Directory Server は、内部スキーマの管理のために、(数値順、次にアルファベット順で) もっとも大きい名前を持つファイルを使用するからです。
作成したスキーマファイルに 99zzz.ldif という名前を付けると、次に LDAP または Directory Server コンソールを使用してスキーマを更新したときに、'user defined' (通常は 99user.ldif ファイルに格納されています) の値として X-ORIGIN を持つすべての属性が 99zzz.ldif に書き込まれます。その結果、重複した情報を持つ 2 つの LDIF ファイルが存在し、99zzz.ldif ファイル内のいくつかの情報が削除される可能性があります。
- 原則として、追加するカスタムスキーマ要素の識別には、次の 2 つの項目を使用します。
- カスタムスキーマファイルの X-ORIGIN フィールドに指定されている 'user defined'
- および、X-ORIGIN フィールドの 'Example.com Corporation defined' のように、カスタムスキーマ要素の内容を後から判断する上で役立つより説明的な情報。たとえば、X-ORIGIN ('user defined' 'Example.com Corporation defined') など
スキーマ要素を手動で追加し、X-ORIGIN フィールドの 'user defined' を使用しない場合、これらの要素は Directory Server コンソールの読み取り専用セクションに表示されるため、コンソールを使用して編集することができません。
新しいスキーマの由来と関連するその他のスキーマを特定し、理解する上で役立つので、'user defined' を補完する説明的な識別子を使用することをお勧めします。サーバーによって自動的に追加される 'user defined' という値以外に説明を加えない場合、後から LDAP または Directory Server コンソールを使用してカスタムスキーマ定義を追加しなければならなくなったときに、そのスキーマが何に関連しているかを確認することが困難になります。
- 変更は自動的にレプリケートされないので、作成したカスタムスキーマファイルをすべてのサーバーに伝達するか、すべてのサーバーで手動で変更を加えることが重要です。
ディレクトリスキーマを変更すると、サーバーはスキーマがいつ変更されたのかを示すタイムスタンプを記録します。各レプリケーションセッションの最初に、サーバーはコンシューマのタイムスタンプとこのタイムスタンプを比較し、必要であればスキーマの変更をプッシュします。カスタムスキーマファイルについては、サーバーは 99user.ldif ファイルに関連付けられている 1 つのタイムスタンプだけを維持します。つまり、カスタムスキーマファイルに加えた変更、または 99user.ldif ファイル以外のファイルに対する追加は、トポロジ内のその他のサーバーにはレプリケートされません。このため、トポロジ全体にすべてのスキーマ情報が行き渡るように、作成したカスタムスキーマファイルをすべてのサーバーに伝達するか、すべてのサーバーで変更を行う必要があります。
カスタムスキーマファイルに加えた変更は、次のいずれかの方法で伝達できます。
- schema_push.pl スクリプトを実行して変更をレプリケートする (各サーバーの再起動が必要)
- 作成したカスタムスキーマファイルをすべてのサーバーに手動でコピーする
新しいカスタムスキーマ定義をレプリケーションプロセスによってすべてのサーバーにレプリケートする方法を選択した場合は、1 つのマスターだけでスキーマを維持してください。スキーマ定義が存在しないコンシューマサーバーにスキーマ定義がレプリケートされると、それを定義したカスタムスキーマファイルではなく、99user.ldif ファイルに定義が格納されます。スキーマ要素をコンシューマの 99user.ldif ファイルに格納しても、1 つのマスターサーバーだけでスキーマを管理している限り問題はありません。
各サーバーにスキーマファイルをコピーする方法を選択した場合は、変更のたびにファイルをコピーする必要があります。変更のたびにコピーしない場合、変更がコンシューマ上の 99user.ldif ファイルにレプリケートおよび格納される可能性があります。変更が 99user.ldif ファイル内に格納されると管理がむずかしくなります。これは、一部の属性が、コンシューマ上の 2 つのスキーマファイル (サプライヤからコピーした元のカスタムスキーマファイルとレプリケート後の 99user.ldif ファイル) の両方に現れるためです。
- カスタムスキーマ要素がレプリケーショントポロジ内の別のサーバーにレプリケートされないようにするには、次の処理が必要です。
スキーマのレプリケートについては、「スキーマのレプリケーション」を参照してください。
データの整合性の維持
Directory Server 内のスキーマの整合性を維持すると、LDAP クライアントアプリケーションがディレクトリのエントリを検出しやすくなります。ディレクトリに格納している情報のタイプごとに、その情報をサポートするために必要なオブジェクトタイプと属性を選択し、常に同じものを使用する必要があります。整合性のないスキーマオブジェクトを使用すると、ディレクトリツリー内の情報を効率よく検出できなくなります。
次のようにすると、整合性のあるスキーマを維持できます。
- スキーマ検査を使用して、属性とオブジェクトクラスが必ずスキーマ規則にマッチしていることを確認する
- 整合性のあるデータ形式を選択して適用する
次に、スキーマ内で整合性を維持する方法について詳しく説明します。
スキーマ検査
スキーマ検査は、すべての新しいまたは変更したディレクトリエントリが、スキーマ規則にマッチしているかどうかを検査します。規則にマッチしていない場合、ディレクトリは変更要求を拒否します。
注 スキーマ検査では、適切な属性があるかどうかだけを検査します。属性値が当該属性について正しい構文で記述されているかどうかは検査しません。Directory Server 5.2 には nsslapd-valuecheck という属性があり、これを使用することで属性値の DN 構文だけを検索することができます。ただし、この属性はデフォルトではオフに設定されており、属性値の検査は行われません。
スキーマ検査はデフォルトで有効になっています。クライアントの更新を受け付けるサーバーでは、これをオフにすることはお勧めできません。スキーマ検査をオン、オフする方法については、『Sun ONE Directory Server 管理ガイド』の「Turning Schema Checking On and Off」を参照してください。
スキーマ検査を有効にする場合は、オブジェクトクラスで定義されている必須の属性と許可された属性に注意する必要があります。通常、オブジェクトクラス定義には少なくとも 1 つの必須の属性と 1 つ以上の省略可能な属性が含まれています。省略可能な属性とは、ディレクトリのエントリに追加できるが必須ではない属性のことです。エントリのオブジェクトクラス定義で必須でなく許可されてもいない属性をエントリに追加しようとすると、Directory Server はオブジェクトクラス違反メッセージを返します。
たとえば、エントリで organizationalPerson オブジェクトクラスを使用するように定義した場合は、commonName (cn) と surname (sn) がそのエントリの必須の属性になります。これらの属性にはエントリの作成時に値を指定する必要があります。さらに、オプションとしてエントリで使用できる属性の長いリストがあります。このリストには、telephoneNumber、Uid、streetAddress、userPassword などの説明属性が含まれています。
整合性のあるデータ形式の選択
LDAP スキーマを使用して、必要なデータを任意の属性値に格納できます。ただし、LDAP クライアントアプリケーションとディレクトリユーザーに適切な形式を選択して、ディレクトリツリー内で整合性を維持するようにデータを格納することが重要です。
LDAP プロトコルと Sun ONE Directory Server を使用する場合は、RFC 2252 で規定されているデータ形式でデータを表す必要があります。
また、電話番号の正しい LDAP 形式は、次の ITU-T 勧告ドキュメントで定義されています。
- ITU-T 勧告 E.123
国内および国際電話番号に関する注記
- ITU-T 勧告 E.163
国際電話サービスの番号計画
たとえば、米国の電話番号は次のような形式になります。
+1 555 222 1717
postalAddress 属性には、区切り文字としてドル記号 ($) を使用する複数行文字列形式の属性値が必要です。適切に形式化されたディレクトリエントリは次のようになります。
postalAddress: 1206 Directory Drive$Pleasant View, MN$34200
レプリケートされたスキーマでの整合性の維持
レプリケート環境で整合性のあるスキーマを維持するには、次の点に留意します。
- コンシューマサーバーのスキーマを変更しない
コンシューマサーバーのスキーマを変更すると、マスターサーバーのスキーマよりも新しいスキーマとなります。したがって、マスターがレプリケーションで更新をコンシューマに送信すると、コンシューマのスキーマが新しいデータをサポートできないため、多数のレプリケーションエラーが発生します。
- マルチマスターレプリケーション環境では、1 つのマスターサーバーだけでスキーマを変更する
2 つのマスターサーバーのスキーマを変更すると、最後に更新されたマスターのスキーマがコンシューマに伝達されます。これは、コンシューマのスキーマと他方のマスターのスキーマとの間に整合性がないことを意味します。
スキーマレプリケーションについては、「スキーマのレプリケーション」を参照してください。
その他のスキーマ関連資料
標準 LDAPv3 スキーマについては、次のドキュメントを参照してください。
- Internet Engineering Task Force (IETF) http://www.ietf.org
- 『Understanding and Deploying LDAP Directory Services』
(T. Howes、M. Smith、G. Good 著、Macmillan Technical Publishing 発行、1999 年)
- RFC 2252: LDAPv3 Attribute Syntax Definitions
http://www.ietf.org/rfc/rfc2252.txt
- RFC 2256: Summary of the X.500 User Schema for Use with LDAPv3
http://www.ietf.org/rfc/rfc2256.txt
- RFC 2251:Lightweight Directory Access Protocol (v3)
http://www.ietf.org/rfc/rfc2251.txt