[Freeipa-users] replication - original master not replicating

[Jim Kinney]

Greetings,

I'm running freeipa 3.0 with multimaster between 3 machines. The first
system, the original installation machine and thus the keepers of the
CA, etc, is not replicating with the other two. The other two are fine.
Additionally, the original machine is no longer using the freeIPA
running on it for authentication services.

Examples: I created a new user on the first machine using ipa
user-add .... and the other two systems didn't pick it up (even after an
overnight wait). So I thought it was not created. I then tried to create
the user again but on #2 machine on the web gui. It refused saying the
private group of that user already existed. It did not error about the
username. So I went to #1 and deleted the user. Back to #2 to create the
user and #3 picked it up within a minute. But #1 picked it up this time.

>From #1, running id on any user in the system returns a "No such user".
But when I go to the gui on #1, I can find users. The #1 system has
files sss in nsswitch for passwd, shadow, group, services, netgroup as
do #2 and #3. 

When I setup #2, I ran the ipa-ca-install on the generated file from the
#1 machine. So I think #2 now has the CA for my department. When I tried
to setup #3 by using #1 as the master, it would not connect/complete
back to #1. I replicated from #2 and it worked.

It's been several months (10+ or so) since I set up the #1 machine and
#2 was about 2 days after it.  I don't know if #1 always didn't use
freeIPA for authentication or not. 

#1 and #2 are CentOS 6.5. #3 is CentOS 7 and freeIPA 3.3. I was
concerned that the version mismatch would be an issue but it seems to
work well between #2 and #3. 

Clearly, if I add a user now, I use #2 or #3. I can get by with not
messing around with #1 and it's just for master CA needs. 

Oh. I have all three in DNS and #1 and #2 are DNS servers. #3 is in a
separate network segment and exists to provide auth services in the
(likely) event a network link goes down between that location and the
main stack.
-- 

Jim Kinney
Senior System Administrator
Department of BioMedical Informatics
Emory University
jimkinney at emory.edu
404.712.0300
bmi.emory.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140903/77574305/attachment.htm>