Solaris ネーミングの管理

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

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

NIS の初期設定と構成の方法については、『Solaris ネーミングの設定と構成』を参照してください。

NIS の概要

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

システム管理者はネットワーク情報サービスを動作させることにより、「マップ」と呼ばれる管理データベースをさまざまなサーバー (「マスター」と「スレーブ」) に分散でき、またこれらの管理データベースを一元管理により自動的かつ確実な方法で更新できます。したがって、すべてのクライアントがネットワーク全体において一貫した方法で同じネームサービス情報を共有できます。NIS の概要および背景の詳細は、「NIS とは」を参照してください。

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


注 -

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


NIS アーキテクチャ

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

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

Graphic

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

Graphic

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

NIS と NIS+

NIS と NIS+ は、いくつかの同じ作業を行います。ただし NIS+では、NIS では提供されない階層ドメイン、名前空間セキュリティ、その他の機能が使用できます。NIS と NIS+ の相違点の詳細は、「NIS+ と NIS の違い」を参照してください。

NIS 管理者は、以下に示す原則および条件下で NIS を NIS+ と共に使用できます。

さまざまなネームサービス情報を取得するためにマシンがどのサービスを使用するかは、そのマシンの nsswitch.conf ファイルで制御されます。このファイルは、「スイッチ」ファイルと呼ばれています。詳細は、第 2 章「ネームサービススイッチ」を参照してください。

NIS と FNS

ある特定の状況では、FNS コマンドを使用して NIS クライアントは、ファイルシステムやプリンタの自分に関係のあるネーム情報を更新します。詳細は、「NIS クライアントが SKI の実行中 FNS によってコンテキストを更新する」を参照してください。

NIS マシンのタイプ

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

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

NIS サーバー

NIS サーバーは、ネットワーク上のマシンおよびアプリケーションが使用可能な一群のマップを保存するマシンと定義されています。NIS サーバーは、FNS ファイルサーバーと同じマシンである必要はありません。

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

NIS 管理者は、ドメインに別の NIS サーバーをスレーブサーバーとして指定できます。各スレーブサーバーには、マスターサーバーの一群の NIS マップの完全なコピーが存在します。マスターサーバーの一群の NIS マップが更新されると、必ずこれらの更新がスレーブサーバーに反映されます。スレーブサーバーの存在によりシステム管理者は、NIS リクエストへの応答で発生する負荷を均等に分散できます。スレーブサーバーはまた、マスターサーバーが使用不可になったときの影響を最小限に抑えます。

通常、すべての NIS マップに対して 1 つのマスターサーバーを指定します。ただし、各 NIS マップ内にマスターサーバーのマシン名が符合化されているので NIS 管理者は、マスターサーバーおよびスレーブサーバーとして動作するように、異なる複数のマップに対して異なる複数のサーバーを指定することもできます。ただし、ある 1 つのサーバーをある 1 つのマップのマスターサーバーとして指定し、別のサーバーを別のマップのマスターサーバーとして指定するといったランダムな指定は、管理上、非常に大きな混乱を発生させる可能性があります。したがって、1 つのドメイン内に NIS 管理者が作成するすべてのマップに対して、1 つのサーバーをマスターサーバーとして指定することが最良です。この章の例では、1 つのサーバーがドメイン内のすべてのマップのマスターサーバーとなっています。

NIS クライアント

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

NIS サーバーはまた、多くの場合にクライアントともなっています。NIS クライアントの作成方法については、ypbind(1M) のマニュアルページを参照してください。

NIS の要素

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

NIS ドメイン

NIS「ドメイン」は、共通な一群の NIS マップを共有するマシンの集合です。各ドメインはドメイン名を持っており、共通な一群の NIS マップを共有する各マシンは指定されたドメインに属します。ドメイン名は、大文字と小文字を区別します。

どのマシンも指定されたドメインに属することができます。ただしこれは、そのドメインのマップに対するサーバーが同一ネットワーク上に存在する場合に限ります。Solaris 2.x を動作しているマシンの場合はサーバーが同一サブネット上に存在する必要はありませんが、先行する NIS インプリメンテーションでは 1 つのサーバーが NIS が使用されている各サブネットに存在している必要がありました。NIS クライアントマシンはドメイン名を取得し、NIS サーバーにブートプロセスの一部としてバインドされます。

NIS デーモン

NIS サービスは、表 18-1 に示されている 5 つのデーモンで提供されます。

表 18-1 NIS デーモン

デーモン 

機能 

ypserv

サーバープロセス 

ypbind

バインドプロセス 

ypxfr

高速マップ転送 

rpc.yppasswdd

NIS パスワード更新デーモン 

rpc.ypupdated

他のマップ (publickey など) を更新します

NIS ユーティリティ

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

表 18-2 NIS ユーティリティ

ユーティリティ 

機能 

makedbm

NIS マップの dbm ファイルを作成する

ypcat

マップのデータを一覧表示する 

ypinit

NIS データベースの作成、インストール、および NIS クライアントの ypservers リストの初期化を行う

yppmatch

マップの特定エントリを検索する 

yppoll

サーバーからマップ順序番号を取得する 

yppush

データを NIS マスターサーバーから NIS スレーブサーバーに反映させる 

ypset

特定サーバーにバインドを設定する 

ypwhich

NIS サーバー名およびニックネーム変換テーブルを表示する 

ypxfr

NIS マスターサーバーから NIS スレーブサーバーにデータを転送する 

NIS マップ

NIS は、マップと呼ばれている一群のファイルに情報を保存します。

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

NIS マップは、Solaris データベースのインプリメンテーションの 1 つのタイプです。他のタイプはこのタイプとは必ずしも重複しておらず、一般に /etc ディレクトリ、DNS リソースレコード (RR) 、NIS+ テーブルに存在するファイルです。

NIS マップの概要

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

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

NIS Makefile は、インストール時に NIS サーバーとして指定されたマシンの /var/yp ディレクトリに保存されます。このディレクトリで make を実行すると、makedbm が入力ファイルからデフォルトの NIS マップを作成または更新します。このプロセスを使って NIS 名前空間を初期設定する方法については、『Solaris ネーミングの設定と構成』を参照してください。


注 -

スレーブサーバー上でマップを作成しないでください。マップを作成する場合は、必ずマスターサーバー上で make を実行してください。


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

デフォルトの NIS マップ

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

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

表 18-3 NIS マップに関する説明

マップ名 

対応する NIS 管理ファイル 

説明 

bootparams

bootparams

ブート時にクライアントが必要とするファイルのパス名 (ルート、スワップ、その他) を含む 

ethers.byaddr

ethers

マシン名と Ethernet アドレスを含む。マップのキーは、Ethernet アドレス 

ethers.byname

ethers

ethers.byaddr と同じ。ただしキーは、Ethernet アドレスではなくマシン名

group.bygid

group

グループセキュリティ情報を含む。キーはグループ ID 

group.byname

group

グループセキュリティ情報を含む。キーはグループ名 

hosts.byaddr

hosts

マシン名と IP アドレスを含む。キーは IP アドレス 

hosts.byname

hosts

マシン名と IP アドレスを含む。キーはマシン (ホスト) 名  

mail.aliases

aliases

別名とメールアドレスを含む。キーは別名 

mail.byaddr

aliases

メールアドレスと別名を含む。キーはメールアドレス 

netgroup.byhost

netgroup

グループ名、ユーザー名、マシン名を含む。キーはマシン名 

netgroup.byuser

netgroup

netgroup.byhost と同じ。ただし、キーはユーザー名

netgroup

netgroup

netgroup.byhost と同じ。ただし、キーはグループ名

netid.byname

passwd, hosts

group

UNIX スタイルの認証に使用される。マシン名とメールアドレスを含む (ドメイン名も含む)。netid ファイルが使用可能な場合は、他のファイルの使用可能データーに加えて、netid ファイルも検索する

netmasks.byaddr

netmasks

IP 送出時に使用するネットワーを含む。キーはアドレス 

networks.byaddr

networks

システムに認識されているネットワーク名、および IP アドレスを含む。キーは IP アドレス 

networks.byname

networks

networks.byaddr と同じ。ただし、キーはネットワーク名

passwd.adjunct. byname

passwdshadow

C2 クライアントに関する監査情報および隠されたパスワード情報を含む 

passwd.byname

passwdshadow

パスワード情報を含む。キーはユーザー名 

passwd.byuid

passwdshadow

passwd.byname と同じ。ただし、キーはユーザー ID

protocols.byname

protocols

システムに認識されているネットワークプロトコルを含む 

protocols.bynumber

protocols

protocols.byname と同じ。ただし、キーはプロトコル番号

rpc.bynumber

rpc

システムに認識されている RPC のプログラム番号と名前を含む。キーは RPC のプログラム番号 

services.byname

services

ネットワークに認識されているインターネットサービスを一覧表示する。キーはポートまたはプロトコル 

services.byservice

services

ネットワークに認識されているインターネットサービスを一覧表示する。キーはサービス名 

ypservers

N/A 

ネットワークに認識されている NIS サーバーを一覧表示する 

NIS マップの使用

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

たとえば、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 の詳細は、ypwhich(1) のマニュアルページを参照してください。

NIS マップのニックネーム

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

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

NIS 関連コマンドについてのまとめ

NIS サービスには、特殊なデーモン、システムプログラム、コマンドが含まれています。これらのコマンドについては、表 18-4 にまとめられています。これらの各コマンドの使い方の詳細は、それぞれ該当するマニュアルページを参照してください。

表 18-4 NIS コマンドについてのまとめ

コマンド 

説明 

ypserv

NIS クライアントが要求する NIS マップの情報を提供します。ypserv は、完全な一群のマップが存在する NIS サーバー上で動作するデーモン。NIS サービスが機能するには、少なくとも 1 つの ypserv デーモンがネットワークに存在する必要がある

ypbind

クライアントに NIS サーバーバインド情報を提供する。ypbind は、要求元クライアントのドメイン内のマップにサービスを提供する ypserv プロセスを見つけてバインドを行う。ypbind はすべてのサーバーおよびクライアント上で実行される必要がある

ypinit

自動的に入力ファイルから NIS サーバーのマップを作成する。ypinitはまた、クライアント上に /var/yp/binding/domain/ypservers 初期ファイルを作成する際にも使用される。NIS マスターサーバーおよび NIS スレーブサーバーを初めて設定する場合は、ypinit を使用する

make

Makefile を読み込むことで NIS マップを更新する (make/var/yp ディレクトリで実行した場合)。make を使うと、入力ファイルに基づいてすべてのマップを更新したり、個々のマップを更新したりできる。NIS の make の機能については、ypmake(1M) のマニュアルページで説明されている

makedbm

makedbm は入力ファイルを取得し、これを dbm.dir および dbm.pag ファイルに変換する (これらのファイルは、NIS がマップとして使用できる有効な dbm ファイル)。また、makedbm -u と入力すると、マップを分解できる。したがって、NIS 管理者は、マップを構成するキーと値のペアを参照できる

ypxfr

NIS 自体を転送媒体として使い、NIS マップをリモートサーバーから /var/yp/domain ローカルディレクトリに取り込む。NIS 管理者は ypxfr を対話形式で実行したり、crontab ファイルから定期的に実行したりできる。また、ypxfrypserv によって呼び出されると、転送が開始される

ypxfrd

ypxfr リクエスト (一般にスレーブサーバーで発生する) に対してマップ転送サービスを提供する。ypxfr は、マスターサーバー上でだけ動作する

yppush

NIS マップの新バージョンを NIS マスターサーバーからそのスレーブにコピーする。yppush の実行は、NIS マスターサーバー上で行う

ypset

指定された NIS サーバーにバインドするように ypbind プロセスに要求する。ypset は、セキュリティの関係上、通常のオペレーションで気軽に使用できるようには設計されていない。したがって、ypset はできる限り使用しない。ypbind プロセスの ypset および ypsetme オプションについては、ypset(1M) および ypbind(1M) のマニュアルページを参照

yppoll

指定されたサーバー上で NIS マップのどのバージョンが動作しているかを通知する。yppoll はまた、NIS マップのマスターサーバーを一覧表示する

ypcat

NIS マップの内容を表示する 

ypmatch

NIS マップ内の指定された 1 つ以上のキーの値をプリントする。NIS 管理者は、NIS サーバーマップのバージョンを指定することはできない 

ypwhich

現在どの NIS サーバーをクライアントが使用して NIS サービスを取得しているかを表示する。また、-m mapname オプションを指定して起動した場合は、どの NIS サーバーが各マップのマスターサーバーかが表示される。-m だけを指定した場合は、使用可能なすべてのマップ名、およびこれらのマップのマスターサーバーが表示される

NIS のバインド

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

サーバーリストモード

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

  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 はデフォルトとしてローカルマシン (コマンドが実行されるマシン) を使用します。

NIS 旧バージョンとの相違点

Solaris 8 リリース の NIS の特徴は、次のとおりです。

NSKit が存在しない

NIS サービスは、2.6 以前の Solaris リリースには組み込まれていませんでした。NIS サービスは今までは、個別販売される NSKit からインストールしなければなりませんでした。現在、NIS サービスは Solaris 8 リリースに組み込まれています。したがって、Solaris 7 以降のリリース には NSKit は存在しません。

Solaris 7 以降のリリースには NIS サービスが組み込まれたので、SUNWnsktu および SUNWnsktr パッケージはもはや存在しません。NIS のインストールは、NIS サーバークラスタにより行われています (NIS には SUNWypu および SUNWypr パッケージが含まれています) 。

NIS サービスは現在、/etc/init.d/yp スクリプトでは起動されません。/etc/init.d/yp スクリプトは現在、存在しません。Solaris 8 リリース では、まずマスターサーバーの NIS マップを ypinit スクリプトで作成し、次に ypstart で NIS を起動してください。NISサービスの停止は、ypstop コマンドで行われます。

ypupdated デーモン

ypupdated デーモンは、NSKit の 2.6 以前のバージョンには組み込まれていませんでしたが、Solaris 7 以降のリリース には組み込まれいます。

/var/yp/securenets

/var/yp/securenets ファイルは、Solaris 8 リリース でも Solaris 7 以前の NSKit リリースの場合と同様に、NIS サービスへのアクセスを制限するために使用されます。このファイルが NIS サーバーに存在する場合は、この NIS サーバーは照会に答えたり、ファイルに収められている IP アドレスのマシンおよびネットワークへのマップを与えたりするだけです。ファイルのフォーマットについては、securenets(4) のマニュアルページを参照してください。

securenets ファイルの例を以下に示します。


255.255.255.0 13.13.13.255
host    13.13.14.1
host    13.13.14.2

上記において 255.255.255.0 はネットマスクで、13.13.13.255 はネットワークアドレスです。1 行目のセットアップに関しては、ypserv はサブネットの 13.13.13.255 の範囲のこれらのアドレスにのみ応答します。/var/yp/securenets ファイルのエントリを変更したときは、ypservypxfrd のデーモンを終了させて再起動をする必要があります。

マルチホームマシンのサポート

ypserv プロセスは、Solaris.8 リリース でも Solaris 7 以前の NSKit リリースの場合と同様に、複数のネットワークアドレスを持つマシンをサポートします。マシンマップが作成されると、Makefile は、複数のアドレスを持つマシンのマップに YP_MULTI_HOSTNAME エントリを作成します。このエントリには、そのマシンのすべてのアドレスがリストされます。マシンアドレスが必要な場合は、このリストに存在するアドレスのなかで、希望するアドレスに最も近いアドレスを使用しようとします。詳細は、ypserv(1) のマニュアルページを参照してください。

希望するアドレスに最も近いアドレスの判断は算術的判断なので、アドレスの妥当性検査は行われません。たとえば、マルチホームマシンが 6 つの IP アドレスを持っているが、このマルチホームマシン上の 5 つのインタフェースだけが正常に動作していると仮定します。このマルチホームマシンに直接接続されていないネットワーク上のマシンは、ypserv からダウンインタフェースの IP アドレスを受け取ることができます。したがって、この仮説上のクライアントはマルチホームマシンにアクセスできません。


注 -

マルチホームマシンのすべてのアドレスは、通常、アクティブでなければなりません。特定のアドレスまたはマシンでサービスが提供できなくなる恐れがある場合は、そのアドレスまたはマシンは NIS マップから削除してください。


SunOS 4.x 互換モード

Solaris 8 リリースの NIS は、パスワード構成ファイルを SunOSTM 4.x (Solarisリリース 1) フォーマットおよび Solaris リリース 2 のパスワードファイルフォーマットおよびシャドウファイルフォーマットの両方でサポートしています。

動作モードは、$PWDIR/shadow ファイルが存在するか否かによって決定されます ($PWDIR は、/var/yp/Makefile ファイルに設定されている Makefile マクロセットです) 。shadow ファイルが存在する場合は、NIS は Solaris リリース 2 モードで動作します。shadow ファイルが存在しない場合は、NIS は SunOS 4.x モードで動作します。

SunOS 4.x モードでは、すべてのパスワード情報は passwd ファイルに保存されています。Solaris リリース 2 モードでは、パスワード情報は shadow ファイルに保存され、ユーザー課金情報は passwd ファイルに保存されます。

make マクロ PWDIR/etc ディレクトリに設定された場合は、Solaris リリース 2 の passwd 処理要件の関係上、NIS は Solaris リリース 2 モードでしか動作できません。しかし、PWDIR/etc 以外のディレクトリに設定されている場合は、ユーザーは passwd 構成ファイルを SunOS 4.x フォーマットでも Solaris リリース 2 フォーマットでも保存できます。rpc.yppasswdd デーモンはこれら両方のパスワードフォーマットを認識しますが、Solaris リリース 2 フォーマットを使用することをお勧めします。

ネームサービススイッチの使用

ネームサービススイッチは、ネームサービス管理を単純化することを目的としています。クライアントマシンおよびアプリケーションは、このスイッチを使用してネームサービスを選択します。スイッチメカニズムは、/etc/nsswitch.conf ファイルを使って実現されます。このファイルは、各情報タイプを参照するために使用されるリソースを指定します。

この節では、NIS オペレーションに関するネームサービススイッチを正しく作成するために必要な要素についてだけ説明します。nsswitch.conf ファイルの詳細は、第 2 章「ネームサービススイッチ」を参照してください。

nsswitch.conf ファイルは、Solaris 8 リリースソフトウェアによって自動的に各マシンの /etc ディレクトリにロードされます。この際、以下に示す 3 つの代替 (テンプレート) バージョンも一緒にロードされます。

これらの代替テンプレートファイルには、NIS+ サービス、NIS、ローカルファイルで使用されるデフォルトのスイッチ構成が入っています。(「nsswitch.conf テンプレートファイル」を参照してください。) DNS ではデフォルトのファイルは提供されませんが、これらの代替テンプレートファイルを編集することで DNS の使用が可能になります (「NIS クライアントでの DNS 転送」を参照)。

このスイッチ機能は SunOS 4.x 上には存在しません。したがって、4.x クライアントへの DNS 転送は、NIS サーバー上で行われなければなりません。この状況下で 4.x クライアントが、NIS サーバーの NIS マップにリストされていないホストに対して情報を要求した場合は、NIS サーバーはこの要求を DNS サーバーに転送します。

Solaris87 リリースソフトウェアがまずマシンにインストールされると、インストーラはマシンのデフォルトのネームサービス (NIS+、NIS、またはローカルファイル) を選択します。インストール時には、対応するテンプレートファイルが /etc/nsswitch.conf にコピーされます。NIS が使用されているクライアントマシンの場合は、インストール時には nsswitch.nisnsswitch.conf にコピーされます。NIS データベースの設定が普通に行われていれば、NIS オペレーションにおいては、nsswitch.conf にコピーされたデフォルトの /etc/nsswitch.nis テンプレートファイルで十分です。

NIS 管理者は、クライアントマシンのネーミングシステム (/etc、NIS、または NIS+) を別のネーミングシステムに変更する場合は、対応するテンプレートファイルを nsswitch.conf にコピーしてください。NIS 管理者はまた、/etc/nsswitch.conf ファイルの該当行を編集することによって、クライアントが使用する特定タイプのネットワーク情報の発信元を変更できます。『Solaris ネーミングの設定と構成』、および本書の第 2 章「ネームサービススイッチ」を参照してください。


注意 - 注意 -

/etc/nsswitch.conf ファイルが files (nis ではない) に設定されており、サーバーが /etc/hosts ファイルに存在しない場合は、ypcat コマンドは次のようなエラーメッセージを出します。「RPC failure: "RPC failure on yp operation"