 |
» |
|
|
|
Configuring an NFS server involves
completing the following tasks: Identify the
set of directories that you want the NFS server to share. For example,
consider an application App1 running on an NFS client. Application App1 requires access to the abc filesystem in an NFS server. NFS server should share
the abc filesystem. The decision of sharing directories by an
NFS server is driven by the applications running on NFS clients
that require access to those directories. Specify access restrictions
and security modes for the shared directories. For example, you
can use Kerberos (a security product) that is already configured
on your system to specify access restrictions and security modes
for the NFS shared directories.
NFS
Configuration Files and Daemons | |
This section describes the NFS configuration files and daemons. Configuration FilesTable 2-1 “NFS Server Configuration Files” describes the NFS
configuration files and their functions. Table 2-1 NFS Server Configuration Files File Name | Function |
|---|
| /etc/rc.config.d/nfsconf | Contains the variables read by the start-up
scripts of the NFS subsystem. | | /etc/pcnfsd.conf | Contains the PC NFS configuration information. | | /etc/default/nfs | Contains the parameters to set the default behavior
of various NFS commands and daemons. | | /etc/dfs/dfstab | Contains the share commands that are executed when the NFS server subsystem
starts. | /etc/dfs/fstypes | Contains the distributed filesystem types.
The default filesystem is NFS. | | /etc/nfssec.conf | Contains the valid and supported NFS
security modes. | | /etc/dfs/sharetab | Contains the system record of shared
filesystems. | | /etc/rmtab | Contains all the entries for hosts that
have mounted filesystems from any system. |
DaemonsTable 2-2 “NFS Server Daemons” describes the NFS
server daemons. Table 2-2 NFS Server Daemons Daemon Name | Function |
|---|
rpc.mountd | Answers requests for NFS access information
and filesystem mount requests. The mountd daemon reads the /etc/dfs/sharetab file to determine which filesystems are available for
mounting and by which remote systems. | nfsd | Handles client filesystem requests. By
default, nfsd starts over TCP, TCP6, UDP, and UDP6 transports. | | nfslogkd | Flushes nfslog information from the kernel to a file. | nfsmapid | Maps to and from NFSv4 owner and owner
group identification attributes to local UID and GID numbers used by
both NFSv4 client and server. | nfs4srvkd | Supports server side delegation. | rpc.lockd | Supports record lock and share lock operations
on the NFS files. | rpc.statd | Maintains a list of clients that have performed
the file locking operation over NFS against the server. These clients are
monitored and notified in the event of a system crash. |
Following are the tasks involved in configuring and administering
an NFS server: Configuring
the NFSv4 Server Protocol Version | |
By default, the version of the NFS protocol used between the
client and the server is the highest one available on both systems.
On HP-UX 11i v3, the default maximum protocol version of the NFS
server and the client is 3. The default minimum protocol version
of the NFS server and the client is 2. To configure the NFS server to enable clients to mount filesystems
using protocol version 4 (NFSv4), follow these steps: Set the value of NFS_SERVER_VERSMAX variable
to 4 in the /etc/default/nfs file, as follows:
The NFS_SERVER_VERSMAX variable specifies
the maximum protocol version of the NFS protocol for communication.
For more information on NFSv4, see nfsd(1m), mount_nfs(1m), and nfsmapid(1m). Enabling
an NFS Server | |
To enable an NFS server, follow these steps: In the /etc/rc.config.d/nfsconf file, ensure that the NFS_SERVER and START_MOUNTD variables are set to 1: NFS_SERVER=1
START_MOUNTD=1 |
Enter the following command to verify whether rpcbind daemon is running: If the daemon is running, an output similar to the following
is displayed: No message is displayed if the daemon is not running. To start the rpcbind daemon, enter the following command: /sbin/init.d/nfs.core start |
Enter the following commands to verify whether the lockd and statd daemons are running: If the daemons are running, an output similar to the following
is displayed: 1069548396 ? 0:00 rpc.lockd |
1069640883 ? 0:00 rpc.statd |
No message is displayed if the daemons are not running. To start the lockd and statd daemons, enter the following command: /sbin/init.d/lockmgr start |
Enter the following command to run the NFS startup
script: /sbin/init.d/nfs.server start |
The NFS startup script enables the NFS server and uses the
variables in the /etc/rc.config.d/nfsconf file to determine which processes to start. Sharing
Directories with NFS Clients | |
The share command exports or shares local directories with NFS
clients. If you use the share command without specifying any options, it displays the
list of currently shared directories. You can also use the share command with options to specify access restrictions and
other access options for the shared directories. | | | |  | NOTE: The exportfs command, used to export directories in versions prior
to HP-UX 11i v3, is now a script that calls the share command. HP provides a new exportfs script for backward compatibility to enable you to continue
using exportfs with the functionality supported in earlier versions
of HP-UX. To use any of the new features provided in HP-UX 11i v3
you must use the share command. In HP-UX 11i v3, the /etc/dfs/dfstab file replaces the /etc/exports file and the /etc/dfs/sharetab file
replaces the /etc/xtab file. | | | | |
You can share a filesystem in the following methods: Automatic sharing Filesystems configured in the /etc/dfs/dfstab file are shared automatically during system reboot.
To set up a directory for automatic sharing, you must configure
it in the /etc/dfs/dfstab file. Manual sharing Filesystems can also be shared manually. However, if the system
is restarted or rebooted, the filesystems will no longer be shared
and must be re-shared before it can be accessed by NFS clients.
To share directories manually, you must run the share command. Sharing using scripts Sharing of filesystems using scripts, such as Serviceguard,
is a variant of manual sharing. Configure the filesystems that you
share across your Serviceguard clusters through scripts that are
executed under Serviceguard’s control. For more information
on configuring the filesystems for sharing using scripts, see Managing Serviceguard,
12th Edition, March 2006.
Consider the following points before you share a directory: When you share a directory, the share options that restrict access to a shared directory are
applied, in addition to the regular HP-UX permissions on that directory. For example, if only the owner of a file has write permission,
others cannot write to the file even if it is shared with read and
write permissions. You can also specify the access permissions on the
NFS client, when a directory is mounted. If these permissions differ
from the permissions for the shared directory on the NFS server,
the more restrictive permissions are used. For example, consider an NFS client that mounts a directory
with read and write permissions while the directory is shared by
the NFS server with read permission. Read permissions being more restrictive,
the NFS client only has read permission. Exercise caution when sharing a directory that contains
a symbolic link, which refers to data outside the NFS mounted directory. Once the directory is mounted on an NFS client, the symbolic
link is resolved locally on the client.
Figure 2-1 “Symbolic
Links in NFS Mounts” depicts symbolic
links in NFS mounts. The destination of the symbolic link exists
on the NFS server, but does not exist on the NFS client. This results
in an error message. Sharing
a directory with NFS ClientsBefore you share your filesystem or directory, determine whether
you want the sharing to be automatic or manual. To share a directory
with NFS clients, select one of the following methods: Automatic ShareTo share your directories automatically, follow these steps: Add an entry to the /etc/dfs/dfstab file for each directory you want to share with the NFS
clients. Following is an example of an entry in the /etc/dfs/dfstab file for the netgroup Developers. All the hosts that are part of the netgroup will
now have read and write permissions to the /home directory. share -F nfs -o rw="Developers" -d "home dirs" /home |
Where: - -F
Specifies the filesystem
type - nfs
Specifies that the filesystem
type is NFS - -o
Enables you to use some of
the specific options of the share command, such as sec, async,
public, and others. - -d
Enables you to describe the filesystem being shared
When NFS is restarted or the system is rebooted, the /etc/dfs/dfstab file is read and all directories are shared automatically. Share all the directories configured in the /etc/dfs/dfstab file without restarting the server by using the following
command: This command reads the entries in the /etc/dfs/dfstab file and shares all the directories. Verify that your filesystem is shared by entering
the following command: An output similar to the following output is displayed: /home rw=Developers, ro= "home dirs" |
All the directories that you have shared must be present
in this list.
Manual ShareTo share your directories manually, follow these steps: Enter the following command to add
a directory to the server’s internal list of shared directories: share -F nfs directory_name |
Enter the following command to verify if your filesystem
is shared: An output similar to the following output is displayed: /tmp rw=hpdfs001.cup.hp.com ““
/mail rw ““
/var rw ““ |
The directory that you have shared must be present in this
list.
For more information on the share command and a list of share options, see share_nfs(1M) and share(1M). Examples
for Sharing directories This section discusses different examples for sharing directories. Sharing a directory with read-only
access In this example, all clients are allowed read-only access
to the /tmp directory. The /tmp directory needs to be configured to allow read access
to users on the clients. For example, specify -r--r--r-- permissions for the /tmp directory. Sharing a directory with varying access permissions share -F nfs -o ro=Jan:Feb,rw=Mar /usr/kc |
In this example, the /usr/kc directory is shared with clients Jan, Feb, and Mar. The rw option specifies that users on client Mar have read-write access to the /usr/kc directory. The ro option specifies that users on Jan and Feb have read-only access. In addition to the share options, the HP-UX permissions for the /usr/kc directory must be set to allow access to all users
or group that includes the users on Jan, Feb, and Mar. Sharing a directory with root access for clients share -F nfs -o root=Red:Blue:Green /var/mail |
In this example, the /var/mail directory is shared. Root access is allowed for
clients Red, Blue, and Green. Superusers on all other clients are considered
as unknown by the NFS server, and are given the access privileges
of an anonymous user. Non-superusers on all clients are allowed
read-write access to the /var/mail directory if the HP-UX permissions on the /var/mail directory allow them read-write access. Sharing a directory with root access for superuser
and read-write access for other users share -F nfs -o rw=Red,root=Red /var/mail/Red |
In this example, the /var/mail/Red directory is shared. Only the superuser on client Red is granted root access to the directory. All other
users on client Red have read-write access if they are provided read-write
access by the regular HP-UX permissions. Users on other clients
have read-only access if they are allowed read access through the
HP-UX permissions. Sharing directories with anonymous users based on
access rights given to the superuser share -F nfs -o rw=Green,root=Green,anon=65535 /vol1/grp1/Green |
In this example, superusers on host Green use uid 0 and are treated as root. The root users
on other hosts (Red and Blue) are considered anonymous and their uids and gids
are re-mapped to 65535. The superusers on host Green are allowed
read-write access. All other clients get read-only access. Sharing directories with anonymous users based on
access rights given to them share -F nfs -o anon=200 /export/newsletter |
In this example, the /export/newsletter directory is shared with all clients. Anonymous
users are given the effective user ID of 200. Other users retain
their own user IDs (even if they do not exist in the NFS server’s passwd database). Anonymous users are users who have not been authenticated,
or requests that use the AUTH_NONE security mode, or root users on hosts not included in
the root=list. By default, anonymous users are given the effective
user ID, UID_NOBODY. If the user ID is set to -1, access is denied. The ls command displays that a file created by a superuser is
owned by user ID 200. If an anonymous user with a non-zero user
ID, for example, 840, is allowed to create a file in this directory,
the ls command displays that it is owned by user ID 840.
Secure
Sharing of Directories | |
The share command enables you to specify a security mode for NFS.
Use the sec option to specify the different security
modes. Table 2-3 “Security Modes of the share command” describes the
security modes of the share command. Table 2-3 Security Modes of the share command Security Mode | Description |
|---|
sys | Uses the default authentication method,
AUTH_SYS. The sys mode is a simple authentication method that uses UID/GID
UNIX permissions, and is used by NFS servers and NFS clients using
the version 2, 3, and 4 protocol. | | dh | Uses the Diffie-Hellman public-key system
and uses the AUTH_DES authentication. | | krb5 | Uses Kerberos V5 protocol to authenticate
users before granting access to the shared filesystems. | krb5i | Uses Kerberos V5 authentication with
integrity checking to verify that the data is not tampered with, while
in transit between the NFS clients and servers. | krb5p | Uses Kerberos V5 authentication, integrity
checking, and privacy protection (encryption) on the shared filesystems. | | none | Uses NULL authentication (AUTH_NONE).
NFS clients using AUTH_NONE are mapped to the anonymous user nobody by NFS. |
You can combine the different security modes. However, the
security mode specified in the host must be supported by the client.
If the modes on the client and server are different, the directory
cannot be accessed. For example, an NFS server can combine the dh (Diffie-Hellman) and krb5 (Kerberos) security modes as it supports both the modes.
However, if the NFS client does not support krb5, the shared directory cannot be accessed using krb5 security mode. Consider the following points before you specify or combine
security modes: The share command uses the AUTH_SYS mode by default, if the sec=mode option is not specified. If your network consists of clients with differing
security requirements, some using highly restrictive security modes
and some using less secure modes, use multiple security modes with
a single share command. For example, consider an environment where all clients do
not require same level of security. This environment is usually
difficult to secure and requires running various scripts. However,
if you use the share command, you can specify different security mechanisms for
each netgroup within your network. If one or more explicit sec= options are specified, you must set the sys security
mode to continue to allow access to share directories, using the
AUTH_SYS authentication method. For example, if you are specifying multiple security options,
such as Kerberos and Diffie-Hellman, then specify the sys security option as well to enable users to access the
shared directories using the AUTH_SYS security method. If ro and rw options are specified in a sec clause,
the order of the options rule is not enforced. All hosts are granted
read-only access, except those in the read-write list.
Secure
NFS Setup with KerberosThis section describes how to configure your secure NFS using
Kerberos. Configuring Secure NFS Server with Kerberos You need to set up the NFS server as a Kerberos client before
securing the NFS server. To configure your secure NFS server, follow these steps: Set up the host as a Kerberos client.
For more information on setting up the NFS server as a Kerberos
client, see Configuration Guide for Kerberos Client Products on
HP-UX (5991-7685). | | | | | NOTE: Add a principal for all machines that are going to use
the NFS Service. Also, add a principal for all users who will access
the data on the NFS server. For example, the sample/krbsrv39.anyrealm.com principal should be added to the Kerberos database
before running the sample applications. | | | | |
To get the initial Ticket Granting Ticket (TGT)
to request a service from the application server, enter the following
command: The password prompt is displayed. Enter the password for the
root principal that is added to the Kerberos database. To verify the TGT, enter the following command: An output similar to the following output is displayed: Ticket cache: /tmp/krb5cc_0Default principal: root@krbhost.anyrealm.comValid starting Expires Service principalFri 16 Jan 2007 01:44:08 PM PDT Sat 17 Jan 2007 01:44:08 PM PDT krbtgt/krbhost.anyrealm.com@krbhost.anyrealm.com |
To verify that the system is set up as a Kerberos
client, enter the following command: An output similar to the following output is displayed: root 1156 1139 0 Feb 9 ? 0:30 /opt/krb5/sbin/kdcd root 1139 1 0 Feb 9 ? 0:00 /opt/krb5/sbin/kdcd root 1154 1 0 Feb 9 ? 15:33 /opt/krb5/sbin/kadmind |
This output indicates that the Kerberos daemons are running. To verify that the underlying GSS-API framework
is working properly, run the sample program /usr/contrib/gssapi/sample. In this example, the following setup was used to run the program: - GSS-API Server Host:
krbsrv39 - GSS-API Client Host:
krbcl145
An output similar to the following output is displayed: krbcl145: #/hpsample/gss-client krbcl145 sample@krbsrv39 "hi"Sending init_sec_context token (size=541)...continue needed...length = 106context flag: GSS_C_MUTUAL_FLAGcontext flag: GSS_C_REPLAY_FLAGcontext flag: GSS_C_CONF_FLAGcontext flag: GSS_C_INTEG_FLAG"root/krbcl145.anyrealm.com@krbhost.anyrealm.com" to "sample/krbsrv39.anyrealm.com@krbhost.anyrealm.com", lifetime 86297, flags 36, locally initiated, openName type of source name is { 1 2 840 113554 1 2 1 1 }.Mechanism { 1 2 840 113554 1 2 2 } supports 7 names 0: { 1 2 840 113554 1 2 1 1 } 1: { 1 2 840 113554 1 2 1 2 } 2: { 1 2 840 113554 1 2 1 3 } 3: { 1 3 6 1 5 6 2 } 4: { 1 2 840 113554 1 2 1 4 } 5: { 1 2 840 113554 1 2 1 1 } 6: { 1 2 840 113554 1 2 2 1 }length = 37Signature verified. |
The statement Signature verified indicates that the GSS-API framework is working properly. | | | | | NOTE: Step 6 and Step 7 are to be performed on the Kerberos
Server. | | | | |
To add the NFS service principal to the NFS server,
such as nfs/krbsrv39.anyrealm.com, in the Kerberos database of the Kerberos server, first
run the kadmin command-line administrator command and then add a new
principal using the add command. Command: addName of Principal to Add: nfs/krbsrv39.anyrealm.comEnter password:Re-enter password for verification:Principal added. |
| | | | | NOTE: The server hostname in the service principal must be
a fully qualified name. | | | | |
To extract the key for the
added NFS service principal, use the Kerberos administration tool,
kadminl_ui, and store it in a file called machine_name.keytab. Then, copy this file to /etc/krb5.keytab on the NFS server. To verify the keys, enter
the following command :
# klist -k
An output similar to the following output
is displayed:
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
--------------------------------------------------------
1 nfs/krbsrv39.anyrealm.com@krbhost.anyrealm.com
If you did not add the NFS
service principal with the fully qualified hostname, an error similar
to the following error is displayed: share -o sec=krb5i /export_krb5 share_nfs: /export_krb5: Invalid argument |
Modify the /etc/nfssec.conf file.
Uncomment the entries for either krb5, krb5i, or krb5p based on the security protocol you want to choose. You
can choose all the versions as shown in this example: |
#ident "@(#)nfssec.conf 1.5 07/11/09 SMI"# The NFS Security Service Configuration File.# Each entry is of the form:# <NFS_security_mode_name> <NFS_security_mode_number> \# <GSS_mechanism_name> <GSS_quality_of_protection> <GSS_services># The "-" in <GSS_mechanism_name> signifies that this is not a GSS mechanism.# A string entry in <GSS_mechanism_name> is required for using RPCSEC_GSS# services. <GSS_quality_of_protection> and <GSS_services> are optional.# White space is not an acceptable value.# default security mode is defined at the end. It should be one of the flavor numbers defined above it.none 0 - - - # AUTH_NONEsys 1 - - - # AUTH_SYSdh 3 - - - # AUTH_DHkrb5 390003 krb5_mech default - # RPCSEC_GSSkrb5i 390004 krb5_mech default integrity # RPCSEC_GSSkrb5p 390005 krb5_mech default privacy # RPCSEC_GSSdefault 1 - - - # default is AUTH_SYS |
To create a credential table,
enter the following command: Share a directory with the
Kerberos security option as described in the following section.
Examples
for Securely Sharing DirectoriesThis section discusses different examples for sharing directories
in a secure manner. Granting access to shared directories
only for AUTH_DES mode users share -F nfs -o sec=dh /var/casey |
In this example, only clients that use AUTH_DES security mode are granted access. Sharing directories using a combination of security
modes share -F nfs -o sec=dh,rw,sec=sys,rw=onc21 /var/Casey |
In this example, the security modes dh and sys are combined. Sharing directories with read-only access for all
non AUTH_DES users share -F nfs -o sec=dh,rw,sec=sys,ro /var/Casey |
All clients that do not use the AUTH_DES security mode get read-only access. Sharing directories with two groups having different
access permissions share -F nfs -o ro=nw1,rw=nw2 /var/Casey |
In this example, client onc36 is common to two netgroups, nw1 and nw2. Each netgroup is granted different access permissions, rw and ro. The order of the two options determines the permission
that the client is granted. Client onc36 is granted read-only access. share -F nfs -o rw=nw1,ro=nw2 /var/Casey |
In this example, the client onc36 is granted read-write access. Sharing directories with different access permissions share -F nfs -o ro=onc32,root=onc21 /var/Casey |
In this example, onc21 is included in the root= list.
There is no interaction between the root option,
and the rw and ro options. Here, onc21 is denied access. share -F nfs -o ro=onc32,rw=onc21,root=onc21 /var/casey |
In this example, onc21 is given read-write access.
Secure NFS Client Configuration with Kerberos To secure your NFS client setup using Kerberos, follow these
steps: Set up Kerberos
client for the same realm as the NFS server. You can copy the krb5.conf file from the NFS server. | | | | | NOTE: Add a principal for all machines that are going
to use the NFS Service. Also, add a principal for all users who
will access the data on the NFS server. For example, the sample/krbsrv39.anyrealm.com principal should be added to the Kerberos database
before running the sample applications. | | | | |
To get the initial TGT to
request a service from the application server, enter the following
command:
# kinit username
The password prompt is displayed.
Enter the password for the root principal that is added to the Kerberos
database. To verify the TGT, enter the following command: An output similar to the following output is displayed: Ticket cache: /tmp/krb5cc_0Default principal: root@krbhost.anyrealm.comValid starting Expires Service principalFri 16 Jan 2007 01:44:08 PM PDT Sat 17 Jan 2007 01:44:08 PM PDT krbtgt/krbhost.anyrealm.COM@krbhost.anyrealm.com |
To verify that the system is set up as a Kerberos
client, enter the following command: An output similar to the following output is displayed: root 1156 1139 0 Feb 9 ? 0:30 /opt/krb5/sbin/kdcd root 1139 1 0 Feb 9 ? 0:00 /opt/krb5/sbin/kdcd root 1154 1 0 Feb 9 ? 15:33 /opt/krb5/sbin/kadmind |
This indicates that the Kerberos daemons are running. To verify that the underlying GSS-API framework
is working properly, run the sample program /usr/contrib/gssapi/sample. In this example, the following setup was used to run the program: - GSS-API Server Host:
krbsrv39 - GSS-API Client Host:
krbcl145
The output generated is similar to the one displayed for the Configuring
Secure NFS server with Kerberos procedure. Modify the /etc/nfssec.conf file
and uncomment the entries for krb5, krb5i, and krb5p based on the security protocol you choose. You can decide
to choose all the versions as shown in the example in the Secure
NFS server configuration. To mount a directory or filesystem with the Kerberos
security option, enter the following command: mount -o sec=<Kerberos protocol version> <svr:/dir> </mount-point> |
Where, - -o
Enables you to use some of
the specific options of the share command, such as sec, async,
public, and others. - sec
Enables you to specify the
security mode to be used. Specify krb5 as the kerberos protocol version. - <svr:/dir>
Enables you to specify the
location of the directory. - </mount-point>
Enables you to specify the
mount-point location where the filesystem is mounted.
An initial ticket grant is carried out when the user accesses
the mounted filesystem.
Accessing
Shared NFS Directories across a Firewall | |
To access shared NFS directories across a firewall, you must
configure the firewall based on the ports that the NFS service daemons
listen on. To access NFS directories, the following daemons are
required: rpcbind, nfsd, rpc.lockd, rpc.statd, and rpc.mountd. The rpcbind daemon uses a fixed port, 111, and the nfsd daemon uses 2049 as its default port. To configure the
firewall, you must know the port numbers of the other NFS daemons,
to ensure that the NFS client requests are not denied. | | | | | NOTE: This section does not document how to configure a firewall.
This section documents the considerations to keep in mind while
sharing a directory across a firewall. | | | | |
Shared NFS directories can be accessed across a firewall in
the following ways: Sharing directories
across a firewall without fixed port numbers Sharing directories across
a firewall using fixed port numbers in the /etc/default/nfs file Sharing directories across
a firewall using the NFSv4 protocol Sharing directories across
a firewall using the WebNFS feature
Sharing
directories across a firewall without fixed port numbers (NFSv2
and NFSv3)This is the default method of sharing directories across a
firewall. In this method, the rpc.statd and rpc.mountd daemons do not run on fixed ports. The ports used by these
daemons are assigned from the anonymous port range. By default,
the anonymous port range is configured between 49152 and 65535. The rpc.lockd daemon runs at port 4045, by default. To change the port at
which it runs, modify the lockd entry in the /etc/services file and restart the daemon. To determine the port numbers
currently used by rpc.statd and rpc.mountd daemons, run the rpcinfo -p command, and configure the firewall accordingly. For example, to determine the port numbers, enter the following command: An output similar to the following output is displayed: program vers proto port service100024 1 udp 49157 status100024 1 tcp 49152 status100021 2 tcp 4045 nlockmgr100021 3 udp 4045 nlockmgr100005 3 udp 49417 mountd100005 3 tcp 49259 mountd100003 2 udp 2049 nfs100003 3 tcp 2049 nfs |
Each time the rpc.statd and rpc.mountd daemons are stopped and restarted they may be assigned
a different port from the anonymous port range. The firewall must
be reconfigured each time the NFS service is restarted. For example, if the NFS service or the rpc.statd and rpc.mountd daemons are restarted, run the rpcinfo -p command to view the new port numbers. An output similar to the following output is displayed: program vers proto port service 100024 1 tcp 49154 status100024 1 udp 49161 status100021 3 tcp 49156 nlockmgr100021 3 udp 49163 nlockmgr100005 3 udp 49181 mountd100005 3 tcp 49181 mountd100003 3 udp 2049 nfs100003 3 tcp 2049 nfs |
Configure the firewall based on the new port numbers. Sharing
directories across a firewall using fixed port numbers in the nfs
fileUsing the /etc/default/nfs file enables you to specify fixed port numbers for the rpc.statd and rpc.mountd daemons. The rpc.lockd daemon runs at port 4045 and is not configurable. To set the port numbers using the /etc/default/nfs file, follow these steps: Assign values to the variables, STATD_PORT and MOUNT_PORT, as follows: STATD_PORT = port_number
MOUNTD_PORT = port_number
|
Where: - port_number
The port number on which
the daemon runs. It can be set to any unique value between 1024
and 65536. - STATD_PORT
The port on which the rpc.statd daemon runs. - MOUNTD_PORT
The port on which the rpc.mountd daemon runs.
Activate the changes made to the /etc/default/nfs file by restarting the lock manager and NFS server daemons
as follows: /sbin/init.d/nfs.server stop
/sbin/init.d/lockmgr stop
/sbin/init.d/lockmgr start
/sbin/init.d/nfs.server start |
Configure the firewall based
on the port numbers configured.
Sharing
directories across a firewall using the NFSv4 protocolNFSv4 is a single protocol that handles mounting, and locking operations
for NFS clients and servers. The NFSv4 protocol runs on port 2049,
by default. To override the default port number (2049) for the NFSv4 protocol, modify
the port number for the nfsd entry in the /etc/services file. Configure the firewall based on the port number set. Sharing
directories across a firewall using the WebNFS FeatureThe WebNFS service makes files in a directory available to
clients using a public file handle. The ability to use this predefined
file handle reduces network traffic, by avoiding the MOUNT protocol. This section compares the process of communication between
an NFS client and an NFS server across LANs and WANs. Table 2-4 “NFS Session Versus WebNFS Session” compares the NFS session across a LAN
with a WebNFS session across a WAN. Table 2-4 NFS Session Versus WebNFS Session How NFS works across LANs | How WebNFS works across WANs |
|---|
NFS servers must register their port assignments
with the portmapper service that is registered on port 111, although the
NFS server uses 2049 as the destination port. | NFS servers register on port 2049. WebNFS clients
contact the WebNFS server on port 2049. | The MOUNT service is not registered on
a specific port. The NFS client must use the portmapper service to locate the MOUNT port. Once the port is located,
the client must issue a request for a file handle corresponding
to the requested path. | A WebNFS client can use the PUBLIC file handle
as an initial file handle, rather than using the MOUNT protocol. |
Figure 2-2 “WebNFS
Session” shows a sample
WebNFS session. Figure 2-2 “WebNFS
Session” depicts the following
steps: An NFS client
uses a LOOKUP request with a PUBLIC file handle to access the
foo/index.html file. The NFS client bypasses the portmapper service
and contacts the server on port 2049 (the default port). The NFS server responds with
the file handle for the foo/index.html file. The NFS client sends a READ
request to the server. The NFS server responds with
the data.
Removing the additional overhead of the PORTMAP and MOUNT protocols
reduces the binding time between the client and the server. The WebNFS
protocol reduces the number of over-the-wire requests and makes
traversing firewalls easier. WebNFS offers no support for locking files across mounted
filesystems. Hence, multiple clients cannot synchronize their locking
calls across WebNFS mounted filesystems. To access the shared directory across a firewall using the
WebNFS feature, configure the firewall to allow connections to the
port number used by the nfsd daemon. By default the nfsd daemon uses port 2049. Configure the firewall based on the port number configured. Configuring
an NFS Server for use by a PC NFS client | |
PC NFS is a protocol designed to perform the following functions: Allow PC users who do not have UNIX
style credentials to authenticate to a UNIX account Perform print spooling from a PC on to a UNIX server
Once a PC client has successfully authenticated itself on
the NFS server, the PC uses the MOUNT and NFS protocols to mount
the filesystem and to read and write to a file. You may want to create the /etc/pcnfsd.conf file for the following reasons: If the PC NFS client software assigns
user IDs smaller than 101 or greater than 60002, you can set the uidrange in the /etc/pcnfsd.conf file to allow access to a different range of user IDs,
as in the following example: You want to provide PC users a different set of
default print options. For example, add an entry to the /etc/pcnfsd.conf file which defines raw as a default print option for PC users submitting
jobs to the printer lj3_2 as follows: printer lj3_2 lj3_2 lp -dlj3_2 -oraw |
The /etc/pcnfsd.conf file is read when the pcnfsd daemon starts. If you make any changes to /etc/pcnfsd.conf file while pcnfsd is running, you must restart pcnfsd before the changes take effect. A PC must have NFS client software installed in order to use
the system as a PC NFS server. The PCNFS_SERVER variable, configured using the /etc/rc.config.d/nfsconf file controls whether the pcnfsd daemon is started at system boot time. To configure
the server to automatically start pcnfsd during system boot, follow these steps: In the /etc/rc.config.d/nfsconf file, use a text editor to set the PCNFS_SERVER variable to 1, as follows: To forcibly start the pcnfsd daemon while the server is running, run the following
command: /sbin/init.d/nfs.server start |
For more information on pcnfsd, see pcnfsd(1M). Disabling
the NFS Server | |
To disable the NFS server, follow these steps: On the NFS server, enter the following command to unshare
all the shared directories: Enter the following command to disable NFS server
capability: /sbin/init.d/nfs.server stop |
On the NFS server, edit the /etc/rc.config.d/nfsconf file to set the NFS_SERVER variable to 0, as follows: NFS_SERVER=0
This prevents the NFS server daemons from starting when the system reboots. |
For more information about forced unmount, unmounting and unsharing,
see mount_nfs (1M), unshare(1M), and umount(1M). |
Printable version
