Building Tablet PC Applications (Pro-Developer)
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.
| 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.
| 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.
| 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.
| 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.
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.
| 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