ok, I have just tried to compile authlib 0.66.4, but without success.
errors related to wrong courier-unicode version (1 vs 2):
rfc2047.c:379:1: error: unknown type name 'unicode_char'
static int encode_word(const unicode_char *uc,
also courier-imap is related with courier-unicode, which means that I
have to downgrade everything in order to get older authlib 0.66
installed which I will not do it due to usual reasons (old versions, no
support etc).
so I will try to investigate this issue deeply
regards
michal
Dňa 23.5.2018 o 15:02 Michal Bruncko napísal(a):
seems that there was some code rewrite for LDAP module in version 0.67.0.
2016-01-04 Sam Varshavchik
* authldaplib.cpp: Rewrite authldap in modern C++. Autodetect
and automatically reload authldaprc when it is changed. No server
restart is required.
I am wondering whether I can downgrade authlib to version 0.66 without
affecting any other courier component...
regards
michal
Dňa 23.5.2018 o 14:58 Michal Bruncko napísal(a):
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
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap
------------------------------------------------------------------------------
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
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap
