第 10 章 NIS+ のテーブルと情報

この章では、これらのテーブルの構造と設定方法の概要について説明します。

NIS+ は、将来のリリースではサポートされなくなる可能性があります。NIS+ から LDAP への移行支援ツールは、Solaris 9 リリース以降で使用できます (『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照)。詳細については、http://www.sun.com/directory/nisplus/transition.html を参照してください。

NIS+ テーブル構造

NIS+ は、さまざまなネットワーク情報をテーブルに格納します。NIS+ テーブルには、単純なテキストファイルやマップにはない、いくつかの機能があります。これらのテーブルは、列エントリ構造を持ち、検索パスを受け付けます。また、これらのテーブルをリンクして、いくつかの異なる方法で構成することもできます。NIS+ には事前構成された 16 個のシステムテーブルがあり、独自のテーブルを作成することもできます。表 10–1 は、事前構成した NIS+ テーブルを示します。

ネームサービスとして、NIS+ テーブルはオブジェクト自体ではなく、オブジェクトの参照情報を格納するように設計されています。そのため、NIS+ はエントリの大きなテーブルをサポートできません。テーブルに非常に大きなエントリがある場合、rpc.nisd は機能しません。

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 テーブルの内容は次のようになります。

ここで、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 オプションを付けて実行します。

テーブルの設定方法

NIS+ テーブルの設定には 3 つまたは 4 つの作業が伴います。

1. org_dir ディレクトリの作成

2. システムテーブルの作成

3. システムテーブル以外のテーブルの作成 (必要に応じて)

4. 情報を入力してテーブルを生成 (populate) する

「NIS+ のファイルとディレクトリ」で説明したように、NIS+ のシステムテーブルは org_dir ディレクトリに格納されます。したがって、テーブルを作成するには、その前にテーブルを入れる org_dir ディレクトリを作成しなければなりません。これには 3 つの方法があります。

• nisserver スクリプトを使用。nisserver スクリプトは、ディレクトリとシステムテーブのルフルセットを作成します。nisserver スクリプトを実行することを推奨します。

• nismkdir コマンドを使用。nismkdir コマンドは単にディレクトリを作成するものです。

• /usr/lib/nis/nissetup ユーティリティを使用。nissetup ユーティリティは org_dir および groups_dir ディレクトリとシステムテーブルのフルセットを作成します。

nisserver スクリプトと、nissetup および nismkdir ユーティリティについては、「nismkdir コマンド」を参照してください。nismkdir コマンドに関するその他の情報については、「nismkdir コマンド」に説明があります。

nissetup ユーティリティのメリットは、サーバーが NIS 互換モードで動作しているドメインのテーブルに対して、適切なアクセス権を割り当てる機能です。-Y フラグを付けて実行すると、このユーティリティは作成するオブジェクトの「未認証」カテゴリに読み取りアクセス権を割り当てます。その結果、未認証の NIS クライアントは、そのドメインの NIS+ テーブルから情報を得ることができます。

NIS+ の 16 個のシステムテーブルと、これらに格納される情報の種類については、第 10 章「NIS+ のテーブルと情報」で説明します。これらを作成するには、前述の 3 つの方法を使用できます。nistbladm コマンドは NIS+ テーブルの作成と変更を行います。nistbladm コマンドで名前空間内のすべてのテーブルを作成できますが、入力量が多くなり、列の正確な名前やアクセス権を知っている必要があります。nisserver スクリプトを使う方が、はるかに簡単です。

システムテーブル以外のテーブル、つまり NIS+ によってまだ構成されていないテーブルを作成するには、nistbladm コマンドを使用します。オートマウントマップを追加する場合は、最初の列の名前が key、2 番目の列の名前が value になっている必要があります。

NIS+ テーブルを生成するには、NIS マップから行う方法、ASCII ファイル (/etc 内のファイルなど) から行う方法、および手作業の 3 つの方法があります。

NIS サービスからアップグレードしている場合、すでにネットワーク情報の大部分が NIS マップに格納されています。この情報を NIS+ テーブルに手作業で再入力する必要はありません。nispopulate スクリプトか nisaddent ユーティリティを使用すると自動的に転送できます。

ほかのネットワーク情報サービスを使用していない場合で、しかもネットワークデータを /etc 内のファイルで管理しているときも、この情報を再入力する必要はありません。nispopulate スクリプトか nisaddent ユーティリティを使用しても自動的に転送できます。

ネットワークをはじめて設定する場合、多くのネットワーク情報をすでにどこかに格納しているということはおそらくないでしょう。この場合、まず情報を入手して、次に NIS+ テーブルに手作業で入力する必要があります。これを行うには、nistbladm コマンドを使用できます。また、特定のテーブルの全情報を「入力ファイル」(これは本質的に /etc 内のファイルと同じです) に入力し、次に、nispopulate スクリプトか nisaddent ユーティリティを使用してファイルの内容を転送することによっても同じことが行えます。

テーブルの更新方法

ドメインが設定されると、サーバーはそのドメインの NIS+ テーブルの最初のバージョンを受け取ります。これらのバージョンはディスクに格納されますが、サーバーは起動されると、これらをメモリーにロードします。サーバーがテーブルに対する更新を受信すると、サーバーはそのメモリーにあるテーブルをすぐに更新します。サーバーが情報の要求を受信すると、その応答のためにメモリーにあるコピーを使用します。

もちろん、サーバーはその更新をディスクにも格納する必要があります。ディスクにあるテーブルを更新するには時間がかかるため、NIS+ の全サーバーはテーブル用の「ログ」ファイルを持っています。このログファイルは、テーブルに対して行われた変更内容を、ディスク上で更新できるまで、一時的に格納するように設計されています。ログファイルは、テーブル名を接頭辞として使用し、これに .log を追加します。たとえば、以下のようになります。

hosts.org_dir.log
bootparams.org_dir.log
password.org_dir.log
ipnodes.org_dir.log

ログファイルが大きくなりすぎて大量のディスク領域を占有しないように、ディスクにあるテーブルのコピーは毎日更新しなければなりません。このプロセスは「チェックポイントを実行する」と呼ばれます。これには、nisping -C コマンドを使用します。