Phase II-Connect the NIS+ Namespace to Other Namespaces
[Optional] Connect the root domain to the DNS namespace.
An NIS+ client can be connected to the Internet using the name service switch. machines, if they are also DNS clients, can have their name service switch configuration files set to search for information in DNS zone files--in addition to NIS+ tables or NIS maps.
Configure each client's /etc/nsswitch.conf and /etc/resolv.conf files properly. The /etc/nsswitch.conf file is the client's name service switch configuration file. The /etc/resolv.conf lists the IP addresses of the client's DNS servers.
Test the joint operation of NIS+ with DNS.
Verify that requests for information can pass between the namespaces without difficulty.
If operating NIS+ in parallel with NIS, test the transfer of information.
Use the nispopulate script to transfer information from NIS to NIS+. To transfer data from NIS+ to NIS, run nisaddent -d and then ypmake. (See the man pages for more information.) Use scripts to automate this process. Establish policies for keeping tables synchronized, particularly the hosts and passwd tables. Test the tools used to maintain consistency between the NIS and NIS+ environments. Decide when to make the NIS+ tables the real source of information.
Test operation of NIS+ with both DNS and NIS.
Test all three namespaces together to make sure the added links do not create problems.
Phase III-Make the NIS+ Namespace Fully Operational
Convert clients one workgroup at a time, and convert all workgroups in a subnet before starting on those of another subnet. That way, when you convert all the clients in a subnet, you can eliminate the NIS service on that subnet. Run the verification script after converting each client to make sure that the conversion worked properly. That verification script should inform the user which support structure is in place, to help with problems and how to report them. The actual steps required depend on the site.
Use the nisclient script to convert NIS clients to NIS+ clients. If you need to modify the clients' DNS configuration, you must write your own scripts to automate that process.
You can also save time if your site has a shared, mounted central directory similar to /usr/local. You could put the script in the central directory and, on the day of conversion, send email to clients asking them to run the script as superuser.
Monitor the status of the transition as clients are being converted.
Track progress against your plan and all serious complications not anticipated in the planning stages. Announce your status so that interested parties can track it.
As all the clients on a subnet are converted to NIS+, decommission the NIS servers. If a particular subnet has some clients that require NIS service, use the NIS-compatibility feature of the NIS+ servers but do not retain the NIS servers.
After the implementation is complete, test to see that NIS+ is working correctly.
Optimize the NIS+ environment.
Based on the results of your performance evaluation, modify the NIS+ environment as needed. These improvements can be as simple as adding selected replicas in domains with high loads or as involved as rearranging the storage of NIS+ information for a group of domains.
If you did not change old domain names during the transition for the sake of simplicity, upgrade them now to the new NIS+ naming scheme. For example, if you left some domains with geographic labels while you converted to an organizational hierarchy, you now change the geographic names to their organizational versions.
Phase IV-Upgrade NIS-Compatible Domains
Convert the last NIS clients to NIS+.
As soon as you can, eliminate the need for NIS-compatible NIS+ domains. Upgrading the last NIS clients to NIS+ will allow you to take advantage of NIS+ security features. You will not be able to eliminate the need for NIS-compatible NIS+ domains if you are running non-Solaris machines on your network.
Adjust your security configuration.
When you have no more NIS clients, you can restart the NIS+ servers in standard mode and run nischmod on the NIS+ tables to change permission levels, eliminating the security hole caused by NIS compatibility. If you did not create credentials for NIS+ principals before, you must do that now. Restrict the access of unauthenticated principals.
Establish miscellaneous evaluation and improvement programs.
Evaluate operational procedures to determine which ones can be improved, particularly procedures used to recover from problems. Plan for new NIS+ releases and possible functional enhancements. Track the development of Solaris components that might require new NIS+ tables. Look for automated tools that enable you to perform NIS+ administration functions more efficiently. Finally, work with internal developers to help them take advantage of the NIS+ API.