Namespaces in the Enterprise

This section introduces the types of namespaces within an enterprise:

• Organizational units
• Sites (an extension to the XFN policy)
• Hosts
• Users
• Services
• Files
• Printers (an extension to the XFN policy)

Some of these namespaces, such as users and hosts, can appear more than once in a federated namespace.

Organizational Unit Namespace

The organizational unit namespace provides a hierarchical namespace for naming subunits of an enterprise. Each organizational unit name is bound to an organizational unit context that represents the organizational unit.

In the Solaris environment, organizational units correspond to NIS+ domains and are named using dot-separated right-to-left compound names, where each atomic part names an organizational unit within a larger unit. For example, the name dct.eng names an organizational unit dct within a larger unit named eng.

Organizational unit names can be either fully qualified NIS+ domain names or relatively named NIS+ domain names. Fully qualified names have a terminal dot; relative names do not. If a terminal dot is present in the organization name, the name is treated as a fully qualified NIS+ domain name. If there is no terminal dot, the organization name is resolved relative to the top of the organizational hierarchy. For example, if the top organization corresponds to the NIS+ root domain wiz.com.(the trailing dot is significant) and if dct.eng is one of its suborganizations, the organization names dct.eng and dct.eng.wiz.com. (the trailing dot is significant) are equivalent.

Site Namespace

The site namespace provides a geographic namespace for naming objects that are naturally identified with their physical locations. These objects may be, for example, buildings on a campus, machines and printers in a building, conference rooms in a building and their schedules, and users in a particular quadrant of a building.

In the Solaris environment, sites are named using compound names, where each atomic part names a site within a larger site. The syntax of site names is dot-separated right-to-left, with components arranged from the most general to the most specific location description. For example, clarke.b5.mtv names the Clarke conference room in building 5 on the Mountain View campus of some enterprise.

User Namespace

The user namespace provides a namespace for naming human users in a computing environment.

Users are named in username contexts. The username context has a single-level namespace and contains bindings of user names to user contexts. A user context allows you to name objects relative to a user, such as files, services, or resources associated with the user.

In the Solaris environment, user names correspond to Solaris login user names.

Host Namespace

The host namespace provides a namespace for naming computers.

Hosts are named in hostname contexts. The hostname context has a flat namespace and contains bindings of host names to host contexts. A host context allows you to name objects relative to a host, such as files and printers found at that host.

In the Solaris environment, host names correspond to Solaris host names. Alias names for a single machine share the same context.

Service Namespace

The service namespace provides a namespace for services used by or associated with objects within an enterprise. Examples of such services are electronic calendars, faxes, mail, and printing.

In the Solaris environment, the service namespace is hierarchical. Service names are slash-separated (/) left-to-right compound names. An application that uses the service namespace can make use of this hierarchical property to reserve a subtree for that application. For example, the printer service reserves the subtree printer in the service namespace.

FNS does not specify how service names or reference types are chosen. These are determined by service providers that share the service namespace. For example, the calendar service uses the name calendar in the service context to name the calendar service and what is bound to the name calendar is determined by the calendar service.

Service Name and Reference Registration

SunSoft, Inc., maintains a registry of the names bound in the first level of the service namespace. To register a name, send an email request to fns-register@sun.com, or write to:

FNS Registration Sun Microsystems, Inc. 2550 Garcia Avenue Mountain View, CA 94043

Please include a brief description of the intended use of the name and a description of the format of the reference that can be bound to that name. See "References and Addresses" on page 153 for details on reference formats.

Printer Namespace

The printer namespace provides a namespace for naming printers. The printer namespace and context is described in more detail in Chapter 9, "Administering the Printer Namespace."

File Namespace

A file naming system (or file system) provides a namespace for naming files. The file context and namespace is described in more detail in Chapter 8, "Administering the File System Namespace."

Namespace Identifiers

The organizational unit namespace, site namespace (an extension to XFN policies), user namespace, host namespace, service namespace, and file namespace are referred to by the atomic names _orgunit, _site, _host, _user, _service, and _fs, respectively, in the federated enterprise namespace. These atomic names are called namespace identifiers.

Table 4-1

Namespace Identifier	Resolves to
orgunit _orgunit	Context for naming organizational units
site _site	Context for naming sites
host _host	Context for naming hosts
user _user	Context for naming users
fs _fs	Context for naming files
service _service	Context for naming services
printer	Context for naming printers

In addition, FNS also supports the use of these names without the leading underscore ("_") character (orgunit, site, host, user, service, and fs, respectively) as namespace identifiers for these namespaces. These names without the underscore are extensions to the XFN policies. The site and printer contexts are extensions to the XFN policies.

---

Note - In XFN terminology, the names with the leading underscore are the canonical namespace identifiers. The names without the underscore are the Solaris customized namespace identifiers. Solaris customized namespace identifiers, with the addition of printer, may not necessarily be recognized in non-Solaris environments. The canonical namespace identifiers are always recognized and, hence, portable to other environments.

---

The XFN component separator (/) is used to delimit namespace identifiers. For example, composing the namespace identifier orgunit with the organizational unit name accountspayable.finance gives the composite name, orgunit/accountspayable.finance.

Composing the namespace identifier user with the user name jsmith gives the composite name, user/jsmith.

FNS reserves the use of all atomic names in Table 4-1 as namespace identifiers in contexts in which namespace identifiers can appear, as defined by the arrangement of naming systems in "Structure of the Enterprise Namespace." FNS does not otherwise restrict the use of these atomic names in other contexts. For example, the atomic name service is used as a namespace identifier relative to a user name, as in user/jsmith/service/calendar, to mean the root of user jsmith's service namespace. This does not preclude a system from using the name service as a user name, as in user/service, because FNS specifies that the context to which the name user/ is bound is for user names and not for namespace identifiers. Thus, in this case, service is unambiguously interpreted as a user name.

Structure of the Enterprise Namespace

FNS defines the structure of the enterprise namespace. The goal of this structure is to allow easy and uniform composition of names. This structure has two main rules: (1) objects with narrower scopes are named relative to objects with wider scopes, and (2) namespace identifiers are used to denote the

transition from one namespace to the next. Table 4-2 is a summary of FNS policy for arranging the enterprise namespace. Figure 4-1 on page 44 shows an example of a namespace layout that follows FNS policy.

Table 4-2

Namespace Identifiers	Name Service Type	Subordinate Context	Parent Context	Namespace Organization	Syntax
orgunit	Organiza-	Site,	Enterprise root	Hierarchical	NIS+ domain
_orgunit	tional unit	user, host, file system, service			name Dot-separated, right-to-left
site	Site	Service,	Enterprise root,	Hierarchical	Dot-separated,
_site		file system	organizational unit		right-to-left
user	User	Service,	Enterprise root,	Flat	Solaris login
_user		file system	organizational unit,		name
host	Host	Service,	Enterprise root,	Flat	Solaris
_host		file system	organizational unit,		host name
service	Service	Application-	Enterprise root,	Hierarchical	/ separated,
_service		specific	organizational unit, site, user, host		left-to-right
fs	File system	None	Enterprise root,	Hierarchical	/ separated,
_fs			organizational unit, site, user, host		left-to-right
printer	Printer	None	Service	Hierarchical	/ separated, left-to-right

Figure 4-1

The namespace of an enterprise is structured around the hierarchical structure of organizational units of an enterprise. Names of sites, hosts, users, files, and services may be named relative to names of organizational units by composing the organizational unit name with the appropriate namespace identifier and object name.

In Figure 4-1, a user jsmith in the engineering organization of an enterprise is named using the name

orgunit/desktop.sw.eng/user/jsmith

Note the use of the namespace identifier user to denote the transition from the orgunit namespace to the user namespace. In a similar fashion (with the use of appropriate namespace identifiers), names of files and services may also be named relative to names of sites, users, or hosts. Names of sites may be named relative to organizational unit names.

The goal of easy and uniform composibility of names is met using this structure. For example, once you know the name for an organizational unit within an enterprise (for example, orgunit/sw), you can name a user relative to it by composing it with the user namespace identifier and the user's login name to yield a name such as

    orgunit/sw/user/joe

To name a file in this user's file system, you can use a name like

    orgunit/sw/user/joe/fs/notes

Double Slashes in Organization Name

orgunit// names the context of namespace identifiers associated with the root organizational unit, as in orgunit//service/printer. See "Significance of Double Slashes" on page 99 for more details on the significance of double slashes.

Enterprise Root

The root context of an enterprise, referred to as the enterprise root, is a context for naming objects found at the root of the enterprise namespace.

Parent Context

Enterprise roots are bound in the global namespace.

Subordinate Contexts

The following objects can be named relative to the enterprise root:

• Organizational units in that enterprise
• Sites in the top organizational unit of the enterprise (an extension to XFN policies)

• Users in the top organizational unit of the enterprise
• Hosts in the top organizational unit of the enterprise
• Services for the top organizational unit of the enterprise
• File service for the top organizational unit of the enterprise

These objects are named by composing with the namespace identifier of the target object's namespace and the name of the target object.

For example, if .../wiz.com¹ is the name of an enterprise, the root of the context for naming organizational units is

.../wiz.com/orgunit/

and an organizational unit in that enterprise would be named using a name like

      .../wiz.com/orgunit/finance

Sites in that enterprise would be named using a name starting with

      .../wiz.com/site/

Organizational Units

Parent Context

Organizational units may be named relative to the enterprise root.

Given an organization name, you can compose a name for its organizational unit context by using one of the namespace identifiers, orgunit or _orgunit. For example, if .../wiz.com is the name of an enterprise, the root of the context for naming organizational units is

.../wiz.com/orgunit/

and an organizational unit in that enterprise would be named using a name like

.../wiz.com/orgunit/finance

---

1. The atomic name "..." (three dots) appears in the initial context to mean the global context. See Chapter 5, "Policies for the Global Namespace" for a description of the global context.

Subordinate Contexts

The following objects can be named relative to an organizational unit name:

• Sites for that organizational unit (an extension to the XFN policies)
• Hosts in that organizational unit
• Users in that organizational unit
• Services for that organization unit
• File service for that organizational unit

These objects are named by composing the organizational unit's name with the namespace identifier of the target object's namespace and the name of the target object. For example, the name

  orgunit/sales/service/calendar

names the calendar service of the sales organizational unit. Similar, the name

  orgunit/sales/user/jpeters

names a user jpeters in the sales organizational unit.

To name an organizational unit's subunit, you use the organizational unit namespace's syntax to compose the subunit's name. For example, a subunit accountspayable of the organizational unit finance is named using the name

orgunit/accountspayable.finance

whereas user jsmith in the finance organizational unit is named using the name

orgunit/finance/user/jsmith

Sites

Sites are an extension to the XFN policies.

Parent Contexts

Sites may be named relative to

• The enterprise root
• An organizational unit

Sites named relative to the enterprise root are the same as sites named relative to the top organizational unit. Given an organization name, you can compose a name for its site context by using one of the namespace identifiers, site or _site. For example, if .../wiz.com is the name of an enterprise, the root of the context for naming sites is

      .../wiz.com/site

which is equivalent to

      .../wiz.com/orgunit//site

 A site in that enterprise would be named using a name like

      .../wiz.com/site/OceanSide

In another example, the name

  orgunit/eng/site/

names the root of the site namespace for the organizational unit orgunit/eng,
while the name

  orgunit/eng/site/b5.mtv

names a location within that site; in this example, building 5 in Mountain View.

Subordinate Contexts

The following objects can be named relative to a site name:

• Services at the site, such as the site schedule or calendar, printers, and faxes
• The file service available at the site

These objects are named by composing the site name with the namespace identifier of the target object's namespace and the name of the target object.

For example, the name

site/Clark.b5.mtv/service/calendar

names the calendar service of the conference room Clark.b5.mtv and is obtained by composing the site name site/Clark.b5.mtv with the service name service/calendar. To name a subunit of a site, you use the site namespace syntax. For example, the name

site/b5.mtv

names building 5, on the Mountain View campus of some enterprise while the name

site/mtv/service/calendar

names the calendar service for the Mountain View site.

Users

Parent Contexts

Users can be named relative to

• An organizational unit
• The enterprise root

Users named relative to the enterprise root are the same as users named relative to the top organizational unit. Given an organization name, you can compose a name for its username context by using one of the namespace identifiers, user or _user. Thus, if orgunit/dct.eng names an organization, then

    orgunit/dct.eng/user/

names the username context of dct.eng. The username context contains bindings of user names to user contexts.

Continuing with the above example, the name

orgunit/dct.eng/user/jsmith

names a user jsmith in the dct.eng organizational unit.

Subordinate Contexts

The following objects can be named relative to a user name:

• Services associated with the user
• The user's files

These objects are named by composing the user's name with the namespace identifier of the target object's namespace and the name of the target object. For example, the name

user/jjones/service/calendar

names the calendar for the user jjones.

Hosts

Parent Contexts

Hosts can be named relative to

• An organizational unit
• The enterprise root

Hosts named relative to the enterprise root are the same as hosts named relative to the top organizational unit. Given an organization name, you can compose a name for its hostname context by appending one of the namespace identifiers, host or _host. Thus if orgunit/dct.eng names an organization, then

    org/dct.eng/host/

names the hostname context of dct.eng. The hostname context contains bindings of host names to host contexts. Continuing with the above example, the name

org/dct.eng/host/silver

names a machine silver in the dct.eng organizational unit.

Subordinate Contexts

The following objects can be named relative to a host name:

• Services associated with the host
• Files exported by the host

These objects are named by composing the host name with the namespace identifier of the target object's namespace and the name of the target object. For example, the name

host/silver/fs/release

names the file directory release being exported by the machine silver.

Typically, resources should not be named relative to hosts but relative to more intuitive entities such as organizations, users, or sites. Dependence on host names forces the user to remember information that is often obscure and sometimes not very stable. For example, a user's files may move from one host to another, because of hardware changes, file space usage, users who share the same file server, network reconfigurations, and so on. Yet if the files were named relative to the user, such changes would not affect how the files are named. There may be a few cases in which the use of host names is appropriate. For example, if a resource is available only on a particular machine and is tied to the existence of that machine, and there is no other logical way to name the resource relative to other entities, then it may make sense to name the resource relative to the host.

Services

Service names should be registered with SunSoft, Inc., as directed in "Service Name and Reference Registration" on page 40.

Parent Contexts

A service can be named relative to

• An organizational unit
• The enterprise root
• A user
• A host
• A site

Services named relative to the enterprise root are the same as services named relative to the top organizational unit.

The parent contexts allow services, such as Calendar Manager or printers, to be named relative to the parent object. A service context is named by using the namespace identifiers service or _service, relative to the organization, site, user, or host with which it is associated. For example, if orgunit/accountspayable.finance names an organizational unit, then

    orgunit/accountspayable.finance/service/calendar

names the calendar service of the organizational unit accountspayable.finance.

Subordinate Contexts

FNS does not restrict the types of bindings in the service namespace. Applications may create contexts of a type other than service contexts and bind them in the service namespace.

FNS supports the creation of generic contexts in the service context. A generic context is similar to a service context except that a generic context has an application-determined reference type. All other properties of a generic context are the same as a service context.

For example, a company, World Intrinsic Designs Corp (WIDC), reserves the name extcomm in the service namespace to refer to a generic context for adding bindings related to its external communications line of products. The context bound to extcomm is a generic context, with reference type WIDC_comm. The only difference between this context and a service context is that this context has a different reference type.

Files

Parent Contexts

A file namespace can be named relative to

• The enterprise root
• An organizational unit
• A user
• A host
• A site

Files named relative to the enterprise root are the same as files named relative to the top organizational unit. A file context is named by using the namespace identifiers fs or _fs, relative to the organization, site, user, or host with which it is associated. For example, if orgunit/accountspayable.finance names an organizational unit, then

    orgunit/accountspayable.finance/fs/

names the file service of the organizational unit accountspayable.finance. In another example, if user/jsmith names a user jsmith, the name

user/jsmith/fs/highlights95.mif

names her file highlights95.mif. The file service of the user defaults to her home directory, as specified in the NIS+ passwd table.

Subordinate Contexts

There can be no other type of context subordinate to a file system.

Printers

The printer context is an extension of XFN policies.

Parent Contexts

A printer namespace can be named in the service context.

A printer context is named by using the namespace identifier, printer, in the service context relative to

• An organizational unit
• A user
• A host
• A site

For example, if orgunit/accountspayable.finance names an organizational unit, then

    orgunit/accountspayable.finance/service/printer

names the printer service of the organizational unit accountspayable.finance.

Subordinate Contexts

There can be no other type of context subordinate to a printer.

Initial Context Bindings for Naming Within the Enterprise

The XFN API provides a function, fn_ctx_handle_from_initial(), that allows the client to obtain an initial context object as a starting point for name resolution. The initial context contains bindings that allow the client application to (eventually) name any object in the enterprise namespace.Figure 4-2 on page 54 shows the same naming system as the one shown in Figure 4-1 on page 44, except that the initial context bindings are shaded and shown in italics.

Figure 4-2

The initial context has a flat namespace for namespace identifiers. The bindings of these namespace identifiers are summarized in Table 4-3 on page 55 and are described in more detail in subsequent sections. There are three categories of bindings:

• User-related bindings
• Host-related bindings
• "Shorthand" bindings

In Table 4-3, the user to which the bindings are related is denoted by U, and the host to which the bindings are related is denoted by H. Not all of these names need to appear in all initial contexts. For example, when a program is invoked by the superuser, none of the user-related bindings appears in the initial context. These bindings are described in more detail in the following sections.

Table 4-3

Namespace Identifier	Binding
myself _myself thisuser	U's user context
myens _myens	The enterprise root of U
myorgunit _myorgunit	U's distinguished organizational unit context; in the Solaris environment, the distinguished organizational unit is U's NIS+ home domain
thishost _thishost	H's host context
thisens _thisens	The enterprise root of H
thisorgunit _thisorgunit	H's distinguished organizational unit context; in the Solaris environment, the distinguished organizational unit is H's NIS+ home domain
user _user	The context in which users in the same organizational unit as H are named
host _host	The context in which hosts in the same organizational unit as H are named
org orgunit _orgunit	The root context of the organizational unit namespace in H's enterprise; in the Solaris environment, this corresponds to the NIS+ root domain

Table 4-3 (Continued)

Namespace Identifier	Binding
site _site	The root context of the site namespace at the top organizational unit if the site namespace has been configured

In XFN terminology, the names with the leading underscore prefix are the canonical namespace identifiers. The names without the leading underscore, with the additions of org and thisuser, are Solaris customizations. Solaris customized namespace identifiers are not guaranteed to be recognized in other, non-Solaris environments. The canonical namespace identifiers are always recognized and, hence, portable to other environments.

---

Note - The current implementations of FNS does not support the addition or modification of names and bindings in the initial context.

---

User-related Bindings

FNS assumes that there is a user associated with a process when fn_ctx_handle_from_initial() is invoked. This association is based on the effective user ID (euid) of the process. Although the association of user to process may change during the life of the process, the original context handle does not change.

In the following sections the user is denoted by "U." FNS defines the following bindings in the initial context that are related to U.

myself

The namespace identifier myself (or either synonym _myself or thisuser) in the initial context resolves to the user context of U. For example, if U is jsmith, the name myself resolves in the initial context to jsmith's user context, and the name

myself/fs/.cshrc

names the file .cshrc of jsmith.

myorgunit FNS assumes that each user is affiliated with an organizational unit of an enterprise. A user may be affiliated with multiple organizational units, but there must be one that is distinguished, perhaps by its position in the organizational namespace or by the user's role in the organization. In NIS+ terminology, this organizational unit corresponds to the user's home domain.

The namespace identifier myorgunit (or synonym _myorgunit) resolves in the initial context to the context of U's distinguished organizational unit. For example, if U is the user jsmith, and jsmith's home domain is accountspayable.finance, then myorgunit resolves in the initial context to the organizational unit context for accounts_payable.finance, and the name

    myorgunit/service/calendar

resolves to the calendar service of accounts_payable.finance.

myens FNS assumes that there is an association of a user to an enterprise. This corresponds to the NIS+ hierarchy that holds myorgunit.

The namespace identifier myens (and synonym _myens) resolves in the initial context to the enterprise root of the enterprise to which U belongs. For example, assume that U is jsmith and jsmith's NIS+ home domain is accountspayable.finance, which in turn is in the NIS+ hierarchy with root domain name wiz.com. The name

myens/orgunit/

resolves to the top organizational unit of wiz.com.

---

Note - Writers of set-user-ID programs need to be careful when using user-related composite names, such as myorgunit or myself/service, because these bindings depend on the effective user ID of a process. In cases where programs have a set-user-ID of root in order to access system resources on behalf of the caller, it will generally be desirable to call seteuid(getuid()) before calling fn_ctx_handle_from_initial().

---

Host-related Bindings

A process is running on a particular host when fn_ctx_handle_from_initial() is invoked. In the following discussion this host is denoted by "H." FNS defines the following bindings in the initial context that are related to H.

thishost
The namespace identifier thishost (or its synonym _thishost) is bound to
the host context of H. For example, if the process is running on the machine
gofer, thishost would be bound to the host context of gofer, and the name

    thishost/service/calendar

would refer to the calendar service of gofer.

thisorgunit FNS assumes that there is an association of a host to an organizational unit. A host may be associated with multiple organizational units, but there must be one that is distinguished. In NIS+ terminology, this organizational unit corresponds to the host's home domain.

The namespace identifier thisorgunit (or its synonym _thisorgunit) resolves to H's distinguished organizational unit. For example, if H is the machine gofer, and gofer's NIS+ home domain is desktop.engineering, thisorgunit resolves to the organizational unit context for desktop.engineering and the name

    thisorgunit/service/fax

refers to the fax service of the organizational unit desktop.engineering.

thisens FNS assumes that there is an association of a host to an enterprise. This corresponds to the NIS+ hierarchy that holds thisorgunit.

The namespace identifier thisens (or its synonym _thisens) resolves to the enterprise root of H. For example, assume that H is the machine gofer and gofer's NIS+ home domain is desktop.engineering, which in turn is in the NIS+ hierarchy with root domain name wiz.com. The name

thisens/site/

resolves to the root of the site namespace of wiz.com.

"Shorthand" Bindings

FNS defines the following "shorthand" bindings in the initial context to enable the use of shorter names to refer to objects in certain commonly referenced namespaces.

user The namespace identifier user (or its synonym _user) is bound in the initial context to the username context in H's organizational unit. This allows other users in the same organizational unit as H to be named from this context.

From the initial context, the names user and thisorgunit/user resolve to the same context. For example, if H is the machine gofer and gofer is in the desktop.engineering organizational unit, the name user/mjones names the user mjones in desktop.engineering.

host The namespace identifier host (or its synonym _host) is bound in the initial context to the hostname context in H's organizational unit. This allows other hosts in the same organizational unit as H to be named from this context.

From the initial context, the names host and thisorgunit/host resolve to the same context. For example, if H is the machine gofer and gofer is in the desktop.engineering organizational unit, the name host/bigbig names the machine bigbig in the organizational unit desktop.engineering.

org The namespace identifier org (or its synonyms orgunit, _orgunit) is bound in the initial context to the root context of the organization naming system of the enterprise to which H belongs.

From the initial context, the names org and thisens/orgunit resolve to the same context. For example, if H is the machine gofer and gofer is in the enterprise wiz.com., the name

org/accountspayable.finance

names the organizational unit accountspayable.finance in wiz.com.

site The namespace identifier site (or its synonym _site) is bound in the initial context to the root of the site naming system of the top organizational unit of the enterprise to which H belongs.

From the initial context, the names site and thisens/site resolve to the same context. For example, if H is the machine gofer and gofer is in the enterprise wiz.com., the name

    site/clarke.b5.mtv

names a conference room, clarke in building 5 on the Mountain View campus of wiz.com.