Section 39.2. Objective 2: NIS Configuration

39.2. Objective 2: NIS Configuration

NIS is Sun's Network Information Service. It was formerly known as Yellow Pages, but after a trademark dispute with British Telecom, Sun changed the name to Network Information Service. The history of Yellow Pages is why many NIS-related commands begin with yp.

NIS is a simple directory service whose main purpose is to allow remote authentication for systems on local network systems. NIS allows information such as passwd and group files, sendmail aliases, automount maps, and hosts files to be kept on a central server. Each system in the NIS domain runs the NIS client, ypbind, to find a server and retrieve the appropriate maps from it.

NIS uses a master/slave server configuration that resembles DNS. The master NIS server holds the NIS map files. Changes to the maps are then pushed to any slave servers. While an NIS domain can operate with only one server, it is best to have at least one slave server for redundancy.

You must run the RPC portmapper (/usr/sbin/portmap) to run NIS . The RPC portmapper servers convert the RPC program numbering to TCP/IP or UDP/IP protocol port numbers.

Most Linux distributions ship with NIS Version 2. NIS Version 3 is known as NIS+ and is not in widespread use.

Before setting up servers or clients, you must decide on a domain name for your NIS setup. The domain is used to ensure that you're talking to the right NIS servers . This domain name has nothing to do with DNS, your DNS domain name, or your hostnames. Most directory administrators use the same domain in NIS as in DNS to simplify network administration, but the NIS domain could be completely different from the DNS domain. The command domainname or ypdomainname are usually links to the hostname binary and can be used to set the NIS domain. This has nothing to do with the hostname command.

39.2.1. NIS Master Server

You should have at least two NIS servers, one master and one slave. If one of them fails, the clients using it will switch to the other automatically. To set up a server, start by installing the NIS and/or YP packages in your distribution. On the server side, you have the tools shown in Table 39-1:

Table 39-1. NIS server-side tools
Tool	Description
ypserv	The NIS server program
yppasswdd	Server that handles the NIS password changes
yppush	Notifies the slave servers when changes are made to master databases
ypinit	Installs and builds an NIS database

Sometimes some of these have an rpc. prefix in their filenames. After having the server tools installed, you must configure and initialize them. Do the following to get a master server :

All planned NIS servers, masters, and slaves must be present in your /etc/hosts file. Following the IP address, place the fully qualified domain name, which is the hostname including the DNS domain, then the bare name and any aliases, like this:
```
 10.0.0.5roke.example.com roke mailserver nisserver 
```
Configure your domain name. On Debian, simply put the name in the /etc/defaultdomain file. On Red Hat you must set the NISDOMAIN variable to your domain name in /etc/sysconfig/network.
Set the correct networks in /etc/ypserv.securenets. If your internal network uses the 10.0.0.0/255.255.255.0 subnet, for instance, the file should look something like this:
```
 # Always allow access for localhost 255.0.0.0       127.0.0.0 # This line gives access to ourselves 255.255.255.010.0.0.0 
```
Start the master server processes. On Debian, you simply set NISSERVER=master in /etc/default/nis and start the needed services with /etc/init.d/nis start. On Red Hat you must start all the master server services one by one, using the scripts installed in /etc/init.d:
```
 # ypserv start # yppasswdd start # ypxfrd start # ypbind start 
```
You can execute ypserv -d to run the process in the foreground and stream debug messages to console output. If you type ypserv without the -d option, the process will run in the background and just report errors (access violations, dbm failures) using the syslog facility.
Initialize the server maps or databases. Before doing this, you need an /etc/networks file, even if it's empty. Then you can do the initialization of the master server:
```
 /usr/lib/yp/ypinit -m 
```
This populates the databases from the contents of your master server system files. The work is done in /var/yp/Makefile. By customizing this file, you can change the location of the master files. Most often people change the location of the master passwd and groups files. If you do that, you should take a look at the yppasswdd manpage to tell that command where the master files are.
If you run ypcat passwd now, you should get a listing of all or some of the entries from your /etc/passwd file.
Now you have to set up the master as a client as well.

39.2.2. NIS Client

The tools provided for manipulating clients arelisted in Table 39-2.

Table 39-2. NIS client-side tools
Tool	Description
ypwhich	Returns the name of the NIS server used by the NIS client
ypcat	Prints the values of all keys in the specified NIS map
yppoll	Returns the version and master server of the specified NIS map
ypmatch	Prints the values of specified keys from an NIS map
ypdomainname	Prints or sets the name of the NIS domain
yppasswd	Changes passwords in the NIS server

yppasswd is needed because the standard passwd command can change only passwords in /etc/passwd and /etc/shadow, but that is not very well-suited for a network information service. You need a special command that is aware of NIS to update the password on the master server.

Setting up an NIS client is simple. The following steps cover the process:

Set the NIS domain name. On Debian, /etc/defaultdomain should contain the domain name. On Red Hat, set NISDOMAIN in /etc/sysconfig/network.
Start ypbind. On Debian, set NISSERVER=false in /etc/default/nis (unless you're on your master server, of course) and then run /etc/init.d/nis start. On Red Hat, simply run /etc/init.d/ypbind start. If your server is not on the same IP subnet, you must customize /etc/yp.conf and set the server name there.
Customize /etc/nsswitch.conf. All the name services that should get information from NIS should have nis somewhere on the line. This includes the whole of the NIS map contents. On the passwd, group, and shadow lines, you should always put file in front of nis.
NIS offers an access control method based on users and groups. The entries for passwd, group, and shadow accept a special compat option, which enables you to use a + in the corresponding files. This is described later.
When you now enter getent passwd, you should see the contents of your local passwd file as well as the contents of the NIS passwd file.

After ypbind is running, you can see what NIS server it has bound itself to with ypwhich. ypcatmap lists the contents of the specified map. ypmatchkeymap lists just the specified entry of the specified map.

39.2.2.1. compat

When compat is listed as the passwd, shadow, and group source in nsswitch.conf, you can use a special syntax in the files. We'll use the password file as an example, but the same goes in the other files, save for the number of colons.

To allow access to the system to the users janl and killroy, the two first lines in the followng example do the job. The third line illustrates group access, allowing an NIS netgroup called ftpusers in as FTP users only. Note that even if janl and killroy are members of this netgroup, they still get full access, because they are listed in the password file before the netgroup line. The last line includes all the other users in NIS but sets their password to * and shell to /etc/nologin, barring them from using the system.

 +janl:::::: +killroy:::::: +@ftpusers::::::/etc/ftponly +:*:::::/etc/nologin

Most often, only the last form is used in group files. But it is easier and faster to just put groups: files, nis in nsswitch.conf.

39.2.2.2. NIS slave server

Once a host is an NIS client, it can be set up as a slave by performing these steps:

Ensure that your slave server is listed in the master's /etc/hosts file and vice versa.
Configure the slave's /etc/ypserv.securenets file.
The master must know that it has slaves. On the master, set NOPUSH to false in /var/yp/Makefile.
On the master, run /usr/lib/yp/ypinit -m again. Add your slave when it asks for it.
Back on the slave, start the slave server processes. On Debian, set NISSERVER=slave in /etc/default/nis and run /etc/init.d/nis stop;/etc/init.d/nis restart (using restart because it's already started as a client). On Red Hat, start the server process with: /etc/init.d/ypserv start.
Initialize the slave server by running /usr/lib/yp/ypinit -smaster-server.
Run ypcat -h localhost passwd to verify that the slave works correctly.
Because NIS servers do not autosynchronize, you need to configure synchronization on the master. Put the following in /etc/cron.d/nis to ensure that it updates the slaves regularly:
```
 10 *    * * *    root  /usr/lib/yp/ypxfr_1perhour >/dev/null 2>&1 20 6,18 * * *    root  /usr/lib/yp/ypxfr_2perday  >/dev/null 2>&1 40 5    * * *    root  /usr/lib/yp/ypxfr_1perday  >/dev/null 2>&1 
```
The hourly job transfers the passwd, shadow, and group maps. The twice daily job transfers hosts, netgroups, and the networks maps. The once daily file just transfers the protocols, RPC, and services maps. Of course, there is nothing wrong with running these more often, but they always transfer the complete maps, so on large sites with thousands of entries in the maps and multiple slave servers, they're going to take some time.
These map transfer scripts and cron times should be modified to meet your needs, such as including new maps and excluding old ones, as in this example:
```
 [root@pirarucu yp]# cat ypxfr_1perhour #! /bin/sh YPBINDIR=/usr/lib/yp MAPS_TO_GET="passwd.byname passwd.byuid shadow.byname publickey.byname hosts.byname hosts.byaddr netgroup netgroup.byuser netgroup.byhost group.byname group.bygid protocols.byname protocols.bynumber networks.byname networks.byaddr rpc.byname rpc.bynumber services.byname ypservers auto.home seismic_users" for map in $MAPS_TO_GET do   echo "Syncing map: $map ..."   $YPBINDIR/ypxfr -c -s ep.bc.nismaster.gov.br -d ep.bc.nisslave.gov.br $map done 
```

Don't forget to make all the NIS processes start when the system boots.

39.2.3. NIS Maps and Tools

39.2.3.1. Map lookups and nicknames

During the previous setup, you may have noticed that NIS does not have a passwd file, but it does have passwd.byname and passwd.byuid. If you look in /var/yp/domain_name, where domain_name is the NIS domain name, you'll see the map names that NIS has as shown in a listing like this:

 # ls /var/yp/nismaster.gov.br group.bygid   netgroup.byhost  protocols.byname    services.byservicename group.byname  netgroup.byuser  protocols.bynumber  shadow.byname hosts.byaddr  netid.byname     rpc.byname          ypservers hosts.byname  passwd.byname    rpc.bynumber netgroup      passwd.byuid     services.byname

These files are provided for the standard Unix and Linux system calls that do name resolution, such as getpwnam and getpwuid. When getting information from files, these functions have to iterate through the whole /etc/passwd file to find the given name or UID. In NIS, instead, they do a lookup into the map indexed by the username or the UID, namely passwd.byname and passwd.byuid. The same goes for the lookup functions for the other system files that are in NIS. The following example demonstrates a lookup by name and UID in the NIS passwd files.

 # ypmatch killroy passwd.byname killroy:x:1002:100::/home/killroy:/bin/bash # ypmatch 1002 passwd.byuid killroy:x:1002:100::/home/killroy:/bin/bash

To obtain the complete NIS passwd file, one can iterate through the whole map, and any of the maps will do. That is what ypcat does. To make using NIS a bit more like the system files, there are map aliases so that you can refer to the databases by the name you're used to. passwd is a alias for passwd.byname, and so on for all the other maps. Table 39-3 shows these aliases, or nicknames.

Table 39-3. NIS map aliases
Alias	Map name
aliases	mail.aliases
ethers	ethers.byname
group	group.byname
hosts	hosts.byname
networks	networks.byaddr
passwd	passwd.byname
protocols	protocols.bynumber
services	services.byname

Check the map nickname translation table with the command ypwhich -k.

39.2.3.2. Keeping maps up to date

If you ever suspect that your NIS maps are out of sync, you can do what the master server does: poll their versions to compare them:

 # yppoll -h localhost passwd.byname Domain example.com is supported. Map passwd.byname has order number 1076234245. [Sun Feb  8 10:57:25 2004] The master server is debian.example.com. # yppoll -h roke passwd.byname Domain example.com is supported. Map passwd.byname has order number 1076234245. [Sun Feb  8 10:57:25 2004] The master server is debian.example.com.

These maps are the same. But if the slave is not up-to-date and you want to force updating just one map on one or more servers, use yppush. On the master, enter something like this:

 # yppush -h roke passwd.byname

If you do not include the -h option, the map will be pushed to all the slaves. You can also enter several -h options to push it to several named slaves.

39.2.3.3. Netgroups

Netgroups have been mentioned before in this chapter and also in relation to NFS. They are most useful as a mechanism to support access control for machines (in the password file as shown earlier) and for restricting NFS shares to certain hosts. The general format is as follows:

 netgroup  (host,user,domain) | netgroup [ , ... ]

The actual use may be clearer from the following example:

 nfsservers      (server1,,), (server2,,) nfsclients      (client1,,), (client2,,), nfsservers serverusers     (,user1,), (,user2,)

If you use compat for passwd: in /etc/nsswitch.conf, you can now enter +@serverusers:::::: at the end of the /etc/passwd to allow the NIS users user1 and user2 access. You may need to put the equivalent entries in your /etc/shadow file as well.

On NFS servers you can use @netgroup syntax in /etc/exports instead of hostnames. For instance:

 /var/export @nfsservers(rw,no_root_squash) @nfsclients(rw,root_squash)

If you try to use ypcat on the netgroup map, it won't tell you much, because the netgroup names are only stored as keys and won't be shown. Add the -k option to se the keys as well, as shown here:

 # ypcat -k netgroup nfsservers (server1,,), (server2,,) serverusers (,user1,), (,user2,) nfsclients (client1,,), (client2,,), nfsservers

39.2.3.4. RPC calls

The utility rpcinfo can be used to detect and debug a variety of failures. Just type rpcinfo -p hostname to check how the things are going in your NIS server. Here's an output of a functional NIS server:

 # rpcinfo -p localhost    program vers proto   port     100000    2   tcp    111  portmapper     100000    2   udp    111  portmapper     390011    4   tcp  32772     390008    1   tcp  32776     100004    2   udp    852  ypserv     100004    2   tcp    855  ypserv     100007    2   udp    725  ypbind     100007    2   tcp    728  ypbind     100011    1   udp    840  rquotad     100011    1   tcp    857  rquotad     100003    2   udp   2049  nfs     100003    2   tcp   2049  nfs     100021    1   udp  33745  nlockmgr     100021    4   tcp  36331  nlockmgr     100005    1   udp    853  mountd     100005    1   tcp    865  mountd     100005    2   udp    853  mountd     100024    1   udp  32768  status     100024    1   tcp  32769  status

The output from rpcinfo shows the RPC program and version numbers, the protocols supported, the IP port used by the RPC server, and the name of the service. If rpcinfo times out while attempting to reach the remote machine and reports an error, check whether the portmapper service is alive.

 # /etc/init.d/portmap status portmap (pid 2124) is running...