[Fedora-directory-users] Re: MMR: excessive clock skew
Rich Megginson
rmeggins at redhat.com
Wed Jun 11 18:03:03 UTC 2008
Gary Windham wrote:
> Sorry for not replying to the original thread, but I just joined this
> list.
>
> On Tue, 13 May 2008, Rich Megginson wrote:
>
> > Has anyone seen these errors with 1.1? We fixed a few 64-bit issues
> in 1.1.
>
> I am running two 32-bit FDS 1.1 (fedora-ds-1.1.0-3.fc6) servers, on
> RHEL 5.1, in an MMR configuration. These servers, which are
> configured behind a load balancer, act as the University's central
> authentication service. We have are using the password policy plugin
> and have the "passwordisglobalpolicy" setting enabled, so there is a
> substantial amount of write activity due to replication of
> password-policy-related attributes (e.g., passwordRetryCount,
> retryCountResetTime, etc). Time on both systems is synchronized via
> NTP; clocks are in sync.
>
> We have the same situation as Reinhard Nappert reported on 5/13/2008:
> MMR will work fine for a while (usually a few weeks; the longest
> period we've gone is a month, the shortest time a few hours).
> Eventually replication will fail with the following sequence of
> messages in the errors log:
>
> [24/May/2008:05:18:54 -0700] - csngen_adjust_time: adjustment limit
> exceeded; value - 86401, limit - 86400
> [24/May/2008:05:18:54 -0700] NSMMReplicationPlugin - conn=1800
> op=60262 replica="<suffix>": Unable to acquire replica: error:
> excessive clock skew
> [24/May/2008:05:20:05 -0700] - csngen_adjust_time: adjustment limit
> exceeded; value - 86401, limit - 86400
> [24/May/2008:05:20:05 -0700] NSMMReplicationPlugin -
> agmt="cn=kif2zapp" (zapp:389): Incremental protocol: fatal er
> ror - too much time skew between replicas!
> [24/May/2008:05:20:05 -0700] NSMMReplicationPlugin -
> agmt="cn=kif2zapp" (zapp:389): Incremental update failed and
> requires administrator action
>
> The "csngen_adjust_time" error message always reports the same value
> when this occurs (86401).
>
> We have also employed the workaround described by Chris St. Pierre in
> https://bugzilla.redhat.com/show_bug.cgi?id=233642#c3. This resolves
> the problem for a short while, but it always reappears. BTW, I was in
> contact with Chris recently about his experiences with MMR and he said
> that, in addition to moving to FDS 1.1, he moved a lot of "frequently
> updated" data out of FDS and into MySQL, and that his problem
> disappeared afterward; obviously this isn't a solution for us as we
> are utilizing FDS as an authentication engine.
>
> We are desperately trying to find a solution to this issue that will
> allow us to continue using MMR...we could resort to a traditional
> passive/active + shared storage HA design, but we want to keep that as
> a last resort. If there is any additional information I should
> provide, please let me know.
I've attached a script to
https://bugzilla.redhat.com/show_bug.cgi?id=233642 to help diagnose this
problem.
>
> --
> Gary Windham
> Senior Enterprise Systems Architect
> The University of Arizona, UITS
> +1 520 626 5981
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3258 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-directory-users/attachments/20080611/b95b4792/attachment.bin>
More information about the Fedora-directory-users
mailing list