Chapter 6 Implementing the Transition

This chapter divides the task of setting up an NIS+ namespace into recommended phases.

Introduction to Setting Up NIS+

After you have performed the tasks described in the previous chapters, most of the hard work is done. Now all you have to do is set up the namespace you designed and add the clients to it. This chapter describes how to do that. Before performing these steps, verify that all pre-transition tasks have been completed and that users at your site are aware of your plans.

If you plan to run NIS+ domains alongside DNS domains, you must set up one NIS+ sub-domain with each DNS domain. After you have set up a complete NIS+ namespace along with the first DNS domain and have verified that everything is working right, then you can set up the other NIS+ namespaces in parallel.

Phase I-Set Up the NIS+ Namespace

Set up the namespace with full DES authentication, even if the domains will operate in NIS-compatibility mode. Use the NIS+ scripts described in Solaris Naming Setup and Configuration Guide to set up your namespace; see Solaris Naming Administration Guide for more explanation of NIS+ structure and concepts. Then perform the following steps:

Set up the root domain.

If you are going to run the root domain in NIS-compatibility mode, use nisserver. (If you choose not to use the setup scripts, use the -Y flag of rpc.nisd and nissetup.)

Populate the root domain tables.

You can use nispopulate to transfer information from NIS maps or text files. Of course, you can also create entries one at a time with nistbladm or nisaddent.

Set up clients of the root domain.

Set up a few clients in the root domain so that you can properly test its operation. Use full DES authentication. Some of these client machines will later be converted to root replica servers and some will serve as workstations for the administrators who support the root domain. NIS+ servers should never be an individual's workstation.

Create or convert site-specific NIS+ tables.

If the new NIS+ root domain requires custom, site-specific NIS+ tables, create them, with nistbladm and transfer the NIS data into them with nisaddent.

Add administrators to root domain groups.

Remember, the administrators must have LOCAL and DES credentials (use nisaddcred). Their workstations should be root domain clients and their root identities should also be NIS+ clients with DES credentials.

Update the sendmailvars table, if necessary.

If your email environment has changed as a result of the new domain structure, populate the root domain's sendmailvars table with the new entries.

Set up root domain replicas.

First convert the clients into servers (use rpc.nisd with -Y for NIS compatibility and also use -B if you want DNS forwarding), then associate the servers with the root domain by running nisserver -R.

For NIS compatibility, run rpc.nisd with the -Y and edit the /etc/init.d/rpc file to remove the comment symbol (#) from the EMULYP line. For DNS forwarding, use the -B option with rpc.nisd.

Test the root domain's operation.

Develop a set of installation-specific test routines to verify a client's functioning after the switch to NIS+. This will speed the transition work and reduce complaints. You should operate this domain for about a week before you begin converting other users to NIS+.

Set up the remainder of the namespace.

Do not convert any more clients to NIS+, but go ahead and set up all the other domains beneath the root domain. This includes setting up their master and replica servers. Test each new domain as thoroughly as you tested the root domain until you are sure your configurations and scripts work properly.

Test the operation of the namespace.

Test all operational procedures for maintenance, backup, recovery, and other scenarios. Test the information-sharing process between all domains in the namespace. Do not proceed to Phase II until the entire NIS+ operational environment has been verified.

Customize the security configuration of the NIS+ domains.

This may not be necessary if everything is working well; but if you want to protect some information from unauthorized access, you can change the default permissions of NIS+ tables so that even NIS clients are unable to access them. You can also rearrange the membership of NIS+ groups and the permissions of NIS+ structural objects to align with administrative responsibilities.

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. Workstations, 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; it is described in Solaris Naming Setup and Configuration Guide.

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 to NIS+.

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.

Decommission NIS servers.

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.

Evaluate NIS+ performance.

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.

Clean up new 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.

This completes your transition to NIS+.