How FNS Policies Relate to NIS

See "FNS and NIS Naming" for overview and background information relating to FNS and NIS.

FNS provides the XFN interface for performing basic naming and attributes operations using NIS as the naming service.

FNS stores bindings for enterprise objects in FNS maps which are located in a /var/yp/domainname directory on the NIS master server (and NIS slave servers, if any). FNS maps are similar in structure and function to FNS maps. These NIS maps store bindings for the following enterprise namespaces:

• Organization which provides a namespace for naming objects relative to an entire enterprise. When NIS is the underlying naming service, there is a single organizational unit context that corresponds to the NIS domain. This organization unit context is identified in FNS by the NIS domain name or an empty name which defaults to the machines NIS domain name.

• Hosts namespace which correspond to the hosts.byname map of the NIS domain. FNS provides a context for each host in the hosts.byname map.

• Users namespace which correspond to the passwd.byname map. FNS provides a context for each user in the passwd.byname map of the domain.

• Sites namespace which allows you to name geographical sites relative to the organization, hosts, and users.

• Services namespace which allows you to name services such as a printer service and calendar service relative to the organization, hosts, and users.

  FNS provides contexts which allow other objects to be named relative to these five namespaces.

  The FNS fncreate command creates the FNS maps in the /var/yp/domainname directory of a NIS master server. This can be the same machine that is master server for the NIS naming service, or it can be a different machine that functions as an FNS master server. (If there are slave servers, NIS pushes the FNS maps to them as part of its normal operation.) To run fncreate, you must be a privileged user on the server that will host the FNS maps. Individual users cannot make changes to FNS data.