test

Solaris Naming Administration Guide

Part V Administering FNS

This part describes the Federated Naming Service (FNS) and how to administer it.

Chapter 20 FNS Quickstart

This chapter provides a summary overview of FNS, a brief description of setup and configuration steps, and a programming example. Experienced administrators may find that this quick start chapter is all that they need.

For more detailed information, see the remaining chapters of this part. For more detailed initial FNS setup and configuration information, see Solaris Naming Setup and Configuration Guide.

Federated Naming Service (FNS)

Federated Naming Service (FNS) provides a method for federating multiple naming services under a single, simple interface for naming and directory operations. Naming services that can be linked with FNS include: NIS+, NIS, files, DNS, and X.500/LDAP.

X/Open Federated Naming (XFN)

The programming interface and policies that FNS supports are specified by XFN (X/Open Federated Naming).

Why FNS?

FNS is useful for the following reasons:

Composite Names and Contexts

Fundamental to FNS are the notions of composite names and contexts.

Composite Names

A composite name is a name that spans multiple naming systems.

A composite name consists of an ordered list of components. Each component is a name from the namespace of a single naming system. Individual naming systems are responsible for the syntax of each component. FNS defines the syntax for constructing a composite name using names from component naming systems. Composite names are composed left to right using the slash character (/) as the component separator.

For example, the composite name .../doc.com/site/bldg-5.alameda consists of four components: ..., doc.com, site, and bldg-5.alameda.

Contexts

A context provides operations for:

A context contains a set of name-to-reference bindings. Each reference contains a list of communication end-points or addresses. The federated naming system is formed by contexts from one naming system being bound in the contexts of another naming system. Resolution of a composite name proceeds from contexts within one naming system to those in the next until the name is resolved.

Attributes

Attributes may be applied to named objects. Attributes are optional. A named object can have no attributes, one attribute, or multiple attributes.

Each attribute has a unique attribute identifier, an attribute syntax, and a set of zero or more distinct attribute values.

XFN defines the base attribute interface for examining and modifying the values of attributes associated with existing named objects. These objects can be contexts or any other types of objects. Associated with a context are syntax attributes that describe how the context parses compound names.

The extended attribute interface contains operations that search for specific attributes and that create objects and their associated attributes.

Enterprise Naming Services

Enterprise-level naming services are used to name objects within an enterprise. FNS currently supports three enterprise-level naming services:

NIS+

NIS+ is the preferred enterprise-wide information service in the Solaris operating environment environment. FNS organization units correspond to NIS+ domains and subdomains. There is one orgunit context for each domain and subdomain.

Under NIS+, FNS context and attribute data are stored in NIS+ tables. These tables are stored in NIS+ directory objects named ctx_dir. There is a ctx_dir directory object for each NIS+ domain and subdomain, residing at the same level as the domain's groups_dir and org_dir directory objects. Thus, the directory object ctx_dir.sales.doc.com. contains FNS tables which store FNS context and attribute data for the sales.doc.com. domain.

Under NIS+, you use FNS and NIS+ commands to work with the information in FNS tables. Do not edit these tables directly or manipulate them with UNIX commands.

NIS

NIS is an enterprise-wide information service in the Solaris environment. Each enterprise is a single NIS domain. There is one FNS organizational unit which corresponds to the single NIS domain.

Under NIS, FNS context and attribute data are stored in NIS maps. These maps are stored in a /var/yp/domainname directory on a NIS server. Under NIS, the super user can use FNS commands to work with the information in FNS maps.

NIS Clients Can Update Contexts With FNS if SKI is Running

If certain conditions are met, any NIS client (machine, process, or user) can use FNS commands such as fncreate_fs or fncreate_printer to update the client's own contexts. This allows NIS clients to use FNS commands to update applications such as Printer Administrator, CDE Calendar Manager, Admin Tool and others.

For non-super-users to update their own contexts with FNS commands, the following conditions must be met:

Note -

SKI does not support 64-bit mode. Thus, NIS clients cannot update contexts in 64-bit mode.

Files-Based

Files refers to the naming files normally found in a machine's /etc directory. These machine-based files contain UNIX user and password information, host information, mail aliases, and so forth. They also support Solaris-specific data such as the automount maps.

Under a files-based naming system, FNS context and attribute data is stored in files. These FNS files are stored in machine's /var/fn directory. (The /var/fn directory does not have to be on each machine, it could be exported from an NFS file server.)

Under a files naming system, you use FNS commands to work with the information in FNS files.

Global Naming Services

FNS also supports federating NIS+ and NIS with DNS and X.500. This means that you can connect enterprise level namespaces with global namespaces to make the enterprise objects accessible in the global scope.

FNS currently supports the following global naming services:

FNS Naming Policies

FNS defines naming policies so that users and applications can depend on and use the shared namespace.

Within an enterprise, there are namespaces for organizational units, sites, hosts, users, files and services, referred to by the names orgunit, site, host, user, fs (for file system), and service. These namespaces can also be named by preceding each name with an underscore (_). For example, host and _host are considered identical.

Table 20-1 summarizes the FNS policies for enterprise-level namespaces.

Table 20-1 FNS Policy Summary

Context Type 

Subordinate Contexts 

Parent Contexts 

orgunit _orgunit

site user host fs service

enterprise root 

site _site

user host fs service

enterprise root 

orgunit

user _user

service fs

enterprise root 

orgunit

host _host

service fs

enterprise root 

orgunit

service _service

Printer and other applications 

enterprise root 

orgunit site user host

fs _fs(file system)

(none) 

enterprise rootorgunit site user host

Organization Names

The binding of an FNS orgunit is determined by the underlying naming service:

The types of objects that may be named relative to an organizational unit name are: user, host, service, fs, and site. For example:

Site Names

Site names are created as needed. The types of objects that may be named relative to a site name are: user, host, service and fs. For example:

User Names

User names correspond to names in the corresponding passwd table in NIS+, the passwd map in NIS, or the /etc/passwd file under files. A user's file context is obtained from his or her passwd entry.

The types of objects that may be named relative to a user name are: service, and fs. For example:

Host Names

Host names correspond to names in the corresponding hosts table in NIS+, the hosts map in NIS, or the /etc/hosts file under files. The host's file context corresponds to the files systems exported by the host.

The types of objects that may be named relative to a host name are: service, and fs. For example:

Service Names

Service names correspond to, and are determined by, service applications. The service context must be named relative to an organization, user, host, or site context. For example:

File Names

File system names correspond to file names. For example:

Getting Started

To begin using FNS with your underlying name service, you run the fncreate command.

The fncreate command recognizes the underlying naming service in which FNS contexts are to be created (such as, NIS+, NIS, or files). To specify a specific naming service, you must run the fnselect command as explained in "Designating a Non-Default Naming Service"..

Designating a Non-Default Naming Service

By default:

You can also explicitly specify a non-default target naming service by using the fnselect command. For example the following command selects the target naming service to be NIS. 


# fnselect nis

Creating the FNS Namespace

Once the naming service has been selected either using the default policy or explicitly via fnselect, you can execute the following command to create the FNS namespace: 


# fncreate -t org org//

This creates all the necessary contexts for users and hosts in the corresponding naming service.

NIS+ Considerations

When your primary enterprise-level naming service is NIS+, take into account the following points.

NIS+ Domains and Subdomains

The command syntax shown above creates the FNS namespace for the root NIS+ domain. To specify a domain other than the root, add the domain name between the double slashes, as in:


# fncreate -t org org/sales.doc.com./

Note the trailing dot after the fully qualified sales.doc.com. domain name.

Space and Performance Considerations

The fncreate commands creates NIS+ tables and directories in the ctx_dir directory. The ctx_dir directory object resides at the same level as the NIS+ groups_dir and org_dir directory objects of the domain.

NIS+ Security Requirements

The user who runs fncreate and other FNS commands is expected to have the necessary NIS+ credentials.

The environment variable NIS_GROUP specifies the group owner for the NIS+ objects created by fncreate. In order to facilitate administration of the NIS+ objects, NIS_GROUP should be set to the name of the NIS+ group responsible for FNS administration for that domain prior to executing fncreate 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 and fnlist, described later in this document.

NIS Considerations

The fncreate command must be executed by superuser on the NIS system that will serve as the NIS master server for the FNS maps.

The NIS maps used by FNS are stored in /var/yp/domainname.

Any changes to the FNS information can only be done by the superuser on the FNS NIS master server using FNS commands.

Files Considerations

When using fncreate with the -t org option to create your FNS namespace, the command must be executed by superuser on the machine that owns the file system on which /var is located. The files used by FNS are stored in the /var/fn directory.

Once users' contexts are created, users are allowed to modify their own contexts based on their UNIX credentials.

If exported, the file system /var/fn can be mounted by other systems to access the FNS namespace.

Browsing the FNS Namespace

Once the namespace has been set up, you can browse using the following commands:

Listing Context Contents

The fnlist command displays the names and references bound in the context of name. 


fnlist [-lvA] [name]
Table 20-2 fnlist Command Options

Option 

Description 

name

A composite name. Displays the names bound in the context of name

-v

Verbose. Displays the binding in more detail 

-l

Also displays the bindings of the names bound in the named context 

-A

Forces fnlist to obtain its information from the authoritative server. Under NIS and NIS+, that is the domain master server. The -A option has no effect when the primary naming service is files.

For example:

To list names in the initial context:


% fnlist

To list in detail all the users in the current organizational unit:


% fnlist -v user

To list the contents of the service context for the user pug:


% fnlist user/pug/service

To list names and bindings from the authoritative server:


% fnlist -l -A

Displaying the Bindings of a Composite Name

The fnlookup command shows the binding of the given composite name. 


fnlookup [-vAL] [name]
Table 20-3 fnlookup Command Options

Option 

Description 

name

The name of a context. Displays the binding and XFN link of name

-v

Verbose. Displays the binding in more detail 

-L

Also displays the XFN link that the name is bound to 

-A

Forces fnlist to obtain its information from the authoritative server. Under NIS and NIS+, that is the domain master server. The -A option has no effect when the primary naming service is files-based.

For example: to display the binding of user/ana/service/printer:


# fnlookup user/ana/service/printer

Showing the Attributes of a Composite Name

The fnattr command displays (and updates) the attributes of the given composite name.

For example, to search for the attributes associated with a user named ada:


# fnattr user/ada

To search for the attributes associated with a printer named laser-9:


# fnattr thisorgunit/service/printer/laser-9

See "Working With Attributes" for more details.

Searching for FNS Information

The fnsearch command displays the names and, optionally, the attributes and references of objects bound at or below a composite name whose attributes satisfy the given search criteria.

For example:

To list the users and their attributes who have an attribute called realname:


% fnsearch user realname

To list the users with the attribute realname whose value is Ravi Chattha:


% fnsearch user "realname == 'Ravi Chattha'"

The fnsearch command uses the common Boolean operators. Note the use of double and single quotes and double equals sign in the above example.

Updating the Namespace

Once the namespace has been set up, you can add, delete, and modify elements using the following commands:

FNS Administration Privileges

FNS System administration varies according to the underlying naming service:

The ability of users to make changes to their own user sub-contexts varies according to the underlying naming service:

Binding a Reference to a Composite Name

The fnbind command is used to bind an existing reference (name) to a new composite name.


fnbind -r [-s][-v][-L] name [-O|-U] newname reftype addrtype [-c|-x] address
Table 20-4 fnbind Command Options

Option 

Description 

name

The existing composite name 

newname

The composite name of the new binding 

addrtype

Address type to use. Applications-specific such as onc_cal_str.

address

Address contents to use. For example, tsvi@altair.

reftype

Reference type to use. Applications-specific such as one_calendar.

-s

Bind to newname even if it is already bound. This replaces the previous binding of newname. Without -s, fnbind fails if newname is already bound.

-v

Display the reference that will be bound to newname.

-L

Create an XFN link using oldname and bind it to newname.

-r

Bind newname to the reference constructed by the command line arguments.

-c

Store address contents in the form as entered, do not use XDR-encoding.

-x

Convert address to a hexadecimal string without converting it to XDR-encoding.

-O

The identifier format is FN_ID_ISO_OID_STRING, an ASN.1 dot-separated integer list string. 

-U

The identifier format is FN_ID_DCE_UUID, a DCE UUID in string form. 

For example:

To add a calendar binding for the user jamal:


# fnbind -r user/jamal/service/calendar onc_calendar onc_cal_str
 jamal@cygnus

To replace the existing binding of org//service/Sparc-4 with that of org//service/printer:


# fnbind -s org//service/printer org//service/Sparc-4

To copy the reference site/bldg-5/service/printer to user/ando/service/printer:


# fnbind site/bldg-5/service/printer user/ando/service/printer

To bind the reference site/bldg-5/service/printer to user/ando/service/printer using a symbolic link:


# fnbind -L site/bldg-5/service/printer user/ando/service/printer

To bind the name thisens/service/calendar to the address staff@altair, when staff@altair is a reference of the type onc_cal and an address of the type onc_cal_str:


# fnbind -r thisens/service/calendar onc_calendar onc_cal_str staff@altair

To bind newname to the reference constructed by its command line address 


# fnbind -r [-sv] newname [-O|-U] reftype {[-O|-U] addrtype [-c|-x] address}

Removing Bindings

The fnunbind name command is used to remove bindings.

For example: to remove the binding for user/jsmith/service/calendar:


# fnunbind user/jsmith/service/calendar

Creating New Contexts

The fncreate command is used to create contexts. 


fncreate -t context [-f file] [-o] [-r reference] [-s] [-v] [-D] name
Table 20-5 fncreate Command Options

Option 

Description 

-t context

Create context of type context. Context types can be: org, hostname, host, username, user, service, fs, site, nsid, and generic.

-f file

Use an input file to list users and hosts for whom to create contexts. 

-r reference

Type of reference. The -r reference option can only be used with -t generic.

name

A composite name 

-o

Create only the context identified by name.

-s

Overwrite (supersede) any existing binding. If -s is not used, fncreate will fail if name is already bound.

-D

Display information about each context and corresponding tables, directories, and files as it is created. 

-v

Verbose. Display information about each context as it is displayed. 

For example:

To create a context and subcontexts for the root organization:


# fncreate -t org org//

To create a context, and subcontexts, for the host deneb:


# fncreate -t host host/deneb

To create a context, service and file subcontexts, and then add a calendar binding for the user sisulu:


# fncreate -t user user/sisulu
# fnbind -r user/sisulu onc_calendar onc_cal_str sisulu@deneb

To create a site context for the sales organization:


# fncreate -t site org/sales/site/

The site context supports a hierarchal namespace, with dot-separated right-to-left names, which allows sites to be partitioned by their geographical coverage relationships. For example, to create a site context alameda and a site subcontext bldg-6.alameda for it:


# fncreate -t site org/sales/site/alameda
# fncreate -t site org/sales/site/bldg-6.alameda

Creating File Contexts

Table 20-6 fncreate_fs Command Options

Option 

Description 

name

The name of the file context 

options

Mount options 

mount

Mount location 

-f file

Input file 

-v

Verbose. Displays information about the contexts being created 

-r

Replace the bindings in the context name with those specified in the input.

For example:

To create a file system context named data for the sales organization bound to the /export/data path of an NFS server named server4.


# fncreate_fs org/sales/fs/data server4:/export/data

To create a hierarchy of file system contexts for the sales organization named buyers and buyers/orders mounted on two different servers:


# fncreate_fs org/sales/fs/buyers server2:/export/buyers
# fncreate_fs org/sales/fs/buyers/orders server3:/export/orders

To create a file system context named leads for the sales organization bound to a server and path specified by an input file named input_a:


# fncreate_fs -f input_a org/sales/fs/leads

(See the fncreate_fs man page for information on input file format.)

Creating Printer Contexts

The fncreate_printer command creates printer contexts for organizations, users, hosts and site contexts. The printer context is created under the service context of the respective composite name. 


fncreate_printer [-vs] name printer [prntaddr]
 

fncreate_printer [-vs] [-f [file]] name
Table 20-7 fncreate_printer Command Options

Option 

Description 

name

The name of the org, host, user, or site of the printer 

printer

The name of the printer 

prntaddr

The printer address in the form <addresstype>=<address>

-f file

Use the named file as input for a list of printers to be created. The input file is in the format of the /etc/printers.conf file. If neither a printer name nor a -f file is specified, fncreate_printer uses the /etc/printer.conf file on the machine where fncreate_printer is run as a default input file.

-s

Replace an existing address with the same address-type. 

-v

Verbose. Displays the binding in more detail 

For example:

To create printers for the sales organization based on the printers listed in the /etc/printers.conf file of the machine on which fncreate_printer is run: 


# fncreate_printer -s org/sales/

Assume that the machine altair is the server for a printer named Sparc-5. To create a printer named invoices for the user nguyen that is actually the Sparc-5 printer:


# fncreate_printer user/nguyen invoices bsdaddr=altair,Sparc-5

It is also possible to organize printers hierarchically. For example, the fncreate_printer command can create printer contexts for the printers, color, color/inkjet and color/Sparc with the resulting contexts:


org/doc.com/service/printer/color
org/doc.com/service/printer/color/inkjet
org/doc.com/service/printer/color/Sparc

To create the above contexts, you would run:


# fncreate_printer org/doc.com color bsdaddr=colorful,color
# fncreate_printer org/doc.com color/inkjet bsdaddr=colorjet,inkjet
# fncreate_printer org/doc.com color/Sparc bsdaddr=colorprt,Sparc

Destroying Contexts

The fndestroy command is used to destroy empty contexts.

For example, to destroy the service context of the user patel:


# fndestroy user/patel/service

Working With Attributes

The fnattr command can be used to add, delete or modify attributes associated with a name. You can make modifications one at a time, or batch several within the same command.

Table 20-8 fnattr Command Options

Option 

Description 

name

The composite name 

attrib

The identifier of an attribute 

values

One or more attribute values 

oldvalue

An attribute value to be replaced by a new value 

newvalue

The attribute value that replaces an old value 

-a

Add an attribute 

-d

Destroy an attribute 

-l

List attributes 

-m

Modify an attribute 

-s

Replace all old attribute values with the new values for the attribute specified. 

-O

The identifier format is FN_ID_ISO_OID_STRING, an ASN.1 dot-separated integer list string. 

-U

The identifier format is FN_ID_DCE_UUID, a DCE UUID in string form. 

For example:

To show all of the attributes associated with the user name rosa:


# fnattr user/rosa

To display the size attribute associated with the user uri:


# fnattr user/uri/ size

For a user named devlin, to add an attribute named shoesize with a value of small, delete the hatsize attribute, and change the dresssize attribute value from 12 to 8:


# fnattr user/devlin -a shoesize small -d hatsize -m dresssize 12 8

Federating a Global Namespace

You can federate NIS+ or NIS to a global naming service like DNS and X.500.

To federate an NIS+ or NIS namespace under DNS or X.500, you first need to obtain the root reference for the NIS+ hierarchy or NIS domain.

From the point of view of the global name service, the root reference is known as the next naming system reference because it refers to the next naming system beneath the DNS domain or X.500 entry. To federate NIS+ or NIS with a global name service, you add the root reference information to that global service.

Once you have added the root reference information to the global service, clients outside of your NIS+ hierarchy or NIS domain can access and perform operations on the contexts in the NIS+ hierarchy or NIS domain. Foreign NIS+ clients access the hierarchy as unauthenticated NIS+ clients.

For example:

If NIS+ is federated underneath the DNS domain doc.com., you can now list the root of the NIS+ enterprise using the command


# fnlist .../doc.com/

If NIS+ is federated underneath the X.500 entry /c=us/o=doc, you can list the root of the NIS+ enterprise using the command:


# fnlist .../c=us/o=doc/

Note the mandatory trailing slash in both examples.

Copying and Converting FNS Contexts

The fncopy command can be used to copy or convert an FNS context and attributes to a new FNS context.

By using the -i and -o options, you can copy FNS contexts based on one underlying enterprise-level name service to a context based on a different underlying name service. For example, if you have an FNS installation running on top of NIS, and you upgrade your NIS service to NIS+, you can use fncopy to create a new context using NIS+.

Note that:

Table 20-9 fncopy Command Options

Option 

Description 

-i oldservice

The old (input) underlying enterprise-level name service. For example, -i nis specifies that the old service is NIS. Allowed values are files, nis, nisplus.

-o newservice

The new (output) underlying enterprise-level name. For example, o nisplus specifies that the new service is NIS+. Allowed values are files, nis, nisplus.

-f filename

A text file listing FNS contexts to be copied. In the absence of the -i and -o options, contexts must be identifies using global names.

oldcontext

The name of the context being copied 

newcontext

The name of the context being created or copied to. 

For example, to copy the doc.com printer contexts (and sub-contexts) and bindings to orgunit/east/doc.com:


# fncopy .../doc.com/service/printer .../doc.com/orgunit/east/service/printer

To copy the NIS FNS users' contexts specified in the file user_list to a NIS+ FNS users' context of the orgunit west/doc.com:


# fncopy -i nis -o nisplus -f /etc/user_list thisorgunit/user org/doc.com/user

Namespace Browser Programming Examples

The programming examples in this section shows the usage of XFN APIs to perform the following operations:

Listing Names Bound in a Context

The example below shows XFN operations to list a context.


#include <stdio.h>
#include <xfn/xfn.h>
#include <string.h>
#include <stdlib.h>
/*
 This routine returns the list of names
 bound under the given context (ctx_name).
 Examples of ctx_name are "user", "thisorgunit/service",
	host/alto/service, user/jsmit/service/calendar, etc.,
*/
typedef struct fns_listing {
	char *name;
	struct fns_listing *next;
} fns_listing;
fns_listing *
fns_list_names(const char *ctx_name)
{
	FN_status_t *status;
	FN_ctx_t *initial_context;
	FN_composite_name_t *context_name;
	FN_namelist_t *name_list;
	FN_string_t *name;
	unsigned int stat;
	fns_listing *head = 0, *current, *prev;
	int no_names = 0;
	status = fn_status_create();
	/* Obtain the initial context */
	initial_context = fn_ctx_handle_from_initial(0, status);
	if (!fn_status_is_success(status)) {
		fprintf(stderr, "Unable to obtain intial context\n");
		return (0);
	}
	context_name = fn_composite_name_from_str((unsigned char *)
                  ctx_name);
	/* FNS call to list names */
	name_list = fn_ctx_list_names(initial_context, context_name,
               status);
	if (!fn_status_is_success(status)) {
		fprintf(stderr, "Unable to list names\n");
		return (0);
	}
	/* Obtain the names individually */
	while (name = fn_namelist_next(name_list, status)) {
		no_names++;
		current = (fns_listing *) malloc(sizeof(fns_listing));
		current->name = (char *)
		 malloc(strlen((char *) fn_string_str(name, &stat)) + 1);
		strcpy(current->name, (char *) fn_string_str(name, &stat));
		current->next = 0;
		if (head) {
			prev->next = current;
			prev = current;
		} else {
			head = current;
			prev = current;
		}
		fn_string_destroy(name);
	}
	fn_namelist_destroy(name_list);
	fn_status_destroy(status);
	fn_ctx_destroy(initial_context);
	return (head);

Creating a Binding

Example 20-1 shows how to create a binding.

Example 20-1 Creating a Binding


#include <stdio.h>
#include <xfn/xfn.h>
#include <string.h>
/*
 This routine creates a binding with a name provided by "name"
 and having a reference type "reference_type" and address type
 "address_type".
 An example of using the function could be:
	 fns_create_bindings(
	 "user/jsmith/service/calendar",
	 "onc_calendar",
	 "onc_cal_str",
	 "jsmith&calserver");
*/
int fns_create_bindings(
 char *name,
 char *reference_type,
 char *address_type,
 char *data)
{
	int return_status;
	FN_composite_name_t *binding_name;
	FN_identifier_t ref_id, addr_id;
	FN_status_t *status;
	FN_ref_t *reference;
	FN_ref_addr_t *address;
	FN_ctx_t *initial_context;
	/* Obtain the initial context */
	status = fn_status_create();
	initial_context = fn_ctx_handle_from_initial(0, status);
	/* Check status for any error messages */
	if ((return_status = fn_status_code(status)) != FN_SUCCESS) {
		fprintf(stderr, "Unable to obtain the initial context\n");
		return (return_status);
	}
	/* Get the composite name for the printer name */
	binding_name = fn_composite_name_from_str((unsigned char *) name);
	/* Construct the Address */
	addr_id.format = FN_ID_STRING;
	addr_id.length = strlen(address_type);
	addr_id.contents = (void *) address_type;
	address = fn_ref_addr_create(&addr_id,
		strlen(data), (const void *) data);
	/* Construct the Reference */
	ref_id.format = FN_ID_STRING;
	ref_id.length = strlen(reference_type);
	ref_id.contents = (void *) reference_type;
	reference = fn_ref_create(&ref_id);
	/* Add Address to the Reference */
	fn_ref_append_addr(reference, address);
	
	/* Create a binding */
	fn_ctx_bind(initial_context, binding_name, reference, 0, status);
	/* Check the error status and return */
	return_status = fn_status_code(status);
	fn_composite_name_destroy(binding_name);
	fn_ref_addr_destroy(address);
	fn_ref_destroy(reference);
	fn_ctx_destroy(initial_context);
	return (return_status);
}

Listing and Working Wtih Object Attributes

The examples below show techniques to list and work with attributes of an object.

Listing an Object's Attributes

The example below shows how to list the attributes of an object.


#include <stdio.h>
#include <xfn/xfn.h>
/*
 This routine prints all the attributes associated
 with the named object to the standard output.
 Examples of using the function:
 	fns_attr_list("user/jsmith");
	fns_attr_list("thisorgunit/service/printer/color");
*/
void fns_attr_list(const char *name)
{
	FN_composite_name_t *name_comp;
	const FN_identifier_t *identifier;
	FN_attribute_t *attribute;
	const FN_attrvalue_t *values;
	char *id, *val;
	FN_multigetlist_t *attrset;
	void *ip;
	FN_status_t *status;
	FN_ctx_t *initial_context;
	name_comp = fn_composite_name_from_str((unsigned char *) name);
	status = fn_status_create();
	/* Obtain the initial context */
	initial_context = fn_ctx_handle_from_initial(0, status);
	if (!fn_status_is_success(status)) {
		fprintf(stderr, "Unable to obtain intial context\n");
		return;
	}
	/* Obtain all the attributes */
	attrset = fn_attr_multi_get(initial_context, name_comp, 0, 0,
            status);
	if (!fn_status_is_success(status)) {
		fprintf(stderr, "Unable to obtain attributes\n");
		return;
	}
	/* List all attributes */
	while (attribute = fn_multigetlist_next(attrset, status)) {
		identifier = fn_attribute_identifier(attribute);
		switch(identifier->format) {
		case FN_ID_STRING:
			id = (char *) malloc(identifier->length + 1);
			memcpy(id, identifier->contents, identifier->length);
			id[identifier->length] = '\0';
			printf("Attribute Identifier: %s", id);
			free(id);
			break;
		default:
			printf("Attribute of non-string format\n\n");
			continue;
		}
		for (values = fn_attribute_first(attribute, &ip);
		 values != NULL;
		 values = fn_attribute_next(attribute, &ip)) {
			val = (char *) malloc(values->length + 1);
			memcpy(val, values->contents, values->length);
			val[values->length] = '\0';
			printf("Value: %s", val);
			free(val);
		}
		fn_attribute_destroy(attribute);
		printf("\n");
	}
	fn_multigetlist_destroy(attrset);
	fn_ctx_destroy(initial_context);
	fn_status_destroy(status);
	fn_composite_name_destroy(name_comp);
}

Adding, Deleting, and Modifying an Object's Attributes

The example below shows how to add, delete, or modify an object's attributes.


#include <stdio.h>
#include <xfn/xfn.h>
/*
 This routine modifies an attribute associated
 with the named object. The modify operation supported are:
 	FN_ATTR_OP_ADD
 FN_ATTR_OP_ADD_EXCLUSIVE
 FN_ATTR_OP_REMOVE
 FN_ATTR_OP_ADD_VALUES
 FN_ATTR_OP_REMOVE_VALUES
 The function assumes the attribute values to be strings.
 Examples of using the function:
 The following function add an attribute of identifier "realname"
 with value "James Smith" to the user object "user/jsmith".
 	fns_attr_modify(
		"user/jsmith",
		"realname",
		"James Smith",
		FN_ATTR_OP_ADD);
 The following function removes an attribute of identifier 
 "location" from the printer object 
 "thisorgunit/service/printer/color".
 	fns_attr_modify(
		"thisorgunit/service/printer/color",
		"location",
		NULL,
		FN_ATTR_OP_REMOVE);
*/
static const char *attr_id_syntax = "fn_attr_syntax_ascii";
void fns_attr_modify(const char *name,
	const char *attr_id,
	const char *attr_value,
	unsigned int operation)
{
	FN_composite_name_t *name_comp;
	FN_identifier_t identifier, syntax;
	FN_attrvalue_t *values;
	FN_attribute_t *attribute;
	FN_status_t *status;
	FN_ctx_t *initial_context;
	name_comp = fn_composite_name_from_str((unsigned char *) name);
	status = fn_status_create();
	/* Obtain the initial context */
	initial_context = fn_ctx_handle_from_initial(0, status);
	if (!fn_status_is_success(status)) {
		fprintf(stderr, "Unable to obtain intial context\n");
		return;
	}
	/* Create the attribute to be added */
	/* First, the identifier */
	identifier.format = FN_ID_STRING;
	identifier.length = strlen(attr_id);
	identifier.contents = (void *) strdup(attr_id);
	/* Second, the syntax */
	syntax.format = FN_ID_STRING;
	syntax.length = strlen(attr_id_syntax);
	syntax.contents = (void *) strdup(attr_id_syntax);
	/* Third, the attribute value */
	if (attr_value) {
		values = (FN_attrvalue_t *) malloc(sizeof(FN_attrvalue_t));
		values->length = strlen(attr_value);
		values->contents = (void *) strdup(attr_value);
	} else
		values = NULL;
	/* Fourth, create the attribute */
	attribute = fn_attribute_create(&identifier, &syntax);
	/*Fifth, add the attribute value */
	if (values)
		fn_attribute_add(attribute, values, 0);
	
	/* Perform the XFN operation */
	fn_attr_modify(initial_context, name_comp, operation, attribute, 0,
status);
	if (!fn_status_is_success(status))
		fprintf(stderr, "Unable to perform attribute operation\n");
	fn_ctx_destroy(initial_context);
	fn_status_destroy(status);
	fn_composite_name_destroy(name_comp);
	fn_attibute_destroy(attribute);
	free(identifier.contents);
	free(syntax.contents);
	if (values) {
		free(values->contents);
		free(values);
 ]
]

Searching for Objects in a Context

The example below shows how to search for objects in a context with a specific attribute identifier and value.


#include <stdio.h>
#include <xfn/xfn.h>
#include <string.h>
#include <stdlib.h>
/*
 This routine searchs for objects in a context
 which has the specified attribute identifier and value.
*/
typedef struct fns_search_results {
	char *name;
	struct fns_search_results *next;
} fns_search_results;
static const char *attr_id_syntax = "fn_attr_syntax_ascii";
fns_search_results *
fns_attr_search(const char *name,
	const char *attr_id,
	const char *attr_value)
{
	FN_status_t *status;
	FN_ctx_t *initial_context;
	FN_composite_name_t *context_name;
	FN_searchlist_t *search_list;
	FN_string_t *search_name;
	FN_attribute_t *attribute;
	FN_attrset_t *attrset;
	FN_identifier_t identifier, syntax;
	FN_attrvalue_t *values;
	unsigned stat;
	fns_search_results *head = 0, *current, *prev;
	int no_names = 0;
	context_name = fn_composite_name_from_str((unsigned char *) name);
	status = fn_status_create();
	initial_context = fn_ctx_handle_from_initial(0, status);
	if (!fn_status_is_success(status)) {
		fprintf(stderr, "Unable to obtain intial context\n");
		return (0);
	}
	/* Construnct the attrset with attributes to be searched */
	/* First, the identifier */
	identifier.format = FN_ID_STRING;
	identifier.length = strlen(attr_id);
	identifier.contents = (void *) strdup(attr_id);
	/* Second, the syntax */
	syntax.format = FN_ID_STRING;
	syntax.length = strlen(attr_id_syntax);
	syntax.contents = (void *) strdup(attr_id_syntax);
	/* Third, the attribute value */
	values = (FN_attrvalue_t *) malloc(sizeof(FN_attrvalue_t));
	values->length = strlen(attr_value);
	values->contents = (void *) strdup(attr_value);
	/* Fourth, create the attribute */
	attribute = fn_attribute_create(&identifier, &syntax);
	/* Fifth, add the attribute value */
	fn_attribute_add(attribute, values, 0);
	/* Sixth, create attrset, and add the attribute */
	attrset = fn_attrset_create();
	fn_attrset_add(attrset, attribute, 0);
	search_list = prelim_fn_attr_search(initial_context,
	 context_name, attrset, 0, 0, status);
	if (!fn_status_is_success(status)) {
		fprintf(stderr, "Unable to list names\n");
		return (0);
	}
	while (search_name = prelim_fn_searchlist_next(search_list,
	 0, 0, status)) {
		no_names++;
		current = (fns_search_results *) 
    malloc(sizeof(fns_search_results));
		current->name = (char *)
		 malloc(strlen((char *) fn_string_str(search_name, &stat)) + 1);
		strcpy(current->name, (char *) fn_string_str(search_name, &stat));
		current->next = 0;
		if (head) {
			prev->next = current;
			prev = current;
		} else {
			head = current;
			prev = current;
		}
		fn_string_destroy(search_name);
	}
	fn_searchlist_destroy(search_list);
	fn_status_destroy(status);
	fn_ctx_destroy(initial_context);
	fn_attrset_destroy(attrset);
	fn_attribute_destroy(attribute);
	free(identifier.contents);
	free(syntax.contents);
	free(values->contents);
	free(values);
	return (head);
}

Chapter 21 Federated Naming Overview

This chapter describes the Federated Naming Service (FNS) which is Sun's implementation of the X/Open XFN federated naming standard.

XFN and FNS

Different name services are often embedded in different applications and services in a computing environment. Working with different name services presents significant difficulties to the application developer. Most applications are designed to use a single name service and have very limited access to objects in a distributed computing environment. Because different applications use different name services they expect names to be composed differently. They often use different names for what the user considers very similar objects. For example, you might be able to send mail to your friend Johanna using her name johanna@admin.doc.com, but be required to use another name, jsmith@altair, to access her calendar.

FNS, Sun's implementation of the XFN standard, allows you to name objects in a uniform way, yet still provide the functionality that applications and developers need.

Note -

In this manual it is important to distinguish between XFN and FNS. The FNS policies include some extensions to XFN policies, and these are explicitly defined with notes. Objects belonging to the XFN programming interface are designated as XFN objects to avoid confusion with other programming interfaces.

The XFN Model

This section describes the XFN naming model from several perspectives.

XFN Architectural Model

The primary services provided by a federated naming system are mapping a composite name to a reference and providing access to attributes associated with a named object. This section defines the elements of the XFN naming model.

Atomic Names

The smallest, indivisible component of a name is called an atomic name. For example, the machine name nismaster or the user name chou. An atomic name may have one or more attributes, or no attributes at all (see "Attributes").

References

A reference is the information on how to reach an object. A reference contains a list of addresses. An address identifies a communication endpoint (an object). For example, the address of a machine such as nismaster.doc.com, or a user's email address such as chou@doc.com.

A reference might contain multiple addresses that identify multiple communication endpoints for a single conceptual object or service. For example, a list of addresses might be required because the object is distributed or because the object can be accessed through more than one communication mechanism.

Note -

XFN cannot guarantee specific properties of addresses such as their stability, validity, or reachability. A client might be able to look up a name but not be able to use the returned reference because the client might not have support for any of the necessary communication mechanisms or might lack the necessary network connectivity to reach the address. Further, the address might be invalid from that origin or stale; these issues are the province of the convention between the name's binder, the clients, and the service provider specified in the address.

Contexts

A context is a set of atomic names bound to references, as shown in Figure 21-1. Every context has an associated naming convention. A context provides a lookup (resolution) operation, which returns the reference, and may provide operations such as binding names, unbinding names, and listing bound names. Contexts are at the heart of the lookup and binding operations.

Figure 21-1 An XFN `Context'

Graphic

Attributes

Attributes may be applied to named objects. Attributes are optional. A named object can have no attributes, one attributes, or multiple attributes.

Each attribute has a unique attribute identifier, an attribute syntax, and a set of zero or more distinct attribute values. Attributes are indicated by the dotted lines in Figure 21-1 above.

XFN defines the base attribute interface for examining and modifying the values of attributes associated with existing named objects. These objects can be contexts or any other types of objects. Associated with a context are syntax attributes that describe how the context parses compound names.

The extended attribute interface contains operations that search for specific attributes and that create objects and their associated attributes.

Compound Names

A compound name is a sequence of one or more atomic names. An atomic name in one context can be bound to a reference to another context of the same type, called a subcontext. Objects in the subcontext are named using a compound name. Compound names are resolved by looking up each successive atomic name in each successive context.

A familiar analogy for UNIX users is the file naming model, where directories are analogous to contexts, and path names serve as compound names. Furthermore, contexts can be arranged in a "tree" structure, just as directories are, with the compound names forming a hierarchical namespace.

For example:

Composite Names

A composite name is a name that spans multiple naming systems. Each component is a name from the namespace of a single naming system. Composite name resolution is the process of resolving a name that spans multiple naming systems.

Components are separated by slashes (/) and ordered from left to right, according to XFN composite name syntax. For example, the composite name

sales.doc.com/usr/local/bin

has two components, a DNS name (sales.doc.com) and a UNIX path name (usr/local/bin).

FNS Namespaces

Atomic names and reference addresses may also be resolved relative to one or more namespaces. By default, FNS provides six namespaces: org (for organization), site, host, user, service, and fs (for files).

FNS policies are used to determine how names associated with namespaces relate to each other. For example; a user is named sergei in the user namespace and is identified as /user/sergei. A calendar application is named in the service namespace and is identified as /service/calendar. With this system, you can then identify Sergei's calendar service as: /user/sergei/service/calendar. (See "Introduction to FNS and XFN Policies" for more information on namespaces and how they are used.)

If an application is expecting you to type a user name, the application can include the namespace identifier user/ in front of names that you enter. If the application needs to name one of the user's services, such as the user's default fax machine, it can append the service namespace and the name of the service (/service/fax), to the input supplied. Hence, a fax tool might take as input the user name jacques and then compose the full name user/jacques/service/fax for the default fax of the user jacques. Similarly, to access a person's calendar, you just need to type the person's user name. The application takes the input, raj, and uses it to construct the composite name, in this case, user/raj/service/calendar.

XFN Links

An XFN link is a special form of a reference that is bound to an atomic name in a context. Instead of an address, a link contains a composite name. Many naming systems support a native notion of link that can be used within the naming system itself. XFN does not specify whether there is any relationship between such native links and XFN links.

Initial Context

Every XFN name is interpreted relative to some context, and every XFN naming operation is performed on a context object. The initial context object provides a starting point for the resolution of composite names. The XFN interface provides a function that allows the client to obtain an initial context.

The policies described in Chapter 22, FNS Policies, specify a set of names that the client can expect to find in this context and the semantics of their bindings. This provides the initial pathway to other XFN contexts.

User's View

Users experience federated naming through applications. Typically, the user does not need to compose or know the full composite name of objects because the application takes care of constructing the composite names. This allows the user to interact with XFN-aware applications in a simple, intuitive, and consistent manner.

File System View

Users and applications also experience federated naming through the file system. The initial context is located under /xfn in the root directory. For example, user ingrid's to_do file has the XFN name, xfn/user/ingrid/fs/to_do.

To read this file, you could type:


% cat /xfn/user/ingrid/fs/to_do

Applications access the files under /xfn just as they do any other files. Applications do not need to be modified in any way, nor do they need to use the XFN API.

Application View

The way that client applications interact with XFN to access different naming systems is illustrated in a series of figures. Figure 21-2 shows an application that uses the XFN API and library.

Figure 21-2 Client Application Interaction With XFN

Graphic

Figure 21-3 shows the details beneath the API. A name service that is federated is accessed through the XFN client library and a context shared object module. This module translates the XFN calls into name service-specific calls.

Figure 21-3 Details Beneath XFN API

Graphic

API Usage Model

Many clients of the XFN interface are only interested in lookups. Their usage of the interface amounts to:

Once the client obtains a desired reference from the lookup operation, it constructs a client-side representation of the object from the reference.

Federated Naming Service

Within the Solaris environment, name services are integrated into other services such as the file system, the network information service, the mail system, and the calendar service. For example, the file system includes a naming system for files and directories; NIS+ service combines a naming system with a specialized information service.

Without FNS, users of the Solaris environment must use different, inconsistent names to refer to objects. For example: you might use the name jsmith@admin to send mail to Joan, the name jsmith@altair to access her calendar, and the name /home/jsmith/.cshrc to reach a file in her home directory. This disparity makes it hard for users to formulate names and hard for applications to automatically generate names on behalf of users. FNS policies define a coherent way for naming these objects.

FNS and Application Development

Applications also need naming services and applications in the Solaris environment must often deal with a diversity of name service interfaces. An application might also be exposed to a variety of often incompatible naming systems external to the Solaris environment. Local- and wide-area networks connect a heterogeneous array of hardware and operating systems, increasing the variety of potential interfaces. Not only do these naming interfaces differ widely, but the essential naming operations are often obscure.

FNS simplifies these problems in two ways:

FNS and Composite Names

Some applications use composite names to access objects in the Solaris environment. The commands mail and rcp are examples of such applications.

rcp uses composite names such as sirius:/usr/jsmith/memo, which has two components: the host name sirius and the file name (path) /usr/jsmith/memo. The mail program uses composite names such as jsmith@altair, which has two components: the user name jsmith and the host name altair.

Each application defines its own composition rule for names, parses the composite names, and resolves composite names. Composition rules often differ from one application to another.

Without FNS, the user must remember which applications permit composite naming and which do not. For example, the composite name sirius:/tmp/saleslist is accepted by the rcp command, but not by the cp command.

Without FNS, the user must also remember the different composition rules used among different applications. Applications that support composite names on their own can use only a small and specific set of naming systems, and must be changed whenever a new type of naming system is added.

Incorporating a uniform policy for composite naming into the computing platform permits any application to support composite names in a uniform way. The application passes one name to one interface.

FNS Policy Principles

The following principles were used to arrive at FNS policies:

FNS in the Solaris Environment

In the Solaris environment, the FNS implementation currently consists of name services implemented on top of:

FNS will become increasingly more visible to Solaris users as more applications and systems use FNS.

Solaris Enterprise-Level Naming Services

An enterprise-level naming service identifies (names) machines (hosts), users and files within an enterprise-level network. FNS also allows naming of organizational units, geographic sites, and application services. An "enterprise-level" network can be a single Local Area Network (LAN) communicating over cables, infra-red beams, or radio broadcast; or a cluster of two or more LANs linked together by cable or direct phone connections. Within an enterprise-level network, every machine is able to communicate with every other machine without reference to a global naming service such as DNS or X.500/LDAP.

FNS currently supports three enterprise-level naming services:

See Chapter 23, FNS and Enterprise Name Services, for administration information regarding FNS and enterprise-level naming services.

FNS and NIS+ Naming

If you are not familiar with NIS+ and its terminology, refer to Part 1 and Glossary of this guide. You will find it helpful to be familiar with the structure of a typical NIS+ environment.

NIS+ is the preferred enterprise-wide information service in the Solaris environment. Both NIS and local files can be used along with NIS+. NIS+ allows an enterprise to be divided into hierarchical organizational levels composed of domains and subdomains.

FNS organization units correspond to NIS+ domains and subdomains. There is one orgunit context for each domain and subdomain.

FNS federates NIS+, NIS, and local files to support naming policies in the Solaris environment. To do this, FNS provides the XFN interface for performing naming operations on organization, site, user, and host objects. It implements these operations using the appropriate programming interface for accessing files, directories, and tables.

Under NIS+, FNS context and attribute data is stored in NIS+ type tables. These tables are stored in NIS+ type directory objects named ctx_dir. There is an ctx_dir directory object for each NIS+ domain and subdomain, residing at the same level as the domain's groups_dir and org_dir directory objects. Thus, the directory object ctx_dir.sales.doc.com. contains FNS tables which store FNS context and attribute data for the sales.doc.com domain.

Under NIS+, you use FNS and NIS+ commands to work with the information in FNS tables. Do not edit these tables directly or manipulate them with UNIX commands.

FNS and NIS Naming

NIS is an enterprise-wide information service in the Solaris environment. Local files can be used along with NIS. Under NIS, an enterprise is organized as a single NIS domain.

Each enterprise is a single NIS domain. There is one FNS organizational unit which corresponds to the single NIS domain.

FNS federates NIS and local files to support naming policies in the Solaris environment. To do this, FNS provides the XFN interface for performing naming operations on organization, site, user, and host maps. It implements these operations using the appropriate programming interface for accessing files, directories.

Under NIS, FNS context and attribute data are stored in NIS maps. These maps are stored in a /var/yp/domainname directory on a NIS server. Under NIS, the super user can use FNS commands to work with the information in FNS maps.

NIS Clients Can Update Contexts With FNS if SKI is Running

If certain conditions are met, any NIS client (machine, process, or user) can use FNS commands such as fncreate_fs or fncreate_printer to update the client's own contexts. This allows NIS clients to use FNS commands to update applications such as Printer Administrator, CDE Calendar Manager, Admin Tool and others.

For non-super-users to update their own contexts with FNS commands, the following conditions must be met:

FNS and Files-Based Naming

Files refers to the naming files normally found in a machine's /etc directory. These machine-based files contain UNIX user and password information, host information, mail aliases, and so forth. They also support Solaris-specific data such as the automount maps.

FNS federates local files to support naming policies in the Solaris environment. To do this, FNS provides the XFN interface for performing naming operations on organization, site, user, and host files. It implements these operations using the appropriate programming interface for accessing files, directories.

Under a files-based naming system, FNS context and attribute data is stored in files. These files are stored in a /var/fn directory exported from an NFS file server.

Under a files-based naming system, you use FNS commands to work with the information in FNS files.

Global Naming Services

A global naming service identifies (names) those enterprise-level networks around the world that are linked together via phone, satellite, or other communication systems. This world-wide collection of linked networks is known as the "Internet." In addition to naming networks, a global naming service also identifies individual machines and users within a given network.

FNS currently supports two global naming services:

Note -

You can only federate a global naming service if your enterprise-level name service is NIS+ or NIS. If you are using a files-based name service for your enterprise, you cannot federate either DNS or X.500/LDAP.

See Chapter 26, FNS and Global Naming Systems, for administration information regarding FNS and enterprise-level naming services.

FNS and DNS

The Internet Domain Name System (DNS) is a hierarchical collection of name servers that provide the world Internet with host and domain name resolution. FNS uses DNS to name enterprise objects globally.

A domain name is the name DNS uses to identify an enterprise-level network (LAN or WAN). Networks using NIS+ permit creation of subdomains within the parent domain, and DNS can identify such subdomains.

Names can be constructed for any enterprise that is accessible on the Internet; consequently, names can also be constructed for objects exported by these enterprises. For more information about FNS and DNS, see "Federating Under DNS".

FNS and X.500

X.500 is a global directory service. Its components cooperate to manage information about objects in a worldwide scope. Such objects include countries, organizations, people, and machines. FNS federates X.500 to enable global access to enterprise name services. You can choose to use one of two APIs to access the X.500 global directory service:

See "Federating Under X.500/LDAP" for information on federating X.500.

FNS and Applications

FNS supports:

FNS File Naming

FNS-based file naming integrates FNS naming into the Solaris file service. FNS-based file naming enables files to be named relative to users, hosts, sites, and organizations, using the FNS policies shared with other non-file applications.

FNS-based file naming gives clients a common view of the global and enterprise-wide file namespaces. Solaris applications that access the file system will, without modification, have access to the file namespaces supported by FNS.

FNS Printer Naming

FNS-based printer naming provides the basic naming support for the unbundled Sun Microsystems Print Client (SSPC). FNS-based printer naming enables printers to be named relative to users, hosts, sites, and organizations, using the FNS policies shared with other non-printing-related applications.

FNS-based printer naming gives clients a common view of the global and enterprise-wide printer namespaces and allows centralized administration of the printer namespaces.

FNS Application Support

Applications that are aware of FNS can expect the namespace to be arranged according to the FNS policies, and applications that bind names in the FNS namespace are expected to follow these policies.

Applications use FNS three ways:

Administering FNS

FNS System administration varies according to the underlying naming service:

The ability of users to make changes to their own user sub-contexts varies according to the underlying naming service:

Troubleshooting and Error Messages

For troubleshooting common FNS problems and solving them, see "FNS Problems and Solutions". FNS error messages are included in Appendix B, Error Messages.

Chapter 22 FNS Policies

This chapter describes FNS policies.

Introduction to FNS and XFN Policies

XFN defines policies for naming objects in the federated namespace. The goals of these policies are

What FNS Policies Specify

FNS policies contain all the XFN policies plus extensions for the Solaris environment.

Computing environments now offer worldwide scope and a large range of services. Users expect to have access to services at every level of the computing environment. FNS policies provide a common framework for the three levels of services: global, enterprise, and application.

FNS provides to applications a set of policies on how name services are arranged and used:

What FNS Policies Do Not Specify

The FNS policies do not specify:

Policies for the Enterprise Namespace

FNS policies specify the types and arrangement of namespaces within an enterprise and how such namespaces can be used by applications. For example, which namespaces can be associated with which other namespaces. The FNS policies described here include some extensions to XFN policy. These are explicitly defined with notes.

Default FNS Enterprise Namespaces

The FNS enterprise policies deal with the arrangement of enterprise objects within the namespace. Each enterprise objects has its own namespace.

By default, there are seven FNS enterprise objects and namespaces:

Figure 22-1 shows how these enterprise namespaces are arranged.

Figure 22-1 What FNS Policies Arrange

Graphic

Some of these namespaces, such as users and hosts, can appear more than once in a federated namespace.

The policies that apply to these namespaces are summarized in Table 22-2.

Enterprise Namespace Identifiers

Enterprise namespaces are referred to by their atomic names in the federated enterprise namespace.

XFN uses leading underscore ("_") characters to indicate an enterprise namespace identifier. For example, _site. FNS also supports the use of these identifiers without the leading underscore ("_") character. These names without the underscore are extensions to the XFN policies. The site and printer contexts are also extensions to the XFN policies. These atomic names are listed in Table 22-1.

Table 22-1 Enterprise Namespace Identifiers in the Enterprise

Namespace 

XFN Identifiers 

FNS Identifiers 

Resolves to 

Organization 

_orgunit 

orgunit or org 

Context for naming organizational units 

Site 

_site 

site 

Context for naming sites 

Host 

_host 

host 

Context for naming hosts 

User 

_user 

user 

Context for naming users 

File system 

_fs 

fs 

Context for naming files 

Service 

_service 

service 

Context for naming services 

Printer 

 

printer 

Context for naming printers, (subordinate to service namespace) 

Note -

In XFN terminology, the names with the leading underscore are the canonical namespace identifiers. The names without the underscore are namespace identifies that have been customized for the Solaris environment. These customized namespace identifiers, with the addition of printer, might not be recognized in non-Solaris environments. The canonical namespace identifiers are always recognized and so are portable to other environments.

Component Separators

The XFN component separator (/) delimits namespace identifiers. For example, composing the namespace identifier orgunit with the organizational unit name west.sales gives the composite name, orgunit/west.sales.

Default FNS Namespaces

There are seven namespaces supplied with FNS:

Organizational Unit Namespace

The organizational unit namespace provides a hierarchical namespace for naming subunits of an enterprise. Each organizational unit name is bound to an organizational unit context that represents the organizational unit. Organization unit names are identified by the prefixes org/, orgunit/, or _orgunit/. (The shorthand alias org/ is only used in the initial context, never in the middle of a compound name. See "Initial Context Bindings for Naming Within the Enterprise" and "Composite Name Examples".)

NIS+ Environment

In an NIS+ environment, organizational units correspond to NIS+ domains and subdomains.

Under NIS+, organization units must map to domains and subdomains. You must have an organizational unit for each NIS+ domain and subdomain. You cannot have "logical" organization units within a domain or subdomain. In other words, you cannot divide an NIS+ domain or subdomain into smaller organization units. Thus, if you have a NIS+ domain doc.com. and two subdomains sales.doc.com. and manf.doc.com., you must have three FNS organizational units corresponding to those three domains.

Organizational units are named using dot-separated right-to-left compound names, where each atomic element names an organizational unit within a larger unit. For example, the name org/sales.doc.com. names an organizational unit sales within a larger unit named doc.com. In this example, sales is an NIS+ subdomain of doc.com.

Organizational unit names can be either fully qualified NIS+ domain names or relatively named NIS+ names. Fully qualified names have a terminal dot; relative names do not. Thus, if a terminal dot is present in the organization name, the name is treated as a fully qualified NIS+ domain name. If there is no terminal dot, the organization name is resolved relative to the top of the organizational hierarchy. For example, orgunit/west.sales.doc.com. is a fully qualified name identifying the west organization unit, and _orgunit/west.sales is a relatively qualified name identifying the same subdomain.

NIS Environment

In a NIS environment there is only one organization unit per enterprise which corresponds to the NIS domain. This orgunit is named orgunit/domainname where domainname is the name of the NIS domain. For example, if the NIS domain name is doc.com, the organizational unit is org/doc.com.

In an NIS environment, you can use an empty string as a shorthand for the organizational unit. Thus, org// is equivalent to org/domainname.

Files-Based Environment

There is only one FNS organization unit and no subunits when your primary enterprise-level name service is files-based. The only permitted organization unit under files-based naming is org//.

Site Namespace

The site namespace provides a geographic namespace for naming objects that are naturally identified with their physical locations. These objects can be, for example, buildings on a campus, machines and printers on a floor, conference rooms in a building and their schedules, and users in contiguous offices. Site names are identified by the prefixes site/or _site/.

In the Solaris environment, sites are named using compound names, where each atomic part names a site within a larger site. The syntax of site names is dot-separated right-to-left, with components arranged from the most general to the most specific location description. For example, _site/pine.bldg5 names the Pine conference room in building 5, while site/bldg7.alameda identifies building 7 of the Alameda location of some enterprise.

Host Namespace

The host namespace provides a namespace for naming computers. Host names are identified by the prefixes host/or _host/. For example, host/deneb identifies a machine named deneb.

Hosts are named in hostname contexts. The host context has a flat namespace and contains bindings of host names to host contexts. A host context allows you to name objects relative to a machine, such as files and printers found at that host.

In the Solaris environment, host names correspond to Solaris host names. Alias names for a single machine share the same context. For example, if the name mail_server is an alias for the machines deneb and altair, both deneb and altair will share the contexts created for mail_server.

Network resources should only be named relative to hosts as appropriate. In most cases, it is more intuitive to name resources relative to entities such as organizations, users, or sites. Dependence on host names forces the user to remember information that is often obscure and sometimes not very stable. For example, a user's files might move from one host to another because of hardware changes, file space usage, network reconfigurations, and so on. And users often share the same file server, which might lead to confusion if files were named relative to hosts. Yet if the files were named relative to the user, such changes do not affect how the files are named.

There might be a few cases in which the use of host names is appropriate. For example, if a resource is available only on a particular machine and is tied to the existence of that machine, and there is no other logical way to name the resource relative to other entities, then it might make sense to name the resource relative to the host. Or, in the case of a file system, if the files are being shared by many users it might make sense to name them relative to the machine they are stored on.

User Namespace

The user namespace provides a namespace for naming human users in a computing environment. User names are identified by the prefixes user/or _user/.

Users are named in user contexts. The user context has a single-level namespace and contains bindings of user names to user contexts. A user context allows you to name objects relative to a user, such as files, services, or resources associated with the user.

In the Solaris environment, user names correspond to Solaris login IDs. For example, _user/inga identifies a user whose login ID is inga.

File Namespace

A file namespace (or file system) provides a namespace for naming files. File names are identified by the prefixes fs/or _fs/. For example the name fs/etc/motd identifies the file motd which is stored in the /etc directory.

The file namespace is described in more detail in "FNS File Naming". and file contexts are discussed in "File Contexts Administration".

Service Namespace

The service namespace provides a namespace for services used by or associated with objects within an enterprise. Examples of such services are electronic calendars, faxes, mail, and printing. Service names are identified by the prefixes service/ or _service/.

In the Solaris environment, the service namespace is hierarchical. Service names are slash-separated (/) left-to-right compound names. An application that uses the service namespace can make use of this hierarchical property to reserve a subtree for that application. For example, the printer service reserves the subtree printer in the service namespace.

FNS does not specify how service names or reference types are chosen. These are determined by service providers that share the service namespace. For example, the calendar service uses the name _service/calendar in the service context to name the calendar service and what is bound to the name calendar is determined by the calendar service.

Service Name and Reference Registration

Sun Microsystems, Inc., maintains a registry of the names bound in the first level of the service namespace. To register a name, send an email request to fns-register@sun.com, or write to:

FNS Registration Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, CA 94303

Please include a brief description of the intended use of the name and a description of the format of the reference that can be bound to that name.

Printer Namespace

The printer namespace provides a namespace for naming printers. The printer namespace is associated with (subordinate to) the service namespace. In other words, printer service and the printer namespace is one of the services in the service namespace. Printer names are identified by the prefixes service/printer or _service/printer. For example, service/printer/laser1 identifies the printer named laser1.

Significance of Trailing Slash

The trailing / names objects in the next naming system. You need it whenever you are going from one naming system to another.

For example, in the name, org/east.sales/service/printer the slash between org and east.sales is a component delimiter as described above and the slash that trails after the last element in the organization name (sales/) separates the service namespace from the organizational unit namespace. Thus, org/west.sales/service/printer names the printer service of the west.sales organization unit.

FNS Reserved Names

FNS reserves for its own use all the atomic names listed in Table 22-1 as namespace identifiers. For example: _orgunit, org, _site, site, and so forth. This limitation applies to contexts in which the namespace identifiers can appear, as defined by the arrangement of namespaces in "Structure of the Enterprise Namespace". FNS does not otherwise restrict the use of these atomic names in other contexts.

For example, the atomic name service is used as a namespace identifier relative to a user name, as in user/fatima/service/calendar, to mean the root of user fatima's service namespace. This does not preclude a system from using the name service as a user name, as in user/service, because FNS specifies that the context to which the name user/ is bound is for user names and not for namespace identifiers. In this case, service is unambiguously interpreted as a user name. On the other hand, you should not create a directory named user because /user/mikhail would cause confusion between the user mikhail and the file (or subdirectory) /user/mikhail.

Composite Name Examples

This section shows examples of names that follow FNS policies. (See Table 22-2 for a summary of these policies.)

The specific choices of organization names, site names, user names, host names, file names, and service names (such as calendar and printer) are illustrative only; these names are not specified by FNS policy.

Composing Names Relative to Organizations

The namespaces that can be associated with the organization namespace (_orgunit, orgunit, or org) are: user, host, service, fs, and site.

For example:

Composing Names Relative to Users

The namespaces that can be associated with the user namespace are service and fs.

Composing Names Relative to Hosts

The namespaces that can be associated with the hosts namespace are service and fs.

Composing Names Relative to Sites

The namespaces that can be associated with the sites namespace are service and fs.

Composing Names Relative to Services and Files

No other namespaces can be associated with either the files (fs) or services (service) namespaces. For example, you cannot compose a name such as /services/calendar/orgunit/doc.com. In other words, you cannot compose a compound name relative to either the files or the service namespace. You can, of course, compose a file or service name relative to some other namespace such as /user/esperanza/service/calendar.

Structure of the Enterprise Namespace

FNS policies define the structure of the enterprise namespace. The purpose of this structure is to allow easy and uniform composition of names. This enterprise namespace structure has two main rules:

Table 22-2 is a summary of FNS policies for arranging the enterprise namespace. Figure 22-2 shows an example of a namespace layout that follows these FNS policies.

Table 22-2 Policies for the Federated Enterprise Namespace

Namespace 

Identifiers 

Subordinate Namespaces 

Parent Context 

Namespace Organization 

Syntax 

orgunit 

_orgunit 

org 

Site, user, host, file system, service 

Enterprise root 

Hierarchical 

Dot-separated right-to-left 

site 

_site 

Service, file system 

Enterprise root, organizational unit 

Hierarchical 

Dot-separated right-to-left 

user 

_user 

Service, file system 

Enterprise root, organizational unit 

Flat 

Solaris login name 

host 

_host 

Service, file system 

Enterprise root, organizational unit 

Flat 

Solaris host name 

service 

_service 

Application specific 

Enterprise root, organizational unit, site, user, host 

Hierarchical 

/ separated left-to-right 

fs 

 

_fs 

None 

Enterprise root, organizational unit, site, user, host 

Hierarchical 

/ separated, left-to-right 

printer 

None 

Service 

Hierarchical 

/ separated left-to-right 

Figure 22-2 Example of an Enterprise Namespace

Graphic

The namespace of an enterprise is structured around a hierarchy of organizational units. Names of sites, hosts, users, files, and services can be named relative to names of organizational units by composing the organizational unit name with the appropriate namespace identifier and object name.

In Figure 22-2, a user myoko in the west division of the sales organization of an enterprise is named using the name orgunit/west.sales/user/myoko.

Note the use of the namespace identifier user to denote the transition from the orgunit namespace to the user namespace. In a similar fashion (with the use of appropriate namespace identifiers), names of files and services can also be named relative to names of sites, users, or hosts. Names of sites can be named relative to organizational unit names.

The goal of easy and uniform composability of names is met using this structure. For example, once you know the name for an organizational unit within an enterprise (for example, orgunit/west), you can name a user relative to it by composing it with the user namespace identifier and the user's login name to yield a name such as orgunit/west/user/josepha.

To name a file in this user's file system, you can use a name like orgunit/west/user/josepha/fs/notes.

Enterprise Root

The root context of an enterprise, is a context for naming objects found at the root level of the enterprise namespace. Enterprise roots are bound in the global namespace.

There are two ways of naming the enterprise root:

Using Three Dots to Identify the Enterprise Root

You can use .../rootdomain/ to identify an enterprise root where:

Using org// to Identify the Enterprise Root

You can use org// to identify an enterprise root. In essence, org// is an alias or functional equivalent for .../domainname/. When using org//, the double slashes identifies the root enterprise context and namespaces associated with it.

For example, org//site/alameda names the Alameda site associated with the enterprise root.

In contrast, org/ or orgunit/ (with a single slash) points to an organizational context which is not necessarily named relative to the enterprise root. For example, org/sales/site/alameda.

Enterprise Root Subordinate Contexts

The following objects can be named relative to the enterprise root:

Enterprise Root and Organizational Subunits

Organizational subunits can be named relative to the enterprise root.

Given an organization root name, you can compose names for its subordinate organizational unit contexts by using one of the namespace identifiers, orgunit or _orgunit.

For example, if .../doc.com is the name of an enterprise, the root of the context for naming organizational units is .../doc.com/orgunit/, and organizational unit names look like .../doc.com/orgunit/sales and .../doc.com/orgunit/west.sales. Or, you could achieve the same result with org//orgunit/sales.

The following objects can be named relative to an organizational unit name:

Enterprise Root and Sites

Sites are an extension to the XFN policies.

Sites can be named relative to

Enterprise Root and Users

Users can be named relative to

Enterprise Root and Hosts

Hosts can be named relative to

Enterprise Root and Services

A service can be named relative to

Enterprise Root and Files

A file namespace can be named relative to

Enterprise Root and Printers

The printer context is an extension of XFN policies.

A printer namespace can be named in the service context. A printer context is named by using the namespace identifier, printer, in the service context relative to

Initial Context Bindings for Naming Within the Enterprise

An initial context is the starting place from which client users, hosts, and applications can (eventually) name any object in the enterprise namespace.

Figure 22-3 shows the same naming system as the one shown in Figure 22-2, except that the initial context bindings are shaded and shown in italics. These initial contexts are shown from the point of view of the user, host, or application asking for a name to be resolved.

Figure 22-3 Example of Enterprise Bindings in the Initial Context

Graphic

XFN provides an initial context function, fn_ctx_handle_from_initial(), that allows a client to obtain an initial context object as a starting point for name resolution. The initial context has a flat namespace for namespace identifiers. The bindings of these initial context identifiers are summarized in Table 22-3 and are described in more detail in subsequent sections. Not all of these names need to appear in all initial contexts. For example, when a program is invoked by the superuser, only the host and client-related bindings appears in the initial context, none of the user-related bindings appear.

Table 22-3 Initial Context Bindings for Naming Within the Enterprise

Namespace 

Identifier 

Binding 

myself, _myself, thisuser

The context of the user who is trying to resolve a name. 

myens, _myens

The enterprise root of the user who is trying to resolve a name. 

myorgunit, _myorgunit

The user's primary organizational unit context. For example, in an NIS+ environment, the primary organizational unit is the user's NIS+ home domain. 

thishost, _thishost

The context of the host that is trying to resolve a name. 

thisens, _thisens

The enterprise root of the host that is trying to resolve a name. 

thisorgunit, _thisorgunit

The host's primary organizational unit context. For example, in an NIS+ environment, the primary organizational unit is the host's NIS+ home domain 

user, _user

The context in which users in the same organizational unit as the host are named 

host, _host

The context in which hosts in the same organizational unit as the host are named 

org, orgunit, _orgunit

The root context of the organizational unit namespace in the host's enterprise. For example, in an NIS+ environment, this corresponds to the NIS+ root domain 

site, _site

The root context of the site namespace at the top organizational unit if the site namespace has been configured 

In XFN terminology, names with a leading underscore prefix are called the canonical namespace identifiers. The names without the leading underscore, with the additions of org and thisuser, are Solaris customizations. Solaris customized namespace identifiers are not guaranteed to be recognized in other, non-Solaris environments. The canonical namespace identifiers are always recognized and therefore portable to other environments.

Note -

The current implementations of FNS does not support the addition or modification of names and bindings in the initial context.

Initial context bindings fall into three basic categories:

User-related Bindings

FNS assumes that there is a user associated with a process when the XFN initial context function is invoked. This association is based on the effective user ID (euid) of the process. Although the association of user to process can change during the life of the process, the original context handle does not change.

FNS defines the following bindings in the initial context that are related to the user requesting name resolution.

myself

The namespace identifier myself (or either synonym _myself or thisuser) in the initial context resolves to the user context of whomever is making the request. For example, if a process owned by the user jsmith requests name resolution, the name:

myorgunit

FNS assumes that each user is affiliated with an organizational unit of an enterprise. A user can be affiliated with multiple organizational units, but there must be one organizational unit that is primary, perhaps by its position in the organizational namespace or by the user's role in the organization.

myens

FNS assumes that there is an association of a user to an enterprise. This corresponds to the namespace that holds myorgunit.

The namespace identifier myens (and _myens) resolves in the initial context to the enterprise root of the enterprise to which the user making the request belongs. For example, if jsmith is making the request, and jsmith's NIS+ home domain is east.sales, which in turn is in the NIS+ hierarchy with the root domain name of doc.com. The name myens/orgunit/ resolves to the top organizational unit of doc.com.

Note -

Be careful about set-user-ID programs when using user-related composite names, such as myorgunit or myself/service, because these bindings depend on the effective user ID of a process. For programs that set-user-ID to root to access system resources on behalf of the caller, it is usually a good idea to call seteuid(getuid()) before calling fn_ctx_handle_from_initial().

Host-related Bindings

A process is running on a particular host when the XFN initial context function is invoked. FNS defines the following bindings in the initial context that are related to the host the process is running on.

thishost

The namespace identifier thishost (or _thishost) is bound to the host context of the host running the process. For example, if the process is running on the machine cygnus, thishost is bound to the host context of cygnus, and the name thishost/service/calendar refers to the calendar service of the machine cygnus.

thisorgunit

FNS assumes that a host is associated with an organizational unit. A host can be associated with multiple organizational units, but there must be one that is primary. In an NIS+ namespace, this organizational unit corresponds to the host's home domain.

The namespace identifier thisorgunit (or _thisorgunit) resolves to the primary organizational unit of the host running the process. For example, if that host is the machine cygnus, and cygnus's NIS+ home domain is west.sales, then thisorgunit resolves to the organizational unit context for west.sales and the name thisorgunit/service/fax refers to the fax service of the organizational unit west.sales.

thisens

FNS assumes that there is an association of a host to an enterprise. This corresponds to the namespace that holds thisorgunit.

The namespace identifier thisens (or _thisens) resolves to the enterprise root of the host running the process. For example, under NIS+, if the host's home domain is sales.doc.com, then the name thisens/site/ resolves to the root of the site namespace of doc.com.

"Shorthand" Bindings

FNS defines the following "shorthand" bindings in the initial context to enable the use of shorter names to refer to objects in certain commonly referenced namespaces.

user

The namespace identifier user (or _user) is bound in the initial context to the username context in organizational unit of the host running the process. This allows other users in the same organizational unit to be named from this context.

From the initial context, the names user and thisorgunit/user resolve to the same context. For example, if the host running the process is a machine altair and altair is in the east.sales organizational unit, the name user/medici names the user medici in east.sales.

host

The namespace identifier host (or _host) is bound in the initial context to the hostname context organizational unit of the host running the process. This allows other hosts in the same organizational unit to be named from this context.

From the initial context, the names host and thisorgunit/host resolve to the same context. For example, if the host running the process is a machine named sirius and it is in the east.sales organizational unit, the name host/sirius names the machine sirius in the organizational unit east.sales.

org

The namespace identifier org (or orgunit, _orgunit) is bound in the initial context to the root context of the organization of the enterprise to which the host running the process belongs.

From the initial context, the names org and thisens/orgunit 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 org/east.sales names the organizational unit east.sales in doc.com.

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:

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 Glossary of 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:

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 22-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:

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:

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.

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:

  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 among 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.

FNS File System Namespace

Files may be named relative to users, hosts, organizations, and sites in FNS by appending the fs enterprise namespace identifier to the name of the object, and following this with the name of the file. For example, the file draft96 in the sales division's budget directory might be named org/sales/fs/budget/draft96.

The initial context is located under /xfn in the file system's root directory. Thus a user might view the file by typing 


% more /xfn/org/sales/fs/budget/draft96

Existing applications can access this directory just as they would any other directory. Applications do not need to be modified in any way or use the XFN API.

NFS File Servers

NFS is Sun's distributed file system. The files associated with an object will generally reside on one or more remote NFS file servers. In the simplest case, the namespace identifier fs corresponds to the root of an exported NFS file system, as shown in Figure 22-4.

Figure 22-4 NFS File System--Simple Case

Graphic

In contrast, an object's file system may be composed of multiple--and possibly overlapping--remote mounts, woven together into a "virtual" directory structure managed by FNS.

Figure 22-5 illustrates how this capability might be used to piece together an organization's file system from three separate file servers. The project directory, along with its lib subdirectory, resides on one file server, while the src subdirectory resides on another. Users and applications need not be aware of the use of multiple servers; they see a single, seamless namespace.

Figure 22-5 NFS File System--Multiple Servers

Graphic

The Automounter

For efficiency, the automounter is used to mount FNS directories on demand. The default /etc/auto_master configuration file contains the line: 


/xfn -xfn

which tells the automounter that the FNS namespace is "mounted" under /xfn, as specified by XFN.

Since the automounter is used to mount directories named through FNS, the subdirectories of an FNS directory cannot be listed until they have been mounted. For example, suppose the file system of the sales organization is composed of multiple NFS file systems. The following ls command shows only two file systems that have been visited recently and are currently mounted: 


% ls /xfn/org/sales/fs
customers products

To see the entire listing, use the fnlist command:


% fnlist org/sales/fs
Listing org/sales/fs:
products
goals
customers
incentives

The FNS Printer Namespace

The printer context is not part of the XFN policies. It is provided in FNS in order to store printer bindings.

FNS provides the capability to store printer bindings in the FNS namespace. This gives print servers the means to advertise their services and allow users to browse and choose among available printers without client-side administration.

Printer bindings are stored in printer contexts, which are associated with organizations, users, hosts, and sites. Hence, each organization, user, host, and site has its own printer context.

The printer context is created under the service context of the respective composite name. For example, the composite name shown below has the following printer context:


org/doc.com./service/printer

The name of a printer for a host, deneb, with a printer context might look like this:


host/deneb/service/printer/laser

Policies for the Global Namespace

Global name services have worldwide scope. This section describes the policies for naming objects that use global naming systems.

In regard to naming, an enterprise links to the federated global namespace by binding the root of the enterprise in the global namespace. This enables applications and users outside the enterprise to name objects within that enterprise. For example, a user within an enterprise can give out the global name of a file to a colleague in another enterprise to use.

DNS and X.500 contexts provide global-level name service for naming enterprises. FNS provides support for both DNS and X.500 contexts. Without FNS, DNS and X.500 allow outside access to only limited portions of the enterprise namespace. FNS enables outside access to the entire enterprise namespace including services such as calendar manager.

Initial Context Bindings for Global Naming

The atomic name "..." (three dots) appears in the initial context of every FNS client. The atomic name "..." is bound to a context from which global names can be resolved.

Table 22-5 Initial Context Bindings for Global Naming

Atomic Name 

Binding 

. ..

Global context for resolving DNS or X.500 names 

/ ...

Synonym for three dots 

Global names can be either fully qualified Internet domain names, or X.500 distinguished names.

Federating DNS

Any fully qualified DNS name can be used in the global context. When a DNS name is encountered in the global namespace, it is resolved using the resolver library. The resolver library is the DNS name-resolution mechanism. A DNS name typically resolves to an Internet host address or to DNS domain records. When the global context detects a DNS name, the name is passed to the DNS resolver for resolution. The result is converted into an XFN reference structure and returned to the requester.

The contents of DNS domains can be listed. However, the listing operations might be limited by practical considerations such as connectivity and security on the Internet. For example, listing the global root of the DNS domain is generally not supported by the root DNS servers. Most entities below the root, however, do support the list operation.

DNS hosts and domains are distinguished from each other by the presence or absence of name service (NS) resource records associated with DNS resource names.

DNS can be used to federate other naming systems by functioning as a non-terminal naming system.

For example, an enterprise naming system can be bound to doc.com in DNS such that the FNS name .../doc.com/ refers to the root of that enterprise's FNS namespace.

The enterprise naming system is bound to a DNS domain by adding the appropriate text (TXT) records to the DNS map for that domain. When the FNS name for that domain includes a trailing slash (/), the TXT resource records are used to construct a reference to the enterprise naming system.

For general information about DNS, see the in.named man page or the DNS chapters in Solaris Naming Setup and Configuration Guide.

Federating X.500/LDAP

X.500 is a global directory service. It stores information and provides the capability to look up information by name as well as to browse and search for information.

X.500 information is held in a directory information base (DIB). Entries in the DIB are arranged in a tree structure. Each entry is a named object and comprises a defined set of attributes. Each attribute has a defined attribute type and one or more values.

An entry is unambiguously identified by a distinguished name that is the concatenation of selected attributes from each entry in the tree along a path leading from the root down to the named entry. For example, using the DIB shown in Figure 22-6, c=us/o=doc is a distinguished name of the doc organization in the U.S. Users of the X.500 directory can interrogate and modify the entries and attributes in the DIB.

Figure 22-6 Example of an X.500 Directory Information Base

Graphic

FNS federates X.500 by supplying the necessary support to permit namespaces to appear to be seamlessly attached below the global X.500 namespace.

For example, FNS facilitates linking the enterprise naming system for the doc organization below X.500. Starting from the initial context, an FNS name to identify the sales organizational unit of the doc organization might be

.../c=us/o=doc/orgunit/sales

The name within the enterprise is simply concatenated onto the global X.500 name. (Note that FNS names use the name "..." in the initial context to indicate that a global name follows.)

Name resolution of FNS names takes place as follows. When an X.500 name is encountered in the global namespace, it is resolved using the X.500 name- resolution mechanism. One of three outcomes is possible:

Chapter 23 FNS and Enterprise Name Services

This chapter discusses administration matters relating to FNS and enterprise level naming services.

FNS and Enterprise-Level Naming Services

Enterprise-level naming services are used to name objects within an enterprise. FNS currently supports three enterprise-level naming services:

Choosing an Enterprise-Level Name Service

When you initially set up and configure your FNS namespace with the fncreate command as described in Solaris Naming Setup and Configuration Guide, the correct default name service is automatically selected for each machine.

If you later change a machine's primary enterprise-level name service, you should run the fnselect command on that machine. See "Selecting a Naming Service" for details.

FNS and Naming Service Consistency

As a system administrator one of your tasks is to maintain consistency between FNS and the underlying naming service by ensuring that the contents of FNS contexts and the files, maps, or tables of the underlying naming service correspond.

When you initially set up and configure your FNS namespace with the fncreate command as described in Solaris Naming Setup and Configuration Guide, fncreate ensures that FNS contexts are correctly created and are consistent with the underlying naming service data. After the FNS contexts have been set up, this correspondence needs to be maintained as users, hosts, printers, and so forth are added to and removed from the system. The following sections describe how to maintain FNS and name service consistency.

FNS and Solstice AdminSuite

If you have the Solstice AdminSuite product, you can use it to add, change, or delete user and host information in the underlying name service. This is a recommended method because the AdminSuite tools update the corresponding FNS namespace automatically.

Checking Naming Inconsistencies

When updates to FNS or the primary name service are made independent of the Solstice AdminSuite product, the resulting inconsistencies are resolved by the use of the FNS tool, fncheck. The fncheck command checks for inconsistencies between the FNS hostname and user contexts, and:

The fncheck command lists those host and user names that are in the FNS namespace but not in the name service data, and those host and user names that are in the name service data but not in the FNS namespace.

The command syntax is: 


fncheck [-r][-s][-u][-t hostname|username][domain_name]
Table 23-1 fncheck Command Options

Option 

Description 

domain

Apply the command to an NIS+ domain other than the one in which you are running the command. 

-t

Specifies the type of context to check. Allowed types are hostname or username.

-s

Lists host or user names from the namespace dataset that are not in the FNS namespace 

-r

Lists host or user names from the FNS namespace that do not have entries in the corresponding namespace dataset 

-u

Updates the FNS namespace based on information in the relevant namespace dataset 

The -t option is used to specify the contexts to check (host or user). If you omit the -t option, both the hostname and username contexts are checked.

When the -r option is used with the -u option, items that appear only in the FNS context are removed from the FNS context. When the -s option is used with the -u option, items that appear only in the namespace dataset are added to the FNS context. If neither -r or -s are specified, items are added and removed from the FNS context to make it consistent with the corresponding namespace data.

Selecting a Naming Service

When FNS constructs the bindings in the initial context for a machine, it does so on the basis of a particular naming service.

You can choose which name service FNS is to use with the fnselect command. The name service setting you specify with fnselect affects the entire machine, all applications running on that machine, and all users logged in to that machine.

Only root can run fnselect. The command syntax is: 


fnselect [-D] [namesvc]
Table 23-2 fnselect Command Options

Option 

Description 

namesvc

The naming service you want to select. Must be one of: default, nisplus, nis, or files.

-D

Display the naming service used to generate the FNS initial context. 

For example, to select NIS+ as a machine's name service:


#fnselect nisplus

For example, to select the default as a machine's name service and print the name of the service used to generate the FNS initial context:


#fnselect -D default

Default Naming Service

If you do not designate a naming service with fnselect, FNS uses the default naming service. The default naming service is determined by FNS based on the name service that the machine is using. If the machine is an NIS+ client, FNS uses NIS+ as the name service. If the machine is a NIS client, FNS uses NIS. If the machine is neither an NIS+ nor a NIS client, FNS uses /etc files as the machine's default name service.

When NIS+ and NIS Coexist

In rare cases you may need to access both NIS+ and NIS-based contexts. For example, you might have a NIS server running that is itself an NIS+ client. In this situation, you use the fnselect command to select the enterprise-level naming service that you want to work with.

Advanced FNS and NIS+ Issues

This section provides detailed information on the relationship between NIS+ objects and FNS objects. This information is useful when you must change the access control of FNS objects.

Note -

See:

Mapping FNS Contexts to NIS+ Objects

FNS contexts are stored as NIS+ objects. All contexts associated with an organization are stored under the FNS ctx_dir directory of the associated NIS+ domain. The ctx_dir directory resides at the same level as the org_dir directory of the same domain. In other words, when running in conjunction with FNS, for every NIS+ domain or subdomain, there are corresponding org_dir, groups_dir and ctx_dir directory objects.

Use the -v option for the fnlookup or fnlist command to see the detailed description of references. The internal name field displays the name of the corresponding NIS+ object.

Browsing FNS Structures Using NIS+ Commands

The NIS+ command, nisls, can be used to list the NIS+ objects used by FNS. For example, the following commands list the contents of the NIS+ domain directory and its ctx_dir subdirectory. 


# nisls doc.com.
doc.com.:
manf
sales
groups_dir
org_dir
ctx_dir
 

# nisls ctx_dir.doc.com.
ctx_dir.DOC.COM.:
fns
fns_user
fns_host
fns_host_alto
fns_host_mladd
fns_host_elvira
fns_user_jjones
fns_user_jsmith
fns_user_aw

Use the niscat command to list the contents of the fns_hosts table. 


# niscat fns_host.ctx_dir
altair *BINARY* *BINARY*
cygnus *BINARY* *BINARY*
centauri *BINARY* *BINARY*

Checking Access Control

Use niscat -o to see the access control of a context. To see the access control of a particular binding, use the name of the binding entry in the parent context's binding table (that is, the name displayed in the internal name field in the output of fnlookup -v and fnlist -v): 


# niscat -o fns_host.ctx_dir
Object Name     	:	fns_host
Owner           	:	alto.doc.com.
Group      	        :       admin.doc.com.
Domain	                :	ctx_dir.doc.com.
Access Rights   	:	r-c-rmcdrmcdr-c-
Time to Live    	:	53:0:56
Object Type     	:	TABLE
Table Type      	:	H
Number of Columns	:	3
Character Separator	
Search Path     	:
Columns         	:
[0]	Name    	:	atomicname
	Attributes	:	(SEARCHABLE, TEXTUAL DATA,	CASE INSENSITIVE)
	Access Rights	:	r-c-rmcdrmcdr-c-
[1]	Name    	:	reference
	Attributes	:	(BINARY DATA)
	Access Rights	:	r-c-rmcdrmcdr-c-
[2]	Name    	:	flags
	Attributes	:	(BINARY DATA)
	Access Rights	:	r-c-rmcdrmcdr-c-
 

# niscat -o "[atomicname=altair],fns_host.ctx_dir"
Object Name	:	fns_host
Owner   	:	altair.doc.com.
Group   	:       admin.doc.com.
Domain  	:	ctx_dir.doc.com.
Access Rights	:	r-c-rmcdrmcdr-c-
Time to Live	:	12:0:0
Object Type	:	ENTRY
 Entry data of type H
 [1] - [5 bytes] 'alto'
 [2] - [104 bytes] '0x00 ...'
 [3] - [1 bytes] 0x01

(See "The niscat Command" for additional information on the niscat command.)

To change the access control or ownership of a particular context, use the commands:

Give either the binding entry or the bindings table as an argument, depending on the object the operation is to affect.

Advanced FNS and NIS Issues

This section provides specific information on the relationship between NIS and FNS.

NIS and FNS Maps and Makefiles

FNS uses six new maps which are stored in /var/yp/domainname directories on the NIS master and slave servers:

Service and file context information for hosts, users, and the organization are stored in the respective fns_host.ctx, fns_user.ctx, and fns_org.ctx maps. Printer context information is stored in the same maps as other service context information. However, the older printers.conf.byname map is still supported.

Sites are subcontexts of the organization and site context information is stored in the fns_org.ctx map.

Note -

These FNS maps should not be edited directly. You modify or work with these maps by running the appropriate FNS commands such as fncreate, fndestroy, fnbind, fnunbind, fnrename, fnattr, fnlookup, and fnlist. These commands must be run on the NIS master server. You cannot run them on slave servers or client machines.

The FNS map files are placed in the /var/yp/domainname directory. The NIS Makefile in /var/yp is modified to be aware of the FNS Makefile in /etc/fn/domainname.

Large FNS Contexts

NIS has a 64K limit on the number of entries a NIS map can contain. If only service and printer contexts are created for each object (host or user), that limit will be reached when the number of users or hosts exceeds 7K. If additional contexts are created for hosts or users, as is usually the case, the upper 64K limit will be reached with far fewer hosts or users.

FNS solves this problem by automatically creating new maps after an old map has reached its maximum size. Each new map is identified by adding a numeric suffix to the map's name. For example, when a second fns_user.ctx map is created it is given the name fns_user_0.ctx. If a third map became necessary it would be given the name fns_user_1.ctx. As additional maps are created, the number is incremented each time.

Printer Backward Compatibility

In Solaris release 2.5, FNS support for printer naming under NIS was provided for the organization context with a map named printers.conf.byname. In the current Solaris release, organization context printer support is maintained in the fns_org.ctx map. That is, the fncreate_printer command now modifies the fns_org.ctx map and not the printers.conf.byname map.

Migrating From NIS to NIS+

The fncopy command handles the FNS-related aspects of changing your underlying enterprise-level naming service from NIS to NIS+. This command copies and converts NIS-based FNS contexts to NIS+ based contexts.

The command syntax is: 


fncopy [-i oldsvc -o newsvc] [-f filename] oldctx newctx
Table 23-3 fncopy Command Options

Option 

Description 

-i oldsvc

Source naming service. Only nis or files may be specified.

-o newsvc

Target naming service. Only nisplus or nis may be specified.

-f filename

Name of file listing the FNS contexts to be copied 

oldctx

Old FNS context to be copied 

newctx

Target new FNS context 

For example, to copy the contexts listed in the file /etc/sales_users from the doc.com domain of a NIS-based naming service to the sales.doc.com domain of an NIS+ naming service, you would enter:


fncopy -i nis -o nisplus -f /etc/sales_users org/sales.doc.com/user

Advanced FNS and File-Based Naming Issues

This section provides specific information on the relationship between files-based naming and FNS.

FNS Files

FNS uses new files which are stored in /var/fn directories on each machine. (While a /var/fn directory is normally stored on each machine, you can mount and export a central /var/fn directory via NFS.)

The new FNS files are:

Service and file context information for hosts, users, and the organization are stored in the respective fns_host.ctx, fns_user.ctx, and fns_org.ctx files. Printer context information is stored in the same files as other service context information.

Sites are subcontexts of the organization and site context information is stored in the fns_org.ctx file.

Note -

These FNS files should not be edited directly. You modify or work with these files by running the appropriate FNS commands such as fncreate, fndestroy, fnbind, fnunbind, fnrename, fnattr, fnlookup, and fnlist. When you run these commands as root, they affect the context that they are applied to such as hosts, site, and organization unit. When you run these commands as a user, they affect only your own user sub-contexts.

Migrating From Files-Based Naming to NIS or NIS+

The fncopy command handles the FNS-related aspects of changing your underlying enterprise-level naming service from files to NIS or NIS+. This command copies and converts files-based FNS contexts to NIS or NIS+ based contexts.

The command syntax is: 


fncopy [-i oldsvc -o newsvc] [-f filename] oldctx newctx

For example, to copy the contexts listed in the file /etc/host_list to the doc.com domain of an NIS+ naming service, you would enter:


fncopy -i files -o nisplus -f /etc/host_list //doc.com/host

Printer Backward Compatibility

In Solaris release 2.5, FNS support for printer naming for files was provided for the organization context with a file named printers.conf.byname. In the current Solaris release, organization context printer support is maintained in the fns_org.ctx map. That is, the fncreate_printer command now modifies the fns_org.ctx map and not the printers.conf.byname map.

Chapter 24 Enterprise Level Contexts

This chapter describes how to individually create, and administer existing enterprise-level contexts.

Creating Enterprise Level Contexts

FNS contexts are created using the fncreate command. This section describes how to create FNS contexts individually rather than for the entire organization as described in Solaris Naming Setup and Configuration Guide. The fncreate command creates a context of the specified type and binds it to the given composite name. It also creates subcontexts for the context.

The fncreate command has the following syntax, 


fncreate -t context_type [-f input_file] [-o][-r reference_type][-s][-v] [-D] composite_name
Table 24-1 fncreate Command Options

Option 

Description 

--t context

Specifies the type of context to create. The context operator can be one of org, hostname, username, host, user, service, site, nsid, generic, or fs

-f

Creates a context for every host or user listed in input_file. This option can only be used with the -t username or -t hostname option and is useful for creating contexts for a subset of users and hosts found in the corresponding NIS+ passwd and hosts tables, respectively.

-o

Creates only the context specified. Without the -o option, subcontexts are created according to the FNS policies.

-r

Specifies the reference_type of the generic context being created. It can only be used with the -t generic option.

-s

Creates new contexts for composite names already in use. Otherwise, no new contexts are created for names already bound. 

-D

Displays information about the NIS+ object associated with a context each time a context is created. This option is useful for debugging. 

-v

Displays information about the creation as each context is created. 

Note -

If you specify the -o option when creating an organization context, the associated host, user, and service contexts are still created but they are not populated.

When creating contexts bound to namespace identifiers, the name without the underscore (for example, user) is used to create the context and the name with the underscore (for example, _user) is then bound to the reference of the newly created context. This is done regardless of whether the name with or without the underscore is specified in the command line.

For example, the command


fncreate -t username org/sales/_user

creates a context for org/sales/user and adds a binding for org/sales/_user to the context of org/sales/user.

Creating an Organization Context

Use the org type to create an organization context. The composite name must be one of the following, depending on the primary naming service:

Organization Context NIS+ Example

Assume the root NIS+ domain is doc.com and the subdomain is sales.doc.com. To create a sales organization context to correspond to the sales subdomain, you would enter the following command: 


fncreate -t org org/sales/

When the new context is created, a ctx_dir directory, if it does not already exist, is created under the directory of the domain, sales.doc.com.

Because this example used only the -t option without the -o option, it created an organization context for the composite name org/sales/ and, in addition, created hostname, username, and service subcontexts for it, which in turn, created host and user contexts, and service subcontexts for hosts and users. In effect, that is the same as running the following commands:


fncreate -t hostname org/sales/host/
fncreate -t username org/sales/user/
fncreate -t service org/sales/service/

If, instead, you ran fncreate -o -t org, the org context is created and the hostname, username, and service contexts are also created, but not populated with host and user contexts.

The org context is owned by the administrator who executed the fncreate command, as are the hostname, username, and service subcontexts. The host and user contexts, however, and their subcontexts are owned by the hosts or users for which the contexts were created. In order for the administrator to subsequently manipulate host and user contexts, the NIS_GROUP environment variable must have been set accordingly at the time fncreate is executed. For example, assuming a C-Shell, to set NIS_GROUP to fns_admins.doc.com: 


rootmaster# setenv NIS_GROUP fns_admins.doc.com

All Hosts Context

The hostname type creates a hostname context in which host contexts can be created and bound. Host contexts and their subcontexts are created for each machine name found in the NIS+ hosts.org_dir table unless the -o option is used. When the -o option is used, only the hostname context is created.

For example, running the command 


fncreate -t hostname org/sales/host/

creates the hostname context and effectively runs the command:


fncreate -t host org/sales/host/hname

Where hname is the name of each machine found in the hosts.org_dir table. It also adds a binding for org/sales/_host/ that is bound to the reference of org/sales/host/.

The hostname context is owned by the administrator who executed the fncreate command. A host context and its subcontexts are owned by the machine for which the contexts were created. That is, each host owns its own host context and subcontexts.

The -f option can be used to create contexts for a subset of the hosts found in the NIS+ table hosts.org_dir. It creates contexts for those hosts listed in the given input file.

Single Host Context

The host type creates the context and subcontexts for a single host. The command automatically creates a service context for the host and a binding for fs unless the -o option is used. When the -o option is used, only the host context is created.

For example, the command 


# fncreate -t host org/sales/host/antares/

creates a context for the host named antares and effectively runs the commands


fncreate -t service org/sales/host/antares/service/
fncreate -t fs org/sales/host/antares/fs/

The host context and its subcontexts are owned by the machine. In the above example, the machine antares, with NIS+ principal name antares.sales.doc.com, owns the contexts:

The hostname context (org/sales/host in the above example) to which the machine belongs must already exist. The machine name supplied should already exist in the NIS+ hosts.org_dir table.

Host Aliases

Alias host names may exist in an NIS+ hosts.org_dir table. These appear in the table as a set of hosts with the same canonical name but different alias names.

In FNS, a single host with multiple alias names has a single host context. Alias names for that host in the hostname context are bound to the reference of that host context.

All-Users Context

The username type creates a username context in which individual user contexts can be created and bound. User contexts and their subcontexts are created for each user name found in the NIS+ passwd.org_dir table unless the -o option is used. When the -o option is used, only the username context is created.

For example, running the command


# fncreate -t username org/sales/user/

creates the username context and effectively runs the command:


fncreate -t user org/sales/user/uname

Where uname represents the various user names that appear in the passwd.org_dir table. It also adds a binding for org/sales/_user/ that is bound to the reference of org/sales/user/.

The username context is owned by the administrator who executed the fncreate command. Individual user contexts and their subcontexts are owned by the users for which the contexts were created. Each user owns his or her own user context and subcontexts.

The -f option can be used to create contexts for a subset of the users found in the NIS+ table passwd.org_dir. It creates contexts for those users listed in the given input file.

Single User Context

The user type creates the user context and subcontexts for a user. A service subcontext and a binding for fs are created under the user context unless the -o option is used. When the -o option is used, only the user context is created.

For example, the command


# fncreate -t user org/sales/user/jjones/

creates the user context for the user named jjones and effectively runs the commands 


fncreate -t service org/sales/user/jjones/service/
fncreate -t fs org/sales/user/jjones/fs/

The user context and its subcontexts are owned by the user for whom the contexts were created. In the above example, the contexts created are owned by the user jjones with NIS+ principal name jjones.sales.doc.com.

The username context (org/sales/user in the above example) to which the user belongs must already exist. The user name supplied should already exist in the NIS+ passwd.org_dir table.

Service Context

The service type creates the service context in which service names can be bound. There is no restriction on what type of references may be bound in a service context. The policies depend on the applications that use the service context. For example, a group of desktop applications may bind references for a calendar, a telephone directory, a fax service, and a printer in a service context.

For example, the command 


# fncreate -t service org/sales/service/

creates a service context for the organization sales. Because the terminal atomic name is a namespace identifier, fncreate also adds a binding for org/sales/_service/ that is bound to the reference of org/sales/service/. After executing this command, names such as org/sales/service/calendar and org/sales/service/fax can then be bound in this service context.

The service context supports a hierarchical namespace, with slash-separated left-to-right names. The service namespace can be partitioned for different services. Continuing with the desktop applications example, a group of plotters may be named under the service context after the creation of the plotter context.


# fncreate -t service org/sales/service/plotter

Names such as org/sales/service/plotter/speedy and org/sales/service/plotter/color could then be bound under the service context.

Note -

Because the terminal atomic name is not a namespace identifier, no additional binding is added (as was the case with service and _service).

The service context created is owned by the administrator who ran the fncreate command.

Printer Context

The printer context is created under the service context of the respective composite name.

Generic Context

The generic type creates a context for binding names used by applications.

A generic context is similar to a service context except it can have a different reference type. The -r option is used to specify the reference type for the generic context being created. If it is omitted, the reference type is inherited from its parent generic context or, if the parent context is not a generic context, the reference type used is a default generic reference type.

Like a service context, there is no restriction on what type of references may be bound in a generic context. The policies depend on the applications that use the generic context.

For example, the command 


# fncreate -t generic -r WIDC_comm org/sales/service/extcomm

creates a generic context with the WIDC_comm reference type under the service context of the organization sales. Names such as org/sales/service/extcomm/modem can then be bound in this generic context.

The generic context supports a hierarchical namespace, with slash-separated left-to-right names, which allows an application to partition its namespace for different services. Continuing with the example above, a generic subcontext for modem can be created running the command


# fncreate -t generic org/sales/service/extcomm/modem

Names such as org/sales/service/extcomm/modem/secure and org/sales/service/extcomm/modem/public could then be bound under the modem context.

The generic context created is owned by the administrator who ran the fncreate command.

Site Context

The site type creates contexts in which site names can be bound.

For example, the command 


# fncreate -t site org/sales/site/

creates a site context. Because the terminal atomic name is a namespace identifier, fncreate also adds a binding for org/sales/_site/ that is bound to the reference of org/sales/site/.

The site context supports a hierarchial namespace, with dot-separated right-to-left names, which allows sites to be partitioned by their geographical coverage relationships.

For example, the commands


# fncreate -t site org/sales/alameda
# fncreate -t site org/sales/site/alameda.bldg-5

create a site context alameda and a site subcontext alameda.bldg-5 for it.

Note -

Because these terminal atomic names are not namespace identifiers, no additional bindings are added (as was the case with site and _site).

The site context created is owned by the administrator who ran the fncreate command.

File Context

The fs type creates a file system context (or file context) for a user or a host. For example, the command 


# fncreate -t fs org/sales/user/petrova/fs/

creates the fs context for user petrova. Because the terminal atomic name is a namespace identifier, fncreate also adds a binding for org/sales/user/petrova/_fs/ that is bound to the reference of org/sales/user/petrova/fs/.

The fs context of a user is the user's home directory as it is stored in the NIS+ passwd.org_dir table. The fs context of a host is the set of NFS file systems that the host exports.

Use the fncreate_fs command to create file contexts for organizations and sites or to create file contexts other than the defaults for users and hosts. See "File Contexts Administration" for details.

The fs context created is owned by the administrator who ran the fncreate command.

Namespace Identifier Context

The nsid (namespace identifier) type creates a context in which namespace identifiers can be bound.

For example, the command 


# fncreate -t nsid org/sales/site/alameda.bldg-5/

creates the nsid context for the site alameda.bldg-5 and permits the creation of subcontexts such as service/. Continuing with this example, you could then execute the command


# fncreate -t service org/sales/site/alameda.bldg-5/service/

to create the service context for alameda.bldg-5.

The nsid context created is owned by the administrator who ran the fncreate command.

Administering Enterprise Level Contexts

A number of tools are provided for examining and managing FNS contexts. The commands and their syntax are shown in the sections that follow.

Displaying the Binding

fnlookup displays the binding of the given composite name. 


fnlookup [-v][-L] composite_name
Table 24-2 fnlookup Command Options

Option 

Description 

-v

Displays the binding in more detail 

-L

Displays the reference to which the XFN link is bound 

For example, to show the binding for the user darwin in detail, you would enter:


# fnlookup -v user/darwin/
Reference type: onc_fn_user
Address type: onc_fn_nisplus
 length: 52
 context type: user
 representation: normal
 version: 0
 internal name: fns_user_darwin.ctx_dir.sales.doc.com.

Suppose user/Charles.Darwin is linked to user/darwin. The first command in the following example shows what user/Charles.Darwin is bound to (an XFN link). The second command follows the XFN link, user/darwin, and shows what user/darwin is bound to (the user context).


# fnlookup user/Charles.Darwin
Reference type: fn_link_ref
Address type: fn_link_addr
 Link name: user/darwin
# fnlookup -L user/Charles.Darwin
Reference type: onc_fn_user
Address type: onc_fn_nisplus
 context type: user

Listing the Context

fnlist lists the contents of the context identified by the given name. 


fnlist [-lv] [name]
Table 24-3 fnlist Command Options

Option 

Description 

-v

Displays the binding in more detail 

-l

Displays the bindings of the names bound in the named context 

For example, to display the bindings under the user context:


# fnlist user/
Listing 'user/':
jjones
julio
chaim
James.Jones

If no name is given, the command lists the contents of the initial context.


# fnlist
Listing '':
_myorgunit
...
_myself
thishost
myself
_orgunit
_x500
_host
_thisens
myens
thisens
org
orgunit
_dns
thisuser
_thishost
myorgunit
_user
thisorgunit
host
_thisorgunit
_myens
user

When the -l option is given, the bindings of the names bound in the named context are displayed.


# fnlist -l user/
Listing bindings 'user/':
name: julio
Reference type: onc_fn_user
Address type: onc_fn_nisplus
 context type: user
name: chaim
Reference type: onc_fn_user
Address type: onc_fn_nisplus
 context type: user
name: James.Jones
Reference type: fn_link_ref
Address type: fn_link_addr
 Link name: user/jjones
name: jjones
Reference type: onc_fn_user
Address type: onc_fn_nisplus
 context type: user

When the -v option is given in conjunction with the -l option, the bindings are displayed in detail.


# fnlist -lv user/
Listing bindings 'user/':
name: julio
Reference type: onc_fn_user
Address type: onc_fn_nisplus
 length: 52
 context type: user
 representation: normal
 version: 0
 internal name: fns_user_julio.ctx_dir.sales.doc.com.
name: chaim
Reference type: onc_fn_user
Address type: onc_fn_nisplus
 length: 52
 context type: user
 representation: normal
 version: 0
 internal name: fns_user_chaim.ctx_dir.sales.doc.com.
name: James.Jones
Reference type: fn_link_ref
Address type: fn_link_addr
 length: 11
 data: 0x75 0x73 0x65 0x72 0x2f 0x6a 0x6a 0x6f 0x6e 0x65
user/jjones
name: jjones
Reference type: onc_fn_user
Address type: onc_fn_nisplus
 length: 52
 context type: user
 representation: normal
 version: 0
 internal name: fns_user_jjones.ctx_dir.sales.doc.com.

Binding a Composite Name to a Reference

fnbind allows you to bind a composite name to a reference.

There are two uses of this command.

Binding an Existing Name to a New Name

The syntax of fnbind for binding existing names to new names is: 


fnbind [-s][-v][-L] oldname newname
Table 24-4 fnbind Command Options (Binding Names)

Option 

Description 

oldname

The existing composite name 

newname

The new name to which you are binding the old name 

-s

Supersedes any existing binding of the original composite name 

-v

Prints out the reference used for the binding 

-L

Creates an XFN link using name and binding it to new_name

For example, to bind the name user/julio/service/printer to the reference of myorgunit/service/printer you would enter:


# fnbind myorgunit/service/printer user/julio/service/printer

If the given newname is already bound, fnbind -s must be used or the operation will fail. In the above example, if user/julio/service/printer is already bound, the -s option must be used to overwrite the existing binding with that of myorgunit/service/printer as shown below:


# fnbind -s myorgunit/service/printer user/julio/service/printer

The -v option prints out the reference used for the binding.


# fnbind -v myorgunit/service/printer user/julio/service/printer
Reference type: onc_printers
Address type: onc_fn_printer_nisplus

The following command constructs an XFN link out of user/jjones and binds it to the name user/James.Jones:


# fnbind -L user/jjones user/James.Jones

Similarly, to create a link from user/julio/service/printer to myorgunit/service/printer you would enter:


# fnbind -sL myorgunit/service/printer user/julio/service/printer

Constructing a Reference on the Command Line

The syntax of fnbind for building a reference on the command line is: 


fnbind -r [-s] [-v] newname [-O | -U] reftype {[-O | -U] | addresstype [-c|-x] addresscontents}+
Table 24-5 fnbind Command Options (Reference Construction)

Option 

Description 

newname

The new name for which you are constructing a reference 

reftype

The type of reference you are creating. Unless the -O or -U options are used, FN_ID_STRING is used as the indentifier for reftype.

addresstype

The type of address you are creating. Unless the -O or -U options are used, FN_ID_STRING is used as the indentifier for addresstype.

addresscontents

The address of the reference you are creating. Unless the -c or -x options are used, the address is stored as an XDR-encoded string.

-s

Supersedes any existing binding of the original composite name 

-v

Prints out the reference used for the binding 

-c

Stores address contents without XDR encoding 

-x

Interprets address contents as a hexadecimal input string and store it as is 

-r

Creates a reference with a specified type and binds the reference to a name specified on the command line 

-O

Interprets and stores type string as ASN.1 dot-separated integer list 

-U

Interprets and stores type string as a DCE UUID 

For example, to bind the name thisorgunit/service/calendar to the address contents of staff@cygnus with a reference type of onc_calendar and and an address type onc_cal_str you would enter:


# fnbind -r thisorgunit/service/calendar onc_calendar onc_cal_str staff@cygnus

By default, the address contents supplied in the command line is XDR-encoded before being stored in the reference. If the -c option is given, the address contents are stored in normal, readable characters, not as an XDR-encoded string. If the -x option is given, the address contents supplied in the command line are interpreted as a hexadecimal string and stored (and not XDR-encoded).

By default, the reference and address types of the reference to be constructed uses the FN_ID_STRING identifier format. If the -O option is given, the identifier format is FN_ID_ISO_OID_STRING, an ASN.1 dot-separated integer list string. If the -U option is given, the identifier format is FN_ID_DCE_UUID, a DCE UUID in string form.

Note -

For more information on ASN.1, see ISO 8824: 1990, Information Technology -- Open Systems Interconnection -- Specification of Abstract Syntax Notation One (ASN.1). For more information on DCE UUID see X/Open Preliminary Specification, October 1993, X/Open DCE: Remote Procedure Call (ISBN: 1-872630-95-2).

For example, to bind to the name thisorgunit/service/nx a reference with a hexadecimal string as the address contents and OIDs as reference and address types, you would enter:


# fnbind -r thisorgunit/service/nx -O 1.2.99.6.2.1 -O 1.2.99.6.2.3 
-x ef12eab67290

Removing a Composite Name

fnunbind removes the given composite name from the namespace. Note that this does not remove the object associated with the name; it only unbinds the name from the object.

For example, to remove the binding associated with the name user/jjones/service/printer/color, you would enter:


# fnunbind user/jjones/service/printer/color

Renaming an Existing Binding

The fnrename command renames an existing binding.

For example, to rename the binding of clndr to calendar, in the context named by user/jjones/service/ you would enter:


# fnunbind user/jjones/service/printer/color

Destroying a Context

fndestroy removes the given composite name from the namespace and destroys the context named by the composite name.

For example, to unbind the name user/jones/ from the namespace and destroys the context named by user/jjones/ you would enter:


# fndestroy user/jjones/

If the composite name identifies a context to be removed, the command fails if the context contains subcontexts.

Chapter 25 Administering File Contexts

This chapter describes how to administer application specific contexts.

File Contexts Administration

File contexts may be:

Creating a File Context With fncreate_fs

The fncreate_fs command creates file contexts for organizations and sites. It may also be used to override the default file contexts for users and hosts that are created by the fncreate command.

There are two methods of using the fncreate_fs command.

The two methods of fncreate_fs have the following syntax: 


fncreate_fs [-v] [-r] -f  file composite_name
fncreate_fs [-v] [-r] composite_name [options] [location...]
Table 25-1 fncreate_fs Command Options

Option 

Description 

composite_name

The composite name of the file context. 

-f file

Use an input file named file.

options

Mount options 

location

Mount location. 

-v

Sets verbose output, displaying information about the contexts being created and modified. 

-r

Replaces the bindings in the context named by composite_name --and all of its subcontexts--with only those specified in the input. This is equivalent to destroying the context (and, recursively, its subcontexts), and then running fncreate_fs without this option. The -r option should be used with care.

The fncreate_fs command manipulates FNS contexts and bindings of the onc_fn_fs reference type. It uses an address of type onc_fn_fs_mount to represent each remote mount point. The data associated with an address of this type are the corresponding mount options and locations in a single, XDR-encoded string.

Creating File Contexts With an Input File

The input file supplies the names and values to be bound in the context of composite_name. Its format is based upon and similar, but not identical, to the format of indirect automount maps. The input file contains one or more entries with the form:


name [options] [location...]

Where:

For each entry a reference to the mount locations and the corresponding mount options is bound to the name composite_name/name.

If options and location are both omitted, then no reference is bound to composite_name/name. Any existing reference is unbound.

For example, suppose you want kuanda's file system to be an NFS mount of the directory /export/home/kuanda from host altair as shown in Figure 22-4. The command would be run as follows:


% fncreate_fs -f infile user/kuanda/fs

With infile containing: 


. altair:/export/home/kuanda

To set up a more complex file system distributed over more than one server as shown in Figure 22-5, run the command


% fncreate_fs -f infile org/sales/fs

with infile containing


tools/db	 	altair:/export/db
project		 	altair:/export/proj
project/lib             altair:/export/lib
project/src	 	deneb:/export/src

To change the NFS mounts for project and its subcontexts src and lib to be read-only, you can change infile as follows:


tools/db 	 			svr1:/export/db
project	      -ro			svr1:/export/projproject/lib altair:/export/lib
project/src	 			svr2:/export/src

The -ro is unnecessary in the third and fourth lines because src and lib are subcontexts of project, they will inherit the -ro mount option from above.

The following input file would make all of the mounts read-only except for org/sales/fs/project/src.


.	 		-ro
tools/db 			 	svr1:/export/db
project	 				svr1:/export/proj
project/lib altair:/export/lib
project/src         -rw	         svr2:/export/src

Creating File Contexts With Command-line Input

The fncreate_fs command also allows the binding description to be provided on the command line: 


fncreate_fs composite_name [mmount_options] [mount_location ...]

This is equivalent to using the input file form of the command but entering the individual bindings from your keyboard. The previous example in which kuanda's file system was set could be set from the command line as follows:


% fncreate_fs user/kuanda/fs altair:/export/home/kuanda

Similarly, the hierarchy illustrated in Figure 22-5 could have been set up by running the sequence of commands:


% fncreate_fs org/sales/fs/tools/db altair:/export/db
% fncreate_fs org/sales/fs/project altair:/export/proj
% fncreate_fs org/sales/fs/project/lib altair:/export/lib
% fncreate_fs org/sales/fs/project/src deneb:/export/src

To make all three of the mounts read-only, you would run this command:


% fncreate_fs org/sales/fs -ro

Advanced Input Formats

The following two sections apply to both input file and command-line input formats.

Multiple Mount Locations

Multiple location fields may be specified for NFS file systems that are exported from multiple, functionally equivalent locations:


% fncreate_fs org/sales/fs altair:/sales cygnus:/sales

The automounter will attempt to choose the best server from among the alternatives provided. If several locations in the list share the same path name, they may be combined using a comma-separated list of host names:


% fncreate_fs org/sales/fs altair,cygnus:/sales

The hosts may be weighted, with the weighting factor appended to the host name as an integer in parentheses: the lower the number, the more desirable the server. The default weighting factor is zero (most desirable). Negative numbers are not allowed.

The following example illustrates one way to indicate that cygnus is the preferred server:


% fncreate_fs org/sales/fs altair(2),cygnus(1):/sales

Variable Substitution

Variable names, prefixed by $, may be used in the options or location fields of fncreate_fs. For example, a mount location may be given as:


altair:/export/$CPU

The automounter will substitute client-specific values for these variables when mounting the corresponding file systems. In the above example, $CPU is replaced by the output of uname -p; for example, sparc.

Backward Compatibility Input Format

For additional compatibility with automount maps, the following input file format is also accepted by fncreate_fs: 


name	 [mount_options] [mount_location ...] \ 
 /offset1	[mount_options1] mount_location1 ... \
 /offset2	[mount_options2] mount_location2 ... \
 ...

Where each offset field is a slash-separated hierarchy. The backslash (\) indicates the continuation of a single long line. This is interpreted as being equivalent to:


name [mount_options] [mount_location ...] \
name/offset1	[ mount_options1] mount_location1 ... \
name/offset2	[mount_options2] mount_location2 ......

The first line is omitted if both mount_options and mount_location are omitted. This format is for compatibility only. It provides no additional functionality, and its use is discouraged.

Chapter 26 FNS and Global Naming Systems

This chapter describes two global naming systems (DNS and X.500/LDAP) and how to federate them under FNS.

FNS and Global Naming Systems

See "Global Naming Services" for overview and background information on the relationship between FNS and global naming services.

FNS supports federation of enterprise naming systems into the global naming systems, DNS and X.500/LDAP. This chapter describes the procedures for federating NIS+ with DNS and X.500. In general, the procedures involve

Note -

You can only federate a global naming service if your enterprise-level name service is NIS+ or NIS. If you are using a files-based name service for your enterprise, you cannot federate either DNS or X.500/LDAP.

Obtaining the Root Reference

To federate an enterprise naming service under DNS or X.500/LDAP, information must be added to these respective naming systems to enable access to and from the enterprise and the global Internet outside of the enterprise. This information is the root reference, which consists of network address information describing how to reach the top of a particular enterprise namespace.

The root reference consists of a single address which contains a single, XDR-encoded string. The address type and content varies according to the enterprise level name service you are using: NIS+ or NIS.

NIS+ Root Reference

When your enterprise level name service is NIS+, the root reference address type is: onc_fn_nisplus_root. There are two required, and one optional, elements in a root reference network address. The elements are separated by white spaces:


root-domain server [server_IP_address]
Table 26-1 NIS+ Root Reference

Address Element 

Description 

root_domain

The fully qualified name of the NIS+ root domain (trailing dot required). 

server

The host name of one of the NIS+ servers (master or replica) serving nis+_root_domain.

server_IP_address

The IP address of nis+server. This is optional if the address of nis+server is expected to be known. This means it should be available through one of the name services listed in the /etc/nsswitch.conf file.

For example, suppose that the NIS+ root domain is doc.com. (notice the trailing dot), and that it can be reached using the host nismaster.doc.com. The root reference would be:


doc.com. nismaster.doc.com

The IP address of the server is not given in the example above because it is expected to be available through other means. If for some reason that IP address was not available through other means, the root reference would look like:


doc.com. nismaster.doc.com 123.123.123.33

NIS Root Reference

When your enterprise level name service is NIS, the root reference address type is: onc_fn_nis_root. There are two required, and one optional, elements in a root reference network address. The elements are separated by white spaces:


root_domain server [server_IP_address]
Table 26-2 NIS Root Reference

Address Element 

Description 

root_domain

The fully qualified name of the NIS domain (trailing slash required). 

server

The host name of one of the NIS servers (master or slave) serving root_domain.

server_IP_address

The IP address of nis-server. This is optional if the address of nis-server is expected to be known. This means it should be available through one of the name services listed in the /etc/nsswitch.conf file.

For example, suppose that the NIS domain is doc.com, and that it can be reached using the host ypmaster.doc.com. The root reference would be:


doc.com/ ypmaster.doc.com

The IP address of the server is not given in the example above because it is expected to be available through other means. If for some reason that IP address was not available through other means, the root reference would look like:


doc.com/ ypmaster.doc.com 123.123.123.37

Federating Under DNS

This section describes the steps required to add TXT (text) records for a subordinate enterprise naming system implemented with NIS+ or NIS. To federate a subordinate naming system in DNS, you need to add reference information into DNS describing how to reach the subordinate naming system's root reference.

  1. Obtain the root reference.

    See "Obtaining the Root Reference".

  2. Add a root reference TXT record to the DNS loopback file.

    By default, this manual uses the name /etc/named.local for this file (other common names for this file are domain.127.0.0 or db.127.0.0).

    The root reference TXT record has the following format:

    For NIS+


    TXT "XFNNISPLUS rootdomain server [server_IP_address]"

    For example:


    TXT "XFNNISPLUS doc.com. nismaster.doc.com"

    For NIS


    TXT "XFNNIS rootdomain server [server_IP_address]"

    For example:


    TXT "XFNNIS doc.com/ ypmaster.doc.com"

    The TXT record must be associated with a DNS domain that includes an NS (name server) record entry. The following is an example of a DNS domain with reference information for NIS+ bound in it.


    $ORIGIN doc.com
@ IN SOA foo bar.eng.doc.com
 (
 100 ;; Serial
 3600 ;; Refresh
 3600 ;; Retry
 3600 ;; Expire
 3600 ;; Minimum
 )
 NS nshost
 TXT "XFNNISPLUS doc.com. nismaster 123.123.123.33"
nshost IN A 133.33.33.34

    For more information about DNS files, see "DNS Configuration and Data Files".

  3. After adding the TXT record into the DNS table, either restart the DNS server or send it a signal to reread the table.


    # kill -HUP pid

    Where pid is the process ID number of in.named.

    For further information on how DNS TXT records are used for XFN references, see "DNS Text Record Format for XFN References".

Federating Under X.500/LDAP

In order to federate a subordinate naming system (either NIS+ or NIS) in X.500/LDAP:

Specifying an X.500 Root Reference

  1. Obtain the NIS+ root reference for your NIS+ hierarchy.

    See "Obtaining the Root Reference".

  2. Create an X.500 entry that supports XFN reference attributes.

    For example, the following command creates a new X.500 entry called c=us/o=doc with the object classes top, organization, and XFN-supplement (1.2.840.113536.25). The XFN-supplement object class allows the c=us/o=doc entry to store reference information for a subordinate naming system.


    # fnattr -a .../c=us/o=doc object-class \
top organization XFN-supplement

    If the X.500 entry already existed and was not defined with the XFN-supplement object class, it must be removed and re-created with the additional object class. Otherwise, it will not be able to hold reference information about the subordinate naming system.

  3. Add the reference information about the subordinate system to the entry.

    After creating the X.500 entry, you can then add information about the subordinate system by binding the appropriate root reference to the named entry.

    For example, if your subordinate naming system is NIS+, and the NIS+ server you want to use is nismaster, your would enter:


    # fnbind -r .../c=us/o=doc/ onc_fn_enterprise onc_fn_nisplus_root \
"doc.com. nismaster

    If your subordinate naming system is NIS, and the NIS server you want to use is ypmaster, your would enter:


    # fnbind -r .../c=us/o=doc/ onc_fn_enterprise onc_fn_nis_root \
"doc.com/ ypmaster"

    These examples bind the reference for the NIS+ or NIS hierarchy with the root domain name doc.com., to the next naming system pointer (NNSP) of the X.500 entry c=us/o=doc, thus linking the X.500 namespace with the doc.com. namespace.

    The address format used is that of the root reference described in "Obtaining the Root Reference". Note the use of the trailing slash in the name argument to fnbind, .../c=us/o=doc/, to signify that the reference is being bound to the NNSP of the entry, rather than to the entry itself.

    For further information on X.500 entries and XFN references, see "X.500 Attribute Syntax for XFN References".

Specifying an X.500 Client API

An X.500 client API is required in order to access X.500 using FNS. You can use one of two different clients:

The API that you use is specified in each machine's /etc/fn/x500.conf file. This file contains configuration information for X.500 and LDAP. This file can be edited directly. The default x500.conf file contains two entries: 


x500-access: xds ldap 
ldap-servers: localhost ldap

Where localhost and ldap are the IP addresses or hostnames of one or more LDAP servers.

The first entry specifies the order in which X.500 accesses APIs. In the example above, X.500 will first try to use XDS/XOM. If XDS/XOM is not available, it will default to using LDAP. If the entry read: x500-access: ldap xds, X.500 would use LDAP and only fall back on XDS if LDAP were not available.

The second entry lists the IP addresses or hostnames of servers running LDAP. Each server is tried in turn until a successful LDAP connection is achieved. In the example above, the localhost is tried first. If LDAP is not available on that server, the next one is tried.

Chapter 27 Administering FNS Attributes

This chapter describes FNS attributes and how to administer them.

Attributes Overview

Attributes can be applied to named objects. Attributes are optional. A named object can have no attributes, one attribute, or multiple attributes.

Each attribute has a unique attribute identifier, an attribute syntax, and a set of zero or more distinct attribute values.

XFN defines the base attribute interface for examining and modifying the values of attributes associated with existing named objects. These objects can be contexts or any other type of object. Associated with a context are syntax attributes that describe how the context parses compound names.

The extended attribute interface contains operations that search for specific attributes and that create objects and their associated attributes.

Examining Attributes

Search for attributes with the fnsearch command.

The syntax of the fnsearch command is 


fnsearch [-ALlv] [-n max] [-s scope] name [-a ident]... [-O|-U] filter_expr [filter_arg]
Table 27-1 fnsearch Command Options

Option 

Description 

-n max

Display only max number of objects. 

-s scope

Set the scope of the search 

-a ident

Display only those attributes that match ident. 

name

Composite name 

filter_expr

Boolean, logical, grouping, relational, and comparison operators (see Table 27-2)

filter_arg

Arguments for filter expressions (see Table 27-2]

-A

Consult only the authoritative source. 

-L

Follow XFN links. 

-l

Display the object references for the matching objects. 

-v

Verbose. Display detailed object references for the matching objects. 

-O

Use an OSI OID as the identifier 

-U

Use a DCE UUID as the identifier 

Searching for Objects Associated With an Attribute

With the fnsearch command, you can search for objects that are associated with the attributes you choose.

For example, to find all the objects that are associated with the attribute for_sale in orgunit/sales/site/, you would enter the following command:


 % fnsearch orgunit/sales/site/ for_sale

Customizing Attribute Searches

You can also use all the following in filter expressions in your search patterns.

Table 27-2 fnsearch Filter Expression Operators

Filter Expression Operator 

Symbols and Forms 

Logical operators 

or, and, not

Parentheses for grouping 

( )

Relational operators: Compare an attribute to a supplied value 

== True if at least one attribute value is equal to the supplied value. != True if none of the attribute values are equal to the supplied value. < True if at least one attribute value is less than the supplied value. <= True if at least one attribute value is less than or equal to the supplied value. > True if at least one attribute value is greater than the supplied value. >= True if at least one attribute value is greater than or equal to the supplied value. ~= True if at least one attribute value matches the supplied value according to some context-specific approximate matching criterion. This criterion must subsume strict equality.

Example: 

% fnsearch name "not (make == 'olds' and year == 1983)"

Substitution tokens: 

Helpful when writing shell scripts; allow the use of OSI OIDs and DCE UUIDs when used with the -O and -U options

%a for attribute

%s for string

%i for identifier

%v for attribute value (only fn_attr_syntax_ascii is currently supported)

Example: 

The following three examples are equivalent. 

% fnsearch name "color == 'red'"

% fnsearch name "%a == 'red'" color

% fnsearch name "%a == %s" color red

Wild card strings 

*, *string, string*, str*ing, %s*

Extended operators 

'name'(wildcarded_string), 'reftype'(identifier), 'addrtype' (identifier)

Example: 

Search for objects with names starting with "Bill" and IQ attributes over 80. 

% fnsearch name "'name'('bill'*) and IQ > 80"

See the fnsearch man page for detailed information about creating search patterns.

Updating Attributes

The fnattr command lets you update and examine attributes associated with FNS named objects. You can perform four attribute operations with the fnattr command: 


fnattr -a [-s] name [-O|-U] identifier values


fnattr -d name [[-O|-U] identifier [values]]
 

fnattr -m name [-O|-U identifier oldvalue newvalue


fnattr -l name [[-O|-U] identifier
Table 27-3 fnattr Command Options

Option 

Description 

name

Composite name. 

identifier

Attribute name. 

values

One or more attributes values 

oldvalue

The attribute value that you want to change. 

newvalue

The new attribute value. 

-aa

Add (create) a new attribute 

-d

Delete an attribute 

-m

Change (modify) an attribute 

-l

List attribute values 

-s

Add in "supersede" mode. Removes any existing values for the identifier attribute and creates new attribute values.

-l

List attributes and values. 

-O

Use an OSI OID as the identifier 

-U

Use a DCE UUID as the identifier 

In each of these cases, the identifier format is FN_ID_STRING, unless the option -O or -U is used.

Adding an Attribute

The -a option is for adding an attribute or adding a value to an attribute. Specify the composite name the attribute is associated with, the attribute identifier, and the values to add.


fnattr -a [-s] name [-O | -U] identifier value1 [value2+]

The following example adds the attribute identifier model and the value hplaser to thisorgunit/service/printer.


# fnattr -a thisorgunit/service/printer model hplaser

The -s option means "add in supersede" mode. If an attribute with the specified identifier already exists, -s removes all of its values and replaces them with the values added. If this option is omitted, the resulting values for the specified attribute includes the existing values and the new values added.


# fnattr -as thisorgunit/service/printer model hplaser

The example above will first remove any existing values associated with model and add hplaser as the value.

Deleting an Attribute

To delete an attribute associated with an FNS named object, use the -d option.


fnattr -d name [[-O | -U] identifier value1 [value2+]]]

You can control what to delete:

For example, to delete all the attributes associated with thisorgunit/service/printer.


# fnattr -d thisorgunit/service/printer

Listing an Attribute

The -l option is for listing attributes and their values.


fnattr -l name [[-O | -U] identifier]

For example to list the values of the model attribute of thisorgunit/service/printer.


# fnattr -l thisorgunit/service/printer model
laser
postscript

If an identifier is not specified, all the attributes associated with the named object are displayed.

Modifying an Attribute

The -m option lets you modify an attribute value.


fnattr -m name [-O | -U] identifier old_value new_value

For example, to replace the value postscript with laser you would enter:


# fnattr -m thisorgunit/service/printer model postscript laser

Only the specified values are affected. Other attributes and values associated with the name are not affected.

Other Options

The -O option assumes the format of the attribute identifier is an ASN.1 dot-separated integer string list (FN_ID_ISO_OID_STRING).

The -U option assumes the format of the attribute identifier is a DCE UUID string form (FN_ID_DCE_UUID).