Before setting up the FNS namespace, do the following:
Make sure that the NIS+ domain is properly set up.
The NIS+ domain and associated subdomains must already be set up before configuring FNS. In other words, NIS+ standard tables, such as hosts and passwd, must already exist and be populated.
Make sure that the domain's hosts.org_dir and passwd.org_dir tables are fully populated with the names of every host and user.
You can use the niscat or nismatch commands to check the contents of these tables.
Set the NIS_GROUP
environment variable to the
name of the group that will be administering the FNS objects.
The fncreate command will not let you complete the
FNS setup without setting this variable first. When fncreate
creates user and host contexts, they are 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 though they do not own the objects.
Assuming a C-Shell, the example below sets NIS_GROUP
to fns_admins.doc.com.
rootmaster# setenv NIS_GROUP fns_admins.doc.com |
[Optional] Specify that FNS run on a machine other than the NIS+ master server.
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. For large domains, such as those with more than 5000 users and hosts, it is recommended (though not required) that the ctx_dir used by FNS be supported by a server different from the one supporting the standard NIS+ directories, such as groups_dir. Using separate servers avoids placing too much load on one server. It also allows you to keep separate the administration of FNS's use of NIS+ and the administration of NIS+ itself.
To specify that FNS be hosted by a machine that is not the NIS+ master server for the domain, you must manually create a ctx_dir directory object on the machine that will serve as the FNS host for the domain. (If you omit this step, FNS will be installed on the domain's NIS+ root master server.)
To specify the machine that will become the FNS master server:
Create the ctx_dir directory for the NIS+ domain.
For example, to create a ctx_dir directory on a machine named fns_server in the doc.com domain, run the following command on the domain's master server (note the trailing dot at the end of the domain name, as shown):
nismaster# nismkdir -m fns_server ctx_dir.doc.com. |
(See The nismkdir Command for more information on creating NIS+ directory objects with the nismkdir command.)
If you are creating an FNS ctx_dir directory for a subdomain, the machine you specify as the FNS server hosting ctx_dir must reside in the subdomain, it cannot be a machine in the parent domain. (By contrast, a subdomain's NIS+ master server always resides in the domain above the one it serves.) In other words, when configuring FNS for an NIS+ subdomain, if you use the same server for both NIS+ and FNS, that server resides in the domain above the subdomain; but if you use different servers for NIS+ and FNS, the NIS+ master server resides in the domain above and the FNS server resides in the subdomain that it serves.
Use the nisls command to verify that the ctx_dir directory has been created.
rootmaster # nisls doc.com.ctx_dir |
Run nisping to checkpoint the directory
# /usr/lib/nis/nisping -C ctx_dir.doc.com. |