Bug 450973 - rhds80 account accountunlocktime attribute breaks replication
rhds80 account accountunlocktime attribute breaks replication
Product: Red Hat Directory Server
Classification: Red Hat
Component: Replication - General (Show other bugs)
All Linux
high Severity urgent
: ---
: ---
Assigned To: Rich Megginson
Chandrasekar Kannan
: 442560 (view as bug list)
Depends On:
Blocks: 249650 FDS112 453229
  Show dependency treegraph
Reported: 2008-06-11 19:53 EDT by Issue Tracker
Modified: 2015-01-04 18:32 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-08-27 16:38:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
diffs (3.29 KB, patch)
2008-06-23 12:45 EDT, Rich Megginson
no flags Details | Diff
cvs commit log (232 bytes, text/plain)
2008-06-23 14:39 EDT, Rich Megginson
no flags Details

  None (edit)
Description Issue Tracker 2008-06-11 19:53:57 EDT
Escalated to Bugzilla from IssueTracker
Comment 12 Rich Megginson 2008-06-20 16:16:46 EDT
Looks like there is a bug.  The problem is two fold:
1) The supplier ignores the isglobalpolicy setting - it attempts to send the
which would be ok except for
2) The consumer rejects mod operations that contain no valid modifications with
err=53.  The consumer does honor the isglobalpolicy setting, removes the invalid
mods from the mod list, finds there are no mods left, and returns with err=53. 
The supplier does not recover from this error due to a bug in the async result
handling code.
Comment 13 Rich Megginson 2008-06-23 12:45:55 EDT
Created attachment 310042 [details]

This is for the actual bug - replication should not break.  This fixes a bug in
the replication error handling code so that replication will continue after
getting the err=53 from the consumer.

The other part of this fix is to simply not replicate those attributes.  I
believe this can be done by using fractional replication and adding the
attributes passwordRetryCount retryCountResetTime accountUnlockTime to the list
of attributes to not replicate.  This will only work with the redhat-ds-base
8.0.0-13 or later - i.e. if you have installed redhat-ds-base but not upgraded
to the latest one available in RHN, you need to do so, or fractional
replication between masters will not work.
Comment 14 Rich Megginson 2008-06-23 12:48:56 EDT
Correction - the fractional MMR fix is in 8.0.0-14 or later, not -13.
Comment 15 Rich Megginson 2008-06-23 14:39:23 EDT
Created attachment 310060 [details]
cvs commit log

Reviewed by: nhosoi (Thanks!)
Fix Description: We were not handling errors returned from the consumer
correctly in the async replication code.  The problem was that we were exiting
the async read results thread immediately.  However, we needed to wait for and
read all of the outstanding responses, then exit the thread when all of them
had been read.	The new code handles this case correctly, allowing us to read
all of the pending responses before exiting.

The flip side of this is that passwordIsGlobalPolicy only works on the
_consumer_.  It has no effect whatsoever on the _supplier_ side of replication.
 The fix for this is to configure fractional replication _always_ and to add
the password policy op attrs to the list of attrs not to replicate.  This
should work fine with RHDS 8.0.0-14 and later.
Platforms tested: RHEL5
Flag Day: no
Doc impact: Yes.  We will need to document exactly how passwordIsGlobalPolicy
works and how to configure fractional replication.
QA impact: Will need to do more testing of MMR with account lockout to make
sure this error does not blow up MMR anymore.
New Tests integrated into TET: Working on it.
Comment 17 Rich Megginson 2008-06-23 19:12:03 EDT
*** Bug 442560 has been marked as a duplicate of this bug. ***
Comment 24 errata-xmlrpc 2008-08-27 16:38:47 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.