Sun N1 System Manager 1.2 管理ガイド

Previous: 第 5 章サーバーの監視

第 6 章障害追跡

この章では、次の項目に関する障害追跡情報を提供します。

検出の問題

検索に失敗した場合、ジョブ出力に次が含まれていると、対象サーバーは SNMP 接続が最大数に達しています。

Error. The limit on the number of SNMP destinations has been exceeded.

Sun Fire V20z および V40z のサービスプロセッサには、SNMP 接続先が 3 つという制限があります。現在の SNMP 接続先を表示するには、次の手順を実行します。

SSH を使用し、サービスプロセッサにログインします。
次のコマンドを実行します。
sp get snmp-destinations

SNMP 接続先が出力に表示されます。

V20z または V40z の接続先が 3 つある場合、検出に失敗します。障害が発生したのは、検出中に N1 System Manager がサービスプロセッサに snmp-destination を追加したからです。

SNMP 接続先は、N1 System Manager などの管理ソフトウェアによってサービスプロセッサに設定できます。SNMP 接続先のエントリが不要になった場合は、SNMP 接続先からエントリを削除できます。ある管理サーバーで N1 System Manager を使用して対象サーバーを検出した後で、サーバーを削除することなく、その管理サーバーを使用しなくなった場合にこの状態になります。エントリを削除する場合は、サービスプロセッサで sp delete snmp-destination コマンドを使用します。他の管理ソフトウェアが監視のために必要としている可能性があるため、削除コマンドの使用には注意が必要です。ただし、delete server コマンドを使用して N1 System Manager からサーバーが削除されると、プロビジョニング可能なサーバーの SNMP 接続先が削除されます。プロビジョニング可能なサーバーを削除するときは、delete server コマンドの使用が適しています。

セキュリティーの問題

この節では、セキュリティーに関する障害追跡情報を提供します。

N1 System Manager は強力な暗号化手法を用いて、管理サーバーと管理対象の各サーバーとの間の通信の安全を確保します。

N1 System Manager が使用するキーは、Linux を実行する各サーバーの /etc/opt/sun/cacao/security ディレクトリに格納されます。Solaris OS を実行するサーバーでは、これらのキーが /etc/opt/SUNWcacao/security ディレクトリに格納されます。

セキュリティーキーを再生成する理由

N1 System Manager で使用されるセキュリティーキーは、すべてのサーバーで同一な必要があります。通常動作では、キーで使用されるセキュリティーキーがデフォルト状態のままでかまいません。セキュリティーキーの再生成が必要になることもあります。

管理サーバーの root パスワードが外部に漏れた恐れがある場合、セキュリティーキーを再生成してください。
管理サーバーのシステム日付が、date コマンドを使用して変更された場合、セキュリティーキーを再生成してください。date コマンドを使用して管理サーバーのシステム日付が変更された場合、N1 System Manager 管理デーモン n1sminit が次回再起動したときに、管理サーバーでそれ以降サービスが提供されなくなる恐れがあります。この場合は、キーを再生成し、N1 System Manager 管理デーモンを再起動する必要があります。説明は、「共通エージェントコンテナのセキュリティーキーを再生成する」にあります。

共通エージェントコンテナのセキュリティーキーを再生成する

手順

管理サーバー上でスーパーユーザー権限を使い、N1 System Manager 管理デーモンを停止します。
# /etc/init.d/n1sminit stop

create-keys サブコマンドを使用し、セキュリティーキーを再作成します。

Linux がインストールされている管理サーバーの場合
# /opt/sun/cacao/bin/cacaoadm create-keys --force
Solaris OS がインストールされている管理サーバーの場合
# /opt/SUNWcacao/bin/cacaoadm create-keys --force

管理サーバー上でスーパーユーザー権限を使い、N1 System Manager 管理デーモンを再起動します。
# /etc/init.d/n1sminit start

一般的なセキュリティー上の留意点

N1 System Manager を使用する際に、注意しなければならない一般的なセキュリティー上の留意点を次に示します。

N1 System Manager のブラウザインタフェースの起動に使用する Java^TM Web Console は、自己署名の証明書を使用します。これらの証明書は、クライアントとユーザーによって、適切な信頼レベルをもって取り扱われるべきです。
ブラウザインタフェースでシリアルコンソール機能用に使用される端末エミュレータアプレットは、証明書に基づくアプレットの認証を提供しません。またアプレットを使用するには、管理サーバーの SSHv1 を有効にする必要があります。証明書に基づく認証を使用する、または SSHv1 を有効にしない場合は、n1sh シェルから、connect コマンドを実行してシリアルコンソールを使用してください。
プロビジョニング可能なサーバーで管理サーバーからプロビジョニングネットワークインタフェースへの接続に使用される SSH フィンガープリントは、N1 System Manager ソフトウェアによって自動的に認識されます。この自動認識によって、プロビジョニング可能なサーバーは、中間者攻撃を受けやすくなる場合があります。
Sun Fire X4100 および Sun Fire X4200 サーバーの Web Console (Sun ILOM Web GUI) 自動ログイン機能は、サーバーのサービスプロセッサ資格を、「ログイン」ページの Web ページソースを参照できるユーザーに公開してしまいます。このセキュリティー上の問題を回避するには、n1smconfig ユーティリティーを実行して自動ログイン機能を使用不可にします。詳細は、『Sun N1 System Manager 1.2 インストールおよび構成ガイド』の「N1 System Manager システムの設定」を参照してください。

OS ディストリビューションの障害追跡

ここでは、OS の配備が失敗する例、およびその問題を修正する方法を説明します。

ディストリビューションのコピーの失敗

ファイルのコピーエラーで、OS ディストリビューションの作成に失敗した場合は、ISO イメージの容量を確認し、また、データが壊れていないことを確かめてください。ジョブの詳細に、次に類似する出力がみられることがあります。

bash-3.00# /opt/sun/n1gc/bin/n1sh show job 25
ジョブ ID:　　  25
日時:　　　     2005-07-20T14:28:43-0600
種類:　　　     OS ディストリビューションの作成
ステータス:     エラー (2005-07-20T14:29:08-0600)
コマンド:　     create os RedHat file /images/rhel-3-U4-i386-es-disc1.iso
所有者:　　     root
エラー:　　     1
警告:　　　     0

ステップ
ID     種類　　　　　    開始
Completion                    結果
1      ホスト取得　　    2005-07-20T14:28:43-0600
2005-07-20T14:28:43-0600      完了
2      コマンドの実行    2005-07-20T14:28:43-0600
2005-07-20T14:28:43-0600      完了
3      ホスト取得　　    2005-07-20T14:28:46-0600
2005-07-20T14:28:46-0600      完了
4      コマンドの実行    2005-07-20T14:28:46-0600
2005-07-20T14:29:06-0600      エラー 1

エラー
エラー 1:
Description: INFO   : Mounting /images/rhel-3-U4-i386-es-disc1.iso at
/mnt/loop23308
INFO   : Version is 3ES, disc is 1
INFO   : Version is 3ES, disc is 1
INFO   : type redhat ver: 3ES
cp: /var/opt/SUNWscs/data/allstart/image/3ES-bootdisk.img: Bad address
INFO   : Could not copy PXE file bootdisk.img
INFO   : umount_exit: mnt is: /mnt/loop23308
INFO   : ERROR: Could not add floppy to the Distro

結果
結果 1:
サーバー:　   -
ステータス:   -1
メッセージ:   Creating OS rh30u4-es failed.

この場合は、別のディストリビューションファイルセットを管理サーバーにコピーしてください。「CD または DVD から OS ディストリビューションをコピーする」または「ISO ファイルから OS ディストリビューションをコピーする」を参照してください。

マウントポイントの問題

ディストリビューションのコピー失敗は、/mnt マウントポイントにファイルシステムがある場合も起きます。create os コマンドの実行前に、/mnt マウントポイントからすべてのファイルシステムを他に移動してください。

Solaris 9 ディストリビューションへのパッチの適用

Linux がインストールされている管理サーバーから、サーバーに Solaris 9 OS ディストリビューションを配備できない問題は、通常 NFS マウントの問題が原因です。この問題を解決するには、Solaris 9 OS ディストリビューションの mini-root にパッチを適用する必要があります。ここでは、必要なパッチを適用する手順を説明します。手順は、次の表に示すように、管理サーバーおよびパッチサーバーの構成によって異なります。

表 6–1 Solaris 9 ディストリビューションへのパッチの適用の作業マップ


管理サーバー	パッチサーバー	作業
Red Hat 3.0 u2	Solaris 9 OS x86 プラットフォーム版	「Solaris 9 OS x86 パッチサーバーを使用して Solaris 9 OS ディストリビューションにパッチを適用する」
Red Hat 3.0 u2	Solaris 9 OS SPARC 版	「Solaris 9 OS SPARC パッチサーバーを使用して Solaris 9 OS ディストリビューションにパッチを適用する」

プロビジョニング可能なサーバーの使用による OS ディストリビューションへのパッチ適用

パッチサーバーを使用して次の作業を行うときは、管理サーバーおよびプロビジョニング可能なサーバーの両方に対して同時に root でアクセスする必要があります。作業の一部では、はじめにプロビジョニング可能なサーバーにパッチを適用し、それから管理サーバーをマウントしてディストリビューションにパッチを適用する必要があります。

Solaris 9 OS x86 パッチサーバーを使用して Solaris 9 OS ディストリビューションにパッチを適用する

ここでは、N1 System Manager 内の Solaris 9 OS ディストリビューションにパッチを適用する手順を説明します。この説明の各手順は、パッチサーバーおよび管理サーバーの両方で実行する必要があります。ここで説明しているパッチは、N1 System Manager で Solaris OS 9 アップデート 7 以前をプロビジョニングできるようにするために必要です。Solaris OS 9 アップデート 8 以降では、この手順が必要ありません。

2 つの端末ウィンドウを開いて各手順を実行することをお勧めします。この手順では、まずパッチサーバーにパッチを適用し、そのあとディストリビューションにパッチを適用します。

始める前に

管理サーバーに Solaris 9 OS ディストリビューションを作成します。「CD または DVD から OS ディストリビューションをコピーする」または「ISO ファイルから OS ディストリビューションをコピーする」を参照してください。OS ディストリビューションの ID を表示するには、コマンド行で show os os-name と入力します。この番号は、説明の中では DISTRO_ID としています。
管理サーバーではないマシンに Solaris 9 OS x86 プラットフォーム版をインストールします。
Solaris 9 x86 パッチサーバーに /patch ディレクトリを作成します。
Solaris OS x86 ディストリビューションでは、Solaris 9 OS x86 パッチサーバーの /patch ディレクトリに次のパッチをダウンロードして展開します。117172-17 および 117468-02。パッチは、http://sunsolve.sun.com にあります。
Solaris OS SPARC ディストリビューションでは、Solaris 9 OS x86 パッチサーバーの /patch ディレクトリに次のパッチをダウンロードして展開します。117171-17、117175-02、および 113318-20。これらのパッチも、http://sunsolve.sun.com で入手できます。

手順

Solaris 9 OS x86 パッチサーバーにパッチを適用します。
1. root としてログインします。
  % su password:password
  root プロンプトが表示されます。
2. Solaris 9 パッチサーバーをシングルユーザーモードで再起動します。
  # reboot -- -s
3. シングルユーザーモードでパッチディレクトリに移動します。
  # cd /patch
4. パッチをインストールします。
  # patchadd -M . 117172-17 # patchadd -M . 117468-02
  ヒント –
  マルチユーザーモードに戻るには、Control+D キーを押します。

管理サーバーでディストリビューションにパッチを適用する準備をします。
1. root として管理サーバーにログインします。
  % su password:password
  root プロンプトが表示されます。
2. /etc/exports ファイルをエディタで開きます。
  # vi /etc/exports
3. /js *(ro,no_root_squash) を /js *(rw,no_root_squash) に変更します。
4. /etc/exports ファイルを保存して閉じます。
5. NFS を再起動します。
  # /etc/init.d/nfs restart

管理サーバーにコピーしたディストリビューションにパッチを適用します。
1. root として Solaris 9 パッチサーバーにログインします。
  % su password:password
  root プロンプトが表示されます。
2. 管理サーバーをマウントします。
  # mount -o rw management-server-IP:/js/DISTRO_ID /mnt
3. 次のいずれかの操作を行いパッチをインストールします。
  - x86 ディストリビューションにパッチを適用する場合は、次のコマンドを入力します。
    # patchadd -C /mnt/Solaris_9/Tools/Boot/ -M /patch 117172-17 # patchadd -C /mnt/Solaris_9/Tools/Boot/ -M /patch 117468-02
  - SPARC ディストリビューションにパッチを適用する場合は、次のコマンドを入力します。
    # patchadd -C /mnt/Solaris_9/Tools/Boot/ -M /patch 117171-17 # patchadd -C /mnt/Solaris_9/Tools/Boot/ -M /patch 117175-02 # patchadd -C /mnt/Solaris_9/Tools/Boot/ -M /patch 113318-20
    注 –
    最初のパッチのインストールでは、部分エラーが発生します。このエラーは無視してください。
4. 管理サーバーをマウント解除します。
  # unmount /mnt

管理サーバーで NFS を再起動します。
1. /etc/exports ファイルを編集します。
  # vi /etc/exports
2. /js *(rw,no_root_squash) を /js *(ro,no_root_squash) に変更します。
3. NFS を再起動します。
  # /etc/init.d/nfs restart
  NFS が再起動します。
  
  これで、Solaris 9 OS SPARC ディストリビューションを対象のサーバーに配備する準備ができました。

Solaris 9 OS x86 ディストリビューションを修正します。
1. /js/<distro_id>/Solaris_9/Tools/Boot/boot/solaris に移動します。
  # cd /js/<distro_id>/Solaris_9/Tools/Boot/boot/solaris
2. bootenv.rc リンクを作成し直します。
  # ln -s ../../tmp/root/boot/solaris/bootenv.rc .
  これで、Solaris 9 OS x86 ディストリビューションを対象のサーバーに配備する準備ができました。

注意事項

別のディストリビューションにパッチを適用する場合は、 /patch/117172-17 ディレクトリをいったん削除して、unzip 117172-17.zip コマンドを使ってディレクトリを作成し直さなければならないことがあります。最初のディストリビューションへのパッチ適用時に、patchadd コマンドによって、ディレクトリに変更が加えられるため、次の patchadd コマンドの実行で問題が生じます。

Solaris 9 アップデート 8 ビルド 5 OS 以降では、このパッチが不要です。そのため、Solaris 9 9/05 s9x_u8wos_05 以降の Solaris OS では、このパッチが必要ありません。

Solaris 9 OS SPARC パッチサーバーを使用して Solaris 9 OS ディストリビューションにパッチを適用する

ここでは、N1 System Manager 内の Solaris 9 OS ディストリビューションにパッチを適用する手順を説明します。この説明の各手順は、プロビジョニング可能なサーバーおよび管理サーバーで実行する必要があります。2 つの端末ウィンドウを開いて各手順を実行することをお勧めします。この手順では、まずプロビジョニング可能なサーバーにパッチを適用し、そのあとディストリビューションにパッチを適用します。

始める前に

管理サーバーに Solaris 9 OS ディストリビューションを作成します。「CD または DVD から OS ディストリビューションをコピーする」または「ISO ファイルから OS ディストリビューションをコピーする」を参照してください。OS ディストリビューションの ID を表示するには、show os os-name と入力します。この番号は、説明の中では DISTRO_ID としています。
管理サーバーではないマシンに Solaris 9 OS SPARC プラットフォーム版をインストールします。「サーバーまたはサーバーグループに OS プロファイルをロードする」を参照してください。
Solaris 9 SPARC パッチサーバーに /patch ディレクトリを作成します。
Solaris OS x86 ディストリビューションでは、Solaris 9 OS x86 パッチサーバーの /patch ディレクトリに次のパッチをダウンロードして展開します。117172-17 および 117468-02。パッチは、http://sunsolve.sun.com にあります。
Solaris OS SPARC ディストリビューションでは、Solaris 9 OS x86 パッチサーバーの /patch ディレクトリに次のパッチをダウンロードして展開します。117171-17、117175-02、および 113318-20。これらのパッチは、 http://sunsolve.sun.com で入手できます。

手順

Solaris 9 OS SPARC マシンをセットアップし、パッチを適用します。
1. スーパーユーザーで Solaris 9 マシンにログインします。
  % su password:password
2. Solaris 9 マシンをシングルユーザーモードで再起動します。
  # reboot -- -s
3. シングルユーザーモードでパッチディレクトリに移動します。
  # cd /patch
4. パッチをインストールします。
  # patchadd -M . 117171-17 # patchadd -M . 117175-02 # patchadd -M . 113318–20
  ヒント –
  マルチユーザーモードに戻るには、Control+D キーを押します。

管理サーバーにコピーしたディストリビューションにパッチを適用します。
1. スーパーユーザーで Solaris 9 マシンにログインします。
  % su password:password
2. 管理サーバーをマウントします。
  # mount -o rw management-server-IP:/js/DISTRO_ID /mnt
3. 次のいずれかの操作を行いパッチをインストールします。
  - Solaris OS x86 ソフトウェアディストリビューションにパッチを適用する場合は、次のコマンドを入力します。
    # patchadd -C /mnt/Solaris_9/Tools/Boot/ -M /patch 117172-17 # patchadd -C /mnt/Solaris_9/Tools/Boot/ -M /patch 117468-02
  - Solaris OS SPARC ソフトウェアディストリビューションにパッチを適用する場合は、次のコマンドを入力します。
    # patchadd -C /mnt/Solaris_9/Tools/Boot/ -M /patch 117171-17 # patchadd -C /mnt/Solaris_9/Tools/Boot/ -M /patch 117175-02 # patchadd -C /mnt/Solaris_9/Tools/Boot/ -M /patch 113318-20
    注 –
    最初のパッチのインストールでは、部分エラーが発生します。このエラーは無視してください。
4. 管理サーバーをマウント解除します。
  # unmount /mnt

管理サーバーで NFS を再起動します。
1. /etc/exports ファイルを編集します。
  # vi /etc/exports
2. /js *(rw,no_root_squash) を /js *(ro,no_root_squash) に変更します。
3. NFS を再起動します。
  # /etc/init.d/nfs restart
  NFS が再起動します。
  
  これで、Solaris 9 OS SPARC ディストリビューションを対象のサーバーに配備する準備ができました。

Solaris 9 OS x86 ディストリビューションを修正します。
1. /js/<distro_id>/Solaris_9/Tools/Boot/boot/solaris に移動します。
  # cd /js/<distro_id>/Solaris_9/Tools/Boot/boot/solaris
2. bootenv.rc リンクを作成し直します。
  # ln -s ../../tmp/root/boot/solaris/bootenv.rc .
  これで、Solaris 9 OS x86 ディストリビューションを対象のサーバーに配備する準備ができました。

注意事項

OS プロファイルの配備失敗

『Sun N1 System Manager 1.2 サイト計画の手引き』の第 2 章「Sun N1 System Manager システムとネットワークの準備」では、OS プロビジョニングネットワークを分離することが推奨されています。おもな理由は、ネットワーク上で DHCP が使用されることと、プロビジョニング動作で大きな帯域幅が使用されることです。

DHCP はブロードキャストプロトコルであるため、DHCP サーバー間でネットワークの衝突が発生する可能性があります。プロビジョニングネットワークでは、OS 監視も実行されます。大規模な構成では、OS 監視によって大量のネットワーク帯域幅が使用されることがあります。

管理ネットワークでは、ハードウェア監視および管理機能を運用することも推奨します。ただし、業務上のニーズからネットワークを均一なものとする必要があり、DHCP と上記の帯域幅に関する事項に対応するようネットワークを設定できる場合は、サイトでネットワークを分離する必要はありません。

次のいずれかの状態では、OS プロファイル配備できないか、配備を完了できません。

Sun Fire V40z または SPARC V440 サーバーに適したパーティションの変更が行われていない。「Sun Fire V40z または SPARC v440 サーバー用にデフォルトの Solaris OS プロファイルを変更する」を参照してください。
Sun Fire V20z サーバー上で、Ethernet インタフェースを認識するのに必要なドライバをインストールするようにスクリプトが変更されていない。「Sun Fire V20z サーバー (K2.0 マザーボード) 用に Solaris 9 OS プロファイルを変更する」を参照してください。
DHCP が正しく構成されていない。「Solaris の配備ジョブのタイムアウトまたは停止」を参照してください。
OS プロファイルが、コアシステムサポートディストリビューショングループのみをインストールする。「Solaris OS プロファイルのインストールの失敗」を参照してください。
対象のサーバーが DHCP 情報にアクセスできないか、またはディストリビューションのディレクトリをマウントできない。「無効な管理サーバーネットマスク」を参照してください。
管理サーバーが、「OS のロード」操作中にファイルにアクセスできない。「Boot Failed エラーの解決のための NFS の再起動」を参照してください。
Linux の配備が停止している。「Linux の配備の停止」を参照してください。
Red Hat の配備に失敗している。「Red Hat OS プロファイルの配備の失敗」を参照してください。

障害の解決のために、次の図を使用してください。この図は、プロビジョニング操作を開始する際に行う手順を示しています。この手順を行うことによって効率的に配備の問題を解決できます。

Sun Fire V40z または SPARC v440 サーバー用にデフォルトの Solaris OS プロファイルを変更する

ここでは、デフォルトで作成されている Solaris OS プロファイルを変更する手順を説明しています。Sun Fire V40z または SPARC v440 サーバーにデフォルトの Solaris OS プロファイルを正しくインストールするには、次の変更が必要です。

手順

N1 System Manager にログインします。

詳細は、「N1 System Manager のコマンド行にアクセスする」を参照してください。

デフォルトプロファイルのコピーを作成します。
N1-ok> create osprofile sol10v40z clone sol10

ルートパーティションを削除します。
N1-ok> remove osprofile sol10v40z partition /

スワップパーティションを削除します。
N1-ok> remove osprofile sol10v40z partition swap

新しいルートパーティションを追加します。

N1-ok> add osprofile sol10v40z partition / device c1t0d0s0 sizeoption free\
 type ufs

新しいスワップパーティションを追加します。

N1-ok> add osprofile sol10v40z partition swap device c1t0d0s1 size 2000\
 type swap sizeoption fixed

参照

変更した OS プロファイルのロード方法については、「サーバーまたはサーバーグループに OS プロファイルをロードする」を参照してください。

Sun Fire V20z サーバー (K2.0 マザーボード) 用に Solaris 9 OS プロファイルを変更する

ここでは、スクリプトを作成して Solaris OS プロファイルに追加する方法を説明します。このスクリプトは、K2.0 マザーボードを持つ Sun Fire V20z サーバー上の Ethernet インタフェースを Solaris 9 x86 で認識するために必要な、Broadcom 5704 NIC ドライバをインストールします。Sun Fire V20z サーバーの初期バージョンでは、K1.0 マザーボードが使用されています。最近のバージョンでは、K2.0 マザーボードが使用されています。

注 –

このパッチは、K2.0 マザーボードに必要なものですが、K1.0 マザーボードに対して使用しても悪影響はありません。

手順

N1 System Manager にログインします。

詳細は、「N1 System Manager のコマンド行にアクセスする」を参照してください。

次のコマンドを入力します。
% /opt/sun/n1gc/bin/n1sh show os
使用可能な OS ディストリビューションの一覧が表示されます。

Solaris 9 ディストリビューションの ID を書き留めておきます。

次のステップで、この ID (実際には DISTRO_ID) を使用します。

次のコマンドを入力します。
# mkdir /js/DISTRO_ID/patch
ここで、distro_id は前のステップで書き留めた ID です。Solaris 9 ディストリビューション用にパッチディレクトリが作成されます。

http://sunsolve.sun.com から /js/DISTRO_ID/patch ディレクトリにパッチ 116666-04 をダウンロードします。

/js/DISTRO_ID/patch ディレクトリに移動します。
# cd /js/DISTRO_ID/patch

パッチファイルを展開します。
# unzip 116666-04.zip

次のコマンドを入力します。
# mkdir /js/scripts

/js/scripts ディレクトリに、次の 3 行を含む patch_sol9_k2.sh という名前のスクリプトを作成します。
#!/bin/sh echo "Adding patch for bge devices." patchadd -R /a -M /cdrom/patch 116666-04
注 –
スクリプトが実行可能ファイルであることを確認します。chmod 775 patch_sol9_k2.sh コマンドを使用します。

Solaris 9 OS プロファイルにスクリプトを追加します。

N1-ok> add osprofile osprofile script /js/scripts/patch_sol9_k2.sh type post

例 6–1 Solaris OS プロファイルへのスクリプトの追加

この例は、OS プロファイルにスクリプトを追加する方法を示しています。type 属性には、スクリプトをインストールのあとで実行することが指定されています。

N1-ok> add osprofile sol9K2 script /js/scripts/patch_sol9_k2.sh\ 
type post

次の手順

変更した Solaris OS プロファイルをロードするには、「サーバーまたはサーバーグループに OS プロファイルをロードする」を参照してください。

Solaris の配備ジョブのタイムアウトまたは停止

Solaris OS プロファイルをロードしようとして、「OS の配備」ジョブがタイムアウトまたは停止した場合は、ジョブの詳細で出力をチェックして対象のサーバーの PXE ブートが完了していることを確認します。次に例を示します。

PXE-M0F: Exiting Broadcom PXE ROM.
      Broadcom UNDI PXE-2.1 v7.5.14
     Copyright (C) 2000-2004 Broadcom Corporation
     Copyright (C) 1997-2000 Intel Corporation
     All rights reserved.      
CLIENT MAC ADDR: 00 09 3D 00 A5 FC  GUID: 68D3BE2E 6D5D 11D8 BA9A 0060B0B36963
     DHCP.

PXE ブートに失敗している場合は、N1 System Manager による管理サーバーの /etc/dhcpd.conf ファイルの設定が正しくありません。

注 –

最良の診断方法は、対象のマシンのコンソールウィンドウを開き、配備を実行することです。「サーバーのシリアルコンソールを開く」を参照してください。

/etc/dhcpd.conf ファイルが正しく設定されていないことが疑われる場合は、次の手順で設定を変更してください。

ネットワークインタフェース構成を変更する

手順

root として管理サーバーにログインします。

dhcpd.conf のエラーを調べます。
# vi /etc/dhcpd.conf

エラーがある場合は修正する必要があります。次のコマンドを実行します。
# /usr/bin/n1smconfig
n1smconfig ユーティリティーが表示されます。

プロビジョニングネットワークインタフェースの構成を変更します。

詳細は、『Sun N1 System Manager 1.2 インストールおよび構成ガイド』の「N1 System Manager システムの設定」を参照してください。

対象のサーバーで OS プロファルをロードします。

Solaris OS プロファイルのインストールの失敗

コアシステムサポートディストリビューショングループのみをインストールする OS プロファイルは、正常にロードできません。distributiongroup パラメータの値として “Entire Distribution plus OEM Support” を指定してください。これによって、必要な SSH のバージョン、および N1 System Manager によって管理するサーバーに必要なそのほかのツールをインストールするようにプロファイルを構成します。

無効な管理サーバーネットマスク

Solaris 10 の配備中に、対象のサーバーが DHCP 情報にアクセスできない、または管理サーバーのディストリビューションディレクトリをマウントできない場合は、無効なネットマスクによってネットワークに問題があることが考えられます。コンソールに、次に類似する出力がみられます。

Booting kernel/unix...
  krtld: Unused kernel arguments: `install'.
  SunOS? Release 5.10 Version Generic 32-bit
  Copyright 1983-2005 Sun Microsystems, Inc.  All rights reserved.
  Use is subject to license terms.
  Unsupported Tavor FW version: expected: 0003.0001.0000, actual: 0002.0000.0000
  NOTICE: tavor0: driver attached (for maintenance mode only)
  Configuring devices.
  Using DHCP for network configuration information.
  Beginning system identification...
  Searching for configuration file(s)...
  Using sysid configuration file /sysidcfg
  Search complete.
  Discovering additional network configuration...
  Completing system identification...
  Starting remote procedure call (RPC) services: done.
  System identification complete.
  Starting Solaris installation program...
  Searching for JumpStart directory...
  /sbin/dhcpinfo: primary interface requested but no primary interface is set
  not found
  Warning: Could not find matching rule in rules.ok
  Press the return key for an interactive Solaris install program...

この問題を解決するには、管理サーバーのネットマスク値を 255.255.255.0 に設定します。『Sun N1 System Manager 1.2 インストールおよび構成ガイド』の「N1 System Manager システムを設定する」を参照してください。

Linux の配備の停止

Linux OS を配備していて、配備が停止する場合は、対象のサーバーのコンソールをチェックしてインストーラが双方向モードになっているかどうかを確認します。インストーラが双方向モードになっている場合は、管理サーバーから対象のサーバーへのデータ送信の遅延が原因で、配備がタイムアウトしています。この遅延は、通常、2 つのマシンを接続しているスイッチ (複数の場合もある) のスパニングツリーが有効になっているために起こります。スイッチのスパニングツリーをオフにするか、管理サーバーに接続されているポートと対象サーバーに接続されているポートのスパニングツリーを無効にしてください。

スパニングツリーがすでに無効になっていて OS の配備が停止する場合は、ネットワークに問題があると考えられます。

注 –

一部のネットワーク設定で Red Hat をインストールするには、スパニングツリーを有効にする必要があります。

Red Hat OS プロファイルの配備の失敗

N1 System Manager で Red Hat OS プロファイルを構築するには、さらなる分析を行わないと失敗することがあります。カスタム OS プロファイルで問題がある場合は、問題の配備が有効な状態のまま、次の手順を実行します。

root として管理サーバーにログインします。

次のスクリプトを実行します。

# cat /var/opt/sun/scs/share/allstart/config/ks*cfg > failed_ks_cfg

failed_ks_cfg ファイルには、カスタマイズしたものを含めてすべての KickStart パラメータが格納されます。設定ファイルで設定したパラメータが、現在のハードウェア構成に合ったものになっていることを確認します。誤りを修正し、配備を再実行します。

V20z または V40z の OS 配備が「`internal error`」メッセージで失敗

V20z または V40z の OS 配備が失敗し、ジョブ結果に「internal error occurred」メッセージが表示される場合は、プラットフォームのコンソール出力をサービスプロセッサに出力してください。プラットフォームのコンソール出力を簡単にサービスプロセッサに出力できない場合は、サービスプロセッサを再起動します。サービスプロセッサを再起動するには、サービスプロセッサにログオンし、sp reboot コマンドを実行します。

コンソール出力を調べるには、サービスプロセッサにログオンし、 platform console コマンドを実行します。OS 配備中の出力を確認し、問題を解決してください。

`Boot Failed` エラーの解決のための NFS の再起動

Error: boot: lookup /js/4/Solaris_10/Tools/Boot failed boot: cannot open kernel/sparcv9/unix

対処方法:

このメッセージは、配備している OS によって異なります。「OS のロード」の操作中に、管理サーバーがファイルにアクセスできない場合は、ネットワークに問題があると考えられます。この問題を修正する 1 つの方法として、NFS を再起動することがあげられます。

Solaris システムでは、次のように入力します。

# /etc/init.d/nfs.server stop
# /etc/init.d/nfs.server start

Linux システムでは、次のように入力します。

# /etc/init.d/nfs restart

OS 監視に関連するコマンドの失敗の解決

管理サーバーの古い SSH エントリが原因で、機能の追加に失敗することがあります。add server server-name feature osmonitor agentip コマンドが失敗し、セキュリティー違反がないことが確かな場合は、/root/.ssh/known_hosts ファイル、またはプロビジョニング可能なサーバーに対応するファイル内のエントリを削除します。そのあとで add コマンドを再度実行します。

さらに、基本管理機能を持つサーバーへの OS 監視機能の追加に失敗することがあります。ジョブの出力に次のようなエラーが表示されます。

Repeat attempts for this operation are not allowed.

このエラーは、SSH 資格が以前に提供されていて変更できないことを示しています。このエラーを回避するには、add server feature osmonitor コマンドに agentssh 資格をつけないで実行してください。手順については、「OS 監視機能を追加する」を参照してください。

N1-ok> show job 61
ジョブ ID:　　   61
日時:　　　      2005-08-16T16:14:27-0400
種類:　　　      Modify OS Monitoring Support
ステータス:      Error (2005-08-16T16:14:38-0400)
コマンド:　      add server 192.168.2.10 feature osmonitor agentssh root/rootpasswd
所有者:　　      root
エラー:　　      1
警告:　　　      0

ステップ
ID    種類　　　　　    開始                        Completion                  結果
1     ホスト取得　　    2005-08-16T16:14:27-0400　　2005-08-16T16:14:28-0400    完了
2     コマンドの実行    2005-08-16T16:14:28-0400　　2005-08-16T16:14:28-0400    完了
3     ホスト取得　　    2005-08-16T16:14:29-0400　　2005-08-16T16:14:30-0400    完了
4     コマンドの実行    2005-08-16T16:14:30-0400　　2005-08-16T16:14:36-0400    エラー

結果
結果 1:
サーバー:　      192.168.2.10
ステータス:      -3
メッセージ:      Repeate attempts for this operation are not allowed.

OS 監視エージェントの確認

「OS 監視機能を追加する」の説明に従って OS 監視エージェントをインストールしても、OS 監視データが表示されない場合は、OS 監視機能がインストールされたことを、次のようにして確認してください。

OS 監視データが完全に初期化されるまで、5 〜 7 分かかります。CPU アイドルが 0.0% と表示されていると、OS 使用の Failed Critical を引き起こします。OS 監視機能の追加またはアップグレード後、5 〜 7 分以内に、この状態が解消されるはずです。その時点で、show server server コマンドを使用すると、プロビジョニング可能なサーバーから OS 監視データを使用できるようになります。

grep コマンドを使用し、エージェント自身が正常にインストールされたかどうかを調べてください。

Solaris の機能を確認する場合は、次のコマンドを入力します。

# pkginfo |grep n1sm 

sparc:   SUNWn1smsparcag-1-2
solx86:  SUNWn1smx86ag-1-2
# ps -ef |grep -i esd
root 23817     1  0 19:57:59 ?       0:01 esd - init agent -dir
 /var/opt/SUNWsymon -q

Linux の機能を確認する場合は、次のコマンドを入力します。

# rpm -qa | grep n1sm-linux-agent

 # ps -ef | grep -i esd
 root 1940 1 0 Jan28 ? 00:00:14 esd - init agent -dir
 /var/opt/SUNWsymon -q

OS アップデートの問題

ここでは、次の障害について、考えられる解決方法について説明しています。

OS アップデートの作成の失敗

新しい OS アップデートを作成する場合に指定する名前は、一意である必要があります。同様に、作成される OS アップデートも 1 つしか存在しないものである必要があります。すなわち、各 OS アップデートのファイル名に加えて、内部パッケージ名、バージョン、リリース、ファイル名の組み合わせも同じく一意である必要があります。

たとえば、test1.rpm が test1 という名前の RPM のソースである場合、test2 という名前の別の OS アップデートを、test1.rpm という同じファイル名にすることができません。名前に関する問題を回避するために、OS アップデートの名前は、プロビジョニング可能なサーバーの別の既存のパッケージの内部パッケージ名と同じ名前にしないようにしてください。

OS アップデートを作成する場合は、admin ファイルの値を指定できます。Solaris OS アップデートパッケージでは、デフォルトの admin ファイルは /opt/sun/n1gc/etc/admin にあります。

mail=
   instance=unique
   partial=nocheck
   runlevel=nocheck
   idepend=nocheck
   rdepend=nocheck
   space=quit
   setuid=nocheck
   conflict=nocheck
   action=nocheck
   basedir=default
   authentication=nocheck

adminfile を使用して OS アップデートをインストールする場合は、パッケージのファイル名がパッケージの名前と一致していることを確認してください。ファイル名がパッケージ名と一致しない状態で adminfile を使用して OS アップデートをインストールすると、アンインストールできなくなります。「OS アップデートのアンインストールの失敗」を参照してください。

N1 System Manager で Solaris パッケージの配備に使用されるデフォルトの admin ファイルの設定は、instance=unique です。パッケージの重複でエラーを報告させる場合は、admin ファイルの設定を instance=quit に変更します。このように変更すると、重複したパッケージが検出された場合に、「アップデートのロード」ジョブの結果にエラーが表示されるようになります。

admin ファイルのパラメータ設定の詳細は、admin(4) のマニュアルページを参照してください。Solaris システムで、root ユーザーとして man -s4 admin と入力すると、マニュアルページを表示できます。

Solaris パッケージには、応答ファイルが必要な場合もあります。OS アップデートを作成するときに、admin ファイルおよび response ファイルを指定する方法については、「OS アップデートをコピーする」を参照してください。

Solaris OS アップデートの配備の失敗

ここでは、Solaris OS アップデートを配備するときの、次の問題に関する考えられる解決方法について説明します。

ジョブを送信する前に発生するエラー
「アップデートのロード」ジョブのエラー
「アップデートのアンロード」ジョブのエラー
「アップデートのロード」の「停止」ジョブのエラー

次の unload コマンドでは、update は、show update all コマンドを入力して表示される一覧の update の名前、または対象のサーバー上にある実際のパッケージ名のいずれかです。

N1-ok> load server server update update

常に、パッケージが正しいアーキテクチャーに対して指定されているかどうかを確認してください。

注 –

N1 System Manager は、Solaris OS (x86 または SPARC) の 32 ビットと 64 ビットを区別しません。したがって、パッケージまたはパッチが対応していない OS にインストールされた場合は、インストールに失敗する場合があります。

パッケージまたはパッチが正常にインストールされた場合でも、パフォーマンスが低下した場合は、パッチのアーキテクチャーと OS のアーキテクチャーが合致していることを確認してください。

次に、ジョブが送信される前に発生する可能性がある一般的なエラーを示します。

Target server is not initialized

対処方法:

add server feature osmonitor コマンドが実行され、それが成功していることを確認します。

Another running job on the target server

対処方法:

サーバーで同時に実行できるジョブは 1 つだけです。ジョブが完了したあとで再度実行します。

Update is incompatible with operating system on target server

対処方法:

対象のサーバーの OS の種類が、アップデートの OS の種類に合致していることを確認します。 N1–ok> プロンプトで show update update-name と入力し、アップデートの OS の種類を表示できます。

Target server is not in a good state or is powered off

対処方法:

対象のサーバーが起動され、稼動中であることを確認します。N1–ok> プロンプトで show server server-name と入力すると、サーバーのステータスを表示できます。reset server server-name force と入力すると強制的に再起動することができます。

「アップデートのロード」ジョブが失敗する原因として、次のことが考えられます。

「アップデートのロード」ジョブは、同じパッケージがすでに存在するため、またはより新しいバージョンのパッケージが存在するために、失敗することがあります。ジョブが失敗した場合は、対象のサーバーにそのパッケージが存在しないことを確認してください。

error: Failed dependencies:

A prerequisite package and should be installed.

対処方法:

Solaris システムでは、admin ファイルの idepend= パラメータを設定します。

Preinstall or postinstall scripts failure: Non-zero status

pkgadd: ERROR: ... script did not complete successfully

対処方法:

インストール前スクリプトまたはインストール後処理スクリプトの考えられるエラーを確認し、このエラーを解決します。

Interactive request script supplied by package

対処方法:

このメッセージは、response ファイルがない、または admin ファイルの設定が正しくないことを示しています。response ファイルを追加して、このエラーを修正します。

patch-name was installed without backing up the original files

対処方法:

このメッセージは、Solaris OS アップデートがインストールされたときに元のファイルのバックアップを取らなかったことを示しています。対処の必要はありません。

Insufficient diskspace

対処方法:

ディスク領域が十分でないために「アップデートのロード」に失敗する可能性があります。df -k と入力して空き容量をチェックします。また、パッケージの容量も確認します。パッケージの容量が大きすぎる場合は、対象のサーバーの使用可能な領域を増やします。

次に、アップデートのロードまたはアンロード操作で発生する停止ジョブのエラーを示します。

「アップデートのロード」または「アップデートのアンロード」ジョブの停止操作を行なってもジョブが停止されない場合は、管理サーバーで、次のプロセスが終了されているかを手動で確認します。

# ps -ef |grep swi_pkg_pusher
ps -ef |grep pkgadd, pkgrm, scp, ...

プロビジョニング可能なサーバーで実行中のすべてのプロセスをチェックします。

# ps -ef |grep pkgadd, pkgrm, ...

「サーバーのアンロード」および「グループのアンロード」ジョブの一般的なエラーを次に示します。

この項の以降では、次のコマンドに関係する問題のエラーおよび考えられる解決策を示します。unload server server-name update update-name および unload group group-name update update-name。

Removal of <SUNWssmu> was suspended (interaction required)

対処方法:

このメッセージは、Solaris パッケージのアンインストールにおける依存関係の問題を示しています。admin ファイルの設定をチェックし、適切な response ファイルを提供してください。

Job step failure without error details

対処方法:

このメッセージは、ジョブが内部で開始できなかったことを示す可能性があります。詳細情報を得るには、Sun のサービス担当者に連絡してください。

Job step failure with vague error details: Connection to 10.0.0.xx

対処方法:

このメッセージは、一部のパッケージが完全にインストールされていなかったためにアンインストールに失敗したことを示す可能性があります。この場合は、対象のサーバーで問題のパッケージを手動でインストールします。次に例を示します。

.pkg ファイルを手動でインストールするには、次のコマンドを入力します。

# pkgadd -d pkg-name -a admin-file

パッチを手動でインストールするには、次のコマンドを入力します。

# patchadd -d patch-name -a admin-file

このあとで、unload コマンドを再度実行してください。

Job hangs

対処方法:

ジョブがハングアップしたら、ジョブを停止し、残りのプロセスを手動で終了してください。次に例を示します。

ジョブを手動で終了するには、次のコマンドを入力します。

# n1sh stop job job-ID

次に、PKG の PID を検索してプロセスを終了します。次のコマンドを入力します。

# ps -ef |grep pkgadd
# pkill pkgadd-PID

このあとで、unload コマンドを再度実行してください。

Linux OS アップデートの配備の失敗

ここでは、Linux OS アップデートを配備するときの、次の問題に関する考えられる解決方法について説明します。

ジョブを送信する前に発生するエラー
「アップデートのロード」ジョブのエラー
「アップデートのアンロード」ジョブのエラー
「アップデートのロード」の「停止」ジョブのエラー

N1-ok> load server server update update

次に、ジョブが送信される前に発生する可能性がある一般的なエラーを示します。

Target server is not initialized

対処方法:

add server feature osmonitor コマンドが実行され、それが成功していることを確認します。

Another running job on the target server

対処方法:

サーバーで同時に実行できるジョブは 1 つだけです。ジョブが完了したあとで再度実行します。

Update is incompatible with operating system on target server

対処方法:

Target server is not in a good state or is powered off

対処方法:

「アップデートのロード」ジョブが失敗する原因として、次のことが考えられます。

error: Failed dependencies:

A prerequisite package should be installed

対処方法:

Linux RPM の依存関係を調べ、解決するために RPM ツールを使用します。

Preinstall or postinstall scripts failure: Non-zero status

ERROR: ... script did not complete successfully

対処方法:

インストール前スクリプトまたはインストール後処理スクリプトの考えられるエラーを確認し、このエラーを解決します。

Insufficient diskspace

対処方法:

次に、アップデートのロードまたはアンロード操作で発生する停止ジョブのエラーを示します。

# ps -ef |grep swi_pkg_pusher
ps -ef |grep rpm

プロビジョニング可能なサーバーで実行中のすべてのプロセスをチェックします。

# ps -ef |grep rpm, ...

「サーバーのアンロード」および「グループのアンロード」ジョブの一般的なエラーを次に示します。

Job step failure without error details

対処方法:

Job step failure with vague error details: Connection to 10.0.0.xx

対処方法:

このメッセージは、RPM の一部が完全にインストールされていなかったためにアンインストールに失敗したことを示す可能性があります。この場合は、対象のサーバーで問題のパッケージを手動でインストールします。次に例を示します。

RPM を手動でインストールするには、次のコマンドを入力します。

# rpm -Uvh rpm-name

このあとで、unload コマンドを再度実行してください。

Job hangs

対処方法:

ジョブがハングアップしたら、ジョブを停止し、残りのプロセスを手動で終了してください。次に例を示します。

ジョブを手動で終了するには、次のコマンドを入力します。

# n1sh stop job job-ID

次に、RPM の PID を検索してプロセスを終了します。次のコマンドを入力します。

# ps -ef |grep rpm-name
# pkill rpm-PID

このあとで、unload コマンドを再度実行してください。

OS アップデートのアンインストールの失敗

adminfile でインストールされた OS アップデートをアンインストールできない場合は、パッケージファイル名がパッケージの名前と一致しているかどうか確認してください。パッケージ名を調べるには、次のようにします。

bash-2.05# ls FOOi386pkg 
   FOOi386pkg
   bash-2.05# pkginfo -d ./FOOi386pkg 
   application FOOi386pkg     FOO Package for Testing
   bash-2.05# pkginfo -d ./FOOi386pkg | /usr/bin/awk '{print $2}'
   FOOi386pkg
---
   bash-2.05# cp FOOi386pkg Foopackage
   bash-2.05# pkginfo -d ./Foopackage 
   application FOOi386pkg     FOO Package for Testing
   bash-2.05# pkginfo -d ./Foopackage | /usr/bin/awk '{print $2}'
   FOOi386pkg
   bash-2.05#

名前が異なる場合は、プロビジョニング対象サーバーの /tmp ディレクトリにある adminfile の名前をパッケージと一致するよう変更し、unload コマンドを再実行してみてください。それでもパッケージがアンインストールされない場合は、pkgrm を使用してプロビジョニング対象サーバーからパッケージを削除します。

V20z および V40z サーバーのファームウェアアップデートのダウンロード

ここでは、Sun Fire V20z および V40z サーバーの検出に必要なファームウェアヴァージョンをダウンロードして準備するための詳細情報を示します。

Sun Fire V20z および V40z サーバーのファームウェアをダウンロードして準備する

手順

N1 System Manager 管理サーバーに root でログインします。

N1–ok プロンプトが表示されます。

V20z および V40z ファームウェアアップデートの zip ファイルを保存するディレクトリを作成します。

各サーバータイプのファームウェアをダウンロードするために、それぞれ別個のディレクトリを作成します。次に例を示します。
# mkdir V20z-firmware V40z-firmware

Web ブラウザで、http://www.sun.com/servers/entry/v20z/downloads.htmlにアクセスします。

Sun Fire V20z/V40z サーバーのダウンロードのページが表示されます。

「Current Release」をクリックします。

「Sun Fire V20z/V40z NSV Bundles 2.3.0.11」ページが表示されます。

「Download」をクリックします。

ダウンロードの「Welcome」ページが表示されます。ユーザー名とパスワードを入力して「Login」をクリックします。

「Terms of Use」ページが表示されます。ライセンス契約をよく読みます。ファームウェアをダウンロードするには、ライセンスの規約に同意する必要があります。「Accept」をクリックしたあとで、「Continue」をクリックします。

「Download」ページが表示されます。ダウンロード可能なファイルの一覧が表示されます。

V20z ファームウェアの zip ファイルをダウンロードするには、「V20z BIOS and SP Firmware, English (nsv-v20z-bios-fw_V2_3_0_11.zip)」をクリックします。

手順 2 で作成した V20z のファームウェア用のディレクトリに 10.21M バイトのファイルを保存します。

V40z ファームウェアの zip ファイルをダウンロードするには、「V40z BIOS and SP Firmware, English (nsv-v40z-bios-fw_V2_3_0_11.zip)」をクリックします。

手順 2 で作成した V40z のファームウェア用のディレクトリに 10.22M バイトのファイルを保存します。

V20z ファームウェアのファイルをダウンロードしたディレクトリに移動します。
1. unzip と入力してファイルを展開します。
  
  y と入力して操作を続けます。
  
  sw_images ディレクトリが抽出されます。
  
  sw_images ディレクトリにある次のファイルは、N1 System Manager によって V20z のプロビジョニング可能なサーバーのファームウェアを更新するために使用されます。
  - サービスプロセッサ
    
    sw_images/sp/spbase/V2.3.0.11/install.image
  - BIOS
    
    sw_images/platform/firmware/bios/ V2.33.5.2/bios.sp

V40z ファームウェアの zip ファイルをダウンロードしたディレクトリに移動します。
1. unzip nsv-v40z-bios-fw_V2_3_0_11.zip と入力し、zip ファイルを展開します。
  
  sw_images ディレクトリが抽出されます。
  
  sw_images ディレクトリにある次のファイルは、N1 System Manager によって V40z のプロビジョニング可能なサーバーのファームウェアを更新するために使用されます。
  - サービスプロセッサ
    
    sw_images/sp/spbase/V2.3.0.11/install.image
  - BIOS
    
    sw_images/platform/firmware/bios/V2.33.5.2/bios.sp

次の手順

N1 System Manager にファームウェアアップデートをコピーします。説明は、「ファームウェアアップデートをコピーする」にあります。
単一のサーバーまたはサーバーグループのプロビジョニング可能なサーバーでファームウェアをアップデートします。説明は、「サーバーまたはサーバーグループにファームウェアアップデートをロードする」にあります。

ALOM 1.5 のファームウェアアップデートのダウンロード

ここでは、ALOM 1.5 を使用する Sun サーバーの検出に必要なファームウェアバージョンをダウンロードして準備するための詳細情報を示します。

ALOM 1.5 のファームウェアをダウンロードして準備する

手順

N1 System Manager 管理サーバーに root でログインします。

N1–ok プロンプトが表示されます。

ALOM のファームウェアアップデートの zip ファイルを保存するディレクトリを作成します。

各サーバータイプのファームウェアをダウンロードするために、それぞれ別個のディレクトリを作成します。次に例を示します。
# mkdir ALOM-firmware

Web ブラウザで、http://jsecom16.sun.com/ECom/EComActionServlet?StoreId=8 にアクセスします。

ダウンロードのページが表示されます。

ALOM 1.5 ファームウェアの zip ファイルをダウンロードするには、ログインし、「ALOM 1.5」、「All Platforms/SPARC」、「English」、「Download」の順に進みます。

手順 2 で作成した ALOM ファームウェア用のディレクトリにファイルをダウンロードします。

ALOM のファームウェアファイルをダウンロードしたディレクトリに移動し、tar ファイルを展開します。

bash-3.00# tar xvf ALOM_1.5.3_fw.tar
x README, 9186 bytes, 18 tape blocks
x copyright, 93 bytes, 1 tape blocks
x alombootfw, 161807 bytes, 317 tape blocks
x alommainfw, 5015567 bytes, 9797 tape blocks

ファイルが抽出されます。

次の手順

N1 System Manager にファームウェアアップデートをコピーします。説明は、「ファームウェアアップデートをコピーする」にあります。
単一のサーバーまたはサーバーグループのプロビジョニング可能なサーバーでファームウェアをアップデートします。説明は、「サーバーまたはサーバーグループにファームウェアアップデートをロードする」にあります。

しきい値違反の処理

監視対象属性のしきい値が破られると、イベントが生成されます。通知規則を作成して、この種のイベントに関して警告を発行させることができます。しきい値違反または警告の通知は、イベントログを使って行われます。このログは、ブラウザインタフェースで簡単に見ることができます。

create notification コマンドを使って通知を作成し、電子メールで送信するか、ポケットベルに送信することができます。構文の詳細は、『Sun N1 System Manager 1.2 コマンド行レファレンスマニュアル』の「create notification」を参照してください。

ハードウェアおよび OS しきい値違反の確認

監視対象のハードウェア健全性属性または OS リソース使用属性の値がしきい値を破った場合は、イベントログがただちに作成されてそのことが示されます。イベントログはブラウザインタフェースからアクセスできます。「サーバーのしきい値を取得する」の図に示すように、ブラウザインタフェースの監視対象データテーブルに記号が表示され、しきい値が破られたことが示されます。

または、show log コマンドを使用して、イベントログが作成されたことを確認します。

N1-ok> show log
Id            日時                       重要度    件名                  メッセージ
.
. 
10            2005-11-22T01:45:02-0800   警告　    Sun_V20z_XG041105786
A critical high threshold was violated for server Sun_V20z_XG041105786: Attribute cpu0.vtt-s3 Value 1.32

13            2005-11-22T01:50:08-0800   警告　    Sun_V20z_XG041105786
A normal low  threshold was violated for server Sun_V20z_XG041105786: Attribute cpu0.vtt-s3 Value 1.2

監視トラップが失われると、特定のしきい値ステータスは最大 30 時間は更新されませんが、総合的なステータスは 10 分ごとに更新されます。

監視障害の確認

「監視の有効化と無効化」で説明しているように監視が有効で、show server または show group コマンドの出力にステータスとして「不明」か「アクセス不能」が示された場合、監視対象のそのサーバーまたはサーバーグループは正常に到達されていません。ステータスが「不明」または「アクセス不能」のままである時間が 30 分以内である場合は、一時的なネットワークの問題が発生している可能性があります。これに対し、ステータスが「 不明」または「アクセス不能」のままの時間が 10 分以上の場合は、監視に問題が発生している可能性があります。監視機能の障害が原因である可能性があります。詳細は、「OS 監視に関連するコマンドの失敗の解決」を参照してください。

監視トラップが失われると、特定のしきい値ステータスは最大 30 時間は更新されませんが、総合的なステータスは 10 分ごとに更新されます。

監視データ出力には、タイムスタンプが示されます。このタイムスタンプと現在の時刻の関係を基に、監視エージェントに問題があるかどうかを判定することもできます。

サービスの再起動後または再開後の問題

管理サーバーを再起動したときに N1 System Manager サービスが再開されない場合は、セキュリティーキーを再生成する必要があります。説明は、「セキュリティーキーを再生成する理由」にあります。

n1sminit stop コマンドを使用して N1 System Manager を停止したときに、n1sminit start コマンドを使用してもサービスが再開されない場合は、セキュリティーキーを再生成する必要があります。説明は、「セキュリティーキーを再生成する理由」にあります。

再起動後にプロビジョニング対象サーバーの管理機能を使用できない

load server または load group コマンドを使用してプロビジョニング可能なサーバーにソフトウェアをインストールした場合は、プロビジョニング可能なサーバーの networktype 属性を dhcp に設定できます。この設定では、サーバーが DHCP を使用してプロビジョニングネットワークの IP アドレスを取得します。システムが再起動し、load コマンドまたは add server コマンドで agentip パラメータに指定したものとは異なる IP アドレスを取得した場合、次の機能が動作しなくなります。

show server コマンドの「OS の監視」の内容(OS 監視なし)。
load server server update および load group group update コマンド
start server server command コマンド
set server server threshold コマンド
set server server refresh コマンド

この場合は、set server server agentip コマンドを使用し、この手順で示したようにサーバーのエージェント IP アドレスを修正します。詳細は、「サーバーのエージェント IP を変更する」を参照してください。

ALOM によるサーバーからの通知の修正

プロビジョニング可能なサーバーの一部のモデルのポートでは、ALOM (Advanced Lights Out Manager) 規格が使用されています。これらのサーバーでは、SNMP トラップではなく電子メールを使用して、管理サーバーにハードウェアイベントに関する通知を送信します。説明は、『Sun N1 System Manager 1.2 サイト計画の手引き』の「プロビジョニング可能なサーバーの要件」にあります。他のイベントについての詳細は、「イベントログエントリの管理」および「イベント通知の設定」を参照してください。

管理サーバーがこれらのサーバーからイベント通知を受け取るには、管理サーバーを設定するか、N1 System Manager からアクセス可能な他の専用サーバーを、ALOM を使用するプロビジョニング可能なサーバーからのハードウェアイベントに関する通知の受信用電子メールサーバーとして設定します。詳細は、『Sun N1 System Manager 1.2 サイト計画の手引き』の「管理サーバーのメールサービスとアカウントの設定」および『Sun N1 System Manager 1.2 インストールおよび構成ガイド』の「N1 System Manager システムの設定」を参照してください。

ALOM を使用するプロビジョニング可能なサーバーからハードウェアイベントに関する通知がない場合、すべての管理対象サーバーは正常です。ただし、管理サーバー、または N1 System Manager からアクセス可能な他の専用サーバーが電子メールサーバーとして正しく設定されていないか、ネットワークエラーやドメイン名の変更など他の原因によって電子メール設定が無効になった可能性もあります。

電子メールサーバーが設定されている場合、メールアカウントのリセットが必要な場合もあります。プロビジョニング可能なサーバーの電子メールアカウントは削除されている、または破損している可能性があります。あるいは、ドメイン名や管理ネットワーク IP アドレスの変更など、電子メールサーバーの設定に影響のある変更が行われている可能性があります。

管理サーバーで使用される電子メールアドレスをリセットまたは変更するには、次の手順に従います。

ALOM によるプロビジョニング可能なサーバーの電子メールアカウントをリセットする

ここでは、プロビジョニング可能なサーバーの電子メールアカウントをリセットする手順を説明します。この手順によって、管理サーバーで使用されていた電子メールアドレスを、新しいアドレスに入れ替えることができます。

リセットする電子メールアドレスは、N1 System Manager のみで使用するように予約されているものにしてください。

始める前に

この問題は、サーバーの電子メール警告を受信できていないことが原因であることを確認してください。管理サーバーまたは N1 System Manager からアクセス可能な他のサーバーが電子メールサーバーとして正しく設定されていない、またはネットワークエラーやドメイン名の変更など他の原因によって電子メール設定が無効になっている可能性があります。

この手順を実行する前に、Mozilla など別のメールクライアントで同じメールサーバー IP、ユーザー名、およびパスワードを設定して、ALOM サーバーから送信された電子メールを専用電子メールサーバーで受信できることを確認してください。次に、telnet コマンドで ALOM サーバーにアクセスし、resetsc -y コマンドを実行して警告メッセージを生成します。メールクライアントで ALOM 警告メッセージを受信できるかどうかをチェックしてください。受信できた場合は、以下の手順を行う必要はありません。

サーバーの telnet のデフォルトログイン名とパスワードについては、「サーバーの検出」を参照してください。

この手順を実行する前に、telnet コマンドを使用して ALOM サーバーにアクセスし、showsc コマンドを実行して、N1 System Manager が専用電子メールサーバーにアクセスできることも確認してください。パラメータや値が、次のように設定されていることを確認してください。

if_emailalerts 値の設定は true
mgt_mailhost 値の設定は専用メールサーバーの IP アドレス
mgt_mailalert(1) 値の設定は、警告の送信先の電子メールアドレス

これらの設定が表示されない場合、または mgt_mailalert の電子メールアドレスが誤っている場合は、次の手順を行ってください。

手順

N1 System Manager にログインします。

詳細は、「N1 System Manager のコマンド行にアクセスする」を参照してください。

ALOM によるプロビジョニング可能なサーバーの監視をオフにします。

set server コマンドを使用して、monitored 属性を false に設定します。
N1-ok> set server server monitored false
この例で、server は電子メールアカウントをリセットする ALOM によるプロビジョニング可能なサーバーの名前です。このコマンドを実行すると、指定したサーバーの監視が無効になります。
- ALOM によるサーバーが同じグループ内にある場合は、set group コマンドを使用してサーバーグループの監視をオフにします。
  N1-ok> set group group monitored false
  この例で、group は電子メールアカウントをリセットする ALOM によるプロビジョニング可能なサーバーのグループ名です。このコマンドを実行すると、指定したサーバーグループの監視が無効になります。

n1smconfig コマンドに —a オプションを付けて使用し、サーバーの電子メールアドレスを変更します。

ALOM によるサーバーでサポートされる電子メールアドレスの長さは、最大 33 文字です。

注 –
ALOM によるサーバーが他のアドレスにイベント通知を電子メールで送信するよう、telnet コマンドおよび setsc mgt_mailalert コマンドを使用して手動で設定してある場合は、n1smconfig コマンドを実行してもアドレスが変更されません。

ALOM によるプロビジョニング可能なサーバーの監視をオンにします。

set server コマンドを使用し、monitored 属性を true に設定します。
N1-ok> set server server monitored true
- ALOM によるサーバーが同じグループ内にある場合は、set group コマンドを使用してサーバーグループの監視をオンにします。
  N1-ok> set group group monitored true
  この例で、group は電子メールアカウントをリセットする ALOM によるプロビジョニング可能なサーバーのグループ名です。このコマンドを実行すると、指定したサーバーグループの監視が有効になります。

Previous: 第 5 章サーバーの監視

第 6 章 障害追跡

検出の問題

セキュリティーの問題

セキュリティーキーを再生成する理由

共通エージェントコンテナのセキュリティーキーを再生成する

手順

一般的なセキュリティー上の留意点

OS ディストリビューションの障害追跡

ディストリビューションのコピーの失敗

マウントポイントの問題

Solaris 9 ディストリビューションへのパッチの適用

プロビジョニング可能なサーバーの使用による OS ディストリビューションへのパッチ適用

Solaris 9 OS x86 パッチサーバーを使用して Solaris 9 OS ディストリビューションにパッチを適用する

始める前に

手順

注意事項

Solaris 9 OS SPARC パッチサーバーを使用して Solaris 9 OS ディストリビューションにパッチを適用する

始める前に

手順

注意事項

OS プロファイルの配備失敗

Sun Fire V40z または SPARC v440 サーバー用にデフォルトの Solaris OS プロファイルを変更する

手順

参照

Sun Fire V20z サーバー (K2.0 マザーボード) 用に Solaris 9 OS プロファイルを変更する

手順

例 6–1 Solaris OS プロファイルへのスクリプトの追加

次の手順

Solaris の配備ジョブのタイムアウトまたは停止

ネットワークインタフェース構成を変更する

手順

Solaris OS プロファイルのインストールの失敗

無効な管理サーバーネットマスク

Linux の配備の停止

Red Hat OS プロファイルの配備の失敗

V20z または V40z の OS 配備が「internal error」メッセージで失敗

Boot Failed エラーの解決のための NFS の再起動

OS 監視に関連するコマンドの失敗の解決

OS 監視エージェントの確認

OS アップデートの問題

OS アップデートの作成の失敗

Solaris OS アップデートの配備の失敗

Linux OS アップデートの配備の失敗

OS アップデートのアンインストールの失敗

V20z および V40z サーバーのファームウェアアップデートのダウンロード

Sun Fire V20z および V40z サーバーのファームウェアをダウンロードして準備する

手順

次の手順

ALOM 1.5 のファームウェアアップデートのダウンロード

ALOM 1.5 のファームウェアをダウンロードして準備する

手順

次の手順

しきい値違反の処理

ハードウェアおよび OS しきい値違反の確認

監視障害の確認

サービスの再起動後または再開後の問題

再起動後にプロビジョニング対象サーバーの管理機能を使用できない

ALOM によるサーバーからの通知の修正

ALOM によるプロビジョニング可能なサーバーの電子メールアカウントをリセットする

始める前に

手順

第 6 章障害追跡

V20z または V40z の OS 配備が「`internal error`」メッセージで失敗

`Boot Failed` エラーの解決のための NFS の再起動