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  rela-
     tive 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 sin-
     gle 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)

Man(1) output converted with man2html