Chapter 4 Using NIS-Compatibility Mode

This chapter provides general information on NIS-compatibility mode and discusses the issues involved in running NIS+ in NIS-compatibility mode.

• "Introduction to NIS-Compatibility Mode"

• "Selecting Your NIS-Compatible Domains"

• "Determining NIS-Compatible Server Configuration"

• "Deciding How to Transfer Information Between Services"

• "Deciding How to Implement DNS Forwarding "

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

• "NIS-Compatibility Mode Protocol Support"

Introduction to NIS-Compatibility Mode

Deciding whether and how to run NIS+ in parallel to NIS--and when to stop--is probably one of the most difficult transition issues you will face. NIS+ provides several features that allow it to operate in parallel with NIS, notably, the NIS-compatibility mode.

If you plan to use NIS-compatibility mode, you have to consider the essential benefit provided by NIS-compatibility mode. You need not make any changes to NIS clients. The essential drawback is that you cannot take advantage of full NIS+ security and hierarchy and you may have to change those clients' domain names.

Figure 4-1 illustrates how you convert from an NIS-only namespace to an NIS-compatible namespace that responds to both NIS and NIS+ requests.

Figure 4-1 Transition to NIS-Compatibility Mode

Selecting Your NIS-Compatible Domains

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 name that is being supported by the NIS-compatible NIS+ server.

At first, NIS will no doubt be the primary service. As you become familiar with the intricacies of sharing information, you can plan a transition to make NIS+ the primary service. Some NIS+ users may want the capability of switching back and forth between the main NIS domain and the new NIS+ domain. The nisclient script can help them do this when backup files are made.

Determining NIS-Compatible Server Configuration

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 cannot 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 can 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 mail host 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 "Domain Hierarchy", except for root domains, all NIS+ servers live in the domain above the ones that they serve. So either do not run 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 were no hierarchy; the NIS+ root servers would live in the domain that they serve. The resource requirements of an NIS+ server are greater than those of an NIS server; therefore, it is advisable to avoid running other services along with NIS+.

If you have non-Solaris machines on your network, then you can either 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. This will reduce the number of replicas required for any domain.

Deciding How to Transfer Information Between Services

To keep 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. However, 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 on the netgroup map (for example, ypcat). The passwd.adjunct map is not supported, either.

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

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

In versions of NIS+ previous to the Solaris 2.5 release, it was necessary to use separate password commands (passwd, yppasswd, nispasswd) to handle password matters, depending on whether a user's password information was stored in /etc files, NIS maps, or NIS+ tables. Starting with the Solaris 2.5 release, all of these matters are handled automatically by the passwd or passwd -r nisplus commands and are controlled by the passwd entry in the user's nsswitch.conf file.

In order to properly implement the passwd command and password aging on your NIS+ or NIS-compatible network, the passwd entry of the nsswitch.conf file on every machine must be correct. This entry determines where the passwd command goes for password information and where it updates password information.

Only five passwd entry configurations are permitted:

Example 4-1 Permitted passwd nsswitch.conf Entries

passwd:files

passwd: files nis

passwd: files nisplus

passwd: compat

passwd_compat: nisplus

All of the nsswitch.conf files on all of your network's workstations must use one of the passwd configurations shown above. If you configure the passwd entry in any other way, users may not be able to log in.

In domains created with NIS-compatibility mode, the permissions are slightly different: permissions at the table level must be set to provide read rights to the world class, and at the column level, permissions must provide read access to the nobody class.

Deciding 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, starting with the Solaris 2.3 or later releases. (This feature is available in the Solaris 2.2 release patch #101022-06.) 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 supported by Solaris 2.0 or 2.1 servers running in NIS-compatibility mode are not 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. Since DNS-forwarding automatically forwards host requests to DNS, this syntax causes both the NIS+ server and the name service switch to forward unsuccessful requests to the DNS servers, slowing performance.

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-2 describes which NIS commands are supported in the Solaris 2.x release.

• Table 4-3 and Table 4-4 describe the NIS+ equivalents to NIS client and server commands in the Solaris 2.x release.

• Table 4-5 contains a list of the NIS application programming 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. Only 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 chkey and newkey commands. Table 4-2 lists the NIS commands supported in the Solaris 2.x release.

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-3 contains name service client commands and Table 4-4 contains name service server commands.

Client Command Equivalents

Table 4-3 shows 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 1 run on Solaris 1.x or 2.x NIS clients connected to Solaris 1.x NIS servers. The commands in column 2 run on Solaris 1.x or 2.x NIS clients connected to Solaris 2.x NIS+ servers running in NIS-compatibility mode. The commands in column 3 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.

Note that:

• In the Solaris 2.5 release, the passwd command should be used regardless of NIS or NIS+ status. The functions previously performed by nispasswd and yppasswd have now been included in the passwd command.

• The ypinit -c command is available only on Solaris 2.x NIS clients.

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

Server Command Equivalents

Table 4-4 shows 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 or NIS+ servers in NIS-compatibility mode. In addition, an NIS server cannot make updates to an NIS+ server, nor can an NIS+ server make updates to an NIS server. Column 3 lists the NIS+ server commands that are equivalent to the NIS server commands in column 1. Servers in NIS-compatibility mode have no exact equivalents because NIS-compatibility mode refers only to client commands.

NIS and NIS+ API Function Equivalents

To completely convert your site to NIS+, you must both change the name service and port all applications to NIS+. Any internally created applications that make NIS calls have to be modified to use NIS+ calls. Otherwise, you 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-5 contains a list of the NIS API functions and their NIS+ API equivalents, if they exist.

NIS-Compatibility Mode Protocol Support

Table 4-6 shows which NIS protocols are supported by NIS+ servers in NIS- compatibility mode.