Sun Directory Services 3.1 管理ガイド

第 6 章ディレクトリを NIS サーバーとして使用する

ネットワーク情報システム (NIS) には、堅固で信頼性の高いネーミングサービスがあります。しかし、ある種の制約があるため、Sun Directory Services で提供される NIS サーバーに移行する方がよい場合があります。

この章では、NIS ネーミングサービスから Sun Directory Services へ移行する方法を説明します。また、NIS サービスを提供し、NIS から LDAP 情報へのマッピングを行う Sun Directory Services のデーモンについても説明します。

NIS から Sun Directory Services への移行

Sun Directory Services の NIS サーバーでは、従来の NIS ネーミングサービスが持ついくつかの制限が除かれています。

従来の NIS サーバーは、更新だけでなくテーブル全体を伝達していた。
従来の NIS サーバーでは、50,000 から 60,000 エントリに及ぶような非常に大きなテーブルは処理できなかった。

NIS 環境がすでに確立されているサイトにおいて、ネーミングサービスに影響を与えずにうまく移行する方法を図 6-1、図 6-2、および図 6-3 に示します。

図 6-1 に示す純粋な NIS 環境では、クライアントからの NIS 要求は同じネットワークにある最も近い NIS サーバーで処理されます。マスターサーバーとスレーブサーバーにある情報の同期は、NIS のテーブル伝達機能によって行われます。

図 6-1 純粋な NIS 環境

図 6-2 は、NIS スレーブを Sun Directory Services ディレクトリサーバーで段階的に置き換えた環境を示しています。マスターサーバーよりスレーブサーバーを先に置き換えることをお勧めします。これは、変更の影響がネットワーク全体ではなく、一部のクライアントだけに限定されるためです。また、この間に新しいツールへの手順を検証できます。最終的には NIS マスターサーバーを Sun Directory Services に移行できます。

この段階では、ローカルスレーブサーバーは LDAP クライアントを同時にサポートします。複製には引き続き NIS を使用しなければなりません。

図 6-2 NIS と Sun Directory Services が混在した環境

図 6-3 は、従来の NIS サーバーをすべて Sun Directory Services で置き換えた環境を示しています。これらのサーバーでは NIS 要求と LDAP 要求がサポートされます。マスターサーバーとスレーブサーバーの間では LDAP 複製を使用してください。

図 6-3 Sun Directory Services 環境

NIS 機能と LDAP 機能の対応

Sun Directory Services により、NIS と同じレベルのサービスを提供できます。表 6-1 は、標準の NIS 機能が Sun Directory Services でどのように実現されているかを示します。

表 6-1 NIS 機能と LDAP 機能の対応


Sun Directory Services	従来の NIS	NIS サービス
`dsservd`	`ypserv`	NIS 要求に応答するサーバープロセス
`dsyppasswdd`	`rpc.yppasswdd`	NIS `passwd` テーブルを変更するためのデーモン
`dsypxfrd`	`ypxfrd`	NIS テーブルを転送してマスターサーバーとスレーブサーバーを同期させるデーモン
`dsyppush`	`yppush`	更新をスレーブサーバーに伝達するときにマスターサーバーで使用するコマンド
`dsypxfr`	`ypxfr`	更新を NIS マスターに要求するときにスレーブの NIS サーバーで使用するコマンド
`dsmakedbm`	`makedbm`	標準ファイルから NIS テーブルを作成するプロセス
`dsypinit`	`ypinit`	NIS クライアント、NIS マスターサーバー、NIS スレーブサーバーを初期設定するプロセス
`dsyprsvd`	`rpc.nisd_resolv`	DNS アクセス

dsservd

dsservd デーモンは、NIS デーモン ypserv と同じようにして NIS 要求を受信し、応答します。このデーモンは NIS をネイティブモードでサポートするので、NIS 要求を LDAP 要求に変換したり、LDAP 応答を NIS 応答に変換したりすることはありません。

さらに、dsservd デーモンは NIS テーブルの最新コピーを維持しているので、伝達要求は高速に処理されます。このデーモンは、/etc/opt/SUNWconn/ldap/current/mapping/nis.mapping ファイルのマッピング情報に基づいてディレクトリ情報を NIS テーブルに変換します。

dsservd デーモンの構成方法については、dsservd(8) のマニュアルページを参照してください。

注 -

dsservd デーモンは LDAP サーバーでもあります。

dsyppasswdd

dsyppasswdd デーモンは、LDAP ディレクトリに格納されているパスワードテーブルの変更を管理します。このデーモンはマスターサーバーで動作し、passwd コマンドでパスワード、(gecos フィールドの) 記述全体、またはシェルを変更するユーザーの要求に応答します。dsyppasswdd デーモンは、LDAP データベースだけでなく、NIS passwd ファイルも更新します。さらに、shadow ファイルがある場合は、このファイルも更新します。

dsyppasswdd デーモンの構成方法については、dsyppasswdd(8) のマニュアルページを参照してください。

dsypxfrd

dsypxfrd デーモンは、従来の NIS 環境において、マスターサーバーからスレーブサーバーへの NIS テーブルの伝達を管理します。このデーモンは、NIS 情報の LDAP 複製は管理しません。このプロセスはマスターサーバーだけで動作します。

dsypxfrd デーモンは、NIS 環境の ypxfrd デーモンと同じように動作します。つまり、スレーブサーバーで動作する dsypxfrd プロセスからの要求を待ち、要求されたテーブルを配信します。dsservd デーモンは、処理を速くするためにすべての NIS テーブルの最新コピーを持っています。したがって、NIS テーブルを転送する前に、それらのテーブルを LDAP ディレクトリの情報から作成する必要はありません。

dsypxfrd の構成方法については、dsypxfrd(1M) のマニュアルページを参照してください。

dsyppush

dsyppush コマンドは、更新を NIS スレーブサーバーに伝達するときにマスターサーバーで使用します。このデーモンは、/var/yp にある NIS Makefile によって呼び出されます。さらに、管理コンソールで「自動配信 (Autopush)」オプションが有効に設定されていれば、ディレクトリが変更されると、このデーモンが自動的に起動されます。

詳細は、dsyppush(1M) のマニュアルページを参照してください。

dsypxfr

dsypxfr コマンドは、更新を NIS マスターサーバーに要求するときにスレーブサーバーで使用します。このコマンドは、マスターサーバーで動作しローカルデータベースを更新する dsypxfrd デーモンを呼び出します。この更新は、標準の NIS 伝達を使って行われます。

詳細は、dsypxfr(1M) のマニュアルページを参照してください。

dsmakedbm

dsmakedbm コマンドは、NIS ソースファイルに格納されている情報から NIS テーブルを作成します。このコマンドは、dsimport ユーティリティを呼び出して、ディレクトリに NIS エントリを作成するという点が NIS の標準の makedbm とは少し異なります。

dsypinit

dsypinit コマンドは、NIS サーバーをマスターサーバーやスレーブサーバーとして宣言または初期設定するときに使用します。NIS の標準の ypinit コマンドの代わりに、このコマンドで NIS クライアントを初期設定することもできます。

詳細は、dsypinit(1M) のマニュアルページを参照してください。

注 -

NIS サービスの初期設定には dsypinit を使用しないでください。初期設定の場合には、「NIS サービスを初期設定するには」の dsypinstall を使用してください。

dsyprsvd

dsyprsvd デーモンは、要求されたホスト情報がディレクトリの NIS エントリにない場合は DNS サーバーに連絡します。このデーモンが動作するのは、NIS サーバーが DNS 相互運用モードで動作するように構成されている場合だけです。この指定は、NIS 初期設定スクリプト dsypinstall のプロンプトに対して入力します。

詳細は、dsyprsvd(1M)のマニュアルページを参照してください。

Sun Directory Services の NIS サービスの初期設定

Sun Directory Services の NIS サービスでは、既存の NIS 環境が保持されます。標準の NIS 環境がカスタマイズされている場合は、その設定が引き続き有効です。初期設定プロセスでは、make プロセスが NIS の標準の makedbm コマンドの代わりに dsmakedbm と dsimport を呼び出すように、既存の NIS Makefile が変更されます。さらに、yppush の代わりに dsyppush を使用するように変更されます。

Sun Directory Services の NIS サービスでは、ドメイン構成要素 (dc) ネーミング構造を使用することによって、NIS ドメイン名を LDAP ディレクトリツリーにマップできます。たとえば、sales.XYZ.com ドメインに関連する情報は、LDAP ディレクトリのサブツリー dc=sales, dc=XYZ, dc=com の下に格納できます。

NIS サービスを初期設定するには

Sun Directory Services をインストールし、ライセンスを取得します。

これらの作業については、『Sun Directory Services 3.1 ご使用にあたって』を参照してください。

パッケージのインストールが完了すると、dsypinstall スクリプトを実行して NIS サービスを初期設定する必要があるという内容のメッセージが表示されます。しかし、作業を実行する前にここで説明する構成手順に従ってください。

管理コンソールを起動します。

この手順については、「管理コンソールの表示」を参照してください。

NIS 情報を格納するための名前付きコンテキストを作成します。

作成する名前付きコンテキストは、サーバーが管理するドメインに対応するドメイン構成要素 (DC) ツリー接尾辞を持っていなければなりません。初期設定スクリプトでは、指定する NIS ドメイン名から NIS エントリの名前付きコンテキストが選択されます。たとえば、ドメイン名として sales.XYZ.com と指定する場合は、dc=XYZ, dc=com 書式の名前付きコンテキストが必要です。

また、nis.mapping ファイルを変更して、NIS ドメイン名から作られるデフォルトの DC 構造とは異なるネーミング構造を指定することもできます。詳細は、「名前付きコンテキストの構成」を参照してください。

名前付きコンテキストの作成方法については、「データ格納を作成するには」を参照してください。

現在の NIS ファイルとデータベースのバックアップをとります。

スーパーユーザー (root) として dsypinstall を実行します。
```
# /opt/SUNWconn/sbin/dsypinstall
```
dsypinstall スクリプトでは、Makefile は /var/yp にあるとします。さらに、NIS テーブルのすべてのソースファイルは、プロンプトで指定するディレクトリにあるとします。ただし、aliases ファイルだけは /etc/mail にあるとします。

プロンプトに対し、サーバーが管理する NIS ドメイン名と、DSN 相互運用性を使用するかどうかを指定します。

dsypinstall スクリプトが正常に終了すれば、NIS サーバーは初期設定され、LDAP ディレクトリデータベースには NIS テーブルから抽出された情報が入ります。

管理コンソールに表示される NIS の状態を確認します。

dsypinstall スクリプトを実行する前に管理コンソールが動作している場合は、「状態 (Status)」セクションの「状態を検査 (Check Status)」をクリックして現在の状態を表示します。

「状態 (Status)」セクションには、NIS サービスが「動作中 (Running)」、自動再起動が「有効 (Enabled)」と表示されます。「NIS」セクションには、dsypinstall による初期設定でサーバーをどのように宣言したかによって、NIS の機能的役割が「NIS マスターサーバー (NIS master server)」か「NIS スレーブサーバー (NIS slave server)」として表示されます。さらに、「NIS」セクションには、そのサーバーがサポートするすべての NIS マップのリストも表示されます。

サーバーで dejasync を実行します。スーパーユーザー (root) として次のように入力します。
```
# /opt/SUNWconn/ldap/sbin/dejasync
```
コマンドのオプションの詳細は、dejasync(1M) のマニュアルページを参照してください。Deja ツールを使ってディレクトリの NIS エントリを変更する場合は、dejasync を実行する必要があります。

NIS 情報を LDAP ディレクトリにインポートおよび格納する方法については、「LDAP ディレクトリの NIS 情報」を参照してください。

NIS サービスの構成

管理コンソールから NIS サービスに対し次のパラメータを構成できます。

NIS ドメイン名
NIS の管理エントリが入るサブツリーの識別名。これらのエントリは、サーバーが自動的に管理します。
標準の NIS 複製を使用するかどうか
すべてのディレクトリエントリを組み込むかどうか。このオプションを指定すると、NIS マップを再生成することによって、NIS サービスを最初に初期設定する前にディレクトリにあったすべてのエントリを組み込むことができます。これらのエントリは、NIS サービスを初期設定する際のインポート操作では組み込まれません。さらに、nis.mapping ファイルに定義されているマッピング構成を変更したときにも、このオプションを使ってディレクトリ内の NIS マップを再生成する必要があります。
サーバーでどのマップをサポートするか
このサーバーで NIS エントリが変更されたときに更新情報をスレーブサーバーに自動的に配信するかどうかと遅延。このオプションを使用する場合は、標準の NIS 複製を有効にしなければなりません。

これらのパラメータを構成するには、管理コンソールメインウィンドウの「NIS」セクションを使用します。

NIS テーブルの更新

ディレクトリを最初に作成したら、2 つの方法でデータの保守を実行できます。

NIS ファイルを更新し、/var/yp ディレクトリで make を実行する
Deja ツールなどを使って、ディレクトリのエントリを更新する

NIS 情報を保守する方法としては、ディレクトリのエントリを更新するのが最も効率的ですが、ディレクトリの内容と NIS ファイルの内容は同期しなくなります。これらを同期させるには、dsexport を使ってディレクトリのエントリを対応する NIS ファイルにエクスポートする必要があります。詳細は、dsexport(1M) のマニュアルページを参照してください。

NIS マップは、ディレクトリのエントリから定期的に再生成されます。ただし、管理コンソールの「マップを再生成 (Regenerate Map)」機能でいつでもマップを再作成できます。この機能では、NIS ソースファイルではなく、ディレクトリに格納されているエントリだけが使われます。ディレクトリのエントリから NIS マップを生成するには、次の手順を実行します。

管理コンソールの「NIS」セクションで、マップリストからマップを選択して強調表示します。

(省略可能)「既存の LDAP エントリを含める (Include existing LDAP entries)」オプションを「はい (yes)」に設定します。

NIS サービスの初期設定後にマップをすぐに再生成する場合や、nis.mapping ファイルで特定のマップのマッピング定義を変更した場合は、この方法が便利です。

「マップを再生成 (Regenerate Map)」ボタンをクリックします。

注 -
ディレクトリサーバーが維持する NIS マップに NIS サービスの初期設定前に存在したエントリを組み込む場合は、これらのエントリが NIS サービスにとってセキュリティ上危険とならないよう注意が必要です。たとえば、ユーザーは自身のディレクトリエントリに対し書き込みアクセス権を持っているため、ユーザーが uid 属性を変更して root ユーザーになることが可能です。

NIS テーブルの伝達

マスターサーバーとスレーブサーバーの間で NIS テーブルを伝達するには 2 つの方法があります。2 つの Sun Directory Services サーバー間で行う場合は、LDAP 複製を選択します。Sun Directory Services サーバーと従来の NIS サーバーの場合は、標準の NIS 複製を使用する必要があります。

注 -

同じサブツリーや個別のエントリに対し LDAP 複製と NIS 複製を両方とも使用することはできません。原則として、2 つのサーバー間では 1 つの複製方式を使用してください。

標準の NIS 複製

ディレクトリの NIS エントリの代わりに NIS ファイルを更新する場合、make で NIS テーブルを再作成すると、dsyppush コマンドが自動的に実行されます。

LDAP 複製

ディレクトリの NIS エントリを更新する場合には、すべてのマップが自動的に配信されるように管理コンソールから指定できます。また、「複製を同期 (Synchronize replicas)」ボタンを使えば、選択したマップだけをいつでも配信できます。

LDAP 複製の構成方法については、第 9 章「複製の実装」を参照してください。

LDAP ディレクトリの NIS 情報

LDAP ディレクトリにインポートする NIS 情報は、標準の NIS ファイルやユーザー独自のファイルから抽出します。Sun Directory Services では、標準の NIS 情報から LDAP 属性へマッピングが可能です。デフォルトの nis.mapping ファイルには、次の NIS ファイルの情報をマッピングする方法が記載されています。

aliases
bootparams
ethers
group
hosts
netgroup
networks
passwd
protocols
rpc
ypservers

デフォルトの nis.mapping ファイルには、次の標準 NIS ファイルと、NIS Makefile にリストされている独自の NIS ファイルに対するマッピング定義はありません。これらのファイルに対するマッピング定義は、dsypinstall を実行して NIS サービスを初期設定すると自動的に作成されます。

auto_home
auto_master
netid
netmasks
publickey
services
timezone

これらのファイルと独自のファイルに対するマッピング定義は総称的なもので、どのマップでも同じです。違いはマップ名だけです。

表 6-2 は、LDAP エントリの種類と場所を NIS マップごとに示します。nis.mapping ファイルのマッピング定義を構成する方法については、「NIS 情報のマッピング」を参照してください。

表 6-2 NIS または LDAP マッピングの要約


NIS ソースファイル	NIS マップ	作成されるエントリのオブジェクトクラス	作成されるエントリの名前付きコンテキスト
`/etc/mail/aliases`	mail.aliases, mail.byaddr	nisMailAlias	ou=Aliases, ou=Services
`/etc/bootparams`	bootparams	bootableDevice	ou=Hosts, ou=Services
`/etc/ethers`	ethers.byaddr, ethers.byname	ieee802Device	ou=Hosts, ou=Services
`/etc/group`	group,byname, group.bygid	posixGroup	ou=Group, ou=Services
`/etc/hosts`	hosts.byaddr, hosts.byname	ipHost	ou=Hosts, ou=Services
`/etc/netgroup`	netgroup	nisNetGroup	ou=Netgroup, ou=Services
	netgroup.byhost	nisObject	ou=netgroup.byhost, ou=Services
	netgroup.byuser	nisObject	ou=netgroup.byuser, ou=Services
`/etc/networks`	networks.byname, networks.byaddr	ipNetwork	ou=Networks, ou=Services
`/etc/passwd`	passwd.byname, passwd.byuid	posixAccount	ou=People
`/etc/protocols`	protocols.byname, protocols.bynumber	ipProtocol	ou=Protocols, ou=Services
`/etc/rpc`	rpc.bynumber	oncRpc	ou=rpc, ou=Services
`/var/yp/binding/domainName`	ypservers	sunNisServer	ou=ypservers, ou=Services
`makefile` にリストされているその他のすべてのマップ	`mapName`	nisObject	ou=`mapName`, ou=Services

NIS 名前付きコンテキスト

LDAP ディレクトリにインポートされる情報は、NIS の初期設定段階で、図 6-4 のツリー構造に従って編成されます。この図で ou=mapName は、nis.mapping ファイルに定義されていないマップ (たとえば、services.byname) を表します。

図 6-4 NIS 情報のツリー構造

このツリー構造を必要に応じて構成するには、マッピングファイル /etc/opt/SUNWconn/ldap/current/mapping/nis.mapping を変更します。

NIS 情報のマッピング

NIS テーブルのエントリから LDAP 属性へマッピングするための情報は、/etc/opt/SUNWconn/ldap/current/mapping/nis.mapping ファイルに定義します。このファイルは、各 NIS テーブルのマッピング情報を定義する個別のセクションに分割されます。ファイルの始めには構成情報を定義する「Common」セクションがあり、すべてのテーブルに適用されます。

nis.mapping ファイルは、次の構成要素によって使用されます。

dsimport ユーティリティ。NIS ファイルから情報を抽出し、LDAP ディレクトリのエントリに変換する場合
dsexport ユーティリティ。LDAP エントリから情報を抽出し、NIS ファイルを元の書式で復元する場合
dsservd デーモン。LDAP エントリを NIS テーブルのエントリに変換する場合。dsservd デーモンは、LDAP データベースにあるすべての NIS テーブルの最新コピーを維持し、従来の NIS スレーブからの同期要求に応じます。
dsypxfrd デーモン。同期要求で指定されたテーブルがマッピングファイルでサポートされているかどうかを検査する場合

nis.mapping ファイルのマッピング定義では、次の項目を指定します。

ディレクトリにエントリを作成する場合に使われるオブジェクトクラスと属性
エントリがその下に作成される名前付きコンテキスト
エントリの検索でディレクトリサーバーが大文字と小文字を区別するかどうか

オブジェクトクラスと属性

NIS ファイルから作成するエントリのオブジェクトクラスと属性は、そのテーブル用のマッピング定義の「Import」または「Build」セクションにリストされます。「Build」セクションの LDAP 属性に割り当てる値は、テーブル定義の他のセクションに指定したトークンからとられます。

NIS Makefile にリストされているファイルのうち、nis.mapping ファイルに特定のマッピング定義がないものには、総称マッピングが適用されます。このマッピングでは、ファイルから NIS キーと NIS 値の情報が抽出され、次の総称的な NISobject オブジェクトクラスに基づいて次のようにエントリが作成されます。

cn	nisKey (LDAP 検索で大文字と小文字を区別する)
sunNisKey	nisKey
nisMapEntry	nisValue
nisMapName	`makefile` で宣言されたマップ名
objectClass	top
objectClass	nisSunObject

マッピングファイルに記述されたすべての標準 NIS テーブルに対して作成されるオブジェクトクラスと属性を次に示します。ここでは、aliases ファイルのマッピングだけを詳しく説明します。

aliases

aliases ファイルのエントリは、通常、次の書式になっています。

aliasname: mailaddress1, mailaddress2, mailaddress3...

nis.mapping ファイルでは、この行のマッピングは次のようになっています。

Table: mail.aliases
...
Import:
	Extract:
		LINE =>$aliasNameT:$aliasListT
	Condense:
		rfc822mailMembersT=string2instances($aliasListT,",")
		trimrfc822mailMembersT=trim($rfc822mailMembersT)
		objectClassT=string2instances("top nisMailAlias", " ")
	Build:
		dn=cn=$aliasNameT,$BASE_DN
		cn=$aliasNameT
		rfc822mailMember=$trimrfc822mailMembersT
		objectClass=$objectClassT

「Extract」セクションのキーワード LINE は、aliases ファイルの行の初期分解を表します。aliases ファイルでコロン以外の句読記号で別名と別名リストを区切っている場合は、ファイル書式に合わせて LINE 定義を変更する必要があります。

「Condense」セクションの rfc822mailMembersT のトークン定義では、別名リストの次の段階の分解を行います。aliases ファイルでコンマ以外の句読記号で別名リストの各要素を区切っている場合は、ファイル書式に合わせてトークン定義を変更する必要があります。

trimrfc822mailMemberT のトークン定義では、別名リストに対して前に行なった string2instances 操作の結果から不要な空白を取り除きます。

objectClassT のトークン定義では、nisMailAlias オブジェクトクラスの継承階層を指定します。

「Build」セクションでは、cn 属性と属性値を BASE_DN トークンと結合してエントリの識別名を作成します。BASE_DN トークンは、そのエントリを入れる名前付きコンテキストを表します。

rfc822mailMember 属性と objectClass 属性には複数の値が入ります。string2instances 操作によって得られた各値に対し、これらの属性が 1 つ発生します。

たとえば、ドメイン France.XYZ.com の aliases ファイルに次の行があるとします。

dir-team: pdurand, jdupond, asantini, msmith, dphilippe, smartin

aliases ファイルのこの行から作成されるディレクトリエントリの識別名は、cn=dir-team, ou=Aliases, ou=Services, dc=France, dc=XYZ, dc=com です。このエントリとして格納される属性とその値は、次のようになります。

cn	dir-team
rfc822mailMember	pdurand
	jdupond
	asantini
	msmith
	dphilippe
	smartin
objectClass	top
objectClass	nisMailAlias

bootparams

bootparams ファイルのエントリは、通常、次の書式になっています。

hostname	 parameter1 parameter2 parameter3...parameterx

たとえば、France.XYZ.com ドメインの bootparams ファイルに次の行があるとします。

camembert	root=server1:/export/camembert/root ¥
		swap=server1:/export/camembert/swap ¥
	domain=France.XYZ.com

bootparams ファイルのこの行から作成されるディレクトリエントリの識別名は、cn=camembert, ou=Host, ou=Services, dc=France, dc=XYZ, dc=com です。このエントリとして格納される属性とその値は、次のようになります。

cn	camembert
bootParameter	root=server1:/export/roquefort/root
	swap=server1:/export/roquefort/swap
	domain=France.XYZ.com
objectClass	top
	device
	bootableDevice

ホスト camembert には、/etc/ethers と /etc/hosts にもエントリがあります。しかし、LDAP ディレクトリでは、ホスト camembert のエントリは 1 つだけで、他のすべての属性は ethers テーブルマッピングと hosts テーブルマッピングから派生したものです。ホスト camembert 用に作成された LDAP ディレクトリには、いくつかのオブジェクトクラスがあります。このうち、1 つは継承した構造体オブジェクトクラス device で、3 つは補助オブジェクトクラス bootableDevice、ieee802Device、ipHost です。

「ethers」と「hosts」の例の場合、LDAP ディレクトリに作成されるホスト camembert の完全なエントリは、次のようになります。

cn	camembert
cn	bertie
bootParameter	root=server1:/export/roquefort/root
	swap=server1:/export/roquefort/swap
	domain=France.XYZ.com
macAddress	0:1:23:aa:bb:cc
ipHostNumber	123.456.789.1
description	SS5 Pierre's Desktop
objectClass	top
	device
	bootableDevice
	ieee802Device
	ipHost

bootparams ファイルから camembert のエントリを削除すると、camembert のディレクトリエントリが更新され、bootableDevice オブジェクトクラスとそのオブジェクトクラス固有の bootParameter 属性が削除されます。

ethers

ethers ファイルのエントリは、通常、次の書式になっています。

ethernetaddress	machinename

たとえば、ドメイン France.XYZ.com の ethers ファイルに次の行があるとします。

0:1:23:aa:bb:cc	camembert

ethers ファイルのこの行から作成されるディレクトリエントリの識別名は、cn=camembert, ou=Hosts, ou=Services, dc=France, dc=XYZ, dc=com です。このエントリとして格納される属性とその値は次のようになります。

cn	camembert
macAddress	0:1:23:aa:bb:cc
objectClass	top
	device
	ieee802Device

ホスト camembert には /etc/bootparams ファイルと /etc/hosts ファイルにもエントリがある場合があります。これらのファイルから作成される LDAP ディレクトリの完全なエントリの詳細は、「bootparams」を参照してください。

group

group ファイルのエントリは、通常、次の書式になっています。

groupname:password:groupidnumber:listofmembers

たとえば、ドメイン France.XYZ.com の group ファイルに次の行があるとします。

sysadmin:yai957KJwXrjc:10:bgreen, hgrant, dbrown

group ファイルのこの行から作成されるディレクトリエントリの識別名は、cn=sysadmin, ou=Group, ou=Services, dc=France, dc=XYZ, dc=com です。このエントリとして格納される属性とその値は次のようになります。

cn	sysadmin
gidNumber	10
memberUid	bgreen
	hgrant
	dbrown
userPassword	{crypt}yai957KJwXrjc
objectClass	top
objectClass	posixGroup

hosts

hosts ファイルのエントリは、通常、次の書式になっています。

ipaddress hostname hostaliasnames #hostdescription

たとえば、ドメイン France.XYZ.com の hosts ファイルに次の行があるとします。

123.456.789.1	camembert	bertie	# SS5 Pierre's Desktop

hosts ファイルのこの行から作成されるディレクトリエントリの識別名は、cn=camembert, ou=Hosts, ou=Services, dc=France, dc=XYZ, dc=com です。このエントリとして格納される属性とその値は次のようになります。

cn	camembert
cn	bertie
ipHostNumber	123.456.789.1
description	SS5 Pierre's Desktop
objectClass	top
	device
	ipHost

ホスト camembert には /etc/bootparams ファイルと /etc/ethers ファイルにもエントリがある場合があります。これらのファイルから作成される LDAP ディレクトリの完全なエントリの詳細は、「bootparams」を参照してください。

netgroup

netgroup ファイルのエントリは、通常、次の書式になっています。

netgroupname	grouptriple	grouptriple	grouptriple	grouptriple

grouptriple の書式は (hostname, username, domainname) です。

たとえば、ドメイン France.XYZ.com の netgroup ファイルに次の行があるとします。

printers¥
	(bordeaux,-,France.XYZ.com)¥
	(bourgogne,-,France.XYZ.com)¥
	(sauternes,-,France.XYZ.com)

netgroup ファイルのこの行から作成されるディレクトリエントリの識別名は、cn=printers, ou=netgroup, ou=Services, dc=France, dc=XYZ, dc=com です。このエントリとして格納される属性とその値は次のようになります。

cn	printers
nisNetGroupTriple	bordeaux,-,France.XYZ.com
	bourgogne,-,France.XYZ.com
	sauternes,-,France.XYZ.com
objectClass	top
objectClass	nisNetGroup

networks

networks ファイルのエントリは、通常、次の書式になっています。

networkname	networkaddress	networkalias	#description

たとえば、ドメイン France.XYZ.com の networks ファイルに次の行があるとします。

XYZ-eng	123.456.789	eng	#engineering subnetwork

networks ファイルのこの行から作成されるディレクトリエントリの識別名は、cn=XYZ-eng, ou=networks, ou=Services, dc=France, dc=XYZ, dc=com です。このエントリとして格納される属性とその値は次のようになります。

cn	XYZ-eng
cn	eng
ipNetworkNumber	123.456.789
description	engineering subnetwork
objectClass	top
objectClass	ipNetwork

passwd

passwd ファイルのエントリは、通常、次の書式になっています。

userid:userPasswd:uidnumber:gidnumber:gecos:homeDir:shell

passwd ファイルに関連付けられた shadow ファイルがある場合、そのファイルの書式は、通常、次のようになっています。

userid:userPasswd:::::::

passwd ファイルと shadow ファイルのユーザー ID は同じですが、ユーザーのパスワードは、実際には passwd ファイルではなく shadow ファイルに格納されます。

たとえば、ドメイン France.XYZ.com の passwd ファイルに Pierre Durand に対する次の行があるとします。

pdurand:x:12345:67:Pierre Durand - Project Manager:/home/pdurand:/bin/csh

ユーザーパスワードの代わりに x があるのは、実際のパスワードが shadow ファイルに格納されていることを示します。shadow ファイルには、Pierre Durand に対し次の行があります。

pdurand:yai957KJwXrjc:::::::

passwd ファイルと shadow ファイルのこれらの行から作成されるディレクトリエントリの識別名は、uid=pdurand, ou=People, dc=France, dc=XYZ, dc=com です。このエントリとして格納される属性とその値は次のようになります。

cn	Pierre Durand
uid	pdurand
userPassword	{crypt}yai957KJwXrjc
uidNumber	12345
gidNumber	67
gecos	Pierre Durand - Project Manager
homeDirectory	/home/pdurand
loginshell	/bin/csh
objectClass	top
	account
	posixAccount

protocols

protocols ファイルのエントリは、通常、次の書式になっています。

protocolname	protocolnumber 	protocolalias		#description

たとえば、ドメイン France.XYZ.com の protocols ファイルに次の行があるとします。

tcp	0	TCP_Protocol 	#Transmission Control Protocol

protocols ファイルのこの行から作成されるディレクトリエントリの識別名は、ou=protocols, ou=Services, dc=France, dc=XYZ, dc=com です。このエントリとして格納される属性とその値は次のようになります。

cn	tcp
cn	TCP_Protocol
ipProtocolNumber	0
description	Transmission Control Protocol
objectClass	top
objectClass	ipProtocol

rpc

rpc ファイルのエントリは、通常、次の書式になっています。

programname	programnumber	protocolalias	#description

たとえば、ドメイン France.XYZ.com の rpc ファイルに次の行があるとします。

yppasswdd	100123	yppasswd

rpc ファイルのこの行から作成されるディレクトリエントリの識別名は、cn=yppasswdd, ou=rpc, ou=Services, dc=France, dc=XYZ, dc=com です。このエントリとして格納される属性とその値は次のようになります。

cn	yppasswdd
cn	yppasswd
oncRpcNumber	100123
objectClass	top
objectClass	oncRpc

ypservers

NIS 環境では、ドメインの NIS サーバーのリストが ypservers ファイルに入っています。

たとえば、ドメイン France.XYZ.com の ypservers ファイルに次のリストがあるとします。

brie
camembert
emmental
gorgonzola
roquefort

このファイルにリストされているサーバーごとにディレクトリエントリが作成されます。たとえば、サーバー brie 用に作成されるエントリの識別名は、cn=brie, ou=ypservers, ou=Services, dc=France, dc=XYZ, dc=com になります。また、サーバー brie のエントリは次のようになります。

cn	brie
objectClass	top
objectClass	sunNisServer

NIS 情報に対する ACL

LDAP ディレクトリの NIS 情報は、特別な ACL のセットで保護されます。これらの ACL は dsserv.acl.conf ファイルに入っています。このファイルの一部を次に示します。

# NIS ACLs
access to attrs=userPassword
        by self write
        by * compare

access to attrs=gecos,loginShell
        by self write

デフォルトでは、ユーザーは自分のエントリのすべての属性に対し読み込みアクセス権を持っているが、書き込みアクセス権があるのは、userPassword、gecos、loginShell 属性に対してだけです。

名前付きコンテキストの構成

NIS サービスの初期設定で NIS エントリ用に作成する名前付きコンテキストは、nis.mapping ファイルにキーワード BASE_DN で指定します。この基本識別名は、各マップに固有の組織単位 (ou) と通常いくつかのマップに共通の rootTree トークンとを結合したものです。

たとえば、networks マップから作成するエントリ用の名前付きコンテキストは、nis.mapping ファイルの次の 2 つの行で定義します。

rootTreeT=ou=Services,$NAMING_SUFFIX||ou=Services,$DC_NAMING
BASE_DN=ou=Networks,$rootTreeT

networks ファイルから作成するディレクトリエントリは、ou=Networks, ou=Services の名前付きコンテキストに作成されます。

ネーミング構造として NAMING_SUFFIX キーワードを選択するか、DC_NAMING キーワードを選択するかは構成で指定します。DC_NAMING キーワードではドメイン構成要素 (DC) 接尾辞を使用します。このネーミング構造でエントリを作成すると、その識別名の接尾辞は dc=XYZ, dc=com の書式になります。インポートプロセスでは dsypinstall プロセスで指定するドメイン名から DC ネーミング接尾辞がとられるため、NIS サービスを初期設定するときのネーミング構造には、デフォルトでこの方法が使用されます。

これとは異なる接尾辞を使用する場合は、nis.mapping ファイルの始めにあるフロントエンドの「Common」セクションで、NAMING_SUFFIX キーワードのコメントを解除する必要があります。NAMING_SUFFIX キーワードの値を変更して、NIS エントリを作成する接尾辞または名前付きコンテキストを指定します。指定する値は、データ格納にある有効な名前付きコンテキストでなければなりません。名前付きコンテキストの作成方法については、「データ格納の作成と変更」を参照してください。

nis.mapping ファイルの DOMAIN_NAME キーワードはコメント化しないでください。このキーワードには、dsypinstall プロセスで指定したドメイン名が入っています。これは、サーバーが NIS サービスを行うときに使用します。

大文字と小文字の区別

通常、検索を行う属性に大文字と小文字の区別があれは (ces 構文)、ディレクトリサーバーは大文字と小文字を区別して検索します。同様に、検索を行う属性に大文字と小文字の区別がなければ (cis 構文)、検索する際に大文字と小文字は区別されません。

しかし、nis.mapping ファイルでテーブルのマッピング定義にキーワード CASE_SENSITIVE=yes を指定すれば、属性構文に対し大文字と小文字の区別を強制的に適用できます。

たとえば、uid 属性が cis 構文を持っている場合、セキュリティのために大文字と小文字の区別を強制する必要があります。したがって、nis.mapping ファイルの passwd.byname 定義には、CASE_SENSITIVE キーワードが指定されています。

Table: passwd.byname

	Common:
		MAP_NAME=passwd.byname
		# The LDAP attribute used to store the key (uid) is case insensitive!
		CASE_SENSITIVE=yes

第 6 章 ディレクトリを NIS サーバーとして使用する

NIS から Sun Directory Services への移行

図 6-1 純粋な NIS 環境

図 6-2 NIS と Sun Directory Services が混在した環境

図 6-3 Sun Directory Services 環境

NIS 機能と LDAP 機能の対応

dsservd

dsyppasswdd

dsypxfrd

dsyppush

dsypxfr

dsmakedbm

dsypinit

dsyprsvd

Sun Directory Services の NIS サービスの初期設定

NIS サービスを初期設定するには

NIS サービスの構成

NIS テーブルの更新

NIS テーブルの伝達

標準の NIS 複製

LDAP 複製

LDAP ディレクトリの NIS 情報

NIS 名前付きコンテキスト

図 6-4 NIS 情報のツリー構造

NIS 情報のマッピング

オブジェクトクラスと属性

aliases

bootparams

ethers

group

hosts

netgroup

networks

passwd

protocols

rpc

ypservers

NIS 情報に対する ACL

名前付きコンテキストの構成

大文字と小文字の区別

第 6 章ディレクトリを NIS サーバーとして使用する