NIS+ への移行

第 6 章移行の実施

この章では、NIS+ 名前空間の設定に必要な作業を、いくつかの段階に分けて説明します。

移行の実施

前の章で説明した作業を実行すれば、手のかかる仕事はほとんど終わったことになります。ここでしなければならないことは、設計した名前空間の設定と、クライアントの追加だけです。この章では、これらの処理を行う方法について説明します。これらの手順を実行するにあたっては、移行前の準備作業すべてが完了していて、各サイトのユーザーが移行の計画を了解していることを確認してください。

NIS+ ドメインを DNS ドメインと並行して使用する場合は、各 DNS ドメインに 1 つの NIS+ サブドメインを設定します。最初の DNS ドメインに完全な NIS+ 名前空間を設定して、すべてが正しく動作していることを確認したら、別の NIS+ 名前空間を並行して設定することができます。

第 1 段階 - NIS+ 名前空間を設定する

ドメインを NIS 互換モードで管理している場合でも、完全な DES 認証を備えた名前空間を設定してください。『Solaris ネーミングの設定と構成』に記載された NIS+ スクリプトを使用して、名前空間を設定します。基本的な手順の詳細については、『Solaris ネーミングの管理』を参照してください。そして、次の手順に従ってください。

ルートドメインを設定します。

NIS 互換モードでルートドメインを管理する場合は、nisserver を使用します(セットアップスクリプトを使用しない場合は、rpc.nisd および nissetup に -y フラグを付けて使用してください)。

ルートドメインテーブルを生成します。

NIS マップまたはテキストファイルから、 nispopulate を使用して、情報を転送することができます。もちろん、 nistbladm や nisaddent を使用して、同時に複数のエントリを作成することもできます。

ルートドメインのクライアントを設定します。

ルートドメインに 2、3 のクライアントを設定して、その操作を正しくテストできるようにします。完全な DES 認証を使用してください。これらのクライアントコンピュータの中には、後でルートの複製サーバーに変換されたり、ルートドメインをサポートする管理者のワークステーションとして機能するものがあります。NIS+ サーバーは、個人用のワークステーションにはなりません。

サイト固有の 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+ の構成オブジェクトのアクセス権を再構成して、管理責任を割り当てることもできます。

第 2 段階 - NIS+ 名前空間を他の名前空間に接続する

ルートドメインを DNS 名前空間に接続します (任意)。

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+ テーブルを実際の情報源にする時期を決めます。

DNS と NIS の両方との NIS+ の操作をテストします。

3 つの名前空間をすべて一緒にテストして、追加した接続に問題がないことを確認します。

第 3 段階 - 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+ の命名方式に合わせて変更します。たとえば、物理的な位置を表す名前を持つドメインをいくつか残し、その一方で組織的な階層へ移行した場合は、物理的な位置を表す名前を組織を表す名前に変更します。

第 4 段階 - NIS 互換ドメインを移行する

最後の NIS クライアントを NIS+ に移行します。

NIS 互換の NIS+ ドメインが、できるだけ早く不要になるようにします。最後の NIS クライアントを NIS+ に移行すると、NIS+ のセキュリティ機能を利用できるようになります。ネットワーク上で Solaris 以外のコンピュータを実行している場合は、NIS 互換の NIS+ ドメインを削除することはできません。

セキュリティ構成を調整します。

NIS クライアントがなくなったら、NIS+ サーバーを標準モードで再起動して、NIS+ テーブルに対して nischmod を実行し、アクセス権レベルを変更して、NIS 互換によって生じたセキュリティの不備を削除することができます。NIS+ 主体に以前に資格を作成しなかった場合は、ここで資格を作成してください。認証されていない主体のアクセスは制限してください。

その他の評価とプログラムの改善を行います。

操作手順を評価して、改善できるものがないかを調べます。特に、問題回復に使用される手順を調べてください。新しい NIS+ リリースと機能強化の可能性について検討します。また、新しい NIS+ テーブルを必要とする可能性がある Solaris の構成要素の開発を調査します。さらに、NIS+ 管理作業をより効率的に実行できるようにする自動化ツールを探します。最後に、社内の開発担当者と協力して、NIS+ API を利用できるように援助してください。

これで NIS+ への移行は完了です。