test

Solaris ネーミングの設定と構成

非ルートドメインを設定する

注 -

非ルートドメインを設定する作業は、この章で説明する NIS+ コマンドセットを使用する方法よりも、パート I で説明した NIS+ 設定スクリプトを使用する場合の方が簡単です。この章で説明する方法は、NIS+ に精通した管理者や、設定スクリプトでは提供されない標準以外の機能や構成を必要とする管理者だけが使用してください。

最初に非ルートドメインのサーバーを構成してから、非ルートドメインを構成してください。

非ルートドメインを設定するには、次の作業を行います。

ルートドメインの構成と同様に、これらの作業は連続して実行できません。構成プロセスを簡単にするため、これらを個々の手順に分割して、最も効率的な順序に並べています。

標準構成と NIS 互換構成の手順の相違

サブドメインにおける NIS 互換の NIS+ サーバーと標準の NIS+ サーバーとの違いは、ルートドメインの場合と同じです (「標準構成と NIS 互換構成の手順の相違」参照)。

NIS 互換ドメインの各サーバーの NIS+ デーモンは、第 7 章「NIS+ サーバーの構成」の説明に従って、-Y オプションを使用して起動する必要があります。また、NIS 互換ドメインでは、ドメインのテーブルによって未認証クラスに読み取り権を提供する必要があります。これにより、NIS クライアントはテーブルに格納されている情報にアクセスできます。手順 4 で説明するとおり、nissetup コマンドに -Y オプションを追加すると、テーブル内の情報にアクセスできます。標準の NIS+ ドメインでも同じコマンドを使用しますが、-Y オプションは使用しません。これについても手順 4 で説明します。

構成プロセス全体のまとめは次のとおりです。

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

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

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

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

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

  6. ディレクトリオブジェクトに完全なグループアクセス権を設定します。

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

  8. 他の管理者の資格を追加します。

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

セキュリティ上の留意点

注 -

NIS+ のセキュリティシステムは複雑です。NIS+ のセキュリティに精通していない場合は、『Solaris ネーミングの管理』のセキュリティ関連の章を読んでから NIS+ 環境の構成を始めてください。

多くのサイトでは、親ドメインのセキュリティを確保するために、その下にドメインを作成できるのは、親ドメインのマスターサーバー、または親ドメインの管理グループに所属するシステム管理者に限定しています。これは、管理方針であり NIS+ の必要条件ではありませんが、この章の操作説明ではこの作業を行う管理者がこの方針に従っているものと仮定します。もちろん、親ドメインの管理グループには、親ディレクトリオブジェクトに対する作成権が必要です。これを確認するには、niscat -o コマンドを実行します。


rootmaster# niscat -o doc.com.
Object Name : Doc
Owner : rootmaster
Group : admin.doc.com.
Domain : Com.
Access Rights : r---rmcdrmcdr---
:

安全性よりも便宜性を重視する場合、新しいドメインのマスターサーバーをその親ドメインの管理グループのメンバーとし、そのサーバーからすべて手順を実行できます。この場合、『Solaris ネーミングの管理』のグループ関連の章で説明する nisgrpadm コマンドを使用します。

前提条件

必要な情報

非ルートドメインを設定する - タスクマップ

表 8-1 非ルートドメインを設定する
 

タスク 

 

説明 

 

指示の参照先 

 
 

非ルートドメインを設定する 

 

NIS+ コマンドを使って非ルートドメインを設定する 

 

「非ルートドメインを設定する方法」

 
       

非ルートドメインを設定する方法

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

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

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

    実際に管理グループを作成するのは、手順 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

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

    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 を実行する必要はありません。

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

    この手順では、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 コマンドを実行します 。ただしこの時点ではテーブルは空です。

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

    この手順では、手順 2 で指定した管理グループを作成します。nisgrpadm コマンドに -c オプションを付けて実行します。次の例では admin.sales.doc.com. グループを作成します。 


    smaster# nisgrpadm -c admin.sales.doc.com.
Group admin.sales.doc.com. created.

    この手順はグループを作成するだけであり、メンバーの指定は行いません。指定は 手順 9 で行います。

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

    デフォルトでは、ディレクトリオブジェクトはそのグループに読み取り権を与えるだけであり、これではその他のカテゴリと同様、グループも使うことができません。クライアントとサブドメインの構成を簡単にするため、ディレクトリオブジェクトがそのグループに与えるアクセス権を、読み取り権のみから読み取り権、変更権、作成権、削除権に変更します。次に示すように、nischmod コマンドを実行します。 


    smaster# nischmod g+rmcd sales.doc.com.

    nischmod コマンドの詳しい使用法は、『Solaris ネーミングの管理』のアクセス権に関連する章を参照してください。

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

    この時点で、このドメインのグループにはメンバーがありません。-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.

    サーバーが実際にグループのメンバーであることを確認するには、-l オプションを付けて nisgrpadm コマンドを実行します (『Solaris ネーミングの管理』のグループに関する章を参照)。 


    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

  8. 他の管理者の資格を追加します。

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

    すでにもう 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 コマンドを実行して、自分のネットワークパスワードを変更できます。ネットワークパスワードを変更する方法については、『Solaris ネーミングの管理』の資格および鍵に関する章を参照してください。

    注 -

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

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

    この手順は、他の管理者がダミーパスワードを変更していなくても実行できます。-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.

  10. 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 バイトが必要です。