test

System Administration Guide: Naming and Directory Services (FNS and NIS+)

Enterprise Root Subordinate Contexts

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

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

Enterprise Root and Organizational Subunits

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:

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

Enterprise Root and Sites

Sites are an extension to the XFN policies.

Sites can be named relative to

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

Enterprise Root and Users

Users can be named relative to

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

Enterprise Root and Hosts

Hosts can be named relative to

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

Enterprise Root and Services

A service can be named relative to

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 Sun Microsystems, Inc., as directed in Service Name and Reference Registration.

Enterprise Root and Files

A file namespace can be named relative to

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.

Enterprise Root and Printers

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

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.