This section describes several miscellaneous tasks that must be carried out before beginning the transition:
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 ypmatch 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 will help uncover potential roadblocks.
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:
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 Transition Principles, 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 e-mail notices, conduct informative seminars, and designate email aliases or individuals to whom users can send questions.
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 AIX software and NIS+ that you will be using for the transition. Here are some suggestions for scripts you might want to write:
Scripts such as these will 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 /etc/irs.conf, that all clients across the namespace can use.
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 summarizes commands that operate on NIS+ groups and the group permissions that are useful,
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.
Once 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:
Determine what administrative resources will be required for the implementation. These will be above and beyond the resources required for normal operation of NIS+. If your transition will involve a long period of NIS+ and NIS compatibility, additional resources may be required.
Consider not only the implementation of the namespace design but also the conversion 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 a while 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 makes troubleshooting and performance monitoring simpler. 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 Designing 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.
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.
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, and then add them back later after NIS+ is installed, than to proceed with the scripts and possibly corrupt data.
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 host names. You can convert host name dots to underscores (_). For example, you cannot have a machine named sales.alpha. You can convert that name to sales_alpha. (See the host command description for detailed information on allowable host names.)
As described in Designing 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.
Attention: 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.
Documenting your current configuration will give you a clear point of departure for the transition. Make a list of the following items:
Correlate the list of your NIS clients with their eventual NIS+ domains. They will have to be upgraded to the AIX Version 4.3.3 release.
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 will 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 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). Once you have identified the servers you plan to convert to NIS+ service, upgrade them to NIS+ requirements (see Disk Space and Memory Requirements).