Solaris Naming Administration Guide

Policies for the Enterprise Namespace

FNS policies specify the types and arrangement of namespaces within an enterprise and how such namespaces can be used by applications. For example, which namespaces can be associated with which other namespaces. The FNS policies described here include some extensions to XFN policy. These are explicitly defined with notes.

Default FNS Enterprise Namespaces

The FNS enterprise policies deal with the arrangement of enterprise objects within the namespace. Each enterprise objects has its own namespace.

By default, there are seven FNS enterprise objects and namespaces:

Organization (orgunit). Entities such as departments, centers, and divisions. Sites, hosts, users, and services can be named relative to an organization. The XFN term for organization is organizational unit. When used in an initial context the identifier org can be used as an alias for orgunit.
Site (site). Physical locations, such as buildings, machines in buildings, and conference rooms within buildings. Sites can have files and services associated with them.
Host (host). Machines. Hosts can have files and services associated with them.
User (user). Human users. Users can have files and services associated with them.
File (fs). Files within a file system.
Service (service). Services such as printers, faxes, mail, and electronic calendars.
Printer (service/printer). The printer namespace is subordinate to the service namespace.

Figure 22-1 shows how these enterprise namespaces are arranged.

Figure 22-1 What FNS Policies Arrange

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

The policies that apply to these namespaces are summarized in Table 22-2.

Enterprise Namespace Identifiers

Enterprise namespaces are referred to by their atomic names in the federated enterprise namespace.

XFN uses leading underscore ("_") characters to indicate an enterprise namespace identifier. For example, _site. FNS also supports the use of these identifiers without the leading underscore ("_") character. These names without the underscore are extensions to the XFN policies. The site and printer contexts are also extensions to the XFN policies. These atomic names are listed in Table 22-1.

Table 22-1 Enterprise Namespace Identifiers in the Enterprise


Namespace	XFN Identifiers	FNS Identifiers	Resolves to
Organization	_orgunit	orgunit or org	Context for naming organizational units
Site	_site	site	Context for naming sites
Host	_host	host	Context for naming hosts
User	_user	user	Context for naming users
File system	_fs	fs	Context for naming files
Service	_service	service	Context for naming services
Printer		printer	Context for naming printers, (subordinate to service namespace)

Note -

In XFN terminology, the names with the leading underscore are the canonical namespace identifiers. The names without the underscore are namespace identifies that have been customized for the Solaris environment. These customized namespace identifiers, with the addition of printer, might not be recognized in non-Solaris environments. The canonical namespace identifiers are always recognized and so are portable to other environments.

Component Separators

The XFN component separator (/) delimits namespace identifiers. For example, composing the namespace identifier orgunit with the organizational unit name west.sales gives the composite name, orgunit/west.sales.

Default FNS Namespaces

There are seven namespaces supplied with FNS:

Organization. (See "Organizational Unit Namespace")
Site. (See "Site Namespace")
Host. (See "Host Namespace")
User. (See "User Namespace")
File. (See "File Namespace")
Service. (See "Service Namespace")
Printer. (See "Service 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. Organization unit names are identified by the prefixes org/, orgunit/, or _orgunit/. (The shorthand alias org/ is only used in the initial context, never in the middle of a compound name. See "Initial Context Bindings for Naming Within the Enterprise" and "Composite Name Examples".)

NIS+ Environment

In an NIS+ environment, organizational units correspond to NIS+ domains and subdomains.

Under NIS+, organization units must map to domains and subdomains. You must have an organizational unit for each NIS+ domain and subdomain. You cannot have "logical" organization units within a domain or subdomain. In other words, you cannot divide an NIS+ domain or subdomain into smaller organization units. Thus, if you have a NIS+ domain doc.com. and two subdomains sales.doc.com. and manf.doc.com., you must have three FNS organizational units corresponding to those three domains.

Organizational units are named using dot-separated right-to-left compound names, where each atomic element names an organizational unit within a larger unit. For example, the name org/sales.doc.com. names an organizational unit sales within a larger unit named doc.com. In this example, sales is an NIS+ subdomain of doc.com.

Organizational unit names can be either fully qualified NIS+ domain names or relatively named NIS+ names. Fully qualified names have a terminal dot; relative names do not. Thus, 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, orgunit/west.sales.doc.com. is a fully qualified name identifying the west organization unit, and _orgunit/west.sales is a relatively qualified name identifying the same subdomain.

NIS Environment

In a NIS environment there is only one organization unit per enterprise which corresponds to the NIS domain. This orgunit is named orgunit/domainname where domainname is the name of the NIS domain. For example, if the NIS domain name is doc.com, the organizational unit is org/doc.com.

In an NIS environment, you can use an empty string as a shorthand for the organizational unit. Thus, org// is equivalent to org/domainname.

Files-Based Environment

There is only one FNS organization unit and no subunits when your primary enterprise-level name service is files-based. The only permitted organization unit under files-based naming is org//.

Site Namespace

The site namespace provides a geographic namespace for naming objects that are naturally identified with their physical locations. These objects can be, for example, buildings on a campus, machines and printers on a floor, conference rooms in a building and their schedules, and users in contiguous offices. Site names are identified by the prefixes site/or _site/.

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, _site/pine.bldg5 names the Pine conference room in building 5, while site/bldg7.alameda identifies building 7 of the Alameda location of some enterprise.

Host Namespace

The host namespace provides a namespace for naming computers. Host names are identified by the prefixes host/or _host/. For example, host/deneb identifies a machine named deneb.

Hosts are named in hostname contexts. The host 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 machine, 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. For example, if the name mail_server is an alias for the machines deneb and altair, both deneb and altair will share the contexts created for mail_server.

Network resources should only be named relative to hosts as appropriate. In most cases, it is more intuitive to name resources relative to 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 might move from one host to another because of hardware changes, file space usage, network reconfigurations, and so on. And users often share the same file server, which might lead to confusion if files were named relative to hosts. Yet if the files were named relative to the user, such changes do not affect how the files are named.

There might 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 might make sense to name the resource relative to the host. Or, in the case of a file system, if the files are being shared by many users it might make sense to name them relative to the machine they are stored on.

User Namespace

The user namespace provides a namespace for naming human users in a computing environment. User names are identified by the prefixes user/or _user/.

Users are named in user contexts. The user 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 IDs. For example, _user/inga identifies a user whose login ID is inga.

File Namespace

A file namespace (or file system) provides a namespace for naming files. File names are identified by the prefixes fs/or _fs/. For example the name fs/etc/motd identifies the file motd which is stored in the /etc directory.

The file namespace is described in more detail in "FNS File Naming". and file contexts are discussed in "File Contexts Administration".

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. Service names are identified by the prefixes service/ or _service/.

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 _service/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

Sun Microsystems, 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., 901 San Antonio Road, Palo Alto, CA 94303

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.

Printer Namespace

The printer namespace provides a namespace for naming printers. The printer namespace is associated with (subordinate to) the service namespace. In other words, printer service and the printer namespace is one of the services in the service namespace. Printer names are identified by the prefixes service/printer or _service/printer. For example, service/printer/laser1 identifies the printer named laser1.

Significance of Trailing Slash

The trailing / names objects in the next naming system. You need it whenever you are going from one naming system to another.

For example, in the name, org/east.sales/service/printer the slash between org and east.sales is a component delimiter as described above and the slash that trails after the last element in the organization name (sales/) separates the service namespace from the organizational unit namespace. Thus, org/west.sales/service/printer names the printer service of the west.sales organization unit.

FNS Reserved Names

FNS reserves for its own use all the atomic names listed in Table 22-1 as namespace identifiers. For example: _orgunit, org, _site, site, and so forth. This limitation applies to contexts in which the namespace identifiers can appear, as defined by the arrangement of namespaces 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/fatima/service/calendar, to mean the root of user fatima'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. In this case, service is unambiguously interpreted as a user name. On the other hand, you should not create a directory named user because /user/mikhail would cause confusion between the user mikhail and the file (or subdirectory) /user/mikhail.

Composite Name Examples

This section shows examples of names that follow FNS policies. (See Table 22-2 for a summary of these policies.)

The specific choices of organization names, site names, user names, host names, file names, and service names (such as calendar and printer) are illustrative only; these names are not specified by FNS policy.

Composing Names Relative to Organizations

The namespaces that can be associated with the organization namespace (_orgunit, orgunit, or org) are: user, host, service, fs, and site.

For example:

orgunit/doc.com/site/videoconf.bldg-5 names a conference room videoconf located in Building 5 of the site associated with the organization doc.com. (You can also use the alias org for orgunit to form, org/doc.com/site/videoconf.bldg-5.)
orgunit/doc.com/user/mjones names a user mjones in the organization doc.com.
orgunit/doc.com/host/smptserver1 names a machine smptserver1 belonging to the organization doc.com.
orgunit/doc.com/fs/staff/agenda9604/ names a file staff/agenda9604 belonging to the organization doc.com.
orgunit/doc.com/service/calendar names the calendar service for the organization doc.com. This might manage the meeting schedules for the organization.

Composing Names Relative to Users

The namespaces that can be associated with the user namespace are service and fs.

user/helga/service/calendar names the calendar service of a user named helga.
user/helga/fs/tasklist names the file tasklist under the home directory of the user helga.

Composing Names Relative to Hosts

The namespaces that can be associated with the hosts namespace are service and fs.

host/mailhop/service/mailbox names the mailbox service associated with the machine mailhop.
host/mailhop/fs/pub/saf/archives.96 names the directory pub/saf/archives.96 found under the root directory of the file system exported by the machine mailhop.

Composing Names Relative to Sites

The namespaces that can be associated with the sites namespace are service and fs.

site/bldg-7.alameda/service/printer/speedy names a printer speedy in the bldg-7.alameda site.
site/alameda/fs/usr/dist names a file directory usr/dist available in the alameda site.

Composing Names Relative to Services and Files

No other namespaces can be associated with either the files (fs) or services (service) namespaces. For example, you cannot compose a name such as /services/calendar/orgunit/doc.com. In other words, you cannot compose a compound name relative to either the files or the service namespace. You can, of course, compose a file or service name relative to some other namespace such as /user/esperanza/service/calendar.

Structure of the Enterprise Namespace

FNS policies define the structure of the enterprise namespace. The purpose of this structure is to allow easy and uniform composition of names. This enterprise namespace structure has two main rules:

Objects with narrower scopes are named relative to objects with wider scopes.
Namespace identifiers are used to denote the transition from one namespace to the next.

Table 22-2 is a summary of FNS policies for arranging the enterprise namespace. Figure 22-2 shows an example of a namespace layout that follows these FNS policies.

Table 22-2 Policies for the Federated Enterprise Namespace


Namespace Identifiers	Subordinate Namespaces	Parent Context	Namespace Organization	Syntax
orgunit _orgunit org	Site, user, host, file system, service	Enterprise root	Hierarchical	Dot-separated right-to-left
site _site	Service, file system	Enterprise root, organizational unit	Hierarchical	Dot-separated right-to-left
user _user	Service, file system	Enterprise root, organizational unit	Flat	Solaris login name
host _host	Service, file system	Enterprise root, organizational unit	Flat	Solaris host name
service _service	Application specific	Enterprise root, organizational unit, site, user, host	Hierarchical	/ separated left-to-right
fs _fs	None	Enterprise root, organizational unit, site, user, host	Hierarchical	/ separated, left-to-right
printer	None	Service	Hierarchical	/ separated left-to-right

Figure 22-2 Example of an Enterprise Namespace

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

In Figure 22-2, a user myoko in the west division of the sales organization of an enterprise is named using the name orgunit/west.sales/user/myoko.

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 can also be named relative to names of sites, users, or hosts. Names of sites can be named relative to organizational unit names.

The goal of easy and uniform composability of names is met using this structure. For example, once you know the name for an organizational unit within an enterprise (for example, orgunit/west), 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/west/user/josepha.

To name a file in this user's file system, you can use a name like orgunit/west/user/josepha/fs/notes.