Bug 1009679 - replication stops with excessive clock skew
replication stops with excessive clock skew
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Rich Megginson
Sankar Ramalingam
Depends On: 1009122
  Show dependency treegraph
Reported: 2013-09-18 16:48 EDT by Rich Megginson
Modified: 2014-06-17 23:00 EDT (History)
3 users (show)

See Also:
Fixed In Version: 389-ds-base-
Doc Type: Bug Fix
Doc Text:
Cause: The directory server replication protocol takes into account clock differences between servers. The clock skew accumulator can grow quite high, especially due to problems with ntp or clocks in virtual machines. Once the clock skew is greater than 1 day, replication will stop working. Consequence: Updates made to one server are not replicated to other servers. Re-initialization does not help. Fix: Add a new configuration parameter to cn=config nsslapd-ignore-time-skew: on|off - default off If nsslapd-ignore-time-skew: on, the replication consumer will log errors about excessive time skew, but will allow replication to proceed, and will not return a time skew error to the replication supplier. Result: With nsslapd-ignore-time-skew: on, replication will continue despite excessive clock skew.
Story Points: ---
Clone Of: 1009122
Last Closed: 2014-06-13 06:57:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Rich Megginson 2013-09-18 16:48:53 EDT
+++ This bug was initially created as a clone of Bug #1009122 +++

This bug is created as a clone of upstream ticket:

If the CSN generator clock skew is over 1 day, replication stops.  Users need to be able to continue to replicate with the high clock skew.  There should be a configuration attr that allows replication to continue despite excessive clock skew.

This is becoming a much bigger problem now that many users are using VMs, which are notorious for having system clock/time/ntp issues.

--- Additional comment from Rich Megginson on 2013-09-17 14:06:25 EDT ---

Red Hat IT is requesting a hot fix, which means this bug will need to be officially fixed and supported in rhel 6.6.
Comment 1 Rich Megginson 2013-09-24 16:15:36 EDT
r8139 | rmeggins@REDHAT.COM | 2013-09-24 14:15:15 -0600 (Tue, 24 Sep 2013) | 6 lines

Bug 1009122 - replication stops with excessive clock skew

added test bug1009122 to test the new nsslapd-ignore-time-skew attribute
Comment 3 Rich Megginson 2014-01-20 15:29:34 EST
There is a new fix upstream that we need to pick up
Comment 4 Rich Megginson 2014-01-22 11:17:34 EST
r8282 | rmeggins@REDHAT.COM | 2014-01-22 09:09:54 -0700 (Wed, 22 Jan 2014) | 3 lines

Bug 1009679
Additional tests
Comment 5 Sankar Ramalingam 2014-02-14 07:13:20 EST
Based on comment #4, marking the bugzilla with qe_test_coverage+ flag.

Test cases added to mmrepl/accept/accept.sh.
bug1009122 test.
Comment 6 Sankar Ramalingam 2014-02-14 08:51:34 EST
Automated tests are passing with selected test cases. Hence, marking the bug as Verified.

Build tested - 389-ds-base-

S2 contains the changes from S1, after completing tests for bug1009122.
[root@lenovo-rd230-02 11818]# ldapsearch -x -p 24204 -h localhost -D "cn=Directory Manager" -w Secret123 -b "o=airius.com" -s base 

# airius.com
dn: o=airius.com
telephoneNumber: bug100912202-2
description: bug100912202-2
o: airius.com
objectClass: top
objectClass: organization

supportedldapversion: 3
instance [/usr/lib64/dirsrv/slapd-lenovo-rd230-02/../slapd-s1] is alive on port [24202]
StartSlapd: Server successfully started
-----------------StartSlapd: Completed-----------------

stopped slapd-s1
TestCase [bug1009122] result-> [PASS]
Comment 7 Ludek Smid 2014-06-13 06:57:14 EDT
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.

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