3.4. スキーマのカスタマイズ

各 LDAP オブジェクトクラスまたは属性に一意の名前と object identifier (OID) を割り当てる必要があります。スキーマを定義する場合、要素には組織固有のベース OID が必要です。別の階層レベルを追加して、属性とオブジェクトクラスの新規ブランチを作成します。スキーマで OID を取得して割り当てるには、以下のステップが必要です。

新しいオブジェクトクラスは次の 2 つの方法で作成できます。

2 つの方法を組み合わせることもできます。たとえば、exampleDateOfBirth、examplePreferredOS、exampleBuildingFloor、および exampleVicePresident という属性を作成するとします。簡単なソリューションは、これらの属性のサブセットを許可する複数のオブジェクトクラスを作成することです。

新しいオブジェクトクラスは、以下のように LDAPv3 スキーマ形式で表示されます。

objectclasses: ( 2.16.840.1.117370.999.1.2.3 NAME 'examplePerson' DESC 'Example Person Object Class'
     SUP inetorgPerson MAY (exampleDateOfBirth $ examplePreferredOS) )

objectclasses: ( 2.16.840.1.117370.999.1.2.4 NAME 'exampleOrganization' DESC 'Organization Object Class'
     SUP organization MAY (exampleBuildingFloor $ exampleVicePresident) )

objectclasses: ( 2.16.840.1.117370.999.1.2.3 NAME 'examplePerson' DESC 'Example Person Object Class'
     SUP inetorgPerson MAY (exampleDateOfBirth $ examplePreferredOS) )

objectclasses: ( 2.16.840.1.117370.999.1.2.4 NAME 'exampleOrganization' DESC 'Organization Object Class'
     SUP organization MAY (exampleBuildingFloor $ exampleVicePresident) )

あるいは、これらすべての属性を許可する単一のオブジェクトクラスを作成し、それらを必要とするエントリーで使用することもできます。単一のオブジェクトクラスは以下のようになります。

objectclasses: (2.16.840.1.117370.999.1.2.5 NAME 'exampleEntry' DESC 'Standard Entry Object Class' SUP top
     AUXILIARY MAY (exampleDateOfBirth $ examplePreferredOS $ exampleBuildingFloor $ exampleVicePresident) )

objectclasses: (2.16.840.1.117370.999.1.2.5 NAME 'exampleEntry' DESC 'Standard Entry Object Class' SUP top
     AUXILIARY MAY (exampleDateOfBirth $ examplePreferredOS $ exampleBuildingFloor $ exampleVicePresident) )

新しい exampleEntry オブジェクトクラスには AUXILIARY というマークが付き、構造的なオブジェクトクラスとは無関係に任意のエントリーと共に使用できることを意味します。

組織環境に応じて新しいオブジェクトクラスを編成できます。新しいオブジェクトクラスの実装を決定するときは、次の点を考慮してください。

アプリケーションの互換性と長期的なメンテナンスの両方のために、標準属性を使用する必要があります。デフォルトのディレクトリースキーマにすでに存在する属性を検索し、それを新しいオブジェクトクラスで使用するか、Directory Server スキーマガイドを確認する必要があります。ただし、標準スキーマに必要な情報がすべて含まれていない場合は、新しい属性と新しいオブジェクトクラスを追加します。

たとえば、person エントリーでは、デフォルトで person、organizationalPerson、または inetOrgPerson オブジェクトクラスがサポートするよりも多くの属性が必要になる可能性があります。標準の Directory Server スキーマ内には、生年月日を保存するための属性は存在しません。新しい補助オブジェクトクラス examplePerson 内の許可属性として、新しい属性 dateOfBirth を作成して設定できます。

attributetypes: ( dateofbirth-oid NAME 'dateofbirth' DESC 'For employee birthdays'
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Example defined')

objectclasses: ( 2.16.840.1.117370.999.1.2.3 NAME 'examplePerson' DESC 'Example Person Object Class'
     SUP inetorgPerson MAY (exampleDateOfBirth $ cn) X-ORIGIN 'Example defined')

attributetypes: ( dateofbirth-oid NAME 'dateofbirth' DESC 'For employee birthdays'
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Example defined')

objectclasses: ( 2.16.840.1.117370.999.1.2.3 NAME 'examplePerson' DESC 'Example Person Object Class'
     SUP inetorgPerson MAY (exampleDateOfBirth $ cn) X-ORIGIN 'Example defined')

Directory Server にデフォルトで含まれているスキーマ要素を削除することはできません。未使用のスキーマ要素は、操作や管理のオーバーヘッドを表しません。標準の LDAP スキーマの一部を削除すると、Directory Server およびその他のディレクトリー対応アプリケーションの今後のインストールとの間で互換性の問題が発生する可能性があります。

ただし、使用されていないカスタムスキーマ要素は削除できます。スキーマからオブジェクトクラス定義を削除する前に、オブジェクトクラスを使用して各エントリーを変更します。最初に定義を削除すると、オブジェクトクラスを使用するエントリーが後で変更されなくなる可能性があります。不明なオブジェクトクラス値がエントリーから削除されない限り、変更されたエントリーのスキーマチェックも失敗します。

Directory Server で提供される 99user.ldif ファイルに加えて、Directory Server 用のカスタムスキーマファイルを作成して使用することができます。これらのスキーマファイルには、組織固有の新しいカスタム属性とオブジェクトクラスが含まれます。新しいスキーマファイルは、スキーマディレクトリー /etc/dirsrv/slapd-instance_name/schema/ に配置されています。標準属性とオブジェクトクラスはすべて、カスタムスキーマ要素が読み込まれた後にのみロードされます。

カスタムスキーマファイルを作成したら、次の方法でスキーマの変更をすべてのサーバーに配布できます。

これらのカスタムスキーマファイルをすべてのサーバーにコピーしない場合は、サプライヤーサーバー上のスキーマに変更が加えられたときにのみ、スキーマ情報がコンシューマーサーバーにレプリケートされます。スキーマの定義がまだ存在しないコンシューマーサーバーにレプリケートされると、それらは 99user.ldif ファイルに保存されます。

次の提案は、互換性があり管理しやすいカスタムスキーマを定義するのに役立ちます。

カスタムスキーマファイルに名前を付ける場合は、[00-99]yourName.ldif という命名形式を使用します。

カスタムスキーマ要素を 99user.ldif に手動で直接追加する場合は、X-ORIGIN の値として 'user defined' を使用します。異なる X-ORIGIN 値が設定されている場合、サーバーはそれを上書きする可能性があります。

値が 'user defined' の X-ORIGIN を使用すると、Directory Server によって 99user.ldif ファイル内のスキーマ定義が削除されなくなります。

以下に例を示します。

attributetypes: ( exampleContact-oid NAME 'exampleContact'
DESC 'Example Corporate contact'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
X-ORIGIN 'Example defined')

attributetypes: ( exampleContact-oid NAME 'exampleContact'
DESC 'Example Corporate contact'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
X-ORIGIN 'Example defined')

Directory Server がスキーマエントリーを読み込むと、以下のように表示されます。

attributetypes: ( exampleContact-oid NAME 'exampleContact'
DESC 'Example Corporate contact'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
X-ORIGIN ('Example defined' 'user defined') )

attributetypes: ( exampleContact-oid NAME 'exampleContact'
DESC 'Example Corporate contact'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
X-ORIGIN ('Example defined' 'user defined') )