test

NIS+ Transition Guide

Designing a Domain Hierarchy

If you are unfamiliar with domain hierarchies, first read Part I of Solaris Naming Administration Guide. 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:

Remember that a domain is not an object, but a reference to a collection of objects. Therefore, a server that supports a domain is not actually associated with the domain but with the domain's directories. A domain consists of four directories: domain, ctx_dir.domain, org_dir.domain, and groups_dir.domain, as shown in Figure 2-1.

Figure 2-1 Server Relationship to Domain

Graphic

Organizational or Geographical Mapping

One of the major benefits of NIS+ is its capability of dividing the namespace into smaller, more manageable parts. You could create a hierarchy of organizations, such as those of the hypothetical corporation, Doc Inc., as shown in Figure 2-2

Figure 2-2 Sample NIS+ Hierarchy by Logical Organization

Graphic

You could also organize the hierarchy by buildings instead of organizations, as shown in Figure 2-3.

Figure 2-3 Sample NIS+ Hierarchy by Physical Location

Graphic

The scheme you select depends primarily on how you prefer to administer the namespace and how clients will tend to use the namespace. For example, if clients of factory.com. will be distributed throughout the buildings of Doc Inc., you should not organize the namespace by building. Because the clients constantly need to have access to other domains, you need to add their credentials to the other domains and you increase traffic flow through the root master server. A better scheme would be to arrange clients by organization. On the other hand, building-sized domains are immune to the reorganizations that require organization-based domains to be restructured.

Do not be limited by the physical layout of the network; an NIS+ namespace does not have to be congruent with the physical network, except where it has to support NIS clients. The number of domains your namespace needs depends on the kind of hierarchy you select.

Consider future expansion plans. Will today's NIS+ root domain be beneath another NIS+ domain in the future? Changing this arrangement would entail a great deal of work. Try to estimate the need for future domains in the namespace and design a structure that can accommodate them without disruption.

Connection to Higher Domains?

Consider whether the NIS+ namespace will be connected to higher domains, such as those of the Internet or DNS. If you currently use NIS under a DNS hierarchy, do you want to replace only the NIS domains or do you want to replace the entire company-wide DNS/NIS structure with an NIS+ namespace?

Client Support in the Root Domain

In the two Doc Inc., domain hierarchies illustrated in Figure 2-2 and Figure 2-3, are all the clients placed in domains beneath the root domain? Or do some belong to the root domain? Is the purpose of the root domain to act only as the root for its subdomains, or will it support its own group of clients? You could place all clients in the lowest layer of domains, and only those used for administration in the root and any intermediate domains. For example, if you implemented the plan in Figure 2-2, all clients would belong to the big.sales.com., small.sales.com., and factory.com. domains, and only clients used for administration would belong to the .com. and sales.com. domains.

Or you could place the clients of general-purpose departments in higher-level domains. For example, in Figure 2-3, where the domain is organized by building, you could put the clients of the Facilities Department in the .com. domain. It is not recommended that you do so, however, because the root domain should be kept simple and relatively unpopulated.

Domain Size Compared With Number of Domains

The current NIS+ implementation is optimized for up to 1000 NIS+ clients per domain and for up to 10 replicas per domain. Such a domain would typically have 10,000 table entries. The limitations come from the current server discovery protocol. If you have more than 1000 NIS+ clients, you should divide your namespace into different domains and create a hierarchy.

Creating a hierarchy, however, may introduce more complexity than you are prepared to handle. You may still prefer to create larger domains rather than a hierarchy; because one large domain requires less administration than multiple smaller domains. Larger domains need fewer skilled administrators to service them, since tasks can be automated more readily (with scripts you create), thus lowering the administrative expense. Smaller domains provide better performance, and you can customize their tables more easily. You also achieve greater administrative flexibility with smaller domains.

Number of Levels

NIS+ was designed to handle multiple levels of domains. Although the software can accommodate almost any number of levels, a hierarchy with too many levels is difficult to administer. For example, the names of objects can become long and unwieldy. Consider 20 to be the limit for the number of subdomains for any one domain and limit the levels of the NIS+ hierarchy to 5.

Security Level

Typically, you will run the namespace at security level 2. However, if you plan to use different security levels for different domains, you should identify them now. Chapter 3, Planning NIS+ Security Measures provides more information about security levels.

Domains Across Time Zones

Geographically-dispersed organizations may determine that organizing their domain hierarchy by functional groups causes a domain to span more than one time zone. It is strongly recommended that you do not have domains that span multiple time zones. If you do need to configure a domain across time zones, be aware that a replica's time is taken from the master server, so the database updates will be synchronized properly, using Greenwich mean time (GMT). This may cause problems if the replica machine is used for other services that are time critical. To make domains across time zones work, the replica's /etc/TIMEZONE file has to be set locally to the master server's time zone when you are installing NIS+. After the replica is running, some time-critical programs may run properly and some may not, depending on whether these programs use universal or local time.

Information Management

It is best to use a model of local administration within centralized constraints for managing the information in an NIS+ namespace. Information should be managed, as much as possible, from within its home domain, but according to guidelines or policies set at the global namespace level. This provides the greatest degree of domain independence while maintaining consistency across domains.