第 4 章 NIS+ の名前空間

この章では、NIS+ の名前空間の構造、これをサポートするサーバー、およびこれを利用するクライアントについて説明します。

• 「NIS+ ファイルとディレクトリ」

• 「NIS+ 名前空間の構造」

• 「ディレクトリ」

• 「ドメイン」

• 「サーバー」

• 「NIS+ 主体 (クライアント)」

• 「命名規則」

• 「NIS+ の名前展開」

NIS+ ファイルとディレクトリ

表 4-1 は、NIS+ ファイルが格納される UNIX ディレクトリの一覧です。

nisinit など NIS+ 設定プロシージャーによって作成された /var/nis、/var/nis/data といったディレクトリ、およびその下のファイルは、名前を変更しないでください。Solaris 2.4 以前では、/var/nis ディレクトリに hostname.dict、hostname.log という 2 つのファイルが含まれていました。またサブディレクトリ /var/nis/hostname もありました。Solaris 2.5 を起動すると、2 つのファイル名は trans.log、data.dict となり、サブディレクトリ名は /var/nis/data となります。ファイルの「内容」も変更されており、Solaris 2.4 以前との互換性はなくなっています。したがって、これらのファイルやディレクトリを Solaris 2.4 での名前にしてしまうと、Solaris 2.4、2.5 双方の rpc.nisd で機能しなくなりますので名前を変更しないようにしてください。

Solaris オペレーティング環境では、NIS+ データディレクトリ (/var/nis/data.dict) は、マシンに依存しません。そのため、NIS+ 名を簡単に変えることができます。また、NIS+ のバックアップコピーを使用したり機能を復元したりして、NIS+ のデータをひとつのサーバーから別のサーバーに転送もできます。「バックアップと復元を使用して複製サーバーを設定する」を参照してください。

NIS+ 名前空間の構造

NIS+ の名前空間は、NIS+ によって格納された情報を配置したものです。この名前空間は、組織のニーズに合わせていろいろな方法で配置することができます。たとえば、3 つの部門を持つ組織の場合、その NIS+ の名前空間も各部門ごとに 1 つずつで 3 つの部分に分割されます。分割した各部分は、その部門のユーザー、ワークステーション、およびネットワークサービスについての情報を格納しますが、互いに通信することも簡単です。このような配置により、ユーザーによる情報へのアクセスや、管理者による情報の管理が更に容易に行えます。

NIS+ の名前空間の配置はサイトごとに異なりますが、ディレクトリ、テーブル、グループという構成はすべてのサイトが使用します。これらの構成は NIS+「オブジェクト」と呼ばれます。NIS+ オブジェクトは、UNIX のファイルシステムに似た階層形式に配置できます。たとえば、次の図を参照してください。左側の名前空間は、3 つのディレクトリオブジェクト、3 つのグループオブジェクト、および 3 つのテーブルオブジェクトから構成されています。右側の UNIX ファイルシステムは、3 つのディレクトリと 3 つのファイルから構成されています。

NIS+ の名前空間は UNIX ファイルシステムに似ていますが、重要な違いが 5 つあります。

• 両方ともディレクトリを使用するが、NIS+ の名前空間でのオブジェクトはテーブルとグループであり、ファイルではない

• NIS+ の名前空間は、その目的 (システム管理ツール) のために設計された NIS+ の管理コマンド、または Solstice^TM AdminSuite^TM

  ツールなどのグラフィカルユーザーインタフェース (GUI) を通じてだけ管理され、標準の UNIX ファイルシステムコマンドや GUI では管理できない

• UNIX ファイルシステム構成要素の名前はスラッシュで区切られる (/usr/bin) が、NIS+ の名前空間オブジェクト名はドットで区切られる (doc.com.)

• UNIX ファイルシステムの「ルート」へは、ディレクトリを右から左にたどっていけば到達する (/usr/src/file1) が、NIS+ の名前空間のルートは左から右にたどって到達する (sales.doc.com.)

• NIS+ オブジェクト名は、左から右に構成されているので、完全指定名は常にドットで終わる。また最後に「.」がないものは完全な名前とはみなされず、相対的な名前 (まだ上の階層があるという意味) であるとみなされる。

ディレクトリ

ディレクトリオブジェクトは、名前空間の骨格を形成します。ツリー構造に配置した場合、名前空間を別々に分けます。ディレクトリ階層を理解するには、木の根を一番上に置き、逆さまの木として見るとよく分かります。名前空間の一番上のディレクトリが「ルート」ディレクトリです。名前空間が 1 つの層だけの場合、ディレクトリは 1 つしかありませんが、そのディレクトリはルートディレクトリです。ルートディレクトリの下にあるディレクトリオブジェクトは、単に「ディレクトリ」と呼ばれます。

1 つの名前空間は複数の階層のディレクトリを持つことができます。

あるディレクトリと他のディレクトリの関係を考える場合、下側のディレクトリは「子」ディレクトリと呼ばれ、上側のディレクトリは「親」ディレクトリと呼ばれます。

UNIX のディレクトリは UNIX のファイルを入れるように設計されていますが、NIS+ のディレクトリは NIS+ オブジェクト (他のディレクトリ、テーブル、およびグループ) を入れるように設計されています。各 NIS+ のドメインレベルのディレクトリには、以下のサブディレクトリが含まれています。

• groups_dir - NIS+ グループ情報を格納する

• org_dir - NIS+ システムテーブルを格納する

• ctx_dir - FNS を使用しているときだけ使用する

技術的には、ユーザーはディレクトリ、テーブル、およびグループをどんな構造にでも配置することができます。しかし、名前空間内の NIS+ のディレクトリ、テーブル、およびグループは、「ドメイン」と呼ばれる構成に配置されるのが普通です。ドメインは、名前空間の別々の部分をサポートするよう設計されています。たとえば、あるドメインが会社の営業部門 (Sales Division) をサポートし、別のドメインが製造部門 (Manufacturing Division) をサポートできます。

ドメイン

1 つの NIS+ のドメインは、ディレクトリオブジェクト、その org_dir ディレクトリ、その groups_dir ディレクトリ、および NIS+ テーブルのセットから構成されます。

NIS+ のドメインは、実際に存在する名前空間の構成要素ではありません。これらは単に、現実の組織をサポートするために使用される名前空間の「一部分」を示すための便利な方法にすぎません。

たとえば、DOC 社に営業部門と製造部門があるとします。これらの部門をサポートするため、DOC 社の NIS+ 名前空間は、以下に示すような構造によって、3 つの主要ディレクトリグループに配置されることになります。

図 4-1 NIS+ ディレクトリ構造の例

このような構造を、3 つのディレクトリ、6 つのサブディレクトリ、およびいくつかの追加オブジェクトと表現するよりも、3 つのドメインと表現する方が便利です。

図 4-2 NIS+ ドメインの例

サーバー

すべての NIS+ ドメインは複数の NIS+「サーバー」によってサポートされます。サーバーは、ドメインのディレクトリ、グループ、およびテーブルを格納し、ユーザー、管理者、およびアプリケーションからのアクセス要求に応答します。各ドメインは、1 組の複数のサーバーだけによってサポートされます。ただし、この 1 組のサーバーは複数のドメインをサポートできます。

ドメインはオブジェクトではなく、オブジェクトの集合を意味するものであることを忘れないでください。したがって、ドメインをサポートするサーバーは、実際にはドメインにではなく、ドメインのメイン「ディレクトリ」に関連付けられています。

サーバーとディレクトリオブジェクトとのこうした接続は、ドメインを設定するときに行われます。操作説明についてはパート II「NIS+ の紹介と概要」で説明しますが、ここでは大切なことを 1 つ指摘しておきます。それは、この接続が確立されたときに、ディレクトリオブジェクトはそのサーバー名と IP アドレスを格納するということです。後述しますが、クライアントはこの情報を使用してサービス要求を送信します。

Solaris 8 リリースベースのワークステーションは、どれも NIS+ サーバーとなることができます。Solaris 2.4 のリリースには、NIS+ のサーバー用とクライアント用の両方のソフトウェアが入っています。したがって、Solaris 2.x がインストールされているワークステーションであれば、サーバーにもクライアントにも、あるいはその両方にもなることができます。クライアントとサーバーを区別するのは、その果たす役割です。ワークステーションが NIS+ サービスを提供している場合、それは NIS+ サーバーとして機能しています。ワークステーションが NIS+ サービスを要求している場合、これは NIS+ クライアントとして機能しています。

多数のクライアント要求にサービスを提供する必要があるため、NIS+ サーバーとして機能するワークステーションは、平均的なクライアントよりも高いコンピューティング能力と多くのメモリーを装備して構成されます。そして、NIS+ データを格納する必要があるため、より大型のディスクも装備することになります。しかし、性能を高めるためのハードウェアを除いては、サーバーと NIS+ クライアントとの本質的な違いはありません。

NIS+ ドメインをサポートするのは、マスターとその複製の 2 種類のサーバーです。

ルートドメインのマスターサーバーを「ルートマスター」サーバーと呼びます。1 つの名前空間には 1 つのルートマスターサーバーしか存在しません。他のドメインのマスターサーバーは、単にマスターサーバーと呼びます。同様に、ルート複製サーバーと単なる複製サーバーがあります。

マスターサーバーと複製サーバーは、両方とも NIS+ テーブルを格納し、クライアント要求に応答します。ただし、マスターサーバーはドメインのテーブルのマスターコピーを格納し、複製サーバーは複製だけを格納します。管理者は、情報をマスターサーバー内のテーブルにロードし、マスターサーバーはそれを複製サーバーに伝達します。

この配置には 2 つのメリットがあります。第 1 に、マスターテーブルが 1 組しか存在しないことから、テーブル間の不一致を避けることができます。複製サーバーによって格納されたテーブルは、マスターのコピーにすぎません。第 2 に、これによって NIS+ サービスの「信頼性」が大幅に向上します。マスターまたはスレーブのどちらかがダウンした場合、他のサーバーがバックアップとして機能し、サービス要求に応えることができます。

サーバーが変更を伝達する方法

NIS+ のマスターサーバーは、そのオブジェクトをすぐに更新します。しかし、更新内容を複製サーバーに伝達する前に、複数の更新をまとめ (バッチ) ようと試みます。マスターサーバーが、ディレクトリ、グループ、リンク、またはテーブルといったオブジェクトへの更新を受信した場合、約 2 分間ほかの更新が到着しないかどうかを待機して確認します。待機時間が終了すると、これらの更新をディスクと「トランザクションログ」の 2 カ所に格納します (メモリーにはすでに更新を格納)。

マスターサーバーはトランザクションログを使用して、名前空間への変更内容が複製に伝達されるまで、これを格納します。トランザクションログには、更新とタイムスタンプという 2 つの要素が記録されます。

更新とは、変更されたオブジェクトの実際のコピーです。たとえば、ディレクトリが変更された場合、更新はそのディレクトリオブジェクトの完全なコピーです。テーブルエントリが変更された場合、更新は実際のテーブルエントリのコピーです。タイムスタンプは、マスターサーバーによって更新が行われた時間を示します。

その変更内容をトランザクションログに記録したのち、マスターは自分の複製にメッセージを送信し、送信すべき更新があることを知らせます。各複製は、マスターから受信した最後の更新のタイムスタンプでこれに応答します。するとマスターは、各複製のタイムスタンプ以降にログに記録した更新を複製に送信します。

マスターサーバーがその複製サーバーをすべて更新すると、トランザクションログをクリアします。ドメインに新しい複製が追加された場合などには、マスターは、トランザクションログに記録されている最も早い時間のタイムスタンプよりもさらに前のタイムスタンプを複製から受け取ることがあります。この場合、マスターサーバーは全面的な「再同期」、つまり「resync」を行います。resync では、マスターに格納されているすべてのオブジェクトと情報を該当複製にダウンロードします。resync 実行中には、マスターと複製の両方がビジー状態となります。複製は要求に応答できません。マスターは、読み取り要求には応答できますが、更新要求は受け付けできません。両方とも「Server Busy - Try Again」というメッセージで応答します。

NIS+ 主体 (クライアント)

NIS+ 主体とは、NIS+ サービスに要求をするエンティティ (クライアント) のことです。

主体

一般ユーザーであってもスーパーユーザー (root) であってもログインをすれば NIS+ 主体になります。実際の要求は、前者の場合はクライアントユーザーから、後者の場合はクライアントワークステーションから送られます。つまり NIS+ 主体は、クライアントユーザーである場合と、クライアントワークステーションである場合とがあります。

また NIS+ サーバーから NIS+ サービスを提供するエンティティも、NIS+ 主体になることができます。NIS+ サーバーは、すべて NIS+ クライアントと考えることができるので、ここでの説明のほとんどは NIS+ サーバーにも当てはまります。

クライアント

NIS+ クライアントとは、NIS+ サービスを要求するように設定されたワークステーションです。NIS+ クライアントの設定では、セキュリティ資格 (credential) を設定し、クライアントを適切な NIS+ グループのメンバーとし、そのホームドメインを確認し、スイッチ構成ファイルを確認し、最後に NIS+ 初期設定ユーティリティを実行します (詳細は、パート II「NIS+ の紹介と概要」を参照)。

NIS+ クライアントは、セキュリティ上の制約に従って、名前空間のどの部分にもアクセスできます。つまり、認証されており、しかも適切なアクセス権が与えられている場合、名前空間内のどのドメインの情報やオブジェクトにもアクセスできます。

クライアントは名前空間全域にアクセスできますが、1 つのクライアントが所属するドメインは 1 つだけであり、これをその「ホーム」ドメインと呼びます。クライアントのホームドメインは、インストール時に指定されるのが普通ですが、インストール後でも変更または指定できます。クライアントの IP アドレスや資格など、クライアントについてのすべての情報は、そのホームドメインの NIS+ テーブルに格納されています。

NIS+ クライアントであることと、NIS+ テーブルに登録されていることは、微妙な違いがあります。あるワークステーションについての情報を NIS+ テーブルに入力しても、そのワークステーションが自動的に NIS+ クライアントになるわけではありません。これは単に、すべての NIS+ クライアントがそのワークステーションの情報を使用できるようにするだけです。そのワークステーションを実際に NIS+ クライアントとして設定しない限り、NIS+ サービスを要求することはできません。

逆に、あるワークステーションを NIS+ クライアントにしても、そのワークステーションについての情報は NIS+ テーブルに入力されません。これは単に、そのワークステーションで NIS+ サービスを受信できるようにするだけです。管理者がそのワークステーションについての情報を明確に NIS+ テーブルに入力しないと、他の NIS+ クライアントはその情報を入手できません。

クライアントが名前空間へのアクセスを要求した場合、実際には、クライアントは名前空間内の特定ドメインへのアクセスを要求していることになります。したがって、クライアントは、アクセスしようとしているドメインをサポートするサーバーに自分の要求を送信します。簡単に表現すると次のようになります。

クライアントはこのサーバーを、単純な試行錯誤によって認識します。クライアントは、自分のホームサーバーから始めて、正しいサーバーが見つかるまでサーバーを 1 台ずつ試していきます。サーバーがクライアントの要求に応じられない場合、サーバーは適切なサーバーの検索に役立つ情報をクライアントに送信します。やがて、クライアントは自分の情報キャッシュを構築し、適切なサーバーをより効率的に検索できるようになります。このプロセスの詳細を次に示します。

コールドスタートファイルとディレクトリキャッシュ

クライアントが初期設定されるとき、クライアントには「コールドスタートファイル」が与えられます。コールドスタートファイルの目的は、名前空間内のサーバーと連絡をとるための起点として使用できるディレクトリオブジェクトのコピーをクライアントに提供することです。ディレクトリオブジェクトには、アドレス、公開鍵、およびそのディレクトリをサポートするマスターサーバーと複製サーバーについての情報が収められています。通常、コールドスタートファイルには、クライアントのホームドメインのディレクトリオブジェクトが収められています。

コールドスタートファイルは、クライアントの「ディレクトリキャッシュ」を初期設定するためにだけ使用されます。ディレクトリキャッシュは、「キャッシュマネージャ」と呼ばれる NIS+ 機能によって管理され、クライアントが自分の要求を適切なサーバーに送信できるようにするためのディレクトリオブジェクトを格納しています。

名前空間のディレクトリオブジェクトのコピーを自分のディレクトリキャッシュに格納することによって、クライアントは、どのサーバーがどのドメインをサポートするかを知ることができます。クライアントのキャッシュの内容を表示するには、nisshowcache コマンドを使用してください (「nisshowcache コマンド」を参照)。簡単な例を次に示します。

これらのコピーを最新の状態に保つため、各ディレクトリオブジェクトには「生存期間」フィールドがあります。このデフォルト値は 12 時間です。クライアントがディレクトリオブジェクトを求めてディレクトリキャッシュを調べ、最近の 12 時間以内にこれが更新されていないことを発見した場合、キャッシュマネージャはオブジェクトの新しいコピーを獲得します。「nischttl コマンド」で説明するように、ディレクトリオブジェクトの生存期間の値は、nischttl コマンドで変更できます。ただし、生存期間を長くするほどオブジェクトのコピーが古くなる可能性が高くなり、生存期間を短くするほどネットワークトラフィックとサーバーのロードが増加することに注意してください。

ディレクトリキャッシュは、これらのディレクトリオブジェクトをどうやって蓄積するのでしょうか。前に説明したように、コールドスタートファイルはキャッシュ内の最初のエントリを提供します。したがって、クライアントが最初の要求を送信するとき、コールドスタートファイルによって指定されたサーバーに要求を送信します。その要求がそのサーバーによってサポートされるドメインへのアクセスである場合、そのサーバーは要求に応答します。

その要求が別のドメイン (たとえば、sales.doc.com.) へのアクセスである場合、サーバーは、クライアントが適切なサーバーを探すのを助けようとします。サーバーが、自分のディレクトリキャッシュ内に該当するドメイン用のエントリを保有している場合、そのドメインのディレクトリオブジェクトのコピーをクライアントに送信します。クライアントは、その情報を今後の参照用として自分のディレクトリキャッシュにロードし、そのサーバーに要求を送信します。

ほとんどありえないことですが、クライアントがアクセスしようとしているディレクトリオブジェクトのコピーを、サーバーが保有していない場合、そのサーバーは、自分のホームドメインのディレクトリオブジェクトのコピーをクライアントに送信します。ここには、そのサーバーの親のアドレスが登録されています。クライアントは、親サーバーを使ってこのプロセスを繰り返し、適切なサーバーを見つけるか、または名前空間内の全サーバーを試し終わるまで、これを繰り返します。クライアントがドメイン内の全サーバーを試し終わった後でどうするかは、そのネームサービススイッチ構成ファイルの指示によって決まります。詳細は、第 2 章「ネームサービススイッチ」を参照してください。

やがてクライアントは、名前空間内のすべてのディレクトリオブジェクトのコピーをキャッシュ内に蓄積します。したがって、これらディレクトリオブジェクトをサポートするサーバーの IP アドレスも蓄積することになります。クライアントが他のドメインへのアクセス要求を送信する必要があるとき、通常は、自分のディレクトリキャッシュの中から自分のサーバー名を見つけ、そのサーバーにアクセス要求を直接送信できます。

NIS+ サーバーはクライアントでもある

NIS+ サーバーは NIS+ クライアントでもあります。実際、ワークステーションをサーバーとして設定する (パート II「NIS+ の紹介と概要」を参照) には、その前にクライアントとして初期設定しなければなりません。唯一の例外はルートマスターサーバーであり、このサーバーには独自の設定を行う必要があります。

つまり、サーバーはドメインをサポートするだけではなく、ドメインにも「所属する」のです。つまり、クライアントになることによって、サーバーにはホームドメインがあるということです。サーバーのホスト情報は自分のホームドメインの hosts テーブルに格納され、その DES 資格は自分のホームドメインの cred テーブルに格納されます。他のクライアントと同様、サーバーは、自分のディレクトリキャッシュに記録されているサーバーに対して、サービス要求を送信します。

忘れてはならない重要な点は、ルートドメインを除いて、サーバーのホームドメインは、そのサーバーがサポートするドメインの「親」ドメインであるということです。

つまり、サーバーは 1 つのドメイン内のクライアントをサポートしますが、別のドメインの「クライアント」になるのです。ルートドメインを除いて、サーバーは自分のサポートするドメインのクライアントにはなれません。ルートドメインをサポートするサーバーには親ドメインがないため、これらはルートドメイン自体に所属します。

たとえば、次のような名前空間を考えてみます。

各サーバーがどのドメインをサポートし、どのドメインに所属するかを次に示します。

命名規則

NIS+ の名前空間内のオブジェクトは、「部分指定」と「完全指定名」という 2 種類の名前によって識別できます。部分指定名は「単純」名とも呼ばれ、単なるオブジェクトの名前か、または完全指定名の一部分です。ある管理業務を行なっている間にユーザーがオブジェクトまたは主体の部分指定名を入力した場合、NIS+ はその名前を完全指定名に展開しようと試みます。詳細は、「NIS+ の名前展開」を参照してください。

完全指定名とは、名前空間内でオブジェクトを探すために必要なすべての情報を含んだオブジェクトの完全な名前です。必要なすべての情報とはオブジェクトの親ディレクトリ (もしあれば)、最後のドットも含んだ完全なドメイン名などです。

これはオブジェクトの種類によって異なるため、各タイプと NIS+ の主体ごとの規則を別個に説明します。次の名前空間を例として使用します。

NIS+ の主体を含めて、この名前空間内の全オブジェクトの完全指定名を図 4-3 に要約します。

図 4-3 名前空間の構成要素の完全指定名

NIS+ ドメイン名

完全指定ドメイン名は左から右に作成され、ローカルドメインで始まってルートドメインで終わります。たとえば次のようになります。

doc.com. (ルートドメイン)

sales.doc.com. (サブドメイン)

intl.sales.doc.com. (サブドメイン)

最初の行はルートドメインの名前を示します。ルートドメインは、少なくとも 2 つのラベルを持ち、ドットで終わらなければなりません。最後 (右端) のラベルは自由につけられますが、インターネット上の互換性を維持するためには、表 4-2 に示されるようなインターネットの組織名、または 2、3 文字の地域識別子 (日本であれば .jp) をつける必要があります。

上の 2 行目と 3 行目は下位レベルドメインの名前です。

ディレクトリオブジェクト名

ディレクトリの単純名は、単にディレクトリオブジェクトの名前です。この完全指定名は、単純名にそのドメインの完全指定名を加えたものです (常に最後のドットを含む)。

groups_dir (単純名)

groups_dir.manf.doc.com. (完全指定名)

複数のディレクトリ層が 1 つのドメインを形成しないような変則的な階層を設定する場合、中間ディレクトリ名を含めるようにしてください。たとえば、次のようにします。

lowest_dir.lower_dir.low_dir.mydomain.com.

通常単純名は、同じドメイン内から使用され、完全指定名は、リモートドメインから使用されます。しかし、ドメインの NIS_PATH 環境変数に検索パスを指定することによって、リモートドメインから単純名を使用できます (「NIS+ の名前展開」を参照してください)。

テーブルおよびグループ名

完全指定されたテーブル名とグループ名は、オブジェクト名から始まり、ディレクトリ名をつけ、その後に完全指定されたドメイン名が続いて作られます。すべてのシステムテーブルオブジェクトは org_dir ディレクトリに格納されて、すべてのグループオブジェクトは groups_dir ディレクトリに格納されていることを忘れないでください。独自の NIS+ テーブルを作成した場合は、どこでも好きなところに格納できます。グループ名とテーブル名の例を次に示します。

admin.groups_dir.doc.com.
admin.groups_dir.doc.com.
admin.groups_dir.sales.doc.com.
admin.groups_dir.sales.doc.com.
hosts.org_dir.doc.com.
hosts.org_dir.doc.com.
hosts.org_dir.sales.doc.com.
hosts.org_dir.sales.doc.com.

テーブルエントリ名

NIS+ テーブル内のエントリを識別するには、その中にあるエントリとテーブルオブジェクトを識別する必要があります。このような名前を「インデックス付き」名と呼びます。この構文を次に示します。

[column=value,column=value,...],tablename 

Column はテーブル列の名前です。Value はその列の実際の値です。tablename はテーブルオブジェクトの完全指定名です。hosts テーブルのエントリ例を次に示します。

[addr=129.44.2.1,name=pine],hosts.org_dir.sales.doc.com.
[addr=129.44.2.2,name=elm],hosts.org_dir.sales.doc.com.
[addr=129.44.2.3,name=oak],hosts.org_dir.sales.doc.com.

括弧の中には、テーブルエントリを一意に識別するために必要な最小限の列の値のペアを使用できます。

一部の NIS+ 管理コマンドは、この構文のバリエーションを利用できます。詳細は、パート II「NIS+ の紹介と概要」の nistbladm、nismatch、nisgrep の各コマンドの説明を参照してください。

ホスト名

ホスト名の長さは 24 文字までで、使用できるのは文字、数字、ダッシュ (-)、および下線 (_) です。大文字と小文字の区別はありません。また先頭は英文字とします。スペースは使用できません。

ドット (.) を含むホスト名 (myco.2 など) は使用できません。これは、`myco.2' のように引用符を使用しても同じです。ドットを使用するのは、完全指定のホスト名の一部として表記するときだけです (myco-2.sales.doc.com など)。

またドメイン名とホスト名が同じにならないようにします。たとえば、sales ドメインがある場合は、ホスト名に sales を使用することはできません。同様に、home というホスト名がある場合には、ドメイン名に home を使用できません。これは、サブドメインについても同様です。たとえば、すでにホスト名として west がある場合には、sales.west.myco.com というサブドメインを作ることはできません。

NIS+ 主体の名前

NIS+ の主体名は、Secure RPC のネット名とよく混同することがあります。これらの名前については、パート II「NIS+ の紹介と概要」のセキュリティに関する章で説明します。念のためここで 1 つだけ違いを指摘しておきます。NIS+ の主体名は必ずドットで終わりますが、Secure RPC のネット名はドットで終わることは絶対ありません。

また、たとえ主体の資格が cred テーブルに格納されていても、cred テーブル名も org_dir ディレクトリ名も主体名には含まれません。

使用できる記号

名前空間名は、ISO ラテン 1 セットの印刷可能文字を自由に使用して作成できます。ただし、名前の先頭には次に示す文字は使用できません。@ < > + [ ] - / = . , : ;

文字列を使用するには、二重引用符で囲みます。名前の中に引用符を使用するには、その記号も引用符で囲みます (たとえば、o'henry を使用するには o"'"henry と入力します)。John Smith などのように空白スペースを組み込むには、次のように一重引用符の中で二重引用符を使用します。

`"John Smith"`

ホスト名に適用される制限については 「ホスト名」を参照してください。

NIS+ の名前展開

NIS+ のコマンドで完全指定名を入力することは面倒です。この作業を簡単にするため、NIS+ は名前展開機能を提供します。部分指定名が入力されると、NIS+ は別のディレクトリのもとでこのオブジェクトを見つけようと試みます。最初は、デフォルトドメインから探します。これは、このコマンドを入力したクライアントのホームドメインです。デフォルトドメインでオブジェクトが見つからなかった場合、このオブジェクトが見つかるまで、NIS+ はデフォルトドメインの親ディレクトリを下から上へ探していきます。2 つのラベルしかない名前に到達すると、検索を停止します。次にその例を示します。この例では、software.big.sales.doc.com. ドメインに所属するクライアントにログインしたと仮定します。

環境変数 NIS_PATH

環境変数 NIS_PATH の値を変更することによって、NIS+ が検索するディレクトリのリストを変更または拡張できます。NIS_PATH には、コロンで区切って複数のディレクトリ名を設定できます。次に例を示します。

setenv NIS_PATH directory1:    directory2: directory3 ...

または

NIS_PATH=directory1:    directory2: directory3 ...;export NIS_PATH

NIS+ は、これらのディレクトリを左から右へ検索していきます。たとえば、次のようになります。

$PATH や $MANPATH のように、変数 NIS_PATH には特殊記号 $ を使用できます。$ 記号は、ディレクトリ名に追加するか、または単独で追加できます。ディレクトリ名に追加した場合、NIS+ はその名前にデフォルトディレクトリを追加します。たとえば、次のようになります。

$ 記号を単独で使用する (たとえば、org_dir.$:$) 場合、NIS+ は前述のような標準の名前展開を実行します。つまり、デフォルトディレクトリの検索から始め、親ディレクトリへと進めていきます。NIS_PATH のデフォルト値は $ です。

NIS_PATH に追加や変更を加えると、NIS+ がより多くの検索を行わなければならないので、性能が低下するという点に注意してください。