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-Designing_the_Replication_Process-Common_Replication_Scenarios.html#Deployment_Guide-Multi_Master_Replication-Multi_Master_Replication_Configuration_A_Four_Suppliers > > * 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@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
