Directory Server には、数多くのオブジェクトクラスおよび属性を持つ標準のスキーマが付属しています。通常の作業では標準のオブジェクトクラスと属性で十分ですが、新しいオブジェクトクラスや属性の作成など、スキーマの拡張が必要となることもあります。標準スキーマの概要と配備に適合するスキーマの設計手順については、『Sun Java System Directory Server Enterprise Edition 6.3 配備計画ガイド』を参照してください。
この章では、スキーマを管理する方法について説明します。次の内容について説明します。
スキーマ検査を有効にすると、インポート、追加、変更のすべての処理が Directory Server によって、次のように現在定義されているディレクトリスキーマに準拠するようになります。
各エントリのオブジェクトクラスと属性は、スキーマに準拠する。
エントリには、そのエントリに定義されているすべてのオブジェクトクラスに必要なすべての属性が含まれる。
エントリには、そのエントリのオブジェクトクラスに許可されている属性だけが含まれる。
エントリを変更する場合、Directory Server は、変更する属性だけでなく、エントリ全体に対してスキーマ検査を実行します。このため、エントリのいずれかのオブジェクトクラスまたは属性がスキーマに準拠していない場合、変更処理は失敗します。
ただし、スキーマ検査では構文に関する属性値の有効性は検証されません。
スキーマ検査はデフォルトで有効にされています。一般に、スキーマ検査を有効にして、Directory Server を実行します。多くのクライアントアプリケーションでは、スキーマ検査を有効にしておくことは、すべてのエントリがスキーマに準拠しているものと見なされます。ただし、スキーマ検査を有効にしても、Directory Server はディレクトリの既存の内容を確認しません。ディレクトリのすべての内容がスキーマに確実に準拠するようにするには、エントリを追加する前、またはすべてのエントリを再初期化する前にスキーマ検査を有効にする以外に方法はありません。
スキーマ検査を無効にするのは、スキーマに準拠していることが確実な LDIF ファイルのインポートを高速で処理するときだけです。ただし、スキーマに準拠しないエントリのインポートにはリスクがあります。スキーマ検査が無効にされている場合、スキーマに準拠しないインポートされたエントリが検出されません。
レプリケートされた環境でのスキーマ検査の使用の詳細については、「ディレクトリスキーマのレプリケート」を参照してください。
エントリがスキーマに準拠していない場合は、このエントリを検索することができず、エントリに対する変更処理も失敗することがあります。次の手順に従って、問題を修正します。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
スキーマの準拠の問題を修正する必要性を避けるため、配備の前にスキーマを計画し、スキーマの変更を最小にします。詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 配備計画ガイド』を参照してください。
エントリが準拠しない理由を判断するには、エントリを取得し、それを現在定義されているスキーマと手動で比較します。
詳細については、「属性タイプを表示する」および 「オブジェクトクラスを表示する」を参照してください。
スキーマに準拠するようにエントリを変更するか、エントリに準拠するようにスキーマを変更します。
ディレクトリのニーズに対して、標準スキーマでは著しく制限される場合に、標準スキーマを拡張できます。スキーマをカスタマイズする場合は、次のガイドラインに従います。
できるかぎり既存のスキーマ要素を再利用する。
各オブジェクトクラスに定義する必須の属性の数を最小限にする。
同じ目的で複数のオブジェクトクラスまたは属性を定義しない。
できるかぎりスキーマを簡潔にする。
スキーマをカスタマイズする場合は、標準スキーマの属性またはオブジェクトクラスの既存の定義の変更、削除、および置換は行わないでください。標準スキーマを修正すると、ほかのディレクトリや 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 ファイルに記述されています。
サーバーの稼動中は、このディレクトリ内のファイルを変更しないでください。
各 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 つのエントリ (1 つは属性用の OID.1、もう 1 つはオブジェクトクラス用の OID.2) を作成します。独自のマッチングルールや制御を定義する場合は、必要に応じて OID.3 などの新しいエントリを追加できます。
新しい属性とオブジェクトクラスの名前を作成する場合、スキーマで使いやすいように、わかりやすい名前を作成します。
作成する要素に固有の接頭辞を付けて、作成したスキーマ要素と既存のスキーマ要素間での名前の衝突を防ぎます。たとえば、Example.com 社では、各カスタムスキーマ要素の前に Example という接頭辞を追加します。また、ディレクトリ内の Example.com 社員を識別するために ExamplePerson という特別なオブジェクトクラスを追加します。
LDAP では、属性タイプ名とオブジェクトクラス名は、大文字と小文字が区別されません。アプリケーションでは、それらを大文字と小文字を区別しない文字列として扱う必要があります。
ディレクトリのエントリに格納する必要がある情報の中に既存のオブジェクトクラスがサポートしていないものがある場合は、新しいオブジェクトクラスを追加します。
新しいオブジェクトクラスを作成するには、次の 2 つの方法があります。
属性を追加するオブジェクトクラス構造ごとに 1 つずつ、多数の新しいオブジェクトクラスを作成する。
ディレクトリ用に作成するすべての属性を含む 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) )
または、これらのすべての属性を許可する 1 つのオブジェクトクラスを作成することができます。属性を使う必要があるエントリで、そのオブジェクトクラスを使用できます。 1 つのオブジェクトクラスは、次のようになります。
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 オブジェクトクラスを作成すると、作成および管理するスキーマ要素の数も増える。
一般に、要素の数が少なければ、管理の手間も少なくて済みます。スキーマに複数のオブジェクトクラスを追加することを計画している場合は、1 つのオブジェクトクラスにまとめた方が簡単な場合があります。
複数の STRUCTURAL オブジェクトクラスを作成する場合は、より厳密かつ注意深いデータ設計が必要となる。
データを厳密に設計するには、個々のデータを配置するオブジェクトクラス構造を考慮する必要があります。この制限は役立つ場合とわずらわしい場合があります。
複数のタイプのオブジェクトクラス構造に入れたいデータがある場合は、1 つの AUXILIARY オブジェクトクラスを使用した方がデータ設計が簡単になる。
たとえば、preferredOS 属性を人のエントリとグループエントリの両方に設定するとします。このような場合は、1 つのオブジェクトクラスを作成して、そのクラスでこの属性が許可されるようにします。
目的に合ったグループを構成する実際のオブジェクトとグループ要素に関連するオブジェクトクラスを設計する。
新しいオブジェクトクラスに必須の属性を設定しない。
必須の属性を設定するとスキーマに柔軟性がなくなります。新しいオブジェクトクラスを作成する場合は、必須の属性より許可の属性にするようにします。
新しいオブジェクトクラスを定義したら、そのオブジェクトクラスの許可された属性と必須の属性、および継承するオブジェクトクラスを決める必要があります。
ディレクトリのエントリに格納する必要がある情報の中に既存の属性がサポートしていないものがある場合は、新しい属性を追加します。できるかぎり、標準属性を使用するようにします。デフォルトのディレクトリスキーマにある属性を探し、それらを新しいオブジェクトクラスに関連付けて使用します。
たとえば、person、organizationalPerson、または inetOrgPerson の各オブジェクトクラスがサポートしている以外の情報を、個人のエントリに格納したい場合があります。ディレクトリに生年月日を格納する場合、Directory Server の標準スキーマには対応する属性がありません。 dateOfBirth という新しい属性を作成できます。この属性を許可する新しい補助クラスを定義して、この属性をエントリで使用できるようにします。
カスタムスキーマファイルを作成するとき、特にレプリケーションを使用する場合は、次の点に注意する必要があります。
新たに追加したスキーマ要素をオブジェクトクラスで使用するためには、事前にすべての属性が定義されている必要があります。属性とオブジェクトクラスは同じスキーマファイル内で定義できます。
作成する各カスタム属性またはオブジェクトクラスは、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 に読み取り専用で表示されます。
'user defined' という値は、LDAP または DSCC を使用してカスタムスキーマ定義を追加する場合は、サーバーによって自動的に追加されます。ただし、X-ORIGIN フィールドによりわかりやすい値を追加しないと、どのスキーマが関連しているかをあとで理解することが難しくなります。
変更は自動的にはレプリケートされないため、カスタムスキーマファイルはすべてのサーバーに手動で伝達します。
ディレクトリスキーマを変更すると、サーバーはスキーマがいつ変更されたのかを示すタイムスタンプを記録します。各レプリケーションセッションの最初に、サーバーはコンシューマのタイムスタンプとこのタイムスタンプを比較し、必要であればスキーマの変更をプッシュします。カスタムスキーマファイルについては、サーバーは 99user.ldif ファイルに関連付けられている 1 つのタイムスタンプだけを維持します。つまり、カスタムスキーマファイルに加えた変更、または 99user.ldif 以外のファイルに対する変更は、レプリケートされません。このため、トポロジ全体にすべてのスキーマ情報が行き渡るように、カスタムスキーマファイルをほかのすべてのサーバーに伝達する必要があります。
この節では、LDAP 経由で属性タイプを作成、表示、および削除する方法を説明します。
cn=schema エントリは複数の値を持つ属性 attributeTypes があり、ディレクトリスキーマの各属性タイプの定義を格納します。それらの定義は ldapmodify(1) コマンドを使用して追加できます。
新しい属性タイプの定義とユーザー定義属性タイプの変更は、99user.ldif ファイルに保存されます。
各属性タイプ定義には、新しい属性タイプを定義する 1 つ以上の OID を指定する必要があります。新しい属性タイプには、少なくとも次の要素を使用することを考慮してください。
属性 OID。属性のオブジェクト識別子に相当します。OID はスキーマオブジェクトを一意に識別する文字列で、通常は小数点で区切られた数値です。
LDAP v3 に厳密に準拠するには、有効な数値 OID を指定する必要があります。OID の詳細または企業のプレフィックスを要求するには、iana@iana.org の IANA (Internet Assigned Number Authority) に電子メールを送信するか、IANA Web サイトを参照してください。
属性名。属性の一意の名前に相当します。その属性タイプとも呼ばれます。属性名はアルファベットから始まる必要があり、ASCII 文字、数字、ハイフンだけが有効です。
属性名には大文字を含めることもできますが、LDAP クライアントでは属性を区別するために、大文字と小文字で区別すべきではありません。RFC 4512 のセクション 2.5 に従って、属性名は大文字と小文字を区別しないで扱う必要があります。
オプションで、属性タイプに代替の属性名 (エイリアスとも呼ばれる) を含めることもできます。
属性の説明。属性の目的を説明する短い説明文です。
構文。OID によって参照され、属性に保持されているデータを説明します。
OID による属性構文は RFC 4517 に示されています。
使用できる値の数。デフォルトで、属性は複数の値を持つことができますが、1 つの値に制限することができます。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
RFC 4517 に指定された構文に従って、属性タイプ定義を準備します。
ldapmodify(1) コマンドを使用して、属性タイプ定義を追加します。
Directory Server によって、指定した定義に X-ORIGIN 'user defined' が追加されます。
次の例では、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) コマンドを使用して読み取ることができます。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
次のコマンドは、すべての属性タイプの定義を表示します。
$ 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 に保存されます。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
削除する属性タイプの定義を表示します。
詳細については、「属性タイプを表示する」を参照してください。
ldapmodify(1) コマンドを使用して、スキーマに表示される属性タイプ定義を削除します。
次のコマンドは、例 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 経由で、オブジェクトクラスを作成、表示、および削除する方法を説明します。
cn=schema エントリには、ディレクトリスキーマの各オブジェクトクラスの定義を格納し、複数の値を持つ属性 objectClasses があります。それらの定義は ldapmodify(1) コマンドを使用して追加できます。
新しいオブジェクトクラス定義とユーザー定義オブジェクトクラスへの変更は 99user.ldif ファイルに保存されます。
ほかのオブジェクトクラスから継承する複数のオブジェクトクラスを作成するときは、最初に親オブジェクトクラスを作成する必要があります。新しいオブジェクトクラスがカスタム属性を使用するときは、その属性も事前に定義しておく必要があります。
各オブジェクトクラス定義に、1 つ以上の OID を指定する必要があります。新しいオブジェクトクラスには少なくとも次の要素を使用することを考慮してください。
オブジェクトクラス OID。オブジェクトクラスのオブジェクト識別子に相当します。OID はスキーマオブジェクトを一意に識別する文字列で、通常は小数点で区切られた数値です。
LDAP v3 に厳密に準拠するには、有効な数値 OID を指定する必要があります。OID の詳細または企業のプレフィックスを要求するには、iana@iana.org の IANA (Internet Assigned Number Authority) に電子メールを送信するか、IANA Web サイトを参照してください。
オブジェクトクラス名。オブジェクトクラスの一意の名前に相当します。
親オブジェクトクラス。このオブジェクトクラスが属性を継承する既存のオブジェクトクラスです。
このオブジェクトクラスをほかの特定のオブジェクトクラスから継承させない場合は、top を使用します。
一般に、ユーザーエントリに対して属性を追加する場合、親オブジェクトは inetOrgPerson オブジェクトクラスになります。企業エントリに対して属性を追加する場合、親オブジェクトは通常 organization または organizationalUnit になります。グループエントリに対して属性を追加する場合、親オブジェクトは通常 groupOfNames または groupOfUniqueNames になります。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
RFC 4517 に指定された構文に従って、オブジェクトクラス定義を準備します。
ldapmodify(1) コマンドを使用して、オブジェクトクラス定義を追加します。
Directory Server によって、指定した定義に X-ORIGIN 'user defined' が追加されます。
次の例では、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) コマンドを使用して読み取ることができます。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
次のコマンドは、すべてのオブジェクトクラスの定義を表示します。
$ 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 ファイルに保存されます。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
削除するオブジェクトクラス定義を表示します。
詳細については、「オブジェクトクラスを表示する」を参照してください。
ldapmodify(1) コマンドを使用して、スキーマに表示されるオブジェクトクラス定義を削除します。
次のコマンドは、例 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' を含めて、このスキーマ定義を拡張として分類する必要があります。
スキーマに新しい属性を追加する場合は、それらの属性を持つオブジェクトクラスを新しく作成する必要があります。必要な属性のほとんどが含まれている既存のオブジェクトクラスに対して、新たに必要となった属性を追加すると、LDAP クライアントとの相互運用性が低下するためです。
Directory Server と既存の LDAP クライアントとの相互運用性は、標準の LDAP スキーマに依存しています。標準スキーマを変更すると、サーバーのアップグレード時にも問題が発生します。同様の理由から、標準スキーマの要素を削除することはできません。
Directory Server スキーマは cn=schema エントリの属性に保存されます。設定エントリと同様に、これは、サーバーの起動中にファイルから読み取られる、スキーマの LDAP ビューです。
Directory Server スキーマの拡張に使用する方法は、スキーマ拡張を保存するファイル名を制御するかどうかによって異なります。さらに、レプリケーションによってコンシューマに変更をプッシュするかどうかによっても異なります。次の表を参照して、特定の状況で実行する手順を判断してください。
表 12–1 スキーマの拡張方法
作業 |
参照先 |
---|---|
レプリケーションを使用しない。カスタムスキーマファイルを追加して、スキーマを拡張する。 | |
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 という名前をファイルにその要素を定義し、このファイルをすべてのサーバーのスキーマディレクトリにコピーします。次にすべてのサーバーを再起動して、新しいスキーマファイルを読み込みます。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
98mySchema.ldif などの独自のスキーマ定義ファイルを作成します。
スキーマファイルの定義の構文については、RFC 4517 で説明されています。
(省略可能) このスキーマが更新をほかのサーバーに送るマスターレプリカである場合は、レプリケーショントポロジでスキーマ定義ファイルを各サーバーインスタンスにコピーします。
レプリケーションメカニズムでは、スキーマを含む LDIF ファイルに直接加えた変更は検出されません。そのため、マスターを再起動したあとでも、変更がコンシューマにレプリケートされません。
スキーマ定義ファイルをコピーした各 Directory Server インスタンスを再起動します。
サーバーが再起動すると、スキーマ定義が再ロードされ、変更が有効になります。
スキーマは cn=schema 内の LDAP ビューによって定義されるため、ldapsearch ユーティリティーおよび ldapmodify ユーティリティーを使用してスキーマをオンラインで表示、変更することができます。しかし、変更できるスキーマ要素は、X-ORIGIN フィールドに 'user defined' という値が設定されている要素だけです。サーバーは、その他の定義に対するすべての変更処理を拒否します。
新しい要素の定義とユーザー定義の要素に対する変更は、99user.ldif ファイルに保存されます。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
コマンド行からのスキーマ定義の変更は、正確な入力が必要な値が長いため、エラーを生じがちです。しかし、ディレクトリスキーマの更新が必要なスクリプトにこの機能を指定することができます。
ldapmodify(1) コマンドを使用して、各 attributeTypes 属性値を追加または削除します。
詳細については、「属性タイプを作成する」または 「属性タイプを削除する」を参照してください。
ldapmodify(1) コマンドを使用して、各 objectClasses 属性値を追加または削除してください。
詳細については、「オブジェクトクラスを作成する」または 「オブジェクトクラスを削除する」を参照してください。
いずれかの値を変更するには、特定の値を削除してから、新しい値として値を追加する必要があります。この処理は、属性に複数の値を持つために必要です。詳細については、「複数値属性の 1 つの値の変更」を参照してください。
カスタムスキーマファイルについては、「カスタムスキーマファイルによるスキーマの拡張」を参照してください。次の手順では、レプリケーションメカニズムを使用して、スキーマ拡張をトポロジのすべてのサーバーに伝達する方法を説明します。
この手順のいくつかの部分では、DSCC を使用してこのタスクを実行できます。詳細については、「Directory Service Control Center のインタフェース」 および DSCC オンラインヘルプを参照してください。手順のその他の部分については、コマンド行を使用した場合にのみ実効できます。
次のいずれかの方法で、スキーマ拡張を準備します。
スキーマファイルの定義の構文については、RFC 4517 で説明されています。
スキーマ定義ファイルを配置するマスターサーバーで、schema_push コマンドを実行します。
このスクリプトは実際にはスキーマをレプリカにプッシュしません。代わりに、このスクリプトは、スキーマファイルがロードされるとすぐにレプリケートされるように、特別な属性をスキーマファイルに書き込みます。詳細については、schema_push(1M) のマニュアルページを参照してください。
スキーマ定義ファイルを配置したマスターサーバーを再起動します。
レプリケーションメカニズムでは、スキーマを含む LDIF ファイルに直接加えた変更は検出されません。ただし、schema_push の実行後にサーバーを再起動すると、サーバーがすべてのスキーマファイルをロードし、レプリケーションメカニズムによって、新しいスキーマがコンシューマにレプリケートされます。
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 からデータをロードできません。
部分コンシューマレプリカで、スキーマ検査を無効にしている場合、その部分コンシューマレプリカが存在するサーバーインスタンス全体に、スキーマ検査が適用されません。その結果、サプライヤレプリカが、部分コンシューマと同じサーバーインスタンスに設定されません。
デフォルトでは、レプリケーションメカニズムによってスキーマがレプリケートされるたびに、スキーマ全体がコンシューマに送信されます。スキーマ全体をコンシューマに送信することが望ましくない状況は 2 つあります。
DSCC またはコマンド行から cn=schema に加える変更は、ユーザー定義のスキーマ要素だけに対象が限定され、すべての標準スキーマは変更されません。スキーマを頻繁に変更する場合、未変更のスキーマ要素を含む大規模な要素セットを毎回送信することはパフォーマンスに影響します。ユーザー定義のスキーマ要素だけをレプリケートすることで、レプリケーションとサーバーのパフォーマンスを向上できます。
Directory Server のマスターが Directory Server 5.1 のコンシューマにレプリケートすると、これらのバージョンの設定属性のスキーマが異なり、競合が発生します。この場合は、ユーザー定義のスキーマ要素のみをレプリケートする必要があります。
Directory Server は 11rfc2307.ldif スキーマファイルを使用します。このスキーマファイルは、RFC 2307 に準拠しています。
Directory Server 5.2 より前の Directory Server のバージョンでは 10rfc2307.ldif スキーマファイルを使用します。
DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。