test

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

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.

Security Considerations When Populating Tables From NIS Maps

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.

ProcedureHow to Populate Tables From Maps

Populate NIS+ tables from NIS maps.

Before You Begin

You need the name and location of the NIS maps.

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

  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 command 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 Chapter 19, Administering NIS+ Tables.

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