| 跳过导航链接 | |
| 退出打印视图 | |
|
Oracle Solaris 管理：网络服务 Oracle Solaris 11 Information Library (简体中文) |
| 跳过导航链接 | |
| 退出打印视图 | |
|
|
Oracle Solaris 管理：网络服务 Oracle Solaris 11 Information Library (简体中文) |
以下各节介绍了 NFS 软件的一些复杂功能。请注意，本节说明的某些功能仅适用于 NFS 版本 4。
注 - 如果系统启用了区域并且您要在非全局区域中使用此功能，请参见《Oracle Solaris 管理：Oracle Solaris Zones、Oracle Solaris 10 Zones 和资源管理》以了解更多功能。
NFS 启动过程包括协商服务器和客户机的协议级别。如果未指定版本级别，则缺省情况下将选择最佳级别。例如，如果客户机和服务器都可以支持版本 3，则会使用版本 3。如果客户机或服务器只能支持版本 2，则会使用版本 2。
可以使用 sharectl 命令设置 client_versmin、client_versmax、server_versmin 和 server_versmax 参数。为服务器和客户机指定的最小值和最大值将取代这些关键字的缺省值。对于客户机和服务器，最小缺省值为 2，最大缺省值为 4。为查找服务器支持的版本，NFS 客户机会从 client_versmax 的设置开始，然后依次尝试每个版本，直到遇到 client_versmin 的版本设置为止。一旦找到所支持的版本，此过程便会终止。例如，如果 client_versmax=4 而 client_versmin=2，则客户机会首先尝试版本 4，然后尝试版本 3，最后尝试版本 2。如果 client_versmax 和 client_versmax 设置为相同的值，则客户机会始终使用此版本，而不会尝试任何其他版本。如果服务器不提供此版本，挂载将会失败。
有关过程信息，请参阅设置 NFS 服务。
在版本 4 中对 NFS 进行了许多更改。本节介绍这些新功能。
注 - 从 Solaris 10 发行版开始，NFS 版本 4 不支持 LIPKEY/SPKM 安全风格。另外，NFS 版本 4 也不会使用 mountd、nfslogd 和 statd 守护进程。
有关与使用 NFS 版本 4 相关的过程信息，请参阅设置 NFS 服务。
如果同时使用 NFS 版本 3 和版本 4，则客户机尝试访问一个已经取消共享的文件系统时，服务器会以错误代码响应。但是，如果使用 NFS 版本 3，则服务器会保留客户机在取消共享文件系统之前所获取的所有锁定。这样，重新共享文件系统时，NFS 版本 3 客户机即可访问此文件系统，就好像从未取消共享此文件系统一样。
如果使用 NFS 版本 4，则取消共享文件系统时，将破坏此文件系统中任何已打开文件或文件锁定的所有状态。如果客户机尝试访问这些文件或锁定，则会收到一条错误消息。通常会将此错误消息作为 I/O 错误报告给应用程序。但是请注意，通过重新共享当前共享的文件系统来更改选项不会破坏服务器上的任何状态。
有关信息，请参阅NFS 版本 4 中的客户机恢复 或参见 unshare_nfs(1M) 手册页。
NFS 版本 4 服务器可创建并维护一个伪文件系统，此系统使客户机能够对服务器上所有导出的对象进行无缝访问。在 NFS 版本 4 之前，不存在伪文件系统。客户机会强制挂载每个共享服务器文件系统来进行访问。请参考以下示例。
图 6-2 服务器文件系统和客户机文件系统的视图
请注意，客户机无法看到 payroll 目录和 nfs4x 目录，因为这些目录未被导出，也没有通向导出目录。但是，客户机可以看到 local 目录，因为 local 是一个导出的目录。客户机还可看到 projects 目录，因为 projects 通向导出目录 nfs4。因此，未显式导出的服务器名称空间的部分内容会与伪文件系统桥接，该文件系统仅显示导出目录和那些通向服务器导出目录的目录。
伪文件系统是服务器创建的仅包含目录的结构。伪文件系统允许客户机浏览已导出文件系统的分层结构。因此，客户机的伪文件系统视图限制为仅显示通向已导出文件系统的路径。
以前的 NFS 版本不允许客户机在未挂载每个文件系统的情况下遍历服务器文件系统。但是，在 NFS 版本 4 中，服务器名称空间可进行以下操作：
将客户机的文件系统视图限制为仅显示通向服务器导出的目录。
使客户机能够对服务器导出目录进行无缝访问，而不要求客户机挂载每个底层文件系统。请参见前面的示例。但是请注意，某些操作系统可能会要求客户机挂载每个服务器文件系统。
由于与 POSIX 相关的原因，Oracle Solaris NFS 版本 4 客户机不会跨越服务器的文件系统边界。如果尝试进行这类操作，则客户机会使目录显示为空。要修正这种情况，必须针对服务器的每个文件系统执行挂载。
文件句柄是在服务器上创建的，其中包含唯一标识文件和目录的信息。在 NFS 版本 2 和 3 中，服务器会返回持久性文件句柄。这样，客户机即可确保服务器会生成始终引用同一文件的文件句柄。例如：
如果删除某个文件并将其替换为同名文件，则服务器会为新文件生成新的文件句柄。如果客户机使用旧的文件句柄，则服务器会返回一条错误消息，说明此文件句柄已过时。
如果重命名文件，则文件句柄将保持不变。
如果必须重新引导服务器，则文件句柄将保持不变。
因此，当服务器从客户机收到包括文件句柄的请求时，解决方案会非常简单，并且文件句柄会始终引用正确的文件。
这种为 NFS 操作标识文件和目录的方法对大多数基于 UNIX 的服务器都很有效。但是，此方法不能在依赖其他标识方法（如文件的路径名）的服务器上实施。为了解决此问题，NFS 版本 4 协议允许服务器声明其文件句柄为可变句柄。这样，即可更改文件句柄。如果文件句柄确实已更改，则客户机必须找到新的文件句柄。
与 NFS 版本 2 和 3 一样，Oracle Solaris NFS 版本 4 服务器始终提供持久性文件句柄。但是，访问非 Solaris NFS 版本 4 服务器的 Oracle Solaris NFS 版本 4 客户机必须在服务器使用可变文件句柄时支持这些句柄。具体来说，当服务器通知客户机文件句柄可变时，客户机必须高速缓存路径名和文件句柄之间的映射。客户机会一直使用可变文件句柄，直到句柄过期为止。文件句柄过期后，客户机会执行以下操作：
刷新引用此文件句柄的高速缓存信息
搜索此文件的新文件句柄
重试此操作
注 - 服务器会始终通知客户机哪些文件句柄为持久性句柄，哪些文件句柄为可变句柄。
可变文件句柄可能会由于以下任一原因过期：
关闭文件
迁移文件句柄的文件系统
客户机重命名文件
服务器重新引导
请注意，如果客户机无法找到新的文件句柄，则会在 syslog 文件中放入一条错误消息。进一步尝试访问此文件会失败，并显示 I/O 错误。
NFS 版本 4 协议为有状态协议。如果客户机和服务器都保留有关以下内容的当前信息，协议即为有状态协议。
打开的文件
文件锁定
出现故障（如服务器崩溃）时，客户机和服务器会协同工作，重新建立故障前已存在的打开状态和锁定状态。
服务器崩溃并重新引导时，会丢失其状态。客户机检测到服务器已经重新引导后，将启动帮助服务器重建其状态的进程。此进程称为客户机恢复，因为由客户机引导此进程。
客户机发现服务器已经重新引导后，便会立即暂停其当前活动并启动客户机恢复进程。启动恢复进程时，系统错误日志 /var/adm/messages 中会显示如下消息。
NOTICE: Starting recovery server basil.example.company.com
在恢复进程中，客户机会向服务器发送有关客户机以前状态的信息。但是请注意，在此期间，客户机不会向服务器发送任何新请求。任何打开文件或设置文件锁定的新请求都必须等到服务器完成其恢复期之后才能继续进行。
客户机恢复进程完成时，系统错误日志 /var/adm/messages 中会显示以下消息。
NOTICE: Recovery done for server basil.example.company.com
现在，客户机已经成功地将其状态信息发送给服务器。不过，尽管此客户机已经完成了此进程，但是其他客户机可能尚未完成将其状态信息发送给服务器这一进程。因此，在一段时间内，服务器不会接受任何打开或锁定请求。指定这段时间（称为宽延期）目的在于允许所有客户机完成其恢复。
在宽延期内，如果客户机尝试打开任何新文件或建立任何新锁定，服务器都会拒绝请求并显示 GRACE 错误代码。收到此错误后，客户机必须等到宽延期结束，然后才能向服务器重新发送请求。在宽延期内，会显示以下消息。
NFS server recovering
请注意，在宽延期内，可以继续执行不打开文件或不设置文件锁定的命令。例如，ls 和 cd 命令不会打开文件或设置文件锁定。因此，不会暂停执行这些命令。但是，cat 之类可打开文件的命令会暂停执行，直到宽延期结束为止。
宽延期结束后，会显示以下消息。
NFS server recovery ok.
现在，客户机即可向服务器发送新的打开和锁定请求。
客户机恢复会因为各种原因而失败。例如，如果服务器重新引导后存在网络分区，则客户机可能无法在宽延期结束之前与服务器重新建立其状态。宽延期结束后，服务器不允许客户机重新建立其状态，因为新的状态操作可能会产生冲突。例如，新的文件锁定可能会与客户机尝试恢复的旧的文件锁定发生冲突。发生这种情况时，服务器会将 NO_GRACE 错误代码返回到客户机。
如果恢复某个特定文件的打开操作失败，客户机会将此文件标记为不可用，并显示以下消息。
WARNING: The following NFS file could not be recovered and was marked dead (can't reopen: NFS status 70): file : filename
请注意，数字 70 仅是一个示例。
如果在恢复过程中重新建立文件锁定失败，则会显示以下错误消息。
NOTICE: nfs4_send_siglost: pid PROCESS-ID lost lock on server SERVER-NAME
在这种情况下，会向进程发送 SIGLOST 信号。SIGLOST 信号的缺省操作是终止此进程。
要从此状态恢复，必须重新启动所有在失败时打开文件的应用程序。请注意，可能会出现以下情况。
一些没有重新打开文件的进程可能会收到 I/O 错误消息。
在恢复失败之后已重新打开文件或执行打开操作的其他进程可顺利访问文件。
因此，一些进程可以访问其他进程无法访问的特定文件。
NFS 版本 4 协议提供了几种文件共享模式，客户机可以使用这些模式控制其他客户机对文件的访问。客户机可以指定以下内容：
DENY_NONE 模式，用于允许其他客户机对文件进行读写访问。
DENY_READ 模式，用于拒绝其他客户机对文件进行读取访问。
DENY_WRITE 模式，用于拒绝其他客户机对文件进行写入访问。
DENY_BOTH 模式，用于拒绝其他客户机对文件进行读写访问。
Oracle Solaris NFS 版本 4 服务器完全实现了这些文件共享模式。因此，如果客户机尝试打开文件的方式与当前共享模式冲突，则服务器会通过使操作失败来拒绝此尝试。如果这类尝试在打开或创建操作开始时失败，则 NFS 版本 4 客户机会收到一条协议错误消息。此错误会映射为应用程序错误 EACCES。
尽管此协议提供了几种共享模式，但目前 Oracle Solaris 中的打开操作不提供多种共享模式。打开文件时，Oracle Solaris NFS 版本 4 客户机只能使用 DENY_NONE 模式。
另外，尽管 fcntl 系统调用使用 F_SHARE 命令来控制文件共享，但是 fcntl 命令无法在 NFS 版本 4 中正常实现。如果在 NFS 版本 4 客户机上使用这些 fcntl 命令，则客户机会向应用程序返回一条 EAGAIN 错误消息。
NFS 版本 4 为委托同时提供客户机支持和服务器支持。委托是服务器用于将文件管理委托给客户机的一种技术。例如，服务器可以授予客户机读取委托或写入委托。读取委托可以同时授予多台客户机，因为这些读取委托不会彼此冲突。写入委托只能授予一台客户机，因为写入委托会与其他任何客户机进行的任何文件访问相冲突。虽然客户机拥有写入委托，但是它不会向服务器发送各种操作，因为客户机保证具有对文件的独占访问权限。同样，客户机在拥有读取委托时也不会向服务器发送各种操作。这是因为服务器保证任何客户机都不能以写入模式打开文件。通过委托，可显著减少服务器和客户机之间针对被委托文件的交互。因此，可降低网络通信流量，并且提高客户机和服务器的性能。但是请注意，性能提高的程度取决于应用程序使用的文件交互的类型以及网络和服务器的拥塞量。
是否授予委托完全由服务器决定。客户机不会请求委托。服务器可根据文件的访问模式来决定是否授予委托。如果几台不同的客户机最近以写入模式访问了文件，则服务器可能不会授予委托。原因是此访问模式表明将来可能会发生冲突。
当客户机访问文件的方式与当前授予此文件的委托不一致时，便会发生冲突。例如，如果一台客户机拥有对文件的写入委托，同时另一台客户机打开此文件来进行读取或写入访问，则服务器会撤销第一台客户机的写入委托。同样，如果一台客户机拥有读取委托，同时另一台客户机打开同一个文件进行写入，则服务器会撤销读取委托。请注意，在这两种情况下都不会将委托授予第二台客户机，因为此时存在冲突。发生冲突时，服务器会使用回调机制来联系当前拥有委托的客户机。收到此回调后，客户机会向服务器发送文件的更新状态并返回委托。如果客户机无法对重新调用做出响应，则服务器会撤销委托。在此类情况下，服务器会拒绝客户机对此文件进行的所有操作，客户机将已请求的操作报告为失败。通常，这些失败会作为 I/O 错误报告给应用程序。要从这些错误中恢复，必须关闭文件，然后再重新打开。当客户机和服务器之间存在网络分区并且客户机拥有委托时，撤销委托会失败。
请注意，一台服务器不能解决对其他服务器上存储的文件的访问冲突。因此，NFS 服务器仅解决它自己存储的文件的冲突。此外，要响应由运行各种 NFS 版本的客户机导致的冲突，NFS 服务器只能对运行 NFS 版本 4 的客户机启动重新调用。NFS 服务器不能对运行早期 NFS 版本的客户机启动重新调用。
检测冲突的进程会有所变化。例如，与 NFS 版本 4 不同，因为版本 2 和版本 3 不包括打开过程，所以仅会在客户机尝试读取、写入或锁定文件之后检测冲突。服务器对这些冲突的响应也会有所不同。例如：
对于 NFS 版本 3，服务器会返回 JUKEBOX 错误消息，这会导致客户机停止访问请求并稍后重试。客户机会输出消息 File unavailable。
对于 NFS 版本 2，因为不存在与 JUKEBOX 错误消息等效的消息，所以服务器不做任何响应，这会导致客户机等待然后再重试。客户机会输出消息 NFS server not responding。
解决了委托冲突之后，便不会存在这些情况。
缺省情况下，会启用服务器委托。可以通过将 server_delegation 参数设置为 none 来禁用委托。有关过程信息，请参阅如何在服务器上选择不同版本的 NFS。
客户机委托不需要任何关键字。NFS 版本 4 回调守护进程 nfs4cbd 在客户机上提供回调服务。只要启用对 NFS 版本 4 的挂载，此守护进程就会自动启动。缺省情况下，客户机会针对 /etc/netconfig 系统文件中列出的所有 Internet 传输向服务器提供必需的回调信息。请注意，如果在客户机上启用了 IPv6 并且可以确定客户机名称的 IPv6 地址，则回调守护进程可接受 IPv6 连接。
回调守护进程使用临时的程序编号以及动态指定的端口号。此信息提供给服务器，服务器会在授予任何委托之前测试回调路径。如果回调路径测试不成功，则服务器不会授予委托，这是唯一可从外部看到的行为。
请注意，因为回调信息嵌在 NFS 版本 4 请求中，所以服务器不能通过使用网络地址转换 (Network Address Translation, NAT) 的设备来联系客户机。另外，回调守护进程还会使用动态端口号。因此，即使防火墙在端口 2049 上启用了正常的 NFS 流量，服务器可能仍然无法遍历防火墙。在此类情况下，服务器不会授予委托。
访问控制列表 (access control list, ACL) 通过使文件的所有者可以为文件所有者、组以及其他特定用户和组定义文件权限来提供更好的文件安全性。在 ZFS 文件系统上，ACL 是使用 chmod 命令在服务器和客户机上设置的。对于 UFS 文件系统，请使用 setfacl 命令。有关更多信息，请参见 chmod(1) 和 setfacl(1) 手册页。在 NFS 版本 4 中，ID 映射器 nfsmapid 用于将服务器上的 ACL 项中的用户 ID 或组 ID 映射为客户机上的 ACL 项中的用户 ID 或组 ID。相反的映射也能实现。ACL 项中的用户 ID 和组 ID 必须同时存在于客户机和服务器上。
以下情况可能导致 ID 映射失败：
如果存在于服务器上 ACL 项中的用户或组不能映射为客户机上的有效用户或组，则该用户可以读取 ACL，但某些用户或组将显示为“未知”。
例如，发出 ls -lv 或 ls - lV 命令时，某些 ACL 项会将组或用户显示为“未知”。有关此命令的更多信息，请参见 ls(1) 手册页。
如果不能将客户机上设置的任何 ACL 项中的用户 ID 或组 ID 映射为服务器上的有效用户 ID 或组 ID，则 setfacl 或 chmod 命令可能会失败，并返回 Permission denied 错误消息。
如果客户机和服务器的 nfsmapid_domain 值不匹配，则 ID 映射将失败。有关更多信息，请参见 nfsmapid 守护进程。
为避免 ID 映射问题，请执行以下操作：
确保 nfsmapid_domain 的值已正确设置。
确保 ACL 项中的所有用户和组 ID 同时存在于 NFS 版本 4 客户机和服务器上。
要确定是否有无法在服务器或客户机上映射的用户或组，请使用以下脚本：
#! /usr/sbin/dtrace -Fs
sdt:::nfs4-acl-nobody
{
printf("validate_idmapping: (%s) in the ACL could not be mapped!",
stringof(arg0));
}
请参见以下内容：
启动过程中，还会协商传输协议。缺省情况下，将选择客户机和服务器同时支持的第一个面向连接的传输。如果此选择未成功，则使用第一个可用的无连接传输协议。/etc/netconfig 中列出了系统支持的传输协议。TCP 是该发行版支持的面向连接的传输协议。UDP 是无连接传输协议。
如果 NFS 协议版本和传输协议都是通过协商确定的，则 NFS 协议版本优先于传输协议。使用 UDP 的 NFS 版本 3 协议比使用 TCP 的 NFS 版本 2 协议具有更高的优先级。可以使用 mount 命令手动选择 NFS 协议版本和传输协议。请参见 mount_nfs(1M) 手册页。在大多数情况下，允许协商选择最佳选项。
文件传输大小确定在客户机与服务器之间传输数据时使用的缓冲区的大小。一般情况下，最好使用较大的传输大小。NFS 版本 3 协议的传输大小没有限制。如果需要，客户机可以在挂载时规定较小的传输大小，但是在大多数情况下，此规定是没有必要的。
系统不会与使用 NFS 版本 2 协议的系统协商传输大小。在这种情况下，最大的传输大小将设置为 8 KB。
可以在 mount 命令中使用 -rsize 和 -wsize 选项来手动设置传输大小。对于某些 PC 客户机，可能需要减小传输大小。另外，如果将 NFS 服务器配置为使用较大的传输大小，则还可以增加传输大小。
注 - 从 Solaris 10 发行版开始，放宽了对线路传输大小的限制。传输大小取决于底层传输的能力。例如，对于 UDP，NFS 的传输限制仍然是 32 KB。但是，因为 TCP 是流协议，不受 UDP 的数据报限制，因此通过 TCP 的最大传输大小已经增加到 1 MB。
以下说明适用于 NFS 版本 3 挂载。NFS 版本 4 挂载过程既不包括端口映射服务，也不包括 MOUNT 协议。
客户机需要从服务器挂载文件系统时，客户机必须从服务器获取文件句柄。文件句柄必须与文件系统对应。此过程需要在客户机与服务器之间处理多项事务。在本示例中，客户机正在尝试从服务器挂载 /home/terry。此事务的 snoop 跟踪如下。
client -> server PORTMAP C GETPORT prog=100005 (MOUNT) vers=3 proto=UDP server -> client PORTMAP R GETPORT port=33492 client -> server MOUNT3 C Null server -> client MOUNT3 R Null client -> server MOUNT3 C Mount /export/home9/terry server -> client MOUNT3 R Mount OK FH=9000 Auth=unix client -> server PORTMAP C GETPORT prog=100003 (NFS) vers=3 proto=TCP server -> client PORTMAP R GETPORT port=2049 client -> server NFS C NULL3 server -> client NFS R NULL3 client -> server NFS C FSINFO3 FH=9000 server -> client NFS R FSINFO3 OK client -> server NFS C GETATTR3 FH=9000 server -> client NFS R GETATTR3 OK
在此跟踪中，客户机首先从 NFS 服务器上的端口映射服务请求挂载端口号。客户机收到挂载端口号 (33492) 后，会使用该端口号测试服务器上服务的可用性。客户机确定服务正在该端口号上运行后，便会请求挂载。服务器对此请求做出响应时，服务器中会包含正在挂载的文件系统 (9000) 的文件句柄。随后，客户机将针对 NFS 端口号发送请求。客户机收到来自服务器的端口号后，客户机便会测试 NFS 服务 (nfsd) 的可用性。此外，客户机还会请求有关使用该文件句柄的文件系统的 NFS 信息。
在以下跟踪中，客户机正在使用 public 选项挂载文件系统。
client -> server NFS C LOOKUP3 FH=0000 /export/home9/terry server -> client NFS R LOOKUP3 OK FH=9000 client -> server NFS C FSINFO3 FH=9000 server -> client NFS R FSINFO3 OK client -> server NFS C GETATTR3 FH=9000 server -> client NFS R GETATTR3 OK
通过使用缺省的公共文件句柄（即 0000），系统将跳过所有要从端口映射服务获取信息并要确定 NFS 端口号的事务。
使用 -public 选项可能会造成导致挂载失败的条件。添加 NFS URL 也可产生导致失败的情形。以下列表介绍了如何使用这些选项挂载文件系统的具体细节。
带有 NFS URL 的 public 选项－强制使用公共文件句柄。如果系统不支持公共文件句柄，则挂载将失败。
带有常规路径的 public 选项－强制使用公共文件句柄。如果系统不支持公共文件句柄，则挂载将失败。
仅 NFS URL－使用公共文件句柄（如果在 NFS 服务器上启用了此文件句柄）。如果在使用公共文件句柄时挂载失败，则尝试使用 MOUNT 协议进行挂载。
仅常规路径－不使用公共文件句柄，而使用 MOUNT 协议。
通过使用客户端故障转移，NFS 客户机可以识别使相同数据可用的多台服务器，并且在当前服务器不可用时可以切换到备用服务器。如果发生以下情况之一，则文件系统就会变得不可用。
文件系统连接到的服务器崩溃
服务器过载
出现网络故障
在上述情况下执行的故障转移通常对用户是透明的。因此，故障转移可以随时进行，而不会中断客户机上正在运行的进程。
故障转移要求采用只读方式挂载文件系统。文件系统必须相同，故障转移才能成功进行。有关使文件系统相同的原因说明，请参见什么是复制的文件系统？。静态文件系统或不常更改的文件系统是故障转移的最佳候选系统。
您不能对同一 NFS 挂载同时使用 CacheFS 和客户端故障转移。系统针对每个 CacheFS 文件系统存储了额外信息。故障转移期间不能更新此信息，因此挂载文件系统时只能使用这两个功能之一。
需要为每个文件系统建立的副本数目取决于许多因素。理想的情况是，应该至少具有两台服务器。每台服务器都应该支持多个子网。此设置比每个子网中具有唯一一台服务器更好。该过程要求检查列出的每台服务器。因此，列出的服务器越多，每个挂载的速度就越慢。
要完全领会该过程，需要了解两个术语。
故障转移－从支持复制的文件系统的服务器列表中选择服务器的过程。通常，使用已排序列表中的下一台服务器，除非该服务器无法做出响应。
重映射－使用新的服务器。在正常使用中，客户机在远程文件系统上存储每个活动文件的路径名。在重映射期间，系统将评估这些路径名以在新的服务器上找到这些文件。
为了实现故障转移，当其中每个文件大小都相同且文件大小或文件类型与原始文件系统相同时，可以将这样的文件系统称为副本。不考虑权限、创建日期和其他文件属性。如果文件大小或文件类型不同，则重映射将失败，且该过程将挂起，直到旧的服务器可用为止。在 NFS 版本 4 中，该行为是不同的。请参见NFS 版本 4 中的客户端故障转移。
可以使用 rsync、cpio 或其他文件传输机制来维护复制的文件系统。由于更新复制的文件系统会导致不一致，因此为实现最佳效果，应考虑以下预防措施：
在安装新版本的文件之前，先重命名旧版本的文件
在夜间运行更新，此时客户机使用率较低
使更新始终很小
将副本数目降到最少
某些软件包需要对文件进行读取锁定。为防止这些产品被破坏，允许对只读文件系统进行读取锁定，但是只有客户端可查看读取锁定。这些锁定在重映射后不会发生变化，因为服务器不“知晓”有关锁定的信息。由于文件不会发生更改，因此您不需要在服务器端锁定文件。
在 NFS 版本 4 中，如果由于文件大小不同或文件类型不同而无法建立副本，将发生以下情况。
文件被标记为停用。
输出警告信息。
应用程序收到系统调用故障信息。
注 - 如果重新启动应用程序并再次尝试访问该文件，则应该会成功。
在 NFS 版本 4 中，您不会再收到因目录大小不同而导致的复制错误。在以前的 NFS 版本中，这种情况被视为错误且会阻碍重映射过程。
此外，在 NFS 版本 4 中，如果目录读取操作未成功，则将由列出的下一台服务器执行该操作。在以前的 NFS 版本中，未成功的读取操作将导致重映射失败且挂起该过程，直到原始服务器可用为止。
操作系统支持大于 2 GB 的文件。缺省情况下，UFS 文件系统是使用 -largefiles 选项挂载的，以便支持此新功能。如有需要，请参见如何在 NFS 服务器上禁用大文件以获取说明。
如果服务器的文件系统是使用 -largefiles 选项挂载的，则客户机可以访问大文件，而不需要进行更改。但是，并非所有命令都可以处理这些大文件。有关可处理大文件的命令的列表，请参见 largefile(5)。不能支持具有大文件扩展的 NFS 版本 3 协议的客户机不能访问任何大文件。
NFS 服务器日志记录提供 NFS 读写记录，以及修改文件系统的操作记录。此数据可用于跟踪对信息的访问。此外，记录可以提供用于度量信息重要性的定量方法。
访问启用了日志记录的文件系统时，内核会将原始数据写入缓冲区文件。此数据包括以下内容：
时间戳
客户机 IP 地址
申请者的 UID
正在访问的文件或目录对象的文件句柄
已执行操作的类型
nfslogd 守护进程会将此原始数据转换为日志文件中存储的 ASCII 记录。转换期间，IP 地址将被修改为主机名，UID 将被修改为登录名（如果已启用的名称服务可以找到匹配项）。文件句柄也被转换为路径名。为了完成转换，该守护进程将跟踪文件句柄并在单独的文件句柄到路径表中存储信息。这样，每次访问文件句柄时，就不必再次识别路径了。由于在 nfslogd 关闭时不会在文件句柄到路径表中对映射进行任何更改，因此必须始终使该守护进程保持运行状态。
注 - NFS 版本 4 不支持服务器日志记录。
WebNFS 服务通过使用公共文件句柄使目录中的文件可用于客户机。文件句柄是内核生成的地址，可标识 NFS 客户机的文件。公共文件句柄具有预定义的值，因此服务器不需要为客户机生成文件句柄。通过删除 MOUNT 协议，可以使用此预定义文件句柄来减少网络通信流量。此功能还会加速客户机的进程处理。
缺省情况下，系统将在根文件系统上建立 NFS 服务器上的公共文件句柄。此缺省设置为 WebNFS 提供了对已在服务器上具有挂载权限的任何客户机的访问权限。通过使用 share 命令，可以更改公共文件句柄以指向任意文件系统。
当客户机具有与文件系统对应的文件句柄时，将会运行 LOOKUP，以确定要访问的文件的文件句柄。NFS 协议一次只允许评估一个路径名组件。目录分层结构的每个附加层都需要运行一次 LOOKUP。当 LOOKUP 与公共文件句柄有关时，WebNFS 服务器可以使用单个多组件查找事务来评估整个路径名。多组件查找使 WebNFS 服务器可以将该文件句柄传送到所需的文件，而不针对路径名中的每一目录层交换文件句柄。
此外，NFS 客户机还可以通过单一 TCP 连接启动并发下载。此连接提供快速访问，而不会在服务器上产生因设置多个连接而导致的负载增加。尽管 Web 浏览器应用程序支持件并发下载多个文件，但每个文件都有各自的连接。通过使用某个连接，WebNFS 软件可以减少服务器上的开销。
如果路径名中的最终组件是指向其他文件系统的符号链接，则客户机可以访问文件（如果客户机已具备通过正常的 NFS 活动进行访问的权限）。
通常，NFS URL 是相对于公共文件句柄进行评估的。通过在路径的开始位置添加一个附加的斜杠，可以更改评估，使其与服务器的根文件系统有关。在本示例中，如果已在 /export/ftp 文件系统上建立了公共文件句柄，则这两个 NFS URL 是等效的。
nfs://server/junk nfs://server//export/ftp/junk
注 - NFS 版本 4 协议优先于 WebNFS 服务。NFS 版本 4 完全集成了已添加到 MOUNT 协议和 WebNFS 服务中的所有安全协商。
NFS 服务包括一个协议，该协议使 WebNFS 客户机可以与 WebNFS 服务器协商选定的安全机制。新协议使用安全协商多组件查找功能，该功能是对早期版本的 WebNFS 协议中使用的多组件查找功能的扩展。
WebNFS 客户机通过使用公共文件句柄来发出常规多组件查找请求，进而启动进程。由于客户机不知道服务器保护路径的方式，因此将使用缺省的安全机制。如果缺省的安全机制不够，则服务器将回复 AUTH_TOOWEAK 错误。此回复表明缺省机制无效。客户机需要使用更强大的缺省机制。
客户机收到 AUTH_TOOWEAK 错误后，会向服务器发送请求，以确定需要哪种安全机制。如果请求成功，则服务器将使用指定路径所需的安全机制数组进行响应。根据安全机制数组的大小，客户机可能必须发出更多请求才能获取完整的数组。如果服务器不支持 WebNFS 安全协商，则请求将失败。
请求成功后，WebNFS 客户机将从其支持的数组中选择第一个安全机制。然后，该客户机将使用选定的安全机制发出常规多组件查找请求，以获取文件句柄。所有后续的 NFS 请求都是使用选定安全机制和文件句柄发出的。
注 - NFS 版本 4 协议优先于 WebNFS 服务。NFS 版本 4 完全集成了已添加到 MOUNT 协议和 WebNFS 服务中的所有安全协商。
使用 HTTP 的 Web 站点可以提供的多项功能不受 WebNFS 软件的支持。这些差异源自 NFS 服务器仅发送文件这一事实，因此必须在客户机上执行所有的特殊处理。如果需要为 WebNFS 和 HTTP 访问配置一个 Web 站点，则应考虑以下问题：
NFS 浏览不运行 CGI 脚本。因此，带有活动 Web 站点（该站点使用许多 CGI 脚本）的文件系统可能不适用于 NFS 浏览。
浏览器可能会启动不同查看器来处理不同文件格式的文件。如果可以通过文件名来确定文件类型，则通过 NFS URL 访问这些文件便可启动外部查看器。使用 NFS URL 时，浏览器应该识别标准 MIME 类型的任何文件扩展名。WebNFS 软件不会为了确定文件类型而在文件内部进行检查。因此，确定文件类型的唯一方法就是通过文件扩展名。
NFS 浏览不能利用服务器端图像映射（可单击的图像）。但是，NFS 浏览可以利用客户端图像映射（可单击的图像），因为 URL 是使用位置定义的。不需要来自文档服务器的任何其他响应。
NFS 环境是用于在具有不同计算机体系结构和操作系统的网络中共享文件系统的一种强大而便捷的方式。但是，这些通过 NFS 操作使文件系统共享变得非常便利的功能同时还会造成一些安全问题。以前，大多数 NFS 实现使用 UNIX（或 AUTH_SYS）验证，但是也可以使用更强大的验证方法（如 AUTH_DH）。使用 UNIX 验证时，NFS 服务器通过验证发出请求的计算机（而不是用户）来验证文件请求。因此，客户机用户可以运行 su 并模仿文件的所有者。如果使用 DH 验证，则 NFS 服务器将验证用户，这使得此类模仿非常困难。
凭借超级用户访问权限和对网络编程的了解，任何人都可以将任意数据引入网络，并从网络中提取任何数据。最危险的攻击就是涉及数据引入的攻击。例如，通过生成适当的包或通过记录“会话”并稍后重放来模仿用户。这些攻击将影响数据的完整性。涉及被动窃听（仅侦听网络通信流量，而不模仿任何人）的攻击不是很危险，因为不会损害数据完整性。用户可通过对通过网络发送的数据进行加密来保护敏感信息的保密性。
解决网络安全问题的常见方法是针对每个应用程序都单独制定解决方案。更好的方法是在涉及所有应用程序的级别上实现标准验证系统。
Oracle Solaris 操作系统包括位于远程过程调用 (remote procedure call, RPC) 级别的验证系统（NFS 操作所依赖的机制）。此系统（称为安全 RPC）可以大大提高网络环境的安全性，并能为 NFS 系统等服务提供附加安全性。当 NFS 系统使用由安全 RPC 提供的功能时，该系统称为安全 NFS 系统。
安全 RPC 是安全 NFS 系统的基础。安全 RPC 的目标是建立至少与分时系统一样安全的系统。在分时系统中，所有用户共享单台计算机。分时系统通过登录口令验证用户。使用数据加密标准 (Data Encryption Standard, DES) 验证，可以完成相同的验证过程。用户可以登录任何远程计算机，就像登录本地终端一样。用户的登录口令是其网络安全的保证。在分时环境中，系统管理员出于道义不会更改口令以模仿某人。在安全 RPC 中，网络管理员是可信的，不会更改存储有公钥的数据库中的项。
为了解 RPC 验证系统，您需要熟悉两个术语：凭证和检验器。以 ID 证件为例，凭证就是标识用户的具体内容：姓名、地址和生日。检验器就是附加到证件上的照片。通过对照携带该证件的人员检查该证件上的照片，可以确定该证件未被盗用。在 RPC 中，客户机进程会通过每个 RPC 请求将凭证和检验器发送到服务器。服务器仅发回检验器，因为客户机已经“知晓”服务器的凭证。
RPC 验证是开放式的，这表示可以在其中插入各种验证系统，如 UNIX、DH 和 KERB。
当网络服务使用 UNIX 验证时，凭证包含客户机的主机名、UID、GID 和组访问列表。但是，检验器不包含任何内容。由于不存在检验器，因此超级用户可以使用如 su 等命令来伪造相应的凭证。UNIX 验证的另一个问题是 UNIX 验证将认为网络中的所有计算机都是 UNIX 计算机。UNIX 验证在应用于异构网络中的其他操作系统时将会中断。
为克服 UNIX 验证问题，安全 RPC 将使用 DH 验证。
DH 验证使用数据加密标准 (Data Encryption Standard, DES) 和 Diffie-Hellman 公钥密码学来验证网络中的用户和计算机。DES 是标准加密机制。Diffie-Hellman 公钥密码学是包含两个密钥的密码系统：一个公钥和一个私钥。公钥和私钥存储在名称空间中。NIS 将密钥存储在公钥映射中。这些映射包含所有潜在用户的公钥和私钥。有关如何设置映射的更多信息，请参见《Oracle Solaris Administration: Naming and Directory Services》。
DH 验证的安全性依赖于发件人加密当前时间的能力，随后收件人可以对该时间进行解密，并对照自己的时钟进行检查。时间戳是使用 DES 进行加密的。使此方案正常工作的要求如下所示：
两个代理必须就当前时间达成一致。
发件人和收件人必须使用相同的加密密钥。
如果网络运行时间同步程序，则系统将自动同步客户机和服务器上的时间。如果时间同步程序不可用，则可以使用服务器的时间（而不是网络时间）来计算时间戳。客户机在启动 RPC 会话之前会向服务器询问时间，然后计算自己的时钟与服务器时钟之间的时间差。此差异用于在计算时间戳时补偿客户机的时钟。如果客户机与服务器的时钟未同步，则服务器将开始拒绝客户机的请求。客户机上的 DH 验证系统将与服务器重新进行同步。
客户机和服务器使用同一个加密密钥，具体方法是：生成一个随机的对话密钥（也称为会话密钥），并使用公钥密码学推导公用密钥。公用密钥是只有客户机和服务器才能推导的密钥。对话密钥用于加密和解密客户机的时间戳。公用密钥用于加密和解密对话密钥。
Kerberos 是 MIT 开发的验证系统。Kerberos 提供各种加密类型，包括 DES。Kerberos 支持不再作为安全 RPC 的一部分来提供，但是此发行版中包含服务器端和客户端实现。有关 Kerberos 验证实现的更多信息，请参见《Oracle Solaris 管理：安全服务》中的第 19 章 "Kerberos 服务介绍"。
如果在周围无人的情况下服务器发生崩溃（例如，在断电后），则存储在系统中的所有私钥都将被删除。此时，所有进程都不能访问安全网络服务或挂载 NFS 文件系统。重新引导期间的重要进程通常以 root 身份运行。因此，如果已妥善存储了超级用户的私钥，且没有人可以键入该私钥的解密口令，则这些进程可以正常工作。keylogin -r 允许 root 在 keyserv 可读取的 /etc/.rootkey 中存储明文形式的私钥。
某些系统以单用户模式引导，控制台上会显示超级用户登录 shell，但不显示口令提示。在这类情况下，物理安全性是非常必要的。
无盘计算机引导并不是绝对安全的。他人可以模拟引导服务器并引导不正当的内核，例如，在远程计算机上记录您的私钥。安全 NFS 系统仅在内核和密钥服务器都处于运行状态之后，才会提供保护。否则，无法验证引导服务器提供的回复。此限制可能会是一个严重的问题，不过，只有使用内核源代码的复杂攻击才能利用此限制。此外，犯罪行为会留下证据。如果轮询网络查找引导服务器，则会发现不正当引导服务器的位置。
大多数 setuid 程序都归 root 所有。如果 root 的私钥存储在 /etc/.rootkey 中，则这些程序会正常工作。但是，如果用户拥有 setuid 程序，则 setuid 程序可能有时无法正常工作。例如，假设 setuid 程序归 dave 所有，并且在引导计算机之后 dave 未登录计算机。在这种情况下，该程序可能无法访问安全网络服务。
如果使用 login、rlogin 或 telnet 登录远程计算机并且使用 keylogin 获取访问权限，则可以访问您的帐户。原因是您的私钥会被传递给该计算机的密钥服务器，该服务器随后会存储您的私钥。只有在不信任远程计算机的情况下才考虑使用此过程。但是，如果存在疑问，请勿在远程计算机要求口令时登录远程计算机。请使用 NFS 环境来挂载与远程计算机共享的文件系统。此外，也可以使用 keylogout 从密钥服务器中删除私钥。
如果使用 -o sec=dh 选项共享起始目录，则远程登录可能会有问题。如果未将 /etc/hosts.equiv 或 ~/.rhosts 文件设置为提示输入口令，将成功登录。但是，用户不能访问其起始目录，因为没有在本地进行验证。如果系统提示用户输入口令，则当该口令与网络口令匹配时，用户有权访问其起始目录。
|