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:

Check the content of each file that you will be transferring data from.
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).
Log in to an NIS+ client. (You must have credentials and permissions allowing you to update the tables. See Security Considerations When Populating NIS+ Tables From Files, below.)
Add /usr/lib/nis to the search path for this shell (if not already done).
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 prior to the Solaris 10 7/07 release, ipnodes.

Note - Prior to the Solaris 10 7/07 release, the /etc/inet/ipnodes file contains IPv4 and IPv6 addresses. If you are running a Solaris release prior to the Solaris 10 7/07 release, use nisaddent to transfer the /etc/inet/ipnodes file into the ipnodes.org_dir table.
Transfer the publickey file.
Transfer the automounter information.
Ping any replicas.
Checkpoint the tables.

Security Considerations When Populating NIS+ Tables From Files

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.

Note - The NIS+ security system is complex. If you are not familiar with NIS+ security, you may want to review Chapter 11, NIS+ Security Overview 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.

How to Populate NIS+ Tables From Files

Populate NIS+ tables from files.

Before You Begin

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

The information in the file must be formatted appropriately for the table into which it will be loaded. See Prerequisites to Running nispopulate to Populate Root Server Tables for information concerning 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.

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

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.)
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.
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.
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
```
Use nisaddent to transfer any of these files, one at a time:
```
aliases
bootparams
ethers
group
hosts
ipnodes (Not used as of the Solaris 10 7/07 release)
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.
To verify that the entries were transferred into the NIS+ table, use the niscat command, as described more fully in Chapter 19, Administering NIS+ Tables.
```
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.
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.
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 
```
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
```
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
```
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.

Skip Navigation Links
Exit Print View
	System Administration Guide: Naming and Directory Services (NIS+)