第 4 章 ネットワーク情報サービス (NIS) (概要)

この章では、ネットワーク情報サービス (NIS) の概要について説明します。

NIS とは分散型ネームサービスであり、ネットワーク上のオブジェクトおよびリソースを識別し、探索するメカニズムです。NIS は、ネットワーク全体の情報に関する一様な記憶領域と検索方法を、トランスポートプロトコルやメディアに依存しない形式で提供します。

この章の内容は次のとおりです。

• 「NIS の概要」

• 「NIS マシンのタイプ」

• 「NIS の要素」

• 「NIS のバインド」

NIS の概要

システム管理者は、NIS を実行することにより、「マップ」と呼ばれる管理データベースをさまざまなサーバー (「マスター」と「スレーブ」) に分散させることができます。さらに、これらの管理データベースを一元管理により自動的かつ確実な方法で更新できるため、どのクライアントもネットワーク全体を通して一貫した方法で同じネームサービス情報を共有できます。

NIS は DNS から独立して開発されたため、その焦点は少し異なっています。DNS は数値 IP アドレスの代わりにマシン名を使うことによって、通信を簡略化することに焦点を当てているのに対して、NIS の場合は、多様なネットワーク情報を集中管理することによりネットワーク管理機能を高めることに焦点を絞っています。NIS には、マシン名とアドレスだけでなく、ユーザー、ネットワークそのもの、ネットワークサービスについての情報も格納されます。このようなネットワーク「情報」の集まりを NIS の「名前空間」と呼びます。

「マシン」名の代わりに「ホスト」名が使われることがあります。この解説では「マシン」名が使われていますが、一部の画面メッセージまたは NIS マップ名では「ホスト」名または「マシン」名が使われています。

NIS アーキテクチャー

NIS はクライアントサーバー方式を使用します。NIS サーバーが NIS のクライアントへサービスを提供します。主サーバーは「マスター」サーバーと呼ばれ、信頼性を保証するためにバックアップつまり「スレーブ」サーバーを持っています。マスターサーバーとスレーブサーバーは、NIS の情報検索ソフトウェアを使い、NIS のマップを格納します。

NIS はドメインを使用して、マシン、ユーザー、およびネットワークをその名前空間に配置します。しかし、ドメイン階層を使用しないため、NIS の名前空間はフラットになっています。

したがって、上記のような物理ネットワークは、次のように 1 つの NIS ドメインに配置されます。

NIS だけを使っても、NIS ドメインをインターネットに直接接続することはできません。ただし、NIS を使用してインターネットへも接続したいと希望する組織では、NIS と DNS を組み合せることができます。その場合、NIS を使用してすべてのローカル情報を管理し、DNS を使用してインターネットのホストを検索できます。NIS は、NIS マップで情報が見つからない場合にホスト検索の機能を DNS へ転送する転送サービス機能を持っています。Solaris システムでは、ホスト検索要求を DNS だけに転送する、DNS で情報が見つからなければ次に NIS に転送する、あるいは NIS で情報が見つからなければ次に DNS に転送する、という切り替えも nsswitch.conf ファイルで設定できます。詳細については、第 2 章ネームサービススイッチ (概要)を参照してください。

NIS マシンのタイプ

NIS マシンには、次の 3 つのタイプがあります。

• マスターサーバー

• スレーブサーバー

• NIS サーバーのクライアント

NIS クライアントにはどのマシンでもなれますが、NIS サーバー (マスターまたはスレーブ) となるのはディスクが装備されているマシンだけです。一般にサーバーは、多くの場合はそのサーバー自身のクライアントでもあります。

NIS サーバー

NIS サーバーは、FNS ファイルサーバーと同じマシンである必要はありません。

NIS サーバーには、マスターサーバーとスレーブサーバーの 2 つの種類があります。マスターサーバーとして指定されているマシンには、NIS 管理者が必要に応じて作成、更新する一群のマップが保存されます。各 NIS ドメインには、マスターサーバーが 1 つだけ存在している必要があります。マスターサーバーは、パフォーマンスの低下を最小限に抑えながら NIS の更新をスレーブサーバーに伝播できます。

ドメインに別の NIS サーバーをスレーブサーバーとして指定できます。各スレーブサーバーには、マスターサーバーの NIS マップセットの完全なコピーが存在します。マスターサーバーの NIS マップが更新されると、必ずこれらの更新がスレーブサーバーに伝播されます。スレーブサーバーは、マスターサーバーからの要求のオーバーフローに対処して、「サーバー使用不可」エラーを最小限に抑えることができます。

通常、システム管理者はすべての NIS マップに対してマスターサーバーを 1 つ指定します。ただし、各 NIS マップ内ではマスターサーバーのマシン名が符合化されているので、異なる複数のマップに対して異なる複数のサーバーを、マスターサーバーやスレーブサーバーとして動作するように指定することもできます。管理の複雑さを最小限に抑えるには、1 つのドメイン内で作成されるすべてのマップに対して、マスターサーバーを 1 つだけ指定します。この章の例では、1 つのサーバーがドメイン内のすべてのマップのマスターサーバーとなっています。

NIS クライアント

NIS クライアントでは、サーバー上のマップのデータを要求するプロセスが動作します。各 NIS サーバーに保存されている情報は同じであるはずなので、クライアントではマスターサーバーとスレーブサーバーの区別は行われません。

Solaris オペレーティングシステムは、NIS クライアントとネイティブな LDAP クライアントが同一のクライアントマシン上に共存する構成をサポートしません。

NIS の要素

NIS ネームサービスは、次の要素から構成されています。

• ドメイン (「NIS ドメイン」を参照)

• デーモン (「NIS デーモン」を参照)

• ユーティリティー (「NIS ユーティリティー」を参照)

• マップ (「NIS のマップ」を参照)

• NIS コマンドセット (「NIS 関連コマンド」を参照)

NIS ドメイン

NIS「ドメイン」は、共通の NIS マップセットを共有しているマシンの集合です。各ドメインにはドメイン名が指定されており、共通の NIS マップセットを共有している各マシンがそのドメインに属しています。

どのマシンも指定されたドメインに属することができます。ただしこれは、そのドメインのマップに対するサーバーが同一ネットワーク上に存在する場合に限ります。NIS クライアントマシンは、ブートプロセス中にドメイン名を取得して、NIS サーバーにバインドします。

NIS デーモン

NIS サービスは、表 4–1 に示す 5 つのデーモンで提供されます。NIS サービスはサービス管理機能によって管理されます。このサービスに関する有効化、無効化、再起動などの管理アクションは svcadm コマンドを使用して実行できます。SMF の概要については、『Solaris のシステム管理 (基本編)』の第 18 章「サービスの管理 (概要)」を参照してください。また、詳細については、svcadm(1M) および svcs(1) のマニュアルページを参照してください。

rpc.yppasswdd は、r で始まるすべてのシェルを制限付きとみなします。たとえば、/bin/rksh で作業しているユーザーはそのシェルを別のシェルに変更できません。r で始まるシェルを持っているが、そのような制約を受けたくない場合は、第 7 章NIS のトラブルシューティングの対処方法を参照してください。

NIS ユーティリティー

NIS サービスは、表 4–2 に示す 9 つのユーティリティーでサポートされています。

NIS のマップ

NIS マップの情報は、ndbm フォーマットで保存されます。マップファイルのフォーマットについては、ypfiles(4) と ndbm(3C) のマニュアルページで説明しています。

NIS マップは、UNIX の /etc ファイルおよびほかの構成ファイルを置換するように設計されているので、名前およびアドレスよりはるかに多くの情報を保存できます。NIS が動作しているネットワーク上では、各 NIS ドメインの NIS マスターサーバーは、照会されるドメイン内のほかのマシンの NIS マップセットを保持します。NIS スレーブサーバーは、NIS マスターサーバーのマップのコピーを保持します。NIS クライアントマシンは、マスターサーバーまたはスレーブサーバーから名前空間情報を取得できます。

NIS マップは、本質的には 2 つの列からなるテーブルです。1 つの列は「キー」であり、もう 1 つの列はキーに関連する情報です。NIS は、キーを検索してクライアントに関する情報を見つけます。各マップでは異なるキーが使われるので、一部の情報はいくつかのマップに保存されます。たとえば、マシン名とアドレスは、 hosts.byname および hosts.byaddr という 2 つのマップに保存されます。サーバーがマシンの名前を持っており、そのマシンのアドレスを見つける必要がある場合は、サーバーは hosts.byname マップを調べます。サーバーがマシンのアドレスを持っており、そのマシンの名前を見つける必要がある場合は、サーバーは hosts.byaddr マップを調べます。

NIS Makefile は、インストール時に NIS サーバーとして指定されたマシンの /var/yp ディレクトリに保存されます。このディレクトリで make を実行すると、makedbm が入力ファイルからデフォルトの NIS マップを作成または更新します。

マップは必ずマスターサーバー上で作成してください。スレーブサーバーで作成したマップはマスターサーバーに自動的に格納されません。

デフォルトの NIS マップ

Solaris システムには、NIS マップのデフォルトセットが提供されています。システム管理者は、これらのマップをすべて使用することも一部だけを使用することもできます。また、ほかのソフトウェア製品のインストール時にシステム管理者が作成または追加したマップもすべて NIS で使用できます。

NIS ドメインのデフォルトのマップは、各サーバーの /var/yp/domainname ディレクトリに入っています。たとえば、test.com ドメインに属しているマップは、各サーバーの /var/yp/test.com ディレクトリにあります。

表 4–3 には、デフォルトの NIS マップ、これらの NIS マップに存在する情報、および NIS 動作時にソフトウェアが対応する管理ファイルを調べているか否かが示されています。

新しい ipnodes マップ (ipnodes.byaddr および ipnodes.byname) が、NIS に追加されました。このマップには、IPv4 アドレスと IPv6 アドレスの両方が格納されます。

Solaris 10 8/07 リリース以降、Solaris OS には 2 つの別個の hosts ファイルは存在しません。/etc/inet/hosts ファイルが唯一の hosts ファイルであり、この中に IPv4 と IPv6 の両方のエントリが含まれます。常に同期させる必要がある 2 つの hosts ファイル内の IPv4 エントリを維持管理する必要はありません。/etc/inet/ipnodes ファイルは、下位互換性のために、/etc/inet/hosts ファイルへの同名のシンボリックリンクに置き換えられています。

詳細は、hosts(4) のマニュアルページを参照してください。

NIS クライアントとサーバーは、IPv4 または IPv6 のどちらかの RPC トランスポートを使用して通信することができます。

ageing.byname マッピングには、yppasswdd によって使用される情報が含まれています。NIS から LDAP への移行時に、DIT とのパスワード有効期限情報の読み取りおよび書き込みのために使用されます。パスワードの有効期限を使用しない場合は、この情報をマッピングファイルからコメントアウトします。NIS から LDAP への移行の詳細については、第 15 章NIS から LDAP への移行 (概要と手順)を参照してください。

NIS マップの使用

NIS を使うと、/etc ファイルシステムを使った場合に比べ、ネットワークデータベースの更新がはるかに簡単になります。/etc ファイルシステムではネットワーク環境を更新するたびに各マシンの管理 /etc ファイルを変更する必要がありましたが、NIS ではこのような操作を行う必要はありません。

たとえば、NIS が動作しているネットワークに新しいマシンを追加する場合に必要なのは、マスターサーバーの入力ファイルを更新し、make を実行することだけです。これで、hosts.byname および hosts.byaddr マップが自動的に更新されます。次に、これらのマップはすべてのスレーブサーバーに転送され、ドメインのすべてのクライアントマシン、およびこれらのクライアントマシンのプログラムはこれらのマップを使用することが可能になります。クライアントマシンまたはアプリケーションがマシン名またはアドレスを要求すると、NIS サーバーは必要に応じて hosts.byname または hosts.byaddr マップを参照し、要求された情報をクライアントに送信します。

ypcat コマンドを使うと、マップの値を表示できます。ypcat の基本的な使用形式は、次のとおりです。

% ypcat mapname

mapname は、調べたいマップ名またはその「ニックネーム」です。ypservers の場合のようにマップがキーだけで構成されている場合は、ypcat -k と入力してください。ypcat -k と入力しない場合は、空白行が出力されます。ypcat のほかのオプションについては、ypcat(1) のマニュアルページに説明されています。

ypwhich コマンドを使うと、どのサーバーが特定のマップのマスターサーバーなのかを判定できます。次のように入力します。

% ypwhich -m mapname

mapname は、検索するマスターサーバーのマップ名またはニックネームです。mapname を入力すると、マスターサーバー名が表示されます。詳細については、ypwhich(1) のマニュアルページを参照してください。

NIS マップのニックネーム

「ニックネーム」は、マップのフルネームのエイリアスです。使用可能なマップのニックネーム (たとえば、passwd.byname の場合は passwd) を一覧表示するには、ypcat -x または ypwhich -x と入力してください。

ニックネームは、/var/yp/nicknames ファイルに保存されています。このファイルには、マップの完全指定名のあとに、マップのニックネームが空白で区切られて含まれています。ニックネームのリストは、追加または更新できます。ニックネーム数は現在、500 に制限されています。

NIS 関連コマンド

NIS サービスには、特殊なデーモン、システムプログラム、コマンドが含まれています。これらのコマンドについては次の表にまとめてあります。

NIS のバインド

NIS クライアントは、バインドプロセスにより NIS サーバーから情報を取得します。バインドプロセスは、サーバーリストおよび同報通信という 2 つのモードのどちらかで動作できます。

• サーバーリスト。サーバーリストモードでは ypbind プロセスは、/var/yp/binding/domain/ypservers リストでドメイン内のすべての NIS サーバー名を調べます。ypbindプロセスは、このファイルに存在するサーバーにだけバインドされます。このファイルは、ypinit -c を実行すると作成されます。

• 同報通信。ypbind プロセスはまた、RPC 同報通信を使ってバインドを開始できます。同報通信は、それ以上配信されない唯一のローカルサブネットイベントです。したがって、クライアントと同じサブネット上に少なくとも 1 つのサーバー (マスターまたはスレーブ) が存在しなければなりません。サーバーは、異なる複数のサブネット上に存在できます (マップはサブネット境界を超えて伝播されるため) 。サブネット環境での 1 つの一般的方法は、NIS サーバーとしてサブネットルーターを使用することです。この方法を使用すると、ドメインサーバーはどちらかのサブネットインタフェース上でクライアントにサービスを提供できます。

サーバーリストモード

サーバーリストモードでは、バインドプロセスは次のように動作します。

1. NIS マップで提供された情報を必要とする、NIS クライアントマシン上で動作しているプログラムが、ypbind にサーバー名を要求します。

2. ypbind が、/var/yp/binding/domainname/ypservers ファイルを調べてドメインの NIS サーバーリストを見つけます。

3. ypbind が、NIS サーバーリストの先頭サーバーへのバインドを開始します。先頭サーバーが応答しない場合、ypbind はサーバーが見つかるまで、あるいは NIS サーバーリストの最後に達するまで、2 番目以降のサーバーへのバインドを順に試みます。

4. ypbind が、どのサーバーにアクセスすべきかをクライアントプロセスに通知します。次に、クライアントプロセスが直接、サーバーに要求を送信します。

5. NIS サーバー上の ypserv デーモンが、該当するマップを調べて要求を処理します。

6. ypserv デーモンが、要求された情報をクライアントに送り返します。

同報通信モード

同報通信モードでは、バインドプロセスは次のように動作します。

1. 同報通信オプション (broadcast) が設定されている状態で ypbind を起動する必要があります。

2. ypbind が、RPC 同報通信を送出して NIS サーバーを探索します。

   ---

   注 –

   このようなクライアントをサポートするには、NIS サービスを要求している各サブネット上に 1 つの NIS サーバーが存在する必要があります。

   ---

3. ypbind が、同報通信に応答する先頭サーバーへのバインドを開始します。

4. ypbind が、どのサーバーにアクセスすべきかをクライアントプロセスに通知します。次に、クライアントプロセスが直接、サーバーに要求を送信します。

5. NIS サーバー上の ypserv デーモンが、該当するマップを調べて要求を処理します。

6. ypserv デーモンが、要求された情報をクライアントに送り返します。

通常、いったんクライアントがサーバーにバインドされると、何らかの原因でバインドが解除されるまではクライアントはサーバーにバインドされたままになります。たとえば、サーバーがサービスを提供できなくなると、このサーバーがサービスを提供していたクライアントは、新しいサーバーにバインドされます。

どの NIS サーバーが現在、特定クライアントにサービスを提供しているかを調べる場合は、次のコマンドを入力してください。

%ypwhich machinename

machinename は、クライアント名です。マシン名が指定されていない場合は、ypwhich はデフォルトとしてローカルマシン (コマンドが実行されるマシン) を使用します。