test

NIS+ への移行

第 5 章 移行の準備

この章では、移行を始める前に実行しなければならないいくつかの作業について説明します。

他のシステムに対する NIS+ の影響を調べる

システム管理者を教育するだけでなく、サイトで NIS+ を紹介し、テストを行い、NIS+ に習熟できるような教育を行なってください。また、NIS+ への移行によって影響を受ける他のシステムやアプリケーションの NIS への依存関係を調べてください。

たとえば、アプリケーションの中には、NIS マップの一部に依存するものがあります。これらのアプリケーションが標準 NIS+ テーブルまたはカスタム NIS+ テーブルのどちらで機能するか、また、それらのアクセスの必要性によりセキュリティ計画全体にどのような影響が及ぶかを調べてください。

さらに、サイトで使用される標準以外の NIS マップはどれか、また、それらのマップを NIS+ テーブルに変換するかあるいは標準以外の NIS+ テーブルを作成して、情報を格納できるかを調べてください。アクセス権をチェックする必要もあります

各サイトで、NIS に依存する、ローカルで作成したアプリケーションを使用するかどうかも調べます。また、 yp_match() 関数の呼び出しが埋め込まれているかどうかなど、直接 NIS を呼び出すコマンドやアプリケーションがあるかどうかも調べる必要があります。(詳細については、「NIS と NIS+ の API 関数の対応」 を参照してください。)

名前空間でユーザー名とホスト名が重複していないかチェックしてください。(詳細については、「ユーザー名とホスト名の重複の解決」を参照してください。)

NIS+ への移行がネットワークのインストール手順に与える影響も調べます。もし影響があれば、必要な変更を分析してください。 NIS+ のサイト管理作業に対する影響を調べると、発生する可能性がある障害を事前に明らかにすることができます。

システム管理者の教育

「NIS+ について理解する」 で説明した紹介と教育プログラムのもう 1 つの目的として、各サイトの管理者に NIS+ の概念を理解してもらい、作業手順に慣れる機会を与えるということがあります。教室での学習だけでは不十分です。システム管理者には、業務に支障をきたさない環境で作業する機会が必要です。この教育には、次の内容が含まれます。

ユーザーへの事前の連絡

NIS+ へのクライアントの移行を実際に開始するかなり前から、ユーザーに事前に移行についての連絡を行ってください。実装の計画を伝え、詳細を入手する方法を提供してください。第 1 章「概要」 で説明したように、移行の主な目的の 1 つは、クライアントに対する移行の影響を最小限に抑えるということですが、当然ユーザーは新しい変更に気づく場合があります。このような場合には、電子メールで通知を送って、情報セミナーの開催を知らせ、ユーザーが質問を送信できる電子メールの別名または個人名を指定してください。

必要な変換ツールとプロセスを明らかにする

移行のツールを作成または入手して、実装に利用してください。各サイトですでに自動化ツールを使用して、個々のシステムやネットワークサービスを管理している場合は、それらを移植して、移行に使用するバージョンの Solaris ソフトウェアや NIS+ で動作するようにしてください (「1 種類のソフトウェアリリースを使用する」を参照)。次に、スクリプトを作成する際の推奨事項を示します。

このようなスクリプトを作成すると、ドメイン全体で一貫した移行を行い、移行の効率をあげて、問題を減らすことができます。また、名前空間全体のすべてのクライアントで使用できるような、 nsswitch.conf といった一連の標準構成ファイルとオプションを用意する必要もあります。

移行に使用される管理用のグループを明らかにする

移行を行う際に調べた管理資源に対応する名前空間の設計 (「パスワード有効期限の基準、原則、および規則を確立する」 を参照) の一部として、NIS+ グループが作成されたことを確認してください。NIS+ 名前空間の日常的な操作に使用されるもの以外の NIS+ グループを、移行に使用することもできます。リモートの管理者の援助が至急必要な場合には、グループにこれらの管理者を追加してください。

グループのメンバに正しい資格があり、名前空間オブジェクトがグループに正しいアクセス権を承認していることを確認してください。また、その適切なグループが、適切な名前空間オブジェクトのグループ所有者として識別されることを確認してください。

表 5-1 は、NIS+ グループで使用できるコマンドとグループアクセス権をまとめたものです。

表 5-1 グループ用の NIS+ コマンド

コマンド 

説明 

nisgrpadm

グループを作成または削除し、メンバを追加、変更、一覧表示、削除する 

niscat -o

NIS+ グループのオブジェクト属性値を表示する 

nissetup

ドメインのグループが格納されているディレクトリの基本構造を作成する 

nisls

ディレクトリの内容を一覧表示する 

NIS_GROUP

シェルで設定されている nisdefaults の値を上書きする環境変数

nischmod

オブジェクトのアクセス権を変更する 

nischown

NIS+ オブジェクトの所有者を変更する 

nischgrp

NIS+ オブジェクトのグループ所有者を変更する 

nistbladm -u

NIS+ テーブルの列へのアクセス権を変更する 

nisdefaults

現在の NIS+ のデフォルトを表示、または変更する 

ドメインの所有者を決める

ドメイン階層の機能を十分利用するには、ドメインの所有権を、それらのドメインをサポートしている組織に分散させてください。これにより、ルートドメインの管理者が、ローカルレベルの基本的な作業を行わなくてもすむようになります。 誰が何を所有しているのかがわかれば、管理用のグループを作成するための指針を用意して、オブジェクトへのアクセス権を設定することができます。

NIS+ ドメインの所有権と DNS ドメインの所有権をどのように調整するかを検討してください。次のいくつかの指針を示します。

資源の利用度を調べる

実装にどの管理資源が必要かを調べます。これらの資源は、通常の NIS+ の操作に必要な資源をはるかに超えます。移行を行うときに、NIS+ と NIS の互換性が必要な期間が長期に及ぶ場合は、さらに資源が必要になります。

名前空間の設計を実装する作業だけでなく、多くのクライアントを移行して、特殊な要求や問題を処理する作業についても検討してください。このとき、NIS+ の習得にかなり時間がかかることを考慮に入れておいてください。NIS+ でサポート作業を行う場合、NIS で作業していたときとくらべて、しばらくの間、管理者の作業効率がやや低下する場合があります。このため、通常の教育だけでなく、実習経験をともなう上級コースの研修を受けることも検討してください。

さらに、移行が完了した後でも、管理者は、NIS+ をサポートするための毎日の作業に慣れるまでに若干の時間を要します。

ハードウェア資源についても検討してください。NIS サーバーは、経路指定、印刷、ファイル管理などの他のネットワークサービスをサポートするために使用されることがよくあります。NIS+ サーバーにかかる可能性のある負荷を考えて、専用の NIS+ サーバーを使用する必要があります。このように負荷を分散すると、障害追跡と性能監視が簡単になるため、移行が簡略化されます。もちろん、システムを追加するとコストがかかります。必要なサーバーの数と、その構成方法については、第 2 章「NIS+ 名前空間の設計」 に説明があります。

これらのサーバーは、NIS サーバーの他に必要であることを忘れないでください。NIS サーバーは、移行が完了すると、必要なくなるか、あるいは他の用途で使用される場合がありますが、 NIS+ サーバーは引き続き使用されます。

ログイン名とホスト名の衝突を解決する

NIS+ 認証では、ワークステーションとユーザーが、1 つのドメイン内で同じ名前を使用することはできません。たとえば、joe@joe は使用できません。NIS+ は、ホストの資格とログイン名の資格を区別しないため、1 つの名前に 1 種類の資格を使用するだけですみます。名前空間に重複する名前があり、何らかの理由でその重複するホスト名を維持しなければならないときは、次のように変更してください。つまり、ユーザーログイン名をそのままにして、重複するホスト名を別名に指定します。ホストに新しい名前を作成して、古い名前を新しい名前の別名として使用します。無効な名前の組み合わせの例については、「ユーザー名とホスト名の重複の解決」 を参照してください。

名前の衝突を解決してから実装を開始する必要がありますが、通常の NIS+ 操作中、新しいワークステーションとユーザーの名前を常時チェックする計画をたてる必要もあります。これには、nisclient スクリプトを使用してクライアントの資格を作成すると、名前の比較が行われます。

すべての情報源となるファイルを調べる

/etc 内のファイルと NIS マップをすべて調べて、空のフィールドやこわれているデータがないかを確認してから、 NIS+ を構成してください。NIS+ テーブルの生成スクリプトとコマンドは、データファイルに空のフィールドや余分な文字があると、正常に実行されない場合があります。空フィールドを埋めるか、またはデータを修正してから、作業を開始してください。NIS+ スクリプトをそのまま実行してデータを破壊する危険をおかすよりも、問題のあるユーザーやマシン名を、 /etc 内のファイルや NIS マップから削除してから、 NIS+ スクリプトを実行して、NIS+ のインストール後にそれらを戻すようお勧めします。

ホスト名から "." を削除する

NIS+ では、ドット (ピリオド) を、マシン名とドメインの区切り、および親ドメインとサブドメインとの区切りに使用するため、ドットを含むマシン名 (ホスト名) を付けることはできません。NIS+ へ移行するにあたって、ホスト名からドットを必ず削除する必要があります。ドットの代わりにハイフン (-) を使用できます。たとえば、sales.alpha というマシン名を付けることはできません。この名前は、sales-alpha に置き換えることができます。(使用可能なホスト名の詳細については、hosts のマニュアルページを参照してください)。

NIS マップ名から "." を削除する

第 2 章「NIS+ 名前空間の設計」で説明したように、NIS+ のオートマウンタテーブルでは、その名前とファイル内容の "." が下線で置き換えられています。この変更は、移行中に使用する NIS マップの名前に対しても行う必要があります。この変更を行わないと、NIS+ は、名前の "." を、オブジェクト名のドメインレベルを区別するピリオドと混同します。

注 -

オートマウンタだけでなく、すべての NIS マップの「.」を必ず下線に変換してください。ただし、標準以外の NIS マップの名前をドットから下線に変更した場合、標準以外のマップを使用するアプリケーションを、NIS+ 構文を認識するように変更しないと、そのアプリケーションに障害が生じるおそれがあります。

既存の NIS 名前空間を文書化する

現在の構成を文書化しておくと、移行を開始する開始点を明確にすることができます。次の項目のリストを作成してください。

NIS クライアントのリストと、最終的な NIS+ ドメインを対応させてください。これらは、Solaris オペレーティング環境にアップグレードする必要があります。

NIS サーバーの移行計画を作成する

NIS サーバーについてよく考慮します。移行が完了した後でも NIS サーバーを他の用途に使用することができますが、「両方」のサービスにサーバーを必要とする段階があることを忘れないでください。したがって、既存の NIS サーバーを使って、すべての NIS+ サーバーの必要を満たす計画を立てることはできません。

NIS サーバーの詳しい移行計画を作成して、NIS+ に使用される NIS サーバーと、その移行時期を明らかにしておくと役立ちます。NIS から NIS+ への移行の初期段階では、NIS サーバーを NIS+ サーバーとして使用しないでください。第 6 章「移行の実行」で説明するように、名前空間全体に対する作業を調べてからクライアントを NIS+ に移行すると、大抵の場合安定した実装を行うことができます。

NIS サーバーを NIS+ ドメインに割り当てて、各サーバーの役割 (マスタまたは複製) を明らかにしてください。NIS+ サービスへの移行を計画しているサーバーを指定したら、それらを NIS+ の要件に合わせてアップグレードしてください。 (「サーバーメモリーの容量」を参照)