Replace, Append, and Merge

When you populate a table -- whether from a file or an NIS map -- you can use any of three options: replace, append, or merge.

The append option simply adds the source entries to the NIS+ table.

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 table's .log file (one set for removing the existing entries, another for adding the new ones), taking up space in /var/nis and making propagation to replicas time-consuming.

The merge option produces the same result as the replace option, but uses a different process, one that can greatly reduce the number of operations that must be sent to the replicas. 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 only deletes 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.

Populating NIS+ Tables From Files

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

Here is a list of the steps:

1. Log on to an NIS+ client.

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

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

4. Transfer the publickey file.

5. Transfer the automounter information.

6. Checkpoint the tables.

Security Considerations

You can perform this task from any NIS+ client, including the root master server, as long as you 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.

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 Name Services Configuration Guide.
• The information in the file must be formatted appropriately for the table into which it will be loaded. The Name Services Configuration Guide describes the 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 would need to remove.

Information You Need

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

· How to Populate NIS+ Tables From Files

1. Log on 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. Since

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.

2. 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 csh users, one for sh/ksh users:

rootmaster# setenv $PATH:/usr/lib/nis # csh users rootmaster# PATH=$PATH:/usr/lib/nis # sh/ksh users rootmaster# export PATH

If you are using the Solaris 1.x distribution of NIS+, the path may be different; check the README file.

3. 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 4, for the automounter file, go to Step 5, for the passwd and shadow file go to Step 6.

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

rootmaster# nisaddent -r -f filename table [domain] # to replace rootmaster# nisaddent -a -f filename table [domain] # to append rootmaster# nisaddent -m -f filename table [domain] # to merge

The best option for populating the tables for the first time is the -a option, which is the default anyway. 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. 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 simply 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.Wiz.Com. master server belongs to the Wiz.Com. domain. To populate tables in the Sales.Wiz.Com. domain from that master server, you would have to append the Sales.Wiz.Com. domain name to the nisaddent statement. For example:

salesmaster# nisaddent -f /etc/hosts.xfr hosts \ Sales.Wiz.Com.

If you performed this operation as a client of the Sales.Wiz.Com. domain, you would not need to append the domain name to the syntax. For more information about nisaddent, see Chapter 12, "Administering NIS+ Tables."

To verify that the entries were transferred into the NIS+ table, use the niscat command (described in Chapter 12, "Administering NIS+ Tables"). Here is an example:

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

4. Transfer the publickey file.

   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 text file that you transfer into the Cred table. You can avoid this by removing those credentials from the publickey text file. For rootmaster, that line would be:

unix.rootmaster@Wiz.Com public-key:private-key

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

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

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

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

6. 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 as shown below. (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

7. 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 have just setup 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 (upper case) option:

rootmaster# nisping -C org_dir Checkpointing replicas serving directory org_dir.Wiz.Com. : Master server is rootmaster.Wiz.Com. Last update occured at date Master server is rootmaster.Wiz.Com. checkpoint succeeded.

If you don't have enough swap space, the server will be unable to checkpoint properly, but it won't notify you. One way to make sure all went well is to list the contents of a table with the niscat command. If you don't have enough swap space, you'll get 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.

This step completes this task.

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. Log on to an NIS+ client.

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

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

4. Transfer the publickey map.

5. Transfer the automounter information.

6. Checkpoint the tables.

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 only need Create rights.

After you complete this operation, the table entries will be 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.

Information You Need

You need the name and location of the NIS maps.

· How to Populate NIS+ Tables From Maps

1. Log on 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. Since 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.

2. 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 csh users, one for sh/ksh users:

rootmaster# setenv $PATH:/usr/lib/nis # csh users rootmaster# PATH=$PATH:/usr/lib/nis # sh/ksh users rootmaster# export PATH

If you are using the Solaris 1.x distribution of NIS+, the path may be different; check the README file.

3. 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 4, and for the automounter files, go to Step 5.

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

rootmaster# nisaddent -r -y nisdomain table # to replace rootmaster# nisaddent -a -y nisdomain table # to append rootmaster# nisaddent -m -y nisdomain table # to merge

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

The -y (lower case) 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 correspond to the table argument. Here are some examples:

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

The first example transfers the contents of the hosts.byname and hosts.byaddr maps in the OldWiz (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 12, "Administering NIS+ Tables."

4. 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. First, dump the publickey map to a file:

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

Open the file and remove the credentials of the workstation you are logged onto from the publickey map. For rootmaster, that line would be:

unix.rootmaster@Wiz.Com public-key:private-key

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

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

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

5. 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 OldWiz -Y auto.master \ -t auto_master.org_dir key-value rootmaster# nisaddent -y OldWiz -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, OldWiz). However, you must precede the name of the NIS map (e.g., auto.master) with a -Y (upper case). 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+ table (auto_master.org_dir) and the type of table (key-value). Be sure to append the "org_dir" suffixes to the NIS+ table names.

6. 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 (upper case) option:

rootmaster# nisping -C org_dir Checkpointing replicas serving directory org_dir.Wiz.Com. : Master server is rootmaster.Wiz.Com. Last update occured at date Master server is rootmaster.Wiz.Com. checkpoint succeeded.

If you don't have enough swap space, the server will be unable to checkpoint properly, but it won't notify you. One way to make sure all went well is to use list the contents of a table with the niscat command. If you don't have enough swap space, you'll get 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.

This step completes this task.

Transferring Information From NIS+ to NIS

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

1. Log on to the NIS+ server.

2. Transfer the NIS+ tables into output files.

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

Security Considerations

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

Prerequisites

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

· How to Transfer Information From NIS+ to NIS

1. Log on to the NIS+ server.

   This example uses the server named "dualserver."

2. Transfer the NIS+ tables into output files.

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

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

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

3. Transfer the contents of the output files into 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, and then use makedbm as usual:

dualserver# makedbm flags output-file NIS-dbm-file

Limiting Access to the Passwd Column

This task describes how to limit Read access to the passwd column of the Passwd table only to authenticated users without affecting the Read access of unauthenticated principals (i.e., applications) to the remaining columns in the Passwd table. Use this task only for NIS+ releases prior to Solaris 2.3, since Solaris 2.3 and later supplies as a default the access rights provided by this task.

Security Considerations

• The domain must not be running in NIS-compatibility mode.
• All NIS+ clients of the domain must have DES credentials.

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.

· How to Limit Access to the Passwd Column

1. Log onto 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

If the table has the permissions shown below, you don't need to perform this task; the table is already set up properly:

rootmaster# niscat -o passwd.org_dir Object Name : passwd . . . 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---

3. Change the table permissions.

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

--- rmcd rmcd r---

rootmaster# nischmod n=,og=rmcd,w=r passwd.org_dir

4. Change the column permissions.

   Use the nistbladm command with the -u option to change the column permissions to:

name r--- ---- ---- r--- passwd ---- -m-- ---- ---- uid r--- ---- ---- r--- gid r--- ---- ---- r--- gcos r--- ---- ---- r--- home r--- ---- ---- r--- shell r--- ---- ---- r--- shadow r--- ---- ---- r---

You could use nistbladm once . . .

rootmaster# nistbladm -u [name=n+r,uid=n+r,gid=n+r,gcos=n+r, \ home=n+r,shell=n+r,shadow=n+r],passwd.org_dir

. . . but if you made a typing error, you'd have to retype the whole line, possibly several times over. You might prefer to use the command once for each column:

rootmaster# nistbladm -u [name=n+r],passwd.org_dir rootmaster# nistbladm -u [uid=n+r],passwd.org_dir rootmaster# nistbladm -u [gid=n+r],passwd.org_dir rootmaster# nistbladm -u [gcos=n+r],passwd.org_dir rootmaster# nistbladm -u [home=n+r],passwd.org_dir rootmaster# nistbladm -u [shell=n+r],passwd.org_dir rootmaster# nistbladm -u [shadow=n+r],passwd.org_dir

This example assumes the columns had no previous Read permissions assigned to the Nobody class. Notice that no Read permissions are added to the passwd column. If your table provided different permissions, you would use a different syntax; for details, see the description of the nistbladm -u command on page 151.

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.

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 2.3 or a later release.
• Users' network passwords (used to encrypt their DES credentials) must be the same 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.
• The previous task, "Limiting Access to the Passwd Column" must have already been performed.

Information You Need

All you need is the name of the Passwd table.

· How to Limit Read Access to the Passwd Column

1. Log onto 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 Chapter 9, "Administering NIS+ Access Rights."

3. Change the table permissions.

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

---- rmcd rmcd ----

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.

Summaries

Following is a summary of the steps required to populate NIS+ tables. It assumes 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.

rootmaster% % PATH=$PATH:/usr/lib/nis; export PATH % nisaddent -m -f /etc/hosts.xfr hosts % . % . % . % vi /etc/publickey.xfer	1. Log on to an NIS+ client. 2. Add /usr/lib/nis to search path. 3. Transfer each file, one at a time. 4. Transfer publickey file.
% nisaddent -a -f /etc/publickey.xfr cred % nisaddent -f auto.master.xfr \	First remove new credentials from the file. Then transfer it. 5. Transfer the automounter files.
-t auto_master.org_dir key-value % nisaddent -f auto.home.xfr \ -t auto_home.org_dir key-value % nisping -C org_dir	6. Checkpoint the table directory.

Figure 5-1 Summary of Steps to Transfer Files Into NIS+ Tables

rootmaster% % PATH=$PATH:/usr/lib/nis; export PATH $ nisaddent -m -y OldWiz hosts % . % . % . % makedbm -u /var/yp/OldWiz/publickey.byname > \ /etc/publickey.xfr % vi /etc/publickey.xfr % nisaddent -a -f /etc/publickey.xfr -t cred.ortg_dir publickey	1. Log on to an NIS+ client. 2. Add /usr/lib/nis to search path. 3. Transfer each map, one at a time. 4. Transfer publickey file. First dump the publickey map to a file. Then remove new credentials. Then transfer the file. 5. Transfer the automounter maps.
% nisaddent -y OldWiz -Y auto.master \ -t auto_master.org_dir key-value % nisaddent -y OldWiz -Y auto.home \ -t auto_home.org_dir key-value % nisping -C org_dir	6. Checkpoint the table directory.

Figure 5-2 Summary of Steps to Transfer Maps into NIS+ Tables

dualserver% % /usr/lib/nis/nisaddent -d [-t table] tabletype > filename % . % . % . % makedbm flags output-file NIS-dbm-file

1. Log on to NIS+ server. 2. Transfer NIS+ tables to files. 3. Transfer files to NIS maps.

Figure 5-3 Summary of Steps to Transfer NIS+ Tables to NIS Maps

rootmaster# # niscat -o passwd.org_dir # nischmod n=,og=rmcd,w=r passwd.org_dir # nistbladm -u [name=n+r,uid=n+r,gid=n+r, \ gcos=n+r,home=n+r,shell=n+r, \ shadow=n+r], passwd.org_dir # niscat -o passwd.org_dir

1. Log onto the domain's master server. 2. Check the table's existing rights. 3. Assign the table new rights. 4. Assign the columns new rights 5. Verify the new rights.

Figure 5-4 Summary of Steps to Limit Acces to Passwd Column

rootmaster# # niscat -o passwd.org_dir # nischmod og=rmcd,nw= passwd.org_dir # nistbladm -u [passwd=o+r, shadow=n+r], \ passwd.org_dir # niscat -o passwd.org_dir

1. Log onto the domain's master server. 2. Check the table's existing rights. 3. Assign the table new rights. 4. Assign the columns new rights 5. Verify the new rights.

Figure 5-5 Summary of Steps to Change Access Rights to Passwd Column