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.
Service (service). Services such as printers, faxes, mail, and electronic calendars.
Printer (service/printer). The printer namespace is subordinate to the service namespace.
The policies that apply to these namespaces are summarized in Table 25-26.
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 25-25.
Table 25-25 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 operating 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.
Site.
Host.
User.
File.
Service.
Printer.
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 an 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 an 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 operating 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 operating 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.