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 link and managed attributes both have DN values. The value of the link attribute contains the DN of the entry for the plug-in to update; the managed attribute in the second entry has a DN value which points back to the original link entry.)
7.3.1. About Linking Attributes
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 (
Figure 7.5. Basic Linked Attribute Configuration
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. See Section 18.7.2, “Adding an ACI”
for information on setting ACIs.
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 in the entire directory.
Figure 7.6. Restricting the Linked Attribute Plug-in to a Specific Subtree
When configuring the Linked Attribute Plug-in instance, certain configurations are required:
Both the managed attribute and linked attribute must require the Distinguished Name syntax in their attribute definitions. The linked attributes are essentially managed cross-references, and the way that the plug-in handles these cross-references is by pulling the DN of the entry from the attribute value.
Each Linked Attribute Plug-in instance must be local and any managed attributes must be blocked from replication using fractional replication.
Any changes that are made on one supplier will 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.
7.3.2. Looking at the Linking Attributes Plug-in Syntax
The default Linked Attributes Plug-in entry is a container entry for each plug-in instance, similar to the password syntax plug-ins or the DNA Plug-in in the next section. Each entry beneath this container entry defines a different link-managed attribute pair.
To create a new linking attribute pair, then, create a new plug-in instance beneath the container entry. A basic linking attribute plug-in instance required defining two things:
The attribute that is managed manually by administrators, in the
The attribute that is created dynamically by the plug-in, in the
Optionally, a scope that restricts the plug-in to a specific part of the directory tree, in the
Example 7.5. Example Linked Attributes Plug-in Instance Entry
dn: cn=Manager Link,cn=Linked Attributes,cn=plugins,cn=config
cn: Manager Link
7.3.4. Cleaning up Attribute Links
The managed-linked attributes can get out of sync. For instance, a linked attribute could be imported or replicated over to a server, but the corresponding managed attribute was not because the link attribute was not properly configured. The managed-linked attribute pairs can be fixed by running the
dsconf plugin linked-attr fixup command or by launching a fix-up task.
The fixup task removes any managed attributes (attributes managed by the plug-in) that do not have a corresponding link attribute (attributes managed by the administrator) on the referenced entry. Conversely, the task adds any missing managed attributes if the link attribute exists in an entry.
188.8.131.52. Regenerating Linked Attributes
dsconf plugin linked-attr fixup command launches a special task to regenerate all of the managed-link attribute pairs on directory entries. One or the other may be lost in certain situations. If the link attribute exists in an entry, the task traces the cross-referenced DN in the available attribute and creates the corresponding configured managed attribute on the referenced entry. If a managed attribute exists with no corresponding link attribute, then the managed attribute value is removed.
To repair all configured link attribute pairs for the entire scope of the plug-in, then run the command as the Directory Manager:
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin linked-attr fixup
It is also possible to limit the fixup task to a single link-managed attribute pair by passing a base DN to the command. For example:
# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin linked-attr fixup "cn=Manager Link,cn=Linked Attributes,cn=plugins,cn=config"
184.108.40.206. Regenerating Linked Attributes Using ldapmodify
Repairing linked attributes is one of the tasks which can be managed through a special task configuration entry. Task entries occur under the
cn=tasks configuration entry in the
dse.ldif file, so it is also possible to initiate a task by adding the entry using
ldapmodify. When the task is complete, the entry is removed from the directory.
This task is the same one created automatically by the
dsconf plugin linked-attr fixup command when it is run.
To initiate a linked attributes fixup task, add an entry under the
cn=fixup linked attributes,cn=tasks,cn=config entry. The only required attribute is the
cn for the specific task, though it also allows the
ttl attribute to set a timeout period. Using
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x
dn: cn=example,cn=fixup linked attributes,cn=tasks,cn=config
Once the task is completed, the entry is deleted from the
dse.ldif configuration, so it is possible to reuse the same task entry continually.