Advanced FNS and File-Based Naming Issues
This section provides specific information on the relationship between files-based naming and FNS.
FNS Files
FNS uses new files which are stored in /var/fn directories on each machine. (While a /var/fn directory is normally stored on each machine, you can mount and export a central /var/fn directory via NFS.)
The new FNS files are:
fns_host.ctx which stores host attributes and subcontext data. When this is first created, it derives its information from the /etc/hosts file.
fns_user.ctx which stores user attributes and subcontext data. When this is first created, it derives its information from the /etc/passwd file.
fns_org.ctx which stores organization attributes and subcontext data.
fns_host.attr which stores host attributes for attribute based searches.
fns_user.attr which stores user attributes for attribute based searches.
fns_org.attr which stores organization attributes for attribute based searches.
Users' sub-context and attribute information is stored in separate /var/fn files that are owned by each user. This allows users to modify their own data with FNS commands. These user-specific files are named fns_user_username.ctx where username is the login ID of the individual user.
Service and file context information for hosts, users, and the organization are stored in the respective fns_host.ctx, fns_user.ctx, and fns_org.ctx files. Printer context information is stored in the same files as other service context information.
Sites are subcontexts of the organization and site context information is stored in the fns_org.ctx file.
Note - These FNS files should not be edited directly. You modify or work with these files by running the appropriate FNS commands such as fncreate, fndestroy, fnbind, fnunbind, fnrename, fnattr, fnlookup, and fnlist. When you run these commands as root, they affect the context that they are applied to such as hosts, site, and organization unit. When you run these commands as a user, they affect only your own user sub-contexts.
Migrating From Files-Based Naming to NIS or NIS+
The fncopy command handles the FNS-related aspects of changing your underlying enterprise-level naming service from files to NIS or NIS+. This command copies and converts files-based FNS contexts to NIS or NIS+ based contexts.
fncopy [-i oldsvc -o newsvc] [-f filename] oldctx newctx |
For example, to copy the contexts listed in the file /etc/host_list to the doc.com domain of an NIS+ naming service, you would enter:
fncopy -i files -o nisplus -f /etc/host_list //doc.com/host |
Printer Backward Compatibility
In Solaris release 2.5, FNS support for printer naming for files was provided for the organization context with a file named printers.conf.byname. In the current Solaris release, organization context printer support is maintained in the fns_org.ctx map. That is, the fncreate_printer command now modifies the fns_org.ctx map and not the printers.conf.byname map.
File Contexts Administration
File contexts may be:
Created using the fncreate_fs command (see "Creating a File Context With fncreate_fs").
Inspected using the fnlist command (see "Listing the Context") or the fnlookup command (see "Displaying the Binding").
Pruned or destroyed using fnunbind command (see "Removing a Composite Name") or the fndestroy command (see "Destroying a Context").
Creating a File Context With fncreate_fs
The fncreate_fs command creates file contexts for organizations and sites. It may also be used to override the default file contexts for users and hosts that are created by the fncreate command.
There are two methods of using the fncreate_fs command.
Input file. File context bindings may be provided by an input file (See "Creating File Contexts With an Input File")
Command line. File context bindings may be created from the command line (See "Creating File Contexts With Command-line Input").
The two methods of fncreate_fs have the following syntax:
fncreate_fs [-v] [-r] -f file composite_name fncreate_fs [-v] [-r] composite_name [options] [location...] |
Table 25-24 fncreate_fs Command Options
Option | Description |
|---|---|
composite_name | The composite name of the file context. |
-f file | Use an input file named file. |
options | Mount options. |
location | Mount location. |
-v | Sets verbose output, displaying information about the contexts being created and modified. |
-r | Replaces the bindings in the context named by composite_name --and all of its subcontexts--with only those specified in the input. This is equivalent to destroying the context (and, recursively, its subcontexts), and then running fncreate_fs without this option. The -r option should be used with care. |
The fncreate_fs command manipulates FNS contexts and bindings of the onc_fn_fs reference type. It uses an address of type onc_fn_fs_mount to represent each remote mount point. The data associated with an address of this type are the corresponding mount options and locations in a single, XDR-encoded string.
Creating File Contexts With an Input File
The input file supplies the names and values to be bound in the context of composite_name. Its format is based upon and similar, but not identical, to the format of indirect automount maps. The input file contains one or more entries with the form:
name [options] [location...] |
name is the reference name. The name field may be a simple atomic name or a slash-separated hierarchical name. It may also be "." (dot), in which case the reference is bound directly to composite_name.
options are mount options, if any. The options field begins with a hyphen ("-"). This is followed by a comma-separated list (with no spaces) of the mount options to use when mounting the directory. These options also apply to any subcontexts of composite_name/name that do not specify mount options of their own.
location is the mount location. The location field specifies the host or hosts that serve the files for composite_name/name. In a simple NFS mount, location takes the form:
host:path
Where host is the name of the server from which to mount the file system and path is the path name of the directory to mount.
For each entry a reference to the mount locations and the corresponding mount options is bound to the name composite_name/name.
If options and location are both omitted, then no reference is bound to composite_name/name. Any existing reference is unbound.
For example, suppose you want kuanda's file system to be an NFS mount of the directory /export/home/kuanda from host altair as shown in Figure 25-3. The command would be run as follows:
% fncreate_fs -f infile user/kuanda/fs |
. altair:/export/home/kuanda |
To set up a more complex file system distributed over more than one server as shown in Figure 25-4, run the command
% fncreate_fs -f infile org/sales/fs |
with infile containing
tools/db altair:/export/db project altair:/export/proj project/lib altair:/export/lib project/src deneb:/export/src |
To change the NFS mounts for project and its subcontexts src and lib to be read-only, you can change infile as follows:
tools/db svr1:/export/db project -ro svr1:/export/projproject/lib altair:/export/lib project/src svr2:/export/src |