test

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

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.

  1. Create a database id that identifies the NIS+ table to be mapped. 


    nisplusLDAPdatabaseIdMapping	nodeinfo:nodeinfo

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

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

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

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

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

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

  8. The mapping information is complete. In order to begin using it, stop and later start the rpc.nisd daemon.

    # pkill rpc.nisd

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

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

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