NFS | 徒然なるままに https://www.seichan.org 徒然と日々の出来事(ネタ)を書いていこうかと．主に FreeBSD，Unix系の話題が中心ですが，その他の話題もあつかってみたり． Sat, 23 Mar 2024 05:09:11 +0000 ja hourly 1 https://wordpress.org/?v=7.1.2 FreeBSD で NFS (NFSクライアントとマウントオプション②) https://www.seichan.org/2014/01/post-367.html https://www.seichan.org/2014/01/post-367.html#respond Sun, 26 Jan 2014 15:59:09 +0000 http://www.seichan.org/blog/?p=367 FreeBSD の NFS について以前 Pukiwiki の「FreeBSD で NFS(Network File System) サーバ & クライアント」に纏めていましたが，当時 5.0 RELEASE の頃に纏めてましたのでだいぶ状況が変わってしまいました．
ですので今のバージョン 9.2-RELEASE をターゲットに改めて解説します．

前回「FreeBSD で NFS (NFSクライアントとマウントオプション①)」で NFS クライアント側の説明に移りました．今回も同様にクライアント側の説明行います．

クライアント側設定

フォアグラウンドとバックグラウンド

NFS マウントを行う際，フォアグラウンドでのマウントは -o fg オプションで実行します．一方，バックグラウンドでのマウントは -o bg オプションを使用します．オプションを付けない場合はデフォルトでフォアグラウンドでのマウントとなります．

たとえば，/etc/fstab に NFS マウントを記述している場合，フォアグラウンドマウントでは NFS マウントが成功するまで処理がブロックされ，次の処理に移行しません．そのため，サーバ起動時にマウント処理が完了するまで待機します．

一方，バックグラウンドマウントでは，NFS マウントが失敗しても後続の処理が進行し，再試行はバックグラウンドで行われます．これにより，マウント処理が失敗した場合でもサーバーの起動が進行し，ログインプロンプトの表示まで待機することができます．

どちらを選択するかは，NFS マウントの目的によります．ホームディレクトリーや Web コンテンツなどの重要なファイルをマウントする場合は，フォアグラウンドでのマウントが適しています．一方、独自ビルドしたパッケージのリポジトリーなど，通常の操作に影響を与えないファイルをマウントする場合は，バックグラウンドでのマウントを検討することができます．

したがって，次のように覚えるのが良いでしょう．

  • マウントできていないと困る場合はフォアグラウンド (fg)
  • 無くても困らない場合はバックグラウンド (bg)

ハードとソフト

NFS マウントを行う際，ハードマウントの場合は -o hard オプションを使用します．一方，ソフトマウントの場合は -o soft オプションを指定します．これらのオプションを省略した場合は，デフォルトでハードマウントが適用されます．

ハードマウントの場合，NFS サーバーからの応答がなくタイムアウトした場合，ファイル操作は無期限に再試行されます．また，シェル上でのファイル操作時には「nfs server not responding」というメッセージがコンソールに表示され，中断操作を受け付けません．
一方，ソフトマウントの場合，タイムアウト時にはファイル操作を呼び出したプログラムに「I/O Error」が返されます．

これらの違いから，ソフトマウントの方がより優れているように思われますが，実際にはアプリケーションの動作によって異なります．例えば，NAS などの冗長化された NFS サーバー環境では，NFS サーバーに障害が発生しても数分でフェイルオーバーされ，再び利用可能になることが多いです．このような場合，ハードマウントを使用すると切り替わり後に処理を継続できますが，ソフトマウントの場合はエラーが返り，関連するプログラムがエラーで終了する可能性があります．

個人的な見解として，クライアント用途や小規模の NFS サーバーが冗長化されていない環境では，ソフトマウントの方が扱いやすいと考えられます．一方，サーバー環境や大規模の NFS サーバーが冗長化されている場合は，ハードマウントの方が適していると考えられます．

ハードマウントと割り込み

ハードマウントの場合，NFS サーバからの応答がなくタイムアウトした場合，ファイル操作は無期限に再試行されます．また，シェル上でのファイル操作時には「nfs server not responding」というメッセージがコンソールに表示され，一切の中断操作を受け付けません．
これが都合の悪い場合，割り込みを受け付けるようにするオプション -o intr を使用します．このオプションを指定すると Ctrl+C (SIGINT) を発行してプロセスをエラーで終了させることができます．
したがって，ハードマウントする場合は割り込みも合わせて指定するようにしてください．つまり -o hard,intr です。

読み込みデータサイズと書き込みデータサイズ

読み込みと書き込み時に NFS が利用するバッファーサイズを調整することができます．通常，FreeBSD 9.2 では読み書きいずれも 8192 バイトがデフォルト値です．一般的にはこのサイズでも十分なパフォーマンスが得られますので，特に理由がなければデフォルトのままでも問題ありません．

ただし，最近のサーバ (PCでも同様です) の処理速度の向上や NIC 自体の性能向上により，バッファーサイズを上げることでパフォーマンスを向上させることができます．

読み取りバッファーサイズは -o rsize=バッファーサイズ，書き込みバッファサイズは -o wsize=バッファーサイズ を指定します．バッファーサイズは 1024 バイト以上で，2 のべき乗を指定する必要があります．たとえば、8192 の次に大きい値は 16384 です．それ以上の値を指定しても，無意味な場合や逆にパフォーマンスが低下する可能性があります．

いずれの場合も，本番環境で使用する前に十分な試験が必要です．個人的には 32768 がお勧めです．
ほとんどの環境で良好なパフォーマンスを提供し，基準値として利用しています．

なお，設定によってはパフォーマンスが低下する可能性があるため，ご利用の際は自己責任でお願いします．

NFS マウントオプションのまとめ

ここまでで通常利用する NFS マウントオプションについては解説出来たと思います．これらオプションを纏めるとおすすめのマウントオプションは次のようなオプション群になります．このオプションを基準に挙動やパフォーマンスを確認して行くのが良いと思います．

ここまでで，通常利用する NFS マウントオプションについては解説が完了しました．これらのオプションをまとめると，以下のようなおすすめのオプション群になります．これらのオプションを基準にして，挙動やパフォーマンスを確認していくことが重要です．

  • -o bg: バックグラウンドでのマウントを行います．マウントが失敗した場合でも処理を続行します
  • -o hard: ハードマウントを行います．再試行を延々と続け，中断操作を受け付けません
  • -o intr: 割り込みを受け付けるように設定します．ハードマウントと併用することが推奨されます
  • -o rsize=32768: 読み取りバッファサイズを 32768 バイトに設定します
  • -o rsize=32768: 書き込みバッファサイズを 32768 バイトに設定します

コマンドオプションとして纏めるとこのようになります．

-o nfsv3,tcp,rw,fg,hard,intr,rsize=32768,wsize=32768

以上で FreeBSD での NFS の NFSv3 を通常利用する方法について詳しく説明しました．今後は，NFSv4 やその他のオプションについても解説していきたいと考えています．

]]> https://www.seichan.org/2014/01/post-367.html/feed 0 FreeBSD で NFS (NFSクライアントとマウントオプション①) https://www.seichan.org/2014/01/post-358.html https://www.seichan.org/2014/01/post-358.html#respond Fri, 17 Jan 2014 17:42:01 +0000 http://www.seichan.org/blog/?p=358 FreeBSD の NFS について以前 Pukiwiki の「FreeBSD で NFS(Network File System) サーバ & クライアント」に纏めていましたが，当時 5.0 RELEASE の頃に纏めてましたのでだいぶ状況が変わってしまいました．
ですので今のバージョン 9.2-RELEASE をターゲットに改めて解説します．

前回「FreeBSD で NFS – (NFSサーバ設定と /etc/exports 詳解②)」までは NFS サーバー側の説明を書いていましたが，今回からはクライアント側の説明に移ります．

クライアント側設定

NFS クライアント側では，単純にマウントを行う場合は特に意識することもない部分が多いのですが，現代の NFS を利用するにはいくつか覚えておくべき点があります．ここでは，そのポイントを解説していきます．

デーモン

NFSv3 におけるファイルロックを利用するには，NFS クライアント側で特定のデーモンの起動が必要です．それは、「FreeBSD で NFS – (NFSの概要 / NFS とは)」で述べたとおり，rpc.lockd と rpc.statd です．
これらのデーモンは，名前の通り RPC を利用しますので，rpcbind が依存的に必要となります．
これらのデーモンがシステム再起動後も自動的に起動するようにするには，/etc/rc.conf ファイルに次のように記述します．

rpc_lockd_enable="YES"
rpc_statd_enable="YES"
rpcbind_enable="YES"

NFSクライアントデーモンの起動

/etc/rc.conf ファイルに設定を記述した後，再起動せずに NFS クライアントデーモン（実質的にはロックデーモンなど）を起動するには，以下のコマンドを実行します．
これにより，NFS クライアントデーモンが順序通りに起動されます．デーモンの起動順序は rpcbind，rpc.statd，rpc.lockd の順番です．

# /etc/rc.d/rpcbind start
Starting rpcbind.
# /etc/rc.d/statd start
Starting statd.
# /etc/rc.d/lockd start
Starting lockd.

rpc.statd と rpc.lockd が起動したら，NFSロックが利用可能な状態となります．
NFSサーバ側でも rpc.statd と rpc.lockd が動作している必要があります．
また，FreeBSD以外の場合は同等のデーモンが動作している必要があります．

ファイルロックの確認

ファイルロックが有効に働いているかを素早く確認するには，NFSサーバとNFSクライアントで同じファイルを編集するのが良いでしょう．

「/pub/testfile」を編集しようとすると，NFSクライアント側で rpc.statd や rpc.lockd が動作していないこと場合は次のようなメッセージが表示されます．

testfile: unmodified, UNLOCKED

特定のホストからしか編集されない．という事がわかっている状況ではこれでも機能すると思いますが，危ない状況ですので，早急にロックを有効にしてください．その特定のホスト内で同時にファイルを操作する．なんてシチュエーションも考えられますので．

特定のホストからしか編集されないことが分かっている場合でも，ロックを有効にすることが重要です．なぜなら，その特定のホスト内でも同時にファイルを操作する可能性があるからです．

ファイルロックが有効な環境での同時編集が発生した場合は，次のようになります．
この例では，NFS サーバ側で testfile を vi で開いている状態で，NFS クライアント側でも testfile を vi で開いた状況です．

testfile already locked, session is read-only.
testfile: unmodified, readonly: line 1
Press any key to continue:

「testfile already locked」という表示で，既にファイルが開かれており，ロックされていることが示されます．

マウント

FreeBSD で NFS マウントするには，2つの方法があります．mount に -t nfs とファイルシステムタイプを nfs と指定する方法と，mount_nfs コマンドを使用する方法です．
mount -t nfs と指定した場合でも，最終的には mount_nfs が呼び出されますので結果は変わりません．その為，使いやすい方法で使って大丈夫です．

FreeBSD で NFS をマウントするには，2つの方法があります．1つ目は，mount コマンドに -t nfs オプションとファイルシステムタイプを nfs として指定する方法です．
もう1つは，mount_nfs コマンドを使用する方法です．
mount -t nfs を使ってマウントする場合でも，実際には最終的に mount_nfs が呼び出されますので結果は変わりません．そのため，どちらの方法を使っても大丈夫です．

マウントする際の基本的な指定方法は次の通りです．以下に，両方の方法を併記します．

mount -t nfs nfsserver:[nfsshare] [mountpoint]
mount_nfs nfsserver:[nfsshare] [mountpoint]

nfsserver は NFS サーバの名前もしくは IP アドレスです．[nfsshare] は NFS サーバ側で共有設定をしているディレクトリになります．そして [mountpoint] は NFS クライアント側のマウント先ディレクトリとなります．

nfsserver は NFS サーバーの名前またはIPアドレスを指します．[nfsshare] は NFS サーバーで共有設定されたディレクトリを示し，[mountpoint] は NFS クライアントでのマウントポイントを指定します．

ここでは，NFS サーバ stglab1 の /pub を NFS クライアントの /mnt にマウントしてみます．以降は mount -t nfs の形式で記載します．

ここでは、NFS サーバー stglab1 上の /pub を NFS クライアントの /mnt にマウントしてみます．以降は mount -t nfs の形式で記載します．

# mount -t nfs stglab1:/pub /mnt

マウントが成功したら，特になにも出力がなくプロンプトに戻ります．mount コマンドで NFS マウントしていることを確認してみましょう．

マウントが成功した場合，通常は特に出力がなくプロンプトに戻ります．NFS マウントが正常に行われたかどうかを確認するには，mount コマンドを使用します．

# mount
stglab1:/pub on /mnt (nfs)

この状態で NFS マウントが行われており，権限があれば /mnt 以下のファイルを読み書き可能です．

読み取り専用マウント

明らかに読み取り専用でしか利用を想定していない場合は，NFS サーバ側で読み取り専用で共有設定をすべきですが，それが難しい場合もあります．そのようなシチュエーションの場合は NFS クライアント側で明示的に読み取り専用としてマウントする必要があります．

読み取り専用 (read-only) とする場合の方法も2通りあります．-r という専用のオプションか，-o ro とオプションの一覧の中の read-only オプションを選択する方法です．これも好き好きでどちらを利用しても構わないのですが，Seichan としては，色々オプションを書くことを想定して -o の中に纏める方法が好みです．

先に例示したマウントの場合，読み書き可能な状態でマウントしていますが，読み取り専用でマウントしたい場合が多いと思います．

明確に読み取り専用での利用を想定している場合は，NFS サーバ側で読み取り専用で共有を設定すべきですが，それが難しい場合もあります．そのような状況では，NFS クライアント側で明示的に読み取り専用としてマウントする必要があります．

読み取り専用（read-only）とする方法には2つの選択肢があります．1つは，-r という専用のオプションを使用する方法であり，もう1つは -o ro というオプションの一部として read-only オプションを使用する方法です．どちらの方法を選択しても構いませんが、オプションを多く指定することを想定して，-o の中に纏める方法が好ましいと考えています．

以下に，2つの読み取り専用オプションの指定を例示します．

# mount -t nfs -r stglab1:/pub /mnt
# mount -t nfs -o ro stglab1:/pub /mnt

いずれの場合も，mount コマンドで確認すると，このように read-only と表示されます．

# mount
stglab1:/pub on /mnt (nfs, read-only)

NFS バージョンの指定

NFS には v2，v3，v4 のバージョンが存在しますが，mount コマンドは 1 つしかありません．何も指定しない場合，通常は NFSv3 での接続を最初に試み，失敗した場合に NFSv2 に切り替えます．
しかし，NFSv2 には 2GB 以上のファイルを扱えない制限など，現代では適さない点がいくつかあります．
また，他に意図しないバージョンでの接続によるトラブルの発生も考えられます．そのため，明示的にバージョンを指定してマウントすることが重要です．

NFS バージョンの指定は -o オプションに nfsv2，nfsv3，nfsv4 のいずれかを指定します．明示的にバージョンを指定した場合，そのバージョンでの接続ができなかったときはすぐにマウント失敗となります．

次の例は，NFSv3 での接続を行う場合の例となります．

# mount -t nfs -o nfsv3 stglab1:/pub /mnt

TCP または UDP

NFSv2 と NFSv3 は，TCP と UDP の両方を利用することができます．UDP の方がパフォーマンスが高いとされますが，再送処理が発生するとファイル全体を再送する必要があるため，パケットロスがわずかでも発生するとパフォーマンスが急激に低下します．また、マニュアルには「現在では UDP 接続は互換性のために残されている」という記載がありますので，UDP を使用する利点はほとんどありません．

mount_nfs コマンドはデフォルトで TCP を利用しますが，ここも明示的に利用プロトコルを指定すべきです．
Unix 系 OS の種類によってデフォルトの設定が異なる可能性があるため，これらの機種差を考慮しなくても良くなるよう，プロトコルの指定を明確にするべきです．

先の NFS バージョンと合わせて指定する例を書いてみます．

# mount -t nfs -o nfsv3,tcp stglab1:/pub /mnt

この NFS バージョンとプロトコルを指定したマウントを実際の業務では基本としてください．

このように，実際の業務では NFS バージョンとプロトコルを指定したマウントを基本とすべきです．

記事が長くなりましたので引き続きオプションの説明を次回解説します．

]]> https://www.seichan.org/2014/01/post-358.html/feed 0 FreeBSD で NFS – (NFSサーバ設定と /etc/exports 詳解②) https://www.seichan.org/2014/01/post-327.html https://www.seichan.org/2014/01/post-327.html#respond Wed, 08 Jan 2014 16:46:45 +0000 http://www.seichan.org/blog/?p=327 FreeBSD の NFS について以前 Pukiwiki の「FreeBSD で NFS(Network File System) サーバ & クライアント」に纏めていましたが，当時 5.0 RELEASE の頃に纏めてましたのでだいぶ状況が変わってしまいました．
ですので今のバージョン 9.2-RELEASE をターゲットに改めて解説します．

前回「FreeBSD で NFS – (NFSサーバ設定と /etc/exports 詳解①)」で書いたとおり，/etc/exports 詳解の続編です．

/etc/exports 詳解

読み取り専用でマウント

読み取り専用で共有を行いたいシチュエーションはとても多いと思います．例えば，ISOイメージの共有などです．そういう場合は -ro オプションで設定することが可能です．
次の例は /usr は読み取り専用で，/pub は読み書き可能な共有を設定しています．

/usr     -ro -network 192.168.241.0 -mask 255.255.255.0
/pub     -network 192.168.241.0 -mask 255.255.255.0

指定したディレクトリ以下を任意にマウント

「FreeBSD で NFS – (NFSサーバ設定と /etc/exports 詳解①)」で述べた「複数のディレクトリの共有」の場合，1行に複数のディレクトリを纏めて共有する方法を紹介しました．

/usr/src /usr/obj  -network 192.168.241.0 -mask 255.255.255.0

あまり推奨されない方法ですが，指定したディレクトリ以下のすべてのサブディレクトリを任意のマウントポイントとする方法があります．
次のように -alldirs オプションを使用します．

/usr    -alldirs -network 192.168.241.0 -mask 255.255.255.0

この設定では，/usr 以下の任意の場所を指定してマウントが可能になります．指定したディレクトリ以下全てが公開されますので，NFS を提供するネットワークにセキュリティ上の懸念が少ない場合に利用するなどの判断を行ってください．
なお，RedHat Enterprise Linux の NFS では，この動作がデフォルトのようです．

root ユーザアクセスの制御

オプションを指定しない場合，NFSクライアント上の root ユーザー（UID: 0）のアクセスは，UID/GID が -2:-2 という扱いになり，通常は nobody:nobody にマップされます．
そのため，NFS サーバ上の root が所有者のファイルは編集できません．これは，NFS v2/v3 では認証機能が殆どないため，セキュリティを担保するためです．

信頼できるネットワークやホストからの root アクセスを許可する場合は，-maproot オプションを使って明示的に許可する必要があります．
次の例は /pub に対する 192.168.241.0/24 のネットワークからの root アクセスを root ユーザーで処理する設定です．ただし，/usr には -maproot オプションをつけていないため，root アクセスは nobody にマップされたままです．

/usr    -network 192.168.241.0 -mask 255.255.255.0
/pub    -maproot=root -network 192.168.241.0 -mask 255.255.255.0

-maproot オプションには個別のユーザーアカウントを指定することができ，root アクセスの変換先を指定できます．指定方法によって，NFS アクセス時のマッピングが変化しますので注意が必要です．

-maproot=[user]

このようにユーザー名のみを指定した場合，指定されたユーザが所属するプライマリーグループが含まれます．ユーザーが所属するグループのいずれかが読み書きの権限を持つファイルに対してアクセスが可能となります．
なお，ドキュメント上ではユーザが所属する全てのグループが含まれると記載されていますが，9.2-RELEASEではそのような動作はしませんでした．

-maproot=[user]:[group1]:[group2]

このようにユーザー名とグループを指定した場合，ここで明記されたグループのみが含まれます．ユーザーおよび，指定されたグループに対する権限を持つファイルに対してのみアクセスが可能となります．

-maproot=[user]:

このように，ユーザー名のみを指定して最後をコロンで終えた場合，UID の変換は行われますが，GID の変換は行われません．そのため，指定したユーザーの UID に変換されますが，GID は 0 (wheel) のままとなります．
ドキュメントでは，この形式は指定したユーザーに関する完全な権限を区別するために利用されると記載されていますが，実際にはそのような動作とはなりませんでした．

例として，次のような環境での挙動を確認してみます．

# id seichan<br />uid=1000(seichan) gid=1000(seichan) groups=1000(seichan),10000(users)

# ls -l /pub
drwxrwxr-x  2 root     operator  512 Jan  6 10:56 .snap
-rw-r-----  1 root     wheel       0 Jan  6 10:57 file1
-rw-r-----  1 seichan  seichan     0 Jan  6 10:57 file2
-rw-r-----  1 seichan  wheel       0 Jan  6 10:57 file3
-rw-r-----  1 root     seichan     0 Jan  6 10:57 file4
-rw-r-----  1 root     users       0 Jan  6 10:58 file5
パターン1: -maproot が存在しない場合
/pub    -network 192.168.241.0 -mask 255.255.255.0

-maproot オプションが存在しない場合，NFS クライアント上の root ユーザーのアクセスは nobody ユーザーの権限で行われます．そのため，全てのファイルが Permission denied で読み取りに失敗します．

# cat file1
cat: file1: Permission denied
# cat file2
cat: file2: Permission denied
# cat file3
cat: file3: Permission denied
# cat file4
cat: file4: Permission denied
# cat file5
cat: file5: Permission denied
パターン2: -maproot=seichan の場合
/pub    -maproot=seichan -network 192.168.241.0 -mask 255.255.255.0

NFS サーバー上の seichan ユーザーおよび seichan が所属するプライマリーグループがマッピングされますので，ファイルオーナーが seichan のものもしくはグループオーナーが seichan のファイルの読み取りは可能となります．

# cat file1
cat: file1: Permission denied
# cat file2
# cat file3
# cat file4
# cat file5
cat: file5: Permission denied
パターン3: -maproot=seichan: の場合
/pub    -maproot=seichan: -network 192.168.241.0 -mask 255.255.255.0

NFS サーバー上では，ファイルオーナーが seichan である場合や，グループオーナーが wheel であるファイルについて，NFS クライアント側でのファイルアクセスが許可されます．この際、ユーザーは seichan にマップされますが、グループID（GID）は変更されず，そのまま渡されます．

# cat file1
# cat file2
# cat file3
# cat file4
cat: file4: Permission denied
# cat file5
cat: file5: Permission denied
パターン4: -maproot=seichan:seichan:users の場合
/pub    -maproot=seichan:seichan:users -network 192.168.241.0 -mask 255.255.255.0

NFS サーバー上で seichan ユーザーが所有するファイルや，グループが seichan および users であるファイルについて，NFS クライアントからの読み取りが可能となります．

# cat file1
cat: file1: Permission denied
# cat file2
# cat file3
# cat file4
# cat file5

-maproot オプションは，このように指定された値によって挙動が異なるため，個別のユーザアカウントにマップさせたい場合などには，事前に挙動を確認してからサービスをリリースするように心がけましょう．

全てのユーザアクセスの制御

先のオプションは -maproot と，root アクセス時の制御を行いましたが，NFS クライアント側のユーザアカウント及び UID にとらわれず，全てのアクセスを特定の ID にマップさせることも可能です．-mapall オプションがその機能を実現します．
-mapall オプションは -maproot オプションと同じ形式の指定が可能で，動作も同様の動作となります．

先のオプションである -maproot は、root アクセス時の制御を行いましたが，NFS クライアント側のユーザーアカウントや UID にとらわれず，全てのアクセスを特定の ID にマップさせることも可能です．
この機能を実現するのが -mapall オプションです．-mapall オプションは -maproot と同様の形式で指定が可能であり，動作も同様です．

以上，駆け足ではありましたが，/etc/exportsに関する詳細な解説でした．これは NFSv2/NFSv3 の基本的な設定に関する内容であり，今後はセキュリティやNFSv4などについても改めてまとめてみたいと考えています．

]]> https://www.seichan.org/2014/01/post-327.html/feed 0 FreeBSD で NFS – (NFSサーバ設定と /etc/exports 詳解①) https://www.seichan.org/2014/01/post-320.html https://www.seichan.org/2014/01/post-320.html#respond Wed, 01 Jan 2014 17:33:19 +0000 http://www.seichan.org/blog/?p=320 FreeBSD の NFS について以前 Pukiwiki の「FreeBSD で NFS(Network File System) サーバ & クライアント」に纏めていましたが，当時 5.0 RELEASE の頃に纏めてましたのでだいぶ状況が変わってしまいました．
ですので今のバージョン 9.2-RELEASE をターゲットに改めて解説します．

今回は NFS サーバーまわりの設定について解説します．

NFS サーバ側設定

NFS サーバ側では，NFSサービスを提供するデーモンや共有領域の設定を行います．

デーモン

NFS サーバ側で必要なデーモンは「FreeBSD で NFS – (NFSの概要 / NFS とは)」で説明した nfsd，mountd，rpcbind，rpc.lockd，rpc.statd です．
これらがシステム再起動後も自動的に起動するように，次のように /etc/rc.conf に記述します．

nfs_server_enable="YES"
mountd_enable="YES"
rpc_lockd_enable="YES"
rpc_statd_enable="YES"
rpcbind_enable="YES"

一度 NFS サービスを起動できるか確認するために，mountd が要求するファイルである「/etc/exports」を touch コマンドで空ファイルとして作成しておきます．

# touch /etc/exports

NFS サーバデーモンの起動

/etc/rc.conf ファイル記載後，サーバを再起動せずに NFS サービスを起動するにはコマンドを実行します．
デーモン起動の順番は rpcbind，mountd，nfsd，rpc.lockd，rpc.statd の順番となります．
これは /etc/rc.d 以下の各制御スクリプトの REQUIRE 行を見ればわかります．それぞれのファイルを見て理解するのが一番良いと思いますが，FreeBSD 8.0 より service コマンドが利用可能で，このコマンドを使って実行順序を確認する事ができます．

service コマンドで実行順序の確認を行うと次のようにスクリプトのパスが表示されます．

# service -e
/etc/rc.d/hostid
/etc/rc.d/hostid_save
/etc/rc.d/cleanvar
/etc/rc.d/ip6addrctl
/etc/rc.d/devd
/etc/rc.d/newsyslog
/etc/rc.d/syslogd
/etc/rc.d/rpcbind
/etc/rc.d/virecover
/etc/rc.d/dmesg
/etc/rc.d/mountd
/etc/rc.d/nfsd
/etc/rc.d/statd
/etc/rc.d/lockd
/etc/rc.d/motd
/etc/rc.d/sshd
/etc/rc.d/sendmail
/etc/rc.d/cron
/etc/rc.d/mixer
/etc/rc.d/gptboot
/etc/rc.d/bgfsck

デーモンの起動順序が確認できたところで実際に実行してみます．

# /etc/rc.d/rpcbind start
Starting rpcbind.
# /etc/rc.d/mountd start
Starting mountd.
# /etc/rc.d/nfsd start
NFSv4 is disabled
Starting nfsd.
# /etc/rc.d/statd start
Starting statd.
# /etc/rc.d/lockd start
Starting lockd.

デーモンが起動したら，NFS サーバーの起動は完了です．ただし，まだ共有を提供していないため，共有するディレクトリとNFSクライアントを設定する必要があります．

NFS サーバの共有設定

NFS サーバーのほとんどの設定は共有設定に関係します．書式とルールを理解しないと，不必要なネットワークに共有される可能性があるため，セキュリティ上のリスクがあります．注意して設定しましょう．

基本の共有

一旦共有を設定し，クライアントがマウントできるかどうかを確認しましょう．任意のディレクトリを共有できますが，この例では /usr を共有します．これは、FreeBSDで各種サーバを構築する際に、/usr/src や /usr/obj、/usr/ports をNFSで共有することで環境の統一が容易になるためです．
もちろん，共有したい領域があれば適宜読み替えてください．

/etc/exports ファイルに次のような行を追加します．ネットワークとサブネットマスクは環境に合わせて適切に読み替えてください．

/usr    -network 192.168.241.0 -mask 255.255.255.0

/etc/exports を作成した後，mountd を再読み込みすることで /etc/exports の内容を適用させます．これにより，mountd が正しく動作します．正常に読み直されているかは showmount コマンドで確認できます．
showmount コマンドで正常に表示されない場合，記述ミスが考えられますので /var/log/messages を確認してください．

# /etc/rc.d/mountd reload

# showmount -e
Exports list on localhost:
/usr                               192.168.241.0

NFS クライアントからマウント

NFS クライアントから共有をマウントしてみましょう．NFS サーバの /usr をそのまま NFS クライアントの /usr にマウントすることはできないので，代わりに /mnt にマウントします．mount コマンドを実行し，エラーが出ていなければマウントは成功しています．
その後，mount コマンドや df コマンドを使用して確認してみましょう．

# mount -t nfs nfsserver:/usr /mnt
# mount
/dev/da0p2 on / (ufs, local, journaled soft-updates)
devfs on /dev (devfs, local, multilabel)
nfsserver:/usr on /mnt (nfs)

ここまでの基本動作確認が出来たら umount で一度マウントを解除してください．

# umount /mnt

/etc/exports 詳解

NFS サーバーの設定は重要です．この段階でのミスはトラブルのもとです．
以下では，シチュエーションごとに具体的な設定方法を説明します．

複数のネットワークに対する共有

複数のネットワークに対して共有を行う場合は，次のようにします．それぞれの宛先に対して行を分けることがポイントです．
例えば，192.168.241/24 と 10.192.168/24 の両方に対して /usr を公開する場合はこのようになります．

/usr    -network 192.168.241.0 -mask 255.255.255.0
/usr    -network 10.192.168.0 -mask 255.255.255.0

CIDR 形式で記載することも可能です．ただし，混在させると混乱の原因になりますので，統一した形式で記述することをお勧めします．

/usr    -network 192.168.241.0 -mask 255.255.255.0
/usr    -network 10.192.168/24

特定のホストに対する共有

ネットワーク単位ではなく，特定のホストに対してのみ共有したい場合は次のように記述します．
上の行は特定のIPアドレスに対して，下の行は特定のホスト名に対しての共有です．

/usr    192.168.241.100
/usr    client1.seichan.org

ホスト名での指定は，最終的には逆引きされた IP アドレスになりますのでこの点は注意してください．
DNS もしくは /etc/hosts に正しくエントリーがある場合にのみ作用します．名前とIPアドレスの解決ができない状態で「mountd reload」を行うと，/var/log/messages には次のようにエラーが表示されます．

mountd[1934]: bad exports list line /usr  client1.seichan.org

複数のディレクトリの共有

複数のディレクトリーを共有する場合は次のようになります．共有するディレクトリーと，共有したい相手のリストを必要分記載します．
この場合，192.168.241.0/24 にいる NFS クライアントは /usr と /pub を，10.192.168.0/24 にいるクライアントは /usr のみマウントできます．

/usr    -network 192.168.241.0 -mask 255.255.255.0
/usr    -network 10.192.168.0 -mask 255.255.255.0
/pub    -network 192.168.241.0 -mask 255.255.255.0

ファイルシステム内の細かい共有

複数のディレクトリの共有を行う際にハマりやすいポイントとして，ファイルシステムが同じ場所のディレクトリの共有を設定する際には，ディレクトリを一行にまとめて記述する必要があります．
たとえば，先ほどの例では /usr という大きなディレクトリを共有していますが，/usr/src，/usr/obj，/usr/ports のみを共有したいとします．そのような場合次のような記述ではエラーが発生します．

/usr/src  -network 192.168.241.0 -mask 255.255.255.0
/usr/obj  -network 192.168.241.0 -mask 255.255.255.0

次のように「bad exports list」というエラーが記録され，showmount の結果では先に記載した設定のみが反映されています．

# tail /var/log/messages
mountd[1934]: can't change attributes for /usr/obj: Invalid radix node head, rn: 0 0xfffffe0002ec4800
mountd[1934]: bad exports list line /usr/obj    -ro -network 192.168.241.0 -mask 255.255.255.0

# showmount -e
Exports list on localhost:
/usr/src                           192.168.241.0

これを正しい状態にするには，次のように一行に記載します．

/usr/src /usr/obj  -network 192.168.241.0 -mask 255.255.255.0

長くなってしまいましたので，exports 詳解は次回に引き続きます．

]]> https://www.seichan.org/2014/01/post-320.html/feed 0 FreeBSD で NFS – (NFSの概要 / NFS とは) https://www.seichan.org/2013/12/post-307.html https://www.seichan.org/2013/12/post-307.html#comments Tue, 31 Dec 2013 14:19:40 +0000 http://www.seichan.org/blog/?p=307 今回は 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 ですね．
vSphere も現在は NFSv3 と NFSv4 の両方を利用できるようになっています．

NFS には v2，v3，v4 の 3つのバージョンがあります．v1 は Sun Microsystems 内部でのみ存在したと言われています．
現在一般的には，多くの場所で NFSv3が 利用されています．NFSv2 はほとんど使われていません．

NFSv4 の利用は増えていますが，NFSv3 に固定された製品があるため，完全に移行するにはまだ一歩が残っています．以前の ESX/ESXi などの製品が NFSv3 に固定されていましたが，現在では NFSv3 と NFSv4 の両方を利用できます．

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

 NFSv2NFSv3NFSv4
トランスポートUDPUDP/TCPTCP
 ファイルサイズ制限2GBなしなし
ファイルロックあり(別プロトコル)あり(別プロトコル)あり
 非同期書き込みなしありあり
 ステート保持あり(別プロトコル)あり(別プロトコル)あり

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

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

rpcbind

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

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

mountd

mountd はマウント処理を担当するデーモンです．NFS アクセスにはファイルハンドルが必要で，これは inode のようなものです．NFS クライアントは，このファイルハンドルの番号を知るために mountd がNFS共有しているディレクトリ（マウントポイント）のファイルハンドルを通知します．
その後，NFSクライアントは基点のファイルハンドルを知り，直接 nfsd と通信します．
このため，mountd は NFS アクセスの最初の段階でのみ介入します．NFS マウント済みのクライアントを許可ネットワークから外した場合でも，NFS クライアントは通信を継続します．対処方法は NFS セッションを切断することのみですので注意してください．

nfsd

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

rpc.lockd

rpc.lockd は NFSプロトコル上でファイルロックを実現するためのデーモンです．NFS Lock Manager（NLM）という別のプロトコルが開発され，rpc.lockd がそのプロトコルを担当します．
このデーモンが動作していないとファイルロックが利用できず，さまざまな不都合が生じます．
このデーモンはサーバーとクライアントの両方で動いている必要があります．5.0-RELEASE あたりから利用可能になり，8.x 頃にカーネルに統合されました．

rpc.statd

rpc.statd は NFS Lock Manager のステータスを管理する NFS Status Monitor プロトコルのデーモンです．NFS Lock Manager は状態を保持せず，NFS サーバーが再起動するとロック情報が失われます．これを防ぐために rpc.statd はロック情報をローカルに保持し，サーバーの復旧後にロック状態を引き継ぎます．

FreeBSD の NFS 実装

FreeBSD 8.0 で NFS 実装に大きな変更がありました．新しい実装は NFSv4 に対応し，古い実装と並行して提供されます．
デフォルトでは古い実装が動作しますが，9.0 では逆に新しい実装が優先されます．
9.2-RELEASE 以降は特に理由がない限り新しい実装を利用することが推奨されます．
私の環境では以前は新しい実装が不安定でしたが，現在は問題なく利用しています．

NFSv3 までの落とし穴

NFS を使う際によく問題になる箇所は FreeBSD に限らずいくつかあります．

UID と GID の不一致

NFSv3 まででは、サーバー上の UID/GID とクライアントの UID/GID が一致していることが前提です．管理できないクライアントを NFS サーバに接続すると，意図しないファイルアクセスが発生する可能性があります．
例えば，サーバ側の「UID 100: seichan」と、クライアント側の「UID 100: foo」がある場合，クライアントの「foo」が NFS アクセスすると，サーバ上の「seichan」のファイルの所有者として認識されます．
root アクセスを許可している場合はさらに危険です．管理できない端末の接続を最初から拒否する運用が必要です．

ポート番号が不定

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

RPC を使用するため，ポート番号は一定ではありません．そのため，ファイアーウォールで拒否されて NFS アクセスができないトラブルがよく発生します．
使用するポート番号固定化，ファイアーウォールのフィルタールールを設定することで問題を回避しができます．
異なる機種間では固定化できるかどうか事前に確認することをお勧めします．

以上が NFS の概要についての説明です．次回は NFS サーバーの設定について解説します．

]]> https://www.seichan.org/2013/12/post-307.html/feed 1