この章では、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 への移行用ツールとサービス管理機能」を参照してください。
この章では、次の用語を使用します。
コンテナ
すべての関連エントリが格納される LDAP DIT 内の場所。たとえば、ユーザーアカウント情報は、多くの場合、ou=People コンテナに格納される。また、ホストアドレス情報は、 ou=Hosts コンテナに格納される
ネット名
認証可能な SecureRPC 内のエンティティー (ユーザーまたはマシン)
マッピング
NIS+ オブジェクトと LDAP エントリとの関係。たとえば、passwd.org_dir NIS+ テーブルの name 列のデータ (アカウントのユーザー名など) が、ou=People コンテナ内の posixAccount オブジェクトクラスの LDAP uid 属性に対応しているとする。構成によって、name 列と uid 属性が対応づけられる。name 列が uid 属性に対応づけられる (またはその逆) とも表現できる
主体
認証可能な NIS+ のエンティティー (ユーザーまたはマシン) 。通常、ネット名と主体名は 1 対 1 で対応づけられる
2 つの構成ファイルを使用して、rpc.nisd 処理を制御します。
/etc/default/rpc.nisd
LDAP サーバーと認証、NIS+ ベースドメイン、LDAP デフォルト検索ベース、例外処理、および rpc.nisd の一般的な構成に関する情報を含みます。このファイルは、LDAP マッピングが有効であるかどうかにかかわらず適用されます。
/var/nis/NIS+LDAPmapping
NIS+ データと LDAP との間のマッピング情報を含みます。テンプレートファイル (/var/nis/NIS+LDAPmapping.template) は、client_info.org_dir と timezone.org_dir 以外のすべての標準 NIS+ オブジェクトに対応しています。「client_info および timezone テーブル (NIS+ から LDAP への移行)」および NIS+LDAPmapping(4) のマニュアルページを参照してください。
構成とは、値を定義済みの属性に割り当てることです。構成ファイル以外に、構成属性を LDAP から読み取ることもできます (「構成情報を LDAP に格納する」を参照)。また、rpc.nisd コマンドの -x オプションに構成属性を指定することもできます。複数の場所で同じ属性が指定されている場合、優先順位 (高から低) は次のとおりです。
rpc.nisd -x オプション
構成ファイル
LDAP
NIS+ から LDAP への移行に関連するコマンド行管理タスクの大部分は、サービス管理機能によって管理されます。SMF の概要については、『Solaris のシステム管理 (基本編)』の第 18 章「サービスの管理 (概要)」を参照してください。また、詳細については、svcadm(1M) および svcs(1) のマニュアルページを参照してください。
NIS+ から LDAP への移行サービスに関する有効化、無効化、再起動などの管理アクションは svcadm コマンドを使用して実行できる
-t オプションを使用してサービスを一時的に無効化すると、そのサービス構成に対していくらかの保護を提供できます。-t オプションを指定してサービスを無効にした場合、リブート後に元の設定が復元されます。-t オプションを指定しないでサービスを無効にした場合、リブート後もそのサービスは無効のままです。
NIS+ の障害管理リソース識別子 (FMRI) は、svc:/network/rpc/nisplus: <instance> です。LDAP クライアントサービスの FMRI は、svc:/network/ldap/client: <instance> です。
svcs コマンドを使用して NIS+ の状態を照会できる。
svcs コマンドと出力の例を、次に示します。
# svcs \*nisplus\* STATE STIME FMRI online Sep_01 svc:/network/rpc/nisplus:default |
svcs -l コマンドと出力の例を、次に示します。次に示す出力を得るには、FMRI でインスタンス名を使用する必要があります。
# svcs -l network/rpc/nisplus:default fmri svc:/network/rpc/nisplus:default enabled false state disabled next_state none restarter svc:/system/svc/restarter:default dependency require_all/none svc:/network/rpc/keyserv (online) |
デーモンの存在は ps コマンドを使用して確認できます。
# ps -e | grep rpc.nisd root 23320 1 0 Aug 27 ? 16:30 ./ns-slapd -D \ /usr/iplanet/ds5/slapd-lastrev -i /usr/iplanet/ds5/slapd-lastrev/ root 25367 25353 0 15:35:19 pts/1 0:00 grep slapd |
-f オプションを ps で使用しないでください。このオプションはユーザー ID を名前に変換しようとするため、より多くのネームサービス検索が失敗する可能性があります。
通常、/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 |
rpc.nisd デーモンをサービス管理機能によって起動するときに特定のオプションを含める場合、svcprop コマンドを使用するか、/lib/svc/method/nisplus ファイルを変更できます。svcprop コマンドの使用方法の詳細については、svcprop(1) のマニュアルページを参照してください。/lib/svc/method/nisplus ファイルを変更する手順を次に示します。
スーパーユーザーになるか、同等の役割を引き受けます。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の第 9 章「役割によるアクセス制御の使用 (手順)」を参照してください。
NIS+ サービスを停止します。
# svcadm disable network/rpc/nisplus:default |
/lib/svc/method/nisplus ファイルを開きます。
任意のエディタを使用してください。
ファイルを編集して必要なオプションを追加します。
変更前:
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 に追加され、起動時に自動的に実装されます。
/lib/svc/method/nisplus ファイルを保存して終了します。
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 サーバーでも機能することがあります。
ただし、defaultSearchBase、preferredServerList、および authenticationMethod 属性を除き、この章で使用されているオブジェクト識別子 (OID) は、SYNTAX 仕様と同様に、説明用に挙げているだけです。OID の基準はありません。任意の OID を使用できます。
NIS+ データを LDAP リポジトリに格納するために必要な構成の概要については、NIS+LDAPmapping(4) のマニュアルページを参照してください。ここでは、構成ファイルの編成について詳細に説明します。
/etc/default/rpc.nisd ファイルに値を割り当てるときは、すべて attributeName=value タイプとします。
次の属性は、rpc.nisd の一般的な構成を制御し、LDAP マッピングが有効かどうかにかかわらずアクティブになります。これらの属性は通常、デフォルトのままにしておきます。詳細については、rpc.nisd(4) のマニュアルページを参照してください。
nisplusNumberOfServiceThreads
nisplusThreadCreationErrorAction
nisplusThreadCreationErrorAttempts
nisplusThreadCreationErrorTimeout
nisplusDumpErrorAction
nisplusDumpErrorAttempts
nisplusDumpErrorTimeout
nisplusResyncService
nisplusUpdateBatching
nisplusUpdateBatchingTimeout
次の属性は、LDAP からのその他の構成属性の読み込みを制御します。これらの属性自体を LDAP に常駐させることはできません。コマンド行または構成ファイルから読み込む必要があります。詳細については、rpc.nisd(4) のマニュアルページを参照してください。
nisplusLDAPconfigDN
nisplusLDAPconfigPreferredServerList
nisplusLDAPconfigAuthenticationMethod
nisplusLDAPconfigTLS
nisplusLDAPconfigTLSCertificateDBPath
nisplusLDAPconfigProxyUser
nisplusLDAPconfigProxyPassword
preferredServerList
LDAP サーバーとポート番号を指定します。
# LDAP server can be found at port 389 # LDAP server can be found at port 389 on the local machine # preferredServerList=127.0.0.1 # Could also be written # preferredServerList=127.0.0.0.1:389 LDAP server on the machine at IP # address "1.2.3.4", at port 65042 # preferredServerList=1.2.3.4:65042 |
authenticationMethod
nisplusLDAPproxyUser
nisplusLDAPproxyPassword
認証方式と、その方式に適切なプロキシユーザー (バインド識別名 DN) とパスワード (鍵またはその他の共有された機密情報)。これらは、rpc.nisd デーモンと LDAP サーバーの間で使用されます。詳細については、「セキュリティーと認証」を参照してください。
nisplusLDAPTLS
nisplusLDAPTLSCertificateDBPath
必要に応じて、SSL を使用し、証明書ファイルの場所を指定します。詳細については、「SSL の使用」を参照してください。
defaultSearchBase
LDAP DIT 内で、RFC 2307 に準拠したネームサービスデータのコンテナが配置される場所。コンテナ DN の完全な検索ベースを個別に指定しなかった場合は、この場所がデフォルトで使用されます。詳細については、「nisplusLDAPobjectDN 属性」を参照してください。
nisplusLDAPbaseDomain
NIS+ オブジェクト仕様 (「nisplusLDAPdatabaseIdMapping 属性」を参照) を完全指定しなかった場合は、このデフォルト NIS+ ドメイン名が使用されます。
nisplusLDAPbindTimeout
nisplusLDAPmodifyTimeout
nisplusLDAPaddTimeout
nisplusLDAPdeleteTimeout
上のパラメータ (順番に、ldap bind、modify、add、および delete 操作) でタイムアウトを設定します。これらの属性は通常、デフォルトのままにしておきます。
nisplusLDAPsearchTimeout
nisplusLDAPsearchTimeLimit
上のパラメータには、LDAP 検索処理のタイムアウトを設定します。下のパラメータでは、サーバー側の検索時間制限を要求します。nisplusLDAPsearchTimeLimit では、LDAP サーバーが検索要求に使用する時間を制御します。このため、nisplusLDAPsearchTimeLimit には nisplusLDAPsearchTimeout 以上の値を設定してください。NIS+ サーバー、LDAP サーバー、および 2 つのサーバー間の接続のパフォーマンスに応じて、検索制限をデフォルト値より大きくしなければならないことがあります。rpc.nisd から送信されたタイムアウトに関するシステムログメッセージを基にして、これらの値を大きくするかどうかを判断します。
nisplusLDAPsearchSizeLimit
このパラメータでは、LDAP 検索要求に対して返される LDAP データ量に対する制限を要求します。デフォルトでは、制限は要求しません。この制限は、サーバー側に適用されます。LDAP サーバーでは、最大データ量に対して制限を適用することがあります。データ量の制限は、使用されているプロキシユーザー (バインド DN) に関連づけられることがあります。最も大きいコンテナに対して十分なデータが送信されるように、LDAP サーバーで rpc.nisd を設定してください。サイトによりますが、多くの場合、passwd.org_dir、mail_aliases.org_dir、または netgroup.org_dir のコンテナが使用されます。詳細については、LDAP サーバーのマニュアルを参照してください。
nisplusLDAPfollowReferral
このパラメータには、LDAP の処理中に別の LDAP サーバーへの参照が発生したときに、実行する処理を指定します。デフォルトでは、参照は行いません。参照を希望するか必要な場合は、参照を有効にします。参照は便利ですが、参照要求が発生するたびに rpc.nisd と複数の LDAP サーバーが対話する必要があるため、処理速度が遅くなることがあります。rpc.nisd には通常、発行する可能性のあるすべての LDAP 要求を処理できる LDAP サーバーを直接指定してください。
次のパラメータには、LDAP 処理中にエラーが発生したときに、実行する処理を指定します。これらのパラメータは通常、デフォルトのままにしておきます。詳細については、rpc.nisd(4) のマニュアルページを参照してください。
nisplusLDAPinitialUpdateAction
nisplusLDAPinitialUpdateOnly
nisplusLDAPretrieveErrorAction
nisplusLDAPretrieveErrorAttempts
nisplusLDAPretrieveErrorTimeout
nisplusLDAPstoreErrorAction
nisplusLDAPstoreErrorAttempts
nisplusLDAPstoreErrorTimeout
nisplusLDAPrefreshErrorAction
nisplusLDAPrefreshErrorAttempts
nisplusLDAPrefreshErrorTimeout
nisplusLDAPmatchFetchAction
このパラメータでは、NIS+ 照合処理のために、LDAP データを事前に取得するかどうかを決定します。ほとんどの場合、この値はデフォルトのままにしておきます。詳細については、rpc.nisd(4) のマニュアルページを参照してください。
デフォルトの 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 エントリは変更されません。
NIS+ から LDAP への移行シナリオの例を挙げます。
すべての NIS+ クライアントを 1 回の操作で LDAP に変換する場合。rpc.nisd デーモンを使用すれば、LDAP に存在しないすべての NIS+ データをアップロードできます。「すべての NIS+ データを 1 回の操作で LDAP に変換する方法」を参照してください。
NIS+ から LDAP に段階的に移行する場合。まず、NIS+ データを LDAP に変換します (「すべての NIS+ データを 1 回の操作で LDAP に変換する方法」を参照)。NIS+ クライアントと LDAP クライアントで、同じネームサービスを共有することができます。NIS+ および LDAP のデータは、rpc.nisd によって自動的に同期化されます。移行の初期段階では場合によって、NIS+ が認証されたサーバーとして機能し、LDAP サーバーは、NIS+ データを複製して、LDAP クライアントに提供します。適切な段階で、LDAP を認証されたネームサービスに移行します。NIS+ サービスは、段階的に処理を停止していき、NIS+ クライアントの移行が完了した時点で完全になくなります。
LDAP がすでにネームサービスとして使用されている場合。NIS+ データと LDAP データをマージする必要があります。次の 3 つのマージ方法があります。
NIS+ データを LDAP に追加する方法。NIS+ に存在するが LDAP に存在しないエントリが、LDAP に追加されます。エントリが NIS+ および LDAP の両方に存在するが、データが異なる場合は、NIS+ データが優先されます。「すべての NIS+ データを 1 回の操作で LDAP に変換する方法」を参照してください。
NIS+ データを LDAP データで上書きする方法。NIS+ に存在するが LDAP に存在しないエントリが、NIS+ から削除されます。NIS+ および LDAP の両方に存在するエントリでは、 LDAP データが優先されます。「すべての LDAP データを 1 回の操作で NIS+ に変換する方法」を参照してください。
NIS+ データと LDAP データをマージする方法。衝突が発生した場合は、個別に解決します。「NIS+ データと LDAP データのマージ」を参照してください。
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 属性を参照してください。
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+ データのバックアップを /nisbackup ディレクトリに作成する
有効なマッピング構成が /etc/default/rpc.nisd および /var/nis/tmpmap (テーブルをマージする場合) にすでに存在する
マージ前の NIS+ データのフラットファイル表現を /before に格納し、マージ後は /after に格納する
niscat は、nisaddent(1M) でサポートされないカスタム NIS+ テーブルを、フラットファイル表現でダンプするときに使用する。このようなカスタムテーブルを、NIS+ からまたは NIS+ にダンプして読み込むために、独自のコマンドまたはスクリプトを作成することがある。この場合は、niscat に優先して、独自のコマンドまたはスクリプトを使用する。niscat コマンドには、フラットファイル表現のデータを NIS+ に戻す便利な方法がないためである
niscat(1) を使用してデータをダンプした場合は、nistbladm(1) を使用すれば、エントリを 1 つずつ NIS+ に戻すことができる
コマンドパスに /usr/lib/nis (nisaddent(1M) が存在する場所) を含める
手順 4 のダウンロードデータと、手順 10 のアップロードデータが一致しない場合は、アップロードデータによって変更が上書きされます。このため、この手順を実行しているときは、LDAP データの変更はできるだけ避けてください。詳細については、LDAP サーバーのマニュアルを参照してください。
nisbackup コマンドを使用して、すべての NIS+ データをバックアップします。
# nisbackup -a /nisbackup |
LDAP とマージするデータが含まれる NIS+ テーブルを特定します。これらのテーブルの内容をフラットファイルにダンプします。たとえば、次のように nisaddent を使用して group.org_dir の内容をダンプします。
# nisaddent -d group | sort > /before/group |
パイプを使って nisaddent の出力を sort の入力として渡すと、比較処理が簡単になります。
LDAP データを NIS+ にダウンロードします。
# /usr/sbin/rpc.nisd -D -m tmpmap \ -x nisplusLDAPinitialUpdateAction=from_ldap \ -x nisplusLDAPinitialUpdateOnly=yes |
NIS+ サービスを開始します。
# svcadm enable network/rpc/nisplus:default |
rpc.nisd デーモンが、LDAP からダウンロードしたデータを提供するようになります。解決を必要とする衝突を NIS+ クライアント上で発生させないようにする必要がある場合は、これ以降の手順は、ほとんどまたはすべての NIS+ クライアントが動作していないときに実行してください。
影響を受けるテーブルの NIS+ データをダンプします。
次の例では、group.org_dir テーブルをダンプします。
# nisaddent -d group | sort > /after/group |
マージしたテーブルを作成します。
任意のマージ手順を使用して、マージ済みテーブルを作成できます。diff(1) 以外のツールを使用できない場合は、diff(1) コマンドを使用して /before ファイルと /after ファイルとの相違点を収集し、テキストエディタを使用して手動でマージすることができます。
次の例では、マージ後のテーブルが /after に格納されていることを前提としています。
マージ後のデータを NIS+ に読み込みます。次の例では、group テーブルを読み取ります。
# nisaddent -m -f /after/group group |
マージ後のテーブルから、不要な 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+ 複製は、NIS+ マスターから更新を取得するか (LDAP から取得する場合を含む) 、LDAP サーバーから直接データを読み込みます。この 2 つの方法を組み合わせることもできます。つまり、NIS+ 複製を使用するときは、主に 2 つの方法があります。
NIS+ 複製は変更せずに使用し、更新データは NIS+ マスターから取得する
この方法の場合は、NIS+ マスター以外は、LDAP サーバーと接続する必要がないため、構成が単純になります。従来の複製関係も変更されません。つまり、新しいデータはまずマスターに反映され、次に複製に反映されます。ネームサービスのデータを従来どおり NIS+ が管理するときは、ほとんどの場合、この方法が最も便利な方法です。ただし、LDAP と NIS+ 複製サーバーとの間のパスが長くなります。
NIS+ 複製は、更新データを NIS+ マスターから取得しないで、LDAP から直接取得する
この場合、複製のデータの更新は、LDAP から取得したデータの検索トラフィックおよび TTL に基づいて、NIS+ マスターの更新前または更新後に行われます。この方法はより複雑ですが、LDAP がネームサービスリポジトリを管理するときは、便利な方法です。NIS+ データに対する直接の更新は、ほとんどまたはまったく発生しません。
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+ マスター上のデータと異なることがあります。
LDAP データが NIS+ マスター上のデータと異なる
複製は、ローカルな NIS+ データベースであるキャッシュにデータを格納している。このキャッシュは期限切れではないが、LDAP と同期がとれていない。
このようなデータの不一致を許容できない場合は、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 との間でアカウント情報を完全に共有することはできません。
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 認証を利用できます。
none
none は、デフォルトの認証方式です。none には、固有の設定は必要ありません。ただし、セキュリティーは保証されません。セキュリティーを考慮する必要がない環境だけで使用してください。
none 認証を使用するときは、authenticationMethod 属性に次の値を設定してください。
authenticationMethod=none |
この認証方式を利用するときに一定のセキュリティーを保証するには、多くの場合、共有された機密情報 (パスワードまたは鍵) と LDAP の DN を関連付ける必要があります。rpc.nisd デーモンで使用する DN は一意なものであり、ほかの目的で使用することもできます。予測される LDAP トラフィックに対応するために、DN には適切な権限を割り当てる必要があります。たとえば、rpc.nisd デーモンが LDAP にデータを書き込む場合は、NIS+ データに使用されるコンテナ内で LDAP データを追加、更新、および削除する権限を、選択した DN に割り当てる必要があります。また、LDAP サーバーでは、リソースの使用方法がデフォルトで制限されている場合があります (検索時間制限、検索結果のサイズ制限など) 。この制限がある場合は、必要な数の NIS+ データコンテナをサポートできるように、選択した DN に対して必要な設定をする必要があります。
simple
simple 認証方式では、暗号化されていないパスワード文字列が交換されます。パスワードは、LDAP クライアント (rpc.nisd デーモン) および LDAP サーバー間をプレーンテキストとして送信されます。このため、simple 方式は、NIS+ と LDAP サーバー間の情報交換が別の方式で保護されている場合にだけ使用してください。
たとえば、LDAP トラフィックのトランポート層を暗号化するときに使用します。また、NIS+ サーバーと LDAP サーバーが同一システム上にあり、NIS+ および LDAP のトラフィックがカーネル内で処理され、認証されていないユーザーから保護されている場合にも使用できます。
simple 認証を使用するときは、rpc.nisd デーモンで使用する DN とパスワードの構成を変更してください。たとえば、DN が cn=nisplusAdmin, ou=People, dc=some, dc=domain で、パスワードが aword の場合は、次のように設定します。
authenticationMethod=simple nisplusLDAPproxyUser=cn=nisplusAdmin,ou=People,dc=some,dc=domain nisplusLDAPproxyPassword=aword |
パスワードが格納されている場所は、認証されないアクセスから確実に保護する必要があります。パスワードを rpc.nisd コマンド行で指定した場合は、ps(1) などのコマンドによってシステム上の任意のユーザーに見られる可能性があります。
sasl/digest-md5
sasl/digest-md5 認証方式では、digest/md5 アルゴリズムを使用して認証が行われます。
digest-md5 で使用する承認 ID を設定する方法と、/etc/default/rpc.nisd ファイルに承認 ID とそのパスワードを指定する方法については、LDAP サーバーのマニュアルを参照してください。
authenticationMethod=sasl/digest-md5 nisplusLDAPproxyUser=cn=nisplusAdmin,ou=People,dc=some,dc=domain nisplusLDAPproxyPassword=aword |
パスワードを格納するファイルを、承認されていないアクセスから確実に保護してください。
sasl/cram-md5
cram/md5 アルゴリズムを使用した認証方式。通常は、現在使用されていない SunDS LDAP サーバー以外では使用されません。
cram-md5 を使用してバインド DN を設定する方法と、/etc/default/rpc.nisd ファイルにバインド DN とそのパスワードを指定する方法については、LDAP サーバーのマニュアルを参照してください。
authenticationMethod=sasl/cram-md5 nisplusLDAPproxyUser=cn=nisplusAdmin,ou=People,dc=some,dc=domain nisplusLDAPproxyPassword=aword |
パスワードを格納するファイルを、承認されていないアクセスから確実に保護してください。
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) を組み合わせることができます。
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
次に、各引数について説明します。
server-address
/etc/default/rpc.nisd の preferredServerList 値の IP アドレス部分
bind-DN
/etc/default/rpc.nisd の nisplusLDAPproxyUser 値
password
/etc/default/rpc.nisd の nisplusLDAPproxyPassword 値
container
RFC 2307 に準拠したコンテナ名 (ou=Services、ou=Rpc など)
search-base
/etc/default/rpc.nisd の defaultSearchBase 値
/bin/time から出力される実際の値は、経過時間です。この値が、対応するテーブルエントリの TTL を 25 パーセント以上占めている場合は (「認証とセキュリティー」 を参照)、LDAP コンテナにインデックスを設定すると有効です。
rpc.nisd では、simple page と VLV インデックス方式がサポートされます。ご使用の LDAP サーバーでサポートされているインデックス方式、およびそのインデックスの作成方法については、LDAP サーバーのマニュアルを参照してください。
テーブルエントリ以外の NIS+ オブジェクトを LDAP に格納できます。ただし、NIS+ 複製が LDAP からこれらの NIS+ オブジェクトを取得しない限り、LDAP に格納しても値は設定されません。次の方法をお勧めします。
複製がない場合、または複製が NIS+ データを NIS+ マスターだけから取得する場合。
マッピング構成ファイル (NIS+LDAPmapping(4) のマニュアルページを参照) を編集して、テーブルエントリ以外のすべてのオブジェクトから次の属性値を削除します。
nisplusLDAPdatabaseIdMapping nisplusLDAPentryTtl nisplusLDAPobjectDN |
たとえば、/var/nis/NIS+LDAPmapping.template ファイルの場合は、次のセクションを削除するか、コメントにして無効にします。
# Standard NIS+ directories nisplusLDAPdatabaseIdMapping basedir: . . . |
nisplusLDAPdatabaseIdMapping user_attr_table:user_attr.org_dir |
nisplusLDAPdatabaseIdMapping audit_user_table:audit_user.org_dir # Standard NIS+ directories nisplusLDAPentryTtl basedir:21600:43200:43200 . . . |
nisplusLDAPentryTtl user_attr_table:21600:43200:43200 nisplusLDAPentryTtl audit_user_table:21600:43200:43200 # Standard NIS+ directories nisplusLDAPobjectDN basedir:cn=basedir,ou=nisPlus,?base?\ |
objectClass=nisplusObjectContainer:\ cn=basedir,ou=nisPlus,?base?\ objectClass=nisplusObjectContainer,\ objectClass=top . . . |
nisplusLDAPobjectDN audit_user_table:cn=audit_user,ou=nisPlus,?base?\ objectClass=nisplusObjectContainer:\ cn=audit_user,ou=nisPlus,?base?\ objectClass=nisplusObjectContainer,\ objectClass=top |
NIS+ 複製が NIS+ データを LDAP サーバーから取得する場合。
nisplusObject 属性と nisplusObjectContainer オブジェクトクラスを次の例に従って作成します。LDIF データは ldapadd(1) に適しています。属性とオブジェクトクラス OID は、例として挙げているだけです。
dn: cn=schema changetype: modify add: attributetypes attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.1.0 NAME 'nisplusObject' DESC 'An opaque representation of an NIS+ object' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 SINGLE-VALUE ) |
dn: cn=schema changetype: modify add: objectclasses |
objectclasses: (1.3.6.1.4.1.42.2.27.5.42.42.2.0 NAME'nisplusObjectContainer' |
SUP top STRUCTURAL DESC 'Abstraction of an NIS+ object' MUST ( cn $ nisplusObject ) ) |
NIS+ オブジェクトのコンテナも作成する必要があります。次の LDIF 構文は、ou=nisPlus,dc=some,dc=domain コンテナの作成方法を示しています。このコンテナは、ldapadd(1) の入力として使用できます。
dn: ou=nisPlus,dc=some,dc=domain ou: nisPlus objectClass: top objectClass: organizationalUnit |
NIS+ テーブルエントリを LDAP データから作成するときは、そのエントリオブジェクトが存在するテーブルオブジェクトの対応する値を使用して、所有者、グループ、アクセス権、および TTL を初期化する必要があります。環境によっては、これらの NIS+ エントリ属性を個別に設定する必要があります。たとえば、rpc.nispasswdd(1M) デーモンを使用しない環境では、この操作が必要になります。ユーザー自身が NIS+ パスワードを変更して、cred.org_dir テーブルに格納されている Diffie-Hellman キーを再暗号化できるようにするには、passwd.org_dir および cred.org_dir エントリの所有者をそのユーザーに設定し、その所有者に変更権限を割り当てる必要があります。
1 つ以上の NIS+ テーブルエントリの所有者、グループ、アクセス権、または TTL を LDAP に格納するには、次の操作を実行する必要があります。
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 ) ) |
関連するテーブルの 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 |
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 |
所有者、グループ、アクセス権、および TTL エントリデータのどれか、またはすべてを LDAP にアップロードします。
詳細については、「すべての NIS+ データを 1 回の操作で LDAP に変換する方法」を参照してください。
マッピングの変更を有効にするために、NIS+ サービスを再起動します。
# svcadm restart network/rpc/nisplus:default |
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+ インストールでは、主体名とネット名を作成するときは、この方式でかまいません。ただし、次のような場合は、この方式では成功しません。
cred.org_dir テーブルの所有者名が属しているドメインが、cred.org_dir テーブル内の主体名およびネット名によって共有されるドメインと一致していない場合。所有者が親ドメインの主体である場合は、サブドメインの cred.org_dir テーブルも同様です。この問題は、次のいずれかの方法で解決できます。
cred.org_dir テーブルの所有者を変更して、テーブルエントリのドメインと一致させます。
cred.org_dir データベース ID のマッピングルールを変更して、ほかの NIS+ オブジェクトの所有者を使用します。適切なオブジェクトが存在しない場合は、この目的のために NIS+ オブジェクトを作成します。
たとえば、sub.dom.ain. ドメインの cred.org_dir テーブルを master.dom.ain. が所有し、cred.org_dir.sub.dom.ain. の主体とネット名が sub.dom.ain に属している場合は、次のようなリンクオブジェクトを作成します。
# nisln cred.org_dir.sub.dom.ain. \ credname.sub.dom.ain. |
リンクオブジェクトの所有者を、次のように sub.dom.ain. 内の適切な主体に設定します。
# nischown trusted.sub.dom.ain. credname.sub.dom.ain. |
マッピングファイルを編集します。次の箇所を変更します。
(nis+:zo_owner[]cred.org_dir, "*.%s")), \ |
から
(nis+:zo_owner[]credname.sub.dom.ain., "*.%s")), \ |
ここで使用しているリンクオブジェクト credname は、例として挙げています。エントリオブジェクト以外の、任意の有効なオブジェクトタイプとオブジェクト名が使用できます。オブジェクトの所有者に正しいドメイン名を設定することが重要です。
主体およびネット名に使用されるドメインの主体に対して、特別な目的のオブジェクトであってもその所有権を与えたくない場合は、次に示すように nisplusPrincipalName 属性と nisplusNetname 属性を作成します。
cred.org_dir テーブルに、複数のドメインに属している主体とネット名が設定されている場合。
LDAP サーバーのマニュアルを参照して、nisplusPrincipalName 属性および nisplusNetname 属性と、nisplusAuthName オブジェクトクラスを作成します。次のデータは ldapadd への LDIF データになっています。属性とオブジェクトクラス OID は、例として挙げているだけです。
dn: cn=schema changetype: modify add: attributetypes attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.7.0 NAME 'nisplusPrincipalName' \ DESC 'NIS+ principal name' \ SINGLE-VALUE \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) |
attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.9.0 NAME 'nisplusNetname' \ DESC 'Secure RPC netname' \ SINGLE-VALUE \ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) dn: cn=schema changetype: modify add: objectclasses objectclasses: ( 1.3.6.1.4.1.42.2.27.5.42.42.10.0 NAME 'nisplusAuthName' \ SUP top AUXILLIARY DESC 'NIS+ authentication identifiers' \ MAY ( nisplusPrincipalName $ nisplusNetname ) ) |
新しく作成した nisplusNetname 属性および nisplusPrincipalName 属性を使用するために cred.org_dir マッピングを有効にします。テンプレートマッピングファイル /var/nis/NIS+LDAPmapping.template では、この目的に対応した行がコメントになっています。credlocal、creduser、および crednode データベース ID については、nisplusObjectDN、nisplusLDAPattributeFromColumn 属性、および nisplusLDAPcolumnFromAttribute 属性の値を参照してください。マッピングファイルの編集が終了したら、NIS+ サービスを再起動します。
RFC 2307 では、NIS+ の client_info.org_dir および timezone.org_dir テーブルに保存する情報のスキーマは規定していません。このため、これらのテーブルのマッピングは、テンプレートマッピングファイル (/var/nis/NIS+LDAPmapping.template) ではデフォルトで無効になっています。client_info および timezone の情報を LDAP に保存する場合は、LDAP サーバーのマニュアルを参照しながら、以降の節で説明する新しい属性とオブジェクトクラスを作成します。
次のような属性とオブジェクトクラスを作成し、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 への移行シナリオ」を参照してください。
次のような属性とオブジェクトクラスを作成し、タイムゾーンデータのコンテナを作成します。推奨コンテナ名は 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 への移行シナリオ」を参照してください。
テンプレートマッピングファイル /var/nis/NIS+LDAPmapping.template には、すべての標準 NIS+ オブジェクトのマッピング情報が含まれます。サイトまたはアプリケーション固有のオブジェクトのマッピングをサポートするには、新しいマッピングエントリを追加する必要があります。エントリ以外のオブジェクト (ディレクトリ、グループ、リンク、またはテーブル) の場合は、簡単に追加できます。しかし、エントリオブジェクトの場合、対応するエントリデータの LDAP 編成が NIS+ で使用される編成と大きく異なるときは、エントリの追加が複雑になることがあります。ここでは簡単な例を挙げます。
対応づけるオブジェクトの完全指定名を検索します。
このオブジェクト名が nisplusLDAPbaseDomain 属性で指定されるドメイン名に存在する場合は、nisplusLDAPbaseDomain 値に等しい部分は省略できます。
たとえば、nisplusLDAPbaseDomain の値が some.domain. で、マッピング先のオブジェクトが nodeinfo.some.domain. と呼ばれるテーブルの場合、オブジェクト名は nodeinfo に短縮できます。
オブジェクトを識別するデータベース 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 |
オブジェクトの 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 |
オブジェクトデータを 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 はマスターおよび複製の両方に対して使用できます。
(マッピング先の NIS+ オブジェクトがまだ NIS+ に作成されていない場合は、この手順を省略できます。)オブジェクトデータを LDAP に格納します。この操作には、rpc.nisd デーモンを使用できます。ただし、nisldapmaptest(1M) ユーティリティーを使用すると rpc.nisd デーモンを停止する必要がないので、この操作をより簡単に行うことができます。
# nisldapmaptest -m /var/nis/NIS+LDAPmapping -o -t nodeinfo -r |
-o オプションには、テーブルエントリではなく、テーブルオブジェクト自体を指定します。
オブジェクトデータが 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 属性が nodeInventory と nodeOwner であるとします。
既存の nodeinfo データを LDAP にアップロードするときは、別のファイルに新しいマッピング属性を作成すれば、簡単に行うことができます。たとえば、/var/nis/tmpmapping を使用します。
マッピング先の NIS+ テーブルを識別するデータベース ID を作成します。
nisplusLDAPdatabaseIdMapping nodeinfo:nodeinfo |
nodeinfo テーブルのエントリに TTL を設定します。この情報はほとんど変更されないため、TTL を 12 時間に設定します。rpc.nisd デーモンがディスクから nodeinfo テーブルを最初に読み取ると、テーブルエントリの TTL が 6 - 12 時間からランダムに選択されます。
nisplusLDAPentryTtl nodeinfo:21600:43200:43200 |
既存のマッピングから、作成するマッピングに似ているものを選択します。この例では、属性値の割り当ては簡単で、直接割り当てるだけです。ただし、既存のコンテナに LDAP データを格納する処理が複雑です。このため、nodeinfo データの削除は、慎重に行う必要があります。ou=Hosts エントリ全体を削除せずに、nodeInventory および nodeOwner 属性だけを削除します。このため、特別の削除ルールが必要になります。
つまり、コンテナを共有し削除ルールを持つマッピングを探します。この候補として、netmasks マッピングがあります。このマッピングは、ou=Networks コンテナを共有し、削除ルールを持っています。
/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 |
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 |
LDAP のデータを NIS+ にマッピングするときは、netmasks エントリのテンプレートは次のようになります。
nisplusLDAPcolumnFromAttribute \ netmasks: addr=ipNetworkNumber, \ mask=ipNetmaskNumber, \ comment=description |
属性および列名を代入すると、次のようになります。
nisplusLDAPcolumnFromAttribute \ nodeinfo: cname=cn, \ inventory=nodeInventory, \ owner=nodeOwner |
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= |
マッピング情報はこれで完了です。
NIS+ nodeinfo テーブルにすでにデータが存在する場合は、そのデータを LDAP にアップロードします。新しい nodeinfo マッピング情報を、別のファイル /var/nis/tmpmapping に格納します。
# /usr/sbin/rpc.nisd -D -m /var/nis/tmpmapping \ -x nisplusLDAPinitialUpdateAction=to_ldap \ -x nisplusLDAPinitialUpdateOnly=yes |
一時ファイル /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 |
リダイレクトに二重矢印「>>」を使っている点に注意してください。矢印「>」を使った場合は対象ファイルを上書きします。
NIS+ および LDAP の構成情報は、構成ファイルとコマンド行で格納できますが、構成属性は LDAP にも格納できます。構成情報が多くの NIS+ サーバーによって共有され、定期的に変更される場合は、LDAP に格納すると便利です。
構成属性を LDAP に格納するには、LDAP サーバーのマニュアルを参照して、次の新しい属性とオブジェクトクラスを作成します。構成情報は、rpc.nisd コマンド行または /lib/svc/method/nisplus の 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 $ 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 |