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.

• "XFN and FNS"

• "The XFN Model"

• "Federated Naming Service"

• "FNS in the Solaris Environment"

• "Solaris Enterprise-Level Naming Services"

• "FNS and NIS+ Naming"

• "FNS and NIS Naming"

• "FNS and Files-Based Naming"

• "Global Naming Services"

• "FNS and Applications"

• "FNS File Naming"

• "FNS Printer Naming"

• "FNS Application Support"

• "Administering FNS"

• "Troubleshooting and Error Messages"

XFN and FNS

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 johanna@admin.doc.com, 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.

• XFN is X/Open Company, Ltd. Federated Naming standard. XFN is a standard actively supported by organizations such as Sun Microsystems, Inc., IBM, Hewlett-Packard, Digital Equipment Corpaoration, Siemens, and OSF. FNS, the Solaris operating environment implementation of XFN, is compliant with the X/Open Preliminary Specification for Federated Naming (July 1994). Applications that use FNS are portable across platforms because the interface exported by FNS is XFN, a public, open interface endorsed by other vendors and X/Open. The X/Open Co. Ltd. is an international standards organization committed to defining computing standards that are endorsed and adhered to by the major computer vendors.

• FNS provides a method for federating multiple name services under a single, simple uniform interface for the basic naming operations. The service supports resolution of composite names--names that span multiple name systems-- through the naming interface. Each member of a federation has autonomy in its choice of naming conventions, administrative interfaces, and its particular set of operations other than name resolution.

  In the Solaris environment, the FNS implementation consists of a set of enterprise-level name services (see "Solaris Enterprise-Level Naming Services") with specific policies and conventions for naming organizations, users, hosts, sites, and services as well as support for global name services (see "Global Naming Services") such as DNS and X.500.

  FNS is useful for the following reasons:

  • A single uniform naming interface is provided to clients for accessing different name services. As a consequence, the addition of new name services does not require changes to applications or to existing member name services.

  • Names can be composed in a uniform way, and the resulting composite names can have any number of components.

  • Coherent naming is encouraged through the use of shared contexts and shared names.

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").

References

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 nismaster.doc.com, or a user's email address such as chou@doc.com.

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.

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.

Contexts

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

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:

• UNIX: usr/local/bin. UNIX atomic names are ordered from left to right and are delimited by slash (/) characters. The name usr is bound to a context in which local is bound. The name local is bound to a context in which bin is bound.

• DNS: sales.doc.com. DNS atomic names are ordered from right to left, and are delimited by dot (.) characters. The domain name com is bound to a context in which doc is bound. doc is bound to a context in which sales is bound.

• X.500: c=us/o=doc/ou=sales. An X.500 atomic name comprises an attribute type and an attribute value. Atomic names are known as relative distinguished names in X.500. In this string representation, X.500 atomic names are ordered from left to right, and are delimited by slash (/) characters. An attribute type is separated from an attribute value by an equal sign (=) character. Abbreviations are defined for commonly used attribute types (for example, "c" represents country name). The country name US is bound to a context in which doc is bound. The organization name doc is bound to a context in which the organizational unit name sales is bound.

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

sales.doc.com/usr/local/bin

has two components, a DNS name (sales.doc.com) 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:

• Obtaining the initial context

• Looking up one or more names relative to the initial context

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:

• It provides a single standard interface to the basic naming functions that developers can use for their applications.

• It permits changes or additions to network name services without changing existing applications.

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:

• When it is natural to name other objects relative to a certain object, that object should provide a naming context. For example, because it is natural to want to name various things relative to a user, a user object should be a naming context.

• It should be possible to compose names using common components. This reduces the number of names that users need to remember and makes it easier for applications and users to construct names based on their knowledge of common components and how they can be logically composed.

• Names should be intuitive and self-evident. For example, the FNS name /user/wong/service/calendar clearly identifies the calendar service used by Wong. In contrast, the calendar name wong@deneb names the host (deneb) where the calendar service for Wong is being provided. But to other users, there is no obvious connection between the user's calendar and a host. The host name is extraneous and difficult to discover and remember.

• Never use two contexts when one context will do. In the example above, we would like to name a mail address, a calendar, and a file's directory relative to the user wong. Sharing contexts and their names make naming more coherent and simplifies administration.

FNS in the Solaris Environment

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

• Enterprise-level name services such NIS+, NIS, and/or local files. (See "Solaris Enterprise-Level Naming Services", below.)

• File naming, printer naming, and support for other applications. (see Chapter 25, Administering File Contexts.)

• Global-level naming systems using DNS and X.500/LDAP. (See Chapter 26, FNS and Global Naming Systems.)

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:

• NIS+. See "FNS and NIS+ Naming", "How FNS Policies Relate to NIS+", and "Advanced FNS and NIS+ Issues".

• NIS. See "FNS and NIS Naming", "How FNS Policies Relate to NIS", and "Advanced FNS and NIS Issues".

• Files. See "FNS and Files-Based Naming", "How FNS Policies Relate to Files-Based Naming", and "Advanced FNS and File-Based Naming Issues".

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 ctx_dir.sales.doc.com. contains FNS tables which store FNS context and attribute data for the sales.doc.com 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:

• Secure Key_management Infrastructure (SKI) must be available on the NIS master server.

• The fnsypd daemon must be running on the NIS master server. This daemon must be started by someone with super user privileges.

• A client user or machine is only allowed to update its own context.

• The client must be authorized to perform the requested update.

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:

• DNS. See "FNS and DNS", below and "Federating Under DNS".

• X.500/LDAP. See "FNS and X.500", below and "Federating Under X.500/LDAP".

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.

FNS and DNS

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:

• XDS/XOM API

• LDAP (Lightweight Directory Access Protocol) API.

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

FNS and Applications

FNS supports:

• Solaris NFS file service (see "FNS File Naming", below).

• Printer naming (see "FNS Printer Naming").

• Other applications (see "FNS Application Support").

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:

• Applications can be direct clients of the FNS interface and policies. Application-level utilities such as the file system, the printing service, and the desktop tools (calendar manager, file manager) are examples of clients that use the FNS interface directly.

• Applications can use FNS through existing interfaces. A significant proportion of FNS use is through existing application programming interfaces. For example, consider a UNIX application that obtains a file name that it later supplies to the UNIX open() function. With FNS support for resolution of file names, the application need not be aware that the strings it deals with are composite names rather than the traditional local path names. Many applications can thereby support the use of composite names without modification.

• Systems can export the FNS interface. Naming systems, such as DNS and X.500, and naming systems embedded in other services, like the file system and printing service, are examples of naming systems that export the FNS interface.

Administering FNS

FNS System administration varies according to the underlying naming service:

• NIS+. Under NIS+, FNS system administration tasks can only be performed by those with authorization to do so. The usual method of granting system administration privileges is to create an NIS+ group and assign that group the necessary privileges for that domain. Any member of the group can then perform system administration functions.

• NIS. Under NIS, FNS administration tasks must be performed by root on the NIS master server.

• Files. Under a files-based naming system, FNS administration tasks must be performed by someone with root access to the /var/fn directory.

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

• NIS+. Under NIS+, a user's context (and associated sub-contexts) are owned by them. When logged in as an NIS+ principle, users who have the appropriate credentials and privileges can make changes to their own context using the fncreate, fnbind, fnunbind, and similar commands.

• NIS. Under NIS, users cannot make any changes to any FNS data. Only those with root access on the NIS master server can change FNS data.

• Files. Under a files-based naming system, users own their own contexts. Standard UNIX access controls apply to FNS files.

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.