FreeBSD で NFS (1) 【NFS概要】

Seichan です．こんばんわ．今年もあと1時間を切りました…
ちょっと GEOM 以外に行っておきたいなぁと思いましたので，NFS に逃げてみます．

FreeBSD の NFS について以前 Pukiwiki の「FreeBSD で NFS(Network File System) サーバ & クライアント」に纏めていたのですが，当時 5.0 Release 位で纏めてますので少し状況が変わってきています．
ですので今のバージョン 9.2-RELEASE をターゲットに改めて纏めてみます。

NFSのおさらい

NFSというプロトコルの説明は他で見て頂くとして，簡単に説明します．

NFS のバージョン

NFS バージョンは v2, v3, v4 の3つがあります．v1 は Sun Microsystems 内部でのみ存在したバージョンのようです．
多くのところでは NFSv3 が利用されています．v2 はもう利用している所は殆どないと思います．NFSv4 の利用は増えていっていますが，v3 決め打ちの製品がある等で今一歩という所です．v3 決め打ちの有名どころでは ESX/ESXi ですね．

各バージョンの違いを簡単に表にすると次のような形です．

NFSv3 を構成するプログラム(デーモン)

NFS は単純なようで少し複雑で，複数のデーモンを利用してサービスが提供されています．それらデーモンの役割を簡単に記載します．

• rpcbind

以前は portmap デーモンと呼ばれていました．RPC プログラム番号からユニバーサルアドレスに変換するサーバです．RPC を使用するプログラムは，プログラム開始時に rpcbind に通知され，それらプログラムが待ち受けるポート番号の情報や RPC プログラム番号等が登録されます．後述する mountd は RPC を利用しますのでこのプログラムは動作必須なものとなります．

• mountd

mountd はマウント処理を担当するデーモンです．NFS アクセスを行うにあたりファイルハンドルが必要となります．inode のようなものですね．NFS クライアントがこのファイルハンドルの番号をどうやって知ることが出来るのか．という所で mountd が NFS 居優しているディレクトリ(マウントポイント) のファイルハンドルを NFS クライアントに通知する事により解決します．以降，NFS クライアントは基点のファイルハンドルを知っていますので直接 nfsd とやり取りを行います．
ということで，mountd は NFS アクセスの一発目のみ介在する事になります．その為，NFS マウント済みのクライアントが存在する中，そのクライアントを許可ネットワークから外した場合でも NFS クライアントはそのまま通信が出来てしまいます．これを対処する方法は一度 NFS セッション自体を切断するしかありませんので注意してください．

• nfsd

NFS サーバデーモンです．RPC を使いますので，rpcbind に依存します．NFS リクエストを受けた後，ローカルのファイルシステムへのアクセスに変換して読み書き等の処理を行った後 NFS クライアントに結果を返します．

• rpc.lockd

rpc.lockd は NFS プロトコル上でファイルロックを実現するためのデーモンです．上述の表内のファイルロックの個所にて別プロトコルと書いてますが，このデーモンが該当します．NFS と別のプロトコルとして NFS Lock Manager (NLM) というプロトコルが開発されました．rpc.lockd はそのプロトコルを担当します．これが動作していないとファイルロックが利用できない為，色々と不都合が起きます．このデーモンは，サーバ/クライアント双方で必要となります．5.0-RELEASE あたりから利用できるようになりましたが，8.x 頃に kernel に統合されました．

• rpc.statd

rpc.statd は NFS Lock Manager のステータスを管理する NFS Status Monitor プロトコルのデーモンです．上述の表内のステート保持の個所にて別プロトコルと書いてますが，このデーモンが該当します．NFS Lock Manager は状態を保持する機能が無く，NFS サーバが再起動した場合等，それまでのロック情報が全て失われる事になります．それを防ぐためロック情報をローカルに持ち，サーバ復旧後にその情報を元にロック状態を引き継ぎます．

FreeBSD の NFS 実装

FreeBSD では，8.0 で NFS 実装に変化がありました．具体的には NFSv4 に対応した新しい実装が入り，既存と新規の2つの実装がそのまま入る形になっています．何も指定しない場合は古い実装の NFS サービスが動作します．
9.0 ではこれが逆になり，なにも指定しない場合は新しい実装の NFS サービスを利用する事となりました．古い実装を明示的に利用する事も出来ますが，9.2-RELEASE 時，特段の理由がない限りは新しい実装で十分だと思います．
自分の環境では 9.0-RELEASE の頃は新しい実装だと正常に使えなかったため，明示的に古い実装で動かすようにしていましたが… 今時点では新しい実装を素直に利用しています．

NFSv3 までの落とし穴

FreeBSD に限らず NFS で良くはまる箇所が幾つかあります．

• UID と GID の不一致

NFSv3 までは，サーバ上の UID/GID とクライアントの UID/GID は一致している事が前提です．管理できないクライアントを NFS サーバに接続した場合，意図しないファイルアクセスが出来てしまいます．
たとえば，サーバ側の UID 100: seichan で，クライアント側 UID 100: foo だった場合，クライアントで foo が NFS アクセスした際，サーバ上の seichan がオーナーのファイル読み書きが出来てしまいます．
root アクセスを許可している環境ではより危険です．管理出来ていない端末の接続を最初から拒否するような状態にした運用を行う必要があります．

• ポート番号が不定

RPC を使用する為，ポート番号が一定ではありません．その為，良くファイアウォールで拒否されてしまい NFS アクセスが出来ない
．なんてトラブルが発生します．指定する事で固定化出来ますので固定化をしたのちに問題が無いか確認，その後フィルタルールを設定する．なんていう対応が必要となります．
また，異機種間の場合は正しく固定化出来るのか．等をあらかじめ確認しておく事をお薦めします．

次は NFS サーバの設定まわりですです．