 |
» |
|
|
|
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 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 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 mountddaemon 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 exportfsscript 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/dfstabfile 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 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/dsftab 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_NONEsecurity 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 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 syssecurity 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 secclause, 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_0
Default principal: root@krbhost.anyrealm.com
Valid starting Expires Service principal
Fri 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 = 106
context flag: GSS_C_MUTUAL_FLAG
context flag: GSS_C_REPLAY_FLAG
context flag: GSS_C_CONF_FLAG
context 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, open
Name 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 = 37
Signature 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: add
Name of Principal to Add: nfs/krbsrv39.anyrealm.com
Enter 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 : 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 usi
ng 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_NONE
sys 1 - - - #
AUTH_SYS
dh 3 - - - #
AUTH_DH
krb5 390003 krb5_mech default - #
RPCSEC_GSSkrb5i 390004 krb5_mech default integrity #
RPCSEC_GSS
krb5p 390005 krb5_mech default privacy #
RPCSEC_GSS
default 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_0
Default principal: root@krbhost.anyrealm.com
Valid starting Expires Service principal
Fri 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.mountddaemons 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 and
is not configurable. To determine the port numbers currently used
by rpc.statd andrpc.mountd daemons,
run the rpcinfo -pcommand, 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 service
100024 1 udp 49157 status
100024 1 tcp 49152 status
100021 2 tcp 4045 nlockmgr
100021 3 udp 4045 nlockmgr
100005 3 udp 49417 mountd
100005 3 tcp 49259 mountd
100003 2 udp 2049 nfs
100003 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 status
100024 1 udp 49161 status
100021 3 tcp 49156 nlockmgr
100021 3 udp 49163 nlockmgr
100005 3 udp 49181 mountd
100005 3 tcp 49181 mountd
100003 3 udp 2049 nfs
100003 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 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 shows a sample
WebNFS session. Figure 2-2 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/nfsconffile 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
