Introducing the Network Information Service for Linux

As networks of computers grow, it is increasingly important to share common system information between them to present a unified appearance to the computer user. To share files, we use NFS or Samba protocols to communicate with a file server. Mail is often kept in a central location and accessed from clients with POP3 or IMAP protocols. However, most Linux distributions aren't ready “out of the box” to share configuration file information. This doesn't have to be the case.

The Network Information Service (NIS) is a system originally invented by Sun Microsystems for distributing shared configuration files seamlessly across a network. Files such as /etc/passwrd and /etc/group become more and more difficult to maintain by hand as the number of machines grows beyond two or three. For instance, if user foo changes his password on one computer in a work group or cluster, he will probably expect to be able to sit down at a machine across the room and use his new password to log in. However, because the password configuration file is not shared, the reality is that he now has two passwords; the new one on the machine he just sat at and the old one on all the other machines. Each time he uses a new computer he will have to change his password. As the number of machines increases, this becomes more than merely annoying.

While schemes other than NIS exist for keeping files synchronized, they are generally “hacks” involving rcp and cron and leave much to be desired in the way of flexibility. Additionally, NIS has become a UNIX industry standard, supported by many of the commercial UNIX vendors, including IBM (AIX), Hewlett Packard (HP-UX) and of course Sun (SunOS/Solaris). As a result, when setting up Linux computers in a heterogeneous UNIX environment, NIS is often the rule rather than the exception.

There are two major versions of NIS. The first, called NIS but historically referred to as Yellow Pages or YP, is well-supported by Linux. The second, called NIS+, is a new implementation of NIS which attempts to address security issues in the original protocol through encryption and other methods. NIS+ support in Linux is of beta quality and is readily available only in the new glibc/libc6, which currently applies to a very small fraction of the installed Linux base. NIS+ is best suited for very large installations: in most cases the “original” NIS is sufficient and reasonably secure when the proper precautions are taken.

Linux has included most of the components necessary to support NIS for a long time, but unfortunately distributions such as Slackware and Red Hat fail to provide adequate setup information or a complete set of tools.

Documentation has also historically been severely lacking; the NIS-HOWTO was neglected and outdated for a very long time, and it was only in November of 1997 that it finally received some major updates from one of the new NIS maintainers. In general, setting up NIS on Linux has been perceived as one of the hardest administrative tasks an administrator could undertake. I hope to change that sentiment with this article.

NIS support involves several things. To serve configuration files, one computer acts as an NIS “master”. It is possible to have several NIS server machines, but machines in addition to the master are called “slaves” and are provided only for fail-safe redundancy. All of the other computers that receive information from the server computer(s) are called “clients”. This article deals primarily with setting up Linux NIS clients, but describes the basics of configuring Linux to act as a server as well. A description of configuring NIS slaves and other advanced features are beyond the scope of this article. If you need more information in these areas, I suggest that you obtain the excellent book from O'Reilly, Managing NFS and NIS, which, although Sun-oriented, has much information applicable to Linux as well.

If you do not have an NIS master server on your network, you will need to set one up. If you do have one, you can skip this section. The package for setting up NIS servers is logically called ypserv, and the latest stable version at the time of this writing (February) is 1.2.6. Unfortunately, Red Hat 4.2 ships with an older version that you probably don't want to use. There is a contributed RPM in the directory /contrib/hurricane/SRPMS on the Red Hat mirror sites, and if you get the source RPM, you can rebuild it and use it. Otherwise, the URL at which the original distribution can be found is ftp://ftp.uni-paderborn.de/linux/local/yp/.

After configuring and installing the ypserv package (the default locations it specifies are fine), make sure that it will be started at boot time. The RPM will install the appropriate SYSV-style init scripts, but if you are using another Linux, you will have to add a command to start /usr/sbin/ypserv in the configuration file from which network daemons are started, usually /etc/rc.d/rc.inet2.

The files an NIS server makes available to its clients are not the actual local configuration files, but “compiled” versions of these that are referred to as the NIS “maps”. The process of creating NIS maps is done with a Makefile, and so I refer to the process as akin to compiling. NIS maps are in the gdbm UNIX database format for quick random access. The main directory where this all takes place is /var/yp.

You also have to update a few configuration files specifically for your site. If you don't want all the traditional files published via NIS to be available to clients, you will have to edit /var/yp/Makefile and remove the rules for files you wish to omit. A typical rule might look like this:

networks: networks.byaddr networks.byname

A stock Red Hat 4.2 system doesn't come with the /etc/networks file; you will get an error when running make if the file is not present. Comment out this line with a “#” character at the beginning. Luckily, the Makefile has a great deal of documentation included with all the different options so making changes to it is a breeze.

For security reasons you may also want to edit /etc/ypserv.conf and change a few defaults. The man page for ypserv.conf explains each of the options. The most important ones are sunos_kludge, which you will have to set to “yes” if you have old SunOS 4.1.x machines on your NIS network, and the “hosts” section that allows you to include and exclude certain hosts from accessing specific NIS maps on the server. The ypserv daemon also supports the TCP wrappers package, and this gives you another option for fine-grained access control. This is not an article on security, though, so if you are installing the server in an environment where security is of the utmost importance, read the documentation that comes with the server carefully.

You're almost done; the last thing you need to do is to create the initial build of NIS maps from the local configuration files. To do this, run make in /var/yp. This will create a lot of files that you will never have to alter, but these are the files that actually get served to the clients. If you get an error during the make process, chances are that one of the files make is trying to convert to an NIS map is not present. Check for its presence; if it is not there or if you don't want it to be built, comment it out of the Makefile.

If you want users to be able to change their passwords on the client machines instead of only on the server, you must run the rpc.yppasswdd daemon. It comes with the NIS server and has good documentation. All it has to do is run at boot time after ypserv starts up.

Now the setup is done. Reboot your machine, and when it comes back up, use ps to make sure ypserv and rpc.yppasswdd are running. If they are, clients should be able to connect. There are only a few final notes before moving on to client setup. First, remember that the NIS maps are not the same as the local configuration files, even though they are created from them. Each time you change a local file such as /etc/passwd or /etc/netgroup, you need to rebuild the NIS maps by going into /var/yp and running make. You might want to set up a cron job to do this once an hour in case you make some changes but forget to rebuild. Second, if you want to be able to see the NIS maps on your server, you will have to configure it as a client. Follow the steps in the next section to do so.

I will describe how to set up NIS on a Linux machine running the Red Hat 4.2 distribution. However, what I cover is generally applicable to any Linux machine running a libc5-based system with the NYS NIS support library included in the libc (as the case is with Red Hat), or a new libc6 system. If you are unfortunate enough not to fall into either of these cases, I suggest upgrading your Linux distributions across the board, or going out and getting a different libc at sunsite.unc.edu. (Upgrading libc is not a task for the faint-of-heart.)

The two packages required to make Red Hat Linux into an NIS client are yp-clients-2.2 and ypbind-3.3. These tools start with the letters “yp” for historical reasons. If you want to get the tar.gz files, they are available at ftp://ftp.uni-paderborn.de/linux/local/yp/. Otherwise, you can use pre-packaged RPMs from any Red Hat FTP site. The yp-clients package is in the standard binary RPMS directory, but the ypbind package is only available in the “contrib/SRPMS” area. You can run NIS without ypbind, but not all features will be available. You will want those features though, so get the RPM or source code, compile it and install.

Once you have those packages installed, verify that you have the portmapper running. The portmapper enables the Remote Procedure Call (RPC) mechanism, which is used by NIS and NFS, among other things. If you are already running NFS, you don't need to worry. Otherwise, install the portmap package for your appropriate distribution; it should be included.

Now that you have the various components installed, you must set up a few configuration files to enable NIS at boot-time. First, you have to determine the NIS domain in which the client will run. This is not the same thing as your DNS domain, although sometimes the name is the same. The traditional location for the NIS domain is in the file /etc/defaultdomain. This file should contain a single line with the name of your NIS domain, for example, econ.yale.edu. However, this file's mere presence does not set the domain name; to actually set the name you must use the domainname command. Usually this is done at boot time from the init scripts. On Red Hat, add the line:

domainname `cat /etc/defaultdomain`

near the top of /etc/rc.d/rc.sysinit. On non-SYSV init systems like Slackware, the appropriate file to change would most likely be /etc/rc.d/rc.inet2. The main objective is to get domainname to run “early” in the boot process, before other network services that might depend on NIS run, but after the network hardware is initialized and the IP address information is set.

Next, you have to start the ypbind daemon, which turns on the NIS client services. If you installed the ypbind RPM referenced above, the proper SYSV-style startup files should be ready to go. Otherwise, you will have to start ypbind yourself. Insert the call to /usr/sbin/ypbind right after the line initializing the NIS domain name.

Third, create the file /etc/yp.conf and include the line:

ypserver

Replace servername with the host name of your NIS master or slave server, whose host name must also be listed in /etc/hosts. You can list multiple servers on separate lines; if one host is down at boot time, the client will try the others. Failure to create this file will not disable NIS, but ypbind will broadcast a request for a server across your entire IP subnet, and this can be a major security hole. Someone can set up a renegade NIS server on your subnet and then feed you false configuration files. Better safe than sorry—create /etc/yp.conf.

That wasn't too bad, was it? Now you're ready to go. Reboot your machine, and when it comes back up, log in and do a few diagnostics. First type domainname without any arguments to be sure that it responds with the proper NIS domain. If not, check that the command to set the domain has run properly. Then type ypwhich, the command to tell you which NIS server you are talking to. If all is well, it will respond with the one you listed in the /etc/yp.conf file. Now it's time to put NIS to work.

There are a number of useful command-line utilities, used to query the NIS system, that come with the yp-clients package. ypwhich tells you what NIS server you are bound to. Typing the command ypcat filename will display the contents of a file served over NIS. For example, ypcat passwd will display the NIS password file. Typing the command ypmatch key filename will match a “key” in the file name specified. For instance, I could do a ypmatch pbrown passwd, and it would return the entry for my account. These commands can be useful in shell scripts, debugging NIS setup troubles and numerous other creative ways.

The file used to tell your client computer which files to get from NIS and which files to get locally from the hard disk is called /etc/nsswitch.conf. This file is included with Red Hat Linux, but if you don't have a copy, you should be able to obtain a sample from a libc distribution or from the NIS-HOWTO. The file is in the same format as the one from Solaris, so if you are familiar with that one, you're a step ahead. If not, a short tutorial is useful.

The nsswitch.conf file consists of entries in the following form:

filename:

The part of the line before the colon describes the file in question, say passwd or group. The information after the colon describes how that file should be obtained. Access methods we are concerned with include nis, compat and files. The access methods are cumulative; if multiple methods are specified, they add up to create the final file. For instance, the entry

passwd: files nis

Most likely, the lines all say files nisplus nis for the access methods. You don't have NIS+ running, so that method will be skipped and all will be well—you will end up with a combination of your local files and the NIS files, which is probably what you desire. However, you may want finer control over which entries users from the NIS file get added to your local file. This is where the compat access method comes in.

If you list compat as your sole access method, a special syntax in the passwd and group files is enabled. By default, the NIS version of the file isn't consulted; only the local file is used. To add entries from the NIS file, you put lines in the passwd/group file starting with a “+” character. For instance, if I wanted to add the single user steveb to my local passwd file, I would put the following line at the end of the passwd file:

+steveb::::::

The colons are place holders for fields normally included in the password file. Any information which is omitted will be filled in from the NIS file. Here, I have omitted everything but the user's name; all the other information (password, full-name field, home, shell) will be replaced automatically by NIS. Similarly, if you wanted to change steveb's shell on this computer, you might use this line as his entry:

+steveb::::::/usr/local/bin/newshell

+::::::

+mygroup:::

+mygroup:::steveb,pbrown,jrust

Using a “-” character instead of a “+” character is also possible, and does just what you would expect—it removes the specified login(s) or group(s) from the file. The one warning is that you must include “-” lines before any other line that might include the user. For instance, if jrust is included in the NIS passwd file, and you want to remove him from the local computer but give everyone else access, you would add these two lines to the end of your passwd file:

-jrust::::::
+::::::

Another common situation arises where you want to exclude users from being able to login, but you want their information available in the passwd file. For this, you would add the line:

+::::::/bin/false

The netgroup file gives system administrators a powerful way for grouping users and hosts into distinctive groups which can then be referenced when setting up NIS access on the client computers. The netgroup file is maintained on the NIS master server in /etc/netgroup. It consists of the group name followed by one or more entries in the following format:

(

For instance, you might have a line like this:

sysadmins (,pbrown,) (,kbrown,) (,vladdy,) (,ieong,)

+@sysadmins
+:::::/bin/false

You can use netgroups for all sorts of creative things. Create a netgroup with dangerous users listed in it and use a “-” line in the passwd file to disallow them, but include everyone else. Create netgroups for all the “semi-private” machines you have on your network and list the valid users for those machines. Include them in your passwd file to give just those users access. The possibilities are almost endless.

While for the most part, the fact that you are running NIS instead of using traditional configuration files will be completely transparent, there are a few cases where this is not true. The most glaring of these is that you cannot use the passwd command to change your password on the client machines. If you do so, the entire NIS passwd map will be appended to the local /etc/passwd file each time you use the command, which is certainly not the intended effect. This may have changed with libc6, but it is definitely a problem with the stock utilities that come with Red Hat 4.2. However, all hope is not lost; there is a solution, and it is called yppasswd. This utility acts just like passwd, but makes a call to the NIS server to do the actual change instead of trying to change things locally. The NIS server must support this by running the yppasswdd daemon. In its absence, you will have to tell users to log in to the NIS server to change their password, which is only a minor inconvenience.

If you run into troubles while setting up either the server or clients, the most likely source of your problems is the /etc/nsswitch.conf file. Make sure that each line is creating the behavior you intend, and when in doubt refer to the man page. Also, check the “+/-” syntax in your passwd and group files and make sure it follows the proper notation. Minor typos can have wide-ranging effects, so proofread carefully.

Unfortunately, I cannot hope to cover all the details of setting up a complex distributed network environment. You may well have unique problems or concerns that haven't been addressed here. If this is the case, I highly recommend the O'Reilly book on NIS (and NFS) that was previously mentioned. If all of these roads lead to nowhere, try the Linux, and especially the Sun, newsgroups on Usenet. There is a good chance someone else has dealt with your problem before.

Good luck setting up NIS on your Linux network. The couple of hours you initially invest will save you days of headaches in the long run.