Chapter 9 Setting Up NIS+ Tables

This chapter provides step-by-step instructions for using the NIS+ command set to populate NIS+ tables on a master server from /etc files or NIS maps, how to transfer information back from NIS+ tables to NIS maps, how to limit access to the passwd column of the passwd table.

• "Populating Tables--Options"

• "Populating NIS+ Tables From Files"

• "Populating NIS+ Tables From NIS Maps"

• "Transferring Information From NIS+ to NIS"

• "Limiting Access to the Passwd Column to Owners and Administrators"

Setting Up Tables

It is much easier to perform this task with the NIS+ installation scripts, as described in Part 1, than with the NIS+ command set, as described here. The methods described in this chapter should be used only by those administrators who are very familiar with NIS+ and who require some nonstandard features or configurations not provided by the installation scripts. Also, if you have them available, the Solstice AdminSuite tools provide easier methods of working with NIS+ tables.

You can populate NIS+ tables in four ways:

• From files, as described in "Populating NIS+ Tables From Files"

• From NIS maps, as described in "Populating NIS+ Tables From NIS Maps"

• With the nispopulate script, as described in "Populating NIS+ Tables" and "Populating the New Subdomain's Tables"

• With Solstice AdminSuite tools, if you have them available

When populating tables from maps or files, the tables should have already been created in the process of setting up a root or subdomain, as explained in Chapter 5, Setting Up the Root Domain and Chapter 8, Configuring a Non-Root Domain. Although you can populate a domain's tables at any time after they are created, it is recommended that you do so immediately after setting up the domain. This enables you to add clients more easily, since the required information about the clients should already be available in the domain's tables.

Populating Tables--Options

When you populate a table--whether from a file or an NIS map--you can use any of these options:

• Replace - With the replace option, NIS+ first deletes all existing entries in the table and then adds the entries from the source. In a large table, this adds a large set of entries into the master server's /var/nis/trans.log file (one set for removing the existing entries, another for adding the new ones), taking up space in /var/nis. Thus, propagation to replicas will take longer.

• Append - The append option adds the source entries to the NIS+ table. Existing entries are not touched.

• Merge -- The merge option produces the same results as the replace option but uses a different process. The Merge option updates existing entries rather than deleting and then replacing them. With the merge option, NIS+ handles three types of entries differently:

  • Entries that exist only in the source are added to the table.

  • Entries that exist in both the source and the table are updated in the table.

  • Entries that exist only in the NIS+ table are deleted from the table.

  When updating a large table with a file or map whose contents are not vastly different from those of the table, the merge option can spare the server a great many operations. Because it deletes only the entries that are not duplicated in the source (the replace option deletes all entries, indiscriminately), it saves one delete and one add operation for every duplicate entry. Therefore, this is the preferred option.

Populating NIS+ Tables From Files

This task transfers the contents of an ASCII file, such as /etc/hosts, into an NIS+ table.

Here is an outline of the procedure:

1. Check the content of each file that you will be transferring data from.

2. Make a copy of each file. Use this copy for the actual transfer. In this guide, copies of files to be transferred are given names ending in xfr (for example, hosts.xfr).

3. Log in to an NIS+ client. (You must have credentials and permissions allowing you to update the tables. See "Files Security Considerations", below.)

4. Add /usr/lib/nis to the search path for this shell (if not already done).

5. Use nisaddent to transfer any of these files one at a time: aliases, bootparams, ethers, group, hosts, netgroup, netmasks, networks, passwd, protocols, rpc, services, shadow, and ipnodes.

   ---

   Note -

   The new /etc/inet/ipnodes file contains IPv4 and IPv6 addresses. Use nisaddent to transfer the /etc/inet/ipnodes file into the ipnodes.org_dir table.

   ---

6. Transfer the publickey file.

7. Transfer the automounter information.

8. Ping any replicas.

9. Checkpoint the tables.

Files Security Considerations

You can populate NIS+ tables from any NIS+ client or from the root master server. You do not have to be logged in as superuser (root) to populate NIS+ tables, but you do have to have the proper credentials and access rights. If you are going to replace or merge the entries in the table with the entries from the text file, you must have create and destroy rights to the table. If you are going to append the new entries, you only need create rights.

The NIS+ security system is complex. If you are not familiar with NIS+ security, you may want to review the security-related chapters of Solaris Naming Administration Guide before starting to set up your NIS+ environment.

After you complete this operation, the table entries will be owned by the NIS+ principal that performed the operation and the group specified by the NIS_GROUP environment variable.

Prerequisites

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

• The domain's servers must have enough swap space to accommodate the new table information. See NIS+ Transition Guide for information on NIS+ requirements.

• The information in the file must be formatted appropriately for the table into which it will be loaded. See "Prerequisites to Running nispopulate" for information concering what format a text file must have to be transferred into its corresponding NIS+ table. Local /etc files are usually formatted properly, but may have several comments that you need to remove.

• Machine and user names cannot be duplicated. All users and all machines must have unique names. You cannot have a machine with the same name as a user.

• Machine names cannot contain dots (periods) or underscores. For example, a machine named sales.alpha is not allowed. Hyphens, however, are allowed. For example, a machine name such as sales-alpha is allowed.

Information You Need

You need the name and location of the text files that will be transferred.

Populating NIS+ Tables From Files -- Task Map

How to Populate NIS+ Tables From Files

1. Check each file that you will be transferring data from.

   Make sure that there are no spurious or incorrect entries. Make sure that the right data is in the correct place and formatted properly. Remove any outdated, invalid, or corrupt entries. You should also remove any incomplete or partial entries. (It is easier to add incomplete entries after setup than to try transferring incomplete or damaged entries from the file.)

2. Make a working copy of each file you will be transferring.

   Use this working copy for the actual file transfer steps described in this section. Give each working copy the same filename extension (for example, .xfr).

   rootmaster% cp /etc/hosts /etc/hosts.xfr

   For safety reasons, you might also copy all of the files you plan to use to some directory other than /etc. The nisaddent and nispopulate commands allow you to specify the file source directory.

3. Log in to an NIS+ client.

   You can perform this task from any NIS+ client--just be sure that the client belongs to the same domain as the tables into which you want to transfer the information. The examples in this task use the root master server. Because the administrator in these examples is logged on as superuser, the NIS+ principal actually performing this operation (and therefore needing the proper credentials and access rights) is the root master server.

   However, it is not necessary to be a superuser (root) or to be logged in on the root master server to update NIS+ tables. Regular users or superusers on any machine can update NIS+ tables, so long as they have the proper credentials, authorization, file permissions.

4. Add /usr/lib/nis to the search path for this shell.

   Since you will be using the /usr/lib/nis/nisaddent command once per table, adding its prefix to the search path will save you the trouble of typing it each time. Here are two examples, one for C shell users and one for Bourne or Korn shell users:

   For C Shell

   rootmaster# setenv PATH $PATH:/usr/lib/nis

   For Bourne or Korn Shell

   rootmaster# PATH=$PATH:/usr/lib/nis rootmaster# export PATH

5. Use nisaddent to transfer any of these files, one at a time:

   aliases bootparams ethers group hosts ipnodes netgroup netmasks networks protocols rpc, services

   The publickey, automounter, passwd, and shadow files require slightly different procedures; for the publickey file, go to Step 6; for the automounter files, go to Step 7; for the passwd and shadow files, go to Step 8.

   By default, nisaddent appends the information. To replace or merge instead, use the -r or -m options.

   To replace:

   rootmaster# nisaddent -r -f filename table[domain]

   To append:

   rootmaster# nisaddent -a -f filename table [domain]

   To merge:

   rootmaster# nisaddent -m -f filename table [domain]

   The best option for populating the tables for the first time is the -a option, the default. The best option to synchronize the NIS+ tables with NIS maps or /etc files is the -m (merge) option.

   • filename is the name of the file. The common convention is to append .xfr to the end of these file names to identify them as transfer files created with nisaddent.

   • table is the name of the NIS+ table. The domain argument is optional; use it only to populate tables in a different domain. Here are some examples, entered from the root domain's master server. The source files are edited versions of the /etc files:

   rootmaster# nisaddent -m -f /etc/hosts.xfr hosts rootmaster# nisaddent -m -f /etc/groups.xfr groups

   If you perform this operation from a non-root server, keep in mind that a non-root server belongs to the domain above the one it supports; therefore, it is a client of another domain. For example, the sales.doc.com. master server belongs to the doc.com. domain. To populate tables in the sales.doc.com. domain from that master server, you must append the sales.doc.com. domain name to the nisaddent statement.

   salesmaster# nisaddent -f /etc/hosts.xfr hosts Sales.doc.com.

   If you perform this operation as a client of the sales.doc.com. domain, you do not need to append the domain name to the syntax. For more information about nisaddent, see the tables chapter of Solaris Naming Administration Guide.

   To verify that the entries were transferred into the NIS+ table, use the niscat command, as described more fully in the tables chapter of Solaris Naming Administration Guide.

   rootmaster# niscat groups.org_dir root::0:root other::1:: bin::2:root,bin,daemon .

   Troubleshooting tip: If niscat does not now show the updates immediately, it could be because the changes have not been sent by the master server to one or more of the replica servers. In this case, you can either wait and try again in five or ten minutes or use niscat's -M option, which specifies that niscat obtain its data from the master server.

6. Transfer the publickey file.

   Because the domain's cred table already stores some credentials, you need to make sure they are not overwritten by the contents of the publickey text file that you transfer into the cred table. You can avoid this by removing those credentials from the publickey text file. For rootmaster, there might be one or more lines like the following, all of which should be removed:

   unix.rootmaster@doc.com public-key:private-key [alg-type]

   Then you can transfer the contents of the publickey file to the cred table. Use nisaddent, with the -a (add) option.

   rootmaster# nisaddent -a -f /etc/publickey.xfr -t cred.org_dir publickey [domain]

   Note, however, that this operation transfers only DES credentials into the cred table. You still need to create their LOCAL credentials to the cred table.

7. Transfer the automounter information.

   Although the nissetup utility creates auto_master and auto_home tables, they are not considered standard NIS+ tables. Therefore, transferring information into them requires a slightly different syntax; in particular, you must use the -t flag and specify that the table is of type key-value.

   rootmaster# nisaddent -f auto.master.xfr -t auto_master.org_dir key-value rootmaster# nisaddent -f auto.home.xfr -t auto_home.org_dir key-value

8. Build the NIS+ passwd table.

   The NIS+ passwd table is composed of data drawn from both the /etc/passwd and /etc/shadow files. Thus, you must run nisaddent twice to build the passwd table: once for the /etc/passwd file, using passwd as the target table, and once for the /etc/shadow file, using shadow as the target table. (Note that when running nisaddent on the shadow file, you specify shadow as the target table, even though there is no shadow table and the data is actually being placed in the shadow column of the passwd table.)

   rootmaster# nisaddent -m -f /etc/passwd.xfr passwd rootmaster# nisaddent -m -f /etc/shadow.xfr shadow

9. Transfer your updates to your replica servers by running nisping.

   Running nisping updates any replica servers with your changes.

   master1# nisping domain master1# nisping org_dir.domaincom. master1# nisping groups_dir.domain

10. Checkpoint the tables.

    Now that you have updated the in-memory copies of the NIS+ data set on your master and replica servers, you should write those changes into the table files on disk. This is called checkpointing. (Checkpoint is not mandatory at this time, so long as you have regularly scheduled checkpoints that will take care of it later. But if your changes have been significant, it is a good idea to get them written to disk as soon as convenient.)

    This step ensures that all the servers supporting the domain transfer the new information from their .log files to the disk-based copies of the tables. If you have just set up the root domain, this step affects only the root master server, since the root domain does not yet have replicas. To checkpoint, use the nisping command with the -C (uppercase) option.

    rootmaster# nisping -C org_dir Checkpointing replicas serving directory org_dir.doc.com. : Master server is rootmaster.doc.com. Last update occurred at July 14, 1997 Master server is rootmaster.doc.com. checkpoint succeeded.

    If you do not have enough swap space, the server is unable to checkpoint properly, but it will not notify you. One way to make sure that you have sufficient swap space is to list the contents of a table with the niscat command. If you do not have enough swap space, you will see this error message:

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

    Even though it doesn't seem to, this message indicates that you don't have enough swap space. Increase the swap space and checkpoint the domain again.

Populating NIS+ Tables From NIS Maps

This task transfers the contents of an NIS map into an NIS+ table. Here is a list of the steps:

1. Check the content of each NIS map that you will be transferring data from.

2. Log in to an NIS+ client.

3. Add /usr/lib/nis to the search path for this shell.

4. Use nisaddent to transfer any of these maps, one at a time: aliases, bootparams, ethers, group, hosts, netgroup, netmasks, networks, passwd, protocols, rpc, services.

5. Transfer the publickey map.

6. Transfer the automounter information.

7. Update your replicas with your changes by running nisping.

8. Checkpoint the tables.

Maps Security Considerations

You can perform this task from any NIS+ client as long as you (or superuser on the client) have the proper credentials and access rights. If you are going to replace or merge the entries in the table with the entries from the NIS map, you must have create and destroy rights to the table. If you are going to append the new entries, you need only create rights.

After you complete this operation, the table entries are owned by the NIS+ principal that performed the operation (either you or, if logged on as superuser, the client) and the group specified by the NIS_GROUP environment variable.

Prerequisites

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

• The dbm files (.pag and .dir files) for the NIS maps you are going to load into the NIS+ tables must already be in a subdirectory of /var/yp.

• Machine and user names cannot be duplicated. All users and all machines must have unique names. You cannot have a machine with the same name as a user.

• Machine names cannot contain dots (periods). For example, a machine named sales.alpha is not allowed. A machine named sales-alpha is allowed.

Information You Need

You need the name and location of the NIS maps.

Populating NIS+ Tables From NIS Maps -- Task Map

How to Populate Tables From Maps

1. Check each NIS map that you will be transferring 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 properly. Remove any outdated, invalid, or corrupt entries. You should also remove any incomplete or partial entries. (It is easier to add incomplete entries after setup than to try transferring incomplete or damages entries from the map.)

2. Log in to an NIS+ client.

   You can perform this task from any NIS+ client--so long as that client belongs to the same domain as the tables into which you want to transfer the information. The examples in this task use the root master server. Since the administrator in these examples is logged in as superuser, the NIS+ principal actually performing this operation (and therefore needing the proper credentials and access rights) is the root master server.

3. Add /usr/lib/nis to the search path for this shell.

   Because you will be using the /usr/lib/nis/nisaddent command once for each table, adding its prefix to the search path will save you the trouble of typing it each time. Here are two examples, one for C shell users and one for Bourne or Korn shell users:

   For C Shell

   rootmaster# setenv PATH $PATH:/usr/lib/nis

   For Bourne or Korn Shell

   rootmaster# PATH=$PATH:/usr/lib/nis rootmaster# export PATH

4. Use nisaddent to transfer any of these maps, one at a time:

   aliases, bootparams, ethers, group, hosts, netgroup, netmasks, networks, passwd, protocols, rpc, services.

   The -publickey and automounter maps require slightly different procedures; for the publickey file, go to Step 6, and for the automounter files, go to Step 7.

   By default, nisaddent appends the file information to the table information. To replace or merge instead, use the -r or -m options:

   To replace:

   rootmaster# nisaddent -r -y nisdomain table

   To append:

   rootmaster# nisaddent -a -y nisdomain table

   To merge:

   rootmaster# nisaddent -m -y nisdomain table

   The best option for populating the tables for the first time is the -a option, which is the default. The best option to synchronize the NIS+ tables with NIS maps or /etc files is the -m (merge) option.

   The -y (lowercase) option indicates an NIS domain instead of a text file. The nisdomain argument is the name of the NIS domain whose map you are going transfer into the NIS+ table. You don't have to name the actual map; the nisaddent utility automatically selects the NIS map that corresponds to the table argument. Here are some examples:

   rootmaster# nisaddent -m -y olddoc hosts rootmaster# nisaddent -m -y olddoc passwd rootmaster# nisaddent -m -y olddoc groups

   The first example transfers the contents of the hosts.byname and hosts.byaddr maps in the olddoc (NIS) domain to the NIS+ hosts table in the root domain (NIS+). The second transfers the NIS maps that store password-related information into the NIS+ passwd table. The third does the same with group-related information. For more information about the nisaddent command, see the tables chapter of Solaris Naming Administration Guide.

5. Transfer the publickey map.

   Since the domain's cred table already stores some credentials, you need to make sure they are not overwritten by the contents of the publickey map that you transfer into the cred table.

   1. First, dump the publickey map to a file, then open that file with your text editor.

      rootmaster# makedbm -u /var/yp/olddoc/publickey.byname /etc/publickey.xfr rootmaster# vi /tmp/publickey.tmp

   2. Now remove the credentials of the workstation you are logged in to from the publickey map.

      For rootmaster, there might be one or lines like the following, all of which should be removed:

      unix.rootmaster@doc.com public-key:private-key [alg-type]

   3. Now you can transfer the contents of the file--not the map--into the cred table. Use nisaddent, with the -a (add) option.

      rootmaster# nisaddent -a -f /etc/publickey.xfr -t cred.org_dir Publickey

      Notice that this operation transfers only DES credentials into the cred table. You still need to create their LOCAL credentials to the cred table.

6. Transfer the automounter information.

   Although the nissetup utility creates auto_master and auto_home tables, they are not considered standard NIS+ tables. Therefore, transferring information into them requires a slightly different syntax:

   rootmaster# nisaddent -y olddoc -Y auto.master -t auto_master.org_dir key-value rootmaster# nisaddent -y olddoc -Y auto.home -t auto_home.org_dir key-value

   The -m and -y options are still required, as is the NIS domain name (in this instance, olddoc). However, you must precede the name of the NIS map (for example, auto.master) with a -Y (uppercase). Then, as is required when transferring automounter text files, you must use the -t option, which indicates that this is a nonstandard NIS+ table. Its arguments are the name of the NIS+ directory object (auto_master.org_dir) and the type of table (key-value). Be sure to append the org_dir suffixes to the NIS+ table names.

7. Transfer your updates to your replica servers by running nisping.

   Running nisping updates any replica servers with your changes.

   master1# nisping domain master1# nisping org_dir.domaincom. master1# nisping groups_dir.domain

8. Checkpoint the tables.

   This step ensures that all the servers supporting the domain transfer the new information from their .log files to the disk-based copies of the tables. If you just finished setting up the root domain, this step affects only the root master server, since the root domain does not yet have replicas. Use the nisping command with the -C (uppercase) option.

   rootmaster# nisping -C org_dir Checkpointing replicas serving directory org_dir.doc.com. : Master server is rootmaster.doc.com. Last update occurred at July 14, 1994 Master server is rootmaster.doc.com. checkpoint succeeded.

   If you do not have enough swap space, the server is unable to checkpoint properly, but it does not notify you. One way to make sure you have sufficient swap space is to use list the contents of a table with the niscat command. If you do not have enough swap space, you will see this error message:

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

   Even though it does not seem to, this message indicates that you do not have enough swap space. Increase the swap space and checkpoint the domain again.

Transferring Information From NIS+ to NIS

This task transfers the contents of NIS+ tables into NIS maps on a Solaris 1.x NIS master server. Here is an outline of the procedure:

1. Log in to the NIS+ server.

2. Transfer the NIS+ tables in to output files.

3. Transfer the contents of the output files to the NIS maps.

NIS to NIS+ Security Considerations

To perform this task, you must have read access to each table whose contents you transfer.

Prerequisites

The maps must already have been built on the NIS server.

Transferring Information From NIS+ to NIS -- Task Map

How to Transfer Information From NIS+ to NIS

1. Log in to the NIS+ server.

   This example uses the server named dualserver.

2. Transfer the NIS+ tables to output files.

   Use the nisaddent command with the -d option, once for each table.

   dualserver% /usr/lib/nis/nisaddent -d -t table tabletype > filename

   The -d option transfers the contents of table to filename, converting the contents back to standard /etc file format.

3. Transfer the contents of the output files in to the NIS maps.

   The NIS+ output files are ASCII files that you can use as input files for the NIS maps. Copy them into the NIS master's /etc directory, then use make as usual.

   dualserver# cd /var/yp dualserver# make

Limiting Access to the Passwd Column to Owners and Administrators

This task describes how to limit read access to the password-related columns of the passwd table to the entry owner and the table administrators, without affecting the read access of other authenticated principals (including applications) to the remaining columns of the passwd table.

This task establishes the following rights:

                         Nobody  Owner   Group  World
Table Level Rights:      ----    rmcd    rmcd   ----
Passwd Column Rights:    ----    rm--    rmcd   ----
Shadow Column Rights:    ----    rm--    rmcd   ----

Passwd Column Security Considerations

• The domain must not be running in NIS-compatibility mode.

• All clients of the domain must have DES credentials.

• All clients of the domain must be running Solaris Release 2.3 or a later release.

• Users' network passwords (used to encrypt their DES credentials) must be the same directory as their login passwords.

Prerequisites

• The passwd table must have already been set up. It need not have any information in it, however.

• The NIS+ principal performing this task must have modify rights to the passwd table.

Information You Need

All you need is the name of the passwd table.

Limiting Access to the Passwd Column to Owners and Administrators -- Task Map

How to Limit Read Access to the Passwd Column

1. Log in to the domain's master server.

   The examples in this task use the root master server, rootmaster.

2. Check the current table and column permissions.

   Use the niscat -o command.

   rootmaster# niscat -o passwd.org_dir

   This task assumes the existing permissions are:

   Access Rights : ----rmcdrmcdr--- Columns : [0] Name : name Access Rights : r-----------r--- [1] Name : passwd Access Rights : -----m---------- [2] Name : uid Access Rights : r-----------r--- [3] Name : gid Access Rights : r-----------r--- [4] Name : gcos Access Rights : r----m------r--- [5] Name : home Access Rights : r-----------r--- [6] Name : shell Access Rights : r-----------r--- [7] Name : shadow Access Rights : r-----------r---

   If your permissions are different, you may need to use a different syntax. For instructions, see the rights chapter of Solaris Naming Administration Guide.

3. Change the table permissions.

   Use the nischmod command to change the table's object-level permissions to ---- rmcdrmcd ----

   rootmaster# nischmod og=rmcd,nw= passwd.org_dir

4. Change the column permissions.

   Use the nistbladm command with the -u option to change the permissions of the passwd and shadow columns to:

   passwd ---- rm-- ---- ---- shadow ---- r--- ---- ---- rootmaster# nistbladm -u passwd=o+r, shadow=o+r passwd.org_dir

5. Verify the new permissions.

   Use the niscat -o command, as you did in Step 2. The permissions should look the same as they do in that step's output.

Table Population Summaries

Following are summaries of the steps required to populate NIS+ tables. They assume the simplest case, so be sure you are familiar with the more thorough task descriptions before you use this summary as a reference. For brevity, these summaries do not show the server's responses to each command.