第 2 章 NIS+ の紹介

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

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

NIS+ について

NIS+ は NIS によく似たネットワークネームサービスですが、より多くの機能を備えています。NIS+ は、NIS の拡張機能ではなく、新しいソフトウェアプログラムです。

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

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

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

NIS+ はクライアントサーバーモデルを使用して、NIS+ 名前空間に情報を格納し、またその情報にアクセスできます。各ドメインは複数のサーバーによってサポートされます。もっとも重要なサーバーは「マスター」サーバーと呼ばれ、バックアップサーバーは「複製」サーバーと呼ばれます。ネットワーク情報は、内部 NIS+ データベース内にある 16 個の標準 NIS+ テーブルに格納されています。マスターサーバーと複製サーバーは、両方とも NIS+ のサーバーソフトウェアを実行し、NIS+ テーブルのコピーを保持します。マスターサーバー上の NIS+ データの変更は、複製サーバーにも自動的に伝達されます。

NIS+ には、名前空間の構造とその情報を保護するために、高度なセキュリティシステムが組み込まれています。NIS+ は認証 (authentication) と承認 (authorization) を使用して、クライアントの情報要求に応えるべきかどうかを検証します。「認証」とは、情報の要求者がネットワークの正当なユーザーであるかどうかを判定することです。「承認」とは、要求された情報に関して特定のユーザーが入手または変更を許可されているかどうかを判定することです。

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

NIS+ のメリット

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

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

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

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

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

• 増分 (incremental) 更新

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

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

NIS+ の ドメイン構造、サーバー、およびクライアントの詳細については、それぞれ 「NIS+ のドメイン」、「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 互換モードの詳細については、『Solaris のシステム管理 (ネーミングとディレクトリサービス : NIS+ 編)』の「NIS+ サーバーの設定」を参照してください。

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

再起動を繰り返しても NIS 互換モードが持続するように設定する場合は、「NIS+ とサービス管理機能」の説明に従って、/lib/svc/method/nisplus ファイルを変更する必要があります。

NIS+ の管理コマンド

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

NIS+ サービスに関連したコマンド行管理タスクのほとんどは、サービス管理機能 (Service Management Facility、SMF) によって管理されます。SMF を NIS+ で使用する方法については、「NIS+ とサービス管理機能」を参照してください。SMF の概要については、『Solaris のシステム管理 (基本編)』の「サービスの管理 (概要)」を参照してください。詳細については、svcadm(1M) と svcs(1) の各マニュアルページも参照してください。

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+ 名前空間のレイアウトを設計します。レイアウトを設計する際、次の点を考慮してください。

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

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

    上記およびほかの設計上の考慮事項、および推奨ガイドラインの詳細については本書をよくお読みください。

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

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

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

NIS と NIS+

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

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

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

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

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

表 2–3 は、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 と現行バージョンのどちらの 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+ の管理コマンド、または管理用に設計された Solaris 管理コンソール^TM ツールなどのグラフィカルユーザーインタフェース (GUI) だけで管理され、UNIX 標準のファイルシステムコマンドや GUI では管理できない

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

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

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

NIS+ 名前空間のディレクトリ

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

1 つの名前空間には、複数の階層のディレクトリを割り当てることができます。

ディレクトリ間の関係を識別する場合には、下位ディレクトリは「子」ディレクトリと呼ばれ、上位ディレクトリは「親」ディレクトリと呼ばれます。

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

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

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

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

NIS+ のドメイン

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

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

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

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

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

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

NIS+ サーバー

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

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

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

Solaris プラットフォームベースのマシンは、どれも NIS+ サーバーとなることができます。このリリースには、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+ サービスに要求をするエンティティ (クライアント) のことです。

NIS+ 主体

一般ユーザーであってもスーパーユーザー (root) であってもログインをすれば NIS+ 主体になります。実際の要求は、前者の場合はクライアントユーザーから、後者の場合はクライアントマシンから送られます。つまり 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+ 機能によって管理されます。キャッシュマネージャには、クライアントが自身の要求を適切なサーバーに送信できるようにするためのディレクトリオブジェクトが格納されます。クライアントのコールドスタートファイルから取得された情報は、/var/nis 内の NIS_SHARED_DIRCACHE というファイルにダウンロードされます。

名前空間のディレクトリオブジェクトのコピーを自分のディレクトリキャッシュに格納することによって、クライアントは、どのサーバーがどのドメインをサポートするかを知ることができます。クライアントのキャッシュの内容を表示するには、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. (第 3 レベルのサブドメイン)

最初の行はルートドメインの名前を示します。ルートドメインは、少なくとも 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 文字までで、使用できるのは文字、数字、ダッシュ (-)、および下線 (_) です。大文字と小文字の区別はありません。また先頭は英文字とします。スペースは使用できません。

ドット (.) はホスト名には使用できません。たとえば、ホスト名には doc.2 などは使用できません。また、引用符で囲んだドットも、ホスト名には使用できません。たとえば、`doc.2' は使用できません。ドメイン構成要素を識別するために、完全指定ホスト名の一部として使用する場合にのみ、ドットを使用します。たとえば、doc-2.sales.doc.com. は、正しい完全指定のホスト名です。

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

NIS+ の主体名

NIS+ の主体名は、Secure RPC のネット名とよく混同することがあります。念のためここで 1 つだけ違いを指摘しておきます。NIS+ の主体名は必ずドットで終わりますが、Secure RPC のネット名はドットで終わることは決してありません。以下に、例を示します。

NIS+ の主体名

olivia.sales.doc.com.

Secure RPC netname

unix.olivia@sales.doc.com

また、たとえ主体の資格が 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+ への移行を始める前に、計画および準備に関する重要な情報について、『Solaris のシステム管理 (ネーミングとディレクトリサービス : NIS+ 編)』の「スクリプトを使用した NIS+ の設定」を参照してください。NIS+ のスクリプトを使用すると、NIS マップのデータを利用して簡単に NIS+ を起動できます。第 4 章「スクリプトを使用した NIS+ の設定」で、NIS+ スクリプトを使用してシステムファイルや NIS マップから NIS+ 名前空間を作成する方法を説明します。

ただし、名前空間がすでに存在している場合、スクリプトをスムーズに実行するため NIS+ への移行用の設定が必要です。

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

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

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

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

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

Solaris 2.4 以前では、 /var/nis ディレクトリに hostname.dict、hostname.log という 2 つのファイルが含まれていました。また、/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+ の削除」を参照してください。