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 のドメイン構造に似ています。
ドメインを階層構造にすると、規模の小さいものから非常に大きいものまで、広い範囲のネットワークに NIS+ を使用することができます。また、NIS+ のサービスを、組織の成長に対応させることもできます。NIS+ ドメインの構造の詳細については、『Solaris ネーミングの管理』を参照してください。
NIS+ が提供する相互運用性とは、NIS からの移行と、NIS サービスによって提供されていた DNS とを継続して併用できることを意味します。 NIS+ には、NIS からの移行に役立つ、NIS 互換モードと情報転送ユーティリティがあります。TNIS 互換モードを使用すると、Solaris 2.x のソフトウェアを実行する NIS+ サーバは、NIS クライアントからの要求に応じる一方で、NIS+ クライアントからの要求にも引き続き応じることができます。情報転送ユーティリティにより管理者は、NIS のマップと NIS+ のテーブルを同期させることができます。
NIS 互換モードの設定に必要な手順は、標準 NIS+ サーバで使用する手順と若干異なります。また、NIS 互換モードは、NIS+ 名前空間内のテーブルとセキュリティ上の関連を持っています。手順の違いとセキュリティとの関連については、『Solaris ネーミングの設定と構成』および『Solaris ネーミングの管理』を参照してください。
NIS+ サーバが NIS 互換モードで実行されている場合、NIS のクライアントコンピュータは、 NIS+ のクライアントコンピュータとは異なる方法で、NIS+ 名前空間にアクセスします。次にこの違いを示します。
NIS+ サーバ上で rpc.nisd に -Y -B オプションを付けて実行している場合、NIS+ サーバ内で解決できない、NIS のクライアントマシンからのホスト要求を DNS に転送することができます。しかし、NIS+ クライアントからのこのような要求は転送されません。NIS+ クライアントマシンの DNS 要求の転送は、/etc/resolv.conf ファイルと /etc/nsswitch.conf ファイルの構成によって制御されます。詳細については、『Solaris ネーミングの管理』 を参照してください。
許可を持つ NIS+ の管理者は、passwd コマンドを使用して、パスワードの有効期限やロックの設定など、パスワードに関連するすべての管理業務を実行できます。NIS+ クライアントのユーザは、passwd コマンドを使用して、自分自身のパスワードを変更できます。
ローカルサブネット上のすべてのサーバが応答しなくなった場合でも、NIS+ クライアントマシンは、そのドメインの複製サーバのどれかと通信できれば、そのネームサービスの呼び出しに応答を得ることができます。NIS クライアントマシンは、サーバ名が設定されていないと、そのサブネットの外部にあるネットワーク上の情報にアクセスすることができません。サーバ名は、ypset によって、または Solaris 2.x の NIS クライアントの場合には ypset サブネットの外部にあるネットワーク上の情報にアクセスする によって設定されます。
NIS クライアントマシンは、受信中のデータが、承認された NIS サーバから送信されたものかどうかについては確認できません。これに対して、承認された NIS+ クライアントでは、承認された NIS+ サーバからデータが送信されていることを確認できます。
NIS のもとでは、サーバが応答しなくなると、NIS の yp_match() 呼び出しは、サーバが応答して要求に応じるまで、この呼び出しを試行し続けます。NIS+ の API (アプリケーションプログラムインタフェース) では、このような事態が発生すると、アプリケーションに対してエラーメッセージを返します。
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 種類の定義済みテーブル、つまり システムテーブルがあります。
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+ のテーブルと構造を直接編集することはできません。