この章では、Directory Server のリリース時点で判明している、製品固有の重要な情報を示します。
この章では、次の内容について説明します。
この節では、Directory Server の前回のリリース以降に修正されたバグの一覧を示します。
Solaris および Linux で ZIP 形式の配布パッケージからインストールすると、共通エージェントコンテナ (cacao) の再起動後に Directory Server が SNMP 経由で表示されません。
パスワード変更の拡張操作を使用して LDAP パスワードを変更した場合、pwdSafeModify を off にしていても、アカウントの現在のパスワードが要求されます。
Windows 2003 システムでは、ZIP 形式の配布パッケージから dsee_deploy コマンドを使用してインストールされたソフトウェアをドイツ語のロケールで使用しないでください。
db2ldif または ldif2db を実行後、新しい変更ログが作成されるが、古い変更ログが削除されません。
レプリケーションが有効になっていると、ns-slapd はクラッシュします。
Directory Server 5.1 マスターを 6.x に移行すると、エラーが表示されます。
lockhart にロードされている一部の jar ファイルは、125310-02 および 125278-02 パッチの適用後にアップグレードできなくなります。
dsconf create-plugin -Y pwdstoragescheme コマンドは、不正な DN を持つプラグインエントリを追加します。
この節では、リリース時点での既知の問題点および制限事項の一覧を示します。
この節では、製品の制限事項の一覧を示します。
インストール済みの Directory Server Enterprise Edition 製品ファイルのアクセス権を変更すると、場合によってはソフトウェアが正常に動作しなくなる可能性があります。ファイルのアクセス権は、製品マニュアルの指示、または Sun サポートからの指示に従っている場合のみ変更してください。
この制限事項を回避するには、適切なユーザーアクセス権およびグループアクセス権を持つユーザーとして製品をインストールし、サーバーインスタンスを作成します。
cn=changelog サフィックスのレプリケーションを設定することは可能ですが、実際に設定するとレプリケーションに干渉する可能性があります。cn=changelog サフィックスをレプリケートしないでください。cn=changelog サフィックスは、旧バージョン形式の変更ログのプラグインによって作成されます。
Sun Cluster 上で Directory Server を実行しているとき、共有されていないディレクトリを使用するように nsslapd-db-home-directory を設定すると、データベースキャッシュファイルが複数のインスタンスによって共有されます。フェイルオーバー後、新しいノード上の Directory Server インスタンスが、古くなっている可能性があるそのデータベースキャッシュファイルを使用します。
この制限に対処するには、共有ディレクトリを使用するように nsslapd-db-home-directory を設定するか、または Directory Server の起動時に nsslapd-db-home-directory 下のファイルが削除されるようにシステムを設定してください。
LD_LIBRARY_PATH に /usr/lib が含まている場合に、誤った SASL ライブラリが使用され、インストール後に dsadm コマンドが失敗する原因となります。
cn=config に対する LDAP の変更操作では、置換サブ操作のみを使用できます。属性を追加または削除しようとすると、操作は拒否され、エラー 53 (DSA is unwilling to perform) が返されます。Directory Server 5 では、属性または属性値の追加または削除が可能でしたが、値の検証を経ることなく dse.ldif ファイルに更新が適用され、DSA の内部状態は DSA を停止して再開するまで更新されませんでした。
cn=config 設定インタフェースは非推奨となっています。可能な場合は、代わりに dsconf コマンドを使用してください。
この制限への対処として、追加または削除サブ操作の代わりに、LDAP の変更操作の置換サブ操作を代用することができます。機能面での支障は発生しません。また、変更後の DSA 設定の状態が予測しやすくなります。
この問題点は、Windows システム上のサーバーインスタンスのみに影響します。この問題の原因は、Start TLS 操作を使用するときの Windows システム上のパフォーマンスです。
この問題に対処するには、dsconf コマンドで -P オプションを指定し、SSL ポートを直接使用して接続することを検討してください。別の方法として、ネットワーク接続がすでにセキュリティー保護されている場合は、dsconf コマンドの -e オプションの使用を検討してください。このオプションにより、セキュリティー保護された接続を要求せずに標準ポートに接続できます。
レプリケートした Directory Server インスタンスをレプリケーショントポロジから削除したあとも、レプリケーション更新ベクトルがそのインスタンスへの参照を維持し続けることがあります。結果として、存在しなくなったインスタンスへのリフェラルが発生する可能性があります。
この問題点に対処するには、ネイティブパッケージからのインストール時に root 権限で cacaoadm enable コマンドを使用してください。
Directory Server の設定プロパティー max-thread-per-connection-count は、Windows システムには適用されません。
Microsoft Windows 2000 Standard Edition のバグが原因で、Microsoft 管理コンソールを使用して Directory Server サービスを削除したあとも、このサービスが「無効」として表示されます。
Windows XP 上で実行している webconsole に Administrator アカウントでログインできません。
この問題に対処するには、ゲストアカウントを無効にして、レジストリキー HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\ForceGuest を 0 に設定してください。
この節では、Directory Server 6.2 のリリース時に判明していた既知の問題点の一覧を示します。
オンラインでのエクスポート、バックアップ、復元、またはインデックス作成の実行中にサーバーを停止したときに Directory Server がクラッシュする現象が確認されています。
Directory Server で LDIF からエントリをインポートするときに、createTimeStamp 属性および modifyTimeStamp 属性が生成されません。
LDIF インポートは高速化のために最適化されています。そのため、インポート処理ではこれらの属性を生成しません。この制限に対処するには、エントリをインポートする代わりに追加してください。インポートを実行する前に LDIF を前処理して属性を追加する対処策もあります。
Directory Server の一部のエラーメッセージで、実際には存在しない『Database Errors Guide』に言及しています。クリティカルなエラーメッセージの意味が理解できず、そのメッセージについての記述がドキュメントに存在しない場合は、Sun サポートまでお問い合わせください。
ソフトウェアを削除する場合、dsee_deploy uninstall コマンドでは既存のサーバーインスタンスが停止または削除されません。
この制限に対処するには、『Sun Java System Directory Server Enterprise Edition 6.2 Installation Guide』の指示に従ってください。
Directory Server で、サプライヤレプリカ上で pwdFailureTime 属性の値をクリアしたあとも、コンシューマレプリカ上ではこの属性値が保持される現象が確認されています。userPassword の変更がレプリケートされたあとも、属性値は保持されたままです。
送信先サフィックスに対して SSL クライアント認証を使用するとき、dsconf accord-repl-agmt コマンドがレプリケーションアグリーメントの認証プロパティーを整合できません。
この問題点に対処するには、次の手順に従って、サプライヤの証明書をコンシューマ上の設定に格納します。ここで示すコマンド例は、2 つのインスタンスが同じホスト上にあることを前提としています。
証明書をファイルにエクスポートします。
次の例は、/local/supplier および /local/consumer に位置するサーバーを対象にエクスポートを実行する方法を示しています。
$ dsadm show-cert -F der -o /tmp/supplier-cert.txt /local/supplier defaultCert $ dsadm show-cert -F der -o /tmp/consumer-cert.txt /local/consumer defaultCert |
クライアントとサプライヤの証明書を交換します。
次の例は、/local/supplier および /local/consumer に位置するサーバーを対象に交換を実行する方法を示しています。
$ dsadm add-cert --ca /local/consumer supplierCert /tmp/supplier-cert.txt $ dsadm add-cert --ca /local/supplier consumerCert /tmp/consumer-cert.txt |
コンシューマ上で SSL クライアントエントリを追加します。usercertificate;binary 属性に supplierCert 証明書を指定し、適切な subjectDN を指定します。
コンシューマ上でレプリケーションマネージャー DN を追加します。
$ dsconf set-suffix-prop suffix-dn repl-manager-bind-dn:entryDN |
/local/consumer/alias/certmap.conf 内のルールを更新します。
dsadm start コマンドで両方のサーバーを再起動します。
複数バイト文字を含む証明書名は、dsadm show-cert instance-path valid-multibyte-cert-name コマンドの出力ではドットとして示されます。
Directory Service Control Center では、値を文字列としてソートします。そのため、Directory Service Control Center で数字をソートすると、それらの数字は文字列であるかのようにソートされます。
0、20、および 100 を昇順にソートすると、0、100、20 というリストが得られます。0、20、および 100 を降順にソートすると、20、100、0 というリストが得られます。
パスに複数バイト文字を含む Directory Server インスタンスが DSCC に作成されない、起動されない、またはその他の通常のタスクを実行できない可能性があります。
これらの問題の一部は、インスタンスの作成に使用された文字セットを使用することで解決できます。文字セットを設定するには、次のコマンドを実行します。
# cacaoadm list-params | grep java-flags java-flags=-Xms4M -Xmx64M # cacaoadm stop # cacaoadm set-param java-flags="-Xms4M -Xmx64M -Dfile.encoding=utf-8" # cacaoadm start |
これらの問題を回避するには、インスタンスのパスに ASCII 文字のみを使用してください。
エスケープした引用符またはシングルエスケープしたコンマを含む ACI ターゲット DN を Directory Server が正しく解析できません。次の例に示す変更は構文エラーとなります。
dn:o=mary\"red\"doe,o=example.com changetype:modify add:aci aci:(target="ldap:///o=mary\"red\"doe,o=example.com") (targetattr="*")(version 3.0; acl "testQuotes"; allow (all) userdn ="ldap:///self";)
dn:o=Example Company\, Inc.,dc=example,dc=com changetype:modify add:aci aci:(target="ldap:///o=Example Company\, Inc.,dc=example,dc=com") (targetattr="*")(version 3.0; acl "testComma"; allow (all) userdn ="ldap:///self";)
ただし、エスケープしたコンマが 2 つ以上含まれる例は、正しく解析されることが確認されています。
dpconf コマンドを対話型モードで使用するときに、「「cn=Directory Manager」のパスワードを入力:」プロンプトが 2 回表示される現象が確認されています。
Directory Service Control Center では、PKCS#11 外部セキュリティーデバイスまたはトークンを管理できません。
Windows で、SASL 認証が次の 2 つの理由で失敗します。
SASL 暗号化が使用されている。
SASL 暗号化によって生じる問題に対処するには、サーバーを停止し、dse.ldif を編集し、次のように SASL をリセットします。
dn: cn=SASL, cn=security, cn=config dssaslminssf: 0 dssaslmaxssf: 0 |
ネイティブパッケージを使用してインストールが実行された。
ネイティブパッケージのインストールによって生じる問題に対処するには、SASL_PATH を install-dir\share\lib に設定します。
国名を指定すると、Directory Service Control Center による自己署名付き証明書の生成は失敗します。
Directory Service Control Center では、userCertificate バイナリ値が正しく表示されません。
設定属性 passwordRootdnMayBypassModsCheck を有効に設定したときに、別のユーザーのパスワードを変更するときのパスワード構文チェックをすべての管理者が回避できるようにサーバーの動作が変更されましたが、この属性の名前は実際の動作を正しく反映していません。
ZIP 形式の配布パッケージからインストールする前、または dsadm コマンドを使用する前に、LD_LIBRARY_PATH を設定しないでください。
Windows では、dsadm および dpadm コマンドによる出力とヘルプメッセージが、簡体字中国語および繁体字中国語にローカライズされていません。
既存のサーバーの設定をコピーできる Directory Service Control Center の機能を使用して、プラグイン設定をコピーすることはできません。
Windows システムで、LDIF ファイル名に 2 バイト文字が含まれる LDIF を dsconf コマンドでインポートしようとしたときに、インポートが失敗する現象が確認されています。
この問題点に対処するには、2 バイト文字が含まれないように LDIF ファイル名を変更します。
dsadm enable-service コマンドが Sun Cluster に対して正しく機能しません。
Common Agent Container への Monitoring Framework コンポーネントの登録中に dsee_deploy コマンドがハングアップする現象が確認されています。
ルート DSE の supportedSSLCiphers 属性に、サーバーで実際にはサポートされていない NULL 暗号化方式が表示されます。
Directory Server が最低でも 1 回起動されていないと、dsadm enable-service コマンドがシステム再起動時に Directory Server の再起動に失敗します。
Directory Service Control Center と dsconf コマンドのどちらを使用しても、無効なプラグイン署名を Directory Server が処理する方法を設定できません。デフォルトの動作では、プラグインの署名の検証は行われますが、署名が有効であることは要求されません。署名が無効な場合、Directory Server は警告をログに記録します。
サーバーの動作を変更するには、cn=config 上で ds-require-valid-plugin-signature 属性と ds-verify-valid-plugin-signature 属性を調整します。どちらの属性も、値 on または off を設定できます。
Directory Service Control Center では、別のサフィックスにリフェラルを返すように設定されたサフィックスを参照できません。
Windows システムでのインストール後およびサーバーインスタンス作成後は、インストールおよびサーバーインスタンスのフォルダに対するファイルアクセス権により、すべてのユーザーにアクセスが許可されます。
この問題点に対処するには、インストールおよびサーバーインスタンスのフォルダのアクセス権を変更します。
Internet Explorer 6 を使用して、Directory Service Control Center 上で Directory Server のリフェラルモードを有効にすると、リフェラルモードの確認ウィンドウが小さいために、テキストの一部が切れて表示されません。
この問題点に対処するには、Mozilla Web ブラウザなどの別のブラウザを使用します。
新しい証明書を作成または追加したあと、変更を有効にするために Directory Server を再起動する必要があります。
レプリカをアップグレードし、新しいシステムにサーバーを移動したあと、新しいホスト名を使用するレプリケーションアグリーメントを再作成する必要があります。Directory Service Control Center では、既存のレプリケーションアグリーメントを削除できますが、新規アグリーメントを作成することはできません。
Red Hat システムでは、dsadm autostart コマンドによって、ブート時に確実にサーバーインスタンスが起動されるとは限りません。
DSML を設定している場合、dsconf コマンドは、適切な dsSearchBaseDN 設定を要求しません。
Windows システムでは、インスタンスの basename が ds である場合、Directory Server が起動に失敗する現象が確認されています。
ZIP 形式の配布パッケージからインストールする場合、dsee_deploy コマンドでは、SNMP およびストリームアダプタポートを設定するためのオプションが提供されません。
この問題に対処するには、
Web コンソールまたは dpconf を使用して、監視プラグインを有効にします。
cacaoadm set-param を使用して、snmp-adaptor-port、snmp-adaptor-trap-port、および commandstream-adaptor-port を変更します。
dsconf help-properties コマンドは、インスタンス作成後にのみ正しく機能するように設定されています。また、オンラインマニュアルで、dsml-client-auth-mode コマ ンドのデフォルト値が間違って記述されています。正しい値のリストは client-cert-first | http-basic-only | client-cert-only です。
Windows XP システムで Directory Service Control Center を使用するには、ゲストアカウントを無効にする必要があります。さらに、認証を成功させるには、レジストリキー HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\ForceGuest を 0 に設定する必要があります。
ネイティブパッチ配布では、アクセスログのフィルタリング用の日付選択に使用するミニチュアカレンダが、繁体字中国語に正しくローカライズされていません。
schema_push、repldisc、pwdhash、ns-inactivate、ns-activate、ns-accountstatus、mmldif、insync、fildif、entrycmp、dsrepair、dsee_deploy、dsadm show-cert、dsadm repack、および ldif コマンドの出力がローカライズされていません。
dsccmon、dsccreg、dsccsetup、および dsccreg コマンドによって表示される一部の出力がローカライズされていません。
システムのロケールを変更してから DSCC を起動しても、ポップアップウィンドウのメッセージが選択したロケールで表示されません。
英語以外のロケールで Directory Service Control Center を設定する場合、Directory Service Control Center Registry の作成に関するログメッセージは完全にローカライズされていません。一部のログメッセージは、Directory Service Control Center の設定時に使用されたロケールで表示されます。
DSCC 上で、Directory Manager DN に複数バイト文字を指定して作成したインスタンスは、パスワード確認に失敗するため起動されません。
Internet Explorer を使用しているときに「Directory Service Control Center オンラインヘルプの参照」をクリックしても、オンラインヘルプが表示されません。
Directory Server のプラグイン API には、slapi_value_init()()、slapi_value_init_string()()、および slapi_value_init_berval()() 関数が含まれています。
これらすべての関数が内部要素をリリースするためには「done」関数が必要になります。しかし、パブリック API に slapi_value_done()() 関数がありません。
既知の問題点により、Windows インストールの nsslapd-idletimeout は、すべての条件下でドキュメントに記載されているとおりに計算されるわけではありません。
Unix (Solaris を含む) では、ドキュメントに記載されているように、nsslapd-idletimeout は新しい接続が開かれたとき、および新しいデータが受信されたときに計算されます。
Windows では、nsslapd-idletimeout は接続がセキュリティー保護されている場合、または ds-start-tls-enabled が true の場合は同じように計算されます。ただし、接続がセキュリティー保護されていない場合と、ds-start-tls-enabled が false の場合は、nsslapd-idletimeout は新しい接続が開かれたときにのみ計算されます。
インターネットサービスプロバイダにより設定されている制限によっては、DSCC に長い ACI が表示されないことがあります。
Linux では、Directory Server インスタンスが、そのインスタンスの作成されたロケールとは異なるロケールで起動されると、複数バイト文字が正しく表示されません。
Solaris 10 で Service Management Facility (SMF) を使用してサーバーインスタンスを有効にした場合、システムをリブートしてもインスタンスが起動しないことがあります。
この問題を回避するには、次に示す + でマークされた行を /opt/SUNWdsee/ds6/install/tmpl_smf.manifest に追加します。
... restart_on="none" type="service"> <service_fmri value="svc:/network/initial:default"/> </dependency> + <dependency name="nameservice" grouping="require_all" \ + restart_on="none" type="service"> + <service_fmri value="svc:/milestone/name-services"/> + </dependency> <exec_method type="method" name="start" exec="%%%INSTALL_PATH%%%/bin/dsadm start --exec %{sunds/path}"... |
Directory Server Enterprise Edition Windows サービスは、システムの再起動時に複数のサーバーインスタンスの起動に失敗します。
DSCC が Tomcat 5.5 および JDK 1.6 とともに使用されている場合、エラーが発生する可能性があります。
この問題を回避するには、代わりに JDK 1.5 を使用します。
Solaris 10 にバンドルされている Sun Java System Application Server では、認証メカニズム用の SASL クライアント接続を作成できないので、共通エージェントコンテナと通信できません。
この問題を回避するには、appserver-install-path/appserver/config/asenv.conf ファイルを編集して、AS_JAVA エントリを AS_JAVA="/usr/java" に置き換えることで、アプリケーションサーバーによって使用される JVM を変更します。アプリケーションサーバーのドメインを再起動します。
dsadm autostart によって、システムのリブート時にネイティブの LDAP 認証が失敗することがあります。
この問題を回避するには、リブートスクリプトの順序を逆にします。デフォルトの順序は /etc/rc2.d/S71ldap.client および /etc/rc2.d/S72dsee_directory です。
アプリケーションサーバーに Web Archive (WAR) ファイルを配備して、DSCC を設定した場合、DSCC の「バージョン」ウィンドウに html ソースコードが表示される可能性があります。この問題を回避するには、domain-path/domain-name/config/default-web.xml に次のエントリを追加します。
<mime-mapping> <extension>shtml</extension> <mime-type>text/html</mime-type> </mime-mapping> |
英語以外の言語で、DSCC を利用している場合、進行状況ウィンドウに表示されるローカライズされたサーバーメッセージに含まれる複数バイト文字が、文字化けして表示されることがあります。
Web Archive (WAR) ファイルを使用して構成された DSCC 上でオンラインヘルプにアクセスすると、エラーが表示されます。
idsktune コマンドは、SuSE Enterprise Linux をサポートしていません。
システムで解凍機能が利用できない場合、dsee_deploy はどの製品もインストールしません。
インスタンスの「詳細な表示オプション」で、「アクセスログ」タブ、「エラーログ」タブ、および「監査ログ」タブの日付がローカライズされていません。
Directory Server の複数の属性で一意性プラグインを使用できるよう設定すると、Directory Server の起動時にエラーが表示されます。
サーバーインスタンスを停止せずに Directory Server Enterprise Edition 6.2 パッチを適用すると、dsadm info および dsadm stop は、サーバーの実行中にサーバーがダウンしていることを示します。
韓国語および簡体字中国語のメッセージの一部で、文字列 err= が翻訳されていません。
Solaris で、システムの再起動後、サービスとして登録されているインスタンスが起動しないことがあります。
この問題を回避するには、次のコマンドを実行します。
# /usr/sbin/svccfg svc:> select application/sun/ds svc:/application/sun/ds> delpropvalue start/timeout_seconds 60 svc:/application/sun/ds> delpropvalue stop/timeout_seconds 60 svc:/application/sun/ds> addpropvalue start/timeout_seconds 600 svc:/application/sun/ds> addpropvalue stop/timeout_seconds 600 svc:/application/sun/ds> quit |
dsconf のフランス語のヘルプで、Directory Server が serveur d'annuaire ではなく、répertoire と誤訳されていることがあります。
Tomcat サーバーで構成された DSCC で、「ヘルプ」および「バージョン」ポップアップウィンドウのタイトルに含まれる複数バイト文字が文字化けしています。
構成プロパティー (pwd-max-history-count) またはパスワードポリシー属性 (pwdInHistory) を上限値である 24 に設定すると、Directory Server インスタンスがクラッシュすることがあります。
この問題を回避するには、pwd-max-history-count または pwdInHistory を 23 以下の値にする必要があります。
フランス語、ドイツ語、およびスペイン語で、dsconf enable-repl -? コマンド構文の ROLE は翻訳されているが、後出の ROLE = master 文字列では翻訳されていません。
コマンド行インタフェースのヘルプで、INSTANCE_PATH がドイツ語およびスペイン語に翻訳されていません。
Linux で、/etc/security/limits.conf ファイルにファイルの最大数が指定されていると、システム再起動時に Directory Server インスタンスが起動しません。
この問題を回避するには、etc/init.d/dsee_directory ファイルに次の行を追加します。
# ulimit -Hn 65536 # ulimit -Sn 65536 |
フランス語のロケールで、サーバーの停止または登録解除を確認するポップアップウィンドウに重複したアポストロフィーが表示されます。