Certification Objective 10.01-Configuring a Network File System (NFS) Server | Linux Patch Management: Keeping Linux Systems Up To Date

The NFS is the standard for sharing files and printers on a directory with Linux and Unix computers. It was originally developed by Sun Microsystems in the mid- 1980s. Linux has supported NFS (both as a client and a server) for years, and NFS continues to be popular in organizations with Unix- or Linux-based networks.

Inside the Exam

More Network Services

The Red Hat Exam Prep guide suggests that you can expect to configure NFS, FTP, and Samba servers during the Installation and Configuration portion of the RHCE exam. As described in the Red Hat Exam Prep guide, for each of these services, RHCEs must be able to do the following:

Install the packages needed to provide the service.
Configure SELinux to support the service.
Configure the service to start when the system is booted.
Configure the service for basic operation.
Configure host-based and user-based security for the service.

It also suggests that you need to know how to "diagnose and correct problems with (these) network services" as well as SELinux-related network issues during the Troubleshooting and System Maintenance portion of this exam.

In this chapter, the NFS service should be installed automatically with RHEL 5. vsFTP and Samba are important server options for many administrators, and it's very possible that you'll install them during the RHCE exam. For each service, remember to use a command such as chkconfig to make sure it starts the next time you boot Linux. It also will help you get full credit for the work you do on the Red Hat exams.

You can create shared NFS directories directly by editing the /etc/exports configuration file, or with Red Hat's NFS Configuration tool. As NFS servers come first, that's what this chapter covers first.

Exam Watch

I believe even beginning Linux administrators should know how to connect to a shared NFS directory. While the Red Hat Exam Prep guide does not explicitly require RHCT candidates to have this knowledge, it is consistent with the spirit of that exam. The Red Hat Exam Prep guide does explicitly require that RHCE candidates know how to configure and troubleshoot an NFS server.

NFS Server Configuration and Operation

NFS servers are relatively easy to configure. All you need to do is export a filesystem, either generally or to a specific host, and then mount that filesystem from a remote client. In Chapter 2, you configured an NFS server to install RHEL over a network. This chapter goes further into the basics of NFS server configuration and operation.

Required Packages

Two RPM packages are closely associated with NFS: portmap and nfs-utils. They should be installed by default. Just in case, you can use the rpm -q packagename command to make sure these packages are installed. The rpm -ql packagename command provides a list of files installed from that package. The nfs-utils package includes a number of key files. The following is not a complete list:

/etc/rc.d/init.d/nfs Control script for NFS, hard linked to /etc/init.d/nfs
/etc/rc.d/init.d/nfslock Control script for lockd and statd, which locks files currently in use, hard linked to /etc/init.d/nfslock
/usr/share/doc/nfs-utils-versionnumber Documentation, mostly in HTML format
Server daemons in /usr/sbin rpc.mountd, rpc.nfsd, rpc.rquotad
Server daemons in /sbin rpc.lockd, rpc.statd
Control programs in /usr/sbin exportfs, nfsstat, nhfsgraph, nhfsnums, nhfsrun, nhfsstone, showmount
Status files in /var/lib/nfs etab, rmtab, statd, state, xtab

The portmap RPM package includes the following key files (also not a complete list):

/etc/rc.d/init.d/portmap Control script, hard linked to /etc/init.d/portmap
/usr/share/doc/portmap-4.0 Documentation
Server daemon in /sbin portmap
Control programs in /usr/sbin pmap_dump, pmap_set

Configuring NFS to Start

Once configured, NFS can be set up to start during the Linux boot process or can be started with the service nfs start command. NFS also depends on the portmap package, which helps secure NFS directories that are shared through /etc/exports. Because of this dependency, you need to make sure to start the portmap daemon before starting NFS, and don't stop it until after stopping NFS.

Exam Watch

Remember that both the portmap and nfs daemons must be running before NFS can work.

The nfs service script starts the following processes:

rpc.mountd Handles mount requests
nfsd Starts an nfsd kernel process for each shared directory
rpc.rquotad Reports disk quota statistics to clients

If any of these processes is not running, NFS won't work. Fortunately, it's easy to check for these processes by running the rpcinfo -p command. As with other service scripts, if you want it to start when RHEL boots, you'll need to run a command such as this:

 # chkconfig nfs on

This command makes sure NFS starts the next time you boot into runlevels 2, 3, 4, or 5. Alternatively, you can use the Red Hat Service Management utility described in Chapter 3 to make sure NFS starts the next time you boot RHEL.

Configuring NFS for Basic Operation

NFS is fairly simple. The only major NFS configuration file is /etc/exports. Once configured, you can export these directories with the exportfs -a command. Each line in this file lists the directory to be exported, the hosts to which it will be exported, and the options that apply to this export. You can export a particular directory only once. Take the following examples from an /etc/exports file:

 /pub        (ro,insecure,sync) one.example.net(rw,insecure,sync) /home       *.example.net(rw,insecure,sync) /tftpboot   nodisk.example.net(rw,insecure,no_root_squash,sync)

In this example, the /pub directory is exported to all users as read-only. It is also exported to one specific computer with read/write privileges. The /home directory is exported, with read/write privileges, to any computer on the .example.net network. Finally, the /tftpboot directory is exported with full read/write privileges (even for root users) to the nodisk.example.net computer.

All of these options include the sync flag. This requires all changes to be written to disk before a command such as a file copy is complete. They also include the insecure flag, which allows access on ports above 1024. If you want to run NFS through a firewall, you'll need to specify ports for NFS communication, as described later in this chapter.

On the Job

Be very careful with /etc/exports; one common cause of problems is an extra space between expressions. For example, if you type in a space after either comma in (ro,insecure,sync), your directory won't get exported, and you'll get an error message.

Wildcards and Globbing

In Linux network configuration files, you can specify a group of computers with the right wildcard, which in Linux is also known as globbing. What you do for a wildcard depends on the configuration file. The NFS /etc/exports file uses "conventional" wildcards: for example, *.example.net specifies all computers within the example .net domain. In contrast, /etc/hosts.deny is less conventional; .example.net, with the leading dot, specifies all computers in that same domain.

For IPv4 networks, wildcards often require some form of the subnet mask. For example, 192.168.0.0/255.255.255.0 specifies the 192.168.0.0 network of computers with IP addresses that range from 192.168.0.1 to 192.168.0.254. Some services support the use of CIDR (Classless InterDomain Routing) notation. In CIDR, since 255.255.255.0 masks 24 bits, CIDR represents this with the number 24. If you're configuring a network in CIDR notation, you can represent this network as 192.168.0.0/24. For details, see the discussion for each applicable service in Chapter 7 and Chapters 9 through 15.

Activating the List of Exports

Once you've modified /etc/exports, you need to do more. First, this file is simply the default set of exported directories. You need to activate them with the exportfs -a command. The next time you boot RHEL, if you've activated nfs at the appropriate runlevels, the nfs start script (/etc/init.d/nfs) automatically runs the exportfs -r command, which synchronizes exported directories.

When you add a share to /etc/exports, the exportfs -r command adds the new directories. However, if you're modifying, moving, or deleting a share, it is safest to temporarily unexport all filesystems first with the exportfs -ua command before reexporting the shares with the exportfs -a command.

Once exports are active, they're easy to check. Just run the showmount -e command on the server. If you're looking for the export list for a remote NFS server, just add the name of the NFS server. For example, the showmount -e enterprise5 command looks for the list of exported NFS directories from the enterprise5 computer. If this command doesn't work, you may have blocked NFS messages with a firewall.

NFS Server Configuration Tool

It's easy to configure /etc/exports, and the Red Hat NFS Server Configuration tool is also easy to use and is reliable. To start this tool, type the system-config-nfs command in a GUI terminal, or choose System (or KDE Main Menu) | Administration | Server Settings | NFS. This opens the NFS Server Configuration window shown in Figure 10-1. After you go through these steps, you'll see how much simpler it is to add a line to /etc/exports.

image from book
Figure 10-1: NFS Server Configuration

To add a shared NFS directory, take the following steps:

Click Add or choose File | Add Share. This opens the Add NFS Share window shown in Figure 10-2.
Under the Basic tab, add the directory that you want to share. If you want to limit access to a specific host or domain, add the appropriate names or IP addresses to the Host(s) text box. If you want to allow access to all hosts, enter an asterisk (*). Set read-only or read/write permissions as desired. Click the General Options tab.
Under the General Options tab, you can set several parameters for this share, as described in Table 10-1. Note that sync and hide options are active by default. The default is sufficient unless you receive specific instructions for an NFS share on your exam. If you want to activate NFS through a firewall, activate the Allow Connections From Port 1024 And Higher (insecure) option. (But this isn't sufficient.) Click the User Access tab.
Under the User Access tab, you can set different parameters for remote users, as defined in Table 10-2.
Once you've finished configuring your shared NFS directory, click OK. The directory is automatically exported with the exportfs -r command, and, as long as you aren't blocking access with firewalls, it should now be ready for use.
If you have problems, check for firewalls. Check for limitations in /etc/hosts.allow and /etc/hosts.deny. For more information on firewall management, read Chapter 15. If necessary, use the service nfs stop and service nfs start commands to restart the NFS service. If problems continue, you may find more information in your /var/log/messages file.

image from book
Figure 10-2: The Add NFS Share window

Table 10-1: NFS Tool General Options
Parameter	Corresponding /etc/exports Command and Explanation
Allow connections from ports 1024 or higher	insecure This supports NFS messages above ports 1024.
Allow insecure file locking	insecure_locks If you have an older NFS client, this does not check user permissions to a file.
Disable subtree checking	no_subtree_check If you export a subdirectory such as /mnt/inst, this feature disables checks of higher level directories for permissions.
Sync write operations on request	sync Data is written upon request. Active by default.
Force sync of write operations immediately	no_wdelay Data is written to the share immediately.
Hide filesystems beneath	hide If you export a directory and subdirectory such as /mnt and /mnt/inst, shares to /mnt/inst must be explicitly mounted.
Export only if mounted	mp Requires the export point to also be a mount point on the client.
Optional mount point	Specifies a mount directory for mp; must be used by the client.
Set explicit filesystem ID	fsid Specifies a numeric identifier for the exported filesystem.

Table 10-2: NFS Tool User Access Options
Parameter	Corresponding /etc/exports Command and Explanation
Treat remote root user as local root	no_root_squash Remote root users get root privileges on the shared directory.
Treat all client users as anonymous users	all_squash All remote users are mapped as an anonymous user. In RHEL 3, that user is nfsnobody, which you can see in /etc/passwd.
Specify local user ID for anonymous users	anonuid=userid Allows you to map remote users to a specific user ID such as pcguest.
Specify local group ID for anonymous users	anongid=groupid Allows you to map remote groups to a specific group ID such as pcguest.

Unfortunately, the NFS Server Configuration tool does not activate NFS at the appropriate runlevels for the next time you boot Linux.

If you need to run NFS through a firewall, return to the NFS Server Configuration tool. Click File | Server Settings. Set unused ports for the noted services:

rpc.lockd (TCP)
rpc.lockd (UDP)
rpc.mountd (TCP)
rpc.statd (TCP)

In Linux documentation, common ports for these services are 32764, 32765, 32766, and 32767. But these ports are cited only because they're unused in /etc/ services. You'll also need to designate a port for the rpc.rquotad service in /etc/ services. If rpc.rquotad is running, you'll have to stop and restart the daemon.

Exam Watch

If you use Red Hat's NFS Server Configuration tool, don't forget to activate NFS at the appropriate runlevels (at least 3 and 5) so your shared directories are available when your instructor reboots your computer to see what you've done. And remember, that's what you need to do in real life-what good is it if you've shared a directory over NFS if the service isn't running?

Whatever ports you choose, you'll need to make sure that these ports (as well as TCP and UDP ports 111 for the portmap daemon) are allowed through any configured firewall. For more information, see Chapter 15.

Making NFS Work with SELinux

There are four directives associated with making NFS work with SELinux in targeted mode:

allow_gssd_read_tmp supports the reading of temporary directories by the General Security Services daemon, gssd, which helps protect NFS using Kerberos 5.
allow_nfsd_anon_write supports NFS servers when they modify files on public file transfer services.
nfs_export_all_ro supports read-only access to shared NFS directories.
nfs_export_all_rw supports read-write access to shared NFS directories.

To set these directives, use the setsebool command. For example, to activate read-write access, run the following command:

 # setsebool -P nfs_export_all_rw 1

Quirks and Limitations of NFS

NFS does have its problems. Any administrator who controls shared NFS directories would be wise to take note of these limitations.

Statelessness

NFS is a "stateless" protocol. In other words, you don't need to log in separately to access a shared NFS directory. Instead, the NFS client normally contacts rpc.mountd on the server. The rpc.mounted daemon handles mount requests. It checks the request against currently exported filesystems. If the request is valid, rpc.mounted provides an NFS file handle (a "magic cookie"), which is then used for further client/server communication for this share.

The stateless protocol allows the NFS client to wait if the NFS server ever has to be rebooted. The software waits, and waits, and waits. This can cause the NFS client to hang.

This can also lead to problems with insecure single-user clients. When a file is opened through a share, it may be "locked out" from other users. When an NFS server is rebooted, handling the locked file can be difficult. The security problems can be so severe that NFS communication is blocked even by the default Red Hat Enterprise Linux firewall.

In theory, the recent change to NFS, setting up sync as the default for file transfers, should help address this problem. In theory, locked-out users should not lose any data that they've written with the appropriate commands.

Absolute and Relative Symbolic Links

If you have any symbolic links on an exported directory, be careful. The client interprets a symbolically linked file with respect to its own local filesystem. Unless the mount point and filesystem structures are identical, the linked file can point to an unexpected location, which may lead to unpredictable consequences.

You have a couple of ways to address this issue. You can take care to limit the use of symbolic links within an exported directory. Alternatively, NFS offers a server-side export option (link_relative) that converts absolute links to relative links; however, this can have counterintuitive results if the client mounts a subdirectory of the exported directory.

Root Squash

By default, NFS is set up to root_squash, which prevents root users on an NFS client from gaining root access to a share on an NFS server. Specifically, the root user on a client (with a user ID of 0) is mapped to the nfsnobody unprivileged account (yes, this user exists if you've installed the right packages-check your /etc/passwd file).

This behavior can be disabled via the no_root_squash server export option in /etc/exports. For exported directories so disabled, remote root users can use their root privileges on the shared NFS directory.

NFS Hangs

Because NFS is stateless, NFS clients may wait up to several minutes for a server. In some cases, an NFS client may wait indefinitely if a server goes down. During the wait, any process that looks for a file on the mounted NFS share will hang. Once this happens, it is generally difficult or impossible to unmount the offending filesystems. You can do several things to reduce the impact of this problem:

Take great care to ensure the reliability of NFS servers and the network.
Avoid mounting many different NFS servers at once. If several computers mount each other's NFS directories, this could cause problems throughout the network.
Mount infrequently used NFS exports only when needed. NFS clients should unmount these clients after use.
Set up NFS shares with the sync option, which should at least reduce the incidence of lost files.
Don't configure a mission-critical computer as an NFS client, if at all possible.
Keep NFS mounted directories out of the search path for users, especially that of root.
Keep NFS mounted directories out of the root (/) directory; instead, segregate them to a less frequently used filesystem, if possible, on a separate partition.

Inverse DNS Pointers

An NFS server daemon checks mount requests. First, it looks at the current list of exports, based on /etc/exports. Then it looks up the client's IP address to find its host name. This requires a reverse DNS lookup.

This host name is then finally checked against the list of exports. If NFS can't find a host name, rpc.mountd will deny access to that client. For security reasons, it also adds a "request from unknown host" entry in /var/log/messages.

File Locking

Multiple NFS clients can be set up to mount the same exported directory from the same server. It's quite possible that people on different computers end up trying to use the same shared file. This is addressed by the file-locking daemon service.

NFS has historically had serious problems making file locking work. If you have an application that depends on file locking over NFS, test it thoroughly before putting it into production.

On the Job

There may still be "file-locking" issues with other applications; for example, file locking was only recently incorporated in the OpenOffice.org suite, which prevents different users from editing the same file simultaneously.

Performance Tips

You can do several things to keep NFS running in a stable and reliable manner. As you gain experience with NFS, you might monitor or even experiment with the following factors:

Eight kernel NFS daemons, which is the default, is generally sufficient for good performance, even under fairly heavy loads. If your NFS server is busy, you may want to add additional NFS daemons through the RPCNFSDCOUNT directive in the /etc/init.d/nfs script. Just keep in mind that the extra kernel processes consume valuable kernel resources.
NFS write performance can be extremely slow, particularly with NFS v2 clients, as the client waits for each block of data to be written to disk.
You may try specialized hardware with nonvolatile RAM. Data that is stored on such RAM isn't lost if you have trouble with network connectivity or a power failure.
In applications where data loss is not a big concern, you may try the async option. This makes NFS faster because async NFS mounts do not write files to disk until other operations are complete. However, a loss of power or network connectivity can result in a loss of data.
Host name lookups are performed frequently by the NFS server; you can start the Name Switch Cache Daemon (nscd) to speed lookup performance.

On the Job

NFS is a powerful file-sharing system. But there are risks associated with NFS. If an NFS server is down, it could affect your entire network. It's also not sufficiently secure to use on the Internet. NFS is primarily used on secure networks.

NFS Security

NFS includes a number of serious security problems and should never be used in hostile environments (such as on a server directly exposed to the Internet), at least not without strong precautions.

Shortcomings and Risks

NFS is an easy-to-use yet powerful file-sharing system. However, it is not without its problems. The following are a few security issues to keep in mind:

Authentication NFS relies on the host to report user and group IDs. However, this can expose your files if root users on other computers access your NFS shares. In other words, data that is accessible via NFS to any user can potentially be accessed by any other user.
Privacy Not even "secure" NFS encrypts its network traffic.
portmap infrastructure Both the NFS client and server depend on the RPC portmap daemon. The portmap daemon has historically had a number of serious security holes. For this reason, portmap is not recommended for use on computers that are directly connected to the Internet or other potentially hostile networks.

Security Tips

If NFS must be used in or near a hostile environment, you can reduce the security risks:

Educate yourself in detail about NFS security. If you do not clearly understand the risks, you should restrict your NFS use to friendly, internal networks behind a good firewall.
Export as little data as possible, and export filesystems as read-only if possible.
Use the root_squash option to prevent clients from having root access to exported filesystems.
If an NFS client has a direct connection to the Internet, use separate network adapters for the Internet connection and the LAN.
Use appropriate firewall settings to deny access to the portmapper and nfsd ports, except from explicitly trusted hosts or networks. For more information, see Chapter 15. The known ports are
```
 111     TCP/UDP      portmapper      (server and client) 2049    TCP/UDP      nfsd            (server) 
```
Fix the port associated with NFS; it's possible in /etc/sysconfig/nfs with the following directives (which are read by the /etc/init.d/nfs script). You can choose a different port number; it should be unused in /etc/services and remembered when a firewall is configured:
```
 LOCKD_TCPPORT=32765 LOCKD_UDPPORT=32765 MOUNTD_PORT=32767 STATD_PORT=32766 
```
Create a port for rquotad in /etc/services, stop, and restart the rpc.quotad daemon.
Use a port scanner to verify that these ports are blocked for untrusted network(s).

Exam Watch

While some may find it easier to learn with GUI tools, these tools are usually more time consuming and less fl exible than direct action from the command line. As time is often short on the RHCE exam, I recommend that you learn how to configure and activate NFS and other services from the command line.

Exercise 10-1: NFS

This exercise requires two computers: one set up as an NFS server, the other as an NFS client. For this exercise, disable any currently active firewall and SELinux protection. Then, on the NFS server, take the following steps:

Set up a group named IT for the Information Technology group in /etc/group.
Create the /MIS directory. Assign ownership to the MIS group with the chgrp command.
Set the SGID bit on this directory to enforce group ownership.
Update /etc/exports file to allow read and write for your local network. Run the following command to set it up under NFS:
```
 # exportfs -a 
```
Restart the NFS service.

Then, on an NFS client, take the following steps:
Create a directory for the server share called /mnt/MIS.
Mount the shared NFS directory on /mnt/MIS.
List all exported shares from the server and save this output as /mnt/MIS/shares.list.
Make this service a permanent connection in the /etc/fstab file. Assume that the connection might be troublesome and add the appropriate options, such as soft mounting.
Run the mount -a command to reread /etc/fstab. (This is quicker than rebooting the client computer.) Check to see if the share is properly remounted.
Test the NFS connection. Stop the service on the server, and then try copying a file to the /mnt/MIS directory. While the attempt to copy will fail, it should not hang the client.
Restart the NFS server.
Edit /etc/fstab again. This time, assume that NFS is reliable, and remove the special options that you added in step 9.
Now test what happens when you shut down the server. The mounted NFS directory on the client should hang when you try to access the service.
The client computer will probably lock. If so, reboot the client computer; you may need to boot into single-user mode, as described in Chapter 3, to boot without being locked by an NFS problem. Restore the original configuration.

Exam Watch

Remember that one of the tasks during the Troubleshooting and System Maintenance portion of the RHCE exam is to diagnose and correct problems with network services, including NFS. This exercise illustrates one potential problem with NFS.

Exercise 10-2: Using the NFS Server Configuration Tool

In this exercise, you'll use the options associated with the NFS Server Configuration tool to experiment with creating a shared directory in /etc/exports. While it's best and usually fastest to edit a Linux configuration file directly, Red Hat GUI configuration tools such as the NFS Server Configuration tool can help you learn about different options for Linux services.

Open a GUI on an RHEL computer. Log in using the graphical login menu; or, from a text menu, use the startx command.
Start the NFS Server Configuration tool. You can run system-config-nfs from a command line interface, or choose GNOME's System (or KDE Main Menu) | Administration | Server Settings | NFS.
In the NFS Server Configuration tool, click Add. This opens the Add NFS Share window with the Basic tab. Set up a share for your home directory. Share it with one specific host on your LAN, with read-only permissions.
Click the General Options tab. Select the options of your choice. It does not matter what you select; the purpose of this lab is to demonstrate the effect of the NFS Server Configuration tool on the /etc/exports file.
Click the User Access tab. Select the options of your choice.
Click OK. The settings you chose are saved in /etc/exports.
Open a command line window. Right-click the desktop, and select New Terminal from the pop-up menu that appears.
Open the /etc/exports file in the text editor of your choice. What is the relationship between the options you selected in the NFS Server Configuration tool and the command options associated with your home directory in /etc/exports? Close the /etc/exports file.
Back in the NFS Server Configuration tool, highlight the line associated with your home directory, and then click Properties. This opens the Edit NFS Share window with the settings that you just created.
Make additional changes under the three tabs in this window. After you click OK, check the results in /etc/exports. What happened?
If you don't actually want to export your home directory, highlight the appropriate line in the NFS Server Configuration tool and click Delete. What happens to /etc/exports?
Click the Server Settings button, which opens the NFS Server Settings window. Assign otherwise unused ports above 1024 (and below 65535) to the given daemons. To see if a port is used, check /etc/services. To make sure the port you select is unused, check /etc/exports. Click OK and check the result in /etc/sysconfig/nfs. Review the directives, and look at their impact on /etc/init.d/nfs.

Open up /etc/services, and set TCP and UDP ports for the rquotad service. Stop and start the rpc.rquotad daemon, and make sure the new ports are actually being used with the rpcinfo -p command.

When you fix ports for NFS, you can set up a firewall that allows traffic through the ports you set in /etc/sysconfig/nfs. For more information, see Chapter 15.
Exit from the NFS Server Configuration tool.