v NIS client machines cannot be sure that the data they are receiving comes from an authorized NIS
server, while authorized NIS+ clients are certain that the data is coming from an authorized NIS+ server.
v Under NIS, if the server is no longer responding, the NIS ypmatch call continues to retry this call until
the server starts responding and answers the request. The NIS+ API (application programing interface)
returns an error message to the application when this situation occurs.
Note: In the AIX 4.3.3 and later releases, the NIS-compatibility mode supports DNS forwarding.
Although an NIS+ domain cannot be connected to the Internet directly, the NIS+ client machines can be
connected to the Internet using the /etc/irs.conf and /etc/netsvc.conf configuration files and the
NSORDER system environment variable.
Server Configuration
The NIS+ client-server arrangement is similar to those of NIS and DNS in that each domain is supported
by a set of servers. The main server is called the master server, and the backup servers are called
replicas. Both master and replica servers run NIS+ server software and both maintain copies of NIS+
tables.
However, NIS+ uses a different update model from the one used by NIS. At the time NIS was developed,
it was assumed that most of the information NIS would store would be static. NIS updates are handled
manually, and its maps have to be remade and propagated in full every time any information in the map
changes.
NIS+, however, accepts incremental updates to the replicas. Changes must still be made to the master
database on the master server, but once made, they are automatically propagated to the replica servers.
You do not have to ″make″ any maps or wait for propagation. Propagation now takes only a matter of
minutes.
Information Management
NIS+ stores information in tables instead of maps or zone files. NIS+ provides predefined, or system,
tables, each of which stores a different type of information. For instance, the hosts table stores
information about workstation addresses, while the passwd table stores information about users of the
network. (Details about each table are provided in Appendix A, “Information in NIS+ Tables”, on page 231.)
The master server stores the original tables, and the replicas store copies.
NIS+ tables are not ASCII files, but are tables in the NIS+ relational database. You can view and edit their
contents only by using the “Using NIS+ Commands” on page 9.
An NIS+ table can be searched by any searchable column, not just by the first column (sometimes
referred to as the key). This eliminates the need for duplicate maps, such as the hosts.byname and
hosts.byaddr maps used by NIS. (To know whether a particular column is searchable, run the niscat -o
command on a table. The command returns a list of the table’s columns and their attributes, one of which
is whether a column is searchable.)
Also, the information in NIS+ tables has access controls at three levels: the table level, the entry (row)
level, and the column level. NIS+ tables—and the information stored in them—are described in “NIS+
Tables and Information” on page 82.
NIS maps are located on the server in /var/yp/domainname, whereas NIS+ directories are located in
/var/nis/data. The NIS+ tables are contained in the database. The tables’ information is loaded into
memory as requests are made to the database. Keeping data in memory in the order requested minimizes
calls to the disk, thereby improving request-response time.
Another improvement is that NIS+ uses a different updating model from the one used by NIS. At the time
NIS was developed, the type of information it stored would change infrequently, NIS was developed with
Chapter 1. Introduction to Name Services 7