Server Command Equivalents

Table 26-12 shows name server-to-name server commands. The NIS server commands are not included in the Solaris 2 or Solaris 9 releases, 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.

Table 26-12 NIS Server Commands and Equivalent NIS+ 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 26-13 contains a list of the NIS API functions and their NIS+ API equivalents, if they exist.

Table 26-13 NIS API and NIS+ API Equivalent Functions

NIS-Compatibility Mode Protocol Support

Table 26-14 shows which NIS protocols are supported by NIS+ servers in NIS- compatibility mode.

Table 26-14 Support for NIS Protocols by NIS+ Servers

Before You Transition to NIS+: Gauge the Impact of NIS+ on Other Systems

Develop a formal introduction, testing, and familiarization program for your site, not only to train administrators, but also to uncover dependencies of other systems or applications on NIS that will be affected by a transition to NIS+.

For example, some applications may rely on some of the NIS maps. Will they function with standard or custom NIS+ tables? How will their need for access affect your overall security plan?

What nonstandard NIS maps are being used at your site? Can you convert them to NIS+ tables or create nonstandard NIS+ tables to store their information? Be sure to check their access rights.

Does your site use locally built applications that depend on NIS? Do you have commands or applications that make direct NIS calls, such as embedded yp_match() function calls? (See NIS and NIS+ API Function Equivalents for more information.)

Do you have any duplicate user and host names in your namespace? (See Resolving User/Host Name Conflicts for more information.)

How will the network installation procedures be affected by the transition to NIS+? Analyze the changes required, if any. Gauging the impact of NIS+ on your site administrative practices can help uncover potential roadblocks.

Train Administrators

Another goal of the introduction and familiarization program discussed in Become Familiar With NIS+ is to give the administrators at your site an opportunity to become familiar with NIS+ concepts and procedures. Classroom instruction alone is insufficient. Administrators need a chance to work in a safe test environment. The training should consist of:

• A formal course in NIS+ concepts and administration

• Basic NIS+ troubleshooting information and practice

• Information about your site's implementation strategy and plans

Write a Communications Plan

Prepare a plan to communicate your intentions to users long before you actually begin converting clients to NIS+. Tell them about the implementation plan and give them a way to obtain more information. As mentioned in Suggested Transition Phases, a typical transition goal is to keep the impact of the transition on clients to a minimum, but users might become concerned about the upcoming change. Send out email notices, conduct informative seminars, and designate email aliases or individuals to whom users can send questions.

Identify Required Conversion Tools and Processes

Consider creating or obtaining transition tools to help with the implementation. If your site already uses automated tools to administer individual systems or network services, consider porting them to operate under the versions of Solaris software and NIS+ that you will be using for the transition (see Use a Single Release of Software). Here are some suggestions for scripts you might want to write:

• A script to convert users to NIS+--make additions to the nisclient shell script

• A check script to verify the correctness of a user's NIS+ environment

• Backup and recovery scripts

• crontab entries for routine NIS+ maintenance

• Procedures for notification of outages

Scripts such as these ensure that the transition is carried out uniformly across domains, speed the transition, and reduce complaints. You should also prepare a set of standard configuration files and options, such as nsswitch.conf, that all clients across the namespace can use.

Identify Administrative Groups Used for Transition

Be sure that the NIS+ groups created as part of your namespace design (see Establishing Password-aging Criteria, Principles, and Rules) correspond to the administrative resources you have identified for the transition. You could require a different set of NIS+ groups for the transition than for routine operation of an NIS+ namespace. Consider adding remote administrators to your groups in case you need their help in an emergency.

Make sure that group members have the proper credentials, that namespace objects grant the proper access rights to groups, and that the right group is identified as the group owner of the right namespace objects.

The following table provides a summary of commands that operate on NIS+ groups and group permissions.

Table 26-15 NIS+ Commands for Groups