test

NIS+ Transition Guide

Chapter 2 Planning the NIS+ Namespace

This chapter provides general guidelines and recommendations for designing the final NIS+ namespace your site will have.

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

In Solaris 7, 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 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.

Domain Names

Consider name length and complexity. First, choose names that are descriptive. For example, "Sales" is considerably more descriptive than "BW23A." Second, choose short names. To make your administrative work easier, avoid long names such as administration_services.corporate_headquarters.doc.com.

A domain name is formed from left to right, starting with the local domain and ending with 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."

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

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

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 mail host is required. If you use a domain hierarchy for NIS+, you may need one mail host for each domain in the namespace because names in separate domains may be no longer 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 earlier Solaris releases, these changes required a great deal of work. This release 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-5), then examines the local sendmail.cf file.

Note -

Be sure that mail servers reside in the NIS+ domain whose clients they support. 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.

Determining Server Requirements

Each NIS+ domain is supported by a set of NIS+ servers. Each set contains one master and one or more replica servers. These 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. While a single set of servers can support more than one domain, this is not recommended.

The NIS+ service requires you to assign at least one server, the master, to each NIS+ domain. How many replica servers a domain requires is determined by the traffic load, the network configuration, and whether NIS clients are present. The amount of server memory, disk storage, and processor speed is determined by the number of clients and the traffic load they place on the servers.

Any workstation, running in the Solaris operating environment, 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 the Solaris operating environment installed can become a server or a client, or both.

When determining what servers are needed to support your NIS+ namespace, consider these factors, discussed in the following sections:

Number of Supported Domains

To begin, you assign one master server to each domain in the hierarchy. Figure 2-4 shows one possible assignment.

Figure 2-4 Assigning Servers to Domains

Graphic

Add one or more replicas to each domain. Replicas allow requests to be answered even if the master server is temporarily out of service. (See "Designing the Namespace Structure" for information on how many replicas to use.)

Figure 2-5 Adding Replicas to a Domain

Graphic

Number of Replica Servers

The optimum number of servers (master plus replicas) for a domain is determined by a number of factors:

One way you can have a sufficient number of replicas per domain without using a multiplicity of machines is to create multihomed servers. A multihomed server is a machine with multiple ethernet or network interfaces. A multihomed server can serve multiple subnets in a domain. (While it is possible to have a master or replica serve multiple domains, that is not recommended.)

Server Speed

The faster the server, the better NIS+ performs. (However, at this time NIS+ servers cannot take advantage of SMP multithreaded hardware.) Your NIS+ servers should be as powerful, or more powerful, than your average client. Using older machines as servers for newer clients is not recommended.

In addition to server speed, many other factors affect NIS+ performance. The numbers and kinds of users and hosts, the kinds of applications being run, network topology, load densities, and other factors, all affect NIS+ performance. Thus, no two networks can expect identical performance from the same server hardware.

The benchmark figures presented in Table 2-2 below, are for comparison purposes only; performance on your network may vary. These benchmark figures are based on a test network with typical table sizes of 10,000 entries. See Table 2-2.

Table 2-2 Hardware Speed Comparison NIS+ Operations

Machine 

Number of Match Operations Per Second 

Number of Add Operations Per Second 
 SS5-110 400 6
 SS20-50 440 6
 PPro-200 760 13
 Ultra-167 800 11
 Ultra-200 1270  8

Server Memory Requirements

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

Ideally, an NIS+ server should have enough memory to hold all the entries of all the searchable columns of all the operative NIS+ tables in RAM at one time. In other words, optimal server memory is equal to the total memory requirements of all the NIS+ tables.

For illustration purposes, Table 2-3 shows memory requirements for the netgroup table with five searchable columns, and Table 2-4 shows approximate memory requirements for the passwd, host, and cred tables.

Table 2-3 Server Memory Required for netgroups Table

Number of Entries 

Server Memory Usage in Mbytes 
 6,000 4.2
 60,000 39.1
 120,000 78.1
 180,000 117.9
 240,000 156.7
 300,000 199.2

Table 2-4 Approximate Memory Required for passwd Table

Number of Entries 

Server Memory Usage in Mbytes 
 6,000 3.7
 60,000 31.7
 120,000 63.2
 180,000 94.9
 240,000 125.8
 300,000 159.0
 1,000,000 526.2

For the other tables, you can estimate the memory size by multiplying the estimated number of entries times the average number of bytes per entry for each searchable column. For example, suppose you have a table with 10,000 entries and two searchable columns. The average number of bytes per entry in the first column is 9, the average number of bytes per entry in the second column is 37. Your calculation is: (10,000x9)+(10,000x37)=460,000.

Note -

When estimating the number of entries in the cred table, keep in mind that every user will have two entries (one for the user's Local credential and one for the user's DES credential). Each machine will have only one entry.

See "NIS+ Standard Tables" for the number of searchable columns in each of the standard NIS+ tables.

Server Disk Space Requirements

How much disk space you need depends on four factors:

The Solaris operating environment can require over 220 Mbytes of disk space, depending on how much of it you install. For exact numbers, see your Solaris installation guides. You should also count the disk space consumed by other software the server might use. The NIS+ software itself is part of the Solaris 2.6 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 also 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 space equal to the amount you are allocating to /var/nis for /var/yp to hold the NIS maps that you transfer from NIS.

You also need swap space equal to twice the size of rpc.nisd--in addition to the server's normal swap space requirements. To see the amount of memory being used by rpc.nisd on your system, run the nisstat command. See the rpc.nisd man page for more information. 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.

Determining 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 discussed in the following sections:

Differences Between NIS+ Tables and NIS Maps

NIS+ tables differ from NIS maps in many ways, but two of those differences should be kept in mind during your namespace design:

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-5. Table 2-6 lists the correspondences 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 Solaris Naming Setup and 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 names of the automounter tables:

The dots were changed to underscores because NIS+ uses dots to separate directories. Dots in a table name can cause NIS+ to mistranslate names. For the same reason, machine names cannot contain any dots. You must change any machine name that contains a dot to something else. For example, a machine named sales.alpha is not allowed. You could change it to sales_alpha or salesalpha or any other name that does not contain a dot.

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. See Table 2-5.

Table 2-5 NIS+ Tables

NIS+ Table 

Information in the Table 

hosts

Network address and host name 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 

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-6 Correspondences Between NIS Maps and NIS+ Tables

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

 

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 manner in which NIS and other network information services interacted with /etc files in the SunOS 4.x environment was controlled by the /etc files using the +/- syntax. How NIS+, NIS, DNS and other network information services interact with /etc files in the Solaris operating environment is determined by the name service switch. The switch is a configuration file, /etc/nsswitch.conf, located on every Solaris operating environment client. It 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 simplified version in Example 2-1.

Example 2-1 Simplified Name Service Switch File


passwd: files

group: compat

group_compat: nisplus

hosts: nisplus dns [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. For the passwd and group entries, the sources can either be network files or from /etc files and NIS+ tables as indicated by +/- entries in the files.

You can select from three versions of the switch-configuration file or you can create your own. For instructions, see Solaris Naming 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 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:

Do not use paths and links 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. See Figure 2-6.

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

Graphic

Such a path has two main benefits. First, it saves clients in lower domains the trouble of explicitly searching through a second table. Second, it allows 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 can 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 mail host, you should use its fully qualified name in the search path (for example, mailhost.sales.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 a table's search path, 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:

Figure 2-7 summarizes this principle.

Figure 2-7 Information Distribution Across an NIS+ Hierarchy

Graphic

Resolving User/Host Name Conflicts

NIS+ cannot distinguish between a human principal and a workstation principal when requests are made. Therefore, all user names must be different from machine names in the same namespace. In other words, within a given namespace, no user can have the same user name as a machine name, and no machine can have the same name as any user ID.

For example, under NIS it was acceptable to have a user with the login name of irina whose local machine is also named irina. Her network address would be irina@irina. This is not allowed under NIS+. When the site is converted to NIS+, either the user will have to change her login name or her machine name. Identical user and machine names are a problem even when the machine with the duplicate name does not belong to the user with the same name. The following examples illustrate duplicate name combinations not valid with NIS+:

The best solution to this problem is to check all /etc files and NIS maps before you use the data to populate NIS+ tables. If you find duplicate names, change the machine names rather than the login names, and later create an alias for the machine's old name.