test

NIS+ への移行

第 1 章 概要

この章では、ネットワーク情報サービス (NIS) からネットワーク情報サービスプラス (NIS+) へ移行する場合の問題点について説明します。ここでは、2 つのネームサービスの違いについて説明し、推奨する移行方法の概要を示します。

NIS と NIS+ の相違

NIS と NIS+ の間には相違点がいくつかあり、移行に大きな影響を与えます。たとえば、NIS は、1 つのドメイン (またはいくつかの別々のドメイン) を持つ平坦な、階層型ではない名前空間を使用しますが、NIS+ には、DNS に似たドメイン階層があります。つまり、NIS+ に変換する前に、NIS+ の名前空間を設計する必要があることを意味します。また、 NIS+ にはセキュリティを強化するための機能があり、これにより、名前空間内の情報だけでなく、名前空間の構造的な構成要素へのアクセスも制限されます。

こういった相違点は、NIS+ が、単に NIS をアップグレードしたものではなく、完全に新しい製品であることを示しています。したがって、NIS から NIS+ へ移行するポイントは、主にこれらの製品間の相違が中心になります。

この章では、これらの相違点を、次に示す一般的な用語を使って説明します。NIS+ への移行を正しく行うには、これらの用語を理解することが重要です。

ドメインの構造

NIS+ は、NIS を単にアップグレードするものではなく、NIS に置き換わるものとして設計されています。このことは、NIS+ のドメイン構造を調べると明らかです。NIS のドメインは平坦で、階層を持つことができません。これに対して、NIS+ のドメインは平坦な場合もありますが、階層構造のドメインを作成することもできます。この階層は、ルートドメインと、その下の任意の数のサブドメインから構成されます。

NIS のドメイン構造は、1980 年代に一般的であったクライアントとサーバー間のコンピューティングネットワークの管理の要件に対応したものでした。つまり、数百のクライアントと少数の多目的サーバーを持つ、クライアントとサーバー間のネットワークを対象としていました。

NIS+ が対象としているネットワークは、世界中のサイト内で、10〜100 台の専用サーバーによってサポートされる、100〜10000 台の複数のベンダ製のクライアントが接続されており、また、いくつかの「信頼性の低い」公衆ネットワークに接続されています。このようなネットワークの規模と構成を維持するには、新しい独立した管理方式が必要です。NIS+ のドメイン構造は、次の図に示すように、DNS のドメイン構造に似ています。

図 1-1 NIS+ のドメイン

Graphic

ドメインを階層構造にすると、規模の小さいものから非常に大きいものまで、広い範囲のネットワークに NIS+ を使用することができます。また、NIS+ のサービスを、組織の成長に対応させることもできます。NIS+ ドメインの構造の詳細については、『Solaris ネーミングの管理』を参照してください。

DNS、NIS、および NIS+ の相互運用性

NIS+ が提供する相互運用性とは、NIS からの移行と、NIS サービスによって提供されていた DNS とを継続して併用できることを意味します。 NIS+ には、NIS からの移行に役立つ、NIS 互換モードと情報転送ユーティリティがあります。TNIS 互換モードを使用すると、Solaris オペレーティング環境 のソフトウェアを実行する NIS+ サーバーは、NIS クライアントからの要求に応じる一方で、NIS+ クライアントからの要求にも引き続き応じることができます。情報転送ユーティリティにより管理者は、NIS のマップと NIS+ のテーブルを同期させることができます。

NIS 互換モードの設定に必要な手順は、標準 NIS+ サーバーで使用する手順と若干異なります。また、NIS 互換モードは、NIS+ 名前空間内のテーブルとセキュリティ上の関連を持っています。手順の違いとセキュリティとの関連については、『Solaris ネーミングの設定と構成』および『Solaris ネーミングの管理』を参照してください。

NIS+ サーバーが NIS 互換モードで実行されている場合、NIS のクライアントコンピュータは、 NIS+ のクライアントコンピュータとは異なる方法で、NIS+ 名前空間にアクセスします。次にこの違いを示します。

Solaris 2.3 以降のリリースでは、NIS 互換モードで DNS 転送をサポートします。Solaris 2.2 リリースでは、DNS 転送を可能にする「パッチ (patch #101022-06)」が提供されています。DNS 転送を可能にするパッチは、Solaris 2.0 と 2.1 では利用できません 。

NIS+ ドメインは、Internet に直接接続することはできませんが、ネームサービススイッチによって、NIS+ クライアントマシンを Internet に接続することはできます。クライアントは、そのスイッチ構成ファイル (/etc/nsswitch.conf) を設定して、NIS+ テーブルだけでなく、DNS ゾーンファイル、または、NIS マップ-の情報を検索することもできます。

サーバーの構成

NIS+ のクライアント-サーバー構成は、各ドメインが複数のサーバーによってサポートされているという点で、NIS と DNS の構成に似ています。メインサーバーは「 マスタサーバー」と呼び、バックアップサーバーは「複製サーバー」と呼びます。マスタサーバーも複製サーバーも NIS+ サーバーソフトウェアを実行し、どちらも NIS+ テーブルを持ちます。

ただし、NIS+ は、NIS とはまったく異なる、データベースの更新方法を使用します。NIS が開発された時点では、NIS が格納する情報のほとんどが静的なものと想定されていました。したがって、NIS の変更は手作業で処理し、そのマップ内の情報が変更されるたびに、マップを作成しなおし、すべてを伝達させる必要があります。

これに対して NIS+ では、複製サーバーに対して変更分だけの更新ができます。マスタサーバー上のマスタデータベースに変更を行う必要はありますが、一度行った変更は、複製サーバーにも自動的に伝達されます。「make」マップを再度作成したり、情報が伝達されるまで何時間も待つ必要はありません。伝達は、3、4 分程度で終了します。

情報の管理

NIS+ は、マップやゾーンファイルではなく、「テーブル」に情報を格納します。NIS+ には、図 1-2 に示すように、17 種類の定義済みテーブル、つまり システムテーブルがあります。

図 1-2 NIS+ の標準テーブル

Graphic

NIS+ テーブルは ASCII ファイルではなく、NIS+ リレーショナルデータベース内のテーブルです。NIS+ テーブルの内容を表示したり、編集できるのは、NIS+ のコマンドを通してだけです。

NIS+ テーブルには、NIS で使用したマップに比べて大きく改善された機能が 2 つありますその 1 つは、NIS+ テーブルを、最初の列 (「キー」とも呼ぶ) だけでなく、任意の検索可能な列によって検索できるという機能です。特定の列が検索可能であるかどうかを知るには、テーブルに対して niscat -o コマンドを実行してください。コマンドは、そのテーブルの列と属性のリストを返します。この検索機能により、NIS によって使用される hosts.byname マップと hosts.byaddr マップのような、重複するマップを持つ必要性がなくなります。もう 1 つは、NIS+ テーブル内の情報に対して、テーブルレベル、エントリ (行) レベル、列レベルという 3 つのレベルでアクセスを制御できることです。

NIS マップはサーバーのディレクトリ /var/yp/domainname に置かれるのに対して、NIS+ ディレクトリは /var/nis/data に置かれます。NIS+ テーブルはデータベースの中に格納されます。テーブルの情報は、データベースへの要求が出されると、メモリーに読み込まれます。データを要求された順序でメモリーに保存すると、ディスクへのアクセスを最小限に抑えられるため、要求への応答時間を短縮することができます。

セキュリティ

NIS+ のセキュリティ機能は、名前空間の情報と名前空間そのものの構造を、不正なアクセスから保護します。NIS+ のセキュリティ機能は、「 認証」と「承認」という 2 つの手段によって行われます。認証とは、NIS+ サーバーが、特定の要求を送信した NIS+ の「主体」(クライアントユーザーまたはクライアントワークステーション) を識別する処理を指します。承認とは、サーバーが、その主体 (クライアントマシンまたはクライアントユーザー) に許可されたアクセス権を識別する処理を指します。

つまり、最高レベルの NIS+ セキュリティ機能がサイトに導入されている場合、名前空間内の情報にアクセスするには、認証された NIS+ クライアントでなければならず、その情報にアクセスするための適切なアクセス権を持っていなければなりません。さらに、名前空間へのアクセス要求は、NIS+ のクライアントライブラリルーチンか、NIS+ の管理コマンドのどちらかによって行われた場合にだけ有効になります。また、NIS+ のテーブルと構造を直接編集することはできません。

推奨する移行手順

NIS から NIS+ への移行において、推奨する移行手順の概略を次に示します。

  1. 基本的な移行の方針について確認します。

  2. NIS+ について理解します。

  3. 最終的な NIS+ 名前空間を設計します。

  4. セキュリティの方式を選択します。

  5. NIS 互換モードの使用方法を決定します。

  6. 移行の準備を完了します。

  7. 移行を実行します。

この章の以下の部分では、上記の手順の各段階について詳しく説明します。

移行の方針

移行を開始するにあたって、次に示す基本的な方針を確認してください。

移行をすぐに実行するのではなく、別の方法を考慮する

Solaris オペレーティング環境への移行を完全に終えるまで、NIS+ へのアップグレードを延ばすことができます。これにより、Solaris オペレーティング環境への移行中は、その移行作業だけに専念できます。NIS+ への移行を行える準備ができるまでは、Solaris オペレーティング環境により継続して NIS を実行することができます。

処理を簡略化する

いくつかの手順により、移行を簡略にすることができます。これらの手順を実行すると、NIS+ の効果は減少しますが、サーバーの台数は少なくて済み、管理に要する時間も減ります。移行が完了すれば、NIS+ の設定を変更して、サイトの要求に完全に適合させることができます。次にいくつかの推奨事項を示します。

1 種類のソフトウェアリリースを使用する

Solaris オペレーティング環境のソフトウェアと NIS+ のどのバージョンを移行に使用するかを決定します。各バージョン間には若干の違いがあるため、複数のバージョンを同時に使用すると、移行の処理が不必要に複雑になります。Solaris 製品の 1 バージョンだけを選択して、それに対応するバージョンの NIS+ を使用してください。

現在のリリースは、設定スクリプトなどのほとんどの機能を備えています。通常の操作に必要な Solaris release 2.6 のパッチを用意し、すべてのサーバーとクライアントに同じパッチがインストールされていることを確認してください。

クライアントユーザーへの影響を最小限に抑える

クライアントユーザーに関して、2 つの考慮すべき点があります。1 つは、ユーザーがサービスの変更に気が付かないようにするということです。もう 1 つは、移行作業そのものがユーザーに与える混乱を最小限に抑えるということです。2 番目のポイントについては、ユーザーに移行作業を要求するのではなく、必ず各ドメインの管理者がそのクライアントマシンの NIS+ への移行作業を行うようにすれば解決できます。これにより、正しい手順が実行され、その手順がクライアントマシン全体でも一貫して実行されます。したがって、問題があっても、管理者がただちに処理することができます。

禁止事項

NIS+ について理解する

NIS+ について、特にこの章で要約し、このマニュアルの後半で説明する概念をよく理解するようにしてください。「関連マニュアル」でとりあげたマニュアルを参照してください。

NIS+ を理解するための最もよい方法の 1 つは、プロトタイプの名前空間を作成することです。製品を実際に経験するということに優る方法はありません。システム管理者には、業務に支障をきたさないテスト環境での練習が必要です。

注 -

プロトタイプのドメインを、実際に使用する NIS+ 名前空間に使用しないでください。プロトタイプですべてを学んだら、そのプロトタイプは削除して、名前空間の構成上の問題が起こらないようにします。計画をすべて終えたら、新たに実際の名前空間を作成してください。

テストドメインを作成するときは、小規模の、管理しやすいドメインを作成してください。テストドメインの作成については、『Solaris ネーミングの設定と構成』を参考にしてください。『Solaris ネーミングの設定と構成』では、NIS 互換モードを設定した状態、または設定しない状態で、NIS+ セットアップスクリプトを使用して簡単なテストドメインとサブドメインを計画して作成する方法について説明しています。

注 -

NIS+ の名前空間を設定する場合、『Solaris ネーミングの設定と構成』の Part I で説明した NIS+ スクリプトの使用をお勧めします。この手順では、最初に NIS+ スクリプトを使用して、基本的な NIS+ 名前空間を設定します。続いて NIS+ コマンドセットを使用して、各自のニーズに合わせて名前空間をカスタマイズします。

最終的な NIS+ 名前空間を設計する

第 2 章「NIS+ 名前空間の設計」の指針に従って、最終的な NIS+ 名前を設計します。名前空間の設計中は、NIS からの移行によって生じる制限を気にする必要はありません。これらの制約は、最終的な NIS+ の目的を明確にしてから変更することができます。

セキュリティの方式を選択する

NIS+ のセキュリティは、ユーザーと管理者にとって非常に有益ですが、ユーザーにも管理者にも、より詳しい知識と設定作業が必要になります。 また、計画上の決定をいくつか行う必要もあります。第 3 章「NIS+ セキュリティ方法の選択」では、NIS+ セキュリティの持つ意味と、NIS+ 名前空間でセキュリティを使用する場合に必要な決定事項について説明します。

NIS 互換モードの使用方法を決定する

移行の間は、NIS と NIS+ の名前空間を並行して使用することは事実上避けられません。2 つの名前空間を同時に使用するには、さらに資源を追加する必要があるため、各サイトが二重のサービスを使用する時間、または名前空間内の二重サービスの適用範囲を減らす (たとえば、可能なかぎり多くのドメインを NIS+ に変換するなど) ように努めてください。

第 4 章「NIS 互換モードの使用方法」では、NIS 互換モードに関連する移行の問題を説明し、 NIS から、NIS 互換を経由して、NIS+ へ完全に移行する方法を示します。

移行の準備を完了する

上記で説明した計画上の決定のほかに、第 5 章「移行の準備」で説明するように、他にもいくつかの準備を行う必要があります。

移行を実行する

第 6 章「移行の実行」では、推奨される一連の手順を示して、それまでに計画した移行を実際に実行します。