FNS 名前空間を設定する前に以下の作業を行います。
NIS+ ドメインが正確に設定されていることを確認します。
NIS+ドメインと関連のサブドメインが、FNS の構成前に設定済みである必要があります。つまり hosts と passwd など NIS+ の標準のテーブルが既に存在し、サブコンテキストが生成されている必要があります。
ドメインの hosts.org_dir と passwd.org_dir のテーブルが、すべてのホスト名とユーザー名を持つサブコンテキストが生成されていることを確認します。
niscat と nismatch のコマンドを使用して、これらテーブルの内容を確認できます。
NIS_GROUP
環境変数を、FNS オブジェクトを管理するグループの名前に設定します。
この変数を最初に設定しないと、fncreate コマンドで FNS 設定を完了できません。fncreate コマンドがユーザーとホストのコンテキストを作成するとき、それらはコマンドを実行したシステム管理者ではなく、そのホストとユーザーの所有となります。NIS_GROUP
の設定によって、グループのメンバーになっているシステム管理者は、オブジェクトを所有していなくてもコンテキストを修正できます。
Cシェルの場合、次のように NIS_GROUP
に fns_admins.doc.com を設定します。
rootmaster# setenv NIS_GROUP fns_admins.doc.com |
[必要に応じて] NIS+ マスターサーバー以外のマシンで FNS を実行するように指定します。
FNS が使用する、すべての NIS+ オブジェクトは、NIS+ ドメインの ctx_dir ディレクトリの下に保管されます。5,000 以上のユーザーやホストを有する大規模なドメインでは、FNS が使用する ctx_dir が、groups_dir のような標準の NIS+ ディレクトリをサポートするサーバーとは別のサーバーによってサポートされるようにしてください。これは必須ではありませんが、推奨されています。別個のサーバーを使用することで、1 つのサーバーに過剰な負荷がかからなくなります。またこれによって、FNS による NIS+ の使用の管理と NIS+ 自体の管理を分離できます。
ドメインに対する NIS+ マスターサーバーではないマシンによって FNS が提供されるように指定するには、ドメインに対する FNS ホストとして機能するマシン上に ctx_dir ディレクトリオブジェクトを手作業で作成する必要があります。この手順を省略すると、FNS はドメインの NIS+ ルートマスターサーバーにインストールされます。
FNS のマスターサーバーになるマシンを指定するには次のようにします。
NIS+ ドメインに ctx_dir ディレクトリを作成します。
たとえば、doc.com ドメイン内で fns_server と名前のついたマシン上に ctx_dir ディレクトリを作成するには、ドメインのマスターサーバーで次のコマンドを実行します。ドメイン名の最後にドットが付いていることに注意してください。
nismaster# nismkdir -m fns_server ctx_dir.doc.com. |
nismkdir コマンドによる NIS+ ディレクトリの作成については、『Solaris ネーミングの管理』を参照してください。
「サブドメイン」用の FNS の ctx_dir を作成する場合、ctx_dir を提供する FNS サーバーとして指定するマシンはサブドメイン内に存在する必要があります、親ドメイン内のマシンは指定できません。これとは対照的に、サブドメインの NIS+ のマスターサーバーは常に、それが機能する 1 つ上のドメインに存在します。つまり、NIS+ のサブドメインに対して FNS を構成しているときに、NIS+ と FNS の両方で同じサーバーを使用する場合には、そのサーバーはサブドメインの上のドメインに存在します。しかし、NIS+ と FNS で異なるサーバーを使用する場合には、NIS+ のマスターサーバーはその上のドメインに存在し、FNS サーバーはそれが機能するサブドメインに存在します。
nisls コマンドを使用して、ctx_dir ディレクトリが作成されたことを検証します。
rootmaster# nisls doc.com.ctx_dir |
nisping を実行して、ディレクトリをチェックポイントします。
# /usr/lib/nis/nisping -C ctx_dir.doc.com. |