System Administration Guide: Naming and Directory Services (FNS and NIS+)

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 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:

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:

Table 26–5 NIS+ Tables

NIS+ Table 

Information in the Table 

hosts

Network address and host name of every machine 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 machines 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 machine 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 26–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 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:

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

Diagram shows an established path to higher domains

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 26–9 Information Distribution Across an NIS+ Hierarchy

Diagram shows information distribution across a NIS+ hierarchy