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.

Note - NIS+ might not be supported in a future release. Tools to aid the migration from NIS+ to LDAP are available in the Solaris 9 operating environment (see Part V). For more information, visit http://www.sun.com/directory/nisplus/transition.html.

Setting Up Tables

Note - 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:

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 "Files Security Considerations", 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 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.
Transfer the publickey file.
Transfer the automounter information.
Ping any replicas.
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.

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.

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


	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. Note - NIS+ might not be supported in a future release. Tools to aid the migration from NIS+ to LDAP are available in the Solaris 9 operating environment (see Part V). For more information, visit `http://www.sun.com/directory/nisplus/transition.html`. Setting Up Tables Note - 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: 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 "Files Security Considerations", 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 `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. Transfer the `publickey` file. Transfer the automounter information. Ping any replicas. 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. 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. 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. 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 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. 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.