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
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 "Planning the NIS+ Namespace: Identifying the Goals of Your Administrative Model".
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 machines 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 machines and user names during routine NIS+ operation. The nisclient script does name comparisons when you use it to create a client credential.