How to Map Non-Entry Objects

1. 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.

2. 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

3. 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

4. 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.

5. (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.

6. 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.

   dn: cn=nodeinfo,ou=nisPlus,dc=some,dc=domain objectclass: nisplusObjectContainer objectclass: top cn: nodeinfo nisplusobject=<base 64 encoded data>