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+ 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 NIS+ Standard Tables. Table 26–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 Table 26–6.) 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:

• 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 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. Refer to the following table:

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 the following example.

Example 26–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 Chapter 1, The Name Service Switch.

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:

• Through paths.

• Through links.

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. Refer to the following figure:

Figure 26–8 Establishing a Path to Tables in a Higher Domain

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:

• 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 is to administer autonomously.

• Only NIS+ clients can see tables connected by paths and links. They cannot be seen by NIS clients, as illustrated by the following figure:

Figure 26–9 Information Distribution Across an NIS+ Hierarchy