How to Configure a Non-root Domain (System Administration Guide: Naming and Directory Services (FNS and NIS+))

System Administration Guide: Naming and Directory Services (FNS and NIS+)

How to Configure a Non-root Domain

Log in to the domain's master server.

Log in to the server that you will designate as the new domain's master. The steps in this task use the server named smaster, which belongs to the doc.com. domain, and will become the master server of the sales.doc.com. subdomain. The administrator performing this task is nisboss.doc.com., a member of the admin.doc.com. group. That group has full access rights to the doc.com. directory object.

Name the domain's administrative group.

Although you won't actually create the admin group until Step 5, you need to identify it now. This enables the nismkdir command used in the following step to create the directory object with the proper access rights for the group. It does the same for the nissetup utility used in Step 4.

Set the value of the environment variable NIS_GROUP to the name of the domain's admin group. Here are two examples, one for C shell users and one for Bourne or Korn shell users. They both set NIS_GROUP to admin.sales.doc.com.

For C Shell
smaster# setenv NIS_GROUP admin.sales.doc.com.
For Bourne or Korn Shell
smaster# NIS_GROUP=admin.sales.doc.com. smaster# export NIS_GROUP

Create the domain's directory and designate its servers.

The nismkdir command, in one step, creates the new domain's directory and designates its supporting servers. It has the following syntax:
nismkdir -m master -s replica domain
The -m flag designates its master server, and the -s flag designates its replica.
smaster# nismkdir -m smaster -s salesreplica sales.doc.com.
Caution –
Always run nismkdir on the master server. Never run nismkdir on the replica machine. Running nismkdir on a replica creates communications problems between the master and the replica.

The directory is loaded into /var/nis. Use the niscat -o command to view it (do not use cat or more).
smaster# niscat -o sales.doc.com. Object Name : Sales Owner : nisboss.doc.com. Group : admin.sales.doc.com. Domain : doc.com. Access Rights : ----rmcdr---r--- .
Unlike the root directory, this directory object does have the proper group assignment. As a result, you won't have to use nischgrp.

Create the domain's subdirectories and tables.

This step adds the org_dir and groups_dir directories and the NIS+ tables beneath the new directory object. Use the nissetup utility, but be sure to add the new domain name. And, for an NIS-compatible domain, include the -Y flag.

NIS compatible

smaster# /usr/lib/nis/nissetup -Y sales.doc.com.

NIS+

smaster# /usr/lib/nis/nissetup sales.doc.com.

Each object added by the utility is listed in the output:

smaster# /usr/lib/nis/nissetup
org_dir.sales.doc.com. created
groups_dir.sales.doc.com. created
auto_master.org_dir.sales.doc.com. created
auto_home.org.dir.sales.doc.com. created
bootparams.org_dir.sales.doc.com. created
cred.org_dir.sales.doc.com. created
ethers.org_dir.sales.doc.com. created
group.org_dir.sales.doc.com. created
hosts.org_dir.sales.doc.com. created
mail_aliases.org_dir.sales.doc.com. created
sendmailvars.org_dir.sales.doc.com. created
netmasks.org_dir.sales.doc.com. created
netgroup.org_dir.sales.doc.com. created
networks.org_dir.sales.doc.com. created
passwd.org_dir.sales.doc.com. created
protocols.org_dir.sales.doc.com. created
rpc.org_dir.sales.doc.com. created
services.org_dir.sales.doc.com. created
timezone.org_dir.sales.doc.com. created

The -Y option creates the same tables and subdirectories as for a standard NIS+ domain, but assigns read rights to the nobody class so that requests from NIS clients, which are unauthenticated, can access information in the NIS+ tables.

You can verify the existence of the org_dir and groups_dir directories by looking in your master server's /var/nis/data directory. They are listed along with the root object and other NIS+ tables. The tables are listed under the org_dir directory. You can examine the contents of any table by using the niscat command, described in Chapter 9, Setting Up NIS+ Tables (although at this point the tables are empty).

Create the domain's admin group.

This step creates the admin group named in Step 2. Use the nisgrpadm command with the -c option. This example creates the admin.sales.doc.com. group
smaster# nisgrpadm -c admin.sales.doc.com. Group admin.sales.doc.com. created.
This step only creates the group—it does not identify its members. That is done in Step 9.

Assign full group access rights to the directory object.

By default, the directory object grants only its group read access, which makes the group no more useful than the world class. To make the configuration of clients and subdomains easier, change the access rights that the directory object grants its group from read to read, modify, create, and destroy. Use the nischmod command.
smaster# nischmod g+rmcd sales.doc.com.
Complete instructions for using the nischmod command are provided in Chapter 15, Administering NIS+ Access Rights.

Add the servers to the domain's admin group.

At this point, the domain's group has no members. Add the master and replica servers, using the nisgrpadm command with the -a option. The first argument is the group name; the others are the names of the new members. This example adds smaster.doc.com. and salesreplica.doc.com. to the admin.sales.doc.com. group:

smaster# nisgrpadm -a admin.sales.doc.com. smaster.doc.com. 
salesreplica.doc.com.
Added smaster.doc.com. to group admin.sales.doc.com.
Added salesreplica.doc.com. to group admin.sales.doc.com.

To verify that the servers are indeed members of the group, use the nisgrpadm command with the -l option (see Chapter 17, Administering NIS+ Groups).

smaster# nisgrpadm -l admin.sales.doc.com.
 Group entry for admin.sales.doc.com. group:
 Explicit members:
 smaster.doc.com.
 salesreplica.doc.com.
 No implicit members
 No recursive members
 No explicit nonmembers
 No implicit nonmembers
 No recursive nonmembers

Add credentials for other administrators.

Add the credentials of the other administrators who will work in the domain.

For administrators who already have DES credentials in another domain, add LOCAL credentials. Use the nisaddcred command with both the -p and the -P flags.

smaster# nisaddcred -p 33355 -P nisboss.doc.com. local

For administrators who do not yet have credentials, you can proceed in two different ways.

One way is to ask them to add their own credentials. However, they will have to do this as superuser. Here is an example in which an administrator with a UID of 22244 and a principal name of juan.sales.doc.com. adds his own credentials to the sales.doc.com. domain.

smaster# nisaddcred -p 22244 -P juan.sales.doc.com. local
smaster# nisaddcred -p unix.22244@sales.doc.com -P juan.sales.doc.com. des
Adding key pair for unix.22244@sales.doc.com.
Enter login password:

The other way is for you to create temporary credentials for the other administrators, using dummy passwords (each administrator must have an entry in the NIS+ passwd table).

smaster# nisaddcred -p 22244 -P juan.sales.doc.com. local
smaster# nisaddcred -p unix.22244@sales.doc.com -P juan.sales.doc.com. des
Adding key pair for unix.22244@sales.doc.com.
Enter juan's login password:
nisaddcred: WARNING: password differs from login passwd.
Retype password:

Each administrator can later change his or her network password by using the chkey command. Chapter 12, Administering NIS+ Credentials and Chapter 13, Administering NIS+ Keys describe how to do this.

Note –

In the two examples shown in Step 8, the domain name following the lower case -p flag must never end in a trailing dot, while the domain name following the upper case -P flag must always end in a trailing dot.

Add the administrators to the domain's admin group.

You don't have to wait for the other administrators to change their dummy passwords to perform this step. Use the nisgrpadm command with the -a option. The first argument is the group name, and the remaining arguments are the names of the administrators. This example adds the administrator juan to the admin.sales.doc.com. group:
smaster# nisgrpadm -a admin.sales.doc.com. juan.sales.doc.com. Added juan.sales.doc.com. to group admin.sales.doc.com.

Allocate sufficient swap space to accommodate NIS+ tables.

Swap space should be double the size of the maximum size of rpc.nisd. To determine how much memory rpc.nisd is using, issue the following command:
rootmaster# /usr/lib/nis/nisstat
rpc.nisd will under certain circumstances fork a copy of itself. If there is not enough memory, rpc.nisd fails.

You can also calculate the memory and swap space requirements for NIS+ tables. For example, if you have 180,000 users and 180,000 hosts in your NIS+ tables, those two tables occupy approximately 190 Mbytes of memory. When you add credentials for 180,000 users and 180,000 hosts, the cred table has 540,000 entries (one entry for each local user credential, one entry for each DES user credential, and one entry for each host). The cred table occupies approximately 285 Mbytes of memory. In this example, rpc.nisd occupies at least 190 Mbytes + 285 Mbytes = 475 Mbytes of memory. So, you will require at least 1 Gbyte swap space. You will also want at least 500 Mbytes of memory to hold rpc.nisd entirely in memory.