Creating Global FNS Namespace Contexts -- Task Map

Table 25-11 Globally Creating FNS Namespace Contexts

How to Create Namespace Contexts Under NIS+

When your primary enterprise-level name service is NIS+, namespace contexts must be created separately for each NIS+ domain or subdomain in your enterprise.

• The NIS+ domain or subdomain must already exist.

• If you intend to use the same server for both NIS+ and FNS, you must run the fncreate command on the domain's (or subdomain's) master server. If you intend to use different servers for NIS+ and FNS, you must run the fncreate command on the machine that will function as the FNS server. (If you are going to use different machines, you must first prepare the FNS server, as explained in Step 4.)

• You must have full NIS+ administration authorization.

For example, to create the contexts for the manf.doc.com subdomain on the submaster machine that is the NIS+ master server for that domain:

1. On the subdomain master, run fncreate as shown below:

submaster# fncreate -t org org/manf.doc.com./

This creates the organization context for the NIS+ manf.doc.com. subdomain, and contexts and associated subcontexts for all users found in that subdomain's passwd.org_dir table and all hosts found in the subdomain's hosts.org_dir table.

(If you want to use different machines for NIS+ and FNS servers, run the above command on the machine you want to use as the FNS server. See Step 4 for information on how to prepare a non-NIS+ server to be an FNS server.)

1. Use nisping to checkpoint the ctx_dir directory:

   # /usr/lib/nis/nisping -C ctx_dir.manf.doc.com.

   
   

   ---

   Note - For a large organization with several thousand users and hosts, the initial fncreate operation can take several hours; the subsequent checkpoint can also take several hours.

   ---

How to Create Namespace Contexts Under NIS

When your primary enterprise-level name service is NIS, there is only one domain for the enterprise. Namespace contexts are created for that enterprise-wide domain.

• The NIS domain must already exist.

• The fncreate command must be run by root on the FNS master server. (Normally, this would be the NIS master server, but you could choose to use a different server.)

For example, create the contexts for the doc.com domain, on the machine named fns_master, which is also the NIS master server:

• On the domain master, run fncreate as shown below:

  fns_master# fncreate -t org org//

  
  

  This creates the organization context for the NIS domain doc.com, and contexts and associated subcontexts for all users found in NIS servers's passwd map and all hosts found in the server's hosts map.

  ---

  Note - After you have created your context maps, you can assign the same machine to be the master server, using the same procedure that you would to assign a different master for any other NIS map. The FNS maps all have names starting with fns_ and ending with either .ctx or .attr.

  ---

How to Create Namespace Contexts Under Local Files

When your primary enterprise-level name service is files-based, namespace contexts are created for the system.

• The /etc/passwd and /etc/hosts files on the machine where the /var/fn directory resides must be clean and fully populated.

• The fncreate command must be run by root on the machine where the /var/fn directory resides.

For example, to create the contexts for the system:

• On the machine hosting the /var/fn directory, run fncreate, as shown below:

  server1# fncreate -t org org//

  
  

This creates the organization context for the system and contexts and associated subcontexts for all users found in machine's /etc/passwd file, and all hosts found in the machine's /etc/hosts file.

Replicating FNS Service

On large or mission-critical networks where performance and reliability of FNS naming is of vital importance, FNS service should be replicated.

Replicating FNS Service -- Task Map

Table 25-12 Replicating FNS Service

How to Replicate FNS Under NIS+

After the FNS namespace has been set up on the master server, additional replicas can be added in each domain to serve the domain's ctx_dir directory. Replicas enhance availability and performance of the servers.

1. Run the nismkdir command on the FNS master server to add a replica for the ctx_dir directory.

   For example, establish the machine fnsrserver as an FNS replica for the doc.com. domain:

   # nismkdir -s fnsrserver ctx_dir.doc.com.

   
   

2. Checkpoint the ctx_dir directory with the nisping command.

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

   
   

   FNS replicas should be checkpointed at regular intervals. The recommended period is every few days. The period you choose depends on how frequently changes are made to the FNS namespace.