Show Table of Contents
7.3. Linking Attributes to Manage Attribute Values
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 (managedType).
Figure 7.5. 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. 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.For information on planning custom schema elements, see Chapter 12, Managing the Directory Schema.
- 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.For information on using fractional replication, see Section 15.1.7, “Replicating a Subset of Attributes with Fractional Replication”.
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
linkTypeattribute - The attribute that is created dynamically by the plug-in, in the
managedTypeattribute - Optionally, a scope that restricts the plug-in to a specific part of the directory tree, in the
linkScopeattribute
Example 7.5. Example Linked Attributes Plug-in Instance Entry
dn: cn=Manager Link,cn=Linked Attributes,cn=plugins,cn=config objectClass: top objectClass: extensibleObject cn: Manager Link linkType: directReport managedType: manager linkScope: ou=people,dc=example,dc=com
For a list of attributes available for an instance of the Linked Attributes plug-in, see the corresponding section in the Red Hat Directory Server Configuration, Command, and File Reference.
7.3.3. Configuring Attribute Links
- If it is not already enabled, enable the Linked Attributes plug-in. For details, see Section 1.10.3, “Enabling and Disabling Plug-ins”.f
- Create the plug-in instance. Both the
--managed-typeand--link-typeparameters are required. The following example shows the plug-in instance created by usingdsconf:# dsconf -D "cn=Directory Manager" ldap://server.example.com plugin linked-attr config "Manager Link" add --link-type=directReport --managed-type=manager
- Restart the instance:
# dsctl instance_name restart
If you enable the dynamic plug-in as described in Section 1.10.2, “Enabling Plug-ins Dynamically”, restarting the instance is not required.
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.
7.3.4.1. Regenerating Linked Attributes
The
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"
7.3.4.2. 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:
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x dn: cn=example,cn=fixup linked attributes,cn=tasks,cn=config changetype: add cn:example ttl: 5
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.
The
cn=fixup linked attributes task configuration is described in more detail in the Configuration, Command, and File Reference.