The NIS+ server daemon, rpc.nisd, stores NIS+ data in proprietary-format files in the /var/nis/data directory. While it is entirely possible to keep NIS+ data synchronized with LDAP, such synchronization has previously required an external agent. However, the NIS+ daemon now enables you to use an LDAP server as a data repository for NIS+ data. Since this makes it possible for NIS+ and LDAP clients to share the same naming service information, it is easier to transition from using NIS+ as the main naming service, to using LDAP for the same role.
By default, the rpc.nisd daemon continues to work as before, relying only on the/var/nis/data NIS+ database. If desired, the system administrator can choose to use an LDAP server as the authoritative data repository for any subset of the NIS+ database. In this case, the /var/nis/data files serve as a cache for the rpc.nisd daemon, reducing LDAP lookup traffic, and enabling the rpc.nisd to continue working if the LDAP server is temporarily unavailable. In addition to continuous synchronization between NIS+ and LDAP, you can also perform uploads of NIS+ data to LDAP, or downloads of LDAP data to NIS+.
Mapping of data to and from LDAP is controlled by a flexible configuration file syntax. (All standard NIS+ tables (except for client_info.org_dir and timezone.org_dir) are covered by a template mapping file, /var/nis/NIS+LDAPmapping.template), which should require little or no change for most NIS+ installations. (See client_info and timezone Tables (NIS+ to LDAP) for information on client_info.org_dir and timezone.org_dir .) In addition to locations for NIS+ data in the LDAP Directory Information Tree (DIT), the mapping file also allows establishing time-to-live (TTL) for NIS+ data sourced from LDAP. While there often is a one-to-one mapping between NIS+ column values and LDAP attribute values, the mapping file can be used to maintain more complicated relationships as well.
The /etc/default/rpc.nisd file is used to select LDAP server and authentication, and controls some general rpc.nisd behavior. See rpc.nisd(4). The details of the mapping are specified in the /var/nis/NIS+LDAPmapping file. For more information, see NIS+LDAPmapping(4). The name of the mapping file can be changed by editing the /lib/svc/method/nisplus file. See NIS+ to LDAP Tools and the Service Management Facility for more information.
The following terms are used in this chapter.
A container is the location in the LDAP DIT where all related entries are stored. For example, user account information is often stored in the ou=People container, while host address information can be stored in the ou=Hosts container.
A netname is an entity in secure RPC (user or machine) that can be authenticated.
Mapping is the relationship between an NIS+ object and an LDAP entry. For example, data from the name column in the passwd.org_dir NIS+ table (such as the user name of an account) corresponds to the LDAP uid attribute of the posixAccount object class in the ou=People container. The configuration can establish a mapping between the name column and the uid attribute. You can also say that the name column is mapped to the uid attribute (or vice versa).
A principal is an entity in NIS+ (user or machine) that can be authenticated. Usually, there is a one-to–one correspondence between netnames and principal names.
This file contains information regarding the LDAP server and authentication, the NIS+ base domain, the LDAP default search base, exception processing, and general rpc.nisd configuration, which applies whether or not LDAP mapping is in effect.
This file contains information on mapping of NIS+ data to and from LDAP. The template file (/var/nis/NIS+LDAPmapping.template) covers all standard NIS+ objects, except client_info.org_dir and timezone.org_dir. See client_info and timezone Tables (NIS+ to LDAP) and NIS+LDAPmapping(4).
Configuration is done by assigning values to pre-defined attributes. In addition to the configuration files, the configuration attributes can also be read from LDAP (see Storing Configuration Information in LDAP) or can be specified on the rpc.nisd command line by way of the -x option. If the same attribute is specified in more than one place, the priority order is (from higher to lower) as follows.
rpc.nisd -x option
Most of the command line administrative tasks associated with the NIS+ to LDAP transition are managed by 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.
Administrative actions on the NIS+ to LDAP transition service, such as enabling, disabling, or restarting, can be performed using the svcadm command.
Temporarily disabling a service by using the -t option provides some protection for the service configuration. If the service is disabled with the -t option, the original settings would be restored for the service after a reboot. If the service is disabled without -t, the service will remain disabled after reboot.
The NIS+ Fault Managed Resource Identifier (FMRI) is svc:/network/rpc/nisplus:<instance>. The FMRI for the LDAP client service is svc:/network/ldap/client:<instance>.
You can query the status of NIS+ by using the svcs command.
Example of svcs command and output.
# svcs \*nisplus\* STATE STIME FMRI online Sep_01 svc:/network/rpc/nisplus:default
Example of svcs -l command and output. To get the output shown below, you must use the instance name in the FMRI.
# svcs -l network/rpc/nisplus:default fmri svc:/network/rpc/nisplus:default enabled false state disabled next_state none restarter svc:/system/svc/restarter:default dependency require_all/none svc:/network/rpc/keyserv (online)
You can check a daemon's presence by using the ps command.
# ps -e | grep rpc.nisd root 23320 1 0 Aug 27 ? 16:30 ./ns-slapd -D \ /usr/iplanet/ds5/slapd-lastrev -i /usr/iplanet/ds5/slapd-lastrev/ root 25367 25353 0 15:35:19 pts/1 0:00 grep slapd
Do not use the -f option with ps because this option attempts to translate user IDs to names, which causes more naming service lookups that might not succeed.
In general, the /usr/sbin/rpc.nisd daemon is administered using the svcadm command. However, when rpc.nisd is invoked with -x nisplusLDAPinitialUpdateOnly=yes, rpc.nisd performs the specified initial update action, then exits. That is, rpc.nisd does not daemonize. The Service Management Facility should not be used in conjunction with -x nisplusLDAPinitialUpdateOnly=yes. SMF can be used any other time you want to start, stop, or restart the rpc.nisd daemon.
The following example shows rpc.nisd used with -x nisplusLDAPinitialUpdateOnly=yes.
# /usr/sbin/rpc.nisd -m mappingfile \ -x nisplusLDAPinitialUpdateAction=from_ldap \ -x nisplusLDAPinitialUpdateOnly=yes
If you want to include specific options when you invoke the rpc.nisd daemon with the Service Management Facility, you can use the svcprop command or modify the /lib/svc/method/nisplus file. See the svcprop(1) man page for more information about using the svcprop command. The following procedure describes how to modify the /lib/svc/method/nisplus file.
Become superuser or assume an equivalent role.
Roles contain authorizations and privileged commands. For more information about roles, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services.
Stop the NIS+ service.
# svcadm disable network/rpc/nisplus:default
Open the /lib/svc/method/nisplus file.
Use the editor of your choice.
Edit the file to add the desired options.
if [ -d /var/nis/data -o -d /var/nis/$hostname ]; then /usr/sbin/rpc.nisd || exit $
if [ -d /var/nis/data -o -d /var/nis/$hostname ]; then /usr/sbin/rpc.nisd -Y -B || exit $?
In this example, the -Y and -B options are added to rpc.nisd, so the options are automatically implemented at startup.
Save and quit the /lib/svc/method/nisplus file.
Start the NIS+ service.
# svcadm enable network/rpc/nisplus:default
Depending on how you configure the NIS+/LDAP mapping, you might need to create a number of new LDAP attributes and object classes. The examples show how to do this by specifying LDIF data that can be used as input to the ldapadd command. Create a file containing the LDIF data, and then invoke ldapadd(1).
# ldapadd -D bind-DN -f ldif -file
This method works with Sun Java System Directory Server, and might work with other LDAP servers as well.
Except for the defaultSearchBase, preferredServerList, and authenticationMethod attributes, as well as the SYNTAX specifications, the object identifiers (OIDs) used in this chapter are intended for illustration only. As no official OIDs have been assigned, you are free to use any suitable OIDs.