| Sun Control Station 2.2.1 リリースノート |     |
| Sun Control Station 2.2.1 リリースノート | |
|
このリリースノートは SunTM Control Station 2.2.1 ソフトウェアについて書かれています。インストール、新機能、すでに判明しているシステム制限について、ほかのマニュアルの発行後に明らかにされた重要な情報が記載されています。
パッチは、サンの正規販売店、サービスプロバイダから入手するか、または次の URL の SunSolve Online SM Web サイトからダウンロードできます。
パッチ情報およびインストール手順については、各パッチに付属している「README」ファイルを参照してください。
Sun Control Station 2.2.1 のインストールイメージは、ダウンロードしやすいよう 64M バイト単位ごとに分割されています。それぞれの単位をダウンロードしてから統合して、元の圧縮 tar イメージにまとめる必要があります。
|
注 - ダウンロードには、700M バイト以上の空き容量が必要です。この空き容量は、ダウンロード済みファイルのほか、圧縮 tar インストールファイルを「復元」した場合の容量も計算に入れています。 |
1. Sun Download Center にアクセスします。
Sun Download Center へのアクセス方法とシリアル番号についての説明は、Sun Control Station の注文時にお受け取りになった電子メールに記載されています。
2. Sun Control Station 2.2.1 ファイルをダウンロードします。
Sun Control Station 2.2.1 のインストールイメージは、ダウンロードしやすいよう 64M バイト単位ごとに分割されています。それぞれの単位をダウンロードしてから統合して、元の圧縮 tar イメージにまとめる必要があります。
ダウンロード対象のファイル、およびこれらの md5sum チェックサムは、次のとおりです。
3. ダウンロードしたファイルを次に示す順序で統合します。次のコマンドは 1 行で入力します。
# cat scs-2.2.1.166.tgz.aa scs-2.2.1.166.tgz.ab scs-2.2.1.166.tgz.ac scs-2.2.1.166.tgz.ad scs-2.2.1.166.tgz.ae scs-2.2.1.166.tgz.af > scs-2.2.1.166.tgz |
ab065e7c0b6a5cc135f30e02ec8c34f9 scs-2.2.1.166.tgz
|
注 - 次のコマンドを入力し、すべてのファイルのチェックサムを確認します。
|
4. このファイルを、インストールファイルのセットアップ先ディレクトリに解凍します。次のコマンドを入力します。
tar ファイルが解凍されると、ファイルの一覧が表示されます。
5. ディストリビューションに含まれているインストールスクリプトを実行し、ライセンスに同意します。次のように入力します。
# ./scs-2.2.1.166/install/install
『Sun Control Station 2.2 ソフトウェアのインストール』および『Sun Control Station 2.2 管理者マニュアル』に記載されている対応表は、最新情報ではありません。正しい対応表は、本書の「最新の対応表」を参照してください。
この節では、バージョン 2.2.1 の新機能について簡単に説明します。この製品の以前のバージョンに習熟しているユーザーを主に対象にしています。
Sun Control Station 2.2.1 では、管理対象ノードおよび SCS サーバーとして、SuSE Enterprise バージョン 9.0 (SLES 9) および SuSE Linux Professional 9.2 がサポートされます。クライアント/管理対象ノードとしては SLES 9 SP 1 もサポートしています。バージョン 2.2.1 では、管理対象ノードに SLES 9、SLES 9 SP1、および SuSE 9.2 ディストリビューションを OS 導入できます。Health Monitoring、Inventory、および管理ソフトウェアを見つけてこれらのプラットフォームに指定することもできます。
Health Monitoring (HM) 機能には、次のような変更があります。
本リリースでは、/home および /var パーティションがサポートされます。SCS 2.2 GA リリースでは、HM モジュールの単一のパーティションモニターによって、/、/home、/var の 3 つのパーティションがすべて監視されていました。これらのパーティションのいずれかに重大な状態や警戒を要する状態が生じた場合、状態の変化が報告されていました。SCS 2.2.1 の HM には、3 つのパーティションにそれぞれ別のモニターが装備されています。この機能により、具体的にどのパーティションで重大な状態や警戒を要する状態が発生したかが、明確に示されます。
バージョン 2.2.1 には、次の 2 種類の Inventory 機能が新たに追加されています。
大量のソフトウェアインベントリ情報を効率よく照会するため、ソフトウェアインベントリの「View Inventory」ページおよび「View Patches」ページでは、RPM、SVR4 パッケージ、またはパッチに対して、特定の検索条件に基づくフィルタや検索が可能になりました。
バージョン 2.2.1 には、ソフトウェアバンドルの一般的なインストールのサポートに関する主要な新機能が追加されています。「アップロード」画面のパッケージ選択に、「その他」という 4 番目の選択肢が追加されています。あらゆるフォーマットの単一ファイルを、「その他」のパッケージとしてアップロードできます。ファイルをアップロードすると、そのパッケージの「編集」画面が表示されます。この画面で、パッケージの名前、説明、バージョン、リリース、およびベンダー情報を入力できます。パッケージの種類が不明なため、ユーザーが必要な情報を入力する必要があります。
バンドルのインストール方法を認識するスクリプトファイルも指定しなければなりません。スクリプトファイルは Bourne シェル /bin/sh で実行できなければなりません。一般的なバンドルをインストールすると、管理対象システムの /tmp にスクリプトファイルとバンドルファイルの両方がコピーされます。次に、プラットフォームの通常のパッケージインストール用コマンド (rpm、pkgadd、または patchadd) ではなく、このスクリプトファイルが、パッケージファイルへのフルパスを唯一の引数として Bourne シェルを用いて実行されます。
stdout または stderr へのインストールからの出力は、単一文字列に取り込まれてタスクログに表示されます。インストールスクリプトがゼロ以外の値によって終了する場合、インストールは失敗したとみなされ、タスクの失敗状態が記録および表示されます。
この他、2.2.1 リリースには SVR4 パッケージのアンインストール中に admin ファイルを使用するためのサポート (コマンドラインのみ) が追加されています。2.2 リリース以降、「編集」画面から SVR4 パッケージの admin ファイルを指定できるようになりました。2.2 リリースでは、pkgadd コマンドを用いた SVR4 パッケージのインストール中に admin ファイルが使用されます。2.2.1 リリースの場合、スクリプト /scs/sbin/swi_pkg_uninstall.pl を用いた SVR4 パッケージのアンインストール時、-a オプションが指定されている場合、スクリプトは SVR4 パッケージの admin ファイルを検索します。「編集」画面で admin ファイルを指定しておいた場合、pkgrm コマンドに対して -a オプションを使用すると、管理対象ホストでそのファイルが使用されます。
UI を介してパッケージをアンインストールする場合は、デフォルトの admin ファイルが使用され、非対話形式でアンインストールが実行されます。
本リリースに新たに搭載されている LX50/v60/v65x 向けの Terminal Concentrator モジュールで、次のタスクを実行できます。
SCS 2.2 より前のリリースからアップグレードする場合は、まず v2.2 にアップグレードし、その後 v2.2.1 にアップグレードしてください。
次の問題は、SCS 2.2 RR をすでに実行しているシステムに SCS 2.2 GA リリースをパッチとしてインストールした場合にのみシステムに影響を与えます。
|
注 - SCS 2.2 GA リリースはそれ単体か、または既存の SCS 2.2 RR インストールのパッチとしてのみインストールできます。これ以外の既存の SCS インストールへのパッチまたはアップデートとしてはインストールできません。 |
2004 年 12 月 から出荷されている v20z システムには、最新の K2 マザーボードが搭載されています。変更点の 1 つは、openipmi ドライバに結合されている KCS ポートのアドレスです。以前の (K1) バージョンでは、このアドレスは標準ではなかったため、このもう 1 つのポートを結合するには SCS でカスタムの openipmi ドライバをインストールする必要がありました。現在、K2 マザーボードでは搭載ドライバが結合する先の標準のアドレスを使用しているため、カスタムドライバは不要となり、実際には機能しません。(CR6219875)
ハードウェアを新調するとともにシステムを取得しても、新ボードを認識しない SCS 2.2 の RR リリースで最初にコンピュータを管理しようとした場合、LOM モジュールをホストに追加した時点でカスタムの openipmi ドライバがインストールされた可能性があります。これは、手動構成手続きを実行したときに、ホストで実行していた LOM コマンド、すなわち ipmitool コマンドが機能しなくなることで明らかになります。
SCS パッチ (SCS 2.2 GA リリース) を追加するためのアップグレード手続きを行なっても、カスタムの openipmi ドライバはアンインストールされません。そのため、影響を受けるホストに LOM コマンドを送ってもやはり機能しません。さらに、LOM モジュールを削除して再インストールしても、またはホストを削除して再インポートしても問題は解決されません。K2 ホスト上のカスタム openipmi ドライバをアンインストールするには、もっと簡単な方法があります。
まず SCS アップグレードを行い、カスタムドライバをアンインストールすべき K2 ホストかどうかを確認します。
2. /var/log/scs-install.log ファイルに、影響を受けたホストに関連した次のようなメッセージがあります。
特に、「V20z (rev. B or later)」の箇所にご注目ください。これは、このホストが K2 マザーボードを使用しているホストであることを LOM が検出したことを表しています。
回避策として、この両方の状況が起こっている場合、カスタム openipmi ドライバを手動で、影響を受けているホストから削除する必要があります。これを行うには、次の手順に従います。
1. 影響を受けているホストに対する端末ウィンドウを root ユーザーとして開きます。
2. 次のように入力して、openipmi ドライバがインストールされていることを確認します (これによって、問題が ipmi ドライバに関係していることが確かめられます)。
このホストには、問題のドライバが実際にインストールされています。
3. まず、SCS からホストを削除する必要があります。これには、「管理」→「ホスト」で表示されるページからホストを選択し、「削除」を選択します。
4. ここで、安全に管理できるよう SCS からインポートされたすべてのファイルをホストから削除する必要があります。ルートユーザーのホームディレクトリにある hostinstall.pl スクリプトを使用してこれを実行します。
# hostinstall.pl remove
これにより、SCS でホストを管理できる SCS クライアント側のパッケージと ssh キーが削除されます。
5. 次に、カスタム openipmi ドライバ rpm を削除します。これを行うには、次のように入力します。
# rpm -e openipmi-2.4.21-29
6. 次のように入力して、カスタムドライバがインストールされていないことを確認します。
# rpm -qa | grep openipmi
7. さらに、ipmitool インストールも削除します。次のように入力します。
# rpm -qa | grep ipmitool
ipmitool-1.6.0-1.rh3
# rpm -e ipmitool-1.6.0-1.rh3
8. ipmi ドライバによってセットアップされるデバイスファイル /dev/ipmi0 が存在するかどうか、次のように入力して確認します。
# ls /dev/ipmi0
9. このファイルが存在する場合は、次のように入力して削除します。
# rm /dev/ipmi0
10. ここで、hostinstall.pl スクリプトを使用して、SCS クライアント側のパッケージと ssh キーを再インストールする必要があります。
# hostinstall.pl install
11. 最後に、SCS にホストを再インポートします。『Sun Control Station 管理者マニュアル』に記載されている新ホスト追加の手順に従ってください。
これが完了したら、『Sun Control Station 電源管理 (LOM) モジュール』の手順に従って、LOM 構成をセットアップできます。
上記の手順に従っても LOM に問題が生じる場合は、サンのサービス担当者にご連絡ください。
SCS 2.2 RR から SCS 2.2 GA にアップグレードすると、「健全性監視」情報ページの「そのほかのシステムサービス」の下にある LOM に関する健全性サービス項目の実データの代わりに、プレースホルダテキストが表示されます。(CR6219696)
データベースのスキーマおよび搭載モジュールへの変更により、SCS 2.2 の RR リリースバージョンで作成したバックアップは GA リリースでは使用できません。旧バージョンで作成したバックアップを復元しようとすると、invalid backup file エラーメッセージが表示されます。(CR6218739)
SCS 2.2 GA/RR から SCS 2.2.1 へアップグレードした場合のみ、次の問題が発生します。「Station の設定」→「アクティブな監視」機能で監視されていた一部またはすべてのサービス (CPU、ディスク、メモリー、http、telnet、tomcat、FTP、DNS、SSH、postgres、電子メール、RAID) が表示されなくなります。(CR6269565)
この問題を回避するには、Control Station ホストを実行している端末から、次のコマンドを入力します。
次の問題は、SCS 2.2 RR または SCS 2.2 GA をすでに実行しているシステムに SCS 2.2.1 リリースをパッチとしてインストールした場合にのみシステムに影響を与えます。
SCS 2.2.1 GA リリースはそれ単体か、または既存の SCS 2.2 RR または GA インストールのパッチとしてのみインストールできます。これ以外の既存の SCS インストールへのパッチまたはアップデートとしてはインストールできません。
2.2 RR または GA からのアップグレードでは、次のような情報メッセージがインストール中に表示されます。(CR6239945)
INFO :Uninstalling scs-health-2.2-153 from control station ==>/var/tmp/rpm-tmp 16917: line 3:/scs/bin healthManageServers.pl: No such file or directory |
これは、問題のない情報メッセージです。このバグは 2.2.1 リリースで修正されています。今後のアップグレードでこのようなメッセージが表示されることはありません。
2.2 RR または GA からアップグレードすると、パッケージとオペレーティングシステムの間に作成した関連付けが失われる場合があります。
この問題を回避するには、アップグレードに先立ち、Control Station から root として次のコマンドを実行し、関連付けを含むテーブル (swinstaller_pkg_os) の内容をバックアップしておきます。
/usr/bin/env PGUSER=mgmt PGPASSWORD=mgmt /usr/bin/pg_dump -p 5434 -t swinstaller_pkg_os mgmt > /tmp/pkgos.bak |
アップグレードをインストールしたあと、次のコマンドで関連付けを復元します。
/scs/sbin/db_tool.pl load /tmp/pkgos.bak
Netscape 6.2.2 は、Sun Control Limited Solaris 10 x86 のハードウェアサポートでは機能しません。
SCS 2.2 GA リリースは、Solaris 10 x86 を実行している Sun Fire V20z および Sun Fire V40z の管理対象ホストをサポートします。このリリースを執筆している時点では、Solaris 10 x86 の管理対象ホストについてはまだテストを終えていません。(CR6213445)
AllStart および Software Installer モジュール操作の中には、大容量のファイルを SCS にアップロードしなければならないものがあります。これらの操作では SCS の進行状況バーが表示されないため、システムが一瞬「ハング」したように見えることがあります。
これは、ファイルのアップロードが、SCS ソフトウェアではなくブラウザによって実行されるためです。このため SCS ソフトウェアは、アップロードが完了するまで「待つ」しかありません。極端な場合は、これに数分もかかることがあります。
時にはマウスを動かすと、一時的に「待ち状態」のマウスカーソルが表示されることがあります。しかし操作の完了を確認する最良の方法は、SCS によって適切なメッセージまたはページが表示されるまで待つことです。(CR6214326、CR6219228)
アクティブな監視が SuSE Linux システム上の FTP サービスを適切に監視しない場合、/etc/xinetd.d/vsftpd の設定ファイルに FTP を有効または無効に指定する一行が抜けている可能性があります。その場合、アクティブな監視内では FTP サービスが常にグレー表示されます。(CR6204715)
この問題を解決するには、次のいずれかの行を /etc/xinetd.d/vsftpd 設定ファイルに追加してください。
ネットワーク障害、ホスト動作障害、SCS クライアント側ソフトウェアコンポーネントの削除などが原因で Control Station の管理対象ホストが接続できなくなると、そのホストから Control Station を使用してモジュールのインストールまたは削除ができなくなります。
モジュールのインストールが失敗しても、「モジュール名をホストにインストールできませんでした」という不明確なエラーメッセージが SCS によって表示されるだけで、「制御モジュール」ページの失敗回数、およびホストの「コントロールモジュールのインストールレポート」は正しく更新されません。
モジュールの削除が失敗した場合は、適切なエラーメッセージが表示されます。ただし、「Control モジュール」、および「Control モジュールのインストールレポート」のテーブルには、モジュールがアンインストールされたことが誤って紛らわしい形で反映されます。(CR6220242)
2. アンインストールされなかったモジュールコンポーネントが残っていれば、削除します。
# /usr/mgmt/sbin/hostinstall.pl remove
3. 『Sun Control Station 2.2 ソフトウェアのインストール』の記述に従って、クライアント側の管理コンポーネントをホストに再インストールします。
4. 「管理」→「ホスト」から、適切なコマンドを使用して削除し、問題のホストを再度追加します。
|
注 - このホストが複数の Control Station から管理されている場合、それぞれの Control Station からこの最後の手順を実行する必要があります。 |
Control Station の IP アドレスを変えると、システムが不安定な状態になります。hostinstall.pl スクリプトは利用できなくなります。hostinstall.pl は 1 回限り使用するためのものです。(CR6191532)
この問題を回避するには、hostinstall.pl のすべてのコピーを管理対象ホストから削除します。管理対象ホストに新しい hostinstall.pl のコピーを転送し、これを使用して新しい Control Station のアドレスにクライアントサポートを削除して再インストールします。また、Health Monitoring モジュールを使用する管理対象ホストをすべて管理し直す必要があります。
Control Station 上の IP アドレスを変更したら、次の手順に従います。
1. 管理対象ホストから hostinstall.pl を削除します。
2. Control Station 上で、root として次のコマンドを入力します。
# /scs/sbin/updateIP.sh
このコマンドにより、hostinstall.pl の新しいコピーが Control Station に生成され、次のアドレスから利用できるようになります。
http://<controlstation>/pub/hostinstall.pl
3. 新しく作成した hostinstall.pl のコピーを管理対象ホストに転送します。
この新しい hostinstall.pl のコピーを使用して、新しい Control Station アドレスのクライアントサポートを削除して再インストールします。
4. Health Monitoring モジュールを使用しているすべてのホストを管理し直します。
それぞれのホストを削除してから、それぞれのホストを再度追加し直します。手順については、『Sun Control Station 2.2 管理者マニュアル』を参照してください。
デフォルトでは、hostinstall.pl が HTTP 経由で Control Station のホスト名と設定済み IP アドレスによって Control Station に接続を試みます。hostinstall.pl スクリプトは接続できるまで最大 3 分間待ち続けながら、各アドレスを順に接続を試みます。
このため、管理対象ホストから接続できないアドレスがあった場合、たとえば管理対象ホストが個人のサブネットに常駐するような環境の場合に、hostinstall.pl を実行中に予期せぬ遅延を引き起こすことがあります。
Control Station に接続するのに最適なアドレスがすでにわかっていれば、管理者が次のように -c スイッチでコマンドライン引数として Control Station のアドレスを hostinstall.pl に明示的に指定してこの遅延を防ぐことができます。
# ./hostinstall.pl -c 192.168.1.1 install
これにより、hostinstall.pl がスクリプトの一部として自動設定されているアドレスを使用する前に、まず IP アドレス 192.168.1.1 にある Control Station に接続を試みます。(CR6199090)
BIOS を常にネットワークから起動するように設定している場合、Sun Fire V20z が正しく機能しません。コンピュータを起動しようとすると、ホストのコンソールに次のようなエラーメッセージが表示されます。
この問題を回避するには、キーボード、シリアルポート、または Serial-over-LAN から手動でネットワークブートを行なって、OS の設定を開始します。(CR6216832)
SCS Control Station では、どの X windows セッションもローカルで実行されません。これを行うと、CPU とメモリリソースを消費し、SCS のパフォーマンスを大きく低下させます。(CR6218255)
モジュールのインストールやファイルのバックアップなど、ある主要な操作を行うと、Sun Control Station ソフトウェアで Control Station システム上の /var/tomcat4/temp ディレクトリをクリーンアップできなくなります。(CR6221622)
/var ファイルシステムが一杯になる極端な場合を除き、この問題によって引き起こされる症状はありません。
Software Installer 操作と AllStart 操作では、このようなファイルは残しません。回避策として、保留になっていた操作があった場合、それが完了したら、
/var/tomcat4/temp ディレクトリから無関係なファイルをすべて手動で削除しておくと安全です。
Redhat 3 Update 3 以降および Redhat 2.1 Update 4 以降で英語以外の各国語版 SCS 2.2 を実行している場合のみ、次の問題が発生します。
ある操作を実行すると、文字化けが表示されます。(CR6220205)
回避策として、SCS サーバーのコマンドラインから次のように実行します。
1. /etc/sysconfig/i18n ファイルを編集します。
LANG を、UTF-8 文字セットエンコードのうちの 1 つに変更します。たとえば、編集後に、次のような 1 行がファイルに加えられます。
LANG="en_US.UTF-8"
2. Tomcat サーバーを再起動します。次のように入力します。
% /etc/rc.d/init.d/tomcat4 restart
Redhat 3 Update 3 以降および Redhat 2.1 Update 4 以降で英語以外の各国語版 SCS 2.2 を実行している場合のみ、次の問題が発生します。
テキストフィールドに 2 バイト文字を入力すると、文字化けが表示されることがあります。(CR6216758)
この問題を回避するには、テキストフィールドには ASCII 文字のみを入力してください。
SuSE 9.0 で英語以外の各国語版 SCS 2.2 を実行している場合のみ、次の問題が発生します。
Health Monitor、AllStart、Software Installer モジュールのあるタスクを実行すると、「タスクの進捗状況」ウィンドウに文字化けが表示されることがあります。(CR6221654)
この問題を回避するには、英語ロケールを使用してサーバーにログインします。または、SCS サーバーに Red Hat OS をインストールします。
進行状況バーが表示されている UI でタスクを実行した直後に「バックグラウンドでのタスクの実行」ボタンを選択すると、エラーページが表示される場合があります。(CR 6191921)
この問題を回避するには、しばらく (1〜2 秒間) 待ってから、バックグラウンドでタスクを実行するようにしてください。
「ホストのスキャン」ページで指定したホストが SCS によってすでに管理されている場合、ホスト情報は返されず、これについての診断メッセージも返されません。(CR 6248259)
このような場合は、「ホスト」ページで、問題のホストがすでに管理されていることを確認してください。
特定の状況では、特殊文字 (英数字以外) を用いてグループを作成すると問題が発生します。たとえば、作成するグループ名に「%」や「&」などの文字を使用した場合、「新規グループに追加するホストの選択」チェックボックスを選択して追加対象のホストを選択すると、エラーページが表示されたり、単にグループが作成できなかったりする場合があります。(CR 6265577)
この問題を回避するには、グループの作成時、「新規グループを追加するホストの選択」チェックボックスを選択せず、グループを作成したあとでホストを追加してください。
AllStart ソフトウェアは、Red Hat EL 2.1 ASu2 オペレーティングシステムを実行中のクライアントをビルドできません。これは HTTP 1.1 のチャンキングが原因です。これは、すでに判明している Red Hat の問題点です (Red Hat バグ ID 9748 を参照)。(CR6189029)
Sun Control Station の Web サーバーは、チャンクした HTTP 1.1 応答でクライアントの HTTP 要求に応答しますが、ローダーはこれを理解しません。クライアントの /tmp/ks.cfg ファイルの末尾に、判読不可能な文字が追加されます。Anaconda はこれらの文字を解読できずに、インストールを停止します。(CR6189029)
回避策としては、思いがけない状況が起こるリスクがいくつかありますが、1.0 へ強制的に応答することでこの問題は解決します。1.0 へ応答するには、次の手順に従います。
1. ファイル /etc/tomcat4/httpd.conf に、次の行を追加します。
BrowserMatch .* downgrade-1.0 force-response-1.0
/scs/etc/init.d/init.scs-httpd restart
Red Hat Advanced Server 2.1 によるシステム設定は現在、Sun Fire V20z および Sun Fire V40z サーバーではサポートされていません。ただし、お客様ご自身のリスクでビルドを試みる場合は、次の手順を実行してください。
1. 「AllStart」ユーザーインタフェースから、AS 2.1 distro を AllStart に追加します。
2. システムのコマンドラインに root ユーザーとしてログオンします。
/scs/sbin/as_distro.pl -l
4. ユーザーインタフェースで作成した distro の ID を探します。次のように入力します。
DISTRO_ID:17 DISTRO NAME:RHEL2.1 AS U3 OS_ID: 6
cd /tftpboot/DISTRO_ID/
mv initrd.img initrd.img_BAK
cp -f initrd-everything.img initrd.img
8. Red Hat AS 2.1 クライアントを作成します。
AllStart を使用して Solaris 9 または Solaris 10 システムを設定しようとすると、RedHat Advanced Server 2.1 システム上で実行中の SCS 2.2 Control Station が機能せずにハングすることがあります。(CR6215968)
この問題を回避するには、Control Station のオペレーティングシステムを RH2.1 AS Update 5 以降にアップデートします。これで、旧バージョンの Redhat で判明している、NFS の問題によって起こるこの問題は解決されるはずです。
「AllStart プロファイル」には、「インストール後にシステムをリブートする」オプションが含まれています。
Solaris SPARC システムを設定すると、このオプションが設定されているいないにかかわらず、インストール後に JumpStart によってシステムが再起動されます。これには回避策がありません。(CR6214903)
AllStart の「リモートの場所からのファイルの追加」機能から 250M バイト以上のファイルを追加するには問題があります。Struts フレームワークにおけるアップロード済みファイルのデフォルトの最大サイズは、250M バイトです。(CR6199038)
1. 250M バイトよりも大きいファイルは、Control Station の
/scs/data/allstart/iso ディレクトリに手動でアップロードします
2. ファイルを追加するには、「Allstart」
「ファイル」 「ファイルの追加」機能を使用します。
詳細は、『Sun Control Station2.2 AllStart モジュール』を参照してください。
AllStart モジュールの実行する RAID 設定検証の内容は、ごく限定的なものです。AllStart プロファイルから正常に作成した RAID 設定は、必ずしも SuSE などの OS ベンダーによってサポートされているとは限りません。
SuSE RAID 1 および RAID 5 プロファイルには、すでに判明している問題があります。SuSE RAID 1 および RAID 5 プロファイルが機能せず、GRUB インストールエラーが発生します。(CR6181315)
特定の情報については、オペレーティングシステムソフトウェアに付属するベンダーマニュアルを参照してください。
再起動するとビルドを開始できるようクライアントのブートローダーが変更されるため、管理対象ホストは自動的に有効になります。ただし、DHCP でクライアントを PXE / ネットブートするには、「AllStart クライアント」テーブルからこれを選択し「有効化」ボタンをクリックして、クライアントを手動で再度有効にする必要があります。(CR6193165)
NFS v2 の問題により、SCS サーバーが Red Hat EL3 または SuSE 9 オペレーティングシステムの実行時には、AllStart は Solaris 9 x86 または SPARC クライアントを設定できません。Sun Control Station サーバーとして Redhat EL 3 または SuSE 9 を実行し、Solaris 9 または SPARC x86 クライアントをビルドするには、「vanilla」Linux カーネルを実行する必要があります。(CR6180789)
1. Red Hat 2.1 または Fedora Core 1 を実行します。
2. Red Hat カーネルを SuSE9 および Red Hat EL3 と置き換えるために、「vanilla」Linux カーネルをコンパイルします。
このカーネルは、ftp.kernel.org からダウンロードできます。
AllStart モジュールから複数の Solaris クライアントをビルドすると、エラーメッセージが表示されることがあります。システムが停止し、設定プロセス中に手動による入力が求められます。AllStart クライアントを有効化すると、エラーメッセージが表示されることもあります。(CR6223268)
この問題は、rules.ok ファイルに欠落している Solaris エントリで追跡できます。AllStart クライアント画面で、すべてのクライアントを無効にしてから再度有効にします。AllStart が自動的に rules.ok ファイルを再生成します。
Fedora Core 3 で解決されましたが、RedHat のバグにより、Fedora Core 2 による Sun Fire V20z または Sun Fire V40z システムの設定はサポートされていません。
この問題を回避するには、Sun Fire V20z または Sun Fire V40z システムを Fedora Core 3 で設定します。
SLES 9 を v60/v65x に OS 設定する場合、次の問題に注意する必要があります。(CR6233968)
この節では、Solaris 9 ディストリビューションに NFSv2 パッチを適用して、Red Hat EL3 または SuSE Linux Professional 9 サーバー上で稼働している SCS サーバーから、SPARC または x86 クライアントの OS を設定する方法について説明します。(CR6180789)
Solaris 9 マシンから RedHat 3.0 マシンへの nfs のマウントに問題があるため、SCS 2.2 を用いて Solaris 9 イメージを SPARC または x86 マシンに導入するには、まずディストリビューションの mini-root にパッチを当てる必要があります。
これを行うには、RedHat 3.0 SCS サーバーをマウントできるようにパッチを適用した、Solaris 9 x86/SPARC マシンを用意する必要があります。この Solaris 9 マシンから SCS サーバーをマウントし、SCS サーバーに常駐する Solaris 9 ディストリビューションにも同じパッチを適用します。
x86 用に必要なパッチは 117172-17 および 117468-02 です。SPARC マシン用のパッチは、SunSolve から入手できます。次のリンクから SunSolve にアクセスし、最新バージョンのパッチを入手してください。
http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access
2. SunSolve からパッチの zip ファイルを入手します。
6. Solaris システムをシングルユーザーモードでリブートします (reboot -- -s)。
これで、この Solaris 9 システムを使用して、ネットワーク内の SCS サーバー上にある Solaris 9 ディストリビューションにパッチできます。
1. Solaris 9 ディストリビューションを作成します。
2. /scs/sbin/as_distro.pl -l を実行し、Solaris 9 ディストリビューションの DISTRO_ID を書き留めておきます。
3. vi /etc/exports を実行し、/js *(ro,no_root_squash) を
/js *(rw,no_root_squash) に変更します。
4. /etc/init.d/nfs restart を実行します。
ふたたび Solaris 9 システムで、RedHat システムのディストリビューションにパッチを適用します。手順 2 では、インストールが部分的に失敗します。前の手順で bootenv.rc リンクが削除されているため、patchadd コマンドで SUNWos86r パッケージの検証を試行するとエラーが発生します。次の手順 4 でリンクがふたたび作成されます。これ以外にエラーが発生しなかった場合は、パッチが完了しています。
1. mount -o rw <RH30 machine ip>:/js/<distro_id> /mnt
2. patchadd -C /mnt/Solaris_9/Tools/Boot/ -M /patch 117172-17
3. patchadd -C /mnt/Solaris_9/Tools/Boot/ -M /patch 117468-02
ふたたび RedHat 3.0 システムで、次の手順を実行します。
1. vi /etc/exports を実行し、/js *(rw,no_root_squash) を
/js *(ro,no_root_squash) に変更します。
2. /etc/init.d/nfs restart を実行します。
3. cd /js/<distro_id>/Solaris_9/Tools/Boot/boot/solaris
4. ln -s ../../tmp/root/boot/solaris/bootenv.rc
これで Solaris 9 をサーバーに導入できます。別のディストリビューションにパッチを適用するときは、/patch/117172-17 ディレクトリを削除してから 117172-17 を解凍してディレクトリを再作成する必要がある場合があります。最初のディストリビューションへのパッチ適用時に、patchadd によってディレクトリに変更が加えられるため、次に patchadd を実行すると問題が発生します。
|
注 - パッチを適用したディストリビューションが導入できるのは、mini-root にパッチが適用されたためです。ただし、結果として導入される OS は、元のディストリビューションと同じバージョンです。新たに導入した OS に Redhat ディレクトリをリモートでマウントするには、この OS にも同じパッチを適用する必要があります。 |
この節では、Solaris 9 にパッチを適用することにより、K2.0 マザーボード搭載の V20z に対して S9 の OS 設定を正しく行う方法について説明します。(CR6243352、CR6240419)
V20z の K2.0 マザーボードでは Broadcom 製の 5704 NIC カードが使用されます。Solaris 9 にはこのカードに対応したドライバが搭載されていません。パッチを用いて追加する必要があります。ドライバの追加手順は次のとおりです。
mkdir /js/<distro_id>/patch。<distro_id> はディストリビューションの ID です (前の節を参照)。
2. SunSolve からパッチ 116666-04 をこのディレクトリにダウンロードします。
3. パッチを解凍します。unzip 116666-04.zip
4. /js/scripts ディレクトリにスクリプトを作成します。たとえば、次の 3 行を含む patch_sol9_k2.sh を作成します。このスクリプトは、インストールの最後に終了スクリプトの一部として実行されます。
5. UI を使用して、Solaris 9 の配置に使用する OS プロファイルに、このスクリプトを配置後カスタムスクリプトとして追加します。
/js/scripts/patch_sol9_k2.sh
6. クライアントを有効にすると、インストールの最後に patchadd コマンドが実行されます。
Allstart を正しく使用して SPARC ネットブートが実行されるよう、boot net:dhcp - install を使用してください。このコマンドを使用しない場合、
- install パラメータがないため、ビルドに失敗します。
Allstart のマニュアルには、Solaris クライアントのインポートに使用する XML の例はありません。(CR 6245169)
パッケージ依存性データは自動生成されません。パッケージをアップロードし、「編集」画面でオペレーティングシステムと関連付けたあと、メイン画面でこのパッケージを選択し、「依存性の追加」をクリックする必要があります。定義できるのは、すでにリポジトリにアップロードされているパッケージに対する依存性のみです。
インストール対象として選択したパッケージに依存性が定義されていた場合、それらのパッケージもインストールするかどうかを確認するメッセージが表示されます。依存性に対応した順序でパッケージがインストールされます。複数レベルの依存性も含まれます。
CR 6245216 の修正用に、応答ファイルと admin ファイルが Web サイトに掲示されています。応答ファイルの URL は次のとおりです。
http://docs.sun.com/app/docs/doc/816-0211/6m6nc6735?a=view
http://docs.sun.com/app/docs/doc/816-0219/6m6njqb69?a=view
admin ファイルを指定しない場合は、デフォルトのファイルが使用されます。デフォルトの値は次のとおりです。
mail= instance=unique partial=quit runlevel=quit idepend=quit rdepend=quit space=quit setuid=nocheck conflict=quit action=nocheck basedir=default |
Software Installer モジュールでプロキシの使用を停止する場合、RPM をアップロードする前に Tomcat の Web サーバーを再起動する必要があります。(CR6201371)
2. Control Station からログアウトします。
3. 次のように入力して、Tomcat の Web サーバーを再起動します。
# /scs/etc/init.d/init.scs-tomcat4 restart
RPM のアップロードについては、『Sun Control Station 2.2 Software Installer モジュール』を参照してください。
LDAP/NIS を実行している Redhat クライアントでモジュールをインストールできず、インストール中に次のエラーメッセージが表示されます。
0 INFO :- Running pkgMgr with mode "lock check"1 ERROR :Failed to run package manager
これは Redhat のバグが原因です (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=69236)。この問題を回避するには、クライアントで nscd を開始します。
nscd を正しく開始するには、次のコマンドを使用します。影響を受ける各クライアントでコマンドを実行します。
# chkconfig nscd on
# /etc/init.d/nscd start
SuSE 9.1/9.2 では、insserv をアップデートしないと SCS 管理サーバーをインストールできません。(CR6263297)
SuSE 9.2 の /sbin/insserv プログラム内のバグが原因で、SCS インストールが失敗し、次のメッセージが表示されます。
回避策としては、insserv の最新バージョンにアップデートすると、この問題が修正され、SCS インストールが正常に実行できます。
32 ビット x86 マシンの insserv パッケージは、SuSE YAST ツールを介してダウンロードしてインストールすることも、次のいずれかの Web サイトから手動でダウンロードしてインストールすることもできます。
http://ftp.suse.com/pub/suse/i386/update/9.2/rpm/i586/insserv-1.00.5-6.2.i586.rpm
http://ftp.suse.com/pub/suse/i386/update/9.2/rpm/i586/insserv.rpm
64 ビット x64 マシン用のバージョンは、次のいずれかのサイトからダウンロードできます。
http://ftp.suse.com/pub/suse/i386/update/9.2/rpm/x86_64/insserv-1.00.5-6.2.x86_64.rpm
http://ftp.suse.com/pub/suse/i386/update/9.2/rpm/x86_64/insserv.rp
SuSE 9.2 Linux Professional 上には、2 種類の tftp サーバー (atftp および tftp) があります。SCS 2.2.1 をインストールするには、tftp をインストールする必要があります。この問題を回避するには、atftp をアンインストールし、代わりに tftp を使用します。
現時点では、SLES9 プラットフォームに利用可能な perl-DBD-Pg モジュールはありません (CR 6253727)。perl スクリプトと postgres のインタフェースにはこのモジュールが必要です。回避策として、同様に Perl 5.8.3 を使用し SLES 9 で動作する SuSE Pro 9.1 用の DBD-Pg RPM を使用します。このモジュールは、次のいずれかのサイトから入手できます。
ftp://ftp.suse.com/pub/suse/i386/9.1/suse/i386/perl-DBD-Pg-1.22-194.i586.rpm
ftp://ftp.suse.com/pub/suse/x86_64/9.1/suse/x86_64/perl-DBD-Pg-1.22-170.x86_64.rpm
SCS 2.2.1 は 1.4.2_03 以前のバージョンでのみテストされています。1.4.2_03 より新しいバージョンの JDK が RPM フォーマットでインストールされている場合、SCS のインストールは失敗します (CR 6252903)。この問題を回避するには、次のように実行します。
1. インストールされている新しい JDK RPM を削除します。
2. java.sun.com にアクセスし、必要なバージョンの JDK を tgz フォーマットでダウンロードします。
3. SCS 2.2.1 をインストールします。今回は正常にインストールできます。
4. 必要なバージョンの JDK を tgz フォーマットでインストールします。
これで、ディレクトリに新しいバージョンの JDK がインストールされ、このシステムで SCS 2.2.1 が実行できるようになります。
LOM は、Sun Fire V20z サーバーに対し openipmi ドライバの代わりに imb ドライバを使用しようとします。AS 2.1 を実行中の Sun Fire V20z への LOM のインストールはサポートされていません。(CR6196687)
SLES 9、SLES 9 SP1 および SuSE Pro 9.2 を実行している V20z「K1」システムでは、LOM モジュールが機能しない場合があります。これは、関連付けられている openipmi ドライバが読み込まれない場合があるためです。この問題を回避するには、openimpi ドライバを再読み込みします。
2005 年 1 月 11 日より前に出荷された V20z システムには「K1」マザーボードが使用されている可能性が高く、次のように識別できます。
この日付よりあとに出荷されたシステムには「K2」または「K2.5」マザーボードが使用されています。末尾が「L」の標準仕様 (A55-NWB1-1-1GRA5L など) では「K2」マザーボードが使用されています。(CR 6254983)
Sun Fire V20z および Sun Fire V40z システムで実行中の LOM にのみ該当する問題です。
Sun Fire V20z および Sun Fire V40z コンピュータ上のシステムイベントログ (SEL) イベントに「Pre-init Timestamp」というタイムスタンプが付くことがあります。LOM はこのタイムスタンプを、次のように Unix バイナリタイムの 0 と解釈します。"1970-01-01 00:00:00."
LOM レコードにこのタイムスタンプが表示されても、そのコンピュータは「故障」しているわけではありません。(CR6213992)
この問題は、CPU が足りない Sun Fire V20z および Sun Fire V40z において、特定の設定でのみ発生します。
これらのシステムはアクティブセンサーであるため存在しない CPU を監視してしまい、センサーが ipmitool の範囲外の値を返すことにより LOM が「赤」または「重大」と解釈する場合があります。(CR6219901)
回避策としては、センサー名を確認してどの CPU が監視されているかを割り出し、「重大」値が実 CPU によるものか錯覚によるものかを見極めて、影響を受けたホストの Inventory モジュールのハードウェアインベントリを確認します。センサーによって示された CPU が実在しなければ、範囲外の測定値は安全に無視することができます。
LOM モジュールは、管理対象の Solaris ホストのハードウェア種類を v20z と誤って表記し続けています。これは、表記上誤っているだけであり、LOM 機能には影響を及ぼしません。また、ある特定の LOM 画面にのみ発生し、LOM 以外の SCS 画面には現れません。(CR6221467)
この問題 (CR 6262425) を回避するには、SCS による管理を可能にするため、SuSE 9.2 Linux Professional マシンのファイアウォールを無効にします。
SuSE 9.2 Linux Professional のファイアウォールを無効にするには、各マシン上で次のスクリプトを手動で実行します。
このスクリプトは、Allstartの SuSE 9.2 プロファイルに、インストール後カスタムスクリプトとして追加することもできます。カスタムスクリプトの追加方法については、Allstart のマニュアルを参照してください。
この問題は、SPARC および x86 管理対象ホストを複数のネットワークインタフェースで監視しているときにのみ発生します。
このような場合、ハードウェアインベントリがすべてのホストのネットワークインタフェースに対して正確な情報を表示しているとは信用できません。省略されているインタフェースがあったり、正しくない情報で表示されているインタフェースがあるかもしれません。(CR6221086)
ここでは、ハードウェアインベントリのファイルシステム情報の詳細な解釈について説明します (CR 6248981)。たとえば、ファイルシステム情報の「タイプ」列に「1382369651」という数字が表示されている場合、16 進数の変換により、このファイルシステムの種類は REISERFS_SUPER_MAGIC であるとわかります。一般的なファイルシステムの種類は、16 進数の値で次のように示されます。
Tot Blks は、その種類のファイルシステムで利用可能なブロック数です。ブロックの基本サイズは、使用するシステムによって異なります。通常、ほとんどの Sun システムでは 1K です。
Free Blks はファイルシステムで利用可能な空きブロック数です。使用されている容量 (%) を正確に計算するには、次の計算式を使用します。
[( Tot Blks - Free Blks ) / Tot Blks ] * 100
利用可能な空き容量 (%) を正確に計算するには、次の計算式を使用します。
[ (Free Blks)/Tot Blks ] * 100
NSU Blks は、スーパーユーザー以外のユーザーが使用できる空きブロック数です。
Nodes は、この FS に搭載可能なノードの合計数です。
File Len は、このファイルシステムでのファイル名に使用できる最大文字数です。
|
x86 上で稼働する EL 2.1 ES/AS、x86 および x86_64 上で稼働する EL 3 AS、x86 で稼働する EL 3 ES |
|
|
x86 および x86_64 上で稼働する SuSE Linux Professional 9.0 および 9.2、x86 および x86_64 上で稼働する SLES 9 |
|
x86 上で稼働する 7.3、8.0、9、x86 で稼働する EL 2.1 WS/AS/ES、x86 および x86_64 上で稼働する EL 3 WS/AS、x86 上で稼働する EL 3 ES |
|
|
x86 および x86_64 上で稼働する SuSE Linux Professional 9.0 および 9.2、x86 および x86_64 上で稼働する SLES 9、SP 1 |
|
Sun Control Station 2.2 GA リリースには、『Sun Control Station 2.2 Software Installer モジュール』マニュアルの発行後に、新しく Software Installer モジュールという主要機能が搭載されました。この節の説明は、このマニュアルの 1-12 ページの記述に置き換わるものです。
この節では、Sun
Control Station (SCS) ソフトウェアの一部である Software Installer のコントロールモジュールで使用できる機能とサービスについて説明します。このモジュールでは、次の操作を行うことができます。
フィルタ機能を使用して、表示して操作するパッケージファイルの種類を絞り込むこともできます。
|
注 - 本マニュアルでは、読者が Sun Control Station (SCS) ソフトウェアの基本操作を理解していると想定して説明します。ステータスアイコン、スケジューラ、タスクの進捗状況ダイアログなどの基本的な SCS の機能については、『Sun Control Station 2.2 管理者マニュアル』を参照してください。 |
Sun Control Station にログインし、「ソフトウェアインストールプログラム」→「パッケージ」とクリックすると、次のウィンドウが開きます。
このマニュアルでは、「パッケージファイル」という用語が次のいずれかを示すものとします。
のソフトウェアパッチは、zip フォーマット (.zip) を使用します。
次に、Softaware Installer モジュールで実行できる機能について説明します。
「アップロード」機能は、ローカルリポジトリまたはインターネットから Control Station にパッケージファイルを読み込みます。
「詳細」機能は、そのパッケージファイルに関する特定の情報を表示します。パッケージファイルの名前、バージョン、リリース、ベンダー、ファイル名、概要、説明など、パッケージファイルの関連情報を表示します。
「編集」機能は、1 つのパッケージファイルについて対応する OS の追加と削除を行います。
「編集」機能と同様、この「OS の再度関連付け」機能は複数のパッケージファイルについて対応する OS の追加と削除を行います。
「削除」機能は、利用可能なパッケージファイルの一覧からパッケージファイルを削除します。パッケージファイルが Control Station 上のローカルリポジトリ内に配置されている場合は、利用可能なパッケージファイルの一覧からそのパッケージファイルに対するエントリが取り除かれ、パッケージファイルがリポジトリから削除されます。
「インストール」機能は、選択したホストにパッケージファイルをインストールします。パッケージファイルをローカルリポジトリから管理対象ホストにコピーしてインストールします。
パッケージファイルをインストールする前に、インストールのテストを行うことができます。Control Station が先行試験を行い、.rpm の検証、パッケージファイルが以前インストールしたものでないかどうかの確認、その他一般的なエラーについての確認を行います。「インストールのテスト」オプションは、.rpm パッケージファイルに固有のもので、これ以外のパッケージファイルでは機能しません。
「依存性の追加」機能は、「利用可能なパッケージリスト」ウィンドウで選択したパッケージファイルと同種類の (現在定義されていない) すべてのパッケージファイルを表示します。依存性を追加するには、複数のパッケージファイルではなくパッケージファイルを １ つ選択します。
「依存性の削除」機能は、選択したファイルに依存するパッケージファイルとして追加したパッケージファイルをすべて、特定の順序で表示します。依存性を削除するには、複数のパッケージファイルではなくパッケージファイルを １ つ選択します。このオプションから、依存性の並べ替えも行えます。
「利用可能なパッケージリスト」ウィンドウは、製品名 が認識したすべてのソフトウェアパッケージを表示し、ローカルのリポジトリでパッケージファイルを管理できるようにします。ソフトウェアパッケージは Control Station に保存されています。
次に、「ソフトウェアインストールプログラム」ウィンドウの「パッケージ」内に表示される「利用可能なパッケージリスト」オプションの図を示します。
1 つのパッケージファイルをアップロードする手順は、次のとおりです。
1. 「ソフトウェアインストールプログラム」→「パッケージ」 と選択します。
3. 「タイプ」ドロップダウンメニューから「RPM」、「SVR4」、「パッチ」、「その他」のいずれかを選択します。
4. どちらかのラジオボタンをクリックし、パッケージファイルのロケーションを入力します。
|
注 - Control Station がプロキシを介してインターネットにアクセスする場合は、「Station の設定」→「設定」で入力したプロキシ設定が使用されます。この設定をまだ完了していない場合は、URL でパッケージファイルをアップロードする前にこの設定を行う必要があります。詳細は、『Sun Control Station 2.2 管理者マニュアル』を参照してください。 |
ファイルのアップロード中、「タスクの進捗状況」ダイアログが表示されます。
6. インストールするパッケージでサポートされるオペレーティングシステムと他の情報を入力します。詳細は、README ファイルの「Software Installer モジュール」の項を参照してください。
7. アップロードが完了したら、「完了」または「イベントの表示」のどちらかをクリックします。
「完了」をクリックすると、「パッケージ情報の編集」ウィンドウが表示されます。ここから、インストールしたパッケージファイルに対応する OS を入力できます。
利用可能なパッケージファイルの詳細情報を表示する手順は、次のとおりです。
1. 「ソフトウェアインストールプログラム」→「パッケージ」 と選択します。
2. 利用可能なパッケージファイルリストで、使用するパッケージファイルを選択します。
「詳細なパッケージ情報」ウィンドウには、選択したパッケージファイルについての情報が表示されます。表示される情報は、選択したパッケージファイルの種類によって異なります。
4. 「利用可能なパッケージリスト」ウィンドウに戻るには、「完了」をクリックします。
1 つのパッケージファイルに対して対応 OS を追加または削除する手順は、次のとおりです。
1. 「ソフトウェアインストールプログラム」→「パッケージ」 と選択します。
2. 利用可能なパッケージファイルリストで、使用するパッケージファイルを選択します。
編集できるのは、一度に 1 つのパッケージファイルだけです。
「パッケージ情報の編集」ウィンドウが開きますが、選択したパッケージファイルの種類によって異なります。次に、.rpm パッケージファイルを使用した場合の「パッケージ情報の編集」ウィンドウの一例を示します。
4. 適用できる OS を設定するには、次のオプションを設定します。
5. 編集に SVR4 パッケージファイルを選択した場合、「パッケージ情報の編集」ウィンドウに次のようなオプションがさらに表示されます。
|
注 - このスクリプトファイルは、Bourne シェルフォーマット /bin/sh と互換性のあるシェルスクリプトである必要があります。 |
6. 編集にパッチを選択した場合、「パッケージ情報の編集」ウィンドウに次のようなオプションがさらに表示されます。
複数のパッケージファイルに対して対応 OS を同時に追加または削除する手順は、次のとおりです。
1. 「ソフトウェアインストールプログラム」→「パッケージ」 と選択します。
2. 利用可能なパッケージファイルリストで、使用するパッケージファイルを選択します。
4. 適用できる OS を設定するには、次のオプションを設定します。
|
注 - 以前に「編集」を使用してオペレーティングシステムをパッケージファイルに割り当てたことがある場合でも、その情報は保管されていないため、この操作をやり直してください。 |
利用可能なパッケージファイルのリストからパッケージファイルを削除する手順は、次のとおりです。
1. 「ソフトウェアインストールプログラム」→「パッケージ」 と選択します。
2. 利用可能なパッケージファイルリストで、削除するパッケージファイルを選択します。
確認ダイアログが表示され、パッケージの削除命令の実行を確認します。
パッケージファイルが削除され、「利用可能なパッケージリスト」ウィンドウに戻ります。
パッケージファイルをインストールする手順は、次のとおりです。
1. 「ソフトウェアインストールプログラム」→「パッケージ」 と選択します。
2. 利用可能なパッケージファイルリストで、インストールするパッケージファイルを選択します。
「パッケージのインストール先ホストを選択」ウィンドウが表示されます。
|
注 - 選択したパッケージファイルに依存性を持つものがあった場合は、インストールにこれら依存性も含めるかどうかを確認するウィンドウがさらに表示されます。 |
必要に応じて、「すべてを選択」と「すべての選択を解除」ボタンを選択します。
5. RPM のみ - インストール前にパッケージファイルをテストして確認するには、「インストールのテスト」をクリックします。
このオプションはパッケージが実行可能であるかどうかを確認します。完了したら、「完了」または「イベントの表示」をクリックしてインストールに戻ります。
|
注 - 選択したパッケージファイルで対応していない OS を選択するとエラーメッセージが表示されるので、続行する前に対応 OS を更新してください。 |
7. インストールが完了または停止したら、「完了」または「イベントの表示」をクリックします。
|
注 - パッケージファイルがインストールされると、システムは、インストール済みパッケージファイルの一覧をすぐに更新します。 |
「利用可能なパッケージリスト」ウィンドウに同時に表示されるパッケージファイル数を制限するには、「フィルタ」機能を使用します。
1. 「ソフトウェアインストールプログラム」→「パッケージ」 と選択します。
「利用可能なパッケージリスト」ウィンドウが表示され、ウィンドウの下部に次のような「フィルタ」機能が表示されます。
2. 「列」ドロップダウンリストからオプションを選択します。
「列」ドロップダウンリストで利用できる検索条件は次のとおりです。
3. 「検索タイプ」ドロップダウンリストからオプションを選択します。
「検索タイプ」ドロップダウンリストで利用できる検索条件は次のとおりです。
入力されたパラメータに応じて「フィルタ」機能がパッケージファイルを検索し、更新した「利用可能なパッケージリスト」ウィンドウ内に結果を返します。
|
注 - 「クリア」をクリックすると、「利用可能なパッケージリスト」ウィンドウ内のリスト全体が更新され、利用可能なパッケージファイルのすべてが表示されます。また、フィルタの条件を 1 つクリアするには、「値の検索」テキストボックスからそのテキストを削除して「クリア」をクリックします。 |
『Sun Control Station 2.2 ソフトウェアのインストール』の 8 ページ、および『Sun Control Station 2.2 管理者マニュアル』の 4 ページに記載の対応表は、最新情報ではありません。正しい対応表は、本リリースノートを参照してください。
『Sun Control Station 2.2 AllStart モジュール』の第 2 章に記載の図 2-55 「ネットワークインタフェース情報の入力」テーブルは、旧リリースからのパラメータを示しています。バージョン 2.2 では、「ネットワークのタイプ」の「None」パラメータを使用しなくなりました。次に、正しい図を示します。
『Sun Control Station 2.2 Health Monitoring モジュール』の図 1 に記載の「健全性監視」テーブルは、正確ではありません。Raq 550 および Qube 3 が、Sun Control Station 2.2 ソフトウェアではサポートされていません。
『Sun Control Station 2.2 AllStart モジュール』の 54 ページの図 2-35 は、SuSE には適切ですが、Redhat Linux には不適切な画面を示しています。(CR6215055)
1. 「RAID とディスクデバイス」内の「ディスクドライブのオプション」アイコンは、Redhat 向けには存在しません。
2. 「自動判定 (/boot および swap のみ)」オプションは、Redhat 向けには存在しません。
『Sun Control Station 2.2 AllStart モジュール』の 77 ページの図 2-55 は、「ネットワークのタイプ」に 3 つの選択肢がある画面を示しています。この選択肢には、「Static IP」、「DHCP」、「None」がありますが、最後の選択肢「None」はオプションではなく、ソフトウェアに存在しません。(6218257)
| Sun Control Station 2.2.1 リリースノート | 819-3011-10 | |
Copyright© 2005, Sun Microsystems, Inc. All rights reserved.
パッチを適用して Solaris 9 システムを設定する