test

Solaris のシステム管理 (ネーミングとディレクトリサービス : FNS、NIS+ 編)

パート V ネームサービス間の移行

このパートでは、NIS から NIS+ への移行方法および NIS+ から LDAP への移行方法について説明します。

第 26 章 NIS から NIS+ への移行

この章では、NIS ネームサービスから NIS+ ネームサービスへの変換方法について説明します。ここでは、2 つのネームサービスの違いについて説明し、推奨する移行方法の概要を示します。

注 -

NIS+ は、将来のリリースでサポートされない可能性があります。NIS+ から LDAP への移行支援ツールは、Solaris 9 オペレーティング環境で使用できます (パート V を参照)。 詳細については 、http://www.sun.com/directory/nisplus/transition.html を参照してください。

NIS と NIS+ の相違

NIS と NIS+ の間には、移行に影響を与える相違点がいくつかあります。たとえば、NIS は、1 つのドメイン (またはいくつかの別々のドメイン) を持つ平坦な (階層型ではない) 名前空間を使用しますが、NIS+ は、DNS に似たドメイン階層を使用します。このため、NIS+ に変換する前に、NIS+ の名前空間を設計する必要があります。また、 NIS+ にはセキュリティを強化するための機能があります。これにより、名前空間内の情報だけでなく、名前空間の構造的な構成要素へのアクセスも制限されます。

このような相違点から、NIS+ が単に NIS をアップグレードしたものではなく、完全に新しい製品であることがわかります。NIS から NIS+ へ移行する際は、主にこれらの製品間の相違がポイントになります。

この章では、これらの相違点について、次に示す一般的な用語を使って説明します。NIS+ への移行を正しく行うには、これらの用語を理解することが重要です。

ドメインの構造

NIS+ は、NIS に置き換わるものとして設計されており、単に NIS をアップグレードしたものではありません。このことは、NIS+ のドメイン構造を調べると明らかです。NIS のドメインは平坦で、階層を持つことができません。これに対して、NIS+ のドメインは平坦な場合もありますが、階層構造のドメインを作成できます。この階層は、ルートドメインと、その下の任意の数のサブドメインから構成されます。

NIS のドメイン構造は、1980 年代に一般的であったクライアントとサーバー間のコンピューティングネットワークの管理の要件に対応したものでした。つまり、数百のクライアントと少数の多目的サーバーを持つ、クライアントとサーバー間のネットワークを対象としていました。

NIS+ は、世界中のサイトの専用サーバー 10〜100 台によってサポートされるクライアント 100〜10000 台をサポートするネットワークを対象としています。こうしたネットワークは、複数の「信頼性の低い」公衆ネットワークに接続されています。このようなネットワークの規模と構成を維持するには、新しい独立した管理方式が必要です。NIS+ のドメイン構造は、これらの要件を満たすように設計されています。NIS+ のドメイン構造は、次の図に示すように、DNS のドメイン構造に似ています。

図 26-1 NIS+ のドメイン

Graphic

ドメインを階層構造にすると、規模の小さいものから非常に大きいものまで、広い範囲のネットワークに NIS+ を使用することができます。また、NIS+ のサービスを組織の成長に対応させることもできます。NIS+ ドメイン構造の詳細については、「ドメイン」 を参照してください。

DNS、NIS、NIS+ の相互運用性

NIS+ が提供する相互運用性とは、NIS からの移行と、NIS サービスによって提供されていた DNS とを継続して併用できることを意味します。 NIS+ には、NIS からの移行に役立つ NIS 互換モードと情報転送ユーティリティがあります。NIS 互換モードを使用すれば、Solaris オペレーティング環境で動作している NIS+ サーバーは、NIS+ クライアントからの要求に応答しながら、NIS クライアントからの要求にも応答できます。また、管理者は、情報転送ユーティリティを使って NIS のマップと NIS+ のテーブルを同期させることができます。

NIS 互換モードの設定に必要な手順は、標準 NIS+ サーバーで使用する手順と若干異なります。また、NIS 互換モードは、NIS+ 名前空間内のテーブルとセキュリティ上の関連を持っています。

NIS+ サーバーが NIS 互換モードで実行されている場合、NIS のクライアントコンピュータは、 NIS+ のクライアントコンピュータとは異なる方法で NIS+ 名前空間にアクセスします。次にこの違いを示します。

Solaris 2.3 では、NIS 互換モードで DNS 転送をサポートします。Solaris 2.2 では、DNS 転送を可能にする「パッチ (patch #101022-06)」が提供されています。DNS 転送を可能にするパッチは、Solaris 2.0 と 2.1 では利用できません 。

NIS+ ドメインは、インターネットに直接接続できません。ただし、NIS+ クライアントマシンは、ネームサービススイッチ経由でインターネットに接続できます。クライアントのスイッチ構成ファイル (/etc/nsswitch.conf) を設定して、NIS+ テーブル以外に、DNS ゾーンファイルまたは NIS マップの情報をクライアントから検索できます。

サーバーの構成

NIS+ のクライアント サーバー構成は、各ドメインが複数のサーバーによってサポートされているという点で、NIS と DNS の構成に似ています。メインサーバーは「マスターサーバー」と呼ばれ、バックアップサーバーは「複製サーバー」と呼ばれます。マスターサーバーと複製サーバーの両方で NIS+ サーバーソフトウェアが動作しており、NIS+ テーブルのコピーを維持しています。

ただし、NIS+ では、NIS の場合とはまったく異なる方法でデータベースが更新されます。NIS が開発された時点では、NIS が格納する情報のほとんどが静的なものと想定されていました。したがって、NIS の変更は手作業で処理し、そのマップ内の情報が変更されるたびにマップを作成しなおし、すべてを伝達させる必要があります。

これに対して NIS+ では、複製サーバーに対して変更分だけの更新ができます。マスタサーバー上のマスタデータベースを変更する必要はありますが、変更内容は複製サーバーにも自動的に伝達されます。「make」マップを再度作成したり、情報が伝達されるまで何時間も待つ必要はありません。伝達は、3 〜 4 分で終了します。

情報の管理

NIS+ は、マップやゾーンファイルではなく、「テーブル」に情報を格納します。NIS+ には、図 26-2 に示すように、17 種類の定義済みテーブル (システムテーブル) があります。

図 26-2 NIS+ の標準テーブル

Graphic

NIS+ テーブルは、ASCII ファイルでなく、NIS+ リレーショナルデータベース内のテーブルです。NIS+ テーブルの内容は、NIS+ のコマンドを使用しなければ表示したり編集したりできません。

NIS+ テーブルには、NIS で使用したマップに比べて大きく改善された機能が 2 つあります。その 1 つは、NIS+ テーブルを、最初の列 (「キー」とも呼ぶ) だけでなく、任意の検索可能な列によって検索できるという機能です。特定の列が検索可能であるかどうかを知るには、テーブルに対して niscat -o コマンドを実行してください。コマンドは、そのテーブルの列と属性のリストを返します。この検索機能により、NIS によって使用される hosts.byname マップと hosts.byaddr マップのような重複するマップを持つ必要性がなくなります。もう 1 つは、NIS+ テーブル内の情報に対して、テーブルレベル、エントリ (行) レベル、列レベルという 3 つのレベルでアクセスを制御できることです。

NIS マップがサーバーのディレクトリ /var/yp/domainname に置かれるのに対して、NIS+ ディレクトリは /var/nis/data に置かれます。NIS+ テーブルはデータベースの中に格納されます。テーブルの情報は、データベースへの要求が出されると、メモリーに読み込まれます。データを要求された順序でメモリーに保存すると、ディスクへのアクセスを最小限に抑えられるため、要求への応答時間を短縮することができます。

セキュリティ

NIS+ のセキュリティ機能は、名前空間の情報と名前空間そのものの構造を不正なアクセスから保護します。NIS+ のセキュリティ機能は、「認証」と「承認」という 2 つの手段によって行われます。 認証とは、NIS+ サーバーが、特定の要求を送信した NIS+ の「主体」(クライアントユーザーまたはクライアントマシン) を識別する処理を指します。承認とは、サーバーが、その主体 (クライアントマシンまたはクライアントユーザー) に許可されたアクセス権を識別する処理を指します。

つまり、最高レベルの NIS+ セキュリティ機能がサイトに導入されている場合、名前空間内の情報にアクセスするには認証された NIS+ クライアントでなければならず、その情報にアクセスするための適切なアクセス権を持っていなければなりません。さらに、名前空間へのアクセス要求は、NIS+ のクライアントライブラリルーチンか NIS+ の管理コマンドによって行われた場合にだけ有効になります。また、NIS+ のテーブルと構造を直接編集することはできません。

推奨する移行手順

次に、NIS から NIS+ への移行において推奨する移行手順の概略を示します。

  1. 基本的な移行の方針について確認します。

  2. NIS+ について理解します。

  3. 最終的な NIS+ 名前空間を設計します。

  4. セキュリティの方式を選択します。

  5. NIS 互換モードの使用方法を決定します。

  6. 移行の準備を完了します。

  7. 移行を実行します。

この章の以下の部分では、上記の手順の各段階について詳しく説明します。

移行の方針

移行を開始するにあたって、次に示す基本的な方針を確認してください。

移行をすぐに実行するのではなく、別の方法を考慮する

NIS+ へのアップグレードは、NIS+ を Solaris オペレーティング環境に完全に移行した段階で行ってもかまいません。このようにすれば、リソースを移行作業だけに利用することができます。NIS を Solaris オペレーティング環境上で稼動しながら、NIS+ への移行を準備することができます。

処理を簡略化する

いくつかの手順により、移行を簡略にすることができます。これらの手順を実行すると、NIS+ の効果は減少しますが、サーバーの台数は少なくて済み、管理に要する時間も減ります。移行が完了すれば、NIS+ の設定を変更して、サイトの要求に完全に適合させることができます。次にいくつかの推奨事項を示します。

1 種類のソフトウェアリリースを使用する

移行に使用する Solaris オペレーティング環境と NIS+ のバージョンを決定します。各バージョン間には若干の違いがあるため、複数のバージョンを同時に使用すると、移行の処理が不必要に複雑になります。Solaris 製品の 1 バージョンだけを選択して、それに対応するバージョンの NIS+ を使用してください。

現在のリリースは、設定スクリプトなどのほとんどの機能を備えています。通常の操作に必要な Solaris 2.6 のパッチを用意し、すべてのサーバーとクライアントに同じパッチがインストールされていることを確認してください。

クライアントユーザーへの影響を最小限に抑える

クライアントユーザーに関して、考慮するべき点が 2 つあります。1 つは、ユーザーがサービスの変更に気が付かないようにするということです。もう 1 つは、移行作業そのものがユーザーに与える混乱を最小限に抑えるということです。2 番目のポイントについては、ユーザーに移行作業を要求するのではなく、必ず各ドメインの管理者がそのクライアントマシンの NIS+ への移行作業を行うようにすれば解決できます。これにより、正しい手順が実行され、その手順がクライアントマシン全体でも一貫して実行されます。したがって、問題があっても、管理者がただちに処理することができます。

禁止事項

NIS+ について理解する

NIS+ に関する理解を深めておいてください。特に、この章の前半で要約した概念 (このマニュアルの後半で詳しく説明します) については、よく理解しておく必要があります。

NIS+ を理解するための最もよい方法の 1 つは、プロトタイプの名前空間を作成することです。製品を実際に経験するということに優る方法はありません。システム管理者には、業務に支障をきたさないテスト環境での練習が必要です。

注 -

プロトタイプのドメインを、実際の NIS+ 名前空間としては使用しないでください。プロトタイプですべてを学んだら、そのプロトタイプは削除して、名前空間の構成上の問題が起こらないようにします。計画をすべて終えたら、新しく実際の名前空間を作成してください。

テストドメインを作成するときは、小規模の管理しやすいドメインを作成してください。NIS+ 設定スクリプトを使用して、単純なテストドメインとサブドメインを計画および作成する方法 (NIS 互換モードも使用可能) については、「NIS+ 名前空間サンプルの作成」 を参照してください。

注 -

NIS+ 名前空間を設定するときは、説明に従って NIS+ スクリプトを利用することをお勧めします。この手順では、最初に NIS+ スクリプトを使用して、基本的な NIS+ 名前空間を設定します。続いて NIS+ コマンドセットを使用して、各自のニーズに合わせて名前空間をカスタマイズします。

最終的な NIS+ 名前空間を設計する

「NIS+ 名前空間の設計 - 管理モデルの目的を明らかにする」の指針に従って、最終的な NIS+ 名前を設計します。名前空間の設計中は、NIS からの移行によって生じる制限を気にする必要はありません。これらの制約は、最終的な NIS+ の目的を明確にしてから変更することができます。

セキュリティの方式を選択する

NIS+ のセキュリティは、ユーザーと管理者にとって非常に有益ですが、ユーザーにも管理者にも、より詳しい知識と設定作業が必要になります。 また、計画上の決定をいくつか行う必要もあります。「NIS+ セキュリティの影響について理解する」では、NIS+ セキュリティの持つ意味と、NIS+ 名前空間でセキュリティを使用する場合に必要な決定事項について説明します。

NIS 互換モードの使用方法を決定する

移行の間は、NIS と NIS+ の名前空間を並行して使用することは事実上避けられません。2 つの名前空間を同時に使用するには、さらに資源を追加する必要があるため、各サイトが二重のサービスを使用する時間、または名前空間内の二重サービスの適用範囲を減らす (たとえば、可能なかぎり多くのドメインを NIS+ に変換するなど) ように努めてください。

「NIS+ への移行の準備 - 他システムに対する NIS+ の影響を調べる」では、NIS 互換モードに関連する移行の問題を説明し、 NIS から、NIS 互換を経由して、NIS+ へ完全に移行する方法を示します。

移行を実行する

「NIS+ の実装の概要」では、推奨される一連の手順を示して、それまでに計画した移行を実際に実行します。

NIS+ 名前空間の設計 - 管理モデルの目的を明らかにする

名前空間を設計するときは、NIS からの移行によって生じる制限を気にしないでください。NIS+ ドメインは、後で最終的な NIS+ 構成がどのようになるかがわかってから変更することができます。

ドメイン構造など、各サイトで使用する情報管理のモデルを選択します。各サイトでの情報の作成、格納、使用、管理について明確な方針がないと、この節で示す設計の決定を行うことが困難になります。たとえば、作業に必要以上の経費がかかる設計をしてしまう可能性があります。また、要求に合わない名前空間を設計してしまうおそれもあります。一度設定した名前空間の設計の変更には時間と手間がかかります。

名前空間の構造を設計する

NIS+ 名前空間の設計は、いろいろな作業の内で最も重要なものの 1 つです。これは、 NIS+ を一度設定した後にドメイン構造を変更するのは、時間のかかる複雑な作業になるからです。この作業が複雑になるのは、情報、セキュリティ、管理の各方針が名前空間のドメイン構造に組み込まれているからです。ドメインを編成しなおす場合は、情報の再編成、セキュリティの再設定、管理方針の再設計が必要になります。

NIS+ 名前空間の構造を設計するときは、この章の以下の節で説明する要素を考慮してください。

ドメインの階層

NIS+ ドメイン階層には、名前空間をより管理しやすい複数の構成要素に分割できる、という利点があります。各構成要素には独自のセキュリティ、情報管理、管理方針を持たせることができます。クライアントの数が 500 を超える場合、あるユーザーグループに異なるセキュリティに方針を設定したい場合、あるいは地理的に分散したサイトがある場合は、階層を使用することをお勧めします。

ドメイン階層の必要がなければ、階層を使用しません。こうすることにより、NIS+ への移行が簡略化されます。すべてのユーザーが同じ NIS ドメイン内にいる場合、これらのユーザーは、完全指定名を使用しなくてもお互いを直接認識することができます。しかし、NIS+ 階層を作成すると、ユーザーは別々のドメインに置かれます。つまり、完全指定名か完全指定パスを使用しないかぎり、あるドメインにいるユーザーは別のドメインにいるユーザーを直接認識することができません。

たとえば、sales.com. および factory.com. というサブドメインが、 .com. ドメインから作成されているとします。このとき、sales.com. ドメインのユーザー juan が factory.com. ドメインのユーザー myoko にメールを送信するには、送信先のユーザー名を myoko ではなく myoko@hostname.factory.com. または myoko@hostname.factory と指定する必要があります。送信先のユーザーが同じドメインに存在する場合は、myoko だけでかまいません。リモートログインでもドメイン間の完全指定名が必要です。

テーブル間のパスを使用すると、あるドメインのテーブルと別のドメインのテーブルとの間に接続を設定することができますが、ドメイン階層を使用するメリットはなくなります。また、NIS+ サービスの信頼性も低くなります。これは、クライアントが、各自のホームドメインの利用状況だけでなく、各自のテーブルにパス指定される他のドメインの利用状況にも依存するようになるためです。テーブル間のパスを使用すると、要求への応答時間も長くなります。

ドメインの階層 - Solaris 2.6 以前のリリース

Solaris 2.6 以前のリリースでは、各サブドメインの NIS+ サーバーは、そのドメインではなく、親ドメインに含まれます。ただし、ルートドメインは除きます。サーバーとサブドメインの関係がこのような関係になっていると、サーバーがネームサービスデータをサブドメインから取得できることを想定しているアプリケーションの場合に、問題が発生します。たとえば、サブドメインの NIS+ サーバーが NFS サーバーを兼ねている場合、サーバーはネットグループ情報をサブドメインからは取得しません。代わりに、サブドメインの上位ドメインからネットグループ情報を取得します。 この点に注意してください。階層によって問題が発生する可能性がある場合の別の例としては、遠隔ログインするユーザーが自分のマシンからでは実行できないコマンドを実行する場合に、この NIS+ サーバーも使用する場合です。ルートドメインが 1 つしかない場合には、NIS+ ルートサーバーは自分がサーバーであるドメイン内にいるので、このような問題は発生しません。

ドメインの階層 - Solaris 9

Solaris オペレーティング環境では、ドメインの NIS+ サーバーは、自分がサーバーであるドメイン内に存在できます。したがって、サーバーはクライアントが使用している名前をドメイン名に設定することができます。残りのドメインの階層との機密保護通信を実行できるサーバーの機能には影響を与えません。

ドメインの階層を設計する

ドメイン階層を使い慣れていない場合は、まず 第 2 章「NIS+ の紹介」 を参照してください。 このマニュアルでは、NIS+ のドメイン構造、情報の格納、セキュリティについて説明しています。

ドメイン階層の各構成要素を理解したら、最終的な階層を示す図を作成します。この図は、設定手順を進めるうえで非常に参考になります。少なくとも、次の問題について考慮する必要があります。

ドメインは 1 つのオブジェクトではなく、オブジェクトの集合に対する参照であることを忘れないでください。したがって、ドメインをサポートするサーバーは、実際にはドメインと関連しないでドメインのディレクトリと関連しています。ドメインは、次の図に示すように、domain、ctx_dir. domain、org_dir.domain、およびgroups_dir.domain という 4 つのディレクトリで構成されます。

図 26-3 サーバーとドメインの関係

Graphic

組織的または地理的な構造による階層

NIS+ の主な利点の 1 つに、名前空間をより小さく、より管理しやすい部分に分割できるという機能があります。たとえば、次の図 (仮想企業 Doc Inc. の階層) のような組織の階層を作成できます。

図 26-4 論理的な組織構造による NIS+ 階層の例

Graphic

次の図に示すように、組織ではなく建物によって階層を構成することもできます。

図 26-5 物理的な位置による NIS+ 階層の例

Graphic

どの構成を選択するかは、主に名前空間の管理方法とクライアントによる名前空間の使用方法によって決まります。たとえば、factory.com. ドメインに属するクライアントが Doc Inc. の建物全体に分散している場合は、名前空間を建物によって構成しないでください。 クライアントは他のドメインに常にアクセスしなければならないため、他のドメインへの資格をクライアントに与えなければならず、ルートマスタサーバーとの通信量が増加します。この場合は、組織ごとにクライアントを構成してください。これに対して、建物に基づくドメインは、組織に変更があっても影響を受け付けません。

ネットワークの物理的配置による制限を受けないようにしてください。NIS+ 名前空間は、NIS クライアントをサポートしなければならない場合を除いて、物理的ネットワークに一致する必要はありません。名前空間で必要なドメインの数は、選択した階層の種類によって決まります。

今後の拡張計画を検討します。現在の NIS+ ルートドメインが、将来別の NIS+ ドメインの下に配置されるかどうかを検討してください。現在の設定を変更するには、膨大な作業が必要になります。名前空間での今後のドメインの必要性を見積って、混乱なくそれらのドメインを収容できる構造を設計してください。

上位ドメインへの接続

NIS+ 名前空間をインターネットや DNS のドメインなどの上位ドメインに接続するかどうかを検討します。現在 DNS 階層のもとで NIS を使用している場合は、NIS+ 名前空間に、 NIS ドメインだけを置き換えるか、サイト全体の DNS/NIS 構造を置き換えるかを決めます。

ルートドメインでのクライアントサポート

図 26-4 と図 26-5 に示した Doc Inc. の 2 つのドメイン階層を例にして説明します。まず、すべてのクライアントを、ルートドメインの下のドメインに配置するかどうかを調べます。また、一部のクライアントをルートドメインに配置するかどうかを調べます。ルートドメインの目的がそのサブドメインのルートとして動作することだけかどうか、あるいはルートドメインがそれ自身のクライアントグループをサポートするかどうかを調べます。 すべてのクライアントをドメインの最下層に配置し、管理に使用するクライアントだけを中間ドメインに配置することができます。たとえば、図 26-4 でこの計画を実行すると、すべてのクライアントが big.sales.com.、small.sales.com.、factory.com. の各ドメインに配置され、管理に使用されるクライアントだけが .com. と sales.com. ドメインに配置されます。

また、汎用部門のクライアントを上位レベルのドメインに置くこともできます。たとえば図 26-5 では、.com.ドメインは建物によって構成されていて、設備部門のクライアントを .com. ドメインに置くことができます。しかし、ルートドメインは単純で比較的ゆとりのある状態に維持しておく必要があるため、この配置はお勧めできません。

ドメインの大きさとドメインの数と比較

現在 NIS+ の実装は、1 つのドメインあたり最大 1000 の NIS+ クライアント、1 つのドメインあたり最大 10 の複製サーバーを設定するように最適化されています。このようなドメインには、通常 10000 のテーブルエントリがあります。この制約は、現在のサーバー発見プロトコルに起因しています。NIS+ クライアントが 1000 を超える場合は、名前空間を異なる複数のドメインに分割して、階層を作成してください。

しかし、階層を作成すると、状況が複雑になって対処しにくくなるおそれがあります。 1 つのドメインを大きくした方が、複数の小さいドメインを作成するよりも管理が容易なため、階層ではなくより大きなドメインを作成したいと考えるかもしれません。数の少ない大きいドメインでは、各自が作成するスクリプトを使って、作業をより容易に自動化できるため、それらのドメインのサービスを担当する熟練の管理者が少なくて済み、管理に要する手間と費用を削減することができます。しかし、ドメインを小さくすると性能が向上し、各自のテーブルをより簡単にカスタマイズすることができます。また、小さいドメインでは、管理をより柔軟に行うこともできます。

レベルの数

NIS+ は、複数レベルのドメインを処理するように設計されています。NIS+ は、任意の数のレベルに対応することができますが、レベルの数が多すぎる階層は、管理が困難です。たとえば、オブジェクトの名前は、長くてややこしいものになる場合があります。したがって、1 つのドメインに対するサブドメインの数は 20 までとし、NIS+ 階層のレベルの数は 5 までに制限するようお勧めします。

セキュリティレベル

名前空間は、通常、セキュリティレベル 2 で管理します。ただし、ドメインごとに異なるセキュリティレベルを使用する場合は、ここでそのレベルを指定する必要があります。「NIS+ セキュリティの影響について理解する」では、セキュリティレベルの詳細を説明しています。

複数の時間帯にまたがるドメイン

地理的に分散した組織では、ドメイン階層を機能のグループによって構成すると、1 つのドメインが複数の時間帯にまたがることがあります。ドメインが複数の時間帯にまたがることが「決して」ないようにしてください。複数の時間帯にまたがるドメインを構成する必要があるときは、複製サーバーの時刻は、マスタサーバーの時刻に合わせられることに注意してください。これにより、データベースの更新は、万国標準時 (グリニッジ標準時) を使って正しく行われます。時刻が重要な他のサービスに複製サーバーが使用されると、このことが問題の原因となるおそれがあります。複数の時間帯にまたがるドメインを動作させるには、 NIS+ をインストールするときに、複製サーバーの /etc/TIMEZONE ファイルを、マスタサーバーの時間帯に合わせてローカルに設定する必要があります。複製サーバーがいったん動作を始めると、時刻が重要なプログラムの中には、万国標準時かローカル時刻のどちらを使用するかによって、正しく作動するものとしないものがでてきます。

情報の管理

NIS+ 名前空間の情報の管理は、中央の制約の範囲内でローカルに行うことをお勧めします。情報は、できるかぎりそのホームドメインで管理するべきですが、広域の名前空間レベルで設定された指針または方針に従ってください。これにより、ドメインの独立性を強化する一方で、ドメイン間の整合性を維持することができます。

ドメイン名

名前の長さと複雑さについて検討します。まず、内容がわかりやすい名前を選択します。たとえば、 Sales は BW23A よりも内容をわかりやすく表しています。次に、短い名前を選択します。管理業務をより簡単にするためには、あまり長い名前を付けないでください (長い名前の例: administration_services.corporate_headquarters.doc.com.。

ドメイン名は、左から右に形成され、ローカルドメインから始まって、ルートドメインで終わります。ルートドメインには、常に少なくとも 2 つのラベルがなければならず、ドットで終了しなければなりません。2 番目のラベルは、「com.」などの Internet のドメイン名にすることができます。

サイト内とインターネット全体の電子メールドメインを対象に、このドメイン固有の名前の意味について検討する必要があります。

移行の方式によっては、NIS 上のドメイン名を希望の構造に変更してから、 NIS+ ドメインに移行することもできます。

電子メール環境

NIS が平坦なドメイン空間を持つのに対して、NIS+ はドメイン階層を持つことができるため、NIS+ への移行はメール環境にも影響があります。NIS では、必要なメールホストは 1 つだけです。NIS+ でドメイン階層を使用すると、名前空間の各ドメインごとに 1 つのメールホストが必要になります。これは、各ドメインの名前が一意ではなくなるためです。

したがって、ルートドメインにないクライアントの電子メールアドレスが変更される場合があります。一般的に、クライアントの電子メールアドレスは、ドメイン名が変更されるか、または階層に新しいレベルが追加されると変更されます。

以前の Solaris のリリースでは、これらの変更に非常に手間がかかりました。このリリースでは、sendmail の拡張機能がいくつか追加され、作業が簡単になっています。さらに、NIS+ には、sendmailvars テーブルが追加されています。sendmail プログラムは、まず sendmailvars テーブル (図 26-7 を参照) を見てから、ローカルな sendmail.cf ファイルを調べます。

注 -

メールサーバーが、そのサポート対象となるクライアントの NIS+ ドメイン内にあることを確認してください。また、パフォーマンス上の理由から、 メールサーバーに対して他のドメイン内のテーブルへのパスを指定しないでください。

DNS での新しいメールアドレスの影響について検討してください。DNS の MX レコードを修正しなければならない場合があります。

サーバーの必要条件を決める

各 NIS+ ドメインは、一組の NIS+ サーバーによってサポートされています。各組は、1 つのマスタサーバーと 1 つ以上の複製サーバーを持っています。これらのサーバーは、ドメインのディレクトリ、グループ、テーブルを格納して、ユーザー、管理者、アプリケーションからのアクセス要求に応答します。各ドメインをサポートしているのは、一組のサーバーだけです。一組のサーバーで、複数のドメインをサポートすることができますが、お勧めできません。

NIS+ サービスでは、マスターサーバーを少なくとも 1 つ各 NIS+ ドメインに割り当てる必要があります。各ドメインが必要とする複製サーバーの数は、通信量の負荷、ネットワークの構成、NIS クライアントの有無などによって決まります。サーバーメモリーの量、ディスク記憶容量、プロセッサの速度は、クライアントの数とサーバー上に置かれる通信量の負荷によって決まります。

Solaris オペレーティング環境で稼動する任意のマシンを NIS+ サーバーにすることができます。ただし、ハードディスク要件を満たしていなければなりません。NIS+ のサーバー用、クライアント用のソフトウェアは、どちらも Solaris 製品に含まれています。つまり、Solaris オペレーティング環境がインストールされていれば、任意のマシンをサーバーまたはクライアント、あるいはその両方にすることができます。

NIS+ 名前空間をサポートするために必要なサーバーを決定するとき、次の節で説明する要因を考慮する必要があります。

サポートするドメインの数

まず、階層内のドメインごとに、マスターサーバーを 1 つずつ割り当てます。次の図は、可能な割り当ての例です。

図 26-6 サーバーをドメインに割り当てる

Graphic

1 つ以上の複製を各ドメインに割り当てます。複製を使うと、マスターサーバーが一時的に使用不可能な場合でも、要求に応答することができます。使用する複製の数については、「複製サーバーの数」を参照してください。

図 26-7 ドメインへの複製サーバーの追加

Graphic

複製サーバーの数

ドメインに最適なサーバーの数 (マスターと複製) は、数多くの要因によって決まります。

各種のマシンを使わないでドメインあたりの複製の数を十分なものにする 1 つの方法は、マルチホームのサーバーを作成することです。マルチホームサーバーとは、複数のイーサネットまたはネットワークインタフェースを持っているマシンをいいます。マルチホームサーバーは、1 つのドメイン内にある複数のサブネットにサービスを提供することができます (マスターあるいは複製サーバーに複数のドメインを設定することもできますが、これはお勧めできません)。

サーバーの速度

サーバーの速度が早いほど、 NIS+ のパフォーマンスは向上します (しかし、その場合 NIS+ サーバーは SMP マルチスレッドハードウェアを有効に利用することはできません)。NIS+ サーバーは、平均的なクライアントと同等かそれ以上に強力にする必要があります。 新しいクライアントのサーバーとして古いマシンを使うことはお勧めできません。

サーバーの速度以外に、その他の多くの要因が NIS+ のパフォーマンスに影響を与えます。ユーザーおよびホストの数と種類、実行しているアプリケーションの種類、ネットワークトポロジ、負荷の密度、その他の要因すべてが NIS+ のパフォーマンスに影響します。したがって、 2 つの異なるネットワークにおいて、同じサーバーハードウェアからまったく同じパフォーマンスを期待することはできません。

下の表のベンチマークは、比較のために掲載しています。各ネットワーク上のパフォーマンスは、この数字とは違うこともあります。下に示したベンチマークの数字は、10000 エントリという標準的なテーブルサイズのテストネットワークに基づいています。

表 26-2 ハードウェア速度と NIS+ 動作の比較

対象マシン 

秒当たりの整合動作数 

秒当たりの追加動作数 
 SS5-110  400  6
 SS20-50  440  6
 PPro-200  760 13
 Ultra-167  800 11
 Ultra-200 1270 8

サーバーメモリーの容量

サーバーの絶対最低メモリー必要量は 32M バイトですが、中から大規模ドメインのサーバーは少なくとも 64M バイトを装備した方が良いでしょう。

理想的には、 NIS+ サーバーは、 有効な NIS+ テーブルすべての検索可能列のエントリすべてを RAM 内に一度に保存できるほど十分なメモリーが必要です。要するに、最適なサーバーメモリーは、すべてのNIS+ テーブルが必要とするの合計メモリー必要量になります。

分かりやすくするため、下の表は検索可能列が 5 つある netgroup テーブルのメモリー必要量を示し、表 26-4 は passwd 、host および cred テーブルのおおよそのメモリー必要量を示しています。

表 26-3 netgroups テーブルに必要なサーバーメモリー

エントリの数 

サーバーメモリー使用量 ( M バイト) 
 6000 4.2
 60000 39.1
 120000 78.1
 180000 117.9
 240000 156.7
 300000 199.2

表 26-4 passwd テーブルに必要なおおよそのメモリー

エントリの数 

サーバーメモリー使用量 ( M バイト) 
 6000 3.7
 60000 31.7
 120000 63.2
 180000 94.9
 240000 125.8
 300000  159.0
 1000000 526.2

他のテーブルには、検索可能な各列に対してエントリ当たりの平均バイト数に予測エントリ数を掛けると、メモリーサイズを予測することができます。たとえば、エントリが 10,000 で検索可能列が 2 のテーブルがあるとします。最初の列でのエントリ当たりの平均バイト数は 9 で、 2 番目の列でのエントリ当たり平均バイト数は 37 です。したがって、計算結果は、 (10,000 × 9) + (10,000 × 37) = 460,000 になります。

注 -

cred テーブルのエントリ数を予測するときは、ユーザーのローカル資格証明書に 1 つ、DES 資格証明書に 1 つずつ、すべてのユーザーが 2 つのエントリを持つことを忘れないでください。各マシンが使用するエントリは 1 つだけです。

標準的な NIS+ テーブルのそれぞれにある検索可能列の数については、「NIS+ 標準テーブル」を参照してください。

サーバーのディスク容量

必要なディスク容量は、次の 4 つの要因によって決まります。

Solaris オペレーティング環境に必要なディスク容量は、インストール方法によっては、220M バイトを超えることがあります。正確な数字については、Solaris のインストールガイドを参照してください。また、サーバーが使用する他のソフトウェアの使用するディスク容量も計算に入れる必要があります。NIS+ ソフトウェア自体は、Solaris オペレーティング環境配布の一部であるため、余分なディスク容量を使用しません。

NIS+ のディレクトリ、グループ、テーブル、クライアント情報は、/var/nis に格納されています。この /var/nis ディレクトリは、1 つのクライアントごとにおよそ 5K バイトのディスク容量を使用します。たとえば、名前空間に 1000 のクライアントがあると、/var/nis には、およそ 5M バイトのディスク容量が必要になります。ただし、同じく /var/nis に格納されるトランザクションのログが大量になる場合があるため、クライアントごとにディスク容量を追加する必要があるかもしれません。この場合は 10〜15M バイトの容量を追加するようお勧めします。つまり、1000 のクライアントがあるときは、15〜20M バイトを /var/nis に割り当ててください。トランザクションのログに対して定期的にチェックポイントを実行する場合、この数字を減らすことができます。/var/nis には独立したパーティションを設けることをお勧めします。パーティションが独立していることにより、オペレーティングシステムのアップグレードを行う際、その作業が容易になります。

NIS+ を NIS と並行して使用するときは、/var/yp に対して、/var/nis に割り当てている量と同じ容量を割り当てて、NIS から転送する NIS マップを格納してください。

さらに、サーバーの通常のスワップ空間の所要量に加えて、rpc.nisd のサイズの 2 倍のスワップ空間も必要になります。システム上で rpc.nisd が使用しているメモリーの量を確認するには、 nisstat コマンドを実行します。詳細は、 rpc.nisd マニュアルページを参照してください。この空間のほとんどは、コールバック操作中や、 nisping-C によってディレクトリに対しチェックポイントを実行するか、複製サーバーが作成されるときに使用されます。これは、このような手続き中には、NIS+ サーバープロセス全体がフォークされるためです。使用するスワップ空間が、64M バイト未満になることはありません。

テーブルの構成を決める

NIS+ テーブルには、単純なテキストファイルやマップにはない、いくつかの機能があります。これらのテーブルは、列エントリ構造を持ち、検索パスを受け付けます。また、これらのテーブルをリンクして、いくつかの異なる方法で構成することもできます。さらに、独自のカスタム NIS+ テーブルを作成することもできます。各自のドメイン用にテーブル構成を選択するときは、以下の節の内容を検討してください。

NIS+ テーブルと NIS マップとの違い

NIS+ テーブルは、様々な点で NIS マップと異なりますが、次の 2 つの相違点は、名前空間を設計する場合に念頭においておく必要があります。

NIS+ 標準テーブル

17 の標準 NIS+ テーブルを参照して、各サイトの必要に応じたものかどうかを確認してください。これらのテーブルは、「名前空間の構造を設計する」 に示してあります。表 26-6 は、 NIS マップと NIS+ テーブルの対応を示しています。

関連するテーブルの同期化については心配する必要はありません。NIS+ テーブルには、基本的に NIS マップと同じ情報が格納されます。ただし、NIS+ テーブルでは、類似の情報が 1 つのテーブルに統合されます (たとえば、NIS+ の hosts テーブルには、NIS マップの hosts.byaddr と hosts.byname と同じ情報が格納されます)。NIS+ テーブルでは、NIS マップで使用されていた「キー - 値」ペアの代わりに、列と行が使用されます。表 26-6 を参照してください。「キー - 値」テーブルは、2 つの列で構成されます。1 列目がキー、2 列目が値です。したがって、ホスト情報などの情報を変更するときは、その情報を、hosts テーブルなど 1 か所で変更するだけですみます。関連するマップ全体の情報の整合性の維持について注意する必要はなくなりました。

オートマウンタテーブルの新しい名前は次のとおりです。

NIS+ では、ドットを使ってディレクトリを区切るため、ドットは下線に変更されました。テーブル名にドットを使用すると、NIS+ は名前の変換を誤ります。同じ理由で、マシン名にドットを使用することはできません。ドットを含むマシン名は、かならず他の名前に変更してください。たとえば、マシン名に sales.alpha を使用できません。 sales_alpha、salesalpha などのドットを含まない任意の名前に変更してください。

NIS から NIS+ への移行を行うには、NIS 自動マウンタマップのドットを下線に変更する必要があります。また、クライアントのオートマウンタ構成ファイルでも、同じ処理が必要です。次の表を参照してください。

表 26-5 NIS+ テーブル

NIS+ テーブル 

テーブル内の情報 

hosts

ドメイン内にあるすべてのマシンのネットワークアドレスとホスト名 

bootparams

ドメイン内にあるすべてのディスクレスクライアントのルート、スワップ、ダンプの各パーティションの位置 

passwd

ドメイン内のすべてのユーザーに関するパスワード情報 

cred

ドメインに属する主体の資格 

group

ドメイン内のすべての UNIX ® グループのグループパスワード、グループ ID、メンバー

netgroup

ドメイン内のマシンやユーザーが所属できるネットグループ 

mail_aliases

ドメイン内のユーザーの mail 別名に関する情報 

timezone

ドメインの時間帯 

networks

ドメイン内のネットワークとその標準的な名前 

netmasks

ドメイン内のネットワークとそれに関連するネットマスク 

ethers

ドメイン内にあるすべてのマシンの Ethernet アドレス 

services

ドメインで使用される IP サービスの名前とそのポート番号 

protocols

ドメインで使用される IP プロトコルのリスト 

rpc

ドメインで使用できる RPC サービスの RPC プログラム番号 

auto_home

ドメイン内のすべてのユーザーホームディレクトリの位置 

auto_master

オートマウンタマップ情報 

sendmailvars

mail ドメインを格納 

表 26-6 NIS マップと NIS+ テーブルの対応表

NIS マップ 

NIS+ テーブル 

注 

auto.home

auto_home

 

auto.master

auto_master

 

bootparams

bootparams

 

ethers.byaddr

ethers

 

ethers.byname

ethers

 

group.bygid

group

NIS+ グループとは異なる 

group.byname

group

NIS+ グループとは異なる 

hosts.byaddr

hosts

 

hosts.byname

hosts

 

mail.aliases

mail_aliases

 

mail.byaddr

mail_aliases

 

netgroup

netgroup

 

netgroup.byhost

netgroup

 

netgroup.byuser

netgroup

 

netid.byname

cred

 

netmasks.byaddr

netmasks

 

networks.byaddr

networks

 

networks.byname

networks

 

passwd.byname

passwd

 

passwd.byuid

passwd

 

protocols.byname

protocols

 

protocols.bynumber

protocols

 

publickey.byname

cred

 

rpc.bynumber

rpc

 

services.byname

services

 

ypservers

 

必要なし 

NIS+ には、NIS テーブルと対応しない sendmailvars という新しいテーブルが 1 つあります。 この sendmailvars テーブルには、sendmail で使用される mail ドメインが格納されます。

NIS+ テーブルは、NIS とは異なる方法で /etc 内のファイルと相互運用される

NIS および 他のネットワーク情報サービスが SunOS 4.x 環境の /etc 内のファイルとの間で行う相互運用は、+/- 構文を使用して /etc 内のファイルによって管理されていました。NIS+、NIS、DNS、および他のネットワーク情報サービスと、Solaris オペレーティング環境の /etc ファイルとを相互運用する方法は、ネームサービススイッチによって決まります。ネームサービススイッチは、/etc/nsswitch.conf という名前の構成ファイルとして、各 Solaris オペレーティング環境クライアントに配置されます。すべての Solaris オペレーティング環境クライアントにある構成ファイルの nsswitch.conf は、そのクライアントの情報源を指定します。 これは、 /etc 内のファイル、DNS ゾーンファイル (ホストだけ)、NIS マップ、または NIS+ テーブルなどです。NIS+ クライアントの nsswitch.conf 構成ファイルを簡単に示すと、次の例のようになります。

例 26-1 簡略化されたネームサービススイッチファイルの例


passwd: files

group: compat

group_compat: nisplus

hosts: nisplus dns [NOTFOUND=return] files

services: nisplus [NOTFOUND=return] files

networks: nisplus [NOTFOUND=return] files

protocols: nisplus [NOTFOUND=return] files

rpc: nisplus [NOTFOUND=return] files

ethers: nisplus [NOTFOUND=return] files

netmasks: nisplus [NOTFOUND=return] files

bootparams: nisplus [NOTFOUND=return] files

publickey: nisplus

netgroup: nisplus

automount: files nisplus

aliases: files nisplus

つまり、ほとんどのタイプの情報で、情報源はまず NIS+ テーブルであり、次に /etc 内のファイルということになります。passwd および group エントリの場合、ネットワーク情報のソースは、ネットワークファイルか、または /etc 内のファイルおよび /etc ファイルの +/- エントリによって表された NIS+ テーブル のいずれかとなります。

3 種類のスイッチ構成ファイルから選択するか、または独自のスイッチ構成ファイルを作成することができます。詳細は第 1 章「ネームサービススイッチ」を参照してください。

カスタム NIS+ テーブルの使用

どの標準以外の NIS マップを使用するか、またその使用目的を決定してください。NIS+ に変換できるか、あるいは NIS+ 標準マップと置き換えられるかを検討します。

アプリケーションの中には、NIS マップに依存するものがあります。これらのアプリケーションが、NIS+ でも同様に機能するか、また混合環境で正しく機能できるかを検討します。

NIS+ でカスタムテーブルを作成するには、nistbladm を使用します。テーブル名にはドットを使用できないことを忘れないでください。

NIS+ を使用して、独自の NIS マップをサポートできるようにしたい場合は、2 つの列を使用するキー値テーブルを作成する必要があります。最初の列はキー、2 番目の列は値を示します。このテーブルを作成して、NIS+ サーバーを NIS 互換モードで実行すると、NIS クライアントは機能の変更に気がつきません。

テーブル間の接続

NIS+ テーブルには、そのホームドメインの資源とサービスに関する情報だけが含まれています。したがってクライアントは、別のドメインに格納された情報を検索する際には、そのドメインの名前を指定しなければなりません。この「転送」を自動化するには、ローカルテーブルをリモートテーブルに接続してください。NIS+ テーブルは、次の 2 つの方法で接続することができます。

NIS+ 名前空間で NIS クライアントを使用するときは、パスとリンクを使用してはいけません。NIS クライアントは、パスまたはリンクでは、正しい情報を検索することができません。

パス

他のドメインのクライアントが、特定の NIS+ テーブル内の情報を頻繁に要求する場合は、そのローカル NIS+ テーブルから他のドメインのテーブルへのパスを設定することを検討してみてください。次の図を参照してください。

図 26-8 上位ドメイン内のテーブルへのパスを設定する

Graphic

このようなパスがもたらす主な利点は 2 つあります。まず、下位ドメインのクライアントが、別のテーブルを明示的に検索しなくてもすみます。さらに、上位ドメインの管理者があるテーブルで変更を行い、その変更を他のドメインのクライアントに見えるようにすることができます。ただし、このようなパスを設定すると、パフォーマンスが低下します。特に検索がうまくいかないと、パフォーマンスに影響が出ます。これは、NIS+ サービスで、1 つのテーブルではなく 2 つのテーブルを検索しなければならないためです。パスを使用すると、テーブル検索も、他のドメインの利用状況に依存することになります。この依存によって、ドメインの実質の利用度が低下する可能性があります。このような理由から、パスは、他に問題を解決する手段がない場合に限って使用するようにしてください。

mailhost は、別名として使用されることが多いため、特定の mailhost に関する情報を検索する必要がある時は、検索パスに完全指定名 (たとえば、 mailhost.sales.com. など) を使用する必要があることに注意してください。 そうしないと、 NIS+ は、検索したすべてのドメインで見つかった mailhost をすべて返します。

パスをローカルテーブルに設定するには、nistbladm コマンドに -p オプションを付けて使用します。テーブルのパスを変更するには、テーブルオブジェクトへの変更アクセス権がなければなりません。テーブルの検索パスを調べるには、niscat -o コマンドを使用してください (テーブルへの読み取りアクセス権が必要です)。

リンク

テーブル間にリンクを設定すると、パスと同様の効果が生じますが、リンクでは 1 つのテーブル、つまりリモートテーブルの検索だけが行われる点が異なります。検索パスでは、 NIS+ はまずローカルテーブルを検索し、うまくいかなかった場合にのみリモートテーブルを検索します。リンクでは、検索は、リモートテーブルに対して直接行われます。実際には、リモートテーブルがローカルテーブルと置き換わります。リンクを設定すると、下位ドメインが、独自のテーブルを管理しなくても、上位ドメインの情報を使用することができます。

リンクを作成するには、nisln コマンドを使用してください。また、テーブルオブジェクトに対する変更権が必要です。

パスを使用するか、またはドメイン内の NIS+ テーブルをリンクするかを決定するのは、容易ではありません。この決定を行う際の基本的な方針をいくつか、次に示しておきます。

図 26-9 NIS+ 階層での情報の配布

Graphic

ユーザー名とホスト名の重複の解決

NIS+ は、要求が実行された場合に、その主体が人間なのかマシンなのかを区別できません。したがって、すべてのユーザー名は、同一の名前空間におけるマシン名と違うものでなければなりません。すなわち、一定の名前空間においては、ユーザーがマシン名と同じユーザー名を持つことができず、またユーザー ID と同じマシン名を付けることもできません。

たとえば、NIS 環境ではローカルマシンの名前が irina の場合も、ユーザーは irina というログイン名を使用できます。このユーザーのネットワークアドレスは、irina@irina となります。これは、NIS+ 環境では成立しません。サイトを NIS+ に変換する場合、ユーザーがログイン名を変更するか、あるいはユーザーのマシン名を変更する必要があります。同一のユーザー名とマシン名が存在する場合、その名前を持つマシンが同じ名前のユーザーに属していない場合でも問題となります。次に示す例は、NIS+ では無効となる重複した名前の例です。

この問題の一番の解決方法は、/etc 内のファイルすべてと NIS マップ をチェックしてから、 NIS+ テーブルを生成することです。重複している名前を見つけた場合は、ログイン名ではなくマシン名を変更し、後でマシンの元の名前の別名を作成してください。

NIS+ セキュリティの影響について理解する

NIS+ には、NIS にはなかったセキュリティが備わっているため、さらに多くの管理作業が必要になります。chkey、keylogin、または keylogout の手順の実行に慣れていないユーザーにも、より多くの作業が要求されることがあります。さらに、NIS+ によって提供される保護は、完璧に安全というものではありません。十分な計算能力と知識があれば、Diffie-Hellman 公開鍵暗号システムを破ることができます。

192 ビットを超える Diffie-Hellman 鍵を使用すると、NIS+ セキュリティが大幅に向上します。ただし、鍵が長くなるにつれて認証に必要な時間が長くなるため、パフォーマンスが低下する可能性があります。

注 -

nisauthconf を使用して、この種類の Diffie-Hellman 鍵を設定します。長い鍵の使用については、nisauthconf(1M) を参照してください。

また、キーサーバープロセスによって格納された秘密鍵は、資格を持つ、root 以外のユーザーがログアウトしても、そのユーザーが keylogout によってログアウトしないかぎり、自動的に削除されません。セキュリティは、ユーザーが keylogout によってログアウトしたとしても、完全ではありません。これは、セッションキーが、その期限が切れるか、または再初期化されるまで、有効なためです (詳細については keylogout(1) のマニュアルページを参照してください)。ルートキーは、keylogin -r によって作成されて、/etc/.rootkey に格納されますが、これは .rootkey ファイルが明示的に削除されるまで残ります。スーパーユーザーは keylogout を使用することができません。しかしそれでも、NIS+ は、NIS よりもはるかに安全です。

NIS+ セキュリティがユーザーに与える影響

NIS+ セキュリティを使用すると、NIS+ から取得する情報の信頼性が向上し、情報への不正なアクセスを防げるため、ユーザーにとって有益です。ただし、NIS+ セキュリティを使用するには、ユーザーは、セキュリティに関する若干の知識を習得して、2 〜 3 の管理手順を実行しなければなりません。

NIS+ ではネットワークログインが必要ですが、ユーザーがさらにキーログインを実行する必要はありません。これは、クライアントが正しく設定されていれば、login コマンドにより、そのクライアントのネットワーク鍵が自動的に取得されるためです。クライアントは、そのログインパスワードと SecureRPC パスワードが同じであれば、正しく設定されます。ユーザー root の秘密鍵は、通常、/etc/.rootkey ファイルで入手することができます (潜在的なセキュリティの問題として前述しました)。NIS+ ユーザーのパスワードと資格が、passwd コマンドによって変更されると、そのユーザーの資格情報も自動的に変更されます。

ただし、ユーザーがそのネットワークパスワードだけでなく、ローカルの /etc/passwd ファイルのパスワードも管理できて、これらのパスワードがネットワークパスワードと異なる場合、ユーザーは login を実行するたびに keylogin を実行しなければなりません。

NIS+ セキュリティがシステム管理者に与える影響

Solaris オペレーティング環境は、認証のために DES 暗号機構を備えているため、セキュリティ保護操作を必要とするシステム管理者は、別に暗号キットを購入する必要がありません。ただし、システム管理者は、ユーザーに、passwd コマンドと passwd -r コマンドを使用する方法と、これらのコマンドをいつ使用するかを指示する必要があります。

また、セキュリティを強化した NIS+ 名前空間の設定は、通常の名前空間の設定よりも複雑です。この複雑さは、名前空間の設定に必要なステップが多いことだけではなく、すべての NIS+ 主体に対するユーザーの資格とマシンの資格を作成して管理しなければならないということに原因があります。管理者は、passwd テーブルとhosts テーブルから不要なアカウント情報を削除するのと同様に、不要な資格を削除する必要があります。また、管理者は、サーバーの公開鍵が変更された場合、nisupdkeys を使用して、名前空間全体の鍵も変更しなければなりません。さらに管理者は、他のドメインからこのドメインへのリモートログインを望んだり、NIS+ への認証されたアクセスを望むユーザーに対して、LOCAL 資格を追加しなければなりません。

NIS+ セキュリティが移行の計画に与える影響

NIS+ セキュリティの利点と管理上の要件をよく理解したら、NIS+ セキュリティを、移行中または移行後のどちらで実装するかを決める必要があります。NIS 互換モードで、ドメイン内のサーバーの一部またはすべてを操作している場合でも、完全な NIS+ セキュリティを使用するようお勧めします (ドメイン内のすべてのサーバーが同じ NIS 互換モードを使用しているのが、望ましい状態です)。ただし、これには管理の手間が非常にかかります。簡単な方法としては、NIS 互換セキュリティによって NIS+ サーバーと名前空間を設定し、NIS+ クライアントの資格は作成しないことです。ただし、管理者とサーバーには、やはり資格が必要です。NIS+ クライアントは、NIS クライアントとともに、未認証カテゴリに割り当てられます。これにより、学習と設定の作業は軽減されますが、次のような欠点があります。

資格を選択する

NIS+ には、LOCAL と DES という 2 つの種類の資格があります。

注 -

このマニュアルでは、「DES 資格」という用語は、拡張 640 ビット Diffie-Hellman 鍵と、オリジナルの 192 ビット Diffie-Hellman (デフォルト) 鍵の長さについて使用します。cred テーブルでは、拡張鍵は DES キーワードではなく、DH640-0 のような着信先を使用します。長い鍵の使用については、nisauthconf(1M) を参照してください。

どの NIS+ 主体も、これらの資格のうち少なくとも 1 つを必要とします。名前空間がセキュリティレベル 2 (デフォルト) で管理されているときは、すべての NIS+ 主体 (クライアント) は、そのホームドメインに、DES 資格がなければなりません。また、すべてのユーザー (マシンではなく) は、そのホームドメインと、ログインアクセスが必要な他のすべてのドメインに、LOCAL 資格がなければなりません。

名前空間の資格の必要を調べるには、次のことを検討してください。

NIS+ の主体になれるのは、クライアントマシン上のユーザーかスーパーユーザーです。図 26-10 を参照してください。

図 26-10 NIS+ の主体について

Graphic

作成する資格を決定したら、その資格を必要とする主体の種類を確認します。たとえば、NIS+ クライアントを nisclient によって設定する場合、マシンとユーザーの両方に資格を作成することになります。ユーザーの資格を作成しないと、そのユーザーには、未認証クラスに許可されたアクセス権しか与えられません。意図してそのように名前空間を設定している場合は、この設定は十分正しく機能します。しかし、未認証クラスにアクセス権を何も与えていないと、ユーザーはその名前空間を使用することができません。

セキュリティレベルを選択する

NIS+ はセキュリティレベル 2 で実行されるように設計されており、このレベルがデフォルトです。セキュリティレベルの 0 および 1 は、テストとデバッグの目的にのみ用意されています。実際にユーザーが存在しているネットワーク (operational network) は、レベル 2 以外で運用しないでください。詳細については、第 11 章「NIS+ のセキュリティの概要」を参照してください。

パスワード有効期限の基準、原則、および規則を確立する

パスワードの有効期限は、ユーザーに対し定期的にパスワードを変更させる仕組みです。パスワードの有効期限については、次の設定が可能です。

さまざまな最大日数や期間に到達していても、それまでにすでにログインしているユーザーは、上記の機能には影響されないことを覚えておいてください。これらのユーザーは、通常どおりに作業を継続できます。パスワード有効期限に関する制限と動作は、ユーザーがログインした場合、または次の操作のうちの 1 つを実行した場合のみ実行されます。

パスワード有効期限のパラメータは、ユーザー単位を基本として適用されます。また、ユーザーごとに異なるパスワード有効期限を設定できます。さらに、個別に有効期限を設定したユーザー以外のすべてのユーザーに適用される、一般的なデフォルトのパスワード有効期限パラメータを設定できます。

NIS+ の名前空間を計画する場合、実装したいパスワード有効期限の機能と指定したいデフォルト値を決定してください。パスワードの有効期限の詳細については、第 16 章「パスワードの管理」 を参照してください。

NIS+ グループの計画

NIS+ は、NIS にはない新しい種類のグループをネームサービス管理に導入します。NIS+ グループは、NIS+ アクセス権を一度にいくつかの NIS+ 主体に与える手段としてだけ使用します。またこれは、NIS+ の承認にだけ使用します。

NIS+ グループは、アクセス権が基準を置いている、4 つの承認クラスのうちの 1 つです。4 つの承認クラスは次のとおりです。

NIS+ スクリプトにより、アクセス権を与える目的で作成されたデフォルトのグループ名は、admin グループです。また、別の名前を付けて別のグループを作成することも、別のグループに別の NIS+ オブジェクトを割り当てることもできます。

あるオブジェクトグループのメンバーユーザーには、そのオブジェクトに特定の変更を行うアクセス権のような特権があります。たとえば、admin グループに何人かの見習い管理者を追加し、passwd テーブルと hosts テーブルだけを変更できるが、他のテーブルは変更できないようにすることができます。admin グループを使用すると、管理作業を、階層全体のスーパーユーザーだけに行わせるのではなく、多数のユーザーに分散させることができます。NIS+ admin グループには、NIS 互換モードでドメインを管理している場合でも、そのメンバーのために作成された資格がなければなりません。これは、認証を受けたユーザーだけが、NIS+ テーブルを変更するアクセス権を持つためです。

必要な資格の種類を確認したら、名前空間に必要なアクセス権を選択する必要があります。この作業を容易にするには、まずいくつの管理用のグループが必要かを決めます。複数のグループに異なる権利を割り当てたい場合は、独立したグループを使用すると便利です。通常、グループはドメイン別に作成します。各ドメインには、admin グループが 1 つだけなければなりません。

NIS+ グループとディレクトリへのアクセス権の計画

主体をグループに配置したあと、名前空間のオブジェクトによって、他のカテゴリの主体 (未認証、所有者、グループ、その他) だけでなく、これらのグループに許可されるアクセス権の種類を決めます。これらの割り当てを事前に決めておくと、一貫性のあるセキュリティの方針を確立するうえで役立ちます。

表 26-7 に示すように、NIS+ では名前空間の各オブジェクトに対してデフォルトのアクセス権を提供します。

表 26-7 NIS+ オブジェクトへのデフォルトのアクセス権

オブジェクト 

未認証 

所有者 

グループ 

その他 

ルートディレクトリオブジェクト 

r---

rmcd

rmcd

r---

ルート以外のディレクトリオブジェクト 

r---

rmcd

rmcd

r---

groups_dir ディレクトリオブジェクト 

r---

rmcd

rmcd

r---

org_dir ディレクトリオブジェクト 

r---

rmcd

rmcd

r---

NIS+ グループ 

----

rmcd

r---

r---

NIS+ テーブル 

varies

varies

varies

varies

デフォルトのアクセス権を使用するか、または独自のアクセス権を割り当てることができます。独自のアクセス権を割り当てるときは、名前空間内のオブジェクトがどのようにアクセスされるかをよく考える必要があります。未認証クラスは、NIS+ クライアントからのすべての要求から構成されており、その要求は認証されていてもいなくても構わない、ということに注意してください。その他のクラスは、NIS+ クライアントからの認証を受けているすべての要求から構成されます。したがって、認証されていない要求に対し、名前空間へのアクセス権を与えたくなければ、未認証クラスへのアクセス権を割り当てず、その他のクラスだけを割り当てます。一方で、いくつかのクライアントが、たとえばアプリケーションを通して、認証されていない読み取り要求を出すことが予測されるときは、未認証クラスに読み取り権を割り当てる必要があります。NIS クライアントを NIS 互換モードでサポートしたい場合は、未認証クラスに読み取り権を割り当てなければなりません。

また、各種の名前空間オブジェクトが、最初に指定した NIS+ グループに割り当てる権利についても検討してください。名前空間の管理方法によって、利用できるアクセス権の一部またはすべてを、このグループに割り当てることができます。マスターサーバー上のユーザー root を、admin グループの所有者にすることをお勧めします。admin グループには、ルートドメインのオブジェクトに対する作成権と削除権が必要です。1 人の管理者にだけ、ルートドメインを作成、変更させたい場合は、その管理者だけを admin グループに所属するようにしてください。グループには、いつでもメンバーを追加することができます。設定を行う管理者が何人かいる場合は、その管理者をすべてグループに追加して、そのグループにすべての権利を割り当ててください。その方が、所有者を切り替えたり元に戻したりするよりも簡単です。

オブジェクトの所有者にはすべての権利が与えられていなければなりません。ただし、グループにすべての権利が与えられていれば、このことはさほど重要ではありません。すべての権利を所有者にだけ与えると、名前空間のセキュリティ保護はより安全なものになります。しかし、管理グループにすべての権利を与えた方が管理は容易です。

NIS+ テーブルのアクセス権の計画

NIS+ テーブル以外の NIS+ オブジェクトは、主に構造的なものです。一方、NIS+ テーブルは、オブジェクトの種類が異なり、情報を伝えるものです。 NIS+ テーブルへのアクセスは、すべての NIS+ 主体と、これらの主体に代わって実行されるアプリケーションで必要とされます。このため、NIS+ へのアクセス要件は若干異なります。

表 26-8 は、NIS+ テーブルに割り当てられるデフォルトのアクセス権を示しています。列が、テーブルの権利以外の権利を持つ場合は、それらの権利も示しています。テーブルとエントリのレベルの権利は、nischmod コマンドによって変更することができます。また、列レベルの権利は、nistbladm -u コマンドによって変更することができます。「暗号化されているパスワードフィールドの保護」 には、テーブル権利を変更して異なる要求に応える方法の一例を示してあります。

表 26-8 NIS+ テーブルと列のデフォルトのアクセス権

テーブル / 列 

未認証 

所有者 

グループ 

その他 

hosts テーブル 

r---

rmcd

rmcd

r---

bootparams テーブル 

r---

rmcd

rmcd

r---

passwd テーブル 

----

rmcd

rmcd

r---

 

名前 (name) 列 

r---

----

----

----

 

パスワード (passwd) 列 

----

-m--

----

----

 

ユーザー ID (uid) 列 

r---

----

----

----

 

グループ ID (gid) 列 

r---

----

----

----

 

GCOS (gcos) 列 

r---

-m--

----

----

 

ホームディレクトリ (home) 列 

r---

----

----

----

 

ログインシェル (shell) 列 

r---

----

----

----

 

シャドー (shadow) 列 

----

----

----

----

group テーブル 

----

rmcd

rmcd

r---

 

名前 (name) 列 

r---

----

----

----

 

パスワード (passwd) 列 

----

-m--

----

----

 

グループ ID (gid) 列 

r---

----

----

----

 

メンバー (members) 列 

r---

-m--

----

----

cred テーブル 

r---

rmcd

rmcd

r---

 

cname 列 

----

----

----

----

 

auth_type 列 

----

----

----

----

 

auth_name 列 

----

----

----

----

 

public_data 列 

----

-m--

----

----

 

private_data 列 

----

-m--

----

----

networks テーブル 

r---

rmcd

rmcd

r---

netmasks テーブル 

r---

rmcd

rmcd

r---

ethers テーブル 

r---

rmcd

rmcd

r---

services テーブル 

r---

rmcd

rmcd

r---

protocols テーブル 

r---

rmcd

rmcd

r---

rpc テーブル 

r---

rmcd

rmcd

r---

auto_home テーブル 

r---

rmcd

rmcd

r---

auto_master テーブル 

 

rmcd

rmcd

r---

注 -

NIS 互換ドメインは、テーブルオブジェクトレベルの passwd テーブルに、未認証クラスの読み取り権を与えます。

暗号化されているパスワードフィールドの保護

表 26-8 を見るとわかるように、passwd テーブルを除くすべてのテーブルで、未認証クラスに読み取り権が与えられています。NIS+ テーブルは、未認証クラスの読み取りアクセス権を与えます。これは、NIS+ テーブルにアクセスする必要がある多くのアプリケーションが、認証されていないクライアントとして実行されるためです。ただし、passwd テーブルに対して同じことを行うと、暗号化されているパスワードの列が、認証されていないクライアントに公開されてしまいます。

表 26-8 に示す構成は、NIS 互換ドメインに対するデフォルトのアクセス権です。NIS 互換ドメインは、passwd 列に、未認証クラスの読み取りアクセス権を与えなければなりません。これは、NIS クライアントが認証されておらず、未認証クラスの読み取りアクセス権を与えないと、その passwd 列にアクセスできないためです。したがって、NIS 互換ドメインでは、パスワードが暗号化されていても、復号化されやすい状態にあります。パスワードを、所有者以外には読めないようにしておくと、より安全になります。

標準の NIS+ ドメイン (NIS 互換ではない) には、さらに別のレベルのセキュリティがあります。 nissetup によって提供されるデフォルトの構成では、列ごとに制御する方法で、passwd 列を未認証ユーザーから保護しますが、passwd テーブルの残りの部分に対するアクセス権は与えられます。テーブルレベルでは、未認証の主体に読み取りアクセス権はありません。列レベルでは、passwd 列を除くすべての列への読み取りアクセス権があります。

エントリ所有者が、パスワード列に対するアクセス権を取得する方法について説明します。エントリ所有者は、各自のエントリに対する読み取り権と変更権の両方を持ちます。エントリ所有者は、その他のクラスのメンバーになることによって、読み取り権を取得します (テーブルレベルでは、その他のクラスに読み取り権があることに注意してください)。また、エントリ所有者は、列レベルでの明示的な割り当てによって、変更権を取得します。

テーブルの所有者とエントリの所有者は、同じ NIS+ 主体であることはほとんどなく、また同じである必要もないことに注意してください。したがって、所有者にテーブルレベルの読み取り権があっても、特定のエントリの所有者に読み取り権があるということではありません。

前に述べたように、これは、Solaris 2.3 以降のリリース (Solaris 9のデフォルト設定です。テーブル、エントリ、および列レベルのセキュリティの詳細については、第 16 章「パスワードの管理」を参照してください。

NIS 互換モードの使用方法の概要

NIS と平行して NIS+ を実行するかどうか、実行する場合にはその方法、および停止する時を決定するのは、おそらくユーザーが直面する最も難しい移行問題の 1 つでしょう。 NIS+ には、 NIS といっしょに使用できる機能がいくつかありますが、中でも NIS 互換モードという機能があります。

NIS 互換モードを使用する計画がある場合、 NIS 互換モードで利用できる基本的な利点を考えておく必要があります。 NIS クライアントにはまったく変更を行う必要はありません。基本的な欠点は、完全な NIS+ セキュリティと階層を利用できないことと、クライアントのドメイン名を変更する必要があることです。

図 26-11 は、NIS だけの名前空間から、NIS と NIS+ の両方の要求に応じる名前空間に変換する方法を示しています。

図 26-11 NIS　互換モードへの移行

Graphic

NIS 互換になるドメインを選ぶ

NIS クライアントのリストを作成して、それらを最終的な NIS+ ドメインにグループ化してください。NIS 互換モードで管理される NIS+ ドメインの名前が、その NIS クライアントの元の NIS ドメインと異なる場合は、NIS クライアントのドメイン名を、NIS 互換の NIS+ サーバーによってサポートされる NIS+ ドメインの名前に変更しなければなりません。

まず、NIS は間違いなく一次サービスです。情報共有の複雑さに慣れれば、NIS+ を一次サービスに移行する計画を立てることもできます。NIS+ ユーザーは、主な NIS ドメインと新しい NIS+ ドメインを切り替える機能を必要とする場合があります。nisclient スクリプトを使用すると、バックアップファイルが作成されるとき、この切り替えを行うことができます。

NIS 互換サーバーの構成を決める

NIS+ サーバーの要件を考慮した上で、各自の NIS サーバーについて判断を行います。最終的に、それらのサーバーを NIS+ サービスに使用する場合は、それらを NIS+ で推奨されるものに変更します。どの NIS サーバーを使用してどの NIS+ ドメインを、またどの機能 (マスターか複製か) でサポートするかを明らかにします。NIS+ サーバーは、それらがサポートするドメインよりも上位のドメインに属することを忘れないでください (ルートドメインサーバーは例外です)。NIS+ サーバーは、そのサービス対象となるドメインに属さないため、ドメインに依存する情報を必要とする他のサービスに、そのマシンを使用することはできません。

可能であれば、NIS+ サーバーマシンは、NIS+ にだけ使用するようにしてください。この構成では、DNS ネームサービス、ブートサーバー、ホームディレクトリ、NFS サーバーなどの他のネットワークサービスを、NIS+ ではないサーバーマシンに転送しなけれならない可能性があります。

サイトの多くで、NIS サーバーは、NFS サーバー、計算サーバー、rlogin サーバー、メールホストサーバーなど、複数の役割を果たします。NIS サーバーは、そのクライアントと同じ情報を使用してその名前を解決するため、他のサービスも提供することができます。「ドメインの階層」で説明したように、ルートドメインを除くすべての NIS+ サーバーが、それがサービスを提供するドメインよりも上位のドメインに存在します。したがって、NIS+ サーバー上ではネームサービスを利用しなければならないサービスを実行しないようにするか、あるいは nsswitch.conf のファイルのような他の手段を使用して、これと同じ情報を取得してください。この問題は、階層がない場合には起こりません。この場合、NIS+ ルートサーバーは、そのサービス対象のドメイン内に存在します。NIS+ サーバーの資源の要件は、NIS サーバーの要件よりも大きいため、NIS+ とともに他のサービスを実行しないようにしてください。

Solaris 以外のマシンがネットワーク上にある場合は、NIS 互換モードで NIS+ サーバーを引続き使用することも、このようなマシンをすべて独自のドメインに移動させることもできます。Solaris 以外のマシンをすべて、1 つのサブネットに移動すると、NIS 互換クライアントの場合と同様に、同じサブネットに NIS+ サーバーがなければならないという制約をなくすことができます。これにより、ドメインに必要な複製サーバーの数が減ります。

サービス間で情報を転送する方法を決める

情報を同期させるには、一方の名前空間がもう一方の名前空間に従属する関係になるようにしてください。まず、NIS 名前空間を「主」とします。この場合、NIS マップを変更すると、次にその変更内容を「従」である NIS+ テーブルに反映します。したがって、NIS 名前空間がマスタデータベースになります。

NIS 互換モードの NIS+ サーバーは、標準の NIS マップをサポートします。これらのマップの完全なリストは、ypfiles(4) のマニュアルページの注意事項の節にあります。ただし、マップのサポートにはいくつかの制約があります。NIS+ サーバーは、ネットグループマップに対する ypmatch 要求には応じますが、逆マップに対する要求には応じません。また、ypcat などのネットグループマップの表示要求をサポートしません。passwd.adjunct マップもサポートしません。

最終的には NIS+ 名前空間が「主」になります。この場合は、NIS+ テーブルで変更を行って、それを NIS マップにコピーします。

NIS+ コマンドの nisaddent と NIS+ スクリプトの nispopulate を使用すると、表 26-9 に示すように、NIS マップと NIS+ テーブルの間で、情報を転送することができます。

表 26-9 passwd テーブルでの情報変更のためのコマンド

NIS+ コマンド 

説明 

/usr/lib/nis/nisaddent -y

ypxfr を実行して、NIS サーバーからローカルディスクへマップを転送した後で、NIS マップから NIS+ テーブルへ情報を転送する。標準以外の NIS マップは、情報がキーと値のペアになっていれば、NIS+ テーブルに転送できる。複数列のマップは転送されない

/usr/lib/nis/nisaddent -d

NIS+ テーブルからファイルへ情報をコピーする。この情報は、標準 NIS ユーティリティを使って、さらに NIS マップに転送することができる 

/usr/lib/nis/nispopulate -Y

NIS マップから NIS+ テーブルへ情報を転送する 

Solaris 2.5 より前のリリースの NIS+ のバージョンでは、ユーザーのパスワード情報が /etc 内のファイル、NIS マップ、NIS+ テーブルのどこに格納されているかによって、別々のパスワードコマンド (passwd、yppasswd、nispasswd) を使用して、パスワード関連の処理を行う必要がありました。Solaris 2.5 からは、パスワード関連の処理をすべて passwd または passwd -r nisplus のコマンドで自動的に行うとともに、ユーザーの nsswitch.conf ファイルの passwd エントリによって管理することになりました。

NIS+ または NIS 互換のネットワーク上に、passwd コマンドとパスワードの有効期限を正しく設定するには、各マシン上の nsswitch.conf ファイルの passwd エントリが正しくなければなりません。このエントリによって、passwd コマンドがパスワード情報を取得する場所と更新する場所が決まります。

次の 5 つのパスワードエントリ構成のみが使用できます。

例 26-2 nsswitch.conf ファイルにおける使用可能な passwd エントリ


passwd:files
 
passwd: files nis
 
passwd: files nisplus
 
passwd: compat
 
passwd_compat: nisplus
注意 - 注意 -

使用しているネットワークのすべてのマシン上に存在する nsswitch.conf ファイルは、必ず上記の passwd 構成のうちの 1 つを使用していなければなりません。別の方法で、passwd エントリを構成した場合、ユーザーがログインできない可能性があります。

NIS 互換モードで作成されたドメインのアクセス権は、NIS+ の場合と少し異なります。テーブルレベルのアクセス権は、その他クラスに読み取りアクセス権を割り当てる必要があります。列レベルのアクセス権は、未認証クラスに読み取りアクセス権を割り当てる必要があります。

DNS 転送を実装する方法を決める

NIS サーバーは、Solaris 1.x の NIS クライアントからの DNS 要求を転送することができます。 NIS 互換モードで実行される NIS+ サーバーにも、DNS 転送機能がありますが、Solaris 2.3 のリリースからしか使用できません (この機能は、パッチ #101022-06 を使用すれば、Solaris 2.2 でも使用できます)。このため、Solaris 2 または Solaris 9 オペレーティング環境で動作している NIS クライアントは、/etc/nsswitch.conf と /etc/resolv.conf ファイルをローカルに設定しておく必要があります。

NIS 互換モードで実行される Solaris 2.0 または 2.1 のサーバーによってサポートされている Solaris 1.X NIS クライアントは、DNS 転送を利用することができません。これらのサーバーは、Solaris 2.3 にアップグレードする必要があります。

DNS ドメインの区分を再度作成するときは、新しい DNS ゾーンファイルを定義しなければなりません。ただし、クライアントによっては、/etc/resolv.conf ファイルの変更が必要な場合があります。クライアントが DNS クライアントでもある場合は、そのネームサービススイッチ構成ファイルを設定して、NIS+ テーブルだけでなく、DNS ゾーンファイルまたは NIS マップのホスト情報を検索することができます。

NIS+ クライアントの DNS 転送

NIS+ クライアントは、NIS クライアントのような暗黙の DNS 転送機能を持ちません。そのかわり、ネームサービススイッチを使用することができます。NIS+ クライアントに DNS 機能を与えるには、その hosts エントリを次のように変更してください。


hosts: nisplus dns [NOTFOUND=return] files

Solaris 2 または Solaris 9 オペレーティング環境の NIS クライアントの DNS 転送

NIS クライアントが、 NIS 互換の NIS+ サーバーの DNS 転送機能を使用している場合、そのクライアントの nsswitch.conf ファイルは、hosts エントリに次の構文があってはいけません。


hosts: nis dns files

DNS 転送では、ホスト要求が DNS に自動的に転送されるため、この構文があると、NIS+ サーバーとネームサービススイッチの両方が、不必要な要求を DNS サーバーに転送してしまいます。この結果、パフォーマンスが低下します。

Solaris 1、Solaris 2、Solaris 9 における NIS コマンドと NIS+ コマンドの対応

この節で示す表によって、Solaris 1 オペレーティング環境の NIS コマンド、Solaris 2 または Solaris 9 オペレーティング環境の NISコマンド、およびそれに対応する NIS+ コマンドがわかります。

Solaris 2 および Solaris 9 でサポートされている NIS コマンド

Solaris 2 および Solaris 9 では、一部の NIS コマンドだけがサポートされています。NIS サーバーコマンドは、Solaris 2 および Solaris 9 では提供されません。NIS クライアントコマンドだけがこのリリースに含まれています。これらの NIS コマンドが実行されるかどうかも、Solaris 2 または Solaris 9 の NIS クライアントが、NIS サーバーまたは NIS 互換モードの NIS+ サーバーにサービスを要求するかどうかによって決まります。NIS クライアントは、NIS 互換モードで実行されている NIS+ サーバーに更新を依頼することができません。たとえば、このようなクライアントは、chkey、newkey の各コマンドを実行することができません。表 26-10 は、Solaris 2 および Solaris 9 でサポートされている NIS コマンドの一覧です。

表 26-10 Solaris 2 および Solaris 9 オペレーティング環境でサポートされる NIS コマンド

コマンドの種類 

Solaris 2 および 9 でサポートされる NIS コマンド 

Solaris 2 および 9 でサポートされない NIS コマンド 

ユーティリティ 

ypinit ypxfr ypcat ypmatch yppasswd ypset ypwhich

yppush yppoll ypchsh ypchfn ypmake

デーモン 

ypbind

ypserv ypxfrd rpc.ypupdated rpc.yppasswdd

NIS API 

yp_get_default_domain() yp_bind() yp_unbind() yp_match() yp_first yp_next() yp_all() yp_master() yperr_string() ypprot_err()

yp_order() yp_update()

クライアントコマンドとサーバーコマンドの対応

この節で示す 2 つの表には、NIS コマンドと、それに相当する NIS+ コマンドを示してあります。これらのコマンドは、2 つのカテゴリに分けられます。表 26-11 では、ネームサービスクライアントからネームサービスサーバーへのコマンドを示しています。 表 26-12 では、ネームサービスサーバーからネームサービスサーバーへのコマンドを示しています。

対応するクライアントコマンド

表 26-11 では、ネームクライアントからネームサーバーへのコマンドを示しています。これらのコマンドを、ネームサービスのクライアントマシン上で入力してネームサービスサーバーの情報を要求します。表の 1 列目のコマンドは、Solaris 1 の NIS サーバーに接続されている、 Solaris 1、Solaris 2、または Solaris 9 の NIS クライアントで実行されます。表の 2 列目のコマンドは、 NIS 互換モードで実行されている Solaris 2 または Solaris 9 の NIS+ サーバーに接続されている、 Solaris 1、Solaris 2、または Solaris 9 の NIS クライアント上で実行されます。 表の 3 列目のコマンドは、 Solaris 2 または Solaris 9 の NIS+ サーバーに接続されている、Solaris 2 または Solaris 9 の NIS+ クライアント上でのみ実行されます。1 つの行に示されたコマンドは、ほぼ同じ機能を持ちます。「なし」は、対応するコマンドがないことを示しています。

表 26-11 NIS クライアントコマンドと対応する NIS+ コマンド

SunOS 4.x NIS サーバー 

NIS 互換モードの NIS+ サーバー 

NIS+ サーバー 

ypwhich -m

ypwhich -m

niscat -o org_dir

ypcat

ypcat

niscat

ypwhich

ypwhich

なし 

ypmatch

ypmatch

nismatch/nisgrep

yppasswd

passwd

passwd

ypbind

ypbind

なし 

yppoll

なし 

なし 

ypset

ypset

なし 

なし 

ypinit -c

nisclient -c

以下の点に注意してください。

対応するサーバーコマンド

表 26-12 では、ネームサーバーからネームサーバーへのコマンドを示しています。NIS サーバーコマンドは、Solaris 2 または Solaris 9 に含まれていないため、NIS+ サーバーにも NIS 互換モードの NIS+ サーバーにも使用できません。また、NIS サーバーは、NIS+ サーバーに変更を依頼することができません。この逆もできません。このテーブルの 3 番目の列には、最初の列の NIS サーバーコマンドに対応する NIS+ サーバーコマンドが示されています。NIS 互換モードはクライアントコマンドだけを参照するため、NIS 互換モードのサーバーには同じ機能を提供するコマンドはありません。

表 26-12 NIS サーバーコマンドと対応する NIS+ コマンド

SunOS 4.x NIS サーバー 

NIS 互換モードの NIS+ サーバー 

NIS+ サーバー 

ypxfr

なし 

なし 

makedbm

なし 

nisaddent

ypinit -m ypinit -s

なし 

nisserver

ypserv

rpc.nisd -Y

rpc.nisd

ypserv -d

rpc.nisd -Y -B

DNS 転送は不要、/etc/nsswitch.conf を使用すること

ypxfrd

なし 

なし 

rpc.ypupdated

なし 

なし 

rpc.yppasswd

rpc.nispasswdd

rpc.nispasswdd

yppush

なし 

nisping

ypmake

なし 

nissetup、nisaddent

ypxfr

なし 

なし 

NIS と NIS+ の API 関数の対応

サイトを完全に NIS+ に移行するには、ネームサービスを変更するだけでなく、すべてのアプリケーションを NIS+ に移植する必要があります。NIS の呼び出しを行う、サイトの内部で作成されたアプリケーションはすべて、NIS+ の呼び出しを実行するように変更しなければなりません。そうしないと、常に NIS 互換モードで NIS+ サーバーを実行しなければならず、このモードの欠点をすべて抱えることになります。サイトの外部で作成されたアプリケーションでは、必要な変更が行われるまで、NIS 互換モードで名前空間を管理しなければならないことがあります。

表 26-13 では、NIS API 機能と、それに対応する NIS+ API 機能を示しています。

表 26-13 NIS の API の関数と NIS+ の API の関数の対応

NIS API の関数 

NIS API の関数 

yp_get_default_domain()

nis_local_directory()

ypbind()

なし 

ypunbind()

なし 

ypmatch()

nis_list()

yp_first()

nis_first_entry()

yp_next()

nis_next_entry()

yp_all()

nis_list()

yp_master()

nis_lookup()

yperr_string()

nis_perror() nis_sperrno()

ypprot_err()

nis_perror() nis_sperrno()

yp_order()

なし 

yp_update()

nis_add_entry()、nis_remove_entry()、nis_modify_entry()

NIS 互換モードのプロトコルサポート

表 26-14 は、NIS 互換モードで動作する NIS+ サーバー によってサポートされる NIS プロトコルについて示しています。

表 26-14 NIS+ サーバーによる NIS プロトコルのサポート

NIS プロトコル 

互換性についての説明 

NIS クライアント V2 プロトコル 

サポートしている 

NIS サーバー間プロトコル(NIS server-to-server プロトコル) 

サポートしていない 

NIS クライアント更新プロトコル 

yppasswdプロトコルをサポートしている

NIS クライアント V1 プロトコル 

YPPROC_NULL、YPPROC_DOMAIN、YPPROC_DOMAIN_NONACK を除き、サポートしていない

NIS+ への移行の準備 - 他システムに対する NIS+ の影響を調べる

システム管理者を教育するだけでなく、サイトで NIS+ を紹介し、テストを行い、NIS+ に習熟できるような教育を行なってください。また、NIS+ への移行によって影響を受ける他のシステムやアプリケーションの NIS への依存関係を調べてください。

たとえば、アプリケーションの中には、NIS マップの一部に依存するものがあります。これらのアプリケーションが標準 NIS+ テーブルまたはカスタム NIS+ テーブルのどちらで機能するか、また、それらのアクセスの必要性によりセキュリティ計画全体にどのような影響が及ぶかを調べてください。

さらに、サイトで使用される標準以外の NIS マップはどれか、また、それらのマップを NIS+ テーブルに変換するかあるいは標準以外の NIS+ テーブルを作成して、情報を格納できるかを調べてください。アクセス権をチェックする必要もあります

各サイトで、NIS に依存する、ローカルで作成したアプリケーションを使用するかどうかも調べます。また、 yp_match() 関数の呼び出しが埋め込まれているかどうかなど、直接 NIS を呼び出すコマンドやアプリケーションがあるかどうかも調べる必要があります (詳細については、「NIS と NIS+ の API 関数の対応」を参照してください)。

名前空間でユーザー名とホスト名が重複していないかチェックしてください (詳細については、「ユーザー名とホスト名の重複の解決」を参照してください)。

NIS+ への移行がネットワークのインストール手順に与える影響も調べます。もし影響があれば、必要な変更を分析してください。 NIS+ のサイト管理作業に対する影響を調べると、発生する可能性がある障害を事前に明らかにすることができます。

システム管理者の教育

「NIS+ について理解する」 で説明した紹介と教育プログラムのもう 1 つの目的として、各サイトの管理者に NIS+ の概念を理解してもらい、作業手順に慣れる機会を与えるということがあります。教室での学習だけでは不十分です。システム管理者には、業務に支障をきたさない環境で作業する機会が必要です。この教育には、次の内容が含まれます。

ユーザーへの事前の連絡

NIS+ へのクライアントの移行を実際に開始するかなり前から、ユーザーに事前に移行についての連絡を行なってください。実装の計画を伝え、詳細を入手する方法を提供してください。「推奨する移行手順」 で説明したように、移行の主な目的の 1 つは、クライアントに対する移行の影響を最小限に抑えるということですが、ユーザーが新しい変更に関心を持つ場合があります。このような場合には、電子メールで通知を送って、情報セミナーの開催を知らせ、ユーザーが質問を送信できる電子メールの別名または個人名を指定してください。

必要な変換ツールとプロセスを明らかにする

移行のツールを作成または入手して、実装に利用してください。各サイトですでに自動化ツールを使用して、個々のシステムやネットワークサービスを管理している場合は、それらを移植して、移行に使用するバージョンの Solaris ソフトウェアや NIS+ で動作するようにしてください (「1 種類のソフトウェアリリースを使用する」を参照)。次に、スクリプトを作成する際の推奨事項を示します。

このようなスクリプトを作成すると、ドメイン全体で一貫した移行を行い、移行の効率をあげて、問題を減らすことができます。また、名前空間全体のすべてのクライアントで使用できるような nsswitch.conf といった一連の標準構成ファイルとオプションを用意する必要もあります。

移行に使用される管理用のグループを明らかにする

移行の際に調べた管理資源に対応する名前空間の設計 (「パスワード有効期限の基準、原則、および規則を確立する」 を参照) の一部として、NIS+ グループが作成されたことを確認してください。NIS+ 名前空間の日常的な操作に使用されるもの以外の NIS+ グループを、移行に使用することもできます。リモートの管理者の援助が至急必要な場合には、グループにこれらの管理者を追加してください。

グループのメンバーに正しい資格があり、名前空間オブジェクトがグループに正しいアクセス権を承認していることを確認してください。また、その適切なグループが、適切な名前空間オブジェクトのグループ所有者として識別されることを確認してください。

次の表は、NIS+ グループとグループアクセス権を操作するコマンドの一覧です。

表 26-15 グループ用の NIS+ コマンド

コマンド 

説明 

nisgrpadm

グループを作成または削除し、メンバーを追加、変更、一覧表示、削除する 

niscat -o

NIS+ グループのオブジェクト属性値を表示する 

nissetup

ドメインのグループが格納されているディレクトリの基本構造を作成する 

nisls

ディレクトリの内容を一覧表示する 

NIS_GROUP

シェルで設定されている nisdefaults の値を上書きする環境変数

nischmod

オブジェクトのアクセス権を変更する 

nischown

NIS+ オブジェクトの所有者を変更する 

nischgrp

NIS+ オブジェクトのグループ所有者を変更する 

nistbladm -u

NIS+ テーブルの列へのアクセス権を変更する 

nisdefaults

現在の NIS+ のデフォルトを表示、または変更する 

ドメインの所有者を決める

ドメイン階層の機能を十分利用するには、ドメインの所有権を、それらのドメインをサポートしている組織に分散させてください。これにより、ルートドメインの管理者が、ローカルレベルの基本的な作業を行わなくてもすむようになります。 誰が何を所有しているのかがわかれば、管理用のグループを作成するための指針を用意して、オブジェクトへのアクセス権を設定することができます。

NIS+ ドメインの所有権と DNS ドメインの所有権をどのように調整するかを検討してください。次のいくつかの指針を示します。

資源の利用度を調べる

実装にどの管理資源が必要かを調べます。これらの資源は、通常の NIS+ の操作に必要な資源をはるかに超えます。移行を行うときに、NIS+ と NIS の互換性が必要な期間が長期に及ぶ場合は、さらに資源が必要になります。

名前空間の設計を実装する作業だけでなく、多くのクライアントを移行して、特殊な要求や問題を処理する作業についても検討してください。このとき、NIS+ の習得にかなり時間がかかることを考慮に入れておいてください。NIS+ でサポート作業を行う場合、NIS で作業していたときとくらべて、しばらくの間、管理者の作業効率がやや低下する場合があります。このため、通常の教育だけでなく、実習経験をともなう上級コースの研修を受けることも検討してください。

さらに、移行が完了した後でも、管理者は、NIS+ をサポートするための毎日の作業に慣れるまでに若干の時間を要します。

ハードウェア資源についても検討してください。NIS サーバーは、経路指定、印刷、ファイル管理などの他のネットワークサービスをサポートするために使用されることがよくあります。NIS+ サーバーにかかる可能性のある負荷を考えて、専用の NIS+ サーバーを使用する必要があります。このように負荷を分散すると、障害追跡と性能監視が簡単になるため、移行が簡略化されます。もちろん、システムを追加するとコストがかかります。必要なサーバーの数と、その構成方法については、「NIS+ 名前空間の設計 - 管理モデルの目的を明らかにする」に説明があります。

これらのサーバーは、NIS サーバーの他に必要であることを忘れないでください。NIS サーバーは、移行が完了すると、必要なくなるか、あるいは他の用途で使用される場合がありますが、 NIS+ サーバーは引き続き使用されます。

ログイン名とホスト名の衝突を解決する

NIS+ 認証では、マシンとユーザーが、1 つのドメイン内で同じ名前を使用することはできません。たとえば、joe@joe は使用できません。NIS+ は、ホストの資格とログイン名の資格を区別しないため、1 つの名前に 1 種類の資格を使用するだけですみます。名前空間に重複した名前があり、何らかの理由でその重複したホスト名を維持しなければならないときは、次のように変更してください。つまり、ユーザーログイン名をそのままにして、重複したホスト名を別名に指定します。ホストに新しい名前を作成して、古い名前を新しい名前の別名として使用します。不正な名前の組み合わせの例については、「ユーザー名とホスト名の重複の解決」を参照してください。

名前の衝突を解決してから実装を開始する必要がありますが、通常の NIS+ の操作中に新しいマシンとユーザーの名前を常時チェックする計画をたてる必要もあります。これには、nisclient スクリプトを使用してクライアントの資格を作成すると、名前の比較が行われます。

すべての情報源となるファイルを調べる

/etc 内のファイルと NIS マップをすべて調べて、空のフィールドやこわれているデータがないかを確認してから、NIS+ を構成してください。NIS+ テーブルの生成スクリプトとコマンドは、データファイルに空のフィールドや余分な文字があると、正常に実行されない場合があります。空フィールドを埋めるか、またはデータを修正してから、作業を開始してください。NIS+ スクリプトをそのまま実行してデータを破壊する危険をおかすよりも、問題のあるユーザーやマシン名を /etc 内のファイルや NIS マップから削除してから、 NIS+ スクリプトを実行して、NIS+ のインストール後にそれらを戻すことをお勧めします。

ホスト名から「.」を削除する

NIS+ では、マシン名とドメインの区切りや親ドメインとサブドメインとの区切りにドット (ピリオド) を使用するため、ドットを含むマシン名 (ホスト名) を付けることはできません。NIS+ へ移行するにあたって、ホスト名からドットを必ず削除する必要があります。ドットの代わりにハイフン (-) を使用できます。たとえば、sales.alpha というマシン名を付けることはできません。この名前は、sales-alpha に置き換えることができます (使用可能なホスト名の詳細については、 hosts のマニュアルページを参照してください)。

NIS マップ名から「.」を削除する

「NIS+ 名前空間の設計 - 管理モデルの目的を明らかにする」で説明したように、NIS+ のオートマウンタテーブルでは、その名前とファイル内容の「.」(ドット) が下線で置き換えられています。この変更は、移行中に使用する NIS マップの名前に対しても行う必要があります。この変更を行わないと、NIS+ は、名前の「.」を、オブジェクト名のドメインレベルを区別するピリオドと混同します。

注 -

オートマウンタだけでなく、すべての NIS マップの「.」を必ず下線に変換してください。ただし、標準以外の NIS マップの名前をドットから下線に変更した場合、標準以外のマップを使用するアプリケーションを、NIS+ 構文を認識するように変更しないと、そのアプリケーションに障害が生じるおそれがあります。

既存の NIS 名前空間を文書化する

現在の構成を文書化しておくと、移行を開始する開始点を明確にすることができます。次の項目のリストを作成してください。

NIS クライアントのリストと、最終的な NIS+ ドメインを対応させてください。これらは、Solaris オペレーティング環境にアップグレードする必要があります。

NIS サーバーの移行計画を作成する

NIS サーバーについてよく考慮します。移行が完了した後でも NIS サーバーを他の用途に使用することができますが、「両方」のサービスにサーバーを必要とする段階があることを忘れないでください。したがって、既存の NIS サーバーを使って、すべての NIS+ サーバーの必要を満たす計画を立てることはできません。

NIS サーバーの詳しい移行計画を作成して、NIS+ に使用される NIS サーバーと、その移行時期を明らかにしておくと役立ちます。NIS から NIS+ への移行の初期段階では、NIS サーバーを NIS+ サーバーとして使用しないでください。「NIS+ の実装の概要」で説明するように、名前空間全体に対する操作を調べてからクライアントを NIS+ に移行すると、より安定した実装を行うことができます。

NIS サーバーを NIS+ ドメインに割り当てて、各サーバーの役割 (マスタまたは複製) を明らかにしてください。NIS+ サービスへの移行を計画しているサーバーを指定したら、それらを NIS+ の要件に合わせてアップグレードしてください (「サーバーメモリーの容量」を参照)。

NIS+ の実装の概要

以上の節で説明した作業を実行すれば、手のかかる仕事はほとんど終わったことになります。ここでしなければならないことは、設計した名前空間の設定と、クライアントの追加だけです。この章では、これらの処理を行う方法について説明します。これらの手順を実行するにあたっては、移行前の準備作業すべてが完了していて、各サイトのユーザーが移行の計画を了解していることを確認してください。

NIS+ ドメインを DNS ドメインと並行して使用する場合は、各 DNS ドメインに 1 つの NIS+ サブドメインを設定します。最初の DNS ドメインに完全な NIS+ 名前空間を設定して、すべてが正しく動作していることを確認したら、別の NIS+ 名前空間を並行して設定することができます。

第 1 段階 - NIS+ 名前空間を設定する

ドメインを NIS 互換モードで管理している場合でも、完全な DES 認証を備えた名前空間を設定します。NIS+ スクリプトを使用します。NIS+ の構造と概念の詳細については、第 4 章「スクリプトを使用した NIS+ の設定」を参照してください。そして、次の手順を行います。

  1. ルートドメインを設定します。

    NIS 互換モードでルートドメインを管理する場合は、nisserver を使用します(セットアップスクリプトを使用しない場合は、rpc.nisd および nissetup に -y フラグを付けて使用してください)。

  2. ルートドメインテーブルを生成します。

    NIS マップまたはテキストファイルから、 nispopulate を使用して、情報を転送することができます。もちろん、 nistbladm や nisaddent を使用して、同時に複数のエントリを作成することもできます。

  3. ルートドメインのクライアントを設定します。

    ルートドメインに 2、3 のクライアントを設定して、その操作を正しくテストできるようにします。完全な DES 認証を使用してください。これらのクライアントマシンの中には、後でルートの複製サーバーに変換されたり、ルートドメインをサポートする管理者のマシンとして機能するものがあります。NIS+ サーバーは、個人用のマシンにはなりません。

  4. サイト固有の NIS+ テーブルを作成、または変換します。

    新しい NIS+ ルートドメインにサイト固有のカスタム NIS+ テーブルが必要な場合は、 nisaddent を使用してそれらのテーブルを作成し、 nistbladm を使用して、それらのテーブルに NIS データを転送します。

  5. ルートドメインのグループに管理者を追加します。

    管理者には、LOCAL 資格と DES 資格が必要です ( nisaddcred を使用します)。管理者のマシンは、ルートドメインのクライアントでなければなりません。また、管理者の root 識別情報は、DES 資格を持つ NIS+ クライアントでなければなりません。

  6. 必要に応じて、sendmailvars テーブルを変更します。

    新しいドメイン構造の結果、電子メール環境が変更された場合は、新しいエントリを使って、ルートドメインの sendmailvars テーブルを生成します。

  7. ルートドメインの複製サーバーを設定します。

    まず、クライアントをサーバーに変換します (NIS 互換のために rpc.nisd に -Y オプションを使用し、DNS 転送が必要な場合は -B も使用します)。次に、nisserver -R を使って、それらのサーバーをルートドメインに関連付けます。

    NIS 互換の場合は、 rpc.nisd に -Y オプションを使用して実行します。そして、 /etc/init.d/rpc ファイルを編集して、EMULYP 行からコメント記号 (#) を削除します。DNS 転送の場合は、rpc.nisd に -B オプションを使用します。

  8. ルートドメインの動作をテストします。

    一連のインストール固有のテストルーチンを作成して、NIS+ に切り替えた後に、クライアントの機能を確認します。これにより、移行処理の効率が向上して、問題が減ります。このドメインをおよそ 1 週間操作してから、他のユーザーを NIS+ に移行してください。

  9. 名前空間の残りを設定します。

    これ以上クライアントを NIS+ に移行しないで処理を進め、ルートドメインの下にある他のドメインをすべて設定します。これには、マスターサーバーと複製サーバーの設定も含まれます。新しい各ドメインを、ルートドメインの場合と同様に完全にテストして、構成とスクリプトが正しく機能することを確認します。

  10. 名前空間の動作をテストします。

    保守、バックアップ、復元などのすべての操作手順をテストします。名前空間内のすべてのドメイン間での情報共有処理をテストします。NIS+ 全体の操作環境を検査し終わるまでは、第 2 段階に進まないでください。

  11. NIS+ ドメインのセキュリティ構成をカスタマイズします。

    これは、すべてが正しく機能していれば必要ありません。ただし、不正なアクセスから保護したい情報がある場合は、NIS+ テーブルのデフォルトアクセス権を変更して、 NIS クライアントであっても、それらの情報にアクセスできないようにすることができます。また、NIS+ グループのメンバーの関係と NIS+ の構成オブジェクトのアクセス権を再構成して、管理責任を割り当てることもできます。

第 2 段階 - NIS+ 名前空間を他の名前空間に接続する

  1. ルートドメインを DNS 名前空間に接続します (任意)。

    NIS+ クライアントは、ネームサービススイッチを使って、インターネットに接続することができます。マシンが DNS クライアントでもある場合、そのネームサービススイッチ構成ファイルを設定して、NIS+ テーブルや NIS マップだけでなく、DNS ゾーンファイル内の情報を検索することもできます。

    各クライアントの /etc/nsswitch.conf ファイルと /etc/resolv.conf ファイルを正しく構成してください。/etc/nsswitch.conf ファイルは、クライアントのネー ムサービススイッチ構成ファイルです。/etc/resolv.conf では、クライアントの DNS サーバーの IP アドレスを一覧にします。

  2. NIS+ と DNS の共同操作をテストします。

    情報への要求を複数の名前空間の間で、問題なく渡せることを確認します。

  3. NIS+ を NIS と並行して操作している場合は、情報の転送をテストします。

    nispopulate スクリプトを使用して、NIS から NIS+ へ情報を転送します。NIS+ から NIS へデータを転送するには、 nisaddent -d を実行後、 ypmakeを実行します (詳細についてはマニュアルページを参照してください)。 スクリプトを使用して、この処理を自動化します。テーブル、特に hosts テーブルと passwd テーブルを同期させる方針を設定します。NIS 環境と NIS+ 環境の間で整合性を維持するために使用するツールをテストします。NIS+ テーブルを実際の情報源にする時期を決めます。

  4. DNS と NIS の両方との NIS+ の操作をテストします。

    3 つの名前空間をすべて一緒にテストして、追加した接続に問題がないことを確認します。

第 3 段階 - NIS+ 名前空間を十分に稼働させる

  1. クライアントを NIS+ に移行します。

    一度に 1 つのワークグループのクライアントを移行して、1 つのサブネット内のワークグループをすべて移行してから、他のサブネットでの移行を行います。このように、1 つのサブネット内のクライアントをすべて移行したら、そのサブネット上の NIS サービスを削除することができます。各クライアントを移行したら、検査スクリプトを実行して、移行が正しく行われたことを確認します。この検査スクリプトは、ユーザーに対して、問題とその問題の報告に役立つサポート形態を通知します。実際に必要は手順は、サイトによって異なります。

    nisclient スクリプトを使用して、NIS クライアントを NIS+ クライアントに移行します。クライアントの DNS 構成を変更する必要がある場合は、独自のスクリプトを作成して、その処理を自動化しなければなりません。

    /usr/local のような共有の、マウントされるディレクトリがサイトにあれば、時間を節約することができます。このディレクトリにスクリプトを置いて、移行時に、このスクリプトをスーパーユーザーとして実行するよう依頼する電子メールをクライアントに送ることができます。

  2. クライアントの移行中、移行の状況を監視します。

    計画と突き合わせて進行状況を追跡し、計画段階では予測できなかった重大な問題がないかを監視します。状況を通知して、関係するグループがそれを追跡できるようにします。

  3. NIS サーバーを削除します。

    サブネット上のすべてのクライアントが NIS+ に移行されたら、NIS サーバーを削除します。特定のサブネットに、NIS サービスを必要とするクライアントがある場合は、NIS+ サーバーの NIS 互換モード機能を使用します。NIS サーバーをそのままにしないでください。

  4. NIS+ のパフォーマンスを評価します。

    実装が完了したら、NIS+ が正しく機能しているかどうかをテストします。

  5. NIS+ 環境を最適化します。

    性能の評価結果に基づいて、必要であれば NIS+ の環境を変更します。このような改善には、選択した複製サーバーを負荷の高いドメインに追加するような簡単なものや、ドメインのグループの NIS+ 情報の記憶領域を再編成したりすることが含まれます。

  6. 新しいドメインを整理します。

    移行の際に、処理の簡便化のため、古いドメインの名前を変更しなかった場合は、それらをここで新しい NIS+ の命名方式に合わせて変更します。たとえば、物理的な位置を表す名前を持つドメインをいくつか残し、その一方で組織的な階層へ移行した場合は、物理的な位置を表す名前を組織を表す名前に変更します。

第 4 段階 - NIS 互換ドメインを移行する

  1. 最後の NIS クライアントを NIS+ に移行します。

    NIS 互換の NIS+ ドメインが、できるだけ早く不要になるようにします。最後の NIS クライアントを NIS+ に移行すると、NIS+ のセキュリティ機能を利用できるようになります。ネットワーク上で Solaris 以外のコンピュータを実行している場合は、NIS 互換の NIS+ ドメインを削除することはできません。

  2. セキュリティ構成を調整します。

    NIS クライアントがなくなったら、NIS+ サーバーを標準モードで再起動して、NIS+ テーブルに対して nischmod を実行し、アクセス権レベルを変更して、NIS 互換によって生じたセキュリティの不備を削除することができます。NIS+ 主体に以前に資格を作成しなかった場合は、ここで資格を作成してください。認証されていない主体のアクセスは制限してください。

  3. その他の評価とプログラムの改善を行います。

    操作手順を評価して、改善できるものがないかを調べます。特に、問題回復に使用される手順を調べてください。新しい NIS+ リリースと機能強化の可能性について検討します。また、新しい NIS+ テーブルを必要とする可能性がある Solaris の構成要素の開発を調査します。さらに、NIS+ 管理作業をより効率的に実行できるようにする自動化ツールを探します。最後に、社内の開発担当者と協力して、NIS+ API を利用できるように援助してください。

    これで NIS+ への移行は完了です。

第 27 章 NIS+ から LDAP への移行

この章では、NIS+ ネームサービスから LDAP ネームサービスへの移行方法について説明します。

概要

NIS+ サーバーデーモン rpc.nisd は、NIS+ データを /var/nis/data ディレクトリ内の NIS+ 固有の書式ファイルに格納します。 NIS+ データは、LDAP と同期化することができます。従来は、そのために外部エージェントが必要でした。しかし、新しい NIS+ デーモンでは、LDAP サーバーを NIS+ データのデータリポジトリとして使用できるようになりました。これにより、NIS+ および LDAP クライアントが同一のネームサービス情報を共有できるため、メインネームサービスを NIS+ から LDAP に移行する作業がより簡単になりました。LDAP をネームサービスとして 使用する場合は、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照してください。

デフォルトの rpc.nisd デーモンは、従来と同様に機能し、/var/nis/data の NIS+ データベースにデータを格納します。システム管理者は、必要に応じて、NIS+ データベースの一部の権限を LDAP サーバーに譲渡し、NIS+ データのリポジトリとして使用することができます。この場合、/var/nis/data ファイルは rpc.nisd デーモンのキャッシュとして機能するため、LDAP ルックアップトラフィックが減少します。また、LDAP サーバーが一時的に使用できなくなった場合でも、 rpc.nisd デーモンは動作を継続できます。NIS+ および LDAP は常に同期化されるだけでなく、NIS+ および LDAP 間でデータをアップロードまたはダウンロードすることができます。

LDAP に対するデータのマッピングは、構成ファイルの柔軟な構文を使用して行います。client_info.org_dir および timezone.org_dir 以外のすべての標準 NIS+ テーブルは、テンプレートマッピングファイル /var/nis/NIS+LDAPmapping.template で対応できます。ほとんどの NIS+ インストールのテーブルは、変更する必要がないか、わずかな変更で済みます(client_info.org_dir と timezone.org_dir については、「client_info および timezone テーブル」 を参照)。NIS+ データは、LDAP ディレクトリ情報ツリー (DIT) に配置されます。また、マッピングファイルでは、LDAP から入力された NIS+ データに対して生存期間 (TTL) を設定できます。多くの場合、NIS+ 列値および LDAP 属性値は 1 対 1 で対応づけられますが、マッピングファイルはより複雑な関係にも対応できます。

新しい /etc/default/rpc.nisd ファイルは、LDAP サーバーと認証を選択するときに使用し、rpc.nisd の一般的な動作をいくつか制御します。rpc.nisd(4) のマニュアルページを参照してください。マッピングの詳細は、/var/nis/NIS+LDAPmapping ファイルを使用して指定します。詳細については、NIS+LDAPmapping(4) のマニュアルページを参照してください。このファイルの名前を変更するときは、rpc.nisd に -m コマンド行オプションを指定して使用します。詳細については、rpc.nisd(1M) のマニュアルページを参照してください。

この章では、次の用語を使用します。

構成ファイル

rpc.nisd の処理は、2 つの構成ファイルを使用して制御します。

構成とは、値を定義済みの属性に割り当てることです。構成ファイル以外に、構成属性を LDAP から読み込むこともできます (「構成情報を LDAP に格納する」 を参照)。また、rpc.nisd コマンドの -x オプションに構成属性を指定することもできます。複数の場所で同じ属性が指定されている場合、優先順位 (高から低) は次のとおりです。

  1. rpc.nisd -x オプション

  2. 構成ファイル

  3. LDAP

属性とオブジェクトクラスの作成

NIS+ と LDAP のマッピングの構成によっては、新しい LDAP 属性とオブジェクトクラスをいくつか作成しなければならないことがあります。次の例では、これらの作成方法として、 ldapadd コマンドの入力として使用できる LDIF データを指定する方法を示します。LDIF データを含むファイルを作成してから、ldapadd(1) を起動します。

# ldapadd -D bind-DN-f ldif -file

この方法は、iPlanetTM Directory Server 5.1 およびほかの LDAP サーバーでも使用します。

注 -

ただし、defaultSearchBase、 preferredServerList、および authenticationMethod 属性を除き、この章で使用されているオブジェクト識別子 (OID) は、SYNTAX 仕様と同様に、説明用に挙げているだけです。OID の基準はありません。任意の OID を使用できます。

移行の準備

NIS+ データを LDAP リポジトリに格納するために必要な構成の概要については、NIS+LDAPmapping(4) のマニュアルページを参照してください。ここでは、構成ファイルの編成について詳細に説明します。

/etc/default/rpc.nisd

/etc/default/rpc.nisd ファイルに値を割り当てるときは、すべて attributeName=value タイプとします。

一般的な構成

次の属性は、 rpc.nisd の一般的な構成を制御します。また、LDAP マッピングが有効かどうかにかかわらず、アクティブになります。 これらの属性は通常、デフォルトのままにしておきます。詳細については、rpc.nisd(4) のマニュアルページを参照してください。

LDAP からの構成データ

次の属性は、LDAP からのその他の構成属性の読み込みを制御します。これらの属性自体を LDAP に常駐させることはできません。コマンド行または構成ファイルから読み込む必要があります。詳細については、rpc.nisd(4) のマニュアルページを参照してください。

サーバーの選択

認証とセキュリティ

認証方式と、その方式に適切なプロキシユーザー (バインド識別名 DN) とパスワード (鍵またはその他の共有された機密情報)。これらは、 rpc.nisd デーモンと LDAP サーバーの間で使用されます。詳細については、「セキュリティと認証」 を参照してください。

必要に応じて、SSL を使用し、証明書ファイルの場所を指定します。詳細については、「SSL の使用」 を参照してください。

LDAP および NIS+ 内のデフォルトの場所

LDAP 通信のタイムアウト制限、サイズ制限、および参照アクション

上のパラメータ (順番に、ldap bind、modify、add、および delete 操作) でタイムアウトを設定します。これらのパラメータは通常、デフォルトのままにしておきます。

上のパラメータには、LDAP 検索処理のタイムアウトを設定します。下のパラメータでは、サーバー側の検索時間制限を要求します。nisplusLDAPsearchTimeLimit では、LDAP サーバーが検索要求に使用する時間を制御します。このため、nisplusLDAPsearchTimeLimit には nisplusLDAPsearchTimeout 以上の値を設定してください。NIS+ サーバー、LDAP サーバー、および 2 つのサーバー間の接続のパフォーマンスに応じて、検索制限をデフォルト値より大きくしなければならないことがあります。rpc.nisd から送信されたタイムアウトに関するシステムログメッセージを基にして、これらの値を大きくするかどうかを判断します。

エラー処理

次のパラメータには、LDAP 処理中にエラーが発生したときに、実行する処理を指定します。これらのパラメータは通常、デフォルトのままにしておきます。詳細については、rpc.nisd(4) のマニュアルページを参照してください。

一般的な LDAP 処理の制御

/var/nis/NIS+LDAPmapping

この構成の名前は、rpc.nisd(1M) の -m オプションを使用して変更できます。NIS+LDAPmapping ファイルは、NIS+ および LDAP マッピングのマスタースイッチとして機能します。

マッピングファイルに対してデフォルト以外の名前を使用する場合は、/etc/init.d/rpc ブートスクリプトを編集して、rpc.nisd 起動行にそのマッピングファイル名を指定する必要があります。

LDAP に対応づける NIS+ オブジェクトごとに、 NIS+LDAPmapping ファイルに 2 - 5 個の属性を指定します。指定する属性値は、オブジェクトとデフォルト値によって異なります。

nisplusLDAPdatabaseIdMapping

別名は、オブジェクトがほかのマッピング属性で使用されるときに設定する必要があります。NIS+ オブジェクト名が完全指定されていない場合 (ドットで終わっていない場合) は 、nisplusLDAPbaseDomain の値が付加されます。

たとえば、次のようになります。


nisplusLDAPdatabaseIdMapping	rpc:rpc.org_dir

このパラメータでは、データベース ID rpc を NIS+ rpc.org_dir テーブルの別名として定義しています。

NIS+ テーブルオブジェクトを 2 つの異なるデータベース ID ごとに 2 回定義する場合、テーブルオブジェクト自体 (このオブジェクトを LDAP に対応づける必要がある場合) として定義し、次にテーブルエントリとして定義します。たとえば、次のようになります。


nisplusLDAPdatabaseIdMapping	rpc_table:rpc.org_dir
nisplusLDAPdatabaseIdMapping	rpc:rpc.org_dir

まず、データベース ID rpc_table と rpc を、rpc.org_dir テーブルの別名として定義します。次に、rpc_table を rpc.org_dir テーブルオブジェクトに使用し、rpc をそのテーブルのエントリに使用することを定義します。

nisplusLDAPentryTtl

rpc.nisd デーモンのローカルデータベースは、メモリ内およびディスク上で LDAP データのキャッシュとして機能します。nisplusLDAPentryTtl 属性を使用すれば、そのキャッシュ内のエントリの生存期間 (TTL) 値を設定できます。各データベース ID には、3 つの TTL があります。最初の 2 つの TTL は、rpc.nisd が、対応する NIS+ オブジェクトデータをディスクから最初に読み込むときの初期 TTL を制御します。3 番目の TTL は、NIS+ オブジェクトデータを LDAP から読み込んだとき (更新したとき) にオブジェクトに割り当てられます。

たとえば、次の場合、rpc.org_dir テーブルオブジェクトは、21600 - 43200 秒の範囲からランダムに選択された初期 TTL を取得します。


nisplusLDAPentryTtl	rpc_table:21600:43200:43200

初期 TTL の生存期間が切れると、テーブルオブジェクトが LDAP から再度読み込まれ、TTL が 43200 秒に設定されます。

同様に、次の場合は、テーブルオブジェクトが最初に読み込まれたときに、800 - 3600 秒から選択された初期 TTL が、 rpc.org_dir テーブルのエントリに割り当てられます。


nisplusLDAPentryTtl	rpc:1800:3600:3600

各エントリは、指定された範囲からランダムに選択された TTL を取得します。テーブルエントリが期間切れになり、更新されると、TTL は 3600 秒に設定されます。

TTL 値を選択するときは、パフォーマンスと整合性のバランスを考慮してください。rpc.nisd によって LDAP データがキャッシュされているときは、その TTL が大きい場合、rpc.nisd に LDAP データとの関連付けを設定していない場合とパフォーマンスは同じになります。しかし、rpc.nisd 以外のエンティティによって LDAP データが変更されると、変更が NIS+ に反映されるまでにかなりの時間がかかります。

逆に、小さな値 (またはゼロ) を TTL に設定すると、LDAP データに対する変更が NIS+ にすばやく反映されますが、パフォーマンスが低下する可能性があります。通常、NIS+ 上で LDAP データの読み込みまたは書き込みを行うときは、LDAP 通信を行わない場合と比較して、2 から 3 倍の時間に加えて LDAP ルックアップの時間がかかります。パフォーマンスはハードウェアリソースによって大きく異なりますが、大きな LDAP コンテナ (数万から数十万のエントリ) を走査して、更新が必要な NIS+ エントリを識別するのは、かなりの時間を必要とします。rpc.nisd デーモンは、この走査をバックグラウンドで実行して、走査の実行中も可能なデータを供給し続けます。しかし、バックグラウンドで走査している場合でも、NIS+ サーバーの CPU とメモリは消費されます。

NIS+ データと LDAP を同期化する重要性を十分に考慮して、適用可能な最も長い TTL を NIS+ オブジェクトごとに選択してください。デフォルト (nisplusLDAPentryTtl を指定しないとき) は 1 時間です。テンプレートマッピングファイル /var/nis/NIS+LDAPmapping.template を適用すると、テーブルエントリ以外のオブジェクトの TTL が 12 時間に変更されます。ただし、テーブルエントリ以外のオブジェクトは自動的に認識されないため、テーブルエントリ以外のオブジェクトのマッピングを追加すると、TTL はデフォルトの 1 時間に設定されます。

注 -

存在しないオブジェクトには 、TTL はありません。このため、NIS+ テーブル内で LDAP に対応づけられたエントリの TTL を有効にしても、NIS+ に存在しないエントリを要求すると、常に LDAP を照会してそのエントリを取得しようとします。

nisplusLDAPobjectDN

nisplusLDAPobjectDN には、対応づけられた NIS+ オブジェクトごとに、オブジェクトデータが常駐する LDAP DIT 内の対応する場所を設定します。また、LDAP エントリが削除されたときに実行する処理も指定できます。nisplusLDAPobjectDN 値は、3 つの部分から構成されます。最初の部分には、LDAP データの読み込み元を指定します。2 番目の部分には、LDAP データの書き込み先を指定します。3 番目の部分には、LDAP データが削除されたときの処理を指定します。次の例を参照してください。


nisplusLDAPobjectDN	rpc_table:¥ 
                          cn=rpc,ou=nisPlus,?base?¥
                                   objectClass=nisplusObjectContainer:¥ 
                          cn=rpc,ou=nisPlus,?base?¥ 
                                   objectClass=nisplusObjectContainer,¥ 
                                       objectClass=top

この例では、rpc.org_dir テーブルオブジェクトが DN cn=rpc,ou=nisPlus から読み込まれます。このとき、DN 値がコンマで終了しているため、defaultSearchBase 属性 (検索範囲) の値として base が付加されます。また、ObjectClass 属性の値が nisplusObjectContainer であるエントリが選択されます。

このテーブルオブジェクトは、読み込み元と同じ場所に書き込まれます。削除については指定されていないため、デフォルトの処理が実行されます。NIS+ テーブルオブジェクトが削除されると、LDAP エントリ全体も削除されます。

データを読み込むだけで LDAP に書き込まない場合は、書き込み部分を省略し、読み込み部分との区切り文字であるコロンも省略します。


nisplusLDAPobjectDN	rpc_table:¥
                          cn=rpc,ou=nisPlus,?base?¥
                          objectClass=nisplusObjectContainer

nisplusObjectContainer オブジェクトクラスは、RFC 2307 に準拠していません。このオブジェクトクラスを使用するには、LDAP サーバーを 「テーブルエントリ以外の NIS+ オブジェクトのマッピング」 で説明するように構成する必要があります。

rpc.org_dir テーブルエントリには、次の例も使用できます。


nisplusLDAPobjectDN rpc:ou=Rpc,?one?objectClass=oncRpc:¥
                          ou=Rpc,?one?objectClass=onRpc,objectClass=top

この例では、テーブルエントリの読み込みおよび書き込みが、ベース ou=Rpc に対して行われます。コンマで終了しているため、 defaultSearchBase 値が付加されます。objectClass 属性の値が oncRpc であるエントリを選択してください。LDAP の ou=Rpc コンテナ内にエントリを作成するときは、objectClass の値として top も指定する必要があります。

デフォルト以外の削除を指定する場合は、次の例を参照してください。


nisplusLDAPobjectDN	user_attr:¥
                          ou=People,?one?objectClass=SolarisUserAttr,¥
                              solarisAttrKeyValue=*:¥
                          ou=People,?one?objectClass=SolarisUserAttr:¥
                              dbid=user_attr_del

user_attr.org_dir データは、ou=People LDAP コンテナに存在します。このコンテナには、ほかのソース (passwd.org_dir NIS+ テーブルなど) のアカウント情報も入ります。

そのコンテナ内のエントリから、solarisAttrKeyValue 属性を持つものが選択されます。user_attr.org_dir データが、これらのエントリにだけ含まれるためです。nisplusLDAPobjectDN の dbid=user_attr_del 部分の定義によって、user_attr.org_dir NIS+ テーブル内のエントリが削除されると、対応する LDAP エントリが存在する場合は、データベース ID が user_attr_del のルールセットのルールに基づいて 削除されます。詳細については、「nisplusLDAPcolumnFromAttribute」 を参照してください。

nisplusLDAPattributeFromColumn

nisplusLDAPattributeFromColumn には、NIS+ データを LDAP に対応づけるときのルールを指定します。LDAP から NIS+ データへのマッピングルールは、nisplusLDAPcolumnFromAttribute に指定します。

nisplusLDAPcolumnFromAttribute

nisplusLDAPcolumnFromAttribute には、LDAP データを NIS+ に対応づけるときのルールを指定します。

エントリマッピングの完全な構文については、 NIS+LDAPmapping(4) のマニュアルページを参照してください。ここでは、わかりやすい例をいくつか挙げます。

NIS+ rpc.org_dir テーブルには、cname、name、numbe、およびcomment という列が含まれます。たとえば、NIS+ RPC プログラム番号 (100300) に対して、正規名として nisd が指定され、別名として rpc.nisd と nisplusd が指定されているとします。このエントリは、rpc.org_dir の次の NIS+ エントリを使用して表現できます。


nisd nisd 100300	NIS+ server
nisd rpc.nisd 100300	NIS+ server
nisd nisplusd 100300	NIS+ server

defaultSearchBase の値を dc=some,dc=domain と想定します。対応する LDAP は、ldapsearch(1) を実行すると次のように表示されます。


cn=nisd,ou=Ppc,dc=some,dc=domain
cn=nisd
cn=rpc.nsid
cn=nisplusd
oncrocnumber=100300
description=NIS+ server
objectclass=oncRpc
objectclass=top

この例は、NIS+ および LDAP が単純に 1 対 1 で対応づけられている場合です。この場合、NIS+ から LDAP へのマッピング属性値は、次のようになります。


nisplusLDAPattributeFromColumn ¥ 
rpc:		dn=("cn=%s,", name), ¥ 
				cn=cname, ¥
				cn=name, ¥
				oncRpcNumber=number, ¥
				description=comment

このエントリの DN として、cn=%s が構成されます。cname 列の値が %s に代入されます。


cn=nisd,

値がコンマで終了しているため、 nisplusObjectDN の読み込みベース値が付加され、次のようになります。


cn=nisd,ou=Rpc,dc=some,dc=domain

oncRpcNumber 属性および description 属性の値には、対応する NIS+ 列の値が代入されます。rpc.nisd によって、複数の NIS+ エントリが 1 つの LDAP エントリに収集され、異なる name 列値を表す複数の cn 値が生成されます。

同様に、LDAP から NIS+ へのマッピングは、次のようになります。


nisplusLDAPcolumnFromAttribute ¥ 
rpc:    cname=cn, ¥
        (name)=(cn), ¥
        number=oncRpcNumber, ¥
        comment=description

この例では、oncRpcNumber および description の値が、対応する NIS+ 列に割り当てられます。複数値 cn ((cn) として示す) が、複数の name 列の値 ((name) として示す) に対応づけられます。name 列は複数値列でないため、rpc.nisd によって cn 値ごとに 1 つの NIS+ エントリが作成されます。

最後に、削除に使用するルールセットの例を、nisplusLDAPattributeFromColumn 値を使って説明します。


nisplusLDAPattributeFromColumn ¥
user_attr_del:	dn=("uid=%s,", name), ¥
        SolarisUserQualifier=, ¥
        SolarisAttrReserved1=, ¥
        SolarisAttrReserved2=, ¥
        SolarisAttrKeyValue=

すでに述べたように、user_attr.org_dir データは、 ほかのテーブル (passwd.org_dir など) のアカウント情報と、 ou=People コンテナを共有しています。user_attr.org_dir テーブルのエントリが削除されたときに、 ou=People エントリ全体を削除したいとはおそらく考えないでしょう。この例ではエントリ全体を削除する代わりに、user_attr.org_dir エントリが削除されたときに、SolarisUserQualifier 、SolarisAttrReserved1、SolarisAttrReserved2 、および SolarisAttrKeyValue 属性が存在する場合、次のルールに指定されている ou=People エントリから削除されます。


dn=("uid=%s,", name)

これ以外の LDAP エントリは変更されません。

NIS+ から LDAP への移行シナリオ

NIS+ から LDAP への移行シナリオの例を挙げます。

すべての NIS+ データを 1 回の操作で LDAP に変換する方法

  1. rpc.nisd を使用して、LDAP に存在しない NIS+ データをすべてアップロードします。

    NIS+ と LDAP のすべてのデータマッピングが、デフォルトの場所 (/var/nis/NIS+LDAPmapping) に設定されている場合は、次のコマンドを使用します。

    # /usr/sbin/rpc.nisd -D ¥

    -x nisplusLDAPinitialUpdateAction=to_ldap ¥

    -x nisplusLDAPinitialUpdateOnly=yes

    上記のコマンドによって、rpc.nisd デーモンによりデータが LDAP にアップロードされて、変換が終了します。この処理を実行しても、NIS+ データは変更されません。

    rpc.nisd(4) のマニュアルページの nisplusLDAPinitialUpdateAction 属性を参照してください。

すべての LDAP データを 1 回の操作で NIS+ に変換する方法

  1. rpc.nisd を使用して、すべての LDAP データを NIS+ にダウンロードし、既存の NIS+ データを上書きします。

    NIS+ と LDAP のすべてのデータマッピングが、デフォルトの場所 (/var/nis/NIS+LDAPmapping) に設定されている場合は、次のコマンドを使用します。

    # /usr/sbin/rpc.nisd -D ¥

    -x nisplusLDAPinitialUpdateAction=from_ldap ¥

    -x nisplusLDAPinitialUpdateOnly=yes

    上記のコマンドによって、rpc.nisd デーモンによりデータが LDAP からダウンロードされて、変換が終了します。この処理を実行しても、LDAP データは変更されません。

    rpc.nisd(4) のマニュアルページの nisplusLDAPinitialUpdateAction 属性を参照してください。

NIS+ データと LDAP データのマージ

NIS+ および LDAP 間でデータの衝突が発生したときは、NIS+ または LDAP データのどちらかを正式なものとして解決しなければなりません。「NIS+ から LDAP への移行シナリオ」 では、NIS+ データと LDAP データを同期化する方法について説明しています。データをマージするときは、ほかの方法と比べて複雑な手順が必要になります。

この節で挙げた手順では、次の点を前提としています。

NIS+ データと LDAP データをマージする方法
警告 - 警告 -

手順 4 のダウンロードデータと、手順 10 のアップロードデータが一致しない場合は、アップロードデータによって変更が上書きされます。このため、この手順を実行しているときは、LDAP データの変更はできるだけ避けてください。詳細については、LDAP サーバーのマニュアルを参照してください。

  1. nisbackup コマンドを使用して、すべての NIS+ データをバックアップします。

    # nisbackup -a /nisbackup

  2. LDAP とマージするデータが含まれる NIS+ テーブルを特定します。これらのテーブルの内容をフラットファイルにダンプします。たとえば、次のように nisaddent を使用して、group.org_dir の内容をダンプします。

    # nisaddent -d group | sort> /before/group

    パイプを使って nisaddent の出力を sort の入力として渡すと、比較処理が簡単になります。

  3. rpc.nisd デーモンを停止します。

    # pkill rpc.nisd

  4. LDAP データを NIS+ にダウンロードします。

    # /usr/sbin/rpc.nisd -D -m tmpmap ¥

    -x nisplusLDAPinitialUpdateAction=from_ldap ¥

    -x nisplusLDAPinitialUpdateOnly=yes

  5. rpc.nisd デーモンを起動します。

    # /usr/sbin/rpc.nisd

    rpc.nisd デーモンが、LDAP からダウンロードしたデータを提供するようになります。解決を必要とする衝突を NIS+ クライアント上で発生させないようにする必要がある場合は、これ以降の手順は、ほとんどまたはすべての NIS+ クライアントが動作していないときに実行してください。

  6. 影響を受けるテーブルの NIS+ データをダンプします。

    次の例では、 group.org_dir テーブルをダンプします。

    # nisaddent -d group | sort> /after/group

  7. 任意のファイルマージ手順を使用して、マージしたテーブルを作成します。diff(1) 以外のツールを使用できない場合は、このコマンドを使用して /before ファイルと /after ファイルとの相違点を収集し、テキストエディタを使用して手動でマージすることができます。

    次の例では、マージ後のテーブルが /after に格納されていることを前提としています。

  8. マージ後のデータを NIS+ に読み込みます。次の例では、 group テーブルを読み込みます。

    # nisaddent -m -f /after/group group

  9. マージ後のテーブルから、不要な LDAP エントリを削除します。

    A . マージ後の NIS+ データ内に存在しない LDAP エントリが、アップロード後の LDAP に必要がない場合、これらの LDAP エントリは削除する必要があります。

    LDAP サーバーには、コンテナのすべてのエントリを削除する方法など、複数のエントリを削除する便利な方法が提供されていることがあります。提供されていない場合は、ldapsearch(1) を使用して、各コンテナのエントリの一覧を生成することができます。たとえば、ou=Rpc コンテナに含まれるすべてのエントリの一覧を生成するには、ldapsearch(1) を次のように使用します。

    # ldapsearch -h server-address -D bind-DN -w password ¥

    -b ou=Rpc,search-base 'objectClass=*' dn | ¥

    grep -i ou=Rpc | grep -v -i ¥^ou=Rpc> ¥

    /tmp/delete-dn

    メタ引数 (server-address、 bind-DN など) については、「パフォーマンスとインデックス処理」 を参照してください。

    B. 結果ファイル (/tmp/delete-dn) を編集して、削除するエントリだけを指定します。コンテナのすべてのエントリを削除する場合は、該当するファイルは操作しないで、NIS+ アップロードを使用して LDAP データを復元することもできます。どちらの方法を使用する場合でも、LDAP データをバックアップしてから、次の ldapdelete 操作を実行してください。

    C. ldapdelete を使用して、LDAP エントリを削除します。stdout (通常は、削除したエントリごとに空白行が 1 行ずつ出力される) は、/dev/null にリダイレクトします。

    # ldapdelete -h server-address -D bind-DN -w password ¥

    /tmp/delete-dn /dev/null

    D. 削除するエントリが 1 つ以上含まれるコンテナごとに、前述の手順を繰り返します。

  10. これで NIS+ には、マージされたデータが生成されます。このデータは、LDAP にアップロードできます。次の操作を実行します。

    rpc.nisd デーモンを停止します。

    # pkill rpc.nisd

    アップロードを実行します。

    # /usr/sbin/rpc.nisd -D -m tmpmap ¥

    -x nisplusLDAPinitialUpdateAction=to_ldap ¥

    -x nisplusLDAPinitialUpdateOnly=yes

  11. rpc.nisd デーモンを再起動します。

    • rpc.nisd デーモンが LDAP リポジトリを使用する場合は、適切なマッピングファイルを指定します。

    • rpc.nisd デーモンを NIS (YP) エミュレーションに対応させる場合は、-Y オプションを指定します。

    # /usr/sbin/rpc.nisd -m mappingfile [ -Y ]

    手順 10 のアップロードコマンドから、-x nisplusLDAPinitialUpdateOnly=yes を省略することもできます。省略した場合、アップロードが完了すると、rpc.nisd デーモンは NIS+ データの提供を開始します。

マスターと複製

NIS+ マスターだけが、データを LDAP に書き込むことができます。NIS+ 複製は、NIS+ マスターから更新を取得するか (LDAP から取得する場合を含む) 、LDAP サーバーから直接データを読み込みます。この 2 つの方法を組み合わせることもできます。つまり、NIS+ 複製を使用するときは、主に 2 つの方法があります。

複製タイムスタンプ

NIS+ 複製が特定の NIS+ ディレクトリに含まれる 1 つ以上のオブジェクトのデータを LDAP から取得しているときは、nisping(1M) によって出力される更新タイムスタンプが NIS+ マスターおよび NIS+ 複製間のデータの整合性を示しているとは限りません。たとえば、NIS+ ディレクトリ dir1 に table1 および table2 テーブルが含まれているとします。複製が table1 および table2 のデータを NIS+ マスターから取得しているときは、次のようなタイムスタンプが出力されます。

# nisping dir1 


Master server is "master.some.domain."
Last update occurred at Mon Aug  5 22:11:09 2002

Replica server is "replica.some.domain." 		
	Last Update seen was Mon Aug  5 22:11:09 2002

これらのタイムスタンプは、マスターおよび複製のデータが完全に一致していることを示しています。しかし、複製が table1 または table2、あるいはその両方のデータを LDAP から取得しているとします。この場合、この出力には、複製がマスターから NIS_PING を受け取り、再同期化のタイムスタンプをシステム管理用に更新したことだけが示されます。LDAP に対応づけられているテーブルのデータは、次のどちらかの場合、NIS+ マスター上のデータと異なることがあります。

このようなデータの不一致を許容できない場合は、NIS+ 複製が常に NIS+ マスターからデータを取得するようにします。NIS+ マスターが常に LDAP からデータを取得するように構成した場合は、複製を変更する必要はありません。

ディレクトリサーバー

rpc.nisd デーモンの LDAP マッピングでは、LDAP プロトコルバージョン 3 を使用して LDAP サーバーと対話します。 デフォルトのマッピング構成 ( /var/nis/NIS+LDAPmapping.template) では、LDAP サーバーが RFC 2307 の拡張版 に準拠していることを前提としています。RFC は、 http://www.ietf.org/rfc.html から入手できます。NIS+ データと LDAP データとのマッピングは、NIS+LDAPmapping(4) を使用して変更できます。ただし、LDAP のデータ編成が RFC 2307 の規定に準拠していることを、基本的な前提としています。

たとえば、LDAP クライアントと NIS+ クライアントとの間でアカウント情報を共有するには、UNIX crypt 書式のアカウント (ユーザー) パスワードを LDAP サーバーに格納できるようにする必要があります。LDAP サーバーをこのように構成できない場合でも、アカウントを含む NIS+ データを LDAP に格納することはできます。その場合、NIS+ ユーザーと LDAP bindDN との間でアカウント情報を完全に共有することはできません。

iPlanet Directory Server 5.1 の構成

iPlanet Directory Server 5.1 のインストール、設定、および管理の詳細については、「iPlanetTM Directory Server 5.1 Collection」を参照してください。

iPlanet Directory Server バージョン 5.1 を構成して、LDAP クライアントが LDAP をネームサービスとして使用できる ようにするには、idsconfig(1M) を使用します。idsconfig(1M) を使用して設定した構成は、NIS+ で LDAP データリポジトリを使用する場合にも適しています。

注 -

iPlanet Directory Server 5.1 以外の LDAP サーバーを使用している場合は、RFC 2307 に準拠するように、サーバーを手動で構成する必要があります。

idsconfig の詳細については、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照してください。

サーバーアドレスとポート番号の割り当て

/etc/default/rpc.nisd ファイルは、ローカル LDAP サーバーをポート 389 で使用するように設定されています。この設定が現在の構成に適していない場合は、preferredServerList 属性に新しい値を設定します。たとえば、LDAP サーバーを IP アドレス 192.0.0.1 とポート 65535 で使用するには、次のように指定します。


preferredServerList=192.0.0.1:65535

セキュリティと認証

NIS+ クライアントおよび NIS+ サーバー間の認証は、NIS+ サーバーが LDAP からデータを取得する場合でも、影響することはありません。ただし、NIS+ データを LDAP に格納するときの整合性を保持するには、rpc.nisd デーモンおよび LDAP サーバー間の認証を必要に応じて設定する必要があります。LDAP サーバーの機能に応じて、さまざまなタイプの認証を利用できます。

rpc.nisd デーモンでは、次の LDAP 認証を利用できます。

この認証方式を利用するときに一定のセキュリティを保証するには、多くの場合、共有された機密情報 (パスワードまたは鍵) と LDAP の DN を関連付ける必要があります。rpc.nisd デーモンで使用する DN は一意なものであり、ほかの目的で使用することもできます。予測される LDAP トラフィックに対応するために、DN には適切な権限を割り当てる必要があります。たとえば、rpc.nisd デーモンが LDAP にデータを書き込む場合は、NIS+ データに使用されるコンテナ内で LDAP データを追加、更新、および削除する権限を、選択した DN に割り当てる必要があります。また、LDAP サーバーでは、リソースの使用方法がデフォルトで制限されている場合があります (検索時間制限、検索結果のサイズ制限など) 。この制限がある場合は、必要な数の NIS+ データコンテナをサポートできるように、選択した DN に対して必要な設定をする必要があります。

SSL の使用

rpc.nisd デーモンは、SSL を使用した LDAP トラフィックのトランスポート層の暗号化にも対応しています。LDAP サーバー認証用の SSL 証明書の生成については、LDAP サーバーのマニュアルを参照してください。SSL 証明書は、NIS+ サーバー上のファイル (/var/nis/cert7.db など) に格納します。/etc/default/rpc.nisd は、次のように変更します。


nisplusLDAPTLS=ssl 
nisplusLDAPTLSCertificateDBPath=/var/nis/cert7.db

SSL 証明書は、承認されていないアクセスから確実に保護する必要があります。この例では、セッションの暗号化と LDAP サーバーの認証が rpc.nisd に提供されます。SSL 証明書では、LDAP サーバーに対する rpc.nisd の認証は提供されません。この証明書には、この LDAP クライアント (rpc.nisd ) の識別情報が含まれていないためです。ただし、rpc.nisd と LDAP サーバーが相互に認証するには、SSL と別の認証方式 (simple、sasl/digest-md5) を組み合わせることができます。

LDAP のセキュリティの詳細については、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照してください。

パフォーマンスとインデックス処理

niscat(1) などを使用して、LDAP に対応づけられた NIS+ テーブルの列挙を rpc.nisd デーモンに 要求すると、テーブル内のエントリの TTL が 1 つでも期限切れになっている場合は、対応する LDAP コンテナが列挙されます。コンテナの列挙はバックグラウンドで実行されるため、LDAP のパフォーマンスはそれほど重要ではありません。ただし、LDAP にインデックスを設定すれば、コンテナが大きい場合でもすばやく列挙することができます。

特定のコンテナの列挙に必要な時間を見積もるには、次のようなコマンドを使用します。

% /bin/time ldapsearch -h server-address -D bind-DN -w password ¥

-b container, search-base 'cn=*' /dev/null

ここで

/bin/time から出力される実際の値は、経過時間です。この値が、対応するテーブルエントリの TTL を 25 パーセント以上占めている場合は (「認証とセキュリティ」 を参照)、LDAP コンテナにインデックスを設定すると有効です。

rpc.nisd では、simple page と VLV インデックス方式がサポートされます。ご使用の LDAP サーバーでサポートされているインデックス方式、およびそのインデックスの作成方法については、LDAP サーバーのマニュアルを参照してください。

テーブルエントリ以外の NIS+ オブジェクトのマッピング

テーブルエントリ以外の NIS+ オブジェクトを LDAP に格納できます。ただし、NIS+ 複製が LDAP からこれらの NIS+ オブジェクトを取得しない限り、LDAP に格納しても値は設定されません。次の方法をお勧めします。

NIS+ エントリの所有者、グループ、アクセス権、および TTL

NIS+ テーブルエントリを LDAP データから作成するときは、そのエントリオブジェクトが存在するテーブルオブジェクトの対応する値を使用して、所有者、グループ、アクセス権、および TTL を初期化する必要があります。環境によっては、これらの NIS+ エントリ属性を個別に設定する必要があります。たとえば、rpc.nispasswdd(1M) デーモンを使用しない環境では、この操作が必要になります。ユーザー自身が NIS+ パスワードを変更して、cred.org_dir テーブルに格納されている Diffie-Hellman キーを再暗号化できるようにするには、passwd.org_dir および cred.org_dir エントリの所有者をそのユーザーに設定し、その所有者に変更権限を割り当てる必要があります。

1 つ以上の NIS+ テーブルエントリの所有者、グループ、アクセス権、または TTL を LDAP に格納するには、次の操作を実行する必要があります。

エントリ属性を LDAP に追加するには

  1. LDAP サーバーのマニュアルを参照して、次の新しい属性とオブジェクトクラスを作成します。LDIF データは、ldapadd に適用できます。属性とオブジェクトクラス OID は、例として挙げています。


    dn: cn=schema
changetype: modify
add: attributetypes
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.4.0 NAME 'nisplusEntryOwner' ¥
                    DESC 'Opaque representation of NIS+ entry owner' ¥
                    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.4.1 NAME 'nisplusEntryGroup' ¥
                    DESC 'Opaque representation of NIS+ entry group' ¥
                    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.4.2 NAME 'nisplusEntryAccess' ¥
                    DESC 'Opaque representation of NIS+ entry access' ¥
                    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.4.3 NAME 'nisplusEntryTtl' ¥
                    DESC 'Opaque representation of NIS+ entry TTL' ¥
                    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
    		 

    dn: cn=schema
changetype: modify
add: objectclasses
    		 

    objectclasses:(1.3.6.1.4.1.42.2.27.5.42.42.5.0 NAME 'nisplusEntryData'¥
SUP top STRUCTURAL DESC 'NIS+ entry object non-column data'¥
    		 

    MUST ( cn ) MAY ( nisplusEntryOwner $ nisplusEntryGroup $¥
nisplusEntryAccess $ nisplusEntryTtl ) )

  2. 関連するテーブルの nisplusLDAPobjectDN 属性値を変更して、新しく作成した nisplusEntryData オブジェクトクラスを書き込み部分に含めます。

    たとえば、passwd.org_dir テーブルの場合、 /var/nis/NIS+LDAPmapping.template をベースにしたテンプレートファイルを使用しているときは、次のように編集します。


    nisplusLDAPobjectDN	passwd:ou=People,?one?objectClass=shadowAccount,¥
                                objectClass=posixAccount:¥
                          ou=People,?one?objectClass=shadowAccount,¥
                                objectClass=posixAccount,¥
                                objectClass=account,objectClass=top

    属性値を次のように編集します。


    nisplusLDAPobjectDN	passwd:ou=People,?one?objectClass=shadowAccount,¥
                                objectClass=posixAccount:¥
                          ou=People,?one?objectClass=shadowAccount,¥
                                objectClass=posixAccount,¥
                                objectClass=nisplusEntryData,¥
                                objectClass=account,objectClass=top

  3. nisplusLDAPattributeFromColumn 属性値および nisplusLDAPcolumnFromAttribute 属性値を編集して、所有者、グループ、アクセス権、または TTL を必要に応じて指定します。

    手順 2 で、これらの値を格納する LDAP 属性を作成しました。NIS+ には、zo_owner 、zo_group、zo_access、および zo_ttl と呼ばれる定義済みの擬似列名が、あらかじめ定義されています。たとえば、passwd.org_dir エントリの所有者、グループ、およびアクセス権を LDAP に格納するには、次の nisplusLDAPattributeFromColumn 値を変更します。


    nisplusLDAPattributeFromColumn ¥
		passwd:		dn=("uid=%s,", name), ¥
				cn=name, ¥
				uid=name, ¥
				userPassword=("{crypt$}%s", passwd), ¥
				uidNumber=uid, ¥
				gidNumber=gid, ¥
				gecos=gcos, ¥
				homeDirectory=home, ¥
				loginShell=shell, ¥
				(shadowLastChange,shadowMin,shadowMax, ¥
				 shadowWarning, shadowInactive,shadowExpire)=¥
					(shadow, ":")

    次のように編集します。


    nisplusLDAPattributeFromColumn ¥
		passwd:		dn=("uid=%s,", name), ¥
				cn=name, ¥
				uid=name, ¥
				userPassword=("{crypt$}%s", passwd), ¥
				uidNumber=uid, ¥
				gidNumber=gid, ¥
				gecos=gcos, ¥
				homeDirectory=home, ¥
				loginShell=shell, ¥
				(shadowLastChange,shadowMin,shadowMax, ¥
				 shadowWarning, shadowInactive,shadowExpire)=¥
					(shadow, ":"), ¥
				nisplusEntryOwner=zo_owner, ¥
				nisplusEntryGroup=zo_group, ¥
				nisplusEntryAccess=zo_access

    同様に、 NIS+ エントリの所有者、グループ、LDAP データからのアクセス権を passwd.org_dir テーブルに設定するには、次の値を変更します。


    nisplusLDAPcolumnFromAttribute ¥
		passwd:		name=uid, ¥
				("{crypt$}%s", passwd)=userPassword, ¥
				uid=uidNumber, ¥
				gid=gidNumber, ¥
				gcos=gecos, ¥
				home=homeDirectory, ¥
				shell=loginShell, ¥
				shadow=("%s:%s:%s:%s:%s:%s", ¥
					shadowLastChange, ¥
					shadowMin, ¥
					shadowMax, ¥
					shadowWarning, ¥
					shadowInactive, ¥
					shadowExpire)

    次のように編集します。


    nisplusLDAPcolumnFromAttribute ¥
		passwd:		name=uid, ¥
				("crypt$%s", passwd)=authPassword, ¥
				uid=uidNumber, ¥
				gid=gidNumber, ¥
				gcos=gecos, ¥
				home=homeDirectory, ¥
				shell=loginShell, ¥
				shadow=("%s:%s:%s:%s:%s:%s", ¥
					shadowLastChange, ¥
					shadowMin, ¥
					shadowMax, ¥
					shadowWarning, ¥
					shadowInactive, ¥
					shadowExpire), ¥
				zo_owner=nisplusEntryOwner, ¥
				zo_group=nisplusEntryGroup, ¥
				zo_access=nisplusEntryAccess

  4. マッピングの変更を有効にするために、rpc.nisd デーモンを再起動します。

    まず、所有者、グループ、アクセス権、および TTL エントリデータを LDAP にアップロードする必要があります。アップロード方法については、「すべての NIS+ データを 1 回の操作で LDAP に変換する方法」 を参照してください。

主体名とネット名

NIS+ 認証は、主体名 (ドメイン名で修飾されたユーザー名またはホスト名) とネット名 (SecureRPC での主体名) に基づいて認証可能なエンティティ (主体) を一意に識別します。RFC 2307 では、NIS+ 認証に使用する Diffie-Hellman 鍵の格納場所は規定していますが、主体名またはネット名の格納場所は規定していません。

/var/nis/NIS+LDAPmapping.template ファイルでは、この問題を回避するために、cred.org_dir テーブルの所有者名 (主体名) から主体名およびネット名のドメイン部分を派生します。つまり、NIS+ ドメインが x.y.z. で、cred.org_dir テーブルの所有者が aaa.x.y.z. の場合、LDAP データから作成された NIS+ エントリの主体名は、次の形式になります。

user or system.x.y.z.

ネット名は次の形式になります。

unix.uid@x.y.z.

unix.nodename@x.y.z.

ほとんどの NIS+ インストールでは、主体名とネット名を作成するときは、この方式でかまいません。ただし、次のような場合は、この方式では成功しません。

client_info および timezone テーブル

RFC 2307 では、NIS+ の client_info.org_dir および timezone.org_dir テーブルに保存する情報は規定していません。このため、これらのテーブルのマッピングは、テンプレートマッピングファイル (/var/nis/NIS+LDAPmapping.template) ではデフォルトで無効になっています。client_info および timezone の情報を LDAP に保存する場合は、LDAP サーバーのマニュアルを参照しながら、以降の節で説明する新しい属性とオブジェクトクラスを作成します。

client_info 属性とオブジェクトクラス

次のような属性とオブジェクトクラスを作成し、client_info データのコンテナを作成します。推奨コンテナ名は ou=ClientInfo です。LDIF データは ldapadd(1) に適用します。属性とオブジェクトクラス OID は、例として挙げています。


dn: cn=schema
changetype: modify
add: attributetypes
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.12.0 ¥
		  NAME 'nisplusClientInfoAttr' ¥
		  DESC 'NIS+ client_info table client column' ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.12.1 ¥
		  NAME 'nisplusClientInfoInfo' ¥
		  DESC 'NIS+ client_info table info column' ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.12.2 ¥
		  NAME 'nisplusClientInfoFlags' ¥
		  DESC 'NIS+ client_info table flags column' ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

dn: cn=schema
changetype: modify
add: objectclasses
objectclasses:	( 1.3.6.1.4.1.42.2.27.5.42.42.13.0 ¥
		  NAME 'nisplusClientInfoData' ¥
		  DESC 'NIS+ client_info table data' ¥
		  SUP top STRUCTURAL MUST ( cn ) ¥
		  MAY ( nisplusClientInfoAttr $ nisplusClientInfoInfo $ nisplusClientInfoFlags ) )

コンテナを作成するには、次の LDIF データをファイルに入力します。実際の検索ベースを searchBase に代入します。

dn: ou=ClientInfo, searchBase

objectClass: organizationalUnit

ou: ClientInfo

objectClass: top

ou=ClientInfo コンテナを作成するために、上記のファイルを ldapadd コマンドの入力として使用します。たとえば、LDAP 管理者の DN が cn=directory manager で、LDIF データが含まれるファイルが cifile の場合は、次のコマンドを実行します。

# ldapadd -D cn="directory manager" -f cifile

必要な認証によっては、ldapadd コマンドを実行するときに、パスワードプロンプトが表示されることがあります。

/var/nis/NIS+LDAPmapping.template ファイルでは、client_info.org_dir テーブルの定義はコメントになっています。これらの定義を実際のマッピングファイルにコピーし、コメント文字「#」を削除して定義を有効にしてから、rpc.nisd デーモンを再起動します。必要に応じて、NIS+ データと LDAP データを同期化します。方法については、「NIS+ から LDAP への移行シナリオ」 を参照してください。

timezone 属性とオブジェクトクラス

次のような属性とオブジェクトクラスを作成し、タイムゾーンデータのコンテナを作成します。推奨コンテナ名は ou=Timezone です。LDIF データは ldapadd(1) に適用できます。属性とオブジェクトクラス OID は、例として挙げています。


dn: cn=schema
changetype: modify
add: attributetypes
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.15.0 NAME 'nisplusTimeZone' ¥
		  DESC 'tzone column from NIS+ timezone table' ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

dn: cn=schema
changetype: modify
add: objectclasses
objectclasses:	( 1.3.6.1.4.1.42.2.27.5.42.42.16.0 NAME 'nisplusTimeZoneData' ¥
		  DESC 'NIS+ timezone table data' ¥
		  SUP top STRUCTURAL MUST ( cn ) ¥
		  MAY ( nisplusTimeZone $ description ) )

ou=Timezone コンテナを作成するには、次の LDIF データをファイルに入力します。実際の検索ベースを searchBase に代入します。

dn: ou=Timezone,searchBase ou: Timezone objectClass: top

objectClass: organizationalUnit

ou=Timezone コンテナを作成するために、上記のファイルを ldapadd(1) の入力として使用します。たとえば、LDAP 管理者の DN が cn=directory manager で、LDIF データが含まれるファイルが tzfile の場合は、次のコマンドを実行します。

# ldapadd -D cn="directory manager" -f tzfile

必要な認証によっては、ldapadd コマンドを実行すると、パスワードプロンプトが表示されることがあります。

/var/nis/NIS+LDAPmapping.template ファイルでは、timezone.org_dir テーブルの定義はコメントになっています。これらの定義を実際のマッピングファイルにコピーし、コメント文字「#」を削除して定義を有効にしてから、rpc.nisd デーモンを再起動します。必要に応じて、NIS+ データと LDAP データを同期化します。方法については、「NIS+ から LDAP への移行シナリオ」 を参照してください。

新しいオブジェクトマッピングの追加

テンプレートマッピングファイル /var/nis/NIS+LDAPmapping.template には、すべての標準 NIS+ オブジェクトのマッピング情報が含まれます。サイトまたはアプリケーション固有のオブジェクトのマッピングをサポートするには、新しいマッピングエントリを追加する必要があります。エントリ以外のオブジェクト (ディレクトリ、グループ、リンク、またはテーブル) の場合は、簡単に追加できます。しかし、エントリオブジェクトの場合、対応するエントリデータの LDAP 編成が NIS+ で使用される編成と大きく異なるときは、エントリの追加が複雑になることがあります。ここでは簡単な例を挙げます。

エントリ以外のオブジェクトを対応づけるには

  1. 対応づけるオブジェクトの完全指定名を検索します。

    このオブジェクト名が nisplusLDAPbaseDomain 属性で指定されるドメイン名に存在する場合は、nisplusLDAPbaseDomain 値に等しい部分は省略できます。

    たとえば、nisplusLDAPbaseDomain の値が some.domain. で、マッピング先のオブジェクトが nodeinfo.some.domain. と呼ばれるテーブルの場合、オブジェクト名は nodeinfo に短縮できます。

  2. オブジェクトを識別するデータベース ID を作成します。

    データベース ID は、使用するマッピング構成に対して一意でなければなりません。一意でない場合は解釈されません。LDAP データには、データベース ID がありません。エントリオブジェクトのマッピングと混同しないように、テーブルエントリではなくテーブルオブジェクト自体を識別するデータベース ID を作成します。ID の末尾には、_table などのわかりやすい文字列を付加します。

    たとえば、データベース ID nodeinfo_table を使用して、データベース ID とオブジェクトの接続を標準のマッピングファイルの場所 (/var/nis/NIS+LDAPmapping) で確立するには、以下を追加します。


    nisplusLDAPdatabaseIdMapping	nodeinfo_table:nodeinfo.some.domain.

    nisplusLDAPbaseDomain が some.domain. の場合は、以下も機能します。


    nisplusLDAPdatabaseIdMapping	nodeinfo_table:nodeinfo

  3. オブジェクトの TTL を決定します。

    TTL とは、 rpc.nisd デーモンがオブジェクトのローカルコピーを有効とみなす期間のことです。TTL が期限切れになると、オブジェクトが次に参照されるときに LDAP ルックアップが初期化され、オブジェクトが更新されます。

    2 つの TTL 値があります。1 番目の TTL は、リブートまたは再起動したあとに、 rpc.nisd デーモンがディスクからオブジェクトを最初に読み込んだときに設定されます。2 番目の TTL は、LDAP から更新されたときに設定されます。1 番目の TTL は、設定した範囲からランダムに選択されます。たとえば、 nodeinfo_table の生存期間を、最初に読み込まれたときには 1 - 3 時間、次回以降に読み込まれたときは 12 時間に設定する場合は、次のように指定します。


    nisplusLDAPentryTtl		nodeinfo_table:3600:10800:43200

  4. オブジェクトデータを LDAP のどこに格納するかを決定します。

    テンプレートマッピングファイルでは、エントリ以外のオブジェクトの格納先が ou=nisPlus コンテナに設定されています。

    この設定を使用する場合に、適切な属性、オブジェクトクラス、およびコンテナをまだ作成していないときは、「テーブルエントリ以外の NIS+ オブジェクトのマッピング」 を参照してください。

    たとえば、nodeinfo オブジェクトを ou=nisPlus,dc=some,dc=domain コンテナに格納し、その LDAP エントリを cn nodeinfo にするとします。次の nisplusLDAPobjectDN を作成してください。


    nisplusLDAPobjectDN	nodeinfo_table:¥
				cn=nodeinfo,ou=nisPlus,dc=some,dc=domain?base?¥
				objectClass=nisplusObjectContainer:¥
				cn=nodeinfo,ou=nisPlus,dc=some,dc=domain?base?¥
					objectClass=nisplusObjectContainer,¥
					objectClass=top

    NIS+ 複製は LDAP にデータを書き込まないため、この nisplusLDAPobjectDN はマスターおよび複製の両方に対して使用できます。

  5. マッピング先の NIS+ オブジェクトがまだ NIS+ に作成されていない場合は、この手順を省略できます。オブジェクトデータを LDAP に格納します。この操作には、rpc.nisd デーモンを使用できます。ただし、 nisldapmaptest(1M) ユーティリティを使用すると、より簡単に行うことができます。この場合、rpc.nisd デーモンを停止する必要はありません。

    # nisldapmaptest -m /var/nis/NIS+LDAPmapping -o -t nodeinfo -r

    -o オプションには、テーブルエントリではなく、テーブルオブジェクト自体を指定します。

  6. オブジェクトデータが LDAP に格納されたことを確認します。この例では、LDAP サーバーがローカルマシンのポート 389 で動作していることを前提としています。

    # ldapsearch -b ou=nisPlus,dc=some,dc=domain cn=nodeinfo

    出力は次のようになります。


    cn=nodeinfo,ou=nisPlus,dc=some,dc=domain
nisplusobject=NOT ASCII
objectclass=nisplusObjectContainer
objectclass=top
cn=nodeinfo

  7. rpc.nisd デーモンを再起動すると、新しいマッピング情報が有効になります。マッピングファイルがデフォルト以外の名前の場合には、必ず -m オプションを指定してください。rpc.nisd デーモンを NIS (YP) サービスに対応させる場合は、 -Y オプションを追加します。

    # pkill rpc.nisd

    # /usr/sbin/rpc.nisd -m mappingfile [-Y]

エントリオブジェクトの追加

NIS+LDAPmapping(4) には、テーブルエントリマッピングの構文および意味論が詳細に指定されています。また、構文要素ごとの使用例も提供されています。ただし、多くの場合、既存のマッピングから目的のマッピングに近いものを選択し、そのマッピングをコピーして変更すれば、最も簡単に行うことができ、エラーも少なくなります。

たとえば、ノードの在庫一覧と所有者情報を格納する nodeinfo という NIS+ テーブルを想定します。NIS+ テーブルは、次のコマンドを使って作成されたとします。

# nistbladm -c -D access=og=rmcd,nw=r -s : nodeinfo_tbl ¥

cname=S inventory=S owner= nodeinfo.`domainname`.

cname 列には、ノードの正式名が格納されます。つまり、ノードの hosts.org_dir テーブルの cname 列と同じ値が格納されます。

また、対応する情報が LDAP の ou=Hosts コンテナに格納され、nodeInfo オブジェクトクラスの必須属性が cn で、オプション属性が nodeInventory と nodeOwner であるとします。nodeInfo オブジェクトクラスは、この例のための仮想クラスで、RFC では定義されていません。

既存の nodeinfo データを LDAP にアップロードするときは、別のファイルに新しいマッピング属性を作成すれば、簡単に行うことができます。たとえば、/var/nis/tmpmapping を使用します。

  1. マッピング先の NIS+ テーブルを識別するデータベース ID を作成します。


    nisplusLDAPdatabaseIdMapping	nodeinfo:nodeinfo

  2. nodeinfoテーブルのエントリに TTL を設定します。この情報はほとんど変更されないため、TTL を 12 時間に設定します。rpc.nisd デーモンがディスクから nodeinfo テーブルを最初に読み込むと、テーブルエントリの TTL が 6 - 12 時間からランダムに選択されます。


    nisplusLDAPentryTtl		nodeinfo:21600:43200:43200

  3. 既存のマッピングから、作成するマッピングに似ているものを選択します。この例では、属性値の割り当ては簡単で、直接割り当てるだけです。ただし、既存のコンテナに LDAP データを格納する処理が複雑です。このため、nodeinfo データの削除は、慎重に行う必要があります。ou=Hosts エントリ全体を削除せずに、nodeInventory および nodeOwner 属性だけを削除します。このため、特別の削除ルールが必要になります。

    つまり、コンテナを共有し削除ルールを持つマッピングを探します。この候補として netmasks マッピングがあります。このマッピングは、ou=Networks コンテナを共有し、削除ルールを持っています。

  4. /var/nis/NIS+LDAPmapping.template の netmasks テンプレートマッピングでは、次のマッピングがデフォルトになっています。


    nisplusLDAPobjectDN	netmasks:ou=Networks,?one?objectClass=ipNetwork,¥
                                        ipNetMaskNumber=*:¥	
                                  ou=Networks,?one?objectClass=ipNetwork:
                                        dbid=netmasks_del

    このテンプレートマッピングを nodeinfo の新しいマッピングにコピーし、データベース ID を nodeinfo、コンテナを ou=Hosts、オブジェクトクラスを nodeInfo に変更します。つまり、nodeinfo マッピングの最初の行は、次のようになります。


    nisplusLDAPobjectDN	nodeinfo:ou=Hosts,?one?objectClass=nodeInfo,¥

    netmasks マッピングの 2 行目は、検索フィルタ部分になっています。ipNetMaskNumber 属性を含む ou=Networks エントリだけを選択します。この例では、次の nodeInventory 属性を持つ ou=Hosts エントリを選択します。


    nodeInventory=*:¥

    3、4 行目は、nisplusLDAPobjectDN の書き込み部分になっています。LDAP nodeinfo データの書き込み先と、nodeinfo データを削除するときのルールが指定されています。ここでは、データベース ID が nodeinfo_del の削除ルールを作成します。ou=Hosts の既存のエントリに常に書き込むため、次のように nodeinfo データ自体のオブジェクトクラスを指定するだけです。


    ou=Hosts,?one?objectClass=nodeInfo:¥
								dbid=nodeinfo_del

    この結果、nisplusLDAPobjectDN は次のようになります。


    nisplusLDAPobjectDN	nodeinfo:ou=Hosts,?one?objectClass=nodeInfo,¥
                                        nodeInventory=*:¥
                                  ou=Hosts,?one?objectClass=nodeInfo:¥
                                        dbid=nodeinfo_del

  5. nodeinfo データを NIS+ から LDAP に対応づけるマッピングルールを作成します。netmasks を使用するテンプレートは、次のようになります。


    nisplusLDAPattributeFromColumn ¥
		netmasks:	dn=("ipNetworkNumber=%s,", addr), ¥
						ipNetworkNumber=addr, ¥
						ipNetmaskNumber=mask, ¥
						description=comment

    ここでは、ou=Hosts コンテナはより複雑な構成になります。RFC 2307 の規定では、dn に IP アドレスを含める必要があるためです。しかし、IP アドレスは nodeinfo テーブルに格納されないため、別の方法で取得する必要があります。テンプレートファイルの crednode マッピングには、IP アドレスの取得方法が記述されています。


    nisplusLDAPattributeFromColumn ¥
		crednode:	dn=("cn=%s+ipHostNumber=%s,", ¥
								(cname, "%s.*"), ¥
			ldap:ipHostNumber:?one?("cn=%s", (cname, "%s.*"))), ¥

    crednodeマッピングの部分をコピーできます。ただし、ここでは、cname 列値は主体名ではなく実際のホスト名です。cname の一部を抽出する必要はありません。属性および列名を完全な名前の代入に変更します。nodeinfo マッピングは次のようになります。


    nisplusLDAPattributeFromColumn ¥
		nodeinfo:	dn=("cn=%s+ipHostNumber=%s,", cname, ¥
			ldap:ipHostNumber:?one?("cn=%s", cname)), ¥
				nodeInventory=inventory, ¥
				nodeOwner=owner

  6. LDAP のデータを NIS+ にマッピングするときは、 netmasks エントリのテンプレートは次のようになります。


    nisplusLDAPcolumnFromAttribute ¥
		netmasks:	addr=ipNetworkNumber, ¥
				mask=ipNetmaskNumber, ¥
				comment=description

    属性および列名を代入すると、次のようになります。


    nisplusLDAPcolumnFromAttribute ¥
		nodeinfo:	cname=cn, ¥
				inventory=nodeInventory, ¥
				owner=nodeOwner

  7. netmasks の削除ルールは、次のようになっています。


    nisplusLDAPattributeFromColumn ¥
		netmasks_del:	dn=("ipNetworkNumber=%s,", addr), ¥
				ipNetmaskNumber=

    この例では、NIS+ の netmasks エントリが削除されると、対応する ou=Networks LDAP エントリの ipNetmaskNumber 属性が削除されます。ここでは、 nodeInventory および nodeOwner 属性を削除します。つまり、手順 (5) の dn 指定を使用して、次のように編集します。


    nisplusLDAPattributeFromColumn ¥
		nodeinfo_del:	dn=("cn=%s+ipHostNumber=%s,", cname, ¥
			ldap:ipHostNumber:?one?("cn=%s", cname)), ¥
				nodeInventory=, ¥
				nodeOwner=

  8. マッピング情報はこれで完了です。このマッピングを有効にするために、rpc.nisd デーモンを停止してから、再起動します。

    # pkill rpc.nisd

  9. NIS+ nodeinfo テーブルにすでにデータが存在する場合は、そのデータを LDAP にアップロードします。新しい nodeinfo マッピング情報を、別のファイル /var/nis/tmpmapping に格納します。

    # /usr/sbin/rpc.nisd -D -m /var/nis/tmpmapping ¥

    -x nisplusLDAPinitialUpdateAction=to_ldap ¥

    -x nisplusLDAPinitialUpdateOnly=yes

  10. 一時ファイル /var/nis/tmpmapping のマッピング情報を実際のマッピングファイルに追加します。エディタを使用するか、次の方法でデータを追加します。対象のマッピングファイルは、 /var/nis/NIS+LDAPmapping とします。

    # cp -p /var/nis/NIS+LDAPmapping ¥

    /var/nis/NIS+LDAPmapping.backup

    # cat /var/nis/tmpmapping>> /var/nis/NIS+LDAPmapping

    注 -

    二重矢印 「>>」はリダイレクトを示します。矢印「>」は、対象ファイルの上書きを示します。

  11. rpc.nisd デーモンを再起動します。 rpc.nisd デーモンが次のように NIS(YP) データも提供する場合は、-Y オプションを追加します。

    # /usr/sbin/rpc.nisd -m /var/nis/NIS+LDAPmapping

構成情報を LDAP に格納する

NIS+ および LDAP の構成情報は、構成ファイルとコマンド行で格納できますが、構成属性は LDAP にも格納できます。構成情報が多くの NIS+ サーバーによって共有され、定期的に変更される場合は、LDAP に格納すると便利です。

構成属性を LDAP に格納するには、LDAP サーバーのマニュアルを参照して、次の新しい属性とオブジェクトクラスを作成します。構成情報は、 rpc.nisd コマンド行または /etc/default/rpc.nisd の nisplusLDAPconfigDN 値に指定された場所に存在することが前提となっています。また、cn が nisplusLDAPbaseDomain 値であることも前提です (LDAP から構成情報を読み込む前に、rpc.nisd デーモンに認識されているため)。

LDIF データは、ldapadd(1) に適用できます。属性とオブジェクトクラス OID は、例として挙げています。

defaultSearchBase、preferredServerList 、およびauthenticationMethod 属性は、「DUA config」スキーマの原案に準拠しています。このスキーマは、IETF 標準となる見込みです。NIS+LDAPmapping(4) で使用する場合は、次の定義で十分です。


dn: cn=schema
changetype: modify
add: attributetypes
attributetypes:	( 1.3.6.1.4.1.11.1.3.1.1.1 NAME 'defaultSearchBase' ¥
		  DESC 'Default LDAP base DN used by a DUA' ¥
		  EQUALITY distinguishedNameMatch ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.11.1.3.1.1.2 NAME 'preferredServerList' ¥
		  DESC 'Preferred LDAP server host addresses to be used by a DUA' ¥
		  EQUALITY caseIgnoreMatch ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.11.1.3.1.1.6 NAME 'authenticationMethod' ¥
		  DESC 'Identifies the authentication method used to connect to the DSA'¥
		  EQUALITY caseIgnoreMatch ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )

NIS+ および LDAP の構成属性は、次のようになっています。


dn: cn=schema
changetype: modify
add: attributetypes
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.0 ¥
		  NAME 'nisplusLDAPTLS' ¥
		  DESC 'Transport Layer Security' ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.1 ¥
		  NAME 'nisplusLDAPTLSCertificateDBPath' ¥
		  DESC 'Certificate file' ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.2 ¥
		  NAME 'nisplusLDAPproxyUser' ¥
		  DESC 'Proxy user for data store/retrieval' ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.3 ¥
		  NAME 'nisplusLDAPproxyPassword' ¥
		  DESC 'Password/key/shared secret for proxy user' ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.4 ¥
		  NAME 'nisplusLDAPinitialUpdateAction' ¥
		  DESC 'Type of initial update' ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.5 ¥
		  NAME 'nisplusLDAPinitialUpdateOnly' ¥
		  DESC 'Exit after update ?' ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.6 ¥
		  NAME 'nisplusLDAPretrieveErrorAction' ¥
		  DESC 'Action following an LDAP search error' ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.7 ¥
		  NAME 'nisplusLDAPretrieveErrorAttempts' ¥
		  DESC 'Number of times to retry an LDAP search' ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.8 ¥
		  NAME 'nisplusLDAPretrieveErrorTimeout' ¥
		  DESC 'Timeout between each search attempt' ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.9 ¥
		  NAME 'nisplusLDAPstoreErrorAction' ¥
		  DESC 'Action following an LDAP store error' ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.10 ¥
		  NAME 'nisplusLDAPstoreErrorAttempts' ¥
		  DESC 'Number of times to retry an LDAP store' ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.11 ¥
		  NAME 'nisplusLDAPstoreErrorTimeout' ¥
		  DESC 'Timeout between each store attempt' ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.12 ¥
		  NAME 'nisplusLDAPrefreshErrorAction' ¥
		  DESC 'Action when refresh of NIS+ data from LDAP fails' ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.13 ¥
		  NAME 'nisplusLDAPrefreshErrorAttempts' ¥
		  DESC 'Number of times to retry an LDAP refresh' ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.14 ¥
		  NAME 'nisplusLDAPrefreshErrorTimeout' ¥
		  DESC 'Timeout between each refresh attempt' ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.15 ¥
		  NAME 'nisplusNumberOfServiceThreads' ¥
		  DESC 'Max number of RPC service threads' ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.16 ¥
		  NAME 'nisplusThreadCreationErrorAction' ¥
		  DESC 'Action when a non-RPC-service thread creation fails' ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.17 ¥
		  NAME 'nisplusThreadCreationErrorAttempts' ¥
		  DESC 'Number of times to retry thread creation' ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.18 ¥
		  NAME 'nisplusThreadCreationErrorTimeout' ¥
		  DESC 'Timeout between each thread creation attempt' ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.19 ¥
		  NAME 'nisplusDumpErrorAction' ¥
		  DESC 'Action when an NIS+ dump fails' ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.20 ¥
		  NAME 'nisplusDumpErrorAttempts' ¥
		  DESC 'Number of times to retry a failed dump' ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.21 ¥
		  NAME 'nisplusDumpErrorTimeout' ¥
		  DESC 'Timeout between each dump attempt' ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.22 ¥
		  NAME 'nisplusResyncService' ¥
		  DESC 'Service provided during a resync' ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.23 ¥
		  NAME 'nisplusUpdateBatching' ¥
		  DESC 'Method for batching updates on master' ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.24 ¥
		  NAME 'nisplusUpdateBatchingTimeout' ¥
		  DESC 'Minimum time to wait before pinging replicas' ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.25 ¥
		  NAME 'nisplusLDAPmatchFetchAction' ¥
		  DESC 'Should pre-fetch be done ?' ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.26 ¥
		  NAME 'nisplusLDAPbaseDomain' ¥
		  DESC 'Default domain name used in NIS+/LDAP mapping' ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.27 ¥
		  NAME 'nisplusLDAPdatabaseIdMapping' ¥
		  DESC 'Defines a database id for an NIS+ object' ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.28 ¥
		  NAME 'nisplusLDAPentryTtl' ¥
		  DESC 'TTL for cached objects derived from LDAP' ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.29 ¥
		  NAME 'nisplusLDAPobjectDN' ¥
		  DESC 'Location in LDAP tree where NIS+ data is stored' ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.30 ¥
		  NAME 'nisplusLDAPcolumnFromAttribute' ¥
		  DESC 'Rules for mapping LDAP attributes to NIS+ columns' ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetypes:	( 1.3.6.1.4.1.42.2.27.5.42.42.18.31 ¥
		  NAME 'nisplusLDAPattributeFromColumn' ¥
		  DESC 'Rules for mapping NIS+ columns to LDAP attributes' ¥
		  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

dn: cn=schema
changetype: modify
add: objectclasses
objectclasses:	( 1.3.6.1.4.1.42.2.27.5.42.42.19.0 NAME 'nisplusLDAPconfig' ¥
		  DESC 'NIS+/LDAP mapping configuration' ¥
		  SUP top STRUCTURAL MUST ( cn ) ¥
		  MAY ( preferredServerList $ defaultSearchBase $ 
authenticationMethod $ nisplusLDAPTLS $ nisplusLDAPTLSCertificateDBPath 
$ nisplusLDAPproxyUser $ nisplusLDAPproxyPassword $ nisplusLDAPinitialUpdateAction 
$ nisplusLDAPinitialUpdateOnly $ nisplusLDAPretrieveErrorAction 
$ nisplusLDAPretrieveErrorAttempts $ nisplusLDAPretrieveErrorTimeout 
$ nisplusLDAPstoreErrorAction $ nisplusLDAPstoreErrorAttempts 
$ nisplusLDAPstoreErrorTimeout $ nisplusLDAPrefreshErrorAction 
$ nisplusLDAPrefreshErrorAttempts $ nisplusLDAPrefreshErrorTimeout 
$ nisplusNumberOfServiceThreads $nisplusThreadCreationErrorAction 
$ nisplusThreadCreationErrorAttempts $ nisplusThreadCreationErrorTimeout 
$ nisplusDumpErrorAction $ nisplusDumpErrorAttempts 
$ nisplusDumpErrorTimeout $ nisplusResyncService $ nisplusUpdateBatching 
$ nisplusUpdateBatchingTimeout $ nisplusLDAPmatchFetchAction 
$ nisplusLDAPbaseDomain $ nisplusLDAPdatabaseIdMapping $ nisplusLDAPentryTtl 
$ nisplusLDAPobjectDN $ nisplusLDAPcolumnFromAttribute !
$ nisplusLDAPattributeFromColumn ) )

次の LDIF データを含むファイルを作成します。実際の検索ベースを searchBase に、完全指定ドメイン名を domain に代入します。

dn: cn=domain,searchBase

cn:domain

objectClass: top objectClass: nisplusLDAPconfig

上のファイルを ldapadd(1) の入力として使用し、NIS+ および LDAP の構成エントリを作成します。最初は、エントリは空になっています。ldapmodify(1) を使用して、構成属性を追加します。たとえば、nisplusNumberOfServiceThreads 属性に「32」を設定するには、ldapmodify(1) の入力として次のファイルを作成します。

dn: cn=domain, searchBase nisplusNumberOfServiceThreads: 32