パート I では、名前空間と Solaris ネームサービスの紹介と概要、nsswitch.conf ファイルを使用してネームサービスの使用法を調整する方法について説明します。
この章では、「名前空間」と「ネームサービス」の概要と機能について説明します。ネームサービスは、「ネットワーク情報サービス」、「ディレクトリサービス」と呼ぶこともあります。後半では、DNS、NIS、FNS、NIS+ という 4 つの Solaris ネームサービスについて簡単に説明します。
NIS+、NIS、DNS、FNS の名前空間の設定については、『Solaris ネーミングの設定と構成』で説明します。用語や略語の定義については 用語集を参照してください。
ネームサービスは、ユーザー、ワークステーション、アプリケーションが、ネットワークを通じてやりとりする必要がある情報を 1 つの場所に格納します。情報にはたとえば、以下のものがあります。
マシン (ホスト) 名とアドレス
ユーザー名
パスワード
アクセス権
集中化されたネームサービスがなければ、ワークステーションごとに、これらの情報のコピーを管理しなければなりません。ネームサービス情報はファイルまたはマップ、データベーステーブルの形で格納できます。これらのデータを 1 カ所で管理すれば、大規模なネットワークの管理が簡単になります。
ネームサービスは、どのようなコンピュータネットワークにも欠かせないものです。そのほかにもネームサービスには、以下の機能があります。
名前とオブジェクトを対応づける (結合する)
オブジェクトの名前を解決する
結合を解除する
名前を一覧表示する
名前を変更する
ネットワーク情報サービスを使用すると、数値アドレスの代わりに一般的な名前でワークステーションを識別できます。そのため、ユーザーは「129.44.3.1」のような難しい数値アドレスを覚えて入力する必要がなくなり、情報のやりとりが簡単になります。
たとえば、pine、elm、oak という 3 台のワークステーションからなる簡単なネットワークを例にとります。pine が elm または oak にメッセージを送信するには、それら 2 台のネットワークアドレスを知る必要があります。そのため pine は、自分自身を含めたネットワーク内のすべてのワークステーションのネットワークアドレスを格納する /etc/hosts ファイルまたは /etc/inet/ipnodes ファイルを持っています。
同様に、elm や oak が pine と通信したり、お互いに通信するためには、同じ /etc/hosts ファイルを持つ必要があります。
しかし、ワークステーションが格納しなければならないネットワーク情報は、アドレスだけではありません。セキュリティ情報、メールデータ、Ethernet インタフェースについての情報、ネットワークサービスについての情報、ネットワークの使用を許可されたユーザーグループについての情報、ネットワーク上で提供されるサービスについての情報なども必要です。ネットワークによって提供されるサービスが増えるにつれて、そのファイルも大きくなります。その結果、各ワークステーションに /etc/hosts または /etc/inet/ipnodes のようなファイルのセット全部を持たせる必要もでてきます。
この情報が変更されるごとに、管理者はネットワーク内のすべてのワークステーションにある情報を最新のものにしなければなりません。小さなネットワークではこれは単純な作業にすぎませんが、中規模または大規模なネットワークでは、この仕事は時間がかかるだけではなく、手に負えないものとなります。
ネットワーク情報サービスがこの問題を解決します。このサービスでは、ネットワーク情報をサーバーに格納し、その情報を要求するワークステーションに提供します。
この場合、ワークステーションはサーバーの「クライアント」と呼ばれます。ネットワークについての情報が変更されるたびに、各クライアントのローカルファイルを変更する代わりに、管理者はネットワーク情報サービスが格納する情報だけを更新します。これによって、エラー、クライアント間の不一致、そして作業量を減らすことができます。
このように、サーバーがネットワークを通してサービスをクライアントに提供する方法を「クライアントサーバーコンピューティング」と呼びます。
ネットワーク情報サービスの第一の目的は情報の一元管理ですが、もう 1 つの目的はネットワーク名の簡素化です。たとえば、ある会社がネットワークを設定して、インターネットに接続したと仮定します。インターネットはその会社に 129.44.0.0 というネットワーク番号と、doc.com というドメインネームを割り当てました。会社には「営業 (Sales)」と「製造 (Manf)」という 2 つの部門があるため、このネットワークは 1 つのメインネットと、各部門に 1 つずつ、合計 2 つのサブネットに分割されます。各ネットには独自のアドレスがあります。
上に示すように、各部はネットワークアドレスで識別することもできますが、ネームサービスで使用できる名前の方が便利です。
したがって、メールやその他のネットワーク通信の送信先を 129.44.1.0 というアドレスを指定する代わりに、単に doc と指定できます。また、129.44.2.0 や 129.44.3.0 と指定する代わりに、sales.doc や manf.doc と指定できます。
名前は、物理アドレスよりもはるかに柔軟です。物理的なネットワークはめったに変更されませんが、これらを使用する組織はよく変化します。ネットワーク情報サービスは、組織とその物理的なネットワークとの間のバッファのように機能します。その理由は、ネットワーク情報サービスが物理的ネットワークに実際に接続されているのではなく、マップされているためです。次の例でこれを説明します。
この doc.com ネットワークが、S1、S2、S3 の 3 台のサーバーによってサポートされ、これらのうち 2 台のサーバー (S1 と S3) がクライアントをサポートすると仮定します。
クライアント C1、C2、C3 はネットワーク情報をサーバー S1 から入手します。クライアント C4、C5、C6 はこれをサーバー S3 から入手します。このような形態のネットワークを次の表に示します (表 1-1 は、前記のネットワークを一般化して表現したもので、実際のネットワーク情報マップとは異なる)。
表 1-1 doc.com ネットワークの構成
ネットワークアドレス |
ネットワーク |
サーバー |
クライアント |
---|---|---|---|
129.44.1.0 |
doc |
S1 |
|
129.44.2.0 |
sales.doc |
S2 |
C1, C2, C3 |
129.44.3.0 |
manf.doc |
S3 |
C4, C5, C6 |
2 つの部門からある人数の人材を借りて第 3 の部門 Test を新設し、第 3 のサブネットは開設しなかったとします。その結果この物理ネットワークは、この企業の組織とは対応しなくなってしまいます。
Test 部門の通信には専用のサブネットがなく、129.44.2.0 と 129.44.3.0 に分割されます。しかし、ネットワーク情報サービスを使用することにより、Test 部門の通信も専用のネットワークを備えることができます。
このように、組織が変更された場合、そのネットワーク情報サービスは単にマッピングを変更するだけで対応できます。
こうして、クライアント C1 と C2 はサーバー S2 から、C3 と C4 はサーバー S4 から、C5 と C6 はサーバー S3 からそれぞれ情報を入手します。
この組織でこれ以降に行われる変更に対しては、ハードウェアのネットワーク構造を再編成することなく、ソフトウェアのネットワーク情報構造を変更することにより対応できます。
Solaris 8 リリースには、以下のようなネームサービスがあります。
DNS (ドメイン各システム、Domain Name Service) - 「DNS とは」を参照してください。
/etc ファイル - 本来 UNIX で使用されるネームシステム。「/etc ファイル」を参照してください。
NIS (ネットワーク情報サービス、Network Information Service) - 「NIS とは」を参照してください。
NIS+ (Network Information Service plus) - 「NIS+ とは」を参照してください。
FNS (フェデレーテッド・ネーミング・サービス、Federated Naming Service) - 1 つの Solaris 環境でさまざまな独立したネーミングシステムを使用できます。「FNS とは」を参照してください。
最近のほとんどのネットワークでは、これらのサービスを 2 つ、またはそれ以上組み合わせて使用します。複数のサービスを使用するときは、nsswitch.conf ファイルで調整します。nsswitch.conf ファイルについては第 2 章「ネームサービススイッチ」で説明します。
DNS は TCP/IP ネットワーク用にインターネットが提供するネームサービスです。ネットワーク上のワークステーションがインターネットアドレスではなく、普通の名前で識別できるように開発されたものです。DNS は、ローカルの管理ドメイン内と、複数の管理ドメイン間においてホスト名の管理を行います。
DNS を使う、ネットワークに接続されたワークステーションの集合のことを「DNS 名前空間」と呼びます。DNS 名前空間は階層をなす複数の「ドメイン」に分けることができます。1 つの DNS ドメインは複数のワークステーションがまとまったグループです。各ドメインは複数の「ネームサーバー」、つまり、1 つの主サーバーと 1 つまたは複数の副サーバーよってサポートされます。各サーバーは in.named と呼ばれるデーモンを実行することによって DNS を実装しています。クライアント側は、「リゾルバ」によって DNS を実装します。リゾルバの機能は、ユーザーによる参照を解決することです。このためにリゾルバはネームサーバーを参照します。参照を受けたネームサーバーは、要求された情報、または、別のサーバーに向けられた参照内容を返します。
最初のホストを基本とした UNIX の命名システムは、スタンドアロンの UNIX マシン用に開発された後、ネットワークで使用されるようになりました。UNIX オペレーティングシステムの旧版の多くや UNIX マシンでは、現在でもこのシステムが使用されていますが、大規模で複雑なネットワークにはあまり適切ではありません。
「NIS」は DNS とは独立して開発され、目的はやや異なっています。DNS はワークステーションアドレスの代わりにワークステーション名を使うことによって、通信を簡略化することに焦点を当てているのに対して、NIS の場合は、多様なネットワーク情報を集中管理することによりネットワーク管理機能を高めることに焦点を絞っています。NIS には、ユーザー、ネットワークそのもの、ネットワークサービスについての情報も格納されます。これらのネットワーク「情報」をまとめて「NIS の名前空間」と呼びます。
NIS 名前空間情報は NIS マップに格納されています。NIS マップは UNIX の /etc ファイルやその他の構成ファイルに替わるものとして設計され、実際には名前やアドレス以外の情報も持っています。その結果、NIS 名前空間には非常に大きなマップの集合が含まれることになります (「NIS マップ」を参照)。
NIS は DNS に似たクライアントサーバーの配列を持っています。複製の NIS サーバーは NIS クライアントへサービスを提供します。主サーバーは「マスター」サーバーと呼ばれ、安全のためのバックアップがあります。これは「スレーブ」サーバーと呼ばれています。どちらのサーバーも NIS 情報検索ソフトウェアを使用し、NIS マップを格納します。NIS アーキテクチャの詳細は、「NIS アーキテクチャ」を参照してください。
NIS とその管理方法については パート IV「NIS の管理」を参照してください。
「NIS+」は、NIS によく似たネットワークネームサービスですが、より多くの機能を備えています。NIS+ は NIS を機能拡張したものではなく、新しいソフトウェアプログラムとなっています。
NIS+ ネームサービスは、ネットワークがどのような構造であっても、その周囲を取り巻くことにより、サービスを設置した組織の形態に適合するように設計されています。NIS の場合と異なり、NIS+ の名前空間は動的なため更新が可能で、正規ユーザーであればいつでも更新できます。
NIS+ は (ワークステーションのアドレス、セキュリティ情報、メール情報、Ethernet インタフェースおよびネットワークサービスに関する情報などの) 情報を 1 カ所に格納して、ネットワーク上のすべてのワークステーションからアクセスできるようにします。このように構成されたネットワーク情報を、NIS+「名前空間」と呼びます。
NIS+ 名前空間は階層構造となっていて、UNIX のディレクトリファイルシステムによく似ています。階層構造になっていることから、NIS+ 名前空間は企業組織の階層に合わせて構成できます。名前空間の情報のレイアウトは、その「物理的」構成とは無関係です。したがって、NIS+ 名前空間は、独立して管理できる複数のドメインに分割できます。クライアントは、適切なアクセス権があれば、自分のドメインだけではなく、ほかのドメインの情報にもアクセスできます。
NIS+ はクライアントサーバーモデルを使用して、NIS+ 名前空間に情報を格納し、またその情報にアクセスできます。各ドメインは複数のサーバーによってサポートされます。最も重要なサーバーは「マスターサーバー」と呼ばれ、バックアップサーバーは「複製サーバー」と呼ばれます。ネットワーク情報は、内部 NIS+ データベース内にある 16 個の標準 NIS+ テーブルに格納されています。マスターサーバーと複製サーバーは、共に NIS+ サーバーソフトウェアを実行し、NIS+ テーブルのコピーを管理します。マスターサーバー上の NIS+ データに対する変更は、複製サーバーにも自動的に伝達されます。
NIS+ には、名前空間の構造とその情報を保護するために、高度なセキュリティシステムが組み込まれています。NIS+ は認証 (authentication) と承認 (authorization) を使用して、クライアントの情報要求に応えるべきかどうかを検証します。「認証」とは、情報の要求者がネットワークの正当なユーザーであるかどうかを判定することです。「承認」とは、要求された情報に関して特定のユーザーが入手または変更を許可されているかどうかを判定することです。
NIS+ のより詳しい説明については、パート II「NIS+ の紹介と概要」を、使用方法については、パート III「NIS+ の管理」を参照してください。
「FNS」は、1 つの Solaris 環境でさまざまなネームサービスを独立して動作させるための機能です。FNS を使用すれば、ネットワーク上のさまざまなネームサービスすべてに、1 つの簡単なネームシステムインタフェースで対応できます。FNS は、X/Open federated naming (XFN) 規格に適合しています。
FNS は、NIS+、NIS、DNS、/etc ファイルの代わりとして使用することはできません。FNS はむしろこれらのサービスの一番上に位置しており、通常の名前をデスクトップ上のアプリケーションで使用できるようにします。
FNS のより詳しい説明と管理方法については、パート V「FNS の管理」を参照してください。
この章では、ネームサービススイッチの機能と、これを使用してクライアントが 1 つまたは複数のソースからネーミング情報を入手する方法について説明します。ネームサービススイッチは、異なるネームサービスの使用方法を調整するために使います。
ネームサービススイッチは nsswitch.conf という名前のファイルで、クライアントのワークステーションやアプリケーションがネットワーク情報を得る方法を管理します。ネームサービススイッチは、
のような getXbyY() インタフェースを呼び出すクライアントアプリケーションによって使用されます。ネームサービススイッチは単に「スイッチ」または「スイッチファイル」と呼ばれることもあります。各ワークステーションは、それぞれの /etc ディレクトリの中にスイッチファイルを持っています。ファイルの各行は、host、passwd、group などの特定タイプのネットワーク情報を識別します。その後には、クライアントがネットワーク情報を探すための 1 つまたは複数のソースが続きます。
クライアントは、1 つまたは複数のスイッチのソースからネーミング情報を入手できます。たとえば、NIS+ のクライアントは、NIS+ テーブルからホスト情報を、ローカルの /etc ファイルからパスワード情報をそれぞれ入手できます。さらに、スイッチが各ソースを使用する条件を指定することもできます。「検索規準」を参照してください。
Solaris オペレーティング環境では、インストールの過程において、各ワークステーションの /etc ディレクトリに nsswitch.conf ファイルを自動的にロードします。同時に、次に示すスイッチファイルの 4 つの代替 (テンプレート) バージョンも /etc ディレクトリにロードされます。
/etc/nsswitch.files
/etc/nsswitch.nis
/etc/nsswitch.nisplus
/etc/nsswitch.ldap
これら 4 つのファイルは、代替デフォルトスイッチファイルです。各ファイルはそれぞれ /etc ファイル、NIS、NIS+ 、LDAP という異なる主要なネームサービス用に設計されています。Solaris リリースソフトウェアを初めてワークステーションにインストールするときに、インストール担当者はワークステーションのデフォルトネームサービスを NIS+、NIS、ローカルファイル、LDAP の中から選択します。インストール中に、対応するテンプレートファイルが nsswitch.conf ファイルにコピーされます。たとえば、クライアントが NIS+ を使用しているワークステーションでは、インストールの過程で nsswitch.nisplus ファイルが nsswitch.conf にコピーされます。特殊な名前空間を持っている場合を除き、通常の操作には nsswitch.conf にコピーされるデフォルトのテンプレートファイルを使用します。DNS または IPv6 用のデフォルトファイルは提供されませんが、これら 4 つのファイルを編集して DNS または IPv6 用に使用できます (「DNS とインターネットでのアクセス」および「IPv6 とインターネットでのアクセス」を参照してください)。
後からワークステーションの主要なネームサービスを変更する場合は、適切な代替スイッチファイルを nsswitch.conf にコピーするだけで変更できます (「nsswitch.conf テンプレートファイル」を参照)。また、/etc/nsswitch.conf ファイルの適当な行を編集することによって、クライアントが使用するネットワーク情報のソースを変更することもできます。この構文については以下に説明します。詳細は、『Solaris ネーミングの設定と構成』を参照してください。
nsswitch.conf ファイルは、基本的には 16 種類の情報とそのソース (getXXbyYY() 関数の情報検索先) のリストです。順序は必ずしも以下のとおりではありません。
aliases
bootparams
ethers
group
hosts
ipnodes
netgroup
netmasks
networks
passwd (シャドウ情報含む)
protocols
publickey
rpc
services
automount
sendmailvars
表 2-1 は、上記の情報タイプのスイッチファイルの中に、一覧表示できるソースの種類の詳細を示しています。
表 2-1 スイッチソースの例
ソース |
説明 |
---|---|
files |
クライアントの /etc ディレクトリに格納されているローカルファイル (/etc/passwd など) |
nisplus |
NIS+ テーブル (hosts テーブルなど) |
nis |
NIS マップ (hosts マップなど) |
compat |
パスワードとグループ情報を対象に、/etc/passwd、/etc/shadow、/etc/group ファイルで旧形式の「+」または「-」構文をサポートする |
dns |
ホスト情報を DNS から入手するように指定する |
ldap |
エントリを LDAP ディレクトリから入手するように指定する |
「単一ソース」
nisplus のような情報のソースが 1 つだけの場合、スイッチを使用している関数は、そのソースだけで情報を検索します。情報が見つかった場合、success という状態メッセージが渡されます。情報が見つからない場合は、検索が停止され、success 以外の状態メッセージが渡されます。状態メッセージに基づいて何をするかは、関数によって異なります。
「複数ソース」
テーブルに複数のソースがある場合、スイッチは最初のソースから情報検索を始めるように関数に指示します。情報が見つかれば success という状態メッセージが返されますが、見つからないときは次のソースが検索されます。関数は必要な情報が見つかるか、return 処理によって中止されるまで全ソースの検索を続けます。必要な情報がどのソースにもなかったとき、関数は検索を停止し、non-success という状態メッセージを返します。
関数は情報を見つけると、success という状態メッセージを返します。また情報が見つからなかった場合、その理由によって、3 種類のメッセージのうちの 1 つを返します。表示される状態メッセージを、以下の表 2-2 に示します。
表 2-2 スイッチ状態メッセージ
状態メッセージ |
意味 |
---|---|
SUCCESS |
要求されたエントリがソース内で発見された |
UNAVAIL |
ソースが応答しない、または使用不可。つまり、NIS+ テーブル、NIS マップ、/etc ディレクトリのファイルが見つからなかった (アクセスできなかった) |
NOTFOUND |
エントリなし。テーブル、マップ、ファイルにアクセスしたが、必要な情報は見つからなかった |
TRYAGAIN |
ソース使用中のため、再検索の必要あり。テーブル、マップ、ファイルは見つかったが、照会に対して応答しなかった |
表 2-3 に示すように、状態メッセージに対して次の 2 つの動作のどちらかで応答するようにスイッチに指示できます。
表 2-3 スイッチ状態メッセージへの応答
動作 |
意味 |
---|---|
return |
情報の検索を停止する |
continue |
次のソースがあれば、それを検索する |
nsswitch.conf ファイルの状態メッセージと動作オプションの組み合わせによって、関数の各ステップでの動作が決まります。この状態と動作の組み合わせのことを、「検索基準」と呼びます。
スイッチのデフォルト検索規準は、どのソースについても同じです。これらを上記の状態メッセージに基づいて説明すれば次のようになります。
SUCCESS=return
UNAVAIL=continue
次のソース (nsswitch.conf ファイルに指定されたもの) を使用して検索を続行する。次のソースがなければ、NOTFOUND という状態メッセージを返す
NOTFOUND=continue
次のソース (nsswitch.conf ファイルに指定されたもの) を使用して検索を続行する。次のソースがなければ、NOTFOUND という状態メッセージを返す
TRYAGAIN=continue
次のソース (nsswitch.conf ファイルに指定されたもの) を使用して検索を続行する。次のソースがなければ、NOTFOUND という状態メッセージを返す
これらはデフォルトの検索基準であるため、自動的に表示されます。つまり、スイッチファイルで、はっきりと指定する必要はありません。ほかの検索基準を明示してデフォルトの検索基準を変更するには、上記の STATUS=action という構文を使用します。たとえば、NOTFOUND 状態に対し、デフォルトの動作では次のソースに移って検索を続行します。networks など、特定の情報を設定して検索すると、検索は NOTFOUND で中止します。スイッチファイルの networks の行を、以下のように編集してください。
networks: nis [NOTFOUND=return] files |
networks: nis [NOTFOUND=return] files は、NOTFOUND に関してデフォルトでない検索基準を設定するものです (デフォルト以外の設定をするときは [ ] を使用します)。
この例では、検索関数は以下のような働きをします。
networks
マップが見つかり、必要な情報があった場合、関数は SUCCESS という状態メッセージを返します。
networks
マップが見つからなかった場合、関数は UNAVAIL という状態メッセージを返し、デフォルトにより適当な /etc ファイルの検索を続行します。
networks
マップは見つかったが必要な情報がなかった場合、関数は NOTFOUND という状態メッセージを返します。そして /etc ファイルの検索を続行する (デフォルトの設定) 代わりに検索を停止します。
networks
マップが使用中の場合、関数は TRYAGAIN という状態メッセージを返し、デフォルトで適当な /etc ファイルの検索を続行します。
クライアントのライブラリ関数には、nsswitch.conf ファイルにおいて「必要なエントリがない」、「エントリの構文が誤っている」といった場合に使用されるコンパイル時に組み込まれるデフォルトエントリが含まれています。これらのエントリは nsswitch.conf ファイルのデフォルトエントリと同じものです。ネームサービススイッチは、テーブル名やソース名のスペルが正しいものとして処理をします。スペルが正しくない場合は、デフォルト値が使用されます。
auto_home テーブル、auto_master テーブルとマップのスイッチ検索基準は、automount と呼ばれる1つのカテゴリに統合されます。
timezone テーブルはスイッチを使用しないため、スイッチファイルのリストには含まれていません。
nsswitch.conf ファイル中の行のうち、「#」で始まっているものはコメント行として解釈され、ファイルを検索する関数では無視されます。
「#」が行の途中にある場合、その左側の文字は nsswitch.conf ファイルを検索する関数の一部となり、右側の文字はコメント行として無視されます。
表 2-4 スイッチファイルのコメント例
行の種類 |
コメント例 |
---|---|
コメント行 (無視される) |
# hosts: nisplus [NOTFOUND=return] files |
完全に解釈される行 |
hosts: nisplus [NOTFOUND=return] file |
部分的に解釈される行 (「files」の部分は解釈されない) |
hosts: nisplus [NOTFOUND=return] # files |
キーサーバーは、起動時にだけネームサービススイッチ構成ファイルの publickey エントリを参照します。つまり、スイッチ構成ファイルを更新しても、再起動しない限りキーサーバーはそのことを認識しないということになります。
Solaris 8 リリースでは、nsswitch.conf のテンプレートファイルが 3 種類提供されます。デフォルトの情報ソース (一次ソース、およびそれに続くもの) としては、それぞれ異なったものが指定されています。
3 種類のテンプレートファイルの詳細は以下のとおりです。
「NIS+ テンプレートファイル」(nsswitch.nisplus ファイル)
このテンプレートファイルで passwd、group、automount、aliases を除くすべての情報の一次ソースとして指定されているのは、NIS+ です。passwd、group、automount、aliases の一次ソースとして指定されているのは /etc ディレクトリのファイルで、二次ソースとして指定されているのは NIS+ テーブルです。[NOTFOUND=return] という検索基準は、「No such entry」というメッセージを受け取ったら NIS+ テーブルの検索を停止する」という意味です。また、ローカルファイルを検索するのは NIS+ サーバーを使用できない場合だけです。
「NIS テンプレートファイル」(nsswitch.nis ファイル)
NIS+ テーブルではなく NIS マップを使用するという点を除けば NIS+ テンプレートファイルとほぼ同じです。passwd、group の情報に関しては files nis という順序で検索するよう指定されているため、/etc/passwd と /etc/group に + エントリを指定する必要はありません。
「Files テンプレートファイル」(nsswitch.files ファイル)
このテンプレートファイルでは、ローカルの /etc ディレクトリのファイルだけがワークステーションの情報ソースとして指定されています。netgroup に関する files のソースは存在しないため、クライアントがスイッチファイルでこのエントリを使用することはありません。
要求するものに最も近いテンプレートファイルを nsswitch.conf にコピーし、必要に応じて修正します。この手順の詳細は、『Solaris ネーミングの設定と構成』のスイッチに関する章を参照してください。
たとえば、NIS+ テンプレートファイルを使用するには、以下のコマンドを入力します。
mymachine# cp nsswitch.nisplus nsswitch.conf |
3 つのスイッチファイルは、Solaris 8 リリースでは、以下のようになります。
# # /etc/nsswitch.nisplus: # # An example file that could be copied over to /etc/nsswitch.conf; # it uses NIS+ (NIS Version 3) in conjunction with files. # # "hosts:" and "services:" in this file are used only if the # /etc/netconfig file has a "-" for nametoaddr_libs of "inet" # transports. # the following two lines obviate the "+" entry in /etc/passwd # and /etc/group. passwd: files nisplus group: files nisplus # consult /etc "files" only if nisplus is down. hosts: nisplus [NOTFOUND=return] files # Uncomment the following line, and comment out the above, to use # both DNS and NIS+. You must also set up the /etc/resolv.conf # file for DNS name server lookup. See resolv.conf(4). # hosts: nisplus dns [NOTFOUND=return] files services: nisplus [NOTFOUND=return] files networks: nisplus [NOTFOUND=return] files protocols: nisplus [NOTFOUND=return] files rpc: nisplus [NOTFOUND=return] files ethers: nisplus [NOTFOUND=return] files netmasks: nisplus [NOTFOUND=return] files bootparams: nisplus [NOTFOUND=return] files publickey: nisplus netgroup: nisplus automount: files nisplus aliases: files nisplus sendmailvars: files nisplus |
# # /etc/nsswitch.nis: # # An example file that could be copied over to /etc/nsswitch.conf; # it uses NIS (YP) in conjunction with files. # # "hosts:" and "services:" in this file are used only if the # /etc/netconfig file has a "-" for nametoaddr_libs of "inet" # transports. # # the following two lines obviate the "+" entry in /etc/passwd # and /etc/group. passwd: files nis group: files nis # consult /etc "files" only if nis is down. hosts: nis [NOTFOUND=return] files networks: nis [NOTFOUND=return] files protocols: nis [NOTFOUND=return] files rpc: nis [NOTFOUND=return] files ethers: nis [NOTFOUND=return] files netmasks: nis [NOTFOUND=return] files bootparams: nis [NOTFOUND=return] files publickey: nis [NOTFOUND=return] files netgroup: nis automount: files nis aliases: files nis # for efficient getservbyname() avoid nis services: files nis sendmailvars: files |
# # /etc/nsswitch.files: # # An example file that could be copied over to /etc/nsswitch.conf; # it does not use any naming service. # # "hosts:" and "services:" in this file are used only if the # /etc/netconfig file has a "-" for nametoaddr_libs of "inet" # transports. passwd: files group: files hosts: files networks: files protocols: files rpc: files ethers: files netmasks: files bootparams: files publickey: files # At present there isn't a 'files' backend for netgroup; # the system will figure it out pretty quickly, and won't use # netgroups at all. netgroup: files automount: files aliases: files services: files sendmailvars: files |
Solaris の環境を初めてインストールするときのデフォルトの nsswitch.conf ファイルは、Solaris のソフトウェアをインストールする際に選択したネームサービスで決まります。ネームサービスが選択されると、そのサービスのスイッチテンプレートファイルがコピーされ、新しい nsswitch.conf ファイルが作成されます。たとえば、NIS+ が選択された場合は、nsswitch.nisplus ファイルがコピーされて nsswitch.conf ファイルが作成されます。
nsswitch.conf ファイルでは、以下のいくつかのセクションで説明するとおり、クライアントの DNS 転送も制御されます。DNS 転送によって、クライアントへのインターネットでのアクセスが可能になります。
NIS+ クライアントには、正しく設定された /etc/resolv.conf ファイルが必要です (「DNS クライアントとリゾルバ」を参照)。
NIS+ および NIS クライアントによる DNS 転送ができるよう設定するための手順については、『Solaris ネーミングの設定と構成』 のスイッチファイルに関する説明を参照してください。
NIS+ クライアントには、NIS クライアントにあるような DNS 転送機能はありません。その代わりに、スイッチを使用した DNS 転送が可能です。NIS+ のクライアントに DNS 転送機能を持たせるには、hosts のエントリを以下のように変えます。
hosts: nisplus dns [NOTFOUND=return] files |
NIS ネームサービスでは、本来 DNS 転送が可能です。DNS 転送を可能にするためには、NIS 一次スイッチファイルの hosts の行に以下の書式を使用します。
hosts: nis [NOTFOUND=return] files |
NIS のクライアントが、NIS と互換性のある NIS+ サーバーの DNS 転送機能を使用している場合、ホストファイルの構文として nsswitch.conf ファイルに hosts: nis dns files を使用することはできません。使用した場合、DNS 転送によってホスト要求が自動的に DNS に転送され、この構文によって NIS+ サーバーが DNS サーバーにエラーステータスメッセージを 2 度転送することになり、性能が低下します。DNS 転送機能を十分に利用するには nsswitch.nis ファイルのデフォルト構文を使用してください。
nsswitch.conf ファイルは、IPv6 のアドレスの検索基準を制御します。IPv6 は、32 ビットから 128 ビットまで IP アドレスサイズを大きくして、より多くのアドレス階層をサポートし、より多くのノードにアドレス指定できるようにします。 IPv6 の構成と実装の詳細は、『Solaris のシステム管理 (第 3 巻)』の「IPv6 の概要」と「IPv4 から IPv6 への移行」を参照してください。
IPv6 アドレスには、新しい ipnodes ソースを使用してください。/etc/inet/ipnodes ファイルには、 IPv4 と IPv6 の両方のアドレスが格納されています。 /etc/inet/ipnodes ファイルは、 /etc/hosts ファイルと同じフォーマットを使用しています。
IPv6 のネームサービスでは、 検索用に新しい ipnodes ソースを使用しています。たとえば、 LDAP でIPv6 のアドレスを認識させる場合には、次のように指定します。
ipnodes: ldap [NOTFOUND=return] files |
ipnodes は、デフォルトでは files です。 IPv4 から IPv6 への変更中には、すべてのネームサービスが、IPv6 のアドレスを認識できるわけではないので、デフォルトの files を使用します。 このデフォルトを使用しない場合には、アドレスの解決中に不必要な遅延が生じることがあります (ブート時の遅延など) 。
アプリケーションは、、IPv4 のアドレスを ipnodes データベースで検索してから、hosts データベースを検索します。 ipnodes を指定する前に、IPv4 アドレスの両方のデータベースを検索する時間を考慮にいれる必要があります。
nsswitch.conf ファイルに、/etc/passwd、/etc/shadow、/etc/group などでときおり使用される +/- 構文との互換性を持たせる方法を以下に示します。
「NIS+ の場合」に NIS+ で +/- 構文と同じ効果を得るには、passwd および groups のソースを compat に変更し、nsswitch.conf ファイルの passwd あるいは group エントリの後に passwd_compat: nisplus というエントリを追加します (下記参照)。
passwd: compat passwd_compat: nisplus group: compat group_compat: nisplus |
この指定により、クライアント関数のネットワーク情報獲得先は、ファイル中に +/- エントリを指定したのと同じように、/etc ディレクトリのファイルと NIS+ テーブルになります。
「NIS の場合」に Sun OS 4.x リリースの構文と同じ効果を得るには、passwd と groups のソースを compat に変更します。
passwd: compat group: compat |
この指定により、クライアント関数のネットワーク情報獲得先は、ファイル中に +/- エントリを指定したのと同じように、/etc ファイルと NIS マップになります。
NIS+ サーバーが NIS 互換モードで動作している場合、クライアントマシンでは netgroup テーブルに対して ypcat を実行できません。実行してもテーブルにエントリがない場合と同じような動作をします。
nsswitch.conf ファイルに +/- 構文と同じ意味を持つ指定をする手順の詳細は、『Solaris ネーミングの設定と構成』のスイッチファイルに関する説明を参照してください。
passwd 情報では、常に files が初めに検索されるソースになります。
たとえば、NIS+ の環境では、nsswitch.conf ファイルの passwd 行は以下のようになります。
passwd: files nisplus |
NIS の環境では、nsswitch.conf ファイルの passwd 行は以下のようになります。
passwd: files nis |
passwd 情報の nsswitch.conf ファイルでは、files を 1 番目のソースにしてください。files が 1 番目のソースでない場合は、ネットワークセキュリティが低くなり、ログの扱いが難しくなります。
FNS (フェデレーテッド・ネーミング・サービス) の詳細は、パート V「FNS の管理」を参照してください。
FNS (XFN API を Solaris 上に実装したもの) は、クライアントがネーム情報を照会するためのネームサービスを指定するときにも使用できます。XFN API は、X、Y 両次元において、スイッチファイルを使用する最新の getXbyY() インタフェースよりも一般的です。たとえば、XFN API を使用して、NIS+ と NIS の両方からホストとユーザーに関する情報を調べることができます。アプリケーションは、getXbyY()、XFN、あるいはその両方のクライアントとして使用できます。
FNS による名前空間データの変更を、スイッチファイルを使用して名前空間情報を入手しているクライアントが常に把握できるようにするために、スイッチと FNS には常に同じネームサービスを設定してください。
XFN API によるデータ更新は、getXbyY() インタフェースによる更新よりも優れています。ほとんどの名前空間は複数ソースのデータで構成されています。たとえば、groups の名前空間には、/etc/group ファイルと NIS+ group.org_dir オブジェクトの両方の情報があるかもしれません。しかし、スイッチファイルは、グループデータの特定の部分のソースや更新するソースを識別するための、アプリケーションの更新関数に十分な情報を提供しません。
各 FNS の従属名前空間は、すべてが 1 つのネームサービスから取られます。更新がどのネームサービスに行われるかというような混乱がないため、更新は簡単明瞭なものになります。