Solaris Naming Administration Guide

Chapter 21 Federated Naming Overview

This chapter describes the Federated Naming Service (FNS) which is Sun's implementation of the X/Open XFN federated naming standard.


Different name services are often embedded in different applications and services in a computing environment. Working with different name services presents significant difficulties to the application developer. Most applications are designed to use a single name service and have very limited access to objects in a distributed computing environment. Because different applications use different name services they expect names to be composed differently. They often use different names for what the user considers very similar objects. For example, you might be able to send mail to your friend Johanna using her name, but be required to use another name, jsmith@altair, to access her calendar.

FNS, Sun's implementation of the XFN standard, allows you to name objects in a uniform way, yet still provide the functionality that applications and developers need.

Note -

In this manual it is important to distinguish between XFN and FNS. The FNS policies include some extensions to XFN policies, and these are explicitly defined with notes. Objects belonging to the XFN programming interface are designated as XFN objects to avoid confusion with other programming interfaces.

The XFN Model

This section describes the XFN naming model from several perspectives.

XFN Architectural Model

The primary services provided by a federated naming system are mapping a composite name to a reference and providing access to attributes associated with a named object. This section defines the elements of the XFN naming model.

Atomic Names

The smallest, indivisible component of a name is called an atomic name. For example, the machine name nismaster or the user name chou. An atomic name may have one or more attributes, or no attributes at all (see "Attributes").


A reference is the information on how to reach an object. A reference contains a list of addresses. An address identifies a communication endpoint (an object). For example, the address of a machine such as, or a user's email address such as

A reference might contain multiple addresses that identify multiple communication endpoints for a single conceptual object or service. For example, a list of addresses might be required because the object is distributed or because the object can be accessed through more than one communication mechanism.

Note -

XFN cannot guarantee specific properties of addresses such as their stability, validity, or reachability. A client might be able to look up a name but not be able to use the returned reference because the client might not have support for any of the necessary communication mechanisms or might lack the necessary network connectivity to reach the address. Further, the address might be invalid from that origin or stale; these issues are the province of the convention between the name's binder, the clients, and the service provider specified in the address.


A context is a set of atomic names bound to references, as shown in Figure 21-1. Every context has an associated naming convention. A context provides a lookup (resolution) operation, which returns the reference, and may provide operations such as binding names, unbinding names, and listing bound names. Contexts are at the heart of the lookup and binding operations.

Figure 21-1 An XFN `Context'



Attributes may be applied to named objects. Attributes are optional. A named object can have no attributes, one attributes, or multiple attributes.

Each attribute has a unique attribute identifier, an attribute syntax, and a set of zero or more distinct attribute values. Attributes are indicated by the dotted lines in Figure 21-1 above.

XFN defines the base attribute interface for examining and modifying the values of attributes associated with existing named objects. These objects can be contexts or any other types of objects. Associated with a context are syntax attributes that describe how the context parses compound names.

The extended attribute interface contains operations that search for specific attributes and that create objects and their associated attributes.

Compound Names

A compound name is a sequence of one or more atomic names. An atomic name in one context can be bound to a reference to another context of the same type, called a subcontext. Objects in the subcontext are named using a compound name. Compound names are resolved by looking up each successive atomic name in each successive context.

A familiar analogy for UNIX users is the file naming model, where directories are analogous to contexts, and path names serve as compound names. Furthermore, contexts can be arranged in a "tree" structure, just as directories are, with the compound names forming a hierarchical namespace.

For example:

Composite Names

A composite name is a name that spans multiple naming systems. Each component is a name from the namespace of a single naming system. Composite name resolution is the process of resolving a name that spans multiple naming systems.

Components are separated by slashes (/) and ordered from left to right, according to XFN composite name syntax. For example, the composite name

has two components, a DNS name ( and a UNIX path name (usr/local/bin).

FNS Namespaces

Atomic names and reference addresses may also be resolved relative to one or more namespaces. By default, FNS provides six namespaces: org (for organization), site, host, user, service, and fs (for files).

FNS policies are used to determine how names associated with namespaces relate to each other. For example; a user is named sergei in the user namespace and is identified as /user/sergei. A calendar application is named in the service namespace and is identified as /service/calendar. With this system, you can then identify Sergei's calendar service as: /user/sergei/service/calendar. (See "Introduction to FNS and XFN Policies" for more information on namespaces and how they are used.)

If an application is expecting you to type a user name, the application can include the namespace identifier user/ in front of names that you enter. If the application needs to name one of the user's services, such as the user's default fax machine, it can append the service namespace and the name of the service (/service/fax), to the input supplied. Hence, a fax tool might take as input the user name jacques and then compose the full name user/jacques/service/fax for the default fax of the user jacques. Similarly, to access a person's calendar, you just need to type the person's user name. The application takes the input, raj, and uses it to construct the composite name, in this case, user/raj/service/calendar.

XFN Links

An XFN link is a special form of a reference that is bound to an atomic name in a context. Instead of an address, a link contains a composite name. Many naming systems support a native notion of link that can be used within the naming system itself. XFN does not specify whether there is any relationship between such native links and XFN links.

Initial Context

Every XFN name is interpreted relative to some context, and every XFN naming operation is performed on a context object. The initial context object provides a starting point for the resolution of composite names. The XFN interface provides a function that allows the client to obtain an initial context.

The policies described in Chapter 22, FNS Policies, specify a set of names that the client can expect to find in this context and the semantics of their bindings. This provides the initial pathway to other XFN contexts.

User's View

Users experience federated naming through applications. Typically, the user does not need to compose or know the full composite name of objects because the application takes care of constructing the composite names. This allows the user to interact with XFN-aware applications in a simple, intuitive, and consistent manner.

File System View

Users and applications also experience federated naming through the file system. The initial context is located under /xfn in the root directory. For example, user ingrid's to_do file has the XFN name, xfn/user/ingrid/fs/to_do.

To read this file, you could type:

% cat /xfn/user/ingrid/fs/to_do

Applications access the files under /xfn just as they do any other files. Applications do not need to be modified in any way, nor do they need to use the XFN API.

Application View

The way that client applications interact with XFN to access different naming systems is illustrated in a series of figures. Figure 21-2 shows an application that uses the XFN API and library.

Figure 21-2 Client Application Interaction With XFN


Figure 21-3 shows the details beneath the API. A name service that is federated is accessed through the XFN client library and a context shared object module. This module translates the XFN calls into name service-specific calls.

Figure 21-3 Details Beneath XFN API


API Usage Model

Many clients of the XFN interface are only interested in lookups. Their usage of the interface amounts to:

Once the client obtains a desired reference from the lookup operation, it constructs a client-side representation of the object from the reference.

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:

FNS in the Solaris Environment

In the Solaris environment, the FNS implementation currently consists of name services implemented on top of:

FNS will become increasingly more visible to Solaris users as more applications and systems use FNS.

Solaris Enterprise-Level Naming Services

An enterprise-level naming service identifies (names) machines (hosts), users and files within an enterprise-level network. FNS also allows naming of organizational units, geographic sites, and application services. An "enterprise-level" network can be a single Local Area Network (LAN) communicating over cables, infra-red beams, or radio broadcast; or a cluster of two or more LANs linked together by cable or direct phone connections. Within an enterprise-level network, every machine is able to communicate with every other machine without reference to a global naming service such as DNS or X.500/LDAP.

FNS currently supports three enterprise-level naming services:

See Chapter 23, FNS and Enterprise Name Services, for administration information regarding FNS and enterprise-level naming services.

FNS and NIS+ Naming

If you are not familiar with NIS+ and its terminology, refer to Part 1 and Glossary of this guide. You will find it helpful to be familiar with the structure of a typical NIS+ environment.

NIS+ is the preferred enterprise-wide information service in the Solaris environment. Both NIS and local files can be used along with NIS+. NIS+ allows an enterprise to be divided into hierarchical organizational levels composed of domains and subdomains.

FNS organization units correspond to NIS+ domains and subdomains. There is one orgunit context for each domain and subdomain.

FNS federates NIS+, NIS, and local files to support naming policies in the Solaris environment. To do this, FNS provides the XFN interface for performing naming operations on organization, site, user, and host objects. It implements these operations using the appropriate programming interface for accessing files, directories, and tables.

Under NIS+, FNS context and attribute data is stored in NIS+ type tables. These tables are stored in NIS+ type directory objects named ctx_dir. There is an ctx_dir directory object for each NIS+ domain and subdomain, residing at the same level as the domain's groups_dir and org_dir directory objects. Thus, the directory object contains FNS tables which store FNS context and attribute data for the domain.

Under NIS+, you use FNS and NIS+ commands to work with the information in FNS tables. Do not edit these tables directly or manipulate them with UNIX commands.

FNS and NIS Naming

NIS is an enterprise-wide information service in the Solaris environment. Local files can be used along with NIS. Under NIS, an enterprise is organized as a single NIS domain.

Each enterprise is a single NIS domain. There is one FNS organizational unit which corresponds to the single NIS domain.

FNS federates NIS and local files to support naming policies in the Solaris environment. To do this, FNS provides the XFN interface for performing naming operations on organization, site, user, and host maps. It implements these operations using the appropriate programming interface for accessing files, directories.

Under NIS, FNS context and attribute data are stored in NIS maps. These maps are stored in a /var/yp/domainname directory on a NIS server. Under NIS, the super user can use FNS commands to work with the information in FNS maps.

NIS Clients Can Update Contexts With FNS if SKI is Running

If certain conditions are met, any NIS client (machine, process, or user) can use FNS commands such as fncreate_fs or fncreate_printer to update the client's own contexts. This allows NIS clients to use FNS commands to update applications such as Printer Administrator, CDE Calendar Manager, Admin Tool and others.

For non-super-users to update their own contexts with FNS commands, the following conditions must be met:

FNS and Files-Based Naming

Files refers to the naming files normally found in a machine's /etc directory. These machine-based files contain UNIX user and password information, host information, mail aliases, and so forth. They also support Solaris-specific data such as the automount maps.

FNS federates local files to support naming policies in the Solaris environment. To do this, FNS provides the XFN interface for performing naming operations on organization, site, user, and host files. It implements these operations using the appropriate programming interface for accessing files, directories.

Under a files-based naming system, FNS context and attribute data is stored in files. These files are stored in a /var/fn directory exported from an NFS file server.

Under a files-based naming system, you use FNS commands to work with the information in FNS files.

Global Naming Services

A global naming service identifies (names) those enterprise-level networks around the world that are linked together via phone, satellite, or other communication systems. This world-wide collection of linked networks is known as the "Internet." In addition to naming networks, a global naming service also identifies individual machines and users within a given network.

FNS currently supports two global naming services:

Note -

You can only federate a global naming service if your enterprise-level name service is NIS+ or NIS. If you are using a files-based name service for your enterprise, you cannot federate either DNS or X.500/LDAP.

See Chapter 26, FNS and Global Naming Systems, for administration information regarding FNS and enterprise-level naming services.


The Internet Domain Name System (DNS) is a hierarchical collection of name servers that provide the world Internet with host and domain name resolution. FNS uses DNS to name enterprise objects globally.

A domain name is the name DNS uses to identify an enterprise-level network (LAN or WAN). Networks using NIS+ permit creation of subdomains within the parent domain, and DNS can identify such subdomains.

Names can be constructed for any enterprise that is accessible on the Internet; consequently, names can also be constructed for objects exported by these enterprises. For more information about FNS and DNS, see "Federating Under DNS".

FNS and X.500

X.500 is a global directory service. Its components cooperate to manage information about objects in a worldwide scope. Such objects include countries, organizations, people, and machines. FNS federates X.500 to enable global access to enterprise name services. You can choose to use one of two APIs to access the X.500 global directory service:

See "Federating Under X.500/LDAP" for information on federating X.500.

FNS and Applications

FNS supports:

FNS File Naming

FNS-based file naming integrates FNS naming into the Solaris file service. FNS-based file naming enables files to be named relative to users, hosts, sites, and organizations, using the FNS policies shared with other non-file applications.

FNS-based file naming gives clients a common view of the global and enterprise-wide file namespaces. Solaris applications that access the file system will, without modification, have access to the file namespaces supported by FNS.

FNS Printer Naming

FNS-based printer naming provides the basic naming support for the unbundled Sun Microsystems Print Client (SSPC). FNS-based printer naming enables printers to be named relative to users, hosts, sites, and organizations, using the FNS policies shared with other non-printing-related applications.

FNS-based printer naming gives clients a common view of the global and enterprise-wide printer namespaces and allows centralized administration of the printer namespaces.

FNS Application Support

Applications that are aware of FNS can expect the namespace to be arranged according to the FNS policies, and applications that bind names in the FNS namespace are expected to follow these policies.

Applications use FNS three ways:

Administering FNS

FNS System administration varies according to the underlying naming service:

The ability of users to make changes to their own user sub-contexts varies according to the underlying naming service:

Troubleshooting and Error Messages

For troubleshooting common FNS problems and solving them, see "FNS Problems and Solutions". FNS error messages are included in Appendix B, Error Messages.