各手順では詳細を説明し、また、関連する情報についても説明します。詳細な説明が必要ない場合は、ルートドメイン構成の要覧に必要なコマンドをまとめたリストがありますので参照してください。
設定作業の手順を次にまとめます。
ルートマスターサーバーにスーパーユーザーとしてログインします。
ルートマスターサーバーのドメイン名をチェックします。
ルートマスターサーバーのスイッチ構成ファイルをチェックします。
オプションで Diffie-Hellman キー長を設定します。
NIS+ のファイルを削除しプロセスを終了します。
ルートドメインの管理グループを指定します。
ルートディレクトリを作成し、ルートマスターサーバーを初期設定します。
NIS+ デーモンを -Y で起動します (NIS の互換場合)。NIS+ デーモンを起動します (NIS+ の場合)。
NIS+ デーモンが実行されていることを確認します。
ルートドメインのサブディレクトリとテーブルを作成します。
ルートマスターサーバーの DES 資格を作成します。
ルートドメインの管理グループを作成します。
ルートドメインの管理 (admin) グループにルートマスターを追加します。
ルートドメインの公開鍵を更新します。
NIS+ キャッシュマネージャを起動します。
NIS+ デーモンをセキュリティレベル 2 で再起動します。
自分の LOCAL 資格をルートドメインに追加します。
自分の DES 資格をルートドメインに追加します。
他のシステム管理者の資格を追加します。
ルートドメインの管理グループに自分と他のシステム管理者を追加します。
作業 |
説明 |
参照先 |
|
---|---|---|---|
ルートドメインを確立する |
domainname コマンドを使用して、ルートドメインを設定する。オプションで Diffie-Hellman キー長を長くする。ncsd デーモンの停止と起動を行う。keyserv デーモンの終了と再起動を行う。不要な NIS+ 情報を消去する |
NIS+ はルートドメインに対しデフォルトのセキュリティを提供します。デフォルトのセキュリティレベルは、レベル 2 です。実際にユーザーが存在するネットワークは、常にセキュリティレベル 2 で運用してください。セキュリティレベル 0 およびレベル 1 は、構成およびテストの目的だけに使用します。本番環境のネットワークは、レベル 0 または 1 で稼動しないでください。
NIS+ のセキュリティシステムは複雑です。NIS+ セキュリティを使い慣れていない場合は、第 11 章「NIS+ のセキュリティの概要」を参照してから NIS+ 環境を構成することをお勧めします。
作業を開始する前に、以下のことを確認します。
ルートマスターサーバー上の /etc/passwd ファイルには、この構成作業でルートドメインに資格を追加するシステム管理者である自分と、他のすべてのシステム管理者のエントリが含まれなければなりません。
サーバーが NIS 互換モードで動作し、Solaris 1.x のクライアントで DNS 転送を使用する場合は、/etc/resolv.conf ファイルを正しく構成しておく必要があります。
サーバーには、必ず他のユーザー ID と異なる、固有のマシン名を付けてください。
サーバーに付けるマシン名には、ドットを使用しないでください。たとえば、マシン名に sales.alpha を使用できない。sales-alpha というマシン名は、使用できます。
ルートドメインを作成するには、次の内容について調べておく必要があります。
ルートマスターサーバーとなるマシンのスーパーユーザーパスワード
ルートドメイン名
ルートドメインの管理グループ名
自分のユーザー ID とパスワード
ルートドメインに資格を追加する予定の他のシステム管理者のユーザー ID
ルートマスターサーバーとするマシン上にスーパーユーザーとしてログインします。
次の例では、rootmaster をルートマスターサーバーとして、doc.com. をルートドメインとして、それぞれ使用します。
ルートマスターサーバーのドメイン名をチェックします。
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 など) にしてください。
ルートマスターサーバーのスイッチ構成ファイルをチェックします。
ルートマスターサーバーが、NIS 互換モードで動作する場合であっても、NIS+ 用の nsswitch.conf ファイルを使用していることを確認してください。この手順で、ルートマスター用の情報の主情報源が確実に NIS+ テーブルとなります。
rootmaster# more /etc/nsswitch.conf |
上のコマンドを実行すると、現在の nsswitch.conf ファイルの内容が表示されます。このファイルによって参照される主ネームサービスは nisplus です。ルートマスターサーバーの構成ファイルが主ネームサービスとして nisplus を使用していない場合は、構成ファイルの変更を参照して、nisplus を使用する構成ファイルに置き換えてください。
オプションで Diffie-Hellman キー長を設定します。
DES 認証を使用する場合には、Diffie-Hellman キー長をデフォルトの 192 ビットより長くすることができます。たとえば、640 ビットと 192 ビットの両方を許可する場合には、以下を入力します。
rootmaster# nisauthconf dh640-0 des |
nsswitch.conf ファイルに対する変更が終了したら、nscd デーモンを終了して再起動します。
nscd が nsswitch.conf ファイルの内容をキャッシュに格納しているため、ファイルの内容を変更したあとは、nscd を終了して再起動する必要があります。
詳細な手順については、第 1 章「ネームサービススイッチ」を参照してください。
次のように入力し、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 |
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 内に管理スクリプトを格納していた場合、ルートドメインの設定が終わるまでは、これらを一時的に他のどこかに格納しておくことができます。
サーバーのデーモンを終了します。
現在作業しているマシンが、すでに NIS+ サーバーとして使用されていた場合は、rpc.nisd または rpc.nispasswdd が実行されているかどうか確認してください。実行されている場合は、どちらのデーモンも終了してください。
ルートドメインの管理グループを指定します。
手順 16 までは、実際には管理グループを作成しませんが、ここで管理グループの名前を指定する必要があります。ここで管理グループの名前を指定することによって、ルートドメインの 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 |
ルートディレクトリを作成し、ルートマスターサーバーを初期設定します。
この手順では、名前空間内の最初のオブジェクトであるルートディレクトリを作成し、マシンをルートマスターサーバーに変換します。次に示すように、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 が存在していました。またサブディレクトリ /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 で機能しなくなるので名前の変更をしないようにしてください。ディレクトリ名もファイル名も変更しないでください。
NIS+ デーモンを -Y で起動します (NIS 互換の場合のみ)。
この手順は、NIS 互換モードでルートドメインを設定している場合にだけ実行します。標準の NIS+ ドメインを設定する場合は、この代わりに 手順 12 を実行します。この手順には、NIS クライアントの DNS 転送機能をサポートするための操作手順が含まれます。
「a」では、NIS+ デーモンを NIS 互換モードで起動します。「b」では、NIS+ デーモンはこのサーバーが再起動されたとき、確実に NIS 互換モードで再起動します。手順 b の「b」の後は、手順 14 に進んでください。
rpc.nisd に -Y、-B、-S 0 オプションを使用して実行します。
rootmaster# rpc.nisd -Y -B -S 0 options |
-Y オプションを指定すると、NIS+ 要求だけでなく NIS 要求にも応答します。-B オプションを指定すると DNS 転送をサポートします。-S 0 フラグは、サーバーのセキュリティレベルに 0 を設定します。この時点では、ブートストラップ動作のためにこの設定が必要です。cred テーブルはまだ存在しないため、NIS+ 主体は資格をもつことができません。これより高いセキュリティレベルを使用した場合、ユーザーがサーバーから締め出されてしまいます。
/etc/init.d/rpc ファイルを編集します。
/etc/init.d/rpc ファイル内で文字列 EMULYP=”Y” を検索します。その行のコメント指定を解除し、DNS 転送機能を使用できるようにするために、-B フラグを追加します。
DNS 転送を使用する rpc ファイルの場合
EMULYP=”-Y -B” |
DNS 転送を使用しない rpc ファイルの場合
EMULYP=”-Y” |
DNS 転送機能を使用する必要がない場合、この行をコメント解除しますが、-B フラグは追加しません。
NIS+ デーモンを起動します (標準 NIS+ の場合のみ)。
rpc.nisd コマンドを使用しますが、必ず -S 0 フラグを追加してください。
rootmaster# rpc.nisd -S 0 |
-S 0 フラグは、サーバーのセキュリティレベルに 0 を設定します。この時点では、ブートストラップ動作のためにこの設定が必要です。cred テーブルはまだ存在しないため、NIS+ 主体は資格をもつことができません。これより高いセキュリティレベルを使用した場合、ユーザーがサーバーから締め出されてしまいます。
ルートオブジェクトが正しく作成されているかどうか確認します。
手順 11 または 手順 12 を実行すると、名前空間には次のものが作成されます。
ルートディレクトリオブジェクト (root.dir)
NIS+ デーモン (rootmaster) を実行するルートマスターサーバー (rpc.nisd)
トランザクションログファイル (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+ が内部目的に使用するものであり、システム管理者には関係ありません。
ルートドメインのサブディレクトリとテーブルを作成します。
この手順では、ルートディレクトリオブジェクトの下に、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 オプションを使用して、このテーブル内の情報を調べることもできますが、この時点では空です。
ルートマスターサーバーは、自分の要求が認証されるために、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 を実行します。第 12 章「NIS+ 資格の管理」を参照してください。
最終的に自分のログインパスワードを使用する場合は、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 コマンドを使用します。デフォルトのドメイン名は doc.com. であるため、cred テーブルの完全指定名を入力する必要はありません。接尾辞の org_dir で十分です。ルートマスターの資格を探すためには、その Secure RPC ネット名を探してください。
この手順では、手順 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 : |
ルートドメインの管理 (admin) グループにルートマスターを追加します。
この時点では、このルートマスターサーバーは DES 資格をもつ唯一の NIS+ 主体であるため、管理グループに追加すべき唯一のメンバーです。今度は、nisgrpadm コマンドに -a オプションを付けて実行します。第 1 引数はグループ名、第 2 引数はルートマスターサーバー名です。この例では、rootmaster.doc.com. を doc.com ドメインに追加します。
rootmaster# nisgrpadm -a admin.doc.com. rootmaster.doc.com. Added rootmaster.doc.com. to group admin.doc.com. |
ルートマスターがこの管理グループに属していることを確認するには、nisgrpadm コマンドを、-l オプションを指定して実行します。第 17 章「NIS+ グループの管理」を参照してください。
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 |
ディレクトリオブジェクトは、すでに DES 資格をもつ NIS+ 主体によって作成されるのが普通です。しかしこの場合、cred テーブルを作成するまでは、自分の資格を格納する親ドメインがないため、ルートマスターサーバーは DES 資格を獲得できません。その結果、root、org_dir、および groups_dir という 3 つのディレクトリオブジェクトには、ルートマスターサーバーの公開鍵のコピーがありません。これについては、niscat -o コマンドにどれかのディレクトリオブジェクトを指定して実行することによって確認できます。「Public Key:」フィールドを探してください。手順については、第 18 章「NIS+ ディレクトリの管理」 を参照してください。
ルートマスターサーバーの公開鍵を、ルートドメインの 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) |
NIS+ キャッシュマネージャを起動します。
キャッシュマネージャは、NIS+ クライアント (この場合、ルートマスターサーバー) に関する位置情報のローカルキャッシュを管理します。初期の情報をクライアントのコールドスタートファイル (手順 11 または 手順 12 で作成) から入手し、これを /var/nis 内の NIS_SHARED_DIRCACHE という名前のファイルに保存します。
キャッシュマネージャを起動するには、次に示すように、nis_cachemgr コマンドを入力します。
rootmaster# nis_cachemgr |
キャッシュマネージャがいったん起動されたら、このプロセスを明示的に終了させた場合を除いて、再起動する必要はありません。クライアントが再起動されたときには、/var/nis 内の NIS_COLD_START ファイルがキャッシュマネージャを自動的に起動するため、キャッシュマネージャを再起動する必要はありません。
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 は、設定およびテストの目的だけに使用します。本番環境ネットワークは、レベル 0 または 1 で稼動しないでください。
ユーザーはルートドメインの 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 コマンドの詳細については、第 12 章「NIS+ 資格の管理」を参照してください。
自分の 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 ファイルに格納していない場合、このメッセージは表示されません。
他のシステム管理者の資格を追加します。
そのルートドメインで作業する他のシステム管理者の 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 テーブルにエントリが生成されます (パスワード列は除く)。次の nisaddent により、shadow 列が生成されます。各システム管理者は、chkey コマンドを使用することによって、自分のネットワークパスワードを後で変更できます。この手順については、第 12 章「NIS+ 資格の管理」を参照してください。
ルートドメインの管理グループに自分と他のシステム管理者を追加します。
この手順を実行するには、他のシステム管理者がダミーパスワードを変更するまで待つ必要はありません。-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. |
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 バイトが必要です。