この章では、「ネットワーク情報サービス」(NIS) について説明します。
NIS の初期設定と構成の方法については、『Solaris ネーミングの設定と構成』を参照してください。
NIS とは分散型ネームサービスであり、ネットワーク上のオブジェクトおよびリソースを識別し、探索するメカニズムです。NIS は、ネットワーク全体の情報に関する一様な記憶領域と検索方法を、転送プロトコルおよび媒体に依存しない形式で提供します。
システム管理者はネットワーク情報サービスを動作させることにより、「マップ」と呼ばれる管理データベースをさまざまなサーバー (「マスター」と「スレーブ」) に分散でき、またこれらの管理データベースを一元管理により自動的かつ確実な方法で更新できます。したがって、すべてのクライアントがネットワーク全体において一貫した方法で同じネームサービス情報を共有できます。NIS の概要および背景の詳細は、「NIS とは」を参照してください。
NIS (ネットワーク情報サービス) は DNS とは独立して開発され、目的はやや異なっています。DNS は数値 IP アドレスの代わりにマシン名を使うことによって、通信を簡略化することに焦点を当てているのに対して、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 互換モードで動作させることができます。詳細は、「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 章「ネームサービススイッチ」を参照してください。
ある特定の状況では、FNS コマンドを使用して NIS クライアントは、ファイルシステムやプリンタの自分に関係のあるネーム情報を更新します。詳細は、「NIS クライアントが SKI の実行中 FNS によってコンテキストを更新する」を参照してください。
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 クライアントの作成方法については、ypbind(1M) のマニュアルページを参照してください。
NIS サービスは、以下の要素から構成されています。
ドメイン (「NIS ドメイン」を参照)
マップ (「NIS マップ」を参照)
デーモン (「NIS デーモン」を参照)
ユーティリティ (「NIS ユーティリティ」を参照)
NIS コマンドセット (「NIS 関連コマンドについてのまとめ」を参照)
NIS「ドメイン」は、共通な一群の NIS マップを共有するマシンの集合です。各ドメインはドメイン名を持っており、共通な一群の NIS マップを共有する各マシンは指定されたドメインに属します。ドメイン名は、大文字と小文字を区別します。
どのマシンも指定されたドメインに属することができます。ただしこれは、そのドメインのマップに対するサーバーが同一ネットワーク上に存在する場合に限ります。Solaris 2.x を動作しているマシンの場合はサーバーが同一サブネット上に存在する必要はありませんが、先行する NIS インプリメンテーションでは 1 つのサーバーが NIS が使用されている各サブネットに存在している必要がありました。NIS クライアントマシンはドメイン名を取得し、NIS サーバーにブートプロセスの一部としてバインドされます。
NIS サービスは、表 18-1 に示されている 5 つのデーモンで提供されます。
表 18-1 NIS デーモン
デーモン |
機能 |
---|---|
ypserv |
サーバープロセス |
ypbind |
バインドプロセス |
ypxfr |
高速マップ転送 |
rpc.yppasswdd |
NIS パスワード更新デーモン |
rpc.ypupdated |
他のマップ (publickey など) を更新します |
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 マップは、UNIX の /etc ファイルおよび他の構成ファイルを置換するように設計されているので、名前およびアドレスよりはるかに多くの情報を保存できます。NIS が動作しているネットワーク上では、各 NIS ドメインの NIS マスターサーバーは、照会されるドメイン内の他のマシンの一群の NIS マップを保持します。NIS スレーブサーバーは、NIS マスターサーバーのマップのコピーを保持します。NIS クライアントマシンは、マスターサーバーまたはスレーブサーバーから名前空間情報を取得できます。
NIS マップは、Solaris データベースのインプリメンテーションの 1 つのタイプです。他のタイプはこのタイプとは必ずしも重複しておらず、一般に /etc ディレクトリ、DNS リソースレコード (RR) 、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 管理者が作成または追加したマップはすべて使用できます。
表 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 |
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 |
N/A |
ネットワークに認識されている 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) のマニュアルページを参照してください。
ニックネームは、マップのフルネームの別名です。使用可能なマップのニックネーム (たとえば、passwd.byname の場合は passwd) を一覧表示するには、ypcat -x または ypwhich -x と入力してください。
ニックネームは、/var/yp/nicknames ファイルに保存されています。/var/yp/nicknames ファイルには、マップのニックネームとフルネームが 1 つの空白で区切られて入っています。ニックネームのリストは、追加または更新できます。ニックネーム数は現在、500 に制限されています。
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 ファイルから定期的に実行したりできる。また、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 管理者は、NIS サーバーマップのバージョンを指定することはできない |
ypwhich |
現在どの NIS サーバーをクライアントが使用して NIS サービスを取得しているかを表示する。また、-m mapname オプションを指定して起動した場合は、どの NIS サーバーが各マップのマスターサーバーかが表示される。-m だけを指定した場合は、使用可能なすべてのマップ名、およびこれらのマップのマスターサーバーが表示される |
NIS クライアントは、バインドプロセスにより NIS サーバーから情報を取得します。バインドプロセスは、サーバーリストおよび同報通信という 2 つのモードのどちらかで動作できます。
サーバーリストモード
サーバーリストモードでは ypbind プロセスは、/var/yp/binding/domain/ypservers リストでドメイン内のすべての NIS サーバー名を調べます。ypbindプロセスは、このファイルに存在するサーバーにだけバインドします。このファイルは、ypinit -c を動作させることで作成されます。
同報通信モード
ypbind プロセスはまた、RPC 同報通信を使ってバインドを開始できます。同報通信は、これ以上送信されない唯一のローカルサブネットイベントです。したがって、同じサブネット上にクライアントとして少なくとも 1 つのサーバー (マスターまたはスレーブ) が存在しなければなりません。サーバーは、異なる複数のサブネット上に存在できます (マップはサブネット境界を超えて伝送されるため) 。サブネット環境での 1 つの一般的方法は、NIS サーバーとしてサブネットルーターを使用することです。この方法を使用すると、ドメインサーバーはどちらかのサブネットインタフェース上でクライアントにサービスを提供できます。
サーバーリストモードでは、バインドプロセスは次のように動作します。
NIS マップで提供された情報を必要とする、NIS クライアントマシン上で動作しているプログラムが、ypbind にサーバー名を要求します。
ypbind が、/var/yp/binding/domainname/ypservers ファイルを調べてドメインの NIS サーバーリストを見つけます。
ypbind が、NIS サーバーリストの先頭サーバーへのバインドを開始します。先頭サーバーが応答しない場合は、ypbind はサーバーが見つかるまでまたは NIS サーバーリストの最後に達するまで 2 番目以降のサーバーへのバインドを順に試みます。
ypbind が、どのサーバーにトークすべきかをクライアントプロセスに通知します。次に、クライアントプロセスが直接、サーバーにリクエストを送信します。
ypserv デーモンが、要求された情報をクライアントに送り返します。
同報通信モードでは、バインドプロセスは次のように動作します。
ypbind が、RPC 同報通信を送出して NIS サーバーを探索します。
このようなクライアントをサポートするには、NIS サービスを要求している各サブネット上に 1 つの NIS サーバーが存在する必要があります。
ypbind が、同報通信に応答する先頭サーバーへのバインドを開始します。
ypbind が、どのサーバーにトークすべきかをクライアントプロセスに通知します。次に、クライアントプロセスが直接、サーバーにリクエストを送信します。
ypserv デーモンが、要求された情報をクライアントに送り返します。
通常、いったんクライアントがサーバーにバインドされると、何らかの原因でバインドが解除されるまではクライアントはサーバーにバインドされたままになります。たとえば、サーバーがサービスを提供できなくなると、このサーバーがサービスを提供していたクライアントは、新しいサーバーにバインドされます。
どの NIS サーバーが現在、特定クライアントにサービスを提供しているかを知りたい場合は、以下に示すコマンドを入力してください。
% ypwhich machinename |
machinename は、クライアント名です。マシン名が指定されていない場合は、ypwhich はデフォルトとしてローカルマシン (コマンドが実行されるマシン) を使用します。
Solaris 8 リリース の NIS の特徴は、次のとおりです。
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 デーモンは、NSKit の 2.6 以前のバージョンには組み込まれていませんでしたが、Solaris 7 以降のリリース には組み込まれいます。
/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 マップから削除してください。
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 つの代替 (テンプレート) バージョンも一緒にロードされます。
/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"」