Select the Domains That Will Be NIS Compatible

Make a list of your NIS clients and group them in their eventual NIS+ domains. If the NIS+ domain running in NIS-compatibility mode does not have the same name as its NIS clients' original NIS domain, you must change the NIS clients' domain name to the NIS+ domain's name that is being supported by the NIS-compatible NIS+ server.

In NIS-compatibility mode, NIS client users can no longer use the yppasswd command to change their own passwords. Instead, system administrators with authorization or members of the NIS+ admin group have to run the nispasswd command for them.

Changing passwords raises the subject of synchronization of information between the NIS+ and NIS domains. You must devise a way to keep the NIS+ domains in synchronization with the NIS domains. At first, you should update the NIS+ tables nightly with the latest NIS information. If you are using NIS domains as the master source of name service information at your site, all changes made to the NIS+ tables between synchronization updates will be erased every time you propagate an NIS update. For example, passwords that were changed with the nispasswd command will be overwritten by the previous NIS password, unless you also run yppasswd whenever you run the nispasswd command. When you convert to an all NIS+ namespace, you will no longer need to run the yppasswd command.

At first, NIS will no doubt be the primary service. As you become familiar with the intricacies of sharing information, you will be able to plan a transition to make NIS+ the primary service.

Some NIS+ users may want the capability to switch back and forth between the main NIS domain and the new NIS+ domain. The nisclient script can help them do this easily when backup files are made.

Determine the Configuration of NIS-Compatible Servers

Take stock of your NIS servers, keeping in mind the requirements for your NIS+ servers. If you plan to eventually use them for the NIS+ service, upgrade them to the NIS+ recommendations. Identify which NIS servers will be used to support which NIS+ domains, and in what capacity, (either master or replica). Remember that NIS+ servers belong to the domain above the one they support

(except for the root domain servers). Since NIS+ servers do not belong to the domain they serve, you will not be able to use the same machines for other services that require domain dependent information.

If possible, plan to use your NIS+ server machines only for NIS+. This arrangement could require you to transfer other network services, such as DNS name services, boot server, home directories, NFS servers, and so on, to non-NIS+ server machines.

At many sites, the NIS server plays multiple roles, such as NFS server, compute server, rlogin server, and mailhost server. Because the NIS server uses the same information to resolve its names as do its clients, the NIS server can provide other services as well. As discussed in "The Domain Hierarchy" on page 12, except for root domains, all NIS+ servers live in the domain above the ones that they serve. So either do not run those services on an NIS+ server that require access to the name service, or use other means, such as files in nsswitch.conf, to acquire this same information. This problem would be solved if there is no hierarchy; in which case, the NIS+ root servers will live in the domain that they serve. The resource requirements of an NIS+ server are greater than those of an NIS server; hence it is advisable to not run other services along with NIS+.

If you have non-Solaris machines on your network, then either you can continue to run your NIS+ servers in NIS-compatibility mode, or you can move all such machines into their own domain. If you move all non-Solaris machines to one subnet, you can remove the restriction of having NIS+ servers on the same subnet as their NIS-compatible clients require. This will reduce the number of replicas required for any domain.

Decide How to Transfer Information Between Services

To keep the information synchronized, be sure to make one namespace subordinate to the other. At first, the NIS namespace may be the dominant one, in which case you would make changes to the NIS maps and load them into the NIS+ tables. In effect, the NIS namespace would be the master database.

An NIS+ server in NIS-compatibility mode supports standard NIS maps. An exhaustive list of these maps is in the NOTES section of the ypfiles(4) man page. But there are some limitations on map support. The NIS+ server serves

ypmatch requests only on the netgroup map, and not on the reverse maps. It does not support enumeration requests. (For example, ypcat.) The passwd.adjunct map is not supported, either.

Eventually, the NIS+ namespace would be dominant. When that is the case, you would make changes in the NIS+ tables and copy them to the NIS maps.

The NIS+ command nisaddent and the NIS+ script nispopulate transfer information between NIS maps and NIS+ tables, as summarized in Table 4-2.

Table 4-2

NIS+ Command	Description
/usr/lib/nis/nisaddent -y	Transfers information from an NIS map to an NIS+ table after you run ypxfr to transfer maps from an NIS server to the local disk. Nonstandard NIS maps can be transferred to NIS+ tables if the information is in key/value pairs. Multi-columned maps will be not be transferred.
/usr/lib/nis/nisaddent -d	Copies information from an NIS+ table into a file, which can then be transferred into an NIS map with standard NIS utilities.
/usr/lib/nis/nispopulate -Y	Transfers information from NIS maps into NIS+ tables.

A Note About Changing Information in the Password Table

While using parallel NIS and NIS+ namespaces, be sure to keep the information in the NIS+ passwd table synchronized with the information in the NIS passwd map. The nispasswd and yppasswd commands affect only their respective databases.

NIS+ uses the nispasswd command to change information stored in the NIS+ passwd table. It is the equivalent of the yppasswd command for NIS. The nispasswd command provides capabilities that are similar to those offered by other commands. Table 4-3 on page 51 summarizes their differences.

Table 4-3

Command	Description
passwd	Changes information in the workstation's /etc/passwd and /etc/shadow file.
yppasswd	Changes information in the NIS passwd map. Has no effect on the NIS+ passwd table or local files.
nispasswd	Changes and displays information in the NIS+ passwd table. When a principal's password is changed, nispasswd tries to update the principal's secret key in the cred table. Although nistbladm could be used to edit the NIS+ passwd table, nispasswd is better because its options are customized for the passwd table, including password encryption, which makes the command easier to use.
nistbladm	Creates, changes, and displays information about any NIS+ table, including the passwd table. Although the nispasswd command is easier to use for the passwd table, nistbladm allows you to: - Create new entries - Delete an existing entry - Change the UID and GID fields in the passwd table - Change the LastChanged, Inactive, and Expired fields in the shadow table - Change access rights and other security-related attributes of the passwd table. NOTE: (Do not use it to change the passwords themselves, though.)

If you are the owner of the passwd table, you can change password information without constraints. However, if you are not the owner, you must comply with construction constraints.

In domains created with NIS-compatibility mode, the permissions are slightly different: permissions at the column level provide read access to the nobody category.

Decide How to Implement DNS Forwarding

NIS servers can forward DNS requests made from Solaris 1.x NIS clients. NIS+ servers running in NIS-compatibility mode also provide DNS forwarding, but only starting with the Solaris 2.3 or later releases. (This feature is available in

the Solaris 2.2 release through a patch.) As a result, Solaris 2.x NIS clients must have appropriate /etc/nsswitch.conf and /etc/resolv.conf files installed locally.

Solaris 1.x NIS clients being supported by Solaris 2.0 or 2.1 servers running in NIS-compatibility mode will not be able to take advantage of DNS forwarding. You must upgrade those servers to Solaris 2.3 or later releases.

If the DNS domains are repartitioned, you must redefine new DNS zone files. Clients, however, may require updates to their /etc/resolv.conf file. A client, if it is also a DNS client, can set up its Name Service Switch configuration file to search for host information in either DNS zone files or NIS maps--in addition to NIS+ tables.

DNS Forwarding for NIS+ Clients

NIS+ clients do not have implicit DNS forwarding capabilities like NIS clients do. Instead, they take advantage of the Name Service Switch. To provide DNS capabilities to an NIS+ client, change its hosts entry to:

hosts:  nisplus dns       [NOTFOUND=return] files

DNS Forwarding for Solaris 2.x NIS Clients

If an NIS client is using the DNS forwarding capability of an NIS-compatible NIS+ server, the client's nsswitch.conf file should not have the following syntax in the hosts file:

hosts:  nis dns files # not for NIS clients

Since DNS forwarding automatically forwards host requests to DNS, the syntax shown above would cause both the NIS+ server and the name service switch to forward unsuccessful requests to the DNS servers, impacting performance.

In addition, NIS clients running the Solaris 1.x release must have a resolver library. Be sure to install the shlib_custom software category. In this case, Solaris 1.x NIS clients would only use DNS for host lookup.

NIS and NIS+ Command Equivalents in the Solaris 1.x and 2.x Releases

The tables in this section give a quick overview of the differences between Solaris 1.x NIS commands, Solaris 2.x NIS commands, and their NIS+ equivalents. Table 4-4 on page 54 describes which NIS commands are supported in the Solaris 2.x release. Table 4-5 on page 55 and Table 4-6 on page 56 describe the NIS+ equivalents to NIS client and server commands in the Solaris 2.x release. Table 4-7 on page 57 contains a list of the NIS application programmer's interface functions and their NIS+ API equivalents, if they exist. See the appropriate man pages for details.

NIS Commands Supported in the Solaris 2.x Release

Only some NIS commands are supported in the Solaris 2.x release. NIS server commands are not shipped with the Solaris 2.x release. Just the NIS client commands are included. Whether these NIS commands run also depends on whether a Solaris 2.x NIS client is making requests of an NIS server or of an NIS+ server in NIS-compatibility mode. NIS clients cannot make updates to NIS+ servers that are running in NIS-compatibility mode. For example, such clients cannot run the commands chkey, newkey, and yppasswd. Table 4-4 on page 54 lists the NIS commands supported in the Solaris 2.x release.

Table 4-4

Command Type	NIS Commands Supported in the Solaris 2.x Release	NIS Commands Not Supported in the Solaris 2.x Release
Utilities	ypinit ypxfr ypcat ypmatch yppasswd ypset ypwhich	yppush yppoll ypchsh ypchfn ypmake
Daemons	ypbind	ypserv ypxfrd rpc.ypupdated rpc.yppasswdd
NIS API	yp_get_default_domain() yp_bind() yp_unbind() yp_match() yp_first() yp_next() yp_all() yp_master() yperr_string() ypprot_err()	yp_order() yp_update()

Client and Server Command Equivalents

The two tables in this section contain NIS commands and their approximate NIS+ equivalents. The commands have been divided into two categories; Table 4-5 on page 55 contains those commands that are name service client to name service server and Table 4-6 on page 56 contains those commands that are name service server to name service server.

The commands shown in Table 4-5 on page 55 are client to name server commands. These commands are typed on name service client machines and request information of name service servers. The commands in column one

will run on Solaris 1.x or 2.x NIS clients connected to Solaris 1.x NIS servers. The commands in column two will run on Solaris 1.x or 2.x NIS clients connected to Solaris 2.x NIS+ servers running in NIS-compatibility mode.

---

Note - The command ypinit -c is only available, however, on Solaris 2.x NIS clients.

---

The commands in column three will only run on Solaris 2.x NIS+ clients connected to Solaris 2.x NIS+ servers. Commands are approximately equivalent across rows. N/A indicates that an equivalent command does not exist for that case.

Table 4-5 NIS Client Commands and Equivalent NIS+ Commands

SunOS 4.x NIS Server

NIS+ Server in NIS-Compatibility Mode

NIS+ Server

ypwhich -m	ypwhich -m	niscat -o
ypcat	ypcat**	niscat
ypwhich	ypwhich	N/A
ypmatch	ypmatch	nismatch/nisgrep
yppasswd	N/A	nispasswd
ypbind	ypbind	N/A
yppoll	N/A	N/A
ypset	ypset	N/A
N/A	ypinit -c	nisinit

---

Note - ** The ypcat command is not supported for queries directed to the netgroup table. The NIS client's request will time-out before an answer is received because this table's format is so different from the netgroup NIS map's format.

---

The commands shown in Table 4-6 on page 56 are name server to name server commands. The NIS server commands are not included in the Solaris 2.x release, so they are not available to either NIS+ servers nor NIS+ servers in NIS-compatibility mode. In addition, an NIS server cannot make updates to an

NIS+ server, nor is the reverse situation possible. The third column of this table lists the NIS+ server commands that are equivalent to the NIS server commands listed in the first column. There are no exact equivalents for servers in NIS-compatibility mode because NIS-compatibility mode only refers to client commands.

Table 4-6 NIS Server Commands and Equivalent NIS+ Commands

SunOS 4.x NIS Server

NIS+ Server in NIS-Compatibility Mode

NIS+ Server

ypxfr	N/A	N/A
makedbm	N/A	nisaddent
ypinit -m ypinit -s	N/A	nisserver
ypserv	rpc.nisd -Y	rpc.nisd
ypserv -d	rpc.nisd -Y -B	no DNS forwarding required, use /etc/nsswitch.conf
ypxfrd	N/A	N/A
rpc.ypupdated	N/A	N/A
rpc.yppasswd	N/A	N/A
yppush	N/A	nisping
ypmake	N/A	nissetup, nisaddent

NIS and NIS+ API Function Equivalents

To completely convert your site to NIS+, all applications have to be ported to NIS+ in addition to changing the name service. Any internally created applications that make NIS calls have to be modified to use NIS+ calls. Otherwise, you will always have to run your NIS+ servers in NIS-compatibility mode with all the drawbacks that this mode entails. External applications may force you to run your namespace in NIS--compatibility mode until they are updated as well.

Table 4-7 contains a list of the NIS application programmer's interface functions and their NIS+ API equivalents, if they exist.

Table 4-7

NIS API Functions	NIS+ API Functions
yp_get_default_domain()	nis_local_directory()
ypbind()	N/A
ypunbind()	N/A
ypmatch()	nis_list()
yp_first()	nis_first_entry()
yp_next()	nis_next_entry()
yp_all()	nis_list()
yp_master()	nis_lookup()
yperr_string()	nis_perror(), nis_sperrno()
ypprot_err()	nis_perror(), nis_sperrno()
yp_order()	N/A
yp_update()	nis_add_entry(), nis_remove_entry(), nis_modify_entry()