この章では、FNS ポリシーについて説明します。
XFN は、フェデレートされた名前空間にあるオブジェクトをネーミングするためのポリシーを定義します。これらのポリシーは、次のような目的を持っています。
統一性のある複合名を簡単に作成する
アプリケーションおよびサービスでネーミングの一貫性を持たせる
簡単ながら十分な機能をもつポリシーを提供し、アプリケーションで特定環境に特別のポリシーを作成したり、実行したりする必要をなくす
アプリケーションの移植性を拡張する
異機種システム混在コンピュータ環境でのプラットフォーム同士の相互運用性を高める
FNS ポリシーには、すべての XFN ポリシーと Solaris 環境用の拡張機能が含まれます。
現在、コンピュータ環境は世界的な規模となり、広範囲なサービスを提供しています。ユーザーは、どのレベルのコンピュータ環境のサービスにもアクセスできます。FNS ポリシーは、グローバル、エンタープライズ、アプリケーションの 3 つのレベルのサービスに共通の枠組みを提供します。
FNS は、ネームサービスをどのように調整して使用するかについて次のようなポリシーをアプリケーション側に提供します。
エンタープライズ名前空間をフェデレートして、グローバル名前空間でアクセス可能にする方法を指定する
各プロセスの初期コンテキストにある名前およびバインドを指定する
組織、ホスト、ユーザー、サイト、ファイル、サービスなどのエンタープライズのオブジェクトに対するネームサービス
組織、ホスト、サイト、ファイル、サービスのエンタープライズのオブジェクト間の関係を定義する
これらのエンタープライズのオブジェクトのリファレンスに使用される名前の構文を指定する
FNS ポリシーでは、次のものは指定されません。
ネームサービスで使用される実際の名前
アプリケーション内のネーミング。アプリケーションレベルのネーミングは、個別のアプリケーションまたは関連アプリケーションのグループで行われる
オブジェクトがネーミングされた後に使用する属性
FNS ポリシーでは、エンタープライズ内の名前空間のタイプおよび配列と、アプリケーションが名前空間を使用する方法が指定されます。たとえば、名前空間が他のどの名前空間と関連するかが指定されます。ここで説明する FNS ポリシーには、XFN ポリシーへの拡張機能があります。これらは、注釈によって明確に定義されます。
FNS エンタープライズのポリシーでは、名前空間内でのエンタープライズのオブジェクトの配列が処理されます。各エンタープライズのオブジェクトは、独自の名前空間を持っています。
デフォルトでは、FNS には 7 つのエンタープライズオブジェクトと対応する名前空間があります。
「組織」(orgunit)
部、センター、課などのエンティティ。サイト、ホスト、ユーザー、サービスには、組織に関連する名前を付けることができる。組織に対する XFN 用語は、「組織単位」となる。初期コンテキストで使用されたときは、識別子 org は、orgunit の別名として使用できる
「サイト」(site)
「ホスト」(host)
「ユーザー」(user)
「ファイル」(fs)
「サービス」(service)
「プリンタ」(service/printer)
図 22-1 は、エンタープライズの名前空間が配列される方法を示しています。
ユーザーやホストなどの名前空間には、フェデレートされた名前空間で複数回表示されるものもあります。
これらの名前空間に適用されるポリシーは、表 22-2 に要約しています。
エンタープライズ名前空間は、フェデレートされた名前空間の原子名によって参照されます。
XFN では、先行する下線 (_) 文字を使用して、エンタープライズ名前空間の識別子が示されます。たとえば、_site となります。FNS では、下線 (_) なしの識別子の使用もサポートされます。下線なしの名前は、XFN ポリシーの範疇には入りません。site および printer のコンテキストも、XFN ポリシーの範疇には入りません。これらの原子名は、表 22-1 に挙げられています。
表 22-1 エンタープライズでのエンタープライズ名前空間の識別子
名前空間 |
XFN 識別子 |
FNS 識別子 |
解釈処理 |
---|---|---|---|
組織 |
_orgunit |
orgunit または org |
組織単位をネーミングするためのコンテキスト |
サイト |
_site |
site |
サイトをネーミングするためのコンテキスト |
ホスト |
_host |
host |
ホストをネーミングするためのコンテキスト |
ユーザー |
_user |
user |
ユーザーをネーミングするのためのコンテキスト |
ファイルシステム |
_fs |
fs |
ファイルをネーミングするためのコンテキスト |
サービス |
_service |
service |
サービスをネーミングするためのコンテキスト |
プリンタ |
|
printer |
プリンタをネーミングするためのコンテキスト (サービスの名前空間に従属) |
XFN の用語では、先行する下線のある名前は、「正規」名前空間識別子です。下線のない名前は、Solaris 環境用に「カスタマイズ」された名前空間識別子です。これらのカスタマイズされた名前空間識別子に printer を追加しても、Solaris 以外の環境では認識されません。正規の名前空間識別子は、他の環境でも常に認識され、互換性があります。
XFN 構成要素の区切り文字 (/) で、名前空間識別子を区切ります。たとえば、名前空間識別子 orgunit を組織単位名 west.sales とともに作成すると、複合名は orgunit/west.sales となります。
FNS では、次の 7 つの名前空間が提供されます。
「組織」(「組織単位の名前空間」を参照)
「サイト」(「サイトの名前空間」を参照)
「ホスト」(「ホストの名前空間」を参照)
「ユーザー」(「ユーザーの名前空間」を参照)
「ファイル」(「ファイルの名前空間」を参照)
「サービス」(「サービスの名前空間」を参照)
「プリンタ」(「サービスの名前空間」を参照)
組織単位の名前空間では、エンタープライズのサブ単位をネーミングするために階層になった名前空間が提供されます。各組識単位名は組織単位を表す「組織単位コンテキスト」と結合されています。組織単位名は、接頭辞 org/、orgunit/、または _orgunit/ によってネーミングされます。短縮形別名の org/ は、内部コンテキストだけで使用され、複合名の途中では使用されません。「エンタープライズ内のネーミングに対する初期コンテキストのバインド」および、「複合名の例」を参照してください。
NIS+ 環境では、組織単位は NIS+ のドメインおよびサブドメインに対応します。
NIS+ では、組織単位は必ずドメインおよびサブドメインにマップされます。それぞれの NIS+ ドメインおよびサブドメインに組織単位を与える必要があります。ドメインまたはサブドメインに論理、組織ユニットを与えることはできません。つまり、NIS+ ドメインまたはサブドメインを小規模な組織単位に分割することはできません。そのため、NIS+ ドメイン doc.com. と 2 つのサブドメイン sales.doc.com. および manf.doc.com. がある場合は、これら 3 つのドメインに対応する 3 つの FNS 組織単位を持つ必要があります。
組織単位は、ドットで区切られた右から左への複合名を使用してネーミングされます。ここでは、各原子要素がより大きな単位内の組織単位をネーミングします。たとえば、org/sales.doc.com. という名前は、doc.com. という名前のより大きな単位内にある sales をネーミングします。この例では、sales は、doc.com. の NIS+ サブドメインです。
組織単位名は、完全指定の NIS+ ドメインまたは相対名の NIS+ 名のどちらかになります。完全指定名には終端にドットが付きますが、相対名には付きません。そのため、終端のドットが組織名にある場合は、その名前は完全指定の NIS+ ドメイン名として処理されます。終端にドットがない場合は、その組織名は最上部の組織階層に対して相対的に解釈処理されます。たとえば、orgunit/west.sales.doc.com. は、west 組織単位をネーミングする完全指定名で、_orgunit/west.sales は、同じサブドメインをネーミングする相対的な名前です。
NIS 環境では、NIS ドメインに対応する組織単位は各エンタープライズ 1 つずつあります。この orgunit には、orgunit/domainname という名前が付けられ、ここでの domainname は NIS ドメイン名です。たとえば、NIS ドメイン名が doc.com である場合は、組織単位は org/doc.com です。
NIS 環境では、空の文字列を組織単位の省略形として使用できます。したがって、org// は、org/domainname に相当します。
エンタープライズレベルのネームサービスがファイルベースであるときには、1 つだけの FNS 組織単位が存在し、サブ単位はありません。ファイルベースのネーミングで許容される唯一の組織単位は org// です。
サイトの名前空間では、物理的位置でそのまま識別される地域名前空間が提供されます。たとえば、これらのオブジェクトには、キャンパスにある建物、ある階のマシンやプリンタ、建物内の会議室とその使用スケジュール、隣接するオフィスにいるユーザーなどがあります。サイト名は、接頭辞 site/ または _site/ で識別されます。
Solaris 環境では、サイトは複合名を使用してネーミングされます。複合名では、各原子名がより大きなサイト内のサイトを表わします。サイト名の構文は、ドット区切りの右から左であり、もっとも一般的な位置記述からもっとも特定の位置記述に配列された構成要素が含まれます。たとえば、_site/pine.bldg5 は、建物 5 にある Pine 会議室を表わし、site/bldg7.alameda は、あるエンタープライズの Alameda にある建物 7 を表わします。
ホストの名前空間では、コンピュータをネーミングするための名前空間が提供されます。ホスト名は、接頭辞 host/ または _host/ で識別されます。たとえば、host/deneb は、deneb という名前のマシンを識別します。
ホストは、「hostname」コンテキストでネーミングされます。ホストコンテキストには、フラットな名前空間があり、ホストコンテキストへのホスト名のバインドが含まれます。「ホストコンテキスト」では、そのホストで見つかったファイルやプリンタなどの、マシンに相対的なオブジェクトをネーミングできます。
Solaris 環境では、ホスト名は Solaris のホスト名に対応します。単一のマシンに対する別名で同じコンテキストが共有されます。たとえば、mail_server という名前がマシン deneb および altair の別名である場合、deneb と altair の両方で、mail_server に作成されたコンテキストが共有されます。
ネットワーク資源は、必要に応じてホストに関連付けてネーミングする必要があります。たいていの場合、組織、ユーザー、サイトなどの構成要素に関連して資源をネーミングした方がわかりやすくなります。ホスト名に依存すると、ユーザーは、あいまいで変更される可能性のある情報を覚えなくてはならなくなります。たとえば、ハードウェアの変更、ファイルスペースの使用、ネットワークの再構成などのために、ユーザーのファイルがあるサーバーから他のサーバーに移動されてしまう場合もあります。さらに、ユーザーは、同じファイルサーバーを共有することが多くなり、ファイルがホストに関連付けてネーミングされた場合に混乱を招きます。しかし、ファイルがユーザーに関連付けてネーミングされた場合は、このような変更はファイルのネーミング方法に影響しません。
ホスト名を使用した方が適切な場合もあります。たとえば、資源が特定のマシンだけで使用可能であり、他の構成要素に関連付けてその資源をネーミングする論理的方法がない場合には、ホストに関連付けてネーミングする意味があります。または、ファイルシステムでは、ファイルが多くのユーザーに共有されている場合、格納されているマシンに関連付けてファイルをネーミングする意味があります。
ユーザーの名前空間では、コンピュータ環境内のユーザーをネーミングするための名前空間が提供されます。ユーザー名は、接頭辞 user/ または _user/ で識別されます。
ユーザーは、「ユーザーコンテキスト」でネーミングされます。ユーザーコンテキストには、単一レベルの名前空間があり、「ユーザーコンテキスト」へのユーザー名のバインドが含まれます。ユーザーコンテキストでは、ユーザーに関連するファイル、サービス、資源などのオブジェクトをユーザーに関連付けてネーミングすることができます。
Solaris 環境では、ユーザー名は Solaris ログイン ID に対応します。たとえば、_user/inga は、ログイン ID が inga のユーザーを識別します。
ファイルの名前空間 (またはファイルシステム) では、ファイルをネーミングするための名前空間が提供されます。ファイル名は、接頭辞 fs/ または _fs/ で識別されます。たとえば、fs/etc/motd という名前では、/etc ディレクトリに格納されているファイル motd が識別されます。
ファイルの名前空間については、「FNS ファイルネーミング」で詳しく説明し、ファイルのコンテキストについては、「ファイルコンテキストの管理」で説明します。
サービスの名前空間では、エンタープライズ内のオブジェクトに使用される、または関連するサービスのための名前空間が提供されます。このようなサービスには、電子カレンダ、FAX、メール、印刷などがあります。サービス名は、接頭辞 service/ または _service/ で識別されます。
Solaris 環境では、サービスの名前空間は階層になっています。サービス名は、スラッシュ (/) で区切られた左から右の複合名です。サービスの名前空間を使用するアプリケーションは、この階層属性を利用し、そのアプリケーションのサブツリーを獲保します。たとえば、プリンタサービスはサービスの名前空間のサブツリー printer を獲保します。
FNS は、サービス名またはリファレンスタイプが選択される方法を指定します。これらは、サービスの名前空間を共有するサービス提供者によって決定されます。たとえば、カレンダサービスは、サービスのコンテキストにある名前 _service/calendar を使用してカレンダサービスをネーミングし、名前 calendar にバインドされたものを決定します。
米国 Sun Microsystems, Inc. は、service の名前空間の最初のレベルにある名前の登録を行います。新規名を登録するには、電子メールのリクエストを fns-register@sun.com まで送信するか、または書面で次の住所までご郵送ください。
FNS Registration Sun Microsystems, Inc. 901 San Antonio Road. Palo Alto, CA 94303 U.S.A. |
名前の使用目的についての簡単な説明と、その名前にバインドされるリファレンスのフォーマットの説明をお書き添えください。
プリンタの名前空間では、プリンタをネーミングするための名前空間が提供されます。プリンタの名前空間は、サービスの名前空間に関連 (従属) します。つまり、プリンタのサービスは、サービスの名前空間のサービスの一部です。プリンタ名は、接頭辞 service/printer または _service/printer で識別されます。たとえば、service/printer/laser1 では、laser1 という名前のプリンタが識別されます。
後続の / は、次のネーミングシステムにあるオブジェクトをネーミングします。あるネーミングシステムから他のネーミングシステムに移動するときに必ず必要となります。たとえば、名前 org/east.sales/service/printer では、org と east.sales の間のスラッシュは、上で説明した構成要素の区切り文字であり、組織名 (sales/) の最後の要素に続くスラッシュは、service 名前空間を組織単位名前空間から区切ります。したがって、org/west.sales/service/printer では、west.sales という組織単位の printer サービスがネーミングされます。
FNS は、表 22-1 に挙げたすべての原子名をそれ自身の使用のために名前空間識別子として獲保します。たとえば、_orgunit、org、_site、site などです。この制限事項は、「エンタープライズ名前空間の構造」にある名前空間の配列で定義されているように、名前空間識別子が現れるコンテキストに適用されます。それ以外の場合は、FNS は、他のコンテキストではこれらの原子名の使用を制限します。
たとえば、原子名 service は、user/fatima/service/calendar のように、ユーザー名に相対的な名前空間識別子として使用され、ユーザー fatima のサービスの名前空間のルートであることを意味します。FNS では、名前 user/ がバインドされるコンテキストは、名前空間識別子にではなく、ユーザー名に指定されるため、user/service のようにユーザー名として名前 service を使用することが禁止されるわけではありません。この場合、service は明確にユーザー名として解釈されます。一方で、/user/mikhail を使用すると、ユーザー mikhail とファイル (またはサブディレクトリ) /user/mikhail の区別がつきにくくなるため、user という名前のディレクトリは作成しないでください。
この項では、FNS ポリシーに従う名前の例を示します。これらのポリシーについては、表 22-2 を参照してください。
組織名、サイト名、ユーザー名、ホスト名、ファイル名、サービス名 (calendar や printer など) の名前は、例として使用されています。これらの名前は、FNS ポリシーでは指定されません。
組織の名前空間 (_orgunit、orgunit、または org) に関連付けることのできる名前空間は、user、host、service、fs、と site です。
以下に例を示します。
orgunit/doc.com/site/videoconf.bldg-5 では、組織 doc.com に関連するサイトの建物 5 にある会議室 videoconf がネーミングされる (orgunit に別名 org を使用して、org/doc.com/site/videoconf.bldg-5 を作成することもできる)
orgunit/doc.com/user/mjones では、組織 doc.com のユーザー mjones がネーミングされる
orgunit/doc.com/host/smptserver1 では、組織 doc.com に所属するマシン smptserver1 がネーミングされる
orgunit/doc.com/fs/staff/agenda9604/ では、組織 doc.com に所属するファイル staff/agenda9604 がネーミングされる
orgunit/doc.com/service/calendar では、組織 doc.com の calendar サービスがネーミングされます。ここでは、組織の会議スケジュールを管理する
user の名前空間に関連付けることができる名前空間は、service および fs です。
user/helga/service/calendar では、helga という名前のユーザーの calendar サービスがネーミングされる
user/helga/fs/tasklist では、ユーザー helga のホームディレクトリにあるファイル tasklist がネーミングされる
hosts の名前空間に関連付けることができる名前空間は、service および fs です。
host/mailhop/service/mailbox では、マシン mailhop と関連する mailbox サービスがネーミングされる
host/mailhop/fs/pub/saf/archives.96 では、マシン mailhop によってエクスポートされたファイルシステムのルートディレクトリにあるディレクトリ pub/saf/archives.96 がネーミングされる
sites の名前空間に関連付けることができる名前空間は、service および fs です。
site/bldg-7.alameda/service/printer/speedy では、bldg-7.alameda サイトにあるプリンタ speedy がネーミングされる
site/alameda/fs/usr/dist では、alameda サイトで使用可能なファイルディレクトリ usr/dist がネーミングされる
ファイル (fs) またはサービス (service) の名前空間に関連付けることができる名前空間はありません。たとえば、/services/calendar/orgunit/doc.com などの名前は作成できません。つまり、ファイルまたはサービスの名前空間に関連付けた複合名は作成できません。もちろん、/user/esperanza/service/calendar のように、他の名前空間に関連付けてファイル名またはサービス名を作成することは可能です。
FNS ポリシーでは、エンタープライズ名前空間の構造が定義されます。この構造の目的は、統一性のある名前を簡単に作成することです。このエンタープライズ名前空間構造には、2 つの主要なルールがあります。
狭い有効範囲のオブジェクトは、広い有効範囲のオブジェクトに関連してネーミングされる
名前空間識別子は、ある名前空間から次の名前空間への移行を表すために使用される
表 22-2 は、エンタープライズ名前空間を配列するための FNS ポリシーのまとめです。図 22-2 に、これらの FNS ポリシーに従う名前空間の配置の例を示します。
表 22-2 フェデレートされたエンタープライズ名前空間用のポリシー
名前空間 識別子 |
従属する名前空間 |
親コンテキスト |
名前空間編成 |
構文 |
---|---|---|---|---|
orgunit _orgunit org |
サイト、ユーザー、ホスト、ファイルシステム、サービス |
エンタープライズのルート |
階層 |
ドット区切り、右から左 |
site _site |
サービス、ファイルシステム |
エンタープライズのルート、組織単位 |
階層 |
ドット区切り、右から左 |
user _user |
サービス、ファイルシステム |
エンタープライズのルート、組織単位 |
フラット |
Solaris ログイン名 |
host _host |
サービス、ファイルシステム |
エンタープライズのルート、組織単位 |
フラット |
Solaris ホスト名 |
service _service |
アプリケーション固有 |
エンタープライズのルート、組織単位、サイト、ユーザー、ホスト |
階層 |
/ 区切り、左から右 |
fs
_fs |
なし |
エンタープライズのルート、組織単位、サイト、ユーザー、ホスト |
階層 |
/ 区切り、左から右 |
printer |
なし |
サービス |
階層 |
/ 区切り、左から右 |
エンタープライズの名前空間は、組織単位の周辺に構成されます。適切な名前空間識別子とオブジェクト名を使用して組織単位名を作成して、サイト、ホスト、ユーザー、ファイル、サービスの名前は、組織単位に関連付けてネーミングできます。
図 22-2 では、エンタープライズの sales 組織の西部事業部のユーザー myoko は、名前 orgunit/west.sales/user/myoko を使用してネーミングされます。
名前空間識別子 user を使用して、orgunit 名前空間から user 名前空間への移行を表していることに注意してください。同様に (適切な名前空間識別子を使用して)、ファイル名およびサービス名も、サイト、ユーザー、またはホストの名前に関連付けてネーミングできます。サイト名は、組織単位名に関連付けてネーミングできます。
簡単に均質な名前を作成することは、この構造を使用して達成されます。たとえば、エンタープライズ (orgunit/west) 内の組織単位名が分かれば、user の名前空間識別子とユーザーのログイン名で名前を作成して orgunit/west/user/josepha などの名前を作成し、エンタープライズに関連付けてユーザーをネーミングできます。
このユーザーのファイルシステムにあるファイルをネーミングするときには、orgunit/west/user/josepha/fs/notes などの名前を使用できます。
エンタープライズのルートコンテキストは、エンタープライズ名前空間のルートレベルにあるオブジェクトをネーミングするためのコンテキストです。エンタープライズのルートは、グローバルの名前空間でバインドされます。
エンタープライズのルートをネーミングする方法には、次の 2 つがあります。
.../rootdomain
org//
.../rootdomain/ を使用して、エンタープライズのルートを識別できます。
最初の 3 つのドット (...) は、グローバルのコンテキストを示す原子名 (「グローバル名前空間のポリシー」のグローバルのコンテキストについての説明を参照)
rootdomain/ は、エンタープライズのルートドメイン。たとえば、doc.com/ など
したがって、.../doc.com/ では、ルートドメインが doc.com である会社のエンタープライズのルートが識別されます。この例では、エンタープライズのルートに関連するサイトをネーミングするためのコンテキストは、.../doc.com/site/alameda または .../doc.com/site/alameda.bldg5 などの .../doc.com/site/ となります。
DNS のグローバルの建物を設定した場合は、.../rootdomain フォーマットだけを使用できます。
org// を使用して、エンタープライズのルートを識別できます。本質的に org// は、.../domainname/ に対する別名または機能的に相当するものです。org// を使用するときは、二重のスラッシュによって、ルートのエンタープライズコンテキストとそれに関連する名前空間が識別されます。
たとえば、org//site/alameda では、エンタープライズのルートに関連する Alameda サイトがネーミングされます。
反対に、org/ または orgunit/ (一重のスラッシュ) では、エンタープライズのルートに必ずしも相対的にネーミングされていない組織のコンテキストを示します。たとえば、org/sales/site/alameda のようになります。
次のオブジェクトは、エンタープライズのルートに関連付けてネーミングできます。
エンタープライズの組織単位
エンタープライズの最上位の組織単位にあるサイト (XFN ポリシーへの拡張)
エンタープライズの最上位の組織単位にいるユーザー
エンタープライズの最上位の組織単位にあるホスト
エンタープライズの最上位の組織単位に対するサービス
エンタープライズの最上位の組織単位に対するファイルサービス
これらのオブジェクトは、ターゲットオブジェクトの名前でターゲットオブジェクトの名前空間の名前空間識別子を作成して、ネーミングします。
組織のサブ単位は、エンタープライズのルートに関連付けてネーミングできます。
組織ルート名の場合は、orgunit または _orgunit のどちらかの名前空間識別子を使用して、従属する組織単位コンテキストに名前を作成できます。
たとえば、.../doc.com がエンタープライズ名である場合、組織単位にネーミングするためのコンテキストのルートは、.../doc.com/orgunit/ であり、組織単位名は .../doc.com/orgunit/sales や .../doc.com/orgunit/west.sales のようになります。または、 org//orgunit/sales でも同じ結果を得ることができます。
次のオブジェクトは、組織単位名に関連付けてネーミングできます。
その組織単位のサイト (XFN ポリシーからの拡張)
その組織単位にあるホスト
その組織単位にいるユーザー
その組織単位に対するサービス
その組織単位に対するファイルサービス
たとえば、名前 ...doc.com/orgunit/sales/service/calendar では、sales 組織単位のカレンダのサービスが識別されます。組織単位に関連付けてオブジェクトをネーミングする際の詳細は、「組織単位の名前空間」および 「組織に関連する名前を作成する」を参照してください。
サイトは、XFN ポリシーから拡張されています。
サイトは、次のものに関連付けてネーミングできます。
エンタープライズのルート
組織単位
エンタープライズのルートに関連付けてネーミングされたサイトは、最上位の組織単位に関連付けてネーミングされたサイトと同一になります。組織名の場合は、名前空間識別子の site または _site を使用して、サイトのコンテキストに名前を作成できます。たとえば、エンタープライズのルートが ../doc.com である場合、エンタープライズのルートに関連付けてサイトにネーミングするためのコンテキストは、../doc.com/site となります。サイトは、../doc.com/site/alameda のような名前になります。
次のオブジェクトは、サイト名に関連付けてネーミングできます。
サイトのスケジュールまたはカレンダ、プリンタ、および FAX などのサイトでのサービス
サイトで利用可能なファイルサービス
これらのオブジェクトは、ターゲットオブジェクトの名前空間とターゲットオブジェクト名の名前空間識別子でサイト名を作成して、ネーミングできます。たとえば、名前 site/Clark.bldg-5/service/calendar は、会議室 Clark.bldg-5 のカレンダのサービスでネーミングし、サイト名 site/Clark.bldg-5 とサービス名 service/calendar から作成されます。サイトに関連付けてオブジェクトにネーミングする際の詳細は、「サイトに関連する名前を作成する」を参照してください。
ユーザーは、次のものに関連付けてネーミングできます。
組織単位
エンタープライズのルート
エンタープライズのルートに関連付けてネーミングされたユーザーは、最上位の組織単位に関連付けてネーミングされたユーザーと同一になります。組織名の場合は、名前空間識別子の user または _user のどちらかを使用して、コンテキストに名前を作成できます。したがって、orgunit/east.sales で組織がネーミングされる場合は、orgunit/east.sales/user/hirokani で east.sales 組織単位にいるユーザー hirokani がネーミングされます。
次のオブジェクトは、ユーザー名に関連付けてネーミングできます。
ユーザーに関連するサービス
ユーザーのファイル
これらのオブジェクトは、ターゲットオブジェクトの名前空間とターゲットオブジェクト名の名前空間識別子でユーザー名を作成して、ネーミングされます。たとえば、名前 user/sophia/service/calendar では、ユーザー sophia に対するカレンダがネーミングされます。ユーザーに関連付けてオブジェクトにネーミングする際の詳細は、「ユーザーの名前空間」および 、「エンタープライズのルートとユーザー」を参照してください。
ホストは、次のものに関連付けてネーミングできます。
組織単位
エンタープライズのルート
エンタープライズのルートに関連付けてネーミングされたホストは、最上位の組織単位に関連付けてネーミングされたホストと同一になります。組織名の場合は、名前空間識別子の host または _host のどちらかを追加して、hostname のコンテキストに名前を作成できます。したがって、orgunit/west.sales で組織がネーミングされる場合は、名前 org/west.sales/host/altair で west.sales 組織単位にあるマシン altair がネーミングされます。
次のオブジェクトは、ホスト名に関連付けてネーミングできます。
ホストに関連するサービス
ホストによってエクスポートされたファイル
これらのオブジェクトは、ターゲットオブジェクトの名前空間とターゲットオブジェクト名の名前空間識別子でホスト名を作成して、ネーミングされます。たとえば、名前 host/sirius/fs/release では、マシン sirius によってエクスポートされたファイルディレクトリ release がネーミングされます。(ホストに関連付けてオブジェクトにネーミングする際の詳細は、「ホストの名前空間」および「ホストに関連する名前を作成する」を参照してください。)
サービスは、次のものに関連付けてネーミングできます。
組織単位
エンタープライズのルート
ユーザー
ホスト
サイト
エンタープライズのルートに関連付けてネーミングされたサービスは、最上位の組織単位に関連付けてネーミングされたサービスと同一になります。
サービスのコンテキストは、名前空間識別子 service または _service を使用して、関連する組織、サイト、ユーザー、またはホストに関連付けてネーミングされます。たとえば、orgunit/corp.finance で組織単位がネーミングされる場合は、orgunit/corp.finance/service/calendar で組織単位 corp.finance の calendar サービスがネーミングされます。ユーザーの名前空間および、ユーザーに関連付けてオブジェクトをネーミングする際の詳細は、「サービスの名前空間」および、「サービスおよびファイルに関連する名前を作成する」を参照してください。
FNS では、サービスの名前空間でのバインドのタイプが制限されるわけではありません。アプリケーションは、サービスのコンテキスト以外のタイプのコンテキストを作成し、サービスの名前空間でバインドできます。
FNS は、サービスのコンテキストに「汎用」コンテキストを作成することをサポートします。汎用コンテキストは、アプリケーション決定のリファレンスタイプを持つこと以外は、サービスのコンテキストに類似しています。汎用コンテキストの他のすべての属性は、サービスのコンテキストと同一です。
たとえば、World Intrinsic Designs Corp (WIDC) という名前の会社は、サービスの名前空間で名前 extcomm を獲保し、製品の外部通信ラインに関連するバインドを追加するための汎用コンテキストを参照します。extcomm にバインドされるコンテキストは、リファレンスタイプ WIDC_comm を持つ汎用コンテキストです。このコンテキストとサービスのコンテキストの違いは、このコンテキストが異なるリファレンスタイプを持っていることだけです。
サービス名は、「サービス名およびリファレンスの登録」で説明しているように、米国 Sun Microsystems, Inc. に登録する必要があります。
ファイルの名前空間は、次のものに関連付けてネーミングできます。
エンタープライズのルート
組織単位
ユーザー
ホスト
サイト
エンタープライズのルートに関連付けてネーミングされたファイルは、最上位の組織単位に関連付けてネーミングされたファイルと同一になります。ファイルのコンテキストは、名前空間識別子の fs または _fs を使用して、関連する組織、サイト、ユーザー、またはホストに関連付けてネーミングされます。たとえば、orgunit/accountspayable.finance で組織単位がネーミングされる場合は、名前 user/jsmith/fs/report96.doc でファイル report96.doc がネーミングされます。ユーザーのファイルサービスは、NIS+ の passwd テーブルで指定されているように、デフォルトではホームディレクトリになります。ユーザーの名前空間の詳細は、「ファイルの名前空間」 を参照してください。
この他には、ファイルシステムに従属するコンテキストのタイプはありません。
プリンタのコンテキストは、XFN ポリシーの拡張です。
プリンタの名前空間は、サービスのコンテキストでネーミングできます。プリンタのコンテキストは、名前空間識別子の printer を使用して、次のものに関連したサービスのコンテキストでネーミングされます。
組織単位
ユーザー
ホスト
サイト
たとえば、org/east.sales で組織単位がネーミングされる場合は、org/eastsales/service/printer では組織単位 east.sales のプリンタのサービスがネーミングされます。したがって lp1 という名前の固有のプリンタは、次のように識別されます。
org/east.sales/service/printer/lp1
この他には、プリンタに従属するコンテキストのタイプはありません。
初期コンテキストは、クライアントのユーザー、ホスト、およびアプリケーションがエンタープライズ名前空間の任意のオブジェクトに (結果的に) ネーミングできる開始点です。
図 22-3 に示すネーミングシステムは、初期コンテキストのバインドが影付きでイタリックになっている点を除いて図 22-2 に挙げたネーミングシステムと同一です。これらの初期コンテキストは、解決する名前を決定するユーザー、ホスト、またはアプリケーションの観点から示されています。
XFN では、「初期コンテキスト関数」の fn_ctx_handle_from_initial() が提供され、クライアントは初期コンテキストのオブジェクトを名前解決の開始点として得ることが可能になります。初期コンテキストには、名前空間識別子に対するフラットな名前空間があります。これらの初期コンテキスト識別子のバインドについては表 22-3 に要約し、その後の節でさらに詳細に説明しています。これらの名前は、必ずしもすべての初期コンテキストに表示されるわけではありません。たとえば、スーパーユーザーがプログラムを起動したときには、ホストとクライアントに関連するバインドのみが初期コンテキストに表示され、ユーザーに関連するバインドは表示されません。
表 22-3 エンタープライズ内のネーミングに対する初期コンテキストのバインド
名前空間 識別子 |
バインド |
---|---|
myself, _myself, thisuser |
名前解決しようとするユーザーのコンテキスト |
myens, _myens |
名前解決しようとするユーザーのエンタープライズのルート |
myorgunit, _myorgunit |
ユーザーの主要な組織単位のコンテキスト。たとえば、NIS+ 環境では、主組織単位はユーザーの NIS+ ホームドメインとなる |
thishost, _thishost |
名前解決しようとするホストのコンテキスト |
thisens, _thisens |
名前解決しようとするホストのエンタープライズのルート |
thisorgunit, _thisorgunit |
ホストの主要な組織単位のコンテキスト。たとえば、NIS+ 環境では、主組織単位はホストの NIS+ ホームドメインとなる |
user, _user |
ホストと同じ組織単位にいるユーザーがネーミングされるコンテキスト |
host, _host |
ホストと同じ組織単位にいるホストがネーミングされるコンテキスト |
org, orgunit, _orgunit |
ホストのエンタープライズにある組織単位の名前空間のルートコンテキスト。たとえば、NIS+ 環境では、これは NIS+ ルートドメインに対応する |
site, _site |
サイトの名前空間が構成された場合、最上位の組織単位にあるサイトの名前空間のルートコンテキスト |
XFN 用語では、接頭辞として使用される下線は、「正規」名前空間識別子と呼ばれます。この下線がなく、org および thisuser が追加された名前は、Solaris 用にカスタマイズされた名前です。Solaris カスタマイズの名前空間識別子は、他の Solaris 以外の環境で認識されるとは限りません。正規名前空間識別子は、他の環境でも必ず認識されるため移植性があります。
現在実装されている FNS では、初期コンテキストにある名前およびバインドの追加や修正はサポートされません。
初期コンテキストのバインドは、基本的に次の 3 つに分けられます。
ユーザーに関連するバインド (「ユーザーに関連するバインド」を参照)
ホストに関連するバインド (「ホストに関連するバインド」を参照)
短縮形のバインド (「短縮形のバインド」を参照)
FNS では、XFN 初期コンテキスト関数が呼び出されたときに、プロセスに関連付けられたユーザーが存在するものと仮定されます。この関連付けは、プロセスの実効ユーザー ID (euid) に基づいています。プロセスに対するユーザーの関連付けがプロセスの途中で変更されることはありますが、元のコンテキストハンドルは変更されません。
FNS では、名前解決を要求するユーザーに関連する初期コンテキストにある次のバインドが定義されます。
初期コンテキストにある名前空間識別子 myself (あるいは同義語の _myself または thisuser のどちらか) は、要求を行うユーザーのコンテキストで解決されます。ユーザー jsmith が所有するプロセスが名前解決を要求したときの例を示します。
名前 myself は、jsmith のユーザーのコンテキストとして初期コンテキストで解決される
myself/fs/.cshrc は、jsmith のファイル cshrc にネーミングする
FNS では、各ユーザーがエンタープライズの組織単位に関連するものと仮定されます。1 人のユーザーを複数の組織単位に関連させることはできますが、組織の名前空間での位置または組織内でのユーザーの役割によって、主な組織単位が必ず 1 つ必要です。
「NIS+」
NIS+ 名前空間では、この組織単位はユーザーのホームドメイン (これは、サブドメインになることもある) に対応する
「NIS」
NIS 名前空間では、ユーザーのドメインに対応するエンタープライズレベルの組織単位は 1 つしかない
「ファイル」
ファイルベースの名前空間では、組織単位は myorgunit にマップする org// しかない
名前空間識別子 myorgunit (または _myorgunit) は、要求を行うユーザーが所属する主組織単位のコンテキストとして初期コンテキストで解決されます。たとえば、要求を行うユーザーが jsmith で、jsmith のホームドメインが east.sales である場合は、myorgunit は east.sales の組織単位コンテキストとして初期コンテキストで解決され、名前 myorgunit/service/calendar は east.sales のカレンダのサービスで解決されます。
FNS では、各ユーザーがエンタープライズに関連するものと仮定されます。これは、myorgunit を保持する名前空間に対応します。
名前空間識別子 myens (および _myens) は、要求を行うユーザーが所属するエンタープライズのルートとして初期コンテキストで解決されます。たとえば、jsmith が要求を行い、jsmith の NIS+ ホームドメインが east.sales である場合、それは doc.com. のルートドメイン名を含む NIS+ 階層にあります。名前 myens/orgunit/ は、doc.com の最上部の組織単位で解決されます。
myorgunit または myself/service などのユーザーに関連する複合名を使用するときは、これらのバインドはプロセスの実効ユーザー ID に依存するため、ユーザー ID 設定プログラムに注意してください。ユーザー ID を root に設定して、呼び出し元に代わってシステムリソースにアクセスするプログラムでは、通常は fn_ctx_handle_from_initial() を呼び出す前に seteuid(getuid()) を呼び出してください。
XFN 初期コンテキスト関数が呼び出されたときには、特定のホストでプロセスが実行中です。FNS では、プロセス実行中のホストに関連する初期コンテキストにある次のバインドが定義されます。
名前空間識別子 thishost (または _thishost) は、プロセス実行中のホストのホストコンテキストにバインドされます。たとえば、プロセスがマシン cygnus で実行中である場合、thishost は cygnus のホストのコンテキストにバインドされ、名前 thishost/service/calendar はマシン cygnus のカレンダのサービスを参照します。
FNS では、ホストは組織単位に関連付けられていると仮定します。1 つのホストを複数の組織単位に関連付けることができますが、主となる組織単位が必要です。NIS+ 名前空間では、組織単位はホストのホームドメインに対応します。
名前空間識別子 thisorgunit (または _thisorgunit) は、プロセス実行中のホストの主要な組織単位に解決されます。たとえば、ホストがマシン cygnus であり、cygnus の NIS+ ホームドメインが west.sales である場合は、thisorgunit は west.sales として組織単位コンテキストで解決され、名前 thisorgunit/service/fax は組織単位 west.sales の FAX サービスを参照します。
FNS では、ホストがエンタープライズに関連するものと仮定されます。これは、thisorgunit を保持する名前空間に対応します。
名前空間識別子 thisens (または _thisens) は、プロセス実行中のホストのエンタープライズのルートで解決されます。たとえば、NIS+ で、ホストのホームドメインが sales.doc.com である場合、名前 thisens/site/ は doc.com. のサイトの名前空間のルートで解決されます。
FNS では、初期コンテキストにある次の短縮形バインドを定義し、短い名前を使用して、共通に参照される特定の名前空間を参照できます。
名前空間識別子 user (または _user) は、プロセス実行中のホストの組織単位にある username コンテキストとして初期コンテキストにバインドされます。これにより、同じ組織単位にいる他のユーザーをこのコンテキストからネーミングできます。
初期コンテキストから、名前 user および thisorgunit/user は同じコンテキストで解決されます。たとえば、プロセス実行中のホストがマシン altairであり、altair が east.sales 組織単位にある場合は、名前 user/medici で east.sales にいるユーザー medici がネーミングされます。
名前空間識別子 host (または _host) は、プロセス実行中のホストの組織単位にある hostname コンテキストとして初期コンテキストにバインドされます。これにより、同じ組織単位にいる他のホストをこのコンテキストからネーミングできます。
初期コンテキストから、名前 host および thisorgunit/host は同じコンテキストで解決されます。たとえば、プロセス実行中のホストがマシン sirius であり、sirius が east.sales 組織単位にある場合は、名前 host/sirius で east.sales にあるマシン sirius がネーミングされます。
名前空間識別子 org (または orgunit、_orgunit) は、プロセス実行中のホストが所属するエンタープライズの組織のルートコンテキストとして初期コンテキストでバインドされます。
初期コンテキストから、名前 org および thisens/orgunit は同じコンテキストで解決されます。たとえば、プロセス実行中のホストがマシン aldebaran であり、aldebaran がエンタープライズ doc.com にある場合は、名前 org/east.sales で doc.com. にある組織単位 east.sales がネーミングされます。
名前空間識別子 site (または _site) は、プロセス実行中のホストが所属するエンタープライズの最上位の組織単位のサイトネーミングシステムのルートに対する初期コンテキストにバインドされます。
初期コンテキストから、名前 site および thisens/site は同じコンテキストで解決されます。たとえば、プロセス実行中のホストがマシン aldebaran であり、aldebaran がエンタープライズ doc.com にある場合は、名前 site/pine.bldg-5 で doc.com. の建物 5 にある会議室 pine がネーミングされます。
FNS では、基本ネーミング操作の単一の簡単なインタフェースで、複数のネームサービスをフェデレートする方法が提供されます。FNS は、次の 3 つのエンタープライズレベルのネームサービスで機能するように設計されています。
「NIS+」(「FNS ポリシーと NIS+ との関連」および「FNS と NIS+ のネーミング」を参照)
「NIS」(「FNS ポリシーと NIS の関連」および「FNS と NIS のネーミング」を参照)
「ファイル」(「FNS ポリシーとファイルベースのネーミングの関連」および「FNS とファイルベースのネーミング」を参照)
また FNS は、「FNS ポリシーの対象となるクライアントアプリケーション」で説明しているようなプリンタおよびカレンダサービスなどのアプリケーションで機能するようにも設計されています。
FNS および NIS+ に関連する内容説明の概要については、「FNS と NIS+ のネーミング」を参照してください。NIS+ およびその用語を調べる場合は、このマニュアルのパート 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. を含む場合は、次の名前で同じ組織が参照されます。
表 22-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 ポリシーを利用できます。
FNS では、ファイル名はユーザー、ホスト、組織、サイトとの関係から設定できます。この場合実際には、オブジェクトの名前の後にエンタープライズの名前空間識別子 fs を指定し、その後にファイル名を指定します。たとえば、Sales 部門の、budget というファイルなら、org/sales/fs/budget/draft96という名前になります。
初期コンテキストは、ルートディレクトリの /xfn の下にあります。したがって、以下のように入力して参照できます。
% more /xfn/org/sales/fs/budget/draft96 |
アプリケーションからこのディレクトリへアクセスする方法は、他のディレクトリの場合とまったく同様です。アプリケーションを修正したり、XFN API を使用したりする必要はありません。
NFS は Sun Microsystems, Inc. の製品で、分散ファイルシステムの一種です。オブジェクトのファイルは、通常1つ以上のリモート NFS ファイルサーバーにあります。最も単純なのは、エクスポートされた NFS ファイルシステムに名前空間識別子 fs が対応するという図 22-4 のような場合です。
しかしオブジェクトのファイルシステムの中には、複数の (重なり合う場合もある) リモートマウントで構成され、FNS によって管理される仮想ディレクトリ構造にまとめられているものもあります。
図 22-5 は、3 つの異なるファイルサーバーをまとめて、組織のファイルシステムを 1 つ作成している例です。project ディレクトリと lib サブディレクトリは同じファイルサーバー上に常駐していますが、src サブディレクトリの常駐先は別です。しかしユーザー、およびアプリケーションの側からは 1 つのシームレスな名前空間に見えるので、複数のサーバーを使用していることを意識する必要はありません。
効率を上げるため、FNS ディレクトリのマウントには必要に応じてオートマウンタが使用されます。/etc/auto_master 構成ファイルには、デフォルトでは以下のような行が含まれます。
/xfn -xfn |
これは、「FNS 名前空間が、XFN の指定どおり /xfn の下にマウントされる」という意味です。
オートマウンタは、FNS によって指定されたディレクトリのマウントに使用されるため、FNS ディレクトリのサブディレクトリは、マウントされるまで表示できません。たとえば、sales 組織のファイルシステムが複数のファイルシステムで構成されているとします。以下の ls コマンドは最近アクセスして現在もマウントされている 2 つのファイルシステムだけを表示します。
% ls /xfn/org/sales/fs customers products |
完全なリストを表示するには、fnlist コマンドを使用します。
% fnlist org/sales/fs Listing `org/sales/fs': products goals customers incentives |
printer コンテキストは、XFN ポリシーには含まれていません。FNS に提供されているのは、プリンタバインディングを保存するためです。
FNS では、FNS 名前空間にプリンタバインディングを保存するための機能が提供されています。この機能によって、プリントサーバーは自分自身のサービスをユーザーに知らせることができ、ユーザーはクライアント側の管理がなくてもプリンタのブラウズおよび選択ができます。
プリンタバインディングは、組織、ユーザー、ホスト、サイトごとに存在する printer コンテキストに格納されます。したがって、組織、ユーザー、ホスト、サイトは、それぞれ専用の printer コンテキストを所有できます。
printer コンテキストは、個々の複合名の service コンテキストの下に作成されます。例を以下に示します。
org/doc.com./service/printer |
ホストのプリンタ名が deneb である場合、printer コンテキストは以下のように作成されます。
host/deneb/service/printer/laser |
グローバルネームサービスには、固有の適用範囲があります。ここでは、グローバルネームサービスを使用するオブジェクトをネーミングするためのポリシーについて説明します。
ネーミングに関しては、エンタープライズは、グローバル名前空間にあるエンタープライズのルートをバインドして、フェデレートされたグローバル名前空間にリンクします。これにより、エンタープライズ外部のアプリケーションおよびユーザーがそのエンタープライズ内部のオブジェクトをネーミングできます。たとえば、エンタープライズ内部のユーザーは、他のエンタープライズにいる同僚にファイルのグローバル名を渡すことができます。
DNS および X.500 のコンテキストは、エンタープライズをネーミングするためのグローバルレベルのネームサービスを提供します。FNS では、DNS と X.500 コンテキストの両方がサポートされます。FNS がない場合、DNS および X.500 では、限定された部分のエンタープライズ名前空間だけに外部からアクセスできます。FNS では、カレンダマネージャなどのサービスを含むエンタープライズ名前空間全体に外部からアクセスできます。
原子名「...」(3 つのドット) は、各 FNS クライアントの初期コンテキストに表示されます。原子名「...」は、グローバル名が解決されるコンテキストにバインドされます。
表 22-5 グローバルネーミングに対する初期コンテキストバインド
原子名 |
バインド |
---|---|
. .. |
DNS または X.500 の名前を解決するためのグローバルコンテキスト |
/ ... |
3 つのドットの同義語 |
グローバル名は、完全指定のインターネットドメイン名か、または X.500 の識別名になります。
インターネットドメイン名は、インターネット RFC 1035 で指定された構文に表示される。たとえば、.../doc.com (「DNS のフェデレーティング」を参照) など
X.500 名は、X/Open DCE ディレクトリで決定された構文に表示される。たとえば、.../c=us/o=doc など (「X.500/LDAP のフェデレーティング」を参照)
名前「...」および「/...」は、初期コンテキストで解決されるときには等価になります。たとえば、名前 /.../c=us/o=doc および .../c=us/o=doc は、初期コンテキストで同じオブジェクトとして解決されます。
完全指定の DNS 名は、必ずグローバルコンテキストで使用できます。DNS 名がグローバル名前空間で見つかると、リゾルバライブラリを使用して解決されます。リゾルバライブラリは、DNS 名前解決メカニズムです。一般的 DNS 名は、インターネットのホストアドレスまたは DNS ドメインレコードで解決されます。グローバルコンテキストで DNS 名が検出されると、名前は DNS リゾルバに引き渡されて解決されます。結果は、XFN リファレンス構造に変換され、要求者に返されます。
DNS ドメインの内容は、表示できます。しかし、表示操作は、インターネットでの連結性とセキュリティなどの実用上の理由によって限定されることもあります。たとえば、DNS ドメインのグローバルルート表示は、一般的にルート DNS サーバーではサポートされません。しかし、ルートの下にあるたいていのエンティティは、表示操作をサポートします。
DNS ホストおよびドメインは、DNS リソース名と関連付けられたネームサービス (NS) のリソースレコードの有無によって確認されます。
「DNS ドメイン名」
NS レコードがリソース名に存在する場合は、その名前はドメイン名であると考えられ、返されたリファレンスのタイプは inet_domain となる
「DNS ホスト名」
NS レコードがリソース名に存在しない場合は、その名前はホスト名であると考えられ、返されたリファレンスのタイプは inet_host となる
DNS は、端末以外のネーミングシステムのように機能し、他のネーミングシステムをフェデレートするために使用されます。
たとえば、エンタープライズネーミングシステムは、FNS 名 .../doc.com/ がそのエンタープライズの FNS 名前空間のルートを参照するような DNS にある doc.com にバインドできます。
エンタープライズのネーミングシステムは、適切なテキスト (TXT) レコードをそのドメインの DNS マップに追加して、DNS ドメインにバインドされます。そのドメインに対する FNS 名には後に続くスラッシュ (/) が含まれ、TXT リソースレコードは、エンタープライズのネーミングシステムへのリファレンスを構成するために使用されます。
DNS に関する一般的な情報については、in.named(1M) のマニュアルページか、または『Solaris ネーミングの設定と構成』の DNS についての章を参照してください。
X.500 は、グローバルのディレクトリサービスです。ここでは、情報が格納され、情報を表示して検索する機能と同様に、名前で情報を検索する機能が提供されます。
X.500 の情報は、ディレクトリ情報ベース (DIB) に格納されます。DIB にあるエントリは、ツリー構造で配列されます。各エントリは名前付きオブジェクトで、定義された属性のセットを含んでいます。各属性には、定義済みの属性タイプと 1 つまたは複数の値があります。
エントリは、ルートから名前付きエントリまでのパスでツリー内の各エントリから選択された属性の連結である「識別名」によって明確に識別されます。たとえば、図 22-6 に示す DIB を使用すると、c=us/o=doc は、合衆国にある doc 組織の識別名となります。X.500 ディレクトリのユーザーは、DIB にあるエントリと属性を問い合わせたり、変更したりすることができます。
FNS は、名前空間をグローバル X.500 名前空間の下にシームレスに接続して表示するために必要なサポートを提供し、X.500 をフェデレートします。
たとえば、FNS は、X.500 の下の doc 組織にエンタープライズネーミングシステムをリンクします。初期コンテキストから始まって、doc 組織の sales 組織単位を識別する FNS 名は次のようになります
.../c=us/o=doc/orgunit/sales
エンタープライズ内の名前は、単純にグローバルの X.500 名上に連結されます。FNS 名が初期コンテキストで名前「...」を使用して、グローバル名が後に続くことを示すことに注意してください。
FNS 名の名前解決は、次のように行われます。X.500 名がグローバル名前空間で見つかると、X.500 名前解決メカニズムを使用して解決されます。次の 3 つの結果が考えられます。
フルネームが X.500 エントリに解決される。これは、エントリが X.500 に格納されていることを示す。要求された FNS 操作がそのエントリで実行される
フルネームの接頭辞は、X.500 エントリに解決される。これは、名前の残りの部分が従属するネーミングシステムに所属することを示す
従属するネーミングシステムへの次のネーミングシステムのポインタ (NNSP) が調べられ、XFN リファレンスが返されます。この後、名前解決は従属するネーミングシステムで続けられます。
エラーが報告される
X.500 エントリは、FNS 操作を使用して調べたり、変更したりできます (アクセス制御に従う)。しかし、現在は FNS を使用して X.500 名前空間のルートの下にある従属するエントリを表示できません。