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

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

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

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


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

オプション 

説明 

-t context

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

-f

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

-o

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

-r

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

-s

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

-D

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

-v

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


注 –

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


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

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


fncreate -t username org/sales/_user

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

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

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

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

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


fncreate -t org org/sales/

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

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


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

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

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


rootmaster# setenv NIS_GROUP fns_admins.doc.com

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

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

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


fncreate -t hostname org/sales/host/

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


fncreate -t host org/sales/host/hname

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

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

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

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

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

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


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

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


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

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

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

ホストの別名

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

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

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

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

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


# fncreate -t username org/sales/user/

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


fncreate -t user org/sales/user/uname

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

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

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

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

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

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


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

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


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

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

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

サービスのコンテキスト

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

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


# fncreate -t service org/sales/service/

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

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


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

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


注 –

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


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

プリンタコンテキスト

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

汎用コンテキスト

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

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

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

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


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

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

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


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

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

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

サイトコンテキスト

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

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


# fncreate -t site org/sales/site/

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

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

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


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

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


注 –

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


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

ファイルのコンテキスト

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


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

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

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

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

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

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

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

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


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

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


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

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

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