18 ディレクトリ・データの管理
18.1 データのインポートおよびエクスポート
ディレクトリ・サーバーは、特定のバックエンドとの間でデータをやり取りするいくつかのメカニズムを備えています。
次の各トピックでは、各種オプションの概要を示し、インポートおよびエクスポートのメカニズムについて詳しく説明します。
-
import-ldifを使用したデータのインポート
ノート:
ユーザー・エントリをインポートする場合、Oracle Unified Directoryでは、事前に暗号化されたパスワードがパスワード・ポリシーに一致していることを検証できないことに注意してください。したがって、事前に暗号化されたパスワードは、次のエラーで拒否されます:
LDAP: error code 53 - Pre-encoded passwords are not allowed for the password attribute userPassword.
ldapmodifyまたはimport-ldifを使用してユーザー・エントリをインポートする場合に事前に暗号化されたパスワードを許可するには、拡張プロパティallow-pre-encoded-passwordsをtrueに設定することで、デフォルト・パスワード・ポリシーを変更します。詳細は、「デフォルト・パスワード・ポリシーの変更」を参照してください。
18.1.1 スタンドアロン・ディレクトリ・サーバーへのデータの移入
スタンドアロン・ディレクトリにデータを移入するには、setupユーティリティまたはimport-ldifコマンドを使用して、LDAPデータ変換形式(LDIF)からデータをインポートしたり、別のサーバーからバイナリ・データベースをコピーしたり、以前のバックアップがある場合はそれをリストアしたり、ldapmodifyコマンドを使用してエントリを追加します。
スタンドアロン・ディレクトリ・サーバーにデータを移入するには、次の方法の1つを使用します:
-
サーバーをセットアップする際に、GUIモードで
setupユーティリティを使用するか、対話方式コマンド行モードでsetupユーティリティを使用することによって、LDAPデータ交換形式(LDIF)ファイルからデータをインポートします。これは、スタンドアロン・サーバーまたはレプリケートされたトポロジにおける最初のサーバーを初期化するための最も便利な方法です。 -
空の接尾辞から開始し、
ldapmodifyコマンドを使用することでエントリを追加します。たとえば:$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ -a -f /usr/local/add_entry.ldif
-
import-ldifコマンドを使用して、LDIFファイルからデータをインポートします。たとえば:$ import-ldif -b dc=example,dc=com -n userRoot -l /var/tmp/Example.ldif
これは、エントリを一括して追加する場合の大変効率的な方法です。
import-ldifコマンドは、接尾辞の既存のデータを置き換えるか、ベースDNにデータを追加することによって、LDIFファイルからデータをインポートします。同様に、export-ldifコマンドは、データベースからLDIFファイルにエントリをエクスポートし、その後、それは別のサーバーにインポートできます。どちらのツールでも、ファイルの圧縮およびSASL拡張と、SSLおよびstartTLSを使用したクライアント/サーバー認証がサポートされています。 -
別のサーバーからバイナリ・データベースをコピーします。この方法は、バイナリ・コピーとも呼ばれます。
$ cp instance-path/db/example.db destination-path/db
-
restoreコマンドを使用して、バックアップからデータベースをリストアします。たとえば:$ restore -d /home/backup/userRoot
ノート:
バイナリ・データベース・コピーまたはバックアップからのデータベースのリストアを実行するには、ソース・サーバーとターゲット・サーバーでデータベース・リモートLDAP構造および索引が同一であることが必要です。
18.1.2 import-ldifを使用したデータのインポート
import-ldifコマンドは、LDIFファイルから読み取ったデータまたはMakeLDIFテンプレート・ファイルから生成されたデータをディレクトリ・サーバー・バックエンドに移入するために使用されます。通常、import-ldifを使用すると、ldapmodifyを使用してエントリを追加するよりも非常に速く処理できます。
MakeLDIFファイルの作成の詳細は、「MakeLDIFテンプレート・ファイルの作成について」を参照してください。import-ldifコマンドでは、LDIFファイルと圧縮済ファイル(.zip)の両方がサポートされています。
インポート操作における次の局面に注意してください:
-
Oracle Berkeley DB Java Edition (JE)バックエンド全体への完全なインポートのほうが、JEバックエンドの分岐への部分インポートよりもパフォーマンスがよくなります。インポートするすべてのLDIFファイルで、UTF-8文字セット・エンコードを使用している必要があります。
-
接尾辞のインポートは、リソースに負荷のかかる操作です。多数の接尾辞を含むLDIFファイルをインポートする場合、そのインポート操作を完了するにはヒープ領域不足になることがあります。そのようなLDIFファイルをインポートする前に、ヒープを可能なかぎり増やしておく必要があります。詳細は、「パフォーマンスのチューニング」および「大規模データ・セットのインポート」を参照してください。
-
LDIFファイルをインポートするためにroot権限は必要ありませんが、
cn=Directory Managerなどのroot権限を持つユーザーとして認証される必要があります。
次の項では、import-ldifコマンドを使用してデータをインポートする方法について説明します:
18.1.2.1 import-ldifの操作モードについて
import-ldifコマンドには、操作にオンラインとオフラインの2つのモードがあります。
-
オンライン・モード。オンライン・モードでは、
import-ldifは、実行中のディレクトリ・サーバー・インスタンスにアクセスし、インポート・タスクを登録します。このコマンドは、管理コネクタを通してSSL経由でタスク・バックエンドにアクセスします。詳細は、「サーバーへの管理トラフィックの管理」を参照してください。オンライン・モードは、接続オプション(--hostname、--port、--bindDN、--bindPasswordFileなど)が指定されている場合は自動的に実行されます。ノート:
オンライン・インポートの場合でも、インポート中はバックエンドは使用できません。レプリケートされたトポロジでは、全体的なサービスは、依然としてreferral on update機能を通して使用可能です。詳細は、「レプリケート・トポロジでのリフェラルの理解」を参照してください。
一般的に、オンライン・インポートを実行する予定である場合は、サーバーを起動するときにヒープを増やす必要があります。詳細は、「パフォーマンスのチューニング」を参照してください。
-
オフライン・モード。接続オプションが指定されていない場合、このコマンドはオフライン・モードで実行されます。オフライン・モードでは、
import-ldifはディレクトリ・サーバー・インスタンスを介さずに、データベースに直接アクセスします。この場合、ディレクトリ・サーバーを停止する必要があります。
18.1.2.2 オフライン・モードでのデータのインポート
次の手順では、インポートLDIFファイルで指定されている新しいエントリを持つリモートLDAPデータベースをインポートします。コマンドはオフライン・モードで実行され、それには、インポートする前にサーバーを停止する必要があります。
18.1.2.5 部分的なファイルのインポート
import-ldifコマンドには、プロセス中に含めるまたは除外するベースDNを指定することによって、インポート・ファイルの一部をインポートするオプションがあります。
この例では、ベースDN (dc=example,dc=com)の下のすべてのエントリがインポートされ、ou=People,dc=example,dc=comの下のすべてのエントリが除外されます。
18.1.2.6 フィルタを使用した部分的なファイルのインポート
import-ldifコマンドには、データを含めるか除外するためのフィルタを使用することによって、インポート・ファイルの一部をインポートするオプションがあります。このメカニズムを使用する前に、それがどのように機能するのかを完全に把握してください。
この例では、検索フィルタl=Auckland (つまり、location=Auckland)に一致するエントリを除く、LDIFファイルの内容がインポートされます。
--includeFilterオプションは、インポート中に検索フィルタに一致するすべてのエントリが含められることを除いて、--excludeFilterと同様の方法で機能します。
18.1.2.7 インポート中の属性の組込みと除外
import-ldifコマンドには、--includeAttributeおよび--excludeAttributeのオプションを使用することで、インポート中に、それぞれ属性を含めるまたは除外するオプションがあります。このメカニズムを使用する前に、それがどのように機能するのかを完全に把握してください。
18.1.2.9 インポート中に拒否またはスキップされたエントリの記録
import-ldifコマンドは、インポート・プロセス中に拒否またはスキップされたエントリについて出力ファイルに書き込む方法を提供します。このファイルにより、LDIFファイルの簡単なデバッグが可能です。拒否されたエントリは、ディレクトリ・サーバーによって、追加されるエントリがスキーマ違反が原因で拒否された場合に発生します。スキップされたエントリは、指定されているベースDNの下にエントリを配置できない場合に発生します。
18.1.2.10 MakeLDIFテンプレートからのデータのインポート
ディレクトリ・サーバーにはJavaユーティリティmakeLDIFが組み込まれており、それを使用してインポート向けのサンプル・データを生成できます。makeLDIFユーティリティには、テンプレート・ファイルが必要です。独自のテンプレート・ファイルを作成するか、INSTANCE_DIR/OUD/config/MakeLDIF/example.templateにあるテンプレート・ファイルを必要に応じて編集して使用できます。詳細は、「MakeLDIFテンプレート・ファイルの作成について」および「make-ldif」を参照してください。
18.1.2.11 オンライン・モードでのインポートの実行
import-ldifユーティリティは、サーバーをオンラインにした状態で実行することもできます。オンライン・モードでは、このコマンドは、管理コネクタを通してSSL経由でタスク・バックエンドにアクセスします。オンライン・モードでこのコマンドを実行するには、SSL証明書の信頼方法など関連する接続オプションを指定する必要があります。この例では、-Xオプションを使用して、すべての証明書を信頼します。詳細は、「サーバーへの管理トラフィックの管理」を参照してください。
適切な接続オプションを指定して、import-ldifコマンドを実行します。
$ import-ldif -h localhost -port 4444 -D "cn=Directory Manager" -j pwd-file -X \ -l /ldif-files/example.ldif
18.1.2.12 インポートのスケジュール
import-ldifユーティリティは、将来の日付でインポートをスケジュールするための--startオプションを備えています。manage-tasksユーティリティを使用することで、このスケジュール済タスクを表示できます。このコマンドは、管理コネクタを通してSSL経由でタスク・バックエンドにアクセスします。インポート・タスクをスケジュールするには、SSL証明書の信頼方法など関連する接続オプションを指定する必要があります。この例では、-Xオプションを使用して、すべての証明書を信頼します。
--startオプションを指定して、import-ldifコマンドを実行します。
$ import-ldif -h localhost -port 4444 -D "cn=Directory Manager" -j pwd-file -X \ -l /ldif-files/example.ldif --start 20080124121500
詳細は、「タスクとしてのコマンドの構成」を参照してください。
18.1.3 export-ldifを使用したデータのエクスポート
export-ldifコマンドを使用して、ディレクトリ・サーバー・バックエンドからデータをエクスポートします。
このコマンドは、次のタスクに有効です:
-
ディレクトリ・データのバックアップ
-
他のアプリケーションへのデータのエクスポート
-
ディレクトリ・トポロジへの変更後のデータベースへの移入
-
レプリケートされたトポロジでのマスター・サーバーの再初期化
ノート:
export-ldifコマンドを使用して、monitor、ads-truststore、backupおよびconfig-file-handlerのバックエンドからデータをエクスポートすることはできません。
次の項では、export-ldifコマンドを使用してデータをエクスポートする方法について説明します:
18.1.3.1 export-ldifの操作モードについて
export-ldifコマンドには、操作にオンラインとオフラインの2つのモードがあります。
-
オンライン・モード。オンライン・モードでは、
export-ldifは、実行中のディレクトリ・サーバー・インスタンスにアクセスし、エクスポート・タスクを登録します。このモードは、LDAP接続オプション(--hostname、--port、--bindDN、--bindPasswordFileなど)が使用されている場合は自動的に実行されます。このコマンドは、管理コネクタを通してSSL経由でタスク・バックエンドにアクセスします。詳細は、「サーバーへの管理トラフィックの管理」を参照してください。 -
オフライン・モード。接続オプションが指定されていない場合、このコマンドはオフライン・モードで実行されます。オフライン・モードでは、
export-ldifはディレクトリ・サーバー・インスタンスを介さずに、データベースに直接アクセスします。この場合、ディレクトリ・サーバーを停止する必要があります。
詳細は、「export-ldif」を参照してください。
18.1.3.3 部分的なデータのエクスポート
export-ldifコマンドには、処理中に含めるまたは除外するベースDNおよびその子を指定することでバックエンドの一部をエクスポートするオプションがあります。
18.1.3.4 フィルタを使用したバックエンドの一部のエクスポート
export-ldifコマンドには、検索フィルタを使用することで、バックエンドの一部をエクスポートするオプションがあります。ディレクトリ・サーバーでは、フィルタに一致するすべてのエントリが含められるか除外されます。このメカニズムを使用する前に、それがどのように機能するのかを完全に把握してください。
この例では、検索フィルタl=Cupertino (つまり、location=Cupertino)に一致するエントリのみがエクスポートされます。--excludeFilterオプションは、エクスポート中にフィルタに一致するすべてのエントリが除外されることを除いて、--includeFilterと同様の方法で機能します。
18.1.3.5 エクスポート中の属性の組込みと除外
export-ldifユーティリティには、--includeAttributeおよび--excludeAttributeのオプションを使用することで、エクスポート中に、それぞれ属性を含めるまたは除外するオプションがあります。このメカニズムを使用する前に、それがどのように機能するのかを完全に把握してください。
18.1.3.7 オンライン・モードでのエクスポートの実行
export-ldifコマンドは、サーバーをオンラインにした状態で実行することもできます。オンライン・モードでは、このコマンドは、管理コネクタを通してSSL経由でタスク・バックエンドにアクセスします。詳細は、「サーバーへの管理トラフィックの管理」を参照してください。オンライン・モードでこのコマンドを実行するには、SSL証明書の信頼方法など関連する接続オプションを指定する必要があります。この例では、-Xオプションを使用して、すべての証明書を信頼します。
LDAP接続オプションを指定して、export-ldifコマンドを実行します。たとえば:
$ export-ldif -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \ --includeBranch "dc=example,dc=com" --backendID userRoot --ldifFile export.ldif
18.1.3.8 エクスポートのスケジュール
export-ldifユーティリティは、将来の日付でエクスポートをスケジュールするための--startオプションを備えています。manage-tasksユーティリティを使用することで、このスケジュール済タスクを表示できます。このコマンドは、管理コネクタを通してSSL経由でタスク・バックエンドにアクセスします。詳細は、「サーバーへの管理トラフィックの管理」を参照してください。
エクスポート・タスクをスケジュールするには、SSL証明書の信頼方法など関連する接続オプションを指定する必要があります。この例では、-Xオプションを使用して、すべての証明書を信頼します。
エクスポートをスケジュールするには、サーバーが実行中である必要があります。
--startオプションおよびLDAP接続パラメータを指定して、export-ldifコマンドを実行します。
--startオプションは、その値として、yyyymmddhhmmss形式の日付と時刻を取ります。たとえば:
$ export-ldif -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file -X \ --includeBranch "dc=example,dc=com" --backendID userRoot \ --ldifFile export.ldif --start 20080124121500
18.1.4 MakeLDIFテンプレート・ファイルの作成について
make-ldifコマンドは、テンプレート・ファイルを使用して、LDIFファイルを生成する方法を定義します。この手法では、目的の結果を生成するためにコードを変更することを必要とせずに柔軟性が得られます。
この項の各トピックでは、make-ldifコマンドを使用して、カスタマイズされたLDIFファイルを作成する方法を説明します。
18.1.4.1 テンプレート・ファイルの書式の理解
テンプレート・ファイルには、最大4つのセクションを含めることができ、それらは次の順序で指定する必要があります。
18.1.4.1.1 カスタム・タグのインクルードの理解
カスタム・タグのインクルードは、カスタム・タグをロードし、make-ldifテンプレートを処理するときにそれらを使用できるうにするメカニズムを提供します。これは、次のようにincludeディレクティブを使用して実行します:
include com.example.opends.makeldif.MyCustomTag
指定したクラスは、クラス・パスに含まれている必要があり、org.opends.server.tools.makeldif.Tagクラスのサブクラスである必要があります。カスタム・タグの開発の詳細は、「カスタム・タグの定義」を参照してください。
make-ldifで提供されている標準置換タグはすべて、自動的に使用可能であるため、明示的なincludeディレクティブは必要ありません。
18.1.4.1.2 グローバル置換変数の理解
最初のセクションは、テンプレート・ファイルに必ず含める必要があり、そこでグローバル置換変数を定義します。グローバル置換変数は、テンプレート・ファイルで後で参照できるテキストの文字列を定義するために使用され、各行がメモリーに読み込まれるときに自動的に置換されます(Cプリプロセッサによって、コード内のマクロ゛かそれらの定義済の値と置換されるのに似ています)。たとえば、次の置換変数定義によって、dc=example,dc=comという値を持つsuffixという名前のグローバル置換変数が作成されます:
define suffix=dc=example,dc=com
グローバル置換変数が定義されているときは、その縁数名が大カッコで囲まれている場合(たとえば、[suffix])、トークンがその置換変数に対して定義された値と置換されます。
最初の空白行とその後に続く1つ以上の置換変数定義によって示されるようにすべての置換変数定義が読み取られると、テンプレート・ファイルから読み取られるすべて残りの行が、1行ずつ処理されます。大カッコ内の置換変数名のすべてのオカレンスは、その変数の値で置換されます。置換は、テンプレート・ファイルがメモリーに読み取られるときに実行されるため、置換変数は、分岐、テンプレート定義、さらにタグ内などどの場所にも配置できます。
テンプレート・ファイルに定義されているグローバル置換変数がある場合、それらは、ファイルの先頭に配置する必要があり、それらの間に空白文字を入れないようにします。ただし、置換変数は必要ありません。置換変数がない場合、テンプレート・ファイルは分岐定義から開始する必要があります。
18.1.4.1.3 分岐定義の理解
分岐定義は、生成されたLDIFに使用する基本構造を定義するためにmake-ldifテンプレート・ファイル内で使用されます。それらによって、階層の最上部に配置される1つ以上のエントリと、それらの下に配置されるエントリのタイプが指定されます。
分岐定義の最も基本的な形式は、次のとおりです:
branch: dc=example,dc=com
この例では、次のエントリがdc=example,dc=comのDNで作成されます:
dn: dc=example,dc=com objectClass: top objectClass: domain dc: example
エントリの基本構造は、分岐定義のDNで指定されているdcのRDN属性によって定義されます。make-ldifコマンドは、dc RDN属性をdomainオブジェクト・クラスと自動的に関連付けます。make-ldifコマンドには、次のように分岐エントリ内の他の共通RDN属性に対して同様の定義があります:
-
o -
organizationオブジェクト・クラスのエントリを作成します。 -
ou -
organizationalUnitオブジェクト・クラスのエントリを作成します。 -
c -
countryオブジェクト・クラスのエントリを作成します。
分岐エントリに対して、他のどのような種類のRDN属性も使用できます。前述の指定したもの以外のRDN属性を持つ分岐エントリについては、エントリはuntypedObjectおよびextensibleObjectオブジェクト・クラスで作成されます。
前述の分岐定義によって、その分岐エントリの下に追加のエントリが作成されることはありません。これを行うには、1つ以上のsubordinateTemplate行を指定する必要があります。たとえば:
branch: ou=People,dc=example,dc=com subordinateTemplate: person:100
これにより、ou=People,dc=example,dc=comエントリが作成され、personテンプレートでモデル化された1000個の他のエントリがその下に作成されます。personテンプレートは、テンプレート・ファイルで後で定義する必要があります。詳細は、「テンプレート定義の理解」を参照してください。
分岐エントリは、1つのsubordinateTemplate定義のみに限定されません。その分岐定義の別の行にsubordinateTemplate定義を含めることによって、それらを複数指定できます。次の例では、personテンプレートに基づいて1000個のエントリを作成し、certificatePersonテンプレートに基づいて別の100個のエントリを作成します:
branch: ou=People,dc=example,dc=com subordinateTemplate: person:10000 subordinateTemplate: certificatePerson:100
前述のすべてのエントリにおいて、分岐エントリ自体には、DN、RDN属性、およびRDN属性と関連付けられたオブジェクト・クラスのみが含まれています。分岐エントリにその他の属性を含めるには、テンプレート・ファイルの分岐定義にそれらを含めます。たとえば、次のような分岐定義では:
branch: dc=example,dc=com description: This is the description for dc=example,dc=com
次のエントリが作成されます。
dn: dc=example,dc=com objectClass: top objectClass: domain dc: example description: This is the description for dc=example,dc=com
この追加のテキストは、静的にするか、任意の定義済グローバル置換変数を含めるか、またはテンプレート定義で使用できる置換タグのサブセットを含めることができます。使用可能なタグの概要、および分岐定義でどのタグが使用できるかに関する情報は、「標準置換タグの理解」を参照してください。
18.1.4.1.4 テンプレート定義の理解
make-ldifテンプレート・ファイルの中心となるのは、一連のテンプレート定義です。テンプレートによって、生成されるエントリの構造が定義されます。エントリに含める一連の属性と、その属性に含める値のタイプを指定します。値の指定は、make-ldifによって解析されるタグによって処理され、それらのタグに適した値で置換されます。
テンプレート定義の例は、次のようになります:
template: person
rdnAttr: uid
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
givenName: <first>
sn: <last>
cn: {givenName} {sn}
initials: {givenName:1}<random:chars:ABCDEFGHIJKLMNOPQRSTUVWXYZ:1>{sn:1}
employeeNumber: <sequential:0>
uid: user.{employeeNumber}
mail: {uid}@[maildomain]
userPassword: password
telephoneNumber: <random:telephone>
homePhone: <random:telephone>
pager: <random:telephone>
mobile: <random:telephone>
street: <random:numeric:5> <file:streets> Street
l: <file:cities>
st: <file:states>
postalCode: <random:numeric:5>
postalAddress: {cn}${street}${l}, {st} {postalCode}
description: This is the description for {cn}.
この例は、LDIFデータを作成するときにmake-ldifが提供する柔軟性を示しています。テンプレート定義に含めることができるタグは、後続のトピックで説明します(「標準置換タグの理解」および「属性値参照タグの使用」を参照)。
テンプレート定義の最上部には、テンプレート自体に関する情報を示す2つの行があり、このテンプレートから作成されるエントリには含まれません。最初の行は、テンプレートの名前を指定します。これは、分岐定義のsubordinateTemplate行で参照される名前です。2番目の行では、エントリのRDN属性として使用する属性の名前を指定します。そのRDN属性には、テンプレート定義の本文で値を割り当てる必要があり、値の割当て方法では、同じ親の下の同じテンプレートで作成されるすべての他のエントリの間でその値が必ず一意となるようにする必要があります。
ノート:
次の例に示すように、プラス記号で属性名を区切ることで、複数の値を持つRDNを指定できます:
rdnAttr: uid+employeeNumber
複数の値を持つRDNを使用する場合、すべてのRDN属性について値をテンプレート本文で定義し、各エントリのRDN値の組合せが一意になっていることが必要です。ただし、組合せが重複しない場合は、そのRDN内で1つ以上の属性が一意でなくてもかまいません。
template行およびrdnAttr行に加えて1つ以上のsubordinateTemplate行を含めることができ、これにより、動的に生成された他のエントリの下に動的に生成されたエントリを含め(たとえば、各ユーザー・エントリの下に1つ以上のエントリを含める)、複雑な階層にすることができます。ネストのこのレベルに対する制限はありませんが、同じテンプレートを使用して追加のエントリを直接または間接的に作成するsubordinateTemplateを設定することで再帰的ループが作成されないようにする必要があります。
テンプレート定義では、extendsキーワードの使用による継承の概念もサポートされています。たとえば、次のテンプレート定義から生成されるエントリには、指定されている形式でuserCertificate;binaryとともにpersonテンプレートで定義されているすべての属性が含まれます:
template: certificatePerson rdnAttr: uid extends: person userCertificate;binary:: <random:base64:1000>
extendsキーワードを使用して複数の行を含めることで複数の継承が可能ですが、subordinateTemplateキーワードの場合と同様に、テンプレート・ファイルが、直接または間接的にそれ自体から継承される再帰的ループが作成されないようにすることが重要です。
18.1.4.2 make-ldifテンプレート・ファイル・タグの理解
make-ldifによって、多様なデプロイメントをシミュレートするために使用できるLDIFファイルを生成できるようにするために、テンプレートで使用するための多数のタグが定義されています。「カスタム・タグの定義」の説明に従って、カスタム・タグを作成することもできます。
次の各トピックでは、make-ldifテンプレート・ファイルで使用できる標準セットのタグについて説明します。
18.1.4.2.1 標準置換タグの理解
make-ldif標準置換タグは、山カッコで囲まれた特殊な要素(小なり記号(<)で始まり、大なり記号(>)で終わる)であり、生成された値に動的に置換されます。標準置換タグには、引数を必要としないもの(たとえば、<first>)があります。他のものは引数を取り、その場合、最初にタグ名、次にコロン、そして、各引数の間をコロンで区切った引数のリストが続きます(たとえば、<random:numeric:5>)。引数では、通常、大文字小文字が区別されますが、タグ名では大文字小文字が区別されまません。
次のタイプの標準置換タグは、現在、make-ldifの一部として組み込まれています:
-
DNタグ
DN標準置換タグは、現在のエントリのDNで置換されます。そのDNがまだ使用できない場合(生成されるエントリではRDN属性に値が割り当てられていないためなど)、それは空の文字列で置換されます。通常、このタグが使用される前に、先にテンプレート内ですべてのRDN属性に必ず値が割り当てられるようにします。
DNタグは、引数を指定せずに使用でき(たとえば、
<DN>)、その場合、それが、そのエントリの完全なDNで置換されます。このタグは、1つの整数の引数を取ることもでき、それによって、出力に含めるコンポーネントの最大数を指定します。たとえば、タグ<DN:1>では、そのエントリの左端のDNコンポーネント(多くの場合、RDNと呼ばれる)のみが含められます。したがって、生成されるエントリのDNがuid=john.doe,ou=People,dc=example,dc=comである場合、タグ<DN:1>はuid=john.doeで置換されます。引数値が正ではなく負である場合、指定されている引数値の絶対値が使用され、DNの終わりからその数のコンポーネントを取ります。したがって、uid=john.doe,ou=People,dc=example,dc=comのDNを使用すると、タグ<DN:-1>はdc=comで置換されます。このタグは、分岐とテンプレートの両方の定義で使用できます。
-
Fileタグ
File標準置換タグは、指定されているファイルの行で置換されます。1つまたは2つの引数が必要です。最初の引数は、データ・ファイルのバスである、絶対パスでも
config/MakeLDIFディレクトリに含まれているファイルの名前(パス情報なし)のいずれでもかまいません。2番目の引数がある場合、それはsequentialとrandomのいずれかの値であることが必要で、それはファイル内の行を連続した順序で取得するか、ランダムに選択するかを示しています。2番目の引数を指定しない場合、値はランダムに選択されます。たとえば、タグ<file:cities>と<file:cities:random>のどちらでも、タグは、citiesファイルからランダムに選択した行で置換されますが、タグ<file:cities:sequential>では、市区町村名が連続した順序で取得されます。連続した順序が使用されていて、すべての値が使用し尽された場合、そのファイルの最初の行に戻ります。make-ldifコマンドは、生成されたデータで使用できるいくつかの標準データ・ファイルをインクルードします。これらのファイルは、config/MakeLDIFディレクトリにインクルードされているため、ファイル名のみが必要です。該当するファイルは次のとおりです。cities— 一般的な市区町村名のリストが含まれていますfirst.names— 一般的な名のリストが含まれていますlast.names— 一般的な姓のリストが含まれていますstates— 米国の州を表す2文字の略語すべてのリストが含まれていますstreets— 一般的な番地名のリストが含まれていますこのタグは、分岐とテンプレートの両方の定義で使用できます。
-
Firstタグ
First標準置換タグは、
config/MakeLDIF/first.namesファイルから取得された名前で置換されます。名前と姓の組合せが常に一意になるなど、<first>タグと<last>タグの間には特別な関係があります。名前ファイルと姓ファイルからの考えられる組合せをすべて使用し尽した場合、make-ldifによって、整数値が姓に追加され、値は確実に常に一意になります。<first>タグは、引数を取りません。これは、テンプレート定義内でのみ使用できます。分岐定義で使用することはできません。 -
GUIDタグ
GUID標準置換タグは、ランダムに生成されたGUID (globally-unique identifier)値で置換されます。生成されたすべてのGUID値は、一意になります。生成される値は、それぞれ8、4、4、4および12桁からなるダッシュで区切られたグループに分かれている32桁の16進数です(たとえば、
12345678-90ab-cdef-1234-567890abcdef)。<guid>タグは、引数を取りません。これは、分岐とテンプレートの両方の定義で使用できます。 -
IfAbsentタグ
IfAbsent標準置換タグは、それ自体の値は生成せず、したがって、常に空の文字列で置換されます。ただし、その値によって、指定した属性または属性値が存在するかどうかに基づいて、エントリないに属性がまとめて表示されないようにすることができます。
たとえば、次のテンプレートについて考えてみます:
template: example rdnAttr: cn objectClass: top objectClass: untypedObject objectClass: extensibleObject cn: <guid> displayName: <presence:50>{cn} description: <ifabsent:displayName>{cn}この場合、
description属性は、displayName属性が含まれていない場合のみ、生成されるエントリに含まれます(つまり、結果のエントリには、displayNameとdescriptionのいずれかのみが含まれ、両方が含まれることはありません)。IfAbsentタグには、1つまたは2つの引数が必要です。最初の引数は、ターゲット属性の名前です。2番目の引数がある場合、それはターゲット属性に対して特定の値を指定します。値が指定されている場合、生成されるエントリにその値が含まれていると、IfAbsentタグがアクションを実行します。このタグは、分岐とテンプレートの両方の定義で使用できます。
-
IfPresentタグ
IfPresent標準置換タグは、それ自体の値は生成せず、したがって、常に空の文字列で置換されます。ただし、その値によって、指定した属性または属性値が存在するかどうかに基づいて、エントリないに属性がまとめて表示されないようにすることができます。たとえば、次のテンプレートについて考えてみます:
template: example rdnAttr: cn objectClass: top objectClass: untypedObject objectClass: extensibleObject cn: <guid> displayName: <presence:50>{cn} description: <ifpresent:displayName>{cn}この場合、
description属性は、displayName属性も含まれている場合のみ、生成されるエントリに含まれます(つまり、結果のエントリには、どちらの属性も含まれないか、両方の属性が含まれるかのいずれかになります)。IfPresentタグには、1つまたは2つの引数が必要です。最初の引数は、ターゲット属性の名前です。2番目の引数がある場合、それはターゲット属性に対して特定の値を指定します。値が指定されている場合、生成されるエントリにその値が含まれているときにのみ、IfPresentタグは機能します。このタグは、分岐とテンプレートの両方の定義で使用できます。
-
Lastタグ
Last標準置換タグは、config/MakeLDIF/last.namesファイルから取得された姓で置換されます。名前と姓の組合せが常に一意になるなど、<first>タグと<last>タグの間には特別な関係があります。名前ファイルと姓ファイルからの考えられる組合せをすべて使用し尽した場合、make-ldifによって、整数値が姓に追加され、値は確実に常に一意になります。<last>タグは、引数を取りません。これは、テンプレート定義内でのみ使用できます。分岐定義で使用することはできません。 -
Listタグ
List標準置換タグは、指定されている値のリストから選択された文字列で置換されます。使用される値は、Listタグの引数として指定する必要があります(少なくとも1つの引数を指定する必要があります)。オプションで、各値の後にセミコロンと、その値の相対的な重みを指定する整数値を続けることができます。値に重みが含まれていない場合、そのアイテムの重みは1と想定されます。重みは、それに関連する値がリスト内の他のすべての値と比較して選択される頻度を制御するために使用します。
たとえば、リストされているすべての色が同じ重みを持つ赤、緑、青の色のリストを選択するには、次のものを使用できます:
<list:red:green:blue>
赤い色を、他のいずれの色に対しても2倍の頻度で表示する場合は、次のものを使用できます:
<list:red;2:green;1:blue;1>
この場合、greenとblueの要素の後の
1は、技術的には不要です。それは、重みを明示的に含まないアイテムの重みは1であるためですが、この例では明確にするために指定されています。このタグは、分岐とテンプレートの両方の定義で使用できます。
-
ParentDNタグ
ParentDN標準置換タグは、生成されるエントリの親エントリのDNで置換されます。これは常に使用可能です。このタグは、引数を取りません。これは、テンプレート定義内でのみ使用できます。これは分岐定義では使用できません。
-
Presenceタグ
Presence標準置換タグは、それ自体の値は生成せず、したがって、常に空の文字列で置換されます。ただし、その値は、関連付けられた属性を、指定した割合でエントリに表示するために使用できます。たとえば、次のテンプレートについて考えてみます:
template: example rdnAttr: cn objectClass: top objectClass: untypedObject objectClass: extensibleObject cn: <guid> displayName: <presence:50>{cn}この場合、
displayName属性が存在するのは、生成されるエントリの約50%のみになります。Presenceタグには、1つの引数が必要であり、それは0と100の間の整数値で、関連する属性を持つエントリの割合を示します。このタグは、分岐とテンプレートの両方の定義で使用できます。
-
Randomタグ
Random標準置換タグは、ランダムに生成された値で置換されます。多くの異なるタイプの値を生成できます。このタグが取る引数の個数は可変ですが、最初の引数は、常に、生成する値のタイプを指定します。そのタイプは、次の値の1つにすることができます:-
alpha。この値により、タグは、指定された数の小文字のASCII英文字(つまり、文字セット
abcdefghijklmnopqrstuvwxyz)で置換されます。これには、もう1つの引数が必要であり、それは生成される値に含まれる文字の数を指定する整数です。たとえば、<random:alpha:5>では、ランダムに選択された5つの英文字からなる文字列が生成されます。 -
numeric。これにより、タグは、1つ以上の桁の数字で置換されます。1つまたは2つの追加の引数を指定できます。追加の引数が1つである場合、それは、その値に含まれる数字の桁数を指定します(たとえば、
<random:numeric:5>では、5桁の数字の文字列が生成されます)。追加の引数が2つある場合、それらはランダムに生成される数の上限と下限を指定します(たとえば、<random:numeric:5:10>では、5から10までの間でランダムな整数が生成されます)。 -
alphanumeric。これにより、タグは、指定された数の小文字のASCII英文字(つまり、文字セット
abcdefghijklmnopqrstuvwxyz)または数値(つまり、文字セット0123456789)、あるいはその両方で置換されます。これには、もう1つの引数が必要であり、それは生成される値に含まれる文字の数を指定する整数です。たとえば、<random:alphanumeric:5>では、ランダムに選択された英数字からなる文字列が生成されます。 -
chars。これにより、タグは、ユーザー定義の文字セットの文字で置換されます。これは、2つまたは3つの追加の引数を取ることができます。最初の追加の引数は、ユーザー定義の文字セットの文字です。文字セットの後に1つの引数がある場合、それは、そのセットから取得する文字の数を指定します(たとえば、
<random:chars:abcd:3>では、3つの文字が選択され、それらの文字はa、b、cまたはdのいずれかです)。文字セットの後に2つの引数がある場合、生成される文字の数はこの範囲内の整数になります(たとえば、<random:chars:abcd:3:5>では、その値に3から5個の文字が含められ、各文字はa、b、cまたはdのいずれかです)。 -
hex。これにより、タグは、指定された数の16進文字で置換されます(つまり、文字セット
0123456789abcdef)。これには、もう1つの引数が必要であり、それは生成される値に含まれる文字の数を指定する整数です。たとえば、<random:hex:5>では、ランダムに選択された5つの16進文字からなる文字列が生成されます。 -
base64.これにより、タグは、指定された数のbase64文字セットで許可される文字で置換されます(
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz01234567890+/)。これには、もう1つの引数が必要であり、それは生成される値に含まれる文字の数を指定する整数です。たとえば、<random:base64:5>では、ランダムに選択された5つの16進文字からなる文字列が生成されます。 -
month。これにより、タグは、1年間のうちのいずれかの月の名前で置換されます。追加の引数がない場合、月の完全な名前が含められます(たとえば、
<random:month>では、Octoberの値が返されます)。追加の引数が1つある場合、それは月の名前から含める文字の最大数を指定する整数値である必要があります(たとえば、<random:month:3>では、Octの値が生成されます)。 -
telephone。これにより、タグは、123-456-7890の形式のランダムに生成された電話番号で置換されます。これは、追加の引数を取りません(つまり、常に
<random:telephone>のように使用されます)。
このタグは、分岐とテンプレートの両方の定義で使用できます。
-
-
RDNタグ
RDN標準置換タグは、現在のエントリであるRDN(つまり、左端のDNコンポーネント)で置換されます。そのRDNがまだ使用できない場合(生成されるエントリではRDN属性に値が割り当てられていないためなど)、それが空の文字列で置換されます。通常、このタグが使用される前に、先にテンプレート内ですべてのRDN属性に必ず値が割り当てられるようにします。このタグの動作は、値が1である1つの引数を使用して使用されている場合(つまり、<dn:1>)のDNタグの動作と同一です。RDNタグは、引数を取りません。これは、分岐とテンプレートの両方の定義で使用できます。 -
Sequentialタグ
Sequential標準置換タグは、1つの整数値で置換されます。各エントリには、連続して増加する値が指定されます(たとえば、最初のエントリにはゼロの値、次のエントリには1の値などのように指定されます)。このタグは、ゼロ、1または2個の引数を取ることができます:
-
引数がない(つまり、タグが
<sequential>である)場合、最初の値はゼロになり、その値は新しい分岐ごとにゼロにリセットされます。 -
追加の引数が1つある場合、それは、使用する初期値を指定する整数値である必要があります(たとえば、
<sequential:1000>では、0のかわりに1000から値の生成を開始します)。値は、新しい分岐ごとに、指定した初期値にリセットされます。 -
引数が2つある場合は、最初のものは初期値を指定する整数であり、2番目のものは新しい分岐が始まるたびにカウンタをリセットするかどうかを示す
trueまたはfalseのブール値である必要があります。
このタグは、分岐とテンプレートの両方の定義で使用できます。
-
-
_DNタグ
_DN(先頭のアンダースコア文字に注意)標準置換タグは、生成されるエントリのDNで置換されますが、DNコンポーネント間ではカンマのかわりにアンダースコアが使用されます。カンマのかわりにアンダースコアを使用することを除けば、これは、DNタグとまったく同じように動作します。したがって、左から(値が負の場合は右から)、含めるコンポーネントの数を指定するオプションの整数引数も取ることができます。このタグは、分岐とテンプレートの両方の定義で使用できます。
-
_ParentDNタグ
_ParentDN(先頭のアンダースコア文字に注意)標準置換タグは、生成されるエントリの親エントリのDNで置換されますが、DNコンポーネント間ではカンマのかわりにアンダースコアが使用されます。これは常に使用可能です。このタグは、引数を取りません。これは、テンプレート定義内でのみ使用できます。これは分岐定義では使用できません。
18.1.4.2.2 属性値参照タグの使用
属性値参照タグは、同じエントリの指定した属性の値で、そのタグを置換するために使用できます。それは、目的の属性の名前を中カッコで囲むことによって使用されます。たとえば、{cn}は、ターゲット・エントリですでにcn属性に値が指定されている場合は、その値で置換されます。エントリでターゲット属性にまだ値が割り当てられていない場合、それは空の文字列で置換されます。
たとえば、テンプレートからの次の抜粋について考えてみます:
givenName: <first>
sn: <last>
uid: {givenName}.{sn}
cn: {givenName} {sn}
mail: {uid}@example.com
最初の名前に対して選択された値がJohnであり、最後の名前がDoeである場合、結果のLDIF出力は次のようになります:
givenName: John sn: Doe uid: John.Doe cn: John Doe mail: John.Doe@example.com
属性名の後にコロンを配置し、その後に、ターゲット属性から含める文字の最大数を指定する正の整数値を続けることもできます。たとえば、次のテンプレートの抜粋の場合:
givenName: <first>
sn: <last>
initials: {givenName:1}{sn:1}
次のLDIFが生成されます:
givenName: John sn: Doe initials: JD
指定した長さが、指定した属性の値よりも長い場合、埋込みが追加されることなく、その値全体が使用されます。それ以外の場合、指定した個数の文字がその値から取得されます。
18.1.4.3 カスタム・タグの定義
make-ldifユーティリティは、拡張可能に設計されているため、新しいタグをテンプレート・ファイル内で定義および使用できます。
すべてのタグは、org.opends.server.tools.makeldif.Tag抽象クラスのサブクラスであることが必要です。
make-ldifで使用可能なタグはすべて、org.opends.server.tools.makeldifパッケージに含められています。それらは、カスタム・タグの実相に何が関与しているのかを把握するための参照に使用できます。
ノート:
カスタム・タグを定義する場合、それを必要とする可能性があるテンプレート・ファイルで使用できるようになっているいことを確認してください。これは、include文を使用して実行され、それはテンプレート・ファイルの先頭に配置する必要があります。詳細は、「カスタム・タグのインクルードの理解」を参照してください。
カスタム・タグ定義には、次のメソッドを含める必要があります:
| メソッド | 説明 |
|---|---|
|
public String getName() |
これにより、タグを参照するために使用する名前が取得されます。それが返す値は、サーバーによって使用される他のすべてのタグの間で一意である必要があります。 |
|
public boolean allowedInBranch() |
これは、そのタグが分岐定義で許可されるかどうかを示します。それが |
|
public void initializeForBranch(TemplateFile templateFile, Branch branch, String[] arguments, int lineNumber, List<String> warnings) |
これは、タグが分岐定義で使用される場合に必要な初期化を実行します。 |
|
public void initializeForTemplate(TemplateFile templateFile, Template template, String[] arguments, int lineNumber, List<String> warnings) |
これは、タグがテンプレート定義で使用される場合に必要な初期化を実行します。 |
|
public void initializeForParent(TemplateEntry parentEntry) |
これは、新しい親の下でのエントリの生成を開始する前に必要な初期化を実行します。特別な初期化が不要な場合、これを実装する必要はありません。 |
|
public TagResult generateValue(TemplateEntry templateEntry, TemplateValue templateValue) |
これは、エントリを生成するときに、関連付けられたタグを置換するために使用される値を生成します。 |
18.2 大規模データ・セットのインポート
ディレクトリ・サーバーに大規模データ・セットをインポートするときのパフォーマンスの向上について、このトピックで理解します。デフォルトでは、サーバーは、固定したセットのパラメータでデータをインポートします。
デフォルトの動作を変更するには、次の2通りがあります:
-
import-ldifコマンドを実行する際は、特定のオプションを指定します。詳細は、「インポート・オプション設定について」を参照してください。
-
import-ldifコマンドを実行する前に、dsjavapropertiesコマンドを使用して、適切なJava引数を設定します。詳細は、「JVMおよびJava引数のチューニング」を参照してください。
18.2.1 インポート・オプション設定について
import-ldifコマンドには、特に大規模なデータベースをインポートする場合に役立つ様々なオプションがあります。このトピックでは、それらのオプションをリストして説明します。
それらを次に示します。import-ldifコマンドの次のオプションは、特に大規模なデータベースをインポートする場合に役立ちます。
-
--skipDNValidationこのオプションでは、インポートの最初のフェーズでDNの検証もデータベースのロードも実行されないため、大量のインポートが大幅に高速化されます。LDIFファイルのDNは、通常の索引として処理され、インポートのフェーズ2でロードされるスクラッチ索引ファイルに書き込まれます。
インポートの2番目のフェーズ中に、限られたDN親チェックが実行されます。この評価中に、LDIFファイル内のDNが調べられ、各DNが適切な親DNを持っていることが確認されます。親のないDNが検出された場合、ダミーのエントリが拒否ファイルに書き込まれます。
--skipDNValidationオプションが指定されている場合、重複したDNのチェックは実行されません。インポートのフェーズ2中に索引データベースから不適切なエントリIDがサーバーによって削除されることはありません。したがって、
--skipDNValidationオプションが指定されている場合は、そのLDIFインポート・ファイルが適切であることが不可欠です。通常、適切なLDIFファイルは、make-ldifコマンド、LDAPサーバーからエクスポートされたLDIFファイル、または適切なLDIFを生成することが履歴からわかっているスクリプトによって作成されたLDIFファイルを使用して生成できます。 -
--threadCountこのオプションでは、より多くのスレッドをインポート・プロセス専用に指定可能にすることで、大量のインポートが高速化されます。デフォルトでは、CPUごとに2つのスレッドがインポート操作に使用されます。
--thread-countを増やすと、LDIFインポートのフェーズ1に必要なバッファ領域も増えます。 -
--tmpDirectoryインポートの最初のフェーズでは、サーバーによってLDIFファイルが解析され、索引レコードがソートされ、レコードが一時ファイルに書き込まれます。デフォルトでは、一時索引ファイルが
intall-dir/import-tmpに書き込まれます。特に大きな索引ファイルをインポートする場合、より大きいディスク領域がある別の場所を指定することもできます。一時索引ファイルに必要な領域の容量は、次の要因に応じて異なります:
-
LDIFファイル内のエントリの数。
-
LDIFファイル内のエントリのサイズ。
索引付けを必要とする属性の数が多いエントリでは、一時ディレクトリの場所およびデータベース・ディレクトリで必要とされる領域が、より多くなります。
-
構成される索引の数。
構成される索引数が多くなるほど、一時ディレクトリの場所およびデータベース・ディレクトリで必要とされるディスク領域が多くなります。部分文字列索引では、処理するために他のタイプの作成よりも多くの一時ディスク領域が必要になります。
-
すべての作成または個々の索引に対して
index-entry-limitを増やすと、より多くのディスク領域が必要になります。これは、特に部分文字列索引の場合に該当します。多数のエントリを含むLDIFファイルをインポートする場合、大半の索引レコードが
index-entry-limitをヒットしないように、すべての部分文字列索引をオフにする必要があります。
-
18.2.2 JVMおよびJava引数のチューニング
JVMヒープのチューニングは、import-ldifコマンドのパフォーマンスに不可欠です。import-ldifコマンドでは、それが必要とするJVMヒープの容量を制限することが試みられますが、多数のエントリをインポートする場合、可能なかぎり多くのJVMヒープをimport-ldifに割り当てる必要があります。
この項では、次の項目について説明します。
18.2.2.1 JVM引数のチューニングの考慮事項
次のJVMチューニングの考慮事項は、import-ldif操作に特定の影響があります:
-
オンライン・インポートの実行では、サーバーが起動されたときに指定されたJVM設定が使用されます。オンライン・インポートを使用することで大きなLDIFファイルをインポートする予定である場合、サーバーを起動するときに追加のJVMヒープを指定する必要があります。一般的に、大きなLDIFファイルをインポートする必要がある場合、最良の選択肢は、オフライン・インポートを実行することです。
-
32ビットのJVMは通常、小規模なLDIFファイル、および大規模なLDIFファイルのほとんどでパフォーマンスが高くなります。
常に、最初にこのJVMを、可能なかぎり大きいヒープを設定して試す必要があります。最小ヒープは2 GBをお薦めします。
-
極端に大きいLDIFファイルでは、エントリのサイズと構成されている索引に応じて、大きなJVMヒープ(4 GBを超える)を設定した64ビットのJVMが必要な場合もあります。
64ビットのJVMは、通常、32ビットのJVMほどパフォーマンスは高くありません。
-
デフォルトのJVMエルゴノミクスでは、いくつかのJVMに対して小さすぎて、パフォーマンスに重大な影響を与えることができます。
ご使用のJVMのデフォルト・エルゴノミクス値をノートにとってください(これらの値はベンダーごとおよびオペレーティング・システムごとに異なります)。
-
レプリケーションを使用している場合、特にオンライン・インポート後に、トポロジの他のレプリカの完全な初期化を実行する予定である場合は、追加のJVMヒープを計画する必要があります。
-
大量のインポートに対しては、パラレル・ガベージ・コレクションを有効化します。
-
並行Mark Sweep (CMS)ガベージ・コレクタを使用します。このオプションを使用すると、JVMにおけるLDAP操作のレスポンス時間を最小化できますが、サーバーの全体的なパフォーマンス(スループット)に若干の影響を与える可能性があります。
18.3 データのバックアップおよびリストア
Oracle Unified Directoryは、様々なリポジトリ・タイプをサポートする拡張可能なフレームワークを提供します。ディレクトリ・サーバーは、そのプライマリ・バックエンドとしてBerkeley DB Java Edition (JE)を使用します。JEバックエンドには、他のデータベースと比較していくつかの利点があります。それは、それが、データ・セット(小さなものから非常に大きなものまで)に対して、ACIDセマンティクスに対する完全なサポートとともに、高性能かつスケーラブルなトランザクショナルBツリー・データベースを提供するためです。また、そのエントリを、エンコードされた形式で格納し、高速かつ効率的なデータ取得のための索引を提供することも可能です。
この項の内容は次のとおりです。
18.3.1 バックアップおよびリストアのプロセスの概要
JEバックエンドにディレクトリ・データを保持するために、Oracle Unified Directoryは、全体バックアップおよび増分バックアップをサポートする効率的なバックアップおよびリストア・ユーティリティを備えています。全体バックアップでは、ディレクトリ・データ・ファイルが、圧縮済アーカイブ・ファイルとして環境に保存されます。増分バックアップでは、前回のバックアップ以降に書き込まれたファイルのみが、前回のバックアップ以降に変更されていないファイルの名前のリストとともに保存され圧縮されます。Oracle Unified Directoryでは、リストアを簡単にするためにバックアップ・バックエンドにそのバックアップ情報が格納されます。
ディレクトリ・サーバー・バックアップは、ローカル・ディスク上またはリモート・ディスク上で、たとえば、ネットワーク接続ストレージ(NAS)で実行できます。ローカルでバックアップを実行する場合、セキュリティ上の理由から、別のマシンまたはファイル・システムにバックアップをコピーして保存します。
データのバックアップとリストアを開始する前に、次の事項を考慮します:
-
ご使用のディレクトリ・サービス・システムに対して実行可能なバックアップおよびリストア戦略を設計する必要があります。たとえば、増分バックアップを毎日実行し、全体バックアップを少なくとも週に1回実行することができます。バックアップ・プロセスおよびリストア可能かどうかを定期的にテストしてください。データをリストアするために、多くの会社では、レプリケートされたサーバーからディレクトリ・サーバーをリストアし、それによって、ディレクトリ・データの最も更新されているコピーが使用されるようにしています。ディレクトリ・データが損傷し(たとえば、エントリが欠落し)、損傷したデータが他のサーバーにレプリケートされた場合には、バックアップ・テープが必要になります。
-
障害時リカバリ計画が策定済であることを確認します。障害時リカバリは、破局的なイベント、データ破損、またはデータの不正操作が発生した場合に必要です。企業は、独自の計画を策定するか、サード・パーティの専門家にその作業をアウトソーシングします。詳細は、「障害時リカバリのためのディレクトリ・サーバーのバックアップ」を参照してください。
-
バックアップを格納する場所が確保されていることを確認します。アーカイブ済データ、構成ディレクトリ、スキーマ・サブディレクトリ、およびご使用のサーバーのインストール・ディレクトリを、1つの場所にまとめて保存します。これらのアイテムはすべて、サーバーをリストアするときに必要です。
18.3.2 データのバックアップ
ディレクトリ・サーバーは、データベースをバックアップするための効率的なコマンド行ユーティリティ(backup)を備えています。backupコマンドは、ただちに実行することも、タスクとしてスケジュールすることもできます。バックアップがスケジュール済の場合、このコマンドは管理コネクタを使用してSSL経由でサーバーにアクセスし、バックアップ・タスクを登録します。接続オプションが指定されていない場合、このコマンドはただちに実行されます。
次の手順は、様々なバックアップ・シナリオにおけるbackupコマンドの使用を示しています。
18.3.2.1 すべてのバックエンドのバックアップ
--backUpAllオプションを使用することで、バックエンドをバックアップできます。
--backUpAllオプションを指定してbackupコマンドを実行した場合、次のランタイム・データはバックアップされないことに注意してください。それ以外のバックエンドはすべてバックアップできます。
adminRoot:cn=admin data
ads-truststore:cn=ads-truststore
backup:cn=backups
monitor:cn=monitor次のコマンドは、スタンドアロン・ディレクトリ・サーバーで実行され、すべてのデータベースをバックアップすることを指定し、バックアップ・ファイルを圧縮し、ファイルを指定した場所に保存します。
$ backup --backUpAll --compress --backupDirectory /tmp/backup
このバックアップ・ディレクトリには、各バックエンドのサブディレクトリが含まれています:
$ ls /tmp/backup ./ ../ config/ schema/ tasks/ userRoot/
backupユーティリティによって、指定したディレクトリにバックアップが書き込まれ、バックアップに関する詳細を示すbackup.infoファイルが作成されます。ディレクトリ・サーバーによって、現在の日付と時刻に基づいたバックアップIDが割り当てられます。独自のIDを作成するには、--backupIDオプションを指定します:
$ ls /tmp/backup/config ./ backup.info ../ config-backup-20070827153501Z
backup.infoファイルには、現行のバックアップに関する詳細情報が含まれます。
$ more /tmp/backup/config/backup.info backend_dn=ds-cfg-backend-id=config,cn=Backends,cn=config backup_id=20070827153501Z backup_date=20070827153511Z incremental=false compressed=true encrypted=false property.archive_file=config-backup-20070827153501Z
18.3.2.2 暗号化および署名付きハッシュを使用したすべてのバックエンドのバックアップ
backupユーティリティは、セキュアなバックアップのために暗号化および署名付きハッシュのサポートを提供しています。暗号化および署名付きハッシュ・オプションを使用するには、オンライン・サーバー・インスタンスへの接続が必要であるため、適切な接続オプションを指定する必要があります。
backupコマンドを実行します。
次のコマンドは、すべてのバックエンドをバックアップし、それらを圧縮し、ハッシュを生成し、ハッシュに署名し、そのデータを暗号化します。
$ backup -h localhost -p 4444 -D "cn=directory manager" -j pwd-file --backUpAll \ -X --compress --hash --signHash --encrypt --backupID 123 \ --backupDirectory /tmp/backup
18.3.2.3 すべてのバックエンドでの増分バックアップの実行
増分バックアップでは、最後のバックアップ(増分または全体)以降に発生した変更のみが保存されます。増分バックアップの主な利点は、全体バックアップと比べてシステムのバックアップが高速であることです。増分バックアップの短所は、各増分バックアップをリストアする必要があり、全体リストアよりも時間と注意が必要なことです。
増分バックアップを実行するには、次のように--incrementalオプションを指定してbackupコマンドを実行します:
$ backup --backUpAll --incremental --compress --backupDirectory /tmp/backup
18.3.2.6 タスクとしてのバックアップのスケジュール
ディレクトリ・サーバーは、バックアップやリストアなどの管理タスクを実行するためにタスク・バックエンドを提供しています。-tまたは--startオプションを使用することで、バックアップまたはリストアの開始時間を指定できます。これらのオプションを指定しない場合、タスクのスケジュール後ただちにユーティリティは終了します。ただちに実行するようにタスクをスケジュールし、タスクのスケジュール後ただちにユーティリティを終了するには、開始時間の値として0を指定します。-tまたは--startオプションを省略すると、ユーティリティは、タスクをただちに実行するようにスケジュールし、タスクの進行状況を追跡し、ログ・メッセージを使用できるように出力し、タスクが完了したときに終了します。
タスク・バックエンドへのアクセスは、管理コネクタを介してSSL経由で提供されます。したがって、バックアップをタスクとしてスケジュールする場合、SSL証明書の信頼方法を指定する必要があります。この例では、バックアップを将来の時刻に実行するようにスケジュールします。-Xオプションは、サーバーによって定義されるすべての証明書を信頼することを指定します。詳細は、「サーバーへの管理トラフィックの管理」を参照してください。
18.3.3 サーバー構成のバックアップについて
ディレクトリ・サーバー・インスタンスのすべての構成設定は、configディレクトリにあるconfig.ldifファイルに保存されます。構成内で変更が適切に認識されるように、config.ldifファイルはディレクトリ・サーバーによって自動的に保存されます。
ファイルは、次の2つの特定の時間に保存されます:
-
起動時。現在の構成がアーカイブされた構成に一致しない場合は、サーバーによって
config.ldifファイルが保存されます。 -
変更時。サーバーがオンラインになっている状態でディレクトリ管理者が
dsconfigユーティリティを使用して構成を変更するたびに、ディレクトリ・サーバーによって、変更前にconfig.ldifファイルが保存されます。
アーカイブされた構成ファイルにはINSTANCE_DIR/OUD/config/archived-configsディレクトリからアクセスできます。このディレクトリによって、各保存済構成ファイルがリストされ、それが.gzファイルとして圧縮され、構成がconfig-timestamp.gzとして保存されます。たとえば、アーカイブ済config.ldifファイルを次のように表示できます:
$ ls config/archived-configs 09/02/2010 03:43 PM 9,045 config-20100819055359Z.gz
18.3.4 障害時リカバリのためのディレクトリ・サーバーのバックアップ
ディレクトリ管理者およびシステム管理者は、自然障害、人為的障害、または破局的な障害が発生した場合の障害時リカバリ計画を策定しておく必要があります。ディレクトリ・サービスが複数の個別のサーバーに分散されている場合、すべてのサーバーを個別にバックアップするか、すべてのディレクトリ・データを中央からバックアップします。
かわりに、バックアップおよびリストア戦略としてレプリケーションを検討してください。レプリケーションは、別のレプリケートされたサーバーからのより高速なリストアおよびより更新されたデータを提供します。詳細は、「レプリケートされたディレクトリ・サーバーの復元の考慮事項」を参照してください。
次の手順では、障害時リカバリのためのディレクトリ・サーバーのバックアップ方法について説明します。
18.3.5 ファイル・システム・スナップショットを使用したデータのバックアップおよびリストア
特定のデプロイメントに対して、ファイル・システム・スナップショット・テクノロジは、従来のバックアップに対する実行可能な代替手段を提供します。Solarisシステムでは、ZFSによって、領域効率がよく、迅速に作成でき、システム間で移植可能なファイル・システム・スナップショットが可能です。データ・センターごとに1つ、または2つ(1つのデータ・センターでサービス全体を実行している場合)の専用ディレクトリ・サーバーを使用している場合は、障害時リカバリ計画の一部としてデータをリストアするために有効かつ冗長なソリューションをデプロイします。
この項では、次の項目について説明します。
18.3.6 データのリストア
restoreユーティリティを使用してデータをリストアできます。restoreユーティリティでは、一度に1つのバックエンドのみリストアできます。リストア・タスクをスケジュールしている場合、または署名またはハッシュされたデータをリストアする場合以外は、リストアする前にディレクトリ・サーバーを停止しておく必要があります。
この項では、次の項目について説明します。
18.3.6.2 増分バックアップからのバックエンドのリストア
通常、システム管理者は、増分バックアップを毎日、全体バックアップを毎週実行します。増分バックアップからのシステムのリストアのほうが時間が長くかかることに注意してください。
18.3.6.3 タスクとしてのリストアのスケジュール
ディレクトリ・サーバーは、バックアップやリストアなどの管理タスクを実行するためにタスク・バックエンドを提供しています。-tまたは--startオプションを使用することで、リストアの開始時間を指定できます。これらのオプションを指定しない場合、タスクのスケジュール後ただちにユーティリティは終了します。ただちに実行するようにタスクをスケジュールし、タスクのスケジュール後ただちにユーティリティを終了するには、開始時間の値として0を指定します。-tまたは--startオプションを省略すると、ユーティリティは、タスクをただちに実行するようにスケジュールし、タスクの進行状況を追跡し、ログ・メッセージを使用できるように出力し、タスクが完了したときに終了します。
タスク・バックエンドへのアクセスは、管理コネクタを使用してSSL経由で提供されます。したがって、リストアをタスクとしてスケジュールする場合、SSL証明書の信頼方法を指定する必要があります。
18.3.6.4 構成ファイルのリストア
場合によっては、障害時リカバリ目的で、または他のイベントのために、別のサーバーに構成を転送するための構成ファイルをリストアする必要があります。一般に、サーバーがオンラインである場合、現在の構成ファイルは、最後にアーカイブした構成ファイルと同一です。ただし、前の日付のものからconfig.ldifファイルをリストアすることを選択できます。
18.3.7 レプリケートされたディレクトリ・サーバーの復元の考慮事項
レプリケートされた環境でバイナリ・リストアを実行するには、レプリケートされたトポロジに応じた特別な注意が必要です。可能な場合は、バックアップからの復元ではなく、ご使用のシステムのレプリケーション・メカニズムを使用することでバックエンドを更新してください。従来のテープによるバックアップと比較して、レプリケーションには明確な利点があります。データのリストアは、テープによるリストアよりも大幅に高速であり、データは、より最新の状態に保たれます。ただし、テープは、依然として、レプリケートされたデータが破損していて、他のサーバーに伝播された場合に必要になります。
レプリケートされたサーバーを復元する場合は、構成ファイルINSTANCE_DIR/OUD/config/config.ldifが、バックアップが実行されときと同一であることを確認します。サーバー・バックエンドを復元する前に、config.ldifファイルを復元します。
古いバックアップをマスター・サーバーに復元することはできません。最新でない可能性があるためです。かわりに、レプリケーション・メカニズムが、マスターを読取り専用に設定することで、他のマスター・サーバーを使用してそのマスターを最新の状態にできるようにします。マスターが同期されたら、それを読取り/書込みにリセットできます。
レプリケートされたサーバーを復元する必要がある場合は、LDIFファイルをインポートすることで、他のレプリケートされたサーバーの1つからサーバーを再初期化します。
大規模データベース(数百万のエントリ)の場合は、1つのサーバーのバイナリ・コピーを作成し、それを他のレプリケートされたサーバー上で復元します。
比較的最近のバックアップ(他のレプリケートされたサーバーの変更ログの内容の最大保持時間よりも古くないもの)がある場合、そのバージョンを使用し、restoreコマンドを使用してデータを復元できます。古いバックアップを復元すると、他のサーバーによって、そのバックアップを保存した後に行われた最近の更新でそのサーバーが更新されます。レプリケーションchangelogDBの詳細は、「既存のレプリケート対象トポロジにあるデータ・セットの変更」を参照してください。
18.4 ディレクトリ・データの検索について
ディレクトリ・サーバーは、検索機能およびフィルタの形式の高性能なルックアップ操作など、LDAPv3対応のコマンド行ツールのスイートを備えています。Oracle Directory Services Managerを使用してディレクトリ・データを検索することもできます。
この項では、ldapsearchコマンド行ユーティリティおよびOracle Unified Directory Services Managerを使用してディレクトリ内のエントリを見つける方法について説明します。
この項では、次の項目について説明します。
18.4.1 ldapsearchコマンドの概要
ldapsearchコマンドでは、検索リクエストを入力し、そこでディレクトリ内のエントリを見つけるためのホスト名、ポート、バインドDNおよびパスワード、さらに検索基準を指定できます。LDAPクライアントが、ディレクトリ・サーバーに対して検索リクエストを実行すると、そのディレクトリ・サーバーへの接続がTCP/IP経由で開きます。その後、クライアントは、指定されたエントリの照合を試みることで、ディレクトリ・サーバーへのbind操作を実行し、それによって実際にクライアントが認証されます。大部分のユーザーは、ディレクトリ管理者や彼ら自身など特定のユーザーとしてバインドすることも、どのユーザーとしてもバインドしないこと(この場合、ディレクトリ・サーバーはそのユーザーが匿名ユーザーとしてバインドしていると想定する)もできます。
ディレクトリ・データへのすべてのアクセスは、接続のバインド方法に基づいているため、ディレクトリ・サーバーによって、クライアントの権限が調べられ、クライアントが特定の検索操作を実行できるかどうかが確認されます。ディレクトリ・サーバーによって、ユーザーのアクセス権が調べられた後、クライアントからディレクトリ・サーバーに一連の検索基準およびオプションで構成された検索リクエストが渡されます。
ディレクトリ・サーバーによって、その検索基準およびオプションに一致するすべてのエントリが検索されます。その後、それによって、標準出力のLDIFテキストの形式でエントリ、DN、および各エントリのすべての属性が返されます。エラーが発生した場合、ディレクトリ・サーバーによって、そのエラーを示すエラー・メッセージが表示されます。最後に、検索操作が完了すると、クライアントによって接続が閉じられます。
18.4.2 ldapsearchの場所と形式について
ldapsearchの場所と形式について学習します。形式の各オプションの目的について理解します。
ldapsearchユーティリティは次の場所にあります:
(UNIX, Linux) INSTANCE_DIR/OUD/bin (Windows) INSTANCE_DIR\OUD\bat
このユーティリティは次の形式です:
ldapsearch optional-options search-filter optional-list-of-attributes
説明:
-
optional-optionsは、コマンド行オプションであり、検索フィルタの前に配置される必要があります。
-
search-filterは、コマンド行またはファイル内で指定されるLDAP検索フィルタです。
-
optional-list-of-attributesは、空白で区切られた属性のリストです。属性のリストは、検索フィルタの後に配置する必要があります。
「ldapsearchの一般的なオプションについて」に、ldapsearchの一般的なオプションに関する詳細な説明があります。
18.4.2.1 ldapsearchの一般的なオプションについて
ldapsearchコマンドには、ディレクトリ内のエントリを検索するための多くのオプションがあります。オプションは、短い形式(たとえば、-b baseDN)でも長い形式(たとえば、--baseDN)でも可能です。ldapsearchとともに使用する最も一般的なコマンド・オプションは、次のとおりです:
-
-h, --hostname address -
検索を実行する必要があるディレクトリ・サーバーのホスト名またはIPアドレスを指定します。これは、IPアドレスまたは解決可能なホスト名です。これを指定しない場合、
localhostのデフォルト値が使用されます。 -
-p, --port port -
ディレクトリ・サーバー・ポートを指定します。これは、
1から65535までの整数値(両端を含む)にする必要があります。これを指定しない場合、389のデフォルト・ポートが使用されます。 -
-b, --baseDN baseDN -
検索操作に使用するベースDNを指定します。
--filenameオプションを使用して複数のフィルタを含むファイルが指定された場合、このベースDNが、すべての検索に対して使用されます。これは必須オプションです。 -
-s, --searchScope scope -
検索操作の範囲を設定します。次のいずれかの値を指定する必要があります:
-
base。--baseDNまたは-bオプションで指定されたエントリのみを検索します。 -
one。--baseDNまたは-bオプションで指定されたエントリおよびその直下の子のみを検索します。 -
subまたはsubordinate。ベースが--baseDNまたは-bオプションで指定されたエントリであるサブツリー全体を検索します。これは、--searchScopeオプションが指定されていない場合のデフォルトです。
-
-
-D, --bindDN bindDN -
簡易認証を使用してディレクトリ・サーバーにバインドするときに使用するDNを指定します。このオプションは、SASL認証または匿名バインドを使用する場合は不要です。
-
-w, --bindPassword bindPassword -
ディレクトリ・サーバーにバインドするときに使用するパスワードを指定します。このオプションは、簡易認証の場合、およびCRAM-MD5、DIGEST-MD5、PLAINなどのパスワードベースのSASLメカニズムの場合に使用します。匿名バインドを使用する場合は、不要です。このオプションは、
--bindPasswordFileオプションとともに使用できません。パスワードの入力を要求するには、-w -を入力します。 -
-l, --timeLimit numSeconds -
ディレクトリ・サーバーが検索リクエストの処理に費やす時間の最大の長さを秒単位で設定します。これを指定しない場合、クライアントによって適用される時間制限はありません。
ノート:
ディレクトリ・サーバーによって適用される時間制限が、クライアントによって要求されるものよりも短い場合があります。
-
-z, --sizeLimit numEntries -
ディレクトリ・サーバーがクライアントに返す一致エントリの最大数を設定します。これを指定しない場合、クライアントによって適用される最大サイズはありません。
ノート:
ディレクトリ・サーバーでは、クライアントにより要求されるサイズ限度よりも低い限度を施行することができます。
-
-S, --sortOrder sortOrder -
結果をクライアントに返す前に、それらをソートします。ソート順はソート・キーのカンマ区切りリストであり、各ソート・キーは次の要素で構成されます:
-
+/- (プラスまたはマイナス記号)。ソートを昇順にするのか(+)降順にするのか(-)を指定します。この値を省略すると、デフォルトではソートで昇順が使用されます。 -
Attribute name.データをソートする属性の名前。この要素は必須です。 -
NameまたはOID Matching Rule。オプションのコロンの後に、ソートの実行に使用する一致ルールの名前またはOIDが続きます。これを指定しない場合、指定した属性タイプのデフォルトの順序付け一致ルールが使用されます。たとえば、ソート順序文字列
sn,givenNameでは、最初にsnによって、次にgivenNameによって昇順でエントリがソートされます。かわりに、-modifyTimestampを使用すると、ディレクトリ・サーバーによって、最新の値を持つものが最初になるようにmodifyTimestamp属性がソートされます。
-
18.4.3 検索基準の理解
検索基準および様々なフィルタ・オプションについて学習します。
この項では、次の項目について説明します。
18.4.3.1 検索基準の概要
ldapsearchコマンドには、ディレクトリ情報ツリー内のどこで何を検索するのかを指定する次の3つのセットの情報が必要です:
-
ベースDN。ベースDNを指定することで、検索を実行するディレクトリの最上位識別名(DN)または開始店を定義します。すべての検索は、範囲に応じてベースDNから、またその下からツリーの下に向かって開始され、上に向かって進むことはありません。ベースDNの例としては、
dc=example,dc=comおよびou=People,dc=example,dc=comがあります。 -
範囲。範囲によって、検索フィルタによってベースDNのエントリとその下のエントリのどちらのセットを評価するのかが決まります。検索範囲およびベースDNは、ともに、ディレクトリのないのエントリを検索する場所を示します。
-
検索フィルタ。検索フィルタは、クライアントに返されるエントリが満たす必要がある条件を指定します。
18.4.3.2 検索フィルタのタイプと演算子の指定
ディレクトリ・サーバーは、LDAPプロトコルで定義されている7つのタイプの検索フィルタを備えています。検索フィルタ・タイプごとに、attributeとvalueの2つのエンティティ間の関係をテストする演算子を使用します。
次の表は、検索問合せにおいて特定のエントリを返すための検索フィルタの使用方法を示しています。
| 検索フィルタ | 演算子 | 説明 |
|---|---|---|
|
プレゼンス |
|
指定された属性と関連する値を持つすべてのエントリを返します。このフィルタでは、ワイルドカード文字を使用して、文字列内のゼロ個以上の文字を示します。たとえば、フィルタ ノート: LDAPプロトコルでは、フィルタは、引用符に囲まれたカッコも含めて"(filter)"の形式を持つと指定されています。大部分のディレクトリ・サーバーでは、カッコと引用符がないフィルタを受け入れますが、それらを含めることをお薦めします。 |
|
等価 |
|
指定された値に等しい属性を含むエントリを返します。たとえば、 ノート: |
|
部分文字列 |
|
指定した部分文字列または部分的な部分文字列を含む属性を持つエントリが返されます。このフィルタでは、ワイルドカード文字を使用して、文字列内のゼロ個以上の文字を示します。
|
|
以上 |
|
指定された値以上の属性を含むエントリを返します。たとえば、 |
|
以下 |
|
指定された値以下の属性を含むエントリを返します。たとえば、 |
|
近似 |
|
検索フィルタに指定されている値にほぼ等しい値を持つ指定された属性を含むエントリを返します。たとえば、 |
|
拡張可能一致 |
|
指定した一致ルールで属性がその値に等しい場合、結果のエントリを返します。LDAPバージョン3では、特定の属性に対する一致演算子およびルールを作成できます。一致ルールによって、特定の構文と属性値を比較する方法が定義されます。つまり、拡張可能検索フィルタでは、一致ルールを検索フィルタに追加できます。たとえば、 |
18.4.3.3 複合検索フィルタの評価
次のように演算子を使用することで、複数の検索フィルタ・コンポーネントを結合し、評価できます:
(Boolean-Operator(filter)(filter)(filter))
ブール演算子を結合し、ネストして、複合式を形成できます:
(Boolean-Operator(filter)(Boolean-operator(filter)(filter)))
次の表で、ブール演算子について説明します。
| 検索フィルタ | 演算子 | 説明 |
|---|---|---|
|
AND |
|
文がtrueになるためには、指定されているすべてのフィルタがtrueである必要があります。たとえば、 |
|
OR |
|
文がtrueになるためには、指定されているフィルタの少なくとも1つがtrueである必要があります。たとえば、 |
|
NOT |
|
文がtrueになるためには、指定されているフィルタがtrueでない必要があります。たとえば、 |
18.4.3.4 検索フィルタでのUTF-8エンコードの使用方法
UTF8は、Unicodeのバイト順の可変長文字コードであり、ASCIIのサブセットです。7ビットのASCII文字を、1バイトのUTF-8エンコーディングで置き換えることで複数言語サポートにUTF-8を使用します。通常、UTF-8エンコーディングは1つの円記号でエスケープする必要があります。
たとえば、文字éのUTF-8表記はc3a9であり、èのUTF-8表記はc3a8です。UTF-8エンコーディングは、エスケープ円記号で表されます。したがって、éは\\c3\\a9として、èは\\c3\\a8として表されます。cn=Hélène Laurentを表すには、次のエンコーディングを使用します:
(cn=H\\c3\\a9l\\c3\\a8ne Laurent)
18.4.3.5 検索フィルタの特殊文字
特殊文字(たとえば、空白、円記号、アスタリスク、カンマ、ピリオドなど)は、エスケープ円記号を使用することで指定する必要があります。
-
アスタリスク。アスタリスク(
*)は、\\2aとして表します。たとえば、Five*Starは"(cn=Five\\2aStar)"として表されます。 -
円記号。円記号(
\)は、\\5cとして表します。たとえば、c:\\fileは"(cn=c:\\5c\\5cfile)"として表されます。 -
カッコ。カッコ
()は、それぞれ\\28および\\29として表されます。たとえば、John Doe (II)は"(cn=John Doe \\28II\\29)"として表されます。 -
NULL。NULLは、
\\00として表されます。たとえば、0001は"(bin=\\00\\00\\00\\01)"として表されます。 -
カンマ。カンマ(
,)は、それを\\,のようにエスケープすることで表します。たとえば、"(cn=Mkt\\,Peru,dc=example,dc=com)"のようになります。 -
空白。通常、空白を含む文字列は引用符を使用して囲みます。たとえば、
(cn="HR Managers,ou=Groups,dc=example,dc=com")のようになります。
18.4.4 ldapsearchコマンドの使用
ldapsearchコマンドを使用して、特定のユーザー属性を検索し、様々な範囲での検索を実行し、属性およびエントリを返すことができます。次のトピックでは、ldapsearchコマンドの使用方法について学習します。
この項には、ldapsearchコマンドの使用について説明する次のトピックがあります。
18.4.4.1 ldapsearchコマンドのオプションについて
次の例は、各種検索オプションを指定したldapsearchコマンドの使用を示しています。これらの例はすべて、現行作業ディレクトリがINSTANCE_DIR/OUD/bin (WindowsシステムではINSTANCE_DIR\OUD\bat)であることを想定しています。
次の点は、この項のすべての例に関係しています:
-
例で(
--searchScopeまたは-sオプションで)範囲が指定されていない場合、ldapsearchでは、範囲がsubordinateまたはsubであると想定され、ベースDNのすべてのサブツリーが返されます。 -
属性が指定されていない場合、このコマンドはすべての属性とそれらの値を返します。
-
--bindDNおよび--bindPasswordが指定されていない場合、検索で匿名バインドが使用されます。 -
--hostnameが指定されていない場合、デフォルト(localhost)が使用されます。
ノート:
多くのUNIXおよびLinuxオペレーティング・システムで、/usr/binディレクトリにldapsearch、ldapmodify、ldapdeleteなど一般的なLDAPクライアント・ツールのインストール済バージョンが提供されています。ディレクトリ・サーバーを検索するには、そのディレクトリ・サーバーで提供されているldapsearchを使用する必要があります。次のコマンドを入力することで、ldapsearchのどのバージョンを使用しているのかを調べることができます:
$ which ldapsearch
/usr/bin内のldapsearchを使用する場合は、$PATHの先頭にINSTANCE_DIR/OUD/binを付けます。
18.4.4.2 すべてのエントリを返す
プレゼンス検索フィルタ(objectclass=*)を使用すると指定した分岐DNの下のすべてのエントリを返すことができます。この検索フィルタでは、値を持つ1つ以上のオブジェクト・クラスを持つすべてのエントリが検索されます。すべてのエントリは、いくつかのオブジェクト・クラス定義を持っているため、このフィルタはすべてのエントリが返されることを保証します。
フィルタ(objectclass=*)を指定してldapsearchコマンドを実行します。
$ ldapsearch --hostname localhost --port 1389 --baseDN "dc=example,dc=com" \ "(objectclass=*)" dn: dc=example,dc=com objectClass: domain objectClass: top dc: example dn: ou=Groups,dc=example,dc=com objectClass: organizationalunit objectClass: top ou: Groups dn: cn=Directory Administrators,ou=Groups,dc=example,dc=com objectClass: groupofuniquenames objectClass: top ou: Groups cn: Directory Administrators uniquemember: uid=kvaughan, ou=People, dc=example,dc=com uniquemember: uid=rdaugherty, ou=People, dc=example,dc=com uniquemember: uid=hmiller, ou=People, dc=example,dc=com ...
18.4.4.3 特定のユーザーの検索
等価フィルタを使用して、ディレクトリ内の特定のユーザーを見つけることができます。この例では、Frank Albersという共通名を持つ従業員を見つけます。
フィルタ"(cn=Frank Albers)"を指定してldapsearchコマンドを実行します。
$ ldapsearch --port 1389 --baseDN dc=example,dc=com "(cn=Frank Albers)"
dn: uid=falbers,ou=People,dc=example,dc=com
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: top
givenName: Frank
uid: falbers
cn: Frank Albers
sn: Albers
telephoneNumber: +1 408 555 3094
userPassword: {SSHA}nDTQJ9DDiMUrBwR0WNKq0tgS4iB2A9QJFgpZiA==
roomNumber: 1439
ou: Accounting
ou: People
l: Sunnyvale
mail: falbers@example.com
facsimileTelephoneNumber: +1 408 555 975118.4.4.4 特定のユーザー属性の検索
等価フィルタを使用して、ディレクトリ内のエントリの1つ以上の属性を見つけることができます。検索フィルタの後に1つ以上の属性を配置することによって、それらを指定します。この例では、Frank Albersのユーザー・エントリからtelephoneNumberおよびmail属性を見つけます。
フィルタ"(cn=Frank Albers)"および対応する属性を指定してldapsearchコマンドを実行します。
$ ldapsearch --port 1389 --baseDN dc=example,dc=com \ "(cn=Frank Albers)" telephoneNumber mail dn: uid=falbers,ou=People,dc=example,dc=com telephoneNumber: +1 408 555 3094 mail: falbers@example.com
18.4.4.5 ベース範囲を指定した検索の実行
検索ベースDNとともに指定することで、範囲によって、ディレクトリ情報ツリー(DIT)のどの部分を調べるのかが決まります。ベース範囲では、そのベースDNで指定されたレベルのみ(その子のエントリは除く)が調査されます。ベース範囲は、--searchScope baseオプションまたはその短い形式の同等物である-s baseを使用して指定します。
--searchScope baseオプションを指定して、ldapsearchコマンドを実行します。
$ ldapsearch --hostname localhost --port 1389 --baseDN "dc=example,dc=com" \ --searchScope base "(objectclass=*)" dn: dc=example,dc=com objectClass: domain objectClass: top dc: example
18.4.4.6 1レベル範囲を指定した検索の実行
1レベル範囲では、ベースDNの直下のレベルのみが調査されます。1レベル範囲は、--searchScope oneオプションまたはその短い形式の同等物である-s oneを使用して指定します。これ例では、ベースDNの直下のエントリを表示します。
--searchScope oneオプションを指定して、ldapsearchコマンドを実行します。
$ ldapsearch --hostname localhost --port 1389 --baseDN "dc=example,dc=com" \ --searchScope one "(objectclass=*)" dn: ou=Groups,dc=example,dc=com objectClass: top objectClass: organizationalunit ou: Groups dn: ou=People,dc=example,dc=com objectClass: top objectClass: organizationalunit ou: People dn: ou=Special Users,dc=example,dc=com objectClass: top objectClass: organizationalUnit ou: Special Users description: Special Administrative Accounts dn: ou=Company Servers,dc=example,dc=com objectClass: top objectClass: organizationalUnit ou: Company Servers description: Standard branch for Company Server registration
18.4.4.7 サブツリー範囲を指定した検索の実行
サブツリー範囲では、ベースDNの下のサブツリーとそのベースDNレベルが調査されます。サブツリー範囲は、--searchScope subオプションまたはその短い形式の同等物である-s subを使用して指定します。--searchScopeを指定しない場合、ldapsearchではサブツリー範囲が想定されます。
--searchScope subオプションを指定して、ldapsearchコマンドを実行します。
$ ldapsearch --hostname localhost --port 1389 \ --baseDN "cn=Directory Administrators,ou=Groups,dc=example,dc=com" \ --searchScope sub "(objectclass=*)" dn: cn=HR Managers,ou=groups,dc=example,dc=com objectClass: groupOfUniqueNames objectClass: top ou: groups description: People who can manage HR entries cn: HR Managers uniqueMember: uid=kvaughan, ou=People, dc=example,dc=com uniqueMember: uid=cschmith, ou=People, dc=example,dc=com
18.4.4.8 属性名のみを返す
ldapsearchコマンドは、ディレクトリ内に属性が存在しているかどうかを調べるための便利なオプションを備えています。--typesOnlyオプションまたはその短い形式の同等物である-Aを使用して、ディレクトリ・サーバーに、属性の値を表示しないで属性名を表示することを指示します。
--typesOnlyオプションを指定して、ldapsearchコマンドを実行します。
$ ldapsearch --hostname localhost --port 1389 \ --baseDN "dc=example,dc=com" --typesOnly "(objectclass=*)" dn: dc=example,dc=com objectClass dc dn: ou=Groups,dc=example,dc=com objectClass ou ...
18.4.4.9 ユーザー属性のみを返す
アスタリスク*を含めることで、ldapsearchを使用して、検索フィルタに一致するエントリのユーザー属性のみを返すことができます。ユーザー属性は(操作属性とは異なり)、ディレクトリ内にユーザー情報を格納します。アスタリスクを指定しない場合、デフォルトでユーザー属性が返されます。シェルに対してはアスタリスクを適切にエスケープする必要があります。
検索フィルタの後に'*'を指定してldapsearchコマンドを実行します。
$ ldapsearch --hostname localhost --port 1389 --baseDN "dc=example,dc=com" \ "(objectclass=*)" '*' dn: cn=Aggie Aguirre,ou=People,dc=example,dc=com objectClass: person objectClass: inetorgperson objectClass: organizationalperson objectClass: top postalAddress: Aggie Aguirre$15172 Jackson Street$Salt Lake City, MI 49843 postalCode: 49843 uid: user.99 description: This is the description for Aggie Aguirre. employeeNumber: 99 initials: AGA givenName: Aggie pager: +1 514 297 1830 mobile: +1 030 300 0720 cn: Aggie Aguirre telephoneNumber: +1 730 027 2062 sn: Aguirre street: 15172 Jackson Street homePhone: +1 229 128 3072 mail: user.99@maildomain.net l: Salt Lake City st: MI
18.4.4.10 ベースDNのみを返す
検索フィルタの後に1.1文字列を含めることで、ldapsearchを使用して、検索フィルタに一致するエントリのベースDNのみを返すことができます。
検索フィルタの後に1.1を指定してldapsearchコマンドを実行します。
$ ldapsearch --hostname localhost --port 1389 --baseDN "dc=example,dc=com" \ "(objectclass=*)" 1.1 version: 1 dn: cn=Richard Arnold,ou=people,dc=example,dc=com dn: cn=Kevin Booysen,ou=people,dc=example,dc=com dn: cn=Steven Morris,ou=people,dc=example,dc=com dn: cn=Leila Shakir,ou=people,dc=example,dc=com dn: cn=Emily Smith,ou=people,dc=example,dc=com ...
18.4.4.11 特定のオブジェクト・クラスの検索
特定のオブジェクト・クラスの名前の前に@文字を付けることで、そのオブジェクト・クラスによって属性が参照されるすべてのエントリを検索できます。groupOfUniqueNamesのオブジェクト・クラスを持つすべてのエントリを表示するには、検索フィルタの後に@groupOfUniqueNamesを含めます。
検索フィルタの後に@およびオブジェクト・クラスを指定してldapsearchコマンドを実行します。
$ ldapsearch --hostname localhost --port 1389 \ --baseDN "ou=Groups,dc=example,dc=com" "(objectclass=*)" @groupOfUniqueNames dn: ou=Groups,dc=example,dc=com ou: Groups objectClass: organizationalunit objectClass: top dn: cn=Directory Administrators,ou=Groups,dc=example,dc=com ou: Groups objectClass: groupofuniquenames objectClass: top cn: Directory Administrators uniqueMember: uid=kvaughan, ou=People, dc=example,dc=com uniqueMember: uid=rdaugherty, ou=People, dc=example,dc=com uniqueMember: uid=hmiller, ou=People, dc=example,dc=com ...
18.4.4.12 ディレクトリ内の一致するエントリのカウントを返す
ldapsearchコマンドは、ディレクトリ・サーバーから返された一致するエントリの合計数を返すための--countEntriesを備えています。ディレクトリ・サーバーによって、検索フィルタに一致するすべてのエントリが返され、最後の行に合計数が表示されます。この例では、位置がCincinnatiの従業員のエントリの数を判別します。
--countEntriesオプションを指定して、ldapsearchコマンドを実行します。
$ ldapsearch --hostname localhost --port 1389 --bindDN "cn=Directory Manager" \ --bindPassword password --baseDN dc=example,dc=com --countEntries "l=Cincinnati" dn: cn=Adi Adamski,ou=People,dc=example,dc=com ... l: Cincinnati st: OH dn: Aggi Aguinsky,ou=People,dc=example,dc=com objectClass: person ... l: Cincinnati st: OH # Total number of matching entries: 2
18.4.4.13 複合フィルタを使用した検索の実行
複合検索フィルタには、ブール演算子AND (&)、OR (|)またはNOT (!)を使用する複数のテストが含まれています。ブール演算子とフィルタを組み合せ、ネストして、複合式を作成できます。次の例では、Jensenという名前で、Cupertinoで働いている従業員のすべてのエントリを検索します。このコマンドは2つの結果を返します。
複合検索フィルタを指定してldapsearchコマンドを実行します。
$ ldapsearch --hostname localhost --port 1389 --bindDN "cn=Directory Manager" \ --bindPassword password --baseDN dc=example,dc=com "(&(sn=jensen)(l=Cupertino))" dn: uid=bjensen,ou=People,dc=example,dc=com objectClass: person objectClass: inetOrgPerson objectClass: top objectClass: organizationalPerson ou: Product Development ou: People sn: Jensen ... l: Cupertino st: CA dn: uid=rjensen,ou=People,dc=example,dc=com objectClass: person objectClass: inetOrgPerson objectClass: top objectClass: organizationalPerson ou: Accounting ou: People sn: Jensen ... l: Cupertino st: CA
18.4.4.14 フィルタ・ファイルを使用した検索の実行
--filenameオプションを使用することで、ファイル内に複合または複数のフィルタを配置できます。ファイルに複数のフィルタが含まれている場合は、1行に1つのフィルタが表示されるようにファイルを構成する必要があります。検索は、フィルタ・ファイルに記載されている順序でディレクトリ・サーバーへの同じ接続を使用して実行されます。--filenameオプションを使用する場合、その後のオプションはすべて独立した属性として処理されます。そうでない場合は、最初の後続オプションを検索フィルタにする必要があります。
この例では、Jensenという名前で、Cupertinoで働いていて、かつ会計部門では働いていない従業員のすべてのエントリを検索します。
18.4.4.15 検索で返されるエントリ数の制限
-zまたは--sizeLimitオプションを使用することで、返されるエントリの数を制限できます。エントリの数が、指定されている数を超える場合、検索によって指定された数のエントリが返され、サイズ制限を超えたことを示すエラーが返されます。次の例では、最大5つのエントリが要求されます。
--sizeLimitオプションを指定して、ldapsearchコマンドを実行します。
$ ldapsearch --hostname localhost --port 1389 -b "dc=example,dc=com" \ --sizeLimit 5 "objectclass=*" 1.1 dn: dc=example,dc=com dn: ou=People,dc=example,dc=com dn: uid=user.0,ou=People,dc=example,dc=com dn: uid=user.1,ou=People,dc=example,dc=com dn: uid=user.2,ou=People,dc=example,dc=com SEARCH operation failed Result Code: 4 (Size Limit Exceeded) Additional Information: This search operation has sent the maximum of 5 entries to the client
18.5 拡張検索機能の使用方法
ディレクトリ・サーバーは、ldapsearchコマンドを使用することでLDAPv3対応の検索機能をサポートしています。ご使用のシステム構成に基づいて、検索プロセスで特殊属性、セキュリティ、オプション、およびLDAP制御を使用できます。
この項では、次の項目について説明します。
詳細は、「ディレクトリ・データの検索について」、「サーバー・コマンドによるプロパティ・ファイルの使用方法」および「ldapsearch」を参照してください
18.5.1 特別なエントリおよび属性の検索
操作属性およびルートDSEエントリを検索する方法を学習します。
この項では、次の項目について説明します。
18.5.1.1 操作属性の検索
操作属性は、サーバー自体で処理を行ったり、ディレクトリ・サーバーで管理されている(クライアントから明示的に提供されることのない)その他のデータを保持するために必要な情報を格納する場合に使用されます。操作属性は、検索属性のリストに明示的に含められていない場合は、検索操作から返されるエントリに含まれません。+ (プラス記号)をldapsearchコマンドに追加することで、操作属性を返すようにディレクトリ・サーバーに要求できます。
+文字を指定して、ldapsearchコマンドを実行します。
ご使用のシェルに適した方法で文字をエスケープする必要があります。
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" \ -j pwd-file -b "dc=example,dc=com" "(objectclass=*)" "+" ... dn: cn=PD Managers,ou=groups,dc=example,dc=com numSubordinates: 0 hasSubordinates: false subschemaSubentry: cn=schema entryDN: cn=pd managers,ou=groups,dc=example,dc=com entryUUID: 38666d52-7a53-332e-902f-e34dd4aaa7a0 ...
18.5.1.2 ルートDSEエントリの検索
ルートDSEは、サーバーの名前、ネーミング・コンテキスト、およびサポートされている機能に関する情報を提供する特別なエントリです。属性の多くは操作属性であるため、+ (プラス記号)を指定してルートDSEエントリの属性を表示する必要があります。
""のbaseDNを指定してldapsearchコマンドを実行します。
baseとして範囲を指定し、+文字を含めて、操作属性を表示します。
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" \ -j pwd-file -b "" --searchScope base "(objectclass=*)" "+" dn: supportedExtension: 1.3.6.1.4.1.4203.1.11.3 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 1.3.6.1.4.1.26027.1.6.2 supportedExtension: 1.3.6.1.4.1.26027.1.6.1 supportedExtension: 1.3.6.1.1.8 supportedExtension: 1.3.6.1.4.1.1466.20037 ...
18.5.1.3 ACI属性の検索
ディレクトリ・サーバーでは、アクセス制御命令(ACI)を、エントリのaci属性の1つ以上の値として保存し、そのディレクトリ・データベースへのアクセスを許可または拒否します。aci属性は、ディレクトリ・ユーザーが読取りおよび変更できる複数値操作属性であり、それ自体がACIによって保護される必要があります。管理ユーザーは、通常、aci属性への完全アクセス権を付与され、ldapsearchコマンドを実行することでその値を表示できます。
ldapsearchコマンドを次のように実行します:
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" \ -j pwd-file -b dc=example,dc=com --searchScope base "(aci=*)" aci dn: dc=example,dc=com aci: (target ="ldap:///dc=example,dc=com")(targetattr h3.="userPassword") (version 3.0;acl "Anonymous read-search access";allow (read, search, compare) (userdn = "ldap:///anyone");) aci: (target="ldap:///dc=example,dc=com") (targetattr = "*") (version 3.0; acl "allow all Admin group"; allow(all) groupdn = "ldap:///cn=Directory Administrators,ou=Groups,dc=example,dc=com";)
18.5.1.4 スキーマ・エントリの検索
ディレクトリ・サーバーは、ご使用のインスタンスに対して定義されているオブジェクト・クラスおよび属性のスキーマ情報をスキーマ・エントリ(cn=schema)に保持しています。
cn=schemaベースDNに対してldapsearchコマンドを実行します。
スキーマ内の属性は、操作属性であるため、検索の最後に"+"を含める必要があります。
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" \ -j pwd-file -b cn=schema --searchScope base "(objectclass=*)" "+" dn: cn=schema nameForms: ( 1.3.6.1.1.10.15.1 NAME 'uddiBusinessEntityNameForm' OC uddiBusiness Entity MUST ( uddiBusinessKey ) X-ORIGIN 'RFC 4403' ) nameForms: ( 1.3.6.1.1.10.15.2 NAME 'uddiContactNameForm' OC uddiContact MUST (uddiUUID ) X-ORIGIN 'RFC 4403' ) nameForms: ( 1.3.6.1.1.10.15.3 NAME 'uddiAddressNameForm' OC uddiAddress MUST (uddiUUID ) X-ORIGIN 'RFC 4403' ) ... attributeTypes: ( 1.3.6.1.1.1.1.12 NAME 'memberUid' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'draft-howard-rfc2307bis' ) attributeTypes: ( 1.3.6.1.1.1.1.13 NAME 'memberNisNetgroup' EQUALITY caseExactIA 5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'draft-howard-rfc2307bis' ) attributeTypes: ( 1.3.6.1.1.1.1.14 NAME 'nisNetgroupTriple' DESC 'Netgroup triple' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'draft-howard-rfc2307bis' ) ...
18.5.1.5 構成エントリの検索
ディレクトリ・サーバーは、その構成をcn=configエントリの下に格納します。LDAPを使用したこのエントリへの直接アクセスはお薦めしません。この構成は、dsconfigコマンドを使用してアクセスおよび変更できます。dsconfigコマンドは、管理コネクタを使用してSSL経由でディレクトリ・サーバーに接続します。詳細は、「サーバーへの管理トラフィックの管理」を参照してください。
対話モードでdsconfigを使用して構成エントリを検索するには、次のようにコマンドを実行します:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file
dsconfigを使用したサーバー構成へのアクセスの詳細は、「dsconfigを使用したサーバー構成の管理」を参照してください。
18.5.1.6 モニタリング・エントリの検索
ディレクトリ・サーバーのモニター・エントリcn=monitorは、サーバー・パフォーマンス、状態およびバージョンに関する統計情報を提供します。この情報には、ldapsearchコマンドを使用することでアクセスできます。
任意の構成済LDAP接続ハンドラを使用してcn=monitorにアクセスできますが、管理接尾辞へのすべてのアクセスに管理コネクタを使用することをお薦めします。管理コネクタを使用すると、データのモニタリングが損なわれず、ユーザー・トラフィックよりもサーバー管理が優先されるようになります。管理コネクタを使用するには、管理ポートを指定し、--useSSLオプションを含めます。詳細は、「サーバーへの管理トラフィックの管理」を参照してください。
ベースDNcn=monitorに対してldapsearchコマンドを実行します。
$ ldapsearch -h localhost -p 4444 --useSSL -D "cn=Directory Manager" \ -j pwd-file -b cn=monitor "(objectclass=*)" dn: cn=monitor startTime: 20120119135658Z objectClass: extensibleObject objectClass: top objectClass: ds-monitor-entry cn: monitor vendorName: Oracle Corporation currentTime: 20120125145650Z vendorVersion: Oracle Unified Directory 11.1.2.0.0 maxConnections: 3 productName: Oracle Unified Directory currentConnections: 1 totalConnections: 22 upTime: 6 days 0 hours 59 minutes 52 seconds ...
18.5.2 SSL経由の検索
自己署名証明書または証明書を使用することでSSL接続を受け入れるようにディレクトリ・サーバーを構成した場合、クライアント認証を使用して検索できます。
次の各トピックでは、各種認証メカニズムを使用してSSL経由でディレクトリを検索する方法を示すために手順を説明します。
18.5.2.1 ブラインド信頼を使用したSSL経由の検索
サーバーから提示されたどのような証明書も、自動的に信頼するようにクライアントを構成できます。ただし、この方法は安全ではなく、介在者による攻撃を受けやすくなります。一般的に、このタイプの認証は、テスト目的でのみ使用してください。
--trustAllオプションを指定して、ldapsearchコマンドを実行します。
次のコマンドは、ルートDSEを検索します。
$ ldapsearch -h localhost -p 1636 --useSSL --trustAll -b "" \ --searchScope base "(objectClass=*)"
18.5.2.2 トラスト・ストアを使用したSSL経由の検索
証明書トラスト・ストアを使用するようにクライアントを構成できます。これには、信頼できる証明書に関する情報が含まれています。クライアントは、サーバー証明書を、トラスト・ストアにリストされているものと比べてチェックできます。クライアントによって一致が確認されると、サーバーとの間でセキュアな通信を行えます。一致がない場合、サーバーを信頼できません。提示された証明書が有効であることを確認し、それをトラスト・ストアに追加する必要があります。それによってセキュアな通信が許可されます。
--trustStorePathオプションを指定して、ldapsearchコマンドを実行します。
次のコマンドは、トラスト・ストアを使用してルートDSEを検索します。
$ ldapsearch -h localhost -p 1636 --useSSL \ --trustStorePath /home/scarter/security/cert.db -b "" \ --searchScope base "(objectClass=*)"
18.5.2.3 トラスト・ストアを指定しないSSL経由の検索
トラスト・ストアが指定されていない場合、クライアントに提示された証明書を信頼するかどうかに関するプロンプトが表示されます。
--trustStorePathオプションを指定せずに、ldapsearchコマンドを実行します。
次のコマンドは、トラスト・ストアを使用せずにルートDSEを検索します。
$ ldapsearch -h localhost -p 1636 --useSSL -b "" \ --searchScope base "(objectclass=*)" The server is using the following certificate: Subject DN: CN=example.com, O=Example Corp, C=US Issuer DN: CN=example.com, O=Example Corp, C=US Validity: Fri Mar 02 16:48:17 CST 2007 through Thu May 31 17:48:17 CDT 2007 Do you wish to trust this certificate and continue connecting to the server? Please enter "yes" or "no": yes dn: objectClass: ds-rootDSE objectClass: top
18.5.2.4 キーストアを使用したSSL経由の検索
クライアントがディレクトリ・サーバーに独自の証明書ょ提示する必要がある場合、そのクライアントは、どの証明書キーストアを使用するのか認識している必要があります。クライアントは、--keyStorePasswordまたは--keyStorePasswordFileオプションのいずれかを使用して、--keyStorePathオプションを指定することで証明書キーストアを判別できます。このシナリオは、通常、クライアントがSASL EXTERNAL認証を実行する場合、またはサーバーが常にクライアントに独自の証明書を提示することを要求する場合に発生します。
--keyStore...オプションを指定して、ldapsearchコマンドを実行します。
次のコマンドは、トラスト・ストアおよびキーストアを使用してルートDSEを検索します。
$ ldapsearch -h localhost -p 1636 --useSSL \ --keyStorePath /home/scarter/security/key.db \ --keyStorePasswordFile /home/keystore.pin \ --trustStorePath /home/scarter/security/cert.db --useSASLExternal -b "" \ --searchScope base "(objectClass=*)"
18.5.2.5 StartTLSを使用した検索
ldapsearchユーティリティでStartTLSを使用するプロセスは、SSLを使用するプロセスととてもよく似ています。ただし、次のことを実行する必要があります:
-
サーバーがunencrypted LDAPリクエストをリスニングするポートを使用します。
-
SSLのかわりにStartTLSを使用する必要があることを示します(つまり、
--useSSLオプションのかわりに--startTLSオプションを使用します)。
--startTLSオプションを指定して、ldapsearchコマンドを実行します。
次のコマンドは、startTLSを使用してルートDSEを検索します。
$ ldapsearch -h localhost -p 1389 --startTLS \ -b "" --searchScope base "(objectClass=*)"
18.5.2.6 DIGEST-MD5クライアント認証を利用したSASLを使用した検索
ディレクトリ・サーバーは、いくつかのSimple Authentication and Security Layer (SASL)メカニズムをサポートしています。DIGEST-MD5は、クリアテキスト・パスワードを公開しないサーバーに対するSASL認証の1つの形式です。
適切な--saslOptionオプションを指定して、ldapsearchコマンドを実行します。
authidオプションは、サーバーに認証を受けるユーザーのアイデンティティを指定します。このオプションは、dn (たとえば、dn:uid=scarter,dc=example,dc-com)またはユーザー名(たとえば、authid=u:sam.carter)の形式にすることができます。この属性は、認証後に別のユーザーの認可の下に検索操作を実行する必要があることを示すために使用できます。realmは、サーバー・ホスト・マシンの完全修飾名を指定しますが、省略可能です。
この例では、ルートDSEを検索します。
$ ldapsearch -h localhost -p 1636 --useSSL \ --trustStorePath /home/cert.db --certNickName "my-cert" -w - \ --saslOption mech=DIGEST-MD5 --saslOption realm="example.com" \ --saslOption authid="dn:uid=scarter,dc=example,dc=com" -b "" "(objectclass=*)"
18.5.2.7 GSSAPIメカニズムを利用したSASLを使用した検索
GSSAPIメカニズムはKerberos環境で認証を実行し、クライアント・システムがそのような環境に参加するように構成されていることを必要とします。
有効なKerberosセッションをすでに保持しているユーザーとしてldapsearchコマンドを実行し、検索します。
authid属性は、ユーザーの識別に使用する認証IDを指定します。
この例では、ルートDSEを検索します。
$ ldapsearch -h localhost -p 1389 --saslOption mech=GSSAPI \ --saslOption authid="dn:uid=scarter,dc=example,dc=com" \ --searchScope "" -b "" "(objectclass=*)"
18.5.2.8 PLAINメカニズムを利用したSASLを使用した検索
PLAINメカニズムは、ユーザーが完全なDNではなく認可IDの形式で識別されること以外はLDAP簡易認証に類似した方法で認証を実行します。
有効なKerberosセッションをすでに保持しているユーザーとしてldapsearchコマンドを実行し、検索します。
authid属性は、ユーザーの識別に使用する認証IDを指定します。
この例では、ルートDSEを検索します。
$ ldapsearch -h localhost -p 1389 \ --saslOption mech=PLAIN --saslOption authid="dn:uid=scarter,dc=example,dc=com" \ --searchScope "" -b "" "(objectclass=*)"
18.5.3 制御を使用した検索
LDAP制御は、ldapsearchなどのLDAPコマンドの機能を拡張し、検索結果に対して追加の操作を実行します。各制御は、制御、クリティカル度フラグ、および関連付けられている値を一意に識別するオブジェクト識別子(OID)として定義されます。ディレクトリ・サーバーに制御が送信されるときに、クライアントによってクリティカル度フラグが設定されている場合、そのディレクトリ・サーバーではその制御を使用して操作を実行するか、それを処理しないかのいずれかにする必要があります。フラグがクライアントによって設定されていない場合、ディレクトリ・サーバーでは、その制御を処理できない場合はそれを無視できます。
1つの操作内で、仮想リスト表示とサーバー側ソートなど複数の制御を使用できます。仮想リスト表示制御には、追加の説明が必要なため、それ自体の項で説明します。
この項では、次の項目について説明します。
18.5.3.1 使用可能な制御の表示
supportedControl属性のルートDSEエントリを検索することで、ディレクトリ・サーバーの制御の現在のリストを表示できます。
ルートDSEエントリに対してldapsearchコマンドを実行します。
$ ldapsearch -h localhost -p 1389 -b "" --searchScope base "(objectclass=*)" \ supportedControl dn: supportedControl: 1.2.826.0.1.3344810.2.3 supportedControl: 1.2.840.113556.1.4.1413 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.840.113556.1.4.473 supportedControl: 1.2.840.113556.1.4.805 supportedControl: 1.3.6.1.1.12 supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.4.1.26027.1.5.2 supportedControl: 1.3.6.1.4.1.26027.1.5.5 supportedControl: 1.3.6.1.4.1.26027.1.5.6 supportedControl: 1.3.6.1.4.1.26027.2.3.1 supportedControl: 1.3.6.1.4.1.26027.2.3.2 supportedControl: 1.3.6.1.4.1.42.2.27.8.5.1 supportedControl: 1.3.6.1.4.1.42.2.27.9.5.2 supportedControl: 1.3.6.1.4.1.42.2.27.9.5.8 supportedControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: 1.3.6.1.4.1.4203.1.10.2 supportedControl: 2.16.840.1.113730.3.4.12 supportedControl: 2.16.840.1.113730.3.4.16 supportedControl: 2.16.840.1.113730.3.4.17 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.19 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 2.16.840.1.113730.3.4.3 supportedControl: 2.16.840.1.113730.3.4.4 supportedControl: 2.16.840.1.113730.3.4.5 supportedControl: 2.16.840.1.113730.3.4.9 supportedControl: 2.16.840.1.113894.1.8.21 supportedControl: 2.16.840.1.113894.1.8.31
制御は、OIDのリストとして返されます。
ノート:
これらの制御の一部はldapsearchコマンドで使用できません。それぞれに対応する制御の説明およびサポートされているLDAP制御の詳細は、「サポートされているLDAP制御」を参照してください。
18.5.3.2 結合検索制御を使用した検索
結合検索制御では、1回の検索操作で、友人、マネージャなど関連するエントリ・ツリー・チェーンを取得します。結合制御がターゲットとすることができるのは、相互参照できる(ただし、しなくてもよい)確立された関係を持つエントリ・チェーンのみです。
たとえば、次のエントリは、参加しているエントリそれぞれが他の参加しているエントリにリンクを持つ確立されたfriends関係階層の一部です。この場合、これらのリンクはfriend属性によって形成されます。
dn: uid=user.3,ou=People,dc=example,dc=com objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: top uid: user.3 cn: Kenny McCormick sn: McCormick friend: uid=user.0,ou=People,dc=example,dc=com friend: uid=user.1,ou=People,dc=example,dc=com friend: uid=user.2,ou=People,dc=example,dc=com ...
結合制御を使用する検索操作では、範囲およびフィルタなどの検索パラメータは、その結合検索、つまり結合中に評価されたエントリに適用されます。つまり、一致する結果のみが返されます。この機能によって、1回の検索操作で、特定の検索基準または範囲に基づいて、リンクされた関係階層全体を取得したり、そのサブセットを取得できます。
次のように、近似検索制御OID (1.3.6.1.4.1.26027.2.3.1)とともに--controlまたは-Jオプションを使用することで、ldapsearchコマンドで近似検索制御を指定できます:
OID:criticality:attribute
ここで、attributeは、エントリ間の関係の基になっている属性です。
次の例では、friend属性を介してリンクしているユーザー・エントリのサブセットをリクエストします。
$ ldapsearch -h localhost -p 1389 -D "cn=directory manager" -j pwd-file \ --baseDN "uid=user.3,ou=People,dc=example,dc=com" \ --searchScope sub \ -J "1.3.6.1.4.1.26027.2.3.1:true:friend" \ "(objectClass=person)"
結合検索では、検索パラメータには次のような意味があります:
-
baseDN検索ベースは、結合検索を開始するエントリを指定するために使用します。
-
searchScope検索範囲は、結合の深さの個別のレベルを指定するために使用します。
-
baseの検索範囲は、直接の関係(たとえば、サンプル・エントリではfriend属性によって指定される直接の友人)のみを取得します。 -
oneの検索範囲は、1レベル深くなり、サンプル・エントリの直接の友人の直接の友人を取得します。 -
subの検索範囲は、レベルの数に関係なく階層チェーン全体を横断します。 -
subordinateの検索範囲は、subと同じ効力を持ちますが、検索結果にベース・エントリは含まれません。
-
-
filter検索フィルタは、検索結果に含めるための結合中に、候補のエントリを評価するために使用されます。フィルタは、特定のエントリのみを含めるように検索を絞り込むためにも使用できます。これは、標準検索操作のフィルタと同じですが、結合検索結果にのみ適用できます。
18.5.3.3 近接検索制御を使用した検索
近接検索制御では、検索リクエストでサーバーにベース位置データが提供されます。これによって、サーバーは、位置データを含む近接仮想属性値を候補のエントリすべてに対して生成できます。エントリ内のlocation属性の値は、WGS84標準形式の緯度経度GPS座標です。ユーザー・アプリケーションは、ユーザーの最後の既知の位置で、この属性の値を定期的に更新できます。
たとえば、次の抽出されたエントリは、位置がゴールデン・ゲート・ブリッジの座標に更新されたエントリを示しています:
dn: uid=user.1,ou=People,dc=example,dc=com objectClass: geoObject objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: top objectClass: geoObject uid: user.1 cn: Bob Smith sn: Smith location: 37.81997, -122.47859 ...
サーバーは、近似検索制御で提供されるベースの位置に対する、各エントリの場所の近接度を計算できます。
したがって、クライアント・アプリケーションは、一致する検索結果エントリごとに近似値を計算して返すようにリクエストできます。クライアント・アプリケーションは、検索操作自体の検索フィルタで近似属性を使用でき、したがって、指定されたベースの位置に対するそれらの近接度に基づいて一致する検索結果エントリをリクエストできます。
次のように、近似検索制御OID (1.3.6.1.4.1.26027.2.3.2)とともに--controlまたは-Jオプションを使用することで、ldapsearchコマンドで近似検索制御を指定できます:
OID:criticality:location
ここで、位置は、WGS84標準形式の緯度経度GPS座標を表します。
次の例では、ベース位置をエッフェル塔(48.858844, 2.294351)の座標に設定し、位置がベース位置から500m以内のすべてのユーザー・エントリをリクエストします。
$ ldapsearch -h localhost -p 1389 -D "cn=directory manager" -j pwd-file \ -b "dc=example,dc=com" --searchScope sub \ -J "1.3.6.1.4.1.26027.2.3.2:true:48.858844,2.294351" \ "(&(objectClass=person)(proximity<=500))"
18.5.3.4 アカウント・ユーザビリティ・リクエスト制御を使用した検索
アカウント・ユーザビリティ・リクエスト制御は、ユーザー・アカウントをサーバーから認証を受けるために使用できるかどうかを判別します。ユーザー・アカウントを使用できる場合、その制御によって、アカウントが使用可能であるかどうかに基づいてエントリの前にメッセージが追加されます。
次のようにしてldapsearchとともにアカウント・ユーザビリティ・リクエスト制御を指定できます:
-
OID。アカウント・ユーザビリティ・リクエスト制御OIDの
1.3.6.1.4.1.42.2.27.9.5.8とともに、値を指定しないで--controlまたは-Jオプションを使用します。 -
名前付き定数。アカウント・ユーザビリティ・リクエスト制御OIDのかわりに、名前付き定数
accountusableまたはaccountusabilityを--controlまたは-Jオプションとともに使用します。たとえば、ldapsearchコマンドとともに-J accountusableまたは-J accountusabilityを使用します。
--controlオプションまたはその短い形式である-Jを指定して、ldapsearchコマンドを実行します。
$ ldapsearch -h localhost -p 1389 -b "dc=example,dc=com" \ --searchScope sub -J "accountusability:true" "(objectclass=*)" # Account Usability Response Control # The account is usable dn: dc=example,dc=com objectClass: domain objectClass: top dc: example ...
18.5.3.5 認可アイデンティティ・リクエスト制御を使用した検索
認可アイデンティティ・リクエスト制御によって、クライアントは、LDAPバインド・リクエスト中にクライアント接続のための認可アイデンティティを取得できます。サーバーによって返される認可IDは、認証が完了するとただちにクライアントに表示されます。認可IDを含む行は、前に#文字が付けられ、出力がLDIFとして解釈される場合にコメントになります。
次のようにしてldapsearchに認可アイデンティティ・リクエスト制御を指定します。
-
OID。認可アイデンティティ・リクエスト制御OIDの
2.16.840.1.113730.3.4.16とともに、値を指定しないで--controlまたは-Jオプションを使用します。 -
名前付き定数。認可アイデンティティ・リクエスト制御OIDのかわりに、名前付き定数
authzidまたはauthorizationidentityを--controlまたは-Jオプションとともに使用します。たとえば、ldapsearchコマンドとともに-J authzidまたは-J authorizationidentityを使用します。
--reportAuthzIDオプションを指定して、ldapsearchコマンドを使用します。
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" \ -j pwd-file -b dc=example,dc=com --searchScope base \ --reportAuthzID "(objectclass=*)" # Bound with authorization ID dn:cn=Directory Manager,cn=Root DNs,cn=config dn: dc=example,dc=com objectClass: domain objectClass: top dc: example
18.5.3.6 実効権限取得制御を使用した検索
実効権限取得制御によって、既存または新しいACIを評価でき、指定されたエントリ上のユーザーに付与された実効権限を確認できます。
この制御に対するレスポンスは、検索結果のエントリおよび属性に関する実効権限情報を返すことです。この追加情報としては、各エントリとその中の各属性に対する読取り権限および書込み権限などがあります。権限は、検索に使用するバインドDNまたは任意のDNに対してリクエストできるため、管理者はディレクトリ・ユーザーの権限をテストできます。
ldapsearchコマンドには、次の2つの実効権限取得制御の使用方法があります:
-
-J effectiverightsまたはOID-J "1.3.6.1.4.1.42.2.27.9.5.2"を使用します。リクエストは認可ID (authzid)のみを取ります。認可ID (authzid)にNULL値を指定すると、バインド・ユーザーはauthzidとして使用されます。 -
-g dn:"dn"を使用します。このコマンド・オプションは、指定されたDNとバインドされているユーザーの実効権限を示します。このオプションを-eオプションとともに使用して、指定した属性に対する実効権限を含めることができます。このオプションを使用すると、エントリ内に現在存在しない属性を追加する権限をユーザーが持っているかどうかを判別できます。
ノート:
-Jオプションとともに-gオプションを使用することはできません。
実効権限を表示するには、仮想属性aclRightsおよびaclRightsInfoを指定します。これらは、実効権限リクエストに応答してサーバーによって生成されます。したがって、どのような種類の検索コマンドでもこれらの属性を使用しないでください。
18.5.3.7 LDAPアサーション制御を使用した検索
LDAPアサーション制御によって、検索操作を処理するためにtrueに評価される必要がある条件を指定できます。この制御の値は、LDAP検索フィルタの形式にする必要があります。サーバーによって、検索範囲とフィルタに一致するエントリを検索する前に、ベース・オブジェクトがテストされます。アサーションが失敗すると、エントリは何も返されません。
この例では、最初にアサーションを満たすかどうかを判別し、エントリが検索フィルタに一致する場合はそれを返します。
アサーション(objectclass=top)を使用し、--assertionFilterオプションを指定して、ldapsearchコマンドを実行します。
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ -b "cn=HR Managers,ou=Groups,dc=example,dc=com" \ -s sub \ --assertionFilter "(objectclass=top)" "(objectclass=*)" dn: cn=HR Managers,ou=groups,dc=example,dc=com objectClass: groupOfUniqueNames objectClass: top ou: groups description: People who can manage HR entries uniqueMember: uid=kvaughan, ou=People, dc=example,dc=com uniqueMember: uid=cschmith, ou=People, dc=example,dc=com cn: HR Managers
18.5.3.8 LDAPサブエントリ制御を使用した検索
LDAPサブエントリ制御によって、クライアントは、検索操作中にldapSubEntryオブジェクト・クラスを持つエントリのみがサーバーによって返されることをリクエストできます。LDAPサブエントリは、操作属性に類似した操作オブジェクトであり、それらが明示的にリクエストされた場合にのみ返されます。通常、スキーマを検索する場合はこの制御を使用できます。
次のようにしてldapsearchで、サブエントリを返すようにサーバーにリクエストします:
-
--subEntriesオプションを使用して、LDAPサブエントリ制御を指定します。 -
ベースDNが既知である場合は、ベース検索範囲を指定して特定のサブエントリを取得します。
-
等価フィルタ
(objectclass=ldapSubentry)を使用します。ノート:
等価フィルタの使用は、標準の一部ではなく、後方互換性のためにのみサポートされています。
次のように、--subEntriesオプションを指定して、ldapsearchコマンドを実行します:
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ -b "cn=schema" --subEntries "(objectclass=*)"
18.5.3.9 DSA ITの管理制御を使用した検索
DSA ITの管理制御によって、クライアントは、検索中にサーバーがスマート・リフェラルを通常のエントリとして処理することをリクエストできます。スマート・リフェラルは、別のサーバーまたはディレクトリ情報ツリーDIT内の場所を参照し、そのリフェラルを指定するLDAP URLを含む1つ以上の属性を持つreferralオブジェクト・クラスが含まれているエントリです。
次のようにしてldapsearchにDSA ITの管理制御を指定します。
-
OID。DSA ITの管理制御OIDの
2.16.840.1.113730.3.4.2とともに、値を指定しないで--controlまたは-Jオプションを使用します。 -
名前付き定数。DSA ITの管理制御OIDのかわりに、名前付き定数
managedsaitを--controlまたは-Jオプションとともに使用します。たとえば、ldapsearchコマンドとともに-J managedsaitを使用します。
検索でDSA ITの管理制御を使用するには、次のように-Jオプションを指定してldapsearchコマンドを実行します:
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ -b dc=example,dc=com -J managedsait "(uid=president)" ref dn: uid=president,ou=People,dc=example,dc=com ref: ldap://example.com:389/dc=example,dc=com??sub?(uid=bjensen)
ノート:
-J managedsait引数を指定しないと、このコマンドは、参照先のエントリを返します。
18.5.3.10 一致値フィルタ制御を使用した検索
一致値フィルタ制御によって、クライアントは、Trueに評価される属性値のサブセットをエントリにリクエストできます。この制御によって、ユーザーは、すべての値を取得することなく属性値のサブセットを選択して読み取り、目的のセットをローカルにスキャンできます。
--matchedValuesFilterオプションを指定して、ldapsearchコマンドを実行します。
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ -b ou=groups,dc=example,dc=com --matchedValuesFilter "(uniquemember=uid=kvaughan*)" "(objectclass=*)" dn: ou=Groups,dc=example,dc=com dn: cn=Directory Administrators,ou=Groups,dc=example,dc=com uniqueMember: uid=kvaughan, ou=People, dc=example,dc=com dn: cn=Accounting Managers,ou=groups,dc=example,dc=com dn: cn=HR Managers,ou=groups,dc=example,dc=com uniqueMember: uid=kvaughan, ou=People, dc=example,dc=com dn: cn=QA Managers,ou=groups,dc=example,dc=com dn: cn=PD Managers,ou=groups,dc=example,dc=com
18.5.3.11 パスワード・ポリシー制御を使用した検索
パスワード・ポリシー制御によって、クライアントは、ユーザー・エントリの現在のパスワード・ポリシー情報に関する情報をリクエストできます。
次のようにしてldapsearchにパスワード・ポリシー制御を指定します。
-
OID。パスワード・ポリシー制御OIDの
1.3.6.1.4.1.42.2.27.8.5.1とともに、値を指定しないで--controlまたは-Jオプションを使用します。 -
名前付き定数。パスワード・ポリシー制御OIDのかわりに、名前付き定数
pwpolicyまたはpasswordpolicyを--controlまたは-Jオプションとともに使用します。たとえば、ldapsearchとともに-J pwpolicyまたは-J passwordpolicyを使用します。 -
オプション。
--usePasswordPolicyControlオプションを使用します。
ノート:
-Jまたは--controlオプションは、検索リクエストでどの制御を使用するのかを指定するために使用します。--usePasswordPolicyControlオプションは、バインド・リクエストに使用されます。
--usePasswordPolicyControlオプションを指定して、ldapsearchコマンドを実行します。
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ -b dc=example,dc=com -s base --usePasswordPolicyControl "(objectclass=*)"
18.5.3.12 永続検索制御を使用した検索
永続検索制御によって、クライアントは、追加、削除または変更操作によってディレクトリのエントリが変更されたときに、通知を受け取れます。変更が行われたときに、そのエントリが、エントリ変更通知制御によって使用された検索基準に一致する場合、サーバーによって更新済エントリがクライアントに送信されます。
ldapsearchコマンドには、接続を開いたままにして、変更(追加、削除、変更、またはすべて)が発生するたびにその範囲およびフィルタに一致するエントリを表示する永続検索(-C)を実行するオプションがあります。この検索は、[Ctrl] + [C]を押すことで終了できます。
この引数の値は、ps[[:''changetype''[[:''changesonly''[[:''entrychangecontrols'']]]の形式にする必要があります。
この値の要素には、次のものがあります:
-
ps— 必須演算子。 -
changetype— クライアントが通知の受信を必要とする変更のタイプを指定します。この要素は、add、del、mod、moddnのいずれか、またはすべての変更タイプに登録する場合はallです。また、複数の特定の変更タイプに登録するには、カンマ区切りリストにすることもできます。この要素が指定されない場合、デフォルトとしてall変更タイプが含まれます。 -
changesonly—Trueの場合、クライアントは、その検索が登録された後に一致するエントリに行われた変更のみを通知されます。Falseの場合、サーバーによって、サーバー内の指定された検索基準に一致するすべての既存のエントリも送信されます。この要素が指定されていない場合、デフォルトでは、その検索が登録された後に発生した更新についてのみエントリが返されます。 -
entrychangecontrols—Trueの場合、サーバーは、変更の結果としてクライアントに送信されるエントリ内にエントリ変更通知制御を含めます。Falseの場合、エントリ変更通知制御は含められません。この要素が指定されない場合、デフォルトとしてエントリ変更通知制御が含まれます。
18.5.3.13 プロキシ設定された認可制御を使用した検索
プロキシ設定された認可制御によって、クライアントは、特定の操作に対して別のエントリを偽装できます。この制御は、多数の異なるユーザーのかわりに実行する必要がある信頼できるアプリケーションにおいて役立ち、そのアプリケーションが操作ごとに再度認証を受ける必要がなくなります。
次のように、--proxyAsオプションを指定して、ldapsearchコマンドを実行します:
ここで、プロキシ設定された認可制御を使用するには、サブツリー内でclientAppが適切なACI権限を持っている必要があります。付与されていない場合は、LDAPエラー50「不十分なアクセス権限」がクライアントに返されます。
$ ldapsearch -h localhost -p 1389 \ -D "uid=clientApp,ou=Applications,dc=example,dc=com" -j pwd-file \ -s sub -b dc=example,dc=com \ --proxyAs "dn:uid=acctgAdmin,ou=Administrators,ou=People,dc=example,dc=com" \ "(uid=kvaughan)" mail
18.5.3.14 サーバー側ソート制御を使用した検索
サーバー側ソート制御によって、クライアントは、サーバーが検索結果をクライアントに送信する前にそれらをソートするようにリクエストできます。これは、サーバーに、クライアントによってリクエストされたソート順序をクライアントより速く満たすことができる索引がある場合に便利です。
--sortOrderオプションを使用することで、返されるエントリをソートできます。昇順の+ (プラス記号)または降順の- (マイナス記号)を指定しない場合、デフォルトのオプションは、昇順でのソートです。
18.5.3.15 単純なページングの結果制御を使用した検索
単純なページングの結果制御によって、検索操作で、一度に結果のサブセットのみを返すことができます。検索結果全体を一度に1ページずつ取り出すために使用できます。これは、結果のソートを必要とせず、検索結果全体に順番に繰り返し処理を実行するためにのみ使用できること以外、仮想一覧表示制御に似ています。
--simplePageSizeオプションを指定して、ldapsearchコマンドを使用します。
次のコマンドは、--countEntriesオプションを使用して、各ページをマークします。
$ ldapsearch --hostname localhost --port 1389 \ --bindDN "cn=Directory Manager" --bindPassword password \ --searchScope sub --baseDN dc=example,dc=com \ --simplePageSize 2 --countEntries "(objectclass=*)" dn: ou=Groups,dc=example,dc=com objectClass: organizationalunit objectClass: top ou: Groups dn: ou=People,dc=example,dc=com objectClass: organizationalunit objectClass: top ou: People # Total number of matching entries: 2 dn: ou=Special Users,dc=example,dc=com objectClass: organizationalUnit objectClass: top description: Special Administrative Accounts ou: Special Users dn: ou=Company Servers,dc=example,dc=com objectClass: organizationalUnit objectClass: top description: Standard branch for Company Server registration ou: Company Servers # Total number of matching entries: 2 dn: ou=Contractors,dc=example,dc=com objectClass: organizationalUnit objectClass: top ou: Contractors ou: Product Testing ou: Product Development ou: Accounting # Total number of matching entries: 1
18.5.3.16 仮想リスト表示制御を使用した検索
次の各トピックでは、仮想リスト表示制御を使用して検索する手順について説明します。
18.5.3.16.1 仮想リスト表示制御について
仮想リスト表示制御によって、クライアントは、サーバーにエントリの特定の範囲内で小さい、管理可能なチャンクで検索結果を送信するようにリクエストできます。GUIブラウザまたはアプリケーションで特定のエントリに直接移動するように構成されている場合は、これにより、クライアントは、検索操作の結果内を前後に移動することもできるようになります。
ノート:
仮想リスト表示制御は、返されるエントリのソートが必要です。
--virtualListViewオプションまたはその短い形式である-Gとともに、次の引数を指定します:
-
before。結果に含めるターゲットの前のエントリ数を指定します。
before値がターゲット・オフセット以上である場合は、返される最初のエントリが、リストの先頭になるようにbefore値が調整されます。 -
after。結果に含めるターゲットの後のエントリ数を指定します。
-
index。結果セット内のターゲット・エントリのオフセットを指定します。索引の1は、常に最初のエントリを意味します。
indexとcontent_countが等しい場合、最後のエントリが選択されます。index値が負である場合、サーバーによってリクエストが拒否されます。index値が0である場合、返される値が表示されるようにそれが1に調整されます。index値が、一致する値の合計数よりも大きい場合、その内容の数より1大きいものに調整されます。indexの値は、アサーション値にすることもでき、そのようにすると返されるエントリにその値が含まれます。返されるエントリが、リストの終わりに近すぎて、afterの値が最後のエントリを超える場合は、afterの値が適切なエントリを表示するように調整されます。 -
count。結果セットの予期されるサイズを指定します。
-
count=0。ターゲット・エントリは、指定されたindexの位置にあるエントリで、1から始まり、ソート結果の全体リストに相対しています。この引数は、クライアントが結果セットのサイズを把握していない場合に使用します。
-
count=1。ターゲット・エントリは、ソート結果のリストにある最初のエントリです。
-
count>1。ターゲット・エントリは、index/countの分数で表されるリストの一部の最初のエントリです。リストの最後の結果をターゲットにするには、count引数よりも大きいindex引数を使用します。クライアント・アプリケーションは、ユーザーがスクロール・バーを使用して長いリスト内を移動できるインタフェースを使用できます。たとえば、indexが33で、countが100の場合、アプリケーションは、リストの33パーセント進んだ位置に移動できます。
-
たとえば、引数(0:4:1:0)は、索引1にあるターゲット・エントリの前の0個のエントリと、後の4個のエントリを表示することを示します。クライアントがセットのサイズを把握していない場合、countは0です。
18.5.3.16.2 仮想リスト表示制御を使用した検索
ソート順序オプション(-S)は、仮想リスト表示制御とともに使用する必要があります。この例では、仮想リスト表示制御オプションを使用して、次のように指定します:
-
Before=0。ターゲットの前の0個のエントリを表示することを指定します。
-
After=2。ターゲットの後の2個のエントリを表示することを指定します。
-
Index=1。結果セット内のターゲット・エントリのオフセットを返すことを指定します。
-
Count=0。索引位置にあるターゲット・エントリ(最初のエントリ)を返すことを指定します。
したがって、サーバーによって、最初のエントリと、そのターゲットの後の2個のエントリが、givenName属性で昇順にソートされて返されます。
--virtualListViewオプションを指定して、ldapsearchコマンドを使用します。
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -w bindPassword \ -b dc=example,dc=com --searchScope sub --sortOrder givenName \ --virtualListView "0:2:1:0" "(objectclass=*)" dn: uid=awhite,ou=People,dc=example,dc=com objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: top givenName: Alan uid: awhite cn: Alan White sn: White ... dn: uid=aworrell,ou=People,dc=example,dc=com objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: top givenName: Alan uid: aworrell cn: Alan Worrell sn: Worrell ... dn: uid=alutz,ou=People,dc=example,dc=com objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: top givenName: Alexander uid: alutz cn: Alexander Lutz sn: Lutz ... # VLV Target Offset: 1 # VLV Content Count: 172
18.5.3.16.3 特定のターゲットを指定して仮想リスト表示を使用した検索
ソート順序(-S)オプションを仮想リスト表示とともに使用できます。
この例のコマンドでは、仮想リスト表示制御オプションを使用して、次のように指定します:
-
Before=0。ターゲットの前の0個のエントリを表示することを指定します。
-
After=4。ターゲットの後の4個のエントリを表示することを指定します。
-
Index=jensen。結果セット内の文字列
jensenを返すことを指定します。 -
Count=指定しない。デフォルトの
count=0を使用します。これは最初のエントリです。
したがって、サーバーによって、jensenに一致する最初のsn属性と、そのターゲットの後の4個のsn属性が、sn属性で昇順にソートされて返されます。
--virtualListViewオプションを指定して、ldapsearchコマンドを使用します。
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ -b dc=example,dc=com --searchScope sub --sortOrder sn \ --virtualListView "0:4:jensen" "(objectclass=*)" sn dn: uid=kjensen,ou=People,dc=example,dc=com sn: Jensen dn: uid=bjensen,ou=People,dc=example,dc=com sn: Jensen dn: uid=gjensen,ou=People,dc=example,dc=com sn: Jensen dn: uid=jjensen,ou=People,dc=example,dc=com sn: Jensen dn: uid=ajensen,ou=People,dc=example,dc=com sn: Jensen # VLV Target Offset: 56 # VLV Content Count: 172
18.5.3.16.4 既知の合計を指定して仮想リスト表示を使用した検索
ソート順序(-S)オプションは、仮想リスト表示とともに使用する必要があります。
この例のコマンドでは、仮想リスト表示制御オプションを使用して、次のように指定します:
-
Before=0。ターゲットの前の0個のエントリを表示することを指定します。
-
After=2。ターゲットの後の2個のエントリを表示することを指定します。
-
Index=57。結果セット内の57の索引を返すことを指定します。これは、リストの約1/3です。
-
Count=172。合計カウントを使用します。
したがって、サーバーによって、リスト内の1/3である最初のsn属性と、2個のsn属性が、sn属性で昇順にソートされて返されます。
--virtualListViewオプションを指定して、ldapsearchコマンドを使用します。
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ -b dc=example,dc=com -s sub --sortOrder sn \ --virtualListView "0:2:57:172" "(objectclass=*)" sn dn: uid=bjensen,ou=People,dc=example,dc=com sn: Jensen dn: uid=gjensen,ou=People,dc=example,dc=com sn: Jensen dn: uid=jjensen,ou=People,dc=example,dc=com sn: Jensen # VLV Target Offset: 57 # VLV Content Count: 172
18.5.3.16.5 仮想リスト表示制御への匿名アクセスの許可
デフォルトてば、仮想リスト表示制御へのアクセスは、認証済のユーザーにのみ許可されます。認証されていないユーザーに仮想リスト表示制御へのアクセスを許可するには、仮想リスト表示制御(2.16.840.1.113730.3.4.9)のOIDを、「匿名制御アクセス」グローバルACIに追加し、「認証済ユーザー制御アクセス」グローバルACIから削除する必要があります。
ds-cfg-global-aci: (targetcontrol="2.16.840.1.113730.3.4.2 || 2.16.840.1.113730.3.4.17 || 2.16.840.1.113730.3.4.19 || 1.3.6.1.4.1.4203.1.10.2 || 1.3.6.1.4.1.42.2.27.8.5.1 || 2.16.840.1.113730.3.4.16 || 2.16.840.1.113894.1.8.31") (version 3.0; acl "Anonymous control access"; allow(read) userdn="ldap:///anyone";) ds-cfg-global-aci: (targetcontrol="1.3.6.1.1.12 || 1.3.6.1.1.13.1 || 1.3.6.1.1.13.2 || 1.2.840.113556.1.4.319 || 1.2.826.0.1.3344810.2.3 || 2.16.840.1.113730.3.4.18 || 2.16.840.1.113730.3.4.9 || 1.2.840.113556.1.4.473 || 1.3.6.1.4.1.42.2.27.9.5.9 || 1.2.840.113556.1.4.473") (version 3.0; acl "Authenticated users control access"; allow(read) userdn="ldap:///all";)
これらのグローバルACIを変更する最も簡単な方法は、次のようにOUDSMを使用することです。
- 「OUDSMを使用したサーバーへの接続」の説明に従って、OUDSMからディレクトリ・サーバーに接続します。
- 「セキュリティ」タブを選択します。
- 「ルート」メニューから、匿名制御アクセスを選択します。
- 左側のペインの「ターゲット」表で、「ターゲット制御」フィールドを選択し、「編集」をクリックします。
- 「使用可能なコントロール」リストから、仮想リスト表示制御(2.16.840.1.113730.3.4.9)を選択します。
- 右矢印をクリックして、VLV制御を「選択したコントロール」リストに移動します。
- 「OK」をクリックします。
- 「適用」をクリックして、変更を保存します。
- 「ルート」メニューから、認証済ユーザー制御アクセスを選択します。
- 左側のペインの「ターゲット」表で、「ターゲット制御」フィールドを選択し、「編集」をクリックします。
- 「選択したコントロール」リストから、仮想リスト表示制御(2.16.840.1.113730.3.4.9)を選択します。
- 左矢印をクリックして、VLV制御を「使用可能なコントロール」リストに移動します。
- 「OK」をクリックします。
- 「適用」をクリックして、変更を保存します。
dsconfigを使用してグローバルACIを変更することもできますが、dsconfigでACI値を変更することはできません。かわりに、ACIを削除して再作成する必要があります。詳細は、「デフォルト・グローバルACIについて」を参照してください。
18.5.4 詳細モードでの検索とプロパティ・ファイルを使用した検索
詳細モードでの検索およびプロパティ・ファイルを使用した検索の方法を理解できます。詳細モードはデバッグに便利で、プロパティ・ファイルは様々な構成環境で作業する場合に便利です。
この項では、次の項目について説明します。
18.5.4.1 詳細モードでの検索
詳細モードでは、クライアントとサーバー間で送信されている処理情報が表示されます。このモードはデバッグに便利です。
ldapsearchコマンドを次のように使用します:
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-b dc=example,dc=com -s base --verbose "(objectclass=*)"
LDAP: C>S 01:43:46.140 (0ms) LDAPMessage(msgID=1, protocolOp=BindRequest
(version =3, dn=cn=Directory Manager, password=password))
ASN1: C>S 01:43:46.140 (0ms) ASN.1 Sequence
BER Type: 30
Decoded Values:
ASN1Integer(type=02, value=1)
ASN1Sequence(type=60, values={ ASN1Integer(type=02, value=3),
cn=Directory Manager, opends })
Value:
02 01 01 60 23 02 01 03 04 14 63 6E 3D 64 69 72 `# cn=directory
65 63 74 6F 72 79 20 6D 61 6E 61 67 65 72 80 08 manager
70 61 73 73 77 6F 72 64 password
...18.5.4.2 プロパティ・ファイルを使用した検索
ディレクトリ・サーバーは、ldapsearchコマンドで使用するデフォルト引数値を保持しているプロパティ・ファイルの使用をサポートしています。プロパティ・ファイルは、様々な構成環境、特にスクリプト済アプリケーションまたは埋込みアプリケーションで作業する場合に便利です。詳細は、「サーバー・コマンドによるプロパティ・ファイルの使用方法」を参照してください。
18.5.5 国際化されたエントリの検索
照合ルールの使用、検索の例の理解およびサポートされている照合ルールの使用により、国際化されたエントリを検索できます。
この項では、次の項目について説明します。
18.5.5.1 照合ルールの使用による国際化されたエントリの検索
次の各トピックでは、照合ルールを使用して国際化されたエントリを検索する方法について説明します。
18.5.5.1.1 照合ルールについて
Oracle Unified Directoryでは、エントリと照合して、「サーバー側ソート制御を使用した検索」のように使用して検索結果をソートする照合ルールがサポートされています。この照合ルールは、次に示すように、コロンで区切って、検索フィルタで一致ルールとして指定します:
locale.matchingRule
説明:
-
localeは、次のいずれかの方法で指定します。
-
ロケールOID
-
ロケール文字接尾辞(
ar、en、fr-CAなど)。サポートされているロケール、それらのOIDおよびタグのリストは、「サポートされている照合ルール」を参照してください。
-
-
matchingRuleは、表18-1に示すように、ロケールに追加された数字接尾辞または文字接尾辞のいずれかとして指定できます。
ノート:
ロケールをそのOIDで指定する場合、一致ルールはその数字接尾辞で指定する必要があります。この場合、一致ルールを文字接尾辞で指定することはできません。
表18-1 一致ルール接尾辞
| 一致ルール | 数字接尾辞 | 文字接尾辞 |
|---|---|---|
|
より小さい |
.1 |
.lt |
|
以下 |
.2 |
.lte |
|
等価 |
.3 |
.eq (デフォルト) |
|
以上 |
.4 |
.gte |
|
より大きい |
.5 |
.gt |
|
部分文字列 |
.6 |
.sub |
等価が、デフォルトの一致ルールです。つまり、一致ルール接尾辞が指定されていない場合、照合ルールでは等価一致ルールが使用されます。
18.5.5.1.2 照合ルールの使用の例
次の例は同等であり、英語の照合ルールと等価一致ルールを指定しますが、2番目の例では.eq接尾辞で等価一致ルールを明示的に指定しています。
"cn:en:=sanchez" "cn:en.eq:=sanchez"
次の例では、同じ検索フィルタを示していますが、ロケールの文字接尾辞と一致ルールの数字コードを使用して指定しています:
"cn:en.3:=sanchez"
次の例では、ロケールOIDと一致ルールの数字接尾辞を使用して指定した同じ検索フィルタを示しています:
"cn:1.3.6.1.4.1.42.2.27.9.4.34.1.3:=sanchez"
次の例では、同じ検索フィルタを、スペイン語の照合ルールで指定しています。
"cn:es.eq:=sanchez" "cn:1.3.6.1.4.1.42.2.27.9.4.49.1.3:=sanchez" "cn:es.3:=sanchez"
次の例では、スペイン語の照合ルールでgreater-than一致ルールを使用する同じ検索フィルタを指定しています。
"cn:es.gt:=sanchez" "cn:1.3.6.1.4.1.42.2.27.9.4.49.1.5:=sanchez" "cn:es.5:=sanchez"
18.5.5.2 検索の例の理解
この項では、使用可能な様々な検索について説明します。
-
等価検索
次の検索では、
en(en-US)ロケールOIDを指定したフィルタを使用し、等価検索を実行して、cn値がsanchezのエントリを返します:$ ldapsearch -D "cn=directory manager" -j pwd-file -b "o=test" \ "cn:1.3.6.1.4.1.42.2.27.9.4.34.1:=sanchez"
次のフィルタでは、同じ結果が返されます:
-
"cn:en:=sanchez" -
"cn:en.3:=sanchez" -
"cn:en.eq:=sanchez" -
"cn:1.3.6.1.4.1.42.2.27.9.4.34.1.3:=sanchez"
-
-
より小さい検索
次の検索では、
es(es-ES)ロケールを指定したフィルタを使用し、より小さい検索を実行して、departmentnumber値がabc119のエントリを返します:$ ldapsearch -D "cn=directory manager" -j pwd-file -b "o=test" \ "departmentnumber:1.3.6.1.4.1.42.2.27.9.4.49.1.1:=abc120"
次のフィルタでは、同じ結果が返されます:
-
"departmentnumber:es.1:=abc120" -
"departmentnumber:es.lt:=abc120"
-
-
以下検索
次の検索では、
es(es-ES)ロケールを指定したフィルタを使用し、departmentnumber値がabc119のエントリを返す、以下検索を実行します:$ ldapsearch -D "cn=directory manager" -j pwd-file -b "o=test" \ "departmentnumber:1.3.6.1.4.1.42.2.27.9.4.49.1.2:=abc119"
次のフィルタでは、同じ結果が返されます:
-
"departmentnumber:es.2:=abc119" -
"departmentnumber:es.lte:=abc119"
-
-
以上検索
次の検索では、
fr(fr-FR)ロケールを指定したフィルタを使用し、departmentnumber値がabc119のエントリを返す、以上検索を実行します。$ ldapsearch -D "cn=directory manager" -j pwd-file -b "o=test" \ "departmentnumber:fr.4:=abc119"
次のフィルタでは、同じ結果が返されます:
-
"departmentnumber:1.3.6.1.4.1.42.2.27.9.4.76.1.4:=abc119" -
"departmentnumber:fr.gte:=abc119"
-
-
より大きい検索
次の検索では、
fr(fr-FR)ロケールを指定したフィルタを使用し、より大きい検索を実行します:$ ldapsearch -D "cn=directory manager" -j pwd-file -b "o=test" \ "departmentnumber:fr.5:=abc119"
前述の検索では、departmentnumber値が
abc119のエントリは返されません。次のフィルタでは、同じ結果が返されます:
-
"departmentnumber:1.3.6.1.4.1.42.2.27.9.4.76.1.5:=abc119" -
"departmentnumber:fr.gt:=abc119"
-
-
部分文字列検索
次の検索では、
en(en-US)ロケールを指定したフィルタを使用し、sn値がQuebecのエントリを返す、部分文字列検索を実行します:$ ldapsearch -D "cn=directory manager" -j pwd-file -b "o=test" \ "sn:en.6:=*u*bec"
次のフィルタでは、同じ結果が返されます:
-
"sn:1.3.6.1.4.1.42.2.27.9.4.34.1.6:=*u*bec" -
"sn:en.sub:=*u*bec"
-
18.5.5.3 サポートされている照合ルール
次の表は、Oracle Unified Directoryによってサポートされている国際化ロケールを、文字接尾辞のアルファベット順に示しています。
表18-2 サポートされている照合ルール
| ロケール | 文字接尾辞 | OID |
|---|---|---|
|
アラビア語 |
ar |
1.3.6.1.4.1.42.2.27.9.4.3.1 |
|
アラビア語アラブ首長国連邦 |
ar-AE |
1.3.6.1.4.1.42.2.27.9.4.4.1 |
|
アラビア語バーレーン |
ar-BH |
1.3.6.1.4.1.42.2.27.9.4.5.1 |
|
アラビア語アルジェリア |
ar-DZ |
1.3.6.1.4.1.42.2.27.9.4.6.1 |
|
アラビア語エジプト |
ar-EG |
1.3.6.1.4.1.42.2.27.9.4.7.1 |
|
アラビア語インド |
ar-IQ |
1.3.6.1.4.1.42.2.27.9.4.9.1 |
|
アラビア語ヨルダン |
ar-JO |
1.3.6.1.4.1.42.2.27.9.4.10.1 |
|
アラビア語クウェート |
ar-KW |
1.3.6.1.4.1.42.2.27.9.4.11.1 |
|
アラビア語レバノン |
ar-LB |
1.3.6.1.4.1.42.2.27.9.4.12.1 |
|
アラビア語リビア |
ar-LY |
1.3.6.1.4.1.42.2.27.9.4.13.1 |
|
アラビア語モロッコ |
ar-MA |
1.3.6.1.4.1.42.2.27.9.4.14.1 |
|
アラビア語オマーン |
ar-OM |
1.3.6.1.4.1.42.2.27.9.4.15.1 |
|
アラビア語カタール |
ar-QA |
1.3.6.1.4.1.42.2.27.9.4.16.1 |
|
アラビア語サウジアラビア |
ar-SA |
1.3.6.1.4.1.42.2.27.9.4.17.1 |
|
アラビア語スーダン |
ar-SD |
1.3.6.1.4.1.42.2.27.9.4.18.1 |
|
アラビア語シリア |
ar-SY |
1.3.6.1.4.1.42.2.27.9.4.19.1 |
|
アラビア語チュニジア |
ar-TN |
1.3.6.1.4.1.42.2.27.9.4.20.1 |
|
アラビア語イエメン |
ar-YE |
1.3.6.1.4.1.42.2.27.9.4.21.1 |
|
ベラルーシ語 |
be |
1.3.6.1.4.1.42.2.27.9.4.22.1 |
|
ブルガリア語 |
bg |
1.3.6.1.4.1.42.2.27.9.4.23.1 |
|
カタロニア語 |
ca |
1.3.6.1.4.1.42.2.27.9.4.25.1 |
|
チェコ語 |
cs |
1.3.6.1.4.1.42.2.27.9.4.26.1 |
|
デンマーク語 |
da |
1.3.6.1.4.1.42.2.27.9.4.27.1 |
|
ドイツ語 |
de |
1.3.6.1.4.1.142.2.27.9.4.28.1 |
|
ドイツ語ドイツ |
de-DE |
1.3.6.1.4.1.142.2.27.9.4.28.1 |
|
ドイツ語オーストリア |
de-AT |
1.3.6.1.4.1.42.2.27.9.4.29.1 |
|
ドイツ語スイス |
de-CH |
1.3.6.1.4.1.42.2.27.9.4.31.1 |
|
ドイツ語ルクセンブルク |
de-LU |
1.3.6.1.4.1.42.2.27.9.4.32.1 |
|
ギリシア語 |
el |
1.3.6.1.4.1.42.2.27.9.4.33.1 |
|
英語 |
en |
1.3.6.1.4.1.42.2.27.9.4.34.1 |
|
英語アメリカ合衆国 |
en-US |
1.3.6.1.4.1.42.2.27.9.4.34.1 |
|
英語オーストラリア |
en-AU |
1.3.6.1.4.1.42.2.27.9.4.35.1 |
|
英語カナダ |
en-CA |
1.3.6.1.4.1.42.2.27.9.4.36.1 |
|
英語イギリス |
en-GB |
1.3.6.1.4.1.42.2.27.9.4.37.1 |
|
英語アイルランド |
en-IE |
1.3.6.1.4.1.42.2.27.9.4.39.1 |
|
英語インド |
en-IN |
1.3.6.1.4.1.42.2.27.9.4.40.1 |
|
英語ニュージーランド |
en-NZ |
1.3.6.1.4.1.42.2.27.9.4.42.1 |
|
英語南アフリカ |
en-ZA |
1.3.6.1.4.1.42.2.27.9.4.46.1 |
|
スペイン語 |
es |
1.3.6.1.4.1.42.2.27.9.4.49.1 |
|
スペイン語スペイン |
es-ES |
1.3.6.1.4.1.42.2.27.9.4.49.1 |
|
スペイン語アルゼンチン |
es-AR |
1.3.6.1.4.1.42.2.27.9.4.50.1 |
|
スペイン語ボリビア |
es-BO |
1.3.6.1.4.1.42.2.27.9.4.51.1 |
|
スペイン語チリ |
es-CL |
1.3.6.1.4.1.42.2.27.9.4.52.1 |
|
スペイン語コロンビア |
es-CO |
1.3.6.1.4.1.42.2.27.9.4.53.1 |
|
スペイン語コスタリカ |
es-CR |
1.3.6.1.4.1.42.2.27.9.4.54.1 |
|
スペイン語ドミニカ共和国 |
es-DO |
1.3.6.1.4.1.42.2.27.9.4.55.1 |
|
スペイン語エクアドル |
es-EC |
1.3.6.1.4.1.42.2.27.9.4.56.1 |
|
スペイン語グアテマラ |
es-GT |
1.3.6.1.4.1.42.2.27.9.4.57.1 |
|
スペイン語ホンジュラス |
es-HN |
1.3.6.1.4.1.42.2.27.9.4.58.1 |
|
スペイン語メキシコ |
es-MX |
1.3.6.1.4.1.42.2.27.9.4.59.1 |
|
スペイン語ニカラグア |
es-NI |
1.3.6.1.4.1.42.2.27.9.4.60.1 |
|
スペイン語パナマ |
es-PA |
1.3.6.1.4.1.42.2.27.9.4.61.1 |
|
スペイン語ペルー |
es-PE |
1.3.6.1.4.1.42.2.27.9.4.62.1 |
|
スペイン語プエルトリコ |
es-PR |
1.3.6.1.4.1.42.2.27.9.4.63.1 |
|
スペイン語パラグアイ |
es-PY |
1.3.6.1.4.1.42.2.27.9.4.64.1 |
|
スペイン語サルバドル |
es-SV |
1.3.6.1.4.1.42.2.27.9.4.65.1 |
|
スペイン語ウルグアイ |
es-UY |
1.3.6.1.4.1.42.2.27.9.4.67.1 |
|
スペイン語ベネズエラ |
es-VE |
1.3.6.1.4.1.42.2.27.9.4.68.1 |
|
エストニア語 |
et |
1.3.6.1.4.1.42.2.27.9.4.69.1 |
|
フィンランド語 |
fi |
1.3.6.1.4.1.42.2.27.9.4.74.1 |
|
フランス語 |
fr |
1.3.6.1.4.1.42.2.27.9.4.76.1 |
|
フランス語 |
fr-FR |
1.3.6.1.4.1.42.2.27.9.4.76.1 |
|
フランス語 |
fr-BE |
1.3.6.1.4.1.42.2.27.9.4.77.1 |
|
フランス語 |
fr-CA |
1.3.6.1.4.1.42.2.27.9.4.78.1 |
|
フランス語 |
fr-CH |
1.3.6.1.4.1.42.2.27.9.4.79.1 |
|
フランス語 |
fr-LU |
1.3.6.1.4.1.42.2.27.9.4.80.1 |
|
ヘブライ語 |
he |
1.3.6.1.4.1.42.2.27.9.4.85.1 |
|
クロアチア語 |
hr |
1.3.6.1.4.1.42.2.27.9.4.87.1 |
|
ハンガリー語 |
hu |
1.3.6.1.4.1.42.2.27.9.4.88.1 |
|
アイスランド語 |
is |
1.3.6.1.4.1.42.2.27.9.4.91.1 |
|
イタリア語 |
it |
1.3.6.1.4.1.42.2.27.9.4.92.1 |
|
イタリア語スイス |
it-CH |
1.3.6.1.4.1.42.2.27.9.4.93.1 |
|
日本語 |
ja |
1.3.6.1.4.1.42.2.27.9.4.94.1 |
|
韓国語 |
ko |
1.3.6.1.4.1.42.2.27.9.4.97.1 |
|
リトアニア語 |
lt |
1.3.6.1.4.1.42.2.27.9.4.100.1 |
|
ラトビア語 |
lv |
1.3.6.1.4.1.42.2.27.9.4.101.1 |
|
マケドニア語 |
mk |
1.3.6.1.4.1.42.2.27.9.4.102.1 |
|
オランダ語 |
nl |
1.3.6.1.4.1.42.2.27.9.4.105.1 |
|
オランダ語オランダ |
nl-NL |
1.3.6.1.4.1.42.2.27.9.4.105.1 |
|
オランダ語ベルギー |
nl-BE |
1.3.6.1.4.1.42.2.27.9.4.106.1 |
|
ノルウェー語 |
no |
1.3.6.1.4.1.42.2.27.9.4.107.1 |
|
ノルウェー語ノルウェー |
no-NO |
1.3.6.1.4.1.42.2.27.9.4.107.1 |
|
ノルウェー語ニーノシュク |
no-NO-NY |
1.3.6.1.4.1.42.2.27.9.4.108.1 |
|
ポーランド語 |
pl |
1.3.6.1.4.1.42.2.27.9.4.114.1 |
|
ポルトガル語 |
pt |
1.3.6.1.4.1.42.2.27.9.4.115.1 |
|
ポルトガル語ポルトガル |
pt-PT |
1.3.6.1.4.1.42.2.27.9.4.115.1 |
|
ポルトガル語ブラジル |
pt-BR |
1.3.6.1.4.1.42.2.27.9.4.116.1 |
|
ルーマニア語 |
ro |
1.3.6.1.4.1.42.2.27.9.4.117.1 |
|
ロシア語 |
ru |
1.3.6.1.4.1.42.2.27.9.4.118.1 |
|
ロシア語ロシア |
ru-RU |
1.3.6.1.4.1.42.2.27.9.4.118.1 |
|
スロバキア語 |
sk |
1.3.6.1.4.1.42.2.27.9.4.121.1 |
|
スロベニア語 |
sl |
1.3.6.1.4.1.42.2.27.9.4.122.1 |
|
アルバニア語 |
sq |
1.3.6.1.4.1.42.2.27.9.4.127.1 |
|
セルビア語 |
sr |
1.3.6.1.4.1.42.2.27.9.4.128.1 |
|
スウェーデン語 |
sv |
1.3.6.1.4.1.42.2.27.9.4.129.1 |
|
スウェーデン語スウェーデン |
sv-SE |
1.3.6.1.4.1.42.2.27.9.4.129.1 |
|
タイ語 |
th |
1.3.6.1.4.1.42.2.27.9.4.136.1 |
|
トルコ語 |
tr |
1.3.6.1.4.1.42.2.27.9.4.140.1 |
|
ウクライナ語 |
uk |
1.3.6.1.4.1.42.2.27.9.4.141.1 |
|
ベトナム語 |
vi |
1.3.6.1.4.1.42.2.27.9.4.142.1 |
|
中国語 |
zh |
1.3.6.1.4.1.42.2.27.9.4.143.1 |
|
中国語中国 |
zh-CN |
1.3.6.1.4.1.42.2.27.9.4.144.1 |
|
中国語香港 |
zh-HK |
1.3.6.1.4.1.42.2.27.9.4.145.1 |
|
中国語台湾 |
zh-TW |
1.3.6.1.4.1.42.2.27.9.4.148.1 |
18.6 ディレクトリ・データの処理
ディレクトリ・サーバーは、ディレクトリ・エントリを管理するためのLDAPv2およびLDAPv3準拠クライアント・ツールの完全なセットを備えています。ldapmodifyおよびldapdeleteユーティリティを使用することで、エントリを追加、更新または削除できます。LDAPコマンド行ユーティリティは、コマンド行から入力またはファイルから読み取られたLDAP Data Interchange Format (LDIF)形式の入力を必要とします。
ディレクトリ・データに変更を行う前に、次の概念を理解していることを確認します。
-
権限およびアクセス制御メカニズム。
権限の設定の詳細は、「データへのアクセス制御」を参照してください。
-
ご使用のディレクトリ・サーバーの構造。
-
ご使用のディレクトリ・サーバーのスキーマ。
この項では、次の項目について説明します。
18.6.1 ディレクトリ・エントリの追加
ldapmodifyコマンドを使用して1つ以上のエントリをディレクトリ・サーバーに追加できます。ldapmodifyは、ディレクトリ・サーバーへの接続を開き、それにバインドし、コマンド行オプションによって指定されたとおりにデータベースに対する変更(この場合は「追加」)を実行します。
ldapmodifyでは、次の2つの方法のいずれかでエントリを追加できます:
-
--defaultAddオプションの使用。コマンド行でデータを入力する場合は、
--defaultAddオプションを使用して新しいエントリをディレクトリに追加します。終了したら、[Ctrl] + [D] (UNIX、Linux)または[Ctrl] + [Z] (Windows)を押すか、変更内容が含まれている入力ファイルを使用します。 -
LDIF更新文の使用。LDIF更新文は、
ldapmodifyによってディレクトリ・エントリをどのように変更するのかを定義します。LDIF更新文には、変更するエントリのDN、特定のエントリをどのように変更するのか(add、delete、modify、modrdn)を定義するchangetype、および一連の属性とそれらの変更された値が含まれています。
ノート:
新たに追加されたエントリはすべて、そのディレクトリのスキーマに準拠している必要があります。スキーマに準拠しないエントリを追加すると、サーバーはオブジェクト・クラス違反エラーで応答します。エラーの詳細は、errorsログで表示できます。
この項では、次の項目について説明します。
18.6.1.1 ルート・エントリの作成
ルート・エントリは、ディレクトリの最上位のエントリであり、ネーミング・コンテキストまたはルート接尾辞を含んでいる必要があります。ルート・エントリは、ディレクトリ・サーバーを最初にインストールするときに、グラフィカル・ユーザー・インタフェース(GUI)またはコマンド行を使用して設定できます。データを含めずにディレクトリをインストールする場合は、--defaultAddオプションを指定してldapmodifyコマンドを使用してルート・エントリを作成します。
18.6.1.2 ldapmodifyで--defaultAddオプションを使用したエントリの追加
--defaultAddオプションを使用してエントリを追加するには、ldapmodifyコマンドを次のように実行します。
18.6.2 属性の追加
エントリに属性を追加するには、後続の項の例に示すように、changetype:modify文を使用します。各コマンドをダッシュ(-)で区切ることで、1つのファイル内の複数のコマンドを結合できます。
LDIF changetype:add文は、エントリをディレクトリに追加します。
この項では、エントリの管理方法を説明しており、内容は次のとおりです:
18.6.2.2 ACI属性の追加
ldapmodifyを使用して、アクセス制御命令(ACI)を追加し、ユーザーのアカウントのアクセス権を管理できます。詳細は、「データへのアクセス制御」およびACI構文を参照してください。
次の例では、ユーザーに自身のディレクトリ属性の変更を許可します。
18.6.2.3 国際化属性の追加
ディレクトリ・サーバーでは、attribute;language-subtype形式の言語タグを使用して国際化ロケールを表します。たとえば、homePostalAddress;lang-jp:addressは、日本のロケール(subtype=jp)では住所を指定します。
ldapmodifyを使用して属性を追加します。
言語サブタイプlang-ccを追加します。ccは国コードです。
$ ldapmodify --hostname localhost --port 1389 --bindDN "cn=Directory Manager" \ --bindPassword password dn: uid=jarrow,ou=People,dc=example,dc=com changetype: modify add: homePostalAddress;lang-jp homePostalAddress;lang-jp: 1-8-15 Azuchimachi, Chuo-ku (Press Ctrl-D on Unix, Linux) (Press Ctrl-Z on Windows), then press ENTER.
ノート:
属性値にASCII以外の文字がある場合、UTF-8エンコードする必要があります。
18.6.3 ディレクトリ・エントリの変更
LDIF更新文changetype:modifyを使用して、既存のディレクトリ・データに変更を行います。
次の手順は、ディレクトリ・エントリを変更する例を示し、内容は次のとおりです:
詳細は、「ldapmodify」を参照してください
18.6.3.1 属性値の変更
ldapmodifyを使用し、changetype:modifyおよびreplace要素を使用してエントリを変更します。
modifyの後に空白がないことを確認してください。
この例では、ユーザーの既存の電話番号を変更します。
$ ldapmodify -h localhost -p 1389 D "cn=Directory Manager" -j pwd-file \ dn: uid=Marcia Garza,ou=People,dc=example,dc=com changetype: modify replace: telephonenumber telephonenumber: +1 408 555 8288 Processing MODIFY request for uid=Marcia Garza,ou=People,dc=example,dc=com MODIFY operation successful for DN uid=Marcia Garza,ou=People,dc=example,dc=com
複数の属性を変更するには、属性をダッシュ(-)で区切ります。たとえば:
dn: uid=Marcia Garza,ou=People,dc=example,dc=com changetype: modify replace: telephonenumber telephonenumber: +1 408 555 6465 - add: facsimiletelephonenumber facsimiletelephonenumber: +1 408 222 4444 - replace: l l: Sunnyvale
18.6.3.2 前後のスナップショットでの属性の変更
ldapmodifyコマンドには、--preReadAttributeと--postReadAttributeのオプションがあり、それらはそれぞれ、前および後のスナップショットで変更された属性を返します。
--preReadAttributeおよび--postReadAttributeオプションを指定してldapmodifyを使用します。
この例では、ユーザーの既存の電話番号を変更します。
$ ldapmodify -h localhost -p 1389 D "cn=Directory Manager" -j pwd-file \ --preReadAttributes telephoneNumber --postReadAttributes telephoneNumber dn: uid=Marcia Garza,ou=People,dc=example,dc=com changetype: modify replace: telephonenumber telephonenumber: +1 408 555 8288 Processing MODIFY request for uid=Marcia Garza,ou=People,dc=example,dc=com MODIFY operation successful for DN uid=Marcia Garza,ou=People,dc=example,dc=com Target entry before the operation: dn: uid=Marcia Garza,ou=People,dc=example,dc=com telephonenumber: +1 408 555 4283 Target entry after the operation: dn: uid=Marcia Garza,ou=People,dc=example,dc=com telephonenumber: +1 408 555 8288
18.6.3.3 属性の削除
この例では、エントリから位置(l)属性を削除します。
ldapmodifyを使用して属性を削除します。
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file dn: uid=Marcia Garza,ou=People,dc=example,dc=com changetype: modify delete: l (Press CTRL-D for Unix, Linux) (Press CTRL-Z for Windows), then press ENTER. Processing MODIFY request for uid=Marcia Garza,ou=People,dc=example,dc=com MODIFY operation successful for DN uid=Marcia Garza,ou=People,dc=example,dc=com
[Ctrl] + [D] (UNIX、Linux)または[Ctrl] + [Z] (Windows)を押して入力を完了します。
18.6.3.4 RDNの変更
エントリの識別名(DN)によって、エントリが一意に識別され、そのエントリが記述されます。識別名は、そのエントリ自体の名前と、ディレクトリ内でそれの上にあるオブジェクトの名前(下から上の順序)で構成されています。
相対識別名(RDN)は、エントリDNの左端の要素です。たとえば、uid=Marcia Garza,ou=People,dc=example,dc=comのRDNは、uid=Marcia Garzaです。RDNを変更するには、changetype:moddn LDIF更新文を使用します。
deleteoldrdn属性を使用することでディレクトリ内に古いRDNを保持するかどうかを指定できます。0のdeleteoldrdn値は、既存のRDNをディレクトリ内に保持することを示します。1の値は、既存のRDNを新しいRDNで置き換えることを示します。
18.6.3.5 エントリの移動
1つの親から別の親にエントリを移動する場合、その親エントリのアクセス制御命令(ACI) 権限を拡張します。エントリの移動元の親エントリ上で、構文allow(export...)を使用することで、ACIでエクスポート操作が許可されるようにします。エントリの移動先の親エントリ上で、構文allow(import...)を使用することで、ACIでインポート操作が許可されるようにします。
この例では、uid=sgarzaをou=Contractors,dc=example,dc=com接尾辞からou=People,dc=example,dc=comサブツリーに移動します。
18.6.4 ディレクトリ・エントリの削除
ldapmodifyおよびldapdeleteを使用して、ディレクトリからエントリを削除できます。ldapmodifyコマンドは、delete属性とともに、LDIF更新文changetype:deleteを使用してエントリを、changetype:modifyを使用して属性を削除します。ldapdeleteツールでは、エントリのみが削除されます。
ノート:
子エントリを持つエントリは削除できません。子を持つエントリを削除する場合、最初にターゲット・エントリの下にあるすべての子エントリを削除してから、そのエントリを削除します。
次の各トピックでは、ディレクトリ・エントリを削除する方法を説明します。
詳細は、「ldapdelete」を参照してください。
18.6.4.1 ldapmodifyを使用したエントリの削除
changetype:delete文を指定して、ldapmodifyコマンドを使用します。
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file dn: uid=Marcia Garza,ou=People,dc=example,dc=com changetype: delete (Press CTRL-D for Unix) (Press CTRL-Z for Windows), then press ENTER. Processing DELETE request for uid=Marcia Garza,ou=People,dc=example,dc=com DELETE operation successful for DN uid=Marcia Garza,ou=People,dc=example,dc=com The number of entries deleted was 1
18.6.4.2 ldapdeleteを使用したエントリの削除
ldapdeleteコマンドを使用して、削除するエントリを変更します。
$ ldapdelete -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file "uid=mgarza,ou=People,dc=example,dc=com" Processing DELETE request for uid=Marcia Garza,ou=People,dc=example,dc=com DELETE operation successful for DN uid=Marcia Garza,ou=People,dc=example,dc=com
18.7 ディレクトリ・データへの索引付け
索引は、サーバーごとに構成され、索引構成はレプリケートされません。dsconfigを使用して、ローカル・データベース索引および仮想リスト表示(VLV)索引を作成します。
ローカル・データベース索引は、検索基準に一致するエントリを見つけるために使用されます。VLV索引は、VLV制御で効率的に検索を処理するために使用されます。
ユーザーにunindexed-search権限がある場合以外は、索引付けされていない検索はデフォルトで拒否されます。詳細は、「ルート・ユーザーの特権の変更」を参照してください。
次の2つの方法で、検索が索引付けされているかどうかを判別できます:
-
匿名で検索の実行を試みます。(サーバーは、デフォルトで、索引付けされていない匿名検索を拒否します。)
-
debugsearchindex操作属性を使用します。この属性は、検索で使用される索引、各索引からの候補エントリの数、最終的な索引付けされたステータスを提供します。次のように、ldapsearchコマンドにdebugsearchindex属性を含めます:$ ldapsearch -h localhost -p 1389 -b "dc=example,dc=com" "(objectClass=*)" debugsearchindex
次の各項では、dsconfigコマンド行ツールを使用して属性に索引付けする方法を説明します。
18.7.1 ローカルDBバックエンドでの索引の構成
ローカルDBバックエンドでサポートされる索引タイプについて理解し、新しいローカルDB索引を作成します。この項には、索引を作成および追加するための例が含まれています。
この項では、次の項目について説明します。
18.7.1.1 ローカルDBバックエンドでサポートされる索引タイプ
ローカルDBバックエンドでは、次の索引タイプがサポートされています:
-
approximate—近似検索フィルタを使用する検索の効率を高めます。 -
equality- 等価検索フィルタを使用する検索の効率を高めます。 -
ordering- 以上または以下の検索フィルタを使用する検索の効率を高めます。今後、この索引タイプは、サーバー側ソートにも使用される可能性があります。 -
presence- プレゼンス検索フィルタを使用する検索の効率を高めます。 -
substring- 部分文字列検索フィルタを使用する検索の効率を高めます。
ディレクトリ・サーバーでは、照合一致ルール、相対時間の一致ルール、部分的な日付や時刻の一致ルールなど拡張可能一致操作のサブセットに対してのみ索引付けがサポートされています。詳細は、「国際化されたエントリの検索」、「相対時間の一致ルールの理解」および「部分的な日付や時間の一致ルールの理解」を参照してください。
dsconfigで新しいローカルDBバックエンドを作成すると、次のデフォルト索引が自動的に作成されます:
-
aci(プレゼンス索引) -
ds-sync-hist(順序付け索引) -
entryuuid(等価索引) -
objectclass(等価索引)
18.7.1.2 新規ローカルDB索引の作成
新規ローカルDB索引を作成するには、次のステップを実行します。
ノート:
新しい索引を作成した後、rebuild-indexユーティリティを使用して索引を再構築する必要があります。ディレクトリ・サーバーは、索引が再構築されるまで新しい索引を使用できません。詳細は、「rebuild-index」を参照してください。
-
新しい索引を作成します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ create-local-db-index \ --element-name backend --index-name attribute \ --set index-type:index-type
-
ローカルDB索引をそのバックエンドに対してリストすることで索引が作成されたことを確認します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ list-local-db-indexes \ --element-name backend -
具体的な索引プロパティを構成します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-local-db-index-prop \ --element-name backend --index-name attribute \ --set property:value
-
索引プロパティをリストして変更を検証します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ get-local-db-index-prop \ --element-name backend --index-name attribute
-
索引を再構築します。
-
サーバーを停止し、索引を再構築して、サーバーを再起動します。
$ stop-ds $ rebuild-index --baseDN baseDN --index attribute $ start-ds
-
または、タスクとしてrebuild-indexコマンドを実行することで、オンラインで索引を再構築します。
$ rebuild-index -h localhost -p 4444 -D "cn=Directory manager" -j pwd-file \ -X -n --baseDN dc=example,dc=com --index aci Rebuild Index task 20110201162742312 scheduled to start immediately ... Rebuild Index task 20110201162742312 has been successfully completed
ノート:
オンラインの再索引付け操作の場合でも、再索引付け中はバックエンドは使用できません。レプリケートされたトポロジでは、全体的なサービスは、依然としてreferral on update機能を通して使用可能です。詳細は、「レプリケート・トポロジでのリフェラルの理解」を参照してください。
-
18.7.1.3 索引の作成および追加の例
次の例は、新しい等価索引を作成する方法および部分文字列索引を追加する方法を示しています。
18.7.1.3.1 新しい等価索引の作成
この項の例では、employeeNumber属性の新しい等価索引を作成し、索引プロパティを検証し、索引エントリの制限を5000に設定します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ create-local-db-index \ --element-name userRoot --index-name employeeNumber \ --set index-type:equality $ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ list-local-db-indexes \ --element-name userRoot Local DB Index : Type : index-type ---------------:---------:----------- ... employeeNumber : generic : equality ... $ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ get-local-db-index-prop \ --element-name userRoot --index-name employeeNumber Property : Value(s) -------------------------------:--------------- attribute : employeenumber index-entry-limit : 4000 index-extensible-matching-rule : - index-type : equality $ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-local-db-index-prop \ --element-name userRoot --index-name employeeNumber --set index-entry-limit:5000 $ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ get-local-db-index-prop \ --element-name userRoot --index-name employeeNumber Property : Value(s) -------------------------------:--------------- attribute : employeenumber index-entry-limit : 5000 index-extensible-matching-rule : - index-type : equality $ rebuild-index -h localhost -p 4444 -D "cn=Directory manager" -j pwd-file -X \ --baseDN dc=example,dc=com --index employeeNumber
18.7.1.3.2 部分文字列索引の追加
この項の例では、部分文字列索引を前の例で作成した索引に追加します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-local-db-index-prop \ --' p userRoot --index-name employeeNumber \ --add index-type:substring $ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ get-local-db-index-prop \ --element-name userRoot --index-name employeeNumber Property : Value(s) -------------------------------:--------------- attribute : employeenumber index-entry-limit : 5000 index-extensible-matching-rule : - index-type : equality, substring $ rebuild-index -h localhost -p 4444 -D "cn=Directory manager" -j pwd-file -X \ --baseDN dc=example,dc=com --index employeeNumbe
18.7.2 VLV索引の構成
VLV索引の構成を理解し、例を参考にして新しいVLV索引の作成について学習します。
次の各トピックでは、VLV索引の構成について説明します。
18.7.2.1 VLV索引構成について
VLV索引は、指定されたベース・エントリおよびそのサブツリーに対する特定の検索に適用されます。索引を作成するときは、ソート順序、索引の範囲、ベースDNおよびフィルタを定義する必要があります。
新しいVLV索引を作成した後、rebuild-indexコマンドを使用して索引を再構築し、索引名の前にvlv.を追加する必要があります。ディレクトリ・サーバーは、索引が再構築されるまで新しい索引を使用できません。詳細は、「rebuild-index」を参照してください。
ノート:
VLVリクエスト制御へのアクセスは、デフォルトで、認証されたユーザーにのみ許可されます。認証されていないユーザーが検索リクエストでVLV制御を使用できるようにする場合は、対応するグローバルACIを変更する必要があります。詳細は、「仮想リスト表示制御への匿名アクセスの許可」を参照してください。
18.7.2.2 新しいVLV索引の作成
新しいVLV索引を作成するには、次のステップに従います。
-
次のように、
dsconfigを使用して新しいVLV索引を作成します:$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ create-local-db-vlv-index \ --element-name backend --index-name name --set sort-order:attributes \ --set scope:scope --set base-dn:baseDN --set filter:filter
説明:
-
index-nameは一意の索引名を指定し、VLV索引を作成した後に変更できません。 -
sort-orderは、エントリをソートする基準となる属性の名前およびそれらの優先順位を高いほうから順に指定します。 -
scopeは、索引付けされる問合せのLDAP範囲を指定し、base-object、single-level、subordinate-subtreeまたはwhole-subtreeの1つにすることができます。 -
base-dnは、索引付けされる検索問合せで使用されるベースDNを指定します。 -
filterは、索引付けされる問合せに使用されるLDAPフィルタを指定し、任意の有効なLDAPフィルタにすることができます。
-
-
既存のVLV索引をリストすることで索引が作成されたことを確認します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ list-local-db-vlv-indexes \ --element-name backend -
索引プロパティを表示して変更を検証します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ get-local-db-vlv-index-prop \ --element-name backend --index-name name
-
索引を再構築します。
-
サーバーを停止し、索引を再構築して、サーバーを再起動します。
$ stop-ds $ rebuild-index --baseDN baseDN --index vlv.name $ start-ds
-
または、タスクとしてrebuild-indexコマンドを実行することで、オンラインで索引を再構築します。
$ rebuild-index -h localhost -p 4444 -D "cn=Directory manager" -j pwd-file -X \ --baseDN baseDN --index vlv.name
-
18.7.2.3 新しいVLV索引の作成の例
次の例では、新しいVLV索引を作成し、問合せsn=*に対して、最初に姓で、次に共通名でエントリをソートします。この例では、その後、索引をオンラインで再構築します。
$ dsconfig -D "cn=directory manager" -j pwd-file -n create-local-db-vlv-index \ --element-name userRoot --index-name myVLVIndex --set sort-order:"sn cn" \ --set scope:base-object --set base-dn:dc=example,dc=com --set filter:sn=* $ rebuild-index -h localhost -p 4444 -D "cn=Directory manager" -j pwd-file -X \ -b "dc=example,dc=com" --index vlv.myVLVIndex
18.8 格納されるデータ・サイズの削減
ディレクトリ・サーバーは、格納されるデータのサイズを減らすための2つのメカニズムを備えていますこれらのメカニズムは、圧縮エンコーディングおよびエントリの圧縮です。
次の各トピックでは、前述のメカニズムのいずれかを使用した格納されるデータ・サイズの削減および属性値のトークンを使用したデータベース領域の節約について理解できます。
18.8.1 格納されるデータ・サイズの削減について
圧縮エンコーディングおよびエントリの圧縮を有効にすることによって、格納されるデータのサイズを削減できます。
ディレクトリ・サーバーは、格納されるデータのサイズを減らすための2つのメカニズムを備えています:
-
圧縮エンコーディング。圧縮エンコーディングが有効化されている場合、バックエンドではエントリをエンコードするときに属性の説明とオブジェクト・クラス・セットを圧縮することで、圧縮形式が使用されます。このプロパティは、エントリ自体にのみ適用され、索引データには影響を与えません。圧縮エンコーディングは、デフォルトで有効化されていますが、必要に応じて無効化できます。ご使用のデプロイメントで、オブジェクト・クラスおよび属性タイプ名でユーザーによる先頭文字の大文字化が必要とされている場合、ユーザーによる先頭文字の大文字化は圧縮されたエントリでは保持されないため、圧縮エンコーディングを無効化できます。ただし、圧縮は、パフォーマンスを向上させるため、パフォーマンスのためにはユーザーによる先頭文字の大文字化を無視できるか、それが不要なデプロイメントでは利点があります。
-
エントリの圧縮。エントリの圧縮では、デフレータを使用して、データを格納する前に圧縮します。エントリの圧縮を有効化すると、エントリをデータベースに格納する前にバックエンドによってそれらの圧縮が試みられます。このプロパティも、エントリ自体にのみ適用され、索引データには影響を与えません。エントリの圧縮の有効性は、エントリに含まれているデータ型に基づきます。
これらのメカニズムの1つまたは両方を有効化して、格納されるデータのサイズを減らすことができます。これらのメカニズムを有効化すると、今後の書込みにのみ作用するため、データベースには、圧縮されたデータと圧縮されていないレコードが混在することがあります。圧縮の設定に関係なく、どちらのタイプのレコードも読取り可能です。
18.8.2 圧縮エンコーディングの有効化または無効化
圧縮エンコーディングは、ローカル・バックエンド・ワークフロー要素のcompact-encodingプロパティを設定することで構成されます。この設定に対する変更は、変更が行われた後に発生する書込みにのみ有効になります。既存のデータがさかのぼって変更されることはありません。
userRootワークフロー要素に対しては圧縮エンコーディングを無効化します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-workflow-element-prop --element-name="userRoot" --set compact-encoding:false
18.8.3 エントリの圧縮の有効化または無効化
エントリの圧縮は、ローカル・バックエンド・ワークフロー要素のentries-compressedプロパティを設定することで構成されます。この設定に対する変更は、変更が行われた後に発生する書込みにのみ有効になります。既存のデータがさかのぼって変更されることはありません。
userRootワークフローに対してはエントリの圧縮を有効化します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-workflow-element-prop --element-name="userRoot" \ --set entries-compressed:true
18.8.4 属性値のトークンを使用したデータベース領域の節約
Oracle Unified Directoryサーバーでは、値の数が少なく、多数のエントリで多くの回数繰り返される属性を圧縮できます。サーバーは、トークンを使用してこれらの属性とその値を参照します。サーバーは、トークンとその値を一度個別の表に格納してから、トークンのみをデータベース・エントリに格納します。この最適化により、本来は多くのデータベース・エントリにわたって属性値が繰り返される場合の領域が節約されます。これにより、本来はデータベース全体がメモリーに収まらない場合のキャッシュ効率も改善できます。
たとえば、すべての顧客(ユーザー)が使用する携帯電話の名前とモデルを格納するmobile-phoneユーザー属性を持つ電話会社について考えてみます。電話会社のデータベース内の各ユーザー・エントリには、1つのmobile-phone属性値(複数の値でない場合)があります。mobile-phoneが取得できる値のセットは限られており、最も一般的なmobile-phoneの値は、データベース内のユーザーにわたって数千回(場合によっては数百万回)繰り返されます。
ただし、この最適化を使用する場合、Oracle Unified Directoryサーバーはトークンを使用してmobile-phone属性値を格納します。サーバーは、トークンおよび属性値を一度だけ個別の表に格納してから、トークンをデータベース・エントリに格納します。
トークンを使用して圧縮する必要がある属性のリストを構成するには、DBローカル・バックエンド・ワークフロー要素の複数値ds-cfg-compact-attribute-values-using-tokensプロパティを設定します。たとえば:
$ dsconfig set-workflow-element-prop \
--element-name userRoot \
--set compact-attribute-values-using-tokens:mobile-phone \
--hostname host --port admim-port \
--trustStorePath INSTALL_PATH/asinst_1/OUD/config/admin-truststore \
--bindDN "cn=Directory Manager" \
--bindPasswordFile ****** --no-prompt
このプロパティを設定した後、変更は、変更後に発生する書込みに対してのみ有効になります。既存のデータがさかのぼって変更されることはありません。
構成前から存在する属性の既存のデータをds-cfg-compact-attribute-values-using-tokensプロパティを使用して圧縮するには、データをエクスポートしてから再インポートします(ただし、属性のトークンを使用することで達成されるパフォーマンスに照らしてこの操作のコストを考慮する必要があります)。
ds-cfg-compact-attribute-values-using-tokensプロパティを使用して属性を圧縮した後、dbtestコマンドで、値を格納するためにデータベースで作成されたトークンの合計数を表示します。たとえば:
$ dbtest list-database-containers -n userRoot Database Name Database Type JE Database Name Entry Count --------------------------------------------------------------------------------- Schema maps compressed_object_classes 8 compressed_attributes 32 compressed_values 14 ...
compressed_values行は、このデプロイメントで、14の値がトークンとしてエンコードされ、多数の値のエンコードに再利用できることを示します。dbtestを使用して、この機能が正しく構成されており、トークンの数が多くなりすぎていないかをチェックできます。
18.8.5 複数値属性の作成順での取得
複数値属性をそれらが作成された順序で格納および取得できます。
属性の複数の値を格納できます。ただし、圧縮エンコーディング機能のため、複数値属性に対して問合せが実行された場合、属性の複数の値が作成された順序で返される保証はありません。複数の属性値の取得時に、値が作成された同じ順序で返されるようにする場合は、圧縮エンコーディングを無効にする必要があります。圧縮エンコーディングを無効にする方法については、「圧縮エンコーディングの有効化または無効化」を参照してください。
18.9 選択的属性キャッシングの構成
選択的属性キャッシングを使用して大規模なデプロイメントのメモリー要件を削減し、大きいエントリを使用する場合のパフォーマンスを改善できます。
次の各トピックでは、選択的属性キャッシングの使用方法について説明します。
18.9.1 選択的属性キャッシングの理解
Oracle Unified Directoryは、読取りまたは書込み操作のLDAPエントリ全体に対してI/Oおよびデータベース・キャッシングを実行します。ただし、大部分の読取りおよび書込み操作は特定の属性のみを対象としており、データベースに格納されている他の属性にアクセスすることはほとんどありません。大規模なデプロイメントや大きいエントリの場合、この動作がメモリーおよびパフォーマンスに影響することがあります。
選択的属性キャッシングを使用すると、アクセス頻度に基づいてLDAPエントリ内の属性を区別することによって、これらの操作をより適切に管理できます。
-
通常属性: アクセス頻度が高い属性。たとえば、事務所の電話番号、ユーザーID、電子メール・アドレスなどです。
-
コールド属性: アクセス頻度が低い属性。たとえば、ページャ番号、自宅の電話番号、jpegフォトなどのバイナリ・データです。
操作要求のみに機能する、または特定のユースケースに適したコールド属性を構成できます。
ノート:
コールド属性を効果的に指定するには、使用するアプリケーションについて熟知している必要があります。
通常属性とコールド属性は各種のLDAPアプリケーション・ワークロードで異なる場合があることに注意してください。たとえば、デプロイメントで従業員のページャ番号や自宅の電話番号にアクセスする頻度が低い場合は、それらの属性をコールド属性として構成できます。ただし、別の顧客のデプロイメントで従業員のページャ番号や電話番号に頻繁にアクセスする場合、それらの属性をコールドとして構成することは不適切です。
ノート:
コールドとして構成できる属性に制限はありませんが、(次のような)各種のコア・サーバー機能で使用される属性をコールドに指定した場合、選択的属性キャッシングの利点が損なわれ、一部のコア・サーバー機能で予想外の動作が発生する可能性があります。
-
グループ(定義がエントリ属性に基づく場合があります)
-
仮想属性(他のエントリ属性に依存する場合があります)
-
パスワード・ポリシー属性(ポリシー属性を読み取り、変更します)
-
ユーザー・アカウント通知
-
アサーション制御
-
永続検索
これらのコア・サーバー属性をコールドに指定することはサポートされていません。
コールド属性を指定すると、サーバーはLDAPエントリ・ストアをid2entryとid2entry-coldの2つのデータベースに分割します。サーバーは通常属性を通常のid2entryデータベースに格納し、コールド属性をid2entry-coldデータベースに格納します。2つのデータベースを使用した場合、部分エントリ・データに関する操作のI/Oが削減され、javaヒープ、データベース・キャッシュおよびファイル・システム(FS)キャッシュのメモリー・フットプリントが削減されます。
18.9.2 選択的属性キャッシングの使用の例
選択的属性キャッシングの使用方法についてさらに学習します。
LDAPエントリ・ストアに次の属性が含まれているシナリオについて考えます。
dn: uid=user.0,ou=People,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson givenName: Aaccf sn: Amar cn: Aaccf Amar employeeNumber: 0 uid: user.0 mail: user.0@example.com userPassword: password telephoneNumber: +1 024 705 1954 homePhone: +1 021 391 6930 mobile: +1 195 481 7233 initials: AFA street: 77569 Lake Street l: Elmira st: ND postalCode: 31858 postalAddress: Aaccf Amar$77569 Lake Street$Elmira, ND 31858 description: This is the description for Aaccf Amar. pager: +1 575 339 1600
属性を次のように構成および格納することを決定できます。
| id2entryデータベース | id2entry-coldデータベース |
|---|---|
dn: uid=user.0,ou=People,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson givenName: Aaccf sn: Amar cn: Aaccf Amar employeeNumber: 0 uid: user.0 mail: user.0@example.com userPassword: password telephoneNumber: +1 024 705 1954 homePhone: +1 021 391 6930 mobile: +1 195 481 7233 |
initials: AFA street: 77569 Lake Street l: Elmira st: ND postalCode: 31858 postalAddress: Aaccf Amar$77569 Lake Street$Elmira, ND 31858 description: This is the description for Aaccf Amar. pager: +1 575 339 1600 |
Oracle Unified Directoryは、属性へのアクセスが行われ、通常属性のキャッシュの優先度がコールド属性より高い場合にのみ、id2entry-coldデータベースから属性をキャッシュします。その結果、コールド属性を対象としない操作はキャッシュに入る可能性が高くなります。
また、書込み操作がコールド属性を対象としていない場合、それらの操作はid2entry-coldデータベースをリライトする必要がないため、特に大きい属性がコールド属性として宣言された場合、操作が高速になります。
ノート:
選択的属性キャッシングでは、DBキャッシュに完全に収まるデータベースの検索パフォーマンスは向上しない可能性があります。ただし、選択的属性キャッシングを使用すると、データベースがメモリーに完全には収まらない場合に、最も一般的に使用される属性のキャッシュ・ヒットを増やすことができます。
18.9.3 属性レベルのキャッシングの構成
属性レベルのキャッシングはDBキャッシュに関連するため、構成はバックエンド構成エントリに保持されます。
DBローカル・バックエンド・ワークフロー要素でコールド属性を構成するには、複数値ds-cfg-cold-attributeプロパティを使用してデータベースにコールド属性の名前を指定します。
ノート:
任意の属性をコールド属性に指定できますが、操作処理のためにサーバーが依存している属性(ACI、パスワード・ポリシー、他の前述のコア・サーバー機能など)を指定することは避ける必要があります。
たとえば、
dsconfig set-workflow-element-prop \
--element-name userRoot \
--add cold-attribute:description \
--add cold-attribute:initials \
--add cold-attribute:l \
--add cold-attribute:pager \
--add cold-attribute:postalAddress \
--add cold-attribute:postalCode \
--add cold-attribute:st \
--add cold-attribute:street \
このdsconfigコマンドを実行した後、(dsconfigによって表示される) userRootワークフロー要素のプロパティは次のようになります。
Property : Value(s) -----------------------------:------------------------------- 1) base-dn : "dc=example,dc=com" 2) cold-attribute : description, initials, l, pager, postalAddress, postalCode,st, street ...
dsconfigコマンドを実行した後、cn=configの下のuserRootワークフロー要素のエントリは次のようになります。
dn : cn=userRoot,cn=Workflow Elements,cn=config objectClass : ds-cfg-local-backend-workflow-element objectClass : ds-cfg-workflow-element objectClass : ds-cfg-db-local-backend-workflow-element objectClass : top ... ds-cfg-cold-attribute : description ds-cfg-cold-attribute : pager ds-cfg-cold-attribute : postalCode ds-cfg-cold-attribute : postalAddress ds-cfg-cold-attribute : st ds-cfg-cold-attribute : l ds-cfg-cold-attribute : street ds-cfg-cold-attribute : initials
ノート:
コールド属性を定義する場合、サーバーは既存のデータをコールド・データベースに移動しません。新しいエントリを追加した場合や既存のエントリを変更した場合にのみ、サーバーはコールド・データベースへのコールド属性の格納を開始します。
コールド属性を定義した後にデータの新規インポートを実行することが理想的です。
制限
コールド属性を使用する場合、次の制限が適用されます。
-
前述のように、コア・サーバー機能(アクセス制御命令(ACI)、仮想ACI、パスワード・ポリシー属性、グループなど)で使用される属性をコールドに指定した場合、選択的属性キャッシングの利点が損なわれ、一部のコア・サーバー機能で予期しない動作が発生する可能性があります。これらの属性をコールドに指定することはサポートされていません。
-
Oracle Unified Directoryは、コールド属性を含むエントリをエントリ・キャッシュにキャッシュできません。属性レベルのキャッシングは、デプロイメントがメモリーによって制約され、メモリーで非常にコストが高いためエントリ・キャッシュ使用できない場合に役立ちます。
18.9.4 コールド属性使用のモニタリング
Oracle Unified Directoryには、サーバーがコールド属性にアクセスするたびに追跡するコールド属性使用方法モニターが用意されています。このモニターはパフォーマンスへの影響を防ぐためにデフォルトで無効になっていますが、ds-cfg-monitor-cold-attributesバックエンド構成プロパティを使用して、診断のために有効にできます。
コールド属性を構成した後、モニターを有効にし、特定のアプリケーション・ワークロードを使用してサーバーを実行できます。モニターによって、サーバーがアクセスしたコールド属性およびアクセスした回数が記録されます。このデータを使用してコールド属性の構成を改良できます。たとえば、モニタリングによりコールド属性が多くの回数アクセスされていることが示される場合は、その属性を通常属性として再構成することを検討する可能性もあります。
次のサンプル出力では、descriptionは9回アクセスされ、それ以外のすべてのコールド属性は3回アクセスされていることがわかります。
たとえば、次のサンプル・モニタリング出力について考えます。
dn: cn=dc_example_dc_com Cold Attributes Usage,cn=monitor objectClass: top objectClass: ds-monitor-entry objectClass: extensibleObject cn: dc_example_dc_com Cold Attributes Usage l: 3 st: 3 initials: 3 postalCode: 3 pager: 3 description: 9 postalAddress: 3 street: 3
18.10 属性値の一意性の確認
ディレクトリの構造では、識別名によって、ディレクトリ情報ツリー内のオブジェクトおよびその場所が一意に識別される必要があります。ディレクトリ・サーバーは、一意属性プラグインを備えており、それによって、属性がディレクトリ内で追加、変更または移動された場合に、属性値の一意性が確保されます。
この節では、以下のトピックについて説明します。
18.10.1 一意な属性プラグインの概要
一意属性プラグインは、デフォルトで無効化されています。このプラグインは、dsconfigコマンドを使用することで有効化でき、それによってチェックされる接尾辞および属性を定義できます。このプラグインは、有効化されている場合、操作によってデータベースが更新される前に、LDAP追加、変更またはDN変更操作によって、2つのエントリが同じ属性を持つようになるかどうかを識別します。サーバーによって競合が認識された場合、操作は終了され、LDAP_CONSTRAINT_VIOLATIONエラーがクライアントに返されます。
既存のディレクトリで属性値の一意性を有効にしても、サーバーは既存のエントリ間での一意性をチェックしません。プラグインが有効化された後は、エントリが追加、変更または移動されるときに一意性が強制されます。
一意の属性プラグインを構成し、ディレクトリ内の1つ以上のサブツリーや、特定のオブジェクト・クラスのエントリ間で、一意性を確保できます。他の属性の一意性を確保する場合、一意属性プラグインのインスタンスをいくつか定義できます。通常、値を一意にする属性ごとに、1つのプラグイン・インスタンスを定義します。同じ属性に複数のプラグイン・インスタンスを用意することで、複数のエントリ・セットでその属性の一意性を個別に確保できます。
一意属性プラグインはデフォルトでは無効化されており、マルチマスターのレプリケーション構成が影響を受けることはありません。プラグインが有効化されていると、スタンドアロン・システムの場合は追加、変更またはDN変更操作の前にuid属性が一意であることが確認され、レプリケートされた環境では同期の後に一意性がチェックされます。
一意属性プラグインは、他のプラグインと同様に、dsconfigコマンドを使用して構成されます。詳細は、「dsconfigを使用したプラグインの構成」を参照してください。プラグインを構成する最も簡単な方法は、対話型モードでdsconfigを使用する方法です。対話モードは、ウィザードのように機能し、プラグイン構成を手順を追ってガイドします。対話モードは説明不要であるため、この項の例では、対話モードを例示せず、同等の完全なdsconfigコマンドについて説明します。
18.10.2 dsconfigを使用した一意の属性プラグインの構成
dsconfigコマンドを使用した属性値の一意性の構成を学習します。
この項では、次の項目について説明します。
18.10.2.1 uid属性値の一意性の確認
デフォルトでは、一意属性プラグインはuid属性をチェックします。次のタスクによって、一意属性プラグインが有効化され、ベースDN(その下のuid属性の属性値の一意性がチェックされる)が設定されます。
18.11 仮想属性の構成
仮想属性とは、永続ストレージに存在しないが動的に生成される値を持つ属性です。
仮想属性を構成するには、次の各項で説明するように、dsconfigコマンドを使用するか、またはOUDSMグラフィカル・ユーザー・インタフェースを使用します。
18.11.1 サポートされている仮想属性
次の表の列から、サポートされている仮想属性について理解します。
Oracle Unified Directoryでは次の仮想属性タイプをサポートしています。
表18-3 サポートされている仮想属性
| 仮想属性名 | 説明 |
|---|---|
|
|
エントリに影響するすべての集合属性サブエントリを指定する仮想属性を生成します。 |
|
|
エントリのDNの正規化された形式を含むentryDN操作属性をディレクトリ・エントリ内に生成します。 |
|
|
プライベート・バックエンドに含まれるすべてのエントリにentryUUID操作属性の値があることを確認します。 |
|
|
エントリで有効なスキーマ定義を使用してDIT構造ルールを指定します。 |
|
|
エントリに下位エントリがあるかどうかを示します。 |
|
|
ユーザーがメンバーであるグループのDNが含まれます。 |
|
|
メンバー、または値が指定された仮想静的グループのメンバーのDNである |
|
|
LDAPデータベースとしてOracle Directory Server Enterprise Editionを使用するレガシー・アプリケーションからOracle Unified Directoryへの移行の間の名前の競合を解決するために、ディレクトリ・サーバーの各エントリに割り当てられる一意の識別子を生成します。 |
|
|
エントリの下に存在する直接の子エントリの数を指定します。 |
|
|
orclguid仮想属性を作成します。 |
|
|
経過後にユーザーのパスワードが期限切れになる正確な時間を示します。
|
|
|
エントリで有効なパスワード・ポリシー・サブエントリを指します。 |
|
|
位置ベースの近接性をメートルで指定します。 |
|
|
エントリで有効なスキーマ定義を使用して構造オブジェクト・クラスを指定します。 |
|
|
エントリで有効なスキーマ定義を使用してsubschemaSubentryの場所を指定します。 |
|
|
プラグインの構成で定義されている基準と一致するエントリ内のユーザー定義値を使用して、仮想属性を作成します。 |
18.11.2 dsconfigを使用した仮想属性の構成
仮想属性を構成する最も簡単な方法は、対話モードでdsconfigを使用することです。対話モードは、ウィザードのように機能し、仮想属性構成を手順を追ってガイドします。対話モードは説明不要であるため、この項の例では、対話モードを例示せず、同等の完全なdsconfigコマンドについて説明します。
次の各トピックでは、dsconfigコマンドを使用して仮想属性を構成および管理する方法を説明します。
dsconfigの使用方法の詳細は、「dsconfigを使用したサーバー構成の管理」を参照してください。
18.11.2.1 dsconfigを使用した既存の仮想属性のリスト
ディレクトリ・サーバーは、デフォルトでいくつかの仮想属性ルールを提供します。
構成されているすべての仮想属性ルールのリストを表示するには、次のdsconfigコマンドを実行します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n list-virtual-attributes
次の例は、前述のコマンドのサンプル出力を示しており、これは構成されているすべての仮想属性ルールのリストです。
Virtual Attribute : Type : enabled : attribute-type --------------------------------:---------------------------------:---------:---------------- Collective Attribute Subentries : collective-attribute-subentries : true : collectiveattributesubentries entryDN : entry-dn : true : entrydn entryUUID : entry-uuid : true : entryuuid governingStructureRule : governing-structure-rule : true : governingstructurerule hasSubordinates : has-subordinates : true : hassubordinates isMemberOf : is-member-of : true : ismemberof nsuniqueid : nsuniqueid : true : nsuniqueid numSubordinates : num-subordinates : true : numsubordinates orclguid : orclguid : true : orclguid Password Expiration Time : password-expiration-time : true : passwordexpirationtime Password Policy Subentry : password-policy-subentry : true : pwdpolicysubentry Proximity : proximity : true : proximity structuralObjectClass : structural-object-class : true : structuralobjectclass subschemaSubentry : subschema-subentry : true : subschemasubentry Virtual Static member : member : true : member Virtual Static uniqueMember : member : true : uniquemember
次の情報(左から右)が、コマンドのサンプル出力の前述のリストに含まれています。
-
Virtual Attribute。通常それが何を行うかを説明する、仮想属性の名前を表示します。 -
Type。仮想属性のタイプを表示します。特定のタイプの仮想属性を複数定義することができます。 -
enabled。仮想属性が有効化されているか無効化されているかを示します。無効化された仮想属性はサーバー構成内に保持されますが、それらの値は生成されません。 -
attribute-type。仮想属性が生成される属性のタイプを表示します。
18.11.2.2 dsconfigを使用した新規仮想属性の作成
新規仮想属性を作成するには、create-virtual-attributeサブコマンドを使用します。
たとえば、次のdsconfigコマンドを実行して、位置がシドニーのユーザー・エントリに仮装FAX番号の+61 2 45607890を追加する(彼らが自身のエントリにすでにFAX番号を持っていない場合)仮想属性ルールを作成し、有効化できます。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ create-virtual-attribute \ --type user-defined --name "Sydney Fax Number" \ --set attribute-type:facsimiletelephonenumber --set enabled:true \ --set value:+61245607890 --set filter:"(&(objectClass=person)(l=Sydney))"
18.11.2.3 dsconfigを使用した仮想属性の有効化または無効化
仮想属性を有効化するには、enabledプロパティをtrueに設定します。仮想属性を無効化するには、enabledプロパティをfalseに設定します。
たとえば、次のコマンドを実行して、前の例で作成した仮想属性を無効化します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ set-virtual-attribute-prop --name="Sydney Fax Number" --set enabled:false
18.11.2.4 dsconfigを使用した仮想属性の構成の表示
仮想属性の構成を表示するには、get-*-propサブコマンドを使用します。
たとえば、次のコマンドを実行して、「OUDSMを使用した仮想属性の作成」で作成した仮想属性のプロパティのリストを表示します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ get-virtual-attribute-prop --name="Sydney Fax Number" Property : Value(s) ------------------:---------------------------------- attribute-type : facsimiletelephonenumber base-dn : - conflict-behavior : real-overrides-virtual enabled : false filter : (&(objectClass=person)(l=Sydney)) group-dn : - value : +61245607890
18.11.2.5 dsconfigを使用した仮想属性の構成の変更
仮想属性の構成を変更するには、set-*-propサブコマンドを使用します。
たとえば、このコマンドを使用して、競合が発生した場合に仮想属性の動作を変更できます。デフォルトでは、実際の属性の値によって仮想属性の値が上書きされます。次のコマンドを実行すると、実際の属性の値と仮想属性の値がマージされます。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-virtual-attribute-prop --name="Sydney Fax Number" \ --set conflict-behavior:merge-real-and-virtual
18.11.3 OUDSMを使用した仮想属性の構成
OUDSMを使用して仮想属性を管理できます。
次の各トピックでは、OUDSMの「構成」タブを使用して仮想属性を表示および作成する方法を説明します。
18.11.3.5 OUDSMを使用した仮想属性の有効化または無効化
仮想属性を有効化または無効化するには、属性の構成ページを開き(「OUDSMを使用した仮想属性の構成の変更」を参照)、「有効」ボックスを使用します。
-
仮想属性を有効化するには、ボックスを選択します。
-
仮想属性を無効化するには、ボックスをクリアします。
18.12 LDAPサブエントリの使用方法
LDAPサブエントリは、サーバーの操作データを保持し、ldapSubEntryオブジェクト・クラスを持つ特別なエントリです。それらは、サブエントリ制御リクエスト制御を含めることで明示的にリクエストされない場合は、クライアントに返されない点で、操作属性に似ています。
この項には次のトピックが含まれます:
18.12.1 LDAPサブエントリについて
LDAPサブエントリは、エントリの範囲を指定するために使用できます。この機能は、集合属性の定義で使用され、アクセス制御などの他の分野でも便利です。
詳細は、「集合属性の使用方法」および「LDAPサブエントリとしてのパスワード・ポリシーの定義」を参照してください。
サブツリーの指定では、次のパラメータを使用して一連のエントリを定義します:
-
ベース
これは、管理ポイントを基準としたサブツリーのルートの相対名です。管理ポイントが
ou=systemで、ベースがou=usersである場合、サブツリーは、ou=users,ou=systemで始まります。ベースは、""を含む任意の長さの名前コンポーネントにすることができます。この場合、サブツリーは、前の例のou=system管理ポイントで始まります。 -
切捨て
chopBeforeおよびchopAfterパラメータは、サブツリーのベースを基準とした名前であり、エントリとその子をコレクションから除外するかどうかを指定します。minimumパラメータは、選択にエントリを含めるために必要なベースとターゲットの間の名前コンポーネントの最小数を示します。maximumパラメータは、コレクションからエントリから除外されるまでに許可されるベースとターゲットの間の最大長を示します。 -
仕様フィルタ
仕様フィルタは、前のパラメータによって定義されたサブツリーを絞り込み、それがエントリの連続したセットではなく、エントリの
objectClass特性に基づいて収集されたセットになるようにします。たとえば、管理領域のリージョンを対象にするが、そのリージョンの
inetOrgPersonsのみを含むサブツリーを定義できます。
LDAPサブエントリのOracle Unified Directoryの実装は、RFC 3672 (http://www.ietf.org/rfc/rfc3672.txt)に基づいていますが、相対サブツリーという拡張が1つあり、それは次の項で説明します。
18.12.2 相対サブツリー
相対サブツリーは標準サブツリーのように機能します。ただし、仕様フィルタは、一連の絞込みではなくLDAP検索フィルタです
相対サブツリーの場合は、仕様によって、relativeBaseキーワードを使用してサブツリーのルートを指定することが定められています。baseキーワードを使用してサブツリーのルートを指定しないでください。
たとえば、次のサブツリー定義は、ベースDN ou=Peopleの下の、位置がパリのすべてのユーザーをターゲットにします:
subtreeSpecification: {relativeBase "ou=people", specificationFilter "(l=Paris)" }18.13 集合属性の使用方法
集合属性は、エントリのコレクション全体で共有される値を持つ属性です。集合属性は、Oracle Directory Server Enterprise Editionサービス・クラス機能に類似した機能を提供します。
Oracle Unified Directoryの集合属性は、仮想属性に似ていますが、LDAPサブエントリとしてユーザー・データとともに定義され、格納されます。ユーザー・データの一部として、集合属性は、トポロジ内の他のサーバーにレプリケートできます。
次の各項では、Oracle Unified Directory内の集合属性の実装と、集合属性の構成方法について説明します。
18.13.1 集合属性の標準に対する拡張
集合属性のOracle Unified Directory実装は、RFC 3671およびRFC 3672に基づいていますが、特定の拡張があります。これらの拡張により、Oracle Unified Directoryの集合属性は、LDAPクライアント・アプリケーションに対して、より透過的になっています。
RFC 3671 (http://www.ietf.org/rfc/rfc3671.txt)およびRFC 3672 (http://www.ietf.org/rfc/rfc3672.txt)を参照してください。Oracle Unified Directoryの集合属性については、次の各項で説明します。
18.13.1.1 集合属性のネーミングについて
RFC 3671 (http://www.ietf.org/rfc/rfc3671.txt)によれば、集合属性はCOLLECTIVE属性タイプを持ち、スキーマで定義されている通常のユーザー属性から導出され、c-接頭辞を持っている必要があります。たとえば、c-lは、標準l属性に対する集合属性であり、影響を受けるユーザー・エントリには必要に応じてc-lが追加されます。
この仕様により、多くのクライアント・アプリケーションで問題が発生することがあります。それらは、一般的に、集合属性を認識せず、集合属性を処理するように変更または拡張する必要がありすま。したがって、Oracle Unified Directoryでは、この制約を取り除き、任意の通常の属性を、スキーマ内で集合属性として定義することがサポートされています。この拡張は、関連する集合属性サブエントリに、必要な属性を追加し、その属性に集合オプションでマークすることで容易になります。
18.13.1.2 集合属性のネーミングと競合解消の使用の例
集合属性には、様々な方法で名前が付けられます。このため、すでに関連する実際の属性を含んでいる影響を受けるユーザー・エントリに対して、競合解消メカニズムが提供されています。Oracle Unified Directoryでは、仮想属性の場合と同じ競合解消オプション(real-overrides-virtual、virtual-overrides-realおよびmerge-real-and-virtual)を集合属性に提供しています。
デフォルトの競合解消ルールは、real-overrides-virtualです。エントリにすでに同じ属性タイプが定義されている場合は、明示的に定義された属性が集合属性より優先されます。この動作は、collectiveConflictBehavior 属性を使用することで集合属性サブエントリごとに(virtual-overrides-realまたはmerge-real-and-virtualに)変更できます。
次の例では、Parisの値を持つl集合属性を、ou=peopleの下にある該当するユーザー・エントリそれぞれに動的に追加します。集合属性の値によって、エントリに固有のlの値がすべてオーバーライドされます:
dn: cn=People Locale,dc=example,dc=com
objectClass: top
objectClass: subentry
objectClass: collectiveAttributeSubentry
objectClass: extensibleObject
cn: People Locale
l;collective: Savoie
subtreeSpecification: {base "ou=people", minimum 1}
collectiveConflictBehavior: virtual-overrides-real18.13.1.3 特定のエントリからの集合属性の除外
場合によっては、特定のユーザー・エントリに集合属性を含めることを避ける必要があります。この動作を得るために、そのようなエントリにcollectiveExclusions操作属性を追加できます。特定の集合属性を除外するには、collectiveExclusions属性の値として属性名をリストします。すべての集合属性を除外するには、collectiveExclusionsの値をexcludeAllCollectiveAttributesに設定します。
次の例では、preferredLanguage属性を、user.0のエントリへの適用から除外します:
dn: uid=user.0,ou=People,dc=example,dc=com
objectclasses and other user attributes
collectiveExclusions: preferredLanguage
次の例では、c-l属性を、user.1のエントリへの適用から除外します:
dn: uid=user.1,ou=People,dc=example,dc=com
objectclasses and other user attributes
collectiveExclusions: c-l
次の例では、preferredLanguageとc-lの両方の属性を、user.2のエントリへの適用から除外します:
dn: uid=user.2,ou=People,dc=example,dc=com
objectclasses and other user attributes
collectiveExclusions: preferredLanguage
collectiveExclusions: c-l
次の例では、すべての集合属性を、user.0のエントリへの適用から除外します:
dn: uid=user.0,ou=People,dc=example,dc=com
objectclasses and other user attributes
collectiveExclusions: excludeAllCollectiveAttributes18.13.2 集合属性の構成
18.13.2.1 集合属性の構成の処理
集合属性は、ディレクトリ・ツリー内のLDAPサブエントリを使用して定義されます(適用可能な場合)。次の例では、複数のユーザー・エントリを持つ単純なツリーを使用します。
dn: dc=example,dc=com
dn: ou=People,dc=example,dc=com
dn: uid=user.0,ou=People,dc=example,dc=com
dn: uid=user.1,ou=People,dc=example,dc=com
dn: uid=user.2,ou=People,dc=example,dc=com
...
すべてのユーザーに共通のpreferredLanguage属性を追加するには、次のものに類似した集合属性サブエントリを作成して追加します:
dn: cn=People Preferred Language,dc=example,dc=com
objectClass: top
objectClass: subentry
objectClass: collectiveAttributeSubentry
objectClass: extensibleObject
cn: People Preferred Language
preferredLanguage;collective: fr
subtreeSpecification: {base "ou=people", minimum 1}
次の例に示すように、preferredLanguage属性と値のペアは、ou=peopleの下のすべてのユーザー・エントリに動的に追加されます:
dn: uid=user.0,ou=People,dc=example,dc=com objectclasses and other user attributes preferredLanguage: fr dn: uid=user.1,ou=People,dc=example,dc=com objectclasses and other user attributes preferredLanguage: fr ...
同じ手順が、collective属性タイプにも適用されます。たとえば、c-l集合属性タイプは、エントリのコレクションに対して地域名を指定します。次の例では、共通c-l集合属性を追加します:
dn: cn=People Locale,dc=example,dc=com
objectClass: top
objectClass: subentry
objectClass: collectiveAttributeSubentry
objectClass: extensibleObject
cn: People Locale
c-l: Paris
subtreeSpecification: {base "ou=people", minimum 1}
この例に示すように、c-l: Paris属性が、該当するエントリに追加されます:
dn: uid=user.0,ou=People,dc=example,dc=com objectclasses and other user attributes c-l: Paris dn: uid=user.1,ou=People,dc=example,dc=com objectclasses and other user attributes c-l: Paris ...
次のようにして、任意の集合属性のサブエントリに複数の集合属性を定義できます:
-
集合属性タイプをサブエントリに追加する
-
集合オプションを指定した通常の属性タイプを追加する
-
それらの2つの組合せを追加する
集合属性サブエントリでは、柔軟かつ複雑な定義が可能です。集合属性の範囲指定およびsubtreeSpecification構文の詳細は、RFC 3671 (http://www.ietf.org/rfc/rfc3671.txt)およびRFC 3672 (http://www.ietf.org/rfc/rfc3672.txt)を参照してください。
18.13.2.3 集合属性の削除
集合属性は、ldapdeleteコマンドまたはldapmodifyコマンドを使用することで削除できます。
次の例に示すように、changetype: delete要素を指定してldapmodifyコマンドを使用します。
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file dn: cn=People Preferred Language,dc=example,dc=com changetype: delete deleting entry cn=People Preferred Language,dc=example,dc=com
18.13.2.4 エントリに適用される集合属性のリスト
特定のユーザー・エントリに適用される集合属性サブエントリをリストするには、そのエントリに対するcollectiveAttributeSubentries操作属性をリクエストします。
ldapsearchコマンドを使用して、user.0エントリに適用される集合属性サブエントリをリストします:
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ -b "uid=user.0,ou=People,dc=example,dc=com" \ "objectclass=*" "collectiveAttributeSubentries" version: 1 dn: uid=user.0,ou=People,dc=example,dc=com collectiveAttributeSubentries: cn=People Preferred Language,dc=example,dc=com
18.13.3 継承集合属性の概要
継承属性では、継承の特性から、属性の共通セットの共有が可能になります。継承集合属性は、標準サブエントリ・サブツリー仕様を使用する柔軟な範囲指定メカニズムを提供し、RDNの定義および構築のためのすべての属性タイプをサポートします。
この項には、継承集合属性に関する次のトピックがあります。
18.13.3.1 継承集合属性について
集合属性と継承集合属性の主な相違は、属性値のソースです:
-
集合属性は、常に、その値をその定義エントリから導出します。
-
継承集合属性は、直接的または間接的に他のエンティティから集合属性値を継承できます。
継承集合属性の機能は、就航属性の上に構築および拡張されます。継承属性は、集合属性サブエントリの特別なタイプとして定義されます(inheritedCollectiveAttributeSubentry)。このタイプは、さらに次の2つの個別サブタイプに分かれています:
-
inheritedFromDNCollectiveAttributeSubentry -
inheritedFromRDNCollectiveAttributeSubentry
各サブタイプには、構成属性の独自のセットがあります。これらのサブタイプは1つの定義内に混在できず、継承属性定義は1つのサブタイプのもののみになります。
継承集合属性の範囲下にあるエントリは、複数のテンプレート・エントリを指す可能性があり、したがって、複数のエントリから値を継承できます。この場合、最初に処理された値が優先されます。
他の仮想属性と同様に、継承属性ではスキーマ・チェックは実行されません。したがって、継承によって、エントリがスキーマ違反になることがあります。ただし、これらの属性はすべて仮想であるため、この種のスキーマ違反は、サーバー機能に影響がないため無視できます。
継承集合属性は、Oracle Directory Server Enterprise Editionサービス・クラス(クラシックCoS)に類似した機能を提供します。たとえば、次のものがあるとします。ユーザー・エントリ:
uid=psmith,ou=people,dc=example,dc=com departmentNumber: 123 ...
部門エントリ:
cn=123,ou=departments,dc=example,dc=com telephoneNumber: 4486152643 ...
および継承属性定義:
dn: cn=classicCOS,dc=example,dc=com
objectClass: top
objectClass: subentry
objectClass: inheritedCollectiveAttributeSubentry
objectClass: inheritedFromRDNCollectiveAttributeSubentry
cn: classicCOS
subtreeSpecification: {base "ou=people"}
inheritFromBaseRDN: ou=departments
inheritFromRDNAttribute: departmentNumber
inheritFromRDNType: cn
inheritAttribute: telephoneNumber
継承集合属性サブエントリは、ou=people,dc=example,dc=comの下のユーザー・エントリに適用されます。telephoneNumber属性は、それらのエントリそれぞれに追加されます。telephoneNumber属性の値は、次のロジックで構築したDNを持つエントリから継承されます:
inheritFromRDNType=inheritFromRDNAttribute,inheritFromBaseRDN,"inherited collective attribute sub-entry rootDN"
またはcn=123,ou=departments,dc=example,dc=com
したがって、影響を受けるユーザー・エントリは次の形式になります:
uid=psmith,ou=people,dc=example,dc=com departmentNumber: 123 ... telephoneNumber: 4486152643
18.13.3.2 継承集合属性の指定
通常の集合属性と同様に、継承集合属性は、ディレクトリ・ツリー内のLDAPサブエントリを使用して定義されます(適用可能な場合)。
次の例では、複数のユーザー・エントリを持つ単純なツリーを使用します。
dn: dc=example,dc=com
dn: ou=People,dc=example,dc=com
dn: uid=hpollock,ou=People,dc=example,dc=com
dn: uid=cventer,ou=People,dc=example,dc=com
dn: uid=sdonnelly,ou=People,dc=example,dc=com
...
すべてのユーザーに継承postalAddress属性を追加するには、次のものに類似した継承集合属性サブエントリを作成して追加します:
dn: cn=indirectCOS,dc=example,dc=com
objectClass: top
objectClass: subentry
objectClass: inheritedCollectiveAttributeSubentry
objectClass: inheritedFromDNCollectiveAttributeSubentry
cn: indirectCOS
subtreeSpecification: {base "ou=people"}
inheritFromDNAttribute: manager
inheritAttribute: postalAddress
このサブエントリは、そのユーザー・エントリが、そのユーザー・エントリ内のmanager属性によって参照されるエントリからそのpostalAddress値を継承することを指定します。
マネージャのエントリには、postalAddress属性の実際の値が含まれています:
dn: uid=dsmith,ou=People,dc=example,dc=com ... objectclasses and other user attributes postalAddress: 650 Granger Parkway, Redwood Shores, CA 94065
各ユーザー・エントリは、マネージャ・エントリを参照し、そのエントリからそのpostalAddressを継承します:
dn: uid=hpollock,ou=People,dc=example,dc=com ... objectclasses and other user attributes manager: uid=dsmith,ou=People,dc=example,dc=com postalAddress: 650 Granger Parkway, Redwood Shores, CA 94065 dn: uid=cventer,ou=People,dc=example,dc=com ... objectclasses and other user attributes manager: uid=dsmith,ou=People,dc=example,dc=com postalAddress: 650 Granger Parkway, Redwood Shores, CA 94065 dn: uid=sdonnelly,ou=People,dc=example,dc=com ... objectclasses and other user attributes manager: uid=dsmith,ou=People,dc=example,dc=com postalAddress: 650 Granger Parkway, Redwood Shores, CA 94065
18.14 リフェラルの構成
リフェラルは、結果のかわりにクライアントに返されるリモート接尾辞またはエントリへのポインタです。
次の各トピックでは、リフェラルの構成方法について説明します。
18.14.1 リフェラルの構成の概要
サーバーは、クライアントのリクエストを処理できない場合、トポロジ内の他のサーバーをクライアントに示すリフェラルのリストをクライアントに送信します。その後、クライアントは、リフェラル・リスト内のリモート・サーバーの1つに対して操作を再度実行します。このトピックから、リフェラルについて理解します。
サーバーは、次の場合にリフェラルのリストを返します:
-
サーバーまたはローカル・バックエンド・ワークフロー要素で、書込み可能性が無効化されているか
internal-onlyに設定されています。詳細は、「書込み可能モード」を参照してください。この種のリフェラルは、referral on updateと呼ばれます。
-
ローカル・バックエンド・ワークフロー要素が、メンテナンス・モードになっていました。
一時的に、サーバーがクライアント・リクエストに応答しないようにする場合は、ローカル・バックエンド・ワークフロー要素をメンテナンス・モードにすることができます。
バックエンドをメンテナンス・モードにするには、ローカル・バックエンド・ワークフロー要素の
maintenanceプロパティをtrueに設定します。 -
データ・インポートまたは再索引付けの処理中などなんらかの理由で、バックエンドが使用できません。
-
クライアント・リクエストが明示的にスマート・リフェラルをターゲットにしています。詳細は、「スマート・リフェラルの管理」を参照してください。
リフェラルURLは、ホスト名、ポート番号、および必要に応じてローカル・ホストまたは別のサーバーのDNを含むLDAP URLです。詳細は、「LDAP URLの理解」を参照してください。
使用可能な場合は、サーバーから結果コードREFERRAL (10)がリフェラルURLのリストとともに返されます。使用可能なリフェラルURLがない場合は、サーバーから結果コードUNAVAILABLE (52)が返されます。
リフェラルURLは次の2つの方法で作成できます:
-
レプリケートされたサーバーの場合は、レプリケーション・サービスを使用してリストを伝播します。詳細は、「レプリケート・トポロジでのリフェラルの理解」を参照してください。
-
DBローカル・バックエンド・ワークフロー要素の
ds-cfg-referrals-urlプロパティを設定することで、リストを手動で作成します。詳細は、「リフェラル・リストの手動による構成」を参照してください。
18.14.2 レプリケート・トポロジでのリフェラルの理解
レプリケーション・サービスによって、リクエストをリダイレクトできるリフェラルURLのリストが生成されます。このリストは、各ローカル・サーバーで構成されているLDAP/LDAPS接続ハンドラに対応しています。LDAP/LDAPS接続ハンドラ以外の値を公開するには、独自のリフェラルURLを、ローカル・サーバー上のレプリケーション・ドメインのreferrals-urlプロパティの値として定義します。
クライアント・リクエストが、使用できないレプリケートされたサーバーをターゲットとしている場合は、サーバーから、リクエストをリダイレクトできるリフェラルURLのリストが送信されます。
リフェラルURLのリストは、リクエストに使用されたプロトコルに従って編成されます。たとえば、その操作がLDAPS経由で実行された場合、提供される最初のURLは、同じセキュアなプロトコル(LDAPS)を使用するものになります。
さらに、リストはグループIDによって編成されます。同じレプリケーション・グループ内のサーバーを表すURLは、最初に提示されます。URLのリストは、プロトコル・タイプ(LDAP/LDAPS)ごとに16個までのURLに制限されており、信頼されないサーバーは除外されます。
セキュリティ上の理由から、レプリケーション・サービスによって伝播されるリテラルは、信頼されないサーバーに対しては返されません。信頼されないサーバーが、トポロジの残りのものに関する情報を漏えいしないようにします。クライアント・リクエストが、信頼されないサーバーをターゲットとしている場合は、リフェラルURLのリストには、ローカル・バックエンド上の管理者によって管理されているサーバーのみが含まれるようになります。さらに、レプリケーション・サービスによって提供されるリフェラルURLでは、トポロジ内の信頼されないサーバーは除外されます。
レプリケーション・ドメインのpublish-referrals構成プロパティがfalseに設定されている場合は、レプリケーション・サービスによって生成されるリフェラルのリストにそのサーバーは含まれなくなります。
18.14.3 リフェラル・リストの手動による構成
レプリケーション・サービスによって提示されるリフェラルURLのリストをオーバーライドするか、またはレプリケートされたトポロジの外部でリフェラルを設定するには、DBローカル・バックエンド・ワークフロー要素のreferrals-urlプロパティを設定します。referrals-urlプロパティは、値として1つ以上のLDAP URLを取ります。
次の例では、dc=example,dc=com接尾辞をターゲットとしているクライアント・リクエストは、ホストhost1.example.com上で実行されているサーバーを参照し、ポート2389でリスニングする必要があります。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-workflow-element-prop --element-name userRoot \ --set referrals-url:ldap://host1.example.com:2389/dc=example,dc=com
複数のLDAP URLを指定するには、--addサブオプションを複数回使用します。たとえば:
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-workflow-element-prop --element-name userRoot \ --add referrals-url:ldap://host1.example.com:2389/dc=example,dc=com --add referrals-url:ldap://host2.example.com:1389/dc=example,dc=com
18.14.4 スマート・リフェラルの管理
スマート・リフェラルは、別のサーバーまたは別の接尾辞のコンテンツを参照する特別なタイプのエントリです。スマート・リフェラル・エントリには、ref属性の1つ以上のインスタンスを含むreferralオブジェクト・クラスが含まれています。各ref属性には、リフェラルで使用されるLDAP URLが含まれています。
この項では、次の項目について説明します。
18.14.4.1 スマート・リフェラルの構成
スマート・リフェラルを構成するには、referralオブジェクト・クラスおよびref属性を含む新しいエントリを追加します。ref属性には、LDAP URLが含まれている必要があります。
この例では、サーバーAに存在しているユーザー・エントリのリフェラルをサーバーBに作成します。
18.14.4.2 スマート・リフェラルの変更
スマート・リフェラルを表示または変更するには、manageDsaIT制御を指定して、ldapsearchまたはldapmodifyコマンドを使用します。この制御は、サーバーに、通常のエントリとしてリフェラル・オブジェクトを管理する予定であることを通知し、リフェラル・オブジェクトを読み取りまたは更新するリクエストに対してサーバーからリフェラル結果が送信されないようにします。
18.14.5 LDAP URLの理解
LDAP URLの形式は、RFC 4516で説明されており、次のように要約されます。
ldap[s]://hostname:port/base_dn?attributes?scope?filter
LDAP URLのコンポーネントは、次のとおりです:
-
ldaps[s]
サーバーに接続するのか(
ldap:)、SSL経由でサーバーに接続するのか(ldaps:)を示します。 -
hostname
LDAPサーバーのホスト名またはIPアドレスを指定します。
-
port
LDAPサーバーのポート番号を指定します。ポートが指定されていない場合、デフォルトLDAPポート(389)またはLDAPSポート(636)が使用されます。
-
base_dn
ディレクトリ内のエントリの識別名(DN)を指定します。このDNは、検索の開始点であるエントリを識別します。ベースDNが指定されていない場合、検索は、そのディレクトリ・ツリーのルートから開始されます。
-
attributes
指定された属性を返します。複数の属性を区切るには、カンマを使用します。属性が指定されていない場合、検索によってすべての属性が返されます。
-
scope
検索の範囲を指定します:
-
base。base_dnで指定されたベース・エントリのみを検索します。
-
one。base_dnで指定されたベース・エントリの1レベル下を検索します。
-
sub。base_dnで指定されたベース・エントリおよびその下のすべてのエントリを検索します。
範囲が指定されていない場合、ベース検索が実行されます。
-
-
filter
検索の指定された範囲内のエントリに適用される検索フィルタを指定します。フィルタが指定されていない場合、デフォルト(
objectclass=*)が使用されます。空白はすべて、ご使用のシェルに適した文字を使用してエスケープする必要があります。
ノート:
LDAPクライアントが認証を提供しない場合、LDAP URLを使用して開始された検索リクエストはすべて匿名(未認証)になります。
次に、LDAP URLの例のリストを示します。
-
次のLDAP URLは、
dc=example,dc=comの下のいずれかのレベルで姓Jensenを持つすべてのエントリの検索を指定します。ポートが指定されていない場合は、デフォルト(389)が使用されます。属性が指定されていない場合、すべての属性が返されます。ldap://example.com/dc=example,dc=com??sub?(sn=Jensen)
-
次のLDAP URLは、
dc=example,dc=comの下のすべてのレベルにおけるcnおよびtelephoneNumber属性の検索を指定します。サーバーは、ポート2389でリモート・サーバーにアクセスします。検索フィルタが指定されていないため、デフォルト・フィルタ(objectclass=*)が使用されます。ldap://example.com:2389/dc=example,dc=com?cn,telephoneNumber?sub
18.15 アップグレード時の属性の大文字と小文字の区別の保持
アップグレードの直前にcompact-encodingフラグの値をfalseに設定しておくと、11.1.2.2.0から11.1.2.3.0へのアップグレード後に大文字と小文字の区別がある値を保持できます。
dn (ドメイン名)属性には、cn (共通名)、uid (一意のアイデンティティ)または他の属性がdnの一部として含まれる場合があります。次の例では、cnおよびdnの値の大文字と小文字の区別が等しくなっています。指定された属性の値および大文字と小文字が等しい場合は、11.1.2.2.0から11.1.2.3.0にアップグレードした後も大文字と小文字の区別は失われません。dn: cn=john.doe1,ou=people,dc=example,dc=com
givenName: John
mail: john.doe1@example.com
userPassword: password
cn: john.doe1次の表は、compact-encodingフラグ値に関して、大文字と小文字が区別されるデータのデフォルト動作について説明しています。
| compact-encodingフラグをFalseに設定した場合 | compact-encodingフラグをTrueに設定した場合 |
|
11.1.2.2.0では、 前述の詳細が設定されたユーザーを作成しようとすると、作成されるユーザー・エントリには、入力に指定された |
11.1.2.3.0では、デフォルトでこのフラグがtrueに設定され、
前述の詳細が設定されたユーザーを作成しようとすると、OUDでは、 |
11.1.2.2.0では、dnとは異なるcnまたはuidの値を指定可能で、Oracle Unified Directoryでは、dnにある値とは関係なく、指定された値が有効になります。これが、compact-encoding機能が存在しない場合のデフォルトの動作です。
dn: uid=john.doe1,ou=people,dc=example,dc=com
givenName: John
mail: john.doe1@example.com
userPassword: password
uid: John.Doe1属性がdnの一部として存在する場合は、大文字と小文字が区別される値が保持されます。たとえば、dnにuid属性が含まれる場合に、uid値が明示的に指定されていない場合は、dnに指定されているuid値が有効になります。
11.1.2.3.0では、属性の値および大文字と小文字の区別が等しいと想定されているため、11.1.2.3.0のデフォルトの動作に従って、Oracle Unified Directoryでは、エントリ作成時のdnにある値が有効となります。11.1.2.3.0のデフォルトでは、compact-encodingフラグはtrueに設定されます。アップグレード時には、特に静的グループに関しては、これらのグループが11.1.2.3.0に保存されている方法が原因で、指定されたcnまたはuid属性の大文字と小文字の区別が失われます。これが、compact-encodingフラグがtrueに設定された場合のデフォルトの動作です。
大文字と小文字の区別がある値を維持するには、アップグレードする直前にcompact-encodingフラグの値を明示的にfalseに設定する必要があります。詳細は、「圧縮エンコーディングの有効化または無効化」を参照してください。
compact-encodingフラグがfalseに設定されていない場合は、dnに指定されたcnまたはuid属性値のみがアップグレード後にOUDで有効になります。
ノート:
バージョン11.1.2.2.0から12.2.1.3.0バージョンにアップグレードするときも、属性の大文字と小文字の区別を維持できます。18.16 OUDSMを使用したデータの管理
OUDSMの各サーバー・インスタンスの「データ・ブラウザ」タブで、ディレクトリ・データに対する基本検索を実行でき、エントリを追加、削除および変更できます。
OUDSMには、どのデータ・フィールドにも文字のサブセットを入力できる自動提案機能があります。その後、OUDSMによって、その文字のサブセットに一致するすべてのエントリが返されます。自動提案機能では、OUDSMによってすでにキャッシュされているエントリのみが返されます。
次の各項では、OUDSMを使用してデータを管理する方法について説明します。
18.16.1 エントリの表示
「データ・ブラウザ」タブの「エントリ」ペインから、エントリを表示し、エントリを特定のエントリ・セットに制限できます。
OUDSMデータ・ブラウザを使用してディレクトリ・エントリを表示するには、次のステップに従います。
「エントリの属性の表示」も参照してください。
18.16.3 エントリの検索
「データ・ブラウザ」タブの基本検索機能では、ユーザーまたはグループのエントリを検索できます。
ディレクトリ・データに対して基本検索を実行するには、次のステップに従います。
- 「OUDSMを使用したサーバーへの接続」の説明に従って、OUDSMからディレクトリ・サーバーに接続します。
- 「データ・ブラウザ」タブを選択します。
- 「ネットワーク・グループ」リストから適切なネットワーク・グループを選択します。
- 左ペインで「検索」タブを選択します。
- 「対象」リストから、ユーザー・エントリとグループ・エントリのどちらを検索するのかを選択します。
- エントリ名の任意の部分を入力し、右矢印ボタンをクリックします。たとえば、John Smithというユーザーを検索するには、
Smith、Smi、Johnなどを入力できます。 - 左ペインにエントリが表示されたら、そのエントリをダブルクリックし、右ペインにその詳細を表示します。
18.16.4 エントリの追加
Oracle Unified Directory Services Managerでエントリを追加または削除するには、親エントリに対する書込みアクセス権限があり、新規エントリの識別名を認識している必要があります。
18.16.5 既存のエントリに基づいたエントリの追加
類似エントリの作成オプションを使用することで、既存のエントリに基づいてエントリを追加できます。
OUDSMデータ・ブラウザを使用して既存のエントリに基づいたエントリを追加するには、次のステップに従います。
18.16.6 エントリの削除
「削除」オプションを使用して、OUDSMデータ・ブラウザからエントリを削除できます。
OUDSMデータ・ブラウザを使用してエントリを削除するには、次のステップに従います。
- 「エントリの表示」の説明に従って、既存のエントリを表示します。
- 削除するエントリを選択し、「削除」アイコンをクリックします。
- 「エントリの削除」ダイアログで、適切なエントリを削除しようとしていることを確認し、「OK」をクリックします。
18.16.7 エントリとそのサブツリーの削除
エントリとそのサブツリーの削除オプションを使用して、エントリと、ディレクトリ・ツリー内でその下にあるすべてのエントリを削除できます。
エントリとそのサブツリーを削除するには、次のステップに従います。
- 「エントリの表示」の説明に従って、既存のエントリを表示します。
- 削除するエントリを選択し、エントリとそのサブツリーの削除アイコンをクリックします。
- 「サブツリーの削除」ダイアログで、適切なエントリを削除しようとしていることを確認し、「OK」をクリックします。
18.16.8 エントリのRDNの変更
OUDSMデータ・ブラウザを使用して、エントリのRDNを変更できます。
次のステップを実行します。
- 「エントリの表示」の説明に従って、既存のエントリを表示します。
- 新しいエントリの基にする、変更するRDNを持つエントリを選択し、「RDNの編集」アイコンをクリックします。
- 「新規RDN値」フィールドに新しいRDNを指定します。
- 古いRDNを形成していた値をエントリから削除する場合は、「古いRDNの削除」を選択します。このチェック・ボックスを選択しない場合、古いRDNを形成していた値は、そのエントリの非識別属性値として保持されます。
- オプションで、「サブツリー・エントリのリフレッシュ」アイコンをクリックし、RDNの変更を確認します。
18.16.9 LDIFファイルからのデータのインポート
OUDSMデータ・ブラウザで「LDIFのインポート」オプションを使用して、LDIFファイルからデータをインポートできます。
LDIFファイルからエントリをインポートするには、次のステップに従います。
- 「OUDSMを使用したサーバーへの接続」の説明に従って、OUDSMからディレクトリ・サーバーに接続します。
- 「データ・ブラウザ」タブを選択します。
- 「ネットワーク・グループ」リストから適切なネットワーク・グループを選択します。
- 「LDIFのインポート」アイコンをクリックします。
- 「エントリのインポート」ダイアログで、「ファイルの選択」をクリックします。
- システム上のLDIFファイルを見つけ、「OK」をクリックします。
- 「LDIFのインポート進行状況」ダイアログで、インポートの進行状況をモニターし、インポートが完了したら、「OK」をクリックします。
- データ・ブラウザ・ツリーがリフレッシュされ、新規エントリが表示されます。