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.
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
Resolving User/Host Name Conflicts
NIS+ cannot distinguish between a human principal and a machine 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+:
jane@jane in the same namespace
patna@peshawar and rani@patna in the same namespace
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.