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
<http://ipa31.bph.cxn/ipa/config/unauthorized.html> 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
