この節では、判明している実行時の問題について説明します。
「Check In Current」処理を使用することで、ユーザーは Master Server リポジトリ内のコンポーネントのバージョンを最新状態に維持できます。Master Server は、ソースホスト上のバージョンに照らしてそのコンポーネントのバージョンを確認します。この確認は、前回のチェックイン時に収集されたコンポーネント位置についてのメタデータに基づいて行われます。
「Check In Current」処理は、すべてのコンポーネントタイプに対して行えるわけではありません。一般に、ブラウザインタフェースを使用してブラウズできるコンポーネントタイプは「Check In Current」処理が行えます。
「Check In Current」処理をまとめて行う場合、「Check In Current」処理をサポートしないコンポーネントタイプを選択すると、エラーが表示されないまま処理が完了します。サポートされていないコンポーネントタイプについては、「Progress」ダイアログボックスに結果が何も表示されないこともあれば、履歴データとして現れることもあります。
対処方法: 対応策はありません。
N1 Grid 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 接続を試みる際にシステムのハングアップは発生しません。
「Plug-Ins」ページのブラウザインタフェースから 40MB を超えるファイルのインポートを試みると、インポートは失敗します。
対処方法: 40MB を超えるプラグインファイルをインポートする場合は、CLI Client で plg.p.add コマンドを使用してください。手順については、『N1 Grid Service Provisioning System 5.0 コマンド行インタフェース (CLI) リファレンスマニュアル』の第 11 章「plg:プラグインの CLI コマンド」を参照してください。
ブラウザインタフェースを使用して新しいファイルコンポーネントを作成し、そのコンポーネントに対して「Check In Current」処理を実行してバージョン 1.1 を作成した場合、両方のコンポーネントバージョンを同時に削除しようとすると、次のエラーメッセージが表示されます。
The 1.0 version of the object cannot be deleted as long as other versions of the same object exist. |
対処方法: 2 つのコンポーネントをまとめて削除せず、別々に削除してください。
基準がわずかしか存在しないか、あるいはまったく基準が含まれない通知規則を作成すると、プランの実行速度が遅いように見えることがあります。プランの実行が遅いのではく、プラン結果の表示が遅いという可能性があります。
対処方法: 通知規則を作成する場合は、できるだけ多くの基準を使用してください。通知規則の基準を増やすと、ネットワーク上でプロビジョニングシステムが送信する通知電子メールの数が減ります。通知電子メールの数が少なくなると、プラン結果の表示が妨げられる可能性が低くなります。
Master Server 上で利用できる API の一部は、アクセス許可をまったくチェックしません。アクセス許可をチェックしない状態では、認証を受けていないユーザーがこれらのサービスを起動し、Master Server に害を及ぼす可能性があります。
対処方法: Master Server と CLI Client は、未承認アクセスを防止するように設定できます。Master Server と CLI Client では、次のセキュリティオプションを利用できます。
SSL を使用して CLI Client に接続するように Master Server を構成する
N1 Grid Service Provisioning System へのアクセスが許可されたユーザーしかアクセスできないサーバーに CLI Client をインストールする
(Solaris OS、Red Hat Linux、IBM AIX サーバーの場合) 承認されたプロビジョニングシステムユーザーだけから構成されるユーザーグループ内に CLI Client をインストールする
N1SPS5.0-CLI-home/cli/data/private.store で、CLI Client プライベートキーストアのアクセス許可を 640 に設定する。このアクセス許可を設定すると、承認されたプロビジョニングシステムユーザーだけが CLI Client プライベートキーにアクセスし、Master Server への接続を確立できる状態となります。
(Windows 2000 システムの場合) 承認されたプロビジョニングシステムユーザーだけに CLI Client プライベートキーストアの読み取り許可を与える
バックアップファイルの作成に使用した Master Server パス以外のパスにインストールされた Master Server にデータを復元しようとすると、その復元は失敗します。次のメッセージが表示されます。
ERROR! Failed to restore the database successfully. The following fatal errors were encountered ERROR: stat failed on file 'N1SPS5.0-MS-home/': No such file or directory |
N1SPS5.0-MS-home は、バックアップファイルの作成に使用された Master Server のホームディレクトリです。
対処方法: Master Server データを復元するサーバーで、バックアップの作成に使用した Master Server と同じディレクトリに Master Server をもう一度インストールしてください。