Solaris Naming Setup and Configuration Guide

Part III NIS Setup and Configuration

This part describes how to set up and configure the Network Information Service (NIS) service. It has one chapter.

Chapter 10 Configuring NIS Service

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

See Solaris Naming Administration Guide for a general description and overview of NIS.

NIS in the Solaris 7 release

The following NIS features are new or different in Solaris 7 release.

NSKit Discontinued

The most recent Solaris releases have not included NIS service. Up to now, NIS service had to be installed from the unbundled NSKit. NIS has now been included in the base Solaris 7 release, and there is no 7-level NSKit.

Because NIS service is now part of the base Solaris 7 release, the SUNWnsktu and SUNWnsktr packages no longer exist. Instead, NIS is now installed via the Solaris 7 release SUNWypu and SUNWypr packages.

NIS service is no longer started with the /etc/init.d/yp script, which no longer exists. With the Solaris 7 release, you first configure your master server NIS maps with the ypinit script, then start NIS with the /usr/lib/netsvc/yp/ypstart script (these steps are described in detail in the following sections of this chapter). NIS service is stopped with the ypstop command.

Enhanced ypupdated Daemon

The most recent versions of NSKit did not include the ypupdated daemon. The ypupdated daemon is now included in this Solaris release.

Before You Begin Configuring NIS

Before configuring your NIS namespace, you must:

Planning Your NIS Domain

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

Planning the Domain

Decide which machines will be in your NIS domain(s). A 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(s).

Choose a NIS domain name. A NIS domain name can be up to 256 characters long, though much shorter names are more practical. 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 doc.com, you can name your NIS domain doc.com. If you wanted to divide doc.com into two NIS domains, one for the sales department and the other for the manufacturing department, you could name one sales.doc.com and the other manf.doc.com.

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

Decide which machines will be NIS servers. Select one machine to be the master server (you can always change this at a later date). Decide which machines, if any, will be slave servers. (See Solaris Naming Administration Guide for a general overview of NIS and NIS requirements.)

Identify Your NIS Client Machines

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

NIS Configuration Steps

After your Solaris 7 release software and nsswitch.conf files are installed, and your domain planned, you must perform the following steps to configure NIS:

  1. Prepare the master server (see "Preparing the Master Server").

  2. Configure the NIS master server (see "How to Set Up the Master Server With ypinit").

  3. Start the NIS daemons on the master server (see "Starting NIS Service on the Master Server").

  4. Configure your slave servers (see "Setting Up NIS Slave Servers").

  5. Configure NIS client machines (see "Setting Up NIS Clients").


Note -

In some contexts, machine names are referred to as host names or workstation names. This discussion uses "machine," but some screen messages or NIS map names may use host or workstation.


The following sections explain these steps in detail.

Preparing the Master Server

Setting up the master server involves converting the source (input) text files on the master into NIS master server maps. Before doing this, however, you need to take several precautions.

Source Files Directory

The source files may be located either in the /etc directory on the master server or in some other directory. Having them in /etc might be 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 would have access to the master server maps and the root password would be passed to all YP clients through the passwd map. (See "Passwd Files and Namespace Security" for additional information on this subject).

However, if you choose to locate 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.)

Passwd Files and Namespace Security

The passwd map is a special case. In addition to the old Solaris 1.x passwd file format, this implementation of NIS accepts the Solaris 7 release /etc/passwd and /etc/shadow file format 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 /usr/lib/netsvc/yp/ypstart script automatically sets the correct directory option according to the configuration specified in your Makefile.

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.


Caution - Caution -

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


Preparing the Master Server -- Task Map

Table 10-1 Preparing the Master Server
 

Task 

 

Description 

 

For Instructions, Go To 

 

Preparing the Master Server 

 

Prepare the master server 

 

"How To Prepare Source Files for Conversion to NIS Maps"

 
 

 

 

 

 

"How to Set Up the Master Server With ypinit"

      

How To Prepare Source Files for Conversion to NIS Maps

Prepare the source files for conversion to NIS maps.

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

    Check the following files:

    • auto.home or auto_home

    • auto.master or auto_master

    • bootparams

    • ethers

    • group

    • hosts

    • netgroup

    • netmasks

    • networks

    • passwd

    • protocols

    • rpc

    • service

    • shadow

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

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

  4. 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. Make sure the /etc/mail/aliases source file is complete by verifying that it contains all the mail aliases that you want to have available throughout the domain. Refer to the aliases man page for more information.

  5. 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.)

  6. Check to 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 the next section, "How to Set 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 similar to Example 10-1 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:


Example 10-1 Default Makefile Before Modification


# "@(#)Makefile 1.15 95/05/05 SMI"
#
# It is somewhat confusing to note that Solaris 2.x uses
# /etc/auto_master instead of the 4.x /etc/auto.master file name
# because of NIS+ treating a "." in a special way.
#
# Set the following variable to "-b" to have NIS servers use the
# domain name resolver for hosts not in the current domain.
#B=-b
B=
DIR =/etc
#
# 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`
all: passwd group hosts ethers networks rpc services protocols \
netgroup bootparams aliases publickey netid netmasks c2secure \
timezone auto.master auto.home
passwd.time: $(PWDIR)/passwd $(PWDIR)/shadow
	-@if [ -f $(PWDIR)/security/passwd.adjunct ]; then \
		(nawk 'BEGIN { FS=":"; OFS=":" } /^[a-zA-Z0-9_]/\
		{ $$2 = "##" $$1; printf "%s\t%s\n", \
		$$1, $$0 }' $(PWDIR)/passwd $(CHKPIPE)) | \
		$(MAKEDBM) - $(YPDBDIR)/$(DOM)/passwd.byname; \
	(nawk 'BEGIN { FS=":"; OFS=":" } /^[a-zA-Z0-9_]/ \
		{ $$2 = "##" $$1; printf "%-10d\t%s\n", $$3, $$0 }'\
		$(PWDIR)/passwd $(CHKPIPE)) | \
		$(MAKEDBM) - $(YPDBDIR)/$(DOM)/passwd.byuid; \
	(nawk 'BEGIN { FS=":"; OFS=":"; while ( getline \
		< "$(PWDIR)/shadow" > 0) shadow[$$1] = $$2; } /^[a-zA-Z0-9_]/
		{ $$2 = shadow[$$1]; \
		printf "%-10d\t%s\n",$$3,$$0 }' \
		$(PWDIR)/passwd $(CHKPIPE))| \
		$(MAKEDBM) - $(YPDBDIR)/$(DOM)/passwd.byuid; \
else \
	(awk 'BEGIN { FS=":"; OFS="\t"; } /^[a-zA-Z0-9_]/ \
		{ print $$1, $$0 }' $(PWDIR)/passwd $(CHKPIPE))| \
		$(MAKEDBM) - $(YPDBDIR)/$(DOM)/passwd.byname; \
	(awk 'BEGIN { FS=":"; OFS="\t"; } /^[a-zA-Z0-9_]/ \
		{ printf("%-10d ", $$3); print $$0 }' $(PWDIR)/passwd\
		$(CHKPIPE))| $(MAKEDBM) - $(YPDBDIR)/$(DOM)/passwd.byuid;
\
fi
	@touch passwd.time;
	@echo "updated passwd";
	@if [ ! $(NOPUSH) ]; then $(YPPUSH) -d $(DOM) passwd.byname;
fi
	@if [ ! $(NOPUSH) ]; then $(YPPUSH) -d $(DOM) passwd.byuid; fi
	@if [ ! $(NOPUSH) ]; then echo "pushed passwd"; fi group.time: $(DIR)/group
	@(awk 'BEGIN { FS=":"; OFS="\t"; } /^[a-zA-Z0-9_]/ \
		{ print $$1, $$0 }' $(DIR)/group $(CHKPIPE))| \
		$(MAKEDBM) - $(YPDBDIR)/$(DOM)/group.byname;
	@(awk 'BEGIN { FS=":"; OFS="\t"; } /^[a-zA-Z0-9_]/ \
		{ printf("%-10d ", $$3); print $$0 }' \
		$(DIR)/group $(CHKPIPE)) | $(MAKEDBM) - \
		$(YPDBDIR)/$(DOM)/group.bygid;
	@touch group.time;
	@echo "updated group";
	@if [ ! $(NOPUSH) ]; then $(YPPUSH) -d $(DOM) group.byname; fi
	@if [ ! $(NOPUSH) ]; then $(YPPUSH) -d $(DOM) group.bygid; fi
	@if [ ! $(NOPUSH) ]; then echo "pushed group"; fi.
.
passwd: passwd.time
group: group.time
hosts: hosts.time
ethers: ethers.time
networks: networks.time
netmasks: netmasks.time
timezone: timezone.time
auto.master: auto.master.time
auto.home: auto.home.time
$(DIR)/netid:
$(DIR)/timezone:
$(DIR)/auto_master:
$(DIR)/auto_home:
$(PWDIR)/shadow:

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 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.

How to Set Up the Master Server With ypinit

The /usr/sbin/ypinit shell 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, follow these steps:

  1. Become root on the master server and ensure that the name service gets its information from the /etc files, not from NIS, by typing:


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

  3. To build new maps on the master server, type:


    # /usr/sbin/ypinit -m
  4. 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.

  5. 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 Table 10-3 for a description of all default NIS maps.


  6. 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. You must answer yes to install the new version of NIS.

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


    # 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 and runs makedbm on them, 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.

  8. To enable NIS as the naming service, type:


    # 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, a NIS master server supports only one NIS domain. However, if you are using a master server to support multiple domains, you must modify the steps slightly, as described in the section above, 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 the section above 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

Where 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 password map to the intended domain, instead of the domain to which the master belongs.

Starting 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. To do this, you have to start ypserv on the server and run ypbind. 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.

There are two ways that NIS service can be started 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 ypserve when the machine is booted. (See "How to Set Up the Master Server With ypinit".)

Starting NIS From the Command Line

To begin NIS service from the command line, run the /usr/lib/netsvc/yp/ypstart script:


#/usr/lib/netsvc/yp/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 ypstart when calling it from inside a program or script.


DNS Forwarding

In the Solaris 7 release, if the /etc/resolv.conf file is present ypstart will start up ypserve with DNS forwarding. If you do not want the DNS forwarding option set, edit the /usr/lib/netsvc/yp/ypstart script to remove the -d option from the ypserv command. You must then reboot the machine.

For more information about using NIS with DNS, refer to Chapter 13, Setting Up DNS Servers and Solaris Naming Administration Guide.

Stopping NIS with ypstop

To stop NIS service, run the ypstop command:


#/usr/lib/netsvc/yp/ypstop

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 NIS Slave Servers -- Task Map

Table 10-2 Setting Up NIS Slave Servers
 

Task 

 

Description 

 

For Instructions, Go To 

 

Setting Up NIS Slave Servers 

 

Set up NIS slave servers 

 

"How to Set Up a Slave Server"

 
      

How to Set Up a Slave Server

Now you are ready to create a new slave server, as follows:

  1. As root, edit the /etc/hosts file on the slave server to add the name and IP addresses of all the other NIS servers.

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

  3. To initialize the slave server as a client, type the following:


    # /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).


    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. To determine if ypbind is running, type:


    # ps -ef | grep ypbind

    If a listing is displayed, ypbind is running.

  5. If ypbind is running, stop it by typing:


    # /usr/lib/netsvc/yp/ypstop
  6. Type the following to restart ypbind:


    # /usr/lib/netsvc/yp/ypstart
  7. To initialize this machine as a slave, type the following:


    # /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.

Starting NIS Service on a Slave Server

Now you can start daemons on the slave server and begin NIS service. All existing yp processes must be stopped, by typing:


# /usr/lib/netsvc/yp/ypstop

To start ypserv on the slave server and run ypbind, type:


# /usr/lib/netsvc/yp/ypstart

Alternatively, you can reboot the slave server and daemons will be started automatically.

Setting Up NIS Clients

You must perform two tasks to allow a machine to use NIS:

Configuring a Machine to Use NIS

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

You will be asked to name NIS servers from which the client obtains name service information. You can list as many master or slave servers as you want. The servers that you list can be located anywhere in the domain. It is a better practice to first list the servers closest (in net terms) to the machine, than those that are on more distant parts of the net.

When you run ypbind, it searches the local subnet for an NIS server. If it finds one, it binds to it. This search is referred to as broadcasting. If there is no NIS server on the client's local subnet, it fails to bind and the client machine is not able to obtain namespace data from the NIS service.

NIS Maps

The namespace data set used by NIS is stored in a set of NIS maps. NIS maps are essentially two-column tables.

Default NIS Maps

Table 10-3 describes the default NIS maps, information they contain, and whether the operating system consults the corresponding administrative files when NIS is running.

Table 10-3 NIS Map Descriptions

Map Name 

Corresponding NIS Admin File 

Description 

bootparams

bootparams

Contains path names of files clients need during boot: root, swap, possibly others. 

ethers.byaddr

ethers

Contains machine names and Ethernet addresses. The Ethernet address is the key in the map. 

ethers.byname

ethers

Same as ethers.byaddr, except the key is machine name instead of the Ethernet address.

group.bygid

group

Contains group security information with group ID as key. 

group.byname

group

Contains group security information with group name as key.  

hosts.byaddr

hosts

Contains machine name, and IP address, with IP address as key. 

hosts.byname

hosts

Contains machine name and IP address, with machine (host) name as key. 

mail.aliases

aliases

Contains aliases and mail addresses, with aliases as key. 

mail.byaddr

aliases

Contains mail address and alias, with mail address as key. 

netgroup.byhost

netgroup

Contains group name, user name, and machine name. 

netgroup.byuser

netgroup

Same as netgroup.byhost, except that key is user name.

netgroup

netgroup

Same as netgroup.byhost, except that key is group name.

netid.byname

passwd, hosts, group

Used for UNIX-style authentication. Contains the netname database. If there is a netid file available it is consulted in addition to the data available through the other files.

netmasks.byaddr

netmasks

Contains network mask to be used with IP subnetting, with the address as the key. 

networks.byaddr

networks

Contains names of networks known to your system and their IP addresses, with the address as the key. 

networks.byname

networks

Same as networks.byaddr, except the key is the name of the network.

passwd.adjunct. byname

passwd and shadow

Contains auditing information and the hidden password information for C2 clients. 

passwd.byname

passwd and shadow

Contains password information with user name as key. 

passwd.byuid

passwd and shadow

Same as passwd.byname, except that the key is user ID.

protocols.byname

protocols

Contains network protocols known to your network. 

protocols.bynumber

protocols

Same as protocols.byname, except that key is protocol number.

rpc.bynumber

rpc

Contains program number and name of RPCs known to your system. Key is RPC program number. 

services.byname

services

Lists Internet services known to your network. Key is port and protocol. 

services.byservice

services

Lists Internet services known to your network. Key is service name. 

ypservers

N/A 

Lists NIS servers known to your network. 

Modifying NIS Maps

See Solaris Naming Administration Guide for information on modifying NIS maps after they are created.

NIS Administration, Problem Solving, and Error Messages

See Solaris Naming Administration Guide for information on NIS administration, problem solving, and error messages.