Re: [389-users] Bad Ber tag encountered and IO block timeout logconv.pl

[Rich Megginson]

Prashanth Sundaram wrote:
>  Hello all,
>
>  We have been experiencing some ldap timeout errors in a multi-master 
>  setup.
>
>  My setup looks close to this one but there is _NO_ M32 and M41 i.e 
>  consumers don;t replicate to masters
>
> http://www.redhat.com/docs/manuals/dir-server/8.1/deploy/Deployment_Guide...
>
>  * 2 Supplier servers with multi-master setup between the two.
>  * 2 consumer servers with multi-master setup between the two.
>  * Each supplier server has replication setup to each of the two 
>  consumer servers.(for redundancy)
>  * M1 & M2 authenticate users via PAM-PTA plugin to Active Directory.
>  * M3 & M4 use PTA plugin via SSL to authenticate via M1 & M2 in a 
>  redundant fashion.
>
>  BIGGEST ISSUE: Clients connecting to M3 and M4 are having “pam_ldap: 
>  ldap_result Timed out” error. Any ideas, how we can improve/fix this?
>
>  Configuration:
>  nsslapd-sizelimit: 16384
>  nsslapd-idletimeout: 7200
>  nssslapd-maxbersize: 0
>
>
>  Q1. Should I increase my nsslapd-maxbersize? 
I don't think that's your
problem. If it were, you'd get B2 Incoming BER 
Element too big messages in your logs.

In fact, you have it set to 0, which is the same as not setting it at 
all, which tells the server to use the default value of 2MB.
>  Q2. How do I restrict the ldap clients to bind only using LDAP v3? (I 
>  remembert reading it somewhere)
>  LDAP v2 Binds: 1006
>  LDAP v3 Binds: 9324 
I don't think there is a server setting to do this.
>  Q3. I use “uniquemember” as group membership attribute, but logs show 
>  filters like this. As far as I know, we don;t have any hard coded 
>  filters on any hosts. How to remove filter like this.
>
>
> (|(member=uid=kcapell,ou=people,dc=domain,dc=com)(uniquemember=uid=kcapell,ou=people,dc=domain,dc=com)(memberuid=kcapell))
man nss_ldap


>  I ran logconv.pl on M2 and here is what I found
>  ============================================================================
>  B1 75045 Bad Ber Tag Encountered 
Usually just means the client did a close() of the
socket rather than 
issuing an unbind request first. Usually ok.
>  U1 13456 Cleanly Closed Connections 
Client issued the unbind
request.
>  T2 160 IO Block Timeout Exceeded or NTSSL Timeout 
The server
timed out attempting to send results back to the client
>  T1 22 Idle Timeout Exceeded 
The server timed out waiting to
read more data from the client.
>  69409 10.1.1.2 * [ M1 ]
>  * 37611 - B1 Bad Ber Tag Encountered
>  3968 - U1 Cleanly Closed Connections
>  160 - T2 IO Block Timeout Exceeded or NTSSL Timeout
>
>  55326 10.1.1.3 *[ M2 ] *
>  27886 - B1 Bad Ber Tag Encountered
>  7 - U1 Cleanly Closed Connections
>
>  18096 10.1.0.7 * [old ldap server which was using pen-ldap to pass 
>  connection during migration ]
>  * 9531 - B1 Bad Ber Tag Encountered
>  8564 - U1 Cleanly Closed Connections
>
>  26 10.101.1.16 *[ M3 ]
>  * 20 - T1 Idle Timeout Exceeded
>  1 - B1 Bad Ber Tag Encountered
>
>  * Unknown Host
>  16 - B1 Bad Ber Tag Encountered
>  13 - U1 Cleanly Closed Connections
>  2 - T1 Idle Timeout Exceeded
>
>  1. You have unindexed searches, this can be caused from a search on an 
>  unindexed attribute, or your returned results exceeded the 
>  allidsthreshold. Unindexed searches are not recommended. To refuse 
>  unindexed searches, switch 'nsslapd-require-index' to 'on' under your 
>  database entry (e.g. cn=UserRoot,cn=ldbm database,cn=plugins,cn=config). 
The
logconv.pl script should tell you which searches took the longest times.
>  2. You have some connections that are are being closed by the 
>  idletimeout setting. You may want to increase the idletimeout if it is 
>  set low.
>
>  3. You have some coonections that are being closed by the 
>  ioblocktimeout setting. You may want to increase the ioblocktimeout.
>
>  4. You have a significant difference between binds and unbinds. You 
>  may want to investigate this difference. 
Client is doing close() instead of
unbind.
>  5. You have more abnormal connection codes than cleanly closed 
>  connections. You may want to investigate this difference.
>
>
>  ===============================================================
>
>  ------------------------------------------------------------------------
>
>  --
>  389 users mailing list
>  389-users(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/389-users