test

Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド

第 12 章 Directory Server のスキーマ

Directory Server には、数多くのオブジェクトクラスおよび属性を持つ標準のスキーマが付属しています。通常の作業では標準のオブジェクトクラスと属性で十分ですが、新しいオブジェクトクラスや属性の作成など、スキーマの拡張が必要となることもあります。標準スキーマの概要と配備に適合するスキーマの設計手順については、『Sun Java System Directory Server Enterprise Edition 6.3 配備計画ガイド』を参照してください。

この章では、スキーマを管理する方法について説明します。次の内容について説明します。

スキーマ検査の管理

スキーマ検査を有効にすると、インポート、追加、変更のすべての処理が Directory Server によって、次のように現在定義されているディレクトリスキーマに準拠するようになります。

注 –

エントリを変更する場合、Directory Server は、変更する属性だけでなく、エントリ全体に対してスキーマ検査を実行します。このため、エントリのいずれかのオブジェクトクラスまたは属性がスキーマに準拠していない場合、変更処理は失敗します。

ただし、スキーマ検査では構文に関する属性値の有効性は検証されません。

スキーマ検査はデフォルトで有効にされています。一般に、スキーマ検査を有効にして、Directory Server を実行します。多くのクライアントアプリケーションでは、スキーマ検査を有効にしておくことは、すべてのエントリがスキーマに準拠しているものと見なされます。ただし、スキーマ検査を有効にしても、Directory Server はディレクトリの既存の内容を確認しません。ディレクトリのすべての内容がスキーマに確実に準拠するようにするには、エントリを追加する前、またはすべてのエントリを再初期化する前にスキーマ検査を有効にする以外に方法はありません。

スキーマ検査を無効にするのは、スキーマに準拠していることが確実な LDIF ファイルのインポートを高速で処理するときだけです。ただし、スキーマに準拠しないエントリのインポートにはリスクがあります。スキーマ検査が無効にされている場合、スキーマに準拠しないインポートされたエントリが検出されません。

レプリケートされた環境でのスキーマ検査の使用の詳細については、「ディレクトリスキーマのレプリケート」を参照してください。

Procedureスキーマの準拠の問題を修正する

エントリがスキーマに準拠していない場合は、このエントリを検索することができず、エントリに対する変更処理も失敗することがあります。次の手順に従って、問題を修正します。

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

始める前に

スキーマの準拠の問題を修正する必要性を避けるため、配備の前にスキーマを計画し、スキーマの変更を最小にします。詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 配備計画ガイド』を参照してください。

  1. エントリが準拠しない理由を判断するには、エントリを取得し、それを現在定義されているスキーマと手動で比較します。

    詳細については、「属性タイプを表示する」および 「オブジェクトクラスを表示する」を参照してください。

  2. スキーマに準拠するようにエントリを変更するか、エントリに準拠するようにスキーマを変更します。

カスタムスキーマについて

ディレクトリのニーズに対して、標準スキーマでは著しく制限される場合に、標準スキーマを拡張できます。スキーマをカスタマイズする場合は、次のガイドラインに従います。

スキーマをカスタマイズする場合は、標準スキーマの属性またはオブジェクトクラスの既存の定義の変更、削除、および置換は行わないでください。標準スキーマを修正すると、ほかのディレクトリや LDAP クライアントアプリケーションとの互換性に問題が生じます。

Directory Server 内部オペレーショナル属性は変更しないでください。ただし、外部アプリケーション用に独自のオペレーショナル変数を作成できます。

objectClass: extensibleObject を使用する代わりに、常にオブジェクトクラスを定義します。Directory Server は、オブジェクトクラス extensibleObject があるエントリのスキーマ検査を実行しないため、エントリに存在する属性を制限したり、検査したりしません。アプリケーションでのタイプミス、たとえば givenName 属性タイプを giveName と間違えた場合も、Directory Server はその間違いに気づきません。また、Directory Server は、extensibleObject エントリの中で未定義の属性は、複数値属性で、大文字小文字に関係ない文字列構文を持つことを前提とします。さらに、特定のオブジェクトクラスを持つエントリに依存するアプリケーションもあります。一般に、オブジェクトクラスへの拡張を必要とするアプリケーションがある場合は、スキーマ管理を放棄しないでください。代わりに、アプリケーションに必要な属性を含む補助のオブジェクトクラスを作成します。

この節では、デフォルトのディレクトリスキーマについてと、カスタマイズした属性とオブジェクトクラスの作成について説明します。

デフォルトの Directory Server スキーマ

Directory Server で提供されるスキーマは、instance-path /config/schema/ ディレクトリに保存されているファイルのセットに記述されています。

このディレクトリには、Directory Server の一般的なすべてのスキーマと関連製品が格納されています。LDAP v3 標準のユーザースキーマと組織スキーマは、00core.ldif ファイルに記述されています。旧バージョンのディレクトリで使用された設定スキーマは、50ns-directory.ldif ファイルに記述されています。

注 –

サーバーの稼動中は、このディレクトリ内のファイルを変更しないでください。

オブジェクト識別子

各 LDAP オブジェクトクラスまたは属性には、一意の名前とオブジェクト識別子 (OID) が割り当てられている必要があります。スキーマを定義するときは、組織に固有の OID が必要です。1 つの OID ですべてのスキーマ要件に対応できます。属性とオブジェクトクラスのその OID に新しいエントリを追加します。

OID の取得とスキーマでの割り当ては、次の手順で行います。

属性とオブジェクトクラスの命名

新しい属性とオブジェクトクラスの名前を作成する場合、スキーマで使いやすいように、わかりやすい名前を作成します。

作成する要素に固有の接頭辞を付けて、作成したスキーマ要素と既存のスキーマ要素間での名前の衝突を防ぎます。たとえば、Example.com 社では、各カスタムスキーマ要素の前に Example という接頭辞を追加します。また、ディレクトリ内の Example.com 社員を識別するために ExamplePerson という特別なオブジェクトクラスを追加します。

LDAP では、属性タイプ名とオブジェクトクラス名は、大文字と小文字が区別されません。アプリケーションでは、それらを大文字と小文字を区別しない文字列として扱う必要があります。

新しいオブジェクトクラスを定義する場合

ディレクトリのエントリに格納する必要がある情報の中に既存のオブジェクトクラスがサポートしていないものがある場合は、新しいオブジェクトクラスを追加します。

新しいオブジェクトクラスを作成するには、次の 2 つの方法があります。

新しいオブジェクトクラスを実装する方法を決めるときは、次の点に留意します。

新しい属性を定義する場合

ディレクトリのエントリに格納する必要がある情報の中に既存の属性がサポートしていないものがある場合は、新しい属性を追加します。できるかぎり、標準属性を使用するようにします。デフォルトのディレクトリスキーマにある属性を探し、それらを新しいオブジェクトクラスに関連付けて使用します。

たとえば、person、organizationalPerson、または inetOrgPerson の各オブジェクトクラスがサポートしている以外の情報を、個人のエントリに格納したい場合があります。ディレクトリに生年月日を格納する場合、Directory Server の標準スキーマには対応する属性がありません。 dateOfBirth という新しい属性を作成できます。この属性を許可する新しい補助クラスを定義して、この属性をエントリで使用できるようにします。

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

カスタムスキーマファイルを作成するとき、特にレプリケーションを使用する場合は、次の点に注意する必要があります。

LDAP 経由での属性タイプの管理

この節では、LDAP 経由で属性タイプを作成、表示、および削除する方法を説明します。

属性タイプの作成

cn=schema エントリは複数の値を持つ属性 attributeTypes があり、ディレクトリスキーマの各属性タイプの定義を格納します。それらの定義は ldapmodify(1) コマンドを使用して追加できます。

新しい属性タイプの定義とユーザー定義属性タイプの変更は、99user.ldif ファイルに保存されます。

各属性タイプ定義には、新しい属性タイプを定義する 1 つ以上の OID を指定する必要があります。新しい属性タイプには、少なくとも次の要素を使用することを考慮してください。

Procedure属性タイプを作成する

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

  1. RFC 4517 に指定された構文に従って、属性タイプ定義を準備します。

  2. ldapmodify(1) コマンドを使用して、属性タイプ定義を追加します。

    Directory Server によって、指定した定義に X-ORIGIN 'user defined' が追加されます。

例 12–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(1) コマンドを使用して読み取ることができます。

Procedure属性タイプを表示する

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

  1. ディレクトリスキーマに現在存在するすべての属性タイプ定義を表示するには、ldapsearch コマンドを使用します。

例 12–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 があり、ディレクトリスキーマの各属性タイプの定義を格納します。X-ORIGIN 'user defined' を含む定義を削除するには、ldapmodify(1) コマンドを使用します。

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

ユーザー定義属性の変更は、ファイル 99user.ldif に保存されます。

Procedure属性タイプを削除する

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

  1. 削除する属性タイプの定義を表示します。

    詳細については、「属性タイプを表示する」を参照してください。

  2. ldapmodify(1) コマンドを使用して、スキーマに表示される属性タイプ定義を削除します。

例 12–3 属性タイプの削除

次のコマンドは、例 12–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

Directory Server によって追加された X-ORIGIN 'user defined' を含めて、このスキーマ定義を拡張として分類する必要があります。

LDAP 経由でのオブジェクトクラスの管理

この節では、LDAP 経由で、オブジェクトクラスを作成、表示、および削除する方法を説明します。

オブジェクトクラスの作成

cn=schema エントリには、ディレクトリスキーマの各オブジェクトクラスの定義を格納し、複数の値を持つ属性 objectClasses があります。それらの定義は ldapmodify(1) コマンドを使用して追加できます。

新しいオブジェクトクラス定義とユーザー定義オブジェクトクラスへの変更は 99user.ldif ファイルに保存されます。

ほかのオブジェクトクラスから継承する複数のオブジェクトクラスを作成するときは、最初に親オブジェクトクラスを作成する必要があります。新しいオブジェクトクラスがカスタム属性を使用するときは、その属性も事前に定義しておく必要があります。

各オブジェクトクラス定義に、1 つ以上の OID を指定する必要があります。新しいオブジェクトクラスには少なくとも次の要素を使用することを考慮してください。

Procedureオブジェクトクラスを作成する

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

  1. RFC 4517 に指定された構文に従って、オブジェクトクラス定義を準備します。

  2. ldapmodify(1) コマンドを使用して、オブジェクトクラス定義を追加します。

    Directory Server によって、指定した定義に X-ORIGIN 'user defined' が追加されます。

例 12–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(1) コマンドを使用して読み取ることができます。

Procedureオブジェクトクラスを表示する

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

  1. ldapsearch コマンドを使用して、ディレクトリスキーマに現在存在するすべてのオブジェクトクラス定義を表示します。

例 12–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 があります。X-ORIGIN 'user defined' を含む定義を削除するには、ldapmodify(1) コマンドを使用します。

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

ユーザー定義の要素の変更は、 99user.ldif ファイルに保存されます。

Procedureオブジェクトクラスを削除する

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

  1. 削除するオブジェクトクラス定義を表示します。

    詳細については、「オブジェクトクラスを表示する」を参照してください。

  2. ldapmodify(1) コマンドを使用して、スキーマに表示されるオブジェクトクラス定義を削除します。

例 12–6 オブジェクトクラスの削除

次のコマンドは、例 12–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

Directory Server によって追加された X-ORIGIN 'user defined' を含めて、このスキーマ定義を拡張として分類する必要があります。

Directory Server スキーマの拡張

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

Directory Server と既存の LDAP クライアントとの相互運用性は、標準の LDAP スキーマに依存しています。標準スキーマを変更すると、サーバーのアップグレード時にも問題が発生します。同様の理由から、標準スキーマの要素を削除することはできません。

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

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

表 12–1 スキーマの拡張方法

作業 

参照先 

レプリケーションを使用しない。カスタムスキーマファイルを追加して、スキーマを拡張する。 

「カスタムスキーマファイルによってスキーマを拡張する」

LDAP を経由してスキーマを拡張する。 

「LDAP によりスキーマを拡張する」

レプリケーションを使用する。すべてのサーバーでカスタムスキーマファイルのファイル名を維持する。 

「カスタムスキーマファイルによってスキーマを拡張する」

レプリケーションを使用する。マスターレプリカにカスタムスキーマファイルを追加して、スキーマを拡張する。次に、レプリケーションメカニズムによって、そのスキーマ拡張をコンシューマサーバーにコピーする。 

「スキーマファイルとレプリケーションを使用してスキーマを拡張する」

オブジェクトクラス、属性、ディレクトリスキーマの詳細と、スキーマの拡張のガイドラインについては、『Sun Java System Directory Server Enterprise Edition 6.3 配備計画ガイド』の「ディレクトリスキーマの設計」を参照してください。標準属性およびオブジェクトクラスについては、『Sun Java System Directory Server Enterprise Edition 6.3 Man Page Reference』を参照してください。

この節では、ディレクトリスキーマを拡張する様々な方法を説明します。

カスタムスキーマファイルによるスキーマの拡張

スキーマファイルは LDIF ファイルで instance-path /config/schema/ にあります。instance-path は、Directory Server インスタンスが存在するファイルシステムディレクトリに対応します。たとえば、インスタンスは /local/ds/ などにあります。このファイルは Directory Server と Directory Server に依存するすべてのサーバーが使用する標準スキーマを定義します。ファイルと標準スキーマについては、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』と『Sun Java System Directory Server Enterprise Edition 6.3 Man Page Reference』に説明しています。

サーバーは、起動時に 1 回だけスキーマファイルを読み取ります。スキーマのメモリー内の LDAP ビューの cn=schema 内にファイルの LDIF の内容が追加されます。スキーマ定義の順序には意味があるため、スキーマファイルの名前の先頭には番号がつけられ、英数字順に読み込まれます。このディレクトリに含まれるスキーマファイルには、インストール時に定義されたシステムユーザーだけが書き込み処理を実行できます。

スキーマを LDIF ファイルに直接定義するときは、X-ORIGIN フィールドの値として 'user defined' を指定することはできません。この値は、cn=schema の LDAP ビューで定義されるスキーマ要素用に予約されており、これは 99user.ldif ファイルに表示されます。

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

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

Procedureカスタムスキーマファイルによってスキーマを拡張する

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

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

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

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

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

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

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

LDAP によるスキーマの拡張

スキーマは cn=schema 内の LDAP ビューによって定義されるため、ldapsearch ユーティリティーおよび ldapmodify ユーティリティーを使用してスキーマをオンラインで表示、変更することができます。しかし、変更できるスキーマ要素は、X-ORIGIN フィールドに 'user defined' という値が設定されている要素だけです。サーバーは、その他の定義に対するすべての変更処理を拒否します。

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

ProcedureLDAP によりスキーマを拡張する

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

始める前に

コマンド行からのスキーマ定義の変更は、正確な入力が必要な値が長いため、エラーを生じがちです。しかし、ディレクトリスキーマの更新が必要なスクリプトにこの機能を指定することができます。

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

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

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

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

参照

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

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

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

Procedureスキーマファイルとレプリケーションを使用してスキーマを拡張する

この手順のいくつかの部分では、DSCC を使用してこのタスクを実行できます。詳細については、「Directory Service Control Center のインタフェース」 および DSCC オンラインヘルプを参照してください。手順のその他の部分については、コマンド行を使用した場合にのみ実効できます。

  1. 次のいずれかの方法で、スキーマ拡張を準備します。

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

    • 99user.ldif にスキーマ拡張を追加します。

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

  2. スキーマ定義ファイルを配置するマスターサーバーで、schema_push コマンドを実行します。

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

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

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

ディレクトリスキーマのレプリケート

2 つのサーバーの間で 1 つまたは複数のサフィックスのレプリケーションを設定するたびに、スキーマ定義も自動的にレプリケートされます。スキーマ定義の自動レプリケーションにより、すべてのレプリカが、コンシューマにレプリケート可能なすべてのオブジェクトクラスと属性を定義する完全な同一のスキーマになります。マスターサーバーもマスタースキーマを格納します。

ただし、スキーマレプリケーションは、LDAP を経由してスキーマを変更した場合でも、即時に実行されません。スキーマレプリケーションは、ディレクトリデータの更新によって、またはスキーマ変更後の最初のレプリケーションセッションの開始時にトリガーされます。

すべてのレプリカにスキーマを適用するには、少なくともすべてのマスターでスキーマ検査を有効にする必要があります。スキーマは、LDAP 処理が行われるマスターでチェックされるため、コンシューマの更新時はチェックの必要はありません。パフォーマンスを向上させるために、レプリケーションメカニズムではコンシューマレプリカでのスキーマ検査を行いません。

注 –

ハブと専用コンシューマでは、スキーマ検査を無効にしないでください。スキーマ検査は、コンシューマのパフォーマンスに影響を与えません。スキーマ検査は常に有効にして、レプリカの内容がそのスキーマと一致するようにします。

コンシューマの初期化時に、マスターサーバーはスキーマをコンシューマに自動的にレプリケートします。さらに、DSCC またはコマンド行ツールから、スキーマが変更された場合にも、マスターサーバーは自動的にスキーマをレプリケートします。デフォルトで、スキーマ全体がレプリケートされます。コンシューマに存在していない追加のスキーマ要素は、コンシューマで作成され、99user.ldif ファイルに保存されます。

たとえば、マスターサーバーの起動時に、サーバーの 98mySchema.ldif ファイルにスキーマ定義が含まれているとします。さらに、ほかのサーバー、マスター、ハブ、または専用コンシューマのいずれかに対するレプリケーションアグリーメントを定義するとします。このマスターからレプリカを初期化すると、レプリケートされたスキーマには 98mySchema.ldif からの定義が含まれますが、レプリカサーバー側の 99user.ldif にもこの定義が格納されます。

コンシューマの初期化時にスキーマがレプリケートされたあとで、マスター側の cn=schema でスキーマを変更すると、マスターはスキーマ全体をコンシューマにもレプリケートします。このように、コマンド行ユーティリティーまたは DSCC からマスタースキーマに加えた変更は、コンシューマにレプリケートされます。これらの変更はマスターの 99user.ldif に保存され、先述した同じメカニズムによって、変更がコンシューマの 99user.ldif にも保存されます。

レプリケート環境で整合性のあるスキーマを維持するには、次のガイドラインに留意します。

部分レプリケーションを設定する場合は、次のガイドラインにも留意します。

スキーマレプリケーションの制限

デフォルトでは、レプリケーションメカニズムによってスキーマがレプリケートされるたびに、スキーマ全体がコンシューマに送信されます。スキーマ全体をコンシューマに送信することが望ましくない状況は 2 つあります。

注 –

Directory Server は 11rfc2307.ldif スキーマファイルを使用します。このスキーマファイルは、RFC 2307 に準拠しています。

Directory Server 5.2 より前の Directory Server のバージョンでは 10rfc2307.ldif スキーマファイルを使用します。

Procedureスキーマレプリケーションを制限する

DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。

  1. ユーザー定義のスキーマのみがレプリケートされるように、スキーマレプリケーションを制限します。


    $ dsconf set-server-prop -h host -p port repl-user-schema-enabled:on

    デフォルト値の off を使うことで、必要に応じてスキーマ全体をレプリケートできます。