Transition Principles

Before you begin the transition, you should review the following basic principles:

Consider the Alternatives to Making the Transition Immediately

You can defer the upgrade to NIS+ until after your site has completed its transition to the Solaris operating environment. This allows you to focus your resources on one transition effort at a time. You can continue to run NIS under the Solaris operating environment until you are ready to make the transition to NIS+.

Keep Things Simple

You can take several steps to simplify the transition. While these steps will diminish the effectiveness of NIS+, they will consume fewer servers and less administrative time. After the transition is complete, you can change the NIS+ setup to better suit your needs. Here are some suggestions:

Do not change domain names.
Do not use any hierarchies; keep a flat NIS+ namespace.
Use the NIS-compatibility features.
Use default tables and directory structures.
Do not establish credentials for clients, if you are running the Solaris 2.5 Release or later.

Use a Single Release of Software

Decide which version of the Solaris operating environmenta and NIS+ you will use for the transition. Because there are slight differences between versions, using multiple versions could needlessly complicate the transition process. Choose one version of the Solaris product and use its corresponding version of NIS+.

The current release has the most features (such as setup scripts). Make sure you compile a list of the Solaris operating environment patches that are required for normal operation, and make sure that all servers and clients have the same patches loaded.

Minimize Impact on Client Users

Consider the two major user-related factors: First, users should not notice any change in service. Second, the transition phase itself should cause minimal disruption to client users. To ensure the second consideration, be sure the administrators responsible for each domain migrate their client machines to NIS+, rather than ask the users to implement the migration. This ensures that proper procedures are implemented, that procedures are consistent across client machines, and that irregularities can be dealt with immediately by the administrator.

Things You Should Not Do

Do not change the name services currently provided by NIS or change the way NIS functions.
Do not change the structure of DNS.
Do not change the IP network topology.
Do not upgrade applications that use NIS to NIS+; leave the migration to NIS+ APIs for the future.
Do not consider additional uses for NIS+ during the implementation phase; add them later.

Become Familiar With NIS+

Familiarize yourself with NIS+, particularly with the concepts summarized earlier in this chapter and discussed in the remainder of this book.

One of the best ways to become familiar with NIS+ is to build a prototype namespace. There is no substitute for hands-on experience with the product; administrators need the opportunity to practice in a forgiving test environment.

Note - Do not use your prototype domain as the basis for your actual running NIS+ namespace. Deleting your prototype after you have learned all you can from it will avoid namespace configuration problems. Start anew to create the real namespace after following all the planning steps.

When you create the test domains, make small, manageable domains. See "Creating a Sample NIS+ Namespace", which describes how to plan and create a simple test domain and subdomain (with or without NIS-compatibility mode), using the NIS+ setup scripts.

Note - The NIS+ scripts described in are the recommended method for setting up an NIS+ namespace. The recommended procedure is to first set up your basic NIS+ namespace using the scripts, then customize that namespace for your particular needs, using the NIS+ command set.

Design Your Final NIS+ Namespace

Design the final NIS+ namespace, following the guidelines in"Planning the NIS+ Namespace: Identifying the Goals of Your Administrative Model" . While designing the namespace, do not worry about limitations imposed by the transition from NIS. You can add those later, after you know what your final NIS+ goal is.

Plan Security Measures

NIS+ security measures provide a great benefit to users and administrators, but they require additional knowledge and setup steps on the part of both users and administrators. They also require several planning decisions. "Understanding the Impact of NIS+ Security" describes the implications of NIS+ security and the decisions you need to make for using it in your NIS+ namespace.

Decide How to Use NIS-Compatibility Mode

The use of parallel NIS and NIS+ namespaces is virtually unavoidable during a transition. Because of the additional resources required for parallel namespaces, try to develop a transition sequence that reduces the amount of time your site uses dual services or the extent of dual services within the namespace (for example, convert as many domains as possible to NIS+ only).

"Before You Transition to NIS+: Gauge the Impact of NIS+ on Other Systems" explains the transition issues associated with the NIS-compatibility mode and suggests a way to make the transition from NIS, through NIS compatibility, to NIS+ alone.

Implement the Transition

" Implementing NIS+: An Introduction" provides suggested steps to implement the transition you have planned in the previous steps.

Planning the NIS+ Namespace: Identifying the Goals of Your Administrative Model

When designing the namespace, do not worry about limitations imposed by the transition from NIS. You can modify your NIS+ domain later, after you know how your final NIS+ configuration will look.

Select the model of information administration, such as the domain structure, that your site will use. Without a clear idea of how information at your site will be created, stored, used, and administered, it is difficult to make the design decisions suggested in this section. You could end up with a design that is more expensive to operate than necessary. You also run the risk of designing a namespace that does not suit your needs. Changing the namespace design after it has been set up is costly.

Designing the Namespace Structure

Designing the NIS+ namespace is one of the most important tasks you can perform, since changing the domain structure after NIS+ has been set up is a time-consuming, complex job. It is complex because information, security, and administration policies are woven into the domain structure of the namespace. Rearranging domains requires rearranging information, reestablishing security, and recreating administration policies.

When designing the structure of an NIS+ namespace, consider the factors which are discussed in the following sections of this chapter:

Domain Hierarchy

The main benefit of an NIS+ domain hierarchy is that it allows the namespace to be divided into more easily managed components. Each component can have its own security, information management, and administration policies. It is advisable to have a hierarchy when the number of clients you have exceeds 500, if you want to set up different security policies for a set of users, or if you have geographically distributed sites.

Unless there is a need for a domain hierarchy, not having a hierarchy can simplify your transition to NIS+. When all users were in the same NIS domain, they were directly visible to each other without using fully qualified names. Creating an NIS+ hierarchy, however, puts users in separate domains, which means that the users in one domain are not directly visible to users in another domain, unless you use fully qualified names or paths.

For example, if there are two subdomains, sales.com. and factory.com., created out of the earlier .com. domain, then for user juan in the sales.com. domain to be able to send mail to user myoko in factory.com., he would have to specify her name as myoko@hostname.factory.com. (or myoko@hostname.factory) instead of just myoko, as was sufficient when they were in the same domain. Remote logins also require fully qualified names between domains.

You could use the table path to set up connections between tables in one domain and another domain, but to do so would negate the advantages of having a domain hierarchy. You would also be reducing the reliability of the NIS+ service because now clients would have to depend upon the availability of not only their own home domains, but also of other domains to which their tables are pathed. Using table paths may also slow request response time.

Domain Hierarchy - Solaris 2.6 and Earlier

In Solaris 2.6 and earlier, the NIS+ servers for each subdomain are not part of the subdomain that they serve, with the exception of the root domain. The NIS+ servers are in the parent domain of the subdomain they serve. This relationship of server to subdomain creates problems for applications that expect the servers to be able to get their name-service data from the subdomain. For example, if a subdomain NIS+ server is also an NFS server, then the server does not get its netgroups information from the subdomain; instead, it retrieves the information from its domain, which is the domain above the subdomain; this can be confusing. Another example of when a hierarchy can cause problems is where the NIS+ server is also used by users to log in remotely and to execute certain commands that they cannot execute from their own machines. If you have only a single root domain, you do not have these problems because NIS+ root servers live in the domain that they serve.

Domain Hierarchy - Solaris 9

In the Solaris operating environment, the NIS+ server for a domain can be in the same domain it serves. This allows a server to set its domain name to the same as that used by its clients without affecting the server's ability to securely communicate with the rest of the domain hierarchy.

Designing a Domain Hierarchy

If you are unfamiliar with domain hierarchies, first read Chapter 2, NIS+: An Introduction. It describes NIS+ domain structure, information storage, and security.

After you are familiar with the components of a domain hierarchy, make a diagram of how you expect the hierarchy to look when you are finished. The diagram will be a useful reference when you are in the midst of the setup procedure. At a minimum, you will need to consider the following issues:

Organizational or geographical mapping
Connection to higher domain.
Client support in the root domain.
Domain size compared to number of domains.
Number of levels.
Security levels.
Replicas and number of replicas.
Information management.


26. Transitioning from NIS to NIS+ Suggested Transition Phases


	Transition Principles Before you begin the transition, you should review the following basic principles: Consider the Alternatives to Making the Transition Immediately You can defer the upgrade to NIS+ until after your site has completed its transition to the Solaris operating environment. This allows you to focus your resources on one transition effort at a time. You can continue to run NIS under the Solaris operating environment until you are ready to make the transition to NIS+. Keep Things Simple You can take several steps to simplify the transition. While these steps will diminish the effectiveness of NIS+, they will consume fewer servers and less administrative time. After the transition is complete, you can change the NIS+ setup to better suit your needs. Here are some suggestions: Do not change domain names. Do not use any hierarchies; keep a flat NIS+ namespace. Use the NIS-compatibility features. Use default tables and directory structures. Do not establish credentials for clients, if you are running the Solaris 2.5 Release or later. Use a Single Release of Software Decide which version of the Solaris operating environmenta and NIS+ you will use for the transition. Because there are slight differences between versions, using multiple versions could needlessly complicate the transition process. Choose one version of the Solaris product and use its corresponding version of NIS+. The current release has the most features (such as setup scripts). Make sure you compile a list of the Solaris operating environment patches that are required for normal operation, and make sure that all servers and clients have the same patches loaded. Minimize Impact on Client Users Consider the two major user-related factors: First, users should not notice any change in service. Second, the transition phase itself should cause minimal disruption to client users. To ensure the second consideration, be sure the administrators responsible for each domain migrate their client machines to NIS+, rather than ask the users to implement the migration. This ensures that proper procedures are implemented, that procedures are consistent across client machines, and that irregularities can be dealt with immediately by the administrator. Things You Should Not Do Do not change the name services currently provided by NIS or change the way NIS functions. Do not change the structure of DNS. Do not change the IP network topology. Do not upgrade applications that use NIS to NIS+; leave the migration to NIS+ APIs for the future. Do not consider additional uses for NIS+ during the implementation phase; add them later. Become Familiar With NIS+ Familiarize yourself with NIS+, particularly with the concepts summarized earlier in this chapter and discussed in the remainder of this book. One of the best ways to become familiar with NIS+ is to build a prototype namespace. There is no substitute for hands-on experience with the product; administrators need the opportunity to practice in a forgiving test environment. Note - Do not use your prototype domain as the basis for your actual running NIS+ namespace. Deleting your prototype after you have learned all you can from it will avoid namespace configuration problems. Start anew to create the real namespace after following all the planning steps. When you create the test domains, make small, manageable domains. See "Creating a Sample NIS+ Namespace", which describes how to plan and create a simple test domain and subdomain (with or without NIS-compatibility mode), using the NIS+ setup scripts. Note - The NIS+ scripts described in are the recommended method for setting up an NIS+ namespace. The recommended procedure is to first set up your basic NIS+ namespace using the scripts, then customize that namespace for your particular needs, using the NIS+ command set. Design Your Final NIS+ Namespace Design the final NIS+ namespace, following the guidelines in"Planning the NIS+ Namespace: Identifying the Goals of Your Administrative Model" . While designing the namespace, do not worry about limitations imposed by the transition from NIS. You can add those later, after you know what your final NIS+ goal is. Plan Security Measures NIS+ security measures provide a great benefit to users and administrators, but they require additional knowledge and setup steps on the part of both users and administrators. They also require several planning decisions. "Understanding the Impact of NIS+ Security" describes the implications of NIS+ security and the decisions you need to make for using it in your NIS+ namespace. Decide How to Use NIS-Compatibility Mode The use of parallel NIS and NIS+ namespaces is virtually unavoidable during a transition. Because of the additional resources required for parallel namespaces, try to develop a transition sequence that reduces the amount of time your site uses dual services or the extent of dual services within the namespace (for example, convert as many domains as possible to NIS+ only). "Before You Transition to NIS+: Gauge the Impact of NIS+ on Other Systems" explains the transition issues associated with the NIS-compatibility mode and suggests a way to make the transition from NIS, through NIS compatibility, to NIS+ alone. Implement the Transition " Implementing NIS+: An Introduction" provides suggested steps to implement the transition you have planned in the previous steps. Planning the NIS+ Namespace: Identifying the Goals of Your Administrative Model When designing the namespace, do not worry about limitations imposed by the transition from NIS. You can modify your NIS+ domain later, after you know how your final NIS+ configuration will look. Select the model of information administration, such as the domain structure, that your site will use. Without a clear idea of how information at your site will be created, stored, used, and administered, it is difficult to make the design decisions suggested in this section. You could end up with a design that is more expensive to operate than necessary. You also run the risk of designing a namespace that does not suit your needs. Changing the namespace design after it has been set up is costly. Designing the Namespace Structure Designing the NIS+ namespace is one of the most important tasks you can perform, since changing the domain structure after NIS+ has been set up is a time-consuming, complex job. It is complex because information, security, and administration policies are woven into the domain structure of the namespace. Rearranging domains requires rearranging information, reestablishing security, and recreating administration policies. When designing the structure of an NIS+ namespace, consider the factors which are discussed in the following sections of this chapter: Domain Hierarchy The main benefit of an NIS+ domain hierarchy is that it allows the namespace to be divided into more easily managed components. Each component can have its own security, information management, and administration policies. It is advisable to have a hierarchy when the number of clients you have exceeds 500, if you want to set up different security policies for a set of users, or if you have geographically distributed sites. Unless there is a need for a domain hierarchy, not having a hierarchy can simplify your transition to NIS+. When all users were in the same NIS domain, they were directly visible to each other without using fully qualified names. Creating an NIS+ hierarchy, however, puts users in separate domains, which means that the users in one domain are not directly visible to users in another domain, unless you use fully qualified names or paths. For example, if there are two subdomains, `sales.com.` and `factory.com.`, created out of the earlier `.com.` domain, then for user `juan` in the `sales.com.` domain to be able to send mail to user `myoko` in `factory.com.`, he would have to specify her name as `myoko@hostname.factory.com.` (or `myoko@hostname.factory`) instead of just `myoko`, as was sufficient when they were in the same domain. Remote logins also require fully qualified names between domains. You could use the table path to set up connections between tables in one domain and another domain, but to do so would negate the advantages of having a domain hierarchy. You would also be reducing the reliability of the NIS+ service because now clients would have to depend upon the availability of not only their own home domains, but also of other domains to which their tables are pathed. Using table paths may also slow request response time. Domain Hierarchy - Solaris 2.6 and Earlier In Solaris 2.6 and earlier, the NIS+ servers for each subdomain are not part of the subdomain that they serve, with the exception of the root domain. The NIS+ servers are in the parent domain of the subdomain they serve. This relationship of server to subdomain creates problems for applications that expect the servers to be able to get their name-service data from the subdomain. For example, if a subdomain NIS+ server is also an NFS server, then the server does not get its netgroups information from the subdomain; instead, it retrieves the information from its domain, which is the domain above the subdomain; this can be confusing. Another example of when a hierarchy can cause problems is where the NIS+ server is also used by users to log in remotely and to execute certain commands that they cannot execute from their own machines. If you have only a single root domain, you do not have these problems because NIS+ root servers live in the domain that they serve. Domain Hierarchy - Solaris 9 In the Solaris operating environment, the NIS+ server for a domain can be in the same domain it serves. This allows a server to set its domain name to the same as that used by its clients without affecting the server's ability to securely communicate with the rest of the domain hierarchy. Designing a Domain Hierarchy If you are unfamiliar with domain hierarchies, first read Chapter 2, NIS+: An Introduction. It describes NIS+ domain structure, information storage, and security. After you are familiar with the components of a domain hierarchy, make a diagram of how you expect the hierarchy to look when you are finished. The diagram will be a useful reference when you are in the midst of the setup procedure. At a minimum, you will need to consider the following issues: Organizational or geographical mapping Connection to higher domain. Client support in the root domain. Domain size compared to number of domains. Number of levels. Security levels. Replicas and number of replicas. Information management.