System Administration Toolkit

Managing NIS services for authorizations

Content series:

This content is part # of # in the series: System Administration Toolkit

Stay tuned for additional content in this series.

This content is part of the series:System Administration Toolkit

Stay tuned for additional content in this series.

About this series

The typical UNIX® administrator has a key range of utilities, tricks, and systems he or she uses regularly to aid in the process of administration. There are key utilities, command-line chains, and scripts that are used to simplify different processes. Some of these tools come with the operating system, but a majority of the tricks come through years of experience and a desire to ease the system administrator's life. The focus of this series is on getting the most from the available tools across a range of different UNIX environments, including methods of simplifying administration in a heterogeneous environment.

Understanding NIS

The Network Information System (NIS) is a networked database that can be used to store system files that need to be shared among a number of computers. You can see the basic structure of an NIS system in Figure 1.

Figure 1. Basic structure of an NIS system
Basic structure of an NIS system
Basic structure of an NIS system

The NIS master holds the master copies of all the information. NIS slaves can download (or be sent) a copy of this information, and all NIS servers (whether masters or slaves) listen to requests from clients to look up information in the NIS databases. Only the NIS master can update the databases; although the slaves share the information, they only share the information sent to them (or downloaded) from the NIS master. NIS clients contact an NIS slave, or the NIS master, when they want to resolve a particular piece of information.

There are no rules about the number of servers you should have in an NIS setup, but traditionally you would have at least one NIS server per subnet (for example, 254 hosts). The NIS system is not particularly efficient, as information on the clients is not cached. This means that any operation that would normally look up data from a file has to request the information through NIS instead. This includes obvious situations, such as looking up password information during login and simpler operations like obtaining a list of files that involves listing file/directory ownership information, which must be looked up in the user database.

Data sharing and NIS maps

The data itself is stored within a series of NIS maps, and these are built on the NIS master from the same files that would ordinarily be used by the master. The primary role for NIS is as a database sharing mechanism for information, such as the user/password database (/etc/passwd and /etc/shadow) and a hosts file (/etc/hosts), although it can be used to share any one of the following files that are normally located in /etc:

  • auto.home or auto_home
  • auto.master or auto_master
  • bootparams
  • ethers
  • group
  • hosts
  • ipnodes
  • netgroup
  • netmasks
  • networks
  • passwd
  • protocols
  • rpc
  • service
  • shadow

For example, if you share a hosts map using the hosts file from the master as the source for the map, then NIS clients can be configured to look up host information using the information in the NIS database, in place of its own local /etc/hosts file.

NIS can be used in place of, or in addition to, the Domain Name System (DNS) for host information. The real benefit of NIS is that it can share and exchange other information, particularly password and Network File System (NFS) automounter information, within a network.

The master supplies all of the information for these databases in one direction only; the slaves are not able to update the information that they copy from the master, except in the unique situation of the login and password data. To enable users to change their password, a special password command can be used to update the server password information, which will then be propagated to all of the slaves in the domain.

The domain name is a key part of the sharing of information, as it provides the key identity information that groups the NIS maps together. You can configure an NIS client to use a specific NIS domain, and it is the domain that identifies the client computers, master, and databases as sharing the same information.

Setting the domain name

The NIS domainname name is not related the DNS domainname, and it has no relationship to the DNS protocol. Your NIS and DNS domains can be the same, or different, and it will not affect the way the system works. In general, the NIS domain is designed to hold the information about a small number of machines unique to a given network, or even department, while the DNS is a larger distributed system for managing and determining the IP address of hosts in a hierarchical domain structure across a number of networks.

You can set the domain name using the domainname command:

$ domainname mynisdomain

Note that the domain should be a single word; the hierarchical format used by DNS is not required.

You can set the domain permanently by putting the domain name in the /etc/defaultdomain file (Solaris), by editing the /etc/rc.nfs file (AIX®), and by editing the NIS_DOMAIN value in /etc/rc.config.d/namesrvrs file (HP-UX), or in the /etc/yp.conf or /etc/conf.d/domainname file (Linux®).

Setting NIS source data

To set up NIS on the master, there are two stages:

  1. Initialize the NIS databases.
  2. Start the NIS services.

The databases that you create will be based on the existing information you already have configured on your server. However, you do not want to use the original versions of these files. This is because you do not want to modify the data files of the master server each time you want to update the information; you need to instead use a copy of these files and update the copy each time you want to disseminate information to the slaves.

The easiest way to do this is to copy the source files (from the list given earlier) to a new directory, such as /etc/nisdata or /var/nisdata. The files you copy in this directory form the basis of the your NIS-shared information.

Once you have copied the files, it is a good idea to make some changes to the information on your NIS source files and the original files on which they were based. First and foremost, you want to avoid having to change both the host-specific and NIS master files when a change occurs (that is, after all, one of the reasons you are migrating the information to NIS). By ensuring there is no duplication of information, you can simplify the long-term management of your data.

Ideally, the NIS source files should contain the information that you want to share, while the original files should contain the information that is unique the master host, or that would be required in the event of an NIS failure. For example, you might include key host records in /etc/hosts as well as sharing the information through NIS so that an NIS failure does not affect hostname lookups. But the NFS automounter maps (auto.home) might only be made available through NIS.

Regardless of how you decide to divide up the information, you must make one change to the copy of the /etc/passwd file; remove the root account. If you leave the root account in the NIS source files, then all machines that share information through NIS use the same root passwd and definition. This opens up your entire network to a potential security risk if your root password ever becomes known.

In a heterogeneous environment where you are sharing NIS information amongst many different UNIX/Linux hosts, you should also trim the /etc/passwd file of any system-level user information; for example, the users sys, adm, news, mail, uucp; all of these might have different numerical user IDs and roles on the different systems, so sharing unified data through NIS for this would be impossible.

On some systems where you are also sharing the /etc/aliases (or /etc/mail/aliases) mail alias database for use with Sendmail, you might not be able copy the file to another location, because its location is hardwired in the Sendmail tool. Later versions of Sendmail enable you to set the location of this file and are not subject to the same problems.

Building the NIS maps

Now that you have the source files to build the information, you need to initialize the NIS maps with the data. To do this, you need to configure the Makefile in /var/yp to build the maps, and then run make to generate the map information.

The Makefile used to build the maps is a standard Makefile, and the first few lines from a file on a Solaris host are detailed in Listing 1.

Listing 1. The Makefile
# Copyright 1996-2003 Sun Microsystems, Inc.  All rights reserved.
# Use is subject to license terms.
#pragma ident   "@(#)Makefile   1.31    03/04/16 SMI"
# Set the following variable to "-b" to have NIS servers use the domain name
# resolver for hosts not in the current domain. 
DIR =/etc
# If the ipnodes (IPv6 hosts file) lives in a directory other than
# /etc/inet, then you'll need to change the following line.
# If the audit_user, auth_attr, exec_attr, prof_attr files
# live in a directory other than /etc/security, then you'll
# need to change the following line.
# If the passwd, shadow and/or adjunct files used by rpc.yppasswdd
# live in directory other than /etc then you'll need to change the
# following line.
# DO NOT indent the line, however, since /etc/init.d/yp attempts
# to find it with grep "^PWDIR" ...
PWDIR =/etc
DOM = `domainname`
ALIASES = /etc/mail/aliases

CHKPIPE=  || (  echo "NIS make terminated:" $@ 1>&2; kill -TERM 0 )

        @if [ ! $(NOPUSH) ]; then $(MAKE)  $(MFLAGS) -k all; \
        else $(MAKE) $(MFLAGS) -k all NOPUSH=$(NOPUSH);fi

all: passwd group hosts ipnodes ethers networks rpc services protocols \
        netgroup bootparams aliases publickey netid netmasks c2secure \
        timezone auto.master auto.home ageing \
        auth.attr exec.attr prof.attr user.attr audit.user

You might need to edit the following elements of the Makefile:

  • NIS maps -- the list of maps to be generated. This is contained in the 'all:' line -- edit the contents to match the maps you want to create.
  • DIR variable -- holds the location of the main source data files.
  • PWDIR variable -- holds the location of the /etc/passwd file (or its copy).
  • DOM variable -- specifies the name of the domain. If you have already set your domain name using the domainname command, then you can leave the value as specified, which runs the domainname command to determine the domain name you have set.

You are now ready to build the NIS maps. You can do this in two ways, using the Makefile or the ypinit command.

To use the Makefile method, run make in the /var/yp directory to build the maps:

$ make

For the ypinit method, run ypinit with the -m command-line option; you will be prompted for the name of all the YP servers (master and slave) that you want to configure, and then the maps will be built (see Listing 2).

Listing 2. The ypinit method
$ ypinit -m
In order for NIS to operate successfully, we have to construct a list of 
the NIS servers.  Please continue to add the names for YP servers in 
order of preference, one per line.  When you are done with the list, 
type a <control D>
or a return on a line by itself.
        next host to add:  ultra3
        next host to add:  ^D
The current list of yp servers looks like this:


Is this correct?  [y/n: y]  y

Installing the YP database will require that you answer a few questions.
Questions will all be asked at the beginning of the procedure.

Do you want this procedure to quit on non-fatal errors? [y/n: n]  
OK, please remember to go back and redo manually whatever fails.  If you
don't, some part of the system (perhaps the yp itself) won't work.
The yp domain directory is /var/yp/mcslp
There will be no further questions. The remainder of the 
procedure should take 5 to 10 minutes.
Building /var/yp/mcslp/ypservers...
Running /var/yp /Makefile...
updated hosts

ultra3 has been set up as a yp master server without any errors.

If there are running slave yp servers, run yppush now for any data bases
which have been changed.  If there are no running slaves, run ypinit on
those hosts which are to be slave servers.

When the data is converted into an NIS map, the source data is organized into a number of different maps according to how the information might be used. For example, the /etc/passwd file generates two maps, passwd.byname, which enables lookups of login based on the username, and passwd.byuid, which enables lookups using the unique user ID number. For hosts, the maps generated are hosts.byname and hosts.byaddr, and it's by hostname and IP address for lookups, respectively.

The files are created. Now you need to only start the NIS server so that the databases are shared.

Starting the master server

The ypserv command starts the NIS server process that listens for queries from NIS clients. To start the NIS service, run the command:

$ ypserv

Clients should now be able to query the NIS database for information.

You should make sure that the NIS process is started automatically. On most SVR4 hosts (Solaris, AIX, HP-UX), there is usually a file, such as /etc/init.d/nis.server or /sbin/init.d/nis.server, that you can link to the startup scripts to ensure that the server is started.

On an NIS master server, you might also want to start one of the other daemons used to run and support the NIS service. The ypxfrd daemon provides transfer services for synchronizing NIS maps between slaves and the master NIS server. It doesn't have to be used but, in networks with very large maps, it can significantly improve the performance of the transfer and synchronization process.

The updated daemon provides a secure method for updating NIS source files over a network. It is not required, but might be useful if you want to be able to remotely update NIS information.

The yppasswdd daemon listens for requests to change a users password and updates the files accordingly. Once the update has been processed, the changes are 'pushed' to NIS slave servers so that the password is valid for the user almost immediately. You need to adjust the configuration of this daemon so that it correctly updates the NIS source file, rather than your master's /etc/passwd file. If you have configured the Makefile in /var/yp, this often sets the right information. This differs on different UNIX versions but, for most, it is simply a case of changing the command line when the daemon is executed. For example, you change the command executed on AIX to read:

rpc.yppasswdd -a -f DIR/passwd

DIR is the directory where your NIS data files are located.

Under Linux, use the -D option to specify the directory:

rpc.yppasswdd -DDIR

On HP-UX, edit the YPPASSWDD_OPTIONS variable in the /etc/rc.config.d/namesrvrs file to point to the right directory and file.

Configuring NIS slaves

Ideally, you should have configured an NIS slaver server to be an NIS client before you convert it for NIS slave use. This is because the slave server must be able to look up and contact the master for the databases to create copies of the NIS maps before they are served.

To set up an NIS slave, follow these steps:

  1. Set the domain name:
    $ domainname nisdomain
  2. Run ypinit, specifying the hostname of the master server:
    $ ypinit -s masterserver

Start the NIS server and NIS client (see Listing 3):

Listing 3. Starting the NIS server and NIS client
$ /etc/init.d/nis.server start
$ /etc/init.d/nis.client start

The NIS slave automatically registers with the NIS master so that updates are sent to the slave by the master automatically.

Configuring NIS clients

Each machine that wants to query the NIS maps must be configured to connect to an NIS server. You can do this in two ways, using ypinit or manually. To use ypinit, run the following command:

$ ypinit -c

You will be asked to specify the names of the NIS servers that you want to use.

Make sure you start the client service and configure the service at boot time using the /etc/init.d/nis.client, or similar script.

To perform the process manually, you can use the broadcast option to the ypbind daemon, the daemon that services local requests and sends them to an NIS server. To use this method, first set the domain name:

$ domainname nisdomain

And then start the NIS daemon:

$ ypbind -broadcast

To confirm that your machine is correctly configured to access the remote maps, use the yppoll command to test for map availability. For example, check the existence of the passwd.byname map with:

$ yppoll passwd.byname

To view the map data, use ypcat (see Listing 4).

Listing 4. Use ypcat to view the map data
$ ypcat passwd.byname

Now you have the maps in place, you should configure the system to use the maps when looking up information.

Integrating with other solutions

The /etc/nsswitch.conf file tells the system where it should look for specific information, such as hostnames and login information. You can use this file to control the order (or priority) in which databases are examined, and how to handle a failure.

An example of the file is shown in Listing 5.

Listing 5.
passwd:      files
shadow:      files
group:       files

hosts:       files dns
networks:    files dns

services:    db files
protocols:   db files
rpc:         db files
ethers:      db files
netmasks:    files
netgroup:    files
bootparams:  files

automount:   files
aliases:     files

The first column is the database; subsequent entries list the source (in order) that should be used to lookup the information.

For example, the passwd database is using 'files' (in other words, /etc/passwd) to resolve login and user ID information. The hosts database, however, is using local files first, and then asking the DNS system.

To configure NIS, add the word nis to the list of searched databases. The order is important, so to check NIS first and then use the local files. For login/password lookups, you should set the following, as shown in Listing 6.

Listing 6. Setting the lookups
passwd:      nis files
shadow:      nis files
group:       nis files

You can also be more specific about what to do in the event of success or failure. For example, the above configuration tells the system to look in NIS and, if no result is found, to use files. However, the lookup might have failed, because the NIS system had a technical failure, rather than the information not being in the NIS maps.

Instead of this automatic resolution, you might want hostname lookups to use NIS by default, but only use files in the event of an NIS failure. The format, [STATUS = ACTION], can be used after each database, where STATUS is one of: success, notfound, unavail, tryagain, and ACTION is one of return or continue.

The ACTION defines what should happen when a particular status occurs. The return option indicates that the resolution process should return and not process any further database entries. The continue indicates that the next database should be used.

The definitions of the STATUS values are as follows:

  • success -- no error occurred and the requested entry was found. Default action is to return.
  • notfound -- no error occurred and the requested entry was not found. Default action is to continue.
  • unavail -- the database is permanently unavailable. Default action is to continue.
  • tryagain -- the database is temporarily unavailable, and you can try again. Default action is to continue.

For example, to configure the system as outlined above, where only a system failure causes a fallover to the local files, you might use the following, as shown in Listing 7.

Listing 7. Configuring the system
hosts: nis [NOTFOUND=return][UNAVAIL=continue] files

Care should be taken, however, when configuring the options for login information. If you are not sharing your root user and password (and other system users) over NIS, then you should not configure a failure to find a match to 'return'. Setting the configuration like this prevents users not in NIS from logging in, including the root user.

Keeping your databases up to date

In order for NIS to work properly, you must update the databases. Simply updating the files is not enough, you must recreate the NIS maps and, if you are using slave servers, push or reload the NIS master maps to the slaves.

The easiest way to do this is to use the Makefile on the master (see Listing 8).

Listing 8. Using the Makefile on the master
$ cd /var/yp
$ make

This recreates the maps and pushes the map changes to the slave servers.


The NIS system provides one of the simplest methods of sharing login, password, hosts, and other information, essentially by exposing your existing file-based data through a network interface.

NIS maps revolve around the NIS domainname, a unique identifier for all of the hosts within a network group. Information is tagged with this domain and then shared. Setting up NIS is also straightforward, with just a few commands required to set up a master server, slave, or NIS client.

Downloadable resources

Related topics

Zone=AIX and UNIX
ArticleTitle=System Administration Toolkit: Managing NIS services for authorizations