System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP)

Chapter 5 Setting Up and Configuring NIS Service

This chapter describes initial set up and configuration of the Network Information Service (NIS).

Note –

In some contexts, machine names are referred to as host names or machine names. This discussion uses “machine,” but some screen messages or NIS map names might use host or machine.

This chapter covers the following topics.

Configuring NIS Task Map


For Instructions, Go To 

Prepare source files for conversion. 

Preparing Source Files for Conversion to NIS Maps

Set up master server using ypinit

Setting Up the Master Server With ypinit

Start NIS on master server. 

Starting and Stopping NIS Service on the Master Server

Set up slave servers. 

Setting Up a Slave Server

Set up NIS client. 

Setting Up NIS Clients

Before You Begin Configuring NIS

Before configuring your NIS namespace, you must do the following.

NIS and the Service Management Facility

The NIS service is managed by the Service Management Facility. For an overview of SMF, refer to Chapter 18, Managing Services (Overview), in System Administration Guide: Basic Administration. Also refer to the svcadm(1M) and svcs(1) man pages for more details.

Planning Your NIS Domain

Before you configure machines as NIS servers or clients, you must plan the NIS domain.

Decide which machines will be in your NIS domain. An NIS domain does not have to be congruent with your network. A network can have more than one NIS domain, and there can be machines on your network that are outside of your NIS domain.

Choose an NIS domain name, which can be 256 characters long. A good practice is to limit domain names to no more than 32 characters. Domain names are case-sensitive. For convenience, you can use your Internet domain name as the basis for your NIS domain name. For example, if your Internet domain name is, you can name your NIS domain If you wanted to divide into two NIS domains, one for the sales department and the other for the manufacturing department, you could name one and the other

Before a machine can use NIS services, the correct NIS domain name and machine name must be set. A machine's name is set by the machine's /etc/nodename file and the machine's domain name is set by the machine's /etc/defaultdomain file. These files are read at boot time and the contents are used by the uname -S and domainname commands, respectively. Diskless machines read these files from their boot server.

Identify Your NIS Servers and Clients

Select one machine to be the master server. Decide which machines, if any, will be slave servers.

Decide which machines will be NIS clients. Typically all machines in your domain are set to be NIS clients, although this is not necessary.

Preparing the Master Server

The following sections describe how to prepare the source files and the passwd files for the master server.

Source Files Directory

The source files should be located in the /etc directory, on the master server or in some other directory. Having them in /etc is undesirable because the contents of the maps are then the same as the contents of the local files on the master server. This is a special problem for passwd and shadow files because all users have access to the master server maps and the root password would be passed to all NIS clients through the passwd map. See Passwd Files and Namespace Security for additional information.

However, if you put the source files in some other directory, you must modify the Makefile in /var/yp by changing the DIR=/etc line to DIR=/your-choice, where your-choice is the name of the directory you will be using to store the source files. This allows you to treat the local files on the server as if they were those of a client. (It is good practice to first save a copy of the original Makefile.)

In addition, if audit_user, auth_attr, exec_attr and prof_attr are to be taken from a directory other than the default, you must amend the RBACDIR =/etc/security to RBACDIR=/your-choice.

Passwd Files and Namespace Security

The passwd map is a special case. In addition to the old Solaris 1 passwd file format, this implementation of NIS accepts the /etc/passwd and /etc/shadow file formats as input for building the NIS password maps.

For security reasons, the files used to build the NIS password maps should not contain an entry for root, to prevent unauthorized root access. Therefore, the password maps should not be built from the files located in the master server's /etc directory. The password files used to build the password maps should have the root entry removed from them and be located in a directory that can be protected from unauthorized access.

For example, the master server password input files should be stored in a directory such as /var/yp, or any directory of your choice, as long as the file itself is not a link to another file and its location is specified in the Makefile. The correct directory option is set automatically according to the configuration specified in your Makefile.

Caution – Caution –

Be sure that the passwd file in the directory specified by PWDDIR does not contain an entry for root.

If your source files are in a directory other than /etc, you must alter the PWDIR password macro in the Makefile to refer to the directory where the passwd and shadow files reside, changing the line PWDIR=/etc to PWDIR/your-choice, where your-choice is the name of the directory you will be using to store the passwd map source files.

Preparing Source Files for Conversion to NIS Maps

Prepare the source files for conversion to NIS maps.

ProcedureHow to Prepare Source Files for Conversion

  1. Become superuser or assume an equivalent role.

    Roles contain authorizations and privileged commands. For more information about roles, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services.

  2. Check the source files on the master server to make sure they reflect an up-to-date picture of your system.

    Check the following files:

    • auto.home or auto_home

    • auto.master or auto_master

    • audit_user

    • auth_attr

    • bootparams

    • ethers

    • exec_attr

    • group

    • hosts

    • ipnodes

    • netgroup

    • netmasks

    • networks

    • passwd

    • protocols

    • rpc

    • service

    • shadow

    • user_attr

  3. Copy all of these source files, except passwd, to the DIR directory that you have selected.

  4. Copy the passwd file to the PWDIR directory that you have selected.

  5. Copy audit_user, auth_attr, exec_attr, and prof_attr to the selected RBACDIR directory.

  6. Check the /etc/mail/aliases file.

    Unlike other source files, the /etc/mail/aliases file cannot be moved to another directory. This file must reside in the /etc/mail directory. Refer to aliases(4) for more information.

    Note –

    You can add a nis-specific mail aliases file by pointing the ALIASES = /etc/mail/aliases entry in /var/yp/Makefile to another location. When you then run a make, the ALIASES entry creates a mail.aliases map. The sendmail service uses this map in addition to the /etc/mail/aliases file when the /etc/nsswitch.conf file properly targets nis in addition to files. Refer to Modifying and Using the Makefile.

  7. Clean all comments and other extraneous lines and information from the source files.

    These operations can be done through a sed or awk script or with a text editor. The Makefile performs some file cleaning automatically for you, but it is good practice to examine and clean these files by hand before running.

  8. Make sure that the data in all the source files is correctly formatted.

    Source file data needs to be in the correct format for that particular file. Check the man pages for the different files to make sure that each file is in the correct format.

Preparing the Makefile

After checking the source files and copying them into the source file directory, you now need to convert those source files into the ndbm format maps that the NIS service uses. This is done automatically for you by ypinit when called on the master server, as explained in Setting Up the Master Server With ypinit.

The ypinit script calls the program make, which uses the Makefile located in the /var/yp directory. A default Makefile is provided for you in the /var/yp directory and contains the commands needed to transform the source files into the desired ndbm format maps.

You can use the default Makefile as it is, or modify it if you want. (If you do modify the default Makefile, be sure to first copy and store the original default Makefile in case you need it for future use.) You might need to make one or more of the following modifications to the Makefile:

The function of the Makefile is to create the appropriate NIS maps for each of the databases listed under all. After passing through makedbm the data is collected in two files, mapname.dir and mapname.pag. Both files are in the /var/yp/domainname directory on the master server.

The Makefile builds passwd maps from the /PWDIR/passwd, /PWDIR/shadow, and /PWDIR/security/passwd.adjunct files, as appropriate.

Setting Up the Master Server With ypinit

The ypinit script sets up master and slave servers and clients to use NIS. It also initially runs make to create the maps on the master server.

To use ypinit to build a fresh set of NIS maps on the master server, do the following.

ProcedureHow to set up the master server using ypinit

  1. On the master server, become superuser or assume an equivalent role.

    Roles contain authorizations and privileged commands. For more information about roles, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services.

  2. Copy the contents of the nsswitch.files file to the nsswitch.conf file.

    # cp /etc/nsswitch.files /etc/nsswitch.conf
  3. Edit the /etc/hosts or /etc/inet/ipnodes file to add the name and IP address of each of the NIS servers.

  4. Build new maps on the master server.

    # /usr/sbin/ypinit -m
  5. When ypinit prompts for a list of other machines to become NIS slave servers, type the name of the server you are working on, along with the names of your NIS slave servers.

  6. When ypinit asks whether you want the procedure to terminate at the first nonfatal error or continue despite nonfatal errors, type y.

    When you choose y, ypinit exits upon encountering the first problem; you can then fix it and restart ypinit. This is recommended if you are running ypinit for the first time. If you prefer to continue, you can try to manually fix all problems that occur, and then restart ypinit.

    Note –

    A nonfatal error can appear when some of the map files are not present. This is not an error that affects the functionality of NIS. You might need to add maps manually if they were not created automatically. Refer to Default NIS Maps for a description of all default NIS maps.

  7. ypinit asks whether the existing files in the /var/yp/domainname directory can be destroyed.

    This message is displayed only if NIS has been previously installed.

  8. After ypinit has constructed the list of servers, it invokes make.

    This program uses the instructions contained in the Makefile (either the default one or the one you modified) located in /var/yp. The make command cleans any remaining comment lines from the files you designated. It also runs makedbm on the files, creating the appropriate maps and establishing the name of the master server for each map.

    If the map or maps being pushed by the Makefile correspond to a domain other than the one returned by the command domainname on the master, you can make sure that they are pushed to the correct domain by starting make in the ypinit shell script with a proper identification of the variable DOM, as follows:

    # make DOM=domainname password

    This pushes the password map to the intended domain, instead of the domain to which the master belongs.

  9. To enable NIS as the naming service, type the following.

    # cp /etc/nsswitch.nis /etc/nsswitch.conf

    This replaces the current switch file with the default NIS-oriented switch file. You can edit this file as necessary.

Master Supporting Multiple NIS Domains

Normally, an NIS master server supports only one NIS domain. However, if you are using a master server to support multiple domains, you must slightly modify the steps, as described in Setting Up the Master Server With ypinit, when setting up the server to serve the additional domains.

Run the domainname command on the server. The domain name returned by the command is the server's default domain. The steps described in Setting Up the Master Server With ypinit will work properly for setting up service for that domain. To configure service for any other domain, you must modify the ypinit shell script as follows.

# make DOM=correct-domain passwd

correct-domain is the name of the other domain that you are setting up service for, and passwd is the make target. This command pushes the passwd map to the intended domain, instead of the domain to which the master belongs.

Starting and Stopping NIS Service on the Master Server

Now that the master maps are created, you can start the NIS daemons on the master server and begin service. When you enable the NIS service, ypserv and ypbind start on the server. When a client requests information from the server, ypserv is the daemon that answers information requests from clients after looking them up in the NIS maps. The ypserv and ypbind daemons are administered as a unit.

There are three ways that NIS service can be started or stopped on a server:

Starting NIS Service Automatically

After the NIS master server has been configured by running ypinit, ypstart is automatically invoked to start up ypserv when the machine is booted. See Setting Up the Master Server With ypinit.

Starting and Stopping NIS From the Command Line

Use the Service Management Facility svcadm commands or the ypstart/ypstop commands to start and stop NIS from the command line. When using svcadm, the instance name is needed only if you are running more than one instance of the service. For more information, see NIS and the Service Management Facility, or see the svcadm(1M), ypstart(1M), and ypstop(1M) man pages.

To begin NIS service from the command line, run the svcadm enable command or the ypstart command.

# svcadm enable network/nis/server:<instance>
# svcadm enable network/nis/client:<instance>
# ypstart

Note –

Because there is a slight delay before ypserv is ready to respond to calls after startup, you should issue a three to five second sleep after svcadm when calling it from inside a program or script.

To stop NIS service, run the svcadm disable command or the ypstop.

# svcadm disable network/nis/server:<instance>
# svcadm disable network/nis/client:<instance>
# ypstop

To stop and immediately restart an NIS service, use the svcadm restart command.

# svcadm restart network/nis/server:<instance>
# svcadm restart network/nis/client:<instance>

Setting Up NIS Slave Servers

Your network can have one or more slave servers. Having slave servers ensures the continuity of NIS services when the master server is not available.

Preparing a Slave Server

Before actually running ypinit to create the slave servers, you should run the domainname command on each NIS slave to make sure the domain name is consistent with the master server.

Note –

Domain names are case-sensitive.

Make sure that the network is working properly before you configure an NIS slave server. In particular, check to be sure you can use rcp to send files from the master NIS server to NIS slaves.

Setting Up a Slave Server

The following procedure shows how to set up a slave server.

ProcedureHow to Set Up a Slave Server

  1. Become superuser or assume an equivalent role.

    Roles contain authorizations and privileged commands. For more information about roles, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services.

  2. Edit the /etc/hosts or /etc/inet/ipnodes file on the slave server to add the name and IP addresses of all the other NIS servers.

  3. Change directory to /var/yp on the slave server.

    Note –

    You must first configure the new slave server as an NIS client so that it can get the NIS maps from the master for the first time. See Setting Up NIS Clients for details.

  4. Initialize the slave server as a client.

    # /usr/sbin/ypinit -c

    The ypinit command prompts you for a list of NIS servers. Enter the name of the local slave you are working on first, then the master server, followed by the other NIS slave servers in your domain in order from the physically closest to the furthest in network terms.

  5. Determine if the NIS client is running, then start the client service as needed.

    # svcs network/nis/client
    STATE          STIME     FMRI
    online         20:32:56  svc:/network/nis/client:default

    If svc:/network/nis/client is displayed with an online state, then NIS is running. If the service state is disabled, then NIS is not running.

    1. If the NIS client is running, restart the client service.

      # svcadm restart network/nis/client
    2. If the NIS client is not running, start the client service.

      # svcadm enable network/nis/client
  6. Initialize this machine as a slave.

    # /usr/sbin/ypinit -s master

    Where master is the machine name of the existing NIS master server.

    Repeat the procedures described in this section for each machine you want configured as an NIS slave server.

ProcedureHow to Start NIS on a Slave Server

The following procedure shows how to start NIS on a slave server.

  1. Become superuser or assume an equivalent role.

    Roles contain authorizations and privileged commands. For more information about roles, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services.

Setting Up NIS Clients

The two methods for configuring a client machine to use NIS as its naming service are explained below.

Note –

The Solaris operating system does not support a configuration in which a NIS client and a Native LDAP client co-exist on the same client machine.

Note –

For reasons of security and administrative control it is preferable to specify the servers a client is to bind to in the client's ypservers file rather than have the client search for servers through broadcasting. Broadcasting slows down the network, slows the client, and prevents you from balancing server load by listing different servers for different clients.