|Skip Navigation Links|
|Exit Print View|
|System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP)|
The NIS–to–LDAP transition service (N2L service) replaces existing NIS daemons on the NIS master server with NIS–to–LDAP transition daemons. The N2L service also creates an NIS–to–LDAP mapping file on that 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 9, LDAP 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:
The NIS and LDAP services are managed by the Service Management Facility. Administrative actions on these services, such as enabling, disabling, or restarting, can be performed by using the svcadm command. You can query the status of services by using the svcs command. For more information about using SMF with LDAP and NIS, see LDAP and the Service Management Facility and NIS and the Service Management Facility. For an overview of SMF, refer to Chapter 18, Managing Services (Overview), in System Administration Guide: Basic Administration. Also refer to the svcadm(1M) and svcs(1) man pages for more details.
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.
Chapter 4, Network Information Service (NIS) (Overview), for an overview of NIS
Chapter 8, Introduction to LDAP Naming Services (Overview/Reference), for an overview of LDAP
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.
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.
The following terms are related to the implementation of the N2L service.
Table 15-1 Terminology Related to the N2L Transition
There are two utilities, two configuration files, and a mapping that are associated with the N2L transition.
Table 15-2 Descriptions of N2L Commands, Files, and Maps
By default, the N2L service supports mappings between the following list of maps and RFC 2307, or its successors', LDAP entries. These standard maps do not require manual modification to the mapping file. Any maps on your system that are not in the following list are considered custom maps and require manual modification.
The N2L service also supports automatic mapping of the auto.* maps. However, since most auto.* file names and contents are specific to each network configuration, those files are not specified in this list. The exceptions to this are the auto.home and auto.master maps, which are supported as standard maps.
audit_user auth_attr auto.home auto.master bootparams ethers.byaddr ethers.byname exec_attr group.bygid group.byname group.adjunct.byname hosts.byaddr hosts.byname ipnodes.byaddr ipnodes.byname mail.byaddr mail.aliases netgroup netgroup.byprojid netgroup.byuser netgroup.byhost netid.byname netmasks.byaddr networks.byaddr networks.byname passwd.byname passwd.byuid passwd.adjunct.byname printers.conf.byname prof_attr project.byname project.byprojectid protocols.byname protocols.bynumber publickey.byname rpc.bynumber services.byname services.byservicename timezone.byname user_attr
During the NIS-to-LDAP transition, the yppasswdd daemon uses the N2L-specific map, ageing.byname, to read and write password aging information to the DIT. If you are not using password aging, then the ageing.byname mapping is ignored.