Part 1 では、Solstice AutoClient ソフトウェアについての概略を説明します。Part 1 は、次の 5 つの章で構成されています。
AutoClient の技術に関する情報を示します。AutoClient システムの特性、その他のシステムに比べた場合の利点、AutoClient の技術について説明します。
新たに追加された機能、必要なディスク容量、設定上の問題、制限事項、製品に関するその他の情報について説明します。
ネームサービス環境で Solstice AutoClient を使用する方法について説明します。
Solstice AutoClient のセキュリティに関する問題と使用時の注意事項について説明します。
ホストマネージャの機能について説明します。
Solstice AutoClient では、AutoClient システムを設定し、それを集中管理することができます。AutoClient システムとは、必要なシステムソフトウェアをサーバーからコピーしてキャッシュに書き込む (データー参照時に、データーをローカルにコピーする) システムです。AutoClient システムでは、Solaris ディスクレスシステムとキャッシュファイルシステム (CacheFSTM) のテクノロジを使用しています。
CacheFS は、サーバーとネットワークの負荷を軽減することによって、NFSTM サーバーのパフォーマンスとスケーラビリティを改良することができる、汎用的なファイルシステムキャッシュです。また、HSFS ファイルシステムと共に CacheFS を使用することもできます。CacheFS についての詳細は、日本語 Solaris 2.5 システム管理 AnswerBookTM の『Solaris のシステム管理 (第 1 巻)』を参照してください。
AutoClient テクノロジによって、システム管理者は 1 台のサーバーから多数の AutoClient システムを管理できるので、管理作業が簡単になります。たとえばシステムに変更を加える場合には、各システムごとに変更作業を行う必要はありません。また、AutoClient システムとサーバーの両方でパフォーマンスが改善されます。
この章では、次の事項について説明します。
本書では、AutoClient テクノロジを使用したシステムのことを「AutoClient システム」と記述します。
システムタイプは通常、/ (ルート)、/usr ファイルシステム、スワップ領域に、システムがどのようにアクセスするかによって分類しています。たとえば、スタンドアロンシステムやサーバーシステムは、ローカルディスクから上記のファイルシステムをマウントします。一方、ディスクレスクライアントやデータレスクライアントは、リモートからファイルシステムをマウントし、サービスの提供はサーバーが行います。表 1-1 に、各システムタイプの違いを示します。
表 1-1 システムタイプ
システムタイプ |
ローカルファイルシステム |
ローカルスワップ領域 |
リモートファイルシステム |
---|---|---|---|
/ (ルート) /usr /home /opt /export /export/home /export/root |
あり |
選択可能 |
|
/ (ルート) /usr /export/home |
あり |
選択可能 |
|
/ (ルート) |
あり |
/usr /home
|
|
なし |
なし |
/ (ルート) スワップ領域 /usr /home
|
|
AutoClient システム |
キャッシュされた/ (ルート) キャッシュされた /usr |
あり |
/ (ルート) /usr /home |
表 1-2 に、スタンドアロンシステムと比較した、その他のクライアントシステムの特徴を示します。
表 1-2 クライアントシステムの特徴 (スタンドアロンシステムとの比較)
システムタイプ |
集中管理 |
パフォーマンス |
ディスク使用効率 |
ネットワーク使用効率 |
---|---|---|---|---|
AutoClient システム |
しやすい |
同程度 |
良い |
同程度 |
ディスクレスクライアント |
しやすい |
劣る |
良い |
劣る |
データレスクライアント |
同程度 |
劣る |
良い |
劣る |
/ (ルート) および /usr ファイルシステムとスワップ領域
/export、/export/swap、/export/home ファイルシステム
クライアントシステムをサポートし、各ユーザーにホームディレクトリを提供します。
/opt ディレクトリまたはファイルシステム
アプリケーションソフトウェアを保存します。
サーバーには、他のシステムをサポートするための次のソフトウェアが置かれています。
OS サービス
ディスクレスクライアントおよび AutoClient システムに提供されます。
ネットワークシステムでリモートインストールを実行するためのソフトウェアです。
ネットワークシステムでカスタム JumpStart インストールを実行するためのディレクトリです。
ネットワーク上のスタンドアロンシステムには、ローカルのハードディスクに、 / (ルート)、/usr、/export/home のファイルシステム、スワップ領域があるので、独立して動作することができます。したがって、スタンドアロンシステムは、オペレーティングシステム、実行可能ファイル、仮想メモリー領域、ユーザーが作成したファイルに、ローカルでアクセスすることができます。また、ネットワーク上のスタンドアロンシステムは、ネットワーク上のその他のシステムと情報を共有することもできます。
ネットワークに接続されていないスタンドアロンシステムは、ネットワークに接続されていない点を除いて、上記の特性をすべて備えています。
データレスクライアントには、/ (ルート) ファイルシステムとスワップ領域があります。実行可能ファイル (/usr) とユーザーファイル (/home) は、ネットワーク上のサーバーのディスク上に置かれているので、データレスクライアントがネットワークから切り離されると、動作しません。
Solaris 2.5.1 より後のバージョンから、データレスクライアントのサポートを中止する予定です。現在は、ホストマネージャを使用してデータレスクライアントを追加することができますが、今後リリースされる Solaris では、データレスクライアント以外のシステムタイプを選択する必要があります。データレスクライアントの代わりに、AutoClient システムを使用することをお勧めします。
データレスクライアントは、ディスクレスクライアントよりも、サーバーやネットワークに対する負荷が小さくなります。データレスクライアントはネットワークへのアクセスの頻度が少ないので、サーバーはディスクレスクライアントよりも多くのデータレスクライアントに対応することができます。また、データレスクライアントのユーザーファイルはすべてサーバー上に保存されるので、サーバーでまとめてバックアップをとり、集中管理することができます。
ディスクレスクライアントはディスクを持たないので、使用するソフトウェアや必要なディスク領域はすべてサーバーに依存しています。ディスクレスクライアントは、サーバーからリモートで、/ (ルート) 、/usr、/home の各ファイルシステムをマウントします。
ディスクレスクライアントは、常にネットワークを介してオペレーティングシステムと仮想メモリー領域を確保する必要があるので、ネットワークへの負荷が大きくなります。またディスクレスクライアントは、ネットワークから切断されたりサーバーに異常がある場合には動作しません。
AutoClient システムは、インストールや管理においてはディスクレスクライアントとほぼ同じです。AutoClient システムの特徴を示します。
/ (ルート) ファイルシステムおよび /usr ファイルシステムを、サーバーからコピーしてキャッシュに書き込むための領域とスワップ領域用に、100 M バイト以上のローカルディスク領域が必要です。
サーバーが使用できなくなった場合でも、キャッシュへアクセスできるように設定することができます。
その他のファイルシステムとソフトウェアアプリケーションは、サーバーから提供されます。
次の図に、サーバーと AutoClient システムの関係を示します。
ネットワークに追加する AutoClient システムごとに、ライセンスを取得する必要があります。ライセンスについての詳細は、『Solstice AutoClient 2.1 ご使用にあたって』を参照してください。
AutoClient テクノロジには、従来のシステムタイプに比べて、システム管理上の利点があります。
AutoClient システムには、ディスクレスシステムと比較して次の利点があります。
ネットワーク環境の全体的なスケーラビリティが改善されるため、ネットワークへの負荷が小さくなります。
ディスクレスシステムに比べ、サーバー上に必要なディスク領域が少なくてすみます (AutoClient システムは、サーバー上にスワップ領域は必要ありません)。
ディスクレスシステムに比べ、必要なネットワークとサーバーの帯域幅が少なくてすみます。
AutoClient システムには、データレススタンドアロンシステムと比較して、次の利点があります。
システム管理全般が軽減されます。AutoClient システムのデーターはサーバー上にあるので、データーを集中管理することができます。たとえば、AutoClient システムを使用すると、各 AutoClient システムをサポートするサーバー上のデーターのバックアップをとるだけですみます。一方、データレスシステムのデーターのバックアップをとるには、各システム上のデーターのバックアップをとる必要があります。また、各 AutoClient システムにアクセスせずに、サーバーから AutoClient のルートファイルシステムを操作することができます。
ホストマネージャを使用して AutoClient システムを設定すると、同時にインストールも行われます。Solaris インストールプログラムを使用して、AutoClient システムに Solaris をインストールする必要はありません。
CacheFS は、AutoClient システムの重要な要素となります。キャッシュとは、データーを保存するためのローカルの領域のことです。キャッシュファイルシステムとは、ファイルが参照される時にキャッシュにファイルを書き込むローカルのファイルシステムです。いったんキャッシュに書き込まれたファイルは、2 回目以降に参照する時にはサーバーへアクセスせずに、キャッシュに直接アクセスできるようになります。これによって、ネットワークやサーバーの負荷が軽減されるため、通常は AutoClient システムへのアクセスが速くなります。なお、キャッシュがいっぱいになると、使用頻度の低い領域 (LRU) からデーターが消去されます。最も長い期間参照されていないファイルがキャッシュから削除され、現在参照されているファイル用の領域が解放されます。
AutoClient システムは、ローカルディスクを使用して、スワップ領域を確保し、サーバーのバックファイルシステムにある / (ルート) ファイルシステムと /usr ファイルシステムをキャッシュに書き込みます。図 1-2 に、どのようにして AutoClient が動作しているかを示します。
AutoClient システムは、整合性検査を行い、キャッシュファイルシステムとバックファイルシステムの同期をとります。以下に、AutoClient システムで実行される整合性検査について説明します。
デフォルトでは、サーバーのバックファイルシステムで更新されたファイルは、24 時間以内に AutoClient システムのキャッシュファイルシステムでも更新されます。ただし、autosync コマンドを使用すると、直ちにキャッシュファイルシステムを更新することができます。autosync(1M) コマンドを実行すると、整合性が検査され、サーバーのバックファイルシステムに合わせて、AutoClient システムのキャッシュファイルシステムが更新され (同期がとられ) ます。
autosync コマンドについての詳細は、第 8 章「AutoClient 環境の保守」および autosync(1M) のマニュアルページを参照してください。
AutoClient システムをブートするたびに、AutoClient システムのキャッシュファイルシステムの整合性が検査され、サーバーのバックファイルシステムに合わせて更新されます。
AutoClient システムの整合性検査は、CacheFS を実行しているシステムの場合とは異なります。AutoClient のファイル (/ および /usr) は、頻繁には変更されないので、AutoClient システムでは、CacheFS を使用したシステムよりも、整合性検査の頻度は少なくてすみます。このため、AutoClient ネットワークへの負荷が少なくなります。CacheFS の整合性検査についての詳細は、日本語 Solaris 2.5 システム管理 AnswerBook の『Solaris のシステム管理 (第 1 巻)』を参照してください。
また、AutoClient システムではライトスルーキャッシュが使用されているので、AutoClient システムに新たにファイルを追加すると、サーバーのバックファイルシステムがただちに更新されます。ライトスルーキャッシュは、キャッシュのデーターが変更または追加されると同時に、バックファイルシステムを更新するキャッシュです。
Solstice AutoClient 製品を使用して、AutoClient システムを設定したり、システムに対する変更を管理することができます。本章では、この後の章で説明する作業を正しく行うことができるように、AutoClient 製品について説明します。
この章では、次の事項について説明します。
Solstice AutoClient 2.1 には、次の新機能が追加されています。
AutoClient システムを追加、修正、削除する場合に、この機能でスクリプトをカスタマイズすることができます。AutoClient システムを追加する場合には、AutoClient システムを追加時と起動時それぞれの前後に実行されるようにスクリプトを指定することができます。修正する場合には、AutoClient システムの修正時の前後に実行されるようにスクリプトを指定することができます。
この機能についての詳細は、ホストマネージャのオンラインヘルプ、または第 5 章「ホストマネージャ」を参照してください。
AutoClient システムを追加、削除する場合に、ホストマネージャを使用してシステムのルートのパスワードを設定することができます。この機能についての詳細は、ホストマネージャのオンラインヘルプ、または第 5 章「ホストマネージャ」を参照してください。
ホストマネージャでの JavaStationTM のサポート
ホストマネージャで JavaStation のクライアントを追加することができます。この機能を使用するには、使用中のサーバーに JavaOSTM サービスを読み込んでおく必要があります。
この機能についての詳細は、ホストマネージャのオンラインヘルプ、または『Solstice AdminSuite 2.3 管理者ガイド』を参照してください。
ホストマネージャによって、複数のネットワークインタフェースを持つホスト用の IP アドレスを追加することができます。
従来のホストマネージャにはルートの機能に限界がありました。すなわち、ホストマネージャをルートとして実行している場合には、実行できる機能はほとんどありませんでした。ホストマネージャが更新されたことで、ホストマネージャのアプリケーションの実行中にも従来よりも多くの機能がルートで実行できるようになりました。
ホストマネージャによって OS サーバーから OS サービスを削除できるようになりました。
表 2-1 に、Solstice AutoClient 2.1 ソフトウェアでサポートされるサーバーとクライアントの構成を示します。
表 2-1 サポートされるサーバーおよびクライアントの構成
サーバー |
クライアント |
OS |
---|---|---|
Solaris 2.3 ‾ 2.5.1 が稼働している SPARC サーバー |
SPARC クライアント |
Solaris 2.4 ‾ 2.5.1 |
|
x86 クライアント |
Solaris 2.4 ‾ 2.5.1 |
Solaris 2.4 ‾ 2.5.1 が稼働している x86 サーバー |
SPARC クライアント |
Solaris 2.4 ‾ 2.5.1 |
|
x86 クライアント |
Solaris 2.4 ‾ 2.5.1 |
表 2-2 に、AutoClient サーバーおよび AutoClient システムに必要となるディスク容量を示します。
表 2-2 必要なディスク容量
システムタイプ |
ファイルシステム |
必要なディスク容量 (最低限) |
---|---|---|
AutoClient システムのサーバー |
/ (ルート) |
1 M バイト |
|
/usr |
4 M バイト |
|
/usr |
7.5 M バイト |
|
/export |
17 M バイト (各 OS ごとに) OS に最低限必要なディスク容量です。インストールする OS により異なりますが、実際に必要なディスク容量は、より大きなものになる場合があります。 |
|
/export |
20 M バイト (各 AutoClient システムごとに) 注 - AutoClient システムをサーバーに追加する時、各システムにつき 20 M バイトの領域を確保するディレクトリとして、デフォルトで /export/root ディレクトリが指定されます。ただし、使用可能なディスク領域がある任意のディレクトリを指定することもできます。詳細は、 「AutoClient システムの追加」を参照してください。 |
AutoClient システム |
/ ( ルート) および 共有された /usr 用のキャッシュファイル |
70 M バイト |
AutoClient は、システムのディスク全体を使用します (AutoClient のディスク構成についての詳細は、表 6-3 を参照してください)。すでにディスク上にあるデーターは上書きされてしまいます。データーが必要な場合は、システムを追加してブートを行う前に、別の場所にデーターを保存しておいてください (詳細は、「AutoClient システムの追加」を参照してください)。
Solaris 2.5 以降のオペレーティングシステムでは、ネットワークに新たに AutoClient システムを追加したり、表 2-3 のように AutoClient システムを変換したりすることができます。
表 2-3 AutoClient システムの変換
変換前 |
変換後 |
---|---|
汎用システム |
AutoClient システム |
スタンドアロンシステム |
AutoClient システム |
データレスシステム |
AutoClient システム |
AutoClient システム |
スタンドアロンシステム |
既存の汎用 (generic) システム、データレスシステム、スタンドアロンシステムを AutoClient システムに変換する場合は、再インストールとみなしてください。システム中の既存データーはすべて、AutoClient システムを最初にブートする時点で上書きされます。
AutoClient システムでは、1 ディスクまたは 2 ディスクの構成のみがサポートされます。AutoClient システムには、その他のディスク構成はお勧めできません。選択するディスク構成によっては、1 ディスクまたは 2 ディスク全体が AutoClient 製品によって上書きされることがあります。ディスク構成オプションについては、表 6-3 を参照してください。
AutoClient システムに変換されたスタンドアロンシステムにローカルなメール領域 ( /var/mail) がある場合は、このローカルディスクをキャッシュとして使用する前に、ローカルディスクからこのディレクトリをコピーしておいてください。AutoClient の設定では、一括管理によって管理作業をより簡単にできるように、サーバー上にメールスプールディレクトリを設定してください。
ネットワークのスタンドアロンシステム上にローカルファイルシステム (Solaris 分散ファイルシステム以外のファイルシステム) が存在する場合は、これらのファイルを保存してから、AutoClient システムに変換してください。AutoClient システムにローカルファイルシステムが残っていると、FRU (「AutoClient システム」および 「FRU の制限事項」参照) の利点や、バックアップが不要であるという利点がなくなります。
ホストマネージャを使用して AutoClient システムを設定すると、/opt ディレクトリが空になります。AutoClient システムが必要なファイルシステムをマウントできるように、サポートされるプラットフォームごとに特定の名前を付けた /opt ファイルシステム (たとえば、sparc_opt または x86_opt など) を設定する必要があります。
ファイルシステムの作成および管理は、ストレージマネージャを使用して行なってください。ストレージマネージャについての詳細は、『Solstice AdminSuite 2.3 管理者ガイド』を参照してください。
AutoClient システムをネットワークに設定する時には、次の制限事項に注意してください。
AutoClient システムでは、/usr ファイルシステムが読み取り専用になるので、/usr ファイルシステムを変更することはできません。AutoClient システムは、ディスクレスシステムやデータレスシステムの場合 (読み取り専用としてマウントされる) と同じように、/usr ファイルシステムを使用します。
pkginfo(1) は、AutoClient システムで利用できるソフトウェアすべてについての情報を表示するわけではありません。AutoClient システムのパッケージデータベースには、システムのルートディレクトリにインストールされたパッケージのみが含まれています。また、/usr にあるソフトウェアがすべて利用可能であっても、その情報は pkginfo(1) に反映されません。
すでに AutoClient システムを認識する NIS+ サーバーをネットワーク上で実行している場合は、通常 AutoClient システムを NIS システムとして正常にブートすることはできません 。AutoClient システムは自動的に NIS+ システムとして設定されます。ただし、bootparams ファイルを修正して、AutoClient システムに ns キーを追加すれば、この設定を変更することができます。ns キーについての詳細は、bootparams(4) を参照してください。
AutoClient システムが Solaris 2.4 で動作している場合に AutoClient サーバーが使用不可になると、AutoClient システムのコンソールに NFS server servername not responding (NFS サーバーの servername というサーバーが応答しない) というメッセージが表示されます。サーバーが使用不可になった場合でも、キャッシュ中のファイルシステムへアクセスが保証されるようにするには、Solaris 2.5 以降で AutoClient を実行する必要があります。切断時実行継続機能については、 表 6-2、またはオンラインヘルプを参照してください。
OS サーバーに OS サービスを追加した後に、ホストマネージャによって OS サービスを削除することはできません。
AutoClient では、Power ManagementTM 電源管理システム (システムの消費電力を節約するソフトウェア) はサポートされません。電源管理システムについての詳細は、『電源管理システムユーザーマニュアル』を参照してください。
AutoClient システムのインストール、設定、管理は、コマンド行インタフェースまたはホストマネージャのいずれを使用しても実施できます。ホストマネージャは、ネットワーク内の AutoClient システムを効率的かつ簡単に管理するためのグラフィカルユーザーインタフェースです。システム管理者はホストマネージャを使用して、次の作業を行うことができます。
ネットワーク環境で、AutoClient システム情報を追加、変更、表示、削除する
既存の汎用システム、スタンドアロンシステム、データレスシステムを AutoClient システムに変換する
複数の AutoClient システムに関する情報を 1 回の操作で変更する
ホストマネージャでは、AutoClient システムの /opt ディレクトリは設定されません。詳細は、「設定と移行」を参照してください。
AutoClient システムへの変換が簡単
簡単に AutoClient システムネットワークへ追加したり、既存システムを AutoClient システムに変換したりすることができます。
変更が簡単
「変更」ウィンドウを使用して、AutoClient システムを簡単に変更することができます。新しく追加された AutoClient や AutoClient に変換されたスタンドアロンシステムの変更を保存する前に、全ての属性を修正することができます。変更を保存した後では属性のサブセットの修正のみが可能です。
全体表示
ローカルネットワーク上の各システムを 1 つの画面で確認することができます。
一括処理
複数の AutoClient システムへの、追加、削除、変更の作業を、1 回の操作で実行することができます。
経過表示/状態表示
メインメニューの下にある領域に、1 回の操作で追加、削除、または変更されたシステムの数が表示されます。
表示/スクロール機能
スクロールバーを使用して、システム情報を簡単に確認することができます。またホストマネージャには検索機能も備えられています。
エラーメッセージの表示
操作中にエラーが発生すると、ポップアップウィンドウが表示されます。また、「表示」メニューから手動でウィンドウを開くこともできます。
これらの各機能については、第 5 章「ホストマネージャ」および第 6 章「AutoClient システムの管理」を参照してください。
本書では、ホストマネージャを使用して AutoClient システムを管理する方法を中心に説明を進めます。ホストマネージャの機能についての詳細は、オンラインヘルプ、または『Solstice AdminSuite 2.3 管理者ガイド』を参照してください。
表 2-4 に、ホストマネージャに対応するコマンドを示します。各コマンドは、OpenWindowsTM などの X Window System がなくでも実行できます。第 6 章「AutoClient システムの管理」で説明する処理はほとんど、コマンド行インタフェースを使用して同じ処理を実行することができます。
表 2-4 ホストマネージャに対応するコマンド行インタフェース
コマンド |
説明 |
---|---|
admhostadd |
システムまたは OS サーバーを新しく追加します。 |
admhostmod |
既存のシステムまたは OS サーバーを変更します。既存の OS サーバーに OS サービスを追加することもできます。 |
admhostdel |
既存のシステムまたは OS サーバーを削除します。 |
admhostls |
指定したネームサービスに登録されているシステム情報を表示します。 |
admhostls -h |
指定したネームサービスに登録されているシステムハードウェア情報を表示します。 |
表 2-5 に、AutoClient システムの追加や管理を行う時に、ホストマネージャで変更できるシステムファイルを示します。
表 2-5 ホストマネージャで変更できるファイル
Solstice AutoClient は、さまざまなネームサービス環境で使用することができます。
この章では、次の事項について説明します。
Solstice AutoClient では、ローカルシステム上の情報を管理するだけでなく、ネームサービスを使用することにより、ネットワークを介して情報を管理することができます。表 3-1 に Solstice AutoClient で使用することができるネームサービスを示します。
表 3-1 使用できるネームサービス
ネームサービス |
管理対象の情報 |
---|---|
NIS+ テーブル情報。テーブルを変更するには、sysadmin グループ (group 14) のメンバーであり、適切な所有権とアクセス権を持っている必要があります。 |
|
NIS マップ情報。マップを更新するには、sysadmin グループのメンバーである必要があります。NIS マスターサーバーが Solaris 1.x で動作している場合は、NIS マスターサーバーへの明示的なアクセス権が必要です。つまり、ホスト名とユーザー名のエントリが、NIS マスターサーバーのルートの .rhosts ファイルに記述されている必要があります。NIS マスターサーバーが Solaris 2.x またはネームサービス移行キット 1.2 で動作している場合は、エントリは必要ありません。 |
|
なし |
ローカルシステム上の /etc 内のファイル。ローカルシステムの sysadmin グループのメンバーである必要があります。 |
ネームサービスを使用する場合および使用しない場合の Solstice AutoClient の使用方法については、「AutoClient のアクセス権の設定」を参照してください。
Solstice AutoClient では、ホストマネージャで変更を行なった時に、どのネームサービスのデータベースを更新するかを選択することができます。ただし、各システムの /etc/nsswitch.conf ファイルには、ネームサービスの検索に関する規則が指定されています。
ホストマネージャで選択したネームサービスと、/etc/nsswitch.conf ファイル中で指定したネームサービスを、一致させるようにしてください。一致していない場合、ホストマネージャは正常に動作せず、エラーメッセージまたは警告メッセージが出力されます。ネームサービスのウィンドウの例を、「ネームサービス環境の選択」に示します。
/etc/nsswitch.conf ファイルの内容は、システム設定ファイルの更新処理には影響を与えません。/etc/nsswitch.conf ファイルには、データベースの参照先情報が指定されています。指定方法は複雑になりますが、複数のデータベースからデーターを検索するように指定することもできます。
しかし、更新時に使用するデータベースを /etc/nsswitch.conf ファイル中に指定するための規則はありません。したがって、ホストマネージャの起動時に選択したネームサービスによって、更新処理が制御されます。システム管理者は、どこに対して更新処理を行うかを決定する必要があります。
ホストマネージャを使用すると、1 回の操作で複数のシステムに対する管理作業を行うことができます。各システムの /etc/nsswitch.conf ファイルの設定内容が異なる場合は、ネットワークの管理がとても難しくなります。すべてのシステムの /etc/nsswitch.conf ファイルを同じにしておき、Solstice AutoClient ソフトウェアを使用して、標準の /etc/nsswitch.conf ファイル中に指定されている一次ネームサービスを管理することをお勧めします。
Solstice AutoClient では、admtblloc コマンドを使用することによって、ホストマネージャでの更新についてより複雑な規則を定義することができます。admtblloc コマンドについての詳細は、admtblloc(1M) のマニュアルページと 「admtblloc コマンド」を参照してください。
Solstice 起動ツールを起動して、アプリケーションのアイコンをクリックすると、ネームサービスを選択するウィンドウが表示されます。使用する環境に適したネームサービスを選択してください。
グループマネージャの「読み込み」ウィンドウの例を示します。
ネームサービス移行キット 1.2 を使用すると、Solaris 2.x で動作している NIS サーバーを使用することができます。ネームサービス移行キット 1.2 ソフトウェアのインストールと Solaris 2.x の NIS サーバーの設定については、ネームサービス移行キット 1.2 AnswerBook の『ネームサービス移行キット 1.2 の管理』を参照してください。Solstice AutoClient は、ネームサービス移行キット 1.2 でインストールした Solaris 2.x NIS サーバーでサポートされている NIS ネームサービスを使用して、情報を管理することができます。
Solaris 2.x、ネームサービス移行キット 1.2、Solstice AutoClient ソフトウェアがインストールされた NIS サーバー上で、/etc ディレクトリにある構成ファイルを AutoClient を使用して編集します (これらの構成ファイルは編集後に自動的に NIS マップに変換されます)。NIS サーバーに Solstice AutoClient がインストールされていない場合は、/var/yp/Makefile ファイル中の変数 $DIR によって指定されたディレクトリにある構成ファイルを編集します。
Solstice AutoClient を使用するには、sysadmin グループ (group 14) のメンバーでなければなりません。詳細は、「sysadmin グループへのユーザーの追加」を参照してください。
以下に、Solstice AutoClient を使用するためのその他の必要条件を、各ネームサービスごとに示します。
Solstice AutoClient を使用するための必要条件は次のとおりです。
NIS+ グループへユーザーを追加する方法、および NIS+ テーブルへのアクセス権を取得する方法については、『Solaris ネーミングの管理』を参照してください。
Solstice AutoClient を使用するための必要条件は次のとおりです。
NIS マスターサーバーが Solaris 1.x で動作している場合は、NIS マスターサーバーのルートの .rhost ファイルに、ホスト名とユーザー名のエントリが記述されていること。NIS マスターサーバーが Solaris 2.x またはネームサービス移行キット 1.2 で動作している場合は、Solstice AdminSuite がインストールされていればエントリは必要ありません。
所属しているドメイン以外で NIS マップ情報を管理する場合は、-broadcast オプション (デフォルト) を指定して ypbind を実行していること。
所属しているドメイン以外で NIS マップ情報を管理する場合は、NIS ドメインマスターが、ネットワークに直接接続されている必要があります。
sysadmin グループへユーザーを追加する方法を、各ネームサービスごとに説明します。Solstice AdminSuite を使用できる場合は、グループマネージャを使用してユーザーを追加してください。
NIS+ ドメインのシステムに、グループテーブルの読み取り権と書き込み権を持つ登録ユーザーとしてログインします。
グループテーブルを一時ファイルに保存します。
$ niscat group.org_dir > /var/tmp/group-file |
一時ファイルを編集して、Solstice AutoClient の使用を許可するユーザーを追加します。
グループファイルの sysadmin エントリにユーザーを追加する例を示します。
. . . sysadmin::14:user1,user2,user3 nobody::60001: noaccess::60002: |
記号の意味は、以下のとおりです。
user1,user2,user3 |
sysadmin グループに追加するユーザーの ID |
編集した一時ファイルを NIS+ グループテーブルとマージします。
$ /usr/lib/nis/nisaddent -mv -f /var/tmp/group-file group |
マージした結果が表示されます。
一時ファイルを削除します。
$ rm /var/tmp/group-file |
追加したユーザーごとに以下の手順を実行して、ユーザーが sysadmin グループに追加されたことを確認してください。
# su - user1 $ groups staff sysadmin $ exit |
NIS マスターサーバーにスーパーユーザーとしてログインします。
group ファイル (デフォルトでは /etc ディレクトリにあります) を編集します。
sysadmin グループに追加するメンバーをコンマで区切って指定します。
. . . sysadmin::14:user1,user2,user3 |
group ファイルが置かれているディレクトリ名は、NIS の makefile ファイル中に変数 $DIR で指定されています。group ファイルの場所が不明な場合は、このファイルを参照してください。
NIS の makefile のあるディレクトリ (デフォルトは /var/yp) へ移動し、NIS マップを再生成します。
# cd /var/yp # make group |
NIS マップのサイズによっては、マップを更新してネットワーク全体へ変更を適用するのに、数分から数時間かかることがあります。
(必要な場合のみ) NIS マスターサーバーが Solaris 1.x で稼働している場合は、NIS マスターサーバーのルート (/) ディレクトリに、.rhosts エントリを以下のような書式で作成し、NIS マップの変更権を持つユーザーの情報を記述します。
host-name user-name |
Solstice AutoClient をローカルシステムだけで使用する場合は、以下の手順を実行します。
ネームサービスには、Solstice AutoClient が管理するシステムの位置とネットワークの情報を指定する必要があります。この情報は、ローカルシステムの /etc ディレクトリ、または NIS+ および NIS のネームサービスに置かれます。
Solstice AutoClient ソフトウェアでは、異なる種類のネームサービスを使用することができます。これによって、システム設定情報を異なるネームサービスで管理することができます。
admtblloc(1M) コマンドを使用することによって、Solstice AutoClient で複製する複数の異なる種類のネームサービスを選択することができます。たとえば図 3-2 に示すように、ホストマネージャを使用して、bootparams 情報についてはローカルの /etc ファイル、その他のホスト設定情報については NIS+ テーブルを複製することができます。
異なるネームサービスを併用する場合は、/etc ディレクトリに設定情報が置かれているシステムから、Solstice AutoClient ソフトウェアを実行してください。
admtblloc コマンドを使用すると、Solstice AutoClient で異なる種類のネームサービスを併用することができます。このコマンドを使用するには、各ネームサービスで AutoClient を使用するためのアクセス権が必要になります。詳細は、「AutoClient のアクセス権の設定」を参照してください。
admtblloc コマンドは、/etc/nsswitch.conf ファイルとは関係がありません。/etc/nsswitch.conf ファイルは、Solaris 2.x オペレーティング環境でシステム全体に適用するネームサービスの選択に関する規則を設定する場合に使用します。admtblloc コマンドは、Solstice AutoClient を使用するすべてのユーザーに対する規則を設定する場合に使用します。
図 3-2 に示す各ネームサービスの内容を、admtblloc コマンドを使用して指定する例を示します。
$ admtblloc -c NIS+ -d solar.com bootparams NONE |
-c NIS+ -d solar.com |
NIS+ ドメイン solar.com は、ネームサービスのコンテキスト (「読み込み」ウィンドウで指定したネームサービスとドメイン名) を表わします。 |
bootparams |
ネームサービスを設定するための設定ファイルです。 |
NONE |
Solstice AutoClient を実行するホストで、/etc ディレクトリにある bootparams ファイルを使用するように指定します。 |
図 3-2 に示すようにネームサービスを設定すると、ネームサービス (「読み込み」ウィンドウで指定するネームサービス) が NIS+ に設定されている限り、現在 Solstice AutoClient を実行しているホストの /etc ディレクトリにある bootparams 情報が使用されるようになります。これ以外の設定ファイル (hosts、ethers、timezone、credential) に対するネームサービスは、admtblloc を使用して変更しない限り NIS+ になります。また、異なる種類のネームサービスを併用する時の方針は、admtblloc コマンドを使用して変更しない限り、ネームサービス環境で Solstice AutoClient を使用するすべてのユーザーに適用されます。
admtblloc コマンドを使用して、設定ファイルのネームサービスの位置を NONE (なし) に指定すると、現在 Solstice AutoClient を実行しているホストにある /etc ファイルが変更されます。したがって、ローカルの /etc ファイルを使用したいホストにログインし、Solstice AutoClient を使用して処理を実行する必要があります。
admtblloc コマンドを使用して、ネームサービスの設定内容を表示する例を示します。
$ admtblloc Name Name Service Path Aliases NIS+ Hosts NIS+ Group NIS+ Netgroup NIS+ Protocols NIS+ Bootparams NONE Auto.home NIS+ RPC NIS+ Timezone NIS+ Netmasks NIS+ Ethers NIS+ Passwd NIS+ Services NIS+ Networks NIS+ Locale NIS+ |
Name |
設定ファイルの名前です。 |
Name Service |
設定ファイルにアクセスするのに使用するネームサービスを指定します。 |
Path |
(必要な場合のみ) NIS ネームサービスの NIS サーバーにある ASCII ソースファイルへのパスを指定します。デフォルトは /etc ディレクトリです。 |
admtblloc コマンドを実行すると、デフォルトでは現在のホストが属するネームサービスの設定内容が表示されます。別のネームサービスの設定内容を表示するには、該当するネームサービスのコンテキストを指定します。
admtblloc コマンドを使用して、NONE (/etc ファイル) のネームサービスコンテキストのドメインに対する、ネームサービスの設定内容を表示する例を示します。
$ admtblloc -c NONE Name Name Service Path Aliases NONE Hosts NONE Group NONE Auto_home NONE Netgroup NONE Protocols NONE Bootparams NONE RPC NONE Timezone NONE Netmasks NONE Ethers NONE Passwd NONE Services NONE Networks NONE Locale NONE |
-c |
ネームサービスコンテキストを指定します。 |
NONE |
ローカルの /etc ファイルネームサービスです。 |
admtblloc コマンドを使用して、指定した設定ファイルのネームサービスの設定内容を表示することもできます。以下に、hosts ファイルに対するデフォルトのネームサービスの設定内容を表示する例を示します。
$ admtblloc Hosts Hosts NIS+ |
異なる種類のネームサービスを併用する環境で Solstice AutoClient が使用できる設定ファイルを示します。
Aliases
Hosts
Group
Auto_home
Credentials
Netgroup
Protocols
Bootparams
Rpc
Timezone
Netmasks
Ethers
Passwd
Services
Networks
Locale
上記以外の設定ファイルについては、admtblloc コマンドを使用してネームサービスを設定することはできません。
admtblloc コマンドについての詳細は、admtblloc(1M) のマニュアルページを参照してください。
Solstice AutoClient ソフトウェアを使用する際には、セキュリティ機能について理解し、管理データーを保護するためのセキュリティ方針を設定することが重要です。
この章では、次の事項について説明します。
Solstice AutoClient は、ネットワークを介して管理作業を行う際に、分散型のシステム管理デーモン (sadmind) を使用して、セキュリティ処理を行います。sadmind デーモンは、クライアントの要求をサーバー上で実行し、Solstice AutoClient を使用できるユーザーを制御します。
セキュリティの管理には、ユーザーの認証とアクセス権の承認があります。
認証とは、sadmind デーモンが要求を出したユーザーを確認することを意味します。
承認とは、「認証」されたユーザーが、サーバー上の Solstice AutoClient の実行権を持っていることを sadmind デーモンが確認することを意味します。sadmind デーモンは、ユーザーを確認して得たユーザーの情報を使用して「承認」を行います。
Solstice AutoClient の実行権を持っている場合でも、NIS+ マップを変更するには、作成権、削除権、変更権が必要です。NIS+ セキュリティについての詳細は、日本語 Solaris 2.5 システム管理 AnswerBook の『NIS+ と DNS の設定と構成』を参照してください。
承認では、ユーザーおよびグループの識別情報は次のように確認されます。
スーパーユーザーには、ローカルシステム上のデーターのみのアクセス権および変更権があります。サーバーがローカルシステムの場合 (つまり、一般のユーザーがサーバーにスーパーユーザーとしてログインした場合) 、一般のユーザーはスーパーユーザーとして Solstice AutoClient 機能を実行することができます。
sysadmin グループ (group 14) のメンバーであるユーザー
Solstice AutoClient のアクセス権は、sysadmin グループのメンバーであるユーザーに与えられます。つまり、管理データーを変更するには、変更を行うシステム上で sysadmin グループのメンバーになる必要があります。
管理データーを変更する要求には、ユーザー ID とユーザーが所属するグループ ID などの資格情報が含まれています。サーバーはこれらの資格情報を使用して、ユーザーとアクセス権を確認します。
認証セキュリティには、表 4-1 に示す 3 つのレベルがあります。
表 4-1 Solstice AutoClient のセキュリティレベル
レベル |
レベル名 |
説明 |
---|---|---|
0 |
NONE |
サーバーはユーザー識別情報をチェックしません。すべてのユーザー ID は nobody に設定されます。このレベルは主にテストで使用されます。 |
1 |
SYS |
サーバーは、クライアントシステムから元のユーザーおよびグループの識別情報を受け取り、それを確認して承認を行います。クライアントのユーザー ID がサーバー上の同じユーザーを示すかどうかは確認しません。つまり、管理者がネットワーク上のすべてのシステムにおいて、ユーザー ID とグループ ID の整合性を保つことを前提としています。このレベルでは、ユーザーが要求の実行権を持っているかどうかについて確認します。 |
2 |
DES |
DES 認証を使用して資格を確認し、ユーザーが要求の実行権を持っているかどうかを確認します。ユーザーの DES ネットワーク識別情報を、ローカルのユーザー ID およびグループ ID に割り当てることによって、ユーザーおよびグループの識別情報をサーバー上のファイルから取得します。サーバーで選択されるネームサービスによって、どのファイルが使用されるかが決まります。このレベルは、最も安全に管理作業を行うことができる環境を提供します。また、sadmind デーモンを実行しているすべてのサーバー、およびツールにアクセスするすべてのユーザーに対して、publickey エントリが必要です。 |
sadmind は、デフォルトではセキュリティレベルは 1 を使用します。
各システムの /etc/inetd.conf ファイルを編集し、sadmind エントリに -S 2 オプションを追加すると、セキュリティレベルを 1 から 2 へ変更することができます。この場合、ドメイン上のサーバーが DES セキュリティを使用するように設定されていることを確認してください。
ネットワーク上のすべてのシステムについて同じセキュリティレベルを設定しておく必要はありません。たとえば、ファイルサーバーなど厳密なセキュリティを必要とするシステムではセキュリティレベルを 2 とし、その他のシステムについてはデフォルトのセキュリティレベルを 1 にすることもできます。
NIS+ のセキュリティの設定方法については、日本語 Solaris 2.5 システム管理 AnswerBook の『NIS+ と FNS の管理』を参照してください。
sadmind デーモンは、ネームサービスが保持している情報を使用します。次の 3 つの情報源があります。
各システムの /etc/nsswitch.conf ファイルには、管理用のファイルと、情報を検索するために使用されるネームサービスを表わすキーワードが記述されています。複数のキーワードが記述されている場合、記述されている順にネームサービスが使用されます。
たとえば以下のようなエントリの場合、セキュリティ機能は、まずローカルの /etc/group ファイルでエントリを探します。
group: files nisplus
エントリが見つかるとそのエントリ中の情報を使用し、エントリが見つからない場合は NIS+ の group ファイルを検索します。
Solaris 2.4 以降の OS を使用するシステムには、ローカル /etc/group ファイルに sysadmin グループのエントリがデフォルトで記述されています。ネットワーク全体の情報を使用できるようにシステムを設定するには、ローカルシステム上で sysadmin グループにメンバーを追加するのではなく、ネームサービスのグループテーブルにある sysadmin グループのエントリを変更してください。
セキュリティレベル 2 の場合、セキュリティ機能は公開鍵および非公開鍵の情報を使用します。publickey のエントリの後に nis または nisplus (使用しているネームサービス) のいずれかが記述されていることを確認してから、files を削除します。nsswitch.conf ファイルについての詳細は、日本語 Solaris 2.5 システム管理 AnswerBook の『NIS+ と FNS の管理』を参照してください。
ネームサービス環境で Solstice AutoClient ソフトウェアを使用するためのセキュリティ方針を作成する場合は、次の点に注意してください。
どの程度の信頼性が必要かを決定する
ネットワークが安全で、認証セキュリティを使用する必要がない場合は、デフォルトのレベル 1 のセキュリティで Solstice AutoClient ソフトウェアを使用することができます。
セキュリティのレベルを高くしたい場合は、sadmind のセキュリティレベルをレベル 2 に設定することができます。
使用するネームサービスを決定する
使用するネームサービスによって、ユーザーおよびグループの識別情報をセキュリティ機能が取得する場所が決まります。ネームサービスは、/etc/nsswitchoconf ファイルに指定します。詳細は、「/etc/nsswitch.conf ファイル」および 「ネームサービス情報」を参照してください。
Solstice AutoClient ソフトウェアにアクセスするユーザーを決定する
Solstice AutoClient ソフトウェアを使用してネットワーク上で管理作業を行うユーザーを決め、そのユーザーをサーバーによってアクセスされる sysadmin グループのメンバーとして記述します。sysadmin グループは、Solstice AutoClient ソフトウェアによって管理データーが更新される各システムからアクセス可能でなければなりません。管理者が決定する方針に応じて、sysadmin グループは、各システムにローカルに設定したり、ネームサービスドメイン全体で使用できるように設定することができます。
グローバルの方針 (ネームサービスドメイン全体の方針) は、ネットワーク内のすべてのホストに影響を与えます。たとえば、NIS および NIS+ の group ファイルに、sysadmin グループのメンバーを追加することができます。sysadmin グループのメンバーは、ネームサービスを一次情報源としているすべてのサーバー上で、管理作業を行うことができます。ネームサービスは、/etc/nsswitchoconf ファイルに記述されています。nsswitch.conf ファイルについての詳細は、「/etc/nsswitch.conf ファイル」および 「ネームサービス情報」を参照してください。
ユーザーは、ローカルの /etc/group ファイルに sysadmin グループを作成して、ローカルシステムへのアクセス権を持つユーザーを記述することによって、グローバルの方針とは異なる、ローカルの方針を設定することができます。このグループのメンバーは、そのローカルシステム上で Solstice AutoClient ソフトウェアを実行して操作することができます。
ローカルの方針を設定してもグローバルの方針は有効です。ネームサービスのアクセス権は、nsswitch.conf ファイルによって決まります。
Solstice AutoClient ソフトウェアを使用して NIS+ ファイルを変更または更新する場合は、適切なアクセス権が必要です。また、NIS+ セキュリティ機能に対するアクセス権も必要です。NIS+ セキュリティ機能についての詳細は、日本語 Solaris 2.5 システム管理 AnswerBook の『NIS+ と FNS の管理』を参照してください。
NIS マスターサーバーで Solaris 1.x が稼働している場合、ユーザーが NIS ファイルを変更するためには NIS マスターサーバー上に .rhosts のエントリが必要です。NIS マスターサーバーで Solaris 2.x およびネームサービス移行キット 1.2 が稼働している場合、AdminSuite がすでにインストールされていればエントリは必要ありません。NIS の変更は、標準の sysadmin グループの機能によって承認されます。
DES セキュリティシステム (レベル 2) を作成する手順は、使用しているシステムの構成によって異なります。以下に、NIS または NIS+ のネームサービスを使用しているシステム、およびネームサービスなしのシステムに、レベル 2 の DES セキュリティを設定する手順について説明します。
sadmind デーモンを実行している各システムで、/etc/inetd.conf ファイルを編集します。
以下のような行を、
100232/10 tli rpc/udp wait root /usr/sbin/sadmind sadmind |
次のように変更します。
100232/10 tli rpc/udp wait root /usr/sbin/sadmind sadmind --S 2 |
sadmind デーモンを実行している各システムで、/etc/nsswitch.conf ファイルの publickey エントリを files に変更します。
以下のような行を、
publickey: nis [NOTFOUND=return] files |
次のように変更します。
publickey: files |
sysadmin グループのメンバー全員と、sadmind -S 2 を実行するすべてのシステムに対して、資格を作成します。
sadmind -S 2 を実行するシステムのうちの 1 台に、スーパーユーザーとしてログインします。
admintool を実行する各ユーザーに対して、次のコマンドを実行します。
# newkey -u username |
sysadmin グループのメンバーでないユーザーに対しても、上記のコマンドを実行する必要があります。sysadmin グループのメンバーでなく、資格も持っていない場合、sadmind デーモンにはユーザーとして認識されないので、処理を何も実行することができません。また、スーパーユーザーになる必要がない処理も実行することができません。この場合、newkey プログラムの実行時に、ユーザーのパスワードを入力する必要があります。
sadmind デーモンを実行できるように設定したすべてのホストに対して、次のコマンドを実行します。
# newkey -h hostname |
各ホストに対して、スーパーユーザーのパスワードを入力する必要があります。
現在ログインしているシステムの /etc/publickey ファイルを、各ホストへコピー (上書き) します。
このファイルには、各ユーザーおよびホスト用の資格が記述されています。
すべてのシステムでは newkey を実行しないでください。すべてのシステム上で実行すると、異なる公開鍵と非公開鍵の組み合わせが作成され、ネットワーク上の公開鍵が無効になります。/etc/publickey ファイルは 1 台のシステム上のみに作成し、それをその他のシステムにコピーしてください。
各システムにスーパーユーザーとしてログインし、次のコマンドを実行してルートの非公開鍵を /etc/.rootkey に置きます。
# keylogin -r |
この手順によって、システムのブート時に自動的にルートの keylogin が作成されるので、admintool を実行するシステムごとに、毎回スーパーユーザーとして keylogin を実行する必要がなくなります。
各システムの各ユーザーについて /etc/netid ファイルを作成し、すべてのシステム上に置きます。
publickey ファイル中に記述されているすべてのユーザーについて、/etc/netid ファイル中に次のようなエントリを作成します。
unix.uid@domainname uid: uid: gid,gid, ... |
このユーザーがメンバーとして登録されているすべてのグループを表示します。sysadmin グループのメンバーを確認するには、/etc/group ではなく、sadmind -S 2 や netid に依存しているファイルを利用します。
publickey ファイルに記述されている各ホストで、/etc/netid ファイル中に次のようなエントリを追加します。
unix.hostname@domainname 0:hostname |
/etc/netid ファイル内に記述されているすべてのシステムに、/etc/netid ファイルをコピーします。
すべてのシステムをリブートします。
アプリケーションを実行する各システムにログインし、keylogin を実行します (sysadmin グループのメンバーである必要があります)。
keylogin を実行すると安全にログアウトすることができます。明示的に keylogout を実行したりシステムをリブートするまで、鍵は keyserv デーモン中に保存されます。
sadmind デーモンを実行している各システムで、/etc/inetd.conf ファイルを編集します。
以下のような行を、
100232/10 tli rpc/udp wait root /usr/sbin/sadmind sadmind |
次のように変更します。
100232/10 tli rpc/udp wait root /usr/sbin/sadmind sadmind -S 2 |
sadmind デーモンを実行している各システムで、/etc/nsswitch.conf ファイルの publickey エントリを nis に変更します。
以下のような行を、
publickey: nis [NOTFOUND=return] files |
次のように変更します。
publickey: nis |
sysadmin グループのメンバー全員と、sadmind -S 2 を実行するすべてのシステムに対して、資格を作成します。
NIS サーバーに、スーパーユーザーとしてログインします。
admintool を実行する各ユーザーに対して、次のコマンドを実行します。
# newkey -u username -s files |
sysadmin グループのメンバーでないユーザーに対しても、上記のコマンドを実行する必要があります。sysadmin グループのメンバーでなく資格も持っていない場合、sadmind デーモンにはユーザーとして認識されないので、処理を何も実行することができません。また、スーパーユーザーになる必要がない処理も実行することができません。この場合、newkey プログラムの実行時に、ユーザーのパスワードを入力する必要があります。
sadmind デーモンを実行できるように設定したすべてのホストに対して、次のコマンドを実行します。
# newkey -h hostname |
各ホストに対して、スーパーユーザーのパスワードを入力する必要があります。
現在ログインしている NIS サーバー上の /etc/publickey ファイルを、/var/yp/Makefile ファイル中に指定されているソースファイルにコピーします。nis マップを作成し直してプッシュします。
# cd /var/yp; make |
nis の group マップを参照して、sysadmin グループのメンバーになっていることを確認します。
スーパーユーザーとしてログインします。
/var/yp/Makefile ファイル中に指定されているソースファイルのあるディレクトリに移動します。
/etc/group ファイルを編集した場合と同様に、グループファイルを編集して自分自身を sysadmin グループのメンバーに追加します。
/var/yp ディレクトリに移動し、make を実行します。
# cd /var/yp; make |
group マップがプッシュされると、メッセージが表示されます。
セキュリティシステムは、NIS マップを参照して sysadmin グループのメンバーを確認します。/etc/nsswitch.conf ファイルに nis グループファイルがあるかどうかに関係なく、NIS マップに sysadmin グループのメンバーとして指定していない場合は、セキュリティシステムのエラーとなります。
sadmind デーモンが -S 2 モードで実行されている場合は、publickey のエントリによって、ユーザーの資格を調べるのにどのネームサービスを参照するかが決まります。/etc/nsswitch.conf ファイル内のエントリが nis になっている場合、sadmind デーモンは nis グループマップを参照して、ユーザーが sysadmin グループのメンバーであることを確認します。
各システムにスーパーユーザーとしてログインし、ルートの公開鍵を /etc/.rootkey に置きます。
# keylogin -r |
この手順によって、システムのブート時に自動的にルートの keylogin が作成されるので、admintool を実行するシステムごとに、毎回スーパーユーザーとして keylogin を実行する必要がなくなります。
すべてのシステムをリブートし、nscd をフラッシュし (内部バッファに蓄積されたデーターをファイルに書き込み) ます。
アプリケーションを実行する各システムにログインし、keylogin を実行します (sysadmin グループのメンバーである必要があります)。
keylogin を実行すると安全にログアウトすることができます。明示的に keylogout を実行したりシステムをリブートするまで、鍵は keyserv デーモン中に保存されます。
sadmind デーモンを実行している各システムで、/etc/inetd.conf ファイルを編集します。
以下のような行を、
100232/10 tli rpc/udp wait root /usr/sbin/sadmind sadmind |
次のように変更します。
100232/10 tli rpc/udp wait root /usr/sbin/sadmind sadmind -S 2 |
sadmind デーモンを実行している各システムで、/etc/nsswitch.conf ファイルの publickey エントリを、nisplus に設定します。
以下のような行を、
publickey: nisplus [NOTFOUND=return] files |
次のように変更します。
publickey: nisplus |
NIS+ マスターサーバーにスーパーユーザーとしてログインし、sysadmin グループのメンバー全員と、sadmind -S 2 を実行するすべてのシステムに対して、資格を作成します。
NIS+ マスターサーバーにスーパーユーザーとしてログインし、AdminSuite を使用するすべてのユーザーを NIS+ の sysadmin グループに追加します。
# nistbladm -m members=username, username...[name-sysadmin], group.org_dir |
現在の sysadmin グループのメンバーは、この手順で入力したメンバーに変更されます。このため、新しく追加するメンバーだけを指定するのではなく、sysadmin グループのすべてのメンバーを指定してください。
AdminSuite を使用するすべてのユーザーを、NIS+ admin グループに追加します。
# nisgrpadm -a admin username |
NIS_GROUP 環境変数が admin に設定されていることを確認してください。
admintool を使用するすべてのシステムで、以下のコマンドを実行します。
# keylogin -r |
すべてのシステムをリブートし、nscd をフラッシュし (内部バッファに蓄積されたデーターをファイルに書き込み) ます。
アプリケーションを実行する各システムにログインし、keylogin を実行します (sysadmin グループのメンバーである必要があります)。
keylogin を実行すると安全にログアウトすることができます。明示的に keylogout を実行したりシステムをリブートするまで、鍵は keyserv デーモン中に保存されます。
ホストマネージャの機能について説明します。
この章では、次の事項について説明します。
起動ツールでツールのアイコンを選択すると、各ツールのメインウィンドウが表示されます。図 5-1 に、ホストマネージャのメインウィンドウの例を示します。
メインウィンドウには、メニューバーと表示領域の 2 つの領域があります。メニューバーには通常、「ファイル」、「編集」、「表示」、「ヘルプ」の 4 つのメニューがあります。これらのメニューについての詳細はオンラインヘルプを参照してください。オンラインヘルプの起動方法は、「システム管理ヘルプ」で説明しています。
Solstice AdminSuite ソフトウェアには、システム管理ヘルプというヘルプユーティリティがあります。システム管理ヘルプでは、Solstice AdminSuite ツールとその機能に関する詳細な情報を参照することができます。
Solstice AdminSuite アプリケーションのメインウィンドウからシステム管理ヘルプを参照するには、「ヘルプ」メニューで「xx マネージャについて」を選択します。
Solstice AdminSuite アプリケーションのコマンドウィンドウからシステム管理ヘルプを参照するには、「ヘルプ」ボタンをクリックします。
図 5-2 に「システム管理ヘルプ」ウィンドウを示します。
上部のウィンドウ区画には、参照可能なトピックの標題がヘルプの各項目ごとに表示されます。
下部のウィンドウ区画には、選択されているトピックの内容を説明するテキストが表示されます。
各区画の右側にあるスクロールバーを使用して、ヘルプ情報の表示をスクロールすることができます。
「システム管理ヘルプ」ウィンドウの左側には、情報を検索し、ヘルプシステム内を移動するためのボタンがあります。これらのボタンについては、表 5-1 を参照してください。
表 5-1 「システム管理ヘルプ」ボタン
ボタン |
機能 |
備考 |
---|---|---|
トピック |
参照可能な項目の一覧を表示 |
上部ウィンドウ区画内のタイトルをクリックすると、関連するヘルプテキストを表示します。 |
手順 |
詳細手順の一覧を表示 |
上部ウィンドウ区画内のタイトルをクリックすると、関連するヘルプテキストを表示します。 |
リファレンス |
さらに詳細な情報の一覧を表示 |
上部ウィンドウ区画内のタイトルをクリックすると、関連するヘルプテキストを表示します。 |
戻る |
前回アクセスしたヘルプテキストに戻る |
ヘルプ画面は自動的に直前に選択したヘルプテキストに戻ります。 |
終了 |
システム管理ヘルプを終了 |
「システム管理ヘルプ」ウィンドウを閉じます。 |
ホストマネージャのメインウィンドウで表示するシステムエントリを指定するには、「表示」メニューから「フィルタの設定」を選択します。「フィルタ」ウィンドウが表示され、表示対象を指定する属性を 1 つから 3 つまで指定することができます。図 5-3 に例を示します。
エントリの表示方法を選択して、「了解」をクリックします。
表 5-2 に、Solstice AdminSuite ツールのすべてのウィンドウに共通した、ボタンの機能を示します。
表 5-2 Solstice AdminSuite のウィンドウで共通なボタン
ボタン名 |
機能 |
---|---|
了解 |
操作を完了し、処理可能にします。操作の完了後、ウィンドウは閉じます。 |
適用 |
操作を完了しますが、ウィンドウは開いたままです (すべてのウィンドウで使用できるわけではありません)。 |
リセット |
すべてのフィールドを、最後の操作を行う前の内容に戻します。 |
取消し |
操作を取り消して (変更を実行しない)、ウィンドウを閉じます。フィールドの内容は元に戻ります。 |
ヘルプ |
ヘルプシステムにアクセスします。 |
「適用」をクリックした後に「了解」をクリックすると、操作が重複してエラーが発生する可能性があります。「適用」をクリックした後にウィンドウを閉じるには「取消し」をクリックしてください。
図 5-4 に示すように、ホストマネージャを使用するとメインウィンドウに大部分のシステムの属性を表示することができます。属性を表示するオプション (属性の表示方法) を変更するには、「表示」メニューから「カスタマイズ」を選択します。
ホストマネージャを使用すると、複数のシステムに対して、追加、削除、変更、変換、元に戻す、などの処理を一度に行うことができます。このような処理を「一括処理」と呼びます。図 5-5 に示すように、メインウィンドウにはスクロール機能や反転表示機能があるので、複数のシステムを同時に選択することができます。1 つ目のシステムは、マウスのセレクトボタン (左ボタン) をクリックして選択し、2 つ目以降のシステムは、Control キーを押しながらマウスのセレクトボタンでクリックして選択します。
追加、削除、変更、変換、復元の各処理についての詳細は、第 6 章「AutoClient システムの管理」を参照してください。
「メインウィンドウ」で説明したメニューバーと表示領域の 2 つの領域に加えて、メインウィンドウの下方には図 5-6 に示すような「状態表示領域」があります。
状態表示領域の左隅には、追加、削除、変更、変換などの処理を待機しているシステムの数など、まだ実行されていない変更処理に関する情報が表示されます。右隅には、現在ホストマネージャで変更しているネームサービスが表示されます。
「総変更数 (待機中): 」に表示される数は、「ファイル」メニューから「変更を保存」を選択すると、追加、削除、変更、変換などの処理が実行されるシステム数を示します。「ファイル」メニューから「変更を保存」を選択すると、「総変更数 (待機中): 」が「すべての処理に成功」に変わります。変更が正常に実行されなかった場合は、ポップアップウィンドウにエラーメッセージが表示されます。
ログファイルを設定しておくと、Solstice AdminSuite ツールまたはコマンド行で行なった主な操作を記録することができます。ログ機能を有効にすると各処理ごとに、日付、時刻、サーバー、ユーザー ID (UID)、コメントが、指定したファイルに書き込まれます。
ログファイルに操作履歴を記録するには、Solstice AdminSuite を実行している各サーバーで、「ログ機能を有効にする」の手順を実行してください。
以下の処理を実行するために、ホストマネージャや Solstice 起動ツールを終了する必要はありません。
スーパーユーザーになります。
/etc/syslog.conf ファイルの末尾に、以下の形式でエントリを追加します。
user.info filename |
filename には、ログファイル名を絶対パスで指定します。
例 : /var/log/admin.log
ログファイルを新たに作成する場合は、次のコマンドを実行します。
filename には、ログファイル名を指定します。
# touch filename |
syslog サービスをいったん停止してから再起動して、/etc/syslog.conf ファイルへ加えた変更を有効にします。
# /etc/init.d/syslog stop Stopping the syslog service. # /etc/init.d/syslog start syslog service starting. # |
Solstice AdminSuite の操作が、指定したファイルに記録されるようになります。
Aug 30 10:34:23 lorna Host Mgr: [uid=100] Get host prototype Aug 30 10:34:52 lorna Host Mgr: [uid=100] Adding host: frito Aug 30 10:35:37 lorna Host Mgr: [uid=100] Get host prototype Aug 30 10:35:59 lorna Host Mgr: [uid=100] Deleting host frito Aug 30 10:36:07 lorna Host Mgr: [uid=100] Modifying sinister with sinister Aug 30 14:39:21 lorna Host Mgr: [uid=0] Read hosts Aug 30 14:39:43 lorna Host Mgr: [uid=0] Get timezone for lorna Aug 30 14:39:49 lorna Host Mgr: [uid=0] Get host prototype Aug 30 14:40:01 lorna Host Mgr: [uid=0] List supported architectures for lorna dirpath=/cdrom/cdrom0/s0 |