15.4. NFS and NIS Configuration
Once you have TCP/IP enabled on your system, you may wish to configure your system to use the Network File System (NFS) or 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 (formerly known as the Yellow Pages, or YP, service) 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 into 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 into 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.
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'll show you how to configure your system as an NFS and NIS client; that 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 there are many subtle issues involved in configuring any Unix or Linux system as an NFS/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 of the specifics.
15.4.1. Configuring NFS
Configuring your system to mount remote filesystems over NFS is a breeze. Assuming that you have TCP/IP configured and hostname lookup works correctly, you can simply add a line to your /etc/fstab file such as the following:
As with regular filesystem mounts, be sure to create the mount-point directory (in this case /fsys/allison/usr) first. The line in /etc/fstab example allows your system to mount the directory /usr from the machine allison on the network.# device directory type options allison:/usr /fsys/allison/usr NFS defaults
Before the example NFS mount will work, however, the system administrator for the NFS server (here allison) must configure the system 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 simple command. Exporting a directory makes it available for other systems to mount it using NFS. It is not necessary for the exported directory to be the root of a filesystem itself; that is, you can export /usr even if /usr does not have its own separate filesystem.
In exporting a directory, the administrator may choose to make the directory available for read-only access. In this case you will not be able to write to the filesystem when mounted on your system. You should set the options field of the/etc/fstab line in the previous example to ro instead of defaults.
A few words of warning about NFS.
First of all, NFS 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, you can attempt to unmount any remote filesystems from the affected servers.
Another detail to watch out for when mounting NFS filesystems is the owner (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 ID 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 ). This approach requires you to chown and chgrp all of 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. For this reason, you will not have omnipotent power to access or modify remote-mounted files when logged in as root on your local system.
15.4.2. Configuring NIS
NIS is a complex system, simply because it is so flexible. NIS is a general-purpose network database system, allowing 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 ), for example, to be maintained on a single server 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. NIS clients are those systems that request database information from servers or slaves. 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.
To completely understand how NIS works and to maintain an NIS server is enough material for a whole book (again, Managing NFS and NIS). However, when reading about NIS you are likely to come across various terms. NIS was originally named YP. This usage has been discontinued as Yellow Pages is trademarked in the United Kingdom (it's the phone book, after all).
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 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. On the other hand, the new glibc2 standard C library comes with support for NIS+. 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 the NIS and NYS implementations, meaning that no matter which is installed on your system, it should be able to act as a client.
We do assume here that you have 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 administrators 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 different, for 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:
for example, domainname vpizzas. The command itself is usually found in /sbin/domainname and may have a slightly different name, such as domainname-yp.domainname domain-name
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:
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 administrators can provide you with the hostname of your preferred NIS server.domain vpizzas ypserver allison.vpizza.com
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 queries specific NIS databases, for example:
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.ypwhich username passwd
Copyright © 2001 O'Reilly & Associates. All rights reserved.