test

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

ルートドメインを構成する方法

  1. ルートマスターサーバーとするマシン上にスーパーユーザーとしてログインします。

    次の例では、rootmaster をルートマスターサーバーとして、doc.com. をルートドメインとして、それぞれ使用します。

  2. ルートマスターサーバーのドメイン名をチェックします。

    domainname コマンドを使用して、ルートマスターサーバーが正しいドメイン名を使用していることを確認します。domainname コマンドは、ワークステーションの現在のドメイン名を返します。

    注意 - 注意 -

    ドメインとホストで同じ名前を使用しないでください。たとえば、sales というドメインを使用している場合、sales という名前の付いたマシンは使用しないでください。同様に、home という名前のマシンを使用する場合は、home という名前のドメインを作成しないでください。これは、サブドメインの場合にもあてはまります。たとえば、マシンに west という名前を付けている場合、sales.west.myco.com というサブディレクトリを作成しないでください。

    ドメイン名が正しくない場合は、変更してください。


    rootmaster# domainname
strange.domain
rootmaster# domainname doc.com
rootmaster# domainname
rootmaster# doc.com
rootmaster# rm -f /etc/defaultdomain
rootmaster# domainname > /etc/defaultdomain

    domainname コマンドの最後にドットを付けないでください。domainname コマンドは、NIS+ コマンドではありません。そのため、domainname コマンドは、ドメイン名の最後にドットを付ける NIS+ の表記規則には従っていません。

    上記の例では、ルートマスターサーバーのドメイン名を strange.domain から doc.com に変更しています。ドメイン名を変更したり設定したりする場合は、doc ではなく doc.com のように、少なくとも 2 つのラベルを付けてください。末尾の要素はインターネットの組織コード (.com など) または地域識別子 (.jp、.uk など) にしてください。

  3. ルートマスターサーバーのスイッチ構成ファイルをチェックします。

    ルートマスターサーバーが、NIS 互換モードで動作する場合であっても、NIS+ 用の nsswitch.conf ファイルを使用していることを確認してください。この手順で、ルートマスター用の情報の主情報源が確実に NIS+ テーブルとなります。 


    rootmaster# more /etc/nsswitch.conf

    上のコマンドを実行すると、現在の nsswitch.conf ファイルの内容が表示されます。このファイルによって参照される主ネームサービスは nisplus です。ルートマスターサーバーの構成ファイルが主ネームサービスとして nisplus を使用していない場合は、「構成ファイルの変更」を参照して、nisplus を使用する構成ファイルに置き換えてください。

  4. オプションで Diffie-Hellman キー長を設定します。

    DES 認証を使用する場合には、Diffie-Hellman キー長をデフォルトの 192 ビットより長くすることができます。たとえば、640 ビットと 192 ビットの両方を許可する場合には、以下を入力します。


    rootmaster# nisauthconf dh640-0 des

  5. nsswitch.conf ファイルに対する変更が終了したら、nscd デーモンを終了して再起動します。

    nscd が nsswitch.conf ファイルの内容をキャッシュに格納しているため、ファイルの内容を変更したあとは、nscd を終了して再起動する必要があります。

    詳しい手順は、第 1 章「ネームサービススイッチの設定」を参照してください。

  6. 次のように入力し、keyserv を強制終了して再起動します。 


    rootmaster# cp /etc/nsswitch.nisplus /etc/nsswitch.conf
rootmaster# sh /etc/init.d/nscd stop
rootmaster# sh /etc/init.d/nscd start
rootmaster# ps -e | grep keyserv
 root 145 1 67 16:34:44 ? keyserv
 .
 .
rootmaster# kill -9 145
rootmaster# rm -f /etc/.rootkey
rootmaster# keyserv

  7. NIS+ のファイルを削除しプロセスを終了します。

    現在作業しているワークステーションが、以前は NIS+ のサーバーまたはクライアントとして使用したものである場合、/var/nis 内にファイルがあればすべて削除し、キャッシュマネージャがまだ実行中であれば、そのプロセスを終了します。この例では、/var/nis 内にはコールドスタートファイルとディレクトリキャッシュファイルがまだ存在します。 


    rootmaster# ls /var/nis
NIS_COLD_START NIS_SHARED_CACHE
rootmaster# rm -rf /var/nis/*
rootmaster# ps -ef | grep nis_cachemgr
 root 295 260 10 15:26:58 pts/0 0:00 grep nis_cachemgr
 root 286 1 57 15:21:55 ? 0:01 /usr/sbin/nis_cachemgr
rootmaster# kill -9 286

    この手順によって、/var/nis 内に残されたファイル、またはキャッシュマネージャによって格納されたディレクトリオブジェクトは完全に消去されるため、これらがこの設定作業で生成される新しい情報と重複することはありません。/var/nis 内に管理スクリプトを格納していた場合、ルートドメインの設定が終わるまでは、これらを一時的に他のどこかに格納しておくことができます。

  8. サーバーのデーモンを終了します。

    現在作業しているワークステーションが、すでに NIS+ サーバーとして使用されている場合は、rpc.nisd または rpc.nispasswdd が実行されているかどうか確認してください。実行されている場合は、どちらのデーモンも終了してください。

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

    手順 16 までは、実際には管理グループを作成しませんが、ここで管理グループの名前を指定する必要があります。手順 13 で管理グループの名前を指定することによって、ルートドメインの org_dir ディレクトリオブジェクト、groups_dir ディレクトリオブジェクト、およびその全テーブルオブジェクトが 手順 14 で作成されたときに、適切なデフォルトグループが割り当てられます。

    管理グループを指定するには、環境変数 NIS_GROUP の値に、ルートドメインの管理グループの名前を設定します。次に、csh ユーザー用と、sh/ksh ユーザー用の 2 つの例を示します。どちらも、NIS_GROUP を admin.doc.com. に設定します。

    C シェルの場合


    rootmaster# setenv NIS_GROUP admin.doc.com.

    Bourne シェルまたは Korn シェルの場合


    rootmaster# NIS_GROUP=admin.doc.com.
rootmaster# export NIS_GROUP

  10. ルートディレクトリを作成し、ルートマスターサーバーを初期設定します。

    この手順では、名前空間内の最初のオブジェクトであるルートディレクトリを作成し、ワークステーションをルートマスターサーバーに変換します。次に示すように、nisinit -r コマンドを使用します。この場合に限り、ドメインのディレクトリオブジェクトの作成と、そのマスターサーバーの初期設定が 1 回の操作で行われます。実際には nisinit -r が nismkdir を実行し、自動的にルートディレクトリを作成します。いずれにせよ、ルートマスターの場合を除くと、これらの 2 つのプロセスは別々の作業として行われます。 


    rootmaster# nisinit -r
This machine is in the doc.com. NIS+ domain
Setting up root server ...
All done.

    /var/nis/data という名前の UNIX ディレクトリが生成されます。

    この下には root.object. という名前のファイルがあります。 


    rootmaster# ls -l /var/nis/data
-rw-rw-rw- 1 root other 384 date root.object

    これはルートディレクトリオブジェクトではありません。実際には、NIS+ が内部目的のために名前空間の root を記述するために使用するファイルです。NIS+ のルートディレクトリオブジェクトは、手順 11 または 手順 12 で作成します。

    以降の手順では、この手順で作成されるディレクトリの下に、他のファイルが追加されます。UNIX ディレクトリを直接調べることによって、これらのファイルの存在を検証できますが、NIS+ にはもっと便利なコマンドがあります。以下の手順では、必要に応じてこれらのコマンドを実行します。

    注意 - 注意 -

    nisinit など NIS+ の構成手順によって作成された /var/nis、/var/nis/data といったディレクトリ、およびその下のファイルは、名前を変更しないでください。Solaris リリース 2.4 以前では、/var/nis ディレクトリに hostname.dict、hostname.log という 2 つのファイルとサブディレクトリ /var/nis/hostname が存在していました。Solaris リリース 2.5 では、これらの 2 つのファイル名は trans.log、data.dict とし、サブディレクトリ名は /var/nis/data となります。Solaris リリース 2.5 ではこれらのファイルの内容も変更されており、Solaris リリース 2.4 以前との互換性はなくなっています。したがって、これらのファイルやディレクトリを Solaris リリース 2.4 での名前にしてしまうと、Solaris リリース 2.4、2.5 双方の rpc.nisd で機能しなくなるので名前の変更をしないようにしてください。

  11. NIS+ デーモンを -Y で起動します (NIS 互換の場合のみ)。

    この手順は、NIS 互換モードでルートドメインを設定している場合にだけ実行します。標準の NIS+ ドメインを設定する場合は、この代わりに 手順 12 を実行します。この手順には、NIS クライアントの DNS 転送機能をサポートするための操作手順が含まれます。

    「a」では、NIS+ デーモンを NIS 互換モードで起動します。「b」では、NIS+ デーモンはこのサーバーが再起動されたとき、確実に NIS 互換モードで再起動します。「b」の後は、手順 14 に進んでください。

    1. rpc.nisd に -Y、-B、-S 0 オプションを使用して実行します。


      rootmaster# rpc.nisd -Y -B -S 0 options

      -Y オプションを指定すると、NIS+ 要求だけでなく NIS 要求にも応答します。-B オプションを指定すると DNS 転送をサポートします。-S 0 フラグは、サーバーのセキュリティレベルに 0 を設定します。この時点では、ブートストラップ動作のためにこの設定が必要です。cred テーブルはまだ存在しないため、NIS+ 主体は資格をもつことができません。これより高いセキュリティレベルを使用した場合、ユーザーがサーバーから締め出されてしまいます。

    2. /etc/init.d/rpc ファイルを編集します。

      /etc/init.d/rpc ファイル内で文字列 EMULYP="Y" を検索します。その行のコメント指定を解除し、DNS 転送機能を使用できるようにするために、-B フラグを追加します。

      DNS 転送を使用する rpc ファイルの場合


      EMULYP="-Y -B"

      DNS 転送を使用しない rpc ファイルの場合


      EMULYP="-Y"

      DNS 転送機能を使用する必要がない場合、この行をコメント解除しますが、-B フラグは追加しません。

  12. NIS+ デーモンを起動します (標準 NIS+ の場合のみ)。

    rpc.nisd コマンドを使用しますが、必ず -S 0 フラグを追加してください。 


    rootmaster# rpc.nisd -S 0

    -S 0 フラグは、サーバーのセキュリティレベルに 0 を設定します。この時点では、ブートストラップ動作のためにこの設定が必要です。cred テーブルはまだ存在しないため、NIS+ 主体は資格をもつことができません。これより高いセキュリティレベルを使用した場合、ユーザーがサーバーから締め出されてしまいます。

  13. ルートオブジェクトが正しく作成されているかどうか確認します。

    手順 11 または 手順 12 を実行すると、名前空間には次のものが作成されます。

    • ルートディレクトリオブジェクト (root.dir)

    • NIS+ デーモン (rootmaster) を実行するルートマスターサーバー (rpc.nisd)

    • マスターサーバー用のコールドスタートファイル (NIS_COLD_START)

    • トランザクションログファイル (trans.log)

    • テーブル辞書ファイル (data.dict)

    ルートディレクトリオブジェクトは、手順 10 で作成したディレクトリに格納されます。ls コマンドを使用して、ディレクトリの内容を確認してください。


    rootmaster# ls -l /var/nis/data 
-rw-rw-rw- 1 root other 384 date root.object
-rw-rw-rw- 1 root other 124 date root.dir

    この時点で、ルートディレクトリは空です。つまり、サブディレクトリはありません。このことを確認するには、nisls コマンドを使用します。


    rootmaster# nisls -l doc.com.
doc.com.:

    ただし、いくつかの「オブジェクト」属性は存在し、niscat -o を使用すればこれを調べることができます。


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

    なお、ルートディレクトリオブジェクトは、「所有者」と「グループ」の両方には完全な (読み取り、変更、作成、削除) 権利を与え、「その他」と「未認証」には読み取り権だけを与えます。ディレクトリオブジェクトがこれらの権利を提供しない場合、nischmod コマンドを使用して変更できます。

    NIS+ デーモンが動作していることを確認するには、ps コマンドを使用します。


    rootmaster# ps -ef | grep rpc.nisd
root 1081 1 61 16:43:33 ? 0:01 rpc.nisd -S 0
root 1087 1004 11 16:44:09 pts/1 0:00 grep rpc.nisd

    ルートマスターサーバーのインターネットアドレスが (最終的には公開鍵も) 収められているルートドメインの NIS_COLD_START ファイルは、/var/nis 内に置かれます。この内容を調べるための NIS+ コマンドはありませんが、この内容はサーバーのディレクトリキャッシュ (NIS_SHARED_DIRCACHE) に保存されます。これらの内容は、/usr/lib/nis/nisshowcache コマンドで調べることができます。

    また、トランザクションログファイル (trans.log) と辞書ファイル (data.dict) も作成されます。マスターサーバーのトランザクションログは、前回の更新以降マスターサーバーとそのすべての複製サーバーによって実行されたすべてのトランザクションを格納しています。この内容を調べるには、nislog コマンドを使用します。辞書ファイルは、NIS+ が内部目的に使用するものであり、システム管理者には関係ありません。

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

    この手順では、ルートディレクトリオブジェクトの下に、org_dir ディレクトリと groups_dir ディレクトリ、および NIS+ テーブルを追加します。nissetup ユーティリティを使用してください。NIS 互換ドメインの場合、必ず -Y フラグを付けてください。両方の場合の例を次に示します。

    標準 NIS+ のみの場合


    rootmaster# /usr/lib/nis/nissetup

    NIS 互換のみの場合


    rootmaster# /usr/lib/nis/nissetup -Y

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


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

    -Y オプションは、標準の NIS+ ドメインと同じテーブルとサブディレクトリを作成します。しかし、NIS クライアントからの未認証要求が passwd テーブルに含まれる暗号化されたパスワードにアクセスできるようにするため、passwd テーブルへの読み取り権を未認証クラスに割り当てます。

    nisls でルートディレクトリの内容を調べたとき (手順 12)、これが空であったことを思い出してください。現在は 2 つのサブディレクトリがあります。


    rootmaster# nisls doc.com.
doc.com.:
org_dir
groups_dir

    サブディレクトリとテーブルのオブジェクト属性を調べるには、niscat -o コマンドを使用してください。また、フラグなしで niscat オプションを使用して、このテーブル内の情報を調べることもできますが、この時点では空です。

  15. ルートマスターサーバーの DES 資格を作成します。

    ルートマスターサーバーは、自分の要求が認証されるために、DES 資格を必要とします。これらの資格を作成するには、次に示すように nisaddcred コマンドを使用します。プロンプトに対して、サーバーの root パスワードを入力します。 


    rootmaster# nisaddcred des 
DES principal name: unix.rootmaster@doc.com
Adding key pair for unix.rootmaster@doc.com
 (rootmaster.doc.com.).
Enter login password:
Wrote secret key into /etc/.rootkey

    サーバーの root パスワードと異なるパスワードを入力した場合、警告メッセージとパスワードを再入力するプロンプトが表示されます。 


    Enter login password:
nisaddcred: WARNING: password differs from login password.
Retype password:

    それでも同じパスワードを再び入力すると、NIS+ は資格を作成します。この新しいパスワードは /etc/.rootkey に格納され、キーサーバーが起動時に使用します。キーサーバーに新しいパスワードをすぐに与えるには、keylogin -r を実行します (『Solaris ネーミングの管理』の、資格に関連のある章を参照)。

    最終的に自分のログインパスワードを使用する場合は、Control-C を押して、この手順をやり直します。Control-C を押さずにメッセージに従って自分のログインパスワードを入力すると、別の目的のエラーメッセージが表示され、混乱を招くことがあります。


    nisaddcred: WARNING: password differs from login password.
Retype password:
nisaddcred: password incorrect.
nisaddcred: unable to create credential.

    この手順の結果として、ルートサーバーの非公開鍵と公開鍵がルートドメインの cred テーブル (cred.org_dir.doc.com.) に格納され、その非公開鍵は /etc/.rootkey. に格納されます。cred テーブル内の資格を確認するには、niscat コマンドを使用します (第 8 章を参照)。デフォルトのドメイン名は doc.com. であるため、cred テーブルの完全指定名を入力する必要はありません。接尾辞の org_dir で十分です。ルートマスターの資格を探すためには、その Secure RPC ネット名を探してください。

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

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


    rootmaster# nisgrpadm -c admin.doc.com.
 Group admin.doc.com. created.

    この手順ではグループを作成するだけであり、そのメンバー名の指定は行いません。これについては、手順 17 で行います。グループのオブジェクト属性を見るには、niscat -o を使用します。しかし、グループ名では必ず groups_dir を使用します。たとえば、次のようになります。


    doc.com.
Object Name : admin
Directory : groups_dir.doc.com
Owner : rootmaster.doc.com.
Group : admin.doc.com.
Domain : groups_dir.doc.com.
Access Rights : ----rmcdr---r---
Time to Live : 1:0:0
Object Type : GROUP
Group Flags :
Group Members :

  17. ルートドメインの管理 (admin) グループにルートマスターを追加します。

    この時点では、このルートマスターサーバーは DES 資格をもつ唯一の NIS+ 主体であるため、管理グループに追加すべき唯一のメンバーです。今度は、nisgrpadm コマンドに -a オプションを付けて実行します。第 1 引数はグループ名、第 2 引数はルートマスターサーバー名です。この例では admin.doc.com グループに rootmaster.doc.com. を追加します。 


    rootmaster# nisgrpadm -a admin.doc.com.
rootmaster.doc.com.
Added rootmaster.doc.com. to group admin.doc.com.

    ルートマスターが本当にグループのメンバーであることを確認するには、-l オプションを指定して nisgrpadm コマンドを使用します (『Solaris ネーミングの管理』のグループ関連の章を参照)。

    注 -

    nisgrpadm などのグループ関連コマンドでは、名前に groups_dir サブディレトリを含める必要はありません。niscat などのコマンドの場合、NIS+ オブジェクト一般に対して動作するように設計されているため、このディレクトリを含む必要があります。グループ関連コマンドは、groups_dir サブディレクトリを対象としています。


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

  18. ルートドメインの公開鍵を更新します。

    ディレクトリオブジェクトは、すでに DES 資格をもつ NIS+ 主体によって作成されるのが普通です。しかしこの場合、cred テーブルを作成するまでは、自分の資格を格納する親ドメインがないため、ルートマスターサーバーは DES 資格を獲得できません。その結果、root、org_dir、および groups_dir という 3 つのディレクトリオブジェクトには、ルートマスターサーバーの公開鍵のコピーがありません。これについては、niscat -o コマンドにどれかのディレクトリオブジェクトを指定して実行することによって確認できます。「Public Key:」フィールドを探してください。詳細は、『Solaris ネーミングの管理』のディレクトリ関連の章を参照してください。

    ルートマスターサーバーの公開鍵を、ルートドメインの cred テーブルからこれら 3 つのディレクトリオブジェクトに伝達するには、次に示すように、各ディレクトリオブジェクトに対して /usr/lib/nis/nisupdkeys ユーティリティを使用します。 


    rootmaster# /usr/lib/nis/nisupdkeys doc.com.
rootmaster# /usr/lib/nis/nisupdkeys org_dir.doc.com.
rootmaster# /usr/lib/nis/nisupdkeys groups_dir.doc.com.

    コマンドを実行するたびに、次のような確認メッセージが表示されます。


    Fetch Public key for server rootmaster.doc.com.
 netname = 'unix.rootmaster@doc.com.'
Updating rootmaster.doc.com.'s public key.
 Public key:

    これらのディレクトリを (niscat -o を使用して) 表示すると、「Public key:」フィールドに 1 つまたは複数のエントリが見つかります。 


    Public key: Diffie-Hellman (192 bits)

  19. NIS+ キャッシュマネージャを起動します。

    キャッシュマネージャは、NIS+ クライアント (この場合、ルートマスターサーバー) に関する位置情報のローカルキャッシュを管理します。初期の情報をクライアントのコールドスタートファイル (手順 11 または 手順 12 で作成) から入手し、これを /var/nis 内の NIS_SHARED_DIRCACHE という名前のファイルに保存します。

    キャッシュマネージャを起動するには、次に示すように、nis_cachemgr コマンドを入力します。 


    rootmaster# nis_cachemgr

    キャッシュマネージャがいったん起動されたら、このプロセスを明示的に終了させた場合を除いて、再起動する必要はありません。クライアントが再起動されたときには、/var/nis 内の COLD_STARTファイルがキャッシュマネージャを自動的に起動するため、キャッシュマネージャを再起動する必要はありません。NIS+ キャッシュマネージャの詳細は、『Solaris ネーミングの管理』のディレクトリに関連する章を参照してください。

  20. NIS+ デーモンをセキュリティレベル 2 で再起動します。

    これで、ルートマスターサーバーには DES 資格があり、ルートディレクトリオブジェクトにはルートマスターの公開鍵のコピーがあるため、ルートマスターをセキュリティレベル 2 で再起動できます。まず既存のデーモンのプロセスを終了し、次にこれをセキュリティレベル 2 で再起動します。

    標準 NIS+ ドメインの場合


    rootmaster# ps -e | grep rpc.nisd
1081 ? 0:03 rpc.nisd -s 0
rootmaster# kill 1081
rootmaster# rpc.nisd

    NIS 互換のルートドメインの場合、必ず -Y フラグ (および -B フラグ) を使用してください。

    NIS 互換の NIS+ ドメインの場合


    rootmaster# ps -e | grep rpc.nisd
1081 ? 0:03 rpc.nisd -Y -B -s 0
rootmaster# kill 1081
rootmaster# rpc.nisd -Y -B

    セキュリティレベル 2 はデフォルトであるため、-S 2 フラグは不要です。

    注 -

    実際にユーザーが存在するネットワークは、常にセキュリティレベル 2 で運用してください。セキュリティレベル 0 およびレベル 1 は、設定およびテストの目的だけに使用します。

  21. 自分の LOCAL 資格をルートドメインに追加します。

    ユーザーはルートドメインの cred テーブルに対するアクセス権がないため、この動作はスーパーユーザーとして実行しなければなりません。さらに、「前提条件」で説明したように、ルートマスターの /etc/passwd ファイルには自分用のエントリが必要です。nisaddcred コマンドに -p と -P フラグを付けて使用します。その構文と例を次に示します。 


    nisaddcred -p uid -P  principal-name local

    principal-name はシステム管理者のログイン名とドメイン名で構成されます。この例では、UID が 11177 で NIS+ 主体名が topadmin.doc.com.のシステム管理者用の LOCAL 資格を追加します。


    rootmaster# nisaddcred -p 11177 -P topadmin.doc.com. local

    nisaddcred コマンドの詳細は、『Solaris ネーミングの管理』の資格に関する章を参照してください。

  22. 自分の DES 資格をルートドメインに追加します。

    ここでも nisaddcred コマンドを使用しますが、次のような構文となります。 


    nisaddcred -p secure-RPC-netname- P principal-name des

    secure-RPC-netname は、接頭辞 unix に自分のユーザー ID、@ 記号、およびドメイン名を付けて構成しますが、最後にドットは付けません。principal-name は LOCAL 資格の場合と同じで、ログイン名にドメイン名を付け、さらに最後にドットを付けます。 


    rootmaster# nisaddcred -p unix.11177@doc.com -P topadmin.doc.com. des
Adding key pair for unix.11177@doc.com (topadmin.doc.com.).
Enter login password:

    ログインパスワードの入力後に「password that differs from the login password」という警告が表示され、入力したパスワードが正しいログインパスワードである場合は、このエラーメッセージを無視してください。NIS+ がパスワードの格納されている、保護された /etc/shadow ファイルを期待どおりに読み込めないため、このメッセージが表示されます。ユーザーパスワード情報を /etc/passwd ファイルに格納していない場合、このメッセージは表示されません。

  23. 他のシステム管理者の資格を追加します。

    そのルートドメインで作業する他のシステム管理者の LOCAL 資格と DES 資格を追加します。これには 以下の方法があります。

    • 他の管理者に一時的な資格を作成するには、NIS+ モードで実行されている Solstice AdminSuite (使用できる場合) を使用すると簡単です。

    • 2 つ目は、他の管理者にその管理者自身の資格を追加するよう要求する方法です。この方法は、スーパーユーザーとして実行する必要があります。ユーザー ID が 33355 で主体名が miyoko.doc.com. のシステム管理者の資格を追加する例を次に示します。 


      rootmaster# nisaddcred -p 33355 -P miyoko.doc.com. local 
rootmaster# nisaddcred -p unix.33355@doc.com -P miyoko.doc.com. des 
Adding key pair for unix.33355@doc.com (miyoko.doc.com.).
 Enter login password:

    • 3 つ目は、ダミーのパスワードを使用して、他の管理者に一時的な資格を作成する方法です。他の管理者、この例では miyoko は、NIS+ passwd テーブルにエントリがなければなりません。エントリがない場合は、まず nistbladm を使用して、必ずエントリを作成してください。次の例で、その手順を示しています。 


      rootmaster# nistbladm -D owner=miyoko.doc.com. name=miyoko uid=33355 gcos=miyoko 
home=/home/miyoko shell=/bin/tcsh passwd.org_dir
rootmaster# nisaddent -a -f /etc/passwd.xfr passwd 
rootmaster# nisaddent -a -f /etc/shadow.xfr shadow
rootmaster# nisaddcred -p 33355 -P miyoko.doc.com. local
rootmaster# nisaddcred -p unix.33355@doc.com -P miyoko.doc.com. des
Adding key pair for unix.33355@doc.com (miyoko.doc.com.).
Enter miyoko's login password:
nisaddcred: WARNING: password differs from login passwd.
Retype password:
rootmaster# nischown miyoko.doc.com. '[name=miyoko],passwd.org_dir'

      この場合、最初の nisaddent で passwd テーブルにエントリが生成されます (shadow 列は除く)。次の nisaddent により、shadow 列が生成されます。各システム管理者は、chkey コマンドを使用することによって、自分のネットワークパスワードを後で変更できます。詳しくは、『Solaris ネーミングの管理』の資格に関連する章を参照してください。

  24. ルートドメインの管理グループに自分と他のシステム管理者を追加します。

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


    rootmaster# nisgrpadm -a admin.doc.com. topadmin.doc.com. miyoko.doc.com.
Added topadmin.doc.com. to group admin.doc.com.
Added miyoko.doc.com. to group admin.doc.com.

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