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