test

Solaris のシステム管理 (ネーミングとディレクトリサービス : NIS+ 編)

第 18 章 NIS+ ディレクトリの管理

この章では、NIS+ ディレクトリオブジェクトとその管理方法について説明します。

注 –

NIS+ は、将来のリリースではサポートされなくなる可能性があります。NIS+ から LDAP への移行支援ツールは、Solaris 9 リリース以降で使用できます (『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照)。詳細については、http://www.sun.com/directory/nisplus/transition.html を参照してください。

NIS+ ディレクトリ

NIS+ ディレクトリオブジェクトは、NIS+ ドメインに関連する情報の格納に使用されます。NIS+ ドメインには、それぞれ NIS+ ディレクトリ構造が関連付けられます。NIS+ ディレクトリの詳細については、第 2 章「NIS+ の紹介」を参照してください。

NIS+ ディレクトリ関連のコマンドとその構文、オプションについては、nis+(1) のマニュアルページを参照してください。

ディレクトリについて niscat コマンドを使用する

niscat -o コマンドを使えば、NIS+ ディレクトリのオブジェクト属性を表示できます。このコマンドを使うには、ディレクトリオブジェクトの読み取り権が必要です。

ディレクトリのオブジェクト属性を表示する

ディレクトリのオブジェクト属性を表示するには、niscat -o とディレクトリ名を使います。


niscat -o directory-name

たとえば、以下のようになります。


rootmaster# niscat -o doc.com.
Object Name : doc
Owner : rootmaster.doc.com.
Group :
Domain : Com.
Access Rights : r---rmcdr---r---
Time to Live : 24:0:0
Object Type : DIRECTORY
.
.

nisls コマンドでディレクトリを表示する

nisls コマンドは、NIS+ ディレクトリの内容を表示します。このコマンドを使うには、ディレクトリオブジェクトに対する読み取り権が必要です。

簡潔形式での表示


nisls [-dgLmMR] directory-name

詳細形式での表示


nisls -l [-gm] [-dLMR] directory-name
表 18–1 nisls コマンドのオプション

オプション 

目的 

-d

ディレクトリオブジェクト。ディレクトリの内容を表示するのではなく、別のオブジェクトのように扱う 

-L

リンク。ディレクトリ名が実際にはリンクである場合、コマンドはリンクをたどり、リンクされたディレクトリの情報を表示する 

-M

マスター。マスターサーバーだけから情報を取得する。これによって最新の情報が得られるが、マスターサーバーが使用中の場合は長時間を要することがある 

-R

再帰的 (recursive)。ディレクトリを再帰的に表示する。つまり、ディレクトリ中にほかのディレクトリがある場合、それらの内容も表示する 

-l

長形式。情報を長形式で表示する。長形式では、オブジェクトのタイプ、作成時間、所有者、およびアクセス権を表示する 

-g

グループ。情報を長形式で表示するとき、ディレクトリ所有者ではなく、そのグループ所有者を表示する 

-m

変更時間。情報を長形式で表示するとき、ディレクトリ作成時間ではなく、その変更時間を表示する 

ディレクトリの内容を表示する (簡潔形式)

ディレクトリ内容をデフォルトの短形式で表示するには、次に示すオプションの内の 1 つまたは複数と、ディレクトリ名を使います。ディレクトリ名を指定しない場合、NIS+ はデフォルトのディレクトリを使います。


nisls [-dLMR] directory-name

または


nisls [-dLMR]

たとえば、次の nisls の場合は、ルートドメイン doc.com. のルートマスターサーバーから入力します。


rootmaster% nisls doc.com.:
org_dir
groups_dir

次に、ルートマスターサーバーから入力した別の例を示します。


rootmaster% nisls -R sales.doc.com.
sales.doc.com.:
org_dir
groups_dir
groups_dir.sales.doc.com.: 
admin
org_dir.sales.doc.com.:
auto_master
auto_home
bootparams
cred
.

ディレクトリの内容を表示する (詳細形式)

ディレクトリの内容を詳細形式で表示するには -l オプション、および次に示すオプションのうちの 1 つまたは複数を使います。-g と -m のオプションは、表示される属性を変更します。-g と -m のオプションは、表示される属性を変更します。ディレクトリ名を指定しない場合、NIS+ はデフォルトのディレクトリを使います。


nisls -l [-gm] [-dLMR] directory-name

または


nisls -l [-gm] [-dLMR]

次に示すのは、ルートドメイン doc.com. のマスターサーバーから入力した例です。


rootmaster% nisls -l
doc.com.
D r---rmcdr---r--- rootmaster.doc.com. date org_dir
D r---rmcdr---r--- rootmaster.doc.com. date groups_dir

nismkdir コマンド

注 –

この節では、nismkdir コマンドを使用して既存のドメインにルート以外のサーバーを追加する方法を説明します。nisserver スクリプトを使用すれば、より簡単に追加できます。方法については、第 4 章「スクリプトを使用した NIS+ の設定」を参照してください。

nismkdir コマンドは、ルート以外の NIS+ ディレクトリを作成し、これをマスターサーバーに関連付けます。ルートディレクトリを作成するには、「nisinit コマンド」で説明する nisinit -r コマンドを使います。nismkdir コマンドを使って、複製サーバーを既存のディレクトリに追加できます。

NIS+ ディレクトリを作成するには、いくつかの関連作業のほかに、いくつかの前提条件があります。

ディレクトリを作成するには、以下のように入力します。


nismkdir [-m master-server] \
 directory-name

複製を既存のディレクトリに追加するには、以下のように入力します。


nismkdir -s replica-server \
 directory-name
nismkdir -s replica-server \
 org_dir.directory-name
nismkdir -s replica-server \
 groups_dir.directory-name

ディレクトリを作成する

ディレクトリを作成するには、(ドメインのマスターサーバー上の) 親ディレクトリに対する作成権が必要です。まず -m オプションを使ってマスターサーバーを定義し、次に -s オプションを使って複製を定義します。


nismkdir -m master directory
nismkdir -s replica directory
注意 – 注意 –

nismkdir は必ず (複製サーバーではなく) マスターサーバー上で実行してください。複製サーバー上で nismkdir を実行しないでください。複製サーバーで実行すると、マスターサーバーと複製サーバーの間で通信上の問題が発生します。

この例では、sales.doc.com. ディレクトリを作成してから、そのマスターサーバー smaster.doc.com. と複製サーバー rep1.doc.com. を指定します。これはルートマスターサーバーから入力します。 


rootmaster% nismkdir -m smaster.doc.com. sales.doc.com.
rootmaster% nismkdir -m smaster.doc.com. org_dir.sales.doc.com.
rootmaster% nismkdir -m smaster.doc.com. groups_dir.sales.doc.com.
rootmaster% nismkdir -s rep1.doc.com. sales.doc.com.
rootmaster% nismkdir -s rep1.doc.com. org_dir.sales.doc.com.
rootmaster% nismkdir -s rep1.doc.com. groups_dir.sales.doc.com.
図には、親のサーバーを使用する新規ディレクトリを示します。

小規模またはテスト用の名前空間でないかぎりは推奨しませんが、nismkdir コマンドを使えば、独自のサーバーを指定する代わりに、親ディレクトリのサーバーを新しいディレクトリ用に使えます。 次に 2 つの例を示します。

最初の例では、sales.doc.com. ディレクトリを作成し、これをその親ディレクトリのマスターと複製サーバーに関連付けます。


rootmaster% nismkdir sales.doc.com
この図は、マスターサーバーを指定する新しいディレクトリを示します。

2 番目の例では、sales.doc.com. ディレクトリを作成し、独自のマスターサーバーである smaster.doc.com. を指定します。


rootmaster% nismkdir -m smaster.doc.com. sales.doc.com.

複製サーバーは指定されないため、nismkdir を再び使用して複製を割り当てるまでは、新しいディレクトリにはマスターサーバーしかありません。sales.doc.com. ドメインがすでに存在する場合、上記の nismkdir コマンドは、salesmaster.doc.com. をその新しいマスターサーバーとし、その古いマスターサーバーを複製サーバーに格下げします。

複製サーバーを既存のディレクトリに追加する

この章では nismkdir コマンドを使用して複製サーバーを既存のシステムに追加する方法を説明します。nisserver スクリプトを使用すると、より簡単に追加できます。

以下の点に注意してください。

新しい複製サーバーを既存のディレクトリに割り当てるには、マスターサーバーに対して -s オプションと既存のディレクトリ名 (org_dir と groups_dir) を指定した nismkdir を使います。 


nismkdir -s replica-server existing-directory-name
nismkdir -s replica-server org_dir. existing-directory-name
nismkdir -s replica-server groups_dir. existing-directory-name

nismkdir コマンドは、ディレクトリがすでに存在することを知っているため、再び作成しません。単に、追加の複製サーバーを割り当てるだけです。たとえば、新しい複製サーバーマシン名が rep1 である場合は、以下のように入力します。


rootmaster% nismkdir -s rep1.doc.com. doc.com.
rootmaster% nismkdir -s rep1.doc.com. org_dir.doc.com.
rootmaster% nismkdir -s rep1.doc.com. groups_dir.doc.com.
注意 – 注意 –

nismkdir は必ず (複製サーバーではなく) マスターサーバー上で実行してください。複製サーバー上で nismkdir を実行しないでください。複製サーバーで実行すると、マスターサーバーと複製サーバーの間で通信上の問題が発生します。

上記の説明に従って nismkdir を 3 回繰り返して実行した後は、以下の 3 つのディレクトリでマスターサーバーから nisping を実行する必要があります。 


rootmaster# nisping doc.com.
rootmaster# nisping org_dir.doc.com.
rootmaster# nisping group_dir.doc.com.

この結果は以下のようになります。


rootmaster# nisping doc.com.
Pinging replicas serving directory doc.com. :
Master server is rootmaster.doc.com.
 Last update occurred at Wed Nov 18 19:54:38 1995
Replica server is rep1.doc.com.
 Last update seen was Wed Nov 18 11:24:32 1995
 Pinging ... rep1.doc.com

マスターサーバーの cron ファイルに、nisping コマンドが少なくとも 24 時間に一度 (この 3 つのディレクトリに対して) 実行されるよう設定しておくことをお勧めします。

nisrmdir コマンド

nisrmdir コマンドでは、ディレクトリを削除したり、ディレクトリと複製サーバーを切り離すことができます。ディレクトリを削除するかディレクトリと複製サーバーを切り離すと、その NIS+ ドメインに対して、マシンは NIS+ 複製サーバーとしては機能しなくなります。

ディレクトリの削除では、まずマスターサーバーと複製サーバーをディレクトリから切り離し、次にそのディレクトリを削除します。

nisrmdir コマンドの実行で問題が生じる場合は、「複製の失敗からの NIS+ ディレクトリの削除または分離」を参照してください。

ディレクトリを削除する

ディレクトリ全体を削除し、そのマスターサーバーと複製サーバーを切り離すには、nisrmdir コマンドをオプションなしで実行します。


nisrmdir directory-name
nisping domain

次の例では、doc.com. ディレクトリの下の manf.doc.com. ディレクトリを削除します。


rootmaster% nisrmdir manf.doc.com.
rootmaster% nisping doc.com.

複製サーバーをディレクトリから切り離す

複製サーバーをディレクトリから切り離すには、まず、ディレクトリの org_dir と groups_dir サブディレクトリを削除します。その時は、nisrmdir コマンドに -s オプションを付けて実行します。サブディレクトリが削除されたら、親ドメインに戻って nisping を実行してください。 


nisrmdir -s replicanameorg_dir.domain
nisrmdir -s replicanamegroups_dir.domain
nisrmdir -s replicaname domain
nisping domain

次の例では、manfreplica1 サーバーを manf.doc.com. ディレクトリから切り離します。


rootmaster% nisrmdir -s manfreplica1 org_dir.manf.doc.com.
rootmaster% nisrmdir -s manfreplica1 groups_dir.manf.doc.com.
rootmaster% nisrmdir -s manfreplica1 manf.doc.com.
rootmaster% nisping manf.doc.com.

nisrmdir -s コマンドを実行したが、切り離し対象の複製サーバーがダウンしていた、または通信が途絶していたという場合、「Cannot remove replica name:attempt to remove a non-empty table」というエラーメッセージが出されます。このような場合は、マスターサーバー上で nisrmdir -f -s replicaname コマンドを実行すれば、強制的に切り離すことができます。ただし、nisrmdir -f -s コマンドでダウン状態の複製サーバーを切り離した場合、その複製サーバーがオンラインに復帰したらただちに nisrmdir -f -s コマンドを再実行して複製サーバーの /var/nis ファイルシステムの中を整理する必要があります。nisrmdir -f -s replicaname を再実行しないと、複製がサービスを再開した時に複製上に残された古い情報によって問題が発生する場合があります。

nisrm コマンド

nisrm コマンドは、標準の rm システムコマンドと似ています。このコマンドは、ディレクトリと空でないテーブルを除いて、名前空間からすべての NIS+ オブジェクトを削除します。nisrm コマンドを使うには、オブジェクトに対する削除権が必要です。しかし、この権利がない場合、-f オプションを使うことができます。このオプションは、アクセス権がなくても動作を強行しようと試みます。

nisgrpadm -d コマンド (「NIS+ グループを削除する」を参照) を使えばグループオブジェクトを削除でき、nistbladm -r または nistbladm -R (「テーブルを削除する」を参照) を使えばテーブルを空にできます。

ディレクトリ以外のオブジェクトは、次のコマンドで削除します。


nisrm [-if] object-name
表 18–2 nisrm 構文オプション

オプション 

目的 

-i

照会。オブジェクトを削除する前に確認を要求する。指定されたオブジェクト名が完全指定されていない場合、このオプションが自動的に使われる

-f

強制。たとえ適切なアクセス権がない場合でも、削除の強行を試みる。nischmod コマンドを使ってアクセス権の変更を試み、再度オブジェクトの削除を試みる

ディレクトリ以外のオブジェクトを削除する

ディレクトリ以外のオブジェクトを削除するには、nisrm コマンドを使い、オブジェクト名を指定します。 


nisrm object-name...

次の例では、名前空間からグループとテーブルを削除します。


rootmaster% nisrm -i admins.doc.com. groups.org_dir.doc.com.
Remove admins.doc.com.? y
Remove groups.org_dir.doc.com.? y

rpc.nisd デーモン

NIS+ サービスを有効にすると、rpc.nisd デーモンが起動します。NIS+ デーモンを起動するにはアクセス権は不要ですが、そのすべての前提条件と関連作業を知っておく必要があります。前提条件については、「NIS+ サーバーを設定するための前提条件」を参照してください。

注 –

NIS+ サービスは、サービス管理機能 (SMF) によって管理されます。このサービスに対する有効化、無効化、再起動などの管理操作を実行するには、svcadm コマンドを使用します。SMF を NIS+ で使用する方法については、「NIS+ とサービス管理機能」を参照してください。SMF の概要については、『Solaris のシステム管理 (基本編)』の「サービスの管理 (概要)」を参照してください。詳細については、svcadm(1M) と svcs(1) の各マニュアルページも参照してください。

rpc.nisd デーモンを起動する

NIS+ サービスを有効にすると、rpc.nisd デーモンが起動します。サービスを起動するには、svcadm enable コマンドを使用します。


rootmaster# svcadm enable /network/rpc/nisplus:default

rpc.nisd デーモンを停止する

NIS+ サービスを無効にすると、rpc.nisd デーモンが停止します。まず、svcs コマンドを使って FMRI とサービスの状態を確認します。次に、svcadm disable コマンドを使ってサービスを停止します。その際、サービスが通常モードで動作しているか、NIS 互換モードで動作しているかは関係ありません。


rootmaster# svcs \*nisplus\*
STATE          STIME    FMRI
online         Oct_07   svc:/network/rpc/nisplus:default

rootmaster# svcadm disable /network/rpc/nisplus:default

rpc.nisd 構文オプションを変更する

デフォルトでは、NIS+ デーモンはセキュリティレベル 2 で起動し、通常モードで動作します。サービス管理機能を使って rpc.nisd デーモンを呼び出すときに特定のオプションを指定する場合は、そのオプションを含むように /lib/svc/method/nisplus ファイルを変更します。詳細については、「NIS+ とサービス管理機能」を参照してください。

表 18–3 に、一般的な rpc.nisd 構文オプションをいくつか示します。

表 18–3 一般的な rpc.nisd 構文オプション

オプション 

目的 

-Y

デーモンが NIS 互換モードで動作することを指定します。これにより、デーモンは NIS クライアントからの要求に応答できます。ルートマスターを含む任意のサーバーで、NIS+ デーモンを NIS 互換モードで起動できます。 

-B

NIS 互換モードで動作している NIS+ デーモンに DNS 転送機能を追加します。このオプションでは、/etc/resolv.conf ファイルが DNS ネームサーバーとの通信用に設定されている必要があります。 

-S security-level

セキュリティレベルを指定する。0 は「NIS+ セキュリティを使用しない」、2 は「最高レベルの NIS+ セキュリティを使用する」という意味 (レベル 1 はサポートされない)

-F

デーモンによって提供されるディレクトリのチェックポイント設定を強行する。この動作は、ディレクトリのトランザクションログを空にして、ディスク空間を解放することになる 

nisinit コマンド

この節では、nisinit コマンドを使用してマシンクライアントを初期設定する方法について説明します。nisclient スクリプトを使用すると、より簡単に初期設定できます。「NIS+ クライアントマシンの設定」を参照してください。

nisinit コマンドは、NIS+ クライアントまたはサーバーとなるマシンを初期設定します。rpc.nisd コマンドと同様、nisinit コマンドを使うにはアクセス権は不要ですが、その前提条件と関連作業を知っておく必要があります。「NIS+ クライアントを初期設定する」を参照してください。

クライアントを初期設定する

クライアントを初期設定するには、次の 3 つの方法があります。

前提条件と関連作業は、方法によってそれぞれ異なります。たとえば、ホスト名によってクライアントを初期設定するには、その前にクライアントの /etc/hosts ファイルまたは /etc/inet/ipnodesファイルに、使用するホスト名を登録しなければなりません。また nsswitch.conf ファイルの hosts の最初の選択肢として、files を指定する必要があります。IPv6 アドレスには、hosts の最初の選択肢としてipnodes を指定してください。nisinit コマンドを使う手順を次にまとめてみます。

ホスト名によってクライアントを初期設定するには、-c と -H のオプションを使い、クライアントがそのコールドスタートファイルを取得するサーバー名を指定します。


nisinit -c -H hostname

コールドスタートファイルによってクライアントを初期設定するには、-c と -C のオプションを使い、コールドスタートファイル名を指定します。


nisinit -c -C filename

ブロードキャストによってクライアントを初期設定するには、-c と -B のオプションを使います。


nisinit -c -B

ルートマスターサーバーを初期設定する

ルートマスターサーバーを初期設定するには、nisinit -r コマンドを使います。


nisinit -r

ここで次の情報が必要になります。

表 18–4 インターネットの組織ドメイン

ドメイン 

目的 

com

営利団体 

edu

教育機関 

gov

行政機関 

mil

軍事組織 

net

主要ネットワークサポートセンター 

org

非営利団体 

int

国際組織 

nis_cachemgr デーモン

nis_cachemgr は、すべての NIS+ クライアント上で動作する必要があります。キャッシュマネージャは、名前空間でもっともよく使われるディレクトリをサポートする NIS+ サーバーの位置情報キャッシュを管理します。位置情報はトランスポートアドレス、認証情報、生存期間値などです。

キャッシュマネージャが起動すると、クライアントのコールドスタートファイルから初期情報を取得し、それを /var/nis/NIS_SHARED_DIRCACHE ファイルにダウンロードします。

キャッシュマネージャは、クライアントマシンとして要求を行います。クライアントマシンには必ず適切な資格を持たせてください。そうしないと、性能が向上するどころか、キャッシュマネージャが性能を低下させます。

キャッシュマネージャの起動と停止

サービス管理機能 (SMF) の使用時は、キャッシュマネージャは NIS+ サービスに依存しているため、NIS+ サービスとともに起動または停止します。 NIS+ サービスを起動、停止、または再起動するには、 svcadm コマンドを使用します。


client% svcadm enable /network/rpc/nisplus:default
client% svcadm disable /network/rpc/nisplus:default
client% svcadm restart /network/rpc/nisplus:default

NIS+ サービスをいったん停止してから起動すると、キャッシュマネージャが再起動されますが、/var/nis/NIS_SHARED_DIRCACHE ファイル内の情報は保持されます。コールドスタートファイル内の情報は、キャッシュファイル内の既存の情報にそのまま追加されます。キャッシュファイルをクリアし、クライアントのコールドスタートファイルの内容からこれを再び初期設定するには、-i オプションを使用します。

nisshowcache コマンド

nisshowcache コマンドは、クライアントのディレクトリキャッシュの内容を表示します。

NIS+ キャッシュの内容を表示する

nisshowcache コマンドは、/usr/lib/nis 内にあります。このコマンドはキャッシュヘッダーとディレクトリ名だけを表示します。ルートマスターサーバーから入力した例を次に示します。 


rootmaster# /usr/lib/nis/nisshowcache -v
Cold Start directory:
Name : doc.com.
Type : NIS
Master Server :
 Name : rootmaster.doc.com.
 Public Key : Diffie-Hellman (192 bits)
 Universal addresses (3)
 . .
Replicate:
 Name : rootreplica1.doc.com.
 Public Key : Diffie-Hellman (192 bits)
 Universal addresses (3)
 .
 .
 .
Time to live : 12:0:0
Default Access Rights :

ping とチェックポイントを実行する

NIS+ データセットに変更を加えると、その変更は、当該 NIS+ ドメイン (またはサブドメイン) のマスターサーバーのメモリーに格納されます。変更の記録はマスターサーバーのトランザクションログ (/var/nis/data/trans.log) にも残されます。

通常、NIS+ データセットに変更が加えられると、その 120 秒 (2 分) 後に、マスターサーバーから当該ドメインの複製サーバーにその変更の内容が転送されます。この転送プロセスのことを「ping」といいます。マスターサーバーから複製サーバーへの ping が実行されると、通知された変更内容に従って複製サーバーのデータセットが更新されます。これにより、変更された NIS+ データがマスターサーバーと複製サーバーの両方のメモリーに格納されることになります。

自動 ping プロセスが不調で複製サーバーのデータセットが更新されないこともあります。その場合は、「ping を強制的に実行する」の説明に従って ping を強制的に実行する必要があります。複製サーバーが最新の NIS+ データどおりに正しく更新されているかどうか不安な場合は、「最新更新時間を表示する」の説明に従って複製サーバーが最後に更新されたのはいつであるかを確認してください。

NIS+ データセットに対する変更は、サーバーのメモリーに格納され、トランザクションログに記録されたのち、ディスク上の NIS+ テーブルに書き込まれなければなりません。この NIS+ テーブルを更新することを「チェックポイントを実行する」といいます。

チェックポイントの実行は自動的には行われません。「ディレクトリにチェックポイントを実行する」の説明に従ってチェックポイントコマンドを実行する必要があります。

nisping コマンド

nisping コマンドには次の用途があります。

最新更新時間を表示する

-u オプションを指定して nisping コマンドを実行すると、ローカルドメインのマスターサーバーと複製サーバーが更新された時間が表示されます。


/usr/lib/nis/nisping -u [domain]

ほかのドメインで最後に更新が行われた時間を表示するには、コマンド行にそのドメイン名を指定します。-u オプションを指定して nisping コマンドを実行した場合、複製サーバーに対する ping は一切実行されない点に注意してください。

たとえば、ローカルドメイン doc.com. で複製サーバーが最後に更新された時間を表示するには、次のように入力します。


rootmaster# /usr/lib/nisping -u
Last updates for directory doc.com.:
Master server is rootmaster.doc.com.
 Last update occurred at Wed Nov 25 10:53:37 1992
Replica server is rootreplica1.doc.com.
 Last update seen was Wed Nov 25 10:53:37 1992

ping を強制的に実行する

-u オプションを指定して nisping コマンドを実行した結果、複製サーバーが正しく更新されていないことがわかったとします。そのような場合は、nisping コマンドを実行することにより、マスターサーバーからドメイン内のすべての複製サーバーに対して、または特定の複製サーバーに対して、ping を強制的に実行できます。

すべての複製サーバーを ping の対象とする場合、次に示すように、nisping コマンドをオプションなしで実行します。


/usr/lib/nis/nisping

これにより、マスターサーバーからドメイン内のすべての複製サーバーへの ping が強制的に実行されます。ローカルドメイン doc.com. のすべての複製サーバーに対する ping を強制的に実行するには、次のように入力します。


rootmaster# /usr/lib/nis/nisping
Pinging replicas serving directory doc.com.:
Master server is rootmaster.doc.com.
 Last update occurred at Wed Nov 25 10:53:37 1992
Replica server is rootreplica1.doc.com.
 Last update seen was Wed Nov 18 11:24:32 1992
 Pinging ... rootreplica1.doc.com.

ローカルドメインでないドメイン内のすべての複製サーバーに対し ping を実行するには、ドメイン名を指定します。


/usr/lib/nis/nisping domainname

特定の 1 台のホスト上のすべてのディレクトリにあるすべてのテーブルに対し ping を実行することもできます。この場合、-a オプションを使用します。


/usr/lib/nis/nisping -a hostname

ディレクトリにチェックポイントを実行する

スワップの頻度やディスク領域との関連でトランザクションログが大きくなりすぎる場合、各ドメインおよびサブドメインに対しては、少なくとも 24 時間に 1 回はチェックポイントを実行する必要があります。

注 –

大きなドメイン、または大きなトランザクションログを持つドメインに対してチェックポイントを実行すると、終了するまでにかなりの時間がかかり、その間 NIS+ サーバーが拘束され、NIS+ サービスの速度が低下します。サーバーは、チェックポイントを実行している間もサービス要求に応答しますが、更新できません。できるだけ、システムが混んでいない時間帯を選んでチェックポイントを実行することをお勧めします。チェックポイントの実行スケジュールは cron ファイルで調整できます。

チェックポイントを実行するには、当該ドメインのマスターサーバー上で nisping -C コマンドを実行します。先にすべての複製サーバーに対して ping を実行してから、チェックポイントを実行することをお勧めします。その場合には、複製サーバーに対して常に最新のデータでチェックポイントを実行できます。

サーバーによってそのトランザクションログの情報が NIS+ テーブルに転送されると、ログファイル内のトランザクションは、ディスク領域の節約のため消去されます。

doc.com. ドメイン内のすべてのディレクトリに対してチェックポイントを実行するには、次のように入力します。


rootmaster# /usr/lib/nis/nisping -C -a
Checkpointing replicas serving directory doc.com. :
Master server is rootmaster.doc.com.
 Last update occurred at Wed May 25 10:53:37 1995
Master server is rootmaster.doc.com.
checkpoint has been scheduled with rootmaster.doc.com.
Replica server is rootreplica1.doc.com.
 Last update seen was Wed May 25 10:53:37 1995
Replica server is rootreplica1.doc.com.
checkpoint has been scheduled with rootmaster.doc.com.

nislog コマンド

nislog コマンドは、トランザクションログの内容を表示します。 


/usr/sbin/nislog 
/usr/sbin/nislog -h [number]
/usr/sbin/nislog -t [number]
表 18–5 nislog コマンドのオプション

オプション 

目的 

-h [num]

ログの先頭からトランザクションを表示する。数字を指定しなければ、最初のトランザクションから表示が開始される。0 を指定すると、ログヘッダーだけが表示される 

-t [num]

ログの末尾からトランザクションを表示する。数字を指定しなければ、最後のトランザクションから表示が開始される。0 を指定すると、ログヘッダーだけが表示される 

-v

冗長モード。 

トランザクションログの内容を表示する

各トランザクションは、トランザクションの明細部とオブジェクト定義のコピー部の 2 つの部分から構成されます。

doc.com. ディレクトリが最初に作成されたときに作られたトランザクションログエントリを次の例に示します。「XID」はトランザクション ID を意味します。 


rootmaster# /usr/sbin/nislog -h 1
NIS Log printing facility.
NIS Log dump:
 Log state : STABLE
Number of updates : 48
Current XID : 39
Size of log in bytes : 18432
***UPDATES***
@@@@@@@@@@@@@@TRANSACTION@@@@@@@@@@@@@@
#00000, XID : 1
Time : Wed Nov 25 10:50:59 1992
Directory : doc.com.
Entry type : ADD Name
Entry timestamp : Wed Nov 25 10:50:59 1992
Principal : rootmaster.doc.com.
Object name : org_dir.doc.com.
...................Object......................
Object Name : org_dir
Owner : rootmaster.doc.com.
Group : admin.doc.com.
Domain : doc.com.
Access Rights : r---rmcdr---r---
Time to Live : 24:0:0
Object Type : DIRECTORY
Name : `org_dir.doc.com.'
Type: NIS
Master Server : rootmaster.doc.com.
.
.
................................................
@@@@@@@@@@@@@@TRANSACTION@@@@@@@@@@@@@@
#00000, XID : 2

nischttl コマンド

nischttl コマンドは、名前空間内のオブジェクトまたはエントリの生存期間値を変更します。キャッシュマネージャは、この生存期間値を使って、キャッシュエントリをいつ期限切れにするかを決めます。生存期間を指定するには、合計秒数か、日、時間、分、秒の組み合わせのいずれかを使います。

オブジェクトまたはエントリに割り当てる生存期間値は、オブジェクトの安定性に左右されます。よく変化するオブジェクトの場合、生存期間値を低くします。安定したオブジェクトの場合、高い値を指定します。高い生存期間値であれば、1 週間などを指定し、低い値であれば 1 分未満を指定します。パスワードエントリの生存期間値は約 12 時間とし、1 日に 1 回パスワード変更ができるようにする必要があります。RPC テーブル内のエントリなど、あまり変化しないテーブルのエントリには、数週間の値を設定できます。

オブジェクトの生存期間を変更するには、そのオブジェクトに対する変更権が必要です。テーブルエントリの生存期間を変更するには、テーブルに対する変更権が必要であり、テーブルがなければエントリに対して、エントリもなければ変更したい列に対して変更権が必要です。

オブジェクトまたはテーブルエントリの現在の生存期間値を表示するには、第 15 章「NIS+ のアクセス権の管理」で説明する nisdefaults -t コマンドを使います。

オブジェクトの生存期間値を変更するには、以下のどちらかのように入力します。 


nischttl time-to-live object-name

または


nischttl [-L] time-to-live object-name

エントリの生存期間値を変更するには、以下のいずれかのように入力します。


nischttl time-to-live \
 [column=value,...], \
 table-name

または


nischttl [-ALP] time-to-live \
 [column=value,...], \
 table-name

time-to-live には以下のものを指定します。

以上の値は組み合わせて使うことができます。たとえば「 4d3h2m1s 」は、4 日 3 時間 2 分 1 秒を意味します。

nischttl コマンドでは以下のフラグを使用できます。

表 18–6 nischttl 構文のオプション

オプション 

目的 

A

すべて。[column=value] 指定に合致する全エントリに変更を適用する

L

リンク。リンクをたどり、リンク自体ではなく、リンクされたオブジェクトまたはエントリを変更する 

P

パス。条件を満足するエントリが 1 つ見つかるまで、パスをたどる 

オブジェクトの生存期間を変更する

オブジェクトの生存期間を変更するには、生存期間の値とオブジェクト名を指定して nischttl コマンドを入力します。-L コマンドを追加すれば、リンクされたオブジェクトにまで変更を拡張できます。


nischttl -L time-to-live  object-name

生存期間は秒か、日、時間、分、秒の組み合わせかで指定できます。前者の場合、秒数だけを指定します。後者の場合、日数、時間数、分数と秒数に「 s、m、h、d」をつけてください。 たとえば、以下のようになります。


client% nischttl 86400 sales.doc.com.
client% nischttl 24h sales.doc.com.
client% nischttl 2d1h1m1s sales.doc.com.

最初の 2 つでは、sales.doc.com. ディレクトリの生存期間が 86,400 秒、つまり 24 時間に変更されます。3 つめでは、hosts テーブル内の全エントリの生存期間が 176,461 秒、つまり 2 日と 1 時間 1 分 1 秒に変更されます。

テーブルエントリの生存期間を変更する

エントリの生存期間を変更するには、インデックス付きのエントリフォーマットを使います。-A、-L、または -P のどのオプションでも使えます。


nischttl [-ALP] time-to-live \
 [column=value,...], \
 table-name
注 –

Cシェル を使用している場合、[ ]?がメタキャラクタとして解釈されないように引用符で囲みます。

次に示す例は上記の例と似ていますが、オブジェクトではなく、テーブルエントリの値を変更します。


client% nischttl 86400 '[uid=99],passwd.org_dir.doc.com.'
client% nischttl 24h `[uid=99],passwd.org_dir.doc.com.'
client% nischttl 2d1h1m1s `[name=fred],hosts.org_dir.doc.com.'