Sun Microsystems, Inc.
spacer | | |  
black dot
A   B   C   D   E   F   G   H   I   J   K   L   M   N   O   P   Q   R   S   T   U   V   W   X   Y   Z
Standards, Environments, and Macrosfns_files(5)


 fns_files - overview of FNS over files implementation



The Federated Naming Service (FNS) provides a method for federating multiple naming services under a single, simple interface for the basic naming operations. One of the naming services supported by FNS is /etc files. FNS provides the XFN interface for performing naming and attribute operations on FNS enterprise objects (organization, site, user, host, and service objects), using files as the naming service. FNS stores bindings for these objects in files and uses them in conjunction with existing /etc files objects.

FNS Policies and /etc Files


FNS defines policies for naming objects in the federated namespace (see fns_policies(5)). At the enterprise level, FNS policies specify naming for organizations, hosts, users, sites, and services. The enterprise-level naming service provides contexts to allow other objects to be named relative to these objects.

The organizational unit namespace provides a hierarchical namespace for naming subunits of an enterprise. In /etc files, there is no concept of an organization. Hence, with respect to /etc files as the naming service, there is a single organizational unit context that represents the entire system. Users in an FNS organizational unit correspond to the users in the /etc/passwd file. FNS provides a context for each user in the /etc/passwd file.

Hosts in an FNS organizational unit correspond to the hosts in the /etc/hosts file. FNS provides a context for each host in the /etc/hosts file.

Security Considerations


Changes to the FNS information (using the commands fncreate(1M), fncreate_fs(1M), fnbind(1), fndestroy(1M) and fnunbind(1)) can be performed only by the privileged users on the system that exports the /var/fn directory. Also, based on the UNIX user IDs, users are allowed to modify their own contexts, bindings, and attributes, from any machine that mounts the /var/fn directory.

For example, the command fncreate(1M) creates FNS related files and directories in the system on which the command is executed. Hence, the invoker of the fncreate(1M) command must have super-user privileges in order to create the user, host, site, and service contexts. However, a user could use the fnunbind(1) command to create calendar bindings in the user's own context, as in this example:

fnbind -r thisuser/service/calendar onc_calendar onc_cal_str jsmith@beatrix

The files object name that corresponds to an FNS composite name can be obtained using fnlookup(1) and fnlist(1).



The files used for storing FNS information are placed in the directory /var/fn. The machine on which /var/fn is located has access to the FNS file. The FNS information can be made accessible to other machines by exporting /var/fn. Client machines that NFS mount the /var/fn directory would then be able to access the FNS information.



fnbind(1), fnlist(1), fnlookup(1), fnunbind(1), fncreate(1M), fncreate_fs(1M), fndestroy(1M), xfn(3XFN), fns(5), fns_initial_context(5), fns_nis(5), fns_nis+(5), fns_policies(5), fns_references(5)

SunOS 5.9Go To TopLast Changed 13 Dec 1996

Copyright 2002 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms.