Sun Java System Directory Server Enterprise Edition 6.2 管理ガイド

カスタムスキーマについて

ディレクトリのニーズに対して、標準スキーマでは著しく制限される場合に、標準スキーマを拡張できます。スキーマをカスタマイズする場合は、次のガイドラインに従います。

できるかぎり既存のスキーマ要素を再利用する。
各オブジェクトクラスに定義する必須の属性の数を最小限にする。
同じ目的で複数のオブジェクトクラスまたは属性を定義しない。
できるかぎりスキーマを簡潔にする。

スキーマをカスタマイズする場合は、標準スキーマの属性またはオブジェクトクラスの既存の定義の変更、削除、および置換は行わないでください。標準スキーマを修正すると、ほかのディレクトリや LDAP クライアントアプリケーションとの互換性に問題が生じます。

Directory Server 内部オペレーショナル属性は変更しないでください。ただし、外部アプリケーション用に独自のオペレーショナル変数を作成できます。

objectClass: extensibleObject を使用する代わりに、常にオブジェクトクラスを定義します。Directory Server は、オブジェクトクラス extensibleObject があるエントリのスキーマ検査を実行しないため、エントリに存在する属性を制限したり、検査したりしません。アプリケーションでのタイプミス、たとえば givenName 属性タイプを giveName と間違えた場合も、Directory Server はその間違いに気づきません。また、Directory Server は、extensibleObject エントリの中で未定義の属性は、複数値属性で、大文字小文字に関係ない文字列構文を持つことを前提とします。さらに、特定のオブジェクトクラスを持つエントリに依存するアプリケーションもあります。一般に、オブジェクトクラスへの拡張を必要とするアプリケーションがある場合は、スキーマ管理を放棄しないでください。代わりに、アプリケーションに必要な属性を含む補助のオブジェクトクラスを作成します。

この節では、デフォルトのディレクトリスキーマについてと、カスタマイズした属性とオブジェクトクラスの作成について説明します。

デフォルトの Directory Server スキーマ

Directory Server で提供されるスキーマは、instance-path /config/schema/ ディレクトリに保存されているファイルのセットに記述されています。

このディレクトリには、Directory Server の一般的なすべてのスキーマと関連製品が格納されています。LDAP v3 標準のユーザースキーマと組織スキーマは、00core.ldif ファイルに記述されています。旧バージョンのディレクトリで使用された設定スキーマは、50ns-directory.ldif ファイルに記述されています。

注 –

サーバーの稼動中は、このディレクトリ内のファイルを変更しないでください。

オブジェクト識別子

各 LDAP オブジェクトクラスまたは属性には、一意の名前とオブジェクト識別子 (OID) が割り当てられている必要があります。スキーマを定義するときは、組織に固有の OID が必要です。1 つの OID ですべてのスキーマ要件に対応できます。属性とオブジェクトクラスのその OID に新しいエントリを追加します。

OID の取得とスキーマでの割り当ては、次の手順で行います。

IANA (Internet Assigned Numbers Authority) または国内の機関から組織の OID を取得する。

国によっては、企業にすでに OID が割り当てられています。所属する組織がまだ OID を持っていない場合は、IANA から OID を取得できます。
OID の割り当てを追跡できるように、OID レジストリを作成する。

OID レジストリは、ディレクトリスキーマで使用する OID と OID の説明を提供するリストで、作成者が保持します。OID レジストリにより、OID が複数の目的に使用されないようにすることができます。
スキーマ要素を入れるために、OID ツリーにエントリを作成する。

OID エントリまたはディレクトリスキーマの下に少なくとも 2 つのエントリ (1 つは属性用の OID.1、もう 1 つはオブジェクトクラス用の OID.2) を作成します。独自のマッチングルールや制御を定義する場合は、必要に応じて OID.3 などの新しいエントリを追加できます。

属性とオブジェクトクラスの命名

新しい属性とオブジェクトクラスの名前を作成する場合、スキーマで使いやすいように、わかりやすい名前を作成します。

作成する要素に固有の接頭辞を付けて、作成したスキーマ要素と既存のスキーマ要素間での名前の衝突を防ぎます。たとえば、Example.com 社では、各カスタムスキーマ要素の前に Example という接頭辞を追加します。また、ディレクトリ内の Example.com 社員を識別するために ExamplePerson という特別なオブジェクトクラスを追加します。

LDAP では、属性タイプ名とオブジェクトクラス名は、大文字と小文字が区別されません。アプリケーションでは、それらを大文字と小文字を区別しない文字列として扱う必要があります。

新しいオブジェクトクラスを定義する場合

ディレクトリのエントリに格納する必要がある情報の中に既存のオブジェクトクラスがサポートしていないものがある場合は、新しいオブジェクトクラスを追加します。

新しいオブジェクトクラスを作成するには、次の 2 つの方法があります。

属性を追加するオブジェクトクラス構造ごとに 1 つずつ、多数の新しいオブジェクトクラスを作成する。
ディレクトリ用に作成するすべての属性を含む 1 つのオブジェクトクラスを作成する。このオブジェクトクラスは AUXILIARY オブジェクトクラスとして定義して作成する。

サイトに ExampleDepartmentNumber と ExampleEmergencyPhoneNumber という属性を作成するとします。これらの属性にいくつかのサブセットを許可する複数のオブジェクトクラスを作成できます。ExamplePerson というオブジェクトクラスを作成し、そのオブジェクトクラスが ExampleDepartmentNumber と ExampleEmergencyPhoneNumber を許可するようにします。ExamplePerson の親は inetOrgPerson であるとします。ExampleOrganization というオブジェクトクラスを作成し、そのオブジェクトクラスが ExampleDepartmentNumber と ExampleEmergencyPhoneNumber 属性を許可するようにします。ExampleOrganization の親は organization オブジェクトクラスであるとします。

新しいオブジェクトクラスは、LDAP v3 スキーマ形式では次のようになります。
```
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 が付いています。

新しいオブジェクトクラスを実装する方法を決めるときは、次の点に留意します。

複数の STRUCTURAL オブジェクトクラスを作成すると、作成および管理するスキーマ要素の数も増える。

一般に、要素の数が少なければ、管理の手間も少なくて済みます。スキーマに複数のオブジェクトクラスを追加することを計画している場合は、1 つのオブジェクトクラスにまとめた方が簡単な場合があります。
複数の STRUCTURAL オブジェクトクラスを作成する場合は、より厳密かつ注意深いデータ設計が必要となる。

データを厳密に設計するには、個々のデータを配置するオブジェクトクラス構造を考慮する必要があります。この制限は役立つ場合とわずらわしい場合があります。
複数のタイプのオブジェクトクラス構造に入れたいデータがある場合は、1 つの AUXILIARY オブジェクトクラスを使用した方がデータ設計が簡単になる。

たとえば、preferredOS 属性を人のエントリとグループエントリの両方に設定するとします。このような場合は、1 つのオブジェクトクラスを作成して、そのクラスでこの属性が許可されるようにします。
目的に合ったグループを構成する実際のオブジェクトとグループ要素に関連するオブジェクトクラスを設計する。
新しいオブジェクトクラスに必須の属性を設定しない。

必須の属性を設定するとスキーマに柔軟性がなくなります。新しいオブジェクトクラスを作成する場合は、必須の属性より許可の属性にするようにします。

新しいオブジェクトクラスを定義したら、そのオブジェクトクラスの許可された属性と必須の属性、および継承するオブジェクトクラスを決める必要があります。

新しい属性を定義する場合

ディレクトリのエントリに格納する必要がある情報の中に既存の属性がサポートしていないものがある場合は、新しい属性を追加します。できるかぎり、標準属性を使用するようにします。デフォルトのディレクトリスキーマにある属性を探し、それらを新しいオブジェクトクラスに関連付けて使用します。

たとえば、person、organizationalPerson、または inetOrgPerson の各オブジェクトクラスがサポートしている以外の情報を、個人のエントリに格納したい場合があります。ディレクトリに生年月日を格納する場合、Directory Server の標準スキーマには対応する属性がありません。 dateOfBirth という新しい属性を作成できます。この属性を許可する新しい補助クラスを定義して、この属性をエントリで使用できるようにします。

カスタムスキーマファイルを作成する場合

カスタムスキーマファイルを作成するとき、特にレプリケーションを使用する場合は、次の点に注意する必要があります。

新たに追加したスキーマ要素をオブジェクトクラスで使用するためには、事前にすべての属性が定義されている必要があります。属性とオブジェクトクラスは同じスキーマファイル内で定義できます。
作成する各カスタム属性またはオブジェクトクラスは、1 つのスキーマファイル内でだけ定義されている必要があります。この方法により、サーバーが最近作成されたスキーマをロードするときに、以前の定義の上書きを防ぎます。Directory Server は、最初に数字順、次にアルファベット順でスキーマファイルをロードします。
新しいスキーマ定義を手動で作成するときは、一般にその定義を 99user.ldif ファイルに追加する方法が最も適しています。

LDAP を使用してスキーマ要素を更新すると、新しい要素が自動的に 99user.ldif ファイルに書き込まれます。このとき、もしほかのカスタムスキーマファイルも使用していると、そのファイルに対して行なったスキーマ定義の変更が、上書きされる可能性があります。99user.ldif ファイルのみを使用すると、スキーマ要素の重複と、スキーマの変更の上書きを防ぐことができます。
Directory Server はスキーマファイルを英数字順に読み込む、つまり、数字が小さいものから先に読み込むため、カスタムスキーマファイルの名前を次のように指定する必要があります。
```
[00-99] filename.ldif
```
この数字は、すでに定義されているどのディレクトリ標準スキーマよりも大きな値にする必要があります。

スキーマファイルの名前を標準のスキーマファイルより小さい数字で指定すると、そのスキーマを読み込むときにサーバーにエラーが発生することがあります。また、標準の属性およびオブジェクトクラスはすべて、カスタムスキーマ要素が読み込まれたあとに読み込まれることになってしまいます。
Directory Server は内部スキーマ管理用に順番が最後のファイルを使用するため、カスタムスキーマファイル名を数字順またはアルファベット順で、99user.ldif より大きくならないようにしてください。

たとえば、スキーマファイルを作成し、99zzz.ldif という名前を付けた場合、次にスキーマを更新すると、X-ORIGIN の値が 'user defined' であるすべての属性が 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' を使用しない場合、このスキーマ要素は DSCC に読み取り専用で表示されます。
  
  'user defined' という値は、LDAP または DSCC を使用してカスタムスキーマ定義を追加する場合は、サーバーによって自動的に追加されます。ただし、X-ORIGIN フィールドによりわかりやすい値を追加しないと、どのスキーマが関連しているかをあとで理解することが難しくなります。
変更は自動的にはレプリケートされないため、カスタムスキーマファイルはすべてのサーバーに手動で伝達します。

ディレクトリスキーマを変更すると、サーバーはスキーマがいつ変更されたのかを示すタイムスタンプを記録します。各レプリケーションセッションの最初に、サーバーはコンシューマのタイムスタンプとこのタイムスタンプを比較し、必要であればスキーマの変更をプッシュします。カスタムスキーマファイルについては、サーバーは 99user.ldif ファイルに関連付けられている 1 つのタイムスタンプだけを維持します。つまり、カスタムスキーマファイルに加えた変更、または 99user.ldif 以外のファイルに対する変更は、レプリケートされません。このため、トポロジ全体にすべてのスキーマ情報が行き渡るように、カスタムスキーマファイルをほかのすべてのサーバーに伝達する必要があります。