この章では、すでに存在しているエンタープライズレベルのコンテキストを、個別に作成、管理する方法について説明します。
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/ |
削除の対象となるコンテキスト (指定された複合名を持つもの) にサブコンテキストが存在する場合、コマンドは正常に動作しません。