FNS では、基本ネーミング操作の単一の簡単なインタフェースで、複数のネームサービスをフェデレートする方法が提供されます。FNS は、次の 3 つのエンタープライズレベルのネームサービスで機能するように設計されています。
「NIS+」(「FNS ポリシーと NIS+ との関連」および「FNS と NIS+ のネーミング」を参照)
「NIS」(「FNS ポリシーと NIS の関連」および「FNS と NIS のネーミング」を参照)
「ファイル」(「FNS ポリシーとファイルベースのネーミングの関連」および「FNS とファイルベースのネーミング」を参照)
また FNS は、「FNS ポリシーの対象となるクライアントアプリケーション」で説明しているようなプリンタおよびカレンダサービスなどのアプリケーションで機能するようにも設計されています。
FNS および NIS+ に関連する内容説明の概要については、「FNS と NIS+ のネーミング」を参照してください。NIS+ およびその用語を調べる場合は、このマニュアルの Part I および用語集を参照してください。一般的な NIS+ 環境の構造を学ぶときに便利です。
FNS では、NIS+ サーバー上のドメインレベルの org_dir NIS+ ディレクトリにある FNS テーブルに、エンタープライズのオブジェクトに対するバインドが格納されます。FNS テーブルは NIS+ テーブルに類似しています。これらの FNS テーブルには、次のエンタープライズ名前空間に対するバインドが格納されます。
「NIS+ ドメインと FNS 組織単位」で説明する「組織」の名前空間
「NIS+ ホストと FNS ホスト」で説明する「ホスト」の名前空間
「NIS+ ユーザーと FNS ユーザー」で説明する「ユーザー」の名前空間
組織、ホスト、ユーザーに関連付けて地域のサイトにネーミング可能な「サイト」の名前空間
組織、ホスト、ユーザーに関連付けてプリンタやカレンダなどのサービスにネーミング可能な「サービス」の名前空間
FNS では、優先 Solaris エンタープライズのネームサービスである NIS+ 内の組織、ユーザー、ホストのエンタープライズオブジェクトがネーミングされます。NIS+ ドメインは、ユーザーおよびマシンの論理コレクションとそれらについての情報で構成され、エンタープライズ内の階層組織構造のフォームを反映するように配列されます。
FNS は、NIS+ ドメインを FNS 組織にマッピングして、NIS+ で実行されます。組織単位名は、NIS+ ドメイン名に対応しており、完全指定された形式の NIS+ ドメイン名または NIS+ ルートに関連した NIS+ ドメイン名のどちらかを使用して識別されます。最上位の FNS 組織名前空間は、NIS+ ルートドメインにマップされ、初期コンテキストから名前 org/ を使用してアクセスされます。
NIS+ では、ユーザーおよびホストに「ホームドメイン」の概念があります。ホストまたはユーザーのホームドメインは、それらの関連付けられた情報を保持する NIS+ ドメインです。ユーザーまたはホストのホームドメインは、直接 NIS+「主体名」を使用して決定できます。NIS+ 主体名は、原子ユーザー (ログイン) 名または原子ホスト名と、NIS+ ホームドメイン名からなります。たとえば、ホームドメイン doc.com. を持つユーザー sekou には NIS+ 主体名 sekou.doc.com が付けられ、マシン名 vega には NIS+ 主体名 vega.doc.com が付けられます。
ユーザーの NIS+ ホームドメインは、ユーザーの FNS 組織単位に対応します。同様に、ホストのホームドメインは、その FNS 組織単位に対応します。
組織名の後のドットは、その名前が完全指定の NIS+ ドメイン名であることを示します。このドットがない場合は、その組織名は NIS+ ルートドメインに関連付けて解決される NIS+ ドメイン名です。
たとえば、NIS+ ルートドメインが doc.com. であり、サブドメイン ales.doc.com. を含む場合は、次のいくつかの名前で同じ組織が参照されます。
表 21-4 NIS+ での相対および完全指定の組織名の例
相対名 |
完全指定名 |
---|---|
org/ |
org/doc.com. |
org/sales |
org/sales.doc.com. |
manf という名前だけを含む NIS+ ドメインは存在しないため、名前 org/manf. (ドット付き) はありません。
NIS+ 名前空間のホストは、ホストのホームドメインの hosts.org_dir テーブルにあります。FNS 組織にあるホストは、対応する NIS+ ドメインの hosts.org_dir テーブル内のホストに対応します。FNS では、hosts テーブル内の各ホストにコンテキストが提供されます。
NIS+ 名前空間にいるユーザーは、ユーザーのホームドメインの passwd.org_dir テーブルのリストに入っています。FNS 組織にいるユーザーは、対応する NIS+ ドメインの passwd.org_dir テーブル内のユーザーに対応します。FNS では、passwd テーブル中の各ホストにコンテキストが提供されます。
FNS の fncreate コマンドを使用して、コマンドが実行されたホストのドメインに関連付けられた NIS+ 階層に FNS テーブルとディレクトリを作成します。fncreate を実行するには、そのドメインの NIS+ オブジェクトの読み取り、作成、変更、削除を許可する資格を得て、認証された NIS+ 主体になる必要があります。fncreate で作成した FNS テーブルの「所有者」になります。この許可を得る 1 つの方法は、ドメインの管理者特権を持つ NIS+ グループのメンバーになることです。
fncreate を実行する前に、NIS_GROUP
環境変数をドメインに対する NIS+ 管理グループ名に設定する必要があります。個別のユーザーが、ユーザーに関連する
FNS データを変更可能かどうかを指定できます。
NIS+ セキュリティの説明については、第 6 章「セキュリティの概要」を参照してください。
FNS および NIS に関連する概要と内容説明については、「FNS と NIS のネーミング」を参照してください。
FNS では、NIS をネームサービスとして使用する基本的なネーミングおよび属性の操作用に XFN インタフェースが提供されます。
FNS では、NIS マスターサーバー (および存在する場合は NIS スレーブサーバー) /var/yp/domainname ディレクトリにある FNS マップのエンタープライズオブジェクトへのバインドが格納されます。FNS マップは、構造と機能の面で FNS マップと類似しています。これらの NIS マップでは、次のエンタープライズ名前空間に対するバインドが格納されます。
エンタープライズ全体に関連するオブジェクトをネーミングするための名前空間を提供する「組織」。NIS がネームサービスの下にあるときは、NIS ドメインに対応する 1 つの組織単位コンテキストがある。この組織単位コンテキストは、NIS ドメイン名または、マシン NIS ドメイン名をデフォルトとする空白名によって FNS で識別される。
NIS ドメインの hosts.byname マップに対応する「ホスト」の名前空間。FNS では、hosts.byname マップにある各ホストにコンテキストが提供される
passwd.byname マップに対応する「ユーザー」の名前空間。FNS では、ドメインの passwd.byname にある各ユーザーにコンテキストが提供される
組織、ホスト、ユーザーに関連する地域サイトにネーミングするための「サイト」の名前空間
組織、ホスト、ユーザーに関連付けてプリンタやカレンダなどのサービスにネーミングするための「サービス」の名前空間
FNS では、他のオブジェクトをこれら 5 つの名前空間に関連付けてネーミングするためのコンテキストが提供されます。
FNS の fncreate コマンドを使用して、NIS マスターサーバーの /var/yp/domainname ディレクトリに FNS マップを作成します。これは、NIS ネームサービスのマスターサーバーと同じマシンか、または FNS マスターサーバーとして機能する異なるマシンで行えます。スレーブサーバーが存在する場合は、NIS は、通常の処理の一部として FNS マップをそれらにプッシュします。fncreate を実行するには、FNS マップのホストとなるサーバーの特権ユーザーになる必要があります。各ユーザーは、FNS データを変更できません。
FNS とファイルに関連する概要および内容説明については、「FNS とファイルベースのネーミング」を参照してください。
FNS では、ローカルのファイルをネームサービスとして使用する基本的なネーミングおよび属性の操作用に XFN インタフェースが提供されます。
FNS では、通常各マシンに NFS マウントされた /var/fn ディレクトリにあるファイル内のエンタープライズオブジェクトに対するバインドが格納されます。これらの FNS ファイルでは、次のエンタープライズ名前空間に対するバインドが格納されます。
エンタープライズ全体に関連付けてオブジェクトをネーミングする名前空間を提供する「組織」。ローカルのファイルがネームサービスの下にある場合は、システム全体を表す 1 つの組織単位コンテキストがある。この組織単位コンテキストは、FNS では常に org// として識別される
/etc/hosts ファイルに対応する「ホスト」の名前空間。FNS では、/etc/hosts ファイルにある各ホストにコンテキストが提供される
/etc/passwd ファイルに対応する「ユーザー」の名前空間。FNS では、/etc/passwd ファイルにある各ユーザーにコンテキストが提供される
組織、ホスト、ユーザーに関連付けて地域サイトをネーミングするための「サイト」の名前空間
組織、ホスト、ユーザーに関連付けてプリンタやカレンダなどのサービスにネーミングするための「サービス」の名前空間
FNS では、他のオブジェクトをこれら 5 つの名前空間に関連付けてネーミングするためのコンテキストが提供されます。
FNS の fncreate コマンドによって、コマンドが実行されるマシンの /var/fn ディレクトリに FNS ファイルを作成します。fncreate を実行するには、そのマシンでのスーパーユーザー特権を持つ必要があります。UNIX ユーザー ID に基づいて、各ユーザーは、FNS コマンドを使用して自身のコンテキスト、バインド、属性を変更することが許可されます。
FNS ポリシーの 1 つの目的は、ファイルシステム、およびカレンダマネージャ、印刷ツール、ファイルマネージャ、メールツールなどの DeskSet ツール、またこれらのツールをサポートする RPC、電子メール、印刷サブシステムなどのサービスなどの、共通して使用されるツールに一貫性を持たせることです。
これらの例のいくつかは、現在 Solaris 環境には導入されていませんが、FNS の使用方法を示すためにここに挙げます。
「カレンダ」
「username@hostname」の形の名前を使用して誰かのカレンダにアクセスする代わりに、たいていの場合は単にサイト、組織、またはユーザー名を入力する。カレンダをネーミングするときには、複合名を使用することもできる。たとえば、FNS でフェデレートするときには、次の形式の名前がカレンダマネージャで使用可能となる
bernadette
user/bernadette
site/pine.bldg-5 (Pine 会議室用のカレンダ)
org/sales (sales 組織用のカレンダ)
「印刷」
特定のプリンタを名前でネーミングする代わりに、ユーザー、サイト、または組織に関連付けてプリンタをネーミングできる。次のようなものがある。
ilych (ilych のデフォルトのプリンタ)
org/sales (組織のデフォルトのプリンタ)
site/pine.bldg-5 (Pine 会議室のプリンタ)
「ファイルアクセス」
ファイルシステムやファイルをネーミングするときに複合名を使用できる。オートマウンタは、FNS を使用して複合名の解決を可能にする。たとえば、/xfn/user/baruch/fs/.cshrc などのファイル名を使用して、ユーザー baruch の .cshrc ファイルを参照できる
「RPC」
サービスをホスト名、プログラム、およびバージョン番号でアドレス指定する代わりに、複合名を使用してサービスをネーミングできる。たとえば、user/hatori/service/rpc のようにユーザーまたは組織に関連付けて RPC サービスをネーミングできる
「メール」
同様に、複合名はメールの宛先をネーミングするために使用される。次のような名前を使用できる
angus
user/angus
org/mlist (組織のメールリスト)
site/pine.bldg-5 (会議室の調整係のメールボックス)
「他のデスクトップアプリケーション」
スプレッドシート、文書作成ツール、FAX ツールなどの他のデスクトップアプリケーションに複合名を引き渡すことができる。これらのアプリケーションには、それ自身の名前空間をサービスの名前空間に接続し、FNS フェデレーションの一部となるものもある
ここでは、カレンダサービスというアプリケーションを変更して、FNS ポリシーを使用する方法について説明します。この例では、ユーザーから FNS 複合名が提示され、承認される手順を示します。
DeskSet のカレンダサービスは、一般的なクライアントサーバーアプリケーションです。カレンダサーバーは、複数のマシンで動作し、ユーザーのカレンダを保持します。カレンダマネージャ (cm) は、デスクトップで動作し、適切なサーバーにコンタクトして必要なカレンダを入手します。
カレンダサービスは、次のような簡単なレジストリまたは検索のモデルを使用して FNS を利用します。
「バインド」
起動時に、サーバーは、user/jsmith/service/calendar などの管理するそれぞれのカレンダの複合名に対するそれ自身の ONC+ RPC アドレス (ホスト、プログラム、バージョン) を含むリファレンスをバインドし、サーバーの管理するカレンダを登録する
「検索」
cm を使用するときには、ユーザーは、単にユーザー名 (hirokani など) を入力するか、または以前に入力した名前のリストからユーザーを選択して、他のユーザーのカレンダを指定する。ユーザー名が hirokani の場合は、cm で複合名 user/hirokani/service/calendar が作成され、これを使用してカレンダを管理するサーバーと通信する必要のある RPC アドレスが検索される
前の例では、名前 calendar を使用して、カレンダのバインドを示しています。RPC プログラムを RPC 管理者に登録するのと同じように、カレンダサービスの開発者は、名前 calendar を FNS 管理者に登録します。「サービス名およびリファレンスの登録」を参照してください。
ここで使用した名前 calendar は 1 つの例です。FNS ポリシーによって、特定のサービス名が指定されるわけではありません。
カレンダサービスでは、カレンダをサイト、組織、およびホストに関連付け、一定の方法でそれらをネーミングして、FNS ポリシーをさらに利用できます。たとえば、カレンダを会議室 (サイト) と関連付け、ユーザーのカレンダのセットでその部屋の会議に利用可能な時間を見つけるのと同じように、サービスを使用して会議室のカレンダを多重表示できます。同様に、カレンダは、グループ会議の組織や、保守スケジュールを管理するホストに関連付けることができます。
カレンダマネージャ (cm) は、いくつかの簡単な手順に従って、ユーザーが指定する必要のあることを明確にします。
cm では、ユーザーからの複合名を承認して、カレンダが要求されたオブジェクト名を構成するためのツールが使用されます。
オブジェクトは、ユーザー、サイト、ホスト、または組織の名前になります。たとえば、ユーザーが名前 kuanda を入力すると、カレンダマネージャで複合名 user/kuanda が生成されます。このツールは、DeskSet アプリケーションのグループ間で共有できます。
cm は、XFN インタフェースを使用して、接尾辞 /service/calendar を含む名前を作成し、カレンダ名を入手します。
このカレンダ名は、プロセスの初期コンテキストに関連付けて解決されます。
続いて、名前 user/kuanda/service/calendar が解決されます。同様に、ユーザーがサイト名 pine.bldg-5 を入力した場合は、cm で名前 site/pine.bldg-5/service/calendar が生成され解決されます。
印刷やメールなどの他のサービスでも、類似の方法で FNS ポリシーを利用できます。