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

ディレクトリーのニーズ用に標準スキーマの制限が多い場合、拡張できます。Directory Server の Web コンソールを使用して、属性とオブジェクトクラスを簡単に追加することにより、スキーマを拡張できます。LDIF ファイルを作成し、スキーマ要素を手動で追加することもできます。詳細は『Red Hat Directory Server 管理ガイド』を参照してください。
Directory Server スキーマをカスタマイズする場合は、以下のルールを念頭に置いてください。
  • スキーマはできるだけシンプルに保ちます。
  • 可能であれば、既存のスキーマ要素を再利用します。
  • 各オブジェクトクラスに定義される必須属性の数を最小限に抑える。
  • 複数のオブジェクトクラスまたは属性を同じ目的 (データ) に定義しないでください。
  • 属性またはオブジェクトクラスの既存の定義は変更しないでください。
注記
スキーマをカスタマイズする場合、標準スキーマの削除または置き換えは 絶対に行わないでください。これを行うと、他のディレクトリーやその他の LDAP クライアントアプリケーションとの互換性の問題が発生する可能性があります。
カスタムオブジェクトクラスおよび属性は 99user.ldif ファイルで定義されます。個々のインスタンスは、/etc/dirsrv/slapd-instance_name/schema/ ディレクトリーに独自の 99user.ldif ファイルを維持します。カスタムスキーマファイルを作成し、スキーマを動的にサーバーにリロードすることもできます。

3.4.1. スキーマを拡張するケース

Directory Server により提供されるオブジェクトクラスおよび属性は、ほとんどの一般的な企業のニーズに対応しますが、特定のオブジェクトクラスは組織に関する特殊な情報を格納できない場合があります。また、スキーマは LDAP 対応アプリケーションの固有のデータニーズに必要なオブジェクトクラスおよび属性をサポートするために拡張する必要があることがあります。

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

各 LDAP オブジェクトクラスまたは属性には、一意の名前と オブジェクト識別子 (OID) を割り当てる必要があります。スキーマが定義されている場合、要素には組織に固有のベース OID が必要です。すべてのスキーマニーズを満たすのに、1 つの OID で十分です。別の階層レベルを追加して、属性とオブジェクトクラスの新規ブランチを作成します。スキーマで OID を取得して割り当てるには、以下のステップが必要です。
  1. Internet Assigned Numbers Authority (IANA) または国際的な組織から OID を取得します。
    国によっては、企業に OID がすでに割り当てられています。組織に OID がない場合は、IANA から取得できます。詳細は、IANA の Web サイト (http://www.iana.org/cgi-bin/enterprise.pl) にアクセスしてください。
  2. OID 割り当てを追跡する OID レジストリーを作成します。
    OID レジストリーは、OID と、ディレクトリースキーマで使用される OID の説明のリストです。これにより、OID が複数の目的に使用されないようにします。次に、スキーマに OID レジストリーをパブリッシュします。
  3. スキーマ要素に対応するために OID ツリーでブランチを作成します。
    属性に OID.1 を、オブジェクトクラスに OID.2 を使用して、OIDブランチまたはディレクトリースキーマに少なくとも 2 つのブランチを作成します。カスタムマッチングルールまたは制御を定義するには、必要に応じて新規ブランチを追加します（例：OID.3 ）。

3.4.3. 命名属性およびオブジェクトクラス

新しい属性とオブジェクトクラスの名前を作成する場合は、名前をできるだけ意味のあるものにしてください。これにより、Directory Server の管理者はスキーマを簡単に使用できます。
すべてのスキーマ要素に一意の接頭辞を含めることで、スキーマ要素と既存のスキーマ要素間の命名の競合を回避してください。たとえば、Example Corp. は、それぞれのカスタムスキーマ要素の前に接頭辞 example を追加します。ディレクトリー内で Example Corp. 従業員を特定するために、examplePerson という特別なオブジェクトクラスを追加する場合があります。

3.4.4. 新規オブジェクトクラスを定義するストラテジー

新しいオブジェクトクラスを作成する方法は 2 つあります。
  • 属性を追加する各オブジェクトクラス構造に対して、多くの新規オブジェクトクラスを作成します。
  • ディレクトリーに作成されるすべてのカスタム属性をサポートする単一のオブジェクトクラスを作成します。この種類のオブジェクトクラスは、補助オブジェクトクラスとして定義して作成します。
2 つのメソッドを混在させることが最も簡単な場合があります。
たとえば、管理者が属性 exampleDateOfBirth、examplePreferredOS、exampleBuildingFloor、および exampleVicePresident を作成するとします。簡単なソリューションは、これらの属性のサブセットを許可する複数のオブジェクトクラスを作成することです。
  • 1 つのオブジェクトクラス examplePerson が作成され、exampleDateOfBirth および examplePreferredOS を許可します。examplePerson の親は inetOrgPerson です。
  • 2 つ目のオブジェクトクラス exampleOrganization は、exampleBuildingFloor および exampleVicePresident を許可します。exampleOrganization の親は、organization オブジェクトクラスです。
新しいオブジェクトクラスは、以下のように 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) )
または、これらの属性をすべて許可するオブジェクトクラスを 1 つ作成し、これらの属性を必要とするエントリーと共に使用ます。単一のオブジェクトクラスは以下のようになります。 
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 というマークが付けられます。つまり、構造のオブジェクトクラスに関係なく、任意のエントリーと併用できます。
注記
この例の新しいオブジェクトクラスの OID (2.1.117370)は、以前の Netscape OID 接頭辞に基づいています。カスタムオブジェクトクラスを作成するには、「オブジェクト識別子の取得と割り当て」の説明に従って OID を取得します。
組織環境に応じて、新規オブジェクトクラスを整理する方法はいくつかあります。新しいオブジェクトクラスの実装方法を決定する際に、以下を考慮してください。
  • 複数のオブジェクトクラスによって、作成および維持するスキーマ要素がより多くなります。
    通常、要素の数が小さいため、メンテナンスはほとんど必要ありません。ただし、スキーマに 2 つ以上のオブジェクトクラスが追加されている場合は、単一のオブジェクトクラスを使用するのがより簡単です。
  • 複数のオブジェクトクラスの場合には、より注意深い厳密なデータ設計が必要です。
    厳密なデータ設計により、すべてのデータが置かれるオブジェクトクラス構造に注意を払うことが強制されます。これには、便利な面と面倒な面があります。
  • 人とアセットエントリーの両方など、複数のタイプのオブジェクトクラスに適用できるデータがある場合に、単一のオブジェクトクラスはデータ設計を簡素化します。
    たとえば、カスタムの preferredOS 属性は、ユーザーエントリーとグループエントリーの両方に設定できます。単一のオブジェクトクラスは両方のタイプのエントリーでこの属性を許可できます。
  • 新規オブジェクトクラスには、必要な属性は使用しないでください。
    新規オブジェクトクラスの属性に 許可 ではなく 必要 を指定すると、スキーマが柔軟ではなくなります。新規オブジェクトクラスを作成する場合には、できるだけ 必要 でなく 許可 を使用します。
    新しいオブジェクトクラスを定義したら、許可および必要な属性、ならびに属性を継承するオブジェクトクラスを決定します。

3.4.5. 新規属性を定義する際のストラテジー

アプリケーションの互換性と長期的なメンテナンスの両方のために、可能な場合は常に標準の属性を使用します。デフォルトのディレクトリースキーマにすでに存在する属性を検索し、新しいオブジェクトクラスと関連する属性を使用するか、『Directory Server Schema Guide』を確認してください。ただし、標準スキーマに必要なすべての情報が含まれていない場合は、新しい属性と新しいオブジェクトクラスを追加します。
たとえば、 person エントリーでは、デフォルトで person、organization openblas、または inetOrgPerson オブジェクトクラスがサポートするよりも多くの属性が必要になる場合があります。たとえば、標準の Directory Server スキーマには、生年月日を格納する属性はありません。新しい属性 dateOfBirth を作成し、新しい補助オブジェクトクラス examplePerson 内で許可される属性として設定できます。 
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')
重要事項: カスタム属性を標準のスキーマ要素に追加したり、削除したり しないでください。ディレクトリーにカスタム属性が必要な場合は、カスタムオブジェクトクラスを追加してそれらを含めます。

3.4.6. スキーマ要素の削除

Directory Server にデフォルトで含まれるスキーマ要素を削除しないでください。未使用のスキーマ要素は、操作や管理のオーバーヘッドを表しません。標準の LDAP スキーマの一部を削除すると、Directory Server およびその他のディレクトリー対応アプリケーションの今後のインストールとの間で互換性の問題が発生する可能性があります。
ただし、未使用のカスタムスキーマ要素を削除できます。スキーマからオブジェクトクラス定義を削除する前に、オブジェクトクラスを使用して各エントリーを変更します。最初に定義を削除すると、オブジェクトクラスを使用するエントリーが後で変更されなくなる可能性があります。未知のオブジェクトクラス値がエントリーから削除されない限り、変更されたエントリーのスキーマチェックも失敗します。

3.4.7. カスタムスキーマファイルの作成

管理者は、Directory Server で提供される 99user.ldif ファイルに加えて、Directory Server が使用するカスタムスキーマファイルを作成できます。これらのスキーマファイルは、組織に固有の新しいカスタム属性とオブジェクトクラスを保持します。新しいスキーマファイルは、スキーマディレクトリー /etc/dirsrv/slapd-instance_name/schema/ に配置する必要があります。
標準属性とオブジェクトクラスはすべて、カスタムスキーマ要素が読み込まれた後にのみロードされます。
注記
カスタムスキーマファイルは、99user.ldif より数字またはアルファベット順で高くしないでください。そうしないと、サーバーで問題が発生する可能性があります。
カスタムスキーマファイルの作成後、全サーバー間でスキーマの変更を分散する方法が 2 つあります。
  • このカスタムスキーマファイルをインスタンスのスキーマディレクトリー /etc/dirsrv/slapd-instance/schema に手動でコピーします。スキーマをロードするには、サーバーを再起動するか、schema-reload.pl スクリプトを実行してスキーマを動的にリロードします。
  • Web コンソールまたは ldapmodify などの LDAP クライアントでサーバーのスキーマを変更します。
  • サーバーがレプリケートされたら、レプリケーションプロセスがスキーマ情報を各コンシューマーサーバーにコピーするのを許可します。
    レプリケーションでは、レプリケートされたスキーマ要素はすべてコンシューマーサーバーの 99user.ldif ファイルにコピーされます。90example_schema.ldif などのカスタムスキーマファイルにスキーマを保持するには、ファイルを手動でコンシューマーサーバーにコピーする必要があります。レプリケーションは、スキーマファイルをコピーしません。
これらのカスタムスキーマファイルがすべてのサーバーにコピーされていない場合、Web コンソールまたは ldapmodify などの LDAP クライアントを使用してサプライヤーサーバーのスキーマに変更が加えられた場合に限り、スキーマ情報はレプリカ（コンシューマーサーバー）に複製されます。
スキーマ定義が存在しないコンシューマーサーバーに複製されると、99user.ldif ファイルに保存されます。このディレクトリーは、スキーマ定義の保存場所を追跡しません。コンシューマーの 99user.ldif ファイルにスキーマ要素を保存しても、スキーマがサプライヤーサーバーでのみ維持されている限り、問題はありません。
カスタムスキーマファイルが各サーバーにコピーされた場合、スキーマファイルへの変更を各サーバーに再度コピーする必要があります。ファイルが再びコピーされない場合、変更がコンシューマー上の 99user.ldif ファイルに複製され保存される可能性があります。99user.ldif ファイルに変更を加えると、スキーマ管理が困難になる可能性があります。これは、一部の属性がコンシューマー上の 2 つの別個のスキーマファイルに表示されるためです。1 度は、サプライヤーからコピーされた元のカスタムスキーマファイルで、レプリケーション後に 99user.ldif ファイルに再度表示されるためです。
スキーマの複製の詳細は、「スキーマレプリケーション」を参照してください。

3.4.8. カスタムスキーマのベストプラクティス

スキーマファイルを使用する場合は、互換性があり、管理しやすいスキーマを必ず作成してください。

3.4.8.1. スキーマファイルの命名

カスタムスキーマファイルの命名時には、以下の命名形式を使用します。 
[00-99]yourName.ldif
99user.ldif よりも低いもの（数字とアルファベット順）のカスタムスキーマファイルに名前を付けます。これにより、LDAP ツールと Web コンソールの両方で、Directory Server が 99user.ldif への書き込みが可能になります。
99user.ldif ファイルには、X-ORIGIN 値が 'user defined' の属性が含まれます。ただし、Directory Server は、すべての ユーザー定義のスキーマ要素を、数値順でアルファベット順に名前の高いファイルに書き込みます。99zzz.ldif という名前のスキーマファイルがある場合、次にスキーマが更新されるとき(LDAP コマンドラインツールまたは Web コンソールを使用)、'user defined' の値を持つ X-ORIGIN 属性はすべて 99zzz.ldif に書き込まれます。結果は、重複情報が含まれる 2 つの LDIF ファイルであり、99zzz.ldif ファイルの一部の情報が消去される可能性があります。

3.4.8.2. Origin として 'user defined' の使用

'user defined' は、LDAP でスキーマが追加されるときに Directory Server によって内部で使用されるため、カスタムスキーマファイル（例： 60example.ldif）の X-ORIGIN フィールドに 'user defined' を使用し ない でください。カスタムスキーマファイルで、'Example Corp. defined' などの説明的なものを使用します。
ただし、カスタムスキーマ要素を手動で 99user.ldif に直接追加する場合は、'user defined' を X-ORIGIN の値として使用します。別の X-ORIGIN 値を設定すると、サーバーはそれを上書きする可能性があります。
'user defined' の値の X-ORIGIN を使用すると、99user.ldif ファイルのスキーマ定義が Directory Server によってファイルから削除されないようにします。Directory Server は、'user defined' の値の X-ORIGIN を使用して、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')
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') )

3.4.8.3. オブジェクトクラスの前の属性の定義

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

3.4.8.4. 単一ファイルでのスキーマの定義

カスタム属性またはオブジェクトクラスは、それぞれ 1 つのスキーマファイルでのみ定義する必要があります。これにより、最近作成されたスキーマを読み込む際に、サーバーが以前の定義をオーバーライドしなくなります (サーバーは最初に番号順、その後にアルファベット順でスキーマを読み込むため)。重複するファイルにスキーマを確保しない方法を決定します。
  • 各スキーマファイルにどのスキーマ要素が含まれているかに注意してください。
  • スキーマファイルの命名および更新には注意が必要です。スキーマ要素が LDAP ツールを使用して編集されると、変更が自動的に最後のファイル (アルファベット順) に書き込まれます。ほとんどのスキーマの変更は、デフォルトのファイル 99user.ldif に書き込みます。これは、60example.ldif などのカスタムスキーマファイルではありません。また、99user.ldif のスキーマ要素は、他のスキーマファイルの重複要素を上書きします。
  • すべてのスキーマ定義を 99user.ldif ファイルに追加します。これは、Web コンソールからスキーマを管理している場合に便利です。