Differences Between NIS and NIS+

NIS and NIS+ have several differences that have an impact on a transition. For instance, NIS uses a flat, non-hierarchical namespace with only one domain (or several disconnected domains), while NIS+ provides a domain hierarchy similar to that of DNS. This means that before you can convert to NIS+, you must design the NIS+ namespace. NIS+ also provides security, which limits access not only to the information in the namespace but also to the structural components of the namespace.

These and other differences demonstrate that NIS+ is not simply an upgrade to NIS, but an entirely new product. Therefore, the transition from NIS to NIS+ is largely directed by the differences between the products.

These differences are described in broad terms in the remainder of this chapter. Understanding them is critical to a successful transition to NIS+. They are:

• Domain structure
• Interoperability

• Server configuration
• Information management
• Security

Domain Structure

NIS+ is not simply an upgrade to NIS; it is designed to replace NIS. This becomes evident when you examine its domain structure. NIS domains are flat and lack the ability to have a hierarchy. NIS+ domains may be flat, but you can also construct NIS+ hierarchical domains. Such hierarchies consist of a root domain with an infinite number of subdomains under them.

The NIS domain structure addressed the administration requirements of client-server computing networks prevalent in the 1980s; in other words, client-server networks with a few hundred clients and a few multipurpose servers.

NIS+ is designed to support networks with 100 to 10,000 multivendor clients supported by 10 to 100 specialized servers located in sites throughout the world, connected to several "untrusted" public networks. The size and complexity of these networks requires new, autonomous administration practices. The NIS+ domain structure was designed to address these requirements. It consists of hierarchical domains similar to those of DNS, as shown in the following diagram:

Figure 1-1 NIS+ Domains

Hierarchical domains allow NIS+ to be used in a range of networks, from small to very large. They also allow the NIS+ service to adapt to the growth of an organization. The NIS+ domain structure is thoroughly described in the Name Services Configuration Guide.

Interoperability

NIS+ provides interoperability features designed for upgrading from NIS and for continuing the interaction with DNS originally provided by the NIS service.

To help convert from NIS, NIS+ provides an NIS-compatibility mode and an information transfer utility. The NIS-compatibility mode enables an NIS+ server running Solaris 2.x software to answer requests from NIS clients while continuing to answer requests from NIS+ clients. The information transfer utility helps administrators keep NIS maps and NIS+ tables synchronized.

NIS-compatibility mode requires slightly different setup procedures than those used for a standard NIS+ server. Also, NIS-compatibility mode has security implications for tables in the NIS+ namespace. These differences and implications are described in Name Services Configuration Guide.

NIS client machines interact with the NIS+ namespace differently from NIS+ client machines when NIS+ servers are running in NIS-compatibility mode. The differences are:

• NIS client machines cannot follow NIS+ table paths or links, or do read operations in other domains.
• NIS client machines can have their unsatisfied host requests forwarded to DNS if you run rpc.nisd with the -Y -B options, but the NIS+ server will not forward these requests for an NIS+ client. The forwarding of NIS+ client machines' DNS requests is controlled by the resolv.conf and nsswitch.conf files' configurations. See Name Services Configuration Guide for more information.
• Authorized NIS+ client users can update entries in the namespace and perform operations such as updating the password with the nispasswd command, and changing their secure-RPC credentials with the chkey command. NIS client users cannot make any updates directly to NIS+ servers running in NIS-compatibility mode. For example, you cannot use yppasswd to update a password in the NIS+ password table. You have to use nispasswd to update a password in the NIS+ password table. Since you cannot run nispasswd on an NIS client, the command must be run on the NIS+ server.

• Even if all the servers on a local subnet no longer respond, the NIS+ client machines can still have their name service calls answered if they can contact any of the replicas of that domain. NIS client machines do not have access to information on the network outside their subnet unless the server names have been set with ypset, or for Solaris 2.x NIS clients only, with ypinit.
• 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.
• Under NIS, if the server is no longer responding, the NIS yp_match() call continues to retry this call until the server starts responding and answers the request. The NIS+ API (application program interface) will return an error message to the application when this situation occurs.

In the Solaris 2.3 and later releases, the NIS-compatibility mode supports DNS forwarding. In the Solaris 2.2 release, support for DNS forwarding is available as a patch. The DNS forwarding patch is not available in the Solaris 2.0 and 2.1 releases.

Although an NIS+ domain cannot be connected to the Internet directly, the NIS+ client machines can be connected to the Internet with the name service switch. The client can set up its switch configuration file to search for information in either DNS zone files or NIS maps--in addition to NIS+ tables.

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 an update model that is completely different 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 don't have to "make" any maps or wait hours for propagation. Propagation is now a matter of minutes, perhaps as much as 200 seconds.

Information Management

NIS+ stores information in tables instead of maps or zone files. NIS+ provides 17 types of predefined, or system, table as is shown in Figure 1-2:

Figure 1-2 NIS+ Standard Tables

NIS+ tables are not ASCII files, but are tables in the NIS+ relational database. You can only view and edit their contents by using the NIS+ commands.

NIS+ tables provide two major improvements over the maps used by NIS. First, an NIS+ table can be searched by any searchable column, not just the first column (sometimes referred to as the "key"). 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 the which is whether a column is searchable. This searching ability eliminates the need for duplicate maps, such as the hosts.byname and hosts.byaddr maps used by NIS. Second, the information in NIS+ tables has access controls at three levels: the table level, the entry (row) level, and the column level.

NIS maps are located on the server in /var/yp/domainname, whereas NIS+ directories are located in /var/nis/machinename. 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.

Security

The security features of NIS+ protect the information in the namespace and the structure of the namespace itself from unauthorized access. NIS+ security is provided by two means: authentication and authorization. Authentication is the process by which an NIS+ server identifies the NIS+ principal (a client user or client workstation) that sent a particular request. Authorization is the process by which a server identifies the access rights granted to that principal, be it a client machine or client user.

In other words, before someone can access anything in the namespace, they must be an authenticated NIS+ client and they must have the proper permission to access that information if the highest level of NIS+ security has been implemented at a site. Furthermore, requests for access to the namespace are only honored if they are made either through NIS+ client library routines or NIS+ administration commands. The NIS+ tables and structures cannot be directly edited.

Suggested Transition Process

Following is a suggested transition process:

1. Identify major transition goals.

2. Become familiar with NIS+.

3. Design your final NIS+ namespace.

4. Select security measures.

5. Decide how to use NIS-compatibility mode.

6. Complete prerequisites to transition.

7. Implement the transition.

Identify Major Transition Goals

Before you begin the transition, you might find it helpful to state the goals of your site's transition before you begin. Here are some typical goals:

Consider the Alternatives to Making the Transition Immediately You can defer the upgrade to NIS+ until after your site has completed its transition to the Solaris 2.x release. This would allow you to focus your resources on one transition effort at a time. Use the binary-compatibility mode Name Service kit to continue running NIS after you upgrade to the Solaris 2.x release. It is a much better solution than running NIS+ with the Solaris 1.x release.

Upgrading to NIS+ before upgrading to the Solaris 2.x release is possible but definitely not recommended. There are Solaris 1.x NIS+ binaries. These binaries were developed to enable sites to upgrade their network information service when they were unable to upgrade their servers to the Solaris 2.x release. There is no client-side NIS+ support for the Solaris 1.x release.

Keep Things Simple You can take several steps to simplify the transition. While these steps will diminish the effectiveness of NIS+, they will consume fewer servers and less administrative time. Once the transition is complete, you can change the NIS+ setup to completely suit your needs. Here are some suggestions:

• Don't change domain names.
• Don't use any hierarchies, keep a flat NIS+ namespace.
• Use the NIS-compatibility features.
• Use default tables and directory structures.
• Don't establish credentials for clients.

Use a Single Release of Software Decide which version of the Solaris 2.x software and NIS+ you will use for the transition. Since there are slight differences between versions, using multiple versions would complicate the transition process needlessly. Choose one version of the Solaris product and use its corresponding version of NIS+.

The current release has the most features (such as setup scripts). Make sure you compile a list of the SunOS patches that are required for normal operation, and make sure that all servers and clients have the same patches loaded.

Minimize Impact on Client Users This goal implies two major considerations. First, users should not notice any change in service. Second, the transition phase itself should cause minimal disruption to client users. To ensure the second consideration, be sure the administrators responsible for each domain migrate their client machines to NIS+, rather than ask the users to implement the migration. This ensures the proper procedures are implemented, the procedures are consistent across client machines, and irregularities can be dealt with immediately by the administrator.

Miscellaneous "Don'ts"

• Don't change the name services currently provided by NIS or the way NIS functions.
• Don't change the structure of DNS.
• Don't change the IP network topology.
• Don't upgrade applications that use NIS to NIS+; leave the migration to NIS+ APIs for the future.
• Don't consider additional uses for NIS+ during the implementation phase; add them later.

Become Familiar With NIS+

Familiarize yourself with NIS+, particularly with the concepts summarized earlier in this chapter and discussed in the remainder of this book. For details, see the following sources of information:

• Name Services Configuration Guide - Describes the structure of NIS+ objects, provides planning guidelines, complete setup instructions, task-oriented descriptions of NIS+ administrative commands, and how to use the NIS+ scripts, which help you set up an NIS+ namespace more easily and quickly than using the individual NIS+ administrative commands.
• Name Services Administration Guide - Describes how to administer a running NIS+ namespace and how to customize your namespace.
• Network Interfaces Programmer's Guide - Describes the functions of the NIS+ API.
• NIS+ man pages in man Pages(1M): System Administration Commands - Describes all the NIS+ commands and their syntax.

One of the best ways to become familiar with NIS+ is to build a prototype namespace. There is no substitute for hands-on experience with the product; administrators need the opportunity to practice in a forgiving test environment.

---

Note - Do not use your prototype domain as the basis for your actual running NIS+ namespace. Deleting your prototype when you have learned all you can from it will avoid namespace configuration problems. Start anew to create the real namespace after following all the planning steps.

---

When you create the test domain(s), make small, manageable domains. For guidance, you can use Name Services Configuration Guide and Name Services Administration Guide. Name Services Configuration Guide shows you how to create a simple test domain and subdomain with or without NIS-compatibility mode set using the NIS+ scripts. The NIS+ scripts, which are only available starting with the Solaris 2.3 release, spare you the trouble of typing each individual NIS+ command when you are performing such tasks as setting up an NIS+ server. It also includes all the planning information you need to know before you make the transition to your real NIS+ namespace.

Design Your Final NIS+ Namespace

Design the final NIS+ namespace, following the guidelines in Chapter 2, "Designing the NIS+ Namespace." While designing the namespace, do not worry about limitations imposed by the transition from NIS. You can add those later, once you know what your final NIS+ goal is.

Select Security Measures

NIS+ security measures provide a great benefit to users and administrators, but they require additional knowledge and setup steps on the part of both users and administrators. They also require several planning decisions. Chapter 3, "Selecting NIS+ Security Measures" describes the implications of NIS+ security and the decisions you need to make for using it in your NIS+ namespace.

Decide How to Use NIS-Compatibility Mode

The use of parallel NIS and NIS+ namespaces is virtually unavoidable during a transition. Because of the additional resources required for parallel namespaces, try to develop a transition sequence that reduces the amount of time your site uses dual services or the extent of dual services within the namespace (for example, convert as many domains as possible to NIS+ only).

Chapter 4, "Using NIS-Compatibility Mode" explains the transition issues associated with the NIS-compatibility mode and suggests a way to make the transition from NIS, through NIS compatibility, to NIS+ alone.

Complete Prerequisites to Transition

In addition to all these planning decisions mentioned above, you must complete several miscellaneous prerequisites, as described in Chapter 5, "Prerequisites to Transition."

Implement the Transition

Chapter 6, "Implementing the Transition" provides a suggested series of steps to implement the transition you have planned in the previous steps.