[ Next Article | Previous Article | Book Contents | Library Home | Legal | Search ]
Network Information Services (NIS and NIS+) Guide

Using 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 is that it does not require you to make any changes to NIS clients. The essential drawback is that you will not be able to take advantage of full NIS+ security and hierarchy and you may have to change those clients' domain names.

The following figure illustrates how you convert from an NIS-only namespace to an NIS-compatible namespace that responds to both NIS and NIS+ requests.

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 will be able to 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 easily 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 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 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 irs.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 not run other services along with NIS+.

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 ypfiles command description. 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 should be dominant. When that is the case, you would 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 the following table.

NIS+ Data Transfer Commands Changing Information in the Passwd Table
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. Multicolumned maps will be not be transferred.
/usr/lib/nis/nisaddent -d Copies information from an NIS+ table to a file, which can then be transferred to an NIS map with standard NIS utilities.
/usr/lib/nis/nispopulate -Y Transfers information from NIS maps to NIS+ tables.

To properly implement the passwd command and password aging on your NIS+ network, the entries in the /etc/security/user file on every machine must be correct. These entries determine where the passwd command will go for information and where it will update password information.

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 NIS clients. NIS+ servers running in NIS-compatibility mode also provide DNS forwarding.

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.

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

The following table contains a list of the NIS API functions and their NIS+ API equivalents, if they exist.

NIS API and NIS+ API Equivalent Functions
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()

NIS-Compatibility Mode Protocol Support

The following table shows which NIS protocols are supported by NIS+ servers in NIS- compatibility mode.

Support for NIS Protocols by NIS+ Servers
NIS Protocols Compatibility Description
NIS client V2 protocol Supported
NIS server-to-server protocol Unsupported
NIS client update protocol yppasswd protocol supported
NIS client V1 protocol Not supported except for YPPROC_NULL, YPPROC_DOMAIN, and YPPROC_DOMAIN_NONACK


[ Next Article | Previous Article | Book Contents | Library Home | Legal | Search ]