Chapter 24 Enterprise Level Contexts

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

• "Creating Enterprise Level Contexts"

• "All Hosts Context"

• "Single Host Context"

• "Host Aliases"

• "All-Users Context"

• "Single User Context"

• "Service Context"

• "Printer Context"

• "Generic Context"

• "Site Context"

• "File Context"

• "Namespace Identifier Context"

• "Administering Enterprise Level Contexts"

• "Displaying the Binding"

• "Listing the Context"

• "Binding a Composite Name to a Reference"

• "Removing a Composite Name"

• "Renaming an Existing Binding"

• "Destroying a Context"

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

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. The 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:

• NIS+. The name of an existing NIS+ domain (or subdomain). An NIS+ domain is an NIS+ directory object with an org_dir subdirectory. Populated host and passwd tables for the domain must exist in the domain's org_dir subdirectory.

• NIS. The name of the NIS domain. Associated host and passwd maps must also exist.

• /etc files. There is only the org// organization context when using /etc files.

Organization Context NIS+ Example

Assume the root NIS+ domain is doc.com and there is a subdomain 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 orgthe 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:

• org/sales/host/antares/

• org/sales/host/capsule/service/

• org/sales/host/capsule/fs.

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.

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.

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

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]

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.

• The first usage allows the user to bind the reference of an existing name to a new name. (See below.)

• The second usage allows the user to bind a reference constructed using arguments in the command line to a name. (See "Constructing a Reference on the Command Line ".)

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

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}+

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.

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.