テーブルの構成を決める

NIS+ テーブルには、単純なテキストファイルやマップにはない、いくつかの機能があります。これらのテーブルは、列エントリ構造を持ち、検索パスを受け付けます。また、これらのテーブルをリンクして、いくつかの異なる方法で構成することもできます。さらに、独自のカスタム NIS+ テーブルを作成することもできます。各自のドメイン用にテーブル構成を選択するときは、以下の節の内容を検討してください。

• 「NIS+ テーブルと NIS マップとの違い」

• 「カスタム NIS+ テーブルの使用」

• 「テーブル間の接続」

NIS+ テーブルと NIS マップとの違い

NIS+ テーブルは、様々な点で NIS マップと異なりますが、次の 2 つの相違点は、名前空間を設計する場合に念頭においておく必要があります。

• NIS+ が使用する標準テーブルの数は NIS よりも少ない

• NIS+ テーブルは、SunOS 4.x リリースでの NIS マップとは異なる方法で、/etc 内のファイルと相互運用される

NIS+ 標準テーブル

17 の標準 NIS+ テーブルを検討して、各サイトの必要に応じたものかどうかを確認してください。これらのテーブルは、表 2-5 に示してあります。表 2-6 は、 NIS マップと NIS+ テーブルの対応を示しています。

関連するテーブルの同期化については心配する必要はありません。NIS+ テーブルには、基本的に NIS マップと同じ情報が格納されます。ただし、NIS+ テーブルでは、類似の情報が 1 つのテーブルに統合されます (たとえば、NIS+ の hosts テーブルには、NIS マップの hosts.byaddr と hosts.byname と同じ情報が格納されます)。NIS+ テーブルでは、 NIS マップで使用されていた対のキー値の代わりに、列と行が使用されます (『Solaris ネーミングの設定と構成』を参照)。キー値のテーブルには、2 つの列があり、最初の列はキー、 2 番目の列は値になります。したがって、ホスト情報などの情報を変更するときは、その情報を、hosts テーブルなど 1 か所で変更するだけですみます。関連するマップ全体の情報の整合性の維持について注意する必要はなくなりました。

オートマウンタテーブルの新しい名前は次のとおりです。

• auto_home (旧名 : auto.home)

• auto_master (旧名 : auto.master)

NIS+ では、ドットを使ってディレクトリを区切るため、ドットは下線に変更されました。テーブル名にドットを使用すると、NIS+ は名前の変換を誤ります。同じ理由で、マシン名にドットを使用することはできません。ドットを含むマシン名は、かならず他の名前に変更してください。たとえば、sales.alpha というマシン名は使用できません。 sales_alpha、salesalpha などのドットを含まない任意の名前に変更してください。

NIS から NIS+ への移行を行うには、NIS 自動マウンタマップのドットを下線に変更する必要があります。また、クライアントのオートマウンタ構成ファイルでも、同じ処理が必要です。表 2-5 を参照してください。

NIS+ には、NIS テーブルと対応しない sendmailvars という新しいテーブルが 1 つあります。この sendmailvars テーブルには、sendmail で使用される mail ドメインが格納されます。

NIS+ テーブルは、NIS とは異なる方法で /etc 内のファイルと相互運用される

NIS および 他のネットワーク情報サービスが SunOS 4.x 環境の /etc 内のファイルとの間で行う相互運用は、+/- 構文を使用して /etc 内のファイルによって管理されていました。 NIS+、NIS、DNS、および他のネットワーク情報サービスが、Solaris オペレーティング環境の /etc 内のファイルと相互運用を行う方法は、ネームサービススイッチによって決まります。ネームサービススイッチは構成ファイルで、/etc/nsswitch.conf という名前ですべての Solaris オペレーティング環境のクライアントに格納されています。すべての Solaris オペレーティング環境クライアントにある構成ファイルの nsswitch.conf は、そのクライアントの情報源を指定します。これは、 /etc 内のファイル、DNS ゾーンファイル (ホストだけ)、NIS マップ、または NIS+ テーブルなどです。この NIS+ クライアントの nsswitch.conf 構成ファイルの例は、例 2-1 の簡易説明です。

例 2-1 簡易化されたネームサービススイッチファイルの例

passwd: files

group: compat

group_compat: nisplus

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

つまり、ほとんどのタイプの情報で、情報源はまず NIS+ テーブルであり、次に /etc 内のファイルということになります。passwd および group エントリの場合、ネットワーク情報のソースは、ネットワークファイルか、または /etc 内のファイルおよび /etc ファイルの +/- エントリによって表された NIS+ テーブル のいずれかとなります。

3 種類のスイッチ構成ファイルから選択するか、または独自のスイッチ構成ファイルを作成することができます。方法については、『Solaris ネーミングの管理』を参照してください。

カスタム NIS+ テーブルの使用

どの標準以外の NIS マップを使用するか、またその使用目的を決定してください。NIS+ に変換できるか、あるいは NIS+ 標準マップと置き換えられるかを検討します。

アプリケーションの中には、NIS マップに依存するものがあります。これらのアプリケーションが、NIS+ でも同様に機能するか、また混合環境で正しく機能できるかを検討します。

NIS+ でカスタムテーブルを作成するには、nistbladm を使用します。テーブル名にはドットを使用できないことを忘れないでください。

NIS+ を使用して、独自の NIS マップをサポートできるようにしたい場合は、2 つの列を使用するキー値テーブルを作成する必要があります。最初の列はキー、2 番目の列は値を示します。このテーブルを作成して、NIS+ サーバーを NIS 互換モードで実行すると、NIS クライアントは機能の変更に気がつきません。

テーブル間の接続

NIS+ テーブルには、そのホームドメインの資源とサービスに関する情報だけが含まれています。したがってクライアントは、別のドメインに格納された情報を検索する際には、そのドメインの名前を指定しなければなりません。この「転送」を自動化するには、ローカルテーブルをリモートテーブルに接続してください。NIS+ テーブルは、次の 2 つの方法で接続することができます。

• パスを使用する方法

• リンクを使用する方法

NIS+ 名前空間で NIS クライアントを使用するときは、パスとリンクを使用してはいけません。NIS クライアントは、パスまたはリンクでは、正しい情報を検索することができません。

パス

他のドメインのクライアントが、特定の NIS+ テーブル内の情報を頻繁に要求する場合は、そのローカル NIS+ テーブルから他のドメインのテーブルへのパスを設定することを検討してみてください。図 2-6 を参照してください。

図 2-6 上位ドメイン内のテーブルへのパスを設定する

このようなパスがもたらす主な利点は 2 つあります。まず、下位ドメインのクライアントが、別のテーブルを明示的に検索しなくてもすみます。さらに、上位ドメインの管理者があるテーブルで変更を行い、その変更を他のドメインのクライアントに見えるようにすることができます。ただし、このようなパスを設定すると、性能が低下します。特に検索がうまくいかないと、性能に影響が出ます。これは、NIS+ サービスで、1 つのテーブルではなく 2 つのテーブルを検索しなければならないためです。パスを使用すると、テーブル検索も、他のドメインの利用状況に依存することになります。この依存によって、ドメインの実質の利用度が低下する可能性があります。このような理由から、パスは、他に問題を解決する手段がない場合に限って使用するようにしてください。

mailhost (mail ホスト) は、別名として使用されることが多いため、特定の mailhost に関する情報を検索する必要がある時は、検索パスに完全指定名 (たとえば、 mailhost.sales.com. など) を使用する必要があることに注意してください。そうしないと、 NIS+ は、検索したすべてのドメインで見つかった mailhost をすべて返します。

パスをローカルテーブルに設定するには、nistbladm コマンドに -p オプションを付けて使用します。テーブルのパスを変更するには、テーブルオブジェクトへの変更アクセス権がなければなりません。テーブルの検索パスを調べるには、niscat -o コマンドを使用してください (テーブルへの読み取りアクセス権が必要です)。

リンク

テーブル間にリンクを設定すると、パスと同様の効果が生じますが、リンクでは 1 つのテーブル、つまりリモートテーブルの検索だけが行われる点が異なります。検索パスでは、 NIS+ はまずローカルテーブルを検索し、うまくいかなかった場合にのみリモートテーブルを検索します。リンクでは、検索は、リモートテーブルに対して直接行われます。実際には、リモートテーブルがローカルテーブルと置き換わります。リンクを設定すると、下位ドメインが、独自のテーブルを管理しなくても、上位ドメインの情報を使用することができます。

リンクを作成するには、nisln コマンドを使用してください。また、テーブルオブジェクトに対する変更権が必要です。

パスを使用するか、またはドメイン内の NIS+ テーブルをリンクするかを決定するのは、容易ではありません。この決定を行う際の基本的な方針をいくつか、次に示しておきます。

• すべてのドメインに、すべての標準テーブルへのアクセス権がなければなりません。

• 内容の更新が多く、またアクセス頻度が高いデータは、階層の下位に位置していなければなりません。このようなデータは、最も使用頻度の高い場所の近くに置くようにしてください。

• いくつかのドメインが使用するデータは、階層内の上位に位置していなければなりません。ただし、それらのドメインを独立した状態にしておく必要がある場合は除きます。

• データの格納場所が階層の下位であればあるほど、自立的な管理は容易になります。

• NIS+ クライアントだけが、パスおよびリンクで接続されたテーブルを見ることができます。NIS クライアントは、これらのテーブルを見ることができません。

図 2-7 は、以上の方針をまとめたものです。

図 2-7 NIS+ 階層での情報の配布