Section 15.2. NFS Configuration and NIS

15.2. NFS Configuration and NIS

When TCP/IP is configured, most Linux distributions support the Network File System (NFS) and the Network Information Service (NIS). NFS allows your system to share files directly with a network of machines. File access across NFS is transparent; you simply access the files as if they were stored on your local disk. In system administration terms, one system mounts another's filesystem on a local directory, just as a local filesystem can be mounted. NFS also allows you to export filesystems, allowing other systems on the network to mount your disks directly.

NIS is a system that allows your host to obtain information automatically on user accounts, groups, filesystem mount points, and other system databases from servers on the network. For example, let's say you have a large collection of machines that should have the same user accounts and groups (information usually found in /etc/passwd and /etc/group). Users should be able to log in to any of these machines and access their files directly (say, by mounting their home filesystem from a central location using NFS). Obviously, maintaining user accounts across many machines would be problematic; in order to add a new user, you would need to log in to each machine and create the user account on each. When you use NIS, however, the system automatically consults centrally maintained databases across the network for such information, in addition to local files such as /etc/passwd. NIS+ is an enhanced NIS service that is coming into use at some sites.

There are two sides to NFS. It is possible to export parts of the filesystem on your server or workstation so that other users can access its files and directories, and it is possible to mount remote resources on your workstation, or server, so they are available locally in like manner to local physical disk resources. NFS resources are exported by an NFS server. Locally mounted NFS resources are available on an NFS client.

You should be aware that NFS provides absolutely no encryption. If you mount your filesystems over the Internet, the transferred files can be interfered and even tampered with at any time (some people joke that NFS is short for "No File Security"). On the other hand, NFS mounts beyond your local network are probably too slow to be useful anyway, unless you are on a really big pipe.

If your Linux system is to interact with other systems on a LAN, it's quite possible that NFS and NIS are in wide use on your LAN. In this section, we show you how to configure your system as an NFS and NIS clientthat is, to mount remote filesystems and to participate in an existing NIS domain. It is possible to configure your system as an NFS and NIS server, but many subtle issues are involved in configuring a system as an NFS or NIS server. Instead of providing a dangerously incomplete account of server configuration here, we refer you to O'Reilly's Managing NFS and NIS by Hal Stern. If you are already familiar with NFS/NIS configuration on other Unix systems, Linux is really no different; the manual pages and Linux HOWTO documents provide all the specifics.

15.2.1. Configuring Your System as an NFS Client

A few words of warning about NFS. First of all, the client is not very happy when the servers for remote filesystems go down or the network connection fails. When the NFS server is unreachable for any reason, your system prints warning messages to the console (or system logs) periodically. If this is a problem, use the standard umount command (introduced in Chapter 10) to unmount any remote filesystems offered by the affected servers.

Another detail to watch out for when mounting NFS filesystems is the user IDs (uids) and group IDs (gids) of the files on the remote filesystem. In order to access your own files via NFS, the user and group IDs for your own account must match those on the NFS server. One easy way to check this is with an ls -l listing: if the uid or gid does not match any local user, ls displays the uid/gid of files as numbers; otherwise, the user or group name is printed.

If IDs do not match, you have a few ways to remedy this problem. One is to simply change the uid of your user account (and the gid of your primary group) to match those on the NFS server (say, by editing your local /etc/passwd file). This approach requires you to chown and chgrp all your local files after making the change. Another solution is to create a separate account with matching uid/gid. However, the best approach may be to use NIS to manage your user and group databases. With this solution, you do not create your user and group accounts locally; instead, they are provided to you by an NIS server. More on this later.

Another NFS caveat is the restriction of root permissions on NFS-mounted filesystems. Unless the NFS server explicitly grants your system root access on NFS-mounted filesystems, you will not have total access to files when logged in as root on your local system. The reason for this is security: allowing unlimited root access to files on a remote-mounted NFS filesystem opens itself up to abuse, especially when the NFS server and the NFS client are maintained or owned by different people.

NFS clients can make use of exported NFS resources in a number of ways:

Automatic boot-time mounting through the /etc/fstab file
Manual mounting from a shell command line
Automated mount via the automount daemon

Discussion of the automount daemon is beyond the scope of this chapter; refer to Chapter 10 for further information. The next sections contain a simplified overview of the two other methods.

15.2.1.1. Using /etc/fstab NFS client entries

Configuring your system to mount remote filesystems over NFS is a breeze. Assuming that you have TCP/IP configured and that hostname lookup works correctly, you can simply add a line to your /etc/fstab file such as the following:

     # device        directory           type  options   dump fsckorder     allison:/usr    /fsys/allison/usr   nfs   defaults  0    0

This line is similar to fstab for partitions on a local system, but the name of the remote system appears in the first column, and the mount type is nfs. This line will cause the remote /usr on the machine allison to be mounted at boot time at the directory mount point /fsys/allison/usr.

As with regular filesystem mounts, be sure to create the mount-point directory (in this case, /fsys/allison/usr) before letting the system mount the remote directory. The line in the /etc/fstab example allows your system to mount the directory /usr from the machine allison on the network.

The mount can be specified with various options. Two commonly used options are soft and hard. The soft mounting option means that when a file access request fails, the NFS client will report an error to the process that makes the request. Some application handle that error report gracefully, and some do not. The hard mounting option means that the NFS client will hang when the NFS server ceases to respond to file access requests. You should read the manpage for the mount on your Linux system to explore the finer points of each of the possible options.

Don't forget to check the ro and rw options as well. When exporting a directory, the administrator may choose to make the directory available for read-only access, in which case you will not be able to write to the filesystem when mounted on your system. In this case, you should set the options field of the /etc/fstab line in the previous example to ro instead of defaults.

Make sure the administrator of the remote system has exported the desired directory (see "Adding a directory to the NFS server's exports," later in this chapter) and test your configuration by issuing a mount as root:

     # mount allison:/usr

15.2.1.2. Finding NFS exported resources and diagnosing problems

Sometimes you know that there should be an NFS filesystem resource (a share) on a particular server, but you do not know whether the NFS server is running, or perhaps you do not know the correct name of the shared resource. Here is an example to show how you can find out what is available. In this example there are three NFS servers: merlin, frodo, and sunsol. Let's see what NFS resources are available on each.

The utility that can be used to examine the availabilty of NFS services is called showmount. This tool is normally only available to the root user. We will examine all three machines as shown here:

     linux:~ # showmount -e merlin     Export list for merlin:     /srv  *.myworld.org,192.168.1.0/24     /data *.myworld.org,192.168.1.0/24

The machine merlin has two NFS exports. They may be used only by NFS clients in the myworld.org domain, as well as from any IP address in the 192.168.1.0 network. Let's see what surprises the machine sunsol has for you:

     linux:~ # showmount -e sunsol     Export list for sunsol:     /export (everyone)

The /export directory has been exported to the whole world. It is just as well that this resource is inside a private network and not on a machine that is exposed to the Internet. Just for the record, anyone can mount an export that is world-readable. If it is also capable of being written, that does not make for a particularly secure system!

Finally, let's see what happens when we request NFS export information from a server on which the NFS server service is not running. Let's ask the machine frodo, on which the NFS has apparently failed or has been stopped for some reason:

     linux:~ # showmount -e frodo     mount clntudp_create: RPC: Program not registered

You can see that the Remote Procedure Call (RPC) process over which NFS resources are shared is not running. RPC is a protocol for client-server communication. It is possible to check what RPC services are running using the rpcinfo utility. In this case, we will check the difference in services available from the machines merlin and frodo, as shown here:

     linux:~ # rpcinfo -p merlin        program vers proto   port         100000    2   tcp    111  portmapper         100000    2   udp    111  portmapper         100003    2   udp   2049  nfs         100003    3   udp   2049  nfs         100227    3   udp   2049  nfs_acl         100003    2   tcp   2049  nfs         100003    3   tcp   2049  nfs         100227    3   tcp   2049  nfs_acl         100024    1   udp   1254  status         100021    1   udp   1254  nlockmgr         100021    3   udp   1254  nlockmgr         100021    4   udp   1254  nlockmgr         100024    1   tcp   4777  status         100021    1   tcp   4777  nlockmgr         100021    3   tcp   4777  nlockmgr         100021    4   tcp   4777  nlockmgr         100005    1   udp    645  mountd         100005    1   tcp    648  mountd         100005    2   udp    645  mountd         100005    2   tcp    648  mountd         100005    3   udp    645  mountd         100005    3   tcp    648  mountd

The nlockmgr RPC service provides file-locking capabilities over NFS-mounted connections, and the nfs_acl RPC service provides POSIX Access Control List (ACL) file security controls. Here is the result of asking the same question of the machine frodo:

     linux:~ # rpcinfo -p frodo        program vers proto   port         100000    2   tcp    111  portmapper         100000    2   udp    111  portmapper         100024    1   udp  32768  status         100021    1   udp  32768  nlockmgr         100021    3   udp  32768  nlockmgr         100021    4   udp  32768  nlockmgr         100024    1   tcp  32768  status         100021    1   tcp  32768  nlockmgr         100021    3   tcp  32768  nlockmgr         100021    4   tcp  32768  nlockmgr

The nfs RPC service is not available. Moments later we executed the command again to obtain this result:

     linux:~ # rpcinfo -p frodo     rpcinfo: can't contact portmapper: RPC: Remote system error - Connection refused

This means that the portmapper service that provides the RPC capabilities has been shut down. This may have been done to permit some maintenance procedures to be performed, or the server may be in the process of being shut down.

By now, you should be getting some clues for finding and diagnosing NFS availability as well as potential causes of NFS problems.

15.2.1.3. Manual mounting of NFS filesystems

It is possible to determine what NFS filesystems are currently mounted on your Linux system by using the mount utility:

     linux:~ # mount -t nfs     merlin:/data on /data type nfs (rw,addr=192.168.1.4)     merlin:/srv on /msrv type nfs (rw,addr=192.168.1.4)     sunsol:/export on /mnt type nfs (ro,addr=192.168.1.6)

The NFS filesystem resources from the machine merlin have been mounted so that they are capable of read/write access. The resource on the machine sunsol has been mounted with read-only access capability.

Assuming you want to mount the /export/work resource from the machine sunsol on your Linux workstation at the directory mount point /home/work, here is the command to use:

     linux:~ # mkdir /home/work     linux:~ # mount sunsol:/export/work /home/work

The df command will help to show that it is mounted, as well as the disk space available:

     linux:~ # df /home/work     Filesystem           1K-blocks      Used Available Use% Mounted on     sunsol:/export/work   17645600   3668352  13800800  21% /home/work

When it is necessary to unmount an NFS mounted resource, simply do this:

     linux:~ # umount /home/work

With a little practice, you will soon be an expert at using the NFS client facilities.

15.2.1.4. Adding a directory to the NFS server's exports

As we said earlier, we will not try to tell you how to configure an NFS server, but we'll briefly explain how to export a directory once the server is running. In our example, the system administrator for the allison server must configure it to export the given directory (here, /usr) to your system. On most Unix systems, this is simply a matter of editing a file, such as /etc/exports, or running a command that edits the file. It is not necessary for the exported directory to be the root of a filesystem itself; that is, a server can export /usr even if /usr does not have its own separate filesystem.

Let's take the role of an administrator on an NFS server now and export the /data/accounts directory for use by all NFS clients in the myworld.org DNS domain. These simple steps will achieve this:

Create the /data/accounts directory:
```
     linux:~ # mkdir -p /data/accounts     linux:~ # chmod 770 /data/accounts     linux:~ # chown bill:accounting /data/accounts
```
These commands created the exported directory (it did not exist previously), set the permissions so that group members can access the directory, and then set permissions so that the accounting group can read and write to the directory. Of course, they can also list any files that may be placed within it.

Create the /etc/exports file with the following contents:

     /data/accounts   *.myworld.org(rw,no_root_squash,sync)

Set the ownership and permissions on this file:

     linux:~ # chown root:root /etc/exports     linux:~ # chmod 644 /etc/exports

15.2.2. Configuring Your System as an NIS Client

NIS is not a tool for file and printer sharing, but we present it in this chapter because it shares some components with its cousin NFS, and because it can make NFS easier to administer because NIS allows each user to have the same account number on all systems.

NIS is a complex system, simply because it is so flexible. It is a general-purpose network database system that allows your machine to transparently access information on user accounts, groups, filesystems, and so forth, from databases stored across the network.

One goal of NIS is to ease network management. Allowing user account information (such as that stored in /etc/passwd) to be maintained on a single server, for example, makes it easy for many machines to share the same user accounts. In the previous section on NFS, we showed how user and group IDs on the NFS server and client should match in order to effectively access your files remotely. Using NIS allows your uid and gid to be defined from a remote site, not locally.

If your machine is connected at a site where NIS is used, chances are you can add your machine as an NIS client, thus allowing it to obtain user, group, and other databases directly from the network. To some extent this makes it unnecessary to create local user accounts or groups at all; apart from the locally defined users such as root, bin, and so forth, all other users will be created from the NIS server. If you couple the use of NIS with mounting user home directories from an NFS server, it's also unnecessary to set aside local storage for users. NIS can greatly lessen the amount of work you need to do as a system administrator.

In an NIS configuration, there may be NIS servers, slaves, and clients. As you can guess, servers are the systems where NIS databases originate and are maintained. NIS slaves are systems to which the server copies its databases. The slaves can provide the information to other systems, but changes to the databases must be made from the server. Slaves are simply used as a way to ease the load on the NIS server; otherwise, all NIS requests would have to be serviced by a single machine. NIS clients are systems that request database information from servers or slaves.

To completely discuss how NIS works and how to maintain an NIS server requires enough material for a whole book (again, see Managing NFS and NIS). However, when reading about NIS you are likely to come across various terms. NIS was originally named Yellow Pages. This usage has been discontinued because Yellow Pages is trademarked in the United Kingdom (it's the phone book, after all), but its legacy can still be seen in commands containing the letters yp.

There are at least two implementations of NIS for Linux: the "traditional" NIS implementation and a separate implementation known as NYS (standing for NIS+, YP, and Switch). The NIS client code for the "traditional" implementation is contained within the standard C library and is already installed on most Linux systems. (This is necessary to allow programs such as login to transparently access NIS databases as well as local system files.) The glibc2 standard C library that most distributions use these days comes with support for NIS+. The NYS client code is contained within the Network Services Library, libnsl. Linux systems using NYS should have compiled programs such as login against this library.

Different Linux distributions use different versions of the NIS or NYS client code, and some use a mixture of the two. To be safe, we'll describe how to configure a system for both traditional NIS and NYS implementations, meaning that no matter which is installed on your system, it should be able to act as a client.

To make matters even more complex, some distributions employ the PAM (Pluggable Authentication Modules) system, mentioned in "PAM and Other Authentication Methods" in Chapter 11. In this case, programs such as login are linked against the PAM library, which in turn loads a PAM library module that implements the authentication system in use on the system, or delegates the task to other libraries.

We assume here that an administrator on your local network has installed and started all the necessary NIS daemon processes (such as ypbind) used by traditional NIS to talk to the NIS server. If your Linux system does not appear to have any NIS support, consult documents such as the Linux NIS HOWTO to configure it from scratch. Nearly all current Linux distributions come prepackaged with NIS client (and server) support, and all that's required of you is to edit a few configuration files.

The first step is to set the NIS domain in which your system will be operating. Your network administrator can provide this information to you. Note that the NIS domain name is not necessarily identical to the DNS domain name, which can be set with the hostname command. For example, if the full hostname of your system is loomer.vpizza.com, your DNS domain name is vpizza.com. However, your NIS domain name could be entirely differentfor example, vpizzas. The NIS domain name is selected by the NIS server administrators and is not related to the DNS domain name described earlier.

Setting the domain name is usually a matter of running the domainname command at boot time, perhaps in one of your system rc files (such as /etc/rc.d/rc.inet1, described earlier). You should first check that domainname is not being executed in one of the existing rc files. The command takes the format.

     linux:~ # domainname      domain-name

An example is domainname vpizzas. The command is usually found in /sbin/domainname and may have a slightly different name, such as domainname-yp.

A slightly different method sets the domain name under NYS. You should create (or edit) the file /etc/yp.conf. This file should contain two lines: one specifying the name of your NIS domain, and another specifying the hostname of the NIS server. As an example:

     linux:~ # domain vpizzas     linux:~ # ypserver allison.vpizza.com

sets the NIS domain name to vpizzas and specifies that allison.vpizza.com should be used as the NIS server. If no ypserver line is included in this file, the system broadcasts a message on the network at boot time to determine the name of the NIS server. Your network administrator can provide you with the hostname of your preferred NIS server.

Once these two steps are complete, your system should be able to transparently access NIS databases. One way to test this is to query the system for a password database entry from the NIS server. The ypwhich command queries specific NIS databases. For example:

     linux:~ # ypwhichusername passwd

If this returns the line from the NIS passwd database for the given user, you have successfully queried the NIS database. (One way to verify that the information returned is correct is to run this same command on another system in your NIS domain whose NIS configuration is known to be working.) The NIS passwd database is not identical to the /etc/passwd file on your system, although it is in the same format. The Linux HOWTO documents contain additional information on troubleshooting your NIS configuration.