Setting Up FNS

Setting up FNS involves preparing the NIS+ environment that FNS will use and then creating FNS contexts for organizations, users, hosts, services, and sites. Depending on the size of the organization, you should allow several hours for the FNS set up to be completed, not including the required hardware and software preparation or any NIS+ preparation.

Estimating Resource Requirements

Before proceeding with any installation procedure, you must first ensure that the machines on which NIS+ servers for supporting FNS will run have sufficient memory and disk storage.

For example, to support an FNS environment with 1200 users and hosts, you will need

• A minimum of 20 Mbytes of disk space beyond the space needed for NIS+
• An additional 40 Mbytes of swap space

Setting Up NIS+ Service for FNS

NIS+ objects used by FNS and standard NIS+ domain information should be supported on separate sets of servers. This avoids placing additional loads on the standard NIS+ service. It also allows you to keep the administration of FNS's use of NIS+ and the standard NIS+ service separate.

All NIS+ objects used by FNS are kept under the ctx_dir directory of an NIS+ domain, at the same level as the domain's org_dir directory. The NIS+ domain must be already set up before setting up FNS. That is, NIS+ domain tables such as hosts and passwd must already exist and be populated.

Before setting up the FNS namespace, do the following:

1. Set the NIS_GROUP environment variable to the name of the group that will be administering the FNS objects.

   In fact, the fncreate command will not let you complete the FNS set up without setting the variable first. In this example, NIS_GROUP is set to fns_admins.wiz.com. When fncreate creates user and host contexts, they will be owned by those hosts and users, and not by the administrator who executed the command. Setting NIS_GROUP allows the administrators who are members of the group to subsequently modify these contexts even thought they do not own the objects.

# set NIS_GROUP=fns_admins.wiz.com;export nis_group

2. To set up separate servers, create the ctx_dir directory for the NIS+ domain. Assign a master server to service it using the NIS+ command nismkdir.

   The example shows how nismkdir creates the ctx_dir directory and assigns the machine fns_mserver to be the master server for that directory. Include the trailing dot as shown.

# nismkdir -m fns_mserver ctx_dir.wiz.com.

3. Use the nisls command to verify that the ctx_dir directory has been created.

# nisls wiz.com. ctx_dir groups_dir org_dir

Setting Up the FNS Namespace

The FNS namespace is created by the fncreate command. This command creates the contexts for the specified organization and all its subcontexts, including contexts for users and hosts in the NIS+ domain corresponding to the organization.

1. For a standard setup, use the syntax of fncreate as shown. This creates the organization context for the root NIS+ domain, wiz.com., contexts for all users found in the passwd.org_dir table, and contexts for all hosts found in the hosts.org_dir table in the wiz.com NIS+ domain.

# fncreate -t org org//

After setting up the FNS namespace, you should checkpoint the ctx_dir directory before performing other FNS operations.

2. Use nisping to checkpoint the ctx_dir directory:

# /usr/lib/nis/nisping -C ctx_dir.wiz.com.

For an organization with a few thousand users and hosts, the initial fncreate for an organization will typically take several hours; the subsequent checkpoint will also typically take several hours.

Replicating FNS Service

Additional replicas should be added to serve the ctx_dir directory after the FNS namespace has been set up on the master server. Replicas enhance availability and read performance of the servers.

1. Use the nismkdir -s command to add a replica fns_rserver for the ctx_dir directory and send the contents of the directory to the replica.

# nismkdir -s fns_rserver ctx_dir.wiz.com.

2. Checkpoint the ctx_dir directory periodically with the nisping command.

   The recommended period is every few days. The period you choose depends on how frequently changes are made to the FNS namespace.

# /usr/lib/nis/nisping -C ctx_dir.wiz.com.

At this point, you are done with the initial FNS setup.

Creating FNS Contexts Individually

FNS contexts are created using the fncreate(1M) command. This section describes the fncreate command and its other options. Use this section to create FNS contexts individually rather than for the entire organization as described in the section "Setting Up the FNS Namespace" on page 255.

The fncreate command has the following syntax,

fncreate -t context_type [-f input_file][-o][-r reference_type][-s][-v] [-D] composite_name

where context_type specifies one of the following: org, hostname, username, host, user, service, site, nsid, generic, or fs.

fncreate creates a context of the specified type and binds it to the given composite name. It also creates subcontexts for the context.

When fncreate creates contexts, it also creates corresponding NIS+ directories and tables. These new directories and tables are managed by the same servers that manage the parent contexts of the new contexts, and can be administered using the same tools used to administer NIS+ entities.

Table 14-1 fncreate

Option	Description
-t	Specifies the type of context to create.
-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 specified1. 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.

1. The org context is the exception where the contexts for host name and user name are created but 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.

Organization Context

Use the org type to create an organization context. The composite name must be that of an existing NIS+ domain. An NIS+ domain is an NIS+ directory with an org_dir subdirectory. Associated host and passwd tables for the domain must also exist.

Assume the root NIS+ domain is wiz.com. In the example

# fncreate -t org org/sales/

there must be an NIS+ domain named 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.wiz.com. The previous example 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.

Effectively, the following commands are run:

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

When fncreate -o -t org is used, only the organization context is created. The hostname, username, and service contexts are 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 access host and user contexts, the NIS_GROUP environment variable must be set accordingly. See "Setting Up NIS+ Service for FNS" on page 254 for instructions.

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 host 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 hostname org/sales/host/hname/

for each host name, hname, 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 host 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 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/capsule/

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

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

The host context and its subcontexts are owned by the host. In the above example, the host capsule, with NIS+ principle name capsule.sales.wiz.com, owns the contexts org/sales/host/capsule/ and org/sales/host/capsule/service/.

The hostname context to which the host belongs must already exist. The host 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 host name context are bound to the reference of that host context.

All Users Context

The username type creates a username context in which 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/

for each user, uname, that appears 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. A user context and its subcontexts are owned by the user 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 a 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.wiz.com.

The username context 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 a 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 rolodex, 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, which allows an application to partition its namespace 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 context.

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

Names such as org/sales/service/plotter/speedy and org/sales/service/plotter/production 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. Refer to Chapter 17, "Administering the Printer Namespace," for more information.

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 the 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 using 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/site/east # fncreate -t site org/sales/site/maynard.east

create a site context east and a site subcontext maynard.east for it.

---

Note - Because these terminal atomic names are not namespace identifiers, no additional binding 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 simply file context) for a user or a host. For example, the command

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

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

The file context of a user is the user's home directory as it is stored in the NIS+ passwd.org_dir table. The file 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 available for users and hosts. See Chapter 16, "Administering the File System Namespace," 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/maynard.east/

creates a nsid context for the site maynard.east, 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/maynard.east/service/

to create a service context for maynard.east.

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

Managing and Examining FNS Contexts

A number of tools are provided for examining and managing FNS contexts. The commands and their syntax are shown as follows. For additional information, see the man page for the tool. Note that fnbind has two usages.

fnlookup [-v][-L] composite_name fnlist [-l][-v] [composite_name] fnbind [-s][-v][-L] name new_name fnbind -r [-s] [-v] new_name [-O | -U] ref_type {[-O | -U] | address_type [-c|-x] address_contents}+ fnunbind composite_name fnrename [-sv] context_name old_atomic_name new_atomic_name fndestroy composite_name

Displaying the Binding

fnlookup displays the binding of the given composite name.

Table 14-2 fnlookup

Option	Description
-v	Displays the binding in more detail
-L	Displays the reference to which the XFN link is bound

For example, the command

# fnlookup user/jjones/ Reference type: onc_fn_user Address type: onc_fn_nisplus context type: user

shows the binding of the user jjones.

# fnlookup -v user/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.wiz.com.

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

# fnlookup user/James.Jones Reference type: fn_link_ref Address type: fn_link_addr Link name: user/jjones # fnlookup -L user/James.Jones 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.

Table 14-3 fnlist

Option	Description
-v	Displays the binding in more detail
-l	Displays the bindings of the names bound in the named context

For example, the command

# fnlist user/ Listing 'user/': jjones mladd jsmith James.Jones

shows the bindings under the user context.

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

# fnlist Listing '': _myorgunit ... _myself thishost myself _orgunit _host _thisens myens thisens org orgunit 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: mladd Reference type: onc_fn_user Address type: onc_fn_nisplus context type: user name: jsmith 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: mladd Reference type: onc_fn_user Address type: onc_fn_nisplus length: 52 context type: user representation: normal version: 0 internal name: fns_user_mladd.ctx_dir.sales.wiz.com. name: jsmith Reference type: onc_fn_user Address type: onc_fn_nisplus length: 52 context type: user representation: normal version: 0 internal name: fns_user_jsmith.ctx_dir.sales.wiz.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.wiz.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. The second usage allows the user to bind a reference constructed using arguments in the command line to a name.

Table 14-4 fnbind

Option	Description
-s	Supercede 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
-c	Stores address contents without XDR encoding
-x	Interprets address contents as a hexadecimal input string and store it as is
-r	Create a reference with a specified type and bind 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 an DCE UUID

The first usage of fnbind is

fnbind [-s][-v][-L] name new_name

For example, the command

# fnbind myorgunit/service/printer user/mladd/service/printer

binds the name user/mladd/service/printer to the reference of

myorgunit/service/printer.

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

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

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

# fnbind -v myorgunit/service/printer user/mladd/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, the following creates a link from user/mladd/service/printer to myorgunit/service/printer

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

The second usage of fnbind constructs a reference using arguments in the command line and bounds it to the given name.

fnbind -r [-s] [-v] new_name [-O | -U] ref_type {[-O | -U] | address_type [-c|-x]address_contents}+

For example

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

binds the name thisorgunit/service/calendar to the reference with type onc_calendar and address type onc_cal_str and address contents of staff@exodus.

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 the clear, not as an XDR-endoded 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 example, the following command binds to the name thisorgunit/service/nx a reference with OIDs as reference and address types and a hexadecimal string as the address contents.

# 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, the command

# fnunbind user/jjones/service/printer/color

removes the binding associated with the name user/jjones/service/printer/color.

Renaming an Existing Binding

fnrename renames an existing binding. The following example renames the binding of clndr to calendar, in the context named by user/jjones/service/.

# fnrename user/jjones/service/ clndr calendar

The -s option is used to overwrite any binding to new_atomic_name.

---

1. See ISO 8824: 1990, Information Technology -- Open Systems Interconnection -- Specification of Abstract Syntax Notation One (ASN.1)

2. See X/Open Preliminary Spcification, October 1993, X/Open DCE : Remote Procedure Call (ISBN: 1- 872630-95-2)

Destroying the Named Context

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

For example, the command

# fndestroy user/jjones/

unbinds the name user/jones/ from the namespace and destroys the context named by user/jjones/.

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

Managing and Examining FNS Attributes

The fnattr command lets you update and examine attributes associated with FNS named objects. The four main options are for adding, deleting, listing, and modifying an attribute. 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. You need to specify the composite name the attribute is associated with, the attribute identifier, and the values to add.

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

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

# fnattr -as thisorgunit/service/printer model hplaser

Deleting an Attribute

To delete an attribute associated with an FNS named object, use the -d option. You can control what to delete:

• If an identifier is not specified, all the attributes associated with the named object are removed.
• If an identifier is specified, but without values, the entire attribute identified by identifier is removed.
• If individual values are specified, then only those values are removed from the attribute. Removal of the last value of an attribute is the same as removing the attribute itself.

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

The following command deletes 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. The command syntax is

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

The following example lists 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. The command syntax is

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

For example,

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

replaces the value postscript with laser. Other attributes and values associated with thisorgunit/service/printer are not affected.

Other Options

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 it with the value(s) added. If this option is omitted, the resulting values for the specified attribute includes the existing values and the new values added.

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

Maintaining Consistency Between NIS+ and FNS

A key task of the system administrator is to maintain consistency between FNS and NIS+. This means that the contents of FNS contexts and NIS+ tables must correspond. This correspondence is initially accomplished by the fncreate command, which ensures that FNS contexts are correctly created and populated and are consistent with NIS+ directory object and directory structures. After the FNS contexts have been set up, the correspondence needs to be maintained as new users and hosts are added to and removed from the system.

The Solstice AdminSuite product that adds user and host information to NIS+ also updates FNS. When updates to FNS or NIS+ are made independent of the Solstice AdminSuite, the resulting inconsistencies can be resolved by the use of the FNS tool, fncheck. fncheck checks for inconsistencies between user and host names in FNS, and user and host names in NIS+.

Checking Naming Inconsistencies

The fncheck command checks for naming inconsistences between FNS hostname and username contexts, and the NIS+ standard system tables hosts.org_dir and passwd.org_dir, respectively. fncheck lists host and/or user names that are in the FNS namespace but are not in the NIS+ standard system tables. It also lists host or user names that are in the NIS+ standard system tables but not in the FNS namespace.

The command syntax is

fncheck[-r][-s][-u][-t hostname|username][domain_name]

Table 14-5 fncheck

Option	Description
-t	Specifies the type of context to check
-s	Lists host or user names from the NIS+ standard system tables 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 NIS+ standard system tables
-u	Updates the FNS namespace based on information in the relevant NIS+ standard system tables

The -t option is used to check hostname and username contexts. For the hostname option, the hostname context associated with the organization is checked against the NIS+ hosts.org_dir table of the same organization. For the username option, the username context associated with the organization is checked against the NIS+ passwd.org_dir table in the same organization. When the -t option is omitted, both hostname and username contexts are checked.

The -s option does not list hosts or users that are already in the FNS namespace.

If the -r option is used in conjunction with the -u option, items that appear only in the FNS context are removed from the FNS context. If the -s option is used, items that appear only in the NIS+ standard system tables 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 NIS+ table.

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.

Mapping FNS Contexts to NIS+ Objects

FNS contexts are stored as NIS+ objects. All contexts associated with an organization are stored under the ctx_dir directory of the associated NIS+ domain, which resides at the same level as the org_dir directory of the same domain.

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, lists all 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 wiz.com. wiz.com.: eng sales org_dir ctx_dir

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

List the contents of the fns_hosts table by using the niscat command.

# niscat fns_host.ctx_dir alto *BINARY* *BINARY* mladd *BINARY* *BINARY* elvira *BINARY* *BINARY*

Checking Access Control

Use niscat -o to see the access control of a context.

# niscat -o fns_host.ctx_dir Object Name:fns_host Owner: alto.wiz.com. Group: admin.wiz.com. Domain: ctx_dir.wiz.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:-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-

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 "[atomicname=alto],fns_host.ctx_dir" Object Name:fns_host Owner: alto.wiz.com. Group: admin.wiz.com. Domain: ctx_dir.wiz.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

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

• nischown
• nischmod
• nischgrp

and give as an argument either the binding entry or the bindings table, depending on the object the operation is to effect.

Significance of Double Slashes

In the name, org//, the double slashes identifies the context of namespace identifiers associated with the root organizational name, as in

org//service/printer.

In contrast, org/ points to the root of the organizational context. Each org context has suborganizations as well as a pointer to context that contains namespace identifiers such as service, user, and host. org/ names the root organizational context in which you can name suborganizations, as in org/sales.finance.

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, the name, org/sales.finance names the context for naming suborganizations of the sales.finance organization, as in org/audit.sales.finance.

On the other hand, org/sales.finance/ names the context for naming namespace identifiers of the sales.finance organization, as in org/sales.finance/service/printer.

Troubleshooting and Error Messages

For troubleshooting common FNS problems and solving them, see "FNS Problems and Solutions" on page 343

For example, a user attempted to create a context for org//service/trading/bb. The name org//service/ was resolved successfully, but trading was not found in the context named by org//service/.

Thus, trading/bb is displayed as the part of the name that remains when the operation failed:

Error in creating 'org//service/trading/bb': Name Not Found: 'trading/bb'

In another example, a user attempted to destroy the context org//service/dictionary/english, but could not carry out the operation because the context named was not empty. The pair of single quotes ('') indicates that FNS was able to resolve the complete name given, but could not complete the operation as requested:

Error in destroying 'org//service/dictionary/english': Context Not Empty: ''

For an alphabetic listing of common FNS error messages, see Appendix B, "Error Messages." For troubleshooting common FNS problems and solving them, see "FNS Problems and Solutions" on page 343.