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