Linux/UNIX下NFS的技术细节

NFS的技术细节

与大多数基于网络的服务一样，NFS也使用了客户端和服务器实例，也就是说，它有自己的客户端组件和服务器端组件。

我们在第7章中介绍了文件系统的挂载和卸载，NFS上也使用相同的概念，区别在于每个NFS挂载都需要指定磁盘共享所来自的服务器的合格的名称，当然，该服务器必须要配置客户端请求的分区为共享的分区。

下来我们看一个例子。假定有一个名为serverA的NFS服务器，它允许要通过网络共享其/home分区或者目录。在NFS中，我们称这种共享为导出/home分区。假定网络中有一个名为clientA的客户端系统，它需要访问NFS服务器导出的/home分区的内容。最后，我们假定所有的要求（许可权限、安全、兼容性等等）都是具备的。

为了让clientA访问serverA导出的/home共享分区，clientA需要向导出的/home分区发出一个NFS挂载请求，这样它才能将该分区挂载到本地，这样，该共享就会像本地/home目录一样。执行这个挂载请求的命令如下所示：

[root@clientA ~]# mount serverA:/home  /home

假定上面这条命令是在主机clientA上运行的，那么，所有clientA上的用户都将可以查看/home的内容，就像这就是本机的另外一个目录一样。Linux会处理所有到服务器的网络请求。

远程过程调用RPC负责处理在客户端和服务器之间的请求。RPC技术为任何RPC客户端联系服务器以及找出应该将其定向到哪个服务提供了一种标准机制。因而，在服务器上要是一个服务可用，就必须在RPC服务管理器——portmap中注册该服务。portmap负责告诉客户端服务器上真正的服务在哪里。

1 NFS的版本

NFS并不是一个静态的协议，标准委员会已经帮助NFS发展了很多新技术的优点，也包括使用风格的改变。在本书编写的时候，有3个比较知名的该协议的版本：NFS版本2（NFSv2）、NFS版本3（NFSv3）和NFS版本4（NFSv4）。NFS版本1也存在，但是它是SUN内部的，它从就没有真正在SUN以外使用过！

NFSv2是这3个版本中最古老的；NFSv3可能是使用范围最广的标准；NFSv4已经开发了一段时间了，它是最新的标准。NFSv2应该尽可能避免使用，只有因为历史遗留原因才会考虑使用NFSv2。考虑稳定性和最大范围的客户端的支持的话，就使用NFSv3。如果需要利用前沿的新特性以及不考虑向后的兼容新的新部署时，我们就考虑使用NFSv4。

在决定NFS版本的时候最重要的因素可能是考虑我们的客户端支持哪个版本。

下面是对每个NFS版本的特性的介绍：

l         NFSv2 挂载请求是基于每主机的，而不是基于每用户。它使用TCP或者UDP作为其传输协议。版本2的客户代可以访问的文件大小限制为2GB以下。

l         NFSv3 这个版本包含了对NFSv2中大量的bug的修复，与协议版本2相比，它提供了更多的特性和性能上的提高，它也可以使用TCP或者UDP作为其传输协议。依赖于NFS服务器本身文件系统的限制，客户端可以访问2GB以上大小的文件。挂载请求也是基于每主机的，而不是基于每用户。

l         NFSv4 协议的这个版本使用可靠的协议像TCP或者SCTP作为其传输协议。它提高的安全性主要来自它对Kerberos的支持，例如，客户端的认证可以根据每用户或者主要的负责人来管理。它被设计为Internet应用，因而协议的这个版本对防火墙很友好，它监听众所周知的端口2049。在这个协议版本中不再需要RPC绑定协议的服务，因为这些功能已经内建在服务器中了。换句话说，NFSv4在单一的协议规范中结合了以前这些全然不同的NFS协议（不再使用portmap服务）。它包含了对文件访问控制列表（ACL）特性的支持，同时它还支持版本2和版本3的客户端。NFSv4中引入了伪文件系统的概念。

我们可以在客户端挂载NFS共享的时候使用mount选项来指定使用的NFS的版本。对于使用NFSv2的Linux客户端，mount的选项为nfsvers=2；对于使用NFSv2的Linux客户端，mount的选项为nfsvers=3；对于NFSv4，它不再支持nfsvers选项，但是我们可以通过指定nfs4作为文件系统的类型来使用NFSv4。

本章中接下来将集中介绍NFSv3，因为NFSv3在Linux下是比较稳定的，而且很知名，同时还具有最广泛的平台支持。

2 NFS的安全方面的考虑

很不幸，NFS并不是一个很安全的共享磁盘的方法，使得NFS系统更安全的步骤与让其他的系统更安全的步骤并没有什么不同，惟一的把握是我们必须要有信任客户端系统上的用户、尤其是root用户的能力。如果我们同时是客户端和服务器上的root用户，就不太需要担心这一点。在这种情况下重要的是确保非root用户不能变成root用户——这也就是我们所需要注意的地方！

如果我们处于不能完全信任访问共享磁盘的用户的这种环境下，那我们就需要花时间来努力找出可选的共享资源的方式（比如只读共享磁盘）。

始终保持对计算机紧急相应工作组（http://www.cert.org/）的最新的安全公告的关注，同时保持从我们的软件提供商发布的所有的补丁。

3挂载并访问一个分区

客户端请求挂载服务器的分区是需要执行如下步骤（这些步骤主要适用于NFSv2和NFSv3）：

1.         客户端向服务器的portmap管理器联系，确定分配给NFS挂载服务的网络端口。

2.         客户端与服务器的挂载服务联系并请求挂载一个分区，挂载服务检查该客户端是否具有挂载该分区的权限（客户端挂在分区的权限基于/etc/exports文件来决定）。如果该客户端具有对应的权限，服务器就会返回肯定的答复。

3.         客户端再次向服务器的portmap管理器联系，这次它要确定NFS服务器所在的端口（这个端口通常是2049）。

4.         只要客户端希望向服务器发出请求（例如，要阅读一个目录），就会向NFS服务器发送一个RPC（远程过程调用）。

5.         客户端完成之后，它就会更新自己的挂载表，但是它并不会通知服务器。

通知服务器是没有必要的，因为并不跟踪那些挂载它的文件系统的客户端。因为服务器并不维护客户端的状态信息，客户端也不维护服务器的状态信息，因而，当客户端和服务器之间出现系统崩溃时，它们之间并不知道这种分别，因此，如果NFS服务器重新启动，一旦该服务器重新在线，所有的客户端就会自动继续它们的操作。

4启用NFS

自护所有主流的Linux发行版都带有这样或那样对NFS的支持，管理员唯一要做的就是配置并启用NFS。在我们示例的Fedora Core系统中，启用NFS是很容易的。

因为NFS及其辅助程序都是基于RPC的，所以我们需要首先确保系统中运行portmap服务。使用如下所示的命令来在Fedora系统上检查portmap服务的状态：

[root@serverA ~]# service portmap status

portmap is stopped

如果像例子中显示的，portmap服务是停止的，我们可以使用如下命令启动该服务：

[root@serverA ~]# service portmap start

Starting portmap:                                                                                       [ OK ]

在继续之前，使用rpcinfo命令查看一下在portmap中注册的基于RPC的服务的状态，图下所示：

[root@serverA ~]# rpcinfo -p

program         vers       proto      port

100000           2            tcp         111 portmapper

100000           2            udp        111 portmapper

因为在我们的示例系统中还没有运行NFS，这个输出中没有显示太多的RPC服务。

要启动NFS服务，使用如下命令：

[root@serverA ~]# service nfs start

Starting NFS services:                                                                               [ OK ]

Starting NFS quotas:                                                                                 [ OK ]

Starting NFS daemon:                                                                                [ OK ]

Starting NFS mountd:                                                                                [ OK ]

再次运行rpcinfo命令来查看portmap中注册的基于RPC的服务的状态：

[root@serverA ~]# rpcinfo -p

program         vers       proto      port

100000           2            tcp         111 portmapper

100000           2            udp        111 portmapper

100011           1            udp        952 rquotad

100003           2            udp        2049 nfs

....<OUTPUT TRUNCATED>.....

100003           3            udp        2049 nfs

100021           1            udp        32791 nlockmgr

100005           1            udp        970 mountd

以上输出显示各种RPC程序（mountd、nfs、rquotad等等）正在运行。

要在不关机的情况下停止NFS服务，使用如下命令：

[root@serverA ~]# service nfs stop

Shutting down NFS mountd:                                                                     [ OK ]

Shutting down NFS daemon:                                                                     [ OK ]

Shutting down NFS quotas:                                                                       [ OK ]

Shutting down NFS services:                                                                     [ OK ]

为了让NFS服务在系统重启之后自动启动，我们可以使用chkconfig命令。使用如下命令检查当前在那个运行级别中该服务是被配置为启动的：

[root@serverA ~]# chkconfig --list nfs

nfs                 0:off       1:off       2:off       3:off       4:off       5:off       6:off

在Fedora Core系统中，NFS服务默认是禁用的，输入如下命令是该服务在启动时自动运行：

[root@serverA ~]# chkconfig nfs on

5 NFS的组件

NFS协议版本2和版本3主要依赖于远程过程调用RPC来处理在客户端和服务器之间的通讯。在Linux下RPC服务是由portmap管理的。正如前面所讲的，这个辅助的服务在NFSv4种将不再需要。

下面列出了一些在Linux下的不同的NFS服务所使用的RPC进程，这些RPC进程主要适用于NFS版本2和NFS版本3，但是在NFSv4中也有涉及。

l         rpc.statd NFS服务器正常关机之后，再次启动的时候，这个进程负责在向NFS客户端发送通告。当被查询时，它向rpc.lockd提供有关服务器的状态信息，这个过程通过网络状态监视器（NSM）RPC协议来完成，在Fedora Core系统中，这个可选的服务被nfslock服务自动启动。在NFSv4种不使用该服务。

l         rpc.rquotad 正如其名称，rpc.rquotad提供在NFS和配额管理器之间的接口。NFS用户/客户端如果在本地文件系统而不是NFS上工作时，它们将会被应用以相同的磁盘配额限制。

l         rpc.mountd 当客户端请求挂载分区时，rpc.mountd守护进程负责校验该客户端是否有足够的权限来挂载该分区，这个权限信息保存在/etc/exports文件中（下一节21.2.1：“配置文件/etc/exports”中我们将学习到更多相关的信息）。这个进程被NFs服务器的init脚本自动启动，在NFSv4中将不使用该进程。

l         rpc.nfsd NFS系统的主要组件，它是NFS的服务器进程，它和Linux内核一起工作，根据需要或者加载、或者不加载内核模块。当然，这个进程在NFSv4中仍然是有用的。

注意：我们应该知道，不管该协议版本如何，NFS本身是一个基于RPC的服务。因此，即使是NFSv4也是基于RPC的。其良好的形象掩盖了如下的事实：大多数先前使用的基于RPC的辅助服务已经不再必要了，因为它们这些独立的功能现在已经集成到NFS守护进程中了。

l         rpc.lockd rpc.statd守护进程使用这个进程来处理崩溃系统上的锁定恢复。这个进程也可以被客户端用来锁定服务器上的文件。它就是nfslock服务，在NFSv4中不再使用。

l         rpc.idmapd 这是NFSv4的ID名称映射进程。它通过将用户ID和组ID转换成名称来向NFSv4核心客户端和服务器提供这种功能。

l         rpc.svcgssd 这是服务器端的rpcsec_gss进程。rpcsec_gss协议允许在NFSv4中使用gss-api通用安全API来提供高级的安全性。

l         rpc.gssd 这个进程在NFSv4的认证机制中提供了客户端的传输机制。

6 NFS的内核支持

在不同的Linux发行版当中NFS以两种形式实现。大多数的Linux发行版在内核中都自带开启NFS的支持，少数的Linux发行版也带有对NFS的支持，不过它们是以独立进程的形式出现的，可以通过软件包来安装。

早在Linux 2.2的时候，就有了基于内核支持的NFS，它明显比早期实现的NFS运行速度快得多。在编写本书的时候，基于内核的NFS服务器支持已经被认为是现成的产品了。当然，这并非强制性的，如果我们在内核编译中不实现NFS支持，我们将不能使用NFS。如果我们有机会尝试让内核支持NFS，我们高度推荐大家这么做。如果我们选择了不使用NFS，也不用担心：处理NFS服务器服务的nfsd程序完全是自包含的，它提供NFS服务所需的一切。

注意：另一方面，客户端必须在内核中支持NFS。内核中对NFS的这种支持已经有很长时间了，大家公认它是很稳定的。几乎所有现在的Linux发行版都在内核中支持NFS的启用。