Network Information Services (NIS) is an RPC-based application (as is NFS) that helps manage access control across multiple machines. Originally, it was called Yellow Pages (YP), because it works in the same manner as a directory service. Due to copyright requirements, it was later renamed NIS.
NIS solves one of the difficulties of working with LANs: synchronizing user access across the LAN. For instance, on a 10-computer LAN with 15 users sharing computers, each user must have a login on each machine he or she might use. If these machines are true multiuser systems that use Linux or a variant of BSD or UNIX, this is possible. However, if each user is to have access to every machine, each user must maintain 10 accounts. If users want to change their passwords, they must do it in 10 places.
If you use NIS for logons and NFS for file sharing on your LAN, users can log in to any workstation, and they’ll be unable to tell the difference from any other workstation they may have used previously. With NIS, the network is transparent to the users; they will always find themselves in the same environment, regardless of which computer they use. If you use NFS to automount /home partitions, users can be in the exact same desktop, with the exact same look and feel, on each computer, provided the operating system and applications available are identical.
More on NFS
For more information on using NFS, check out Bryan Pfaffenberger’s "Working with NFS" Daily Drill Down.
Because NIS is a distributed access system, each machine on the network that is to use NIS will access a central server, known as the NIS master or ypmaster. This server will provide access permission information. On larger networks, you can even define NIS slaves, or ypslaves, to provide both up-to-date access to the other systems in the network and server redundancy in the case that the ypmaster fails.
NIS' other functions
NIS can do more than simply provide access permission to various systems. It can also be used to transfer copies of master files from the ypmaster to the client systems. Some of the files that can be handled in this manner, beyond the traditional /etc/passwd and /etc/group files, are the /etc/hosts, /etc/services, and /etc/networks files. This means that using NIS can be an easy alternative to setting up a DNS server to provide IP addresses to other systems on the LAN. Because each NIS client can obtain a copy of /etc/hosts, the master /etc/hosts file can contain the mapping information that maps hostnames to IP addresses for the LAN.
This doesn’t mean that to use NIS you must also distribute these files. On the contrary, if all you wanted to share among the client systems was the /etc/hosts file, you could do so. You don’t need to use NIS to provide user and group information at all.
Installing the NIS master
Almost all distributions come with the necessary programs to run the NIS server and client programs. Installing NIS support in your LAN should be as simple as installing the appropriate packages: yps or ypserv for the server component and ypbind and yp-tools for the client-side software. In fact, most distributions will allow you to select NIS services during the initial installation. If you absolutely must download and build NIS from source, you can obtain the sources. I’m going to assume you installed the packages required for NIS, since very few distributions will require you to build these tools from source.
First, we’ll concentrate on the ypmaster, which is the NIS master server. On the master system, you should install all of the packages: ypbind, yp-tools, and ypserv. The next step is to edit the Makefile for the ypserv program. The Makefile is typically found in /var/yp.
A Makefile is involved because NIS creates map files of the requested master files. These map files are stored in DBM format. To create these files, NIS uses the GNU make command to compile the master files into their DBM counterpart map files. The ypmake utility is used to build the database files for NIS on older versions, while the traditional GNU make is used with more recent versions.
The first step is to determine which files you want to share between systems. When you edit the Makefile, you’ll have to modify which files it builds database maps for. In the file, you’ll see a line that will look something like this:
all: passwd group hosts rpc services netid protocols mail
This is the line that determines which map files are created. In the above line, the files /etc/passwd, /etc/group, /etc/hosts, /etc/rpc, /etc/services, /etc/netid, /etc/protocols, and /etc/aliases would all have corresponding map files generated. If you only wanted to distribute the files /etc/passwd, /etc/group, and /etc/hosts, you would change the line to the following:
all: passwd group hosts
Some newer implementations of ypserv can handle many other files, like those required for the autofs automounting daemon, locale files, and time zone files. The Makefile will illustrate all of the available files for replication. You can also set some other options, such as the minimum UID and GID to use for the replicated user access maps. The following two options set the minimum UID and GID requirements for users to be included in replication:
On most Linux systems, user accounts begin with UID/GID values of 500 and higher. By setting that value to the minimum, you prevent NIS from replicating important system accounts, which could result in decreased security and confusion, especially if you’re mixing different flavors of Linux. On BSD systems, the minimum UID and GID values should be 1000.
Also, if you’re setting up NIS in a larger network and want to use NIS slave servers, you’ll need to change:
in the Makefile. This tells NIS to push the map files to slave servers. If you’re in a smaller network with only a single NIS server, you can keep NOPUSH at its default value of true.
When you’re finished modifying the Makefile to your tastes, you must run the following command to build the map files and initialize the ypmaster:
This tells the ypmaster to build a ypservers file, which contains a list of the master and slave NIS servers. At the minimum, your hostname must appear in the list. If you’re setting up slave systems, you can also add them. Next, you should run the following command:
Some systems don’t use ypmake; if you get an error saying that the command isn’t found, issue the following command in the /var/yp directory:
This will build your map files. Now you should see a subdirectory below /var/yp that has the same name as your domain name. For example, if your domain name on the ypmaster was mydomain.com, you might see a new directory called /var/yp/mydomain or /var/yp/mydomain.com. If you look in this directory, you’ll see some new files. If you told NIS to only build maps for the group, passwd, and hosts files, you’ll see the following files: group.bygid, group.byname, hosts.byaddr, hosts.byname, passwd.byname, and passwd.byuid. These are the map files for your domain. NIS typically builds map files in one of two formats, depending on how the map file is accessed. For users and groups, the map file is built with the user/group name or the UID/GID value, while for hosts it’s the hostname or IP address.
Finally, you’ll need to define your NIS domain name. On Red Hat and derived systems (like Mandrake Linux), you’ll need to set the NISDOMAIN variable in the /etc/sysconfig/network file. For SuSE, you’ll need to modify the variable YP_DOMAINNAME in /etc/rc.config and then run the SuSEconfig command. On Debian and other UNIX systems, the domain name is typically specified on a single line in the /etc/defaultdomain file.
Now that your ypmaster is configured, you can start ypserv. To do this, you usually use the initscript on SysV-style systems by issuing the following command:
You’ll also need to start rpc.yppasswdd on your master or sole ypmaster server. Most distributions also provide an initscript to yppasswdd, so you should be able to start it like this:
The initscript location will vary depending on which distribution you use. Now you can concentrate on configuring the client systems. Keep in mind that when you make changes to your user or group databases, or any other file that is to be distributed by the ypmaster, you’ll have to rebuild the map files.
Installing the NIS clients
Now you must configure the client systems. The NIS clients will need to have the yp-tools and ypbind packages installed. Once you have them installed, you’ll need to edit the /etc/yp.conf file to tell the system who the ypmaster is. You can do this by adding this line to /etc/yp.conf:
This tells the system that ypserv.mydomain.com is the ypmaster for your domain. On some older systems, you might have to specify the server like this:
Save the file and make sure that it’s world-readable. You’ll also need to edit your /etc/hosts file to make sure that the hostname you defined can be resolved. A fictional entry in /etc/hosts for the above might look like this:
192.168.0.25 ypserv.mydomain.com ypserv
Next, start ypbind to bind to the NIS domain by executing the following, as root:
Now you can test your NIS system. Use the ypcat program to display the contents of a file you’re distributing via NIS. Let's assume you’re distributing the /etc/passwd file, so issue the following as any user:
You should see the contents of the passwd.byname file as found on the master server. If you do, congratulations; you now have a working NIS system.
The next step is to edit /etc/nsswitch.conf. This file is used to determine which files on the client will be retrieved from the ypmaster and which will remain local. The format of the file is like this:
hosts: nis, files
networks: nis, files
passwd: nis, files
group: nis, files
This tells the system to attempt to retrieve the hosts, networks, passwd, and group files from the NIS server first and, if that fails, to use local copies. For the rpc, protocols, and services files, we always use local copies.
If you do make changes to the /etc/nsswitch.conf file, remember to restart ypbind so that those changes will take effect.
Now, if a user wants to change his or her password, he or she simply needs to run yppasswd, which will update the password on the master NIS server. With this, the user only needs to change the password once, on one machine, to have it replicated to all of the other systems that user may be logging in to.
I found one big problem, a mysterious error returned by ypbind, which caused me a few hours of frustration and fruitless searching on the Web for answers. Whenever I started ypbind, it would indicate that it was unable to find and bind to the NIS domain. You may see this problem when you initially set up NIS. I used Mandrake Linux 8.0 to configure and set up NIS, and it was on that distribution that I noticed the error. During my searches, I found many similar problems reported under Debian, Red Hat, SuSE, and other Linux distributions. The solution that cleared it up for me was embarrassingly simple: Run ypbind and ypserv in debug mode.
Instead of using the initscripts, I launched ypserv using the following:
Then, in another console, on the same system, I launched ypbind using the following:
Lo and behold, it started to work. Starting ypbind via the initscript on a remote system resulted in it binding to the domain.
Stop both processes by using the ps command to find the PID for each and kill it, and then use the initscript to start them. This worked for me, and now NIS is running quite nicely on my LAN.
At this point, you should have a working NIS system. When you want to make changes to any of the files served by the NIS master, you need to modify them on the ypmaster and rerun the make command in /var/yp. If you distribute the passwd and groups files, you’ll need to rerun the command after adding or deleting new users to the network.
As you can see, NIS offers some very attractive capabilities to your network. If you combine this with a file server that exports a single /home partition to all clients, your users can be on any machine and easily check their mail, browse the Web with their bookmarks intact, and work on the Linux workstation with their chosen desktop and all the configuration changes they've made to it.
Vincent Danen works on the Red Hat Security Response Team and lives in Canada. He has been writing about and developing on Linux for over 10 years and is a veteran Mac user.