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

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

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

fncreate -t context_type [-f input_file][-o][-r reference_type][-s][-v] [-D] composite_name

組織コンテキスト作成時に -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」の場合

  NIS ドメインの名前。host マップと passwd マップが必要です。

• /etc ファイルの場合

  /etc ファイルを使用するのは、org// 組織コンテキストだけです。

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

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

fncreate -t org org/sales/

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

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

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

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

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

rootmaster# setenv NIS_GROUP fns_admins.doc.com 

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

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

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

fncreate -t hostname org/sales/host/

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

fncreate -t host org/sales/host/hname

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

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

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

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

fncreate で host をコンテキストのタイプとして指定すると、ホストのコンテキストとサブコンテキストが作成されます。-o オプションを指定しなければ、ホストの service コンテキストと fs のバインディングが作成されます。-o オプションを指定した場合は、host コンテキストだけが作成されます。

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

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

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

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

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

• 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 には、別名を持つホストが存在することもあります。この種のホストは、テーブル中では「１つの正式名にいくつかの別名が対応づけられている」という形で表されます。

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

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

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

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

# fncreate -t username org/sales/user/

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

fncreate -t user org/sales/user/uname

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

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

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

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

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

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

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

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

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

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

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

サービスのコンテキスト

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

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

# fncreate -t service org/sales/service/

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

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

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

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

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

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

プリンタコンテキスト

プリンタコンテキストは、複合名の 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 コンテキストでは、サイト名のバインドが行えます。

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 コマンドを実行した管理者です。