Identify the Goals of Your Administrative Model

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.

Design 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 would require rearranging information, reestablishing security, and recreating administration policies.

When designing the structure of an NIS+ namespace, consider the following factors:

• The domain hierarchy
• Domain names
• The mail environment

The 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 if 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 will simplify your transition to NIS+ because 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 within the parent domain of the subdomain they serve. This relationship of server to subdomain creates problems for those 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 would not get its netgroups information from the subdomain, but instead retrieve the information from its domain, which is the domain above the subdomain; this can be confusing. Another example of when a hierarchy could cause problems would be where the NIS+ server was also used by users to log in remotely and to execute certain commands that they could not execute from their own workstations. If you have only a single root domain, you will not have these problems because NIS+ root servers live in the domain that they serve.

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 will not be directly visible to users in another domain unless you use fully qualified names or paths. For example, if there are two subdomains, sales.wiz.com. and eng.wiz.com., created out of the earlier wiz.com. domain, then for user "joe" in the sales.wiz.com. domain to be able to send mail to user "jane" in eng.wiz.com., he would have to specify her name as jane@hostname.eng.wiz.com. (or jane@hostname.eng) instead of just "jane" 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.

Designing a Domain Hierarchy

To design a domain hierarchy, first read Part I of Name Services Configuration Guide. It describes NIS+ domain structure, information storage, and security.

Once 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

Organizational or Geographical Mapping One of the major benefits of NIS+ is its capability to divide the namespace into smaller, manageable parts. You could create a hierarchy of organizations, such as those of the hypothetical corporation, Wizard, Inc.:

Figure 2-1 Sample NIS+ Hierarchy by Logical Organization

You could also organize the hierarchy by buildings instead of organizations:

Figure 2-2 Sample NIS+ Hierarchy by Physical Location

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 eng.wiz.com. will be distributed throughout the buildings of Wizard, Inc., you should not organize the namespace by building. Since the clients would need to constantly have access to other domains, you would need to add their credentials to the other domains and you would increase traffic flow through the root master server. A better scheme would be to arrange them 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, since an NIS+ namespace does not have to be congruent with the physical network, except for situations 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 the NIS domains only or do you want to replace the entire companywide DNS/NIS structure with an NIS+ namespace?

Client Support in the Root Domain In the two Wizard, Inc., domain hierarchies illustrated in Figure 2-1 and Figure 2-2 on page 14, 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 only to act 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 intermediate domains. For example, if you implemented this plan in the first illustration, all clients would belong to the big.sales.wiz.com., small.sales.wiz.com., and eng.wiz.com. domains, and only clients used for administration would belong to the wiz.com. and sales.wiz.com. domains.

Or you could place the clients of general-purpose departments in higher-level domains. For example, in the second illustration, Figure 2-2 on page 14, where the domain is organized by building, you could put the clients of the Facilities Department in the wiz.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 do. 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 would be difficult to administer. For example, the names of objects could 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, "Selecting NIS+ Security Measures," provides more information about security levels.

Replicas and Number of Replicas Any one domain should have no more than 10 replicas because of the increased network traffic and server load that occur when information updates are propagated to the replicas. Determining the number of replicas a domain requires depends on other factors as well. They are:

• The physical location of the servers
• The number of subnets in a domain
• Whether there are NIS clients in the NIS+ namespace

You should create a minimum of two servers (one master and one replica) for every domain and at least one replica for every physical location. You do not need a replica for every subnet, unless you have Solaris 1.x NIS clients and you want NIS+ servers in NIS-compatibility mode to support the NIS clients. NIS clients do not have access to servers that are not on the same subnet. The only exception are the Solaris 2.x NIS clients, which can use ypinit (1M) to specify a list of NIS servers. The netmask number in these cases would have to be set appropriately.

One way you can have a sufficient number of replicas per domain without using a multiplicity of machines is to create multi-homed servers. A multi-homed server is a machine with multiple ethernet or network interfaces. A multi-homed server can serve multiple subnets in a domain.

If the domain hierarchy that you design spans a WAN link, it would be prudent to replicate the domain on either side of the WAN link--with a master server on one side and a replica on the other. This could possibly enable clients on the other side of the link to continue with NIS+ service even if the WAN link were temporarily disabled. Putting servers on either side of a WAN, however, does change the structure of a namespace that is organized by group function rather than by physical layout, since the replica might possibly physically reside within the geographic perimeter of a different domain.

Domains Across Time Zones Geographically dispersed organizations may determine that organizing their domain hierarchy by functional groups would cause 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 will be taken from the master server, so the database updates will be synchronized properly, using universal (Greenwich Mean) time. 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 locally set to the master server's time zone when you are installing NIS+. Once 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.

Domain Names

Consider name length and complexity. First, choose names that are descriptive. "Sales" is considerably more descriptive than "BW23A." Second, choose short names. Avoid appending a long string such as

"EmployeeAdministrationServices.WizardCorporation" to object names when you administer the namespace.

A domain name is formed from left to right, starting with the local domain and ending with the root domain. For example:

Figure 2-3 Domain Names Syntax

The first line above shows the name of the root domain. The root domain must always have at least two labels and must end in a dot. The second label can be an Internet domain name, such as "Com." The second line above shows the name of a lower-level domain.

Also consider implications of particular names for email domains, both within the company and over the Internet.

Depending on the migration strategy chosen, it could be a viable alternative to change domain names on NIS to the desired structure, then migrate to NIS+ domain by domain.

The Email Environment

Because NIS+ can have a domain hierarchy while NIS has a flat domain space, changing to NIS+ can have effects on your mail environment. With NIS, only one mailhost is required. If you use a domain hierarchy for NIS+, you may need one mailhost for each domain in the namespace because names in separate domains may no longer be unique.

Therefore, the email addresses of clients who are not in the root domain may change. As a general rule, client email addresses can change when domain names change or when new levels are added to the hierarchy.

In Solaris 2.x, these changes required a great deal of work. Later releases provided several sendmail enhancements to make the task easier. In addition, NIS+ provides a sendmailvars table. The sendmail program first looks at the sendmailvars table (see Table 2-1 on page 25), then examines the local sendmail.cf file.

---

Note - Be sure that mail servers reside in the NIS+ domain whose clients they support. Also for performance reasons, do not use paths to direct mail servers to tables in other domains.

---

Consider the impact of the new mail addresses on DNS. You may need to adjust the DNS MX records.

Select the Namespace Servers

Each NIS+ domain is supported by a set of NIS+ servers. The servers store the domain's directories, groups, and tables, and answer requests for access from users, administrators, and applications. Each domain is supported by only one set of servers. However, a single set of servers can support more than one domain.

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 three directories: domain, org_dir.domain, and groups_dir.domain:

Figure 2-4 Server Relationship to Domain

Any Solaris 2.x-based workstation can be an NIS+ server as long as it has its own hard disk of sufficient size. The software for both NIS+ servers and clients is included in the Solaris product. Therefore, any workstation that has a Solaris 2.x release installed can become a server or a client, or both.

When selecting the servers that will support the NIS+ namespace, consider the following factors:

• Supported domains
• Server load
• Disk space and memory requirements
• NIS clients

Supported Domains

When selecting servers, you must differentiate between the requirements imposed by the NIS+ service and those imposed by the traffic load of your namespace.

The NIS+ service requires you to assign at least one server, the master, to each NIS+ domain¹. How many other servers a domain requires is determined by the traffic load, the network configuration, and whether NIS clients are present.

The traffic loads you anticipate will determine the total number of servers used to support the namespace, how much storage and processing speed each will require, and whether a domain needs replicas to ensure its availability. How can you determine how many servers you need?

A good way to begin is by assigning one master server to each domain in the hierarchy:

Figure 2-5 Assigning Servers to Domains

If certain domains must always be available, add two or more replicas to them. Two replicas allow requests to still be answered even if one of the replicas is damaged. Requests may not be answered in a timely manner if a master has only one replica and it is being repaired or updated. A domain with only one

---

1. An NIS+ server is capable of supporting more than one domain, but use this configuration only in small namespaces or testing situations.

replica loses fifty percent of its load capacity when the replica is down. Always add at least one replica to a domain. In small to medium domains, configurations with two to four replicas are normal.

Figure 2-6 Adding Replicas to a Domain

In organizations with many distributed sites, each site often needs its own subdomain. Typically, the subdomain master is placed in a higher-level domain. As a result, there can be a great deal of traffic between point-to-point links. Creating local replicas can speed request response and minimize point-to-point traffic across the link. In this configuration, lookups may be handled locally.

Server Load

NIS+ master servers require fewer replicas than NIS servers did, since NIS+ does not depend on broadcasts on the local subnet.

Putting replicas on both sides of a weak network link (such as wide area links) is recommended. If the link breaks and the networks are decoupled, both sides of the network can still obtain service.

Do not put more than 10 replicas on one domain. If you can, put one on each subnet; otherwise, distribute the servers as best you can and optimize for the best performance. You don't need NIS+ servers on every subnet, unless they support NIS clients. In such cases, you may want to install NIS+ servers on multi-homed machines.

Try to keep fewer than 1000 clients in a domain. NIS+ clients present a higher load on servers than NIS clients. A large number of clients served by only a few servers may impact network performance.

Disk Space and Memory Requirements

How much disk space you need depends on four factors:

• Disk space consumed by the Solaris 2.x software
• Disk space for /var/nis (and /var/yp)
• Amount of memory
• Swap space required for NIS+ server processes

The Solaris 2.x software can require over 220 Mbytes of disk space, depending on how much of it you install. For exact numbers, see SPARC: Installing Solaris Software or x86: Installing Solaris Software. You should also count the disk space consumed by other software the server may use. The NIS+ software itself is part of the Solaris 2.4 distribution, so it does not consume additional disk space.

NIS+ directories, groups, tables, and client information are stored in /var/nis. The /var/nis directory uses about 5 Kbytes of disk space per client. For example purposes only, if a namespace has 1000 clients, /var/nis requires about 5 Mbytes of disk space. However, because transaction logs (also kept in /var/nis) can grow large, you may want additional space per client--an additional 10-15 Mbytes is recommended. In other words, for 1000 clients, allocate 15 to 20 Mbytes for /var/nis. You can reduce this if you checkpoint transaction logs regularly. You should create a separate partition for /var/nis. This separate partition will help during an operating system upgrade.

If you will use NIS+ concurrently with NIS, allocate an equal amount of space to the amount you are allocating to /var/nis for /var/yp to hold NIS maps that you may transfer from NIS.

Although 32 Mbytes is the minimum memory requirement for servers, it is better to equip servers of medium to large domains with at least 64 Mbytes.

You also need swap space equal to three times or more of the size of the NIS+ server process--in addition to the server's normal swap space requirements. The size of the rpc.nisd process as shown by the ps -efl command. Most of this space is used during callback operations or when directories are

checkpointed (with nisping -C) or replicated, because during such procedures an entire NIS+ server process is forked. In no case should you use less than 64 Mbytes of swap space.

Determine Table Configurations

NIS+ tables provide several features not found in simple text files or maps. They have a column-entry structure, accept search paths, can be linked together, and can be configured in several different ways. You can also create your own custom NIS+ tables. When selecting the table configurations for your domains, consider the following factors:

• Differences between NIS+ tables and NIS maps
• Use of custom NIS+ tables
• Table location
• Connections between tables

Differences Between NIS+ Tables and NIS Maps

NIS+ tables differ from NIS maps in many ways, but two of those differences are worth keeping in mind during your namespace design:

• NIS+ uses fewer standard tables than NIS
• NIS+ tables interoperate with /etc files differently than NIS maps did in the SunOS 4.x releases

NIS+ Standard Tables

Review the 17 standard NIS+ tables to make sure they suit the needs of your site. They are listed in Table 2-1 on page 25. Table 2-2 on page 26 lists the correspondence between NIS maps and NIS+ tables.

Do not worry about synchronizing related tables. The NIS+ tables store essentially the same information as NIS maps, but they consolidate similar information into a single table (for example, the NIS+ hosts table stores the same information as the hosts.byaddr and hosts.byname NIS maps). Instead of the key-value pairs used in NIS maps, NIS+ tables use columns and rows. (See Name Services Configuration Guide.) Key-value tables have two columns with the first column being the key and the second column being the

value. Therefore, when you update any information, such as host information, you need only update it in one place, such as the hosts table. You no longer have to worry about keeping that information consistent across related maps.

Note the new name of the automounter tables:

• auto_home (old name: auto.home)
• auto_master (old name: auto.master)

The dots were changed to underscores because NIS+ uses dots to separate directories. Dots in a table name will cause NIS+ to mistranslate names.

To make the transition from NIS to NIS+, you must change the dots in your NIS automounter maps to underscores. You may also need to do this on your clients' automounter configuration files.

Table 2-1

NIS+ Table	Information in the Table
hosts	Network address and hostname of every workstation in the domain
bootparams	Location of the root, swap, and dump partition of every diskless client in the domain
passwd	Password information about every user in the domain
cred	Credentials for principals who belong to the domain
group	The group password, group id, and members of every UNIX group in the domain
netgroup	The netgroups to which workstations and users in the domain may belong
mail_aliases	Information about the mail aliases of users in the domain.
timezone	The time zone of the domain
networks	The networks in the domain and their canonical names
netmasks	The networks in the domain and their associated netmasks
ethers	The ethernet address of every workstation in the domain
services	The names of IP services used in the domain and their port numbers
protocols	The list of IP protocols used in the domain
rpc	The RPC program numbers for RPC services available in the domain

Table 2-1 (Continued)

NIS+ Table	Information in the Table
auto_home	The location of all user's home directories in the domain
auto_master	Automounter map information
sendmailvars	Stores the mail domain

Table 2-2

NIS Map	NIS+ Table	Notes
auto.home	auto_home
auto.master	auto_master
bootparams	bootparams
ethers.byaddr	ethers
ethers.byname	ethers
group.bygid	group	Not the same as NIS+ groups.
group.byname	group	Not the same as NIS+ groups.
hosts.byaddr	hosts
hosts.byname	hosts
mail.aliases	mail_aliases
mail.byaddr	mail_aliases
netgroup	netgroup
netgroup.byhost	netgroup
netgroup.byuser	netgroup
netid.byname	cred
netmasks.byaddr	netmasks
networks.byaddr	networks
networks.byname	networks
passwd.byname	passwd
passwd.byuid	passwd
protocols.byname	protocols

Table 2-2 (Continued)

NIS Map	NIS+ Table	Notes
protocols.bynumber	protocols
publickey.byname	cred
rpc.bynumber	rpc
services.byname	services
ypservers		Not needed.

NIS+ has one new table for which there is no corresponding NIS table: sendmailvars. The sendmailvars table stores the mail domain used by sendmail.

NIS+ Tables Interoperate Differently With /etc Files

The way NIS interacted with /etc files in the SunOS 4.x environment--or other network information services--was controlled by the /etc files, using the +/- syntax. How NIS+, NIS, or DNS interacts with /etc files in the Solaris 2.x release--or other network information services--is determined by the name service switch. A configuration file, /etc/nsswitch.conf, located on every Solaris 2.x client, specifies the sources of information for that client: /etc files, DNS zone files (hosts only), NIS maps, or NIS+ tables. The nsswitch.conf configuration file of NIS+ clients resembles the example in Figure 2-7 on page 28.

Figure 2-7 Sample Name Service Switch File

passwd: files nisplus group: files nisplus hosts: nisplus [NOTFOUND=return] files services: nisplus [NOTFOUND=return] files networks: nisplus [NOTFOUND=return] files protocols: nisplus [NOTFOUND=return] files rpc: nisplus [NOTFOUND=return] files ethers: nisplus [NOTFOUND=return] files netmasks: nisplus [NOTFOUND=return] files bootparams: nisplus [NOTFOUND=return] files publickey: nisplus netgroup: nisplus automount: files nisplus aliases: files nisplus

In other words, for most types of information, the source is first an NIS+ table, then an /etc file.

You can select from three versions of the switch configuration file or you can create your own. For instructions, see Name Services Administration Guide.

Use of Custom NIS+ Tables

Determine which nonstandard NIS maps you use and their purpose. Can they be converted to NIS+ or replaced with NIS+ standard maps?

Some applications may rely on NIS maps. Will they still function the same way with NIS+, and can they function correctly in a mixed environment?

To build a custom table in NIS+, use nistbladm. Remember that you cannot use dots in the table names.

If you want to be able to use NIS+ to support your custom NIS maps, you should create a key-value table, a table with two columns. The first column is the key and the second column is the value. If you then run the NIS+ servers in NIS-compatibility mode, the NIS clients will not notice any change in functionality.

Connections Between Tables

NIS+ tables contain information only about the resources and services in their home domain. If a client tries to find information that is stored in another domain, the client has to provide the other domain name. You can make this "forwarding" automatic by connecting the local table to the remote table. NIS+ tables can be connected in two different ways:

• Through paths
• Through links

Paths and links should not be used if you are going to have NIS clients in the NIS+ namespace, because NIS clients are unable to follow the paths or links to find the appropriate information.

Paths

If information in a particular NIS+ table is often requested by clients in other domains, consider establishing a path from the local NIS+ table to the one in the other domain. For example:

Figure 2-8 Establishing a Path to Tables in a Higher Domain

Such a path would have two main benefits. First, it would save clients in lower domains the trouble of explicitly searching through a second table. Second, it would allow the administrator in the higher-level domain to make changes in one table and render that change visible to clients in other domains. However, such a path would also hurt performance. Performance is especially affected when searches are unsuccessful, because the NIS+ service must search through two tables instead of one. When you use paths, a table lookup now also depends upon the availability of other domains. This dependence can reduce the net availability of your domain. For these reasons, use paths only if you do not have any other solution to your problem.

You should also be aware that since "mailhost" is often used as an alias, when trying to find information about a specific mailhost, you should use its fully qualified name in the search path (for example, mailhost.sales.wiz.com.); otherwise NIS+ will return all the mailhosts it finds in all the domains it searches through.

The path is established in the local table, with the -p option to the nistbladm command. To change a table's path, you must have modify access to the table object. To find out what a table's search path is, use the niscat -o command (you must have read access to the table).

Links

Links between tables produce an effect similar to paths, except that the link involves a search through only one table: the remote table. With a search path, NIS+ first searches the local table, and only if it is unsuccessful does it search the remote table. With a link, the search moves directly to the remote table. In fact, the remote table virtually replaces the local table.

The benefit of a link is that it allows a lower domain to access the information in a higher domain without the need to administer its own table.

To create a link, use the nisln command. You must have modify rights to the table object.

Deciding whether to use a path or to link NIS+ tables in a domain is a complex decision, but here are some basic principles to keep in mind:

• Every domain must have access to every standard table.
• Volatile, frequently accessed data should be located lower in the hierarchy. Such data should be located closer to where it is used most often.

• Data that is accessed by several domains should be located higher in the hierarchy, unless the domains need to be independent.
• The lower in the hierarchy you place data, the easier it will be to administer autonomously.
• Only NIS+ clients can see tables connected by paths and links. They cannot be seen by NIS clients.

Figure 2-9 summarizes this principle.

Figure 2-9 Information Distribution Across an NIS+ Hierarchy