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 マッピングは無視されます。