Ran the suggested command from the primary (master) IPA:
[root@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@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 
  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

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

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@ipaN1 ~]# cat /etc/resolv.conf                                            
search localdomain

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

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

Just for chance I ran the query again and voila:
[root@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 
  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.auerb...@flbog.edu | www.flbog.edu

-----Original Message-----
From: Rob Crittenden [mailto:rcrit...@redhat.com] 
Sent: Thursday, February 05, 2015 4:10 PM
To: Auerbach, Steven; IPA User Maillist (freeipa-users@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.


Manage your subscription for the Freeipa-users mailing list:
Go To http://freeipa.org for more info on the project

Reply via email to