第 3 章 Directory Server のスキーマ

第 2 章で実施したサイト調査により、ディレクトリに格納しようと計画しているデータについての情報を収集できました。次に、このデータの表現方法を決める必要があります。ディレクトリスキーマは、ディレクトリに格納できるデータのタイプを表します。スキーマの設計時には、各データ要素を LDAP 属性に割り当て、関連する要素を集めて LDAP オブジェクトクラスに入れます。スキーマを適切に設計することで、データの整合性を維持できます。

この章では、スキーマの設計方法について次の項目ごとに説明します。

Directory Server のオブジェクトクラスと属性、およびスキーマファイルとディレクトリ設定属性については、『Directory Server Administration Reference』を参照してください。サーバー間でのスキーマのレプリケーション方法については、「スキーマのレプリケーション」を参照してください。

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 で定義されている場合は、X-ORIGIN フィールドに Sun ONE Directory Server という値が入ります。

たとえば、標準の person オブジェクトクラスはスキーマ内で次のように示されます。

objectclasses: ( 2.5.6.6 NAME 'person' DESC 'Standard Person
Object Class' SUP top MUST (objectclass $ 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) を示しています。

すべての Directory Server のスキーマと同様、オブジェクトクラスは Directory Server で直接定義され、格納されています。これは、ディレクトリのスキーマを標準の LDAP 操作で問い合わせたり、変更したりできるということです。

スキーマ設計のプロセス

スキーマの設計時には、Directory Server によって格納されるエントリを表すのに使用するオブジェクトクラスと属性を選択および定義します。スキーマの設計は、次の手順で行います。

可能であれば、最善の方法は、Directory Server が提供する標準スキーマに定義されている既存のスキーマ要素を使用することです。標準スキーマの要素を選択すれば、ディレクトリを使用するアプリケーションとの互換性を保証できます。また、スキーマは LDAP 標準に基づいているので、多くのディレクトリユーザーによってレビューされ、承認されています。

デフォルトスキーマへのデータの割り当て

「サイト調査の実施」で説明したように、サイト調査で識別したデータをデフォルトディレクトリスキーマに割り当てる必要があります。この節では、デフォルトスキーマを表示する方法と、適切なスキーマ要素にデータを割り当てる方法について説明します。

デフォルトスキーマとマッチしない要素が独自のスキーマ内にある場合は、カスタマイズしたオブジェクトクラスと属性を作成する必要があります。詳細は、「スキーマのカスタマイズ」を参照してください。

デフォルトのディレクトリスキーマの表示

Directory Server で提供されるスキーマは、次のディレクトリに保存される一連のファイルに記述されています。

このディレクトリには、Sun Java System 製品のすべての共通スキーマが入っています。LDAPv3 標準のユーザースキーマと組織スキーマは、 00core.ldif ファイルに記述されています。旧バージョンのディレクトリで使用された設定スキーマは、50ns-directory.ldif ファイルに記述されています。

データとスキーマ要素の対応付け

サイト調査で識別したデータを既存のディレクトリスキーマに割り当てる必要があります。この作業は、次の手順で行います。


注	サーバーの稼動中は、このディレクトリ内のファイルを変更しないでください。手動で加えた変更は、LDAP または Directory Server コンソールを使用して別の変更を加えるまでレプリケートされません。

サイト調査に記載されているデータにもっとも適したオブジェクトを選択します。データで複数のオブジェクトを記述できる場合があります。必要に応じて別の要素をスキーマに入れるかどうかを決める必要があります。たとえば、電話番号に社員の電話番号と会議室の電話番号を記述できます。これらの電話番号データを、スキーマで異なるオブジェクトとみなすかどうかは設計者が決めます。

group、people、organization などの共通オブジェクトクラスを使用します。

対応するオブジェクトクラスから、サイト調査で識別したデータにもっとも適した属性を選択します。

デフォルトのディレクトリスキーマで定義されているオブジェクトクラスと属性に対応しないデータがある場合は、スキーマをカスタマイズする必要があります。詳細は、「スキーマのカスタマイズ」を参照してください。

次の表に、ディレクトリスキーマの要素をサイト調査で識別したデータに割り当てた例を示します。

表 3-1 デフォルトディレクトリスキーマに割り当てられたデータ
データ	所有者	オブジェクトクラス	属性
社員名	HR	person	cn(commonName)
ユーザーパスワード	IS	person	userPassword
自宅の電話番号	HR	inetOrgPerson	homePhone
社員の所属場所	IS	inetOrgPerson	localityName
会社の電話番号	設備	person	telephoneNumber

表 3-1 では、個人を社員名で表しています。デフォルトのディレクトリスキーマには、top オブジェクトクラスから継承する person オブジェクトクラスがあります。このオブジェクトクラスには複数の属性が許可されており、その中に個人の氏名を記述する cn (commonName ) という属性があります。この属性は、社員名データを入れる目的にもっとも適しています。

ユーザーパスワードも person オブジェクトに関連付けることができます。person オブジェクトの許可された属性に userPassword が含まれています。

自宅の電話番号は、特定の個人のある側面を表すものです。しかし、person オブジェクトクラスに関連するリストには、該当する属性がありません。自宅の電話番号をより本質的に分析すると、これは、組織的な企業ネットワークにおいて、特定の個人を表すものだといえます。このためこのオブジェクトは、ディレクトリスキーマの inetOrgPerson オブジェクトクラスに対応します。inetOrgPerson オブジェクトクラスは organizationalPerson オブジェクトクラスから継承し、organizationalPerson オブジェクトクラスは person オブジェクトクラスから継承します。inetOrgPerson オブジェクトの許可された属性には、社員の自宅の電話番号を入れるのに適した homePhone 属性があります。

スキーマのカスタマイズ

標準スキーマの制限が多すぎて、ディレクトリの要件に対応できない場合は、標準スキーマを拡張できます。Directory Server コンソールは、スキーマ定義を管理する上で役立ちます。詳細は、『Directory Server 管理ガイド』の「ディレクトリスキーマの拡張」を参照してください。

スキーマをカスタマイズするときは、次の規則に留意してください。

できるかぎり既存のスキーマ要素を再利用する。既存のすべてのスキーマ要素のリストは、『Directory Server Administration Reference』の「Object Class Reference」および「Attribute Reference」に記載されています。

各オブジェクトクラスに定義する必須の属性の数を最小限にする。

同じ目的で複数のオブジェクトクラスまたは属性を定義しない。

できるかぎりスキーマを簡潔にする。



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



注	Directory Server の内部オペレーショナル属性は変更しないでください。これらの属性は、Sun により今後のリリースで変更または書き替えられる可能性があります。ただし、外部アプリケーション用に独自のオペレーショナル変数を作成できます。

カスタムのオブジェクトクラスと属性は、次のファイル内に定義されます。

次の項目ごとに、ディレクトリスキーマのカスタマイズについて詳しく説明します。

スキーマの拡張が必要な場合

Directory Server が提供するオブジェクトクラスと属性は、ユーザーのほとんどの要件を満たしますが、既存のオブジェクトクラスによっては組織の特殊な情報を格納できない場合もあります。また、LDAP 対応アプリケーションの独自のデータ要件に適したオブジェクトクラスや属性をサポートできるように、スキーマを拡張しなければならない場合もあります。

オブジェクト識別子の取得と割り当て

各 LDAP オブジェクトクラスまたは属性には、一意の名前とオブジェクト識別子 (OID) が割り当てられている必要があります。スキーマを定義するときは、組織に固有の OID が必要です。1 つの OID ですべてのスキーマ要件に対応できます。別の階層レベルを追加するだけで、属性とオブジェクトクラスに新しい分岐を作成できます。OID の取得とスキーマでの割り当ては、次の手順で行います。

国によっては、企業にすでに OID が割り当てられています。所属する組織がまだ OID を持っていない場合は、IANA から取得できます。詳細は、IANA の Web サイト http://www.iana.org/cgi-bin/enterprise.pl を参照してください。

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

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

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

新しい属性やオブジェクトクラスに名前を付けるときは、できるかぎりわかりやすいものにします。わかりやすい名前にすると、Directory Server の管理者がスキーマを使いやすくなります。

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

新しいオブジェクトクラスの定義戦略

ディレクトリのエントリに格納する必要がある情報の中に既存のオブジェクトクラスがサポートしていないものがある場合は、新しいオブジェクトクラスを追加します。新しいオブジェクトクラスを作成するには、次の 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 Java System OID 接頭辞に基づいており、配備した製品内では使用できません。独自の新しいオブジェクトクラスを作成するには、独自の OID を取得する必要があります。詳細は、「オブジェクト識別子の取得と割り当て」を参照してください。

一般に、要素の数が少なければ、管理の手間も少なくて済みます。しかし、スキーマに 2 ～ 3 つのオブジェクトクラスを追加する場合は、1 つのオブジェクトクラスを使用する方が簡単です。

データを厳密に設計するには、個々のデータを配置するオブジェクトクラス構造を考慮する必要があります。これは、有用であることもあれば、面倒なこともあります。

たとえば、preferredOS 属性を人のエントリとグループエントリの両方に設定するとします。このような場合は、1 つのオブジェクトクラスを作成して、そのクラスでこの属性が許可されるようにします。

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

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

新しい属性の定義方法

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

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

スキーマ要素の削除

Directory Server に含まれているスキーマ要素は削除しないでください。未使用のスキーマ要素は、Directory Server の動作や管理において、オーバーヘッドになることはありません。標準 LDAP スキーマの一部を削除すると、将来提供される新しいバージョンの Directory Server や LDAP 対応アプリケーションとの互換性に問題が生じる可能性があります。

拡張したスキーマの新しい要素を使用しないときは、その不要要素を削除できます。スキーマ要素を削除する前に、ディレクトリ内のどのエントリもそれを使用しないことを確認してください。このためのもっとも簡単な方法は、そのスキーマ要素を含むすべてのエントリを返す ldapsearch を実行することです。

たとえば、myObjectClass というオブジェクトクラスを削除する前に、次の ldapsearch コマンドを実行します。

これに該当するエントリが見つかった場合は、それを削除するか、スキーマから消去される部分を削除することができます。あるスキーマ定義を使用するエントリを削除する前にそのスキーマ定義を削除すると、そのエントリを後から変更できなくなることがあります。不明な値をエントリから削除しない限り、変更されたエントリに関するスキーマ検査も失敗します。

カスタムスキーマファイルの作成 - 最良の事例と落とし穴

Directory Server に含まれている 99user.ldif ファイルのほかに、独自のカスタムスキーマファイルを作成できます。ただし、カスタムスキーマファイルを作成するとき、特にレプリケーションを使用する場合は、次の点に注意する必要があります。

新たに追加したスキーマ要素をオブジェクトクラスで使用するためには、事前にすべての属性が定義されている必要があります。属性とオブジェクトクラスは同じスキーマファイル内で定義できます。

作成する各カスタム属性またはオブジェクトクラスは、1 つのスキーマファイル内でだけ定義されている必要があります。これにより、サーバーが最新のスキーマを読み込むときに、前の定義を上書きするのを防ぐことができます。サーバーは、最初に数字順、次にアルファベット順にスキーマを読み込みます。

新しいスキーマ定義を手動で作成するときは、その定義を 99user.ldif ファイルに追加する方法が最も適しています。

LDAP を使用するスキーマ要素を更新すると、新しい要素が自動的に 99user.ldif ファイルに書き込まれます。このため、カスタムスキーマファイルに加えたそれ以外のスキーマ定義の変更が、上書きされる可能性があります。99user.ldif ファイルのみを使用すると、スキーマ要素の重複と、スキーマの変更の上書きを防ぐことができます。

この数字は、すでに定義されているどのディレクトリ標準スキーマよりも大きな値にする必要があります。

スキーマファイルの名前を標準のスキーマファイルより小さい数字で指定すると、そのスキーマを読み込むときにサーバーにエラーが発生することがあります。また、標準の属性およびオブジェクトクラスはすべて、カスタムスキーマ要素が読み込まれた後にしか読み込まれません。

作成したスキーマファイルに 99zzz.ldif という名前を付けると、次に LDAP または Directory Server コンソールを使用してスキーマを更新したときに、'user defined' (通常は 99user.ldif ファイルに格納される) の値として X-ORIGIN を持つすべての属性が 99zzz.ldif に書き込まれます。その結果、重複した情報を持つ 2 つの LDIF ファイルが存在し、99zzz.ldif ファイル内のいくつかの情報が削除される可能性があります。

スキーマ要素を手動で追加し、X-ORIGIN フィールドの 'user defined' を使用しない場合、これらのスキーマ要素は Directory Server コンソールの読み取り専用セクションに表示されるため、コンソールを使用して編集することができません。

'user defined' という値は、LDAP または Directory Server コンソールを使用してカスタムスキーマ定義を追加する場合は、サーバーによって自動的に追加されます。ただし、X-ORIGIN フィールドによりわかりやすい値を追加しないと、どのスキーマが関連しているかを後で理解することが難しくなります。

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

カスタムスキーマの変更は、次のいずれかの方法で伝達できます。

schema_push.pl スクリプトを実行して変更をレプリケートする。

作成したカスタムスキーマファイルをすべてのサーバーに手動でコピーする。

どちらの方法でも、それぞれのサーバーを再起動する必要があります。schema_push.pl スクリプトを使用してカスタムスキーマ定義をレプリケートする場合は、1 つのマスターだけでスキーマを維持する必要があります。スキーマ定義が存在しないコンシューマにスキーマ定義がレプリケートされると、それを定義したカスタムスキーマファイルではなく、99user.ldif ファイルに定義が格納されます。スキーマ要素をコンシューマの 99user.ldif ファイルに格納しても、1 つのマスターサーバーだけでスキーマを管理している限り問題はありません。

スキーマファイルを手動でコピーする方法を選択した場合は、変更のたびにファイルをコピーする必要があります。変更のたびにコピーしないと、変更がレプリケートされ、コンシューマの 99user.ldif ファイルに格納されることがあります。変更が 99user.ldif ファイル内に格納されるとスキーマの管理が難しくなります。これは、一部の属性が、コンシューマ上の 2 つのスキーマファイル (サプライヤからコピーした元のカスタムスキーマファイルとレプリケート後の 99user.ldif ファイル) の両方に現れるためです。

カスタムスキーマ要素がレプリケーショントポロジ内の別のサーバーにレプリケートされないようにするには、次のようにします。

レプリケートしたくないスキーマ要素を別のファイルに定義する。

それらの要素を X-ORIGIN フィールドの 'user defined' として識別しない。

X-ORIGIN フィールドで 'user defined' というラベルを持つスキーマだけがレプリケートされるように、nsslapd-schema-repl-useronly 属性を on に設定する。



注	また、バージョン 5.0 または 5.1 の Directory Server にレプリケートするときは、この nsslapd-schema-repl-useronly 属性を on に設定する必要があります。

データの整合性の維持

Directory Server 内のスキーマの整合性を維持すると、LDAP クライアントアプリケーションがディレクトリのエントリを検出しやすくなります。ディレクトリに格納している情報のタイプごとに、その情報をサポートするために必要なオブジェクトクラスと属性を選択し、常に同じものを使用します。整合性のないスキーマオブジェクトを使用すると、情報を効率よく検出できなくなります。

次のようにすると、整合性のあるスキーマを維持できます。

次に、スキーマの整合性を維持する方法について詳しく説明します。

スキーマ検査

スキーマ検査は、すべての新しいまたは変更したディレクトリエントリが、スキーマ規則にマッチしているかどうかを検査します。規則にマッチしていない場合、ディレクトリは変更要求を拒否します。



注	スキーマ検査では、適切な属性があるかどうかだけを検査します。属性値が当該属性について正しい構文で記述されているかどうかは検査しません。Directory Server には nsslapd-valuecheck という属性があり、これを使用することで値に DN 構文が含まれている属性を検索することができます。ただし、この属性はデフォルトではオフに設定されているため、属性値の検査は行われません。

デフォルトでは、スキーマ検査はデフォルトで有効になっています。クライアントの更新を受け付けるサーバーでは、スキーマ検査はオフにしないでください。スキーマ検査をオン、オフする方法については、『Directory Server 管理ガイド』の「スキーマ検査」を参照してください。

スキーマ検査を有効にする場合は、オブジェクトクラスで定義されている必須の属性と許可された属性に注意する必要があります。通常、オブジェクトクラス定義には少なくとも 1 つの必須の属性と 1 つ以上の省略可能な属性が含まれています。省略可能な属性とは、ディレクトリのエントリに追加できるが必須ではない属性のことです。エントリのオブジェクトクラス定義で必須でなく許可されてもいない属性をエントリに追加しようとすると、Directory Server はオブジェクトクラス違反メッセージを返します。

たとえば、エントリで organizationalPerson オブジェクトクラスを使用するように定義した場合は、commonName (cn) および surname (cn) 属性がそのエントリの必須の属性になります。これらの属性にはエントリの作成時に値を指定する必要があります。さらに、オプションとしてエントリで使用できる属性の長いリストがあります。このリストには、telephoneNumber、Uid、streetAddress、userPassword などの説明属性が含まれています。

スキーマ検査を設定するときは、次の点に留意してください。

一般には、スキーマ違反を回避するために、スキーマに定義されている各エントリのすべての必須属性をレプリケートします。部分レプリケーションを使用して一部の必須属性をフィルタリングする場合は、スキーマ検査を無効にする必要があります。

スキーマ検査で部分レプリケーションが有効になっていると、サーバーを ldif ファイルからオフラインで初期化できなくなる可能性があります。これは、必須属性をフィルタリングすると、サーバーが ldif ファイルを読み込めなくなるためです。

スキーマ検査を無効にすると、パフォーマンスが向上する場合があります。

部分コンシューマレプリカでスキーマ検査を無効にした場合、その部分コンシューマレプリカが存在するサーバーインスタンス全体にスキーマが適用されなくなります。このため、同じサーバーインスタンスではサプライヤ (読み取り、書き込み) レプリカを設定しないようにする必要があります。

部分レプリケーションの設定ではサプライヤがスキーマをプッシュするため、部分コンシューマレプリカのスキーマは、マスターレプリカのスキーマのコピーとなります。このため、適用される部分レプリケーション設定には対応しません。

整合性のあるデータ形式の選択

LDAP スキーマを使用して、必要なデータを任意の属性値に格納できます。ただし、LDAP クライアントアプリケーションとディレクトリユーザーに適切な形式を選択して、ディレクトリツリー内で整合性を維持するようにデータを格納することが重要です。

LDAP プロトコルと Directory Server を使用する場合は、RFC 2252 で規定されているデータ形式でデータを表す必要があります。また、電話番号の正しい LDAP 形式は、次の ITU-T 勧告ドキュメントで定義されています。

国内および国際電話番号に関する注記。

国際電話サービスの番号計画。

postalAddress 属性には、区切り文字としてドル記号 ($) を使用する複数行文字列形式の属性値が必要です。適切に形式化されたディレクトリエントリは次のようになります。

レプリケートされたスキーマでの整合性の維持

レプリケート環境で整合性のあるスキーマを維持するには、次の点に留意します。

コンシューマサーバーのスキーマを変更すると、マスターサーバーのスキーマよりも新しいスキーマとなります。マスターがレプリケーションで更新をコンシューマに送信すると、コンシューマのスキーマが新しいデータをサポートできないため、多数のレプリケーションエラーが発生します。

2 つのマスターサーバーのスキーマを変更すると、最後に更新されたマスターのスキーマがコンシューマに伝達されます。これは、コンシューマのスキーマと他方のマスターのスキーマとの間に整合性がないことを意味します。



注	Directory Server 5.2 は 11rfc2307.ldif スキーマファイルを使用します。このスキーマファイルは、rfc2307 に準拠しています。 Directory Server 5.2 より前のバージョンの Directory Server では、10rfc2307.ldif スキーマファイルを使用します。異なるスキーマファイルを実行しているサーバー間でレプリケーションが有効な場合、レプリケーションは失敗します。 10rfc2307.ldif ファイルを使用している Directory Server インスタンスに、11rfc2307.ldif ファイルをコピーし、10rfc2307.ldif ファイルを削除します。

その他のスキーマ関連資料

標準 LDAPv3 スキーマについては、次のドキュメントを参照してください。

前へ目次索引次へ
Sun Java™ System Directory Server 5.2 2005Q1 配備計画ガイド