NIS+ Search Paths

A table contains information only about its local domain. For instance, tables in the doc.com. domain contain information only about the users, clients, and services of the doc.com. domain. The tables in the sales.doc.com. domain store information only about the users, clients, and services of the sales.doc.com. domain. And so on.

If a client in one domain tries to find information that is stored in another domain, it has to provide a fully qualified name. As described in NIS+ NIS_PATH Environment Variable if the NIS_PATH environment variable is set up properly, the NIS+ service will do this automatically.

Every NIS+ table can also specify a search path that a server will follow when looking for information. The search path is an ordered list of NIS+ tables, separated by colons:

table:table:table...

The table names in the search path don't have to be fully qualified; they can be expanded just like names entered at the command line. When a server cannot find information in its local table, it returns the table's search path to the client. The client uses that path to look for the information in every table named in the search path, in order, until it finds the information or runs out of names.

Here is an example that demonstrates the benefit of search paths. Assume the following domain hierarchy:

The hosts tables of the lower two domains contain the following information.

Assume now that a user logged onto the luna machine in the sales.doc.com. domain wants to log in remotely to another client. Without providing a fully qualified name, that user can only remotely log in to five machines: localhost, phoebus, europa, ganymede, and the mailhost.

Now assume that the search path of the hosts table in the sales.doc.com. domain listed the hosts table from the manf.doc.com. domain:

hosts.org_dir.manf.doc.com.

Now a user in the sales.doc.com. domain can enter something like rlogin sirius, and the NIS+ server will find it. It will first look for sirius in the local domain, but when it does not find a match, it will look in the manf.doc.com. domain. How does the client know how to find the manf.doc.com. domain? As described in Chapter 2, NIS+: An Introduction, the information is stored in its directory cache. If it is not stored in its directory cache, the client will obtain the information by following the process described in Chapter 2, NIS+: An Introduction.

There is a slight drawback, though, to specifying a search path. If the user were to enter an incorrect name, such as rlogin luba (rather than “luna”), the server would need to look through three tables – instead of just one – before returning an error message. If you set up search paths throughout the namespace, an operation may end up searching through the tables in 10 domains instead of just 2 or 3. Another drawback is a performance loss from having many clients contact more than one set of servers when they need to access NIS+ tables.

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 (for example, mailhost.sales.doc.com.), or NIS+ will return all the mailhosts it finds in all the domains it searches through.

You can specify a table's search path by using the -p option to the nistbladm command, as described in Using the nistbladm Command With NIS+ Tables.