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

2013-11-05 Thread Alexander Bokovoy 

On Tue, 05 Nov 2013, Tamas Papp wrote:

hi,

The systems are uptodate F19 KVM guests.


I'm trying to login the web ui with no success:

"Your session has expired. Please re-login.

To login with Kerberos, please make sure you have valid tickets
(obtainable via kinit) and configured
 the browser
correctly, then click Login.

To login with username and password, enter them in the fields below then
click Login."


Then after a while something happens and it starts working.

In logs:

On the "primary" node:

[05/Nov/2013:12:19:06 +0100] NSMMReplicationPlugin -
agmt="cn=meToipa12.bpo.cxn" (ipa12:389): Replication bind with GSSAPI
auth resumed


On the "secondary" node:

[05/Nov/2013:12:31:25 +0100] csngen_new_csn - Warning: too much time
skew (-1658 secs). Current seqnum=3
[05/Nov/2013:12:45:33 +0100] csngen_new_csn - Warning: too much time
skew (-811 secs). Current seqnum=a
[05/Nov/2013:12:45:33 +0100] csngen_new_csn - Warning: too much time
skew (-812 secs). Current seqnum=1
[05/Nov/2013:12:45:35 +0100] csngen_new_csn - Warning: too much time
skew (-811 secs). Current seqnum=1
[05/Nov/2013:12:45:47 +0100] csngen_new_csn - Warning: too much time
skew (-800 secs). Current seqnum=4
[05/Nov/2013:12:45:47 +0100] csngen_new_csn - Warning: too much time
skew (-801 secs). Current seqnum=1
[05/Nov/2013:12:45:49 +0100] csngen_new_csn - Warning: too much time
skew (-800 secs). Current seqnum=1


Date shows up the same system time on both machines:

Tue Nov  5 12:59:29 CET 2013

I called as primary the machine that was installed initially and
secondary is the one that was deployed by replication.

Virtual Machines are known to have issues with keeping time in sync.


Finally, I have some questions:)

1. How can this happen, what's the problem? Is it something about the
design, I screwed up something, or maybe the virtualization layer..?
How can I avoid it and if it happens, how can I fix it immediately?
It is virtualization/time issue. 


https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization_for_Desktops/2.2/html/Administration_Guide/chap-Virtualization-KVM_guest_timing_management.html


2. What is the difference between 'primary' and 'secondary'. What does
happen, if the primary machine gets destroyed?

In IPA all replicas are the same, they only would differ by the paths
they sync with each other and by presence of integrated CA (if any).

If you have deployed original IPA server with integrated CA, then your
other replicas better to have at least one with CA configured to allow
proper recovery in case primary one is destroyed.




4. How many "master" can I use?

Technically there could be 65536 different masters in 389-ds replication
topology.


5. If I have a network like this:

A1__B1
A2  B2

A2 and B1,2 are replicated from A1

If the connection gets lost between A and B site, are B1 and 2 (and
A1,2) replicated fine?

I assume from the above that B1 does not know about B2 (and vice versa)?
Once connectivity between sites A and B restored, all unreplicated data
will be replicated. There could be conflicts if there were changes on
both sides during the split but majority of them are solved
automatically by 389-ds.


6. If a client is installed with ipa-client-install using A1 and A1 gets
lost, does the client know, where it needs to connect (failover..)?

IPA server which was used to enroll the host will be primary one (A1 in
your example). There is failover in sssd.conf to use SRV records of the
domain, and trying servers in the order returned by the SRV records.


7. Can I install slave (read-only) replicas so clients access them only
for queries and for changes (like pw change) they access master servers?

No read-only replicas available for IPA. All replicas are read-write and
propagate changes across replication paths as defined in replication
agreements. All IPA servers are really masters, thus we have
multi-master replication rather than master-slave.

--
/ Alexander Bokovoy

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

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

2013-11-05 Thread Rich Megginson 

On 11/05/2013 06:04 AM, Alexander Bokovoy wrote:

On Tue, 05 Nov 2013, Tamas Papp wrote:

hi,

The systems are uptodate F19 KVM guests.


I'm trying to login the web ui with no success:

"Your session has expired. Please re-login.

To login with Kerberos, please make sure you have valid tickets
(obtainable via kinit) and configured
 the browser
correctly, then click Login.

To login with username and password, enter them in the fields below then
click Login."


Then after a while something happens and it starts working.

In logs:

On the "primary" node:

[05/Nov/2013:12:19:06 +0100] NSMMReplicationPlugin -
agmt="cn=meToipa12.bpo.cxn" (ipa12:389): Replication bind with GSSAPI
auth resumed


On the "secondary" node:

[05/Nov/2013:12:31:25 +0100] csngen_new_csn - Warning: too much time
skew (-1658 secs). Current seqnum=3
[05/Nov/2013:12:45:33 +0100] csngen_new_csn - Warning: too much time
skew (-811 secs). Current seqnum=a
[05/Nov/2013:12:45:33 +0100] csngen_new_csn - Warning: too much time
skew (-812 secs). Current seqnum=1
[05/Nov/2013:12:45:35 +0100] csngen_new_csn - Warning: too much time
skew (-811 secs). Current seqnum=1
[05/Nov/2013:12:45:47 +0100] csngen_new_csn - Warning: too much time
skew (-800 secs). Current seqnum=4
[05/Nov/2013:12:45:47 +0100] csngen_new_csn - Warning: too much time
skew (-801 secs). Current seqnum=1
[05/Nov/2013:12:45:49 +0100] csngen_new_csn - Warning: too much time
skew (-800 secs). Current seqnum=1


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?





Date shows up the same system time on both machines:

Tue Nov  5 12:59:29 CET 2013

I called as primary the machine that was installed initially and
secondary is the one that was deployed by replication.

Virtual Machines are known to have issues with keeping time in sync.


Finally, I have some questions:)

1. How can this happen, what's the problem? Is it something about the
design, I screwed up something, or maybe the virtualization layer..?
How can I avoid it and if it happens, how can I fix it immediately?

It is virtualization/time issue.
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization_for_Desktops/2.2/html/Administration_Guide/chap-Virtualization-KVM_guest_timing_management.html 




2. What is the difference between 'primary' and 'secondary'. What does
happen, if the primary machine gets destroyed?

In IPA all replicas are the same, they only would differ by the paths
they sync with each other and by presence of integrated CA (if any).

If you have deployed original IPA server with integrated CA, then your
other replicas better to have at least one with CA configured to allow
proper recovery in case primary one is destroyed.




4. How many "master" can I use?

Technically there could be 65536 different masters in 389-ds replication
topology.


5. If I have a network like this:

A1__B1
A2  B2

A2 and B1,2 are replicated from A1

If the connection gets lost between A and B site, are B1 and 2 (and
A1,2) replicated fine?

I assume from the above that B1 does not know about B2 (and vice versa)?
Once connectivity between sites A and B restored, all unreplicated data
will be replicated. There could be conflicts if there were changes on
both sides during the split but majority of them are solved
automatically by 389-ds.


6. If a client is installed with ipa-client-install using A1 and A1 gets
lost, does the client know, where it needs to connect (failover..)?

IPA server which was used to enroll the host will be primary one (A1 in
your example). There is failover in sssd.conf to use SRV records of the
domain, and trying servers in the order returned by the SRV records.


7. Can I install slave (read-only) replicas so clients access them only
for queries and for changes (like pw change) they access master servers?

No read-only replicas available for IPA. All replicas are read-write and
propagate changes across replication paths as defined in replication
agreements. All IPA servers are really masters, thus we have
multi-master replication rather than master-slave.



___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

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

2013-11-05 Thread Rich Megginson 

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.



freeipa-admintools-3.3.2-1.fc19.x86_64
freeipa-client-3.3.2-1.fc19.x86_64
freeipa-python-3.3.2-1.fc19.x86_64
freeipa-server-3.3.2-1.fc19.x86_64
libipa_hbac-1.11.1-4.fc19.x86_64
libipa_hbac-python-1.11.1-4.fc19.x86_64
sssd-ipa-1.11.1-4.fc19.x86_64
389-ds-base-libs-1.3.1.12-1.fc19.x86_64
389-ds-base-1.3.1.12-1.fc19.x86_64

Linux ipa31.bph.cxn 3.11.6-201.fc19.x86_64 #1 SMP Sat Nov 2 14:09:09 UTC
2013 x86_64 x86_64 x86_64 GNU/Linux
Fedora 19.


How can I fix it?


ldapmodify -x -D "cn=directory manager" -W <


Thanks,
tamas



___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

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

2013-11-05 Thread Tamas Papp 
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.

freeipa-admintools-3.3.2-1.fc19.x86_64
freeipa-client-3.3.2-1.fc19.x86_64
freeipa-python-3.3.2-1.fc19.x86_64
freeipa-server-3.3.2-1.fc19.x86_64
libipa_hbac-1.11.1-4.fc19.x86_64
libipa_hbac-python-1.11.1-4.fc19.x86_64
sssd-ipa-1.11.1-4.fc19.x86_64
389-ds-base-libs-1.3.1.12-1.fc19.x86_64
389-ds-base-1.3.1.12-1.fc19.x86_64

Linux ipa31.bph.cxn 3.11.6-201.fc19.x86_64 #1 SMP Sat Nov 2 14:09:09 UTC
2013 x86_64 x86_64 x86_64 GNU/Linux
Fedora 19.


How can I fix it?


Thanks,
tamas

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

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

2013-11-05 Thread Tamas Papp 

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.

>>
>> freeipa-admintools-3.3.2-1.fc19.x86_64
>> freeipa-client-3.3.2-1.fc19.x86_64
>> freeipa-python-3.3.2-1.fc19.x86_64
>> freeipa-server-3.3.2-1.fc19.x86_64
>> libipa_hbac-1.11.1-4.fc19.x86_64
>> libipa_hbac-python-1.11.1-4.fc19.x86_64
>> sssd-ipa-1.11.1-4.fc19.x86_64
>> 389-ds-base-libs-1.3.1.12-1.fc19.x86_64
>> 389-ds-base-1.3.1.12-1.fc19.x86_64
>>
>> Linux ipa31.bph.cxn 3.11.6-201.fc19.x86_64 #1 SMP Sat Nov 2 14:09:09 UTC
>> 2013 x86_64 x86_64 x86_64 GNU/Linux
>> Fedora 19.
>>
>>
>> How can I fix it?
>
> ldapmodify -x -D "cn=directory manager" -W < dn: cn=config
> changetype: modify
> replace: nsslapd-ignore-time-skew
> nsslapd-ignore-time-skew: on
> EOF
>
> Do this on all of your servers.

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?


Thanks,
tamas

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

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

2013-11-05 Thread Tamas Papp 

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.


tamas

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

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

2013-11-05 Thread Rich Megginson 

On 11/05/2013 01:03 PM, 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.


freeipa-admintools-3.3.2-1.fc19.x86_64
freeipa-client-3.3.2-1.fc19.x86_64
freeipa-python-3.3.2-1.fc19.x86_64
freeipa-server-3.3.2-1.fc19.x86_64
libipa_hbac-1.11.1-4.fc19.x86_64
libipa_hbac-python-1.11.1-4.fc19.x86_64
sssd-ipa-1.11.1-4.fc19.x86_64
389-ds-base-libs-1.3.1.12-1.fc19.x86_64
389-ds-base-1.3.1.12-1.fc19.x86_64

Linux ipa31.bph.cxn 3.11.6-201.fc19.x86_64 #1 SMP Sat Nov 2 14:09:09 UTC
2013 x86_64 x86_64 x86_64 GNU/Linux
Fedora 19.


How can I fix it?

ldapmodify -x -D "cn=directory manager" -W <
I tried this, but no joy. Still not good:/


Can you describe the exact steps you took, on all replicas?



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?


Thanks,
tamas


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

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

2013-11-05 Thread Rob Crittenden 

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.




freeipa-admintools-3.3.2-1.fc19.x86_64
freeipa-client-3.3.2-1.fc19.x86_64
freeipa-python-3.3.2-1.fc19.x86_64
freeipa-server-3.3.2-1.fc19.x86_64
libipa_hbac-1.11.1-4.fc19.x86_64
libipa_hbac-python-1.11.1-4.fc19.x86_64
sssd-ipa-1.11.1-4.fc19.x86_64
389-ds-base-libs-1.3.1.12-1.fc19.x86_64
389-ds-base-1.3.1.12-1.fc19.x86_64

Linux ipa31.bph.cxn 3.11.6-201.fc19.x86_64 #1 SMP Sat Nov 2 14:09:09 UTC
2013 x86_64 x86_64 x86_64 GNU/Linux
Fedora 19.


How can I fix it?


ldapmodify -x -D "cn=directory manager" -W <

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?


rob

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

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

2013-11-05 Thread 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


to


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

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

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

2013-11-05 Thread Tamas Papp 

On 11/05/2013 09:25 PM, Rich Megginson wrote:
> On 11/05/2013 01:03 PM, 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.
>>
 freeipa-admintools-3.3.2-1.fc19.x86_64
 freeipa-client-3.3.2-1.fc19.x86_64
 freeipa-python-3.3.2-1.fc19.x86_64
 freeipa-server-3.3.2-1.fc19.x86_64
 libipa_hbac-1.11.1-4.fc19.x86_64
 libipa_hbac-python-1.11.1-4.fc19.x86_64
 sssd-ipa-1.11.1-4.fc19.x86_64
 389-ds-base-libs-1.3.1.12-1.fc19.x86_64
 389-ds-base-1.3.1.12-1.fc19.x86_64

 Linux ipa31.bph.cxn 3.11.6-201.fc19.x86_64 #1 SMP Sat Nov 2
 14:09:09 UTC
 2013 x86_64 x86_64 x86_64 GNU/Linux
 Fedora 19.


 How can I fix it?
>>> ldapmodify -x -D "cn=directory manager" -W <>> dn: cn=config
>>> changetype: modify
>>> replace: nsslapd-ignore-time-skew
>>> nsslapd-ignore-time-skew: on
>>> EOF
>>>
>>> Do this on all of your servers.
>> I tried this, but no joy. Still not good:/
>
> Can you describe the exact steps you took, on all replicas?

I created ldif files:

# cat replication_ignore-time-skew.ldif
dn: cn=config
changetype: modify
replace: nsslapd-ignore-time-skew
nsslapd-ignore-time-skew: on

Then:

$ ldapmodify -x -D "cn=directory manager" -W -f
replication_ignore-time-skew.ldif



But I don't see the changes:

# ldapsearch -x|grep -i ignore
#

Probably you realized, I'm not an ldap expert:)
But I assume it's because it doesn't exist right now, therefore it
should be add ot modify?

I don't wan't to try it now, because currently it's working. Maybe when
it gets fail again.


Thanks,
tamas

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

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

2013-11-05 Thread Tamas Papp 

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.

Eventually you were right, it looks, that the problem is related to the
virtualization, thanks for the tip.

Although I wouldn't say, it's because of messy VMs. It definitely must
be a software bug or misconfiguration, otherwise a VM should always
looks the same as a bare metal machine.

Actually in my specific case I don't see the reason, why it is working
withand not with  if
the time in the VM synchronized after bootup.
It looks a software bug to me. But using UTC on (only) one machine is
definitely a misconfiguration:)


Thanks,
tamas

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

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

2013-11-05 Thread Tamas Papp 

On 11/05/2013 03:17 PM, Rich Megginson wrote:
>
>>> 2. What is the difference between 'primary' and 'secondary'. What does
>>> happen, if the primary machine gets destroyed?
>> In IPA all replicas are the same, they only would differ by the paths
>> they sync with each other and by presence of integrated CA (if any).

Do I need CA in normal cases or is it just an additional and optional
service? In other words is this CA the same as used by replicas and
clients and the UI..etc?

>> If you have deployed original IPA server with integrated CA, then your
>> other replicas better to have at least one with CA configured to allow
>> proper recovery in case primary one is destroyed.

Is there any caveats to not deploy CA on all replicas as a simples solution?

>>> 4. How many "master" can I use?
>> Technically there could be 65536 different masters in 389-ds replication
>> topology.

Perfect!

>>
>>> 5. If I have a network like this:
>>>
>>> A1__B1
>>> A2  B2
>>>
>>> A2 and B1,2 are replicated from A1
>>>
>>> If the connection gets lost between A and B site, are B1 and 2 (and
>>> A1,2) replicated fine?
>> I assume from the above that B1 does not know about B2 (and vice versa)?

Well, that is actually one of the questions. B1 and B2 are on the same
sites and failover nodes from point of view of clients.

>> Once connectivity between sites A and B restored, all unreplicated data
>> will be replicated. There could be conflicts if there were changes on
>> both sides during the split but majority of them are solved
>> automatically by 389-ds.

The main question is that B1 and B2 are not replicated to each other
automatically? What about the case if

A1 -- replication -- A2 --- replication --- B1 -- replication -- B2

If B1 gets destroyed, how B2 and A2 (and A1) gets synchronized?
Especially automatically...?
Is there such a failover configuration?

>>> 6. If a client is installed with ipa-client-install using A1 and A1
>>> gets
>>> lost, does the client know, where it needs to connect (failover..)?
>> IPA server which was used to enroll the host will be primary one (A1 in
>> your example). There is failover in sssd.conf to use SRV records of the
>> domain, and trying servers in the order returned by the SRV records.

Ahh. Then if I use external DNS, I need to configure these srv records
manually, that's all, right?

>>> 7. Can I install slave (read-only) replicas so clients access them only
>>> for queries and for changes (like pw change) they access master
>>> servers?
>> No read-only replicas available for IPA. All replicas are read-write and
>> propagate changes across replication paths as defined in replication
>> agreements. All IPA servers are really masters, thus we have
>> multi-master replication rather than master-slave.


Perfect, thanks for the clarification!

Thanks,
tamas

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

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

2013-11-05 Thread Rich Megginson 

On 11/05/2013 04:34 PM, 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.

Eventually you were right, it looks, that the problem is related to the
virtualization, thanks for the tip.

Although I wouldn't say, it's because of messy VMs. It definitely must
be a software bug or misconfiguration, otherwise a VM should always
looks the same as a bare metal machine.

Actually in my specific case I don't see the reason, why it is working
withand not with  if
the time in the VM synchronized after bootup.

You can file a ticket.

It looks a software bug to me. But using UTC on (only) one machine is
definitely a misconfiguration:)


Thanks,
tamas


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

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

2013-11-05 Thread Rich Megginson 

On 11/05/2013 04:23 PM, Tamas Papp wrote:

On 11/05/2013 09:25 PM, Rich Megginson wrote:

On 11/05/2013 01:03 PM, 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.


freeipa-admintools-3.3.2-1.fc19.x86_64
freeipa-client-3.3.2-1.fc19.x86_64
freeipa-python-3.3.2-1.fc19.x86_64
freeipa-server-3.3.2-1.fc19.x86_64
libipa_hbac-1.11.1-4.fc19.x86_64
libipa_hbac-python-1.11.1-4.fc19.x86_64
sssd-ipa-1.11.1-4.fc19.x86_64
389-ds-base-libs-1.3.1.12-1.fc19.x86_64
389-ds-base-1.3.1.12-1.fc19.x86_64

Linux ipa31.bph.cxn 3.11.6-201.fc19.x86_64 #1 SMP Sat Nov 2
14:09:09 UTC
2013 x86_64 x86_64 x86_64 GNU/Linux
Fedora 19.


How can I fix it?

ldapmodify -x -D "cn=directory manager" -W <
I tried this, but no joy. Still not good:/

Can you describe the exact steps you took, on all replicas?

I created ldif files:

# cat replication_ignore-time-skew.ldif
dn: cn=config
changetype: modify
replace: nsslapd-ignore-time-skew
nsslapd-ignore-time-skew: on

Then:

$ ldapmodify -x -D "cn=directory manager" -W -f
replication_ignore-time-skew.ldif



But I don't see the changes:

# ldapsearch -x|grep -i ignore
ldapsearch -x -D "cn=directory manager" -W -s base -b cn=config 
'objectclass=*' nsslapd-ignore-time-skew

#

Probably you realized, I'm not an ldap expert:)
But I assume it's because it doesn't exist right now, therefore it
should be add ot modify?

It is always ok to do a changetype: modify replace


I don't wan't to try it now, because currently it's working. Maybe when
it gets fail again.

Ok.



Thanks,
tamas


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

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

2013-11-05 Thread Rob Crittenden 

Tamas Papp wrote:


On 11/05/2013 03:17 PM, Rich Megginson wrote:



2. What is the difference between 'primary' and 'secondary'. What does
happen, if the primary machine gets destroyed?

In IPA all replicas are the same, they only would differ by the paths
they sync with each other and by presence of integrated CA (if any).


Do I need CA in normal cases or is it just an additional and optional
service? In other words is this CA the same as used by replicas and
clients and the UI..etc?


Yes and since you are planning for replication you should plan to have 
at least one of the replica have a CA on it as well to avoid a single 
point of failure.





If you have deployed original IPA server with integrated CA, then your
other replicas better to have at least one with CA configured to allow
proper recovery in case primary one is destroyed.


Is there any caveats to not deploy CA on all replicas as a simples solution?


You don't need a CA on every single replica, but you probably want at 
least two.





4. How many "master" can I use?

Technically there could be 65536 different masters in 389-ds replication
topology.


Perfect!


The 389-ds team has fully QA'd 20 masters at a time, so keep that in mind.

Also, replication is not free. It requires space to store the changes to 
send out, CPU time to calculate whom to send what and network bandwidth 
to share the data. Each master you add increases this workload.


Not to mention any administrative burden of running a lot of masters.






5. If I have a network like this:

A1__B1
A2  B2

A2 and B1,2 are replicated from A1

If the connection gets lost between A and B site, are B1 and 2 (and
A1,2) replicated fine?

I assume from the above that B1 does not know about B2 (and vice versa)?


Well, that is actually one of the questions. B1 and B2 are on the same
sites and failover nodes from point of view of clients.


You can manage the replication topology with ipa-replica-manage connect 
and disconnect.  So if you want B1 and B2 connected you can do that.





Once connectivity between sites A and B restored, all unreplicated data
will be replicated. There could be conflicts if there were changes on
both sides during the split but majority of them are solved
automatically by 389-ds.


The main question is that B1 and B2 are not replicated to each other
automatically? What about the case if

A1 -- replication -- A2 --- replication --- B1 -- replication -- B2

If B1 gets destroyed, how B2 and A2 (and A1) gets synchronized?
Especially automatically...?
Is there such a failover configuration?


No, the masters only replicate to the ones you tell them to, so if B1 
went away forever then B2 would never get any other updates unless you 
explicitly made a connection to A1 or A2.





6. If a client is installed with ipa-client-install using A1 and A1
gets
lost, does the client know, where it needs to connect (failover..)?

IPA server which was used to enroll the host will be primary one (A1 in
your example). There is failover in sssd.conf to use SRV records of the
domain, and trying servers in the order returned by the SRV records.


Ahh. Then if I use external DNS, I need to configure these srv records
manually, that's all, right?


Right.




7. Can I install slave (read-only) replicas so clients access them only
for queries and for changes (like pw change) they access master
servers?

No read-only replicas available for IPA. All replicas are read-write and
propagate changes across replication paths as defined in replication
agreements. All IPA servers are really masters, thus we have
multi-master replication rather than master-slave.



Perfect, thanks for the clarification!

Thanks,
tamas

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users



___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

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

2013-11-06 Thread Dmitri Pal 
On 11/05/2013 10:16 PM, Rob Crittenden wrote:
>>
 If you have deployed original IPA server with integrated CA, then your
 other replicas better to have at least one with CA configured to allow
 proper recovery in case primary one is destroyed.
>>
>> Is there any caveats to not deploy CA on all replicas as a simples
>> solution?
>
> You don't need a CA on every single replica, but you probably want at
> least two.
>
It is important to understand that CA is crucial to IPA so if for some
reason you loose all the replicas that have CA you are facing a
redeployment.
This is why we suggest having "enough" replicas with CA and also to do
periodically snapshot one of the replicas with CA so that everything is
lost you can recover from the snapshot.
We are working on a more comprehensive disaster recovery document but it
is worth mentioning it here.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

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

2013-11-06 Thread Tamas Papp 

On 11/06/2013 02:08 AM, Rich Megginson wrote:
> On 11/05/2013 04:23 PM, Tamas Papp wrote:
>> On 11/05/2013 09:25 PM, Rich Megginson wrote:
>>> On 11/05/2013 01:03 PM, 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.

>> freeipa-admintools-3.3.2-1.fc19.x86_64
>> freeipa-client-3.3.2-1.fc19.x86_64
>> freeipa-python-3.3.2-1.fc19.x86_64
>> freeipa-server-3.3.2-1.fc19.x86_64
>> libipa_hbac-1.11.1-4.fc19.x86_64
>> libipa_hbac-python-1.11.1-4.fc19.x86_64
>> sssd-ipa-1.11.1-4.fc19.x86_64
>> 389-ds-base-libs-1.3.1.12-1.fc19.x86_64
>> 389-ds-base-1.3.1.12-1.fc19.x86_64
>>
>> Linux ipa31.bph.cxn 3.11.6-201.fc19.x86_64 #1 SMP Sat Nov 2
>> 14:09:09 UTC
>> 2013 x86_64 x86_64 x86_64 GNU/Linux
>> Fedora 19.
>>
>>
>> How can I fix it?
> ldapmodify -x -D "cn=directory manager" -W < dn: cn=config
> changetype: modify
> replace: nsslapd-ignore-time-skew
> nsslapd-ignore-time-skew: on
> EOF
>
> Do this on all of your servers.
 I tried this, but no joy. Still not good:/
>>> Can you describe the exact steps you took, on all replicas?
>> I created ldif files:
>>
>> # cat replication_ignore-time-skew.ldif
>> dn: cn=config
>> changetype: modify
>> replace: nsslapd-ignore-time-skew
>> nsslapd-ignore-time-skew: on
>>
>> Then:
>>
>> $ ldapmodify -x -D "cn=directory manager" -W -f
>> replication_ignore-time-skew.ldif
>>
>>
>>
>> But I don't see the changes:
>>
>> # ldapsearch -x|grep -i ignore
> ldapsearch -x -D "cn=directory manager" -W -s base -b cn=config
> 'objectclass=*' nsslapd-ignore-time-skew

You're right, I tried it with wrong base dn.

Thanks,
tamas

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

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

2013-11-06 Thread Tamas Papp 

On 11/06/2013 02:07 AM, Rich Megginson wrote:
> On 11/05/2013 04:34 PM, 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.
>> Eventually you were right, it looks, that the problem is related to the
>> virtualization, thanks for the tip.
>>
>> Although I wouldn't say, it's because of messy VMs. It definitely must
>> be a software bug or misconfiguration, otherwise a VM should always
>> looks the same as a bare metal machine.
>>
>> Actually in my specific case I don't see the reason, why it is working
>> withand not with  if
>> the time in the VM synchronized after bootup.
> You can file a ticket.

I'm not absolutely sure, that this was the root cause of the problem.

tamas

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

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

2013-11-06 Thread Tamas Papp 

On 11/06/2013 04:16 AM, Rob Crittenden wrote:
>
>>

> 5. If I have a network like this:
>
> A1__B1
> A2  B2
>
> A2 and B1,2 are replicated from A1
>
> If the connection gets lost between A and B site, are B1 and 2 (and
> A1,2) replicated fine?
 I assume from the above that B1 does not know about B2 (and vice
 versa)?
>>
>> Well, that is actually one of the questions. B1 and B2 are on the same
>> sites and failover nodes from point of view of clients.
>
> You can manage the replication topology with ipa-replica-manage
> connect and disconnect.  So if you want B1 and B2 connected you can do
> that.
>
>>
 Once connectivity between sites A and B restored, all unreplicated
 data
 will be replicated. There could be conflicts if there were changes on
 both sides during the split but majority of them are solved
 automatically by 389-ds.
>>
>> The main question is that B1 and B2 are not replicated to each other
>> automatically? What about the case if
>>
>> A1 -- replication -- A2 --- replication --- B1 -- replication -- B2
>>
>> If B1 gets destroyed, how B2 and A2 (and A1) gets synchronized?
>> Especially automatically...?
>> Is there such a failover configuration?
>
> No, the masters only replicate to the ones you tell them to, so if B1
> went away forever then B2 would never get any other updates unless you
> explicitly made a connection to A1 or A2.

Can the replication agreement be circular?

*A2*-A1-B1-B2-*A**2*?



Thanks,
tamas
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

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

2013-11-06 Thread Rich Megginson 

On 11/06/2013 06:41 AM, Tamas Papp wrote:


On 11/06/2013 04:16 AM, Rob Crittenden wrote:







5. If I have a network like this:

A1__B1
A2  B2

A2 and B1,2 are replicated from A1

If the connection gets lost between A and B site, are B1 and 2 (and
A1,2) replicated fine?
I assume from the above that B1 does not know about B2 (and vice 
versa)?


Well, that is actually one of the questions. B1 and B2 are on the same
sites and failover nodes from point of view of clients.


You can manage the replication topology with ipa-replica-manage 
connect and disconnect.  So if you want B1 and B2 connected you can 
do that.




Once connectivity between sites A and B restored, all unreplicated 
data

will be replicated. There could be conflicts if there were changes on
both sides during the split but majority of them are solved
automatically by 389-ds.


The main question is that B1 and B2 are not replicated to each other
automatically? What about the case if

A1 -- replication -- A2 --- replication --- B1 -- replication -- B2

If B1 gets destroyed, how B2 and A2 (and A1) gets synchronized?
Especially automatically...?
Is there such a failover configuration?


No, the masters only replicate to the ones you tell them to, so if B1 
went away forever then B2 would never get any other updates unless 
you explicitly made a connection to A1 or A2.


Can the replication agreement be circular?

*A2*-A1-B1-B2-*A**2*?


Yes.





Thanks,
tamas


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users