[Freeipa-users] I think I have an issue, but maybe not.....Is IPA Replica Clean-up Needed?

[Auerbach, Steven]

We have IPA set up in active-active mode.  The first node (ipa01) logs errors regularly (every few minutes) that seem to be based upon an attempt to communicate with a replica that no longer exists.

Feb 25 14:38:04 ipa01 named[2161]: LDAP query timed out. Try to adjust "timeout" parameter
Feb 25 14:38:04 ipa01 named[2161]: LDAP query timed out. Try to adjust "timeout" parameter
Feb 25 14:38:14 ipa01 named[2161]: LDAP query timed out. Try to adjust "timeout" parameter
Feb 25 14:38:14 ipa01 named[2161]: LDAP query timed out. Try to adjust "timeout" parameter
Feb 25 14:38:22 ipa01 ns-slapd: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Cannot contact any KDC for <<REALM>> '<<REALM>>.LOCAL')
Feb 25 14:38:35 ipa01 named[2161]: LDAP query timed out. Try to adjust "timeout" parameter
Feb 25 14:38:35 ipa01 named[2161]: LDAP query timed out. Try to adjust "timeout" parameter
Feb 25 14:38:45 ipa01 named[2161]: LDAP query timed out. Try to adjust "timeout" parameter
Feb 25 14:38:45 ipa01 named[2161]: LDAP query timed out. Try to adjust "timeout" parameter
Feb 25 14:38:45 ipa01 ns-slapd: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Server ldap/ipa02.<<REALM>>.local@<<REALM>>.LOCAL not found in Kerberos database)

The only place I found any references to the server ipa02 is in dse.ldif files in the /etc/dirsrv/slapd-<<REALM>>-LOCAL/ folders

Quoted from dse.ldif:
dn: cn=replica,cn=dc\3D<<REALM>>\2Cdc\3Dlocal,cn=mapping tree,cn=config
cn: replica
nsDS5Flags: 1
objectClass: top
objectClass: nsds5replica
objectClass: extensibleobject
nsDS5ReplicaType: 3
nsDS5ReplicaRoot: dc=<<REALM>>,dc=local
nsds5ReplicaLegacyConsumer: off
nsDS5ReplicaId: 4
nsDS5ReplicaBindDN: cn=replication manager,cn=config
nsDS5ReplicaBindDN: krbprincipalname=ldap/ipa02.<<REALM>>.local@<<REALM>>.LOCAL,cn=services,cn=accounts,dc=<<REALM>>,dc=local
nsDS5ReplicaBindDN: krbprincipalname=ldap/ipa-r02.<<REALM>>.local@<<REALM>>.LOCAL,cn=services,cn=accounts,dc=<<REALM>>,dc=local
creatorsName: cn=directory manager
modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config
createTimestamp: 20130924144354Z
modifyTimestamp: 20160225194116Z
nsState:: BAAAAAAAAADcWM9WAAAAAAEAAAAAAAAAZQAAAAAAAAADAAAAAAAAAA==
nsDS5ReplicaName: a5641a0e-252711e3-96afcc83-6ff9b802
numSubordinates: 1


When I execute "ipa-replica-manage list" from either the master or replica server I get the same response:
ipa01.<<REALM>>.local: master
ipa-r02.<<REALM>>.local: master

and when I execute "ipa-csreplica-manage list" from either the master or the replica server I get the same response:
ipa01.<<REALM>>.local: master
ipa-r02.<<REALM>>.local: CA not configured

I would have expected one of these commands to include the "ipa02" server as well since it is in the dse.ldif file.

I know we are configured in "active-active" mode and that the CA is only on ipa01.

>From an operating perspective, identity management operations (including signing on to the browser-based interface and updates made one server showing up on the other) from the replica (ipa-r02) are much faster than from the master (ipa01). I am guessing that this is because any task executing on the replica has only a replica pointer to the master, whereas any operation on the master that tries to replicate has to timeout on the invalid pointer to "ipa02" before it can actually communicate with the replica (ipa-r02).  Of course my intuition could be completely wrong and my actual understanding of how this process works is nil.

I would like to clean up this environment before I hand the reins over to the next person on my team.

So my questions are:

1)    Is there a way to remove the invalid pointer without having to disrupt services on the ipa01?

2)    Do I need to clean this up in this location at all?

Thanks for your interest.


Steven Auerbach, Systems Administrator
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20160303/89e36e87/attachment.htm>