Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
When in the MMR + DNA setup the plugin configuration entry of DNA is modified, the new attributes dnaRemoteBindMethod and dnaRemoteConnProtocol that are in the shared configuration entry get erased by the plugin.
This happens when the entry is modified manually as well as when the plugin config entry is modified when the plugin itself assigns a value to newly added entry and updates the dnaNextValue attribute in the process.
This disables the dna range transfer process from a server that is not known to the server making the request (e.g. M1 <-----> M2 <-----> M3 topology).
Version-Release number of selected component (if applicable):
389-ds-base-1.3.1.6-21.el7
How reproducible:
always
Steps to Reproduce:
1. Set up MMR and DNA with the topology from description
2. Set M1 and M2 to have only few remaining values above the threshold abd M3 with a lot of available space.
3. Add users to M1 to deplete the available values and fall beneath the threshold, triggering the range transfer.
Actual results:
The server tries to get a new range from server M2, (probably) using credentials from replication agreement, and is rejected. The server can't contact the server M3 as it can't retrieve the attributes from the shared entry.
logs:
[07/Mar/2014:14:18:44 -0500] dna-plugin - dna_pre_op: Passed threshold of 10 remaining values for range cn=account uids,cn=distributed numeric assignment plugin,cn=plugins,cn=config. (6 values remain)
[07/Mar/2014:14:18:44 -0500] dna-plugin - dna_get_replica_bind_creds: Failed to fetch replication agreement for range cn=Account UIDs,ou=Ranges,dc=example,dc=com, server example.com, port 3389
[07/Mar/2014:14:18:44 -0500] dna-plugin - dna_request_range: Unable to retrieve replica bind credentials.
[07/Mar/2014:14:18:44 -0500] dna-plugin - dna_request_range: Error sending range extension extended operation request to server dell-pe840-02.rhts.eng.bos.redhat.com:2389 [error 53]
Expected results:
The server uses the method and protocol settings stored in the shared configuration to contact server M3 and gets new range.
Additional info:
Setting as a blocker for the bugzilla 971111 as I'm not sure I can verify the functionality as I cannot trigger the range transfer without deleting the configuration.
(In reply to Milan Kubík from comment #0)
> Setting as a blocker for the bugzilla 971111 as I'm not sure I can verify
> the functionality as I cannot trigger the range transfer without deleting
> the configuration.
I'm not sure I understand why you would need to delete the configuration. You should be able to trigger the range transfer by simply adding enough users to bypass the threshold setting. Would you mind explaining why you are modifying the configuration to trigger a range transfer?
I know that the IPA development team has been able to test the core functionality of this feature manually.
I'm not modifying the plugin configuration.
When a plugin generates the values for an entry when they are added, it updates dnaNextValue attribute in its configuration, deleting the attributes from shared configuration.
(In reply to Milan Kubík from comment #5)
> I'm not modifying the plugin configuration.
>
> When a plugin generates the values for an entry when they are added, it
> updates dnaNextValue attribute in its configuration, deleting the attributes
> from shared configuration.
I inspected the code on Friday, and internal updates to dnaNextValue should not trigger removal of the shared config entry. Are you sure that this wasn't caused by the event thread that runs 30 seconds after startup?
Ok, new evidence suggests that I may have been wrong in my initial guess.
I was able to get a nextRange from M3 to M1 in this topology after I made sure it was after the initial update event.
Removing TestBlocker keyword.