| Oracle® Fusion Middleware Oracle Directory Server Enterprise Edition管理者ガイド 11g リリース1 (11.1.1.7.0) B72439-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Directory Server Enterprise Edition管理者ガイド 11g リリース1 (11.1.1.7.0) B72439-01 |
|
前 |
次 |
Directory Serverには、数百のオブジェクト・クラスおよび属性を含む標準スキーマが付属しています。標準のオブジェクト・クラスおよび属性で、ほとんどのユーザー要件が満たされますが、新しいオブジェクト・クラスおよび属性を作成して、スキーマを拡張する必要がある場合もあります。標準スキーマの概要およびデプロイメントに合ったスキーマの設計手順については、『Oracle Fusion Middleware Oracle Directory Server Enterprise Editionデプロイメント・プランニング・ガイド』を参照してください。
この章では、スキーマの管理方法について説明します。この章の内容は次のとおりです。
スキーマ・チェックがオンの場合、インポート、追加および変更のすべての操作が、Directory Serverによって、現在定義されているディレクトリ・スキーマに準拠するようになります。
各エントリのオブジェクト・クラスおよび属性はスキーマに準拠します。
エントリには、そのエントリに定義されているすべてのオブジェクト・クラスに必要なすべての属性が含まれます。
エントリには、そのエントリのオブジェクト・クラスにより許可された属性のみが含まれます。
|
注意: エントリ変更の際、Directory Serverでは変更する属性のみでなく、エントリ全体でスキーマ・チェックを実行します。したがって、エントリのいずれかのオブジェクト・クラスまたは属性がスキーマに準拠しない場合、操作が失敗する場合もあります。 ただし、スキーマ・チェックでは構文に関する属性値の有効性については検証されません。 |
スキーマ・チェックはデフォルトでオンとなります。一般には、スキーマ・チェックをオンにして、Directory Serverを実行します。多くのクライアント・アプリケーションでは、スキーマ・チェックをオンにすることは、すべてのエントリがスキーマに準拠していることを示すとみなします。しかし、スキーマ・チェックをオンにすることで、Directory Serverがディレクトリの既存の内容を検証することにはなりません。ディレクトリのすべての内容がスキーマに確実に準拠するようにするには、エントリを追加する前、またはすべてのエントリを再初期化する前にスキーマ・チェックを有効にする以外に方法はありません。
スキーマ・チェックをオフにする例のひとつとして、スキーマに準拠していることがわかっているLDIFファイルのインポート操作を高速化する場合があります。ただし、スキーマに準拠しないエントリをインポートしてしまう危険性もあります。スキーマ・チェックがオフの場合、スキーマに準拠しないインポートされたエントリは検出されません。
レプリケートされた環境におけるスキーマ・チェックの使用については、「ディレクトリ・スキーマのレプリケート」を参照してください。
エントリがスキーマに準拠していない場合、このエントリを検索できず、エントリに対する変更処理も失敗することがあります。次の手順に従い、問題を修正します。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
開始する前に
スキーマ準拠の問題を修正する必要性を回避するには、デプロイメントの前にスキーマを計画し、スキーマの変更を最小限にします。詳細は、『Oracle Fusion Middleware Oracle Directory Server Enterprise Editionデプロイメント・プランニング・ガイド』を参照してください。
エントリが準拠しない理由を判断するには、エントリを取得し、それを現在定義されているスキーマと手動で比較します。
詳細は、「属性タイプを表示するには:」および「オブジェクト・クラスを表示するには:」を参照してください。
スキーマに準拠するようにエントリを変更するか、エントリに準拠するようにスキーマを変更します。
スキーマに新しい属性を追加する場合は、それらの属性を持つオブジェクト・クラスを新しく作成する必要があります。必要な属性のほとんどが含まれている既存のオブジェクトクラスに対して属性を追加したほうが便利とも思えますが、それを行うとLDAPクライアントとの相互運用性が損なわれてしてしまいます。
Directory Serverと既存のLDAPクライアントとの相互運用性は、標準のLDAPスキーマに依存します。標準スキーマを変更した場合、サーバーのアップグレード時にも問題が発生します。同様の理由により、標準スキーマの要素は削除できません。スキーマをカスタマイズするための一般的なガイドラインの詳細は、「カスタム・スキーマについて」を参照してください。
Directory Serverのスキーマは、cn=schemaエントリの属性に格納されます。構成エントリと同様に、これはサーバーの起動中にファイルから読み取られるスキーマのLDAPビューです。
Directory Serverスキーマの拡張で使用する方法は、スキーマ拡張子を格納するファイル名を制御するかどうかにより異なります。また、レプリケーションによってコンシューマに変更をプッシュするかどうかによっても異なります。次の表を参照して、特定の場合に実行する手順を判断してください。
表11-1 スキーマの拡張方法
| 作業 | 手順 |
|---|---|
|
LDAPによりスキーマを拡張する。 |
|
|
レプリケーションを使用しない。カスタム・スキーマ・ファイルを追加してスキーマを拡張する。 |
|
|
レプリケーションを使用する。すべてのサーバーでカスタム・スキーマ・ファイルのファイル名を保持する。 |
|
|
レプリケーションを使用する。マスター・レプリカにカスタム・スキーマ・ファイルを追加してスキーマを拡張する。次に、レプリケーション・メカニズムにより、そのスキーマ拡張をコンシューマ・サーバーにコピーする。 |
スキーマ・ファイルおよびレプリケーションを使用してスキーマを拡張するには: |
オブジェクト・クラス、属性およびディレクトリ・スキーマの詳細、ならびにスキーマ拡張のガイドラインについては、『Oracle Fusion Middleware Oracle Directory Server Enterprise Editionデプロイメント・プランニング・ガイド』のディレクトリ・スキーマの設計に関する項を参照してください。標準の属性およびオブジェクト・クラスについては、Oracle Directory Server Enterprise Editionのマニュアル・ページ・リファレンスを参照してください。
この項では、ディレクトリ・スキーマを拡張するための様々な方法について説明します。
スキーマは、cn=schemaのLDAPビューにより定義されるので、ldapsearchおよびldapmodifyユーティリティを使用してオンラインでスキーマを表示および変更できます。ただし、X-ORIGINフィールドに値'user defined'が設定されているスキーマ要素しか変更できません。他の定義に対する変更はいずれもサーバーにより拒否されます。
新しい要素の定義およびユーザー定義の要素に対する変更はファイル99user.ldifに保存されます。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
開始する前に
コマンドラインからのスキーマ定義の変更では、長い値を正確に入力する必要があるため、エラーが出やすくなります。しかし、ディレクトリ・スキーマの更新が必要なスクリプトでは、この機能を使用できます。
ldapmodifyコマンドを使用して、各attributeTypes属性値を追加または削除します。
詳細は、「属性タイプを作成するには:」または「属性タイプを削除するには:」を参照してください。
ldapmodifyコマンドを使用して、各objectClasses属性値を追加または削除します。
詳細は、「オブジェクト・クラスを作成するには:」または「オブジェクト・クラスを削除するには:」を参照してください。
関連項目:
いずれかの値を変更するには、特定の値を削除して、新しい値として値を追加する必要があります。属性は複数値であるので、このプロセスは必須となります。詳細は、「複数値属性の1つの値の変更」を参照してください。
|
注意: スキーマを拡張するためのスキーマ・ファイル変更については、このスキーマ拡張方法ではエラーが出やすくなるのでお薦めできません。Directory Serverのスキーマに対して変更を行うには、より信頼性の高いスキーマ拡張方法である |
スキーマ・ファイルは、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という名前のファイルにその要素を定義して、このファイルをすべてのサーバーのスキーマ・ディレクトリにコピーします。その後、すべてのサーバーを再起動して、新しいスキーマ・ファイルをロードします。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
独自のスキーマ定義ファイル(98mySchema.ldifなど)を作成します。
スキーマ・ファイル内の定義の構文については、RFC 4517 (http://www.ietf.org/rfc/rfc4517.txt)で説明されています。
カスタムのスキーマ・ファイルを作成する前に、「カスタム・スキーマ・ファイルを作成する場合」をお読みください。
このサーバーが、他のサーバーに更新を送信するマスター・レプリカである場合、スキーマ定義ファイルをレプリケーション・トポロジ内の各サーバー・インスタンスにコピーします。
レプリケーション・メカニズムでは、スキーマを含むLDIFファイルに直接加えた変更は検出できません。したがって、マスターを再起動後しても変更はコンシューマにレプリケートされません。
スキーマ定義ファイルをコピーした各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以外のファイルに対するカスタム・スキーマ・ファイルの変更または追加はレプリケートされません。したがって、カスタム・スキーマ・ファイルを他のすべてのサーバーに伝播して、すべてのスキーマ情報がトポロジ全体に行き渡るようにする必要があります。
カスタム・スキーマ・ファイルの詳細は、「カスタム・スキーマ・ファイルでのスキーマの拡張」を参照してください。次の手順では、レプリケーション・メカニズムを使用してスキーマ拡張をトポロジ内のすべてのサーバーに伝播する方法を説明します。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
次のいずれかの方法でスキーマ拡張を準備します。
独自のスキーマ定義ファイル(98mySchema.ldifなど)を作成します。
スキーマ拡張を99user.ldifに追加します。
スキーマ・ファイル内の定義の構文については、RFC 4517 (http://www.ietf.org/rfc/rfc4517.txt)で説明されています。
スキーマ定義ファイルを配置したマスター・サーバーで、dsadm startまたはdsadm restartコマンドを、--schema-pushを指定して実行します。
実際には、このスクリプトではスキーマをレプリカにプッシュしません。そのかわり、このスクリプトは、スキーマ・ファイルがロードされるとすぐにレプリケートされるように、特別な属性をスキーマ・ファイルに書き込みます。詳細は、dsadmに関する説明のマニュアル・ページを参照してください。
スキーマ定義ファイルを配置したマスター・サーバーを再起動します。
レプリケーション・メカニズムでは、スキーマを含むLDIFファイルに直接加えた変更は検出できません。サーバーを再起動すると、サーバーがすべてのスキーマ・ファイルをロードし、レプリケーション・メカニズムによって、新しいスキーマがコンシューマにレプリケートされます。
ディレクトリのニーズに対して、標準スキーマでは著しく制限される場合に、標準スキーマを拡張できます。スキーマをカスタマイズする際は、次のガイドラインに従います。
可能なかぎり、既存のスキーマ要素を再利用します。
各オブジェクト・クラスに対して定義する必須属性の数を最小限にします。
同じ目的に対して複数のオブジェクト・クラスまたは属性を定義しないでください。
スキーマはできるかぎり簡潔にします。
スキーマをカスタマイズする場合は、標準スキーマの属性またはオブジェクトクラスの既存の定義の変更、削除および置換は行わないでください。これを行うと、他のディレクトリおよびLDAPクライアント・アプリケーションとの互換性に問題が生じる可能性があります。
Directory Serverの内部操作属性は変更しないでください。ただし、外部のアプリケーション用に独自の操作変数を作成できます。
objectClass: extensibleObjectを使用するかわりに、常にオブジェクトクラスを定義しますDirectory Serverでは、オブジェクト・クラスextensibleObjectがあるエントリのスキーマ・チェックを実行しないため、エントリに存在する属性を制限したり、チェックしたりしません。アプリケーションでのタイプ・ミス(givenName属性タイプのgiveNameなど)は、Directory Serverでは認識されません。Directory Serverでは、extensibleObjectエントリの未定義属性はすべて複数値で、大文字/小文字が区別されないことを前提とします。さらに、特定のオブジェクト・クラスを持つエントリに依存するアプリケーションもあります。一般に、オブジェクト・クラスに対して拡張が必要なアプリケーションがある場合は、スキーマ管理を放棄しないでください。そのかわりに、アプリケーションで必要な属性を含む補助オブジェクト・クラスを作成します。
この項では、デフォルトのディレクトリ・スキーマについて、およびカスタムの属性とオブジェクト・クラスの作成について説明します。
Directory Serverで提供するスキーマについては、instance-path/config/schema/ディレクトリに格納されている一連のファイルで説明しています。
このディレクトリには、Directory Serverと関連製品の共通スキーマがすべて含まれます。LDAP v3ユーザーおよび組織用の標準スキーマは、00core.ldifファイル内に記述されています。旧バージョンのディレクトリで使用された構成スキーマは、50ns-directory.ldifファイル内に記述されています。オブジェクト・クラスや属性など、ユーザーが作成した要素は、99user.ldifに格納されます。
|
注意: このディレクトリのファイルは変更しないでください。Directory Serverスキーマの管理には、ldapmodifyコマンドを使用してください。 |
LDAPの各オブジェクト・クラスまたは属性には、一意の名前およびオブジェクト識別子(OID)を割り当てる必要があります。スキーマを定義する際は、組織に固有のOIDが必要になります。ユーザーのスキーマに対するニーズをすべて満たすには、1つのOIDで十分となります。属性およびオブジェクト・クラスのそのOIDに新しいブランチを追加します。
OIDの取得およびスキーマでの割当てでは、次の処理を行います。
IANA(Internet Assigned Numbers Authority)または国内の機関から組織のOIDを取得します。
国によっては、企業にすでにOIDが割り当てられています。組織がまだOIDを持っていない場合、IANAよりOIDを取得できます。
OIDの割当てを追跡できるように、OIDレジストリを作成します。
OIDレジストリは、ディレクトリスキーマで使用するOIDとOIDの説明を提供するリストで、作成者が保持します。OIDレジストリにより、OIDが複数の目的で使用されないようにできます。
OIDツリーにスキーマ要素を収容するブランチを作成します。
OIDブランチすなわちディレクトリ・スキーマの下に2つ以上のブランチ(属性用にOID.1、オブジェクト・クラス用にOID.2)を作成します。独自のマッチング・ルールや制御を定義する場合、必要に応じてOID.3などの新しいブランチを追加できます。
新規の属性およびオブジェクト・クラスの名前を作成する場合、スキーマで使用しやすいように、わかりやすい名前を作成します。
カスタム要素に一意の接頭辞を含めることにより、カスタム・スキーマ要素と既存のスキーマ要素の名前の競合を防ぎます。たとえばExample.com社では、各カスタム・スキーマ要素の前に接尾辞Exampleを追加できます。ExamplePersonという特殊オブジェクト・クラスを追加して、ディレクトリ内のExample.comの従業員を識別することもできます。
LDAPでは、属性タイプ名およびオブジェクト・クラス名は大文字と小文字の区別がないことに注意してください。アプリケーションでは、それらを大文字/小文字の区別なしで扱う必要があります。
既存のオブジェクト・クラスでは、ディレクトリ・エントリへ格納する必要のある情報のすべてがサポートされていない場合、新しいオブジェクト・クラスを追加します。
新しいオブジェクト・クラスを作成するには、次の2つの方法があります。
属性を追加する各オブジェクト・クラス構造に1つずつ、多数の新しいオブジェクト・クラスを作成します。
ディレクトリ用に作成する属性をすべてサポートする単一のオブジェクト・クラスを作成します。この種のオブジェクト・クラスは、AUXILIARYオブジェクト・クラスと定義して作成します。
サイトで属性ExampleDepartmentNumberおよびExampleEmergencyPhoneNumberを作成するとします。これらの属性のいくつかのサブセットを許可するオブジェクト・クラスを複数作成できます。ExamplePersonというオブジェクト・クラスを作成して、それがExampleDepartmentNumberおよびExampleEmergencyPhoneNumber属性を許可するようにします。ExamplePersonの親はinetOrgPersonです。ExampleOrganizationというオブジェクト・クラスを作成し、それもExampleDepartmentNumberおよびExampleEmergencyPhoneNumber属性を許可するようにできます。ExampleOrganizationの親はorganizationオブジェクト・クラスです。
新しいオブジェクト・クラスは、次のようにLDAP v3スキーマ・フォーマットで表されます。
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) )
または、これらの属性をすべて許可する単一のオブジェクト・クラスを作成することもできます。これらの属性を使用するエントリで、このオブジェクト・クラスを使用できます。この単一オブジェクト・クラスは、次のように表されます。
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というマークが付けられます。
新しいオブジェクト・クラスの実装方法を決定する際には、次のことを考慮します。
複数のSTRUCTURALオブジェクト・クラスでは、作成および管理するスキーマ要素も増えます。
一般に、要素数を少なく抑えると、メンテナンスの必要性が軽減されます。しかし、スキーマに3つ以上のオブジェクト・クラスを追加する場合は、単一オブジェクト・クラスを使用する方が簡単な場合があります。
複数のSTRUCTURALオブジェクト・クラスでは、より入念かつ厳密にデータ設計をする必要があります。
厳密なデータ設計では、個々のデータが配置されるオブジェクト・クラス構造を考慮する必要があります。この制約は役立つ場合もありますが、煩雑でもあります。
単一のAUXILIARYオブジェクト・クラスでは、複数のタイプのオブジェクト・クラス構造にデータを配置する場合に、データ設計が簡素化されます。
たとえば、個人およびグループの両方のエントリに、preferredOSを置くとします。このような場合、オブジェクト・クラスを1つのみ作成し、この属性を許可するようにできます。
実際のオブジェクトに関連するオブジェクト・クラスと目的に合ったグループ化を構成するグループ要素を設計します。
新しいオブジェクト・クラスには、必須属性を回避します。
属性を必要とすることにより、スキーマに柔軟性がなくなる可能性があります。新しいオブジェクト・クラスを作成する場合は、属性を要求するのではなく許可します。
新しいオブジェクト・クラスを定義したら、オブジェクト・クラスで許可される属性と必要とする属性、および継承するオブジェクト・クラスを決める必要があります。
既存の属性で、ディレクトリ・エントリに格納する必要がある情報のすべてをサポートしていない場合、新しい属性を追加します。可能なかぎり標準の属性を使用するようにします。デフォルトのディレクトリ・スキーマにある属性を検索して、それらの属性を新しいオブジェクト・クラスに関連付けて使用します。
たとえば、person、organizationalPersonまたはinetOrgPersonの各オブジェクト・クラスがサポートしている以外の情報を個人エントリに格納する場合もあります。ディレクトリに誕生日を格納する場合、標準のDirectory Serverスキーマにはそのような属性が存在しません。dateOfBirthという新しい属性を作成することはできます。この属性を許可する新しい補助クラスを定義することで、この属性が人々を表すエントリで使用できるようになります。
この項では、LDAPで属性を作成、表示および削除する方法について説明します。
cn=schemaエントリは複数値属性attributeTypesを持ち、この属性にはディレクトリ・スキーマ内の各属性タイプの定義が含まれています。ldapmodifyコマンドを使用して、これらの定義に追加できます。
新しい属性タイプの定義、およびユーザー定義属性タイプへの変更はファイル99user.ldifに保存されます。
各属性タイプ定義には、新しい属性タイプを定義する1つ以上のOIDを指定する必要があります。新しい属性タイプには、少なくとも次の要素を使用することを考慮してください。
属性OID。属性のオブジェクト識別子に相当します。OIDは通常、ドット区切りの10進数の文字列で、スキーマ・オブジェクトを一意に識別します。
LDAP v3に厳密に準拠するには、有効な数値のOIDを指定する必要があります。OIDについて学ぶには、またはユーザーの企業用に接頭辞を要求するには、IANA (Internet Assigned Number Authority)のiana@iana.org宛に電子メールを送付するか、IANA Webサイト(http://www.iana.org)を参照してください。
属性名。属性の一意の名前に相当します。属性タイプとも呼ばれます。属性名はアルファベットで開始し、ASCII文字、数字およびハイフンのみで構成する必要があります。
属性名は大文字を含めることもできますが、LDAPクライアントでは、大文字/小文字による属性の区別は行われません。属性名は、RFC 4512 (http://www.ietf.org/rfc/rfc4512.txt)の第2.5項に従い、大文字/小文字を区別しないで扱う必要があります。
オプションで、別名とも呼ばれる代替属性名を属性タイプに含めることができます。
属性の説明。属性の目的を説明する短い説明テキストです。
構文。OIDにより参照され、属性により保持されるデータを記述します。
OIDを伴う属性の構文は、RFC 4517 (http://www.ietf.org/rfc/rfc4517.txt)にリストされています。
許容値の数。デフォルトでは、属性は複数値となりますが、単一値に制限することもできます。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
RFC 4517 (http://www.ietf.org/rfc/rfc4517.txt)で指定されている構文に従って、属性タイプ定義を準備します。
ldapmodifyコマンドを使用して、属性タイプ定義を追加します。
Directory Serverにより、X-ORIGIN 'user defined'が指定した定義に追加されます。
例11-1 属性タイプの作成
次の例では、ldapmodifyコマンドを使用して、ディレクトリ文字列構文で新しい属性タイプを追加します。
$ cat blogURL.ldif dn: cn=schema changetype: modify add: attributeTypes attributeTypes: ( 1.2.3.4.5.6.7 NAME ( 'blog' 'blogURL' ) DESC 'URL to a personal weblog' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) $ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - -f blogURL.ldif Enter bind password: modifying entry cn=schema $
本番環境では、1.2.3.4.5.6.7ではなく、有効な一意のOIDを指定します。
cn=schemaエントリは複数値属性attributeTypesを持ち、この属性にはディレクトリ・スキーマ内の各属性タイプの定義が含まれています。ldapsearchコマンドを使用して、これらの定義を読み取ることができます。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
ldapsearchコマンドを使用して、ディレクトリ・スキーマに現在存在するすべての属性タイプ定義を表示します。
例11-2 属性タイプの表示
次のコマンドにより、すべての属性タイプの定義を表示します。
$ ldapsearch -T -b cn=schema "(objectclass=*)" attributeTypes
-Tオプションにより、ldapsearchコマンドはLDIF行を折りたたまないため、grepまたはsedなどのコマンドを使用して出力の操作をより容易にできます。さらに、grepコマンドにより、コマンドの出力をパイプすると、ディレクトリ・スキーマのユーザー定義の拡張のみを表示できます。次に例を示します。
$ ldapsearch -T -b cn=schema "(objectclass=*)" attributeTypes | grep "user defined" attributeTypes: ( 1.2.3.4.5.6.7 NAME ( 'blog' 'blogURL' ) DESC 'URL to a personal weblog' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'user defined' )
cn=schemaエントリは複数値属性attributeTypesを持ち、この属性にはディレクトリ・スキーマ内の各属性タイプの定義が含まれています。ldapmodifyコマンドを使用して、X-ORIGIN 'user defined'を含む定義を削除できます。
スキーマは、cn=schemaのLDAPビューにより定義されるので、ldapsearchおよびldapmodifyユーティリティを使用してオンラインでスキーマを表示および変更できます。ただし、X-ORIGINフィールドに値'user defined'があるスキーマ要素しか削除できません。サーバーでは、その他の定義を削除しません。
ユーザー定義属性の変更は、ファイル99user.ldifに保存されます。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
削除する属性タイプの定義を表示します。
詳細は、「属性タイプを表示するには:」を参照してください。
ldapmodifyコマンドを使用して、スキーマに表示される属性タイプ定義を削除します。
例11-3 属性タイプの削除
次のコマンドで、例11-1で作成した属性タイプを削除します。
$ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: cn=schema changetype: delete delete: attributeTypes attributeTypes: ( 1.2.3.4.5.6.7 NAME ( 'blog' 'blogURL' ) DESC 'URL to a personal weblog' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'user defined' ) ^D
X-ORIGIN 'user defined'を含める必要があることに注意してください。これは、このスキーマ定義を拡張として分類するために、Directory Serverにより追加されたものです。
この項では、LDAPでオブジェクト・クラスを作成、表示および削除する方法について説明します。
cn=schemaエントリは複数値属性objectClassesを持ち、この属性にはディレクトリ・スキーマ内の各オブジェクト・クラスの定義が含まれています。ldapmodifyコマンドを使用して、これらの定義に追加できます。
新しいオブジェクト・クラスの定義、およびユーザー定義オブジェクト・クラスへの変更はファイル99user.ldifに保存されます。
他のオブジェクト・クラスから継承されるオブジェクト・クラスをいくつか作成する場合、まず親のオブジェクト・クラスを作成する必要があります。新しいオブジェクト・クラスがカスタム属性を使用する場合は、まずその属性を定義する必要があります。
各オブジェクト・クラス定義には、少なくとも1つのOIDを指定する必要があります。新しいオブジェクト・クラスには、少なくとも次の要素を使用することを考慮してください。
オブジェクト・クラスOID。オブジェクト・クラスのオブジェクト識別子に相当します。OIDは通常、ドット区切りの10進数の文字列で、スキーマ・オブジェクトを一意に識別します。
LDAP v3に厳密に準拠するには、有効な数値のOIDを指定する必要があります。OIDについて学ぶには、またはユーザーの企業用に接頭辞を要求するには、IANA (Internet Assigned Number Authority)のiana@iana.org宛に電子メールを送付するか、IANA Webサイト(http://www.iana.org)を参照してください。
オブジェクト・クラス名。オブジェクト・クラスの一意の名前に相当します。
親オブジェクト・クラス。このオブジェクト・クラスが属性を継承する既存のオブジェクト・クラスです。
このオブジェクト・クラスを他の特定のオブジェクト・クラスから継承させない場合は、topを使用します。
一般に、ユーザー・エントリに新しい属性を追加する場合、親はinetOrgPersonオブジェクト・クラスとなります。企業エントリに新しい属性を追加する場合、通常、親はorganizationまたはorganizationalUnitとなります。グループ・エントリに新しい属性を追加する場合、通常、親はgroupOfNamesまたはgroupOfUniqueNamesとなります。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
RFC 4517 (http://www.ietf.org/rfc/rfc4517.txt)で指定されている構文に従って、オブジェクト・クラスの定義を準備します。
ldapmodifyコマンドを使用して、オブジェクト・クラスの定義を追加します。
Directory Serverにより、X-ORIGIN 'user defined'が指定した定義に追加されます。
例11-4 オブジェクト・クラスの作成
次の例では、ldapmodifyコマンドを使用して、新しいオブジェクト・クラスを追加します。
$ cat blogger.ldif dn: cn=schema changetype: modify add: objectClasses objectClasses: ( 1.2.3.4.5.6.8 NAME 'blogger' DESC 'Someone who has a blog' SUP inetOrgPerson STRUCTURAL MAY blog ) $ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - -f blogger.ldif Enter bind password: modifying entry cn=schema $
本番環境では、1.2.3.4.5.6.8ではなく、有効な一意のOIDを指定します。
cn=schemaエントリは複数値属性objectClassesを持ち、この属性にはディレクトリ・スキーマ内の各オブジェクト・クラスの定義が含まれています。ldapsearchコマンドを使用して、これらの定義を読み取ることができます。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
ldapsearchコマンドを使用して、ディレクトリ・スキーマに現在存在するオブジェクト・クラスの定義をすべて表示します。
例11-5 オブジェクト・クラスの表示
次のコマンドにより、すべてのオブジェクト・クラスの定義を表示します。
$ ldapsearch -T -b cn=schema "(objectclass=*)" objectClasses
-Tオプションにより、ldapsearchコマンドはLDIF行を折りたたまないため、grepまたはsedなどのコマンドを使用して出力の操作をより容易にできます。さらに、grepコマンドにより、コマンドの出力をパイプすると、ディレクトリ・スキーマのユーザー定義の拡張のみを表示できます。次に例を示します。
$ ldapsearch -T -b cn=schema "(objectclass=*)" objectClasses | grep "user defined" objectClasses: ( 1.2.3.4.5.6.8 NAME 'blogger' DESC 'Someone who has a blog' STRUCTURAL MAY blog X-ORIGIN 'user defined' ) $
cn=schemaエントリは複数値属性objectClassesを持ち、この属性にはディレクトリ・スキーマ内の各オブジェクト・クラスの定義が含まれています。ldapmodifyコマンドを使用して、X-ORIGIN 'user defined'を含む定義を削除できます。
スキーマは、cn=schemaのLDAPビューにより定義されるので、ldapsearchおよびldapmodifyユーティリティを使用してオンラインでスキーマを表示および変更できます。ただし、X-ORIGINフィールドに値'user defined'があるスキーマ要素しか削除できません。サーバーでは、その他の定義を削除しません。
ユーザー定義要素への変更は、ファイル99user.ldifに保存されます。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
削除するオブジェクト・クラスの定義を表示します。
詳細は、「オブジェクト・クラスを表示するには:」を参照してください。
ldapmodifyコマンドを使用して、スキーマに表示されるオブジェクト・クラス定義を削除します。
例11-6 オブジェクト・クラスの削除
次のコマンドで、例11-4で作成したオブジェクト・クラスを削除します。
$ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: cn=schema changetype: delete delete: objectClasses objectClasses: ( 1.2.3.4.5.6.8 NAME 'blogger' DESC 'Someone who has a blog' STRUCTURAL MAY blog X-ORIGIN 'user defined' ) ^D
X-ORIGIN 'user defined'を含める必要があることに注意してください。これは、このスキーマ定義を拡張として分類するために、Directory Serverにより追加されたものです。
2つのサーバー間で、1つ以上の接尾辞のレプリケーションを構成するたびに、スキーマ定義も自動的にレプリケートされます。スキーマ定義の自動レプリケーションにより、すべてのレプリカが、コンシューマにレプリケート可能なすべてのオブジェクト・クラスと属性を定義する完全な同一のスキーマになります。したがって、マスター・サーバーにもマスター・スキーマが含まれます。
しかし、LDAPでスキーマを変更した場合でも、スキーマのレプリケーションは瞬時に行われるわけではありません。スキーマ・レプリケーションでは、ディレクトリ・データの更新によって、またはスキーマ変更後の最初のレプリケーション・セッションの開始時にトリガーされます。
すべてのレプリカにスキーマを適用するには、少なくともすべてのマスターでスキーマ・チェックを有効にする必要があります。スキーマはLDAP操作を実行するマスターでチェックされるので、コンシューマの更新時にはチェックする必要はありません。パフォーマンスを向上させるため、レプリケーション・メカニズムでは、コンシューマ・レプリカでのスキーマ・チェックを行いません。
|
注意: ハブおよび専用コンシューマではスキーマ・チェックをオフにしないでください。スキーマ・チェックがコンシューマのパフォーマンスに影響することはありません。スキーマ・チェックをオンに保ち、レプリカの内容がスキーマと一致するようにします。 |
コンシューマの初期化時に、マスター・サーバーはスキーマをコンシューマに自動的にレプリケートします。さらに、DSCCまたはコマンドライン・ツールから、スキーマが変更された場合にも、マスター・サーバーは自動的にスキーマをレプリケートします。デフォルトで、スキーマ全体がレプリケートされます。コンシューマにまだ存在していない追加スキーマ要素は、コンシューマで作成され、99user.ldifファイルに格納されます。
たとえば、マスター・サーバーの起動時に、そのサーバーの98mySchema.ldifファイルにスキーマ定義が含まれているとします。さらに、他のサーバー(マスター、ハブまたは専用コンシューマ)とのレプリケーション承諾を定義するとします。続いて、このマスターからレプリカを初期化すると、レプリケートされたスキーマには98mySchema.ldifの定義が含まれますが、この定義はレプリカ・サーバーの99user.ldifに格納されます。
コンシューマの初期化時に、スキーマがレプリケートされた後で、マスター側のcn=schemaでスキーマを変更すると、スキーマ全体がコンシューマにもレプリケートされます。したがって、コマンドライン・ユーティリティまたはDSCCからマスター・スキーマに加えた変更は、コンシューマにレプリケートされます。これらの変更はマスターの99user.ldifに格納され、前述のものと同じメカニズムにより、コンシューマの99user.ldifにも格納されます。
レプリケーション環境でスキーマの一貫性を維持するために、次のガイドラインを考慮してください。
コンシューマ・サーバーのスキーマを変更しないでください。
コンシューマのスキーマを変更すると、レプリケーション・エラーが発生する可能性があります。これは、コンシューマのスキーマ内の差分により、サプライヤからの更新がコンシューマのスキーマに一致しなくなる可能性があるためです。
マルチマスター・レプリケーション環境では、1つのマスター・サーバーでスキーマを変更します。
2つのマスター・サーバーのスキーマを変更すると、最後に更新されたマスターがそのスキーマをコンシューマに伝播します。すると、コンシューマのスキーマが他のマスターのスキーマと一致しなくなる可能性があります。
部分レプリケーションを構成する場合は、次のガイドラインも考慮してください。
部分レプリケーションの構成では、スキーマはサプライヤによってプッシュされるので、部分コンシューマ・レプリカのスキーマはマスター・レプリカのスキーマのコピーとなります。したがって、スキーマが適用される部分レプリケーションの構成と対応しなくなる可能性があります。
一般に、Directory Serverでは、スキーマ違反を回避するため、スキーマに定義されている各エントリのすべての必須属性がレプリケートされます。必須属性を除外するよう部分レプリケーションを構成する場合、スキーマ・チェックを無効にする必要があります。
部分レプリケーションでスキーマ・チェックが有効になっている場合、オフラインでレプリカを初期化できないことがあります。必須属性がフィルタで除外された場合、Directory ServerではLDIFからデータをロードできなくなります。
部分コンシューマ・レプリカでスキーマ・チェックを無効にした場合、その部分コンシューマ・レプリカのあるサーバー・インスタンス全体でスキーマ・チェックが行われなくなります。このため、部分コンシューマと同じサーバー・インスタンスでサプライヤ・レプリカを構成することは避けてください。
デフォルトでは、レプリケーション・メカニズムによってスキーマがレプリケートされるたびに、スキーマ全体がコンシューマに送信されます。次の状況では、スキーマ全体をコンシューマに送信することは好ましくありません。
DSCCまたはコマンドラインからのcn=schemaに対する変更は、ユーザー定義のスキーマ要素に限定され、標準スキーマは一切変更されません。頻繁にスキーマを変更する場合、変更されていない大規模なスキーマ要素セットを毎回送信することはパフォーマンスに影響を及ぼします。ユーザー定義のスキーマ要素のみをレプリケートすることで、レプリケーションおよびサーバーのパフォーマンスを向上できる場合もあります。
このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。
ユーザー定義のスキーマのみをレプリケートするように、スキーマのレプリケーションを制限します。
$ dsconf set-server-prop -h host -p port repl-user-schema-enabled:on
必要な場合は、デフォルト値のoffにより、スキーマ全体をレプリケートします。
