site
The namespace identifier site (or _site) is bound in the initial context to the root of the site naming system of the top organizational unit of the enterprise to which the host running the process belongs.
From the initial context, the names site and thisens/site resolve to the same context. For example, if the host running the process is the machine aldebaran and aldebaran is in the enterprise doc.com., the name site/pine.bldg-5 names a conference room, pine in building 5 of doc.com.
FNS and Enterprise Level Naming
FNS provides a method for federating multiple naming services under a single, simple interface for basic naming operations. FNS is designed to work with three enterprise-level name services, NIS+, NIS and Files. FNS is also designed to work with applications such as printer and calendar service as described in "Target Client Applications of FNS Policies".
How FNS Policies Relate to NIS+
FNS stores bindings for enterprise objects in FNS tables which are located in domain-level org_dir NIS+ directories on NIS+ servers. FNS tables are similar to NIS+ tables. These FNS tables store bindings for the following enterprise namespaces:
Organization namespaces as described in "NIS+ Domains and FNS Organizational Units".
Hosts namespaces as described in "NIS+ Hosts and FNS Hosts".
Users namespace as described in "NIS+ Users and FNS Users".
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 a printer service and calendar service relative to the organization, hosts, and users.
NIS+ Domains and FNS Organizational Units
FNS names organization, user, and host enterprise objects within NIS+ which is the preferred Solaris enterprise name service. An NIS+ domain is comprised of logical collections of users and machines and information about them, arranged to reflect some form of hierarchical organizational structure within an enterprise.
FNS is implemented on NIS+ by mapping NIS+ domains to FNS organizations. An organizational unit name corresponds to an NIS+ domain name and is identified using either the fully qualified form of its NIS+ domain name, or its NIS+ domain name relative to the NIS+ root. The top of the FNS organizational namespace is mapped to the NIS+ root domain and is accessed using the name org/ from the initial context.
In NIS+, users and hosts have a notion of a home domain. A host or user's home domain is the NIS+ domain that maintains information associated with them. A user or host's home domain can be determined directly using its NIS+ principal name. An NIS+ principal name is composed of the atomic user (login) name or the atomic host name and the name of the NIS+ home domain. For example, the user sekou with home domain doc.com. has an NIS+ principal name sekou.doc.com and the machine name vega has an NIS+ principal name vega.doc.com.
A user's NIS+ home domain corresponds to the user's FNS organizational unit. Similarly, a host's home domain corresponds to its FNS organizational unit.
Trailing Dot in Organization Names
The trailing dot in an organization name indicates that the name is a fully qualified NIS+ domain name. Without the trailing dot, the organization name is an NIS+ domain name to be resolved relative to the NIS+ root domain.
For example, if the NIS+ root domain is doc.com., with a subdomain sales.doc.com., the following pairs of names refer to the same organization:
Table 25-28 Example of Relative and Fully Qualified Organization Names Under NIS+
Relative Name | Fully Qualified Name |
|---|---|
org/ | org/doc.com. |
org/sales | org/sales.doc.com. |
The name org/manf. (with trailing dot) would not be found, because there is no NIS+ domain with just the manf. name.
NIS+ Hosts and FNS Hosts
Hosts in the NIS+ namespace are found in the hosts.org_dir table of the host's home domain. Hosts in an FNS organization 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 table.
NIS+ Users and FNS Users
Users in the NIS+ namespace are listed in the passwd.org_dir table of the user's home domain. Users in an FNS organization 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 table.
NIS+ Security and FNS
The FNS fncreate command creates FNS tables and directories in the NIS+ hierarchy associated with the domain of the host on which the command is run. In order to run fncreate, you must be an authenticated NIS+ principle with credentials authorizing you to Read, Create, Modify, and Destroy NIS+ objects in that domain. You will be the owner of the FNS tables created by fncreate. One way to obtain this authorization is to be a member of the NIS+ group that has administrator privileges in the domain.
The NIS_GROUP environment variable should be set to name of the NIS+ administration group for the domain prior to running fncreate. You can specify whether or not individual users can make changes to FNS data that relates to them.
How FNS Policies Relate to NIS
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 an 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.
How FNS Policies Relate to Files-Based Naming
FNS stores bindings for enterprise objects in files which are located in a /var/fn directory which is normally NFS mounted on each machine. These FNS files store bindings for the following enterprise namespaces:
Organization which provides a namespace for naming objects relative to the entire enterprise. When local files are the underlying naming service, there is a single organizational unit context that represents the entire system. This organization unit context is always identified in FNS as org//.
Hosts namespace which correspond to the /etc/hosts file. FNS provides a context for each host in the /etc/hosts file.
Users namespace which correspond to the /etc/passwd file. FNS provides a context for each user in the /etc/passwd file.
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 files in the /var/fn directory of the machine on which the command is run. To run fncreate, you must have super-user privileges on that machine. Based on UNIX user IDs, individual users are allowed to modify their own contexts, bindings, and attributes using FNS commands.