パート IV NIS の管理

パート IV では、「ネットワーク情報サービス」(NIS) とその管理方法について説明します。

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

• 第 19 章「NIS の管理」

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

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

• 「NIS の概要」

• 「NIS マシンのタイプ」

• 「NIS の要素」

• 「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 の名前空間はフラットになっています。

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

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+ と共に使用できます。

• 同一ドメインに NIS サーバーと NIS+ サーバーの両方が存在する

  NIS 管理者は同一ドメインで NIS サーバーと NIS+ サーバーの両方を動作させることは可能ですが、このような動作を長時間行わせることは望ましくありません。一般に、同一ドメイン内での NIS サーバーと NIS+ サーバーを両方使用するのは、NIS から NIS+ への短い移行期間だけに制限するべきです。クライアントから NIS サービスの要求があった場合に、NIS 管理者は、NIS+ を NIS 互換モードで動作させることができます。詳細は、「Solaris 1.x と NIS 互換モード」を参照してください。

• サブドメイン

  NIS 管理者のルートドメインのマスターサーバーで NIS+ が動作している場合は、NIS 管理者は、すべてのサーバーで NIS が動作しているサブドメインを設定できます。NIS 管理者のルートドメインのマスターサーバーで NIS が動作している場合は、NIS 管理者はサブドメインの設定はできません。この操作は、NIS 管理者が NIS から NIS+ に切り換えるときに有用であるかもしれません。たとえば、互いに独立した複数の NISドメイン (ドメインは地理的に別々のサイトに置かれていることもある) を持った会社の中で、NIS 管理者がそれらのドメインをすべてリンクさせて NIS+ の下に1つの階層型マルチドメイン名前空間を構築するケースを考えてみます。この場合、NIS 管理者はまずルートドメインを NIS+ 下に設定し、次に従来の NISドメインをサブドメインとして指定できます。これらのサブドメインでは、NIS+ への切り換えが行われるまで NIS が継続して動作します。

• 同一ドメインに複数のマシンが存在する

  • 同一ドメイン内のサーバーで NIS+ が動作している場合は、NIS+、NIS、または /etc ファイルを使ってネームサービス情報を取得するように、ドメイン内の各マシンを設定できます。NIS+ サーバーが NIS クライアントのニーズに応えるには、この NIS+ サーバーは、『Solaris ネーミングの設定と構成』で説明されていように NIS 互換モードで動作していなければなりません。

  • 同一ドメイン内のサーバーで NIS が動作している場合は、NIS または /etc ファイルを使ってネームサービス情報を取得するように、このドメイン内の各マシンを設定できます (各マシンは NIS+ を使用することはできません) 。

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

NIS と FNS

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

NIS マシンのタイプ

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

• マスターサーバー

• スレーブサーバー

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

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 ユーティリティ」を参照)

• NIS コマンドセット (「NIS 関連コマンドについてのまとめ」を参照)

NIS ドメイン

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

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

NIS デーモン

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

NIS ユーティリティ

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

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.byname と hosts.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 動作時にソフトウェアが対応する管理ファイルを調べているか否かが示されています。

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 にまとめられています。これらの各コマンドの使い方の詳細は、それぞれ該当するマニュアルページを参照してください。

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

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 ファイルのエントリを変更したときは、ypserv と ypxfrd のデーモンを終了させて再起動をする必要があります。

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

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

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

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

SunOS 4.x 互換モード

Solaris 8 リリースの NIS は、パスワード構成ファイルを SunOS^TM 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 つの代替 (テンプレート) バージョンも一緒にロードされます。

• /etc/nsswitch.nisplus

• /etc/nsswitch.nis

• /etc/nsswitch.files

これらの代替テンプレートファイルには、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.nis が nsswitch.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"」

第 19 章 NIS の管理

この章では、NIS の管理方法について説明します。

• 「パスワードファイルと名前空間のセキュリティ」

• 「NIS ユーザーの管理」

• 「ネットグループ」

• 「NIS マップに関する作業」

• 「マップ情報の取得」

• 「マップのマスターサーバーの変更」

• 「構成ファイルの更新」

• 「Makefile の更新と使用」

• 「既存のマップの更新」

• 「新しいスレーブサーバーを追加する」

• 「C2 セキュリティが装備されている NIS の使用 」

• 「マシンの NIS ドメインの変更」

• 「NIS を DNS と一緒に使用する」

• 「NIS サービスをオフにする」

• 「NIS の問題解決とエラーメッセージ」

NIS の概要は、第 18 章「ネットワーク情報サービス (NIS)」を参照してください。

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

パスワードファイルと名前空間のセキュリティ

セキュリティの関係上、次の点に注意してください

• マスターサーバーの NIS マップへのアクセスは制限します。

• 未許可アクセスを防止するためには、NIS パスワードマップの作成に使用されたファイルに root エントリを含めないでください。したがって、root エントリをこのパスワードファイルから削除して、このパスワードファイルをマスターサーバーの /etc ディレクトリ以外のディレクトリにおく必要があります。このディレクトリへの未許可アクセスは、防止しなければなりません。

たとえば、マスターサーバーのパスワード入力ファイルは、別のファイルへのリンクではなく Makefile に指定されている限り、/var/yp/ などのディレクトリに存在するか、または選択されたディレクトリに存在します。/usr/lib/netsvc/yp/ypstart スクリプトは、Makefile に指定された構成に従って自動的に適切なディレクトリオプションを設定します。

この NIS インプリメンテーションでは、NIS パスワードマップを作成するための入力として、Solaris 1.x バージョンの passwd ファイルのフォーマットに加え、Solaris リリース 2 の passwd ファイルと shadow ファイルのフォーマットも使用できます。

NIS ユーザーの管理

この節では、ユーザーパスワードの設定、NIS ドメインへの新しいユーザーの追加、ネットグループへのユーザーの割り当てについて説明します。

NIS ドメインに新しいユーザーを追加する

NIS ドメインに新しいユーザーを追加するには、以下の手順に従ってください。

1. NIS マスターサーバーのルートとしてログインします。

2. useradd コマンドで新しいユーザーのログイン ID を作成します。

   Solarisリリース 2 のシステムの場合は、次のように入力します。

   # useradd userID

   userID は新しいユーザーのログイン ID です。このコマンドは、NIS マスターサーバー上の /etc/passwd ファイルと /etc/shadow ファイルにエントリを作成します。

3. 新しいユーザーの初期パスワードを作成します。

   新しいユーザーがログインするために使用できる初期パスワードを作成するには、passwd コマンドを以下の形式で実行します。

   # passwd userID

   userID は新しいユーザーのログイン ID です。このユーザーに割り当てるパスワードを入力するよう指示が出ます。

   このステップが必要になるのは、useradd コマンドで作成されたパスワードエントリがロックされ、新しいユーザーがログインできないからです。初期パスワードを指定することで、このパスワードエントリのロックが解除されます。

4. 必要であれば、新しいエントリをマスターサーバーの passwd マップ入力ファイルにコピーします。

   マスターサーバー上のマップソースファイルが /etc 以外のディレクトリに存在する場合は、新しい行を /etc/passwd ファイルと /etc/shadow ファイルからマスターサーバー上の passwd マップ入力ファイルにコピー＆ペーストする必要があります。詳細は、「パスワードファイルと名前空間のセキュリティ」を参照してください。

   たとえば、新しいユーザー baruch を追加すると、/etc/passwd ファイルから passwd 入力ファイルにコピーされる行は次のようになります。

   baruch:x:123:10:User baruch:/home/baruch:/bin/csh:

   /etc/shadow からコピーされる baruch 行は次のようになります。

   baruch:W12345GkHic:6445::::::

   ---

   注 -

   NIS マップの入力として Solaris リリース 1 の passwd ファイルフォーマットを使用している場合は、passwd ファイルへの新しいユーザーの追加は、テキストエディタを使用して手作業で行わなければなりません。

   ---

5. パスワード入力ファイルが存在するディレクトリを、Makefile で正しく指定していることを確認します。

6. 必要であれば、/etc/passwd ファイルと /etc/shadow 入力ファイルから新しいユーザーのエントリを削除します。

   セキュリティの関係上、NIS マスターサーバーの /etc/passwd ファイルと /etc/shadow 入力ファイルでユーザーエントリを保持することは望ましくありません。新しいユーザーのエントリを他のディレクトリに存在する NIS マップソースファイルにコピーした後、マスターサーバー上の userdel コマンドで新しいユーザーを削除します。

   たとえば、マスターサーバーの /etc ファイルから新しいユーザー baruch を削除するには、次のように入力します。

   # userdel baruch

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

7. NIS の passwd マップを更新します。

   マスターサーバー上の passwd 入力ファイルを更新した後、ソースファイルが存在するディレクトリで make を実行して passwd マップを更新します。

   # userdel baruch # cd /var/yp # /usr/ccs/bin/make passwd

8. 新しいユーザーのログイン ID に割り当てられた初期パスワードを新しいユーザーに通知します。

   ログイン後、新しいユーザーはいつでも passwd を実行して別のパスワードに変更できます。

ユーザーパスワード

ユーザーは passwd を実行してパスワードを変更します。

% passwd username

(ユーザーの立場から見たパスワードの詳細は、「パスワードの使用」を参照してください。)

ユーザーがパスワードを変更する前に、NIS 管理者はマスターサーバー上の rpc.yppasswdd デーモンを起動してパスワードファイルを更新しなければなりません。rpc.yppasswd デーモンを起動するコマンドは、/usr/lib/netsvc/yp/ypstart ファイルにすでに存在しています。

rpc.yppasswdd デーモンは、自動的にマスターサーバー上の ypstart で起動されます。rpc.yppasswd に -m オプションが指定された場合は、ファイルが更新された直後に /var/yp の make が実行されます。passwd ファイルが更新されるたびにこの make が実行されることを回避したい場合は、ypstart スクリプトの rpc.yppasswd コマンドから -m オプションを削除して、crontab ファイルで passwd マップの転送を制御してください。

rpc.yppasswd -m コマンドの後に引数を指定しないでください。別の動作を行わせるために ypstart スクリプトファイルを編集することは可能ですが、-m オプションを任意に削除すること以外の変更をこのファイルに加えることは望ましくありません。すべてのコマンドおよびデーモンは、一群の適切なコマンド行パラメータが存在するこのファイルで起動されます。このファイルを編集する場合は、rpc.yppasswdd コマンドの編集では特に注意してください。passwd.adjunct ファイルに明示的コールを追加する場合は、パスを $PWDIR/security/passwd.adjunct と正確に指定しなければなりません。$PWDIR/security/passwd.adjunct というパスを指定しない場合は、不適切な処理が行われます。

ネットグループ

NIS ネットグループは、NIS 管理者が管理目的のために定義する、ユーザーまたはマシンのグループ (集合) です。たとえば、次のようなネットグループを作成できます。

• 特定マシンにアクセスできる一群のユーザーを定義するネットグループ

• 特定のファイルシステムにアクセスできる一群の NFS クライアントマシンを定義するネットグループ

• 特定の NIS ドメインのすべてのマシンに対して管理者権限を持つ一群のユーザーを定義するネットグループ

各ネットグループには、1 つのネットグループ名が与えられます。ネットグループは、アクセス権を直接設定しません。代わりに、ユーザー名またはマシン名が一般に使用される場所では、ネットグループ名が他の NIS マップで使用されます。たとえば、netadmins というネットワーク管理者ネットグループを作成したと仮定します。netadmins ネットグループのすべてのメンバーに特定マシンへのアクセス権を与えるには、そのマシンの /etc/passwd ファイルに netadmin エントリを追加するだけで、ネットグループ名を /etc/netgroup ファイルに追加して、NIS グループマップに追加することもできます。ネットグループの使用の詳細は、netgroup(4) のマニュアルページを参照してください。

NIS が使用されているネットワーク上では、NIS マスターサーバー上の netgroup 入力ファイルを使用して、netgroup、netgroup.byuser、netgroup.byhost という 3 つのファイルが生成されます。netgroup マップには、netgroup 入力ファイルの基本情報が入っています。他の 2 つの NIS マップには、マシンまたはユーザーが指定されるとネットグループ情報の検索が迅速に行われるフォーマットで情報が入っています。

netgroup 入力ファイルのエントリのフォーマットは、name ID です。name はネットグループ名であり、ID は、ネットグループに属しているマシンまたはユーザー、あるいはその両方を示します。ネットグループの ID (メンバー) は、コンマで区切っていくつでも指定できます。たとえば、3 つのメンバーが存在するネットグループを作成する場合、netgroup 入力ファイルエントリのフォーマットは、name ID、ID、IDとなります。netgroup 入力ファイルエントリのメンバー ID のフォーマットは、次のようになります。

([-|machine], [-|   user], [domain])

machine はマシン名、user はユーザー ID、domain はマシンまたはユーザーの NIS ドメインで、それぞれコンマで区切られます。ドメインエレメントはオプションですが、他の NIS ドメインのマシンまたはユーザーを示す場合には必ず指定します。各エントリではマシンエレメントとユーザーエレメントは必須ですが、ダッシュ (-) は空であることを示すために使用されます。エントリでは、マシンエレメントとユーザーエレメントの関係を示す必要はありません。

netgroup 入力ファイルの 2 つのサンプルエントリを以下に示します。これらの各サンプルエントリでは、admins という名前のネットグループが作成されます。これらの各 admins は、リモートドメイン sales に存在するユーザー hauri と juanita、およびマシン altair と sirius で構成されます。

admins (altair, hauri), (sirius,juanita,sales)
admins (altair,-), (sirius,-), (-,hauri), (-,juanita,sales)

さまざまなプログラムでは、ログイン、リモートマウント、リモートログイン、リモートシェル作成時に NIS ネットグループマップを使用してアクセス権チェックを行います。さまざまなプログラムとは、mountd、login、rlogin、rsh などです。login コマンドは、passwd データベース内でネットグループ名を見つけた場合は、ネットグループマップでユーザー分類を調べます。mountd デーモンは、/etc/dfs/dfstab ファイル内でネットグループ名を見つけた場合は、ネットグループマップでマシン分類を調べます。rlogin と rsh (インタフェースを使用するプログラムならどれでも) は、/etc/hosts.equiv または .rhosts ファイル内でネットグループ名を見つけた場合は、ネットグループマップでマシン分類とユーザー分類の両方を調べます。

ネットワークに新しい NIS ユーザーまたはマシンを追加する場合は、netgroup 入力ファイルの該当ネットグループに追加してください。次に、make でネットグループマップを作成し、これを yppush コマンドですべての NIS サーバーに転送してください。ネットグループおよびネットグループ入力ファイル構文の詳細は、netgroup(4) のマニュアルページを参照してください。

NIS マップに関する作業

この節では、NIS マップの管理方法について説明します。

マップ情報の取得

マップ情報は、ypcat、ypwhich、ypmatch コマンドを使っていつでも取得できます。以下の例では、mapname はマップの正式名とニックネーム（存在する場合）の両方を意味します。

マップのすべての値を表示するには、次のように入力してください。

% ypcat mapname

マップのキーと値 (存在する場合) の両方を表示するには、次のように入力してください。

% ypcat -k mapname

マップのすべてのニックネームを表示するには、以下のコマンドのどれかを入力してください。

% ypcat -x
% ypwhich -x
% ypmatch -x

使用可能なすべてのマップとマスターサーバーを表示するには、次のように入力してください。

% ypwhich -m

特定マップのマスターサーバーを表示するには、次のように入力してください。

% ypwhich -m mapname

キーをマップのエントリと比較するには、次のように入力してください。

% ypmatch key  mapname

見つけたい項目がマップのキーでない場合は、次のように入力してください。

% ypcat mapname | grep item

item は、見つけたい情報です。他のドメインに関する情報を取得するには、これらのコマンドの -d domainname オプションを指定してください。

デフォルト以外のドメインの情報を要求するマシンが、そのドメインに対するバインドを持っていない場合は、このマシンは ypbind で /var/yp/binding/domainname/ypservers ファイルを参照して、そのドメインのサーバーリストを検索します。このファイルが存在しない場合は、ypbind は RPC 同報通信を送出してサーバーを検索します。この場合、検索先であるドメインのサーバーは、要求元マシンと同じサブネットに存在している必要があります。

マップのマスターサーバーの変更

選択されたマップのマスターサーバーを変更するには、まず新しい NIS マスターサーバー上にマップを作成しなければなりません。古いマスターサーバー名は既存のマップにキーと値のペアとして発生するので (このペアは makedbm で自動的に挿入される)、ypxfr でマップを新しいマスターサーバーにコピーしたり、コピーを新しいマスターサーバーに転送するだけでは不十分です。キーと新しいマスターサーバー名との対応づけをし直す必要があります。マップに ASCII ソースファイルが存在する場合は、このファイルを新しいマスターサーバーにコピーしてください。

sites.byname というサンプル NIS マップを作成し直す手順を以下に示します。

1. 新しいマスターサーバーにスーパユーザーとしてログインし、次のように入力します。

   newmaster# cd /var/yp

2. 作成するマップを指定する前に、Makefile にこの新しいマップのエントリが必要です。ない場合は、最初に Makefile を編集します。

3. マップを更新または再作成するには、次のように入力します。

   newmaster# make sites.byname

4. 古いマスターサーバーが NIS サーバーとして残っている場合は、古いマスターサーバーにリモートログイン (rlogin) してから、Makefile を編集します。sites.byname を作成した Makefile 内のセクションをコメントアウトして、このセクションで sites.bynam が再び作成されないようにします。

5. sites.byname が ndbm ファイルとしてだけ存在している場合は、以下に示す makedbm で任意の NIS サーバーからコピーを取り出し、実行して sites.byname を新しいマスターサーバー上で作成し直します。

   newmaster# cd /var/yp newmaster# ypcat -k sites.byname | makedbm - domain /sites.byname

   新しいマスターサーバー上でマップが作成されたら、そのコピーをこのマスターサーバーのスレーブサーバーに送信します。ただしこの場合、yppush を使用しないでください。yppush を使用すると、スレーブサーバーは新しいマスターサーバーからではなく古いマスターサーバーから新しいコピーを取得します。このような動作を回避するには、一般にマップのコピーを新しいマスターサーバーから古いマスターサーバーに送り返すという方法が用いられます。この操作を行うには、古いマスターサーバーのスーパユーザーとなり、次のように入力します。

   oldmaster# /usr/lib/netsvc/yp/ypxfr -h newmaster sites.byname

   これで、yppush を使用できます。スレーブサーバーは、古いマスターサーバーを現行のマスターサーバーとして認識しているので、スレーブサーバーは、マップの現行のバージョンを古いマスターサーバーから取得しようとします。それから、スレーブサーバーは、新しいマスターサーバーが現行のマスターサーバーとして指定されている新しいマップを取得します。

   この方法が失敗した場合は、各 NIS サーバーのルートとしてログインし、上記の ypxfr コマンドを実行してください。この方法は、面倒ですが必ず成功します。

構成ファイルの更新

NIS は、設定ファイルを正確に構文解析します。このため NIS 管理は容易になりますが、設定ファイルおよび構成ファイルにおける変更により、NIS の動作は影響を受けます。

ファイルには次のものがあります。

• /var/yp/Makefile

  このファイルは、サポートされているマップを追加または削除するために使用します。

• /etc/resolv.conf

  このファイルを追加または削除することで、DNS 転送が可能または不可になります。

• $PWDIR/security/passwd.adjunct

  このファイルを追加または削除することで、C2 セキュリティが可能または不可になります。$PWDIR は、/var/yp/Makefile で定義されます。

上記ファイルを更新するには、以下の手順に従ってください。

1. 次のように入力して NIS サーバーを停止します。

   # /etc/init.d/yp stop

2. 必要に応じてファイルを変更します。

3. 次のように入力して NIS サーバーを再起動します。

   # /etc/init.d/yp start

NIS のマップまたはマップソースファイルを更新する場合は、NIS を停止および起動する必要はありません。

以下の点に注意してください。

• NIS マスターサーバーからマップまたはソースファイルを削除しても、スレーブサーバー上の対応するマップまたはソースファイルは自動的には削除されません。スレーブサーバー上の対応するマップまたはソースファイルの削除は、NIS 管理者が手作業で行う必要があります。

• 新しいマップは、自動的には既存のスレーブサーバーに転送されません。新しいマップを既存のスレーブサーバーに転送するには、NIS 管理者がそのスレーブサーバーで ypxfr を実行してください。

Makefile の更新と使用

/var/yp で提供されたデフォルトの Makefile を更新することにより、NIS 管理者のニーズを満たすことができます。今後に備えて、必ずこのオリジナルの Makefile のコピーを保存しておいてください。Makefile を使用すると、マップの追加または削除、および一部のディレクトリ名の変更ができます。

新しい NIS マップを追加するには、マップの ndbm ファイルのコピーをドメインに存在する各 NIS サーバーの /var/yp/domainname ディレクトリに転送する必要があります。この転送は通常、Makefile が自動的に行います。どの NIS サーバーがマップのマスターサーバーであるかを決定したら、マップを容易に作成し直せるようにマスターサーバーの Makefile を更新してください。異なる複数のサーバーを異なる複数のマップのマスターサーバーとして設定することも可能ですが、このようにするとたいていの場合、管理上の混乱を招きます。したがって、1 つのサーバーだけをすべてのマップのマスターサーバーとして設定することをお勧めします。

一般に、人間が判読可能なテキストファイルは、makedbm に対する入力として適したものにするために awk、sed、grep でフィルタリングされます。デフォルトの Makefile を参照してください。make コマンドの概要については、make(15) のマニュアルページを参照してください。

make が認識する従属性の作成方法を決定する際には、Makefile にすでに備わっているメカニズムを使用してください。make では従属ルール内の行の始まりにタブが存在するか否かが重要であり、タブが存在しないというだけでエントリが無効になることがあるので注意してください。

Makefile エントリの追加

Makefile にエントリを追加するには、以下の作業を行ってください。

• データベース名を all ルールに追加します。

• time ルールを作成します。

• データベースのルールを追加します。

たとえば、Makefile をオートマウンタ入力ファイルで動作させるには、auto_direct.time および auto_home.time マップを NIS データベースに追加してください。

NIS データベースにこれらのマップを追加するには、以下の手順に従ってください。

1. all という語で始まる行に、追加したいデータベース名 (1 つまたは複数) を追加します。

   all: passwd group hosts ethers networks rpc services protocols ¥ netgroup bootparams aliases netid netmasks ¥ auto_direct auto_home auto_direct.time auto_home.time

   エントリの順序は任意ですが、継続行の始まりの空白はスペースではなくタブにしてください。

2. Makefile の終わりに以下の行を追加します。

   auto_direct: auto_direct.time auto_home: auto_home.time

3. ファイル中央に auto_direct.time エントリを追加します。

   auto_direct.time: $(DIR)/auto_direct @(while read L; do echo $$L; done < $(DIR)/auto_direct $(CHKPIPE)) | ¥ (sed -e "/^#/d" -e "s/#.*$$//" -e "/^ *$$/d" $(CHKPIPE)) | ¥ $(MAKEDBM) - $(YPDBDIR)/$(DOM)/auto_direct; @touch auto_direct.time; @echo "updated auto_direct"; @if [ ! $(NOPUSH) ]; then $(YPPUSH) auto_direct; fi @if [ ! $(NOPUSH) ]; then echo "pushed auto_direct"; fi

   • CHKPIPE は、次のコマンドに結果を渡す (パイピングする) 前に、パイプ (|) の左側の動作が正しく行われたことを確認します。パイプの左側の動作が正しく行われなかった場合は、NIS make terminated というメッセージが表示されてプロセスは終了します。

   • NOPUSH は、Makefile が yppush を呼び出して新しいマップをスレーブサーバーに転送することを防止します。NOPUSH が設定されていない場合は、転送は自動的に行われます。

   継続行の始まりにある while ループは、バックスラッシュで拡張された行を入力ファイルから削除するためのものです。sed スクリプトはコメント行および空行を削除し、makedbm に出力を渡します。

   他のすべてのオートマウンタマップ (auto_home や他のデフォルトでないマップなど) でも、同じ手順が必要となります。

4. make を実行します。

   # make name

   name は、作成するマップ名です。たとえば、auto_direct などです。

Makefile エントリの削除

Makefile に特定データベースのマップを作成しない場合は、Makefile を以下のように編集してください。

1. all ルールからデータベース名を削除します。

2. 削除するデータベースのデータベースルールを削除またはコメントアウトします。

   たとえば、hosts データベースを削除するには、hosts.time エントリを削除します。

3. time ルールを削除します。

   たとえば、hosts データベースを削除するには、hosts: hosts.time エントリを削除します。

4. マスターサーバーとスレーブサーバーからマップを削除します。

Makefile のマクロおよび変数の変更

Makefile の先頭で定義されている変数の設定値の変更は、等号 (=) の右側の値を変更するだけで行うことができます。たとえば、マップを作成するための入力として、/etc に存在するファイルではなく別のディレクトリに存在するファイル (たとえば、/var/etc/domainname など) を使用する場合は、DIR 値を DIR=/etc から DIR=/var/etc/domainname に変更してください。また、PWDIR 値を PWDIR=/etc から PWDIR=/var/etc/domainname に変更することもできます。

変数は次のとおりです。

• DIR=

  passwd と shadow を除くすべての NIS 入力ファイルが存在するディレクトリ。デフォルト値は /etc です。マスターサーバーの /etc ディレクトリのファイルを NIS 入力ファイルとして使用することは望ましくないので、この値は変更しなければなりません。

• PWDIR

  NIS 入力ファイル passwd と shadow が存在するディレクトリ。マスターサーバーの /etc ディレクトリのファイルを NIS 入力ファイルとして使用することは望ましくないので、この値は変更しなければなりません。

• DOM

  NISドメイン名。DOM のデフォルト値は、domainname コマンドで設定されます。大部分の NIS コマンドでは現在のマシンのドメイン（現在のマシンの /etc/defaultdomain ファイルに設定されている）が使用されることに注意してください。

既存のマップの更新

NIS のインストール終了後、頻繁に更新しなければならないマップとまったく更新する必要がないマップがあることに気づくかもしれません。たとえば、passwd.byname マップは、大企業のネットワークでは頻繁に更新されることがあります。一方、auto_master マップはまったくではないにしてもほとんど更新されません。

マップを更新する必要がある場合は、マップがデフォルトのマップか否かによって 2 つの更新手順のどちらかを使用できます。

• デフォルトのマップは、ネットワークデータベースから ypinit で作成されたデフォルトのセットに存在するマップです。

• デフォルトでないマップは、以下のどれかです。

  • ベンダーから購入したアプリケーションと共に提供されたマップ

  • ユーザーサイト用に特別に作成されたマップ

  • テキスト以外のファイルから作成されたマップ

この節では、さまざまな更新ツールの使用方法について説明します。実際上、これらの更新ツールは、システム起動後にデフォルトでないマップを追加する場合、または一群の NIS サーバーを変更する場合にだけ使用できます。

デフォルトのマップの更新

デフォルトのセットと共に提供されたマップを更新するには、以下の手順に従ってください。

1. マスターサーバーのルートになります。

   必ずマスターサーバーだけの NIS マップを更新します。

2. 更新するマップのソースファイルを編集します (このファイルが /etc に存在しているか、選択された他のディレクトリに存在しているかは問題ではありません)。

3. 次のように入力します。

   # cd /var/yp# make mapname

   make コマンドは、対応するファイルに対して NIS 管理者が行った変更に従ってマップを更新します。make コマンドはまた、これらの変更を他のサーバーに反映します。

デフォルトでないマップの更新

デフォルトでないマップを更新するには、以下の手順に従ってください。

1. 対応するテキストファイルを作成または編集します。

2. 新しいマップまたは更新されたマップを作成 (または再作成) します。マップ作成には 2 つの方法があります。

   • Makefile を使用する方法

     デフォルトでないマップを作成するには、この方法を用います。Makefile にマップのエントリが存在する場合は、make name を実行するだけです (name は作成するマップ名)。Makefile にマップのエントリが存在しない場合は、「Makefile の更新と使用」を参照してエントリを作成をしてください。

   • /usr/sbin/makedbm プログラムを使用する方法

     このコマンドの詳細は、makedbm(1M) のマニュアルページで説明されています。

デフォルトでないマップを makedbm で更新する

入力ファイルが存在しない場合は、makedbm でマップを更新する方法は 2 つあります。

• makedbm -u の出力先を一時ファイルに変更し、一時ファイルを更新し、更新済みの一時ファイルを使用します。

• makedbm -u の出力を makedbm に渡されるパイプライン内で動作させます。分解されたマップを awk、sed、または cat で更新できる場合は、この方法を用います。

新しいマップの作成

新しいマップを作成するには、入力として既存のテキストファイルを使用する方法、または入力として標準入力を使用する方法のどちらかを使用できます。

テキストファイルからマップを作成する

テキストファイル /var/yp/mymap.asc がマスターサーバー上のエディタまたはシェルスクリプトで作成されていると仮定します。この場合、このファイルから NIS マップを作成し、作成された NIS マップを homedomain サブディレクトリに入れるには、マスターサーバー上で次のように入力してください。

# cd /var/yp
# makedbm mymap .asc  homedomain/mymap

mymap マップは現在、マスターサーバーの homedomain ディレクトリに存在しています。この新しいマップをスレーブサーバーに転送するには、ypxfr を実行してください。

ファイルをベースとしたマップにエントリを追加する

mymap にエントリを追加することは簡単です。最初に、対応するテキストファイルを更新せずに実際の dbm ファイルを更新すると、更新は反映されないので、テキストファイル /var/yp/mymap.asc を更新します。次に、上記のような makedbm を実行してください。

標準入力からマップを作成する

オリジナルのテキストファイルが存在しない場合は、キーボードから makedbm に次のように入力して NIS マップを作成してください (最後に Control-D と入力)。

ypmaster# cd /var/yp
ypmaster# makedbm - homedomain/mymap   key1 value1 key2 value2  key3 value3
ypmaster#

標準入力から作成されたマップを更新する

後でマップを更新する必要がある場合は、makedbm でマップを取り出し、一時ファイルを作成できます。マップを分解し、一時ファイルを作成するには、次のように入力してください。

% cd /var/yp
% makedbm -u homedomain/ mymap > mymap.temp

作成される一時ファイル mymap.temp には、1 行につき 1 つのエントリが存在します。このファイルは、任意のテキストエディタで必要に応じて編集できます。

マップを更新するには、次のように入力して、更新後の一時ファイル名を makedbm につけます。

% makedbm mymap.temp  homedomain/mymap
% rm mymap.temp

次に、ルートになり次のように入力してマップをスレーブサーバーに反映させます。

# yppush mymap

ここでは makedbm でマップを作成する方法について説明してきましたが、実際に行わなければならないほとんどすべての作業は、ypinit と Makefile で行うことができます。ただし、システム起動後にデフォルトでないマップをデータベースに追加したり一群の NIS サーバーを変更しない場合に限ります。

/var/yp の Makefile を使用しても他の手順を使用しても、正しく作成された dbm ファイルの新しいペアをマスターサーバー上の maps ディレクトリに入れなければなりません。

NISマップを反映させる

マップが更新されると、Makefile が yppush で新しいマップをスレーブサーバーに転送させます (ただし、NOPUSH が Makefile に設定されていない場合)。転送させるための動作手順は次のとおりです。スレーブサーバー上の ypserv デーモンにマップ転送リクエストを送信します。ypserv デーモンが ypxfr プロセスを起動します。ypxfrd プロセスがマスターサーバー上の ypxfr デーモンに連絡します。いくつかの基本検査 (マップが実際に更新されていることの確認など) が行われます。マップが転送されると、スレーブサーバー上の ypxfrd が、転送が成功したことを yppush プロセスに通知します。

上記手順は、新しく作成されたマップがスレーブサーバー上に存在しない場合は動作しません。新しいマップを、スレーブサーバー上の ypxfr でスレーブサーバーに転送する必要があります。

マップ転送は失敗することがありますが、失敗した場合は ypxfr を使って手作業で新しいマップ情報を転送してください。ypxfr は、2 つの方法で使用できます。1 つはルートの crontab ファイルを定期的に使用する方法であり、もう 1 つはコマンド行から対話形式で使用する方法です。これらの方法については、以下で説明します。

cron でマップ転送を行う

マップの更新頻度は、マップによってそれぞれ異なります。たとえば、デフォルトのマップである protocols.byname やデフォルトでないマップの auto_master など一部のマップは何カ月も更新されないことがありますが、一方、passwd.byname など一部のマップは 1 日に数回更新されることがあります。crontab コマンドでマップ転送をスケジュールすると、個々のマップに対して特定の更新時間を設定できます。

マップに適切な頻度で ypxfr を定期的に実行するには、各スレーブサーバー上のルートの crontab ファイルに、該当する ypxfr エントリを入れる必要があります。ypxfr は、マスターサーバー上のコピーがローカルのコピーより新しい場合に限り、マスターサーバーと連絡をとり、マップを転送します。

デフォルトの -m オプションが指定されている rpc.yppasswdd をマスターサーバー上で実行すると、誰かが yp パスワードを変更するたびに、passwd デーモンが make を実行して passwd マップを作成し直します。

cron と ypxfr でシェルスクリプトを使用する

NIS 管理者は、各マップに対する crontab エントリを個々に作成するという方法ではなく、ルートの crontab コマンドでシェルスクリプトを実行してすべてのマップを定期的に更新するという方法を使用することもできます。マップ更新シェルスクリプトのサンプルは、/usr/lib/netsvc/yp ディレクトリに入っています。スクリプト名は、ypxfr_1perday、ypxfr_1perhour、ypxfr_2perday です。これらのシェルスクリプトを、更新または置換することによって、容易にサイト要件に適合させることができます。例 19-1 は、デフォルトの ypxfr_1perday シェルスクリプトを示しています。

例 19-1 ypxfr_1perday シェルスクリプト

#! /bin/sh
#
# ypxfr_1perday.sh - YP マップの検査・更新を毎日行う
PATH=/bin:/usr/bin:/usr/lib/netsvc/yp:$PATH
export PATH
# set -xv
ypxfr group.byname
ypxfr group.bygid
ypxfr protocols.byname
ypxfr protocols.bynumber
ypxfr networks.byname
ypxfr networks.byaddr
ypxfr services.byname
ypxfr ypservers

このシェルスクリプトは、ルートの crontab が毎日実行されると、マップを 1 日に 1 回更新します。NIS 管理者は、1 週間に 1 回、1 ヶ月に 1回、または 1 時間に 1 回などといった頻度でマップを更新するスクリプトを使用することもできますが、マップを頻繁に更新すると性能が低下するので注意してください。

NIS ドメインに対して構成された各スレーブサーバー上で同じシェルスクリプトを root で実行してください。各サーバー上の実行時間を変更して、マスターサーバーが動作不能にならないようにしてください。

特定のスレーブサーバーからマップを転送する場合は、シェルスクリプトの ypxfr の -h machine オプションを使用してください。シェルスクリプトに記述するコマンドの構文は、次のとおりです。

/usr/lib/netsvc/yp/ypxfr -h machine [ -c ] mapname

machine は、転送するマップが存在するサーバー名です。mapname は、要求されたマップ名です。マシンを指定することなく -h オプションを指定すると、ypxfr はマスターサーバーからマップを取得しようとします。ypxfr 実行時に ypserv がローカルに実行されていない場合は、ypxfr がローカル ypserver に現在のマップリクエストの取消しを送信しないよう、-c フラグを使用してください。

-s domain オプションを使用すると、別のドメインからローカルドメインにマップを転送できます。これらのマップは、各ドメインにおいて同じでなければなりません。たとえば、2 つのドメインが同じ services.byname マップおよび services.byaddr マップを共有することがあります。また、より細かい制御を行うための rcp または rdist を使用してファイルを複数のドメインに転送することもできます。

ypxfr を直接起動する

2 番目の方法である ypxfr の起動とは、ypxfr をコマンドとして実行することです。一般に、ypxfr をコマンドとして実行するのは例外的状況においてだけです。たとえば、一時的に NIS サーバーを設定して試験環境を作成する場合や、他のサーバーと調和して動作不能になっていた NIS サーバーを迅速に取得しようとする場合などです。

ypxfr のアクティビティを記録する

ypxfr が試みた転送およびその転送結果は、ログファイルに記録されます。/var/yp/ypxfr.log というファイルが存在する場合は、転送結果はこのファイルに記録されます。このログファイルのサイズを制限する試みは行われません。このログファイルのサイズが無限に大きくなることを防止するには、ときどき次のように入力してこのログファイルを空にしてください。

# cd /var/yp
# cp ypxfr.log ypxfr.log.old
# cat /dev/null > /var/yp/ypxfr.log

これらのコマンドは、crontab で週間に 1 回実行させることができます。記録をオフにするには、ログファイルを削除してください。

新しいスレーブサーバーを追加する

NIS 実行後、ypinit に与えられた初期リストに含まれていなかった新しいスレーブサーバーを追加する必要があるかもしれません。

新しいスレーブサーバーを追加するには、以下の手順に従ってください。

1. ルートとしてマスターサーバーにログインします。

2. 次のように入力して NIS ドメインディレクトリに移ります。

   # cd /var/yp/domainname

3. 次のように入力して ypservers ファイルを変換します。

   # makedbm -u ypservers >/tmp/temp_file

   makedbm コマンドは、ypservers を ndbm フォーマットから /tmp/temp_file (一時 ASCII ファイル) に変換します。

4. テキストエディタで /tmp/temp_file ファイルを編集します。つまり、新しいスレーブサーバー名をサーバーリストに追加します。この後、/tmp/temp_file ファイルを保存し、閉じます。

5. /temp_file で入力ファイルとして makedbm コマンドを実行し、出力ファイルとして ypservers を実行します。

   # makedbm /tmp/temp_file ypservers

   makedbm は、ypservers を変換して ndbm フォーマットに戻します。

6. ypservers の ASCII ファイルは存在しないので、次のように入力して ypservers マップが適切なものであることを確認します。

   slave3# makedbm -u ypservers

   makedbm コマンドは、画面に ypservers の各エントリを表示します。

   ---

   注 -

   ypservers にマシン名が存在しない場合は、ypservers はマップファイルの更新を受信しません。これは、yppush がこのマップでスレーブサーバーリストを調べるからです。

   ---

7. マスターサーバーから一群の NIS マップをコピーして新しいスレーブサーバーの NISドメインディレクトリを設定します。

   この操作を行うには、スーパユーザーとして新しい NIS スレーブサーバーにログインし、ypinit および ypbind コマンドを実行します。

   slave3# cd /var/yp slave3# ypinit -c list of servers slave3# /usr/lib/netsvc/yp/ypbind

8. このマシンをスレーブサーバーとして初期化するには、次のように入力します。

   # /usr/sbin/ypinit -s ypmaster

   ypmaster は、既存の NIS マスターサーバーのマシン名です。

9. ypstop を実行して、NIS クライアントとして実行されているマシンを停止します。

   # /usr/lib/netsvc/up/ypstop

10. ypstart を実行して NIS スレーブサーバーのサービスを開始します。

    # /usr/lib/netsvc/up/ypstart

    NIS スレーブサーバーの設定の詳細は、『Solaris ネーミングの設定と構成』を参照してください。

C2 セキュリティが装備されている NIS の使用

$PWDIR/security/passwd.adjunct ファイルが存在する場合は、C2 セキュリティが自動的に起動されます。$PWDIR は、/var/yp/Makefile で定義されます。C2 セキュリティモードでは、passwd.adjunct ファイルで passwd.adjunct NIS マップが作成されます。C2 セキュリティモードでは、passwd.adjunct ファイルと shadow ファイルの両方を使用してセキュリティを管理できます。passwd.adjunct ファイルは、次のように入力された場合にだけ処理されます。

# make passwd.adjunct

make passwd コマンドは、NIS 管理者が C2 セキュリティモードで make を手作業で実行した場合にだけ passwd マップ (passwd.adjunct マップではない) を処理します。

マシンの NIS ドメインの変更

マシンの NIS ドメイン名を変更するには、以下の手順に従ってください。

1. マシンの /etc/defaultdomain ファイルを編集して、現在の内容をマシン用の新しいドメイン名に置き換えます。

   たとえば、現在のドメイン名である sales.doc.com を research.doc.com に変更したりします。

2. domainname `cat /etc/defaultdomain' を実行します。

3. マシンを NIS クライアント、スレーブサーバー、またはマスターサーバーとして設定します。

   詳細は、『Solaris ネーミングの設定と構成』参照してください。

NIS を DNS と一緒に使用する

一般に NIS クライアントは、マシン名とアドレスの検索に NIS だけが使用されるように、nsswitch.conf ファイルで構成されます。このような検索が失敗した場合は、NIS サーバーはこれらの結果を DNS に転送します。

マシン名とアドレスの検索が最初に NIS で行われ、次に DNS で行われるように構成するには、以下の手順に従ってください。

1. 2 つのマップ (hosts.byname と hosts.byaddr) に YP_INTERDOMAIN キーが必要です。 このキーを設定するには、Makefile を編集します。つまり、Makefile ファイルの先頭部分の行を次のように変更します。

   #B=-b B=

   を

   B=-b #B=

   に変更

   この変更が行われると、マップ作成時に makedbm が -b フラグで起動されるよう要求されて、また YP_INTERDOMAIN キーが ndbm ファイルに挿入されます。

2. make を実行して上記マップを作成し直します。

   # /usr/ccs/bin/make hosts

3. 有効な名前のサーバーを指定している /etc/resolv.conf ファイルが NIS サーバーに存在することを確認します。

4. DNS 転送を行うには、各サーバーを ypstop コマンドで停止します。

   # /usr/lib/netsvc/yp/ypstop

5. 各サーバーを ypstart コマンドで再起動します。

   # /usr/lib/netsvc/yp/ypstart

   この NIS インプリメンテーションでは、サーバーに /etc/resolve.conf ファイルが存在する場合は、ypstart が -d オプションで自動的に ypserv デーモンを起動して DNS にリクエストを転送します。

   ---

   注 -

   Solaris リリース 2 が実行されていない NIS サーバーを使用している場合は、参照される DNS のホストマップに YP_INTERDOMAIN キーが存在することを確認してください。

   ---

混在 NIS ドメインにおける問題

これまでの説明の大部分では、NISドメインのマスターサーバーとスレーブサーバーの両方で Solaris リリース 2 が実行されていることが前提となっています。したがって、それ以外の場合には、問題が発生することがあります。混在 NIS ドメインにおける問題を回避する方法については、表 19-1 にまとめてあります。"4.0.3+" という表記は、「SunOS のリリース 4.0.3 以降」であることを意味します。makedbm -b コマンドは、Makefile の "-B" 変数に対する参照です。

NIS サービスをオフにする

マスターサーバー上の ypserv が使用不可になっている場合は、NIS マップを更新できません。ネットワーク上の NIS をオフにする場合は、リブート後に次のように入力して ypbind ファイルを ypbind.orig に名前を変更するだけで NIS を使用不可にできます。

% mv /usr/lib/netsvc/yp/ypbind /usr/lib/netsvc/yp/ypbind.orig 

リブート後に特定の NIS スレーブサーバーまたはマスターサーバー上の NIS を使用不可にする場合は、その特定の NIS スレーブサーバーまたはマスターサーバー上で次のように入力してください。

% mv /usr/lib/netsvc/yp/ypserv /usr/lib/netsvc/yp/ypserv.orig 

NIS を直ちに停止するには、次のように入力してください。

% /usr/lib/netsvc/yp/ypstop

NIS サービスは、リブートが行われると自動的に再起動されます。ただし、ypbind および ypserv ファイルで上記のような名前の変更が行われない場合です。

NIS の問題解決とエラーメッセージ

• NIS の問題解決については、「NIS の問題と対策」および 「NIS+ と NIS の互換性の問題」を参照してください。

• 一般的な名前空間エラーメッセージのアルファベット順のリスト、およびこれらのエラーメッセージの意味については、付録 B 「エラーメッセージ」 を参照してください。