Solaris ネーミングの管理

パート V FNS の管理

パート V では、フェデレーテッド・ネーミング・サービス (FNS) とその管理方法について説明します。

第 20 章 FNS の手引き

この章では、FNS の概要、設定と構成の手順に関する簡単な説明、およびプログラミングの例を示します。熟練の管理者であれば、この章を読むだけで必要なことがすべてわかります。

詳細は、パート V「FNS の管理」の他の章を参照してください。FNS の初期設定と構成の詳細は、『Solaris ネーミングの設定と構成』を参照してください。

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

フェデレーテッド・ネーミング・サービス (FNS) は、ネーミングとディレクトリ操作のための 1 つの単純なインタフェースのもとに、複数のネームサービスをフェデレートする方法を提供します。FNS によってリンクできるネームサービスには、NIS+、NIS、ファイルベース、DNS、および X.500/LDAP があります。

XFN (X/Open Federated Naming)

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

FNS を使用する理由

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

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

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

複合名

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

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

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

コンテキスト

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

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

属性

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

各属性は、一意の属性識別子、属性構文、ゼロまたはいくつかの属性値の集合を持ちます。

XFN は、既存の名前付きオブジェクトに関連付けられた属性値を確認、変更するための基本属性インタフェースを定義します。これらのオブジェクトは、コンテキストまたは他の任意のタイプのオブジェクトにできます。コンテキストには、コンテキストによる合成名の構文解析方法を記述する構文属性が関連付けられます。

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

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

エンタープライズレベルのネームサービスは、あるエンタープライズ内のオブジェクトに名前を付けるために使用されます。FNS は現在、次の 3 つのレベルのネームサービスをサポートしています。

NIS+

NIS+ は、Solaris 8 リリース環境で推奨されるエンタープライズ規模の情報サービスです。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_fsfncreate_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 は、ネーミングポリシーを定義して、ユーザーとアプリケーションが共有名前空間に依存し、それを使用できるようにします。

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

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

表 20-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 root

orgunit site user host

組識名

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

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

サイト名

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

ユーザー名

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

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

ホスト名

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

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

サービス名

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

ファイル名

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

開始前に必要な処置

各自のネームサービスで 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_dirorg_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]
表 20-2 fnlist コマンドのオプション

オプション 

説明 

name

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

-v

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

-l

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

-A

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

次に例を示します。

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


% fnlist

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


% fnlist -v user

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


% fnlist user/pug/service

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


% fnlist -l -A

複合名の割り当ての表示

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


fnlookup [-vAL] [name]
表 20-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
表 20-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@altaironc_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
表 20-5 fncreate コマンドのオプション

オプション 

説明 

-t context

context タイプのコンテキストを作成する。context タイプは、orghostnamehostusernameuserservicefssitensidgeneric

-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

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

表 20-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
表 20-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 コマンドは、プリンタ colorcolor/inkjetcolor/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 コマンドは、空のコンテキストを削除するために使用されます。

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


# fndestroy user/patel/service

属性の処理

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

表 20-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+ を使って新しいコンテキストを作成できます。

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

表 20-9 fncopy コマンドのオプション

オプション 

説明 

-i oldservice

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

-o newservice

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

-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);

バインディングの作成

次の例は、バインディングの作成方法を示しています。


例 20-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);
 }

第 21 章 FNS の概要

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

XFN と FNS

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

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


注 -

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


XFN モデル

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

XFN アーキテクチャモデル

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

原子名

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

リファレンス

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

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


注 -

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


コンテキスト

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

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

Graphic

属性

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

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

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

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

合成名 (compound name)

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

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

次に例を示します。

複合名 (composite name)

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

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

sales.doc.com/usr/local/bin

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

FNS 名前空間

原子名とリファレンスアドレスは、1 つまたは複数の「名前空間」に対応して解決することもできます。デフォルトにより、FNS には、org (組織を示す)、sitehostuserservicefs (ファイルを示す) の 6 つの名前空間があります。

FNS のポリシーは、名前空間に関連する名前が相互に関連付け合う方法を決めるために使用されます。たとえば、あるユーザーが、ユーザー名前空間で sergei とネーミングされていて、/user/sergei と識別されるとします。カレンダアプリケーションは、サービス名前空間でネーミングされ、/service/calendar と識別されます。このシステムでは、sergei のカレンダサービスを /user/sergei/service/calendar と識別できます。名前空間とその使用方法の詳細は、「FNS および XFN のポリシーの概要」を参照してください。

あるアプリケーションでユーザー名の入力が必要な場合、そのアプリケーションでは、入力する名前の前に名前空間識別子 user/ を付けることができます。アプリケーションで、ユーザーのデフォルトのファックス機などのユーザーのサービスの 1 つをネーミングする必要がある場合は、入力された名前に service 名前空間とサービスの名前 (/service/fax) を追加できます。したがって、ファックスツールは、入力値として、ユーザー名 jacques をとり、ユーザー jacques のデフォルトファックスの完全指定名 user/jacques/service/fax を作成します。同様に、ユーザー名を入力するだけで、あるユーザーのカレンダにアクセスできます。アプリケーションは入力値 raj をとり、その値を使用して複合名を作成します。この場合は、user/raj/service/calendar です。

XFN リンク

XFN リンクは、コンテキスト内の原子名に割り当てられたリファレンスの特殊な形式です。リンクには、アドレスではなく複合名が含まれます。ネーミングシステムの多くは、そのネーミングシステム自体で使用可能なリンクという基本概念をサポートしています。XFN は、このような基本リンクと XFN リンクの間に何らかの関係があるかどうかを指定しません。

初期コンテキスト

XFN 名はすべていくつかのコンテキストに対応して解釈され、XFN ネーミング操作は、コンテキストオブジェクトに対して実行されます。「初期コンテキスト」オブジェクトは、複合名解決の開始地点となるものです。XFN インタフェースは、クライアントが初期コンテキストを獲得するための機能を提供します。

第 22 章「FNS ポリシー」で説明しているように、このコンテキストとそのバインドの意味を見つけるためにクライアントが必要とする名前の集合を指定します。これにより、別の XFN コンテキストを見つけることが可能となります。

ユーザーへの表示

ユーザーは、アプリケーションによりフェデレーテッド・ネーミングを利用できます。通常、ユーザーは、オブジェクトの完全複合名を作成する必要も、知る必要もありません。これは、アプリケーションが複合名の作成を行うためです。これにより、ユーザーは、XFN を認識するアプリケーションと、単純な一貫した方法で対話することができます。

ファイルシステムの表示

ユーザーとアプリケーションは、ファイルシステムによっても、フェデレーテッドネーミングを利用できます。初期コンテキストは、ルートディレクトリの /xfn に入っています。たとえば、ingridto_do ファイルの XFN 名が xfn/user/ingrid/fs/to_do だとします。

このファイルを読むには、次のように入力します。


% cat /xfn/user/ingrid/fs/to_do

アプリケーションは、他のファイルの場合と同様に、/xfn のもとにあるファイルにアクセスします。アプリケーションを変更する必要も、XFN API を使用する必要もありません。

アプリケーションの表示

次の一連の図は、クライアントアプリケーションが XFN と対話して異なるネーミングシステムにアクセスする方法を示します。図 21-2 は、XFN API とライブラリを使用するアプリケーションを示します。

図 21-2 クライアントアプリケーションと XFN との対話

Graphic

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

図 21-3 XFN API の詳細

Graphic

API 使用モデル

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

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

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

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

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

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

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

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

FNS と複合名

アプリケーションによっては、複合名を使用して、Solaris 環境のオブジェクトにアクセスするものがあります。コマンドの mailrcp は、このようなアプリケーションの一例です。

rcp は、sirius:/usr/jsmith/memo などの複合名を使用します。これは、ホスト名 sirius とファイル名 (パス) /usr/jsmith/memo の 2 つの構成要素からなります。mail プログラムは、jsmith@altair などの複合名を使用します。これは、ユーザ名 jsmith とホスト名 altair の 2 つの構成要素からなります。

各アプリケーションは、独自の名前作成規則を定義し、複合名を構文解析して、複合名を解決します。複合規則は、通常、アプリケーションごとに異なります。

FNS がない場合、ユーザーは、どのアプリケーションで複合ネーミングが可能であり、どれが可能でないかを覚えておく必要があります。たとえば、複合名 sirius:/tmp/saleslist は、rcp コマンドでは受け入れられますが、cp コマンドでは受け入れられません。

FNS がない場合、ユーザーは、アプリケーションごとに使用される異なる作成規則も覚えておく必要があります。独自の複合名をサポートするアプリケーションは、小さい特定のネーミングシステムしか使用できません。また、新しいタイプのネーミングシステムが追加されるたびに変更する必要があります。

複合ネーミングの一貫したポリシーを、コンピューティングプラットフォームに組み込むと、どのアプリケーションでも一貫した方法で複合名をサポートできます。アプリケーションは、1 つの名前を 1 つのインタフェースに渡します。

FNS ポリシーの原則

FNS ポリシーには、次の原則があります。

Solaris 環境での FNS

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

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

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

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

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

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

FNS と NIS+ のネーミング

NIS+ とその用語については、このマニュアルのパート I「ネーミングの紹介」と用語集を参照してください。典型的な NIS+ 環境の構造を理解しておくと有効です。

NIS+ は、Solaris 環境で推奨される組織規模の情報サービスです。NIS+ では、NIS とローカルファイルの両方を使用できます。NIS+ を使用すると、ドメインとサブドメインからなる階層組織レベルに組織を分割できます。

FNS 組織ユニットは、NIS+ のドメインとサブドメインに対応します。各ドメインとサブドメインに 1 つの orgunit コンテキストがあります。

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

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

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

FNS と NIS のネーミング

NIS は Solaris 環境でのエンタープライズ規模の情報サービスです。ローカルファイルは、NIS とともに使用できます。NIS のもとでは、エンタープライズは単一の NIS ドメインとして構成されます。

各エンタープライズは、単一の NIS ドメインです。1 つの NIS ドメインに対応して、1 つの FNS エンタープライズユニットがあります。

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

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

NIS クライアントが SKI の実行中 FNS によってコンテキストを更新する

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

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

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

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

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

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

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

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

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

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


注 -

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


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

FNS と DNS

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

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

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

FNS と X.500

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

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

FNS とアプリケーション

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

FNS ファイルネーミング

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

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

FNS プリンタネーミング

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

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

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

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

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

FNS の管理

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

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

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

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

第 22 章 FNS ポリシー

この章では、FNS ポリシーについて説明します。

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

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

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

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

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

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

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

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

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

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

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

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

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

図 22-1 は、エンタープライズの名前空間が配列される方法を示しています。

図 22-1 FNS ポリシーが配列するもの

Graphic

ユーザーやホストなどの名前空間には、フェデレートされた名前空間で複数回表示されるものもあります。

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

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

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

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

表 22-1 エンタープライズでのエンタープライズ名前空間の識別子

名前空間 

XFN 識別子 

FNS 識別子 

解釈処理 

組織 

_orgunit

orgunit または org

組織単位をネーミングするためのコンテキスト 

サイト 

_site

site

サイトをネーミングするためのコンテキスト 

ホスト 

_host

host

ホストをネーミングするためのコンテキスト 

ユーザー 

_user

user

ユーザーをネーミングするのためのコンテキスト 

ファイルシステム 

_fs

fs

ファイルをネーミングするためのコンテキスト 

サービス 

_service

service

サービスをネーミングするためのコンテキスト 

プリンタ 

 

printer

プリンタをネーミングするためのコンテキスト (サービスの名前空間に従属) 


注 -

XFN の用語では、先行する下線のある名前は、「正規」名前空間識別子です。下線のない名前は、Solaris 環境用に「カスタマイズ」された名前空間識別子です。これらのカスタマイズされた名前空間識別子に printer を追加しても、Solaris 以外の環境では認識されません。正規の名前空間識別子は、他の環境でも常に認識され、互換性があります。


構成要素の区切り文字

XFN 構成要素の区切り文字 (/) で、名前空間識別子を区切ります。たとえば、名前空間識別子 orgunit を組織単位名 west.sales とともに作成すると、複合名は orgunit/west.sales となります。

デフォルトの FNS 名前空間

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

組織単位の名前空間

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

NIS+ 環境

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

NIS+ では、組織単位は必ずドメインおよびサブドメインにマップされます。それぞれの NIS+ ドメインおよびサブドメインに組織単位を与える必要があります。ドメインまたはサブドメインに論理、組織ユニットを与えることはできません。つまり、NIS+ ドメインまたはサブドメインを小規模な組織単位に分割することはできません。そのため、NIS+ ドメイン doc.com. と 2 つのサブドメイン sales.doc.com. および manf.doc.com. がある場合は、これら 3 つのドメインに対応する 3 つの FNS 組織単位を持つ必要があります。

組織単位は、ドットで区切られた右から左への複合名を使用してネーミングされます。ここでは、各原子要素がより大きな単位内の組織単位をネーミングします。たとえば、org/sales.doc.com. という名前は、doc.com. という名前のより大きな単位内にある sales をネーミングします。この例では、sales は、doc.com. の NIS+ サブドメインです。

組織単位名は、完全指定の NIS+ ドメインまたは相対名の NIS+ 名のどちらかになります。完全指定名には終端にドットが付きますが、相対名には付きません。そのため、終端のドットが組織名にある場合は、その名前は完全指定の NIS+ ドメイン名として処理されます。終端にドットがない場合は、その組織名は最上部の組織階層に対して相対的に解釈処理されます。たとえば、orgunit/west.sales.doc.com. は、west 組織単位をネーミングする完全指定名で、_orgunit/west.sales は、同じサブドメインをネーミングする相対的な名前です。

NIS 環境

NIS 環境では、NIS ドメインに対応する組織単位は各エンタープライズ 1 つずつあります。この orgunit には、orgunit/domainname という名前が付けられ、ここでの domainname は NIS ドメイン名です。たとえば、NIS ドメイン名が doc.com である場合は、組織単位は org/doc.com です。

NIS 環境では、空の文字列を組織単位の省略形として使用できます。したがって、org// は、org/domainname に相当します。

ファイルベースの環境

エンタープライズレベルのネームサービスがファイルベースであるときには、1 つだけの FNS 組織単位が存在し、サブ単位はありません。ファイルベースのネーミングで許容される唯一の組織単位は org// です。

サイトの名前空間

サイトの名前空間では、物理的位置でそのまま識別される地域名前空間が提供されます。たとえば、これらのオブジェクトには、キャンパスにある建物、ある階のマシンやプリンタ、建物内の会議室とその使用スケジュール、隣接するオフィスにいるユーザーなどがあります。サイト名は、接頭辞 site/ または _site/ で識別されます。

Solaris 環境では、サイトは複合名を使用してネーミングされます。複合名では、各原子名がより大きなサイト内のサイトを表わします。サイト名の構文は、ドット区切りの右から左であり、もっとも一般的な位置記述からもっとも特定の位置記述に配列された構成要素が含まれます。たとえば、_site/pine.bldg5 は、建物 5 にある Pine 会議室を表わし、site/bldg7.alameda は、あるエンタープライズの Alameda にある建物 7 を表わします。

ホストの名前空間

ホストの名前空間では、コンピュータをネーミングするための名前空間が提供されます。ホスト名は、接頭辞 host/ または _host/ で識別されます。たとえば、host/deneb は、deneb という名前のマシンを識別します。

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

Solaris 環境では、ホスト名は Solaris のホスト名に対応します。単一のマシンに対する別名で同じコンテキストが共有されます。たとえば、mail_server という名前がマシン deneb および altair の別名である場合、denebaltair の両方で、mail_server に作成されたコンテキストが共有されます。

ネットワーク資源は、必要に応じてホストに関連付けてネーミングする必要があります。たいていの場合、組織、ユーザー、サイトなどの構成要素に関連して資源をネーミングした方がわかりやすくなります。ホスト名に依存すると、ユーザーは、あいまいで変更される可能性のある情報を覚えなくてはならなくなります。たとえば、ハードウェアの変更、ファイルスペースの使用、ネットワークの再構成などのために、ユーザーのファイルがあるサーバーから他のサーバーに移動されてしまう場合もあります。さらに、ユーザーは、同じファイルサーバーを共有することが多くなり、ファイルがホストに関連付けてネーミングされた場合に混乱を招きます。しかし、ファイルがユーザーに関連付けてネーミングされた場合は、このような変更はファイルのネーミング方法に影響しません。

ホスト名を使用した方が適切な場合もあります。たとえば、資源が特定のマシンだけで使用可能であり、他の構成要素に関連付けてその資源をネーミングする論理的方法がない場合には、ホストに関連付けてネーミングする意味があります。または、ファイルシステムでは、ファイルが多くのユーザーに共有されている場合、格納されているマシンに関連付けてファイルをネーミングする意味があります。

ユーザーの名前空間

ユーザーの名前空間では、コンピュータ環境内のユーザーをネーミングするための名前空間が提供されます。ユーザー名は、接頭辞 user/ または _user/ で識別されます。

ユーザーは、「ユーザーコンテキスト」でネーミングされます。ユーザーコンテキストには、単一レベルの名前空間があり、「ユーザーコンテキスト」へのユーザー名のバインドが含まれます。ユーザーコンテキストでは、ユーザーに関連するファイル、サービス、資源などのオブジェクトをユーザーに関連付けてネーミングすることができます。

Solaris 環境では、ユーザー名は Solaris ログイン ID に対応します。たとえば、_user/inga は、ログイン ID が inga のユーザーを識別します。

ファイルの名前空間

ファイルの名前空間 (またはファイルシステム) では、ファイルをネーミングするための名前空間が提供されます。ファイル名は、接頭辞 fs/ または _fs/ で識別されます。たとえば、fs/etc/motd という名前では、/etc ディレクトリに格納されているファイル motd が識別されます。

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

サービスの名前空間

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

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

FNS は、サービス名またはリファレンスタイプが選択される方法を指定します。これらは、サービスの名前空間を共有するサービス提供者によって決定されます。たとえば、カレンダサービスは、サービスのコンテキストにある名前 _service/calendar を使用してカレンダサービスをネーミングし、名前 calendar にバインドされたものを決定します。

サービス名およびリファレンスの登録

米国 Sun Microsystems, Inc. は、service の名前空間の最初のレベルにある名前の登録を行います。新規名を登録するには、電子メールのリクエストを fns-register@sun.com まで送信するか、または書面で次の住所までご郵送ください。


FNS Registration
Sun Microsystems, Inc.
901 San Antonio Road.
Palo Alto, CA 94303
U.S.A.

名前の使用目的についての簡単な説明と、その名前にバインドされるリファレンスのフォーマットの説明をお書き添えください。

プリンタの名前空間

プリンタの名前空間では、プリンタをネーミングするための名前空間が提供されます。プリンタの名前空間は、サービスの名前空間に関連 (従属) します。つまり、プリンタのサービスは、サービスの名前空間のサービスの一部です。プリンタ名は、接頭辞 service/printer または _service/printer で識別されます。たとえば、service/printer/laser1 では、laser1 という名前のプリンタが識別されます。

後続スラッシュの意味

後続の / は、次のネーミングシステムにあるオブジェクトをネーミングします。あるネーミングシステムから他のネーミングシステムに移動するときに必ず必要となります。たとえば、名前 org/east.sales/service/printer では、orgeast.sales の間のスラッシュは、上で説明した構成要素の区切り文字であり、組織名 (sales/) の最後の要素に続くスラッシュは、service 名前空間を組織単位名前空間から区切ります。したがって、org/west.sales/service/printer では、west.sales という組織単位の printer サービスがネーミングされます。

FNS 予約名

FNS は、表 22-1 に挙げたすべての原子名をそれ自身の使用のために名前空間識別子として獲保します。たとえば、_orgunitorg_sitesite などです。この制限事項は、「エンタープライズ名前空間の構造」にある名前空間の配列で定義されているように、名前空間識別子が現れるコンテキストに適用されます。それ以外の場合は、FNS は、他のコンテキストではこれらの原子名の使用を制限します。

たとえば、原子名 service は、user/fatima/service/calendar のように、ユーザー名に相対的な名前空間識別子として使用され、ユーザー fatima のサービスの名前空間のルートであることを意味します。FNS では、名前 user/ がバインドされるコンテキストは、名前空間識別子にではなく、ユーザー名に指定されるため、user/service のようにユーザー名として名前 service を使用することが禁止されるわけではありません。この場合、service は明確にユーザー名として解釈されます。一方で、/user/mikhail を使用すると、ユーザー mikhail とファイル (またはサブディレクトリ) /user/mikhail の区別がつきにくくなるため、user という名前のディレクトリは作成しないでください。

複合名の例

この項では、FNS ポリシーに従う名前の例を示します。これらのポリシーについては、表 22-2 を参照してください。

組織名、サイト名、ユーザー名、ホスト名、ファイル名、サービス名 (calendarprinter など) の名前は、例として使用されています。これらの名前は、FNS ポリシーでは指定されません。

組織に関連する名前を作成する

組織の名前空間 (_orgunitorgunit、または org) に関連付けることのできる名前空間は、userhostservicefs、と site です。

以下に例を示します。

ユーザーに関連する名前を作成する

user の名前空間に関連付けることができる名前空間は、service および fs です。

ホストに関連する名前を作成する

hosts の名前空間に関連付けることができる名前空間は、service および fs です。

サイトに関連する名前を作成する

sites の名前空間に関連付けることができる名前空間は、service および fs です。

サービスおよびファイルに関連する名前を作成する

ファイル (fs) またはサービス (service) の名前空間に関連付けることができる名前空間はありません。たとえば、/services/calendar/orgunit/doc.com などの名前は作成できません。つまり、ファイルまたはサービスの名前空間に関連付けた複合名は作成できません。もちろん、/user/esperanza/service/calendar のように、他の名前空間に関連付けてファイル名またはサービス名を作成することは可能です。

エンタープライズ名前空間の構造

FNS ポリシーでは、エンタープライズ名前空間の構造が定義されます。この構造の目的は、統一性のある名前を簡単に作成することです。このエンタープライズ名前空間構造には、2 つの主要なルールがあります。

表 22-2 は、エンタープライズ名前空間を配列するための FNS ポリシーのまとめです。図 22-2 に、これらの FNS ポリシーに従う名前空間の配置の例を示します。

表 22-2 フェデレートされたエンタープライズ名前空間用のポリシー

名前空間 

識別子 

従属する名前空間 

親コンテキスト 

名前空間編成 

構文 

orgunit

_orgunit

org

サイト、ユーザー、ホスト、ファイルシステム、サービス 

エンタープライズのルート 

階層 

ドット区切り、右から左 

site

_site

サービス、ファイルシステム 

エンタープライズのルート、組織単位 

階層 

ドット区切り、右から左 

user

_user

サービス、ファイルシステム 

エンタープライズのルート、組織単位 

フラット 

Solaris ログイン名 

host

_host

サービス、ファイルシステム 

エンタープライズのルート、組織単位 

フラット 

Solaris ホスト名 

service

_service

アプリケーション固有 

エンタープライズのルート、組織単位、サイト、ユーザー、ホスト 

階層 

/ 区切り、左から右 

fs

 

_fs

なし 

エンタープライズのルート、組織単位、サイト、ユーザー、ホスト 

階層 

/ 区切り、左から右 

printer

なし 

サービス 

階層 

/ 区切り、左から右 

図 22-2 エンタープライズ名前空間の例

Graphic

エンタープライズの名前空間は、組織単位の周辺に構成されます。適切な名前空間識別子とオブジェクト名を使用して組織単位名を作成して、サイト、ホスト、ユーザー、ファイル、サービスの名前は、組織単位に関連付けてネーミングできます。

図 22-2 では、エンタープライズの sales 組織の西部事業部のユーザー myoko は、名前 orgunit/west.sales/user/myoko を使用してネーミングされます。

名前空間識別子 user を使用して、orgunit 名前空間から user 名前空間への移行を表していることに注意してください。同様に (適切な名前空間識別子を使用して)、ファイル名およびサービス名も、サイト、ユーザー、またはホストの名前に関連付けてネーミングできます。サイト名は、組織単位名に関連付けてネーミングできます。

簡単に均質な名前を作成することは、この構造を使用して達成されます。たとえば、エンタープライズ (orgunit/west) 内の組織単位名が分かれば、user の名前空間識別子とユーザーのログイン名で名前を作成して orgunit/west/user/josepha などの名前を作成し、エンタープライズに関連付けてユーザーをネーミングできます。

このユーザーのファイルシステムにあるファイルをネーミングするときには、orgunit/west/user/josepha/fs/notes などの名前を使用できます。

エンタープライズのルート

エンタープライズのルートコンテキストは、エンタープライズ名前空間のルートレベルにあるオブジェクトをネーミングするためのコンテキストです。エンタープライズのルートは、グローバルの名前空間でバインドされます。

エンタープライズのルートをネーミングする方法には、次の 2 つがあります。

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 でも同じ結果を得ることができます。

次のオブジェクトは、組織単位名に関連付けてネーミングできます。

エンタープライズのルートとサイト

サイトは、XFN ポリシーから拡張されています。

サイトは、次のものに関連付けてネーミングできます。

エンタープライズのルートとユーザー

ユーザーは、次のものに関連付けてネーミングできます。

エンタープライズのルートとホスト

ホストは、次のものに関連付けてネーミングできます。

エンタープライズのルートとサービス

サービスは、次のものに関連付けてネーミングできます。

エンタープライズのルートとファイル

ファイルの名前空間は、次のものに関連付けてネーミングできます。

エンタープライズのルートとプリンタ

プリンタのコンテキストは、XFN ポリシーの拡張です。

プリンタの名前空間は、サービスのコンテキストでネーミングできます。プリンタのコンテキストは、名前空間識別子の printer を使用して、次のものに関連したサービスのコンテキストでネーミングされます。

エンタープライズ内のネーミングに対する初期コンテキストのバインド

初期コンテキストは、クライアントのユーザー、ホスト、およびアプリケーションがエンタープライズ名前空間の任意のオブジェクトに (結果的に) ネーミングできる開始点です。

図 22-3 に示すネーミングシステムは、初期コンテキストのバインドが影付きでイタリックになっている点を除いて図 22-2 に挙げたネーミングシステムと同一です。これらの初期コンテキストは、解決する名前を決定するユーザー、ホスト、またはアプリケーションの観点から示されています。

図 22-3 初期コンテキストのエンタープライズバインドの例

Graphic

XFN では、「初期コンテキスト関数」の fn_ctx_handle_from_initial() が提供され、クライアントは初期コンテキストのオブジェクトを名前解決の開始点として得ることが可能になります。初期コンテキストには、名前空間識別子に対するフラットな名前空間があります。これらの初期コンテキスト識別子のバインドについては表 22-3 に要約し、その後の節でさらに詳細に説明しています。これらの名前は、必ずしもすべての初期コンテキストに表示されるわけではありません。たとえば、スーパーユーザーがプログラムを起動したときには、ホストとクライアントに関連するバインドのみが初期コンテキストに表示され、ユーザーに関連するバインドは表示されません。

表 22-3 エンタープライズ内のネーミングに対する初期コンテキストのバインド

名前空間 

識別子 

バインド 

myself, _myself, thisuser

名前解決しようとするユーザーのコンテキスト 

myens, _myens

名前解決しようとするユーザーのエンタープライズのルート 

myorgunit, _myorgunit

ユーザーの主要な組織単位のコンテキスト。たとえば、NIS+ 環境では、主組織単位はユーザーの NIS+ ホームドメインとなる 

thishost, _thishost

名前解決しようとするホストのコンテキスト 

thisens, _thisens

名前解決しようとするホストのエンタープライズのルート 

thisorgunit, _thisorgunit

ホストの主要な組織単位のコンテキスト。たとえば、NIS+ 環境では、主組織単位はホストの NIS+ ホームドメインとなる 

user, _user

ホストと同じ組織単位にいるユーザーがネーミングされるコンテキスト 

host, _host

ホストと同じ組織単位にいるホストがネーミングされるコンテキスト 

org, orgunit, _orgunit

ホストのエンタープライズにある組織単位の名前空間のルートコンテキスト。たとえば、NIS+ 環境では、これは NIS+ ルートドメインに対応する 

site, _site

サイトの名前空間が構成された場合、最上位の組織単位にあるサイトの名前空間のルートコンテキスト 

XFN 用語では、接頭辞として使用される下線は、「正規」名前空間識別子と呼ばれます。この下線がなく、org および thisuser が追加された名前は、Solaris 用にカスタマイズされた名前です。Solaris カスタマイズの名前空間識別子は、他の Solaris 以外の環境で認識されるとは限りません。正規名前空間識別子は、他の環境でも必ず認識されるため移植性があります。


注 -

現在実装されている FNS では、初期コンテキストにある名前およびバインドの追加や修正はサポートされません。


初期コンテキストのバインドは、基本的に次の 3 つに分けられます。

ユーザーに関連するバインド

FNS では、XFN 初期コンテキスト関数が呼び出されたときに、プロセスに関連付けられたユーザーが存在するものと仮定されます。この関連付けは、プロセスの実効ユーザー ID (euid) に基づいています。プロセスに対するユーザーの関連付けがプロセスの途中で変更されることはありますが、元のコンテキストハンドルは変更されません。

FNS では、名前解決を要求するユーザーに関連する初期コンテキストにある次のバインドが定義されます。

myself

初期コンテキストにある名前空間識別子 myself (あるいは同義語の _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 で実行中である場合、thishostcygnus のホストのコンテキストにバインドされ、名前 thishost/service/calendar はマシン cygnus のカレンダのサービスを参照します。

thisorgunit

FNS では、ホストは組織単位に関連付けられていると仮定します。1 つのホストを複数の組織単位に関連付けることができますが、主となる組織単位が必要です。NIS+ 名前空間では、組織単位はホストのホームドメインに対応します。

名前空間識別子 thisorgunit (または _thisorgunit) は、プロセス実行中のホストの主要な組織単位に解決されます。たとえば、ホストがマシン cygnus であり、cygnus の NIS+ ホームドメインが west.sales である場合は、thisorgunitwest.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であり、altaireast.sales 組織単位にある場合は、名前 user/medicieast.sales にいるユーザー medici がネーミングされます。

host

名前空間識別子 host (または _host) は、プロセス実行中のホストの組織単位にある hostname コンテキストとして初期コンテキストにバインドされます。これにより、同じ組織単位にいる他のホストをこのコンテキストからネーミングできます。

初期コンテキストから、名前 host および thisorgunit/host は同じコンテキストで解決されます。たとえば、プロセス実行中のホストがマシン sirius であり、sirius が east.sales 組織単位にある場合は、名前 host/siriuseast.sales にあるマシン sirius がネーミングされます。

org

名前空間識別子 org (または orgunit、_orgunit) は、プロセス実行中のホストが所属するエンタープライズの組織のルートコンテキストとして初期コンテキストでバインドされます。

初期コンテキストから、名前 org および thisens/orgunit は同じコンテキストで解決されます。たとえば、プロセス実行中のホストがマシン aldebaran であり、aldebaran がエンタープライズ doc.com にある場合は、名前 org/east.salesdoc.com. にある組織単位 east.sales がネーミングされます。

site

名前空間識別子 site (または _site) は、プロセス実行中のホストが所属するエンタープライズの最上位の組織単位のサイトネーミングシステムのルートに対する初期コンテキストにバインドされます。

初期コンテキストから、名前 site および thisens/site は同じコンテキストで解決されます。たとえば、プロセス実行中のホストがマシン aldebaran であり、aldebaran がエンタープライズ doc.com にある場合は、名前 site/pine.bldg-5doc.com. の建物 5 にある会議室 pine がネーミングされます。

FNS およびエンタープライズのレベルのネーミング

FNS では、基本ネーミング操作の単一の簡単なインタフェースで、複数のネームサービスをフェデレートする方法が提供されます。FNS は、次の 3 つのエンタープライズレベルのネームサービスで機能するように設計されています。

FNS ポリシーと NIS+ との関連

FNS および NIS+ に関連する内容説明の概要については、「FNS と NIS+ のネーミング」を参照してください。NIS+ およびその用語を調べる場合は、このマニュアルのパート I「ネーミングの紹介」および用語集を参照してください。一般的な 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. であり、サブドメイン ales.doc.com. を含む場合は、次の名前で同じ組織が参照されます。

表 22-4 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 データを変更可能かどうかを指定できます。

NIS+ セキュリティの説明については、第 6 章「セキュリティの概要」を参照してください。

FNS ポリシーと NIS の関連

FNS および NIS に関連する概要と内容説明については、「FNS と NIS のネーミング」を参照してください。

FNS では、NIS をネームサービスとして使用する基本的なネーミングおよび属性の操作用に XFN インタフェースが提供されます。

FNS では、NIS マスターサーバー (および存在する場合は NIS スレーブサーバー) /var/yp/domainname ディレクトリにある FNS マップのエンタープライズオブジェクトへのバインドが格納されます。FNS マップは、構造と機能の面で FNS マップと類似しています。これらの NIS マップでは、次のエンタープライズ名前空間に対するバインドが格納されます。

FNS ポリシーとファイルベースのネーミングの関連

FNS とファイルに関連する概要および内容説明については、「FNS とファイルベースのネーミング」を参照してください。

FNS では、ローカルのファイルをネームサービスとして使用する基本的なネーミングおよび属性の操作用に XFN インタフェースが提供されます。

FNS では、通常各マシンに NFS マウントされた /var/fn ディレクトリにあるファイル内のエンタープライズオブジェクトに対するバインドが格納されます。これらの FNS ファイルでは、次のエンタープライズ名前空間に対するバインドが格納されます。

FNS ポリシーの対象となるクライアントアプリケーション

FNS ポリシーの 1 つの目的は、ファイルシステム、およびカレンダマネージャ、印刷ツール、ファイルマネージャ、メールツールなどの DeskSet ツール、またこれらのツールをサポートする RPC、電子メール、印刷サブシステムなどのサービスなどの、共通して使用されるツールに一貫性を持たせることです。


注 -

これらの例のいくつかは、現在 Solaris 環境には導入されていませんが、FNS の使用方法を示すためにここに挙げます。


アプリケーションの例 - カレンダサービス

ここでは、カレンダサービスというアプリケーションを変更して、FNS ポリシーを使用する方法について説明します。この例では、ユーザーから FNS 複合名が提示され、承認される手順を示します。

DeskSet のカレンダサービスは、一般的なクライアントサーバーアプリケーションです。カレンダサーバーは、複数のマシンで動作し、ユーザーのカレンダを保持します。カレンダマネージャ (cm) は、デスクトップで動作し、適切なサーバーにコンタクトして必要なカレンダを入手します。

カレンダサービスは、次のような簡単なレジストリまたは検索のモデルを使用して FNS を利用します。

  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. の製品で、分散ファイルシステムの一種です。オブジェクトのファイルは、通常1つ以上のリモート NFS ファイルサーバーにあります。最も単純なのは、エクスポートされた NFS ファイルシステムに名前空間識別子 fs が対応するという図 22-4 のような場合です。

図 22-4 NFS ファイルシステム - 単純な場合

Graphic

しかしオブジェクトのファイルシステムの中には、複数の (重なり合う場合もある) リモートマウントで構成され、FNS によって管理される仮想ディレクトリ構造にまとめられているものもあります。

図 22-5 は、3 つの異なるファイルサーバーをまとめて、組織のファイルシステムを 1 つ作成している例です。project ディレクトリと lib サブディレクトリは同じファイルサーバー上に常駐していますが、src サブディレクトリの常駐先は別です。しかしユーザー、およびアプリケーションの側からは 1 つのシームレスな名前空間に見えるので、複数のサーバーを使用していることを意識する必要はありません。

図 22-5 NFS ファイルシステム - 複数サーバーで構成されている場合

Graphic

オートマウンタ

効率を上げるため、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 クライアントの初期コンテキストに表示されます。原子名「...」は、グローバル名が解決されるコンテキストにバインドされます。

表 22-5 グローバルネーミングに対する初期コンテキストバインド

原子名 

バインド 

. ..

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(1M) のマニュアルページか、または『Solaris ネーミングの設定と構成』の DNS についての章を参照してください。

X.500/LDAP のフェデレーティング

X.500 は、グローバルのディレクトリサービスです。ここでは、情報が格納され、情報を表示して検索する機能と同様に、名前で情報を検索する機能が提供されます。

X.500 の情報は、ディレクトリ情報ベース (DIB) に格納されます。DIB にあるエントリは、ツリー構造で配列されます。各エントリは名前付きオブジェクトで、定義された属性のセットを含んでいます。各属性には、定義済みの属性タイプと 1 つまたは複数の値があります。

エントリは、ルートから名前付きエントリまでのパスでツリー内の各エントリから選択された属性の連結である「識別名」によって明確に識別されます。たとえば、図 22-6 に示す DIB を使用すると、c=us/o=doc は、合衆国にある doc 組織の識別名となります。X.500 ディレクトリのユーザーは、DIB にあるエントリと属性を問い合わせたり、変更したりすることができます。

図 22-6 X.500 ディレクトリ情報ベースの例

Graphic

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 つの結果が考えられます。

第 23 章 FNS とエンタープライズのネームサービス

この章では、FNS およびエンタープライズレベルのネームサービスの管理について説明します。

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

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

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

Solaris ネーミングの設定と構成』で説明している fncreate コマンドで FNS 名前空間を初期設定して構成するときには、正しいデフォルトのネームサービスが自動的に各マシンに選択されます。

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

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

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

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

FNS と Solstice AdminSuite

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

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

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

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

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


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

オプション 

説明 

domain

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

-t

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

-s

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

-r

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

-u

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

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

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

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

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

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

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


fnselect [-D] [namesvc]
表 23-2 fnselect コマンドオプション

オプション 

説明  

namesvc

選択するネームサービス。必ず次のどれかになる。defaultnisplusnis または 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 オブジェクトのアクセス制御を変更するときに有効です。

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

次を参照してください。

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

FNS コンテキストは、NIS+ オブジェクトに格納されます。組織に関連するすべてのコンテキストは、関連する NIS+ ドメインの ctx_dir ディレクトリに格納されます。ctx_dir ディレクトリは、同じドメインの org_dir と同じレベルにあります。すなわち、FNS と同時に実行される時には、それぞれの NIS+ ドメインまたはサブドメインには対応する org_dirgroups_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.ctxfns_user.ctx、および fns_org.ctx のマップに格納されます。プリンタのコンテキスト情報は、他のサービスのコンテキスト情報と同じマップに格納されます。しかし、古い printers.conf.byname マップはここでもサポートされます。

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


注 -

これらの FNS マップは、直接編集しないでください。fncreatefndestroyfnbindfnunbindfnrenamefnattrfnlookup、および 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 
表 23-3 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.ctxfns_user.ctx、および fns_org.ctx のファイルに格納されます。プリンタのコンテキスト情報は、他のサービスのコンテキスト情報と同じファイルに格納されます。

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


注 -

これらの FNS マップは、直接編集しないでください。fncreate fndestroyfnbindfnunbindfnrenamefnattrfnlookup、および 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 マップは変更されません。

第 24 章 エンタープライズレベルのコンテキスト

この章では、すでに存在しているエンタープライズレベルのコンテキストを、個別に作成、管理する方法について説明します。

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

FNS コンテキストは、fncreate コマンドを使用して作成します。この節では、『Solaris ネーミングの設定と構成』に説明されているような組織全体の FNS コンテキストではなく、個別に FNS コンテキストを作成する方法について説明します。fncreate コマンドは、指定されたタイプのコンテキストを作成し、そのコンテキストを任意の複合名とバインドします。また、コンテキストのサブコンテキストを作成することもできます。

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


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

オプション 

説明 

-t context

作成するコンテキストのタイプを指定する。context には、orghostnameusernamehostuserservicesitensidgenericfs のうちいずれかを使用する

-f

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

-o

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

-r

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

-s

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

-D

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

-v

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


注 -

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


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

たとえば、以下のコマンドでは、org/sales/user のコンテキストが作成され、org/sales/_userorg/sales/user のコンテキストのリファレンスにバインドされます。


fncreate -t username 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/ の組織コンテキストが作成されると同時に、サブコンテキストとして hostnameusernameservice が作成されます。また 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 コンテキストだけが作成されます。hostnameusernameservice のコンテキストは作成されますが、host コンテキストと user コンテキストの生成はされません。

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


rootmaster# setenv NIS_GROUP fns_admins.doc.com 

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

fncreatehostname をコンテキストのタイプとして指定すると 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 台のホストのコンテキスト

fncreatehost をコンテキストのタイプとして指定すると、ホストのコンテキストとサブコンテキストが作成されます。-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 には、別名を持つホストが存在することもあります。この種のホストは、テーブル中では「1つの正式名にいくつかの別名が対応づけられている」という形で表されます。

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

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

fncreateusername をコンテキストのタイプとして指定すると、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 人のユーザーのコンテキスト

fncreateuser をコンテキストタイプとして指定すると、ユーザーの 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/calendarorg/sales/service/fax といった名前をこのサービスコンテキストでバインドできます。

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


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

さらにこの下には、org/sales/service/plotter/speedyorg/sales/service/plotter/color といった名前をバインドできます。


注 -

ただし、末尾の名前が名前空間識別子ではないので、service_service のようなバインドが行われることはありません。


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

プリンタコンテキスト

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

汎用コンテキスト

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

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

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

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


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

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

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


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

さらにこの下には、org/sales/service/extcomm/modem/secureorg/sales/service/extcomm/modem/public といった名前をバインドできます。

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

Site コンテキスト

site コンテキストでは、サイト名のバインドが行えます。

site コンテキストを作成するには、以下のようなコマンドを使用します。


# fncreate -t site org/sales/site/

ここでは末尾の名前 (site) が名前空間識別子なので、org/sales/site/ のリファレンスに org/sales/_site/ がバインドされます。

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

たとえば、site コンテキスト alameda と、site サブコンテキスト alameda.bldg-5 を作成するには、以下のコマンドを使用します。


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

注 -

ただし末尾の名前が名前空間識別子ではないので、site_site の場合のようなバインドが行われることはありません。


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

ファイルのコンテキスト

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


# fncreate -t fs org/sales/user/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 = 名前空間識別子) タイプのコンテキストでは、名前空間識別子がバインドできます。

たとえば、以下のコマンドでは、サイト alameda.bldg-5 コンテキストが作成され、service/ などサブコンテキストが作成できるようになります。


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

この場合以下のコマンドを実行すると、alameda.bldg-5service コンテキストが作成できます。


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

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

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

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

バインドに関する情報を表示する

fnlookup は、複合名のバインドに関する情報を表示するのに使用します。


fnlookup [-v][-L] composite_name
表 24-2 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.Darwinuser/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]
表 24-3 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
表 24-4 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}+
表 24-5 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/

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

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

この章では、アプリケーション固有のコンテキストをどのように管理するかについて説明します。

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

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

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-1 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 に割り当てられます。

optionslocation の両方が省略されると、リファレンスは composite_name/name にバインドされません。既存のリファレンスもすべてバインドされません。

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


% fncreate_fs -f infile user/kuanda/fs 

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


. altair:/export/home/kuanda

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


% 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 

プロジェクトやそのサブコンテキストの srclib の 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 

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


% 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_fsoptionslocation のフィールドで使用できます。たとえば、マウントの位置は、以下のように指定できます。


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_optionsmount_location の両方が省略されている場合、省略します。この書式は、互換のためだけのものです。これ以外の機能はないので、あまり使用しないでください。

第 26 章 FNS およびグローバルネーミングシステム

この章では、2 つのグローバルネーミングシステム (DNS と X.500/LDAP) とそれらを FNS でフェデレートする方法について説明します。

FNS およびグローバルネーミングシステム

FNS とグローバルネームサービスの関係についての概要および背景に関しては、「グローバルネームサービス」を参照してください。

FNS は、エンタープライズネーミングシステムのグローバルネーミングシステム、DNS、および X.500/LDAP のフェデレーションをサポートします。この章では、NIS+ を DNS および X.500 でフェデレートするための手順について説明します。通常、この手順には以下の内容が含まれます。


注 -

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


ルートリファレンスを取得する

DNS、あるいは X.500/LDAP でエンタープライズネームサービスをフェデレートする場合、企業や企業外部のグローバルインターネットからの、あるいはそれらへのアクセスができるようにするために、情報をこれらそれぞれのネーミングシステムに追加する必要があります。この情報とは「ルートリファレンス」のことで、これは、ある特定の企業の名前空間の最上部にどのようにして到達するかを示すネットワークアドレス情報からできています。

ルートリファレンスは、XDR で符号化した 1 つの文字列を含む 1 つのアドレスからできています。アドレスのタイプと内容は、使用しているエンタープライズレベルのネームサービスによって、つまり NIS+ かあるいは NIS かによって異なります。

NIS+ ルートリファレンス

エンタープライズレベルのネームサービスが NIS+ の場合、ルートリファレンスのアドレスタイプは、onc_fn_nisplus_root になります。ルートリファレンスネットワークアドレスには、必要 (必須の) 要素が 2 つと、オプションの要素が 1 つあります。要素は、以下のように空白文字で区切られます。


root-domain server [server_IP_address]
表 26-1 NIS+ ルートリファレンス

アドレス要素 

説明 

root_domain

NIS+ ルートドメインの完全指定名 (末尾にドットが必要) 

server

nis+_root_domain にサービスを行なっている NIS+ サーバー (マスターあるいは複製) のうちの 1 つのホスト名

server_IP_address

nis+server の IP アドレス。これは、nis+server の名前がわかっている場合は、オプション。このことは、/etc/nsswitch.conf ファイルのリストにあるネームサービスのどれか 1 つにより、これが取得できなければならないことを意味している

たとえば、NIS+ ルートドメインが doc.com. (末尾のドットに注意) で、ホスト nismaster.doc.com を使ってこれに到達できるとします。この場合ルートリファレンスは以下のようになります。


doc.com. nismaster.doc.com

上の例で、サーバーの IP アドレスが指定されていないのは、これ以外の方法で取得できるからです。何らかの理由で、その IP アドレスがこれ以外の方法で取得できない場合、ルートリファレンスは以下のようになります。


doc.com. nismaster.doc.com 123.123.123.33

NIS ルートリファレンス

エンタープライズレベルのネームサービスが NIS の場合、ルートリファレンスのアドレスタイプは、onc_fn_nis_root になります。ルートリファレンスネットワークアドレスには必要 (必須の) 要素が 2 つと、オプションの要素が 1 つあります。要素は、以下のように空白文字で区切られます。


root_domain server [server_IP_address]
表 26-2 NIS ルートリファレンス

アドレスの要素 

説明 

root_domain

NISドメインの完全指定名 (末尾にスラッシュが必要) 

server

root_domain にサービスを行なっている NIS サーバー (マスターか、あるいは複製) のうちの 1 つのホスト名

server_IP_address

nis-server の IP アドレス。これは、nis-server のアドレスがわかっている場合は、オプション。このことは、/etc/nsswitch.conf ファイルのリストにあるネームサービスのどれか 1 つにより、これが取得できなければならないことを意味している

たとえば、NIS ドメインが doc.com で、ホスト ypmaster.doc.com を使ってこれに到達できるとします。ルートリファレンスは以下のようになります。


doc.com/ ypmaster.doc.com

上の例で、サーバーの IP アドレスが指定されていないのは、これ以外の方法で取得できるからです。何らかの理由でその IP アドレスが、これ以外の方法で取得できない場合、ルートリファレンスは以下のようになります。


doc.com/ ypmaster.doc.com 123.123.123.37

DNS でフェデレートする

この項では、NIS+ あるいは NIS が使われている下位のエンタープライズネーミングシステムのための、TXT (テキスト) レコードを追加するのに必要な手順を説明します。DNS で下位のネーミングシステムをフェデレートする場合、DNS にリファレンス情報を追加し、下位のネーミングシステムのルートリファレンスへの到達の仕方を記述する必要があります。

  1. ルートリファレンスを取得します。

    詳細は、「ルートリファレンスを取得する」を参照してください。

  2. ルートリファレンス TXT レコードを DNS ループバックファイルに追加します。

    デフォルトで、このマニュアルでは、このファイル用に /etc/named.local の名前を使用します (これ以外で、このファイルによく使われる名前は、domain.127.0.0 あるいは db.127.0.0 です)。

    ルートリファレンス TXT レコードには以下の形式があります。

    NIS+ の場合


    TXT "XFNNISPLUS rootdomain server [server_IP_address]"

    たとえば、次のようになります。


    TXT "XFNNISPLUS doc.com. nismaster.doc.com"

    NIS の場合


    TXT "XFNNIS rootdomain server [server_IP_address]"

    たとえば、次のようになります。


    TXT "XFNNIS doc.com/ ypmaster.doc.com"

    TXT レコードは、NS (ネームサーバー) レコードのエントリを含む DNS ドメインに関連していなければなりません。以下は、DNS ドメインの例を、その中でバインドされている NIS+ への参照情報とともに示したものです。


    ORIGIN doc.com
    @ IN SOA foo bar.eng.doc.com
    	(
    	100 ;; Serial
    	3600 ;; Refresh
    	3600 ;; Retry
    	3600 ;; Expire
    	3600 ;; Minimum
    	)
    	NS nshost
    	TXT "XFNNISPLUS doc.com. nismaster 123.123.123.33"
    nshost IN A 133.33.33.34

    DNS ファイルの詳細は、「DNS の構成ファイルとデータファイル」を参照してください。

  3. TXT レコードを DNS テーブルに追加した後、DNS サーバーを再スタートするか、あるいはこれにテーブルを再度読むようシグナルを送ります。


    # kill -HUP pid
    

    pid のところには、in.named のプロセス ID 番号が入ります。

    DNS TXT を XFN リファレンス用に使用する方法の詳細は、「XFN リファレンス用 DNS 文書レコードの書式」を参照してください。

X.500/LDAP でフェデレートする

X.500/LDAP で下位のネーミングシステム (NIS+ または NIS) をフェデレートする場合、以下の規則があります。

X.500 ルートリファレンスを指定する

  1. NIS+ 階層構造用の NIS+ ルートリファレンスを取得します。

    詳細は、「ルートリファレンスを取得する」を参照してください。

  2. XFN リファレンス属性をサポートする X.500 エントリを作成します。

    たとえば、以下のコマンドは、オブジェクトクラスである toporganization、および XFN-supplement (1.2.840.1135436.25) を使って、c=us/o=doc と呼ばれる新しい X.500 エントリを作成します。XFN-supplement オブジェクトクラスにより、c=us/o=doc エントリに、下位のネーミングシステム用のリファレンス情報を保存できます。


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

    X.500 エントリがすでに存在していて、XFN-supplement オブジェクトクラスで定義されたものでない場合、これを削除し、オブジェクトクラスを追加して作成し直す必要があります。そうでないと、下位のネーミングシステムに関するリファレンス情報を保持しておくことができなくなります。

  3. 下位のシステムに関するリファレンス情報をエントリに追加します。

    X.500 エントリを作成した後、適切なルートリファレンスを指定したエントリにバインドすることにより、下位のシステムに関する情報を追加できます。

    たとえば、下位のネーミングシステムが NIS+ で、使用する NIS+ サーバーが nismaster の場合、以下のように入力します。


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

    下位のネーミングシステムが NIS で、使用する NIS サーバーが ypmaster の場合、以下のように入力します。


    # fnbind -r .../c=us/o=doc/ onc_fn_enterprise onc_fn_nis_root ¥
    "doc.com/ ypmaster"
    

    これらの例では、ルートのドメイン名 doc.com. を使って、NIS+ あるいは NIS 階層構造のリファレンスを X.500 エントリ c=us/o=doc の次のネーミングシステムポインタ (NNSP) にバインドしており、このようにして doc.com. 名前空間を x.500 名前空間にリンクしています。

    使用しているアドレスのフォーマットは、「ルートリファレンスを取得する」で説明したルートリファレンスの形式です。fnbind に対する名前の引数 .../c=us/o=doc/ の末尾に付いているスラッシュは、リファレンスがエントリ自体ではなく、エントリの NNSP にバインドされることを示すために使っていることに注意してください。

    X.500 エントリおよび XFN リファレンスの詳細は、「XFN リファレンス用 X.500 属性の構文」を参照してください。

X.500 クライアント API を指定する

X.500 クライアント API は、FNS を使って X.500 にアクセスする場合に必要です。以下の 2 つの異なるクライアントのうちどちらか 1 つを使うことができます。

使用する API は、各マシンの /etc/fn/x500.conf のファイルで指定されています。このファイルには、X.500 および LDAP の設定に関する情報が入っています。このファイルは、直接編集できます。デフォルトの x500.conf ファイルには、以下の 2 つのエントリが入っています。


x500-access: xds ldap
ldap-servers: localhost ldap

localhost および ldap のところには、1 つあるいは複数の LDAP サーバーの IP アドレス、またはホスト名が入ります。

最初のエントリでは、X.500 が API にアクセスする順序を指定します。上の例の場合、X.500 はまず XDS/XOM を使用しようとします。XDS/XOM が使用できない場合、LDAP を使用します。エントリが x500-access: ldap xds になっている場合、x.500 は LDAP を使い、LDAP が使用できない場合にだけ XDS に戻ります。

2 番目のエントリでは、LDAP を実行しているサーバーの IP アドレス、またはホスト名を表示します。各サーバーが、LDAP 接続が成功するまで、次々に試されます。上の例の場合、localhost が最初に試されます。LDAP がそのサーバーで使用できない場合、次のサーバーが試されます。

第 27 章 FNS 属性の管理

この章では、FNS 属性と、その管理の方法について説明します。

属性の概要

属性は、名前付きオブジェクトに使用することができます。属性はオプション指定ですから、属性のないオブジェクトもあれば、1 つあるいは複数の属性を持つオブジェクトもあります。

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

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

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

属性を検索する

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

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


fnsearch [-ALlv] [-n max] [-s scope] name [-a ident ]... [-O|-U] filter_expr [ filter_arg]

表 27-1 fnsearch コマンドのオプション

オプション 

説明 

-n max

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

-s scope

検索の範囲を設定する 

-a ident

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

name

複合名 

filter_expr

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

filter_arg

フィルタ表現の引数 (表 27-2 参照)

-A

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

-L

XFN リンクに従う 

-l

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

-v

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

-O

識別子にOSI OIDを使用する 

-U

識別子にDCE UUIDを使用する 

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

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

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


% fnsearch orgunit/sales/site/ for_sale

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

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

表 27-2 fnsearch フィルタ表現の演算子

フィルタ表現演算子 

シンボル、あるいは形式 

論理演算子 

orandnot

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

( )

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

== 少なくとも 1 つの属性値が、入力した値に等しい場合、True (真) != 入力した値に等しい属性値がまったくない場合、True (真) < 少なくとも 1 つの属性値が、入力した値より小さい場合、True (真) <= 少なくとも 1 つの属性値が、入力した値よりも小さいか等しい場合、True (真) >少なくとも 1 つの属性値が、入力した値よりも大きい場合、True (真) >= 少なくとも 1 つの属性値が、入力した値よりも大きいか、等しい場合、True (真) ‾= 少なくとも 1 つの属性値が、いくつかのコンテキスト特有のおおまかな一致条件に照らして、入力した値に一致している場合、True (真)。この条件は厳密な一致を含む必要がある

例 

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

置換トークン: 

シェルスクリプトを書くときに役に立ち、-O および -U オプションを指定すると、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]
表 27-3 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 と値 hplaserthisorgunit/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/printermodel 属性の値が表示されます。


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

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

属性を変更する

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


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

以下の例では、postscript という値が laser に変更されます。thisorgunit/service/printer の他の属性 (およびその値) には影響がありません。


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

その他のオプション

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

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