Time Skew on Amazon nodes?

[pgb205]

I have noticed that we had a broken replication agreement between replica in amazon and on
another physical node. I have attempted to re-initialize but receivedUpdate failed!
Status: [2 Replication error acquiring replica: excessive clock skew]


I had triple verified that time on both is correct and at most within seconds of each
other.
in dirsrv logs I get 
Excessive clock skew from supplier RUVUnable to acquire replica: error: excessive clock
skew

 After doing a bit of searching I found this
beauty:https://www.redhat.com/archives/freeipa-users/2014-February/msg000...

The article mentions that the time skew might occur due to server being virtualied, and
I'm  wondering if this is applicable to Amazon.
The steps mentioned in the article look intrusive (and intimidating) . I'm curious
what other avenues are available to me to fix this?If I blow away the replica and re-set
up the new one from scratch would that fix the problem.

[Ludwig Krispenz]

replication uses CSNs(change sequence numbers) to synchronize data 
across the topology, and it requires the times to be in sync and that 
time never goes backward, otherwise a new change would get an older csn 
and probably be ignored after repliciation.
Since it is not guaranteed that system time is always is sync and that 
no one plays with the time setting, replcation uses its own csn state, 
maintainig the local system time and remote or local offsets when 
differnces in time were detected. This ensures that time is in sync, as 
good as possible, and that time never goes backward.
Unfortunately these offsets can accumulate over time and reach a value 
where replication "thinks" it is insane to continue and raises the clock 
skew error.
In my opinion this should not be a fatal error, but right now it is, 
feel free to log an RFE.

Now, the csns are part of all the individual data in the servers's 
database, so you cannot just clean them up, also if you add a new 
replica it will inherit the offsets present in other servers. 
Unfortunately I only see the hard way to get out of this: export the 
data without state information(csns), reimport and reinitialize. That's 
in the doc you referenced

Ludwig

On 06/01/2017 09:29 PM, pgb205 via FreeIPA-users wrote:
>  I have noticed that we had a broken replication agreement between 
>  replica in amazon and on another physical node.
>  I have attempted to re-initialize but received
>  /Update failed! Status: [2 Replication error acquiring replica: 
>  excessive clock skew]/
>
>
>  I had triple verified that time on both is correct and at most within 
>  seconds of each other.
>
>  in dirsrv logs I get
>  /Excessive clock skew from supplier RUV/
>  /Unable to acquire replica: error: excessive clock skew/
>  /
>  /
>   After doing a bit of searching I found this beauty:
>  https://www.redhat.com/archives/freeipa-users/2014-February/msg00007.html
>
>  The article mentions that the time skew might occur due to server 
>  being virtualied, and I'm  wondering if this is applicable to Amazon.
>
>  The steps mentioned in the article look intrusive (and intimidating) . 
>  I'm curious what other avenues are available to me to fix this?
>  If I blow away the replica and re-set up the new one from scratch 
>  would that fix the problem.
>
>
>
>  _______________________________________________
>  FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org 
-- 
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric
Shander

[pgb 205]

Ludwig, 

what about this 'fix'
https://bugzilla.redhat.com/show_bug.cgi?id=1009122

won't the setting of nsslapd -ignore-time-skew==on  effectively solve the issue?

IE on the down server edit the value in /etc/dirsrv/slapd-DOMAIN/dse.ldif  to
nsslapd-ignore-time-skew=on
and then try to bring up the ipa server?

[Ludwig Krispenz]

On 07/31/2017 10:45 PM, pgb 205 via FreeIPA-users wrote:
>  Ludwig,
>
>  what about this 'fix'
>  https://bugzilla.redhat.com/show_bug.cgi?id=1009122
>
>  won't the setting of nsslapd -ignore-time-skew==on  effectively solve the issue?
>
>  IE on the down server edit the value in /etc/dirsrv/slapd-DOMAIN/dse.ldif  to
> nsslapd-ignore-time-skew=on
>  and then try to bring up the ipa server? 
yes, that should work. Sorry I had missed
that we had implemented this.
>  _______________________________________________
>  FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org 
-- 
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric
Shander

[pgb 205]

ok thats great news! But I just want to make sure even if the server IS ALREADY DOWN due
to this bug we can still manually edit the database (dse.ldif) for this value and then
bring up the processes. Would that work?

[Ludwig Krispenz]

On 08/01/2017 04:42 PM, pgb 205 via FreeIPA-users wrote:
>  ok thats great news! But I just want to make sure even if the server
> IS ALREADY DOWN due to this bug we can still manually edit the database (dse.ldif) for
> this value and then bring up the processes. Would that work? 
yes, that should work
>  _______________________________________________
>  FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org 
-- 
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric
Shander

[pgb 205]

also, any repercussions to leaving the CSN number skewed like this long-term(as  nsslapd
-ignore-time-skew will only mask the problem). I take it that there aren't. We'll
just get log messages but no ill effects otherwise.

thank you