hello

I would like to report one issue related to authldap module of authlib (we use courier-authlib-ldap-0.68.0-1). in normal situation the communication is working fine without issues, users get authenticated etc...

If I perform following steps:

1. start openldap

2. start courier-authlib

all is working fine. i.e. authlib connects to LDAP server and authenticates clients and uses LDAP as information about user mailboxes for maildrop.


issue start if openldap server will be unavailable for some short period of time (for example LDAP service restart, LDAP system reboot, whatever network issue...). once the openldap server is back available, the majority of LDAP connections between authlib and LDAP server are stucked with following error on openldap server side:

May 23 14:25:39 auth1 slapd[1328]: connection_input: conn=1015 deferring operation: pending operations May 23 14:25:39 auth1 slapd[1328]: connection_input: conn=1015 deferring operation: pending operations May 23 14:25:39 auth1 slapd[1328]: connection_input: conn=1015 deferring operation: pending operations May 23 14:25:39 auth1 slapd[1328]: connection_input: conn=1015 deferring operation: pending operations May 23 14:25:39 auth1 slapd[1328]: connection_input: conn=1015 deferring operation: too many executing May 23 14:25:39 auth1 slapd[1328]: connection_input: conn=1015 deferring operation: pending operations May 23 14:25:39 auth1 slapd[1328]: connection_input: conn=1015 deferring operation: pending operations May 23 14:25:39 auth1 slapd[1328]: connection_input: conn=1015 deferring operation: pending operations May 23 14:25:39 auth1 slapd[1328]: connection_input: conn=1015 deferring operation: pending operations May 23 14:25:39 auth1 slapd[1328]: connection_input: conn=1015 deferring operation: pending operations May 23 14:25:39 auth1 slapd[1328]: connection_input: conn=1015 deferring operation: pending operations May 23 14:25:39 auth1 slapd[1328]: connection_input: conn=1015 deferring operation: pending operations May 23 14:25:39 auth1 slapd[1328]: connection_input: conn=1015 deferring operation: pending operations May 23 14:25:39 auth1 slapd[1328]: connection_input: conn=1015 deferring operation: pending operations May 23 14:25:39 auth1 slapd[1328]: connection_input: conn=1015 deferring operation: pending operations May 23 14:25:39 auth1 slapd[1328]: connection_input: conn=1015 deferring operation: pending operations May 23 14:25:39 auth1 slapd[1328]: connection_input: conn=1015 deferring operation: pending operations May 23 14:25:39 auth1 slapd[1328]: connection_input: conn=1015 deferring operation: pending operations May 23 14:25:39 auth1 slapd[1328]: connection_input: conn=1015 deferring operation: pending operations

and this issue is in place (log events are reoccuring) until I do restart of authlib service (thus all existing connections to LDAP server will be closed).

this results that majority of login requests are failed and thus users cant login. only restart of authlib service restores the connectivity and it will start working.

this evening I will try to investigate deeply.

component versions:

 * openldap-ltb-2.4.46-1.el7.x86_64
 * courier-authlib-ldap-0.68.0-1
 * courier-imap-4.18.2.20180216-1.x86_64
 * maildrop-2.9.3-1.x86_64

this issue started when we migrated mailserver from old centos 5 (with courier-authlib-0.66.1-1, courier-imap-4.15-1, maildrop-2.5.2-1) to new system due to system out of support and impossibility to compile/install new/latest courier packages in that centos 5 system.

on old system we havent any such authldap issues.

in version change 0.66 to 0.68 was there any LDAP code rewrite please? or any other idea how to resolve this?

thanks for any help

michal

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Courier-imap mailing list
Courier-imap@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap

Reply via email to