nisplusLDAPattributeFromColumn
nisplusLDAPattributeFromColumn specifies the rules used to map NIS+ data to LDAP. Mapping rules for the other direction is controlled by nisplusLDAPcolumnFromAttribute.
nisplusLDAPcolumnFromAttribute
nisplusLDAPcolumnFromAttribute specifies the rules used to map LDAP data to NIS+.
The full entry mapping syntax can be found on NIS+LDAPmapping(4). However, a few examples should make things clearer.
The NIS+ rpc.org_dir table contains four columns called cname, name, numbe, and comment. Therefore, the entries for the NIS+ RPC program number (100300) with the canonical name nisd and the aliases rpc.nisd and nisplusd could be represented by the following NIS+ entries in rpc.org_dir.
nisd nisd 100300 NIS+ server nisd rpc.nisd 100300 NIS+ server nisd nisplusd 100300 NIS+ server |
Assuming the defaultSearchBase value is dc=some,dc=domain, the corresponding LDAP entry, as listed by ldapsearch(1), would be the following.
cn=nisd,ou=Ppc,dc=some,dc=domain cn=nisd cn=rpc.nsid cn=nisplusd oncrocnumber=100300 description=NIS+ server objectclass=oncRpc objectclass=top |
This makes for a simple one-to-one mapping between NIS+ and LDAP data, and the corresponding mapping attribute value going from NIS+ to LDAP is the following.
nisplusLDAPattributeFromColumn \
rpc: dn=("cn=%s,", name), \
cn=cname, \
cn=name, \
oncRpcNumber=number, \
description=comment
|
This constructs the DN for the entry to be cn=%s, with the value of the cname column substituted for %s.
cn=nisd, |
Since the value ends in a comma, the read base value from the nisplusObjectDN is appended, and you have the following.
cn=nisd,ou=Rpc,dc=some,dc=domain |
The oncRpcNumber and description attribute values are just simple assignments of the corresponding NIS+ column values. The rpc.nisd will collect the multiple NIS+ entries into one LDAP entry, with multiple cn values to represent the different name column values.
Similarly, the mapping from LDAP to NIS+ would be as follows.
nisplusLDAPcolumnFromAttribute \ rpc: cname=cn, \ (name)=(cn), \ number=oncRpcNumber, \ comment=description |
The above assigns the oncRpcNumber and description values to the corresponding NIS+ columns. The multi-valued cn (denoted by (cn)) is mapped to multiple name column values (denoted by (name)). Since the name column cannot be multi-valued, the rpc.nisd creates one NIS+ entry for each cn value.
Finally, the nisplusLDAPattributeFromColumn value is an example of rule sets used for deletion.
nisplusLDAPattributeFromColumn \
user_attr_del: dn=("uid=%s,", name), \
SolarisUserQualifier=, \
SolarisAttrReserved1=, \
SolarisAttrReserved2=, \
SolarisAttrKeyValue=
|
Again, the user_attr.org_dir data shares the ou=People container with other account information (from the passwd.org_dir and other tables). If an entry in the user_attr.org_dir table is deleted, you probably do not want to delete the entire ou=People entry. Instead, the delete entry above says that when a user_attr.org_dir entry is deleted, the SolarisUserQualifier, SolarisAttrReserved1, SolarisAttrReserved2, and SolarisAttrKeyValue attributes (if any) are deleted from the ou=People entry specified by the following rule.
dn=("uid=%s,", name)
|
The rest of the LDAP entry is left unchanged.
NIS+ to LDAP Migration Scenarios
Likely scenarios for a migration from NIS+ to LDAP include the following.
Convert all NIS+ clients to LDAP in one operation. You can use the rpc.nisd daemon to upload any NIS+ data that does not yet exist in LDAP. See "How to Convert All NIS+ Data to LDAP in One Operation".
Do a gradual migration from NIS+ to LDAP. Start by converting NIS+ data to LDAP (see "How to Convert All NIS+ Data to LDAP in One Operation"). You could have both NIS+ and LDAP clients sharing the same naming service data, and let the rpc.nisd automatically keep NIS+ and LDAP data synchronized. Initially, perhaps, NIS+ would be authoritative, and the LDAP server(s) would maintain a duplicate of the NIS+ data for the benefit of LDAP clients. At a convenient time, LDAP can become the authoritative naming service, and NIS+ service gradually phased out, until there are no more NIS+ clients.
LDAP is already used as a naming service, so you need to merge the NIS+ and LDAP data. There are three possible ways to perform this merge.
Add the NIS+ data to LDAP. Entries that exist in NIS+, but not in LDAP, are added to LDAP. Entries that appear both in NIS+ and LDAP, but with different data, end up with the NIS+ data. See "How to Convert All NIS+ Data to LDAP in One Operation".
Overwrite the NIS+ data with the LDAP data. If there are entries that exist in NIS+ but not in LDAP, they will disappear from NIS+. Entries that exist both in NIS+ and LDAP end up with the LDAP data. See "How to Convert All LDAP Data to NIS+ in One Operation".
Merge NIS+ and LDAP data, resolving conflicts on an individual basis. See "Merging NIS+ and LDAP Data".
How to Convert All NIS+ Data to LDAP in One Operation
Use the rpc.nisd to upload any NIS+ data that does not yet exist in LDAP.
Assuming all NIS+/LDAP data mappings have been established in the default location (/var/nis/NIS+LDAPmapping), use the following command.
# /usr/sbin/rpc.nisd -D \
--x nisplusLDAPinitialUpdateAction=to_ldap \
-x nisplusLDAPinitialUpdateOnly=yes
The above would make the rpc.nisd upload data to LDAP, and then exit. The NIS+ data would be unaffected by this operation.
See the nisplusLDAPinitialUpdateAction attribute on rpc.nisd(4).
How to Convert All LDAP Data to NIS+ in One Operation
Use the rpc.nisd to download all LDAP data to NIS+, overwriting existing NIS+ data.
Assuming all NIS+/LDAP data mappings have been established in the default location (/var/nis/NIS+LDAPmapping), use the following command.
# /usr/sbin/rpc.nisd -D \
-x nisplusLDAPinitialUpdateAction=from_ldap \
-x nisplusLDAPinitialUpdateOnly=yes
The above would make the rpc.nisd daemon download data from LDAP, and then exit. The LDAP data would be unaffected by this operation.
See the nisplusLDAPinitialUpdateAction attribute on rpc.nisd(4).