この章では、ディレクトリ・サーバーにおけるデータのインポート、エクスポート、追加、変更、削除および検索の方法について説明します。また、データに索引付けすることによって、より効率的に検索を実行する方法、エントリが一意であることを確認する方法、仮想属性など拡張データ機能を使用する方法についても説明します。
この章には次のセクションが含まれます:
ディレクトリ・サーバーは、特定のバックエンドとの間でデータをやり取りするいくつかのメカニズムを備えています。この章では、各種オプションの概要を示し、インポートおよびエクスポートのメカニズムについて詳しく説明します。
この項の内容は次のとおりです:
注意: ユーザー・エントリをインポートする場合、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ファイルから読み取ったデータまたは第18.1.4項「MakeLDIFテンプレート・ファイルの作成」に基づいて生成されたデータを、ディレクトリ・サーバー・バックエンドに移入します。多くの場合、import-ldif
のほうが、ldapmodify
を使用してエントリを追加するよりも大幅に高速です。
import-ldif
コマンドでは、LDIFファイルと圧縮済ファイル(.zip
)の両方がサポートされています。
インポート操作における次の局面に注意してください:
Oracle Berkeley DB Java Edition (JE)バックエンド全体への完全なインポートのほうが、JEバックエンドの分岐への部分インポートよりもパフォーマンスがよくなります。インポートするすべてのLDIFファイルで、UTF-8文字セット・エンコードを使用している必要があります。
接尾辞のインポートは、リソースに負荷のかかる操作です。多数の接尾辞を含むLDIFファイルをインポートする場合、そのインポート操作を完了するにはヒープ領域不足になることがあります。そのようなLDIFファイルをインポートする前に、ヒープを可能なかぎり増やしておく必要があります。詳細は、第36章「パフォーマンス・チューニング」および第18.2項「大規模データ・セットのインポート」を参照してください。
LDIFファイルをインポートするためにroot権限は必要ありませんが、cn=Directory Manager
などのroot権限を持つユーザーとして認証される必要があります。
次の項では、import-ldif
コマンドを使用してデータをインポートする方法について説明します:
import-ldif
の操作モードimport-ldif
コマンドには、操作にオンラインとオフラインの2つのモードがあります。
オンライン・モード。オンライン・モードでは、import-ldif
は、実行中のディレクトリ・サーバー・インスタンスにアクセスし、インポート・タスクを登録します。このコマンドは、管理コネクタを通してSSL経由でタスク・バックエンドにアクセスします。詳細は、第17.4項「サーバーへの管理トラフィックの管理」を参照してください。オンライン・モードは、いずれかの接続オプション(--hostname
、--port
、--bindDN
、--bindPasswordFile
など)が指定されている場合は自動的に実行されます。
注意: オンライン・インポートの場合でも、インポート中はバックエンドは使用できません。レプリケートされたトポロジでは、全体的なサービスは、依然としてreferral on update機能を通して使用可能です。詳細は、第18.14.1項「レプリケートされたトポロジでのリフェラル」を参照してください。一般的に、オンライン・インポートを実行する予定である場合は、サーバーを起動するときにヒープを増やす必要があります。詳細は、第36章「パフォーマンス・チューニング」を参照してください。 |
オフライン・モード 。接続オプションが指定されていない場合、このコマンドはオフライン・モードで実行されます。オフライン・モードでは、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
にあるテンプレート・ファイルを必要に応じて編集して使用できます。詳細は、第18.1.4項「MakeLDIFテンプレート・ファイルの作成」および付録A「make-ldif」を参照してください。
サーバーが実行中である場合は、それを停止します。
$ stop-ds
テンプレート・ファイルを使用して、データをインポートします。
このサンプル・テンプレートによって、指定したバックエンドに10,003個のサンプル・エントリが生成されます。
$ import-ldif --backendID userRoot --templateFile example.template \ --randomSeed 0
import-ldif
ユーティリティは、サーバーをオンラインにした状態で実行することもできます。オンライン・モードでは、このコマンドは、管理コネクタを通してSSL経由でタスク・バックエンドにアクセスします。オンライン・モードでこのコマンドを実行するには、SSL証明書の信頼方法など関連する接続オプションを指定する必要があります。この例では、-X
オプションを使用して、すべての証明書を信頼します。詳細は、第17.4項「サーバーへの管理トラフィックの管理」を参照してください。
適切な接続オプションを指定して、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
詳細は、第17.5項「タスクとしてのコマンドの構成」を参照してください。
export-ldif
を使用したデータのエクスポートexport-ldif
コマンドを使用して、ディレクトリ・サーバー・バックエンドからデータをエクスポートします。このコマンドは、次のタスクに有効です:
ディレクトリ・データのバックアップ
他のアプリケーションへのデータのエクスポート
ディレクトリ・トポロジへの変更後のデータベースへの移入
レプリケートされたトポロジでのマスター・サーバーの再初期化
注意: export-ldif コマンドを使用して、monitor 、ads-truststore 、backup およびconfig-file-handler のバックエンドからデータをエクスポートすることはできません。 |
次の項では、export-ldif
コマンドを使用してデータをエクスポートする方法について説明します:
export-ldif
の操作モードexport-ldif
コマンドには、操作にオンラインとオフラインの2つのモードがあります。
オンライン・モード。オンライン・モードでは、export-ldif
は、実行中のディレクトリ・サーバー・インスタンスにアクセスし、エクスポート・タスクを登録します。このモードは、LDAP接続オプション(--hostname
、--port
、--bindDN
、--bindPasswordFile
など)が使用されている場合は自動的に実行されます。このコマンドは、管理コネクタを通してSSL経由でタスク・バックエンドにアクセスします。詳細は、第17.4項「サーバーへの管理トラフィックの管理」を参照してください。
オフライン・モード 。接続オプションが指定されていない場合、このコマンドはオフライン・モードで実行されます。オフライン・モードでは、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経由でタスク・バックエンドにアクセスします。詳細は、第17.4項「サーバーへの管理トラフィックの管理」を参照してください。オンライン・モードでコマンドを実行するには、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経由でタスク・バックエンドにアクセスします。詳細は、第17.4項「サーバーへの管理トラフィックの管理」を参照してください。
エクスポート・タスクをスケジュールするには、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
クラスのサブクラスである必要があります。カスタム・タグの開発の詳細は、第18.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属性に対して同様の定義があります:
o
organization
オブジェクト・クラスのエントリを作成します。
ou
organizationalUnit
オブジェクト・クラスのエントリを作成します。
c
country
オブジェクト・クラスのエントリを作成します。
分岐エントリに対して、他のどのような種類のRDN属性も使用できます。前述の指定したもの以外のRDN属性を持つ分岐エントリについては、エントリはuntypedObject
およびextensibleObject
オブジェクト・クラスで作成されます。
前述の分岐定義によって、その分岐エントリの下に追加のエントリが作成されることはありません。これを行うには、1つ以上のsubordinateTemplate
行を指定する必要があります。例:
branch: ou=People,dc=example,dc=com subordinateTemplate: person:100
これにより、ou=People,dc=example,dc=com
エントリが作成され、person
テンプレートでモデル化された1000個の他のエントリがその下に作成されます。person
テンプレートは、テンプレート・ファイルで後で定義する必要があります。詳細は、第18.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
この追加のテキストは、静的にするか、任意の定義済グローバル置換変数を含めるか、またはテンプレート定義で使用できる置換タグのサブセットを含めることができます。使用可能なタグの概要、および分岐定義でどのタグが使用できるかに関する情報は、第18.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
が提供する柔軟性を示しています。テンプレート定義に含めることができるタグは、後続の項で説明します(第18.1.4.2.1項「標準置換タグ」および第18.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
テンプレート・ファイルで使用できる標準セットのタグについて説明します。第18.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
パッケージに含められています。それらは、カスタム・タグの実相に何が関与しているのかを把握するための参照に使用できます。
注意: カスタム・タグを定義する場合、それを必要とする可能性があるテンプレート・ファイルで使用できるようになっているいことを確認してください。これは、include 文を使用して実行され、それはテンプレート・ファイルの先頭に配置する必要があります。詳細は、第18.1.4.1.1項「カスタム・タグのインクルード」を参照してください。 |
この項では、ディレクトリ・サーバーに大きなデータ・セットをインポートする際のパフォーマンスの向上に関するヒントを示します。デフォルトでは、サーバーは、固定したセットのパラメータでデータをインポートします。デフォルトの動作を変更するには、次の2通りがあります:
import-ldif
コマンドを実行する際は、特定のオプションを指定します。
詳細は、第18.2.1項「インポート・オプションの設定」を参照してください。
import-ldif
コマンドを実行する前に、dsjavaproperties
コマンドを使用して、適切なJava引数を設定します。
詳細は、第18.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
注意: dsjavaproperties コマンドの実行またはOPENDS_JAVA_ARGS 環境変数の設定がパフォーマンスに影響を及ぼすのは、インポートがオフラインである場合のみです。サーバーがすでに実行中であり、オンライン・インポートを実行する場合、Java引数を変更しても、インポートのパフォーマンスに影響を与えることはありません。それは、インポートはサーバーJVMによって実行されるためです。 |
Oracle Unified Directoryは、様々なリポジトリ・タイプをサポートする拡張可能なフレームワークを提供します。ディレクトリ・サーバーは、そのプライマリ・バックエンドとしてBerkeley DB Java Edition (JE)を使用します。JEバックエンドには、他のデータベースと比較していくつかの利点があります。それは、それが、データ・セット(小さなものから非常に大きなものまで)に対して、ACIDセマンティクスに対する完全なサポートとともに、高性能かつスケーラブルなトランザクショナルBツリー・データベースを提供するためです。また、そのエントリを、エンコードされた形式で格納し、高速かつ効率的なデータ取得のための索引を提供することも可能です。
この項の内容は次のとおりです:
JEバックエンドにディレクトリ・データを保持するために、Oracle Unified Directoryは、全体バックアップおよび増分バックアップをサポートする効率的なバックアップおよびリストア・ユーティリティを備えています。全体バックアップでは、ディレクトリ・データ・ファイルが、圧縮済アーカイブ・ファイルとして環境に保存されます。増分バックアップでは、前回のバックアップ以降に書き込まれたファイルのみが、前回のバックアップ以降に変更されていないファイルの名前のリストとともに保存され圧縮されます。Oracle Unified Directoryでは、リストアを簡単にするためにバックアップ・バックエンドにそのバックアップ情報が格納されます。
ディレクトリ・サーバー・バックアップは、ローカル・ディスク上またはリモート・ディスク上で、たとえば、ネットワーク接続ストレージ(NAS)で実行できます。ローカルでバックアップを実行する場合、セキュリティ上の理由から、別のマシンまたはファイル・システムにバックアップをコピーして保存します。
データのバックアップとリストアを開始する前に、次の事項を考慮します:
ご使用のディレクトリ・サービス・システムに対して実行可能なバックアップおよびリストア戦略を設計する必要があります。たとえば、増分バックアップを毎日実行し、全体バックアップを少なくとも週に1回実行することができます。バックアップ・プロセスおよびリストア可能かどうかを定期的にテストしてください。データをリストアするために、多くの会社では、レプリケートされたサーバーからディレクトリ・サーバーをリストアし、それによって、ディレクトリ・データの最も更新されているコピーが使用されるようにしています。ディレクトリ・データが損傷し(たとえば、エントリが欠落し)、損傷したデータが他のサーバーにレプリケートされた場合には、バックアップ・テープが必要になります。
障害時リカバリ計画が策定済であることを確認します。障害時リカバリは、破局的なイベント、データ破損、またはデータの不正操作が発生した場合に必要です。企業は、独自の計画を策定するか、サード・パーティの専門家にその作業をアウトソーシングします。詳細は、第18.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
オプションは、サーバーによって定義されるすべての証明書を信頼することを指定します。詳細は、第17.4項「サーバーへの管理トラフィックの管理」を参照してください。
次のオプションを指定して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
ディレクトリ管理者およびシステム管理者は、自然障害、人為的障害、または破局的な障害が発生した場合の障害時リカバリ計画を策定しておく必要があります。ディレクトリ・サービスが複数の個別のサーバーに分散されている場合、すべてのサーバーを個別にバックアップするか、すべてのディレクトリ・データを中央からバックアップします。
かわりに、バックアップおよびリストア戦略としてレプリケーションを検討してください。レプリケーションは、別のレプリケートされたサーバーからのより高速なリストアおよびより更新されたデータを提供します。詳細は、第18.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
ユーティリティを使用することで、このスケジュール済タスクを表示できます。
詳細は、第17.5項「タスクとしてのコマンドの構成」を参照してください。
場合によっては、障害時リカバリ目的で、または他のイベントのために、別のサーバーに構成を転送するための構成ファイルをリストアする必要があります。一般に、サーバーがオンラインである場合、現在の構成ファイルは、最後にアーカイブした構成ファイルと同一です。ただし、前の日付のものから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つのエンティティ間の関係をテストする演算子を使用します。
次の表は、検索問合せにおいて特定のエントリを返すための検索フィルタの使用方法を示しています。
検索フィルタ | 演算子 | 説明 |
---|---|---|
プレゼンス | attr=* |
指定された属性と関連する値を持つすべてのエントリを返します。このフィルタでは、ワイルドカード文字を使用して、文字列内のゼロ個以上の文字を示します。たとえば、フィルタ(objectclass=\*) は、よく使用されるフィルタであり、すべてのエントリにある値を持つオブジェクト・クラスを含むすべてのエントリが返されます。
注意: LDAPプロトコルでは、フィルタは、引用符に囲まれたカッコも含めて"(filter)"の形式を持つと指定されています。大部分のディレクトリ・サーバーでは、カッコと引用符がないフィルタを受け入れますが、それらを含めることをお薦めします。 |
等価 | attr=value |
指定された値に等しい属性を含むエントリを返します。たとえば、(sn=Bergin) では、姓(sn )属性の値がBergin であるすべてのエントリが返されます。
注意: |
部分文字列 | attr=<initial-string><any substring> |
指定した部分文字列または部分的な部分文字列を含む属性を持つエントリが返されます。このフィルタでは、ワイルドカード文字を使用して、文字列内のゼロ個以上の文字を示します。
|
以上 | attr>=value |
指定された値以上の属性を含むエントリを返します。たとえば、(sn>=Bergin) は、属性の一致ルール(第10.1項「一致ルールの理解」を参照)に基づいて、値Bergin 以上の属性を持つすべてのエントリが返されます。 |
以下 | attr<=value |
指定された値以下の属性を含むエントリを返します。たとえば、(sn<=Bergin) は、属性の一致ルールに基づいて、値Bergin 以下の属性を持つすべてのエントリが返されます。 |
近似 | attr~=value |
検索フィルタに指定されている値にほぼ等しい値を持つ指定された属性を含むエントリを返します。たとえば、(sn~=Bergan) では、(sn=Bergin) または(sn=Bergan) に関連するエントリが返されます。近似検索フィルタは、英語の文字列でのみ機能します。JaやZnなど非ASCIIベース文字列では機能しません。 |
拡張可能一致 | attr= attr [":dn"] [":" matchingrule] ":=" value Or:[:dn] ":" matchingrule ":=" value |
指定した一致ルールで属性がその値に等しい場合、結果のエントリを返します。LDAPバージョン3では、特定の属性に対する一致演算子およびルールを作成できます。一致ルールによって、特定の構文と属性値を比較する方法が定義されます。つまり、拡張可能検索フィルタでは、一致ルールを検索フィルタに追加できます。たとえば、(sn:2.5.13.5:=Jensen) の検索フィルタでは、OID 2.5.13.5によって指定された一致ルールを使用することで、Jensen に等しい値を持つ姓属性を含むエントリが比較されます。もう1つの例の(sn:dn:2.5.13.5:=Jensen) は、比較を行うときにOID 2.5.13.5 を使用すること、および一致を評価するときにエントリの属性をエントリの一部と見なすことを示すための":dn" 表記の使用例を示します。 |
次のように演算子を使用することで、複数の検索フィルタ・コンポーネントを結合し、評価できます:
(Boolean-Operator(filter)(filter)(filter))
ブール演算子を結合し、ネストして、複合式を形成できます:
(Boolean-Operator(filter)(Boolean-operator(filter)(filter)))
次の表で、ブール演算子について説明します。
検索フィルタ | 演算子 | 説明 |
---|---|---|
AND | (&(filter)(filter)) |
文がtrueになるためには、指定されているすべてのフィルタがtrueである必要があります。たとえば、(&(sn=Carter)(l=Cupertino)) では、姓属性がCarterで、かつ位置属性がCupertino のエントリがあれば、それらがすべて返されます。 |
OR | (|(filter)(filter)) |
文がtrueになるためには、指定されているフィルタの少なくとも1つがtrueである必要があります。たとえば、(|(sn=Carter)(l=Cupertino)) では、姓属性がCarter であるか、位置属性がCupertino のエントリがあれば、それらがすべて返されます。 |
NOT | (!(filter)(filter)) |
文がtrueになるためには、指定されているフィルタがtrueでない必要があります。たとえば、(!(sn=Bergin)) では、姓属性が文字列Smith でないすべてのエントリが返されます。このフィルタでは、sn 属性を持たないすべてのエントリも返されます。 |
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オペレーティング・システムで、/usr/bin ディレクトリにldapsearch 、ldapmodify 、ldapdelete など一般的なLDAPクライアント・ツールのインストール済バージョンが提供されています。ディレクトリ・サーバーを検索するには、そのディレクトリ・サーバーで提供されているldapsearch を使用する必要があります。次のコマンドを入力することで、ldapsearch のどのバージョンを使用しているのかを調べることができます:
$ 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検索を実行するには、次のステップを完了します。
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「拡張検索」タブを選択します。
「ネットワーク・グループ」リストから適切なネットワーク・グループを選択します。
「ベース検索DN」フィールドで、検索の開始点となるDNを入力します。
「ベース検索DN」としてエントリを選択するには、「選択」をクリックします。
「エントリ・ピッカー」ウィンドウで、「ツリー・ビュー」を選択してディレクトリ・ツリーに移動し、対象のエントリを見つけるか、「検索ビュー」を選択して対象のエントリを検索します。
「範囲」リストから検索の範囲を選択します。LDAP検索範囲は、検索操作の一致候補と見なされる、ベースDNまたはその下にある一連のエントリを示します。範囲は、次のいずれかです:
ベース。検索操作は、検索ベースDNとして指定されたエントリに対してのみ実行されることを示します。その下には検討されるエントリはありません。
「1レベル」。検索操作は、検索ベースDNとして指定されたエントリの直下のエントリに対してのみ実行されることを示します。ベース・エントリ自体または検索ベース・エントリの直下より下位のエントリは含まれません。
サブツリー。検索操作は、検索ベースとして指定されたエントリ、および深さにかかわらず検索ベースの下位すべての指定されたエントリに対して実行されることを示します。
「フィルタ」フィールドで、有効なLDAP検索フィルタを入力します。
かわりに、「フィルタ・ビルダー」をクリックし、ODSMに必要な情報を入力し、LDAP検索フィルタを構築します。
LDAP検索フィルタの詳細は、第18.4.3.1項「フィルタのタイプと演算子の指定」を参照してください。
「検索結果サイズ」リストから、検索によって返されるエントリの数をODSMで制限する方法を選択します。
「制限設定」で、返されるエントリの正確な数を指定できます。
「仮想リスト・ビューの使用」によって、検索に仮想リスト表示索引を使用できます。詳細は、第18.5.3.16項「仮想リスト表示制御を使用した検索」を参照してください。
「ページングの使用」によって、一度に結果のサブセットのみを返すことを指定でき、各ページの結果の数を指定できます。詳細は、第18.5.3.15項「単純なページングの結果制御を使用した検索」を参照してください。
ディレクトリ・サーバーは、ldapsearch
コマンドを使用することでLDAPv3対応の検索機能をサポートしています。ご使用のシステム構成に基づいて、検索プロセスで特殊属性、セキュリティ、オプション、およびLDAP制御を使用できます。詳細は、第18.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経由でディレクトリ・サーバーに接続します。詳細は、第17.4項「サーバーへの管理トラフィックの管理」を参照してください。
対話モードでdsconfig
を使用して構成エントリを検索するには、次のようにコマンドを実行します:
$ dsconfig -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file
dsconfig
を使用したサーバー構成へのアクセスの詳細は、第17.1項「dsconfig
を使用したサーバー構成の管理」を参照してください。
ディレクトリ・サーバーのモニター・エントリcn=monitor
は、サーバー・パフォーマンス、状態およびバージョンに関する統計情報を提供します。この情報には、ldapsearch
コマンドを使用することでアクセスできます。
任意の構成済LDAP接続ハンドラを使用してcn=monitor
にアクセスできますが、管理接尾辞へのすべてのアクセスに管理コネクタを使用することをお薦めします。管理コネクタを使用すると、データのモニタリングが損なわれず、ユーザー・トラフィックよりもサーバー管理が優先されるようになります。管理コネクタを使用するには、管理ポートを指定し、--useSSL
オプションを含めます。詳細は、第17.4項「サーバーへの管理トラフィックの管理」を参照してください。
ベース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のリストとして返されます。
注意: これらの制御の一部はldapsearch コマンドで使用できません。それぞれに対応する制御の説明およびサポートされているLDAP制御の詳細は、付録B「サポートされているLDAP制御」を参照してください。 |
結合検索制御では、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
オプションとともに使用して、指定した属性に対する実効権限を含めることができます。このオプションを使用すると、エントリ内に現在存在しない属性を追加する権限をユーザーが持っているかどうかを判別できます。
注意: -J オプションとともに-g オプションを使用することはできません。 |
実効権限を表示するには、仮想属性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)
注意: -J managedsait 引数を指定しないと、このコマンドは、参照先のエントリを返します。 |
一致値フィルタ制御によって、クライアントは、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
オプションを使用します。
注意: -J または--control オプションは、検索リクエストでどの制御を使用するのかを指定するために使用します。--usePasswordPolicyControl オプションは、バインド・リクエストに使用されます。 |
--usePasswordPolicyControl
オプションを指定して、ldapsearch
コマンドを実行します。
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ -b dc=example,dc=com -s base --usePasswordPolicyControl "(objectclass=*)"
永続検索制御によって、クライアントは、追加、削除または変更操作によってディレクトリのエントリが変更されたときに、通知を受け取れます。変更が行われたときに、そのエントリが、エントリ変更通知制御によって使用された検索基準に一致する場合、サーバーによって更新済エントリがクライアントに送信されます。
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=*)"
注意: このコマンドを使用する場合、サーバーはadd 、delete 、modify またはall を使用して行われた変更を待って、値を返します。 |
別の端末ウィンドウを開き、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を使用することです:
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、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を削除して再作成する必要があります。詳細は、第28.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では、エントリと突き合せて、第18.5.3.14項「サーバー側ソート制御を使用した検索」のように使用して検索結果をソートする照合ルールがサポートされています。この照合ルールは、次に示すように、コロンで区切って、検索フィルタで一致ルールとして指定します:
locale.
matchingRule
ここで:
localeは、次のいずれかの方法で指定します。
ロケールOID
ロケール文字接尾辞(ar
、en
、fr-CA
など)。
サポートされているロケール、それらのOIDおよびタグのリストは、第18.5.5.2項「サポートされている照合ルール」を参照してください。
matchingRuleは、表18-1に示すように、ロケールに追加された数字接尾辞または文字接尾辞のいずれかとして指定できます。
注意: ロケールをそのOIDで指定する場合、一致ルールはその数字接尾辞で指定する必要があります。この場合、一致ルールを文字接尾辞で指定することはできません。 |
表18-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"
このセクションには次のトピックが含まれます:
例18-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"
例18-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"
例18-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"
例18-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"
例18-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によってサポートされている国際化ロケールを、文字接尾辞のアルファベット順に示しています。
表18-2 サポートされている照合ルール
ロケール | 文字接尾辞 | OID |
---|---|---|
アラビア語 |
ar |
1.3.6.1.4.1.42.2.27.9.4.3.1 |
アラビア語アラブ首長国連邦 |
ar-AE |
1.3.6.1.4.1.42.2.27.9.4.4.1 |
アラビア語バーレーン |
ar-BH |
1.3.6.1.4.1.42.2.27.9.4.5.1 |
アラビア語アルジェリア |
ar-DZ |
1.3.6.1.4.1.42.2.27.9.4.6.1 |
アラビア語エジプト |
ar-EG |
1.3.6.1.4.1.42.2.27.9.4.7.1 |
アラビア語インド |
ar-IQ |
1.3.6.1.4.1.42.2.27.9.4.9.1 |
アラビア語ヨルダン |
ar-JO |
1.3.6.1.4.1.42.2.27.9.4.10.1 |
アラビア語クウェート |
ar-KW |
1.3.6.1.4.1.42.2.27.9.4.11.1 |
アラビア語レバノン |
ar-LB |
1.3.6.1.4.1.42.2.27.9.4.12.1 |
アラビア語リビア |
ar-LY |
1.3.6.1.4.1.42.2.27.9.4.13.1 |
アラビア語モロッコ |
ar-MA |
1.3.6.1.4.1.42.2.27.9.4.14.1 |
アラビア語オマーン |
ar-OM |
1.3.6.1.4.1.42.2.27.9.4.15.1 |
アラビア語カタール |
ar-QA |
1.3.6.1.4.1.42.2.27.9.4.16.1 |
アラビア語サウジアラビア |
ar-SA |
1.3.6.1.4.1.42.2.27.9.4.17.1 |
アラビア語スーダン |
ar-SD |
1.3.6.1.4.1.42.2.27.9.4.18.1 |
アラビア語シリア |
ar-SY |
1.3.6.1.4.1.42.2.27.9.4.19.1 |
アラビア語チュニジア |
ar-TN |
1.3.6.1.4.1.42.2.27.9.4.20.1 |
アラビア語イエメン |
ar-YE |
1.3.6.1.4.1.42.2.27.9.4.21.1 |
ベラルーシ語 |
be |
1.3.6.1.4.1.42.2.27.9.4.22.1 |
ブルガリア語 |
bg |
1.3.6.1.4.1.42.2.27.9.4.23.1 |
カタロニア語 |
ca |
1.3.6.1.4.1.42.2.27.9.4.25.1 |
チェコ語 |
cs |
1.3.6.1.4.1.42.2.27.9.4.26.1 |
デンマーク語 |
da |
1.3.6.1.4.1.42.2.27.9.4.27.1 |
ドイツ語 |
de |
1.3.6.1.4.1.142.2.27.9.4.28.1 |
ドイツ語ドイツ |
de-DE |
1.3.6.1.4.1.142.2.27.9.4.28.1 |
ドイツ語オーストリー |
de-AT |
1.3.6.1.4.1.42.2.27.9.4.29.1 |
ドイツ語スイス |
de-CH |
1.3.6.1.4.1.42.2.27.9.4.31.1 |
ドイツ語ルクセンブルク |
de-LU |
1.3.6.1.4.1.42.2.27.9.4.32.1 |
ギリシャ語 |
el |
1.3.6.1.4.1.42.2.27.9.4.33.1 |
英語 |
en |
1.3.6.1.4.1.42.2.27.9.4.34.1 |
英語アメリカ合衆国 |
en-US |
1.3.6.1.4.1.42.2.27.9.4.34.1 |
英語オーストラリア |
en-AU |
1.3.6.1.4.1.42.2.27.9.4.35.1 |
英語カナダ |
en-CA |
1.3.6.1.4.1.42.2.27.9.4.36.1 |
英語イギリス |
en-GB |
1.3.6.1.4.1.42.2.27.9.4.37.1 |
英語アイルランド |
en-IE |
1.3.6.1.4.1.42.2.27.9.4.39.1 |
英語インド |
en-IN |
1.3.6.1.4.1.42.2.27.9.4.40.1 |
英語ニュージーランド |
en-NZ |
1.3.6.1.4.1.42.2.27.9.4.42.1 |
英語南アフリカ |
en-ZA |
1.3.6.1.4.1.42.2.27.9.4.46.1 |
スペイン語 |
es |
1.3.6.1.4.1.42.2.27.9.4.49.1 |
スペイン語スペイン |
es-ES |
1.3.6.1.4.1.42.2.27.9.4.49.1 |
スペイン語アルゼンチン |
es-AR |
1.3.6.1.4.1.42.2.27.9.4.50.1 |
スペイン語ボリビア |
es-BO |
1.3.6.1.4.1.42.2.27.9.4.51.1 |
スペイン語チリ |
es-CL |
1.3.6.1.4.1.42.2.27.9.4.52.1 |
スペイン語コロンビア |
es-CO |
1.3.6.1.4.1.42.2.27.9.4.53.1 |
スペイン語コスタリカ |
es-CR |
1.3.6.1.4.1.42.2.27.9.4.54.1 |
スペイン語ドミニカ共和国 |
es-DO |
1.3.6.1.4.1.42.2.27.9.4.55.1 |
スペイン語エクアドル |
es-EC |
1.3.6.1.4.1.42.2.27.9.4.56.1 |
スペイン語グアテマラ |
es-GT |
1.3.6.1.4.1.42.2.27.9.4.57.1 |
スペイン語ホンジュラス |
es-HN |
1.3.6.1.4.1.42.2.27.9.4.58.1 |
スペイン語メキシコ |
es-MX |
1.3.6.1.4.1.42.2.27.9.4.59.1 |
スペイン語ニカラグア |
es-NI |
1.3.6.1.4.1.42.2.27.9.4.60.1 |
スペイン語パナマ |
es-PA |
1.3.6.1.4.1.42.2.27.9.4.61.1 |
スペイン語ペルー |
es-PE |
1.3.6.1.4.1.42.2.27.9.4.62.1 |
スペイン語プエルトリコ |
es-PR |
1.3.6.1.4.1.42.2.27.9.4.63.1 |
スペイン語パラグアイ |
es-PY |
1.3.6.1.4.1.42.2.27.9.4.64.1 |
スペイン語サルバドル |
es-SV |
1.3.6.1.4.1.42.2.27.9.4.65.1 |
スペイン語ウルグアイ |
es-UY |
1.3.6.1.4.1.42.2.27.9.4.67.1 |
スペイン語ベネズエラ |
es-VE |
1.3.6.1.4.1.42.2.27.9.4.68.1 |
エストニア語 |
et |
1.3.6.1.4.1.42.2.27.9.4.69.1 |
フィンランド語 |
fi |
1.3.6.1.4.1.42.2.27.9.4.74.1 |
フランス語 |
fr |
1.3.6.1.4.1.42.2.27.9.4.76.1 |
フランス語 |
fr-FR |
1.3.6.1.4.1.42.2.27.9.4.76.1 |
フランス語 |
fr-BE |
1.3.6.1.4.1.42.2.27.9.4.77.1 |
フランス語 |
fr-CA |
1.3.6.1.4.1.42.2.27.9.4.78.1 |
フランス語 |
fr-CH |
1.3.6.1.4.1.42.2.27.9.4.79.1 |
フランス語 |
fr-LU |
1.3.6.1.4.1.42.2.27.9.4.80.1 |
ヘブライ語 |
he |
1.3.6.1.4.1.42.2.27.9.4.85.1 |
クロアチア語 |
hr |
1.3.6.1.4.1.42.2.27.9.4.87.1 |
ハンガリー語 |
hu |
1.3.6.1.4.1.42.2.27.9.4.88.1 |
アイスランド語 |
is |
1.3.6.1.4.1.42.2.27.9.4.91.1 |
イタリア語 |
it |
1.3.6.1.4.1.42.2.27.9.4.92.1 |
イタリア語スイス |
it-CH |
1.3.6.1.4.1.42.2.27.9.4.93.1 |
日本語 |
ja |
1.3.6.1.4.1.42.2.27.9.4.94.1 |
韓国語 |
ko |
1.3.6.1.4.1.42.2.27.9.4.97.1 |
リトアニア語 |
lt |
1.3.6.1.4.1.42.2.27.9.4.100.1 |
ラトビア語 |
lv |
1.3.6.1.4.1.42.2.27.9.4.101.1 |
マケドニア語 |
mk |
1.3.6.1.4.1.42.2.27.9.4.102.1 |
オランダ語 |
nl |
1.3.6.1.4.1.42.2.27.9.4.105.1 |
オランダ語オランダ |
nl-NL |
1.3.6.1.4.1.42.2.27.9.4.105.1 |
オランダ語ベルギー |
nl-BE |
1.3.6.1.4.1.42.2.27.9.4.106.1 |
ノルウェー語 |
no |
1.3.6.1.4.1.42.2.27.9.4.107.1 |
ノルウェー語ノルウェー |
no-NO |
1.3.6.1.4.1.42.2.27.9.4.107.1 |
ノルウェー語ニーノシュク |
no-NO-NY |
1.3.6.1.4.1.42.2.27.9.4.108.1 |
ポーランド語 |
pl |
1.3.6.1.4.1.42.2.27.9.4.114.1 |
ポルトガル語 |
pt |
1.3.6.1.4.1.42.2.27.9.4.115.1 |
ポルトガル語ポルトガル |
pt-PT |
1.3.6.1.4.1.42.2.27.9.4.115.1 |
ポルトガル語ブラジル |
pt-BR |
1.3.6.1.4.1.42.2.27.9.4.116.1 |
ルーマニア語 |
ro |
1.3.6.1.4.1.42.2.27.9.4.117.1 |
ロシア語 |
ru |
1.3.6.1.4.1.42.2.27.9.4.118.1 |
ロシア語ロシア |
ru-RU |
1.3.6.1.4.1.42.2.27.9.4.118.1 |
スロバキア語 |
sk |
1.3.6.1.4.1.42.2.27.9.4.121.1 |
スロベニア語 |
sl |
1.3.6.1.4.1.42.2.27.9.4.122.1 |
アルバニア語 |
sq |
1.3.6.1.4.1.42.2.27.9.4.127.1 |
セルビア語 |
sr |
1.3.6.1.4.1.42.2.27.9.4.128.1 |
スウェーデン語 |
sv |
1.3.6.1.4.1.42.2.27.9.4.129.1 |
スウェーデン語スウェーデン |
sv-SE |
1.3.6.1.4.1.42.2.27.9.4.129.1 |
タイ語 |
th |
1.3.6.1.4.1.42.2.27.9.4.136.1 |
トルコ語 |
tr |
1.3.6.1.4.1.42.2.27.9.4.140.1 |
ウクライナ語 |
uk |
1.3.6.1.4.1.42.2.27.9.4.141.1 |
ベトナム語 |
vi |
1.3.6.1.4.1.42.2.27.9.4.142.1 |
中国語 |
zh |
1.3.6.1.4.1.42.2.27.9.4.143.1 |
中国語中国 |
zh-CN |
1.3.6.1.4.1.42.2.27.9.4.144.1 |
中国語香港 |
zh-HK |
1.3.6.1.4.1.42.2.27.9.4.145.1 |
中国語台湾 |
zh-TW |
1.3.6.1.4.1.42.2.27.9.4.148.1 |
ディレクトリ・サーバーは、ディレクトリ・エントリを管理するためのLDAPv2およびLDAPv3準拠クライアント・ツールの完全なセットを備えています。ldapmodify
およびldapdelete
ユーティリティを使用することで、エントリを追加、更新または削除できます。LDAPコマンド行ユーティリティは、コマンド行から入力またはファイルから読み取られたLDAP Data Interchange Format (LDIF)形式の入力を必要とします。
ディレクトリ・データに変更を行う前に、次の概念を理解していることを確認します。
権限およびアクセス制御メカニズム。
権限の設定の詳細は、第28章「データへのアクセス制御」を参照してください。
ご使用のディレクトリ・サーバーの構造。
ご使用のディレクトリ・サーバーのスキーマ。
このセクションには次のトピックが含まれます:
ldapmodify
コマンドを使用して1つ以上のエントリをディレクトリ・サーバーに追加できます。ldapmodify
は、ディレクトリ・サーバーへの接続を開き、それにバインドし、コマンド行オプションによって指定されたとおりにデータベースに対する変更(この場合は「追加」)を実行します。
ldapmodify
では、次の2つの方法のいずれかでエントリを追加できます:
--defaultAddオプションの使用。コマンド行でデータを入力する場合は、--defaultAdd
オプションを使用して新しいエントリをディレクトリに追加します。終了したら、[Ctrl] + [D] (UNIX、Linux)または[Ctrl] + [Z] (Windows)を押すか、変更内容が含まれている入力ファイルを使用します。
LDIF更新文の使用。LDIF更新文は、ldapmodify
によってディレクトリ・エントリをどのように変更するのかを定義します。LDIF更新文には、変更するエントリのDN、特定のエントリをどのように変更するのか(add、delete、modify、modrdn)を定義するchangetype、および一連の属性とそれらの変更された値が含まれています。
注意: 新たに追加されたエントリはすべて、そのディレクトリのスキーマに準拠している必要があります。スキーマに準拠しないエントリを追加すると、サーバーはオブジェクト・クラス違反エラーで応答します。エラーの詳細は、errors ログで表示できます。 |
このセクションには次のトピックが含まれます:
ルート・エントリは、ディレクトリの最上位のエントリであり、ネーミング・コンテキストまたはルート接尾辞を含んでいる必要があります。ルート・エントリは、ディレクトリ・サーバーを最初にインストールするときに、グラフィカル・ユーザー・インタフェース(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
注意: --bindDN および--bindPassword オプションにより、新しいエントリを追加する権限を持つユーザーのバインドDNとパスワードをそれぞれ指定します。クリアテキスト・バージョンのパスワードを指定できます。サーバーではこの値を暗号化し、暗号化されたもののみを保存します。LDIFファイルに表示されるクリアテキストのパスワードを保護するため、読取り権限を制限してください。このセキュリティの問題を回避するには、SSLまたはstartTLSを使用してください。 |
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)を追加し、ユーザーのアカウントのアクセス権を管理できます。詳細は、第28章「データへのアクセス制御」および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
注意: --continueOnError オプションは、エラーが発生した場合にコマンドが次の検索アイテムで続行されることを指定します。 |
この項では、dsconfig
コマンド行ツールを使用して属性に索引付けする方法を説明します。索引は、サーバーごとに構成され、索引構成はレプリケートされません。
dsconfig
を使用して、ローカル・データベース索引および仮想リスト表示(VLV)索引を作成します。ローカル・データベース索引は、検索基準に一致するエントリを見つけるために使用されます。VLV索引は、VLV制御で効率的に検索を処理するために使用されます。
ユーザーにunindexed-search
権限がある場合以外は、索引付けされていない検索はデフォルトで拒否されます。詳細は、第29.3.5項「ルート・ユーザーの特権の変更」を参照してください。
次の2つの方法で、検索が索引付けされているかどうかを判別できます:
匿名で検索の実行を試みます。(サーバーは、デフォルトで、索引付けされていない匿名検索を拒否します。)
debugsearchindex
操作属性を使用します。この属性は、検索で使用される索引、各索引からの候補エントリの数、最終的な索引付けされたステータスを提供します。次のように、ldapsearch
コマンドにdebugsearchindex
属性を含めます:
$ ldapsearch -h localhost -p 1389 -b "dc=example,dc=com" "(objectClass=*)" debugsearchindex
この項では、データの索引付け方法を説明しており、内容は次のとおりです:
ローカルDBバックエンドでは、次の索引タイプがサポートされています:
approximate
: 近似検索フィルタを使用する検索の効率を高めます。
equality
: 等価検索フィルタを使用する検索の効率を高めます。
ordering
: 以上または以下の検索フィルタを使用する検索の効率を高めます。今後、この索引タイプは、サーバー側ソートにも使用される可能性があります。
presence
: プレゼンス検索フィルタを使用する検索の効率を高めます。
substring
: 部分文字列検索フィルタを使用する検索の効率を高めます。
ディレクトリ・サーバーでは、照合一致ルール、相対時間の一致ルール、部分的な日付や時刻の一致ルールなど拡張可能一致操作のサブセットに対してのみ索引付けがサポートされています。詳細は、第18.5.5項「国際化されたエントリの検索」、第10.1.3項「相対時間の一致ルール」および第10.1.4項「部分的な日付や時間の一致ルール」を参照してください。
dsconfig
で新しいローカルDBバックエンドを作成すると、次のデフォルト索引が自動的に作成されます:
aci
(プレゼンス索引)
ds-sync-hist
(順序付け索引)
entryuuid
(等価索引)
objectclass
(等価索引)
このセクションには次のトピックが含まれます:
これは、新規ローカルDB索引を作成するステップを示しています。
注意: 新しい索引を作成した後、rebuild-index ユーティリティを使用して索引を再構築する必要があります。ディレクトリ・サーバーは、索引が再構築されるまで新しい索引を使用できません。詳細は、付録A「rebuild-index」を参照してください。 |
新しい索引を作成します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ create-local-db-index \ --element-name backend --index-name attribute \ --set index-type:index-type
ローカルDB索引をそのバックエンドに対してリストすることで索引が作成されたことを確認します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
list-local-db-indexes \
--element-name backend
具体的な索引プロパティを構成します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-local-db-index-prop \ --element-name backend --index-name attribute \ --set property:value
索引プロパティをリストして変更を検証します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ get-local-db-index-prop \ --element-name backend --index-name attribute
索引を再構築します。
サーバーを停止し、索引を再構築して、サーバーを再起動します。
$ stop-ds $ rebuild-index --baseDN baseDN --index attribute $ start-ds
または、タスクとしてrebuild-indexコマンドを実行することで、オンラインで索引を再構築します。
$ rebuild-index -h localhost -p 4444 -D "cn=Directory manager" -j pwd-file \ -X -n --baseDN dc=example,dc=com --index aci Rebuild Index task 20110201162742312 scheduled to start immediately ... Rebuild Index task 20110201162742312 has been successfully completed
注意: オンラインの再索引付け操作の場合でも、再索引付け中はバックエンドは使用できません。レプリケートされたトポロジでは、全体的なサービスは、依然としてreferral on update機能を通して使用可能です。詳細は、第18.14.1項「レプリケートされたトポロジでのリフェラル」を参照してください。 |
例18-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
例18-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を変更する必要があります。詳細は、第18.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
例18-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
Oracle Unified Directoryサーバーは、少数の値を持ち、多数のエントリで多くの回数繰り返される属性を圧縮できます。サーバーは、トークンを使用してこれらの属性とその値を参照します。サーバーは、トークンとその値を一度個別の表に格納してから、トークンのみをデータベース・エントリに格納します。
この最適化により、本来は多くのデータベース・エントリにわたって属性値が繰り返される場合の領域が節約されます。これにより、本来はデータベース全体がメモリーに収まらない場合のキャッシュ効率も改善できます。
たとえば、すべての顧客(ユーザー)が使用する携帯電話の名前とモデルを格納するmobile-phone
ユーザー属性を持つ電話会社について考えてみます。電話会社のデータベース内の各ユーザー・エントリには、1つのmobile-phone
属性値(複数の値でない場合)があります。mobile-phone
が取得できる値のセットは限られており、最も一般的なmobile-phone
の値は、データベース内のユーザーにわたって数千回(場合によっては数百万回)繰り返されます。
ただし、この最適化を使用する場合、Oracle Unified Directoryサーバーはトークンを使用してmobile-phone
属性値を格納します。サーバーは、トークンおよび属性値を一度だけ個別の表に格納してから、トークンをデータベース・エントリに格納します。
トークンを使用して圧縮する必要がある属性のリストを構成するには、DBローカル・バックエンド・ワークフロー要素の複数値ds-cfg-compact-attribute-values-using-tokens
プロパティを設定します。例:
$ dsconfig set-workflow-element-prop \ --element-name userRoot \ --set compact-attribute-values-using-tokens:mobile-phone \ --hostname host --port admim-port \ --trustStorePath INSTALL_PATH/asinst_1/OUD/config/admin-truststore \ --bindDN "cn=Directory Manager" \ --bindPasswordFile ****** --no-prompt
このプロパティを設定した後、変更は、変更後に発生する書込みに対してのみ有効になります。既存のデータがさかのぼって変更されることはありません。
構成前から存在する属性の既存のデータをds-cfg-compact-attribute-values-using-tokens
プロパティを使用して圧縮するには、データをエクスポートしてから再インポートします(ただし、属性のトークンを使用することで達成されるパフォーマンスに照らしてこの操作のコストを考慮する必要があります)。
ds-cfg-compact-attribute-values-using-tokens
プロパティを使用して属性を圧縮した後、dbtest
コマンドで、値を格納するためにデータベースで作成されたトークンの合計数を表示します。例:
$ dbtest list-database-containers -n userRoot Database Name Database Type JE Database Name Entry Count --------------------------------------------------------------------------------- Schema maps compressed_object_classes 8 compressed_attributes 32 compressed_values 14 ...
compressed_values
行は、このデプロイメントで、14の値がトークンとしてエンコードされ、多数の値のエンコードに再利用できることを示します。dbtest
を使用して、この機能が正しく構成されており、トークンの数が多くなりすぎていないかをチェックできます。
この項では、選択的属性キャッシングを使用して大規模なデプロイメントのメモリー要件を削減し、大きいエントリを使用する場合のパフォーマンスを改善する方法について説明します。
内容は次のとおりです。
Oracle Unified Directoryは、読取りまたは書込み操作のLDAPエントリ全体に対してI/Oおよびデータベース・キャッシングを実行します。ただし、大部分の読取りおよび書込み操作は特定の属性のみを対象としており、データベースに格納されている他の属性にアクセスすることはほとんどありません。大規模なデプロイメントや大きいエントリの場合、この動作がメモリーおよびパフォーマンスに影響することがあります。
選択的属性キャッシングを使用すると、アクセス頻度に基づいてLDAPエントリ内の属性を区別することによって、これらの操作をより適切に管理できます。
通常属性: アクセス頻度が高い属性。たとえば、事務所の電話番号、ユーザーID、電子メール・アドレスなどです。
コールド属性: アクセス頻度が低い属性。たとえば、ページャ番号、自宅の電話番号、jpegフォトなどのバイナリ・データです。
操作要求のみに機能する、または特定のユースケースに適したコールド属性を構成できます。
注意: コールド属性を効果的に指定するには、使用するアプリケーションについて熟知している必要があります。 |
通常属性とコールド属性は各種のLDAPアプリケーション・ワークロードで異なる場合があることに注意してください。たとえば、デプロイメントで従業員のページャ番号や自宅の電話番号にアクセスする頻度が低い場合は、それらの属性をコールド属性として構成できます。ただし、別の顧客のデプロイメントで従業員のページャ番号や電話番号に頻繁にアクセスする場合、それらの属性をコールドとして構成することは不適切です。
注意: コールドとして構成できる属性に制限はありませんが、(次のような)各種のコア・サーバー機能で使用される属性をコールドに指定した場合、選択的属性キャッシングの利点が損なわれ、一部のコア・サーバー機能で予想外の動作が発生する可能性があります。
これらのコア・サーバー属性をコールドに指定することはサポートされていません。 |
コールド属性を指定すると、サーバーはLDAPエントリ・ストアをid2entry
とid2entry-cold
の2つのデータベースに分割します。サーバーは通常属性を通常のid2entry
データベースに格納し、コールド属性をid2entry-cold
データベースに格納します。
2つのデータベースを使用した場合、部分エントリ・データに関する操作のI/Oが削減され、javaヒープ、データベース・キャッシュおよびファイル・システム(FS)キャッシュのメモリー・フットプリントが削減されます。たとえば、LDAPエントリ・ストアに次の属性が含まれているとします。
dn: uid=user.0,ou=People,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson givenName: Aaccf sn: Amar cn: Aaccf Amar employeeNumber: 0 uid: user.0 mail: user.0@example.com userPassword: password telephoneNumber: +1 024 705 1954 homePhone: +1 021 391 6930 mobile: +1 195 481 7233 initials: AFA street: 77569 Lake Street l: Elmira st: ND postalCode: 31858 postalAddress: Aaccf Amar$77569 Lake Street$Elmira, ND 31858 description: This is the description for Aaccf Amar. pager: +1 575 339 1600
属性を次のように構成および格納することを決定できます。
id2entryデータベース | id2entry-coldデータベース |
---|---|
dn: uid=user.0,ou=People,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson givenName: Aaccf sn: Amar cn: Aaccf Amar employeeNumber: 0 uid: user.0 mail: user.0@example.com userPassword: password telephoneNumber: +1 024 705 1954 homePhone: +1 021 391 6930 mobile: +1 195 481 7233 |
initials: AFA street: 77569 Lake Street l: Elmira st: ND postalCode: 31858 postalAddress: Aaccf Amar$77569 Lake Street$Elmira, ND 31858 description: This is the description for Aaccf Amar. pager: +1 575 339 1600 |
Oracle Unified Directoryは、属性へのアクセスが行われ、通常属性のキャッシュの優先度がコールド属性より高い場合にのみ、id2entry-cold
データベースから属性をキャッシュします。その結果、コールド属性を対象としない操作はキャッシュに入る可能性が高くなります。
また、書込み操作がコールド属性を対象としていない場合、それらの操作はid2entry-coldデータベースをリライトする必要がないため、特に大きい属性がコールド属性として宣言された場合、操作が高速になります。
注意: 選択的属性キャッシングでは、DBキャッシュに完全に収まるデータベースの検索パフォーマンスは向上しない可能性があります。ただし、選択的属性キャッシングを使用すると、データベースがメモリーに完全には収まらない場合に、最も一般的に使用される属性のキャッシュ・ヒットを増やすことができます。 |
属性レベルのキャッシングはDBキャッシュに関連するため、構成はバックエンド構成エントリに保持されます。
DBローカル・バックエンド・ワークフロー要素でコールド属性を構成するには、複数値ds-cfg-cold-attribute
プロパティを使用してデータベースにコールド属性の名前を指定します。
注意: 任意の属性をコールド属性に指定できますが、操作処理のためにサーバーが依存している属性(ACI、パスワード・ポリシー、他の前述のコア・サーバー機能など)を指定することは避ける必要があります。 |
次に例を示します。
dsconfig set-workflow-element-prop \ --element-name userRoot \ --add cold-attribute:description \ --add cold-attribute:initials \ --add cold-attribute:l \ --add cold-attribute:pager \ --add cold-attribute:postalAddress \ --add cold-attribute:postalCode \ --add cold-attribute:st \ --add cold-attribute:street \
このdsconfig
コマンドを実行した後、(dsconfig
によって表示される) userRoot
ワークフロー要素のプロパティは次のようになります。
Property : Value(s) -----------------------------:------------------------------- 1) base-dn : "dc=example,dc=com" 2) cold-attribute : description, initials, l, pager, postalAddress, postalCode,st, street ...
dsconfig
コマンドを実行した後、cn=config
の下のuserRoot
ワークフロー要素のエントリは次のようになります。
dn : cn=userRoot,cn=Workflow Elements,cn=config objectClass : ds-cfg-local-backend-workflow-element objectClass : ds-cfg-workflow-element objectClass : ds-cfg-db-local-backend-workflow-element objectClass : top ... ds-cfg-cold-attribute : description ds-cfg-cold-attribute : pager ds-cfg-cold-attribute : postalCode ds-cfg-cold-attribute : postalAddress ds-cfg-cold-attribute : st ds-cfg-cold-attribute : l ds-cfg-cold-attribute : street ds-cfg-cold-attribute : initials
注意: コールド属性を定義する場合、サーバーは既存のデータをコールド・データベースに移動しません。新しいエントリを追加した場合や既存のエントリを変更した場合にのみ、サーバーはコールド・データベースへのコールド属性の格納を開始します。コールド属性を定義した後にデータの新規インポートを実行することが理想的です。 |
制限
コールド属性を使用する場合、次の制限が適用されます。
前述のように、コア・サーバー機能(アクセス制御命令(ACI)、仮想ACI、パスワード・ポリシー属性、グループなど)で使用される属性をコールドに指定した場合、選択的属性キャッシングの利点が損なわれ、一部のコア・サーバー機能で予期しない動作が発生する可能性があります。これらの属性をコールドに指定することはサポートされていません。
Oracle Unified Directoryは、コールド属性を含むエントリをエントリ・キャッシュにキャッシュできません。属性レベルのキャッシングは、デプロイメントがメモリーによって制約され、メモリーで非常にコストが高いためエントリ・キャッシュ使用できない場合に役立ちます。
Oracle Unified Directoryには、サーバーがコールド属性にアクセスするたびに追跡するコールド属性使用方法モニターが用意されています。
このモニターはパフォーマンスへの影響を防ぐためにデフォルトで無効になっていますが、ds-cfg-monitor-cold-attributes
バックエンド構成プロパティを使用して、診断のために有効にできます。
コールド属性を構成した後、モニターを有効にし、特定のアプリケーション・ワークロードを使用してサーバーを実行できます。モニターによって、サーバーがアクセスしたコールド属性およびアクセスした回数が記録されます。このデータを使用してコールド属性の構成を改良できます。たとえば、モニタリングによりコールド属性が多くの回数アクセスされていることが示される場合は、その属性を通常属性として再構成することを検討する可能性もあります。
次のサンプル出力では、description
は9回アクセスされ、それ以外のすべてのコールド属性は3回アクセスされていることがわかります。
ディレクトリの構造では、識別名によって、ディレクトリ情報ツリー内のオブジェクトおよびその場所が一意に識別される必要があります。ディレクトリ・サーバーは、一意属性プラグインを備えており、それによって、属性がディレクトリ内で追加、変更または移動された場合に、属性値の一意性が確保されます。
この項の内容は次のとおりです:
一意属性プラグインは、デフォルトで無効化されています。このプラグインは、dsconfig
コマンドを使用することで有効化でき、それによってチェックされる接尾辞および属性を定義できます。このプラグインは、有効化されている場合、操作によってデータベースが更新される前に、LDAP追加、変更またはDN変更操作によって、2つのエントリが同じ属性を持つようになるかどうかを識別します。サーバーによって競合が認識された場合、操作は終了され、LDAP_CONSTRAINT_VIOLATION
エラーがクライアントに返されます。
既存のディレクトリで属性値の一意性を有効にしても、サーバーは既存のエントリ間での一意性をチェックしません。プラグインが有効化された後は、エントリが追加、変更または移動されるときに一意性が強制されます。
一意の属性プラグインを構成し、ディレクトリ内の1つ以上のサブツリーや、特定のオブジェクト・クラスのエントリ間で、一意性を確保できます。他の属性の一意性を確保する場合、一意属性プラグインのインスタンスをいくつか定義できます。通常、値を一意にする属性ごとに、1つのプラグイン・インスタンスを定義します。同じ属性に複数のプラグイン・インスタンスを用意することで、複数のエントリ・セットでその属性の一意性を個別に確保できます。
一意属性プラグインはデフォルトでは無効化されており、マルチマスターのレプリケーション構成が影響を受けることはありません。プラグインが有効化されていると、スタンドアロン・システムの場合は追加、変更またはDN変更操作の前にuid
属性が一意であることが確認され、レプリケートされた環境では同期の後に一意性がチェックされます。
一意属性プラグインは、他のプラグインと同様に、dsconfig
コマンドを使用して構成されます。詳細は、第17.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
注意: --advanced サブコマンドを指定して、dsconfig コマンドを必ず実行してください。このサブコマンドにより、postaddoperation 、postmodifyoperation およびpostmodifydnoperation などの選択可能な拡張プラグインを表示するように表示出力が変更されます。デフォルト値は、preaddoperation 、premodifyoperation およびpostmodifyoperation などの操作前プラグインです。操作後プラグインと一致する操作前プラグインを選択する必要があります。 |
ベース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では次の仮想属性タイプをサポートしています:
表18-3 サポートされている仮想属性
仮想属性名 | 説明 |
---|---|
|
エントリに影響するすべての集合属性サブエントリを指定する仮想属性を生成します。 |
|
エントリのDNの正規化された形式を含むentryDN操作属性をディレクトリ・エントリ内に生成します。 |
|
プライベート・バックエンドに含まれるすべてのエントリにentryUUID操作属性の値があることを確認します。 |
|
エントリで有効なスキーマ定義を使用してDIT構造ルールを指定します。 |
|
エントリに下位エントリがあるかどうかを示します。 |
|
ユーザーがメンバーであるグループのDNが含まれます。 |
|
メンバー、または値が指定された仮想静的グループのメンバーのDNであるuniqueMember属性を生成します。 |
|
LDAPデータベースとしてOracle Directory Server Enterprise Editionを使用するレガシー・アプリケーションからOracle Unified Directoryへの移行の間の名前の競合を解決するために、ディレクトリ・サーバーの各エントリに割り当てられる一意の識別子を生成します。 |
|
エントリの下に存在する直接の子エントリの数を指定します。 |
|
orclguid仮想属性を作成します。 |
|
経過後にユーザーのパスワードが期限切れになる正確な時間を示します。
|
|
エントリで有効なパスワード・ポリシー・サブエントリを指します。 |
|
位置ベースの近接性をメートルで指定します。 |
|
エントリで有効なスキーマ定義を使用して構造オブジェクト・クラスを指定します。 |
|
エントリで有効なスキーマ定義を使用してsubschemaSubentryの場所を指定します。 |
|
プラグインの構成で定義されている基準と一致するエントリ内のユーザー定義値を使用して、仮想属性を作成します。 |
仮想属性を構成するには、次の項で説明するように、dsconfig
コマンドを使用するか、またはODSMグラフィカル・ユーザー・インタフェースを使用します。
dsconfig
を使用した仮想属性の構成仮想属性を構成する最も簡単な方法は、対話モードでdsconfig
を使用することです。対話モードは、ウィザードのように機能し、仮想属性構成を手順を追ってガイドします。対話モードは説明不要であるため、この項の例では、対話モードを例示せず、同等の完全なdsconfig
コマンドについて説明します。
dsconfig
の使用の詳細は、第17.1項「dsconfig
を使用したサーバー構成の管理」を参照してください。
この項では、dsconfig
コマンドを使用して仮想属性を構成および管理する方法を説明します。
このセクションには次のトピックが含まれます:
dsconfig
を使用した既存の仮想属性のリストディレクトリ・サーバーは、デフォルトでいくつかの仮想属性ルールを提供します。
構成されているすべての仮想属性ルールのリストを表示するには、次のdsconfig
コマンドを実行します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n list-virtual-attributes
例18-11に、次の情報を含む(左から右へ)このコマンドのサンプル出力を示します。
Virtual Attribute
。通常それが何を行うかを説明する、仮想属性の名前を表示します。
Type
。仮想属性のタイプを表示します。特定のタイプの仮想属性を複数定義することができます。
enabled
。仮想属性が有効化されているか無効化されているかを示します。無効化された仮想属性はサーバー構成内に保持されますが、それらの値は生成されません。
attribute-type
。仮想属性が生成される属性のタイプを表示します。
例18-11 構成されているすべての仮想属性ルールのリスト
Virtual Attribute : Type : enabled : attribute-type --------------------------------:---------------------------------:---------:---------------- Collective Attribute Subentries : collective-attribute-subentries : true : collectiveattributesubentries entryDN : entry-dn : true : entrydn entryUUID : entry-uuid : true : entryuuid governingStructureRule : governing-structure-rule : true : governingstructurerule hasSubordinates : has-subordinates : true : hassubordinates isMemberOf : is-member-of : true : ismemberof nsuniqueid : nsuniqueid : true : nsuniqueid numSubordinates : num-subordinates : true : numsubordinates orclguid : orclguid : true : orclguid Password Expiration Time : password-expiration-time : true : passwordexpirationtime Password Policy Subentry : password-policy-subentry : true : pwdpolicysubentry Proximity : proximity : true : proximity structuralObjectClass : structural-object-class : true : structuralobjectclass subschemaSubentry : subschema-subentry : true : subschemasubentry Virtual Static member : member : true : member Virtual Static uniqueMember : member : true : uniquemember
dsconfig
を使用した新規仮想属性の作成新規仮想属性を作成するには、create-virtual-attribute
サブコマンドを使用します。
たとえば、次のdsconfig
コマンドを実行して、位置がシドニーのユーザー・エントリに仮装FAX番号の+61 2 45607890
を追加する(彼らが自身のエントリにすでにFAX番号を持っていない場合)仮想属性ルールを作成し、有効化できます。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ create-virtual-attribute \ --type user-defined --name "Sydney Fax Number" \ --set attribute-type:facsimiletelephonenumber --set enabled:true \ --set value:+61245607890 --set filter:"(&(objectClass=person)(l=Sydney))"
dsconfig
を使用した仮想属性の有効化または無効化仮想属性を有効化するには、enabled
プロパティをtrue
に設定します。仮想属性を無効化するには、enabled
プロパティをfalse
に設定します。
たとえば、次のコマンドを実行して、前の例で作成した仮想属性を無効化します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ set-virtual-attribute-prop --name="Sydney Fax Number" --set enabled:false
dsconfig
を使用した仮想属性の構成の表示仮想属性の構成を表示するには、get-*-prop
サブコマンドを使用します。
たとえば、次のコマンドを実行して、第18.11.2.2項で作成した仮想属性のプロパティのリストを表示します。
$ 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 -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
この項では、ODSMの「構成」タブを使用して仮想属性を表示および作成する方法を説明します。
このセクションには次のトピックが含まれます:
ODSMを使用して既存の仮想属性のリストを表示するには、次のようにします。
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「構成」タブを選択します。
「一般構成」ノードを開きます。
「仮想属性」ノード内の属性を開き、既存の仮想属性をすべて表示します。
仮想属性名をクリックすると、右側のペインにその属性に関する詳細情報が表示されます。
仮想属性を作成するには、次のようにします。
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「構成」タブを選択します。
「作成」メニューから、「仮想属性」を選択します。
「名前」フィールドに、仮想属性の名前を入力します。
「有効」ボックスはデフォルトで選択されており、仮想属性が有効化されることを示します。
この仮想属性を後で無効化するには、このページに戻り、ボックスの選択を解除します。
「仮想属性タイプ」リストから、作成する仮想属性のタイプを選択します。
「属性のタイプ」選択メニューを使用して、仮想属性によって値が動的に割り当てられる属性の属性タイプを指定します。
「追加」アイコンをクリックし、この仮想属性の使用に適したエントリが含まれている分岐のベースDNを入力します。
次のいずれかを実行してベースDNを入力します:
「ベースDN」フィールドで、目的のベースDNを入力します。
「選択」をクリックし、ツリー・ビューまたは検索ビューを使用してエントリを選択します。
「追加」アイコンをクリックし、この仮想属性の使用に適したメンバーを持つグループのDNを入力します。
次のいずれかを実行して、グループのDNを指定します:
「グループDN」フィールドで、目的のグループDNを入力します。
「選択」をクリックし、ツリー・ビューまたは検索ビューを使用してエントリを選択します。
「追加」アイコンをクリックし、それらのエントリに対して仮想属性を生成する必要があるかどうかを判別するためにそれらのエントリに対して適用される検索フィルタを指定します。
ユーザー定義仮想属性の場合のみ、次の追加プロパティを構成します。
競合動作: 関連する属性に対してすでに1つ以上の実際の値が含まれているエントリに対してサーバーが提示する必要がある動作を指定します。次の値があります:
実際の値と仮想値をマージ: 仮想属性プロバイダが、エントリに含まれている実際の値をすべて保持し、それらを、生成された仮想値のセットとマージして、実際の値と仮想値の両方が使用されるようにすることを示します。
実際の値が仮想値をオーバーライド: エントリに含まれている実際の値をすべて保持して使用し、仮想値を生成しないことを示します。
仮想値が実際の値をオーバーライド: 仮想属性プロバイダが、エントリに含まれている実際の値をすべて抑止し、仮想値を生成して使用することを示します。
値: 仮想属性に含める値を指定します。
メンバー仮想属性の場合のみ、次の追加プロパティを構成します。
競合動作: これは、ユーザー定義仮想属性に似ています。
メンバーシップの取得を許可: 仮想属性のすべての値を要求するリクエストを処理するかどうかを示します。デフォルト値はfalse
です。
「作成」をクリックします。
仮想属性の構成設定を表示するには、次のようにします。
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「構成」タブを選択します。
「コア構成」アイコンをクリックします。
「仮想属性」リストを展開し、構成設定を表示する仮想属性を選択します。
構成設定は右側に表示されます。
仮想属性の構成設定を変更するには、次のようにします。
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「構成」タブを選択します。
「コア構成」アイコンをクリックします。
「仮想属性」リストを展開し、編集する仮想属性を選択します。
属性の構成ページが右側に表示されたら、必要に応じて設定を変更します。
必要に応じて、第18.11.2.2項「ODSMを使用した仮想属性の作成」で説明した構成の手順を参照してください。
「適用」をクリックします。
仮想属性を有効化または無効化するには、属性の構成ページを開き(第18.11.2.4項を参照)、「有効」ボックスを使用します。
仮想属性を有効化するには、ボックスを選択します。
仮想属性を無効化するには、ボックスの選択を解除します。
LDAPサブエントリは、サーバーの操作データを保持し、ldapSubEntry
オブジェクト・クラスを持つ特別なエントリです。それらは、サブエントリ制御リクエスト制御を含めることで明示的にリクエストされない場合は、クライアントに返されない点で、操作属性に似ています。
LDAPサブエントリは、エントリの範囲を指定するために使用できます。この機能は、集合属性の定義で使用され、アクセス制御などの他の分野でも便利です。詳細は、第18.13項「集合属性の使用方法」および第30.6.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
に設定します。
データ・インポートまたは再索引付けの処理中などなんらかの理由で、バックエンドが使用できません。
クライアント・リクエストが明示的にスマート・リフェラルをターゲットにしています。詳細は、第18.14.3項「スマート・リフェラル」を参照してください。
リフェラルURLは、ホスト名、ポート番号、および必要に応じてローカル・ホストまたは別のサーバーのDNを含むLDAP URLです。詳細は、第18.14.4項「LDAP URL」を参照してください。
使用可能な場合は、サーバーから結果コードREFERRAL (10)
がリフェラルURLのリストとともに返されます。使用可能なリフェラルURLがない場合は、サーバーから結果コードUNAVAILABLE (52)
が返されます。
リフェラルURLは次の2つの方法で作成できます:
レプリケートされたサーバーの場合は、レプリケーション・サービスを使用してリストを伝播します。詳細は、第18.14.1項「レプリケートされたトポロジでのリフェラル」を参照してください。
DBローカル・バックエンド・ワークフロー要素のds-cfg-referrals-url
プロパティを設定することで、リストを手動で作成します。詳細は、第18.14.2項「リフェラル・リストの手動による構成」を参照してください。
レプリケーション・サービスによって、リクエストをリダイレクトできるリフェラルURLのリストが生成されます。このリストは、各ローカル・サーバーで構成されているLDAP/LDAPS接続ハンドラに対応しています。LDAP/LDAPS接続ハンドラ以外の値を公開するには、独自のリフェラルURLを、ローカル・サーバー上のレプリケーション・ドメインのreferrals-url
プロパティの値として定義します。
クライアント・リクエストが、使用できないレプリケートされたサーバーをターゲットとしている場合は、サーバーから、リクエストをリダイレクトできるリフェラルURLのリストが送信されます。
リフェラルURLのリストは、リクエストに使用されたプロトコルに従って編成されます。たとえば、その操作がLDAPS経由で実行された場合、提供される最初のURLは、同じセキュアなプロトコル(LDAPS)を使用するものになります。
さらに、リストはグループIDによって編成されます。同じレプリケーション・グループ内のサーバーを表すURLは、最初に提示されます。URLのリストは、プロトコル・タイプ(LDAP/LDAPS)ごとに16個までのURLに制限されており、信頼されないサーバーは除外されます。
セキュリティ上の理由から、レプリケーション・サービスによって伝播されるリテラルは、信頼されないサーバーに対しては返されません。信頼されないサーバーが、トポロジの残りのものに関する情報を漏えいしないようにします。クライアント・リクエストが、信頼されないサーバーをターゲットとしている場合は、リフェラルURLのリストには、ローカル・バックエンド上の管理者によって管理されているサーバーのみが含まれるようになります。さらに、レプリケーション・サービスによって提供されるリフェラルURLでは、トポロジ内の信頼されないサーバーは除外されます。
レプリケーション・ドメインのpublish-referrals
構成プロパティがfalseに設定されている場合は、レプリケーション・サービスによって生成されるリフェラルのリストにそのサーバーは含まれなくなります。
レプリケーション・サービスによって提示されるリフェラル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
アップグレードの直前にcompact-encodingフラグの値をfalseに設定しておくと、11.1.2.2.0から11.1.2.3.0へのアップグレード後に大文字と小文字の区別がある値を保持できます。
Oracle Unified Directory (OUD)にエントリを作成するときには、次の例に示すように属性に値を指定する必要があります。dn (ドメイン名)属性には、cn (共通名)、uid (一意識別子)または他の属性がdnの一部として含まれる場合があります。次の例では、cnおよびdnの値の大文字と小文字の区別が等しくなっています。指定された属性の値および大文字と小文字が等しい場合は、11.1.2.2.0から11.1.2.3.0にアップグレードした後も大文字と小文字の区別は失われません。
dn: cn=john.doe1,ou=people,dc=example,dc=com givenName: John mail: john.doe1@example.com userPassword: password cn: john.doe1
次の表は、compact-encodingフラグ値に関して、大文字と小文字が区別されるデータのデフォルト動作について説明しています。
compact-encodingフラグをFalseに設定した場合 | compact-encodingフラグをTrueに設定した場合 |
---|---|
11.1.2.2.0では、compact-encodingフラグをfalseに設定すると、cn属性に指定された値が保持されます。
dn: cn=john.doe1,ou=people,dc=example,dc=com givenName: John mail: john.doe1@example.com userPassword: password cn: John.Doe1 sn: doe1 前述の詳細が設定されたユーザー作成しようとすると、作成されるユーザー・エントリには、入力に指定されたcn属性値と同じ値が設定されます。 |
11.1.2.3.0では、デフォルトでこのフラグがtrueに設定され、cn属性に明示的に指定された値に関係なく、dnに指定されたcn属性値が有効になります。
cn属性の値を別途指定しないと、OUDでは、dnに指定されたcn属性値がやはり有効になります。 dn: cn=john.doe1,ou=people,dc=example,dc=com givenName: John mail: john.doe1@example.com userPassword: password cn: john.doe1 sn: doe1 前述の詳細が設定されたユーザー作成しようとすると、OUDでは、dnに指定されたcn属性値でエントリが作成されます。 |
11.1.2.2.0では、dnとは異なるcnまたはuidの値を指定可能で、Oracle Unified Directoryでは、dnにある値とは関係なく、指定された値が有効になります。これが、compact-encoding機能が存在しない場合のデフォルトの動作です。
11.1.2.2.0では、dnとは異なるcnまたはuidの値を指定可能で、Oracle Unified Directoryでは、dnにある値とは関係なく、指定された値が有効になります。これが、compact-encoding機能が存在しない場合のデフォルトの動作です。
dn: uid=john.doe1,ou=people,dc=example,dc=com givenName: John mail: john.doe1@example.com userPassword: password uid: John.Doe1
属性がdnの一部として存在する場合は、大文字と小文字が区別される値が保持されます。たとえば、dnにuid属性が含まれる場合に、uid値が明示的に指定されていない場合は、dnに指定されているuid値が有効になります。
11.1.2.3.0では、属性の値および大文字と小文字の区別が等しいと想定されているため、11.1.2.3.0のデフォルトの動作に従って、Oracle Unified Directoryでは、エントリ作成時のdnにある値が有効となります。11.1.2.3.0のデフォルトでは、compact-encodingフラグはtrueに設定されます。アップグレード時には、特に静的グループに関しては、これらのグループが11.1.2.3.0に保存されている方法が原因で、指定されたcnまたはuid属性の大文字と小文字の区別が失われます。これが、compact-encodingフラグがtrueに設定された場合のデフォルトの動作です。
大文字と小文字の区別がある値を維持するには、アップグレードする直前にcompact-encodingフラグの値を明示的にfalseに設定する必要があります。詳細は、第18.8.1項「圧縮エンコーディングの有効化または無効化」を参照してください。
compact-encodingフラグがfalseに設定されていない場合は、dnに指定されたcnまたはuid属性値のみがアップグレード後にOracle Unified Directoryで有効になります。
ODSMの各サーバー・インスタンスの「データ・ブラウザ」タブで、ディレクトリ・データに対する基本検索を実行でき、エントリを追加、削除、および変更できます。
ODSMには、どのデータ・フィールドにも文字のサブセットを入力できる自動提案機能があります。その後、ODSMによって、その文字のサブセットに一致するすべてのエントリが返されます。自動提案機能では、ODSMによってすでにキャッシュされているエントリのみが返されます。
次の項では、ODSMでのデータの管理方法を説明し、内容は次のとおりです:
ODSMデータ・ブラウザを使用してディレクトリ・エントリを表示するには、次のステップを完了します。
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「データ・ブラウザ」タブを選択します。
「ネットワーク・グループ」リストから適切なネットワーク・グループを選択します。
「エントリ」ペインでエントリを開き、必要なサブツリー内のエントリをすべて表示します。
一度に最大200個のエントリが表示されます。
特定のエントリ・セットにエントリを制限するには、サブツリー(たとえば、ou=People
)を選択し、「フィルタ」アイコンをクリックします。
「フィルタ」フィールドで、必要なフィルタ(たとえば、surname=a*
)を入力し、「OK」をクリックします。
左ペインで表示するエントリを選択します。
右側のタブにエントリの詳細が表示されます。
第18.16.2項「エントリの属性の表示」も参照してください。
エントリの属性を表示するには:
第18.16.1項「エントリの表示」の説明に従って、エントリを表示します。
左ペインで表示するエントリを選択します。
右側のタブにエントリの詳細が表示されます。
すべてのエントリに、対応する「プロパティ」タブがあり、それにはそのエントリの使用可能な属性(必須とオプション)がすべて表示されます。さらに、次のタイプのエントリには、カスタマイズされたタブがあり、それにはそのエントリ・タイプに対して論理的なレイアウトでエントリの必須属性が表示されます:
inetorgperson
エントリには、対応する「ユーザー・ページ」タブがあります。
group
エントリには、対応する「グループ・ページ」タブがあります。
country
エントリには、対応する「国ページ」タブがあります。
domain
エントリには、対応する「ドメイン・ページ」タブがあります。
organization
エントリには、対応する「組織ページ」タブがあります。
organization unit
エントリには、対応する「組織単位ページ」タブがあります。
「データ・ブラウザ」タブの基本検索機能では、ユーザーまたはグループのエントリを検索できます。ディレクトリ・データに対して基本検索を実行するには、次のステップを完了します:
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「データ・ブラウザ」タブを選択します。
「ネットワーク・グループ」リストから適切なネットワーク・グループを選択します。
左ペインで「検索」タブを選択します。
「対象」リストから、ユーザー・エントリとグループ・エントリのどちらを検索するのかを選択します。
エントリ名の任意の部分を入力し、右矢印ボタンをクリックします。たとえば、John Smithというユーザーを検索するには、Smith
、Smi
、John
などを入力できます。
左ペインにエントリが表示されたら、そのエントリをダブルクリックし、右ペインにその詳細を表示します。
Oracle Directory Services Managerでエントリを追加または削除するには、親エントリに対する書込みアクセス権限があり、新規エントリの識別名を認識している必要があります。ODSMデータ・ブラウザを使用してエントリを追加するには、次のステップを完了します:
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「データ・ブラウザ」タブを選択します。
「ネットワーク・グループ」リストから適切なネットワーク・グループを選択します。
「エントリの追加」アイコンをクリックし、追加するエントリの種類(たとえば、「ユーザー・エントリ」)を選択します。
親エントリのDNを入力します。これはディレクトリ・ツリーでその下に新しいエントリが表示されるエントリです。たとえば、ou=people,dc=example,dc=com
です。
親エントリとして既存のエントリを選択するには、「選択」をクリックします。
「エントリ・ピッカー」ウィンドウで、「ツリー・ビュー」を選択してディレクトリ・ツリーに移動し、対象のエントリを見つけるか、「検索ビュー」を選択して対象のエントリを検索します。
新しいエントリの追加情報を入力します。
必要な詳細を入力したら、「作成」をクリックします。
ODSMデータ・ブラウザを使用して既存のエントリに基づいたエントリを追加するには、次のステップを完了します:
第18.16.1項「エントリの表示」の説明に従って、既存のエントリを表示します。
新しいエントリの基にするエントリを選択し、類似エントリの作成アイコンをクリックします。
既存のエントリの詳細が右ペインに表示されます。
そのエントリの新しい共通名 およびユーザー名を指定します。
エントリの他の詳細を変更します。
「作成」をクリックします。
ODSMデータ・ブラウザを使用してエントリを削除するには、次のステップを完了します:
第18.16.1項「エントリの表示」の説明に従って、既存のエントリを表示します。
削除するエントリを選択し、「削除」アイコンをクリックします。
「エントリの削除」ダイアログで、適切なエントリを削除しようとしていることを確認し、「OK」をクリックします。
エントリと、ディレクトリ・ツリー内でその下にあるすべてのエントリを削除するには、次のステップを完了します:
第18.16.1項「エントリの表示」の説明に従って、既存のエントリを表示します。
削除するエントリを選択し、エントリとそのサブツリーの削除アイコンをクリックします。
「サブツリーの削除」ダイアログで、適切なエントリを削除しようとしていることを確認し、「OK」をクリックします。
ODSMデータ・ブラウザを使用してエントリのRDNを変更するには、次のステップを完了します:
第18.16.1項「エントリの表示」の説明に従って、既存のエントリを表示します。
新しいエントリの基にする、変更するRDNを持つエントリを選択し、「RDNの編集」アイコンをクリックします。
「新規RDN値」フィールドに新しいRDNを指定します。
古いRDNを形成していた値をエントリから削除する場合は、「古いRDNの削除」を選択します。このチェック・ボックスを選択しない場合、古いRDNを形成していた値は、そのエントリの非識別属性値として保持されます。
オプションで、「サブツリー・エントリのリフレッシュ」アイコンをクリックし、RDNの変更を確認します。
次のようにして、LDIFファイルからエントリをインポートできます:
第16.2項「ODSMを使用したサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「データ・ブラウザ」タブを選択します。
「ネットワーク・グループ」リストから適切なネットワーク・グループを選択します。
「LDIFのインポート」アイコンをクリックします。
「エントリのインポート」ダイアログで、「ファイルの選択」をクリックします。
システム上のLDIFファイルを見つけ、「OK」をクリックします。
「LDIFのインポート進行状況」ダイアログで、インポートの進行状況をモニターし、インポートが完了したら、「OK」をクリックします。
データ・ブラウザ・ツリーがリフレッシュされ、新規エントリが表示されます。
次のようにして、ODSMを使用して、LDIFファイルにエントリをエクスポートできます:
ODSMデータ・ブラウザを使用してLDIFファイルにエントリをエクスポートするには、次のステップを完了します:
第18.16.1項「エントリの表示」の説明に従って、エントリを表示します。
エクスポートするサブツリーの最上位レベルの識別名にナビゲートし、「LDIFのエクスポート」アイコンをクリックします。
操作属性をエクスポートする場合は、「エントリのエクスポート」ダイアログで、「操作属性のエクスポート」を選択します。
「OK」をクリックします。
ここをクリックしてLDIFファイルを開きます。
ODSMが実行されているブラウザ・ウィンドウの個別タブに完全なLDIFファイルが表示されます。
書込み可能な場所にLDIFファイルを保存します。
「エントリのエクスポート」ダイアログで「OK」をクリックし、エクスポートを終了します。