Ran the suggested command from the primary (master) IPA:
[root@ipaN1 ~]# ipa-replica-manage list -v ipaN1..local
ipa-N2..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..local
Directory Manager password: <>
ipaN1..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 .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@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@ipaN1 ~]# ping yahoo.com
ping: unknown host yahoo.com
But I was able to ping the IPA replicant:
[root@ipaN1 ~]# ping ipa-N2..local
PING ipa-N2..local (10.200.23.207) 56(84) bytes of data.
64 bytes from ipaN2..local (10.200.23.207): icmp_seq=1 ttl=64 time=0.136 ms
64 bytes from ipaN2..local (10.200.23.207): icmp_seq=2 ttl=64 time=0.206 ms
64 bytes from ipaN2..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@ipaN1 ~]# ipa-replica-manage list -v ipaN1..local
ipa-N2..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.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:
>
>
