[Freeipa-users] Replication not happening for user password changes even after increasing the nsslapd-sasl-max-buffers to 2M

[Auerbach, Steven]

Ran the suggested command from the primary (master) IPA:
[root at ipaN1 ~]# ipa-replica-manage list -v ipaN1.xxxx.local
ipa-N2.xxxx.local: replica
  last init status: None
  last init ended: None
  last update status: -1  - LDAP error: Can't contact LDAP server
  last update ended: None

Then ran it from the replicant IPA:
[root at ipa-N2 ~]# ipa-replica-manage list -v ipa-N2.xxxx.local
Directory Manager password: <<entered it as required >>

ipaN1.xxxx.local: replica
  last init status: None
  last init ended: None
  last update status: 0 Replica acquired successfully: Incremental update succeeded
  last update ended: 2015-02-06 14:10:43+00:00


Not sure if the "last update status" is current state or last line of a log when an update was attempted, but double checked this morning that the user in question from yesterday still showed up with an unmatched password expiration date in the GUI of the replicant IPA.

So we stopped all IPA-related services on the master (# service ipa stop) waited a few, then restarted them (# service ipa start). Re-ran the query and the last update status message had not changed.

We ran an ldapsearch on each IPA server querying for nsds5ReplConflict and each responded the same:
# search result
search: 2
result: 0 Success

# numResponses: 1

Now we looked at the /etc/resolv.conf on the primary IP and found:
search localdomain
nameserver 8.8.8.8

so we manually edited the file (IPA primary is .206 and IPA replicant is .207):
search xxxx.local
nameserver 10.200.23.206
nameserver 10.200.23.207

and rebooted the server.

When it came back up we checked the /etc/resolv.conf and it had changed back to the values as before the manual edit.  I have never seen this resolver configuration file self-change behavior before on any Linux server and it confuses me. We edited the file again and rebooted again and it changed again.

Interestingly after the third reboot, where the /etc/resolv.conf ultimately looked like this:
[root at ipaN1 ~]# cat /etc/resolv.conf                                                                                          
search localdomain
nameserver 127.0.0.1 8.8.8.8

I was unable to ping an outside name:
[root at ipaN1 ~]# ping yahoo.com
ping: unknown host yahoo.com

But I was able to ping the IPA replicant:
[root at ipaN1 ~]# ping ipa-N2.xxxx.local
PING ipa-N2.xxxx.local (10.200.23.207) 56(84) bytes of data.
64 bytes from ipaN2.xxxx.local (10.200.23.207): icmp_seq=1 ttl=64 time=0.136 ms
64 bytes from ipaN2.xxxx.local (10.200.23.207): icmp_seq=2 ttl=64 time=0.206 ms
64 bytes from ipaN2.xxxx.local (10.200.23.207): icmp_seq=3 ttl=64 time=0.182 ms 

Just for chance I ran the query again and voila:
[root at ipaN1 ~]# ipa-replica-manage list -v ipaN1.xxxx.local                                          
ipa-N2.xxxx.local: replica
  last init status: None
  last init ended: None
  last update status: 0 Replica acquired successfully: Incremental update started
  last update ended: None


Replication took place.  I checked the user in question through GUI on the IPA replicant and the password expiration now matches the IPA primary.

What made the update finally happen?
Why if the /etc/resolv.conf rewriting? Should it point to outside interfaces of localhost / localdomain? 
Will replication continue across future changes or will I have to massage this every time?

This is so strange.


Steven Auerbach
Systems Administrator
State University System of Florida
Board of Governors
325 West Gaines Street
Tallahassee, Florida 32399
(850) 245-9592 | Fax (850) 245-0419
steven.auerbach at flbog.edu | www.flbog.edu




-----Original Message-----
From: Rob Crittenden [mailto:rcritten at redhat.com] 
Sent: Thursday, February 05, 2015 4:10 PM
To: Auerbach, Steven; IPA User Maillist (freeipa-users at redhat.com)
Cc: Ouellet, Dan
Subject: Re: [Freeipa-users] Replication not happening for user password changes even after increasing the nsslapd-sasl-max-buffers to 2M

Auerbach, Steven wrote:
> A user contacted me today for a password reset.  I made the reset on 
> the ipa-primary. The user opened a terminal session on an SSH Client 
> to a server in the realm and logged in. They received the required 
> immediate password change requirement and did so. They can log off and 
> log back on that same server with their new password.  They attempted 
> to open a terminal shell to another server in the realm. Their new 
> password is not accepted.
> 
>  
> 
> Both servers the user is attempting to connect to have the nameserver 
> resolution in the same order (resolv.conf).
> 
>  
> 
> On the ipa-primary their password expiration is 90 days from today.  
> On the ipa-replicant the password expiration is about 60 days out (I 
> did this with them Jan 13^th also but they lost their password.....). It 
> has been an hour since the user logged on to the server and made their 
> required change.
> 
>  
> 
> 2 questions arise:
> 
> How to safely update replicant with the password change without 
> changing the primary/replicant replationship order?
> 
> How to force the other server to refer to the ipa-primary to validate 
> the password?

It sounds like replication isn't working. On each master do this:

$ ipa-replica-manage list -v `hostname`

That will give you the replication status on both sides.

rob