この章では、すでに判明している Sun N1 Service Provisioning System 5.1 の問題について説明します。
このセクションでは、アンインストールに関連する既知の問題について説明します。
Windows Master Server の side-by-side アップグレードを行い、即座にアンインストールを試みると、アンインストールは失敗します。アンインストールを確実に行うには、手動の介入とリブートが必要な場合があります。
対処方法: Master Server のアンインストールを行う前に Windows コントロールパネルの Services アプリケーションから Master Server サービスを停止してください。アンインストールが完了した時点では、Master Server サービスはまだ残っています。マシンをリブートし、Windows コントロールパネルの Services アプリケーションから Master Server サービスのエントリを削除してください。
Sun N1 Service Provisioning System Windows バージョンのローカルディストリビュータまたはリモートエージェントを新バージョンにアップグレードしたあとでそのローカルディストリビュータまたはリモートエージェントをアンインストールすると、アンインストールウィンドウのタイトルに古いバージョン番号が表示されます。
対処方法: アンインストールプログラムは正常に動作しています。タイトルの不正表示は無視してください。
この節では、判明している実行時の問題について説明します。
execNative ステップをバックグラウンドオプションを指定して実行する場合、このコマンドはすぐに開始されず、実行開始までに 10 分以上かかる場合があります。
この問題は、オープンファイル記述子の数が 100 万を超えるかまたは無制限の値に設定されている IBM AIX システムで起きます。無制限の場合、約 20 億に相当します。ulimit -n コマンドを実行することにより、オープンファイル記述子の最大数に対する現在のソフト制限を決定できます。
対処方法: エージェントプロセスを実行するユーザーまたはすべてのユーザーについて、/etc/security/limits ファイルの nofiles パラメタの値を 2000 に設定してください。再起動後にこの値は残り、マシン上のすべてのユーザーに影響します。
nofiles パラメタの値は 100,000 を超えないようにしてください。
/etc/security/limits ファイルの詳細を参照するには、次の操作を行います。
IBM AIX Information Center (http://publib.boulder.ibm.com/infocenter/pseries/index.jsp) に移動します。
検索テキストフィールドに limits file と入力します。
「GO」ボタンをクリックします。
検索結果の「limits File」リンクをクリックします。
setuid ビットを「yes」に設定した SUSE Linux 9 を実行するシステムにリモートエージェントをインストールしたあと、 /protect/jexec ファイルの権限が不正になります。
権限は次のとおりです。
---x--x--- 1 root other 21864 2005-08-15 03:16 jexec |
この権限は次のようにすべきです。
---s--x--- 1 root other 21864 2005-08-15 03:16 jexec |
対処方法: インストールが完了したあと、次のコマンドを使って手動でファイルの権限を修正します。
% chmod 4110 $BASEDIR/agent/bin/protect/jexec |
$BASEDIR はインストールディレクトリです。
バージョンの異なるコンポーネントで直接実行のコンポーネント手順を実行した場合、コンポーネントを削除できないことがあります。
この状況は、特定の直接実行のコンポーネント手順を 1.0 以外のバージョンのコンポーネントで最初に実行し、そのあとで同じ直接実行のコンポーネント手順をバージョン 1.0 のコンポーネントで実行する場合に起きます。
バージョン 1.0 のコンポーネントまたは最初に実行した直接実行のコンポーネントを削除できません。1 つのバージョンの直接削除も両方のバージョンの一括削除もできません。
削除に代わる手段として、問題となっているコンポーネントを非表示にして、表示から削除することができます。
対処方法: 次のいずれかの方法を使って、問題を回避します。
直接実行のコンポーネント手順は、必ずバージョン 1.0 のコンポーネントで最初に実行します。
直接実行のコンポーネント手順をほかのバージョンで実行したら、ルートのコンポーネントでは実行しないでください。
Solaris リモートエージェントで「Detailed Preflight」オプションを選択してプランを実行する場合、プリフライト中にプランが失敗して次のエラーメッセージが表示されます。
The system was unable to create VirtualAgent for host xxx. (017009) Unable to connect to agent at host xxx. (026000) Unable to create an internal representation of host xxx. (017030) Unexpected exception thrown on the server-side. (022046) readdir_r() on "/" failed: "Unknown error [-1]". (025006) |
対処方法: プランを実行するときに「Detailed Preflight」オプションを選択しないでください。
「Check In Current」処理を使用することで、ユーザーは Master Server リポジトリ内のコンポーネントのバージョンを最新状態に維持できます。Master Server は、ソースホスト上のバージョンに照らしてそのコンポーネントのバージョンを確認します。この確認は、前回のチェックイン時に収集されたコンポーネント位置についてのメタデータに基づいて行われます。
「Check In Current」処理は、すべてのコンポーネントタイプに対して行えるわけではありません。一般に、ブラウザインタフェースを使用してブラウズできるコンポーネントタイプは「Check In Current」処理が行えます。
「Check In Current」処理をまとめて行う場合、「Check In Current」処理をサポートしないコンポーネントタイプを選択すると、エラーが表示されないまま処理が完了します。サポートされていないコンポーネントタイプについては、「Progress」ダイアログボックスに結果が何も表示されないこともあれば、履歴データとして現れることもあります。
対処方法: 回避策はありません。
Sun N1 Service Provisioning System を Red Hat Linux Advanced Server 3.0 で稼働させている場合、Secure Socket Layer (SSL) 接続を使用するとシステムがハングアップすることがあります。
SSL は、/dev/random を使用して乱数を生成する SecureRandom を使用します。Red Hat Linux Advanced Server 3.0 には、 /dev/random のエントロピ収集を妨げるというバグがあります。十分なエントロピが収集されないと /dev/random は乱数を生成しないため、/dev/random からランダムデータを読み取ろうとしてアプリケーションはハングアップします。
対処方法: 次の回避策の中から 1 つを選択します。
Red Hat プランに Update 3 のパッチを含めて、この問題を修正する。Red Hat のパッチが提供された時点で、パッチをシステムに適用します。Red Hat パッチの詳細は、 http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=117218 を参照してください。
接続タイプとして SSL を使用せず、TCP/IP または SSH を選択する。
/dev/random を削除し、代わりに /dev/urandom に対するシンボリックリンクを使用する。/dev/urandom は /dev/random よりも安全性に劣りますが、Red Hat Linux Advanced Server 3.0 上でプロビジョニングシステムが SSL 接続を試みる際にシステムのハングアップは発生しません。
基準がわずかしか存在しないか、あるいはまったく基準が含まれない通知規則を作成すると、プランの実行速度が遅いように見えることがあります。プランの実行が遅いのではく、プラン結果の表示が遅いという可能性があります。
対処方法: 通知規則を作成するときにできるだけ多くの基準を使用します。通知規則の基準を増やすと、ネットワーク上でプロビジョニングシステムが送信する通知電子メールの数が減ります。通知電子メールの数が少なくなると、プラン結果の表示が妨げられる可能性が低くなります。
この節では、Windows 2000 プラグインの既知の問題について説明します。
タイプがレジストリキーである単一リソースを持つコンポーネントを作成できます (キャプチャするエントリは単一のデフォルト値となる)。しかし、付随するレジストリキーを指定せずにその値は配備できても、そのアンインストールや削除はできません。パスが無効であることを知らせるメッセージが表示されます。
対処方法: キャプチャするレジストリキーに含まれる値がデフォルト値のみにならないようにしてください。(キーとデフォルト値を含めるなど)。
IIS 設定のスナップショットを含む「モデルとインストール」タイプの比較を行う場合、ターゲットサーバー上で IIS 設定をいったん変更し、そのあと元の値に戻すと、相違がまったくないにもかかわらず、比較結果に相違が報告されることがあります。特に、親ノードから継承されたメタベースプロパティ (Web サイトの読み取り / 書き込み許可やデフォルトのドキュメント設定など) ではこのような現象が発生しがちです。
対処方法: このようなケースで報告される相違は無視してください。
Windows IIS アプリケーションをアンインストールする場合、Master Server ブラウザインタフェースはアンインストールが正常に完了したというメッセージを表示します。しかし、COM+ アプリケーションは完全には削除されていません。COM+ アプリケーションは、コントロールパネルの「プログラムの追加と削除」内に残ったままとなります。
対処方法: 残った COM+ アプリケーションを手動で削除してください。
この問題を防ぐには、アプリケーションのインストール時に shutdownDelaySecs 変数の値を増やしてください。
この節では、WebLogic プラグインの既知の問題について説明します。
WebLogic で管理された複数の仮想サーバーに配備されている EJB コンポーネントに対してデフォルトのアンインストール手続きを実行し、それらのサーバーの 1 つだけをアンインストールの対象として選択した場合、EJB コンポーネントがそのサーバーからアンインストールされたようには見えません。
しかし、アンインストール後、EJB をアンインストールした管理対象サーバーの WebLogic コンソール上のタブをクリックすると、EJB がもはや存在しないことが正しく報告されます。また、EJB タブをクリックすると、EJB がアンインストールされた管理対象サーバーでは現在 EJB は使用されていないことが報告されます。
しかし、EJB タブでは EJB がその管理対象サーバーに配備されていると報告されます。
管理対象であるすべてのサーバーから EJB をアンインストールすると、EJB は WebLogic コンソールから正しく除去されます。
対処方法: WebLogic プラグインは正常にアンインストールされています。不正表示は無視してください。
WAR ファイルと Web アプリケーションの設定が登録されている Web アプリケーションコンテナを含む WebLogic Web アプリケーションを配備し、スナップショットを含め、その後 WebLogic Console から Web アプリケーションを削除した場合、Web アプリケーションコンポーネントについて「モデルとインストール」タイプの比較を行うと、次のエラーが表示されます。
Could not complete operation on webapp domain. No such webapp exists on domain /domain/. (310101) |
この比較では、モデルと、サーバーに実際にインストールされているものの相違が報告されるべきですが、比較は失敗に終わります。
対処方法: 回避策はありません。
管理対象サーバーまたはクラスタに配備されている WebLogic WAR または EJB コンポーネントを WebLogic Console を使用して削除しても、WebLogic Console にはその管理対象サーバーまたはクラスタで WAR または EJB コンポーネントがまだ使用されていると報告されます。このため、管理対象サーバーまたはクラスタの「モデルとインストール」タイプの比較を行なっても、相違が報告されません。「モデルとインストール」タイプの比較では、WebLogic Console がチェックされるため、使用中のアプリケーション (ターゲットとされたアプリケーション) は配備されているものとして報告されます。
対処方法: 回避策はありません。
Sun N1 Service Provisioning System 5.1 を使用して WebLogic アプリケーションをインストールし、その後管理サーバー上のオンディスク WAR アーカイブの内容を変更した場合、比較結果にこの変更が報告されません。構成に変更を加えた場合には、この問題は発生しません。
対処方法: 拡張機能である generate と prepare を使用することで、比較作業をカスタマイズし、比較を実際に行う前にオンディスクアーカイブをあらかじめ処理することができます。このようなカスタマイズは、高度なスクリプト処理が必要になることがあります。
Sun N1 Service Provisioning System 5.1 で WebLogic 管理サーバーを設定する際に「Secure」チェックボックスをクリックすると、SSL 使用した接続の設定が試みられます。この選択では、WebLogic 管理サーバーへのアクセスを要求する操作を試みるとエラーが発生します。
対処方法: WebLogic 管理サーバーとの接続は、SSL 接続を要求するように設定してください。「Secure」チェックボックスは選択しないでください。
この節では、英語ロケール以外で Sun N1 Service Provisioning System 5.1 を使用する際に発生する問題について説明します。
Latin-1 ロケール環境では、検索パターンに非 ASCII 文字を使用しないでください。たとえば、ドイツ語のウムラウトやフランス語のアクサンなどです。検索操作を実行したときに、期待した一致結果が表示されない場合があります。
対処方法: Latin-1 ロケールのユーザーは、検索コマンドの入力に非 ASCII 文字を使用しないでください。非 ASCII 文字を使用すると、期待した結果が得られない場合があります。このようなロケールでは、ASCII 文字だけを使用してください。
Sun N1 Service Provisioning System 内の文字ベースのデータは、標準の辞書目録を使用してソートされます。ロケール固有の照合はなされません。したがって、アクセント記号付きの文字は、同文字のアクセント記号なしのものと同じ場所には表示されません。