NFS服务器原理

NFS服务器

---

 

port：2049

     NFS 为 Network FileSystem 的简称，它的目的就是想让不同的机器、不同的操作系统可以彼此分享个别的档案啦！目前在 Unix Like 当中用来做为文件服务器是相当不错的一个方案！基本上， Unix Like主机连接到另一部 Unix Like 主机来分享彼此的档案时，使用 NFS 要比 SAMBA 这个服务器快速且方便的多了！此外， NFS 的设定真的很简单，几乎只要记得启动 Remote Procedure Call  (RPC, 就是 rpcbind 这个软件啦！ ) 就一定可以架设的起来！真是不错啊！

 

13.1 NFS的由来与其功能

 

NFS 这个藉由网络分享文件系统的服务在架设的时候是很简单的，不过，它最大的问题在于『权限』方面的概念！

因为在客户端与服务器端可能必须要具备相同的账号才能够存取某些目录或档案。

另外， NFS 的启动需要透过所谓的远程过程调用 (RPC)，也就是说，我们并不是只要启动 NFS 就好了， 还需要启动 RPC 这个服务才行！

 

13.1.1 什么是NFS（Network FileSystem）

 

     就如同上面的图示一般，当我们的 NFS 服务器设定好了分享出来的/home/sharefile 这个目录后，其他的 NFS 客户端就可以将这个目录挂载到自己系统上面的某个挂载点 (挂载点可以自定义)，例如前面图示中的 NFS client 1 与 NFSclient 2 挂载的目录就不相同。我只要在 NFS client 1 系统中进入/home/data/sharefile 内，就可以看到 NFS 服务器系统内的 /home/sharefile 目录下的所有数据了 (当然，权限要足够啊！^_^)！这个 /home/data/sharefile 就好像 NFSclient 1 自己机器里面的一个 partition 喔！只要权限对了，那么你可以使用 cp, cd,mv, rm... 等等磁盘或档案相关的指。

 

      因为 NFS 支持的功能相当的多，而不同的功能都会使用不同的程序来启动， 每启动一个功能就会启用一些端口口来传输数据，因此， NFS 的功能所对应的端口口才没有固定住， 而是随机取用一些未被使用的小于 1024 的端口来作为传输之用。但如此一来又造成客户端想要连上服务器时的困扰， 因为客户端得要知道服务器端的相关端口才能够联机吧！

      此时我们就得需要远程过程调用 (RPC) 的服务啦！

 

13.1.2 什么是RPC（Remote Procedure Call）

 

     RPC 最主要的功能就是在指定每个 NFS 功能所对应的 port number ，并且回报给客户端，让客户端可以连结到正确的端口上去。

 

注意： 要启动 NFS 之前， RPC 就要先启动了，否则 NFS 会无法向 RPC 注册。 另外， RPC 若重新启动时，原本注册的数据会不见，因此 RPC 重新启动后，它管理的所有服务都需要重新启动来重新向 RPC 注册。

 

如上图所示，当客户端有 NFS 档案存取需求时，他会如何向服务器端要求数据呢？

1. 客户端会向服务器端的 RPC (port 111) 发出 NFS 档案存取功能的询问要求；
2. 服务器端找到对应的已注册的 NFS daemon 端口后，会回报给客户端；
3. 客户端了解正确的端口后，就可以直接与 NFS daemon 来联机。

 

 

由于 NFS 的各项功能都必须要向 RPC 来注册，如此一来 RPC 才能了解 NFS 这个服务的各项功能之 port number, PID, NFS 在服务器所监听的 IP 等等，而客户端才能够透过 RPC 的询问找到正确对应的端口。

 

 

13.1.3 NFS 启动的 RPC daemons

 

     NFS 服务器主要的任务是进行文件系统的分享，文件系统的分享则与权限有关。 所以 NFS 服务器启动时至少需要两个 daemons ，一个管理客户端是否能够登入的问题， 一个管理客户端能够取得的权限。

     

以较单纯的 NFS 服务器来说：

• rpc.nfsd：最主要的 NFS 服务器服务提供商。
  • 这个 daemon 主要的功能就是在管理客户端是否能够使用服务器文件系统挂载信息等， 其中还包含这个登入者的 ID 的判别！
• rpc.mountd这个 daemon 主要的功能，则是在管理 NFS 的文件系统！
  • 当客户端顺利的通过 rpc.nfsd 而登入服务器之后，在他可以使用 NFS 服务器提供的档案之前，还会经过档案权限 (就是那个 -rwxrwxrwx 与 owner, group 那几个权限啦)的认证程序！
  • 他会去读 NFS 的配置文件 /etc/exports 来比对客户端的权限，当通过这一关之后客户端就可以取得使用 NFS 档案的权限啦！
  • (注：这个也是我们用来管理 NFS 分享之目录的权限与安全设定的地方哩！ )
• rpc.lockd (非必要)这个玩意儿可以用在管理档案的锁定 (lock) 用途。为何档案需要『锁定』呢？因为既然分享的 NFS 档案可以让客户端使用，那么当多个客户端同时尝试写入某个档案时， 就可能对于该档案造成一些问题啦！这个 rpc.lockd 则可以用来克服这个问题。 但 rpc.lockd 必须要同时在客户端与服务器端都开启才行喔！此外， rpc.lockd 也常与 rpc.statd 同时启用。
• rpc.statd (非必要)可以用来检查档案的一致性，与 rpc.lockd有关。 若发生因为客户端同时使用同一档案造成档案可能有所损毁时， rpc.statd 可以用来检测并尝试回复该档案。与 rpc.lockd 同样的，这个功能必须要在服务器端与客户端都启动才会生效。

 

 

     上述这几个 RPC 所需要的程序，其实都已经写入到两个基本的服务启动脚本中了，那就是 nfs 以及 nfslock 啰！ 亦即是在 /etc/init.d/nfs, /etc/init.d/nfslock，与服务器较有关的写入在 nfs 服务中，而与客户端的 rpc.lockd 之类的，就设定于nfslock 服务中。

 

 

13.1.4 NFS 的档案访问权限

 

当我以 dmtsai 这个一般身份使用者要去存取来自服务器端的档案时，你要先注意到的是：

 

文件系统的 inode 所记录的属性为 UID, GID 而非账号与群组名。

那一般Linux 主机会主动的以自己的 /etc/passwd, /etc/group 来查询对应的使用者、组名。

所以当 dmtsai 进入到该目录后，会参照 NFS client 1 的使用者与组名。

 

但是由于该目录的档案主要来自 NFS server ，所以可能就会发现几个情况：

• NFS server/NFS client 刚好有相同的账号与群组则此时使用者可以直接以 dmtsai 的身份进行服务器所提供的文件系统之存取。
• NFS server 的 501 这个 UID 账号对应为 vbird若 NFS 服务器上的 /etc/passwd 里面 UID 501 的使用者名称为 vbird 时，则客户端的 dmtsai 可以存取服务器端的 vbird 这个使用者的档案喔！只因为两者具有相同的 UID 而已。这就造成很大的问题了！因为没有人可以保证客户端的 UID 所对应的账号会与服务器端相同， 那服务器所提供的数据不就可能会被错误的使用者乱改？
• NFS server 并没有 501 这个 UID另一个极端的情况是，在服务器端并没有 501 这个 UID 的存在，则此时 dmtsai的身份在该目录下会被压缩成匿名者， 一般 NFS 的匿名者会以 UID 为 65534为其使用者，早期的 Linux distributions 这个 65534 的账号名称通常是nobody ，我们的 CentOS 则取名为 nfsnobody 。但有时也会有特殊的情况，例如在服务器端分享 /tmp 的情况下， dmtsain 的身份还是会保持 501 但建立的各项数据在服务器端来看，就会属于无拥有者的资料。
• 如果使用者身份是 root 时有个比较特殊的使用者，那就是每个 Linux 主机都有的 UID 为 0 的 root 。

 

     总之，客户端使用者能做的事情是与 UID 及其 GID 有关的，那当客户端与服务器端的 UID 及账号的对应不一致时， 可能就会造成文件系统使用上的困扰，这个就是NFS 文件系统在使用上面的一个很重要的地方！

 

而在了解使用者账号与 UID 及文件系统的关系之后，要实际在客户端以 NFS 取用服务器端的文件系统时， 你还得需要具有：

• NFS 服务器有开放可写入的权限 (与 /etc/exports 设定有关)；
• 实际的档案权限具有可写入 (w) 的权限。

 

当你满足了：

(1)使用者账号，亦即 UID 的相关身份；

(2)NFS 服务器允许有写入的权限；

(3)文件系统确实具有 w 的权限时，你才具有该档案的可写入权限！

尤其是身份 (UID) 确认的环节部分，最容易搞错啦！也因为如此， 所以 NFS 通常需要与NIS这一个可以确认客户端与服务器端身份一致的服务搭配使用，以避免身份的错乱。