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

• 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. Only the org// organization context is available when using /etc files.

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:

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