test

Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)

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

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

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

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

NIS の概要

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

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

注 –

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

NIS アーキテクチャ

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

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

この図は、階層構造が確認されていない 192.44.0.0 を示しています。

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

この図は、フラットな NIS 名前空間に配置された 192.44.0.0 を示しています。

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 サーバーは、FNS ファイルサーバーと同じマシンである必要はありません。

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

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

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

NIS クライアント

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

NIS の要素

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

NIS ドメイン

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

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

NIS デーモン

NIS サービスは、表 7–1 に示す 5 つのデーモンで提供されます。

表 7–1 NIS デーモン

デーモン 

機能 

ypserv

サーバープロセス 

ypbind

バインドプロセス 

ypxfr

高速マップ転送 

rpc.yppasswdd

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

** 下の注を参照 ** 

rpc.ypupdated

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

注 –

rpc.yppasswdd は、r で始まるすべてのシェルを制限付きとみなします。 つまり、r で始まるシェルを持っているユーザーが制約を受けます。たとえば、/bin/rksh で作業しているユーザーはそのシェルを別のシェルに変更できません。 r で始まるシェルを持っているが、そのような制約を受けたくない場合は、第 10 章「NIS の障害追跡」の対処方法を参照してください。

NIS ユーティリティ

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

表 7–2 NIS ユーティリティ

ユーティリティ 

機能 

makedbm

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

ypcat

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

ypinit

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

ypmatch

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

yppoll

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

yppush

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

ypset

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

ypwhich

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

ypxfr

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

NIS マップ

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

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

NIS マップは、本質的には「キー」およびキーに関する情報の 2 列からなるテーブルです。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 ディレクトリにあります。

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

表 7–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 ファイルがある場合には、他のファイルを使用して利用できるデータの他にそれが参照される

netmasks.byaddr

netmasks

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

networks.byaddr

networks

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

networks.byname

networks

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

passwd.adjunct. byname

passwd と shadow

C2 クライアント用の監査情報と隠蔽されたパスワード情報を含む 

passwd.byname

passwd と shadow

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

passwd.byuid

passwd と shadow

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

protocols.byname

protocols

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

protocols.bynumber

protocols

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

rpc.bynumber

rpc

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

services.byname

services

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

services.byservice

services

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

ypservers

なし 

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

新しい ipnodes マップ (ipnodes.byaddr および ipnodes.byname) が、NIS に追加されました。このマップには、IPv4 アドレスと IPv6 アドレスの両方が格納されます。 ipnodes(4) のマニュアルページを参照してください。 NIS クライアントとサーバーは、IPv4 または IPv6 のどちらかの RPC トランスポートを使用して通信することができます。

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

NIS 関連コマンド

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

表 7–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 と入力すると、マップを分解できるため、システム管理者はマップを構成するキーと値のペアを参照できる

ypxfr

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

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 サーバーマップのバージョンを指定することはできない 

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 9 と旧バージョンとの相違点

Solaris 9 の NIS の特徴は、次のとおりです。

NSKit が存在しない

NIS サービスは、2.6 より前の Solaris リリースには組み込まれていませんでした。NIS サービスは今までは、個別販売される NSKit からインストールしなければなりませんでした。現在、NIS サービスは Solaris 9 に組み込まれているため、Solaris 9 の NSKit はありません。

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

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

ypupdated デーモン

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

/var/yp/securenets

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

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


255.255.255.10	 192.168.0.1
host    13.13.14.1
host    13.13.14.2

上記において、255.255.255.10 はネットマスクで、13.13.13.255 はネットワークアドレスです。1 行目の設定では、ypserv はサブネットの 13.13.13.255 の範囲のこれらのアドレスにのみ応答します。

/var/yp/securenets ファイルのエントリを変更したときは、ypserv と ypxfrd のデーモンを終了させて再起動をする必要があります。

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

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

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

注 –

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

SunOS 4 互換モード

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

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

SunOS 4 モードでは、すべてのパスワード情報が passwd ファイルに保存されています。Solaris 2 モードでは、パスワード情報は shadow ファイルに保存され、ユーザーアカウント情報は passwd ファイルに保存されます。

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