[#1050] Document the replication repair control, and test that a repaired modify stays on its replica - #1052
Open
vharseko wants to merge 1 commit into
Conversation
…and test that a repaired modify stays on its replica The control that lets an administrator write entryUUID and ds-sync-hist was only listed by its OID among the supported controls. The reference appendix now names it and says what it does, and the replication chapter of the administration guide shows how to give an entry back the entryUUID another directory assigned to it - on every replica in turn, since the change is not published. ReplicationRepairControlTest covered the add case only, on a suffix that was not replicated. It now runs over a replicated suffix with a broker listening on the replication server, and checks that a modify of entryUUID and nsUniqueId under the control succeeds where the same modify without it is refused, reaches neither the replication server nor the error log, and leaves the entry replicating as any other under its repaired entryUUID. A line-break missing from the LDIF of the add case is restored as well.
vharseko
added
docs
tests
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #1050, where an administrator asked how to give entries back the
entryUUIDvalues another directory had assigned to them, without breaking the replication topology.The answer is the replication repair request control (
1.3.6.1.4.1.26027.1.5.2), which the server has had since the ForgeRock days but which was only listed by its OID among the supported controls. This PR:ds-sync-hist;ldapmodify --controlprocedure to run on each replica, the check to make afterwards, and the warning about repairing some replicas and not others;ReplicationRepairControlTest, which covered the add case on an unreplicated suffix, into a test over a replicated suffix with a broker listening on the replication server. It now also checks that a modify ofentryUUIDandnsUniqueIdunder the control succeeds where the same modify without it is refused, reaches neither the replication server nor the error log, and leaves the entry replicating as any other under its repairedentryUUID. (A line-break missing from the LDIF of the add case is restored on the way: the entry was being added with an object class namedpersonobjectClass: organizationalPerson, which the skipped schema check let through.)Verified: the new assertions fail when
MultimasterReplication.findDomain()no longer marks the repaired operationdontSynchronize(mutant run), and pass on the current code; the changed asciidoc renders without warnings.The Relax Rules control, which looks like the alternative for this, behaves differently on a replicated suffix - see #1051.
Related: #1050.