Solaris Naming Administration Guide

Federated Naming Service

Within the Solaris environment, name services are integrated into other services such as the file system, the network information service, the mail system, and the calendar service. For example, the file system includes a naming system for files and directories; NIS+ service combines a naming system with a specialized information service.

Without FNS, users of the Solaris environment must use different, inconsistent names to refer to objects. For example: you might use the name jsmith@admin to send mail to Joan, the name jsmith@altair to access her calendar, and the name /home/jsmith/.cshrc to reach a file in her home directory. This disparity makes it hard for users to formulate names and hard for applications to automatically generate names on behalf of users. FNS policies define a coherent way for naming these objects.

FNS and Application Development

Applications also need naming services and applications in the Solaris environment must often deal with a diversity of name service interfaces. An application might also be exposed to a variety of often incompatible naming systems external to the Solaris environment. Local- and wide-area networks connect a heterogeneous array of hardware and operating systems, increasing the variety of potential interfaces. Not only do these naming interfaces differ widely, but the essential naming operations are often obscure.

FNS simplifies these problems in two ways:

FNS and Composite Names

Some applications use composite names to access objects in the Solaris environment. The commands mail and rcp are examples of such applications.

rcp uses composite names such as sirius:/usr/jsmith/memo, which has two components: the host name sirius and the file name (path) /usr/jsmith/memo. The mail program uses composite names such as jsmith@altair, which has two components: the user name jsmith and the host name altair.

Each application defines its own composition rule for names, parses the composite names, and resolves composite names. Composition rules often differ from one application to another.

Without FNS, the user must remember which applications permit composite naming and which do not. For example, the composite name sirius:/tmp/saleslist is accepted by the rcp command, but not by the cp command.

Without FNS, the user must also remember the different composition rules used among different applications. Applications that support composite names on their own can use only a small and specific set of naming systems, and must be changed whenever a new type of naming system is added.

Incorporating a uniform policy for composite naming into the computing platform permits any application to support composite names in a uniform way. The application passes one name to one interface.

FNS Policy Principles

The following principles were used to arrive at FNS policies: