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

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

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

NIS+ から LDAP への移行の概要

NIS+ サーバーデーモン rpc.nisd は、/var/nis/data ディレクトリにある独自フォーマットのファイルに NIS+ データを保存します。NIS+ データは、LDAP と同期化することができます。従来は、そのために外部エージェントが必要でした。しかし、新しい NIS+ デーモンでは、LDAP サーバーを NIS+ データのデータリポジトリとして使用できるようになりました。これにより、NIS+ および LDAP クライアントが同一のネームサービス情報を共有できるため、メインネームサービスを 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 および timezone テーブル (NIS+ から LDAP への移行)」 timezone.org_dir については、client_info and timezone Tables (NIS+ to LDAP)を参照)。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) のマニュアルページを参照してください。マッピングファイルの名前を変更するときは、/lib/svc/method/nisplus ファイルを編集します。詳細については、「NIS+ から LDAP への移行用ツールとサービス管理機能」を参照してください。

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

rpc.nisd 構成ファイル

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

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

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

  2. 構成ファイル

  3. LDAP

NIS+ から LDAP への移行用ツールとサービス管理機能

NIS+ から LDAP への移行に関連するコマンド行管理タスクの大部分は、サービス管理機能によって管理されます。SMF の概要については、『Solaris のシステム管理 (基本編)』の第 18 章「サービスの管理 (概要)」を参照してください。また、詳細については、svcadm(1M) および svcs(1) のマニュアルページを参照してください。

NIS+ から LDAP への移行で SMF を使用しない場合

通常、/usr/sbin/rpc.nisd デーモンは、svcadm コマンドを使用して管理します。ただし、rpc.nisd デーモンは、-x nisplusLDAPinitialUpdateOnly=yes を指定して起動すると、指定された初期更新アクションを実行して終了します。つまり、rpc.nisd はデーモン化されません。-x nisplusLDAPinitialUpdateOnly=yes を指定した上で、サービス管理機能を使用してはなりません。それ以外の場合で、rpc.nisd デーモンを起動、停止または再起動するときにはいつでも SMF を使用できます。

次の例は、-x nisplusLDAPinitialUpdateOnly=yes を指定した rpc.nisd です。


# /usr/sbin/rpc.nisd -m mappingfile \
-x nisplusLDAPinitialUpdateAction=from_ldap \
-x nisplusLDAPinitialUpdateOnly=yes

/lib/svc/method/nisplus ファイルの変更

rpc.nisd デーモンをサービス管理機能によって起動するときに特定のオプションを含める場合、svcprop コマンドを使用するか、/lib/svc/method/nisplus ファイルを変更できます。svcprop コマンドの使用方法の詳細については、svcprop(1) のマニュアルページを参照してください。/lib/svc/method/nisplus ファイルを変更する手順を次に示します。

Procedure/lib/svc/method/nisplus ファイルの変更方法

  1. スーパーユーザーになるか、同等の役割を引き受けます。

    役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の第 9 章「役割によるアクセス制御の使用 (手順)」を参照してください。

  2. NIS+ サービスを停止します。


    # svcadm disable network/rpc/nisplus:default
    
  3. /lib/svc/method/nisplus ファイルを開きます。

    任意のエディタを使用してください。

  4. ファイルを編集して必要なオプションを追加します。

    変更前:


    if [ -d /var/nis/data -o -d /var/nis/$hostname ]; then
                        /usr/sbin/rpc.nisd || exit $

    変更後:


    if [ -d /var/nis/data -o -d /var/nis/$hostname ]; then
                         /usr/sbin/rpc.nisd -Y -B || exit $?

    この例では、-Y および -B オプションが rpc.nisd に追加され、起動時に自動的に実装されます。

  5. /lib/svc/method/nisplus ファイルを保存して終了します。

  6. NIS+ サービスを開始します。


    # svcadm enable network/rpc/nisplus:default
    

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

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


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

この方法は、Sun Java System Directory Server で機能します。また、その他の LDAP サーバーでも機能することがあります。


注 –

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


NIS+ から LDAP への移行の開始前に必要な処置

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 bindmodifyadd、および delete 操作) でタイムアウトを設定します。これらの属性は通常、デフォルトのままにしておきます。

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

エラー処理

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

一般的な LDAP 処理の制御

/var/nis/NIS+LDAPmapping ファイル

デフォルトの NIS+LDAPmapping ファイルは、NIS+ および LDAP マッピングのマスタースイッチとして機能します。

デフォルト以外のマッピングファイルを使用する場合、-m mappingfile オプションを使用して /lib/svc/method/nisplus スクリプトを編集し、rpc.nisd 行にマッピングファイル名を指定する必要があります。詳細については、「NIS+ から LDAP への移行用ツールとサービス管理機能」を参照してください。

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_tablerpc を、rpc.org_dir テーブルのエイリアスとして定義します。次に、rpc_tablerpc.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 秒に設定されます。

同様に、次の場合は、テーブルオブジェクトが最初に読み込まれたときに、1800 - 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 データが、これらのエントリにだけ含まれるためです。nisplusLDAPobjectDNdbid=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 テーブルには、cnamenamenumbe、および comment という列が含まれます。たとえば、NIS+ RPC プログラム番号 (100300) に対して、正規名として nisd が指定され、エイリアスとして rpc.nisdnisplusd が指定されているとします。このエントリは、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) で次のように表示されます。


dn: cn=nisd,ou=Ppc,dc=some,dc=domain
cn: nisd
cn: rpc.nsid
cn: nisplusd
oncRpcNumber: 100300
description: NIS+ server
objectClass: oncRpc

この例は、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 エントリが削除されたときに、SolarisUserQualifierSolarisAttrReserved1SolarisAttrReserved2、および SolarisAttrKeyValue 属性が存在する場合、次のルールに指定されている ou=People エントリから削除されます。


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

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

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

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

Procedureすべての 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 属性を参照してください。

Procedureすべての 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 データを同期化する方法について説明しています。データをマージするときは、ほかの方法と比べて複雑な手順が必要になります。

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

ProcedureNIS+ データと 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. LDAP データを NIS+ にダウンロードします。


    # /usr/sbin/rpc.nisd -D -m tmpmap \
    -x nisplusLDAPinitialUpdateAction=from_ldap \
    -x nisplusLDAPinitialUpdateOnly=yes
    
  4. NIS+ サービスを開始します。


    # svcadm enable network/rpc/nisplus:default
    

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

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

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


    # nisaddent -d group | sort > /after/group
    
  6. マージしたテーブルを作成します。

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

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

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


    # nisaddent -m -f /after/group group
    
  8. マージ後のテーブルから、不要な 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 つ以上含まれるコンテナごとに、前述の手順を繰り返します。

マスターと複製 (NIS+ から LDAP への移行)

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

複製タイムスタンプ

NIS+ 複製が特定の NIS+ ディレクトリに含まれる 1 つ以上のオブジェクトのデータを LDAP から取得しているときは、nisping(1M) によって出力される更新タイムスタンプが NIS+ マスターおよび NIS+ 複製間のデータの整合性を示しているとは限りません。たとえば、NIS+ ディレクトリ dir1table1 および 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 からデータを取得するように構成した場合は、複製を変更する必要はありません。

ディレクトリサーバー (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 との間でアカウント情報を完全に共有することはできません。

Sun Java System Directory Server の構成

Sun Java System Directory Server のインストール、設定、および管理の詳細については、Sun Java System Directory Server collection を参照してください。

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


注 –

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


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

/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 と別の認証方式 (simplesasl/digest-md5) を組み合わせることができます。

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

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 に格納するには、次の操作を実行する必要があります。

Procedureエントリ属性を 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_ownerzo_groupzo_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. 所有者、グループ、アクセス権、および TTL エントリデータのどれか、またはすべてを LDAP にアップロードします。

    詳細については、「すべての NIS+ データを 1 回の操作で LDAP に変換する方法」を参照してください。

  5. マッピングの変更を有効にするために、NIS+ サービスを再起動します。


    # svcadm restart network/rpc/nisplus:default
    

主体名とネット名 (NIS+ から 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 テーブル (NIS+ から LDAP への移行)

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 デーモンを再起動します。


# svcadm restart network/rpc/nisplus:default

必要に応じて、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 デーモンを再起動します。


# svcadm restart network/rpc/nisplus:default

必要に応じて、NIS+ データと LDAP データを同期化します。方法については、「NIS+ から LDAP への移行シナリオ」を参照してください。

新しいオブジェクトマッピングの追加 (NIS+ から LDAP への移行)

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

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

  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
    

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


    dn: cn=nodeinfo,ou=nisPlus,dc=some,dc=domain
    objectclass: nisplusObjectContainer
    objectclass: top
    cn: nodeinfo
    nisplusobject=<base 64 encoded data>

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

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 オブジェクトクラス (この例のための仮想クラスで、RFC では定義されていません) の MUST 属性が cn で、MAY 属性が nodeInventorynodeOwner であるとします。

既存の 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.templatenetmasks テンプレートマッピングでは、次のマッピングがデフォルトになっています。


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


    # /usr/sbin/rpc.nisd -D -m /var/nis/tmpmapping \
    -x nisplusLDAPinitialUpdateAction=to_ldap \
    -x nisplusLDAPinitialUpdateOnly=yes
    
  9. 一時ファイル /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
    

    注意 – 注意 –

    リダイレクトに二重矢印「>>」を使っている点に注意してください。矢印「>」を使った場合は対象ファイルを上書きします。


構成情報を LDAP に格納する

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

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

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

defaultSearchBasepreferredServerList、および 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 $ nisplusLDAPTLSCertificateDBPate
$ 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