この章では、X/OPEN XFN フェデレーテッド・ネーミング標準に基づいて Sun Microsysmtems, Inc. が設計した FNS (フェデレーテッド・ネーミング・サービス) について説明します。
コンピューティング環境に組み込まれているネームサービスは、アプリケーションやサービスによって異なります。異なる複数のネームサービスを処理する場合、アプリケーション開発者は多くの問題に直面します。ほとんどのアプリケーションは、1 つのネームサービスを使用するように設計されており、分散コンピューティング環境内のオブジェクトへのアクセスは非常に制限されています。アプリケーションによって、使用するネームサービスが異なるため、名前の作成方法も異なります。ユーザーが非常に似ていると見なすオブジェクトについても、異なる名前が使用される場合がよくあります。たとえば、友人の Johanna に対して彼女の名前 johanna@admin.doc.com を使用してメールを送信できますが、彼女のカレンダにアクセスするには、別の名前 jsmith@altair を使用しなければなりません。
Sun Microsysmtems, Inc. による XFN 標準の実装である FNS を使用すると、オブジェクトを一貫した方法でネーミングし、しかもアプリケーションと開発者が必要とする機能を提供することもできます。
「XFN」は、X/Open フェデレーテッド・ネーミングのことを指します。XFN は、Sun Microsystems, Inc.、IBM、Hewlett-Packard、DEC、Siemens、OSF などの組織によって実際にサポートされている標準です。Solari 7 リリースでの XFN の実装である FNS は、「X/Open Preliminary Specification for Federated Naming」(1994 年 7 月) に準拠しています。FNS を使用するアプリケーションは、プラットフォーム間で移植可能です。これは、FNS によって、エクスポートされるインタフェースが、他のベンダーと X/Open によって認められた公共のオープンインタフェースである XFN だからです。X/Open Company Ltd. は、主要なコンピュータベンダーによって推奨され支持されるコンピューティング標準の定義を委託された国際標準機構です。
「FNS」は、基本的なネーミング操作用の 1 つの単純な一貫したインタフェースによって、複数のネーミングサービスをフェデレートする方法です。このサービスは、複合名、つまり、複数のネーミングシステムにまたがる名前を、ネーミングインタフェースによって解決します。フェデレーションの各メンバーは、ネーミング規則、管理インタフェース、名前解決以外の特定操作の集合を独自に選択できます。
Solaris 環境での FNS 実装は、DNS や X.500 などのグローバルネームサービス (「Solaris エンタープライズレベルのネームサービス」を参照) のサポートだけでなく、組織、ユーザー、ホスト、サイト、サービスをネーミングするための特定のポリシーと規則によって、一連のエンタープライズレベルのネームサービス (「グローバルネームサービス」を参照) から構成されます。
FNS は次の理由で便利です。
異なる複数のネームサービスにアクセスするために、クライアントに対して、一貫した 1 つのネーミングインタフェースが提供される。したがって、新しいネームサービスを追加しても、アプリケーションや既存のメンバー名サービスを変更する必要がない
名前を一貫した方法で作成でき、作成される複合名に任意の数の構成要素を使用できる
共有コンテキストと共有名を使用するときに、一貫したネーミングが可能になる
このマニュアルでは、XFN と FNS を区別することが重要です。FNS ポリシーには XFN ポリシーの拡張がいくつか含まれており、これらのポリシーは、注によって明確に定義されます。XFN プログラミングインタフェースに属するオブジェクトは、他のプログラミングインタフェースとの混同を避けるために、XFN オブジェクトとして指定されます。
この項では、XFN のネーミングモデルについて、いくつかの観点から説明します。
フェデレーテッド・ネーミング・システムによって提供される基本サービスは、複合名とリファレンスのマッピングと、名前付きオブジェクトに関連する属性へのアクセス権の提供です。この項では、XFN ネーミングモデルの各要素を定義します。
分割不可能な名前の最小構成要素を「原子名」といいます。たとえば、マシン名 nismaster やユーザー名 chou などです。原子名には 1 つまたは複数の属性がある場合や、属性がまったくない場合があります (「属性」を参照)。
リファレンスとは、オブジェクトに到達する方法についての情報のことをいいます。リファレンスには、アドレスのリストが入っています。1 つのアドレスは、1 つの通信の終端 (オブジェクト) を識別します。たとえば、nismaster.doc.com などのマシンアドレスや、chou@doc.com などのユーザーの電子メールアドレスです。
リファレンスには、1 つの概念上のオブジェクトまたはサービスを示す、複数の通信終端を識別する複数のアドレスが含まれる場合があります。たとえば、オブジェクトが分配されるか、または複数の通信メカニズムによってオブジェクトにアクセスできるため、アドレスのリストが必要になる場合などです。
XFN は、安定性、有効性、到達の確実性などのアドレス属性を保証できません。クライアントは名前を検索できても、返されたリファレンスを使用できない場合があります。これは、そのクライアントが必要な通信メカニズムをサポートしていないか、あるいはそのアドレスに到達するために必要なネットワークの接続がないために起こります。また、アドレスが最初から無効であるか、古い場合があります。これらは、そのアドレスに指定された名前のバインダ、クライアント、サービスプロバイダ間の規則の問題です。
コンテキストとは、図 21-1 に示すようにリファレンスに割り当てられた原子名の集合のことです。どのコンテキストにも、関連のネーミング規則があります。コンテキストは、検索 (解決) 操作を行います。この操作では、リファレンスが返され、名前のバインド、名前のバインド解除、バインド名のリスト表示を行うこともあります。コンテキストは、検索操作とバインド操作の中心となるものです。
属性は、名前付きオブジェクトに適用できます。属性はオプションです。名前付きオブジェクトには、属性を付けないことも、あるいは 1 つまたは複数の属性を付けることもできます。
各属性は、固有の属性識別子と属性構文を持ちます。個別の属性値の集合のある場合とない場合があります。属性は、図 21-1 に示すように点線で示されます。
XFN は、既存の名前付きオブジェクトに関連する属性の値を調べて変更するための基本属性インタフェースを定義します。これらのオブジェクトは、コンテキストまたは他のタイプのオブジェクトとなります。コンテキストには、コンテキストによる合成名 (compound name) の構文解析方法を記述する構造属性が関連付けられます。
拡張属性インタフェースには、特定の属性を検索する操作と、オブジェクトおよびその関連属性を作成する操作が含まれます。
合成名とは、1 つ以上の原子名が連なったものをいいます。あるコンテキスト内の原子名は、サブコンテキストと呼ばれる同じタイプの別のコンテキストへのリファレンスに割り当てられます。サブコンテキスト内のオブジェクトは、合成名を使用してネーミングされます。合成名は、連続する各コンテキスト内の連続する各原子名を検索することによって解決されます。
これは、UNIX ユーザーのファイルネーミングモデルに似ています。この場合、ディレクトリはコンテキストにあたり、パス名は合成名として機能します。また、コンテキストは、ディレクトリと同様に「ツリー」構造で構成されます。合成名は階層名前空間を形成します。
次に例を示します。
「UNIX」の usr/local/bin
UNIX の原子名は、左から右へ順序付けられ、スラッシュ (/) によって区切られる。usr という名前は、local がバインドされているコンテキストにバインドされる。local という名前は、bin がバインドされているコンテキストにバインドされる
「DNS」の sales.doc.com
DNS の原子名は、右から左へ順序付けられ、ドット (.) によって区切られる。ドメイン名 com は、doc がバインドされているコンテキストにバインドされる。doc は、sales がバインドされているコンテキストにバインドされる
「X.500」の c=us/o=doc/ou=sales
X.500 の原子名は、属性タイプと属性値を構成する。原子名は、X.500 では、「相対識別名」と呼ばれる。この文字列表記で、X.500 原子名は、左から右に順序付けられ、スラッシュ (/) によって区切られる。属性タイプは、等号 (=) によって、属性値と区切られる。一般的に使用される属性タイプには省略名が定義される (たとえば、"c" は国名を表す)。国名 US は、docがバインドされているコンテキストにバインドされる。組織名 doc は、組織ユニット名 sales がバインドされているコンテキストにバインドされる
複合名とは、複数のネーミングシステムにまたがる 1 つの名前のことをいいます。各構成要素は、単一のネーミングシステムの名前空間からとられた名前です。複合名の名前解決は、複数のネーミングシステムにまたがる名前の解決プロセスです。
構成要素はスラッシュ (/) によって区切られ、XFN 複合名構文に従って、左から右へ順序付けられます。たとえば、複合名
sales.doc.com/usr/local/bin
には、DNS 名 (sales.doc.com) と UNIX パス名 (usr/local/bin) という 2 つの構成要素があります。
原子名とリファレンスアドレスは、1 つまたは複数の「名前空間」に対応して解決することもできます。デフォルトにより、FNS には、org (組織を示す)、site、host、user、service、fs (ファイルを示す) の 6 つの名前空間があります。
FNS のポリシーは、名前空間に関連する名前が相互に関連付け合う方法を決めるために使用されます。たとえば、あるユーザーが、ユーザー名前空間で sergei とネーミングされていて、/user/sergei と識別されるとします。カレンダアプリケーションは、サービス名前空間でネーミングされ、/service/calendar と識別されます。このシステムでは、sergei のカレンダサービスを /user/sergei/service/calendar と識別できます。名前空間とその使用方法の詳細は、「FNS および XFN のポリシーの概要」を参照してください。
あるアプリケーションでユーザー名の入力が必要な場合、そのアプリケーションでは、入力する名前の前に名前空間識別子 user/ を付けることができます。アプリケーションで、ユーザーのデフォルトのファックス機などのユーザーのサービスの 1 つをネーミングする必要がある場合は、入力された名前に service 名前空間とサービスの名前 (/service/fax) を追加できます。したがって、ファックスツールは、入力値として、ユーザー名 jacques をとり、ユーザー jacques のデフォルトファックスの完全指定名 user/jacques/service/fax を作成します。同様に、ユーザー名を入力するだけで、あるユーザーのカレンダにアクセスできます。アプリケーションは入力値 raj をとり、その値を使用して複合名を作成します。この場合は、user/raj/service/calendar です。
XFN リンクは、コンテキスト内の原子名に割り当てられたリファレンスの特殊な形式です。リンクには、アドレスではなく複合名が含まれます。ネーミングシステムの多くは、そのネーミングシステム自体で使用可能なリンクという基本概念をサポートしています。XFN は、このような基本リンクと XFN リンクの間に何らかの関係があるかどうかを指定しません。
XFN 名はすべていくつかのコンテキストに対応して解釈され、XFN ネーミング操作は、コンテキストオブジェクトに対して実行されます。「初期コンテキスト」オブジェクトは、複合名解決の開始地点となるものです。XFN インタフェースは、クライアントが初期コンテキストを獲得するための機能を提供します。
第 22 章「FNS ポリシー」で説明しているように、このコンテキストとそのバインドの意味を見つけるためにクライアントが必要とする名前の集合を指定します。これにより、別の XFN コンテキストを見つけることが可能となります。
ユーザーは、アプリケーションによりフェデレーテッド・ネーミングを利用できます。通常、ユーザーは、オブジェクトの完全複合名を作成する必要も、知る必要もありません。これは、アプリケーションが複合名の作成を行うためです。これにより、ユーザーは、XFN を認識するアプリケーションと、単純な一貫した方法で対話することができます。
ユーザーとアプリケーションは、ファイルシステムによっても、フェデレーテッドネーミングを利用できます。初期コンテキストは、ルートディレクトリの /xfn に入っています。たとえば、ingrid の to_do ファイルの XFN 名が xfn/user/ingrid/fs/to_do だとします。
このファイルを読むには、次のように入力します。
% cat /xfn/user/ingrid/fs/to_do |
アプリケーションは、他のファイルの場合と同様に、/xfn のもとにあるファイルにアクセスします。アプリケーションを変更する必要も、XFN API を使用する必要もありません。
次の一連の図は、クライアントアプリケーションが XFN と対話して異なるネーミングシステムにアクセスする方法を示します。図 21-2 は、XFN API とライブラリを使用するアプリケーションを示します。
図 21-3 は、API の詳細を示しています。フェデレートされるネームサービスは、XFN クライアントライブラリと「コンテキスト共有オブジェクトモジュール」によってアクセスされます。このモジュールは、XFN 呼び出しをネームサービス特定呼び出しに変換します。
XFN インタフェースのクライアントの多くは、検索だけを対象とします。これらのクライアントは、インタフェースを次の目的で使用します。
初期コンテキストの獲得
初期コンテキストに対応する 1 つまたは複数の名前の検索
クライアントは、検索操作で必要なリファレンスを獲得すると、そのリファレンスからオブジェクトのクライアント側での表示を作成します。
Solaris 環境では、ネームサービスは、ファイルシステム、ネットワーク情報サービス、メールシステム、カレンダサービスなどの他のサービスに統合されます。たとえば、ファイルシステムには、ファイルとディレクトリ用のネーミングシステムが含まれます。NIS+ サービスでは、ネーミングシステムと特殊な情報サービスを結合します。
FNS がない場合、Solaris 環境のユーザーは、整合性のない複数の名前を使用して、オブジェクトを参照しなければなりません。たとえば、jsmith@admin という名前を使用して Joan にメールを送り、jsmith@altair という名前を使用してカレンダにアクセスし、/home/jsmith/.cshrc という名前を使用して、彼女のホームディレクトリにあるファイルに到達しなければなりません。このため、ユーザーが名前を形式化するのが困難になります。また、アプリケーションがユーザーに代わって名前を自動生成することも難しくなります。FNS ポリシーでは、これらのオブジェクトをネーミングする一貫した方法を定義します。
アプリケーションもネームサービスを必要とします。Solaris 環境のアプリケーションでは、多くのネームサービスインタフェースを処理する必要があります。1 つのアプリケーションが、Solaris 環境の外部にある各種の互換性のないネーミングシステムと関わる場合もあります。ローカルネットワークと広域ネットワークでは、異機種の複数のハードウェアとオペレーティングシステムが接続されているので、各種のインタフェースが混在する可能性が高くなります。これらのネーミングインタフェースは大幅に異なるだけでなく、基本的なネーミング操作も通常明確ではありません。
FNS は、これらの問題を次の 2 つの方法で解決します。
基本ネーミング機能に単一の標準インタフェースを提供して、開発者がアプリケーションで使用できるようにする
既存のアプリケーションを変更しなくても、ネットワークのネームサービスの変更や追加ができるようにする
アプリケーションによっては、複合名を使用して、Solaris 環境のオブジェクトにアクセスするものがあります。コマンドの mail と rcp は、このようなアプリケーションの一例です。
rcp は、sirius:/usr/jsmith/memo などの複合名を使用します。これは、ホスト名 sirius とファイル名 (パス) /usr/jsmith/memo の 2 つの構成要素からなります。mail プログラムは、jsmith@altair などの複合名を使用します。これは、ユーザ名 jsmith とホスト名 altair の 2 つの構成要素からなります。
各アプリケーションは、独自の名前作成規則を定義し、複合名を構文解析して、複合名を解決します。複合規則は、通常、アプリケーションごとに異なります。
FNS がない場合、ユーザーは、どのアプリケーションで複合ネーミングが可能であり、どれが可能でないかを覚えておく必要があります。たとえば、複合名 sirius:/tmp/saleslist は、rcp コマンドでは受け入れられますが、cp コマンドでは受け入れられません。
FNS がない場合、ユーザーは、アプリケーションごとに使用される異なる作成規則も覚えておく必要があります。独自の複合名をサポートするアプリケーションは、小さい特定のネーミングシステムしか使用できません。また、新しいタイプのネーミングシステムが追加されるたびに変更する必要があります。
複合ネーミングの一貫したポリシーを、コンピューティングプラットフォームに組み込むと、どのアプリケーションでも一貫した方法で複合名をサポートできます。アプリケーションは、1 つの名前を 1 つのインタフェースに渡します。
FNS ポリシーには、次の原則があります。
「特定のオブジェクトに対応して他のオブジェクトをネーミングする場合、そのオブジェクトはネーミングコンテキストとなる」
たとえば、ユーザーに対応してさまざまな事柄をネーミングする場合、ユーザーオブジェクトがネーミングコンテキストになります。
「共通構成要素を使用した名前の作成が可能」
これにより、ユーザーが覚える必要がある名前の数が減り、アプリケーションとユーザーによる、共通構成要素とその論理構成に関する知識に基く名前の作成が容易になります。
「名前は視覚的で自明のものでなければならない」
たとえば、FNS 名 /user/wong/service/calendar は、ユーザー Wong によって使用されるカレンダサービスを明示します。これに対して、カレンダ名 wong@deneb は、Wong のカレンダサービスが提供されるホスト (deneb) を表します。ただし、他のユーザーにとって、ホスト名は余分であり、検索しにくく覚えずらいので、このユーザーのカレンダとホストの間に明確な関連性はありません。
「1 つのコンテキストで間に合う場合には、2 つのコンテキストを使用しない。」
上記の例では、メールアドレス、カレンダ、ファイルのディレクトリを、ユーザー Wong に対応してネーミングした方が効果的です。コンテキストとその名前を共有すると、ネーミングの整合性が高まり、管理が簡単になります。
Solaris 環境での FNS 実装は、現在次のものの上に実装されたネームサービスで構成されています。
NIS+、NIS、ローカルファイル、などの組織レベルのネームサービス (「Solaris エンタープライズレベルのネームサービス」を参照)
ファイルネーミング、プリンタネーミング、他のアプリケーションのサポート (第 25 章「ファイルコンテキストの管理」を参照)
DNS と X.500/LDAP を使用するグローバルレベルのネーミングシステム (第 26 章「FNS およびグローバルネーミングシステム」を参照)
FNS は、FNS を使用するアプリケーションとシステムが増えるほど、Solaris のユーザーには利用しやすいものとなります。
「エンタープライズレベル」のネームサービスは、エンタープライズレベルのネットワーク内のマシン (ホスト)、ユーザー、ファイルを識別 (ネーミング) します。FNS でも、組織ユニット、地理的なサイト、アプリケーションサービスのネーミングが可能です。「エンタープライズレベル」のネットワークは、ケーブル、赤外線、ラジオブロードキャストを通して通信する単一のローカルエリアネットワーク (LAN) にできます。または、ケーブルや直接通話接続によってリンクされた複数の LAN にできます。エンタープライズレベルのネットワーク内では、DNS や X.500/LDAP などのグローバルネームサービスを参照しなくても、すべてのマシンが他のマシンと通信できます。
FNS は現在、次に 3 つのエンタープライズレベルのネームサービスをサポートしています。
NIS+
下記の、「FNS と NIS+ のネーミング」、「FNS ポリシーと NIS+ との関連」、「FNS と NIS+ の詳細情報」を参照
NIS
詳細は、「FNS と NIS のネーミング」、「FNS ポリシーと NIS の関連」、「FNS と NIS の詳細情報」を参照
ファイル
詳細は、「FNS とファイルベースのネーミング」、「FNS ポリシーとファイルベースのネーミングの関連」、「FNS とファイルベースのネーミングの詳細情報」を参照
FNS とエンタープライズレベルネームサービスの管理情報については、第 23 章「FNS とエンタープライズのネームサービス」を参照してください。
NIS+ とその用語については、このマニュアルのパート I「ネーミングの紹介」と用語集を参照してください。典型的な NIS+ 環境の構造を理解しておくと有効です。
NIS+ は、Solaris 環境で推奨される組織規模の情報サービスです。NIS+ では、NIS とローカルファイルの両方を使用できます。NIS+ を使用すると、ドメインとサブドメインからなる階層組織レベルに組織を分割できます。
FNS 組織ユニットは、NIS+ のドメインとサブドメインに対応します。各ドメインとサブドメインに 1 つの orgunit コンテキストがあります。
FNS は NIS+、NIS、ローカルファイルをフェデレートして、Solaris 環境でのネーミングポリシーをサポートします。FNS はこのために、organization、site、user、host の各オブジェクトに対してネーミング操作を実行するための XFN インタフェースを提供します。このインタフェースは、ファイル、ディレクトリ、テーブルにアクセスするために適切なプログラミングインタフェースを使用して、これらの操作を実装します。
NIS+ のもとでは、FNS コンテキストと属性データは、NIS+ タイプテーブルに格納されます。これらのテーブルは、ctx_dir という名前の NIS+ タイプのディレクトリオブジェクトに格納されます。各 NIS+ ドメインとサブドメインに ctx_dir ディレクトリオブジェクトがあり、ドメインの groups_dir と org_dir ディレクトリオブジェクトと同じレベルにあります。したがって、ディレクトリオブジェクト ctx_dir.sales.doc.com. には、sales.doc.com ドメインの FNS コンテキストと属性データを格納する FNS テーブルが含まれます。
NIS+ では、FNS と NIS+ のコマンドを使用して、FNS テーブル内の情報を処理します。これらのテーブルを直接編集したり、UNIX コマンドで操作したりしないでください。
NIS は Solaris 環境でのエンタープライズ規模の情報サービスです。ローカルファイルは、NIS とともに使用できます。NIS のもとでは、エンタープライズは単一の NIS ドメインとして構成されます。
各エンタープライズは、単一の NIS ドメインです。1 つの NIS ドメインに対応して、1 つの FNS エンタープライズユニットがあります。
FNS は、NIS とローカルファイルをフェデレートして、Solaris 環境でのネーミングサービスをサポートします。FNS はこのために、organization、site、user、host の各マップに対してネーミング操作を実行するための XFN インタフェースを提供します。このインタフェースは、ファイル、ディレクトリにアクセスするために適切なプログラミングインタフェースを使用して、これらの操作を可能にします。
NIS では、FNS コンテキストと属性データは NIS マップに格納されます。これらのマップは、NIS サーバー上の /var/yp/domainname ディレクトリに格納されます。NIS では、スーパーユーザーが FNS コマンドを使用して、FNS マップ内の情報を処理できます。
一定の条件が合えば、NIS クライアント (マシン、プロセス、またはユーザー) はすべて、fncreate_fs や fncreate_printer などの FNS コマンドを使用して、クライアント自身のコンテキストを更新できます。これにより、NIS クライアントは、FNS コマンドを使用して、Printer Administrator、CDE カレンダマネージャ、admintool などを更新できます。
スーパーユーザー以外のユーザーが、FNS コマンドによって各自のコンテキストを更新するには、次の条件が必要です。
SKI (Secure Key_management Infrastructure) が NIS マスターサーバー上で使用可能
fnsypd デーモンが NIS マスターサーバー上で実行されている。このデーモンは、スーパーユーザー特権を持つユーザーが開始する
クライアントユーザーまたはマシンだけが各自のコンテキストを更新できる
クライアントは、要求された更新の実行権限を持っている
「ファイル」とは、通常、マシンの /etc ディレクトリにあるネーミングファイルのことを指します。これらのマシンベースのファイルには、UNIX ユーザーとパスワードの情報、ホスト情報、メールエイリアスなどが入っています。これらは、オートマウントマップなどの Solaris 特定のデータもサポートします。
FNS は、ローカルファイルをフェデレートして、Solaris 環境でのネームサービスをサポートします。FNS はこのために、organization、site、user、host の各ファイルに対してネーミング操作を実行するための XFN インタフェースを提供します。これらの操作は、ファイル、ディレクトリにアクセスするための適切なプログラミングインタフェースを使用して実装されます。
ファイルベースのネーミングシステムでは、FNS コンテキストと属性は、ファイルに格納されます。これらのファイルは、NFS ファイルサーバーからエクスポートされた /var/fn ディレクトリに格納されます。
ファイルベースのネーミングシステムでは、FNS コマンドを使用して、FNS ファイル内の情報を処理します。
グローバルネームサービスは、電話、衛星などの通信システムによって世界中でリンクされた組織レベルのネットワークを識別 (ネーミング) します。この世界規模でリンクされたネットワークの集合は、「インターネット」と呼ばれています。ネーミングネットワークだけでなく、グローバルネームサービスも、ネットワーク内の個々のマシンとユーザーを識別します。
FNS は現在、次の 2 つのグローバルネームサービスをサポートしています。
DNS
詳細は、「FNS と DNS」、「DNS でフェデレートする」を参照
X.500/LDAP
エンタープライズレベルのネームサービスが NIS+ または NIS の場合、グローバルネームサービスだけをフェデレートできます。ファイルベースのネームサービスをエンタープライズで使用している場合は、DNS も X.500/LDAP もフェデレートできません。
FNS とエンタープライズレベルネームサービスの管理情報については、第 26 章「FNS およびグローバルネーミングシステム」を参照してください。
インターネットドメイン名システム (DNS) は、世界のインターネットにホストとドメインの名前解決を提供するネームサーバーの階層集合です。FNS は DNS を使用してエンタープライズオブジェクトをグローバルにネーミングします。
ドメイン名とは、DNS がエンタープライズレベルネットワーク (LAN または WAN) を識別するために使用する名前のことをいいます。NIS+ を使用するネットワークでは、親ドメイン内でのサブドメインの作成が可能であり、DNS はこのようなサブドメインを識別できます。
名前は、インターネット上でアクセス可能なすべてのエンタープライズについて作成できます。したがって、名前は、これらのエンタープライズからエクスポートされたオブジェクトにも作成できます。FNS と DNS の詳細は、「DNS でフェデレートする」を参照してください。
X.500 はグローバルディレクトリサービスです。この各構成要素は、世界規模の範囲内のオブジェクトに関する情報を管理するためにともに機能します。このようなオブジェクトには、国、組織、ユーザー、マシンが含まれます。FNS は、X.500 をフェデレートして、エンタープライズネームサービスへのグローバルアクセスを可能にします。次の 2 つの API のうち 1 つを使用して、X.500 グローバルディレクトリサービスにアクセスできます。
XDS/XOM API
LDAP (軽量ディレクトリアクセスプロトコル) API
X.500 のフェデレートについては、「X.500/LDAP でフェデレートする」を参照してください。
FNS は、次のものをサポートします。
Solaris NFS ファイルサービス (下記の、「FNS ファイルネーミング」を参照)
プリンタネーミング (下記の、「FNS プリンタネーミング」を参照)
その他のアプリケーション ( 下記の、「FNS アプリケーションサポート」を参照)
FNS ベースのファイルネーミングは、FNS ネーミングを Solaris ファイルサービスに統合します。FNS ベースのファイルネーミングを使用すると、他のファイルに関連しないアプリケーションと共有される FNS ポリシーによって、ユーザー、ホスト、サイト、組織に対応してファイルをネーミングできます。
FNS ベースのファイルネーミングは、クライアントに対して、グローバルかつエンタープライズ規模のファイル名前空間の共通表示を提供します。ファイルシステムにアクセスする Solaris アプリケーションは、FNS によってサポートされるファイル名前空間に、変更せずにアクセスできます。
FNS ベースのプリンタネーミングは、バンドルされていない SunSoft Print Client (SSPC) の基本ネーミング機能となります。FNS ベースのプリンタネーミングを使用すると、他の印刷関連ではないアプリケーションと共有される FNS ポリシーを使用して、ユーザー、ホスト、サイト、組織に対応してプリンタをネーミングできます。
FNS ベースのプリンタネーミングは、クライアントに対して、グローバルかつエンタープライズ規模のプリンタ名前空間の共通表示を提供します。また、これを使用すると、プリンタ名前空間を中央で管理できます。
FNS を認識するアプリケーションでは、名前空を FNS ポリシーに従って構成できます。また、FNS 名前空で名前を割り当てるアプリケーションは、これらのポリシーに従う必要があります。
アプリケーションは、FNS を次の 3 つの方法で使用します。
「アプリケーションは、FNS インタフェースとポリシーを使用すればクライアントとなる。」
ファイルシステム、印刷サービス、デスクトップツール (カレンダマネージャ、ファイルマネージャ) などのアプリケーションレベルのユーティリティは、FNS インタフェースを直接使用するクライアントの一例である
「アプリケーションは、既存のインタフェースにより FNS を使用できる。」
FNS の大部分は、既存のアプリケーションプログラミングインタフェースにより使用される。たとえば、後で UNIX open() 関数に与えられるファイル名を獲得する UNIX アプリケーションを例にとる。この場合、FNS サポートを使用してファイル名を解決すると、アプリケーションは、処理対象の文字列が従来のローカルパス名ではなく複合名であることを認識しなくてもすむ。したがって、アプリケーションの多くは、変更なしに合成名をサポートできる
「システムが FNS インタフェースをエクスポートできる。」
DNS や X.500 などのネーミングシステム、ファイルシステムや印刷サービスなどのサービスに組み込まれたネーミングシステムは、FNS インタフェースをエクスポートするネーミングシステムの例である
FNS システムの管理は、基本となるネームサービスによって異なります。
「NIS+」
NIS+ では、FNS システム管理タスクは、その権限を持つユーザーだけが実行できる。システム管理特権は、通常、NIS+ グループを作成して、そのグループにドメインで必要な特権を割り当てることによって付与される。これにより、グループのメンバーはすべて、システム管理機能を実行できる
「NIS」
NIS では、NIS マスターサーバー上の root が FNS 管理タスクを実行しなければならない
「ファイルベース」
ファイルベースのネーミングシステムでは、/var/fn ディレクトリに root アクセス権を持つユーザーが、FNS 管理タスクを実行しなければならない
各自のユーザーサブコンテキストをユーザーが変更できるかどうかは、基本となるネームサービスによって異なります。
「NIS+」
NIS+ では、ユーザーのコンテキスト (およびサブコンテキスト) は、ユーザーが所有する。NIS+ のポリシーでログインした場合、適切な資格と特権を持つユーザーは、fncreate、fnbind、fnunbind などのコマンドを使用して、各自のコンテキストを変更できる
「NIS」
NIS では、ユーザーはどの FNS データも変更できない。NIS マスターサーバーの root アクセス権を持つユーザーだけが FNS データを変更できる
「ファイルベース」
ファイルベースのネーミングシステムでは、ユーザーが独自のコンテキストを所有する。標準 UNIX アクセスでは、FNS ファイルへの適用が制御される
一般的な FNS の問題を追跡して解決する方法については、「FNS の問題と対策」を参照してください。FNS のエラーメッセージは、付録 B 「エラーメッセージ」 に記載されています。