Chapter 4 Configuring NIS+ With Scripts

This chapter describes how to configure a basic NIS+ namespace using the nisserver, nispopulate, and nisclient scripts in combination with a few NIS+ commands.

NIS+ might not be supported in a future release. Tools to aid the migration from NIS+ to LDAP are available as of the Solaris 9 release. For more information, see System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) and visit NIS+ End-of-Feature (EOF) Announcement FAQ.

NIS+ Configuration Overview

Using the configuration scripts is the recommended method of setting up and configuring an NIS+ namespace. Using these scripts is easier than to trying to set up an NIS+ namespace with the NIS+ command set, as described in Chapter 6, Configuring NIS+ Clients, Chapter 7, Configuring NIS+ Servers, and Chapter 8, Configuring an NIS+ Non-Root Domain.

(See the nisserver, nispopulate, and nisclient man pages for complete descriptions of the scripts. See the Glossary for definitions of terms and acronyms you do not recognize.)

You should not use the small sample NIS+ namespace referred to in this tutorial manual as a basis for your actual NIS+ namespace. You should destroy the sample namespace after you finish exploring it, instead of adding on to it. It is better to begin again and carefully plan your NIS+ hierarchy before you create your actual namespace.

Table 4–1 summarizes the recommended generic configuration procedure. The left column lists the major configuration activities, such as configuring the root domain or creating a client. The text in the middle describes the activities. The third column lists which script or commands accomplish each step.

The NIS+ scripts enable to you to skip most of the individual procedures included in the above activities.

NIS+ and the Service Management Facility

Most of the command line administrative tasks associated with the NIS+ service are managed by the Service Management Facility (SMF). For an overview of SMF, refer to Chapter 18, Managing Services (Overview), in System Administration Guide: Basic Administration. Also refer to the svcadm(1M) and svcs(1) man pages for more details.

• Administrative actions on the NIS+ service, such as enabling, disabling, or restarting, can be performed using the svcadm command. When the service is started or stopped, any dependent processes are also started or stopped.

  ---

  Tip –

  Temporarily disabling a service by using the -t option provides some protection for the service configuration. If the service is disabled with the -t option, the original settings would be restored for the service after a reboot. If the service is disabled without -t, the service will remain disabled after reboot.

  ---

• SMF automatically starts nis_cachemgr when it enables the NIS+ service, if it detects the /var/nis/NIS_COLD_START file.

• The NIS+ Fault Managed Resource Identifier (FMRI) is svc:/network/rpc/nisplus:<instance>.

• The FMRI for keyserv is svc:/network/rpc/keyserv:<instance>.

• You can query the status of NIS+ by using the svcs command.

  • Example of svcs command and output.

    # svcs \*nisplus\* STATE STIME FMRI disabled Sep_01 svc:/network/rpc/nisplus:default

  • Example of svcs -l command and output.

    # svcs -l network/rpc/nisplus fmri svc:/network/rpc/nisplus:default enabled false state disabled next_state none restarter svc:/system/svc/restarter:default dependency require_all/none svc:/network/rpc/keyserv (online)

    You can also use the svccfg utility to get more detailed information about a service. See the svccfg(1M) man page.

• You can check a daemon's presence by using the ps command.

  # ps -e | grep rpc.nisd

  ---

  Note –

  Do not use the -f option with ps because this option attempts to translate user IDs to names, which causes more naming service lookups that might not succeed.

  ---

Using svcadm With rpc.nisd -x

In general, the /usr/sbin/rpc.nisd daemon is administered using the svcadm command. However, when rpc.nisd is invoked with -x nisplusLDAPinitialUpdateOnly=yes, rpc.nisd performs the specified action, then exits. That is, rpc.nisd does not daemonize. SMF should not be used in conjunction with -x nisplusLDAPinitialUpdateOnly=yes. SMF can be used any other time you want to start, stop, or restart the rpc.nisd daemon.

The following example shows rpc.nisd used with -x nisplusLDAPinitialUpdateOnly=yes.

# /usr/sbin/rpc.nisd -m mappingfile \
-x nisplusLDAPinitialUpdateAction=from_ldap \
-x nisplusLDAPinitialUpdateOnly=yes

Modifying the /lib/svc/method/nisplus File

If you want to include specific options when you invoke the rpc.nisd daemon with SMF, add the options to the /lib/svc/method/nisplus file. The following list provides some commonly used options.

-S 0

Sets the server's security level to 0, which is required at this point for bootstrapping.

Because no cred table exists yet, no NIS+ principals can have credentials. If you use a higher security level, you are locked out of the server.

-B

Supports DNS forwarding

-Y

Starts the NIS+ daemon in NIS-compatibility mode

How to Modify the /lib/svc/method/nisplus File

1. Become superuser or assume an equivalent role.

   Roles contain authorizations and privileged commands. For more information about roles, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services.

2. Stop the NIS+ service.

   # svcadm disable network/rpc/nisplus:default

3. Open the /lib/svc/method/nisplus file.

   Use your preferred text editor.

4. Edit the file to add the desired options.

   Example –

   Change:

   /usr/sbin/rpc.nisd $nisd_flags || exit $?

   To:

   /usr/sbin/rpc.nisd $nisd_flags -Y -B || exit $?

   In this example, the -Y and -B options are added to rpc.nisd, so the options are automatically implemented at startup.

5. Save and quit.

6. Start the NIS+ service.

   # svcadm enable network/rpc/nisplus:default

Creating a Sample NIS+ Namespace

The procedures in this chapter show you how to create a sample NIS+ namespace. The sample NIS+ namespace will be created from /etc files and NIS maps. This sample shows you how to use the scripts both when your site is not running NIS and when NIS is running at your site. You can set your servers to NIS-compatibility mode if they will be serving NIS clients. See Solaris 1 Release and NIS-Compatibility Mode for more information on NIS-compatibility mode.

Your site's actual NIS+ namespace and its domain hierarchy probably differs from the sample namespace's, and yours probably contains a different number of servers, clients, and domains. Do not expect any resemblance between your final domain configuration or hierarchy and the sample one. The sample namespace is only an illustration of how to use the NIS+ scripts. After you have created this sample namespace, you should have a clear idea about how to create domains, servers, and clients at your site.

The sample namespace contains the following components:

• A root master server named master for the doc.com. domain

• Four clients of the root domain, doc.com.:

  • The first client, client1, will become a root replica (for the doc.com. domain).

  • The second client, client2, will become a master server for a new subdomain (for the sub.doc.com. domain).

  • The third client, client3, will become a non-root replica server of the new subdomain (for the sub.doc.com.) domain.

  • The fourth client, client4, will remain solely a client of the root domain (doc.com.).

• Two clients, subclient1 and subclient2, of the subdomain (sub.doc.com.).

This scenario shows the scripts being used to configure NIS+ at a site that uses both system information files, such as /etc/hosts, and NIS maps to store network service information. The sample NIS+ namespace uses such a mixed site purely for example purposes.

Summary of NIS+ Scripts Command Lines

Table 4–2 contains the generic sequence of NIS+ scripts and commands you will use to create a ample NIS+ domain. Subsequent sections describe these command lines in detail. After you are familiar with the tasks required to create NIS+ domains, servers, and clients, use Table 4–2 as a quick-reference guide to the appropriate command lines. Table 4–2 is a summary of the actual commands with the appropriate variables that you type to create the sample NIS+ namespace.

To see what commands an NIS+ script calls, without actually executing the commands, use the -x option. The -x option causes the command names and their approximate output to echo to the screen as if you were actually running the script. Running the scripts for the first time with -x can minimize unexpected results. For more information, see the man pages for the scripts.

Setting Up NIS+ Root Servers

Setting up the root master server is the first activity towards establishing NIS+ domain. This section shows you how to configure a root master server using the nisserver script with default settings.

The root master server uses the following defaults:

• Security level 2 (DES) – the highest level of NIS+ security

• NIS compatibility set to OFF (instructions for setting NIS compatibility are included)

• System information files (/etc) or NIS maps as the source of name services information

• admin.domainname as the NIS+ group

The nisserver script modifies the name service switch file for NIS+ when it sets up a root master server. The /etc/nsswitch.conf file can be changed later. See Chapter 1, Name Service Switch for information on the name service switch.

Prerequisites to Running nisserver to Set Up a Root Server

Check to see that the /etc/passwd file on the machine you want to be root master server contains an entry for root.

You need the following information before running nisserver.

• The superuser password of the machine that will become the root master server

• The name of the new root domain. The root domain name must have at least two elements (labels) and end in a dot (for example, something.com.). The last element may be anything you want, but in order to maintain Internet compatibility, the last element must be either an Internet organizational name (as shown in Table 4–3), or a two or three character geographic identifier such as .jp. for Japan.

In the following example, the machine that is designated as the root master server is called master1, and doc.com. becomes the new root domain.

Domains and hosts should not have the same name. For example, if you have doc.com. as a root domain, you should not have a machine named doc in any of your domains. Similarly, if you have a machine named home, you do not want to create a domain named home. This caution also applies to subdomains. For example, if you have a machine named west, you do not want to create a sales.west.doc.com subdomain.

How to Create an NIS+ Root Master Server

1. Set the superuser's PATH variable to include /usr/lib/nis.

   Either add this path to root's .cshrc or .profile file or set the variable directly.

2. Optionally, if using DES authentication, specify the Diffie-Hellman key length.

   To use 640–bit Diffie-Hellman keys as well as the default 192–bit keys, type:

   nisauthconf dh640-0 des

   To allow only 640–bit keys (rejects 192–bit keys), type:

   nisauthconf dh640-0

3. Type the following command as superuser (root) to configure a root master server.

   The -r option indicates that a root master server should be configure. The -d option specifies the NIS+ domain name.

   master1# nisserver -r -d doc.com. This script sets up this machine “master1” as an NIS+ root master server for domain doc.com. Domain name : doc.com. NIS+ group : admin.doc.com. NIS (YP) compatibility : OFF Security level : 2=DES Is this information correct? (type 'y' to accept, 'n' to change)

   “NIS+ group” refers to the group of users who are authorized to modify the information in the doc.com. domain. (Domain names always end with a period.) Modification includes deletion. admin.domainname is the default name of the group. See How to Change Incorrect Information When Setting Up NIS+ for instructions on how to change this name.

   “NIS compatibility” refers to whether an NIS+ server accepts information requests from NIS clients. When set to OFF, the default setting, the NIS+ server does not fulfill requests from NIS clients. When set to ON, an NIS+ server fulfills such requests. You can change the NIS-compatibility setting with this script. See How to Change Incorrect Information When Setting Up NIS+.

   ---

   Note –

   This script sets machines up only at security level 2, the highest level of NIS+ security. You cannot change the security level when using this script. After the script has completed, you can change the security level with the appropriate NIS+ command. See the rpc.nisd man page for more information on changing security levels.

   ---

4. Type y (if the information shown on the screen is correct).

   Typing n causes the script to prompt you for the correct information. (See How to Change Incorrect Information When Setting Up NIS+ for what you need to do if you type n.)

   Is this information correct? (type 'y' to accept, 'n'' to change) y This script will set up your machine as a root master server for domain doc.com. without NIS compatibility at security level 2. Use "nisclient -r" to restore your current network service environment. Do you want to continue? (type `y' to continue, `n' to exit the script)

5. Type y to continue NIS+ configuration.

   (Typing n safely stops the script.) If you interrupt the script after you have chosen y and while the script is running, the script stops running and leaves configured whatever it has created so far. The script does not do any automatic recovery or cleaning up. You can always rerun this script.

   Do you want to continue? (type 'y' to continue, 'n' to exit the script y setting up domain information “doc.com.” ... setting up switch information ... running nisinit ... This machine is in the doc.com. NIS+ domain. Setting up root server ... All done. starting root server at security level 0 to create credentials... running nissetup ... (creating standard directories & tables) org_dir.doc.com. created Enter login password:

   The nissetup command creates the directories for each NIS+ table.

6. Type your machine's root password at the prompt and press Return.

   In this case, the user typed the master1 machine's root password.

   Wrote secret key into /etc/.rootkey setting NIS+ group to admin.doc.com. ... restarting root server at security level 2 ... This system is now configured as a root server for domain doc.com. You can now populate the standard NIS+ tables by using the nispopulate or /usr/lib/nis/nisaddent commands.

   Your root master server is now configured and ready for you to populate the NIS+ standard tables. To continue with populating tables, skip to Populating NIS+ Tables.

How to Change Incorrect Information When Setting Up NIS+

If you typed n because some or all of the information returned to you was wrong in Step 4 in the above procedure, you will see the following:

Is this information correct? (type 'y' to accept, 'n' to change)
 n
Domain name: [doc.com.]

1. Press Return if the domain name is correct; otherwise, type the correct domain name and press Return.

   In this example, Return was pressed, confirming that doc.com. is the desired domain name. The script then prompts for the NIS+ group name.

   Is this information correct? (type 'y' to accept, 'n' to change) n Domain name: [doc.com.] NIS+ group: [admin.doc.com.]

2. Press Return if NIS+ group is correct; otherwise, type the correct NIS+ group name and press Return.

   In this example, the name was changed. The script then prompts for NIS compatibility.

   NIS+ group: [admin.doc.com.] netadmin.doc.com. NIS (YP) compatibility (0=off, 1=on): [0]

3. Press Return if you do not want NIS compatibility; otherwise, type 1 and press Return.

   In this example, Return was pressed, confirming that NIS compatibility status is correct. Once again, the script asks you if the information is correct.

   ---

   Note –

   If you choose to make this server NIS compatible, you also need to edit a file and restart the rpc.nisd daemon before it will work. See Configuring a Client as an NIS+ Server for more information.

   ---

   NIS (YP) compatibility (0=off, 1=on): [0] Domain name : doc.com. NIS+ group : netadmin.doc.com. NIS (YP) compatibility : OFF Security level : 2=DES Is this information correct? (type 'y' to accept, 'n' to change)

   When the information is correct, continue with Step 3 in How to Create an NIS+ Root Master Server. You can keep choosing -n until the information is correct.

How to Set Up a Multihomed NIS+ Root Master Server

The procedure for setting up a multihomed NIS+ server is the same as setting up a single interface server. The only difference is that there are more interfaces that need to be defined in the hosts database, the /etc/hosts file and NIS+ hosts table.

Prior to the Solaris 10 7/07 release, you also need to define interfaces in the /etc/inet/ipnodes file and ipnodes table.

Once the host information is defined, use the nisclient and nisserver scripts to set up the multihomed NIS+ server. For information about setting up a multihomed replica server, see How to Set Up Multihomed NIS+ Replica Servers.

When setting up a multihomed NIS+ server, the server's primary name must be the same as the nodename for the system. This is a requirement of both Secured RPC and nisclient.

• Secured RPC relies on the nodename to create the netname for authentication.

• nisclient relies on the primary name to create the credential for the client.

If these names are different, Secure RPC authentication will fail to work properly causing NIS+ problems.

The following procedure shows how to set up an NIS+ root master server:

1. On the root master, add the server host information into the /etc/hosts file.

   ---

   Note –

   Prior to the Solaris 10 7/07 release, you must also add IPv6 host information to the /etc/inet/ipnodes file.

   ---

   For example, the /etc/hosts file for the hostA system with three Ethernet interfaces looks like:

   127.0.0.1 localhost loghost 192.168.10.x hostA hostA-10 hostA-eri0 192.168.11.y hostA hostA-11 hostA-eri1 192.168.12.z hostA hostA-12

2. Set up the server as a multihome NIS+ root server with nisserver.

   hostA# nisserver -r -d sun.com

   where our example shows sun.com as the root domain name. Issue the nisserver command using the name of your root domain name.

   After completing the steps for setting up a multihome NIS+ root server, the remainder of the setup is exactly the same as for a single interface server.

Populating NIS+ Tables

After the root master server has been configured, you can populate its standard NIS+ tables with name services information. This section shows you how to populate the root master server's tables with data from files or NIS maps using the nispopulate script with default settings.

The script uses:

• The domain created in the previous example (doc.com.)

• System information files or NIS maps as the source of name services

• The standard NIS+ tables: auto_master, auto_home, ethers, group, hosts, networks, passwd, protocols, services, rpc, netmasks, bootparams, netgroup, and aliases

The shadow file's contents are merged with the passwd file's to create the passwd table when files are the tables' information source. No shadow table is created.

Prerequisites to Running nispopulate to Populate Root Server Tables

Before you run the nispopulate script, be sure the following prerequisites have been met.

• View each local /etc file or NIS map from which you will load data. Make sure there are no spurious or incorrect entries. Make sure that the right data is in the correct place and format. Remove any outdated, invalid, or corrupt entries. You should also remove any incomplete or partial entries. You can always add individual entries after configuration is completed. That is easier than trying to load incomplete or damaged entries.

• The information in the files must be formatted appropriately for the table into which it will be loaded. Chapter 9, Setting Up NIS+ Tables describes the format required for a text file to be transferred into its corresponding NIS+ table.

• Make sure that domain and host names are different. Domains and hosts cannot have the same name. For example, if you have a sales domain you cannot have a machine named sales. Similarly, if you have a machine named home, do not create a domain named home. This caution also applies to subdomains. For example, if you have a machine named west, do not create a sales.west.doc.com subdomain.

• Remove all dots and underscores in host names. NIS+ uses dots (periods) to delimit between machine names and domains and between parent and subdomains, so you cannot have a machine name containing a dot. You also cannot use underscores in hostnames, since DNS does not allow it. Before running the nispopulate script, you must eliminate any dots in your host names. You can convert host name dots to hyphens. For example, you cannot have a machine named sales.alpha. You can convert that name to sales-alpha.

• If you are setting up a network for the first time, you may not have much network information stored anywhere. In that case, you first need to collect the information, then type it into the input file, which is essentially the same as an /etc file.

• For safety's sake, you should make copies of the /etc files and use the copies to populate the tables instead of the actual files. (This example uses files in a directory called /nisplusfiles, for instance.)

• Edit four of the copied NIS table files, passwd, shadow, aliases, and hosts, for security problems, particularly items that you do not want distributed across the namespace. For example, you might want to remove the following lines from the copy of your local passwd file so that they are not made available across the namespace:

  root:x:0:1:0000-Admin(0000):/:/sbin/sh daemon:x:1:3:0000-Admin(0000):/: bin:x:3:5:0000-Admin(0000):/usr/bin: sys:x:3:3:0000-Admin(0000):/: adm:x:4:4:0000-Admin(0000):/var/adm: lp:x:78:9:0000-lp(0000):/usr/spool/lp: smtp:x:0:0:mail daemon user:/: uucp:x:5:5:0000-uucp(0000):/usr/lib/uucp: nuucp:x:7:8:0000-uucp (0000):/var/spool/uucppublic:/usr/lib/uucp/uucico listen:x:22:6:Network Admin:/usr/net/nls nobody:x:60000:60000:uid no body:/: noaccess:x:60002:60002:uid no access:/:

• The domain must have already been configured and its master server must be running.

• The domain's server must have sufficient disk space to accommodate the new table information.

• You must be logged in as an NIS+ principal (a client with appropriate credentials) and have write permission to the NIS+ tables in the specified domain. In this example, you must be the user root on the machine master1.

How to Populate the NIS+ Root Master Server Tables

Before You Begin

The NIS domain name is case-sensitive, while the NIS+ domain name is not.

If populating from files, you need the following information.

• The new NIS+ domain name

• The path of the appropriately edited text files whose data will be transferred

• Your root password

If populating from NIS maps, you need:

• The new NIS+ domain name

• The NIS domain name

• The NIS server's name

• The IP address of the NIS server

• Your root password

1. Perform either substep a or b to populate the root master server tables, then continue with Step 2.

   Substep a shows you how to populate tables from files. Substep b shows you how to populate tables from NIS maps. Type these commands in a scrolling window; otherwise, the script's output might scroll off the screen.

   ---

   Note –

   The nispopulate script can fail if there is insufficient /tmp space on the system. To keep this from happening, you can set the environment variable TMPDIR to a different directory. If TMPDIR is not set to a valid directory, the script uses the /tmp directory.

   ---

   1. Type the following command to populate the tables from files.

      master1# nispopulate -F -p /nis+files -d doc.com. NIS+ domain name : doc.com. Directory Path : /nis+files Is this information correct? (type 'y' to accept, 'n' to change)

      The -F option indicates that the tables take their data from files. The -p option specifies the directory search path for the source files. (In this case, the path is /nis+files.) The -d option specifies the NIS+ domain name. (In this case, the domain name is doc.com.)

      The NIS+ principal user is root. You must perform this task as superuser in this instance because this is the first time that you are going to populate the root master server's tables. The nispopulate script adds credentials for all members of the NIS+ admin group.

   2. Type the following command to populate the tables from NIS maps.

      master1# nispopulate -Y -d doc.com. -h salesmaster -a 130.48.58.111 -y sales.doc.com. NIS+ domain name : doc.com. NIS (YP) domain : sales.doc.com. NIS (YP) server hostname : salesmaster Is this information correct? (type 'y' to accept, 'n' to change)

      The -Y option indicates that the tables take their data from NIS maps. The -d option specifies the NIS+ domain name. The -h option specifies the NIS server's machine name. (In this case, the NIS server's name is salesmaster. You have to insert the name of a real NIS server at your site to create the sample domain.) The -a option specifies the NIS server's IP address. (In this case, the address is 130.48.58.111. You have to insert the IP address of a real NIS server at your site to create the sample domain.) The -y option specifies the NIS domain name. (In this case, the domain's name is sales.doc.com.; you have to insert the NIS domain name of the real NIS domain at your site to create the sample domain.)

      The NIS+ principal user is root. You must perform this task as superuser in this instance because this is the first time that you are going to populate the root master server's tables. The nispopulate script also adds credentials for all members of the NIS+ admin group.

2. Type y (if the information returned on the screen is correct).

   Typing n causes the script to prompt you for the correct information. (See How to Change Incorrect Information When Setting Up NIS+ for what you need to do if the information is incorrect.)

   • If you performed substep a of Step a, you will see the following:

     Is this information correct? (type 'y' to accept, 'n' to change) y This script will populate the following NIS+ tables for domain doc.com. from the files in /nis+files: auto_master auto_home ethers group hosts networks passwd protocols services rpc netmasks bootparams netgroup aliases shadow **WARNING: Interrupting this script after choosing to continue may leave the tables only partially populated. This script does not do any automatic recovery or cleanup. Do you want to continue? (type 'y' to continue, 'n' to exit this script)

   • If you performed substep b of Step b, you will see the following:

     Is this information correct? (type 'y' to accept, 'n' to change) y This script will populate the following NIS+ tables for domain doc.com. from the NIS (YP) maps in domain sales: auto_master auto_home ethers group hosts networks passwd protocols services rpc netmasks bootparams netgroup aliases **WARNING: Interrupting this script after choosing to continue may leave the tables only partially populated. This script does not do any automatic recovery or cleanup. Do you want to continue? (type 'y' to continue, 'n' to exit this script)

3. Type y to continue populating the tables.

   By typing n, you can safely stop the script. If you interrupt the script after you have chosen y, while the script's running, the script stops running and can leave the tables only partially populated. The script does not do any automatic recovery or cleaning up.

   When you rerun the script, the tables are overwritten with the latest information.

   • If you are populating tables from files, you see messages like the following as the script uses hosts and passwd information to create the credentials for hosts and users:

     Do you want to continue? (type 'y' to continue, 'n' to exit this script) y populating auto_master table from file /nis+files/auto_master ... auto_master table done. populating auto_home table from file /nis+files/auto_home ... auto_home table done. Credentials have been added for the entries in the hosts and passwd table(s). Each entry was given a default network password (also known as a Secure- RPC password). This password is: nisplus Use this password when the nisclient script requests the network password. Done!

     Note and remember the Secure RPC password (nisplus, in the above example). Use this password when prompted for your network or Secure RPC password.

     The script continues until it has searched for all the files it expects and loads all the tables it can from the available files.

   • If you are populating tables from NIS maps, you will see messages like the following as the script uses hosts and passwd information to create the credentials for hosts and users:

     Do you want to continue? (type 'y' to continue, 'n' to exit this script) y populating auto_master table from sales.doc.com. NIS(YP) domain... auto_master table done. populating auto_home table from file sales.doc.com. NIS(YP) domain... auto_home table done. .... Credentials have been added for the entries in the hosts and passwd table(s). Each entry was given a default network password (also known as a Secure-RPC password). This password is: nisplus Use this password when the nisclient script requests the network password. Done!

     Note and remember the Secure RPC password (nisplus, in the above example). Use this password when prompted for your network or Secure RPC password.

     All the tables are now populated. You can ignore any parse error warnings. Such errors indicate that NIS+ found empty or unexpected values in a field of a particular NIS map. You may want to verify the data later after the script completes.

4. (Optional) Add yourself and others to the root domain's admin group.

   For example, if your login ID is topadm and your co-worker's ID is secondadmin, you enter:

   master1# nisgrpadm -a admin.doc.com. topadm.doc.com. secondadm.doc.com. Added “topadm.doc.com.” to group “admin.doc.com.”. Added “secondadm.doc.com.” to group “admin.doc.com.”.

   The admin.doc.com. argument in the nisgrpadm -a command above is the group name, which must come first. The remaining two arguments are the names of the administrators.

   ---

   Note –

   This step is necessary only if you want to add additional users to the admin group now, which is a good time to add administrators to the root server. You can also add users to the admin group after you have configured NIS+.

   ---

   You do not have to wait for the other administrators to change their default passwords to perform this step; however, they must already be listed in the passwd table before you can add them to the admin group. Members of the admin group will be unable to act as NIS+ principals until they add themselves to the domain. See How to Initialize an NIS+ User for more information on initializing users. The group cache also has to expire before the new members become active.

5. Type the following command to checkpoint the domain.

   master1# nisping -C doc.com. Checkpointing replicas serving directory doc.com. Master server is master1.doc.com. Last update occurred at date Master server is master1.doc.com. checkpoint scheduled on master1.doc.com.

   This step ensures that all the servers supporting the domain transfer the new information from their initialization (.log) files to the disk-based copies of the tables. Since you have just configured the root domain, this step affects only the root master server, as the root domain does not yet have replicas.

   ---

   Caution –

   If you do not have enough swap or disk space, the server will be unable to checkpoint properly, but it will not notify you. One way to make sure everything is correct is to list the contents of a table with the niscat command. For example, to check the contents of the rpc table, type:

   master1# niscat rpc.org_dir rpcbind rpcbind 100000 rpcbind portmap 100000 rpcbind sunrpc 100000

   If you do not have enough swap space, you will see the following error message instead of the sort of output you see above.

   can't list table: Server busy, Try Again.

   Even though it does not say so, in this context this message indicates that you do not have enough swap space. Increase the swap space and checkpoint the domain again.

   ---

Setting Up NIS+ Client Machines

After the root master server's tables have been populated from files or NIS maps, you can initialize NIS+ client machines. (Because the root master server is an NIS+ client of its own domain, no further steps are required to initialize it.) This section shows you how to initialize an NIS+ client by using the nisclient script with default settings.

The script uses:

• The domain used in previous examples, doc.com.

• The Secure RPC password (also known as the network password) created by the nispopulate script in the previous example (nisplus, the default password)

The -i option used in How to Initialize a New NIS+ Client Machine does not configure an NIS+ client to resolve host names requiring DNS. You need to explicitly include DNS for clients in their name service switch files.

How to Initialize a New NIS+ Client Machine

Before You Begin

Before you use the nisclient script, be sure the following prerequisites have been met.

• The domain must have already been configured and its master server must be running.

• The master server of the domain's tables must be populated. (At a minimum, the hosts or, if you are running a system prior to the Solaris 10 7/07 release, the ipnodes table must have an entry for the new client machine.)

• You must be logged in as superuser on the machine that is to become an NIS+ client. In this example, the new client machine is named client1.

You need the following information to run nisclient.

• The domain name.

• The default Secure RPC password (nisplus).

• The root password of the machine that will become the client.

• The IP address of the NIS+ server (in the client's home domain).

• If DES authentication is used, note the Diffie-Hellman key length used on the master server. Use nisauthconf to ascertain the master server Diffie-Hellman key length.

1. Optionally, if using DES authentication, specify the Diffie-Hellman key length.

   On the master server, type

   nisauthconf

   Use the output as the arguments when running the nisauthconf command on the client. For example, if nisauthconf on the master server produces

   dh640dh-0 des

   type the following command on the client machine

   nisauthconf dh640dh-0 des

2. Type the following command to initialize the new client on the new client machine.

   The -i option initializes a client. The -d option specifies the new NIS+ domain name. (If the domain name is not specified, the default is the current domain name.) The -h option specifies the NIS+ server's host name.

   client1# nisclient -i -d doc.com. -h master1 Initializing client client1 for domain “doc.com.”. Once initialization is done, you will need to reboot your machine. Do you want to continue? (type 'y' to continue, 'n' to exit this script)

3. Type y.

   Typing n exits the script. The script prompts you only for the root server's IP address if there is no entry for it in the client's /etc/hosts or, prior to the Solaris 10 7/07 release, in the client's /etc/inet/ipnodes file.

   Do you want to continue? (type 'y' to continue, 'n' to exit this script) y Type server master1's IP address:

4. Type the correct IP address, and press Return.

   This example uses the hypothetical address 123.123.123.123.

   Type server master1's IP address: 123.123.123.123 setting up the domain information... setting up the name service switch information... At the prompt below, type the network password (also known as the Secure-RPC password) that you obtained either from your administrator or from running the nispopulate script. Please enter the Secure-RPC password for root:

5. Type the Secure RPC password (also known as the network password) only if the Secure RPC password differs from the root login password.

   In this case, use the default, nisplus.

   The password does not echo on the screen. If you mistype it, you are prompted for the correct one. If you mistype it twice, the script exits and restores your previous network service. If this happens, try running the script again.

   Please enter the login password for root:

6. Type the root password for this client machine.

   The password does not echo on the screen. (If the Secure RPC password and the root login password happen to be the same, you will not be prompted for the root login password.)

   Typing the root password changes the credentials for this machine. The RPC password and the root password are now the same for this machine.

   Please enter the login password for root: Wrote secret key into /etc/.rootkey Your network password has been changed to your login one. Your network and login passwords are now the same. Client initialization completed!! Please reboot your machine for changes to take effect.

7. Reboot your new client machine.

   Your changes do not take effect until you reboot the machine.

   You can now have the users of this NIS+ client machine add themselves to the NIS+ domain.

Creating Additional NIS+ Client Machines

Repeat the preceding client-initiation procedure on as many machines as you like. To initiate clients for another domain, repeat the procedure but change the domain and master server names appropriately.

The sample NIS+ domain described in this chapter assumes that you will initialize four clients in the doc.com. domain. You are then going to configure two of the clients as non-root NIS+ servers and a third client as a root replica of the root master server of the doc.com. domain.

You always have to make a system into a client of the parent domain before you can make the same system a server of any type.

Initializing NIS+ Client Users

After a machine has become an NIS+ client, the users of that machine must add themselves to the NIS+ domain. Adding a user to the domain means changing the Secure RPC password to that user's login password. What actually happens is that the user's password and the Secure RPC password are bound together. This procedure uses the nisclient script.

How to Initialize an NIS+ User

Before You Begin

Before you use the nisclient script to initialize a user, be sure the following prerequisites have been met.

• The domain must have already been configured and its master server must be running.

• The master server of the domain's tables must be populated. (At a minimum, the hosts table must have an entry for the new client machine.)

• You must have initialized a client machine in the domain.

• You must be logged in as a user on the client machine. In this example, the user is named user1.

• Optionally, if using DES authentication, the client machine must use the same Diffie-Hellman key configuration as that used on the master server.

You need the following information to run nisclient.

• A user's login name (user1 in this example)

• The default Secure RPC password (nisplus in this example)

• The login password of the user who will become the NIS+ client

1. To become an NIS+ client, enter the following nisclient command while logged in as the user.

   user1prompt% nisclient -u At the prompt below, type the network password (also known as the Secure-RPC password) that you obtained either from your administrator or from running the nispopulate script. Please enter the Secure-RPC password for user1:

2. Enter the Secure RPC password, which is nisplus in this case.

   The password does not echo on the screen.

   Please enter the login password for user1:

3. Type the user's login password and press Return.

   The password does not echo on the screen.

   Your network password has been changed to your login one. Your network and login passwords are now the same

   This user is now an NIS+ client. You need to have all users make themselves NIS+ clients.

Setting Up NIS+ Servers

Now that the client machines have been initialized, you can change any of them to NIS+ servers of the following types:

• To be root replicas – to contain copies of the NIS+ tables that reside on the root master server

• To be master servers of subdomains of the root domain

• To be replicas of master servers of subdomains of the root domain

You can have only one NIS+ master root server. Root NIS+ servers are a special type of NIS+ server. This section does not describe how to configure a root master server; see Setting Up NIS+ Root Servers for more information.

You can configure servers any of these different ways:

• Without NIS compatibility

• With NIS compatibility

• With NIS compatibility and DNS forwarding – you only need to set DNS forwarding if you are going to have SunOS 4 clients in your NIS+ namespace

Servers and their replicas should have the same NIS-compatibility settings. If they do not have the same settings, a client that needs NIS compatibility set to receive network information may not be able to receive it if either the server or replica it needs is unavailable.

Configuring a Client as an NIS+ Server

Perform any of the following to alternate procedures to configure a client as a server. These procedures create a directory with the same name as the server and create the server's initialization files which are placed in /var/nis.

All servers in the same domain must have the same NIS-compatibility setting. For example, if the master server is NIS compatible, then its replicas should also be NIS compatible.

How to Configure an NIS+ Server Without NIS Compatibility

Before You Begin

You need to be superuser or establish an equivalent role to perform this procedure.

You need the superuser password of the client that you will convert into a server before you can start the NIS+ service by using the svcadm command.

• Before you start the NIS+ service from the command line by using svcadm, be sure the following prerequisites have been met.

• The domain must have already been configured and its master server must be running.

• The master server of the domain's tables must be populated. (At a minimum, the hosts table must have an entry for the new client machine.)

• You must have initialized the client machine in the domain.

• You must be logged in as root on the client machine. In this example, the client machine is named client1.

• Optionally, if using DES authentication, the client machine must use the same Diffie-Hellman key configuration as that used on the master server.

1. View the /lib/svc/method/nisplus file to verify that the -Y option does not appear.

   See NIS+ and the Service Management Facility for more information.

2. Start the NIS+ service.

   You need to be superuser or establish an equivalent role to perform this step.

   client1# svcadm enable /network/rpc/nisplus:default

   Now this server is ready to be designated a master or replica of a domain.

How to Configure an NIS+ Server With NIS Compatibility

You need to be superuser or establish an equivalent role to perform this procedure.

1. Edit the /lib/svc/method/nisplus file on the server to add the -Y option.

   See NIS+ and the Service Management Facility for more information.

2. Start the NIS+ service.

   You need to be superuser or establish an equivalent role to perform this step.

   client1# svcadm enable /network/rpc/nisplus

   Now this server is ready to be designated a master or replica of a domain.

How to Configure an NIS+ Server With DNS Forwarding and NIS Compatibility

This procedure configures an NIS+ server with both DNS forwarding and NIS compatibility. Both of these features are needed to support SunOS 4 clients.

You need to be superuser or establish an equivalent role to perform this procedure.

1. Edit the /lib/svc/method/nisplus file on the server to add the -Y and -B options.

   See NIS+ and the Service Management Facility for more information.

2. Start the NIS+ service.

   You need to be superuse,r or establish an equivalent role, to perform this step.

   client1# svcadm enable /network/rpc/nisplus:default

Creating Additional NIS+ Servers

Repeat the preceding client-to-server conversion procedure on as many client machines as you like.

The sample NIS+ domain described in this chapter assumes that you will convert three clients to servers. You will then configure one of the servers as a root replica, another as a master of a new subdomain, and the third as a replica of the master of the new subdomain.

Creating an NIS+ Root Replica Server

To have regularly available NIS+ service, you should always create one or more root replica servers. Having replicas can also speed network-request resolution because multiple servers are available to handle requests.

For performance reasons, you should have no more than a few replicas per domain.

If your network includes multiple subnets or different sites connected by a Wide Area Network (WAN), you may need additional replicas:

• Subnets. If you have a domain that spans multiple subnets, it is a good idea to have at least one replica server within each subnet so that if the connection between nets is temporarily out of service, each subnet can continue to function until the connection is restored.

• Remote sites. If you have a domain spanning multiple sites linked over a WAN, it is a good idea to have at least one replica server on each side of the WAN link. For example, it may make sense from an organizational point of view to have two physically distant sites in the same NIS+ domain. If the domain's master server and all of its replicas are at the first site, there will be much NIS+ network traffic between the first and second sites. Creating an additional replica at the second site should reduce network traffic.

See Creating an NIS+ Root Replica Server for additional information on how to determine the optimum number of replicas.

How to Create an NIS+ Root Replica shows the machine client1 being configured as a root replica for the doc.com. domain. This procedure uses the NIS+ nisserver script. (You can also use the NIS+ command set to configure a replica server as described in Using NIS+ Commands to Configure a Replica Server.)

How to Create an NIS+ Root Replica

Before You Begin

You need the following information to run nisserver.

• The domain name

• The client machine name; (client1, in this example)

• The superuser password for the root master server

Before you run nisserver to create a replica, be sure the following prerequisites have been met.

• The domain must already have been configured and its master server must be running.

• The tables of the master server must be populated. (At a minimum, the hosts table must have an entry for the new client machine.)

• You must have initialized the new server as a client machine in the domain, as described in Setting Up NIS+ Client Machines.

• You must have started the NIS+ service, rpc.nisd, on the new replica server, as described in Setting Up NIS+ Servers.

• You must be logged in as root on the root master server. In this example, the root master machine is named master1.

1. To create a root replica, type the following command as superuser (root) on the NIS+ domain's root master server.

   master1# nisserver -R -d doc.com. -h client1 This script sets up an NIS+ replica server for domain doc.com. Domain name: :doc.com. NIS+ server : :client1 Is this information correct? (type 'y' to accept, 'n' to change)

   The -R option indicates that a replica should be configured. The -d option specifies the NIS+ domain name (doc.com., in this example). The -h option specifies the client machine (client1, in this example) that will become the root replica.

2. Type y to continue.

   Typing n causes the script to prompt you for the correct information. (See How to Change Incorrect Information When Setting Up NIS+ for what you need to do if you type n.)

   Is this information correct? (type 'y' to accept, 'n' to change) y This script will set up machine “client1” as an NIS+ replica server for domain doc.com. without NIS compatibility. The NIS+ server daemon, rpc.nisd, must be running on client1 with the proper options to serve this domain. Do you want to continue? (type 'y' to continue, 'n' to exit this script)

3. Type y to continue.

   Typing n safely stops the script. The script will exit on its own if rpc.nisd is not running on the client machine.

   Is this information correct? (type 'y' to continue, 'n' to exit this script) y The system client1 is now configured as a replica server for domain doc.com.. The NIS+ server daemon, rpc.nisd, must be running on client1 with the proper options to serve this domain. ...

   ---

   Note –

   If you want to run this replica in NIS (YP) compatibility mode, modify the /lib/svc/method/nisplus file to add the -Y option. The file needs modification only if you want the root replica to fulfill NIS client requests and it was not already configured as an NIS-compatible server. See Configuring a Client as an NIS+ Server for more information about creating NIS-compatible servers and NIS+ and the Service Management Facility for more information about using Service Management Facility commands with NIS+.

   ---

4. [Optional] Configure the replica to run in NIS (YP) compatibility mode.

   If you want this replica to run in NIS compatibility mode, follow these steps:

   1. Stop the NIS+ service.

      # svcadm disable /network/rpc/nisplus:<instance>

   2. Edit the server's /lib/svc/method/nisplus file to add the -Y option.

   3. Restart the NIS+ service.

      # svcadm enable /network/rpc/nisplus:<instance>

5. Load your namespace data on to the new replica server.

   You can do this in two ways:

   • The preferred method of loading data on to a new replica server is to use the NIS+ backup and restore capabilities to back up the master server, then “restore” that data on to the new replica server. This step is described in detail in How to Load NIS+ Namespace Data by Using the nisrestore Command.

   • Run nisping. Running nisping initiates a full resynch of all NIS+ data from the master server to this new replica. If your namespace is large, this can take a long time, during which your master server is very busy and slow to respond and your new replica is unable to answer NIS+ requests. This step is described in detail in How to Load NIS+ Namespace Data by Using the nisping Command.

   When you have finished loading your namespace data, the machine client1 is now an NIS+ root replica. The new root replica can handle requests from the clients of the root domain. Because there are now two servers available to the domain, information requests can be fulfilled faster.

   Using these procedures, you can create as many root replicas as you need. You can also use these procedures to create replica servers for subdomains.

How to Set Up Multihomed NIS+ Replica Servers

The procedure for setting up a multihomed NIS+ server is the same as setting up a single interface server. The only difference is that there are more interfaces that need to be defined in the hosts database, the /etc/hosts file and NIS+ hosts table.

Prior to the Solaris 10 7/07 release, you also need to define interfaces in the /etc/inet/ipnodes file and ipnodes table.

Once the host information is defined, use the nisclient and nisserver scripts to set up the multihomed NIS+ server.

When setting up a multihomed NIS+ server, the server's primary name must be the same as the nodename for the system. This is a requirement of both Secured RPC and nisclient.

• Secured RPC relies on the nodename to create the netname for authentication.

• nisclient relies on the primary name to create the credential for the client.

If these names are different, Secure RPC authentication will fail to work properly causing NIS+ problems.

This procedure shows how to set up any NIS+ non-root master servers. The following example creates a replica for the root domain. For information about setting up a multihomed root server, see How to Set Up a Multihomed NIS+ Root Master Server.

1. Add the server host information into the hosts file.

   ---

   Note –

   Prior to the Solaris 10 7/07 release, you must also load IPv6 server host information into the client's ipnodes file.

   ---

   For example, for the hostB system with three interfaces:

   192.168.11.y hostB hostB-11 192.168.12.x hostB hostB-12 192.168.14.z hostB hostB-14

2. On the root master server, use either nispopulate or nisaddent to load the new host information into the hosts file.

   ---

   Note –

   Prior to the Solaris 10 7/07 release, you must also load host IPv6 information into the client's ipnodes table.

   ---

   For example:

   hostA# nispopulate -F -d sun.com hosts

   where the example shows sun.com as the NIS+ root domain name. Issue the nispopulate command specifying the name of your NIS+ root domain name.

3. On the root master server, use the nisclient script to create the credential for the new client.

   For example:

   hostA# nisclient -c -d sun.com hostB

   where the example shows sun.com as the root domain name. Issue the nisclient command specifying the name of your root domain name.

4. On the non-root master server, use nisclient to start the new server if it is not already running and initialize the machine as an NIS+ client.

   For example:

   hostB# nisclient -i -d sun.com

   where the example shows sun.com as the root domain name. Issue the nisclient command specifying the name of your root domain name.

5. On the root master server, use nisserver to create a non-root master.

   For example:

   hostA# nisserver -M -d eng.sun.com -h hostB.sun.com.

   where the example shows eng.sun.com as the NIS+ domain name and hostB.sun.com as the fully-qualified hostname for the NIS+ server. Issue the nisserver command specifying the name of your NIS+ domain and the fully-qualified hostname for the NIS+ server.

6. On the root master server, use nisserver to set up a replica server.

   For example:

   hostA# nisserver -R -d sun.com -h hostB.sun.com.

   where the example shows sun.com as the replica server and hostB.sun.com as the fully-qualified hostname for the NIS+ server. Issue the nisserver command specifying the name of your replica server and NIS+ domain.

   After completing the steps for setting up a multihome NIS+ replica server, the remainder of the setup is exactly the same as for a single interface server.

Creating an NIS+ Subdomain

This section shows you how to create the master server of a new non-root domain. The new domain will be a subdomain of the doc.com. domain. The hierarchical structure of NIS+ allows you to create a domain structure that parallels your organizational structure.

This example shows the machine client2 being converted to the master server of the new sub.doc.com. domain. This procedure uses the NIS+ script nisserver.

In Solaris release 2.6 and earlier, any NIS+ client can be converted to an NIS+ master server as long as it is itself in a domain above the domain it is serving. For example, an NIS+ client in domain sales.doc.com. can serve domains below it in the hierarchy, such as the west.sales.doc.com. or even the alameda.west.sales.doc.com. domains. This client cannot, however, serve the domain doc.com., because doc.com. is above the domain sales.doc.com. in the hierarchy. Root replicas are the only exception to this rule. They are clients of the domain that they serve.

In the Solaris 7 release, the domain name of any non-root NIS+ server can be set to the domain it serves. The non-root server behaves as if it lives in its own domain. This allows you to configure applications on the non-root server to use the information provided by the domain above it in the hierarchy.

The non-root server's credentials must still be in the domain above it in the hierarchy. Configure the non-root servers as described in How to Create a New Non-Root NIS+ Domain. Only after the servers are properly configured, can you change the domainname to that of the domain it serves. See the -k option of nisinit and the -d option of nisserver.

How to Create a New Non-Root NIS+ Domain

Before You Begin

You need the following information to run nisserver to create a master server for a non-root domain.

• The client machine name (client2, in this example)

• The superuser password for the parent master server

• A name for the new non-root domain – the name of the new domain includes the name of the parent domain with this syntax: newdomain.rootdomain

  In How to Create a New Non-Root NIS+ Domain, the new non-root domain is called sub.doc.com.

Before you run the nisserver command to create a master server for a new non-root domain, be sure the following prerequisites have been met.

• The parent domain must already have been configured and its master server must be running.

• The parent domain's tables must be populated. (At a minimum, the hosts table must have an entry for the new client machine.)

• You must have initialized the new client machine in the parent domain.

• You must have started the NIS+ service, rpc.nisd, on the client.

• You must have adequate permissions to add the new domain. In this case, you must be logged in as root on the parent master server. In this example, the parent master machine is named master1.

1. Type the following command as superuser (root) on the NIS+ domain's root master server to create a new non-root domain master server.

   The -M option indicates that a master server for a new non-root domain should be created. The -d option specifies the new domain name, sales.doc.com. in this instance. The -h option specifies the client machine, (client2, in this example), that will become the master server of the new domain.

   master1# nisserver -M -d sales.doc.com. -h client2 This script sets up a non-root NIS+ master server for domain sales.doc.com. Domain name : sales.doc.com. NIS+ server : client2 NIS+ group : admin.sales.doc.com. NIS (YP) compatibility : OFF Security level : 2=DES Is this information correct? (type 'y' to accept, 'n' to change)

   Master servers of new non-root domains are created with the same set of default values as root servers. See How to Create an NIS+ Root Master Server for more information on NIS+ group, NIS compatibility, and security level.

2. Type y to continue.

   Typing n causes the script to prompt you for the correct information. (See How to Change Incorrect Information When Setting Up NIS+ for what you need to do if you type n.)

   Is this information correct? (type 'y' to accept, 'n' to change) y This script sets up machine “client2” as an NIS+ non-root master server for domain sales.doc.com. Do you want to continue? (type 'y' to continue, 'n' to exit this script)

3. Type y to continue.

   Typing n safely exits the script. The script exits on its own if rpc.nisd is not running on the client machine.

   Do you want to continue? (type 'y' to continue, 'n' to exit this script) y running nissetup ... org_dir.sales.doc.com. created groups_dir.sales.doc.com. created ... ... setting NIS+ group admin.sales.doc.com. ... The system client2 is now configured as a non-root server for domain sales.doc.com. You can now populate the standard NIS+ tables by using the nispopulate or /usr/lib/nis/nisaddent commands.

   The machine client2 is now the master server of the sales.doc.com. domain. The sales.doc.com. domain is a subdomain of the doc.com. domain. The machine client2 is simultaneously still a client of the root domain doc.com., and the master server of the sales.doc.com. domain.

   You can now populate the standard NIS+ tables on the new master server of the sales.doc.com. domain.

Creating Additional NIS+ Domains

Repeat the preceding procedure for changing servers to master servers of new non-root domains on as many server machines as you like. Every new master server is a new domain. Plan your domain structure before you start creating an NIS+ namespace. See Structure of the NIS+ Namespace for more information on planning an NIS+ hierarchy.

Populating the New NIS+ Subdomain's Tables

After you have created a new domain, you need to populate its master server's standard NIS+ tables. You use the same procedure to populate the new master server's tables as you used to populate the root master server's tables. The major difference is that the nispopulate script is run on the new master server instead of on the root master server. The domain names and file paths or NIS servers' names may change as well.

This example shows the tables of the new domain, sales.doc.com., being populated.

Prerequisites to Populating a NIS+ Subdomain's Tables

Before you run the nispopulate script to populate the new master server's tables, be sure the following prerequisites have been met.

• The information in the files must be formatted appropriately for the table into which it will be loaded.

  • Before proceeding, view each local /etc file or NIS map that you will be loading data from. Make sure that there are no spurious or incorrect entries. Make sure that the right data is in the correct place and format. Remove any outdated, invalid, or corrupt entries. You should also remove any incomplete or partial entries. You can always add individual entries after configuration is completed. That is easier than trying to load incomplete or damaged entries.

  • If you are setting up a network for the first time, you may not have much network information stored anywhere. In that case, you'll need to first get the information and then enter it manually into the input file, which is essentially the same as an /etc file.

  • Make copies of the /etc files and use the copies to populate the tables instead of the actual ones for safety reasons. (This example uses files in a directory called /nis+files, for instance.)

• Edit four of the copied NIS table files, passwd, shadow, aliases, and hosts, for security reasons. For example, you might want to remove the following lines from the copy of your local passwd file so they are not distributed across the namespace.

  root:x:0:1:0000-Admin(0000):/:/sbin/sh daemon:x:1:3:0000-Admin(0000):/: bin:x:3:5:0000-Admin(0000):/usr/bin: sys:x:3:3:0000-Admin(0000):/: adm:x:4:4:0000-Admin(0000):/var/adm: lp:x:78:9:0000-lp(0000):/usr/spool/lp: smtp:x:0:0:mail daemon user:/: uucp:x:5:5:0000-uucp(0000):/usr/lib/uucp: nuucp:x:7:8:0000- uucp (0000):/var/spool/uucppublic:/usr/lib/uucp/uucico listen:x:22:6:Network Admin:/usr/net/nls: nobody:x:60000:60000:uid no body:/: noaccess:x:60002:60002:uid no access:/:

• The domain must have already been configured and its master server must be running.

• The domain's servers must have sufficient disk space to accommodate the new table information.

• You must be logged in as an NIS+ principal and have write permission to the NIS+ tables in the specified domain. In this example, you would have to be the user root on the machine client2.

The nispopulate script can fail if there is insufficient /tmp space on the system. To keep this from happening, you can set the environment variable TMPDIR to a different directory. If TMPDIR is not set to a valid directory, the script uses the /tmp directory instead.

Populating the NIS+ Master Server Tables

Since this procedure is essentially the same as the procedure shown in How to Populate the NIS+ Root Master Server Tables, this example shows you only what you would type to populate the tables of the new sales.doc.com. domain. For more information about this procedure, see How to Populate the NIS+ Root Master Server Tables.

This script should be run on the new domain's master server, not the root master server.

The alternate methods of populating the master server tables on the new master server are:

• You can populate master server tables from files.

• You can populate master server tables from NIS maps.

The information that you need to gather depends upon whether you are populating from files or from NIS maps.

Whichever method you choose should be executed in a scrolling window as the script's output might otherwise scroll off the screen.

How to Populate the NIS+ Tables From Files

If populating from files, you need the following information.

• The new NIS+ domain name

• The path of the appropriately edited text files whose data will be transferred

• The root password of the NIS+ master server

To populate master server tables from files, type the following commands.

client2# nispopulate -F -p /nis+files -d sales.doc.com.
NIS+ domain name : sales.doc.com.
Directory Path : /nis+files
Is this information correct? (type 'y' to accept, 'n' to change

How to Populate the NIS+ Tables From NIS Maps

If populating from NIS maps, you need the following information.

• The new NIS+ domain name

• The NIS domain name

• The NIS server's name

• The IP address of the NIS server

• The root password of the NIS+ master server

The NIS domain name is case-sensitive, while the NIS+ domain name is not.

To populate master server tables from NIS maps, type the following commands.

client2# nispopulate -Y -d sales.doc.com. -h businessmachine -a 
IP_addr_of_NIS_server -y business.doc.com.
NIS+ Domain name : sales.doc.com.
NIS (YP) domain : business.doc.com.
NIS (YP) server hostname : businessmachine
Is this information correct? (type 'y' to accept, 'n' to change)

See How to Populate the NIS+ Root Master Server Tables for additional information.

Creating NIS+ Subdomain Replicas

The same principles that apply to root domain replicas apply to subdomain replicas (see Creating an NIS+ Root Replica Server).

You use the same procedure to create a subdomain replica as you do to create a root replica. The major difference between creating the root replica and a subdomain replica is that the machine you are going to convert to a subdomain replica remains a client of the domain above the one it serves as a replica. This example shows you only what you type to create a replica for the new domain. For the rest of the script's output, see How to Create an NIS+ Root Replica.

How to Create an NIS+ Replica

Before You Begin

Before you run nisserver to create a replica, be sure the following prerequisites have been met.

• The domain must have already been configured and its master server must be running.

• The domain's tables must be populated. (At a minimum, the hosts table must have an entry for the new client machine.)

• You must have initialized the client machine in the parent domain.

• You must have started the NIS+ service, rpc.nisd, on the client.

• You must be logged in as root on the master server. In this example, the master machine is named client2.

You need the following information to run nisserver.

• The domain name

• The client machine name (client3, in this example)

• The superuser password for the root master server

1. Run the nisserver -R command as superuser (root) on the NIS+ domain's master server.

   client2# nisserver -R -d sales.doc.com. -h client3 This script sets up an NIS+ replica server for domain sales.doc.com. Domain name ::sales.doc.com. NIS+ server :client Is this information correct? (type 'y' to accept, 'n' to change)

   In this example, client2 is the master server. The -R option indicates that a replica should be configured. The -d option specifies the NIS+ domain name (sales.doc.com. in this example). The -h option specifies the client machine (client3, in this example) that will become the replica. Notice that this machine is still a client of the doc.com. domain and not a client of the sales.doc.com. domain.

   See How to Create an NIS+ Root Replica for the rest of this script's output.

Initializing NIS+ Subdomain Client Machines

After the master server's tables have been populated from files or NIS maps, you can initialize an NIS+ client machine. This section shows you how to initialize an NIS+ client in the new domain using the nisclient script with default settings. The NIS+ client machine is a different machine from the NIS+ master server.

The -i option used in How to Initialize an NIS+ Subdomain Client Machine does not configure an NIS+ client to resolve host names requiring DNS. You need to explicitly include DNS for clients in their name service switch files.

You use the same procedure to initialize a client in the new domain as you do to initialize a client in the root domain. This example shows you only what you would type to initialize a client for the new domain. For the rest of the script's output, see How to Initialize a New NIS+ Client Machine.

How to Initialize an NIS+ Subdomain Client Machine

Before You Begin

Before you use the nisclient script to initialize a client machine, be sure the following prerequisites have been met.

• The domain must have already been configured and its master server must be running.

• The master server of the domain's tables must be populated. (At a minimum, the host's table must have an entry for the new client machine.)

• You must have initialized a client machine in the domain.

• You must be logged in as a user on the client machine. In this example, the user is named user1.

You need the following information to run nisclient.

• The domain name (sales.doc.com., in this example)

• The default Secure RPC password (nisplus)

• The root password of the machine that will become the client

• The IP address of the NIS+ server (in the client's home domain) (in this example, the address of the master server, client2)

1. Type the following command as superuser to initialize the new client on the new client machine.

   subclient1# nisclient -i -d sales.doc.com. -h client2 Initializing client subclient1 for domain “sales.doc.com.”. Once initialization is done, you will need to reboot your machine. Do you want to continue? (type 'Y' to continue, 'N' to exit this script)

   The -i option initializes a client. The -d option specifies the new NIS+ domain name. (If the domain name is not specified, the default becomes the current domain name.) The -h option specifies the NIS+ server's host name.

   See How to Initialize a New NIS+ Client Machine for the rest of this script's output.

Initializing an NIS+ Subdomain Client Users

You use the same procedure (nisclient) to initialize a user in the new domain as you do to initialize a user in the root domain. All users must make themselves NIS+ clients. This example shows you only what you would type to initialize a user for the new domain. For the rest of the script's output, see How to Initialize an NIS+ User.

How to Initialize an NIS+ Subdomain User

Before You Begin

Before you use the nisclient script to initialize a user, be sure the following prerequisites have been met.

• The domain must have already been configured and its master server must be running.

• The master server of the domain's tables must be populated. (At a minimum, the hosts table must have an entry for the new client machine.)

• You must have initialized a client machine in the domain.

• You must be logged in as a user on the client machine. In this example, the user is named user2.

You need the following information to run the nisclient command.

• The user's login name (user2, in this example)

• The default Secure RPC password (nisplus)

• The login password of the user that will become the NIS+ client

1. To become an NIS+ client, type the following command while logged in as the user.

   user2prompt% nisclient -u At the prompt below, type the network password (also known as the Secure-RPC password) that you obtained either from your administrator or from running the nispopulate script. Please enter the Secure-RPC password for user2:

   See How to Initialize an NIS+ User for the rest of this script's output.

Summary of Commands for the Sample NIS+ Namespace

Table 4–4 summarizes the actual commands that you typed to create the sample namespace. The prompt preceding each command indicates on which machine the command should be typed.