[Freeipa-users] replication - original master not replicating

[Rob Crittenden]

Jim Kinney wrote:
> 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 <mailto: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 <mailto: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 <mailto: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.

Yeah. You can see the actual agreements by binding as cn=Directory
Manager and searching in cn=mapping tree, cn=config. We'd had to see the
agreement to really know what's going on, but it shouldn't affect
sending data to the other masters.

So it looks like vinz is communicating ok with prod01 so the data should
be getting shared ok, esp since prod01 and beast have agreements.

I'd start by checking on the replication agreement between vinz and
beast. The error 32 is a bit odd in itself. The 389-ds error log may
contain more information.

rob