第 2 章 NIS+ の紹介

この章では、NIS+ の概要を述べます。

NIS+ は、将来のリリースでサポートされない可能性があります。NIS+ から LDAP への移行支援ツールは、Solaris 9 オペレーティング環境で使用できます (パート V を参照)。詳細については 、http://www.sun.com/directory/nisplus/transition.html を参照してください。

NIS+ について

NIS+ はネットワークネームサービスの一種です。NIS+ は NIS を機能拡張したものではなく、新しいソフトウェアプログラムとなっています。

NIS+ ネームサービスは、ネットワークがどのような構造であっても、その周囲を取り巻くことにより、サービスを設置した組織の形態に適合するように設計されています。

NIS+ はマシンのアドレス、セキュリティ情報、メール情報、Ethernet インタフェース、ネットワークサービスなどの情報を 1 カ所に格納して、ネットワーク上のすべてのマシンからアクセスできるようにします。このように構成されたネットワーク情報を、NIS+「名前空間」と呼びます。

NIS+ 名前空間は階層構造となっていて、UNIX のディレクトリファイルシステムによく似ています。階層構造になっていることから、NIS+ 名前空間を企業組織の階層に合わせて構成できます。NIS+ 名前空間は、独立して管理できる複数のドメインに分割できます。クライアントは、適切なアクセス権があれば、自分のドメインだけではなく、ほかのドメインの情報にもアクセスできます。

NIS+ では、NIS+ 名前空間への情報の保存やその情報へのアクセスにクライアントサーバーモデルを使用します。各ドメインはいくつかのサーバーでサポートされています。主となるサーバーを「マスター」サーバー、補助用のサーバーを「複製」サーバーと呼びます。ネットワーク情報は、NIS+ 内部のデータベースにある 16 個の標準 NIS+ テーブルに格納されます。マスターサーバーと複製サーバーの両方で NIS+ サーバーソフトウェアが動作しており、NIS+ テーブルのコピーを維持しています。マスターサーバー上の NIS+ データの変更は、複製サーバーにも自動的に伝達されます。

NIS+ では高機能のセキュリティシステムによって、名前空間の構造と保存されている情報が保護されます。このシステムは、情報にアクセスしようとしているクライアントが正当なものであるかどうかを認証と承認によって確認します。「認証」とは、情報の要求者がネットワークの正当なユーザーであるかどうかを判定することです。「承認」では、ユーザーが情報を所有したり修正したりできるかどうかを確認します。

Solaris のクライアントは、ネームサービススイッチ (/etc/nsswitch.conf ファイル) を使用して、ワークステーションがどこからネットワーク情報を取り出すかを決定します。ネットワーク情報が保存されているのは、ローカルの /etc ディレクトリのファイル、NIS、DNS、NIS+ です。ネームサービススイッチには、情報の種類ごとに異なる情報源を指定することもできます。このスイッチの詳細は、第 1 章「ネームサービススイッチ」を参照してください。

NIS+ のメリット

NIS と比較すると、NIS+ には次のようなメリットがあります。

• 安全性の高いデータアクセス

• 階層構造を使用した分散型のネットワーク管理

• 非常に大きな名前空間の管理

• 異なるドメインにあるリソースへのアクセス

• 増分 (incremental) 更新

65 ページの「NIS+ のセキュリティ」で説明したセキュリティシステムを使用すれば、特定のテーブルの個々のエントリに対する特定のユーザーのアクセスを制御できます。このようなセキュリティ方式では、システムを安全に維持できます。また、NIS+ 名前空間全体またはテーブル全体を損傷する危険をおかすことなく、管理業務を広く分散させることができます。

NIS+ の階層構造により、名前空間に複数のドメインを置くことができます。ドメインに分割することにより、管理が容易になります。個々のドメインは完全に独立して管理できるため、システム管理者の負担が軽減され、非常に大きな名前空間の管理責任から解放されます。このように、セキュリティシステムを分散型のネットワーク管理と組み合わせることによって、管理作業の負担を分担することができます。

ドメインが個別に管理されているとしても、すべてのクライアントに名前空間内のすべてのドメインの情報を参照するアクセス権を与えることができます。クライアントは自分のドメイン内のテーブルしか見ることができないため、クライアントがほかのドメイン内のテーブルにアクセスするには、そのテーブルについて明示的にアドレスを指定しなければなりません。

増分更新とは、名前空間内での情報の高速の更新を意味します。ドメインは独立して管理されるため、マスターサーバーテーブルへの変更は、名前空間全体にではなく、その複製サーバーだけに伝達しますが、伝達が行われると、これらの変更はすぐに名前空間全体で有効になります。

NIS+ と NIS の違い

ネットワーク情報サービスプラス (NIS+) は、ネットワーク情報サービス (NIS) といくつかの点で異なります。NIS+ には、多くの新しい機能が追加されています。また、NIS と似た概念に対して、使用する用語が異なることがあります。わからない用語がある場合は、用語集を参照してください。次の表に、NIS と NIS+ の主な相違点を示します。

NIS+ は NIS に代わるものとして設計されました。NIS は、1980 年代に普及していたクライアントサーバーコンピューティングネットワークの管理要件に応えるものです。その当時のクライアントサーバーネットワークは、通常、クライアント数が数百を超えることはなく、多目的サーバーの数もわずかでした。これらのネットワークは数カ所のリモートサイトを結んでいるだけであり、しかもユーザーに専門知識があり信頼できたため、セキュリティを必要としませんでした。

しかしクライアントサーバーネットワークは 1980 年代半ば頃から急速な成長を遂げました。現在では、世界中のサイトに配置された 10〜100 台の専用サーバーにサポートされた 100〜10,000 台のマルチベンダークライアントが存在し、複数の公衆網に接続されています。さらに、ネットワークが格納する情報は、NIS の時代よりもはるかに急速に変化しています。このようなネットワークの規模と複雑性に対処するため、新しい管理方式が必要になりました。NIS+ はこれらの必要性に焦点をあてて設計されました。

NIS の名前空間は、フラットな状態で管理機能を集中管理しています。1990 年代に入りネットワークはスケーラビリティと管理の分散化を求めるようになったため、NIS+ の名前空間は DNS の場合のように階層ドメインをベースに設計されました。

たとえば、図 2-1 は doc という名前の親ドメインと、sales と manf という 2 つのサブドメインを持つ会社の例を示しています。

図 2-1 階層型ドメインの例

これによって NIS+ は、小規模から大規模まで、広い範囲のネットワークで使用できます。また、NIS+ のサービスを組織の成長に適合させることもできます。たとえば、ある会社が 2 つの部門に分かれた場合、それに対する NIS+ の名前空間を 2 つのドメインに分割し、これらを個別に管理できます。インターネットがドメインの管理を下のレベルに委譲するように、NIS+ のドメインも程度の差はあっても互いに独立して管理できます。

NIS+ は DNS と似たドメイン階層を使用しますが、NIS+ のドメインは DNS のドメインよりずっと多くの情報を持っています。DNS のドメインは、そのクライアントの名前とアドレスの情報を格納するだけです。一方 NIS+ のドメインには、組織の一部の中でのマシン、ユーザー、およびネットワークサービスについての「情報」が集められています。

ドメインをこのように分割することで、より個別に管理できるようになり、規模が拡大した場合にもうまく対処できますが、情報へのアクセスが以前より困難になることもありません。クライアントは他のドメインの情報にも、同じドメインと同じようにアクセスできます。あるドメインを別のドメインの内部から管理することもできます。

主サーバーは「マスター」サーバーと呼ばれ、バックアップサーバーは「複製」サーバーと呼ばれます。マスターサーバーと複製サーバーの両方で NIS+ サーバーソフトウェアが動作しており、NIS+ テーブルのコピーをともに維持しています。NIS の情報はマップに格納されますが、NIS+ の情報はテーブルに格納されます。主サーバーはオリジナルのテーブルを、バックアップサーバーはコピーを、それぞれ格納します。

しかし NIS+ は、NIS とはまったく異なる更新方式を使用します。NIS が開発された当時は、格納される情報の型はめったに変化しなかったため、NIS は安定性に重点を置いた更新方式によって開発されました。NIS テーブルの更新は手作業で処理され、大規模な組織では、すべての複製サーバーへの伝達に 1 日以上かかることもあります。この原因の一つは、マップ内の情報が変化するたびにマップ全体を再作成して伝達しなければならなかったからです。

しかし NIS+ は、複製サーバーに対する「増分 (incremental)」更新が可能です。マスターサーバー上での変更は依然として必要ですが、いったん変更すれば、複製サーバーに自動的に伝達され、すぐに名前空間全体から使用できるようになります。マップを「作成」したり、伝達を待つ必要はありません。

NIS+ の ドメイン構造、サーバー、およびクライアントの詳細については、それぞれ 「ドメイン」、「サーバー」、および 「NIS+ 主体とクライアント」 を参照してください。

NIS+ のドメインは、次に示すようなネームサービススイッチを使用して、その NIS+ クライアントを経由してインターネットに接続できます (例 1-1を参照)。このクライアントが DNS のクライアントでもある場合、自分のスイッチ構成ファイルを設定して、NIS+ テーブルだけでなく、DNS ゾーンファイルまたは NIS マップ内の情報を検索できます。

NIS+ は、マップやゾーンファイルではなく、「テーブル」に情報を格納します。NIS+ は 16 種類のあらかじめ定義したテーブル (つまり「システム」テーブル) を提供します。

各テーブルにはそれぞれ違う種類の情報が保存されます。たとえば、hosts テーブルにはマシンアドレスについての情報が、passwd テーブルにはネットワークのユーザーについての情報が格納されています。

NIS+ テーブルには、NIS で使用したマップに比べて大きく改善された機能が 2 つあります。第 1 に、NIS+ のテーブルは、最初の列 (キーと呼ばれることもある) だけではなく、任意の列ごとにアクセスできます。これによって、NIS で使用される hosts.byname や hosts.byaddr マップなどの二重マップが必要なくなります。第 2 に、NIS+ のテーブル内の情報は、3 つの細分化されたレベルでアクセスし、操作できます。テーブルレベル、エントリレベル、および列レベルです。NIS+ のテーブルとそこに格納されている情報については、第 10 章「NIS+ のテーブルと情報」で説明します。

NIS 管理者は、以下に示す原則および条件下で NIS を NIS+ と共に使用できます。

• 同一ドメインに NIS サーバーと NIS+ サーバーの両方が存在するNIS 管理者は同一ドメインで NIS サーバーと NIS+ サーバーの両方を動作させることは可能ですが、このような動作を長時間行わせることは望ましくありません。一般に、同一ドメイン内での NIS サーバーと NIS+ サーバーを両方使用するのは、NIS から NIS+ への短い移行期間だけに制限するべきです。

• サブドメインNIS 管理者のルートドメインのマスターサーバーで NIS+ が動作している場合は、NIS 管理者は、すべてのサーバーで NIS が動作しているサブドメインを設定できます。NIS 管理者のルートドメインのマスターサーバーで NIS が動作している場合は、NIS 管理者はサブドメインの設定はできません。

• 同一ドメインに複数のマシンが存在する

  • 同一ドメイン内のサーバーで NIS+ が動作している場合は、NIS+、NIS、または /etc ファイルを使ってネームサービス情報を取得するように、ドメイン内の各マシンを設定できます。NIS+ サーバーが NIS クライアントのニーズを満たすには、この NIS+ サーバーが NIS 互換モードで動作している必要があります。

  • 同一ドメイン内のサーバーで NIS が動作している場合は、NIS または /etc ファイルを使ってネームサービス情報を取得するように、このドメイン内の各マシンを設定できます (各マシンは NIS+ を使用することはできません) 。

  ネームサービスに使用されるサービスは、そのマシンの nsswitch.conf ファイルで制御されます。このファイルは、「スイッチ」ファイルと呼ばれています。詳細は、第 1 章「ネームサービススイッチ」を参照してください。

NIS+ のセキュリティ

NIS+ は、「承認と認証」という相補的なプロセスによって、名前空間の構造と格納する情報を保護します。

• 「承認 (authorization)」。「承認」は、名前空間の構成要素に対して、「誰がどのような操作を行えるのか」ということを指定することです。すべての構成要素について行われます。

• 「認証 (authentication)」。名前空間に対するアクセス要求はすべて、NIS+ によって「認証」されます。アクセス要求は、 NIS+ 主体から発行されます。NIS+ 主体には、プロセス、マシン、ルート、またはユーザーがなることができます。「正当な NIS+ 主体」とは、NIS+ 資格を持っているものを指します。名前空間へのアクセスが行われると、必ずその要求者 (主体) の認証が行われます。

NIS+ が要求どおりの動作をするのは、「主体が認証されていて (正当な資格を持っていて)、要求された操作が、該当する構成要素において承認されている」という場合のみです。資格がない (または完全でない)、要求された操作が承認されていないという場合、NIS+ はアクセス要求を拒否します。NIS+ セキュリティシステムの詳細は、第 11 章「NIS+ のセキュリティの概要」を参照してください。

Solaris 1.x と NIS 互換モード

Solaris 1.x または 2.x では、NIS+ を NIS が動作しているマシンで使用できます。つまり、NIS+ ドメイン内にあるマシンはそれぞれの nsswitch.conf ファイルを nisplus ではなく nis に設定できます。NIS を実行中のマシン上で NIS+ のサービスにアクセスする場合は、NIS+ のサーバーを「NIS 互換モード」で動作させる必要があります。

NIS 互換モードを使用すれば、Solaris オペレーティング環境を実行している NIS+ サーバーは、NIS+ クライアントからの要求に応答しながら、NIS クライアントからの要求にも応答できます。NIS+ は 2 つのサービスインタフェースを提供することによってこれを実現します。1 つが NIS+ クライアントの要求に応答し、もう 1 つが NIS クライアントの要求に応答します。

このモードでは、NIS クライアントに対してさらに設定や変更を行う必要はありません。実際、NIS クライアントは、応答しているサーバーが NIS サーバーではないことを意識する必要はありません。ただし、NIS 互換モードで動作している NIS+ サーバーは ypupdate と ypxfr のプロトコルをサポートしないため、複製またはマスターの NIS サーバーとしては使用できません。NIS 互換モードの詳細については、第 26 章「NIS から NIS+ への移行」 を参照してください。

さらに 2 つの相違を指摘しておく必要があります。1 つは、NIS 互換モードでサーバーを設定する命令が標準の NIS+ サーバーの設定に使用される命令とは少し異なるということです。もう 1 つの相違としては、NIS 互換モードは、NIS+ の名前空間内のテーブルに対するセキュリティにも関係があります。NIS のクライアントソフトウェアは、NIS+ サーバーが NIS+ クライアントに与える資格 (credential) を提供する機能がないため、NIS クライアントからの要求はすべて「未認証」として分類されます。したがって、NIS クライアントが NIS+ テーブル内の情報にアクセスできるように、NIS+ の名前空間内のテーブルは未認証の要求に対してアクセス権を提供しなければなりません。これはパート II で説明するように、サーバーを NIS 互換モードで設定するために使用されるユーティリティによって自動的に処理されます。認証プロセスと NIS 互換モードについては、第 26 章「NIS から NIS+ への移行」を参照してください。

NIS+ の管理コマンド

NIS+ では、名前空間を管理するのに必要なコマンドがすべて提供されています。次の表に、これらのコマンドについてまとめます。

NIS+ の API

NIS+ の API (アプリケーションプログラミングインタフェース) とは、アプリケーションが NIS+ のオブジェクトへのアクセスと修正を行うために呼び出す関数群です。NIS+ の API には 54 個の関数があり、それらは次の 9 つのグループに分類されます。

• オブジェクト操作関数 (nis_names())

• テーブルアクセス関数 (nis_tables())

• ローカル名関数 (nis_local_names())

• グループ操作関数 (nis_groups())

• アプリケーションサブルーチン関数 (nis_subr())

• その他の関数 (nis_misc())

• データベースアクセス関数 (nis_db())

• エラーメッセージ表示関数 (nis_error())

• トランザクションログ関数 (nis_admin())

設定および構成の前に

NIS+ 名前空間を構成する前に、次の作業を行う必要があります。

• NIS+ を使用するすべてのマシンの nsswitch.conf ファイルを正しく構成します。詳細は 第 1 章「ネームサービススイッチ」 を参照してください。

• NIS+ 名前空間のレイアウトを設計します。これには次の 2 つの作業があります。

  • 名前空間の設計。どんなドメイン名を付けるか。サブドメインを作るか。サブドメインを作るとしたら、それらをどのように編成するか。どのマシンをどのドメインに入れるか。ドメインを上位のドメインあるいはインターネットに接続するか。

  • サーバー要件の確認。各ドメインに複製サーバーをいくつ置くか。必要なサーバーの種類、処理速度、メモリ容量はどれほどか。サーバーのディスク容量はどれくらい必要か。

    名前空間の設計および推奨値の詳細については、第 26 章「NIS から NIS+ への移行」を参照してください。

• 名前空間がすでに存在している場合、NIS+ に移行するための準備をします。「名前空間がすでに存在する場合の設定」 を参照してください。

• ルートサーバーマシンを選択します。

• ルートマスターサーバーとして使用できるシステムが少なくとも 1 つは稼動していることを確認します。ルートマスターサーバーでは、/etc/passwd などのシステム情報ファイルに少なくとも 1 人のユーザー (root) が登録されていなければなりません 。通常のマシンのシステム情報ファイルには root が存在しますので、これが問題となることはないはずです。

NIS と NIS+

NIS と NIS+ は、いくつかの同じ作業を行います。ただし NIS+では、NIS で提供されない階層ドメイン、名前空間セキュリティ、その他の機能が使用できます。NIS と NIS+ の相違点の詳細は、第 26 章「NIS から NIS+ への移行」を参照してください。

NIS 管理者は、以下に示す原則および条件下で NIS を NIS+ と共に使用できます。

• 同一ドメインに NIS サーバーと NIS+ サーバーの両方が存在するNIS 管理者は同一ドメインで NIS サーバーと NIS+ サーバーの両方を動作させることは可能ですが、このような動作を長時間行わせることは望ましくありません。一般に、同一ドメイン内での NIS サーバーと NIS+ サーバーを両方使用するのは、NIS から NIS+ への短い移行期間だけに制限するべきです。クライアントから NIS サービスの要求があった場合に、NIS 管理者は、NIS+ を NIS 互換モードで動作させることができます。詳細は、第 26 章「NIS から NIS+ への移行」を参照してください。

• サブドメインNIS 管理者のルートドメインのマスターサーバーで NIS+ が動作している場合は、NIS 管理者は、すべてのサーバーで NIS が動作しているサブドメインを設定できます。NIS 管理者のルートドメインのマスターサーバーで NIS が動作している場合は、NIS 管理者はサブドメインの設定はできません。この操作は、NIS 管理者が NIS から NIS+ に切り換えるときに有用であるかもしれません。たとえば、互いに独立した複数の NISドメイン (ドメインは地理的に別々のサイトに置かれていることもある) を持った会社の中で、NIS 管理者がそれらのドメインをすべてリンクさせて NIS+ の下に 1 つの階層型マルチドメイン名前空間を構築するケースを考えてみます。この場合、NIS 管理者はまずルートドメインを NIS+ 下に設定し、次に従来の NISドメインをサブドメインとして指定できます。これらのサブドメインでは、NIS+ への切り換えが行われるまで NIS が継続して動作します。

• 同一ドメインに複数のマシンが存在する

  • 同一ドメイン内のサーバーで NIS+ が動作している場合は、NIS+、NIS、または /etc ファイルを使ってネームサービス情報を取得するように、ドメイン内の各マシンを設定できます。NIS+ サーバーが NIS クライアントのニーズを満たすには、この NIS+ サーバーが NIS 互換モードで動作している必要があります。第 26 章「NIS から NIS+ への移行」を参照してください。

  • 同一ドメイン内のサーバーで NIS が動作している場合は、NIS または /etc ファイルを使ってネームサービス情報を取得するように、このドメイン内の各マシンを設定できます (各マシンは NIS+ を使用することはできません) 。

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

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

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+ のデータをひとつのサーバーから別のサーバーに転送もできます。第 21 章「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 つの主要ディレクトリグループに配置されることになります。

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

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

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

サーバー

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

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

サーバーとディレクトリオブジェクトとのこうした接続は、ドメインを設定するときに行われます。ここで、重要なことを 1 つ指摘しておく必要があります。それは、この接続が確立されたときに、ディレクトリオブジェクトはそのサーバー名と IP アドレスを格納するということです。後述しますが、クライアントはこの情報を使用してサービス要求を送信します。

Solaris オペレーティング環境ベースのマシンは、どれも NIS+ サーバーとなることができます。各 Solaris リリースには、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.) へのアクセスである場合、サーバーは、クライアントが適切なサーバーを探すのを助けようとします。サーバーが、自分のディレクトリキャッシュ内に該当するドメイン用のエントリを保有している場合、そのドメインのディレクトリオブジェクトのコピーをクライアントに送信します。クライアントは、その情報を将来の参照用として自分のディレクトリキャッシュにロードし、そのサーバーに要求を送信します。

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

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

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

NIS+ サーバーは NIS+ クライアントでもあります。サーバーとして設定するマシンは、まずクライアントとして初期化する必要があります。唯一の例外はルートマスターサーバーであり、このサーバーには独自の設定を行う必要があります。

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

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

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

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

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

命名規約

NIS+ 名前空間内のオブジェクトは、「部分指定」および「完全指定」の 2 種類の名前によって識別できます。部分指定名は、「単純」名とも呼ばれ、オブジェクト名だけまたは完全指定名の一部です。管理操作中にオブジェクトまたは主体の部分指定名を入力すると、NIS+ によってその名前は完全指定名に展開されます。詳細については、「命名規約」 を参照してください。

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

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

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

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

NIS+ ドメイン名

完全指定ドメイン名は左から右に作成され、ローカルドメインで始まってルートドメインで終わります。

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

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

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

最初の行はルートドメインの名前を示します。ルートドメインは、少なくとも 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_PATH」 を参照)。

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

完全指定されたテーブル名とグループ名は、オブジェクト名から始まり、ディレクトリ名をつけ、その後に完全指定されたドメイン名が続いて作られます。すべてのシステムテーブルオブジェクトは 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 のネット名とよく混同することがあります。念のためここで 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+ がより多くの検索を行わなければならないので、性能が低下するという点に注意してください。

名前空間がすでに存在する場合の設定

NIS ドメインが NIS 名前空間にすでに存在する場合は、そのドメインを NIS+ 名前空間に同じフラット構造で移行することができます。移行したドメインは、あとで階層構造に変更できます。NIS から NIS+ に移行するときは、計画および準備方法について、第 26 章「NIS から NIS+ への移行」 を参照してください。NIS+ のスクリプトを使用すると、NIS マップのデータを利用して簡単に NIS+ を起動できます。第 4 章「スクリプトを使用した NIS+ の設定」 で、NIS+ スクリプトを使用してシステムファイルや NIS マップから NIS+ 名前空間を作成する方法を説明します。

ただし、名前空間がすでに存在している場合、スクリプトをスムーズに実行するため NIS+ への移行用の設定が必要です。移行の準備の詳細については、第 26 章「NIS から NIS+ への移行」 を参照してください。

準備に関する主な注意事項は次のとおりです。

• 「ドメインとホストには同じ名前を使用しない」。たとえば、ドメインが sales の場合、マシンの名前には sales を付けないでください。同様に、home という名前のマシンを使用している場合は、home という名前のドメインは作成しないでください。これはサブドメインの場合も同様です。たとえば、マシンに west という名前を付けている場合、sales.west.myco.com というサブディレクトリを作成しないでください。

• 「ホスト名にはドットを使用しない」。NIS+ では、マシン名とドメイン名の間や、親とサブドメインの間の区切りにドット (ピリオド) を使用します。このため、マシン名の中ではドットを使用できません。使用している場合は、NIS+ に移行する前に (スクリプトを実行する前に) 必ず変更してください。ホスト名中のドットは、ハイフンに置き換えます。たとえば、sales.alpha というマシン名を付けることはできません。このホスト名は、sales-alpha に変換できます。

• 「ルートサーバーが動作していることを確認する」。ルートサーバーになるマシンが起動されていることを確認します。また、スーパーユーザーとしてアクセスできることも確認します。

• 「データのロード元のローカル /etc ファイル、または NIS マップのエントリを確認する」。不正なエントリがないことを確認します。正しいデータが、所定の場所に正しい書式で記録されていることを確認します。エントリのうち、古いもの、無効なもの、破損しているものは削除します。また、不完全なエントリや一部のみのエントリも削除します。構成完了後は、いつでもエントリを追加できます。必要なエントリをあとから追加する方が、不完全なエントリや破損しているエントリを読み込もうとするよりも簡単です。

Solaris 2.4 以前では、/var/nis ディレクトリに hostname.dict、hostname.log という 2 つのファイルと、サブディレクトリ /var/nis/hostname がありました。またサブディレクトリ /var/nis/hostname もありました。Solaris 2.5 の NIS+ では、2 つのファイル名は trans.log、data.dict となり、サブディレクトリ名は /var/nis/data となります。Solaris 2.5 ではこれらのファイルの内容も変更されており、Solaris 2.4 以前との互換性はなくなっています。したがって、これらのファイルやディレクトリを Solaris 2.4 での名前にしてしまうと、Solaris 2.4、2.5 双方の rpc.nisd で機能しなくなります。ディレクトリ名もファイル名も変更しないでください。

2 通りの構成方法

ここでは、NIS+ 名前空間の 2 通りの構成方法を紹介します。

• 「設定 (構成) 用のスクリプトを使う方法」nisserver、 nispopulate、およびnisclient という 3 つの NIS+ スクリプトを使用して NIS+ を構成する方法については、この章と 第 4 章「スクリプトを使用した NIS+ の設定」で説明しています。最も簡単な方法であるため、お勧めします。

• 「NIS+ コマンドを使う方法」NIS+ コマンドを使用して NIS+ を構成する方法については、第 6 章「NIS+ クライアントの構成」、第 7 章「NIS+ サーバーの構成」、および 第 8 章「非ルートドメインの構成」 で説明します。NIS+ コマンドを使用すれば、NIS+ スクリプトより柔軟に構成できますが、複雑になります。NIS+ コマンドは、NIS+ スクリプトによって生成される名前空間と特性が大きく異なる名前空間を構成する必要があるときに、経験豊富な NIS+ 管理者だけが使用してください。

NIS+ コマンドセットを使用する場合は、ネームサービスに NIS+ を使用する各マシンの /etc ディレクトリに正しい nsswitch.conf ファイルが存在することも確認してください (第 1 章「ネームサービススイッチ」 を参照)。この作業は、NIS+ 構成スクリプトを使った場合は自動的に行われます。

NIS+ ディレクトリまたはドメイン、NIS+ サーバー、あるいは NIS+ 名前空間の削除方法については 第 22 章「NIS+ の削除」を参照してください。