Sun Microsystems, Inc.
spacerspacer
spacer www.sun.com docs.sun.com |
spacer
black dot
 
 
25.  Federated Naming Service (FNS) Creating a File Context With fncreate_fs Creating File Contexts With an Input File  Previous   Contents   Next 
   
 

The -ro is unnecessary in the third and fourth lines because src and lib are subcontexts of project, they will inherit the -ro mount option from above.

The following input file would make all of the mounts read-only except for org/sales/fs/project/src.

.	 		-ro
tools/db 			 	svr1:/export/db
project	 				svr1:/export/proj
project/lib altair:/export/lib
project/src         -rw	         svr2:/export/src

Creating File Contexts With Command-line Input

The fncreate_fs command also allows the binding description to be provided on the command line:

fncreate_fs composite_name [mmount_options] [mount_location ...]

This is equivalent to using the input file form of the command but entering the individual bindings from your keyboard. The previous example in which kuanda's file system was set could be set from the command line as follows:

% fncreate_fs user/kuanda/fs altair:/export/home/kuanda

Similarly, the hierarchy illustrated in Figure 25-4 could have been set up by running the sequence of commands:

% fncreate_fs org/sales/fs/tools/db altair:/export/db
% fncreate_fs org/sales/fs/project altair:/export/proj
% fncreate_fs org/sales/fs/project/lib altair:/export/lib
% fncreate_fs org/sales/fs/project/src deneb:/export/src

To make all three of the mounts read-only, you would run this command:

% fncreate_fs org/sales/fs -ro

Advanced Input Formats

The following two sections apply to both input file and command-line input formats.

Multiple Mount Locations

Multiple location fields may be specified for NFS file systems that are exported from multiple, functionally equivalent locations:

% fncreate_fs org/sales/fs altair:/sales cygnus:/sales

The automounter will attempt to choose the best server from among the alternatives provided. If several locations in the list share the same path name, they may be combined using a comma-separated list of host names:

% fncreate_fs org/sales/fs altair,cygnus:/sales

The hosts may be weighted, with the weighting factor appended to the host name as an integer in parentheses: the lower the number, the more desirable the server. The default weighting factor is zero (most desirable). Negative numbers are not allowed.

The following example illustrates one way to indicate that cygnus is the preferred server:

% fncreate_fs org/sales/fs altair(2),cygnus(1):/sales

Variable Substitution

Variable names, prefixed by $, may be used in the options or location fields of fncreate_fs. For example, a mount location may be given as:

altair:/export/$CPU

The automounter will substitute client-specific values for these variables when mounting the corresponding file systems. In the above example, $CPU is replaced by the output of uname -p; for example, sparc.

Backward Compatibility Input Format

For additional compatibility with automount maps, the following input file format is also accepted by fncreate_fs:

name	 [mount_options] [mount_location ...] \ 
 /offset1	[mount_options1] mount_location1 ... \
 /offset2	[mount_options2] mount_location2 ... \
 ...

Where each offset field is a slash-separated hierarchy. The backslash (\) indicates the continuation of a single long line. This is interpreted as being equivalent to:

name [mount_options] [mount_location ...] \
name/offset1	[ mount_options1] mount_location1 ... \
name/offset2	[mount_options2] mount_location2 ......

The first line is omitted if both mount_options and mount_location are omitted. This format is for compatibility only. It provides no additional functionality, and its use is discouraged.

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.

 		 
 
  Previous   Contents   Next