<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="EN-US" link="#0563C1" vlink="#954F72"> <div class="WordSection1"> My IPA LDAP/CS Master logs errors regularly (every few minutes) that seem o be based upon an attempt to communicate with a replica that no longer exists.<o:p></o:p> <o:p> </o:p> Feb 25 14:38:04 ipa01 named[2161]: LDAP query timed out. Try to adjust "timeout" parameter<o:p></o:p> Feb 25 14:38:04 ipa01 named[2161]: LDAP query timed out. Try to adjust "timeout" parameter<o:p></o:p> Feb 25 14:38:14 ipa01 named[2161]: LDAP query timed out. Try to adjust "timeout" parameter<o:p></o:p> Feb 25 14:38:14 ipa01 named[2161]: LDAP query timed out. Try to adjust "timeout" parameter<o:p></o:p> 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')<o:p></o:p> Feb 25 14:38:35 ipa01 named[2161]: LDAP query timed out. Try to adjust "timeout" parameter<o:p></o:p> Feb 25 14:38:35 ipa01 named[2161]: LDAP query timed out. Try to adjust "timeout" parameter<o:p></o:p> Feb 25 14:38:45 ipa01 named[2161]: LDAP query timed out. Try to adjust "timeout" parameter<o:p></o:p> Feb 25 14:38:45 ipa01 named[2161]: LDAP query timed out. Try to adjust "timeout" parameter<o:p></o:p> 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)<o:p></o:p> <o:p> </o:p> The only place I found any references to the server ipa02 is in dse.ldif files in the /etc/dirsrv/slapd-REALM-LOCAL/ folders<o:p></o:p> <o:p> </o:p> Quote from dse.ldif:<o:p></o:p> dn: cn=replica,cn=dc\3Drealm\2Cdc\3Dlocal,cn=mapping tree,cn=config<o:p></o:p> cn: replica<o:p></o:p> nsDS5Flags: 1<o:p></o:p> objectClass: top<o:p></o:p> objectClass: nsds5replica<o:p></o:p> objectClass: extensibleobject<o:p></o:p> nsDS5ReplicaType: 3<o:p></o:p> nsDS5ReplicaRoot: dc=realm,dc=local<o:p></o:p> nsds5ReplicaLegacyConsumer: off<o:p></o:p> nsDS5ReplicaId: 4<o:p></o:p> nsDS5ReplicaBindDN: cn=replication manager,cn=config<o:p></o:p> nsDS5ReplicaBindDN: krbprincipalname=ldap/ipa02.realm.local@REALM.LOCAL,cn=servi<o:p></o:p> ces,cn=accounts,dc=fbog,dc=local<o:p></o:p> nsDS5ReplicaBindDN: krbprincipalname=ldap/ipa-r02.realm.local@REALM.LOCAL,cn=ser<o:p></o:p> vices,cn=accounts,dc=realm,dc=local<o:p></o:p> creatorsName: cn=directory manager<o:p></o:p> modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config<o:p></o:p> createTimestamp: 20130924144354Z<o:p></o:p> modifyTimestamp: 20160225194116Z<o:p></o:p> nsState:: BAAAAAAAAADcWM9WAAAAAAEAAAAAAAAAZQAAAAAAAAADAAAAAAAAAA==<o:p></o:p> nsDS5ReplicaName: a5641a0e-252711e3-96afcc83-6ff9b802<o:p></o:p> numSubordinates: 1<o:p></o:p> <o:p> </o:p> <o:p> </o:p> When I execute “ipa-replica-manage list” from either the master or replica server I get the same response:<o:p></o:p> ipa01.realm.local: master<o:p></o:p> ipa-r02.realm.local: master<o:p></o:p> <o:p> </o:p> and when I execute “ipa-csreplica-manage list” from either the master or the replica server I get the same response:<o:p></o:p> ipa01.fbog.local: master<o:p></o:p> ipa-r02.fbog.local: CA not configured<o:p></o:p> <o:p> </o:p> I know we are configured in “multi-master” mode and that the CA is only on the master. I would have expected one of these commands to include the “ipa02” server as well since it is in the dse.ldif file.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> 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 intuiting 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.<o:p></o:p> <o:p> </o:p> I would like to clean up this environment, however, before I hand the reins over to the next person on my team.<o:p></o:p> <o:p> </o:p> So my question is: What is the best way to remove the invalid pointer without having to disrupt services on the master?<o:p></o:p> <o:p> </o:p> <o:p> </o:p> Steven Auerbach<o:p></o:p> Systems Administrator<o:p></o:p> <o:p> </o:p> State University System of Florida<o:p></o:p> Board of Governors<o:p></o:p> 325 West Gaines Street, Suite 1625C<o:p></o:p> Tallahassee, Florida 32399<o:p></o:p> (850) 245-9592 <o:p> </o:p> <a href="steven.auerbach@flbog.edu">steven.auerbach@flbog.edu</a> | <a href="www.flbog.edu">www.flbog.edu</a><o:p></o:p> <img border="0" width="192" height="67" id="Picture_x0020_1" src="cid:image002.jpg@01D16FDD.87F83020" alt="BOG-wordmark-wideFOR EMAIL-color"><o:p></o:p> <o:p> </o:p> </div> </body> </html>