test

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

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

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 にリダイレクトします。

    # ldapsearch -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+ データの提供を開始します。