Bug 1009679 - replication stops with excessive clock skew
Summary: replication stops with excessive clock skew
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Rich Megginson
QA Contact: Sankar Ramalingam
URL:
Whiteboard:
Depends On: 1009122
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-09-18 20:48 UTC by Rich Megginson
Modified: 2018-12-09 17:11 UTC (History)
3 users (show)

Fixed In Version: 389-ds-base-1.3.1.6-15.el7
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.
Clone Of: 1009122
Environment:
Last Closed: 2014-06-13 10:57:14 UTC
Target Upstream Version:

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Description Rich Megginson 2013-09-18 20:48:53 UTC 
+++ This bug was initially created as a clone of Bug #1009122 +++

This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/47516

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 20:15:36 UTC 
r8139 | rmeggins | 2013-09-24 14:15:15 -0600 (Tue, 24 Sep 2013) | 6 lines

Bug 1009122 - replication stops with excessive clock skew
https://bugzilla.redhat.com/show_bug.cgi?id=1009122

added test bug1009122 to test the new nsslapd-ignore-time-skew attribute
Comment 3 Rich Megginson 2014-01-20 20:29:34 UTC 
There is a new fix upstream that we need to pick up
Comment 4 Rich Megginson 2014-01-22 16:17:34 UTC 
testcases/DS/6.0/mmrepl/accept/accept.sh
------------------------------------------------------------------------
r8282 | rmeggins | 2014-01-22 09:09:54 -0700 (Wed, 22 Jan 2014) | 3 lines

Bug 1009679
Additional tests
Comment 5 Sankar Ramalingam 2014-02-14 12:13:20 UTC 
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 13:51:34 UTC 
Automated tests are passing with selected test cases. Hence, marking the bug as Verified.

Build tested - 389-ds-base-1.3.1.6-18.

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 10:57:14 UTC 
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.