Sun Microsystems, Inc.
spacerspacer
spacer www.sun.com docs.sun.com |
spacer
black dot
 
 
25.  Federated Naming Service (FNS) Creating Global FNS Namespace Contexts  Previous   Contents   Next 
   
 

Creating Global FNS Namespace Contexts -- Task Map

Table 25-11 Globally Creating FNS Namespace Contexts

Task

Description

For Instructions, Go To

Globally Creating FNS Namespace Contexts

Create FNS namespace under NIS+

"How to Create Namespace Contexts Under NIS+"

Globally Creating FNS Namespace Contexts

Create FNS namespace under NIS

"How to Create Namespace Contexts Under NIS"

Globally Creating FNS Namespace Contexts

Create FNS namespace under files

"How to Create Namespace Contexts Under Local Files"

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

Task

Description

For Instructions, Go To

Replicating FNS Service

Replicate FNS service under NIS+

"How to Replicate FNS Under NIS+"

Replicating FNS Service

Replicate FNS service under NIS

"How to Replicate FNS Under NIS"

Replicating FNS Service

Replicate FNS service under files

"How to Replicate FNS Under Files-Based Naming"

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.

How to Replicate FNS Under NIS

After the FNS namespace has been set up on the domain master server, additional slave servers can be added to enhance availability and performance of the servers.

  1. As root, edit the /etc/hosts file on the slave server to add the name and IP addresses of all the other NIS servers.

  2. Change directory to /var/yp on the slave server.

  3. To initialize the slave server as a client, type the following:

    # /usr/sbin/ypinit -c

    The ypinit command prompts you for a list of NIS servers. Enter the name of the local slave you are working on first, then the master server, followed by the other NIS slave servers in your domain in order, from the physically closest to the furthest (in network terms).


    Note - You must first configure the new slave server as an NIS client so that it can get the NIS maps from the master for the first time. (See "Setting Up and Configuring NIS Service" in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) for details.)


  4. To determine if ypbind is running, type:

    # ps -ef | grep ypbind

    If a listing is displayed, ypbind is running.

  5. If ypbind is running, stop it by typing:

    # /usr/lib/netsvc/yp/ypstop

  6. Type the following to restart ypbind:

    # /usr/lib/netsvc/yp/ypstart

  7. To initialize this machine as a slave, type the following:

    # /usr/sbin/ypinit -s master

    Where master is the machine name of the existing NIS master server.

  8. Stop yp processes on the Slave Server:

    # /usr/lib/netsvc/yp/ypstop

  9. Restart yp service:

    # /usr/lib/netsvc/yp/ypstart

    Alternatively, you can reboot the slave server and allow daemons to start automatically.

 
 
 
  Previous   Contents   Next