Chapter 22 FNS Policies

This chapter describes FNS policies.

• "Introduction to FNS and XFN Policies"

• "Policies for the Enterprise Namespace"

• "Enterprise Namespace Identifiers"

• "Default FNS Enterprise Namespaces"

• "Organizational Unit Namespace"

• "Site Namespace"

• "Host Namespace"

• "User Namespace"

• "File Namespace"

• "Service Namespace"

• "FNS Reserved Names"

• "Composite Name Examples"

• "Structure of the Enterprise Namespace"

• "Enterprise Root"

• "Initial Context Bindings for Naming Within the Enterprise"

• "FNS and Enterprise Level Naming"

• "Target Client Applications of FNS Policies"

• "FNS File System Namespace"

• "The FNS Printer Namespace"

• "Policies for the Global Namespace"

• "Federating DNS"

• "Federating X.500/LDAP"

Introduction to FNS and XFN Policies

XFN defines policies for naming objects in the federated namespace. The goals of these policies are

• To allow easy and uniform composition of names

• To promote coherence in naming across applications and services

• To provide a simple, yet sufficiently rich, set of policies so that applications need not invent and implement ad hoc policies for specific environments

• To enhance an application's portability

• To promote cross-platform interoperability in heterogeneous computing environments

What FNS Policies Specify

FNS policies contain all the XFN policies plus extensions for the Solaris environment.

Computing environments now offer worldwide scope and a large range of services. Users expect to have access to services at every level of the computing environment. FNS policies provide a common framework for the three levels of services: global, enterprise, and application.

FNS provides to applications a set of policies on how name services are arranged and used:

• Policies that specify how to federate the enterprise namespace so that it is accessible in the global namespace.

• Policies that specify the names and bindings present in the initial context of every process.

• Name service policies for enterprise objects: organizations, hosts, users, sites, files, and services.

• Policies that define the relationships among the organization, host, user, site, files, and service enterprise objects.

• Policies that specify the syntax of names used to refer to those enterprise objects.

What FNS Policies Do Not Specify

The FNS policies do not specify:

• The actual names used within name services.

• Naming within applications. Application-level naming is left to individual applications or groups of related applications.

• The attributes to use once the object has been named.

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.

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.

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.

Enterprise Root

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

Using Three Dots to Identify the Enterprise Root

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.

  ---

  Note -

  You can only use the .../rootdomain format if you have set up the global binding in DNS.

  ---

Using org// to Identify the Enterprise Root

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.

Enterprise Root 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 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:

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

Enterprise Root and Sites

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

Enterprise Root and Users

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

Enterprise Root and Hosts

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

Enterprise Root and Services

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

Enterprise Root and Files

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.

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

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

Initial Context Bindings for Naming Within the Enterprise

An initial context is the starting place from which client users, hosts, and applications can (eventually) name any object in the enterprise namespace.

Figure 22-3 shows the same naming system as the one shown in Figure 22-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.

Figure 22-3 Example of Enterprise Bindings in the Initial Context

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

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

User-related 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.

myself

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

myorgunit

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.

myens

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

Host-related Bindings

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.

thishost

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.

thisorgunit

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.

thisens

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.

"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 _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.

host

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.

org

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.

site

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.

FNS and Enterprise Level Naming

FNS provides a method for federating multiple naming services under a single, simple interface for basic naming operations. FNS is designed to work with three enterprise-level name services:

• NIS+. See "How FNS Policies Relate to NIS+", below and "FNS and NIS+ Naming"

• NIS. See "How FNS Policies Relate to NIS" and "FNS and NIS Naming"

• Files. See "How FNS Policies Relate to Files-Based Naming" and "FNS and Files-Based Naming"

  FNS is also designed to work with applications such as printer and calendar service as described in "Target Client Applications of FNS Policies".

How FNS Policies Relate to NIS+

See "FNS and NIS+ Naming" for overview and background information relating to FNS and NIS+. If you are not familiar with NIS+ and its terminology, refer to Part 1 and Glossary of this guide. You will find it helpful to be familiar with the structure of a typical NIS+ environment.

FNS stores bindings for enterprise objects in FNS tables which are located in domain-level org_dir NIS+ directories on NIS+ servers. FNS tables are similar to NIS+ tables. These FNS tables store bindings for the following enterprise namespaces:

• Organization namespaces as described in "NIS+ Domains and FNS Organizational Units".

• Hosts namespaces as described in "NIS+ Hosts and FNS Hosts"

• Users namespace as described in "NIS+ Users and FNS Users".

• Sites namespace which allows you to name geographical sites relative to the organization, hosts, and users.

• Services namespace which allows you to name services such a printer service and calendar service relative to the organization, hosts, and users.

NIS+ Domains and FNS Organizational Units

FNS names organization, user, and host enterprise objects within NIS+ which is the preferred Solaris enterprise name service. An NIS+ domain is comprised of logical collections of users and machines and information about them, arranged to reflect some form of hierarchical organizational structure within an enterprise.

FNS is implemented on NIS+ by mapping NIS+ domains to FNS organizations. An organizational unit name corresponds to a NIS+ domain name and is identified using either the fully qualified form of its NIS+ domain name, or its NIS+ domain name relative to the NIS+ root. The top of the FNS organizational namespace is mapped to the NIS+ root domain and is accessed using the name org/ from the initial context.

In NIS+, users and hosts have a notion of a home domain. A host or user's home domain is the NIS+ domain that maintains information associated with them. A user or host's home domain can be determined directly using its NIS+ principal name. An NIS+ principal name is composed of the atomic user (login) name or the atomic host name and the name of the NIS+ home domain. For example, the user sekou with home domain doc.com. has an NIS+ principal name sekou.doc.com and the machine name vega has an NIS+ principal name vega.doc.com.

A user's NIS+ home domain corresponds to the user's FNS organizational unit. Similarly, a host's home domain corresponds to its FNS organizational unit.

Trailing Dot in Organization Names

The trailing dot in an organization name indicates that the name is a fully qualified NIS+ domain name. Without the trailing dot, the organization name is an NIS+ domain name to be resolved relative to the NIS+ root domain.

For example, if the NIS+ root domain is doc.com., with a subdomain sales.doc.com., the following pairs of names refer to the same organization:

The name org/manf. (with trailing dot) would not be found, because there is no NIS+ domain with just the manf. name.

NIS+ Hosts and FNS Hosts

Hosts in the NIS+ namespace are found in the hosts.org_dir table of the host's home domain. Hosts in an FNS organization correspond to the hosts in the hosts.org_dir table of the corresponding NIS+ domain. FNS provides a context for each host in the hosts table.

NIS+ Users and FNS Users

Users in the NIS+ namespace are listed in the passwd.org_dir table of the user's home domain. Users in an FNS organization correspond to the users in the passwd.org_dir table of the corresponding NIS+ domain. FNS provides a context for each user in the passwd table.

NIS+ Security and FNS

The FNS fncreate command creates FNS tables and directories in the NIS+ hierarchy associated with the domain of the host on which the command is run. In order to run fncreate, you must be an authenticated NIS+ principle with credentials authorizing you to Read, Create, Modify, and Destroy NIS+ objects in that domain. You will be the owner of the FNS tables created by fncreate. One way to obtain this authorization is to be a member of the NIS+ group that has administrator privileges in the domain.

The NIS_GROUP environment variable should be set to name of the NIS+ administration group for the domain prior to running fncreate. You can specify whether or not individual users can make changes to FNS data that relates to them.

See Chapter 6, Security Overview, for a description of NIS+ security.

How FNS Policies Relate to NIS

See "FNS and NIS Naming" for overview and background information relating to FNS and NIS.

FNS provides the XFN interface for performing basic naming and attributes operations using NIS as the naming service.

FNS stores bindings for enterprise objects in FNS maps which are located in a /var/yp/domainname directory on the NIS master server (and NIS slave servers, if any). FNS maps are similar in structure and function to FNS maps. These NIS maps store bindings for the following enterprise namespaces:

• Organization which provides a namespace for naming objects relative to an entire enterprise. When NIS is the underlying naming service, there is a single organizational unit context that corresponds to the NIS domain. This organization unit context is identified in FNS by the NIS domain name or an empty name which defaults to the machines NIS domain name.

• Hosts namespace which correspond to the hosts.byname map of the NIS domain. FNS provides a context for each host in the hosts.byname map.

• Users namespace which correspond to the passwd.byname map. FNS provides a context for each user in the passwd.byname map of the domain.

• Sites namespace which allows you to name geographical sites relative to the organization, hosts, and users.

• Services namespace which allows you to name services such as a printer service and calendar service relative to the organization, hosts, and users.

  FNS provides contexts which allow other objects to be named relative to these five namespaces.

  The FNS fncreate command creates the FNS maps in the /var/yp/domainname directory of a NIS master server. This can be the same machine that is master server for the NIS naming service, or it can be a different machine that functions as an FNS master server. (If there are slave servers, NIS pushes the FNS maps to them as part of its normal operation.) To run fncreate, you must be a privileged user on the server that will host the FNS maps. Individual users cannot make changes to FNS data.

How FNS Policies Relate to Files-Based Naming

See "FNS and Files-Based Naming" for overview and background information relating to FNS and files.

FNS provides the XFN interface for performing basic naming and attribute operations using local files as the naming service.

FNS stores bindings for enterprise objects in files which are located in a /var/fn directory which is normally NFS mounted on each machine. These FNS files store bindings for the following enterprise namespaces:

• Organization which provides a namespace for naming objects relative to the entire enterprise. When local files are the underlying naming service, there is a single organizational unit context that represents the entire system. This organization unit context is always identified in FNS as org//.

• Hosts namespace which correspond to the /etc/hosts file. FNS provides a context for each host in the /etc/hosts file.

• Users namespace which correspond to the /etc/passwd file. FNS provides a context for each user in the /etc/passwd file.

• Sites namespace which allows you to name geographical sites relative to the organization, hosts, and users.

• Services namespace which allows you to name services such as a printer service and calendar service relative to the organization, hosts, and users.

  FNS provides contexts which allow other objects to be named relative to these five namespaces.

  The FNS fncreate command creates the FNS files in the /var/fn directory of the machine on which the command is run. To run fncreate, you must have super-user privileges on that machine. Based on UNIX user IDs, individual users are allowed to modify their own contexts, bindings, and attributes using FNS commands.

Target Client Applications of FNS Policies

One goal of the FNS policies is to maintain coherence across the most commonly used tools, including the file system, the DeskSet tools, such as Calendar Manager, Print Tool, File Manager, and Mail Tool, and services that support these tools, such as RPC, email, and print subsystems.

Some of these examples are not currently implemented in the Solaris environment. They are listed here to illustrate how FNS can be used.

• Calendars. Instead of using names of the form username@hostname to access someone's calendar, in most cases you simply supply a site, organization, or user's name. You should also be able to use composite names to name calendars. For example, when federated under FNS, names of the following form are acceptable to calendar manager:

  • bernadette

  • user/bernadette

  • site/pine.bldg-5 (calendar for Pine conference room)

  • org/sales (calendar for the sales organization)

• Printing. Instead of naming a specific printer by its name, you should be able to name a printer relative to a user, site, or organization. For example:

  • ilych (ilych's default printer)

  • org/sales (an organization's default printer)

  • site/pine.bldg-5 (printer in the Pine conference room)

• File access. You should be able to use composite names to name file systems and files. The automounter should use FNS to make resolution of composite names possible. For example, you should be able to use a file name like /xfn/user/baruch/fs/.cshrc to reference the .cshrc file for user baruch.

• RPC. Instead of addressing services by their host name, program, and version numbers, you should be able to name the service using a composite name. For example, you should be able to name an RPC service relative to a user or an organization such as: user/hatori/service/rpc.

• Mail - Similarly, composite names can be used to name mail destinations. You should be able to use names such as the following:

  • angus

  • user/angus

  • org/mlist (an organization's mailing list)

  • site/pine.bldg-5 (mailbox of the conference room coordinator)

• Other desktop applications - You should be able to pass composite names to other desktop applications such as spreadsheets, document preparation tools, fax tools, and so on. Some of these applications attach their own namespace to the service namespace, thus becoming part of the FNS federation.

Example Applications: Calendar Service

This is a description of how one application, a calendar service, could be modified to use FNS policies. This example illustrates how FNS composite names might be presented to and accepted from users.

The DeskSet's calendar service is typical of client-server applications. Calendar servers run on some set of machines and maintain the users' calendars. Calendar Manager (cm) runs on the desktop and contacts the appropriate server to obtain the calendars of interest.

The calendar service could benefit from FNS using a simple registry/lookup model as follows:

• Binding - Upon startup, the server registers the calendars that it manages by binding a reference containing its own ONC+ RPC address (host, program, version) to the composite name for each calendar it manages, such as user/jsmith/service/calendar.

• Lookup - When using cm, the user specifies another user's calendar simply by entering the user's name (for example, hirokani) or selecting it from a list of names previously entered. Given the user name hirokani, cm composes the composite name user/hirokani/service/calendar and uses this to look up the RPC address that it needs to communicate with the server that manages that calendar.

  In the previous example, we used the name "calendar" to denote a calendar binding. The developers of the calendar service should register the name "calendar" with the FNS administrator, much as RPC programs are registered with the RPC administrator. Refer to "Service Name and Reference Registration".

  ---

  Note -

  The name "calendar" used here is an example. FNS policy does not specify the names of specific services.

  ---

  The calendar service could take further advantage of FNS policy by allowing calendars to be associated with sites, organizations, and hosts, while still naming them in a uniform way. For example, by allowing calendars to be associated with a conference room (a site), the service can be used to "multibrowse" the conference room's calendar as well as a set of user calendars to find an available time for a meeting in that room. Similarly, calendars can be associated with organizations for group meetings and hosts for keeping maintenance schedules.

  The cm calendar manager could simplify what the user needs to specify by following some simple steps.

1. cm uses a tool for accepting composite names from the user and constructing the name of the object whose calendar is of interest.

   The object is the name of a user, a site, a host, or an organization. For example, the user might enter the name kuanda and the calendar manager generates the composite name user/kuanda. This tool could be shared among a group of DeskSet applications.

2. cm uses the XFN interface to compose this name with the suffix /service/calendar to obtain the name of the calendar.

3. This calendar name is then resolved relative to the process's initial context.

   Continuing with the example, this results in the resolution of the name user/kuanda/service/calendar. Similarly, if the user enters the name of a site, pine.bldg-5, cm generates the name site/pine.bldg-5/service/calendar for resolution.

   Other services such as printing and mail could take advantage of the FNS policies in a similar way.

FNS File System Namespace

Files may be named relative to users, hosts, organizations, and sites in FNS by appending the fs enterprise namespace identifier to the name of the object, and following this with the name of the file. For example, the file draft96 in the sales division's budget directory might be named org/sales/fs/budget/draft96.

The initial context is located under /xfn in the file system's root directory. Thus a user might view the file by typing

% more /xfn/org/sales/fs/budget/draft96

Existing applications can access this directory just as they would any other directory. Applications do not need to be modified in any way or use the XFN API.

NFS File Servers

NFS is Sun's distributed file system. The files associated with an object will generally reside on one or more remote NFS file servers. In the simplest case, the namespace identifier fs corresponds to the root of an exported NFS file system, as shown in Figure 22-4.

Figure 22-4 NFS File System--Simple Case

In contrast, an object's file system may be composed of multiple--and possibly overlapping--remote mounts, woven together into a "virtual" directory structure managed by FNS.

Figure 22-5 illustrates how this capability might be used to piece together an organization's file system from three separate file servers. The project directory, along with its lib subdirectory, resides on one file server, while the src subdirectory resides on another. Users and applications need not be aware of the use of multiple servers; they see a single, seamless namespace.

Figure 22-5 NFS File System--Multiple Servers

The Automounter

For efficiency, the automounter is used to mount FNS directories on demand. The default /etc/auto_master configuration file contains the line:

/xfn -xfn

which tells the automounter that the FNS namespace is "mounted" under /xfn, as specified by XFN.

Since the automounter is used to mount directories named through FNS, the subdirectories of an FNS directory cannot be listed until they have been mounted. For example, suppose the file system of the sales organization is composed of multiple NFS file systems. The following ls command shows only two file systems that have been visited recently and are currently mounted:

% ls /xfn/org/sales/fs
customers products

To see the entire listing, use the fnlist command:

% fnlist org/sales/fs
Listing org/sales/fs:
products
goals
customers
incentives

The FNS Printer Namespace

The printer context is not part of the XFN policies. It is provided in FNS in order to store printer bindings.

FNS provides the capability to store printer bindings in the FNS namespace. This gives print servers the means to advertise their services and allow users to browse and choose among available printers without client-side administration.

Printer bindings are stored in printer contexts, which are associated with organizations, users, hosts, and sites. Hence, each organization, user, host, and site has its own printer context.

The printer context is created under the service context of the respective composite name. For example, the composite name shown below has the following printer context:

org/doc.com./service/printer

The name of a printer for a host, deneb, with a printer context might look like this:

host/deneb/service/printer/laser

Policies for the Global Namespace

Global name services have worldwide scope. This section describes the policies for naming objects that use global naming systems.

In regard to naming, an enterprise links to the federated global namespace by binding the root of the enterprise in the global namespace. This enables applications and users outside the enterprise to name objects within that enterprise. For example, a user within an enterprise can give out the global name of a file to a colleague in another enterprise to use.

DNS and X.500 contexts provide global-level name service for naming enterprises. FNS provides support for both DNS and X.500 contexts. Without FNS, DNS and X.500 allow outside access to only limited portions of the enterprise namespace. FNS enables outside access to the entire enterprise namespace including services such as calendar manager.

Initial Context Bindings for Global Naming

The atomic name "..." (three dots) appears in the initial context of every FNS client. The atomic name "..." is bound to a context from which global names can be resolved.

Global names can be either fully qualified Internet domain names, or X.500 distinguished names.

• Internet domain names appear in the syntax specified by Internet RFC 1035. For example, .../doc.com. (See "Federating DNS".)

• X.500 names appear in the syntax determined by the X/Open DCE Directory. For example, .../c=us/o=doc. (See "Federating X.500/LDAP".)

  The names "..." and "/..." are equivalent when resolved in the initial context. For example, the names /.../c=us/o=doc and.../c=us/o=doc resolve in the initial context to the same object.

Federating DNS

Any fully qualified DNS name can be used in the global context. When a DNS name is encountered in the global namespace, it is resolved using the resolver library. The resolver library is the DNS name-resolution mechanism. A DNS name typically resolves to an Internet host address or to DNS domain records. When the global context detects a DNS name, the name is passed to the DNS resolver for resolution. The result is converted into an XFN reference structure and returned to the requester.

The contents of DNS domains can be listed. However, the listing operations might be limited by practical considerations such as connectivity and security on the Internet. For example, listing the global root of the DNS domain is generally not supported by the root DNS servers. Most entities below the root, however, do support the list operation.

DNS hosts and domains are distinguished from each other by the presence or absence of name service (NS) resource records associated with DNS resource names.

• DNS domain names. If an NS record exists for a resource name, then that name is considered to be the name of a domain, and the returned reference is of type inet_domain.

• DNS host names. If no NS record exists for a resource name, then that name is considered to be the name of a host, and the returned reference is of type inet_host.

DNS can be used to federate other naming systems by functioning as a non-terminal naming system.

For example, an enterprise naming system can be bound to doc.com in DNS such that the FNS name .../doc.com/ refers to the root of that enterprise's FNS namespace.

The enterprise naming system is bound to a DNS domain by adding the appropriate text (TXT) records to the DNS map for that domain. When the FNS name for that domain includes a trailing slash (/), the TXT resource records are used to construct a reference to the enterprise naming system.

For general information about DNS, see the in.named man page or the DNS chapters in Solaris Naming Setup and Configuration Guide.

Federating X.500/LDAP

X.500 is a global directory service. It stores information and provides the capability to look up information by name as well as to browse and search for information.

X.500 information is held in a directory information base (DIB). Entries in the DIB are arranged in a tree structure. Each entry is a named object and comprises a defined set of attributes. Each attribute has a defined attribute type and one or more values.

An entry is unambiguously identified by a distinguished name that is the concatenation of selected attributes from each entry in the tree along a path leading from the root down to the named entry. For example, using the DIB shown in Figure 22-6, c=us/o=doc is a distinguished name of the doc organization in the U.S. Users of the X.500 directory can interrogate and modify the entries and attributes in the DIB.

Figure 22-6 Example of an X.500 Directory Information Base

FNS federates X.500 by supplying the necessary support to permit namespaces to appear to be seamlessly attached below the global X.500 namespace.

For example, FNS facilitates linking the enterprise naming system for the doc organization below X.500. Starting from the initial context, an FNS name to identify the sales organizational unit of the doc organization might be

.../c=us/o=doc/orgunit/sales

The name within the enterprise is simply concatenated onto the global X.500 name. (Note that FNS names use the name "..." in the initial context to indicate that a global name follows.)

Name resolution of FNS names takes place as follows. When an X.500 name is encountered in the global namespace, it is resolved using the X.500 name- resolution mechanism. One of three outcomes is possible:

• The full name resolves to an X.500 entry. This indicates that the entry is held in X.500. The requested FNS operation is then performed on that entry.

• A prefix of the full name resolves to an X.500 entry. This indicates that the remainder of the name belongs to a subordinate naming system.

  The next naming system pointer (NNSP) to the subordinate naming system is examined to return the XFN reference. Name resolution then continues in the subordinate naming system.

• An error is reported.

  X.500 entries can be examined and modified using FNS operations (subject to access controls). However, it is not currently possible to list the subordinate entries under the root of the X.500 namespace by using FNS.