この章では、NIS+、NIS、ファイルのネームサービス環境での FNS (Federated Naming Service) の初期設定と構成の方法を説明します。「ファイル」のネームサービスとは、NIS+ や NIS ではなく、/etc ファイルからデータを得るネームサービスのことです。
FNS の一般的な説明や概要については、『Solaris ネーミングの管理』を参照してください。
『Solaris ネーミングの管理』には、FNS の要約、設定と構成の手順の簡単な説明、プログラミング例を提供する「FNS の手引き」の章があります。システム管理者は、この章を参照してください。
Solaris 2.6 リリースソフトウェアのインストール後に次の作業を実行して、FNS を設定する必要があります。
サーバーが FNS を取り扱えることを確認します。「リソース条件の決定」を参照してください。
FNS 用の名前空間を準備します。「FNS 用の名前空間の準備」を参照してください。
FNS 名前空間のコンテキストを設定します。次の 2 つの方法があります。
1 つのプロセスで、すべてのコンテキストをグローバルに作成します。「FNS の名前空間コンテキストのグローバルな作成」を参照してください。
FNS コンテキストを個別に作成します。『Solaris ネーミングの管理』を参照してください。
FNS の複製サーバーを設定します。「FNS サービスの複製」を参照してください。
組織の大きさによっては、FNS の設定が完了するまでに数時間、名前空間の準備にもある程度の時間が必要になります。
インストールの手順に進む前に、FNS をサポートしているサーバーに十分なメモリーとディスク領域があることを最初に確認する必要があります。企業レベルのネームサービス (NIS+、NIS、ファイル) で必要な領域の他に FNS 用の領域が必要です。
一般的に確実な方法として、ユーザーとホストごとに、約 17 KB のディスク領域とスワップ領域が必要になります。このディスク領域が配置される場所と、その計算方法は、使用している企業レベルのネームサービスによって異なります。
「NIS+」
ドメインまたサブドメインに対して FNS サーバーとして機能するマシンに、ディスク領域が必要です。NIS+ 環境では、FNS の ctx_dir ディレクトリを提供するサーバーは、org_dir など標準の NIS+ ディレクトリを提供するのと同じサーバーである必要はありません。サーバーの負荷を均等にするために、大規模な構成で使用しているサイトの多くでは、NIS+ と FNS のサーバーに別個のマシンを使用しています。NIS+ 環境で FNS サーバーに必要な領域は、サーバーがネームサービスを提供するドメインまたはサブドメイン内のユーザーとホストの数で決まります。
「NIS」
ドメインに対して FNS サーバーとして機能するマシンにディスク領域が必要です。NIS 環境では、FNS をホストするサーバーは NIS をホストするのと同じサーバーである必要はありません。サーバーの負荷を均等にするために、大規模な構成で使用しているサイトの多くでは、NIS と FNS のサーバーに別個のマシンが使用されています。NIS 環境で FNS サーバーに必要な領域は、ドメイン内のユーザーとホストの数で決まります。
「ファイル」
企業レベルのネームサービスがファイルのときは、FNSに必要なディスク領域は、/var/fn をマウントするマシンの/etc/users と /etc/hosts のファイル内のユーザーとホストの数で決まります。マシンごとに /var/fn ディレクトリがある場合には、必要な領域は各マシンのユーザーとホストのファイルで決まります。/var/fn がマシンにマウントされ、FNS によってネットワーク上の残りのマシンにエクスポートされる場合には、/var/fn を提供するマシンに必要な領域は、マシンの /etc/users と /etc/hosts のファイル内のユーザーとホストの数で決まります。
たとえば、1,200 のユーザーとホストを持つ NIS+ ドメインで FNS 環境をサポートするには、以下が必要になります。
基礎となる名前空間で必要な領域 (NIS+、NIS、ファイル) の他に、少なくとも 20 M バイトのディスク領域
FNS 用に 40 M バイトのスワップ領域
この節では、fncreate を実行して FNS コンテキストを設定する前の準備について説明します。準備は該当する企業レベルのネームサービスによって異なります。以下を参照してください。
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 を実行して、ディレクトリをチェックポイントします。
rootmaster # /usr/lib/nis/nisping -C ctx_dir.doc.com.
FNS 名前空間を設定する前に、以下を実行します。
他の任意の NIS マップに対して異なるマスターを割り当てるのと同じ手順で、FNS マップに異なるマスターサーバーを割り当てることができます。詳細は、『Solaris ネーミングの管理』を参照してください。
ファイルを使用したネームサービスとは、NIS+ または NIS ではなく、/etc ファイルからデータを得るネームサービスのことです。
/var/fn ディレクトリをマシンごとにインストールする場合には、一般的に次の手順をマシンごとに実行する必要があります。1 つのマシンから /var/fn ディレクトリのマウントとエクスポートをする場合には、次の手順を /var/fn をエクスポートするマシンで実行する必要があります。
この節では、企業または NIS+ ドメインに対する名前空間をグローバルに作成する方法を説明します。
FNS の名前空間は、fncreate コマンドを使用して作成されます。
# fncreate -t org org//
もしくは次のコマンドを使用します。
# fncreate -t org org/domain/
この場合 domain 名は、NIS+ドメイン名またはサブドメイン名です。
次の 3 つの企業レベルのネームサービスに対する FNS の名前空間の作成については、以降の節を参照してください。
fncreate コマンドは、指定された編成と、そのすべてのサブコンテキスト用のデフォルトのコンテキストを作成します。これには編成内のユーザーとホストに対するコンテキストとサブコンテキストが含まれます。
個々の FNS コンテキストを手作業で作成する方法は、『Solaris ネーミングの管理』を参照してください。
企業レベルの主ネームサーバーが NIS+ であるときは、NIS+ ドメインまたはサブドメインごとに名前空間のコンテキストを個別に作成する必要があります。
NIS+ ドメインまたはサブドメインが既に存在する必要があります。
NIS+ と FNS の両方で同じサーバーを使用する場合には、ドメイン (サブドメイン) のマスターサーバーで fncreate コマンドを実行する必要があります。NIS+ と FNS で異なるサーバーを使用する場合には、FNS サーバーとして機能するマシンで fncreate コマンドを実行する必要があります。異なるマシンを使用する場合には、前記の「FNS 用の NIS+ サービスの準備」の手順 4 に従って FNS サーバーを最初に準備する必要があります。
NIS+ 管理の完全な認証が必要です。(NIS+ の認証については、『Solaris ネーミングの管理』を参照してください)。
たとえば、そのドメイン用の NIS+ マスターサーバーである submaster マシン上の manf.doc.com サブドメイン用にコンテキストを作成するには、次のようにしま。
submaster# fncreate -t org org/manf.doc.com./
これで、NIS+ manf.doc.com.サブドメイン用の編成コンテキスト、サブドメインの passwd.org_dir テーブルのすべてのユーザーとサブドメインの hosts.org_dir テーブルのすべてのホストに対するコンテキストとサブコンテキストが作成されます。
NIS+ と FNS のサーバーに異なるマシンを使用するには、FNS サーバーとして使用するマシン上で前述のコマンドを実行します。NIS+ ではないサーバーを FNS サーバーとして設定する方法についての説明は、前記の「FNS 用の NIS+ サービスの準備」の手順 4 を参照してください。
nisping コマンドを使用して ctx_dir ディレクトリをチェックポイントにします。
# /usr/lib/nis/nisping -C ctx_dir.manf.doc.com.
数千のユーザーやホストを有する大規模な組織では、最初の fncreate 操作に数時間、それ以降のチェックポイントにも数時間かかる場合があります。
企業レベルの主ネームサービスが NIS であるときは、企業に対して 1 つのドメインだけが存在します。その企業全体のドメインに対して名前空間コンテキストが作成されます。
NIS ドメインが既に存在する必要があります。
たとえば、NIS マスターサーバーでもある fns_master というマシン、doc.com ドメイン用にコンテキストを作成するには、次のようにします。
ドメインマスターで fncreate を次のように実行します。
fns_master# fncreate -t org org//
これで NIS ドメイン doc.com 用の編成コンテキストと、NIS サーバーの passwd マップのすべてのユーザーとサーバーの hosts マップの、すべてのホストに対するコンテキストと関連のサブコンテキストが作成されます。
コンテキストマップを作成したら、他の任意の NIS マップに異なるマスターを割り当てるのと同じ手順で、同じマシンをマスターサーバーに割り当てることができます。FNS マップはすべて、.ctx または .attr のいずれかで終わる名前をもちます。詳細は、『Solaris ネーミングの管理』を参照してください。
企業レベルの主ネームサービスがファイルであるときは、コンテキストはシステムに対して作成されます。
fncreate コマンドは、/var/fn ディレクトリが存在するマシン上で root によって実行される必要があります。
たとえば、システム用のコンテキストを作成するには、次のようにします。
これで、マシン内の /etc/passwd ファイルのすべてのユーザーとマシン内の /etc/hosts ファイルのすべてのホスト用にシステム、コンテキスト、関連のサブコンテキストに対する編成コンテキストが作成されます。
FNS のネームサービスの性能と信頼性が必須な大規模で重要性の高いネットワークでは、FNS サービスを複製してください。
マスターサーバーで FNS 名前空間が設定されたら、その他の複製サーバーを各ドメインに追加して、ドメインの ctx_dir を提供するサーバーにします。複製サーバーによって、サーバーの可用性と性能を拡張できます。
FNS のマスターサーバーで nismkdir コマンドを実行して、ctx_dir ディレクトリ用の複製を追加します。
たとえば、マシン fnsrserver を doc.com. ドメインの FNS の複製 サーバーにします。
# nismkdir -s fnsrserver ctx_dir.doc.com.
nisping コマンドで ctx_dir ディレクトリをチェックポイントします。
# /usr/lib/nis/nisping -C ctx_dir.doc.com.
FNS の複製は一定の間隔でチェックポイントしてください。間隔は、数日に一回程度をお勧めします。選択する間隔は、FNS 名前空間への変更頻度によって異なります。
FNS 名前空間がドメインのマスターサーバーで設定された後に、スレーブサーバーを追加して、サーバーの可用性と機能を拡張できます。
ルートとして、スレーブサーバーの /etc/hosts ファイルを編集して、他のすべての NIS サーバーの名前と IP アドレスを追加します。
クライアントとしてスレーブサーバーを初期化するには、以下を入力します。
# /usr/sbin/ypinit -c
ypinit コマンドが、NIS サーバーのリストの入力を促します。作業中のローカルスレーブの名前を最初に入力してからマスターサーバーを入力し、その後にドメイン内の他の NIS スレーブサーバーをネットワーク的に近いものから遠いものの順番で入力します。
NIS クライアントとして、新しいスレーブサーバーを最初に構成して、マスターサーバーから最初に NIS マップを得ることができるようにします。(詳細は、「NIS クライアントの設定」を参照してください)。
ypbind が実行中かどうかを判断するには、次のとおりに入力します。
# ps -ef | grep ypbind
リストが表示されたら、ypbind は実行中です。
ypbind が実行中なら、次のとおりに入力して停止させます。
# /usr/lib/netsvc/yp/ypstop
以下を入力して ypbind を再起動します。
# /usr/lib/netsvc/yp/ypstart
このマシンをスレーブとして初期化するには、以下を入力します。
# /usr/sbin/ypinit -s master
この場合、master は既存の NIS マスターサーバーのマシン名です。
スレーブサーバーの yp プロセスを停止します。
# /usr/lib/netsvc/yp/ypstop
yp サービスを再起動します。
# /usr/lib/netsvc/yp/ypstart
これとは別に、スレーブサーバーをリブートしてデーモンを自動的に開始することもできます。
主ネームサービスがファイルになっているときはサーバーの複製はありません。
FNS の管理、問題解決、エラーメッセージについては、『Solaris ネーミングの管理』を参照してください。