Solaris Naming Setup and Configuration Guide

Part IV FNS Setup and Configuration

This part describes how to initially set up and configure the Federated Naming Service (FNS) in an NIS+, NIS, or /etc namespace environment.

Chapter 11, FNS Setup and Configuration, FNS Setup and Configuration

Chapter 11 FNS Setup and Configuration

This chapter describes how to initially set up and configure the Federated Naming Service (FNS) in an NIS+, NIS, or files-based naming environment. (Files-based naming refers to name services that obtain their data from /etc files rather than NIS+ or NIS.)

See Solaris Naming Administration Guide for a general description and overview of FNS.

Note -

The Solaris Naming Administration Guide contains an "FNS Quickstart" chapter that provides a summary overview of FNS, a brief description of setup and configuration steps, and a programming example. Experienced administrators may find that this quick start chapter is all they need.

Setting Up FNS--Overview

After your Solaris 7 release software is installed, you must perform the following tasks to set up FNS:

Make sure that your servers can handle FNS. See "Determining Resource Requirements".
Prepare your namespace for FNS. See "Preparing the Namespace for FNS".
Set up the FNS namespace contexts. There are two ways to do this:
1. Globally create all contexts in one process. See "Creating Global FNS Namespace Contexts".
2. Individually create your FNS contexts. See Solaris Naming Administration Guide.
Set up FNS replica servers. See "Replicating FNS Service".

Depending on the size of the organization, you should allow several hours for the FNS setup to be completed, plus additional time for namespace preparation.

Determining Resource Requirements

Before proceeding with any installation procedure, you must first ensure that the servers supporting FNS have sufficient memory and disk storage. Space for FNS is in addition to the space needed for your enterprise-level name service (NIS+, NIS, or files).

As a general rule-of-thumb, you will need approximately 17 Kbytes of disk storage for each user and host, plus adequate swap space. Where this disk storage space is located and how it is calculated varies according to your underlying enterprise-level naming service:

NIS+. The disk storage must be mounted on the machine that will function as the FNS server for the domain or subdomain. In an NIS+ environment, a server hosting the FNS ctx_dir directory does not have to be the same server hosting the standard NIS+ directories, such as org_dir. In order to more evenly distribute server load, many large installations choose to use separate machines for NIS+ and FNS servers. The amount of space needed on an FNS server in an NIS+ environment is determined by the number of users and hosts in the domain, or subdomain, for which the server provides naming.

NIS. The disk storage must be mounted on the machine that will function as the FNS server for the domain. In an NIS environment, a server hosting FNS does not have to be the same server hosting NIS. In order to more evenly distribute server load, many large installations choose to use separate machines for NIS and FNS servers. The amount of space needed on an FNS server in a NIS environment is determined by the number of users and hosts in the domain.

Files-based. When your enterprise-level name service is files-based, the amount of disk storage needed by FNS is determined by the number of users and hosts in /etc/users and /etc/hosts files of the machine mounting /var/fn. If every machine has its own /var/fn directory, then the amount of space needed is determined by each machine's user and host files. If /var/fn is mounted on one machine and exported to the rest of the machines on the network by NFS, the space needed by the machine hosting /var/fn is determined by the number of users and hosts in that machine's /etc/users and /etc/hosts files.

For example, to support an FNS environment in an NIS+ domain with 1200 users and hosts, you will need:

A minimum of 20 Mbytes of disk space beyond the space needed by your underlying enterprise namespace (NIS+, NIS, or files-based).

An additional 40 Mbytes of swap space

Preparing the Namespace for FNS

This section describes the preparations you need to make before running fncreate to set up your FNS contexts. The preparations vary according to your enterprise-level naming service.

Preparing the Namespace for FNS -- Task Map

Table 11-1 Preparing the Namespace for FNS


Task	Description	For Instructions, Go To
Preparing the Namespace for FNS	Prepare the namespace for FNS	"How To Prepare Source Files for Conversion to NIS Maps"
		"How to Prepare NIS Service for FNS"
		"Preparing Files-Based Naming for FNS"

How to Prepare NIS+ Service for FNS

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:
1. 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 Solaris Naming Administration Guide for more information on creating NIS+ directory objects with the nismkdir command.)
  
  Note -
  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.
2. Use the nisls command to verify that the ctx_dir directory has been created.
  rootmaster # nisls doc.com.ctx_dir
3. Run nisping to checkpoint the directory
  # /usr/lib/nis/nisping -C ctx_dir.doc.com.

How to Prepare NIS Service for FNS

Before setting up the FNS namespace, do the following:

Make sure that the hosts.byname, user.byname, and printer.conf.byname maps are complete, correct, and up to date.

Note -

You can assign a different master server for FNS maps, using the same procedure that you would to assign a different master for any other NIS map. See Solaris Naming Administration Guide for details.

Preparing Files-Based Naming for FNS

Files-based naming refers to name services that obtain their data from /etc files rather than NIS+ or NIS.

If you are going to install a /var/fn directory on each machine, as is normally the case, the steps below must be performed on each machine. If you decide to mount and export the /var/fn directory from one machine, the steps below need to be performed on the machine that exports /var/fn.

Make sure that the /etc/hosts and /etc/passwd files are complete and contain the names of all users and hosts.

Creating Global FNS Namespace Contexts

This section describes how to create your namespace globally for a given enterprise or NIS+ domain.

The FNS namespace is created by the fncreate command.

# fncreate -t org org//

Or, alternatively:

# fncreate -t org org/domain/

Where domain is the name of an NIS+ domain or subdomain.

The fncreate command creates the default contexts for the specified organization and all its subcontexts, including contexts and subcontexts for users and hosts in the organization.

For information on how to manually create individual FNS contexts, see Solaris Naming Administration Guide.

Creating Global FNS Namespace Contexts -- Task Map

Table 11-2 Globally Creating FNS Namespace Contexts


Task	Description	For Instructions, Go To
Globally Creating FNS Namespace Contexts	Create FNS namespace contexts	"How to Create Namespace Contexts Under NIS+"
		"How to Create Namespace Contexts Under NIS"
		"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 (see Solaris Naming Administration Guide for information on NIS+ 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:

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

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. See Solaris Naming Administration Guide for details.

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 11-3 Replicating FNS Service


Task	Description	For Instructions, Go To
Replicating FNS Service	Replicate FNS service	"How to Replicate FNS Under NIS+"
		"How to Replicate FNS Under NIS"
		"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.

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.

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.

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

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

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 NIS Clients" for details.)

To determine if ypbind is running, type:
# ps -ef | grep ypbind
If a listing is displayed, ypbind is running.

If ypbind is running, stop it by typing:
# /usr/lib/netsvc/yp/ypstop

Type the following to restart ypbind:
# /usr/lib/netsvc/yp/ypstart

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.

Stop yp processes on the Slave Server:
# /usr/lib/netsvc/yp/ypstop

Restart yp service:
# /usr/lib/netsvc/yp/ypstart
Alternatively, you can reboot the slave server and allow daemons to start automatically.

How to Replicate FNS Under Files-Based Naming

There is no server replication when your primary naming service is files-based.

FNS Administration, Problem Solving, and Error Messages

See Solaris Naming Administration Guide for information on FNS administration, problem solving, and error messages.