Directory Serverのスキーマの拡張

スキーマに新しい属性を追加する場合は、それらの属性を持つオブジェクト・クラスを新しく作成する必要があります。必要な属性のほとんどが含まれている既存のオブジェクトクラスに対して属性を追加したほうが便利とも思えますが、それを行うとLDAPクライアントとの相互運用性が損なわれてしてしまいます。

Directory Serverと既存のLDAPクライアントとの相互運用性は、標準のLDAPスキーマに依存します。標準スキーマを変更した場合、サーバーのアップグレード時にも問題が発生します。同様の理由により、標準スキーマの要素は削除できません。スキーマをカスタマイズするための一般的なガイドラインの詳細は、「カスタム・スキーマについて」を参照してください。

Directory Serverのスキーマは、cn=schemaエントリの属性に格納されます。構成エントリと同様に、これはサーバーの起動中にファイルから読み取られるスキーマのLDAPビューです。

Directory Serverスキーマの拡張で使用する方法は、スキーマ拡張子を格納するファイル名を制御するかどうかにより異なります。また、レプリケーションによってコンシューマに変更をプッシュするかどうかによっても異なります。次の表を参照して、特定の場合に実行する手順を判断してください。

表11-1 スキーマの拡張方法

オブジェクト・クラス、属性およびディレクトリ・スキーマにの詳細、ならびにスキーマ拡張のガイドラインについては、Oracle Directory Server Enterprise Editionデプロイメント・プランニング・ガイドのディレクトリ・スキーマの設計に関する項を参照してください。標準の属性およびオブジェクト・クラスについては、Oracle Directory Server Enterprise Editionマニュアル・ページ・リファレンスを参照してください。

この項では、ディレクトリ・スキーマを拡張するための様々な方法について説明します。

LDAPによるスキーマの拡張

スキーマは、cn=schemaのLDAPビューにより定義されるので、ldapsearchおよびldapmodifyユーティリティを使用してオンラインでスキーマを表示および変更できます。ただし、X-ORIGINフィールドに値’user defined’が設定されているスキーマ要素しか変更できません。他の定義に対する変更はいずれもサーバーにより拒否されます。

新しい要素の定義およびユーザー定義の要素に対する変更はファイル99user.ldifに保存されます。

LDAPによりスキーマを拡張するには:

このタスクの実行には、DSCCが使用できます。詳細は、「Directory Service Control Centerのインタフェース」およびDSCCのオンライン・ヘルプを参照してください。

始める前に

コマンドラインからのスキーマ定義の変更では、長い値を正確に入力する必要があるため、エラーが出やすくなります。しかし、ディレクトリ・スキーマの更新が必要なスクリプトでは、この機能を使用できます。

1. ldapmodify(1)コマンドを使用して、各attributeTypes属性値を追加または削除します。

   詳細は、「属性タイプを作成するには:」または「属性タイプを削除するには:」を参照してください。

2. ldapmodify(1)コマンドを使用して、各objectClasses属性値を追加または削除します。

   詳細は、「オブジェクト・クラスを作成するには:」または「オブジェクト・クラスを削除するには:」を参照してください。

関連項目

いずれかの値を変更するには、特定の値を削除して、新しい値として値を追加する必要があります。属性は複数値であるので、このプロセスは必須となります。詳細は、「複数値属性の1つの値の変更」を参照してください。

カスタム・スキーマ・ファイルでのスキーマの拡張

---

注意: スキーマを拡張するためのスキーマ・ファイル変更については、このスキーマ拡張方法ではエラーが出やすくなるのでお薦めできません。Directory Serverのスキーマに対して変更を行うには、より信頼性の高いスキーマ拡張方法であるldapmodifyコマンドを使用してください。

---

スキーマ・ファイルは、instance-path/config/schema/にあるLDIFファイルです。instance-pathはDirectory Serverインスタンスのあるファイル・システム・ディレクトリに相当します。たとえば、インスタンスは/local/dsInst/などにあります。このファイルはDirectory ServerとDirectory Serverに依存するすべてのサーバーが使用する標準スキーマを定義します。このファイルと標準スキーマについては、Oracle Directory Server Enterprise EditionリファレンスおよびOracle Directory Server Enterprise Editionマニュアル・ページ・リファレンスで説明しています。

サーバーは、起動時に1回のみスキーマ・ファイルを読み取ります。このファイルのLDIFコンテンツは、スキーマのメモリー内LDAPビューのcn=schemaに追加されます。スキーマ定義の順序は重要なので、スキーマ・ファイル名の先頭には数字が付けられ、英数字の順序でロードされます。このディレクトリのスキーマ・ファイルには、インストール時に定義されたシステム・ユーザーのみが書込み可能です。

LDIFファイル内でスキーマを直接定義する場合、X-ORIGINフィールドに値’user defined’は使用できません。この値は、cn=schemaのLDAPビューで定義されファイル99user.ldif内にあるスキーマ要素用に予約されています。

99user.ldifファイルには、cn=schemaエントリと、コマンドラインまたはDSCCから追加されたすべてのスキーマ定義の追加ACIが含まれます。99user.ldifファイルは、新しいスキーマ定義を追加すると上書きされます。このファイルを変更する場合、変更が最新になるように、サーバーをただちに再起動する必要があります。

他のスキーマ・ファイルで定義される標準スキーマは変更しないでください。ただし、新規ファイルを追加して、新しい属性やオブジェクト・クラスを定義することはできます。たとえば、多数のサーバーで新しいスキーマ定義を定義するには、98mySchema.ldifという名前のファイルにその要素を定義して、このファイルをすべてのサーバーのスキーマ・ディレクトリにコピーします。その後、すべてのサーバーを再起動して、新しいスキーマ・ファイルをロードします。

カスタム・スキーマ・ファイルでスキーマを拡張するには

このタスクの実行には、DSCCが使用できます。詳細は、「Directory Service Control Centerのインタフェース」およびDSCCのオンライン・ヘルプを参照してください。

1. 独自のスキーマ定義ファイル(98mySchema.ldifなど)を作成します。

   スキーマ・ファイル内の定義の構文については、RFC 4517で説明されています。

   カスタムのスキーマ・ファイルを作成する前に、「カスタム・スキーマ・ファイルを作成する場合」をお読みください。

2. (オプション)このサーバーが、他のサーバーに更新を送信するマスター・レプリカである場合、スキーマ定義ファイルをレプリケーション・トポロジ内の各サーバー・インスタンスにコピーします。

   レプリケーション・メカニズムでは、スキーマを含むLDIFファイルに直接加えた変更は検出できません。したがって、マスターを再起動後しても変更はコンシューマにレプリケートされません。

3. スキーマ定義ファイルをコピーした各Directory Serverインスタンスを再起動します。

   サーバーが再起動すると、スキーマ定義が再ロードされ、変更が有効になります。

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

カスタム・スキーマ・ファイルの作成時、特にレプリケーションの使用時には、次のことに留意してください。

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

• 作成するカスタムの各属性またはオブジェクト・クラスは、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に読取り専用で表示されます。

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

  これらの変更は、自動的にはレプリケートされません。レプリケートするには、カスタム・スキーマ・ファイルをすべてのサーバーに手動で伝播する必要があります。

  ディレクトリ・スキーマを変更すると、サーバーにはスキーマが変更されたときのタイムスタンプが保持されます。各レプリケーション・セッションの開始時に、サーバーは自身のタイムスタンプとコンシューマのタイムスタンプを比較し、必要に応じてスキーマの変更をプッシュします。カスタム・スキーマ・ファイルに対しては、サーバーでは99user.ldifファイルに関連付けられたタイムスタンプ1つのみが維持されます。つまり、99user.ldif以外のファイルに対するカスタム・スキーマ・ファイルの変更または追加はレプリケートされません。したがって、カスタム・スキーマ・ファイルを他のすべてのサーバーに伝播して、すべてのスキーマ情報がトポロジ全体に行き渡るようにする必要があります。

スキーマ・ファイルおよびレプリケーションを使用したスキーマの拡張

カスタム・スキーマ・ファイルの詳細は、「カスタム・スキーマ・ファイルでのスキーマの拡張」を参照してください。次の手順では、レプリケーション・メカニズムを使用してスキーマ拡張をトポロジ内のすべてのサーバーに伝播する方法を説明します。

スキーマ・ファイルおよびレプリケーションを使用してスキーマを拡張するには:

この手順では部分的ですが、タスクの実行にDSCCを使用できます。詳細は、「Directory Service Control Centerのインタフェース」およびDSCCのオンライン・ヘルプを参照してください。その他の部分の手順では、コマンドラインを使用しなければ実行できません。

1. 次のいずれかの方法でスキーマ拡張を準備します。
   • 独自のスキーマ定義ファイル(98mySchema.ldifなど)を作成します。
   • スキーマ拡張を99user.ldifに追加します。

   スキーマ・ファイル内の定義の構文については、RFC 4517で説明されています。

2. スキーマ定義ファイルを配置したマスター・サーバーで、dsadm startまたはdsadm restartコマンドを、--schema-pushを指定して実行します。

   実際には、このスクリプトではスキーマをレプリカにプッシュしません。そのかわり、このスクリプトは、スキーマ・ファイルがロードされるとすぐにレプリケートされるように、特別な属性をスキーマ・ファイルに書き込みます。詳細は、dsadm(1M)のマニュアル・ページを参照してください。

3. スキーマ定義ファイルを配置したマスター・サーバーを再起動します。

   レプリケーション・メカニズムでは、スキーマを含むLDIFファイルに直接加えた変更は検出できません。サーバーを再起動すると、サーバーがすべてのスキーマ・ファイルをロードし、レプリケーション・メカニズムによって、新しいスキーマがコンシューマにレプリケートされます。