NIS+ は、さまざまなネットワーク情報をテーブルに格納します。NIS+ テーブルには、単純なテキストファイルやマップにはない、いくつかの機能があります。これらのテーブルは、列エントリ構造を持ち、検索パスを受け付けます。また、これらのテーブルをリンクして、いくつかの異なる方法で構成することもできます。NIS+ には事前構成された 16 個のシステムテーブルがあり、独自のテーブルを作成することもできます。表 10–1 は、事前構成した NIS+ テーブルを示します。
ネームサービスとして、NIS+ テーブルはオブジェクト自体ではなく、オブジェクトの参照情報を格納するように設計されています。そのため、NIS+ はエントリの大きなテーブルをサポートできません。テーブルに非常に大きなエントリがある場合、rpc.nisd は機能しません。
テーブル |
テーブル内の情報 |
---|---|
hosts |
ドメイン内の全マシンのネットワークアドレスとホスト名 |
bootparams |
ドメイン内の全ディスクレスクライアントのルート、スワップ、およびダンプパーティションの位置 |
passwd |
ドメイン内の全ユーザーに関するパスワード情報 |
cred |
ドメインに所属する主体の資格 |
group |
ドメイン内の全 UNIX グループのグループ名、グループパスワード、グループ id、およびメンバー |
netgroup |
ドメイン内のマシンやユーザーが所属できるネットグループ |
mail_aliases |
ドメイン内のユーザーのメール別名に関する情報 |
timezone |
ドメイン内の全マシンの時間帯 |
networks |
ドメイン内のネットワークとこれらの標準の名前 |
netmasks |
ドメイン内のネットワークとこれらに関連付けられているネットマスク |
ethers |
ドメイン内の全マシンの Ethernet アドレス |
services |
ドメイン内で使用される IP サービス名とそれらのポート番号 |
protocols |
ドメイン内で使用される IP プロトコルのリスト |
RPC |
ドメイン内で使用可能な RPC サービスの RPC プログラム番号 |
auto_home |
ドメイン内の全ユーザーのホームディレクトリの位置 |
auto_master |
自動マウンタのマップ情報 |
cred テーブルには NIS+ のセキュリティに関係する情報だけが入っています。これについては第 12 章「NIS+ 資格の管理」で説明します。
これらのテーブルには、ユーザー名からインターネットサービスまでの幅広い情報が格納されています。この情報の多くは、設定時または構成の手順の中で生成されます。たとえば、password テーブル内のエントリは、ユーザーアカウントが設定されたときに作成されます。hosts テーブル内のエントリは、マシンがネットワークに追加されたときに作成されます。また、networks テーブル内のエントリは、新しいネットワークが設定されたときに作成されます。
この情報はこのような広範囲にわたる操作によって生成されるため、このマニュアルでは詳細を説明していません。ただし、使いやすさを考慮して、テーブルの各列に含まれる情報は、第 23 章「NIS+ テーブルの情報」に要約してあります。詳細な説明は、グループを NIS+ グループやネットグループと区別する場合など、理解しにくい内容についてのみ行います。テーブルの情報の詳細は、Solaris の「システム管理マニュアルセット」と「ネットワーク管理マニュアルセット」を参照してください。
ドメインにさらに多くのオートマウントマップを作成できますが、必ず NIS+ テーブルとして格納し、auto_master テーブルの中に入れてください。オートマウントマップを作成して、ユーザー用に作成された auto_master に追加するときは、列名にはキー (key) と値 (value) が含まれている必要があります。オートマウントの詳細は、オートマウントまたは NFS ファイルシステムの関連マニュアルを参照してください。
NIS+ テーブルにはさまざまな種類の情報が格納されていますが、これらの基本構造はすべて同じで、行と列から構成されます。この列は、「エントリ」または「エントリオブジェクト」と呼ばれます。
クライアントは、キー、または検索可能な任意の列によりアクセスできます。たとえば、baseball という名前のマシンのネットワークアドレスを見つけるには、ホスト名の列を探して baseball を見つけます。
次に、baseball のエントリ行を移動して、そのネットワークアドレスを見つけます。
クライアントは、任意のレベルでテーブル情報にアクセスできる (つまり、テーブルに全体としてアクセスできる) ため、NIS+ は 3 つのレベルすべてにセキュリティ機構を提供しています。たとえば、管理者は、オブジェクトレベルで全員にテーブルの読み取り権を割り当て、列レベルで所有者に変更権を割り当て、エントリレベルでグループに変更権を割り当てることができます。テーブルのセキュリティの詳細は、第 15 章「NIS+ のアクセス権の管理」で説明しています。
テーブルには、その「ローカル」ドメインについての情報だけが収められています。たとえば、doc.com. ドメイン内のテーブルには、doc.com. ドメインのユーザー、クライアント、およびサービスについての情報だけが収められています。また、sales.doc.com. ドメイン内のテーブルには、sales.doc.com. ドメインのユーザー、クライアント、およびサービスについての情報だけが収められます。
あるドメイン内のクライアントが、別のドメインに格納されている情報を見つけようとした場合、完全指定名を使用しなければなりません。「環境変数 NIS_PATH」で説明したように、 環境変数 NIS_PATH
が正しく設定されていれば、NIS+ サービスによって自動的に処理されます。
情報を探すときにサーバーがたどる「検索パス」をどの NIS+ テーブルでも指定できます。この検索パスは、NIS+ テーブルをコロンで区切って順番に並べたものです。
>tabletable:table... |
検索パス内のテーブル名は、完全指定する必要はありません。テーブル名は、コマンド行で入力された名前と同じように展開されます。サーバーが自分のローカルテーブル内に情報を検出できなかった場合、サーバーはクライアントにテーブルの検索パスを返します。クライアントはそのパスを使用して、その情報が見つかるかまたは最後まで、検索パスに名前があるすべてのテーブルを順番に探していきます。
検索パスのメリットを次に示します。次のようなドメイン階層があるとします。
下位にある 2 つのドメインの hosts テーブルの内容は次のようになります。
表 10–2 hosts テーブルの例
sales.doc.com. |
|
manf.doc.com. |
|
---|---|---|---|
10.0.0.1 |
localhost |
172.18.0.1 |
localhost |
10.22.3.22 |
luna |
172.29.6.1 |
sirius |
10.22.3.24 |
phoebus |
172.29.6.112 |
rigel |
10.22.3.25 |
europa |
172.29.6.90 |
antares |
10.22.3.27 |
ganymede |
172.29.6.101 |
polaris |
10.22.3.28 |
mailhost |
172.29.6.79 |
mailhost |
ここで、sales.doc.com. ドメイン内の luna にログインしたユーザーが、別のクライアントにリモートログインする場合を考えてみます。このユーザーが完全指定名を指定しない場合、そのユーザーがリモートログインできるのは localhost、 phoebus、europa、ganymede、および mailhost の 5 台のマシンだけです。localhost, phoebus, europa, ganymede, and the mailhost.
sales.doc.com. ドメインの hosts テーブルの検索パスに、manf.doc.com. ドメインの hosts テーブルが指定されていると仮定します。
hosts.org_dir.manf.doc.com. |
これで sales.doc.com. ドメイン内のユーザーは、たとえば、rlogin sirius と入力することができ、NIS+ サーバーはこれを検出します。NIS+ サーバーはまずローカルドメインで sirius を探し、見つからなければ manf.doc.com. ドメイン内を探します。クライアントは manf.doc.com. ドメインをどのように認識するのでしょうか。第 2 章「NIS+ の紹介」で説明したように、この情報はディレクトリキャッシュに格納されています。これがディレクトリキャッシュにない場合、クライアントは、第 2 章「NIS+ の紹介」で説明したプロセスに従ってこの情報を入手します。
ただし、検索パスを指定する方法には、若干の欠点があります。ユーザーがたとえば、rlogin luba (luna でなく) などと間違った名前を入力した場合、サーバーは 1 つのテーブルではなく、3 つのテーブルを探さなければエラーメッセージを返せません。名前空間の全域に検索パスを設定した場合、1 つの操作は 2、3 個のドメインではなく、10 個のドメイン内のテーブルを検索してから終了します。もう 1 つの欠点は、多数のクライアントが NIS+ テーブルにアクセスする必要があるとき、複数のサーバーのセットと通信するために、パフォーマンスの低下を招くという点です。
また、mailhost は別名として使用されることが多いため、特定のメールホストについての情報を探したいときは、その完全指定名 (mailhost.sales.doc.com. など) を使用しなければなりません。 そうしないと、NIS+ は検索したすべてのドメインで見つけたすべてのメールホストを返します。
テーブルの検索パスを指定するには、「テーブルでの nistbladm コマンドの使用」で説明するように、nistbladm コマンドに -p オプションを付けて実行します。