カスタムスキーマファイルを作成するとき、特にレプリケーションを使用する場合は、次の点に注意する必要があります。
新たに追加したスキーマ要素をオブジェクトクラスで使用するためには、事前にすべての属性が定義されている必要があります。属性とオブジェクトクラスは同じスキーマファイル内で定義できます。
作成する各カスタム属性またはオブジェクトクラスは、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 以外のファイルに対する変更は、レプリケートされません。このため、トポロジ全体にすべてのスキーマ情報が行き渡るように、カスタムスキーマファイルをほかのすべてのサーバーに伝達する必要があります。