test

NIS+ への移行

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+ のテーブルと構造を直接編集することはできません。