[Freeipa-users] ui login error and questions about replication

[Tamas Papp]

On 11/05/2013 09:20 PM, Tamas Papp wrote:
> On 11/05/2013 09:09 PM, Rob Crittenden wrote:
>> Tamas Papp wrote:
>>> On 11/05/2013 03:58 PM, Rich Megginson wrote:
>>>> On 11/05/2013 07:53 AM, Tamas Papp wrote:
>>>>> On 11/05/2013 03:17 PM, Rich Megginson wrote:
>>>>>> https://fedorahosted.org/389/ticket/47516
>>>>>>
>>>>>> This has been fixed upstream and in some releases - to allow
>>>>>> replication to proceed despite excessive clock skew - what is your
>>>>>> 389-ds-base version and platform?
>>>>> What is the clock skewed? The date and time is the same on both
>>>>> machines.
>>>> VMs are notorious for having the clocks get out of sync - even
>>>> temporarily.
>>> What do you mean by this?
>>> I definitely see the same time on the machines.
>>> Also I can see in the log, that the replication is resumed. There is no
>>> messages about the broken replication after the resume message.
>> You see the same time NOW. The logs were reflecting a difference at
>> that time.
> I saw the same, when the log messages appeared.
> Is there a way to get the time it sees from the other side?
>
>
>
>>> I tried this, but no joy. Still not good:/
>>>
>>> What I really  don't understand, why I cannot login to ui (or to an
>>> installed client machine) if the replication doesn't work.
>>> Is it a normal behaviour?
>> These issues are probably not related, unless perhaps the time skew is
>> also throwing off the Kerberos tickets and/or session cache in the IPA
>> framework.
>>
>> You didn't say how you were trying to log into the UI. Are you using
>> Kerberos or the form-based authentication?
> Latter.
> There is no kerberos configured on my computer.
> But I've also tried with ssh on a normal computer.
> Both failed.

Recently I'm able to login to the UI.
I made couple of changes, but probably this was the tricky one:

One of the host machine was configured to UTC.
So I changed the VM configuration as well:

From
<clock offset='localtime'/>

to
<clock offset='utc'/>

Before this change the 'RTC time:' line was lacking from the output of
timedatectl and after the VM reboot the default time was wrong (though
it could be fixed by ntpdate easily).

After reboot it seems to be working, but:


[05/Nov/2013:23:33:24 +0100] csngen_new_csn - Warning: too much time
skew (-2852 secs). Current seqnum=1
[05/Nov/2013:23:33:24 +0100] NSMMReplicationPlugin -
agmt="cn=meToipa12.bpo.cxn" (ipa12:389): Replication bind with GSSAPI
auth resumed
[05/Nov/2013:23:33:24 +0100] csngen_new_csn - Warning: too much time
skew (-2853 secs). Current seqnum=1
[05/Nov/2013:23:33:25 +0100] csngen_new_csn - Warning: too much time
skew (-2853 secs). Current seqnum=1
[[05/Nov/2013:23:33:51 +0100] csngen_new_csn - Warning: too much time
skew (-2828 secs). Current seqnum=1
[05/Nov/2013:23:33:51 +0100] csngen_new_csn - Warning: too much time
skew (-2829 secs). Current seqnum=1
[05/Nov/2013:23:33:51 +0100] csngen_new_csn - Warning: too much time
skew (-2830 secs). Current seqnum=1
[05/Nov/2013:23:33:53 +0100] csngen_new_csn - Warning: too much time
skew (-2829 secs). Current seqnum=1
[05/Nov/2013:23:35:14 +0100] csngen_new_csn - Warning: too much time
skew (-2749 secs). Current seqnum=1
[05/Nov/2013:23:35:14 +0100] csngen_new_csn - Warning: too much time
skew (-2750 secs). Current seqnum=1
[05/Nov/2013:23:35:23 +0100] csngen_new_csn - Warning: too much time
skew (-2742 secs). Current seqnum=1
[05/Nov/2013:23:35:23 +0100] csngen_new_csn - Warning: too much time
skew (-2743 secs). Current seqnum=1


# ldapsearch -x -D "cn=directory manager" -W |grep -i
nsslapd-ignore-time-skew
Enter LDAP Password:


No I don't understand, why it was resumed and why it is working in spite
of skewed time.
And still I don't understand, why I cannot login, when the replication
is not working.


tamas