test

NIS+ への移行

第 2 章 NIS+ 名前空間の設計

この章では、サイトで使用する最終的な NIS+ 名前空間を設計するための指針と推奨事項を示します。

管理モデルの目的を明らかにする

名前空間を設計するときは、NIS からの移行によって生じる制限を気にしないでください。NIS+ ドメインは、後で最終的な NIS+ 構成がどのようになるかがわかってから変更することができます。

ドメイン構造など、各サイトで使用する情報管理のモデルを選択します。各サイトでの情報の作成、格納、使用、管理について明確な方針がないと、この節で示す設計の決定を行うことが困難になります。たとえば、作業に必要以上の経費がかかる設計をしてしまう可能性があります。また、要求に合わない名前空間を設計してしまうおそれもあります。一度設定した名前空間の設計の変更には時間と手間がかかります。

名前空間の構造を設計する

NIS+ 名前空間の設計は、いろいろな作業の内で最も重要なものの 1 つです。これは、 NIS+ を一度設定した後にドメイン構造を変更するのは、時間のかかる複雑な作業になるからです。この作業が複雑になるのは、情報、セキュリティ、管理の各方針が名前空間のドメイン構造に組み込まれているからです。ドメインを編成しなおす場合は、情報の再編成、セキュリティの再設定、管理方針の再設計が必要になります。

NIS+ 名前空間の構造を設計する際は、次の点を考慮してください。これらについては、この章の以下の節で説明します。

ドメインの階層

NIS+ ドメイン階層には、名前空間をより管理しやすい複数の構成要素に分割できる、という利点があります。各構成要素には独自のセキュリティ、情報管理、管理方針を持たせることができます。クライアントの数が 500 を超える場合、あるユーザーグループに異なるセキュリティに方針を設定したい場合、あるいは地理的に分散したサイトがある場合は、階層を使用することをお勧めします。

ドメイン階層の必要がなければ、階層を使用しません。こうすることにより、NIS+ への移行が簡略化されます。すべてのユーザーが同じ NIS ドメイン内にいる場合、これらのユーザーは、完全指定名を使用しなくてもお互いを直接認識することができます。しかし、NIS+ 階層を作成すると、ユーザーは別々のドメインに置かれます。つまり、完全指定名か完全指定パスを使用しないかぎり、あるドメインにいるユーザーは別のドメインにいるユーザーを直接認識することができません。

たとえば、sales.com. と factory.com. というサブドメインが .com. ドメインの下にあるとします。この場合、sales.com. ドメインのユーザー juan が factory.com. ドメインのユーザー myoko にメールを送るためには、彼女の名前を myoko@hostname.factory.com. (または myoko@hostname.factory) と指定する必要があります。この 2 人のユーザーが同じドメインにいたときには、myoko と指定するだけで十分でした。リモートログインでもドメイン間の完全指定名が必要です。

テーブル間のパスを使用すると、あるドメインのテーブルと別のドメインのテーブルとの間に接続を設定することができますが、ドメイン階層を使用するメリットはなくなります。また、NIS+ サービスの信頼性も低くなります。これは、クライアントが、各自のホームドメインの利用状況だけでなく、各自のテーブルにパス指定される他のドメインの利用状況にも依存するようになるためです。テーブル間のパスを使用すると、要求への応答時間も長くなります。

ドメインの階層 - Solaris 2.6 以前のリリース

Solaris 2.6 以前のリリースでは、各サブドメインの NIS+ サーバーは、そのドメインではなく、親ドメインに含まれます。ただし、ルートドメインは除きます。サーバーとサブドメインの関係がこのような関係になっていると、サーバーがネームサービスデータをサブドメインから取得できることを想定しているアプリケーションの場合に、問題が発生します。たとえば、サブドメインの NIS+ サーバーが NFS サーバーでもある場合、サーバーはネットグループ情報をサブドメインからではなく、サブドメインの上位ドメインから取り出します。このために、混乱が発生する可能性があります。階層によって問題が発生する可能性がある場合の別の例としては、遠隔ログインするユーザーが自分のワークステーションからでは実行できないコマンドを実行する場合に、この NIS+ サーバーも使用する場合です。ルートドメインが 1 つしかない場合には、NIS+ ルートサーバーは自分がサーバーであるドメイン内にいるので、このような問題は発生しません。

ドメインの階層 - Solaris 7

Solaris 7 では、ドメインの NIS+ サーバーは、自分がサーバーであるドメイン内に存在することができます。したがって、サーバーはクライアントが使用している名前をドメイン名に設定することができます。残りのドメインの階層との機密保護通信を実行できるサーバーの機能には影響を与えません。

ドメインの階層を設計する

ドメイン階層について分からない点がある場合は、はじめに『Solaris ネーミングの管理』の Part 1 をお読みください。このマニュアルでは、NIS+ のドメイン構造、情報の格納、セキュリティについて説明しています。

ドメイン階層の各構成要素を理解したら、最終的な階層を示す図を作成します。この図は、設定手順を進めるうえで非常に参考になります。少なくとも、次の問題について考慮する必要があります。

ドメインは 1 つのオブジェクトではなく、オブジェクトの集合に対する参照であることを忘れないでください。したがって、ドメインをサポートするサーバーは、実際にはドメインと関連しないでドメインのディレクトリと関連しています。図 2-1 に示すように、ドメインは domain、ctx_dir.domain、org_dir.domain、groups_dir.domain、という 4 つのディレクトリからなっています。

図 2-1 サーバーとドメインの関係

Graphic

組織的または地理的な構造による階層

NIS+ の主な利点の 1 つに、名前空間をより小さく、より管理しやすい部分に分割できるという機能があります。たとえば、図 2-2 に示す仮の企業である Doc,Inc. の階層にならって、組織の階層を作成することができます。

図 2-2 論理的な組織構造による NIS+ 階層の例

Graphic

図 2-3 に示すように、組織ではなく建物によって階層を構成することもできます。

図 2-3 物理的な位置による NIS+ 階層の例

Graphic

どの構成を選択するかは、主に名前空間の管理方法とクライアントによる名前区間の使用方法によって決まります。たとえば、factory.com. ドメインに属するクライアントが Doc,Inc. の建物全体に分散している場合は、名前空間を建物によって構成しないでください。クライアントは他のドメインに常にアクセスしなければならないため、他のドメインへの資格をクライアントに与えなければならず、ルートマスタサーバーとの通信量が増加します。この場合は、組織ごとにクライアントを構成してください。これに対して、建物に基づくドメインは、組織に変更があっても影響を受け付けません。

ネットワークの物理的配置による制限を受けないようにしてください。NIS+ 名前空間は、NIS クライアントをサポートしなければならない場合を除いて、物理的ネットワークに一致する必要はありません。名前空間で必要なドメインの数は、選択した階層の種類によって決まります。

今後の拡張計画を検討します。現在の NIS+ ルートドメインが、将来別の NIS+ ドメインの下に配置されるかどうかを検討してください。現在の設定を変更するには、膨大な作業が必要になります。名前空間での今後のドメインの必要性を見積って、混乱なくそれらのドメインを収容できる構造を設計してください。

上位ドメインへの接続

NIS+ 名前空間をインターネットや DNS のドメインなどの上位ドメインに接続するかどうかを検討します。現在 DNS 階層のもとで NIS を使用している場合は、NIS+ 名前空間に、 NIS ドメインだけを置き換えるか、サイト全体の DNS/NIS 構造を置き換えるかを決めます。

ルートドメインでのクライアントサポート

図 2-2 と図 2-3 に示した Doc,Inc. の 2 つのドメイン階層を例にして説明します。まず、すべてのクライアントを、ルートドメインの下のドメインに配置するかどうかを調べます。また、一部のクライアントをルートドメインに配置するかどうかを調べます。ルートドメインの目的がそのサブドメインのルートとして動作することだけかどうか、あるいはルートドメインがそれ自身のクライアントグループをサポートするかどうかを調べます。 すべてのクライアントをドメインの最下層に配置し、管理に使用するクライアントだけを中間ドメインに配置することができます。たとえば、最初の図でこの計画を実行すると、すべてのクライアントが big.sales.com.、small.sales.com.、factory.com. の各ドメインに配置され、管理に使用されるクライアントだけが wiz.com. ドメインと sales.com. ドメインに配置されます。たとえば、図 2-2 でこの計画を実行すると、すべてのクライアントが big.sales.com. 、small.sales.com.、factory.com. の各ドメインに配置され、管理に使用されるクライアントだけが .com.ドメインと sales.com. ドメインに配置されます。

また、汎用部門のクライアントを上位レベルのドメインに置くこともできます。たとえば、図 2-3 では、.com.ドメインは建物によって構成されていて、設備部門のクライアントを .com. ドメインに置くことができます。しかし、ルートドメインは、単純で比較的ゆとりのある状態に維持しておく必要があるため、このことはお勧めできません。

ドメインの大きさとドメインの数と比較

現在 NIS+ の実装は、1 つのドメインあたり最大 1000 の NIS+ クライアント、1 つのドメインあたり最大 10 の複製サーバーを設定するように最適化されています。このようなドメインには、通常 10000 のテーブルエントリがあります。この制約は、現在のサーバー発見プロトコルに起因しています。NIS+ クライアントが 1000 を超える場合は、名前空間を異なる複数のドメインに分割して、階層を作成してください。

しかし、階層を作成すると、状況が複雑になって対処しにくくなるおそれがあります。 1 つのドメインを大きくした方が、複数の小さいドメインを作成するよりも管理が容易なため、階層ではなくより大きなドメインを作成したいと考えるかもしれません。数の少ない大きいドメインでは、各自が作成するスクリプトを使って、作業をより容易に自動化できるため、それらのドメインのサービスを担当する熟練の管理者が少なくて済み、管理に要する手間と費用を削減することができます。しかし、ドメインを小さくすると性能が向上し、各自のテーブルをより簡単にカスタマイズすることができます。また、小さいドメインでは、管理をより柔軟に行うこともできます。

レベルの数

NIS+ は、複数レベルのドメインを処理するように設計されています。NIS+ は、任意の数のレベルに対応することができますが、レベルの数が多すぎる階層は、管理が困難です。たとえば、オブジェクトの名前は、長くてややこしいものになる場合があります。したがって、1 つのドメインに対するサブドメインの数は 20 までとし、NIS+ 階層のレベルの数は 5 までに制限するようお勧めします。

セキュリティレベル

名前空間は、通常、セキュリティレベル 2 で管理します。ただし、ドメインごとに異なるセキュリティレベルを使用する場合は、ここでそのレベルを指定する必要があります。第 3 章「NIS+ セキュリティ基準の選択」では、セキュリティレベルの詳細を説明しています。

複数の時間帯にまたがるドメイン

地理的に分散した組織では、ドメイン階層を機能のグループによって構成すると、1 つのドメインが複数の時間帯にまたがることがあります。ドメインが複数の時間帯にまたがることが「決して」ないようにしてください。複数の時間帯にまたがるドメインを構成する必要があるときは、複製サーバーの時刻は、マスタサーバーの時刻に合わせられることに注意してください。これにより、データベースの更新は、万国標準時 (グリニッジ標準時) を使って正しく行われます。時刻が重要な他のサービスに複製サーバーが使用されると、このことが問題の原因となるおそれがあります。複数の時間帯にまたがるドメインを動作させるには、 NIS+ をインストールするときに、複製サーバーの /etc/TIMEZONE ファイルを、マスタサーバーの時間帯に合わせてローカルに設定する必要があります。複製サーバーがいったん動作を始めると、時刻が重要なプログラムの中には、万国標準時かローカル時刻のどちらを使用するかによって、正しく作動するものとしないものがでてきます。

情報管理

NIS+ 名前空間の情報の管理は、中央の制約の範囲内でローカルに行うことをお勧めします。情報は、できるかぎりそのホームドメインで管理するべきですが、広域の名前空間レベルで設定された指針または方針に従ってください。これにより、ドメインの独立性を強化する一方で、ドメイン間の整合性を維持することができます。

ドメイン名

名前の長さと複雑さについて検討します。まず、内容がわかりやすい名前を選択します。たとえば、 Sales は BW23A よりも内容をわかりやすく表しています。次に、短い名前を選択します。管理業務をより簡単にするためには、あまり長い名前を付けないでください (例: administration_services.corporate_headquarters.doc.com.)。

ドメイン名は、左から右に形成され、ローカルドメインから始まって、ルートドメインで終わります。ルートドメインには、常に少なくとも 2 つのラベルがなければならず、ドットで終了しなければなりません。2 番目のラベルは、 "com." などの Internet のドメイン名にすることができます。

サイト内とインターネット全体の電子メールドメインを対象に、このドメイン固有の名前の意味について検討する必要があります。

移行の方式によっては、NIS 上のドメイン名を希望の構造に変更してから、 NIS+ ドメインに移行することもできます。

電子メール環境

NIS が平坦なドメイン空間を持つのに対して、NIS+ はドメイン階層を持つことができるため、NIS+ への移行はメール環境にも影響があります。NIS では、必要な mail ホストは 1 つだけです。NIS+ でドメイン階層を使用すると、名前空間の各ドメインごとに 1 つの mail ホストが必要になります。これは、各ドメインの名前が一意ではなくなるためです。

したがって、ルートドメインにないクライアントの電子メールアドレスが変更される場合があります。一般的に、クライアントの電子メールアドレスは、ドメイン名が変更されるか、または階層に新しいレベルが追加されると変更されます。

以前の Solaris のリリースでは、これらの変更に非常に手間がかかりました。このリリースでは、sendmail の拡張機能がいくつか追加され、作業が簡単になっています。さらに、NIS+ には、sendmailvars テーブルが追加されています。sendmail プログラムは、まず sendmailvars テーブル (表 2-5 を参照) を見てから、ローカルな sendmail.cf ファイルを調べます。

注 -

mail サーバーが、そのサポート対象となるクライアントの NIS+ ドメイン内にあることを確認してください。また、性能上の理由から、 mail サーバーに対して他のドメイン内のテーブルへのパスを指定しないでください。

DNS での新しい mail アドレスの影響について検討してください。DNS の MX レコードを修正しなければならない場合があります。

サーバーの必要条件を決める

各 NIS+ ドメインは、一組の NIS+ サーバーによってサポートされています。各組は、1 つのマスタサーバーと 1 つ以上の複製サーバーを持っています。これらのサーバーは、ドメインのディレクトリ、グループ、テーブルを格納して、ユーザー、管理者、アプリケーションからのアクセス要求に応答します。各ドメインをサポートしているのは、一組のサーバーだけです。一組のサーバーで、複数のドメインをサポートすることができますがお勧めできません。

NIS+ サービスでは、マスターサーバーを少なくとも 1 つ各 NIS+ ドメインに割り当てる必要があります。各ドメインが必要とする複製サーバーの数は、通信量の負荷、ネットワークの構成、NIS クライアントの有無などによって決まります。サーバーメモリーの量、ディスク記憶容量、プロセッサの速度は、クライアントの数とサーバー上に置かれる通信量の負荷によって決まります。

Solaris オペレーティング環境が動作しているワークステーションで、十分な容量のハードディスクさえ備わっていれば、NIS+ サーバーにすることができます。NIS+ のサーバー用、クライアント用のソフトウェアは、どちらも Solaris 製品に含まれています。したがって、Solaris オペレーティング環境がインストールされているワークステーションであれば、サーバーかクライアント、またはこの両方にすることができます。

NIS+ 名前空間をサポートするために必要なサーバーを決定するとき、次の節で説明する要因を考慮する必要があります。

サポートするドメインの数

初めに、階層内の各ドメインに 1 つのマスターサーバーを割り当てます。図 2-4 に割り当ての例を示します。

図 2-4 サーバーをドメインに割り当てる

Graphic

1 つ以上の複製を各ドメインに割り当てます。複製を使うと、マスターサーバーが一時的に使用不可能な場合でも、要求に応答することができます。使用する複製の数については、「名前空間の構造を設計する」を参照してください。

図 2-5 ドメインへの複製サーバーの追加

Graphic

複製サーバーの数

ドメインに最適なサーバーの数 (マスターと複製) は、数多くの要因によって決まります。

各種のマシンを使わないでドメインあたりの複製の数を十分なものにする 1 つの方法は、マルチホームのサーバーを作成することです。マルチホームサーバーとは、複数のイーサネットまたはネットワークインタフェースを持っているマシンをいいます。マルチホームサーバーは、1 つのドメイン内にある複数のサブネットにサービスを提供することができます (マスターあるいは複製サーバーに複数のドメインを設定することもできますが、これはお勧めできません)。

サーバーの速度

サーバーの速度が早いほど、 NIS+ の性能は向上します (しかし、その場合 NIS+ サーバーは SMP マルチスレッドハードウェアを有効に利用することはできません)。NIS+ サーバーは、平均的なクライアントと同等かそれ以上に強力にする必要があります。新しいクライアントのサーバーとして古いマシンを使うことはお勧めできません。

サーバーの速度以外に、その他の多くの要因が NIS+ の性能に影響を与えます。ユーザーおよびホストの数と種類、実行しているアプリケーションの種類、ネットワークトポロジ、負荷の密度、その他の要因すべてが NIS+ の性能に影響します。したがって、 2 つの異なるネットワークにおいて、同じサーバーハードウェアからまったく同じ性能を期待することはできません。

表 2-2 に示したベンチマーク数字は、比較のためにだけ示してあります。ネットワーク上の性能は、この数字とは違うこともあります。下に示したベンチマークの数字は、10000 エントリという標準的なテーブルサイズのテストネットワークに基づいています。表 2-2 を参照してください。

表 2-2 ハードウェア速度と NIS+ 動作の比較
 マシン 秒当たりの整合動作数 秒当たりの追加動作数
 SS5-110  400  6
 SS20-50  440  6
 PPro-200  760 13
 Ultra-167  800 11
 Ultra-200 1270  8

サーバーメモリーの容量

サーバーの絶対最低メモリー必要量は 32M バイトですが、中から大規模ドメインのサーバーは少なくとも 64M バイトを装備した方が良いでしょう。

理想的には、 NIS+ サーバーは、 有効な NIS+ テーブルすべての検索可能カラムのエントリすべてを RAM 内に一度に保存できるほど十分なメモリーが必要です。要するに、最適なサーバーメモリーは、すべてのNIS+ テーブルが必要とするの合計メモリー必要量になります。

分かりやすくするため、表 2-3 は検索可能カラムが 5 つある netgroup テーブルのメモリー必要量を示し、表 2-4 は passwd 、 host および cred テーブルのおおよそのメモリー必要量を示しています。

表 2-3 netgroups テーブルに必要なサーバーメモリー
 エントリの数 サーバーメモリー使用量 ( M バイト)
 6000 4.2
 60000 39.1
 120000 78.1
 180000 117.9
 240000 156.7
 300000 199.2

表 2-4 passwd テーブルに必要なおおよそのメモリー
 エントリの数 サーバーメモリー使用量 ( M バイト)
 6000 3.7
 60000 31.7
 120000 63.2
 180000 94.9
 240000 125.8
 300000 159.0
 1000000 526.2

他のテーブルには、検索可能な各カラムに対してエントリ当たりの平均バイト数に予測エントリ数を掛けると、メモリーサイズを予測することができます。たとえば、エントリが 10000 で検索可能カラムが 2 のテーブルがあるとします。最初のカラムでのエントリ当たりの平均バイト数は 9 で、 2 番目のカラムでのエントリ当たり平均バイト数は 37 です。したがって、計算結果は、 (10000 * 9) + (10000 * 37) = 46000 になります。

注 -

cred テーブルのエントリ数を予測するときは、ユーザーのローカル資格証明書に 1 つ、DES 資格証明書に 1 つずつ、すべてのユーザーが 2 つのエントリを持つことを忘れないでください。各マシンが使用するエントリは 1 つだけです。

標準的な NIS+ テーブルのそれぞれにある検索可能カラムの数については、「NIS+ 標準テーブル」を参照してください。

サーバーディスク容量

必要なディスク容量は、次の 4 つの要因によって決まります。

Solaris オペレーティング環境のソフトウェアは、インストールした量によって、220M バイトを超えるディスク容量を必要とすることがあります。正確な数字については、Solaris のインストールガイドを参照してください。また、サーバーが使用する他のソフトウェアの使用するディスク容量も計算に入れる必要があります。NIS+ ソフトウェア自体は、Solaris 2.4 配布の一部であるため、余分なディスク容量を使用しません。

NIS+ のディレクトリ、グループ、テーブル、クライアント情報は、/var/nis に格納されています。この /var/nis ディレクトリは、1 つのクライアントごとにおよそ 5K バイトのディスク容量を使用します。たとえば、名前空間に 1000 のクライアントがあると、/var/nis には、およそ 5M バイトのディスク容量が必要になります。ただし、同じく /var/nis に格納されるトランザクションのログが大量になる場合があるため、クライアントごとにディスク容量を追加する必要があるかもしれません。この場合は 10〜15M バイトの容量を追加するようお勧めします。つまり、1000 のクライアントがあるときは、15〜20M バイトを /var/nis に割り当ててください。トランザクションのログに対して定期的にチェックポイントを実行する場合、この数字を減らすことができます。 /var/nis には独立したパーティションを設けることをお勧めします。パーティションが独立していることにより、オペレーティングシステムのアップグレードを行う際、その作業が容易になります。

NIS+ を NIS と並行して使用するときは、/var/yp に対して、/var/nis に割り当てている量と同じ容量を割り当てて、NIS から転送する NIS マップを格納してください。

さらに、サーバーの通常のスワップ空間の所要量に加えて、rpc.nisd のサイズの 2 倍のスワップ空間も必要になります。システム上で rpc.nisd が使用しているメモリーの量を確認するには、 nisstat コマンドを実行します。詳細は、 rpc.nisd マニュアルページを参照してください。この空間のほとんどは、コールバック操作中や、 nisping-C によってディレクトリに対しチェックポイントを実行するか、複製サーバーが作成されるときに使用されます。これは、このような手続き中には、NIS+ サーバープロセス全体がフォークされるためです。使用するスワップ空間が、64M バイト未満になることはありません。

テーブルの構成を決める

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

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

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

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 か所で変更するだけですみます。関連するマップ全体の情報の整合性の維持について注意する必要はなくなりました。

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

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

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

表 2-5 NIS+ テーブル

NIS+ テーブル 

テーブル内の情報 

hosts

ドメイン内にあるすべてのワークステーションのネットワークアドレスとホスト名 

bootparams

ドメイン内にあるすべてのディスクレスクライアントのルート、スワップ、ダンプの各パーティションの位置 

passwd

ドメイン内のすべてのユーザーに関するパスワード情報 

cred

ドメインに属する主体の資格 

group

ドメイン内のすべての UNIX ® グループのグループパスワード、グループ ID、メンバー

netgroup

ドメイン内のワークステーションとユーザーが属するネットグループ 

mail_aliases

ドメイン内のユーザーの mail 別名に関する情報 

timezone

ドメインの時間帯 

networks

ドメイン内のネットワークとその標準的な名前 

netmasks

ドメイン内のネットワークとそれに関連するネットマスク 

ethers

ドメイン内にあるすべてのネットワークのイーネットアドレス 

services

ドメインで使用される IP サービスの名前とそのポート番号 

protocols

ドメインで使用される IP プロトコルのリスト 

rpc

ドメインで使用できる RPC サービスの RPC プログラム番号 

auto_home

ドメイン内のすべてのユーザーホームディレクトリの位置 

auto_master

オートマウンタマップ情報 

sendmailvars

mail ドメインを格納 

表 2-6 NIS マップと NIS+ テーブルの対応表

NIS マップ 

NIS+ テーブル 

注 

auto.home

auto_home

 

auto.master

auto_master

 

bootparams

bootparams

 

ethers.byaddr

ethers

 

ethers.byname

ethers

 

group.bygid

group

NIS+ グループとは異なる 

group.byname

group

NIS+ グループとは異なる 

hosts.byaddr

hosts

 

hosts.byname

hosts

 

mail.aliases

mail_aliases

 

mail.byaddr

mail_aliases

 

netgroup

netgroup

 

netgroup.byhost

netgroup

 

netgroup.byuser

netgroup

 

netid.byname

cred

 

netmasks.byaddr

netmasks

 

networks.byaddr

networks

 

networks.byname

networks

 

passwd.byname

passwd

 

passwd.byuid

passwd

 

protocols.byname

protocols

 

protocols.bynumber

protocols

 

publickey.byname

cred

 

rpc.bynumber

rpc

 

services.byname

services

 

ypservers

 

必要なし 

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 上位ドメイン内のテーブルへのパスを設定する

Graphic

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

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

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

リンク

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

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

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

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

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

Graphic

ユーザー名とホスト名の重複の解決

NIS+ は、要求が実行された場合に、その主体が人間なのかワークステーションなのかを区別できません。したがって、すべてのユーザー名は、同一の名前空間におけるマシン名と違うものでなければなりません。すなわち、一定の名前空間においては、ユーザーがマシン名と同じユーザー名を持つことができず、またユーザー ID と同じマシン名を付けることもできません。

たとえば、NIS 環境ではローカルマシンの名前が irina の場合も、ユーザーは irina というログイン名を使用できます。このユーザーのネットワークアドレスは、irina@irina となります。これは、NIS+ 環境では成立しません。サイトを NIS+ に変換する場合、ユーザーがログイン名を変更するか、あるいはユーザーのマシン名を変更する必要があります。同一のユーザー名とマシン名が存在する場合、その名前を持つマシンが同じ名前のユーザーに属していない場合でも問題となります。次に示す例は、NIS+ では無効となる重複した名前の例です。

この問題の一番の解決方法は、/etc 内のファイルすべてと NIS マップ をチェックしてから、 NIS+ テーブルを生成することです。重複している名前を見つけた場合は、ログイン名ではなくマシン名を変更し、後でマシンの元の名前の別名を作成してください。