IBM(R) 分散コンピューティング環境 (DCE) for AIX(R) および Solaris, V3.2 の README 補足 ===================================================== (C) Copyright IBM Corporation 2001. All rights reserved. 注: 著作権の詳しい記述については「12.0 特記事項」をご覧ください。 ===================================================== 目次 1.0 この README 補足について 2.0 LDAP の考慮事項 2.1 IBM SecureWay(R) ディレクトリー・サーバーの e-fix 2.2 並行読み取り / 書き込みに関する要件 2.3 IBM SecureWay ディレクトリー・サーバーでの dcecp カタログ・コマンドのために LDAP サイズの制限を変更する 2.4 ldif2db と複製機能を使用する場合の CreatorsName 属性 2.5 スキーマ変更中のエラー 3.0 AIX の考慮事項 3.1 AIX でのカスタマー・アプリケーション実行の考慮事項 3.2 dcecp に追加された dcf_ulimit コマンド 3.3 dcf_ulimit コマンド 4.0 DCE 3.2 のパフォーマンスの考慮事項とチューニングのヒント 4.1 secd のチューニング 4.1.1 LDAP サーバーとの複数の接続のチューニング 4.1.2 伝搬スレッドの数のチューニング 4.1.3 init_rep の起動側となる secd のチューニング 4.2 IBM SecureWay LDAP 使用時の DB2(R) のチューニング 4.3 LDAP のチューニング 4.3.1 IBM SecureWay LDAP サーバーのチューニング 4.3.2 iPlanet/Netscape LDAP サーバーのチューニング 4.4 ハードウェア 4.5 ネットワーク 4.6 初期マイグレーションで予想されること 4.7 DCE アプリケーションの考慮事項 4.8 ユーザー・タスク (login、chpasswd) 4.9 管理タスク (ユーザーの作成、ユーザーの削除) 5.0 ロケールの考慮事項 5.1 Solaris LDAP クライアントでの UTF-8 の問題 (Solaris のみ) 5.2 サポートされていないロケール設定に関連した LDAP の障害 6.0 必須レジストリー・バージョンの変更 6.1 LDAP マスターへのマイグレーションの前に、すべての レプリカのレジストリー・バージョン番号を同じにする 6.2 registry modify -version は、シーケンス番号が一致する まで待機する 7.0 マイグレーションの考慮事項とエラーについて 7.1 レジストリーのマイグレーションでは、一部のパラメーターを 完全に修飾することが必要 7.2 レジストリーのマイグレーションを停止しても、LDAP への DCE データの伝搬は停止しない 7.3 LDAP スレーブのマイグレーションの障害 7.4 LDAP マスターのマイグレーションの障害 7.5 マイグレーション中にチケットが満了した後に出るメッセージ 8.0 secd 再起動のための条件 8.1 SSL 開始後にキー・データベース・ファイルを変更するには secd を再起動する 8.2 LDAP_SERVER_DOWN 条件 9.0 TRY_PE_SITE 環境変数によるレジストリーの選択 9.1 常に CDS 基本サーバーがサービス中のセキュリティー・サーバー を指すようにする 9.2 強制マイグレーションでは、pe_site ファイルに付加的な セキュリティー・サーバー IP アドレスが必要 10.0 LDAP を使用する場合のレジストリーの制限 10.1 命名上の制約 10.2 既存の LDAP アカウントを削除できない 11.0 その他 11.1 dceback でバックアップできないファイルの手動バックアップ 11.2 分割 config 環境で IP アドレスを変更する 11.3 DCE ドキュメンテーション - start_dcedoc 12.0 特記事項 12.1 商標とサービス・マーク ===================================================== 1.0 この README 補足について このファイルには、DCE バージョン 3.2 for AIX および Solaris に付属の README ファイルに対する変更や更新が含まれています。 注: コマンドには引用符を含めないでください。 ===================================================== 2.0 LDAP の考慮事項 ===================================================== 2.1 IBM SecureWay(R) ディレクトリー・サーバーの e-fix 「DCE Security Registry and LDAP Integration Guide」の第 2 章 「Planning Considerations」の「Supported versions of LDAP」の 部分にある下記の一文は、訂正の必要があります。 "The IBM SecureWay Directory client requires a minimum e-fix of 3.2.2-SWD-0001". (IBM SecureWay ディレクトリー・クライアントには、 最低 3.2.2-SWD-0001 の e-fix が必要です。) 訂正後は、次のようになります。 "The IBM SecureWay Directory server requires a minimum e-fix of 3.2.1-SWD-004". (IBM SecureWay ディレクトリー・クライアントには、 最低 3.2.1-SWD-004 の e-fix が必要です。) さらに、Solaris で UTF-8 ロケールにしている場合は、 e-fix 3.2.1-SWD-005 が必要です。詳しくは、セクション 5.1 をご覧ください。 e-fix は、IBM SecureWay の Web サイト www.ibm.com/secureway/directory で入手できます。 ===================================================== 2.2 並行読み取り / 書き込みに関する要件 IBM SecureWay ディレクトリー・サーバーをバッキング・ストアとして 使用している場合、LDAP サーバーは並行読み取り / 書き込みを 実行するようにセットアップする必要があります。この設定をしなかった場合、 LDAP と DCE の間でデッドロックが発生する可能性があります。 使用している slapd32.conf ファイルのうち下記のスタンザに、 LDAP_CONCURRENTRW 属性を追加してください。 dn: cn=Front End, cn=Configuration cn: Front End ibm-slapdSetenv: LDAP_CONCURRENTRW=ON objectClass: top objectClass: ibm-slapdFrontEnd iPlanet/Netscape ディレクトリーでは、並行読み取り / 書き込みが デフォルトの構成です。 ===================================================== 2.3 IBM SecureWay ディレクトリー・サーバーでの dcecp カタログ・コマンドのために LDAP サイズの制限を変更する ibm-slapdSizeLimit の値が小さ過ぎると、"dcecp -c principal cat" や "dcecp -c account cat" などの dcecp カタログ・コマンドで、 プリンシパル・データのうちの一部が戻されない場合があります。 デフォルト値は 500 であり、その場合は約 480 個までのプリンシパルの 情報が戻されます。ibm-slapdSizeLimit は /usr/ldap/etc/slapd32.conf で定義されています。 ===================================================== 2.4 ldif2db と複製機能を使用する場合の CreatorsName 属性 LDAP で DCE データを作成することが予想されるすべてのユーザーや アプリケーションにおいて、krbTrustedAdmObject 属性または krbKdcServiceObject 属性には識別名 (DN、Distinguished Name) が含まれていなければなりません。それには、すべての DCE セキュリティー・サーバー、ネットワーク認証サービス KDC サーバー、 その他の LDAP 管理アプリケーションが含まれます。 ディレクトリー・インポート・ツールを使って DCE セルの LDAP ディレクトリーを復元する場合、DCE を開始する前に、 そのセルの LDAP エントリーの krbTrustedAdmObject 属性 または krbKdcServiceObject 属性は、そのツールで使用される 認証 DN を含むように更新する必要があります。 IBM SecureWay ディレクトリーの復元に ldif2db を使用する場合、 それは LDAP ディレクトリー管理者の DN です。 さらに、いずれかのディレクトリー・サーバーの複製機能を使用して レジストリーの LDAP レプリカを提供する場合、LDAP マスター・ サーバーにおけるセル・エントリーの krbTrustedAdmObject 属性 と krbKdcServiceObject 属性は、レプリカごとに LDAP 提供者 またはコンシューマーの使用する DN が含まれるように更新する 必要があります。 ===================================================== 2.5 スキーマ変更中のエラー iPlanet ディレクトリー・サーバーのスキーマを変更するとき、 passwordMinAge 属性と gecos 属性の変更試行に関して、エラーが 報告されることがあります。それような場合、変更は、属性の OID または構文に関するものです。そのようなエラーはその iPlanet ディレクトリー・サーバーを使用する DCE やその他のアプリケーション の動作には影響しません。 ===================================================== 3.0 AIX の考慮事項 ===================================================== 3.1 AIX でのカスタマー・アプリケーション実行の考慮事項 アプリケーションで下記のメッセージ (例外) が出た場合、 No memory for RPC (dce/rpc) (RPC のためのメモリーがありません (dce/rpc)) そのアプリケーションは、128 MB というデフォルトのデータ・サイズ の限界に達したと思われます。これを回避するには、アプリケーション のデータ・サイズの限界値を大きくしてください。さらに、 フットプリントが 256 MB より大きいアプリケーションの場合は、 AIX のラージ・メモリー・モデルの使用をご検討ください。 ===================================================== 3.2 dcecp に追加された dcf_ulimit コマンド DCE に関してのみデータ・サイズの ulimit を変更し、システムで 実行されているその他のアプリケーションに関しては変更したくない場合は、 /opt/dcelocal/tcl/user_cmd.tcl ファイルの中で "dcecp -c dcf_ulimit" というコマンドを使用できます。 user_cmd.tcl ファイルの中でこのコマンドを使用する サンプルが /opt/dcelocal/tcl/user_cmd.sample.tcl にあります。 このコマンドの構文については、セクション 3.3 をご覧ください。 ===================================================== 3.3 dcf_ulimit コマンド dcecp に dcf_ulimit というコマンドが追加されました。 dcf_ulimit の動作は ulimit とよく似ています。それには、 複数のコマンド行パラメーターがあります。dcf_ulimit コマンドに -?、-help、または help を指定すると、 下記のように表示されます。 dcf_ulimit [-S|-H] -f -c -t -d -s -m -n ulimit -a コマンドを dcecp 内 (または tcl スクリプト内) から 使用すると、現在の ulimit 設定値を調べることかできます。 しかし、dcf_ulimit で -a パラメーターはサポートされていません。 オペレーティング・システムの ulimit コマンドで使用されるのは、 64 ビット値です。dcecp は 32 ビット・プログラムなので、それは setrlimit API に渡すべき整数値のサイズによって制限されています。 dcf_ulimit コマンドを使用して渡すことのできる最大値は、下記の とおりです。 -f FSIZE 4194303 -c CORE 4194303 -t CPU 2147483647 -d DATA 2097151 -s STACK 2097151 -m RSS 2097151 -n NOFILE 2147483647 また、どのパラメーターについても、"unlimited" というキーワード も値として使用できます。 一般には、dcf_ulimit コマンドの動作は、ulimit コマンドと同じです。 ===================================================== 4.0 3.2 のパフォーマンスの考慮事項とチューニングのヒント ===================================================== DCE 3.2 の機能を使用して DCE セキュリティー情報を LDAP ディレクトリーにマイグレーション場合、パフォーマンスの 考慮事項がいくつかあります。DCE セキュリティー・レジストリーを、 メモリー内データベース (レガシー DCE のモデル) から ディスク上の LDAP データベースに移動すると、パフォーマンスに 影響します。その程度は、セルがマイグレーションのどの段階に あるかによって違います。ハイブリッド・セル (レガシー・ セキュリティー・サーバーと LDAP サーバーの両方が共存している セル) では、完全に LDAP にマイグレーションしたセルに比べて よりパフォーマンスへの影響が大きくなります。これは、更新が LDAP だけでなく、レガシー DCE セキュリティー・サーバーにも 伝搬することに伴うオーバーヘッドによります。一般に、DCE アプリケーションでセキュリティー・レジストリーを頻繁に 更新するため、それらの更新にすぐにアクセスすることが必要な お客様においては、以下のいずれかを実行することをお勧めします。 o ハイブリッド環境で実行する期間が長くならないようにする。 o セキュリティーのアクセス順序設定を使用することによって、それらの アプリケーションによるセキュリティー要求をレガシー DCE セキュリティー・サーバーに送る。 LDAP 統合機能に伴って、パフォーマンス・チューニング上の考慮事項が いくつかあります。それについては、次のセクションで説明します。 ===================================================== 4.1 secd のチューニング ===================================================== 4.1.1 LDAP サーバーとの複数の接続のチューニング MAX_CONNECTIONS 環境変数は、1 つのセキュリティー・サーバーと LDAP データベースとの間の接続数を決定します。現在のデフォルト値は 8 であり、ほとんどのお客様の環境ではそれで十分です。 しかし、さらに多くの接続が必要になる場合も考えられます。 1 つの例は、並行ログインのワークロードがかなり大きい環境です。 また、マルチプロセッサー環境においてシステムの能力を有効に 活用するため、接続数を多くしたいと思うかもしれません。 MAX_CONNECTIONS 環境変数を変更した場合、そのシステムの セキュリティー・サーバーを再起動する必要があります。 サポートされる接続の最大数は 64 です。 ===================================================== 4.1.2 伝搬スレッドの数のチューニング セキュリティー・サーバーが 3 個しかないセルのレガシー・レプリカ および LDAP マイグレーション・サーバーに同時に伝搬するためには、 マスター・セキュリティー・サーバー上で既存の MAX_SEC_PROP_THREADS 環境変数を 2 に設定してください。セキュリティー・サーバーが 4 個 以上ある場合、スレッド数は secd によって自動的に 2 に設定されます。 ===================================================== 4.1.3 init_rep の起動側となる secd のチューニング マスター・セキュリティー・サーバー上で SEC_REP_INIT_FROM_UUID 環境変数を使い、LDAP へのマイグレーション中にセキュリティー・ レジストリーの送り元となるレガシー・レプリカを指定してください。 この変数は、マイグレーション・サーバー上で "dcecp registry migrate" コマンドを発行する前に、レガシー・レプリカの UUID (Universal Unique Identifier) に設定しておいてください。 その UUID を取得するには、"sec_admin" コマンドを発行してから、 "lr -all" と入力します。この UUID は、サーバーのインスタンス ID です。この環境変数を設定した場合、マスター・セキュリティー・ サーバーをいったん停止してから再起動する必要があります。 この環境変数を使用すると、初期設定時にレガシー・マスターが 使用されなくなります。初期設定にレガシー・マスターを使用すると、 マイグレーションの期間中、保守モードになります。 レガシー・セキュリティー・レプリカではこの機能を実行できますが、 LDAP サーバーではできません。SEC_REP_INIT_FROM_UUID 環境変数は LDAP スレーブの UUID には設定しないようにしてください。 ===================================================== 4.2 IBM SecureWay LDAP 使用時の DB2(R) のチューニング 注: このセクションで説明する手順では、デフォルトの LDAP DB2 ユーザー ID (ldapdb2) を使用することを前提としています。 LDAP DB2 のユーザー ID として別のものを使用する場合は、 それに応じて置き換えてください。 DB2 キャッシュが大きいほど入出力アクセスが少なくなるかというと、 必ずしもそうではありません。むしろ、LDAP キャッシュの容量を大きく するほうがストラテジーとして優れています。一般に、DB2 バッファー・ プールのサイズはなるべく小さく、そして LDAP のエントリー・キャッシュ とフィルター・キャッシュはなるべく大きくしてください。下記の例では、 AIX のコマンドを使用しています。LDAP サーバーの位置に応じて、 該当するオペレーティング・システムのコマンドを使用するように してください。 サンプル・ステップ - DB2 (IBM SecureWay LDAP を使用する場合) 1. DB2 スーパーユーザー ldapdb2 としてログインします。たとえば、 su -ldapdb2 2. 既存の SHEAPTHRES (ソート・ヒープのしきい値) を調べます。 たとえば、 db2 get dbm config | grep SHEAP 3. 既存の SHEAPTHRES を 20000 に設定します。たとえば、 db2 update db manager config using SHEAPTHRES 20000 4. DB2 を開始します。たとえば、 db2start 5. LDAP/DB2 に接続します。たとえば、 db2 connect to ldapdb2 6. 既存の BUFFPAGE (バッファー・プールのサイズ) を調べます。 たとえば、 db2 get db config for ldapdb2 | grep BUFF 7. システム・メモリーのサイズ (MB) を調べます。たとえば、 lsattr -E -l sys0 -a realmem 8. DB2 のデフォルトで BUFFPAGE は 1000 (4 KB ページ) ですが、 大規模なデータベースの場合、それでは不十分です。システムの メモリーが 1 GB 以上の場合は、BUFFPAGE として割り振る メモリー量に常識的な値 (おそらく 50% 未満) を使用してください。 メモリーが約 512 MB 以下の場合、下記のアルゴリズムが役立つこと でしょう。BUFFPAGE の設定を変更するため、 db2 update db config for ldapdb2 using BUFFPAGE nnnnn nnnnn は次のようにして計算される値です (システムで バッファー・プールに割り振られる量の 50%)。 nnnnn = [システム・メモリー MB] × 50% / 4KB (1 ページ = 4 KB なので 4 KB で除算しています。) 9. BUFFPAGE パラメーターを大きくする場合は、DBHEAP のサイズも、 BUFFPAGE パラメーターの増加量 30 に対して 1 ずつ大きくして ください。既存の DBHEAP (データベース・ヒープ) を調べる には、たとえば、 db2 get db config for ldapdb2 | grep DBHEAP 10. たとえば、DBHEAP を 1700 に設定するには、次のコマンドを 実行します。 db2 update db config for ldapdb2 using DBHEAP 1700 11. 既存の SORTHEAP (ソート・リスト・ヒープ) を調べます。 たとえば、 db2 get db config for ldapdb2 | grep SORTHEAP 12. DB2 データベース・モニター・ツールを使って、SORTHEAP パラメーターの大体の値を求めます。SORTHEAP の設定を変更 するには、 db2 update db config for ldapdb2 using SORTHEAP nnnn ただし、 nnnn = BUFFPAGE の増加量 / 30 です。 13. 既存の MAXLOCKS (アプリケーション当たりのロック・リストの パーセント値) を調べます。たとえば、 db2 get db config for ldapdb2 | grep MAXLOCKS 14. DB2 データベース・モニター・ツールを使って、MAXLOCKS パラメーターの大体の値を求めます。たとえば、MAXLOCKS を 100 に設定するには、 db2 update db config for ldapdb2 using MAXLOCKS 100 15. バッファー・プールの設定を変更します。たとえば、 db2 alter bufferpool ibmdefaultbp size -1 注: -1 は数字の「いち」であって「エル (L)」ではありません。 16. db2 を再起動して、ここまでの変更内容を有効にします。たとえば、 db2stop db2start DB2 のチューニングについて詳しくは、 www.software.ibm.com/data/db2/library をご覧ください。 ===================================================== 4.3 LDAP のチューニング LDAP のパフォーマンスは、さまざまな要因によって影響を受けます。 パフォーマンスを上げるには、デフォルトの構成をチューニングし、 変更することが不可欠です。 LDAP (IBM SecureWay の LDAP を使用している場合はさらに DB2 キャッシュ) のメリットをフルに活用するためには、事前にそれら のキャッシュを準備する必要があります。LDAP のキャッシュには、 エントリー・キャッシュやフィルター・キャッシュを含め、いくつかの 種類があります。キャッシュに入れるエントリー数は、環境ごとに 選択してください。最適のサイズを決定するためには、いくらか実験 してみることが必要かもしれません。一般に、DB2 バッファー・プールの サイズはなるべく小さく、そして LDAP のエントリー・キャッシュと フィルター・キャッシュはなるべく大きくしてください。 DCE スキーマを IBM SecureWay LDAP にロードすると、DCE 3.2 データベースは自動的に索引付けされます。iPlanet/Netscape ディレクトリー・サーバーを使用している場合には、手動で スキーマの索引付けを実行する必要があります。LDAP は、 並行読み取り / 書き込みで実行されるようにすることをお勧めします。 IBM SecureWay ディレクトリーを使用している場合には、 並行読み取り / 書き込みをオンにする必要があります (LDAP_CONCURRENTRW=ON)。iPlanet/Netscape ディレクトリーを 使用している場合は、デフォルトでオンになっています。 並行読み取り / 書き込みを設定したなら、slapd を再起動する 必要があります。 ===================================================== 4.3.1 IBM SecureWay LDAP サーバーのチューニング 注: このセクションで説明する手順では、slapd のデフォルト構成ファイル (AIX の場合は /usr/ldap/etc/slapd32.conf) と、slapd のデフォルト・ エラー・ログ・ファイル (AIX の場合は /tmp/slapd.errors) を使用 していることを前提にしています。使用している LDAP サーバーで、 それらのデフォルト値以外の値を使用している場合、それに応じて 置き換えてください。 IBM SecureWay の slapd.errors ファイル (AIX の場合は /tmp/slapd.errors、 Solaris の場合は /var/ldap/slapd.errors、そして NT の場合は C:\Program Files\IBM\LDAP\tmp\slapd32.errors) のサイズが大きくなると、 LDAP のパフォーマンスが落ちます。エラーはそれほどたくさん出ないかも しれませんが、長期間実行する環境の場合、このファイルの影響が見過ごされ がちです。このファイルは、LDAP 実行中に削除したり名前を変更したり できます。削除されたり名前が変更されたりすると、新しい slapd.errors ファイルが自動的に作成されます。 環境変数のうち、IBM SecureWay LDAP サーバー・キャッシュのキャッシュ・ サイズに直接影響を及ぼすものが 4 つあります。その値は、その環境の プラットフォーム、メモリー・サイズ、ワークロードなどの要素によって 異なります。それらの変数を設定するための望ましい方法は、 /usr/ldap/etc/slapd32.conf ファイルを使うことです。 サンプル・ステップ - IBM SecureWay LDAP 1. LDAP 構成ファイル /usr/ldap/etc/slapd32.conf に、下記の行を 追加します。 #ADDED LDAP TUNING dn: cn=Front End, cn=Configuration objectclass: top objectclass: ibm-slapdFrontEnd #Turn on concurrent read/write. This can prevent race conditions #that could result in entries being returned that no longer #match the search filter. This locking mechanism can have a #dramatic impact on the performance of LDAP searches when #update operations are in progress. Default is FALSE. #Note that this variable can be set to ON or TRUE in v3.2.2 #of IBM SecureWay LDAP. ibm-slapdSetEnv: LDAP_CONCURRENTRW=ON #RDBM_CACHE_SIZE=; Default is 1000. #Specifies the maximum numbers of entries to keep in the Entry cache. ibm-slapdSetEnv: RDBM_CACHE_SIZE=100000 #RDBM_FCACHE_SIZE=; Default is one fourth of the size of the #RDBM_CACHE_SIZE. #Specifies the maximum number of entries to keep in the search filter #cache. ibm-slapdSetEnv: RDBM_FCACHE_SIZE=100000 #ACLCACHE=; Default is YES. #Controls whether or not the server caches ACL information. ibm-slapdSetEnv: ACLCACHE=YES #ACLCACHESIZE=; Default is = RDBM_CACHE_SIZE. #Specifies the maximum number of entries to keep in the ACL cache. ibm-slapdSetEnv: ACLCACHESIZE=25000 2. LDAP サーバーを停止します。 3. AIX では、LDAP サーバーを再起動する前に、下記の環境変数を エクスポートしておいてください。 export MALLOCMULTIHEAP=heaps:n ただし n = [この LDAP ホスト・マシンのプロセッサー数] + 1 です。 4. LDAP サーバーを起動します。 ===================================================== 4.3.2 iPlanet/Netscape LDAP サーバーのチューニング iPlanet/Netscape ディレクトリー・サーバーを使用している場合、 その製品のドキュメンテーションに記載されているチューニングの 情報やヒントを確認してください。特に、「iPlanet Directory Server Performance Tuning Guide」(2001 年 5 月) の中に、 「Top 10 List of Performance Tuning Tips」というセクションが あります。iPlanet/Netscape ディレクトリー・サーバーを 使用する場合、スキーマは手動で索引付けする必要があります。 iPlanet/Netscape ディレクトリー・サーバーは、データの キャッシュをメモリー内に持っています。このメモリー内 キャッシュもチューニング可能です。 サンプル・ステップ - iPlanet/Netscape LDAP 等価索引属性として、下記の DCE LDAP 属性を構成します。 - krbRealmName-v2 - krbPrincipalName - krbPolicyName - krbKeyVersion - dceDirName - dceXattrName - dceGroupName - dceUUID - unixID どんな DCE LDAP マイグレーションを実行する場合でも、 iPlanet/Netscape LDAP で、エントリー・キャッシュ・サイズと データベース・キャッシュ・サイズの最大値を事前に計算および 設定してください。エントリー・キャッシュ・サイズ (cachesize) は、キャッシュのメモリー・サイズではなく、 キャッシュ 1 個当たりのエントリー項目の数を指定するものです。 原則として、キャッシュ・メモリーの 75% を dbcachesize に、 そして 25% をエントリー・キャッシュ・サイズに当ててください。 詳しくは、「The iPlanet Market Maker 1.0 Deployment Guide」の 第 6 章「Performance Tuning and Monitoring」をご覧ください。 LDAP サーバーの構成ファイルで cachesize と dbcachesize を 新しい値に更新するのを忘れないようにしてください。 LDAP サーバーを再起動すると、それまでに加えた調整が有効に なります。 チューニングに関する 4.13、5.0、その他の iPlanet/Netscape 勧告 について、http://docs.iplanet.com/docs/manuals/directory.html を ご覧ください。 ===================================================== 4.4 ハードウェア この機能のテストにおいては、マシンの速度が速ければ速いほど、 またメモリーが多ければ多いほど、パフォーマンスが向上します。 セキュリティー・レジストリーとして LDAP を使用する DCE セルの パフォーマンスは、LDAP が実行されているシステムの能力と直接 関係しています。IBM では、4 GB のメモリーを積んだ IBM eServer pSeries(TM) 620 Model 6F1 を LDAP/DB2 サーバー・マシンとして 使用した耐久テストを実施しました。LDAP キャッシュにも DB2 キャッシュにも、十分なメモリーが必要です。推奨される 最低のメモリー構成は 128 MB です。 入出力パフォーマンスを改善するため、LDAP/DB2 サーバー・マシン にドライブを追加することを考慮してください。入出力待ち状態の 時間がどの程度の割合を占めているかは、たとえば vmstat ユーティリティーを使用してモニターできます。それが 0% でないなら、 それは、そのデータベースで入出力に時間がかかっている 可能性があることを示唆しており、実際には LDAP が飽和状態に なっていることを示している場合があります。一般に、入出力 待ち時間が 0% 程度になるまでデータベース・バッファーの サイズを大きくすれば、最適な効率が得られます。 ===================================================== 4.5 ネットワーク LDAP サーバーと DCE セキュリティー・マイグレーション・サーバーを 同じマシンで実行すると、パフォーマンスが上がることがあります。 マイグレーション時には、特にこのことが当てはまります。 ネットワークに SSL を使用すると、パフォーマンスがかなり 落ちることがあります。伝搬や更新の活動のための時間が長く なるためです。 ===================================================== 4.6 初期マイグレーションで予想されること マイグレーション・サーバーによってセキュリティー・レジストリーを LDAP にマイグレーションする作業は、レガシー・レプリカの初期化よりも はるかに長い時間がかかります。10,000 個のプリンシパル / アカウントの レジストリー環境をレガシー・レプリカにマイグレーションするのに かかる時間は数分程度ですが、LDAP 環境の場合は 15 時間近くかかることが あります。 ===================================================== 4.7 DCE アプリケーションの考慮事項 ハイブリッド・セルにおいては、複製作業、特にセキュリティー情報の伝搬 のため、LDAP データベースへ移すのにかかる時間がさらに長くなります。 セキュリティー情報を更新して、そのデータにすぐにアクセスする カスタマー・アプリケーションでは、「Registry Object Not Found」 というエラーになることがあります。これは、LDAP に情報を入れるために 必要になる伝搬遅延のためです。これを回避するには、いくつかの方法が あります。1 つの方法は、pe_site ファイルを使うことです。TRY_PE_SITE 環境変数を使用し、pe_site ファイルの中でのセキュリティー・サーバーの 順序を、LDAP マイグレーション・サーバーが最初にならないような順序に してください。アプリケーションでは、伝搬遅延がそれほど大きくない レガシー secd サーバーにバインドします。別の方法は、既存の アプリケーションで、エラーが発生した場合、更新から伝搬に必要な時間が 経過した後で再試行するためのコードを追加する、というものです。 セルが完全に LDAP にマイグレーションしたなら、それ以降、 伝搬は発生しません。 ===================================================== 4.8 ユーザー・タスク (login、chpasswd) IBM では、LDAP サーバーとの複数接続のサポートをインプリメント しました。それによって、並行ログイン活動のパフォーマンスが改善 されます。環境変数 MAX_CONNECTIONS については、前出の「4.1 secd のチューニング」をご覧ください。ユーザーがパスワードを 変更してからすぐにログインした場合、時折、伝搬遅延が発生する ことがあります。パフォーマンスの変更がまだ LDAP にまで伝搬して いないなら、初期障害が発生することがあります。ユーザーが ログインを再試行すれば、正常にログインできるはずです。 ===================================================== 4.9 管理タスク (ユーザーの作成、ユーザーの削除) "dcecp -c user create" コマンドのルックアップの実行方法のため、 関係するステップをそれぞれ別個に実行するよりも、LDAP の方が遅く なるのが普通です。下記のようにして、複数の別個の dcecp コマンドを 実行するようお勧めします。 principal create group create org create group add member org add member account create "dcecp -c user delete" についても同じです。 "dcecp -c user create" コマンドを使用したスクリプトを実行する場合は、 前出の「DCE アプリケーションの考慮事項」の中の pe_site に関する説明 をご覧ください。pe_site ファイルを使用して、マイグレーション中に マイグレーション・サーバーではなくレガシー secd サーバーに要求を 送ると、伝搬遅延のいくつかが緩和されることになる場合があります。 ===================================================== 5.0 ロケールの考慮事項 ===================================================== 5.1 Solaris LDAP クライアントでの UTF-8 の問題 (Solaris のみ) IBM SecureWay ディレクトリー V3.2.1 クライアント (Solaris 版) では、 e-fix 3.2.1-SWD-005 がインストールされていれば、UTF-8 ロケールでの 実行がサポートされます。Solaris にその e-fix がインストールされて いない場合、UTF-8 ロケールで実行中に LDAP で DCE を使用しようと すると、DCE は下記のような LDAP エンコード・エラーになります。 2001-07-09-15:47:53.898-05:00I----- secd ERROR sec ldap ldap_errors.c 666 0xfe8af9bc msgID=0x17122F9F ldap_simple_bind_s returned LDAP_ENCODING_ERROR during rgy_bind_to_ldap_server (1134). ===================================================== 5.2 サポートされていないロケール設定に関連した LDAP の障害 オペレーティング・システムのロケール環境変数 LANG および LC_ALL に 設定されている値がローカル・ホスト・マシン上でサポートされていない なら、IBM SecureWay ディレクトリー V3.2.1 クライアントは正しく動作 しません。設定が正しくないなら、LDAP エラーになり、そのために下記 のような DCE エラーになります。 2001-11-02-14:29:12.435-06:00I----- secd ERROR sec ldap ldap_errors.c 666 0xfea8f904 msgID=0x17122F9F ldap_simple_bind_s returned LDAP_ENCODING_ERROR during rgy_bind_to_ldap_server (1332). 2001-11-02-14:29:12.814-06:00I----- secd ERROR sec rs_ns rs_master_LDAP.c 550 0xfea8fbac msgID=0x17122084 Invalid data record これを回避するには、LANG と LC_ALL の値を、そのマシンでサポートされて いる値に設定してください。 ロケールの現在の設定値を調べるには、DCE セッションでオペレーティング・ システム・コマンド "locale" を実行してください。AIX の場合、コマンド "locale -a" を実行すると、そのローカル・マシンで有効なロケール設定値が 表示されます。そこに現在のロケール設定値が含まれていない場合には、 LANG と LC_ALL を、表示されている値に設定してください。Solaris の 場合は、システム・コマンド実行中にオペレーティング・システムによって 警告メッセージ「couldn't set locale correctly」が表示されるため、 不正な設定値を検出することができます。 ===================================================== 6.0 必須レジストリー・バージョンの変更 ===================================================== 6.1 LDAP マスターへのマイグレーションの前に、すべての レプリカのレジストリー・バージョン番号を同じにする LDAP マスターにマイグレーションする前に、DCE セキュリティー・ レジストリーのバージョンを 1.3 にする必要があります。その際に バージョンを 2 回変更することになるため、LDAP マスターへの マイグレーションを開始するには、すべてのレプリカのバージョン番号 が同じになっていなければなりません。次の処理に移る前に、すべての レプリカで更新が実行されたことを確認するため、"lr -all" を実行 する必要があります。まず "sec_admin" コマンドを実行してから "lr -all" を入力してください。すべてのレプリカのバージョンが 1.3 になり、シーケンス番号が同じになったなら、安全に LDAP マスターに マイグレーションできるようになります。 ===================================================== 6.2 registry modify -version は、シーケンス番号が一致する まで待機する DCE の旧リリースでは、レジストリーのバージョンが短期間のうちに 2 回変更されることはまれでした。DCE 3.2 で LDAP 機能を使用する ようマイグレーションする場合、セル・レジストリーのバージョンが まだ secd.dce.1.2.2a (公開鍵) になっていないなら、レジストリー・ バージョンを少なくとも 2 回変更することが必要になります。 secd.dce.1.2.2 から secd.dce.1.2.2a へ、 その後、secd.dce.1.2.2a から secd.dce.1.3 DCE ではバージョンを一度に 2 以上移行することがサポートされておらず、 1 つのバージョンへの変更が完了して次のバージョンに移ることができる 状態になるまでには、時間がかかります。セキュリティー・レプリカでは、 第 2 のバージョン変更を開始する前に、最初のバージョン変更を伝搬に よって処理する必要があります。そうしないなら、セキュリティー・ レプリカは、一度にバージョンを 2 以上変更しようとしているとして、 エラーを戻します。 レジストリーのバージョンを変更する前に、sec_admin とサブコマンド lr -all を使用することによって、セキュリティー・レプリカのすべての シーケンス番号が最新のものになっていることを確認してください。 すべてのシーケンス番号が一致しているなら、レジストリー・バージョンを 安全に変更できます。この検査は、"dcecp -c registry modify -version" コマンドの毎回の実行の前に、必ず実行してください。 sec_rgy_wait_until_consistent を使用すると、"dcecp -c registry modify -version" コマンドで自動的にこの検査が実行されるようになります。 バージョンの更新を処理する前に、レプリカがすべての更新を完了するまで マスターが待機するようにします。 セキュリティー・レプリカがすべて最新のものではないなら、次のエラーが 表示されます。 Waiting up to 600 seconds for "sec_rgy_wait_until_consistent" to complete. このメッセージが表示されるのは、dcecp が sec_rgy_wait_until_consistent から戻るのを待つ時間が 15 秒を超えた場合です。 sec_rgy_wait_until_consistent API から戻らないまま 10 分が経過すると、 dcecp はタイムアウトになります。その場合、次のメッセージが表示され ます。 0x11315bbd The software timed out waiting for "sec_rgy_wait_until_consistent" to complete. version = secd.dce.1.2.2a 現在のレジストリー・バージョンが表示されます。それによって、 レジストリー・バージョンの更新前または更新後、dcecp が sec_rgy_wait_until_consistent 待機中にタイムアウトになった かどうかを知ることができます。表示されるバージョンが期待 されたものではないなら、数分間待ってから、もう一度、レジストリーを 変更してください。 ほとんどの場合、"dcecp -c registry modify -version" コマンドは、 バージョンの更新がすべてのセキュリティー・レプリカに伝搬するまで 待機します。しかし、一部のセキュリティー・レプリカですべての更新が 完了していないことを、dcecp が検出できないという場合も考えられます。 たとえば、マスター・セキュリティー・サーバーから更新要求が 発行されたが、レプリカがまだその処理を完了していないという場合や、 その時点でレプリカが実行されていないということが考えられます。 セキュリティー・レプリカのすべてが最新の状態になる前にレジストリー・ バージョンが更新されると、いくつかのレプリカからバージョン・エラーが 報告されることがあります。 エラーを報告したセキュリティー・レプリカ・サーバーがレガシー・ セキュリティー・レプリカなら、そのレプリカは再構成する必要があります。 エラーを報告したセキュリティー・レプリカ・サーバーが LDAP セキュリティー・レプリカなら、エラーの出ない LDAP スレーブまたは マイグレーション・スレーブから /opt/dcelocal/var/security/rgy_data/master_info ファイルをコピー してください。その際には、エラーになった場合のために、master_info ファイルのオリジナルを保存しておいてください。 ==================================================== 7.0 マイグレーションの考慮事項とエラーについて ==================================================== 7.1 レジストリーのマイグレーションでは、一部のパラメーターを 完全に修飾することが必要 "dcecp -c registry migrate" コマンドでは、-dce_master_key パラメーター と -keyring パラメーターに完全修飾パス名を使用する必要があります。 そのいずれかに対して、完全に修飾されていないパス名を指定すると、 下記のメッセージが表示されます。 The value, '', for the