学步园

NFS（Network File System）是由升阳（Sun）最先开发，它的目标是让不同机器能够跨平台共享相同的档案资源。简单来说，可以看成是一种远端的档案系统。也因为跨平台的目标，所以几乎所有的Unix Like平台都支援NFS，如IBM AIX、Sun Solaris、HP Unix、GNU/Linux和FreeBSD等，都可以透过NFS来共享档案和目录资源。目前在MS Windows上虽然有NFS Client可以安装，但几乎是商业软件。

所以大家常在Unix Like系统中使用NFS来共享档案资源。或许读者会奇怪，为何不用Samba网芳分享，这样MS Windows和Unix都可以互相连线？这是因为NFS效能比Samba好很多，所以常常在平行运算的超级电脑或者商业大型系统上，使用一台NFS Server，其他Server透过光纤通道连线到NFS档案服务器取得资料。

图17-1

如图17-1，实务上常常架一台NFS Server，并且上面装有磁带机可以定时的备份档案。其他的服务器就把NFS Server share出来的目录挂载起来，实际上所有网页和资料等档案都是放在NFS Server上，这些Server就只单纯运算与回应客户端请求。这样的好处是我们只要维护好一份档案系统即可，并且备份和资源分配也会比较容易。也因为NFS
Server通常使用Raid磁盘阵列系统，所以整个架构可以达成高效能且高可靠性的服务。

NFS运作理论

NFS有好几个版本，最新版是NFSv4。而NFSv1到NFSv4都是透过RPC来运作，所谓的RPC (Remote Procedure Call) 是远端程序呼叫。当跑一个程式时，该程式呼叫另外一个程式去做事情然后把结果传回来称为Procedure Call，所以当一个程式呼叫在不同主机的程式去处理事情并传回结果，我们就称为Remote Procedure Call。对于呼叫别人的程式来说，它会感觉到被呼叫的程式也是在本地执行的。所以RPC有个好处就是在写程式的时候，只要管好呼叫的部份，我们不必实际去处理网络封包等细节，这些细节就给RPC系统处理即可，这样程式也会好写很多。故RPC程式要处理远端传输的问题，只要写好procedure
call来呼叫远端主机的程序读取或写入硬盘即可，这大大简化coding的难度。

NFS的实作就是靠RPC了，所以NFS是不处理网络封包的问题，它只从Client呼叫Server上的NFS procedure，并且告诉该remote procedure想要干嘛，而封包实际的传输就透过标准的RPC协定来达成。故在NFS系统上，Client端和Server端都要安装RPC系统，而RPC在Linux核心里已经有内建。
察看系统上的RPC程序：

# 後面可以不加網址，查詢本機RPC程序
username@ubuntu:~ $ rpcinfo -p 192.1680.183  
   程式採用的協定連接阜
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100003    2   udp   2049  nfs
    100003    4   tcp   2049  nfs
    100005    1   tcp    806  mountd
    100005    2   udp    803  mountd
    100024    1   udp    887  status
    100024    1   tcp    890  status 
???(略)???

现在我们来谈谈Portmap Daemon这个服务！通常当一个RPC程序启动时，若要使用网络传递资料，需要先有个port吧！所以portmap就是把RPC程序启动后，所使用的port纪录起来。因此当Client端要连到RPC程序前，会先连到portmap所使用的port 111，向它查询该RPC程序所使用的port。

这时候就产生一个议题了，每次RPC程式向portmap注册的port可能都不一样，这样造成我们很难写防火墙规则去挡其他不开放的port，这也是为什么使用RPC时常会让系统安全性不佳的原因。由于这种安全性议题NFS和NIS等使用portmap的RPC服务通常限制在局域网路内使用，甚至把所有使用RPC的机器都放到虚拟IP网段内，再透过NAT来对应外部实体IP的port到内部虚拟IP想开放的port。

这个问题目前在NFSv4已经解决了，也就是不必再透过portmap来对应port和RPC程序，因为它改成使用固定的port 2049给Client连接，此时防火墙规则就很好写，不需要考虑到NFSv3 Server使用的port是不固定。

NFSv4提供的新功能包含了完整的Unicode支援，如同Samba的CIFS协定，会在档案传输的时候采用Unicode（UTF-8）来传输档名。旧版的NFSv3在传输档名时，是用本地端的locale来传输档名，也就是传输档名原始资料。但这会有一个问题，如果当A机器使用Big5 Locale，B机器使用UTF-8 Locale，那么我们就无法透过NFSv3来正确传输中文档名，因为NFSv3只能传输原始locale所用的编码，不提供转码阿！所以在从前两台Unix主机必须要使用相同的locale才能正确的传输中文档名。

但是在NFSv4的话，理论上情形就改观了！当一台机器Locale是Big5，另外一台是UTF-8，在传输档名时，都会先转成Unicode（UTF-8）传输，到本地后再转成该机器所使用的Locale编码。因此可以解决不同locale之间中文乱码的问题。不过转码的部份，因为笔者所有的机器都使用UTF-8，笔者没有机会去试，若读者有尝试成功的话，希望可以和笔者分享一下 ^_^。

NFSv4还有其他的优点，例如增加了传输加密的功能（Kerberos 5），因此也更适合直接在Internet上跨不同网域架设NFS Server和Client，不必担心窃听的安全问题。不过这在本书中没有讨论到，有兴趣的读者可以上网找资料或和笔者讨论。

在NFSv4对其他Unix主机的支援性方面，IBM AIX、Sun Sloaris和HP Unix都已经很稳定的支援，因此NFSv4和其他Unix主机沟通目前都已经没有问题。但是目前在Linux核心上NFSv4仍然被标示为EXPERIMENTAL，也就是还在实验阶段。笔者自己使用的情况是在Ubuntu dapper 2.6.15核心没有问题，但是在自己编的官方2.6.17核心client端会不稳定，再更新到2.6.18就没有问题了，可见真的有一点实验性质。

因为它有加密的功能和容易设定防火墙的特性，在笔者管的Server是同时使用NFSv3和NFSv4。NFSv3拿来区网内使用，NFSv4拿来穿越防火墙给校外的Server加密连线。所以要使用NFSv4或NFSv3读者要自己考量和测试！

NFS Server主机规划

设定其实是不难，难的是资源分享的规划和权限设计。这个万一没弄好，别人有可能可以随便对你的NFS Server存取资料。所以在设定前，先想想看要怎样规划档案分享吧！读者首先要想的是NFS Server可以提供给哪些Client机器使用？基本上它不提供帐号认证的方式，所以它使用IP范围来控管Client端。再来你要考虑分享出去的目录权限问题，权限分配有以下几种方式。

1. no_root_squash：这种权限设定就有点危险了！它的意思是若Client端帐号在Server上也有的话，那么在Client端操作该分享目录时，会有该帐号在Server上的权限。危险的地方是在当Client端是root时，那么可以同时取得Server上在分享出来的目录下完整权限。若是Server端没有该帐号，但是Client端有该帐号时，就会变成用nobody来操作该分享目录唷！我们通常使用root_squash会比较安全，且经常会配合NIS一起使用。
2. root_squash：这个基本上和no_root_squash一样。不同的是当Client端用root去操作时，就会变成匿名的nobody权限，所以就安全多了，Client端也无法去做大规模的破坏。通常会配合NIS一起使用。
3. all_squash：这代表了不管Client端用什么帐号，在该分享目录的权限都只有nobody。在开放给所有人使用的匿名NFS Server通常会用这样的设定。
4. anonuid/anongid：当Client mount起来后，不管用什么帐号，在该目录的权限只有anonuid指定的帐号与anongid指定的群组。当你把anonuid和anongid都设成nobody的id时，其实和all_squash有一样的意义！

考虑好权限问题后，读者还要考虑该目录是只能读 (ro)，或者可以读写 (rw)。当要开放给大家只能抓东西，这时候都会配合ro的设定。若是配合NIS让每一部机器的帐号和权限都一样的话，那可以把家目录都放在NFS Server上，并使用rw的设定，这时候不同机器可以负责不同的运算功能，例如网页和Mail Server等，但都是存放在同一个档案系统上。

接下来要考虑可以挂载该分享目录的IP范围，这有两种表示法，一种是直接写上它的IP，笔者不建议用网址（xxx.mook.org）的方式，除非你是写死在hosts里面，不然有可能会因为DNS Server被hack导致你的NFS Server也被攻陷！另外一种方式是用网域的表示方式。例如你想要整个192.168.1.xxx的C Class网域都可以连线到该台NFS Server，那你可以写成192.168.1.0/24。后面的24是netmask 255.255.255.0的简写，换算方式是把该netmask转成二进制后，从前面数过来看有几个1。如每一个255都由8个1bit组成，所以总共3个255就是24了！计算结果是整个C
Class简写为24，B Class简写为16，以此类推。通常要分享到整个网域时，常会把主机全部放在防火墙里面，这样NFS系统会比较安全，不然会直接指定可以存取的Client IP。

由于NFSv3和NFSv4 Server都是使用exports这个资源分享设定档，而NFSv4多了虚拟根目录的概念，所以若要两个同时使用的话，要把所有分享的目录bind到同一个子目录下，故这时候exports的写法要稍微注意一下，需符合NFSv4的规则，并且bind的规则也要记得写到fstab里面，这些会在接下来的17.3节中详细介绍。

NFS Server和Client程式安装

安装NFS Server只要输入以下指令即可。

安装NFS Server：

sudo apt-get install nfs-kernel-server 

安装好server后，它会把portmap，nfs-kernel-server和nfs-common依序加到runlevel里面，若要重新启动NFS服务的话，也要依照这个顺序来唷！

若只需要client端的功能，那如以下指令安装。
安装NFS Client：

sudo apt-get install nfs-common 

若要开机的时候默认不要自动启用NFS，请参考‘深入了解Ubuntu系统’那一章，那里对于runlevel的管理有仔细的介绍。

因为NFSv3和NFSv4的设定有一点不一样，所以详细设定的地方笔者就分开来讲。读者要使用NFSv4或者NFSv3就需要依照你的网络环境来评估。

NFSv3 Server的设定（主流稳定版）

设定NFSv3 Server最重要的就是 /etc/exports这个设定档，我们先弄个简单的范例来看看吧！

Server设定档 /etc/exports范例：

/home  192.168.0.0/24(rw,async,root_squash,no_subtree_check,insecure)
/tmp   192.168.0.0/24(rw,async,root_squash,no_subtree_check,insecure)
/opt   192.168.0.183(ro,root_squash,no_subtree_check,insecure)

如以上范例，exports的格式是第一栏为要分享的目录，第二栏是开放使用的Client主机，最后（rw,async,.....）里面写一些参数。在表17-3-1-1有NFS Server上使用的额外参数详细说明，此范例中的参数是笔者最常用的。在这个例子中，Server分享出3个目录，前两个让192.168.0.0网段所有的电脑都可连进来，且都有读写的权限。最后一个只能由192.168.0.183那台机器连进来，并只能读取。

当设定好后，让它生效不需要重开服务，只要用以下指令即可！

重设Server分享目录：

username@ubuntu:~ $ sudo exportfs -rv    # 重設分享目錄清單
exporting 192.168.0.0/24:/home
exporting 192.168.0.0/24:/tmp
exporting 192.168.0.183:/opt
username@ubuntu:~ $ exportfs      # 察看目前分享目錄，可加 -v獲得更詳細資訊
/home           192.168.0.0/24
/tmp            192.168.0.0/24
/opt            192.168.0.183

Client挂载 /home范例：

# mount -t -o <掛載參數> nfs <Server IP>:<分享目錄> <mount point>
 sudo mount -t nfs 192.168.0.180:/home /NFS/home 
# 讀者也可以依照以下範例使用soft mode且改變讀取區塊大小為8192。
 sudo mount -t nfs -o soft,rsize=8192 192.168.0.180:/home /NFS/home

如Client挂载范例，我们只需要用以上指令就可以挂载上Server的远端目录到本机的mount point上，读者可以自己用同样的方式来挂载tmp和opt。挂载时，也可以加上一些挂载参数，参数可以参考表17-3-1-2，这些参数会在fstab那里给出笔者最长用的设定，读者可以参考看看。

若要看远端有开放哪些资源可以提供挂载，可以使用以下方式。

察看远端可分享的目录资源：

username@ubuntu:~ $ showmount -e 192.168.0.183  # 可用 -a來得知有多少Client連上
Export list for 192.168.0.183:
/export      192.168.0.0/24
/export/home 192.168.0.0/24
/export/tmp  192.168.0.0/24

NFSv4 Server的设定（实验性质）

虽然NFSv4有很多新的功能，但是在kernel中还是被标记为实验用，所以你有可能会遇到一些莫名其妙的bug，例如笔者更新核心到2.6.17后，发现NFSv4 Client会莫名的当掉，最后再更新到2.6.18rc4就正常了！而kernel里面关于NFSv4的程式码又会比原始研发单位还要慢一点，若你想要用最新的NFSv4程式码，可以到http://www.citi.umich.edu/projects/nfsv4/linux/ 抓最新的patch。若读者希望一切都没问题，不想再做一些hack，可以考虑用稳定的NFSv3。但若要在Internet传输，那么NFSv4的容易设定防火墙与加密的特性可以考虑一下！

由于NFSv4使用rpc.idmapd这个daemon来处理User ID、Group ID和权限的对应，所以这个daemon在Client端和Server端都要启动，并且需要自己手动建立通讯pipe给svc gssd subsystem用，这些在Ubuntu都需要手动设定。记得这些设定一定要在Server和Client分别做过一次唷，设定好了就不需要再做了！

建立pipe目录给NFSv4使用：

sudo mkdir /var/lib/nfs/rpc_pipefs

加入以下两行到 /etc/fstab让rpc_pipefs和nfsd fs在开机自动mount起来：

rpc_pipefs /var/lib/nfs/rpc_pipefs rpc_pipefs defaults 0 0
nfsd /proc/fs/nfsd nfsd defaults 0 0

由于我们不重新开机，为了让刚刚加入的两行生效，执行以下指令吧！：

sudo mount rpc_pipefs
sudo mount nfsd

编辑 /etc/default/nfs-common，把NEED_IDMAPD改成yes：

NEED_IDMAPD=yes

接下来重新启动portmap，nfs-kernel-server和nfs-common，要依照笔者下面列出来的顺序操作喔！
对于Server需要重新启动这三个服务：

sudo /etc/init.d/portmap restart
sudo /etc/init.d/nfs-kernel-server restart
sudo /etc/init.d/nfs-common restart

对于Client需要重新启动这两个服务：

sudo /etc/init.d/portmap restart
sudo /etc/init.d/nfs-common restart

这时候可以开始设定 /etc/exports。基本上和NFSv3差不多，只不过多了虚拟根目录的概念。NFSv4为了安全性问题，引入了Pseudo Filesystem的机制，这类似HTTP Server是从系统上的某个子目录当成网页的起始目录（虚拟根目录）。

设定档 /etc/exports范例一 (不正确的设定)：

/home 192.168.0.0/24(rw,fsid=0,async,no_root_squash)
/tmp 192.168.0.0/24(rw,async,no_root_squash)

如以上范例，笔者把home和tmp分享出来，先注意到fsid=0的参数，这个参数在NFSv4是有意义的！这宣告该分享目录是根目录，所以在NFSv4 Client端要mount时，需要mount -t nfs4 IP:/ /mnt/nfs，而不是传统的mount -t nfs IP:/home /mnt/nfs。所以在NFSv4和NFSv3最大的不同是，在v4要先用fsid=0定义出一个根目录，也只有那个根目录以下的子目录才能被挂载，笔者会在接下来用范例来解释。而虚拟根目录只能定义一个，若定义多个的话，会造成不可预期的问题。
Server重设分享目录：

username@ubuntu:~ $ sudo exportfs -rv 

Client挂载 /home范例：

sudo mount -t nfs4 192.168.0.183:/ /NFS # 用NFSv4協定掛載
sudo mount -t nfs 192.168.0.183:/home /NFS # 用NFSv3協定掛載

读者应该有注意到吧！挂载同一个Server上的 /home目录，因为在Server上的exports有指定 /home是虚拟根目录（fsid=0），所以NFSv4远端挂载点是和NFSv3不一样的喔！在我们这个范例中被exports出来的tmp将无法在NFSv4中被挂载，因为它不在虚拟根目录底下阿！所以使用NFSv4时，我们常常会建立一个根目录，然后把其它要分享的目录资源用mount --bind挂载进来，如以下范例。当然大家不会希望每次都要做bind的动作，所以请参考17-3-3小节把设定写到fstab吧！

使用bind来建立虚拟根目录范例：

sudo mkdir /export # 建立NFSv4分享的虛擬根目錄
sudo mkdir /export/home # 由於所有NFSv4分享目錄都要在虛擬根目錄底下，
sudo mkdir /export/tmp # 所以建立 /home和 /tmp來給bind用！
sudo mount --bind /home /export/home
sudo mount --bind /tmp /export/tmp

设定档 /etc/exports范例二 (正确的设定)：

/export 192.168.0.0/24(rw,fsid=0,nohide,insecure,no_subtree_check,async,root_squash)
/export/home 192.168.0.0/24(rw,nohide,insecure,no_subtree_check,async,root_squash)
/export/tmp 192.168.0.0/24(rw,nohide,insecure,no_subtree_check,async,root_squash)

改成这样后，我们先sudo exportfs -rv让新的exports生效，这已经解决虚拟根目录的问题，因为我们使用bind来连接 /home到 /export/home，也就是这两个目录是等义的，这样规划符合NFSv4的单一虚拟根目录的原则，同时也可以在NFSv3中被挂载！

不论Client是NFSv3或NFSv4，在参数加上nohide，这样Client端挂载一个目录时，会自动挂载该目录下其他可挂载资源，而不需要明确的指定并一个一个挂上。

Client挂载 /export范例：

sudo mount -t nfs4 192.168.0.183:/ /NFS # 用NFSv4協定掛載
sudo mount -t nfs 192.168.0.183:/export /NFS # 用NFSv3協定掛載

如以上范例，当Server端有设nohide时，Client在NFSv4会自动挂载 /tmp和 /home或在NFSv3会自动挂载 /export/home和 /export/tmp，不需要再另外设定。

当然也可以直接挂载子目录，如以下范例。

Client挂载 /export/home范例：

sudo mount -t nfs4 192.168.0.183:/home /NFS # 用NFSv4協定掛載
sudo mount -t nfs 192.168.0.183:/export/home /NFS # 用NFSv3協定掛載

若读者使用showmount去看Server分享的资源时，要注意的是这个方式显示的目录是走NFSv3旧的协定，所以没有考虑到虚拟根目录。故使用NFSv4挂载法需要自己把 /export去掉喔！
察看远端可分享的目录资源：

username@ubuntu:~ $ showmount -e 192.168.0.183 # 可用 -a來得知有多少Client連上
Export list for 192.168.0.183:
/export 192.168.0.0/24
/export/home 192.168.0.0/24
/export/tmp 192.168.0.0/24

或许读者会觉得奇怪，不是说NFSv4不需要portmap了嘛？那我们怎还把它启动呢？的确是不需要，若你把它关了是可以正常连线，但showmount是走旧的协定，所以就没办法看Server分享的资源啦！所以若你用不到showmount且不用NFSv3，可以把portmap关了。

将设定写到fstab来自动挂载吧！

在Client中把挂载设定写到 /etc/fstab里面，让每次开机都可以自动挂载远端的NFS Server是很方便的。在Server中若使用到NFSv4，常常用bind的技巧制造一个虚拟根目录，这些bind的规则也经常写到 /etc/fstab里面。这里的讨论继续沿用前两小节的范例，所以读者要视需求修改唷！

笔者先讨论如何在Server上开机后自动把虚拟目录和真正的分享目录bind起来。首先编辑Server上的fstab吧！

Server上的 /etc/fstab范例：

# <來源目錄>  　<目地目錄>   		none     bind   0   0
/home         /export/home  	none     bind   0   0
/tmp          /export/tmp   	none     bind   0   0

如以上范例，在Server上的fstab最后面加上这两行，开机后就会自动把你真正要分享的目录bind到虚拟路径底下唷！

在Client端要设定自动挂载也是加到fstab里面，如以下范例。
Client设定 /etc/fstab来自动挂载NFS Server：

# <Server IP>:<分享目錄>   <掛載點>   nfs4或nfs     <參數>    0  0
# 使用NFSv4協定掛載
192.168.0.183:/        /NFSA  nfs4  proto=udp,rsize=32768,wsize=32768,intr 0  0

# 使用NFSv3協定掛載
192.168.0.183:/export  /NFSB   nfs   proto=udp,rsize=8192,wsize=8192,intr 0  0

这个范例中，Client在开机后会自动mount Server上的 /export。不过一个是用传统的NFSv3，另外一个是NFSv4，它们可以同时使用。再次提醒，它们挂载的分享目录不同是因为NFSv4有虚拟根目录的概念。后面的参数读者可以参考使用，笔者测试这样的参数在区网效能会比较好，参数详细说明在表17-3-1-2。

若你修改过fstab后，不想要重新开机，可以透过以下指令重新依照fstab的内容挂载。
依照fstab的内容重新挂载：

sudo mount –a

若你要看目前系统上有哪些File system被挂载上来，可以透过mount，它也会列出本地硬盘的挂载情形。
了解目前有哪些档案系统被挂载：

username@ubuntu:~ $ mount
???(略)???
nfsd on /proc/fs/nfsd type nfsd (rw)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
192.168.0.183:/ on /NFS type nfs4 (rw,proto=udp,intr,addr=192.168.0.183) 

若当你要卸载NFS Filesystem，遇到系统资源忙碌而无法umount，这时候用Lazy unmount很有用。它会侦测该装置是否忙碌，等到有空档就自动帮你umount，通常笔者会配合force umount使用。
卸载NFS Filesystem：

sudo umount -l -f /NFS # umount /NFS這個NFS Filesystem

看到这里，读者的NFS系统应该也架起来了吧！若有问题，可以先检查一下防火墙设定是不是把它挡掉了，若真的找不到原因，也欢迎和笔者联络，在能力所及的范围下可以互相讨论。

Each host name needs to be resolveable, e.g. the name an IP address in /etc/hosts or via DNS and please make sure you have at least nfs-common installed and working. 

/net -hosts --timeout=60

# Sample auto.master file
# Format of this file:
# mountpoint map options
# For details of the format look at autofs(5).

/media/myth /etc/autofs/auto.media
/media/vantec /etc/autofs/auto.media
/media/cl-boblap /etc/autofs/auto.media
/media/cl-extra /etc/autofs/auto.media
/media/cl-windows /etc/autofs/auto.media

/net -hosts --timeout=60

auto.master
/var/autofs/net      /etc/autofs/auto.nfs  --timeout=60

auto.nfs
fatboy -fstype=nfs,rw,async,vers=3    192.168.0.101:/storage

rc.conf DAEMONS
nfs-common nfs-server

myth -fstype=nfs,rw,async,vers=3    192.168.1.100:/srv/nfs4/myth

myth -fstype=nfs,rw,async,vers=3    192.168.1.100:/srv/nfs4/myth
cl-boblap -fstype=nfs,rw,async,vers=3    192.168.1.105:/srv/nfs4/boblap
cl-extra -fstype=nfs,rw,async,vers=3    192.168.1.105:/srv/nfs4/compaq-extra
cl-windows -fstype=nfs,rw,async,vers=3    192.168.1.105:/srv/nfs4/compaq-windows

#localoptions='rsize=8192,wsize=8192'

# e.g. --timeout=60
daemonoptions='--verbose'

# Sample auto.master file
# Format of this file:
# mountpoint map options
# For details of the format look at autofs(5).

/var/autofs/net/      /etc/autofs/auto.nfs  --timeout=60

#/net -hosts --timeout=60

cl-extra -fstype=nfs,rw,async    192.168.1.105:/srv/nfs4/compaq-extra

Jan  9 17:05:43 localhost automount[20691]: attempting to mount entry /var/autofs/net/cl-extra
Jan  9 17:05:43 localhost rpc.idmapd[13356]: New client: 79
Jan  9 17:05:43 localhost rpc.idmapd[13356]: Opened /var/lib/nfs/rpc_pipefs/nfs/clnt79/idmap
Jan  9 17:05:43 localhost rpc.idmapd[13356]: New client: 7a
Jan  9 17:05:43 localhost rpc.idmapd[13356]: nss_getpwnam: name 'root@none' does not map into domain 'localdomain'
Jan  9 17:05:43 localhost rpc.idmapd[13356]: Stale client: 79
Jan  9 17:05:43 localhost rpc.idmapd[13356]:    -> closed /var/lib/nfs/rpc_pipefs/nfs/clnt79/idmap
Jan  9 17:05:43 localhost rpc.idmapd[13356]: Stale client: 7a
Jan  9 17:05:43 localhost rpc.idmapd[13356]:    -> closed /var/lib/nfs/rpc_pipefs/nfs/clnt7a/idmap
Jan  9 17:05:43 localhost automount[20691]: >> mount.nfs: Argument list too long
Jan  9 17:05:43 localhost automount[20691]: mount(nfs): nfs: mount failure 192.168.1.105:/srv/nfs4/compaq-extra on /var/autofs/net
Jan  9 17:05:43 localhost automount[20691]: failed to mount /var/autofs/net/cl-extra
Jan  9 17:05:43 localhost automount[20691]: attempting to mount entry /var/autofs/net/cl-extra
Jan  9 17:05:43 localhost automount[20691]: failed to mount /var/autofs/net/cl-extra
Jan  9 17:05:43 localhost automount[20691]: attempting to mount entry /var/autofs/net/cl-extra
Jan  9 17:05:43 localhost automount[20691]: failed to mount /var/autofs/net/cl-extra
Jan  9 17:05:43 localhost automount[20691]: attempting to mount entry /var/autofs/net/cl-extra
Jan  9 17:05:43 localhost automount[20691]: failed to mount /var/autofs/net/cl-extra

[General]

Verbosity = 1
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = localdomain

[Mapping]

Nobody-User = nobody
Nobody-Group = nobody

[Translation]

Method = nsswitch

/srv/nfs4 192.168.1.101(rw,fsid=0,no_subtree_check,async,no_root_squash)
/srv/nfs4 192.168.1.100(rw,fsid=0,no_subtree_check,async,no_root_squash)
/srv/nfs4/boblap 192.168.1.101(rw,no_subtree_check,async,nohide)
/srv/nfs4/boblap 192.168.1.100(rw,no_subtree_check,async,nohide)
/srv/nfs4/compaq-windows 192.168.1.101(rw,no_subtree_check,async,nohide)
/srv/nfs4/compaq-windows 192.168.1.100(rw,no_subtree_check,async,nohide)
/srv/nfs4/compaq-extra 192.168.1.101(rw,no_subtree_check,async,nohide)
/srv/nfs4/compaq-extra 192.168.1.100(rw,no_subtree_check,async,nohide)

cl-extra -fstype=nfs,rw,async    192.168.1.105:/compaq-extra

Jan 10 14:07:06 localhost automount[32016]: Starting automounter version 5.0.5, master map auto.master
Jan 10 14:07:06 localhost automount[32016]: using kernel protocol version 5.01
Jan 10 14:07:06 localhost automount[32016]: mounted indirect on /var/autofs/net/ with timeout 60, freq 15 seconds
Jan 10 14:07:06 localhost automount[32016]: ghosting enabled
Jan 10 14:07:33 localhost automount[32016]: attempting to mount entry /var/autofs/net/cl-extra
Jan 10 14:07:33 localhost rpc.idmapd[3327]: New client: 1
Jan 10 14:07:33 localhost rpc.idmapd[3327]: Opened /var/lib/nfs/rpc_pipefs/nfs/clnt1/idmap
Jan 10 14:07:33 localhost rpc.idmapd[3327]: New client: 2
Jan 10 14:07:33 localhost rpc.idmapd[3327]: nss_getpwnam: name 'root@none' does not map into domain 'localdomain'
Jan 10 14:07:33 localhost rpc.idmapd[3327]: New client: 3
Jan 10 14:07:33 localhost rpc.idmapd[3327]: Stale client: 2
Jan 10 14:07:33 localhost rpc.idmapd[3327]:     -> closed /var/lib/nfs/rpc_pipefs/nfs/clnt2/idmap
Jan 10 14:07:33 localhost automount[32016]: mount(nfs): mounted 192.168.1.105:/compaq-extra on /var/autofs/net
Jan 10 14:07:33 localhost automount[32016]: mounted /var/autofs/net/cl-extra

NFS

1、NFS（网络文件系统Network File System）可能启动的进程有nfsd、rpc.mountd、rpc.statd、lockd（内核态）、rpc.idmapd、rpc.gssd、rpc.svcgssd。nfsd使用2049的TCP和2049的UDP端口，其它的端口号由portmap随机提供（portmap自己监听在111端口）；

2、NFS的各个版本概述：

a> NFS v1是SUN公司研发的，包含在Sun的操作系统里，没有单独公开发行过；

b> NFS v2是最原始的NFS协议，在RFC 1094中描述。基于UDP协议，最大单个文件4G；

c> NFS v3在RFC 1813中描述，相对于v2增加了TCP协议支持，安全的async异步写入支持，服务器端访问控制，支持大于16Y的单个文件大小（64bit），提高了一次读写的最大大小，某些版本可以为RPC开启基于kerberos的身份验证（RHEL使用的版本就可以）。v3相对于v2在性能上是一个大的跃进，但从安全的角度来看并没有多少提升；

d> NFS v4在RFC 3530中描述，相对于v3，它把lock和mount都整合进了核心协议中（原来在辅助协议），开发了新的ACL机制，引入对UTF8字符集的支持。NFS v4要求所有的实现都必须支持kerberos的身份验证（RPCSEC_GSS）（替代原有的基于UID、GID的身份验证），要求所有实现必须支持多种加密传输模式。从安全角度而言NFS v4是一个大的跃进，但目前它没有v3版本使用得广泛；

3、NFS v3的连接过程：

a> 客户端问服务器端的portmap：rpc.mount目前的用哪个端口？

b> 客户端向服务器端的rpc.mount请求挂载NFS；

c> 服务器端的rpc.mount判断权限后给客户端一个文件句柄；

d> 客户端使用这个句柄与服务器端的nfsd交流（使用TCP或UDP的2049端口），以读写文件；

e> 文件锁是由lockd和rpc.stats管理的；

4、NFSv3协议的服务器端是无状态的，所以就算机器重启了，NFS服务起来以后，客户端依然可以拿着旧文件句柄继续读写文件。但是服务器端的lockd进程是有状态的，重启就有点麻烦，解决方案是服务器端的rpc.statd让客户端报告自己手里的锁，然后重新让lockd恢复锁状态。这种锁状态机制是到v3版本才引入的；v2版本在crash之后会出现锁错误；

5、NFS v3的验证机制：

a> NFS v3及其附属协议采用标准的RPC AUTH_SYS（又称AUTH_UNIX）机制验证挂载后的客户端对具体文件的权限，服务器完全信任客户端声名的自己的权限（其实不能被称为是“验证”了）；

b> 大概过程就是客户端会在读写之前告诉服务器自己的UID和GID，然后NFS就把这些ID视同自己系统上的ID来验证权限；

c> 客户端可以很容易伪造出高权限的ID以达到攻击的目的，防御的临时解决之道是不让NFS暴露在公有网络上且不打开NFS的root权限（是比较弱的防御）；

d> 还有一个麻烦是，不同客户端上同一个username的UID想保持同步是件不容易的事；

e> 为了解决NFS 验证机制的不足，为NFS引入的解决之道就是kerberos（也就是RPCSEC_GSS验证机制）；

6、NFS的UID／GID同步问题初步讨论：

a> 最简单的办法就是用root_squash或者all_squash来做UID映射，把所有用户都映射成匿名用户。需要注意的是匿名用户的UID其实是-2，所以65534其实只是在16bit用户ID的系统上的表现，在一些32bit用户ID的系统上-2会被表现为4294967294；

b> pam_lisfile.so和pan_limits.so这两个PAM模块可以帮助我们确保NFS用户不会得到shell登录权限；

c> UID和GID在不同客户端之间不同的根治方法是使用NIS或者LDAP的方式直接把UID／GID统一掉；

7、NFS v3的安全怎么做？

a> 不要把包含配置文件的目录export出去；

b> export整个文件系统的根出去，而不是export文件系统中某个目录出去。因为即使只是export一个目录出去，攻击者也可能通过猜测的方式得到文件系统中其它目录的读写权限。比如说一个ext3挂载在/mnt/下了，用NFS export/mnt/data1/出去，攻击者就可能读写/mnt/data2/下的文件。这显然不是我们希望的，因此不如干脆共享整个文件系统（也就是/mnt/）出去。或者也可以使用NFS的substree_check来帮我们做检查来防止这种入侵，但是这个选项会较大幅度降低NFS的性能；

c> 如果一个文件系统挂载点是另一个文件系统的子目录，那么父系统开启crossmnt或者子系统开启nohide就可以把两个文件系统都共享出去，使用这个选项的时候要小心，别共享了自己不想共享的内容出去；

d> 虽然nfsd固定使用2049端口，但是lockd、mountd、statd都使用portmap随机分配的端口，这让防火墙很难配置，而且还可能占用还没起来的其它服务的端口。可以在/etc/sysconfig/nfs中把这些进程的端口都配置成固定的，这样配置防火墙（只放行自己信任的IP）就容易了；

e> NFS基于IP的认证方式让伪造身份成为可能，基于AUTH_SYS（UID／GID）的授权方式让越权变成可能，明文的、没有完整性校验（有校验网络传输完整，没有安全性完整校验）的传输协议让嗅探和篡改变成可能。要解决这些问题，就要采用NFS v4了；

f> NFS是个十分复杂的服务，很多部分要求root权限运行，还运行在内核态里。如果不是必要就尽量不要启动它，以防止未来发现的漏洞给攻击者可乘之机；

8、rpcinfo -p可以查看portmap分配出去的端口；

9、NFS v4的相对v3的变化：

a> NFS版本4把周边附属协议的lockd、rpc.mountd、rpc.statd都整合进了主协议中，进程也都整合进了nfsd里。整个服务的进程结构精简了很多，防火墙只需要开放2049和111端口NFS即可正确提供服务；

b> 新增了一个必须运行的rpc.idmapd进程（服务器端和客户端都要运行），支持RPC验证协议，用于保持username-uid的映射，解决了之前版本的那个麻烦的UID不一致问题。当然，还是可以选择AUTH_SYS的验证方式，自己去弄那麻烦；

c> NFS v4原生可以支持基于kerberos的RPCSEC_GSS安全认证，开启这个功能的话能简化配置，提高安全性，也解决了UID不一致的问题；

d> 精简的协议带来了一定的速度提升（约10％，详见http://www.fedoraforum.org/forum/showthread.php?t=219433）；

e> NFSv4仍在继续开发中，见www.nfsv4.org；

10、NFS v4引入了一个叫做pseudo filesystem（伪文件系统）的机制，网上挺多针对它的讨论的，挺多人认为这个纯属脱裤子放屁，教材上也没提它能带来什么好处。大概意思就是说要先选一个目录表明fsid＝0作为一个伪文件系统的根，然后所有需要export的目录和文件系统都挂载在这个伪文件系统的下，就如同是它的一个子目录。我翻了一下RFC3530（http://www.ietf.org/rfc/rfc3530.txt），RFC里的意思呢，主要是为了解决命名空间的问题，有了这个伪文件系统根，再加上主机名，基本命名空间就都散开不会冲突了。再一个，用了这个之后客户端直接用READDIR就能遍历服务器端的所有export，特别在服务器新export了东西以后，客户端不用做出任何更改便可直接使用新的东西（如果有权限的话）。更详细的见RFC3530
7.3.0；

11、RFC2203介绍了NFS如何利用kerberos的验证机制（又唤RPCSEC_GSS），v3和v4版本都可以用，需要在客户端使用rpc.gssd，在服务器端使用rpc.svcgssd来完成沟通。rpc.svcgssd会通过GSSAPI去获得kerberos的验证信息，而rpc.gssd则负责去向kerberos获得权限认证。它们也会帮忙解决username－uid／groupname－gid映射的麻烦。但是启用了kerberos验证就不能使用基于IP的验证了（当然iptables是可以用的）在Linux
2.6.23和nfs-utils1.1.1后变为可能；

12、kerberos有几种帮助NFS做安全的模式，这些模式需要在服务器端/etc/exports中指定：

a> krb5。仅使用kerberos来做用户身份验证；

b> krb5i。除了之上，再加上安全的数据完整性校验（基于对称密钥的签名）；

c> krb5p。除了之上，再加上把所有数据都加密；

13、目前SELinux还没有能力在NFS的服务器和客户端之间传递安全上下文，这个工作正在进行中，所以目前服务器端和客户端分别有自己的安全上下文（客户端的上下文是统一的，自己设置的）。SELinux为NFS预置了一些很有用的布尔值，如nfs_export_all_rw和use_nfs_home_dirs；

14、cat /proc/net/rpc/nfs4.idtoname/content可以看到NFSv4的名字映射；

15、客户端完全重启NFSv4模块的方法，顺序执行以下：

a> umount -at nfs4；

b> 停止rpc.gssd、rpc.idmapd、autofs；

c> 重启内核模块：modprobe -r nfs lockd fscache nfs_acl rpcsec_gss_krb5 authrpcgss autofs4；

d> 启动rpc.gssd、rpc.idmapd、autofs；

e> 重新挂载NFSv4文件系统；

16、整理一下启用kerberos验证的NFSv4的几个要素：

a> kerberos机制正常；

b> 服务器正确下载了自己principal的keytab；

c> rpc.svcgssd和rpc.gssd正常启动；

d> TGT正确且没过期（可用klist查看）；

e> rpc.idmapd正确配置了；

17、用于NFS的kerberos目前只能用des-cbc-md5的加密方式（要在kadd的时候声名）；

18、NFS v3虽然可以使用kerberos，但并没有v4支持地那么完整。由于它的MOUNT协议还是只支持AUTH_SYS，因此还是需要给未授权用户MOUNT的权限，当然把它们限制到只读是可以的；

19、在高可用的环境下，虽说NFS的句柄是服务器端无状态的，即在服务器重启之后依然可用，但如果NFS服务从一个服务器飘到另一个服务器上提供服务了，那么旧的文件句柄则可能会因为fsid的改变而变得不可用。此时，在配置文件中指定每一个export的fsid是个不错的主意；

原文地址：http://zhumeng8337797.blog.163.com/blog/static/10076891420133159642783/