 |
» |
|
|
|
This section discusses the new features that NFS supports on
systems running HP-UX 11i v3. NFS Version 4 Protocol (NFSv4) | |
NFSv4 is an IETF standard protocol that provides the following
features: Single Protocol In NFSv4, MOUNT, Network Lock Manager, and the ACL protocols are
merged into the NFS protocol. Merging all these protocols into a single
protocol enables you to configure firewalls easily. All NFSv4 requests
are now sent to one port. In earlier versions of NFS, separate protocols were required
to mount a filesystem, monitor a remote client or a server, lock or
unlock a file, and unmount a filesystem. Configuring a firewall to
permit access to specific ports that the protocols listened on was
difficult (or impossible) if the client or the server was part of
a firewalled network. COMPOUND Procedure The COMPOUND procedure decreases transport and security overhead,
because of fewer over-the-wire trips between the client and the server.
This feature is transparent to the user. NFSv4 uses the COMPOUND RPC procedure to build sequence of requests
into a single RPC. All RPC requests are classified as either NULL
or COMPOUND. All requests that are part of the COMPOUND procedure
are known as operations. An operation is a filesystem action that
forms part of a COMPOUND procedure. NFSv4 currently defines 38 operations. The server evaluates and processes operations sequentially.
If an error is encountered, it is returned by the server for the entire
procedure up to the first operation that causes the error. The NFSv4 protocol design enables NFS developers to add new
operations that are based on IETF specifications. Delegation In NFSv4,
the server can delegate certain responsibilities to the client. Delegation
enables a client to locally service operations, such as OPEN, CLOSE,
LOCK, LOCKU, READ, and WRITE, without immediate interactions with
the server. The server grants either a READ or a WRITE delegation to a client
at OPEN. After the delegation is granted, the client can perform all
operations locally. Delegations can be revoked by the server. If another client
requests incompatible access to the file, the server revokes the delegation.
Once the delegation is returned, the other client can access the file. | | | |  | WARNING! Delegations are disabled, by default. If delegations are enabled,
delegations are only supported by applications that access the delegated
files remotely. Local access is not protected until a future release
of HP-UX. Allowing local access and enabling delegation on a file
can corrupt it. | | | | |
Built-In Security In NFSv4, the built-in security feature enables the RPC layer to
use different security mechanisms. You can specify a different security
policy for each filesystem. The server and the clients can negotiate
supported security flavors on a per filesystem basis. NFSv4 uses the RPCSEC_GSS framework for authentication, integrity,
and privacy. This framework enables the RPC protocols to access the
Generic Security Services Application Programming Interface (GSS-API). The RPCSEC_GSS/GSS-API security framework is extensible. However,
the new security flavors, whenever added, must conform to the GSS-API
model. For information on how to secure your systems, see “Secure Sharing of Directories ”. File Handle Types File handles are created on the server and contain information that
uniquely identify files and directories. Following are the different
file handle types: ROOT The ROOT file handle represents the
conceptual root of the file system namespace on an NFS server. The
NFS client starts with the ROOT file handle by using the PUTROOTFH
operation. This operation instructs the server to set the current
file handle to the root of the server file tree. If you use the PUTROOTFH
operation, the client can traverse the entire file tree using the
LOOKUP operation. Persistent The persistent file handle
is an assigned fixed value for the lifetime of the filesystem object
that it refers to. When the server creates the file handle for a filesystem
object, the server must accept the same file handle for the lifetime
of the object. The persistent file handle persists across server reboots
and filesystem migrations.
Namespace Changes The namespace describes the set of available files that are arranged
in a hierarchy. When a server shares files, it typically shares only
a portion of its namespace. In NFSv4, the shared namespace of the
server forms a single hierarchy. When a server shares separate filesystems as a disconnected
portion of its namespace, the server creates a pseudo filesystem to
bridge the unshared portions of the namespace. This enables a client,
which has been enabled to traverse remote filesystems without having
to mount them, to access the shared points from a single common root. The NFSv4 specification does not require a client to traverse
the NFS server’s namespace. HP-UX does not support this feature
for this release. For example, a server shares /opt/dce, /opt/hpsmh, and /doc/archives directories.
In this list, the shared list hierarchy is not connected. The /doc/archives directory is neither a parent nor a child
directory of /opt. Figure 1-1 shows the server
view of the shared directories. If the administrator shares /, and /opt/dce, then the NFS client using NFSv2 and NFSv3 can
mount /and /opt/dce. Attempts
to mount /opt will fail. In NFSv4, the client can mount /, /opt and /opt/dce. If the client
mounts /opt and lists the contents of the directory,
only the directory dce is seen. If you change directory (cd) to dce, the contents of dce is not visible. The client must specifically mount /opt/dce to see the contents of dce. Future versions of HP-UX will allow the client to cross this filesystem
boundary on the server. String Identifiers NFSv4 represents users and groups in the following manner: users@domain Or group@domain Where: - users
specifies the string representation of the user - group
specifies the string representation of the group - domain
specifies a registered DNS domain or a sub-domain
of a registered domain
However, UNIX systems use integers to represent users and groups
in the underlying filesystems stored on the disk. As a result, using
string identifiers requires mapping of string names to integers and
back. The nfsmapid daemon is used to map the owner
and owner_group identification attributes with the local user identification
(UID) and group identification (GID) numbers, which are used by both
the NFSv4 server and the NFSv4 client. On the NFS client, the nfsmapid daemon maps
a numeric UID or a numeric GID to a string representation. On the
NFS server, it maps a string representation to a numeric UID or a
numeric GID. For example, user casey with UID 121212
on an NFSv4 client whose fully qualified name is system.anydomain.com is mapped to casey@anydomain.com. The NFS
client sends the string representation, casey@anydomain.com, to the NFS server. The NFS server maps the string representation, casey@anydomain.com, to the unique ID 121212. The nfsmapid daemon uses the user and group
entries in the /etc/nsswitch.conf file, to determine
which name service to use while converting strings and numerical values
and back. For information on how to configure the nfsmapid daemon, see nfsmapid(1M). File Locking File locking support is integrated with the NFSv4 protocol.
NFSv4 introduces leases for lock management. When a server grants a lock to control the access of a file
for a specific period of time, it is called a lease. During the
lease period, the server cannot grant conflicting access to another
client. The lock lease interval can accept values higher than the cache
consistency leases. As a result, the client requires only a smaller
number of refreshes. The lease ensures that the client does not lose
the locking state. If a client refreshes a lock, all locks held by the client with
that server are validated. This reduces the number of lease refreshes
by the client from one per lock to one per client for a specific lease.
For information on configuring NFSv4 for the server,
see “Configuring the NFSv4 Server Protocol Version ”. For
information on configuring NFSv4 for the client, see “Configuring the NFSv4 Client Protocol Version”. Sharing and Unsharing Directories | |
In HP-UX 11i v3, NFS replaces the exportfs command with the share command. The share command is used on the server to share directories
and files with clients. You can use the unshare command to disable the sharing of directories with other systems. In earlier versions of HP-UX, the exportfs command was used to export directories and files to other systems
over a network. Users and programs accessed the exported files on
remote systems as if they were part of the local filesystem. NFS disabled
the system from exporting directories by using the -u option of the exportfs command. For information on how to share directories with the NFS clients,
see “Sharing Directories with NFS Clients”. For
information on how to unshare directories, see “Unsharing (Removing) a Shared Directory”. Following are the new share features
that NFS supports: Secure sharing of directories Starting
with HP-UX 11i v3, NFS enables you to share directories in a secure
manner. If you have configured a security mechanism on your system,
the share command enables you to specify the security
mechanism under which the filesystem is shared. For example, if you
have installed and configured the Kerberos Security product, you can
specify krb5 as the security mechanism
to be used when you share a filesystem. For information on how to use the share command
to share directories securely, see “Secure Sharing of Directories ”. Sharing directories across a firewall Starting with HP-UX 11i v3, NFS enables you to share directories
easily across a firewall. HP recommends that you share directories
across a firewall in one of the following ways:
Mounting and Unmounting Directories | |
NFS clients can mount any filesystem or a part of a filesystem
that is shared by the NFS server. Filesystems can be mounted automatically
when the system boots, from the command line, or through the automounter.
The different ways to mount a filesystem are as follows: For information on how to disable mount access for a single
client, see “Unmounting (Removing) a Mounted Directory”. Starting with HP-UX 11i v3, the mount command
is enhanced to provide benefits such as performance improvement of
large sequential data transfers and local locking for faster access.
The umount command allows forcible unmounting of
filesystems. These features can be accessed using specific options
of the mount command. For more information on these
options, see mount_nfs (1M), and umount(1M). NFS clients can also unmount the directories using the umount command. For information on unmounting a shared
directory, see “Unsharing (Removing) a Shared Directory”. Support for WebNFS | |
NFS is designed as a file access protocol for LANs. WebNFS is
an extension of NFS. It enables you to access files across the Internet
easily. WebNFS is designed to handle unique problems associated with
accessing files across the Internet. WebNFS enables filesystems at other locations on the Internet
to appear to a user as a local filesystem. WebNFS works through firewalls
and implements features such as read-ahead and write-behind, to improve
throughput and performance over the Internet. WebNFS is supported on NFS version 2 and 3 only. For more information on WebNFS, see “Sharing directories across a firewall using the WebNFS Feature”. Secure Sharing of Directories | |
In earlier versions of HP-UX, NFS used the AUTH_SYS authentication,
which uses UNIX style authentication, (uid/gid), to allow access to the shared files. It is fairly
simple to develop an application or server that can masquerade as
a user because the gid/uid ownership
of a file can be viewed. The AUTH_DH authenticating method was introduced to address
the vulnerabilities of the AUTH_SYS authentication method. The AUTH_DH
security model is stronger, because it authenticates the user by using
the user’s private key. Kerberos is an authentication system that provides secure transactions
over networks. It offers strong user authentication, integrity and
privacy. Kerberos support has been added to provide authentication
and encryption capabilities. For information on how to share directories
in a secure manner, see “Secure Sharing of Directories ”. Client Failover | |
By using client-side failover, an NFS client can specify redundant
servers that are making the same data available and switch to an alternate
server when the current server becomes unavailable. The filesystems
on the current server can become unavailable for the following reasons: If the filesystem is connected to a server that crashes If the server is overloaded If a network fault occurs
A failover occurs when the filesystem is unavailable. The failover
is transparent to the user. The failover can occur at any time without
disrupting processes that are running on the client. Consider the following points before enabling client-side failover: The filesystem must be mounted with read-only permissions. The filesystems must be identical on all the redundant
servers for the failover to occur successfully. For information on
identical filesystems, see “Replicated Filesystems”. A static filesystem or one that is not modified often
is used for failover. File systems that are mounted using CacheFS are not
supported for use with failover. If client-side failover is enabled using the command-line
option, the listed servers must support the same version of the NFS
protocol. For example, onc21 and onc23 must support the same version of NFS protocol,
either NFSv2, NFSv3, or NFSv4.
For information on how to enable client-side failover, see “Enabling Client-Side Failover”. A replicated filesystem contains the corresponding directory
structures and identical files. A replica (identical copy) of a filesystem
consists of files of the same size and same file type as the original
filesystem. HP recommends that you create these replicated filesystems using
the rdist utility. The rdist utility enables you to maintain
identical copies of files on multiple hosts. It preserves the owner,
group, mode, modification time of files, and updates programs that
are running. Enhanced NFS Logging | |
The NFS server logging enables an NFS server to provide a record
of file operations that are performed on its filesystems. The record
includes information about the file accessed, time of access, and
the users who accessed the files. You can also specify the location
of the logs that contain this information. This feature is useful
for sites that make anonymous FTP archives available to NFS and WebNFS
clients. IPv6 Support | |
NFS supports filesystem mounting over an IPv4 or an IPv6 address
where square brackets enclose the IPv6 address. The nsquery feature supports ipnodes lookup
request and provides support to lookup IPv6 data in the backend libraries. |
Printable version
