FNS and the Name Service Switch

See Chapter 20, FNS Quickstart and Chapter 21, Federated Naming Overview, for introductory information about the Federated Naming Service.

FNS, the Solaris implementation of the XFN API, can also be used to specify which name service a client is to query for naming information. The XFN API is more general in both the X and Y dimensions than the update getXbyY() interfaces that use the switch file. For example, it can be used to lookup information on both hosts and users, from both NIS+ and NIS. An application can be a client of either getXbyY(), or XFN, or both.

Maintaining Consistency Between FNS and the Switch File

In order to ensure that changes made to namespace data through FNS are always available to clients obtaining namespace information through the switch file, always configure both the switch and FNS to use the same name service.

Namespace Updates

The support for data updates provided by the XFN API is superior to that of the getXbyY() interfaces. Most namespaces are composed of data from multiple sources. A groups namespace, for example, might contain information from both the /etc/group file and the NIS+ group.org_dir object. But the switch file does not provide enough information for an application update routine to identify the source of some particular piece of group data or the source to update.

Because each FNS subordinate namespace comes entirely from a single name service, updates are simple and straightforward because there is no confusion over which name service the update applies to.