4.2. ビューを使用した仮想ディレクトリー階層の作成


仮想ディレクトリーツリー (DIT) ビューを作成することで、エントリーを独自のグループや階層で整理し、様々な視点から標準の DIT を操作することができます。これにより、ディレクトリー管理のコストを節約し、エントリーによる移動をより直感的にサービスのユーザーに直感的に行うことができます。

4.2.1. ビューについて

仮想ディレクトリーツリービュー、または ビュー とは、DIT でエントリーをカテゴリー分け、検索するための標準ディレクトリーツリー (DIT) に加えて構造の任意のレイヤーです。

ビューを使用すると、仮想ディレクトリー階層を作成できます。そのため、標準の DIT に配置しても、エントリーの移動が簡単になります。ビューは、フィルターされたロールまたは動的グループのメンバーと同様に、エントリーの属性を使用して仮想階層に追加します。クライアントアプリケーションにとって、ビューは通常のコンテナー階層として表示されます。

この方法では、最初はフラットな DIT にエントリーを配置し、ビューを使用して複雑な階層でエントリーを分類することができ、エントリーを移動させる必要がありません。また、標準的な DIT では実現できない、複数のビューでエントリーを表示することができます。

ビューは、名前付きのフィルター と考えることができます。各ビューは nsView オブジェクトクラスのエントリーであり、どのエントリーをそのビューで表示するかを示す nsViewFilter 属性を持つことができます。フィルターにオブジェクトクラスを指定して、返されるエントリーのタイプを制限することが望ましい場合があります。

ビューを他のビューのコンテナーとして使用し、仮想階層を作成できます。ネストされたビューは、その祖先からフィルターを継承し、そのフィルターと祖先フィルターを (&(container filter)(view filter)) などの AND で組み合わせてビューを制限します。

ビューをベースとして検索が実行されると、フィルターに一致するエントリーがこの仮想検索スペースから返されます。エントリーは、ほぼビュー下でネスト化されるように見えますが、実際には DIT の任意の場所に保存できます。

注記

テストインスタンスを作成し、/usr/share/dirsrv/data/Example-views.ldif にあるサンプルファイルからインポートされたデータでビューがどのように機能するかを確認することができます。

4.2.2. ディレクトリーの設計に関する考慮事項

ディレクトリーツリー (DIT) を設計する場合は、階層でエントリーを組織内の階層を反映するために、自然にお気づけられます。DIT のエントリーの位置をエントリーの識別名 (DN) に表示しない標準 DIT は、固定階層で使用するのに適しています。

図4.4 機能的な単位に基づく標準階層 DIT

ただし、組織内の階層の性質は動的なものです。標準的な DIT のエントリーの移動は、エントリーの位置を変更するたびに、エントリーとその子すべての子の名前を変更する必要があるためです。これにより、サービスの中断や追加費用 (特に最上位サブツリーの変更) が発生します。

リソースタイプ (people、等価性など) など、変更しない特性によってリソースの分類が含まれるフラット階層を設計し、標準のフラット DIT でこの階層を取得することが推奨されます。

図4.5 リソースタイプに基づく標準フラット DIT

ただし、リソースを移動するのにフラット DIT は便利ではありません。異なるユーザーは、機能性ユニットや地理的なロケーションとの関連付けなど、異なるパースペクティブからリソースをナビゲートする必要があります。これには、フラット DIT の場合は追加のツールや複雑な検索クエリーが必要になる場合があります。

フラット DIT の制限を解消する解決策は、ビューの仮想階層で提供されます。ビューを使用すると、階層内のエントリーの位置からエントリーの名前を分離して、柔軟な階層を作成できます。仮想階層は、代わりに属性に基づいています。

図4.6 仮想階層のビューを持つ DIT

4.2.3. ビューを使用する利点

仮想ディレクトリーツリービューを使用すると、ユーザーが直感的に操作でき、管理者にとっては深く入れ子になった標準ディレクトリーツリー (DIT) よりも効率的にメンテナンスできる、柔軟なカスタム階層を構築できるというメリットがあります。

フラットで柔軟な命名

仮想 DIT ビューは、従来の階層構造が提供するのと同様のナビゲーションと管理のサポートを提供するため、ビューではエントリーにフラットな名前空間を使用することができます。

DIT に変更がある場合は、エントリーを移動する必要はありません。DIT ビュー階層の変更のみが変更されます。これらの階層には実際のエントリーが含まれていないため、簡単に変更できます。

設計エラーの削減
導入計画中の見落としは、仮想 DIT ビューを使用することで、壊滅的ではなくなります。最初の段階で階層が正しく開発されていなくても、サービスに支障をきたすことなく、簡単かつ迅速に変更することができます。
迅速かつ cheap maintenance

ビュー階層を数分で完全に修正し、その結果を即座に実現できるため、ディレクトリーのメンテナンスコストを大幅に削減できます。

仮想 DIT 階層の変更は瞬時に実現されます。組織変更があっても、新しい仮想 DIT ビューを迅速に作成することができます。新しい仮想 DIT ビューは古いビューと同時に存在できるので、エントリー自体およびそれらを使用するアプリケーション向けに、より段階的な変更が可能です。ディレクトリーの組織の変更は、1 か 0 かの操作ではないため、一定期間サービスを中断せずに実行できます。

全体的な柔軟性の強化

ナビゲーションと管理に複数の仮想 DIT ビューを使用すると、ディレクトリーサービスをより柔軟に利用することができます。

仮想 DIT ビューが提供する機能を使用すると、組織は古いメソッドと新しいメソッドの両方を使用して、エントリーを DIT の特定の位置に配置する必要なしにディレクトリーデータを編成できます。

直感的なユーザーナビゲーション

ビューは、作業の柔軟性を高め、ディレクトリーユーザーが通常は知る必要のない属性名や値を使用して複雑な検索フィルターを作成する必要性を軽減します。

ディレクトリー情報を表示およびクエリーする手段が複数ある柔軟性により、エンドユーザーとアプリケーションは階層ナビゲーションを通じて必要とされるものを直感的に把握できます。

検索クエリーを頻繁に行うためのショートカット
仮想 DIT ビュー階層は、頻繁に必要とされる情報の検索を容易にするための、一種の既製のクエリーとして作成することができます。

4.2.4. 他の機能とのビューの互換性

ビューを使用する場合、検索領域は単一の接尾辞のエントリーに制限されます。ユーザーは、仮想階層からの結果を取得するために、ビューで検索クエリーに基づく必要があります。アクセス制御には若干異なる方法を使用する必要があります。ビューでは、ロールとサービスのクラスと共にエントリーグループを使用できます。

複数のバックエンド

バーチャル DIT ビューは、複数のバックエンドと完全に互換性があるわけではありません。

検索は単一のバックエンドに制限されています。つまり、ビューによって返されるエントリーは同じ接尾辞内になければなりません。

探索空間

仮想検索領域は、標準の検索スペースとは異なります。仮想検索領域は、検索がフィルターを持つビューノードにある場合にのみアクセスできます。それ以外の場合は、仮想 DIT 階層に含まれるエントリーが返されない標準のディレクトリーツリー (DIT) に対する規則的な検索です。

たとえば、dc=example,dc=com がベースの検索を実行すると、ビューの仮想検索空間からのエントリーが返されません。実際、virtual-search-space の検索は実行されません。Views の処理は、検索ベースが ou=Cupertino,ou=Location Views,dc=example,dc=com のような場合に発生します。

このようにして、Directory Server では、検索が両方の場所からエントリーが発生しないようにします。

アクセス制御
ビューを使用するには、アクセス制御に若干異なるアプローチが必要です。現在、ビューにはアクセス制御リスト (ACL) の明示的なサポートがないため、親のビューにロールベースの ACL を作成し、ロールをビュー階層の適切な部分に追加します。これにより、階層の組織プロパティーを利用できます。
エントリーのグループ化
Directory Server の サービスクラスロール は、どちらもビューをサポートしています。ビュー階層の下に class of service または role を追加する場合、ビューに論理的および実際的の両方に含まれるエントリーはスコープ内にあると見なされます。つまり、仮想 DIT ビューを使用して ロールサービスクラス を適用することができますが、フラットな名前空間を照会しても、その適用の効果を見ることができます。

4.2.5. クライアントアプリケーションとのビューの互換性

仮想ディレクトリーツリー (DIT) ビューは、標準の DIT を高レベルにするように設計されています。ビューの存在は、ほとんどのアプリケーションに対して透過的にする必要があります。ビューを使用していることを示すものがあってはいけません。いくつかの特殊なケースを除き、Directory Server インスタンスでビューが使用されていることを、ディレクトリーユーザーが知る必要はありません。ビューは従来の DIT のように表示され、動作します。

特定のタイプのアプリケーションでは、ビュー対応ディレクトリーサービスを使用すると問題が発生する可能性があります。以下に例を示します。

  • ターゲットエントリーの DN を使用して DIT をナビゲートするアプリケーション。

    このタイプのアプリケーションは、エントリーが見つかったビュー階層ではなく、エントリーが物理的に存在する階層をナビゲートしていることを把握します。その理由は、ビューは、ビューの階層に合わせてエントリーの DN を変更することで、エントリーの本当の位置を隠そうとはしないからです。

    これは意図的なものです。エントリーの真の位置が偽装されていると、多くのアプリケーションが機能しなくなります。例えば、一意のエントリーを識別するために DN に依存するアプリケーションなどです。このように DN を分解して上方向にナビゲートするのは、クライアントアプリケーションとしては珍しい手法ですが、それにもかかわらず、これを行うクライアントは意図した通りに機能しない可能性があります。

  • numSubordinates 操作属性を使用して、ノードの下に何個のエントリーが存在するかを判断するアプリケーション。

    ビュー内のノードについては、現在、仮想検索空間を無視して、実際の検索空間に存在するエントリーのみをカウントしています。そのため、アプリケーションでは検索を使用してビューを評価できない場合があります。

4.2.6. ビューの作成

この手順では、コマンドラインで仮想ディレクトリーツリービューを作成する方法を説明します。

手順

  • ldapadd ユーティリティーを使用してビューエントリーを追加します。

    nsView オブジェクトクラスを指定し、nsViewFilter 属性でビューフィルターを定義します。

    # ldapadd -D "cn=Directory Manager" -W -H ldap://server.example.com -x
    dn: ou=PeopleInRoom0466,dc=example,dc=com
    objectClass: top
    objectClass: organizationalUnit
    objectClass: nsView
    ou: PeopleInRoom0466
    description: People in the room 0466
    nsViewFilter: (&(objectClass=inetOrgPerson)(roomNumber=0466))
    Copy to Clipboard Toggle word wrap

検証

  • ビューで検索ベースとして実行します。

    # ldapsearch -D "cn=Directory Manager" -W -H ldap://server.example.com -x -b ou=PeopleInRoom0466,dc=example,dc=com
    Copy to Clipboard Toggle word wrap

ビューは指定のフィルターに基づいて検索結果から派生します。フィルターの一部は nsViewFilter で明示的に指定される属性です。フィルターの残りの部分はエントリー階層に基づいており、ビューに含まれる実際のエントリーの entryid および parentid 操作属性を検索します。

(|(parentid=search_base_id)(entryid=search_base_id)
Copy to Clipboard Toggle word wrap

検索された属性 (entryidparentid、または nsViewFilter の属性) のいずれかにインデックスが付けられていない場合、検索は部分的にインデックスが解除され、Directory Server はディレクトリーツリー全体で一致するエントリーを検索します。

ビューのパフォーマンスを改善するには、以下のようにインデックスを作成します。

  • entryid等価インデックス (eq) を作成します。parentid 属性は、デフォルトでシステムインデックスでインデックス化されます。
  • nsViewFilter 内のフィルターが存在 (attribute=*) をテストする場合は、テスト対象の属性の 存在インデックス (pres) を作成します。このインデックスタイプは、少数のディレクトリーエントリーに表示される属性でのみ使用する必要があります。
  • nsViewFilter 内のフィルターが等価性 (attribute=value) をテストする場合は、テスト対象の属性の 等価インデックス (eq) を作成します。
  • nsViewFilter のフィルターが部分文字列をテストする場合 (attribute=value*) は、テストする属性の 部分文字列インデックス (sub) を作成します。
  • nsViewFilter のフィルターが近似値 (attribute~=value) をテストする場合、テスト対象の属性の 近似インデックス (approximate) を作成します。

たとえば、以下の view フィルターを使用する場合は、以下を実行します。

nsViewFilter: (&(objectClass=inetOrgPerson)(roomNumber=*66))
Copy to Clipboard Toggle word wrap

objectClass には、デフォルトで実行される 等価インデックス で、roomNumber には 部分文字列インデックス でインデックスを付ける必要があります。

前提条件

  • ビューフィルターで使用する属性に注意してください。

手順

  1. オプション: バックエンドをリスト表示し、データベースをインデックス化します。

    # dsconf <instance_name> backend suffix list
    dc=example,dc=com (userroot)
    Copy to Clipboard Toggle word wrap

    (括弧で) 選択したデータベース名を書き留めておきます。

  2. 選択したバックエンドのデータベースの dsconfig ユーティリティーを使用してインデックス設定を作成します。

    特に国際化されたインスタンスの場合、属性名、インデックスタイプと、任意で照合順序 (OID) を設定するためのマッチングルールを指定します。

    # dsconf <instance_name> backend index add --attr roomNumber --index-type sub userroot
    Copy to Clipboard Toggle word wrap

    view フィルターで使用される属性ごとに、このステップを繰り返します。

  3. 新規インデックスを適用するためにデータベースを再インデックスします。

    # dsconf <instance_name> backend index reindex userroot
    Copy to Clipboard Toggle word wrap

検証

  1. ビューで使用するフィルターが同じ標準ディレクトリーツリーに基づく検索を実行します。

    # ldapsearch -D "cn=Directory Manager" -W -H ldap://server.example.com -x -b dc=example,dc=com (&(objectClass=inetOrgPerson)(roomNumber=*66))
    # ldapsearch -D "cn=Directory Manager" -W -H ldap://server.example.com -x -b dc=example,dc=com "(&(objectClass=inetOrgPerson)(roomNumber=*66))"
    Copy to Clipboard Toggle word wrap
  2. /var/log/dirsrv/slapd-<instance_name>/access のアクセスログを表示します。

    検索の RESULT には note=U または Partially Unindexed Filter が詳細に含まれていないはずです。

ビューは指定のフィルターに基づいて検索結果から派生します。フィルターの一部は nsViewFilter で明示的に指定される属性です。フィルターの残りの部分はエントリー階層に基づいており、ビューに含まれる実際のエントリーの entryid および parentid 操作属性を検索します。

(|(parentid=search_base_id)(entryid=search_base_id)
Copy to Clipboard Toggle word wrap

検索された属性 (entryidparentid、または nsViewFilter の属性) のいずれかにインデックスが付けられていない場合、検索は部分的にインデックスが解除され、Directory Server はディレクトリーツリー全体で一致するエントリーを検索します。

ビューのパフォーマンスを改善するには、以下のようにインデックスを作成します。

  • entryid等価インデックス (eq) を作成します。parentid 属性は、デフォルトでシステムインデックスでインデックス化されます。
  • nsViewFilter 内のフィルターが存在 (attribute=*) をテストする場合は、テスト対象の属性の 存在インデックス (pres) を作成します。このインデックスタイプは、少数のディレクトリーエントリーに表示される属性でのみ使用する必要があります。
  • nsViewFilter 内のフィルターが等価性 (attribute=value) をテストする場合は、テスト対象の属性の 等価インデックス (eq) を作成します。
  • nsViewFilter のフィルターが部分文字列をテストする場合 (attribute=value*) は、テストする属性の 部分文字列インデックス (sub) を作成します。
  • nsViewFilter のフィルターが近似値 (attribute~=value) をテストする場合、テスト対象の属性の 近似インデックス (approximate) を作成します。

たとえば、以下の view フィルターを使用する場合は、以下を実行します。

nsViewFilter: (&(objectClass=inetOrgPerson)(roomNumber=*66))
Copy to Clipboard Toggle word wrap

objectClass には、デフォルトで実行される 等価インデックス で、roomNumber には 部分文字列インデックス でインデックスを付ける必要があります。

前提条件

  • Web コンソールでインスタンスにログインしている。
  • ビューフィルターで使用する属性に注意してください。

手順

  1. Database で、インデックスを作成する設定ツリーから接尾辞を選択します。
  2. Indexes および Database Indexes に移動します。
  3. Add Index ボタンをクリックします。
  4. 属性の名前を入力し、属性を選択します。
  5. この属性に対して作成する必要のある Index Types を選択します。
  6. 必要に応じて、特に国際化されたインスタンスの場合に、照合順序 (OID) を指定するための Matching Rules を追加します。
  7. Index attribute after creation を選択し、後でインデックスを再ビルドします。
  8. Create Index をクリックします。
  9. インデックス化される各属性に対して手順を繰り返します。

検証

  • 追加された属性の名前を入力して、インデックスをフィルタリング します。
  • 新たにインデックス化された属性が結果に表示されるはずです。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat