System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP)

Adding New Object Mappings

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.
nisplusLDAPdatabaseIdMapping nodeinfo_table:nodeinfo.some.domain.
Assuming that nisplusLDAPbaseDomain is some.domain., the following would also work.
nisplusLDAPdatabaseIdMapping nodeinfo_table:nodeinfo

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.
nisplusLDAPentryTtl nodeinfo_table:3600:10800:43200

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.

nisplusLDAPobjectDN	nodeinfo_table:\
				cn=nodeinfo,ou=nisPlus,dc=some,dc=domain?base?\
				objectClass=nisplusObjectContainer:\
				cn=nodeinfo,ou=nisPlus,dc=some,dc=domain?base?\
					objectClass=nisplusObjectContainer,\
					objectClass=top

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.
cn=nodeinfo,ou=nisPlus,dc=some,dc=domain nisplusobject=NOT ASCII objectclass=nisplusObjectContainer objectclass=top cn=nodeinfo

Restart the rpc.nisd daemon so that it will start using the new mapping information. Do not forget the -m option if the mapping file has a name other than the default one. Append the -Y option if the rpc.nisd daemon is providing NIS (YP) service.

# pkill rpc.nisd

# /usr/sbin/rpc.nisd -m mappingfile [-Y]

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.
nisplusLDAPdatabaseIdMapping nodeinfo:nodeinfo
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.
nisplusLDAPentryTtl nodeinfo:21600:43200:43200
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.
nisplusLDAPobjectDN netmasks:ou=Networks,?one?objectClass=ipNetwork,\ ipNetMaskNumber=*:\ ou=Networks,?one?objectClass=ipNetwork: dbid=netmasks_del
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.
nisplusLDAPobjectDN nodeinfo:ou=Hosts,?one?objectClass=nodeInfo,\
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.
nodeInventory=*:\
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.
ou=Hosts,?one?objectClass=nodeInfo:\ dbid=nodeinfo_del
Putting it all together, our nisplusLDAPobjectDN is the following.
nisplusLDAPobjectDN nodeinfo:ou=Hosts,?one?objectClass=nodeInfo,\ nodeInventory=*:\ ou=Hosts,?one?objectClass=nodeInfo:\ dbid=nodeinfo_del
Create the rule set that maps nodeinfo data from NIS+ to LDAP. The template (from netmasks) is the following.
nisplusLDAPattributeFromColumn \ netmasks: dn=("ipNetworkNumber=%s,", addr), \ ipNetworkNumber=addr, \ ipNetmaskNumber=mask, \ description=comment
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.
nisplusLDAPattributeFromColumn \ 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.
nisplusLDAPattributeFromColumn \ nodeinfo: dn=("cn=%s+ipHostNumber=%s,", cname, \ ldap:ipHostNumber:?one?("cn=%s", cname)), \ nodeInventory=inventory, \ nodeOwner=owner

When mapping data from LDAP to NIS+, the template netmasks entry is as follows.

nisplusLDAPcolumnFromAttribute \
		netmasks:	addr=ipNetworkNumber, \
				mask=ipNetmaskNumber, \
				comment=description

After substituting attribute and column names, this result is the following.

nisplusLDAPcolumnFromAttribute \
		nodeinfo:	cname=cn, \
				inventory=nodeInventory, \
				owner=nodeOwner

The delete rule set for netmasks is as follows.
nisplusLDAPattributeFromColumn \ netmasks_del: dn=("ipNetworkNumber=%s,", addr), \ ipNetmaskNumber=
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.
nisplusLDAPattributeFromColumn \ nodeinfo_del: dn=("cn=%s+ipHostNumber=%s,", cname, \ ldap:ipHostNumber:?one?("cn=%s", cname)), \ nodeInventory=, \ nodeOwner=
The mapping information is complete. In order to begin using it, stop and later start the rpc.nisd daemon.

# pkill rpc.nisd
If there already is data 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 \

-x nisplusLDAPinitialUpdateOnly=yes
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 \

/var/nis/NIS+LDAPmapping.backup

# cat /var/nis/tmpmapping >> /var/nis/NIS+LDAPmapping

Note –
Note the double arrow redirection, ">>". A single arrow, ">", would overwrite the target file.
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