Part III NIS Setup and Administration

This part provides an overview of the NIS naming service, as well as the setup, administration and troubleshooting of NIS within the Solaris operating environment.

Chapter 7 Network Information Service (NIS) (Overview)

This chapter provides an overview of the Network Information Service (NIS).

NIS is a distributed naming service. It is a mechanism for identifying and locating network objects and resources. It provides a uniform storage and retrieval method for network-wide information in a transport-protocol and media-independent fashion.

This chapter covers the following topics.

• NIS Introduction

• NIS Machine Types

• NIS Elements

• NIS Binding

• Differences in NIS Solaris 2.6 NIS and Earlier NIS Versions

NIS Introduction

By running NIS, the system administrator can distribute administrative databases, called maps, among a variety of servers (master and slaves). The administrator can update those databases from a centralized location in an automatic and reliable fashion to ensure that all clients share the same naming service information in a consistent manner throughout the network.

NIS was developed independently of DNS and has a slightly different focus. Whereas DNS focuses on making communication simpler by using machine names instead of numerical IP addresses, NIS focuses on making network administration more manageable by providing centralized control over a variety of network information. NIS stores information not only about machine names and addresses, but also about users, the network itself, and network services. This collection of network information is referred to as the NIS namespace.

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

NIS Architecture

NIS uses a client-server arrangement. NIS servers provide services to NIS clients. The principal servers are called master servers, and for reliability, they have backup, or slave servers. Both master and slave servers use the NIS information retrieval software and both store NIS maps.

NIS uses domains to arrange the machines, users, and networks in its namespace. However, it does not use a domain hierarchy; an NIS namespace is flat.

Thus, this physical network would be arranged into one NIS domain.

An NIS domain cannot be connected directly to the Internet using just NIS. However, organizations that want to use NIS and also be connected to the Internet can combine NIS with DNS. You can use NIS to manage all local information and use DNS for Internet host lookup. NIS provides a forwarding service that forwards host lookups to DNS if the information cannot be found in an NIS map. The Solaris operating environment also allows you to set up the nsswitch.conf file so that hosts lookup requests go only to DNS, or to DNS and then NIS if not found by DNS, or to NIS and then DNS if not found by NIS. See Chapter 2, The Name Service Switch (Overview) for details.

NIS Machine Types

There are three types of NIS machines.

• Master server

• Slave servers

• Clients of NIS servers

Any machine can be an NIS client, but only machines with disks should be NIS servers, either master or slave. Servers are also clients, typically of themselves.

NIS Servers

The NIS server does not have to be the same machine as the NFS file server.

NIS servers come in two varieties, master and slave. The machine designated as master server contains the set of maps that the system administrator creates and updates as necessary. Each NIS domain must have one, and only one, master server, which can propagate NIS updates with the least performance degradation.

You can designate additional NIS servers in the domain as slave servers. A slave server has a complete copy of the master set of NIS maps. Whenever the master server maps are updated, the updates are propagated among the slave servers. Slave servers can handle any overflow of requests from the master server, minimizing “server unavailable” errors.

Normally, the system administrator designates one master server for all NIS maps. However, because each individual NIS map has the machine name of the master server encoded within it, you could designate different servers to act as master and slave servers for different maps. To minimize confusion, designate a single server as the master for all the maps you create within a single domain. The examples in this chapter assume that one server is the master for all maps in the domain.

NIS Clients

NIS clients run processes that request data from maps on the servers. Clients do not make a distinction between master and slave servers, since all NIS servers should have the same information.

NIS Elements

The NIS naming service is composed of the following elements:

• Domains (see The NIS Domain).

• Maps (see NIS Maps).

• Daemons (see NIS Daemons).

• Utilities (see NIS Utilities).

• NIS Command Set (see NIS-Related Commands).

The NIS Domain

An NIS domain is a collection of machines which share a common set of NIS maps. Each domain has a domain name and each machine sharing the common set of maps belongs to that domain.

Any machine can belong to a given domain, as long as there is a server for that domain's maps in the same network. An NIS client machine obtains its domain name and binds to an NIS server as part of its boot process.

NIS Daemons

NIS service is provided by five daemons as shown in Table 7–1.

rpc.yppasswdd considers all shells that begin with an r to be restricted. This means that users who have a shell that begins with an r. For example, if you are in /bin/rksh, you are not allowed to change from that shell to another one. If you have a shell that begins with r but is not intended to be restricted as such, refer to Chapter 10, NIS Troubleshooting for the workaround.

NIS Utilities

NIS service is supported by nine utilities as shown in Table 7–2.

NIS Maps

The information in NIS maps is stored in ndbm format. ypfiles(4) and ndbm(3C) explain the format of the map file.

NIS maps were designed to replace UNIX /etc files, as well as other configuration files, so they store much more than names and addresses. On a network running NIS, the NIS master server for each NIS domain maintains a set of NIS maps for other machines in the domain to query. NIS slave servers also maintain duplicates of the master server's maps. NIS client machines can obtain namespace information from either master or slave servers.

NIS maps are essentially two-column tables. One column is the key and the other column is information related to the key. NIS finds information for a client by searching through the keys. Some information is stored in several maps because each map uses a different key. For example, the names and addresses of machines are stored in two maps: hosts.byname and hosts.byaddr. When a server has a machine's name and needs to find its address, it looks in the hosts.byname map. When it has the address and needs to find the name, it looks in the hosts.byaddr map.

An NIS Makefile is stored in the /var/yp directory of machines designated as an NIS server at installation time. Running make in that directory causes makedbm to create or modify the default NIS maps from the input files.

Always create maps on the master server, as maps created on a slave will not automatically be pushed to the master server.

Default NIS Maps

A default set of NIS maps are provided in the Solaris operating environment. You might want to use all these maps or only some of them. NIS can also use whatever maps you create or add when you install other software products.

Default maps for a NIS domain are located in each server's /var/yp/domainname directory. For example, the maps that belong to the domain test.com are located in each server's /var/yp/test.com directory.

Table 7–3 describes the default NIS maps, information they contain, and whether the software consults the corresponding administrative files when NIS is running.

New ipnodes maps (ipnodes.byaddr and ipnodes.byname) are added to NIS. The maps store both IPv4 and IPv6 addresses. See the ipnodes(4) man page. NIS clients and servers can communicate using either IPv4 or IPv6 RPC transports.

Using NIS Maps

NIS makes updating network databases much simpler than with the /etc files system. You no longer have to change the administrative /etc files on every machine each time you modify the network environment.

For example, when you add a new machine to a network running NIS, you only have to update the input file in the master server and run make. This automatically updates the hosts.byname and hosts.byaddr maps. These maps are then transferred to any slave servers and are made available to all of the domain's client machines and their programs. When a client machine or application requests a machine name or address, the NIS server refers to the hosts.byname or hosts.byaddr map as appropriate and sends the requested information to the client.

You can use the ypcat command to display the values in a map. The ypcat basic format is the following.

% ypcat mapname

where mapname is the name of the map you want to examine or its nickname. If a map is composed only of keys, as in the case of ypservers, use ypcat -k. Otherwise, ypcat prints blank lines. The ypcat(1) man page describes more options for ypcat.

You can use the ypwhich command to determine which server is the master of a particular map. Type the following.

% ypwhich -m mapname

where mapname is the name or the nickname of the map whose master you want to find. ypwhich responds by displaying the name of the master server. For complete information, refer to the ypwhich(1) man page.

NIS Map Nicknames

Nicknames are aliases for full map names. To obtain a list of available map nicknames, such as passwd for passwd.byname, type ypcat -x or ypwhich -x.

Nicknames are stored in the /var/yp/nicknames file, which contains a map nickname followed by the fully specified name for the map, separated by a space. This list might be added to or modified. Currently, there is a limit of 500 nicknames.

NIS-Related Commands

The NIS service includes specialized daemons, system programs, and commands, which are summarized in the following table.

NIS Binding

NIS clients get information from an NIS server through the binding process, which can work in one of two modes: server-list or broadcast.

• Server-list. In the server-list mode, the ypbind process queries the /var/yp/binding/domain/ypservers list for the names of all of the NIS servers in the domain. The ypbind process binds only to servers in this file. The file is created by running ypinit -c.

• Broadcast. The ypbind process can also use an RPC broadcast to initiate a binding. Since broadcasts are only local subnet events that are not routed further, there must be at least one server (master or slave) on the same subnet as the client. The servers themselves might exist throughout different subnets since map propagation works across subnet boundaries. In a subnet environment, one common method is to make the subnet router an NIS server. This allows the domain server to serve clients on either subnet interface.

Server-List Mode

The binding process in server-list mode works as follows:

1. Any program, running on the NIS client machine that needs information provided by an NIS map, asks ypbind for the name of a server.

2. ypbind looks in the /var/yp/binding/domainname/ypservers file for a list of NIS servers for the domain.

3. ypbind initiates binding to the first server in the list. If the server does not respond, ypbind tries the second, and so on, until it finds a server or exhausts the list.

4. ypbind tells the client process which server to talk to. The client then sends the request directly to the server.

5. The ypserv daemon on the NIS server handles the request by consulting the appropriate map.

6. ypserv sends the requested information back to the client.

Broadcast Mode

The broadcast mode binding process works as follows:

1. ypbind must be started with the broadcast option set (broadcast).

2. ypbind issues an RPC broadcast in search of an NIS server.

   ---

   Note –

   In order to support such clients, it is necessary to have an NIS server on each subnet requiring NIS service.

   ---

3. ypbind initiates binding to the first server that responds to the broadcast.

4. ypbind tells the client process which server to talk to. The client then sends the request directly to the server.

5. The ypserv daemon on the NIS server handles the request by consulting the appropriate map.

6. ypserv sends the requested information back to the client.

Normally, once a client is bound to a server it stays bound to that server until something causes it to change. For example, if a server goes out of service, the clients it served will then bind to new servers.

To find out which NIS server is currently providing service to a specific client, use the following command.

%ypwhich machinename

Where machinename is the name of the client. If no machine name is mentioned, ypwhich defaults to the local machine (that is, the machine on which the command is run).

Differences in NIS Solaris 2.6 NIS and Earlier NIS Versions

The following NIS features are new or different in Solaris 2.6.

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 Solaris 2.6 and there is no 2.6 NSKit.

Because NIS service is now part of the Solaris 2.6, the SUNWnsktu and SUNWnsktr packages no longer exist. Instead, NIS is now installed via the NIS Server cluster (containing the SUNWypu and SUNWypr packages).

NIS service is no longer started with the /etc/init.d/yp script which no longer exists. With the Solaris 2.6, you first configure your master server NIS maps with the ypinit script, and then start NIS with ypstart. NIS service is stopped with the ypstop command.

The ypupdated Daemon

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

The /var/yp/securenets File

As with the previous NSKit release, the /var/yp/securenets file is now used to limit access to NIS services. If such a file exists on an NIS server, the server only answers queries or supplies maps to machines and networks whose IP addresses are listed in the file. For the file format, see securenets(4).

The following is an example of a securenets file.

255.255.255.10	 192.168.0.1
host    13.13.14.1
host    13.13.14.2

where 255.255.255.10 is the netmask and 13.13.13.255 is the network address. For the set up in line 1, ypserv responds to only those addresses in the subnet 13.13.13.255 range.

If you modify entries in the /var/yp/securenets file, you must kill and restart the ypserv and ypxfrd daemons.

Multihomed Machine Support

As with the previous NSKit release, the ypserv process provides support for machines which have more than one network address. When the machine maps are created, the Makefile creates a YP_MULTI_HOSTNAME entry in the map for any machine that has more than one address. This entry lists all the addresses for that machine. When the machine address is needed, an attempt is made to use the closest address on the list. See the ypserv man page for more details.

The determination of closest address is an arithmetic one and as such there is no check for address validity. For example, suppose that a multihomed machine has six IP addresses and only five of the interfaces on the machine are operating normally. Machines on a network that is not directly connected to this multihomed machine can receive the IP address for the down interface from ypserv. Thus, this hypothetical client can not reach the multihomed machine.

All addresses for a multihomed machine should normally be active. If a particular address or machine is going to be out of service, remove it from the NIS maps.

SunOS 4 Compatibility Mode

NIS supports password configuration files in both the SunOS 4 (Solaris 1) password format and the Solaris 2 password and shadow file formats.

The mode of operation is determined by the existence of the file $PWDIR/shadow, where $PWDIR is the Makefile macro set in the /var/yp/Makefile file. If the shadow file exists, NIS operates in the Solaris 2 mode. If this file does not exist, NIS operates in the SunOS 4 mode.

In the SunOS 4 mode, all password information is kept in the passwd file. In the Solaris 2 mode, password information is kept in the shadow file and the user account information is kept in the passwd file.

If the make macro PWDIR is set to the /etc directory, NIS can operate only in the Solaris 2 mode because of the Solaris 2 passwd processing requirements. However, if PWDIR points to any directory other than /etc, the user has the option of keeping passwd configuration files in either the SunOS 4 format or in the Solaris 2 format. The rpc.yppasswdd daemon understands both password formats. The Solaris 2 format is recommended.

Chapter 8 Setting Up and Configuring NIS Service

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

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

• Before You Begin Configuring NIS

• Planning Your NIS Domain

• Preparing the Master Server

• Starting NIS Service on the Master Server

• Setting Up NIS Slave Servers

• Setting Up NIS Clients

Configuring NIS — Task Map

Before You Begin Configuring NIS

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

• Install properly configured nsswitch.conf files on all the machines that will be using NIS. See Chapter 2, The Name Service Switch (Overview) for details.

• Plan your NIS domain. See the following section.

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 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 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 Solaris 7 /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 /usr/lib/netsvc/yp/ypstart script automatically sets the correct directory option according to the configuration specified in your Makefile.

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.

How to Prepare Source Files for Conversion

1. Become superuser.

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

   Check the following files:

   • auto.home or auto_home

   • auto.master or auto_master

   • bootparams

   • ethers

   • 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. Make sure that the /etc/mail/aliases source file contains all the mail aliases that you want to have available throughout the domain. Refer to aliases(4) for more information.

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 the next section, 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:

• Nondefault maps

  If you have created your own non-default source files and want to convert them to NIS maps, you must add those source files to the Makefile.

• DIR value

  If you want the Makefile to use source files stored in some directory other than /etc, as explained in Source Files Directory, you must change the value of DIR in the Makefile to the directory that you want to use. When changing this value in the Makefile, do not indent the line.

• PWDIR value

  If you want the Makefile to use passwd, shadow, and/or adjunct source files stored in some directory other than /etc, you must change the value of PWDIR in the Makefile to the directory that you want to use. When changing this value in the Makefile, do not indent the line.

• Domain name resolver

  If you want the NIS server to use the domain name resolver for machines not in the current domain, comment out the Makefile line B=, and uncomment (activate) the line B= -b.

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.

How to set up the master server using ypinit

1. Become superuser on the master server.

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 the previous section, 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 previous section 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 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:

• By automatically invoking the /usr/lib/netsvc/yp/ypstart script during the boot process

• Using ypstart from the command line

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

To begin NIS service from the command line, run the ypstart script.

# /usr/lib/netsvc/yp/ypstart

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.

To stop NIS service, run the ypstop script.

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

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.

How to Set up a Slave Server

1. Become superuser.

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

5. To determine if ypbind is running, type the following.

   # ps -ef | grep ypbind

   If a listing is displayed, ypbind is running.

6. If ypbind is running, stop it.

   # /usr/lib/netsvc/yp/ypstop

7. Type the following to restart ypbind.

   # /usr/lib/netsvc/yp/ypstart

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

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

How to Start NIS on a Slave Server

1. Become superuser.

2. Stop all existing yp processes.

   # /usr/lib/netsvc/yp/ypstop

3. Start ypserve on the slave and run ypbind.

   # /usr/lib/netsvc/yp/ypstart

   Alternatively, you can reboot the slave server and the daemons start automatically.

Setting Up NIS Clients

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

• ypinit. The recommended method for configuring a client machine to use NIS is to login to the machine as root and run ypinit -c.

  # ypinit —c

  You will be asked to name NIS servers from which the client obtains naming 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 network terms) to the machine, than those that are on more distant parts of the net.

• Broadcast method. An older method of configuring a client machine to use NIS to log in to the machine as root, set the domain name with the domainname command, then run ypbind.

  # domainname doc.com

  # ypbind -broadcast

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

Chapter 9 Administering NIS (Tasks)

This chapter describes how to administer NIS. The following topics are covered.

• Password Files and Namespace Security

• Administering NIS Users

• Working With NIS Maps

• Updating and Modifying Existing Maps

• Adding a Slave Server

• Using NIS With C2 Security

• Changing a Machine's NIS Domain

• Using NIS in Conjunction With DNS

• Turning Off NIS Services

Password Files and Namespace Security

For security reasons, for these guidelines.

• It is best to limit access to the NIS maps on the master server.

• The files used to build the NIS password maps should not contain an entry for root to protect against unauthorized access. To accomplish this, the password files used to build the password maps should have the root entry removed from them and be located in a directory other than the master server's /etc directory. This directory should be secured against unauthorized access.

For example, the master server password input files could 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 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.

In addition to the older Solaris 1 version passwd file format, this implementation of NIS accepts the Solaris 2 passwd and shadow file formats as input for building the NIS password maps.

Administering NIS Users

This section includes information about setting user passwords, adding new users to an NIS domain, and assigning users to netgroups.

How to Add a New NIS User to an NIS Domain

1. Become superuser on the master NIS server.

2. Create the new user's login ID with the useradd command.

   # useradd userID

   userID is the login ID of the new user. This command creates entries in the /etc/passwd and /etc/shadow files on the master NIS server.

3. Create the new user's initial password.

   To create an initial password that the new user can use to log in, run the passwd command.

   # passwd userID

   Where userID is the login ID of the new user. You will be prompted for the password to assign to this user.

   This step is necessary because the password entry created by the useradd command is locked, which means that the new user cannot log in. By specifying an initial password, you unlock the entry.

4. If necessary, copy the new entry into the server's passwd map input files.

   The map source files on your master server should be in a directory other than /etc. Copy and paste the new lines from the /etc/passwd and /etc/shadow files into the passwd map input files on the server. See Password Files and Namespace Security for additional information.

   For example, if you added the new user brown, the line from /etc/passwd that you would copy to your passwd input file would look like the following.

   brown:x:123:10:User brown:/home/brown:/bin/csh:

   The line for brown that you would copy from /etc/shadow would look like:

   brown:W12345GkHic:6445::::::

5. Make sure that the Makefile correctly specifies the directory where the password input file resides.

6. If appropriate, delete the new user's entries from /etc/passwd and /etc/shadow input files.

   For security reasons, do not keep user entries in the NIS master server /etc/passwd and /etc/shadow files. After copying the entries for the new user to the NIS map source files that are stored in some other directory, use the userdel command on the master server to delete the new user.

   For example, to delete the new user brown from the master server's /etc files, you would enter the following.

   # userdel brown

   For more information about userdel, see the userdel man page.

7. Update the NIS passwd maps.

   After you have updated the passwd input file on the master server, update the passwd maps by running make in the directory containing the source file.

   #userdel brown # cd /var/yp # /usr/ccs/bin/make passwd

8. Tell the new user the initial password you have assigned to his or her login ID.

   After logging in, the new user can run passwd at any time to establish a different password.

Setting User Passwords

Users run passwd to change their passwords.

% passwd username

Before users can change their passwords, you must start the rpc.yppasswdd daemon on the master server to update the password file. The commands for starting the daemon are already present in the /usr/lib/netsvc/yp/ypstart file.

The rpc.yppasswdd daemon is started automatically by ypstart on the master server. Notice that when the -m option is given to rpc.yppasswdd, a make is forced in /var/yp immediately following a modification of the file. If you want to avoid having this make take place each time the passwd file is changed, remove the -m option from the rpc.yppasswd command in the ypstart script and control the pushing of the passwd maps through the crontab file.

No arguments should follow the rpc.yppasswd -m command. Although you can edit the ypstart script file to achieve a different action, it is not recommended that you modify this file other than optionally removing the -m option. All commands and daemons invoked by this file with the proper set of command line parameters. If you choose to edit this file, be especially careful when editing the rpc.yppasswdd command. If you add an explicit call to the passwd.adjunct file, the exact $PWDIR/security/passwd.adjunct path must be used; otherwise, incorrect processing results.

NIS Netgroups

NIS netgroups are groups (sets) of users or machines that you define for your administrative purposes. For example, you can create netgroups that do the following

• Define a set of users who can access a specific machine

• Define a set of NFS client machines to be given some specific file system access

• Define a set of users who are to have administrator privileges on all the machines in a particular NIS domain

Each netgroup is given a netgroup name. Netgroups do not directly set permissions or access rights. Instead, the netgroup names are used by other NIS maps in places where a user name or machine name would normally be used. For example, suppose you created a netgroup of network administrators called netadmins. To grant all members of the netadmins group access to a given machine, you need only add a netadmin entry to that machine's /etc/passwd file. Netgroup names can also be added to the /etc/netgroup file and propagated to the NIS netgroup map. See netgroup(4) for more detailed information on using netgroups.

On a network using NIS, the netgroup input file on the master NIS server is used for generating three maps: netgroup, netgroup.byuser, and netgroup.byhost. The netgroup map contains the basic information in the netgroup input file. The two other NIS maps contain information in a format that speeds lookups of netgroup information, given the machine or user.

Entries in the netgroup input file are in the format: name ID, where name is the name you give to a netgroup, and ID identifies a machine or user who belongs to the netgroup. You can specify as many IDs (members) to a netgroup as you want, separated by commas. For example, to create a netgroup with three members, the netgroup input file entry would be in the format: name ID, ID, ID. The member IDs in a netgroup input file entry are in the following format.

([-|machine], [-|user], [domain])

Where machine is a machine name, user is a user ID, and domain is the machine or user's NIS domain. The domain element is optional and should only be used to identify machines or users in some other NIS domain. The machine and user element of each member's entry are required, but a dash (-) is used to denote a null. There is no necessary relationship between the machine and user elements in an entry.

The following are two sample netgroup input file entries, each of which create a netgroup named admins composed of the users hauri and juanita who is in the remote domain sales and the machines altair and sirius.

admins (altair, hauri), (sirius,juanita,sales)

admins (altair,-), (sirius,-), (-,hauri), (-,juanita,sales)

Various programs use the netgroup NIS maps for permission checking during login, remote mount, remote login, and remote shell creation. These programs include mountd, login, rlogin, and rsh. The login command consults the netgroup maps for user classifications if it encounters netgroup names in the passwd database. The mountd daemon consults the netgroup maps for machine classifications if it encounters netgroup names in the /etc/dfs/dfstab file. rlogin and rsh In fact, any program that uses the ruserok interface consults the netgroup maps for both machine and user classifications if they encounter netgroup names in the /etc/hosts.equiv or .rhosts files.

If you add a new NIS user or machine to your network, be sure to add them to appropriate netgroups in the netgroup input file. Then use the make and yppush commands to create the netgroup maps and push them to all of your NIS servers. See netgroup(4) for detailed information on using netgroups and netgroup input file syntax.

Working With NIS Maps

This section contains the following information:

• Obtaining Map Information

• Changing a Map's Master Server

• Modifying Configuration Files

• Modifying and Using the Makefile

Obtaining Map Information

Users can obtain information from and about the maps at any time by using the ypcat, ypwhich, and ypmatch commands. In the examples that follow, mapname refers both to the official name of a map and to its nickname, if any.

To list all the values in a map, type the following.

% ypcat mapname

To list both the keys and the values (if any) in a map, type the following.

% ypcat -k mapname

To list all the map nicknames, type any of the following commands.

%ypcat —x
% ypmatch —x
% ypwhich —x

To list all the available maps and their master(s), type the following.

% ypwhich —m

To list the master server for a particular map, type the following.

% ypwhich -m mapname

To match a key with an entry in a map, type the following.

% ypmatch key mapname

If the item you are looking for is not a key in a map, type the following.

% ypcat mapname | grep item

where item is the information for which you are searching. To obtain information about other domains, use the -d domainname options of these commands.

If the machine requesting information for a domain other than its default does not have a binding for the requested domain, ypbindconsults the /var/yp/binding/domainname/ypservers file for a list of servers for that domain. If this file does not exist it issues an RPC broadcast for a server. In this case, there must be a server for the requested domain on the same subnet as the requesting machine.

Changing a Map's Master Server

To change the master server for a selected map, you first have to build the map on the new NIS master. Since the old master server name occurs as a key-value pair in the existing map (this pair is inserted automatically by makedbm), copying the map to the new master or transferring a copy to the new master with ypxfr is insufficient. You have to reassociate the key with the new master server name. If the map has an ASCII source file, you should copy this file to the new master.

How to Change a Map's Master Server

1. Become superuser.

2. Log in to the new master as superuser and type the following.

   newmaster# cd /var/yp

3. The Makefile must have an entry for the new map before you specify the map to make. If this is not the case, edit the Makefile now, using a map called sites.byname.

4. To update or remake the map, type the following.

   newmaster# make sites.byname

5. If the old master remains an NIS server, remote log in (rlogin) to the old master and edit Makefile. Make sure you comment out the section of the Makefile that made sites.byname so that it is no longer made there.

6. If sites.byname only exists as an ndbm file, remake it on the new master by disassembling a copy from any NIS server, then running the disassembled version through makedbm.

   newmaster# cd /var/yp newmaster# ypcat sites.byname | makedbm -domain/sites.byname

   After making the map on the new master, you must send a copy of the new map to the other slave servers. Do not use yppush, because the other slaves will try to get new copies from the old master, rather than the new one. A typical method for circumventing this is to transfer a copy of the map from the new master back to the old master. To do this, become superuser on the old master server and type the following.

   oldmaster# /usr/lib/netsvc/yp/ypxfr -h newmaster sites.byname

   Now it is safe to run yppush. Any remaining slave servers still believe that the old master is the current master and will attempt to get the current version of the map from the old master. When clients do so, they will get the new map, which names the new master as the current master.

   If this method fails, you can log in as root on each NIS server and execute the ypxfr command shown above.

Modifying Configuration Files

NIS intelligently parses the setup files. Although this makes NIS administration easier, it does make the behavior of NIS more sensitive to changes in the setup and configuration files.

Use the procedures in this section when modifying any of the following.

• /var/yp/Makefile to add or delete supported maps

• Adding or deleting /etc/resolv.conf to allow or deny DNS forwarding

• Adding or deleting $PWDIR/security/passwd.adjunct to allow or deny C2 security ($PWDIR is defined in /var/yp/Makefile)

How to Modify Configuration Files.

1. Become superuser.

2. Stop the NIS server.

   # /etc/init.d/ypstop

3. Make the necessary changes to your files.

4. Restart the NIS server.

   # /etc/init.d/yp start

You do not have to stop and start NIS when changing NIS maps or the map source files.

Keep in mind the following.

• Deleting a map or source file from an NIS master server does not automatically result in corresponding deletions from slave servers. You must delete maps and source files from slave servers by hand.

• New maps do not automatically get pushed to existing slave servers. You must run ypxfr from the slaves.

Modifying and Using the Makefile

You can modify the Makefile provided by default in /var/yp to suit your needs. You can add or delete maps, and you can change the names of some of the directories.

Keep an unmodified copy of the original Makefile for future reference.

Working With the Makefile

To add a new NIS map, you must get copies of the ndbm files for the map into the /var/yp/domainname directory on each of the NIS servers in the domain. This is normally done for you by the Makefile. After deciding which NIS server is the master of the map, modify the Makefile on the master server so that you can conveniently rebuild the map. Different servers can be masters of different maps, but in most cases this leads to administrative confusion. Try to set only one server as the master of all maps.

Typically a human-readable text file is filtered through awk, sed, or grep to make it suitable for input to makedbm. Refer to the default Makefile for examples. See the make(1S) for general information about the make command.

Use the mechanisms already in place in the Makefile when deciding how to create dependencies that make will recognize. Be aware that make is very sensitive to the presence or absence of tabs at the beginning of lines within the dependency rules. A missing tab can invalidate an entry that is otherwise well formed.

Adding an entry to the Makefile involves the following.

• Adding the name of the database to the all rule

• Writing the time rule

• Adding the rule for the database

For example, in order for the Makefile to work on automounter input files, you would have to add the auto_direct.time and auto_home.time maps to the NIS database.

To add these maps to the NIS database you need to modify the Makefile.

Changing Makefile Macros/Variables

You can change the settings of the variables defined at the top of the Makefile by changing the value to the right of the equal sign (=). For instance, if you do not want to use the files located in /etc as input for the maps, but you would rather use files located in another directory, such as /var/etc/domainname, you should change DIR from DIR=/etc to DIR=/var/etc/domainname. You should also change PWDIR from PWDIR=/etc to PWDIR=/var/etc/domainname.

The variables are the following.

• DIR= The directory containing all of the NIS input files except passwd and shadow. The default value is /etc. Since it is not good practice to use the files in the master server's /etc directory as NIS input files, you should change this value.

• PWDIR= The directory containing the passwd and shadow NIS input files. Since it is not good practice to use the files in the master server's /etc directory as NIS input files, you should change this value.

• DOM= The NIS domain name. The default value of DOM is set using the domainname command. However, most NIS commands use the current machine's domain which is set in the machine's /etc/defaultdomain file.

Modifying Makefile Entries

The following procedure describes how to add and delete databases from the Makefile.

How to Modify the Makefile

1. Log in as a superuser.

2. Modify the line that starts with the word all by adding the name(s) of the database you want to add:

   all: passwd group hosts ethers networks rpc services protocols \ netgroup bootparams aliases netid netmasks \ auto_direct auto_home auto_direct.time auto_home.time

   The order of the entries is not relevant, but the blank space at the beginning of the continuation lines must be a Tab, not spaces.

3. Add the following lines at the end of the Makefile:

   auto_direct: auto_direct.time auto_home: auto_home.time

4. Add an entry for auto_direct.time in the middle of the file.

   auto_direct.time: $(DIR)/auto_direct @(while read L; do echo $$L; done < $(DIR)/auto_direct $(CHKPIPE)) | \ (sed -e "/^#/d" -e "s/#.*$$//" -e "/^ *$$/d" $(CHKPIPE)) | \ $(MAKEDBM) - $(YPDBDIR)/$(DOM)/auto_direct; @touch auto_direct.time; @echo "updated auto_direct"; @if [ ! $(NOPUSH) ]; then $(YPPUSH) auto_direct; fi @if [ ! $(NOPUSH) ]; then echo "pushed auto_direct"; fi

   where

   • CHKPIPE makes certain that the operations to the left of the pipe (|) are successfully completed before piping the results to next commands. If the operations to the left of the pipe do not successfully complete, the process is terminated with a NIS make terminated message.

   • NOPUSH prevents the makefile from calling yppush to transfer the new map to the slave servers. If NOPUSH is not set, the push is done automatically.

   The while loop at the beginning is designed to eliminate any backslash-extended lines in the input file. The sed script eliminates comment and empty lines.

   The same procedure should be followed for all other automounter maps, such as auto_home, or any other nondefault maps.

5. Run make.

   # make mapname

   Where mapname is the name of the map you want to make.

If you do not want the Makefile to produce maps for a specific database, edit the Makefile as follows.

1. Delete the name of the database from the all rule.

2. Delete or comment out the database rule for the database you want to delete.

   For example, to delete the hosts database, the hosts.time entry should be removed.

3. Remove the time rule.

   For example, to delete the hosts database, the hosts: hosts.time entry should be removed.

4. Remove the map from the master and slave servers.

Updating and Modifying Existing Maps

After you have installed NIS, you might discover that some maps require frequent updating while others never need to change. For example, the passwd.byname map can change frequently on a large company's network, while the auto_master map changes little, if at all.

As mentioned in Default NIS Maps, the default location of the default NIS maps is on the master server in /var/yp/domainname, where domainname is the name of the NIS domain. When you need to update a map, you can use one of two updating procedures, depending on whether or not it is a default map.

• A default map is a map in the default set created by ypinit from the network databases.

• Nondefault maps can be any of the following.

  • Maps included with an application purchased from a vendor

  • Maps created specifically for your site

  • Maps created from a nontext file

The following sections explain how to use various updating tools. In practice, you might decide to only use them if you add nondefault maps or change the set of NIS servers after the system is already up and running.

How to Update Maps Supplied With the Default Set

Use the following procedure for updating maps supplied with the default set.

1. Become a superuser on the master server.

   Always modify NIS maps only on the master server.

2. Edit the source file for the map you want to change, whether that file resides in /etc or in some other directory of your choice.

3. Type the following.

   # cd /var/yp # make mapname

   The make command then updates your map according to the changes you made in its corresponding file. It also propagates the changes among the other servers.

Propagating an NIS Map

After a map is changed, the Makefile uses yppush to propagate a new map to the slave servers (unless NOPUSH is set in the Makefile). It does this by informing the ypserv daemon and sending a map transfer request. The ypserv daemon on the slave then starts a ypxfr process, which in turn contacts the ypxfrd daemon on the master server. Some basic checks are made (for example did the map really change?) and then the map is transferred. ypxfr on the slave then sends a response to the yppush process indicating whether the transfer succeeded.

The above procedure will not work for newly created maps that do not yet exist on the slave servers. New maps must be sent to the slave servers by running ypxfr on the slaves.

Occasionally, maps fail to propagate and you must to use ypxfr manually to send new map information. You can choose to use ypxfr in two different ways: periodically through the root crontab file, or interactively on the command line. These approaches are discussed in the following sections.

Using cron for Map Transfers

Maps have different rates of change. For instance, some might not change for months at a time, such as protocols.byname among the default maps and auto_master among the nondefault maps; but passwd.byname can change several times a day. Scheduling map transfer using the crontab command allows you to set specific propagation times for individual maps.

To periodically run ypxfr at a rate appropriate for the map, the root crontab file on each slave server should contain the appropriate ypxfr entries. ypxfr contacts the master server and transfers the map only if the copy on the master server is more recent than the local copy.

If your master server runs rpc.yppasswdd with the default -m option, then each time someone changes their yp password, the passwd daemon runs make, which rebuilds the passwd maps.

Using Shell Scripts With cron and ypxfr

As an alternative to creating separate crontab entries for each map, you might prefer to have the root crontab command run a shell script that periodically updates all maps. Sample map-updating shell scripts are n the /usr/lib/netsvc/yp directory. The script names are ypxfr_1perday, ypxfr_1perhour, and ypxfr_2perday. You can modify or replace these shell scripts to fit your site requirements. Example 9–1 shows the default ypxfr_1perday shell script.

Example 9–1 ypxfr_1perday Shell Script

#! /bin/sh
#
# ypxfr_1perday.sh - Do daily yp map check/updates
PATH=/bin:/usr/bin:/usr/lib/netsvc/yp:$PATH
export PATH
# set -xv
ypxfr group.byname
ypxfr group.bygid
ypxfr protocols.byname
ypxfr protocols.bynumber
ypxfr networks.byname
ypxfr networks.byaddr
ypxfr services.byname
ypxfr ypservers

This shell script updates the maps once per day, if the root crontab is executed daily. You can also have scripts that update maps once a week, once a month, once every hour, and so forth, but be aware of the performance degradation implied in frequently propagating the maps.

Run the same shell scripts as root on each slave server configured for the NIS domain. Alter the exact time of execution from one server to another to avoid bogging down the master.

If you want to transfer the map from a particular slave server, use the -h machine option of ypxfr within the shell script. Here is the syntax of the commands you put in the script.

# /usr/lib/netsvc/yp/ypxfr -h machine [ -c ] mapname

Where machine is the name of the server with the maps you want to transfer, and mapname is the name of the requested map. If you use the -h option without specifying a machine, ypxfr tries to get the map from the master server. If ypserv is not running locally at the time ypxfr is executed, you must use the -c flag so that ypxfr does not send a clear current map request to the local ypserver.

You can use the -s domain option to transfer maps from another domain to your local domain. These maps should be the same across domains. For example, two domains might share the same services.byname and services.byaddr maps. Alternatively, you can use rcp, or rdist for more control, to transfer files across domains.

Directly Invoking ypxfr

The second method of invoking ypxfr is to run it as a command. Typically, you do this only in exceptional situations—for example, when setting up a temporary NIS server to create a test environment or when trying to quickly get an NIS server that has been out of service consistent with the other servers.

Logging ypxfr Activity

The transfer attempts and results of ypxfr can be captured in a log file. If a file called /var/yp/ypxfr.log exists, results are appended to it. No attempt to limit the size of the log file is made. To prevent it from growing indefinitely, empty it from time to time by typing the following.

# cd /var/yp
# cp ypxfr.log ypxfr.log.old
# cat /dev/null > /var/yp/ypxfr.log

You can have crontab execute these commands once a week. To turn off logging, remove the log file.

Modifying Default Maps

To update a nondefault map, you must do the following.

1. Create or edit its corresponding text file.

2. Build (or rebuild) the new or updated map. There are two ways to build a map.

   • Use the Makefile. Using the Makefile is the preferred method of building a non-default map. If the map has an entry in the Makefile, run make name where name is the name of map you want to build. If the map does not have a Makefile entry, try to create one following the instructions in Modifying and Using the Makefile.

   • Use the /usr/sbin/makedbm program. makedbm(1M) fully describes this command.

Using makedbm to Modify a Non-Default Map

There are two different methods for using makedbm to modify maps if you do not have an input file:

• Redirect the makedbm -u output to a temporary file, modify the file, then use the modified file as input to makedbm.

• Have the output of makedbm -u operated on within a pipeline that feeds into makedbm. This is appropriate if you can update the disassembled map with either awk, sed, or a cat append.

Creating New Maps from Text Files

Assume that a text file /var/yp/mymap.asc was created with an editor or a shell script on the master. You want to create an NIS map from this file and locate it in the homedomain subdirectory. To do this, type the following on the master server.

# cd /var/yp 
# makedbm mymap.asc homedomain/mymap

The mymap map now exists on the master server in the directory homedomain. To distribute the new map to slave servers run ypxfr.

Adding Entries to a File-Based Map

Adding entries to mymap is simple. First, you must modify the text file /var/yp/mymap.asc. If you modify the actual dbm files without modifying the corresponding text file, the modifications are lost. Then run makedbm as shown above.

Creating Maps From Standard Input

When no original text file exists, create the NIS map from the keyboard by typing input to makedbm, as shown below (end with Control-D).

ypmaster# cd /var/yp
ypmaster# makedbm - homedomain/mymapkey1 value1 key2 value2 key3 value3

Modifying Maps Made From Standard Input

If you later need to modify the map, you can use makedbm to disassemble the map and create a temporary text intermediate file. To disassemble the map and create a temporary file, type the following.

% cd /var/yp 
% makedbm -u homedomain/mymap > mymap.temp

The resulting temporary file mymap.temp has one entry per line. You can edit this file as needed, using any text editor.

To update the map, give the name of the modified temporary file to makedbm by typing the following.

% makedbm mymap.temp homedomain/mymap
% rm mymap.temp

Then propagate the map to the slave servers, by becoming root and typing the following.

# yppush mymap

The preceding paragraphs explained how to use makedbm to create maps; however, almost everything you actually have to do can be done by ypinit and Makefile unless you add nondefault maps to the database or change the set of NIS servers after the system is already up and running.

Whether you use the Makefile in /var/yp or some other procedure the goal is the same. Anew pair of well-formed dbm files must end up in the maps directory on the master server.

Adding a Slave Server

After NIS is running, you might need to create an NIS slave server that you did not include in the initial list given to ypinit.

To add a NIS slave server:

How to Add a Slave Server

1. Log in to the master server as a superuser.

2. Change to the NIS domain directory.

   # cd /var/yp/domainname

3. Disassemble the ypservers file.

   # makedbm -u ypservers >/tmp/temp_file

   The makedbm command converts ypservers from ndbm format to a temporary ASCII file /tmp/temp_file.

4. Edit the /tmp/temp_file file using a text editor. Add the name of the new slave server to the list of servers. Then save and close the file.

5. Run the makedbm command with temp_file as the input file and ypservers as the output file.

   # makedbm /tmp/temp_file ypservers

   makedbm then converts ypservers back into ndbm format.

6. Verify that the ypservers map is correct (since there is no ASCII file for ypservers) by typing the following on the slave.

   slave3# makedbm -u ypservers

   The makedbm command displays each entry in ypservers on your screen.

   ---

   Note –

   If a machine name is not in ypservers, it will not receive updates to the map files because yppush consults this map for the list of slave servers.

   ---

7. Become superuser on the new NIS slave.

8. Set up the new slave server's NIS domain directory by copying the NIS map set from the master server.

   When running the ypinit command, follow the prompts and list the NIS servers in order of preference.

   slave3# cd /var/yp slave3# ypinit -c slave3# /usr/lib/netsvc/yp/ypbind

9. Initialize this machine as a slave.

   slave3# /usr/sbin/ypinit -s ypmaster

   where ypmaster is the machine name of the existing NIS master server.

10. Run ypstop to stop the machine running as an NIS client.

    # /usr/lib/netsvc/yp/ypstop

11. Run ypstart to start NIS slave service.

    # /usr/lib/netsvc/yp/ypstart

Using NIS With C2 Security

If the $PWDIR/security/passwd.adjunct file is present, C2 security is started automatically. ($PWDIR is defined in /var/yp/Makefile.) The C2 security mode uses the passwd.adjunct file to create the passwd.adjunct NIS map. In this implementation, NIS allows you to use both the passwd.adjunct file and shadow file to manage security. The passwd.adjunct file is processed only when you type the following.

# make passwd.adjunct

The make passwd command processes the passwd map only, not the passwd.adjunct map when you run make manually in the C2 security mode.

Changing a Machine's NIS Domain

To change the NIS domain name of a machine, do the following.

How to Change a Machine's NIS Domain Name

1. Become superuser.

2. Edit the machine's /etc/defaultdomain file, exchanging its present contents with the new domain name for the machine.

   For example, if the current domain name is sales.doc.com, you might change it to research.doc.com.

3. Run domainname `cat /etc/defaultdomain'

4. Set the machine up as an NIS client, slave, or master server.

   See for Chapter 8, Setting Up and Configuring NIS Service for details.

Using NIS in Conjunction With DNS

Typically, NIS clients are configured with the nsswitch.conf file to use only NIS for machine name and address lookups. If this type of lookup fails, an NIS server can forward these lookups to DNS.

How to Configure Machine Name and Address Lookup Through NIS and DNS

1. Log into the machine and become a superuser.

2. The two map files, hosts.byname and hosts.byaddr must include the YP_INTERDOMAIN key. To test this key, edit the Makefile and modify the following lines.

   #B=-b B=

   to

   B=-b #B=

   makedbm will now start with the -b flag when it makes the maps, and the YP_INTERDOMAIN key will be inserted into the ndbm files.

3. Run make to rebuild maps.

   # /usr/ccs/bin/make hosts

4. Check that all the NIS server's /etc/resolv.conf files point to valid nameservers.

   ---

   Note –

   If you have NIS servers that are not running Solaris, Release 2, make sure YP_INTERDOMAIN exists in the hosts maps.

   ---

5. To enable DNS forwarding, stop each server.

   # /usr/lib/netsvc/yp/ypstop

6. Restart each server.

   # /usr/lib/netsvc/yp/ypstart

   In this implementation of NIS, ypstart will automatically start the ypserv daemon with the -d option to forward requests to DNS.

Dealing with Mixed NIS Domains

If the master and slave servers are not both running Solaris 2, refer to the following table for how to avoid potential problems. The notation “4.0.3+” refers to that and later releases of SunOS. makedbm -b is a reference to the “B” variable in the Makefile.

Turning Off NIS Services

If ypserv on the master is disabled, you can no longer update any of the NIS maps. If you choose to turn off NIS on a network currently running it, you can disable NIS after the next reboot by renaming the ypbind file to ypbind.orig, as follows.

% mv /usr/lib/netsvc/yp/ypbind /usr/lib/netsvc/yp/ypbind.orig

To disable NIS after the next reboot on a particular NIS slave or master, type the following on the server in question.

% mv /usr/lib/netsvc/yp/ypserv /usr/lib/netsvc/yp/ypserv.orig

To stop NIS immediately, type the following.

% /usr/lib/netsvc/yp/ypstop

The NIS service is automatically restarted after the next reboot unless the ypbind and ypserv files are renamed as described above.

Chapter 10 NIS Troubleshooting

This chapter explains how to resolve problems encountered on networks running NIS. It covers problems seen on an NIS client and those seen on an NIS server.

Before trying to debug an NIS server or client, review Chapter 7, Network Information Service (NIS) (Overview) which explains the NIS environment. Then look for the subheading in this section that best describes your problem.

NIS Binding Problems

Symptoms

Common symptoms of NIS binding problems include the following.

• Messages saying that ypbind can't find or communicate with a server

• Messages saying that server not responding

• Messages saying that NIS is unavailable

• Commands on a client limp along in background mode or function much slower than normal

• Commands on a client hang. Sometimes commands hang even though the system as a whole seems fine and you can run new commands

• Commands on a client crash with obscure messages, or no message at all

NIS Problems Affecting One Client

If only one or two clients are experiencing symptoms that indicate NIS binding difficulty, the problems probably are on those clients. If many NIS clients are failing to bind properly, the problem probably exists on one or more of the NIS servers. See NIS Problems Affecting Many Clients.

ypbind Not Running on Client

One client has problems, but other clients on the same subnet are operating normally. On the problem client, run ls -l on a directory, such as /usr, that contains files owned by many users, including some not in the client /etc/passwd file. If the resulting display lists file owners who are not in the local /etc/passwd as numbers, rather than names, this indicates that NIS service is not working on the client.

These symptoms usually mean that the client ypbind process is not running. Run ps -e and check for ypbind. If you do not find it, log in as superuser and start ypbind by typing:

client# /usr/lib/netsvc/yp/ypstart

Missing or Incorrect Domain Name

One client has problems, the other clients are operating normally, but ypbind is running on the problem client. The client might have an incorrectly set domain.

On the client, run the domainname command to see which domain name is set.

client7# domainname neverland.com

Compare the output with the actual domain name in /var/yp on the NIS master server. The actual NIS domain is shown as a subdirectory in the /var/yp directory.

Client7# ls /var/yp...
-rwxr-xr-x 1 root Makefile
drwxr-xr-x 2 root binding
drwx------ 2 root doc.com ...

If the domain name returned by running domainname on a machine is not the same as the server domain name listed as a directory in /var/yp, the domain name specified in the machine's /etc/defaultdomain file is incorrect. Log in as superuser and correct the client's domain name in the machine's /etc/defaultdomain file. This assures that the domain name is correct every time the machine boots. Now reboot the machine.

The domain name is case-sensitive.

Client Not Bound to Server

If your domain name is set correctly, ypbind is running, and commands still hang, then make sure that the client is bound to a server by running the ypwhich command. If you have just started ypbind, then run ypwhich several times (typically, the first one reports that the domain is not bound and the second succeeds normally).

No Server Available

If your domain name is set correctly, ypbind is running, and you get messages indicating that the client cannot communicate with a server, this might indicate a number of different problems:

• Does the client have a /var/yp/binding/domainname/ypservers file containing a list of servers to bind to? If not, run ypinit -c and specify in order of preference the servers that this client should bind to.

• If the client does have a /var/yp/binding/domainname/ypservers file, are there enough servers listed in it if one or two become unavailable? If not, add additional servers to the list by running yppinit -c.

• If none of the servers listed in the client's ypservers file are available, the client searches for an operating server using broadcast mode. If there is a functioning server on the client's subnet, the client will find it (though performance might be slowed during the search). If there are no functioning servers on the client's subnet can solve the problem in several ways:

  • If the client has no server on the subnet and no route to one, you can install a new slave server on that subnet.

  • You can make sure your routers are configured to pass broadcast packets so that the client can use broadcast to find a server on another subnet. You can use the netstat -r command to verify the route.

  • If there should be a route, but it is not working, make sure that the route daemon in.routed/in.rdisc is running. If it is not running, start it.

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.

• Do the servers listed in a clients ypservers file have entries in the /etc/hosts file? If not, add the servers to the NIS maps hosts input file and rebuild your maps by running yppinit -c or ypinit -s as described Working With NIS Maps.

• Is the /etc/nsswitch.conf file set up to consult the machine's local hosts file in addition to NIS? See Chapter 2, The Name Service Switch (Overview) for more information on the switch.

• Is the /etc/nsswitch.conf file set up to consult files first for services and rpc? See Chapter 2, The Name Service Switch (Overview) for more information on the switch.

ypwhich Displays Are Inconsistent

When you use ypwhich several times on the same client, the resulting display varies because the NIS server changes. This is normal. The binding of the NIS client to the NIS server changes over time when the network or the NIS servers are busy. Whenever possible, the network becomes stable at a point where all clients get acceptable response time from the NIS servers. As long as your client machine gets NIS service, it does not matter where the service comes from. For example, an NIS server machine can get its own NIS services from another NIS server on the network.

When Server Binding is Not Possible

In extreme cases where local server binding is not possible, use of the ypset command can temporarily allow binding to another server, if available, on another network or subnet. However, in order to use the -ypset option, ypbind must be started with either the -ypset or -ypsetme options.

For security reasons, the use of the -ypset and -ypsetme options should be limited to debugging purposes under controlled circumstances. Use of the -ypset and -ypsetme options can result in serious security breaches because while the daemons are running, anyone can alter server bindings causing trouble for others and permitting unauthorized access to sensitive data. If you must start ypbind with these options, once you have fixed the problem you should kill ypbind and restart it again without those options.

ypbind Crashes

If ypbind crashes almost immediately each time it is started, look for a problem in some other part of the system. Check for the presence of the rpcbind daemon by typing the following.

% ps -ef | grep rpcbind

If rpcbind is not present or does not stay up or behaves strangely, consult your RPC documentation.

You might be able to communicate with rpcbind on the problematic client from a machine operating normally. From the functioning machine, type the following.

% rpcinfo client

If rpcbind on the problematic machine is fine, rpcinfo produces the following output.

program	version	netid	address	service	owner
...
100007	2	udp	0.0.0.0.2.219	ypbind	superuser
100007	1	udp	0.0.0.0.2.219	ypbind	superuser
100007	1	tcp	0.0.0.0.2.220	ypbind	superuser
100007	2	tcp	0.0.0.0.128.4	ypbind	superuser
100007	2	ticotsord	\000\000\020H	ypbind	superuser
100007	2	ticots	\000\000\020K	ypbind	superuser
...

Your machine will have different addresses. If the addresses are not displayed, ypbind has been unable to register its services. Reboot the machine and run rpcinfo again. If the ypbind processes are there and they change each time you try to restart /usr/lib/netsvc/yp/ypbind, reboot the system, even if the rpcbind daemon is running.

NIS Problems Affecting Many Clients

If only one or two clients are experiencing symptoms that indicate NIS binding difficulty, the problems probably are on those clients. See NIS Problems Affecting One Client. If many NIS clients are failing to bind properly, the problem probably exists on one or more of the NIS servers.

rpc.yppasswdd Considers a Non-Restricted Shell That Begins With r to be Restricted

1. Create /etc/default/yppasswdd that contains a special string: "check_restricted_shell_name=1".

2. If the "check_restricted_shell_name=1" string is commented out, the 'r' check will no occur.

Network or Servers Are Overloaded

NIS can hang if the network or NIS servers are so overloaded that ypserv cannot get a response back to the client ypbind process within the time-out period.

Under these circumstances, every client on the network experiences the same or similar problems. In most cases, the condition is temporary. The messages usually go away when the NIS server reboots and restarts ypserv, or when the load on the NIS servers or network itself decreases.

Server Malfunction

Make sure the servers are up and running. If you are not physically near the servers, use the ping command.

NIS Daemons Not Running

If the servers are up and running, try to find a client machine behaving normally, and run the ypwhich command. If ypwhich does not respond, kill it. Then log in as root on the NIS server and check if the NIS ypbind process is running by entering the following.

# ps -e | grep yp

Do not use the -f option with ps because this option attempts to translate user IDs to names which causes more naming service lookups that might not succeed.

If either the ypbind or ypserv daemons are not running, kill them and then restart them by entering the following.

# /usr/lib/netsvc/yp/ypstop
# /usr/lib/netsvc/yp/ypstart

If both the ypserv and ypbind processes are running on the NIS server, use ypwhich.

If ypwhich does not respond, ypserv has probably hung and should be restarted. While logged in as root on the server, kill ypserv and restart it by typing the following.

# /usr/lib/netsvc/yp/ypstop
# /usr/lib/netsvc/yp/ypstart

Servers Have Different Versions of an NIS Map

Because NIS propagates maps among servers, occasionally you might find different versions of the same map on various NIS servers on the network. This version discrepancy is normal add acceptable if the differences do not last for more than a short time.

The most common cause of map discrepancy is that something is preventing normal map propagation. For example, an NIS server or router between NIS servers is down. When all NIS servers and the routers between them are running, ypxfr should succeed.

If the servers and routers are functioning properly, check the following:

• Log ypxfr output (see Logging ypxfr Output).

• Check the control files (see Check the crontab File and ypxfr Shell Script).

• Check the ypservers map on the master. See Check the ypservers Map.

Logging ypxfr Output

If a particular slave server has problems updating maps, log in to that server and run ypxfr interactively. If ypxfr fails, it tells you why it failed, and you can fix the problem. If ypxfr succeeds, but you suspect it has occasionally failed, create a log file to enable logging of messages. To create a log file, enter the following on the slave.

ypslave# cd /var/yp 
ypslave# touch ypxfr.log

This creates a ypxfr.log file that saves all output from ypxfr.

The output resembles the output ypxfr displays when run interactively, but each line in the log file is time stamped. (You might see unusual ordering in the time-stamps. That is okay—the time-stamp tells you when ypxfr started to run. If copies of ypxfr ran simultaneously but their work took differing amounts of time, they might actually write their summary status line to the log files in an order different from that which they were invoked.) Any pattern of intermittent failure shows up in the log.

When you have fixed the problem, turn off logging by removing the log file. If you forget to remove it, it continues to grow without limit.

Check the crontab File and ypxfr Shell Script

Inspect the root crontab file, and check the ypxfr shell script it invokes. Typographical errors in these files can cause propagation problems. Failures to refer to a shell script within the /var/spool/cron/crontabs/root file, or failures to refer to a map within any shell script can also cause errors.

Check the ypservers Map

Also, make sure that the NIS slave server is listed in the ypservers map on the master server for the domain. If it is not, the slave server still operates perfectly as a server, but yppush does not propagate map changes to the slave server.

Work Around

If the NIS slave server problem is not obvious, you can work around it while you debug using rcp or ftp to copy a recent version of the inconsistent map from any healthy NIS server. The following shows how to transfer the problem map.

ypslave# rcp ypmaster:/var/yp/mydomain/map.\* /var/yp/mydomain

The * character has been escaped in the command line, so that it will be expanded on ypmaster, instead of locally on ypslave.

ypserv Crashes

When the ypserv process crashes almost immediately, and does not stay up even with repeated activations, the debug process is virtually identical to that described in ypbind Crashes. Check for the existence of the rpcbind daemon as follows.

ypserver% ps -e | grep rpcbind

Reboot the server if you do not find the daemon. Otherwise, if the daemon is running, type the following and look for similar output.

% rpcinfo -p ypserver

% program 	vers 	proto 	port 	service
100000	4	tcp	111	portmapper
100000	3	tcp	111	portmapper
100068	2	udp	32813	cmsd
...
100007	1	tcp	34900	ypbind
100004	2	udp	731	ypserv
100004	1	udp	731	ypserv
100004	1	tcp	732	ypserv
100004	2	tcp	32772	ypserv

Your machine might have different port numbers. The four entries representing the ypserv process are the following.

100004 	2 	udp 	731 	ypserv
100004 	1 	udp 	731 	ypserv
100004 	1 	tcp 	732 	ypserv
100004 	2 	tcp 	32772 	ypserv

If there are no entries, and ypserv is unable to register its services with rpcbind, reboot the machine. If there are entries, de-register the service from rpcbind before restarting ypserv. To de-register the service from rpcbind, on the server type the following.

# rpcinfo -d number 1 
# rpcinfo -d number 2

where number is the ID number reported by rpcinfo (100004, in the example above).