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 the NIS 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 known 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. The inityp2l script assists the server with the initial setup of these configuration files. Once the N2L server has been established, you can edit the configuration file to maintain the N2L service.
The N2L service supports the following:
Import of NIS maps into the LDAP DIT
Client access to DIT information with the speed and extensibility of NIS
In the context of the N2L service, the term "map" is used in the following ways:
To refer to a database file in which NIS stores a specific type of information
To describe the process of mapping NIS information to or from the LDAP DIT
In any naming system, only one source of information can be the authoritative source. In traditional NIS, NIS sources are the authoritative information. When you use the N2L service, the source of authoritative data is the LDAP directory. The directory is managed by using directory management tools. For more information about directory management tools, see Introduction to the LDAP Naming Service.
NIS sources are retained for emergency backup or backout only. After you use the N2L service, you must phase out NIS clients. Eventually, all NIS clients should be replaced by LDAP naming service clients.
The Service Management Facility (SMF) manages the NIS and LDAP services. You can perform administrative actions on these services, such as enabling, disabling, or restarting, 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 in Working With Oracle Solaris 11.3 Directory and Naming Services: DNS and NIS. For information about SMF, refer to Managing System Services in Oracle Solaris 11.3. 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 service, see the following sections:
Chapter 5, About the Network Information Service in Working With Oracle Solaris 11.3 Directory and Naming Services: DNS and NIS, for an overview of NIS
Introduction to the LDAP Naming Service, for an overview of LDAP
Additional overview information is provided in the following sections:
The intent of the N2L service is to serve as a transition tool from using NIS to using LDAP. Do not use the N2L service in the following situations:
In an environment where you do not plan to share data between NIS and LDAP naming service 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 LDAP naming service clients and their corresponding tools.
Installing the files that are related to the N2L service does not change the NIS server's default behavior. While installing the N2L service, you may see some changes to the NIS man pages and the addition of N2L helper scripts, inityp2l and ypmap2src, on the servers. However, 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. The following table lists the NIS and LDAP user types and a description of what each type of user should notice after the N2L service is deployed.
|
This section describes the utilities, configuration files, and mapping associated with the N2L transition.
The N2L transition uses the following utilities:
/usr/lib/netsvc/yp/inityp2l – Assists with the creation of the NISLDAPmapping and ypserv configuration files but not the management of these files. If you are familiar with the technologies, you can maintain the N2L configuration files or create custom mappings by using a text editor to examine and customize the inityp2l output. For more information, see the inityp2l(1M) man page.
/usr/lib/netsvc/yp/ypmap2src – Converts standard NIS maps to approximations of the equivalent NIS source files. You can use the ypmap2src utility to convert from an N2L transition server to traditional NIS. For more information, see the ypmap2src(1M) man page.
The N2L service uses the following files to transition from NIS to LDAP:
/var/yp/NISLDAPmapping – Specifies the mapping between NIS map entries and equivalent DIT entries in LDAP. See the NISLDAPmapping(4) man page.
/var/yp/ypserv – Specifies configuration information for the NIS-to-LDAP transition daemons. For more information, see the ypserv(4) man page.
When the NIS-to-LDAP transition is implemented, the yppasswdd command uses the ageing.byname mapping to read and write password aging information to the DIT.
By default, the N2L service supports mappings between its standard maps and LDAP entries based on RFC 2307, RFC 2307bis, and later standards. Standard maps do not require manual modification of the mapping file. Any maps on your system that are not standard N2L service maps are considered custom maps and require manual modification.
The N2L service also supports automatic mapping of the auto.* maps. However, because most auto.* file names and contents are specific to each network configuration, those files are not specified in the list of standard maps. The exceptions are the auto.home and auto.master maps, which are supported as standard maps.
The N2L service supports the following 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 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 ageing.byname map to read and write password aging information to the DIT. If you are not using password aging, then the ageing.byname mapping is ignored.