[Freeipa-users] replication - original master not replicating

[Jim Kinney]

On Wed, 2014-09-03 at 13:48 -0400, Rob Crittenden wrote:

> Jim Kinney wrote:
> > 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.
> 
> On each master I'd run:
> 
> # ipa-replica-manage list -v `hostname`
> 
> This will give you the replication status on each.
> 
> rob
> 

OK. Interesting results. #1 is vinz, #2 is prod01, #3 is beast :
[root at vinz etc]# ipa-replica-manage list -v `hostname`
beast.cci.emory.edu: replica
  last init status: None
  last init ended: None
  last update status: 32  - LDAP error: No such object
  last update ended: None
prod01.cci.emory.edu: replica
  last init status: None
  last init ended: None
  last update status: 0 Replica acquired successfully: Incremental
update succeeded
  last update ended: 2014-09-03 17:53:07+00:00
vinz.cci.emory.edu: replica
  last init status: None
  last init ended: None
  last update status: -1 Incremental update has failed and requires
administrator actionLDAP error: Can't contact LDAP server
  last update ended: None


[root at prod01 ~]# ipa-replica-manage list -v `hostname`
beast.cci.emory.edu: replica
  last init status: 0 Total update succeeded
  last init ended: 2014-08-20 15:58:38+00:00
  last update status: 0 Replica acquired successfully: Incremental
update succeeded
  last update ended: 2014-09-03 17:54:20+00:00
vinz.cci.emory.edu: replica
  last init status: None
  last init ended: None
  last update status: 0 Replica acquired successfully: Incremental
update succeeded
  last update ended: 2014-09-03 17:54:20+00:00


[root at beast ~]# ipa-replica-manage list -v `hostname`
prod01.cci.emory.edu: replica
  last init status: None
  last init ended: None
  last update status: 0 Replica acquired successfully: Incremental
update started
  last update ended: None
vinz.cci.emory.edu: replica
  last init status: None
  last init ended: None
  last update status: 0 Replica acquired successfully: Incremental
update started
  last update ended: None


It looks like vinz is trying to replicate to itself.

-- 

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/d7bde29d/attachment.htm>