| Oracle® Fusion Middleware Oracle Unified Directory管理者ガイド 11g リリース2 (11.1.2) B72794-02 |
|
 前 |
 次 |
この章では、ディレクトリ・サーバーにおけるデータの追加、変更、削除および検索の方法について説明します。この章では、データに索引付けすることによって、より効率的に検索を実行する方法、エントリが一意であることを確認する方法、仮想属性など拡張データ機能を使用する方法についても説明します。
この章では、次のトピックを取り扱います:
ディレクトリ・サーバーは、特定のバックエンドとの間でデータをやり取りするいくつかのメカニズムを備えています。この章では、各種オプションの概要を示し、インポートおよびエクスポートのメカニズムについて詳しく説明します。
この項の内容は次のとおりです:
|
注意: ユーザー・エントリをインポートする場合、Oracle Unified Directoryでは、事前に暗号化されたパスワードがパスワード・ポリシーに一致していることを検証できません。したがって、事前に暗号化されたパスワードは、次のエラーで拒否されます:
|
スタンドアロン・ディレクトリ・サーバーにデータを移入するには、次の方法の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構造および索引が同一であることが必要です。 |
import-ldifを使用したデータのインポートimport-ldifコマンドは、LDIFファイルから読み取ったデータまたは第17.1.4項「MakeLDIFテンプレート・ファイルの作成」に基づいて生成されたデータを、ディレクトリ・サーバー・バックエンドに移入します。多くの場合、import-ldifのほうが、ldapmodifyを使用してエントリを追加するよりも大幅に高速です。
import-ldifコマンドでは、LDIFファイルと圧縮済ファイル(.zip)の両方がサポートされています。
インポート操作における次の局面に注意してください:
Oracle Berkeley DB Java Edition (JE)バックエンド全体への完全なインポートのほうが、JEバックエンドの分岐への部分インポートよりもパフォーマンスがよくなります。インポートするすべてのLDIFファイルで、UTF-8キャラクタ・セット・エンコードを使用している必要があります。
接尾辞のインポートは、リソースに負荷のかかる操作です。多数の接尾辞を含むLDIFファイルをインポートする場合、そのインポート操作を完了するにはヒープ領域不足になることがあります。そのようなLDIFファイルをインポートする前に、ヒープを可能なかぎり増やしておく必要があります。詳細は、第30章「パフォーマンス・チューニング」および第17.2項「大規模データ・セットのインポート」を参照してください。
LDIFファイルをインポートするためにroot権限は必要ありませんが、cn=Directory Managerなどのroot権限を持つユーザーとして認証される必要があります。
次の項では、import-ldifコマンドを使用してデータをインポートする方法について説明します:
import-ldifの操作モードimport-ldifコマンドには、操作にオンラインとオフラインの2つのモードがあります。
オンライン・モード。オンライン・モードでは、import-ldifは、実行中のディレクトリ・サーバー・インスタンスにアクセスし、インポート・タスクを登録します。このコマンドは、管理コネクタを通してSSL経由でタスク・バックエンドにアクセスします。詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。オンライン・モードは、いずれかの接続オプション(--hostname、--port、--bindDN、--bindPasswordFileなど)が指定されている場合は自動的に実行されます。
オンライン・インポートの場合でも、インポート中はバックエンドが使用できないことに注意してください。レプリケートされたトポロジでは、全体的なサービスは、依然としてreferral on update機能を通して使用可能です。詳細は、第17.13.1項「レプリケートされたトポロジでのリフェラル」を参照してください。
一般的に、オンライン・インポートを実行する予定である場合は、サーバーを起動するときにヒープを増やす必要があります。詳細は、第30章「パフォーマンス・チューニング」を参照してください。
オフライン・モード 。接続オプションが指定されていない場合、このコマンドはオフライン・モードで実行されます。オフライン・モードでは、import-ldifはディレクトリ・サーバー・インスタンスを介さずに、データベースに直接アクセスします。この場合、ディレクトリ・サーバーを停止する必要があります。
この手順では、インポートLDIFファイルで指定されている新しいエントリを持つリモートLDAPデータベースをインポートします。コマンドはオフライン・モードで実行され、それには、インポートする前にサーバーを停止する必要があります。
サーバーが実行中である場合は、それを停止します。
$ stop-ds
次の例のように、LDIFファイルをインポートします:
$ import-ldif -b dc=example,dc=com -n userRoot -l Example.ldif
このコマンドは、インポートに含めるデータの分岐のベースDN(-b)、データのインポート先のバックエンドID (-n)およびインポートに使用するLDIFファイル(-l)を指定します。
次の手順では、既存のバックエンドを、インポート・ファイルで指定されている新しいエントリに置き換えます。
サーバーが実行中である場合は、それを停止します。
$ stop-ds
LDIFファイルをインポートし、既存のデータを置き換えます。例:
$ import-ldif --includeBranch dc=example,dc=com --backendID userRoot \ --replaceExisting --ldifFile Example.ldif
次の手順では、インポート・ファイル内のエントリを、バックエンドの既存のエントリに追加します。
サーバーが実行中である場合は、それを停止します。
$ stop-ds
LDIFファイルをインポートし、既存のデータに新規データを追加します。例:
$ import-ldif --backendID userRoot --append --ldifFile new.ldif
import-ldifコマンドには、プロセス中に含めるまたは除外するベースDNを指定することによって、インポート・ファイルの一部をインポートするオプションがあります。
この例では、ベースDN (dc=example,dc=com)の下のすべてのエントリがインポートされ、ou=People,dc=example,dc=comの下のすべてのエントリが除外されます。
サーバーが実行中である場合は、それを停止します。
$ stop-ds
LDIFファイルの一部をインポートします。例:
$ import-ldif --includeBranch dc=example,dc=com \ --excludeBranch ou=People,dc=example,dc=com --backendID userRoot \ --replaceExisting --ldifFile Example.ldif
import-ldifコマンドには、データを含めるか除外するためのフィルタを使用することによって、インポート・ファイルの一部をインポートするオプションがあります。このメカニズムを使用する前に、それがどのように機能するのかを完全に把握してください。
この例では、検索フィルタl=Auckland (つまり、location=Auckland)に一致するエントリを除く、LDIFファイルの内容がインポートされます。
--includeFilterオプションは、インポート中に検索フィルタに一致するすべてのエントリが含められることを除いて、--excludeFilterと同様の方法で機能します。
サーバーが実行中である場合は、それを停止します。
$ stop-ds
除外フィルタを使用することによって、ファイルの一部をインポートします。例:
$ import-ldif --excludeFilter "(l=Auckland)" --backendID userRoot \ --replaceExisting --ldifFile Example.ldif
import-ldifコマンドには、--includeAttributeおよび--excludeAttributeのオプションを使用することで、インポート中に、それぞれ属性を含めるまたは除外するオプションがあります。このメカニズムを使用する前に、それがどのように機能するのかを完全に把握してください。
サーバーが実行中である場合は、それを停止します。
$ stop-ds
インポートを開始する前に、インポート・ファイルのエントリを表示します。
ディレクトリ・サーバーは、サーバーに接続することなく、インポート・ファイルを検索、変更、比較または削除するために役立つユーティリティを備えています。ldifsearchコマンドを使用して、インポート・ファイル内のエントリを表示できます。たとえば、Sam Carterのエントリを表示するには、次のコマンドを使用します:
$ ldifsearch -b dc=example,dc=com --ldifFile Example.ldif "(cn=Sam Carter)" dn: uid=scarter,ou=People,dc=example,dc=com objectClass: person objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: top givenname: Sam uid: scarter cn: Sam Carter telephonenumber: +1 408 555 4798 sn: Carter userpassword: sprain roomnumber: 4612 mail: scarter@example.com l: Sunnyvale ou: Accounting ou: People facsimiletelephonenumber: +1 408 555 9751
このエントリでは、telephonenumber属性の下にroomnumber属性があることに注意します。
すべてのエントリについてroomnumber属性を除外して、ファイルをインポートします。
$ import-ldif --excludeAttribute "roomnumber" --backendID userRoot \ --replaceExisting --ldifFile Example.ldif
サーバーを起動します。
$ start-ds
ldapsearchを実行し、インポートを確認します。
次の例は、Sam Carterのエントリからroomnumber属性が削除されていることを示しています。
$ ldapsearch --port 1389 --baseDN dc=example,dc=com --bindDN "cn=Directory Manager" \ --bindPassword password "(cn=Sam Carter)" dn: uid=scarter,ou=People,dc=example,dc=com \ objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: top givenName: Sam uid: scarter cn: Sam Carter sn: Carter telephoneNumber: +1 408 555 4798 ou: Accounting ou: People l: Sunnyvale mail: scarter@example.com facsimileTelephoneNumber: +1 408 555 9751
import-ldifユーティリティは圧縮LDIFファイルをサポートしています。
サーバーが実行中である場合は、それを停止します。
$ stop-ds
圧縮LDIFファイルをインポートします。
$ import-ldif --includeBranch dc=example,dc=com --excludeBranch "ou=People,dc=example,dc=com" --ldifFile Example.ldif \ --backendID userRoot --replaceExisting --isCompressed
import-ldifコマンドは、インポート・プロセス中に拒否またはスキップされたエントリについて出力ファイルに書き込む方法を提供します。これにより、LDIFファイルの簡単なデバッグが可能です。拒否されたエントリは、ディレクトリ・サーバーによって、追加されるエントリがスキーマ違反が原因で拒否された場合に発生します。スキップされたエントリは、指定されているベースDNの下にエントリを配置できない場合に発生します。
サーバーが実行中である場合は、それを停止します。
$ stop-ds
--rejectFileおよび--skipFileのオプションを使用して、ファイルをインポートします。
--overWriteオプションを使用して、2つのファイル内の前のアイテムを置換することもできます。このオプションを指定しない場合、ディレクトリ・サーバーでは、新しい拒否されたエントリおよびスキップされたエントリを既存のファイルに追加します。
$ import-ldif --backendID userRoot --append --ldifFile new.ldif --overwrite --rejectFile rejected.ldif --skipFile skipped.ldif
rejectFileおよびskipFileの内容を表示し、インポート中にどのエントリが拒否またはスキップされたのかを判別します。例:
$ more rejected.ldif # Entry ou=Contractors,dc=example,dc=com read from LDIF starting at line 1 is not valid because it violates the server's schema configuration: Entry ou=Contractors,dc=example,dc=com violates the Directory Server schema configuration because it includes attribute changeType which is not allowed. changetype: add objectclasses defined in that entry objectclass: top objectclass: organizationalUnit ou: Contractors ou: Product Testing ou: Product Dev ou: Accounting ... $ more skipped.ldif # Skipping entry ou=People,dc=example,dc=com because the DN is not one that should be included based on the include and exclude branches objectclass: top objectclass: organizationalunit ou: People aci: (target ="ldap:///ou=People,dc=example,dc=com")(targetattr ="userpassword || telephonenumber || facsimiletelephonenumber")(version 3.0;acl "Allow self entry modification"; allow (write)(userdn = "ldap:///self");) aci: (target ="ldap:///ou=People,dc=example,dc=com")(targetattr h3.="cn || sn || uid") (targetfilter ="(ou=Accounting)")(version 3.0;acl "Accounting Managers Group Permissions"; allow (write) (groupdn = "ldap:///cn=Accounting Managers,ou=groups,dc=example,dc=com");) aci: (target ="ldap:///ou=People,dc=example,dc=com")(targetattr h3.="cn || sn || uid") (targetfilter ="(ou=Human Resources)")(version 3.0;acl "HR Group Permissions"; allow write)(groupdn = "ldap:///cn=HR Managers,ou=groups,dc=example,dc=com");) aci: (target ="ldap:///ou=People,dc=example,dc=com")(targetattr h3.="cn ||sn || uid") (targetfilter ="(ou=Product Testing)")(version 3.0;acl "QA Group Permissions"; allow (write)(groupdn = "ldap:///cn=QA Managers,ou=groups,dc=example,dc=com");) aci: (target ="ldap:///ou=People,dc=example,dc=com")(targetattr h3.="cn || sn || uid") (targetfilter ="(ou=Product Development)")(version 3.0;acl "Engineering Group Permissions"; allow (write)(groupdn = "ldap:///cn=PD Managers,ou=groups,dc=example,dc=com");) ...
ディレクトリ・サーバーにはJavaユーティリティmakeLDIFが組み込まれており、それを使用してインポート向けのサンプル・データを生成できます。makeLDIFユーティリティには、テンプレート・ファイルが必要です。独自のテンプレート・ファイルを作成するか、INSTANCE_DIR/OUD/config/MakeLDIF/example.templateにあるテンプレート・ファイルを必要に応じて編集して使用できます。詳細は、第17.1.4項「MakeLDIFテンプレート・ファイルの作成」および付録A「make-ldif」を参照してください。
サーバーが実行中である場合は、それを停止します。
$ stop-ds
テンプレート・ファイルを使用して、データをインポートします。
このサンプル・テンプレートによって、指定したバックエンドに10,003個のサンプル・エントリが生成されます。
$ import-ldif --backendID userRoot --templateFile example.template \ --randomSeed 0
import-ldifユーティリティは、サーバーをオンラインにした状態で実行することもできます。オンライン・モードでは、このコマンドは、管理コネクタを通してSSL経由でタスク・バックエンドにアクセスします。オンライン・モードでこのコマンドを実行するには、SSL証明書の信頼方法など関連する接続オプションを指定する必要があります。この例では、-Xオプションを使用して、すべての証明書を信頼します。詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。
適切な接続オプションを指定して、import-ldifコマンドを実行します。
$ import-ldif -h localhost -port 4444 -D "cn=Directory Manager" -j pwd-file -X \ -l /ldif-files/example.ldif
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
詳細は、第14.4項「タスクとしてのコマンドの構成」を参照してください。
export-ldifを使用したデータのエクスポートexport-ldifコマンドを使用して、ディレクトリ・サーバー・バックエンドからデータをエクスポートします。このコマンドは、次のタスクに有効です:
ディレクトリ・データのバックアップ
他のアプリケーションへのデータのエクスポート
ディレクトリ・トポロジへの変更後のデータベースへの移入
レプリケートされたトポロジでのマスター・サーバーの再初期化
|
注意:
|
次の項では、export-ldifコマンドを使用してデータをエクスポートする方法について説明します:
export-ldifの操作モードexport-ldifコマンドには、操作にオンラインとオフラインの2つのモードがあります。
オンライン・モード。オンライン・モードでは、export-ldifは、実行中のディレクトリ・サーバー・インスタンスにアクセスし、エクスポート・タスクを登録します。このモードは、LDAP接続オプション(--hostname、--port、--bindDN、--bindPasswordFileなど)が使用されている場合は自動的に実行されます。このコマンドは、管理コネクタを通してSSL経由でタスク・バックエンドにアクセスします。詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。
オフライン・モード 。接続オプションが指定されていない場合、このコマンドはオフライン・モードで実行されます。オフライン・モードでは、export-ldifはディレクトリ・サーバー・インスタンスを介さずに、データベースに直接アクセスします。この場合、ディレクトリ・サーバーを停止する必要があります。
詳細は、付録A「export-ldif」を参照してください。
サーバーが実行中である場合は、それを停止します。
$ stop-ds
指定したLDIFファイルにバックエンドをエクスポートします。
$ export-ldif --includeBranch "dc=example,dc=com" --backendID userRoot \ --ldifFile example.ldif
export-ldifコマンドには、処理中に含めるまたは除外するベースDNおよびその子を指定することでバックエンドの一部をエクスポートするオプションがあります。
サーバーが実行中である場合は、それを停止します。
$ stop-ds
バックエンドの一部をエクスポートします。
この例では、ou=People,dc=example,dc=comの下のエントリのみがエクスポートされます。
$ export-ldif --includeBranch ou=People,dc=example,dc=com --backendID userRoot \ --ldifFile example-people.ldif
ldifsearchコマンドを使用して、エクスポートされたファイルを検証します。
ldifsearchコマンドは、ディレクトリ・サーバーに接続することなく、LDIFファイル内のエントリを検証します。これは、ldapsearchコマンドと類似した方法で使用できます。例:
$ ldifsearch -b dc=example,dc=com --ldifFile export.ldif "(objectclass=*)"
dn: ou=People,dc=example,dc=com
objectClass: organizationalunit
objectClass: top
ou: People
dn: uid=scarter,ou=People,dc=example,dc=com
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: top
givenName: Sam
uid: scarter
cn: Sam Carter
sn: Carter
telephoneNumber: +1 408 555 4798
userPassword: {SSHA}Ocpp2P4sImz2MziL69AUG9+khdIhFpmU4B5mvA==
roomNumber: 4612
ou: Accounting
ou: People
l: Sunnyvale
mail: scarter@example.com
facsimileTelephoneNumber: +1 408 555 9751 ...
export-ldifコマンドには、検索フィルタを使用することで、バックエンドの一部をエクスポートするオプションがあります。ディレクトリ・サーバーでは、フィルタに一致するすべてのエントリが含められるか除外されます。このメカニズムを使用する前に、それがどのように機能するのかを完全に把握してください。
この例では、検索フィルタl=Cupertino (つまり、location=Cupertino)に一致するエントリのみがエクスポートされます。--excludeFilterオプションは、エクスポート中にフィルタに一致するすべてのエントリが除外されることを除いて、--includeFilterと同様の方法で機能します。
サーバーが実行中である場合は、それを停止します。
$ stop-ds
--includeFilterオプションを使用することによって、バックエンドの一部をエクスポートします。
$ export-ldif --includeFilter "(l=Cupertino)" --backendID userRoot \ --ldifFile export.ldif
export-ldifユーティリティには、--includeAttributeおよび--excludeAttributeのオプションを使用することで、エクスポート中に、それぞれ属性を含めるまたは除外するオプションがあります。このメカニズムを使用する前に、それがどのように機能するのかを完全に把握してください。
サーバーの実行中に、ldapsearchコマンドを使用することによって、サンプル・エントリを表示します。例:
$ ldapsearch --baseDN dc=example,dc=com "(cn=Sam Carter)" dn: uid=scarter,ou=People,dc=example,dc=com objectClass: person objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: top givenname: Sam uid: scarter cn: Sam Carter telephonenumber: +1 408 555 4798 sn: Carter userpassword: sprain roomnumber: 4612 mail: scarter@example.com l: Sunnyvale ou: Accounting ou: People facsimiletelephonenumber: +1 408 555 9751
サーバーを停止します。
$ stop-ds
--includeAttributeオプションを使用して、エクスポートに含める属性を使用して、バックエンドをエクスポートします。
--includeAttributeオプションは、含める属性ごとに複数回使用できます。この例では、最上位レベルの属性のみがエクスポートされます。
$ export-ldif --backendID userRoot --includeAttribute dn --includeAttribute dc \ --includeAttibute cn --includeAttribute sn --includeAttribute givenname \ --includeAttribute objectclass --includeAttribute ou --includeAttribute uid \ --ldifFile export.ldif
ldifsearchコマンドを使用して、エクスポート・ファイルを検証します。
エラーが発生した場合、サーバーではそのコマンドの処理が続行されます。
$ ldifsearch --baseDN dc=example,dc=com --ldifFile export.ldif "(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 cn: Directory Administrators ou: Groups dn: ou=People,dc=example,dc=com objectClass: organizationalunit objectClass: top ou: People ...
export-ldifコマンドで、出力LDIFファイルを圧縮できます。
サーバーが実行中である場合は、それを停止します。
$ stop-ds
LDIFにエクスポートしてから、そのファイルを圧縮します。
$ export-ldif --backendID userRoot --ldifFile export.ldif --compress
export-ldifコマンドは、サーバーをオンラインにした状態で実行することもできます。オンライン・モードでは、このコマンドは、管理コネクタを通してSSL経由でタスク・バックエンドにアクセスします。詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。オンライン・モードでこのコマンドを実行するには、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
export-ldifユーティリティは、将来の日付でエクスポートをスケジュールするための--startオプションを備えています。manage-tasksユーティリティを使用することで、このスケジュール済タスクを表示できます。このコマンドは、管理コネクタを通してSSL経由でタスク・バックエンドにアクセスします。詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。エクスポート・タスクをスケジュールするには、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
make-ldifコマンドは、テンプレート・ファイルを使用して、LDIFファイルを生成する方法を定義します。この手法では、目的の結果を生成するためにコードを変更することを必要とせずに柔軟性が得られます。この項では、make-ldifコマンドを使用して、カスタマイズされたLDIFファイルを作成する方法を説明します。
テンプレート・ファイルには、最大4つのセクションを含めることができ、それらは次の順序で指定する必要があります:
カスタム・タグのインクルードは、カスタム・タグをロードし、make-ldifテンプレートを処理するときにそれらを使用できるうにするメカニズムを提供します。これは、次のようにincludeディレクティブを使用して実行します:
include com.example.opends.makeldif.MyCustomTag
指定したクラスは、クラス・パスに含まれている必要があり、org.opends.server.tools.makeldif.Tagクラスのサブクラスである必要があります。カスタム・タグの開発の詳細は、第17.1.4.3項「カスタム・タグの定義」を参照してください。
make-ldifで提供されている標準置換タグはすべて、自動的に使用可能であるため、明示的なincludeディレクティブは必要ありません。
最初のセクションは、テンプレート・ファイルに必ず含める必要があり、そこでグローバル置換変数を定義します。グローバル置換変数は、テンプレート・ファイルで後で参照できるテキストの文字列を定義するために使用され、各行がメモリーに読み込まれるときに自動的に置換されます(Cプリプロセッサによって、コード内のマクロ゛かそれらの定義済の値と置換されるのに似ています)。たとえば、次の置換変数定義によって、dc=example,dc=comという値を持つsuffixという名前のグローバル置換変数が作成されます:
define suffix=dc=example,dc=com
グローバル置換変数が定義されているときは、その縁数名が大カッコで囲まれている場合(たとえば、[suffix])、トークンがその置換変数に対して定義された値と置換されます。
最初の空白行とその後に続く1つ以上の置換変数定義によって示されるようにすべての置換変数定義が読み取られると、テンプレート・ファイルから読み取られるすべて残りの行が、1行ずつ処理されます。大カッコ内の置換変数名のすべてのオカレンスは、その変数の値で置換されます。置換は、テンプレート・ファイルがメモリーに読み取られるときに実行されるため、置換変数は、分岐、テンプレート定義、さらにタグ内などどの場所にも配置できます。
テンプレート・ファイルに定義されているグローバル置換変数がある場合、それらは、ファイルの先頭に配置する必要があり、それらの間に空白文字を入れないようにします。ただし、置換変数は必要ありません。置換変数がない場合、テンプレート・ファイルは分岐定義から開始する必要があります。
分岐定義は、生成された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属性に対して同様の定義があります:
oorganizationオブジェクト・クラスのエントリを作成します。
ouorganizationalUnitオブジェクト・クラスのエントリを作成します。
ccountryオブジェクト・クラスのエントリを作成します。
分岐エントリに対して、他のどのような種類の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テンプレートは、テンプレート・ファイルで後で定義する必要があります。詳細は、第17.1.4.1.4項「テンプレート定義」を参照してください。
分岐エントリは、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
この追加のテキストは、静的にするか、任意の定義済グローバル置換変数を含めるか、またはテンプレート定義で使用できる置換タグのサブセットを含めることができます。使用可能なタグの概要、および分岐定義でどのタグが使用できるかに関する情報は、第17.1.4.2.1項「標準置換タグ」を参照してください。
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が提供する柔軟性を示しています。テンプレート定義に含めることができるタグは、後続の項で説明します(第17.1.4.2.1項「標準置換タグ」および第17.1.4.2.2項「属性値参照タグ」を参照してください)。
テンプレート定義の最上部には、テンプレート自体に関する情報を示す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キーワードの場合と同様に、テンプレート・ファイルが、直接または間接的にそれ自体から継承される再帰的ループが作成されないようにすることが重要です。
make-ldifによって、多様なデプロイメントをシミュレートするために使用できるLDIFファイルを生成できるようにするために、テンプレートで使用するための多数のタグが定義されています。この項では、make-ldifテンプレート・ファイルで使用できる標準セットのタグについて説明します。第17.1.4.3項「カスタム・タグの定義」の説明に従って、カスタム・タグを作成することもできます。
この項には次のトピックが含まれます:
make-ldif標準置換タグは、山カッコで囲まれた特殊な要素(小なり記号(<)で始まり、大なり記号(>)で終わる)であり、生成された値に動的に置換されます。標準置換タグには、引数を必要としないもの(たとえば、<first>)があります。他のものは引数を取り、その場合、最初にタグ名、次にコロン、そして、各引数の間をコロンで区切った引数のリストが続きます(たとえば、<random:numeric:5>)。引数では、通常、大文字小文字が区別されますが、タグ名では大文字小文字が区別されまません。
次のタイプの標準置換タグは、現在、make-ldifの一部として組み込まれています:
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標準置換タグは、指定されているファイルの行で置換されます。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標準置換タグは、config/MakeLDIF/first.namesファイルから取得された名前で置換されます。名前と姓の組合せが常に一意になるなど、<first>タグと<last>タグの間には特別な関係があります。名前ファイルと姓ファイルからの考えられる組合せをすべて使用し尽した場合、make-ldifによって、整数値が姓に追加され、値は確実に常に一意になります。
<first>タグは、引数を取りません。これは、テンプレート定義内でのみ使用できます。分岐定義で使用することはできません。
GUID標準置換タグは、ランダムに生成されたGUID (globally-unique identifier)値で置換されます。生成されたすべてのGUID値は、一意になります。生成される値は、それぞれ8、4、4、4および12桁からなるダッシュで区切られたグループに分かれている32桁の16進数です(たとえば、12345678-90ab-cdef-1234-567890abcdef)。
<guid>タグは、引数を取りません。これは、分岐とテンプレートの両方の定義で使用できます。
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標準置換タグは、それ自体の値は生成せず、したがって、常に空の文字列で置換されます。ただし、その値によって、指定した属性または属性値が存在するかどうかに基づいて、エントリないに属性がまとめて表示されないようにすることができます。
たとえば、次のテンプレートについて考えてみます:
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標準置換タグは、config/MakeLDIF/last.namesファイルから取得された姓で置換されます。名前と姓の組合せが常に一意になるなど、<first>タグと<last>タグの間には特別な関係があります。名前ファイルと姓ファイルからの考えられる組合せをすべて使用し尽した場合、make-ldifによって、整数値が姓に追加され、値は確実に常に一意になります。
<last>タグは、引数を取りません。これは、テンプレート定義内でのみ使用できます。分岐定義で使用することはできません。
List標準置換タグは、指定されている値のリストから選択された文字列で置換されます。使用される値は、Listタグの引数として指定する必要があります(少なくとも1つの引数を指定する必要があります)。オプションで、各値の後にセミコロンと、その値の相対的な重みを指定する整数値を続けることができます。値に重みが含まれていない場合、そのアイテムの重みは1と想定されます。重みは、それに関連する値がリスト内の他のすべての値と比較して選択される頻度を制御するために使用します。
たとえば、リストされているすべての色が同じ重みを持つ赤、緑、青の色のリストを選択するには、次のものを使用できます:
<list:red:green:blue>
赤い色を、他のいずれの色に対しても2倍の頻度で表示する場合は、次のものを使用できます:
<list:red;2:green;1:blue;1>
この場合、greenとblueの要素の後の1は、技術的には不要です。それは、重みを明示的に含まないアイテムの重みは1であるためですが、この例では明確にするために指定されています。
このタグは、分岐とテンプレートの両方の定義で使用できます。
ParentDN標準置換タグは、生成されるエントリの親エントリのDNで置換されます。これは常に使用可能です。
このタグは、引数を取りません。これは、テンプレート定義内でのみ使用できます。これは分岐定義では使用できません。
Presence標準置換タグは、それ自体の値は生成せず、したがって、常に空の文字列で置換されます。ただし、その値は、関連付けられた属性を、指定した割合でエントリに表示するために使用できます。
たとえば、次のテンプレートについて考えてみます:
template: example
rdnAttr: cn
objectClass: top
objectClass: untypedObject
objectClass: extensibleObject
cn: <guid>
displayName: <presence:50>{cn}
この場合、displayName属性が存在するのは、生成されるエントリの約50%のみになります。
Presenceタグには、1つの引数が必要であり、それは0と100の間の整数値で、関連する属性を持つエントリの割合を示します。
このタグは、分岐とテンプレートの両方の定義で使用できます。
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(つまり、左端のDNコンポーネント)で置換されます。そのRDNがまだ使用できない場合(生成されるエントリではRDN属性に値が割り当てられていないためなど)、それが空の文字列で置換されます。通常、このタグが使用される前に、先にテンプレート内ですべてのRDN属性に必ず値が割り当てられるようにします。このタグの動作は、値が1である1つの引数を使用して使用されている場合(つまり、<dn:1>)のDNタグの動作と同一です。
RDNタグは、引数を取りません。これは、分岐とテンプレートの両方の定義で使用できます。
Sequential標準置換タグは、1つの整数値で置換されます。各エントリには、連続して増加する値が指定されます(たとえば、最初のエントリにはゼロの値、次のエントリには1の値などのように指定されます)。
このタグは、ゼロ、1または2個の引数を取ることができます:
引数がない(つまり、タグが<sequential>である)場合、最初の値はゼロになり、その値は新しい分岐ごとにゼロにリセットされます。
追加の引数が1つある場合、それは、使用する初期値を指定する整数値である必要があります(たとえば、<sequential:1000>では、0のかわりに1000から値の生成を開始します)。値は、新しい分岐ごとに、指定した初期値にリセットされます。
引数が2つある場合は、最初のものは初期値を指定する整数であり、2番目のものは新しい分岐が始まるたびにカウンタをリセットするかどうかを示すtrueまたはfalseのブール値である必要があります。
このタグは、分岐とテンプレートの両方の定義で使用できます。
_DN (先頭のアンダースコア文字に注意)標準置換タグは、生成されるエントリのDNで置換されますが、DNコンポーネント間ではカンマのかわりにアンダースコアが使用されます。カンマのかわりにアンダースコアを使用することを除けば、これは、DNタグとまったく同じように動作します。したがって、左から(値が負の場合は右から)、含めるコンポーネントの数を指定するオプションの整数引数も取ることができます。
このタグは、分岐とテンプレートの両方の定義で使用できます。
_ParentDN (先頭のアンダースコア文字に注意)標準置換タグは、生成されるエントリの親エントリのDNで置換されますが、DNコンポーネント間ではカンマのかわりにアンダースコアが使用されます。これは常に使用可能です。
このタグは、引数を取りません。これは、テンプレート定義内でのみ使用できます。これは分岐定義では使用できません。
属性値参照タグは、同じエントリの指定した属性の値で、そのタグを置換するために使用できます。それは、目的の属性の名前を中カッコで囲むことによって使用されます。たとえば、{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
指定した長さが、指定した属性の値よりも長い場合、埋込みが追加されることなく、その値全体が使用されます。それ以外の場合、指定した個数の文字がその値から取得されます。
make-ldif構文のすべてのタグには、現在、同一の優先度が指定されています。したがって、それらは、テンプレート定義内で配置されている順序で、上から下に、指定された行内では左から右に評価されます。別のタグ内に1つのタグを埋め込むことはできません。
make-ldifユーティリティは、拡張可能に設計されているため、新しいタグをテンプレート・ファイル内で定義および使用できます。
すべてのタグは、org.opends.server.tools.makeldif.Tag抽象クラスのサブクラスであることが必要です。カスタム・タグ定義には、次のメソッドを含める必要があります:
public String getName()これにより、タグを参照するために使用する名前が取得されます。それが返す値は、サーバーによって使用される他のすべてのタグの間で一意である必要があります。
public boolean allowedInBranch()これは、そのタグが分岐定義で許可されるかどうかを示します。それがtrueの値を返す場合、そのタグは、分岐とテンプレートの両方の定義で使用できます。それがfalseの値を返す場合、そのタグは、テンプレート定義で使用できますが、分岐定義では使用できません。
public void initializeForBranch(TemplateFile templateFile, Branch branch, String[] arguments, int lineNumber, List<String> warnings)これは、タグが分岐定義で使用される場合に必要な初期化を実行します。allowedInBranch()がfalseを返す場合は、これを実装する必要はありません。
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)これは、エントリを生成するときに、関連付けられたタグを置換するために使用される値を生成します。
make-ldifで使用可能なタグはすべて、org.opends.server.tools.makeldifパッケージに含められています。それらは、カスタム・タグの実相に何が関与しているのかを把握するための参照に使用できます。
|
注意: カスタム・タグを定義する場合、それを必要とする可能性があるテンプレート・ファイルで使用できるようになっているいことを確認してください。これは、 |
この項では、ディレクトリ・サーバーに大きなデータ・セットをインポートする際のパフォーマンスの向上に関するヒントを示します。デフォルトでは、サーバーは、固定したセットのパラメータでデータをインポートします。デフォルトの動作を変更するには、次の2通りがあります:
import-ldifコマンドを実行する際は、特定のオプションを指定します。
詳細は、第17.2.1項「インポート・オプションの設定」を参照してください。
import-ldifコマンドを実行する前に、dsjavapropertiesコマンドを使用して、適切なJava引数を設定します。
詳細は、第17.2.2項「JVMおよびJava引数のチューニング」を参照してください。
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をヒットしないように、すべての部分文字列索引をオフにする必要があります。
JVMヒープのチューニングは、import-ldifコマンドのパフォーマンスに不可欠です。import-ldifコマンドでは、それが必要とするJVMヒープの容量を制限することが試みられますが、多数のエントリをインポートする場合、可能なかぎり多くのJVMヒープをimport-ldifに割り当てる必要があります。
次の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操作のレスポンス時間を最小化できますが、サーバーの全体的なパフォーマンス(スループット)に若干の影響を与える可能性があります。
メモリー要件を計算する場合は、次の手順を実行します:
instance-dir/OUD/config/java.propertiesファイルを編集し、次の値を設定します:
overwrite-env-java-args=true import-ldif.offline.java-args=-Xms2560M -Xmx2560M -XX:+UseParallelGC -XX:+UseConcMarkSweepGC
dsjavapropertiesコマンドを実行します:
$ bin/dsjavaproperties
|
注意:
|
Oracle Unified Directoryは、様々なリポジトリ・タイプをサポートする拡張可能なフレームワークを提供します。ディレクトリ・サーバーは、そのプライマリ・バックエンドとしてBerkeley DB Java Edition (JE)を使用します。JEバックエンドには、他のデータベースと比較していくつかの利点があります。それは、それが、データ・セット(小さなものから非常に大きなものまで)に対して、ACIDセマンティクスに対する完全なサポートとともに、高性能かつスケーラブルなトランザクショナルBツリー・データベースを提供するためです。また、そのエントリを、エンコードされた形式で格納し、高速かつ効率的なデータ取得のための索引を提供することも可能です。
この項の内容は次のとおりです:
JEバックエンドにディレクトリ・データを保持するために、Oracle Unified Directoryは、全体バックアップおよび増分バックアップをサポートする効率的なバックアップおよびリストア・ユーティリティを備えています。全体バックアップでは、ディレクトリ・データ・ファイルが、圧縮済アーカイブ・ファイルとして環境に保存されます。増分バックアップでは、前回のバックアップ以降に書き込まれたファイルのみが、前回のバックアップ以降に変更されていないファイルの名前のリストとともに保存され圧縮されます。Oracle Unified Directoryでは、リストアを簡単にするためにバックアップ・バックエンドにそのバックアップ情報が格納されます。
ディレクトリ・サーバー・バックアップは、ローカル・ディスク上またはリモート・ディスク上で、たとえば、ネットワーク接続ストレージ(NAS)で実行できます。ローカルでバックアップを実行する場合、セキュリティ上の理由から、別のマシンまたはファイル・システムにバックアップをコピーして保存します。
データのバックアップとリストアを開始する前に、次の事項を考慮します:
ご使用のディレクトリ・サービス・システムに対して実行可能なバックアップおよびリストア計画を設計する必要があります。たとえば、増分バックアップを毎日実行し、全体バックアップを少なくとも週に1回実行することができます。バックアップ・プロセスおよびリストア可能かどうかを定期的にテストしてください。データをリストアするために、多くの会社では、レプリケートされたサーバーからディレクトリ・サーバーをリストアし、それによって、ディレクトリ・データの最も更新されているコピーが使用されるようにしています。ディレクトリ・データが損傷し(たとえば、エントリが欠落し)、損傷したデータが他のサーバーにレプリケートされた場合には、バックアップ・テープが必要になります。
障害時リカバリ計画が策定済であることを確認します。障害時リカバリは、破局的なイベント、データ破損、またはデータの不正操作が発生した場合に必要です。企業は、独自の計画を策定するか、サード・パーティの専門家にその作業をアウトソーシングします。詳細は、第17.3.4項「障害時リカバリのためのバックアップ」を参照してください。
バックアップを格納する場所が確保されていることを確認します。アーカイブ済データ、構成ディレクトリ、スキーマ・サブディレクトリ、およびご使用のサーバーのインストール・ディレクトリを、1つの場所にまとめて保存します。これらのアイテムはすべて、サーバーをリストアするときに必要です。
ディレクトリ・サーバーは、データベースをバックアップするための効率的なコマンドライン・ユーティリティ(backup)を備えています。backupコマンドは、ただちに実行することも、タスクとしてスケジュールすることもできます。バックアップがスケジュール済の場合、このコマンドは管理コネクタを使用してSSL経由でサーバーにアクセスし、バックアップ・タスクを登録します。接続オプションが指定されていない場合、このコマンドはただちに実行されます。
次の手順は、様々なバックアップ・シナリオにおけるbackupコマンドの使用を示しています。
--backUpAllオプションを使用することで、すべてのバックエンドをバックアップできます。
次のコマンドは、スタンドアロン・ディレクトリ・サーバーで実行され、すべてのデータベースをバックアップすることを指定し、バックアップ・ファイルを圧縮し、ファイルを指定した場所に保存します。
$ 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
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
増分バックアップでは、最後のバックアップ(増分または全体)以降に発生した変更のみが保存されます。増分バックアップの主な利点は、全体バックアップと比べてシステムのバックアップが高速であることです。増分バックアップの短所は、各増分バックアップをリストアする必要があり、全体リストアよりも時間と注意が必要なことです。
増分バックアップを実行するには、次のように--incrementalオプションを指定してbackupコマンドを実行します:
$ backup --backUpAll --incremental --compress --backupDirectory /tmp/backup
保存するバックエンドを指定する--backendIDオプションを使用することによって、1つのバックエンドバックアップできます。
list-backendsコマンド実行することによって、サーバー上に構成されているバックエンドをリストします。例:
$ list-backends Backend ID Base DN -------------- ----------------- adminRoot cn=admin data ads-truststore cn=trust-store backup cn=backups config cn=config monitor cn=monitor schema cn=schema tasks cn=tasks userRoot dc=example,dc=com
--backendIDオプションを指定してbackupコマンドを実行します。
たとえば、userRootバックエンドをバックアップするには、次のコマンドを実行します:
$ backup --backendID userRoot --backupDirectory /tmp/backup
1つはバックエンドバックアップし、レプリケーションが構成されている場合、そのバックエンドに行うすべての変更は、レプリケーション・サーバーの変更ログに格納されます。そのバックエンドをリストアするときに、レプリケーション・サーバーによってそのバックエンドが最新のものではないことが検出され、そのバックアップ以後に行われた変更がリプレイされます。この動作は、レプリケートされたトポロジ内のディレクトリ・サーバーが1つのみである場合でも実行されます。それは、変更がレプリケーション・サーバーに保存されているためです。
この動作を実行しないようにするには、レプリケートされた環境にすべてのバックエンドをバックアップします。これによって、データおよびレプリケーション・サーバーがバックアップされます。この場合、リストアが行われる際、ディレクトリ・サーバーおよびレプリケーション・サーバーはバックアップ前の状態にリストアされ、後続の変更はメモリー内に残りません。
list-backendsコマンド実行することによって、サーバー上に構成されているバックエンドをリストします。例:
$ list-backends Backend ID Base DN -------------- ----------------- adminRoot cn=admin data ads-truststore cn=trust-store backup cn=backups config cn=config monitor cn=monitor schema cn=schema tasks cn=tasks userRoot dc=example,dc=com
--incrementalオプションを指定してbackupコマンドを実行します。
$ backup --incremental --backendID userRoot --backupDirectory /tmp/backup
ディレクトリ・サーバーは、バックアップやリストアなどの管理タスクを実行するためにタスク・バックエンドを提供しています。-tまたは--startオプションを使用することで、バックアップまたはリストアの開始時間を指定できます。これらのオプションを指定しない場合、タスクのスケジュール後ただちにユーティリティは終了します。ただちに実行するようにタスクをスケジュールし、タスクのスケジュール後ただちにユーティリティを終了するには、開始時間の値として0を指定します。-tまたは--startオプションを省略すると、ユーティリティは、タスクをただちに実行するようにスケジュールし、タスクの進行状況を追跡し、ログ・メッセージを使用できるように出力し、タスクが完了したときに終了します。
タスク・バックエンドへのアクセスは、管理コネクタを介してSSL経由で提供されます。したがって、バックアップをタスクとしてスケジュールする場合、SSL証明書の信頼方法を指定する必要があります。この例では、バックアップを将来の時刻に実行するようにスケジュールします。-Xオプションは、サーバーによって定義されるすべての証明書を信頼することを指定します。詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。
次のオプションを指定してbackupコマンドを実行します:
$ backup --port 4444 --bindDN "cn=Directory Manager" \ --bindPasswordFile pwd-file -X \ --backUpAll --backupDirectory /tmp/backups --start 20080601121500 \ --completionNotify admin@example.com --errorNotify admin@example.com
manage-tasksコマンドを使用することで、このスケジュール済タスクに関する情報を表示します。例:
$ manage-tasks --port 4444 --bindDN "cn=Directory Manager" \ --bindPasswordFile pwd-file -X --info 2008040210324704 --no-prompt
ディレクトリ・サーバー・インスタンスのすべての構成設定は、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
ディレクトリ管理者およびシステム管理者は、自然障害、人為的障害、または破局的な障害が発生した場合の障害時リカバリ計画を策定しておく必要があります。ディレクトリ・サービスが複数の個別のサーバーに分散されている場合、すべてのサーバーを個別にバックアップするか、すべてのディレクトリ・データを中央からバックアップします。
かわりに、バックアップおよびリストア計画としてレプリケーションを検討してください。レプリケーションは、別のレプリケートされたサーバーからのより高速なリストアおよびより更新されたデータを提供します。詳細は、第17.3.7項「レプリケートされたディレクトリ・サーバーのリストア」を参照してください。
--backUpAllオプションを使用することですべてのバックエンドのバックアップを実行します。例:
$ backup --backUpAll --backupDirectory /tmp/backup
構成ディレクトリINSTANCE_DIR /OUD/configをコピーします。
schemaサブディレクトリがINSTANCE_DIR /OUD/configディレクトリ内に存在していることを確認します。
INSTANCE_DIR/OUD/logs内のファイルをコピーします。
インストール・ディレクトリのコピーを作成します。
アーカイブ済データ、構成ディレクトリ、スキーマ・サブディレクトリ、ログ・ファイルおよびインストール・ディレクトリを、1つの場所にまとめて保存します。
サーバーをリストアするときにはすべてのアイテムが必要です。
特定のデプロイメントに対して、ファイル・システム・スナップショット・テクノロジは、従来のバックアップに対する実行可能な代替手段を提供します。Solarisシステムでは、ZFSによって、領域効率がよく、迅速に作成でき、システム間で移植可能なファイル・システム・スナップショットが可能です。データ・センターごとに1つ、または2つ(1つのデータ・センターでサービス全体を実行している場合)の専用ディレクトリ・サーバーを使用している場合は、障害時リカバリ計画の一部としてデータをリストアするために有効かつ冗長なソリューションをデプロイします。
この項には次のトピックが含まれます:
ディレクトリ・サーバーは、バックアップ専用であるため、まだサーバーを読取り専用のレプリカとして構成していない場合は、そのように構成します。
$ dsconfig -h host -p 4444 -D "cn=Directory Manager" -j pwd-file -X -n \ set-global-configuration-prop --set writability-mode:internal-only
読取り専用のレプリカのスナップショットからサーバーをリストアする場合、リストアされるサーバーは、トポロジ内の他のレプリカと情報交換した後、書込み可能に設定されるまではレプリケーション・トラフィックのみを受け入れます。
ZFSスナップショットを取ります。
たとえば、ディレクトリ・サーバー・ファイルが、zpool/DS_FSに対応するファイル・システムに格納されている場合、このコマンドは次のとおりです:
$ zfs snapshot zpool/DS_FS@{todays_date}
スナップショットを他のストレージにバックアップします。
$ zfs send zpool/DS_FS@{today_date} > /backups/DS_FS.{today_date}.zfs
スナップショットをレプリケーションのパージ遅延より長く保持しないでください。それは、スナップショットからリストアするときに、レプリケーション・メカニズムによって、レプリカ上のすべての欠落している変更内容がリプレイ可能であることが必要なためです。
バックアップzpoolをインポートします。
マウント・ポイントとして/backupsを使用して、バックアップ・プールにアクセスするためのZFSファイル・システムを作成します。
リストア対象のディレクトリ・サーバーを停止します。
/backupsからZFSファイル・システムを初期化します。
$ dd if=/backups/DS_FS.{date_to_restore}.zfs bs=32k | zfs receive -F zpool/DS_FS
リストアするディレクトリ・サーバーのホスト名とポート番号を使用するように、必要に応じて構成を変更します。
ディレクトリ・サーバーを起動します。
ディレクトリが、トポロジ内の他のレプリカと同期していることが確認されるまで、レプリケーションを監視します。
writability-modeをenabledに設定し、ディレクトリ・サーバーが、クライアントからの書込み操作を処理できるようにします。
$ dsconfig -h restored-host -p 4444 -D "cn=Directory Manager" -j pwd-file -X \ -n set-global-configuration-prop --set writability-mode:enabled
restoreユーティリティを使用してデータをリストアできます。restoreユーティリティでは、一度に1つのバックエンドのみリストアできます。リストア・タスクをスケジュールしている場合、または署名またはハッシュされたデータをリストアする場合以外は、リストアする前にディレクトリ・サーバーを停止しておく必要があります。
この項には次のトピックが含まれます:
サーバーが実行中である場合は、それを停止します。
--listBackupsオプションを指定してrestoreコマンドを実行することでバックアップ情報を表示します。例:
$ restore --listBackups --backupDirectory backup/userRoot Backup ID: 20080827153501Z Backup Date: 27/Aug/2008:10:35:11 -0500 Is Incremental: false Is Compressed: true Is Encrypted: false Has Unsigned Hash: false Has Signed Hash: false Dependent Upon: none
バックエンドをリストアします。
$ restore --backupDirectory backup/userRoot
他のバックエンドに対してリストアを繰り返します。
通常、システム管理者は、増分バックアップを毎日、全体バックアップを毎週実行します。増分バックアップからのシステムのリストアのほうが時間が長くかかることに注意してください。
restoreコマンドを使用することで、システム上に最新の全体バックアップをリストアします。
各バックエンドは、個別にリストアする必要があります。
restoreコマンドを使用することで、各増分バックアップをリストアします。
最新の全体バックアップから開始して、各増分バックアップをリストアします。
ディレクトリ・サーバーは、バックアップやリストアなどの管理タスクを実行するためにタスク・バックエンドを提供しています。-tまたは--startオプションを使用することで、リストアの開始時間を指定できます。これらのオプションを指定しない場合、タスクのスケジュール後ただちにユーティリティは終了します。ただちに実行するようにタスクをスケジュールし、タスクのスケジュール後ただちにユーティリティを終了するには、開始時間の値として0を指定します。-tまたは--startオプションを省略すると、ユーティリティは、タスクをただちに実行するようにスケジュールし、タスクの進行状況を追跡し、ログ・メッセージを使用できるように出力し、タスクが完了したときに終了します。
タスク・バックエンドへのアクセスは、管理コネクタを使用してSSL経由で提供されます。したがって、リストアをタスクとしてスケジュールする場合、SSL証明書の信頼方法を指定する必要があります。
スケジュール済のリストア時間の前にサーバーが停止されていることを確認します。
restoreコマンドの-tまたは--startオプションを使用することによって、リストアをスケジュールします。
次のコマンドは、--startオプションを使用することでスケジュールされた開始時間にuserRootバックエンドをリストアします。リストアによって、admin@example.comに完了およびエラーの通知が送信されます。-Xオプションは、サーバーによって定義されるすべての証明書を信頼することを指定します。
$ restore -p 4444 -D "cn=Directory Manager" -j pwd-file -X \ -d /backup/userRoot --start 20080125121500 --completionNotify admin@example.com \ --errorNotify admin@example.com
manage-tasksユーティリティを使用することで、このスケジュール済タスクを表示できます。
詳細は、第14.4項「タスクとしてのコマンドの構成」を参照してください。
場合によっては、障害時リカバリ目的で、または他のイベントのために、別のサーバーに構成を転送するための構成ファイルをリストアする必要があります。一般に、サーバーがオンラインである場合、現在の構成ファイルは、最後にアーカイブした構成ファイルと同一です。ただし、前の日付のものからconfig.ldifファイルをリストアすることを選択できます。
サーバーが実行中である場合は、それを停止します。
システム上で必要な構成ファイルを特定します。例:
$ ls INSTANCE_DIR/OUD/config/archived-configs
./
../
config-20110817192057Z.gz
config-20110827153200Z.gz
config-20110817192052Z.gz
config-20110827153214Z-2.gz
gunzipなでの解凍ユーティリティを使用して、アーカイブ済構成ファイルを手動で解凍します。
そのファイルをconfigディレクトリにコピーし、現在のconfig.ldifファイルを置き換えます。
$ cp config-20110817192057Z INSTANCE_DIR/OUD/config/config.ldif
ホストに前にインストールされていたディレクトリ・サーバーと同じバージョンをインストールします。
setupコマンドを使用して、サーバー・インスタンスを作成します。
保存済のconfigディレクトリをINSTANCE_DIR /OUD/configにコピーします。
config.ldifファイルは、このディレクトリに配置されています。保存済のスキーマ・サブディレクトリは、INSTANCE_DIR/OUD/config/schemaに配置されています。
リストアしたサーバーの構成が正しいことを確認します。
restoreコマンドを使用することで個々のバックエンドをリストアします。
レプリケートされた環境でバイナリ・リストアを実行するには、レプリケートされたトポロジに応じた特別な注意が必要です。可能な場合は、バックアップからのリストアではなく、ご使用のシステムのレプリケーション・メカニズムを使用することでバックエンドを更新してください。従来のテープによるバックアップと比較して、レプリケーションには明確な利点があります。データのリストアは、テープによるリストアよりも大幅に高速であり、データは、より最新の状態に保たれます。ただし、テープは、依然として、レプリケートされたデータが破損していて、他のサーバーに伝播された場合に必要になります。
レプリケートされたサーバーをリストアする場合は、構成ファイルINSTANCE_DIR/OUD/config/config.ldifが、バックアップが実行されときと同一であることを確認します。サーバー・バックエンドをリストアする前に、config.ldifファイルをリストアします。
古いバックアップをマスター・サーバーにリストアすることはできません。最新でない可能性があるためです。かわりに、レプリケーション・メカニズムが、マスターを読取り専用に設定することで、他のマスター・サーバーを使用してそのマスターを最新の状態にできるようにします。マスターが同期されたら、それを読取り/書込みにリセットできます。
レプリケートされたサーバーをリストアする必要がある場合は、LDIFファイルをインポートすることで、他のレプリケートされたサーバーの1つからサーバーを再初期化します。
大規模データベース(数百万のエントリ)の場合は、1つのサーバーのバイナリ・コピーを作成し、それを他のレプリケートされたサーバー上でリストアします。
比較的最近のバックアップ(他のレプリケートされたサーバーの変更ログの内容の最大保持時間よりも古くないもの)がある場合、そのバージョンを使用してデータをリストアできます。古いバックアップをリストアすると、他のサーバーによって、そのバックアップを保存した後に行われた最近の更新でそのサーバーが更新されます。
通常のバックアップを実行する場合、そのバックアップ・ファイルが、多すぎるディスク領域を消費し始めることがあります。古いバックアップ・ファイルを手動で削除し、新しいもの向けの領域を作る必要があります。
手動でバックアップ・ファイルを削除するときは、バックアップのセット間の依存関係を壊さないようにします。
バックアップ・ディレクトリ内の既存のバックアップをリストします。
たとえば、デフォルト・バックアップ・ディレクトリ内のバックアップをリストするには、次のコマンドを実行します:
UNIX: $ ls INSTANCE_DIR/OUD/bak backup-userRoot-20110929184101Z backup-userRoot-20111029184509Z backup.info backup.info.save WINDOWS: C:\> dir INSTANCE_DIR\OUD\bak backup-userRoot-20110929184101Z backup-userRoot-20111029184509Z backup.info backup.info.save
バックアップ・ディレクトリからバックアップ・ファイルを削除します。
たとえば、前の手順でuserRootデータベースの最も古いバックアップを削除するには、次のコマンドを実行します:
UNIX: $ rm INSTANCE_DIR/OUD/bak/backup-userRoot-20110929184101Z WINDOWS C:\> del INSTANCE_DIR\OUD\bak\backup-userRoot-20110929184101Z
backup.infoファイルから関連するバックアップ情報を削除します。
次のようにして、backup.infoの内容を表示できます(UNIXシステムの場合):
$ more INSTANCE_DIR/OUD/bak/backup.info
backend_dn=ds-cfg-backend-id=userRoot,cn=Backends,cn=config
backup_id=20110929184101Z
backup_date=20110929184104Z
incremental=false
compressed=false
encrypted=false
property.last_logfile_name=00000000.jdb
property.last_logfile_size=160773
property.archive_file=backup-userRoot-20110929184101Z
backup_id=20111029184509Z
backup_date=20111029184512Z
incremental=false
compressed=false
encrypted=false
property.last_logfile_name=00000000.jdb
property.last_logfile_size=160773
property.archive_file=backup-userRoot-20111029184509Z
Windowsシステムの場合、適切なテキスト・エディタを使用します。
ディレクトリ・サーバーは、検索機能およびフィルタの形式の高性能なルックアップ操作など、LDAPv3対応のコマンドライン・ツールのスイートを備えています。Oracle Directory Services Managerを使用してディレクトリ・データを検索することもできます。この項では、ldapsearchコマンドライン・ユーティリティおよびOracle Directory Services Managerを使用してディレクトリ内のエントリを見つける方法について説明します。
この項には次のトピックが含まれます:
ldapsearchコマンドの概要ldapsearchコマンドでは、検索リクエストを入力し、そこでディレクトリ内のエントリを見つけるためのホスト名、ポート、バインドDNおよびパスワード、さらに検索基準を指定できます。LDAPクライアントが、ディレクトリ・サーバーに対して検索リクエストを実行すると、そのディレクトリ・サーバーへの接続がTCP/IP経由で開きます。その後、クライアントは、指定されたエントリの照合を試みることで、ディレクトリ・サーバーへのbind操作を実行し、それによって実際にクライアントが認証されます。大部分のユーザーは、ディレクトリ管理者や彼ら自身など特定のユーザーとしてバインドすることも、どのユーザーとしてもバインドしないこと(この場合、ディレクトリ・サーバーはそのユーザーが匿名ユーザーとしてバインドしていると想定する)もできます。
ディレクトリ・データへのすべてのアクセスは、接続のバインド方法に基づいているため、ディレクトリ・サーバーによって、クライアントの権限が調べられ、クライアントが特定の検索操作を実行できるかどうかが確認されます。ディレクトリ・サーバーによって、ユーザーのアクセス権が調べられた後、クライアントからディレクトリ・サーバーに一連の検索基準およびオプションで構成された検索リクエストが渡されます。
ディレクトリ・サーバーによって、その検索基準およびオプションに一致するすべてのエントリが検索されます。その後、それによって、標準出力のLDIFテキストの形式でエントリ、DN、および各エントリのすべての属性が返されます。エラーが発生した場合、ディレクトリ・サーバーによって、そのエラーを示すエラー・メッセージが表示されます。最後に、検索操作が完了すると、クライアントによって接続が閉じられます。
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コマンドには、ディレクトリ内のエントリを検索するための多くのオプションがあります。オプションは、短い形式(たとえば、-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属性がソートされます。
ldapsearchコマンドには、ディレクトリ情報ツリー内のどこで何を検索するのかを指定する次の3つのセットの情報が必要です:
ベースDN。ベースDNを指定することで、検索を実行するディレクトリの最上位識別名(DN)または開始店を定義します。すべての検索は、範囲に応じてベースDNから、またその下からツリーの下に向かって開始され、上に向かって進むことはありません。ベースDNの例としては、dc=example,dc=comおよびou=People,dc=example,dc=comがあります。
範囲。範囲によって、検索フィルタによってベースDNのエントリとその下のエントリのどちらのセットを評価するのかが決まります。検索範囲およびベースDNは、ともに、ディレクトリのないのエントリを検索する場所を示します。
検索フィルタ。検索フィルタは、クライアントに返されるエントリが満たす必要がある条件を指定します。
この項では、様々なフィルタ・オプションについて説明し、内容は次のとおりです:
ディレクトリ・サーバーは、LDAPプロトコルで定義されている7つのタイプの検索フィルタを備えています。検索フィルタ・タイプごとに、attributeとvalueの2つのエンティティ間の関係をテストする演算子を使用します。
次の表は、検索問合せにおいて特定のエントリを返すための検索フィルタの使用方法を示しています。
| 検索フィルタ | 演算子 | 説明 |
|---|---|---|
|
プレゼンス |
|
指定された属性と関連する値を持つすべてのエントリを返します。このフィルタでは、ワイルドカード文字を使用して、文字列内のゼロ個以上の文字を示します。たとえば、フィルタ 注意: LDAPプロトコルでは、フィルタは、引用符に囲まれたカッコも含めて"(filter)"の形式を持つと指定されています。大部分のディレクトリ・サーバーでは、カッコと引用符がないフィルタを受け入れますが、それらを含めることをお薦めします。 |
|
等価 |
|
指定された値に等しい属性を含むエントリを返します。たとえば、 注意: |
|
部分文字列 |
|
指定した部分文字列または部分的な部分文字列を含む属性を持つエントリが返されます。このフィルタでは、ワイルドカード文字を使用して、文字列内のゼロ個以上の文字を示します。
|
|
以上 |
|
指定された値以上の属性を含むエントリを返します。たとえば、 |
|
以下 |
|
指定された値以下の属性を含むエントリを返します。たとえば、 |
|
近似 |
|
検索フィルタに指定されている値にほぼ等しい値を持つ指定された属性を含むエントリを返します。たとえば、 |
|
拡張可能一致 |
|
指定した一致ルールで属性がその値に等しい場合、結果のエントリを返します。LDAPバージョン3では、特定の属性に対する一致演算子およびルールを作成できます。一致ルールによって、特定の構文と属性値を比較する方法が定義されます。つまり、拡張可能検索フィルタでは、一致ルールを検索フィルタに追加できます。たとえば、 |
次のように演算子を使用することで、複数の検索フィルタ・コンポーネントを結合し、評価できます:
(Boolean-Operator(filter)(filter)(filter))
ブール演算子を結合し、ネストして、複合式を形成できます:
(Boolean-Operator(filter)(Boolean-operator(filter)(filter)))
次の表で、ブール演算子について説明します。
| 検索フィルタ | 演算子 | 説明 |
|---|---|---|
|
AND |
|
文がtrueになるためには、指定されているすべてのフィルタがtrueである必要があります。たとえば、 |
|
OR |
|
文がtrueになるためには、指定されているフィルタの少なくとも1つがtrueである必要があります。たとえば、 |
|
NOT |
|
文がtrueになるためには、指定されているフィルタがtrueでない必要があります。たとえば、 |
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)
特殊文字(たとえば、空白、円記号、アスタリスク、カンマ、ピリオドなど)は、エスケープ円記号を使用することで指定する必要があります。
アスタリスク。アスタリスク(*)は、\\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")のようになります。
ldapsearchの例次の例は、各種検索オプションを指定したldapsearchコマンドの使用を示しています。これらの例はすべて、現行作業ディレクトリがINSTANCE_DIR/OUD/bin (WindowsシステムではINSTANCE_DIR\OUD\bat)であることを想定しています。
次の点は、この項のすべての例に関係しています:
例で(--searchScopeまたは-sオプションで)範囲が指定されていない場合、ldapsearchでは、範囲がsubordinateまたはsubであると想定され、ベースDNのすべてのサブツリーが返されます。
属性が指定されていない場合、このコマンドはすべての属性とそれらの値を返します。
--bindDNおよび--bindPasswordが指定されていない場合、検索で匿名バインドが使用されます。
--hostnameが指定されていない場合、デフォルト(localhost)が使用されます。
|
注意: 多くのUNIXおよびLinuxオペレーティング・システムで、 $ which ldapsearch
|
この項には次のトピックが含まれます:
プレゼンス検索フィルタ(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 ...
等価フィルタを使用して、ディレクトリ内の特定のユーザーを見つけることができます。この例では、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 9751
等価フィルタを使用して、ディレクトリ内のエントリの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
検索ベース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
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
サブツリー範囲では、ベース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
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 ...
アスタリスク*を含めることで、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
検索フィルタの後に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 ...
特定のオブジェクト・クラスの名前の前に@文字を付けることで、そのオブジェクト・クラスによって属性が参照されるすべてのエントリを検索できます。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 ...
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
複合検索フィルタには、ブール演算子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
--filenameオプションを使用することで、ファイル内に複合または複数のフィルタを配置できます。ファイルに複数のフィルタが含まれている場合は、1行に1つのフィルタが表示されるようにファイルを構成する必要があります。検索は、フィルタ・ファイルに記載されている順序でディレクトリ・サーバーへの同じ接続を使用して実行されます。--filenameオプションを使用する場合、その後のオプションはすべて独立した属性として処理されます。そうでない場合は、最初の後続オプションを検索フィルタにする必要があります。
この例では、Jensenという名前で、Cupertinoで働いていて、かつ会計部門では働いていない従業員のすべてのエントリを検索します。
フィルタ・ファイルを作成します。
この例では、(&(sn=jensen)(l=Cupertino)(!(ou=Accounting)))の内容を持つmyfilter.txtという名前のファイルを作成します。
フィルタとしてファイル名を指定してldapsearchコマンドを実行します。
$ ldapsearch --hostname localhost --port 1389 --bindDN "cn=Directory Manager" \ --bindPassword password --baseDN dc=example,dc=com --filename myfilter.txt 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 cn: Barbara Jensen cn: Babs Jensen telephoneNumber: +1 408 555 1862 givenName: Barbara uid: bjensen mail: bjensen@example.com
-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
次の項に示すように、ODSMの各サーバー・インスタンスの「拡張検索」タブで、ディレクトリ・データに対して複合検索を実行できます。
ODSM拡張検索機能を使用することで複合LDAP検索を実行するには、次の手順を完了します:
第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「拡張検索」タブを選択します。
「ネットワーク・グループ」リストから適切なネットワーク・グループを選択します。
「ベース検索DN」フィールドで、検索の開始点となるDNを入力します。
「ベース検索DN」としてエントリを選択するには、「選択」をクリックします。
「エントリ・ピッカー」ウィンドウで、「ツリー・ビュー」を選択してディレクトリ・ツリーに移動し、対象のエントリを見つけるか、「検索ビュー」を選択して対象のエントリを検索します。
「範囲」リストから検索の範囲を選択します。LDAP検索範囲は、検索操作の一致候補と見なされる、ベースDNまたはその下にある一連のエントリを示します。範囲は、次のいずれかです:
ベース。検索操作は、検索ベースDNとして指定されたエントリに対してのみ実行されることを示します。その下には検討されるエントリはありません。
「1レベル」。検索操作は、検索ベースDNとして指定されたエントリの直下のエントリに対してのみ実行されることを示します。ベース・エントリ自体または検索ベース・エントリの直下より下位のエントリは含まれません。
サブツリー。検索操作は、検索ベースとして指定されたエントリ、および深さにかかわらず検索ベースの下位すべての指定されたエントリに対して実行されることを示します。
「フィルタ」フィールドで、有効なLDAP検索フィルタを入力します。
かわりに、「フィルタ・ビルダー」をクリックし、ODSMに必要な情報を入力し、LDAP検索フィルタを構築します。
LDAP検索フィルタの詳細は、第17.4.3.1項「フィルタのタイプと演算子の指定」を参照してください。
「検索結果サイズ」リストから、検索によって返されるエントリの数をODSMで制限する方法を選択します。
「制限設定」で、返されるエントリの正確な数を指定できます。
「仮想リスト・ビューの使用」によって、検索に仮想リスト表示索引を使用できます。詳細は、第17.5.3.16項「仮想リスト表示制御を使用した検索」を参照してください。
「ページングの使用」によって、一度に結果のサブセットのみを返すことを指定でき、各ページの結果の数を指定できます。詳細は、第17.5.3.15項「単純なページングの結果制御を使用した検索」を参照してください。
ディレクトリ・サーバーは、ldapsearchコマンドを使用することでLDAPv3対応の検索機能をサポートしています。ご使用のシステム構成に基づいて、検索プロセスで特殊属性、セキュリティ、オプション、およびLDAP制御を使用できます。詳細は、第17.4項「ディレクトリ・データの検索」、付録A「サーバー・コマンドによるプロパティ・ファイルの使用方法」および付録A「ldapsearch」を参照してください。
この項には次のトピックが含まれます:
この項では、操作属性を検索する方法と、ルートDSEエントリを検索する方法について説明し、内容は次のとおりです:
操作属性は、サーバー自体で処理を行ったり、ディレクトリ・サーバーで管理されている(クライアントから明示的に提供されることのない)その他のデータを保持するために必要な情報を格納する場合に使用されます。操作属性は、検索属性のリストに明示的に含められていない場合は、検索操作から返されるエントリに含まれません。+ (プラス記号)を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 ...
ルート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 ...
ディレクトリ・サーバーでは、アクセス制御命令(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";)
ディレクトリ・サーバーは、ご使用のインスタンスに対して定義されているオブジェクト・クラスおよび属性のスキーマ情報をスキーマ・エントリ(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' ) ...
ディレクトリ・サーバーは、その構成をcn=configエントリの下に格納します。LDAPを使用したこのエントリへの直接アクセスはお薦めしません。この構成は、dsconfigコマンドを使用してアクセスおよび変更できます。dsconfigコマンドは、管理コネクタを使用してSSL経由でディレクトリ・サーバーに接続します。詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。
対話モードでdsconfigを使用して構成エントリを検索するには、次のようにコマンドを実行します:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file
dsconfigを使用したサーバー構成へのアクセスの詳細は、第14.1項「dsconfigを使用したサーバー構成の管理」を参照してください。
ディレクトリ・サーバーの監視エントリcn=monitorは、サーバー・パフォーマンス、状態およびバージョンに関する統計情報を提供します。この情報には、ldapsearchコマンドを使用することでアクセスできます。
任意の構成済LDAP接続ハンドラを使用してcn=monitorにアクセスできますが、管理接尾辞へのすべてのアクセスに管理コネクタを使用することをお薦めします。管理コネクタを使用すると、データの監視が損なわれず、ユーザー・トラフィックよりもサーバー管理が優先されるようになります。管理コネクタを使用するには、管理ポートを指定し、--useSSLオプションを含めます。詳細は、第14.3項「サーバーへの管理トラフィックの管理」を参照してください。
ベース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 ...
自己署名証明書または証明書を使用することでSSL接続を受け入れるようにディレクトリ・サーバーを構成した場合、クライアント認証を使用して検索できます。次の手順は、各種認証メカニズムを使用してSSL経由でディレクトリを検索する方法を示しています。
この項には次のトピックが含まれます:
サーバーから提示されたどのような証明書も、自動的に信頼するようにクライアントを構成できます。ただし、この方法は安全ではなく、介在者による攻撃を受けやすくなります。一般的に、このタイプの認証は、テスト目的でのみ使用してください。
--trustAllオプションを指定して、ldapsearchコマンドを実行します。
次のコマンドは、ルートDSEを検索します。
$ ldapsearch -h localhost -p 1636 --useSSL --trustAll -b "" \ --searchScope base "(objectClass=*)"
証明書トラスト・ストアを使用するようにクライアントを構成できます。これには、信頼できる証明書に関する情報が含まれています。クライアントは、サーバー証明書を、トラスト・ストアにリストされているものと比べてチェックできます。クライアントによって一致が確認されると、サーバーとの間でセキュアな通信を行えます。一致がない場合、サーバーを信頼できません。提示された証明書が有効であることを確認し、それをトラスト・ストアに追加する必要があります。それによってセキュアな通信が許可されます。
--trustStorePathオプションを指定して、ldapsearchコマンドを実行します。
次のコマンドは、トラスト・ストアを使用してルートDSEを検索します。
$ ldapsearch -h localhost -p 1636 --useSSL \ --trustStorePath /home/scarter/security/cert.db -b "" \ --searchScope base "(objectClass=*)"
トラスト・ストアが指定されていない場合、クライアントに提示された証明書を信頼するかどうかに関するプロンプトが表示されます。
--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
クライアントがディレクトリ・サーバーに独自の証明書ょ提示する必要がある場合、そのクライアントは、どの証明書キーストアを使用するのか認識している必要があります。クライアントは、--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=*)"
ldapsearchユーティリティでStartTLSを使用するプロセスは、SSLを使用するプロセスととてもよく似ています。ただし、次のことを実行する必要があります:
サーバーがunencrypted LDAPリクエストをリスニングするポートを使用します。
SSLのかわりにStartTLSを使用する必要があることを示します(つまり、--useSSLオプションのかわりに--startTLSオプションを使用します)。
--startTLSオプションを指定して、ldapsearchコマンドを実行します。
次のコマンドは、startTLSを使用してルートDSEを検索します。
$ ldapsearch -h localhost -p 1389 --startTLS \ -b "" --searchScope base "(objectClass=*)"
ディレクトリ・サーバーは、いくつかの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=*)"
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=*)"
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=*)"
LDAP制御は、ldapsearchなどのLDAPコマンドの機能を拡張し、検索結果に対して追加の操作を実行します。各制御は、制御、クリティカル度フラグ、および関連付けられている値を一意に識別するオブジェクト識別子(OID)として定義されます。ディレクトリ・サーバーに制御が送信されるときに、クライアントによってクリティカル度フラグが設定されている場合、そのディレクトリ・サーバーではその制御を使用して操作を実行するか、それを処理しないかのいずれかにする必要があります。フラグがクライアントによって設定されていない場合、ディレクトリ・サーバーでは、その制御を処理できない場合はそれを無視できます。
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のリストとして返されます。各OIDに対応する制御の説明は、次の表を参照してください。これらの制御の一部はldapsearchコマンドで使用できないことに注意してください。
| OID | 制御 |
|---|---|
|
|
一致する値の制御 |
|
1.2.840.113556.1.4.1413 |
LDAP変更制限緩和制御 |
|
|
単純なページングの結果制御 |
|
|
サーバー側ソート制御 |
|
|
サブツリー削除制御 |
|
|
LDAPアサーション制御 |
|
|
LDAP読込み前制御 |
|
|
LDAP読込み後制御 |
|
|
レプリケーション修復制御 |
|
|
ネットワーク・グループ選択制御 |
|
|
ネットワーク・グループ問合せ制御 |
|
|
Join Search Control |
|
|
近接検索制御 |
|
|
パスワード・ポリシー制御 |
|
|
実効権限取得制御 |
|
|
アカウント・ユーザビリティ・リクエスト制御 |
|
|
LDAP操作なし制御 |
|
|
LDAPサブエントリ・リクエスト制御 |
|
|
プロキシ認可v1制御 |
|
|
認可アイデンティティ制御 |
|
|
実在属性専用制御 |
|
|
プロキシ認可v2制御 |
|
|
仮想属性専用制御 |
|
|
DSA ITの管理制御 |
|
|
永続検索制御 |
|
|
Netscapeパスワード有効期限切れLDAPv3制御 |
|
|
Netscapeパスワード有効期限切れ間近LDAPv3制御 |
|
|
仮想リスト表示制御 |
|
|
検索件数リクエスト制御 |
|
|
ECID実行情報制御 |
結合検索制御では、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
検索フィルタは、検索結果に含めるための結合中に、候補のエントリを評価するために使用されます。フィルタは、特定のエントリのみを含めるように検索を絞り込むためにも使用できます。これは、標準検索操作のフィルタと同じですが、結合検索結果にのみ適用できます。
近似検索制御は、検索リクエストにおいてサーバーにベースの位置データを提供します。これによって、サーバーは、位置データを含む近似仮想属性値を候補のエントリすべてに対して生成できます。エントリ内の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))"
アカウント・ユーザビリティ・リクエスト制御は、ユーザー・アカウントをサーバーから認証を受けるために使用できるかどうかを判別します。ユーザー・アカウントを使用できる場合、その制御によって、アカウントが使用可能であるかどうかに基づいてエントリの前にメッセージが追加されます。
次のようにして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 ...
認可アイデンティティ・リクエスト制御によって、クライアントは、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
実効権限取得制御によって、既存または新しい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オプションとともに使用して、指定した属性に対する実効権限を含めることができます。このオプションを使用すると、エントリ内に現在存在しない属性を追加する権限をユーザーが持っているかどうかを判別できます。
|
注意:
|
実効権限を表示するには、仮想属性aclRightsおよびaclRightsInfoを指定する必要があります。これらは、実効権限リクエストに応答してサーバーによって生成されます。したがって、どのような種類の検索コマンドでもこれらの属性を使用しないでください。
ldapsearchコマンドを使用して、すべてのユーザーの実効権限を表示します。
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ -b dc=example,dc=com -J effectiverights "(objectclass=*)" aclRights dn: dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: ou=Groups, dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: ou=People, dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: cn=Accounting Managers,ou=groups,dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 dn: cn=HR Managers,ou=groups,dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:0,proxy:0 ...
ldapsearchコマンドを使用して、特定のユーザーの実効権限を表示します。
この例では、--getEffectiveRightsAuthzidオプションを使用します。-J geteffectiverightsなど--controlまたは-Jオプションも使用できます。
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ -b dc=example,dc=com \ --getEffectiveRightsAuthzid "dn:uid=scarter,ou=People,dc=example,dc=com" \ "(uid=scarter)" aclRights dn: uid=scarter,ou=People,dc=example,dc=com aclRights;entryLevel: add:0,delete:0,read:1,write:1,proxy:0
ldapsearchコマンドを使用して、特定のユーザーの実効権限情報を表示します。
aclRightsInfo属性は、実効権限がどのように付与または拒否されているかを説明する詳細なロギング情報を提供します。
ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ -b dc=example,dc=com \ --getEffectiveRightsAuthzid "dn:uid=scarter,ou=People,dc=example,dc=com"\ "(uid=scarter)" aclRightsInfo dn: uid=scarter,ou=People,dc=example,dc=com aclRightsInfo;logs;entryLevel;add: acl_summary(main): access not allowed(add) on entry/attr(uid=scarter,ou=People,dc=example,dc=com, NULL) to (uid=scarter,ou=People,dc=example,dc=com) (not proxied) ( reason: no acis matched the subject ) aclRightsInfo;logs;entryLevel;proxy: acl_summary(main): access not allowed(proxy ) on entry/attr(uid=scarter,ou=People,dc=example,dc=com, NULL) to (uid=scarter, ou=People,dc=example,dc=com) (not proxied) ( reason: no acis matched the subject ) aclRightsInfo;logs;entryLevel;write: acl_summary(main): access allowed(write) on entry/attr(uid=scarter,ou=People,dc=example,dc=com, NULL) to (uid=scarter,ou=People,dc=example,dc=com) (not proxied) ( reason: evaluated allow , deciding_aci : Allow self entry modification) aclRightsInfo;logs;entryLevel;read: acl_summary(main): access allowed(read) on entry/attr(uid=scarter,ou=People,dc=example,dc=com, NULL) to (uid=scarter,ou=People,dc=example,dc=com) (not proxied) ( reason: evaluated allow , deciding_aci: Anonymous extended operation access) aclRightsInfo;logs;entryLevel;delete: acl_summary(main): access not allowed(delete) on entry/attr(uid=scarter,ou=People,dc=example,dc=com, NULL) to (uid=scarter,ou=People,dc=example,dc=com) (not proxied) ( reason: no acis matched the subject )
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
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=*)"
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)
|
注意:
|
一致値フィルタ制御によって、クライアントは、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
パスワード・ポリシー制御によって、クライアントは、ユーザー・エントリの現在のパスワード・ポリシー情報に関する情報をリクエストできます。
次のいくつかの方法で、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オプションを使用します。
|
注意:
|
--usePasswordPolicyControlオプションを指定して、ldapsearchコマンドを実行します。
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ -b dc=example,dc=com -s base --usePasswordPolicyControl "(objectclass=*)"
永続検索制御によって、クライアントは、追加、削除または変更操作によってディレクトリのエントリが変更されたときに、通知を受け取れます。変更が行われたときに、そのエントリが、エントリ変更通知制御によって使用された検索基準に一致する場合、サーバーによって更新済エントリがクライアントに送信されます。
ldapsearchコマンドには、接続を開いたままにして、変更(追加、削除、変更、またはすべて)が発生するたびにその範囲およびフィルタに一致するエントリを表示する永続検索(-C)を実行するオプションがあります。この検索は、[Ctrl] + [C]を押すことで終了できます。
この引数の値は、ps[[:''changetype''[[:''changesonly''[[:''entrychangecontrols'']]]の形式にする必要があります。
この値の要素には、次のものがあります:
ps: 必須演算子。
changetype: クライアントが通知の受信を必要とする変更のタイプを指定します。この要素は、add、del、mod、moddnのいずれか、またはすべての変更タイプに登録する場合はallです。また、複数の特定の変更タイプに登録するには、カンマ区切りリストにすることもできます。この要素が指定されない場合、デフォルトとしてall変更タイプが含まれます。
changesonly: Trueの場合、クライアントは、その検索が登録された後に一致するエントリに行われた変更のみを通知されます。Falseの場合、サーバーによって、サーバー内の指定された検索基準に一致するすべての既存のエントリも送信されます。この要素が指定されていない場合、デフォルトでは、その検索が登録された後に発生した更新についてのみエントリが返されます。
entrychangecontrols: Trueの場合、サーバーは、変更の結果としてクライアントに送信されるエントリ内にエントリ変更通知制御を含めます。Falseの場合、エントリ変更通知制御は含められません。この要素が指定されない場合、デフォルトとしてエントリ変更通知制御が含まれます。
ldapsearchコマンドを次のように実行します:
$ ldapsearch -h localhost -p 1389 -D "cn=admin,cn=Administrators,cn=config" \ -j pwd-file -b dc=example,dc=com --persistentSearch ps:add:true:true \ "(objectclass=*)"
|
注意: このコマンドを使用する場合、サーバーは |
別の端末ウィンドウを開き、ldapmodifyを使用して新しいエントリを追加します。
$ ldapmodify -h localhost -p 1389 -b dc=example,dc=com \ --defaultAdd --filename new_add.ldif Processing ADD request for uid=Marcia Garza,ou=People,dc=example,dc=com ADD operation successful for DN uid=Marcia Garza,ou=People,dc=example,dc=com
元の端末ウィンドウに変更内容が表示されます。
このセッションを終了するには、[Ctrl] + [Z] (Unix/Linux)または[Ctrl] + [C] (Windows)を押します。
# Persistent search change type: add
dn: uid=Marcia Garza,ou=People,dc=example,dc=com
objectClass: person
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: top
givenName: Marcia
uid: mgarza
uid: Marcia Garza
cn: Marcia Garza
sn: Garza
userpassword: {SSHA}SNfL1RUm5uvTnLK+G0K3oz+Peb1i5/+YsylfBg==
roomnumber: 5484
l: Santa Clara
ou: Accounting
ou: People
mail: mgarza@example.com
このセッションを途中で終了させるには、[Ctrl] + [D] (Unix/Linux)または[Ctrl] + [C] (Windows)を押し、Yと入力して終了します。
Terminate batch job (Y/N)?
プロキシ設定された認可制御によって、クライアントは、特定の操作に対して別のエントリを偽装できます。この制御は、多数の異なるユーザーのかわりに実行する必要がある信頼できるアプリケーションにおいて役立ち、そのアプリケーションが操作ごとに再度認証を受ける必要がなくなります。
次のように、--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
サーバー側ソート制御によって、クライアントは、サーバーが検索結果をクライアントに送信する前にそれらをソートするようにリクエストできます。これは、サーバーに、クライアントによってリクエストされたソート順序をクライアントより速く満たすことができる索引がある場合に便利です。
--sortOrderオプションを使用することで、返されるエントリをソートできます。昇順の+ (プラス記号)または降順の- (マイナス記号)を指定しない場合、デフォルトのオプションは、昇順でのソートです。
ldapsearchコマンドを使用して、すべてのエントリを検索し、昇順で結果を表示します。
--sortOrderオプションを指定して、snおよびgivenName属性を基準にソートします。
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ --s sub -b dc=example,dc=com --sortorder sn,givenName "(objectclass)" dn: uid=dakers,ou=People,dc=example,dc=com objectClass: person objectClass: organizationalPerson ...<search results>...
ldapsearchコマンドを使用して、すべてのエントリを検索し、降順で結果を表示します。
--sortorderオプションを指定して、属性snを基準にソートします。
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ -s sub -b dc=example,dc=com --sortOrder -sn "(objectclass)" dn: uid=pworrell,ou=People,dc=example,dc=com objectClass: person objectClass: organizationalPerson ...<search results>...
単純なページングの結果制御によって、検索操作で、一度に結果のサブセットのみを返すことができます。検索結果全体を一度に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
仮想リスト表示制御によって、クライアントは、サーバーにエントリの特定の範囲内で小さい、管理可能なチャンクで検索結果を送信するようにリクエストできます。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です。
ソート順序オプション(-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
ソート順序(-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
ソート順序(-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
デフォルトてば、仮想リスト表示制御へのアクセスは、認証済のユーザーにのみ許可されます。認証されていないユーザーに仮想リスト表示制御へのアクセスを許可するには、仮想リスト表示制御(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を変更する最も簡単な方法は、次のようにODSMを使用することです:
第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「セキュリティ」タブを選択します。
「ルート」メニューから、匿名制御アクセスを選択します。
左側のペインの「ターゲット」表で、「ターゲット制御」フィールドを選択し、「編集」をクリックします。
「使用可能なコントロール」リストから、仮想リスト表示制御(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を削除して再作成する必要があります。詳細は、第22.1.1項「デフォルト・グローバルACI」を参照してください。
この項では、詳細モードで検索する方法と、プロパティ・ファイルを使用して検索する方法について説明し、内容は次のとおりです:
詳細モードでは、クライアントとサーバー間で送信されている処理情報が表示されます。このモードはデバッグに便利です。
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
...
ディレクトリ・サーバーは、ldapsearchコマンドで使用するデフォルト引数値を保持しているプロパティ・ファイルの使用をサポートしています。プロパティ・ファイルは、様々な構成環境、特にスクリプト済アプリケーションまたは埋込みアプリケーションで作業する場合に便利です。詳細は、付録A「サーバー・コマンドによるプロパティ・ファイルの使用方法」を参照してください。
任意のテキスト・エディタで、次の内容のプロパティ・ファイルを作成します:
hostname=localhost port=1389 bindDN=cn=Directory Manager bindPasswordFile=pwd-file baseDN=dc=example,dc=com searchScope=sub sortOrder=givenName virtualListView=0:2:1:0
ファイルをtools.propertiesという名前で保存します。
--propertiesFilePathオプションを指定して、ldapsearchを使用します。
$ ldapsearch --propertiesFilePath tools.properties "(objectclass=*)"
Oracle Unified Directoryでは、エントリと突き合せて、第17.5.3.14項「サーバー側ソート制御を使用した検索」のように使用して検索結果をソートする照合ルールがサポートされています。この照合ルールは、次に示すように、コロンで区切って、検索フィルタで一致ルールとして指定します:
locale.matchingRule
ここで:
localeは、次のいずれかの方法で指定します。
ロケールOID
ロケール文字接尾辞(ar、en、fr-CAなど)。
サポートされているロケール、それらのOIDおよびタグのリストは、この項の終わりにある第17.5.5.2項「サポートされている照合ルール」を参照してください。
matchingRuleは、表17-1に示すように、ロケールに追加された数字接尾辞または文字接尾辞のいずれかとして指定できます。
|
注意: ロケールをそのOIDで指定する場合、一致ルールはその数字接尾辞で指定する必要があります。この場合、一致ルールを文字接尾辞で指定することはできません。 |
表17-1 一致ルール接尾辞
| 一致ルール | 数字接尾辞 | 文字接尾辞 |
|---|---|---|
|
未満 |
.1 |
.lt |
|
以下 |
.2 |
.lte |
|
等価 |
.3 |
.eq (デフォルト) |
|
以上 |
.4 |
.gte |
|
Greater than |
.5 |
.gt |
|
部分文字列 |
.6 |
.sub |
等価が、デフォルトの一致ルールです。つまり、一致ルール接尾辞が指定されていない場合、照合ルールでは等価一致ルールが使用されます。次の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"
この項には次のトピックが含まれます:
例17-1 等価検索
次の検索では、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"
例17-2 より小さい検索
次の検索では、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"
例17-3 以下検索
次の検索では、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"
例17-4 以上検索
次の検索では、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"
例17-5 より大きい検索
次の検索では、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"
次の表は、Oracle Unified Directoryによってサポートされている国際化ロケールを、文字接尾辞のアルファベット順に示しています。
表17-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 |
ディレクトリ・サーバーは、ディレクトリ・エントリを管理するためのLDAPv2およびLDAPv3準拠クライアント・ツールの完全なセットを備えています。ldapmodifyおよびldapdeleteユーティリティを使用することで、エントリを追加、更新または削除できます。LDAPコマンドライン・ユーティリティは、コマンドラインから入力またはファイルから読み取られたLDAP Data Interchange Format (LDIF)形式の入力を必要とします。
ディレクトリ・データに変更を行う前に、次の概念を理解していることを確認します:
権限およびアクセス制御メカニズム。
権限の設定の詳細は、第22章「データへのアクセス制御」を参照してください。
ご使用のディレクトリ・サーバーの構造。
ご使用のディレクトリ・サーバーのスキーマ。
この項には次のトピックが含まれます:
ldapmodifyコマンドを使用して1つ以上のエントリをディレクトリ・サーバーに追加できます。ldapmodifyは、ディレクトリ・サーバーへの接続を開き、それにバインドし、コマンドライン・オプションによって指定されたとおりにデータベースに対する変更(この場合は「追加」)を実行します。
ldapmodifyでは、次の2つの方法のいずれかでエントリを追加できます:
--defaultAddオプションの使用。コマンドラインでデータを入力する場合は、--defaultAddオプションを使用して新しいエントリをディレクトリに追加します。終了したら、[Ctrl] + [D] (UNIX、Linux)または[Ctrl] + [Z] (Windows)を押すか、変更内容が含まれている入力ファイルを使用します。
LDIF更新文の使用。LDIF更新文は、ldapmodifyによってディレクトリ・エントリをどのように変更するのかを定義します。LDIF更新文には、変更するエントリのDN、特定のエントリをどのように変更するのか(add、delete、modify、modrdn)を定義するchangetype、および一連の属性とそれらの変更された値が含まれています。
|
注意: 新たに追加されたエントリはすべて、そのディレクトリのスキーマに準拠している必要があります。スキーマに準拠しないエントリを追加すると、サーバーはオブジェクト・クラス違反エラーで応答します。エラーの詳細は、 |
この項には次のトピックが含まれます:
ルート・エントリは、ディレクトリの最上位のエントリであり、ネーミング・コンテキストまたはルート接尾辞を含んでいる必要があります。ルート・エントリは、ディレクトリ・サーバーを最初にインストールするときに、グラフィカル・ユーザー・インタフェース(GUI)またはコマンドラインを使用して設定できます。データを含めずにディレクトリをインストールする場合は、--defaultAddオプションを指定してldapmodifyコマンドを使用してルート・エントリを作成します。
ldapmodifyを使用してルート・エントリを作成します。
$ ldapmodify --hostname localhost --port 1389 --defaultAdd \ --bindDN "cn=Directory Manager" --bindPassword password dn: dc=example,dc=com objectclass: domain objectclass: top dc: example (Press Ctrl-D on Unix, Linux) (Press Ctrl-Z on Windows), then press ENTER. Processing ADD request for dc=example,dc=com ADD operation successful for DN dc=example,dc=com
|
注意:
|
ldapsearchコマンドを使用して変更内容を検証します。
$ ldapsearch --hostname localhost --port 1389 --baseDN "dc=example,dc=com" \ --searchScope base --bindDN "cn=Directory Manager" --bindPassword password \ "(objectclass=*)" dn: dc=example,dc=com objectClass: domain objectClass: top dc: example
ldapmodifyで--defaultAddオプションを使用してエントリを追加する方法LDIF形式でディレクトリ・エントリを作成します。
エントリを追加する前に、エントリの追加先の接尾辞がデータベース内に存在していることを確認します(たとえば、ou=People,dc=example,dc=com)。
この例では、次の内容を持つnew.ldifという入力ファイルを作成します:
dn: uid=Marcia Garza,ou=People,dc=example,dc=com cn: Marcia Garza sn: Garza givenName: Marcia objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson ou: Accounting ou: People l: Santa Clara uid: mgarza mail: mgarza@example.com roomnumber: 5484 userpassword: donuts
--defaultAddオプションを指定してldapmodifyを使用してエントリを追加します。
$ ldapmodify --hostname localhost --port 1389 --bindDN "cn=Directory Manager" \ --bindPassword password --defaultAdd --filename /tmp/new.ldif
ldapmodifyでLDIF更新文を使用してエントリを追加する方法changetype:add要素を指定してLDIF形式でエントリを作成します。
addの後に空白がないことを確認してください。addの後に空白があると、BASE64エンコーディングではその値は空白を表し、それによって問題が発生することがあります。
この例では、new.ldifという名前の入力LDIFファイルを作成します。
dn: uid=Marcia Garza,ou=People,dc=example,dc=com changetype: add cn: Marcia Garza sn: Garza givenName: Marcia objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson ou: Accounting ou: People l: Santa Clara uid: mgarza mail: mgarza@example.com roomnumber: 5484 userpassword: donuts
ldapmodifyを使用してエントリを追加します。
changetype属性によってアクションが指定されるため、-aオプションを含めないでください。
$ ldapmodify --hostname localhost --port 1389 --bindDN "cn=Directory Manager" \ --bindPassword password --filename /tmp/new.ldif Processing ADD request for uid=Marcia Garza,ou=People,dc=example,dc=com ADD operation successful for DN uid=Marcia Garza,ou=People,dc=example,dc=com
LDIF changetype:add文は、エントリをディレクトリに追加します。エントリに属性を追加するには、次の例に示すようにchangetype:modify文を使用します。各コマンドをダッシュ(-)で区切ることで、1つのファイル内の複数のコマンドを結合できます。
この項では、エントリの管理方法を説明しており、内容は次のとおりです:
changetype:modify要素を指定してLDIF形式でエントリを作成します。
既存のエントリを新しい属性を追加して変更しようとしているので、modify変更タイプを使用します。modifyの後に空白がないことを確認してください。changetypeの後に、add: newAttributeNameを指定し、次の行に新しい属性の値を指定します。
この例では、次のようにadd_attribute.ldifという入力LDIFファイルを作成します:
dn: uid=Marcia Garza,ou=People,dc=example,dc=com changetype: modify add: telephonenumber telephonenumber: +1 408 555 8283
|
注意: 複数の属性を追加するには、属性をダッシュ(-)で区切ります。例: dn: uid=Marcia Garza,ou=People,dc=example,dc=com changetype: modify add: telephonenumber telephonenumber: +1 408 555 8283 - add: building building: sc09 |
ldapmodifyを使用して属性を追加します。
$ ldapmodify --hostname localhost --port 1389 --bindDN "cn=Directory Manager" \ --bindPassword password --filename /tmp/add_attribute.ldif 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
ldapmodifyを使用して、アクセス制御命令(ACI)を追加し、ユーザーのアカウントのアクセス権を管理できます。詳細は、第22章「データへのアクセス制御」およびACI構文を参照してください。
次の例では、ユーザーに自身のディレクトリ属性の変更を許可します。
ACIが含まれているLDIFファイルを作成します。
dn: uid=Marcia Garza,ou=People,dc=example,dc=com changetype: modify add: aci aci: (target="ldap:///uid=Marcia Garza,ou=People,dc=example,dc=com") (targetattr="*")(version 3.0; acl "mgarza rights"; allow (write) userdn="ldap:///self";)
ldapmodifyを使用して属性を追加します。
$ ldapmodify --hostname localhost --port 1389 --bindDN "cn=Directory Manager" \ --bindPassword password --filename /tmp/add_aci.ldif 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
ディレクトリ・サーバーでは、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エンコードする必要があります。 |
LDIF更新文changetype:modifyを使用して、既存のディレクトリ・データに変更を行います。次の手順は、ディレクトリ・エントリを変更する例を示し、内容は次のとおりです:
詳細は、付録A「ldapmodify」を参照してください。
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
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
この例では、エントリから位置(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)を押して入力を完了します。
エントリの識別名(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で置き換えることを示します。
ldapmodifyコマンドを使用して、エントリの名前を変更します。
この例では、従業員Marcia Garzaは、彼女の結婚後の名前であるMarcia Petersに変更したいと考えています。
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file dn: uid=Marcia Garza,ou=Marketing,dc=example,dc=com changetype: moddn newrdn: uid=Marcia Peters deleteoldrdn: 1 Processing MODIFY DN request for uid=Marcia Garza,ou=People,dc=example,dc=com MODIFY DN operation successful for DN uid=Marcia Garza,ou=People,dc=example,dc=com
必要に応じて、他の属性を変更します。
この例では、特定の属性に、ユーザーの前の名前が依然としてリストされている可能性があります。
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file dn: uid=Marcia Peters,ou=People,dc=example,dc=com changetype: modify replace: sn sn: Peters - replace: cn cn: Marcia Peters - replace: uid uid: mpeters uid: Marcia Peters - replace: mail mail: mpeters@example.com (Press Ctrl-D on Unix, Linux) (Press Ctrl-Z on Windows), then press ENTER. Processing MODIFY request for uid=Marcia Peters,ou=People,dc=example,dc=com MODIFY operation successful for DN uid=Marcia Peters,ou=People,dc=example,dc=com
1つの親から別の親にエントリを移動する場合、その親エントリのアクセス制御命令(ACI) 権限を拡張します。エントリの移動元の親エントリ上で、構文allow(export...)を使用することで、ACIでエクスポート操作が許可されるようにします。エントリの移動先の親エントリ上で、構文allow(import...)を使用することで、ACIでインポート操作が許可されるようにします。
この例では、uid=sgarzaをou=Contractors,dc=example,dc=com接尾辞からou=People,dc=example,dc=comサブツリーに移動します。
moddn変更タイプを指定してldapmodifyを使用し、エントリを移動します。
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file dn: uid=sgarza,ou=Contractors,dc=example,dc=com changetype: moddn newrdn: uid=sgarza deleteoldrdn: 0 newsuperior: ou=People,dc=example,dc=com --filename move_entry.ldif Processing MODIFY DN request for uid=sgarza,ou=Contractors,dc=example,dc=com MODIFY DN operation successful for DN uid=sgarza,ou=Contractors,dc=example,dc=com
必要に応じて、他の属性値を変更します。
次の例では、ou属性の前後のスナップショットの変更を示します。
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ --preReadAttributes ou --postReadAttributes ou dn: uid=sgarza,ou=People,dc=example,dc=com changetype: modify replace: ou ou: People ou: Product Testing (Press Ctrl-D on Unix, Linux) (Press Ctrl-Z on Windows), then press ENTER. Processing MODIFY request for uid=sgarza,ou=People,dc=example,dc=com MODIFY operation successful for DN uid=sgarza,ou=People,dc=example,dc=com Target entry before the operation: dn: uid=sgarza,ou=People,dc=example,dc=com ou: Contractors ou: Product Testing Target entry after the operation: dn: uid=sgarza,ou=People,dc=example,dc=com ou: People ou: Product Testing
ldapmodifyおよびldapdeleteを使用して、ディレクトリからエントリを削除できます。ldapmodifyコマンドは、delete属性とともに、LDIF更新文changetype:deleteを使用してエントリを、changetype:modifyを使用して属性を削除します。ldapdeleteツールでは、エントリのみが削除されます。
|
注意: 子エントリを持つエントリは削除できません。子を持つエントリを削除する場合、最初にターゲット・エントリの下にあるすべての子エントリを削除してから、そのエントリを削除します。 |
詳細は、付録A「ldapdelete」を参照してください。
この項では、ディレクトリ・エントリの削除方法を説明しており、内容は次のとおりです:
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
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
削除するDNのリストが含まれているファイルを作成します。
この例では、ファイルはdelete.ldifという名前です。ファイルには、各DNが個別の行にリストされます。次の例:
uid=mgarza,ou=People,dc=example,dc=com uid=wsmith,ou=People,dc=example,dc=com uid=jarrow,ou=People,dc=example,dc=com uid=mbean,ou=People,dc=example,dc=com
ldapdeleteコマンドに引数としてファイルを渡すことで、エントリを削除します。
$ ldapdelete -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ --continueOnError --filename delete.ldif Processing DELETE request for uid=mgarza,ou=People,dc=example,dc=com DELETE operation successful for DN uid=mgarza,ou=People,dc=example,dc=com Processing DELETE request for uid=wsmith,ou=People,dc=example,dc=com DELETE operation successful for DN uid=wsmith,ou=People,dc=example,dc=com Processing DELETE request for uid=jarrow,ou=People,dc=example,dc=com DELETE operation successful for DN uid=jarrow,ou=People,dc=example,dc=com Processing DELETE request for uid=mbean,ou=People,dc=example,dc=com DELETE operation successful for DN uid=mbean,ou=People,dc=example,dc=com
|
注意:
|
この項では、dsconfigコマンドライン・ツールを使用して属性に索引付けする方法を説明します。索引は、サーバーごとに構成され、索引構成はレプリケートされません。
dsconfigを使用して、ローカル・データベース索引および仮想リスト表示(VLV)索引を作成します。ローカル・データベース索引は、検索基準に一致するエントリを見つけるために使用されます。VLV索引は、VLV制御で効率的に検索を処理するために使用されます。
ユーザーにunindexed-search権限がある場合以外は、索引付けされていない検索はデフォルトで拒否されます。詳細は、第23.3.5項「ルート・ユーザーの特権を変更するには」を参照してください。
次の2つの方法で、検索が索引付けされているかどうかを判別できます:
匿名で検索の実行を試みます。(サーバーは、デフォルトで、索引付けされていない匿名検索を拒否します。)
debugsearchindex操作属性を使用します。この属性は、検索で使用される索引、各索引からの候補エントリの数、最終的な索引付けされたステータスを提供します。次のように、ldapsearchコマンドにdebugsearchindex属性を含めます:
$ ldapsearch -h localhost -p 1389 -b "dc=example,dc=com" "(objectClass=*)" debugsearchindex
この項では、データの索引付け方法を説明しており、内容は次のとおりです:
ローカルDBバックエンドでは、次の索引タイプがサポートされています:
approximate: 近似検索フィルタを使用する検索の効率を高めます。
equality: 等価検索フィルタを使用する検索の効率を高めます。
ordering: 以上または以下の検索フィルタを使用する検索の効率を高めます。今後、この索引タイプは、サーバー側ソートにも使用される可能性があります。
presence: プレゼンス検索フィルタを使用する検索の効率を高めます。
substring: 部分文字列検索フィルタを使用する検索の効率を高めます。
ディレクトリ・サーバーでは、照合一致ルール、相対時間の一致ルール、部分的な日付や時刻の一致ルールなど拡張可能一致操作のサブセットに対してのみ索引付けがサポートされています。詳細は、第17.5.5項「国際化されたエントリの検索」、第9.1.3項「相対時間の一致ルール」および第9.1.4項「部分的な日付や時間の一致ルール」を参照してください。
dsconfigで新しいローカルDBバックエンドを作成すると、次のデフォルト索引が自動的に作成されます:
aci (プレゼンス索引)
ds-sync-hist (順序付け索引)
entryuuid (等価索引)
objectclass (等価索引)
この項には次のトピックが含まれます:
これは、新規ローカルDB索引を作成する手順を示しています。
|
注意: 新しい索引を作成した後、 |
新しい索引を作成します。
$ 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機能を通して使用可能です。詳細は、第17.13.1項「レプリケートされたトポロジでのリフェラル」を参照してください。
例17-7 新しい等価索引の作成
この例では、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
例17-8 部分文字列索引の追加
この例では、前の例で作成した索引に部分文字列索引を追加します。
$ 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
VLV索引は、指定されたベース・エントリおよびそのサブツリーに対する特定の検索に適用されます。索引を作成するときは、ソート順序、索引の範囲、ベースDNおよびフィルタを定義する必要があります。
新しいVLV索引を作成した後、rebuild-indexコマンドを使用して索引を再構築し、索引名の前にvlv.を追加する必要があります。ディレクトリ・サーバーは、索引が再構築されるまで新しい索引を使用できません。詳細は、付録A「rebuild-index」を参照してください。
VLVリクエスト制御へのアクセスは、デフォルトで、認証されたユーザーにのみ許可されることに注意してください。認証されていないユーザーが検索リクエストでVLV制御を使用できるようにする場合は、対応するグローバルACIを変更する必要があります。詳細は、第17.5.3.16.4項「仮想リスト表示制御への匿名アクセスの許可」を参照してください。
次のように、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
例17-9 新しい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
ディレクトリ・サーバーは、格納されるデータのサイズを減らすための2つのメカニズムを備えています:
圧縮エンコーディング。圧縮エンコーディングが有効化されている場合、バックエンドではエントリをエンコードするときに属性の説明とオブジェクト・クラス・セットを圧縮することで、圧縮形式が使用されます。このプロパティは、エントリ自体にのみ適用され、索引データには影響を与えません。圧縮エンコーディングは、デフォルトで有効化されていますが、必要に応じて無効化できます。ご使用のデプロイメントで、オブジェクト・クラスおよび属性タイプ名でユーザーによる先頭文字の大文字化が必要とされている場合、ユーザーによる先頭文字の大文字化は圧縮されたエントリでは保持されないため、圧縮エンコーディングを無効化できます。ただし、圧縮は、パフォーマンスを向上させるため、パフォーマンスのためにはユーザーによる先頭文字の大文字化を無視できるか、それが不要なデプロイメントでは利点があります。
エントリの圧縮。エントリの圧縮では、デフレータを使用して、データを格納する前に圧縮します。エントリの圧縮を有効化すると、エントリをデータベースに格納する前にバックエンドによってそれらの圧縮が試みられます。このプロパティも、エントリ自体にのみ適用され、索引データには影響を与えません。エントリの圧縮の有効性は、エントリに含まれているデータ型に基づきます。
これらのメカニズムの1つまたは両方を有効化して、格納されるデータのサイズを減らすことができます。これらのメカニズムを有効化すると、今後の書込みにのみ作用するため、データベースには、圧縮されたデータと圧縮されていないレコードが混在することがあります。圧縮の設定に関係なく、どちらのタイプのレコードも読取り可能です。
この項の内容は次のとおりです:
圧縮エンコーディングは、ローカル・バックエンド・ワークフロー要素の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
エントリの圧縮は、ローカル・バックエンド・ワークフロー要素の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
ディレクトリの構造では、識別名によって、ディレクトリ情報ツリー内のオブジェクトおよびその場所が一意に識別される必要があります。ディレクトリ・サーバーは、一意属性プラグインを備えており、それによって、属性がディレクトリ内で追加、変更または移動された場合に、属性値の一意性が確保されます。
この項の内容は次のとおりです:
一意属性プラグインは、デフォルトで無効化されています。このプラグインは、dsconfigコマンドを使用することで有効化でき、それによってチェックされる接尾辞および属性を定義できます。このプラグインは、有効化されている場合、操作によってデータベースが更新される前に、LDAP追加、変更またはDN変更操作によって、2つのエントリが同じ属性を持つようになるかどうかを識別します。サーバーによって競合が認識された場合、操作は終了され、LDAP_CONSTRAINT_VIOLATIONエラーがクライアントに返されます。
既存のディレクトリで属性値の一意性を有効にしても、サーバーは既存のエントリ間での一意性をチェックしません。プラグインが有効化された後は、エントリが追加、変更または移動されるときに一意性が強制されます。
一意属性プラグインを構成すると、ディレクトリ内の1つ以上のサブツリー内または特定のオブジェクト・クラスのエントリ間に一意性を強制できます。他の属性の一意性を確保する場合、一意属性プラグインのインスタンスをいくつか定義できます。通常、値を一意にする属性ごとに、1つのプラグイン・インスタンスを定義します。同じ属性に複数のプラグイン・インスタンスを用意することで、複数のエントリ・セットでその属性の一意性を個別に確保できます。
一意属性プラグインはデフォルトでは無効化されており、マルチマスターのレプリケーション構成が影響を受けることはありません。プラグインが有効化されていると、スタンドアロン・システムの場合は追加、変更またはDN変更操作の前にuid属性が一意であることが確認され、レプリケートされた環境では同期の後に一意性がチェックされます。
一意属性プラグインは、他のプラグインと同様に、dsconfigコマンドを使用して構成されます。詳細は、第14.1.9項「dsconfigを使用したプラグインの構成」を参照してください。プラグインを構成する最も簡単な方法は、対話モードでdsconfigを使用することです。対話モードは、ウィザードのように機能し、プラグイン構成を手順を追ってガイドします。対話モードは説明不要であるため、この項の例では、対話モードを例示せず、同等の完全なdsconfigコマンドについて説明します。
dsconfigを使用した一意な属性プラグインの構成次の手順では、属性値の一意性を構成する方法について説明します。
uid属性の値の一意性を確保する方法デフォルトでは、一意属性プラグインはuid属性をチェックします。次のタスクによって、一意属性プラグインが有効化され、ベースDN(その下のuid属性の属性値の一意性がチェックされる)が設定されます。
サーバーで現在定義されているプラグインを表示します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ list-plugins
インストールに応じて、出力は次のものに類似したものになります。
Plugin : Type : enabled --------------------------------:---------------------------------:-------- 7-Bit Clean : seven-bit-clean : false Change Number Control : change-number-control : true Entry UUID : entry-uuid : true LastMod : last-mod : true LDAP Attribute Description List : ldap-attribute-description-list : true Password Policy Import : password-policy-import : true Profiler : profiler : true Referential Integrity : referential-integrity : false UID Unique Attribute : unique-attribute : false
一意属性プラグインに対して構成されているプロパティを表示します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ get-plugin-prop \ --plugin-name "UID Unique Attribute" \ Property : Value(s) ---------:--------- base-dn : - enabled : false type : uid
一意属性プラグインを有効化します。
$ dsconfig --advanced -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ set-plugin-prop \ --plugin-name "UID Unique Attribute" --set enabled:true
|
注意:
|
ベースDN(それより下で一意性がチェックされる)を設定します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ set-plugin-prop \ --plugin-name "UID Unique Attribute" --set base-dn:ou=People,dc=example,dc=com
デフォルトでは、一意属性プラグインはuid属性をチェックします。別の属性の一意性を確認する場合は、一意属性プラグインの新しいインスタンスを作成し、そのtypeプロパティを設定します。
この例では、一意属性プラグインの新しいインスタンスを作成し、mail属性の一意性を確認します。
一意属性プラグインの新しいインスタンスを作成し、有効化します。
typeプロパティを、一意である必要がある属性の名前(この場合はmail)に設定します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ create-plugin \ --type unique-attribute --plugin-name "MAIL unique attribute" --set enabled:true --set type:mail
新しい一意属性プラグインを有効化します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ set-plugin-prop \ --plugin-name "MAIL Unique Attribute" --set enabled:true
ベースDN(それより下で一意性がチェックされる)を設定します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ set-plugin-prop \ --plugin-name "MAIL Unique Attribute" --set base-dn:ou=People,dc=example,dc=com
値を一意にする必要がある属性を指定します。
この例では、mail属性を指定します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ set-plugin-prop \ --plugin-name "MAIL Unique Attribute" --set type:mail
1つ以上の属性の値が一意であることを確認するには、一意属性プラグインの複数のインスタンスを作成し、有効化します。
レプリケーション操作の一環として更新が実行される際は、一意属性プラグインによる属性の一意性チェックは行われません。レプリケーション環境で属性値の一意性を確認するには、トポロジ内のすべてのサーバーの同じサブツリーの同じ属性に対して一意属性プラグインを有効化します。
仮想属性とは、永続ストレージに存在しないがいずれかの方法で動的に生成される値を持つ属性です。
Oracle Unified Directoryでは次の仮想属性タイプをサポートしています:
collective attribute subentries
entryDN
entryUUID
governingStructureRule
hasSubordinates
isMemberOf
member
nsuniqueid
numSubordinates
orclguid
Password Policy Subentry
Proximity
structuralObjectClass
subschemaSubentry
ユーザー定義仮想属性
仮想属性は、dsconfigコマンドを使用して構成されます。dsconfigコマンドは、第14.3項「サーバーへの管理トラフィックの管理」を使用してSSL経由でプラグイン構成にアクセスします。仮想属性を構成する最も簡単な方法は、対話モードでdsconfigを使用することです。対話モードは、ウィザードのように機能し、仮想属性構成を手順を追ってガイドします。対話モードは説明不要であるため、この項の例では、対話モードを例示せず、同等の完全なdsconfigコマンドについて説明します。
dsconfigの使用の詳細は、第14.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 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。仮想属性が生成される属性のタイプを指定します。
この例では、位置がシドニーのユーザー・エントリに仮装FAX番号の+61 2 45607890を追加する仮想属性ルールを作成し、有効化します(彼らが自身のエントリにすでにFAX番号を持っていない場合):
dsconfigコマンドを次のように実行します:
$ 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))"
仮想属性を有効化するには、enabledプロパティをtrueに設定します。仮想属性を無効化するには、enabledプロパティをfalseに設定します。この例では、前の例で作成された仮想属性を無効化します:
dsconfigコマンドを次のように実行します:
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ set-virtual-attribute-prop --name="Sydney Fax Number" --set enabled:false
dsconfigのget-*-propサブコマンドを使用して、仮想属性構成を表示します。この例では、前の例で作成された仮想属性のプロパティを表示します:
dsconfigコマンドを次のように実行します:
$ 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
dsconfigのset-*-propサブコマンドを使用して、仮想属性構成を変更します。この例では、競合が発生した場合に仮想属性の動作を変更します。デフォルトでは、実際の属性の値によって仮想属性の値が上書きされます。この変更によって、実際の属性の値と仮想属性の値がマージされます。
dsconfigコマンドを次のように実行します:
$ 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
LDAPサブエントリは、サーバーの操作データを保持し、ldapSubEntryオブジェクト・クラスを持つ特別なエントリです。それらは、サブエントリ制御リクエスト制御を含めることで明示的にリクエストされない場合は、クライアントに返されない点で、操作属性に似ています。
LDAPサブエントリは、エントリの範囲を指定するために使用できます。この機能は、集合属性の定義で使用され、アクセス制御などの他の分野でも便利です。詳細は、第17.12項「集合属性の使用方法」および第24.4.7項「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つあり、それは次の項で説明します。
相対サブツリーは標準サブツリーのように機能します。ただし、仕様フィルタは、一連の絞込みではなくLDAP検索フィルタです
相対サブツリーの場合は、仕様によって、relativeBaseキーワードを使用してサブツリーのルートを指定することが定められています。baseキーワードを使用してサブツリーのルートを指定しないでください。
たとえば、次のサブツリー定義は、ベースDN ou=Peopleの下の、位置がパリのすべてのユーザーをターゲットにします:
subtreeSpecification: {relativeBase "ou=people", specificationFilter "(l=Paris)" }
集合属性は、エントリのコレクション全体で共有される値を持つ属性です。集合属性は、Oracle Directory Server Enterprise Editionサービス・クラス機能に類似した機能を提供します。
Oracle Unified Directoryの集合属性は、仮想属性に似ていますが、LDAPサブエントリとしてユーザー・データとともに定義され、格納されます。ユーザー・データの一部として、集合属性は、トポロジ内の他のサーバーにレプリケートできます。
この項では、Oracle Unified Directory内の集合属性の実装と、集合属性の構成方法について説明します。この項の内容は次のとおりです:
集合属性のOracle Unified Directoryでの実装は、RFC 3671 (http://www.ietf.org/rfc/rfc3671.txt)およびRFC 3672 (http://www.ietf.org/rfc/rfc3672.txt)に基づいており、いくつかの特定の拡張があります。これの拡張により、Oracle Unified Directoryの集合属性は、LDAPクライアント・アプリケーションに対して、より透過的になっており、これについては次の項で説明します:
RFC 3671 (http://www.ietf.org/rfc/rfc3671.txt)によれば、集合属性はCOLLECTIVE属性タイプを持ち、スキーマで定義されている通常のユーザー属性から導出し、c-接頭辞を持っている必要があります。たとえば、c-lは、標準l属性に対する集合属性であり、影響を受けるユーザー・エントリには実行中にc-lが追加されます。
この仕様により、多くのクライアント・アプリケーションで問題が発生することがあります。それらは、一般的に、集合属性を認識せず、集合属性を処理するように変更または拡張する必要がありすま。したがって、Oracle Unified Directoryでは、この制約を取り除き、任意の通常の属性を、スキーマ内で集合属性として定義することがサポートされています。この拡張は、関連する集合属性サブエントリに、必要な属性を追加し、その属性に集合オプションでマークすることで容易になります。
集合属性には、様々な方法で名前が付けられます。このため、すでに関連する実際の属性を含んでいる影響を受けるユーザー・エントリに対して、競合解消メカニズムが提供されています。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-real
場合によっては、特定のユーザー・エントリに集合属性を含めることを避ける必要があります。この動作を得るために、そのようなエントリに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: excludeAllCollectiveAttributes
集合属性は、ディレクトリ・ツリー内の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)を参照してください。
この項では、集合属性に関する次の内容について説明します:
集合属性サブエントリを指定するchangetype: add要素を含むLDIFファイルを作成します。
addの後に空白がないことを確認してください。addの後に空白があると、BASE64エンコーディングではその値は空白を表し、それによって問題が発生することがあります。
この例では、add_collective_attr.ldifという名前の入力LDIFファイルを使用します。
dn: cn=People Preferred Language,dc=example,dc=com
changetype: add
objectClass: top
objectClass: subentry
objectClass: collectiveAttributeSubentry
objectClass: extensibleObject
cn: People Preferred Language
preferredLanguage;collective: fr
subtreeSpecification: {base "ou=people", minimum 1}
次の例に示すように、ldapmodifyコマンドを使用して、集合属性を追加します。
$ ldapmodify -p 1389 -h localhost -D "cn=Directory Manager" -j pwd-file \ -f /usr/local/add_collective_attr.ldif Processing ADD request for cn=People Preferred Language,dc=example,dc=com ADD operation successful for DN cn=People Preferred Language,dc=example,dc=com
集合属性は、ldapdeleteコマンドまたはldapmodifyコマンドを使用することで削除できます。この例では、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
特定のユーザー・エントリに適用される集合属性サブエントリをリストするには、そのエントリに対する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
継承属性では、継承の特性から、属性の共通セットの共有が可能になります。継承集合属性は、標準サブエントリ・サブツリー仕様を使用する柔軟な範囲指定メカニズムを提供し、RDNの定義および構築のためのすべての属性タイプをサポートします。
集合属性と継承集合属性の主な相違は、属性値のソースです:
集合属性は、常に、その値をその定義エントリから導出します。
継承集合属性は、直接的または間接的に他のエンティティから集合属性値を継承できます。
継承集合属性の機能は、就航属性の上に構築および拡張されます。継承属性は、集合属性サブエントリの特別なタイプとして定義されます(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
通常の集合属性と同様に、継承集合属性は、ディレクトリ・ツリー内の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
リフェラルは、結果のかわりにクライアントに返されるリモート接尾辞またはエントリへのポインタです。サーバーは、クライアントのリクエストを処理できない場合、トポロジ内の他のサーバーをクライアントに示すリフェラルのリストをクライアントに送信します。その後、クライアントは、リフェラル・リスト内のリモート・サーバーの1つに対して操作を再度実行します。
サーバーは、次の場合にリフェラルのリストを返します:
サーバーまたはローカル・バックエンド・ワークフロー要素で、書込み可能性が無効化されているかinternal-onlyに設定されています。詳細は、第D.22.6項「書込み可能モード」を参照してください。
この種のリフェラルは、referral on updateと呼ばれます。
ローカル・バックエンド・ワークフロー要素が、メンテナンス・モードになっていました。
一時的に、サーバーがクライアント・リクエストに応答しないようにする場合は、ローカル・バックエンド・ワークフロー要素をメンテナンス・モードにすることができます。
バックエンドをメンテナンス・モードにするには、ローカル・バックエンド・ワークフロー要素のmaintenanceプロパティをtrueに設定します。
データ・インポートまたは再索引付けの処理中などなんらかの理由で、バックエンドが使用できません。
クライアント・リクエストが明示的にスマート・リフェラルをターゲットにしています。詳細は、第17.13.3項「スマート・リフェラル」を参照してください。
リフェラルURLは、ホスト名、ポート番号、および必要に応じてローカル・ホストまたは別のサーバーのDNを含むLDAP URLです。詳細は、第17.13.4項「LDAP URL」を参照してください。
使用可能な場合は、サーバーから結果コードREFERRAL (10)がリフェラルURLのリストとともに返されます。使用可能なリフェラルURLがない場合は、サーバーから結果コードUNAVAILABLE (52)が返されます。
リフェラルURLは次の2つの方法で作成できます:
レプリケートされたサーバーの場合は、レプリケーション・サービスを使用してリストを伝播します。詳細は、第17.13.1項「レプリケートされたトポロジでのリフェラル」を参照してください。
DBローカル・バックエンド・ワークフロー要素のds-cfg-referrals-urlプロパティを設定することで、リストを手動で作成します。詳細は、第17.13.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に設定されている場合は、レプリケーション・サービスによって生成されるリフェラルのリストにそのサーバーは含まれなくなります。
レプリケーション・サービスによって提示されるリフェラル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
スマート・リフェラルは、別のサーバーまたは別の接尾辞のコンテンツを参照する特別なタイプのエントリです。スマート・リフェラル・エントリには、ref属性の1つ以上のインスタンスを含むreferralオブジェクト・クラスが含まれています。各ref属性には、リフェラルで使用されるLDAP URLが含まれています。
スマート・リフェラルを構成するには、referralオブジェクト・クラスおよびref属性を含む新しいエントリを追加します。ref属性には、LDAP URLが含まれている必要があります。
この例では、サーバーAに存在しているユーザー・エントリのリフェラルをサーバーBに作成します。
次の検索コマンドを実行することでサーバーA上のユーザー・エントリを見つけます:
$ ldapsearch -h serverA -p 1389 -b dc=example,dc=com "uid=user.199" cn dn: uid=user.199,ou=People,dc=example,dc=com cn: Alfred Altay
サーバーB上のディレクトリにリフェラル・エントリを追加します。
$ ldapmodify -h serverB -p 2389 -D "cn=directory manager" -j pwd-file dn: uid=aaltay,ou=People,dc=example,dc=com changetype: add objectclass: top objectclass: extensibleObject objectclass: referral uid: aaltay ref: ldap://serverA:1389/dc=example,dc=com??sub?(uid=user.199) Processing ADD request for uid=aaltay,ou=People,dc=example,dc=com ADD operation successful for DN uid=aaltay,ou=People,dc=example,dc=com
十分なアクセス権を持つユーザーとして、サーバーB上のユーザー・エントリを検索します。
$ ldapsearch -h serverB -p 2389 -D "cn=directory manager" -j pwd-file \
-b dc=example,dc=com "uid=aaltay"
SearchReference(referralURLs={ldap://localhost:1389/dc=example,dc=com??sub?})
スマート・リフェラルを表示または変更するには、manageDsaIT制御を指定して、ldapsearchまたはldapmodifyコマンドを使用します。この制御は、サーバーに、通常のエントリとしてリフェラル・オブジェクトを管理する予定であることを通知し、リフェラル・オブジェクトを読み取りまたは更新するリクエストに対してサーバーからリフェラル結果が送信されないようにします。
ldapsearchコマンドを使用して、リフェラルを表示します。
$ ldapsearch -h serverB -p 2389 -D "cn=Directory Manager" -j pwd-file \ -b dc=example,dc=com --control managedsait "(uid=aaltay)" ref dn: uid=aamar,ou=People,dc=example,dc=com ref: ldap://serverA:1389/dc=example,dc=com??sub?(uid=user.199)
ldapmodifyコマンドを使用して、リフェラルを変更します。
この例では、リフェラルが指すサーバーと、下にエントリが配置されているベースDNを変更します。
$ ldapmodify -h serverB -p 2389 -D "cn=Directory Manager" -j pwd-file \ --control managedsait dn: uid=aaltay,ou=People,dc=example,dc=com changetype: modify replace: ref ref: ldap://serverC:1389/ou=People,dc=example,dc=com??sub?(uid=user.199) Processing MODIFY request for uid=aaltay,ou=People,dc=example,dc=com MODIFY operation successful for DN uid=aaltay,ou=People,dc=example,dc=com
スマート・リフェラルを削除するには、manageDsaIT制御を指定して、ldapdeleteコマンドを使用します。この制御は、サーバーに、通常のエントリとしてリフェラル・オブジェクトを管理する予定であることを通知し、リフェラル・オブジェクトを読み取りまたは更新するリクエストに対してサーバーからリフェラル結果が送信されないようにします。
ldapsearchコマンドを使用して、リフェラルを表示します。
$ ldapsearch -h serverB -p 2389 -D "cn=Directory Manager" -j pwd-file \ -b dc=example,dc=com --control managedsait "(uid=aaltay)" ref dn: uid=aamar,ou=People,dc=example,dc=com ref: ldap://serverA:1389/dc=example,dc=com??sub?(uid=user.199)
ldapdeleteコマンドを使用して、リフェラルを削除します。
$ ldapdelete -h serverB -p 2389 -D "cn=Directory Manager" -j pwd-file \ --control managedsait "uid=aaltay,ou=People,dc=example,dc=com" Processing DELETE request for uid=aaltay,ou=People,dc=example,dc=com DELETE operation successful for DN uid=aaltay,ou=People,dc=example,dc=com
LDAP URLの形式は、RFC 4516で説明されており、次のように要約されます:
ldap[s]://hostname:port/base_dn?attributes?scope?filter
LDAP URLのコンポーネントは、次のとおりです:
ldap[s]サーバーに接続するのか(ldap:)、SSL経由でサーバーに接続するのか(ldaps:)を示します。
LDAPサーバーのホスト名またはIPアドレスを指定します。
LDAPサーバーのポート番号を指定します。ポートが指定されていない場合、デフォルトLDAPポート(389)またはLDAPSポート(636)が使用されます。
ディレクトリ内のエントリの識別名(DN)を指定します。このDNは、検索の開始点であるエントリを識別します。ベースDNが指定されていない場合、検索は、そのディレクトリ・ツリーのルートから開始されます。
指定された属性を返します。複数の属性を区切るには、カンマを使用します。属性が指定されていない場合、検索によってすべての属性が返されます。
検索の範囲を指定します:
base。base_dnで指定されたベース・エントリのみを検索します。
one。base_dnで指定されたベース・エントリの1レベル下を検索します。
sub。base_dnで指定されたベース・エントリおよびその下のすべてのエントリを検索します。
範囲が指定されていない場合、ベース検索が実行されます。
検索の指定された範囲内のエントリに適用される検索フィルタを指定します。フィルタが指定されていない場合、デフォルト(objectclass=*)が使用されます。
空白はすべて、ご使用のシェルに適した文字を使用してエスケープする必要があります。
|
注意: LDAPクライアントが認証を提供しない場合、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
ODSMの各サーバー・インスタンスの「構成」タブで、仮想属性を作成、削除、および変更できます。
次の項では、ODSMで仮想属性を管理する方法を説明し、内容は次のとおりです:
ODSMで既存の仮想属性を表示するには、次の手順を実行します:
第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「構成」タブを選択します。
「一般構成」ノードを開きます。
「仮想属性」ノード内の属性を開き、既存の仮想属性をすべて表示します。
左ペインで、表示する仮想属性をクリックします。
右ペインに、仮想属性の詳細が表示されます。
ODSMを使用して仮想属性を作成するには、次の手順を実行します:
第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「構成」タブを選択します。
「作成」メニューから、「仮想属性」を選択します。
「名前」フィールドに、仮想属性の名前を入力します。
「仮想属性タイプ」リストから、仮想属性のタイプを選択します。
「追加」アイコンをクリックし、この仮想属性の使用に適したエントリが含まれている分岐のベースDNを入力します。
次のいずれかを実行してベースDNを入力します:
「ベースDN」フィールドで、目的のベースDNを入力します。
「選択」をクリックし、ツリー・ビューまたは検索ビューを使用してエントリを選択します。
「追加」アイコンをクリックし、この仮想属性の使用に適したメンバーを持つグループのDNを入力します。
次のいずれかを実行して、グループのDNを指定します:
「グループDN」フィールドで、目的のグループDNを入力します。
「選択」をクリックし、ツリー・ビューまたは検索ビューを使用してエントリを選択します。
「追加」アイコンをクリックし、それらのエントリに対して仮想属性を生成する必要があるかどうかを判別するためにそれらのエントリに対して適用される検索フィルタを指定します。
「作成」をクリックします。
|
注意: 前述の手順で説明したプロパティは、追加のプロパティが含まれているユーザー定義およびメンバー仮想属性を除いて、すべての仮想属性に対して同じです。 ユーザー定義仮想属性 これには、次の追加プロパティがあります:
メンバー仮想属性 これには、次の追加プロパティがあります:
|
ODSMの各サーバー・インスタンスの「データ・ブラウザ」タブで、ディレクトリ・データに対する基本検索を実行でき、エントリを追加、削除、および変更できます。
ODSMには、どのデータ・フィールドにも文字のサブセットを入力できる自動提案機能があります。その後、ODSMによって、その文字のサブセットに一致するすべてのエントリが返されます。自動提案機能では、ODSMによってすでにキャッシュされているエントリのみが返されます。
次の項では、ODSMでのデータの管理方法を説明し、内容は次のとおりです:
ODSMデータ・ブラウザを使用してディレクトリ・エントリを表示するには、次の手順を完了します:
第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「データ・ブラウザ」タブを選択します。
「ネットワーク・グループ」リストから適切なネットワーク・グループを選択します。
「エントリ」ペインでエントリを開き、必要なサブツリー内のエントリをすべて表示します。
一度に最大200個のエントリが表示されます。
特定のエントリ・セットにエントリを制限するには、サブツリー(たとえば、ou=People)を選択し、「フィルタ」アイコンをクリックします。
「フィルタ」フィールドで、必要なフィルタ(たとえば、surname=a*)を入力し、「OK」をクリックします。
左ペインで表示するエントリを選択します。
右側のタブにエントリの詳細が表示されます。
第17.15.2項「エントリの属性の表示」も参照してください。
エントリの属性を表示するには:
第17.15.1項「エントリの表示」の説明に従って、エントリを表示します。
左ペインで表示するエントリを選択します。
右側のタブにエントリの詳細が表示されます。
すべてのエントリに、対応する「プロパティ」タブがあり、それにはそのエントリの使用可能な属性(必須とオプション)がすべて表示されます。さらに、次のタイプのエントリには、カスタマイズされたタブがあり、それにはそのエントリ・タイプに対して論理的なレイアウトでエントリの必須属性が表示されます:
inetorgpersonエントリには、対応する「ユーザー・ページ」タブがあります。
groupエントリには、対応する「グループ・ページ」タブがあります。
countryエントリには、対応する「国ページ」タブがあります。
domainエントリには、対応する「ドメイン・ページ」タブがあります。
organizationエントリには、対応する「組織ページ」タブがあります。
organization unitエントリには、対応する「組織単位ページ」タブがあります。
「データ・ブラウザ」タブの基本検索機能では、ユーザーまたはグループのエントリを検索できます。ディレクトリ・データに対して基本検索を実行するには、次の手順を完了します:
第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「データ・ブラウザ」タブを選択します。
「ネットワーク・グループ」リストから適切なネットワーク・グループを選択します。
左ペインで「検索」タブを選択します。
「対象」リストから、ユーザー・エントリとグループ・エントリのどちらを検索するのかを選択します。
エントリ名の任意の部分を入力し、右矢印ボタンをクリックします。たとえば、John Smithというユーザーを検索するには、Smith、Smi、Johnなどを入力できます。
左ペインにエントリが表示されたら、そのエントリをダブルクリックし、右ペインにその詳細を表示します。
Oracle Directory Services Managerでエントリを追加または削除するには、親エントリに対する書込みアクセス権限があり、新規エントリの識別名を認識している必要があります。ODSMデータ・ブラウザを使用してエントリを追加するには、次の手順を完了します:
第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「データ・ブラウザ」タブを選択します。
「ネットワーク・グループ」リストから適切なネットワーク・グループを選択します。
「エントリの追加」アイコンをクリックし、追加するエントリの種類(たとえば、「ユーザー・エントリ」)を選択します。
親エントリのDNを入力します。これはディレクトリ・ツリーでその下に新しいエントリが表示されるエントリです。たとえば、ou=people,dc=example,dc=comです。
親エントリとして既存のエントリを選択するには、「選択」をクリックします。
「エントリ・ピッカー」ウィンドウで、「ツリー・ビュー」を選択してディレクトリ・ツリーに移動し、対象のエントリを見つけるか、「検索ビュー」を選択して対象のエントリを検索します。
新しいエントリの追加情報を入力します。
必要な詳細を入力したら、「作成」をクリックします。
ODSMデータ・ブラウザを使用して既存のエントリに基づいたエントリを追加するには、次の手順を完了します:
第17.15.1項「エントリの表示」の説明に従って、既存のエントリを表示します。
新しいエントリの基にするエントリを選択し、類似エントリの作成アイコンをクリックします。
既存のエントリの詳細が右ペインに表示されます。
そのエントリの新しい共通名 およびユーザー名を指定します。
エントリの他の詳細を変更します。
「作成」をクリックします。
ODSMデータ・ブラウザを使用してエントリを削除するには、次の手順を完了します:
第17.15.1項「エントリの表示」の説明に従って、既存のエントリを表示します。
削除するエントリを選択し、「削除」アイコンをクリックします。
「エントリの削除」ダイアログで、適切なエントリを削除しようとしていることを確認し、「OK」をクリックします。
エントリと、ディレクトリ・ツリー内でその下にあるすべてのエントリを削除するには、次の手順を完了します:
第17.15.1項「エントリの表示」の説明に従って、既存のエントリを表示します。
削除するエントリを選択し、エントリとそのサブツリーの削除アイコンをクリックします。
「サブツリーの削除」ダイアログで、適切なエントリを削除しようとしていることを確認し、「OK」をクリックします。
ODSMデータ・ブラウザを使用してエントリのRDNを変更するには、次の手順を完了します:
第17.15.1項「エントリの表示」の説明に従って、既存のエントリを表示します。
新しいエントリの基にする、変更するRDNを持つエントリを選択し、「RDNの編集」アイコンをクリックします。
「新規RDN値」フィールドに新しいRDNを指定します。
古いRDNを形成していた値をエントリから削除する場合は、「古いRDNの削除」を選択します。このチェック・ボックスを選択しない場合、古いRDNを形成していた値は、そのエントリの非識別属性値として保持されます。
オプションで、「サブツリー・エントリのリフレッシュ」アイコンをクリックし、RDNの変更を確認します。
次のようにして、LDIFファイルからエントリをインポートできます:
第18.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「データ・ブラウザ」タブを選択します。
「ネットワーク・グループ」リストから適切なネットワーク・グループを選択します。
「LDIFのインポート」アイコンをクリックします。
「エントリのインポート」ダイアログで、「ファイルの選択」をクリックします。
システム上のLDIFファイルを見つけ、「OK」をクリックします。
「LDIFのインポート進行状況」ダイアログで、インポートの進行状況を監視し、インポートが完了したら、「OK」をクリックします。
データ・ブラウザ・ツリーがリフレッシュされ、新規エントリが表示されます。
次のようにして、ODSMを使用して、LDIFファイルにエントリをエクスポートできます:
ODSMデータ・ブラウザを使用してLDIFファイルにエントリをエクスポートするには、次の手順を完了します:
第17.15.1項「エントリの表示」の説明に従って、エントリを表示します。
エクスポートするサブツリーの最上位レベルの識別名にナビゲートし、「LDIFのエクスポート」アイコンをクリックします。
操作属性をエクスポートする場合は、「エントリのエクスポート」ダイアログで、「操作属性のエクスポート」を選択します。
「OK」をクリックします。
ここをクリックしてLDIFファイルを開きます。
ODSMが実行されているブラウザ・ウィンドウの個別タブに完全なLDIFファイルが表示されます。
書込み可能な場所にLDIFファイルを保存します。
「エントリのエクスポート」ダイアログで「OK」をクリックし、エクスポートを終了します。
