test

Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、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 秒に設定されます。

同様に、次の場合は、テーブルオブジェクトが最初に読み込まれたときに、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 データが、これらのエントリにだけ含まれるためです。 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 とすると、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 エントリは変更されません。