ルートマスターサーバーとするマシン上にスーパーユーザーとしてログインします。
次の例では、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 を使用する構成ファイルに置き換えてください。
nsswitch.conf ファイルに対する変更が終了したら、nscd デーモンを終了して再起動します。
nscd が nsswitch.conf ファイルの内容をキャッシュに格納しているため、ファイルの内容を変更したあとは、nscd を終了して再起動する必要があります。
詳しい手順は、第 1 章「ネームサービススイッチの設定」を参照してください。
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 が実行されているかどうか確認してください。実行されている場合は、どちらのデーモンも終了してください。
手順 15 までは、実際には管理グループを作成しませんが、ここで管理グループの名前を指定する必要があります。手順 13 で管理グループの名前を指定することによって、ルートドメインの org_dir ディレクトリオブジェクト、groups_dir ディレクトリオブジェクト、およびその全テーブルオブジェクトが手順 13 で作成されたときに、適切なデフォルトグループが割り当てられます。
管理グループを指定するには、環境変数 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+ が内部目的のために名前空間のルートを記述するために使用するファイルです。NIS+ のルートディレクトリオブジェクトは、手順 10 または 手順 11 で作成します。
以降の手順では、この手順で作成されるディレクトリの下に、他のファイルが追加されます。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 で機能しなくなりますので名前の変更をしないようにしてください。
NIS+ デーモンを -Y で起動します (NIS 互換の場合のみ)。
この手順は、NIS 互換モードでルートドメインを設定している場合にだけ実行します。標準の NIS+ ドメインを設定する場合は、この代わりに 手順 11 を実行します。この手順には、NIS クライアントの DNS 転送機能をサポートするための操作手順が含まれます。
「a」では、NIS+ デーモンを NIS 互換モードで起動します。「b」では、NIS+ デーモンはこのサーバーが再起動されたとき、確実に NIS 互換モードで再起動します。手順 10 の後は、手順 13 に進んでください。
rpc.nisd に -Y、-B、-S 0 オプションを使用して実行します。
rootmaster# rpc.nisd -Y -B -S 0 option
-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+ 主体は資格をもつことができません。これより高いセキュリティレベルを使用した場合、ユーザーがサーバーから締め出されてしまいます。
ルートオブジェクトが正しく作成されているかどうか確認します。
手順 10 または手順 11 を実行すると、名前空間には次のものが作成されます。
ルートディレクトリオブジェクト (root.dir)
NIS+ デーモン (rootmaster) を実行するルートマスターサーバー (rpc.nisd)
トランザクションログファイル (trans.log)
テーブル辞書ファイル (data.dict)
ルートディレクトリオブジェクトは、手順 9 で作成したディレクトリに格納されます。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 でルートディレクトリの内容を調べたとき (手順 11)、これが空であったことを思い出してください。現在は 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 を実行します (『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 コマンドを使用します (「非ルートドメインの構成」を参照)。デフォルトのドメイン名は doc.com. であるため、cred テーブルの完全指定名を入力する必要はありません。接尾辞の org_dir で十分です。ルートマスターの資格を探すためには、その Secure RPC ネット名を探してください。
この手順では、手順 8 で指定された管理グループを作成します。nisgrpadm コマンドに -c オプションを付けて実行してください。次の例では admin.doc.com. グループを作成します。
rootmaster# nisgrpadm -c admin.doc.com. Group admin.doc.com. created.
この手順はグループを作成するだけであり、そのメンバー名の指定は行いません。これについては、手順 16 で行います。グループのオブジェクト属性を見るには、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 : Flags : Group Members :
ルートドメインの管理 (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
ディレクトリオブジェクトは、すでに 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:」フィールドに次のエントリがあるはずです。
Public key: Diffie-Hellman (192 bits)
NIS+ キャッシュマネージャを起動します。
キャッシュマネージャは、NIS+ クライアント (この場合、ルートマスターサーバー) に関する位置情報のローカルキャッシュを管理します。初期の情報をクライアントのコールドスタートファイル (手順 10 または手順 11 で作成) から入手し、これを /var/nis 内の NIS_SHARED_DIRCACHE という名前のファイルに保存します。
キャッシュマネージャを起動するには、次に示すように、nis_cachemgr コマンドを入力します。
rootmaster# nis_cachemgr
キャッシュマネージャがいったん起動されたら、このプロセスを明示的に終了させた場合を除いて、再起動する必要はありません。クライアントが再起動されたときには、/var/nis 内の NIS_COLD_STARTファイルがキャッシュマネージャを自動的に起動するため、キャッシュマネジャーを再起動する必要はありません。NIS+ キャッシュマネージャの詳細は、『Solaris ネーミングの管理』 のディレクトリに関連する章を参照してください。
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 は、設定およびテストの目的だけに使用します。
ユーザーはルートドメインの 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 ネーミングの管理』の資格に関する章を参照してください。
自分の 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 資格を追加します。これには 3 つの方法があります。
他の管理者に一時的な資格を作成するには、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 により、パスワード列が生成されます。各システム管理者は、chkey コマンドを使用することによって、自分のネットワークパスワードを後で変更できます。詳しくは、『Solaris ネーミングの管理』の資格に関連する章を参照してください。
ルートドメインの管理グループに自分と他のシステム管理者を追加します。
この手順を実行するには、他のシステム管理者がダミーパスワードを変更するまで待つ必要はありません。-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.