Linux NFS-HOWTO

Tavis Barr

         tavis dot barr at liu dot edu
       

Nicolai Langfeldt

         janl at linpro.no
       

Seth Vidal

        skvidal at phy dot duke dot edu
      

Tom McNeal

        trmcneal at attbi dot com
      

中野武雄 - (日本語訳)

        nakano@apm.seikei.ac.jp
      

2002-11-16 (original: 2002-08-25)

Revision History                                                       
Revision v3.1          2002-08-25        Revised by: tavis             
Typo in firewalling section in 3.0                                     
Revision v3.0          2002-07-16        Revised by: tavis             
Updates plus additions to performance, security                        

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

Table of Contents
1. 前書き
   
    1.1. 法的なこと
    1.2. 免責
    1.3. フィードバック
    1.4. 謝辞
   
2. はじめに
   
    2.1. NFS とは何か?
    2.2. この HOWTO は何か (そして何ではないか)
    2.3. 事前に必要とされる知識
    2.4. 事前に必要となるソフトウェア: カーネルバージョンと nfs-utils
    2.5. ヘルプやより詳細な情報のありか
   
3. NFS サーバの設定
   
    3.1. サーバ設定の概略
    3.2. 設定ファイルの編集
    3.3. サービスを開始する
    3.4. NFS が動作しているか確認する
    3.5. /etc/exports をあとから変更する
   
4. NFS クライアントの設定
   
    4.1. リモートのディレクトリをマウントする
    4.2. NFS ファイルシステムをブート時にマウントさせる
    4.3. マウントのオプション
   
5. NFS の性能を最適化する
   
    5.1. ブロックサイズを設定して転送速度を最適化する
    5.2. パケットサイズとネットワークドライバ
    5.3. フラグメントされたパケットのオーバーフロー
    5.4. NFS over TCP
    5.5. タイムアウトと再送の値
    5.6. NFSD のインスタンスの数
    5.7. 入力キューのメモリ制限
    5.8. NIC とハブの自動ネゴシエーションを無効にする
    5.9. NFS の同期動作と非同期動作
    5.10. サーバの性能をあげる NFS 以外の方法
   
6. セキュリティと NFS
   
    6.1. ポートマッパ
    6.2. サーバのセキュリティ: nfsd と mountd
    6.3. クライアントのセキュリティ
    6.4. NFS とファイアウォール (ipchains と iptables)
    6.5. NFS に SSH をトンネルさせる
    6.6. まとめ
   
7. トラブルシュート
   
    7.1. マウントしたファイルシステムでファイルが見えない
    7.2. ファイルリクエストがハングしたり、アクセス待ちでタイムアウトす
        る
    7.3. ファイルシステムをマウントできない
    7.4. マウントしたボリュームで、ファイルにアクセスする権限がありませ
        ん
    7.5. 非常に大きなファイルを転送すると、 NFS がサーバの CPU を取って
        しまって、止まったようになってしまいます
    7.6. ログに奇妙なエラーメッセージが出る
    7.7. 実際のパーミッションが /etc/exports の指定と異なる
    7.8. おかしな、不安定な振舞いをする
    7.9. nfsd が起動しない
    7.10. 複数のクライアントを使うとファイルが壊れる
   
8. Linux の NFS を他の OS と使う
   
    8.1. AIX
    8.2. BSD
    8.3. Tru64 Unix
    8.4. HP-UX
    8.5. IRIX
    8.6. Solaris
    8.7. SunOS
   
1. 前書き

1.1. 法的なこと

Copyright (c) <2002> by Tavis Barr, Nicolai Langfeldt, Seth Vidal, and
Tom McNeal. This material may be distributed only subject to the terms
and conditions set forth in the Open Publication License, v1.0 or later
(the latest version is presently available at http://
www.opencontent.org/openpub/).

(参考訳) Copyright (c) 2002 Travis Barr, Nicolai Langfeldt, Seth Vidal,
and Tom McNeal. この文書は、Open Publication License v1.0 およびそれ以
降 (最新版は http://www.opencontent.org/openpub/ にあります。この日本語
訳は http://www.opensource.jp/openpub/ にあります) の条項・条件に従えば
再配布できます。

翻訳は中野武雄が行いました。 Copyright (C) 1997-2002 Takeo Nakano. ライ
センスは同じく Open Publication License v1.0 (オプションなし) およびそ
れ以降に従います。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

1.2. 免責

This document is provided without any guarantees, including
merchantability or fitness for a particular use. The maintainers cannot
be responsible if following instructions in this document leads to
damaged equipment or data, angry neighbors, strange habits, divorce, or
any other calamity.

この文書の提供にあたっては、商用であるか否か、特定の目的に適応するかし
ないか等を含め、何の保証もありません。この文書の以下における説明によっ
て機器やデータが被害を受けたり、近所の人が怒ったり、変な癖がついてしま
ったり、離婚することになったり、その他あらゆる不幸が生じたとしても、こ
の文書の管理者は何の責任も負うことができません。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

1.3. フィードバック

この文書はまだまだ完成したものではありません。この文書を向上させるため
のフィードバックを歓迎します。 2002 年 2 月の時点においては、Linux NFS
ホームページは http://nfs.sourceforge.net です。メーリングリスト・バグ
フィックス・更新に関してや、現在のこの文書の管理者については、こちらの
ページをチェックしてください。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

1.4. 謝辞

Linux の NFS は多くの人の協力によって可能になりました。しかし中でも何人
かの人々は特に示しておく価値があるでしょう。オリジナルのバージョンは
Olaf Kirch と Alan Cox によって開発されました。version 3 サーバのコード
は、 Saadia Khan, James Yarbrough, Allen Morris, H.J. Lu らの作業をもと
に、Neil Brown が堅牢なものにしました (彼自身もオリジナルの作業者に含ま
れます)。クライアントのコードは Olaf Kirch が書き、 Trond Myklebust が
更新しています。 version 4 のロックマネージャは Saadia Khan が開発しま
した。 Dave Higgen と H.J. Lu の二人が感謝されることの少ない仕事を引き
受け、管理維持とバグフィックスを積極的に行い、コードが期待通りに動作す
るようにしてくれました。もちろん感謝すべき人はまだまだたくさんいます。

この文書のオリジナル版は Nicolai Langfeldt が書きました。 2000 年に
Tavis Barr と Seth Vidal によって多くの部分が書き換えられ、 2.0 カーネ
ルから 2.4 カーネルの間に開発された、 Linux 用 NFS でのさまざまな変更が
反映されました。 2002 年 2 月に再度編集され、Tom McNeal が性能に関する
部分にたくさんの追加を行いました。 Thomas Emmel, Neil Brown, Trond
Myklebust, Erez Zadok, Ion Badulescu らが、価値あるコメントと貢献を寄せ
てくれました。

訳注: 翻訳に際しては、JF ML の皆さんにお世話になりました。特にかねこさ
んと武井さんには、全体を通して有益なコメントをいただきました。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

2. はじめに

2.1. NFS とは何か?

Network File System (NFS) は、リモートマシンのディスクパーティションを
ローカルのハードディスクのようにマウント可能とするために開発されました
。 NFS を用いると、ネットワークを介して、高速かつシームレスなファイル共
有が可能になります。

一方 NFS の設定を間違えると、望ましくない人々があなたのハードドライブに
対してネットワーク経由でアクセスできてしまう可能性も生じます (そしてメ
ールを読まれたり、すべてのファイルを消されたり、システムに侵入されるか
もしれません)。ですから、NFS の設定を行うつもりなら、この文書のセキュリ
ティの章を注意してよく読んでください。

NFS と同様の機能を提供するシステムは他にもあります。 Samba (http://
www.samba.org) は Windows クライアントにファイルサービスを提供します。
最近オープンソースになった IBM の Andrew File System (http://
www.transarc.com/Product/EFS/AFS/index.html) もファイル共有機構を提供し
、さらにセキュリティや性能を向上させるための機能も追加されています。
Coda File System (http://www.coda.cs.cmu.edu/) は、この文書を書いている
時点ではまだ開発の段階ですが、接続が失われたクライアントでもうまく動作
するように設計されています。 Andrew File System や Coda File System の
機能の多くは、次の版の NFS (Version 4)に取り込まれる予定です (http://
www.nfsv4.org)。今日における NFS の利点は、成熟していること、標準である
こと、よく分かっていること、たくさんのプラットフォームで堅固にサポート
されていること、です。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

2.2. この HOWTO は何か (そして何ではないか)

この HOWTO は、NFS を正しくかつ効率的に設定するための、完全なステップバ
イステップのガイドとなるべく執筆されています。 NFS の設定は 2 つの段階
からなります。すなわちサーバの設定とクライアントの設定です。さらにこの
文書は、特定の用途に NFS を用いる人向けのヒントや、ハードウェアの設定、
セキュリティ、トラブルシュート等に参考となる情報を提供しています。

この HOWTO は NFS の中身や下層構造を記述するものではありません。その目
的には、Erez Zadok の Linux NFS and Automounter Administration (Sybex,
2001) が良いでしょう。また NFS の本としては古典ですが、改版された極めて
有用な本として、 Hal Stern が書いた O'Reilly & Associates, Inc. の 
Managing NFS and NIS があります。 (訳注: 邦訳がオライリージャパンから出
ています)。 NFS に関するもっとずっと高度かつ最新の技術情報は、 Brent
Callaghan の NFS Illustrated に書いてあります (邦訳が『NFS バイブル』と
いう書名でアスキーから出ています)。

この文書は完全なリファレンスマニュアルを目指したものでもなく、 Linux
NFS の膨大な機能のリストすべてを含むものでもありません。この目的には、 
nfs(5), exports(5), mount(8), fstab(5), nfsd(8), lockd(8), statd(8), 
rquotad(8), mountd(8) などの man ページを読んでください。

この文書では PC-NFS を扱いません。 PC-NFS は古いですし、Windows マシン
とファイル共有するには Samba のほうがいいです。また NFS Version 4 はま
だ開発中ですので、これも扱いません。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

2.3. 事前に必要とされる知識

この HOWTO を読むには、TCP/IP ネットワークに関する基本的な知識が必要で
す。自信がない場合は Networking-Overview-HOWTO <http://www.linuxdoc.org
/HOWTO/Networking-Overview-HOWTO.html> (JF に日本語訳 <http://
www.linux.or.jp/JF/JFdocs/Networking-Overview-HOWTO.html> があります)
を読んでください。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

2.4. 事前に必要となるソフトウェア: カーネルバージョンと nfs-utils

Version 2 の NFS と Version 3 の NFS との違いについては以降で説明します
。今のところは、専用の高負荷なファイルサーバをインストールする場合は
NFS Version 3 が必要になるだろう、という意見を受け入れてください。より
気軽な用途には NFS Version 2 でも良いでしょう。

NFS Version 2 は、かなり長く使われています (少なくとも 1.2 カーネルシリ
ーズから) が、次のいずれかを必要とする場合は 2.2.18 以降の版のカーネル
が必要です。

 ・ Linux の NFS を他の OS の NFS と混在させたい
   
 ・ NFS 越しに信頼性の高いファイルロックを使いたい
   
 ・ NFS Version 3 を使いたい
   
2.2.14 以降のカーネルには、上記の機能を提供するパッチも存在します。それ
らのいくつかは Linux NFS ホームページからダウンロードできます。 2.2.14
〜2.2.17 のカーネルを使っていて、ソースコードが手元にあるなら、 NFS
Version 3 サーバのサポートが設定オプションにあるかどうかで、これらのパ
ッチが当たっているかどうかを判断できます。しかし、古いカーネルを使う理
由が特になければ、多くのバグが修正されているわけですから、アップグレー
ドをすべきでしょう。カーネル 2.2.19 では、 2.2.18 に比べ、ロック機構の
改善点がいくつか追加されています。

Version 3 の機能を用いるには、nfs-utils パッケージの少なくともバージョ
ン 0.1.6 と、mount のバージョン 2.10m 以降が必要です。しかし nfs-utils
と mount は完全に後方互換性を保っていますし、新しい版では多くのセキュリ
ティやバグの修正がなされていますから、 NFS の設定を開始するところなら、
最新の nfs-utils や mount パッケージを利用しない手はないでしょう。

2.4 のすべてとそれ以降のカーネルには、 NFS Version 3 の機能がすべて含ま
れています。

いずれの場合でも、自分でカーネルをビルドする場合は、 NFS と NFS version
3 のサポートをコンパイル時に選ぶ必要があります。標準的なディストリビュ
ーションのほとんど (全てではありません) には、 NFS version 3 をサポート
したカーネルが付いてきます。

2 GB より大きなファイルを扱うには、 2.4.x カーネルと glibc の 2.2.x 版
が必要です。

2.2.18 以降のすべてのカーネルでは、クライアント側での NFS over TCP をサ
ポートしています。この文書の執筆時点でのサーバ側 NFS over TCP ですが、
2.2.18 以降のシリーズではバグが多く、実験的なオプションになっています。
2.4 や 2.5 カーネルへのパッチは 2.4.17 と 2.5.6 の時点から登場しました
。これらのパッチは安定していると思われていますが、現時点ではまだ比較的
新しく、広い用途で用いられてはいないようですし、メインストリームの 2.4
カーネルにも統合されていません。

上記の機能のほとんどがカーネルバージョン 2.2.18 で導入されたものですの
で、この文書はこのバージョン以降を対象にします (2.4.x も含みます)。古い
カーネルを使っている場合は、この文書はお手元の NFS システムを正しく記述
したものではないかもしれません。

この文書の執筆時点では、NFS version 4 はまだプロトコルの策定がおわった
ばかりで、実装はまだ完成品としては用意できていません。ですのでここでは
扱いません。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

2.5. ヘルプやより詳細な情報のありか

2000 年 11 月の段階では、Linux NFS ホームページは http://
nfs.sourceforge.net にあります。 NFS 関係のメーリングリスト、nfs-utils
の最新版、 NFS カーネルパッチ、その他 NFS 関係のパッケージ等については
こちらをチェックしてください。

この文書や faq、man ページなどで扱われていない問題や質問が生じた場合は
、 nfs メーリングリスト (<nfs@lists.sourceforge.net>) にメッセージを送
ってください。開発者や他のユーザたちが、あなたの問題を評価できるよう、
以下のような情報を含めるようにしてください。

 ・ 用いている nfs-utils のバージョン
   
 ・ カーネルのバージョンと、標準以外の拡張が適用されたカーネルである場
    合はその情報
   
 ・ 用いている Linux ディストリビューション
   
 ・ 問題に関わっている OS が他にあれば、そのバージョン
   
そのホストがつながっているネットワークの設定に関する情報も助けになるで
しょう。

問題の内容が、共有のマウントやエクスポートができない、というものでした
ら、次の情報もお願いします。

 ・ /etc/exports ファイルのコピー
   
 ・ サーバで rpcinfo -p localhost を実行したときの出力
   
 ・ クライアントで rpcinfo -p servername を実行したときの出力
   
まずすべての文書を読み、そして問題と一緒にこれら全ての情報を送るのが、
リストから助力を得るための最善の方法です。

nfs(5), exports(5), mount(8), fstab(5), nfsd(8), lockd(8), statd(8), 
rquotad(8), mountd(8) などの man ページも見ておくといいでしょう。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

3. NFS サーバの設定

3.1. サーバ設定の概略

ここではサーバとクライアントの両方を設定することを考えます。クライアン
トだけを設定して、誰か別の人のサーバ (例えば部門のサーバなど) につなぎ
たい場合は、 Section 4 に進んでください。しかし、クライアントを設定する
たびに、サーバはそのクライアントからの接続を許すよう修正する必要があり
ます (サーバの設定が非常に危険な場合を除けば)。従って自分でサーバを設定
しない場合でも、このセクションは読んでおいたほうがいいでしょう。そうす
れば認証関連の問題があった場合にどこを調べれば良いかわかるでしょうから
。

サーバの設定は 2 つのステップからなります。まず NFS の設定ファイルを編
集し、次に NFS サービスを実際に起動します。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

3.2. 設定ファイルの編集

NFS サーバの設置にあたって編集しなければならない主要な設定ファイルは 3
つあります。 /etc/exports, /etc/hosts.allow, /etc/hosts.deny です。本当
のところを言うと、実際に NFS を動作させるには /etc/exports だけで良いの
ですが、これだと NFS は非常に危険な状態に置かれます。さらに、これらに加
えて起動スクリプトを編集する必要もあるかもしれません。これについては 
Section 3.3.3 を見てください。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

3.2.1. /etc/exports

このファイルにはエントリのリストが書かれており、各エントリは共有するボ
リュームと、それがどの様に共有されるかを記述します。このファイルにおけ
る設定オプションのすべてを知るには man ページ (man exports) を見る必要
がありますが、ここにある記述でも大抵の人の用途には足りるでしょう。

/etc/exports のエントリは、以下のような形式になっています:

 directory machine1(option11,option12) machine2(option21,option22)     

各要素の意味は以下の通りです:

directory
   
    共有させたいディレクトリです。ボリューム全体でも良いですし、そうで
    なくてもかまいません。あるディレクトリを共有させると、それ以下のす
    べてのディレクトリも (同じファイルシステムにある限り) 同様に共有さ
    れます。
   
machine1 and machine2
   
    そのディレクトリにアクセスするクライアントマシンです。マシンは DNS
    アドレスまたは IP アドレスで指定できます (例: machine.company.com
    とか 192.168.0.8)。 IP アドレスを使うほうがより信頼性が高く安全です
    。 DNS アドレスを使う必要があって、その際に正しいマシンを発見できな
    い場合には、 Section 7.3 を見てください。
   
optionxx
   
    各マシンのオプションのリストで、そのマシンがどのようにアクセスでき
    るかを記述します。重要なオプションをいくつか挙げます:
   
     □ ro: このディレクトリは読み出し専用で共有されます。クライアント
        は書き込むことはできません。これがデフォルトです。
       
     □ rw: クライアントマシンは読み出しと書き込み両方のアクセスをこの
        ディレクトリに行います。
       
     □ no_root_squash: デフォルトでは、 root ユーザによるファイル要求
        は、すべてサーバ上では nobody ユーザによってなされたものとして
        扱われます。 (正確に言うと、要求の UID のマップ先はサーバにおけ
        るユーザ "nobody" の UID に依存します。クライアントのものではあ
        りません。) no_root_squash を選ぶと、クライアントマシンの root
        は、サーバシステムでも root としての同じレベルのアクセスをサー
        バのファイルに行うことになります。これはセキュリティに多大な影
        響を及ぼす可能性がありますが、クライアントで行う管理作業にエク
        スポートされたディレクトリを含めたいような場合には、これが必要
        になるでしょう。適切な理由がなければ、このオプションは指定すべ
        きではありません。
       
     □ no_subtree_check: ボリュームの一部だけをエクスポートする場合、
        subtree checking と呼ばれるルーチンが、クライアントから要求され
        たファイルがそのボリュームの適切な場所にあるかどうかを調べます
        。ボリューム全体をエクスポートする場合は、このチェックを無効に
        しておくと転送が高速になります。
       
     □ sync: 最新の版 (version 1.11) を除き、 exportfs コマンドはデフ
        ォルトでは async 動作をします。つまり、NFS が書き込み処理をファ
        イルシステムに渡した段階で、クライアントマシンに書き込みが完了
        した (つまりストレージデバイスへの書き込みが完了した) と伝えま
        す。この動作ではサーバがリブートするとデータが壊れる可能性があ
        り、 sync を指定すればこれを防げます。 sync と async の動作に関
        する詳細な議論は Section 5.9 を見てください。
       
いま 2 台のクライアントマシン、 slave1 と slave2 があり、それぞれの IP
アドレスはそれぞれ 192.168.0.1 と 192.168.0.2 であるとしましょう。これ
らのマシンに、自分たちで作ったソフトウェアバイナリのディレクトリと、ホ
ームディレクトリを共有させたいとします。このような場合の /etc/exports
は次のようになるでしょう:
┌──────────────────────────────────┐
│  /usr/local   192.168.0.1(ro) 192.168.0.2(ro)                      │
│  /home        192.168.0.1(rw) 192.168.0.2(rw)                      │
│                                                                    │
└──────────────────────────────────┘

ここでは /usr/local の共有は slave1 slave2 ともに読み出し専用としていま
す。ここには自分たちで開発したソフトウェアが入るので、 slave1 や slave2
に書き込み権限を与えることに、それがもたらすセキュリティ上のリスクを越
えるメリットはないでしょうから。一方ホームディレクトリは、そこにユーザ
が作業をセーブするのであれば、読み書き可能でエクスポートしなければなり
ません。

もし大きなシステムを使っている場合には、たくさんのコンピュータが同じロ
ーカルネットワークにつながっていて、それらすべてからサーバへのアクセス
を行わせたいかもしれません。多くのマシンへの参照を簡単に行うには、いく
つかの方法があります。最初のものは、ネットワークとネットマスクを用いて
、アクセスを許すマシンの範囲を指定する方法です。例えば 192.168.0.0 から
192.168.0.255 にあるすべてのマシンにアクセスを許すには、次のようなエン
トリを用意します:
┌──────────────────────────────────┐
│  /usr/local 192.168.0.0/255.255.255.0(ro)                          │
│  /home      192.168.0.0/255.255.255.0(rw)                          │
│                                                                    │
└──────────────────────────────────┘

ネットマスクの詳しい動作原理については Networking-Overview HOWTO <http:
//www.linuxdoc.org/HOWTO/Networking-Overview-HOWTO.html> (JF による日本
語訳 <http://www.linux.or.jp/JF/JFdocs/Networking-Overview-HOWTO.html>)
を見てください。また init および hosts.allow の各 man ページも見ておく
といいでしょう。

二番目の方法は、エントリに NIS のネットグループを用いるやり方です。
exports ファイルにネットグループを指定するには、ネットグループ名の前に
"@" をつければ良いだけです。ネットグループの詳しい動作原理については 
NIS HOWTO <http://www.linuxdoc.org/HOWTO/NIS-HOWTO.html> (JF による日本
語訳 <http://www.linux.or.jp/JF/JFdocs/NIS-HOWTO.html>) を見てください
。

三番目の方法は、ホスト名の代わりに *.foo.com や 192.168. のようなワイル
ドカードを使う方法です。2.2 系カーネルにはワイルドカードの実装に問題が
あったのですが、これはカーネル 2.2.19 で修正されました。

しかしこれらの単純化を行うと、ネットグループやローカルネットワークにあ
るすべてのマシンを完全には信頼できていない場合には、セキュリティ上のリ
スクが加わることになります。

エクスポートできない (あるいはすべきでない) 内容について、いくつか順番
に注意しておきます。まず第一に、あるディレクトリをエクスポートすると、
その親ディレクトリと子ディレクトリは (同じファイルシステムにある場合は)
エクスポートできません。しかしこれらをエクスポートする必要はないはずで
す。なぜなら親ディレクトリを /etc/exports にかけば、同じファイルシステ
ムにあるそれ以下のディレクトリはすべてエクスポートされるからです。

第二に、FAT や VFAT ファイルシステム (MS-DOS や Windows 95/98 の領域)
を NFS でエクスポートするのはよい考えではありません。 FAT はマルチユー
ザのマシンで利用することを考慮されていませんから、権限という概念に基づ
いた操作が行えません。さらに、これらのファイルシステムの下層システムは
、設計上の理由から NFS の期待通りには動作しないとも報告されています。

第三に、デバイスファイルや特殊ファイルは、 Linux 以外のクライアントには
正しくエクスポートされないことがあります。各 OS それぞれに関する詳細は 
Section 8 を見てください。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

3.2.2. /etc/hosts.allow と /etc/hosts.deny

この 2 つのファイルは、あなたのマシンのサービスを利用できるのは、ネット
ワーク上のどのコンピュータなのかを指定するものです。このファイルの各行
は、サービスとマシンの一覧をリストしたひとつのエントリになっています。
サーバがあるマシンから要求を受けると、サーバは次のように動作します:

 ・ サーバはまず hosts.allow を調べて、そのマシンがファイル中の記述にマ
    ッチするかを見ます。マッチした場合は、そのマシンからのアクセスは許
    可されます。
   
 ・ そのマシンが hosts.allow のエントリにマッチしないときは、サーバは次
    に hosts.deny を調べ、そのクライアントがこのファイル中のリストにマ
    ッチするかを見ます。マッチしたら、そのマシンのアクセスは拒否されま
    す。
   
 ・ そのクライアントがどちらのファイルのリストにもマッチしなければ、ア
    クセスは許可されます。
   
このファイルによるアクセス制御は、inetd で扱われるサービス (telnet や
FTP など) だけでなく、 NFS にも適用できます。 NFS サービスを提供するデ
ーモンへの接続を制限できるのです。制限はサービスごとに行えます。

アクセスを制限すべき最初のデーモンはポートマッパ (portmapper) です。こ
のデーモンの仕事は、基本的には要求をよこしたクライアントに、システム上
の様々な NFS サービスへの接続先を伝えることだけです。ポートマッパへのア
クセス制限は、 NFS 経由でシステムへ侵入しようとする者に対する最適な防御
となります。なぜなら全く認証されていないクライアントは、どこに NFS デー
モンがいるかを知るすべがないからです。しかしここで 2 つの点に気をつけな
ければなりません。一つ目は、ポートマッパを制限するだけでは十分ではない
ということです。侵入者はなんらかの理由で、これらのデーモンへの接続先を
知っているかもしれません。二つ目は、NIS を動かしている場合には、ポート
マッパを制限すると NIS への要求も制限されるということです。通常は NFS
も NIS も同様に制限したいでしょうから、これが問題になることは少ないでし
ょうが、しかし気には留めておいてください。 (NFS を動作させるなら、 NIS
もいっしょに動作させると良いでしょう。クライアントマシンには、エクスポ
ートされたボリュームにあるファイルの所有者を知る方法が必要だからです。
もちろんパスワードファイルを同期させる方法は他にもありますが。 NIS の設
定については NIS HOWTO <http://www.linuxdoc.org/HOWTO/NIS-HOWTO.html>
(JF による日本語訳 <http://www.linux.or.jp/JF/JFdocs/NIS-HOWTO.html>)
を見てください。

一般には、NFS (を含めほとんどのインターネットサービス) へのアクセスは、
許可する必要のない IP アドレスに対しては明示的に拒否しておくのが良いで
しょう。

こうするには、まず次のようなエントリを /etc/hosts.deny に追加します:

┌──────────────────────────────────┐
│   portmap:ALL                                                      │
│                                                                    │
└──────────────────────────────────┘

nfs-utils 0.2.0 からは、それぞれのデーモンのアクセス制御も行うことがで
き、よりシステムを堅固にできます。侵入者はポートマッパを回避できること
も多いので、この用心をしておくのはよいことです。最近版の nfs-utils を用
いているのなら、 NFS 関連のデーモンそれぞれについてエントリを一行ずつ追
加しておきましょう (これらのデーモンがそれぞれ何であるかは次の節を見て
ください。いまは単にこれらのエントリを hosts.deny に加えてください):

┌──────────────────────────────────┐
│    lockd:ALL                                                       │
│    mountd:ALL                                                      │
│    rquotad:ALL                                                     │
│    statd:ALL                                                       │
│                                                                    │
└──────────────────────────────────┘

古い版の nfs-utils を使っている場合でも、少なくともこれらのエントリを追
加して問題が起きることはありません (単に無視されます)。そしてアップグレ
ードしたときに、システムをトラブルから救ってくれるかもしれないわけです
。 /etc/hosts.deny ファイルに ALL:ALL というエントリを追加する方を選ぶ
システム管理者もいます。こうすると、これらのファイルを参照するすべての
サービスは、明示的に許可されたホスト以外からのアクセスをすべて拒否しま
す。これはとても安全な動作ですが、新しいサービスをインストールした際に
トラブルの原因となるかもしれません。このエントリを置いたことを忘れてい
ると、なぜ新しいサービスが動かないのか、一生かかってもわからないかもし
れません。

次にエントリを hosts.allow に追加し、アクセスを許可するホストを指定しま
す。 (上記のように hosts.deny に追加しただけだと、誰も NFS にアクセスで
きません。) hosts.allow のエントリは次のような形式です:

┌──────────────────────────────────┐
│    service: host [or network/netmask] , host [or network/netmask]  │
│                                                                    │
└──────────────────────────────────┘

ここで host はクライアントになれるホストの IP アドレスです。ホストの
DNS 名を利用できるシステムもありますが、 DNS 名の利用は避けるよう強くお
すすめします。

以前に行ったような設定で、 slave1.foo.com と slave2.foo.com にアクセス
を許可したい場合を考えましょう。これらのマシンの IP アドレスをそれぞれ 
192.168.0.1 と 192.168.0.2 とします。この場合は次のようなエントリを /
etc/hosts.allow に追加します:

┌──────────────────────────────────┐
│   portmap: 192.168.0.1 , 192.168.0.2                               │
│                                                                    │
└──────────────────────────────────┘

最近の版の nfs-utils では、次の内容も追加しましょう (同じくサポートされ
ていなくても無害です):

┌──────────────────────────────────┐
│    lockd: 192.168.0.1 , 192.168.0.2                                │
│    rquotad: 192.168.0.1 , 192.168.0.2                              │
│    mountd: 192.168.0.1 , 192.168.0.2                               │
│    statd: 192.168.0.1 , 192.168.0.2                                │
│                                                                    │
└──────────────────────────────────┘

NFS をローカルなネットワークにつながった多数のマシンに対して動作させる
場合は、 /etc/hosts.allow にも「ネットワーク/ネットマスク」形式のエント
リを指定することもできます。やり方は先に /etc/exports の部分で説明した
のと同じです。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

3.3. サービスを開始する

3.3.1. 事前の準備

これで NFS サーバの設定ができましたので、動作させてみましょう。まず、適
切なパッケージをインストールしましょう。要するに十分新しいカーネルと、
十分新しい版の nfs-utils パッケージです。よく分からなければ Section 2.4
を見ましょう。

続いて、NFS を開始する前に、TCP/IP ネットワークの機能がそのマシンで正し
く動作しているか確認しましょう。 telnet, FTP などが使えれば、おそらく
TCP ネットワークはちゃんと動いていると思います。

じつは、最近の Linux ディストリビューションのほとんどでは、 NFS を起動
して動作させるには、マシンをリブートするだけですみます。こうすると起動
スクリプトは、あなたが /etc/exports に対して行った設定を検知して、NFS
を正しく起動してくれます。こちらを試してみるなら、Section 3.4 を読んで
、 NFS が動作しているかどうか調べてください。うまく行かなかった場合や、
マシンをリブートできない場合には、次の節を読めば NFS サービスに必要なデ
ーモンがどれかわかります。なんらかの理由で、先に設定ファイルを編集して
いた時点で nfsd が動作していた場合は、行った設定を反映させる必要があり
ます。これを行うには Section 3.5 を見てください。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

3.3.2. ポートマッパを起動する

NFS はポートマッパデーモンに依存しています。名前は portmap か 
rpc.portmap のどちらかです。これは最初に起動しなければなりません。おそ
らく置き場所は /sbin でしょうが、 /usr/sbin の場合もあるかもしれません
。最近の Linux ディストリビューションのほとんどは、このデーモンをブート
スクリプトから起動しますが、 NFS に関する作業を始める前には、実際に動作
しているかを確かめておくと良いでしょう (ps aux | grep portmap と入力す
るだけです)。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

3.3.3. それぞれのデーモン

NFS のサービスは、5 つのデーモンによって処理されます: rpc.nfsd は作業の
大部分を行います。 rpc.lockd と rpc.statd はファイルロックを扱います。 
rpc.mountd は接続開始時のマウント要求を扱います。 rpc.quotad はエクスポ
ートされたボリュームにおけるユーザファイルクォータを扱います。 2.2.18
以降では、lockd は nfsd から必要に応じて呼び出されますので、手動で起動
する必要はありません。 statd は別に起動しておく必要があります。最近の
Linux ディストリビューションのほとんどには、これらのデーモンの起動スク
リプトがあるはずです。

これらのデーモンはすべて nfs-utils パッケージに入っており、 /sbin また
は /usr/sbin のいずれかのディレクトリにあると思います。

使っているディストリビューションの起動スクリプトにこれらがない場合は、
次の順に起動するよう設定を追加しなければなりません:

rpc.portmap                                 
rpc.mountd, rpc.nfsd                        
rpc.statd, rpc.lockd (必要なら), rpc.rquotad

nfs-utils パッケージには、RedHat と Debian 向けの起動スクリプトの例が入
っています。これら以外のディストリビューションを使っている場合でも、大
抵は RedHat のスクリプトをコピーすればすむと思いますが、
┌──────────────────────────────────┐
│    . ../init.d/functions                                           │
│                                                                    │
└──────────────────────────────────┘
という行を削除しないとエラーメッセージが表示されるかもしれません。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

3.4. NFS が動作しているか確認する

これを行うには、 rpcinfo -p コマンドを用いてポートマッパに問い合わせ、
どんなサービスが提供されているかを調べます。次のような出力が得られるは
ずです。
┌──────────────────────────────────┐
│    program vers proto   port                                       │
│    100000    2   tcp    111  portmapper                            │
│    100000    2   udp    111  portmapper                            │
│    100011    1   udp    749  rquotad                               │
│    100011    2   udp    749  rquotad                               │
│    100005    1   udp    759  mountd                                │
│    100005    1   tcp    761  mountd                                │
│    100005    2   udp    764  mountd                                │
│    100005    2   tcp    766  mountd                                │
│    100005    3   udp    769  mountd                                │
│    100005    3   tcp    771  mountd                                │
│    100003    2   udp   2049  nfs                                   │
│    100003    3   udp   2049  nfs                                   │
│    300019    1   tcp    830  amd                                   │
│    300019    1   udp    831  amd                                   │
│    100024    1   udp    944  status                                │
│    100024    1   tcp    946  status                                │
│    100021    1   udp   1042  nlockmgr                              │
│    100021    3   udp   1042  nlockmgr                              │
│    100021    4   udp   1042  nlockmgr                              │
│    100021    1   tcp   1629  nlockmgr                              │
│    100021    3   tcp   1629  nlockmgr                              │
│    100021    4   tcp   1629  nlockmgr                              │
│                                                                    │
└──────────────────────────────────┘

ここでは NFS version 2 と 3、rpc.statd version 1、 network lock manager
(rpc.lockd のサービス名) version 1, 3, 4 があります。また NFS が TCP を
使うか UDP を使うかによって、別々のサービスとしてリストされています。
Linux システムは、特に TCP を使うべく指定されない限り、 UDP をデフォル
トで用います。しかし Solaris のような他の OS では、デフォルトは TCP に
なっています。

もし portmapper の行、 nfs の行、 mountd の行のどれかがなければ、戻って
デーモンを起動しなおす必要があります (もしそれでも動かなければ、Section
7 トラブルシュートを見てください)。

これらのサービスが表示されていたら、NFS クライアントを用意して、サーバ
のファイルにアクセスさせるための準備が整ったことになります。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

3.5. /etc/exports をあとから変更する

先ほどやった /etc/exports ファイルの変更を再び行なった場合、その変更は
すぐには反映されません。nfsd に /etc/exports ファイルを読み直させるには
、 exportfs -ra コマンドを実行しなければなりません。　exportfs コマンド
が見つからない場合は、 -HUP フラグを指定して nfsd を kill します (詳細
は kill の man ページを見てください)。

これでもうまくいかない場合は、 hosts.allow を調べ、新しいクライアントマ
シンをリストし忘れていないか確認してください。またファイアウォールを設
定している場合は、そのホストリストもチェックしてください (ファイアウォ
ールと NFS の関係については Section 7 と Section 6 とを見てください)。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

4. NFS クライアントの設定

4.1. リモートのディレクトリをマウントする

作業をはじめる前に、手元の mount プログラムが十分に新しいかもう一度チェ
ックしてください (Version 3 NFS を使いたければ 2.10m が必要です)。また
クライアントマシンが nfs マウントをサポートしているかも確認しておきまし
ょう (大抵のディストリビューションではそうなっているでしょうが)。 2.2
以降のカーネルで /proc ファイルシステムが準備されている場合は、/proc/
filesystems を読んで、nfs と書かれた行があるかを見て下さい。ない場合は
、 insmod nfs と入力してみてください。 NFS がモジュールとしてコンパイル
されていれば、 nfs の行が魔法のように登場することでしょう。これもだめな
ら、NFS サポートを組み込んだカーネルをビルド (あるいはダウンロード) す
る必要があります。通常は、NFS が組み込まれていないカーネルで以下に示す
ような mount コマンドを実行すると、明らかにそれとわかるようなエラーにな
ります。

マシンを NFS クライアントにするには、そのマシンでポートマッパを動かす必
要があります。また NFS でファイルロックを使うには、 rpc.statd と 
rpc.lockd とを、クライアントとサーバの両方で動かす必要があります。最近
のディストリビューションのほとんどでは、デフォルトでこれらのサービスを
ブート時に起動するようになっています。そうなっていない場合には、 
Section 3.2 を見て起動方法を調べてください。

portmap, lockd, statd が動いたら、サーバのリモートディレクトリを (ロー
カルのハードドライブと同じように) mount コマンドを使ってマウントできる
はずです。前節からの例を使い続けることにしましょう: サーバは 
master.foo.com、そしてこのサーバの /home ディレクトリを slave1.foo.com
からマウントしたいとします。この場合やらなければならないのは、 
slave1.foo.com の root のプロンプトから次のように入力するだけです。
┌──────────────────────────────────┐
│   # mount master.foo.com:/home /mnt/home                           │
│                                                                    │
└──────────────────────────────────┘
これで master の /home が slave1 の /mnt/home として見えるはずです。
(このとき、空のディレクトリ /mnt/home はあらかじめマウントポイントとし
て作成してあると仮定しています。)

これがうまくいかない場合は、トラブルシュートの章 (Section 7) を見てくだ
さい。

ファイルシステムを取り外すのもローカルファイルシステムの場合と全く同じ
で、
┌──────────────────────────────────┐
│   # umount /mnt/home                                               │
│                                                                    │
└──────────────────────────────────┘
と入力すれば OK です。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

4.2. NFS ファイルシステムをブート時にマウントさせる

ローカルファイルシステムと同じように、 NFS ファイルシステムも起動時にマ
ウントできます。同様に /etc/fstab に追加すればいいのです。違うのは、フ
ァイルシステムのタイプを nfs にしなければならないことと、dump スイッチ
と fsck シーケンスの指定 (エントリの最後の 2 つ) を 0 にしなければなら
ないこと、です。よって前述の我々の例ならば、 /etc/fstab のエントリは次
のようになります。

   # device       mountpoint     fs-type     options      dump fsckorder 
   ...                                                                   
   master.foo.com:/home  /mnt    nfs          rw            0    0       
   ...                                                                   
                                                                         

このファイルの書式に慣れていない人は、fstab の man ページを見てください
。amd や autofs のようなオートマウンタを使っている人は、マウントリスト
の対応するフィールドに、 (全く同じではないにせよ) よく似たオプションを
指定することになります。

これで NFS が動作するようになったはずですが、うまく動作させるにはまだ少
々微調整が必要です。また Section 6 も読んで、ご自分の設定が十分安全かど
うかを確認してください。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

4.3. マウントのオプション

4.3.1. ソフトマウントとハードマウント

一緒につけておくと良いオプションがいくつかあります。 NFS サーバがクラッ
シュしたときやネットワークが切断されたときに、クライアントがどう振る舞
うかを指定するものです。この状態を穏やかに扱えるのが NFS の良いところの
一つです。サーバの障害にあたっては二つのモードがあります。

soft
   
    ファイルアクセスのリクエストに失敗すると、NFS クライアントはそのフ
    ァイルアクセスを要求したプロセスにエラーを通知します。このエラーを
    正しく扱えるプログラムもありますが、ほとんどはダメです。この設定は
    「破損ファイルとロストデータの作り方」みたいなもので、お勧めできま
    せん。特にメールのディスクには使うべきではありません -- メールに価
    値を認めているならば。
   
hard
   
    NFS マウントされたファイルシステム上のファイルにアクセスしているプ
    ログラムは、サーバがクラッシュすると宙ぶらりんになります。これらの
    プロセスは intr を一緒に指定していない場合は、中断することも kill
    することもできなくなります ("sure kill" を使えば別)。 NFS サーバが
    復活すると、プログラムはそれぞれ何もなかったかのように再開します。
    おそらくこちらが望ましい場合が多いでしょう。全ての NFS マウントには
    、 hard,intr を用いることをお勧めします。
   
上記の例から採れば、fstab のエントリは次のようになるでしょう:

   # device             mountpoint  fs-type    options    dump fsckord 
   ...                                                                 
   master.foo.com:/home  /mnt/home   nfs      rw,hard,intr  0     0    
   ...                                                                 
                                                                       

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

4.3.2. ブロックサイズを設定して転送速度を最適化する

マウントオプションの rsize と wsize は、クライアントとサーバがデータを
やりとりするときの、データの転送単位を指定するものです。

デフォルトの値は大きすぎ/小さすぎかもしれません。全ての、あるいは大抵の
設定に有効なサイズ、というものはありません。例えば Linux カーネルとネッ
トワークカードの組み合わせ (大抵は古いマシンでの話) によっては、あまり
大きなブロックは扱えません。一方大きなブロックが扱えれば、大きなサイズ
の転送は高速になります。

最適なブロックサイズを得る作業は、NFS の性能に重要な影響を与えます。
NFS を現場の環境で使う場合には必須と言えるでしょう。詳細は Section 5 を
見てください。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

5. NFS の性能を最適化する

クライアントとサーバの両面から、環境を注意深く分析することが、 NFS の性
能を最適化する際の最初のステップになります。前半のセクションでは、一般
にクライアントの方で重要になる点を扱います。後半 (Section 5.3 以降) で
は、サーバ側の点を議論します。サーバ・クライアント両側での項目は、互い
に影響を及ぼしあうことがないわけではありませんが、原因・結果をはっきり
させるためには、この 2 つを分けておくと便利かと思います。

十分なネットワーク容量、高速な NIC、全二重の設定にして衝突を減らす、ス
イッチやハブでネットワークスピードを一致させる、といったようなネットワ
ーク関連の設定を除くと、クライアントを最適化するために最も重要な設定は
、 NFS データ転送のバッファサイズでしょう。これは mount コマンドの 
rsize, wsize 各オプションで設定します。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

5.1. ブロックサイズを設定して転送速度を最適化する

mount コマンドの rsize オプションと wsize オプションは、クライアントと
サーバがデータをやりとりするときのデータの転送単位を指定するものです。
それぞれのオプションが指定されないときのデフォルト値は、使っている NFS
のバージョンによって異なります。ほとんどの場合のデフォルトは 4K (4096
バイト) ですが、 2.2 カーネルにおける TCP ベースでのマウントや、 2.4 カ
ーネル以降でのあらゆるマウントでは、サーバがデフォルトのブロックサイズ
を指定します。

NFS V2 プロトコルの理論上の上限は 8K です。 V3 プロトコルでの上限はサー
バによって異なります。 Linux サーバでの最大ブロックサイズは、カーネルソ
ースの ./include/linux/nfsd/const.h にあるカーネル定数 
NFSSVC_MAXBLKSIZE で決まります。 2.4.17 の時点では、カーネルの最大ブロ
ックサイズは 8K (8192 バイト) ですが、 2.4 系に対する NFS over TCP/IP
転送を実装したパッチでは、執筆時点で 32K (このパッチでは 32*1024) が最
大ブロックサイズになっています。

すべての 2.4 系クライアントは、現時点で最大 32 K までのブロック転送サイ
ズをサポートしており、 Solaris のような他のサーバからの NFS 転送で標準
となっている 32K のブロック転送を、クライアントを修正することなく利用で
きます。

デフォルトの値は大きすぎ/小さすぎかもしれません。全ての、あるいは大抵の
設定に有効なサイズ、というものはありません。例えば Linux カーネルとネッ
トワークカードの組み合わせ (ほとんどは古いマシンでの話) によっては、あ
まり大きなブロックは扱えません。一方大きなブロックが扱えれば、大きなサ
イズの転送は高速になります。

実験を行って、動作する限りで最速となるような rsize や wsize を決定しま
しょう。ある設定にしたときの転送速度は、ネットワークが混雑していなけれ
ば、いくつかの簡単なコマンドで調べられます。実際の結果は場合によって大
きく変わってしまうかもしれません。その際には Bonnie, Bonnie++, IOzone
といった、より複雑なベンチマークを使うことになります。

最初に実行すべきコマンドは、16k のブロック 16384 個を、特殊なファイル /
dev/zero (読み込むと 0 を「非常に」高速に吐き出してきます) からマウント
したパーティションに転送するものです。どのくらい時間がかかるかは time
で測りましょう。クライアントマシンから次のように入力します。

    # time dd if=/dev/zero of=/mnt/home/testfile bs=16k count=16384    

こうすると (バイトデータの) 0 で埋めつくされた、大きさが 256Mb のファイ
ルができます。一般には、サーバに積んである RAM のサイズの、少なくとも 2
倍の大きさのファイルを作るべきです (ただしディスクに空きがあるか、確認
を忘れないこと!)。次にそのファイルを、クライアントのブラックホール (/
dev/null) に読み出します。次のように入力してください。

    # time dd if=/mnt/home/testfile of=/dev/null bs=16k                

これを何回か繰り返して、かかった時間を平均してください。対象のファイル
システムを毎回アンマウント→再マウントして (クライアントと、こだわる方
はサーバでも)、キャッシュの効果をすべてクリアするのを忘れずに。

終わったらアンマウントし、ブロックサイズを増減してもう一度マウントして
ください。サイズは 1024 の倍数にし、またシステムでの最大ブロックサイズ
は越えないようにしましょう。 NFS Version 2 の最大サイズは、 
NFSSVC_MAXBLKSIZE での定義にかかわらず 8K です。 Version 3 は、許可され
ていれば 64K までサポートします。ブロックサイズは 2 倍ずつ変えていくの
が良いでしょう。転送に関連するパラメータ (ファイルのシステムブロックサ
イズやネットワークのパケットサイズなど) も、たいていは 2 倍ずつ変わるか
らです。ただし、ブロックサイズを 2 の冪乗以外の値にして、より良い結果を
得たユーザもいます。しかしその場合でも、システムのブロックサイズやネッ
トワークパケットサイズの整数倍にはなっていました。

大きなサイズでマウントしたら、そのファイルシステムに cd し、ls するなど
して、ファイルシステムの中味が正しく見えるか調べてみて下さい。 rsize や
wsize が大き過ぎると、妙な兆候が現われ、ファイルの信頼性が 100% でなく
なります。よくある例としては「ls してもすべてが表示されない、エラーメッ
セージも出ない」とか「エラーメッセージは出ないのにファイルの読み込みに
なぜか失敗する」などがあります。さて、与えた rsize/wsize でシステムが正
しく動作していることがわかったら、もう一度速度のテストをしてみましょう
。サーバの OS が違うと最適なサイズも異なる場合が多いです。

最後に /etc/fstab を編集して、決まった rsize/wsize の値を反映させるのを
忘れないように。

結果が一貫しなかったり、疑わしかったりした場合には、 rsize や wsize の
値を変化させながら、ネットワークをもっと真面目に解析する必要があるかも
しれません。その場合には、ベンチマークソフトを使うと良いかもしれません
。いくつかポインタを挙げておきます。

 ・ Bonnie http://www.textuality.com/bonnie/
   
 ・ Bonnie++ http://www.coker.com.au/bonnie++/
   
 ・ IOzone file system benchmark http://www.iozone.org/
   
 ・ 公式の NFS ベンチマーク, SPECsfs97 http://www.spec.org/osg/sfs97/
   
非常にさまざまなファイルサイズや、さまざまな IO 形式 (読み出し・書き込
み、再読み出し・再書き込み、ランダムアクセスなどなど) など、最も広い範
囲を扱えて、かつ最も簡単なベンチマークは、 IOzone のように思います。推
奨される IOzone の実行方法としては (これには root 権限が必要ですが)、テ
ストするディレクトリをアンマウント・再マウントしてキャッシュが関与しな
いようにし、ファイルクローズ時間の測定をテストに入れるようなやり方です
。すでにサーバ foo で /tmp を制限なしでエクスポートしており、 IOzone を
ローカルディレクトリにインストール済みであるとすると、次のようなコマン
ド群になります。

    # echo "foo:/tmp /mnt/foo nfs rw,hard,intr,rsize=8192,wsize=8192 0 0" 
    >> /etc/fstab                                                         
    # mkdir /mnt/foo                                                      
    # mount /mnt/foo                                                      
    # ./iozone -a -R -c -U /mnt/foo -f /mnt/foo/testfile > logfile        

ベンチマークには最大で 2〜3 時間かかります。そして、もちろん対象の 
rsize や wsize を変更するたびに実行する必要があります。 web サイトには
パラメータを網羅した文書がありますが、上記で用いたオプションについては
以下で説明します。

 ・ -a 完全自動モード。ファイルサイズ 64K から 512M までを、レコードサ
    イズ 4K から 16M まででテストします。
   
 ・ -R レポートを Excel のスプレッドシートで生成します (グラフには
    "surface plot" オプションを用いるのが良いでしょう)。
   
 ・ -c ファイルクローズ時間のテストを行う。これは NFS version 3 の
    commit 時間を取得します。
   
 ・ -U 与えられたマウントポイントをテストごとにアンマウント/再マウント
    し、キャッシュをクリアする。
   
 ・ -f アンマウントを用いるときは、マウントされたファイルシステムに置か
    れたテストファイルを指定する必要があります。
   
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

5.2. パケットサイズとネットワークドライバ

Linux のネットワークカードドライバの多くは優れたものですが、中には、比
較的標準的なカードのものも含め、極めて出来の悪いものもあります。自分の
ネットワークカードを直接テストして、最高の状態で動作させるにはどうすれ
ば良いかを知っておくのは、やるだけの価値があることだと言えます。

2 台のマシンの間で ping をやり取りしてみましょう。その際 -f オプション
と -s オプションを用いて (詳細は ping(8) を見てください) 大きなパケット
を使い、大量のパケットロスが起きていないか、応答に時間がかかっていない
かを見てみましょう。このような障害が起きている場合は、ネットワークカー
ドの性能に問題があるかと思われます。

NFS の動作に特化した解析をより詳しく行うには、 nfsstat コマンドをつかっ
て NFS トランザクション、クライアント/サーバの統計、ネットワークの統計
などを見てください。 "-o net" オプションを用いると、トランザクションの
総パケット数に対するパケット落ちの回数が表示されます。 UDP トランザクシ
ョンで最も重要な統計は再送数で、これはパケット落ち、ソケットのバッファ
オーバーフロー、一般的なサーバの過負荷、タイムアウトなどによって生じま
す。これは NFS の性能に非常に重要な影響を与えるので、注意深く見る必要が
あります。なお nfsstat はまだカウンタをゼロにリセットする -z オプション
を実装していません。したがって、ベンチマークを行う前に、まず nfsstat カ
ウンタの現在値を見ておく必要があります。

ネットワークの問題を修正するには、ネットワークカードの用いているパケッ
トサイズを再設定するといいでしょう。 2 台のマシンの間でやり取りできるパ
ケットサイズの最大値は、ほとんどの場合ネットワークのどこか (例えばルー
タ) において、ネットワークカードのものより小さな値に制限されています。
TCP ではネットワークに対して適切なパケットサイズを自動的に見つけるよう
になっていますが、 UDP では単にデフォルトの値を使うだけです。従って、特
に UDP 上で NFS を使っている場合には、適切なパケットサイズを決めること
は非常に重要です。

ネットワークパケットサイズのテストは tracepath コマンドによって行えます
。クライアントマシンから単に tracepath server 2049 と入力すれば、末尾に
path MTU が表示されます。次に ifconfig の MTU オプションを使って、ネッ
トワークカードの MTU を path MTU の値と同じにし、パケット落ちが少なくな
るか確認してください。 MTU の再設定方法の詳細は ifconfig の man ページ
を見てください。

さらに netstat -s を使えば、サポートされているプロトコル全てに対して収
集された統計が表示されます。また /proc/net/snmp を見れば、現在のネット
ワークの動作状況に関する情報がわかります。詳細は次の節を見てください。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

5.3. フラグメントされたパケットのオーバーフロー

network の MTU (多くのネットワークでは通常 1500) よりも大きな rsize や 
wsize を用いると、NFS over UDP を使っている場合には IP パケットはフラグ
メント化されます。 IP パケットのフラグメント化と再構成は、ネットワーク
接続の両側で、相当量の CPU 資源を必要とします。さらにパケットのフラグメ
ント化が行われている状態では、 UDP パケットのフラグメントがなんらかの理
由で落ちたときに RPC リクエスト全体を再送しなければならないため、ネット
ワーク転送をずっと不安定にします。 RPC 再送の増加は、タイムアウトを増加
させることになりかねず、 NFS over UDP の性能を悪化させる最悪の原因とな
ります。

パケット落ちはいろいろな理由で生じます。ネットワークの形状が複雑だと、
フラグメントの経路が異なるかも知れず、サーバでの再構成時に全てが到着し
ないかもしれません。カーネルがバッファできるフラグメントの数には上限が
あり、これを越えるとパケットは破棄されるため、 NFS サーバの収容能力も問
題になります。 /proc ファイルシステムをサポートするカーネルでは、 /proc
/sys/net/ipv4/ipfrag_high_thresh と /proc/sys/net/ipv4/
ipfrag_low_thresh ファイルで確認できます。未処理のフラグメント化パケッ
トが ipfrag_high_thresh (バイト単位) を越えると、カーネルは単純にパケッ
トのフラグメントを捨てはじめ、サイズの合計が ipfrag_low_thresh に指定し
た値になるまで捨て続けます。

別のモニターカウンタとして、 /proc/net/snmp ファイルにある IP:
ReasmFails があります。この数は、フラグメントの再構成に失敗した回数です
。重いファイル操作の際にこの値があまりに急激に上昇する場合は、おそらく
問題が生じています。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

5.4. NFS over TCP

新しい機能である NFS over TCP は、 2.4 カーネルでも 2.5 カーネルでも利
用できますが、まだ執筆時点ではメインストリームのカーネルには統合されて
いません。 TCP の利用には、UDP に対してはっきりした利点・欠点があります
。利点は、ロスの多いネットワークにおいて UDP よりずっと良く動作すること
です。 TCP を使った場合は、パケットがひとつ落ちると単にそれが再送され、
RPC リクエスト全体を再送するようなことは起こりません。よってロスの多い
ネットワークではより良い性能を示します。さらに TCP は、下層のネットワー
クレベルでのフロー制御のおかげで、ネットワーク速度の違いを UDP よりもう
まく扱えます。

TCP を用いることの欠点は、 TCP が UDP のようなステートレスのプロトコル
ではないことです。パケット送信の最中にサーバがクラッシュすると、クライ
アントはハングしてしまい、すべての共有をアンマウント・再マウントする必
要が生じます。

TCP プロトコルはオーバーヘッドを必要とするため、理想的なネットワーク環
境の下では UDP に比べて少々性能が低下します。しかしそのコストはあまり厳
しいものではなく、注意深く測定しないと気付かない場合が多いでしょう。通
信の端から端まで gigabit イーサネットを使っているような場合は、巨大なフ
レームの利用を試みてみるといいかもしれません。高速なネットワークでは、
特にネットワークが全二重の場合には、フレームサイズを大きくしても衝突レ
ートが増加しないからです。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

5.5. タイムアウトと再送の値

mount コマンドの 2 つのオプション、 timeo と retrans は、クライアントが
パケット落ち・ネットワーク負荷などによってタイムアウトしたときの、 UDP
リクエストの動作を制御するものです。 -o timeo オプションは時間の長さを
1/10 秒単位で指定するもので、クライアントはこの時間を越えるとサーバから
応答がもらえなかったと判断し、リクエストを再送しようと試みます。デフォ
ルトは 0.7 秒です。 -o retrans オプションは、クライアントがあきらめるま
でに許されるタイムアウト回数で、これを越えると Server not responding と
いうメッセージが表示されます。デフォルトは 3 回です。クライアントがこの
メッセージを表示したら、リクエストを送信しようとし続けますが、次のタイ
ムアウト 1 回で、エラーメッセージを表示します。接続が復帰すると、クライ
アントはふたたび元の retrans の値を用いるようになり、 Server OK という
メッセージを表示します。

すでに大量の再送が起きていたり (nfsstat コマンドの出力を見てください)、
あるいはタイムアウト・再送を引き起こすことなくブロック転送サイズを増加
させたい場合には、これらの値を調整するといいでしょう。適切な調整値は環
境に依存しますが、ほとんどの場合では現在のデフォルトで問題ないはずです
。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

5.6. NFSD のインスタンスの数

Linux でも他の OS でも、ほとんどの起動スクリプトでは、 nfsd のインスタ
ンスを 8 つ起動します。 NFS の最初の頃に Sun はこの値を経験則として決め
、その後はみんなこの値をコピーしているのです。どのくらいのプロセス数が
最適かを決める良い基準はありませんが、トラフィックの大きいサーバではよ
り大きな値にするのが良いでしょう。最低でもプロセッサ当たりひとつのデー
モンは起動すべきで、プロセッサ当たり 4 から 8 というのがだいたいの目安
になるでしょう。 2.4 以降のカーネルを使っている人は、各 nfsd スレッドが
どのくらい使われているかを /proc/net/rpc/nfsd で見てみるといいでしょう
。このファイルの th 行の最後の 10 個の数字は、割り当て可能な最大値に対
する各パーセンテージにそのスレッドがあった秒数を示しています。最初の 3
つの値が大きいときは、 nfsd のインスタンスを増やすほうが良いでしょう。
これを行うには、nfsd を起動するときのコマンドラインオプションでインスタ
ンスの数を与えます。 NFS の起動スクリプト (Red Hat なら /etc/rc.d/
init.d/nfs) では RPCNFSDCOUNT で指定します。詳細は nfsd(8) の man ペー
ジを見てください。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

5.7. 入力キューのメモリ制限

2.2 と 2.4 のカーネルでは、ソケットの入力キュー (処理中のリクエストが待
つところ) のデフォルトのサイズ制限値 (rmem_default) は小さく、64k しか
ありません。このキューは読み込み負荷が大きいクライアントで、また書き込
み負荷の大きいサーバで重要です。例えば、サーバで nfsd のインスタンスを
8 つ走らせているとすれば、各々には処理対象のリクエストを保存する場所が
8k ずつしかないことになります。さらに、ソケットの出力キュー (書き込み負
荷の大きなクライアント・読み込み負荷の大きなサーバで重要) も、デフォル
トのサイズ (wmem_default) は小さくなっています。

NFS ベンチマーク SPECsfs <http://www.spec.org/osg/sfs97/> の実行結果が
いくつか公開されていますが、それらでは [rw]mem_default と [rw]mem_max
の両方にずっと大きな値を指定しています。これらの値は、少なくとも 256k
にまで増やすことを考えるべきです。読み書きの上限値は、(例えば) proc フ
ァイルシステムの /proc/sys/net/core/rmem_default と /proc/sys/net/core/
rmem_max を用いて設定します。 rmem_default の値を増加させるには 3 つの
段階を踏みます。以降に示す方法はちょっとあらっぽいですが、ちゃんと動作
しますし、問題を起こすこともないはずです。

 ・ これらのファイルに書かれているサイズを増加します:
   
         # echo 262144 > /proc/sys/net/core/rmem_default        
         # echo 262144 > /proc/sys/net/core/rmem_max            
   
 ・ NFS を再起動します。例えば RedHat システムなら次のようにします。
   
         # /etc/rc.d/init.d/nfs restart                         
   
 ・ サイズの上限値を通常の値に戻し、他のカーネルシステムはこちらを使う
    ようにします。
   
         # echo 65536 > /proc/sys/net/core/rmem_default         
         # echo 65536 > /proc/sys/net/core/rmem_max             
   
この最後のステップは不可欠で、これらの値を長い間変えたままにしておくと
、マシンがクラッシュするというレポートも受けています。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

5.8. NIC とハブの自動ネゴシエーションを無効にする

ネットワークカードの中には、動作速度や全二重・半二重が異なるハブ、スイ
ッチ、ポートなどとの自動ネゴシエーションがうまくできず、大量のコリジョ
ン・パケット落ちなどによって、性能が非常に劣化するものがあります。 
nfsstat の出力に大量のパケット落ちがあったり、あるいは一般にネットワー
クの性能がでない場合は、ネットワーク速度と全/半二重の設定をいじってみて
ください。可能なら 100BaseT 全二重のサブネットを確立することに集中しま
しょう。全二重による仮想的なコリジョン回避は、 NFS over UDP における最
も大きな性能低下の原因を取り除いてくれるからです。カードの自動ネゴシエ
ーション機能を切るときには注意が必要です。カードが接続されているハブや
スイッチは、別の方法で (例えば並列検知など) をもちいて全/半二重の設定を
決めますが、カードによっては (古いハブでもサポートされているという理由
から) デフォルトが半二重になっていることがあるからです。ドライバがサポ
ートしているのであれば、 100BaseT 全二重でネゴシエーションするようカー
ドに強制するのが最善です。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

5.9. NFS の同期動作と非同期動作

nfs-utils の Version 1.11 より前の exportfs では、 NFS の Version 2 と
Version 3 プロトコルのどちらにおいても、デフォルトのエクスポートは「非
同期 (asynchronous)」で行ないます (なお Version 1.11 は CVS ツリーには
存在しますが、 2002 年 1 月の段階ではまだパッケージになっていません)。
このデフォルトにおいては、サーバはクライアントからのリクエストに対し、
処理をローカルのファイルシステムに渡したところで返答することが許されて
おり、データが永続的なストレージに書き込まれることを待つ必要はありませ
ん。これはサーバのエクスポートリストの async オプションによって識別でき
ます。非同期動作は性能が向上しますが、書き込んでいないデータやメタデー
タがキャッシュにあるときにサーバがリブートすると、データが壊れる可能性
があります。このデータ破壊は実際に起こるまでわかりません。 async オプシ
ョンを指定すると、用いているプロトコルに関らず、サーバはクライアントに
対して、データはすべて実際に永続的なストレージに書き込まれた、と嘘をつ
くからです。

「同期 (synchronous)」動作は NFS をサポートする商用製品システム
(Solaris, HP-UX, RS/6000 など) の多くで、また最新版の exportfs でもデフ
ォルトになっています。この動作をさせるには、Linux サーバのファイルシス
テムを sync オプションでエクスポートする必要があります。なお同期的なエ
クスポートをした場合は、サーバのエクスポートリストにはオプションが表示
されません。

 ・ 2 つのファイルシステムを、少々異なるオプションで、あらゆるクライア
    ントに対してエクスポートします。
   
        # /usr/sbin/exportfs -o rw,sync *:/usr/local            
        # /usr/sbin/exportfs -o rw *:/tmp                       
   
 ・ するとエクスポートされたファイルシステムのパラメータは次のようにな
    ります。
   
        # /usr/sbin/exportfs -v                                 
        /usr/local *(rw)                                        
        /tmp *(rw,async)                                        
   
カーネルが /proc ファイルシステムをサポートするようにコンパイルされた場
合は、 /proc/fs/nfs/exports ファイルによってもすべてのエクスポートオプ
ションのリストが表示できます。

同期動作を指定すると、サーバは NFS version 2 のリクエストに対して、ロー
カルファイルシステムがすべてのデータ・メタデータをディスクに書き込むま
で動作を完了しません (つまりクライアントに応答しません)。同期動作の NFS
version 3 においては、サーバはこの遅延を行うことなく返答を行い、クライ
アントにデータの状態を返して、どのデータをキャッシュに保持しておくべき
か、またどのデータは捨ててよいかを判断できるようにします。 include/
linux/nfs.h の enum 型変数 nfs3_stable_how には、3 つの状態値があります
。

 ・ NFS_UNSTABLE - データ・メタデータはサーバの永続的なストレージに
    commit されていないので、後でクライアントの commit リクエストによっ
    てサーバが実際にデータを永続的なストレージに送ったことが確認できる
    まで、クライアントでキャッシュしておかなければならない。
   
 ・ NFS_DATA_SYNC - メタデータは永続的なストレージに送られていないので
    、クライアントでキャッシュしておかなければならない。上の場合と同じ
    ように、後で commit を行う必要がある。
   
 ・ NFS_FILE_SYNC - データ・メタデータをキャッシュしておく必要はない。
    また、このリクエストの範囲に対しては、後で commit を送る必要もない
    。
   
上記の同期動作の定義に加え、クライアントから (プロトコルによらず) 明示
的に完全な同期動作を行うような指定もできます。これにはファイルをオープ
ンする際に O_SYNC オプションを指定します。この場合、クライアントからの
リクエストに対する応答は、データが実際にサーバのディスクに書き込まれる
まで行なわれません。これはプロトコルによりません (つまり NFS version 3
に対しては、すべてのリクエストが NFS_FILE_SYNC リクエストとなり、これは
サーバに対して必ずこの状態を返すように求めるのです)。この場合、NFS
version 2 と NFS version 3 の性能は事実上同じになります。

しかし、古いデフォルトである async 動作が用いられていた場合には、いずれ
の NFS バージョンにおいても O_SYNC オプションは全く意味を持ちません。サ
ーバは書き込みの完了を待つことなくクライアントに応答してしまうからです
。この場合も、バージョンの違いによる性能差は現われません。

最後に一言。NFS version 3 プロトコルのリクエストでは、ファイルをクロー
ズするときや fsync() の時に NFS クライアントから「後出し」の commit リ
クエストが発行されますが、これによってサーバは以前書き込みを完了してい
なかったデータ・メタデータをディスクに書き込むよう強制されます。そして
サーバは、 sync 動作に従うのであれば、この書き込みが終了するまでクライ
アントに応答しません。一方もし async が用いられている場合は、 commit は
基本的に no-op (何も行なわない動作) です。なぜならサーバは再びクライア
ントに対して、データは既に永続的なストレージに送られた、と嘘をつくから
です。するとクライアントはサーバがデータを永続的なストレージに保存した
と信じて自分のキャッシュを捨ててしまうので、これはやはりクライアントと
サーバをデータ破壊の危険に晒すことになります。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

5.10. サーバの性能をあげる NFS 以外の方法

一般に、サーバの性能とサーバのディスクアクセス速度は NFS の性能にも重要
な影響を及ぼします。良好に機能するファイルサーバの設定に対するガイドラ
インを提供することは、この文書で扱う範囲を越えていますが、いくつかのヒ
ントを提供しておく価値はあるでしょう。

 ・ RAID アレイを利用できる場合は、 RAID 1/0 を用いて書き込み速度と冗長
    度の両方を確保しましょう。 RAID 5 を用いると読み込みは速くなります
    が、書き込みはみじめなことになります。
   
 ・ ジャーナリングファイルシステムを用いれば、システムがクラッシュした
    ときに再起動に要する時間が劇的に短くなります。現時点では、 ext3
    <ftp://ftp.uk.linux.org/pub/linux/sct/fs/jfs/> が NFS version 3 と
    一緒に正しく動作します。また Reiserfs version 3.6 以降も、 2.4.7 以
    降のカーネルの NFS version 3 と一緒に正しく動作します (それ以前のカ
    ーネルに対するパッチもあります)。それより前の Reiserfs では、生成番
    号 (generation number) の保管場所が inode に無いため、サーバが再起
    動したときに検知不可能な形でデータが破壊する可能性があります。
   
 ・ また、ジャーナリングファイルシステムにおいて、ジャーナルの更新はデ
    ータ保護のためにのみ必要である、という事実を利用すれば、性能を最大
    化することが可能です。例えば ext3 を例に取るなら、 data=journal を
    用いて、更新をまずすべてジャーナルに対して行ない、そしてその後でフ
    ァイルシステム本体に対して行うようにします。ジャーナルが更新された
    ら、 NFS サーバは安心してクライアントに対する応答を発行でき、メイン
    ファイルシステムの更新はサーバが暇なときに行なえば良いのです。
   
    ジャーナリングファイルシステムのジャーナルをフラッシュメモリカード
    などの別のデバイスに置き、ジャーナルの更新時にシーク動作を不要にす
    ることもできます。こうすれば回転待ちだけがコストになるので、同期 IO
    の性能をかなり良くできます。いまでは ext3 はジャーナルのリロケーシ
    ョンをサポートしており、また ReiserFS も近々 (公式に) サポートする
    はずです。 ftp://ftp.namesys.com/pub/reiserfsprogs/
    reiserfsprogs-3.x.0k.tar.gz <ftp://ftp.namesys.com/pub/
    reiserfsprogs/reiserfsprogs-3.x.0k.tar.gz> にある ReiserFS 用のツー
    ルパッケージには、 reiserfstune というツールがあり、これを用いると
    ジャーナルのリロケーションを行なえます。しかしこれにはカーネルパッ
    チが必要で、これはまだ 2002 年 1 月の段階では公式にはリリースされて
    いません。
   
 ・ automounter (autofs や amd) を用いれば、クロスマウントを (わざとで
    もうっかりでも) したマシンのどちらかが落ちたときでも、もう片方のハ
    ングアップを避けられます。詳細は Automount Mini-HOWTO <http://
    www.linuxdoc.org/HOWTO/mini/Automount.html> を見てください (JF に日
    本語訳 <http://www.linux.or.jp/JF/JFdocs/Automount.html> がありま
    す)。
   
 ・ メーカーによっては、不揮発 RAM (NVRAM) を用いた NFS アクセレレータ
    を提供しています (Network Appliance, Hewlett Packard など)。 NVRAM
    を用いれば、永続的なストレージへのアクセスが async 利用時と同じくら
    いにまで加速できます。
   
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

6. セキュリティと NFS

ここでいくつかセキュリティ上の留意点を述べますが、これであなたのサイト
が完全に安全になるわけではありません。なにものも、サイトを完全に安全に
することはできません。この節を読めば NFS 絡みのセキュリティ問題に関する
知識を得る助けにはなるでしょうが、網羅的なガイドではありませんし、この
内容も常に変化し続けています。もしセキュリティ関連の技やヒントをお持ち
でしたら、 HOWTO の管理者に送ってください。

もしあなたのネットワークが、外部といっさいの通信を行わず (モデムもだめ)
、かつ内部のマシンすべてとユーザすべてを信頼できるなら、この節の内容は
あなたの役には立ちません。しかしこのような状況にあるネットワークはどち
らかというと少数でしょうから、 NFS を設定する人には、この節を徹底的に熟
読することをおすすめします。

NFS において、サーバのリモートディレクトリにあるファイルへアクセスでき
るようになるためには、クライアントは 2 つの段階を経なければなりません。
最初の段階はマウントアクセスです。マウントアクセスは、サーバにアタッチ
しようとしているクライアントマシンによって行われます。この段階でのセキ
ュリティは /etc/exports ファイルが左右します。このファイルは、共有ポイ
ントへのアクセスを許可するマシンの名前または IP アドレスをリストしたも
のです。クライアントの IP アドレスがこのアクセスリストのエントリのどれ
かにマッチすれば、そのマシンはマウントを許されます。これはものすごく安
全、というわけではありません。アドレスを詐称されたり乗っ取られたりする
と、マウントポイントへのアクセスを許してしまいます。このタイプの「認証
」を実世界に例えてみましょうか: 誰かが自己紹介をしてきたとして、その人
に「こんにちは、私の名前は○○です」という名札がついていることを理由に
、その自己紹介の内容を信じるようなものです。マシンがボリュームをマウン
トすると、そのマシンで動作している OS は、そのボリュームのすべてのファ
イルにアクセスできることになります (root が保有しているファイルは除外可
能。後述)。そのボリュームが rw オプションつきでエクスポートされていれば
、これらのファイルへの書き込みアクセスも可能となります。

二番目の段階はファイルアクセスです。これはクライアントにおける、通常の
ファイルシステムのアクセス制御機能であり、 NFS 独自のものではありません
。ドライブがマウントされると、そこのファイルのユーザパーミッション・グ
ループパーミッションがアクセス制御を決めることになります。

再び例を: bob はサーバでユーザ ID 9999 にマップされているとしましょう。
ボブはサーバでユーザのみがアクセスできるファイルを作ります (chmod 600 
filename と入力するのと同じです)。そのファイルが保存されたドライブへの
アクセスを、あるクライアントが許可されました。そのクライアントでは、ユ
ーザ ID 9999 には mary がマップされています。この場合、bob が自分にしか
アクセスできないようにしたファイルに対して、そのクライアントでのユーザ
mary がアクセスできてしまいます。さらに悪いことに、そのクライアントで誰
かがスーパーユーザになってしまうと、その誰かは su - username によってど
んなユーザにもなれてしまうのです。 NFS は賢いとは言えません。

これは絶望的な状況というわけではありません。このクライアントによる危険
性は、サーバにいくつかの手段を施せば軽減することができます。それらも簡
単に紹介します。

セキュリティ問題は自分には関係ない、という考えはおそらく間違いです。 
Section 6.1 ではポートマッパを安全にする方法を述べ、 Section 6.2 ではサ
ーバを、 Section 6.3 ではクライアントを安全にする方法をそれぞれ説明しま
す。最後に Section 6.4 で、 NFS サーバ向けの正しいファイアウォール設定
について簡単に議論したいと思います。

最後にもう一つ、 nfs のデーモンとクライアントプログラムのすべてを最新に
しておくことは非常に重要です。ごく最近にアナウンスされた問題だから自分
には関係ないだろう、という考えている人は、すでにその時点で侵入されてい
るかもしれませんよ。

最新のセキュリティ勧告を逃さないようにするには、 bugtraq メーリングリス
トを購読するのが良いでしょう。購読の方法など、bugtraq に関する各種の情
報は http://www.securityfocus.com/forums/bugtraq/faq.html にあります。

また securityfocus.com <http://www.securityfocus.com> の検索エンジンで 
NFS を検索すれば、 NFS に関連するセキュリティ報告のすべてを見ることもで
きます。

CERT の勧告も定期的にチェックしましょう。 www.cert.org <http://
www.cert.org> にある CERT のウェブページをご覧になってください。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

6.1. ポートマッパ

ポートマッパはどのサービスがどのポートで動作しているかの一覧を保管しま
す。接続してくるマシンは、あるサービスにアクセスするにはどのポートに接
続すれば良いかを、このリストを用いて知るのです。

ポートマッパは、数年前よりはだいぶましになりましたが、しかし現在でも多
くのシステム管理者の頭痛の種です。ポートマッパも、NFS や NIS と同じく、
信頼できるローカルエリアネットワークの外からはアクセスを許すべきではあ
りません。もし外部世界に晒さなければならない環境では、常に注意して、こ
れらのシステムを入念に監視しなければなりません。

Linux ディストリビューションは、すべて同じにはできていません。最新に見
えるディストリビューションでも、安全でないポートマッパを採用しているこ
とがあります。現在使っているポートマッパが安全なものかどうかを調べるに
は、 strings(1) を用いて、ポートマッパが /etc/hosts.deny や /etc/
hosts.allow といったファイルを見ているか調べることです。ポートマッパが
/sbin/portmap にあるのでしたら、次のコマンドでチェックできます:

     strings /sbin/portmap | grep hosts.                               
                                                                       

安全なマシンでは、次のような内容が出力されるはずです。
┌──────────────────────────────────┐
│   /etc/hosts.allow                                                 │
│   /etc/hosts.deny                                                  │
│   @(#) hosts_ctl.c 1.4 94/12/28 17:42:27                           │
│   @(#) hosts_access.c 1.21 97/02/12 02:13:22                       │
│                                                                    │
└──────────────────────────────────┘

まず /etc/hosts.deny を編集します。次のような行を含むようにします。

┌──────────────────────────────────┐
│   portmap: ALL                                                     │
│                                                                    │
└──────────────────────────────────┘

こうするとあらゆるアクセスを拒否します。このクローズした状態で
┌──────────────────────────────────┐
│   rpcinfo -p                                                       │
│                                                                    │
└──────────────────────────────────┘
を実行し、ポートマッパが実際にこのファイルを読み、その指定に従っている
かを調べてみてください。 rpcinfo は何の出力も出さないはずです (あるいは
エラーメッセージを出すかもしれません)。 /etc/hosts.allow および /etc/
hosts.deny の各ファイルは、保存すればすぐに反映されます。いずれのデーモ
ンも再起動する必要はありません。

ポートマッパをすべて閉じてしまうのは少々極端に過ぎるので、 /etc/
hosts.allow を編集して再びオープンしていきましょう。しかしまず、このフ
ァイルに何を書くか決めなければなりません。基本的にはこのポートマッパに
アクセスしなければならないすべてのマシンをリストします。通常の Linux シ
ステムを稼働させるにあたっては、なんらかの理由で何かのアクセスが必要に
なるマシンは非常に少ないはずです。ポートマッパが管理しているのは nfsd, 
mountd, ypbind/ypserv, rquotad, lockd (nlockmgr と表示されます), statd
(status と表示されます) など、および ruptime や rusers のような "r" 系
コマンド群です。このうちなんらかの重要性があるのは、 nfsd, mountd, 
ypbind/ypserv および場合によっては rquotad,lockd, statd だけでしょう。
サーバマシンにアクセスが必要なマシンには、それを許可してあげる必要があ
ります。いまサーバのアドレスが 192.168.0.254 で、サブネット 192.168.0.0
につながっているとします。そしてそのサブネットのすべてのマシンはサーバ
にアクセスする必要があるとします (これらの用語の概論としては 
Networking-Overview-HOWTO <http://www.linuxdoc.org/HOWTO/
Networking-Overview-HOWTO.html> を見てください。日本語訳 <http://
www.linux.or.jp/JF/JFdocs/Networking-Overview-HOWTO.html>も JF にありま
す)。この場合は
┌──────────────────────────────────┐
│   portmap: 192.168.0.0/255.255.255.0                               │
│                                                                    │
└──────────────────────────────────┘
のような行を /etc/hosts.allow に書きます。ネットワークとネットマスクが
はっきりしない場合は、 ifconfig コマンドを使えばネットマスクがわかり、 
netstat コマンドを使えばネットワークがわかります。例えば、このマシンで
デバイス eth0 に ifconfig すると、次のようになるはずです。

┌─────────────────────────────────────┐
│   ...                                                                    │
│   eth0   Link encap:Ethernet  HWaddr 00:60:8C:96:D5:56                   │
│          inet addr:192.168.0.254  Bcast:192.168.0.255 Mask:255.255.255.0 │
│          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1              │
│          RX packets:360315 errors:0 dropped:0 overruns:0                 │
│          TX packets:179274 errors:0 dropped:0 overruns:0                 │
│          Interrupt:10 Base address:0x320                                 │
│   ...                                                                    │
│                                                                          │
└─────────────────────────────────────┘
また netstat -rn は次のようになるはずです。
┌─────────────────────────────────────────┐
│   Kernel routing table                                                           │
│   Destination     Gateway         Genmask         Flags Metric Ref Use    Iface  │
│   ...                                                                            │
│   192.168.0.0     0.0.0.0         255.255.255.0   U     0      0   174412 eth0   │
│   ...                                                                            │
│                                                                                  │
└─────────────────────────────────────────┘
(ネットワークアドレスは最初の列にあります。)

/etc/hosts.deny および /etc/hosts.allow 各ファイルについては、それぞれ
同名の man ページで説明されています。 [訳注: hosts_access(5) の場合が多
いと思いますが。]

重要: これらのファイルの portmap の行に、 IP 番号以外のものを書いてはい
けません。ホスト名の名前引きは間接的にポートマッパを呼び出すことがあり
、するとまたホスト名の名前引き生じてポートマッパが呼び出され、するとま
た...

バージョン 0.2.0 以降では、nfs-utils パッケージも hosts.allow と
hosts.deny の各ファイルを利用します。従ってこれらのファイルには、 lockd
, statd, mountd, rquotad の各エントリも書いておきましょう。詳細な例は 
Section 3.2.2 を見てください。

以上の作業によって、サーバはよりしっかりするはずです。残りの問題は、信
頼したクライアントマシンで誰かが管理者権限を取得し、任意の NFS リクエス
トを送信可能となってしまうような場合です。次のセクションでは、この問題
に関する安全対策を扱います。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

6.2. サーバのセキュリティ: nfsd と mountd

サーバでは、クライアントの root から行なわれたリクエストを一切信頼しな
いようにできます。これには /etc/exports の指定に root_squash オプション
を用います:

   /home slave1(rw,root_squash)                                        
                                                                       

実はこれはデフォルトです。無効にすべき、やむにやまれぬ事情がない限り、
これは常に有効にしておくべきです。無効にするには no_root_squash オプシ
ョンを使います。

root_squash の状態では、クライアントで UID 0 (root のユーザ番号) のユー
ザがファイルにアクセス (read, write, delete) しようとすると、サーバは 
UID をサーバにおける 'nobody' アカウントのものと置き換えます。つまりサ
ーバの root だけにアクセスや変更が許されているファイルに対して、クライ
アントの root がアクセスや変更を行うことができなくなるのです。これは良
い設定ですので、 export する全てのファイルシステムに root_squash を用い
るべきです。「でもクライアントの root ユーザが su を使えば、他のユーザ
になってそのユーザのファイルを変更できちゃうじゃないですか！」とあなた
はおっしゃるかもしれません。答えは、まさにその通り、それが Unix や NFS
の流儀なのです。これにはひとつ重要な側面があります。重要なバイナリやフ
ァイルは、すべて root の所有にすべきで、 bin などの root 以外のアカウン
トにすべきではありません。なぜならクライアントの root ユーザがアクセス
できないのは、サーバの root アカウントのファイルだけだからです。 
exports(5) の man ページには、他にもいくつか squash (排他) オプションが
記述されています。これらを用いれば、好きな (あるいは嫌いな) クライアン
トを信頼しないように設定できます。

TCP のポート 1〜1024 は root が利用するために予約されており (従って
"secure ports" と呼ばれることがあります)、 root でないユーザはこれらの
ポートにバインドできません。 /etc/exports のエントリに secure オプショ
ンを追加すると、クライアント側のポート 1-1024 から来た接続要求のみを受
け付けるようになります。こうすると悪意を持った非 root ユーザが、偽装
NFS 通信を非特権ポートを使って開くことを防げます。このオプションはデフ
ォルトで有効になっています。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

6.3. クライアントのセキュリティ

6.3.1. nosuid マウントオプション

クライアント側では、サーバを信頼しすぎないように設定することが可能で、
これはマウント時のオプションで指定します。例えば NFS ファイルシステムに
ある suid プログラムを動作させないようにするには nosuid オプションを使
います。 unix プログラムの中には (例えば passwd)、 "suid" プログラムと
呼ばれるものがあります。これはファイルを実行するユーザ id を、そのファ
イルの所有者と同じにするものです。ファイルが root の所有で、かつ suid
されていると、そのプログラムは root として動作し、よって root にしか許
されていない操作 (パスワードファイルの書き込みなど) がすべて行えてしま
います。 nosuid オプションを用いるのはよい考えですから、 NFS マウントし
たディスクすべてに対し、利用を検討してください。こうするとサーバの root
ユーザが件のファイルシステムに suid-root プログラムを作り、クライアント
に一般ユーザとしてログインし、その suid-root プログラムを使ってクライア
ントでも root になる、ということができなくなります。さらに noexec オプ
ションをつければ、マウントしたファイルシステムでのファイルの実行を禁止
することもできます。しかしファイルシステムには実行すべきスクリプトやプ
ログラムが多少なりとも含まれているでしょうから、これは nosuid に比べる
とあまり実用的ではないでしょう。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

6.3.2. broken_suid マウントオプション

古いプログラム (xterm などがそうです) では、 root はどこにでも書き込み
可能である、という前提に依存していることがあります。これは新しいカーネ
ルと NFS マウントの下では成立しません。このような suid 動作を行うプログ
ラムは uid の変更に利用できてしまうため、 uid マッピングを行う nfs サー
バではセキュリティ上問題となります。従って linux カーネルのデフォルトで
は、この broken_suid は無効になっています。

かいつまんで言いますと、古い linux ディストリビューションである種の
suid プログラムを使う場合や、なんらかの古い unix を使っている場合は、マ
ウントの際に mount に broken_suid オプションを指定する必要があるかもし
れません。しかし最近の unix や linux ディストリビューションの xterm の
ようなプログラムは、 suid を必要としない通常の実行ファイルになっていて
、 setuid 動作を行うプログラムを別に呼び出すようになっています。

これらのオプションは、オプションのカラムに、 rsize や wsize などと一緒
にコンマで区切って書きます。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

6.3.3. ポートマッパ、rpc.statd, rpc.lockd をクライアントで安全にする

NFS の現在の (2.2.18 以降) の実装では、すべてのファイルロック機能がサポ
ートされています。よってクライアントでは、 rpc.statd と rpc.lockd を実
行し、ロック機能を正しく動作させる必要があります。したがって、これまで
nfs のサーバで見てきた問題が、そのままクライアントにも当てはまります。
上記のポートマッパの節をもう一度読んで、ポートマッパを安全にするための
情報を再確認してください。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

6.4. NFS とファイアウォール (ipchains と iptables)

IPchains (2.2.x カーネル) と iptables (2.4.x カーネル) を用いると、高い
安全性を実現できます。どのマシンが接続できるかの決定をデーモンに (ある
いは tcp ラッパーに) 行わせるのではなく、接続の試みをより下層で許可/拒
否するのです。この場合、接続をより早い段階で、またよりグローバルに切断
でき、あらゆる攻撃からマシンを守ることができるのです。

Linux のファイアウォールをどう設定するかは、この文書の範囲を大きく越え
ています。興味を持った読者は Firewall-HOWTO <http://www.linuxdoc.org/
HOWTO/Firewall-HOWTO.html> (JF の日本語訳 <http://www.linux.or.jp/JF/
JFdocs/Firewall-HOWTO.html>) や IPCHAINS-HOWTO <http://www.linuxdoc.org
/HOWTO/IPCHAINS-HOWTO.html> (JF の日本語訳 <http://www.linux.or.jp/JF/
JFdocs/IPCHAINS-HOWTO.html>) を見てください。カーネル 2.4 以降のユーザ
は、 http://netfilter.samba.org にある netfilter/iptables ウェブページ
に行ってみてください。すでに ipchains や netfilter の動作を熟知している
人には、この節の内容は NFS デーモンをファイアウォールによってどう守るか
について、いくつかのヒントを与えてくれるでしょう。

ファイアウォールの設定において従うべきルールは、まずすべてを禁止し、少
しだけ許可することです。こうすれば意図しない許可を間違って通さずにすみ
ます。

ファイアウォールよる NFS デーモンの守り方を理解するため、各デーモンがど
のポートを使うかについて見ておくことにしましょう。

デーモンは起動すると、ポートマッパに開いているポートを割り当ててくれる
よう要求します。ポートマッパはそのデーモンのためにポートを取得し、その
デーモンがポートを現在使っているかどうか追跡し続けます。他のホストやプ
ロセスがこのデーモンと通信する必要が生じたときは、それらはポートマッパ
に接続に用いるポート番号を尋ねます。よってポートはずっと浮動 (floating)
状態になります。いろいろなポートがいろいろなタイミングで解放されるので
、ポートマッパは場合によって別々のポートを割り当てるからです。これはフ
ァイアウォール設定にとっては厄介な問題です。デーモンの場所がわからなけ
れば、どのポートにアクセスを許すべきかが正確にはわからないからです。ほ
とんどの人にとっては保護された、あるいは隔離された LAN で作業しています
から、これはあまり大きな問題にはならないでしょう。しかし公開ネットワー
クにいる人たちにとっては、これは悪夢です。

カーネル 2.4.13 以降と nfs-utils 0.3.3 以降を組み合わせると、このポート
マッパによるポートの浮動を気にする必要はなくなります。今では NFS に関わ
るすべてのデーモンは、ポートを「固定」することができます。デーモンのほ
とんどは起動時に行儀良く -p オプションを受け付けます。カーネルから起動
されるデーモンは、カーネル引数やモジュールオプションを取ります。これら
は以下で解説します。

NFS でデータ共有を行うためのデーモンのいくつかは、すでにポートにバイン
ドされています。 portmap は常に tcp と udp のポート 111 を使います。 
nfsd は常に tcp と udp のポート 2049 を使います (しかしカーネル 2.4.17
までは NFS over TCP は実験的とみなされており、実用のマシンでは用いられ
ていませんでした)。

他のデーモン、 statd, mountd, lockd, rquotad は、ポートマッパから利用で
きると知らされた最初のポートを利用するので、ポートはいろいろになります
。

statd を特定のポートにバインドさせるには、 -p portnum オプションを用い
ます。 statd を特定のポートに反応させるには、さらに起動時に -o portnum
オプションを用います。

mountd を特定のポートにバインドさせるには、 -p portnum オプションを用い
ます。

例えば statd にポート 32765 をブロードキャストさせてポート 32766 で待機
させ、 mountd にポート 32767 で待機させるには、次のように入力します。

# statd -p 32765 -o 32766                                              
# mountd -p 32767                                                      

lockd は必要に応じてカーネルから起動されます。よって lockd に特定のポー
トで待機・反応させるには、カーネルオプションや (モジュールとしてビルド
された場合は) モジュールオプションを用います。

ローダブルモジュールを用いており、これらのオプションを /etc/
modules.conf ファイルで指定するには、次のような行をこのファイルに追加し
ます。

options lockd nlm_udpport=32768 nlm_tcpport=32768                      

この指定では、lockd の udp と tcp のポートを 32768 にします。

ローダブルモジュールを使わない場合や、 lockd をモジュールとしてビルドせ
ずにカーネルに組み込んだ場合は、選んだポートはカーネルのブート時に渡さ
なければなりません。

次のような感じになります。

 vmlinuz 3 root=/dev/hda1 lockd.udpport=32768 lockd.tcpport=32768      

ポート番号は同じにしなくてもかまいませんが、揃えないと不必要な混乱の原
因になってしまうでしょう。

quota を使っていて、その情報を nfs 経由でも見せるために rpc.quotad を使
っている場合は、これもファイアウォールの設定時に考慮しなければなりませ
ん。 rpc.rquotad には 2 つのソースツリーがあります。 1 つは nfs-utils
で管理されているツリーで、もう 1 つは quota-utils のツリーです。これら
は同じようには動作しません。 nfs-utils のものは、 -p で指定すればデーモ
ンをポートにバインドできます。 quota-utils のものはできません。自分のデ
ィストリビューションがどちらを使っているかは、ディストリビューションの
文書にあたってください。

ここでの議論のために、ネットワークと NFS サーバを守るためのファイアウォ
ールの設定を見ていきましょう。私たちの NFS サーバは 192.168.0.42 にあり
、クライアントは 192.168.0.45 のみとします。上述の例のように、 statd は
入ってくるリクエストについてはポート 32765 のみにバインド、応答するポー
トは 32766 を使うとします。 mountd はポート 32767 にバインドします。 
lockd のモジュールパラメータは、 32768 にバインドするよう設定します。も
ちろん nfsd はポート 2049 を使い、ポートマッパはポート 111 を使います。

quota は使わないことにします。

IPCHAINS を使った、簡単なファイアウォール設定は次のようになります。

ipchains -A input -f -j ACCEPT -s 192.168.0.45                         
ipchains -A input -s 192.168.0.45 -d 0/0 32765:32768 -p 6 -j ACCEPT    
ipchains -A input -s 192.168.0.45 -d 0/0 32765:32768 -p 17 -j ACCEPT   
ipchains -A input -s 192.168.0.45 -d 0/0 2049 -p 17 -j ACCEPT          
ipchains -A input -s 192.168.0.45 -d 0/0 2049 -p 6 -j ACCEPT           
ipchains -A input -s 192.168.0.45 -d 0/0 111 -p 6 -j ACCEPT            
ipchains -A input -s 192.168.0.45 -d 0/0 111 -p 17 -j ACCEPT           
ipchains -A input -s 0/0 -d 0/0 -p 6 -j DENY -y -l                     
ipchains -A input -s 0/0 -d 0/0 -p 17 -j DENY -l                       

同じ設定を netfilter で行う場合は次になります。

iptables -A INPUT -f -j ACCEPT -s 192.168.0.45                         
iptables -A INPUT -s 192.168.0.45 -d 0/0 32765:32768 -p 6 -j ACCEPT    
iptables -A INPUT -s 192.168.0.45 -d 0/0 32765:32768 -p 17 -j ACCEPT   
iptables -A INPUT -s 192.168.0.45 -d 0/0 2049 -p 17 -j ACCEPT          
iptables -A INPUT -s 192.168.0.45 -d 0/0 2049 -p 6 -j ACCEPT           
iptables -A INPUT -s 192.168.0.45 -d 0/0 111 -p 6 -j ACCEPT            
iptables -A INPUT -s 192.168.0.45 -d 0/0 111 -p 17 -j ACCEPT           
iptables -A INPUT -s 0/0 -d 0/0 -p 6 -j DENY --syn --log-level 5       
iptables -A INPUT -s 0/0 -d 0/0 -p 17 -j DENY --log-level 5            

最初の行ではパケットフラグメントを全て受け付けるようにしています (ただ
し先頭のフラグメントは通常のパケットのように扱われます)。理論的には、あ
らゆるパケットは再構成されるまでは通過しませんし、先頭のパケットフラグ
メントが通過しなければ再構成は不可能です。もちろんパケットフラグメント
を用いて、マシンを過負荷にしようとする攻撃も存在します。しかしフラグメ
ントを通すようにしないと、NFS は正しく動作しません。詳細は Section 7.8
を見てください。

他の行は、サーバで利用することにした特定のポートそれぞれへの、クライア
ントの任意のポートからの接続を許可しています。この設定によって、もし例
えば 192.158.0.46 が NFS サーバに接続を試みたとしても、そのマシンはマウ
ントもできず、なにがマウントできるかもわからないことになります。

新たに導入されたポート固定機能を用いれば、 NFS 共有へのマウントを許すホ
ストの制御は見ての通りずっと簡単になります。ただし NFS は暗号化されたプ
ロトコルではありませんから、同じ物理ネットワークにつながっていれば、誰
でもトラフィックを盗聴し、行き交う情報を再構成することが可能です。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

6.5. NFS に SSH をトンネルさせる

ネットワークの NFS トラフィックを暗号化する方法のひとつとして、 ssh の
ポートフォワード機能を用いるやり方があります。しかし、以下で見るように
、サーバのローカルユーザを完全に信頼できない場合は、これには深刻な欠点
もあります。

最初のステップは、ファイルをローカルホストにエクスポートすることです。
例えば /home パーティションをエクスポートする場合は、次の行を /etc/
exports に追加します。

/home   127.0.0.1(rw)                                                  

次のステップは ssh を用いてポートをフォワードすることです。 ssh を使う
と、クライアントの任意のポートを、任意のマシンの任意のポートにフォワー
ドできます。例えば前節のように、我々のサーバは 192.168.0.42 とし、 -p
32767 引数を用いて mountd をポート 32767 に固定したとしましょう。そして
、クライアントから次のように入力します。

     # ssh root@192.168.0.42 -L 250:localhost:2049  -f sleep 60m       
     # ssh root@192.168.0.42 -L 251:localhost:32767 -f sleep 60m       

このコマンドを使うと、クライアントの ssh はクライアントのポート 250 に
対して行なわれたリクエストをフォワードし、サーバの sshd を経由して、サ
ーバのポート 2049 へとフォワードします。次の行もおなじタイプのフォワー
ドで、クライアントのポート 251 へのリクエストをサーバの 32767 へフォワ
ードします。 localhost はサーバから見たホストです。つまり、フォワードは
サーバ自身に対してなされます。これとはべつに、ポートを任意の別のマシン
にフォワードすることもでき、そのリクエストは外世界に向け、サーバからな
されたかのように行われることになります。よって、このリクエストはサーバ
の nfsd に対して、サーバ自身から来たかのように見えます。ところで、クラ
イアントで 1024 以下のポートをバインドするには、このコマンドをクライア
ントの root として実行する必要があります。ファイルシステムをデフォルト
の secure オプションでエクスポートした場合には、こうしなければなりませ
ん。

なおここでは、最後のオプション -f sleep 60m を用いてちょっとしたトリッ
クを行っています。普通 ssh を用いると、 -L オプションを用いた場合でも、
リモートマシンでシェルをオープンすることになります。しかしここではポー
トフォワードをバックグラウンドで実行したいだけで、シェルはクライアント
に戻したいわけです。したがって ssh には、 60 分眠り続けるコマンドをサー
バのバックグラウンドで実行させているのです。これはポートを、接続がある
まで 60 分間フォワードします。接続があると、接続が切れるか 60 分が過ぎ
るまで、どちらか遅い方まで接続は継続します。上記のコマンドは、クライア
ントの起動スクリプトのネットワーク通信開始以降に置くこともできます。

次に、ファイルシステムをクライアントでマウントしなければなりません。こ
れを行うには、クライアントに対して localhost のファイルシステムをマウン
トするように、ただし通常の 2049 とは違うポートを用いるように、伝えます
。具体的に /etc/fstab のエントリを示すと、次のようになります。

  localhost:/home  /mnt/home  nfs  rw,hard,intr,port=250,mountport=251  0 0

ここまで来ると、サーバのローカルにログインできる通常のユーザがいると、
なぜ非常に危険になってしまうのかが理解できます。このようなユーザがいる
と、我々が行ってきたことを妨げるすべは一切なく、 ssh を用いて自分のクラ
イアントマシン (ここでは合法的に root になれます) の特権ポートをサーバ
のポート 2049 や 32767 にフォワードできます。このようにして、サーバの任
意のユーザは、我々のクライアントの root と同じ権限で、任意のファイルシ
ステムをマウントできることになります。 [訳注: 要するに、サーバが
localhost に対してエクスポートすることの危険性を言っています。]

NFS サーバで通常のユーザをログインさせておらず、かつこの方法を使いたい
場合でも、まだ 2 つ、警告しておくことがあります。まずひとつめ、クライア
ントからサーバへの接続は sshd を経由します。よってファイアウォールで、
ポート 22 (sshd が待機するポート) をクライアントに対して開けておく必要
があります。しかし、2049 や 32767 のような他のポートを開けておく必要は
もうありません。ふたつめ、ファイルロックが動作しません。 statd やロック
マネージャに対して、特定のマウントに対するリクエストを特定のポートに行
なわせることはできません。したがって、ロックリクエストがあると statd は
localhost の statd に、つまり自分自身に接続し、エラーは発生せずに失敗し
ます。これを修正するためには、NFS を大きく書き換えなければなりません。

IPSec を用いれば、サーバでのローカルなセキュリティの問題を生じさせない
形でクライアントとサーバ間でのネットワーク通信を暗号化できます。これは
ここでは取り上げません。 Linux で IPSec を用いるための詳細については、 
FreeS/WAN <http://www.freeswan.org/> ホームページを見てください。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

6.6. まとめ

hosts.allow, hosts.deny, root_squash, nosuid, 特権ポートの機能などをポ
ートマッパや NFS ソフトウェアに用いれば、現在 nfs で知られている多くの
バグを避けることができ、少なくともおおむね安全になったと考えることがで
きるでしょう。しかしそれでも結局のところ、侵入者がネットワークにアクセ
スできてしまえば、怪しいコマンドを .forward に書いたり、 /home や /var/
mail が NFS エクスポートされていればメールを読んだりできてしまいます。
また同じ理由から、PGP の秘密鍵は NFS 上に置いてはなりません。少なくとも
危険性があることは知っておくべきです。いまや知ったわけですけど。

NFS とポートマッパは複雑なシステムになっているので、新しいバグが、基本
的な設計にせよ我々の用いている実装にせよ、将来見つからないとは思えませ
ん。いまでも新しい穴がわかっていて、誰かがそれを悪用しているかもしれま
せん。でもそれが人生というものです。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

7. トラブルシュート

    この節は、NFS をうまく使えない場合にどうすればよいか、段階を踏んで
    解説しようというものです。通常トラブルはクライアント側からその兆候
    を現しはじめるので、診断もそこから始めます。
   
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

7.1. マウントしたファイルシステムでファイルが見えない

まず最初に、そのファイルシステムが実際にマウントされているのか確認して
ください。方法は何種類かありますが、一番確かなのは /proc/mounts を見る
ことです。ここにはマウントされているファイルシステムと、それらの詳細が
一覧になっています。これがうまくいかなければ (例えば /proc ファイルシス
テムをカーネルに組み込んでいなかったとか)、mount -f と入力してみてくだ
さい (示される情報は少なくなります)。

ファイルシステムがマウントされているようなら、もしかしたらその上に別の
ファイルシステムをマウントしてしまったのかもしれません (この場合は両方
のボリュームをアンマウントして、再マウントが必要です)。あるいはサーバで
そのボリュームのエクスポートを、実際のマウントの前に行ってしまったのか
もしれません。この場合 NFS はマウントポイントだけをエクスポートしてしま
います (この場合はサーバで NFS を再起動します)。

ファイルシステムがマウントされていなければ、マウントしてみてください。
できなければ症状 3 へ。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

7.2. ファイルリクエストがハングしたり、アクセス待ちでタイムアウトする

通常これは、クライアントがサーバと通信できない場合に起こります。症状 3
の b 項を見てください。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

7.3. ファイルシステムをマウントできない

ボリュームをマウントできない場合に mount が出すエラーは、ほぼ 2 種類で
す。それぞれを順に示しましょう。

 a. failed, reason given by server: Permission denied
   
    これは、ボリュームへのアクセスをサーバから拒否されたときに出るメッ
    セージです。
   
     i. /etc/exports ファイルを調べて、そのボリュームがエクスポートされ
        ているか、クライアントが正しいアクセス権限を持っているかを確認
        しましょう。例えば、読み取りのアクセスしかないクライアントが、
        そのボリュームを ro オプションではなく rw オプションでマウント
        しようとしていないでしょうか。
       
    ii. nfsd の起動以降に /etc/exports を変更した場合は、exportfs コマ
        ンドでそれを NFS に伝えたでしょうか。 exports を確実に再読み込
        みさせるには、 exportfs -ra コマンドを入力しましょう。
       
    iii. /proc/fs/nfs/exports ファイルを調べ、ボリュームとクライアント
        が正しくリストされているか確認しましょう。 (/var/lib/nfs/xtab
        を見れば、アクティブなエクスポートすべてに対する完全なオプショ
        ンのリストも得られます。) リストにない場合は、正しく再エクスポ
        ートされていません。リストにあった場合は、サーバがクライアント
        をあなたの意図通りに認識しているかを確認しましょう。例えばその
        クライアントの古いリストが /etc/hosts にあって、サーバはこっち
        を見ているのかもしれません。あるいはクライアントの完全なアドレ
        スを書いていないせいで、名前解決の結果がドメインの別のマシンに
        なっているかもしれません。例えばクライアントからサーバに ssh や
        telnet でログインしてみましょう。ここで who と入力すると、自分
        のログインセッションがリストに出るはずで、あなたのクライアント
        マシンがサーバからどのような名前で見えているかがわかります。こ
        のマシン名を /etc/exports のエントリに書きましょう。最後に、サ
        ーバからクライアントを ping し、クライアントからサーバを ping
        してみましょう。これでもだめだったり、あるいはパケットロスがあ
        った場合には、より下層のネットワークの問題でしょう。
       
    iv. あるディレクトリを、その子孫のディレクトリと同時にエクスポート
        する (例えば /usr と /usr/local) ことはできません。親ディレクト
        リを適切な許可属性でエクスポートすれば、そのサブディレクトリは
        すべて同じ許可属性でマウントできます。
       
 b. RPC: Program Not Registered (or another "RPC" error):
   
    これはクライアントが、サーバで実行中の NFS を検知できなかったことを
    意味しています。いくつかの理由が考えられます。
   
     i. 最初に、NFS が実際にサーバで動作しているかを確認しましょう。サ
        ーバで rpcinfo -p と入力します。次のような表示が出るはずです。
        ┌──────────────────────────┐
        │   program vers proto   port                        │
        │    100000    2   tcp    111  portmapper            │
        │    100000    2   udp    111  portmapper            │
        │    100011    1   udp    749  rquotad               │
        │    100011    2   udp    749  rquotad               │
        │    100005    1   udp    759  mountd                │
        │    100005    1   tcp    761  mountd                │
        │    100005    2   udp    764  mountd                │
        │    100005    2   tcp    766  mountd                │
        │    100005    3   udp    769  mountd                │
        │    100005    3   tcp    771  mountd                │
        │    100003    2   udp   2049  nfs                   │
        │    100003    3   udp   2049  nfs                   │
        │    300019    1   tcp    830  amd                   │
        │    300019    1   udp    831  amd                   │
        │    100024    1   udp    944  status                │
        │    100024    1   tcp    946  status                │
        │    100021    1   udp   1042  nlockmgr              │
        │    100021    3   udp   1042  nlockmgr              │
        │    100021    4   udp   1042  nlockmgr              │
        │    100021    1   tcp   1629  nlockmgr              │
        │    100021    3   tcp   1629  nlockmgr              │
        │    100021    4   tcp   1629  nlockmgr              │
        │                                                    │
        └──────────────────────────┘
        これらは、NFS の version 2 と 3、rpc.statd version 1、ネットワ
        ークロックマネージャ (サービス名は rpc.lockd) version 1, 3, 4
        が動作中であることを示しています。また NFS が TCP を使っている
        か UDP を使っているかに応じて、別々のサービスリストが表示されて
        います。 TCP を明示的に要求した場合を除き、通常は (常にではあり
        ません) UDP がデフォルトになります。
       
        少なくとも portmapper, nfs, mountd がなければ、 NFS を再起動し
        なければなりません。正しく再起動できないときは、症状 9 に進んで
        ください。
       
    ii. 次にクライアントから調べましょう。クライアントで rpcinfo -p 
        server と入力します。 server にはサーバの DNS 名か IP アドレス
        を入れてください。
       
        リストが表示された場合は、実行しようとしているマウントのタイプ
        がサポートされているか確認してください。 Version 3 NFS を使って
        マウントしたい場合は、 Version 3 がリストされているか確認します
        。 NFS over TCP でマウントしたい場合は、それが登録されているか
        確認してください (Linux でないクライアントでは、 TCP がデフォル
        トになっていることがあります)。出力の見かたに関するより詳しい情
        報を見るには man rpcinfo としてください。利用しようとしているマ
        ウントのタイプがリストにないときは、別のタイプのマウントを試し
        てみてください。
       
        No Remote Programs Registered というエラーが出たときは、サーバ
        の /etc/hosts.allow ファイルと /etc/hosts.deny ファイルを調べて
        、クライアントのアクセスが本当に許可されているか確認してくださ
        い。さらに、エントリが正しいようなら、 /etc/hosts (あるいは DNS
        サーバ) を確認して、クライアントマシンが正しくリストされている
        か、サーバからクライアントに ping が打てるかを確認してください
        。システムのエラーログに何か参考になるメッセージが出ていないか
        も見てみましょう。 /etc/hosts.allow のエントリが間違っている場
        合の認証のエラーは、通常 /var/log/messages に出ますが、システム
        ログの設定によっては別のファイルかもしれません。 syslog の man
        ページを見ると、ログ設定の理解の助けになるでしょう。最後に、古
        い OS では 2 台のマシン間の経路が対称的でないと、問題を生じるこ
        とがあります。クライアントから tracepath [server] と入力し、出
        力に "asymmetric" という単語が出ないことを確認してください。最
        近の Linux ディストリビューションなら、経路が非対称であっても問
        題は生じないはずです。
       
        Remote system error - No route to host, というエラーになり、し
        かし ping は届く場合には、きつすぎるファイアウォールの犠牲にな
        ったのでしょう。おそらくサーバ、またはサーバとクライアントの間
        に設置されているであろう、ファイアウォールを調べて下さい。情報
        は ipchains, netfilter, ipfwadm の man ページや、 
        IPChains-HOWTO <http://www.linuxdoc.org/HOWTO/
        IPCHAINS-HOWTO.html> (JF による日本語訳 <http://www.linux.or.jp
        /JF/JFdocs/IPCHAINS-HOWTO.html>) とか Firewall-HOWTO <http://
        www.linuxdoc.org/HOWTO/Firewall-HOWTO.html> (JF による日本語訳
        <http://www.linux.or.jp/JF/JFdocs/Firewall-HOWTO.html>) 等から
        得られます。
       
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

7.4. マウントしたボリュームで、ファイルにアクセスする権限がありません

2 つの原因が考えられます。

書きこみの権限がない場合は、サーバの /proc/fs/nfs/exports を見て、エク
スポートオプションを確認してください。そのファイルシステムは読み取り専
用になっていないでしょうか。読み取り専用の場合は、読み書きモードで再エ
クスポートしなければなりません (/etc/exports を編集した後は exportfs
-ra を忘れないように)。またクライアントの /proc/mounts も調べ、ボリュー
ムが読み書きモードでマウントされているか確認しましょう (読み取り専用で
マウントしている場合は、もうちょっと特定しやすいエラーメッセージが出て
いるでしょうが)。違っていたら rw オプションを付けて再マウントしましょう
。

2 つめの原因は、ユーザ名のマッピングに関係しており、 root の場合と非
root の場合とで少々異なります。

root でないときは、クライアントとサーバでユーザ名が一致していないかもし
れません。クライアントとサーバの両方で id [user] を実行し、UID 番号が同
じかどうか確認してください。異なっているときは、NIS, NIS+, rsync その他
、ユーザ名の同期に用いているシステムに問題があります。グループ名が一致
しているかも確認しましょう。また、エクスポートの際に all_squash オプシ
ョンを指定していないかどうかも確認しましょう。ユーザ名が一致していると
きは、そのユーザには NFS とは無関係な、より一般的な権限関連の問題がある
ものと思われます。

root の時は、エクスポートの際に no_root_squash オプションを付けていない
のではないでしょうか。サーバで /proc/fs/nfs/exports または /var/lib/nfs
/xtab を調べ、オプションが指定されているか確認してください。ただし一般
には、NFS サーバに root としての書きこみ権限を与えるのは、よほどの必要
がない限り良い考えではありません (Linux NFS がデフォルトでこれを禁止し
ている理由でもあります)。詳細は Section 6 を見てください。

root squash を用いている場合は、そのままにしておくのがいいでしょう。
root を取得しても、ファイルに対する権限は nobody のものと同じになります
。ただし root がどの uid にマップされるかを決めているのはサーバであるこ
とも忘れないように。デフォルトでは、サーバは /etc/passwd ファイルの 
nobody エントリの UID と GID を使いますが、/etc/exports ファイルで 
anonuid オプションや anongid オプションを使えば、これらを変更できます。
クライアントとサーバで、nobody にマップされる UID が同じになっているか
も確認しておきましょう。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

7.5. 非常に大きなファイルを転送すると、 NFS がサーバの CPU を取ってしま
って、止まったようになってしまいます

これは 2.2 カーネルの fsync() コールの問題で、すべての sync-to-disk リ
クエストを同時に行うからです。従って書きこみ時間がファイルサイズの二乗
になってしまいます。可能なら、2.4 カーネルにすれば問題は解決します。ま
たエクスポートに no_wdelay オプションを指定すれば、各プログラムはより高
速な o_sync() を使うようになります。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

7.6. ログに奇妙なエラーメッセージが出る

 a. 次のようなフォーマットのメッセージ:
   
    ┌──────────────────────────────────────────────┐
    │ Jan 7 09:15:29 server kernel: fh_verify: mail/guest permission failure, acc=4, error=13    │
    │ Jan 7 09:23:51 server kernel: fh_verify: ekonomi/test permission failure, acc=4, error=13  │
    │                                                                                            │
    └──────────────────────────────────────────────┘
   
    これらは NFS の setattr オペレーションが、書き込み権限のないファイ
    ルに対して試みられたときに起こります。これらのメッセージは無害です
    。
   
 b. 次のようなメッセージがログに頻繁に現われる:
   
    ┌───────────────────────────────────┐
    │ kernel: nfs: server server.domain.name not responding, still trying  │
    │ kernel: nfs: task 10754 can't get a request slot                     │
    │ kernel: nfs: server server.domain.name OK                            │
    │                                                                      │
    └───────────────────────────────────┘
   
    この "can't get a request slot" というメッセージは、クライアント側
    の RPC コードがタイムアウトをたくさん検出 (おそらくはネットワークの
    混雑やサーバの過負荷のため) したために、同時要求数の値を小さくし、
    サーバの負荷を軽減しようとしていることを示しています。これらのメッ
    セージの原因は、おそらくは性能が悪いためです。 Section 5 を見てみて
    ください。
   
 c. マウントした後、クライアントで次のようなメッセージが出る:
   
    ┌────────────────────────────┐
    │nfs warning: mount version older than kernel            │
    │                                                        │
    └────────────────────────────┘
   
    これは書いてあるとおりです。mount のパッケージや am-utils をアップ
    グレードしてください (なんらかの理由でアップグレードできない場合は
    、コンパイルしなおして、新しいカーネルの機能がコンパイル時に認識さ
    れるようにするだけでも、取り合えずは回避できます)。
   
 d. 起動時/終了時に lockd のログにエラーが出る:
   
    ブートログに次のようなメッセージが出ているのでしょうか:
    ┌────────────────────────────┐
    │nfslock: rpc.lockd startup failed                       │
    │                                                        │
    └────────────────────────────┘
   
    これらは無害です。古いバージョンの rpc.lockd は手動で起動する必要が
    ありました。しかし新しいバージョンでは nfsd によって自動的に起動さ
    れます。現在のデフォルトの起動スクリプトの多くは、まだ lockd を直接
    起動しようとしますが、これは不要なのです。このメッセージを止めさせ
    たければ、起動スクリプトを変更すれば OK です。
   
 e. 次のようなメッセージがログに現われる:
   
    ┌────────────────────────────┐
    │kmem_create: forcing size word alignment - nfs_fh       │
    │                                                        │
    └────────────────────────────┘
   
    これはファイルハンドルが 32 ビットの倍数ではなく 16 ビットであるこ
    とから来ています。このためカーネルの機嫌がちょっと悪くなっているの
    です。無害です。
   
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

7.7. 実際のパーミッションが /etc/exports の指定と異なる

/etc/exports はスペースに非常に敏感です。例えば以下の 2 行は同じではあ
りません:

/export/dir hostname(rw,no_root_squash)                                
/export/dir hostname (rw,no_root_squash)                               
                                                                       

先の方は、hostname に /export/dir 対する rw アクセスを与え、 root 権限
の禁止 (root_squash) はしていません。二番目のは、hostname に rw 権限を
与えて root_squash を指定、そして「あらゆるホスト」に rw アクセスを与え
、 root_squash はしていません。わかりました?

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

7.8. おかしな、不安定な振舞いをする

ls のような簡単なコマンドは動作するが、大量の情報を転送するような作業を
行うとマウントポイントがロックする。

2 つの理由が考えられます。

 i. サーバやクライアントで ipchains を使っており、フラグメント化された
    パケットがチェインを通れないようにしていると、このようなことが起こ
    ります。リモートホストからのフラグメントを許可すれば、再び機能する
    はずです。やり方は Section 6.4 を見てください。
   
ii. マウントオプションの rsize や wsize に、サーバがサポートしているよ
    りも大きな値を指定しているのかもしれません。 rsize や wsize を 1024
    に減らして、問題が解決するか見てください。解決したら、再びゆっくり
    と、より適切な値に増やしてあげてください。
   
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

7.9. nfsd が起動しない

/etc/exports を調べ、 root に対する読み取り許可があるか確認してください
。バイナリを調べ、実行ファイルであるか確認してください。カーネルに NFS
サーバのサポートが組み込まれているでしょうか。これらのいずれでも解決し
なければ、バイナリをインストールしなおす必要があるかもしれません。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

7.10. 複数のクライアントを使うとファイルが壊れる

ファイルが修正されてから 1 秒以内に別の修正がなされ、その際にサイズが変
わらなかった場合、同じ inode 番号が生成されます。このため、一つのファイ
ルに複数のクライアントから連続的に読み書きが行われると、ファイルが壊れ
ることがあります。このバグを修正するには、ファイルシステムの深い部分を
変更しなければならないため、 2.5 における課題になっています。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

8. Linux の NFS を他の OS と使う

あらゆる OS (Linux も含む) には、それぞれの NFS の実装に、ちょっとした
違いや癖があります。ある場合はプロトコルが曖昧なせいだったり、ある場合
はでっかいセキュリティホールを残したままであるせいだったり、理由はいろ
いろです。 Linux は、我々の知る限りでは、メジャーなベンダの NFS 実装す
べてと正しく動作します。しかし、 2 つの OS がお互いクリアに通信している
かどうかを確認するには、追加の作業が必要になることもあります。このセク
ションではこれらの作業を細かく見ていきます。

一般的に言って、カーネル 2.2.18 よりも前の Linux マシンを、 Linux 以外
のクライアントの NFS サーバとするのは、全くおすすめできません。古いカー
ネルでの実装は、クライアントとしてなら問題なく動作すると思います。しか
しこれらのカーネルで何か問題が起きた場合、我々からできるアドバイスは、
まずカーネルをアップグレードして問題が解決するか見てみろ、です。ユーザ
空間の NFS 実装も、 Linux 以外のクライアントとはうまく動きません。

以降に、Linux をメジャーな OS といっしょに使う場合に知られている事柄を
挙げておきます。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

8.1. AIX

8.1.1. Linux クライアントと AIX サーバ

Section 3 で用いた例に対応する /etc/exports ファイルのフォーマットは、
次のようになります。

  /usr   slave1.foo.com:slave2.foo.com,access=slave1.foo.com:slave2.foo.com 
  /home  slave1.foo.com:slave2.foo.com,rw=slave1.foo.com:slave2.foo.com     
                                                                            

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

8.1.2. AIX クライアントと Linux サーバ

AIX は /etc/fstab ではなく /etc/filesystems を用います。 Section 4 での
例に対応するエントリのサンプルを示しておきます。

/mnt/home:                                                                    
        dev             = "/home"                                             
        vfs             = nfs                                                 
        nodename        = master.foo.com                                      
        mount           = true                                                
        options         = bg,hard,intr,rsize=1024,wsize=1024,vers=2,proto=udp 
        account         = false                                               
                                                                              

 i. AIX の Version 4.3.2 (おそらくはそれ以前のバージョンも) に対しては
    、ファイルシステムを insecure オプションでエクスポートする必要があ
    ります。すなわち NFS を非特権ポート (つまり 1024 以上の、root 以外
    のユーザがバインドできるポート) で待機させます。古いバージョンの
    AIX では、これは必要ないようです。
   
ii. AIX のクライアントは、デフォルトでは Version 3 NFS over TCP でマウ
    ントします。 Linux サーバがこれをサポートしていない場合は、マウント
    のオプションに vers=2 や proto=udp を指定しなければなりません。
   
iii. /etc/exports にネットマスクを使うと、あるクライアントがリセットし
    たときに、別のクライアントのマウントが切れてしまう場合があります。
    これは各ホストを一つ一つリストすれば解決します。
   
iv. AIX 4.3.2 の automount は、明らかにどこか変です。
   
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

8.2. BSD

8.2.1. BSD サーバと Linux クライアント

BSD カーネルはブロックサイズを大きくしたほうがより良く動作する傾向があ
ります。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

8.2.2. Linux サーバと BSD クライアント

BSD のバージョンによっては、サーバが非特権ポートで動作している必要があ
ります。この場合ボリュームをエクスポートするときに insecure オプション
が必要になります。詳細は exports(5) の man ページを。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

8.3. Tru64 Unix

8.3.1. Tru64 Unix サーバと Linux クライアント

一般に Tru64 Unix サーバは Linux クライアントと極めて良好に動作します。
Section 3 で我々が用いた例に対応する /etc/exports ファイルのフォーマッ
トは、次のようになります。

                                                                       
/usr         slave1.foo.com:slave2.foo.com \                           
     -access=slave1.foo.com:slave2.foo.com \                           
                                                                       
/home        slave1.foo.com:slave2.foo.com \                           
         -rw=slave1.foo.com:slave2.foo.com \                           
       -root=slave1.foo.com:slave2.foo.com                             
                                                                       

(ここで最後のエントリにある root オプションは情報を示しているだけです。
必要なければ指定しなくても構いません。)

Tru64 は、マウント要求があるたびに /etc/exports ファイルをチェックしま
す。従って exportfs コマンドを起動する必要はありません。実際 Tru64 Unix
の多くのバージョンでは、このコマンドは存在しません。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

8.3.2. Linux サーバと Tru64 Unix クライアント

この組み合わせには注意点が 2 つあります。まず、 Tru64 Unix のマウントは
デフォルトで Version 3 NFS を用います。 Linux のサーバが Version 3 NFS
をサポートしていないと、マウントエラーになるでしょう。次に、Tru64 Unix
4.x では、NFS ロックリクエストを daemon が行います。従って Tru64 Unix
4.x クライアントにエクスポートするボリュームには、すべて insecure_locks
を指定する必要があります。詳細は exports(5) の man ページを。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

8.4. HP-UX

8.4.1. HP-UX サーバと Linux クライアント

HP-UX での /etc/exports のエントリの例を挙げます。

/usr -ro,access=slave1.foo.com:slave2.foo.com                             
/home -rw=slave1.foo.com:slave2.fo.com:root=slave1.foo.com:slave2.foo.com 
                                                                          

(最後のエントリでの root オプションは、情報として示す目的だけです。いら
なければ指定しなくても構いません。)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

8.4.2. Linux サーバと HP-UX クライアント

HP-UX のディスクレスクライアントに対して、デバイスファイルを正しくエク
スポートするには、少なくともカーネルのバージョン 2.2.19 (あるいは
2.2.18 にパッチを当てたもの) が必要になります。また、HP-UX クライアント
へエクスポートする際には、必ず insecure_locks オプションを指定する必要
があります。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

8.5. IRIX

8.5.1. IRIX サーバと Linux クライアント

IRIX での /etc/exports のエントリの例を挙げます。

/usr -ro,access=slave1.foo.com:slave2.foo.com                             
/home -rw=slave1.foo.com:slave2.fo.com:root=slave1.foo.com:slave2.foo.com 
                                                                          

(最後のエントリでの root オプションは、情報を示す目的でのみ用いられてい
ます。いらなければ指定しなくても構いません。)

報告によると、linux 2.2 ベースのシステムに nohide オプションを用いてエ
クスポートすると問題があるそうです。これは 2.4 カーネルでは修正されてい
ます。とりあえず回避するには、ファイルシステムの下の階層を別々にエクス
ポートしてマウントさせることです。

カーネル 2.4.17 の時点では、相互運用上の小さな問題がまだ存在しており、
カーネルのアップグレードが必要になるかもしれません。特記すべきことをい
くつか述べておきます。

 ・ Trond Myklebust の seekdir (または dir) カーネルパッチを忘れずに適
    用しておいてください。最新版 (2.4.17 向け) は次の場所にあります。
   
    http://www.fys.uio.no/~trondmy/src/2.4.17/linux-2.4.17-seekdir.dif
    <http://www.fys.uio.no/~trondmy/src/2.4.17/
    linux-2.4.17-seekdir.dif>
   
 ・ IRIX サーバは、再起動の前後で同じ fsid 属性フィールドを用いるとは限
    らないため、マウントしている IRIX サーバが再起動すると Linux クライ
    アントで inode number mismatch というエラーになるかもしれません。パ
    ッチは次の場所にあります。
   
    http://www.geocrawler.com/lists/3/SourceForge/789/0/7777454/ <http:
    //www.geocrawler.com/lists/3/SourceForge/789/0/7777454/>
   
 ・ naming version=1 で作成された IRIX XFS ファイルシステムがエクスポー
    トされたものから、数百のファイルを保持しているような大きなディレク
    トリを読み出そうとすると、 Linux カーネル 2.4.9 以降では問題が起こ
    りました。理由は次の URL に与えられています。
   
    http://www.geocrawler.com/archives/3/789/2001/9/100/6531172/ <http:
    //www.geocrawler.com/archives/3/789/2001/9/100/6531172/>
   
    naming version は、(IRIX サーバで) 次のコマンドを用いればわかります
    。
   
            xfs_growfs -n mount_point                           
                                                                
   
    問題を回避するには、これらのファイルシステムのエクスポートに際して
    、 /etc/exports ファイルで -32bitclients オプションを指定します。問
    題を修正するには、ファイルシステムを 'naming version=2' に変換しま
    す。残念ながら、これを行うには backup/mkfs/restore が唯一の方法です
    。
   
    IRIX 6.5.14 (およびそれ以降) で mkfs_xfs を行うと、デフォルトでは 
    naming version=2 の XFS ファイルシステムができます。 IRIX 6.5.5 か
    ら 6.5.13 の間では、次のコマンドを用いてください。
   
            mkfs_xfs -n version=2 device                        
                                                                
   
    IRIX 6.5.5 以前では、 naming version=2 の XFS ファイルシステムはサ
    ポートされていません。
   
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

8.5.2. IRIX クライアントと Linux サーバ

IRIX のバージョン 6.5.12 までには、 Linux マシンがエクスポートしたファ
イルシステムをマウントすると、問題が起こりました。マウントポイントが「
消えて」しまうのです。すなわち:

        # mount linux:/disk1 /mnt                                      
        # cd /mnt/xyz/abc                                              
        # pwd                                                          
        /xyz/abc                                                       
                                                                       

これは IRIX のバグであることがわかっており (SGI bug 815265 - IRIX not
liking file handles of less than 32 bytes)、 IRIX 6.5.13 で修正されまし
た。 IRIX 6.5.13 にアップグレードすることが不可能な場合には、非公式な回
避方法ですが、常に 32 ビットのファイルハンドルを用いるよう Linux の 
nfsd に強いるやり方もあります。

たくさんのパッチがあります。次のところを見てください。

 ・ http://www.geocrawler.com/archives/3/789/2001/8/50/6371896/ <http:/
    /www.geocrawler.com/archives/3/789/2001/8/50/6371896/>
   
 ・ http://oss.sgi.com/projects/xfs/mail_archive/0110/msg00006.html
    <http://oss.sgi.com/projects/xfs/mail_archive/0110/msg00006.html>
   
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

8.6. Solaris

8.6.1. Solaris サーバ

Solaris のサーバ側の形式は、他の OS と少々異なっています。設定ファイル
には /etc/exports でなく /etc/dfs/dfstab を用います。エントリには share
コマンドを用います。 Section 3 での例に対応する書式は次のようになります
。

share -o rw=slave1,slave2 -d "Master Usr" /usr                         
                                                                       

そして編集後には、exportfs の代わりに shareall を実行します。

Solaris のサーバはパケットサイズに非常に敏感です。 Linux クライアントを
Solaris サーバと使う場合には、必ずマウント時に rsize と wsize を 32768
にしてください。

最後に Solaris における root squash について述べておきます。 root はユ
ーザ noone にマップされますが、これはユーザ nobody とは異なります。クラ
イアントでファイルのパーミッションに関して問題がおきたら、マッピングが
期待通りになっているか、忘れずにチェックしてください。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

8.6.2. Solaris クライアント

Solaris のクライアントは定期的に次のようなメッセージを出します。

┌──────────────────────────────────┐
│svc: unknown program 100227 (me 100003)                             │
│                                                                    │
└──────────────────────────────────┘

これは Solaris のクライアントが、マウントする際に ACL 情報を取得しよう
とするからです - もちろん Linux にはありません。このメッセージは無視し
て構いません。

ディスクレスな Solaris クライアントに関しては、 2 つほど注意点がありま
す。まず /dev/null を正しくエクスポートするには、少なくともカーネルのバ
ージョンが 2.2.19 でなければなりません。次に、ディスクレスの sparc クラ
イアントでは、パケットサイズを非常に小さく (すなわち 1024 に) しなけれ
ばなりません。クライアントはパケットを逆に並べ換えることができないから
です。これはクライアントの /etc/bootparams で設定できます。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

8.7. SunOS

SunOS には NFS Version 2 over UDP しかありません。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

8.7.1. SunOS サーバ

サーバ側では、SunOS は /etc/exports ファイルの伝統的な形式を用います。 
Section 3 での例は次のようになります。

/usr    -access=slave1.foo.com,slave2.foo.com                                 
/home   -rw=slave1.foo.com,slave2.foo.com, root=slave1.foo.com,slave2.foo.com 
                                                                              

ここでも、 root オプションは情報を示す目的でのみ使われており、いらなけ
れば指定しなくても構いません。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 

8.7.2. SunOS クライアント

SunOS は NFS ロックリクエストをすべて daemon として行います。従って
SunOS クライアントにエクスポートするボリュームには、すべて 
insecure_locks を指定する必要があります。詳細は exports(5) の man ペー
ジを。

