test

Solaris のシステム管理 (ネーミングとディレクトリサービス : FNS、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+ のドメイン構造は、これらの要件を満たすように設計されています。NIS+ のドメイン構造は、次の図に示すように、DNS のドメイン構造に似ています。

図 26–1 NIS+ のドメイン

この図は、階層ドメイン構造を示しています。

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

DNS、NIS、NIS+ の相互運用性

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

NIS 互換モードの設定に必要な手順は、標準 NIS+ サーバーで使用する手順と若干異なります。また、NIS 互換モードは、NIS+ 名前空間内のテーブルとセキュリティ上の関連を持っています。

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

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

NIS+ ドメインは、インターネットに直接接続できません。ただし、NIS+ クライアントマシンは、ネームサービススイッチ経由でインターネットに接続できます。クライアントのスイッチ構成ファイル (/etc/nsswitch.conf) を設定して、NIS+ テーブル以外に、DNS ゾーンファイルまたは NIS マップの情報をクライアントから検索できます。

サーバーの構成

NIS+ のクライアント サーバー構成は、各ドメインが複数のサーバーによってサポートされているという点で、NIS と DNS の構成に似ています。メインサーバーは「マスターサーバー」と呼ばれ、バックアップサーバーは「複製サーバー」と呼ばれます。マスターサーバーと複製サーバーの両方で NIS+ サーバーソフトウェアが動作しており、NIS+ テーブルのコピーをともに維持しています。

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

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

情報の管理

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

図 26–2 NIS+ の標準テーブル

この図は、標準 NIS+ テーブルを示しています。

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