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+. See "How FNS Policies Relate to NIS+", below and "FNS and NIS+ Naming"

• NIS. See "How FNS Policies Relate to NIS" and "FNS and NIS Naming"

• Files. "How FNS Policies Relate to Files-Based Naming" and "FNS and Files-Based Naming"

  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+

See "FNS and NIS+ Naming" for overview and background information relating to FNS and NIS+. If you are not familiar with NIS+ and its terminology, refer to Part 1 and Glossaryof this guide. You will find it helpful to be familiar with the structure of a typical NIS+ environment.

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 a 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 21-4 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.

See Chapter 6, Security Overview, for a description of NIS+ security.

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.

How FNS Policies Relate to Files-Based Naming

See "FNS and Files-Based Naming" for overview and background information relating to FNS and files.

FNS provides the XFN interface for performing basic naming and attribute operations using local files as the naming service.

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.

Target Client Applications of FNS Policies

One goal of the FNS policies is to maintain coherence across the most commonly used tools, including the file system, the DeskSet tools, such as Calendar Manager, Print Tool, File Manager, and Mail Tool, and services that support these tools, such as RPC, email, and print subsystems.

---

Note -

Some of these examples are not currently implemented in the Solaris environment. They are listed here to illustrate how FNS can be used.

---

• Calendars. Instead of using names of the form username@hostname to access someone's calendar, in most cases you simply supply a site, organization, or user's name. You should also be able to use composite names to name calendars. For example, when federated under FNS, names of the following form are acceptable to calendar manager:

  • bernadette

  • user/bernadette

  • site/pine.bldg-5 (calendar for Pine conference room)

  • org/sales (calendar for the sales organization)

• Printing. Instead of naming a specific printer by its name, you should be able to name a printer relative to a user, site, or organization. For example:

  • ilych (ilych's default printer)

  • org/sales (an organization's default printer)

  • site/pine.bldg-5 (printer in the Pine conference room)

• File access. You should be able to use composite names to name file systems and files. The automounter should use FNS to make resolution of composite names possible. For example, you should be able to use a file name like /xfn/user/baruch/fs/.cshrc to reference the .cshrc file for user baruch.

• RPC. Instead of addressing services by their host name, program, and version numbers, you should be able to name the service using a composite name. For example, you should be able to name an RPC service relative to a user or an organization such as: user/hatori/service/rpc.

• Mail - Similarly, composite names can be used to name mail destinations. You should be able to use names such as the following:

  • angus

  • user/angus

  • org/mlist (an organization's mailing list)

  • site/pine.bldg-5 (mailbox of the conference room coordinator)

• Other desktop applications - You should be able to pass composite names to other desktop applications such as spreadsheets, document preparation tools, fax tools, and so on. Some of these applications attach their own namespace to the service namespace, thus becoming part of the FNS federation.

Example Applications: Calendar Service

This is a description of how one application, a calendar service, could be modified to use FNS policies. This example illustrates how FNS composite names might be presented to and accepted from users.

The DeskSet's calendar service is typical of client-server applications. Calendar servers run on some set of machines and maintain the users' calendars. Calendar Manager (cm) runs on the desktop and contacts the appropriate server to obtain the calendars of interest.

The calendar service could benefit from FNS using a simple registry/lookup model as follows:

• Binding - Upon startup, the server registers the calendars that it manages by binding a reference containing its own ONC+ RPC address (host, program, version) to the composite name for each calendar it manages, such as user/jsmith/service/calendar.

• Lookup - When using cm, the user specifies another user's calendar simply by entering the user's name (for example, hirokani) or selecting it from a list of names previously entered. Given the user name hirokani, cm composes the composite name user/hirokani/service/calendar and uses this to look up the RPC address that it needs to communicate with the server that manages that calendar.

  In the previous example, we used the name "calendar" to denote a calendar binding. The developers of the calendar service should register the name "calendar" with the FNS administrator, much as RPC programs are registered with the RPC administrator. Refer to "Service Name and Reference Registration".

  ---

  Note -

  The name "calendar" used here is an example. FNS policy does not specify the names of specific services.

  ---

  The calendar service could take further advantage of FNS policy by allowing calendars to be associated with sites, organizations, and hosts, while still naming them in a uniform way. For example, by allowing calendars to be associated with a conference room (a site), the service can be used to "multibrowse" the conference room's calendar as well as a set of user calendars to find an available time for a meeting in that room. Similarly, calendars can be associated with organizations for group meetings and hosts for keeping maintenance schedules.

  The cm calendar manager could simplify what the user needs to specify by following some simple steps.

1. cm uses a tool for accepting composite names from the user and constructing the name of the object whose calendar is of interest.

   The object is the name of a user, a site, a host, or an organization. For example, the user might enter the name kuanda and the calendar manager generates the composite name user/kuanda. This tool could be shared amongst a group of DeskSet applications.

2. cm uses the XFN interface to compose this name with the suffix /service/calendar to obtain the name of the calendar.

3. This calendar name is then resolved relative to the process's initial context.

   Continuing with the example, this results in the resolution of the name user/kuanda/service/calendar. Similarly, if the user enters the name of a site, pine.bldg-5, cm generates the name site/pine.bldg-5/service/calendar for resolution.

   Other services such as printing and mail could take advantage of the FNS policies in a similar way.