Sun JavaTM System Directory Proxy Server には、Directory Proxy Server のインスタンスの登録と管理を行うためのブラウザインタフェースとコマンド行ツールがあります。このブラウザインタフェースは、Directory Service Control Center (DSCC) と呼ばれています。この章では、DSCC やコマンド行による Directory Proxy Server の管理に必要な基本タスクについて説明します。
特殊なタスクの実行に DSCC を使用するか、コマンド行を使用するかを決定するには、「DSCC を使用する場合とコマンド行を使用する場合の判断」を参照してください。
管理フレームワークの詳細は、『Sun Java System Directory Server Enterprise Edition 6.3 配備計画ガイド』の「Directory Server Enterprise Edition の管理モデル」を参照してください。
この章の内容は次のとおりです。
この節では、Directory Proxy Server の管理目的で、DSCC にアクセスする方法について説明します。
Directory Server の場合と同じ方法で DSCC にアクセスします。
「DSCC にアクセスする」を参照してください。
「プロキシサーバー」タブをクリックして Directory Proxy Server を表示し管理します。
次の図に Directory Proxy Server の最初のウィンドウを示します。
Directory Proxy Server インスタンスをクリックして、その該当のサーバーを表示または管理します。
DSCC の使い方の詳細は、オンラインヘルプを参照してください。
Directory Proxy Server の操作に使用するコマンド行ツールは、dpadm および dpconf と呼ばれています。これらのコマンドの使用方法については、dpadm(1M) および dpconf(1M) のマニュアルページを参照してください。
dpconf、dsconf、dsmig、 dsccmon、dsccreg、および dsccsetup は LDAP ベースのコマンドなので、認証を行うにはこれらのコマンドのユーザーバインド DN とパスワードを指定する必要があります。一方、dpadm コマンドと dsadm コマンドはインスタンスファイルで動作します。
この節では、dpadm コマンドと dpconf コマンドの場所について説明します。また、環境変数、これらのコマンドの比較、これらのコマンドを使用する際の参照情報の入手先についても記載します。
Directory Proxy Server のコマンド行ツールは、デフォルトでは次の場所にあります。
install-path/dps6/bin |
インストールパスはオペレーティングシステムによって異なります。すべてのオペレーティングシステムのインストールパスは、「デフォルトのパスとコマンドの場所」に一覧表示されています。
dpconf コマンドには、環境変数によってプリセットできるオプションが必要です。コマンドを使用する際にオプションが指定されていない場合や、環境変数が設定されていない場合は、デフォルト設定が使用されます。環境変数は次のオプションに対して設定できます。
ユーザーバインド DN。環境変数: LDAP_ADMIN_USER。デフォルト: cn=Proxy Manager。
ユーザーバインド DN のパスワードファイル。環境変数: LDAP_ADMIN_PWF。デフォルト: パスワード入力用のプロンプトを表示する。
ホスト名または IP アドレス。環境変数: DIR_PROXY_HOST。デフォルト: localhost。
LDAP ポート番号。環境変数: DIR_PROXY_HOST。デフォルト: サーバーインスタンスが root として実行中の場合は 389、サーバーインスタンスが通常のユーザーとして実行中の場合は 1389。
dpconf がデフォルトでクリア接続を開くように指定します。環境変数: DIR_PROXY_UNSECURED。この変数が設定されていない場合、dpconf はデフォルトでセキュリティー保護された接続を開きます。
詳細は、dpconf(1M) のマニュアルページを参照してください。
次の表に、dpadm コマンドと dpconf コマンドの比較を示します。
表 17–1 dpadm コマンドと dpconf コマンドの比較
|
dpadm コマンド |
dpconf コマンド |
---|---|---|
目的 |
Directory Proxy Server のローカルインスタンスのプロセスやファイルを管理すること |
Directory Proxy Server のローカルやリモートのインスタンスを設定すること |
ユーザー |
オペレーティング システムのユーザー |
LDAP ユーザー |
ローカルまたはリモート |
コマンドはインスタンスに対してローカルでなければなりません。つまり、コマンドは、サーバーが実行中のホストで実行する必要があります。 |
コマンドはインスタンスに対してローカルにすることができますが、ネットワーク上のどの場所からも実行できます。 |
コマンドの使用例 |
Directory Proxy Server のインスタンスを作成します。 Directory Proxy Server のインスタンスを起動および停止します。 証明書データベースを管理します。 |
Directory Proxy Server のインスタンスの設定を変更します。 データビューを作成します。 データソースプールの負荷分散を設定します。 |
サーバーの状態 |
サーバーは稼動中でも停止していてもかまいません。 |
サーバーは動作している必要があります。 |
コマンドがサーバーインスタンスを識別する方法 |
インスタンスパスを指定することで識別します。インスタンスパスは相対でも絶対でもかまいません。 |
ホスト名か IP アドレスと、ポート番号を指定することで識別します。 コマンドは、LDAP ポート (-p) または LDAPS セキュアポート (-P) を使用します。コマンド行にポート番号が指定されていない場合は、PROXY_PORT 環境変数が使用されます。環境変数が設定されていない場合は、デフォルトポートが使用されます。 |
Directory Proxy Server のプロパティーによっては、複数の値をとることがあります。複数の値を指定するには、次の構文を使用します。
$ dpconf set-container-prop -h host -p port \ property:value [property:value] |
たとえば、my-view という LDAP データビューに複数の書き込み可能属性を設定するには、次のコマンドを入力します。
$ dpconf set-ldap-data-view-prop -h host1 -p 1389 view-name\ writable-attr:uid writable-attr:cn writable-attr:userPassword |
すでに値が含まれている複数値プロパティーに値を追加するには、次のコマンドを入力します。
$ dpconf set-container-prop -h host -p port \ property+:value |
すでに値が含まれている複数値プロパティーから値を削除するには、次のコマンドを入力します。
$ dpconf set-container-prop -h host -p port\ property-:value |
たとえば、前述の例で、書き込み可能属性のリストに sn を追加するには、次のコマンドを入力します。
$ dpconf set-ldap-data-view-prop -h host1 -p 1389 view-name\ writable-attr+:sn |
書き込み可能属性のリストから cn を削除するには、次のコマンドを入力します。
$ dpconf set-ldap-data-view-prop -h host1 -p 1389 view-name\ writable-attr-:cn |
dpadm コマンドと dpconf コマンドの使用方法については、dpadm(1M) および dpconf(1M) のマニュアルページを参照してください。
サブコマンドの一覧を表示するには、次の該当するコマンドを入力します。
$ dpadm --help |
$ dpconf --help |
サブコマンドの使用方法についての説明を表示するには、次の該当するコマンドを入力します。
$ dpadm subcommand --help |
$ dpconf subcommand --help |
dpconf コマンドで使用する設定プロパティーについての情報を得るには、次のように入力します。
$ dpconf help-properties |
サブコマンドの設定プロパティーについての情報を得るには、次のコマンドを使用します。
$ dpconf help-properties subcommand-entity |
たとえば、アクセスログプロパティーについての情報を調べるには、次のように入力します。
$ dpconf help-properties access-log |
サブコマンドで使用するプロパティーについての情報を得るには、次のコマンドを使用します。
$ dpconf help-properties subcommand-entity property |
たとえば、set-access-log-prop サブコマンドの log-search-filters プロパティーについての情報を調べるには、次のように入力します。
$ dpconf help-properties access-log log-search-filters |
データビューや接続ハンドラなどのエンティティーのグループのキープロパティーを一覧表示するには、list サブコマンドで冗長オプション -v を指定してください。
たとえば、接続ハンドラすべてのキープロパティーや相対プロパティーを表示するには、次のコマンドを使用します。
$ dpconf list-connection-handlers -h host -p port -v Name is-enabled priority description -------------------------- ---------- -------- --------------------------- anonymous false 99 unauthenticated connections default connection handler true 100 default connection handler dscc administrators true 1 Administrators connection handler |
個々のプロパティーの詳細は、該当のプロパティーのマニュアルページを参照してください。
この章では、Directory Proxy Server のインスタンスを管理する方法について説明します。この章の内容は次のとおりです。
Directory Proxy Server のインスタンスを作成すると、インスタンスに必要なファイルとディレクトリが指定するパス内に作成されます。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
DSCC を使用して新しいサーバーインスタンスを作成する場合は、既存のサーバーからサーバー設定の一部またはすべてをコピーするよう選択できます。
Directory Proxy Server のインスタンスを作成します。
$ dpadm create -p port instance-path |
たとえば、ディレクトリ /local/dps 内に新しいインスタンスを作成するには、次のコマンドを使用します。
$ dpadm create -p 2389 /local/dps |
インスタンスのほかのパラメータの指定については、dpadm(1M) のマニュアルページを参照してください。
必要に応じてパスワードを入力します。
インスタンスの状況を確認して、インスタンスが作成されていることを確認します。
$ dpadm info instance-path |
(省略可能) Directory Proxy Server が Sun JavaTM Enterprise System インストーラまたはネイティブパッケージインストールを使用してインストールされていて、OS がサービス管理ソリューションを提供する場合は、次の表に示すサービスとしてサーバーを管理できます。
オペレーティングシステム |
コマンド |
---|---|
Solaris 10 |
dpadm enable-service --type SMF instance-path |
Solaris 9 |
dpadm autostart instance-path |
Linux、HP-UX |
dpadm autostart instance-path |
Windows |
dpadm enable-service --type WIN_SERVICE instance-path |
(省略可能) 次のいずれかの方法で、サーバーインスタンスを登録します。
https://localhost:6789 という URL で DSCC にアクセスし、ブラウザインタフェースにログインします。
dsccreg add-server コマンドを使用します。
詳細は、dsccreg(1M) のマニュアルページを参照してください。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
設定変更は、変更を有効にする前にサーバーの再起動が必要になる場合があります。設定変更後に Directory Proxy Server インスタンスを再起動する必要があるかどうかを確認するには、この手順に従います。
サーバーを再起動する必要があるかどうかを確認します。
$ dpconf get-server-prop -h host -p port is-restart-required |
このコマンドが true を返す場合、Directory Proxy Server のインスタンスを再起動する必要があります。
このコマンドが false を返す場合、Directory Proxy Server のインスタンスを再起動する必要はありません。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
Directory Proxy Server を再起動します。
$ dpadm restart instance-path |
たとえば、インスタンスを /local/dps で再起動するには、次のコマンドを入力します。
$ dpadm restart /local/dps |
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
(省略可能) Directory Proxy Server インスタンスを停止します。
$ dpadm stop instance-path |
インスタンスを停止していない場合は、削除コマンドによって自動的に停止します。ただし、サービス管理ソリューションでインスタンスが有効になっている場合は、手動で停止する必要があります。
(省略可能) 以前に DSCC を使用してサーバーを管理していた場合は、コマンド行を使用してサーバーを登録解除します。
$ dsccreg remove-server /local/dps Enter DSCC administrator's password: /local/dps is an instance of DPS Enter password of "cn=Proxy Manager" for /local/dps: Unregistering /local/dps from DSCC on localhost. Connecting to /local/dps Disabling DSCC access to /local/dps |
詳細については、dsccreg(1M) のマニュアルページを参照してください。
(省略可能) 以前にサーバー管理ソリューションでサーバーインスタンスを有効にした場合は、サービスとしてのサーバーの管理を無効にします。
オペレーティングシステム |
コマンド |
---|---|
Solaris 10 |
dpadm disable-service --type SMF instance-path |
Solaris 9 |
dpadm autostart --off instance-path |
Linux、HP-UX |
dpadm autostart --off instance-path |
Windows |
dpadm disable-service --type WIN_SERVICE instance-path |
$ dpadm delete instance-path |
この節では、Directory Proxy Server のインスタンスを設定する方法について説明します。この節で示す手順では、dpadm コマンドと dpconf コマンドを使用します。これらのコマンドについては、dpadm(1M) および dpconf(1M) のマニュアルページを参照してください。
$ dpconf info インスタンスのパス : instance path ホスト名 : host セキュリティー保護された待機アドレス : IP address ポート : port セキュリティー保護されたポート : secure port SSL サーバー証明書 : defaultServerCert Directory Proxy Server を再起動する必要があります。 |
dpconf info では、「セキュリティー保護された待機アドレス」と「待機アドレス」は、これらのプロパティーがデフォルト以外の値に設定されている場合にのみ表示されます。この出力例では、「待機アドレス」のプロパティーがデフォルト値に設定されているため、この項目は表示されていません。
また、dpconf info では、必要な場合はインスタンスを再起動するようにユーザーに促します。
dpadm info でも Directory Proxy Server インスタンスの設定情報を表示できます。
この節では、Directory Proxy Server の設定を変更する方法について説明します。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
Directory Proxy Server の現在の設定を調べます。
$ dpconf get-server-prop -h host -p port |
allow-cert-based-auth : allow allow-ldapv2-clients : true allow-persistent-searches : false allow-sasl-external-authentication : true allow-unauthenticated-operations : true allowed-ldap-controls : - cert-data-view-routing-custom-list : none cert-data-view-routing-policy : all-routable cert-search-attr-mappings : none cert-search-base-dn : none cert-search-bind-dn : none cert-search-bind-pwd : none cert-search-user-attr : userCertificate configuration-manager-bind-dn : cn=proxy manager configuration-manager-bind-pwd : {3DES}RPdIFbvoWdvhLR8lU43zCMZyKFGPxfFg connection-pool-wait-timeout : 3s data-source-read-timeout : 20s data-view-automatic-routing-mode : automatic email-alerts-enabled : false email-alerts-message-from-address : local email-alerts-message-subject : Proxy Server Administrative Alert email-alerts-message-subject-includes-alert-code : false email-alerts-message-to-address : root@localhost email-alerts-smtp-host : localhost email-alerts-smtp-port : smtp enable-remote-user-mapping : false enable-user-mapping : false enabled-admin-alerts : none enabled-ssl-cipher-suites : JRE enabled-ssl-protocols : SSLv3 enabled-ssl-protocols : TLSv1 encrypt-configuration : true extension-jar-file-url : none is-restart-required : false number-of-search-threads : 20 number-of-worker-threads : 50 proxied-auth-check-timeout : 30m remote-user-mapping-bind-dn-attr : none scriptable-alerts-command : echo scriptable-alerts-enabled : false search-mode : parallel search-wait-timeout : 10s ssl-client-cert-alias : none ssl-server-cert-alias : defaultServerCert supported-ssl-cipher-suites : SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA supported-ssl-cipher-suites : SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA supported-ssl-cipher-suites : SSL_DHE_DSS_WITH_DES_CBC_SHA supported-ssl-cipher-suites : SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA supported-ssl-cipher-suites : SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA supported-ssl-cipher-suites : SSL_DHE_RSA_WITH_DES_CBC_SHA supported-ssl-cipher-suites : SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA supported-ssl-cipher-suites : SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 supported-ssl-cipher-suites : SSL_DH_anon_WITH_3DES_EDE_CBC_SHA supported-ssl-cipher-suites : SSL_DH_anon_WITH_DES_CBC_SHA supported-ssl-cipher-suites : SSL_DH_anon_WITH_RC4_128_MD5 supported-ssl-cipher-suites : SSL_RSA_EXPORT_WITH_DES40_CBC_SHA supported-ssl-cipher-suites : SSL_RSA_EXPORT_WITH_RC4_40_MD5 supported-ssl-cipher-suites : SSL_RSA_WITH_3DES_EDE_CBC_SHA supported-ssl-cipher-suites : SSL_RSA_WITH_DES_CBC_SHA supported-ssl-cipher-suites : SSL_RSA_WITH_NULL_MD5 supported-ssl-cipher-suites : SSL_RSA_WITH_NULL_SHA supported-ssl-cipher-suites : SSL_RSA_WITH_RC4_128_MD5 supported-ssl-cipher-suites : SSL_RSA_WITH_RC4_128_SHA supported-ssl-cipher-suites : TLS_DHE_DSS_WITH_AES_128_CBC_SHA supported-ssl-cipher-suites : TLS_DHE_RSA_WITH_AES_128_CBC_SHA supported-ssl-cipher-suites : TLS_DH_anon_WITH_AES_128_CBC_SHA supported-ssl-cipher-suites : TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 supported-ssl-cipher-suites : TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA supported-ssl-cipher-suites : TLS_KRB5_EXPORT_WITH_RC4_40_MD5 supported-ssl-cipher-suites : TLS_KRB5_EXPORT_WITH_RC4_40_SHA supported-ssl-cipher-suites : TLS_KRB5_WITH_3DES_EDE_CBC_MD5 supported-ssl-cipher-suites : TLS_KRB5_WITH_3DES_EDE_CBC_SHA supported-ssl-cipher-suites : TLS_KRB5_WITH_DES_CBC_MD5 supported-ssl-cipher-suites : TLS_KRB5_WITH_DES_CBC_SHA supported-ssl-cipher-suites : TLS_KRB5_WITH_RC4_128_MD5 supported-ssl-cipher-suites : TLS_KRB5_WITH_RC4_128_SHA supported-ssl-cipher-suites : TLS_RSA_WITH_AES_128_CBC_SHA supported-ssl-protocols : SSLv2Hello supported-ssl-protocols : SSLv3 supported-ssl-protocols : TLSv1 syslog-alerts-enabled : false syslog-alerts-facility : USER syslog-alerts-host : localhost use-cert-subject-as-bind-dn : true use-external-schema : false user-mapping-anonymous-bind-dn : none user-mapping-anonymous-bind-pwd : none user-mapping-default-bind-dn : none user-mapping-default-bind-pwd : none verify-certs : false |
あるいは、1 つまたは複数のプロパティーの現在の設定を確認します。
$ dpconf get-server-prop -h host -p port property-name ... |
たとえば、このコマンドを実行することで、未認証の操作が許可されているかどうかを調べます。
$ dpconf get-server-prop -h host -p port allow-unauthenticated-operations allow-unauthenticated-operations : true |
$ dpconf set-server-prop -h host -p port property:value ... |
たとえば、このコマンドを実行することで、未認証の操作を許可しないようにします。
$ dpconf set-server-prop -h host -p port allow-unauthenticated-operations:false |
不正な変更を試みても、変更は行われません。たとえば、allow-unauthenticated-operations パラメータを false ではなく f に設定すると、次のようなエラーが発生します。
$ dpconf set-server-prop -h host -p port allow-unauthenticated-operations:f The value "f" is not a valid value for the property "allow-unauthenticated-operations". Allowed property values: BOOLEAN The "set-server-prop" operation failed. |
必要に応じて、変更を有効にするために Directory Proxy Server のインスタンスを再起動します。
Directory Proxy Server の再起動については、「Directory Proxy Server を再起動する」を参照してください。
Proxy Manager とは、特権を持つ管理者のことで、UNIX® システムの root ユーザーにあたります。Proxy Manager のエントリは、Directory Proxy Server のインスタンスの作成時に定義されます。Proxy Manager のデフォルト DN は cn=Proxy Manager です。
Proxy Manager DN およびパスワードは、次の手順で示すように表示および変更できます。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
Proxy Manager の設定を調べます。
$ dpconf get-server-prop -h host -p port configuration-manager-bind-dn configuration-manager-bind-pwd configuration-manager-bind-dn : cn=proxy manager configuration-manager-bind-pwd : {3DES}U77v39WX8MDpcWVrueetB0lfJlBc6/5n |
Proxy Manager のデフォルト値は cn=proxy manager です。設定マネージャーのパスワードに対するハッシュ値が返されます。
Proxy Manager の DN を変更します。
$ dpconf set-server-prop -h host -p port configuration-manager-bind-dn:bindDN |
Proxy Manager に対するパスワードを含むファイルを作成し、そのファイルを指すプロパティーを設定します。
$ dpconf set-server-prop -h host -p port configuration-manager-bind-pwd-file:filename |
Directory Proxy Server とそのエントリに対するほとんどの設定変更は、オンラインで行うことができます。一部の変更は、変更を有効にするためにサーバーを再起動する必要があります。次のリストのプロパティーに対する設定変更を行う場合は、サーバーを再起動する必要があります。
aci-data-view bind-dn client-cred-mode custom-distribution-algorithm db-name db-pwd db-url db-user distribution-algorithm ldap-address ldap-port ldaps-port listen-address listen-port load-balancing-algorithm num-bind-init num-read-init num-write-init number-of-search-threads number-of-threads number-of-worker-threads ssl-policy use-external-schema
プロパティーの rws キーワードとrwd キーワードは、プロパティーを変更した場合にサーバーを再起動する必要があるかどうかを示します。
プロパティーに rws (読み取り、書き込み、静的) キーワードが含まれている場合は、プロパティーを変更したときにサーバーを再起動する必要があります。
プロパティーに rwd (読み取り、書き込み、動的) キーワードが含まれている場合、プロパティーに対する変更は、サーバーを再起動しなくても、動的に実装されます。
プロパティーに対する変更でサーバーを再起動する必要があるかどうかを確認するには、次のコマンドを実行します。
$ dpconf help-properties | grep property-name
たとえば、LDAP データのバインド DN の変更でサーバーを再起動する必要があるかどうかを確認するには、次のコマンドを実行します。
$ dpconf help-properties | grep bind-dn connection-handler bind-dn-filters rwd STRING | any This property specifies a set of regular expressions. The bind DN of a client must match at least one regular expression in order for the connection to be accepted by the connection handler. (Default: any) ldap-data-source bind-dn rws DN | "" This property specifies the DN to use when binding to the LDAP data source. (Default: undefined)
設定変更のあとでサーバーを再起動する必要があるかどうかを確認するには、次のコマンドを実行します。
$ dpconf get-server-prop -h host -p port is-restart-required
dpadm を使って Directory Proxy Server をバックアップすると、設定ファイルとサーバー証明書がバックアップされます。Directory Proxy Server の仮想 ACI が実装されている場合は、ACI もバックアップされます。
Directory Proxy Server では、サーバーが正常に起動した場合は常に、conf.ldif ファイルが自動的にバックアップされます。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
Directory Proxy Server のインスタンスを停止します。
$ dpadm stop instance-path |
Directory Proxy Server のインスタンスをバックアップします。
$ dpadm backup instance-path archive-dir |
archive-dir ディレクトリは backup コマンドによって作成され、このコマンドを実行する前から存在してはいけません。このディレクトリには、設定ファイルと証明書のそれぞれのバックアップが含まれます。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
復元操作を開始する前に、Directory Proxy Server インスタンスを作成してください。
Directory Proxy Server のインスタンスを停止します。
$ dpadm stop instance-path |
Directory Proxy Server のインスタンスを復元します。
$ dpadm restore instance-path archive-dir |
インスタンスパスが存在する場合、復元操作はメッセージを表示せずに実行されます。instance-path ディレクトリ内の設定ファイルと証明書は、archive-dir ディレクトリ内のもので置き換えられます。
インスタンスパスが存在しない場合、復元操作は失敗します。
LDAP データビューは、LDAP サーバーのデータをクライアント要求に公開し、その要求に応答するデータソースプールを指定します。LDAP データビューを定義することで、次の操作を実行できます。
データベース全体を 1 つのビューで公開する
データベース内の異なるサブツリーに対して異なるビューを提供する
異なるデータベースの統合ビューを提供する
LDAP データビューの作成には、次の手順が含まれます。
この節では、dpconf コマンドを使用して LDAP データソースを作成および設定する方法について説明します。これらのトピックの詳細は、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「LDAP Data Sources」を参照してください。
LDAP データソースの作成と設定の方法については、次の手順を参照してください。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
$ dpconf create-ldap-data-source -h host -p port source-name host:port |
このコマンドで、source-name は新しいデータソースに割り当てる名前です。host と port は、LDAP サーバーが実行されているホストとポートを示します。データソースはデフォルトで SSL を使用しない点に注意してください。
ホストが IP V6 アドレスで指定されている場合、データソースの作成時に IP V6 参照を使用する必要があります。たとえば、Directory Proxy Server がポート 2389 で IP V6 アドレス fe80::209:3dff:fe00:8c93 を持つホストにバインドされる場合、次のコマンドを使用してデータソースを作成します。
$ dpconf create-ldap-data-source -h host1 -p 1389 ipv6-host \ [fe80::209:3dff:fe00:8c93]:2389 |
コンソールを使用してデータソースを作成する場合は、実際の IP V6 アドレスを角括弧なしで指定する必要があります。
LDAP データソースのプロパティーの変更方法については、「LDAP データソースを設定する」を参照してください。
$ dpconf list-ldap-data-sources -h host -p port |
次の手順では、LDAP データソースのプロパティーを表示する方法、および変更する必要のあるプロパティーを設定する方法を示します。LDAP データソースのどのプロパティーの変更にも使用できるコマンドも示します。また、プロパティーの詳細情報を取得する方法も示します。この情報は、そのプロパティーの設定に役立ちます。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
次のコマンド構文を使用して、データソースのプロパティーを表示します。
$ dpconf get-ldap-data-source-prop -h host -p port \ [-M unit] [-Z unit] source-name [property...] |
このコマンドで -M と -Z は、データを表示する単位を示します。M オプションは時間の単位を指定します。-M の値は、月、週、日、時間、分、秒、ミリ秒を示すために、M、 w、d、h、m、 s、または ms にできます。-Z オプションはデータサイズの単位を指定します。-Z の値は、T バイト、G バイト、M バイト、K バイト、バイトを示すために、T、 G、M、k、または b にできます。
プロパティーを指定しないと、すべてのプロパティーが表示されます。LDAP データソースのデフォルトプロパティーは次のとおりです。
bind-dn : - bind-pwd : - client-cred-mode : use-client-identity connect-timeout : 10s description : - is-enabled : false is-read-only : true ldap-address : host ldap-port : port ldaps-port : ldaps monitoring-bind-timeout : 5s monitoring-entry-dn : "" monitoring-entry-timeout : 5s monitoring-inactivity-timeout : 2m monitoring-interval : 30s monitoring-mode : proactive monitoring-search-filter : (|(objectClass=*)(objectClass=ldapSubEntry)) num-bind-incr : 10 num-bind-init : 10 num-bind-limit : 1024 num-read-incr : 10 num-read-init : 10 num-read-limit : 1024 num-write-incr : 10 num-write-init : 10 num-write-limit : 1024 proxied-auth-check-timeout : 1.8s proxied-auth-use-v1 : false ssl-policy : never use-tcp-no-delay : true |
データソースを有効にします。
$ dpconf set-ldap-data-source-prop -h host -p port source-name is-enabled:true |
デフォルト設定を変更する場合は、手順 1に一覧表示されているプロパティーをすべて設定します。
$ dpconf set-ldap-data-source-prop -h host -p port source-name property:value |
たとえば、データソース上のエントリを変更する場合、書き込み操作を許可するようにデータソースを設定します。
$ dpconf set-ldap-data-source-prop -h host -p port source-name is-read-only:false |
サブコマンドで使用するプロパティーについての情報を見つけるには、次のコマンドを実行します。
$ dpconf help-properties ldap-data-source property |
たとえば、is-read-only プロパティーについての情報を見つけるには、次のコマンドを実行します。
dpconf help-properties ldap-data-source is-read-only |
データソースの主要なプロパティーを一覧表示するには、list-ldap-data-sources サブコマンドとともに冗長オプション - v を使用します。
$ dpconf list-ldap-data-sources -v Name is-enabled ldap-address ldap-port ldaps-port description ----------- ---------- ------------ --------- ---------- ----------- datasource0 true myHost myPort ldaps - datasource1 true myHost myPort ldaps - |
必要に応じて、変更を有効にするために Directory Proxy Server のインスタンスを再起動します。
Directory Proxy Server の再起動については、「Directory Proxy Server を再起動する」を参照してください。サーバーの再起動が必要な設定の変更の一覧は、「サーバーの再起動を必要とする設定変更」を参照してください。
この節では、dpconf コマンドを使用して LDAP データソースプールを作成および設定する方法について説明します。これらのトピックの詳細は、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「LDAP Data Sources」を参照してください。
データソースプールの作成と設定の方法については、次の手順を参照してください。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
$ dpconf create-ldap-data-source-pool -h host -p port pool-name |
最初の pool-name のあとに、追加のデータソースプールを指定できます。データソースプールのプロパティーの変更方法については、「LDAP データソースプールを設定する」を参照してください。
$ dpconf list-ldap-data-source-pools -h host -p port |
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
次のコマンド構文を使用して、データソースプールのプロパティーを表示します。
$ dpconf get-ldap-data-source-pool-prop -h host -p port \ [-M unit] [-Z unit] pool-name [property...] |
このコマンドで -M と -Z は、データを表示する単位を示します。M オプションは時間の単位を指定します。-M の値は、月、週、日、時間、分、秒、ミリ秒を示すために、M、 w、d、h、m、 s、または ms にできます。-Z オプションはデータサイズの単位を指定します。-Z の値は、T バイト、G バイト、M バイト、K バイト、バイトを示すために、T、 G、M、k、または b にできます。
プロパティーを指定しないと、すべてのプロパティーが表示されます。LDAP データソースプールのデフォルトプロパティーは次のとおりです。
client-affinity-policy : write-affinity-after-write client-affinity-timeout : 20s description : - enable-client-affinity : false load-balancing-algorithm : proportional |
手順 1に一覧表示されているプロパティーを設定します。
$ dpconf set-ldap-data-source-pool-prop -h host -p port pool-name \ property:value |
負荷分散とクライアントアフィニティーのためにデータソースプールのプロパティーを設定する方法については、第 21 章「Directory Proxy Server による負荷分散とクライアントアフィニティー」を参照してください。
データソースプールに接続されたデータソースは、接続済みデータソースと呼ばれます。接続済みデータソースのプロパティーによって、データソースプールの負荷分散設定が決まります。接続済みデータソースのウェイトを設定する場合は、データソースプールのすべての接続済みデータソースのウェイトを考慮します。ウェイトの設定どおりに負荷分散が機能することを確認します。負荷分散のためにウェイトを設定する方法については、「負荷分散のウェイトを設定する」を参照してください。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
1 つまたは複数のデータソースをデータソースプールに接続します。
$ dpconf attach-ldap-data-source -h host -p port pool-name \ source-name [source-name ...] |
(省略可能) 特定のデータソースプールの接続済みデータソースをすべて一覧表示します。
$ dpconf list-attached-ldap-data-sources -h host -p port -E pool-name |
このコマンドで、-E はオプションであり、1 行に 1 つずつプロパティー値を表示するように表示を変更します。
(省略可能) 特定のデータソースプールの接続済みデータソースの主要なプロパティーを表示します。
$ dpconf list-attached-ldap-data-sources -h host -p port -v pool-name |
このコマンドで、-v は冗長出力を指定します。たとえば、データソースプールの例のプロパティーを表示します。
$ dpconf list-attached-ldap-data-sources -h host1 -p 1389 -v My-pool SRC_NAME add-weight bind-weight compare-weight ----------- ---------- ----------- -------------- datasource0 disabled disabled disabled datasource1 disabled disabled disabled delete-weight modify-dn-weight modify-weight search-weight ------------- ---------------- ------------- ------------- disabled disabled disabled disabled disabled disabled disabled disabled |
(省略可能) 次のコマンド構文を使用して、接続済みデータソースのプロパティーを表示します。
$ dpconf get-attached-ldap-data-source-prop -h host -p port [-M unit] [-Z unit] \ pool-name source-name [property...] |
このコマンドで -M と -Z は、データを表示する単位を示します。M オプションは時間の単位を指定します。-M の値は、月、週、日、時間、分、秒、ミリ秒を示すために、M、 w、d、h、m、 s、または ms にできます。-Z オプションはデータサイズの単位を指定します。-Z の値は、T バイト、G バイト、M バイト、K バイト、バイトを示すために、T、 G、M、k、または b にできます。
プロパティーを指定しないと、すべてのプロパティーが表示されます。
接続済みデータソースのプロパティーは、負荷分散で各種の操作のウェイトを定義します。接続済みデータソースのデフォルトウェイトは次のとおりです。
add-weight : disabled bind-weight : disabled compare-weight : disabled delete-weight : disabled modify-dn-weight : disabled modify-weight : disabled search-weight : disabled |
Directory Proxy Server が意図したとおりに動作するためには、接続済みデータソースのプロパティーを設定する必要があります。次の例では、すべてのプロパティーが 1 に設定されています。これらのプロパティーの値は、要件によって変更できます。負荷分散のために接続済みデータソースのウェイトを設定する方法については、「負荷分散のウェイトを設定する」を参照してください。
$ dpconf set-attached-ldap-data-source-prop -h host -p port \ pool-name source-name add-weight:1 $ dpconf set-attached-ldap-data-source-prop -h host -p port \ pool-name source-name bind-weight:1 $ dpconf set-attached-ldap-data-source-prop -h host -p port \ pool-name source-name compare-weight:1 $ dpconf set-attached-ldap-data-source-prop -h host -p port \ pool-name source-name delete-weight:1 $ dpconf set-attached-ldap-data-source-prop -h host -p port \ pool-name source-name modify-dn-weight:1 $ dpconf set-attached-ldap-data-source-prop -h host -p port \ pool-name source-name modify-weight:1 $ dpconf set-attached-ldap-data-source-prop -h host -p port \ pool-name source-name search-weight:1 |
LDAP データビューの作成と設定の方法については、次の手順を参照してください。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
LDAP データビューを作成します。
$ dpconf create-ldap-data-view -h host -p port view-name pool-name suffix-DN |
LDAP データビューのプロパティーの変更方法については、「LDAP データビューを設定する」を参照してください。
LDAP データビューの一覧を表示します。
$ dpconf list-ldap-data-views -h host -p port |
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
LDAP データビューのプロパティーを表示します。
$ dpconf get-ldap-data-view-prop -h host -p port view-name |
プロパティーを設定せずにデータビューを作成すると、データビューは次のような設定になります。
alternate-search-base-dn : "" attr-name-mappings : none base-dn : suffix-DN contains-shared-entries : false custom-distribution-algorithm-class : none description : - distribution-algorithm : none dn-join-rule : none dn-mapping-attrs : none dn-mapping-source-base-dn : none excluded-subtrees : - filter-join-rule : none is-enabled : true is-read-only : false is-routable : true ldap-data-source-pool : pool-name lexicographic-attrs : all lexicographic-lower-bound : none lexicographic-upper-bound : none non-viewable-attr : none non-writable-attr : none numeric-attrs : all numeric-default-data-view : false numeric-lower-bound : none numeric-upper-bound : none pattern-matching-base-object-search-filter : all pattern-matching-dn-regular-expression : all pattern-matching-one-level-search-filter : all pattern-matching-subtree-search-filter : all process-bind : - replication-role : master viewable-attr : all except non-viewable-attr writable-attr : all except non-writable-attr |
プロキシマネージャー以外のすべてのユーザーには、バックエンドサーバーの cn=config および cn=monitor サフィックスが表示されます。プロキシマネージャーは、デフォルトでバックエンドサーバーからのデータを使用できません。プロキシマネージャーが使用できる cn=config および cn=monitor サブツリーは、プロキシ自体のサブツリーです。
Directory Proxy Server インスタンスを作成すると、プロキシマネージャーの接続ハンドラが空のデータビューポリシーで作成されます。プロキシマネージャーがバックエンドデータへのアクセスを必要とする場合、プロキシマネージャーの接続ハンドラのデータビューポリシーにデータビューを追加する必要があります。このようなデータビューでは、cn=config および cn=monitor サブツリーは、デフォルトで除外されます。
手順 1で一覧表示されるプロパティーの 1 つまたは複数を変更します。
$ dpconf set-ldap-data-view-prop -h host -p port view-name \ property:value [property:value ... ] |
たとえば、データソースの dc=example,dc=com サブツリーにアクセスするには、データビューで dn-mapping-source-base-dn と指定します。
$ dpconf set-ldap-data-view-prop -h host1 -p 1389 myDataView \ dn-mapping-source-base-dn:dc=example,dc=com |
複数値プロパティーに値を追加するには、次のコマンドを使用します。
$ dpconf set-ldap-data-view-prop -h host -p port view-name property+:value |
複数値プロパティーから値を削除するには、次のコマンドを使用します。
$ dpconf set-ldap-data-view-prop -h host -p port view-name property-:value |
必要に応じて、変更を有効にするために Directory Proxy Server のインスタンスを再起動します。
Directory Proxy Server の再起動については、「Directory Proxy Server を再起動する」を参照してください。
Directory Proxy Server の設定エントリは cn=config 内にあります。Directory Proxy Server を使用して設定エントリにアクセスすると、デフォルトでは、Directory Proxy Server の設定エントリにアクセスします。
ディレクトリサーバーの設定エントリにアクセスするには、Directory Proxy Server ではなく Directory Server に直接接続することをお勧めします。Directory Server の設定方法の詳細は、第 4 章「Directory Server の設定」を参照してください。
ディレクトリサーバーの設定エントリにアクセスするよう Directory Proxy Server を設定し直すと、たいていは Directory Proxy Server の管理フレームワークが壊れます。
どうしても Directory Proxy Server からディレクトリサーバーの設定エントリにアクセスする必要がある場合は、Directory Proxy Server の管理フレームワークが壊れないよう、特別の手順をとります。この節では、Directory Proxy Server を使用してディレクトリサーバーの設定エントリにアクセスする方法について説明します。
1 つまたは複数のデータソースを作成します。これについては、「LDAP データソースの作成と設定」を参照してください。
LDAP データソースプールを作成します。これについては、「LDAP データソースプールの作成と設定」を参照してください。
1 つまたは複数のデータソースを、データソースプールに接続します。これについては、「LDAP データソースのデータソースプールへの接続」を参照してください。
1 つの特定のデータソースの設定エントリを公開するには、1 つの LDAP データソースだけを LDAP データソースプールに接続します。
$ dpconf attach-ldap-data-source -h host -p port pool-name data-source-name |
この手順を実行したあと、クライアントは、Directory Proxy Server に接続されているデータソースの設定エントリにアクセスできるようになります。
任意の特定のデータソースの設定エントリを公開するには、複数の LDAP データソースを LDAP データソースプールに接続します。
$ dpconf attach-ldap-data-source -h host -p port pool-name data-source-name \ data-source-name ... |
この手順を実行したあと、クライアントは、Directory Proxy Server に接続されているデータソースの 1 つの設定エントリにアクセスできるようになります。ただし、クライアントには、設定エントリがどのデータソースに属するかはわかりません。
LDAP データビューを作成して、cn=config を公開します。
$ dpconf create-ldap-data-view -h host -p port view-name pool-name cn=config |
ディレクトリ内の各エントリは、DN および一連の属性とその値によって識別されます。しばしば、クライアント側で定義された DN と属性は、サーバー側で定義された DN と属性にマップされません。DN と属性の名前を変更するためにデータビューを定義できます。クライアントが要求を行うと、DN と属性の名前がサーバー側と一致するように変更されます。結果がクライアントに返されると、DN と属性はクライアント側と一致するよう元に戻されます。
属性と DN の名前の変更については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Attribute Renaming and DN Renaming」を参照してください。属性と DN の名前の変更方法については、次の手順を参照してください。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
属性のマッピングを設定するデータビューで 1 つまたは複数の attr-name-mappings プロパティーを設定します。
$ dpconf set-ldap-data-view-prop -h host -p port view-name \ attr-name-mappings:client-side-attribute-name#server-side-attribute-name\ [attr-name-mappings:client-side-attribute-name#server-side-attribute-name ...] |
たとえば、クライアント側の surname をサーバー側では sn と名前変更します。
$ dpconf set-ldap-data-view-prop -h host1 -p 1389 myDataView \ attr-name-mappings:surname#sn |
既存のマッピングリストに属性マッピングを追加するには、次のコマンドを使用します。
$ dpconf set-ldap-data-view-prop -h host -p port view-name \ attr-name-mappings+:client-side-attribute-name#server-side-attribute-name |
既存のマッピングリストから属性マッピングを削除するには、次のコマンドを使用します。
$ dpconf set-ldap-data-view-prop -h host -p port view-name \ attr-name-mappings-:client-side-attribute-name#server-side-attribute-name |
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
DN の名前を変更するデータビューの base-dn プロパティーと DN マッピングプロパティーを表示します。
$ dpconf get-ldap-data-view-prop -h host -p port view-name base-dn \ dn-mapping-source-base-dn dn-mapping-attrs |
プロパティーの意味は次のとおりです。
base-dn は、クライアント側のサブツリーの DN で、データビューのベース DN と同じです。
dn-mapping-source-base-dn はサーバー側のサブツリーの DN です。
dn-mapping-attrs はエントリの DN を含む属性の一覧を定義します。
たとえば、DN の名前の変更が定義されていない場合、クライアント側の dc=example,dc=com データベースのデータビューは次の値になります。
$ dpconf get-ldap-data-view-prop myDataView base-dn \ dn-mapping-source-base-dn dn-mapping-attrs base-dn : dc=example,dc=com dn-mapping-attrs : none dn-mapping-source-base-dn : none |
クライアント側の DN をサーバー側の DN にマップします。
$ dpconf set-ldap-data-view-prop -h host -p port view-name \ dn-mapping-source-base-dn:server-side-dn |
たとえば、クライアント側の dc=example,dc=com データベースをサーバー側の dc=example,dc=org にマップします。
$ dpconf set-ldap-data-view-prop -h host1 -p 1389 myDataView \ dn-mapping-source-base-dn:dc=example,dc=org |
手順 2 の影響を受ける DIT の一部で属性に DN が含まれている場合、これらの属性の名前を変更します。
$ dpconf set-ldap-data-view-prop -h host -p port view-name \ dn-mapping-attrs:attribute-name [dn-mapping-attrs:attribute-name ...] |
たとえば、手順 2の名前変更操作に影響を受ける名前空間で group 属性に DN が含まれている場合、次のように属性の名前を変更します。
$ dpconf set-ldap-data-view-prop -h host1 -p 1389 myDataView dn-mapping-attrs:group |
既存のマッピングリストに DN マッピングを追加するには、次のコマンドを使用します。
$ dpconf set-ldap-data-view-prop -h host -p port \ view-name dn-mapping-attrs+:attribute-name |
既存のマッピングリストから DN マッピングを削除するには、次のコマンドを使用します。
$ dpconf set-ldap-data-view-prop -h host -p port \ view-name dn-mapping-attrs-:attribute-name |
DN の名前を変更したデータビューの base-dn プロパティーと DN マッピングプロパティーを表示します。
$ dpconf get-ldap-data-view-prop -h host -p port view-name base-dn \ dn-mapping-source-base-dn dn-mapping-attrs |
たとえば、DN の名前の変更後、クライアント側の dc=example,dc=com データベースのデータビューは次の値になります。
$ dpconf get-ldap-data-view-prop -h host1 -p 1389 myDataView base-dn \ dn-mapping-source-base-dn dn-mapping-attrs base-dn : dc=example,dc=com dn-mapping-attrs : group dn-mapping-source-base-dn : dc=example,dc=org |
下位のデータビューが作成されると、Directory Proxy Server は上位のデータビューから下位のデータビューを自動的に除外します。要求のターゲットが下位のデータビューの場合、要求は上位のデータビューではなく、下位のデータビューに送られます。
下位のデータビューで代替検索ベースが指定されている場合、上位のデータビューをターゲットとした検索操作も下位のデータビューで実行されます。
デフォルトで、Directory Proxy Server は excluded-subtrees プロパティーと alternate-search-base-dn プロパティーを自動的に設定します。次の手順では、これらのプロパティーの手動での設定方法を説明します。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
手動で要求を経路指定するよう Directory Proxy Server を設定します。
$ dpconf set-server-prop -h host -p port data-view-automatic-routing-mode:manual |
data-view-automatic-routing-mode が manual の場合、Directory Proxy Server は excluded-subtrees プロパティーと alternate-search-base-dn プロパティーを生成しません。これらのプロパティーの値は手動で設定する必要があります。ここで設定した値は、Directory Proxy Server で確認されません。これらの値を間違って設定すると、管理パスが壊れる可能性があることに注意してください。
または、要求を部分的に手動で経路指定するように Directory Proxy Server を設定します。
$ dpconf set-server-prop -h host -p port data-view-automatic-routing-mode:limited |
data-view-automatic-routing-mode が limited の場合、Directory Proxy Server は excluded-subtrees プロパティーと alternate-search-base-dn プロパティーを生成しません。ただし、ここで設定した値が管理パスと競合しないか、Directory Proxy Server が確認します。
ビュー除外ベースを設定します。
$ dpconf set-ldap-data-view-prop -h host -p port view-name excluded-subtrees:suffix-DN |
ビュー除外ベースによって、データビューでエントリが公開されない DIT のエントリが決まります。
代替検索ベースを設定します。
$ dpconf set-ldap-data-view-prop -h host -p port view-name \ alternate-search-base-dn:search-base-DN |
代替検索ベースによって、このデータに属しているエントリが配置される DIT のほかのエントリが決まります。ベース DN は、すべてのデータビューで代替検索ベースとしてデフォルトで定義されます。
この節では、データビューの次の情報とその作成および設定方法について説明します。
ここでの例は、接続ハンドラが Directory Proxy Server によって処理されるすべてのクライアント接続を許可していることを前提としています。
プロパティーを設定せずにデータビューを作成すると、データビューは次のような設定になります。
alternate-search-base-dn : "" alternate-search-base-dn : base-DN attr-name-mappings : none base-dn : suffix-DN contains-shared-entries : - description : - distribution-algorithm : - dn-join-rule : - dn-mapping-attrs : none dn-mapping-source-base-dn : none excluded-subtrees : - filter-join-rule : - is-enabled : true is-read-only : false is-routable : true ldap-data-source-pool : pool-name lexicographic-attrs : all lexicographic-lower-bound : none lexicographic-upper-bound : none non-viewable-attr : - non-writable-attr : - numeric-attrs : all numeric-default-data-view : false numeric-lower-bound : none numeric-upper-bound : none pattern-matching-base-object-search-filter : all pattern-matching-dn-regular-expression : all pattern-matching-one-level-search-filter : all pattern-matching-subtree-search-filter : all process-bind : - replication-role : master viewable-attr : all except non-viewable-attr writable-attr : all except non-writable-attr |
この節では、要求のターゲット DN にかかわりなく、要求をすべてデータソースプールに経路指定するデータビューの設定について説明します。このデータビューは、root データビューと呼ばれます。root データビューは、Directory Proxy Server のインスタンスが作成されると、デフォルトで作成されます。root データビューについては、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Data Views to Route All Requests, Irrespective of the Target DN of the Request」を参照してください。
root データビューには次の設定があります。
alternate-search-base-dn : - attr-name-mappings : none base-dn : "" contains-shared-entries : - description : Automatically-generated data view able to route client operations independently of the operation base dn distribution-algorithm : - dn-join-rule : - dn-mapping-attrs : none dn-mapping-source-base-dn : none excluded-subtrees : "" excluded-subtrees : cn=config excluded-subtrees : cn=monitor excluded-subtrees : cn=proxy manager excluded-subtrees : cn=virtual access controls excluded-subtrees : dc=example,dc=com filter-join-rule : - is-enabled : true is-read-only : false is-routable : true ldap-data-source-pool : defaultDataSourcePool lexicographic-attrs : all lexicographic-lower-bound : none lexicographic-upper-bound : none non-viewable-attr : - non-writable-attr : - numeric-attrs : all numeric-default-data-view : false numeric-lower-bound : none numeric-upper-bound : none pattern-matching-base-object-search-filter : all pattern-matching-dn-regular-expression : all pattern-matching-one-level-search-filter : all pattern-matching-subtree-search-filter : all process-bind : - replication-role : master viewable-attr : all except non-viewable-attr writable-attr : all except non-writable-attr |
この節では、サブツリーの一覧をターゲットとする要求をデータ同等のデータソースセットに経路指定するデータビューの設定方法を説明します。このような配備については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Data Views to Route Requests When a List of Subtrees Are Stored on Multiple, Data-Equivalent Data Sources」を参照してください。
ここでの例には、同じサブツリーのセットを含む複数のデータソースが含まれています。データソースはデータと同等で、負荷分散のために 1 つのデータソースプールにプールされます。データビューは、サブツリーをクライアント要求に公開するために、各サブツリーに対して設定されます。次の図は、配備の例を示しています。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
「LDAP データソースの作成と設定」で説明しているように、各 LDAP サーバーにデータソースを作成します。
「LDAP データソースプールの作成と設定」で説明しているように、データソースプールを作成します。
「LDAP データソースのデータソースプールへの接続」で説明しているように、データソースをデータソースプールに接続します。
(省略可能) 負荷分散を設定します。
詳細は、「負荷分散の設定」を参照してください。
dc=example1,dc=com でデータソースプールを参照するベース DN を持つデータビューを作成します。
$ dpconf create-ldap-data-view -h host1 -p 1389 dataview-1 \ data-source-pool-1 dc=example1,dc=com |
dc=example2,dc=com でデータソースプールを参照するベース DN を持つデータビューをもう 1 つ作成します。
$ dpconf create-ldap-data-view -h host1 -p 1389 dataview-2 \ data-source-pool-1 dc=example2,dc=com |
データビューのもう 1 つのプロパティーは、「デフォルトデータビュー」のデフォルトデータビューと同じです。
必要に応じて、変更を有効にするために Directory Proxy Server のインスタンスを再起動します。
Directory Proxy Server の再起動については、「Directory Proxy Server を再起動する」を参照してください。
この節では、異なるサブツリーが異なるデータソースに保存されている場合に単一のアクセスポイントを提供するデータビューを設定する方法を説明します。このような配備については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Data Views to Provide a Single Point of Access When Different Subtrees Are Stored on Different Data Sources」を参照してください。
この節の例では、各サブツリーのデータビューが含まれます。データソースプールは、データ同等のデータソースのセットごとに設定されます。次の図は、配備の例を示しています。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
「LDAP データソースの作成と設定」で説明しているように、各 LDAP サーバーにデータソースを作成します。
「LDAP データソースプールの作成と設定」で説明しているように、2 つのデータソースプールを作成します。
「LDAP データソースのデータソースプールへの接続」で説明しているように、dc=example1,dc=com を含むデータソースを data-source-pool-1 に、dc=example2,dc=com を含むデータソースを data-source-pool-2 に接続します。
(省略可能) 負荷分散を設定します。
詳細は、「負荷分散の設定」を参照してください。
dc=example1,dc=com で data-source-pool-1 を参照するベース DN を持つデータビューを作成します。
$ dpconf create-ldap-data-view -h host1 -p 1389 dataview-1 \ data-source-pool-1 dc=example1,dc=com |
dc=example2,dc=com で data-source-pool-2 を参照するベース DN を持つデータビューをもう 1 つ作成します。
$ dpconf create-ldap-data-view -h host1 -p 1389 dataview-2 \ data-source-pool-1 dc=example2,dc=com |
データビューのもう 1 つのプロパティーは、「デフォルトデータビュー」のデフォルトデータビューと同じです。
必要に応じて、変更を有効にするために Directory Proxy Server のインスタンスを再起動します。
Directory Proxy Server の再起動については、「Directory Proxy Server を再起動する」を参照してください。
この節では、上位サブツリーと下位サブツリーが異なるデータソースに保存される場合に、単一のアクセスポイントを提供するデータビューを設定する方法を説明します。このような配備については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Data Views to Route Requests When Superior and Subordinate Subtrees Are Stored in Different Data Sources」を参照してください。
ここでの例には、3 つのデータビューが含まれます。データビュー 1 のベース DN は、データビュー 2 のベース DN とデータビュー 3 のベース DN より上位です。つまり、データソースプール 2 とデータソースプール 3 にはデータソースプール 1 のサブツリーの下位であるサブツリーが含まれます。次の図は、配備の例を示しています。
下位エントリが別のデータビューのベース DN として設定されると、Directory Proxy Server は、サブツリーの下位エントリをデータビューから自動的に除外します。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
「LDAP データソースの作成と設定」で説明しているように、各 LDAP サーバーにデータソースを作成します。
「LDAP データソースプールの作成と設定」で説明しているように、3 つのデータソースプールを作成します。
「LDAP データソースのデータソースプールへの接続」の指示に従って、データソースをデータソースプールに接続します。
dc=example,dc=com を含むデータソースを data-source-pool-1 に接続します。
ou=computer,dc=example,dc=com を含むデータソースを data-source-pool-2 に接続します。
ou=people,dc=example,dc=com を含むデータソースを data-source-pool-3 に接続します。
(省略可能) 負荷分散を設定します。
詳細は、「負荷分散の設定」を参照してください。
ベース DN を dc=example,dc=com、データソースプールを data-source-pool-1 と指定したデータビューを作成します。
$ dpconf create-ldap-data-view -h host1 -p 1389 dataview-1 \ data-source-pool-1 dc=example,dc=com |
ベース DN を ou=computer,dc=example,dc=com、データソースプールを data-source-pool-2 と指定したデータビューを作成します。
$ dpconf create-ldap-data-view -h host1 -p 1389 dataview-2 \ data-source-pool-2 ou=computer,dc=example,dc=com |
ベース DN を ou=people,dc=example,dc=com、データソースプールを data-source-pool-3 と指定したデータビューを作成します。
$ dpconf create-ldap-data-view -h host1 -p 1389 dataview-3 \ data-source-pool-3 ou=people,dc=example,dc=com |
excluded-subtrees パラメータをチェックして、サブツリー ou=computer,dc=example, dc=com と ou=people,dc=example, dc=com が dataview-1 から除外されていることを確認します。
$ dpconf get-ldap-data-view-prop -h host1 -p 1389 dataview-1 excluded-subtrees |
除外されたサブツリーの一覧が返されます。
必要に応じて、変更を有効にするために Directory Proxy Server のインスタンスを再起動します。
Directory Proxy Server の再起動については、「Directory Proxy Server を再起動する」を参照してください。
この章では、Directory Proxy Server で証明書を設定する方法について説明します。Directory Server での証明書の設定については、「証明書の管理」を参照してください。
この章で説明する手順では、dpadm コマンドと dpconf コマンドを使用します。これらのコマンドについては、dpadm(1M) および dpconf(1M) のマニュアルページを参照してください。
この章の内容は次のとおりです。
Directory Proxy Server インスタンスを作成すると、デフォルトの自己署名付き証明書が組み込まれます。自己署名付き証明書は公開鍵と非公開鍵のペアであり、公開鍵は Directory Proxy Server で自己署名が付けられます。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
Directory Proxy Server で Secure Sockets Layer (SSL) を実行するには、自己署名付き証明書または公開鍵インフラストラクチャー (PKI) ソリューションのいずれかを使用する必要があります。
PKI ソリューションには外部認証局 (CA) が関与します。PKI ソリューションでは CA 署名付きサーバー証明書が必要であり、これには公開鍵と非公開鍵の両方が含まれます。この証明書は、1 つの Directory Proxy Server インスタンスに固有です。また、公開鍵が含まれる「信頼できる CA 証明書」も必要です。信頼できる CA 証明書は、CA からのサーバー証明書はすべて信頼できることを保証します。この証明書は、CA ルート鍵またはルート証明書と呼ばれることもあります。
デフォルト以外の自己署名付き証明書を作成する方法と、CA 署名付き証明書を要求しインストールする方法については、次の手順を参照してください。
Directory Proxy Server インスタンスを作成すると、デフォルトの自己署名付き証明書が自動的に用意されます。デフォルト以外の設定で自己署名付き証明書を作成する場合は、次の手順を使用します。
この手順では、サーバー証明書用の公開鍵と非公開鍵のペアを作成し、公開鍵が Directory Proxy Server によって署名されます。自己署名付き証明書は、3 か月間有効です。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
Directory Proxy Server 用のデフォルト以外の自己署名付き証明書を作成するには、次のように入力します。
$ dpadm add-selfsign-cert instance-path cert-alias |
ここで、cert-alias は自己署名付き証明書の名前です。
たとえば、次のように入力して、 my-self-signed-cert という証明書を作成することもできます。
$ dpadm add-selfsign-cert /local/dps my-self-signed-cert |
すべてのコマンドオプションの説明については、dpadm(1M) のマニュアルページを参照するか、コマンド行で dpadm add-selfsign-cert --help と入力してください。
自己署名付き証明書はテスト目的では便利です。ただし、稼働環境では、信頼できる認証局 (CA) 証明書を使用するほうがより安全です。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
CA 署名付きサーバー証明書を要求します。
$ dpadm request-cert instance-path cert-alias |
ここで、cert-alias は、要求する証明書の名前です。認証局は、サーバーを識別するためにコマンドのすべてのオプションを必要とすることがあります。すべてのコマンドオプションの説明については、dpadm(1M) マニュアルページを参照してください。
CA 証明書を入手するプロセスは、使用する CA によって異なります。商用 CA のなかには、証明書をダウンロードできる Web サイトを備えているものもあります。また、証明書を電子メールで送信する CA もあります。
たとえば、次のように入力して、 my-CA-signed-cert という証明書を要求することもできます。
$ dpadm request-cert -S cn=my-request,o=test /local/dps my-CA-signed-cert -----BEGIN NEW CERTIFICATE REQUEST----- MIIBYDCBygIBADAhMQ0wCwYDVQQDEwRnZXJpMRAwDgYDVQQDEwdteWNlcnQ0MIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQC3v9ubG468wnjBDAMbRrEkmFDTQzT+LO30D/ALLXOiElVsHrtRyWhJ PG9cURI9uwqs15crxCpJvho1kt3SB9+yMB8Ql+CKnCQDHlNAfnn30MjFHShv/sAuEygFsN+Ekci5 W1jySYE2rzE0qKVxWLSILFo1UFRVRsUnORTX/Nas7QIDAQABoAAwDQYJKoZIhvcNAQEEBQADgYEA fcQMnZNLpPobiX1xy1ROefPOhksVz8didY8Q2fjjaHG5lajMsqOROzubsuQ9Xh4ohT8kIA6xcBNZ g8FRNIRAHCtDXKOdOm3CpJ8da+YGI/ttSawIeNAKU1DApF9zMb7c2lS4yEfWmreoQdXIC9YeKtF6 zwbn2EmIpjHzETtS5Nk= -----END NEW CERTIFICATE REQUEST----- |
dpadm request-cert コマンドを使用して 証明書を要求するとき、証明書要求は PEM (Privacy Enhanced Mail) 形式の PKCS #10 証明書要求です。PEM は、RFC 1421 〜 1424 で指定されている形式です。詳細は、http://www.ietf.org/rfc/rfc1421.txt を参照してください。PEM 形式は、base64 形式で符号化された ASCII 形式の証明書要求を表します。
CA 署名付き証明書を要求すると、一時的な自己署名付き証明書が作成されます。CA 署名付き証明書を CA から受信しインストールすると、新しい証明書が一時的な自己署名付き証明書に取って代わります。
その手順に従って、証明書要求を CA に送信します。
証明書要求を送信したら、証明書に関する CA からの回答を待つ必要があります。要求に対する回答が届くまでの時間は、状況によって異なります。たとえば、CA が社内にある場合は、短い時間で回答が届くこともあります。ただし、CA が社外にある場合は、数週間かかることもあります。
CA から受け取った証明書を保存します。
証明書をテキストファイルで保存し、安全な場所に証明書をバックアップします。
CA 署名付きサーバー証明書を信頼するには、証明書を Directory Proxy Server インスタンスにインストールする必要があります。ここで示す手順では、CA 証明書の公開鍵を Directory Proxy Server 上の証明書データベースにインストールします。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
この CA に対する信頼できる CA 証明書がすでにインストール済みかどうかを確認します。
このためには、「CA 証明書を一覧表示する」で示すように、インストールされているすべての CA 証明書をリストします。
信頼できる CA 証明書がインストールされていない場合は、それをDirectory Proxy Server インスタンス上の証明書データベースに追加します。
$ dpadm add-cert instance-path cert-alias cert-file |
ここで、cert-alias は信頼できる CA 証明書の名前で、cert-file は信頼できる CA 証明書が含まれるファイルの名前です。
CA 署名付きサーバー証明書を証明書データベースにインストールします。
$ dpadm add-cert instance-path cert-alias cert-file |
ここで、cert-alias は CA 署名付きサーバー証明書の名前で、cert-file は CA 署名付きサーバー証明書が含まれるファイルの名前です。この cert-alias は、証明書要求で使用した cert-alias と同じでなければなりません。
たとえば、次のように入力して、CA-cert という CA 署名付きサーバー証明書を、/local/dps 上の証明書データベースに追加できます。
$ dpadm add-cert /local/dps CA-cert /local/safeplace/ca-cert-file.ascii |
この節では、期限切れ CA 署名付きサーバー証明書を更新する方法について説明します。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
CA から更新された証明書を入手します。
証明書を Directory Proxy Server のインスタンスにインストールします。
$ dpadm renew-cert instance-path cert-alias cert-file |
ここで、cert-alias は新しい証明書の名前で、cert-file は証明書が含まれるファイルの名前です。すべてのコマンドオプションについては、dpadm(1M) のマニュアルページを参照してください。
サーバーと CA 証明書を一覧表示する方法については、次の手順を参照してください。
ここで示す手順では、Directory Proxy Server の 1 つのインスタンスにインストールされているすべての証明書を一覧表示します。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
Directory Proxy Server インスタンスにある証明書データベース内のサーバー証明書を一覧表示します。
$ dpadm list-certs instance-path |
デフォルトでは、Directory Proxy Server のインスタンスには、defaultservercert というサーバー証明書が含まれます。Same as issuer は、デフォルト証明書が自己署名付きサーバー証明書であることを示します。
次に例を示します。
$ dpadm list-certs /local/dps Alias Valid from Expires on Self-signed? Issued by Issued to ----------------- ---------------- ---------------- ------------ ------------------ -------------- defaultservercert 2006/06/01 04:15 2008/05/31 04:15 y CN=myserver:myport Same as issuer 1 certificate found. |
ここで示す手順では、Directory Proxy Server の 1 つのインスタンスにインストールされている CA 証明書を一覧表示します。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
Directory Proxy Server インスタンスにある証明書データベース内の CA 証明書を一覧表示します。
$ dpadm list-certs -C instance-path |
次に例を示します。
$ dpadm list-certs -C /local/dps Alias Valid from Expires on Built-in Issued by Issued to ------ ---------- ---------------- --------- --------- --------- CAcert1 1999/06/21 06:00 2020/06/21 06:00 y CN=company1, O=company2 ... |
この節では、証明書をバックエンド LDAP サーバーから Directory Proxy Server 上の証明書データベースに追加する方法について説明します。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
次のコマンド構文を使用して、 PEM 形式のバックエンドディレクトリサーバーからの証明書を表示します。
dsadm show-cert -F ascii instance-path [cert-alias] |
cert-alias を指定しないと、デフォルトのサーバー証明書が表示されます。すべてのコマンドオプションについては、dsadm(1M) のマニュアルページを参照してください。
たとえば、次のように入力して、デフォルトの自己署名付きサーバー証明書を表示します。
$ dsadm show-cert -F ascii /local/ds defaultCert -----BEGIN CERTIFICATE----- MIICJjCCAY+gAwIBAgIFAIKL36kwDQYJKoZIhvcNAQEEBQAwVzEZMBcGA1UEChMQ U3VuIE1pY3Jvc3lzdGVtczEZMBcGA1UEAxMQRGlyZWN0b3J5IFNlcnZlcjENMAsG A1UEAxMEMjAxMTEQMA4GA1UEAxMHY29uZHlsZTAeFw0wNjA1MjIxMTQxNTVaFw0w NjA4MjIxMTQxNTVaMFcxGTAXBgNVBAoTEFN1biBNaWNyb3N5c3RlbXMxGTAXBgNV BAMTEERpcmVjdG9yeSBTZXJ2ZXIxDTALBgNVBAMTBDIwMTExEDAOBgNVBAMTB2Nv bmR5bGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAK9U3ry3sJmEzwQY8CGd 7S2MTZuBedo03Vea1lfDtD08WIsdDMzhHplTdeHAkWWNc8g2PDcEFXeWp9UXFMuD Pcia7t8HtFkm73VmlriWhMd8nn3l2vkxhsPK2LHFEeOIUDR9LBBiMiEeLkjdoEhE VLMSoYKqKI+Aa5grINdmtFzBAgMBAAEwDQYJKoZIhvcNAQEEBQADgYEAF4eDbSd7 qy2l10dIogT+rnXZ362gLTlQFCblhbGpmmptbegUdL1ITGv/62q1isPV2rW7CkjM Cqb0fo3k5UkKKvW+JbMowpQeAPnlgpX612HuDr1tldnKV4eyU7gpG31t/cpACALQ 7OPi1A7oVb2Z8OJKfEJHkp3txBSsiI2gTkk= -----END CERTIFICATE----- |
証明書を保存します。
証明書をテキストファイルで保存し、安全な場所に証明書をバックアップします。
証明書をバックエンド LDAP サーバーから Directory Proxy Server のインスタンス上の証明書データベースに追加します。
$ dpadm add-cert instance-path cert-alias cert-file |
ここで、cert-alias は証明書の名前で、cert-file は証明書に含まれるファイルの名前です。
たとえば、証明書 defaultCert は次のようにして追加できます。
$ dpadm add-cert /local/dps defaultCert /local/safeplace/defaultCert.ascii |
バックエンド LDAP サーバーは、Directory Proxy Server からの証明書を必要とすることがあります。この節では、証明書をバックエンド LDAP サーバーにエクスポートするように Directory Proxy Server を設定する方法について説明します。
バックエンド LDAP サーバーに送信する証明書を指定します。
$ dpconf set-server-prop -h host -p port ssl-client-cert-alias:cert-alias |
ここで、cert-alias は証明書の名前です。すべてのコマンドオプションについては、dpconf(1M) のマニュアルページを参照してください。
証明書の内容をファイルにコピーします。
$ dpadm show-cert -F ascii -o filename instance-path cert-alias |
「CA 署名付きサーバー証明書と信頼できる CA 証明書を追加する」で示すように、証明書をバックエンド LDAP サーバーの証明書データベースに追加します。
バックエンド LDAP サーバーをクライアント認証用に設定します。Directory Server 用にこれを行う方法については、「資格レベルと認証方法の設定」を参照してください。
クライアントと Directory Proxy Server 間の証明書ベースの認証の設定については、「証明書ベースの認証を設定する」を参照してください。
サーバー証明書は、dpadm を使って Directory Proxy Server をバックアップするときにバックアップされます。バックアップされた証明書は、 archive-path/alias ディレクトリに格納されます。
Directory Proxy Server のバックアップと復元の方法については、「Directory Proxy Server インスタンスのバックアップと復元」を参照してください。
デフォルトでは、証明書データベース用のパスワードは内部的に管理されます。したがって、証明書パスワードを入力したりパスワードファイルを指定したりする必要はありません。証明書データベースが格納されているパスワードによって内部的に管理されている場合、パスワードは安全な環境に格納されます。
証明書のセキュリティーを高め、さらに管理するためには、コマンド行でパスワードの入力を要求するように Directory Proxy Server を設定します。それにより、すべての dpadm サブコマンドに対してパスワードの入力を要求されます。ただし、autostart、backup、disable-service、enable-service、info、restore、および stop は除きます。
パスワードの入力を要求する、または要求しないという Directory Proxy Server の設定の詳細は、次の手順を参照してください。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
サーバーを停止します。
$ dpadm stop instance-path Directory Proxy Server instance 'instance-path' stopped |
パスワードプロンプトフラグを on に設定してから、証明書データベースのパスワードを入力し、確認します。
$ dpadm set-flags instance-path cert-pwd-prompt=on Choose the certificate database password: Confirm the certificate database password: |
サーバーを起動してから、証明書データベースのパスワードを入力します。
$ dpadm start instance-path Enter the certificate database password: |
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
サーバーを停止します。
$ dpadm stop instance-path Directory Proxy Server instance 'instance-path' stopped |
パスワードプロンプトフラグを off に設定してから、既存のパスワードを入力します。
$ dpadm set-flags instance-path cert-pwd-prompt=off Enter the old password: |
次のように入力して、Server を起動します。
$ dpadm start instance-path |
負荷分散とクライアントアフィニティーについては、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 16 章「Directory Proxy Server Load Balancing and Client Affinity」を参照してください。この章の内容は次のとおりです。
負荷分散の詳細は、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Load Balancing」を参照してください。この節では、負荷分散を設定する方法について説明し、設定例を示します。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
LDAP データソースプールのプロパティーを表示することで、現在の負荷分散アルゴリズムを取得します。
$ dpconf get-ldap-data-source-pool-prop -h host -p port pool-name |
LDAP データソースプールのデフォルトプロパティーは次のとおりです。
client-affinity-policy : write-affinity-after-write client-affinity-timeout : 20s description : - enable-client-affinity : false load-balancing-algorithm : proportional |
デフォルトでは、負荷分散アルゴリズムは proportional です。
アルゴリズムを使用するように LDAP データソースプールを設定します。
$ dpconf set-ldap-data-source-pool-prop -h host -p port pool-name \ load-balancing-algorithm:selected-algorithm |
ここで、selected-algorithm は次のいずれかです。
failover
operational-affinity
proportional
saturation
アルゴリズムの詳細は、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Introduction to Load Balancing」を参照してください。
Directory Proxy Server のインスタンスを再起動します。
$ dpadm restart instance-path |
データソースのウェイトは、データソースプールに接続されているほかのすべてのデータソースのウェイトを考慮して設定する必要があります。データソースに操作のタイプに対して disabled のウェイトがある場合、そのタイプの要求がそのデータソースに送信されることはありません。データソースにウェイト 0 (ゼロ) がある場合、そのデータソースには要求は配信されません。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
データソースプールに接続されているデータソースのリストを表示します。
$ dpconf list-attached-ldap-data-sources -h host -p port pool-name |
接続済みデータソースのいずれかのプロパティーを表示します。
$ dpconf get-attached-ldap-data-source-prop pool-name \ attached-data-source-name |
接続済みデータソースのプロパティーは、各タイプの操作に対するウェイトを定義します。接続済みデータソースのデフォルトウェイトは次のとおりです。
add-weight : disabled bind-weight : disabled compare-weight : disabled delete-weight : disabled modify-dn-weight : disabled modify-weight : disabled search-weight : disabled |
接続済みデータソースのいずれかのウェイトを設定します。
$ dpconf set-attached-ldap-data-source-prop -h host -p port pool-name \ attached-data-source-name add-weight:value \ bind-weight:value compare-weight:value delete-weight:value \ modify-dn-weight:value modify-weight:value search-weight:value |
接続済みデータソースのキーパラメータを比較します。
$ dpconf list-attached-ldap-data-sources -h host -p port -v pool-name |
たとえば、データソースプールには、次のようなウェイトを持つデータソースを含めることができます。
$ dpconf list-attached-ldap-data-sources -h host1 -p 1389 -v myPool SRC_NAME add-weight bind-weight compare-weight delete-weight -------- ---------- ----------- -------------- ------------- DS-1 disabled 3 disabled disabled DS-2 2 2 2 2 DS-3 1 1 1 1 modify-dn-weight modify-weight search-weight ---------------- ------------- ------------- disabled disabled disabled 2 2 2 1 1 1 |
この節では、各負荷分散アルゴリズムの設定手順の例を示します。
比例アルゴリズムについては、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Proportional Algorithm for Load Balancing」を参照してください。
この例では、データソース ds–1 が、他の 2 つのデータソースのウェイトの 2 倍に設定されます。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
データソースプールに少なくとも 3 つの接続済みデータソースが含まれていることを確認します。データソースとデータソースプールを作成する方法については、「LDAP データビューの作成」を参照してください。
負荷分散に対して比例アルゴリズムを使用するようにデータソースプールを設定します。
$ dpconf set-ldap-data-source-pool-prop -h host -p port pool-name \ load-balancing-algorithm:proportional |
最初のデータソースのプロパティーを設定します。
$ dpconf set-attached-ldap-data-source-prop -h host -p port pool-name ds-1 \ add-weight:2 bind-weight:2 compare-weight:2 delete-weight:2 modify-dn-weight:2 \ modify-weight:2 search-weight:2 |
2 番目のデータソースのプロパティーを設定します。
$ dpconf set-attached-ldap-data-source-prop -h host -p port pool-name ds-2 \ add-weight:1 bind-weight:1 compare-weight:1 delete-weight:1 modify-dn-weight:1 \ modify-weight:1 search-weight:1 |
3 番目のデータソースのプロパティーを設定します。
$ dpconf set-attached-ldap-data-source-prop -h host -p port pool-name ds-3 \ add-weight:1 bind-weight:1 compare-weight:1 delete-weight:1 modify-dn-weight:1 \ modify-weight:1 search-weight:1 |
接続済みデータソースのキーパラメータを比較します。
$ dpconf list-attached-ldap-data-sources -h host -p port -v pool-name SRC_NAME add-weight bind-weight compare-weight delete-weight -------- ---------- ----------- -------------- ------------- ds-1 2 2 2 2 ds-2 1 1 1 1 ds-3 1 1 1 1 modify-dn-weight modify-weight search-weight ---------------- ------------- ------------- 2 2 2 1 1 1 1 1 1 |
Directory Proxy Server のインスタンスを再起動します。
$ dpadm restart instance-path |
飽和アルゴリズムについては、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Saturation Algorithm for Load Balancing」を参照してください。
この例では、データソース ds-1 で大半のバインド操作が実行されますが、ほかのタイプの操作は実行されません。3 つのデータソースが次のウェイトによって設定されます。
ds-1 は、バインド操作に対してウェイト 3 を持つよう設定され、他のすべてのタイプの操作に対しては無効です。
ds-2 は、すべての操作に対してウェイト 2 を持つよう設定されます。
ds-3 は、すべての操作に対してウェイト 1 を持つよう設定されます。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
データソースプールに少なくとも 3 つの接続済みデータソースが含まれていることを確認します。データソースとデータソースプールを作成する方法については、「LDAP データビューの作成」を参照してください。
負荷分散に対して飽和アルゴリズムを使用するようにデータソースプールを設定します。
$ dpconf set-ldap-data-source-pool-prop -h host -p port pool-name \ load-balancing-algorithm:saturation |
最初のデータソースのプロパティーを設定します。
$ dpconf set-attached-ldap-data-source-prop -h host -p port pool-name ds-1 \ add-weight:disabled bind-weight:3 compare-weight:disabled delete-weight:disabled \ modify-dn-weight:disabled modify-weight:disabled search-weight:disabled |
2 番目のデータソースのプロパティーを設定します。
$ dpconf set-attached-ldap-data-source-prop -h host -p port pool-name ds-2 \ add-weight:2 bind-weight:2 compare-weight:2 delete-weight:2 modify-dn-weight:2 \ modify-weight:2 search-weight:2 |
3 番目のデータソースのプロパティーを設定します。
$ dpconf set-attached-ldap-data-source-prop -h host -p port pool-name ds-3 \ add-weight:1 bind-weight:1 compare-weight:1 delete-weight:1 modify-dn-weight:1 \ modify-weight:1 search-weight:1 |
接続済みデータソースのキーパラメータを比較します。
$ dpconf list-attached-ldap-data-sources -h host -p port -v pool-name SRC_NAME add-weight bind-weight compare-weight delete-weight -------- ---------- ----------- -------------- ------------- ds-1 disabled 3 disabled disabled ds-2 2 2 2 2 ds-3 1 1 1 1 modify-dn-weight modify-weight search-weight ---------------- ------------- ------------- disabled disabled disabled 2 2 2 1 1 1 |
Directory Proxy Server のインスタンスを再起動します。
$ dpadm restart instance-path |
このアルゴリズムについては、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Operational Affinity Algorithm for Global Account Lockout」を参照してください。
この例には、3 つのデータソースがあります。データソース ds-1 は、すべてのバインド要求を受信するように設定されます。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
データソースプールに少なくとも 3 つの接続済みデータソースが含まれていることを確認します。データソースとデータソースプールを作成する方法については、「LDAP データビューの作成」を参照してください。
アフィニティーアルゴリズムを使用するようにデータソースプールを設定します。
$ dpconf set-ldap-data-source-pool-prop -h host -p port pool-name \ load-balancing-algorithm:operational-affinity |
最初のデータソースのプロパティーを設定します。
$ dpconf set-attached-ldap-data-source-prop -h host -p port pool-name ds-1 \ add-weight:1 bind-weight:100 compare-weight:1 delete-weight:1 modify-dn-weight:1 \ modify-weight:1 search-weight:1 |
2 番目のデータソースのプロパティーを設定します。
$ dpconf set-attached-ldap-data-source-prop -h host -p port pool-name ds-2 \ add-weight:1 bind-weight:1 compare-weight:1 delete-weight:1 modify-dn-weight:1 \ modify-weight:1 search-weight:1 |
3 番目のデータソースのプロパティーを設定します。
$ dpconf set-attached-ldap-data-source-prop -h host -p port pool-name ds-3 \ add-weight:1 bind-weight:1 compare-weight:1 delete-weight:1 modify-dn-weight:1 \ modify-weight:1 search-weight:1 |
接続済みデータソースのキーパラメータを比較します。
$ dpconf list-attached-ldap-data-sources -h host -p port -v pool-name SRC_NAME add-weight bind-weight compare-weight delete-weight -------- ---------- ----------- -------------- ------------- ds-1 1 100 1 1 ds-2 1 1 1 1 ds-3 1 1 1 1 modify-dn-weight modify-weight search-weight ---------------- ------------- ------------- 1 1 1 1 1 1 1 1 1 |
Directory Proxy Server のインスタンスを再起動します。
$ dpadm restart instance-path |
このアルゴリズムについては、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Operational Affinity Algorithm for Cache Optimization」を参照してください。
この例には、3 つのデータソースがあります。すべての検索操作と比較操作は、データソース ds-1 で処理されます。ds-1 が要求に応答すると、ターゲットエントリがキャッシュ内に格納されます。ds-1 が同じ要求に繰り返し応答する場合、データソースはキャッシュに入れられたデータを使用できます。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
データソースプールに少なくとも 3 つの接続済みデータソースが含まれていることを確認します。データソースとデータソースプールを作成する方法については、「LDAP データビューの作成」を参照してください。
アフィニティーアルゴリズムを使用するようにデータソースプールを設定します。
$ dpconf set-ldap-data-source-pool-prop -h host -p port pool-name \ load-balancing-algorithm:operational-affinity |
最初のデータソースのプロパティーを設定します。
$ dpconf set-attached-ldap-data-source-prop -h host -p port pool-name ds-1 \ add-weight:1 bind-weight:1 compare-weight:100 delete-weight:1 modify-dn-weight:1 \ modify-weight:1 search-weight:100 |
2 番目のデータソースのプロパティーを設定します。
$ dpconf set-attached-ldap-data-source-prop -h host -p port pool-name ds-2 \ add-weight:1 bind-weight:1 compare-weight:1 delete-weight:1 modify-dn-weight:1 \ modify-weight:1 search-weight:1 |
3 番目のデータソースのプロパティーを設定します。
$ dpconf set-attached-ldap-data-source-prop -h host -p port pool-name ds-3 \ add-weight:1 bind-weight:1 compare-weight:1 delete-weight:1 modify-dn-weight:1 \ modify-weight:1 search-weight:1 |
接続済みデータソースのキーパラメータを比較します。
$ dpconf list-attached-ldap-data-sources -h host -p port -v pool-name SRC_NAME add-weight bind-weight compare-weight delete-weight -------- ---------- ----------- -------------- ------------- ds-1 1 1 100 1 ds-2 1 1 1 1 ds-3 1 1 1 1 modify-dn-weight modify-weight search-weight ---------------- ------------- ------------- 1 1 100 1 1 1 1 1 1 |
Directory Proxy Server のインスタンスを再起動します。
$ dpadm restart instance-path |
フェイルオーバーアルゴリズムについては、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Failover Algorithm for Load Balancing」を参照してください。
この例には、3 つのデータソースがあります。データソース ds-1 はすべての要求を受信します。ds-1 が失敗した場合は、ds-1 が回復するまで ds-2 がすべての要求を受信します。ds-1 が回復する前に ds-2 が失敗した場合は、ds-3 がすべての要求を受信します。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
データソースプールに少なくとも 3 つの接続済みデータソースが含まれていることを確認します。データソースとデータソースプールを作成する方法については、「LDAP データビューの作成」を参照してください。
負荷分散に対してフェイルオーバーアルゴリズムを使用するように、データソースプールを設定します。
$ dpconf set-ldap-data-source-pool-prop -h host -p port pool-name \ load-balancing-algorithm:failover |
最初のデータソースのプロパティーを設定します。
$ dpconf set-attached-ldap-data-source-prop -h host -p port pool-name ds-1 \ add-weight:3 bind-weight:3 compare-weight:3 delete-weight:3 modify-dn-weight:3 \ modify-weight:3 search-weight:3 |
2 番目のデータソースのプロパティーを設定します。
$ dpconf set-attached-ldap-data-source-prop -h host -p port pool-name ds-2 \ add-weight:2 bind-weight:2 compare-weight:2 delete-weight:2 modify-dn-weight:2 \ modify-weight:2 search-weight:2 |
3 番目のデータソースのプロパティーを設定します。
$ dpconf set-attached-ldap-data-source-prop -h host -p port pool-name ds-3 \ add-weight:1 bind-weight:1 compare-weight:1 delete-weight:1 modify-dn-weight:1 \ modify-weight:1 search-weight:1 |
接続済みデータソースのキーパラメータを比較します。
$ dpconf list-attached-ldap-data-sources -h host -p port -v pool-name SRC_NAME add-weight bind-weight compare-weight delete-weight -------- ---------- ----------- -------------- ------------- ds-1 3 3 3 3 ds-2 2 2 2 2 ds-3 1 1 1 1 modify-dn-weight modify-weight search-weight ---------------- ------------- ------------- 3 3 3 2 2 2 1 1 1 |
Directory Proxy Server のインスタンスを再起動します。
$ dpadm restart instance-path |
単純な負荷分散の例として、検索操作と比較操作を 1 つのディレクトリセットに送信し、その他の操作をもう 1 つのディレクトリセットに送信します。Directory Proxy Server は、すべてのクライアント操作を受け取ります。Directory Proxy Server は、読み取りを取得するディレクトリセットとその他の操作を取得するディレクトリセットを判別する必要があります。
Directory Proxy Server でこの負荷分散を処理するための設定の主要な手順は次のとおりです。
Directory Proxy Server 用のデータソースとしてディレクトリを追加します。
それらのデータソースをデータソースプールに追加します。
それらのデータソースのいくつかで検索と比較の操作を受け入れるように設定し、残りのデータソースで追加、バインド、削除、変更、および DN 変更の操作を受け入れるように設定します。
データソースプールをデータビューに追加します。
次の例では、Directory Proxy Server はポート 9389 で待機しています。この例では、記述されているように、検索操作と比較操作を処理する Directory Server インスタンス (ds1:1389) と、その他の操作を処理する Directory Server インスタンス (ds2:2389 ) に負荷を分散するようにプロキシを設定します。
最初の手順では、データソースを作成し、そのデータソースを有効にします。この手順では、プロキシサーバーを再起動する必要があります。
$ dpconf create-ldap-data-source -p 9389 ds1 localhost:1389 $ dpconf create-ldap-data-source -p 9389 ds2 localhost:2389 $ dpconf set-ldap-data-source-prop -p 9389 ds1 is-enabled:true $ dpconf set-ldap-data-source-prop -p 9389 ds2 is-enabled:true $ dpadm restart /local/dps |
2 番目の手順では、データソースをデータソースプールに追加します。
$ dpconf create-ldap-data-source-pool -p 9389 "Directory Pool" $ dpconf attach-ldap-data-source -p 9389 "Directory Pool" ds1 ds2 |
3 番目の手順では、ds1 が検索操作と比較操作を受け入れ、ds2 がその他の操作を受け入れるように設定します。
$ dpconf set-attached-ldap-data-source-prop -p 9389 "Directory Pool" ds1 \ add-weight:disabled bind-weight:disabled compare-weight:1 delete-weight:disabled \ modify-dn-weight:disabled modify-weight:disabled search-weight:1 $ dpconf set-attached-ldap-data-source-prop -p 9389 "Directory Pool" ds2 \ add-weight:1 bind-weight:1 compare-weight:disabled delete-weight:1 \ modify-dn-weight:1 modify-weight:1 search-weight:disabled |
4 番目の手順では、クライアントアプリケーション要求がデータソースプールに経路指定されるように、そのプールをデータビューに追加します。
$ dpconf create-ldap-data-view -p 9389 "Balanced View" "Directory Pool" \ dc=example,dc=com |
クライアントアフィニティーにより、負荷分散された配備での伝播遅延のリスクが削減されます。クライアントアフィニティーについては、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Client Affinity」を参照してください。この節では、クライアント接続とデータソース間のアフィニティーを設定する方法を説明し、設定例を示します。
この手順では、クライアント接続とデータソース間のアフィニティーを設定する方法について説明します。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
データソースプールのプロパティーを表示することで、現在の負荷分散アルゴリズムを表示します。
$ dpconf get-ldap-data-source-pool-prop -h host -p port pool-name |
データソースプールのデフォルトプロパティーは、次のとおりです。
client-affinity-policy : write-affinity-after-write client-affinity-timeout : 20s description : - enable-client-affinity : false load-balancing-algorithm : proportional |
次のパラメータは、クライアントアフィニティーを設定します。client-affinity-policy 、client-affinity-timeout、enable-client-affinity 。プロパティーの詳細とそれらの有効な値のリストについては、次のように入力します。
dpconf help-properties ldap-data-source-pool client-affinity-policy \ client-affinity-timeout enable-client-affinity |
プロパティーの詳細は、次のマニュアルページを参照してください。client-affinity-policy(5dpconf)、client-affinity-timeout(5dpconf)、および enable-client-affinity(5dpconf)。
クライアントアフィニティーを有効にします。
$ dpconf set-ldap-data-source-pool-prop -h host -p port pool-name \ enable-client-affinity:true |
クライアントアフィニティーに対するポリシーを選択します。
$ dpconf set-ldap-data-source-pool-prop -h host -p port pool-name \ client-affinity-policy:selected-policy |
ここで、selected-policy は次のいずれかです。
最初の書き込み要求のあとの書き込み要求に対するアフィニティー
最初の書き込み要求のあとのすべての要求に対するアフィニティー
最初の読み取り要求または書き込み要求のあとのすべての要求に対するアフィニティー
書き込み要求のあとの最初の読み取り要求に対するアフィニティー
クライアントアフィニティーの期間を設定します。
$ dpconf set-ldap-data-source-pool-prop -h host -p port pool-name \ client-affinity-timeout:time-out[unit] |
タイムアウトのデフォルトの unit はミリ秒です。
この節では、クライアントアフィニティーに関連する設定の例を示し、レプリケーションの遅延、書き込み操作の検証、接続ベースのルーティングの例を示します。
この手順では、最初の書き込み操作後、3 秒までの間に行われるすべての読み取り操作と書き込み操作に対するクライアントアフィニティーを設定します。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
データソースプールのアフィニティーパラメータを設定します。
$ dpconf set-ldap-data-source-pool-prop -h host -p port pool-name \ client-affinity-policy:read-write-affinity-after-write client-affinity-timeout:3000 \ enable-client-affinity:true |
この手順では、それぞれの書き込み操作のあとの最初の読み取り操作に対するクライアントアフィニティーを設定します。例は、読み取り操作を行うことで指定した DN がそれぞれの書き込み操作の妥当性検査を行うアプリケーションの場合もあります。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
データソースプールのアフィニティーパラメータを設定します。
$ dpconf set-ldap-data-source-pool-prop -h host -p port pool-name \ client-affinity-policy:read-affinity-after-write enable-client-affinity:true |
Directory Proxy Server 6.0 より前のバージョンでは、クライアントと LDAP サーバー間で確立される接続数は 1 つです。この接続が閉じられるまで、クライアントからのすべての要求に使用されました。このタイプのルーティングを、connection-based routing といいます。この手順では、接続ベースのルーティングに対してクライアントアフィニティーを設定する方法について説明します。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
すべてのデータソースがデータソースプールに接続されていて、client-cred-mode が use-client-identity に設定されていることを確認します。
データソースプールのアフィニティーパラメータを設定します。
$ dpconf set-ldap-data-source-pool-prop -h host -p port pool-name \ client-affinity-policy:read-write-affinity-after-any enable-client-affinity:true |
Directory Proxy Server では、データビューの定義によってデータ配布を行うことができます。データビューは、そのデータビュー内のエントリのベース DN を決定するビューベースを使って定義されます。Directory Proxy Server に用意されている配布アルゴリズムに基づいて、エントリをさまざまなデータビュー間で分割する方法を指定できます。
Directory Proxy Server によるデータ配布の概要とユースケースの例の説明については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 17 章「Directory Proxy Server Distribution」を参照してください。
この章の内容は次のとおりです。
Directory Proxy Server には、次の配布アルゴリズムが用意されています。
パターンマッチング
数値
辞書式
レプリケーション
カスタム
Directory Proxy Server では、要求のパラメータと 1 つ以上のパターンの間の一致に基づいて、要求をデータビューに配布します。次のパラメータを設定して、パターンマッチング配布アルゴリズムの設定を行います。
pattern-matching-base-object-search-filter pattern-matching-base-object-search-filter(5dpconf)
pattern-matching-dn-regular-expression pattern-matching-dn-regular-expression(5dpconf)
pattern-matching-one-level-search-filter pattern-matching-one-level-search-filter(5dpconf)
pattern-matching-subtree-search-filter pattern-matching-subtree-search-filter(5dpconf)
filter で終わる設定属性は LDAP フィルタであり、正規表現ではありません。これらの LDAP フィルタは、受信検索要求に含まれる LDAP フィルタに対して評価されます。
たとえば、偶数の uid を持つユーザーの要求を even データビューに、奇数の uid を持つユーザーの要求を odd データビューに送信するようにパターンマッチング配布アルゴリズムを設定するときは、次の設定を使用します。
$ dpconf set-ldap-data-view-prop even pattern-matching-base-object-search-filter:'|(uid=\2a)(uid=*0)(uid=*2)\ (uid=*4)(uid=*6)(uid=*8))'\ pattern-matching-one-level-search-filter:'|(uid=\2a)(uid=*0)(uid=*2)\ (uid=*4)(uid=*6)(uid=*8))'\ pattern-matching-subtree-search-filter:'|(uid=\2a)(uid=*0)(uid=*2)\ (uid=*4)(uid=*6)(uid=*8))'\ pattern-matching-dn-regular-expression:'uid=[0-9]+[02468]' distribution-algorithm: pattern-matching |
$ dpconf set-ldap-data-view-prop odd pattern-matching-base-object-search-filter:'|(uid=\2a)(uid=*1)(uid=*3)\ (uid=*5)(uid=*7)(uid=*9))'\ pattern-matching-one-level-search-filter:'|(uid=\2a)(uid=*1)(uid=*3)\ (uid=*5)(uid=*7)(uid=*9))'\ pattern-matching-subtree-search-filter:'|(uid=\2a)(uid=*1)(uid=*3)\ (uid=*5)(uid=*7)(uid=*9))'\ pattern-matching-dn-regular-expression:'uid=[0-9]+[13579]' distribution-algorithm: pattern-matching |
(uid=\2a) の式で、\2a は * の ASCII 表現であり、2 および a は 2 つの 16 進数字です。(uid=\2a) の式により、データビューがすべての uid の要求を確実に受け入れるようになります。
パターンマッチングアルゴリズムでサポートされる構文は、Java パターンクラス (http://java.sun.com/j2se/1.4.2/docs/api/java/util/regex/Pattern.html で説明されています) によって指定されます。この構文は、通常の regex 構文と同じではありません。
Directory Proxy Server では、要求内の RDN の数値に応じて、要求をデータビューに配布します。この数値は、データビューのベース DN の下にある最初の RDN の値から取られます。次のパラメータを設定して、数値の範囲を定義します。
numeric-attrs numeric-attrs(5dpconf)
numeric-default-data-view numeric-default-data-view(5dpconf)
numeric-lower-bound numeric-lower-bound(5dpconf)
numeric-upper-bound numeric-upper-bound(5dpconf)
たとえば、0 から 99 の間の uid の要求を特定のデータビューに送信する数値配布アルゴリズムを設定できます。残りのユーザーでも同じ構文を使用しますが、データビューは異なります。
$ dpconf set-ldap-data-view-prop dataview distribution-algorithm:numeric \ numeric-attrs:uid numeric-lower-bound:0 numeric-upper-bound:99 |
Directory Proxy Server では、要求内の RDN の辞書式の値に応じて、要求をデータビューに配布します。辞書式の範囲は、データビューのベース DN の下にある最初の RDN の値から取られます。次のパラメータを設定して、辞書式の範囲を定義します。
lexicographic-attrs lexicographic-attrs(5dpconf)
lexicographic-lower-bound lexicographic-lower-bound(5dpconf)
lexicographic-upper-bound lexicographic-upper-bound(5dpconf)
たとえば、名前が A から M の間で始まるユーザーの要求をあるデータビューに送信し、残りのユーザの要求を別のデータビューに送信する辞書式配布アルゴリズムを設定できます。
$ dpconf set-ldap-data-view-prop dataview distribution-algorithm:lexicographic \ lexicographic-attrs:cn lexicographic-lower-bound:A lexicographic-upper-bound:M |
Directory Proxy Server では、レプリケーションにおけるデータビューのロールに応じて、要求をデータビューに配布します。このアルゴリズムでは、書き込み操作はデータソースプール内のすべてのデータソースに配布され、読み取り操作は 1 つのデータソースに配布されます。レプリケーションロールは、replication-role パラメータによって定義されます。データビューには、マスターロールまたはコンシューマロールを設定できます。
$ dpconf set-ldap-data-view-prop dataview distribution-algorithm:replication |
全種類のデータビュー (ldap-data-view、jdbc-data-view、ldif-data-view、および join-data-view) でカスタム配布アルゴリズムを設定できます。次の手順では、このアルゴリズムを ldap-data-view だけで設定します。
配布アルゴリズムクラスが格納された Java Archive (JAR) ファイルのパスが含まれるように extension-jar-file-url プロパティーを設定します。
$ dpconf set-server-prop -h host -p port extension-jar-file-url:jar file path |
jar file path を、file:/expt/dps/custom_plugin/myjar.jar のような有効な JAR ファイルパスに置き換えることができます。
custom-distribution-algorithm を設定する前に、distribution-algorithm を none に設定します。
$ dpconf set-ldap-data-view-prop view name distribution-algorithm:none |
custom-distribution-algorithm プロパティーをカスタム配布アルゴリズムクラスに設定します。
$ dpconf set-ldap-data-view-prop view name custom-distribution-algorithm:PackageName.AlgoClassName |
単純なデータ配布の例として、A から M までの文字で始まる UID を持つエントリを 1 つのディレクトリセットに格納し、N から Z までの文字で始まる UID を持つエントリをもう 1 つのディレクトリセットに格納します。Directory Proxy Server は、すべてのクライアント操作を受け取ります。Directory Proxy Server は、A から M を処理するディレクトリセットと N から Z を処理するディレクトリセットを判別する必要があります。
Directory Proxy Server でこのデータ配布を処理するための設定の主要な手順は次のとおりです。
Directory Proxy Server 用のデータソースとしてディレクトリを追加します。
それらのデータソースを、各データ配布を処理するデータソースプールに追加します。
クライアント要求を適切なデータプールに配布するためのデータビューを作成します。
適切なデータソースに読み込まれるように LDIF を分割します。
分割した LDIF を適切なデータソースにインポートします。
適切なデータプールに接続されたデータソースごとに、操作ベースのウェイトを調整します。
次の例では、Directory Proxy Server はポート 9389 で待機しています。単純にするため、この例では、記述されているように 3 つの Directory Server インスタンスのみに配布するようにプロキシが設定されています。可用性と読み取りのスケーラビリティーを確保するため、レプリケートされたディレクトリトポロジを使用して LDAP データを格納します。一方の Directory Server インスタンス (dsA-M:1389) は、A から M までの文字で始まる UID を持つユーザーエントリを処理します。もう一方の Directory Server インスタンス (dsN-Z:2389) は、N から Z までの文字で始まる UID を持つユーザーエントリを処理します。最後のディレクトリインスタンス (dsBase:3389) は、サフィックスのベースエントリを処理します。
最初の手順では、データソースを作成して有効にします。ベースデータソースは、UID を持たない、サフィックスのルートに近いエントリを保持します。一般的な配備では、これらのエントリは、配布されるエントリよりもずっと少数です。
$ dpconf create-ldap-data-source -p 9389 dsA-M localhost:1389 $ dpconf set-ldap-data-source-prop -p 9389 dsA-M is-enabled:true $ dpconf create-ldap-data-source -p 9389 dsN-Z localhost:2389 $ dpconf set-ldap-data-source-prop -p 9389 dsN-Z is-enabled:true $ dpconf create-ldap-data-source -p 9389 dsBase localhost:3389 $ dpconf set-ldap-data-source-prop -p 9389 dsBase is-enabled:true |
2 番目の手順では、データソースをデータソースプールに追加します。
$ dpconf create-ldap-data-source-pool -p 9389 "Base Pool" $ dpconf attach-ldap-data-source -p 9389 "Base Pool" dsBase $ dpconf create-ldap-data-source-pool -p 9389 "A-M Pool" $ dpconf attach-ldap-data-source -p 9389 "A-M Pool" dsA-M $ dpconf create-ldap-data-source-pool -p 9389 "N-Z Pool" $ dpconf attach-ldap-data-source -p 9389 "N-Z Pool" dsN-Z |
3 番目の手順では、クライアント要求を適切なデータプールに配布するためのデータビューを作成します。ベースプールでは dc=example,dc=com を処理するのに対して、UID 値に従って配布されたデータを保持するプールでは ou=people,dc=example,dc=com を処理します。この手順では、サーバーを再起動する必要があります。
$ dpconf create-ldap-data-view -p 9389 "Base View" "Base Pool" \ dc=example,dc=com $ dpconf create-ldap-data-view -p 9389 "A-M View" "A-M Pool" \ ou=people,dc=example,dc=com $ dpconf set-ldap-data-view-prop -p 9389 "A-M View" \ distribution-algorithm:lexicographic lexicographic-attrs:uid \ lexicographic-lower-bound:a lexicographic-upper-bound:m The proxy server will need to be restarted in order for the changes to take effect $ dpconf create-ldap-data-view -p 9389 "N-Z View" "N-Z Pool" \ ou=people,dc=example,dc=com $ dpconf set-ldap-data-view-prop -p 9389 "N-Z View" \ distribution-algorithm:lexicographic lexicographic-attrs:uid \ lexicographic-lower-bound:n lexicographic-upper-bound:z The proxy server will need to be restarted in order for the changes to take effect $ dpadm restart /local/dps |
4 番目の手順では、適切なデータソースに読み込まれるように LDIF を分割します。この例では、dsadm split-ldif コマンドを使用して最初の分割を実行し、さらに、ファイル編集を使用して、すべてのデータソースで最上位エントリを保持します。これにより、アクセス制御命令を指定する最上位エントリの保持と、各データソースに対する 1 つのインポートコマンドの使用が可能になります。
$ dpadm split-ldif /local/dps /local/ds6/ldif/Example.ldif /tmp/ [14/May/2007:21:14:13 +0200] - STARTUP - INFO - Java Version: 1.5.0_09 (Java Home: /local/jre) [14/May/2007:21:14:13 +0200] - STARTUP - INFO - Java Heap Space: Total Memory (-Xms) = 3MB, Max Memory (-Xmx) = 63MB [14/May/2007:21:14:13 +0200] - STARTUP - INFO - Operating System: SunOS/sparc 5.10 [14/May/2007:21:14:15 +0200] - INTERNAL - ERROR - Entry starting at line 0 does not start with a DN [14/May/2007:21:14:15 +0200] - INTERNAL - ERROR - Unable to parse line "# Kirsten is a Directory Administrator and therefore should not" of entry "uid=kvaughan, ou=People, dc=example,dc=com" starting at line 112 as an attribute/value pair -- no colon found. [14/May/2007:21:14:15 +0200] - INTERNAL - ERROR - Unable to parse line "# Robert is a Directory Administrator and therefore should not" of entry "uid=rdaugherty, ou=People, dc=example,dc=com" starting at line 298 as an attribute/value pair -- no colon found. [14/May/2007:21:14:16 +0200] - INTERNAL - ERROR - Unable to parse line "# Harry is a Directory Administrator and therefore should not" of entry "uid=hmiller, ou=People, dc=example,dc=com" starting at line 556 as an attribute/value pair -- no colon found. [14/May/2007:21:14:16 +0200] - INTERNAL - INFO - SplitLDIF processing complete. Processed 156 entries. $ ls /tmp/*ldif /tmp/a-m view.ldif /tmp/base view.ldif /tmp/n-z view.ldif |
この手順では、インポートの前に LDIF に追加する最上位エントリも必要です。
$ cp /local/ds6/ldif/Example.ldif /tmp/top.ldif $ vi /tmp/top.ldif $ cat /tmp/top.ldif dn: dc=example,dc=com objectclass: top objectclass: domain dc: example aci: (target ="ldap:///dc=example,dc=com")(targetattr != "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";) $ cat /tmp/top.ldif /tmp/base\ view.ldif > /tmp/top\ and\ base\ view.ldif $ cat /tmp/top.ldif /tmp/a-m\ view.ldif > /tmp/top\ and\ a-m\ view.ldif $ cat /tmp/top.ldif /tmp/n-z\ view.ldif > /tmp/top\ and\ n-z\ view.ldif |
5 番目の手順では、分割した LDIF を適切なデータソースにインポートします。ここでは、ベースエントリを処理するディレクトリはポート 3389 上にあります。A 〜 M を処理するディレクトリはポート 1389 で待機します。N 〜 Z を処理するディレクトリはポート 2389 で待機します。
$ dsconf import -p 1389 /tmp/top\ and\ a-m\ view.ldif dc=example,dc=com ... Task completed (slapd exit code: 0). $ dsconf import -p 2389 /tmp/top\ and\ n-z\ view.ldif dc=example,dc=com ... Task completed (slapd exit code: 0). $ dsconf import -p 3389 /tmp/top\ and\ base\ view.ldif dc=example,dc=com ... Task completed (slapd exit code: 0). |
6 番目の手順では、適切なデータプールに接続されたデータソースの操作ベースのウェイトを調整します。クライアントアプリケーションが検索以外の操作を実行する場合は、それらの操作のウェイトも設定してください。
$ dpconf set-attached-ldap-data-source-prop -p 9389 "Base Pool" dsBase search-weight:1 $ dpconf set-attached-ldap-data-source-prop -p 9389 "A-M Pool" dsA-M search-weight:1 $ dpconf set-attached-ldap-data-source-prop -p 9389 "N-Z Pool" dsN-Z search-weight:1 |
操作ベースのウェイトを設定すると、クライアントアプリケーションでは、データが物理的に配布されない場合と同じように Directory Proxy Server を検索できます。
次の検索では、UID が R で始まるユーザーを探します。
$ ldapsearch -p 9389 -b dc=example,dc=com uid=rfisher version: 1 dn: uid=rfisher, ou=People, dc=example,dc=com cn: Randy Fisher sn: Fisher givenName: Randy objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson ou: Human Resources ou: People l: Cupertino uid: rfisher mail: rfisher@example.com telephoneNumber: +1 408 555 1506 facsimileTelephoneNumber: +1 408 555 1992 roomNumber: 1579 |
次の検索では、ベースエントリの 1 つを探します。
$ ldapsearch -p 9389 -b ou=groups,dc=example,dc=com cn=hr\ managers version: 1 dn: cn=HR Managers,ou=groups,dc=example,dc=com objectClass: top objectClass: groupOfUniqueNames cn: HR Managers ou: groups uniqueMember: uid=kvaughan, ou=People, dc=example,dc=com uniqueMember: uid=cschmith, ou=People, dc=example,dc=com description: People who can manage HR entries |
この節では、データビューの次の情報とその作成および設定方法について説明します。
ここでの例は、接続ハンドラが Directory Proxy Server によって処理されるすべてのクライアント接続を許可していることを前提としています。
この節では、サブツリーのさまざまな部分への単一のアクセスポイントを提供するデータビューを設定する方法を説明します。この例では、同じベース DN の 2 つのデータビューが含まれています。数値配布アルゴリズムは、エントリを様々なデータビューに分割するために使用されます。データソースプールは、データ同等のデータソースのセットごとに設定されます。次の図は、配備の例を示しています。
このような配備については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Data Views to Route Requests When Different Parts of a Subtree Are Stored in Different Data Sources」を参照してください。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
「LDAP データソースの作成と設定」で説明しているように、各 LDAP サーバーにデータソースを作成します。
「LDAP データソースプールの作成と設定」で説明しているように、2 つのデータソースプールを作成します。
「LDAP データソースのデータソースプールへの接続」で説明しているように、サブツリーのある部分を含むデータソースを data-source-pool-1 に、サブツリーのもう 1 つの部分を含むデータソースを data-source-pool-2 に接続します。
(省略可能) 負荷分散を設定します。
詳細は、「負荷分散の設定」を参照してください。
ou=people,dc=example,dc=com で uid が 0 から 99 までのエントリが選択されるように、配布アルゴリズムを使ってデータビューを作成し、要求を data-source-pool-1 に送信するようデータビューを設定します。
$ dpconf set-ldap-data-view-prop -h host1 -p 1389 dataview-1 \ ldap-data-source-pool:data-source-pool-1 base-dn:ou=people,dc=example,dc=com \ distribution-algorithm :numeric numeric-attrs:uid numeric-lower-bound :0 \ numeric-upper-bound :99 |
ou=people,dc=example,dc=com で uid が 100 から 199 までのエントリが選択されるように、配布アルゴリズムを使ってもう 1 つのデータビューを作成し、要求を data-source-pool-2 に送信するようデータビューを設定します。
$ dpconf set-ldap-data-view-prop -h host1 -p 1389 dataview-2 \ ldap-data-source-pool:data-source-pool-2 base-dn:ou=people,dc=example,dc=com \ distribution-algorithm:numeric numeric-attrs:uid numeric-lower-bound:100 numeric-upper-bound :199 |
データビューのもう 1 つのプロパティーは、「デフォルトデータビュー」のデフォルトデータビューと同じです。
必要に応じて、変更を有効にするために Directory Proxy Server のインスタンスを再起動します。
Directory Proxy Server の再起動については、「Directory Proxy Server を再起動する」を参照してください。
この節では、階層と配布アルゴリズムを組み合わせるデータビューを設定する方法を説明します。このような配備については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Data Views With Hierarchy and a Distribution Algorithm」を参照してください。
ここでの例には、4 つのデータビューが含まれます。データビュー 1 のベース DN は、その他のデータビューのベース DN より上位です。データビュー 3 とデータビュー 4 のベース DN は同じですが、数値配布アルゴリズムによって、エントリがデータビュー 3 か 4 に割り振られます。
下位エントリが別のデータビューのベース DN として設定されると、Directory Proxy Server は、サブツリーの下位エントリをデータビューから自動的に除外します。数値配布アルゴリズムは同じサブツリーのエントリが異なるデータビューに分割します。データソースプールは、データ同等のデータソースのセットごとに設定されます。
次の図は、配備の例を示しています。
DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。
「LDAP データソースの作成と設定」で説明しているように、各 LDAP サーバーにデータソースを作成します。
「LDAP データソースプールの作成と設定」で説明しているように、4 つのデータソースプールを作成します。
「LDAP データソースのデータソースプールへの接続」の指示に従って、データソースをデータソースプールに接続します。
dc=example,dc=com を含むデータソースを data-source-pool-1 に接続します。
ou=computer,dc=example,dc=com を含むデータソースを data-source-pool-2 に接続します。
ou=people,dc=example,dc=com で uid が 0 と 99 の間のエントリを持つデータソースを data-source-pool-3 に接続します。
ou=people,dc=example,dc=com で uid が 100 と 199 の間のエントリを持つデータソースを data-source-pool-4 に接続します。
(省略可能) 負荷分散を設定します。
詳細は、「負荷分散の設定」を参照してください。
ベース DN が dc=example,dc=com で data-source-pool-1 を参照するデータビューを作成します。
$ dpconf create-ldap-data-view -h host1 -p 1389 dataview-1 \ data-source-pool-1 dc=example,dc=com |
ベース DN が ou=computer,dc=example,dc=com で data-source-pool-2 を参照するデータビューを作成します。
$ dpconf create-ldap-data-view -h host1 -p 1389 dataview-2 \ data-source-pool-2 ou=computer,dc=example,dc=com |
ベース DN が ou=people,dc=example,dc=com で data-source-pool-3 を参照するデータビューを作成します。uid が 0 から 99 までのエントリを選択するようにデータビューで配布アルゴリズムを設定します。
$ dpconf create-ldap-data-view -h host1 -p 1389 dataview-3 \ data-source-pool-3 ou=people,dc=example,dc=com $ dpconf set-ldap-data-view-prop dataview-3 distribution-algorithm:numeric \ numeric-attrs:uid numeric-lower-bound:0 numeric-upper-bound:99 |
ベース DN が ou=people,dc=example,dc=com で data-source-pool-4 を参照するデータビューを作成し、uid が 100 から 199 までのエントリを選択するようデータビューで配布アルゴリズムを設定します。
$ dpconf create-ldap-data-view -h host1 -p 1389 dataview-4 \ data-source-pool-4 ou=people,dc=example,dc=com $ dpconf set-ldap-data-view-prop dataview-4 distribution-algorithm:numeric \ numeric-attrs:uid numeric-lower-bound:100 numeric-upper-bound:199 |
excluded-subtrees パラメータをチェックして、サブツリー ou=computer,dc=example, dc=com と ou=people,dc=example, dc=com が dataview-1 から除外されていることを確認します。
$ dpconf get-ldap-data-view-prop -h host1 -p 1389 dataview-1 excluded-subtrees |
除外されたサブツリーの一覧が返されます。
変更を有効にするために Directory Proxy Server のインスタンスを再起動します。
Directory Proxy Server の再起動については、「Directory Proxy Server を再起動する」を参照してください。
この章では、仮想データビューの作成方法を説明します。仮想データビューは、ソースデータを変換し、そのデータをクライアントアプリケーションに異なるビューで表示します。仮想データビューには、変換された LDAP データビュー、LDIF データビュー、結合データビュー、および JDBC TMデータビューが含まれます。仮想データビューの機能の概要とユースケースの例の説明については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 18 章「Directory Proxy Server Virtualization」を参照してください。
Directory Service Control Center (DSCC) を使用してこの章の手順を実行することはできません。コマンド行を使用する必要があります。
この章の内容は次のとおりです。
LDIF データビューは、LDIF ファイルを LDAP データソースのように見せかける、単純な仮想データビューです。LDAP データビューとは異なり、LDIF データビューを設定する場合にデータソースやデータソースプールは作成しません。代わりに、データビューを作成する場合に LDIF ファイルを指定します。デフォルトで、LDIF データビューに書き込むことはできません。詳細については、「仮想データビューでのアクセス制御の定義」を参照してください。
LDIF データビューの作成と設定については、次の手順を参照してください。
DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。
LDIF データビューを作成します。
$ dpconf create-ldif-data-view -h host -p port view-name path-to-ldif-file suffix-dn |
(省略可能) LDIF データビューの一覧を表示します。
$ dpconf list-ldif-data-views -h host -p port |
デフォルトで設定されている LDIF データビューは、virtual access controls データビューのみです。このデータビューは、サーバーによって生成され、要求を仮想アクセス制御命令 (ACI) に経路指定できるようにします。
DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。
LDIF データビューのプロパティーを表示します。
$ dpconf get-ldif-data-view-prop -h host -p port view-name |
LDIF データビューには、次のデフォルトプロパティーがあります。
alternate-search-base-dn : "" alternate-search-base-dn : dc=com attr-name-mappings : none base-dn : suffixDN bind-pwd-attr : userPassword contains-shared-entries : - db-pwd-encryption : clear-text description : - distribution-algorithm : - dn-join-rule : - dn-mapping-attrs : none dn-mapping-source-base-dn : none excluded-subtrees : - filter-join-rule : - is-enabled : true is-read-only : false is-routable : true ldif-data-source : /path/to/filename.ldif lexicographic-attrs : all lexicographic-lower-bound : none lexicographic-upper-bound : none non-viewable-attr : - non-writable-attr : - numeric-attrs : all numeric-default-data-view : false numeric-lower-bound : none numeric-upper-bound : none pattern-matching-base-object-search-filter : all pattern-matching-dn-regular-expression : all pattern-matching-one-level-search-filter : all pattern-matching-subtree-search-filter : all process-bind : - replication-role : master viewable-attr : all except non-viewable-attr writable-attr : all except non-writable-attr |
手順 1で一覧表示されるプロパティーの 1 つまたは複数を変更します。
$ dpconf set-ldif-data-view-prop -h host -p port view-name property:value \ [property:value ... ] |
たとえば、データビューのソース LDIF ファイルを変更するには、 ldif-data-source プロパティーを設定します。
$ dpconf set-ldif-data-view-prop -h host1 -p 1389 -D cn="Proxy Manager" \ myLDIFDataView ldif-data-source:/local/files/example.ldif |
仮想データビューの ACI は、LDAP ディレクトリまたは LDIF ファイルに保存できます。仮想 ACI の機能方法については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Access Control On Virtual Data Views」を参照してください。
Directory Proxy Server インスタンスを作成すると、仮想アクセス制御の次のデフォルト設定が定義されます。
ACI がデフォルトで保存される LDIF ファイル ( instance-path/config/access_controls.ldif)
virtual access controls という名前の LDIF データビュー
このデータビューは、Directory Proxy Server が LDIF ファイルに保存された ACI にアクセスできるようにします。
前述のデフォルト ACI 設定を使用しない場合は、別のストレージリポジトリを定義できます。
DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。
仮想 ACI が保存されるリポジトリのデータビューを作成します。
ACI が LDAP ディレクトリに保存される場合は、第 19 章「LDAP データビュー」の説明に従って、LDAP データソースと LDAP データビューを作成します。
ACI が LDIF ファイルに保存される場合は、「LDIF データビューの作成と設定」の説明に従って、LDIF データビューを作成します。
前の手順で作成したデータビューに ACI データビューとして名前を指定します。
$ dpconf set-virtual-aci-prop -h host -p port aci-data-view:data-view-name
ACI リポジトリが LDAP ディレクトリの場合は、ACI データビューへのアクセスに必要な資格を指定します。
$ dpconf set-virtual-aci-prop -h host -p port aci-manager-bind-dn:bind-dn $ dpconf set-virtual-aci-prop -h host -p port aci-manager-bind-pwd-file:filename
使用する ACI リポジトリに関係なく、仮想アクセス制御を設定する必要があります。
ACI のプールを作成し、ACI データビューによって直接 ACI を管理できるのはプロキシマネージャーだけです。ACI リポジトリが LDAP ディレクトリの場合、aciSource オブジェクトクラスと dpsaci 属性が含まれるようにそのディレクトリのスキーマを変更します。スキーマのカスタマイズの詳細については、「Directory Server スキーマの拡張」を参照してください。
DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。
ACI リポジトリに ACI のプールを作成し、グローバル ACI を設定します。
グローバル ACI の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Global ACIs」を参照してください。グローバル ACI を設定するには、ACI データビューのビューベースの下に aciSource エントリを追加します。次に例を示します。
% ldapmodify -p port -D "cn=proxy manager" -w - dn: cn=aci-source-name,cn=virtual access controls changetype: add objectclass: aciSource dpsaci: (targetattr="*") (target="ldap:///ou=people,o=virtual") (version 3.0; acl "perm1"; allow(all) groupdn="ldap:///cn=virtualGroup1,o=groups,o=virtual";) cn: data-source-name |
この ACI のプールを使用するよう 1 つまたは複数の接続ハンドラを設定します。
% dpconf set-connection-handler-prop -h host -p port connection-handler \ aci-source:aci-source-name |
必要な ACI をデータに追加します。
これを行うには、ACI を含む仮想エントリを作成します。次に例を示します。
% ldapmodify -p port -D "cn=virtual application,ou=application users,dc=com" -w - dn: ou=people,o=virtual changetype: modify add: dpsaci dpsaci: (targetattr="*")(version 3.0; acl "perm1"; allow(all) userdn="ldap:///self";) dpsaci: (targetattr="*")(version 3.0; acl "perm1"; allow(search, read, compare) userdn ="ldap:///anyone";) |
適切なアクセス権限をもつユーザーなら誰でも、データビューを使用して仮想 ACI を追加、取得できます。
一般に、LDAP データビューの場合、スキーマチェックはバックエンドディレクトリによって、バックエンドディレクトリのスキーマを使用して実行されます。Directory Proxy Server でスキーマチェックを実行する場合は、次の手順に従います。
DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。
要求を正規化するには、特に DN の場合、サーバーの use-external-schema プロパティーを次のように設定します。
サーバーインスタンスが外部スキーマを使用するように設定します。
$ dpconf set-server-prop -h host -p port use-external-schema:true |
接続ハンドラでスキーマチェックを有効にします。
$ dpconf set-connection-handler-prop -h host -p port connection-handler \ schema-check-enabled:true |
cn=schema を公開するデータビューを作成します。
外部スキーマが LDAP ディレクトリで定義される場合、第 19 章「LDAP データビュー」での説明に従って、ビューベースを cn=schema にして LDAP データビューを作成します。
外部スキーマが LDIF ファイルで定義される場合、「LDIF データビューの作成と設定」での説明に従って、ビューベースを cn=schema にして LDIF データビューを作成します。
接続ハンドラによって公開されるデータビューの一覧にこのデータビューを追加します。
デフォルトで、データビューはすべて接続ハンドラによって公開されます。接続ハンドラによって公開されたデータビューのカスタムリストを定義している場合、このデータビューをリストに追加します。
$ dpconf set-connection-handler-prop -h host -p port connection-handler \ data-view-routing-custom-list+:data-view-name |
結合データビューは複数のデータビューを 1 つにまとめたものです。結合データビューの機能方法については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Join Data Views」を参照してください。
結合データビューの作成と設定の方法については、次の手順を参照してください。
DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。
結合ビューを形成するためにまとめる一次データビューと二次データビューを特定します。
結合ビューを作成する前に、一次データビューと二次データビューを準備しておきます。一次ビューと二次ビューは、LDAP データビュー、LDIF データビュー、JDBC データビュー、またはその他の結合データビューを含むどんな種類のデータビューでも構いません。特定のプロパティーを二次ビュー上で設定し、結合ビューのソースとして機能できるようにします。詳細については、「結合ビューの二次ビューを設定する」を参照してください。
結合データビューを作成します。
$ dpconf create-join-data-view -h host -p port view-name primary-view secondary-view \ suffix-dn |
(省略可能) データビューが正常に作成されたことを確認するために、結合ビューの一覧を表示します。
$ dpconf list-join-data-views -h host -p port |
DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。
結合データビューのプロパティーを表示します。
$ dpconf get-join-data-view-prop -h host -p port view-name |
結合データビューのデフォルトプロパティーは次のとおりです。
alternate-search-base-dn : "" alternate-search-base-dn : dc=com attr-name-mappings : none base-dn : suffixDN contains-shared-entries : - description : - distribution-algorithm : - dn-join-rule : - dn-mapping-attrs : none dn-mapping-source-base-dn : none excluded-subtrees : - filter-join-rule : - is-enabled : true is-read-only : false is-routable : true join-rule-control-enabled : false lexicographic-attrs : all lexicographic-lower-bound : none lexicographic-upper-bound : none non-viewable-attr : - non-writable-attr : - numeric-attrs : all numeric-default-data-view : false numeric-lower-bound : none numeric-upper-bound : none pattern-matching-base-object-search-filter : all pattern-matching-dn-regular-expression : all pattern-matching-one-level-search-filter : all pattern-matching-subtree-search-filter : all primary-view : primary-view process-bind : - replication-role : master secondary-view : secondary-view viewable-attr : all except non-viewable-attr writable-attr : all except non-writable-attr |
手順 1で一覧表示されるプロパティーの 1 つまたは複数を変更します。
$ dpconf set-join-data-view-prop -h host -p port view-name property:value \ [property:value ... ] |
たとえば、データソースの一次データビューを myLDAPDataView に変更するには、次のコマンドを使用します。
$ dpconf set-join-data-view-prop -h host1 -p 1389 -D cn="Proxy Manager" \ myJoinDataView primary-view:myLDAPDataView |
結合データビューを設定する場合は、一次データビューと二次データビューで viewable-attr および writable-attr プロパティーを設定します。
これらのプロパティーを設定すると、一次データビューと二次データビューで検索フィルタを適切に分割できます。これらのプロパティーを設定しなければ、二次データビューからの属性が検索フィルタに含まれている場合、検索結果に矛盾が生じる可能性があります。
必要に応じて、変更を有効にするために Directory Proxy Server のインスタンスを再起動します。
Directory Proxy Server の再起動については、「Directory Proxy Server を再起動する」を参照してください。
結合データビューで結合ルール設定情報を設定することにより、そのデータビューが複数の結合データビューから参照されるようにします。これを行うには、次の手順を実行します。
結合データビューで join-rule-control-enabled を true に設定します。
$ dpconf set-join-data-view-prop view-name join-rule-control-enabled:true |
join-rule-control-enabled を true に設定すると、その結合データビューに格納された結合ルール設定情報がサーバーで使用されます。ある結合データビューに対して、結合ルール設定情報が二次データビューに格納されている場合、この情報はサーバーで使用されません。この情報をサーバーに使用させるには、結合データビューレベルで設定情報を手動で追加してください。
二次ビューが一次ビューに関連付けられる方法を決定する結合ルールを定義します。
次のどちらかの結合ルールを使用できます。
DN 結合ルール
$ dpconf set-join-data-view-prop view-name \ dn-join-rule:uid=\${primary-view-name.uid},ou=People,dc=example |
フィルタ結合ルール
$ dpconf set-join-data-view-prop view-name \ filter-join-rule:uid=\${primary-view-name.uid} |
上のコマンドで、属性名を変数として扱う場合には ${} で囲みます。属性名を ${} で囲まないと、その属性名は定数として扱われます。
UNIX で bash または ksh を使用する場合、構築と同様に $ 文字は \${primary-view-name .uid} では \ でエスケープするべきですが、Windows の場合、エスケープは必要ありません。
特定のプロパティーを二次データビュー上で設定し、結合ビューのソースとして機能できるようにします。二次ビューはどんな種類のデータビューでも構わないため、使用するコマンドは、データビューの種類によって異なります。次のサンプルコマンドは、二次ビューが LDAP データビューであることを前提としています。ここで説明するプロパティーの詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Additional Secondary Data View Properties」を参照してください。
DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。
二次ビューが一次ビューに関連付けられる方法を決定する結合ルールを定義します。
filter-join-rule および dn-join-rule は、結合ビューの一次データビューでは決して設定しないでください。
次のどちらかの結合ルールを使用できます。
DN 結合ルール
$ dpconf set-ldap-data-view-prop -h host -p port secondary-view-name \ dn-join-rule:uid=\${primary-view-name.uid},ou=People,dc=example |
フィルタ結合ルール
$ dpconf set-ldap-data-view-prop -h host -p port secondary-view-name \ filter-join-rule:uid=\${primary-view-name.uid} |
dn-join-rule および filter-join-rule プロパティーの設定がサーバーで使用されるのは、結合データビューで join-rule-control-enabled プロパティーが false に設定されている場合だけです。結合データビューで join-rule-control-enabled プロパティーが true に設定されていると、二次ビューで設定された情報は無視されます。
結合データビューでフィルタ結合ルールが設定されている場合は、二次データビューで仮想変換ルールを設定して、その結合データビューでエントリを追加できるようにする必要があります。
dpconf add-virtual-transformation secondary-view-name \ write add-attr-value dn uid=\${uid} |
このルールを設定しなければ、結合データビューにエントリを追加できません。
(省略可能) 二次ビューでバインドを許可するかどうかを指定します。
デフォルトでは、すべてのデータビューでバインドが可能です。二次データビューのバインドを禁止する場合は、次のコマンドを実行します。
$ dpconf set-ldap-data-view-prop -h host -p port secondary-view-name process-bind:false |
このプロパティーの詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Handling of Binds」を参照してください。
(省略可能) 二次データビューに共有エントリが含まれるかどうかを指定します。
$ dpconf set-ldap-data-view-prop -h host -p port secondary-view-name \ contains-shared-entries:true |
このプロパティーの詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Handling of Shared Entries」を参照してください。
JDBC データビューを使用すると、LDAP クライアントアプリケーションがリレーショナルデータベースにアクセスできるようになります。JDBC データビューの機能方法については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「JDBC Data Views」を参照してください。
JDBC データビューの作成と設定の方法については、次の手順を参照してください。
DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。
リレーショナルデータベース用の JDBC データソースを作成します。
$ dpconf create-jdbc-data-source -h host -p port -b db-name -B db-url -J driver-url \ [-J driver-url]... -S driver-class source-name |
現在、各 JDBC データビューでサポートされる JDBC データソースは 1 つだけです。つまり、JDBC データソースで負荷分散することはできません。複数の JDBC データソースにアクセスするには、各データソース用にデータビューを作成し、それらをすべて結合データビューに結合します。
JDBC データソースを作成する場合は、次のプロパティーを設定します。
リレーショナルデータベースの名前。たとえば、payrolldb などです。
データベースへの URL。形式は、jdbc: vendor:driver://dbhost: dbport です。
db-url には、データベース名が含まれていないため、JDBC データベース URL としては完全ではありません。(データベース名は、db-name プロパティーで指定されます。)
db-url の末尾には、MySQL、DB2、および Derby データベースの場合は /、Oracle データベースの場合は : を付けてください。
JDBC ドライバクラス。たとえば、org.hsqldb.jdbcDriver などです。
JDBC ドライバへのパス。たとえば、file:/// path/to/hsqldb/lib/hsqldb.jar などです。
driver-url プロパティーは複数値プロパティーです。そのため、driver-url で JDBC ドライバ用の複数の JAR ファイルを設定することにより、各種のプラットフォームで JDBC ソースに接続できます。
JDBC データソースプールを作成します。
$ dpconf create-jdbc-data-source-pool -h host -p port pool-name |
JDBC データソースを JDBC データソースプールに接続します。
$ dpconf attach-jdbc-data-source -h host -p port pool-name source-name |
JDBC データビューを作成します。
$ dpconf create-jdbc-data-view -h host -p port view-name pool-name suffix-DN |
(省略可能) データビューが正常に作成されたことを確認するために、JDBC データビューの一覧を表示します。
$ dpconf list-jdbc-data-views -h host -p port |
DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。
JDBC データビューのプロパティーを表示します。
$ dpconf get-jdbc-data-view-prop -h host -p port view-name |
JDBC データビューのデフォルトプロパティーは次のとおりです。
alternate-search-base-dn : - attr-name-mappings : none base-dn : o=sql1 contains-shared-entries : - description : - distribution-algorithm : - dn-join-rule : - dn-mapping-attrs : none dn-mapping-source-base-dn : none excluded-subtrees : - filter-join-rule : - is-enabled : true is-read-only : false is-routable : true jdbc-data-source-pool : pool-name lexicographic-attrs : all lexicographic-lower-bound : none lexicographic-upper-bound : none non-viewable-attr : - non-writable-attr : - numeric-attrs : all numeric-default-data-view : false numeric-lower-bound : none numeric-upper-bound : none pattern-matching-base-object-search-filter : all pattern-matching-dn-regular-expression : all pattern-matching-one-level-search-filter : all pattern-matching-subtree-search-filter : all process-bind : - replication-role : master viewable-attr : all except non-viewable-attr writable-attr : all except non-writable-attr |
手順 1で一覧表示されるプロパティーの 1 つまたは複数を変更します。
$ dpconf set-jdbc-data-view-prop -h host -p port view-name property:value \ [property:value ... ] |
JDBC データビューを設定する場合、次のオブジェクトも設定する必要があります。
JDBC オブジェクトクラス。1 つまたは複数の JDBC テーブルを LDAP オブジェクトクラスにマップします。
JDBC テーブル。各リレーショナルデータベーステーブルに対して定義します。
JDBC 属性。JDBC テーブル内の指定された列の LDAP 属性を定義します。
リレーショナルデータベースの各テーブルの JDBC テーブルを作成します。
% dpconf create-jdbc-table jdbc-table-name db-table |
db-table の名前は大文字と小文字を区別します。リレーショナルデータベースで使用したのと同じ文字 (大文字または小文字) を使用してください。異なる文字を使用すると、そのテーブルをターゲットとする操作は失敗する場合があります。
各リレーショナルデータベーステーブル内で各列の JDBC 属性を作成します。
% dpconf add-jdbc-attr table-name attr-name sql-column |
JDBC 属性を作成すると、テーブル列が LDAP 属性にマップされます。
(省略可能) リレーショナルデータベース内の列が大文字と小文字を区別する場合、JDBC 属性の LDAP 構文を変更します。
% dpconf set-jdbc-attr-prop table-name attr-name ldap-syntax:ces |
ldap-syntax の値は、デフォルトで cis です。これは、jdbc-attr が大文字と小文字を区別しないことを意味します。リレーショナルデータベースが大文字と小文字を区別する場合、値を ces に変更します。
Oracle や DB2 など、特定のリレーショナルデータベースはデフォルトで大文字と小文字を区別します。LDAP はデフォルトで大文字と小文字を区別しません。Directory Proxy Server はリレーショナルデータベーステーブルの列が大文字と小文字を区別することを検出すると、フィルタ内の対応する属性の ldapsearch クエリーが UPPER 関数を使用して SQL クエリーに変換されます。
たとえば、クエリー ldapsearch -b "dc=mysuffix" "(attr=abc)" は次の SQL クエリーに変換されます。
SELECT * FROM mytable WHERE (UPPER(attr)='ABC') |
デフォルトで、この種類のクエリーはインデックスが生成されません。このため、このようなクエリーは、パフォーマンスに大きな影響を与える可能性があります。
次の 2 つの方法でパフォーマンスへの影響を緩和できます。
jdbc-attr の ldap-syntax プロパティーを ces に設定する。
LDAP フィルタで使用されている可能性のある各 jdbc-attr の UPPER 関数でインデックスを作成する。
リレーショナルデータベースが大文字と小文字を区別しない場合は、ldap-syntax をデフォルト値の cis に設定します。ldap-syntax:ces は、大文字と小文字を区別しないデータベースではサポートされません。
LDAP リレーショナルデータベーステーブルの JDBC オブジェクトクラスを作成します。
% dpconf create-jdbc-object-class view-name objectclass primary-table \ [secondary-table... ] DN-pattern |
JDBC オブジェクトクラスを作成すると、原則的にこれらのテーブルが関連付けられる LDAP オブジェクトクラスが指定されます。JDBC オブジェクトクラスは、一次テーブルと二次テーブルが存在する場合、これらも指定します。
JDBC オブジェクトクラスを作成する場合、DN パターンを指定します。DN パターンは、エントリの DN の構築にどの属性を使用するかを示します。たとえば、DN パターンを uid として指定すると、エントリの DN は、データビューの属性 uid とビューベースを使用して構築されます。たとえば、uid=bjensen,ou=people,dc=example,dc=com のようになります。DN パターンは複数の属性で構成されることがあります。その場合は、属性を , (カンマ) で区切るようにしてください。たとえば、DN パターンを uid,country として指定した場合、データビューによって返されるエントリの DN は uid=bjensen,country=America,ou=people,dc=example,dc=com となります。
JDBC オブジェクトクラスの DN パターンに定義されたサブツリーコンポーネントにはすべて、それらのサブツリーコンポーネント用に定義された JDBC オブジェクトクラスを設定するようにしてください。たとえば、JDBC オブジェクトクラスに uid,ou という DN パターンがある場合、JDBC オブジェクトクラス定義に DN パターン ou を設定するようにしてください。これは、Directory Proxy Server で正しい構造の DIT を構築するために必要です。この設定を行わないと、ou=xxx,base-DN のような値を持つサブツリーが検索結果で返されません。
二次テーブルが存在する場合、一次テーブルと二次テーブル間の結合ルールを定義します。
% dpconf set-jdbc-table-prop secondary-table-name filter-join-rule:join-rule |
結合ルールは二次テーブルで定義され、そのテーブルからのデータが一次テーブルのデータにリンクされる方法を決定します。オブジェクトクラスの一次テーブルと二次テーブル間の関係の定義方法は重要です。詳細については、「JDBC テーブル間の関係の定義」を参照してください。
JDBC オブジェクトクラスのスーパークラスを指定します。
% dpconf set-jdbc-object-class-prop view-name objectclass super-class:value |
スーパークラスは、JDBC オブジェクトクラスが継承した LDAP オブジェクトクラスを示します。
もっとも単純な場合、JDBC オブジェクトクラスにはテーブルが 1 つ (一次) しか含まれません。二次テーブルはなく、このため、テーブル間の関係を定義する必要はありません。
オブジェクトクラスに複数のテーブルが含まれる場合、これらのテーブル間の関係を明確に定義します。テーブル間の関係は、常に二次テーブル上で定義されます。二次テーブルの次のプロパティーによって、これらの関係を定義できます。
is-single-row-table は、テーブルで LDAP エントリに一致する行が 1 つだけであると指定します。
contains-shared-entries は、二次テーブルの行が一次テーブルの複数の行に使用されることを指定します。
filter-join-rule は、エントリが一次テーブルに基づいて二次テーブルから取得される方法を示します。
次の例は、最初の 2 つのプロパティーの値に基づいて、フィルタ結合ルールがどのように定義されるかを示しています。以降の例では、オブジェクトクラスに一次テーブルと二次テーブルが 1 つずつあることを前提としています。
それぞれプロパティーのデフォルト値が指定されています。この場合、一次テーブルと二次テーブルの関係は、n->1 です。つまり、一次テーブルの n 行は二次テーブルの共有行の 1 つを参照します。
リレーショナルデータベースで、外部キー (FK) が一次テーブルで定義され、二次テーブルの列をポイントします。
たとえば、複数の従業員が同じマネージャーを共有できる組織の場合を考えてみます。2 つのリレーショナルデータベーステーブルは、次の構造で定義されます。
primary table : EMPLOYEE [ID, NAME, FK_MANAGER_ID] secondary table : MANAGER [ID, NAME] |
次のオブジェクトクラスと属性が定義されます。
object-class : employee attr : name (from primary EMPLOYEE.NAME) attr : manager (from secondary MANAGER.NAME) |
次のフィルタ結合ルールが、二次テーブルで定義されます。
ID=\${EMPLOYEE.FK_MANAGER_ID}" |
複数の二次テーブルの場合は、二次テーブルごとに filter-join-rule を設定する必要があります。複数の二次テーブルで filter-join-rule を設定する方法の詳細については、手順 11 を参照してください。
この設定の場合、LDAP 操作で次の動作が行われます。
従業員エントリの追加。従業員エントリのマネージャーがテーブルに存在しない場合、新しい行が作成されます。マネージャーが存在する場合は、既存の行が使用されます。
エントリ内の「manager」属性の値の置き換え。MANAGER.NAME 行の値が変更されます。
従業員エントリの削除。マネージャーエントリが共有されているため、二次テーブルの行は削除されません。
エントリから「manager」 属性の削除。二次テーブルの行が削除され、外部キー (EMPLOYEE.FK_MANAGER_ID) が NULL に設定されます。
この場合、一次テーブルと二次テーブルの関係は、1->1 または 1<-1 です。つまり、一次テーブルの 1 行が二次テーブルの 1 行で参照されます。
リレーショナルデータベースで、外部キー (FK) が一次テーブルまたは二次テーブルで定義されることがあります。
たとえば、従業員の UID が 1 つのテーブルに保存され、従業員の姓が二次テーブルに保存されている組織の場合を考えてみます。2 つのリレーショナルデータベーステーブルは、次の構造で定義されます。
primary table : UID [ID, VALUE, FK_SN_ID] secondary table : SN [ID, VALUE] |
次のオブジェクトクラスと属性が定義されます。
object-class : employee attr : uid (from primary UID.VALUE) attr : sn (from secondary ID.VALUE) |
次のフィルタ結合ルールが、二次テーブルで定義されます。
ID=\${UID.FK_SN_ID} |
別の方法として、二次テーブルに保存されている外部キー FK_UID_ID を UID.ID にポイントさせることでも同等の設定が可能です。
この場合、一次テーブルと二次テーブルの関係は、1->n です。つまり、一次テーブルの 1 行が二次テーブルの n 行で参照されます。この例は、複数値属性の場合を示しています。複数値属性は、属性値ごとに 1 行で表され、それぞれ二次テーブル内の行のセットと対応します。
リレーショナルデータベースで、外部キーが二次テーブルで定義され、一次テーブルの列をポイントします。
たとえば、従業員が複数の電話番号を持っている可能性のある組織の場合を考えてみます。2 つのリレーショナルデータベーステーブルは、次の構造で定義されます。
primary table : EMPLOYEE [ID, NAME] secondary table : PHONE [ID, VALUE, USER_ID] |
次のオブジェクトクラスと属性が定義されます。
object-class : employee attr : cn (from primary EMPLOYEE.NAME) attr : telephoneNumber (from secondary PHONE.VALUE) |
次のフィルタ結合ルールが、二次テーブルで定義されます。
USER_ID=\${EMPLOYEE.ID} |
これは、現在 Directory Proxy Server でサポートされていません。
次の節では、2 つの設定例について説明します。これらの設定は、仮想ディレクトリの主な機能と、これらの機能の設定方法を示しています。
ここでの手順は、LDAP ディレクトリと MySQL データベースを結合する仮想設定の例について説明しています。LDAP ディレクトリは、一次データソースとして、ユーザー情報のほとんどが含まれています。mySQL データベースには、ユーザーについての追加情報が含まれています。結果として得られる設定を次の図に示します。
install-path /ds6/ldif/Example.ldif のサンプルデータを使用して、この例を複製したり、サンプルデータを独自のデータに置き換えられます。
この設定は、3 つの部分に分割できます。
LDAP データビューの設定とテスト
JDBC データビューの設定とテスト
結合データビューの設定とテスト
わかりやすいように、ここでのコマンドはすべて Directory Proxy Server が /local/dps のローカルホストで実行されていることを前提としています。コマンドは、次の環境変数が設定されていることも前提としています。
1389
pwd.txt、管理者パスワードを含むファイル
4389
cn=Directory Manager
ここでの作業は次の情報を前提としています。
Directory Server インスタンスが host1 上のポート 4389 で実行されている。
Directory Server のデータがサフィックス dc=example,dc=com の下に保存されている。この例と同じ環境を構築するには、Directory Server インスタンスとサフィックス dc=example,dc=com を作成し、install-path/ds6/ldif/Example.ldif のサンプルデータをインポートしてください。
Directory Server インスタンスに対して、myds1 という名前の LDAP データソースを作成します。
% dpconf create-ldap-data-source myds1 host1:4389 |
データソースを有効にして、データソースへの書き込み操作を許可します。
% dpconf set-ldap-data-source-prop myds1 is-enabled:true is-read-only:false |
myds1-pool という名前の LDAP データソースプールを作成します。
% dpconf create-ldap-data-source-pool myds1-pool |
LDAP データソースを LDAP データソースプールに接続します。
% dpconf attach-ldap-data-source myds1-pool myds1 |
データソースがそのデータソースプールからのバインド、追加、検索、および変更操作の 100% を受け取るように指定します。
% dpconf set-attached-ldap-data-source-prop myds1-pool myds1 add-weight:100 \ bind-weight:100 modify-weight:100 search-weight:100 |
ベース DN が dc=example,dc=com で myds1–view という名前のデータソースプールの LDAP データビューを作成します。
% dpconf create-ldap-data-view myds1-view myds1-pool dc=example,dc=com |
dc=example,dc=com のユーザーとして、LDAP データソース内のエントリをすべて検索して、データビューから読み取りができることを確認します。
% ldapsearch -p 1389 -D "uid=kvaughan,ou=people,dc=example,dc=com" -w bribery \ -b dc=example,dc=com "objectclass=*" |
dc=example,dc=com のユーザーの資格を使用します。cn=Directory Manager を使用する場合は、この DN を処理するようにデータビューを定義する必要があります。
dc=example,dc=com のユーザーとして、userPassword 属性を変更して、データビューに書き込みができることを確認します。
% ldapmodify -p 1389 -D "uid=kvaughan,ou=people,dc=example,dc=com" -w bribery dn: uid=kvaughan,ou=people,dc=example,dc=com changetype: modify replace: userPassword userPassword: myNewPassword |
Directory Server 内のデフォルト ACI はユーザーが自分自身のパスワードを変更することを許可しています。
次の作業は、mySQL データベースがインストールされて実行中であり、データベースにデータが存在し、mySQL データベースが次のように設定されていることが前提となっています。
データベース名: sample_sql
データベース URL: host2.example.com:3306/
JDBC ドライバ URL: file:/net/host2.example/local/mysql/lib/jdbc.jar
ドライバクラス: com.mysql.jdbc.Driver
データベースユーザー: root
データベースパスワードファイル: mysqlpwd.txt
次の表は、データベース内のテーブルと複合フィールドを説明しています。JDBC データビューを設定するためにこの情報が必要です。
mySQL テーブル |
フィールド |
---|---|
EMPLOYEE |
ID、SURNAME、PASSWORD、 ROOM、COUNTRY_ID |
COUNTRY |
ID、NAME |
PHONE |
USER_ID、NUMBER |
SQL データベース用の mysql1 という名前の JDBC データソースを作成します。
% dpconf create-jdbc-data-source -b sample_sql \ -B jdbc:mysql://host2.example.com:3306/ \ -J file:/net/host2.example/local/mysql/lib/jdbc.jar \ -S com.mysql.jdbc.Driver mysql1 |
SQL データベースのユーザー名とパスワードファイルを指定します。
% dpconf set-jdbc-data-source-prop mysql1 db-pwd-file:sqlpwd.txt db-user:root |
プロキシサーバーを再起動します。
% dpadm restart /local/dps |
データソースを有効にして、データソースへの書き込み操作を許可します。
% dpconf set-jdbc-data-source-prop mysql1 is-enabled:true is-read-only:false |
mysql1–pool という名前の JDBC データソースプールを作成します。
% dpconf create-jdbc-data-source-pool mysql1-pool |
JDBC データソースをデータソースプールに接続します。
% dpconf attach-jdbc-data-source mysql1-pool mysql1 |
ベース DN が o=sql で myjdbc1–view という名前のデータソースプールの JDBC データビューを作成します。
% dpconf create-jdbc-data-view mysql1-view mysql1-pool o=sql |
MySQL データベースの各テーブルの JDBC テーブルを作成します。
% dpconf create-jdbc-table employee1 EMPLOYEE % dpconf create-jdbc-table country1 COUNTRY % dpconf create-jdbc-table phone1 PHONE |
SQL データベースのテーブル名は大文字と小文字を区別します。SQL データベースの場合と同じ文字 (大文字または小文字) を使用していることを確認してください。
各テーブルの各列の JDBC 属性を作成します。
JDBC 属性を作成すると、MySQL 列が LDAP 属性にマップされます。
% dpconf add-jdbc-attr employee1 uid ID % dpconf add-jdbc-attr employee1 sn SURNAME % dpconf add-jdbc-attr employee1 userPassword PASSWORD % dpconf add-jdbc-attr employee1 roomNumber ROOM % dpconf add-jdbc-attr phone1 telephoneNumber NUMBER % dpconf add-jdbc-attr country1 countryName NAME |
phone1 user_id 列と country1 id 列には、LDAP 属性 uid がすでに作成されている EMPLOYEE.ID に存在する値だけが含まれるため、これらの列の JDBC 属性を必ずしも作成する必要はありません。
LDAP person オブジェクトクラスに対して JDBC オブジェクトクラスを作成します。
ここでは、employee1 テーブルを一次テーブル、country1 テーブルと phone1 テーブルを二次テーブルとします。JDBC オブジェクトクラスの作成にも DN が必要です。この例では、DN は uid 属性とデータビューのベース DN から構築されます。
% dpconf create-jdbc-object-class mysql1-view person employee1 country1 phone1 uid |
一次テーブルと二次テーブル間の結合ルールを定義します。
結合ルールは二次テーブルで定義され、そのテーブルからのデータが一次テーブルのデータにリンクされる方法を決定します。
% dpconf set-jdbc-table-prop country1 filter-join-rule:ID=\${EMPLOYEE.COUNTRY_ID} % dpconf set-jdbc-table-prop phone1 filter-join-rule:USER_ID=\${EMPLOYEE.ID} |
JDBC オブジェクトクラスのスーパークラスを指定します。
スーパークラスは、JDBC オブジェクトクラスが属性を継承した LDAP オブジェクトクラスを示します。
% dpconf set-jdbc-object-class-prop mysql1-view person super-class:top |
JDBC データビューをテストする前に、ACI を設定してデータビューへの書き込みアクセスを有効にします。デフォルトで、LDAP データビュー以外への書き込みアクセスは拒否されます。この例では、ユーザーに自分のパスワードの変更を許可するグローバル ACI を 1 つ追加するだけで十分です。
プロキシマネージャーとして、ACI のプールを JDBC データソースに追加し、ユーザーに自分のエントリの変更を許可するグローバル ACI を追加します。
% ldapmodify -p 1389 -D "cn=proxy manager" -w password dn: cn=mysql1,cn=virtual access controls changetype: add objectclass: acisource dpsaci: (targetattr="*") (target = "ldap:///o=sql") (version 3.0; acl "enable all access for all users "; allow(all) userdn="ldap:///uid=kvaughan,o=sql";) cn: mysql1 |
o=sql ドメインへの接続を処理するために接続ハンドラを作成します。
% dpconf create-connection-handler mysql1-handler |
接続ハンドラを有効にして、o=sql ドメイン内のユーザーからのバインドをすべて処理するように設定します。
% dpconf set-connection-handler-prop mysql1-handler is-enabled:true \ bind-dn-filters:"uid=.*,o=sql" |
前の手順で追加した ACI のプールを使用するように接続ハンドラを設定します。
% dpconf set-connection-handler-prop mysql1-handler aci-source:mysql1 |
o=sql のユーザーとして JDBC データソースを検索し、データビューから読み取りができることを確認します。
% ldapsearch -p 1389 -D "uid=kvaughan,o=sql" -w mypwd -b o=sql "objectclass=*" |
o=sql のユーザーの資格を使用する必要があります。
o=sql のユーザーとして、 userPassword 属性を変更して、データビューに書き込みができることを確認します。
% ldapmodify -p 1389 -D "uid=kvaughan,o=sql" -w mypwd dn: uid=kvaughan,o=sql changetype: modify replace: userPassword userPassword: myNewpwd |
myjoin1–view という名前の結合データビューを作成します。
LDAP データビューを一次データビュー、JDBC データビューを二次データビューに指定します。
% dpconf create-join-data-view myjoin1-view myds1-view mysql1-view o=join |
二次データビューで結合ルールを定義します。
次の結合ルールは、二次データビューのエントリの uid 属性が一次データビューのエントリの uid 属性に一致することを指定します。
% dpconf set-jdbc-data-view-prop mysql1-view filter-join-rule:uid=\${myds1-view.uid} |
結合データビューでフィルタ結合ルールが設定されている場合は、二次データビューで仮想変換ルールを設定して、その結合データビューでエントリを追加できるようにする必要があります。
dpconf add-virtual-transformation secondary-view-name \ write add-attr-value dn uid=\${uid} |
このルールを設定しなければ、結合データビューにエントリを追加できません。
結合データビューを使用して、一次データビューに対して読み書きができる属性のセットを定義します。
% dpconf set-ldap-data-view-prop myds1-view viewable-attr:dn \ viewable-attr:cn viewable-attr:sn viewable-attr:givenName \ viewable-attr:objectClass viewable-attr:ou viewable-attr:l \ viewable-attr:uid viewable-attr:mail viewable-attr:telephoneNumber \ viewable-attr:facsimileTelephoneNumber viewable-attr:roomNumber \ viewable-attr:userPassword % dpconf set-ldap-data-view-prop myds1-view writable-attr:dn \ writable-attr:cn writable-attr:sn writable-attr:givenName \ writable-attr:objectClass writable-attr:ou writable-attr:l \ writable-attr:uid writable-attr:mail writable-attr:telephoneNumber \ writable-attr:facsimileTelephoneNumber writable-attr:roomNumber \ writable-attr:userPassword |
これらの定義は、結合ビューのコンテキストにのみ適用されます。LDAP データビューに直接アクセスした場合、デフォルトでは、すべての属性が読み書きできます。
結合データビューを使用して、二次データビューに対して読み書きができる属性のセットを定義します。
% dpconf set-jdbc-data-view-prop mysql1-view viewable-attr:dn \ viewable-attr:objectclass viewable-attr:sn viewable-attr:roomNumber \ viewable-attr:userpassword viewable-attr:jobtitle viewable-attr:countryName \ viewable-attr:telephoneNumber % dpconf set-jdbc-data-view-prop mysql1-view writable-attr:dn \ writable-attr:objectclass writable-attr:sn writable-attr:roomNumber \ writable-attr:userpassword writable-attr:jobtitle \ writable-attr:countryName writable-attr:telephoneNumber |
これらの定義は、結合ビューのコンテキストにのみ適用されます。JDBC データビューに直接アクセスした場合、デフォルトでは、すべての属性が読み書きできます。
プロキシマネージャーとして、結合データビューへの匿名アクセスを許可するグローバル ACI を追加します。
% ldapmodify -p 1389 -D "cn=proxy manager" -w password dn: cn=myjoin1,cn=virtual access controls changetype: add objectclass: acisource dpsaci: (targetattr="*") (target = "ldap:///o=join") (version 3.0; acl "anonymous_access"; allow(all) userdn="ldap:///anyone";) cn: myjoin1 |
前の手順で追加した ACI のプールを使用するように接続ハンドラを設定します。
% dpconf set-connection-handler-prop default-connection-handler aci-source:myjoin1 |
ここでは、Kirsten Vaughan のエントリを検索し、両方の結合ビューからのデータが取得されるかどうかを確認します。
% ldapsearch -p 1389 -b o=join "uid=kvaughan" |
返されるエントリには、LDAP データビューと JDBC データビューの両方からの属性が含まれていることに注意してください。
o=join のユーザーとして、userPassword 属性を変更して、結合データビューに書き込みができることを確認します。
% ldapmodify -p 1389 dn: uid=kvaughan,ou=people,o=join changetype: modify replace: userPassword userPassword: myPassword |
この設定は、仮想ディレクトリの機能のいくつかが特定のディレクトリサービス要件を満たしている Example.com という組織で説明します。
Example.com は複数の異種データソースに組織データを保存しています。過去の経緯により、ユーザーデータは LDAP ディレクトリ、フラット LDIF ファイル、SQL データベースに分散されています。HR 部門は o=example.com のベース DN でユーザーデータを LDAP ディレクトリに保存しています。給与部門はデータを SQL データベースに保存しています。部門やビルの番号などの管理データはdc=example,dc=com のベース DN で管理部門の LDIF ファイルに保存されています。
さらに、Example.com は Company22 という名前の企業を買収しました。Company 22 もユーザーデータを dc=company22,dc=com のベース DN で LDAP ディレクトリに保存しています。
次の図は、Example.com のユーザーデータがどのように保存されているかをまとめたものです。
Example.com には、異種データソースに保存されたデータにアクセスする必要のある LDAP クライアントアプリケーションがいくつかあります。クライアントアプリケーションの要件はすべて同じではありません。異なるデータビューは必要です。場合によっては、クライアントはデータを集約する必要があります。さらに、Example.com の新しい従業員を以前からの従業員とともに管理できるように、一部のクライアントアプリケーションは Company22 のユーザーデータにアクセスする必要があります。
次の図は、Example.com のクライアントアプリケーション要件をまとめたものです。
次の節では、Directory Proxy Server データビューがこのサンプルシナリオで説明したクライアントアプリケーション要件を十分満たすことができる設定について見ていきます。データビューの機能方法については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 17 章「Directory Proxy Server Distribution」および『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 18 章「Directory Proxy Server Virtualization」を参照してください。
サンプルシナリオの設定は次のセクションで構成されています。
HR 部門は従業員名、職務開始データ、職務レベルなどの情報を保存しています。管理部門は、建築基準法や会社の電話番号などの追加データを保存しています。HR データを処理するクライアントアプリケーションは、両方のソースからの複合データにアクセスする必要があります。各エントリ内の属性 employeeNumber は両方のデータソースに共通です。
次の図は、クライアントアプリケーションの要件を示しています。
このアプリケーション要件を満たすために、給与ディレクトリと管理 LDIF ファイル用にデータビューが作成されます。これらの 2 つのデータビューは、その後、集約されたデータにアクセスできるよう結合されます。この共通属性によって、Directory Proxy Server は各ユーザーのデータを集約できます。
わかりやすいように、ここで使用するコマンドは次の情報を前提としています。
Directory Proxy Server インスタンスはローカルホスト上のデフォルト LDAP ポート (389) で実行されている。
Directory Proxy Server インスタンスは、/local/myDPS にある。
プロキシマネージャーのパスワードを含むファイルへのパスは、変数 LDAP_ADMIN_PWF として設定されている。Directory Proxy Server 環境変数の設定の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Installation Guide』の「Environment Variables」を参照してください。
給与 LDAP ディレクトリは payrollHost という名前のホストのポート 2389 で実行されている。
管理データを保存している LDIF ファイルの名前は、 example.ldif である。
各コマンドの完全な構文を取得するために、オプションを使用せずにコマンドを実行します。次に例を示します。
$ dpconf create-ldap-data-view Operands are missing Usage: dpconf create-ldap-data-view VIEW_NAME POOL_NAME SUFFIX_DN
給与ディレクトリの LDAP データソースを作成します。
$ dpconf create-ldap-data-source payroll-directory payrollHost:2389
給与ディレクトリの LDAP データソースプールを作成します。
$ dpconf create-ldap-data-source-pool payroll-pool
給与データソースをデータソースプールに接続します。
$ dpconf attach-ldap-data-source payroll-pool payroll-directory
接続済みデータソースのウェイトを設定します。
$ dpconf set-attached-ldap-data-source-prop -h payrollHost -p 2389 \ payroll-pool payroll-directory add-weight:2 \ bind-weight:2 compare-weight:2 delete-weight:2 \ modify-dn-weight:2 modify-weight:2 search-weight:2
給与ディレクトリの LDAP データビューを作成します。
$ dpconf create-ldap-data-view payroll-view payroll-pool o=example.com
クライアント要求がこのデータビューに経路指定できるように LDAP データビューを有効にします。
$ dpconf set-ldap-data-view-prop payroll-view is-enabled:true
変更を有効にするために、Directory Proxy Server を再起動します。
$ dpadm restart /local/myDPS
管理データの LDIF データビューを作成します。
$ dpconf create-ldif-data-view admin-view example.ldif dc=example,dc=com
管理データの LDIF データビューを有効にします。
$ dpconf set-ldif-data-view-prop admin-view is-enabled:true
管理ビューに給与ビューの複数のエントリで使用されるエントリが含まれるように指定します。
$ dpconf set-ldif-data-view-prop admin-view contains-shared-entries:true
このプロパティーが TRUE に設定されている場合、給与データビューのエントリを削除しても、管理データビューの共有エントリは削除されません。給与データビューにエントリを追加すると、それがすでに存在していなければ、二次データビューのエントリのみが追加されます。
変更を有効にするために、Directory Proxy Server を再起動します。
$ dpadm restart /local/myDPS
データの集約方法を指定するフィルタ結合ルールを管理データビューで作成します。
次の結合ルールは、ユーザーエントリの employeeNumber 属性に基づいてデータが結合されるよう指定します。
$ dpconf set-ldif-data-view-prop admin-view \ filter-join-rule:employeeNumber=\${payroll-view.employeeNumber}
2 つのデータビューを集約する結合データビューを作成します。
結合データビューに対して、組織はサフィックス DN dc=example,dc=com を使用します。
$ dpconf create-join-data-view example-join-view payroll-view admin-view \ dc=example,dc=com
Company 22 のユーザーデータは、DN dc=company22,dc=com で保存されています。Example.com はこのユーザーデータをほとんどの場合に区別しておきたいと考えていますが、あるクライアントアプリケーションは Company 22 の従業員を Example.com の残りの従業員とともに管理する必要があります。このクライアントアプリケーションは Company 22 のユーザーデータが Example.com のデータのように見えることを必要としています。
次の図は、クライアントアプリケーションの要件を示しています。
このアプリケーション要件を満たすために、仮想 DN の dc=example,dc=com のデータビューが Company 22 ディレクトリに対して作成されます。
わかりやすいように、ここで使用するコマンドは次の情報を前提としています。
Directory Proxy Server インスタンスはローカルホスト上のデフォルト LDAP ポート (389) で実行されている。
Directory Proxy Server インスタンスは、/local/myDPS にある。
プロキシマネージャーのパスワードを含むファイルへのパスは、変数 LDAP_ADMIN_PWF として設定されている。Directory Proxy Server 環境変数の設定の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Installation Guide』の「Environment Variables」を参照してください。
Company 22 LDAP ディレクトリは company22Host という名前のホストのポート 2389 で実行されている。
Company 22 のディレクトリの LDAP データソースを作成します。
$ dpconf create-ldap-data-source company22-directory company22Host:2389
Company 22 のディレクトリの LDAP データソースプールを作成します。
$ dpconf create-ldap-data-source-pool company22-pool
Company 22 のデータソースをデータソースプールに接続します。
$ dpconf attach-ldap-data-source company22-pool company22-directory
接続済みデータソースのウェイトを設定します。
$ dpconf set-attached-ldap-data-source-prop -h company22Host -p 2389 \ company22-pool company22-directory add-weight:2 \ bind-weight:2 compare-weight:2 delete-weight:2 \ modify-dn-weight:2 modify-weight:2 search-weight:2
仮想 DN の dc=example,dc=com で Company 22 のディレクトリの LDAP データビューを作成します。
$ dpconf create-ldap-data-view company22-view company22-pool dc=example,dc=com
この仮想 DN を Company 22 のディレクトリの実際の DN にマップするよう Directory Proxy Server に命令します。
$ dpconf set-ldap-data-view-prop company22-view \ dn-mapping-source-base-dn:dc=company22,dc=com
クライアント要求がこのデータビューに経路指定できるように、Company 22 のディレクトリの LDAP データビューを有効にします。
$ dpconf set-ldap-data-view-prop company22-view is-enabled:true
変更を有効にするために、Directory Proxy Server を再起動します。
$ dpadm restart /local/myDPS
HR 部門は Example.com と新しく買収した Company 22 の HR データの集約されたビューを必要としています。次の図は、グローバル HR アプリケーションの要件を示しています。
データの集約方法を指定するフィルタ結合ルールを Company 22 データビューで作成します。
次の結合ルールは、ユーザーエントリの employeeNumber 属性に基づいてデータが結合されるよう指定します。
$ dpconf set-ldif-data-view-prop company22-view \ filter-join-rule:employeeNumber=\${example-join-view.employeeNumber}
Company 22 のデータビューと Example.com の結合データビューを集約する結合データビューを作成します。
$ dpconf create-join-data-view global-join-view example-join-view \ company22-view dc=example,dc=com
Example.com の給与部門は給与データを SQL データベースに保存しています。データベースには、employee テーブルと salary テーブルの 2 つのテーブルがあります。Example.com には、このデータへのアクセスを必要とする LDAP クライアントアプリケーションがあります。クライアントアプリケーションは SQL データが LDAP データのように見えることを必要としています。
次の図は、クライアントアプリケーションの要件を示しています。
このアプリケーション要件を満たすために、SQL テーブル内の列を LDAP 属性にマップする JDBC データビューが作成されます。
わかりやすいように、ここで使用するコマンドは次の情報を前提としています。
Directory Proxy Server インスタンスはローカルホスト上のデフォルト LDAP ポート (389) で実行されている。
Directory Proxy Server インスタンスは、/local/myDPS にある。
プロキシマネージャーのパスワードを含むファイルへのパスは、変数 LDAP_ADMIN_PWF として設定されている。Directory Proxy Server 環境変数の設定の詳細については、『Sun Java System Directory Server Enterprise Edition 6.3 Installation Guide』の「Environment Variables」を参照してください。
SQL データベースが起動して実行中である。
JAVA_HOME 変数が正しい Java パスに設定されている。
SQL データベースへのパスワードは、myPasswordFile ファイルに格納された myPassword である。
給与データベース用の JDBC データソースを作成します。
$ dpconf create-jdbc-data-source -b payrollsqldb \ -B jdbc:payrollsqldb:payrollsql://localhost/ \ -J file://payrollsqldb.jar \ -S org.payrollsqldb.jdbcDriver payroll-src
SQL データベースのプロパティーで JDBC データソースを設定します。
$ dpconf set-jdbc-data-source-prop payroll-src \ db-user:proxy db-pwd-file:password-file-location/myPasswordFile
JDBC データソースを有効にします。
$ dpconf set-jdbc-data-source-prop payroll-src is-enabled:true
給与データベース用の JDBC データソースプールを作成します。
$ dpconf create-jdbc-data-source-pool payroll-pool
給与データソースをデータソースプールに接続します。
$ dpconf attach-jdbc-data-source payroll-pool payroll-src
仮想 DN の o=payroll で給与データベースの JDBC データビューを作成します。
$ dpconf create-jdbc-data-view payroll-view payroll-pool o=payroll
SQL データベースの各テーブルの JDBC テーブルを作成します。
$ dpconf create-jdbc-table jdbc-employee employee $ dpconf create-jdbc-table jdbc-salary salary
各 SQL テーブルの各列の JDBC 属性を作成します。
$ dpconf add-jdbc-attr jdbc-employee eid employee_id $ dpconf add-jdbc-attr jdbc-employee first firstname $ dpconf add-jdbc-attr jdbc-employee last lastname $ dpconf add-jdbc-attr jdbc-employee description description $ dpconf add-jdbc-attr jdbc-employee spouse spousename $ dpconf add-jdbc-attr jdbc-salary salary salary $ dpconf add-jdbc-attr jdbc-salary social ssn
JDBC データビューで表示できる属性と書き込める属性を指定します。
$ dpconf set-jdbc-data-view-prop payroll-view \ viewable-attr:eid \ viewable-attr:first \ viewable-attr:last \ viewable-attr:desc \ viewable-attr:spouse \ viewable-attr:salary \ viewable-attr:social $ dpconf set-jdbc-data-view-prop payroll-view \ writable-attr:eid \ writable-attr:first \ writable-attr:last \ writable-attr:description \ writable-attr:spouse \ writable-attr:salary \ writable-attr:social
LDAP オブジェクトクラスにマップされる JDBC オブジェクトクラスを作成します。
次のコマンドは、LDAP person オブジェクトクラスにマップされるオブジェクトクラスを作成します。オブジェクトクラスは、従業員テーブルは一次テーブルとして使用され、給与テーブルが二次テーブルとして使用されるよう指定します。eid 属性は、DN を構築するために使用されます。
$ dpconf create-jdbc-object-class payroll-view \ person jdbc-employee jdbc-salary eid
二次テーブルからのデータが一次テーブルからのデータにリンクされる方法を指定したフィルタ結合ルールを二次テーブル上で作成します。
次の結合ルールは、employee_id 属性に基づいてデータが結合されるよう指定します。
$ dpconf set-jdbc-table-prop jdbc-salary \ filter-join-rule:employee_id=\${employee.employee_id}
JDBC オブジェクトクラス上のスーパークラスを作成します。
$ dpconf set-jdbc-object-class-prop payroll-view person super-class:extensibleObject
LDAP ディレクトリ上のアクセス制御は、ディレクトリ自体で ACI を定義することで処理されます。仮想データビューによってデータソースにアクセスされる場合、これらのデータビューで表示されるデータのみに適用される ACI を定義する必要があります。
Directory Proxy Server を経由するアクセスはすべて、接続ハンドラによって制御されます。接続ハンドラについては、第 26 章「クライアントと Directory Proxy Server の接続」を参照してください。
ACI を追加します。
$ ldapadd -v -D "cn=proxy manager" -w password -p 389 dn: cn=ldifonly-acis,cn=virtual access controls objectclass: top objectclass: aciSource cn: ldifonly-acis dpsaci: (targetattr="*")(version 3.0; acl "anonymous_access"; allow(all) \ (userdn="ldap:///anyone");)
接続ハンドラで仮想 ACI をポイントします。
$ dpconf set-connection-handler-prop anonymous aci-source:ldifonly-acis
接続ハンドラを有効にします。
$ dpconf set-connection-handler-prop anonymous is-enabled:true
仮想データ変換は、既存のデータビュー上で定義され、仮想データビューを使用して仮想データを作成できるようにします。機能方法については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Virtual Data Transformations」を参照してください。
この章の内容は次のとおりです。
仮想データ変換は次のどの種類のデータビューにも追加できます。LDAP データビュー、LDIF データビュー、結合データビュー、または JDBC データビュー。
DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。
変換をデータビューに追加します。
$ dpconf add-virtual-transformation -h host -p port view-name \ transformation-model transformation-action attribute-name [parameters...] |
transformation-model は、mapping、write、および read 変換のいずれかです。
transformation-action は、add-attr、remove-attr、add-attr-value、remove-attr-value、def-value、および attr-value-mapping アクションのいずれかです。
transformation-model と transformation-action によっては、parameters は必須である場合があります。
変換のモデル、変換アクション、変換パラメータについては、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Virtual Data Transformations」を参照してください。
(省略可能) データビューで定義された仮想変換の一覧を表示します。
$ dpconf list-virtual-transformations -h host -p port view-name
次の節では、仮想データビューが必要なユースケースと、それらのユースケースの実装に必要な変換のモデルとアクションの組み合わせを示します。
次の変換ルールを使用して、エントリの既存の属性から属性を誘導します。たとえば、次の変換ルールを適用すると、givenName および sn 属性から派生した mail 属性が表示されます。
$ dpconf add-virtual-transformation dataview1 read add-attr \ mail \${givenName}.\${sn}@example.com |
次の図に、検索で返されるユーザーエントリで発生する変換を示します。
次のマッピング変換ルールを使用して、純粋な仮想属性の一部として配信された属性を追加します。たとえば、次の変換ルールを適用すると、givenName は、エントリで指定されていなくてもサーバーに格納されます。値は、mail \${givenName}@example.com として定義された純粋な仮想属性から取られます。
$ dpconf add-virtual-transformation dataview1 mapping add-attr \ mail \${givenName}@example.com |
まず、仮想属性として mail 属性を含み、givenName 属性を含まないエントリを追加します。仮想変換により、givenName 属性の値が生成され、エントリは givenName 属性とともに格納されますが、mail 属性は含まれていません。次に、uid 属性の使用時に検索を行いながら、givenName の値を取得すると、同じ仮想変換により、仮想属性 mail の値が生成されます。
次の図に、ユーザーエントリで発生する変換を示します。
次の変換を使用して、別の属性によって指定された属性の値を表示します。たとえば、uid を cn として表示するときに、すでにエントリに格納されている cn の値も表示できます。次の場合は、cn に追加の値は格納されませんが、結果がクライアントに返される前に変換が適用されます。
$ dpconf add-virtual-transformation dataview1 read add-attr-value cn \${uid} |
次の図に、検索で返されるユーザーエントリで発生する変換を示します。
次の変換ルールを使用して、属性の値と、新しいエントリを追加するときに指定した値を格納します。このシナリオでは、エントリを追加すると、mail 属性の追加の値が格納されます。この変換は、新しいエントリを作成するときだけ適用されます。
$ dpconf add-virtual-transformation dataview1 write add-attr-value \ mail \${uid}@example.com |
次の図に、追加要求で発生する変換を示します。
属性を出力に表示しない場合は、次の変換ルールを使用します。たとえば、次の変換ルールを適用すると、givenName は出力に返されません。
dpconf add-virtual-transformation dataview1 read remove-attr givenName |
次の図に、検索で返されるユーザーエントリで発生する変換を示します。
特定の属性を格納しない場合は、次の変換ルールを使用します。たとえば、次の変換ルールを適用すると、givenName 属性は物理データベースに格納されません。この変換は、新しいエントリを作成するときだけ適用されます。
$ dpconf add-virtual-transformation dataview1 write remove-attr givenName |
次の図に、追加要求で発生する変換を示します。
属性に割り当てられたデフォルト値を表示する場合は、次の変換を使用します。たとえば、次の変換を適用すると、それ自体の電話番号が含まれていないエントリのデフォルトの電話番号が表示されます。
$ dpconf add-virtual-transformation data-view read 11111 telephoneNumber default-number |
次の図に、検索で返されるユーザーエントリで発生する変換を示します。
デフォルト値は、エントリの作成時に属性の値が指定されない場合のみ格納されます。デフォルト値を持つ属性を格納する場合は、次の変換ルールを使用します。たとえば、次の変換を適用すると、作成するエントリごとにデフォルトの電話番号が追加されます。この変換は、エントリを追加するときだけ適用されます。
$ dpconf add-virtual-transformation dataview1 write 11111 \ telephoneNumber telephone-number |
次の図に、追加要求で発生する変換を示します。
この章では、Directory Proxy Server とバックエンド LDAP サーバーの接続の設定方法について説明します。この章の内容は次のとおりです。
LDAP データソースを作成した場合、その LDAP データソースに対して開かれるデフォルトの接続数は 6 で、読み取り操作、バインド操作、および書き込み操作にそれぞれ 2 つずつ使用されます。デフォルトの接続数を確認するには、次のコマンドを入力します。
dpconf get-ldap-data-source-prop src-name num-read-init num-write-init num-bind-init num-bind-init : 2 num-read-init : 2 num-write-init : 2 |
接続数は、トラフィックが増加すると自動的に増やされます。
Directory Proxy Server とバックエンド LDAP サーバーの接続の設定方法については、次の手順を参照してください。
この手順では、バインド操作の接続数を設定します。読み取り操作または書き込み操作の接続数を設定するには、同じ手順を実行しますが bind を read または write に置き換えます。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
バインド操作のための Directory Proxy Server とバックエンド LDAP サーバーの接続数の初期値を設定します。
$ dpconf set-ldap-data-source-prop -h host -p port data-source-name \ num-bind-init:new-value |
バインド操作のための接続の増分を設定します。
増分は、現在の数より多い接続が要求されるたびに追加される接続数です。
$ dpconf set-ldap-data-source-prop -h host -p port data-source-name \ num-bind-incr:new-value |
バインド操作のための接続の最大数を設定します。
この接続の最大数に達すると、それ以上接続を追加できなくなります。
$ dpconf set-ldap-data-source-prop -h host -p port data-source-name \ num-bind-limit:new-value |
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
Directory Proxy Server がデータソースに接続し続けることのできる最長時間を設定します。
$ dpconf set-ldap-data-source-prop -h host -p port data-source-name \ connect-timeout:new-value |
たとえば、接続のタイムアウトを 10 ミリ秒に設定します。
$ dpconf set-ldap-data-source-prop -h host1 -p 1389 data-source-name connect-timeout:10 |
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
Directory Proxy Server が接続プール内の確立された接続を使用できるようになるまで待機できる最長時間を設定します。
$ dpconf set-server-prop -h host -p port data-source-name \ connection-pool-wait-timeout:value |
たとえば、タイムアウトを 20 秒に設定します。
$ dpconf set-ldap-data-source-prop -h host1 -p 1389 data-source-name \ connection-pool-wait-timeout:20000 |
次の手順では、Directory Proxy Server とバックエンド LDAP サーバーとの間の SSL の設定方法を説明しています。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
Directory Proxy Server とバックエンド LDAP サーバー間のセキュアポートを設定します。
$ dpconf set-ldap-data-source-prop -h host -p port data-source-name \ ldaps-port:port-number |
Directory Proxy Server とバックエンド LDAP サーバーの接続にいつ SSL が使用されるかを設定します。
$ dpconf set-ldap-data-source-prop -h host -p port data-source-name ssl-policy:value |
value が always の場合、接続に常に SSL が使用されます。
value が client の場合、クライアントが SSL を使用している場合に SSL が使用されます。
接続が SSL を使用していない場合、startTLS コマンドを使用して SSL への接続をプロモートできます。
Transport Layer Security (TLS) は SSL の標準バージョンです。TLS over LDAP は、IETF 認可の、LDAP をセキュリティー保護する標準の方法です。LDAPS は事実上の標準ですが、サービス用のポートが 1 つだけでなく 2 つあるなど、いくぶん複雑な面があります。
「Directory Proxy Server の SSL 暗号化方式と SSL プロトコルの選択」で説明されているように、SSL のプロトコルと暗号化方式を選択します。
バックエンド LDAP サーバーからの SSL サーバー証明書を検証するよう Directory Proxy Server を設定します。
詳細は、「証明書をバックエンド LDAP サーバーから Directory Proxy Server 上の証明書データベースに追加する」を参照してください。
バックエンド LDAP サーバーが Directory Proxy Server からの証明書を要求する場合は、SSL クライアント証明書を送信するよう Directory Proxy Server を設定します。
詳細については、「バックエンド LDAP サーバーへの証明書のエクスポート」を参照してください。
変更を有効にするために Directory Proxy Server のインスタンスを再起動します。
Directory Proxy Server の再起動については、「Directory Proxy Server を再起動する」を参照してください。
Directory Proxy Server で使用できる暗号化方式とプロトコルは、使用している JavaTM 仮想マシン (JVMTM) によって異なります。デフォルトで、Directory Proxy Server は JVM マシンで有効なデフォルトの暗号化方式とプロトコルを使用します。
この手順に従って、サポートされている暗号化方式とプロトコルおよび有効な暗号化方式とプロトコルを取得します。暗号化方式またはプロトコルがサポートされている場合は、それを有効または無効にできます。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
サポートされている暗号化方式とプロトコルの一覧を表示します。
$ dpconf get-server-prop -h host -p port supported-ssl-cipher-suites \ supported-ssl-protocols |
有効な暗号化方式とプロトコルの一覧を表示します。
$ dpconf get-server-prop -h host -p port enabled-ssl-cipher-suites \ enabled-ssl-protocols |
1 つまたは複数のサポートされている暗号化方式またはプロトコルを有効にします。
1 つまたは複数のサポートされている暗号化方式を有効にします。
$ dpconf set-server-prop -h host -p port \ enabled-ssl-cipher-suites:supported-ssl-cipher-suite \ [enabled-ssl-cipher-suites:supported-ssl-cipher-suite ...] |
サポートされている暗号化方式の既存リストに暗号化方式を追加するには、次のコマンドを使用します。
$ dpconf set-server-prop -h host -p port \ enabled-ssl-cipher-suites+:supported-ssl-cipher-suite |
1 つまたは複数のサポートされているプロトコルを有効にします。
$ dpconf set-server-prop -h host -p port \ enabled-ssl-cipher-protocols:supported-ssl-cipher-protocol \ [enabled-ssl-cipher-protocols:supported-ssl-cipher-protocol ...] |
サポートされているプロトコルの既存リストにプロトコルを追加するには、次のコマンドを使用します。
$ dpconf set-server-prop -h host -p port \ enabled-ssl-cipher-protocols+:supported-ssl-cipher-protocol |
(省略可能) サポートされている暗号化方式またはプロトコルを無効にします。
$ dpconf set-server-prop -h host -p port \ enabled-ssl-cipher-protocols-:supported-ssl-cipher-protocol |
この節では、Directory Proxy Server からの要求をバックエンド LDAP サーバーに転送するためのさまざまな方法について説明します。
Directory Proxy Server のクライアント資格のバインド再実行については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Directory Proxy Server Configured for BIND Replay」を参照してください。次の手順は、Directory Proxy Server からの要求をバックエンド LDAP サーバーにバインド再実行を使用して転送する方法について説明しています。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
クライアントによって提供された資格を使用してバックエンド LDAP サーバーへの接続を認証するデータソースクライアント資格を設定します。
$ dpconf set-ldap-data-source-prop -h host -p port data-source-name \ client-cred-mode:use-client-identity |
Directory Proxy Server 内のプロキシ承認については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Directory Proxy Server Configured for Proxy Authorization」を参照してください。
この節では、プロキシ承認とプロキシ承認制御を使用して要求を転送する手順について説明します。
version 1 または version 2 のプロキシ承認制御を受け入れるようデータソースを設定します。
たとえば、version 1 のプロキシ承認制御を受け入れるようデータソースを設定します。
$ dpconf set-ldap-data-source-prop -h host -p port data-source-name \ proxied-auth-use-v1:true |
または、version 2 のプロキシ承認制御を受け入れるようデータソースを設定します。
$ dpconf set-ldap-data-source-prop -h host -p port data-source-name \ proxied-auth-use-v1:false |
プロキシ承認を使用してバックエンド LDAP サーバーへの接続を認証するようデータソースを設定します。
$ dpconf set-ldap-data-source-prop -h host -p port data-source-name \ client-cred-mode:use-proxy-auth |
書き込み操作のみのため、プロキシ承認を使用してバックエンド LDAP サーバーへの接続を認証するようデータソースを設定するには、次のコマンドを実行します。
$ dpconf set-ldap-data-source-prop -h host -p port data-source-name \ client-cred-mode:use-proxy-auth-for-write |
書き込み操作のみがプロキシ承認制御で実行される場合、クライアントのアイデンティティーは読み取り要求のために LDAP サーバーに転送されません。クライアントアイデンティティーのない要求の転送の詳細については、「クライアントアイデンティティーなしでの要求の転送」を参照してください。
Directory Proxy Server のバインド資格でデータソースを設定します。
$ dpconf set-ldap-data-source-prop -h host -p port data-source-name \ bind-dn:DPS-bind-dn bind-pwd-file:filename |
タイムアウトでデータソースを設定します。
$ dpconf set-ldap-data-source-prop -h host -p port data-source-name \ proxied-auth-check-timeout:value |
Directory Proxy Server は、getEffectiveRights コマンドを使用して、プロキシ承認に適した ACI がクライアント DN にあることを確認します。その結果は Directory Proxy Server のキャッシュに格納され、proxied-auth-check-timeout の期限が終了すると更新されます。
必要に応じて、変更を有効にするために Directory Proxy Server のインスタンスを再起動します。
Directory Proxy Server の再起動については、「Directory Proxy Server を再起動する」を参照してください。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
version 1、version 2、またはその両方のプロキシ承認制御を受け入れるよう Directory Proxy Server を設定します。
$ dpconf set-server-prop -h host -p port allowed-ldap-controls:proxy-auth-v1 \ allowed-ldap-controls:proxy-auth-v2 |
次の手順は、クライアントアイデンティティーを転送せずに Directory Proxy Server からの要求をバックエンド LDAP サーバーに転送する方法について説明しています。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
Directory Proxy Server の資格を使用してバックエンド LDAP サーバーへの接続を認証するようデータソースを設定します。
$ dpconf set-ldap-data-source-prop -h host -p port data-source-name \ client-cred-mode:use-specific-identity |
Directory Proxy Server のバインド資格でデータソースを設定します。
$ dpconf set-ldap-data-source-prop -h host -p port data-source-name \ bind-dn:bind-dn-of-DPS bind-pwd-file:filename |
必要に応じて、変更を有効にするために Directory Proxy Server のインスタンスを再起動します。
Directory Proxy Server の再起動については、「Directory Proxy Server を再起動する」を参照してください。
ここでは、代替ユーザーとして要求を転送する方法について説明します。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
代替ユーザーで転送が行えるように設定を有効にします。
$ dpconf set-server-prop -h host -p port enable-user-mapping:true |
リモートマッピング用の ID を含む属性の名前を指定します。
$ dpconf set-server-prop -h host -p port \ remote-user-mapping-bind-dn-attr:attribute-name |
Directory Proxy Server がクライアント ID をリモートでマップできるようにします。
$ dpconf set-server-prop -h host -p port enable-remote-user-mapping:true |
デフォルトマッピングを設定します。
$ dpconf set-server-prop -h host -p port \ user-mapping-default-bind-dn:default-mapping-bind-dn \ user-mapping-default-bind-pwd-file:filename |
マップしたアイデンティティーがリモート LDAP サーバー上に見つからない場合、クライアントアイデンティティーはデフォルトアイデンティティーにマップされます。
リモート LDAP サーバー上のクライアントのエントリでユーザーマッピングを設定します。
Directory Server でのユーザーマッピングの設定については、「プロキシ承認」を参照してください。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
代替ユーザーで転送が行えるように設定を有効にします。
$ dpconf set-server-prop -h host -p port enable-user-mapping:true |
Directory Proxy Server がクライアント ID をリモートでマップする設定がされていないことを確認します。
$ dpconf set-server-prop -h host -p port enable-remote-user-mapping:false |
デフォルトマッピングを設定します。
$ dpconf set-server-prop -h host -p port \ user-mapping-default-bind-dn:default-mapping-bind-dn \ user-mapping-default-bind-pwd-file:filename |
リモート LDAP サーバー上のマッピングに失敗すると、クライアント ID がこの DN にマップされます。
認証されていないユーザーに操作の実行を許可する場合は、認証されていないクライアントに対するマッピングを設定します。
$ dpconf set-server-prop -h host -p port \ user-mapping-anonymous-bind-dn:anonymous-mapping-bind-dn \ user-mapping-anonymous-bind-pwd-file:filename |
認証されていないユーザーに操作の実行を許可する方法については、「匿名アクセスを設定する」を参照してください。
クライアントの ID を設定します。
$ dpconf set-user-mapping-prop -h host -p port \ user-bind-dn:client-bind-dn user-bind-pwd-file:filename |
代替ユーザーの ID を設定します。
$ dpconf set-user-mapping-prop -h host -p port \ mapped-bind-dn:alt-user-bind-dn mapped-bind-pwd-file:filename |
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
認証されていないクライアントのマッピングを設定します。
$ dpconf set-server-prop -h host -p port \ user-mapping-anonymous-bind-dn:anonymous-mapping-bind-dn \ user-mapping-anonymous-bind-pwd-file:filename |
リモート LDAP サーバーには匿名クライアントのエントリが含まれていないため、匿名クライアントのマッピングは、Directory Proxy Server で設定されます。
認証されていないユーザーへの操作の実行の許可については、「匿名アクセスを設定する」を参照してください。
クライアントと Directory Proxy Server の接続の概要、接続ハンドラ、および接続ハンドラで使用される条件とポリシーの説明については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 20 章「Connections Between Clients and Directory Proxy Server」を参照してください。
この章の内容は次のとおりです。
接続ハンドラの作成、設定、削除の方法と、データビューに対するアフィニティーの設定方法については、次の手順を参照してください。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
接続ハンドラを作成します。
$ dpconf create-connection-handler -h host -p port connection-handler-name |
(省略可能) 接続ハンドラのリストを表示します。
$ dpconf list-connection-handlers -h host -p port |
接続ハンドラのプロパティーは、Directory Proxy Server インスタンスに定義されているその他の接続ハンドラのプロパティーに関連して定義する必要があります。さまざまな基準のセットを確実に指定し、正しい優先順位を設定するため、すべての接続ハンドラのプロパティーを考慮してください。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
接続ハンドラの詳細リストを表示して、それらのキープロパティーと対応する優先順位を確認します。
$ dpconf list-connection-handlers -h host -p port -v Name is-enabled priority description -------------------------- ---------- -------- --------------------------- anonymous false 99 unauthenticated connections default connection handler true 100 default connection handler |
接続ハンドラ anonymous および default connection handler は、Directory Proxy Server のインスタンスの作成時に作成されます。
1 つの接続ハンドラのすべてのプロパティーを表示します。
$ dpconf get-connection-handler-prop -h host -p port connection-handler-name |
新しい接続ハンドラのデフォルトプロパティーは、次のようになります。
aci-source : - allowed-auth-methods : anonymous allowed-auth-methods : sasl allowed-auth-methods : simple allowed-ldap-ports : ldap allowed-ldap-ports : ldaps bind-dn-filters : any data-view-routing-custom-list : - data-view-routing-policy : all-routable description : - domain-name-filters : any enable-data-view-affinity : false ip-address-filters : any is-enabled : false is-ssl-mandatory : false priority : 99 request-filtering-policy : no-filtering resource-limits-policy : no-limits schema-check-enabled : false user-filter : any |
接続ハンドラの優先順位を設定します。
$ dpconf set-connaection-handler-prop -h host -p port connection-handler-name priority:value |
優先順位は 1 〜 100 の任意の数にすることができ、もっとも高い優先順位は 1 です。Directory Proxy Server のインスタンスでは、接続ハンドラは優先順位の順に評価されます。
(省略可能) 接続ハンドラの DN フィルタリングプロパティーを指定します。
このプロパティーにより、バインド DN の一部またはすべてに基づいてアクセスを制御できます。プロパティーの値は正規表現です。
$ dpconf set-connection-handler-prop -h host -p port connection-handler-name \ bind-dn-filters:regular-expression |
バインド DN フィルタは、JavaTM 正規表現の形式をとります。Java 正規表現の作成については、http://java.sun.com/j2se/1.4.2/docs/api/java/util/regex/Pattern.html を参照してください。
たとえば、すべてのバインドを ou=people,dc=example,dc=com の下のユーザーから secure-handler という接続ハンドラに送信するには、次のように bind-dn-filters プロパティーを設定します。
$ dpconf set-connection-handler-prop -h host1 -p 1389 secure-handler \ bind-dn-filters:"uid=.*,ou=people,dc=example,dc=com" |
(省略可能) この接続ハンドラで使用する要求フィルタリングポリシーの名前を指定します。
$ dpconf set-connection-handler-prop -h host -p port connection-handler-name \ request-filtering-policy:policy-name |
ここで、policy-name は既存の要求フィルタリングポリシーの名前です。要求フィルタリングポリシーの作成と設定の方法については、「要求フィルタリングポリシーと検索データの非表示ルールの作成と設定」を参照してください。
(省略可能) この接続ハンドラで使用するリソース制限ポリシーの名前を指定します。
$ dpconf set-connection-handler-prop -h host -p port connection-handler-name \ resource-limits-policy:policy-name |
ここで、policy-name は既存のリソース制限ポリシーの名前です。リソース制限ポリシーの作成と設定の方法については、「リソース制限ポリシーの作成と設定」を参照してください。
手順 2 で一覧表示されるほかのプロパティーを設定します。
$ dpconf set-connection-handler-prop -h host -p port connection-handler-name \ property:value [property:value ...] |
たとえば、SSL 接続のみを受け付けるように接続ハンドラを設定します。
$ dpconf set-connection-handler-prop -h host -p port connection-handler-name \ is-ssl-mandatory:true |
プロパティーとその有効な値のリストについては、次のコマンドを実行します。
$ dpconf help-properties connection-handler |
接続ハンドラを有効にします。
$ dpconf set-connection-handler-prop -h host -p port connection-handler-name is-enabled:true |
必要に応じて、変更を有効にするために Directory Proxy Server のインスタンスを再起動します。
Directory Proxy Server の再起動については、「Directory Proxy Server を再起動する」を参照してください。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
(省略可能) 接続ハンドラのリストを表示します。
$ dpconf list-connection-handlers -h host -p port |
1 つまたは複数の接続ハンドラを削除します。
$ dpconf delete-connection-handler -h host -p port connection-handler-name [connection-handler-name ... ] |
接続ハンドラに接続を割り当てると、その接続にある要求は、その接続ハンドラに設定されているデータビューのリスト、または設定されている データビューのすべてに公開されます。その接続のそれ以降の要求は、最初の要求に対して使われるデータビューに排他的に公開されます。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
データビューに対するアフィニティーを有効にします。
$ dpconf set-connection-handler-prop -h host -p port connection-handler-name \ enable-data-view-affinity:true |
(省略可能) 要求をデータビューのカスタムリストに経路指定するように接続ハンドラを設定します。
$ dpconf set-connection-handler-prop -h host -p port connection-handler-name data-view-routing-policy:custom |
(省略可能) データビューのリストを設定します。
$ dpconf set-connection-handler-prop -h host -p port connection-handler-name \ data-view-routing-custom-list:view-name [data-view-routing-custom-list:view-name ...] |
データビューの既存リストにデータビューを追加するには、次のコマンドを使用します。
$ dpconf set-connection-handler-prop -h host -p port connection-handler-name \ data-view-routing-custom-list+:view-name |
データビューの既存リストからデータビューを削除するには、次のコマンドを使用します。
$ dpconf set-connection-handler-prop -h host -p port connection-handler-name \ data-view-routing-custom-list-:view-name |
要求フィルタリングポリシーの概要は、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Request Filtering Policies for Connection Handlers」を参照してください。検索データの非表示ルールの概要は、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Search Data Hiding Rules in the Request Filtering Policy」を参照してください。
要求フィルタリングポリシーと検索データの非表示ルールの作成と設定の方法については、次の手順を参照してください。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
要求フィルタリングポリシーを作成します。
$ dpconf create-request-filtering-policy policy-name |
要求フィルタリングポリシーを接続ハンドラと関連付けます。
$ dpconf set-connection-handler-prop -h host -p port connection-handler-name \ request-filtering-policy:policy-name |
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
要求フィルタリングポリシーのプロパティーを表示します。
$ dpconf get-request-filtering-policy-prop -h host -p port policy-name |
要求フィルタリングポリシーのデフォルトプロパティーは次のとおりです。
allow-add-operations : true allow-bind-operations : true allow-compare-operations : true allow-delete-operations : true allow-extended-operations : true allow-inequality-search-operations : true allow-modify-operations : true allow-rename-operations : true allow-search-operations : true allowed-comparable-attrs : all allowed-search-scopes : base allowed-search-scopes : one-level allowed-search-scopes : subtree allowed-subtrees : "" description : - prohibited-comparable-attrs : none prohibited-subtrees : none |
手順 1 で一覧表示されるプロパティーの 1 つまたは複数を設定することで、要求フィルタリングポリシーを設定します。
$ dpconf set-request-filtering-policy-prop -h host -p port policy-name \ property:value [property:value ...] |
手順 1 で一覧表示されるプロパティーを設定することで、次のような要求フィルタリングポリシーの機能を設定します。
クライアントに実行が許可されている操作のタイプ
クライアントに公開されるサブツリー、またはクライアントから非表示にされるサブツリー
検索操作の範囲
検索フィルタのタイプ
検索操作と比較操作で比較できる属性と比較できない属性のタイプ
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
要求フィルタリングポリシーに対して、1 つまたは複数の検索データ非表示ルールを作成します。
$ dpconf create-search-data-hiding-rule -h host -p port policy-name rule-name \ [rule-name ...] |
検索データ非表示ルールのプロパティーを表示します。
$ dpconf get-search-data-hiding-rule-prop policy-name rule-name |
検索データ非表示ルールのデフォルトプロパティーは、次のとおりです。
attrs : - rule-action : hide-entry target-attr-value-assertions : - target-dn-regular-expressions : - target-dns : - |
手順 2 で一覧表示されるプロパティーの 1 つまたは複数を設定することで、検索データ非表示ルールを設定します。
$ dpconf set-search-data-hiding-rule-prop -h host -p port policy-name rule-name \ property:value [property:value ...] |
次のいずれかのルールアクションを使用できます。
ターゲットエントリは返されません。
ターゲットエントリは返されますが、指定した属性は表示されません。
ターゲットエントリは返されますが、指定した属性以外は表示されません。
ルールは次のエントリに適用できます。
指定した DN を持つエントリ
指定した DN パターンを持つエントリ
指定した属性名と属性値のペアを持つエントリ (attrName#attrValue )
次の設定では、タイプ inetorgperson のエントリを非表示にする検索データ非表示ルールを定義します。
$ dpconf set-search-data-hiding-rule-prop -h host1 -p port my-policy my-rule \ target-attr-value-assertions:objectclass#inetorgperson |
次の例には、要求フィルタリングポリシーと検索データ非表示ルールが含まれます。要求フィルタリングポリシーを検索データ非表示ルールと組み合わせると、次のようにデータへのアクセスが制限されます。
次のタイプの操作は許可されません。追加、削除、拡張、変更、名前変更。
アクセスできるのは、ou=people,dc=sun,dc=com サブツリーだけです。
検索操作では inetorgperson タイプ以外のエントリが返されます。
allow-add-operations : false allow-bind-operations : true allow-compare-operations : true allow-delete-operations : false allow-extended-operations : false allow-inequality-search-operations : true allow-modify-operations : false allow-rename-operations : false allow-search-operations : true allowed-comparable-attrs : all allowed-search-scopes : base allowed-search-scopes : one-level allowed-search-scopes : subtree allowed-subtrees : ou=people,dc=sun,dc=com description : myRequestFilteringPolicy prohibited-comparable-attrs : none prohibited-subtrees : none |
attrs : - rule-action : hide-entry target-attr-value-assertions : objectclass:inetorgperson target-dn-regular-expressions : - target-dns : - |
リソース制限ポリシーの概要については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Resource Limits Policies for Connection Handlers」を参照してください。リソース制限ポリシーを作成する方法と検索制限をカスタマイズする方法については、次の手順を参照してください。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
リソース制限ポリシーを作成します。
$ dpconf create-resource-limits-policy -h host -p port policy-name |
リソース制限ポリシーのプロパティーを変更する方法については、「リソース制限ポリシーを設定する」を参照してください。
リソース制限ポリシーを接続ハンドラに関連付けます。
$ dpconf set-connection-handler-prop -h host -p port connection-handler-name \ resource-limits-policy:policy-name |
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
リソース制限ポリシーのプロパティーを表示します。
$ dpconf get-resource-limits-policy-prop -h host -p port policy-name |
リソース制限ポリシーのデフォルトプロパティーは次のとおりです。
description : - max-client-connections : unlimited max-connections : unlimited max-simultaneous-operations-per-connection : unlimited max-total-operations-per-connection : unlimited minimum-search-filter-substring-length : unlimited referral-bind-policy : default referral-hop-limit : default referral-policy : default search-size-limit : unlimited search-time-limit : unlimited |
手順 1 で一覧表示されるプロパティーの 1 つまたは複数を設定することで、リソース制限ポリシーを設定します。
$ dpconf set-resource-limits-policy-prop -h host -p port policy-name \ property:value [property:value ...] |
検索ベースと検索範囲に従って行われる検索操作に対して、カスタマイズした検索制限を定義することができます。検索操作のターゲット DN と範囲が指定した条件と一致すると、検索結果で返されるエントリの数が制限されます。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
1 つまたは複数のカスタムの検索制限を作成します。
$ dpconf create-custom-search-size-limit -h host -p port policy-name \ custom-search-limit-name [custom-search-limit-name ...] |
カスタムの検索制限に対する条件を設定します。
$ dpconf set-custom-search-size-limit-prop -h host -p port policy-name \ custom-search-limit-name one-level-search-base-dn:value subtree-search-base-dn:value |
手順 2 で検索が条件の 1 つを満たす場合に返される結果の数の制限を設定します。
$ dpconf set-custom-search-size-limit-prop -h host -p port policy-name \ custom-search-limit-name search-size-limit:value |
カスタムの検索制限のプロパティーを表示します。
$ dpconf get-custom-search-size-limit-prop -h host -p port policy-name \ custom-search-limit-name |
カスタムの検索制限のデフォルトプロパティーは、次のとおりです。
one-level-search-base-dn : - search-size-limit : unlimited subtree-search-base-dn : - |
Directory Proxy Server 5.2 は接続ベースのルーターです。Directory Proxy Server 5.2 では、クライアント接続は特定のディレクトリサーバーに経路指定されます。そのクライアント接続のすべての要求は、接続が切断されるかクライアントがアンバインドされるまでは、同じディレクトリサーバーに送信されます。
Directory Proxy Server 6.3 は、操作ベースのルーターです。ただし、互換性のため、このバージョンの Directory Proxy Server は、次の手順で説明するように接続ベースのルーターとして設定できます。
「接続ハンドラの作成、設定、削除」で説明するように、1 つまたは複数の接続ハンドラを作成し、設定します。
デフォルトの接続ハンドラを使用することもできます。
要求を root data view のみに経路指定するように、すべての接続ハンドラを設定します。
次に例を示します。
$ dpconf set-connection-handler-prop -h host1 -p 1389 myConnectionHandler \ data-view-routing-policy:custom data-view-routing-custom-list:"root data view" |
「LDAP データソースの作成と設定」で説明するように、各 バックエンド LDAP サーバーのデータソースを作成し設定します。
次に例を示します。
$ dpconf create-ldap-data-source -h host1 -p 1389 myDataSource host2:2389 |
「LDAP データソースプールの作成と設定」で説明するように、データソースプールを作成し設定します。
次に例を示します。
$ dpconf create-ldap-data-source-pool -h host1 -p 1389 myDataSourcePool |
「LDAP データソースのデータソースプールへの接続」で説明するように、すべてのデータソースをデータソースプールに接続します。
次に例を示します。
$ dpconf attach-ldap-data-source -h host1 -p 1389 myDataSourcePool myDataSource |
「バインド再実行での要求の転送」で説明するように、BIND 再実行を使用してクライアントを認証するように各データソースを設定します。
次に例を示します。
$ dpconf set-ldap-data-source-prop -h host1 -p 1389 myDataSource \ client-cred-mode:use-client-identity |
「クライアントアフィニティーの設定」で説明するように、クライアント接続とデータソースプール間のアフィニティーを設定します。
次に例を示します。
$ dpconf set-ldap-data-source-pool-prop -h host1 -p 1389 myDataSourcePool \ enable-client-affinity:true client-affinity-policy:read-write-affinity-after-write |
Directory Proxy Server のクライアント認証の概要については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 21 章「Directory Proxy Server Client Authentication」を参照してください。
この章の内容は次のとおりです。
Directory Proxy Server には、クライアントとの通信のために、セキュリティー保護されたリスナーとセキュリティー保護されていないリスナーがあります。Directory Proxy Server のリスナーについては、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Directory Proxy Server Client Listeners」を参照してください。ここでは、リスナーの設定方法について説明します。
この手順では、クライアントと Directory Proxy Server 間のセキュリティー保護されていないリスナーを設定します。セキュリティーが確保されているリスナーを設定するには、手順は同じですが、ldap を ldaps に置き換えます。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。 DSCC では、このプロパティーを「パフォーマンス」タブで設定できます。
セキュリティー保護されていないリスナーのプロパティーを表示します。
$ dpconf get-ldap-listener-prop -h host -p port |
セキュリティー保護されていないリスナーのデフォルトプロパティーは、次のとおりです。
connection-idle-timeout : 1h connection-read-data-timeout : 2s connection-write-data-timeout : 1h is-enabled : true listen-address : 0.0.0.0 listen-port : port-number max-connection-queue-size : 128 max-ldap-message-size : unlimited number-of-threads : 2 use-tcp-no-delay : true |
手順 1に一覧表示されているプロパティーの 1 つまたは複数を要件に応じて変更します。
$ dpconf set-ldap-listener-prop -h host -p port property:new-value |
たとえば、host1 で実行されている Directory Proxy Server のインスタンスのセキュリティー保護されていないポートを無効にするには、次のコマンドを実行します。
$ dpconf set-ldap-listener-prop -h host1 -p 1389 is-enabled:false |
非特権ポート番号を使用する場合は、Directory Proxy Server を root として実行する必要があります。
セキュリティー保護されていないポート番号を変更するには、次のコマンドを実行します。
$ dpconf set-ldap-listener-prop -h host -p port listen-port:new-port-number |
必要に応じて、変更を有効にするために Directory Proxy Server のインスタンスを再起動します。
特定のリスナープロパティーの変更には、サーバーの再起動が必要です。サーバーの再起動が必要な場合は、dpconf アラートが表示されます。Directory Proxy Server の再起動については、「Directory Proxy Server を再起動する」を参照してください。
デフォルトでは、Directory Proxy Server は単純バインド認証用に設定されています。単純バインド認証では、追加の設定は必要ありません。
クライアントと Directory Proxy Server 間の認証については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Client Authentication Overview」を参照してください。認証の設定方法については、次の手順を参照してください。
クライアントの証明書ベースの認証については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Configuring Certificates in Directory Proxy Server」を参照してください。この節では、証明書ベースの認証の設定方法について説明します。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
証明書ベースの認証は、SSL 接続でのみ実行できます。
クライアントが SSL 接続を確立する場合に証明書の提示を必要とするように Directory Proxy Server を設定します。
$ dpconf set-server-prop -h host -p port allow-cert-based-auth:require |
匿名アクセスについては、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Anonymous Access」を参照してください。匿名クライアントのアイデンティティーを別のアイデンティティーにマップする方法については、「代替ユーザーとしての要求の転送」を参照してください。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
SASL 外部バインドについては、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Using SASL External Bind」を参照してください。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
非認証操作を禁止します。
$ dpconf set-server-prop -h host -p port allow-unauthenticated-operations:false |
接続の確立時に証明書を提示するようクライアントに求めます。
$ dpconf set-server-prop -h host -p port allow-cert-based-auth:require |
クライアントが DN が含まれた証明書を提供します。
SASL 外部バインドによってクライアントの認証を有効にします。
$ dpconf set-server-prop -h host -p port allow-sasl-external-authentication:true |
バックエンド LDAP サーバーでクライアント証明書をマップするために Directory Proxy Server に使用されアイデンティティーを設定します。
$ dpconf set-server-prop -h host -p port cert-search-bind-dn:bind-DN \ cert-search-bind-pwd-file:filename |
Directory Proxy Server が検索するサブツリーのベース DN を設定します。
Directory Proxy Server がサブツリーを検索し、クライアント証明書にマップされたユーザーエントリを見つけます。
$ dpconf set-server-prop -h host -p port cert-search-base-dn:base-DN |
クライアント証明書の情報を LDAP サーバー上の証明書にマップします。
証明書を含む LDAP サーバー上の属性に名前を付けます。
$ dpconf set-server-prop cert-search-user-attribute:attribute |
クライアント証明書上の属性を、証明書のある LDAP サーバー上のエントリの DN にマップします。
$ dpconf set-server-prop -h host -p port \ cert-search-attr-mappings:client-side-attribute-name:server-side-attribute-name |
たとえば、DN が cn=user1,o=sun,c=us のクライアント証明書を DN が uid=user1,o=sun の LDAP エントリにマップするには、次のコマンドを実行します。
$ dpconf set-server-prop -h host1 -p 1389 cert-search-attr-mappings:cn:uid \ cert-search-attr-mappings:o:o |
(省略可能) SASL 外部バインド操作の要求をすべてのデータビューまたはデータビューのカスタムリストに経路指定します。
すべてのデータビューに要求を経路指定するには、次のコマンドを実行します。
$ dpconf set-server-prop -h host -p port cert-data-view-routing-policy:all-routable |
データビューのリストに要求を経路指定するには、次のコマンドを実行します。
$ dpconf set-server-prop -h host -p port cert-data-view-routing-policy:custom \ cert-data-view-routing-custom-list:view-name [view-name...] |
Directory Proxy Server では、アクセスログおよびエラーログに情報が記録されます。Directory Server とは異なり、Directory Proxy Server には監査ログはありません。Directory Proxy Server のログについては、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 23 章「Directory Proxy Server Logging」を参照してください。
この章の内容は次のとおりです。
Directory Proxy Server のログは、ログファイルを直接表示するか、Directory Service Control Center (DSCC) を通して参照できます。
デフォルトでは、ログは次のディレクトリ内に格納されます。
instance-path/logs |
次の図は、DSCC 上の Directory Proxy Server のエラーログの画面キャプチャーです。
Directory Proxy Server のエラーログとアクセスログは、dpconf コマンドまたは DSCC を使用することで設定できます。DSCC によるログの設定方法については、Directory Proxy Server のオンラインヘルプを参照してください。この節では、dpconf コマンドを使用して Directory Proxy Server のログを設定する方法について説明します。
次のコマンドを実行することで、設定オプションのリストを、個々のオプションで設定可能な値およびデフォルトの設定値の情報とともに取得できます。
$ dpconf help-properties error-log
$ dpconf help-properties access-log
この手順では、Directory Proxy Server のアクセスログを設定します。Directory Proxy Server のエラーログを設定する場合には、以下の手順に出てくる「access」を「error」に置き換えて、同じ手順を実行します。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
アクセスログのプロパティーを表示します。
$ dpconf get-access-log-prop -h host -p port |
アクセスログのデフォルトプロパティーは、次のとおりです。
default-log-level : info enable-log-rotation : true log-buffer-size : 9.8k log-file-name : logs/access log-file-perm : 600 log-level-client-connections : - log-level-client-disconnections : - log-level-client-operations : - log-level-connection-handlers : - log-level-data-sources : - log-level-data-sources-detailed : - log-min-size : 100M log-rotation-frequency : 1h log-rotation-policy : size log-rotation-size : 100M log-rotation-start-day : 1 log-rotation-start-time : 0000 log-search-filters : false max-age : unlimited max-log-files : 10 max-size : unlimited min-free-disk-space-size : 1M |
手順 1 で一覧表示されるプロパティーのうち、1 つまたは複数を変更します。
$ dpconf set-access-log-prop -h host -p port property:value \ [property:value ...] |
たとえば、すべてのメッセージカテゴリのデフォルトのログレベルを warning に設定するには、default-log-level プロパティーの値を warning に設定します。
$ dpconf set-access-log-prop -h host1 -p 1389 default-log-level:warning |
すべてのログを無効にするには、各メッセージカテゴリのログレベルに関係なく、default-log-level プロパティーの値を none に設定します。
$ dpconf set-access-log-prop -h host1 -p 1389 default-log-level:none |
特定のログレベルをデフォルトのログレベルにリセットするには、該当のログレベルのプロパティーを inherited に設定します。たとえば、クライアント接続のログレベルをリセットするには、次のコマンドを実行します。
$ dpconf set-access-log-prop -h host1 -p 1389 log-level-client-connections:inherited |
set-access-log-prop サブコマンドで設定できるプロパティーを調べるには、次のように入力します。
$ dpconf help-properties access-log |
デフォルトでは、ログファイルのサイズが 100M バイトに達すると、ログファイルのローテーションが行われます。デフォルトでは 10 個のログファイルが保存され、それ以降はローテーション手順によってもっとも古いログファイルの上書きが始められます。この節では、Directory Proxy Server ログを予定されたローテーションに対して設定する方法、ログのローテーションを手動で行う方法、ログのローテーションを無効にする方法について説明します。設定例は、「ログローテーションの設定例」を参照してください。
この手順では、Directory Proxy Server のアクセスログを設定します。Directory Proxy Server のエラーログを設定する場合には、以下の手順に出てくる「access」を「error」に置き換えて、同じ手順を実行します。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
(省略可能) アクセスログのプロパティーを表示します。
$ dpconf get-access-log-prop -h host -p port |
(省略可能) アクセスログのプロパティーに対して有効な値を表示します。
$ dpconf help-properties access-log
一定のサイズに達するとログのローテーションが行われるようにするには、次のプロパティーを設定します。
$ dpconf set-access-log-prop -h host -p port \ log-rotation-policy:size log-rotation-size:maximum file size |
最大ファイルサイズの単位を指定しない場合、デフォルトの単位である「バイト」が使用されます。ログファイルが定義されたサイズに達すると、ログのローテーションが行われます。ファイルサイズは、少なくとも 1M バイトにし、2G バイトを超えないようにする必要があります。
サイズによるログのローテーションの例については、「ログサイズに基づくログのローテーション」を参照してください。
ログのローテーションを定期的に行うには、ログサイズに関係なく、次のプロパティーを設定します。
$ dpconf set-access-log-prop -h host -p port \ log-rotation-frequency:interval in months, weeks, hours, or minutes \ log-rotation-policy:periodic \ log-rotation-start-day:day in week (1-7) or day in the month (1-31) \ log-rotation-start-time:time of day (hhmm) |
ログのローテーションが月の 31 日に行われるように設定すると、その月の日数が 31 日より短い場合、ログのローテーションは次の月の最初の日に行われます。
定期的なログのローテーションの例については、「時間に基づくログのローテーション」を参照してください。
ログファイルが十分に大きくなったときに定期的なログのローテーションを行うには、log-rotation-frequency プロパティーと log-min-size プロパティーを設定します。
$ dpconf set-access-log-prop -h host -p port \ log-rotation-frequency:interval in months, weeks, hours, or minutes \ log-rotation-policy:periodic log-min-size:minimum file size log-rotation-start-day:day in week (1-7) or day in the month (1-31) \ log-rotation-start-time:time of day (hhmm) |
log-min-size プロパティーは、ログの最小サイズを示します。ローテーションは、ログファイルが指定したサイズより大きくなった場合のみ、予定された時間に実行されます。
ログのローテーションが月の 31 日に行われるように設定すると、その月の日数が 31 日より短い場合、ログのローテーションは次の月の最初の日に行われます。
ファイルサイズが十分に大きくなったときに定期的にログのローテーションを行う方法の例については、「時間とログサイズに基づくログのローテーション」を参照してください。
この手順では、Directory Proxy Server のアクセスログのローテーションを行います。Directory Proxy Server のエラーログのローテーションを行う場合には、以下の手順に出てくる「access」を「error」に置き換えて、同じ手順を実行します。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
この手順では、Directory Proxy Server のアクセスログのローテーションを無効にします。Directory Proxy Server のエラーログのローテーションを無効にする場合には、以下の手順に出てくる「access」を「error」に置き換えて、同じ手順を実行します。
ログサイズ、時間、またはその両方によってログのローテーションを設定する方法の例は、次のとおりです。
この節では、ログサイズだけに従ってログのローテーションを設定する方法の例を示します。次の設定では、最後にログのローテーションが行われてから経過した時間に関係なく、ログが 10M バイトに達したときにローテーションが行われます。
$ dpconf set-access-log-prop -h host1 -p 1389 log-rotation-policy:size \ log-rotation-size:10M |
この節で示す例では、ログサイズに関係なく、最後のローテーションからの経過時間に従ってログローテーションを設定する方法を示します。
次の設定では、ログのローテーションは今日の 3:00 とそれ以降の 8 時間ごとに行われ、ログファイルのサイズとは無関係です。
$ dpconf set-access-log-prop -h host1 -p 1389 log-rotation-frequency:8h \ log-rotation-policy:periodic log-rotation-start-time:0300 |
次の設定では、ログファイルのサイズとは無関係に、毎日 3:00、13:00、23:00 にログのローテーションが行われます。log-rotation-start-time パラメータは log-rotation-frequency パラメータに優先するため、ログのローテーションは 23:00 に行われると、次回は 10 時間後ではなく、4 時間後の 3:00 に行われます。
$ dpconf set-access-log-prop -h host1 -p 1389 log-rotation-frequency:10h \ log-rotation-policy:periodic log-rotation-start-time:0300 |
次の設定では、ログのローテーションは月曜日の正午に行われ、そのあと毎週同じ時間に行われ、ログファイルのサイズとは無関係です。
$ dpconf set-access-log-prop -h host1 -p 1389 log-rotation-frequency:1w \ log-rotation-policy:periodic log-rotation-start-day:2 log-rotation-start-time:1200 |
次の設定では、ログファイルのサイズとは無関係に、月曜日の正午に最初のログのローテーションが行われ、それ以降は、3 日おきに正午にローテーションが行われます。
$ dpconf set-access-log-prop -h host1 -p 1389 log-rotation-frequency:3d \ log-rotation-policy:periodic log-rotation-start-day:2 log-rotation-start-time:1200 |
ログのローテーションが行われる曜日は、月曜日、木曜日、日曜日、水曜日というように続きます。log-rotation-start-day パラメータは最初の週だけに適用されます。2 週目の月曜日にはログのローテーションは行われません。
次の設定では、ログサイズとは無関係に、毎月 22 日の正午にログのローテーションが行われます。
$ dpconf set-access-log-prop -h host1 -p 1389 log-rotation-frequency:1m \ log-rotation-policy:periodic log-rotation-start-day:22 \ log-rotation-start-time:1200 |
log-rotation-start-day を 31 に設定したときに、30 日しかない月の場合、ログのローテーションは次の月の最初の日に行われます。log-rotation-start-day を 31 に設定したときに、28 日しかない月 (2 月) の場合、ログのローテーションは 3 日に行われます。
この例では、ファイルサイズが十分に大きくなった場合の、指定した間隔でのログのローテーションの設定方法を示します。
次の設定では、ログファイルのサイズが 1M バイトを超えた場合に、毎日 3:00、11:00、19:00 にログのローテーションが行われます。ログファイルのサイズが 1M バイトを超えなければ、ログファイルのローテーションは行われません。
$ dpconf set-access-log-prop -h host1 -p 1389 log-rotation-frequency:8h \ log-rotation-policy:periodic log-min-size:1M log-rotation-start-time:0300 |
Directory Proxy Server では、時間、サイズ、またはディスクの空き容量 (デフォルト) に基づいたログの削除を設定できます。これらの削除ポリシーの詳細は、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Log File Deletion」を参照してください。
次の手順では、アクセスログのログの削除を設定します。エラーログのログの削除を設定するときも同じコマンドを使います。ただし、 access を error に置き換えます。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
ログファイルの最長有効期間を指定します。
$ dpconf set-access-log-prop -h host -p port max-age:duration |
ここで、duration には、日( d)、週 (w)、または月 (M) の単位を指定します。たとえば、5 日前より古いバックアップログファイルを削除するには、次のコマンドを使用します。
$ dpconf set-access-log-prop -h host1 -p 1389 max-age:5d |
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
ログファイルの最大サイズを指定します。
$ dpconf set-access-log-prop -h host -p port max-size:memory-size |
たとえば、1M バイトより大きいバックアップログファイルを削除するには、次のコマンドを使用します。
$ dpconf set-access-log-prop -h host1 -p 1389 max-size:1M |
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
使用可能な最小ディスク容量を指定します。
$ dpconf set-access-log-prop -h host -p port min-free-disk-space-size:memory-size |
たとえば、使用可能なディスク容量が 2M バイトより少なくなったときにバックアップログファイルを削除するには、次のコマンドを使用します。
$ dpconf set-access-log-prop -h host1 -p 1389 min-free-disk-space-size:2M |
この節では、syslogd デーモンに対するアラートメッセージのログを設定する方法と、syslog アラートを受け付けるようにオペレーティングシステムを設定する方法について説明します。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
(省略可能) システムログアラートのプロパティーの現在の値を表示します。
$ dpconf get-server-prop -h host -p port syslog-alerts-enabled \ syslog-alerts-facility syslog-alerts-host |
システムログアラートのデフォルトプロパティーは、次のとおりです。
syslog-alerts-enabled : false syslog-alerts-facility : USER syslog-alerts-host : localhost |
syslog-alerts-host プロパティーは、メッセージの送信先である syslogd デーモンのホスト名を定義します。syslog-alerts-facility プロパティーは読み取り専用であり、メッセージをシステムログ内の user カテゴリに送信します。
syslogd デーモンにアラートメッセージのログを記録できるようにします。
$ dpconf set-server-prop -h host -p port syslog-alerts-enabled:true |
(省略可能) アラートメッセージを別のホスト上の syslogd デーモンに送信します。
$ dpconf set-server-prop -h host -p port syslog-alerts-host:hostname |
この節では、syslog アラートを受け付けるように SolarisTM、Linux、および HP-UX オペレーティング システムを設定する手順を示します。
適切な機能を syslog 設定ファイルに追加します。
たとえば、すべてのアラートを USER 機能を使用して格納するには、/etc/syslog.conf に次の行を追加します。
user.info /var/adm/info
ここでは、例として、/var/adm/info をメッセージの格納先になるローカルディレクトリとします。続行する前に、/var/adm/info が存在することを確認します。
syslogd デーモンを再起動します。
メッセージが syslog に記録されることを確認します。
$ logger -p user.info "Test message" $ cat /var/adm/info Jun 19 17:18:38 host user: [ID 12345 user.info] Test message
適切な機能を syslog 設定ファイルに追加します。
たとえば、すべてのアラートを USER 機能を使用して格納するには、/etc/syslog.conf に次の行を追加します。
user.info /var/adm/info
ここでは、例として、/var/adm/info をメッセージの格納先になるローカルディレクトリとします。続行する前に、/var/adm/info が存在することを確認します。
- r オプションを指定して実行するように、syslogd デーモンを設定します。
このオプションを使えば、syslogd でネットワークからの接続を受け付け可能になります。デフォルトでは、-r オプションは設定されていません。
-r オプションを設定するには、/etc/sysconfig/syslog に次の行を追加します。
SYSLOGD_OPTIONS="-m 0 -r"
/etc/sysconfig/syslog が存在しない場合は、同じ行を /etc/init.d/syslog に追加します。
syslogd デーモンを再起動します。
$ /etc/init.d/syslog stop | start
メッセージが syslog に記録されることを確認します。
$ logger -p user.info "Test message" $ cat /var/adm/info Jun 19 17:18:38 host user: [ID 12345 user.info] Test message
適切な機能を syslog 設定ファイルに追加します。
たとえば、すべてのアラートを USER 機能を使用して格納するには、/etc/syslog.conf に次の行を追加します。
user.info /var/adm/info
ここでは、例として、/var/adm/info をメッセージの格納先になるローカルディレクトリとします。続行する前に、/var/adm/info が存在することを確認します。
syslogd デーモンを再起動します。
$ /sbin/init.d/syslogd stop | start
メッセージが syslog に記録されることを確認します。
$ logger -p user.info "Test message" $ cat /var/adm/info Jun 19 17:18:38 host user: [ID 12345 user.info] Test message
クライアント要求のパスを追跡するには、要求が Directory Proxy Server のアクセスログと Directory Server のアクセスログに記録される方法を理解する必要があります。この節の内容を理解するには、最初に『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Tracking Client Requests Through Directory Proxy Server and Directory Server Access Logs」をお読みください。
DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。
Directory Server のアクセスログ内で追跡する操作の接続番号を見つけます。
たとえば、アクセスログ内の次の行は、接続番号が conn=12839 である op=2 という操作を示します。
[20/Jul/2006:18:01:49 -0500] conn=12839 op=2 msgId=4 - SRCH base="dc=example,dc=com" scope=2 filter="(objectClass=organizationalunit)" attrs=ALL |
その接続についての Directory Proxy Server の接続情報を入手します。
この情報を入手するには、Directory Server のアクセスログを検索して、対応する接続番号を持つすべての操作を見つけます。たとえば、UNIX システムの場合、次のような grep コマンドを実行して、Directory Server のアクセスログ内の接続 conn=12839 に対応するすべての行を見つけます。
$ grep conn=12839 access |
最初の LDAP 接続を示す行が探している行であり、次のようになります。
[19/Jul/2006:16:32:51 -0500] conn=12839 op=-1 msgId=-1 - fd=27 slot=27 LDAP connection from 129.153.160.175:57153 to 129.153.160.175 |
前述の行は、129.153.160.175:57153 から Directory Server への LDAP 接続があることを示しています。ポート番号 (57153) は、Directory Proxy Server のアクセスログで接続情報を調べる際に必要となります。このポート番号を使って、Directory Proxy Server のログ内で対応する接続を見つけることができ、この接続からクライアント情報を見つけることができます。
接続が最初に確立されてからログファイルのローテーションが行われている場合は、アーカイブされたログファイルと現在のアクセスログファイルを検索する必要があります。
Directory Proxy Server のアクセスログ内で対応する接続を見つけます。
この情報を入手するには、Directory Proxy Server のアクセスログを検索して、対応するポート番号を持つすべての操作を見つけます。
ログファイル内で、同じポート番号を持つ複数のエントリが見つかることがあります。正しいエントリを確実に見つけるには、Directory Server のログを検索したときに見つかったエントリに記載されていたタイムスタンプも条件に含めて検索します。
たとえば、UNIX システムでは、次のように grep コマンドを実行して、Directory Server のログで見つけたエントリのタイムスタンプおよびポート番号に対応する接続エントリを見つけます。
$ grep 19/Jul/2006:16:32 access | grep 57153 |
サーバー間でのわずかな時間のずれを考慮に入れて、検索条件にタイムスタンプを含めるときには、秒の値は除きます。
Directory Proxy Server のログ内の対応する行は、次のようになります。
[19/Jul/2006:16:32:51 -0500] - SERVER_OP - INFO - Created BIND LDAP connection s_conn=sunds-d1m1-9389:34 client=0.0.0.0:57153 server=idm160.central.sun.com:9389 main |
この行は、Directory Proxy Server で s_conn=sunds-d1m1-9389:34 への BIND 接続が作成されたことを示します。Directory Proxy Server は、自分自身を TCP ポート 57153 上のクライアント client=0.0.0.0 として識別します。
ログのこの行から得られる重要な情報は、サーバー ID とポート番号 (s_conn=sunds-d1m1-9389:34 ) です。
前述の手順で識別されたサーバー ID とポート番号に対応するすべての操作を見つけます。
この情報を入手するには、Directory Proxy Server のアクセスログで、対応するサーバー ID とポート番号を持つすべての操作をを検索します。
たとえば、UNIX システムでは、次のような grep コマンドを実行して、前述の手順で見つけたサーバー ID に対応する操作を見つけます。
$ grep s_conn=sunds-d1m1-9389:34 access |
この例では、関連する操作が数日にまたがっている可能性があるため、タイムスタンプを用いた検索は有効ではないかもしれません。ただし、検索によって返される操作が正しいものであることを確認する必要があります。複数の Create 接続ステートメントがある場合は、必ず、Directory Server のログで見つけた Create 接続ステートメントと合致するものを見つけてください。そのためには、手順 1 で見つかったエントリのタイムスタンプと同じタイムスタンプのエントリを見つけます。
Directory Proxy Server のアクセスログの次の抜粋は、s_conn=sunds-d1m1-9389:34 に対して返されたすべての操作を示します。
[19/Jul/2006:16:32:51 -0500] - SERVER_OP - INFO - Created BIND LDAP connection s_conn=sunds-d1m1-9389:34 client=0.0.0.0:57153 server=idm160.central.sun.com:9389 main [20/Jul/2006:18:01:49 -0500] - SERVER_OP - INFO - conn=31 op=0 BIND dn="cn=directory manager" method="SIMPLE" s_msgid=3 s_conn=sunds-d1m1-9389:34 [20/Jul/2006:18:01:49 -0500] - SERVER_OP - INFO - conn=31 op=0 BIND RESPONSE err=0 msg="" s_conn=sunds-d1m1-9389:34 [20/Jul/2006:18:01:49 -0500] - SERVER_OP - INFO - conn=31 op=1 SEARCH base="dc=example,dc=com" scope=2 s_msgid=4 s_conn=sunds-d1m1-9389:34 [20/Jul/2006:18:01:49 -0500] - SERVER_OP - INFO - conn=31 op=1 SEARCH RESPONSE err=0 msg="" nentries=1 s_conn=sunds-d1m1-9389:34 |
この情報により、Directory Proxy Server のこの検索操作に対する接続 ID が 31 (conn=31) であることがわかります。
前述の手順で見つかった接続 ID に対応する、クライアント接続 IP アドレスを見つけます。
この情報を入手するには、Directory Proxy Server のアクセスログで、正しい接続 ID とタイムスタンプを持つすべての操作を検索します。検索時には、手順 1 で検索したステートメントのタイムスタンプを使用します。
たとえば、UNIX システムでは、次のような grep コマンドを実行して、クライアント接続 IP アドレスを見つけます。
$ grep "20/Jul/2006:18:01" access | grep conn=31 |
目的の行は次のようになります。
[20/Jul/2006:18:01:49 -0500] - CONNECT - INFO - conn=31 client=129.150.64.156:2031 server=0.0.0.0:11389 protocol=LDAP |
前述の手順で見つかった IP アドレスの所有者を確認します。
この情報により、Directory Server 上で行われた操作をだれが担当したかを、正確に証明できます。
監視により、Directory Proxy Server とデータソースの障害が検出されます。
Directory Proxy Server の監視フレームワークの詳細と、cn=monitor エントリの詳細なレイアウトについては、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Monitoring Directory Proxy Server」を参照してください。この章の内容は次のとおりです。
Directory Proxy Server に関する監視データを取得するには、cn=monitor エントリを使用します。このエントリは、Directory Proxy Server によって、ローカルのメモリー内 データベース内で管理されます。cn=monitor エントリで LDAP 検索を実行することで、cn=monitor の下にある属性を取得できます。このエントリを検索するには、Proxy Manager としてバインドする必要があります。
監視データを取得するための JVM の使用については、「JVM による Directory Proxy Server についての監視データの取得」を参照してください。
Directory Proxy Server でデータソースの健全性を監視する方法については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「Monitoring Data Sources」を参照してください。この節では、データソースの監視を設定する方法について説明します。
このタイプの監視では、Directory Proxy Server は、Directory Proxy Server とデータソース間のトラフィックのエラーを待機します。このタイプの監視をリアクティブな監視といいます。これは、Directory Proxy Server が、エラーが検出されると反応を示しますが、データソースを積極的にはテストしないためです。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
データソースの監視モードを reactive に設定します。
$ dpconf set-ldap-data-source-prop -h host -p port datasource monitoring-mode:reactive |
「Directory Proxy Server に対する管理アラートの設定」で説明するように、エラーが検出された場合、またはデータソースがオフラインまたはオンラインになる場合に送信されるアラートを設定します。
Directory Proxy Server では、指定した時間内にデータソースへの要求やデータソースからの応答がなかった場合、データソースへの専用接続が作成されます。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
データソースの監視モードを proactive に設定します。
$ dpconf set-ldap-data-source-prop -h host -p port datasource monitoring-mode:proactive |
Directory Proxy Server で実行する、監視する検索要求を設定します。
$ dpconf set-ldap-data-source-prop -h host -p port datasource \ monitoring-bind-timeout:timeout monitoring-entry-dn:dn \ monitoring-search-filter:filter monitoring-entry-timeout:timeout |
検索要求では次のプロパティーが使用されます。
Directory Proxy Server がデータソースへの接続の確立を待機する時間の長さ。デフォルトでは、このプロパティーの値は 5 秒です。
検索要求にあるターゲットエントリの DN。デフォルトでは、このプロパティーはルート DSE エントリ ("") です。
検索フィルタ。
Directory Proxy Server が検索応答を待機する時間の長さ。デフォルトでは、このプロパティーの値は 5 秒です。
(省略可能) 予防保守の監視を設定し、特定のユーザーとしてバインドします。
$ dpconf set-ldap-data-source-prop ldap-data-source \ monitoring-bind-dn:uid=user-id monitoring-bind-pwd-file:password-file |
user-id を uid=bjensen,dc=example,dc=com などの有効な dn で、password-file をパスワードを含むファイルのパスで置き換えます。
デフォルトでは、バインドは匿名として実行されます。つまり、monitoring-bind-dn 属性と monitoring-bind-pwd 属性の両方とも none に設定されます。
ポーリング間隔を設定します。
$ dpconf set-ldap-data-source-prop -h host -p port datasource monitoring-interval:interval |
接続がダウンすると、Directory Proxy Server が、その復旧を検出するために、この間隔で接続をポーリングします。デフォルトでは、監視間隔は 30 秒です。
「Directory Proxy Server に対する管理アラートの設定」で説明するように、データベースがオフラインまたはオンラインとして検出された場合に送信されるアラートを設定します。
このタイプの監視では、Directory Proxy Server は、各データソースへの各接続で、定期的な間隔で検索を行います。このようにして Directory Proxy Server では、閉じた接続が検出され、停止しているために接続がドロップすることがないようにします。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
データソースの監視モードを proactive に設定します。
$ dpconf set-ldap-data-source-prop -h host -p port datasource monitoring-mode:proactive |
接続がドロップすることがないように Directory Proxy Server からデータソースに要求を送信するまでの時間間隔を設定します。
$ dpconf set-ldap-data-source-prop -h host -p port datasource \ monitoring-inactivity-timeout:time |
デフォルトでは、非活動タイムアウトは 120 秒です。
(省略可能) 予防保守の監視を設定し、特定のユーザーとしてバインドします。
$ dpconf set-ldap-data-source-prop ldap-data-source monitoring-bind-dn:uid=user-id monitoring-bind-pwd-file:password-file |
user-id を uid=bjensen,dc=example,dc=com などの有効な dn で、password-file をパスワードを含むファイルのパスで置き換えます。
デフォルトでは、バインドは匿名として実行されます。つまり、monitoring-bind-dn 属性と monitoring-bind-pwd 属性の両方とも none に設定されます。
「Directory Proxy Server に対する管理アラートの設定」で説明するように、データベースがオフラインまたはオンラインとして検出された場合に送信されるアラートを設定します。
管理アラートの設定方法については、次の手順を参照してください。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
有効になっているアラートを表示します。
% dpconf get-server-prop -h host -p port enabled-admin-alerts |
1 つまたは複数の管理アラートを有効にします。
% dpconf set-server-prop -h host -p port enabled-admin-alerts:alert1 \ [enabled-admin-alerts:alert2 ...] |
たとえば、使用可能なすべてのアラートを有効にするには、次のコマンドを実行します。
% dpconf set-server-prop -h host -p port \ enabled-admin-alerts:error-configuration-reload-failure-with-impact \ enabled-admin-alerts:error-server-shutdown-abrupt \ enabled-admin-alerts:info-configuration-reload \ enabled-admin-alerts:info-data-source-available \ enabled-admin-alerts:info-server-shutdown-clean \ enabled-admin-alerts:info-server-startup \ enabled-admin-alerts:warning-configuration-reload-failure-no-impact \ enabled-admin-alerts:warning-data-source-unavailable \ enabled-admin-alerts:warning-data-sources-inconsistent \ enabled-admin-alerts:warning-listener-unavailable |
すべてのアラートを無効にするには、次のコマンドを実行します。
% dpconf set-server-prop -h host -p port enabled-admin-alerts:none |
有効なアラートの既存リストにアラートを追加するには、次のコマンドを実行します。
% dpconf set-server-prop -h host -p port enabled-admin-alerts+:alert-name |
有効なアラートの既存リストからアラートを削除するには、次のコマンドを実行します。
% dpconf set-server-prop -h host -p port enabled-admin-alerts-:alert-name |
デフォルトでは、有効なアラートはありません。
詳細は、enabled-admin-alerts(5dpconf) を参照してください。
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
「管理アラートを有効にする」で説明するように、syslog デーモンに送信されるアラートを選択します。
syslog デーモンに送信されるアラートを有効にします。
$ dpconf set-server-prop -h host -p port syslog-alerts-enabled:true |
すべてのアラートは、USER の機能によって syslog に送信されます。
アラートの送信先である、syslog デーモンのホスト名を設定します。
$ dpconf set-server-prop -h host -p port syslog_hostname:hostname |
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
「管理アラートを有効にする」で説明するように、syslog に送信されるアラートを選択します。
電子メールのアドレスと特性を設定します。
$ dpconf set-server-prop -h host -p port email-alerts-smtp-host:host-name \ email-alerts-smtp-port:port-number \ email-alerts-message-from-address:sender-email-address \ email-alerts-message-to-address:receiver-email-address \ [email-alerts-message-to-address:receiver-email-address ...] \ email-alerts-message-subject:email-subject |
電子メールに送信されるアラートを有効にします。
$ dpconf set-server-prop -h host -p port email-alerts-enabled:true |
(省略可能) 電子メールのなかにアラートコードを組み込むフラグを設定します。
$ dpconf set-server-prop -h host -p port \ email-alerts-message-subject-includes-alert-code:true |
このタスクは DSCC を使用して実行することができます。詳細については、「Directory Service Control Center のインタフェース」および DSCC オンラインヘルプを参照してください。
「管理アラートを有効にする」で説明するように、syslog に送信されるアラートを選択します。
アラートでスクリプトを実行できるようにします。
$ dpconf set-server-prop -h host -p port scriptable-alerts-enabled:true |
実行するスクリプトの名前を設定します。
$ dpconf set-server-prop -h host -p port scriptable-alerts-command:script-name |
Directory Proxy Server は Java 仮想マシン (JVM) の内部で実行され、JVM マシンのメモリーに依存します。Directory Proxy Server が確実に正しく実行されるようにするには、JVM マシンのメモリー消費量を監視する必要があります。
JVM マシン用にパラメータを調整する方法については、『Sun Java System Directory Server Enterprise Edition 6.3 配備計画ガイド』の「Directory Proxy Server のハードウェアサイジング」を参照してください。
デフォルトでは、JVM マシンのヒープサイズは 250M バイトです。Directory Proxy Server に十分な物理メモリーがないと、ヒープサイズが 250M バイトより少なくなることがあります。
Directory Proxy Server が実行中の場合は、JVM マシンのヒープサイズを監視して、メモリー不足にならないようにすることができます。このためには、Java Development Kit (JDK) とともに配布される標準ツールを使用します。これらのツールは、次のディレクトリ内にあります。$JAVA_HOME/bin/jps および $JAVA_HOME/bin/jstat。
DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。
DSCC を使用してこのタスクを実行することはできません。次の手順に示すように、コマンド行を使用します。