test

Solaris のシステム管理 (ネーミングとディレクトリサービス : FNS、NIS+ 編)

パート IV FNS の設定、構成、および管理

このパートでは、フェデレーテッド・ネーミング・サービス (FNS) の設定、構成、および管理について説明します。

第 25 章 フェデレーテッド・ネーミング・サービス (FNS)

この章では、NIS+、NIS、またはファイルを使用したネームサービス環境にフェデレーテッド・ネーミング・サービス (FNS) を設定および構成する方法について説明します (「ファイルを使用した」ネームサービスでは、NIS+ または NIS ではなく、/etc ファイルからデータを取得します)。また、Solaris オペレーティング環境上の FNS に関する管理方法および問題解決について説明します。

FNS の手引き

「FNS」は、1 つの Solaris オペレーティング環境でさまざまなネームサービスを独立して動作させるための機能です。FNS を使用すれば、ネットワーク上のさまざまなネームサービスすべてに、1 つの簡単なネームシステムインタフェースで対応できます。FNS は、X/Open federated naming (XFN) 規格に適合しています。

FNS は、NIS+、NIS、DNS、/etc ファイルの代わりとして使用することはできません。FNS はむしろこれらのサービスの一番上に位置しており、通常の名前をデスクトップ上のアプリケーションで使用できるようにします。

XFN (X/Open Federated Naming)

FNS がサポートするプログラミングインタフェースとそのポリシーは、XFN (X/Open Federated Naming) に述べられています。

FNS を使用する理由

FNS は、次の点で有用です。

複合名と複合コンテキスト

FNS の基本概念として、複合名と複合コンテキストがあります。

複合名

複合名とは、複数のネーミングシステムで使用される名前のことをいいます。

複合名は、複数の構成要素の順序付きリストからなります。各構成要素は、単一のネーミングシステムの名前空間からとられた名前です。各構成要素の構文は、個々のネーミングシステムにより異なります。FNS は、複数のネーミングシステムからとられた名前を使用して複合名を作成するときの構文を定義します。複合名は、スラッシュ (/) を構成要素区切り文字として使用して、左から右へ作成されます。

たとえば、複合名 .../doc.com/site/bldg-5.alameda は、...、doc.com、site、bldg-5.alameda という 4 つの構成要素から構成されます。

コンテキスト

コンテキストは、次の操作を行います。

コンテキストには、一連の名前とリファレンスの割り当てが含まれます。各リファレンスには、通信の終端またはアドレスのリストが含まれます。フェデレーテッド・ネーミング・システムは、別のネーミングシステムのコンテキストで割り当て中の、あるネーミングシステムのコンテキストによって形成されます。複合名の解釈処理は、その名前全体が解釈処理されるまで、あるネーミングシステム内のコンテキストから、次のネーミングシステム内のコンテキストへと進みます。

属性

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

属性はユニークな属性識別子、属性構文、および 0 個以上の明確な属性値のセットからなります。

XFN で、既存の名前付きオブジェクトに対応する属性値の検索や変更のための、基本的な属性インタフェースが定義されます。これらのオブジェクトは、コンテキストまたは他の任意のタイプのオブジェクトにできます。コンテキストに関連しているのは、構文属性で、これはコンテキストがどのように複合名を解析するかを示します。

拡張属性インタフェースには、特定の属性を検索したり、オブジェクトやそれに対応する属性を作成するオペレーションが含まれます。

FNS とネームサービススイッチ

FNS (XFN API を Solaris 上に実装したもの) は、クライアントがネーム情報を照会するためのネームサービスを指定するときにも使用できます。XFN API は、X、Y 両次元において、スイッチファイルを使用する最新の getXbyY() インタフェースよりも一般的です。たとえば、XFN API を使用して、NIS+ と NIS の両方からホストとユーザーに関する情報を調べることができます。アプリケーションは、getXbyY()、XFN、あるいはその両方のクライアントとして使用できます。

FNS とスイッチファイルに一貫性を持たせる

FNS による名前空間データの変更を、スイッチファイルを使用して名前空間情報を入手しているクライアントが常に把握できるようにするために、スイッチと FNS には常に同じネームサービスを設定してください。

名前空間の更新

XFN API によるデータ更新は、getXbyY() インタフェースによる更新よりも優れています。ほとんどの名前空間は複数ソースのデータで構成されています。たとえば、groups の名前空間には、/etc/group ファイルと NIS+ group.org_dir オブジェクトの両方の情報があるかもしれません。しかし、スイッチファイルは、グループデータの特定の部分のソースや更新するソースを識別するための、アプリケーションの更新関数に十分な情報を提供しません。

各 FNS の従属名前空間は、すべてが 1 つのネームサービスから取られます。更新がどのネームサービスに行われるかというような混乱がないため、更新は簡単明瞭なものになります。

エンタープライズネームサービス

エンタープライズレベルのネームサービスは、組織内のオブジェクトをネーミングするために使用されます。現在 FNS は、次の 3 つのエンタープライズレベルのネームサービスをサポートしています。サポートされているネームサービスは、NIS+、NIS およびファイルの 3 つです。

NIS+

NIS+ は、Solaris オペレーティング環境で推奨されるエンタープライズ規模の情報サービスです。FNS の組識単位は、NIS+ のドメインとサブドメインに対応します。各ドメインとサブドメインごとに 1 つの orgunit コンテキストがあります。

NIS+ のもとで、FNS のコンテキストと属性データは、NIS+ テーブルに格納されます。これらのテーブルは、ctx_dir という名前の NIS+ ディレクトリオブジェクトに格納されます。各 NIS+ ドメインとサブドメインごとに 1 つの ctx_dir ディレクトリオブジェクトがあり、ドメインの groups_dir および org_dir の各ディレクトリオブジェクトと同じレベルにあります。したがって、ディレクトリオブジェクト ctx_dir.sales.doc.com. には、sales.doc.com ドメインの FNS コンテキストと属性データを格納する FNS テーブルが含まれます。

NIS+ のもとでは、FNS と NIS+ のコマンドを使用して、FNS テーブル内の情報を処理します。これらのテーブルを直接編集したり、UNIX コマンドを使用して処理したりしないでください。

NIS

NIS は、Solaris オペレーティング環境上に実装されたエンタープライズ規模の情報サービスです。 各エンタープライズは 1 つの NIS ドメインにあたります。1 つの NIS ドメインに対応する 1 つの FNS 組識単位があります。

NIS のもとで、FNS のコンテキストと属性データは NIS マップに格納されます。これらのマップは、NIS サーバー上の /var/yp/domainname ディレクトリに格納されます。NIS では、スーパーユーザーは、FNS コマンドを使用して、FNS マップ内の情報を処理できます。

SKI が実行されている場合に NIS クライアントが FNS でコンテキストを更新する

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

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

注 –

SKI は 64 ビットモードをサポートしていません。したがって NIS クライアントは 64 ビットモードでのコンテクストの更新は行うことができません。

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

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

ファイルベースのネーミングシステムでは、FNS コンテキストと属性データはファイルに格納されます。これらの FNS ファイルは、マシンの /var/fn ディレクトリに格納されます。/var/fn ディレクトリを各マシンに置く必要はありません。このディレクトリは、NFS ファイルサーバーからエクスポートされます。

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

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

FNS は、DNS と X.500 による NIS+ と NIS のフェデレートもサポートします。つまり、エンタープライズレベルの名前空間をグローバル名前空間に接続し、エンタープライズオブジェクトをグローバルな有効範囲でアクセス可能にできるということです。

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

FNS ネーミングポリシー

FNS は、ネーミングポリシーを定義して、ユーザーとアプリケーションが共有名前空間に依存し、それを使用できるようにします。

エンタープライズ内には、組識単位、サイト、ホスト、ユーザー、ファイルとサービスごとの名前空間があり orgunit、site、host、user、fs (ファイルシステムを示す)、および service という名前で呼ばれます。これらの名前空間は、各名前の前に下線 (_) を付けることもできます。たとえば、host と _host は同じものと見なされます。

表 25–1 は、エンタープライズレベルの名前空間に関する FNS ポリシーを要約しています。

表 25–1 FNS ポリシーの要約

コンテキストタイプ 

従属コンテキスト 

親コンテキスト 

orgunit _orgunit

site user host fs service

enterprise root

site _site

user host fs service

enterprise root

orgunit

user _user

service fs

enterprise root

orgunit

host _host

service fs

enterprise root

orgunit

service _service

プリンタなどのアプリケーション 

enterprise root

orgunit site user host

fs _fs (ファイルシステム)

(なし) 

enterprise rootorgunit site user host

組識名

FNS orgunit の割り当ては、基本となるネームサービスによって決まります。

組識単位名に対応して命名されるオブジェクトのタイプは、user、host、service、fs、site です。次に例を示します。

サイト名

サイト名は、必要に応じて作成されます。サイト名に対応して指定されるオブジェクトのタイプは、user、host、service、fs です。次に例を示します。

ユーザー名

ユーザー名は、NIS+ の対応する passwd テーブル、NIS の passwd マップ、またはファイルの /etc/passwd ファイルにある名前に対応します。ユーザーのファイルコンテキストは、そのユーザーの passwd エントリから獲得されます。

ユーザー名に対応して指定されるオブジェクトのタイプは、 service と fs です。 次に例を示します。

ホスト名

ホスト名は、NIS+ の対応する hosts、NIS の hosts マップ、またはファイルの /etc/hosts ファイルにある名前に対応します。ホストのファイルコンテキストは、ホストによってエクスポートされるファイルシステムに対応します。

ホスト名に対応して指定されるオブジェクトのタイプは、service と fs です。 次に例を示します。

サービス名

サービス名は、サービスアプリケーションに対応し、それによって決定されます。service コンテキストは、組識、ユーザー、ホスト、またはサイトコンテキストに対応して指定する必要があります。次に例を示します。

ファイル名

ファイルシステム名は、ファイル名に対応します。次に例を示します。

開始前に必要な処置

各自のネームサービスで FNS を開始するには、fncreate コマンドを実行します。

fncreate コマンドは、FNS コンテキストが作成されるネームサービス (NIS+、NIS、ファイルベースなど) を認識します。特定のネームサービスを指定するには、下記の デフォルト以外のネームサービスの指定で説明する、fnselect コマンドを実行する必要があります。

デフォルト以外のネームサービスの指定

デフォルトでは次のようになります。

fnselect コマンドを使用すると、デフォルト以外のターゲットネームサービスを明確に指定することもできます。たとえば、次のコマンドは、ターゲットネームサービスに NIS を選択します。 


# fnselect nis

FNS 名前空間の作成

デフォルトポリシー、または fnselect によって明示的にネームサービスを指定したら、次のコマンドを使用して、FNS 名前空間を作成できます。 


# fncreate -t org org//

このコマンドは、対応するネームサービス内のユーザーとホストに必要なすべてのコンテキストを作成します。

NIS+ についての考慮事項

各自のエンタープライズレベルの基本ネームサービスが NIS+ の場合は、次の点を考慮に入れてください。

NIS+ のドメインとサブドメイン

上記のコマンド構文は、ルート NIS+ ドメインの FNS 名前空間を作成します。ルート以外のドメインを指定するには、次のように、2 つのスラッシュの間にドメイン名を追加します。


# fncreate -t org org/sales.doc.com./

完全指定の sales.doc.com. の最後のドットに注意してください。

空間とパフォーマンスの考慮事項

fncreate コマンドは、ctx_dir ディレクトリに NIS+ のテーブルとディレクトリを作成します。ctx_dir ディレクトリオブジェクトは、ドメインの NIS+ の groups_dir と org_dir ディレクトリオブジェクトと同じレベルにあります。

NIS+ のセキュリティ要件

fncreate などの FNS コマンドを実行するユーザーは、必要な NIS+ 資格を持つことが前提とされます。

環境変数 NIS_GROUP は、fncreate によって作成された NIS+ オブジェクトのグループ所有者を指定します。NIS+ オブジェクトの管理を容易にするために、NIS_GROUP には、そのドメインの FNS 管理を担当する NIS+ グループ名を設定してから、fncreate などの FNS コマンドを実行する必要があります。

デフォルトのアクセス制御権を含む NIS+ 関連属性は、コンテキストの作成後、NIS+ の管理ツールやインタフェースを使用して変更できます。FNS 複合名に対応する NIS+ オブジェクト名は、後で説明する fnlookup および fnlist によって獲得できます。

NIS についての考慮事項

fncreate コマンドは、FNS マップの NIS マスターサーバーとして機能する NIS システム上のスーパーユーザーが実行してください。

FNS によって使用される NIS マップは、/var/yp/domainname に保存されています。

FNS NIS マスターサーバー上のスーパーユーザーだけが、FNS コマンドを使用して FNS 情報を変更できます。

ファイルについての考慮事項

fncreate に -t org オプションを付けて FNS 名前空間を作成する場合は、/var が存在するファイルシステムを所有するマシン上のスーパーユーザーが、コマンドを実行してください。FNS が使用するファイルは、/var/fn ディレクトリに格納されています。

ユーザーのコンテキストを作成すれば、ユーザーは、各自の UNIX 資格に基いて、各自のコンテキストを変更できます。

ファイルシステム /var/fn は、エクスポートすることにより、別のシステムでマウントして、FNS 名前空間にアクセスできます。

FNS 名前空間の表示

名前空間を設定したら、次のコマンドを使用して表示できます。

コンテキストの内容の表示

次の fnlist コマンドは、name のコンテキスト名とリファレンスの割り当てを表示します。 


fnlist [-lvA] [name]
表 25–2 fnlist コマンドのオプション

オプション 

説明 

name

複合名。name のコンテキストでの名前の割り当てを表示する

-v

詳細。割り当てに関する詳細な情報を表示する 

-l

指定のコンテキストで割り当てられた名前の割り当ても表示する 

-A

fnlist で、権限のあるサーバーからの情報を強制的に獲得する。NIS と NIS+ で、これは、ドメインのマスターサーバーになる。-A オプションは、基本ネームサービスがファイルベースの場合、無効である

たとえば、

初期コンテキストの名前をリスト表示する場合


% fnlist

現在の組識単位内のユーザーすべての詳細をリスト表示する場合 


% fnlist -v user

ユーザー pug の service コンテキストの内容をリスト表示する場合


% fnlist user/pug/service

権限のあるサーバーからの名前と割り当てをリスト表示する場合


% fnlist -l -A

複合名の割り当ての表示

fnlookup コマンドは、指定の複合名の割り当てを表示します。 


fnlookup [-vAL] [name]
表 25–3 fnlookup コマンドのオプション

オプション 

説明 

name

コンテキスト名。name の割り当てと XFN リンクを表示する

-v

詳細。割り当てに関する詳細な情報を表示する 

-L

名前に割り当てられている XFN リンクを表示する 

-A

fnlist で、権限のあるサーバーからの情報を強制的に獲得する。NIS と NIS+ で、これは、ドメインのマスターサーバーになる。-A オプションは、基本ネームサービスがファイルベースの場合、無効である

たとえば、user/ana/service/printer の割り当てを表示するには、次のコマンドを実行します。


# fnlookup user/ana/service/printer

複合名の属性の表示

fnattr コマンドは、指定の複合名の属性を表示、更新します。

たとえば、ユーザー ada に関連する属性を検索するには、次のコマンドを実行します。


# fnattr user/ada

プリンタ laser-9 に関連する属性を検索するには、次のコマンドを実行します。


# fnattr thisorgunit/service/printer/laser-9

詳細については、属性の処理を参照してください。

FNS 情報の検索

fnsearch コマンドは、属性が所定の検索基準を満たす複合名以下で割り当てられたオブジェクト名を表示し、必要に応じてその属性とリファレンスを表示します。

たとえば、

realname という属性を持つユーザーとその属性を表示するには、次のコマンドを実行します。


% fnsearch user realname

値が Ravi Chattha の属性 realname を持つユーザーをリスト表示するには、次のコマンドを実行します。


% fnsearch user “realname == 'Ravi Chattha'”

fnsearch コマンドは、共通のブール型演算子を使用します。上記の例では、二重引用符と一重引用符、2 つの等号の使用に注意してください。

名前空間の更新

名前空間を設定したら、次のコマンドを使用して、要素の追加、削除、および変更できます。

FNS 管理特権

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

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

複合名へのリファレンスの割り当て

fnbind コマンドは、既存のリファレンス (名前) を新しい複合名に割り当てるために使用されます。


fnbind -r [-s][-v][-L] name [-O|-U] newname reftype addrtype [-c|-x] address
表 25–4 fnbind コマンドのオプション

オプション 

説明 

name

すでに存在している複合名 

newname

新しい割り当ての複合名 

addrtype

使用するアドレスのタイプ。onc_cal_str のようにアプリケーション特定

address

使用するアドレスの内容。たとえば、tsvi@altair

reftype

使用するリファレンスのタイプ。one_calendar のようにアプリケーション特定

-s

すでに割り当てられている場合でも、newname に割り当てられる。これは、以前の newname の割り当てを置き換える。-s を指定しないと、 newname がまだ割り当てられていない場合、fnbind は失敗する

-v

newname に割り当てられるリファレンスを表示する

-L

oldname を使用して XFN リンクを作成し、それを newname に割り当てる

-r

コマンド行引数によって作成されたリファレンスに newname を割り当てる

-c

入力された形式で address の内容を格納する。XDR コードは使用しない

-x

address を XDR コードに変換しないで、16 進文字列に変換する

-O

識別子の形式は FN_ID_ISO_OID_STRING。これは、ASN.1 のドットで区切られた整数リスト文字列である

-U

識別子の形式は FN_ID_DCE_UUID。これは、文字列形式での DCE UUID である

次に例を示します。

ユーザー jamal にカレンダ割り当てを追加する場合


# fnbind -r user/jamal/service/calendar onc_calendar onc_cal_str
 jamal@cygnus

org//service/Sparc-4 の既存の割り当てを、org//service/printer の割り当てによって置換する場合


# fnbind -s org//service/printer org//service/Sparc-4

site/bldg-5/service/printer のリファレンスを user/ando/service/printer にコピーする場合


# fnbind site/bldg-5/service/printer user/ando/service/printer

シンボリックリンクを使用して、site/bldg-5/service/printer のリファレンスを user/ando/service/printer に割り当てる場合


# fnbind -L site/bldg-5/service/printer user/ando/service/printer

staff@altair が onc_cal タイプのリファレンスであり、かつタイプ onc_cal_str のアドレスである場合、thisens/service/calendar の名前をアドレス staff@altair に割り当てる場合


# fnbind -r thisens/service/calendar onc_calendar onc_cal_str staff@altair

コマンド行 address によって作成されたリファレンスとして newname を割り当てる場合


# fnbind -r [-sv] newname [-O|-U] reftype {[-O|-U] addrtype [-c|-x] address}

割り当ての削除

fnunbind コマンドは、割り当てを削除するために使用されます。

たとえば、user/jsmith/service/calendar の割り当てを削除するには、次のコマンドを実行します。


# fnunbind user/jsmith/service/calendar

新しいコンテキストの作成

fncreate コマンドは、コンテキストを作成するために使用されます。 


fncreate -t context [-f file] [-o] [-r reference] [-s] [-v] [-D] name
表 25–5 fncreate コマンドオプション

オプション 

説明 

-t context

context タイプのコンテキストを作成する。context タイプは、org、hostname 、host、username、 user、service、fs、 site、nsid、generic

-f file

入力ファイルを使用して、コンテキストを作成するユーザーとホストを一覧表示する 

-r reference

リファレンスのタイプ。-r reference オプションは、-t generic とともにしか使用できない

name

複合名 

-o

name によって識別されるコンテキストだけを作成する

-s

既存の割り当てすべてを上書き (置換) する。-s を使用しないと、名前がすでに割り当てられている場合、fncreate は失敗する

-D

各コンテキストの作成時に、そのコンテキストと、対応するテーブル、ディレクトリ、ファイルに関する情報を表示する 

-v

詳細。各テキストの表示時にその情報を表示する 

次に例を示します。

ルート組識のコンテキストとサブコンテキストを作成する場合


# fncreate -t org org//

ホスト deneb のコンテキストとサブコンテキストを作成する場合 


# fncreate -t host host/deneb

コンテキスト、サービス、ファイルサブコンテキストを作成して、ユーザー sisulu のカレンダ割り当てを追加する場合


# fncreate -t user user/sisulu
# fnbind -r user/sisulu onc_calendar onc_cal_str sisulu@deneb

sales 組識のサイトコンテキストを作成する場合 


# fncreate -t site org/sales/site/

サイトコンテキストは、ドットで区切られた右から左へという順番の名前によって、階層名前空間をサポートします。これにより、地理上のカバレージ関係によってサイトを区分化できます。たとえば、サイトコンテキスト alameda とサイトサブコンテキスト bldg-6.alameda を作成するには、次のコマンドを実行します。 


# fncreate -t site org/sales/site/alameda
# fncreate -t site org/sales/site/bldg-6.alameda

ファイルコンテキストの作成

表 25–6 fncreate_fs コマンドのオプション

オプション 

説明 

name

ファイルコンテキスト名 

options

マウントオプション 

mount

マウントする位置 

-f file

入力ファイル 

-v

詳細。作成中のコンテキストに関する情報を表示 

-r

コンテキスト name の割り当てを、入力で指定された割り当てによって置換する

次に例を示します。

FNS サーバー server4 の /export/data パスに割り当てられた sales 組識に関して、ファイルシステムコンテキスト data を作成する場合


# fncreate_fs org/sales/fs/data server4:/export/data

2 つの異なるサーバーにマウントされた buyers および buyers/orders という名前の sales 組識に関して、ファイルシステムコンテキストの階層を作成する場合


# fncreate_fs org/sales/fs/buyers server2:/export/buyers
# fncreate_fs org/sales/fs/buyers/orders server3:/export/orders

input_a という名前の入力ファイルによって指定されたサーバーとパスに割り当てられた sales 組識に関して、leads という名前のファイルシステムコンテキストを作成する場合


# fncreate_fs -f input_a org/sales/fs/leads

入力ファイル形式については、fncreate_fs(1M) のマニュアルページを参照してください。

プリンタコンテキストの作成

fncreate_printer コマンドは、組識、ユーザー、ホスト、サイトの各コンテキストのプリンタコンテキストを作成します。プリンタコンテキストは、対応する複合名のサービスコンテキストのもとで作成されます。 


fncreate_printer [-vs] name printer [prntaddr]
 

fncreate_printer [-vs] [-f [file]] name
表 25–7 fncreate_printer コマンドのオプション

オプション 

説明 

name

プリンタの組識、ホスト、ユーザー、またはサイトの名前 

printer

プリンタ名 

prntaddr

プリンタアドレス。<addresstype>=<address> という形式をとる

-f file

指定のファイルを、作成するプリンタリストへの入力として使用。入力ファイルは /etc/printers.conf ファイルの形式をとる。プリンタ名 も -f ファイル も指定されていない場合、fncreate_printer は、fncreate_printer がデフォルト入力ファイルとして実行されるマシン上の /etc/printer.conf ファイルを使用する

-s

既存のアドレスを、同じアドレスタイプによって置換する 

-v

詳細。割り当ての詳細を表示する 

次に例を示します。

fncreate_printer が実行されるマシンの /etc/printers.conf ファイルに示されたプリンタに基いて sales 組識のプリンタを作成する場合 


# fncreate_printer -s org/sales/

マシン altair が、プリンタ Sparc-5 のサーバーであると想定します。ユーザー nguyen に対して、実際に Sparc-5 プリンタである invoices という名前のプリンタを作成する場合、次のように入力します。


# fncreate_printer user/nguyen invoices bsdaddr=altair,Sparc-5

プリンタを階層構造で構成することもできます。たとえば、fncreate_printer コマンドは、プリンタ color、color/inkjet、color/Sparc のプリンタコンテキストを作成できます。コンテキストは次のようになります。


org/doc.com/service/printer/color
org/doc.com/service/printer/color/inkjet
org/doc.com/service/printer/color/Sparc

上記のコンテキストを作成するには、次のコマンドを実行します。


# fncreate_printer org/doc.com color bsdaddr=colorful,color
# fncreate_printer org/doc.com color/inkjet bsdaddr=colorjet,inkjet
# fncreate_printer org/doc.com color/Sparc bsdaddr=colorprt,Sparc

コンテキストの削除

fndestroy コマンドは、空のコンテキストを削除するために使用されます。

たとえば、ユーザー patel の service コンテキストを削除するには、次のコマンドを実行します。


# fndestroy user/patel/service

属性の処理

fnattr コマンドは、名前に関連する属性の追加、削除、または変更に使用できます。変更は一度に 1 つずつ行うことも、同じコマンド内で何回かバッチ処理することもできます。

表 25–8 fnattr コマンドのオプション

オプション 

説明 

name

複合名 

attrib

属性の識別子 

values

1 つまたは複数の属性値 

oldvalue

新しい値によって置換される属性値 

newvalue

古い値を置換する属性値 

-a

属性の追加 

-d

属性の削除 

-l

属性のリスト表示 

-m

属性の変更 

-s

指定された属性の新しい値によって、すべての古い属性値を置換する 

-O

識別子の形式は FN_ID_ISO_OID_STRING。これは、ASN.1 のドットで区切られた整数リスト文字列である

-U

識別子の形式は FN_ID_DCE_UUID。これは、文字列形式での DCE UUID である

次に例を示します。

ユーザー名 rosa に関連する属性すべてを表示する場合


# fnattr user/rosa

ユーザー uri に関連する size 属性を表示する場合


# fnattr user/uri/ size

devlin という名前のユーザーについて、値が small の属性 shoesize を追加するには、hatsize 属性を削除して、dresssize 属性の値を 12 から 8 に変更します。


# fnattr user/devlin -a shoesize small -d hatsize -m dresssize 12 8

グローバル名前空間のフェデレート

NIS+ または NIS は、DNS や X.500 などのグローバルネームサービスにフェデレートできます。

NIS+ または NIS の名前空間を DNS または X.500 のもとでフェデレートするには、まず NIS+ 階層または NIS ドメインのルートリファレンスを獲得する必要があります。

グローバルネームサービスでは、ルートリファレンスは、「次のネーミングシステムリファレンス」として知られています。これは、このリファレンスが、DNS ドメインまたは X.500 エントリの下にある次のネーミングシステムを指すためです。NIS+ または NIS をグローバルネームサービスによってフェデレートするには、そのグローバルサービスに、ルートリファレンス情報を追加します。

ルートリファレンス情報をグローバルサービスに追加すると、各自の NIS+ 階層または NIS ドメインの外部のクライアントは、その NIS+ 階層または NIS ドメインのコンテキストにアクセスして、操作を実行できます。外部 NIS+ クライアントは、未認証 NIS+ クライアントとしてその階層にアクセスします。

たとえば :

NIS+ が、DNS ドメイン doc.com. の下でフェデレートされる場合は、次のコマンドを使用して NIS+ エンタープライズのルートをリスト表示できます。


# fnlist .../doc.com/

NIS+ が、X.500 エントリ /c=us/o=doc の下でフェデレートされる場合は、次のコマンドを使用して NIS+ エンタープライズのルートをリスト表示できます。 


# fnlist .../c=us/o=doc/

どちらの例でも、最後にスラッシュが必要であることに注意してください。

FNS コンテキストのコピーと変換

fncopy コマンドは、FNS のコンテキストと属性を新しい FNS コンテキストにコピー、または変換するために使用できます。

-i および -o オプションを使用すると、あるエンタープライズレベルのネームサービスに基く FNS コンテキストを、異なるネームサービスに基くコンテキストにコピーできます。たとえば、NIS の上部で実行される FNS インストール環境があって、NIS サービスを NIS+ にアップグレードする場合、fncopy を使用すると、NIS+ を使って新しいコンテキストを作成できます。

以下の点に注意してください。

表 25–9 fncopyコマンドオプション

オプション 

説明 

-i oldservice

エンタープライズレベルの古い (入力) 基本ネームサービス。たとえば、-i nis は、古いサービスが NIS であることを指定する。指定できる値は、files、nis、nisplus

-o newservice

エンタープライズレベルの新しい (出力) ネームサービス。たとえば、-o nisplus は、新しいサービスが NIS+ であることを指定する。指定できる値は、files、nis、nisplus

-f filename

コピーされる FNS コンテキストのリストが入っているテキストファイル。-i および -o オプションを指定しない場合、コンテキストは、グローバル名を使用する識別子でなければならない

oldcontext

コピーされるコンテキスト名 

newcontext

作成先またはコピー先のコンテキスト名 

たとえば、doc.com プリンタコンテキスト (およびサブコンテキスト) と割り当てを orgunit/east/doc.com にコピーするには、次のコマンドを実行します。 


# fncopy .../doc.com/service/printer .../doc.com/orgunit/east/service/printer

ファイル user_list に指定された NIS FNS ユーザーのコンテキストを、orgunit west/doc.com の NIS+ FNS ユーザーのコンテキストにコピーするには、次のコマンドを実行します。


# fncopy -i nis -o nisplus -f /etc/user_list thisorgunit/user org/doc.com/user

名前空間ブラウザのプログラムの例

この節のプログラミング例は、次の操作を実行するための XFN API の使用法を示しています。

コンテキストに割り当てられた名前のリスト表示

次の例は、コンテキストをリスト表示するための XFN 操作を示しています。


#include <stdio.h>
#include <xfn/xfn.h>
#include <string.h>
#include <stdlib.h>
/*
 このルーチンは与えられたコンテキスト (ctx_name) の下で
 割り当てられた名前のリストを返す。
 ctx_name の例としては "user"、"thisorgunit/service"、
 host/alto/service、user/jsmit/service/calendar などがある
*/
typedef struct fns_listing {
 char *name;
 struct fns_listing *next;
} fns_listing;
fns_listing *
fns_list_names(const char *ctx_name)
{
 FN_status_t *status;
 FN_ctx_t *initial_context;
 FN_composite_name_t *context_name;
 FN_namelist_t *name_list;
 FN_string_t *name;
 unsigned int stat;
 fns_listing *head = 0, *current, *prev;
 int no_names = 0;
 status = fn_status_create();
 /* 初期コンテキストの獲得 */
 initial_context = fn_ctx_handle_from_initial(0, status);
 if (!fn_status_is_success(status)) {
  fprintf(stderr, "Unable to obtain intial context\n");
  return (0);
 }
 context_name = fn_composite_name_from_str((unsigned char *)
                   ctx_name);
 /* FNS によるリスト名の呼び出し */
 name_list = fn_ctx_list_names(initial_context, context_name,
              status);
 if (!fn_status_is_success(status)) {
  fprintf(stderr, "Unable to list names\n");
  return (0);
 }
 /* 名前を個々に呼び出す */
 while (name = fn_namelist_next(name_list, status)) {
  no_names++;
 current = (fns_listing *) malloc(sizeof(fns_listing));
 current->name = (char *)
  malloc(strlen((char *) fn_string_str(name, &stat)) + 1);
 strcpy(current->name, (char *) fn_string_str(name, &stat));
 current->next = 0;
 if (head) {
  prev->next = current;
  prev = current;
 } else {
  head = current;
  prev = current;
 }
 fn_string_destroy(name);
}
fn_namelist_destroy(name_list);
fn_status_destroy(status);
fn_ctx_destroy(initial_context);
return (head);

割り当ての作成

例 25–1 は、割り当ての作成方法を示しています。

例 25–1 割り当ての作成


#include <stdio.h>
#include <xfn/xfn.h>
#include <string.h>
/*
 このルーチンは "name" によって提供される名前を使用して
 バインディングを作成する。提供される名前のリファレンスのタイプは
 "reference_type" で、アドレスのタイプは "address_type"である。
 関数の使用例として
  fns_create_bindings(
  "user/jsmith/service/calendar"、
  "onc_calendar"、
  "onc_cal_str"、
  "jsmith&calserver");
 がある
*/
int fns_create_bindings(
 char *name,
 char *reference_type,
 char *address_type,
 char *data)
{
 int return_status;
 FN_composite_name_t *binding_name;
 FN_identifier_t ref_id, addr_id;
 FN_status_t *status;
 FN_ref_t *reference;
 FN_ref_addr_t *address;
 FN_ctx_t *initial_context;
 /* 初期コンテキストの獲得 */
 status = fn_status_create();
 initial_context = fn_ctx_handle_from_initial(0, status);
 /* エラーメッセージの状態のチェック */
 if ((return_status = fn_status_code(status)) != FN_SUCCESS) {
  fprintf(stderr, "Unable to obtain the initial context\n");
  return (return_status);
 }
 /* プリンタ名に付ける複合名の獲得 */
 binding_name = fn_composite_name_from_str((unsigned char *) name);
 /* アドレスのコンストラクト */
 addr_id.format = FN_ID_STRING;
 addr_id.length = strlen(address_type);
 addr_id.contents = (void *) address_type;
 address = fn_ref_addr_create(&addr_id,
  strlen(data), (const void *) data);
 /* リファレンスのコンストラクト */
 ref_id.format = FN_ID_STRING;
 ref_id.length = strlen(reference_type);
 ref_id.contents = (void *) reference_type;
 reference = fn_ref_create(&ref_id);
 /* リファレンスにアドレスを追加する */
 fn_ref_append_addr(reference, address);
 
 /* 割り当ての作成 */
 fn_ctx_bind(initial_context, binding_name, reference, 0, status);
 /* エラー状態をチェックして返す */
 return_status = fn_status_code(status);
 fn_composite_name_destroy(binding_name);
 fn_ref_addr_destroy(address);
 fn_ref_destroy(reference);
 fn_ctx_destroy(initial_context);
 return (return_status);
}

オブジェクト属性のリスト表示と処理

次の例は、オブジェクト属性をリスト表示して処理する方法を示しています。

オブジェクト属性のリスト表示

次の例は、オブジェクト属性をリスト表示する方法を示しています。


#include <stdio.h>
#include <xfn/xfn.h>
/*
 このルーチンは名前付きオブジェクトに関連付けられたすべての属性を
 標準出力に出力する。関数の使用例として fns_attr_list("user/jsmith"); や
 fns_attr_list("thisorgunit/service/printer/color"); がある
*/
void fns_attr_list(const char *name)
{
 FN_composite_name_t *name_comp;
 const FN_identifier_t *identifier;
 FN_attribute_t *attribute;
 const FN_attrvalue_t *values;
 char *id, *val;
 FN_multigetlist_t *attrset;
 void *ip;
 FN_status_t *status;
 FN_ctx_t *initial_context;
 name_comp = fn_composite_name_from_str((unsigned char *) name);
 status = fn_status_create();
 /* 初期コンテキストの獲得 */
 initial_context = fn_ctx_handle_from_initial(0, status);
 if (!fn_status_is_success(status)) {
  fprintf(stderr, "Unable to obtain intial context\n");
  return;
 }
 /* 全属性の獲得 */
 attrset = fn_attr_multi_get(initial_context, name_comp, 0, 0,
        status);
 if (!fn_status_is_success(status)) {
  fprintf(stderr, "Unable to obtain attributes\n");
  return;  }
 /* 全属性の表示 */
 while (attribute = fn_multigetlist_next(attrset, status)) {
  identifier = fn_attribute_identifier(attribute);
  switch(identifier->format) {
  case FN_ID_STRING:
  id = (char *) malloc(identifier->length + 1);
  memcpy(id, identifier->contents, identifier->length);
  id[identifier->length] = '\0';
  printf("Attribute Identifier: %s", id);
  free(id);
  break;
 default:
  printf("Attribute of non-string format\n\n");
  continue;
 }
for (values = fn_attribute_first(attribute, &ip);
 values != NULL;
 values = fn_attribute_next(attribute, &ip)) {
 val = (char *) malloc(values->length + 1);
 memcpy(val, values->contents, values->length);
 val[values->length] = '\0';
 printf("Value: %s", val);
  free(val);
 }
 fn_attribute_destroy(attribute);
 printf("\n");
 }
 fn_multigetlist_destroy(attrset);
 fn_ctx_destroy(initial_context);
 fn_status_destroy(status);
 fn_composite_name_destroy(name_comp);
}

オブジェクト属性の追加、削除、変更

次の例は、オブジェクト属性の追加、削除、変更を示しています。


#include <stdio.h>
#include <xfn/xfn.h>
/*
 このルーチンは名前付きオブジェクトに関連付けられた属性を変更する。
 変更としては、
 FN_ATTR_OP_ADD
 FN_ATTR_OP_ADD_EXCLUSIVE
 FN_ATTR_OP_REMOVE
 FN_ATTR_OP_ADD_VALUES
 FN_ATTR_OP_REMOVE_VALUES
 が有効である。この関数は属性値が文字列であることを前提とする。
 関数の使用例として、以下に "James Smith" という値を持つ識別子 "realname"
 の属性を、ユーザーオブジェクト "user/jsmith" に追加する。
  fns_attr_modify(
  "user/jsmith",
  "realname",
  "James Smith",
  FN_ATTR_OP_ADD);
 次の関数は識別子 "location" の属性をプリンタオブジェクト
 "thisorgunit/service/printer/color" から削除する。
  fns_attr_modify(
  "thisorgunit/service/printer/color",
  "location",
  NULL,
  FN_ATTR_OP_REMOVE);
*/
static const char *attr_id_syntax = "fn_attr_syntax_ascii";
void fns_attr_modify(const char *name,
 const char *attr_id,
 const char *attr_value,
 unsigned int operation)
{
 FN_composite_name_t *name_comp;
 FN_identifier_t identifier, syntax;
 FN_attrvalue_t *values;
 FN_attribute_t *attribute;
 FN_status_t *status;
 FN_ctx_t *initial_context;
 name_comp = fn_composite_name_from_str((unsigned char *) name);
 status = fn_status_create();
 /* 初期コンテキストの獲得 */
 initial_context = fn_ctx_handle_from_initial(0, status);
 if (!fn_status_is_success(status)) {
  fprintf(stderr, "Unable to obtain intial context\n");
  return;
 }
 /* 追加する属性の作成 */
 /* 最初に識別子 */
 identifier.format = FN_ID_STRING;
 identifier.length = strlen(attr_id);
 identifier.contents = (void *) strdup(attr_id);
 /* 次に構文 */
 syntax.format = FN_ID_STRING;
 syntax.length = strlen(attr_id_syntax);
 syntax.contents = (void *) strdup(attr_id_syntax);
 /* 次に属性値 */
 if (attr_value) {
  values = (FN_attrvalue_t *) malloc(sizeof(FN_attrvalue_t));
  values->length = strlen(attr_value);
  values->contents = (void *) strdup(attr_value);
 } else
  values = NULL;
 /* 次に属性の作成 */
 attribute = fn_attribute_create(&identifier, &syntax);
 /*次に属性値の追加 */
 if (values)
 fn_attribute_add(attribute, values, 0);
 /* XFN オペレーションの実行 */
 fn_attr_modify(initial_context, name_comp, operation, attribute, 0,
status);
 if (!fn_status_is_success(status))
  fprintf(stderr, "Unable to perform attribute operation\n");
 fn_ctx_destroy(initial_context);
 fn_status_destroy(status);
 fn_composite_name_destroy(name_comp);
 fn_attibute_destroy(attribute);
 free(identifier.contents); 	free(syntax.contents);
 if (values) {
  free(values->contents);
  free(values);
 ]
]

コンテキスト内のオブジェクトの検索

次の例は、特定の属性識別子と値によって、コンテキスト内のオブジェクトを検索する方法を示しています。


#include <stdio.h>
#include <xfn/xfn.h>
#include <string.h>
#include <stdlib.h>
/*
 このルーチンは、指定された属性識別子と値を持つコンテキスト内の
 オブジェクトを検索します。
*/
typedef struct fns_search_results {
 char *name;
 struct fns_search_results *next;
} fns_search_results;
static const char *attr_id_syntax = "fn_attr_syntax_ascii";
fns_search_results *
fns_attr_search(const char *name,
 const char *attr_id,
 const char *attr_value)
{
 FN_status_t *status;
 FN_ctx_t *initial_context;
 FN_composite_name_t *context_name;
 FN_searchlist_t *search_list;
 FN_string_t *search_name;
 FN_attribute_t *attribute;
 FN_attrset_t *attrset;
 FN_identifier_t identifier, syntax;
 FN_attrvalue_t *values;
 unsigned stat;
 fns_search_results *head = 0, *current, *prev;
 int no_names = 0;
 context_name = fn_composite_name_from_str((unsigned char *) name);
 status = fn_status_create();
 initial_context = fn_ctx_handle_from_initial(0, status);
 if (!fn_status_is_success(status)) {
  fprintf(stderr, "Unable to obtain intial context\n");
  return (0);
 }
 /* 検索する属性を持つ attrset のコンストラクト */
 /* 最初に識別子 */
 identifier.format = FN_ID_STRING;
 identifier.length = strlen(attr_id);
 identifier.contents = (void *) strdup(attr_id);
 /* 次に構文 */
 syntax.format = FN_ID_STRING;
 syntax.length = strlen(attr_id_syntax);
 syntax.contents = (void *) strdup(attr_id_syntax);
 /* 次に属性値 */
 values = (FN_attrvalue_t *) malloc(sizeof(FN_attrvalue_t));
 values->length = strlen(attr_value);
 values->contents = (void *) strdup(attr_value);
 /* 次に属性の作成 */
 attribute = fn_attribute_create(&identifier, &syntax);
 /* 次に属性値の作成 */
 fn_attribute_add(attribute, values, 0);
 /* 次に attrset の作成と属性の追加 */
 attrset = fn_attrset_create();
 fn_attrset_add(attrset, attribute, 0);
 search_list = prelim_fn_attr_search(initial_context,
  context_name, attrset, 0, 0, status);
 if (!fn_status_is_success(status)) {
  fprintf(stderr, "Unable to list names\n");
  return (0);
 }
 while (search_name = prelim_fn_searchlist_next(search_list,
  0, 0, status)) {
  no_names++;
  current = (fns_search_results *)
   malloc(sizeof(fns_search_results));
  current->name = (char *)
   malloc(strlen((char *) fn_string_str(search_name, &stat)) + 1);
  strcpy(current->name, (char *) fn_string_str(search_name, &stat));
  current->next = 0;
  if (head) {
   prev->next = current;
   prev = current;
  } else {
   head = current;
   prev = current;
  }
  fn_string_destroy(search_name);
 }
 fn_searchlist_destroy(search_list);
 fn_status_destroy(status);
 fn_ctx_destroy(initial_context);
 fn_attrset_destroy(attrset);
 fn_attribute_destroy(attribute);
 free(identifier.contents);
 free(syntax.contents);
 free(values->contents);
 free(values);
  return (head);
 }

FNS の設定 - 概要

Solaris オペレーティング環境ソフトウェアのインストール後に次の作業を実行して、FNS を設定する必要があります。

  1. サーバーが FNS を取り扱えることを確認します。リソース条件の決定 を参照してください。

  2. FNS 用の名前空間を準備します。FNS 用の名前空間の準備 を参照してください。

  3. FNS 名前空間のコンテキストを設定します。次の 2 つの方法があります。

    1. 1 つのプロセスで、すべてのコンテキストをグローバルに作成します。グローバルな FNS の名前空間コンテキストの作成 を参照してください。

    2. FNS コンテキストを個別に作成します。

  4. FNS の複製サーバーを設定します。FNS サービスの複製 を参照してください。

組織の大きさによっては、FNS の設定が完了するまでに数時間と、名前空間の準備にもある程度の時間が必要になります。

リソース条件の決定

インストールの手順に進む前に、FNS をサポートしているサーバーに十分なメモリーとディスク領域があることを最初に確認する必要があります。企業レベルのネームサービス (NIS+、NIS、ファイル) で必要な領域の他に FNS 用の領域が必要です。

一般的に確実な方法として、ユーザーとホストごとに、約 17K バイトのディスク領域とスワップ領域が必要になります。このディスク領域が配置される場所と、その計算方法は、使用している企業レベルのネームサービスによって異なります。

たとえば、1,200 のユーザーとホストを持つ NIS+ ドメインで FNS 環境をサポートするには、以下が必要になります。

FNS 用の名前空間の準備

この節では、fncreate を実行して FNS コンテキストを設定する前の準備について説明します。準備は該当する企業レベルのネームサービスによって異なります。以下を参照してください。

FNS 用の名前空間の準備 — 作業マップ

表 25–10 FNS 用の名前空間の準備

作業 

説明 

参照先 

FNS 用の名前空間の準備 

NIS マップへのファイルの変換 

『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』の「NIS マップに関する作業」

FNS 用の名前空間の準備 

NIS サービスの準備 

FNS 用の NIS サービスの準備

FNS 用の名前空間の準備 

ファイルベースのネーミングの準備 

FNS 用のファイルを使用したネームサービスの準備

FNS 用の NIS+ サービスの準備

FNS 名前空間を設定する前に、以下の作業を行います。

  1. NIS+ ドメインが正確に設定されていることを確認します。

    NIS+ ドメインとそのサブドメインは、FNS を構成する前に設定されていなければなりません。つまり hosts と passwd など NIS+ の標準のテーブルが既に存在し、生成されている必要があります。

  2. ドメインの hosts.org_dir と passwd.org_dir のテーブルが、すべてのホスト名とユーザー名で生成されていることを確認します。

    niscat と nismatch のコマンドを使用して、これらテーブルの内容を確認できます。

  3. NIS_GROUP 環境変数を、FNS オブジェクトを管理するグループの名前に設定します。

    この変数を最初に設定しないと、fncreate コマンドで FNS 設定を完了できません。fncreate コマンドがユーザーとホストのコンテキストを作成するとき、それらはコマンドを実行したシステム管理者ではなく、そのホストとユーザーの所有となります。NIS_GROUP の設定によって、グループのメンバーになっているシステム管理者は、オブジェクトを所有していなくてもコンテキストを修正できます。

    C シェルの場合、次のように NIS_GROUP に fns_admins.doc.com を設定します。


    rootmaster# setenv NIS_GROUP fns_admins.doc.com

  4. 必要に応じて、NIS+ マスターサーバー以外のマシンで FNS を実行するように指定します。

    FNS が使用する、すべての NIS+ オブジェクトは、NIS+ ドメインの ctx_dir ディレクトリの下に保管されます。5,000 以上のユーザーやホストを有する大規模なドメインでは、FNS が使用する ctx_dir が、groups_dir のような標準の NIS+ ディレクトリをサポートするサーバーとは別のサーバーによってサポートされるようにしてください。これは必須ではありませんが、推奨されています。別個のサーバーを使用することで、1 つのサーバーに過剰な負荷がかからなくなります。またこれによって、FNS による NIS+ の使用の管理と NIS+ 自体の管理を分離できます。

    ドメインに対する NIS+ マスターサーバーではないマシンによって FNS が提供されるように指定するには、ドメインに対する FNS ホストとして機能するマシン上に ctx_dir ディレクトリオブジェクトを手作業で作成する必要があります。この手順を省略すると、FNS はドメインの NIS+ ルートマスターサーバーにインストールされます。

    FNS のマスターサーバーになるマシンを指定するには次のようにします。

    1. NIS+ ドメインに ctx_dir ディレクトリを作成します。

      たとえば、doc.com ドメイン内で fns_server と名前のついたマシン上に ctx_dir ディレクトリを作成するには、ドメインのマスターサーバーで次のコマンドを実行します。ドメイン名の最後にドットが付いていることに注意してください。


      nismaster# nismkdir -m fns_server ctx_dir.doc.com.

      nismkdir を使用した NIS+ ディレクトリの作成方法の詳細については、nismkdir コマンド を参照してください。

      注 –

      「サブドメイン」用の FNS の ctx_dir を作成する場合、ctx_dir を提供する FNS サーバーとして指定するマシンはサブドメイン内に存在する必要があります、親ドメイン内のマシンは指定できません。これとは対照的に、サブドメインの NIS+ のマスターサーバーは常に、それが機能する 1 つ上のドメインに存在します。つまり、NIS+ のサブドメインに対して FNS を構成しているときに、NIS+ と FNS の両方で同じサーバーを使用する場合には、そのサーバーはサブドメインの上のドメインに存在します。しかし、NIS+ と FNS で異なるサーバーを使用する場合には、NIS+ のマスターサーバーはその上のドメインに存在し、FNS サーバーはそれが機能するサブドメインに存在します。

    2. nisls コマンドを使用して、ctx_dir ディレクトリが作成されたことを検証します。 


      rootmaster # nisls doc.com.ctx_dir

    3. nisping を実行して、ディレクトリでチェックポイントを実行します。 


      # /usr/lib/nis/nisping -C ctx_dir.doc.com.

FNS 用の NIS サービスの準備

FNS 名前空間を設定する前に、以下の作業を行います。

    hosts.byname、user.byname、printer.conf.byname のマップが完全、正確、最新であることを確認します。

注 –

他の任意の NIS マップに対して異なるマスターサーバーを割り当てるのと同じ手順で、FNS マップに異なるマスターサーバーを割り当てることができます。

FNS 用のファイルを使用したネームサービスの準備

「ファイルを使用した」ネームサービスとは、NIS+ または NIS ではなく、/etc ファイルからデータを得るネームサービスのことです。

/var/fn ディレクトリをマシンごとにインストールする場合には、一般的に次の手順をマシンごとに実行する必要があります。1 つのマシンから /var/fn ディレクトリのマウントとエクスポートをする場合には、次の手順を /var/fn をエクスポートするマシンで実行する必要があります。

    /etc/hosts と /etc/passwd のファイルが完全で、すべてのユーザー名とホスト名を含むことを確認してください。

グローバルな FNS の名前空間コンテキストの作成

この節では、企業または NIS+ ドメインに対する名前空間をグローバルに作成する方法を説明します。

FNS の名前空間は、fncreate コマンドを使用して作成されます。


# fncreate -t org org//

あるいは、次のコマンドを使用します。


# fncreate -t org org/domain/

この場合 domain 名は、NIS+ドメイン名またはサブドメイン名です。

fncreate コマンドは、指定された編成と、そのすべてのサブコンテキスト用のデフォルトのコンテキストを作成します。これには編成内のユーザーとホストに対するコンテキストとサブコンテキストが含まれます。

グローバルな FNS の名前空間コンテキストの作成 — 作業マップ

表 25–11 グローバルな FNS の名前空間コンテキストの作成

作業 

説明 

参照先 

グローバルな FNS の名前空間コンテキストの作成 

NIS+ の下での FNS の名前空間コンテキストの作成 

NIS+ の下での名前空間コンテキストの作成

グローバルな FNS の名前空間コンテキストの作成 

NIS の下での FNS の名前空間コンテキストの作成 

NIS の下での名前空間コンテキストの作成

グローバルな FNS の名前空間コンテキストの作成 

ファイルの下での FNS の名前空間の作成 

ローカルファイルの下での名前空間コンテキストの作成

NIS+ の下での名前空間コンテキストの作成

企業レベルの主なネームサービスが NIS+ であるときは、NIS+ ドメインまたはサブドメインごとに名前空間のコンテキストを個別に作成する必要があります。

たとえば、そのドメイン用の NIS+ マスターサーバーである submaster マシン上の manf.doc.com サブドメイン用にコンテキストを作成するには、次のようにします。

    サブドメインのマスターで、fncreate を実行します。 


submaster# fncreate -t org org/manf.doc.com./

これで、NIS+ manf.doc.com.サブドメイン用の編成コンテキスト、サブドメインの passwd.org_dir テーブルのすべてのユーザーとサブドメインの hosts.org_dir テーブルのすべてのホストに対するコンテキストとサブコンテキストが作成されます。

NIS+ と FNS のサーバーに異なるマシンを使用するには、FNS サーバーとして使用するマシン上で前述のコマンドを実行します。NIS+ ではないサーバーを FNS サーバーとして設定する方法についての説明は、前記の「FNS 用の NIS+ サービスの準備」の手順 4 を参照してください。

    nisping コマンドを使用して ctx_dir ディレクトリでチェックポイントを実行します。 


    # /usr/lib/nis/nisping -C ctx_dir.manf.doc.com.

    注 –

    数千のユーザーやホストを有する大規模な組織では、最初の fncreate 操作に数時間、それ以降のチェックポイントにも数時間かかる場合があります。

NIS の下での名前空間コンテキストの作成

企業レベルの主なネームサービスが NIS であるときは、企業に対して 1 つのドメインだけが存在します。その企業全体のドメインに対して名前空間コンテキストが作成されます。

たとえば、NIS マスターサーバーでもある fns_master というマシンで doc.com ドメイン用にコンテキストを作成するには、次のようにします。

    ドメインマスターで fncreate を次のように実行します。 


    fns_master# fncreate -t org org//

    これで NIS ドメイン doc.com 用の編成コンテキストと、NIS サーバーの passwd マップのすべてのユーザーとサーバーの hosts マップの、すべてのホストに対するコンテキストと関連のサブコンテキストが作成されます。

    注 –

    コンテキストマップを作成したら、他の任意の NIS マップに異なるマスターを割り当てるのと同じ手順で、同じマシンをマスターサーバーに割り当てることができます。FNS マップはすべて、.ctx または .attr のいずれかで終わる名前を持ちます。

ローカルファイルの下での名前空間コンテキストの作成

企業レベルの主なネームサービスがファイルであるときは、コンテキストはシステムに対して作成されます。

たとえば、システム用のコンテキストを作成するには次のようにします。

    /var/fn ディレクトリのあるマシンで、fncreate を次のように実行します。 


    server1# fncreate -t org org//

これで、マシン内の /etc/passwd ファイルのすべてのユーザーとマシン内の /etc/hosts ファイルのすべてのホスト用にシステム、コンテキスト、関連のサブコンテキストに対する編成コンテキストが作成されます。

FNS サービスの複製

FNS のネームサービスの性能と信頼性が重要な大規模で重要性の高いネットワークでは、FNS サービスを複製してください。

FNS サービスの複製 — 作業マップ

表 25–12 FNS サービスの複製

作業 

説明 

参照先 

FNS サービスの複製 

NIS+ の下での FNS サービスの複製 

NIS+ の下での FNS の複製

FNS サービスの複製 

NIS の下での FNS サービスの複製 

NIS の下での FNS の複製

FNS サービスの複製 

ファイルの下での FNS の複製 

ファイルを使用したネームサービスの下での FNS の複製

NIS+ の下での FNS の複製

マスターサーバーで FNS 名前空間が設定されたら、その他の複製サーバーを各ドメインに追加して、ドメインの ctx_dir を提供するサーバーにします。複製サーバーによって、サーバーの可用性と性能を拡張できます。

  1. FNS マスターサーバー上で nismkdir コマンドを実行して、ctx_dir ディレクトリ用の複製サーバーを追加します。

    たとえば、マシン fnsrserver を doc.com. ドメインの FNS の複製サーバーにします。


    # nismkdir -s fnsrserver ctx_dir.doc.com.

  2. nisping コマンドを使用して ctx_dir ディレクトリでチェックポイントを実行します。 


    # /usr/lib/nis/nisping -C ctx_dir.doc.com.

    FNS の複製では一定の間隔でチェックポイントを実行してください。間隔は、数日に 1 回程度をお勧めします。選択する間隔は、FNS 名前空間への変更頻度によって異なります。

NIS の下での FNS の複製

FNS 名前空間がドメインのマスターサーバーで設定された後に、スレーブサーバーを追加して、サーバーの可用性と機能を拡張できます。

  1. root として、スレーブサーバーの /etc/hosts ファイルを編集して、他のすべての NIS サーバーの名前と IP アドレスを追加します。

  2. スレーブサーバー上の /var/yp にディレクトリを変更します。

  3. 次のように入力して、スレーブサーバーにするマシンをクライアントとして初期化します。


    # /usr/sbin/ypinit -c

    ypinit コマンドによって、NIS サーバーのリストを求めるプロンプトが表示されます。作業中のローカルスレーブの名前を最初に入力してからマスターサーバーを入力し、その後にドメイン内の他の NIS スレーブサーバーをネットワーク的に近いものから遠いものの順番で入力します。

    注 –

    まず、新しいスレーブサーバーを NIS クライアントとして構成して、最初にマスターサーバーから NIS マップを入手できるようにします。詳細については、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』の「NIS サービスの設定と構成」を参照してください。

  4. ypbind が実行中かどうかを判断するには、次のように入力します。 


    # ps -ef | grep ypbind

    リストが表示されたら、ypbind は実行中です。

  5. ypbind が実行中なら、次のように入力して停止します。 


    # /usr/lib/netsvc/yp/ypstop

  6. 次のように入力して、ypbind を再開します。


    # /usr/lib/netsvc/yp/ypstart

  7. 次のように入力して、このマシンをスレーブとして初期化します。


    # /usr/sbin/ypinit -s master

    master は、既存の NIS マスターサーバーのマシン名です。

  8. スレーブサーバーの yp プロセスを停止します。


    # /usr/lib/netsvc/yp/ypstop

  9. yp サービスを再起動します。


    # /usr/lib/netsvc/yp/ypstart

    これとは別に、スレーブサーバーをリブートしてデーモンを自動的に開始することもできます。

ファイルを使用したネームサービスの下での FNS の複製

主なネームサービスがファイルになっているときはサーバーの複製はありません。

FNS の管理、問題解決、エラーメッセージ

FNS エラーメッセージ

FNS エラーメッセージは、FN_status_t オブジェクトにステータスコードとしてカプセル化されます。対応するステータスコードについては、FN_status_t のマニュアルページを参照してください。

エラーが発生すると、FNS コマンドは、操作が失敗した名前の残りの部分を表示します。表示されなかった名前の部分の処理は成功しています。

たとえば、ユーザーが、org//service/trading/bb に対するコンテキストの作成を試みたとします。名前 org//service/ の解決には成功しましたが、trading は org//service/ によって名前を付けられたコンテキストで見つかりませんでした。このため trading/bb は、操作が失敗したときに残る名前の一部として表示されます。


Error in creating 'org//service/trading/bb': Name Not Found: 'trading/bb'

別の例では、ユーザーがコンテキスト org//service/dictionary/english の削除を試みましたが、名前を付けられたコンテキストが空であったので、操作を実行できませんでした。引用符 ('') の組み合わせは、与えられた完全な名前を FNS は解決できましたが、要求されたとおりに操作を完了できなかったことを示します。


Error in destroying 'org//service/dictionary/english': Context Not Empty: ''

XFN リファレンスに準拠した DNS 文書レコードの書式

Solaris の環境は、DNS 内で広域ネーミングシステムをフェデレートさせるための XFN 規格に準拠しています。DNS でネーミングシステムをフェデレートさせるには、DNS TXT リソースレコードに情報を入力する必要があります。この情報は、従属ネーミングシステム用に XFN リファレンスを作成するために使用されます。この章では、これらの DNS TXT レコードの書式について説明します。

XFN リファレンスのリファレンスタイプは、XFNREF というタグで始まる TXT レコードから作成します。書式は以下の通りです。 


TXT "XFNREF rformat reftype"

TXT の後に続く文字列の中にスペースが存在する場合、そのスペースを削除するか、文字列全体を引用符 (“ ”) で囲む必要があります。XFNREF、rformat、reftype という 3 つのフィールドは、スペース (スペースとタブ) で区切ります。rformat は、リファレンスタイプの識別子の書式を指定します。種類は次のとおりです。

reftype は、リファレンスタイプの識別子の内容を指定します。

XFNREF レコードが存在しない場合、リファレンスタイプはデフォルト設定により FN_ID_STRING を持つ XFN_SERVICE 識別子になります。2 つ以上の XFNREF TXT レコードが存在する場合、どのレコードが処理されるかは不定です。以下の TXT レコードはデフォルト設定の XFNREF と同じ働きをします。 


TXT "XFNREF STRING XFN_SERVICE"

XFN リファレンスのアドレス情報は、XFN 文字列を接頭語にしたタグを持つ TXT レコードを使用して作成します。1 つのリファレンスに複数のアドレスを指定することもできます。同じタグを持つレコードはグループにまとめられ、グループごとにハンドラに渡されます。各ハンドラは渡された TXT レコードからアドレス (複数あるいは、ない場合もある) を作成し、リファレンスに付加します。XFNREF タグの場合は特別で、リファレンスタイプを作成するためにだけ使用されるため、アドレス作成の過程からは除外されます。

TXT レコードのアドレスを指定する構文は次のとおりです。


XFNaddress_type_tag   address_specific_data

XFN_address_type_tag と address_specific_data という 2 つのフィールドは、スペース (スペースとタブ) で区切ります。address_type_tag は、address_specific_data に使用するハンドラを指定します。

TXT レコードには 1 レコードにつき 2 K バイトという文字の制限があります。特定のアドレスのデータが長すぎて 1 つの TXT レコードに格納できない場合は、以下のように複数の TXT レコードを使用できます。


TXT "XFNaddress_type_tag address_specific_data1"
TXT "XFNaddress_type_tag address_specific_data2"

特定のタグのハンドラが呼び出され、両方のデータが渡されます。ハンドラはこれら 2 行を解釈する順番を決定します。

TXT レコードの順番はあまり重要ではありません。異なるタグを持つ行がある場合、特定のタグのハンドラが呼び出される前に、同じタグを持つ行はグループにまとめられます。以下の例では、tag1 のハンドラは 2 つの文書行で呼び出され、tag2 のハンドラは 3 つの文書行で呼出されます。


TXT "XFNtag1 address_specific_data1"
TXT "XFNtag2 address_specific_data2"
TXT "XFNtag1 address_specific_data3"
TXT "XFNtag2 address_specific_data4"
TXT "XFNtag2 address_specific_data5"

XFN リファレンスに使用できる TXT レコードの例を以下に示します。

「例 1」


TXT "XFNREF STRING XFN_SERVICE"
TXT "XFNNISPLUS doc.com. nismaster 129.144.40.23"

「例 2」


TXT "XFNREF OID 1.3.22.1.6.1.3"
TXT "XFNDCE (1 fd33328c4-2a4b-11ca-af85-09002b1c89bb...)"

以下は、従属ネーミングシステムが割り当てられた DNS テーブルの例です。


$ORIGIN test.doc.com
@      IN SOA foo root.eng.doc.com          (
                    100    ;; Serial
                    3600   ;; Refresh
                    3600   ;; Retry
                    3600   ;; Expire
                    3600   ;; Minimum
            )
         NS    nshost
         TXT   "XFNREF STRING XFN_SERVICE"
         TXT   "XFNNISPLUS doc.com. nismaster 129.144.40.23"
nshost IN  A 129.144.40.21

XFN リファレンス用 X.500 属性の構文

この節では、XFN リファレンス用の X.500 属性の使用についての補足情報を述べます。XFN リファレンスを X.500 における属性として保存できるようにするためには、ディレクトリスキーマを、この章で定義されているオブジェクトクラスと属性をサポートするように変更する必要があります。

オブジェクトクラス

XFN リファレンスをサポートするために、XFN と XFN 補助の 2 つの新しいオブジェクトクラスが導入されています。XFN オブジェクトクラスは FNS に適切ではありません。これは、米国 Sun Microsystems, Inc. の X.500 ディレクトリ製品が、新しく導入された複合 ASN.1 構文をサポートしていないためです。その代わりに、FNS では XFN 補助オブジェクトクラスを使用します。

ASN.1 では、次のような 2 つの新しいオブジェクトクラスが定義されています。


xFN OBJECT-CLASS ::= {
         SUBCLASS OF         { top }
         KIND              auxiliary
         MAY CONTAIN       { objectReferenceId |
                             objectReference |
                             nNSReferenceId |
                             nNSReference }
          ID                 id-oc-xFN
     }
     id-oc-xFN OBJECT IDENTIFIER ::= {
        iso(1) member-body(2) ansi(840) sun(113536)
        ds-oc-xFN(24)
     }
xFNSupplement OBJECT-CLASS ::= {
         SUBCLASS OF           { top }
         KIND                  auxiliary
         MAY CONTAIN           { objectReferenceString |
                               nNSReferenceString }
            ID                 id-oc-xFNSupplement
      }
      id-oc-xFNSupplement OBJECT IDENTIFIER ::= {
          iso(1) member-body(2) ansi(840) sun(113536)
          ds-oc-xFNSupplement(25)
      }

XFN 補助オブジェクトクラスは、補助オブジェクトクラスとして定義されているため、X.500 のオブジェクトクラスすべてに引き継がれる可能性があります。XFN 補助オブジェクトクラスは、以下の 2 つの任意属性によって定義されます。

ASN.1 では、この 2 つの属性を以下のように定義しています。 


        objectReferenceString ATTRIBUTE ::= {
            WITH SYNTAX             OCTET STRING
            EQUALITY MATCHING RULE  octetStringMatch
            SINGLE VALUE            TRUE
            ID                      { id-at-objectReferenceString }
        }
        id-at-objectReferenceString OBJECT IDENTIFIER ::= {
            iso(1) member-body(2) ansi(840) sun(113536)
            ds-at-objectReferenceString(30)
        }
        nNSReferenceString ATTRIBUTE ::= {
            WITH SYNTAX             OCTET STRING
            EQUALITY MATCHING RULE  octetStringMatch
            SINGLE VALUE            TRUE
            ID                      { id-at-nNSReferenceString }
        }
        id-at-nNSReferenceString OBJECT IDENTIFIER ::= {
            iso(1) member-body(2) ansi(840) sun(113536)
            ds-at-nNSReferenceString(31)
        }

objectReferenceString と nNSReferenceString は、共に XFN リファレンスを文字列形式で保存します。それぞれのオクテット列構文は、さらに以下の BNF 定義に準拠するように制約を加えられます。


     <ref>          ::= <id> '$' <ref-addr-set>
     <ref-addr-set> ::= <ref-addr> | <ref-addr> '$' <ref-addr-set>
     <ref-addr>     ::= <id> '$' <addr-set>
     <addr>         ::= <hex-string>
     <id>           ::= 'id'   '$' <string> |
                        'uuid' '$' <uuid-string> |
                        'oid'  '$' <oid-string>
     <string>       ::= <char> | <char> <string>
     <char>         ::= <PCS> | '\' <PCS>
     <PCS>          ::= // Portable Character Set:
                        // !"#$%&'()*+,-./0123456789:;<=>?
                        // @ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_
                        // `abcdefghijklmnopqrstuvwxyz{|}~
     <uuid-string>  ::= <uuid-char>  | <uuid-char> <uuid-string>
     <uuid-char>    ::= <hex-digit> | '-'
     <oid-string>   ::= <oid-char>  | <oid-char> <oid-string>
     <oid-char>     ::= <digit> | '.'
     <hex-string>   ::= <hex-octet> | <hex-octet> <hex-string>
     <hex-octet>    ::= <hex-digit> <hex-digit>
     <hex-digit>    ::= <digit> |
                        'a' | 'b' | 'c' | 'd' | 'e' | 'f' |
                        'A' | 'B' | 'C' | 'D' | 'E' | 'F'
     <digit>        ::= '0' | '1' | '2' | '3' | '4' | '5' |
                        '6' | '7' | '8' | '9'

以下は、文字列形式の XFN リファレンスの例です。


id$onc_fn_enterprise$id$onc_fn_nisplus_root$0000000f77697a2e636fd2e2062696762696700

この例では、onc_fn_enterprise というタイプの XFN リファレンスを使用しています。この中には、onc_fn_nisplus_root というアドレスタイプと 1 つのアドレス値があります。アドレス値は XDR によって符号化された文字列で、ドメイン名、doc.com の後にホスト名 cygnus が続く形で構成されています。

XFN リファレンスを X.500 エントリに追加するには、次の例のように fnattr という FNS コマンドを使用します。 


# fnattr -a .../c=us/o=doc object-class top organization xfn-supplement

この例では、c=us/o=doc という新しいエントリを作成し、top、 organization、XFN-supplement という値のオブジェクトクラス属性を追加しています。

fnbind という FNS コマンドは、NIS+ リファレンスを命名されたエントリに割り当て、X.500 を NIS+ 名前空間のルートにリンクします。fnbind の名前因数内の文字の後にスラッシュ (/) が使用されていることに注意してください。


# fnbind -r .../c=us/o=doc/ onc_fn_enterprise onc_fn_nisplus_root "doc.com. cygnus"

FNS コンテキストを個別に作成する

FNS コンテキストは、fncreate コマンドを使用して作成します。この節では、組織全体の FNS コンテキストではなく、FNS コンテキストを個別に 作成する方法について説明します。fncreate コマンドを使用して、特定のタイプのコンテキストを作成し、指定した複合名にそのコンテキストを割り当てます。また、コンテキストのサブコンテキストを作成することもできます。

fncreate コマンドの構文は次のとおりです。 


fncreate -t context_type [-f input_file] [-o][-r reference_type][-s][-v] [-D] composite_name
表 25–13 fncreate コマンドオプション

オプション 

説明 

-t context

作成するコンテキストのタイプを指定する。context には、org、hostname、username、host、user、service、site、 nsid、generic、fs のうちいずれかを使用する

-f

input_file に指定された個々のホストまたはユーザーのコンテキストを作成する。このオプションは、-t username オプションまたは -t hostname オプションと併用される場合にだけ有効で、対応する NIS+ passwd テーブル (または hosts テーブル) 中のユーザー (またはホスト) のサブセットのコンテキストを個々に作成する場合に使用できる

-o

指定されたコンテキストだけを作成する。-o オプションを指定しないと、サブコンテキストは FNS ポリシーに基づいて作成される

-r

作成される汎用コンテキストの reference_type を指定する。これは -t generic オプションと併用される場合にだけ有効

-s

すでに使用されている複合名で、新しいコンテキストを作成する。このオプションを使用しなければ、すでに割り当てられている名前で新しいコンテキストを作成できない 

-D

コンテキストが作成されるたびに、コンテキストに関連付けられた NIS+ オブジェクトの情報を表示する。このオプションはデバッグに役立つ 

-v

コンテキスト作成時に、作成に関する情報を表示する 

注 –

組織コンテキスト作成時に -o オプションを指定した場合、host、user、 service のコンテキストは作成されてもサブコンテキストは生成されません。

名前空間識別子に割り当てられるコンテキストを作成する場合、下線のない名前 (user など) はコンテキストの作成に使用され、下線の付いた名前 (_user など) は新しく作成されたコンテキストのリファレンスに割り当てられます。この点は、コマンド行で指定された名前が下線のついてものであるか否かに関わらず常に同じです。

たとえば、以下のコマンドでは、


fncreate -t username org/sales/_user

org/sales/user のコンテキストを作成し、org/sales/_user の割り当てを org/sales/user のコンテキストに追加しています。

組織コンテキストを作成する

組織コンテキストを作成するには、コンテキストタイプに org を指定します。複合名には、使用しているネームサービスによって以下のいずれかにする必要があります。

NIS+ の場合の組織コンテキストの例

NIS+ のルートドメインが doc.com で、sales.doc.com というサブドメインがあるとします。sales というサブドメインに対応する sales という組織コンテキストを作成するには、以下のコマンドを入力します。 


fncreate -t org org/sales/

新しいコンテキストの作成時には、ドメインである sales.doc.com の下に ctx_dir というディレクトリが作成されます。すでに ctx_dir が存在する場合は作成されません。

上記の例では -t オプションだけを使用し、-o オプションは使用しません。これによって複合名 org/sales/ の組織コンテキストが作成されると同時に、サブコンテキストとして hostname、username、service が作成されます。また host コンテキストと user コンテキスト、ホストとユーザーの service サブコンテキストも作成されます。実際には以下のコマンドが実行されます。


fncreate -t hostname org/sales/host/
fncreate -t username org/sales/user/
fncreate -t service org/sales/service/

代わりに fncreate -o -t org を使用すると、org コンテキストだけが作成されます。hostname、username、service のコンテキストは作成されますが、host コンテキストと user コンテキストの生成はされません。

org コンテキストの所有者となるのは、fncreate コマンドを実行した管理者です。この点は、hostname、username、service といったサブコンテキストについても同様です。ただし、host コンテキスト、user コンテキストとそのサブコンテキストの所有者となるのは、コンテキストの作成対象となったホストおよびユーザーです。管理者が引き続き host コンテキストや user コンテキストを処理するには、fncreate を実行する時に NIS_GROUP 環境変数を適宜設定する必要があります。たとえば、C シェルの場合、NIS_GROUP を以下のように fns_admins.doc.com に設定します。 


rootmaster# setenv NIS_GROUP fns_admins.doc.com

すべてのホストのコンテキスト

fncreate で hostname をコンテキストのタイプとして指定すると hostname コンテキストが作成されます。hostname コンテキストでは、host コンテキストの作成、割り当てができます。この場合、-o オプションを指定しなければ、host コンテキスト (およびそのサブコンテキスト) も NIS+ の host.org_dir テーブル中のホストごとに作成されます。-o オプションを指定した場合は、コンテキストだけが作成されます。

たとえば、以下のコマンドを実行すると、 


fncreate -t hostname org/sales/host/

hostname コンテキストが作成されます。


fncreate -t host org/sales/host/hname

hname とは、各マシンの hosts.org_dir テーブル中にある名前です。また org/sales/_host/ の、org/sales/host/ のリファレンスへの割り当ても行われます。

hostname コンテキストの所有者となるのは、fncreate コマンドを実行した管理者です。また host コンテキスト (およびそのサブコンテキスト) の所有者となるのは、コンテキストの作成対象となったホストです。つまり、個々のホストがそれぞれ自分のホストのコンテキスト (およびそのサブコンテキスト) を持つことになります。

-f オプションを使用すると、NIS+ の hosts.org_dir テーブル中のホストの、サブセットのコンテキストを作成できます。このオプションでは、input_file に指定されたホストのコンテキストが作成されます。

1 台のホストのコンテキスト

fncreate で host をコンテキストのタイプとして指定すると、ホストのコンテキストとサブコンテキストが作成されます。-o オプションを指定しなければ、コマンドによってホストの service コンテキストと fs の割り当てが自動的に作成されます。-o オプションを指定した場合は、host コンテキストだけが作成されます。

たとえば、以下のコマンドでは、 


# fncreate -t host org/sales/host/antares/

antares というホストのコンテキストが作成されます。実際には以下のコマンドが実行されます。


fncreate -t service org/sales/host/antares/service/
fncreate -t fs org/sales/host/antares/fs/

host コンテキスト (およびそのサブコンテキスト) の所有者となるのはホストです。上記の例では antares というホスト (NIS+ 主体名 antares.sales.doc.com) が以下のコンテキストの所有者となります。

ただしこの場合、ホストの属する hostname コンテキスト (上記の例では、org/sales/host/) が必要です。また NIS+ テーブル hosts.org_dir に、ホスト名を指定する必要があります。

ホストの別名

NIS+ の hosts.org_dir テーブルには、別名を持つホストが存在することもあります。これは、テーブル中では「正式名が同じで別名が異なる」ホストの集合として存在します。

FNS においては、たとえ複数の別名を持っていても、１つのホストが持つ host コンテキストは１つだけです。hostname コンテキスト中のホストの別名が割り当てられるのは、正式名と同じコンテキストのリファレンスです。

すべてのユーザーのコンテキスト

fncreate で username をコンテキストのタイプとして指定すると、username コンテキストが作成されます。username コンテキストでは、個々の user コンテキストの作成と割り当てが行われます。-o オプションを指定しないと、NIS+ テーブル passwd.org_dir に存在するユーザー名ごとに、user コンテキスト (およびそのサブコンテキスト) が作成されます。-o オプションを指定した場合は、username コンテキストだけが作成されます。

たとえば、以下のコマンドを実行すると、


# fncreate -t username org/sales/user/

username コンテキストが作成されます。


fncreate -t user org/sales/user/uname

実際には、passwd.org_dir テーブルに存在するユーザー uname ごとに、以下のコマンドが実行されます。また、org/sales/_user/ の org/sales/user/ への割り当ても行われます。

username コンテキストの所有者となるのは、fncreate コマンドを実行した管理者です。個々の user コンテキスト (およびそのサブコンテキスト) の所有者となるのは、コンテキストの作成対象となったユーザーです。ユーザーがそれぞれ独自の user コンテキスト (およびそのサブコンテキスト) を所有することになります。

-f オプションを使用すると、NIS+ テーブル passwd.org_dir に存在するユーザーのサブセットのコンテキストを作成できます。このオプションでは、input_file に指定されたホストのコンテキストが作成されます。

1 人のユーザーのコンテキスト

fncreate で user をコンテキストタイプとして指定すると、ユーザーの user コンテキスト (およびそのサブコンテキスト) が作成されます。-o オプションを指定しなければ、user コンテキストの下に service サブコンテキストと fs の割り当てが作成されます。-o オプションを指定した場合は、user コンテキストだけが作成されます。

たとえば、以下のコマンドでは、


# fncreate -t user org/sales/user/jjones/

jjones という名前のユーザーの user コンテキストが作成されます。実際には、以下のコマンドが実行されます。 


fncreate -t service org/sales/user/jjones/service/
fncreate -t fs org/sales/user/jjones/fs/

user コンテキスト (およびそのサブコンテキスト) の所有者となるのは、コンテキストの作成対象となったユーザーです。上記の場合、作成されたコンテキストの所有者となるのは、jjones というユーザー (NIS+ 主体名 jjones.sales.doc.com) です。

ただしこの場合、ユーザーの属する username コンテキスト (上記の org/sales/user) が必要です。また、指定されたユーザー名が NIS+ テーブル passwd.org_dir 中に存在している必要があります。

サービスのコンテキスト

fncreate でコンテキストタイプとして service を指定すると、service コンテキストが作成されます。service コンテキストでは、サービス名の割り当てが行えます。service コンテキスト中で割り当てられるリファレンスのタイプに制約はありません。ただし、service コンテキストを使用するアプリケーションによっては制約が設けられます。たとえば、デスクトップアプリケーションのグループなら、service コンテキスト中でバインドされるリファレンスのタイプは、カレンダ、カードファイル、ファックスサービス、プリンタなどになるでしょう。

たとえば、以下のコマンドでは、 


# fncreate -t service org/sales/service/

sales という組織の service コンテキストが作成されます。末尾の名前 (service) は名前空間識別子なので、fncreate では org/sales/_service/ の org/sales/service/ のリファレンスへの割り当ても行われます。このコマンドの実行後は、org/sales/service/calendar、org/sales/service/fax といった名前をこのサービスコンテキストで割り当てることができます。

service コンテキストでは、階層型の名前空間 (左から順に名前が並べられ、名前と名前の間はスラッシュで区切られる) がサポートされています。これによってアプリケーションは、名前空間をサービスごとに区切ることができます。デスクトップアプリケーションの場合、plotter コンテキストを作成した後に以下のコマンドを使用すれば、service コンテキストの下に plotter のグループを作成することができます。


# fncreate -t service org/sales/service/plotter

さらにこの下には、org/sales/service/plotter/speedy、 org/sales/service/plotter/color といった名前を割り当てることができます。

注 –

ただし、末尾の名前が名前空間識別子ではないので、service と _service のような割り当てが行われることはありません。

作成される service コンテキストの所有者となるのは、fncreate コマンドを実行した管理者です 。

プリンタコンテキスト

printer コンテキストは、複合名の service コンテキストの下に作成されます。

汎用コンテキスト

fncreate でコンテキストタイプに generic を使用すると、割り当て名のコンテキスト (アプリケーションによって使用される) が作成されます。

generic コンテキストは、リファレンスのタイプを変更できるという点以外は service コンテキストと同じです。generic コンテキストのリファレンスのタイプを指定するには、-r オプションを使用します。このオプションが省略された場合は、親コンテキストが generic タイプであればそれがそのまま使用され、別のタイプであればデフォルトとして指定されたものが使用されます。

service コンテキストと同様、generic コンテキストに割り当てられるリファレンスのタイプには制約がありません。ただし generic コンテキストを使用するアプリケーションによって制約が設けられる場合があります。

たとえば、以下のコマンドでは、 


# fncreate -t generic -r WIDC_comm org/sales/service/extcomm

sales という組織の service コンテキストの下に、リファレンスタイプ WIDC_comm の generic コンテキストが作成されます。この generic コンテキストでは、org/sales/service/extcomm/modem などの名前を割り当てることができます。

generic コンテキストでは、階層型の名前空間 (左から順に名前が並べられ、名前と名前の間はスラッシュで区切られる) がサポートされています。これによってアプリケーションは、名前空間をサービスごとに区切ることができます。上の例の場合、以下のコマンドを使用すれば、modem 用の generic サブコンテキストが作成できます。


# fncreate -t generic org/sales/service/extcomm/modem

さらにこの下には、org/sales/service/extcomm/modem/secure、org/sales/service/extcomm/modem/public といった名前を割り当てることができます。

作成された generic コンテキストの所有者となるのは、fncreate コマンドを実行した管理者です。

サイトコンテキスト

site コンテキストでは、サイト名の割り当てが行えます。

たとえば、以下のコマンドでは、 


# fncreate -t site org/sales/site/

サイトコンテキストを作成します。ここでは末尾の名前 (site) が名前空間識別子なので、fncreate によって org/sales/site/ のリファレンスに org/sales/_site/ が割り当てられます。

site コンテキストでは、階層型の名前空間 (左から順に名前が並べられ、名前と名前の間はドットで区切られる) がサポートされています。これによって、地理的な位置関係にもとづいてサイトを区分できます。

たとえば、以下のコマンドでは、


# fncreate -t site org/sales/alameda
# fncreate -t site org/sales/site/alameda.bldg-5

サイトコンテキスト alameda とサイトサブコンテキスト alameda.bldg-5 を作成します。

注 –

ただし末尾の名前が名前空間識別子ではないので、site と _site の場合のような割り当てが行われることはありません。

作成された site コンテキストの所有者となるのは、fncreate コマンドを実行した管理者です。

ファイルのコンテキスト

fncreate でコンテキストタイプに fs を指定すると、ユーザーまたはホストのファイルシステムコンテキスト (ファイルコンテキストとも呼ばれる) が作成されます。たとえば、以下のコマンドでは、 


# fncreate -t fs org/sales/user/petrova/fs/

ユーザー petrova の fs コンテキストを作成します。ここでは末尾の名前 (fs) が名前空間識別子なので、org/sales/user/petrova/fs/ のリファレンスに org/sales/user/petrova/_fs/ が割り当てられます。

ユーザーの fs コンテキストは、NIS+ テーブル passwd.org_dir に保存されているユーザーのホームディレクトリと同じものです。一方ホストの fs コンテキストは、ホストによってエクスポートされる NFS ファイルシステムをいくつか集めたものです。

組織およびサイトの file コンテキストを作成する場合、あるいはユーザーおよびホストのデフォルトでない file コンテキストを作成する場合は、fncreate_fs コマンドを使用します。詳細については、ファイルコンテキストの管理を参照してください。

作成された fs コンテキストの所有者となるのは、fncreate コマンドを実行した管理者です。

名前空間識別子のコンテキスト

nsid (namspace identifier = 名前空間識別子) タイプのコンテキストでは、名前空間識別子を割り当てることができます。

たとえば、以下のコマンドでは、 


# fncreate -t nsid org/sales/site/alameda.bldg-5/

サイト alameda.bldg-5 の nsid コンテキストを作成します。このコンテキストに対して、service/ などのサブコンテキストを作成できます。 この例に続いて、以下のコマンドを実行して、


# fncreate -t service org/sales/site/alameda.bldg-5/service/

alameda.bldg-5 の service コンテキストを作成できます。

作成された nsid コンテキストの所有者となるのは、fncreate コマンドを実行した管理者です。

エンタープライズレベルのコンテキストを管理する

FNS コンテキストを管理する (コンテキストの内容を確認する) ためのツールには様々な種類があります。以下の表は、そのツール (コマンド) の構文を示したものです。

割り当てに関する情報を表示する

fnlookup は、複合名の割り当てに関する情報を表示するのに使用します。 


fnlookup [-v][-L] composite_name
表 25–14 fnlookup コマンドのオプション

オプション 

説明 

-v

割り当てに関する詳細な情報を表示する 

-L

「XFN リンクの割り当て先となるのはどのリファレンスか」を表示する 

たとえば、以下の例では、ユーザー darwin の割り当てに関する情報が表示されます。


# fnlookup -v user/darwin/
Reference type: onc_fn_user
Address type: onc_fn_nisplus
 length: 52
 context type: user
 representation: normal
 version: 0
 internal name: fns_user_darwin.ctx_dir.sales.doc.com.

ここで user/Charles.Darwin が user/darwin にリンクされているとすると、下の例の最初のコマンドでは、user/Charles.Darwin の割り当て先 (XFNリンク) が表示されます。 2 番目のコマンドでは、XFNリンク user/jjones が調べられ、user/darwin の割り当て先 (user コンテキスト) が表示されます。


# fnlookup user/Charles.Darwin
Reference type: fn_link_ref
Address type: fn_link_addr
 Link name: user/darwin
# fnlookup -L user/Charles.Darwin
Reference type: onc_fn_user
Address type: onc_fn_nisplus
 context type: user

コンテキストの内容を表示する

fnlist は、コンテキストの内容を表示するのに使用されます。 


fnlist [-lv] [name]
表 25–15 fnlist コマンドのオプション

オプション 

説明 

-v

割り当てに関する詳細な情報を表示する 

-l

コンテキスト中で割り当てられている名前に関する情報を表示する 

以下の例では、user コンテキストに割り当てられている名前が表示されます。


# fnlist user/
Listing 'user/':
jjones
julio
chaim
James.Jones

名前を指定しないと、初期コンテキストの内容が表示されます。


# fnlist
Listing '':
_myorgunit
...
_myself
thishost
myself
_orgunit
_x500
_host
_thisens
myens
thisens
org
orgunit
_dns
thisuser
_thishost
myorgunit
_user
thisorgunit
host
_thisorgunit
_myens
user

-l オプションを指定すると、指定されたコンテキスト中で割り当てられている名前に関する情報が表示されます。


# fnlist -l user/
Listing bindings 'user/':
name: julio
Reference type: onc_fn_user
Address type: onc_fn_nisplus
 context type: user
name: chaim
Reference type: onc_fn_user
Address type: onc_fn_nisplus
 context type: user
name: James.Jones
Reference type: fn_link_ref
Address type: fn_link_addr
 Link name: user/jjones
name: jjones
Reference type: onc_fn_user
Address type: onc_fn_nisplus
 context type: user

-l、-v オプションを同時に指定すると、割り当てられた名前に関するさらに詳細な情報が表示されます。


# fnlist -lv user/
Listing bindings 'user/':
name: julio
Reference type: onc_fn_user
Address type: onc_fn_nisplus
 length: 52
 context type: user
 representation: normal
 version: 0
 internal name: fns_user_julio.ctx_dir.sales.doc.com.
name: chaim
Reference type: onc_fn_user
Address type: onc_fn_nisplus
 length: 52
 context type: user
 representation: normal
 version: 0
 internal name: fns_user_chaim.ctx_dir.sales.doc.com.
name: James.Jones
Reference type: fn_link_ref
Address type: fn_link_addr
 length: 11
 data: 0x75 0x73 0x65 0x72 0x2f 0x6a 0x6a 0x6f 0x6e 0x65
user/jjones
name: jjones
Reference type: onc_fn_user
Address type: onc_fn_nisplus
 length: 52
 context type: user
 representation: normal
 version: 0
 internal name: fns_user_jjones.ctx_dir.sales.doc.com.

複合名をリファレンスに割り当てる

fnbind は、複合名をリファレンスに割り当てるためのコマンドです。

このコマンドには、2 種類の構文があります。

既存の名前を新しい名前に割り当てる

既存の名前を新しい名前に割り当てるための fnbind の構文は以下のようになります。 


fnbind [-s][-v][-L] oldname newname
表 25–16 fnbind コマンドのオプション (割り当て名)

オプション 

説明 

oldname

すでに存在している複合名 

newname

すでに存在している複合名に割り当てる新しい名前 

-s

複合名がすでに割り当てられている場合、割り当てを上書きする 

-v

割り当てに使用されたリファレンスに関する情報を表示する 

-L

name を使用して XFN リンクを作成し、それを new_name に割り当てる

たとえば、以下のコマンドでは、user/julio/service/printer という名前が myorgunit/service/printer のリファレンスに割り当てられます。


# fnbind myorgunit/service/printer user/julio/service/printer

newname がすでに割り当てられている場合は、fnbind -s を使用しないと処理が正しく行われません。つまり上記の例で user/julio/service/printer がすでに割り当てられていれば、以下のように -s オプションを使用して myorgunit/service/printer との割り当てで上書きする必要があるということになります。


#fnbind -s myorgunit/service/printer user/julio/service/printer

-v オプションは、割り当てに使用されたリファレンスに関する情報を表示するのに使用されます。


# fnbind -v myorgunit/service/printer user/julio/service/printer
Reference type: onc_printers
Address type: onc_fn_printer_nisplus

以下の例では、user/jjones によって XFN リンクが作成され、user/James.Jones という名前に割り当てられます。


# fnbind -L user/jjones user/James.Jones

同様に以下の例では、user/julio/service/printer から myorgunit/service/printer へのリンクが作成されます。 


# fnbind -sL myorgunit/service/printer user/julio/service/printer

コマンド行にリファレンスを作成する

コマンド行にリファレンスを作成するための fnbind の構文は次のようになります。 


fnbind -r [-s] [-v] newname [-O | -U] reftype {[-O | -U] | addresstype 
[-c|-x] addresscontents}+
表 25–17 fnbind コマンドオプション (リファレンス作成)

オプション 

説明 

newname

リファレンスを作成する新しい名前 

reftype

作成するリファレンスのタイプ。-O、-U オプションを使用しない場合は、reftype の識別子として FN_ID_STRING を使用する

addresstype

作成するアドレスのタイプ。-O、-U オプションを使用しない場合は、addresstype の識別子として FN_ID_STRING を使用する

addresscontents

作成するリファレンスのアドレス。-c あるいは -x オプションを使用しない場合、アドレスは XDR によって符号化された文字列として保存される

-s

複合名がすでに割り当てられている場合、割り当てを上書きする 

-v

割り当てに使用されたリファレンスに関する情報を表示する 

-c

アドレス内容を、XDR による符号化を行わずに保存する 

-x

アドレス内容を 16 進数で入力された文字列であると解釈し、そのまま保存する 

-r

指定タイプのリファレンスを作成し、コマンド行で指定された名前に割り当てる 

-O

タイプを指定する文字列を、ASN.1 の形式 (整数をいくつか並べてドットで区切ったもの) として解釈して保存する 

-U

タイプを指定する文字列を、DCE UUID として解釈して保存する 

たとえば、以下の例では、thisorgunit/service/calendar という名前が、「タイプ onc_calendar、アドレスタイプ onc_cal_str、アドレス staff@cygnus」というリファレンスに割り当てられます。


# fnbind -r thisorgunit/service/calendar onc_calendar 
onc_cal_str staff@cygnus

コマンド行で指定されたアドレスは、デフォルトでは XDR で符号化された後、リファレンスに保存されます。-c オプションが指定された場合は、XDR による符号化は行われず、そのままの形で保存されます。-x オプションが指定された場合は、16 進文字列として解釈されて保存されます (XDR による符号化は行われない)。

リファレンス (およびそのアドレス) のタイプの指定には、デフォルトでは FN_ID_STRING 識別子の形式が使用されます。-O オプションでは FN_ID_ISO_OID_STRING (ASN.1、10進数を並べてドットで区切る) の形式が、-U オプションでは FN_ID_DCE_UUID (DCE UUID、文字列を使用する) の形式が使用されます。

注 –

ASN.1 の詳細は、『ISO 8824: 1990, Information Technology — Open Systems Interconnection — Specification of Abstract Syntax Notation One (ASN.1)』を参照してください。DCE UUID の詳細は、『X/Open Preliminary Specification, October 1993, X/Open DCE: Remote Procedure Call (ISBN: 1-872630-95-2)』を参照してください。

以下の例では、thisorgunit/service/nx という名前に割り当てられるリファレンス (およびそのアドレス) の、タイプが OIDs の形式で、アドレスが 16 進の文字列で指定されています。


# fnbind -r thisorgunit/service/nx -O 1.2.99.6.2.1 
-O 1.2.99.6.2.3 -x ef12eab67290

複合名を削除する

fnunbind は、複合名を名前空間から削除するのに使用されます。ただし、名前に対応するオブジェクトは削除されず、オブジェクトと名前のバインドを解除するだけであるという点に注意してください。

以下の例では、user/jjones/service/printer/color という複合名が削除されます。


# fnunbind user/jjones/service/printer/color

コンテキストに割り当てられた名前を変更する

fnrename は、コンテキストに割り当てられている名前を変更するのに使用されます。

以下の例では user/jjones/service/ というコンテキストに割り当てられた、clndr という名前が calendar に変更されます。


# fnunbind user/jjones/service/printer/color

コンテキストを削除する

fndestroy は、指定された複合名を名前空間から削除し、その名前を持つコンテキストを削除するのに使用されます。

たとえば、user/jones/ という名前を名前空間との割り当てから解除し、user/jjones/ という名前のコンテキストを削除するには、以下のように入力します。


# fndestroy user/jjones/

削除の対象となるコンテキスト (指定された複合名を持つもの) にサブコンテキストが存在する場合、コマンドは正常に動作しません。

FNS の管理 - 属性の概要

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

属性はユニークな属性識別子、属性構文、および 0 個以上の明確な属性値のセットからなります。

XFN で、既存の名前付きオブジェクトに対応する属性値の検索や変更のための、基本的な属性インタフェースが定義されます。これらのオブジェクトはコンテキストの場合もあれば、別のタイプのオブジェクトの場合もあります。コンテキストに関連しているのは、構文属性で、これはコンテキストがどのように複合名を解析するかを示します。

拡張属性インタフェースには、特定の属性を検索したり、オブジェクトやそれに対応する属性を作成するオペレーションが含まれます。

属性を検索する

fnsearch コマンドで、属性を検索します。

fnsearch コマンドの構文を以下に示します。 


fnsearch [-ALlv] [-n max] [-s scope] name [-a ident]... [-O|-U] filter_expr [filter_arg]
表 25–18 fnsearch コマンドのオプション

オプション 

説明 

-n max

オブジェクトの最大数だけを表示する 

-s scope

検索の範囲を設定する 

-a ident

ident に一致する属性だけを表示する

name

複合名 

filter_expr

ブール、論理、グルーピング、リレーショナル、比較演算子 (表 25–19 参照)

filter_arg

フィルタ表現の引数 (表 25–19 参照)

-A

信頼できるソースだけを参照する 

-L

XFN リンクに従う 

-l

一致するオブジェクトのオブジェクトリファレンスを表示する 

-v

詳細表示。一致するオブジェクトの詳細なオブジェクトリファレンスを表示する 

-O

識別子として OSI OID を使用する 

-U

識別子として DCE UUID を使用する 

属性に対応するオブジェクトを検索する

fnsearch コマンドを使って、選択した属性に対応するオブジェクトを検索できます。

たとえば、orgunit/sales/site/ の中の for_sale という属性に対応している属性をすべて見つけ出す場合、以下のコマンドを入力します。


 % fnsearch orgunit/sales/site/ for_sale

属性検索をカスタマイズする

検索パターンにおいて、フィルタ表現のうち以下のすべてを使用することもできます。

表 25–19 fnsearch フィルタ表現の演算子

フィルタ表現演算子 

シンボル、あるいは形式 

論理演算子 

or, and , not

グルーピングのための丸括弧 

( )

関係演算子：ある属性を入力した値と比較する 

== 1 つ以上の属性値が入力値に等しい場合、True (真)。!= 入力値に等しい属性値がない場合、True (真)。< 1 つ以上の属性値が入力値未満の場合、True (真)。<= 1 つ以上の属性値が入力値以下の場合、True (真)。> 1 つ以上の属性値が入力値を超える場合、True (真)。>= 1 つ以上の属性値が入力値以上の場合、True (真)。~= コンテキスト固有のあいまい照合条件に基づいて、1 つ以上の属性値が入力値と一致している場合、True (真)。この条件は厳密な一致を含む必要がある

例 :  

% fnsearch name "not (make == 'olds' and year == 1983)"

置換トークン： 

シェルスクリプトを書くときに役に立ち、-O および -UO を指定すると、OSI OID および DCE UUID を使用できる

%a は、属性に置き換えられる

%s は、文字列に置き換えられる

%i は、識別子に置き換えられる

%v は、属性値に置きかえられる (現在は、fn_attr_syntax_ascii しかサポートされていない)

例 :  

以下の 3 つの例はどれも同じ 

% fnsearch name "color == 'red'"

% fnsearch name "%a == 'red'" color

% fnsearch name "%a == %s" color red

ワイルドカード文字列 

*, *string , string*, str*ing, %s*

拡張演算子 

'name'(ワイルドカードを使った文字列), 'reftype'(識別子), 'addrtype' (識別子)

例 :  

名前が "Bill" で始まり、IQ 属性が 80 以上のオブジェクトを検索する 

% fnsearch name "'name'('bill'*) and IQ> 80"

検索パターン作成の詳細については、fnsearch(1) マニュアルページを参照してください。

属性を更新する

fnattr コマンドにより、FNS 名前付きオブジェクトに関連する属性を更新したり検索したりできます。fnattr コマンドを使って、以下の 4 つの属性に関する操作が行えます。 


fnattr -a [-s] name [-O|-U] identifier values


fnattr -d name [[-O|-U] identifier [values]]
 

fnattr -m name [-O|-U identifier oldvalue newvalue


fnattr -l name [[-O|-U] identifier
表 25–20 fnattr コマンドのオプション

オプション 

説明 

name

複合名 

identifier

属性名 

values

1 つあるいは複数の属性値 

oldvalue

変更する属性値 

newvalue

新しい属性値 

-a

新しい属性値を追加 (作成) する 

-d

属性を削除する 

-m

属性を変更 (修正) する  

-l

属性値を一覧表示する 

-s

「代用」モードで追加する。identifier 属性に対する既存の値をすべて削除し、新しい属性値を作成する

-l

属性と値を一覧表示する 

-O

識別子として OSI OID を使用する 

-U

識別子として DCE UUID を使用する 

各オプションでの識別子の形式は、-O あるいは -U のオプションを使用していない限り、FN_ID_STRING になります。

属性を追加する

属性を追加したり、属性に値を追加したりするには、-a オプションを使用します。この場合、複合名、属性識別子、追加する値も指定します。


fnattr -a [-s] name [-O | -U] identifier value1 [value2+]

以下の例では、属性識別子 model と値 hplaser が thisorgunit/service/printer に追加されます。


# fnattr -a thisorgunit/service/printer model hplaser

-s は、「代用モードで追加する」という意味のオプションです。指定の識別子を持つ属性がすでに存在する場合、-s はその値をすべて削除し、それらを追加した値に置き換えます。このオプションを指定しないと、指定した属性の値には既存の値と追加した新しい値の両方が含まれることになります。


# fnattr -as thisorgunit/service/printer model hplaser

上の例では最初に model に対応する値をすべて削除し、hplaser を値として追加します。

属性を削除する

FNS 名前付きオブジェクトの属性を削除するには、-d オプションを使用します。


fnattr -d name [[-O | -U] identifier value1 [value2+]]]

削除対象の指定には以下の規則があります。

以下の例では、thisorgunit/service/printer のすべての属性が削除されます。


# fnattr -d thisorgunit/service/printer

属性の内容を表示する

属性の内容を表示するには、-l オプションを使用します。構文は以下のとおりです。


fnattr -l name [[-O | -U] identifier]

以下の例では、thisorgunit/service/printer の model 属性の値が表示されます。


# fnattr -l thisorgunit/service/printer model
laser
postscript

識別子を指定しない場合、オブジェクトのすべての属性の内容が表示されます。

属性を変更する

属性値を変更するには、-m オプションを使用します。構文は以下のとおりです。


fnattr -m name [-O | -U] identifier old_value new_value

以下の例では、postscript という値が laser に変更されます。


# fnattr -m thisorgunit/service/printer model postscript laser

指定した値だけが変更されます。その属性に関連付けられたその他の属性と値は変更されません。

その他のオプション

-O オプションを指定した場合、属性識別子の形式には、ASN.1 の整数を並べてドットで区切る形式 (FN_ID_ISO_OID_STRING、10 進数を並べてドットで区切る形式) を使用します。

-U オプションを指定した場合、属性識別子の形式には、DCE UUID 文字列 (FN_ID_DCE_UUID) を使用します。

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

エンタープライズレベルのネームサービスは、組織内のオブジェクトをネーミングするために使用されます。現在 FNS は、NIS、NIS+、およびローカルファイルに対して、3 つのエンタープライズレベルのネームサービスをサポートしています。

エンタープライズレベルのネームサービスを選択する

fncreate コマンドを使用して FNS 名前空間を初めて設定および構成するときは、名前空間の設定方法について FNS 用の名前空間の準備 を参照してください。正しいデフォルトのネームサービスが、各マシンに対して自動的に選択されます。

マシンの主要なエンタープライズレベルのネームサービスを後で変更する場合は、そのマシンで fnselect コマンドを実行する必要があります。詳細については、ネームサービスを選択するを参照してください。

FNS とネームサービスとの整合性

タスクの 1 つにシステム管理者の機能が割り当てられていて、FNS とその下層のネームサービス間の整合性を維持しています。これは、ネームサービスのファイル、マップ、またはテーブルと FNS コンテキストが正しく対応しているかどうかをチェックするということです。

FNS 用の名前空間の準備の説明に従って、fncreate コマンドを使用して FNS 名前空間を初めて設定および構成すると、 fncreate により FNS コンテキストが適切に作成され、配下のネームサービスデータと整合性が確保されます。FNS コンテキストが設定された後、ユーザー、ホスト、プリンタなどがシステムに追加または削除されるときに、この対応関係は維持される必要があります。以下の項では、FNS とネームサービスとの整合性を維持する方法について説明します。

FNS と Solstice AdminSuite

Solstice AdminSuite 製品で、基本的なネームサービスでのユーザーとホストの情報を追加、変更、削除できます。AdminSuite ツールでは対応する FNS 名前空間が自動的に更新されるため、この方法をお勧めします。

ネーミングの不一致をチェックする

Solstice AdminSuite 製品を使用せずに FNS または主要なネームサービスを更新するときに、不一致が発生した場合は、FNS ツールの fncheck を使用して解決します。fncheck コマンドは、FNS の hostname と user のコンテキストと、次のものとの不一致をチェックします。

fncheck コマンドは、FNS 名前空間にあってネームサービスのデータにないホストとユーザー名およびネームサービスのデータにあって FNS 名前空間にないホストとユーザー名を表示します。

コマンド構文は以下の通りです。 


fncheck [-r][-s][-u][-t hostname|username][domain_name]
表 25–21 fncheck コマンドオプション

オプション 

説明 

domain

コマンドを実行しているドメイン以外の NIS+ ドメインにコマンドを適用する 

-t

チェックするコンテキストのタイプを指定する。許容されるタイプは、hostname または username

-s

FNS 名前空間にない名前空間のデータセットからホスト名とユーザー名を表示する 

-r

対応する名前空間のデータセットにないエントリを持たない FNS 名前空間からホスト名またはユーザー名を表示する 

-u

関連した名前空間のデータセットにある情報に基づいて FNS 名前空間を更新する 

-t オプションは、チェックするコンテキスト (ホストまたはユーザー) を指定するために使用します。-t オプションを省略した場合は、hostname と username のコンテキストの両方がチェックされます。

-r オプションを -u オプションとともに使用すると、FNS コンテキストにしか表示されない項目が FNS コンテキストから削除されます。-s オプションを -u オプションとともに使用すると、名前空間のデータセットにしか表示されない項目が FNS コンテキストに追加されます。-r と -s のどちらも指定しない場合は、項目が FNS コンテキストに追加および削除され、対応する名前空間のデータとの整合性が保たれます。

ネームサービスを選択する

FNS がマシンに対する初期コンテキストに割り当てを構成するときには、特定のネームサービスに基づいて行います。

FNS では fnselect コマンドで使用するネームサービスを選択できます。fnselect で指定したネームサービスの設定は、マシン全体、そのマシンで動作するすべてのアプリケーション、およびそのマシンにログインしたすべてのユーザーに影響します。

スーパーユーザーだけが fnselect を実行できます。コマンド構文は以下の通りです。 


fnselect [-D] [namesvc]
表 25–22 fnselect コマンドオプション

オプション 

説明 

namesvc

選択するネームサービス。必ず次のどれかになる。 default、nisplus、nis または files

-D

FNS 初期コンテキストを生成するために使用されるネームサービスを表示する 

たとえば、マシンのネームサービスとして NIS+ を選択するには以下のコマンドを使用します。


# fnselect nisplus

たとえば、マシンのネームサービスとして default を選択し、FNS 初期コンテキストを生成するために使用されるサービスの名前を印刷するには次のように入力します。


# fnselect -D default

デフォルトのネームサービス

fnselect でネームサービスを指定しない場合、FNS はデフォルトのネームサービスを使用します。デフォルトのネームサービスは、マシンの使用するネームサービスに基づいて FNS で決定されます。マシンが NIS+ クライアントである場合は、FNS は NIS+ をネームサービスとして使用します。マシンが NIS クライアントである場合は、FNS は NIS を使用します。マシンが NIS+ および NIS クライアントのどちらでもない場合は、FNS は /etc ファイルをマシンのネームサービスとして使用します。

NIS+ と NIS が共存する場合

ごくまれに、NIS+ と NIS ベースのコンテキストの両方にアクセスする必要が生じることがあります。たとえば、それ自体が NIS+ クライアントである NIS サーバーを稼働している場合です。この場合、fnselect コマンドを使用して、使用するエンタープライズレベルのネームサービスを選択します。

FNS と NIS+ の詳細情報

この節では、NIS+ オブジェクトと FNS オブジェクトの関係の詳細について説明します。この情報は、FNS オブジェクトのアクセス制御を変更するときに有効です。

注 –

以下を参照してください。

FNS コンテキストを NIS+ オブジェクトにマップする

FNS コンテキストは、NIS+ オブジェクトに格納されます。組織に関連するすべてのコンテキストは、関連する NIS+ ドメインの ctx_dir ディレクトリに格納されます。ctx_dir ディレクトリは、同じドメインの org_dir と同じレベルにあります。すなわち、FNS と同時に実行される時には、それぞれの NIS+ ドメインまたはサブドメインには対応する org_dir、groups_dir、および ctx_dir というディレクトリオブジェクトが存在します。

fnlookup または fnlist のコマンドで -v オプションを使用して、リファレンスについての詳細な説明を表示します。内部名フィールドに、対応する NIS+ オブジェクトの名前が表示されます。

NIS+ コマンドを使用して FNS 構造を表示する

NIS+ コマンドの nisls を使用して、FNS で使用される NIS+ オブジェクトを表示できます。たとえば、次のコマンドでは、NIS+ ドメインのディレクトリおよび ctx_dir サブディレクトリの内容が表示されます。 


# nisls doc.com.
doc.com.:
manf
sales
groups_dir
org_dir
ctx_dir
 

# nisls ctx_dir.doc.com.
ctx_dir.DOC.COM.:
fns
fns_user
fns_host
fns_host_alto
fns_host_mladd
fns_host_elvira
fns_user_jjones
fns_user_jsmith
fns_user_aw

niscat コマンドを使用して、fns_hosts テーブルの内容を表示します。 


# niscat fns_host.ctx_dir
altair *BINARY* *BINARY*
cygnus *BINARY* *BINARY*
centauri *BINARY* *BINARY*

アクセス制御をチェックする

niscat コマンドを -o オプションつきで使用して、コンテキストのアクセス制御を確認します。特定の割り当てのアクセス制御を確認するには、親コンテキストの割り当てテーブルにある割り当てエントリの名前 (つまり、fnlookup -v および fnlist -v の出力の内部名フィールドに表示される名前) を使用します。 


# niscat -o fns_host.ctx_dir
Object Name     	:	fns_host
Owner           	:	alto.doc.com.
Group      	      :	admin.doc.com.
Domain            :	ctx_dir.doc.com.
Access Rights   	:	r-c-rmcdrmcdr-c-
Time to Live    	:	53:0:56
Object Type     	:	TABLE
Table Type      	:	H 
Number of Columns	:	3
Character Separator
Search Path     	:
Columns        	:
[0]	Name	:	atomicname
 	Attributes	:	(検索可能、テキストデータ、大文字・小文字の区別なし)
	 Access Rights	:	r-c-rmcdrmcdr-c-
[1]	Name	:	reference
	Attributes	:	(2 進データ)
	Access Rights	:	r-c-rmcdrmcdr-c-
[2]	Name	:	flags
	Attributes	:	(2 進データ)
	Access Rights	:	r-c-rmcdrmcdr-c-
 

# niscat -o "[atomicname=altair],fns_host.ctx_dir" 
Object Name :	fns_host
Owner   	:	altair.doc.com.
Group    :	admin.doc.com.
Domain  	:	ctx_dir.doc.com.
Access Rights :	r-c-rmcdrmcdr-c-
Time to Live	:	12:0:0
Object Type	:	ENTRY
Entry data of type H
[1] - [5 bytes] 'alto'
[2] - [104 bytes] '0x00 ...'
[3] - [1 bytes] 0x01

niscat コマンドに関する追加情報については、niscat コマンドを参照してください。

特定のコンテキストのアクセス権または所有権を変更するには、次のコマンドを使用します。

操作が影響するオブジェクトに応じて、割り当てエントリまたは割り当てテーブルのどちらかを引数として与えます。

FNS と NIS の詳細情報

ここでは、NIS と FNS の関係についての特定情報を説明します。

NIS と FNS のマップと Makefile

FNS は、NIS マスターおよびスレーブのサーバー上の /var/yp/domainname ディレクトリに格納されている 6 つのマップを使用します。

ホスト、ユーザー、およびエンタープライズのサービスとファイルのコンテキスト情報は、それぞれ fns_host.ctx、fns_user.ctx、および fns_org.ctx のマップに格納されます。プリンタのコンテキスト情報は、他のサービスのコンテキスト情報と同じマップに格納されます。しかし、古い printers.conf.byname マップはここでもサポートされます。

サイトは、エンタープライズのサブコンテキストであり、サイトのコンテキスト情報は fns_org.ctx マップに格納されます。

注 –

これらの FNS マップは、直接編集しないでください。fncreate、 fndestroy、fnbind、fnunbind、fnrename、fnattr、fnlookup、および fnlist などの適切な FNS コマンドを実行して、これらのマップで変更または作業を行います。これらのコマンドは、必ず NIS マスターサーバーで実行します。スレーブサーバーまたはクライアントマシンでこれらを実行できません。

FNS マップファイルは、/var/yp/domainname ディレクトリにあります。/var/yp にある NIS Makefile は変更され、/etc/fn/domainname にある FNS Makefile が認識されます。

大型 FNS コンテキスト

NIS では、NIS マップに含まれるエントリ数に 64K という制限があります。サービスおよびプリンタのコンテキストだけが各オブジェクト (ホストまたはユーザー) に作成された場合、ユーザーまたはホストの数が 7K を超えると、エントリ数がその制限に達します。通常行われるように、ホストまたはユーザーに追加のコンテキストが作成された場合、ずっと少ないホストまたはユーザーでエントリ数が 64,000 の上限に達します。

FNS は、古いマップが最大サイズに達したら新規マップを自動的に作成して、この問題を解決します。各新規マップは、マップ名に数字の接尾辞を追加して識別されます。たとえば、2 つめの fns_user.ctx マップが作成されると、そのマップには名前 fns_user_0.ctx という名前が与えられます。3 つめのマップが必要になると、そのマップには名前 fns_user_1.ctx という名前が与えられます。追加のマップが作成されるにつれて、数字は毎回増加していきます。

プリンタの下位互換

Solaris 2.5 では、FNS は、printers.conf.byname という名前のマップを使用して、組織コンテキストに対して NIS のプリンタのネーミングをサポートします。現在の Solaris では、組織コンテキストのプリンタサポートは、fns_org.ctx マップに保持されています。つまり、ここでの fncreate_printer コマンドでは fns_org.ctx マップが変更され、printers.conf.byname マップは変更されません。

NIS から NIS+ への変更

fncopy コマンドは、エンタープライズレベルのネームサービスを NIS から NIS+ に変更するときに、FNS 関連の側面を処理します。このコマンドは、NIS ベースの FNS コンテキストを NIS+ ベースのコンテキストにコピーして変換します。

コマンド構文は以下の通りです。 


fncopy [-i oldsvc -o newsvc] [-f filename] oldctx newctx
表 25–23 fncopyコマンドオプション

オプション 

説明 

-i oldsvc

ソースのネームサービス。nis または files だけが指定される

-o newsvc

目標のネームサービス。 nisplus または nis だけが指定される

-f filename

コピーされる FNS コンテキストを表示するファイル名 

oldctx

コピーされる古い FNS コンテキスト 

newctx

目標の新規 FNS コンテキスト 

たとえば、ファイル /etc/sales_users に表示されるコンテキストを、NIS ベースのネームサービスの doc.com ドメインから NIS+ ネームサービスの sales.doc.com ドメインにコピーするには、次のように入力します。


fncopy -i nis -o nisplus -f /etc/sales_users org/sales.doc.com/user

FNS とファイルベースのネーミングの詳細情報

この節では、ファイルベースのネーミングと FNS の関係についての特定の情報を説明します。

FNS ファイル

FNS では、各マシンの /var/fn ディレクトリに格納された新規ファイルが使用されます。通常 /var/fn ディレクトリは各マシンに格納されていますが、NFS 経由で中央の /var/fn ディレクトリをマウントしたり、エクスポートしたりできます。

新規 FNS ファイルを以下に示します。

ホスト、ユーザー、およびエンタープライズのサービスとファイルのコンテキスト情報は、それぞれ fns_host.ctx、fns_user.ctx、および fns_org.ctx のファイルに格納されます。プリンタのコンテキスト情報は、他のサービスのコンテキスト情報と同じファイルに格納されます。

サイトは、エンタープライズのサブコンテキストであり、サイトのコンテキスト情報は fns_org.ctx ファイルに格納されます。

注 –

これらの FNS ファイルは、直接編集しないでください。fncreate、 fndestroy、fnbind、fnunbind、fnrename、fnattr、fnlookup、および fnlist などの適切な FNS コマンドを実行して、これらのファイルで変更または作業を行います。スーパーユーザーとしてこれらのコマンドを実行すると、ホスト、サイト、および組織単位などの、コマンドが適用されるコンテキストが影響されます。ユーザーとしてこれらのコマンドを実行すると、自分のユーザーのサブコンテキストだけが影響されます。

ファイルベースのネーミングから NIS または NIS+ への変更

fncopy コマンドは、エンタープライズレベルのネームサービスをファイルから NIS または NIS+ に変更するときに、FNS 関連の側面を処理します。このコマンドは、ファイルベースの FNS コンテキストを NIS または NIS+ ベースのコンテキストにコピーして変換します。

コマンド構文は以下の通りです。 


fncopy [-i oldsvc -o newsvc] [-f filename] oldctx newctx

たとえば、ファイル /etc/host_list に表示される内容を NIS+ ネームサービスの doc.com ドメインにコピーするには、次のように入力します。


fncopy -i files -o nisplus -f /etc/host_list //doc.com/host

プリンタの下位互換

Solaris 2.5 では、FNS は、printers.conf.byname という名前のファイルを使用して、組織コンテキストに対してファイルへのプリンタのネーミングをサポートします。現在の Solaris では、組織コンテキストのプリンタサポートは、fns_org.ctx マップに保持されています。つまり、ここでの fncreate_printer コマンドでは fns_org.ctx マップが変更され、printers.conf.byname マップは変更されません。

ファイルコンテキストの管理

ファイルコンテキストには、以下のようなものがあります。

fncreate_fs を使ってファイルコンテキストを作成する

fncreate_fs コマンドにより、組織やサイト用にファイルコンテキストが作成できます。fncreate コマンドによって作成されたホストやユーザーのためのデフォルトのファイルコンテキストを無効にするために使用されることもあります。

fncreate_fs コマンドの使用には、以下のような 2 つの方法があります。

fncreate_fs の 2 つの方法には、以下のような構文があります。 


fncreate_fs [-v] [-r] -f  file composite_name
fncreate_fs [-v] [-r] composite_name [options] [location...]
表 25–24 fncreate_fs コマンドのオプション

オプション 

説明 

composite_name

ファイルコンテキストの複合名 

-f file

file という名前の入力ファイルを使用する

options

マウントのオプション 

location

マウントする位置 

-v

詳細出力に設定。作成および修正されるコンテキストに関する情報を表示 

-r

composite_name で名前付きコンテキスト、およびそのサブコンテキストのすべての割り当てを、入力で指定したものだけで置き換える。これは、コンテキスト (およびそのサブコンテキスト) を削除し、このオプションなしで、fncreate_fs を実行するのと同じ。-r オプションは、注意して使用する必要がある

fncreate_fs コマンドは、FNS コンテキスト、および onc_fn_fs リファレンスタイプの割り当てを操作します。これは、onc_fn_fs_mount タイプのアドレスを使って、それぞれのリモートのマウント先を表わします。このタイプのアドレスに関連するデータは、XDR で符号化された 1 つの文字列で示した、対応するマウントのオプションやマウント先になっています。

入力ファイルを使って、ファイルコンテキストを作成する

入力ファイルには、composite_name のコンテキストで割り当てられる名前や値が入っています。この形式は、間接自動マウントマップの形式に基づいてはいますが、全く同じではありません。入力ファイルには、以下のような形式のエントリが 1 つあるいは複数含まれています。


name [options] [location...]

引数の意味は、それぞれ以下のとおりです。

各エントリについて、マウントの位置や対応するマウントのオプションのリファレンスは、composite_name/name に割り当てられます。

options と location の両方が省略されると、リファレンスは composite_name/name に割り当てられません。既存のリファレンスもすべて割り当てられません。

たとえば、kuanda のファイルシステムを図 25–3 に示すように、ホスト altair からディレクトリ /export/home/kuanda を NFS マウントするとしましょう。コマンドは以下のように実行されます。


% fncreate_fs -f infile user/kuanda/fs

ここでは、以下を含む infile を使用します。 


. altair:/export/home/kuanda

図 25–4 に示されるような、複数のサーバーに分散された複雑なファイルシステムを設定する場合、以下のコマンドを実行します。


% fncreate_fs -f infile org/sales/fs

ここでは、以下を含む infile を使用します。


tools/db	 	altair:/export/db
project		 	altair:/export/proj
project/lib             altair:/export/lib
project/src	 	deneb:/export/src

プロジェクトやそのサブコンテキストの src や lib の NFS マウントを、読み取り専用に変更する場合、infile を以下のように変更します。


tools/db 	 			svr1:/export/db
project	      -ro			svr1:/export/projproject/lib 
altair:/export/lib
project/src	 			svr2:/export/src

-ro は、3 行目と 4 行目では必要ありません。なぜならば、src および lib は、project のサブコンテキストであり、これらは、上から -ro マウントオプションを継承するからです。

以下の入力ファイルは、org/sales/fs/project/src を除いて、すべてのマウントを読み取り専用にします。


.       -ro
tools/db    svr1:/export/db
project     svr1:/export/proj
project/lib altair:/export/lib
project/src      -rw      svr2:/export/src

コマンド行の入力によりファイルコンテキストを作成する

fncreate_fs コマンドにより、以下のように割り当ての説明をコマンド行で入れることもできます。 


fncreate_fs composite_name [mmount_options] [mount_location ...]

これは、コマンドの入力ファイル書式を使用し、キーボードから個々の割り当てを入力するのと同じです。先の kuanda のファイルシステムを設定した例は、コマンド行からは、以下のように設定できます。


% fncreate_fs user/kuanda/fs altair:/export/home/kuanda

同様に、図 25–4 に示した階層構造は、以下のような一連のコマンドを実行することによって、設定できます。


% fncreate_fs org/sales/fs/tools/db altair:/export/db
% fncreate_fs org/sales/fs/project altair:/export/proj
% fncreate_fs org/sales/fs/project/lib altair:/export/lib
% fncreate_fs org/sales/fs/project/src deneb:/export/src

これら 3 つすべてのマウントを読み取り専用にするには、以下のコマンドを実行します。 


% fncreate_fs org/sales/fs -ro

詳細入力フォーマット

以下の 2 つの項で述べる内容は、入力ファイル、およびコマンド行入力の両方の形式に適用されます。

多重マウントの位置

複数の location フィールドが、機能的には同じである複数の位置からエクスポートされた NFS ファイルシステムに対して指定できます。


% fncreate_fs org/sales/fs altair:/sales cygnus:/sales

オートマウンタが、選択肢の中から最適のサーバーを選択します。リストの中のいくつかの位置が同じパス名を共有している場合、これらは以下のようにコンマで区切ったホスト名のリストを使用して、結合されます。


% fncreate_fs org/sales/fs altair,cygnus:/sales

ホストは、丸括弧で囲った整数の形でホストに追加された重み係数により加重されることがあります。この場合、数字が小さければ小さいほど、望ましいサーバーであることを示します。デフォルトの重み係数は、ゼロ (もっとも望ましい) です。マイナスの数字は使用できません。

以下の例では、cygnus が望ましいサーバーになっていることを示す 1 つの方法を表わしています。


% fncreate_fs org/sales/fs altair(2),cygnus(1):/sales

変数の置き換え

前に $ の付く変数名を、fncreate_fs の options や location のフィールドで使用できます。たとえば、マウントの位置は、以下のように指定できます。


altair:/export/$CPU

対応するファイルシステムにマウントする際、オートマウンタにより、これらの変数がクライアントに固有の値に置き換えられます。上の例の場合、$CPU は、uname -p の出力結果、たとえば sparc で置き換えられます。

下位互換入力フォーマット

さらにオートマウントマップとの互換として、以下の入力ファイル書式も fncreate_fs で使用できます。 


name	 [mount_options] [mount_location ...] \ 
 /offset1	[mount_options1] mount_location1 ... \
 /offset2	[mount_options2] mount_location2 ... \
 ...

ここでは、各 offset フィールドは、スラッシュで区切った階層構造になっています。バックスラッシュ (\) は、1 つの長い行の続きであることを示します。これは、以下を行うのと同じことです。


name [mount_options] [mount_location ...] \
name/offset1	[ mount_options1] mount_location1 ... \
name/offset2	[mount_options2] mount_location2 ......

最初の行は、mount_options と mount_location の両方が省略されている場合、省略します。この書式は、互換のためだけのものです。これ以外の機能はないので、あまり使用しないでください。

FNS および XFN ポリシーの概要

XFN は、フェデレートされた名前空間にあるオブジェクトをネーミングするためのポリシーを定義します。これらのポリシーは、次のような目的を持っています。

FNS ポリシーで指定されるもの

FNS ポリシーには、すべての XFN ポリシーと Solaris 環境用の拡張機能が含まれます。

現在、コンピュータ環境は世界的な規模となり、広範囲なサービスを提供しています。ユーザーは、どのレベルのコンピュータ環境のサービスにもアクセスできます。FNS ポリシーは、グローバル、エンタープライズ、アプリケーションの 3 つのレベルのサービスに共通の枠組みを提供します。

FNS は、ネームサービスをどのように調整して使用するかについて次のようなポリシーをアプリケーション側に提供します。

FNS ポリシーで指定されないもの

FNS ポリシーでは、次のものは指定されません。

エンタープライズ名前空間のポリシー

FNS ポリシーでは、エンタープライズ内の名前空間のタイプおよび配列と、アプリケーションが名前空間を使用する方法が指定されます。たとえば、名前空間が他のどの名前空間と関連するかが指定されます。ここで説明する FNS ポリシーには、XFN ポリシーへの拡張機能があります。これらは、注釈によって明確に定義されます。

デフォルトの FNS エンタープライズ名前空間

FNS エンタープライズのポリシーでは、名前空間内でのエンタープライズのオブジェクトの配列が処理されます。各エンタープライズのオブジェクトは、独自の名前空間を持っています。

デフォルトでは、FNS には 7 つのエンタープライズオブジェクトと対応する名前空間があります。

これらの名前空間に適用されるポリシーは、表 25–26 に要約しています。

エンタープライズ名前空間の識別子

エンタープライズ名前空間は、フェデレートされた名前空間の原子名によって参照されます。

XFN では、先行する下線 (_) 文字を使用して、エンタープライズ名前空間の識別子が示されます。たとえば、_site となります。FNS では、下線 (_) なしの識別子の使用もサポートされます。下線なしの名前は、XFN ポリシーの範疇には入りません。site および printer のコンテキストも、XFN ポリシーの範疇には入りません。これらの名前は、表 25–25 に挙げられています。

表 25–25 エンタープライズでのエンタープライズ名前空間の識別子

名前空間 

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 名前空間

FNS では、次の 7 つの名前空間が提供されます。

組織単位の名前空間

組織単位の名前空間では、エンタープライズのサブ単位をネーミングするために階層になった名前空間が提供されます。各組識単位名は組織単位を表す「組織単位コンテキスト」と結合されています。組織単位名は、接頭辞 org/、orgunit/、または _orgunit/ によってネーミングされます。短縮形別名の org/ は、内部コンテキストだけで使用され、複合名の途中では使用されません。および、複合名の例を参照してください。

NIS+ 環境

NIS+ 環境では、組織単位は NIS+ のドメインおよびサブドメインに対応します。

NIS+ では、組織単位は必ずドメインおよびサブドメインにマップされます。それぞれの NIS+ ドメインおよびサブドメインに組織単位を与える必要があります。ドメインまたはサブドメインに論理、組織ユニットを与えることはできません。つまり、NIS+ ドメインまたはサブドメインを小規模な組織単位に分割することはできません。1 つの NIS+ ドメイン (doc.com.) と 2 つのサブドメイン (sales.doc.com. と manf.doc.com. ) が存在する場合は、ドメインごとに 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 環境では、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 という名前のマシンを識別します。

ホストは、「ホスト名」コンテキストでネーミングされます。ホストコンテキストには、フラットな名前空間があり、ホストコンテキストへのホスト名の割り当てが含まれます。「ホストコンテキスト」では、そのホストで見つかったファイルやプリンタなどの、マシンに相対的なオブジェクトをネーミングできます。

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 が識別されます。

ファイルの名前空間については、ファイルベースのネーミング で詳しく説明し、ファイルのコンテキストについては、ファイルコンテキストの管理 で説明します。

サービスの名前空間

サービスの名前空間では、エンタープライズ内のオブジェクトに使用される、または関連するサービスのための名前空間が提供されます。このようなサービスには、電子カレンダ、FAX、メール、印刷などがあります。サービス名は、接頭辞 service/ または _service/ で識別されます。

Solaris オペレーティング環境では、サービスの名前空間は構造階層になっています。サービス名は、スラッシュ (/) で区切られた左から右の複合名です。サービスの名前空間を使用するアプリケーションは、この階層属性を利用し、そのアプリケーションのサブツリーを獲保します。たとえば、プリンタサービスはサービスの名前空間のサブツリー printer を獲保します。

FNS は、サービス名またはリファレンスタイプが選択される方法を指定します。これらは、サービスの名前空間を共有するサービス提供者によって決定されます。たとえば、カレンダサービスは、サービスのコンテキストにある名前 _service/calendar を使用してカレンダサービスをネーミングし、名前 calendar に割り当てられたものを決定します。

サービス名およびリファレンスの登録

米国 Sun Microsystems, Inc. は、service の名前空間の最初のレベルにある名前の登録を行います。新規名を登録するには、電子メールのリクエストを fns-register@sun.com まで送信するか、または書面で次の住所までご郵送ください。

FNS Registration Sun Microsystems, Inc., 4150 Network Circle Santa Clara, CA 95054 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 予約名

FNS は、表 25–25 に挙げたすべての原子名をそれ自身の使用のために名前空間識別子として獲保します。たとえば、_orgunit、 org、_site、site などが予約されています。この制限事項は、エンタープライズ名前空間の構造にある名前空間の配列で定義されているように、名前空間識別子が現れるコンテキストに適用されます。それ以外の場合は、FNS は、他のコンテキストではこれらの原子名の使用を制限します。

たとえば、原子名 service は、user/fatima/service/calendar のように、ユーザー名に相対的な名前空間識別子として使用され、ユーザー fatima のサービスの名前空間のルートであることを意味します。FNS では、名前 user/ が割り当てられるコンテキストは、名前空間識別子にではなく、ユーザー名に指定されるため、user/service のようにユーザー名として名前 service を使用することが禁止されるわけではありません。この場合、service は明確にユーザー名として解釈されます。一方で、/user/mikhail を使用すると、ユーザー mikhail とファイル (またはサブディレクトリ) /user/mikhail の区別がつきにくくなるため、user という名前のディレクトリは作成しないでください。

複合名の例

この項では、FNS ポリシーに従う名前の例を示します。これらのポリシーについては、表 25–26 を参照してください。

組織名、サイト名、ユーザー名、ホスト名、ファイル名、サービス名 (calendar や printer など) の名前は、例として使用されています。これらの名前は、FNS ポリシーでは指定されません。

組織に関連する名前を作成する

組織の名前空間 (_orgunit、orgunit、または org) に関連付けることのできる名前空間は、user、host、service、fs、と site です。

たとえば :

ユーザーに関連する名前を作成する

user の名前空間に関連付けることができる名前空間は、service および fs です。

ホストに関連する名前を作成する

hosts の名前空間に関連付けることができる名前空間は、service および fs です。

サイトに関連する名前を作成する

sites の名前空間に関連付けることができる名前空間は、service および fs です。

サービスおよびファイルに関連する名前を作成する

ファイル (fs) またはサービス (service) の名前空間に関連付けることができる名前空間はありません。たとえば、/services/calendar/orgunit/doc.com などの名前は作成できません。つまり、ファイルまたはサービスの名前空間に関連付けた複合名は作成できません。もちろん、/user/esperanza/service/calendar のように、他の名前空間に関連付けてファイル名またはサービス名を作成することは可能です。

エンタープライズ名前空間の構造

FNS ポリシーでは、エンタープライズ名前空間の構造が定義されます。この構造の目的は、統一性のある名前を簡単に作成することです。このエンタープライズ名前空間構造には、2 つの主要なルールがあります。

表 25–26 は、エンタープライズ名前空間を配列するための FNS ポリシーのまとめです。次の図は、これらの FNS ポリシーに準拠した名前空間の例です。

表 25–26 フェデレートされたエンタープライズ名前空間用のポリシー

名前空間識別子 

従属する名前空間 

親コンテキスト 

名前空間編成 

構文 

orgunit

_orgunit

org

サイト、ユーザー、ホスト、ファイルシステム、サービス 

エンタープライズのルート 

階層 

ドット区切り、右から左 

site

_site

サービス、ファイルシステム 

エンタープライズのルート、組織単位 

階層 

ドット区切り、右から左 

user

_user

サービス、ファイルシステム 

エンタープライズのルート、組織単位 

フラット 

Solaris ログイン名 

host

_host

サービス、ファイルシステム 

エンタープライズのルート、組織単位 

フラット 

Solaris ホスト名 

service

_service

アプリケーション固有 

エンタープライズのルート、組織単位、サイト、ユーザー、ホスト 

階層 

/ 区切り、左から右 

fs

 

_fs

なし 

エンタープライズのルート、組織単位、サイト、ユーザー、ホスト 

階層 

/ 区切り、左から右 

printer

なし 

サービス  

階層 

/ 区切り、左から右 

図 25–1 エンタープライズ名前空間の例

この図は、エンタープライズ名前空間の例を示しています。

エンタープライズの名前空間は、組織単位の周辺に構成されます。適切な名前空間識別子とオブジェクト名を使用して組織単位名を作成して、サイト、ホスト、ユーザー、ファイル、サービスの名前は、組織単位に関連付けてネーミングできます。

図 25–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 つがあります。

3 つのドットを使用してエンタープライズのルートを識別する

.../rootdomain/ を使用して、エンタープライズのルートを識別できます。

org// を使用してエンタープライズのルートを識別する

org// を使用して、エンタープライズのルートを識別できます。本質的に org// は、.../domainname/ に対する別名または機能的に相当するものです。org// を使用するときは、二重のスラッシュによって、ルートのエンタープライズコンテキストとそれに関連する名前空間が識別されます。

たとえば、org//site/alameda では、エンタープライズのルートに関連する Alameda サイトがネーミングされます。

反対に、org/ または orgunit/ (一重のスラッシュ) では、エンタープライズのルートに必ずしも相対的にネーミングされていない組織のコンテキストを示します。たとえば、org/sales/site/alameda のようになります。

エンタープライズのルートの従属するコンテキスト

次のオブジェクトは、エンタープライズのルートに関連付けてネーミングできます。

これらのオブジェクトは、ターゲットオブジェクトの名前でターゲットオブジェクトの名前空間の名前空間識別子を作成して、ネーミングします。

エンタープライズのルートと組織的なサブ単位

組織のサブ単位は、エンタープライズのルートに関連付けてネーミングできます。

組織ルート名の場合は、orgunit または _orgunit のどちらかの名前空間識別子を使用して、従属する組織単位コンテキストに名前を作成できます。

たとえば、.../doc.com がエンタープライズ名である場合、組織単位にネーミングするためのコンテキストのルートは、.../doc.com/orgunit/ であり、組織単位名は .../doc.com/orgunit/sales や .../doc.com/orgunit/west.sales のようになります。または、 org//orgunit/sales でも同じ結果を得ることができます。

次のオブジェクトは、組織単位名に関連付けてネーミングできます。

たとえば、名前 ...doc.com/orgunit/sales/service/calendar では、sales 組織単位のカレンダのサービスが識別されます。組織単位に関連付けてオブジェクトをネーミングする際の詳細については、組織単位の名前空間および 組織に関連する名前を作成するを参照してください。

エンタープライズのルートとサイト

サイトは、XFN ポリシーから拡張されています。

サイトは、次のものに関連付けてネーミングできます。

これらのオブジェクトは、ターゲットオブジェクトの名前空間とターゲットオブジェクト名の名前空間識別子でサイト名を作成して、ネーミングできます。たとえば、名前 site/Clark.bldg-5/service/calendar は、会議室 Clark.bldg-5 のカレンダのサービスでネーミングし、サイト名 site/Clark.bldg-5 とサービス名 service/calendar から作成されます。サイトに関連付けてオブジェクトにネーミングする際の詳細については、サイトに関連する名前を作成するを参照してください。

エンタープライズのルートとユーザー

ユーザーは、次のものに関連付けてネーミングできます。

これらのオブジェクトは、ターゲットオブジェクトの名前空間とターゲットオブジェクト名の名前空間識別子でユーザー名を作成して、ネーミングされます。たとえば、名前 user/sophia/service/calendar では、ユーザー sophia に対するカレンダがネーミングされます。ユーザーに関連付けてオブジェクトにネーミングする際の詳細については、ユーザーの名前空間および 、エンタープライズのルートとユーザーを参照してください。

エンタープライズのルートとホスト

ホストは、次のものに関連付けてネーミングできます。

これらのオブジェクトは、ターゲットオブジェクトの名前空間とターゲットオブジェクト名の名前空間識別子でホスト名を作成して、ネーミングされます。たとえば、名前 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

この他には、プリンタに従属するコンテキストのタイプはありません。

エンタープライズ内のネーミングに対する初期コンテキストの割り当て

初期コンテキストは、クライアントのユーザー、ホスト、およびアプリケーションがエンタープライズ名前空間の任意のオブジェクトに (結果的に) ネーミングできる開始点です。

次の図のネーミングシステムは、図 25–1 のネーミングシステムと同じです。ただし、初期コンテキストの割り当てが影付きになっており、斜体で示されています。これらの初期コンテキストは、解決する名前を決定するユーザー、ホスト、またはアプリケーションの観点から示されています。

図 25–2 初期コンテキストのエンタープライズ割り当ての例

この図は、初期コンテキストのエンタープライズ割り当ての例を示しています。

XFN では、「初期コンテキスト関数」の fn_ctx_handle_from_initial() が提供され、クライアントは初期コンテキストのオブジェクトを名前解決の開始点として得ることが可能になります。初期コンテキストには、名前空間識別子に対するフラットな名前空間があります。これらの初期コンテキスト識別子の割り当てについては表 25–27 に要約し、その後の節でさらに詳細に説明しています。これらの名前は、必ずしもすべての初期コンテキストに表示されるわけではありません。たとえば、スーパーユーザーがプログラムを起動したときには、ホストとクライアントに関連する割り当てのみが初期コンテキストに表示され、ユーザーに関連する割り当ては表示されません。

表 25–27 エンタープライズ内のネーミングに対する初期コンテキストの割り当て

名前空間識別子 

割り当て 

myself、_myself、thisuser

名前解決しようとするユーザーのコンテキスト 

myens、_myens

名前解決しようとするユーザーのエンタープライズの root 

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 (あるいは同義語の _myself または thisuser のどちらか) は、要求を行うユーザーのコンテキストで解決されます。ユーザー jsmith が所有するプロセスが名前解決を要求したときの例を示します。

myorgunit

FNS では、各ユーザーがエンタープライズの組織単位に関連するものと仮定されます。1 人のユーザーを複数の組織単位に関連させることはできますが、組織の名前空間での位置または組織内でのユーザーの役割によって、主な組織単位が必ず 1 つ必要です。

myens

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 (または _thishost) は、プロセス実行中のホストのホストコンテキストに割り当てられます。たとえば、プロセスがマシン cygnus で実行中である場合、thishost は cygnus のホストのコンテキストに割り当てられ、名前 thishost/service/calendar はマシン cygnus のカレンダのサービスを参照します。

thisorgunit

FNS では、ホストは組織単位に関連付けられていると仮定します。1 つのホストを複数の組織単位に関連付けることができますが、主となる組織単位が必要です。NIS+ 名前空間では、組織単位はホストのホームドメインに対応します。

名前空間識別子 thisorgunit (または _thisorgunit) は、プロセス実行中のホストの主要な組織単位に解決されます。たとえば、ホストがマシン cygnus であり、cygnus の NIS+ ホームドメインが west.sales である場合は、thisorgunit は west.sales として組織単位コンテキストで解決され、名前 thisorgunit/service/fax は組織単位 west.sales の FAX サービスを参照します。

thisens

FNS では、ホストがエンタープライズに関連するものと仮定されます。これは、thisorgunit を保持する名前空間に対応します。

名前空間識別子 thisens (または _thisens) は、プロセス実行中のホストのエンタープライズのルートで解決されます。たとえば、NIS+ で、ホストのホームドメインが sales.doc.com である場合、名前 thisens/site/ は doc.com. のサイトの名前空間のルートで解決されます。

短縮形の割り当て

FNS では、初期コンテキストにある次の短縮形割り当てを定義し、短い名前を使用して、共通に参照される特定の名前空間を参照できます。

user

名前空間識別子 user (または _user) は、プロセス実行中のホストの組織単位にある username コンテキストとして初期コンテキストに割り当てられます。これにより、同じ組織単位にいる他のユーザーをこのコンテキストからネーミングできます。

初期コンテキストから、名前 user および thisorgunit/user は同じコンテキストで解決されます。たとえば、プロセス実行中のホストがマシン altairであり、altair が east.sales 組織単位にある場合は、名前 user/medici で east.sales にいるユーザー medici がネーミングされます。

host

名前空間識別子 host (または _host) は、プロセス実行中のホストの組織単位にある hostname コンテキストとして初期コンテキストに割り当てられます。これにより、同じ組織単位にいる他のホストをこのコンテキストからネーミングできます。

初期コンテキストから、名前 host および thisorgunit/host は同じコンテキストで解決されます。たとえば、プロセス実行中のホストがマシン sirius であり、sirius が east.sales 組織単位にある場合は、名前 host/sirius で east.sales にあるマシン sirius がネーミングされます。

org

名前空間識別子 org (または orgunit、_orgunit) は、プロセス実行中のホストが所属するエンタープライズの組織のルートコンテキストとして初期コンテキストで割り当てられます。

初期コンテキストから、名前 org および thisens/orgunit は同じコンテキストで解決されます。たとえば、プロセス実行中のホストがマシン aldebaran であり、aldebaran がエンタープライズ doc.com にある場合は、名前 org/east.sales で doc.com. にある組織単位 east.sales がネーミングされます。

site

名前空間識別子 site (または _site) は、プロセス実行中のホストが所属するエンタープライズの最上位の組織単位のサイトネーミングシステムのルートに対する初期コンテキストに割り当てられます。

初期コンテキストから、名前 site および thisens/site は同じコンテキストで解決されます。たとえば、プロセス実行中のホストがマシン aldebaran であり、aldebaran がエンタープライズ doc.com にある場合は、名前 site/pine.bldg-5 で doc.com. の建物 5 にある会議室 pine がネーミングされます。

FNS およびエンタープライズのレベルのネーミング

FNS では、複数のネームサービスを 1 つの簡単なインタフェースを使用した基本的なネーミング操作でフェデレートすることができます。FNS は、NIS+、NIS、およびファイルという 3 つのエンタープライズレベルのネームサービスを操作できるように設計されています。また、FNS ポリシーの対象となるクライアントアプリケーション で説明するように、プリンタやカレンダサービスなどのアプリケーションも操作できます。

FNS ポリシーと NIS+ との関連

FNS では、NIS+ サーバー上のドメインレベルの org_dir NIS+ ディレクトリにある FNS テーブルに、エンタープライズのオブジェクトに対する割り当てが格納されます。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. で、サブドメインが sales.doc.com. の場合、次の名前の組み合わせは同じ組織を参照します。

表 25–28 NIS+ での相対および完全指定の組織名の例

相対名 

完全指定名 

org/ 

org/doc.com. 

org/sales 

org/sales.doc.com. 

manf. という名前だけを含む NIS+ ドメインは存在しないため、名前 org/manf. (ドット付き) はありません。

NIS+ ホストと FNS ホスト

NIS+ 名前空間のホストは、ホストのホームドメインの hosts.org_dir テーブルにあります。FNS 組織にあるホストは、対応する NIS+ ドメインの hosts.org_dir テーブル内のホストに対応します。FNS では、hosts テーブル内の各ホストにコンテキストが提供されます。

NIS+ ユーザーと FNS ユーザー

NIS+ 名前空間にいるユーザーは、ユーザーのホームドメインの passwd.org_dir テーブルのリストに入っています。FNS 組織にいるユーザーは、対応する NIS+ ドメインの passwd.org_dir テーブル内のユーザーに対応します。FNS では、passwd テーブル中の各ホストにコンテキストが提供されます。

NIS+ セキュリティと FNS

FNS の fncreate コマンドを使用して、コマンドが実行されたホストのドメインに関連付けられた NIS+ 階層に FNS テーブルとディレクトリを作成します。fncreate を実行するには、そのドメインの NIS+ オブジェクトの読み取り、作成、変更、削除を許可する資格を得て、認証された NIS+ 主体になる必要があります。fncreate で作成した FNS テーブルの「所有者」になります。この許可を得る 1 つの方法は、ドメインの管理者特権を持つ NIS+ グループのメンバーになることです。

fncreate を実行する前に、NIS_GROUP 環境変数をドメインに対する NIS+ 管理グループ名に設定する必要があります。個別のユーザーが、ユーザーに関連する FNS データを変更可能かどうかを指定できます。

FNS ポリシーと NIS の関連

FNS では、NIS マスターサーバー (および存在する場合は NIS スレーブサーバー) /var/yp/domainname ディレクトリにある FNS マップのエンタープライズオブジェクトへの割り当てが格納されます。FNS マップは、構造と機能の面で FNS マップと類似しています。これらの NIS マップでは、次のエンタープライズ名前空間に対する割り当てが格納されます。

FNS では、他のオブジェクトをこれら 5 つの名前空間に関連付けてネーミングするためのコンテキストが提供されます。

FNS の fncreate コマンドを使用して、NIS マスターサーバーの /var/yp/domainname ディレクトリに FNS マップを作成します。これは、NIS ネームサービスのマスターサーバーと同じマシンか、または FNS マスターサーバーとして機能する異なるマシンで行えます。スレーブサーバーが存在する場合は、NIS は、通常の処理の一部として FNS マップをそれらにプッシュします。fncreate を実行するには、FNS マップのホストとなるサーバーの特権ユーザーになる必要があります。各ユーザーは、FNS データを変更できません。

FNS ポリシーとファイルベースのネーミングの関連

FNS では、通常各マシンに NFS マウントされた /var/fn ディレクトリにあるファイル内のエンタープライズオブジェクトに対する割り当てが格納されます。これらの FNS ファイルでは、次のエンタープライズ名前空間に対する割り当てが格納されます。

FNS では、他のオブジェクトをこれら 5 つの名前空間に関連付けてネーミングするためのコンテキストが提供されます。

FNS の fncreate コマンドによって、コマンドが実行されるマシンの /var/fn ディレクトリに FNS ファイルを作成します。fncreate を実行するには、そのマシンでのスーパーユーザー特権を持つ必要があります。UNIX ユーザー ID に基づいて、各ユーザーは、FNS コマンドを使用して自身のコンテキスト、割り当て、属性を変更することが許可されます。

FNS ポリシーの対象となるクライアントアプリケーション

FNS ポリシーの 1 つの目的は、ファイルシステム、およびカレンダマネージャ、印刷ツール、ファイルマネージャ、メールツールなどの DeskSet ツール、またこれらのツールをサポートする RPC、電子メール、印刷サブシステムなどのサービスなどの、共通して使用されるツールに一貫性を持たせることです。

注 –

これらのツールの一部は、現在の Solaris オペレーティング環境 には実装されていません。ここでは、FNS の使用例を示すために挙げています。

アプリケーションの例 - カレンダサービス

ここでは、カレンダサービスというアプリケーションを変更して、FNS ポリシーを使用する方法について説明します。この例では、ユーザーから FNS 複合名が提示され、承認される手順を示します。

DeskSet のカレンダサービスは、一般的なクライアントサーバーアプリケーションです。カレンダサーバーは、複数のマシンで動作し、ユーザーのカレンダを保持します。カレンダマネージャ (cm) は、デスクトップで動作し、適切なサーバーにコンタクトして必要なカレンダを入手します。

カレンダサービスは、次のような簡単なレジストリまたは検索のモデルを使用して FNS を利用します。

前の例では、名前 calendar を使用して、カレンダの割り当てを示しています。RPC プログラムを RPC 管理者に登録するのと同じように、カレンダサービスの開発者は、名前 calendar を FNS 管理者に登録します。サービス名およびリファレンスの登録 を参照してください。

注 –

ここで使用した名前 calendar は 1 つの例です。FNS ポリシーによって、特定のサービス名が指定されるわけではありません。

カレンダサービスでは、カレンダをサイト、組織、およびホストに関連付け、一定の方法でそれらをネーミングして、FNS ポリシーをさらに利用できます。たとえば、カレンダを会議室 (サイト) と関連付け、ユーザーのカレンダのセットでその部屋の会議に利用可能な時間を見つけるのと同じように、サービスを使用して会議室のカレンダを多重表示できます。同様に、カレンダは、グループ会議の組織や、保守スケジュールを管理するホストに関連付けることができます。

カレンダマネージャ (cm) は、いくつかの簡単な手順に従って、ユーザーが指定する必要のあることを明確にします。

  1. cm では、ユーザーからの複合名を承認して、カレンダが要求されたオブジェクト名を構成するためのツールが使用されます。

    オブジェクトは、ユーザー、サイト、ホスト、または組織の名前になります。たとえば、ユーザーが名前 kuanda を入力すると、カレンダマネージャで複合名 user/kuanda が生成されます。このツールは、DeskSet アプリケーションのグループ間で共有できます。

  2. cm は、XFN インタフェースを使用して、接尾辞 /service/calendar を含む名前を作成し、カレンダ名を入手します。

  3. このカレンダ名は、プロセスの初期コンテキストに関連付けて解決されます。

    続いて、名前 user/kuanda/service/calendar が解決されます。同様に、ユーザーがサイト名 pine.bldg-5 を入力した場合は、cm で名前 site/pine.bldg-5/service/calendar が生成され解決されます。

    印刷やメールなどの他のサービスでも、類似の方法で FNS ポリシーを利用できます。

FNS ファイルシステム名前空間

FNS では、ファイル名はユーザー、ホスト、組織、サイトとの関係から設定できます。この場合実際には、オブジェクトの名前の後にエンタープライズの名前空間識別子 fs を指定し、その後にファイル名を指定します。たとえば、Sales 部門の、budget というファイルなら、org/sales/fs/budget/draft96という名前になります。

初期コンテキストは、ルートディレクトリの /xfn の下にあります。したがって、以下のように入力して参照できます。 


% more /xfn/org/sales/fs/budget/draft96

アプリケーションからこのディレクトリへアクセスする方法は、他のディレクトリの場合とまったく同様です。アプリケーションを修正したり、XFN API を使用したりする必要はありません。

NFS ファイルサーバー

NFS は Sun Microsystems, Inc. の製品で、分散ファイルシステムの一種です。オブジェクトのファイルは、通常１つ以上のリモート NFS ファイルサーバーにあります。最も単純なのは、エクスポートされた NFS ファイルシステムに名前空間識別子 fs が対応するという図 25–3 のような場合です。

図 25–3 NFS ファイルシステム - 単純な場合

この図は、単純な NFS ファイルシステムを示しています。

しかしオブジェクトのファイルシステムの中には、複数の (重なり合う場合もある) リモートマウントで構成され、FNS によって管理される仮想ディレクトリ構造にまとめられているものもあります。

図 25–4 は、この機能を使用して 3 つの異なるファイルサーバーをまとめて組織のファイルシステムを 1 つ作成している例です。project ディレクトリと lib サブディレクトリは同じファイルサーバー上に常駐していますが、src サブディレクトリの常駐先は別です。しかしユーザー、およびアプリケーションの側からは 1 つのシームレスな名前空間に見えるので、複数のサーバーを使用していることを意識する必要はありません。

図 25–4 NFS ファイルシステム - 複数サーバーで構成されている場合

この図は、複数サーバーで構成されている NFS ファイルシステムを示しています。

オートマウンタ

効率を上げるため、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

FNS プリンタの名前空間

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 クライアントの初期コンテキストに表示されます。名前「...」は、グローバル名が解決されるコンテキストに割り当てられます。

表 25–29 グローバルネーミングに対する初期コンテキスト割り当て

原子名 

割り当て 

...

DNS または X.500 の名前を解決するためのグローバルコンテキスト 

/ ...

3 つのドットの同義語 

グローバル名は、完全指定のインターネットドメイン名か、または X.500 の識別名になります。

DNS のフェデレーティング

完全指定の DNS 名は、必ずグローバルコンテキストで使用できます。DNS 名がグローバル名前空間で見つかると、リゾルバライブラリを使用して解決されます。リゾルバライブラリは、DNS 名前解決メカニズムです。一般的 DNS 名は、インターネットのホストアドレスまたは DNS ドメインレコードで解決されます。グローバルコンテキストで DNS 名が検出されると、名前は DNS リゾルバに引き渡されて解決されます。結果は、XFN リファレンス構造に変換され、要求者に返されます。

DNS ドメインの内容は、表示できます。しかし、表示操作は、インターネットでの連結性とセキュリティなどの実用上の理由によって限定されることもあります。たとえば、DNS ドメインのグローバルルート表示は、一般的にルート DNS サーバーではサポートされません。しかし、ルートの下にあるたいていのエンティティは、表示操作をサポートします。

DNS ホストおよびドメインは、DNS リソース名と関連付けられたネームサービス (NS) のリソースレコードの有無によって確認されます。

DNS は、端末以外のネーミングシステムのように機能し、他のネーミングシステムをフェデレートするために使用されます。

たとえば、エンタープライズネーミングシステムは、FNS 名 .../doc.com/ がそのエンタープライズの FNS 名前空間のルートを参照するような DNS にある doc.com に割り当てられます。

エンタープライズのネーミングシステムは、適切なテキスト (TXT) レコードをそのドメインの DNS マップに追加することにより、DNS ドメインに割り当てられます。そのドメインに対する FNS 名には後に続くスラッシュ (/) が含まれ、TXT リソースレコードは、エンタープライズのネーミングシステムへのリファレンスを構成するために使用されます。

DNS の一般的な情報については、in.named のマニュアルページか『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照してください。

X.500/LDAP のフェデレーティング

X.500 は、グローバルのディレクトリサービスです。ここでは、情報が格納され、情報を表示して検索する機能と同様に、名前で情報を検索する機能が提供されます。

X.500 の情報は、ディレクトリ情報ベース (DIB) に格納されます。DIB にあるエントリは、ツリー構造で配列されます。各エントリは名前付きオブジェクトで、定義された属性のセットを含んでいます。各属性には、定義済みの属性タイプと 1 つまたは複数の値があります。

エントリは、ルートから名前付きエントリまでのパスでツリー内の各エントリから選択された属性の連結である「識別名」によって明確に識別されます。たとえば、図 25–5 に示す DIB を使用すると、c=us/o=doc は、合衆国にある doc 組織の識別名となります。X.500 ディレクトリのユーザーは、DIB にあるエントリと属性を問い合わせたり、変更したりすることができます。

図 25–5 X.500 ディレクトリ情報ベースの例

この図は、X.500 ディレクトリ情報ベースの例を示しています。

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 つの結果が考えられます。

FNS の問題と対策

この節では、問題と共に、考えられる原因、診断、対策を示します。

FNS エラーメッセージの一般的な情報については、FNS エラーメッセージ を参照してください。

初期コンテキストが取得できない

「症状」

「Cannot obtain initial context」というメッセージが表示されます。

「考えられる原因」

インストール時の問題により発生します。

「診断」

/usr/lib/fn/fn_ctx_initial.so というファイルを検索し、FNS が正しくインストールされているかどうかを確認します。

「対策」

fn_ctx_initial.so ライブラリをインストールします。

初期コンテキストが空になっている

「症状」

fnlist を実行して初期コンテキストの内容を確認すると何も表示されないという状態です。

「考えられる原因」

NIS+ の設定によって発生する問題です。fn* コマンドを実行するユーザーやマシンに関連した組織に、ctx_dir ディレクトリがないことが原因です。

「診断」

nisls コマンドを使用して ctx_dir ディレクトリの有無を確認します。

「対策」

診断の結果 ctx_dir ディレクトリがなければ、fncreate -t org/nis+_domain_name/ を実行して作成します。

「No Permission」というメッセージが表示される (FNS)

「症状」

「no permission」というメッセージが表示されます。

「考えられる原因」

このメッセージは、「コマンドを実行しようとしたが、アクセス権がない」ということを意味します。

「診断」

適切な NIS+ コマンドを使用してアクセス権を確認します (FNS と NIS+ の詳細情報を参照)。NIS+ 主体名は、nisdefaults コマンドで知ることができます。

また、使用している名前が正しいかどうかも確認する必要があります。たとえば、ルート組織のコンテキスト名は、org// を使用して決定します。ルート組織を操作する権限があるかどうか確認してください。myorgunit/ を指定する場合もあります。

「対策」

アクセス権が正しく設定されているにもかかわらずこのメッセージが表示される場合は、適切な資格が与えられていない可能性があります。

これには以下の原因が考えられます。

/etc/nsswitch.conf ファイルに publickey: nisplus エントリがあるかどうか確認するこれはおそらく認証エラーとなる

fnlist で下位組織のリストが表示されない

「症状」

fnlist に組織名を指定して実行しても何も表示されません。

「考えられる原因」

NIS+ の設定によって発生する問題です。下位組織は NIS+ ドメインでなければなりません。NIS+ ドメインには、org_dir というサブディレクトリが必要です。

「診断」

nisls コマンドを使用して、どんなサブディレクトリが存在するかを調べます。nisls をサブディレクトリごとに実行すれば、どのサブディレクトリに org_dir があるかを確かめることができます。org_dir のあるサブディレクトリが下位組織になります。

「対策」

「考えられる原因」を参照してください。

ホストコンテキストまたはユーザーコンテキストが作成できない

「症状」

fncreate -t を、user (または username)、または host (または hostname) を指定して実行しても何も起こりません。

「考えられる原因」

NIS_GROUP 環境変数が設定されていません。ユーザーコンテキストあるいはホストコンテキストを作成した際、所有権が名前空間を設定した管理者ではなく、ホストまたはユーザーにあったようです。したがって、fncreate を実行するには、NIS_GROUP 変数を設定して、グループ内の管理者によってコンテキストの操作が行えるようにする必要があります。

「診断」

NIS_GROUP 環境変数をチェックします。

「対策」

NIS_GROUP 環境変数に、コンテキストの管理者のグループ名を設定します。

作成したコンテキストを削除できない

「症状」

ホストコンテキストまたはユーザーコンテキストに対して fndestroy を実行しても、コンテキストが削除されません。

「考えられる原因」

ホストコンテキストまたはユーザーコンテキストの所有権を持っていないことです。ユーザーコンテキストあるいはホストコンテキストを作成した際、所有権が名前空間を設定した管理者ではなく、ホストまたはユーザーにあったようです。

「診断」

NIS_GROUP 環境変数をチェックします。

「対策」

NIS_GROUP 環境変数に、コンテキストの管理者のグループ名を設定します。

fnunbind を実行すると「name in use」というメッセージが表示される

「症状」

割り当てを削除しようとすると、「name in use」というメッセージが表示されます。指定する名前によってコマンドが正しく実行される場合と、そうでない場合があります。

「考えられる原因」

コンテキストの名前の割り当てを解除できません。この制限は、名前のないコンテキスト (orphaned context) が残るような場合に適用されます。

「診断」

fnlist コマンドを実行して、fnbind、fncreate に指定しようとする名前がコンテキストのものかどうか確認します。

「対策」

名前がコンテキストのものであれば、fndestroy コマンドを使用してコンテキストを削除します。

fnbind/ fncreate -s を実行すると「name in use」というメッセージが表示される

「症状」

-s オプションをつけて fnbind および fncreate を実行すると、指定する名前によっては「name in use」というメッセージが表示されます。

「考えられる原因」

fnbind、および fncreate に -s オプションをつけて実行すると、既存の割り当ては上書きされます。ただしそれによって名前のないコンテキストができるような場合、「name in use」というエラーメッセージが表示され、この操作は失敗します。このエラーは、名前のないコンテキストを回避するために発生します。

「診断」

fnlist コマンドを実行して、fnbind、fncreate に指定しようとする名前がコンテキストのものかどうか確認します。

「対策」

fndestroy コマンドを実行してコンテキストを削除してから、fnbind または fncreate を (先にエラーになった場合と同じ名前を指定して) 実行します。

実体のない名前を指定して fndestroy/fnunbind を実行しても「Operation Failed」が返らない

「症状」

実体のない名前を指定して fndestroy、fnunbind を実行しても、操作が失敗したことがまったく知らされない。

「考えられる原因」

fndestroy、fnunbind のセマンティクスが、「端末名がバインドされていなくても、操作が success を返す」というようになっているためだと考えられます。

「診断」

問題が発生した場合と同じ名前を指定して fnlookup コマンドを実行します。「name not found」というメッセージが表示されるはずです。

「対策」

「考えられる原因」を参照してください。

その他の一般的なエラーメッセージ


attribute no permission

「呼び出し側が属性に対して何らかの操作をしようとしたが、アクセス権がないため実行できなかった」ということを意味します。


attribute value required

「値を指定しないで属性の作成が試みられたが、ネーミングシステムがそれを許可しなかった」ということを意味します。


authentication failure

「要求を作成した主体が、関連するネームサービスによって認証されなかったため、操作が完了しなかった」ということを意味します。NIS+ サービスを使用している場合は、(コマンド nisdefaults を使用して)「ユーザーが正しい主体として認識されているかどうか」を確認し、また「公開鍵のソースが、マシンに正しく指定されているか」を確認します (/etc/nsswitch.conf ファイルに publickey:nisplus というエントリがあるかどうかを確認する)。


bad reference

「FNS がリファレンスの内容を理解できなかった」ということを意味します。「リファレンスの内容が壊れている」、「FNS のものであるとされているリファレンスが、FNS で復号化できない」といった場合に発生します。


Cannot obtain Initial Context

インストールに問題があることを示します (初期コンテキストが取得できないを参照)。


communication failure

「FNS がネームサービスとコミュニケーションできず、操作を完了できなかった」ということを意味します。


configuration error

構成上の問題により発生するエラーです。次に例を示します。

(1) 割り当てテーブルが削除されました (FNS の問題ではありません)。

(2) ホストは NIS+ ホストディレクトリオブジェクトの中に存在しますが、ホストに対応する FNS ホストコンテキストがありません。


context not empty

「割り当てを含んでいるコンテキストを削除しようとした」ということを意味します。


continue operation using status values

「ステータスオブジェクトの中に残っている名前、名前との対応づけのできたリファレンスを使用して動作を続行する」ということを意味します。


error

「要求処理中に、ここまでにとりあげたどのエラーにも該当しない状況が発生した」ということを意味します。関連のあるネームサービスの状態をチェックし、特殊な問題が発生していないことを確認します。


illegal name

指定された名前が正しくないことを示します。


incompatible code sets

「操作中、互換性のないコードセットの文字列が使用された」、あるいは「サポートされていないコードセットが提供されている」ということを意味します。


invalid enumeration handle

「提供されている列挙ハンドルが正しくない」ということを意味します。「処理中に更新が発生した」などの理由が考えられます。


invalid syntax attributes

「指定された構文属性が正しくないために、構文を完全に決定できない」ということを意味します。


link error

指定された名前を使用して XFN リンクを作成する際に発生するエラーです。


malformed link

「fn_ctx_lookup_link() の動作中に、不正なリンク参照が検出された」ということを意味します。指定された名前が、リンクされていないリファレンスに結びつけられたということです。


name in use

「指定された名前が、コンテキスト中ですでに使用されている」ということを意味します。


name not found

指定された名前が見つからないということを意味します。


no permission

アクセス制御の問題により、動作が失敗したことを意味します。「No Permission」というメッセージが表示される (FNS)を参照してください。アクセス権がないも参照してください。


no such attribute

オブジェクトが、指定の属性を持たないことを意味します。


no supported address

「/usr/lib/fn ディレクトリに、(FNS の名前に結びつけられたリファレンス中にはいくつかのタイプのアドレスがあるが) どのタイプの共用ライブラリも存在しない」ということを意味します。共用ライブラリの名前は、fn_ctx_ address_type.so という形になります。 リンクは通常、「fn_ctx_address_type.so から fn_ctx_address_type.so.1 へ」という形で行われます。

たとえば、リファレンスのアドレスのタイプが onc_fn_nisplus だとすると、共用ライブラリの存在するパスは /usr/lib/fn/fn_ctx_onc_fn_nisplus.so ということになります。


not a context

「リファレンスが、正しいコンテキストに対応していない」ということを意味します。


partial result returned

操作によって得られた結果が不完全であることを意味します。


Success

(1) 要求は成功しました。このメッセージは、NIS+ のエラーコード定数 NIS_SUCCESS によって生成されます。 詳細については、nis_tables(3N) のマニュアルページを参照してください。

(2) 操作が成功しました。


syntax not supported

「サポートされていないタイプの構文が使用された」ということを意味します。


too many attribute values

「 1 つの属性に、ネーミングシステムでサポートされている範囲を超える数の値を持たせようとした」ということを意味します。


unavailable

操作に必要なネームサービスが利用できないということを意味します。


link loop limit reached

「複数の名前を結びつける際、XFN リンクが原因で完了しないループが検出された」、または「一回の操作における XFN のリンクの数が、実装で定義された上限を超えた」ということを意味します。