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.

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