This section describes 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+.
Gauging the impact of NIS+ on your site administrative practices will help uncover potential road blocks.
Another goal of the introduction and familiarization program discussed in Become Familiar with NIS+ is to give your site administrators an opportunity to become familiar with NIS+ concepts and procedures. Administrators need a chance to work in a safe test environment because classroom training alone is insufficient. The training should consist of:
Communicate your plan 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 seminars, and designate e-mail 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. Some suggestions for scripts you might want to write include the following:
Scripts such as these ensure that the transition is carried out uniformly across domains and speed the entire transition process.
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 appropriate group is identified as the group owner of the appropriate namespace objects.
The following table summarizes commands
that operate on NIS+ groups.
| 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: groups_dir |
| 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 |
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 frees the administrators of the root domain from performing basic tasks at the local level.
After ownership is established, 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 implementing the namespace design but also converting 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+.
Regarding hardware, 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.
NIS+ authentication 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, 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 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.
It is 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).