デフォルトの NIS+LDAPmapping ファイルは、NIS+ および LDAP マッピングのマスタースイッチとして機能します。
デフォルト以外のマッピングファイルを使用する場合、-m mappingfile オプションを使用して /lib/svc/method/nisplus スクリプトを編集し、rpc.nisd 行にマッピングファイル名を指定する必要があります。詳細については、「NIS+ から LDAP への移行用ツールとサービス管理機能」を参照してください。
LDAP に対応づける NIS+ オブジェクトごとに、NIS+LDAPmapping ファイルに 2 から 5 個の属性を指定します。指定する属性値は、オブジェクトとデフォルト値によって異なります。
エイリアスは、オブジェクトがほかのマッピング属性で使用されるときに設定する必要があります。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 をそのテーブルのエントリに使用することを定義します。
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 には、対応づけられた 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 には、NIS+ データを LDAP に対応づけるときのルールを指定します。LDAP から NIS+ データへのマッピングルールは、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) で次のように表示されます。
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 エントリが削除されたときに、SolarisUserQualifier、SolarisAttrReserved1、SolarisAttrReserved2、および SolarisAttrKeyValue 属性が存在する場合、次のルールに指定されている ou=People エントリから削除されます。
dn=("uid=%s,", name) |
これ以外の LDAP エントリは変更されません。