Fedora directory users - Jun 2009 - [389-users] DSA unwilling to process update / Viewing contents of replication updates

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.

Thanks

Chris

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
>
> Thanks
>
> Chris
> ------------------------------------------------------------------------
>
> --
> 389 users mailing list
> 389-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

On Tue, Jun 9, 2009 at 4:06 PM, Rich Megginson <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?

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.

Thanks

Chris

Chris Phillips wrote:
>
>
> On Tue, Jun 9, 2009 at 4:06 PM, Rich Megginson <rmeggins@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@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>