[ новости /+++ | форум | теги | ]

NAME
     fns_nis - overview of FNS over NIS (YP) implementation

DESCRIPTION
     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 NIS (YP), the enterprise-wide
     information services in Solaris (see  ypcat(1),  ypmatch(1),
     ypfiles(4)).  FNS  provides the XFN interface for performing
     naming and attribute operations on  FNS  enterprise  objects
     (organization,  site,  user, host and service objects) using
     NIS. FNS stores bindings for these objects in NIS  and  uses
     them in conjunction with existing NIS objects.

  FNS Policies and NIS
     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 FNS organizational unit namespace provides a  hierarchi-
     cal namespace for naming subunits of an enterprise. However,
     NIS does not support a  hierarchical  organizational  struc-
     ture.  Therefore,  a  NIS  domain maps to a single organiza-
     tional unit in the FNS namespace.

     Users in an FNS organizational unit correspond to the  users
     in  the  passwd.byname  map of the corresponding NIS domain.
     FNS provides a context for each user  in  the  passwd.byname
     map.

     Hosts in an FNS organizational unit correspond to the  hosts
     in  the   hosts.byname  map of the corresponding NIS domain.
     FNS provides a context for each host  in  the   hosts.byname
     map.

  Federating NIS with DNS or X.500
     Federating NIS with the global naming systems DNS  or  X.500
     makes  NIS  contexts accessible outside of an NIS domain. To
     enable the federation,  the  administrator  must  first  add
     address  information in either DNS or X.500 (see  fns_dns(5)
     and fns_x500(5)).  After this administrative step  has  been
     taken, clients outside of the NIS domain can access contexts
     and perform  operations.

  Security Considerations
     Changes  to  the  FNS  information   (using   the   commands
     fncreate(1M),     fncreate_fs(1M),     fncreate_printer(1M),
     fnbind(1), fndestroy(1M), fncheck(1M), and fnunbind(1))  can
     be  performed only by the privileged users on the NIS master
     server that maintains the FNS information.

     For example, the command fncreate(1M) creates  the  NIS  map
     for  the  associated NIS domain in the system on which it is
     executed. Hence, the command must be  run  by  a  privileged
     user  either  on  the  NIS master server or on a system that
     will serve as a NIS master server for FNS.

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

SEE ALSO
     fnbind(1), fnlist(1),  fnlookup(1),  fnunbind(1),  ypcat(1),
     ypmatch(1),   fncheck(1M),   fncreate(1M),  fncreate_fs(1M),
     fncreate_printer(1M), fndestroy(1M), xfn(3XFN),  ypfiles(4),
     fns(5),  fns_dns(5),  fns_files(5),  fns_initial_context(5),
     fns_nis+(5), fns_policies(5), fns_references(5), fns_x500(5)

Партнёры:

Хостинг: