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.

Examine All Information Source Files

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, then add them back later after NIS+ is installed, than to proceed with the scripts and possibly corrupt data.

Remove the "." from Host Names

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 hostnames. You can convert hostname dots to hyphens (-). For example, you cannot have a machine named sales.alpha. You can convert that name to sales-alpha. (See the hosts man page for detailed information on allowable hostnames.)

Remove the "." from NIS Map Names

As described in Planning the NIS+ Namespace: Identifying the Goals of Your Administrative Model, 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.

Note - 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.

Document Your Current NIS Namespace

Documenting your current configuration will give you a clear point of departure for the transition. Make a list of the following items:

• Name and location of all current NIS domains and networks

• Host name and location of all current NIS servers, both master and slave

• Configuration of all current NIS servers, including:

  • Host name

  • CPU type

  • Memory size

  • Disk space available

  • Name of administrators with root access

• Nonstandard NIS maps

Correlate the list of your NIS clients with their eventual NIS+ domains. They must be upgraded to the current Solaris operating environment.

Create a Conversion Plan for Your NIS Servers

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 might 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 NIS+: An Introduction, 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). When you have identified the servers you plan to convert to NIS+ service, upgrade them to NIS+ requirements (see Server Memory Requirements).

Implementing NIS+: An Introduction

After you have performed the tasks described in the previous sections, 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 Chapter 4, Configuring NIS+ With Scripts for more explanation of NIS+ structure and concepts. Then perform the following steps:

1. 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.)

2. 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.

3. 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 machines for the administrators who support the root domain. NIS+ servers should never be an individual's machine.

4. 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.

5. Add administrators to root domain groups.

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

6. 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.

7. 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.

8. 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+.

9. 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.

10. 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.

11. 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.