The root context of an enterprise, is a context for naming objects found at the root level of the enterprise namespace. Enterprise roots are bound in the global namespace.
There are two ways of naming the enterprise root:
.../rootdomain.
org//.
You can use .../rootdomain/ to identify an enterprise root where:
The initial three dots (...) are an atomic name indicating the global context (see "Policies for the Global Namespace" for a description of the global context).
rootdomain/ is the enterprise root domain. For example, doc.com/.
Thus, .../doc.com/ identifies the enterprise root of a company whose root domain is doc.com. In this example, the context for naming sites associated with the enterprise root is .../doc.com/site/ such as .../doc.com/site/alameda or .../doc.com/site/alameda.bldg5.
You can only use the .../rootdomain format if you have set up the global binding in DNS.
You can use org// to identify an enterprise root. In essence, org// is an alias or functional equivalent for .../domainname/. When using org//, the double slashes identifies the root enterprise context and namespaces associated with it.
For example, org//site/alameda names the Alameda site associated with the enterprise root.
In contrast, org/ or orgunit/ (with a single slash) points to an organizational context which is not necessarily named relative to the enterprise root. For example, org/sales/site/alameda.
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 the namespace identifier of the target object's namespace with the name of the target object.
Organizational subunits can be named relative to the enterprise root.
Given an organization root name, you can compose names for its subordinate organizational unit contexts by using one of the namespace identifiers, orgunit or _orgunit.
For example, if .../doc.com is the name of an enterprise, the root of the context for naming organizational units is .../doc.com/orgunit/, and organizational unit names look like .../doc.com/orgunit/sales and .../doc.com/orgunit/west.sales. Or, you could achieve the same result with org//orgunit/sales.
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
For example, the name ...doc.com/orgunit/sales/service/calendar, identifies the calendar service of the sales organizational unit. (See "Organizational Unit Namespace" and "Composing Names Relative to Organizations "for a more detailed description of naming objects relative to organization units.)
Sites are an extension to the XFN policies.
Sites can 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 the enterprise root is ../doc.com the context for naming sites relative to the enterprise root is ../doc.com/site. Sites would have names like ../doc.com/site/alameda.
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.bldg-5/service/calendar names the calendar service of the conference room Clark.bldg-5 and is obtained by composing the site name site/Clark.bldg-5 with the service name service/calendar. (See "Composing Names Relative to Sites " for a more detailed description of naming objects relative to sites.)
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/east.sales names an organization, then orgunit/east.sales/user/hirokani names a user hirokani in the east.sales organizational unit.
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/sophia/service/calendar names the calendar for the user sophia. (See "User Namespace" and "Enterprise Root and Users" for more information on the user namespace and naming objects relative to users.)
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/west.sales names an organization, the name org/west.sales/host/altair names a machine altair in the west.sales organizational unit.
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/sirius/fs/release names the file directory release being exported by the machine sirius. (See "Host Namespace" and "Composing Names Relative to Hosts " for more information on the host namespace and naming objects relative to hosts.)
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.
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/corp.finance names an organizational unit, then orgunit/corp.finance/service/calendar names the calendar service of the organizational unit corp.finance. (See "Service Namespace" and "Composing Names Relative to Services and Files " for more information on the user namespace and naming objects relative to users.)
FNS does not restrict the types of bindings in the service namespace. Applications can 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 named 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.
Service names should be registered with SunSoft, Inc., as directed in "Service Name and Reference Registration".
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 the name user/jsmith/fs/report96.doc names her file report96.doc. The file service of the user defaults to her home directory, as specified in the NIS+ passwd table. (See "File Namespace" for more information on the user namespace.)
There can be no other type of context subordinate to a file system.
The printer context is an extension of XFN policies.
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 org/east.sales names an organizational unit, then org/eastsales/service/printer names the printer service of the organizational unit east.sales. Thus, an individual printer named lp1 would be identified as: org/east.sales/service/printer/lp1.
There can be no other type of context subordinate to a printer.
An initial context is the starting place from which client users, hosts, and applications can (eventually) name any object in the enterprise namespace.
Figure 21-3 shows the same naming system as the one shown in Figure 21-2, except that the initial context bindings are shaded and shown in italics. These initial contexts are shown from the point of view of the user, host, or application asking for a name to be resolved.
XFN provides an initial context function, fn_ctx_handle_from_initial(), that allows a client to obtain an initial context object as a starting point for name resolution. The initial context has a flat namespace for namespace identifiers. The bindings of these initial context identifiers are summarized in Table 21-3 and are described in more detail in subsequent sections. Not all of these names need to appear in all initial contexts. For example, when a program is invoked by the superuser, only the host and client-related bindings appears in the initial context, none of the user-related bindings appear.
Table 21-3 Initial Context Bindings for Naming Within the Enterprise
Namespace Identifier |
Binding |
---|---|
myself, _myself, thisuser |
The context of the user who is trying to resolve a name. |
myens, _myens |
The enterprise root of the user who is trying to resolve a name. |
myorgunit, _myorgunit |
The user's primary organizational unit context. For example, in an NIS+ environment, the primary organizational unit is the user's NIS+ home domain. |
thishost, _thishost |
The context of the host that is trying to resolve a name. |
thisens, _thisens |
The enterprise root of the host that is trying to resolve a name. |
thisorgunit, _thisorgunit |
The host's primary organizational unit context. For example, in an NIS+ environment, the primary organizational unit is the host's NIS+ home domain |
user, _user |
The context in which users in the same organizational unit as the host are named |
host, _host |
The context in which hosts in the same organizational unit as the host are named |
org, orgunit, _orgunit |
The root context of the organizational unit namespace in the host's enterprise. For example, in an NIS+ environment, this corresponds to the NIS+ root domain |
site, _site |
The root context of the site namespace at the top organizational unit if the site namespace has been configured |
In XFN terminology, names with a leading underscore prefix are called 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 therefore portable to other environments.
The current implementations of FNS does not support the addition or modification of names and bindings in the initial context.
Initial context bindings fall into three basic categories:
User-related bindings (see "User-related Bindings")
Host-related bindings (see "Host-related Bindings")
"Shorthand" bindings (see ""Shorthand" Bindings")
FNS assumes that there is a user associated with a process when the XFN initial context function is invoked. This association is based on the effective user ID (euid) of the process. Although the association of user to process can change during the life of the process, the original context handle does not change.
FNS defines the following bindings in the initial context that are related to the user requesting name resolution.
The namespace identifier myself (or either synonym _myself or thisuser) in the initial context resolves to the user context of whomever is making the request. For example, if a process owned by the user jsmith requests name resolution, the name:
myself resolves in the initial context to jsmith's user context
myself/fs/.cshrc names the file .cshrc of jsmith
FNS assumes that each user is affiliated with an organizational unit of an enterprise. A user can be affiliated with multiple organizational units, but there must be one organizational unit that is primary, perhaps by its position in the organizational namespace or by the user's role in the organization.
NIS+. In an NIS+ namespace, this organizational unit corresponds to the user's home domain (which could be a subdomain).
NIS. In a NIS namespace, there is only one enterprise-level organizational unit which corresponds to the user's domain.
Files. In a files-based namespace, there is only one organizational unit, org// which maps to myorgunit.
The namespace identifier myorgunit (or _myorgunit) resolves in the initial context to the context of the primary organizational unit of the user making the request. For example, if the user making the request is jsmith, and jsmith's home domain is east.sales, then myorgunit resolves in the initial context to the organizational unit context for east.sales, and the name myorgunit/service/calendar resolves to the calendar service of east.sales.
FNS assumes that there is an association of a user to an enterprise. This corresponds to the namespace that holds myorgunit.
The namespace identifier myens (and _myens) resolves in the initial context to the enterprise root of the enterprise to which the user making the request belongs. For example, if jsmith is making the request, and jsmith's NIS+ home domain is east.sales, which in turn is in the NIS+ hierarchy with the root domain name of doc.com. The name myens/orgunit/ resolves to the top organizational unit of doc.com.
Be careful about set-user-ID programs when using user-related composite names, such as myorgunit or myself/service, because these bindings depend on the effective user ID of a process. For programs that set-user-ID to root to access system resources on behalf of the caller, it is usually a good idea to call seteuid(getuid()) before calling fn_ctx_handle_from_initial().
A process is running on a particular host when the XFN initial context function is invoked. FNS defines the following bindings in the initial context that are related to the host the process is running on.
The namespace identifier thishost (or _thishost) is bound to the host context of the host running the process. For example, if the process is running on the machine cygnus, thishost is bound to the host context of cygnus, and the name thishost/service/calendar refers to the calendar service of the machine cygnus.
FNS assumes that a host is associated with an organizational unit. A host can be associated with multiple organizational units, but there must be one that is primary. In an NIS+ namespace, this organizational unit corresponds to the host's home domain.
The namespace identifier thisorgunit (or _thisorgunit) resolves to the primary organizational unit of the host running the process. For example, if that host is the machine cygnus, and cygnus's NIS+ home domain is west.sales, then thisorgunit resolves to the organizational unit context for west.sales and the name thisorgunit/service/fax refers to the fax service of the organizational unit west.sales.
FNS assumes that there is an association of a host to an enterprise. This corresponds to the namespace that holds thisorgunit.
The namespace identifier thisens (or _thisens) resolves to the enterprise root of the host running the process. For example, under NIS+, if the host's home domain is sales.doc.com, then the name thisens/site/ resolves to the root of the site namespace of doc.com.
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.
The namespace identifier user (or _user) is bound in the initial context to the username context in organizational unit of the host running the process. This allows other users in the same organizational unit to be named from this context.
From the initial context, the names user and thisorgunit/user resolve to the same context. For example, if the host running the process is a machine altair and altair is in the east.sales organizational unit, the name user/medici names the user medici in east.sales.
The namespace identifier host (or _host) is bound in the initial context to the hostname context organizational unit of the host running the process. This allows other hosts in the same organizational unit to be named from this context.
From the initial context, the names host and thisorgunit/host resolve to the same context. For example, if the host running the process is a machine named sirius and it is in the east.sales organizational unit, the name host/sirius names the machine sirius in the organizational unit east.sales.
The namespace identifier org (or orgunit, _orgunit) is bound in the initial context to the root context of the organization of the enterprise to which the host running the process belongs.
From the initial context, the names org and thisens/orgunit resolve to the same context. For example, if the host running the process is the machine aldebaran and aldebaran is in the enterprise doc.com., the name org/east.sales names the organizational unit east.sales in doc.com.
The namespace identifier site (or _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 the host running the process belongs.
From the initial context, the names site and thisens/site resolve to the same context. For example, if the host running the process is the machine aldebaran and aldebaran is in the enterprise doc.com., the name site/pine.bldg-5 names a conference room, pine in building 5 of doc.com.