test

NFS の管理

第 3 章 NFS リファレンス

この章では、NFS コマンドの概要について説明します。また、NFS 環境のすべての構成要素とそれらが互いにどのように連携するかについても説明します。

NFS ファイル

いくつかの ASCII ファイルでは、いずれのコンピュータ上でも NFS アクティビティをサポートする必要があります。表 3-1 に、こういったファイルとその機能をまとめます。

表 3-1 NFS の ASCII ファイル

ファイル名 

機能 

/etc/mnttab

自動的にマウントしたディレクトリを含む、現在マウントしているファイルシステムを一覧表示する (mnttab(4) のマニュアルページ参照)。編集しないこと。

/etc/netconfig

トランスポートプロトコルのリスト。編集しないこと。 

/etc/nfssec.conf

NFS のセキュリティサービスのリスト。編集しないこと。 

/etc/rmtab

NFS クライアントがリモートにマウントしたファイルシステムを一覧表示する (rmtab(4) のマニュアルページ参照)。 編集しないこと。

/etc/vfstab

ローカルにマウントするファイルシステムを定義する (vfstab(4) のマニュアルページ参照)。

/etc/default/fs

ローカルファイルシステムにおけるデフォルトファイルシステムのタイプを一覧表示する。 

/etc/dfs/dfstab

共有するローカルリソースを一覧表示する。 

/etc/dfs/fstypes

リモートファイルシステムにおけるデフォルトファイルシステムのタイプを一覧表示する。 

/etc/dfs/sharetab

共有している、ローカルとリモートのリソースを一覧表示する (sharetab(4) のマニュアルページ参照)。編集しないこと。

/etc/dfs/fstypes の最初の項目は、リモートファイルシステムにおけるデフォルトファイルシステムのタイプとして使用されることがしばしばあります。この項目は、NFS ファイルシステムのタイプをデフォルトとして定義します。

/etx/default/fs には、項目が 1 つしかありません。ローカルディスクにおけるデフォルトファイルシステムのタイプです。クライアントやサーバでサポートするファイルシステムのタイプは、/kernel/fs のファイルをチェックして決定することができます。

NFS デーモン

NFS アクティビティをサポートするには、システムが実行レベル 3 かマルチユーザモードで動作したときに、いくつかのデーモンを開始します。mountd と nfsd の 2 つのデーモンは、NFS サーバであるシステム上で動作します。サーバデーモンの自動起動は、NFS ファイルシステムのタイプでラベル付けされた項目が /etc/dfs/sharetab に存在するかどうかで変わります。

lockd と statd の 2 つのデーモンは NFS クライアントで動作し、NFS ファイルロッキングをサポートします。NFS サーバでも動作させなければなりません。

lockd

このデーモンは NFS ファイルのレコードロックをサポートします。ロック要求をクライアントから NFS サーバに送り、NFS サーバでローカルのロックを開始します。通常は、パラメータを指定せずに起動します。使用できるオプションは 3 つあります (マニュアルページの lockd(1M) を参照してください)。

-g graceperiod オプションは、サーバがリブートした場合に、その何秒後にロックを再要求するかを示します。NFS サーバはこの秒数の間、それまでのロックの再要求処理しか実行しません。他のサービスに対する要求は、この時間が経過するまで待たされます。このオプションは NFS サーバの応答性に関係するため、NFS サーバでしか変更できません。デフォルト値は 45 秒です。この値を小さくすると、サーバをリブートしてからオペレーションに復帰するまでの時間は短縮されますが、クライアントがすべてのロックを復旧できなくなる可能性が増します。

-t timeout オプションは、ロック要求をリモートサーバに再送信するまで何秒待つかを示します。このオプションは NFS クライアントのサービスに関係します。デフォルト値は 15 秒です。この値を小さくすると、雑音の多いネットワーク上の NFS クライアントに対する応答時間を改善できますが、ロック要求が増えることによってサーバの負荷が増す可能性があります。

nthreads オプションは、サーバが 1 つの接続について同時に処理できるスレッドの数の上限を示します。この値は、NFS サーバに対して予想される負荷に基づいて決定してください。デフォルト値は 20 です。TCP を使用する NFS クライアントはそれぞれ NFS サーバと 1 つの接続を設定するため、各 TCP クライアントはサーバ上で同時に 20 までのスレッドを使うことが許されます。UDP (ユーザデーモンプロトコル) を使用する NFS クライアントは、すべてが NFS サーバと 1 つの接続を共有します。その場合、UDP 接続が使用できるスレッドの数を増やさなければならないことがあるかもしれません。簡単な目安は 1 つの UDP クライアントにつき 2 つのスレッドですが、クライアントに対する作業負荷によってはこれで不十分なこともあります。使用するスレッドを増やすことによるマイナスは、スレッドの使用によって NFS サーバで使われるメモリが増えることです。しかしスレッドが使われないならば、nthreads を大きくしても影響はありません。

mountd

これは、リモートシステムからのファイルシステムマウント要求を処理して、アクセス制御を行う RPC (リモートプロシージャコール) サーバです。/etc/dfs/sharetab を調べることによって、リモートマウントに使用可能なファイルシステムと、リモートマウントを実行可能なシステムを判断します。-v と -r の 2 つのオプションが使えます (マニュアルページの mountd(1M) を参照してください)。

-v オプションは、コマンドを冗長モードで実行します。クライアントが取得すべきアクセス権を NFS サーバが決定するたびに、コンソールにメッセージが表示されます。この情報は、クライアントがファイルシステムにアクセスできない理由を調べるときに役立ちます。

-r オプションは、その後のクライアントからのマウント要求をすべて拒絶します。すでにファイルシステムがマウントされているクライアントには影響しません。

nfsd

これは、他のクライアントからのファイルシステム要求を処理するデーモンです。このコマンドに対してはいくつかのオプションが指定できます。オプションをすべて確認するにはマニュアルページの nfsd(1M) を参照してください。

-l オプションは、接続指向トランスポートでの NFS/TCP に対する接続キューの長さを設定します。デフォルト値は 25 エントリです。

-c #_conn オプションは、接続指向トランスポート 1 つあたりの接続数の上限を選択します。デフォルト値はありません。

nservers オプションは、1 台のサーバが同時に処理可能な要求の数の上限です。デフォルト値は 1 ですが、起動スクリプトでは 16 が選択されます。

このデーモンの以前のバージョンとは異なり、このバージョンの nfsd では複数のコピーを作成して要求を同時に処理することはありません。処理テーブルを ps でチェックすると、動作しているデーモンのコピーが 1 つしかないことがわかります。

statd

lockd とともに動作し、ロック管理機能にクラッシュ機能と回復機能を提供します。NFS サーバでロックを保持しているクライアントの追跡を行い、サーバがクラッシュし、リブートしているあいだに、サーバ側 statd がクライアント側 statd と連絡をとります。次にクライアント側 statd は、サーバ上のすべてのロックを再要求します。クライアントがクラッシュすると、クライアント側 statd はサーバ側 statd にそのことを伝えるので、サーバ上のロックはクリアされます。このデーモンにオプションはありません。詳細については、マニュアルページの statd(1M) を参照してください。

Solaris 7 では、statd がクライアントを追跡する方法が改善されました。Solaris 7 より前のリリースの statd では、クライアントごとにそのクライアントの修飾されていないホスト名を使用して、/var/statmon/sm にファイルが作成されました。そのため、同じホスト名の 2 つのクライアントが異なるドメインに存在する場合や、クライアントが NFS サーバと異なるドメインに存在する場合に問題が発生していました。修飾されていないホスト名にはドメインや IP アドレスの情報がないため、このようなクライアントを区別する方法がありませんでした。これに対処するため、Solaris 7 の statd では、修飾されていないホスト名に対してクライアントの IP アドレスを使用して /var/statmon/sm にシンボリックリンクを作成します。このリンクは、次のような形式です。


# ls -l /var/statmon/sm
lrwxrwxrwx   1 root          11 Apr 29 16:32 ipv4.192.9.200.1 -> myhost
--w-------   1 root          11 Apr 29 16:32 myhost

この例では、クライアントのホスト名は myhost で、IP アドレスは 192.9.200.1 です。他のホストが myhost という名前を持ち、ファイルシステムをマウントしていると、myhost というホスト名に対するシンボリックリンクは 2 つ作成されます。

NFS コマンド

以下のコマンドは、root 権限で実行しなければ、十分な効果がでません。しかし情報の要求は、すべてのユーザが行えます。

clear_locks

このコマンドを使うと、ある NFS クライアントのファイル、レコード、または共有のロックをすべて削除できます。このコマンドを実行するには、スーパーユーザでなければなりません。NFS サーバから解除できるのは特定のクライアントのロックであり、NFS クライアントから解除できるのは特定のサーバ上のそのクライアントに対するロックです。次の例では、現在のシステム上の tulip という NFS クライアントに対するロックが解除されます。 


# clear_locks tulip

-s オプションを指定すると、どの NFS ホストからロックを解除するかを指定できます。これは、そのロックをかけた NFS クライアントから実行しなければなりません。次の場合、クライアントによるロックが bee という名前の NFS サーバから解除されます。


# clear_locks -s bee
注意 - 注意 -

このコマンドは、クライアントがクラッシュしてロックを解除できないとき以外には使用しないでください。データが破壊されるのを避けるため、使用中のクライアントに関するロックは解除しないでください。

mount

このコマンドを使用すると、指定したファイルシステムをローカルかリモートで、指定したマウントポイントに添付できます。詳細については、mount(1M) のマニュアルページを参照してください。引数を指定しないと、現在ユーザのコンピュータにマウントされているファイルシステムのリストが表示されます。

Solaris の標準インストールには、さまざまな種類のファイルシステムが含まれています。すべてのファイルシステムタイプの説明は、『Solaris のシステム管理 (第 1 巻)』の"ファイルシステムのタイプ" in Solaris のシステム管理 (第 1 巻)を参照してください。ファイルシステムの種類ごとにマニュアルページがあり、その種類に対して mount を実行するときに使用可能なオプションのリストが示されています。たとえば、NFS ファイルシステムのマニュアルページは mount_nfs(1M)、UFS ファイルシステムのマニュアルページは mount_ufs(1M) などです。

Solaris 7 では、server:/pathname という標準の構文の代わりに NFS URL を使用して NFS サーバ上のマウントするパス名を指定することが可能になりました。詳細については、「NFS URL を使用して NFS ファイルシステムをマウントする方法」を参照してください。

注意 - 注意 -

Solaris 2.6 以後の mount コマンドでは、無効なオプションがあっても警告されません。解釈できないオプションがあると無視されるだけです。予想外の結果が生じるのを避けるために、使用するオプションはすべて確認してください。

NFS ファイルシステムにおける mount のオプション

NFS ファイルシステムをマウントするときに -o フラグの後に指定できるオプションの一部を、以下に示します。

bg|fg

この 2 つは、マウントが失敗したときの再試行の方法を選択するオプションです。-bg オプションの場合はバックグラウンドで、-fg オプションの場合はフォアグラウンドでマウントが試みられます。デフォルトは -fg です。常に使用可能にしておく必要のあるファイルシステムに対しては -fg が適しています。この場合、マウントが完了するまで他の処理は実行できません。-bg は、マウント要求が完了しなくてもクライアントは他の処理を実行できるため、必ずしも必要でないファイルシステムに適しています。

largefiles

このオプションを使うと、Solaris 2.6 が実行されているサーバに置かれた 2 ギガバイトを超えるサイズのファイルにアクセスできるようになります。大型ファイルにアクセスできるかどうかは、サーバでしか制御できません。したがって、このオプションは NFS バージョン 3 のマウントでは無視されます。デフォルトでは、2.6 以後の UFS ファイルシステムはすべて -largefiles オプション付きでマウントされます。NFS バージョン 2 プロトコルを使ったマウントでこのオプションを指定すると、エラーが発生してマウントできません。

nolargefiles

UFS マウントでこのオプションを指定すると、ファイルシステム上に大型ファイルが存在せず、この後も作成されないことが保証されます (マニュアルページの mount_ufs(1M) を参照してください)。大型ファイルが存在するかどうかは NFS サーバでしか制御できないため、NFS マウントを使う -nolargefiles にはオプションはありません。このオプションを指定してファイルシステムを NFS マウントしようとすると、エラーが発生して拒否されます。

public

このオプションを指定すると、NFS サーバにアクセスするときに必ず公共ファイルハンドルを使用するようになります。NFS サーバが公共ファイルハンドルをサポートしていれば、MOUNT プロトコルが使用されないため、マウント操作は短時間で行われます。また、MOUNT プロトコルを使用しないため、ファイアウォールを越えたマウントが可能です。

rw|ro

-rw オプションと -ro オプションは、ファイルシステムが読み書き可能と読み取り専用のどちらでマウントされるかを示します。デフォルトは読み書き可能で、これはリモートホームディレクトリやメールスプールディレクトリなどの、ユーザによる変更が必要なファイルシステムに適しています。読み取り専用オプションは、ユーザが変更してはいけないディレクトリに適しています。具体的には、マニュアルページの共有コピーなどです。

sec=mode

このオプションは、マウント時に使われる認証機構を指定します。mode の値は、表 3-2 に示したもののいずれかでなければなりません。モードは、/etc/nfssec.conf ファイルにも定義されます。

表 3-2 NFS セキュリティモード

モード 

選択される認証サービス 

krb4

Kerberos バージョン 4 

none

認証なし 

dh

Diffie-Hellman (DH) 認証 

sys

UNIX の標準認証 

soft|hard

soft オプションを指定してマウントされた NFS ファイルシステムは、サーバが応答しなくなるとエラーを返します。hard オプションが指定されていると、サーバが応答するまで再試行が続けられます。デフォルトは hard です。ほとんどのファイルシステムには hard を使用します。ソフトマウントされたファイルシステムからの値を検査しないアプリケーションが多いので、アプリケーションでエラーが発生してファイルが破壊されるおそれがあるためです。検査するアプリケーションの場合でも、ルーティングの問題などによってアプリケーションが正しい判断をできずに、ファイルが破壊されることがあります。原則として、soft は使用しないでください。hard オプションを指定した場合にファイルシステムが使えなくなると、そのファイルシステムを使うアプリケーションはファイルシステムが復旧するまでハングする可能性があります。

mount コマンドの使用

以下のコマンドのどちらも、bee サーバから NFS ファイルシステムを読み出し専用としてマウントします。 


# mount -F nfs -r bee:/export/share/man /usr/man


# mount -F nfs -o ro bee:/export/share/man /usr/man

このコマンドでは -O オプションによって、/usr/man がすでにマウントされていても bee サーバのマニュアルページがローカルシステムにマウントされます。 


# mount -F nfs -O bee:/export/share/man /usr/man

このコマンドでは、クライアント側障害時回避機能が使われています。 


# mount -F nfs -r bee,wasp:/export/share/man /usr/man
注 -

コマンド行から使用する場合、リスト内のサーバがサポートしている NFS プロトコルは同じバージョンでなければなりません。コマンド行から mount を実行するときは、バージョン 2 とバージョン 3 のサーバを混在させないでください。autofs では混在が可能なので、バージョン 2 サーバとバージョン 3 サーバの最適な組み合わせを使用できます。

mount コマンドで NFS URL を使用する例を示します。 


# mount -F nfs nfs://bee//export/share/man /usr/man

mount コマンドに引数を指定しないと、クライアントにマウントされたファイルシステムが表示されます。 

% mount
/ on /dev/dsk/c0t3d0s0 read/write/setuid on Tues Jan 24 13:20:47 1995
/usr on /dev/dsk/c0t3d0s6 read/write/setuid on Tues Jan 24 13:20:47 1995
/proc on /proc read/write/setuid on Tues Jan 24 13:20:47 1995
/dev/fd on fd read/write/setuid on Tues Jan 24 13:20:47 1995
/tmp on swap read/write on Tues Jan 24 13:20:51 1995
/opt on /dev/dsk/c0t3d0s5 setuid/read/write on Tues Jan 24 13:20:51 1995
/home/kathys on bee:/export/home/bee7/kathys
  intr/noquota/nosuid/remote on Tues Jan 24 13:22:13 1995

umount

このコマンドにより、現在マウントされているリモートファイルシステムが削除されます。umount コマンドは、テストのために -V オプションをサポートしています。また、-a オプションを使うことによって 1 度に複数のファイルシステムをアンマウントできます。-a オプションに mount_points を指定すると、そのファイルシステムがアンマウントされます。マウントポイントを指定しないと、/etc/mnttab のリストにあるファイルシステムのうち "required" でないものすべてのアンマウントが試みられます。"required" のファイルシステムとは、/、/usr、/var、/proc、/dev/fd、/tmp などです。

ファイルシステムがすでにマウントされていて、/etc/mnttab に項目が指定されている場合、ファイルシステムのタイプのフラグを指定する必要はありません。

ファイルシステムが使用中だと、このコマンドは実行できません。たとえば、あるユーザが cd コマンドによってファイルシステムにアクセスしていると、作業ディレクトリが他に変更されるまでそのファイルシステムは使用中となります。umount コマンドは、NFS サーバに接続できないと一時的にハングすることがあります。

umount コマンドの使用

以下の例では、/usr/man にマウントしたファイルシステムのマウントが解除されます。 


# umount /usr/man

以下の例では、umount -a -V の実行結果が表示されます。

# umount -a -V
umount /home/kathys
umount /opt
umount /home
umount /net

このコマンドでは、ファイルシステムのアンマウント自体は実行されないことに注意してください。

mountall

このコマンドを使用すると、ファイルシステムテーブルに指定したすべてのファイルシステム、または特定グループのファイルシステムをマウントできます。アクセスするファイルシステムタイプを選択するための -F FSType オプション、ファイルシステムテーブル内のリモートファイルシステムをすべて選択する -r オプション、ローカルファイルシステムをすべて選択する -l オプションがあります。 NFS ファイルシステムタイプと指定されているファイルシステムはすべてリモートファイルシステムなので、これらのオプションは余分な指定になることがあります。詳細については、マニュアルページの mountall(1M) を参照してください。

mountall コマンドの使用

以下の２つの例を実行すると、同じ結果になります。 


# mountall -F nfs


# mountall -F nfs -r

umountall

このコマンドを使用すると、ファイルシステムのグループをアンマウントできます。-k オプションは、mount_point に結び付けられているプロセスを終了させるには fuser -k mount_point コマンドを使う必要があることを表します。-s オプションは、アンマウントを並行処理しないことを示します。-l は、ローカルファイルシステムだけを使用することを、-r はリモートファイルシステムだけを使用することを示します。-h host オプションは、指定されたホストのファイルシステムをすべてアンマウントすることを指定します。-h オプションは、-l または -r とは同時に指定できません。

umountall コマンドの使用

以下のコマンドでは、リモートホストからマウントしたすべてのファイルシステムが切り離されます。 


# umountall -r

以下のコマンドでは、bee サーバからマウントしたすべてのファイルシステムが切り離されます。 


# umountall -h bee

share

このコマンドを使用すると、NFS サーバのローカルファイルシステムをマウントできるようになります。また、システム上のファイルシステムのうち、現在共有しているもののリストを表示します。NFS サーバが動作していないと、share コマンドは使用できません。NFS サーバソフトウェアは、/etc/dfs/dfstab に項目がある場合、ブートの途中で自動的に起動されます。NFS サーバソフトウェアが動作していないくても、このコマンドはエラーを表示しません。NFS サーバソフトウェアが動作していることを確認してからこのコマンドを使用するようにしてください。

ディレクトリツリーはすべて共有できるオブジェクトですが、各ファイルシステムの階層構造は、そのファイルシステムが位置するディスクスライスやパーティションで制限されます。たとえばルート (/) ファイルシステムを共有しても、/usr が同じディスクパーティションかスライスに存在しなければ、/usr を共有することはできません。通常、ルートはスライス 0 に、/usr はスライス 6 にインストールされます。また /usr を共有しても、/usr のサブディレクトリにマウントされているローカルディスクパーティションは共有できません。

すでに共有している大きいファイルシステムの一部であるファイルシステムを共有することはできません。たとえば /usr と /usr/local が同じディスクスライスにある場合、/usr も /usr/local も共有することができますが、両方を別々の共有オプションで共有する場合、/usr/local は別のディスクスライスに移動しなければなりません。

警告 - 警告 -

2 つのファイルシステムが同じディスクスライスにある場合、読み出し専用で共有しているファイルシステムに、読み出しと書き込みが可能な状態で共有しているファイルシステムのファイルハンドルでアクセスすることができます。読み出しと書き込みの両方を行うファイルシステムは、読み出し専用で共有する必要があるファイルシステムとは別のパーティションかディスクスライスに保存するほうが安全です。

share オプション

-o フラグに指定できるオプションの一部を示します。

rw|ro

pathname に指定したファイルシステムを、読み出しと書き込みの両方が可能な状態で共有するか、読み出し専用で共有するかを指定します。

rw=accesslist

ファイルシステムは、リスト上のクライアントに対してだけ読み書き可能で共有されます。それ以外の要求は拒否されます。accesslist に定義されるクライアントのリストは、Solaris 2.6 から拡張されました。詳細については、「share コマンドを使ってアクセスリストを設定する」 を参照してください。このオプションは -ro オプションよりも優先されます。

NFSファイルシステムで指定できるオプションは、以下のとおりです。

aclok

このオプションを指定すると、NFS バージョン 2 プロトコルをサポートしている NFS サーバが NFS バージョン 2 クライアントのアクセス制御を行うように設定できます。このオプションを指定しないと、すべてのクライアントは最低限のアクセスしかできません。指定すると、最大限のアクセスができるようになります。たとえば -aclok オプションを指定して共有したファイルシステムでは、1 人のユーザが読み取り権を持っていれば全員が読み取りを許可されます。このオプションを指定しないと、アクセス権を持つべきクライアントからのアクセスが拒否される可能性があります。アクセス権の与えすぎと制限しすぎのどちらを選ぶかは、現在のセキュリティシステムによって決定します。アクセス制御リスト (ACL) について詳細は、『Solaris のシステム管理 (第 2 巻)』の"ファイルのセキュリティの適用手順" in Solaris のシステム管理 (第 2 巻)を参照してください。

注 -

ACL を活用するためには、クライアントでもサーバでも NFS バージョン 3 と NFS_ACL プロトコルをサポートしているソフトウェアを実行します。NFS バージョン 3 プロトコルしかサポートしていないソフトウェアの場合、クライアントは正しいアクセス権を取得できますが、ACL を操作することはできません。NFS_ACL プロトコルをサポートしていれば、正しいアクセス権を取得した上で ACL の操作も可能です。この両方をサポートしているのは、Solaris 2.5 およびその互換バージョンです。

anon=uid

uid は、認証されていないユーザのユーザ ID を選択するために使用します。uid を -1 に設定すると、認証されていないユーザからのアクセスは拒否されます。anon=0 とするとルートアクセス権を与えることができますが、これは認証されていないユーザにルートアクセス権を与えることになるため、代わりに root オプションを使ってください。

index=filename

-index=filename オプションを使うと、ユーザが NFS URL にアクセスするとディレクトリのリストが表示されるのではなく、HTML (HyperText Markup Language) ファイルが強制的に読み込まれます。これは、HTTP URL がアクセスしているディレクトリに index.html ファイルが見つかるとブラウザのような動作をするというものです。このオプションを設定することは、httpd に対して DirectoryIndex オプションを指定するのと同じ意味があります。たとえば、dfstab ファイルのエントリが次のとおりであるとします。


share -F nfs -o ro,public,index=index.html /export/web

このとき、以下の URL によって表示される情報はすべて同じです。


nfs://<server>/<dir>
nfs://<server>/<dir>/index.html
nfs://<server>//export/web/<dir>
nfs://<server>//export/web/<dir>/index.html
http://<server>/<dir>
http://<server>/<dir>/index.html
nosuid

このオプションを使うと、setuid モードまたは setgid モードを有効にしようとしても無視されます。NFS クライアントは、setuid か setgid のビットがオンの状態ではファイルを作成できません。

public

-public オプションは、WebNFS ブラウズのために追加されました。このオプションで共有できるのは、1 台のサーバにつき 1 つのファイルシステムだけです。

root=accesslist

サーバが、リスト上のホストに対してルートアクセス権を与えます。デフォルトでは、サーバはどのリモートホストにもルートアクセス権は与えません。選択されているセキュリティモードが -sec=sys 以外だと、accesslist に指定できるホストはクライアントだけです。accesslist に定義されたクライアントのリストは、Solaris 2.6 で拡張されました。詳細については、「share コマンドを使ってアクセスリストを設定する」 を参照してください。

注意 - 注意 -

他のホストにルートアクセス権を与えるには、広い範囲でセキュリティが保証されていることが前提です。-root= option は十分慎重に使用してください。

sec=mode[:mode]

mode は、ファイルシステムへのアクセス権を取得するために必要なセキュリティモードです。デフォルトのセキュリティモードは、UNIX の認証です。モードは複数指定できますが、コマンド行に指定するときは 1 行につき 1 つのセキュリティモードだけにしてください。-mode の各オプションは、次に -mode が出現するまでその後の -rw、-ro、-rw=、-ro=、-root=、-window= オプションに適用されます。-sec=none とすると、すべてのユーザがユーザ nobody にマップされます。

window=value

value は、NFS サーバで資格が有効な時間の上限です。デフォルトは 30000 秒 (8.3 時間) です。

share コマンドを使ってアクセスリストを設定する

リリース 2.6 より前の Solaris で、share コマンドの -ro=、-rw=、-root= オプションに指定する accesslist の内容は、ホスト名がネットグループ名に限定されていました。Solaris 2.6 以降では、このアクセス制御リストにドメイン名、サブネット番号、およびアクセス権を与えないエントリも指定できます。この拡張により、名前空間を変更したり多数のクライアントを定義したリストを使うことなく、サーバでのファイルアクセス制御を今までより簡単に管理できます。

以下のコマンドでは、rose と lilac では読み出しと書き込みの両方のアクセスが認められますが、その他では、読み出しのみが許可されます。 


# share -F nfs -o ro,rw=rose:lilac /usr/src

以下の例では、eng ネットグループのすべてのホストで読み出しのみができるようになります。rose クライアントでは、読み出しと書き込みの両方ができます。 


# share -F nfs -o ro=eng,rw=rose /usr/src
注 -

rw と ro には必ず引数が必要です。読み書き可能オプションを指定しないと、デフォルトによってすべてのクライアントが読み書き可能になります。

1 つのファイルシステムを複数クライアントで共有するには、すべてのオプションを同じ行に指定しなければなりません。同じオブジェクトに share コマンドを複数回実行しても、最後のコマンドしか有効になりません。以下のコマンドでは、3 つのクライアントシステムで読み出しと書き込みができますが、rose と tulip では、ファイルシステムに root でアクセスできます。


# share -F nfs -o rw=rose:lilac:tulip,root=rose:tulip /usr/src

複数の認証機構を使ってファイルシステムを共有するときには、セキュリティモードの後に必ず -ro、-ro=、-rw、-rw=、-root、-window の各オプションを指定してください。この例では、eng というネットグループ内のすべてのホストに対して UNIX 認証が選択されています。これらのホストは、ファイルシステムを読み取り専用モードでしかマウントできません。ホスト tulip と lilac は、Diffie-Hellman (DH) 認証を使えば読み書き可能でファイル・システムをマウントできます。tulip と lilac は、そのホスト名が eng ネットグループのリストに含まれていれば、DH 認証を使っていなくても読み取り専用でマウントすることは可能です。


# share -F nfs -o sec=dh,rw=tulip:lilac,sec=sys,ro=eng /usr/src

UNIX 認証はデフォルトのセキュリティモードですが、-sec を指定するとデフォルトは無効になります。他の認証機構とともに UNIX 認証も使う場合には、必ず -sec=sys オプションを指定してください。

実際のドメイン名の名前にドットを付けると、アクセスリストの中で DNS ドメイン名が使えます。ドットは、その後の文字列が完全に修飾されたホスト名ではなくドメイン名であることを表します。次のエントリは、マウントから eng.sun.com ドメイン内のすべてのホストへのアクセスを許可するためのものです。


# share -F nfs -o ro=.:.eng.sun.com /export/share/man

この例で、"." はそれぞれ NIS または NIS+ 名前空間を通じて一致するすべてのホストに対応します。ネームサービスから返される結果にはドメイン名は含まれません。".eng.sun.com" というエントリは、名前空間の解決に DNS を使用するすべてのホストに一致します。DNS が返すホスト名は必ず完全に修飾されるので、DNS と他の名前空間を組み合わせると長いエントリが必要です。

実際のネットワーク番号かネットワーク名の前に "@" を指定すると、アクセスリストの中でサブネット番号が使えます。これは、ネットワーク名をネットグループ名や完全に修飾されたホスト名と区別するためです。サブネットは、/etc/networks の中か NIS または NIS+ 名前空間の中で識別できなければなりません。以下のエントリは、サブネット 129.144 が eng ネットワークと識別されるならばすべて同じ意味を持ちます。


# share -F nfs -o ro=@eng /export/share/man
# share -F nfs -o ro=@129.144 /export/share/man
# share -F nfs -o ro=@129.144.0.0 /export/share/man

2 番めと 3 番めのエントリは、ネットワークアドレス全体を指定する必要がないことを表しています。

ネットワークアドレスの先頭部分がバイトによる区切りでなく、CIDR (Classless Inter-Domain Routing) のようになっている場合には、マスクの長さをコマンド行で具体的に指定できます。この長さは、ネットワーク名かネットワーク番号の後ろにスラッシュで区切ってアドレスの接頭辞に有効ビット数として指定します。たとえば、次のようにします。


# share -f nfs -o ro=@eng/17 /export/share/man
# share -F nfs -o ro=@129.144.132/17 /export/share/man
この例で、"/17" はアドレスの先頭から 17 ビットがマスクとして使われることを表します。CIDR について詳細は、RFC 1519 を参照してください。

また、エントリの前に "-" を指定することでアクセスの拒否を示すこともできます。エントリは左から右に読み込まれるため、アクセス拒否のエントリはそれを適用するエントリの前に置く必要があることに注意してください。


# share -F nfs -o ro=-rose:.eng.sun.com /export/share/man

この例では、eng.sun.com ドメイン内のホストのうち、rose を除いたすべてに対してアクセス権が許可されます。

unshare

このコマンドを使用すると、以前に使用可能な状態になっていたファイルシステムを、クライアントがマウントできないようにします。unshare コマンドを使用すると、share コマンドで共有したファイルシステムや、/etc/dfs/dfstab で自動的に共有しているファイルシステムが共有できないようになります。unshare コマンドを使用し、dfstab ファイルで共有しているファイルシステムの共有を解除する場合は、実行レベル 3 を終了して再度実行レベル 3 に戻ると、そのファイルシステムがまた共有されることに注意してください。実行レベル 3 を終了しても変更内容を継続させるには、そのファイルシステムを dfstab ファイルから削除しなければなりません。

NFSファイルシステムの共有を解除している場合、クライアントから既存マウントへのアクセスは禁止されます。クライアントにはファイルシステムがまだマウントされている可能性がありますが、ファイルにはアクセスできません。

unshare コマンドの使用

以下のコマンドでは、指定したファイルシステムの共有が解除されます。


# unshare /usr/src

shareall

このコマンドを使用すると、複数のファイルシステムを共有することができます。オプションなしで使用すると、/etc/dfs/dfstab 内のすべてのエントリが共有されます。share コマンドを並べたファイルの名前を指定することができます。ファイル名を指定しないと、/etc/dfs/dfstab の内容が検査されます。"-" を使ってファイル名を置き換えれば、標準入力から share コマンドを入力できます。

shareall コマンドの使用

以下のコマンドでは、ローカルファイルに羅列されているすべてのファイルシステムが共有されます。 


# shareall /etc/dfs/special_dfstab

unshareall

このコマンドを使用すると、現在共有されているリソースがすべて使用できなくなります。-F FSType オプションによって、/etc/dfs/fstypes に定義されているファイルシステムタイプのリストを選択します。このフラグによって、特定のタイプのファイルシステムだけを共有解除できます。デフォルトのファイルシステムタイプは、/etc/dfs/fstypes に定義されています。特定のファイルシステムを選択するには、unshare コマンドを使います。

unshareall コマンドの使用

次の例では、NFS タイプのすべてのファイルシステムの共有が解除されます。


# unshareall -F nfs

showmount

このコマンドを使用すると、NFS サーバから共有したファイルシステムをリモートにマウントしたすべてのクライアントや、クライアントがマウントしたファイルシステム、または共有しているファイルシステムとクライアントのアクセス情報が表示されます。構文は以下のとおりです。

showmount [ -ade ] [ hostname ]

-a を指定すると、すべてのリモートマウント (クライアント名とディレクトリ) のリストが表示されます。-d を指定すると、クライアントがリモートにマウントしたディレクトリのリストが表示されます。-e では、共有 (またはエクスポート) しているファイルのリストが表示されます。hostname には、表示する情報が保存されているNFSサーバを指定します。hostname を指定しないと、ローカルホストを入力するように要求されます。

showmount コマンドの使用

以下のコマンドでは、すべてのクライアント、およびマウントしたディレクトリが表示されます。


# showmount -a bee
lilac:/export/share/man
lilac:/usr/src
rose:/usr/src
tulip:/export/share/man

以下のコマンドでは、マウントしたディレクトリが表示されます。


# showmount -d bee
/export/share/man
/usr/src

以下のコマンドでは、共有しているファイルシステムが表示されます。


# showmount -e bee
/usr/src								(everyone)
/export/share/man					eng

setmnt

このコマンドを使用すると、/etc/mnttab テーブルが作成されます。このテーブルは、mount コマンドと umount コマンドで参照されます。通常、このコマンドを使用することはありません。システムがブートされるときに自動的に使用されます。

その他のコマンド

NFS の障害追跡には以下のコマンドを使用します。

nfsstat

このコマンドを使用すると、NFS と RPC 接続について統計情報を収集できます。構文は次のとおりです。

nfsstat [ -cmnrsz ]

-c を指定すると、クライアント側の情報が表示され、-m を指定すると、マウントした各 NFS ファイルシステムの統計が表示されます。-n では、クライアントとサーバの両方の NFS 情報が表示され、-r では、RPC の統計が表示されます。-s を指定すると、サーバ側の情報が表示され、-z を指定すると、統計がゼロに設定されます。コマンド行にオプションを指定しないと、-cnrs が使用されます。

新しいソフトウェアやハードウェアを処理環境に追加した場合、サーバ側の統計を収集することが、デバッグにたいへん役立ちます。このコマンドを週に最低 1 度は実行し、履歴を作成するようにしてください。統計を保存しておくと、以前の効率のよい記録になります。

nfsstat コマンドの使用

# nfsstat -s
 
Server rpc:
Connection oriented:
calls      badcalls   nullrecv   badlen      xdrcall    dupchecks  dupreqs
11420263   0          0          0           0          1428274    19
Connectionless:
calls      badcalls   nullrecv   badlen      xdrcall    dupchecks  dupreqs
14569706   0          0          0           0          953332     1601
 
Server nfs:
calls      badcalls
24234967   226
Version 2: (13073528 calls)
null       getattr    setattr    root        lookup     readlink   read
138612 1%  1192059 9% 45676 0%   0 0%        9300029 71% 9872 0%   1319897 10%
wrcache    write      create     remove      rename     link       symlink
0 0%       805444 6%  43417 0%   44951 0%    3831 0%    4758 0%    1490 0%
mkdir      rmdir      readdir    statfs
2235 0%    1518 0%    51897 0%   107842 0%
Version 3: (11114810 calls)
null       getattr    setattr    lookup      access     readlink   read
141059 1%  3911728 35% 181185 1% 3395029 30% 1097018 9% 4777 0%   960503 8%
write      create     mkdir      symlink     mknod      remove     rmdir
763996 6%  159257 1%  3997 0%    10532 0%    26 0%      164698 1%  2251 0%
rename     link       readdir    readdirplus fsstat     fsinfo     pathconf
53303 0%   9500 0%    62022 0%   79512 0%    3442 0%    34275 0%   3023 0%
commit    
73677 0% 
 
Server nfs_acl:
Version 2: (1579 calls)
null       getacl     setacl     getattr     access
0 0%       3 0%       0 0%       1000 63%    576 36%
Version 3: (45318 calls)
null       getacl     setacl
0 0%       45318 100% 0 0%

上記は、NFS サーバの統計です。最初の 5 行は RPC に関するもので、残りの部分は NFS のアクティビティのレポートです。どちらの統計でも総コール数に対する badcallsi の数や 1 週間あたりの calls 数がわかるので、障害が発生した時点を突き止めのに役立ちます。badcallsiの値は、クライアントからの不良メッセージの数を表すもので、ネットワーク上のハードウェアにおける問題を突き止められます。

いくつかの接続では、ディスクに対する書き込みアクティビティが発生します。この数値の急激な上昇は障害の可能性を示すものなので、調査が必要です。NFS バージョン 2 の場合、特に注意しなければならない接続は、 setattr、write、create、remove、rename、link、symlink、mkdir、および rmdir です。 NFS バージョン 3 の場合には、commit の値に特に注意します。ある NFSサーバの commit レベルが、それと同等のサーバと比較して高い場合は、NFS クライアントに十分なメモリがあるかどうかを確認してください。サーバの commit オペレーションの数は、クライアントにリソースがない場合に上昇します。

pstack

このコマンドを使用すると、各プロセスにおけるスタックトレースが表示されます。root で実行しなければなりません。プロセスがハングした場所を判断するのに使用します。使用できるオプションは、チェックするプロセスの PID だけです (proc(1) のマニュアルページ参照)。

以下の例では、実行中の nfsd プロセスをチェックしています。


# /usr/proc/bin/pstack 243
243:    /usr/lib/nfs/nfsd -a 16
 ef675c04 poll     (24d50, 2, ffffffff)
 000115dc ???????? (24000, 132c4, 276d8, 1329c, 276d8, 0)
 00011390 main     (3, efffff14, 0, 0, ffffffff, 400) + 3c8
 00010fb0 _start   (0, 0, 0, 0, 0, 0) + 5c

プロセスが新規の接続要求を待っていることが示されています。これは、正常な反応です。要求が行われた後でもプロセスがポーリングしていることがスタックから分かった場合、そのプロセスはハングしている可能性があります。「NFS サービスの再起動」 の指示に従って問題を解決してください。ハングしたプログラムによって問題が発生しているかどうかを確実に判断するには、「NFS の障害追跡手順」 を参照してください。

rpcinfo

このコマンドは、システムで動作している RPC サービスに関する情報を生成します。RPC サービスの変更にも使用できます。このコマンドには、たくさんのオプションがあります (rpcinfo(1M) のマニュアルページ参照)。以下は、このコマンドで使用できるオプションの概要です。

rpcinfo [ -m | -s ] [ hostname ]

rpcinfo [ -t | -u ] [ hostname ] [ progname ]

-m は rpcbind 操作の統計テーブル、-s は登録済みの RPC プログラムすべての簡易リスト、-t は TCP を使う RPC プログラム、-u は UDP を使う RPC プログラムを表示します。hostname は情報を取得する元のサーバ、progname は情報を収集する対象の RPC プログラムです。hostname を指定しないと、ローカルホスト名が使われます。progname の代わりに RPC プログラム番号が使えますが、ユーザが覚えやすいのは番号よりも名前です。NFS バージョン 3 が実行されていないシステムでは、-s オプションの代わりに -p オプションが使えます。

このコマンドで生成されるデータには、以下のものがあります。

rpcinfo コマンドの使用

以下の例では、サーバで実行している RPC サービスに関する情報を収集しています。生成されたテキストには sort コマンドのフィルタをかけ、より読みやすくしています。この例では、RPC サービスの数行を省略しています。

% rpcinfo -s bee |sort -n
   program version(s) netid(s)                         service     owner
    100000  2,3,4     udp,tcp,ticlts,ticotsord,ticots  portmapper  superuser
    100001  4,3,2     ticlts,udp                       rstatd      superuser
    100002  3,2       ticots,ticotsord,tcp,ticlts,udp  rusersd     superuser
    100003  3,2       tcp,udp                          nfs         superuser
    100005  3,2,1     ticots,ticotsord,tcp,ticlts,udp  mountd      superuser
    100008  1         ticlts,udp                       walld       superuser
    100011  1         ticlts,udp                       rquotad     superuser
    100012  1         ticlts,udp                       sprayd      superuser
    100021  4,3,2,1   ticots,ticotsord,ticlts,tcp,udp  nlockmgr    superuser
    100024  1         ticots,ticotsord,ticlts,tcp,udp  status      superuser
    100026  1         ticots,ticotsord,ticlts,tcp,udp  bootparam   superuser
    100029  2,1       ticots,ticotsord,ticlts          keyserv     superuser
    100068  4,3,2     tcp,udp                          cmsd        superuser
    100078  4         ticots,ticotsord,ticlts          kerbd       superuser
    100083  1         tcp,udp                          -           superuser
    100087  11        udp                              adm_agent   superuser
    100088  1         udp,tcp                          -           superuser
    100089  1         tcp                              -           superuser
    100099  1         ticots,ticotsord,ticlts          pld         superuser
    100101  10        tcp,udp                          event       superuser
    100104  10        udp                              sync        superuser
    100105  10        udp                              diskinfo    superuser
    100107  10        udp                              hostperf    superuser
    100109  10        udp                              activity    superuser
	.
	.
    100227  3,2       tcp,udp                          -           superuser
    100301  1         ticlts                           niscachemgr superuser
    390100  3         udp                              -           superuser
1342177279  1,2       tcp                              -           14072

次の例では、サーバの特定トランスポートを使用している RPC サービスの情報を収集する方法について説明しています。


% rpcinfo -t bee mountd
program 100005 version 1 ready and waiting
program 100005 version 2 ready and waiting
program 100005 version 3 ready and waiting
% rpcinfo -u bee nfs
program 100003 version 2 ready and waiting
program 100003 version 3 ready and waiting

最初の例では、TCP で実行している mountd サービスをチェックしています。2 番目の例では、UDP で実行している NFS サービスをチェックしています。

snoop

このコマンドは、ネットワーク上のパケットの監視によく使用されます。root として実行しなければなりません。クライアントとサーバの両方で、ネットワークハードウェアが機能しているかどうかを確認する方法としてよく使用されます。使用できるオプションは多数あります (snoop(1M) のマニュアルページ参照)。以下で、このコマンドの概要を説明します。

snoop [ -d device ] [ -o filename ] [ host hostname ]

-d device には、ローカルネットワークインタフェースを指定します。-o filename には、取り込んだすべてのパケットを保存するファイルを指定します。hostname には、表示するパケットが通過したホストを指定します。

-d device オプションは、複数のネットワークインタフェースがあるサーバで特に有効です。ホストの設定以外にも、使用できる式が多数あります。コマンド式を grep で組み合わせることでも、十分に使用できるデータを生成できます。

障害追跡をする場合は、パケットの発信元と送信先のホストが正しいことを確認してください。また、エラーメッセージも調べてください。パケットをファイルに保存すると、データの検査が容易になります。

truss

このコマンドを使用すると、プロセスがハングしたかどうかを確認できます。root で実行しなければなりません。このコマンドに指定できるオプションは多数あります (truss(1) のマニュアルページ参照)。構文の概要は以下のとおりです。

truss [ -t syscall ] -p pid

-t syscall には、追跡するシステムコールを指定します。-p pid には、追跡するプロセスの PID を指定します。syscall には、追跡するシステムコールをカンマで区切って指定することもできます。また、syscall の指定を ! で始めると、そのシステムコールは追跡されなくなります。

次の例は、プロセスが新しいクライアントからの接続要求を待っていることを示しています。 


# /usr/bin/truss -p 243
poll(0x00024D50, 2, -1)         (sleeping...)

これは正常な反応です。新規接続の要求が行われた後でも反応が変わらない場合、そのプロセスはハングしている可能性があります。「NFS サービスの再起動」 の指示に従ってプログラムを修正してください。ハングしたプログラムによって問題が発生しているかどうかを確実に判断するには、「NFS の障害追跡手順」 を参照してください。

コマンドを組み合わせて使う

以下の節では、NFS の複雑な機能をいくつか紹介します。

バージョン 2 とバージョン 3 のネゴシエーション

NFS サーバがサポートしているクライアントが NFS バージョン 3 を使っていない場合に備えて、開始手順にはプロトコルレベルのネゴシエーションが含まれています。クライアントとサーバの両方がバージョン 3 をサポートしていると、バージョン 3 が使われます。どちらか片方でもバージョン 2 しかサポートしていないと、バージョン 2 が使われます。

ネゴシエーションによって決まった値は、mount コマンドに対して -vers オプションを使うことで変更できます (マニュアルページの mount_nfs(1M) を参照してください)。ほとんどの場合、デフォルトによって最適なバージョンが選択されるため、ユーザが指定する必要はありません。

UDP と TCP のネゴシエーション

開始時には、トランスポートプロトコルもネゴシエーションされます。デフォルトでは、クライアントとサーバの両方がサポートしているコネクション型トランスポートの中で最初に見つかったものが選択されます。それが見つからない場合には、コネクションレス型トランスポートプロトコルの中で最初に見つかったものが使われます。システムでサポートされているトランスポートプロトコルのリストは、/etc/netconfig にあります。TCP はコネクション型トランスポートプロトコルで、Solaris 2.6 でサポートされています。UDP はコネクションレス型トランスポートプロトコルです。

NFS プロトコルのバージョンとトランスポートプロトコルが両方ともネゴシエーションによって決まった場合は、NFS プロトコルのバージョンがトランスポートプロトコルよりも優先されます。UDP を使う NFS バージョン 3 プロトコルの方が、TCP を使う NFS バージョン 2 プロトコルよりも優先されます。mount コマンドでは NFS プロトコルのバージョンもトランスポートプロトコルも手動で選択できます (マニュアルページの mount_nfs(1M) を参照してください)。ほとんどの場合、ネゴシエーションによって選択されるオプションの方が適切です。

ファイル転送サイズのネゴシエーション

ファイル転送サイズは、クライアントとサーバの間でデータを転送するときに使われるバッファのサイズです。原則として、ファイル転送サイズが大きいほどパフォーマンスが向上します。NFS バージョン 3 には転送サイズに上限はありませんが、Solaris 2.6 以降がデフォルトで提示するバッファサイズは 32 キロバイトです。クライアントは、必要であればマウント時にこれより小さい転送サイズを提示することができますが、ほとんどの場合必要ありません。

転送サイズは、NFS バージョン 2 を使っているシステムとはネゴシエーションされません。このとき、ファイル転送サイズの上限は 8 キロバイトに設定されます。

mount コマンドに対して -rsize オプションと -wsize オプションを使うと、転送サイズを手動で設定できます。PC クライアントの一部では転送サイズを小さくする必要があります。また、NFS サーバが大きなファイル転送サイズに設定されている場合には、転送サイズを大きくすることができます。

ファイルシステムのマウントの詳細

クライアントがサーバからファイルシステムをマウントするとき、そのファイルシステムに対応するファイルハンドルをサーバから取得する必要があります。そのためには、クライアントとサーバの間でいくつかのトランザクションが発生します。この例では、クライアントはサーバから /home/terry をマウントします。snoop によって追跡したトランザクションは、次のとおりです。 


client -> server PORTMAP C GETPORT prog=100005 (MOUNT) vers=3 proto=UDP
server -> client PORTMAP R GETPORT port=33492
client -> server MOUNT3 C Null
server -> client MOUNT3 R Null
client -> server MOUNT3 C Mount /export/home9/terry
server -> client MOUNT3 R Mount OK FH=9000 Auth=unix
client -> server PORTMAP C GETPORT prog=100003 (NFS) vers=3 proto=TCP
server -> client PORTMAP R GETPORT port=2049
client -> server NFS C NULL3
server -> client NFS R NULL3
client -> server NFS C FSINFO3 FH=9000
server -> client NFS R FSINFO3 OK
client -> server NFS C GETATTR3 FH=9000
server -> client NFS R GETATTR3 OK

この追跡結果では、クライアントがまずマウントポート番号を NFS サーバの portmap サービスに要求します。クライアントが取得したマウントポート番号 (33492) は、サーバに対する存在確認のために使用されます。このポート番号でサービスが実行中であることが確認できると、クライアントはマウントを要求します。この要求により、サーバはマウントされるファイルシステムに対するファイルハンドル (9000) を送ります。これに対してクライアントは、NFS ポート番号を要求します。クライアントはサーバからポート番号を受け取り、NFS サービス (nfsd) を ping してから、ファイルハンドルを使用してファイルシステムに関する NFS 情報を要求します。

次の追跡結果では、クライアントは -public オプションを使用してファイルシステムをマウントしています。 


client -> server NFS C LOOKUP3 FH=0000 /export/home9/terry
server -> client NFS R LOOKUP3 OK FH=9000
client -> server NFS C FSINFO3 FH=9000
server -> client NFS R FSINFO3 OK
client -> server NFS C GETATTR3 FH=9000
server -> client NFS R GETATTR3 OK

デフォルトの公共ファイルハンドル (0000) を使用しているために、すべてのトランザクションにポートマップサービスから情報が与えられ、NFS ポート番号を決定するためのトランザクションはありません。

マウント時の -public オプションと NFS URL の意味

-public オプションを使用すると、マウントが失敗することがあります。NFS URL を組み合わせると、状況がさらに複雑になる可能性があります。これらのオプションを使用した場合にファイルシステムがどのようにマウントされるかは、次のとおりです。

クライアント側障害時回避機能

クライアント側障害時回避機能を使うと、複製されたファイルシステムをサポートしているサーバが使用不能になったときに、NFS クライアントは別のサーバに切り替えることができます。ファイルシステムが使用不能になる原因としては、接続しているサーバのクラッシュ、サーバの過負荷、ネットワーク障害が考えられます。通常、このような場合の障害時回避機能はユーザには分かりません。設定が行われていれば、障害時回避機能はクライアント上のプロセスを中断することなく実行されます。

障害時回避機能が行われるためには、ファイルシステムが読み取り専用でマウントされている必要があります。また、ファイルシステムが完全に同じでないと障害時回避機能は成功しません。ファイルシステムが同一になる条件については、「複製されたファイルシステムとは」 を参照してください。障害時回避機能の候補としては、静的なファイルシステム、または変更の少ないファイルシステムが適しています。

CacheFS を使ってマウントされたファイルシステムは、障害時回避機能には使えません。CacheFS ファイルシステムは、それぞれについて追加情報が格納されています。この情報は障害時回避の際に更新できないため、ファイルシステムをマウントするときには障害時回避機能と CasheFS のどちらか片方の機能しか使えません。

各ファイルシステムについて用意すべき複製の数を決める要素はさまざまです。一般的に、サーバを何台か用意してそれぞれが複数のサブネットをサポートするという環境の方が、サブネット 1 つについて 1 台のサーバを用意するよりもすぐれています。この場合、リストにあるサーバを 1 台ずつチェックする必要があるため、リスト上のサーバが増えるにつれてマウントにかかる時間も増えます。

障害時回避機能に関する用語

障害時回避機能のプロセスを完全に理解するには、以下の 2 つの用語を理解しておく必要があります。

複製されたファイルシステムとは

障害時回避機能に関して、あるファイルシステムのすべてのファイルが元のファイルシステムのファイルとサイズも vnode タイプも同じ場合に、そのファイルシステムを「複製」といいます。アクセス権、作成日付などのファイル属性は関係ありません。ファイルサイズか vnode タイプが異なると再マッピングは失敗し、元のサーバが再び使用可能になるまでプロセスはハングします。

複製されたファイルシステムを保守するには、rdist や cpio などのファイル転送機構を使います。複製されたファイルシステムを更新すると不整合が発生するので、できるだけ以下を守ってください。

障害時回避機能と NFS ロック

ソフトウェアパッケージの一部は、ファイルに読み取りロックをかける必要があります。そのようなソフトウェアが正常に動作できるようにするため、読み取り専用ファイルシステムに対しても読み取りロックがかけられるようになっています。ただし、これはクライアント側でしか認識されません。サーバ側で意識されないため、再マッピングされてもロックはそのまま残ります。ファイルはもともと変更が許されないので、サーバ側でファイルをロックする必要はありません。

大型ファイル

Solaris 2.6 およびその互換バージョンでは、2 ギガバイトを超えるファイルを扱えます。デフォルトでは、UFS ファイルシステムはこの新機能を活かすために -largefiles オプション付きでマウントされます。以前のリリースでは、2 ギガバイトを超えるファイルは扱えません。具体的な方法については 「NFS サーバ上の大型ファイルを無効にする方法」 を参照してください。

サーバのファイルシステムが -largefiles オプション付きでマウントされていれば、Solaris 2.6 の NFS クライアントでは何も変更しなくても大型ファイルにアクセスできます。しかし、Solaris 2.6 のコマンドすべてで大型ファイルが扱えるわけではありません。大型ファイルを処理可能なコマンドのリストは、largefile(5) を参照してください。大型ファイル用機能拡張を備えた NFS バージョン 3 プロトコルをサポートしていないクライアントは、大型ファイルには一切アクセスできません。Solaris 2.5 クライアントでは、NFS バージョン 3 プロトコルを使うことはできますが、大型ファイルを扱う機能は含まれていません。

WebNFS サービスの動作方法

WebNFS サービスとは、あるディレクトリに置かれたファイルを、公開ファイルハンドルを使ってクライアントからアクセスできるようにするものです。ファイルハンドルは、NFS クライアントがファイルを識別できるようにカーネルが生成するアドレスです。公開ファイルハンドル の値はあらかじめ決まっているため、サーバがクライアントに対してファイルハンドルを生成する必要はありません。定義済みのファイルハンドルを使用するというこの機能によって、MOUNT プロトコルが不要になってネットワークトラフィックが減り、クライアントにとってはパフォーマンスが向上します。

デフォルトでは、NFS サーバの公開ファイルハンドルはルートファイルシステムに対して設定されます。このデフォルトのため、サーバに対してマウント権限を持っているすべてのクライアントに対して WebNFS アクセス権が与えられます。公開ファイルハンドルは、share コマンドによって任意のファイルシステムに切り替えることができます。

あるファイルシステムに対するファイルハンドルをクライアントが持っているとき、アクセスするファイルに対応するファイルハンドルを知るには LOOKUP を実行します。 NFS プロトコルでは、パス名の構成要素を 1 度に 1 つしか評価できません。したがって、ディレクトリ階層のレベルが 1 つ増えるたびに 1 回ずつ LOOKUP を実行します。公開ファイルハンドルからの相対パスに対して LOOKUP を実行する場合には、WebNFS サーバは複数構成要素参照という方法によって 1 度にパス名全体を評価できます。複数構成要素参照を使うことにより、WebNFS サーバはパス名の中のディレクトリレベルを 1 つずつファイルハンドルに変換しなくても目的のファイルに対するファイルハンドルを取得できます。

また、NFS クライアントは単一の TCP 接続上で同時に複数のダウンロードを行うこともできます。これにより、複数の接続を設定することによる余分な負荷をサーバにかけずに、高速なアクセスが実現できます。Web ブラウザアプリケーションも複数ファイルを同時にダウンロードできますが、それぞれのファイルに独自の接続が確立されます。WebNFS ソフトウェアは接続を 1 つしか使わないため、サーバに対するオーバーヘッドを軽減できます。

パス名の中の最後の構成要素が他のファイルシステムに対するシンボリックリンクである場合、通常の NFS アクティビティによってあらかじめそのファイルへのアクセス権を持っていれば、クライアントはそのファイルにアクセスできます。

通常、NFS URL は公開ファイルハンドルからの相対位置として評価されます。パスの先頭にスラッシュを 1 つ追加すると、サーバのルートファイルシステムからの相対位置に変更できます。次の例では、公開ファイルハンドルが /export/ftp ファイルシステムに設定されていればこの 2 つの NFS URL は同等です。


nfs://server/junk
nfs://server//export/ftp/junk

Web ブラウザと比較した場合の WebNFS の制約

HTTP を使う Web サイトで実現可能な機能のいくつかは、WebNFS ではサポートされていません。この違いは、NFS サーバはファイルを送るだけであるため、特別な処理はすべてクライアントで行う必要があることが原因です。ある Web サイトを WebNFS と HTTP 両方のアクセスに対応させるには、以下を考慮してください。

Secure NFS システム

NFS 環境は、アーキテクチャやオペレーティングシステムの異なるコンピュータから構成されるネットワーク上でファイルシステムを共有するためには、強力で使いやすい手段です。しかし、NFS の操作によるファイルシステムの共有を便利にする機能が、一方ではセキュリティ上の問題につながっています。今まで、NFS はほとんどのバージョンで UNIX (AUTH_SYS) 認証を使ってきましたが、現在では AUTH_DH のようなより強力な認証方式も使用可能です。UNIX 認証の場合、NFS サーバはファイル要求を認証するために、その要求を行ったユーザではなくコンピュータを認証します。したがって、クライアント側のユーザがスーパーユーザでログインすると、ファイルの所有者になりすますことができます。DH 認証では、NFS サーバはユーザを認証するため、この様な操作が困難になります。

ルートへのアクセス権とネットワークプログラミングについての知識があれば、だれでも任意のデータをネットワークに入れ、ネットワークから任意のデータを取り出すことができます。ネットワークに対する最も危険な攻撃は、有効なパケットを生成したり、または "対話" 対話を記録し後で再生することによってユーザを装うなどの手段により、データをネットワークに持ち込むことです。これらはデータの整合性に影響を与えます。許可を持つユーザを装うことなく、単にネットワークトラフィックを受信するだけの受動的な盗み聞きならば、データの整合性が損なわれることはないため、それほど危険ではありません。ユーザはネットワークに送信されるデータを暗号化することによって、機密情報のプライバシーを守ることができます。

ネットワークのセキュリティ問題における共通の対処方法は、解決策を各アプリケーションにゆだねることです。さらに優れた手法としては、すべてのアプリケーションを対象として、標準の認証システムを導入することです。

Solaris オペレーティングシステムには、NFS が実装されるメカニズムである遠隔手続き呼び出し (RPC) のレベルで、認証システムが組み込まれています。このシステムは Secure RPC と呼ばれ、ネットワーク環境のセキュリティを大幅に向上させるとともに、NFS のセキュリティを強化します。Secure RPC の機能を利用した NFS システムを、Secure NFS システムと呼びます。

Secure RPC

Secure RPC は Secure NFS システムの基本となるメカニズムです。Secure RPC の目標は、少なくともタイムシェアリングシステム (すべてのユーザが 1 台のコンピュータを共有するシステム) 程度に安全なシステムを構築することです。タイムシェアリングシステムはログインパスワードによりユーザを認証します。DES (Data Encryption Service) 認証でもこれは同じです。ユーザは、ローカル端末の場合と同じように、任意のリモートコンピュータにログインできます。ユーザのログインパスワードは、ネットワークセキュリティへのパスポートです。タイムシェアリングでは、システム管理者は信頼のおける人で、パスワードを変更してだれかを装うようなことはしないという道徳上の義務を負います。Secure RPC では、ネットワーク管理者は「公開鍵」を格納するデータベースのエントリを変更しないという前提で信頼されています。

RPC 認証システムを理解するには、「資格 (credential)」と「ベリファイア」という 2 つの用語を理解する必要があります。ID バッジを例にとれば、資格とは、名前、住所、誕生日など人間を識別するものです。ベリファイアとはバッジに添付された写真であり、バッジの写真をその所持者と照合することによって、そのバッジが盗まれたものではないことを確認できます。RPC では、クライアントプロセスは RPC 要求のたびに資格とベリファイアの両方をサーバに送信します。クライアントはサーバの資格をすでに知っているため、サーバはベリファイアだけを送り返します。

RPC の認証機能は拡張が可能で、さまざまな認証システムを組み込むことができます。現在のところ、このようなシステムには UNIX、DH、KERB (Kerberos バージョン 4) の 3 つがあります。

ネットワークサービスで UNIX 認証を使用する場合、資格にはクライアントのコンピュータ名、UID、GID、グループアクセスリストが含まれ、ベリファイアには何も含まれません。ベリファイアが存在しないため、ルートユーザは su などのコマンドを使用して、適切な資格を偽ることができます。UNIX 認証でのもう 1 つの問題は、ネットワーク上のすべてのコンピュータを UNIX コンピュータと想定していることです。UNIX 認証を異機種ネットワーク内のほかのオペレーティングシステムに適用した場合、これは正常に動作しません。

UNIX 認証の欠点を補うために、Secure RPC では DH 認証か KERB 認証を使います。

DH 認証

DH 認証は、Data Encryption Standard (DES) と Diffie-Hellman 公開鍵暗号手法を使用してネットワーク上のユーザとコンピュータの両方を認証します。DES は標準暗号化機能であり、Diffie-Hellman 公開鍵暗号手法は、公開鍵と非公開鍵という 2 つの鍵を使用する暗号方式です。公開鍵と非公開鍵は名前空間に格納されます。NIS の場合、それらの鍵を publickey マップに格納し、NIS+ は cred テーブルに格納します。これらのマップにはすべての認証の候補ユーザの公開鍵と非公開鍵が入っています。マップとテーブルの設定については、『Solaris ネーミングの管理』を参照してください。

DH 認証のセキュリティは、送信側が現在時刻を暗号化する機能に基づいていて、受信側はこれを復号して、自分の時刻と照合します。タイムスタンプは DES を使って暗号化されます。この方式が機能するには次の条件が必要です。

ネットワークが時間同期プログラムを実行する場合、クライアントとサーバ上の時間は自動的に同期されます。時間同期プログラムを使用できない場合、ネットワーク時間ではなく、サーバの時間を使用してタイムスタンプを計算できます。クライアントは、RPC セッションを開始する前にサーバに時間を要求し、自分のクロックとサーバのクロックとの時間差を計算します。タイムスタンプを計算するときには、この差を使用してクライアントのクロックを補正します。サーバがクライアントの要求を拒否するほど、クライアントとサーバのクロック同期がずれた場合、DH 認証システムはサーバとの間で再び同期をとります。

クライアントとサーバは、ランダムな対話鍵 (セッションキーとも呼びます) を生成することによって、同じ暗号化鍵に到達します。次に、公開鍵暗号手法 (公開鍵と秘密鍵を必要とする暗号化方式) を使用して共通鍵を推理します。この共通鍵は、クライアントとサーバだけが推理できる鍵です。対話鍵は、クライアントのタイムスタンプを暗号化および復号化するために使用されます。共通鍵は、この対話鍵を暗号化および復号化するために使用されます。

KERB 認証

Kerberos は MIT で開発された認証方式です。Kerberos での暗号化は DES に基づいています。

Kerberos はユーザのログインパスワードを認証することにより機能します。ユーザは kinit コマンドを入力しますが、このコマンドは、認証サーバからセッション時間 (またはデフォルトセッション時間の 8 時間) の間有効であるチケットを得ます。ユーザがログアウトするときに、このチケットは kdestroy コマンドを使って削除できます。

Kerberos ソフトウェアは、SunOS ソフトウェアの一部ではなく、 MIT の Athena プロジェクトから入手できます。SunOS ソフトウェアは次のソフトウェアを提供します。

詳細については、『Solaris のシステム管理 (第 2 巻)』の「Secure RPC の概要」を参照してください。

NFS での Secure RPC の使用

Secure RPC を使う場合は、以下の点に注意してください。