test

Solaris ネーミングの管理

第 21 章 FNS の概要

この章では、X/OPEN XFN フェデレーテッド・ネーミング標準に基づいて Sun Microsysmtems, Inc. が設計した FNS (フェデレーテッド・ネーミング・サービス) について説明します。

XFN と FNS

コンピューティング環境に組み込まれているネームサービスは、アプリケーションやサービスによって異なります。異なる複数のネームサービスを処理する場合、アプリケーション開発者は多くの問題に直面します。ほとんどのアプリケーションは、1 つのネームサービスを使用するように設計されており、分散コンピューティング環境内のオブジェクトへのアクセスは非常に制限されています。アプリケーションによって、使用するネームサービスが異なるため、名前の作成方法も異なります。ユーザーが非常に似ていると見なすオブジェクトについても、異なる名前が使用される場合がよくあります。たとえば、友人の Johanna に対して彼女の名前 johanna@admin.doc.com を使用してメールを送信できますが、彼女のカレンダにアクセスするには、別の名前 jsmith@altair を使用しなければなりません。

Sun Microsysmtems, Inc. による XFN 標準の実装である FNS を使用すると、オブジェクトを一貫した方法でネーミングし、しかもアプリケーションと開発者が必要とする機能を提供することもできます。

注 -

このマニュアルでは、XFN と FNS を区別することが重要です。FNS ポリシーには XFN ポリシーの拡張がいくつか含まれており、これらのポリシーは、注によって明確に定義されます。XFN プログラミングインタフェースに属するオブジェクトは、他のプログラミングインタフェースとの混同を避けるために、XFN オブジェクトとして指定されます。

XFN モデル

この項では、XFN のネーミングモデルについて、いくつかの観点から説明します。

XFN アーキテクチャモデル

フェデレーテッド・ネーミング・システムによって提供される基本サービスは、複合名とリファレンスのマッピングと、名前付きオブジェクトに関連する属性へのアクセス権の提供です。この項では、XFN ネーミングモデルの各要素を定義します。

原子名

分割不可能な名前の最小構成要素を「原子名」といいます。たとえば、マシン名 nismaster やユーザー名 chou などです。原子名には 1 つまたは複数の属性がある場合や、属性がまったくない場合があります (「属性」を参照)。

リファレンス

リファレンスとは、オブジェクトに到達する方法についての情報のことをいいます。リファレンスには、アドレスのリストが入っています。1 つのアドレスは、1 つの通信の終端 (オブジェクト) を識別します。たとえば、nismaster.doc.com などのマシンアドレスや、chou@doc.com などのユーザーの電子メールアドレスです。

リファレンスには、1 つの概念上のオブジェクトまたはサービスを示す、複数の通信終端を識別する複数のアドレスが含まれる場合があります。たとえば、オブジェクトが分配されるか、または複数の通信メカニズムによってオブジェクトにアクセスできるため、アドレスのリストが必要になる場合などです。

注 -

XFN は、安定性、有効性、到達の確実性などのアドレス属性を保証できません。クライアントは名前を検索できても、返されたリファレンスを使用できない場合があります。これは、そのクライアントが必要な通信メカニズムをサポートしていないか、あるいはそのアドレスに到達するために必要なネットワークの接続がないために起こります。また、アドレスが最初から無効であるか、古い場合があります。これらは、そのアドレスに指定された名前のバインダ、クライアント、サービスプロバイダ間の規則の問題です。

コンテキスト

コンテキストとは、図 21-1 に示すようにリファレンスに割り当てられた原子名の集合のことです。どのコンテキストにも、関連のネーミング規則があります。コンテキストは、検索 (解決) 操作を行います。この操作では、リファレンスが返され、名前のバインド、名前のバインド解除、バインド名のリスト表示を行うこともあります。コンテキストは、検索操作とバインド操作の中心となるものです。

図 21-1 XFN のコンテキスト

Graphic

属性

属性は、名前付きオブジェクトに適用できます。属性はオプションです。名前付きオブジェクトには、属性を付けないことも、あるいは 1 つまたは複数の属性を付けることもできます。

各属性は、固有の属性識別子と属性構文を持ちます。個別の属性値の集合のある場合とない場合があります。属性は、図 21-1 に示すように点線で示されます。

XFN は、既存の名前付きオブジェクトに関連する属性の値を調べて変更するための基本属性インタフェースを定義します。これらのオブジェクトは、コンテキストまたは他のタイプのオブジェクトとなります。コンテキストには、コンテキストによる合成名 (compound name) の構文解析方法を記述する構造属性が関連付けられます。

拡張属性インタフェースには、特定の属性を検索する操作と、オブジェクトおよびその関連属性を作成する操作が含まれます。

合成名 (compound name)

合成名とは、1 つ以上の原子名が連なったものをいいます。あるコンテキスト内の原子名は、サブコンテキストと呼ばれる同じタイプの別のコンテキストへのリファレンスに割り当てられます。サブコンテキスト内のオブジェクトは、合成名を使用してネーミングされます。合成名は、連続する各コンテキスト内の連続する各原子名を検索することによって解決されます。

これは、UNIX ユーザーのファイルネーミングモデルに似ています。この場合、ディレクトリはコンテキストにあたり、パス名は合成名として機能します。また、コンテキストは、ディレクトリと同様に「ツリー」構造で構成されます。合成名は階層名前空間を形成します。

次に例を示します。

複合名 (composite name)

複合名とは、複数のネーミングシステムにまたがる 1 つの名前のことをいいます。各構成要素は、単一のネーミングシステムの名前空間からとられた名前です。複合名の名前解決は、複数のネーミングシステムにまたがる名前の解決プロセスです。

構成要素はスラッシュ (/) によって区切られ、XFN 複合名構文に従って、左から右へ順序付けられます。たとえば、複合名

sales.doc.com/usr/local/bin

には、DNS 名 (sales.doc.com) と UNIX パス名 (usr/local/bin) という 2 つの構成要素があります。

FNS 名前空間

原子名とリファレンスアドレスは、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 ネーミング操作は、コンテキストオブジェクトに対して実行されます。「初期コンテキスト」オブジェクトは、複合名解決の開始地点となるものです。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-2 クライアントアプリケーションと XFN との対話

Graphic

図 21-3 は、API の詳細を示しています。フェデレートされるネームサービスは、XFN クライアントライブラリと「コンテキスト共有オブジェクトモジュール」によってアクセスされます。このモジュールは、XFN 呼び出しをネームサービス特定呼び出しに変換します。

図 21-3 XFN API の詳細

Graphic

API 使用モデル

XFN インタフェースのクライアントの多くは、検索だけを対象とします。これらのクライアントは、インタフェースを次の目的で使用します。

クライアントは、検索操作で必要なリファレンスを獲得すると、そのリファレンスからオブジェクトのクライアント側での表示を作成します。

フェデレーテッド・ネーミング・サービス

Solaris 環境では、ネームサービスは、ファイルシステム、ネットワーク情報サービス、メールシステム、カレンダサービスなどの他のサービスに統合されます。たとえば、ファイルシステムには、ファイルとディレクトリ用のネーミングシステムが含まれます。NIS+ サービスでは、ネーミングシステムと特殊な情報サービスを結合します。

FNS がない場合、Solaris 環境のユーザーは、整合性のない複数の名前を使用して、オブジェクトを参照しなければなりません。たとえば、jsmith@admin という名前を使用して Joan にメールを送り、jsmith@altair という名前を使用してカレンダにアクセスし、/home/jsmith/.cshrc という名前を使用して、彼女のホームディレクトリにあるファイルに到達しなければなりません。このため、ユーザーが名前を形式化するのが困難になります。また、アプリケーションがユーザーに代わって名前を自動生成することも難しくなります。FNS ポリシーでは、これらのオブジェクトをネーミングする一貫した方法を定義します。

FNS とアプリケーションの開発

アプリケーションもネームサービスを必要とします。Solaris 環境のアプリケーションでは、多くのネームサービスインタフェースを処理する必要があります。1 つのアプリケーションが、Solaris 環境の外部にある各種の互換性のないネーミングシステムと関わる場合もあります。ローカルネットワークと広域ネットワークでは、異機種の複数のハードウェアとオペレーティングシステムが接続されているので、各種のインタフェースが混在する可能性が高くなります。これらのネーミングインタフェースは大幅に異なるだけでなく、基本的なネーミング操作も通常明確ではありません。

FNS は、これらの問題を次の 2 つの方法で解決します。

FNS と複合名

アプリケーションによっては、複合名を使用して、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 ポリシーには、次の原則があります。

Solaris 環境での FNS

Solaris 環境での FNS 実装は、現在次のものの上に実装されたネームサービスで構成されています。

FNS は、FNS を使用するアプリケーションとシステムが増えるほど、Solaris のユーザーには利用しやすいものとなります。

Solaris エンタープライズレベルのネームサービス

「エンタープライズレベル」のネームサービスは、エンタープライズレベルのネットワーク内のマシン (ホスト)、ユーザー、ファイルを識別 (ネーミング) します。FNS でも、組織ユニット、地理的なサイト、アプリケーションサービスのネーミングが可能です。「エンタープライズレベル」のネットワークは、ケーブル、赤外線、ラジオブロードキャストを通して通信する単一のローカルエリアネットワーク (LAN) にできます。または、ケーブルや直接通話接続によってリンクされた複数の LAN にできます。エンタープライズレベルのネットワーク内では、DNS や X.500/LDAP などのグローバルネームサービスを参照しなくても、すべてのマシンが他のマシンと通信できます。

FNS は現在、次に 3 つのエンタープライズレベルのネームサービスをサポートしています。

FNS とエンタープライズレベルネームサービスの管理情報については、第 23 章「FNS とエンタープライズのネームサービス」を参照してください。

FNS と NIS+ のネーミング

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 コマンドで操作したりしないでください。

FNS と NIS のネーミング

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 クライアントが SKI の実行中 FNS によってコンテキストを更新する

一定の条件が合えば、NIS クライアント (マシン、プロセス、またはユーザー) はすべて、fncreate_fs や fncreate_printer などの FNS コマンドを使用して、クライアント自身のコンテキストを更新できます。これにより、NIS クライアントは、FNS コマンドを使用して、Printer Administrator、CDE カレンダマネージャ、admintool などを更新できます。

スーパーユーザー以外のユーザーが、FNS コマンドによって各自のコンテキストを更新するには、次の条件が必要です。

FNS とファイルベースのネーミング

「ファイル」とは、通常、マシンの /etc ディレクトリにあるネーミングファイルのことを指します。これらのマシンベースのファイルには、UNIX ユーザーとパスワードの情報、ホスト情報、メールエイリアスなどが入っています。これらは、オートマウントマップなどの Solaris 特定のデータもサポートします。

FNS は、ローカルファイルをフェデレートして、Solaris 環境でのネームサービスをサポートします。FNS はこのために、organization、site、user、host の各ファイルに対してネーミング操作を実行するための XFN インタフェースを提供します。これらの操作は、ファイル、ディレクトリにアクセスするための適切なプログラミングインタフェースを使用して実装されます。

ファイルベースのネーミングシステムでは、FNS コンテキストと属性は、ファイルに格納されます。これらのファイルは、NFS ファイルサーバーからエクスポートされた /var/fn ディレクトリに格納されます。

ファイルベースのネーミングシステムでは、FNS コマンドを使用して、FNS ファイル内の情報を処理します。

グローバルネームサービス

グローバルネームサービスは、電話、衛星などの通信システムによって世界中でリンクされた組織レベルのネットワークを識別 (ネーミング) します。この世界規模でリンクされたネットワークの集合は、「インターネット」と呼ばれています。ネーミングネットワークだけでなく、グローバルネームサービスも、ネットワーク内の個々のマシンとユーザーを識別します。

FNS は現在、次の 2 つのグローバルネームサービスをサポートしています。

注 -

エンタープライズレベルのネームサービスが NIS+ または NIS の場合、グローバルネームサービスだけをフェデレートできます。ファイルベースのネームサービスをエンタープライズで使用している場合は、DNS も X.500/LDAP もフェデレートできません。

FNS とエンタープライズレベルネームサービスの管理情報については、第 26 章「FNS およびグローバルネーミングシステム」を参照してください。

FNS と DNS

インターネットドメイン名システム (DNS) は、世界のインターネットにホストとドメインの名前解決を提供するネームサーバーの階層集合です。FNS は DNS を使用してエンタープライズオブジェクトをグローバルにネーミングします。

ドメイン名とは、DNS がエンタープライズレベルネットワーク (LAN または WAN) を識別するために使用する名前のことをいいます。NIS+ を使用するネットワークでは、親ドメイン内でのサブドメインの作成が可能であり、DNS はこのようなサブドメインを識別できます。

名前は、インターネット上でアクセス可能なすべてのエンタープライズについて作成できます。したがって、名前は、これらのエンタープライズからエクスポートされたオブジェクトにも作成できます。FNS と DNS の詳細は、「DNS でフェデレートする」を参照してください。

FNS と X.500

X.500 はグローバルディレクトリサービスです。この各構成要素は、世界規模の範囲内のオブジェクトに関する情報を管理するためにともに機能します。このようなオブジェクトには、国、組織、ユーザー、マシンが含まれます。FNS は、X.500 をフェデレートして、エンタープライズネームサービスへのグローバルアクセスを可能にします。次の 2 つの API のうち 1 つを使用して、X.500 グローバルディレクトリサービスにアクセスできます。

X.500 のフェデレートについては、「X.500/LDAP でフェデレートする」を参照してください。

FNS とアプリケーション

FNS は、次のものをサポートします。

FNS ファイルネーミング

FNS ベースのファイルネーミングは、FNS ネーミングを Solaris ファイルサービスに統合します。FNS ベースのファイルネーミングを使用すると、他のファイルに関連しないアプリケーションと共有される FNS ポリシーによって、ユーザー、ホスト、サイト、組織に対応してファイルをネーミングできます。

FNS ベースのファイルネーミングは、クライアントに対して、グローバルかつエンタープライズ規模のファイル名前空間の共通表示を提供します。ファイルシステムにアクセスする Solaris アプリケーションは、FNS によってサポートされるファイル名前空間に、変更せずにアクセスできます。

FNS プリンタネーミング

FNS ベースのプリンタネーミングは、バンドルされていない SunSoft Print Client (SSPC) の基本ネーミング機能となります。FNS ベースのプリンタネーミングを使用すると、他の印刷関連ではないアプリケーションと共有される FNS ポリシーを使用して、ユーザー、ホスト、サイト、組織に対応してプリンタをネーミングできます。

FNS ベースのプリンタネーミングは、クライアントに対して、グローバルかつエンタープライズ規模のプリンタ名前空間の共通表示を提供します。また、これを使用すると、プリンタ名前空間を中央で管理できます。

FNS アプリケーションサポート

FNS を認識するアプリケーションでは、名前空を FNS ポリシーに従って構成できます。また、FNS 名前空で名前を割り当てるアプリケーションは、これらのポリシーに従う必要があります。

アプリケーションは、FNS を次の 3 つの方法で使用します。

FNS の管理

FNS システムの管理は、基本となるネームサービスによって異なります。

各自のユーザーサブコンテキストをユーザーが変更できるかどうかは、基本となるネームサービスによって異なります。

問題解決とエラーメッセージ

一般的な FNS の問題を追跡して解決する方法については、「FNS の問題と対策」を参照してください。FNS のエラーメッセージは、付録 B 「エラーメッセージ」 に記載されています。