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+, the enterprise-wide information service in Solaris (see nis+(1)). 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 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. An organizational unit maps to an NIS+ domain. Organizational unit names can be either fully qualified NIS+ domain names or relatively NIS+ domain names. If a terminal dot is present in the name, it is treated as a fully qualified name. Otherwise, the name is resolved relative to the root NIS+ domain.
Users in the NIS+ namespace are found in the passwd.org_dir table of an NIS+ domain. Users in an FNS organizational unit correspond to the users in the passwd.org_dir table of the corresponding NIS+ domain. FNS provides a context for each user in the passwd.org_dir table.
Hosts in the NIS+ namespace are found in the hosts.org_dir table of an NIS+ domain. Hosts in an FNS organizational unit correspond to the hosts in the hosts.org_dir table of the corresponding NIS+ domain. FNS provides a context for each host in the hosts.org_dir table.
In NIS+, users and hosts have a notion of a home domain. It is the primary NIS+ domain that maintains information associated with them. A user or host's home domain can be determined directly using its NIS+ principal name, which is composed of the atomic user (login) name or the atomic host name, and the name of the NIS+ home domain. For example, user jsmith with home domain wiz.com has an NIS+ principal name, jsmith.wiz.com.
A user's NIS+ home domain corresponds to the user's FNS organizational unit and determines the binding for myens and myorgunit.
A host's NIS+ home domain corresponds to the host's FNS organizational unit and determines the binding for thisens, thisorgunit, user, and host.
Federating NIS+ with the global naming systems DNS or X.500 makes NIS+ contexts accessible outside of an NIS+ hierarchy. 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+ hierarchy can access contexts and perform operations from outside the hierarchy as an unauthenticated NIS+ client.
The command fncreate(1M) creates NIS+ tables and directories in the NIS+ hierarchy associated with the domain of the host on which it executes. The invoker of fncreate(1M) and other FNS commands is expected to have the necessary NIS+ credentials. (See nis+(1) and nisdefaults(1)). The environment variable NIS_GROUP of the process specifies the group owner for the NIS+ objects thus created. In order to facilitate administration of the NIS+ objects, NIS_GROUP should be set to the name of the NIS+ administration group for the domain prior to executing fncreate(1M) and other FNS commands. Changes to NIS+-related properties, including default access control rights, could be effected using NIS+ administration tools and interfaces after the context has been created. The NIS+ object name that corresponds to an FNS composite name can be obtained using fnlookup(1) and fnlist(1).
fnlist(1), fnlookup(1), nis+(1), nischgrp(1), nischmod(1), nischown(1), nisdefaults(1), nisls(1), fncreate(1M), xfn(3XFN), fns(5), fns_dns(5), fns_files(5), fns_initial_context(5), fns_nis(5), fns_policies(5), fns_references(5), fns_x500(5)