この章では、LDAP ディレクトリに格納されたネーム情報を使用する NIS クライアントの、サポートを有効にする方法について説明します。この章の手順に従うことで、NIS ネームサービスから LDAP ネームサービスへ移行できます。
LDAP への移行の利点を判定するには、「LDAP ネームサービスとその他のネームサービスの比較」を参照してください。
この章の内容は、次のとおりです。
NIS から LDAP への移行サービス (「N2L サービス」) は、NIS マスターサーバー上の既存の NIS デーモンを、NIS から LDAP への移行用デーモンに置き換えます。また、N2L サービスは、 NIS から LDAP への移行用マッピングファイルを、その NIS マスターサーバー上に作成します。マッピングファイルでは、NIS マップエントリと、LDAP での同等なディレクトリ情報ツリー (DIT) との間のマッピングを指定します。この移行を完了した NIS マスターサーバーは、「N2L サーバー」と呼ばれます。スレーブサーバーには、NISLDAPmapping ファイルはありません。したがって、引き続きそのまま動作します。スレーブサーバーのデータは、N2L サーバーから、通常の NIS マスターからと同様に、定期的に更新されます。
N2L サービスの動作は、構成ファイル ypserv および NISLDAPmapping によって制御されます。スクリプト inityp2l は、これらの構成ファイルの作成を支援します。いったん N2L サーバーが確立されたあとは、構成ファイルを直接編集して N2L を管理できます。
N2L サービスは、次の操作をサポートします。
LDAP ディレクトリ情報ツリー (DIT) 内に NIS マップをインポートする
NIS の速度および拡張性を維持しつつ、クライアントから DIT 情報にアクセスする
あらゆるネームシステムで、1 つのソースの情報だけが正規のソースになります。従来の NIS では、正規の情報は NIS ソースです。N2L サービスを使用する場合、LDAP ディレクトリが正規のデータソースになります。ディレクトリは、第 9 章LDAP 基本コンポーネントおよび概念 (概要)で説明するディレクトリ管理ツールを使用して管理されます。
NIS ソースは、緊急時のバックアップまたはバックアウト (LDAP に移行するのではなく、NIS の使用をやめる) にのみ使用します。N2L サービスを使い始めてから、NIS クライアントを徐々に減らすことができます。最終的に、すべての NIS クライアントを Solaris LDAP ネームサービスクライアントに置き換えることができます。
以降の節では、さらに概要情報を説明します。
NIS と LDAP のサービスはサービス管理機能によって管理されます。これらのサービスに関する有効化、無効化、再起動などの管理アクションは、svcadm コマンドを使用して実行できます。svcs コマンドを使用してサービスの状態を照会できます。LDAP および NIS での SMF の使用の詳細については、「LDAP とサービス管理機能」および「NIS とサービス管理機能」を参照してください。SMF の概要については、『Solaris のシステム管理 (基本編)』の第 18 章「サービスの管理 (概要)」を参照してください。また、詳細については、svcadm(1M) および svcs(1) のマニュアルページを参照してください。
この章の手順を実行するには、NIS および LDAP の概念、用語、および ID を理解する必要があります。NIS および LDAP のネームサービスについての詳細は、このマニュアルの以降の節を参照してください。
NIS の概要については、第 4 章ネットワーク情報サービス (NIS) (概要)。
LDAP の概要については、第 8 章LDAP ネームサービスの紹介 (概要/リファレンス)。
NIS と LDAP ネームサービスクライアント間でデータを共有する予定がない環境。
このような環境では、N2L サーバーは、過度に複雑な NIS マスターサーバーとして機能します。
NIS ソースファイルを変更するツール (yppasswd 以外のツール) で NIS マップを管理している環境。
DIT マップから NIS ソースを再生成する処理は、必ずしも正確ではないため、生成されたマップを手動で確認する必要があります。いったん N2L サービスを使用し始めたあとは、NIS ソースの再生成は NIS をバックアウトするため、または NIS に戻すためにだけ提供されます。
NIS クライアントのない環境。
このような環境では、Solaris LDAP ネームサービスクライアントおよびそれに対応するツールを使用してください。
N2L サービスに関連するファイルをインストールするだけでは、NIS サーバーのデフォルトの動作は変更されません。インストール時に、サーバー上の NIS のマニュアルページの一部が変更され、N2L のヘルパースクリプト inityp2l および ypmap2src が追加されます。しかし、NIS サーバー上で inityp2l を実行したり、N2L 構成ファイルを手動で作成したりしないと、NIS コンポーネントは従来の NIS モードで起動し、通常通りに機能します。
inityp2l の実行後に、サーバーとクライアントの動作が少し変更されます。次の表に、NIS および LDAP のユーザータイプと、N2L サービスの配備後に各タイプのユーザーが注意しなければならない部分の説明を示します。
ユーザータイプ |
N2L サービスの影響 |
---|---|
NIS マスターサーバー管理者 |
NIS マスターサーバーは、N2L サーバーに変換される。構成ファイル NISLDAPmapping および ypserv が、N2L サーバー上にインストールされる。N2L サーバーの確立後は、LDAP コマンドを使用してネーム情報を管理できる |
NIS スレーブサーバー管理者 |
N2L の変換後も、NIS スレーブサーバーは NIS を通常の方法で動作する。ypmake によって yppush が呼び出されると、N2L サーバーは、更新された NIS マップをスレーブサーバーに転送する。ypmake(1M) のマニュアルページを参照 |
NIS クライアント |
NIS の読み取り動作は、従来の NIS と同様。Solaris LDAP ネームサービスクライアントが DIT 内の情報を変更すると、情報が NIS マップ内にコピーされる。コピー操作は、変更可能なタイムアウトの期限が切れると完了する。このような動作は、クライアントが NIS スレーブサーバーに接続された場合の通常の NIS クライアントの動作と同じ N2L サーバーが読み取りのために LDAP サーバーにバインドできない場合、N2L サーバーはローカルにキャッシュされたコピーから情報を返す。また、N2L サーバーは内部サーバーエラーを返す場合もある。N2L サーバーの構成によって、どちらの方法で応答することも可能。詳細については、ypserv(1M) のマニュアルページを参照 |
すべてのユーザー |
NIS クライアントがパスワードの変更を要求すると、N2L マスターサーバーとネイティブの LDAP クライアントに変更がただちに反映される NIS クライアントでのパスワードの変更を試みて、LDAP サーバーが利用できない場合は、変更は拒絶され N2L サーバーは内部サーバーエラーを返す。この動作によって、キャッシュに誤った情報が書き込まれることを防止する |
N2L サービスの実装に関連する用語を次に示します。
表 15–1 N2L の移行の関連用語
用語 |
説明 |
---|---|
N2L 構成ファイル |
/var/yp/NISLDAPmapping および /var/yp/ypserv ファイル。ypserv デーモンが N2L モードでマスターサーバーを起動するために使用する。詳細は、NISLDAPmapping(4) および ypserv(4) のマニュアルページを参照 |
マップ |
N2L サービスでは、「マップ」は、次の 2 とおりの意味で使用される。
|
マッピング |
LDAP DIT エントリとの間の NIS エントリの変換プロセス |
マッピングファイル |
NISLDAPmapping ファイル。NIS と LDAP のファイル間のエントリのマッピング方法を確立する |
標準マップ |
通常使用される NIS マップ。マッピングファイルへの手動修正が不要で、N2L サービスによってサポートされる。サポートされる標準マップのリストは、「サポートされる標準マッピング」を参照 |
非標準マップ |
標準の NIS マップであるが、RFC 2307 やその後継で指定されたマッピング以外の、NIS と LDAP DIT 間のマッピングを使用するようにカスタマイズされたマップ |
カスタムマップ |
標準のマップではないマップ。したがって、NIS から LDAP への移行時にはマッピングファイルの手動修正が必要 |
LDAP クライアント |
従来の LDAP クライアント。LDAP サーバーとの間で読み書きを行う。従来の LDAP クライアントは、任意の LDAP サーバーに対して読み取りおよび書き込みを行うシステム。Solaris LDAP ネームサービスクライアントは、カスタマイズされたネーム情報のサブセットを処理する |
LDAP ネームサービスクライアント |
Solaris LDAP クライアント。カスタマイズされたネーム情報のサブセットを処理する |
N2L サーバー |
N2L サービスを使用して、N2L サーバーとして再構成された NIS マスターサーバー。再構成には、NIS デーモンの置き換えと新しい構成ファイルの追加が含まれる。 |
N2L の移行に関連して 2 つのユーティリティー、2 つの構成ファイル、および 1 つのマッピングがあります。
表 15–2 N2L のコマンド、ファイル、およびマップの説明
コマンド/ファイル/マップ |
説明 |
---|---|
/usr/lib/netsvc/yp/inityp2l |
NISLDAPmapping および ypserv の構成ファイルの作成を支援するユーティリティー。このユーティリティーは、これらのファイルを管理するための汎用ツールではない。熟練したユーザーであれば、inityp2l の出力をテキストエディタを使って検証したりカスタマイズしたりすることで、N2L 構成ファイルの管理や、カスタムマッピングの作成を行うことも可能。inityp2l(1M) のマニュアルページを参照 |
/usr/lib/netsvc/yp/ypmap2src |
標準の NIS マップを同等な NIS ソースファイルに近似したファイルに変換するユーティリティー。ypmap2src の主要な用途は、N2L の移行サーバーから従来の NIS への変換。ypmap2src(1M) のマニュアルページを参照 |
/var/yp/NISLDAPmapping |
NIS マップエントリと、これと同等な LDAP でのディレクトリ情報ツリー (DIT) エントリとの間のマッピングを指定する構成ファイル。NISLDAPmapping(4) のマニュアルページを参照 |
/var/yp/ypserv |
NIS から LDAP への移行用デーモンの構成情報を指定するファイル。ypserv(4) のマニュアルページを参照 |
ageing.byname |
NIS から LDAP への移行の実行時に、DIT でのパスワード有効期限情報の読み取りおよび書き込みのために yppasswdd によって使用されるマッピング |
デフォルトでは、N2L サービスは次のリストのマップと RFC 2307 (またはその後継) LDAP エントリとの間のマッピングをサポートします。これらの標準マップでは、マッピングファイルへの手動修正は不要です。システム上で次のリストにないマップは、カスタムマップと見なされ、マッピングファイルの手動修正が必要です。
また、N2L サービスは、auto.* マップの自動マッピングもサポートします。ただし、ほとんどの auto.* ファイル名とそのコンテンツは、各ネットワーク構成に固有なので、このリストではこれらのファイルは指定していません。例外は、auto.home マップと auto.master マップです。これらは標準マップとしてサポートされます。
audit_user auth_attr auto.home auto.master bootparams ethers.byaddr ethers.byname exec_attr group.bygid group.byname group.adjunct.byname hosts.byaddr hosts.byname ipnodes.byaddr ipnodes.byname mail.byaddr mail.aliases netgroup netgroup.byprojid netgroup.byuser netgroup.byhost netid.byname netmasks.byaddr networks.byaddr networks.byname passwd.byname passwd.byuid passwd.adjunct.byname printers.conf.byname prof_attr project.byname project.byprojectid protocols.byname protocols.bynumber publickey.byname rpc.bynumber services.byname services.byservicename timezone.byname user_attr |
NIS から LDAP への移行時に、yppasswdd デーモンは、N2L 固有のマップ ageing.byname を使用して、 DIT でのパスワード有効期限情報の読み取りと書き込みを行います。パスワード有効期限を使用していない場合は、ageing.byname マッピングは無視されます。
次の表に、標準およびカスタムの NIS から LDAP への変換マッピングによって、N2L サービスをインストールし管理するために必要な手順を示します。
作業 |
説明 |
参照先 |
---|---|---|
すべての前提条件の完了 |
NIS サーバーと Sun Java System Directory Server (LDAP サーバー) を正しく構成すること | |
N2L サービスの設定 |
NIS マスターサーバーで、inityp2l を実行して、次のいずれかのマッピングを設定する |
|
|
標準マッピング | |
|
カスタムまたは非標準マッピング | |
マップのカスタマイズ |
N2L の移行のためのカスタムマップの作成方法の例を参照する | |
N2L のための Sun Java System Directory Server の構成 |
N2L 移行のための、LDAP サーバーとして Sun Java System Directory Server を構成し調整する |
「Sun Java System Directory Server を使用した NIS から LDAP への移行の最良の実践原則」 |
システムのトラブルシューティング |
一般的な N2L の問題を特定し解決する | |
NIS に戻す方法 |
次のいずれか適切なマップを使用して NIS に戻す |
|
|
以前の NIS ソースファイルに基づくマップ | |
|
現在の DIT に基づくマップ |
N2L サービスを実装する前に次の項目をチェックし、完了する必要があります。
inityp2l スクリプトを実行して N2L モードを有効にする前に、システムが従来の NIS サーバーで動作するように設定されていること
システムで LDAP ディレクトリサーバーを構成していること
NIS から LDAP への移行ツールでは、Sun Java System Directory Server (以前の名称は Sun ONE Directory Server) と、Sun から提供されるその互換バージョンのディレクトリサーバーがサポートされています。Sun Java System Directory Server を使用している場合は、N2L サービスを設定する前に、idsconfig コマンドを使用してサーバーを構成してください。idsconfig についての詳細は、第 11 章LDAP クライアントと Sun Java System Directory Server の設定 (手順)と idsconfig(1M) のマニュアルページを参照してください。
その他の (他社製の) の LDAP サーバーが、N2L サービスで動作する場合もありますが、Sun はそれらをサポートしていません。Sun Java System Directory Server または Sun 互換サーバー以外の LDAP サーバーを使用している場合は、N2L サービスを設定する前に、RFC 2307 (またはその後継) スキーマをサポートするようにサーバーを手動で構成してください。
nsswitch.conf ファイルで少なくとも hosts エントリおよび ipnodes エントリに対して、検索順序として nis の前に files がリストされていることを確認すること
N2L マスターサーバーと LDAP サーバーのアドレスが、N2L マスターサーバー上の hosts ファイルまたは ipnodes ファイルに存在することを確認すること。ローカルホスト名を解決するためのシステムの構成方法に応じて、サーバーアドレスは hosts ファイル、ipnodes ファイル、またはその両方にリストされる必要があります。
代わりに、ypserv で、ホスト名ではなく LDAP サーバーのアドレスをリストする方法もあります。このことは、LDAP サーバーのアドレスが別の場所にもリストされていることを意味しています。したがって、LDAP サーバーと N2L マスターサーバーのどちらかのアドレスを変更するには、別のファイルの修正も必要です。
次の 2 つの手順に示すように、標準のマッピングとカスタムマッピングのどちらかを使用して、N2L サービスを設定できます。
NIS から LDAP への変換作業の一部として、inityp2l コマンドを実行する必要があります。このコマンドは、対話型で、構成情報を入力するスクリプトを実行します。次のリストに、構成に必要な情報の種類を示します。これらの属性の詳細については、ypserv(1M) のマニュアルページを参照してください。
作成する構成ファイルの名前 (デフォルト = /etc/default/ypserv)
LDAP の構成情報を格納する DN (デフォルト = ypserv)
LDAP との間でデータをマッピングするための優先サーバーリスト
LDAP との間でデータをマッピングするための認証方式
LDAP との間でデータをマッピングするための TLS (Transport Layer Security)
LDAP との間でデータを読み書きするためのプロキシのユーザーバインド DN
LDAP との間でデータを読み書きするためのプロキシのユーザーパスワード
LDAP バインド動作のタイムアウト値 (秒単位)
LDAP 検索動作のタイムアウト値 (秒単位)
LDAP 変更動作のタイムアウト値 (秒単位)
LDAP 追加動作のタイムアウト値 (秒単位)
LDAP 削除動作のタイムアウト値 (秒単位)
LDAP サーバーでの検索動作の制限時間 (秒単位)
LDAP サーバーでの検索動作の制限サイズ (バイト単位)
N2L が LDAP 照会に従うかどうか
LDAP 検索のエラー処理、検索試行回数、および各試行間のタイムアウト (秒単位)
格納のエラー処理、検索試行回数、および各試行間のタイムアウト (秒単位)
マッピングファイル名
auto_direct マップのマッピング情報を生成するかどうか
スクリプトは、マッピングファイル内の適切な位置にカスタムマップについての情報を配置します。
ネーミングコンテキスト
パスワードの変更を有効にするかどうか
任意のマップのデフォルトの TTL 値を変更するかどうか
sasl/cram-md5 認証は、Sun Java System Directory Server を含むほとんどの LDAP サーバーではサポートされません。
「サポートされる標準マッピング」にリストされているマップを移行する場合は、この手順に従います。カスタムマップまたは非標準マップを使用している場合 は、「カスタムマッピングまたは非標準マッピングを使用して N2L サービスを設定する方法」を参照してください。
LDAP サーバーの設定が終わったら、inityp2l スクリプトを実行して、プロンプトに従って構成情報を入力します。inityp2l は構成を行い、標準および auto.* マップのためのマッピングファイルを設定します。
「NIS から LDAP への移行のための前提条件」にリストされた前提条件の手順を完了します。
NIS マスターサーバーで、スーパーユーザーになるか、同等の役割になります。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の第 9 章「役割によるアクセス制御の使用 (手順)」を参照してください。
NIS マスターサーバーを N2L サーバーに変換します。
# inityp2l |
NIS マスターサーバーで inityp2l スクリプトを実行して、プロンプトに従います。指定が必要な情報のリストは、「NIS から LDAP への移行サービスの設定」を参照してください。
詳細については、inityp2l(1M) のマニュアルページを参照してください。
LDAP ディレクトリ情報ツリー (DIT) が完全に初期化されているかどうかを判定します。
NISLDAPmapping ファイルにリストされたすべてのマップの配備に必要な情報がすでに DIT 内に存在する場合、DIT は完全に初期化されています。
NIS ソースファイルから移行するため、DIT を初期化します。
DIT が完全に初期化されていない場合に限って、次の手順を実行してください。
以前の NIS マップが最新の状態になっていることを確認してください。
# cd /var/yp # make |
詳細については、ypmake(1M) のマニュアルページを参照してください。
NIS デーモンを停止します。
# svcadm disable network/nis/server:default |
以前のマップを DIT にコピーしてから、マップ用の N2L サポートを初期化します。
# ypserv -Ir |
ypserv が終了するまで待ちます。
元の NIS dbm ファイルは上書きされません。必要に応じて、これらのファイルを回復できます。
NIS デーモンを起動し、デーモンが新しいマップを使用していることを確認します。
# svcadm enable network/nis/server:default |
これで、標準マップでの N2L サービスの設定を完了します。手順 6 を行う必要はありません。
NIS マップを初期化します。
DIT が完全に初期化され、手順 5 をスキップした場合に限って、次の手順を実行してください。
次の状況に適合する場合、この手順を実行してください。
「サポートされる標準マッピング」にリストされていないマップがある
RFC 2307 とは異なるマッピングで LDAP にマップしたい標準の NIS マップがある
「NIS から LDAP への移行のための前提条件」にリストされた前提条件の手順を完了します。
NIS マスターサーバーで、スーパーユーザーになるか、同等の役割になります。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の第 9 章「役割によるアクセス制御の使用 (手順)」を参照してください。
NIS マスターサーバーを N2L サーバーに構成します。
# inityp2l |
NIS マスターサーバーで inityp2l スクリプトを実行して、プロンプトに従います。指定が必要な情報のリストは、「NIS から LDAP への移行サービスの設定」を参照してください。
詳細については、inityp2l(1M) のマニュアルページを参照してください。
/var/yp/NISLDAPmapping ファイルを修正します。
マッピングファイルの修正方法の例は、「カスタムマップの例」を参照してください。
LDAP ディレクトリ情報ツリー (DIT) が完全に初期化されているかどうかを判定します。
NISLDAPmapping ファイルにリストされたすべてのマップの配備に必要な情報がすでに DIT 内に存在する場合、DIT は完全に初期化されています。
初期化されていない場合、手順 6、手順 8、および手順 9 を完了します。
初期化されている場合、手順 6 をスキップして、手順 7、手順 8、および手順 9 を完了します。
NIS ソースファイルから移行するため、DIT を初期化します。
以前の NIS マップが最新の状態になっていることを確認してください。
# cd /var/yp # make |
詳細については、ypmake(1M) のマニュアルページを参照してください。
NIS デーモンを停止します。
# svcadm disable network/nis/server:default |
以前のマップを DIT にコピーしてから、マップ用の N2L サポートを初期化します。
# ypserv -Ir |
ypserv が終了するまで待ちます。
元の NIS dbm ファイルは上書きされません。必要に応じて、これらのファイルを回復できます。
NIS デーモンを起動し、デーモンが新しいマップを使用していることを確認します。
# svcadm enable network/nis/server:default |
手順 7 をスキップして、手順 8 から続行します。
NIS マップを初期化します。
DIT が完全に初期化されている場合に限って、この手順を実行します。
LDAP エントリが正しいことを確認します。
エントリが間違っている場合、LDAP ネームサービスクライアントからはそのエントリを見つけられません。
# ldapsearch -h server -s sub -b "ou=servdates, dc=..." \ "objectclass=servDates" |
LDAP_ マップの内容を確認します。
次に、makedbm を使用して servdate.bynumber マップの内容を確認する方法の例を示します。
# makedbm -u LDAP_servdate.bynumber plato: 1/3/2001 johnson: 2/4/2003,1/3/2001 yeats: 4/4/2002 poe: 3/3/2002,3/4/2000 |
出力結果が期待どおりの内容であれば、NIS から LDAP への移行は成功です。
元の NIS dbm ファイルは上書きされないことに注意してください。したがって、いつでもこれらのファイルは回復できます。詳細については、「NIS に戻す方法」を参照してください。
次の 2 つの例に、マップをカスタマイズする方法を示します。必要に応じて、任意のテキストエディタを使用して、/var/yp/NISLDAPmapping ファイルを修正します。ファイルの属性と構文については、NISLDAPmapping(4) のマニュアルページと第 9 章LDAP 基本コンポーネントおよび概念 (概要)の LDAP ネームサービス情報を参照してください。
この例では、DIT でデフォルトの位置から別の (非標準の) 位置にホストエントリを移動する方法を示します。
NISLDAPmapping ファイルの nisLDAPobjectDN 属性を、新しいベース LDAP 識別名 (DN) に変更します。この例では、LDAP オブジェクトの内部構造は変更されません。したがって、objectClass エントリは変更されません。
変更前:
nisLDAPobjectDN hosts: \ ou=hosts,?one?, \ objectClass=device, \ objectClass=ipHost |
変更後:
nisLDAPobjectDN hosts: \ ou=newHosts,?one?, \ objectClass=device, \ objectClass=ipHost |
この変更によって、エントリは次のようにマッピングされます。
dn: ou=newHosts, dom=domain1, dc=sun, dc=com
元は、次のようでした。
dn: ou=hosts, dom=domain1, dc=sun, dc=com.
この例では、カスタムマップの実装方法を示します。
仮想のマップ「servdate.bynumber」には、システムのサービス日付についての情報が含まれます。このマップには、マシンのシリアル番号でインデックスが付けられます。この例では、123 です。各エントリは、マシンの所有者名、コロン、およびサービス日付のコンマ区切りのリストで構成されます。たとえば、John Smith:1/3/2001,4/5/2003 のようになります。
古いマップ構造は、次の形式の LDAP エントリにマップされます。
dn: number=123,ou=servdates,dc=... \ number: 123 \ userName: John Smith \ date: 1/3/2001 \ date: 4/5/2003 \ . . . objectClass: servDates |
NISLDAPmapping ファイルを調べると、必要なパターンに最も近いマッピングが group であることがわかります。カスタムマッピングは group マッピングを参考にできます。マップは 1 つだけなので、nisLDAPdatabaseIdMapping 属性は不要です。NISLDAPmapping に追加される属性は、次のとおりです。
nisLDAPentryTtl servdate.bynumber:1800:5400:3600 nisLDAPnameFields servdate.bynumber: \ ("%s:%s", uname, dates) nisLDAPobjectDN servdate.bynumber: \ ou=servdates, ?one? \ objectClass=servDates: nisLDAPattributeFromField servdate.bynumber: \ dn=("number=%s,", rf_key), \ number=rf_key, \ userName=uname, \ (date)=(dates, ",") nisLDAPfieldFromAttribute servdate.bynumber: \ rf_key=number, \ uname=userName, \ dates=("%s,", (date), ",") |
N2L サービスは、Sun Java System Directory Server (以前の名称は Sun ONE Directory Server) と、Sun の提供するその互換バージョンのディレクトリサーバーをサポートしています。その他の (他社製の) LDAP サーバーが、N2L サービスで動作する場合もありますが、Sun はそれらをサポートしていません。Sun Java System Directory Server または Sun の互換サーバー以外の LDAP サーバーを使用している場合は、RFC 2307 (またはその後継スキーマ) に準拠するように、サーバーを手動で構成してください。
Sun Java System Directory Server を使用すれば、ディレクトリサーバーを強化してパフォーマンスを改善できます。これらの強化を行うには、Sun Java System Directory Server 上に LDAP の管理者権限が必要です。また、ディレクトリサーバーのリブートが必要な場合もあります。リブートは、サーバーの LDAP クライアントとの間で調整が必要な作業です。Sun Java System Directory Server (および SunONE Directory Server、iPlanet Directory Server) のドキュメントは、Web サイト Sun Java System Directory Server Enterprise Edition 6.2 で入手できます。
大規模なマップでは、LDAP の仮想リスト表示 (VLV) インデックスを使用して、LDAP の検索から正しい結果が得られることを保証しなければなりません。Sun Java System Directory Server での VLV インデックスの設定についての詳細は、Sun Java System Directory Server Enterprise Edition 6.2 のドキュメントを参照してください。
VLV の検索結果では、固定ページサイズ 50000 を使用します。Sun Java System Directory Server で VLV を使用する場合は、LDAP サーバーと N2L サーバーの両方でこのサイズの転送を処理できるようにしてください。すべてのマップがこの制限より小規模であることが明らかな場合は、VLV インデックスを使用する必要はありません。ただし、マップがこのサイズ制限より大きい場合、またはすべてのマップのサイズが明確な場合以外には、VLV インデックスを使用して、結果が不完全となることを防止しなければなりません。
VLV インデックスを使用している場合は、次のように適切なサイズ制限を設定します。
Sun Java System Directory Server では、 nsslapd-sizelimit 属性を 50000 以上、または -1 に設定する必要があります。idsconfig(1M) のマニュアルページを参照してください。
N2L サーバーでは、 nisLDAPsearchSizelimit 属性を 50000 以上、または 0 に設定する必要があります。詳細については、NISLDAPmapping(4) のマニュアルページを参照してください。
VLV インデックスが作成されたら、Sun Java System Directory Server で vlvindex オプションを付けて directoryserver を実行してインデックスを有効にします。詳細については、directoryserver(1M) のマニュアルページを参照してください。
次の状況に適合する場合、Sun Java System Directory Server の idsconfig コマンドを使用して、VLV を設定してください。
Sun Java System Directory Server を使用している場合
標準マップを RFC 2307 LDAP エントリにマッピングしている場合
VLV はドメイン固有です。よって、idsconfig を実行するたびに、1 つの NIS ドメインに VLV が作成されます。したがって、NIS から LDAP への移行中に、NISLDAPmapping ファイルに含まれる各 nisLDAPdomainContext 属性に対して、idsconfig を 1 回実行しなければなりません。
次の状況に適合する場合、マップ用に新しい Sun Java System Directory Server の VLV を手動で作成するか、既存の VLV インデックスをコピーして修正しなければなりません。
Sun Java System Directory Server を使用している場合
大規模なカスタムマップがあるか、非標準の DIT 位置にマップされる標準のマップがある場合
既存の VLV インデックスを表示するには、次のように入力します。
# ldapsearch -h hostname -s sub -b "cn=ldbm database,cn=plugins,cn=config" \ "objectClass=vlvSearch" |
N2L サーバーがマップをリフレッシュすると、その結果、大規模な LDAP ディレクトリアクセスが行われる場合があります。Sun Java System Directory Server が正しく構成されていない場合、リフレッシュ動作は完了前にタイムアウトになることがあります。ディレクトリサーバーのタイムアウトを防止するには、次の Sun Java System Directory Server の属性を手動で修正するか、idsconfig コマンドを実行します。
たとえば、サーバーでの検索リクエストの実行にかかる最小時間を秒単位で増やすには、次の属性を修正します。
dn: cn=config nsslapd-timelimit: -1 |
テストのためには、属性値として -1 を使用できます。この値は、制限がないことを示しています。最適な制限値が決まったら、属性値を変更します。稼働サーバーに、-1 の属性値が設定されていてはなりません。制限がないと、サーバーがサービス妨害攻撃に無防備になる場合があります。
LDAP での Sun Java System Directory Server の構成の詳細については、第 11 章LDAP クライアントと Sun Java System Directory Server の設定 (手順)を参照してください。
バッファーオーバーランを防止するには、Sun Java System Directory Server の属性を手動で修正するか、idsconfig コマンドを実行します。
たとえば、クライアント検索照会に返されるエントリの最大数を増やすには、次の属性を修正します。
dn: cn=config nsslapd-sizelimit: -1 |
クライアント検索照会で確認されるエントリの最大数を増やすには、次の属性を修正します。
dn: cn=config, cn=ldbm database, cn=plugins, cn=config nsslapd-lookthroughlimit: -1 |
テストのためには、属性値として -1 を使用できます。この値は、制限がないことを示しています。最適な制限値が決まったら、属性値を変更します。稼働サーバーに、-1 の属性値が設定されていてはなりません。制限がないと、サーバーがサービス妨害攻撃に無防備になる場合があります。
VLV を使用している場合は、sizelimit 属性値を「Sun Java System Directory Server を使用した仮想リスト表示インデックスの作成」での定義に合わせて設定する必要があります。VLV を使用していない場合、最も大きなコンテナを格納できるようにサイズ制限を設定する必要があります。
LDAP での Sun Java System Directory Server の構成の詳細については、第 11 章LDAP クライアントと Sun Java System Directory Server の設定 (手順)を参照してください。
N2L サーバーの設定が完了すると、以降 NIS ソースファイルは使用されません。したがって、N2L サーバーで ypmake を実行しないでください。既存の cron ジョブなどで誤って ypmake を実行した場合、N2L サービスは影響を受けません。ただし、yppush を明示的に呼び出すことを推奨する警告がログに記録されます。
この節では、トラブルシューティングの 2 つの領域を説明します。
N2L サーバーが LDAP 内部の問題に関連するエラーをログに記録して、LDAP 関連のエラーメッセージが表示される場合があります。エラーは致命的なものではありませんが、調査すべき問題を示しています。たとえば、N2L サーバーは動作を継続していても、返される結果が古かったり、不完全になる場合があります。
次のリストに、N2L サービスを実装するときに発生する可能性のある、よくある LDAP エラーメッセージをいくつか示します。エラーの説明、考えられる原因、およびエラーの対策も含みます。
Administrative limit exceeded
エラー番号: 11
原因 : ディレクトリサーバーの nsslapd-sizelimit 属性で許可されたものより大きな LDAP 検索が実行されました。情報の一部だけが返されます。
対策 : nsslapd-sizelimit 属性の値を増やすか、失敗した検索に VLV インデックスを実装します。
Invalid DN Syntax
エラー番号: 34
原因 : 不正な文字を含む DN を使用して LDAP エントリの書き込みが試みられました。N2L サーバーは、DN 内で生成される + 記号などの不正な文字のエスケープを試みます。
対策 : LDAP サーバーのエラーログをチェックして、どのような不正な DN が書き込まれたかを調べます。それから、不正な DN を生成した NISLDAPmapping ファイルを修正します。
Object class violation
エラー番号: 65
原因 : 無効な LDAP エントリの書き込みが試みられました。通常、次のいずれかの状況で生じる MUST 属性が見つからないことがこのエラーの原因です。
見つからない属性のエントリを作成する NISLDAPmapping ファイルのバグ
存在しないオブジェクトへの AUXILIARY 属性の追加の試み
たとえば、ユーザー名がまだ passwd.byxxx マップから作成されていない場合、そのユーザーに対する補足情報の追加の試みは失敗します。
対策 : NISLDAPmapping ファイルのバグである場合は、サーバーエラーログへの書き込みをチェックして、問題の原因を判断します。
Can't contact LDAP server
エラー番号: 81
原因 : ypserv ファイルが正しく構成されず、間違った LDAP ディレクトリサーバーを指定していることがあります。または、ディレクトリサーバーが稼働していません。
対策 :
ypserv ファイルを再構成して、正しい LDAP ディレクトリサーバーを指定します。
LDAP サーバーが実行中であることを確認するには、ディレクトリサーバーでスーパーユーザーになるか、同等の役割になり、次のように入力します。
# pgrep -l slapd |
Timeout
エラー番号: 85
原因 : LDAP 動作がタイムアウトしました。多くの場合、DIT からマップを更新している間に発生します。古い情報がマップに含まれている可能性があります。
対策 : ypserv 構成ファイルの各 nisLDAPxxxTimeout 属性を増やします (xxx の部分は何種類かある)。
N2L サーバーの実行中に、次の問題が発生する場合があります。考えられる原因と対策を説明します。
マッピングファイル NISLDAPmapping は複雑なファイルです。多くの潜在的なエラーによって、マッピングが予期しない動作をする場合があります。次の方法を用いて、この問題を解決してください。
ypserv -ir (または -Ir) を実行したときのコンソールメッセージの表示
問題 : コンソールに簡単なメッセージが表示され、サーバーが終了します (詳細な説明は、syslog に書き込まれます)。
原因 : マッピングファイルの構文が間違っている場合があります。
対策 : NISLDAPmapping ファイルの構文をチェックして修正します。
起動時に NIS デーモンが終了する
問題 : ypserv またはその他の NIS デーモンを実行すると、LDAP 関連のエラーメッセージがログに記録され、デーモンが終了します。
原因 : 原因は次のいずれかが考えられます。
LDAP サーバーと通信できない
NIS マップまたは DIT 内のエントリが、指定されたマッピングと互換性がない
LDAP サーバーへの読み書きの試みがエラーを返す
対策 : LDAP サーバーのエラーログを調査します。「よくある LDAP エラーメッセージ」にリストされた LDAP エラーを参照してください。
NIS 動作からの予期しない結果
問題 : NIS 動作が予期した結果を返さず、エラーはログに記録されません。
原因 : 間違ったエントリが LDAP または NIS マップに存在する場合があります。この結果、マッピングが期待したとおりに完了しません。
対策 : LDAP DIT と NIS マップの N2L バージョンのエントリをチェックして、修正します。
LDAP DIT に正しいエントリが存在するかをチェックしてから、必要に応じてエントリを修正します。
Sun Java System Directory Server を使用している場合は、directoryserver startconsole を実行して管理コンソールを起動します。
新しく生成されたマップと元のマップを比較して、/var/yp ディレクトリの N2L バージョンの NIS マップに期待どおりのエントリが含まれていることをチェックします。必要に応じてエントリを修正します。
# cd /var/yp/domainname # makedbm -u test.byname # makedbm -u LDAP_test.byname |
マップの出力をチェックする場合は、次のことに注意してください。
両方のファイルでのエントリの順序が異なる可能性
出力を比較する前に、sort コマンドを使用します。
両方のファイルでの空白の使い方が異なる可能性
出力を比較するときに、diff -b コマンドを使用します。
NIS マップの処理順序
問題 : オブジェクトクラス違反が発生しています。
原因 : ypserv -i コマンドを実行すると、各 NIS マップが読み取られ、その内容が DIT に書き込まれます。複数のマップが、同一の DIT オブジェクトに属性を提供する場合もあります。通常、オブジェクトは、1 つのマップによってそのオブジェクトの MUST 属性のすべてを含む大部分を生成されます。ほかのマップは、ほかの MAY 属性を提供します。
マップは、NISLDAPmapping ファイルに定義されている nisLDAPobjectDN 属性と同じ順序で処理されます。MAY 属性を含むマップが MUST 属性を含むマップより先に処理されると、オブジェクトクラス違反が発生します。このエラーについての詳細は、「よくある LDAP エラーメッセージ」のエラー 65 を参照してください。
対策 : マップが正しい順序で処理されるように、nisLDAPobjectDN 属性の順序を変更します。
一時的に問題を回避するには、ypserv -i コマンドを複数回実行します。コマンドを実行するたびに、より多くの LDAP エントリが作られます。
1 つのマップからオブジェクトのすべての MUST 属性を作成できないマッピングはサポートされていません。
問題 : サーバーがタイムアウトします。
原因 : N2L サーバーがマップをリフレッシュすると、その結果、大規模な LDAP ディレクトリアクセスが行われる場合があります。Sun Java System Directory Server が正しく構成されていない場合、この動作は完了前にタイムアウトになることがあります。
対策: ディレクトリサーバーのタイムアウトを防止するには、Sun Java System Directory Server の属性を手動で修正するか、idsconfig コマンドを実行します。詳細は、「よくある LDAP エラーメッセージ」と「Sun Java System Directory Server を使用した NIS から LDAP への移行の最良の実践原則」を参照してください。
問題 : ypserv コマンドは起動しますが、NIS リクエストに応答しません。
原因 : N2L サーバーのロックファイルが、NIS マップへのアクセスと正しく同期していません。このような状況が発生してはなりません。
# svcadm disable network/nis/server:default # rm /var/run/yp_maplock /var/run/yp_mapupdate # svcadm enable network/nis/server:default |
問題 : N2L サーバーがデッドロックします。
原因 : N2L マスターサーバーのアドレスと LDAP サーバーのアドレスが hosts、ipnodes、または ypserv ファイルに正しくリストされていない場合、デッドロックの発生することがあります。N2L の正しいアドレス構成についての詳細は、「NIS から LDAP への移行のための前提条件」を参照してください。
デッドロックの発生する例として、次の一連の事柄を考えてみてください。
NIS クライアントが IP アドレスの検索を試みます。
N2L サーバーが、hosts エントリは最新ではないことを検出します。
N2L サーバーが LDAP からの hosts エントリの更新を試みます。
N2L サーバーは、ypserv から LDAP サーバーの名前を取得してから、libldap を使用して検索を実行します。
libldap は、ネームサービススイッチを呼び出して、LDAP サーバー名の IP アドレスへの変換を試みます。
ネームサービススイッチの設定に基づき、N2L サーバーへの NIS 呼び出しを行い、デッドロックが発生します。
対策 : N2L マスターサーバー上の hosts ファイルまたは ipnodes ファイルに N2L マスターサーバーと LDAP サーバーのアドレスをリストします。hosts ファイルおよび ipnodes ファイルがローカルホスト名を解決するためにどのようにして構成されているかに応じて、サーバーアドレスは、各ファイルに、またはその両方にリストされなければなりません。また、nsswitch.conf ファイルの hosts および ipnodes エントリで、検索順序として nis の前に files をリストしていることをチェックしてください。
別の方法として、このデッドロックに対して、ypserv ファイルでホスト名ではなく LDAP サーバーアドレスを記述する方法もあります。これは、LDAP サーバーアドレスが別の場所に記述されていることを意味しています。したがって、LDAP サーバーと N2L サーバーのどちらかでアドレスを変更する場合には、さらに少し作業が必要になります。
N2L サービスを使用して NIS から LDAP に移行したサイトでは、すべての NIS クライアントを Solaris LDAP ネームサービスクライアントに徐々に置き換えていくことが求められます。最終的には、NIS クライアントに対するサポートは不要になります。ただし、必要に応じて、N2L サービスは、次の 2 つの手順に示すように、従来の NIS に復帰するための 2 種類の方法を提供します。
従来の NIS は、N2L バージョンの NIS マップが存在しても、それを無視します。NIS に戻したあとで、サーバー上の N2L バージョンのマップをそのままにしておいた場合でも問題を起こしません。したがって、あとで再度 N2L を有効にしたい場合に備えて、N2L マップを保管しておくことができます。ただし、マップの保管はディスクスペースを消費します。
スーパーユーザーになるか、同等の役割を引き受けます。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の第 9 章「役割によるアクセス制御の使用 (手順)」を参照してください。
NIS デーモンを停止します。
# svcadm disable network/nis/server:default |
N2L を無効にします。
このコマンドは、N2L マッピングファイルをバックアップして、移動します。
# mv /var/yp/NISLDAPmapping backup_filename |
NOPUSH 環境変数を設定して、ypmake によって新しいマップが転送されないようにします。
# NOPUSH=1 |
以前のソースに基づいて、NIS マップの新しいセットを作成します。
# cd /var/yp # make |
(オプション) N2L バージョンの NIS マップを削除します。
# rm /var/yp/domainname/LDAP_* |
NIS デーモンを起動します。
# svcadm enable network/nis/server:default |
この手順を実行する前に、従来の NIS ソースファイルをバックアップします。
スーパーユーザーになるか、同等の役割を引き受けます。
役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の第 9 章「役割によるアクセス制御の使用 (手順)」を参照してください。
NIS デーモンを停止します。
# svcadm disable network/nis/server:default |
DIT に基づいてマップを更新します。
# ypserv -r |
ypserv が終了するまで待ちます。
N2L を無効にします。
このコマンドは、N2L マッピングファイルをバックアップして、移動します。
# mv /var/yp/NISLDAPmapping backup_filename |
NIS ソースファイルを再生成します。
# ypmap2src |
再生成された NIS ソースファイルの内容と構造が正しいことを手動でチェックしてください。
再生成された NIS ソースファイルを適切なディレクトリに移動します。
(オプション) N2L バージョンのマッピングファイルを削除します。
# rm /var/yp/domainname/LDAP_* |
NIS デーモンを起動します。
# svcadm enable network/nis/server:default |