この章では、NIS+ 名前空間の設定に必要な作業を、いくつかの段階に分けて説明します。
前の章で説明した作業を実行すれば、手のかかる仕事はほとんど終ったことになります。ここでしなければならないことは、設計した名前空間の設定と、クライアントの追加だけです。この章では、これらの処理を行う方法について説明します。これらの手順を実行するにあたっては、移行前の準備作業すべてが完了していて、各サイトのユーザが移行の計画を了解していることを確認してください。
NIS+ ドメインを DNS ドメインと並行して使用する場合は、各 DNS ドメインに 1 つの NIS+ サブドメインを設定します。最初の DNS ドメインに完全な NIS+ 名前空間を設定して、すべてが正しく動作していることを確認したら、別の NIS+ 名前空間を並行して設定することができます。
ドメインを NIS 互換モードで管理している場合でも、完全な DES 認証を備えた名前空間を設定してください。『Solarisネーミングの設定と構成』に記載された NIS+ スクリプトを使用して、名前空間を設定します。基本的な手順の詳細については、『Solarisネーミングの管理』を参照してください。そして、次の手順にしたがってください。
ルートドメインを設定します。
NIS 互換モードでルートドメインを管理する場合は、nisserver に -y フラグを使用します(セットアップスクリプトを使用しない場合は、 rpc.nisd および nissetup に -y フラグを付けて使用してください)。
NIS マップまたはテキストファイルから、 nispopulate を使用して、情報を転送することができます。もちろん、 nistbladm やnisaddent を使用して、一度に複数の エントリを作成することもできます。
ルートドメインのクライアントを設定します
ルートドメインに 2、3 のクライアントを設定して、その操作を正しくテストできるようにします。完全な DES 認証を使用してください。これらのクライアントコンピュータの中には、後でルートの複製サーバに変換されたり、ルートドメインをサポートする管理者のワークステーションとして機能するものがあります。NIS+ サーバは、個人用のワークステーションにはなりません。
新しい NIS+ ルートドメインにサイト固有のカスタム NIS+ テーブルが必要な場合は、 nisaddent を使用してそれらのテーブルを作成し、 nistbladm を使用して、それらのテーブルに NIS データを転送します。
管理者には、LOCAL 資格と DES 資格がなければなりません ( nisaddcredを使用します)。管理者のワークステーションは、ルートドメインのクライアントでなければならず、管理者のルート識別情報は、DES 資格を持つ NIS+ クライアントでもなければなりません。
必要に応じて、sendmailvars テーブルを変更します。
新しいドメイン構造の結果、電子メール環境が変更された場合は、ルートドメインの sendmailvars テーブルを、新しいエントリを使って生成します。
まず、クライアントをサーバに変換します (NIS 互換のためにrpc.nisd に -Y オプションを使用し、DNS 転送が必要な場合は -B も使用します)。次に、nisserver -R.を使って、それらのサーバをルートドメインに関連づけます。
NIS 互換の場合は、 rpc.nisd に -Y オプションを使用して実行します。そして、 /etc/init.d/rpc ファイルを編集して、EMULYP 行からコメント記号 (#) を削除します。DNS 転送の場合は、rpc.nisd に -B オプションを使用します。
一連のインストール固有のテストルーチンを作成して、NIS+ に切り替えた後に、クライアントの機能を確認します。これにより、移行処理の効率が向上して、問題が減ります。このドメインをおよそ 1 週間操作してから、他のユーザを NIS+ に移行するようにしてください。
名前空間の残りを設定します。
これ以上クライアントを NIS+ に移行しないで、処理を進め、ルートドメインの下にある他のドメインをすべて設定します。これには、マスタサーバと複製サーバの設定も含まれます。新しい各ドメインを、ルートドメインの場合と同様に完全にテストして、構成とスクリプトが正しく機能することを確認します。
保守、バックアップ、復元などのすべての操作手順をテストします。名前空間内のすべてのドメイン間での情報共有処理をテストします。NIS+ 全体の操作環境を検査し終わるまでは、第 2 段階に進まないでください。
これは、すべてが正しく機能していれば必要ありません。ただし、不正なアクセスから保護したい情報がある場合は、NIS+ テーブルのデフォルトパーミッションを変更して、 NIS クライアントであっても、それらの情報にアクセスできないようにすることができます。また、NIS+ グループのメンバの関係と NIS+ の構成オブジェクトのパーミッションを再構成して、管理責任を割り当てることもできます。
NIS+ クライアントは、ネームサービススイッチを使って、Internet に接続することができます。ワークステーションが DNS クライアントでもある場合、そのネームサービススイッチ構成ファイルを設定して、NIS+ テーブルや NIS マップだけでなく、DNS ゾーンファイル内の情報を検索することもできます。
各クライアントの /etc/nsswitch.conf ファイルと /etc/resolv.conf ファイルを正しく構成してください。 /etc/nsswitch.conf ファイルは、クライアントのネー ムサービススイッチ構成ファイルです。 /etc/resolv.conf には、クライアントの DNS の IP アドレスを列挙します。これは『Solarisネーミングの設定と構成』で説明されています。
NIS+ と DNS の共同操作をテストします。
情報への要求を複数の名前空間の間で、問題なく渡せることを確認します。
NIS+ を NIS と並行して操作している場合は、情報の転送をテストします。
nispopulate スクリプトを使用して、NIS から NIS+ へ情報を転送します。NIS+ から NIS へデータを転送するには、 nisaddent -d を実行後、 ypmakeを実行します。(詳細についてはマニュアルページを参照してください。) スクリプトを使用して、この処理を自動化します。テーブル、特に hosts テーブルと passwd テーブルを同期させる方針を設定します。NIS 環境と NIS+ 環境の間で整合性を維持するために使用するツールをテストします。NIS+ テーブルを実際の情報源にする時期を決めます。
一度に 1 つのワークグループのクライアントを移行して、1 つのサブネット内のワークグループをすべて移行してから、他のサブネットでの移行を行います。このように、1 つのサブネット内のクライアントをすべて移行したら、そのサブネット上の NIS サービスを削除することができます。各クライアントを移行したら、検査スクリプトを実行して、移行が正しく行われたことを確認します。この検査スクリプトは、ユーザに対して、問題とその問題の報告に役立つサポート形態を通知します。実際に必要は手順は、サイトによって異なります。
nisclient スクリプトを使用して、NIS クライアントを NIS+ クライアントに移行します。クライアントの DNS 構成を変更する必要がある場合は、独自のスクリプトを作成して、その処理を自動化しなければなりません。
/usr/local のような共有の、マウントされるディレクトリがサイトにあれば、時間を節約することができます。このディレクトリにスクリプトを置いて、移行時に、このスクリプトをスーパーユーザとして実行するよう依頼する電子メールをクライアントに送ることができます。
クライアントの移行中、移行の状況を監視します。
計画と突き合わせて進行状況を追跡し、計画段階では予測できなかった重大な問題がないかを監視します。状況を通知して、関係するグループがそれを追跡できるようにします。
サブネット上のすべてのクライアントが NIS+ に移行されたら、NIS サーバを削除します。特定のサブネットに、NIS サービスを必要とするクライアントがある場合は、NIS+ サーバの NIS 互換モード機能を使用します。NIS サーバをそのままにしないでください。
実装が完了したら、NIS+ が正しく機能しているかどうかをテストします。
性能の評価結果に基づいて、必要であれば NIS+ の環境を変更します。このような改善には、選択した複製サーバを負荷の高いドメインに追加するような簡単なものや、ドメインのグループの NIS+ 情報の記憶領域を再編成したりすることが含まれます。
移行の際に、簡素化のため、古いドメインの名前を変更しなかった場合は、それらをここで新しい NIS+ の命名方式に合わせて変更します。たとえば、物理的な位置を表す名前を持つドメインをいくつか残し、その一方で組織的な階層へ移行した場合は、物理的な位置を表す名前を、組織を表す名前に変更します。
できるだけ早く、NIS 互換の NIS+ ドメインが不要になるようにします。最後の NIS クライアントを NIS+ に移行すると、NIS+ のセキュリティ機能を利用できるようになります。ネットワーク上で Solaris 以外のコンピュータを実行している場合は、NIS 互換の NIS+ ドメインを削除することはできません。
NIS クライアントがなくなったら、NIS+ サーバを標準モードで再起動して、NIS+ テーブルに対して nischmod を実行し、パーミッションレベルを変更して、NIS 互換によって生じたセキュリティの不備を削除することができます。NIS+ 主体に以前に資格を作成しなかった場合は、ここで資格を作成してください。認証されていない主体のアクセスは制限してください。
操作手順を評価して、改善できるものがないかを調べます。特に、問題回復に使用される手順を調べてください。新しい NIS+ リリースと機能強化の可能性について検討します。また、新しい NIS+ テーブルを必要とする可能性がある Solaris の構成要素の開発を調査します。さらに、NIS+ 管理作業をより効率的に実行できるようにする自動化ツールを探します。最後に、社内の開発担当者と協力して、NIS+ API を利用できるように援助してください。