JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
System Administration Guide: Naming and Directory Services (NIS+)
search filter icon
search icon

Document Information

Preface

Part I About Naming and Directory Services

1.  Name Service Switch

Part II NIS+ Setup and Configuration

2.  NIS+: An Introduction

3.  NIS+ Setup Scripts

4.  Configuring NIS+ With Scripts

5.  Setting Up the NIS+ Root Domain

6.  Configuring NIS+ Clients

7.  Configuring NIS+ Servers

8.  Configuring an NIS+ Non-Root Domain

9.  Setting Up NIS+ Tables

Part III NIS+ Administration

10.  NIS+ Tables and Information

NIS+ Table Structure

NIS+ Columns and Entries

NIS+ Search Paths

Ways to Set Up NIS+ Tables

How NIS+ Tables Are Updated

11.  NIS+ Security Overview

12.  Administering NIS+ Credentials

13.  Administering NIS+ Keys

14.  Administering Enhanced NIS+ Security Credentials

15.  Administering NIS+ Access Rights

16.  Administering NIS+ Passwords

17.  Administering NIS+ Groups

18.  Administering NIS+ Directories

19.  Administering NIS+ Tables

20.  NIS+ Server Use Customization

21.  NIS+ Backup and Restore

22.  Removing NIS+

23.  Information in NIS+ Tables

24.  NIS+ Troubleshooting

A.  NIS+ Error Messages

About NIS+ Error Messages

Common NIS+ Namespace Error Messages

B.  Updates to NIS+ During the Solaris 10 Release

Solaris 10 and NIS+

Glossary

Index

Ways to Set Up NIS+ Tables

Setting up NIS+ tables involves three or four tasks:

  1. Creating the org_dir directory

  2. Creating the system tables

  3. Creating non-system tables (optional)

  4. Populating the tables with information

As described in NIS+ Files and Directories, NIS+ system tables are stored under an org_dir directory. So, before you can create any tables, you must create the org_dir directory that will hold them. You can do this in three ways.

The nisserver script and the nissetup and nismkdir utilities are described in nismkdir Command. Additional information on the nismkdir command can be found in nismkdir Command.

A benefit of the nissetup utility is its capability to assign the proper access rights to the tables of a domain whose servers are running in NIS-compatibility mode. When entered with the -Y flag, it assigns read permissions to the nobody class of the objects it creates, allowing NIS clients, who are unauthenticated, to get information from the domain's NIS+ tables.

The 16 NIS+ system tables and the type of information they store are described in Table 10-1. To create them, you could use one of the three ways mentioned above. The nistbladm utility also creates and modifies NIS+ tables. You could conceivably create all the tables in a namespace with the nistbladm command, but you would have to type much more and you would have to know the correct column names and access rights. A much easier way is to use the nisserver script.

To create a non-system table – that is, a table that has not been preconfigured by NIS+ – use the nistbladm command. (Note that if you are creating additional automount maps, the first column must be named key and the second column named value.)

You can populate NIS+ tables in three ways: from NIS maps, from ASCII files (such as /etc files), and manually.

If you are upgrading from the NIS service, you already have most of your network information stored in NIS maps. You don't have to re-enter this information manually into NIS+ tables. You can transfer it automatically with the nispopulate script or the nisaddent utility.

If you are not using another network information service, but maintain network data in a set of /etc files, you don't have to re-enter this information, either. You can transfer it automatically, also using the nispopulate script or the nisaddent utility.

If you are setting up a network for the first time, you may not have much network information stored anywhere. In that case, you'll need to first get the information and then enter it manually into the NIS+ tables. You can do this with the nistbladm command. You can also do it by entering all the information for a particular table into an input file& – is essentially the same as an /etc file – and then transferring the contents of the file with the nispopulate script or the nisaddent utility.

How NIS+ Tables Are Updated

When a domain is set up, its servers receive their first versions of the domain's NIS+ tables. These versions are stored on disk, but when a server begins operating, it loads them into memory. When a server receives an update to a table, it immediately updates its memory-based version of the table. When it receives a request for information, it uses the memory-based copy for its reply.

Of course, the server also needs to store its updates on disk. Since updating disk-based tables takes time, all NIS+ servers keep log files for their tables. The log files are designed to temporarily store changes made to the table, until they can be updated on disk. They use the table name as the prefix and append .log. For example:

hosts.org_dir.log
bootparams.org_dir.log
password.org_dir.log

You should update disk-based copies of a table on a daily basis so that the log files don't grow too large and take up too much disk space. This process is called checkpointing. To do this, use the nisping -C command.