Chapter 26

Transitioning from NIS to NIS+

This chapter introduces the issues involved in converting from the NIS naming service to the NIS+ naming service. It describes the differences between the two name services and outlines a suggested transition process.

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.

Differences Between NIS and NIS+

NIS and NIS+ have several differences with an impact on a transition. For example, 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 only an upgrade to NIS but is 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 the following.

Domain structure.
Interoperability.
Server configuration.
Information management.
Security.

Domain Structure

NIS+ is not only 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 hierarchical NIS+ 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 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 26-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 "Domains".

DNS, NIS, and NIS+ 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 in the Solaris operating environment 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.

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. DNS request forwarding for NIS+ client machines is controlled by the /etc/resolv.conf and /etc/nsswitch.conf files' configurations. See Chapter 1, The Name Service Switch for more information.

Authorized NIS+ administrators can use the passwd command to perform the full range of password-related administrative tasks, including password aging and locking. NIS+ client users can use the passwd command to change their own passwords.

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 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 responds and answers the request. The NIS+ API (Application Programming Interface) returns an error message to the application when this situation occurs.

In the Solaris 2.3 release, the NIS-compatibility mode supports DNS forwarding. In the Solaris 2.2 release, support for DNS forwarding is available as a patch (patch #101022-06). 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 (/etc/nsswitch.conf) 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 fully propagated 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 hours for propagation. Propagation now takes a matter of minutes.

Information Management

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

Figure 26-2 NIS+ Standard Tables

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 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 which is whether a column is searchable. This search 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/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.

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 machine) that sent a particular request. Authorization is the process by which a server identifies the access rights granted to that principal, whether a client machine or client user.

In other words, before users can access anything in the namespace, they must be authenticated NIS+ clients and they must have the proper permission to access that information. 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 edited directly.

Suggested Transition Phases

The following outline is a suggested NIS-to-NIS+ transition:

Review basic transition principles.
Become familiar with NIS+.
Design your final NIS+ namespace.
Select security measures.
Decide how to use NIS-compatibility mode.
Complete prerequisites to transition.
Implement the transition.

The remainder of this chapter is a detailed discussion of these transition phases.


	Chapter 26 Transitioning from NIS to NIS+ This chapter introduces the issues involved in converting from the NIS naming service to the NIS+ naming service. It describes the differences between the two name services and outlines a suggested transition process. 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`. Differences Between NIS and NIS+ NIS and NIS+ have several differences with an impact on a transition. For example, 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 only an upgrade to NIS but is 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 the following. Domain structure. Interoperability. Server configuration. Information management. Security. Domain Structure NIS+ is not only 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 hierarchical NIS+ 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 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 26-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 "Domains". DNS, NIS, and NIS+ 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 in the Solaris operating environment 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. 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. DNS request forwarding for NIS+ client machines is controlled by the `/etc/resolv.conf` and `/etc/nsswitch.conf` files' configurations. See Chapter 1, The Name Service Switch for more information. Authorized NIS+ administrators can use the `passwd` command to perform the full range of password-related administrative tasks, including password aging and locking. NIS+ client users can use the `passwd` command to change their own passwords. 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 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 responds and answers the request. The NIS+ API (Application Programming Interface) returns an error message to the application when this situation occurs. In the Solaris 2.3 release, the NIS-compatibility mode supports DNS forwarding. In the Solaris 2.2 release, support for DNS forwarding is available as a patch (patch `#101022-06`). 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 `(/etc/nsswitch.conf`) 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 fully propagated 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 hours for propagation. Propagation now takes a matter of minutes. Information Management NIS+ stores information in tables instead of maps or zone files. NIS+ provides 17 types of predefined or system tables, as shown in Figure 26-2. Figure 26-2 NIS+ Standard Tables 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 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 which is whether a column is searchable. This search 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/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. 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 machine) that sent a particular request. Authorization is the process by which a server identifies the access rights granted to that principal, whether a client machine or client user. In other words, before users can access anything in the namespace, they must be authenticated NIS+ clients and they must have the proper permission to access that information. 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 edited directly. Suggested Transition Phases The following outline is a suggested NIS-to-NIS+ transition: Review basic transition principles. Become familiar with NIS+. Design your final NIS+ namespace. Select security measures. Decide how to use NIS-compatibility mode. Complete prerequisites to transition. Implement the transition. The remainder of this chapter is a detailed discussion of these transition phases.