Chapter 15: NIS: Network Information Service

Chapter 15

NIS: Network Information Service

In this chapter:

	Using NIS to simplify your network setup
	Setting up the NIS server to provide maps, translate user names and IDs, and change network passwords
	Setting up an NIS client
	Checking the configuration

The Network Information Service (NIS) provides a simple network lookup service consisting of databases and processes. Its main purpose is to hold information needed on the client machines on a centralized server, and to distribute it transparently over the network. It's more of a local service than something you would provide over the Internet. In fact, it would be a big security risk to allow unknown machines to access this service. Common uses of NIS include acting as a repository for user information stored on the server, and distributing the user and password information to clients on the network. These functions significantly decrease your administrative workload. New users are simply added on to the server, clients receive the user information automatically, and each user whom the server is aware of is known to the whole network, without the necessity of adding the information to each connected machine.

NIS used to be called "YP" for Yellow Pages. The name had to be changed when British Telecom claimed to have the copyright of this term, and so it became NIS.

Even though the official name is NIS now, you'll find many references to this service as YP. This former name is also reflected in the names of the daemons providing this service and the clients accessing it. They all begin with yp.

NIS needs to be set up on the server and on each client machine participating in this service. SuSE did a good job in integrating NIS into its distribution. The client setup can be done inside YaST, and the server setup is not a big deal, either.

15.1 Setting up the Network Information Service

The server setup is mainly done in /etc/rc.config. There is more than one daemon responsible for this service, and each one has a variable in /etc/rc.config that determines whether it should be started:

15.1.1 ypserv

The server providing the main NIS service. It will be started when START_YPSERV is set to yes. Another variable also needs to be set -- the NIS domain name. NIS servers are identified by the domain they serve.

The NIS domain is completely independent of the IP domain of which the machines are part. It is possible, and may seem convenient, to use the same name for both services. For security reasons, we recommend that you use different names. The point does not have to be taken too seriously; security through obscurity is a bad idea in the first place, so please be sure to have additional barriers in place to protect your NIS server. The NIS domain name is given in the variable YP_DOMAINNAME.

After you have enabled NIS in /etc/rc.config, you need to create the NIS database, often called the YP maps. These maps are created by running make in the directory /var/yp:

# cd /var/yp  
# make  
make[1]: Entering directory `/var/yp/bb.home.sf'  
Hashing shadow...  
Updating passwd.byname...  
Updating passwd.byuid...  
Hashing gshadow...  
Updating group.byname...  
Updating group.bygid...  
Updating rpc.byname...  
Updating rpc.bynumber...  
Updating services.byname...  
Updating netid.byname...  
make[1]: Leaving directory `/var/yp/bb.home.sf'

The example shows the generation of YP maps for the domain bb.home.sf. You see that the domain name is not a legal IP domain name -- there is no top-level domain sf. After make is done, you can start the server with the command /sbin/init.d/ypserv start and from then on, NIS is enabled on your machine. Don't forget to rebuild the YP maps every time you change something in the server setup that will be exported to the clients on your LAN.

Example: If you add a new user to the system, you have to run make again in /var/yp in order to have that new user recognized by the client machines.

You may want to make sure that you don't forget to update the yp-maps by simply setting up a cron job, which runs /var/yp/make on a regular basis. See Chapter 8 for instructions on how to use cron.

15.1.2 yppasswdd

This is the NIS password daemon. If you distribute the user and password database to your clients, changing a password from a client machine will not be possible, because the database is held on the server. This problem is solved by the yppasswdd daemon. It allows a client machine to connect and to change a password. The new password will be written in the NIS database and into /etc/shadow for local logins on the server. You enable this service by setting START_YPPASSWDD to yes.

On the client side, you have to use the utility yppasswd rather than passwd to change passwords on the NIS server. The user interface is the same as that of passwd:

> yppasswd  
Changing NIS account information for bb on Tosh.suse.com.  
Please enter old password:  
Changing NIS password for bb on Tosh.suse.com.  
Please enter new password:  
Please retype new password:  

 

The NIS password has been changed on Tosh.suse.com.

To make it easier for your users, you can rename the passwd utility (which you still need to change local passwords) to, for example, passwd.local and create a link from yppasswd to passwd. In this case, you won't have to explain to your users why they can't change their password as they were used to on other Unix machines.

15.1.3 ypxfrd

This is the NIS map transfer server. This service is used to speed up the transfer of large NIS maps from an NIS master to the NIS slave server. If a NIS slave server receives a message that there is a new map, it will start ypxfr to transfer the new map. ypxfr will read the contents of a map from the master server using the yp all() function. The ypxfrd server speeds up the transfer process by allowing NIS slave servers to simply copy the master server's map files rather than build their own from scratch. The ypxfrd server uses an RPC-based file transfer protocol so that there is no need to build a new map. You need this service only if you have a very large network, with NIS slave servers and large maps to transfer between them. To start this service at boot time, set START_YPXFRD to yes in /etc/rc.config.

This is almost all you need to know to get a basic NIS server up and running. For huge networks, you may want to think about setting up slave servers to ensure that even if the main NIS server goes down, NIS is still working for the clients.

More information about NIS can be found in several how-to's located in the directory /usr/doc/howto. A good book for diving deeper into NIS is Managing NFS and NIS, by Hal Stern.

15.2 Setting up an NIS client

Setting up a client is even easier than setting up the server setup. You can do it with YaST using the "Configure YP client" form or entering the setting directly in /etc/rc.config. The variables controlling the client are YP_DOMAINNAME, YP_SERVER and CREATE_YP_CONF. The client gets started if the NIS domain name has been set in YP_DOMAINNAME. CREATE_YP_CONF decides whether the configuration file /etc/yp.conf for the client daemon ypbind should be created by SuSEconfig. Often this is the case, so the default value of yes is okay. The value of YP_SERVER will be used to specify the NIS server in the configuration file. The specification of the NIS server should be done by giving an IP address, not a hostname. NIS doesn't use DNS to resolve hostnames, so if you want or have to use an actual name here, make sure that it's listed in /etc/hosts so that the NIS client can translate the name to a number.

If you have a more complicated setup, you may want to create the configuration yourself. In this case, set CREATE_YP_CONF to no and create /etc/yp.conf manually.

15.3 Making sure it works

It's a good idea to turn the NIS server into one of its own clients. In this way, you can control all the settings on one machine and make sure that everything works as you intended. Also, it may be easier to understand for the users, because they always can use yppasswd to change their password without worrying whether they are on the server or on a client machine. After both sides (client and server) are set up, you can check to see whether the setup is working by using the yp-utilities ypcat and ypwhich. The latter should tell you the name of the NIS server to which you are connected:

> ypwhich  
Tosh.suse.com

With the parameter -x, it'll give you a list of all YP maps the server should export and under which name you can request this map:

> ypwhich -x  
Use "passwd" for "passwd.byname"  
Use "group" for "group.byname"  
Use "networks" for "networks.byaddr"  
Use "hosts" for "hosts.byaddr"  
Use "protocols" for "protocols.bynumber"  
Use "services" for "services.byname"  
Use "aliases" for "mail.aliases"  
Use "ethers" for "ethers.byname"

You can get these maps using ypcat mapname:

>ypcat group  
users:*:100:  
nogroup:*:65534:root  

 

>ypcat passwd  
bb:fAZBH7eoJ46Ao:501:100:Bodo Bauer:/home/bb:/bin/tcsh

You see that these are very small map files. In a real-world environment, you will get much more output than this example shows.

Summary:

The Network Information Service (NIS) can simplify your network setup by providing so-called map files to the NIS clients. These maps are normally used to make transparent which machine in the network you log on to. All clients can share the same data, such as the same user/password combination for the entire network.

Setting up a server and clients is fairly easy in SuSE Linux because everything can be set in /etc/rc.config. The setup can be tested with the yp-utilities ypwhich and ypcat.