ＮＦＳｖ４サーバーの作り方
検証環境
- CentOS/x86_64 6.8（2016年06月10日版）をＮＦＳｖ４【クライアント】とする。
- FreeBSD をクライアントにするケースは今回は無しで。
- 使用するプロトコルはＮＦＳｖ４に絞る（重要なので２回ｒｙ）。
ＮＦＳｖ４サーバーについては先に行った設定を前提とする。
- バージョンの選択についてだが、過去との互換性？今時 v2 はおろか、v3 でもないでしょ、ということで、v4 ないしは v4.1（pNFS はまだ使えない orz）一択で。
ＮＦＳセキュリティメモ
ＮＦＳについてググって見ると使用状況に応じて色々と苦労している点が見られる。 Kerberos 必須という人も居れば不要という人も居るわけで、ここでは以下のアンセキュアな環境を前提とする。
専用ＮＩＣ（ＶＬＡＮ）割り当て
ＮＦＳ共有用に専用ＮＩＣ（ＶＬＡＮ）を割り当てる。そのＮＩＣにはＮＦＳ以外のサービスは提供しない。
- ＧｂＥはいいぞ。単体～数台なら十分以上の性能を発揮する。
- これは「同時」数台が帯域を使い込むような状態を想定しているので、数台がネットワークに存在するだけで飽和することを意味しない:-)。
- 可能なら１０ＧｂＥだろうけど高いし。
- 検証環境では同一ホスト内にＮＦＳサーバーとＮＦＳクライアントを共存させてみたが、単純に / 以下を対象に tar(1) で固めただけで、１．６Ｇｂｐｓ の性能が出た。
- つまり単体で最大性能発揮しようと思ったらＧｂＥは足りないかもしれないけど、１０ＧｂＥ埋めるのは結構大変。
- ましてや「複数台が同時に」という確率と合わせると数台程度ならＧｂＥでも余裕。
- まぁアレだ。キャパシティプランニングで、動画再生のような常時帯域を使いまくるような前提は勘弁な。
パケットフィルタリング無しで
ipfw/pf/iptables/tcpwrapper といったパケットフィルタリングを行わない。
- ＮＦＳｖ４に絞ってるので制限しやすくなってるが、専用ネットワークならそれほどの必要性を感じない。
- 不特定多数の人が使うような用途で、ＮＦＳクライアントの偽装やら root 権限奪取やら、あるいはそれに準じるようなアクセスがあることを想定しているなら、Kerberos 認証とか IEEE 802.1X（認証ＶＬＡＮ）とか IEEE 802.1AE（MACsec）とか導入した方がいいと思うの（言ってることの現実性はテキトー）。
認証や暗号化・アクセス制御は無しで
認証？何それ。ＵＮＩＸアカウント一択（デフォルトの -sec=sys）で。
- ＮＦＳクライアントとＮＦＳサーバーでのファイル所有者の取り扱いは可能な限りシームレスで、つまり、root は root として扱う（違うと色々面倒なんだよ）。
- Kerberos は Kerberos で大変なんだよ。 orz
- 通信の暗号化？ちょっ（ｒｙ。
- Kerberos 有効にしないとアカンって。
- IPsec？パケットは暗号化されるけど、ＮＦＳクライアントで tcpdump(8) したらバレるよねぇ。
- あぁ。ＶＰＮ越しなら IPsec もアリか。
- SELinux の類い。
- 自分アレ、コントロール（ステップアップ）できないので、disabled の扱いで。
結論
とりあえず少しずつステップアップすることがぢゅーよー、ということで、この手順を参考に難しいことに挑戦してみてください。
インストール
インストール
yum -y install nfs-utils
ＮＦＳクライアント・サーバーともに、nfs-utils のインストールで全てまかなえてることになっている。たぶん。
ディレクトリ作成
mkdir -p 0755 /export
自動起動設定
chkconfig rpcbind off chkconfig netfs on chkconfig rpcgssd off chkconfig rpcidmapd on chkconfig nfs off chkconfig nfslock off
セットアップ
ＭＴＵ値の設定
今時のファイル共有ならＧｂＥや１０ＧｂＥ当たり前なので、ＭＴＵ値を設定する。 ＭＴＵ値はネットワーク依存で、通信に絡んでいる一番小さな値を指定することになる。 必ずしも９０００（バイト）とは限らないので、ちゃんと調べよう（＆設定しよう）。
なお手動で設定できるが、設定した瞬間にＭＴＵ値が反映される（インターフェース的な問題よりもＴＣＰ的に）かわからなかった。 即座に反映されたようにも見えるし、umount→mount したら使ってたような気がしないでもなし。 たぶん、リンクダウン・アップした方がいいとは思うけど。
ip link set ethｎ mtu 9000 ip link set ethｎ down ip link set ethｎ up
また、CentOS（RHEL）では、ＩＰアドレス設定が、静的か動的かで、設定ファイルが分かれる。
/etc/sysconfig/network-scripts/ifcfg-ethｎ（静的設定環境用）
DEVICE=ethｎ TYPE=Ethernet BOOTPROTO=static HWADDR=00:0c:29:xx:xx:xx IPADDR=XXX.XXX.XXX.XXX PREFIX=XX NM_CONTROLLED=no MTU=9000 ONBOOT=yes
/etc/dhclient-ethｎ.conf（動的設定環境用）
default interface-mtu 9000; supersede interface-mtu 9000;
ググるとごちゃごちゃ設定（しかもグローバルに）してるケースがあるが、本質的には上記２行だけでｏｋ。 環境によってはどちらか１行でもｏｋ。 もしかしたら良きに計らってくれてるかもしれないくらい（ＤＨＣＰサーバーがＭＴＵ値を広告してくれる）。
たまたま /etc/sysconfig/network-scripts/network-functions のコード読んでたから知ってたけど、意外と知られてないのかな。
/etc/fstab
ＮＦＳクライアントサーバーＩＰ:/ＮＦＳｖ４ライアント名 /export nfs4 defaults,soft,intr,noexec,nosuid 0 0
上記設定を/ etc/fstab に追加する。
/etc/sysconfig/nfs
1 --- /etc/sysconfig/nfs.orig 2016-05-11 15:22:22.000000000 +0900
2 +++ /etc/sysconfig/nfs 2016-06-06 19:32:42.649929205 +0900
3 @@ -69,7 +69,7 @@
4 #
5 #
6 # Optional arguments passed to rpc.idmapd. See rpc.idmapd(8)
7 -#RPCIDMAPDARGS=""
8 +RPCIDMAPDARGS="-C"
9 #
10 # Set to turn on Secure NFS mounts.
11 #SECURE_NFS="yes"
/etc/idmapd.conf
1 --- /etc/idmapd.conf.orig 2015-07-24 17:27:51.000000000 +0900
2 +++ /etc/idmapd.conf 2016-06-06 14:34:41.302648213 +0900
3 @@ -3,6 +3,7 @@
4 # The following should be set to the local NFSv4 domain name
5 # The default is the host's DNS domain name.
6 #Domain = local.domain.edu
7 +Domain = アカウント識別用ドメイン
8
9 # The following is a comma-separated list of Kerberos realm
10 # names that should be considered to be equivalent to the
アカウント作成
postgres
groupadd -g 5432 postgres useradd -u 5432 -g postgres postgres
CentOS では postgres アカウントのＵＩＤ：ＧＩＤは本来 26:26 である。後述する rpc.idmapd のバグのため、ＮＦＳサーバーのＵＩＤ：ＧＩＤと一致させる。
またこの作業は PostgreSQL サーバーをインストールする前に実施するが、すでにインストールされた状態であれば、ＵＩＤ：ＧＩＤを変更の上、ディレクトリやファイルの所有者を探し出して変更すること。
groupmod -g 5432 postgres usermod -u 5432 -g postgres postgres find / -uid 26 -print0 | xargs -0 chown -h postgres find / -gid 26 -print0 | xargs -0 chgrp -h postgres
CentOS 6.x での相互運用問題
CentOS 6.8（おそらく CentOS 5.11 も） との相互運用では以下の点に注意する必要がある。
- ＮＦＳサーバー・クライアント間でＵＩＤ／ＧＩＤを合致させないといけないバグがある（ＮＦＳｖ４の仕様上、バグ認定）。
- というのもＮＦＳクライアント（CentOS 6.8）で postgres(26):postgres(26) のプロセスがアクセス（cd など）した時の、ＮＦＳサーバーへのユーザー問い合わせ結果を tcpdump(8)した結果、「postgres」ではなく「26」という文字列をＮＦＳサーバーに問い合わせ（fattr_owner）ている現象を確認した。
- なお、chown(8) や ls(1) した時には問題無い。
- 本現象について調査したところ、下記のバグがレポートされていることを確認した。
- バグレポートでは以下の点から、CentOS 6 系（少なくとも 6.8、2016年06月09日現在）以下には反映されていないものと考える。
バグレポートで言及されているディストリビューションが FedoraCore 17 である。
CentOS 6(RHEL6) は FedoraCore 12/13 ベースである。
更に CentOS 6 の nfs-utils のバージョンは 1.2.3 であるが、FedoraCore 17 では 1.2.6 である。
FedoraCore 17 ベースの CentOS 7 では問題無いと思われる（未検証）。