パート II NIS+ の設定と構成

パート II では、NIS+ 名前空間を設定および構成する方法について説明します。

• 第 2 章では、NIS+ とは何かを紹介します。

• 第 3 章と第 4 章では、NIS+ 設定スクリプトを使って NIS+ 名前空間を設定する方法を説明します。NIS+ の設定と構成には、NIS+ 設定スクリプトを使うと便利です。

• 第 5 章から第 9 章では、NIS+ の各種コマンドを使って NIS+ 名前空間を設定する方法を説明します。

パート II は次の 8 つの章で構成されています。

• 第 2 章「NIS+ 入門」

• 第 3 章「NIS+ 設定スクリプト - 紹介」

• 第 4 章「スクリプトを使用した NIS+ の設定」

• 第 5 章「ルートドメインの設定」

• 第 6 章「NIS+ クライアントの構成」

• 第 7 章「NIS+ サーバーの構成」

• 第 8 章「非ルートドメインの構成」

• 第 9 章「NIS+ テーブルの設定」

第 2 章 NIS+ 入門

この章では、「Network Information Service Plus」の概要を説明します。また NIS+ を設定する前に行うべき作業を列挙し、NIS+ 名前空間の最低要件について確認したうえで、NIS+ の設定方法を 2 通り紹介します。

• 「NIS+ の概要」

• 「設定および構成の前に」

• 「名前空間がすでに存在する場合の設定」

• 「2 通りの構成方法」

NIS+ の概要

NIS+ はネットワークネームサービスの一種です。NIS と似ていますが、機能はさらに豊富になっています。NIS の拡張機能というより新しいソフトウェアプログラムであるといえます。

NIS+ は (ワークステーションのアドレス、セキュリティ情報、メール情報、Ethernet インタフェースおよびネットワークサービスに関する情報などの) 情報を 1 ヵ所に格納して、ネットワーク上のすべてのワークステーションからアクセスできるようにします。このように構成されたネットワーク情報を、NIS+「名前空間」と呼びます。

NIS+ 名前空間は UNIX のファイルシステムに似た階層構造になっているため、組織の論理上の階層に合わせて構成できます。名前空間における情報の配置は、物理的な配置とは関係ありません。NIS+ 名前空間は複数のドメインに分割が可能で、それぞれ独立して管理できます。クライアントは、適切なアクセス権を持っていれば自分のドメインだけでなく他のドメインの情報にもアクセスできます。

NIS+ では、NIS+ 名前空間への情報の保存やその情報へのアクセスにクライアントサーバーモデルを使用します。それぞれのドメインは、複数のサーバーによってサポートされます。主となるサーバーを「マスター」サーバー、補助用のサーバーを「複製」サーバーと呼びます。ネットワーク情報は、NIS+ 内部のデータベースにある 16 個の標準 NIS+ テーブルに格納されます。マスターサーバーと複製サーバーの両方で NIS+ サーバーソフトウェアが動作しており、NIS+ テーブルのコピーを維持しています。マスターサーバーの NIS+ データに変更が加えられると、その内容は自動的に複製サーバーに順次反映されます。

NIS+ では高機能のセキュリティシステムによって、名前空間の構造と保存されている情報が保護されます。このシステムは、情報にアクセスしようとしているクライアントが正当なものであるかどうかを認証と承認によって確認します。「認証」では、情報を要求しているのがネットワーク上の正当なユーザーであるかどうかを確認します。「承認」では、ユーザーが情報を所有したり修正したりできるかどうかを確認します。

Solaris のクライアントは、ネームサービススイッチ (/etc/nsswitch.conf ファイル) を使用して、ワークステーションがネットワーク情報を検索する場所を指定します。ネットワーク情報が保存されているのは、ローカルの /etc ディレクトリのファイル、NIS、DNS、NIS+ です。ネームサービススイッチには、情報の種類ごとに異なる情報源を指定することもできます。

NIS+ の詳細は、『Solaris ネーミングの管理』を参照してください。

設定および構成の前に

NIS+ 名前空間を構成する前に、次の作業を行う必要があります。

• NIS+ を使用するすべてのマシンの nsswitch.conf ファイルを正しく構成します。詳細は、第 1 章「ネームサービススイッチの設定」を参照してください。

• NIS+ 名前空間のレイアウトを設計します。これには次の 2 つの作業があります。

  • 名前空間の設計

    • どんなドメイン名を付けるか

    • サブドメインを作るか

    • サブドメインを作るとしたら、それらをどのように編成するか

    • どのマシンをどのドメインに入れるか

    • ドメインを上位のドメインあるいはインターネットに接続するか

  • サーバー要件の確認

    • 各ドメインに複製サーバーをいくつ置くか

    • 必要なサーバーの種類、処理速度、メモリ容量は

    • サーバーのディスク容量はどれくらい必要か

    設計に関する詳細な検討項目や指針については、『NIS+ への移行』を参照してください。

• 名前空間がすでに存在している場合、NIS+ に移行するための準備をします。「名前空間がすでに存在する場合の設定」を参照してください。

• ルートサーバーマシンを選択します。

• ルートマスターサーバーとして使用できるシステムが少なくとも 1 つは稼動していることを確認します。ルートマスターサーバーでは、/etc/passwd などのシステム情報ファイルに少なくとも 1 人のユーザー (root) が登録されていなければなりません 。通常のマシンのシステム情報ファイルには root が存在しますので、これが問題となることはないはずです。

名前空間がすでに存在する場合の設定

NIS ドメインがすでに存在する場合は、NIS+ 名前空間にも既存のものと同じフラットな構造のドメインを使用できます (階層構造にあとから変更可能)。NIS から NIS+ への移行は、『NIS+ への移行』を読んで、計画や準備に関する重要事項を確認してから行なってください。NIS+ のスクリプトを使用すると、NIS マップのデータを利用して簡単に NIS+ を起動できます。第 4 章「スクリプトを使用した NIS+ の設定」では、NIS+ スクリプトを使用してシステムファイルや NIS マップから NIS+ 名前空間を作成する方法を説明します。

ただし、名前空間がすでに存在している場合、スクリプトをスムーズに実行するため NIS+ への移行用の設定が必要です。詳細は、『NIS+ への移行』を参照してください。

準備に関する主な注意事項は次のとおりです。

• 「ドメインとホストには同じ名前を使用しない」

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

• 「ホスト名にはドットを使用しない」

  NIS+ では、マシン名とドメイン名の間や、親とサブドメインの間の区切りにドット (ピリオド) を使用します。このため、マシン名の中ではドットを使用できません。使用している場合は、NIS+ に移行する前に (スクリプトを実行する前に) 必ず変更してください。ホスト名中のドットは、ハイフンに置き換えます。たとえば、sales.alpha という名前は、sales-alpha という名前に置き換えます

• 「ルートサーバーが動作していることを確認する」

  ルートサーバーになるマシンが起動されていることを確認します。また、スーパーユーザーとしてアクセスできることも確認します。

• データのロード元のローカル /etc ファイル、または NIS マップのエントリを確認する。偽造されたエントリや誤ったエントリがなく、正しいデータが、所定の場所に正しい書式で記録されていることを確認し、エントリの中で、古いもの、無効なもの、破損しているものは削除します。また、不完全なエントリも削除します。構成完了後は、いつでもエントリを追加できます。必要なエントリをあとから追加する方が、不完全なエントリや破損しているエントリを読み込もうとするよりも簡単です。

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

2 通りの構成方法

ここでは、NIS+ 名前空間の 2 通りの構成方法を紹介します。

• 「設定 (構成) 用のスクリプトを使う方法」

  第 2 章、第 3 章で説明するように、nisserver、nispopulate、nisclient という 3 つのスクリプトを使って NIS+ 名前空間を構成します 。簡単に済ませることができるため、こちらの方法をお勧めします。

• 「NIS+ コマンドを使う方法」

  第 4 章から第 9 章で説明するように、NIS+ コマンドを使うとスクリプトを使う場合より柔軟に構成を決めることができますが、それだけ難しく、NIS+ 管理者としての経験が必要になります。スクリプトによる標準構成では要件を満たせないといった場合に限り使用してください。

NIS+ コマンドを使って構成する場合、NIS+ ネームサービスを使う各マシンの /etc ディレクトリに正しい nsswitch.conf ファイルが必ず格納されるようにしてください (第 1 章「ネームサービススイッチの設定」を参照)。この作業は、NIS+ 構成スクリプトを使った場合は自動的に行われます。

NIS+ ディレクトリ、NIS+ ドメイン、NIS+ サーバー、NIS+ 名前空間を削除する方法については、『Solaris ネーミングの管理』を参照してください。

第 3 章 NIS+ 設定スクリプト - 紹介

この章では、NIS+ スクリプトについて説明し、スクリプトの実行する作業と実行しない作業について解説します。

• 「NIS+ スクリプトについて」

• 「NIS+ スクリプトでは実行しないこと」

NIS+ スクリプトについて

「設定および構成の前に」の手順を必ず実行してから、NIS+ スクリプトを実行してください。

3 つの NIS+ スクリプト nisserver、nispopulate、nisclient を使用すれば、NIS+ 名前空間を設定できます。NIS+ スクリプトは NIS+ コマンド群を実行する Bourne シェルスクリプトであり、NIS+ コマンドを個別に入力する必要はありません。各スクリプトの動作内容を表 3-1 に示します。

NIS+ スクリプトで実行すること

NIS+ スクリプトといくつかの NIS+ コマンドと組み合わせることで、NIS+ 名前空間の設定に必要な作業を実行できます。NIS+ スクリプトとそのオプションについての詳しい説明は、nisserver(1M)、nispopulate(1M)、nisclient(1M) のマニュアルページを参照してください。第 4 章「スクリプトを使用した NIS+ の設定」では、NIS+ スクリプトを使用した NIS+ 名前空間の設定方法について説明しています。

-x オプションを使用して、コマンドを実際に実行せずに各スクリプトを実行できます。このオプションを使用すると、スクリプトが呼び出すコマンドとおおよその結果をシステムを変更せずに確認できます。-x オプションを使用してスクリプトを実行することで、予想外の結果を最小限にできます。

NIS+ スクリプトでは実行しないこと

NIS+ スクリプトを使用すれば NIS+ 名前空間の作成に必要な作業が軽減されるとはいえ、スクリプトですべての NIS+ コマンドを代行できるわけではありません。スクリプトは、NIS+ の一部の機能を提供するだけです。NIS+ にまだ慣れていない場合、NIS+ 名前空間のサンプルを作成してからこの節を読むこともできます。

nisserver スクリプトは、標準のテーブルとアクセス権 (承認) で NIS+ サーバーを設定するだけです。このスクリプトでは次のことは実行しません。

• テーブルとディレクトリに特別なアクセス権を設定する

• NIS+ 管理グループへ NIS+ 主体を追加する

  NIS+ スクリプトではなく nisgrpadm コマンドを使用して、NIS+ 管理グループに特別な NIS+ 主体を追加する方法については、第 4 章「スクリプトを使用した NIS+ の設定」を参照してください。

• 独自のテーブルを作成する

• レベル 2 以外の任意のセキュリティレベルで NIS+ サーバーを実行する

• リモートサーバーで rpc.nisd デーモンを起動する。この作業は、サーバーのインストールを完了するために必要

NIS+ スクリプトではなく rpc.nisd コマンドを使用して、NIS+ クライアントマシンを非ルートサーバーに変更する方法については、第 4 章「スクリプトを使用した NIS+ の設定」を参照してください。

nisclient スクリプトは、DNS を使用してホスト名を検索するように NIS+ クライアントを設定することはありません。この設定を必要とするクライアントの場合、DNS を明確に設定しなければなりません。

第 4 章 スクリプトを使用した NIS+ の設定

この章では、nisserver、nispopulate、nisclient の各スクリプトと NIS+ コマンドを組み合わせて、基本的な NIS+ 名前空間を構成する方法について説明します。

• 「NIS+ 設定の概要」

• 「NIS+ 名前空間サンプルの作成」

• 「NIS+ ルートサーバーの設定」

• 「NIS+ テーブルの生成 (populate)」

• 「NIS+ クライアントマシンの設定」

• 「NIS+ クライアントユーザーの初期設定」

• 「NIS+ サーバーの設定」

• 「ルート複製サーバーの作成」

• 「サブドメインの作成」

• 「新しいサブドメインのテーブルの生成」

• 「サブドメイン複製サーバーの作成」

• 「サブドメインの NIS+ クライアントマシンの初期設定」

• 「サブドメインの NIS+ クライアントユーザーの初期設定」

• 「NIS+ 名前空間サンプルで使用したコマンドのまとめ」

また、この章では次の手順について説明します。

• 「ルートマスターサーバーを作成する方法」

• 「誤った情報を変更する方法」

• 「ルートマスターサーバーのテーブルを生成する方法」

• 「新しいクライアントマシンを初期設定する方法」

• 「NIS+ ユーザーを初期設定する方法」

• 「クライアントを NIS+ サーバーとして構成する方法」

• 「ルート複製サーバーを作成する方法」

• 「新しい非ルートドメインを作成する方法」

• 「マスターサーバーテーブルを生成する方法」

• 「複製サーバーを作成する方法」

• 「新しいサブドメインクライアントマシンを初期設定する方法」

• 「NIS+ サブドメインユーザーを初期設定する方法」

NIS+ 設定の概要

NIS+ 名前空間の設定と構成には、スクリプトを使用する方法をお勧めします。NIS+ コマンド群を使って NIS+ 名前空間を設定する方法 (以降の章で説明) より簡単に実行できます。

(スクリプトの詳細は、nisserver(1M)、nispopulate(1M)、nisclient(1M) の各マニュアルページを参照してください。用語や略語の定義については、『Solaris ネーミングの管理』の用語集を参照してください。)

このチュートリアルで説明するサンプルの小さな NIS+ 名前空間を土台にして実際の NIS+ 名前空間を作ることはしないでください。名前空間についてひととおり理解できたら、サンプルの名前空間は削除してください。サンプルの名前空間に実際の名前空間を追加しないでください。あらためて、初めから NIS+ 階層の計画を注意深く立ててから、実際の名前空間を作成してください。

一般に推奨される設定手順を表 4-1 に要約します。左端の列には、ルートドメインの構成やクライアントの作成などの主な設定作業を示します。中央の列には作業の説明を、右端の列には各手順に必要なスクリプトまたは NIS+ コマンドをそれぞれ示します

NIS+ スクリプトを使用することによって、上の作業で示される個々の手順の大部分を省略できます。

NIS+ 名前空間サンプルの作成

この章では、サンプルの NIS+ 名前空間を作成する方法を説明します。NIS+ 名前空間のサンプルは、/etc 内のファイルと NIS マップから作成されます。このサンプルでは、サイトで NIS を実行している場合と実行していない場合の両方について、スクリプトの使用方法を説明します。サーバーが NIS クライアントにサービスを提供する場合、サーバーを NIS 互換モードに設定できます。NIS 互換モードの詳細は、『NIS+ への移行』および『Solaris ネーミングの管理』を参照してください。

サイトの実際の NIS+ 名前空間とそのドメイン階層は、名前空間サンプルのものとはおそらく異なり、サーバー、クライアント、およびドメインの数も異なります。最終的なドメイン構成と階層は、このサンプルと異なるものと考えてください。この名前空間サンプルは、NIS+ スクリプトの使用法を説明するためだけのものです。この名前空間サンプルを作成すると、自分のサイトでのドメイン、サーバー、およびクライアントの作成方法も理解できるはずです。

名前空間サンプルには次の構成要素があります。

• ルートマスターサーバー 1 台 (名称 master、doc.com ドメイン用)

• ルートドメイン (doc.com.) のクライアント 4 台

  • client1 は、ルート複製サーバーとなる (doc.com. ドメイン用)

  • client2 は、新しいサブドメインのマスターサーバーとなる (sub.doc.com. ドメイン用)

  • client3 は、新しいサブドメインの非ルート複製サーバーとなる (sub.doc.com. ドメイン用)

  • client4 は、ルートドメインのクライアントとして残る (doc.com. ドメイン用)

• サブドメインの 2 台のクライアント (名称 subclient1 および subclient2、sub.doc.com. ドメイン用)

ここでは、/etc/hosts などのシステム情報ファイルと NIS マップの両方を使用してネットワークサービス情報を格納するサイトで、NIS+ の設定に使用されるスクリプトを説明します。NIS+ 名前空間サンプルでこのような混合型のサイトを使用するのは、単にサンプルとして示すことが目的です。

NIS+ スクリプトのコマンド行の要約

NIS+ ドメインの例を作成する場合の NIS+ スクリプトとコマンドの一般的な順序を、表 4-2 に示します。このあとの節ではこれらのコマンド行について詳しく説明します。NIS+ のドメイン、サーバー、およびクライアントの作成に必要な作業に習熟した後、表 4-2 はコマンド行のクイックリファレンスガイドとして使用してください。表 4-2 は、NIS+ 名前空間サンプルを作成するために実際に入力するコマンドと変数をまとめたものです。

実際にコマンドを実行させないで、しかも NIS+ スクリプトがどんなコマンドを呼び出すかを表示するには、-x オプションを使います。-x オプションによって、あたかも実際にスクリプトを実行しているかのように、それらのコマンド名とそれぞれのおおよその出力を画面に表示できます。最初に -x を指定してスクリプトを実行すれば、結果を先に見ることができます。詳細は各スクリプトのマニュアルページを参照してください。

NIS+ ルートサーバーの設定

NIS+ ドメインを設定するための最初の作業が、ルートマスターサーバーの設定です。この節では、nisserver スクリプトを使用してデフォルト設定でルートマスターサーバーを構成する方法を説明します。ルートマスターサーバーは、次のデフォルトを使用します。

• セキュリティレベル 2 (DES) - NIS+ セキュリティの最高レベル

• NIS 互換を OFF に設定 (NIS 互換に設定する方法も記述)

• ネームサービス情報の情報源としてシステム情報ファイル (/etc) または NIS マップ

• NIS+ グループとして admin. domainname

nisserver スクリプトは、ルートマスターサーバーを設定するときに、ネームサービススイッチファイルを NIS+ 用に変更します。/etc/nsswitch.conf ファイルは後で変更できます。ネームサービススイッチについては、『Solaris ネーミングの管理』およびこのマニュアルの第 1 章「ネームサービススイッチの設定」を参照してください。

nisserver を実行するための前提条件

ルートマスターサーバーにしたいマシンの /etc/passwd ファイルに root のエントリがあるかどうかを確認します。

必要な情報

次の情報が必要です。

• ルートマスターサーバーになるワークステーションのスーパーユーザーのパスワード

• 新しいルートドメインの名前。ルートドメイン名は少なくとも 2 つの要素 (ラベル) で構成し、その末尾にドットを置きます (例 something.com.)。最後の要素は実際には何でもかまわないのですが、インターネットとの互換性を保つには、インターネット組織コード (表 4-3) または 2 〜 3 文字の地域コード (日本であれば .jp.) にしなければなりません。

次の例では、ルートマスターサーバーに指定するマシンは master1 で、doc.com. が新しいルートドメインになります。

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

ルートマスターサーバーを作成する方法

1. スーパーユーザーの PATH 変数に /usr/lib/nis を追加します。

   このパスを root の .cshrc または .profile ファイルに追加するか、または変数を直接設定します。

2. オプションで DES 認証を使用する場合には、Diffie-Hellman キー長を選択します。

   640 ビットの Diffie-Hellman キーとデフォルトの 192 ビットのキーを使用するには、以下を入力します。

   nisauthconf dh640-0 des

   640 ビットのキーだけを許可し、192 ビットのキーを拒否するには、以下を入力します。

   nisauthconf dh640-0

3. 次のコマンドをスーパーユーザー (root) として入力し、ルートマスターサーバーを構成します。

   -r オプションはルートマスターサーバーを構成することを示します。-d オプションは NIS+ ドメイン名を指定します。

   master1# nisserver -r -d doc.com. This script sets up this machine "master1" as a NIS+ root master server for domain doc.com. Domain name : doc.com. NIS+ group : admin.doc.com. NIS (YP) compatibility : OFF Security level : 2=DES Is this information correct? (type 'y' to accept, 'n' to change)

   「NIS+ group」とは、doc.com. ドメイン (ドメイン名は必ず最後にピリオドが付く) 内の情報を変更する許可が与えられたユーザーのグループを意味します。変更には削除も含まれます。このグループのデフォルト名は admin.domainname です。この名前の変更方法については、「誤った情報を変更する方法」を参照してください。

   「NIS 互換」とは、NIS+ サーバーが NIS クライアントからの情報要求を受け付けるかどうかを意味します。デフォルト設定の OFF に設定されている場合、NIS+ サーバーは NIS クライアントからの要求を処理しません。ON に設定されている場合、NIS+ サーバーはこの要求を処理します。このスクリプトでは、NIS 互換設定を変更できます。「誤った情報を変更する方法」を参照してください。

   ---

   注 -

   このスクリプトは、マシンを NIS+ セキュリティの最高レベルであるセキュリティレベル 2 で設定します。このスクリプトを使用する場合、セキュリティレベルを変更できません。スクリプトが終了した後、適切な NIS+ コマンドでセキュリティレベルを変更できます。セキュリティレベルの変更については、『Solaris ネーミングの管理』および rpc.nisd(1M) のマニュアルページを参照してください。

   ---

4. y を入力します (画面の情報が正しい場合)。

   n を入力すると、スクリプトは正しい情報の入力を要求します。( n を入力した場合の操作については、「誤った情報を変更する方法」を参照してください)。

   Is this information correct? (type 'y' to accept, 'n'' to change) y This script will set up your machine as a root master server for domain doc.com. without NIS compatibility at security level 2. Use "nisclient -r" to restore your current network service environment. Do you want to continue? (type `y' to continue, `n' to exit the script)

5. y を入力して、NIS+ の構成を続けます。

   ( n を入力するとスクリプトは安全に終了します)。y を選んだ後でスクリプトの実行中にスクリプトを中断した場合、スクリプトは動作を停止し、それまでに作成された構成内容はそのまま残されます。スクリプトは自動回復や後始末は行いません。このスクリプトはいつでも再実行できます。

   Do you want to continue? (type 'y' to continue, 'n' to exit the script y setting up domain information "doc.com." ... setting up switch information ... running nisinit ... This machine is in the doc.com. NIS+ domain. Setting up root server ... All done. starting root server at security level 0 to create credentials... running nissetup ... (creating standard directories & tables) org_dir.doc.com. created Enter login password:

   nissetup(1M) コマンドは、各 NIS+ テーブルのディレクトリを作成します。

6. プロンプトに対してマシンの root パスワードを入力し、Return キーを押します。

   この例の場合、ユーザーは master1 マシンの root パスワードを入力しています。

   Wrote secret key into /etc/.rootkey setting NIS+ group to admin.doc.com. ... restarting root server at security level 2 ... This system is now configured as a root server for domain doc.com. You can now populate the standard NIS+ tables by using the nispopulate or /usr/lib/nis/nisaddent commands.

   これでルートマスターサーバーが構成され、NIS+ の標準テーブルを生成する用意が整いました。続けてテーブルを生成する場合は、「NIS+ テーブルの生成 (populate)」に進みます。

誤った情報を変更する方法

上記の 手順 4 で返された情報の一部あるいは全部が誤っていたために n を入力した場合、次のように表示されます。

Is this information correct? (type 'y' to accept, 'n' to change)
 n
Domain name: [doc.com.]

1. ドメイン名が正しい場合は Return キーを押します。誤っている場合は、正しいドメイン名を入力して Return キーを押します。

   この例では、Return キーを押して、目的のドメイン名が doc.com であることを確認しました。次に、このスクリプトは NIS+ グループ名の確認を要求します。

   Is this information correct? (type 'y' to accept, 'n' to change) n Domain name: [doc.com.] NIS+ group: [admin.doc.com.]

2. NIS+ グループが正しければ Return キーを押します。間違っている場合、正しい NIS+ グループ名を入力して Return キーを押します。

   この例では、名前を変更しました。次に、スクリプトは NIS 互換性の入力を要求します。

   NIS+ group: [admin.doc.com.] netadmin.doc.com. NIS (YP) compatibility (0=off, 1=on): [0]

3. NIS 互換性を必要としない場合は Return キーを押します。互換性が必要な場合は 1 を入力して Return キーを押します。

   この例では、Return キーを押して、NIS 互換の状態が正しいことを確認しました。スクリプトは、情報が正しいかどうかを再度尋ねてきます。

   ---

   注 -

   このサーバーを NIS 互換に選択した場合、この選択を有効にするには、ファイルを編集して、rpc.nisd デーモンを再起動する必要があります。詳細は 「クライアントを NIS+ サーバーとして構成する方法」を参照してください。

   ---

   NIS (YP) compatibility (0=off, 1=on): [0] Domain name : doc.com. NIS+ group : netadmin.doc.com. NIS (YP) compatibility : OFF Security level : 2=DES Is this information correct? (type 'y' to accept, 'n' to change)

   情報が正しい場合、「ルートマスターサーバーを作成する方法」の手順 3 に移ります。正しい情報となるまで、n を繰り返し選択できます。

Multihomed NIS+ ルートマスターサーバーの設定方法

multihomed NIS+ サーバーを設定する手順は、単一インタフェースサーバーの設定手順と同じです。唯一の相違点は、ローカルの /etc/hosts ファイルと NIS+ の hosts テーブル内に定義する必要があるインタフェースが、単一インタフェースサーバーの場合よりも多いという点です。ホスト情報を定義したら、nisclient と nisserver スクリプトを使用して multihomed NIS+ サーバーを設定します。multihomed 複製サーバーの設定の詳細は、「Multihomed NIS+ 複製サーバーの設定方法」を参照してください。

multihomed NIS+ サーバーを設定する場合は、サーバーの主体名はシステムのノード名と同じにする必要があります。これは、Secured RPC と nisclient を同時に使用する際の必要条件です。

• Secured RPC は、ノード名を使用して認証に必要なネット名を作成する

• nisclient は、主体名を使用してクライアントの資格を作成する

次に、NIS+ ルートマスターサーバーの設定手順を示します。

1. ルートマスター上で、サーバーのホスト情報を /etc/hosts ファイル内に追加します。たとえば、3 つのイーサネットインタフェースを装備した hostA システムの場合、/etc/hosts ファイルには次のように入力します。

   127.0.0.1 localhost loghost 192.168.10.x hostA hostA-10 hostA-le0 192.168.11.y hostA hostA-11 hostA-le1 192.168.12.z hostA hostA-12

2. nisserver を使用して、サーバーを multihomed NIS+ ルートサーバーとして設定します。

   hostA# nisserver -r -d sun.com

   上記の例では、sun.com はルートドメイン名を表しています。ルートドメイン名を指定して nisserver コマンドを実行してください。

   multihomed NIS+ ルートサーバーの設定が完了したら、このあとの設定手順は、単一インタフェースサーバーの設定手順とまったく同じです。

NIS+ テーブルの生成 (populate)

ルートマスターサーバーの構成が終了すると、他のネットワークサービスの情報から標準の NIS+ テーブルを生成できます。この節では、nispopulate(1M) スクリプトをデフォルトの設定で使用して、ファイルまたは NIS マップのデータからルートマスターサーバーのテーブルを生成する方法を説明します。このスクリプトは次のものを使用します。

• 前の例で作成されたドメイン (doc.com.)

• ネットワークサービスのソースとしてシステム情報ファイルまたは NIS マップ

• 標準の NIS+ テーブル： auto_master、auto_home、ethers、 group、hosts、

  networks、 passwd、protocols、services、 rpc、netmasks、bootparams、

  netgroup、aliases

テーブルの情報源がファイルである場合、shadow ファイルの内容が passwd ファイルの内容とマージされて passwd テーブルが作成されます。shadow テーブルは作成されません。

nispopulate を実行するための前提条件

スクリプト nispopulate を実行するには、次の条件が必要です。

• データを読み込むローカルの /etc 内の各ファイルまたは NIS マップを表示します。不正なエントリがないことを確認します。正しいデータが、所定の場所に正しい書式で記録されていることを確認します。エントリのうち、古いもの、無効なもの、破損しているものは削除します。また、不完全なエントリや一部のみのエントリも削除します。構成が完了した後は、いつでも各エントリを追加できます。後から追加する方が、不完全なエントリや破損したエントリを読み込むよりも簡単です。

• ファイル内の情報は、それがロードされるテーブルに適合する書式でなければなりません。『Solaris ネーミングの管理』および第 9 章「NIS+ テーブルの設定」では、対応する NIS+ テーブルに変換するテキストファイルで要求される書式について説明しています。

• ドメイン名とホスト名が同一でないことを確認します。ドメインとホストで同じ名前は使用しないでください。たとえば、sales というドメインを使用している場合、sales という名前の付いたマシンを使用しないでください。同様に、home という名前のマシンを使用する場合は、home という名前のドメインを作成しないでください。この注意事項は、サブドメインの場合にもあてはまります。たとえば、マシンに west という名前を付けている場合、sales.west.myco.com というサブドメインを作成しないでください。

• ホスト名のドットと下線はすべて削除します。NIS+ では、ドット (ピリオド) をマシン名とドメインの間、および親ドメインとサブドメインの間の区切りに使用するため、ドットをマシン名に使うことはできません。DNS ではホスト名に下線を使うことを認めていませんので、ホスト名に下線を使うことはできません。nispopulate スクリプトを実行する前に、ホスト名で使用されているドットを必ず削除してください。ドットをハイフンに置き換えるのも 1 つの手です。たとえば、sales.alpha というマシン名は無効ですが、これを sales-alpha とすれば有効になります。

• 初めてネットワークを設定する場合、十分なネットワーク情報がどこにも格納されていないことがあります。このような場合、まずネットワーク情報を集め、「入力ファイル」に手入力する必要があります。このファイルは、基本的に /etc 内のファイルに対応するものです。

• 安全のため、/etc 内のファイルのコピーを作成します。実際のファイルは使用せずに、作成したコピーを使用してテーブルを生成してください。たとえば、この例では /nisplusfiles というディレクトリ内のファイルを使用します。

• コピーした NIS テーブルファイルのうち、passwd、shadow、aliases、hosts の各ファイルには、名前空間全体に分散させるとセキュリティ上問題がある項目があるので、それらを編集します。たとえば、次に示す行をローカル側の passwd ファイルのコピーから削除して、名前空間からはそれらの情報にアクセスできないようにします。

root:x:0:1:0000-Admin(0000):/:/sbin/sh
daemon:x:1:3:0000-Admin(0000):/:
bin:x:3:5:0000-Admin(0000):/usr/bin:
sys:x:3:3:0000-Admin(0000):/:
adm:x:4:4:0000-Admin(0000):/var/adm:
lp:x:78:9:0000-lp(0000):/usr/spool/lp:
smtp:x:0:0:mail daemon user:/:
uucp:x:5:5:0000-uucp(0000):/usr/lib/uucp:
nuucp:x:7:8:0000-uucp (0000):/var/spool/uucppublic:/usr/lib/uucp/uucico
listen:x:22:6:Network Admin:/usr/net/nls
nobody:x:60000:60000:uid no body:/:
noaccess:x:60002:60002:uid no access:/:

• ドメインがすでに構成され、そのマスターサーバーが実行されている必要があります。

• ドメインのサーバーには、新しいテーブル情報を収容できるだけの十分なディスク空き領域が必要です。

• NIS+ 主体 (適切な資格を持つクライアント) としてログインし、指定されたドメイン内の NIS+ テーブルに対する書き込み権が必要です (この例では、マシン master1 上のユーザーは root) 。

必要な情報

ファイルから生成する場合、次の情報が必要です。

• 新しい NIS+ ドメイン名

• 適切に編集された変換されるデータを持つテキストファイルへのパス

• ルートパスワード

NIS マップから生成する場合、次の情報が必要です。

• 新しい NIS+ ドメイン名

• NIS ドメイン名

• NIS サーバー名

• NIS サーバーの IP アドレス

• ルートパスワード

NIS のドメイン名では大文字と小文字を区別しますが、NIS+ のドメイン名では区別しません。

ルートマスターサーバーのテーブルを生成する方法

1. 「a」または「b」を実行してルートマスターサーバーテーブルを生成し、手順 2 に進みます。

   「a」では、ファイルからテーブルを生成する方法を示します。「b」では、NIS マップからテーブルを生成する方法を示します。これらのコマンドはスクロールできるウィンドウ内で実行します。そうしないと、スクリプトの出力がスクロールされて読めないことがあります。

   ---

   注 -

   システムの /tmp 領域が不足すると、nispopulate スクリプトが異常終了することがあります。このようなことが起こらないように、環境変数 TMPDIR に別のディレクトリを設定できます。TMPDIR に有効なディレクトリが設定されていない場合、スクリプトは /tmp ディレクトリを使用します。

   ---

   1. 次のように入力して、ファイルからテーブルを生成します。

      master1# nispopulate -F -p /nis+files -d doc.com. NIS+ domain name : doc.com. Directory Path : /nis+files Is this information correct? (type 'y' to accept, 'n' to change)

      -F オプションは、テーブルがデータをファイルから取り出すことを示します。-p オプションは、入力ファイルが存在するディレクトリのパスを指定します (この例では、パスは /nis+files)。-d オプションは NIS+ ドメイン名を指定します (この例では、ドメイン名は doc.com.)。

      NIS+ 主体のユーザーは root です。この例では、初めてルートマスターサーバーのテーブルを生成することになるため、この作業はスーパーユーザーとして実行しなければなりません。nispopulate スクリプトは、NIS+ 管理グループのすべてのメンバーの資格を追加します。

   2. 次のように入力して、NIS マップからテーブルを生成します。

      master1# nispopulate -Y -d doc.com. -h salesmaster -a 130.48.58.111 -y sales.doc.com. NIS+ domain name : doc.com. NIS (YP) domain : sales.doc.com NIS (YP) server hostname : salesmaster Is this information correct? (type 'y' to accept, 'n' to change)

      -Y オプションは、テーブルがデータを NIS マップから取り出すことを示します。-d オプションは、NIS+ ドメイン名を指定します。-h オプションは、NIS サーバーのマシン名を指定します。salesmaster は NIS サーバーの名前の例です。サンプルドメインを作成する際は、salesmaster の代わりに、サイトでの実際の NIS サーバー名を指定してください。-a オプションは、NIS サーバーの IP アドレスを指定します。130.48.58.111 はアドレスの例です。サンプルドメインを作成する際は、サイトでの実際の NIS サーバーの IP アドレスを指定してください。-y オプションは、NIS ドメイン名を指定します。sales.doc.com はドメイン名の例です。サンプルドメインを作成する際は、sales.doc.com の代わりに、サイトでの実際の NIS ドメインの NIS ドメイン名を指定してください。NIS ドメイン名は大文字と小文字が区別されることを忘れないでください。

      NIS+ 主体のユーザーは root です。この例では、初めてルートマスターサーバーのテーブルを生成することになるため、この作業はスーパーユーザーとして実行しなければなりません。nispopulate(1M) スクリプトは、NIS+ 管理グループのすべてのメンバーの資格を追加します。

2. y を入力します (画面に表示された情報が正しい場合)。

   n を入力すると、スクリプトは正しい情報の入力を要求します。情報が誤っている場合の操作は、「誤った情報を変更する方法」を参照してください。

   • 手順 1 の「a」を実行すると、次のように表示されます。

     Is this information correct? (type 'y' to accept, 'n' to change) y This script will populate the following NIS+ tables for domain doc.com. from the files in /nis+files: auto_master auto_home ethers group hosts networks passwd protocols services rpc netmasks bootparams netgroup aliases shadow **WARNING: Interrupting this script after choosing to continue may leave the tables only partially populated. This script does not do any automatic recovery or cleanup. Do you want to continue? (type 'y' to continue, 'n' to exit this script)

   • 手順 1 の「b」を実行すると、次のように表示されます。

     Is this information correct? (type 'y' to accept, 'n' to change) y This script will populate the following NIS+ tables for domain doc.com. from the NIS (YP) maps in domain sales: auto_master auto_home ethers group hosts networks passwd protocols services rpc netmasks bootparams netgroup aliases **WARNING: Interrupting this script after choosing to continue may leave the tables only partially populated. This script does not do any automatic recovery or cleanup. Do you want to continue? (type 'y' to continue, 'n' to exit this script)

3. y を入力して、テーブルの生成を続けます。

   n を入力すると、スクリプトは安全に終了します。y を選択した後で、スクリプトの実行中にスクリプトを中断した場合、スクリプトは動作を停止し、テーブルは一部だけが生成されたままで残されることがあります。現在生成中であったテーブルは、一部だけが生成されていることがあります。スクリプトは自動回復や後始末は行いません。このスクリプトは安全に再実行できますが、テーブルは最新の情報で上書きされます。

   • ファイルからテーブルを生成する場合、スクリプトが hosts 情報と passwd 情報に基づいてホストとユーザーの資格を作成することを示す、次のようなメッセージが表示されます。

     Do you want to continue? (type 'y' to continue, 'n' to exit this script) y populating auto_master table from file /nis+files/auto_master ... auto_master table done. populating auto_home table from file /nis+files/auto_home ... auto_home table done. Credentials have been added for the entries in the hosts and passwd table(s). Each entry was given a default network password (also known as a Secure- RPC password). This password is: nisplus Use this password when the nisclient script requests the network password. Done!

     Secure RPC パスワード (上の例では nisplus) は必ず控えておき、忘れないようにしてください。ネットワークパスワードまたは Secure RPC パスワードを求められたら、ここで控えておいたパスワードを入力します。

     スクリプトは、必要なすべてのファイルを検索し、使用できるファイルからすべてのテーブルを生成します。

   • NIS マップからテーブルを生成する場合、スクリプトが hosts と passwd の情報に基づいてホストとユーザーの資格を作成する際に、次の内容が表示されます。

     Do you want to continue? (type 'y' to continue, 'n' to exit this script) y populating auto_master table from sales.doc.com NIS(YP) domain... auto_master table done. populating auto_home table from file sales.doc.com NIS(YP) domain... auto_home table done. .... Credentials have been added for the entries in the hosts and passwd table(s). Each entry was given a default network password (also known as a Secure-RPC password). This password is: nisplus Use this password when the nisclient script requests the network password. Done!

     Secure RPC パスワード (上の例では nisplus) は必ず控えておき、忘れないようにしてください。ネットワークパスワードまたは Secure RPC パスワードを求められたら、ここで控えておいたパスワードを入力します。

     これですべてのテーブルが生成されました。parse error という警告が表示されるかもしれませんが無視してかまいません。これらのエラーは、NIS+ が特定の NIS マップのフィールドで空の値または予期せぬ値を見つけたことを示します。必要に応じて、スクリプト終了後、データを検証してください。

4. ルートドメインの管理グループに自分自身と他の管理者を追加します (必要に応じて) 。

   たとえば、自分自身のログイン ID が topadm で、他の管理者の ID が secondadmin の場合、次のように入力します。

   master1# nisgrpadm -a admin.doc.com. topadm.doc.com. secondadm.doc.com. Added "topadm.doc.com." to group "admin.doc.com.". Added "secondadm.doc.com." to group "admin.doc.com.".

   上記の nisgrpadm -a コマンドの引数 admin.doc.com. は、グループ名を表し、最初に記述しなければなりません。残りの 2 つの引数は管理者名です。

   ---

   注 -

   この時点で管理グループにユーザーを追加したい場合にだけ、この手順が必要です。ルートサーバーに管理者を追加するには、この時点で行います。NIS+ を構成した後でも、管理グループにユーザーを追加できます。

   ---

   この手順を実行するには、ほかの管理者がデフォルトパスワードを変更するまで待つ必要はありません。しかし、管理グループにほかの管理者を追加するには、その前に passwd テーブルに管理者が登録されていることが必要です。管理グループのメンバーは、ドメインに自分自身を追加しなければ、NIS+ 主体として行動できません。ユーザーの初期設定については、「NIS+ ユーザーを初期設定する方法」を参照してください。また、新規にメンバーが登録されても、管理グループに対する古いキャッシュが破棄された後でなければ有効になりません。

5. 次のコマンドを入力して、ドメインのチェックポイントを実行します。

   master1# nisping -C doc.com. Checkpointing replicas serving directory doc.com. Master server is master1.doc.com. Last update occurred at date Master server is master1.doc.com. checkpoint scheduled on master1.doc.com.

   この手順によって、そのドメインをサポートする全サーバーは、初期設定 (.log) ファイルから新しい情報をテーブルのディスク上のコピーに転送します。ルートドメインの設定が終了したばかりであるため、このルートドメインにはまだ複製が存在せず、この手順はルートマスターサーバーにだけ影響を与えます。

スワップ領域またはディスク領域が不足している場合、サーバーは適切にチェックポイントを実行できませんが、その旨の通知は行われません。スワップ領域またはディスク領域が不足していないか確認するには、niscat コマンドでテーブルの内容を表示します。たとえば、rpc テーブルの内容をチェックするには、次のように入力します。

master1# niscat rpc.org_dir
rpcbind rpcbind 100000
rpcbind portmap 100000
rpcbind sunrpc 100000

スワップ領域が不足していると「チェックポイントを実行できない」という旨のメッセージではなく、次のエラーメッセージが表示されます。

can't list table: Server busy, Try Again.

このメッセージには明示されていませんが、これはスワップ領域の不足を示します。スワップ領域を増やして、再度ドメインのチェックポイントを実行してください。

NIS+ クライアントマシンの設定

ルートマスターサーバーのテーブルがファイルまたは NIS マップから生成されると、NIS+ クライアントマシンを初期設定できます。ルートマスターサーバーは自分のドメインの NIS+ クライアントであるため、ルートマスターサーバーのこれ以上の初期化は必要ありません。この節では、nisclient スクリプトを使用して、デフォルトの設定で NIS+ クライアントを初期設定する方法を説明します。

• 前の例で使用したドメイン doc.com.

• 前の例で、nispopulate スクリプトによって作成された Secure RPC パスワード (ネットワークパスワードとも呼ばれる。デフォルトは nisplus)

「新しいクライアントマシンを初期設定する方法」で使用する -i オプションでは、DNS を使用してホスト名を検索するような NIS+ クライアントを構成しません。管理者は、明確にクライアントのネームサービススイッチファイルに DNS を指定する必要があります。DNS によるホスト名の検索については、『Solaris ネーミングの管理』およびこのマニュアルの第 1 章「ネームサービススイッチの設定」を参照してください。

nisclient(1M) を実行するための前提条件

nisclient スクリプトを使用するには、次の条件が必要です。

• ドメインがすでに構成されていて、そのマスターサーバーが実行されている

• ドメインのマスターサーバーのテーブルが生成されている。(少なくとも、hosts テーブルには新しいクライアントマシンのエントリが必要)

• NIS+ クライアントとなるマシンにスーパーユーザーとしてログインしている。この例では、新しいクライアントマシン名は client1

必要な情報

次の情報が必要です。

• ドメイン名

• デフォルトの Secure RPC パスワード (nisplus)

• クライアントとなるワークステーションの root のパスワード

• クライアントのホームドメインにある NIS+ サーバーの IP アドレス

• DES 認証を使用する場合には、マスターサーバー上で、Diffie-Hellman キー長が使用される。nisauthconf を使用して、マスターサーバー上で Diffie-Hellman キー長を確認する

新しいクライアントマシンを初期設定する方法

1. DES 認証を使用する場合には、オプションで、Diffie-Hellman キー長を指定します。

   マスターサーバー上で以下を入力します。

   nisauthconf

   クライアントマシン上で nisauthconf コマンドを実行するときは、上記コマンドの出力を引数として使用します。たとえば、マスターサーバー上で nisauthconf を実行すると

   dh640dh-0 des

   と出力される場合には、クライアントマシン上で次のコマンドを入力します。

   nisauthconf dh640dh-0 des

2. 次のコマンドを入力して、新しいクライアントマシン上で新しいクライアントを初期設定します。

   -i オプションはクライアントを初期設定します。-d オプションは新しい NIS+ ドメイン名を指定します。ドメイン名が指定されない場合、そのデフォルトは現在のドメイン名となります。-h オプションは NIS+ サーバーのホスト名を指定します。

   client1# nisclient -i -d doc.com. -h master1 Initializing client client1 for domain "doc.com.". Once initialization is done, you will need to reboot your machine. Do you want to continue? (type 'y' to continue, 'n' to exit this script)

3. y を入力します。

   n を入力するとスクリプトが終了します。クライアントの /etc/hosts ファイルにルートサーバーのエントリがない場合、スクリプトはルートサーバーの IP アドレスの入力を指示します。

   Do you want to continue? (type 'y' to continue, 'n' to exit this script) y Type server master1's IP address:

4. 正しい IP アドレスを入力して、Return キーを押します。

   この例では、アドレス 123.123.123.123 を使用します。

   Type server master1's IP address: 123.123.123.123 setting up the domain information... setting up the name service switch information... At the prompt below, type the network password (also known as the Secure-RPC password) that you obtained either from your administrator or from running the nispopulate script. Please enter the Secure-RPC password for root:

5. Secure RPC パスワード (ネットワークパスワード) がルートのログインパスワードと異なる場合のみ、Secure RPC パスワードを入力します。

   この例では、デフォルトの nisplus を使用します。

   パスワードは画面に表示されません。入力を誤った場合、正しいパスワードを入力するよう要求されます。2 回目も入力を誤った場合、スクリプトが終了し、前回のネットワークサービスが復元されます。この場合、スクリプトを再度実行してください。

   Please enter the login password for root:

6. このクライアントマシンの root パスワードを入力します。

   パスワードは画面に表示されません。ネットワークパスワードと root のログインパスワードが同じ場合、root のログインパスワードの入力要求はありません。

   root パスワードを入力すると、このマシンの資格が変更されます。ここで、このマシンでは RPC パスワードと root パスワードが同じになります。

   Please enter the login password for root: Wrote secret key into /etc/.rootkey Your network password has been changed to your login one. Your network and login passwords are now the same. Client initialization completed!! Please reboot your machine for changes to take effect.

7. クライアントマシンを再起動します。

   ここで行なった変更は、マシンを再起動すると有効になります。

   以上の手順により、この NIS+ クライアントマシンのユーザーを NIS+ ドメインに追加できるようになりました。

クライアントマシンの追加作成

これまでに説明したクライアントの初期設定手順を、必要な各マシンで繰り返します。ほかのドメインのクライアントを初期設定するには、ドメイン名とマスターサーバー名を適宜変更して、上記の手順を繰り返します。

この章で説明する NIS+ ドメインのサンプルでは、ドメイン doc.com 内の 4 台のクライアントを初期設定すると想定しています。そして、このうち 2 台のクライアントを非ルート (ルート以外の) NIS+ サーバーとして構成し、3 番目のクライアントを doc.com ドメインのルートマスターサーバーのルート複製サーバーとして構成します。

システムをサーバーにするには、システムをどの種類のサーバーにするにしても、事前にシステムを親ドメインのクライアントにしておく必要があります。

NIS+ クライアントユーザーの初期設定

マシンが NIS+ クライアントになったら、そのマシンのユーザーは自分自身を NIS+ ドメインに追加しなければなりません。ユーザーをドメインに追加するということは、Secure RPC パスワードをそのユーザーのログインパスワードに変更することを意味します。実際には、ユーザーのパスワードと Secure RPC パスワードが同じになります。この手順では nisclient(1M) スクリプトを使用します。

nisclient(1M) を実行するための前提条件

nisclient(1M) スクリプトを使用してユーザーを初期設定するには、次の条件が必要です。

• ドメインがすでに構成され、そのマスターサーバーが実行されている

• ドメインのマスターサーバーのテーブルが生成されている。少なくとも、hosts テーブルには新しいクライアントマシンのエントリが必要

• ドメイン内のクライアントマシンが初期設定されている

• クライアントマシンに「ユーザー」としてログインしている (この例では、ユーザー名は user1)

• DES 認証を使用する場合には、クライアントマシンは、マスターサーバーと同じ Diffie-Hellman キー設定を使用

必要な情報

次の情報が必要です。

• ユーザーのログイン名 (この例では user1)

• デフォルトの Secure RPC パスワード (この例では nisplus)

• NIS+ クライアントになるユーザーのログインパスワード

NIS+ ユーザーを初期設定する方法

1. NIS+ クライアントになるユーザーとしてログインして、次のように nisclient コマンドを入力します。

   user1prompt% nisclient -u At the prompt below, type the network password (also known as the Secure-RPC password) that you obtained either from your administrator or from running the nispopulate script. Please enter the Secure-RPC password for user1:

2. Secure RPC パスワード (この例では nisplus) を入力します。

   入力したパスワードは画面に表示されません。

   Please enter the login password for user1:

3. ユーザーのログインパスワードを入力し、Return キーを押します。

   パスワードは画面に表示されません。

   Your network password has been changed to your login one. Your network and login passwords are now the same

   これで、このユーザーは NIS+ クライアントになりました。全ユーザーを NIS+ クライアントにする必要があります。

NIS+ サーバーの設定

初期設定が終了したら、どのクライアントマシンも次の NIS+ サーバーに変更できます。

• ルート複製サーバー (ルートマスターサーバー上にある NIS+ テーブルのコピーを格納する)

• ルートドメインのサブドメインのマスターサーバー

• ルートドメインのサブドメインのマスターサーバーの複製サーバー

NIS+ マスタールートサーバーは 1 つしか持てません。ルート NIS+ サーバーは特殊な NIS+ サーバーです。この節ではルートマスターサーバーの構成方法は説明しません。詳細は、「NIS+ ルートサーバーの設定」を参照してください。

サーバーを構成する場合、次の 3 つの設定があります。

• NIS と互換性なし

• NIS と互換性あり

• NIS との互換性と DNS 転送 − NIS+ 名前空間に SunOS 4.x クライアントが存在する場合にだけ、DNS 転送を設定する必要があります。NIS 互換モードの使用方法の詳細は、『NIS+ への移行』を参照してください。

サーバーとその複製は、NIS 互換についての設定が同じでなければなりません。設定が異なる場合、ネットワーク情報を受信するために NIS 互換の設定を必要とするクライアントは、必要なサーバーまたは複製サーバーを使用できなければ、この情報を受信できません。

この例では、マシン client1 がサーバーに変更されます。この手順では、NIS+ スクリプトの代わりに NIS+ コマンド rpc.nisd を使用します。

rpc.nisd を実行するための前提条件

rpc.nisd を実行するには、次の条件が必要です。

• ドメインがすでに構成され、そのマスターサーバーが実行されている

• ドメインのマスターサーバーのテーブルが生成されている。少なくとも、hosts テーブルには新しいクライアントマシンのエントリが必要

• ドメイン内のクライアントマシンが初期設定されている

• クライアントマシンに root としてログインしている。(この例では、クライアントマシン名は client1)

• DES 認証を使用する場合には、クライアントマシンはマスターサーバーと同じ Diffie-Hellman キー設定を使用する必要があります。

必要な情報

サーバーに変換するクライアントのスーパーユーザーのパスワードが必要です。

クライアントを NIS+ サーバーとして構成する方法

クライアントをサーバーとして構成するには、次の手順のどれかを実行します。この手順では、サーバーと同じ名前のディレクトリを作成し、サーバーの初期設定ファイルを作成します。これらは /var/nis に置かれます。

同じドメイン内のすべてのサーバーは、NIS 互換の設定が同じでなければなりません。たとえば、マスターサーバーが NIS 互換である場合、その複製も NIS 互換でなければなりません。

NIS と互換性のない NIS+ サーバーを構成する方法

NIS と互換性のないサーバーを構成するには、次のコマンドを入力します。

client1# rpc.nisd

NIS と互換性のある NIS+ サーバーを構成する方法

1. サーバーの /etc/init.d/rpc ファイルを編集して、文字列 -EMULYP="-Y" を含む行のコメントアウトを解除して有効にします。

   コメントアウトを解除するには、行の先頭から # を削除します。

2. スーパーユーザーとして、次のように入力します。

   client1# rpc.nisd -Y

NIS との互換性と DNS 転送機能を備えた NIS+ サーバーを構成する方法

次の手順を実行して、DNS 転送機能と NIS+ との互換性の両方の機能を備えた NIS+ サーバーを構成します。SunOS 4.x クライアントをサポートするには、両方の機能が必要です。

1. サーバーの /etc/init.d/rpc ファイルを編集します。文字列 -EMULYP="-Y" を含む行のコメントアウトを解除 (行の先頭から # を削除) して有効にします。

   コメントアウトを解除するには、行の先頭から # を削除します。

2. 上の行の引用符で囲まれた中に次のように -B を追加します。

   -EMULYP="-Y -B"

3. 次のコマンドをスーパーユーザーとして入力します。

   client1# rpc.nisd -Y -B

   これで、このサーバーはドメインのマスターまたは複製として指定できます。

サーバーの追加作成

これまでのクライアントをサーバーに変更する手順を、必要なクライアントマシンごとに繰り返します。

この章で説明する NIS+ サンプルドメインは、3 台のクライアントをサーバーに変更すると想定しています。そして、サーバーの 1 台をルート複製サーバーに、もう 1 台を新しいサブドメインのマスターに、そして 3 台目を新しいサブドメインのマスターの複製に構成します。

ルート複製サーバーの作成

NIS+ サービスを常に利用可能な状態にしておくため、ルート複製サーバーを少なくとも 1 つは作成しておくことをお勧めします。複製サーバーを作成すると複数のサーバーが存在することになり、要求の処理を分散させることができるため、ネットワーク要求の処理も高速化されます。

パフォーマンス上の理由から、1 つのドメインに多くの複製サーバーを置くことはお勧めできません。ただし、ネットワークが複数のサブネットで構成されている場合、あるいは広域ネットワーク (WAN) でリモートサイトに接続されている場合には、複製サーバーを追加した方がいい場合があります。

• 「サブネット」

  複数のサブネットで構成されているドメインの場合、各サブネットに複製サーバーを少なくとも 1 つは作成することをお勧めします。そうしておけば、ネットワーク間の通信が一時的に途絶しても、接続が回復するまでの間、サブネットレベルの機能は維持されます。

• 「リモートサイト」

  WAN によりリモートサイトに接続されているドメインの場合、WAN 接続の両側に複製サーバーを少なくとも 1 つは作成することをお勧めします。組織論的な見地からすれば、同一の NIS+ ドメインに物理的に離れた 2 つのサイトがあるのは意味のあることです。たとえば、ドメイン内のマスターサーバーとその複製サーバーがすべて一方のサイトに置かれている場合、そのサイトともう一方のサイトとの間の NIS+ ネットワークトラフィックが増大するのは目に見えています。もう一方のサイトにも複製サーバーを置いておけば、ネットワークトラフィックが減るはずです。複製サーバーの分散配置については、『NIS+ への移行』を参照してください。

最適な複製サーバーの数については、『Solaris ネーミングの管理』を参照してください。

「ルート複製サーバーを作成する方法」では、マシン client1 を doc.com. ドメインのルート複製サーバーとして構成します。この手順では、NIS+ スクリプトの nisserver を使用します。「NIS+ コマンドによる複製サーバーの構成」で説明しているように NIS+ コマンドを使用して複製サーバーを構成することもできます。

nisserver を実行するための前提条件

nisserver を実行してルート複製サーバーを作成するには、次の条件が必要です。

• ドメインがすでに構成され、マスターサーバーが稼動している

• マスターサーバーのテーブルが生成されている。少なくとも、hosts テーブルには新しいクライアントマシンのエントリが 1 つは必要

• 新たに作成した複製サーバーを doc.com. ドメインのクライアントマシンとして初期設定している。(具体的な手順については、「NIS+ クライアントマシンの設定」を参照)

• 新たに作成した複製サーバー上で rpc.nisd(1M) を起動している。(具体的な手順については、「NIS+ サーバーの設定」を参照)

• ルートマスターサーバーにルートとしてログインしている。(この例では、ルートマスターマシン名は master1)

必要な情報

次の情報が必要です。

• ドメイン名

• クライアントマシン名 (この例では、client1 )

• ルートマスターサーバーのスーパーユーザーのパスワード

ルート複製サーバーを作成する方法

1. NIS+ ドメインのルートマスターサーバー上でスーパーユーザー (root) として次のように入力して、ルート複製サーバーを作成します。

   master1# nisserver -R -d doc.com. -h client1 This script sets up a NIS+ replica server for domain doc.com. Domain name: :doc.com. NIS+ server : :client1 Is this information correct? (type 'y' to accept, 'n' to change)

   -R オプションは複製サーバーが構成されることを示します。-d オプションは NIS+ ドメイン名 (このサンプルでは doc.com.) を指定します。-h オプションはルート複製サーバーとなるクライアントマシン (この例では client1) を指定します。

2. y を入力して続行します。

   n を入力すると、スクリプトは正しい情報の入力を要求します。n を入力した場合の操作については、「誤った情報を変更する方法」を参照してください。

   Is this information correct? (type 'y' to accept, 'n' to change) y This script will set up machine "client1" as an NIS+ replica server for domain doc.com. without NIS compatibility. The NIS+ server daemon, rpc.nisd, must be running on client1 with the proper options to serve this domain. Do you want to continue? (type 'y' to continue, 'n' to exit this script)

3. y を入力して続行します。

   n を入力するとスクリプトは問題なく終了します。クライアントマシン上で rpc.nisd が動作していない場合、スクリプトは自動的に終了します。

   Is this information correct? (type 'y' to continue, 'n' to exit this script) y The system client1 is now configured as a replica server for domain doc.com.. The NIS+ server daemon, rpc.nisd, must be running on client1 with the proper options to serve this domain. If you want to run this replica in NIS (YP) compatibility mode, edit the /etc/init.d/rpc file on the replica server ' to uncomment the line which sets EMULYP to "-Y". This will ensure that rpc.nisd will boot in NIS-compatibility mode. Then, restart rpc.nisd with the "-Y" option. These actions should be taken after this script completes.

   ---

   注 -

   上記のメッセージはオプションの手順に関するものです。NIS (YP) 互換ではないルート複製サーバーを NIS 互換にする場合にだけ、/etc/init.d/rpc ファイルを変更します。つまり、NIS 互換のサーバーとして構成されていないルート複製サーバーで NIS クライアント要求を実行する場合にだけ、このファイルの変更が必要になります。NIS 互換サーバーの作成については、「クライアントを NIS+ サーバーとして構成する方法」を参照してください。

   ---

4. [必要に応じて] 複製サーバーを NIS (YP) 互換モードで稼動させることができるように構成します。

   複製サーバーを NIS 互換モードで稼動させるには、次の手順に従います。

   1. rpc.nisd を終了します。

   2. サーバーの /etc/init.d/rpc ファイルをオープンして、EMULYP が -Y に設定されている行のコメントアウトを解除します。

      具体的には、EMULYP 行の先頭の # を削除します。

   3. rpc.nisd を再起動します。

5. 新たに作成した複製サーバーに名前空間データをロードします。

   これには次の 2 つの方法があります。

   • NIS+ の保存と復元の機能を使用して、マスターサーバーのデータを保存し、作成した複製サーバーに復元します (こちらの方法をお勧めします)。具体的な手順については、「nisrestore を使って名前空間データをロードする」を参照してください。

   • nisping を実行します。

     nisping を実行すると、マスターサーバーのすべての NIS+ データを複製サーバーに完全に再同期させることができます。しかし、大きな名前空間の場合、処理に長時間かかることがあります。その間、マスターサーバーはビジーになって応答が遅く、また作成した複製サーバーはまだ NIS+ 要求に応答できない状態になることがあります。具体的な手順については、「nisping を使って名前空間データをロードする方法」を参照してください。

   名前空間データのロードが終了すれば、マシン client1 は NIS+ ルート複製サーバーとなります。この新しいルート複製サーバーは、ルートドメインのクライアントからの要求を処理できます。これでドメインで使用可能なサーバーが 2 台となるため、要求を速く処理できます。

   これらの手順に従って、複製サーバーを必要なだけ作ることができます。同じ手順を使ってサブドメインに複製サーバーを作ることもできます。

Multihomed NIS+ 複製サーバーの設定方法

Multihomed NIS+ サーバーを設定する手順は、単一インタフェースサーバーの設定手順と同じです。唯一の相違点は、ローカルの /etc/hosts ファイルと NIS+ の hosts テーブル内に定義する必要があるインタフェースが、単一インタフェースサーバーよりも多いという点です。ホスト情報を定義したら、nisclient と nisserver スクリプトを使用して Multihomed NIS+ サーバーを設定します。

Multihomed NIS+ サーバーを設定する場合は、サーバーの主体名はシステムのノード名と同じにする必要があります。これは、Secured RPC と nisclient を同時に使用する際の必要条件です。

• Secured RPC は、ノード名を使用して認証に必要なネット名を作成する

• nisclient は、主体名を使用してクライアントの資格を作成する

次に、NIS+ ルートマスター以外のサーバーの設定手順を示します。以下の例では、ルートドメインの複製を作成しています。muitihomed ルートサーバーの設定方法については、「Multihomed NIS+ ルートマスターサーバーの設定方法」を参照してください。

1. サーバーのホスト情報を hosts ファイル内に追加します。たとえば、3 つのインタフェースを装備した hostB システムの場合は、次のように入力します。

   192.168.11.y hostB hostB-11 192.168.12.x hostB hostB-12 192.168.14.z hostB hostB-14

2. ルートマスターサーバー上で、nispopulate または nisaddent のどちらかを使用して、新しいホスト情報を hosts テーブル内にロードします。たとえば、次のように入力します。

   hostA# nispopulate -F -d sun.com hosts

   この例では、sun.com は NIS+ ルートドメイン名を表しています。自分の NIS+ ルートドメイン名を指定して nispopulate コマンドを実行してください。

3. ルートマスターサーバー上で、nisclient スクリプトを使用して新しいクライアントの資格を作成します。たとえば、次のように入力します。

   hostA# nisclient -c -d sun.com hostB

   この例では、sun.com は ルートドメイン名を表しています。自分のルートドメイン名を指定して nisclient コマンドを実行してください。

4. ルートマスター以外のサーバー上で、新しいサーバーがまだ稼動していない場合は、nisclient を使用して新しいサーバーを起動し、このマシンを NIS+ クライアントとして初期化します。たとえば、次のように入力します。

   hostB# nisclient -i -d sun.com

   この例では、sun.com は ルートドメイン名を表しています。自分のルートドメイン名を指定して nisclient コマンドを実行してください。

5. ルートマスター上で、nisserver を使用してルートマスター以外のサーバーを設定します。たとえば、次のように入力します。

   hostA# nisserver -M -d eng.sun.com -h hostB.sun.com.

   この例では、eng.sun.com は NIS+ ドメイン名を表し、hostB.sun.com は NIS+ サーバーの完全指定ホスト名を表しています。nisserver コマンドは、自分の NIS+ ドメイン名と NIS+ サーバーの完全指定ホスト名を指定して実行してください。

6. ルートマスターサーバー上で、nisserver を使用して複製サーバーを設定します。たとえば、次のように入力します。

   hostA# nisserver -R -d sun.com -h hostB.sun.com.

   この例では、sun.com は 複製サーバーを表し、hostB.sun.com は NIS+ サーバーの完全指定ホスト名を表しています。nisserver コマンドは、自分の複製サーバー名と NIS+ サーバーの完全指定ホスト名を指定して実行してください。

multihomed NIS+ 複製サーバーの設定が完了したら、このあとの設定手順は、単一インタフェースのサーバーの設定手順とまったく同じです。

サブドメインの作成

この節では、ルート以外の新しいドメイン (サブドメイン) のマスターサーバーの作成方法を説明します。この新しいドメインは doc.com. ドメインのサブドメインとなります。NIS+ の階層構造によって、組織構造に合わせたドメイン構造を作成できます。

この例では、マシン client2 が sub.doc.com という新しいドメインのマスターサーバーに変更されます。ここでは NIS+ スクリプトの nisserver を使用します。

nisserver を実行するための前提条件

nisserver を実行して、新しいサブドメインのマスターサーバーを作成するには、次の条件が必要です。

• 親ドメインがすでに構成され、そのマスターサーバーが実行されている

• 親ドメインのテーブルが生成されている。少なくとも、hosts テーブルに新しいクライアントマシンのエントリが必要

• 親ドメイン内の新しいクライアントマシンが初期設定されている

• クライアント上で rpc.nisd が起動されている

• 新しいドメインを追加するための適切なアクセス権がある。この例では、親マスターサーバーに root としてログインする。(この例では、親マスターマシン名は master1)

必要な情報

次の情報が必要です。

• 新しいサブドメインの名前 − 親ドメインの名前を含んだ新しいドメイン名。書式は、「 newdomain.rootdomain」となる

• クライアントマシンの名前 (この例では、client2)

• 親マスターサーバーのスーパーユーザーパスワード

「新しい非ルートドメインを作成する方法」では、新しいサブドメインを sub.doc.com とします。

Solaris リリース 2.6 および初期のリリースでは、どんな NIS+ クライアントでも、そのサービスの提供先となるドメインの上位ドメインに置かれている限り、NIS+ マスターサーバーに変更できます。たとえば、ドメイン sales.doc.com 内の NIS+ クライアントは、west.sales.doc.com や alameda.west.sales.doc.com などの下位の階層に属するドメインにサービスを提供できます。しかし、このクライアントは doc.com ドメインにはサービスを提供できません。その理由は、doc.com がドメイン sales.doc.com より上位の階層にあるためです。ただし、ルート複製サーバーはこのルールの唯一の例外であり、サービス提供先のドメインのクライアントです。

Solaris リリース 7 では、ドメインの NIS+ サーバーを、それがサービスしている同じドメイン内に置くことができます。これによって、サーバーとドメイン階層の他の部分との通信を安全な状態に保ったまま、サーバーのドメイン名をそのクライアントが使用しているドメイン名と同じに設定することができます。nisinit の -k オプションおよび nisserver の -d オプションを参照してください。

新しい非ルートドメインを作成する方法

1. NIS+ ドメインのルートマスターサーバー上のスーパーユーザー (root) として次のように入力し、新しい非ルートドメインマスターサーバーを作成します。

   -M オプションは、新しい非ルートドメインのマスターサーバーを作成することを示します。-d オプションは、ドメイン名 (この例では、sales.doc.com.) を指定します。-h オプションは、新しいドメインのマスターサーバーになるクライアントマシン (この例では、client2) を指定します。

   master1# nisserver -M -d sales.doc.com. -h client2 This script sets up a non-root NIS+ master server for domain sales.doc.com Domain name : sales.doc.com. NIS+ server : client2 NIS+ group : admin.sales.doc.com. NIS (YP) compatibility : OFF Security level : 2=DES Is this information correct? (type 'y' to accept, 'n' to change)

   新しい非ルートドメインのマスターサーバーは、ルートサーバーと同じデフォルト値によって作成されます。NIS+ グループ、NIS (YP) 互換性、およびセキュリティレベルの詳細は、「ルートマスターサーバーを作成する方法」を参照してください。

2. y を入力して操作を続けます。

   n を入力すると、スクリプトは正しい情報の入力を要求します。n を入力した場合の操作については、「誤った情報を変更する方法」を参照してください。

   Is this information correct? (type 'y' to accept, 'n' to change) y This script sets up machine "client2" as an NIS+ non- root master server for domain sales.doc.com. Do you want to continue? (type 'y' to continue, 'n' to exit this script)

3. y を入力して操作を続けます。

   n を入力すると、スクリプトは安全に終了します。クライアントマシン上で rpc.nisd が動作していない場合、スクリプトは自動的に終了します。

   Do you want to continue? (type 'y' to continue, 'n' to exit this script) y running nissetup ... org_dir.sales.doc.com. created groups_dir.sales.doc.com. created ... ... setting NIS+ group admin.sales.doc.com. ... The system client2 is now configured as a non-root server for domain sales.doc.com. You can now populate the standard NIS+ tables by using the nispopulate or /usr/lib/nis/nisaddent commands.

   これで、マシン client2 は sales.doc.com. ドメインのマスターサーバーになりました。sales.doc.com. ドメインは doc.com. ドメインのサブドメインです。マシン client2 は、依然としてルートドメイン doc.com. のクライアントであり、しかも sales.doc.com. ドメインのマスターサーバーでもあります。

   これで、sales.doc.com. ドメインの新しいマスターサーバーに標準の NIS+ テーブルを生成できます。

ドメインの追加作成

サーバーを新しい非ルートドメインのマスターサーバーに変更する前述の手順を、必要な各サーバーマシンに対し繰り返します。新しいマスターサーバーはすべて新しいドメインです。ドメイン構造の計画を立ててから、NIS+ 名前空間の作成を始めます。NIS+ 階層の計画については、第 2 章「NIS+ 入門」を参照してください。

新しいサブドメインのテーブルの生成

新しいドメインを作成したら、そのマスターサーバーの標準の NIS+ テーブルを生成しなければなりません。新しいマスターサーバーのテーブルを生成するには、ルートマスターサーバーのテーブルを生成するときと同じ手順を使用します。大きな違いは、nispopulate(1M) スクリプトが、ルートマスターサーバー上ではなく、新しいマスターサーバー上で実行されることです。また、ドメイン名、およびファイルパス、または NIS サーバー名も変わることがあります。

この例では、新しいドメイン (sales.doc.com.) のテーブルを生成します。

nispopulate を実行するための前提条件

スクリプト nispopulate を実行して新しいマスターサーバーのテーブルを生成するには、次の条件が必要です。

• ファイル内の情報は、それがロードされるテーブルに合わせて書式設定されていなければなりません。

  • スクリプトを実行する前に、データを読み込むローカルの /etc 内の各ファイルまたは NIS マップを調べます。不正なエントリがないことを確認します。正しいデータが、所定の場所に正しい書式で記録されていることを確認します。エントリのうち、古いもの、無効なもの、破損しているものは削除します。また、不完全なエントリや一部のみのエントリも削除します。変更を完了した後は、いつでも各エントリを追加できます。後から追加する方が、不完全なエントリや破損したエントリを読み込むよりも簡単です。

  • 初めてネットワークを設定する場合、十分なネットワーク情報がどこにも格納されていないことがあります。このような場合、まずネットワーク情報を集め、「入力ファイル」に手入力する必要があります。このファイルは、基本的に /etc 内のファイルに対応するものです。

• 安全のため、/etc 内のファイルのコピーを作成します。実際のファイルは使用せずに、作成したコピーを使用してテーブルを生成してください。たとえば、この例では /nis+files というディレクトリ内のファイルを使用します。

• コピーした NIS テーブルファイルのうち、passwd、shadow、aliases、hosts の各ファイルには、名前空間全体に分散させるとセキュリティ上問題がある項目があるので、それらを編集します。たとえば、次に示す行をローカル側の passwd ファイルのコピーから削除して、名前空間からはそれらの情報にアクセスできないようにします。

root:x:0:1:0000-Admin(0000):/:/sbin/sh
daemon:x:1:3:0000-Admin(0000):/:
bin:x:3:5:0000-Admin(0000):/usr/bin:
sys:x:3:3:0000-Admin(0000):/:
adm:x:4:4:0000-Admin(0000):/var/adm:
lp:x:78:9:0000-lp(0000):/usr/spool/lp:
smtp:x:0:0:mail daemon user:/:
uucp:x:5:5:0000-uucp(0000):/usr/lib/uucp:
nuucp:x:7:8:0000-
uucp (0000):/var/spool/uucppublic:/usr/lib/uucp/uucico
listen:x:22:6:Network Admin:/usr/net/nls:
nobody:x:60000:60000:uid no body:/:
noaccess:x:60002:60002:uid no access:/:

• ドメインがすでに構成され、そのマスターサーバーが実行されていなければなりません。

• ドメインのサーバーには、新しいテーブル情報を収容できるだけの十分なディスク空き領域が必要です。

• NIS+ 主体としてログインしていて、しかも指定されたドメイン内の NIS+ テーブルに対する書き込み権が必要です。この例では、マシン client2 上の root でなければなりません。

システム上の /tmp 領域が不足する場合、nispopulate スクリプトは異常終了することがあります。これを防止するには、環境変数 TMPDIR に別のディレクトリを設定します。TMPDIR に有効なディレクトリが設定されていない場合、スクリプトは代わりに /tmp ディレクトリを使用します。

必要な情報

ファイルから生成する場合、次の情報が必要です。

• 新しい NIS+ ドメイン名

• データが転送される、適切に編集されたテキストファイルのパス

• NIS+ マスターサーバーの root パスワード

NIS マップから生成する場合、次の情報が必要です。

• 新しい NIS+ ドメイン名

• NIS ドメイン名

• NIS サーバー名

• NIS サーバーの IP アドレス

• NIS+ マスターサーバーの root パスワード

NIS ドメインの名前は大文字と小文字を区別しますが、NIS+ ドメインの名前は区別しません。

マスターサーバーテーブルを生成する方法

この手順は、「ルートマスターサーバーのテーブルを生成する方法」の手順と実質的に同じなので、この例では、新しいドメイン (sales.doc.com.) のテーブルを生成するための入力についてだけ説明します。この手順の詳細は、「ルートマスターサーバーのテーブルを生成する方法」を参照してください。

このスクリプトは、ルートマスターサーバーではなく、新しいドメインのマスターサーバー上で実行しなければなりません。

次のいずれかの方法で、新しいマスターサーバー上にマスターサーバーテーブルを生成します。

• ファイルからマスターサーバーテーブルを生成する

• NIS マップからマスターサーバーテーブルを生成する

実行結果が一度に表示しきれないことがあるので、どちらの方法で行うにしてもスクロール可能なウィンドウを使用してください。

テーブルをファイルから生成する方法

ファイルからマスターサーバーテーブルを生成するには、次のコマンドを入力します。

client2# nispopulate -F -p /nis+files -d sales.doc.com.
NIS+ domain name : sales.doc.com.
Directory Path : /nis+files
Is this information correct? (type 'y' to accept, 'n' to change

テーブルを NIS マップから生成する方法

NIS マップからマスターサーバーテーブルを生成するには、次のコマンドを入力します。

client2# nispopulate -Y -d sales.doc.com. -h businessmachine -a 
IP_addr_of_NIS_server -y business.doc.com
NIS+ Domain name : sales.doc.com.
NIS (YP) domain : business.doc.com
NIS (YP) server hostname : businessmachine
Is this information correct? (type 'y' to accept, 'n' to change)

このスクリプトの残りの出力については、「ルートマスターサーバーのテーブルを生成する方法」を参照してください。

サブドメイン複製サーバーの作成

ルートドメイン複製サーバーに対して適用される規則は、サブドメイン複製サーバーに対しても適用されます ( 「ルート複製サーバーの作成」を参照)。

サブドメインの複製サーバーの作成には、ルート複製サーバーの作成と同じ手順を使用します。このルート複製サーバーの作成とサブドメイン複製サーバーの作成との大きな違いは、サブドメイン複製サーバーに変更しようとしているマシンが、複製サーバーとしてサービスを提供することになるドメインより上位のドメインのクライアントのままであることです。この例では、新しいドメインの複製サーバーを作成するための入力だけを示します。スクリプトの残りの出力については、「ルート複製サーバーを作成する方法」を参照してください。

nisserver を実行するための前提条件

nisserver を実行して複製サーバーを作成するには、次の条件が必要です。

• ドメインがすでに設定され、そのマスターサーバーが実行されている

• ドメインのテーブルが生成されている。少なくとも、hosts テーブルには新しいクライアントマシンのエントリが必要

• 親ドメイン内のクライアントマシンが初期設定されている

• クライアント上で rpc.nisd が起動されている

• マスターサーバーにルートとしてログインしている (この例では、マスターマシン名は client2)

必要な情報

• ドメイン名

• クライアントマシン名 (この例では、client3)

• ルートマスターサーバーのスーパーユーザーのパスワード

複製サーバーを作成する方法

複製サーバーを作成するには、NIS+ ドメインのマスターサーバー上でスーパーユーザー (root) として、nisserver -R コマンドを実行します。

client2# nisserver -R -d sales.doc.com. -h client3 This script sets up a NIS+ replica server for domain sales.doc.com. Domain name :sales.doc.com. NIS+ server :client Is this information correct? (type 'y' to accept, 'n' to change)

この例では、client2 がマスターサーバーです。-R オプションは、複製サーバーを構成することを示します。-d オプションは NIS+ ドメイン名 (ここでは、sales.doc.com.) を指定します。-h オプションは複製サーバーとなるクライアントマシン (ここでは client3) を指定します。なお、このマシンは依然として doc.com. ドメインのクライアントであり、sales.doc.com. ドメインのクライアントではありません。

このスクリプトの残りの出力については、「ルート複製サーバーを作成する方法」を参照してください。

サブドメインの NIS+ クライアントマシンの初期設定

マスターサーバーのテーブルをファイルまたは NIS マップから生成すれば、NIS+ クライアントマシンを初期設定できます。この節では、デフォルト設定の nisclient スクリプトを使用して、新しいドメイン内の NIS+ クライアントを初期設定する方法を説明します。NIS+ クライアントマシンは、NIS+ マスターサーバーとは別のワークステーションです。

「新しいサブドメインクライアントマシンを初期設定する方法」で使用される -i オプションは、NIS+ クライアントを DNS を必要とするホスト名の解決ができるようには構成しません。DNS を使用する場合には、ネームサービススイッチファイルの中でクライアント用に、DNS を明確に指定しなければなりません。DNS によるホスト名の解決については、「DNS を使用できるようにする」を参照してください。

新しいドメイン内のクライアントを初期設定するには、ルートドメイン内のクライアントの初期設定と同じ手順を使用します。この例では、新しいドメインのクライアントを初期設定するための入力だけを示します。スクリプトの残りの出力については、「新しいクライアントマシンを初期設定する方法」を参照してください。

nisclient を実行するための前提条件

nisclient スクリプトを使用してユーザーを初期設定するには、次の条件が必要です。

• ドメインがすでに構成され、そのマスターサーバーが実行されている

• ドメインのマスターサーバーのテーブルが生成されている。少なくとも、hosts テーブルには新しいクライアントマシンのエントリが必要

• ドメイン内のクライアントマシンが初期設定されている

• クライアントマシンに「ユーザー」としてログインしている (この例では、ユーザーの名前は user1)

必要な情報

次の情報が必要です。

• ドメイン名 (この例では、sales.doc.com.)

• デフォルトの Secure RPC パスワード (nisplus)

• クライアントになるワークステーションの root パスワード

• クライアントのホームドメイン内の NIS+ サーバーの IP アドレス (この例では、マスターサーバー client2 のアドレス)

新しいサブドメインクライアントマシンを初期設定する方法

新しいクライアントマシン上で新しいクライアントを初期設定するには、スーパーユーザーとして次のコマンドを入力します。

subclient1# nisclient -i -d sales.doc.com. -h client2 Initializing client subclient1 for domain "sales.doc.com.". Once initialization is done, you will need to reboot your machine. Do you want to continue? (type 'Y' to continue, 'N' to exit this script)

-i オプションはクライアントを初期設定します。-d オプションは新しい NIS+ ドメイン名を指定します。ドメイン名が指定されない場合、現在のドメイン名がデフォルトになります。-h オプションは NIS+ サーバーのホスト名を指定します。

このスクリプトの残りの出力については、「新しいクライアントマシンを初期設定する方法」を参照してください。

サブドメインの NIS+ クライアントユーザーの初期設定

新しいドメイン内のユーザーを初期設定するには、ルートドメイン内のユーザーを初期設定する場合と同じ手順 (nisclient) を使用します。全ユーザーが NIS+ クライアントにならなければなりません。この例では、新しいドメインのユーザーを初期設定するための入力だけを示します。スクリプトの残りの出力については、「NIS+ ユーザーを初期設定する方法」を参照してください。

nisclient(1M) を実行するための前提条件

nisclient スクリプトを使用してユーザーを初期設定するには、次の条件が必要です。

• ドメインがすでに構成され、そのマスターサーバーが実行されている

• ドメインのマスターサーバーのテーブルが生成されている。少なくとも、hosts テーブルには新しいクライアントマシンのエントリが必要

• ドメイン内のクライアントマシンが初期設定されている

• クライアントマシンに「ユーザー」としてログインしている (この例では、ユーザー名は user2)

必要な情報

次の情報が必要です。

• ユーザーのログイン名 (この例では、user2)

• デフォルトのネットワークパスワード (この例では、nisplus)

• NIS+ クライアントになるユーザーのログインパスワード

NIS+ サブドメインユーザーを初期設定する方法

NIS+ クライアントとなるには、ユーザーとしてログインして、次のコマンドを実行します。

user2prompt% nisclient -u At the prompt below, type the network password (also known as the Secure-RPC password) that you obtained either from your administrator or from running the nispopulate script. Please enter the Secure-RPC password for user2:

このスクリプトの残りの出力については、「NIS+ ユーザーを初期設定する方法」を参照してください。

NIS+ 名前空間サンプルで使用したコマンドのまとめ

名前空間サンプルの作成で使用したコマンドを表 4-4 にまとめます。各コマンドの前にあるプロンプトは、そのコマンドをどのマシンで入力するかを示します。

第 5 章 ルートドメインの設定

この章では、NIS+ コマンド群によるルートドメインと DES 認証の設定の手順を説明します。

• 「ルートドメインの設定方法の概要」

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

• 「ルートドメインの確立」

• 「ルートドメイン構成の要覧」

既存のルートマスターサーバーの使用を中止し、別のマシンをルートマスターサーバーにする方法については、『Solaris ネーミングの管理』を参照してください。

ルートドメインの設定方法の概要

ここでは、ルートマスターサーバーをセキュリティレベル 2 で稼動させるルートドメインの構成方法について説明します。

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

ルートドメインの設定には、次の 3 つの主な作業があります。

• ルートマスターサーバーの準備

• ルートドメインの作成

• ルートドメインの資格の作成

ただし、ルートドメインの設定はこれらの 3 つの作業を単にこの順で行うといった簡単なものではありません。3 つの作業はそれぞれ関連し合っています。たとえば、ルートディレクトリを作成する前にセキュリティパラメータの一部を指定しなければなりません。他のパラメータはその後で指定します。ルートドメインの構成を容易にするために、この節ではこれらの作業を個別の手順に分けて、一番効率の良い順番に並べています。

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

この章で説明する手順は、標準の NIS+ ルートドメインと NIS 互換のルートドメインの両方に適用できます。ただし、いくつかの重要な相違があります。NIS 互換ドメイン用の NIS+ デーモンは -Y オプションを使用して起動する必要があります。これによりルートマスターサーバーは、NIS クライアントからの要求に応えることができます。起動方法については「ルートドメインを構成する方法」の 手順 11 で説明します。標準の NIS+ ドメインについては 手順 12で説明します。

また、NIS 互換ドメインでは、passwd テーブルは、未認証クラスに対する読み取り権が必要です。これにより NIS クライアントはテーブルのパスワード列にある情報にアクセスすることができます。これは 手順 14 で nissetup コマンドに -Y オプションを使用して行います。標準の NIS+ ドメインは同じコマンドを使用しますが、-Y オプションは付けません。

ルートドメインの確立

各手順では詳細を説明し、また、関連する情報についても説明します。詳細な説明が必要ない場合は、「ルートドメイン構成の要覧」に必要なコマンドをまとめたリストがありますので参照してください。

手順の要約

設定作業の手順を次にまとめます。

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

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

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

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

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

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

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

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

9. NIS+ デーモンが実行されていることを確認します。

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

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

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

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

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

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

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

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

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

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

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

ルートドメインを確立する - タスクマップ

セキュリティ上の留意点

NIS+ はルートドメインに対しデフォルトのセキュリティを提供します。デフォルトのセキュリティレベルは、レベル 2 です。実際にユーザーが存在するネットワークは、常にセキュリティレベル 2 で運用してください。セキュリティレベル 0 およびレベル 1 は、構成およびテストの目的だけに使用します。

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

前提条件

作業を開始する前に、以下のことを確認します。

• ルートマスターサーバー上の /etc/passwd ファイルには、この構成作業でルートドメインに資格を追加するシステム管理者である自分と、他のすべてのシステム管理者のエントリが含まれなければなりません。

• このサーバーが NIS 互換モードで動作し、Solaris リリース 1.x クライアント用に DNS 転送をサポートする場合、正しく構成された /etc/resolv.conf ファイルが必要です (「リゾルバ」を参照)。

• サーバーには、必ず他のユーザー ID と異なる、固有のマシン名を付けてください。

• サーバーに付けるマシン名には、ドットを使用しないでください。たとえば、マシン名に sales.alpha を使用できません。sales-alpha というマシン名は、使用できます。

必要な情報

ルートドメインを作成するには、次の内容について調べておく必要があります。

• ルートマスターサーバーとなるワークステーションのスーパーユーザーパスワード

• ルートドメイン名

• ルートドメインの管理グループ名

• 自分のユーザー ID とパスワード

• ルートドメインに資格を追加する予定の他のシステム管理者のユーザー ID

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

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

ルートドメイン構成の要覧

ルートドメインの構成に必要な手順を表 5-2 にまとめます。このまとめを参考として使用する前に、作業全体の説明を十分に理解しておいてください。また、ここでは、各コマンドに対するサーバーの応答を示していません。

第 6 章 NIS+ クライアントの構成

この章では、NIS+ コマンド群を使用した 3 通りの初期設定方法で NIS+ クライアントを設定する手順を説明します。ここで説明する手順は、NIS+ または NIS 互換であるかどうかにかかわらず、ルートドメインとサブドメインの両方に適用されます。

• 「NIS+ クライアントの設定方法の概要」

• 「NIS+ クライアントを構成する」

• 「NIS+ クライアントを初期設定する」

• 「ホスト名により NIS+ クライアントを初期設定する」

• 「コールドスタートファイル経由でクライアントを初期設定する」

• 「ワークステーションのドメイン名を変更する」

NIS+ クライアントの設定方法の概要

この章では、標準の NIS+ ドメインと NIS 互換ドメイン内のクライアントを構成する方法を説明します。手順の説明ではそれぞれの内容を詳細に説明し、関連する情報も示します。詳しい手順の説明が必要でない場合は、表 6-6 の「必要なコマンドの一覧」を参照してください。

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

クライアントを設定する作業のうち、手順 10 では、ブロードキャスト、ホスト名、またはコールドスタートファイルのうちのどれかを使用する方法を選択してください。それぞれ実装方法が異なるため、各作業について別々に説明します。クライアントを初期設定したあとは、手順 11 に戻ってクライアントの設定を続けてください。

この章の最後の作業では、ワークステーションのドメイン名を変更する方法を取り上げています。

NIS+ クライアントを構成する

ここでは、ルートドメイン内であるかどうかとは関係なく、一般的な NIS+ クライアントの構成方法を説明します。ここでの説明は、通常の NIS+ クライアント、および後で NIS+ サーバーとなるクライアントに当てはまります。また、標準の NIS+ ドメイン内、および NIS 互換ドメイン内のクライアントにも当てはまります。

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

NIS+ クライアントの設定には、次の作業が必要です。

• クライアントの資格の作成

• ワークステーションの準備

• ワークステーションを NIS+ クライアントとして初期設定

ただし、ルートドメインの設定と同様、クライアントの設定も、これら 3 つの作業を順番に実行するような単純なものではありません。構成手続を実行しやすくするため、これらの作業を個々の手順に分割し、次に示すように、これらの手順を最も効率的な順に並べてあります。

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

2. 新しいクライアントワークステーション用の DES 資格を作成します。

3. マスターサーバーで使用されている Diffie-Hellman キー長を確認します。

4. クライアントにスーパーユーザーとしてログインします。

5. クライアントに新しいドメイン名を設定します。

6. nscd の停止と再起動を行います。

7. クライアントの nsswitch.conf ファイルの設定を確認します。

8. クライアントの Diffie-Hellman キーを設定します。

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

10. クライアントを初期設定します。

11. keyserv デーモンのプロセスを終了して再起動します。

12. keylogin を実行します。

13. クライアントを再起動します。

セキュリティ上の留意点

クライアントの設定には、セキュリティ上の主な必要要件が 2 つあります。つまり、システム管理者とクライアントの両方が、適切な資格とアクセス権を持つことです。そうでない場合、クライアントがセキュリティレベル 2 で実行しているドメインの資格を入手する唯一の方法は、クライアントのホームドメイン内での有効な DES 資格と cred テーブルに対する変更権とを持つシステム管理者が資格を作成することです。システム管理者は DES 資格を、クライアントのホームドメイン内、または自分のホームドメイン内に所持できます。

システム管理者がクライアントの資格を作成すると、そのクライアントは構成プロセスを終了できます。しかしクライアントは、ホームドメインのディレクトリオブジェクトに対する読み取り権を必要とします。第 5 章「ルートドメインの設定」または第 8 章「非ルートドメインの構成」の手順に従ってクライアントのホームドメインを構成した場合、ディレクトリオブジェクトの作成に使用した NIS+ コマンド (nisinit と nismkdir) によって、読み取り権がその他のクラスに提供されています。

ディレクトリオブジェクトのアクセス権をチェックするには、niscat-o コマンドを使用します。このコマンドは、アクセス権などのディレクトリ属性を表示します。次にその例を示します。

rootmaster# niscat -o doc.com.
ObjectName : Doc
Owner : rootmaster.doc.com.
Group : admin.doc.com.
Domain : Com.
Access Rights : r---rmcdr---r---

ディレクトリオブジェクトのアクセス権は、これに対する変更権があれば、nischmod コマンドを使用して変更できます。詳しくは、『Solaris ネーミングの管理』の権利に関連する章を参照してください。

前提条件

クライアントの資格を設定するシステム管理者は、次の条件をすべて満たしている必要があります。

• 有効な DES 資格を持っていること

• クライアントのホームドメインにある cred テーブルを修正する権利を持っていること

クライアントは次の条件をすべて満たしている必要があります。

• ホームドメインのディレクトリオブジェクトに対する読み取り権を持っていること

• クライアントのホームドメインがあらかじめ構成されており、NIS+ を実行していること

• マスターサーバーの /etc/hosts ファイル、またはドメインの hosts テーブルの中にエントリが存在すること

• マシン名が、どのユーザーの ID とも重複しておらず、固有であること

• マシン名にドットが含まれていないこと。たとえば、sales.alpha というマシン名は使用できません。sales-alpha というマシン名なら使用できます。

必要な情報

• クライアントのホームドメイン名

• クライアントとなるワークステーションのスーパーユーザーパスワード

• クライアントのホームドメイン内にある NIS+ サーバーの IP アドレス

クライアントの設定 - タスクマップ

NIS+ クライアントを設定する方法

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

   スーパーユーザーとして、または自分自身のユーザー名でログインします。どちらでログインするかは、どちらの NIS+ 主体がドメインの cred テーブルに資格を追加するための適切なアクセス権を所有しているのかに依存します。

2. 新しいクライアントワークステーション用の DES 資格を作成します。

   -p と -P の引数を付けた nisaddcred コマンドを実行します。

   nisaddcred -p secure-RPC-netname principal-name des [domain]

   secure-RPC-netname は、接頭辞 unix に、クライアントのホスト名、@ 記号、およびクライアントのドメイン名を付けて構成しますが、最後にドットは付けません。principal-name は、クライアントのホスト名とドメイン名によって構成され、最後にドットを付けます。このクライアントの所属するドメインが、コマンドを入力したサーバーとは異なる場合、2 番目の引数の後にクライアントのドメイン名を追加します。

   この例では、doc.com. ドメイン内の client1 という名前のクライアントワークステーションに対する DES 資格を追加します。

   rootmaster% nisaddcred -p unix.client1@doc.com -P client1.doc.com. des Adding key pair for unix.client1@doc.com (client1.doc.com.). Enter client1.doc.com.'s root login passwd: Retype password:

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

3. マスターサーバーで使用される Diffie-Hellman キー長を確認します。

   例

   rootmaster% nisauthconf dh640-0 des

4. クライアントにスーパーユーザーとしてログインします。

   これでクライアントワークステーションに資格ができたため、ユーザーはマスターサーバーからログアウトし、クライアント自体から作業を開始できます。この作業はローカルでもリモートでも可能です。

5. クライアントに新しいドメイン名を設定します。

   クライアントのドメイン名を設定する (変更する) 方法については、「ワークステーションのドメイン名を変更する」を参照し、次の 手順 6 に戻ります。

6. クライアントの nsswitch.conf ファイルをチェックします。

   クライアントが NIS+ バージョンの nsswitch.conf ファイルを使用していることを確認します。これによって、クライアント情報の 1 次ソースが NIS+ テーブルということが確認できます。NIS+ スイッチファイルの詳細は、「NIS+ 用デフォルトスイッチファイル」をご覧ください。

7. nsswitch.conf ファイルに何らかの変更を加えた場合 (または、新規にファイルにコピーした場合) 、必ず次の表のように入力して nscd を停止してから再起動する必要があります。

   client1# cp /etc/nsswitch.nisplus /etc/nsswitch.conf client1# sh /etc/init.d/nscd stop client1# sh /etc/init.d/nscd start

   (第 1 章「ネームサービススイッチの設定」では、この時点でキーサーバーを停止して、再起動するよう説明していますが、同じ操作を 手順 11 で行うため、この場合は停止および再起動の必要はありません。)

8. 手順 3 の情報を使用して、Diffie-Hellman キー長を設定します。

   例 :

   client# nisauthconf dh640-0 des

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

   作業しているワークステーションが、すでに NIS+ のサーバーまたはクライアントとして使用されていて、まだ実行中の場合、/var/nis ディレクトリに存在するファイルすべてを削除し、キャッシュマネージャを停止します。

   client1# ls /var/nis NIS_COLD_START NIS_SHARED_CACHE client1# rm -rf /var/nis/* client1# 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 client1# kill -9 286

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

10. クライアントを初期設定します。

    クライアントの初期設定は、ホスト名、コールドスタートファイル、またはブロードキャストのいずれかを使用して行うことができます。3 つの方法のうち、いずれかを選択して実行します。クライアントの初期設定が終了したら、手順 11 に進みます。

11. keyserv デーモンを終了してから再起動します。

    この手順では、非公開鍵をキーサーバー上に格納します。

    1. keyserv デーモンを終了します。

       この手順によって、キーサーバーが保持していたクライアントに関するスイッチ情報も更新されます。

    2. /etc/.rootkey ファイルを削除します。

    3. キーサーバーを再起動します。

       次の例では、手順 11 の内容を示しています。

       client1# ps -e | grep keyserv root 145 1 67 16:34:44 ? keyserv client1# kill 145 client1# rm -f /etc/.rootkey client1# keyserv

    4. keylogin -r を実行します。

       この手順では、クライアントの非公開鍵をキーサーバーに格納します。また、クライアント上のスーパーユーザーが NIS+ を使用するために keylogin を行わなくてもすむように、/etc/.rootkey にコピーを保存します。-r オプションを付けて keylogin を実行します。パスワードの入力を求められたら、クライアントのスーパーユーザーパスワードを入力します。このパスワードは、クライアントの DES 資格を作成するために与えられたパスワードと同じでなければなりません。

       client1# keylogin -r Password: Wrote secret key into /etc/.rootkey

    5. クライアントを再起動します。

ワークステーションのドメイン名を変更する

この作業では、ワークステーションのドメイン名を変更します。ワークステーションのドメイン名は通常インストール時に設定されるため、domainname コマンドを引数なしで実行して、ワークステーションのドメイン名をチェックしてからこの作業を実行してください。

セキュリティ上の留意点

この作業は、ドメイン名を変更するワークステーション上のスーパーユーザーとして実行しなければなりません。

必要な情報

• ワークステーションのスーパーユーザーパスワード

• 新しいドメイン名

ワークステーションのドメインの変更 - タスクマップ

クライアントのドメイン名を変更する方法

1. ワークステーションにログインし、スーパーユーザーになります。

   この例では、ワークステーションに client1 を、新しいドメイン名に doc.com. を使用します。

   client1% su Password:

2. ワークステーションのドメイン名を変更します。

   domainname コマンドを使用して新しい名前を入力します。名前の最後にドットを入力しないでください。たとえば、ワークステーションのドメインを doc.com に変更するのであれば、次のように入力します。

   client1# domainname doc.com

   ワークステーションが NIS クライアントの場合は、NIS サービスを受けることはできません。

3. 結果を確認します。

   今度は、引数を付けずに domainname コマンドを実行し、サーバーの現在のドメインを表示させます。

   client1# domainname doc.com

4. 新しいドメイン名を保存します。

   domainname コマンドの出力を /etc/defaultdomain ファイルに書き込みます。

   client1# domainname > /etc/defaultdomain

5. 適当な時に、ワークステーションを再起動します。

   /etc/defaultdomain ファイルに新しいドメイン名を入力した後でも、一部のプロセスは依然として古いドメイン名で動作している可能性があります。すべてのプロセスに新しいドメイン名を確実に使用させるため、ワークステーションを再起動します。

   この作業は、他のいくつかの作業の流れの中で行うものです。リブートは、ワークステーション上でのすべての作業が完了したことを確認してから行なってください。確認を怠ると、何度もリブートが必要になる可能性があります。

NIS+ クライアントを初期設定する

NIS+ クライアントを初期設定する方法には、以下の３つの種類があります。

• ブロードキャストを使用する方法 (「ブロードキャストにより初期設定する」を参照)

• ホスト名を使用する方法 (「ホスト名により NIS+ クライアントを初期設定する」を参照)

• コールドスタートファイルを使用する方法 (「コールドスタートファイル経由でクライアントを初期設定する」を参照)

ブロードキャストにより初期設定する

この方法では、クライアントの存在するサブネット上に IP ブロードキャストを送信して NIS+ クライアントを「初期化」します。

初期化の方法としてはこれが最も簡単ですが、最も安全性の低い方法でもあります。ブロードキャストに応答した NIS+ サーバーはクライアントが自分自身のコールドスタートファイルに格納する必要がある情報 (サーバーの公開鍵など) をすべて送信します。おそらくブローキャストに応答するのは NIS+ サーバーだけですが、クライアントからは、ブロードキャストに応答したワークステーションが確かに信用できるサーバーなのかどうか確認できません。そのため、この方法は小規模で、セキュリティが確保されたサイトでだけ使用することをお勧めします。

セキュリティ上の留意点

この作業は、クライアントのスーパーユーザーとして実行しなければなりません。

前提条件

クライアントと同じサブネット上に、少なくとも 1 台の NIS+ サーバーが存在しなければなりません。クライアントは、マスターサーバーで使用するのと同じ Diffie-Hellman キー長を使用する必要があります。nisauthconf(1M) を参照してください。

必要な情報

クライアントのスーパーユーザーのパスワードが必要です。

NIS+ クライアントを初期設定する - タスクマップ

ブロードキャストにより NIS+ クライアントを初期設定する方法

クライアントを初期設定します。

この手順では、クライアントを初期設定し、その /var/nis ディレクトリに NIS_COLD_START ファイルを作成します。nisinit コマンドに -c と -B のオプションを付けて実行します。

client1# nisinit -c -B
This machine is in the doc.com. NIS+ domain.
Setting up NIS+ client ...
All done.

同じサブネット上の NIS+ サーバーがブロードキャストに応答し、その位置情報をクライアントのコールドスタートファイルに追加します。

ホスト名により NIS+ クライアントを初期設定する

クライアントをホスト名によって初期化する場合、信頼できるサーバーの IP アドレスを明確に指摘します。そしてこのサーバー名、位置情報、公開鍵がクライアントのコールドスタートファイルに格納されます。

この方法は、クライアントがサーバーの IP アドレスを指定するので、自分で自分を識別してくるサーバーに応答するブロードキャストよりも安全です。しかし、クライアントと信頼できるサーバーの間にルーターが介在している場合、正しい IP アドレスへのメッセージを横取りし、不正なサーバーに送ることもあり得ます。

セキュリティ上の留意点

この作業は、クライアント上のスーパーユーザーとして実行しなければなりません。

前提条件

• NIS+ サービスはクライアントのドメインで実行されていなければなりません。

• クライアントは、/etc/hosts ファイル内に信頼できるサーバーのエントリを持っていなければなりません。

• クライアントは、マスターサーバーで使用するのと同じ Diffie-Hellman キー長を使用する必要があります。nisauthconf(1M) を参照してください。

必要な情報

信頼できるサーバー名と IP アドレスが必要です。

NIS+ クライアントを初期設定する - タスクマップ

ホスト名により NIS+ クライアントを初期設定する方法

1. クライアントの /etc/hosts ファイルを確認します。

   クライアントが、信頼できるサーバーのエントリを持っていることを確認します。

2. クライアントを初期設定します。

   この手順では、クライアントを初期設定し、その /var/nis ディレクトリ内に NIS_COLD_START ファイルを作成します。nisinit コマンドに -c と -H のオプションを付けて実行します。次の例では、信頼できるサーバーとして rootmaster を使用します。

   Client1# nisinit -c -H rootmaster This machine is in the doc.com. NIS+ domain. Setting up NIS+ client ... All done.

   nisinit ユーティリティは、クライアントの /etc/hosts ファイル内でサーバーのアドレスを探します。したがって、サーバーにドメイン名を付加しないでください。ドメイン名を付加した場合、このユーティリティはサーバーのアドレスを見つけることができません。

コールドスタートファイル経由でクライアントを初期設定する

ここでは、NIS+ クライアントを初期設定するために、別の NIS+ クライアント (できれば同じドメインから) の COLD_START を使用します。NIS+ クライアントを設定する方法としてはこれが最も安全です。これにより、クライアントは、信頼できるサーバーから確実に NIS+ 情報を得ることができます。これはホスト名やブロードキャストによる初期化では保証されません。

セキュリティ上の留意点

この作業は、クライアント上のスーパーユーザーとして実行しなければなりません。

前提条件

COLD_START ファイルに指定されたサーバーは、すでに構成されており、NIS+ を実行していなければなりません。

クライアントは、マスターサーバーで使用するのと同じ Diffie-Hellman キー長を使用する必要があります。nisauthconf(1M) を参照してください。

必要な情報

コピーするCOLD_START ファイルの名前と位置が必要です。

NIS+ クライアントを初期設定する - タスクマップ

COLD_START 経由で NIS+ クライアントを初期設定する方法

1. 他のクライアントの COLD_START ファイルをコピーします。

   他のクライアントの COLD_START ファイルを、新しいクライアントのディレクトリにコピーします。これを行うには、クライアント上のスーパーユーザーとしてではなく、自分のユーザー名でログインしている間に行う方が簡単です。クライアントを初期設定する前に、必ずスーパーユーザーになってください。

   ただし、NIS_COLD_START ファイルを /var/nis にコピーしないでください。初期設定中にこのファイルは上書きされます。次の例では、client1 の COLD_START ファイルを、初期設定されていない client2 の /tmp ディレクトリにコピーします。

   client2# exit client2% rcp client1:/var/nis/NIS_COLD_START /tmp client2% su

2. COLD_START ファイルからクライアントを初期設定します。

   次に示すように、nisinit コマンドに -c と -C のオプションを付けて実行します。

   client2# nisinit -c -C /tmp/NIS_COLD_START This machine is in the doc.com. NIS+ domain. Setting up NIS+ client ... All done.

NIS+ クライアント構成の要覧

クライアントの構成に必要な手順を表 6-6 にまとめます。クライアントは doc.com ドメインにある client1 とします 。これは最も簡単なケースを想定しているため、このまとめを参考用として使用するには、その前に自分の実際の作業の詳細を理解することが必要です。簡略化のため、ここでは各コマンドに対するサーバーの応答を示していません。

第 7 章 NIS+ サーバーの構成

この章では、NIS+ コマンドセットを使って NIS+ サーバーを設定する手順と、既存の NIS+ ドメインに複製サーバーを追加する手順を説明します。

• 「NIS+ サーバーを設定する」

• 「既存のドメインに複製サーバーを追加する」

この章で説明する内容は、ルートマスターを除くすべての NIS+ サーバーに適用されます。つまり、NIS 互換モードで稼動しているかどうかにかかわらず、ルート複製サーバー、非ルートマスターサーバー、または非ルート複製サーバーに適用されます。章末では個々の作業についてまとめています。

既存の NIS+ サーバーの機能を停止し、他のマシンで置き換える方法については、『Solaris ネーミングの管理』を参照してください。

NIS+ サーバーを設定する

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

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

NIS 互換の NIS+ サーバーと標準の NIS+ サーバーの設定における違いは、ルートマスターサーバーの場合と同じです ( 「標準構成と NIS 互換構成の手順の相違」を参照)。NIS 互換サーバー用の NIS+ デーモンは -Y オプション (DNS 転送を使用する場合は、-B オプションを追加する) を使用して起動しなければなりません。これによって、サーバーは NIS クライアントからの要求に応答できます。これについては、「NIS+ サーバーを構成する方法」の手順 2 (標準の NIS+ サーバーの場合は、手順 3) で説明します。

-Y または -B のいずれかのオプションを使用して rpc.nisd を起動した場合、必ず rpc.nisd_resolv という副デーモンが生成され、名前の解決を行います。この副デーモンは、主デーモンを終了させた場合は、必ず別個に終了させなければなりません。

構成プロセス全体のまとめを次に示します。

1. 新しい複製サーバーにスーパーユーザーとしてログインします。

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

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

セキュリティ上の留意点

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

この手順は、サーバー上のスーパーユーザーとして実行しなければなりません。起動したサーバーのセキュリティレベルによって、そのクライアントが備えるべき資格が決ります。たとえば、サーバーがセキュリティレベル 2 で構成された場合、サーバーがサポートするドメイン内のクライアントは、DES 資格を必要とします。このマニュアルの指示に従ってクライアントを構成した場合、そのクライアントは適切なドメインに DES 資格を持ち、セキュリティレベル 2 でサーバーを起動できます。

セキュリティレベル 0 は、管理者による構成とテストの目的だけに使用します。セキュリティレベル 1 はサポートされていません。一般のユーザーが通常の業務を行う環境では、レベル 0 またはレベル 1 を使用せず、常にセキュリティレベル 2 を使用してください。

前提条件

• ルートドメインがあらかじめ構成されている (第 5 章「ルートドメインの設定」を参照)

• サーバーにするには、NIS+ クライアントとして初期設定しておく (第 6 章「NIS+ クライアントの構成」を参照)

• サーバーを構成するには、そのマシンにスーパーユーザーとしてログインする必要がある

• サーバーが NIS 互換モードで稼動し、DNS 転送をサポートするためには、正しく構成された /etc/resolv.conf ファイルが必要 (第 1 章「ネームサービススイッチの設定」を参照)

必要な情報

サーバーに変換するクライアントのスーパーユーザーパスワードが必要です。

NIS+ サーバーを初期設定する - タスクマップ

NIS+ サーバーを構成する方法

1 つのマスターサーバーまたは複製サーバーから複数のドメインにサービスを提供することは可能ですが、あまりお勧めしません。

1. 新しくサーバーにするワークステーションにスーパーユーザーとしてログインします。

   以下の手順では、「NIS+ クライアントを構成する」に従って、ワークステーションを NIS+ クライアントとして設定した後、これを再起動したことを前提としています。ワークステーションを再起動すると、次の手順の推奨前提条件であるキャッシュマネージャが起動します。ワークステーションを再起動しなかった場合、ここでキャッシュマネージャ (nis_cachemgr) を再起動します。

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

   この手順は、サーバーを NIS 互換モードで設定する場合にだけ実行します。標準の NIS+ サーバーを設定する場合は、この代わりに 手順 3を実行します。

   この手順には、NIS クライアントの DNS 転送機能をサポートするための操作説明も含まれています。この手順は、2 つに分かれています。最初の手順では、NIS+ デーモンを NIS 互換モードで起動します。2 つめの手順では、サーバーが再起動されたときに、NIS+ デーモンが NIS 互換モードで再起動するように設定します。

   1. rpc.nisd に -Y と -B のフラグを付けて実行します。

      compatserver# rpc.nisd -Y -B

      -Y オプションは、NIS+ 要求だけでなく NIS 要求にも応答するインタフェースを呼び出します。-B オプションは DNS 転送をサポートします。

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

      /etc/init.d/rpc ファイル内で文字列 EMULYP="-Y" を検索して、この文字列を含む行のコメント指定を解除します。

      DNS 転送機能を使用するには、EMULYP="-Y" に -B フラグを追加します。DNS 転送機能が必要ない場合は、コメント指定の解除だけを実行し、-B フラグは追加しないでください。

      この手順によって、/var/nis/data という名前のディレクトリが作成されます。また、trans.log というトランザクションログファイルが作成され、/var/nis というディレクトリに格納されます。

      compatserver# ls -F /var/nis NIS_COLD_START data/ trans.log data.dict

      trans.log ファイルは、トランザクションログです。トランザクションログの内容は、nislog コマンドを使用して調べることができます。詳細は、『Solaris ネーミングの管理』のディレクトリ関連の章を参照してください。

      ---

      注意 -

      /var/nis ディレクトリと /var/nis/data ディレクトリは、移動または名前の変更をしないでください。また、/var/nis/trans.log ファイルと /var/nis/data.dict ファイルについても、移動または名前の変更をしないでください。Solaris リリース 2.4 以前からアップグレードする場合、それまで使っていた /hostname サブディレクトリは自動的に /var/nis/data に変換され、それに関わりのあるファイルも必要に応じて変換されます。この自動変換がなされた後で、新しい名前に変更することは絶対にしないでください。

      ---

      これで、マスターサーバー、複製サーバーのいずれにするかを決定します (第 8 章「非ルートドメインの構成」を参照)。この作業はこの手順で完了です。作業の要約については、「サーバー構成の要覧」を参考にしてください。

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

   rpc.nisd コマンドを実行します。

   server# rpc.nisd

   NIS+ デーモンが本当に実行されていることを確認するには、次のように ps コマンドを実行します。

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

   この手順によって、/var/nis/data という名前のディレクトリが作成されます。また、trans.log というトランザクションログファイルが作成され、/var/nis ディレクトリに格納されます。

   compatserver# ls -F /var/nis NIS_COLD_START data/ trans.log data.dict

   compatserver.log ファイルは、トランザクションログです。トランザクションログの内容は、nislog コマンドを使用して調べることができます。詳しくは、『Solaris ネーミングの管理』のディレクトリ関連の章を参照してください。

   ---

   注意 -

   /var/nis ディレクトリと /var/nis/data ディレクトリは、移動または名前の変更をしないでください。また、/var/nis/trans.log ファイルと /var/nis/data.dict ファイルについても、移動または名前の変更をしないでください。Solaris リリース 2.4 以前からアップグレードする場合、それまで使っていた /hostname サブディレクトリは自動的に /var/nis/data に変換され、それに関わりのあるファイルも必要に応じて変換されます。この自動変換がなされた後で、新しい名前に変更することは 絶対にしないで ください。

   ---

   これでこのサーバーは、第 8 章「非ルートドメインの構成」 の説明に従って、ドメインのマスターまたは複製に指定できます。NIS+ サーバーの設定は、この手順で完了です。作業の要約については 「サーバー構成の要覧」を参照してください。

既存のドメインに複製サーバーを追加する

NIS+ サービスを常に利用できる状態にしておきたいのであれば、ルート複製サーバーを少なくとも 1 つは作成しておくことをお勧めします。複製サーバーを作成すると複数のサーバーが存在することになり、要求の処理を分散させることができるため、ネットワーク要求の処理も高速化されます。

パフォーマンス上の理由から、1 つのドメインに多くの複製サーバーを置くことはお勧めできません。ネットワークが複数のサブネットで構成されている場合、あるいは広域ネットワーク (WAN) でリモートサイトに接続されている場合にだけ、複製サーバーを置くようにしてください。

• 「サブネット」

  複数のサブネットで構成されているドメインの場合、各サブネットに複製サーバーを少なくとも 1 つは作成することをお勧めします。そうしておけば、ネットワーク間の通信が一時的に途絶していても、接続が回復するまでの間、サブネットレベルの機能は維持されるからです。

• 「リモートサイト」

  WAN によりリモートサイトに接続されているドメインの場合、WAN 接続の両側に複製サーバーを少なくとも 1 つは作成することをお勧めします。組織論的な見地からしても、同一の NIS+ ドメインに物理的に離れた 2 つのサイトがあるのは意味のあることです。たとえば、ドメイン内のマスターサーバーとその複製サーバーがすべて一方のサイトに置かれている場合、そのサイトともう一方のサイトとの間の NIS+ ネットワークトラフィックが増大するのは目に見えています。もう一方のサイトにも複製サーバーを置いておけば、ネットワークトラフィックが減るはずです。複製サーバーの分散配置については、『NIS+ への移行』を参照してください。

理想的な複製サーバーの数については、『Solaris ネーミングの管理』を参照してください。既存のドメインに複製サーバーを追加するには、その複製サーバーを構成してから該当する名前空間の NIS+ データセットをロードします。

新しい複製サーバーを構成して NIS+ データセットをロードする方法には、次の 2 通りがあります。

• 「スクリプト」

  nisserver スクリプトを実行するには、「ルート複製サーバーの作成」の説明に従ってください。この方法では、NIS+ データセットが新しい複製サーバーにロードされて自動的に再同期がとられます。格段に簡単なので、こちらの方法をお勧めしますが、「NIS+ コマンドセット」と「バックアップと復元」を利用する方法に比べると、時間が長くかかることがあります。

• 「NIS+ コマンドセット」

  NIS+ コマンドを使うには、「NIS+ コマンドによる複製サーバーの構成」の説明に従ってください。nisserver スクリプトを実行する方法に比べると、NIS+ に対する深い知識が必要です。この NIS+ コマンドを使う方法には、きめの細かい設定と監視が可能であるという利点があります。そして、もう 1 つ、ドメインディレクトリを手作業で作成して複製サーバーを生成し、nisbackup と nisrestore を使って NIS+ データをロードできるという利点もあります。nisbackup と nisrestore を使うと、nisserver スクリプトを使うより、短時間でデータセットをロードできます。

  新たに構成した複製サーバーに NIS+ データセットをロードする方法には、次の 2 通りがあります。

  • 「nisping」

    nisserver スクリプトと NIS+ コマンドのどちらを使った場合でも、新しい複製サーバーの構成が完了すると、nisping を使用することで、該当する名前空間のデータセットがマスターサーバーにより、ネットワーク経由で自動的に新しい複製サーバーにロードされます。このとき、大きな名前空間では処理に長時間かかり、その間、名前管理情報の要求が遅れることがあります。詳細は、「nisping を使ってデータを複製サーバーにロードする」を参照してください。

  • 「バックアップと復元」

    nisping によるデータ転送に割り込みをかけ、NIS+ のバックアップ機能と復元機能を使って、名前空間データを新たに構成した複製サーバーにロードできます (「nisrestore を使ってデータを複製サーバーにロードする」を参照)。複製サーバーから複製サーバーにデータセットがロードされることになり、マスターサーバーから複製サーバーにネットワーク経由でデータセットをロードする場合に比べて格段に早く終わるので、こちらの方法をお勧めします。

NIS+ コマンドによる複製サーバーの構成

この節では、NIS+ コマンドを使って複製サーバーを既存のドメインに追加する方法について説明します。

セキュリティ上の留意点

この作業を実行する NIS+ 主体には、ドメインのディレクトリオブジェクトに対する変更権が必要です。

前提条件

• ドメインをあらかじめ構成し、マスターサーバーを稼動させておく

• 新しい複製サーバーが NIS+ サーバーとして構成されている (「NIS+ サーバーを設定する」を参照)

必要な情報

• サーバー名

• ドメイン名

NIS+ コマンドを使って複製サーバーを構成する- タスクマップ

NIS+ コマンドを使って複製サーバーを構成する

この例では、マスターサーバー名を master1、新しい複製サーバー名を replica2 とします。

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

2. rpc.nisd が稼働中であることを確認します。

3. ドメインに複製サーバーを追加します。

   nismkdir コマンドに -s オプションを付けて実行します。次の例では、doc.com. ドメインに replica2 という名前の複製サーバーマシンを追加します。

   master1# nismkdir -s replica2 doc.com. master1# nismkdir -s replica2 org_dir.doc.com. master1# nismkdir -s replica2 groups_dir.doc.com.

   すでに存在するディレクトリオブジェクトに nismkdir コマンドを実行すると、ディレクトリは再作成されずに、与えられたフラグに基づいてディレクトリが変更されます。この場合、-s フラグはドメインに追加する複製サーバーを割り当てます。複製サーバーが追加されたことを確認するには、niscat -o コマンドを実行して、ディレクトリオブジェクトの定義を調べます。

   ---

   注意 -

   nismkdir コマンドは必ずマスターサーバー上で実行してください。複製サーバー上で nismkdir コマンドを実行すると、マスターサーバーと複製サーバーとの間で通信上の問題が生じます。

   ---

   これで新しい複製サーバーの構成は完了です。次は、構成した複製サーバーに NIS+ データセットをロードします。NIS+ データセットのロードには、2 通りの方法があります。

   • 「nisping」

     何もしなければ、マスターサーバーによって nisping コマンドが実行され、該当する名前空間データが新たに構成された複製サーバーにロードされます。このとき、大きな名前空間では処理に長時間かかり、その間、名前管理情報の要求に対する応答が遅れることがあります (詳細は、「nisping を使ってデータを複製サーバーにロードする」を参照)。

   • 「バックアップと復元」

     nisping によるデータ転送に割り込みをかけ、NIS+ のバックアップ機能と復元機能を使って、名前空間データを新たに構成した複製サーバーにロードできます (「nisrestore を使ってデータを複製サーバーにロードする」を参照)。他の方法に比べて格段に早く効率的なので、こちらの方法をお勧めします。

nisrestore を使ってデータを複製サーバーにロードする

この節では、NIS+ のバックアップ機能と復元機能を使って名前空間データを新しい複製サーバーにロードする方法について説明します。この方法を使ってデータを複製サーバーにロードすることをお勧めします。

セキュリティ上の留意点

この作業を実行する NIS+ 主体には、ドメインのディレクトリオブジェクトに対する変更権が必要です。

前提条件

• ドメインをあらかじめ構成し、マスターサーバーを稼動させておく

• 新しい複製サーバーが NIS+ サーバーとして構成されている (「NIS+ サーバーを設定する」を参照)

• 新しい複製サーバーが複製サーバーとして構成されている (「NIS+ コマンドによる複製サーバーの構成」を参照)

nisrestore を使ってデータを複製サーバーにロードする - タスクマップ

nisrestore を使って名前空間データをロードする

この例では、マスターサーバー名を master1、新しい複製サーバー名を replica2 とします。

1. 複製サーバー上の rpc.nisd を終了させます。

   マスターサーバーから複製サーバーへの名前空間データの自動ロード ( nisping による) が中断されます。

2. マスターサーバー上で NIS+ バックアップ機能を実行します。

   この手順は『Solaris ネーミングの管理』に詳しく説明されています。以下の例では、nisbackup コマンドを使って master1 を /var/master1_bakup ディレクトリにバックアップします。

   master1# nisbackup -a /var/master1_bakup

   nisrestore を使って新しい複製サーバーを構成する最も簡単な方法は、マスターサーバーのデータを NFS にマウントされた (複製サーバーからアクセス可能な) ディレクトリにバックアップするというものです。この例では、マスターサーバーと新しい複製サーバーの両方に、/var/master1_bakup ディレクトリへのアクセス権が与えられているものと想定します。

   このほかに、tar コマンドを使って /var/master1_bakup ディレクトリからテープカートリッジなどの可搬記憶メディアにデータをコピーし、次に、その可搬記憶メディアから新しい複製サーバーにマウントされているディレクトリにデータをコピーし、そのディレクトリを nisrestore コマンドの情報源として使うという方法 (手順 3 参照) もあります。

3. nisrestore コマンドを使って、NIS+ データセットを新しい複製サーバーにロードします。

   この手順は『Solaris ネーミングの管理』に詳しく説明されています。以下の例では、nisrestore コマンドを使って NIS+ データを/var/master1_bakup ディレクトリから client2 にダウンロードします。

   replica2# nisrestore -a /var/master1_bakup

   作成している複製サーバーがルートドメインで使うものである場合、あるいは nisrestore が必要なデータを検証または見つけることができないという旨のエラーメッセージが出た場合は、次に示すように -f オプション付きで実行してみてください。

   replica2# nisrestore -f -a /var/master1_bakup

4. 新しい複製サーバー上で rpc.nisd を再実行します。

   詳細は、「NIS+ サーバーを構成する方法」を参照してください。

nisping を使ってデータを複製サーバーにロードする

この節では、nisping コマンドを使って名前空間データを新しい複製サーバーにロードする方法について説明します。通常、このプロセスは自動的に実行されるため、nisping コマンドを実行する必要はまずありません。

nisping コマンドを使う方法の問題点は、マスターサーバーから複製サーバーへデータの再同期をとるために、NIS+ プロトコルを使ったネットワーク上のデータのやりとりが必要だということです。名前空間が大きい場合は、この処理に何時間もかかり、その間、名前管理情報の要求に対する応答が遅れることがあります。

セキュリティ上の留意点

この作業を実行する NIS+ 主体には、ドメインのディレクトリオブジェクトに対する変更権が必要です。

前提条件

• ドメインをあらかじめ構成し、マスターサーバーを稼動させておく

• 新しい複製サーバーが NIS+ サーバーとして構成されている (「NIS+ サーバーを設定する」を参照)

• 新しい複製サーバーが複製サーバーとして構成されている (「NIS+ コマンドによる複製サーバーの構成」を参照)

nisping を使ってデータを複製サーバーにロードする - タスクマップ

nisping を使って名前空間データをロードする方法

通常、名前空間データのロードは、マスターサーバーによって自動的に開始されます。マスターサーバーによるロードが行われなかった場合は、次の説明に従って nisping コマンドを実行してください。

ディレクトリに対して nisping を実行します。

この手順では、新しい複製サーバーにメッセージ「ping」を送信して、マスターサーバーに対して更新を要求するように通知します。複製サーバーがルートドメインに所属していない場合、必ずドメイン名を指定してください。次の例では、ドメイン名は完全を期すためにだけ記述してあります。この作業で使用する例は、ルートドメインに複製サーバーを追加しているため、次の例にあるドメイン名 doc.com. は必要ありません。

master1# nisping doc.com. 
master1# nisping org_dir.doc.com. 
master1# nisping groups_dir.doc.com.

次のような画面が表示されます。

master1# nisping doc.com. 
Pinging replicas serving directory doc.com. :
Master server is master1.doc.com.
No last update time
Replica server is replica1.doc.com.
Last update seen was Wed Nov 18 11:24:32 1992
Pinging ... replica2.doc.com.

大きな名前空間の場合、この処理に何時間もかかる場合があります。nisping の詳細は、『Solaris ネーミングの管理』のディレクトリ関連の章を参照してください。

サーバー構成の要覧

表 7-5、表 7-6 では、この章で説明した作業のまとめを示しています。この 2 つの表は、最も簡単な場合を想定しているため、参考用として使用するには、実際の自分の作業の詳細を理解している必要があります。また、ここでは各コマンドに対するサーバーの応答は割愛しています。

上記の例でも説明したように、新しい複製サーバーにデータをロードするのであれば、nisping を使うより NIS+ のバックアップ機能や復元機能を使った方が簡単です 。詳細は、「nisrestore を使ってデータを複製サーバーにロードする」と『Solaris ネーミングの管理』を参照してください。

第 8 章 非ルートドメインの構成

この章では、NIS+ コマンドセットを使ってサブドメイン (非ルートドメイン) を構成する方法 (マスターサーバーと複製サーバーを設定する方法を含む) を、手順を追って説明します。

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

• 「サブドメイン構成の要覧」

作業のまとめは、表 8-2 にあります。

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

非ルートドメインを設定する作業は、この章で説明する 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 コマンドを使用します。

前提条件

• 親ドメインを構成し、実行していなければなりません。

• このドメインのマスターとして指定されるサーバーは、すでに初期設定され、NIS+ を実行していなければなりません。

• 複製サーバーを指定する場合、マスターサーバーは、その /etc/hosts ファイルまたはその NIS+ hosts テーブルを通じて、複製サーバーの IP アドレスを入手できなければなりません。

必要な情報

• 新しいドメインの名前 (手順 3)

• 新しいドメインのマスターサーバーと複製サーバー名

• 新しいドメインの管理グループ名 (手順 2)

• 新しいドメインの管理グループに所属する管理者のユーザー ID (UID) (手順 8)

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

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

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

サブドメイン構成の要覧

表 8-2 は、サブドメインの構成に必要な手順のまとめです。これは、最も簡単な場合を想定しています。このため、まとめを参考として使用する前に、作業の詳細について十分に理解しておいてください。また、この表では各コマンドに対するサーバーの応答は割愛しています。

第 9 章 NIS+ テーブルの設定

この章では、NIS+ コマンドセットを使用して、/etc ディレクトリ内のファイルや NIS マップからマスターサーバー上に NIS+ テーブルを作成する方法について説明します。また、この章では NIS+ テーブルから NIS マップへ情報を戻す方法と、passwd テーブルのパスワード列へのアクセスを制限する方法を説明します。

• 「テーブルの生成の方法」

• 「NIS+ テーブルをファイルから生成する方法」

• 「NIS+ テーブルを NIS マップから生成する方法」

• 「NIS+ から NIS に情報を転送する」

• 「所有者および管理者に対する Passwd へのアクセス制限」

テーブルの設定

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

NIS+ テーブルを生成するには次の 4 種類の方法があります。

• ファイルから作成する。(「NIS+ テーブルをファイルから生成する方法」参照)

• NIS マップから作成する。(「NIS+ テーブルを NIS マップから生成する方法」参照)

• nispopulate スクリプトを使用して作成する。(「NIS+ テーブルの生成 (populate)」および 「新しいサブドメインのテーブルの生成」)

• Solstice AdminSuite ツールを使用する

マップまたはファイルからテーブルを生成する場合、第 5 章「ルートドメインの設定」および第 8 章「非ルートドメインの構成」で説明する手順に従って、ルートまたはサブドメインの設定作業の中で、あらかじめテーブルを作成しておく必要があります。ドメインテーブルは、テーブルの作成後いつでも生成できますが、ドメインの設定が完了したらすぐに生成しておくことをお勧めします。テーブルを生成すると、クライアントに関する必要な情報がすでにドメインテーブル内に格納されることになるため、クライアントの追加が簡単にできます。

テーブルの生成の方法

ファイルまたは NIS マップからテーブルを生成する場合、次の 3 つの方法を使用できます。

• 「置換」

  この方法を使用すると、NIS+ は、初めにテーブル内の既存のエントリをすべて削除してから、情報源からのエントリを追加します。サイズの大きいテーブルの場合は、マスターサーバーの /var/nis/trans.log ファイルにエントリの大きなセット (既存のエントリを削除するためのセットと新しいエントリを追加するためのセット) が追加されます。/var/nis 内のディスク空間を大幅に使用するため、複製サーバーへの転送時間はさらに長くなります。

• 「追加」

  この方法は、NIS+ テーブルに情報源からのエントリを追加します。既存のエントリが影響されることはありません。

• 「マージ」

  この方法は、置換オプションと結果は同じですが、内部的な処理が異なります。既存のエントリを削除後、置換するのではなく、更新します。このオプションでは、NIS+ は次の 3 種類のエントリを異なる方法で処理します。

  • 情報源内だけに存在するエントリは、テーブルに追加する

  • 情報源とテーブルの両方に存在するエントリは、テーブルで更新する

  • NIS+ テーブルだけに存在するエントリは、テーブルから削除する

  大きなテーブルを、内容があまり変わらないファイルやマップで更新する場合、マージ用のオプションを使用すると、サーバーの処理を大幅に減らすことができます。情報源内で重複していないエントリだけを削除する (置換オプションでは、単純にすべてのエントリを削除する) ため、重複するエントリに対する削除と追加の処理を 1 回ずつ少なくできます。このため、この方法をお勧めします。

NIS+ テーブルをファイルから生成する方法

これは /etc/hosts などの ASCII ファイルの内容を NIS+ テーブルに転送する作業です。

手順の概要は次のとおりです。

1. データを転送する各ファイルの内容を確認します。

2. 各ファイルのコピーを作成します。作成したコピーを実際の転送に使用します。このマニュアルでは、hosts.xfr のように、転送されるファイルのコピーの最後に .xfr を付けます。

3. NIS+ クライアントにログインします。テーブルを更新するための資格とアクセス権が必要です。詳細は、「ファイルのセキュリティ上の留意点」を参照してください。

4. このシェルのコマンド検索パスに /usr/lib/nis を追加します。

5. nisaddent を使用して、次の必要なファイルを 1 つずつ転送します。

   aliases
   bootparams
   ethers
   group
   hosts
   netgroup
   netmasks
   networks
   passwd
   protocols
   rpc
   services
   shadow

6. publickey ファイルを転送します。

7. オートマウンタ情報を転送します。

8. 複製サーバーに対して nisping を実行します。

9. テーブルにチェックポイントを実行します。

ファイルのセキュリティ上の留意点

NIS+ テーブルは、NIS+ クライアントまたは NIS+ ルートマスターサーバーから生成できます。NIS+ テーブルを生成するには、スーパーユーザー (root) としてログインする必要はありませんが、一定の資格とアクセス権は必要です。テーブル内のエントリをテキストファイルのエントリによって置換またはマージする場合、そのテーブルへの作成権と削除権が必要です。新しいエントリを追加する場合、作成権だけが必要です。

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

この処理が完了した後、テーブルエントリは、動作を実行した NIS+ 主体と、環境変数 NIS_GROUP によって指定されたグループによって所有されます。

前提条件

• ドメインをあらかじめ設定していて、そのマスターサーバーを実行していなければなりません。

• ドメインのサーバーには、新しいテーブル情報を収容できるだけの十分なスワップ領域が必要です。NIS+ の要件については、『NIS+ への移行』を参照してください。

• ファイル内の情報は、ロード先のテーブルに合った書式で書かれていなければなりません。対応する NIS+ テーブルに転送するテキストファイルで要求される書式については、「nispopulate を実行するための前提条件」を参照してください。ローカルの /etc 内のファイルは、正しい書式で書かれているのが普通ですが、いくつかのコメントを削除しなければならないこともあります。

• マシン名とユーザー名は重複しないようにしてください。ユーザーとマシンは、すべて固有の名前を付ける必要があります。また、ユーザーと同じ名前の付いたマシンは使用できません。

• マシン名にはドット (ピリオド) および下線は使用できません。たとえば、sales.alpha というマシン名は無効です。ドットや下線の代わりにハイフンを使うことはできます。たとえば、sales-alpha というマシン名は有効です。

必要な情報

転送されるテキストファイルの名前と位置が必要です。

NIS+ テーブルをファイルから生成する - タスクマップ

NIS+ テーブルをファイルから生成する方法

1. データを転送する各ファイルをチェックします。

   不正なエントリがないことを確認します。正しいデータが、所定の場所に正しい書式で記録されていることを確認します。エントリのうち、古いもの、無効なもの、破損しているものは削除します。また、不完全なエントリや一部のみのエントリも削除します。不完全なエントリは、設定を完了した後に追加する方が、不完全なエントリや破損したエントリを転送するよりも簡単です。

2. 転送する各ファイルの作業用コピーを作成します。

   このセクションで説明する実際のファイル転送の手順では、作成した作業用コピーを使用します。各作業用コピーには、同じファイル名拡張子を付けます (たとえば、.xfr)。

   rootmaster% cp /etc/hosts /etc/hosts.xfr

   万が一に備えて、使用する予定のすべてのファイルを /etc 以外のディレクトリにコピーしておくのもよいでしょう。nisaddent コマンドと nispopulate コマンドでは、ファイルソースディレクトリを指定できます。

3. NIS+ クライアントにログインします。

   この作業はどの NIS+ クライアントからでも実行できます。ただし、そのクライアントは、情報の転送先となるテーブルと同じドメインに所属していなければなりません。ここで示す例では、ルートマスターサーバーを使用します。これらの例では、システム管理者はスーパーユーザーとしてログインしているため、この操作を実際に実行している (適切な資格とアクセス権を必要とする) NIS+ 主体は、ルートマスターサーバーです。

   しかし、NIS+ テーブルを更新するだけであれば、あえてルートマスターサーバーにスーパーユーザー (root) としてログインする必要はありません。スーパーユーザーであれ、一般ユーザーであれ、一定の資格、権限、許可さえあれば、どのマシンからでも NIS+ テーブルを更新できます。

4. このシェルのコマンド検索パスに /usr/lib/nis を追加します。

   テーブルごとに /usr/lib/nis/nisaddent コマンドを使用するため、検索パスに /usr/lib/nis を追加しておくと、毎回これを入力する必要がありません。ここでは、C シェルユーザーの場合と Bourne シェルまたは Korn シェルのユーザーの場合の 2 つの例を示します。

   C シェルの場合

   rootmaster# setenv PATH $PATH:/usr/lib/nis

   Bourne または Korn シェルの場合

   rootmaster# PATH=$PATH:/usr/lib/nis rootmaster# export PATH

5. nisaddent を使用して、次のファイルを 1 度に 1 つずつ転送します。

   aliases
   bootparams
   ethers
   group
   hosts
   netgroup
   netmasks
   networks
   protocols
   rpc, services

   publickey、automounter、passwd および shadow の各ファイルは、実行する手順がそれぞれ少し異なります。publickey ファイルの場合は、手順 6 に、automounter ファイルの場合は、手順 7 に、passwd ファイルと shadow ファイルの場合は、手順 8 に進んでください。

   デフォルトでは、nisaddent はファイル情報をテーブル情報に追加します。置換またはマージを行うには、-r または -m オプションを使用します。

   置換する場合、次のように入力します。

   rootmaster# nisaddent -r -f filename table[domain]

   追加する場合、次のように入力します。

   rootmaster# nisaddent -a -f filename table [domain]

   マージする場合、次のように入力します。

   rootmaster# nisaddent -m -f filename table [domain]

   初めてテーブルを生成する場合は、デフォルトの -a オプションが最適です。NIS+ テーブルを NIS マップまたは /etc 内のファイルと同期させるための最適なオプションは -m (マージ) オプションです。

   • filename はファイル名です。通常は、nisaddent によって作成されたことを示す .xfr をファイル名の最後につけます。

   • table は NIS+ テーブル名です。domain 引数は省略可能で、テーブルを別のドメインに生成するときに使用します。ルートドメインのマスターサーバーから入力されたいくつかの例を次に示します。これらのファイルは、/etc 内のファイルを編集したものです。

   rootmaster# nisaddent -m -f /etc/hosts.xfr hosts rootmaster# nisaddent -m -f /etc/groups.xfr groups

   この作業をルート以外のサーバーから実行する場合、ルート以外のサーバーは、サポートするドメインの上のドメインに所属することに注意してください。つまり、ルート以外のサーバーはもう一つのドメインのクライアントです。たとえば、sales.doc.com. マスターサーバーは doc.com. ドメインに所属します。そのマスターサーバーからテーブルを sales.doc.com. ドメインに生成するには、nisaddent 文に sales.doc.com. ドメイン名を追加しなければなりません。たとえば、次のようになります。

   salesmaster# nisaddent -f /etc/hosts.xfr hosts Sales.doc.com.

   この作業を sales.doc.com. ドメインのクライアントとして実行した場合、このコマンドにドメイン名を指定する必要はありません。nisaddent については、『Solaris ネーミングの管理』のテーブルに関連する章を参照してください。

   エントリが NIS+ テーブルに転送されたことを確認するには、niscat コマンドを使用します 。詳細は、『Solaris ネーミングの管理』のテーブルに関する章を参照してください。

   rootmaster# niscat groups.org_dir root::0:root other::1:: bin::2:root,bin,daemon .

   障害追跡のこつ：　niscat を実行しても表示された内容が反映されてない場合、変更がマスターサーバーから複製サーバーに送られていないためかもしれません。そのような場合は、5 〜 10 分後にもう一度 niscat の実行を試みるか、niscat に -M オプションを付けて実行してください。-M オプションを付けると、マスターサーバーのデータが取得されます。

6. publickey ファイルを転送します。

   ドメインの cred テーブルには、すでにいくつかの資格が格納されているため、この cred テーブルに転送する publickey テキストファイルの内容によって、これらの資格が上書きされないよう確認する必要があります。これを避けるには、publickey テキストファイルからこれらの資格を取り除きます。rootmaster で次のような行がある場合は、すべて削除してください。

   unix.rootmaster@doc.com public-key:private-key [alg-type]

   こうすれば、publickey ファイルの内容を cred テーブルに転送できます。nisaddent に -a (追加) オプションを付けて実行します。

   rootmaster# nisaddent -a -f /etc/publickey.xfr -t cred.org_dir publickey [domain]

   ただし、この操作は DES 資格を cred テーブルに転送するだけです。主体は、cred テーブルに対する自分の LOCAL 資格を作成する必要があります。

7. オートマウンタ情報を転送します。

   nissetup ユーティリティは auto_master テーブルと auto_home テーブルを作成しますが、これらは標準の NIS+ テーブルとはみなされません。したがって、これらのテーブルに情報を転送するには、少し異なる構文が必要となります。特に、-t フラグを使用し、そのテーブルが key-value 形式であることを指定しなければなりません。

   rootmaster# nisaddent -f auto.master.xfr -t auto_master.org_dir key-value rootmaster# nisaddent -f auto.home.xfr -t auto_home.org_dir key-value

8. NIS+ passwd テーブルを作成します。

   NIS+ の passwd テーブルは、/etc/passwd および /etc/shadow の両方のディレクトリのファイルから引き出されるデータで構成されます。このため、nisaddent を 2 回実行して passwd テーブルを作成しなければなりません。passwd テーブルを対象として /etc/passwd ファイルからデータを引き出す場合と、shadow テーブルを対象として /etc/shadow ファイルからデータを引き出す場合の 2 回実行します。shadow ファイルに対して nisaddent を実行する場合、shadow テーブルが存在しなくても、ターゲットテーブルに shadow を指定すること、そしてデータが実際に passwd テーブルの shadow 列に配置されることに注意してください。

   rootmaster# nisaddent -m -f /etc/passwd.xfr passwd rootmaster# nisaddent -m -f /etc/shadow.xfr shadow

9. nisping を実行して更新内容を複製サーバーに送ります。

   nisping を実行すると、複製サーバーに変更が反映されます。

   master1# nisping domain master1# nisping org_dir.domaincom. master1# nisping groups_dir.domain

10. テーブルに対しチェックポイントを実行します。

    ここまでの手順で、マスターサーバーと複製サーバーの NIS+ データセットがメモリ内で更新されました。今度はそれをディスク上のテーブルファイルに書き込みます。この作業を「チェックポイント」といいます。チェックポイントは必ずしもここで実行しなければならないわけではありません。定期的に実行しさえすればいいのですが、重要な変更を加えた場合は、できるだけ早い機会にディスクに書き込むことをお勧めします。

    この手順により、ドメインをサポートしている全サーバーは、それらの .log ファイルからディスク上のテーブルのコピーに新しい情報を転送します。ルートドメインを設定したばかりの場合、そのルートドメインにはまだ複製サーバーがないため、この手順はルートマスターサーバーだけが対象となります。チェックポイントを実行するには nisping コマンドに -C (大文字) オプションを付けて実行します。

    rootmaster# nisping -C org_dir Checkpointing replicas serving directory org_dir.doc.com. : Master server is rootmaster.doc.com. Last update occurred at July 14, 1997 Master server is rootmaster.doc.com. checkpoint succeeded.

    スワップ空間が不足している場合、サーバーはチェックポイントを正常に実行できませんが、そのことを通知してくれません。スワップ空間が十分あることを確認する方法として、niscat コマンドを使ってテーブルの内容をリスト表示する方法があります。スワップ空間が不足している場合、次のエラーメッセージが表示されます。

    can't list table: Server busy, Try Again.

    このメッセージ内容からはわかりませんが、これはスワップ空間の不足を示しています。スワップ空間を増やし、このドメインに再びチェックポイントを実行します。

NIS+ テーブルを NIS マップから生成する方法

ここでは、NIS マップの内容を NIS+ テーブルに転送します。手順を次に示します。

1. データを転送する各 NIS マップの内容を確認します。

2. NIS+ クライアントにログインします。

3. このシェルのコマンド検索パスに /usr/lib/nis を追加します。

4. nisaddent を使用して、次のマップ を 1 つずつ転送します。

   aliases
   bootparams
   ethers
   group
   hosts
   netgroup
   netmasks
   networks
   passwd
   protocols
   rpc
   services

5. publickey マップを転送します。

6. オートマウンタ情報を転送します。

7. nisping を実行して変更内容を複製サーバーに反映させます。

8. テーブルにチェックポイントを実行します。

マップのセキュリティ上の留意点

この作業を行うシステム管理者 (またはクライアント上のスーパーユーザー) に適切な資格とアクセス権がある限り、この作業は、どの NIS+ クライアントからでも実行できます。テーブル内のエントリを NIS マップのエントリで置換またはマージする場合、そのテーブルへの作成権と削除権が必要です。新しいエントリを追加する場合、作成権だけが必要です。

この作業が完了した後、テーブルエントリは、作業を実行した NIS+ 主体 (システム管理者である自分、またはスーパーユーザーとしてログインした場合はそのクライアント) と、環境変数 NIS_GROUP によって指定されたグループによって所有されます。

前提条件

• ドメインをあらかじめ設定していて、そのマスターサーバーを実行している

• NIS+ テーブルにロードしようとしている NIS マップ用の dbm ファイル (.pag および .dir ファイル) は、/var/yp のサブディレクトリ内にある

• マシン名とユーザー名は重複していない。ユーザーとマシンは、すべて固有の名前を付ける必要がある。また、ユーザーと同じ名前の付いたマシンは使用できない

• マシン名にはドット (ピリオド) を使用できない。たとえば、sales.alpha というマシン名にはできない。sales-alpha というマシン名は可能

必要な情報

NIS マップの名前と位置が必要です。

NIS+ テーブルを NIS マップから生成する - タスクマップ

NIS+ テーブルをマップから生成する方法

1. データを転送する各 NIS マップをチェックします。

   不正なエントリがないことを確認します。正しいデータが、所定の場所に正しい書式で記録されていることを確認します。エントリのうち、古いもの、無効なもの、破損しているものは削除します。また、不完全なエントリや一部のみのエントリも削除します。不完全なエントリは、設定を完了した後に追加する方が、不完全なエントリや破損したエントリを転送するよりも簡単です。

2. NIS+ クライアントにログインします。

   この作業はどの NIS+ クライアントからでも実行できます。ただし、そのクライアントは、情報の転送先となるテーブルと同じドメインに所属していなければなりません。ここで示す例では、ルートマスターサーバーを使用します。これらの例では、システム管理者はスーパーユーザーとしてログインしているため、この操作を実際に実行している (適切な資格とアクセス権を必要とする) NIS+ 主体は、ルートマスターサーバーです。

3. このシェルのコマンド検索パスに /usr/lib/nis を追加します。

   テーブルごとに /usr/lib/nis/nisaddent コマンドを使用するため、コマンド検索パスに /usr/lib/nis を追加しておくと、毎回これを入力する必要がありません。ここでは、C シェルユーザーの場合の例と Bourne シェルまたは Korn シェルのユーザーの場合の例を示します。

   C シェルの場合

   rootmaster# setenv PATH $PATH:/usr/lib/nis

   Bourne または Korn シェルの場合

   rootmaster# PATH=$PATH:/usr/lib/nis rootmaster# export PATH

4. nisaddent を使用して、次のマップを 1 度に 1 つずつ転送します。

   aliases
   bootparams
   ethers
   group
   hosts
   netgroup
   netmasks
   networks
   passwd
   protocols
   rpc
   services

   publickey ファイルとオートマウンタマップでは、少し手順が異なります。publickey ファイルの場合は、「NIS+ テーブルをファイルから生成する方」の 手順 6 に、オートマウンタファイルの場合は、手順 7 に進んでください。

   デフォルトでは、nisaddent はファイル情報をテーブル情報に追加します。置換またはマージを行うには、-r または -m のオプションを使用します。

   置換する場合、次のように入力します。

   rootmaster# nisaddent -r -y nisdomain table

   追加する場合、次のように入力します。

   rootmaster# nisaddent -a -y nisdomain table

   マージする場合、次のように入力します。

   rootmaster# nisaddent -m -y nisdomain table

   初めてテーブルを生成するときに最適なオプションは、デフォルトの -a オプションです。NIS+ テーブルを NIS マップまたは /etc 内のファイルと同期させるための最適なオプションは -m (マージ) オプションです。

   -y (小文字) オプションは、テキストファイルではなく、NIS ドメインを示します。nisdomain 引数は、ユーザーが NIS+ テーブルに転送しようとしているマップを持つ NIS ドメインの名前です。実際のマップを指定する必要はありません。nisaddent ユーティリティは、table 引数に対応する NIS マップを自動的に選択します。

   rootmaster# nisaddent -m -y olddoc hosts rootmaster# nisaddent -m -y olddoc passwd rootmaster# nisaddent -m -y olddoc groups

   最初の例では、olddoc (NIS) ドメイン内の hosts.byname マップと hosts.byaddr マップの内容を、ルートドメイン (NIS+) 内の NIS+ hosts テーブルに転送します。2 番目の例では、パスワード関連情報を格納している NIS マップを、NIS+Passwd テーブルに転送します。3 番目の例では、グループ関連情報で同じことを実行します。nisaddent コマンドの詳細は、『Solaris ネーミングの管理』のテーブルに関連する章を参照してください。

5. publickey マップを転送します。

   ドメインの cred テーブルには、すでにいくつかの資格が格納されているため、cred テーブルに転送する publickey マップの内容によって、これらの資格が上書きされないように確認する必要があります。

   1. 初めに、publickey マップをファイルにダンプします。続いて、テキストエディタでそのファイルをオープンします。たとえば、次のように入力します。

      rootmaster# makedbm -u /var/yp/olddoc/publickey.byname /etc/publickey.xfr rootmaster# vi /tmp/publickey.tmp

   2. publickey マップから、ログインしているワークステーションの資格を削除します。

      rootmaster に対しては、次のような行は、すべて削除してください。

      unix.rootmaster@doc.com public-key:private-key [alg-type]

   3. これにより、マップではなく「ファイル」の内容を cred テーブルに転送できます。nisaddent に -a (追加) オプションを付けて実行します。

      rootmaster# nisaddent -a -f /etc/publickey.xfr -t cred.org_dir Publickey

      ただし、この操作は DES 資格を cred テーブルに転送するだけです。cred テーブルに対する自分の LOCAL 資格は自分で作成する必要があります。

6. オートマウンタ情報を転送します。

   nissetup ユーティリティは auto_master テーブルと auto_home テーブルを作成しますが、これらは標準の NIS+ テーブルとはみなされません。したがって、これらのテーブルに情報を転送するには、少し異なる構文が必要となります。

   rootmaster# nisaddent -y olddoc -Y auto.master -t auto_master.org_dir key-value rootmaster# nisaddent -y olddoc -Y auto.home -t auto_home.org_dir key-value

   NIS ドメイン名 (この例では olddoc) と同様、-m と -y のオプションが必要です。しかし、NIS マップ名 (auto.master など) の前には -Y (大文字) を付けなければなりません。次に、オートマウンタの「テキストファイル」を転送するときに必要なように、標準の NIS+ テーブルであることを示す -t オプションを使用しなければなりません。この引数は、NIS+ ディレクトリオブジェクト (auto_master.org_dir) とテーブルの種類 (key-value) です。NIS+ テーブル名の後ろには必ず接尾辞 org_dir を追加してください。

7. nisping を実行して更新内容を複製サーバーに送ります。

   nisping を実行すると、複製サーバーに変更が反映されます。

   master1# nisping domain master1# nisping org_dir.domaincom. master1# nisping groups_dir.domain

8. テーブルに対しチェックポイントを実行します。

   この手順により、ドメインをサポートしている全サーバーが、それらの .log ファイルからディスク上のテーブルのコピーに新しい情報を転送します。ルートドメインを設定したばかりの場合、そのルートドメインにはまだ複製サーバーがないため、この手順はルートマスターサーバーだけが対象となります。nisping コマンドに -C (大文字) オプションを付けて実行します。

   rootmaster# nisping -C org_dir Checkpointing replicas serving directory org_dir.doc.com. : Master server is rootmaster.doc.com. Last update occurred at July 14, 1994 Master server is rootmaster.doc.com. checkpoint succeeded.

   スワップ空間が不足している場合、サーバーはチェックポイントを正常に実行できませんが、そのことを通知しません。スワップ空間が十分あることを確認する方法として、niscat コマンドを使ってテーブルの内容をリスト表示する方法があります。スワップ空間が不足している場合、次のエラーメッセージが表示されます。

   can't list table: Server busy, Try Again.

   このメッセージ内容からはわかりませんが、これはスワップ空間の不足を示しています。スワップ空間を増やし、このドメインに再びチェックポイントを実行します。