各手順では詳細を説明し、また関連する情報についても説明します。詳細な説明が必要でない場合は、「ルートドメイン構成の要覧」に必要なコマンドをまとめたリストがありますので参照してください。
設定作業の手順を次にまとめます。
ルートマスターサーバーにスーパーユーザーとしてログインします。
ルートマスターサーバーのドメイン名をチェックします。
ルートマスターサーバーのスイッチ構成ファイルをチェックします。
オプションで Diffie-Hellman キー長を設定します。
nsswitch.conf ファイルに少しでも変更を加えた場合は、ネームサービスキャッシュ (nscd) を再起動します。
/etc/.rootkey を削除し、keyserv を再起動します。
NIS+ サービスを停止します。
NIS+ のファイルを削除しプロセスを終了します。
ルートドメインの管理グループを指定します。
ルートディレクトリを作成し、ルートマスターサーバーを初期設定します。
(省略可能) /lib/svc/method/nisplus ファイルを編集して必要なオプションを追加します。
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.doc.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+ コマンドではないため、ドメイン名の最後にドットを付ける 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) デーモンを再起動します。
rootmaster# svcs \*name\* online Jan_12 svc:/system/name-service-cache:default rootmaster# svcadm restart system/name-service-cache |
nscd が nsswitch.conf ファイルの内容をキャッシュに格納しているため、ファイルの内容を変更したあとは、nscd を再起動する必要があります。
詳細な手順については、第 1 章「ネームサービススイッチ」を参照してください。
/etc/.rootkey ファイルを削除し、keyserv を再起動します。
rootmaster# cp /etc/nsswitch.nisplus /etc/nsswitch.conf rootmaster# svcs \*keyserv\* online Jan_12 svc:/network/rpc/keyserv:default rootmaster# svcadm disable network/rpc/keyserv rootmaster# rm -f /etc/.rootkey rootmaster# svcadm enable network/rpc/keyserv |
NIS+ サービスを停止します。
rootmaster# svcs \*nisplus\* online Jan_12 svc:/network/rpc/nisplus:default rootmaster# svcadm disable network/rpc/nisplus:default rootmaster# svcs \*nisplus\* disabled Jan_12 svc:/network/rpc/nisplus:default |
NIS+ のファイルを削除しプロセスを終了します。
現在作業しているマシンが、以前は NIS+ のサーバーまたはクライアントとして使用したものである場合、/var/nis 内にファイルがあればすべて削除します。この例では、/var/nis 内にはコールドスタートファイルとディレクトリキャッシュファイルがまだ存在します。
rootmaster# ls /var/nis NIS_COLD_START NIS_SHARED_CACHE rootmaster# rm -rf /var/nis/* |
この手順によって、/var/nis 内に残されたファイル、またはキャッシュマネージャによって格納されたディレクトリオブジェクトは完全に消去されるため、これらがこの設定作業で生成される新しい情報と重複することはありません。/var/nis 内に管理スクリプトを格納していた場合、ルートドメインの設定が終わるまでは、これらを一時的にほかのどこかに格納しておくことができます。
ルートドメインの管理グループを指定します。
手順 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 |
ルートディレクトリを作成し、ルートマスターサーバーを初期設定します。
この手順では、名前空間内の最初のオブジェクトであるルートディレクトリを作成し、マシンをルートマスターサーバーに変換します。次に示すように、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 ディレクトリが生成されます。
/var/nis ディレクトリ内には、root.object というファイルがあります。
rootmaster# ls -l /var/nis/data -rw-rw-rw- 1 root other 384 date root.object |
これはルートディレクトリオブジェクトではありません。実際には、NIS+ が内部目的で名前空間のルートを記述するために使用するファイルです。NIS+ のルートディレクトリオブジェクトはあとで作成します。
以降の手順では、この手順で作成されるディレクトリの下に、ほかのファイルが追加されます。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 で機能しなくなるので名前の変更をしないようにしてください。ディレクトリ名もファイル名も変更しないでください。
(省略可能) /lib/svc/method/nisplus ファイルを編集して必要なオプションを追加します。
-S 0 オプションを追加する必要があります。適切なテキストエディタを使用します。
/lib/svc/method/nisplus ファイルの編集方法については、「NIS+ とサービス管理機能」を参照してください。
-S 0 |
サーバーのセキュリティレベルを 0 に設定します。現時点ではブートストラップに必要です。 cred テーブルがまだ存在しないので、NIS+ 主体は資格を持つことができません。このため、高いセキュリティレベルを使用すると、サーバーからロックアウトされます。 |
-B |
DNS 転送をサポートします。 |
-Y |
NIS 互換モードで NIS+ デーモンを起動します。 |
NIS+ サービスデーモンを起動します。
rootmaster# svcadm enable network/rpc/nisplus:default |
ルートオブジェクトが正しく作成されているかどうか確認します。
名前空間には次のものが作成される必要があります。
ルートディレクトリオブジェクト (root.dir)
NIS+ サービスを実行するルートマスターサーバー (rootmaster)
マスターサーバー用のコールドスタートファイル (NIS_COLD_START)
トランザクションログファイル (trans.log)
テーブル辞書ファイル (data.dict)
ルートディレクトリオブジェクトは、手順 10 で作成したディレクトリに格納されます。ディレクトリの内容を確認してください。
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 -e | 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 テーブルへの読み取り権を未認証クラスに割り当てます。
現在、ルートディレクトリには 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 引数はルートマスターサーバー名です。この例では doc.com ドメインに rootmaster.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+ サービスを再起動します。
これで、ルートマスターサーバーには DES 資格があり、ルートディレクトリオブジェクトにはルートマスターの公開鍵のコピーがあるため、ルートマスターを再起動すると、自動的にセキュリティレベル 2 で起動されます。
サービス管理機能では、/var/nis/NIS_COLD_START ファイルが検出されると、NIS+ サービスを有効にしたときに nis_cachemgr を自動的に起動します。
NIS と互換性のあるルートドメインの場合は、必ず /lib/svc/method/nisplus ファイルを編集して -Y フラグを追加してください。詳細については、「NIS+ とサービス管理機能」を参照してください。
rootmaster# svcs \*nisplus\* online Jan_12 svc:/network/rpc/nisplus:default rootmaster# svcadm restart network/rpc/nisplus:default |
セキュリティレベル 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+ モードで実行されている Solaris 管理コンソール (使用できる場合) を使用すると簡単です。
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 コマンドを使用することによって、自分のネットワークパスワードを後で変更できます。この手順については、第 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 バイトが必要です。