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

[Rob Crittenden]

Auerbach, Steven wrote:
> 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

You should run it as this on each host:

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

This will show the current agreements it has and the status.

>  
> 
> 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

You should strongly consider adding a second CA. Right now you have a
single point of failure.


> 
> 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.

389-ds uses multi-master replication. active-active is typically a term
used with load balancers and clusters and this isn't really that.

>  
> 
> 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'm not intimately familiar with low-level 389-ds replication but I
don't believe it is done serially.

> 
> 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?

The ipa-replica-manage command will show the current agreements.
Removing a stale one won't affect operations.

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

If there is bogus agreement then yes. It is a resource drag as the
server needs to calculate and store any changes for something that will
never get sent.

rob

> 
>  
> 
> Thanks for your interest.
> 
>  
> 
>  
> 
> *Steven Auerbach, Systems Administrator*
> 
> 
>