パート V では、フェデレーテッド・ネーミング・サービス (FNS) とその管理方法について説明します。
この章では、FNS の概要、設定と構成の手順に関する簡単な説明、およびプログラミングの例を示します。熟練の管理者であれば、この章を読むだけで必要なことがすべてわかります。
詳細は、パート V「FNS の管理」の他の章を参照してください。FNS の初期設定と構成の詳細は、『Solaris ネーミングの設定と構成』を参照してください。
フェデレーテッド・ネーミング・サービス (FNS) は、ネーミングとディレクトリ操作のための 1 つの単純なインタフェースのもとに、複数のネームサービスをフェデレートする方法を提供します。FNS によってリンクできるネームサービスには、NIS+、NIS、ファイルベース、DNS、および X.500/LDAP があります。
FNS がサポートするプログラミングインタフェースとそのポリシーは、XFN (X/Open Federated Naming) に述べられています。
FNS は、次の点で有用です。
単一の一貫したネーミングおよびディレクトリインタフェースがクライアントに対して用意されている。これを使用してネーミングおよびディレクトリサービスにアクセスできる。したがって、新しいネーミングおよびディレクトリサービスを追加しても、アプリケーションや既存のサービスに変更を加える必要はない
名前を一貫した方法で作成できる。FNS は、異なる複数のネーミングシステムから一貫した名前を作成する方法を定義する。これにより、アプリケーションは、これらの異なる複数のネーミングシステム内のオブジェクトを一定の方法でアドレス指定できる
共有コンテキストと共有名の使用によって、一貫したネーミングを行うことができる。異なる複数のアプリケーションでこれらの共有名と共有コンテキストを使用すると、作業を重複して行う必要がなくなる
FNS の基本概念として、複合名と複合コンテキストがあります。
複合名とは、複数のネーミングシステムで使用される名前のことをいいます。
複合名は、複数の構成要素の順序付きリストからなります。各構成要素は、単一のネーミングシステムの名前空間からとられた名前です。各構成要素の構文は、個々のネーミングシステムにより異なります。FNS は、複数のネーミングシステムからとられた名前を使用して複合名を作成するときの構文を定義します。複合名は、スラッシュ (/) を構成要素区切り文字として使用して、左から右へ作成されます。
たとえば、複合名 .../doc.com/site/bldg-5.alameda は、...、doc.com、site、bldg-5.alameda という 4 つの構成要素から構成されます。
コンテキストは、次の操作を行います。
名前をオブジェクトに関連付ける (割り当てる)
名前をオブジェクトとして解釈処理する
割り当てを削除する
名前を表示する
名前を変更する
名前付きオブジェクトに属性を関連付ける
名前付きオブジェクトに関連付けられた属性を取り出して更新する
属性を使用してオブジェクトを検索する
コンテキストには、一連の名前とリファレンスの割り当てが含まれます。各リファレンスには、通信の終端またはアドレスのリストが含まれます。フェデレーテッド・ネーミング・システムは、別のネーミングシステムのコンテキストで割り当て中の、あるネーミングシステムのコンテキストによって形成されます。複合名の解釈処理は、その名前全体が解釈処理されるまで、あるネーミングシステム内のコンテキストから、次のネーミングシステム内のコンテキストへと進みます。
名前付きオブジェクトには、属性を適用できます。属性はオプションです。名前付きオブジェクトには、属性を付けないことも、1 つまたは複数の属性を付けることもできます。
各属性は、一意の属性識別子、属性構文、ゼロまたはいくつかの属性値の集合を持ちます。
XFN は、既存の名前付きオブジェクトに関連付けられた属性値を確認、変更するための基本属性インタフェースを定義します。これらのオブジェクトは、コンテキストまたは他の任意のタイプのオブジェクトにできます。コンテキストには、コンテキストによる合成名の構文解析方法を記述する構文属性が関連付けられます。
拡張属性インタフェースには、特定の属性を検索する操作と、オブジェクトとその関連属性を作成する操作があります。
エンタープライズレベルのネームサービスは、あるエンタープライズ内のオブジェクトに名前を付けるために使用されます。FNS は現在、次の 3 つのレベルのネームサービスをサポートしています。
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 は、Solaris 環境でのエンタープライズ規模の情報サービスです。各エンタープライズは 1 つの NIS ドメインにあたります。1 つの NIS ドメインに対応する 1 つの FNS 組識単位があります。
NIS のもとで、FNS のコンテキストと属性データは NIS マップに格納されます。これらのマップは、NIS サーバー上の /var/yp/domainname ディレクトリに格納されます。NIS では、スーパーユーザーは、FNS コマンドを使用して、FNS マップ内の情報を処理できます。
一定の条件が満たされれば、NIS クライアント (マシン、プロセス、またはユーザー) はすべて、fncreate_fs、fncreate_printer などの FNS コマンドを使用して、クライアント独自のコンテキストを更新できます。これにより、NIS クライアントは、FNS コマンドを使用して、Printer Administrator、CDE カレンダマネージャ、admintool などのアプリケーションを更新できます。
スーパーユーザー以外のユーザーが、FNS コマンドを使用して独自のコンテキストを更新するには、次の条件が必要です。
NIS マスターサーバー上で SKI (Secure Key_management Infrastructure) が使用可能
fnsypd デーモンが、NIS マスターサーバー上で実行されている。このデーモンは、スーパーユーザー特権を持つユーザーが開始する
クライアントユーザーまたはマシンは、独自のコンテキストの更新だけできる
クライアントは、要求された更新を実行するための権限を持っている
SKI は 64 ビットモードをサポートしていません。したがって NIS クライアントは 64 ビットモードでのコンテクストの更新は行うことができません。
「ファイル」とは、通常、マシンの /etc ディレクトリにあるネーミングファイルを指します。これらのマシンベースファイルには、UNIX のユーザーとパスワード情報、ホスト情報、メール別名などが入っています。これらのファイルは、自動マウントマップなどの Solaris 特定のデータもサポートしています。
ファイルベースのネーミングシステムでは、FNS コンテキストと属性データはファイルに格納されます。これらの FNS ファイルは、マシンの /var/fn ディレクトリに格納されます。(/var/fn ディレクトリを各マシンに置く必要はありません。このディレクトリは、NFS ファイルサーバーからエクスポートされます。)
ファイルネーミングシステムでは、FNS コマンドを使用して FNS ファイルの情報を処理します。
FNS は、DNS と X.500 による NIS+ と NIS のフェデレートもサポートします。つまり、エンタープライズレベルの名前空間をグローバル名前空間に接続し、エンタープライズオブジェクトをグローバルな有効範囲でアクセス可能にできるということです。
FNS は現在、次のグローバルネームサービスをサポートしています。
DNS
X.500 (DAP または LDAP を経由)
FNS は、ネーミングポリシーを定義して、ユーザーとアプリケーションが共有名前空間に依存し、それを使用できるようにします。
エンタープライズ内には、組識単位、サイト、ホスト、ユーザー、ファイルとサービスごとの名前空間があり orgunit、site、host、user、fs (ファイルシステムを示す)、および 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 の割り当ては、基本となるネームサービスによって決まります。
NIS+ では、組識単位は NIS+ のドメインまたはサブドメインに対応する。たとえば、NIS+ のルートドメインが doc.com. で、doc.com. のサブドメインが sales だとした場合、FNS 名の org/sales.doc.com. と org/sales は、どちらも NIS+ ドメイン sales.doc.com. に対応する組識単位を指す。(sales.doc.com. の最後のドットは、完全指定 NIS+ 名に必要であることに注意)
NIS では、組識単位は NIS ドメインであり、必ず FNS 名 org// または org/domainname によって識別される。ここで、domainname は、doc.com. などの完全指定ドメイン名を示す。NIS の組識単位名には階層はない
ファイルベースのネーミングシステムで、組識単位は、必ず FNS 名 org// によって識別されるシステムである
組識単位名に対応して命名されるオブジェクトのタイプは、user、host、service、fs、site です。次に例を示します。
org/sales/site/conference1.bldg-6 は、組識単位 sales に関連するサイトの 6 号ビルにある会議室 conference1 を指定する。この例では、org/sales が sales.doc.com. に対応する場合、このオブジェクトを org/sales.doc.com./site/conference1.bldg-6 と指定することもできる (sales.doc.com. の最後のドットに注意)
org/finance/user/mjones は、組識単位 finance のユーザー mjones を指定する
org/finance/host/inmail は、組識単位 finance に属するマシン inmail を指定する
org/accounts.finance/fs/pub/reports/FY92-124 は、組識単位 accounts.finance に属するファイル pub/reports/FY92-124 を指定する
org/accounts.finance/service/calendar は、組識単位 accounts.finance のカレンダサービスを指定する。これは、組識単位のミーティングのスケジュールを管理する
サイト名は、必要に応じて作成されます。サイト名に対応して指定されるオブジェクトのタイプは、user、host、service、fs です。次に例を示します。
site/alameda/user/mjones は、サイト alameda にあるユーザー mjones を指定する
site/alameda/host/sirius は、サイト alameda にあるマシン sirius を指定する
site/alameda/service/printer/Sparc-2 は、サイト alameda にあるプリンタ Sparc-2 を指定する
site/alameda/fs/usr/dist は、サイト alameda で使用可能なファイルディレクトリ usr/dist を指定する
ユーザー名は、NIS+ の対応する passwd テーブル、NIS の passwd マップ、またはファイルの /etc/passwd ファイルにある名前に対応します。ユーザーのファイルコンテキストは、そのユーザーの passwd エントリから獲得されます。
ユーザー名に対応して指定されるオブジェクトのタイプは、service と fs です。次に例を示します。
user/chou/service/fax は、ユーザー chou のファックスサービスを指定する
user/esperanza/fs/projects/conf96.doc は、ユーザー esperanza のファイルシステムの projects サブディレクトリにあるファイル、conf96.doc を指定する
ホスト名は、NIS+ の対応する hosts、NIS の hosts マップ、またはファイルの /etc/hosts ファイルにある名前に対応します。ホストのファイルコンテキストは、ホストによってエクスポートされるファイルシステムに対応します。
ホスト名に対応して指定されるオブジェクトのタイプは、service と fs です。次に例を示します。
host/smtp-1/service/mailbox は、マシン smtp-1 に関連するメールボックスサービスを指定する
host/deneb/fs/etc/.cshrc は、ホスト deneb 上の /etc ディレクトリにあるファイル .cshrc を指定する
サービス名は、サービスアプリケーションに対応し、それによって決定されます。サービスコンテキストは、組識、ユーザー、ホスト、またはサイトコンテキストに対応して指定する必要があります。次に例を示します。
host/deneb/service/printer は、マシン deneb に関連するプリンタサービスを指定する
host/deneb/service/printer/Sparc-2 は、マシン deneb に関連するプリンタを指定する
user/charlie/service/calendar は、ユーザー charlie のカレンダサービスを指定する
site/conf_pine.bldg-7.alameda/service/calendar は、Alameda サイトの 7 号ビルにある conf_pine 会議室のカレンダサービスを指定する
ファイルシステム名は、ファイル名に対応します。次に例を示します。
user/prasad/fs/projects/96draft.doc は、ユーザー prasad の projects ディレクトリにあるファイル 96draft.doc を指定する
各自のネームサービスで FNS を開始するには、fncreate コマンドを実行します。
fncreate コマンドは、FNS コンテキストが作成されるネームサービス (NIS+、NIS、ファイルベースなど) を認識します。特定のネームサービスを指定するには、下記の 「デフォルト以外のネームサービスの指定」で説明する、fnselect コマンドを実行する必要があります。
デフォルトでは次のようになります。
fncreate を NIS+ クライアントまたはサーバーであるマシン上で実行すると、FNS 名前空間が NIS+ に設定されます。FNS NIS+ マスターサーバーとして別のマシンを指定する必要がある場合は、『Solaris ネーミングの設定と構成』を参照してください。
マシンが NIS クライアントの場合、名前空間は NIS で設定されます。
マシンが上記のどちらでもない場合、名前空間はマシンで /var/fn ディレクトリに設定されます。基本となるネームサービスがファイルベースの場合、各マシンで fncreate を実行することによって /var/fn を作成する点は共通です。ただし、一方のマシンで /var/fn を作成し、NFS によってそれをエクスポートして、別のクライアントによってマウントできます。
fnselect コマンドを使用すると、デフォルト以外のターゲットネームサービスを明確に指定することもできます。たとえば、次のコマンドは、ターゲットネームサービスに NIS を選択します。
# fnselect nis |
デフォルトポリシー、または fnselect によって明示的にネームサービスを指定したら、次のコマンドを使用して、FNS 名前空間を作成できます。
# fncreate -t org org// |
このコマンドは、対応するネームサービス内のユーザーとホストに必要なすべてのコンテキストを作成します。
各自のエンタープライズレベルの基本ネームサービスが NIS+ の場合は、次の点を考慮に入れてください。
上記のコマンド構文は、ルート NIS+ ドメインの FNS 名前空間を作成します。ルート以外のドメインを指定するには、次のように、2 つのスラッシュの間にドメイン名を追加します。
# fncreate -t org org/sales.doc.com./ |
完全指定の sales.doc.com. の最後のドットに注意してください。
fncreate コマンドは、ctx_dir ディレクトリに NIS+ のテーブルとディレクトリを作成します。ctx_dir ディレクトリオブジェクトは、ドメインの NIS+ の groups_dir と org_dir ディレクトリオブジェクトと同じレベルにあります。
大きなドメインでは、NIS+ サーバー上で必要な追加スペースが多く、大きなインストール環境では、FNS と標準 NIS+ の各テーブルに個別のサーバーを使用することによって、パフォーマンスを改善できる場合があります。FNS と NIS+ に個別のサーバーを使用する方法については、『Solaris ネーミングの設定と構成』を参照してください。
大きいドメイン、または重要なドメインでは、FNS サービスを複製する必要があります。FNS サービスの複製方法については、『Solaris ネーミングの設定と構成』を参照してください。
fncreate などの FNS コマンドを実行するユーザーは、必要な NIS+ 資格を持つことが前提とされます。
環境変数 NIS_GROUP
は、fncreate によって作成された NIS+ オブジェクトのグループ所有者を指定します。NIS+ オブジェクトの管理を容易にするために、NIS_GROUP
には、そのドメインの FNS 管理を担当する NIS+ グループ名を設定してから、fncreate などの FNS コマンドを実行する必要があります。
デフォルトのアクセス制御権を含む NIS+ 関連属性は、コンテキストの作成後、NIS+ の管理ツールやインタフェースを使用して変更できます。FNS 複合名に対応する NIS+ オブジェクト名は、後で説明する fnlookup および fnlist によって獲得できます。
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 名前空間にアクセスできます。
名前空間を設定したら、次のコマンドを使用して表示できます。
fnlist - コンテキストの内容を表示 (「コンテキストの内容の表示」を参照)
fnlookup - 複合名の割り当てを表示 ( 「複合名の割り当ての表示」を参照)
fnattr - 複合名の属性を表示 (「複合名の属性の表示」を参照)
次の fnlist コマンドは、name のコンテキスト名とリファレンスの割り当てを表示します。
fnlist [-lvA] [name] |
オプション |
説明 |
---|---|
name |
複合名。name のコンテキストでの名前の割り当てを表示する |
-v |
詳細。割り当ての詳細を表示する |
-l |
指定のコンテキストで割り当てられた名前の割り当ても表示する |
-A |
fnlist で、権限のあるサーバーからの情報を強制的に獲得する。NIS と NIS+ で、このサーバーはドメインのマスターサーバーになる。-A オプションは、基本ネームサービスがファイルベースの場合、無効である |
次に例を示します。
初期コンテキストの名前をリスト表示する場合
% fnlist |
現在の組識単位内のユーザーすべての詳細をリスト表示する場合
% fnlist -v user |
ユーザー pug の service コンテキストの内容をリスト表示する場合
% fnlist user/pug/service |
権限のあるサーバーからの名前と割り当てをリスト表示する場合
% fnlist -l -A |
fnlookup コマンドは、指定の複合名の割り当てを表示します。
fnlookup [-vAL] [name] |
オプション |
説明 |
---|---|
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 |
詳細は、「属性の処理」を参照してください。
fnsearch コマンドは、属性が所定の検索基準を満たす複合名以下で割り当てられたオブジェクト名を表示し、必要に応じてその属性とリファレンスを表示します。
たとえば、realname という属性を持つユーザーとその属性をリスト表示するには、次のコマンドを実行します。
% fnsearch user realname |
値が Ravi Chattha の属性 realname を持つユーザーをリスト表示するには、次のコマンドを実行します。
% fnsearch user "realname == 'Ravi Chattha'" |
fnsearch コマンドは、共通のブール型演算子を使用します。上記の例では、二重引用符と一重引用符、2 つの等号の使用に注意してください。
名前空間を設定したら、次のコマンドを使用して、要素の追加、削除、および変更できます。
fnbind - 複合名に新しいリファレンスを割り当てる (「複合名へのリファレンスの割り当て」を参照)
fnunbind - 割り当てを削除する (「割り当ての削除」を参照)
fncreate - 新しい組識、ユーザー、ホスト、サイト、サービスコンテキストを作成する (「新しいコンテキストの作成」を参照)
fncreate_fs - 新しいファイルシステムコンテキストを作成する (「ファイルコンテキストの作成」を参照)
fncreate_printer - 新しいプリンタコンテキストを作成する (「プリンタコンテキストの作成」を参照)
fndestroy - コンテキストを削除する (「コンテキストの削除」を参照)
fnattr - 属性を表示、作成、変更、削除する (「属性の処理」を参照)
fncopy - あるネームサービスから別のネームサービスへ FNS コンテキストと属性をコピーする (「FNS コンテキストのコピーと変換」を参照)
FNS システム管理は、基本となるネームサービスによって異なります。
「NIS+」では、FNS システム管理タスクは、その権限を持つユーザーだけが実行できます。システム管理特権を付与する通常の方法では、NIS+ グループを作成し、そのドメインに必要な特権をそのグループに割り当てます。これにより、そのグループのメンバーはすべて、システム管理機能を実行できるようになります。
「ファイルベース」のネーミングシステムでは、FNS 管理タスクは、/var/fn ディレクトリへの root アクセス権を持つユーザーが実行しなければなりません。
ユーザーが各自のサブコンテキストを変更できるかどうかは、基本となるネームサービスによって異なります。
「NIS+」では、ユーザーのコンテキストと関連サブコンテキストは、ユーザーが所有します。NIS+ ポリシーでログインした場合、適切な資格と特権を持つユーザーは、fncreate、fnbind、fnunbind などのコマンドを使用して、各自のコンテキストを変更できます。
「NIS」では、ユーザーはどの FNS データも変更できません。NIS マスターサーバーへの root アクセス権を持つユーザーだけが、FNS データを変更できます。
「ファイルベース」のネーミングシステムでは、ユーザーは独自のコンテキストを所有します。標準の UNIX アクセス制御が FNS ファイルに適用されます。
fnbind コマンドは、既存のリファレンス (名前) を新しい複合名に割り当てるために使用されます。
fnbind -r [-s][-v][-L] name [-O|-U] newname reftype addrtype [-c|-x] address |
オプション |
説明 |
---|---|
name |
既存の複合名 |
newname |
新しい割り当ての複合名 |
addrtype |
使用するアドレスのタイプ。onc_cal_str のようにアプリケーション特定 |
address |
使用するアドレスの内容。たとえば、tsvi@altair |
reftype |
使用するリファレンスのタイプ。one_calendar のようにアプリケーション特定 |
-s |
すでに割り当てられている場合でも、newname に割り当てられる。これは、以前の newname の割り当てを置き換える。-s を指定しないと、newname がまだ割り当てられていない場合、fnbind は失敗する |
-v |
newname に割り当てられるリファレンスを表示する |
-L |
oldname を使用して XFN リンクを作成し、それを newname に割り当てる |
-r |
コマンド行引数によって作成されたリファレンスに newname を割り当てる |
-c |
入力された形式で address の内容を格納する。XDR コードは使用しない |
-x |
address を XDR コードに変換しないで、16 進文字列に変換する |
-O |
識別子の形式は FN_ID_ISO_OID_STRING。これは、ASN.1 のドットで区切った整数リスト文字列である |
-U |
識別子の形式は FN_ID_DCE_UUID。これは、文字列形式の DCE UUID である |
次に例を示します。
ユーザー jamal にカレンダ割り当てを追加する場合
# fnbind -r user/jamal/service/calendar onc_calendar onc_cal_str jamal@cygnus |
org//service/Sparc-4 の既存の割り当てを、org//service/printer の割り当てによって置換する場合
# fnbind -s org//service/printer org//service/Sparc-4 |
site/bldg-5/service/printer のリファレンスを user/ando/service/printer にコピーする場合
# fnbind site/bldg-5/service/printer user/ando/service/printer |
シンボリックリンクを使用して、site/bldg-5/service/printer のリファレンスを user/ando/service/printer に割り当てる場合
# fnbind -L site/bldg-5/service/printer user/ando/service/printer |
staff@altair が onc_cal タイプのリファレンスであり、かつタイプ onc_cal_str のアドレスである場合、thisens/service/calendar の名前をアドレス staff@altair に割り当てる場合
# fnbind -r thisens/service/calendar onc_calendar onc_cal_str staff@altair |
コマンド行 address によって作成されたリファレンスとして newname を割り当てる場合
# fnbind -r [-sv] newname [-O|-U] reftype {[-O|-U] addrtype [-c|-x] address} |
fnunbind コマンドは、割り当てを削除するために使用されます。
たとえば、user/jsmith/service/calendar の割り当てを削除するには、次のコマンドを実行します。
# fnunbind user/jsmith/service/calendar |
fncreate コマンドは、コンテキストを作成するために使用されます。
fncreate -t context [-f file] [-o] [-r reference] [-s] [-v] [-D] name |
オプション |
説明 |
---|---|
-t context |
context タイプのコンテキストを作成する。context タイプは、org、hostname、host、username、user、service、fs、site、nsid、generic |
-f file |
入力ファイルを使用して、コンテキストを作成するユーザーとホストを一覧表示する |
-r reference |
リファレンスのタイプ。-r reference オプションは、-t generic とともにしか使用できない |
name |
複合名 |
-o |
name によって識別されるコンテキストだけを作成する |
-s |
既存の割り当てすべてを上書き (置換) する。-s を使用しないと、名前がすでに割り当てられている場合、fncreate は失敗する |
-D |
各コンテキストの作成時に、そのコンテキストと、対応するテーブル、ディレクトリ、ファイルに関する情報を表示する |
-v |
詳細。各テキストの表示時にその情報を表示する |
次に例を示します。
ルート組識のコンテキストとサブコンテキストを作成する場合
# fncreate -t org org// |
ホスト deneb のコンテキストとサブコンテキストを作成する場合
# fncreate -t host host/deneb |
コンテキスト、サービス、ファイルサブコンテキストを作成して、ユーザー sisulu のカレンダ割り当てを追加する場合
# fncreate -t user user/sisulu # fnbind -r user/sisulu onc_calendar onc_cal_str sisulu@deneb |
sales 組識のサイトコンテキストを作成する場合
# fncreate -t site org/sales/site/ |
サイトコンテキストは、ドットで区切られた右から左へという順番の名前によって、階層名前空間をサポートします。これにより、地理上のカバレージ関係によってサイトを区分化できます。たとえば、サイトコンテキスト alameda とサイトサブコンテキスト bldg-6.alameda を作成するには、次のコマンドを実行します。
# fncreate -t site org/sales/site/alameda # fncreate -t site org/sales/site/bldg-6.alameda |
fncreate_fs コマンドは、コマンド行から入力された割り当て記述によって、組識とサイトのファイルコンテキストを作成します。
fncreate_fs [-r] [-v] name [options] [mount] |
fncreate_fs コマンドは、入力ファイルから提供された割り当ての記述によって、組識とサイトのファイルコンテキストを作成します。
fncreate_fs [-r] [-v] -f file name |
オプション |
説明 |
---|---|
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 |
オプション |
説明 |
---|---|
name |
プリンタの組識、ホスト、ユーザー、またはサイトの名前 |
printer |
プリンタ名 |
prntaddr |
プリンタアドレス。<addresstype>=<address> という形式をとる |
-f file |
指定の ファイル を、作成するプリンタリストへの入力として使用。入力ファイルは /etc/printers.conf ファイルの形式をとる。プリンタ名 も -f ファイル も指定されていない場合、fncreate_printer は、fncreate_printer がデフォルト入力ファイルとして実行されるマシン上の /etc/printer.conf ファイルを使用する |
-s |
既存のアドレスを、同じアドレスタイプによって置換する |
-v |
詳細。割り当ての詳細を表示する |
次に例を示します。
fncreate_printer が実行されるマシンの /etc/printers.conf ファイルに示されたプリンタに基いて sales 組識のプリンタを作成する場合
# fncreate_printer -s org/sales/ |
マシン altair が、プリンタ Sparc-5 のサーバーであると想定します。ユーザー nguyen に対して、実際に Sparc-5 プリンタである invoices という名前のプリンタを作成する場合、次のように入力します。
# fncreate_printer user/nguyen invoices bsdaddr=altair,Sparc-5 |
プリンタを階層構造で構成することもできます。たとえば、fncreate_printer コマンドは、プリンタ color、color/inkjet、color/Sparc のプリンタコンテキストを作成できます。コンテキストは次のようになります。
org/doc.com/service/printer/color org/doc.com/service/printer/color/inkjet org/doc.com/service/printer/color/Sparc |
上記のコンテキストを作成するには、次のコマンドを実行します。
# fncreate_printer org/doc.com color bsdaddr=colorful,color # fncreate_printer org/doc.com color/inkjet bsdaddr=colorjet,inkjet # fncreate_printer org/doc.com color/Sparc bsdaddr=colorprt,Sparc |
fndestroy コマンドは、空のコンテキストを削除するために使用されます。
たとえば、ユーザー patel の service コンテキストを削除するには、次のコマンドを実行します。
# fndestroy user/patel/service |
fnattr コマンドは、名前に関連する属性の追加、削除、または変更に使用できます。変更は一度に 1 つずつ行うことも、同じコマンド内で何回かバッチ処理することもできます。
fnattr [-l] name
name の属性をリスト表示
fnattr name -a-s -U -O attrib values
属性の追加
fnattr name -m -O -U attrib oldvalue newvalue
属性の変更
fnattr name -d -O | -U [values attrib]
属性の削除
オプション |
説明 |
---|---|
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/ |
どちらの例でも、最後にスラッシュが必要であることに注意してください。
fncopy コマンドは、FNS のコンテキストと属性を新しい FNS コンテキストにコピー、または変換するために使用できます。
-i および -o オプションを使用すると、あるエンタープライズレベルのネームサービスに基く FNS コンテキストを、異なるネームサービスに基くコンテキストにコピーできます。たとえば、NIS の上部で実行される FNS インストール環境があって、NIS サービスを NIS+ にアップグレードする場合、fncopy を使用すると、NIS+ を使って新しいコンテキストを作成できます。
次の点に注意してください。
古いコンテキストをコピー中の新しい FNS コンテキストが、そのターゲットネームサービスにすでに存在する場合は、新しいコンテキストと割り当てだけがコピーされる。これらのコンテキストは上書きも変更もされない
fncopy は、リンクに従わないが、名前に割り当てられた FNS リンクを、新しいコンテキストの名前空間にコピーする
オプション |
説明 |
---|---|
-i oldservice |
エンタープライズレベルの古い (入力) 基本ネームサービス。たとえば、-i nis は、古いサービスが NIS であることを指定する。指定できる値は、files、nis、nisplus |
-o newservice |
エンタープライズレベルの新しい (出力) ネームサービス。たとえば、-o nisplus は、新しいサービスが NIS+ であることを指定する。指定できる値は、files、nis、nisplus |
-f filename |
コピーされる FNS コンテキストのリストが入っているテキストファイル。-i および -o オプションを指定しない場合、コンテキストは、グローバル名を使用する識別子でなければならない |
oldcontext |
コピーされるコンテキスト名 |
newcontext |
作成先またはコピー先のコンテキスト名 |
たとえば、doc.com プリンタコンテキスト (およびサブコンテキスト) と割り当てを orgunit/east/doc.com にコピーするには、次のコマンドを実行します。
# fncopy .../doc.com/service/printer .../doc.com/orgunit/east/service/printer |
ファイル user_list に指定された NIS FNS ユーザーのコンテキストを、orgunit west/doc.com の NIS+ FNS ユーザーのコンテキストにコピーするには、次のコマンドを実行します。
# fncopy -i nis -o nisplus -f /etc/user_list thisorgunit/user org/doc.com/user |
この節のプログラミング例は、次の操作を実行するための XFN API の使用法を示しています。
次の例は、コンテキストをリスト表示するための XFN 操作を示しています。
#include <stdio.h> #include <xfn/xfn.h> #include <string.h> #include <stdlib.h> /* このルーチンは与えられたコンテキスト (ctx_name) の下で 割り当てられた名前のリストを返す。 ctx_name の例としては "user"、"thisorgunit/service"、 host/alto/service、user/jsmit/service/calendar などがある */ typedef struct fns_listing { char *name; struct fns_listing *next; } fns_listing; fns_listing * fns_list_names(const char *ctx_name) { FN_status_t *status; FN_ctx_t *initial_context; FN_composite_name_t *context_name; FN_namelist_t *name_list; FN_string_t *name; unsigned int stat; fns_listing *head = 0, *current, *prev; int no_names = 0; status = fn_status_create(); /* 初期コンテキストの獲得 */ initial_context = fn_ctx_handle_from_initial(0, status); if (!fn_status_is_success(status)) { fprintf(stderr, "Unable to obtain intial context¥n"); return (0); } context_name = fn_composite_name_from_str((unsigned char *) ctx_name); /* FNS によるリスト名の呼び出し */ name_list = fn_ctx_list_names(initial_context, context_name, status); if (!fn_status_is_success(status)) { fprintf(stderr, "Unable to list names¥n"); return (0); } /* 名前を個々に呼び出す */ while (name = fn_namelist_next(name_list, status)) { no_names++; current = (fns_listing *) malloc(sizeof(fns_listing)); current->name = (char *) malloc(strlen((char *) fn_string_str(name, &stat)) + 1); strcpy(current->name, (char *) fn_string_str(name, &stat)); current->next = 0; if (head) { prev->next = current; prev = current; } else { head = current; prev = current; } fn_string_destroy(name); } fn_namelist_destroy(name_list); fn_status_destroy(status); fn_ctx_destroy(initial_context); return (head); |
次の例は、バインディングの作成方法を示しています。
#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); } |
この章では、X/OPEN XFN フェデレーテッド・ネーミング標準に基づいて Sun Microsysmtems, Inc. が設計した FNS (フェデレーテッド・ネーミング・サービス) について説明します。
コンピューティング環境に組み込まれているネームサービスは、アプリケーションやサービスによって異なります。異なる複数のネームサービスを処理する場合、アプリケーション開発者は多くの問題に直面します。ほとんどのアプリケーションは、1 つのネームサービスを使用するように設計されており、分散コンピューティング環境内のオブジェクトへのアクセスは非常に制限されています。アプリケーションによって、使用するネームサービスが異なるため、名前の作成方法も異なります。ユーザーが非常に似ていると見なすオブジェクトについても、異なる名前が使用される場合がよくあります。たとえば、友人の Johanna に対して彼女の名前 johanna@admin.doc.com を使用してメールを送信できますが、彼女のカレンダにアクセスするには、別の名前 jsmith@altair を使用しなければなりません。
Sun Microsysmtems, Inc. による XFN 標準の実装である FNS を使用すると、オブジェクトを一貫した方法でネーミングし、しかもアプリケーションと開発者が必要とする機能を提供することもできます。
「XFN」は、X/Open フェデレーテッド・ネーミングのことを指します。XFN は、Sun Microsystems, Inc.、IBM、Hewlett-Packard、DEC、Siemens、OSF などの組織によって実際にサポートされている標準です。Solari 7 リリースでの XFN の実装である FNS は、「X/Open Preliminary Specification for Federated Naming」(1994 年 7 月) に準拠しています。FNS を使用するアプリケーションは、プラットフォーム間で移植可能です。これは、FNS によって、エクスポートされるインタフェースが、他のベンダーと X/Open によって認められた公共のオープンインタフェースである XFN だからです。X/Open Company Ltd. は、主要なコンピュータベンダーによって推奨され支持されるコンピューティング標準の定義を委託された国際標準機構です。
「FNS」は、基本的なネーミング操作用の 1 つの単純な一貫したインタフェースによって、複数のネーミングサービスをフェデレートする方法です。このサービスは、複合名、つまり、複数のネーミングシステムにまたがる名前を、ネーミングインタフェースによって解決します。フェデレーションの各メンバーは、ネーミング規則、管理インタフェース、名前解決以外の特定操作の集合を独自に選択できます。
Solaris 環境での FNS 実装は、DNS や X.500 などのグローバルネームサービス (「Solaris エンタープライズレベルのネームサービス」を参照) のサポートだけでなく、組織、ユーザー、ホスト、サイト、サービスをネーミングするための特定のポリシーと規則によって、一連のエンタープライズレベルのネームサービス (「グローバルネームサービス」を参照) から構成されます。
FNS は次の理由で便利です。
異なる複数のネームサービスにアクセスするために、クライアントに対して、一貫した 1 つのネーミングインタフェースが提供される。したがって、新しいネームサービスを追加しても、アプリケーションや既存のメンバー名サービスを変更する必要がない
名前を一貫した方法で作成でき、作成される複合名に任意の数の構成要素を使用できる
共有コンテキストと共有名を使用するときに、一貫したネーミングが可能になる
このマニュアルでは、XFN と FNS を区別することが重要です。FNS ポリシーには XFN ポリシーの拡張がいくつか含まれており、これらのポリシーは、注によって明確に定義されます。XFN プログラミングインタフェースに属するオブジェクトは、他のプログラミングインタフェースとの混同を避けるために、XFN オブジェクトとして指定されます。
この項では、XFN のネーミングモデルについて、いくつかの観点から説明します。
フェデレーテッド・ネーミング・システムによって提供される基本サービスは、複合名とリファレンスのマッピングと、名前付きオブジェクトに関連する属性へのアクセス権の提供です。この項では、XFN ネーミングモデルの各要素を定義します。
分割不可能な名前の最小構成要素を「原子名」といいます。たとえば、マシン名 nismaster やユーザー名 chou などです。原子名には 1 つまたは複数の属性がある場合や、属性がまったくない場合があります (「属性」を参照)。
リファレンスとは、オブジェクトに到達する方法についての情報のことをいいます。リファレンスには、アドレスのリストが入っています。1 つのアドレスは、1 つの通信の終端 (オブジェクト) を識別します。たとえば、nismaster.doc.com などのマシンアドレスや、chou@doc.com などのユーザーの電子メールアドレスです。
リファレンスには、1 つの概念上のオブジェクトまたはサービスを示す、複数の通信終端を識別する複数のアドレスが含まれる場合があります。たとえば、オブジェクトが分配されるか、または複数の通信メカニズムによってオブジェクトにアクセスできるため、アドレスのリストが必要になる場合などです。
XFN は、安定性、有効性、到達の確実性などのアドレス属性を保証できません。クライアントは名前を検索できても、返されたリファレンスを使用できない場合があります。これは、そのクライアントが必要な通信メカニズムをサポートしていないか、あるいはそのアドレスに到達するために必要なネットワークの接続がないために起こります。また、アドレスが最初から無効であるか、古い場合があります。これらは、そのアドレスに指定された名前のバインダ、クライアント、サービスプロバイダ間の規則の問題です。
コンテキストとは、図 21-1 に示すようにリファレンスに割り当てられた原子名の集合のことです。どのコンテキストにも、関連のネーミング規則があります。コンテキストは、検索 (解決) 操作を行います。この操作では、リファレンスが返され、名前のバインド、名前のバインド解除、バインド名のリスト表示を行うこともあります。コンテキストは、検索操作とバインド操作の中心となるものです。
属性は、名前付きオブジェクトに適用できます。属性はオプションです。名前付きオブジェクトには、属性を付けないことも、あるいは 1 つまたは複数の属性を付けることもできます。
各属性は、固有の属性識別子と属性構文を持ちます。個別の属性値の集合のある場合とない場合があります。属性は、図 21-1 に示すように点線で示されます。
XFN は、既存の名前付きオブジェクトに関連する属性の値を調べて変更するための基本属性インタフェースを定義します。これらのオブジェクトは、コンテキストまたは他のタイプのオブジェクトとなります。コンテキストには、コンテキストによる合成名 (compound name) の構文解析方法を記述する構造属性が関連付けられます。
拡張属性インタフェースには、特定の属性を検索する操作と、オブジェクトおよびその関連属性を作成する操作が含まれます。
合成名とは、1 つ以上の原子名が連なったものをいいます。あるコンテキスト内の原子名は、サブコンテキストと呼ばれる同じタイプの別のコンテキストへのリファレンスに割り当てられます。サブコンテキスト内のオブジェクトは、合成名を使用してネーミングされます。合成名は、連続する各コンテキスト内の連続する各原子名を検索することによって解決されます。
これは、UNIX ユーザーのファイルネーミングモデルに似ています。この場合、ディレクトリはコンテキストにあたり、パス名は合成名として機能します。また、コンテキストは、ディレクトリと同様に「ツリー」構造で構成されます。合成名は階層名前空間を形成します。
次に例を示します。
「UNIX」の usr/local/bin
UNIX の原子名は、左から右へ順序付けられ、スラッシュ (/) によって区切られる。usr という名前は、local がバインドされているコンテキストにバインドされる。local という名前は、bin がバインドされているコンテキストにバインドされる
「DNS」の sales.doc.com
DNS の原子名は、右から左へ順序付けられ、ドット (.) によって区切られる。ドメイン名 com は、doc がバインドされているコンテキストにバインドされる。doc は、sales がバインドされているコンテキストにバインドされる
「X.500」の c=us/o=doc/ou=sales
X.500 の原子名は、属性タイプと属性値を構成する。原子名は、X.500 では、「相対識別名」と呼ばれる。この文字列表記で、X.500 原子名は、左から右に順序付けられ、スラッシュ (/) によって区切られる。属性タイプは、等号 (=) によって、属性値と区切られる。一般的に使用される属性タイプには省略名が定義される (たとえば、"c" は国名を表す)。国名 US は、docがバインドされているコンテキストにバインドされる。組織名 doc は、組織ユニット名 sales がバインドされているコンテキストにバインドされる
複合名とは、複数のネーミングシステムにまたがる 1 つの名前のことをいいます。各構成要素は、単一のネーミングシステムの名前空間からとられた名前です。複合名の名前解決は、複数のネーミングシステムにまたがる名前の解決プロセスです。
構成要素はスラッシュ (/) によって区切られ、XFN 複合名構文に従って、左から右へ順序付けられます。たとえば、複合名
sales.doc.com/usr/local/bin
には、DNS 名 (sales.doc.com) と UNIX パス名 (usr/local/bin) という 2 つの構成要素があります。
原子名とリファレンスアドレスは、1 つまたは複数の「名前空間」に対応して解決することもできます。デフォルトにより、FNS には、org (組織を示す)、site、host、user、service、fs (ファイルを示す) の 6 つの名前空間があります。
FNS のポリシーは、名前空間に関連する名前が相互に関連付け合う方法を決めるために使用されます。たとえば、あるユーザーが、ユーザー名前空間で sergei とネーミングされていて、/user/sergei と識別されるとします。カレンダアプリケーションは、サービス名前空間でネーミングされ、/service/calendar と識別されます。このシステムでは、sergei のカレンダサービスを /user/sergei/service/calendar と識別できます。名前空間とその使用方法の詳細は、「FNS および XFN のポリシーの概要」を参照してください。
あるアプリケーションでユーザー名の入力が必要な場合、そのアプリケーションでは、入力する名前の前に名前空間識別子 user/ を付けることができます。アプリケーションで、ユーザーのデフォルトのファックス機などのユーザーのサービスの 1 つをネーミングする必要がある場合は、入力された名前に service 名前空間とサービスの名前 (/service/fax) を追加できます。したがって、ファックスツールは、入力値として、ユーザー名 jacques をとり、ユーザー jacques のデフォルトファックスの完全指定名 user/jacques/service/fax を作成します。同様に、ユーザー名を入力するだけで、あるユーザーのカレンダにアクセスできます。アプリケーションは入力値 raj をとり、その値を使用して複合名を作成します。この場合は、user/raj/service/calendar です。
XFN リンクは、コンテキスト内の原子名に割り当てられたリファレンスの特殊な形式です。リンクには、アドレスではなく複合名が含まれます。ネーミングシステムの多くは、そのネーミングシステム自体で使用可能なリンクという基本概念をサポートしています。XFN は、このような基本リンクと XFN リンクの間に何らかの関係があるかどうかを指定しません。
XFN 名はすべていくつかのコンテキストに対応して解釈され、XFN ネーミング操作は、コンテキストオブジェクトに対して実行されます。「初期コンテキスト」オブジェクトは、複合名解決の開始地点となるものです。XFN インタフェースは、クライアントが初期コンテキストを獲得するための機能を提供します。
第 22 章「FNS ポリシー」で説明しているように、このコンテキストとそのバインドの意味を見つけるためにクライアントが必要とする名前の集合を指定します。これにより、別の XFN コンテキストを見つけることが可能となります。
ユーザーは、アプリケーションによりフェデレーテッド・ネーミングを利用できます。通常、ユーザーは、オブジェクトの完全複合名を作成する必要も、知る必要もありません。これは、アプリケーションが複合名の作成を行うためです。これにより、ユーザーは、XFN を認識するアプリケーションと、単純な一貫した方法で対話することができます。
ユーザーとアプリケーションは、ファイルシステムによっても、フェデレーテッドネーミングを利用できます。初期コンテキストは、ルートディレクトリの /xfn に入っています。たとえば、ingrid の to_do ファイルの XFN 名が xfn/user/ingrid/fs/to_do だとします。
このファイルを読むには、次のように入力します。
% cat /xfn/user/ingrid/fs/to_do |
アプリケーションは、他のファイルの場合と同様に、/xfn のもとにあるファイルにアクセスします。アプリケーションを変更する必要も、XFN API を使用する必要もありません。
次の一連の図は、クライアントアプリケーションが XFN と対話して異なるネーミングシステムにアクセスする方法を示します。図 21-2 は、XFN API とライブラリを使用するアプリケーションを示します。
図 21-3 は、API の詳細を示しています。フェデレートされるネームサービスは、XFN クライアントライブラリと「コンテキスト共有オブジェクトモジュール」によってアクセスされます。このモジュールは、XFN 呼び出しをネームサービス特定呼び出しに変換します。
XFN インタフェースのクライアントの多くは、検索だけを対象とします。これらのクライアントは、インタフェースを次の目的で使用します。
初期コンテキストの獲得
初期コンテキストに対応する 1 つまたは複数の名前の検索
クライアントは、検索操作で必要なリファレンスを獲得すると、そのリファレンスからオブジェクトのクライアント側での表示を作成します。
Solaris 環境では、ネームサービスは、ファイルシステム、ネットワーク情報サービス、メールシステム、カレンダサービスなどの他のサービスに統合されます。たとえば、ファイルシステムには、ファイルとディレクトリ用のネーミングシステムが含まれます。NIS+ サービスでは、ネーミングシステムと特殊な情報サービスを結合します。
FNS がない場合、Solaris 環境のユーザーは、整合性のない複数の名前を使用して、オブジェクトを参照しなければなりません。たとえば、jsmith@admin という名前を使用して Joan にメールを送り、jsmith@altair という名前を使用してカレンダにアクセスし、/home/jsmith/.cshrc という名前を使用して、彼女のホームディレクトリにあるファイルに到達しなければなりません。このため、ユーザーが名前を形式化するのが困難になります。また、アプリケーションがユーザーに代わって名前を自動生成することも難しくなります。FNS ポリシーでは、これらのオブジェクトをネーミングする一貫した方法を定義します。
アプリケーションもネームサービスを必要とします。Solaris 環境のアプリケーションでは、多くのネームサービスインタフェースを処理する必要があります。1 つのアプリケーションが、Solaris 環境の外部にある各種の互換性のないネーミングシステムと関わる場合もあります。ローカルネットワークと広域ネットワークでは、異機種の複数のハードウェアとオペレーティングシステムが接続されているので、各種のインタフェースが混在する可能性が高くなります。これらのネーミングインタフェースは大幅に異なるだけでなく、基本的なネーミング操作も通常明確ではありません。
FNS は、これらの問題を次の 2 つの方法で解決します。
基本ネーミング機能に単一の標準インタフェースを提供して、開発者がアプリケーションで使用できるようにする
既存のアプリケーションを変更しなくても、ネットワークのネームサービスの変更や追加ができるようにする
アプリケーションによっては、複合名を使用して、Solaris 環境のオブジェクトにアクセスするものがあります。コマンドの mail と rcp は、このようなアプリケーションの一例です。
rcp は、sirius:/usr/jsmith/memo などの複合名を使用します。これは、ホスト名 sirius とファイル名 (パス) /usr/jsmith/memo の 2 つの構成要素からなります。mail プログラムは、jsmith@altair などの複合名を使用します。これは、ユーザ名 jsmith とホスト名 altair の 2 つの構成要素からなります。
各アプリケーションは、独自の名前作成規則を定義し、複合名を構文解析して、複合名を解決します。複合規則は、通常、アプリケーションごとに異なります。
FNS がない場合、ユーザーは、どのアプリケーションで複合ネーミングが可能であり、どれが可能でないかを覚えておく必要があります。たとえば、複合名 sirius:/tmp/saleslist は、rcp コマンドでは受け入れられますが、cp コマンドでは受け入れられません。
FNS がない場合、ユーザーは、アプリケーションごとに使用される異なる作成規則も覚えておく必要があります。独自の複合名をサポートするアプリケーションは、小さい特定のネーミングシステムしか使用できません。また、新しいタイプのネーミングシステムが追加されるたびに変更する必要があります。
複合ネーミングの一貫したポリシーを、コンピューティングプラットフォームに組み込むと、どのアプリケーションでも一貫した方法で複合名をサポートできます。アプリケーションは、1 つの名前を 1 つのインタフェースに渡します。
FNS ポリシーには、次の原則があります。
「特定のオブジェクトに対応して他のオブジェクトをネーミングする場合、そのオブジェクトはネーミングコンテキストとなる」
たとえば、ユーザーに対応してさまざまな事柄をネーミングする場合、ユーザーオブジェクトがネーミングコンテキストになります。
「共通構成要素を使用した名前の作成が可能」
これにより、ユーザーが覚える必要がある名前の数が減り、アプリケーションとユーザーによる、共通構成要素とその論理構成に関する知識に基く名前の作成が容易になります。
「名前は視覚的で自明のものでなければならない」
たとえば、FNS 名 /user/wong/service/calendar は、ユーザー Wong によって使用されるカレンダサービスを明示します。これに対して、カレンダ名 wong@deneb は、Wong のカレンダサービスが提供されるホスト (deneb) を表します。ただし、他のユーザーにとって、ホスト名は余分であり、検索しにくく覚えずらいので、このユーザーのカレンダとホストの間に明確な関連性はありません。
「1 つのコンテキストで間に合う場合には、2 つのコンテキストを使用しない。」
上記の例では、メールアドレス、カレンダ、ファイルのディレクトリを、ユーザー Wong に対応してネーミングした方が効果的です。コンテキストとその名前を共有すると、ネーミングの整合性が高まり、管理が簡単になります。
Solaris 環境での FNS 実装は、現在次のものの上に実装されたネームサービスで構成されています。
NIS+、NIS、ローカルファイル、などの組織レベルのネームサービス (「Solaris エンタープライズレベルのネームサービス」を参照)
ファイルネーミング、プリンタネーミング、他のアプリケーションのサポート (第 25 章「ファイルコンテキストの管理」を参照)
DNS と X.500/LDAP を使用するグローバルレベルのネーミングシステム (第 26 章「FNS およびグローバルネーミングシステム」を参照)
FNS は、FNS を使用するアプリケーションとシステムが増えるほど、Solaris のユーザーには利用しやすいものとなります。
「エンタープライズレベル」のネームサービスは、エンタープライズレベルのネットワーク内のマシン (ホスト)、ユーザー、ファイルを識別 (ネーミング) します。FNS でも、組織ユニット、地理的なサイト、アプリケーションサービスのネーミングが可能です。「エンタープライズレベル」のネットワークは、ケーブル、赤外線、ラジオブロードキャストを通して通信する単一のローカルエリアネットワーク (LAN) にできます。または、ケーブルや直接通話接続によってリンクされた複数の LAN にできます。エンタープライズレベルのネットワーク内では、DNS や X.500/LDAP などのグローバルネームサービスを参照しなくても、すべてのマシンが他のマシンと通信できます。
FNS は現在、次に 3 つのエンタープライズレベルのネームサービスをサポートしています。
NIS+
下記の、「FNS と NIS+ のネーミング」、「FNS ポリシーと NIS+ との関連」、「FNS と NIS+ の詳細情報」を参照
NIS
詳細は、「FNS と NIS のネーミング」、「FNS ポリシーと NIS の関連」、「FNS と NIS の詳細情報」を参照
ファイル
詳細は、「FNS とファイルベースのネーミング」、「FNS ポリシーとファイルベースのネーミングの関連」、「FNS とファイルベースのネーミングの詳細情報」を参照
FNS とエンタープライズレベルネームサービスの管理情報については、第 23 章「FNS とエンタープライズのネームサービス」を参照してください。
NIS+ とその用語については、このマニュアルのパート I「ネーミングの紹介」と用語集を参照してください。典型的な NIS+ 環境の構造を理解しておくと有効です。
NIS+ は、Solaris 環境で推奨される組織規模の情報サービスです。NIS+ では、NIS とローカルファイルの両方を使用できます。NIS+ を使用すると、ドメインとサブドメインからなる階層組織レベルに組織を分割できます。
FNS 組織ユニットは、NIS+ のドメインとサブドメインに対応します。各ドメインとサブドメインに 1 つの orgunit コンテキストがあります。
FNS は NIS+、NIS、ローカルファイルをフェデレートして、Solaris 環境でのネーミングポリシーをサポートします。FNS はこのために、organization、site、user、host の各オブジェクトに対してネーミング操作を実行するための XFN インタフェースを提供します。このインタフェースは、ファイル、ディレクトリ、テーブルにアクセスするために適切なプログラミングインタフェースを使用して、これらの操作を実装します。
NIS+ のもとでは、FNS コンテキストと属性データは、NIS+ タイプテーブルに格納されます。これらのテーブルは、ctx_dir という名前の NIS+ タイプのディレクトリオブジェクトに格納されます。各 NIS+ ドメインとサブドメインに ctx_dir ディレクトリオブジェクトがあり、ドメインの groups_dir と org_dir ディレクトリオブジェクトと同じレベルにあります。したがって、ディレクトリオブジェクト ctx_dir.sales.doc.com. には、sales.doc.com ドメインの FNS コンテキストと属性データを格納する FNS テーブルが含まれます。
NIS+ では、FNS と NIS+ のコマンドを使用して、FNS テーブル内の情報を処理します。これらのテーブルを直接編集したり、UNIX コマンドで操作したりしないでください。
NIS は Solaris 環境でのエンタープライズ規模の情報サービスです。ローカルファイルは、NIS とともに使用できます。NIS のもとでは、エンタープライズは単一の NIS ドメインとして構成されます。
各エンタープライズは、単一の NIS ドメインです。1 つの NIS ドメインに対応して、1 つの FNS エンタープライズユニットがあります。
FNS は、NIS とローカルファイルをフェデレートして、Solaris 環境でのネーミングサービスをサポートします。FNS はこのために、organization、site、user、host の各マップに対してネーミング操作を実行するための XFN インタフェースを提供します。このインタフェースは、ファイル、ディレクトリにアクセスするために適切なプログラミングインタフェースを使用して、これらの操作を可能にします。
NIS では、FNS コンテキストと属性データは NIS マップに格納されます。これらのマップは、NIS サーバー上の /var/yp/domainname ディレクトリに格納されます。NIS では、スーパーユーザーが FNS コマンドを使用して、FNS マップ内の情報を処理できます。
一定の条件が合えば、NIS クライアント (マシン、プロセス、またはユーザー) はすべて、fncreate_fs や fncreate_printer などの FNS コマンドを使用して、クライアント自身のコンテキストを更新できます。これにより、NIS クライアントは、FNS コマンドを使用して、Printer Administrator、CDE カレンダマネージャ、admintool などを更新できます。
スーパーユーザー以外のユーザーが、FNS コマンドによって各自のコンテキストを更新するには、次の条件が必要です。
SKI (Secure Key_management Infrastructure) が NIS マスターサーバー上で使用可能
fnsypd デーモンが NIS マスターサーバー上で実行されている。このデーモンは、スーパーユーザー特権を持つユーザーが開始する
クライアントユーザーまたはマシンだけが各自のコンテキストを更新できる
クライアントは、要求された更新の実行権限を持っている
「ファイル」とは、通常、マシンの /etc ディレクトリにあるネーミングファイルのことを指します。これらのマシンベースのファイルには、UNIX ユーザーとパスワードの情報、ホスト情報、メールエイリアスなどが入っています。これらは、オートマウントマップなどの Solaris 特定のデータもサポートします。
FNS は、ローカルファイルをフェデレートして、Solaris 環境でのネームサービスをサポートします。FNS はこのために、organization、site、user、host の各ファイルに対してネーミング操作を実行するための XFN インタフェースを提供します。これらの操作は、ファイル、ディレクトリにアクセスするための適切なプログラミングインタフェースを使用して実装されます。
ファイルベースのネーミングシステムでは、FNS コンテキストと属性は、ファイルに格納されます。これらのファイルは、NFS ファイルサーバーからエクスポートされた /var/fn ディレクトリに格納されます。
ファイルベースのネーミングシステムでは、FNS コマンドを使用して、FNS ファイル内の情報を処理します。
グローバルネームサービスは、電話、衛星などの通信システムによって世界中でリンクされた組織レベルのネットワークを識別 (ネーミング) します。この世界規模でリンクされたネットワークの集合は、「インターネット」と呼ばれています。ネーミングネットワークだけでなく、グローバルネームサービスも、ネットワーク内の個々のマシンとユーザーを識別します。
FNS は現在、次の 2 つのグローバルネームサービスをサポートしています。
DNS
詳細は、「FNS と DNS」、「DNS でフェデレートする」を参照
X.500/LDAP
エンタープライズレベルのネームサービスが NIS+ または NIS の場合、グローバルネームサービスだけをフェデレートできます。ファイルベースのネームサービスをエンタープライズで使用している場合は、DNS も X.500/LDAP もフェデレートできません。
FNS とエンタープライズレベルネームサービスの管理情報については、第 26 章「FNS およびグローバルネーミングシステム」を参照してください。
インターネットドメイン名システム (DNS) は、世界のインターネットにホストとドメインの名前解決を提供するネームサーバーの階層集合です。FNS は DNS を使用してエンタープライズオブジェクトをグローバルにネーミングします。
ドメイン名とは、DNS がエンタープライズレベルネットワーク (LAN または WAN) を識別するために使用する名前のことをいいます。NIS+ を使用するネットワークでは、親ドメイン内でのサブドメインの作成が可能であり、DNS はこのようなサブドメインを識別できます。
名前は、インターネット上でアクセス可能なすべてのエンタープライズについて作成できます。したがって、名前は、これらのエンタープライズからエクスポートされたオブジェクトにも作成できます。FNS と DNS の詳細は、「DNS でフェデレートする」を参照してください。
X.500 はグローバルディレクトリサービスです。この各構成要素は、世界規模の範囲内のオブジェクトに関する情報を管理するためにともに機能します。このようなオブジェクトには、国、組織、ユーザー、マシンが含まれます。FNS は、X.500 をフェデレートして、エンタープライズネームサービスへのグローバルアクセスを可能にします。次の 2 つの API のうち 1 つを使用して、X.500 グローバルディレクトリサービスにアクセスできます。
XDS/XOM API
LDAP (軽量ディレクトリアクセスプロトコル) API
X.500 のフェデレートについては、「X.500/LDAP でフェデレートする」を参照してください。
FNS は、次のものをサポートします。
Solaris NFS ファイルサービス (下記の、「FNS ファイルネーミング」を参照)
プリンタネーミング (下記の、「FNS プリンタネーミング」を参照)
その他のアプリケーション ( 下記の、「FNS アプリケーションサポート」を参照)
FNS ベースのファイルネーミングは、FNS ネーミングを Solaris ファイルサービスに統合します。FNS ベースのファイルネーミングを使用すると、他のファイルに関連しないアプリケーションと共有される FNS ポリシーによって、ユーザー、ホスト、サイト、組織に対応してファイルをネーミングできます。
FNS ベースのファイルネーミングは、クライアントに対して、グローバルかつエンタープライズ規模のファイル名前空間の共通表示を提供します。ファイルシステムにアクセスする Solaris アプリケーションは、FNS によってサポートされるファイル名前空間に、変更せずにアクセスできます。
FNS ベースのプリンタネーミングは、バンドルされていない SunSoft Print Client (SSPC) の基本ネーミング機能となります。FNS ベースのプリンタネーミングを使用すると、他の印刷関連ではないアプリケーションと共有される FNS ポリシーを使用して、ユーザー、ホスト、サイト、組織に対応してプリンタをネーミングできます。
FNS ベースのプリンタネーミングは、クライアントに対して、グローバルかつエンタープライズ規模のプリンタ名前空間の共通表示を提供します。また、これを使用すると、プリンタ名前空間を中央で管理できます。
FNS を認識するアプリケーションでは、名前空を FNS ポリシーに従って構成できます。また、FNS 名前空で名前を割り当てるアプリケーションは、これらのポリシーに従う必要があります。
アプリケーションは、FNS を次の 3 つの方法で使用します。
「アプリケーションは、FNS インタフェースとポリシーを使用すればクライアントとなる。」
ファイルシステム、印刷サービス、デスクトップツール (カレンダマネージャ、ファイルマネージャ) などのアプリケーションレベルのユーティリティは、FNS インタフェースを直接使用するクライアントの一例である
「アプリケーションは、既存のインタフェースにより FNS を使用できる。」
FNS の大部分は、既存のアプリケーションプログラミングインタフェースにより使用される。たとえば、後で UNIX open() 関数に与えられるファイル名を獲得する UNIX アプリケーションを例にとる。この場合、FNS サポートを使用してファイル名を解決すると、アプリケーションは、処理対象の文字列が従来のローカルパス名ではなく複合名であることを認識しなくてもすむ。したがって、アプリケーションの多くは、変更なしに合成名をサポートできる
「システムが FNS インタフェースをエクスポートできる。」
DNS や X.500 などのネーミングシステム、ファイルシステムや印刷サービスなどのサービスに組み込まれたネーミングシステムは、FNS インタフェースをエクスポートするネーミングシステムの例である
FNS システムの管理は、基本となるネームサービスによって異なります。
「NIS+」
NIS+ では、FNS システム管理タスクは、その権限を持つユーザーだけが実行できる。システム管理特権は、通常、NIS+ グループを作成して、そのグループにドメインで必要な特権を割り当てることによって付与される。これにより、グループのメンバーはすべて、システム管理機能を実行できる
「NIS」
NIS では、NIS マスターサーバー上の root が FNS 管理タスクを実行しなければならない
「ファイルベース」
ファイルベースのネーミングシステムでは、/var/fn ディレクトリに root アクセス権を持つユーザーが、FNS 管理タスクを実行しなければならない
各自のユーザーサブコンテキストをユーザーが変更できるかどうかは、基本となるネームサービスによって異なります。
「NIS+」
NIS+ では、ユーザーのコンテキスト (およびサブコンテキスト) は、ユーザーが所有する。NIS+ のポリシーでログインした場合、適切な資格と特権を持つユーザーは、fncreate、fnbind、fnunbind などのコマンドを使用して、各自のコンテキストを変更できる
「NIS」
NIS では、ユーザーはどの FNS データも変更できない。NIS マスターサーバーの root アクセス権を持つユーザーだけが FNS データを変更できる
「ファイルベース」
ファイルベースのネーミングシステムでは、ユーザーが独自のコンテキストを所有する。標準 UNIX アクセスでは、FNS ファイルへの適用が制御される
一般的な FNS の問題を追跡して解決する方法については、「FNS の問題と対策」を参照してください。FNS のエラーメッセージは、付録 B 「エラーメッセージ」 に記載されています。
この章では、FNS ポリシーについて説明します。
XFN は、フェデレートされた名前空間にあるオブジェクトをネーミングするためのポリシーを定義します。これらのポリシーは、次のような目的を持っています。
統一性のある複合名を簡単に作成する
アプリケーションおよびサービスでネーミングの一貫性を持たせる
簡単ながら十分な機能をもつポリシーを提供し、アプリケーションで特定環境に特別のポリシーを作成したり、実行したりする必要をなくす
アプリケーションの移植性を拡張する
異機種システム混在コンピュータ環境でのプラットフォーム同士の相互運用性を高める
FNS ポリシーには、すべての XFN ポリシーと Solaris 環境用の拡張機能が含まれます。
現在、コンピュータ環境は世界的な規模となり、広範囲なサービスを提供しています。ユーザーは、どのレベルのコンピュータ環境のサービスにもアクセスできます。FNS ポリシーは、グローバル、エンタープライズ、アプリケーションの 3 つのレベルのサービスに共通の枠組みを提供します。
FNS は、ネームサービスをどのように調整して使用するかについて次のようなポリシーをアプリケーション側に提供します。
エンタープライズ名前空間をフェデレートして、グローバル名前空間でアクセス可能にする方法を指定する
各プロセスの初期コンテキストにある名前およびバインドを指定する
組織、ホスト、ユーザー、サイト、ファイル、サービスなどのエンタープライズのオブジェクトに対するネームサービス
組織、ホスト、サイト、ファイル、サービスのエンタープライズのオブジェクト間の関係を定義する
これらのエンタープライズのオブジェクトのリファレンスに使用される名前の構文を指定する
FNS ポリシーでは、次のものは指定されません。
ネームサービスで使用される実際の名前
アプリケーション内のネーミング。アプリケーションレベルのネーミングは、個別のアプリケーションまたは関連アプリケーションのグループで行われる
オブジェクトがネーミングされた後に使用する属性
FNS ポリシーでは、エンタープライズ内の名前空間のタイプおよび配列と、アプリケーションが名前空間を使用する方法が指定されます。たとえば、名前空間が他のどの名前空間と関連するかが指定されます。ここで説明する FNS ポリシーには、XFN ポリシーへの拡張機能があります。これらは、注釈によって明確に定義されます。
FNS エンタープライズのポリシーでは、名前空間内でのエンタープライズのオブジェクトの配列が処理されます。各エンタープライズのオブジェクトは、独自の名前空間を持っています。
デフォルトでは、FNS には 7 つのエンタープライズオブジェクトと対応する名前空間があります。
「組織」(orgunit)
部、センター、課などのエンティティ。サイト、ホスト、ユーザー、サービスには、組織に関連する名前を付けることができる。組織に対する XFN 用語は、「組織単位」となる。初期コンテキストで使用されたときは、識別子 org は、orgunit の別名として使用できる
「サイト」(site)
「ホスト」(host)
「ユーザー」(user)
「ファイル」(fs)
「サービス」(service)
「プリンタ」(service/printer)
図 22-1 は、エンタープライズの名前空間が配列される方法を示しています。
ユーザーやホストなどの名前空間には、フェデレートされた名前空間で複数回表示されるものもあります。
これらの名前空間に適用されるポリシーは、表 22-2 に要約しています。
エンタープライズ名前空間は、フェデレートされた名前空間の原子名によって参照されます。
XFN では、先行する下線 (_) 文字を使用して、エンタープライズ名前空間の識別子が示されます。たとえば、_site となります。FNS では、下線 (_) なしの識別子の使用もサポートされます。下線なしの名前は、XFN ポリシーの範疇には入りません。site および printer のコンテキストも、XFN ポリシーの範疇には入りません。これらの原子名は、表 22-1 に挙げられています。
表 22-1 エンタープライズでのエンタープライズ名前空間の識別子
名前空間 |
XFN 識別子 |
FNS 識別子 |
解釈処理 |
---|---|---|---|
組織 |
_orgunit |
orgunit または org |
組織単位をネーミングするためのコンテキスト |
サイト |
_site |
site |
サイトをネーミングするためのコンテキスト |
ホスト |
_host |
host |
ホストをネーミングするためのコンテキスト |
ユーザー |
_user |
user |
ユーザーをネーミングするのためのコンテキスト |
ファイルシステム |
_fs |
fs |
ファイルをネーミングするためのコンテキスト |
サービス |
_service |
service |
サービスをネーミングするためのコンテキスト |
プリンタ |
|
printer |
プリンタをネーミングするためのコンテキスト (サービスの名前空間に従属) |
XFN の用語では、先行する下線のある名前は、「正規」名前空間識別子です。下線のない名前は、Solaris 環境用に「カスタマイズ」された名前空間識別子です。これらのカスタマイズされた名前空間識別子に printer を追加しても、Solaris 以外の環境では認識されません。正規の名前空間識別子は、他の環境でも常に認識され、互換性があります。
XFN 構成要素の区切り文字 (/) で、名前空間識別子を区切ります。たとえば、名前空間識別子 orgunit を組織単位名 west.sales とともに作成すると、複合名は orgunit/west.sales となります。
FNS では、次の 7 つの名前空間が提供されます。
「組織」(「組織単位の名前空間」を参照)
「サイト」(「サイトの名前空間」を参照)
「ホスト」(「ホストの名前空間」を参照)
「ユーザー」(「ユーザーの名前空間」を参照)
「ファイル」(「ファイルの名前空間」を参照)
「サービス」(「サービスの名前空間」を参照)
「プリンタ」(「サービスの名前空間」を参照)
組織単位の名前空間では、エンタープライズのサブ単位をネーミングするために階層になった名前空間が提供されます。各組識単位名は組織単位を表す「組織単位コンテキスト」と結合されています。組織単位名は、接頭辞 org/、orgunit/、または _orgunit/ によってネーミングされます。短縮形別名の org/ は、内部コンテキストだけで使用され、複合名の途中では使用されません。「エンタープライズ内のネーミングに対する初期コンテキストのバインド」および、「複合名の例」を参照してください。
NIS+ 環境では、組織単位は NIS+ のドメインおよびサブドメインに対応します。
NIS+ では、組織単位は必ずドメインおよびサブドメインにマップされます。それぞれの NIS+ ドメインおよびサブドメインに組織単位を与える必要があります。ドメインまたはサブドメインに論理、組織ユニットを与えることはできません。つまり、NIS+ ドメインまたはサブドメインを小規模な組織単位に分割することはできません。そのため、NIS+ ドメイン doc.com. と 2 つのサブドメイン sales.doc.com. および manf.doc.com. がある場合は、これら 3 つのドメインに対応する 3 つの FNS 組織単位を持つ必要があります。
組織単位は、ドットで区切られた右から左への複合名を使用してネーミングされます。ここでは、各原子要素がより大きな単位内の組織単位をネーミングします。たとえば、org/sales.doc.com. という名前は、doc.com. という名前のより大きな単位内にある sales をネーミングします。この例では、sales は、doc.com. の NIS+ サブドメインです。
組織単位名は、完全指定の NIS+ ドメインまたは相対名の NIS+ 名のどちらかになります。完全指定名には終端にドットが付きますが、相対名には付きません。そのため、終端のドットが組織名にある場合は、その名前は完全指定の NIS+ ドメイン名として処理されます。終端にドットがない場合は、その組織名は最上部の組織階層に対して相対的に解釈処理されます。たとえば、orgunit/west.sales.doc.com. は、west 組織単位をネーミングする完全指定名で、_orgunit/west.sales は、同じサブドメインをネーミングする相対的な名前です。
NIS 環境では、NIS ドメインに対応する組織単位は各エンタープライズ 1 つずつあります。この orgunit には、orgunit/domainname という名前が付けられ、ここでの domainname は NIS ドメイン名です。たとえば、NIS ドメイン名が doc.com である場合は、組織単位は org/doc.com です。
NIS 環境では、空の文字列を組織単位の省略形として使用できます。したがって、org// は、org/domainname に相当します。
エンタープライズレベルのネームサービスがファイルベースであるときには、1 つだけの FNS 組織単位が存在し、サブ単位はありません。ファイルベースのネーミングで許容される唯一の組織単位は org// です。
サイトの名前空間では、物理的位置でそのまま識別される地域名前空間が提供されます。たとえば、これらのオブジェクトには、キャンパスにある建物、ある階のマシンやプリンタ、建物内の会議室とその使用スケジュール、隣接するオフィスにいるユーザーなどがあります。サイト名は、接頭辞 site/ または _site/ で識別されます。
Solaris 環境では、サイトは複合名を使用してネーミングされます。複合名では、各原子名がより大きなサイト内のサイトを表わします。サイト名の構文は、ドット区切りの右から左であり、もっとも一般的な位置記述からもっとも特定の位置記述に配列された構成要素が含まれます。たとえば、_site/pine.bldg5 は、建物 5 にある Pine 会議室を表わし、site/bldg7.alameda は、あるエンタープライズの Alameda にある建物 7 を表わします。
ホストの名前空間では、コンピュータをネーミングするための名前空間が提供されます。ホスト名は、接頭辞 host/ または _host/ で識別されます。たとえば、host/deneb は、deneb という名前のマシンを識別します。
ホストは、「hostname」コンテキストでネーミングされます。ホストコンテキストには、フラットな名前空間があり、ホストコンテキストへのホスト名のバインドが含まれます。「ホストコンテキスト」では、そのホストで見つかったファイルやプリンタなどの、マシンに相対的なオブジェクトをネーミングできます。
Solaris 環境では、ホスト名は Solaris のホスト名に対応します。単一のマシンに対する別名で同じコンテキストが共有されます。たとえば、mail_server という名前がマシン deneb および altair の別名である場合、deneb と altair の両方で、mail_server に作成されたコンテキストが共有されます。
ネットワーク資源は、必要に応じてホストに関連付けてネーミングする必要があります。たいていの場合、組織、ユーザー、サイトなどの構成要素に関連して資源をネーミングした方がわかりやすくなります。ホスト名に依存すると、ユーザーは、あいまいで変更される可能性のある情報を覚えなくてはならなくなります。たとえば、ハードウェアの変更、ファイルスペースの使用、ネットワークの再構成などのために、ユーザーのファイルがあるサーバーから他のサーバーに移動されてしまう場合もあります。さらに、ユーザーは、同じファイルサーバーを共有することが多くなり、ファイルがホストに関連付けてネーミングされた場合に混乱を招きます。しかし、ファイルがユーザーに関連付けてネーミングされた場合は、このような変更はファイルのネーミング方法に影響しません。
ホスト名を使用した方が適切な場合もあります。たとえば、資源が特定のマシンだけで使用可能であり、他の構成要素に関連付けてその資源をネーミングする論理的方法がない場合には、ホストに関連付けてネーミングする意味があります。または、ファイルシステムでは、ファイルが多くのユーザーに共有されている場合、格納されているマシンに関連付けてファイルをネーミングする意味があります。
ユーザーの名前空間では、コンピュータ環境内のユーザーをネーミングするための名前空間が提供されます。ユーザー名は、接頭辞 user/ または _user/ で識別されます。
ユーザーは、「ユーザーコンテキスト」でネーミングされます。ユーザーコンテキストには、単一レベルの名前空間があり、「ユーザーコンテキスト」へのユーザー名のバインドが含まれます。ユーザーコンテキストでは、ユーザーに関連するファイル、サービス、資源などのオブジェクトをユーザーに関連付けてネーミングすることができます。
Solaris 環境では、ユーザー名は Solaris ログイン ID に対応します。たとえば、_user/inga は、ログイン ID が inga のユーザーを識別します。
ファイルの名前空間 (またはファイルシステム) では、ファイルをネーミングするための名前空間が提供されます。ファイル名は、接頭辞 fs/ または _fs/ で識別されます。たとえば、fs/etc/motd という名前では、/etc ディレクトリに格納されているファイル motd が識別されます。
ファイルの名前空間については、「FNS ファイルネーミング」で詳しく説明し、ファイルのコンテキストについては、「ファイルコンテキストの管理」で説明します。
サービスの名前空間では、エンタープライズ内のオブジェクトに使用される、または関連するサービスのための名前空間が提供されます。このようなサービスには、電子カレンダ、FAX、メール、印刷などがあります。サービス名は、接頭辞 service/ または _service/ で識別されます。
Solaris 環境では、サービスの名前空間は階層になっています。サービス名は、スラッシュ (/) で区切られた左から右の複合名です。サービスの名前空間を使用するアプリケーションは、この階層属性を利用し、そのアプリケーションのサブツリーを獲保します。たとえば、プリンタサービスはサービスの名前空間のサブツリー printer を獲保します。
FNS は、サービス名またはリファレンスタイプが選択される方法を指定します。これらは、サービスの名前空間を共有するサービス提供者によって決定されます。たとえば、カレンダサービスは、サービスのコンテキストにある名前 _service/calendar を使用してカレンダサービスをネーミングし、名前 calendar にバインドされたものを決定します。
米国 Sun Microsystems, Inc. は、service の名前空間の最初のレベルにある名前の登録を行います。新規名を登録するには、電子メールのリクエストを fns-register@sun.com まで送信するか、または書面で次の住所までご郵送ください。
FNS Registration Sun Microsystems, Inc. 901 San Antonio Road. Palo Alto, CA 94303 U.S.A. |
名前の使用目的についての簡単な説明と、その名前にバインドされるリファレンスのフォーマットの説明をお書き添えください。
プリンタの名前空間では、プリンタをネーミングするための名前空間が提供されます。プリンタの名前空間は、サービスの名前空間に関連 (従属) します。つまり、プリンタのサービスは、サービスの名前空間のサービスの一部です。プリンタ名は、接頭辞 service/printer または _service/printer で識別されます。たとえば、service/printer/laser1 では、laser1 という名前のプリンタが識別されます。
後続の / は、次のネーミングシステムにあるオブジェクトをネーミングします。あるネーミングシステムから他のネーミングシステムに移動するときに必ず必要となります。たとえば、名前 org/east.sales/service/printer では、org と east.sales の間のスラッシュは、上で説明した構成要素の区切り文字であり、組織名 (sales/) の最後の要素に続くスラッシュは、service 名前空間を組織単位名前空間から区切ります。したがって、org/west.sales/service/printer では、west.sales という組織単位の printer サービスがネーミングされます。
FNS は、表 22-1 に挙げたすべての原子名をそれ自身の使用のために名前空間識別子として獲保します。たとえば、_orgunit、org、_site、site などです。この制限事項は、「エンタープライズ名前空間の構造」にある名前空間の配列で定義されているように、名前空間識別子が現れるコンテキストに適用されます。それ以外の場合は、FNS は、他のコンテキストではこれらの原子名の使用を制限します。
たとえば、原子名 service は、user/fatima/service/calendar のように、ユーザー名に相対的な名前空間識別子として使用され、ユーザー fatima のサービスの名前空間のルートであることを意味します。FNS では、名前 user/ がバインドされるコンテキストは、名前空間識別子にではなく、ユーザー名に指定されるため、user/service のようにユーザー名として名前 service を使用することが禁止されるわけではありません。この場合、service は明確にユーザー名として解釈されます。一方で、/user/mikhail を使用すると、ユーザー mikhail とファイル (またはサブディレクトリ) /user/mikhail の区別がつきにくくなるため、user という名前のディレクトリは作成しないでください。
この項では、FNS ポリシーに従う名前の例を示します。これらのポリシーについては、表 22-2 を参照してください。
組織名、サイト名、ユーザー名、ホスト名、ファイル名、サービス名 (calendar や printer など) の名前は、例として使用されています。これらの名前は、FNS ポリシーでは指定されません。
組織の名前空間 (_orgunit、orgunit、または org) に関連付けることのできる名前空間は、user、host、service、fs、と site です。
以下に例を示します。
orgunit/doc.com/site/videoconf.bldg-5 では、組織 doc.com に関連するサイトの建物 5 にある会議室 videoconf がネーミングされる (orgunit に別名 org を使用して、org/doc.com/site/videoconf.bldg-5 を作成することもできる)
orgunit/doc.com/user/mjones では、組織 doc.com のユーザー mjones がネーミングされる
orgunit/doc.com/host/smptserver1 では、組織 doc.com に所属するマシン smptserver1 がネーミングされる
orgunit/doc.com/fs/staff/agenda9604/ では、組織 doc.com に所属するファイル staff/agenda9604 がネーミングされる
orgunit/doc.com/service/calendar では、組織 doc.com の calendar サービスがネーミングされます。ここでは、組織の会議スケジュールを管理する
user の名前空間に関連付けることができる名前空間は、service および fs です。
user/helga/service/calendar では、helga という名前のユーザーの calendar サービスがネーミングされる
user/helga/fs/tasklist では、ユーザー helga のホームディレクトリにあるファイル tasklist がネーミングされる
hosts の名前空間に関連付けることができる名前空間は、service および fs です。
host/mailhop/service/mailbox では、マシン mailhop と関連する mailbox サービスがネーミングされる
host/mailhop/fs/pub/saf/archives.96 では、マシン mailhop によってエクスポートされたファイルシステムのルートディレクトリにあるディレクトリ pub/saf/archives.96 がネーミングされる
sites の名前空間に関連付けることができる名前空間は、service および fs です。
site/bldg-7.alameda/service/printer/speedy では、bldg-7.alameda サイトにあるプリンタ speedy がネーミングされる
site/alameda/fs/usr/dist では、alameda サイトで使用可能なファイルディレクトリ usr/dist がネーミングされる
ファイル (fs) またはサービス (service) の名前空間に関連付けることができる名前空間はありません。たとえば、/services/calendar/orgunit/doc.com などの名前は作成できません。つまり、ファイルまたはサービスの名前空間に関連付けた複合名は作成できません。もちろん、/user/esperanza/service/calendar のように、他の名前空間に関連付けてファイル名またはサービス名を作成することは可能です。
FNS ポリシーでは、エンタープライズ名前空間の構造が定義されます。この構造の目的は、統一性のある名前を簡単に作成することです。このエンタープライズ名前空間構造には、2 つの主要なルールがあります。
狭い有効範囲のオブジェクトは、広い有効範囲のオブジェクトに関連してネーミングされる
名前空間識別子は、ある名前空間から次の名前空間への移行を表すために使用される
表 22-2 は、エンタープライズ名前空間を配列するための FNS ポリシーのまとめです。図 22-2 に、これらの FNS ポリシーに従う名前空間の配置の例を示します。
表 22-2 フェデレートされたエンタープライズ名前空間用のポリシー
名前空間 識別子 |
従属する名前空間 |
親コンテキスト |
名前空間編成 |
構文 |
---|---|---|---|---|
orgunit _orgunit org |
サイト、ユーザー、ホスト、ファイルシステム、サービス |
エンタープライズのルート |
階層 |
ドット区切り、右から左 |
site _site |
サービス、ファイルシステム |
エンタープライズのルート、組織単位 |
階層 |
ドット区切り、右から左 |
user _user |
サービス、ファイルシステム |
エンタープライズのルート、組織単位 |
フラット |
Solaris ログイン名 |
host _host |
サービス、ファイルシステム |
エンタープライズのルート、組織単位 |
フラット |
Solaris ホスト名 |
service _service |
アプリケーション固有 |
エンタープライズのルート、組織単位、サイト、ユーザー、ホスト |
階層 |
/ 区切り、左から右 |
fs
_fs |
なし |
エンタープライズのルート、組織単位、サイト、ユーザー、ホスト |
階層 |
/ 区切り、左から右 |
printer |
なし |
サービス |
階層 |
/ 区切り、左から右 |
エンタープライズの名前空間は、組織単位の周辺に構成されます。適切な名前空間識別子とオブジェクト名を使用して組織単位名を作成して、サイト、ホスト、ユーザー、ファイル、サービスの名前は、組織単位に関連付けてネーミングできます。
図 22-2 では、エンタープライズの sales 組織の西部事業部のユーザー myoko は、名前 orgunit/west.sales/user/myoko を使用してネーミングされます。
名前空間識別子 user を使用して、orgunit 名前空間から user 名前空間への移行を表していることに注意してください。同様に (適切な名前空間識別子を使用して)、ファイル名およびサービス名も、サイト、ユーザー、またはホストの名前に関連付けてネーミングできます。サイト名は、組織単位名に関連付けてネーミングできます。
簡単に均質な名前を作成することは、この構造を使用して達成されます。たとえば、エンタープライズ (orgunit/west) 内の組織単位名が分かれば、user の名前空間識別子とユーザーのログイン名で名前を作成して orgunit/west/user/josepha などの名前を作成し、エンタープライズに関連付けてユーザーをネーミングできます。
このユーザーのファイルシステムにあるファイルをネーミングするときには、orgunit/west/user/josepha/fs/notes などの名前を使用できます。
エンタープライズのルートコンテキストは、エンタープライズ名前空間のルートレベルにあるオブジェクトをネーミングするためのコンテキストです。エンタープライズのルートは、グローバルの名前空間でバインドされます。
エンタープライズのルートをネーミングする方法には、次の 2 つがあります。
.../rootdomain
org//
.../rootdomain/ を使用して、エンタープライズのルートを識別できます。
最初の 3 つのドット (...) は、グローバルのコンテキストを示す原子名 (「グローバル名前空間のポリシー」のグローバルのコンテキストについての説明を参照)
rootdomain/ は、エンタープライズのルートドメイン。たとえば、doc.com/ など
したがって、.../doc.com/ では、ルートドメインが doc.com である会社のエンタープライズのルートが識別されます。この例では、エンタープライズのルートに関連するサイトをネーミングするためのコンテキストは、.../doc.com/site/alameda または .../doc.com/site/alameda.bldg5 などの .../doc.com/site/ となります。
DNS のグローバルの建物を設定した場合は、.../rootdomain フォーマットだけを使用できます。
org// を使用して、エンタープライズのルートを識別できます。本質的に org// は、.../domainname/ に対する別名または機能的に相当するものです。org// を使用するときは、二重のスラッシュによって、ルートのエンタープライズコンテキストとそれに関連する名前空間が識別されます。
たとえば、org//site/alameda では、エンタープライズのルートに関連する Alameda サイトがネーミングされます。
反対に、org/ または orgunit/ (一重のスラッシュ) では、エンタープライズのルートに必ずしも相対的にネーミングされていない組織のコンテキストを示します。たとえば、org/sales/site/alameda のようになります。
次のオブジェクトは、エンタープライズのルートに関連付けてネーミングできます。
エンタープライズの組織単位
エンタープライズの最上位の組織単位にあるサイト (XFN ポリシーへの拡張)
エンタープライズの最上位の組織単位にいるユーザー
エンタープライズの最上位の組織単位にあるホスト
エンタープライズの最上位の組織単位に対するサービス
エンタープライズの最上位の組織単位に対するファイルサービス
これらのオブジェクトは、ターゲットオブジェクトの名前でターゲットオブジェクトの名前空間の名前空間識別子を作成して、ネーミングします。
組織のサブ単位は、エンタープライズのルートに関連付けてネーミングできます。
組織ルート名の場合は、orgunit または _orgunit のどちらかの名前空間識別子を使用して、従属する組織単位コンテキストに名前を作成できます。
たとえば、.../doc.com がエンタープライズ名である場合、組織単位にネーミングするためのコンテキストのルートは、.../doc.com/orgunit/ であり、組織単位名は .../doc.com/orgunit/sales や .../doc.com/orgunit/west.sales のようになります。または、 org//orgunit/sales でも同じ結果を得ることができます。
次のオブジェクトは、組織単位名に関連付けてネーミングできます。
その組織単位のサイト (XFN ポリシーからの拡張)
その組織単位にあるホスト
その組織単位にいるユーザー
その組織単位に対するサービス
その組織単位に対するファイルサービス
たとえば、名前 ...doc.com/orgunit/sales/service/calendar では、sales 組織単位のカレンダのサービスが識別されます。組織単位に関連付けてオブジェクトをネーミングする際の詳細は、「組織単位の名前空間」および 「組織に関連する名前を作成する」を参照してください。
サイトは、XFN ポリシーから拡張されています。
サイトは、次のものに関連付けてネーミングできます。
エンタープライズのルート
組織単位
エンタープライズのルートに関連付けてネーミングされたサイトは、最上位の組織単位に関連付けてネーミングされたサイトと同一になります。組織名の場合は、名前空間識別子の site または _site を使用して、サイトのコンテキストに名前を作成できます。たとえば、エンタープライズのルートが ../doc.com である場合、エンタープライズのルートに関連付けてサイトにネーミングするためのコンテキストは、../doc.com/site となります。サイトは、../doc.com/site/alameda のような名前になります。
次のオブジェクトは、サイト名に関連付けてネーミングできます。
サイトのスケジュールまたはカレンダ、プリンタ、および FAX などのサイトでのサービス
サイトで利用可能なファイルサービス
これらのオブジェクトは、ターゲットオブジェクトの名前空間とターゲットオブジェクト名の名前空間識別子でサイト名を作成して、ネーミングできます。たとえば、名前 site/Clark.bldg-5/service/calendar は、会議室 Clark.bldg-5 のカレンダのサービスでネーミングし、サイト名 site/Clark.bldg-5 とサービス名 service/calendar から作成されます。サイトに関連付けてオブジェクトにネーミングする際の詳細は、「サイトに関連する名前を作成する」を参照してください。
ユーザーは、次のものに関連付けてネーミングできます。
組織単位
エンタープライズのルート
エンタープライズのルートに関連付けてネーミングされたユーザーは、最上位の組織単位に関連付けてネーミングされたユーザーと同一になります。組織名の場合は、名前空間識別子の user または _user のどちらかを使用して、コンテキストに名前を作成できます。したがって、orgunit/east.sales で組織がネーミングされる場合は、orgunit/east.sales/user/hirokani で east.sales 組織単位にいるユーザー hirokani がネーミングされます。
次のオブジェクトは、ユーザー名に関連付けてネーミングできます。
ユーザーに関連するサービス
ユーザーのファイル
これらのオブジェクトは、ターゲットオブジェクトの名前空間とターゲットオブジェクト名の名前空間識別子でユーザー名を作成して、ネーミングされます。たとえば、名前 user/sophia/service/calendar では、ユーザー sophia に対するカレンダがネーミングされます。ユーザーに関連付けてオブジェクトにネーミングする際の詳細は、「ユーザーの名前空間」および 、「エンタープライズのルートとユーザー」を参照してください。
ホストは、次のものに関連付けてネーミングできます。
組織単位
エンタープライズのルート
エンタープライズのルートに関連付けてネーミングされたホストは、最上位の組織単位に関連付けてネーミングされたホストと同一になります。組織名の場合は、名前空間識別子の host または _host のどちらかを追加して、hostname のコンテキストに名前を作成できます。したがって、orgunit/west.sales で組織がネーミングされる場合は、名前 org/west.sales/host/altair で west.sales 組織単位にあるマシン altair がネーミングされます。
次のオブジェクトは、ホスト名に関連付けてネーミングできます。
ホストに関連するサービス
ホストによってエクスポートされたファイル
これらのオブジェクトは、ターゲットオブジェクトの名前空間とターゲットオブジェクト名の名前空間識別子でホスト名を作成して、ネーミングされます。たとえば、名前 host/sirius/fs/release では、マシン sirius によってエクスポートされたファイルディレクトリ release がネーミングされます。(ホストに関連付けてオブジェクトにネーミングする際の詳細は、「ホストの名前空間」および「ホストに関連する名前を作成する」を参照してください。)
サービスは、次のものに関連付けてネーミングできます。
組織単位
エンタープライズのルート
ユーザー
ホスト
サイト
エンタープライズのルートに関連付けてネーミングされたサービスは、最上位の組織単位に関連付けてネーミングされたサービスと同一になります。
サービスのコンテキストは、名前空間識別子 service または _service を使用して、関連する組織、サイト、ユーザー、またはホストに関連付けてネーミングされます。たとえば、orgunit/corp.finance で組織単位がネーミングされる場合は、orgunit/corp.finance/service/calendar で組織単位 corp.finance の calendar サービスがネーミングされます。ユーザーの名前空間および、ユーザーに関連付けてオブジェクトをネーミングする際の詳細は、「サービスの名前空間」および、「サービスおよびファイルに関連する名前を作成する」を参照してください。
FNS では、サービスの名前空間でのバインドのタイプが制限されるわけではありません。アプリケーションは、サービスのコンテキスト以外のタイプのコンテキストを作成し、サービスの名前空間でバインドできます。
FNS は、サービスのコンテキストに「汎用」コンテキストを作成することをサポートします。汎用コンテキストは、アプリケーション決定のリファレンスタイプを持つこと以外は、サービスのコンテキストに類似しています。汎用コンテキストの他のすべての属性は、サービスのコンテキストと同一です。
たとえば、World Intrinsic Designs Corp (WIDC) という名前の会社は、サービスの名前空間で名前 extcomm を獲保し、製品の外部通信ラインに関連するバインドを追加するための汎用コンテキストを参照します。extcomm にバインドされるコンテキストは、リファレンスタイプ WIDC_comm を持つ汎用コンテキストです。このコンテキストとサービスのコンテキストの違いは、このコンテキストが異なるリファレンスタイプを持っていることだけです。
サービス名は、「サービス名およびリファレンスの登録」で説明しているように、米国 Sun Microsystems, Inc. に登録する必要があります。
ファイルの名前空間は、次のものに関連付けてネーミングできます。
エンタープライズのルート
組織単位
ユーザー
ホスト
サイト
エンタープライズのルートに関連付けてネーミングされたファイルは、最上位の組織単位に関連付けてネーミングされたファイルと同一になります。ファイルのコンテキストは、名前空間識別子の fs または _fs を使用して、関連する組織、サイト、ユーザー、またはホストに関連付けてネーミングされます。たとえば、orgunit/accountspayable.finance で組織単位がネーミングされる場合は、名前 user/jsmith/fs/report96.doc でファイル report96.doc がネーミングされます。ユーザーのファイルサービスは、NIS+ の passwd テーブルで指定されているように、デフォルトではホームディレクトリになります。ユーザーの名前空間の詳細は、「ファイルの名前空間」 を参照してください。
この他には、ファイルシステムに従属するコンテキストのタイプはありません。
プリンタのコンテキストは、XFN ポリシーの拡張です。
プリンタの名前空間は、サービスのコンテキストでネーミングできます。プリンタのコンテキストは、名前空間識別子の printer を使用して、次のものに関連したサービスのコンテキストでネーミングされます。
組織単位
ユーザー
ホスト
サイト
たとえば、org/east.sales で組織単位がネーミングされる場合は、org/eastsales/service/printer では組織単位 east.sales のプリンタのサービスがネーミングされます。したがって lp1 という名前の固有のプリンタは、次のように識別されます。
org/east.sales/service/printer/lp1
この他には、プリンタに従属するコンテキストのタイプはありません。
初期コンテキストは、クライアントのユーザー、ホスト、およびアプリケーションがエンタープライズ名前空間の任意のオブジェクトに (結果的に) ネーミングできる開始点です。
図 22-3 に示すネーミングシステムは、初期コンテキストのバインドが影付きでイタリックになっている点を除いて図 22-2 に挙げたネーミングシステムと同一です。これらの初期コンテキストは、解決する名前を決定するユーザー、ホスト、またはアプリケーションの観点から示されています。
XFN では、「初期コンテキスト関数」の fn_ctx_handle_from_initial() が提供され、クライアントは初期コンテキストのオブジェクトを名前解決の開始点として得ることが可能になります。初期コンテキストには、名前空間識別子に対するフラットな名前空間があります。これらの初期コンテキスト識別子のバインドについては表 22-3 に要約し、その後の節でさらに詳細に説明しています。これらの名前は、必ずしもすべての初期コンテキストに表示されるわけではありません。たとえば、スーパーユーザーがプログラムを起動したときには、ホストとクライアントに関連するバインドのみが初期コンテキストに表示され、ユーザーに関連するバインドは表示されません。
表 22-3 エンタープライズ内のネーミングに対する初期コンテキストのバインド
名前空間 識別子 |
バインド |
---|---|
myself, _myself, thisuser |
名前解決しようとするユーザーのコンテキスト |
myens, _myens |
名前解決しようとするユーザーのエンタープライズのルート |
myorgunit, _myorgunit |
ユーザーの主要な組織単位のコンテキスト。たとえば、NIS+ 環境では、主組織単位はユーザーの NIS+ ホームドメインとなる |
thishost, _thishost |
名前解決しようとするホストのコンテキスト |
thisens, _thisens |
名前解決しようとするホストのエンタープライズのルート |
thisorgunit, _thisorgunit |
ホストの主要な組織単位のコンテキスト。たとえば、NIS+ 環境では、主組織単位はホストの NIS+ ホームドメインとなる |
user, _user |
ホストと同じ組織単位にいるユーザーがネーミングされるコンテキスト |
host, _host |
ホストと同じ組織単位にいるホストがネーミングされるコンテキスト |
org, orgunit, _orgunit |
ホストのエンタープライズにある組織単位の名前空間のルートコンテキスト。たとえば、NIS+ 環境では、これは NIS+ ルートドメインに対応する |
site, _site |
サイトの名前空間が構成された場合、最上位の組織単位にあるサイトの名前空間のルートコンテキスト |
XFN 用語では、接頭辞として使用される下線は、「正規」名前空間識別子と呼ばれます。この下線がなく、org および thisuser が追加された名前は、Solaris 用にカスタマイズされた名前です。Solaris カスタマイズの名前空間識別子は、他の Solaris 以外の環境で認識されるとは限りません。正規名前空間識別子は、他の環境でも必ず認識されるため移植性があります。
現在実装されている FNS では、初期コンテキストにある名前およびバインドの追加や修正はサポートされません。
初期コンテキストのバインドは、基本的に次の 3 つに分けられます。
ユーザーに関連するバインド (「ユーザーに関連するバインド」を参照)
ホストに関連するバインド (「ホストに関連するバインド」を参照)
短縮形のバインド (「短縮形のバインド」を参照)
FNS では、XFN 初期コンテキスト関数が呼び出されたときに、プロセスに関連付けられたユーザーが存在するものと仮定されます。この関連付けは、プロセスの実効ユーザー ID (euid) に基づいています。プロセスに対するユーザーの関連付けがプロセスの途中で変更されることはありますが、元のコンテキストハンドルは変更されません。
FNS では、名前解決を要求するユーザーに関連する初期コンテキストにある次のバインドが定義されます。
初期コンテキストにある名前空間識別子 myself (あるいは同義語の _myself または thisuser のどちらか) は、要求を行うユーザーのコンテキストで解決されます。ユーザー jsmith が所有するプロセスが名前解決を要求したときの例を示します。
名前 myself は、jsmith のユーザーのコンテキストとして初期コンテキストで解決される
myself/fs/.cshrc は、jsmith のファイル cshrc にネーミングする
FNS では、各ユーザーがエンタープライズの組織単位に関連するものと仮定されます。1 人のユーザーを複数の組織単位に関連させることはできますが、組織の名前空間での位置または組織内でのユーザーの役割によって、主な組織単位が必ず 1 つ必要です。
「NIS+」
NIS+ 名前空間では、この組織単位はユーザーのホームドメイン (これは、サブドメインになることもある) に対応する
「NIS」
NIS 名前空間では、ユーザーのドメインに対応するエンタープライズレベルの組織単位は 1 つしかない
「ファイル」
ファイルベースの名前空間では、組織単位は myorgunit にマップする org// しかない
名前空間識別子 myorgunit (または _myorgunit) は、要求を行うユーザーが所属する主組織単位のコンテキストとして初期コンテキストで解決されます。たとえば、要求を行うユーザーが jsmith で、jsmith のホームドメインが east.sales である場合は、myorgunit は east.sales の組織単位コンテキストとして初期コンテキストで解決され、名前 myorgunit/service/calendar は east.sales のカレンダのサービスで解決されます。
FNS では、各ユーザーがエンタープライズに関連するものと仮定されます。これは、myorgunit を保持する名前空間に対応します。
名前空間識別子 myens (および _myens) は、要求を行うユーザーが所属するエンタープライズのルートとして初期コンテキストで解決されます。たとえば、jsmith が要求を行い、jsmith の NIS+ ホームドメインが east.sales である場合、それは doc.com. のルートドメイン名を含む NIS+ 階層にあります。名前 myens/orgunit/ は、doc.com の最上部の組織単位で解決されます。
myorgunit または myself/service などのユーザーに関連する複合名を使用するときは、これらのバインドはプロセスの実効ユーザー ID に依存するため、ユーザー ID 設定プログラムに注意してください。ユーザー ID を root に設定して、呼び出し元に代わってシステムリソースにアクセスするプログラムでは、通常は fn_ctx_handle_from_initial() を呼び出す前に seteuid(getuid()) を呼び出してください。
XFN 初期コンテキスト関数が呼び出されたときには、特定のホストでプロセスが実行中です。FNS では、プロセス実行中のホストに関連する初期コンテキストにある次のバインドが定義されます。
名前空間識別子 thishost (または _thishost) は、プロセス実行中のホストのホストコンテキストにバインドされます。たとえば、プロセスがマシン cygnus で実行中である場合、thishost は cygnus のホストのコンテキストにバインドされ、名前 thishost/service/calendar はマシン cygnus のカレンダのサービスを参照します。
FNS では、ホストは組織単位に関連付けられていると仮定します。1 つのホストを複数の組織単位に関連付けることができますが、主となる組織単位が必要です。NIS+ 名前空間では、組織単位はホストのホームドメインに対応します。
名前空間識別子 thisorgunit (または _thisorgunit) は、プロセス実行中のホストの主要な組織単位に解決されます。たとえば、ホストがマシン cygnus であり、cygnus の NIS+ ホームドメインが west.sales である場合は、thisorgunit は west.sales として組織単位コンテキストで解決され、名前 thisorgunit/service/fax は組織単位 west.sales の FAX サービスを参照します。
FNS では、ホストがエンタープライズに関連するものと仮定されます。これは、thisorgunit を保持する名前空間に対応します。
名前空間識別子 thisens (または _thisens) は、プロセス実行中のホストのエンタープライズのルートで解決されます。たとえば、NIS+ で、ホストのホームドメインが sales.doc.com である場合、名前 thisens/site/ は doc.com. のサイトの名前空間のルートで解決されます。
FNS では、初期コンテキストにある次の短縮形バインドを定義し、短い名前を使用して、共通に参照される特定の名前空間を参照できます。
名前空間識別子 user (または _user) は、プロセス実行中のホストの組織単位にある username コンテキストとして初期コンテキストにバインドされます。これにより、同じ組織単位にいる他のユーザーをこのコンテキストからネーミングできます。
初期コンテキストから、名前 user および thisorgunit/user は同じコンテキストで解決されます。たとえば、プロセス実行中のホストがマシン altairであり、altair が east.sales 組織単位にある場合は、名前 user/medici で east.sales にいるユーザー medici がネーミングされます。
名前空間識別子 host (または _host) は、プロセス実行中のホストの組織単位にある hostname コンテキストとして初期コンテキストにバインドされます。これにより、同じ組織単位にいる他のホストをこのコンテキストからネーミングできます。
初期コンテキストから、名前 host および thisorgunit/host は同じコンテキストで解決されます。たとえば、プロセス実行中のホストがマシン sirius であり、sirius が east.sales 組織単位にある場合は、名前 host/sirius で east.sales にあるマシン sirius がネーミングされます。
名前空間識別子 org (または orgunit、_orgunit) は、プロセス実行中のホストが所属するエンタープライズの組織のルートコンテキストとして初期コンテキストでバインドされます。
初期コンテキストから、名前 org および thisens/orgunit は同じコンテキストで解決されます。たとえば、プロセス実行中のホストがマシン aldebaran であり、aldebaran がエンタープライズ doc.com にある場合は、名前 org/east.sales で doc.com. にある組織単位 east.sales がネーミングされます。
名前空間識別子 site (または _site) は、プロセス実行中のホストが所属するエンタープライズの最上位の組織単位のサイトネーミングシステムのルートに対する初期コンテキストにバインドされます。
初期コンテキストから、名前 site および thisens/site は同じコンテキストで解決されます。たとえば、プロセス実行中のホストがマシン aldebaran であり、aldebaran がエンタープライズ doc.com にある場合は、名前 site/pine.bldg-5 で doc.com. の建物 5 にある会議室 pine がネーミングされます。
FNS では、基本ネーミング操作の単一の簡単なインタフェースで、複数のネームサービスをフェデレートする方法が提供されます。FNS は、次の 3 つのエンタープライズレベルのネームサービスで機能するように設計されています。
「NIS+」(「FNS ポリシーと NIS+ との関連」および「FNS と NIS+ のネーミング」を参照)
「NIS」(「FNS ポリシーと NIS の関連」および「FNS と NIS のネーミング」を参照)
「ファイル」(「FNS ポリシーとファイルベースのネーミングの関連」および「FNS とファイルベースのネーミング」を参照)
また FNS は、「FNS ポリシーの対象となるクライアントアプリケーション」で説明しているようなプリンタおよびカレンダサービスなどのアプリケーションで機能するようにも設計されています。
FNS および NIS+ に関連する内容説明の概要については、「FNS と NIS+ のネーミング」を参照してください。NIS+ およびその用語を調べる場合は、このマニュアルのパート I「ネーミングの紹介」および用語集を参照してください。一般的な NIS+ 環境の構造を学ぶときに便利です。
FNS では、NIS+ サーバー上のドメインレベルの org_dir NIS+ ディレクトリにある FNS テーブルに、エンタープライズのオブジェクトに対するバインドが格納されます。FNS テーブルは NIS+ テーブルに類似しています。これらの FNS テーブルには、次のエンタープライズ名前空間に対するバインドが格納されます。
「NIS+ ドメインと FNS 組織単位」で説明する「組織」の名前空間
「NIS+ ホストと FNS ホスト」で説明する「ホスト」の名前空間
「NIS+ ユーザーと FNS ユーザー」で説明する「ユーザー」の名前空間
組織、ホスト、ユーザーに関連付けて地域のサイトにネーミング可能な「サイト」の名前空間
組織、ホスト、ユーザーに関連付けてプリンタやカレンダなどのサービスにネーミング可能な「サービス」の名前空間
FNS では、優先 Solaris エンタープライズのネームサービスである NIS+ 内の組織、ユーザー、ホストのエンタープライズオブジェクトがネーミングされます。NIS+ ドメインは、ユーザーおよびマシンの論理コレクションとそれらについての情報で構成され、エンタープライズ内の階層組織構造のフォームを反映するように配列されます。
FNS は、NIS+ ドメインを FNS 組織にマッピングして、NIS+ で実行されます。組織単位名は、NIS+ ドメイン名に対応しており、完全指定された形式の NIS+ ドメイン名または NIS+ ルートに関連した NIS+ ドメイン名のどちらかを使用して識別されます。最上位の FNS 組織名前空間は、NIS+ ルートドメインにマップされ、初期コンテキストから名前 org/ を使用してアクセスされます。
NIS+ では、ユーザーおよびホストに「ホームドメイン」の概念があります。ホストまたはユーザーのホームドメインは、それらの関連付けられた情報を保持する NIS+ ドメインです。ユーザーまたはホストのホームドメインは、直接 NIS+「主体名」を使用して決定できます。NIS+ 主体名は、原子ユーザー (ログイン) 名または原子ホスト名と、NIS+ ホームドメイン名からなります。たとえば、ホームドメイン doc.com. を持つユーザー sekou には NIS+ 主体名 sekou.doc.com が付けられ、マシン名 vega には NIS+ 主体名 vega.doc.com が付けられます。
ユーザーの NIS+ ホームドメインは、ユーザーの FNS 組織単位に対応します。同様に、ホストのホームドメインは、その FNS 組織単位に対応します。
組織名の後のドットは、その名前が完全指定の NIS+ ドメイン名であることを示します。このドットがない場合は、その組織名は NIS+ ルートドメインに関連付けて解決される NIS+ ドメイン名です。
たとえば、NIS+ ルートドメインが doc.com. であり、サブドメイン ales.doc.com. を含む場合は、次の名前で同じ組織が参照されます。
表 22-4 NIS+ での相対および完全指定の組織名の例
相対名 |
完全指定名 |
---|---|
org/ |
org/doc.com. |
org/sales |
org/sales.doc.com. |
manf という名前だけを含む NIS+ ドメインは存在しないため、名前 org/manf. (ドット付き) はありません。
NIS+ 名前空間のホストは、ホストのホームドメインの hosts.org_dir テーブルにあります。FNS 組織にあるホストは、対応する NIS+ ドメインの hosts.org_dir テーブル内のホストに対応します。FNS では、hosts テーブル内の各ホストにコンテキストが提供されます。
NIS+ 名前空間にいるユーザーは、ユーザーのホームドメインの passwd.org_dir テーブルのリストに入っています。FNS 組織にいるユーザーは、対応する NIS+ ドメインの passwd.org_dir テーブル内のユーザーに対応します。FNS では、passwd テーブル中の各ホストにコンテキストが提供されます。
FNS の fncreate コマンドを使用して、コマンドが実行されたホストのドメインに関連付けられた NIS+ 階層に FNS テーブルとディレクトリを作成します。fncreate を実行するには、そのドメインの NIS+ オブジェクトの読み取り、作成、変更、削除を許可する資格を得て、認証された NIS+ 主体になる必要があります。fncreate で作成した FNS テーブルの「所有者」になります。この許可を得る 1 つの方法は、ドメインの管理者特権を持つ NIS+ グループのメンバーになることです。
fncreate を実行する前に、NIS_GROUP
環境変数をドメインに対する NIS+ 管理グループ名に設定する必要があります。個別のユーザーが、ユーザーに関連する FNS データを変更可能かどうかを指定できます。
NIS+ セキュリティの説明については、第 6 章「セキュリティの概要」を参照してください。
FNS および NIS に関連する概要と内容説明については、「FNS と NIS のネーミング」を参照してください。
FNS では、NIS をネームサービスとして使用する基本的なネーミングおよび属性の操作用に XFN インタフェースが提供されます。
FNS では、NIS マスターサーバー (および存在する場合は NIS スレーブサーバー) /var/yp/domainname ディレクトリにある FNS マップのエンタープライズオブジェクトへのバインドが格納されます。FNS マップは、構造と機能の面で FNS マップと類似しています。これらの NIS マップでは、次のエンタープライズ名前空間に対するバインドが格納されます。
エンタープライズ全体に関連するオブジェクトをネーミングするための名前空間を提供する「組織」。NIS がネームサービスの下にあるときは、NIS ドメインに対応する 1 つの組織単位コンテキストがある。この組織単位コンテキストは、NIS ドメイン名または、マシン NIS ドメイン名をデフォルトとする空白名によって FNS で識別される。
NIS ドメインの hosts.byname マップに対応する「ホスト」の名前空間。FNS では、hosts.byname マップにある各ホストにコンテキストが提供される
passwd.byname マップに対応する「ユーザー」の名前空間。FNS では、ドメインの passwd.byname にある各ユーザーにコンテキストが提供される
組織、ホスト、ユーザーに関連する地域サイトにネーミングするための「サイト」の名前空間
組織、ホスト、ユーザーに関連付けてプリンタやカレンダなどのサービスにネーミングするための「サービス」の名前空間
FNS では、他のオブジェクトをこれら 5 つの名前空間に関連付けてネーミングするためのコンテキストが提供されます。
FNS の fncreate コマンドを使用して、NIS マスターサーバーの /var/yp/domainname ディレクトリに FNS マップを作成します。これは、NIS ネームサービスのマスターサーバーと同じマシンか、または FNS マスターサーバーとして機能する異なるマシンで行えます。スレーブサーバーが存在する場合は、NIS は、通常の処理の一部として FNS マップをそれらにプッシュします。fncreate を実行するには、FNS マップのホストとなるサーバーの特権ユーザーになる必要があります。各ユーザーは、FNS データを変更できません。
FNS とファイルに関連する概要および内容説明については、「FNS とファイルベースのネーミング」を参照してください。
FNS では、ローカルのファイルをネームサービスとして使用する基本的なネーミングおよび属性の操作用に XFN インタフェースが提供されます。
FNS では、通常各マシンに NFS マウントされた /var/fn ディレクトリにあるファイル内のエンタープライズオブジェクトに対するバインドが格納されます。これらの FNS ファイルでは、次のエンタープライズ名前空間に対するバインドが格納されます。
エンタープライズ全体に関連付けてオブジェクトをネーミングする名前空間を提供する「組織」。ローカルのファイルがネームサービスの下にある場合は、システム全体を表す 1 つの組織単位コンテキストがある。この組織単位コンテキストは、FNS では常に org// として識別される
/etc/hosts ファイルに対応する「ホスト」の名前空間。FNS では、/etc/hosts ファイルにある各ホストにコンテキストが提供される
/etc/passwd ファイルに対応する「ユーザー」の名前空間。FNS では、/etc/passwd ファイルにある各ユーザーにコンテキストが提供される
組織、ホスト、ユーザーに関連付けて地域サイトをネーミングするための「サイト」の名前空間
組織、ホスト、ユーザーに関連付けてプリンタやカレンダなどのサービスにネーミングするための「サービス」の名前空間
FNS では、他のオブジェクトをこれら 5 つの名前空間に関連付けてネーミングするためのコンテキストが提供されます。
FNS の fncreate コマンドによって、コマンドが実行されるマシンの /var/fn ディレクトリに FNS ファイルを作成します。fncreate を実行するには、そのマシンでのスーパーユーザー特権を持つ必要があります。UNIX ユーザー ID に基づいて、各ユーザーは、FNS コマンドを使用して自身のコンテキスト、バインド、属性を変更することが許可されます。
FNS ポリシーの 1 つの目的は、ファイルシステム、およびカレンダマネージャ、印刷ツール、ファイルマネージャ、メールツールなどの DeskSet ツール、またこれらのツールをサポートする RPC、電子メール、印刷サブシステムなどのサービスなどの、共通して使用されるツールに一貫性を持たせることです。
これらの例のいくつかは、現在 Solaris 環境には導入されていませんが、FNS の使用方法を示すためにここに挙げます。
「カレンダ」
「username@hostname」の形の名前を使用して誰かのカレンダにアクセスする代わりに、たいていの場合は単にサイト、組織、またはユーザー名を入力する。カレンダをネーミングするときには、複合名を使用することもできる。たとえば、FNS でフェデレートするときには、次の形式の名前がカレンダマネージャで使用可能となる
bernadette
user/bernadette
site/pine.bldg-5 (Pine 会議室用のカレンダ)
org/sales (sales 組織用のカレンダ)
「印刷」
特定のプリンタを名前でネーミングする代わりに、ユーザー、サイト、または組織に関連付けてプリンタをネーミングできる。次のようなものがある
ilych (ilych のデフォルトのプリンタ)
org/sales (組織のデフォルトのプリンタ)
site/pine.bldg-5 (Pine 会議室のプリンタ)
「ファイルアクセス」
ファイルシステムやファイルをネーミングするときに複合名を使用できる。オートマウンタは、FNS を使用して複合名の解決を可能にする。たとえば、/xfn/user/baruch/fs/.cshrc などのファイル名を使用して、ユーザー baruch の .cshrc ファイルを参照できる
「RPC」
サービスをホスト名、プログラム、およびバージョン番号でアドレス指定する代わりに、複合名を使用してサービスをネーミングできる。たとえば、user/hatori/service/rpc のようにユーザーまたは組織に関連付けて RPC サービスをネーミングできる
「メール」
同様に、複合名はメールの宛先をネーミングするために使用される。次のような名前を使用できる
angus
user/angus
org/mlist (組織のメールリスト)
site/pine.bldg-5 (会議室の調整係のメールボックス)
「他のデスクトップアプリケーション」
スプレッドシート、文書作成ツール、FAX ツールなどの他のデスクトップアプリケーションに複合名を引き渡すことができる。これらのアプリケーションには、それ自身の名前空間をサービスの名前空間に接続し、FNS フェデレーションの一部となるものもある
ここでは、カレンダサービスというアプリケーションを変更して、FNS ポリシーを使用する方法について説明します。この例では、ユーザーから FNS 複合名が提示され、承認される手順を示します。
DeskSet のカレンダサービスは、一般的なクライアントサーバーアプリケーションです。カレンダサーバーは、複数のマシンで動作し、ユーザーのカレンダを保持します。カレンダマネージャ (cm) は、デスクトップで動作し、適切なサーバーにコンタクトして必要なカレンダを入手します。
カレンダサービスは、次のような簡単なレジストリまたは検索のモデルを使用して FNS を利用します。
「バインド」
起動時に、サーバーは、user/jsmith/service/calendar などの管理するそれぞれのカレンダの複合名に対するそれ自身の ONC+ RPC アドレス (ホスト、プログラム、バージョン) を含むリファレンスをバインドし、サーバーの管理するカレンダを登録する
「検索」
cm を使用するときには、ユーザーは、単にユーザー名 (hirokani など) を入力するか、または以前に入力した名前のリストからユーザーを選択して、他のユーザーのカレンダを指定する。ユーザー名が hirokani の場合は、cm で複合名 user/hirokani/service/calendar が作成され、これを使用してカレンダを管理するサーバーと通信する必要のある RPC アドレスが検索される
前の例では、名前 calendar を使用して、カレンダのバインドを示しています。RPC プログラムを RPC 管理者に登録するのと同じように、カレンダサービスの開発者は、名前 calendar を FNS 管理者に登録します。「サービス名およびリファレンスの登録」を参照してください。
ここで使用した名前 calendar は 1 つの例です。FNS ポリシーによって、特定のサービス名が指定されるわけではありません。
カレンダサービスでは、カレンダをサイト、組織、およびホストに関連付け、一定の方法でそれらをネーミングして、FNS ポリシーをさらに利用できます。たとえば、カレンダを会議室 (サイト) と関連付け、ユーザーのカレンダのセットでその部屋の会議に利用可能な時間を見つけるのと同じように、サービスを使用して会議室のカレンダを多重表示できます。同様に、カレンダは、グループ会議の組織や、保守スケジュールを管理するホストに関連付けることができます。
カレンダマネージャ (cm) は、いくつかの簡単な手順に従って、ユーザーが指定する必要のあることを明確にします。
cm では、ユーザーからの複合名を承認して、カレンダが要求されたオブジェクト名を構成するためのツールが使用されます。
オブジェクトは、ユーザー、サイト、ホスト、または組織の名前になります。たとえば、ユーザーが名前 kuanda を入力すると、カレンダマネージャで複合名 user/kuanda が生成されます。このツールは、DeskSet アプリケーションのグループ間で共有できます。
cm は、XFN インタフェースを使用して、接尾辞 /service/calendar を含む名前を作成し、カレンダ名を入手します。
このカレンダ名は、プロセスの初期コンテキストに関連付けて解決されます。
続いて、名前 user/kuanda/service/calendar が解決されます。同様に、ユーザーがサイト名 pine.bldg-5 を入力した場合は、cm で名前 site/pine.bldg-5/service/calendar が生成され解決されます。
印刷やメールなどの他のサービスでも、類似の方法で FNS ポリシーを利用できます。
FNS では、ファイル名はユーザー、ホスト、組織、サイトとの関係から設定できます。この場合実際には、オブジェクトの名前の後にエンタープライズの名前空間識別子 fs を指定し、その後にファイル名を指定します。たとえば、Sales 部門の、budget というファイルなら、org/sales/fs/budget/draft96という名前になります。
初期コンテキストは、ルートディレクトリの /xfn の下にあります。したがって、以下のように入力して参照できます。
% more /xfn/org/sales/fs/budget/draft96 |
アプリケーションからこのディレクトリへアクセスする方法は、他のディレクトリの場合とまったく同様です。アプリケーションを修正したり、XFN API を使用したりする必要はありません。
NFS は Sun Microsystems, Inc. の製品で、分散ファイルシステムの一種です。オブジェクトのファイルは、通常1つ以上のリモート NFS ファイルサーバーにあります。最も単純なのは、エクスポートされた NFS ファイルシステムに名前空間識別子 fs が対応するという図 22-4 のような場合です。
しかしオブジェクトのファイルシステムの中には、複数の (重なり合う場合もある) リモートマウントで構成され、FNS によって管理される仮想ディレクトリ構造にまとめられているものもあります。
図 22-5 は、3 つの異なるファイルサーバーをまとめて、組織のファイルシステムを 1 つ作成している例です。project ディレクトリと lib サブディレクトリは同じファイルサーバー上に常駐していますが、src サブディレクトリの常駐先は別です。しかしユーザー、およびアプリケーションの側からは 1 つのシームレスな名前空間に見えるので、複数のサーバーを使用していることを意識する必要はありません。
効率を上げるため、FNS ディレクトリのマウントには必要に応じてオートマウンタが使用されます。/etc/auto_master 構成ファイルには、デフォルトでは以下のような行が含まれます。
/xfn -xfn |
これは、「FNS 名前空間が、XFN の指定どおり /xfn の下にマウントされる」という意味です。
オートマウンタは、FNS によって指定されたディレクトリのマウントに使用されるため、FNS ディレクトリのサブディレクトリは、マウントされるまで表示できません。たとえば、sales 組織のファイルシステムが複数のファイルシステムで構成されているとします。以下の ls コマンドは最近アクセスして現在もマウントされている 2 つのファイルシステムだけを表示します。
% ls /xfn/org/sales/fs customers products |
完全なリストを表示するには、fnlist コマンドを使用します。
% fnlist org/sales/fs Listing `org/sales/fs': products goals customers incentives |
printer コンテキストは、XFN ポリシーには含まれていません。FNS に提供されているのは、プリンタバインディングを保存するためです。
FNS では、FNS 名前空間にプリンタバインディングを保存するための機能が提供されています。この機能によって、プリントサーバーは自分自身のサービスをユーザーに知らせることができ、ユーザーはクライアント側の管理がなくてもプリンタのブラウズおよび選択ができます。
プリンタバインディングは、組織、ユーザー、ホスト、サイトごとに存在する printer コンテキストに格納されます。したがって、組織、ユーザー、ホスト、サイトは、それぞれ専用の printer コンテキストを所有できます。
printer コンテキストは、個々の複合名の service コンテキストの下に作成されます。例を以下に示します。
org/doc.com./service/printer |
ホストのプリンタ名が deneb である場合、printer コンテキストは以下のように作成されます。
host/deneb/service/printer/laser |
グローバルネームサービスには、固有の適用範囲があります。ここでは、グローバルネームサービスを使用するオブジェクトをネーミングするためのポリシーについて説明します。
ネーミングに関しては、エンタープライズは、グローバル名前空間にあるエンタープライズのルートをバインドして、フェデレートされたグローバル名前空間にリンクします。これにより、エンタープライズ外部のアプリケーションおよびユーザーがそのエンタープライズ内部のオブジェクトをネーミングできます。たとえば、エンタープライズ内部のユーザーは、他のエンタープライズにいる同僚にファイルのグローバル名を渡すことができます。
DNS および X.500 のコンテキストは、エンタープライズをネーミングするためのグローバルレベルのネームサービスを提供します。FNS では、DNS と X.500 コンテキストの両方がサポートされます。FNS がない場合、DNS および X.500 では、限定された部分のエンタープライズ名前空間だけに外部からアクセスできます。FNS では、カレンダマネージャなどのサービスを含むエンタープライズ名前空間全体に外部からアクセスできます。
原子名「...」(3 つのドット) は、各 FNS クライアントの初期コンテキストに表示されます。原子名「...」は、グローバル名が解決されるコンテキストにバインドされます。
表 22-5 グローバルネーミングに対する初期コンテキストバインド
原子名 |
バインド |
---|---|
. .. |
DNS または X.500 の名前を解決するためのグローバルコンテキスト |
/ ... |
3 つのドットの同義語 |
グローバル名は、完全指定のインターネットドメイン名か、または X.500 の識別名になります。
インターネットドメイン名は、インターネット RFC 1035 で指定された構文に表示される。たとえば、.../doc.com (「DNS のフェデレーティング」を参照) など
X.500 名は、X/Open DCE ディレクトリで決定された構文に表示される。たとえば、.../c=us/o=doc など (「X.500/LDAP のフェデレーティング」を参照)
名前「...」および「/...」は、初期コンテキストで解決されるときには等価になります。たとえば、名前 /.../c=us/o=doc および .../c=us/o=doc は、初期コンテキストで同じオブジェクトとして解決されます。
完全指定の DNS 名は、必ずグローバルコンテキストで使用できます。DNS 名がグローバル名前空間で見つかると、リゾルバライブラリを使用して解決されます。リゾルバライブラリは、DNS 名前解決メカニズムです。一般的 DNS 名は、インターネットのホストアドレスまたは DNS ドメインレコードで解決されます。グローバルコンテキストで DNS 名が検出されると、名前は DNS リゾルバに引き渡されて解決されます。結果は、XFN リファレンス構造に変換され、要求者に返されます。
DNS ドメインの内容は、表示できます。しかし、表示操作は、インターネットでの連結性とセキュリティなどの実用上の理由によって限定されることもあります。たとえば、DNS ドメインのグローバルルート表示は、一般的にルート DNS サーバーではサポートされません。しかし、ルートの下にあるたいていのエンティティは、表示操作をサポートします。
DNS ホストおよびドメインは、DNS リソース名と関連付けられたネームサービス (NS) のリソースレコードの有無によって確認されます。
「DNS ドメイン名」
NS レコードがリソース名に存在する場合は、その名前はドメイン名であると考えられ、返されたリファレンスのタイプは inet_domain となる
「DNS ホスト名」
NS レコードがリソース名に存在しない場合は、その名前はホスト名であると考えられ、返されたリファレンスのタイプは inet_host となる
DNS は、端末以外のネーミングシステムのように機能し、他のネーミングシステムをフェデレートするために使用されます。
たとえば、エンタープライズネーミングシステムは、FNS 名 .../doc.com/ がそのエンタープライズの FNS 名前空間のルートを参照するような DNS にある doc.com にバインドできます。
エンタープライズのネーミングシステムは、適切なテキスト (TXT) レコードをそのドメインの DNS マップに追加して、DNS ドメインにバインドされます。そのドメインに対する FNS 名には後に続くスラッシュ (/) が含まれ、TXT リソースレコードは、エンタープライズのネーミングシステムへのリファレンスを構成するために使用されます。
DNS に関する一般的な情報については、in.named(1M) のマニュアルページか、または『Solaris ネーミングの設定と構成』の DNS についての章を参照してください。
X.500 は、グローバルのディレクトリサービスです。ここでは、情報が格納され、情報を表示して検索する機能と同様に、名前で情報を検索する機能が提供されます。
X.500 の情報は、ディレクトリ情報ベース (DIB) に格納されます。DIB にあるエントリは、ツリー構造で配列されます。各エントリは名前付きオブジェクトで、定義された属性のセットを含んでいます。各属性には、定義済みの属性タイプと 1 つまたは複数の値があります。
エントリは、ルートから名前付きエントリまでのパスでツリー内の各エントリから選択された属性の連結である「識別名」によって明確に識別されます。たとえば、図 22-6 に示す DIB を使用すると、c=us/o=doc は、合衆国にある doc 組織の識別名となります。X.500 ディレクトリのユーザーは、DIB にあるエントリと属性を問い合わせたり、変更したりすることができます。
FNS は、名前空間をグローバル X.500 名前空間の下にシームレスに接続して表示するために必要なサポートを提供し、X.500 をフェデレートします。
たとえば、FNS は、X.500 の下の doc 組織にエンタープライズネーミングシステムをリンクします。初期コンテキストから始まって、doc 組織の sales 組織単位を識別する FNS 名は次のようになります
.../c=us/o=doc/orgunit/sales
エンタープライズ内の名前は、単純にグローバルの X.500 名上に連結されます。FNS 名が初期コンテキストで名前「...」を使用して、グローバル名が後に続くことを示すことに注意してください。
FNS 名の名前解決は、次のように行われます。X.500 名がグローバル名前空間で見つかると、X.500 名前解決メカニズムを使用して解決されます。次の 3 つの結果が考えられます。
フルネームが X.500 エントリに解決される。これは、エントリが X.500 に格納されていることを示す。要求された FNS 操作がそのエントリで実行される
フルネームの接頭辞は、X.500 エントリに解決される。これは、名前の残りの部分が従属するネーミングシステムに所属することを示す
従属するネーミングシステムへの次のネーミングシステムのポインタ (NNSP) が調べられ、XFN リファレンスが返されます。この後、名前解決は従属するネーミングシステムで続けられます。
エラーが報告される
X.500 エントリは、FNS 操作を使用して調べたり、変更したりできます (アクセス制御に従う)。しかし、現在は FNS を使用して X.500 名前空間のルートの下にある従属するエントリを表示できません。
この章では、FNS およびエンタープライズレベルのネームサービスの管理について説明します。
エンタープライズレベルのネームサービスは、組織内のオブジェクトをネーミングするために使用されます。現在 FNS は、次の 3 つのエンタープライズレベルのネームサービスをサポートしています。
NIS+ (「FNS と NIS+ のネーミング」および、「FNS ポリシーと NIS+ との関連」を参照)
NIS (「FNS と NIS のネーミング」および、「FNS ポリシーと NIS の関連」を参照)
ローカルファイル (「FNS とファイルベースのネーミング」および、「FNS ポリシーとファイルベースのネーミングの関連」を参照)
『Solaris ネーミングの設定と構成』で説明している fncreate コマンドで FNS 名前空間を初期設定して構成するときには、正しいデフォルトのネームサービスが自動的に各マシンに選択されます。
マシンの主要なエンタープライズレベルのネームサービスを後で変更する場合は、そのマシンで fnselect コマンドを実行する必要があります。詳細は、「ネームサービスを選択する」を参照してください。
タスクの 1 つにシステム管理者の機能が割り当てられていて、FNS とその下層のネームサービス間の整合性を維持しています。これは、ネームサービスのファイル、マップ、またはテーブルと FNS コンテキストが正しく対応しているかどうかをチェックするということです。
『Solaris ネーミングの設定と構成』で説明している fncreate コマンドで FNS 名前空間を初期設定して構成するとき、fncreate では、FNS コンテキストが適切に作成され、下層のネームサービスのデータと整合されたことが確認されます。FNS コンテキストが設定された後、ユーザー、ホスト、プリンタなどがシステムに追加または削除されるときに、この対応関係は維持される必要があります。以下の項では、FNS とネームサービスとの整合性を維持する方法について説明します。
Solstice AdminSuite 製品で、基本的なネームサービスでのユーザーとホストの情報を追加、変更、削除できます。AdminSuite ツールでは対応する FNS 名前空間が自動的に更新されるため、この方法をお勧めします。
Solstice AdminSuite 製品を使用せずに FNS または主要なネームサービスを更新するときに、不一致が発生した場合は、FNS ツールの fncheck を使用して解決します。fncheck コマンドは、FNS の hostname と user のコンテキストと、次のものとの不一致をチェックします。
「NIS」- NIS の hosts.byname と passwd.byname のマップ
fncheck コマンドは、FNS 名前空間にあってネームサービスのデータにないホストとユーザー名およびネームサービスのデータにあって FNS 名前空間にないホストとユーザー名を表示します。
fncheck [-r][-s][-u][-t hostname|username][domain_name] |
オプション |
説明 |
---|---|
domain |
コマンドを実行しているドメイン以外の NIS+ ドメインにコマンドを適用する |
-t |
チェックするコンテキストのタイプを指定する。許容されるタイプは、hostname または username |
-s |
FNS 名前空間にない名前空間のデータセットからホスト名とユーザー名を表示する |
-r |
対応する名前空間のデータセットにないエントリを持たない FNS 名前空間からホスト名またはユーザー名を表示する |
-u |
関連した名前空間のデータセットにある情報に基づいて FNS 名前空間を更新する |
-t オプションは、チェックするコンテキスト (ホストまたはユーザー) を指定するために使用します。-t オプションを省略した場合は、hostname と username のコンテキストの両方がチェックされます。
-r オプションを -u オプションとともに使用すると、FNS コンテキストにしか表示されない項目が FNS コンテキストから削除されます。-s オプションを -u オプションとともに使用すると、名前空間のデータセットにしか表示されない項目が FNS コンテキストに追加されます。-r と -s のどちらも指定しない場合は、項目が FNS コンテキストに追加および削除され、対応する名前空間のデータとの整合性が保たれます。
FNS がマシンに対する初期コンテキストにバインドを構成するときには、特定のネームサービスに基づいて行います。
FNS では fnselect コマンドで使用するネームサービスを選択できます。fnselect で指定したネームサービスの設定は、マシン全体、そのマシンで動作するすべてのアプリケーション、およびそのマシンにログインしたすべてのユーザーに影響します。
スーパーユーザーだけが fnselect を実行できます。コマンド構文は以下のとおりです。
fnselect [-D] [namesvc] |
オプション |
説明 |
---|---|
namesvc |
選択するネームサービス。必ず次のどれかになる。default、nisplus、nis または files |
-D |
FNS 初期コンテキストを生成するために使用されるネームサービスを表示する |
たとえば、マシンのネームサービスとして NIS+ を選択するには以下のコマンドを使用します。
# fnselect nisplus |
たとえば、マシンのネームサービスとして default を選択し、FNS 初期コンテキストを生成するために使用されるサービスの名前を印刷するには次のように入力します。
# fnselect -D default |
fnselect でネームサービスを指定しない場合、FNS はデフォルトのネームサービスを使用します。デフォルトのネームサービスは、マシンの使用するネームサービスに基づいて FNS で決定されます。マシンが NIS+ クライアントである場合は、FNS は NIS+ をネームサービスとして使用します。マシンが NIS クライアントである場合は、FNS は NIS を使用します。マシンが NIS+ および NIS クライアントのどちらでもない場合は、FNS は /etc ファイルをマシンのネームサービスとして使用します。
ごくまれに、NIS+ と NIS ベースのコンテキストの両方にアクセスする必要が生じることがあります。たとえば、それ自体が NIS+ クライアントである NIS サーバーを稼動している場合です。この場合、fnselect コマンドを使用して、使用するエンタープライズレベルのネームサービスを選択します。
この節では、NIS+ オブジェクトと FNS オブジェクトの関係の詳細について説明します。この情報は、FNS オブジェクトのアクセス制御を変更するときに有効です。
次を参照してください。
FNS コンテキストは、NIS+ オブジェクトに格納されます。組織に関連するすべてのコンテキストは、関連する NIS+ ドメインの ctx_dir ディレクトリに格納されます。ctx_dir ディレクトリは、同じドメインの org_dir と同じレベルにあります。すなわち、FNS と同時に実行される時には、それぞれの NIS+ ドメインまたはサブドメインには対応する org_dir、groups_dir、および ctx_dir というディレクトリオブジェクトが存在します。
fnlookup または fnlist のコマンドで -v オプションを使用して、リファレンスについての詳細な説明を表示します。内部名フィールドに、対応する NIS+ オブジェクトの名前が表示されます。
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 コマンド」を参照してください。
特定のコンテキストのアクセス権または所有権を変更するには、次のコマンドを使用します:
操作が影響するオブジェクトに応じて、バインドエントリまたはバインドテーブルのどちらかを引数として与えます。
ここでは、NIS と FNS の関係についての特定情報を説明します。
FNS は、NIS マスターおよびスレーブのサーバー上の /var/yp/domainname ディレクトリに格納されている 6 つのマップを使用します。
fns_host.ctx
ホスト属性とサブコンテキストのデータを格納する。これが最初に作成されると、hosts.byname マップから情報が得られる
fns_host.ctx
ユーザー属性とサブコンテキストのデータを格納する。これが最初に作成されると、passwd.byname マップから情報が得られる
fns_org.ctx
fns_host.attr
fns_user.attr
属性による検索のためのユーザー属性を格納する
fns_org.attr
ホスト、ユーザー、およびエンタープライズのサービスとファイルのコンテキスト情報は、それぞれ fns_host.ctx、fns_user.ctx、および fns_org.ctx のマップに格納されます。プリンタのコンテキスト情報は、他のサービスのコンテキスト情報と同じマップに格納されます。しかし、古い printers.conf.byname マップはここでもサポートされます。
サイトは、エンタープライズのサブコンテキストであり、サイトのコンテキスト情報は fns_org.ctx マップに格納されます。
これらの FNS マップは、直接編集しないでください。fncreate、fndestroy、fnbind、fnunbind、fnrename、fnattr、fnlookup、および fnlist などの適切な FNS コマンドを実行して、これらのマップで変更または作業を行います。これらのコマンドは、必ず NIS マスターサーバーで実行します。スレーブサーバーまたはクライアントマシンでこれらを実行できません。
FNS マップファイルは、/var/yp/domainname ディレクトリにあります。/var/yp にある NIS Makefile は変更され、/etc/fn/domainname にある FNS Makefile が認識されます。
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 マップは変更されません。
fncopy コマンドは、エンタープライズレベルのネームサービスを NIS から NIS+ に変更するときに、FNS 関連の側面を処理します。このコマンドは、NIS ベースの FNS コンテキストを NIS+ ベースのコンテキストにコピーして変換します。
fncopy [-i oldsvc - o newsvc] [-f filename] oldctx newctx |
オプション |
説明 |
---|---|
-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 では、各マシンの /var/fn ディレクトリに格納された新規ファイルが使用されます。通常 /var/fn ディレクトリは各マシンに格納されていますが、NFS 経由で中央の /var/fn ディレクトリをマウントしたり、エクスポートしたりできます。
新規 FNS ファイルを以下に示します。
fns_host.ctx
ホスト属性とサブコンテキストのデータを格納する。これが最初に作成されると、/etc/hosts ファイルから情報が得られる
fns_user.ctx
ユーザー属性とサブコンテキストのデータを格納する。これが最初に作成されると、/etc/passwd ファイルから情報が得られる
fns_org.ctx
fns_host.attr
fns_user.attr
fns_org.attr
ユーザーのサブコンテキストと属性の情報は、各ユーザーが所有する別個の /var/fn ファイルに格納される。これにより、ユーザーは FNS コマンドを使用して、自分のデータを変更できる。これらのユーザー固有のファイルは、fns_user_username.ctx とネーミングされる。ここでの username は、個々のユーザーのログイン ID になる
ホスト、ユーザー、およびエンタープライズのサービスとファイルのコンテキスト情報は、それぞれ fns_host.ctx、fns_user.ctx、および fns_org.ctx のファイルに格納されます。プリンタのコンテキスト情報は、他のサービスのコンテキスト情報と同じファイルに格納されます。
サイトは、エンタープライズのサブコンテキストであり、サイトのコンテキスト情報は fns_org.ctx ファイルに格納されます。
これらの FNS マップは、直接編集しないでください。fncreate 、fndestroy、fnbind、fnunbind、fnrename、fnattr、fnlookup、および fnlist などの適切な FNS コマンドを実行して、これらのファイルで変更または作業を行います。スーパーユーザーとしてこれらのコマンドを実行すると、ホスト、サイト、および組織単位などの、コマンドが適用されるコンテキストが影響されます。ユーザーとしてこれらのコマンドを実行すると、自分のユーザーのサブコンテキストだけが影響されます。
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 マップは変更されません。
この章では、すでに存在しているエンタープライズレベルのコンテキストを、個別に作成、管理する方法について説明します。
FNS コンテキストは、fncreate コマンドを使用して作成します。この節では、『Solaris ネーミングの設定と構成』に説明されているような組織全体の FNS コンテキストではなく、個別に FNS コンテキストを作成する方法について説明します。fncreate コマンドは、指定されたタイプのコンテキストを作成し、そのコンテキストを任意の複合名とバインドします。また、コンテキストのサブコンテキストを作成することもできます。
fncreate -t context_type [-f input_file][-o][-r reference_type][-s][-v] [-D] composite_name |
オプション |
説明 |
---|---|
-t context |
作成するコンテキストのタイプを指定する。context には、org、hostname、username、host、user、service、site、nsid、generic、fs のうちいずれかを使用する |
-f |
input_file に指定された個々のホストまたはユーザーのコンテキストを作成する。このオプションは、-t username オプションまたは -t hostname オプションと併用される場合にだけ有効で、対応する NIS+ passwd テーブル (または hosts テーブル) 中のユーザー (またはホスト) のサブセットのコンテキストを個々に作成する場合に使用できる |
-o |
指定されたコンテキストだけを作成する。-o オプションを指定しないと、サブコンテキストは FNS ポリシーに基づいて作成される |
-r |
作成される汎用コンテキストの reference_type を指定する。これは -t generic オプションと併用される場合にだけ有効 |
-s |
すでに使用されている複合名で、新しいコンテキストを作成する。このオプションを使用しなければ、すでにバインドされている名前で新しいコンテキストを作成できない |
-D |
コンテキストが作成されるたびに、コンテキストに関連付けられた NIS+ オブジェクトの情報を表示する。このオプションはデバッグに役立つ |
-v |
コンテキスト作成時に、作成に関する情報を表示する |
組織コンテキスト作成時に -o オプションを指定した場合、host、user、service のコンテキストは作成されてもサブコンテキストは生成されません。
名前空間識別子にバインドされるコンテキストを作成する場合、下線のない名前 (user など) はコンテキストの作成に使用され、下線の付いた名前 (_user など) は新しく作成されたコンテキストのリファレンスにバインドされます。この点は、コマンド行で指定された名前が下線のついてものであるか否かに関わらず常に同じです。
たとえば、以下のコマンドでは、org/sales/user のコンテキストが作成され、org/sales/_user が org/sales/user のコンテキストのリファレンスにバインドされます。
fncreate -t username org/sales/_user |
組織コンテキストを作成するには、コンテキストタイプに org を指定します。複合名には、使用しているネームサービスによって以下のいずれかにする必要があります。
「NIS+」の場合
すでに存在している NIS+ ドメイン (またはサブドメイン) の名前。NIS+ ドメインとは、org_dir サブディレクトリを含む NIS+ ディレクトリオブジェクトのことです。ドメインの org_dir サブディレクトリには、そのドメインの生成された host テーブルと passwd テーブルが必要です。
「NIS」の場合
/etc ファイルの場合
NIS+ のルートドメインが doc.com で、sales.doc.com というサブドメインがあるとします。sales というサブドメインに対応する sales という組織コンテキストを作成するには、以下のコマンドを入力します。
fncreate -t org org/sales/ |
新しいコンテキストの作成時には、ドメインである sales.doc.com の下に ctx_dir というディレクトリが作成されます。すでに ctx_dir が存在する場合は作成されません。
上記の例では -t オプションだけを使用し、-o オプションは使用しません。これによって複合名 org/sales/ の組織コンテキストが作成されると同時に、サブコンテキストとして hostname、username、service が作成されます。また host コンテキストと user コンテキスト、ホストとユーザーの service サブコンテキストも作成されます。実際には以下のコマンドが実行されます。
fncreate -t hostname org/sales/host/ fncreate -t username org/sales/user/ fncreate -t service org/sales/service/ |
代わりに fncreate -o -t org を使用すると、org コンテキストだけが作成されます。hostname、username、service のコンテキストは作成されますが、host コンテキストと user コンテキストの生成はされません。
org コンテキストの所有者となるのは、fncreate コマンドを実行した管理者です。この点は、hostname、username、service といったサブコンテキストについても同様です。ただし、host コンテキスト、user コンテキストとそのサブコンテキストの所有者となるのは、コンテキストの作成対象となったホストおよびユーザーです。管理者が引き続き host コンテキストや user コンテキストを処理するには、fncreate を実行する時に NIS_GROUP
環境変数を適宜設定する必要があります。たとえば、C シェルの場合、NIS_GROUP
を以下のように fns_admins.doc.com に設定します。
rootmaster# setenv NIS_GROUP fns_admins.doc.com |
fncreate で hostname をコンテキストのタイプとして指定すると hostname コンテキストが作成されます。hostname コンテキストでは、host コンテキストの作成、バインドができます。この場合、-o オプションを指定しなければ、host コンテキスト (およびそのサブコンテキスト) も NIS+ の host.org_dir テーブル中のホストごとに作成されます。-o オプションを指定した場合は、コンテキストだけが作成されます。
fncreate -t hostname org/sales/host/ |
hostname コンテキストが作成されます。
fncreate -t host org/sales/host/hname |
hname とは、各マシンの hosts.org_dir テーブル中にある名前です。また org/sales/_host/ の、org/sales/host/ のリファレンスへのバインドも行われます。
hostname コンテキストの所有者となるのは、fncreate コマンドを実行した管理者です。また host コンテキスト (およびそのサブコンテキスト) の所有者となるのは、コンテキストの作成対象となったホストです。つまり、個々のホストがそれぞれ自分のホストのコンテキスト (およびそのサブコンテキスト) を持つことになります。
-f オプションを使用すると、NIS+ の hosts.org_dir テーブル中のホストの、サブセットのコンテキストを作成できます。このオプションでは、input_file に指定されたホストのコンテキストが作成されます。
fncreate で host をコンテキストのタイプとして指定すると、ホストのコンテキストとサブコンテキストが作成されます。-o オプションを指定しなければ、ホストの service コンテキストと fs のバインディングが作成されます。-o オプションを指定した場合は、host コンテキストだけが作成されます。
# fncreate -t host org/sales/host/antares/ |
antares というホストのコンテキストが作成されます。実際には以下のコマンドが実行されます。
fncreate -t service org/sales/host/antares/service/ fncreate -t fs org/sales/host/antares/fs/ |
host コンテキスト (およびそのサブコンテキスト) の所有者となるのはホストです。上記の例では antares というホスト (NIS+ 主体名 antares.sales.doc.com) が以下のコンテキストの所有者となります。
org/sales/host/antares/
org/sales/host/capsule/service/
org/sales/host/capsule/fs
ただしこの場合、ホストの属する hostname コンテキスト (上記の例では、org/sales/host/) が必要です。また NIS+ テーブル hosts.org_dir に、ホスト名を指定する必要があります。
NIS+ テーブル hosts.org_dir には、別名を持つホストが存在することもあります。この種のホストは、テーブル中では「1つの正式名にいくつかの別名が対応づけられている」という形で表されます。
FNSにおいては、たとえ複数の別名を持っていても、1つのホストが持つ host コンテキストは1つだけです。hostname コンテキスト中のホストの別名がバインドされるのは、正式名と同じコンテキストのリファレンスです。
fncreate で username をコンテキストのタイプとして指定すると、username コンテキストが作成されます。username コンテキストでは、個々の user コンテキストの作成とバインドが行われます。-o オプションを指定しないと、NIS+ テーブル passwd.org_dir に存在するユーザー名ごとに、user コンテキスト (およびそのサブコンテキスト) が作成されます。-o オプションを指定した場合は、username コンテキストだけが作成されます。
たとえば、以下のコマンドを実行すると、
# fncreate -t username org/sales/user/ |
username コンテキストが作成されます。
fncreate -t user org/sales/user/uname |
実際には、passwd.org_dir テーブルに存在するユーザー uname ごとに、以下のコマンドが実行されます。また、org/sales/_user/ の org/sales/user/ へのバインドも行われます。
username コンテキストの所有者となるのは、fncreate コマンドを実行した管理者です。個々の user コンテキスト (およびそのサブコンテキスト) の所有者となるのは、コンテキストの作成対象となったユーザーです。ユーザーがそれぞれ独自の user コンテキスト (およびそのサブコンテキスト) を所有することになります。
-f オプションを使用すると、NIS+ テーブル passwd.org_dir に存在するユーザーのサブセットのコンテキストを作成できます。このオプションでは、input_file に指定されたホストのコンテキストが作成されます。
fncreate で user をコンテキストタイプとして指定すると、ユーザーの user コンテキスト (およびそのサブコンテキスト) が作成されます。-o オプションを指定しなければ、user コンテキストの下に service サブコンテキストと fs のバインディングが作成されます。-o オプションを指定した場合は、user コンテキストだけが作成されます。
たとえば、以下のコマンドでは、
# fncreate -t user org/sales/user/jjones/ |
jjones という名前のユーザーの user コンテキストが作成されます。実際には、以下のコマンドが実行されます。
fncreate -t service org/sales/user/jjones/service/ fncreate -t fs org/sales/user/jjones/fs/ |
user コンテキスト (およびそのサブコンテキスト) の所有者となるのは、コンテキストの作成対象となったユーザーです。上記の場合、作成されたコンテキストの所有者となるのは、jjones というユーザー (NIS+ 主体名 jjones.sales.doc.com) です。
ただしこの場合、ユーザーの属する username コンテキスト (上記の org/sales/user) が必要です。また、指定されたユーザー名が NIS+ テーブル passwd.org_dir 中に存在している必要があります。
fncreate でコンテキストタイプとして service を指定すると、service コンテキストが作成されます。service コンテキストでは、サービス名のバインドが行えます。service コンテキスト中でバインドできるリファレンスのタイプに制約はありません。ただし、service コンテキストを使用するアプリケーションによっては制約が設けられます。たとえば、デスクトップアプリケーションのグループなら、service コンテキスト中でバインドされるリファレンスのタイプは、カレンダ、カードファイル、ファックスサービス、プリンタなどになるでしょう。
# fncreate -t service org/sales/service/ |
sales という組織の service コンテキストが作成されます。末尾の名前 (service) は名前空間識別子なので、fncreate では org/sales/_service/ の org/sales/service/ のリファレンスへのバインドも行われます。このコマンドの実行後は、org/sales/service/calendar、org/sales/service/fax といった名前をこのサービスコンテキストでバインドできます。
service コンテキストでは、階層型の名前空間 (左から順に名前が並べられ、名前と名前の間はスラッシュで区切られる) がサポートされています。これによってアプリケーションは、名前空間をサービスごとに区切ることができます。デスクトップアプリケーションの場合、plotter コンテキストを作成した後に以下のコマンドを使用すれば、service コンテキストの下に plotter のグループを作成することができます。
# fncreate -t service org/sales/service/plotter |
さらにこの下には、org/sales/service/plotter/speedy、org/sales/service/plotter/color といった名前をバインドできます。
ただし、末尾の名前が名前空間識別子ではないので、service と _service のようなバインドが行われることはありません。
作成される service コンテキストの所有者となるのは、fncreate コマンドを実行した管理者です 。
プリンタコンテキストは、複合名の service コンテキストの下に作成されます。
fncreate でコンテキストタイプに generic を使用すると、バインディング名のコンテキスト (アプリケーションによって使用される) が作成されます。
generic コンテキストは、リファレンスのタイプを変更できるという点以外は service コンテキストと同じです。generic コンテキストのリファレンスのタイプを指定するには、-r オプションを使用します。このオプションが省略された場合は、親コンテキストが generic タイプであればそれがそのまま使用され、別のタイプであればデフォルトとして指定されたものが使用されます。
service コンテキストと同様、generic コンテキストにバインドされるリファレンスのタイプには制約がありません。ただし generic コンテキストを使用するアプリケーションによって制約が設けられる場合があります。
# fncreate -t generic -r WIDC_comm org/sales/service/extcomm |
sales という組織の service コンテキストの下に、リファレンスタイプ WIDC_comm の generic コンテキストが作成されます。この generic コンテキストでは、org/sales/service/extcomm/modem などの名前がバインドできます。
generic コンテキストでは、階層型の名前空間 (左から順に名前が並べられ、名前と名前の間はスラッシュで区切られる) がサポートされています。これによってアプリケーションは、名前空間をサービスごとに区切ることができます。上の例の場合、以下のコマンドを使用すれば、modem 用の generic サブコンテキストが作成できます。
# fncreate -t generic org/sales/service/extcomm/modem |
さらにこの下には、org/sales/service/extcomm/modem/secure、org/sales/service/extcomm/modem/public といった名前をバインドできます。
作成された generic コンテキストの所有者となるのは、fncreate コマンドを実行した管理者です。
site コンテキストでは、サイト名のバインドが行えます。
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-5 の service コンテキストが作成できます。
# fncreate -t service org/sales/site/alameda.bldg-5/service/ |
作成された nsid コンテキストの所有者となるのは、fncreate コマンドを実行した管理者です。
FNS コンテキストを管理する (コンテキストの内容を確認する) ためのツールには様々な種類があります。以下の表は、そのツール (コマンド) の構文を示したものです。
fnlookup は、複合名のバインドに関する情報を表示するのに使用します。
fnlookup [-v][-L] composite_name |
オプション |
説明 |
---|---|
-v |
詳細なバインド関連情報を表示する |
-L |
「XFN リンクのバインド先となるのはどのリファレンスか」を表示する |
たとえば、以下の例では、ユーザー darwin のバインドに関する情報が表示されます。
# fnlookup -v user/darwin/ Reference type: onc_fn_user Address type: onc_fn_nisplus length: 52 context type: user representation: normal version: 0 internal name: fns_user_darwin.ctx_dir.sales.doc.com. |
ここで user/Charles.Darwin が user/darwin にリンクされているとすると、下の例の最初のコマンドでは、user/Charles.Darwin のバインド先 (XFNリンク) が表示されます。2 番目のコマンドでは、XFNリンク user/jjones が調べられ、user/darwin のバインド先 (user コンテキスト) が表示されます。
# fnlookup user/Charles.Darwin Reference type: fn_link_ref Address type: fn_link_addr Link name: user/darwin # fnlookup -L user/Charles.Darwin Reference type: onc_fn_user Address type: onc_fn_nisplus context type: user |
fnlist は、コンテキストの内容を表示するのに使用されます。
fnlist [-lv] [name] |
オプション |
説明 |
---|---|
-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 |
オプション |
説明 |
---|---|
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}+ |
オプション |
説明 |
---|---|
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/ |
削除の対象となるコンテキスト (指定された複合名を持つもの) にサブコンテキストが存在する場合、コマンドは正常に動作しません。
この章では、アプリケーション固有のコンテキストをどのように管理するかについて説明します。
ファイルコンテキストには、以下のようなものがあります。
fncreate_fs コマンドを使用して作成したもの (「fncreate_fs を使ってファイルコンテキストを作成する」を参照)
fnlist コマンド (「コンテキストの内容を表示する」を参照)、あるいは fnlookup コマンド (「バインドに関する情報を表示する」を参照) を使用して、検索されたもの
fnunbind コマンド (「複合名を削除する」を参照)、あるいは fndestroy コマンド (「コンテキストを削除する」を参照) を使用して、切り取られたものあるいは削除されたもの
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...] |
オプション |
説明 |
---|---|
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...] |
name には、リファレンス名が入ります。name フィールドは、単純な原子名のこともあれば、あるいはスラッシュで区切った階層構造を示す名前の場合もあります。さらに (.) といったようにドットを使って示すこともあり、この場合リファレンスは、composite_name に直接バインディングされます。
options には、マウントのオプションがあれば、それが入ります。options フィールドは、ハイフン (-) で始まります。この後に、マウントオプションのコンマで区切ったリスト (スペースなし) が続き、これはディレクトリをマウントするのに使用されます。またこれらのオプションは、composite_name/name サブコンテキストにも適用されます。なお、composite_name/name は、それ自身のマウントオプションは指定しません。
location には、マウントの位置が入ります。location フィールドでは、composite_name/name のファイルを提供する 1 つあるいは複数のホストを指定します。簡単な NFS マウントでは、location は、以下のような形式をとります。
host:path |
host には、ファイルシステムをマウントするサーバー名が入ります。path には、マウントするディレクトリのパス名が入ります。
各エントリについて、マウントの位置や対応するマウントのオプションのリファレンスは、composite_name/name に割り当てられます。
options と location の両方が省略されると、リファレンスは composite_name/name にバインドされません。既存のリファレンスもすべてバインドされません。
たとえば、kuanda のファイルシステムを図 22-4 に示すように、ホスト altair からディレクトリ /export/home/kuanda に NFS マウントするとしましょう。コマンドは以下のように実行されます。
% fncreate_fs -f infile user/kuanda/fs |
. 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 |
プロジェクトやそのサブコンテキストの src や lib の NFS マウントを、読み取り専用に変更する場合、infile を以下のように変更します。
tools/db svr1:/export/db project -ro svr1:/export/projproject/lib altair:/export/lib project/src svr2:/export/src |
-ro は、3 行目と 4 行目では必要ありません。なぜならば、src および lib は、project のサブコンテキストであり、これらは、上から -ro マウントオプションを継承するからです。
以下の入力ファイルは、org/sales/fs/project/src を除いて、すべてのマウントを読み取り専用にします。
. -ro tools/db svr1:/export/db project svr1:/export/proj project/lib altair:/export/lib project/src -rw svr2:/export/src |
fncreate_fs コマンドにより、以下のようにバインディングの説明をコマンド行で入れることもできます。
fncreate_fs composite_name [ mmount_options] [mount_location ...] |
これは、コマンドの入力ファイル書式を使用し、キーボードから個々のバインディングを入力するのと同じです。先の kuanda のファイルシステムを設定した例は、コマンド行からは、以下のように設定できます。
% fncreate_fs user/kuanda/fs altair:/export/home/kuanda |
同様に、図 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_fs の options や location のフィールドで使用できます。たとえば、マウントの位置は、以下のように指定できます。
altair:/export/$CPU |
対応するファイルシステムにマウントする際、オートマウンタにより、これらの変数がクライアントに固有の値に置き換えられます。上の例の場合、$CPU は、uname -p の出力結果、たとえば sparc で置き換えられます。
さらにオートマウントマップとの互換として、以下の入力ファイル書式も fncreate_fs で使用できます。
name [mount_options ] [mount_location ...] ¥ / offset1 [mount_options1] mount_location1 ... ¥ / offset2 [mount_options2] mount_location2 ... ¥ ... |
ここでは、各 offset フィールドは、スラッシュで区切った階層構造になっています。バックスラッシュ (¥) は、1 つの長い行の続きであることを示します。これは、以下を行うのと同じことです。
name [mount_options ] [mount_location ...] ¥ name/offset1 [mount_options1 ] mount_location1 ... ¥ name/offset2 [mount_options2 ] mount_location2 ...... |
最初の行は、mount_options と mount_location の両方が省略されている場合、省略します。この書式は、互換のためだけのものです。これ以外の機能はないので、あまり使用しないでください。
この章では、2 つのグローバルネーミングシステム (DNS と X.500/LDAP) とそれらを FNS でフェデレートする方法について説明します。
FNS とグローバルネームサービスの関係についての概要および背景に関しては、「グローバルネームサービス」を参照してください。
FNS は、エンタープライズネーミングシステムのグローバルネーミングシステム、DNS、および X.500/LDAP のフェデレーションをサポートします。この章では、NIS+ を DNS および X.500 でフェデレートするための手順について説明します。通常、この手順には以下の内容が含まれます。
NIS+ 階層構造用に NIS+ ルートリファレンスを決定する
この情報をグローバルネーミングシステムで必要なフォーマットで追加する
エンタープライズレベルのネームサービスが NIS+ もしくは NIS の場合、グローバルネーミングサービスしかフェデレートできません。企業用にファイルベースのネームサービスを使用している場合、DNS も X.500/LDAP もフェデレートできません。
DNS、あるいは X.500/LDAP でエンタープライズネームサービスをフェデレートする場合、企業や企業外部のグローバルインターネットからの、あるいはそれらへのアクセスができるようにするために、情報をこれらそれぞれのネーミングシステムに追加する必要があります。この情報とは「ルートリファレンス」のことで、これは、ある特定の企業の名前空間の最上部にどのようにして到達するかを示すネットワークアドレス情報からできています。
ルートリファレンスは、XDR で符号化した 1 つの文字列を含む 1 つのアドレスからできています。アドレスのタイプと内容は、使用しているエンタープライズレベルのネームサービスによって、つまり NIS+ かあるいは NIS かによって異なります。
エンタープライズレベルのネームサービスが NIS+ の場合、ルートリファレンスのアドレスタイプは、onc_fn_nisplus_root になります。ルートリファレンスネットワークアドレスには、必要 (必須の) 要素が 2 つと、オプションの要素が 1 つあります。要素は、以下のように空白文字で区切られます。
root-domain server [server_IP_address] |
アドレス要素 |
説明 |
---|---|
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 の場合、ルートリファレンスのアドレスタイプは、onc_fn_nis_root になります。ルートリファレンスネットワークアドレスには必要 (必須の) 要素が 2 つと、オプションの要素が 1 つあります。要素は、以下のように空白文字で区切られます。
root_domain server [server_IP_address] |
アドレスの要素 |
説明 |
---|---|
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 |
この項では、NIS+ あるいは NIS が使われている下位のエンタープライズネーミングシステムのための、TXT (テキスト) レコードを追加するのに必要な手順を説明します。DNS で下位のネーミングシステムをフェデレートする場合、DNS にリファレンス情報を追加し、下位のネーミングシステムのルートリファレンスへの到達の仕方を記述する必要があります。
ルートリファレンスを取得します。
詳細は、「ルートリファレンスを取得する」を参照してください。
ルートリファレンス 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 の構成ファイルとデータファイル」を参照してください。
TXT レコードを DNS テーブルに追加した後、DNS サーバーを再スタートするか、あるいはこれにテーブルを再度読むようシグナルを送ります。
# kill -HUP pid |
pid のところには、in.named のプロセス ID 番号が入ります。
DNS TXT を XFN リファレンス用に使用する方法の詳細は、「XFN リファレンス用 DNS 文書レコードの書式」を参照してください。
X.500/LDAP で下位のネーミングシステム (NIS+ または NIS) をフェデレートする場合、以下の規則があります。
ルートリファレンスの情報は、下位のネーミングシステムへどのように到達するかを示すもので、X.500 に追加する必要があります。
X.500 クライアント API を指定する必要があります。
NIS+ 階層構造用の NIS+ ルートリファレンスを取得します。
詳細は、「ルートリファレンスを取得する」を参照してください。
XFN リファレンス属性をサポートする X.500 エントリを作成します。
たとえば、以下のコマンドは、オブジェクトクラスである top、organization、および 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 オブジェクトクラスで定義されたものでない場合、これを削除し、オブジェクトクラスを追加して作成し直す必要があります。そうでないと、下位のネーミングシステムに関するリファレンス情報を保持しておくことができなくなります。
下位のシステムに関するリファレンス情報をエントリに追加します。
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 は、FNS を使って X.500 にアクセスする場合に必要です。以下の 2 つの異なるクライアントのうちどちらか 1 つを使うことができます。
「XDS/XOM API」
XDS/XOM API がインストールされていることが必要です。これは共用オブジェクトである /opt/SUNWxds/lib/libxomxds.soからエクスポートされます。X.500 製品については、『Getting Started with the SunLink X.500 Client Toolkit』を読んでください。
「LDAP (Lightweight Directory Access Protocol - 軽量ディレクトリアクセスプロトコル)」。Solaris リリース 2.6 の一部として、LDAP API が自動的にインストールされています。
使用する 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 がそのサーバーで使用できない場合、次のサーバーが試されます。
この章では、FNS 属性と、その管理の方法について説明します。
属性は、名前付きオブジェクトに使用することができます。属性はオプション指定ですから、属性のないオブジェクトもあれば、1 つあるいは複数の属性を持つオブジェクトもあります。
属性はユニークな属性識別子、属性構文、および 0 個以上の明確な属性値のセットからなります。
XFN で、既存の名前付きオブジェクトに対応する属性値の検索や変更のための、基本的な属性インタフェースが定義されます。これらのオブジェクトはコンテキストの場合もあれば、別のタイプのオブジェクトの場合もあります。コンテキストに関連しているのは、構文属性で、これはコンテキストがどのように複合名を解析するかを示します。
拡張属性インタフェースには、特定の属性を検索したり、オブジェクトやそれに対応する属性を作成するオペレーションが含まれます。
fnsearch [-ALlv] [-n max] [-s scope] name [-a ident ]... [-O|-U] filter_expr [ filter_arg] |
オプション |
説明 |
---|---|
-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 フィルタ表現の演算子
フィルタ表現演算子 |
シンボル、あるいは形式 |
---|---|
論理演算子 |
or、and、not |
グルーピングのための丸括弧 |
( ) |
関係演算子:ある属性を入力した値と比較する |
== 少なくとも 1 つの属性値が、入力した値に等しい場合、True (真) != 入力した値に等しい属性値がまったくない場合、True (真) < 少なくとも 1 つの属性値が、入力した値より小さい場合、True (真) <= 少なくとも 1 つの属性値が、入力した値よりも小さいか等しい場合、True (真) >少なくとも 1 つの属性値が、入力した値よりも大きい場合、True (真) >= 少なくとも 1 つの属性値が、入力した値よりも大きいか、等しい場合、True (真) ‾= 少なくとも 1 つの属性値が、いくつかのコンテキスト特有のおおまかな一致条件に照らして、入力した値に一致している場合、True (真)。この条件は厳密な一致を含む必要がある |
例 |
% fnsearch name "not (make == 'olds' and year == 1983)" |
置換トークン: シェルスクリプトを書くときに役に立ち、-O および -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] |
オプション |
説明 |
---|---|
name |
複合名 |
identifier |
属性名 |
values |
1 つあるいは複数の属性値 |
oldvalue |
変更する属性値 |
newvalue |
新しい属性値 |
-a |
新しい属性値を追加 (作成) する |
-d |
属性を削除する |
-m |
属性を変更 (修正) する |
-l |
属性値を一覧表示する |
-s |
「代用」モードで追加する。identifier 属性に対する既存の値をすべて削除し、新しい属性値を作成する |
-l |
属性と値を一覧表示する |
-O |
識別子として OSI OID を使用する |
-U |
識別子として DCE UUID を使用する |
各オプションでの識別子の形式は、-O あるいは -U のオプションを使用していない限り、FN_ID_STRING になります。
属性を追加したり、属性に値を追加したりするには、-a オプションを使用します。この場合、複合名、属性識別子、追加する値も指定します。
fnattr -a [-s] name [-O | -U] identifier value1 [ value2+] |
以下の例では、属性識別子 model と値 hplaser が thisorgunit/service/printer に追加されます。
# fnattr -a thisorgunit/service/printer model hplaser |
-s は、「代用モードで追加する」という意味のオプションです。指定の識別子を持つ属性がすでに存在する場合、-s はその値をすべて削除し、それらを追加した値に置き換えます。このオプションを指定しないと、指定した属性の値には既存の値と追加した新しい値の両方が含まれることになります。
# fnattr -as thisorgunit/service/printer model hplaser |
上の例では最初に model に対応する値をすべて削除し、hplaser を値として追加します。
FNS 名前付きオブジェクトの属性を削除するには、-d オプションを使用します。
fnattr -d name [[-O | -U] identifier value1 [ value2+]] |
削除対象の指定には以下の規則があります。
名前のみ。複合名だけを指定し、属性識別子を指定しないと、名前付きオブジェクトの属性はすべて削除される
名前および識別子のみ。複合名と属性識別子だけを指定し、属性値を指定しない場合、「identifier」によって識別された属性全体が削除される
名前、識別子、および値。複合名、属性識別子、および 1 つあるいは複数の属性値を指定した場合、これらの値だけが属性から削除される。属性の最後に残っている値が削除されると、属性自体が削除されたのと同じ結果になる
以下の例では、thisorgunit/service/printer のすべての属性が削除されます。
# fnattr -d thisorgunit/service/printer |
属性の内容を表示するには、-l オプションを使用します。構文は以下のとおりです。
fnattr -l name [[-O | -U] identifier] |
以下の例では、thisorgunit/service/printer の model 属性の値が表示されます。
# fnattr -l thisorgunit/service/printer model laser postscript |
識別子を指定しない場合、オブジェクトのすべての属性の内容が表示されます。
属性値を変更するには、-m オプションを使用します。構文は以下のとおりです。
fnattr -m name [-O | -U] identifier old_value new_value |
以下の例では、postscript という値が laser に変更されます。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) を使用します。