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

ルート以外のドメインの設定方法

ドメインのマスターサーバーにログインします。

新しいドメインのマスターにする予定のサーバーにログインします。この作業の手順では smaster という名前のサーバーを使用します。このサーバーは doc.com. ドメインに所属し、sales.doc.com. サブドメインのマスターサーバーになります。この作業を実行する管理者は、admin.doc.com. グループのメンバーである nisboss.doc.com. です。このグループには、doc.com. ディレクトリオブジェクトに対する完全なアクセス権が割り当てられています。

ドメインの管理グループを指定します。

実際に管理グループを作成するのは、手順 5 の時点でですが、ここで管理グループを指定する必要があります。これによって、次の手順で使用される nismkdir コマンドは、このグループに対する適切なアクセス権をもつディレクトリオブジェクトを作成できます。またこれは、手順 4 で使用する nissetup ユーティリティに対しても同じことを行います。

環境変数 NIS_GROUP に、ドメインの管理グループ名を設定します。ここでは、C シェルユーザーの場合と Bourne シェルまたは Korn シェルユーザーの場合の 2 つの例を示します。どちらの場合も NIS_GROUP を admin.sales.doc.com. に設定します。

C シェルの場合
smaster# setenv NIS_GROUP admin.sales.doc.com.
Bourne シェルまたは Korn シェルの場合
smaster# NIS_GROUP=admin.sales.doc.com. smaster# export NIS_GROUP

ドメインのディレクトリを作成し、そのサーバーを指定する

nismkdir コマンドは、新しいドメインのディレクトリ作成と、そのサポートサーバーの指定を 1 つの手順で行います。この構文を次に示します。
nismkdir -m master -s replica domain
-m フラグはマスターサーバーを指定し、-s フラグは複製サーバーを指定します。この例を次に示します。
smaster# nismkdir -m smaster -s salesreplica sales.doc.com.
注意 –
nismkdir は必ず (複製サーバーではなく) マスターサーバー上で実行してください。複製サーバー上で nismkdir を実行しないでください。複製サーバーで実行すると、マスターサーバーと複製サーバーの間で通信上の問題が発生します。

ディレクトリオブジェクトは /var/nis にロードされます。内容を表示するには、niscat -o コマンドを実行します。cat または more は使用しないでください。
smaster# niscat -o sales.doc.com. Object Name : Sales Owner : nisboss.doc.com. Group : admin.sales.doc.com. Domain : doc.com. Access Rights : ----rmcdr---r--- .
ルートディレクトリとは異なり、このディレクトリオブジェクトには適切なグループが割り当てられています。したがって、nischgrp を実行する必要はありません。

ドメインのサブディレクトリとテーブルを作成します。

この手順では、org_dir ディレクトリと groups_dir ディレクトリ、および NIS+ テーブルを新しいディレクトリオブジェクトの下に追加します。nissetup ユーティリティを使用しますが、新しいドメイン名の追加を忘れないでください。NIS 互換ドメインの場合、-Y フラグを指定します。

「NIS 互換の場合」

smaster# /usr/lib/nis/nissetup -Y sales.doc.com.

「標準 NIS+ の場合」

smaster# /usr/lib/nis/nissetup sales.doc.com.

このユーティリティによって追加されたオブジェクトを表示すると、次のようになります。

smaster# /usr/lib/nis/nissetup
org_dir.sales.doc.com. created
groups_dir.sales.doc.com. created
auto_master.org_dir.sales.doc.com. created
auto_home.org.dir.sales.doc.com. created
bootparams.org_dir.sales.doc.com. created
cred.org_dir.sales.doc.com. created
ethers.org_dir.sales.doc.com. created
group.org_dir.sales.doc.com. created
hosts.org_dir.sales.doc.com. created
mail_aliases.org_dir.sales.doc.com. created
sendmailvars.org_dir.sales.doc.com. created
netmasks.org_dir.sales.doc.com. created
netgroup.org_dir.sales.doc.com. created
networks.org_dir.sales.doc.com. created
passwd.org_dir.sales.doc.com. created
protocols.org_dir.sales.doc.com. created
rpc.org_dir.sales.doc.com. created
services.org_dir.sales.doc.com. created
timezone.org_dir.sales.doc.com. created

-Y オプションによって、標準の NIS+ ドメインの場合と同じテーブルとサブディレクトリが作成されますが、NIS クライアントからの要求が NIS+ テーブル内の情報にアクセスできるよう、未認証クラスに読み取り権が割り当てられます。

/var/nis/salesmaster に相当する自分のマスターを調べることによって、org_dir ディレクトリと groups_dir ディレクトリが存在することを確認できます。これらのディレクトリは、ルートオブジェクトおよびその他の NIS+ ファイルとともに登録されています。テーブルは org_dir ディレクトリに存在します。任意のテーブルの内容を調べるには、第 9 章「NIS+ テーブルの設定」で説明する niscat コマンドを実行します。ただしこの時点ではテーブルは空です。

ドメインの管理グループを作成します。

この手順では、手順 2 で指定した管理グループを作成します。nisgrpadm コマンドに -c オプションを付けて実行してください。次の例では admin.sales.doc.com. グループを作成します。
smaster# nisgrpadm -c admin.sales.doc.com. Group admin.sales.doc.com. created.
この手順ではグループを作成するだけであり、そのメンバー名の指定は行いません。指定は手順 9 で行います。

ディレクトリオブジェクトに完全なグループアクセス権を割り当てます。

デフォルトでは、ディレクトリオブジェクトはそのグループに読み取り権を与えるだけであり、これではその他のカテゴリと同様、グループも使うことができません。クライアントとサブドメインの構成を簡単にするため、ディレクトリオブジェクトがそのグループに与えるアクセス権を、読み取り権のみから読み取り権、変更権、作成権、削除権に変更します。次に示すように、nischmod コマンドを実行します。
smaster# nischmod g+rmcd sales.doc.com.
nischmod コマンドの使用方法の詳細については、第 15 章「NIS+ のアクセス権の管理」を参照してください。

ドメインの管理グループにサーバーを追加します。

この時点で、このドメインのグループにはメンバーがありません。-a オプションを付けて nisgrpadm コマンドを実行し、マスターサーバーと複製サーバーを追加します。最初の引数はグループ名であり、残りの引数は新しいメンバーの名前です。この例では、smaster.doc.com. と salesreplica.doc.com. を admin.sales.doc.com. グループに追加します。

smaster# nisgrpadm -a admin.sales.doc.com. smaster.doc.com. 
salesreplica.doc.com.
Added smaster.doc.com. to group admin.sales.doc.com.
Added salesreplica.doc.com. to group admin.sales.doc.com.

このサーバーが管理グループに属していることを確認するには、nisgrpadm コマンドを -l オプションで実行します。手順については、第 17 章「NIS+ グループの管理」を参照してください。

smaster# nisgrpadm -l admin.sales.doc.com.
 Group entry for admin.sales.doc.com. group:
 Explicit members:
 smaster.doc.com.
 salesreplica.doc.com.
 No implicit members
 No recursive members
 No explicit nonmembers
 No implicit nonmembers
 No recursive nonmembers

ほかの管理者の資格を追加します。

そのドメインで仕事をするほかの管理者の資格を追加します。

すでにもう 1 つのドメインで DES 資格をもつ管理者の場合、単に LOCAL 資格を追加します。このとき、-p フラグと -P フラグ付きの nisaddcred コマンドを実行します。たとえば、次のようになります。

smaster# nisaddcred -p 33355 -P nisboss.doc.com. local

まだ資格をもたない管理者の場合、2 つの方法があります。

管理者に対して、自分の資格を追加するよう要求するのが 1 つの方法です。この方法は、スーパーユーザーとして実行する必要があります。ユーザー ID が 22244 で、主体名が juan.sales.doc.com. の管理者が、sales.doc.com. ドメインに自分の資格を追加する例を次に示します。

smaster# nisaddcred -p 22244 -P juan.sales.doc.com. local
smaster# nisaddcred -p unix.22244@sales.doc.com -P \
juan.sales.doc.com. des
Adding key pair for unix.22244@sales.doc.com.
Enter login password:

もう 1 つの方法では、ダミーパスワードを使用して、ほかの管理者用の一時的な資格を作成します。各管理者には NIS+ passwd テーブル内にエントリが必要です。

smaster# nisaddcred -p 22244 -P juan.sales.doc.com. local
smaster# nisaddcred -p unix.22244@sales.doc.com -P \ 
juan.sales.doc.com. des
Adding key pair for unix.22244@sales.doc.com.
Enter juan's login password:
nisaddcred: WARNING: password differs from login passwd.
Retype password:

各管理者は、後で chkey コマンドを実行して、自分のネットワークパスワードを変更できます。パスワードの変更方法については、第 12 章「NIS+ 資格の管理」と第 13 章「NIS+ 鍵の管理」を参照してください。

注 –

上記の手順 8 の 2 つの例で、小文字の -p フラグに続くドメイン名の終わりにドットを付けないでください。また、大文字の -P フラグに続くドメイン名の終わりにはドットを必ず付けてください。

ドメインの管理グループに管理者を追加します。

この手順を実行するには、ほかのシステム管理者がダミーパスワードを変更するまで待つ必要はありません。-a オプションを付けて nisgrpadm コマンドを実行します。最初の引数はグループ名、残りの引数は管理者名です。この例では、管理者 juan を admin.sales.doc.com. グループに追加します。
smaster# nisgrpadm -a admin.sales.doc.com. juan.sales.doc.com. Added juan.sales.doc.com. to group admin.sales.doc.com.

NIS+ テーブルを格納するための、十分なスワップ空間を割り当てます。

スワップ空間は、rpc.nisd の最大サイズの 2 倍にする必要があります。rpc.nisd が使用するメモリー量を調べるには、次のコマンドを実行してください。
rootmaster# /usr/lib/nis/nisstat
rpc.nisd は、特定の条件のもとでは、自らのコピーを作成してフォークします。メモリーが不足すると、rpc.nisd は正しく動作しません。

また、NIS+ テーブルに必要なメモリーとスワップ空間のサイズも計算できます。たとえば、NIS+ テーブル内に、180,000 人のユーザーと 180,000 台のホストがある場合、これらの 2 つのテーブルが占有するメモリーは、約 190M バイトです。180,000 人のユーザーと 180,000 台のホストに資格を追加する場合、cred テーブルには、540,000 のエントリ (ユーザーごとにローカルの資格と DES の資格、合わせて 2 つの資格、ホストごとに 1 つの資格) が入ります。そのため、cred テーブルが占有するメモリーは、約 285M バイトになります。この例では、rpc.nisd に必要なメモリー容量は、少なくとも、190M バイト + 285M バイト = 475M バイトになります。この結果、少なくとも 1G バイトのスワップ空間が必要になります。また、rpc.nisd 全体をすべてメモリー内に保持するには、少なくとも 500M バイトが必要です。