NIS+ Transition Guide

Chapter 5 Prerequisites to Transition

This chapter describes several miscellaneous tasks that must be carried out before beginning the transition:

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 Chapter 1, Introduction, 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.

Table 5-1 provides a summary of commands that operate on NIS+ groups and group permissions.

Table 5-1 NIS+ Commands for Groups


Command	Description
`nisgrpadm`	Creates or deletes groups, adds, changes, lists, or deletes members
`niscat -o`	Displays the object properties of an NIS+ group
`nissetup`	Creates the basic structure of the directory in which a domain's groups are stored
`nisls`	Lists the contents of a directory
`NIS_GROUP`	Environment variable that overrides the value of `nisdefaults` for the shell in which it is set
`nischmod`	Changes an object's access rights
`nischown`	Changes the owner of an NIS+ object
`nischgrp`	Changes the group owner of an NIS+ object
`nistbladm -u`	Changes access rights to NIS+ table columns
`nisdefaults`	Displays or changes the current NIS+ defaults

Determine Who Will Own the Domains

To take complete advantage of the features inherent in a domain hierarchy, distribute the ownership of domains to the organizations they are dedicated to supporting. This will free the administrators of the root domain from performing rudimentary tasks at the local level. When you know who owns what, you can provide guidelines for creating administrative groups and setting their access rights to objects.

Consider how to coordinate the ownership of NIS+ domains with the ownership of DNS domains. Here are some guidelines:

The administration of the DNS domain structure should remain the responsibility of the highest-level administrative group at the site.

This same administrative group also owns the top-level NIS+ domain.

Responsibility for the administration of lower-level DNS and NIS+ domains is delegated to individual sites by the top-level administrative group. If the NIS+ domains are created along the same principles as the DNS domains (for instance, organized geographically), this delegation will be simple to explain.

Determine Resource Availability

Determine what administrative resources are required for the implementation. These are above and beyond the resources required for normal operation of NIS+. If your transition involves a long period of NIS+ and NIS compatibility, additional resources may be required.

Consider not only the implementation of the namespace design, but also conversion for the numerous clients and dealing with special requests or problems. Keep in mind that NIS+ has a steep learning curve. Administrators may be less efficient for awhile at performing support functions with NIS+ than they were with NIS. Consider not only formal training, but extensive lab sessions with hands-on experience.

Finally, even after the transition is complete, administrators will require extra time to become familiar with the everyday work flow of supporting NIS+.

Consider hardware resources. NIS servers are often used to support other network services, such as routing, printing, and file management. Because of the potential load on an NIS+ server, you should use dedicated NIS+ servers. This load-balancing simplifies the transition because it simplifies troubleshooting and performance monitoring. Of course, you incur the cost of additional systems. The question of how many servers you will need and how they should be configured is addressed in Chapter 2, Planning the NIS+ Namespace.

Remember, these servers are required in addition to the NIS servers. Although the NIS servers might be decommissioned or recycled after the transition is complete, the NIS+ servers will continue to be used.

Resolve Conflicts Between Login Names and Host Names

The NIS+ authentication scheme does not allow workstations and users to use the same names within a domain; for example, joe@joe is not permitted. Since NIS+ does not distinguish between credentials for hosts and login names, you can only use one credential type per name. If you have duplicate names in your namespace and you must keep the duplicate host name for some other reason, make this change: retain the user login name and alias the duplicate host names. Create a new name for the host and use the old name as an alias for the new name. See "Resolving User/Host Name Conflicts" for examples of illegal name combinations.

You must resolve name conflicts before the implementation can begin, but you should also plan on permanently checking new workstations and user names during routine NIS+ operation. The nisclient script does name comparisons when you use it to create a client credential.

Examine All Information Source Files

Check all /etc files and NIS maps for empty fields or corrupted data before configuring NIS+. The NIS+ table-populating scripts and commands might not succeed if the data source files contain empty fields or extraneous characters. Fill blank fields or fix the data before you start. It is better to delete questionable users or machines from the /etc files or NIS maps before running NIS+ scripts, then add them back later after NIS+ is installed, than to proceed with the scripts and possibly corrupt data.

Remove the "." from Host Names

Because NIS+ uses dots (periods) to delimit between machine names and domains and between parent and sub-domains, you cannot have a machine (host) name containing a dot. Before converting to NIS+ you must eliminate any dots in your hostnames. You can convert hostname dots to hyphens (-). For example, you cannot have a machine named sales.alpha. You can convert that name to sales-alpha. (See the hosts man page for detailed information on allowable hostnames.)

Remove the "." from NIS Map Names

As described in Chapter 2, Planning the NIS+ Namespace, NIS+ automounter tables have replaced the "." (dot) in the table name with an underscore. You also need to make this change to the names of NIS maps that you will use during the transition. If you do not, NIS+ will confuse the dot in the name with the periods that distinguish domain levels in object names.

Note -

Be sure to convert the dot to underscores for all NIS maps, not just those of the automounter. Be aware, however, that changing the names of nonstandard NIS maps from dots to underscores may cause applications that use those nonstandard maps to fail unless you also modify the applications to recognize NIS+ syntax.

Document Your Current NIS Namespace

Documenting your current configuration will give you a clear point of departure for the transition. Make a list of the following items:

Name and location of all current NIS domains and networks
Host name and location of all current NIS servers, both master and slave
Configuration of all current NIS servers, including:
- Host name
- CPU type
- Memory size
- Disk space available
- Name of administrators with root access
Nonstandard NIS maps

Correlate the list of your NIS clients with their eventual NIS+ domains. They must be upgraded to the current Solaris operating environment.

Create a Conversion Plan for Your NIS Servers

Take stock of your NIS servers. Although you can recycle them after the transition is complete, keep in mind that you will go through a stage in which you will need servers for both services. Therefore, you cannot simply plan to satisfy all your NIS+ server needs with your existing NIS servers.

You might find it helpful to create a detailed conversion plan for NIS servers, identifying which NIS servers will be used for NIS+ and when they will be converted. Do not use the NIS servers as NIS+ servers during the first stages of NIS-to-NIS+ transition. As described in Chapter 6, Implementing the Transition, the implementation is most stable when you check the operation of the entire namespace as a whole before you convert any clients to NIS+.

Assign NIS servers to NIS+ domains and identify each server's role (master or replica). When you have identified the servers you plan to convert to NIS+ service, upgrade them to NIS+ requirements (see "Server Memory Requirements").