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 25-3.

Figure 25-3 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 25-4 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 25-4 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.

Table 25-29 Initial Context Bindings for Global Naming

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 System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

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 25-5, 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 25-5 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.