Sun Microsystems Logo
Products & Services
 
Support & Training
 
 

Previous Previous     Contents     Index     Next Next
Chapter 19

Transitioning From NIS to LDAP (Overview/Tasks)

This chapter describes how to enable support of NIS clients that use naming information stored in the LDAP directory. By following the procedures in this chapter, you can transition from using an NIS naming service to using LDAP naming services.

To determine the benefits of transitioning to LDAP, see LDAP Naming Services Compared to Other Naming Services.

The following information is included in this chapter.

NIS-to-LDAP Service Overview

Enabling the NIS-to-LDAP transition service (N2L service) requires reconfiguring the NIS daemons on the NIS master server. The N2L service is enabled if the daemons find a NIS-to-LDAP mapping file on the master server. The mapping file specifies the mapping between NIS map entries and equivalent Directory Information Tree (DIT) entries in LDAP. An NIS master server that has gone through this transition is referred to as an N2L server. The slave servers do not have an NISLDAPmapping file, so they continue to function in the usual manner. The slave servers periodically update their data from the N2L server as if it were a regular NIS master.

The behavior of the N2L service is controlled by the ypserv and NISLDAPmapping configuration files. A script, inityp2l, assists with the initial setup of these configuration files. Once the N2L server has been established, you can maintain N2L by directly editing the configuration files.

The N2L service supports the following:

  • Import of NIS maps into the LDAP Directory Information Tree (DIT)

  • Client access to DIT information with the speed and extensibility of NIS

In any naming system, only one source of information can be the authoritative source. In traditional NIS, NIS sources are the authoritative information. When using the N2L service, the source of authoritative data is the LDAP directory. The directory is managed by using directory management tools, as described in Chapter 13, Basic Components and Concepts (Overview).

NIS sources are retained for emergency backup or backout only. After using the N2L service, you can gradually phase out NIS clients. Eventually, all NIS clients can be replaced by Solaris LDAP naming services clients.

Additional overview information is provided in the following subsections:

N2L Audience Assumptions

You need to be familiar with NIS and LDAP concepts, terminology, and IDs to perform the procedures in this chapter. For more information about the NIS and LDAP naming services, see the following sections of this book.

When Not to Use the N2L Service

Do not use the N2L service in these situations:

  • In an environment where there is no plan to share data between NIS and LDAP naming services clients

    In such an environment, an N2L server would serve as an excessively complex NIS master server.

  • In an environment where NIS maps are managed by tools that modify the NIS source files (other than yppasswd)

    Regeneration of NIS sources from DIT maps is an imprecise task that requires manual checking of the resulting maps. Once the N2L service is used, regeneration of NIS sources is provided only for backout or reverting to NIS.

  • In an environment with no NIS clients

    In such an environment, use Solaris LDAP naming services clients and their corresponding tools.

Effects of the N2L Service on Users

Simply installing the files that are related to the N2L service does not change the NIS server's default behavior. At installation, the administrator will see some changes to NIS man pages and the addition of N2L helper scripts, inityp2l and ypmap2src, on the servers. But as long as inityp2l is not run or the N2L configuration files are not created manually on the NIS server, the NIS components continue to start in traditional NIS mode and function as usual.

After inityp2l is run, users see some changes in server and client behavior. Following is a list of NIS and LDAP user types and a description of what each type of user should notice after the N2L service is deployed.

User Type

Effect of N2L Service

NIS master server administrators

The NIS master server is converted to an N2L server. The NISLDAPmapping and ypserv configuration files are installed on the N2L server. After the N2L server is established, you can use LDAP commands to administer your naming information.

NIS slave server administrators

After the N2L transition, an NIS slave server continues to run NIS in the usual manner. The N2L server pushes updated NIS maps to the slave server when yppush is called by ypmake. See the ypmake(1M) man page.

NIS clients

NIS read operations are no different than traditional NIS. When a Solaris LDAP naming services client changes information in the DIT, the information is copied into the NIS maps. The copy operation is complete after a configurable timeout expires. Such behavior is similar to the behavior observed by a normal NIS client when the client is connected to an NIS slave server.

If an N2L server cannot bind to the LDAP server for a read, the N2L server returns the information from its own cached copy. Alternatively, the N2L server can return an internal server error. You can configure the N2L server to respond either way. See the ypserv(1M) man page for more details.

All users

When an NIS client makes a password change request, the change is immediately visible on the N2L master server and to native LDAP clients.

If you attempt to change a password on the NIS client, and the LDAP server is unavailable, then the change is refused and the N2L server returns an internal server error. This behavior prevents incorrect information from being written into the cache.

Previous Previous     Contents     Index     Next Next