Adding New Object Mappings (NIS+ to LDAP)
The template mapping file, /var/nis/NIS+LDAPmapping.template, contains mapping information for all standard NIS+
objects. In order to support mapping of site or application specific objects, you
will need to add new mapping entries. This is a simple task for
non-entry (that is, directory, group, link, or table) objects, but can become complex
for entry objects, if the LDAP organization of the corresponding entry data differs greatly
from that used by NIS+. The following example shows the simple case.
How to Map Non-Entry Objects
- Find the fully qualified name of the object to be mapped.
If this name resides under the domain name specified by the nisplusLDAPbaseDomain attribute,
you can omit the portion that equals the nisplusLDAPbaseDomain value.
For example, if nisplusLDAPbaseDomain has the value some.domain., and the object to
be mapped is a table called nodeinfo.some.domain., the object name can be
shortened to nodeinfo.
- Invent a database id to identify the object.
The database id must be unique for the mapping configuration used, but is
not otherwise interpreted. It does not show up in the LDAP data. In
order to reduce confusion with entry object mappings, create a database id identifying
the table object proper (not the table entries) using an explanatory string like
_table at the end.
For this example, use the database id nodeinfo_table, and establish the connection between
the database id and the object in the standard mapping file location (/var/nis/NIS+LDAPmapping) by
adding the following.
Assuming that nisplusLDAPbaseDomain is some.domain., the following would also work.
- Decide on a TTL for the object.
This is the time during which the rpc.nisd daemon regards its local copy
of the object as valid. When the TTL expires, the next reference to
the object will initiate an LDAP lookup to refresh the object.
There are two different TTL values. The first is set when the
rpc.nisd daemon first loads the object from disk (after a reboot or
restart), and the second pertains to all refreshes from LDAP. The first TTL
is selected randomly from a configured range. For example, if nodeinfo_table should be valid
for a period of between one and three hours following initial load, and
for twelve hours thereafter, specify the following.
- Decide where the object data should be stored in LDAP.
The template mapping file suggests putting non-entry object data in the ou=nisPlus container.
If you use this scheme, and have not yet created the appropriate
attribute, object class, and container, see Mapping NIS+ Objects Other Than Table Entries.
For example, assume you want to store the nodeinfo object in the ou=nisPlus,dc=some,dc=domain
container, and that the LDAP entry should have the cn nodeinfo. Create the following nisplusLDAPobjectDN.
Since NIS+ replicas do not write data to LDAP, you can use
the nisplusLDAPobjectDN above for both master and replicas.
- (Skip this step if the NIS+ object to be mapped has not yet
been created in NIS+.) Store the object data in LDAP. You could use
the rpc.nisd daemon for this purpose, but it is easier to use the
nisldapmaptest(1M) utility, as you can leave the rpc.nisd daemon running.
# nisldapmaptest -m /var/nis/NIS+LDAPmapping -o -t nodeinfo -r
The -o option specifies the table object itself, not the table entries.
- Verify that the object data is stored in LDAP. (This example assumes the
LDAP server is running on the local machine at port 389.)
# ldapsearch -b ou=nisPlus,dc=some,dc=domain cn=nodeinfo
The output would appear similar to the following.
nisplusobject=<base 64 encoded data>
- Restart the NIS+ service.
The service will start by using the new mapping information. Do not forget
to edit the /lib/svc/method/nisplus file to add the -m and -Y options, or
use the svcprop command, as appropriate. See NIS+ to LDAP Tools and the Service Management Facility for more information.
# svcadm restart network/rpc/nisplus:default
Adding Entry Objects
NIS+LDAPmapping(4) specifies the syntax and semantics of table entry mapping in detail, and
also provides examples that show how to use each syntactic element. However, the
simplest and least error-prone approach is usually to identify an already existing mapping
that is similar to what you want to do, and then copy and
modify that existing mapping.
For example, assume that you have an NIS+ table called nodeinfo, which is
used to store inventory and owner information for nodes. Assume that the NIS+
table was created by the following command.
# nistbladm -c -D access=og=rmcd,nw=r -s : nodeinfo_tbl \
cname=S inventory=S owner= nodeinfo.`domainname`.
The cname column is expected to contain the canonical name of the node.
In other words, the same value as that of the cname column in
the hosts.org_dir table for the node.
Also assume that the corresponding information is kept in the ou=Hosts container
in LDAP, and that the nodeInfo object class (which is an invention for
this example, and is not defined in any RFC) has cn as a
MUST attribute, and that nodeInventory and nodeOwner are MAY attributes.
In order to upload existing nodeinfo data to LDAP, it will be convenient
to create the new mapping attributes in a separate file. You could, for
example, use /var/nis/tmpmapping.
Create a database id that identifies the NIS+ table to be mapped.
Set the TTL for entries in the nodeinfo table. Since the information is expected to change only rarely, use a twelve hour TTL. When the rpc.nisd daemon first loads the nodeinfo table from disk, the TTLs for entries in the table are randomly selected to be between six and twelve hours.
Identify an existing mapping that has similar properties to the one you want to create. In this example, mapping the attribute values is trivial (straight assignment). Instead, the complication is that you store the LDAP data in an existing container, so that you have to be careful during removal of the nodeinfo data. You do not want to remove the entire ou=Hosts entry, just the nodeInventory and nodeOwner attributes. You will need a special deletion rule set for this purpose.
To summarize, you are looking for a mapping that shares a container, and has a delete rule set. One possible candidate is the netmasks mapping, which shares the ou=Networks container, and does have a delete rule set.
The template netmasks mapping has the default mapping (from /var/nis/NIS+LDAPmapping.template) as follows.
Transferred to the new mapping for nodeinfo, the database id should be nodeinfo, the container ou=Hosts, and the object class nodeInfo. Thus, the first line of the nodeinfo mapping becomes the following.
The second line in the netmasks mapping is the part of the search filter that selects only those ou=Networks entries that contain the ipNetMaskNumber attribute. In this example, select the ou=Hosts entries that have the following nodeInventory attribute.
The third and fourth lines are the write portion of the nisplusLDAPobjectDN, and they specify where in LDAP nodeinfo data is written, as well as the rule set that is used when nodeinfo data is deleted. In this case, create a delete rule set identified by the database id nodeinfo_del. Because you are always writing to an existing entry in ou=Hosts, you only need to specify the object class for the nodeinfo data proper as follows.
Putting it all together, our nisplusLDAPobjectDN is the following.
Create the rule set that maps nodeinfo data from NIS+ to LDAP. The template (from netmasks) is the following.
netmasks: dn=("ipNetworkNumber=%s,", addr), \
The ou=Hosts container has an additional complication in this case, as RFC 2307 specifies the dn should contain the IP address. However, the IP address is not stored in the nodeinfo table, so you must obtain it in another manner. Fortunately, the crednode mapping in the template file shows how to obtain the IP address.
crednode: dn=("cn=%s+ipHostNumber=%s,", \
(cname, "%s.*"), \
ldap:ipHostNumber:?one?("cn=%s", (cname, "%s.*"))), \
Thus, you can copy that portion of the crednode mapping. In this case, however, the cname column value is the actual host name (not the principal name), so you do not need to extract just a portion of the cname. Making the obvious substitutions of attribute and column names, the nodeinfo mapping becomes the following.
nodeinfo: dn=("cn=%s+ipHostNumber=%s,", cname, \
ldap:ipHostNumber:?one?("cn=%s", cname)), \
When mapping data from LDAP to NIS+, the template netmasks entry is as follows.
netmasks: addr=ipNetworkNumber, \
After substituting attribute and column names, this result is the following.
nodeinfo: cname=cn, \
The delete rule set for netmasks is as follows.
netmasks_del: dn=("ipNetworkNumber=%s,", addr), \
The above specifies that when a netmasks entry is deleted in NIS+, the ipNetmaskNumber attribute in the corresponding ou=Networks LDAP entry is deleted. In this case, delete the nodeInventory and nodeOwner attributes. Therefore, using the dn specification from item (5) above, results in the following.
nodeinfo_del: dn=("cn=%s+ipHostNumber=%s,", cname, \
ldap:ipHostNumber:?one?("cn=%s", cname)), \
The mapping information is complete.
The mapping information is complete. In order to begin using it, stop and later start the rpc.nisd daemon.
# pkill rpc.nisd
Stop, and later start, the NIS+ service, to begin using the mapping file.
# svcadm disable network/rpc/nisplus:default
If data is already in the NIS+ nodeinfo table, upload that data to LDAP. Put the new nodeinfo mapping information into a separate file, /var/nis/tmpmapping.
# /usr/sbin/rpc.nisd -D -m /var/nis/tmpmapping \
-x nisplusLDAPinitialUpdateAction=to_ldap \
Add the mapping information from the temporary file, /var/nis/tmpmapping, to the actual mapping file. Use an editor to do this, or append the data (assuming the actual mapping file is /var/nis/NIS+LDAPmapping) as follows.
# cp -p /var/nis/NIS+LDAPmapping \
# cat /var/nis/tmpmapping >> /var/nis/NIS+LDAPmapping
Caution - Note the double arrow redirection, “>>”. A single arrow, “>”, would overwrite the target file.
Add the -m option to the /lib/svc/method/nisplus file. Also add the -Y or -B options as needed. See NIS+ to LDAP Tools and the Service Management Facility for more information.
Start the NIS+ service.
# svcadm enable network/rpc/nisplus:default
Restart the rpc.nisd daemon. Add the -Y option if the rpc.nisd daemon also serves NIS (YP) data as follows.
# /usr/sbin/rpc.nisd -m /var/nis/NIS+LDAPmapping