Configuring Network File System Servers

The Network File System (NFS) is fundamental to Linux. In fact, one of the basic NFS configuration files is included in the same setup-* RPM package as /etc/passwd and /etc/profile . Yet managing NFS means that you need to pay attention to a number of different daemons.

Setting up exports from an NFS server is relatively easy. Basically, all you need to do is add a line for each shared directory to /etc/exports and share it with the network, and you re on your way. But pay attention to the syntax; the right commands help you secure the directories that you share through NFS.

One key to NFS is the remote procedure call (RPC), which allows you to seamlessly run commands on remotely mounted directories. All of the NFS daemons use RPC.

The GUI configuration tool for NFS, redhat-config-nfs , can help you configure simple shared directories. Remember, this GUI tool is just a front end for what you ll learn in this chapter about configuring NFS.

NFS Packages

The packages you need for NFS may already be installed. Some of these packages are fundamental to a smoothly running Linux system. Table 28.1 lists the packages associated with NFS. As we explained in Chapter 10 , you can run the rpm -qi packagename command to learn more about each package.

Table 28.1: NFS- Related RPM Packages

Package

Function

setup-*

Shared NFS directories are defined in /etc/exports .

initscripts-*

Includes the basic scripts for mounting network directories during the boot process.

nfs- utils -*

Includes basic NFS commands and daemons.

portmap-*

Supports secure NFS remote procedure call (RPC) connections.

quota-*

Includes rpc.rquotad for quotas on directories shared over a network; this package is not required.

Basic Daemons

At least five Linux services are required to run NFS smoothly. They each relate to different functions, from mounting to making sure that remote commands get to the right place. These services are started through the nfs , nfslock , and portmap scripts in the /etc/rc.d/init.d directory. Here s a brief description of each daemon:

The basic NFS Naturally, there is an NFS server daemon, rpc.nfsd , that s started through the nfs script in the /etc/rc.d/init.d directory. The NFS daemon also starts the mount daemon ( rpc. mountd ) and exports shared directories. You can implement configuration changes by stopping and restarting the NFS service.

RPC mount While you can use the mount command to connect to local directories (such as from a floppy) or network directories (such as from a Samba server), there is a special daemon for mounting NFS directories: rpc.mountd .

The portmapper While the portmap daemon just directs RPC traffic, it is essential to NFS service. If portmap is not running, NFS clients can t find directories shared from NFS servers.

Reboots and statd There will be times when your connection to an NFS server goes down. You may have a scheduled reboot, or your server may just have crashed. The rpc.statd daemon works with rpc.lockd to help clients recover NFS connections after an NFS server reboots.

Locking When files are opened through a shared NFS directory, a lock is added. The lock prevents users from overwriting the same file with different changes. Locking is run through the rpc.lockd daemon, via the nfslock script.

Setting Up Exports

Shared NFS directories are listed in /etc/exports . As an example, assume you have one CD drive on your NFS server that you want to share with the other computers on your LAN. Normally, CDs are mounted on the /mnt/ cdrom directory. You also want to share the /tmp directory to help share special packages. The format is simple:

  sharedirectory   hosts(specs)  

In other words, in /etc/exports , you specify the directory that you want to share, the computers that you want to share with, and the limits that you need. Let s look at a couple of examples of how you might do this:

 /mnt/cdrom *.example.com(ro,sync) big.example.com(rw,sync) /tmp  *(rw,insecure,sync,no_wdelay,anonuid=600) 

The shareddirectory is self-explanatory. There are several ways to specify the computers that you want to share with; while you can use IP addresses, NFS does not recognize CIDR notation. Several examples are shown in Table 28.2.

Table 28.2: Specifying Hosts in /etc/exports

Example

Explanation

*.example.com

All computers in the example.com domain

newcomp

The computer named newcomp

10.11.12.13/255.255.255.0

The network with the specified IP address and subnet mask

Finally, you must specify if and how you want to limit access to the shared directory. Do you want it shared as a read-only filesystem? Do you intend to share all subdirectories of a shared directory? Do you want to give the root user from a specific computer root-level access through the directory? While the options shown in this section may be a bit cryptic, you can specify these parameters and more in /etc/exports , as described in Table 28.3.

Table 28.3: /etc/exports Shared Directory Specifications

Spec

Effect

ro

If a directory is mounted ro , users can only have read-only access to it (default).

rw

If a directory is mounted rw , users can read or write to it.

sync

All data is written to a share as requested .

async

NFS may respond to a request before writing data.

secure

NFS requests (default) are sent through a secure TCP/IP port below 1024; default medium- and high-security firewalls block these ports.

insecure

NFS requests are sent through TCP/IP ports above 1024.

wdelay

If more than one computer is about to write to a shared NFS directory, the writes are grouped together (default).

no_wdelay

If more than one computer is about to write to a shared NFS directory, the data is written immediately; if you ve set async , this setting is not required.

hide

NFS by default shares directories, such as /home/mj , without sharing their subdirectories, such as /home/mj/.kde .

no_hide

When you share an NFS directory, this automatically also shares the subdirectories.

subtree_check

If you export a subdirectory such as /usr/sbin , this forces the NFS server to check lower-level directories (e.g., /usr ) for permissions (default).

no_subtree_check

If you export a subdirectory, such as /home/mj , it does not check the higher-level directory, such as /home , for permissions.

insecure_locks

For older NFS clients, this does not check if a user has read access to a requested file; same as no_auth_nlm .

secure_locks

For older NFS clients, this checks for user permissions on a requested file (default); same as auth_nlm .

all_squash

The UID and GID of exported files are mapped to the user anonymous; good for public directories.

no_all_squash

The UID and GID of exported files are retained (default).

root_squash

All requests from the user root are translated or mapped as if they came from the user anonymous (default).

no_root_squash

This allows the root user to have full administrative access through the shared directory.

anonuid=xyz

This specifies the UID of the anonymous user in the NFS server s /etc/passwd file.

anongid=xyz

This specifies the GID of the anonymous group in the NFS server s /etc/group file.

Starting with Red Hat Linux 8.0, you now need to specify sync or async for any shared directory. In other words, you have to specify whether the shared NFS directory responds to a command before a file is written permanently, such as to a hard disk.

Now that you ve seen what can go into an /etc/exports file, return to the earlier example. It should make sense to you now:

 /mnt/cdrom *.example.com(ro,sync) big.example.com(rw,sync) /tmp  *(rw,insecure,sync,no_wdelay,all_squash,anonuid=600) 

The first line shares the /mnt/cdrom directory with all computers in the example.com domain. This directory is read-only, unless the connection is made from the computer named big.example.com . (Naturally, this works only if your CD is writeable .)

The next line shares the /tmp directory with all computers. Computers that connect to this share can read or write ( rw ) to /tmp . The requests can be sent through TCP/IP ports above 1024 ( insecure ). Requests are written to /tmp before anything else is done ( sync ). Data is written immediately to disk, even if other computers that are sharing this directory are also about to write a file ( no_wdelay ). When mounting this directory, all users are given permissions associated with UID 600 in the NFS server s /etc/passwd file.

Securing NFS

You can configure security for shared NFS directories at two levels: through the settings in /etc/ exports and through a firewall. You ve just looked at /etc/exports . When you want to block NFS shared directories to outside networks, you may want to use appropriate iptables commands or even appropriate commands in /etc/hosts.allow and/or /etc/hosts.deny .

But sometimes, you may want to let users get to shared NFS directories through a firewall. While allowing NFS connections through the Internet is strongly discouraged, allowing NFS connections between LANs internal to a company or organization is probably safe.

When thinking of NFS security and firewalls, you need to consider two TCP/IP ports: 111 and 2049. As you can see from /etc/services , port 111 is related to the portmap daemon, and port 2049 is the channel for NFS.

NFS and an iptables Firewall

We discussed the basics of iptables in Chapter 22 . As we discussed in Chapters 3 and 19 , the Red Hat Linux firewall tools lokkit and redhat-config-securitylevel allow you to configure standard high or medium firewalls.

The default high-security firewall blocks all network communication, except responses from DNS servers. Naturally, the two TCP/IP ports required for NFS communication are also blocked.

The default medium-security firewall, as shown in Figure 28.1, blocks all communication on all ports between 0 and 1023, which includes the standard portmap port 111. It also explicitly rejects data moving on NFS port 2049.

click to expand
Figure 28.1: A standard medium firewall
Note  

For more information on the format of iptables firewalls, see Chapter 22 .

First, delete the rules that REJECT NFS data. As you can see from Figure 28.1, these rules are third and fifth in sequence in the RH-Lokkit-0-50-INPUT firewall. Therefore, you ll want to run these commands:

 # iptables -D RH-Lokkit-0-50-INPUT 5 # iptables -D RH-Lokkit-0-50-INPUT 3 

Next, make sure that the firewall accepts input through port 111. As you may remember from Chapter 22 , you can add rules with the -I switch. For example, the following commands accept TCP and UDP inputs through port 111 as the second and third commands in the firewall:

 # iptables -I RH-Lokkit-0-50-INPUT 2 -p tcp -m tcp --dport 111 -j ACCEPT # iptables -I RH-Lokkit-0-50-INPUT 3 -p udp -m udp --dport 111 -j ACCEPT 

Once you re satisfied with the changes, save the firewall for the next time you boot Linux by issuing this command:

 # iptables-save > /etc/sysconfig/iptables 

Now you should be able to set up NFS connections through your firewall.

Note  

As described in Chapter 22 , you can also save new firewall rules in /etc/sysconfig/iptables with the service iptables save command.

NFS and a TCP Wrappers Firewall

In Chapter 23 , we discussed another Linux firewall related to xinetd services. With the wrong commands in /etc/hosts.deny , you can block the portmap , rpc.mountd , rquotad , statd , and lockd services. For example, the simplest firewall in /etc/hosts.deny blocks everything:

 ALL:ALL 

You might recall that xinetd reads /etc/hosts.allow first. So you can let the portmap through this firewall with a simple command. For example, you could add this command in /etc/hosts.allow to let portmap through for the given network IP address (192.168.0.0):

 portmap: 192.168.0.0/255.255.255.0 

Use the same techniques with the other NFS-related services. Remember, CIDR notation such as 192.168.0.0/24 is not allowed in either the /etc/hosts.allow or /etc/hosts.deny file.

Starting NFS

You ve configured exports. You ve customized any firewall you may have. Finally, you re ready to start NFS and export the directories that you plan to share.

Start with the rpcinfo -p command. If NFS is running properly, you should see entries for at least portmap , nfs , and mountd , similar to what is shown in Figure 28.2.

click to expand
Figure 28.2: Checking NFS daemons

If you don t, NFS isn t ready, and you need to start these daemons. If necessary, you should be able to start the rpc.mountd and nfs daemons with the service nfs start command. You should also be able to start the portmap daemon with the service portmap start command.

Once the service is started, you can export the shared directories with the appropriate exportfs command. Some of the options are listed in Table 28.4.

Table 28.4: exportfs Commands

Command

Function

exportfs -a

Exports all shared directories from /etc/exports

exportfs -r

Revises the list of shared directories after you ve changed /etc/exports

exportfs -u

Unexports all directories

exportfs -v

Displays currently shared directories

Now you re ready to connect to a shared directory from an NFS client computer. But there s one thing left to do: make sure that the right services will start the next time you boot Linux. As discussed in Chapter 13 , you can do this with the proper chkconfig command. The following commands check the runlevels at which the nfs and portmap daemons start:

 # chkconfig --list nfs # chkconfig --list portmap 

And if necessary, the following commands make sure that these daemons start at the appropriate runlevels. When the nfs daemon starts, it also starts rpc.mountd and, if available, the rpc.rquotad daemon as well.

 # chkconfig --level 235 portmap on # chkconfig --level 235 nfs on 
 


Mastering Red Hat Linux 9
Building Tablet PC Applications (Pro-Developer)
ISBN: 078214179X
EAN: 2147483647
Year: 2005
Pages: 220

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net