5.5. About Linking Attributes
A class of service dynamically supplies attribute values for entries which all have attributes with the same value, like building addresses, postal codes, or main office numbers. These are shared attribute values, which are updated in a single template entry.
Frequently, though, there are relationships between entries where there needs to be a way to express linkage between them, but the values (and possibly even the attributes) that express that relationship are different. Red Hat Directory Server provides a way to link specified attributes together, so that when one attribute in one entry is altered, a corresponding attribute on a related entry is automatically updated. The first attribute has a DN value, which points to the entry to update; the second entry attribute also has a DN value which is a back-pointer to the first entry.
For example, group entries list their members in attributes like
member. It is natural for there to be an indication in the user entry of what groups the user belongs to; this is set in the memberOf attribute. The memberOf attribute is a managed attribute through the MemberOf Plug-in. The plug-in polls every group entry for changes in their respective member attributes. Whenever a group member is added or dropped from the group, the corresponding user entry is updated with changed memberOf attributes. In this way, the member (and other member attributes) and memberOf attributes are linked.
The MemberOf Plug-in is limited to a single instance, exclusively for a (single) group member attribute (with some other behaviors unique to groups, like handling nested groups). Another plug-in, the Linked Attributes Plug-in, allows multiple instances of the plug-in. Each instance configures one attribute which is manually maintained by the administrator (
linkType) and one attribute which is automatically maintained by the plug-in (managedType).
Figure 5.6. Basic Linked Attribute Configuration
Note
To preserve data consistency, only the plug-in process should maintain the managed attribute. Consider creating an ACI that will restrict all write access to any managed attribute.
A Linked Attribute Plug-in instance can be restricted to a single subtree within the directory. This can allow more flexible customization of attribute combinations and affected entries. If no scope is set, then the plug-in operates on the entire directory.
Figure 5.7. Restricting the Linked Attribute Plug-in to a Specific Subtree
5.5.1. Schema Requirements for Linking Attributes
Both the managed attribute and linked attribute must require the Distinguished Name syntax in their attribute definitions. The plug-in identifies the entries to maintain by pulling the DN from the link attribute, and then it automatically assigns the original entry DN as the value of the managed attribute. This means that both attributes have to use DNs as their values.
The managed attribute must be multi-valued. Users may be members of more than one group, be authors of more than one document, or have multiple "see also" reference entries. If the managed attribute is single-valued, then the value is not updated properly. This is not much of an issue with the default schema because many of the standard elements are multi-valued. It is particularly important to consider, however, when using custom schema.
Figure 5.8. Wrong: Using a Single-Valued Linked Attribute
5.5.2. Using Linked Attributes with Replication
In a simple replication scenario (supplier-consumer), then the plug-in only has to exist on the supplier, because no writes can be made on the consumer.
For multi-supplier replication, each supplier must have its own plug-in instance, all configured identically, and the managed attributes must be excluded from replication using fractional replication.
Figure 5.9. Linking Attributes and Replication
Any changes that are made on one supplier automatically trigger the plug-in to manage the values on the corresponding directory entries, so the data stay consistent across servers. However, the managed attributes must be maintained by the plug-in instance for the data to be consistent between the linked entries. This means that managed attribute values should be maintained solely by the plug-in processes, not the replication process, even in a multi-supplier replication environment.
