Chris Phillips wrote:
On Tue, Jun 9, 2009 at 4:06 PM, Rich Megginson <rmeggins(a)redhat.com
<mailto:rmeggins@redhat.com>> wrote:
Chris Phillips wrote:
Hi,
I've a cluster of boxes with replication form two multimasters
to 6 read only replicas. There appears to be a problem in the
replication in that the error logs state that the DSA is
unwilling to process updates for a specific user account, so
the replication status in the idm just stays at saying it
started rather than completed. I could just delete the account
and recreate it, but as it's unfortunately *my* account (and
is in this state *possibly* because I was messing with the
resetpasswordretrytime field (or something very similarly
named) which I get the impression is treated differently to
other fields) I'd like to avoid deleting the account.
To this end I'm hoping a suitable solution is to remove
whatever the change is that is trying to be pushed across, but
I can't see any way with SSL replication to see what the
actual attributes it doesn't like are. Any way to pull this
straight out with ldapsearch or something? Any tips for
elegantly troubleshooting this in a heavily locked down
environment would be appreciated.
Yes, it probably has to do with one of those password related
operational attributes. There are a couple of ways to handle this
1) change your replication agreement to exclude the attributes
passwordRetryCount, retryCountResetTime, and accountUnlockTime -
you do this by adding these attributes to be excluded in
fractional replication - you should be able to modify your
existing replication agreements to exclude these
2) add the attribute passwordIsGlobalPolicy in cn=config to "on"
on your servers - this will allow those attributes to be replicated
This seems to fit in exactly, thanks. If I set this value on a read
only replica, what will happen if it is locked out on that replica?
Presumably despite this setting that can't get replicated back up to
the multimasters?
Correct. You can set up chain on update to have
"global" lockout - see
http://directory.fedoraproject.org/wiki/Howto:ChainOnUpdate
As an alternative to changing the policy, can I manually undo these
changes? TBH I'm not too clued up on what triggers an attribute like
this to be chosen to be replicated in the first place, if it's a
hidden timestamp or such.
Yes. Those attributes are operational attributes - you
have to ask for
them explicitly in the ldapsearch request. You should be able to set
them manually as directory manager. But for now, the problem is that
the changes are in the changelog and the server is attempting to
replicate them. I suggest setting the isglobal attribute in the
replica, allowing the change, then disabling the replication of those
attributes and disabling global policy.
Thanks
Chris
------------------------------------------------------------------------
--
389 users mailing list
389-users(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-directory-users