Re: ldapdb auxprop configuration
Hi all! Sorry for cross-posting, but since this appears to be SASL related, I switch to the SASL list and leave this message in the cyrus-imap list for others to follow. So when answering to this, please check that you're not crossposting the answer. Summary for the SASL list subscribers, who have missed the start of this thread: I'm running cyrus-imap to authenticate users using the ldapdb auxprop against a remote ldaps: host. During the DIGEST-MD5 or CRAM-MD5 authentication of the user using imtest imapd SEGFAULTs. The ltrace suggests that it happens somewhere in the SASL layer. The setup is Debian Lenny kept current daily on an Intel Core2-Quad, i.e. amd64 build. @ Torsten Schlabach: One comment suggested that the problem might be one of the Debian specific patches! Did you try to build a package without them? Not yet, but I'm determined to get that issue resolved. One of the larger problems could be that Debian uses GnuTLS instead of OpenSSL. I had some severe issues with that kind of porting some years back with OpenLDAP. @ Dan White: I produced debugging versions of cyrus-imap , cyrus-sasl, and openldap and created a backtrace of the crash. See the end of this message. @ cyrus-imap list For some reason the method using the debug_command in /etc/imapd.conf and the -D option for imapd in /etc/cyrus.conf as described in https://langhorst.com/cgi-bin/dwww//usr/share/doc/cyrus21-common/README.Debian.debug.gz does not work, i.e. it does not produce any logs in /tmp. Am I missing something? So what I did was to use CYRUS_VERBOSE=100 in /etc/default/cyrus2.2 and used the 15 second delay to attach a gdb. The following happened and produced the backtrace of the SEGFAULT: hermod:/# imtest -u cyrus -a cyrus -v -p imap -m DIGEST-MD5 hermod.mgr S: * OK hermod.mgr Cyrus IMAP4 v2.2.13-Debian-2.2.13-14 server ready C: C01 CAPABILITY S: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE IDLE STARTTLS AUTH=NTLM AUTH=DIGEST-MD5 AUTH=CRAM-MD5 SASL-IR S: C01 OK Completed C: A01 AUTHENTICATE DIGEST-MD5 S: + bm9uY2U9IjNFZzIrY2xsci84dmREdXprTkd3a1VmL25XYTRBVnRXQmMxSGpndFBiVEk9IixyZWFsbT0iaGVybW9kLm1nciIscW9wPSJhdXRoLGF1dGgtaW50LGF1dGgtY29uZiIsY2lwaGVyPSJyYzQtNDAscmM0LTU2LHJjNCxkZXMsM2RlcyIsbWF4YnVmPTQwOTYsY2hhcnNldD11dGYtOCxhbGdvcml0aG09bWQ1LXNlc3M= Please enter your password: C: dXNlcm5hbWU9ImN5cnVzIixyZWFsbT0iaGVybW9kLm1nciIsbm9uY2U9IjNFZzIrY2xsci84dmREdXprTkd3a1VmL25XYTRBVnRXQmMxSGpndFBiVEk9Iixjbm9uY2U9IjluczF0dmwwMUhWU095dzlNZXRXK0ltRnVyWHRINDd4TFhyUjEvcXpNZHM9IixuYz0wMDAwMDAwMSxxb3A9YXV0aC1jb25mLGNpcGhlcj1yYzQsbWF4YnVmPTEwMjQsZGlnZXN0LXVyaT0iaW1hcC9oZXJtb2QubWdyIixyZXNwb25zZT1lZmYxZjk2MjUyNzlmY2UyMDY3MmIxOTg1NjIzZmIwYw== failure: prot layer failure Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fa6ca1e3700 (LWP 5409)] 0x7fa6c72ed4aa in pthread_mutex_lock () from /lib/libpthread.so.0 (gdb) bt #0 0x7fa6c72ed4aa in pthread_mutex_lock () from /lib/libpthread.so.0 #1 0x7fa6c32b75a9 in ldap_pvt_thread_mutex_lock (mutex=0x1) at /home/admin/packages/openldap/openldap-2.4.11/libraries/libldap_r/thr_posix.c:296 #2 0x7fa6c32c112b in ldap_pvt_sasl_mutex_lock (mutex=0x1) at cyrus.c:1294 #3 0x7fa6c4b69828 in digestmd5_client_mech_step (conn_context=0x2094440, params=0x20960b0, serverin=0x0, serverinlen=0, prompt_need=0x7fffd21e8760, clientout=0x7fffd21e8748, clientoutlen=0x7fffd21e875c, oparams=0x209a510) at digestmd5.c:3955 #4 0x7fa6c9dc25e6 in sasl_client_step (conn=0x2099ca0, serverin=0x0, serverinlen=0, prompt_need=0x7fffd21e8760, clientout=0x7fffd21e8748, clientoutlen=0x7fffd21e875c) at client.c:658 #5 0x7fa6c9dc2445 in sasl_client_start (conn=0x2099ca0, mechlist=0x2041d40 DIGEST-MD5, prompt_need=0x7fffd21e8760, clientout=0x7fffd21e8748, clientoutlen=0x7fffd21e875c, mech=0x7fffd21e8778) at client.c:606 #6 0x7fa6c32bfc79 in ldap_int_sasl_bind (ld=0x2053880, dn=0x0, mechs=0x2041d40 DIGEST-MD5, sctrls=0x0, cctrls=0x0, flags=2, interact=0x7fa6c34fd704 ldapdb_interact, defaults=0x204dce0) at cyrus.c:689 #7 0x7fa6c32c3b7f in ldap_sasl_interactive_bind_s (ld=0x2053880, dn=0x0, mechs=0x2041d40 DIGEST-MD5, serverControls=0x0, clientControls=0x0, flags=2, interact=0x7fa6c34fd704 ldapdb_interact, defaults=0x204dce0) at sasl.c:464 #8 0x7fa6c34fd96c in ldapdb_connect (ctx=0x204dce0, sparams=0x20516c0, user=0x2052f71 cyrus, ulen=5, cp=0x7fffd21e8910) at ldapdb.c:106 #9 0x7fa6c34fdd45 in ldapdb_auxprop_lookup (glob_context=0x204dce0, sparams=0x20516c0, flags=0, user=0x2052f71 cyrus, ulen=5) at ldapdb.c:178 #10 0x7fa6c9dbe881 in _sasl_auxprop_lookup (sparams=0x20516c0, flags=0, user=0x2052f71 cyrus, ulen=5) at auxprop.c:898 #11 0x7fa6c9dbf309 in _sasl_canon_user (conn=0x20521d0, user=0x2052f71 cyrus, ulen=5, flags=1, oparams=0x2052a40) at canonusr.c:190 #12 0x7fa6c4b6556b in
Re: ldapdb auxprop configuration
Hi Lars! @ Torsten Schlabach: One comment suggested that the problem might be one of the Debian specific patches! Did you try to build a package without them? Not yet, but I'm determined to get that issue resolved. One of the larger problems could be that Debian uses GnuTLS instead of OpenSSL. I had some severe issues with that kind of porting some years back with OpenLDAP. It would be nice if you could give it a try. Actually, I would need 1-2 days to get myself a fresh server to replicate the setup and join the effort. What I do remember is: I had build the respective parts from source tarballs once and it did *not* segfault. But it's too long ago to tell if I had been using GnuTLS or OpenSSL. @ Dan White: I produced debugging versions of cyrus-imap , cyrus-sasl, and openldap If you have all the infrastructure set up to create your own version of the packages, it should be a five minute exercise to empty the debian/patches directory, re-build, re-install and see if the issue goes away. In case it does, we're on the wrong mailist list and should continue the discussion in a Debian developer forum IMO. Regards, Torsten Lars Hanke schrieb: Hi all! Sorry for cross-posting, but since this appears to be SASL related, I switch to the SASL list and leave this message in the cyrus-imap list for others to follow. So when answering to this, please check that you're not crossposting the answer. Summary for the SASL list subscribers, who have missed the start of this thread: I'm running cyrus-imap to authenticate users using the ldapdb auxprop against a remote ldaps: host. During the DIGEST-MD5 or CRAM-MD5 authentication of the user using imtest imapd SEGFAULTs. The ltrace suggests that it happens somewhere in the SASL layer. The setup is Debian Lenny kept current daily on an Intel Core2-Quad, i.e. amd64 build. @ Torsten Schlabach: One comment suggested that the problem might be one of the Debian specific patches! Did you try to build a package without them? Not yet, but I'm determined to get that issue resolved. One of the larger problems could be that Debian uses GnuTLS instead of OpenSSL. I had some severe issues with that kind of porting some years back with OpenLDAP. @ Dan White: I produced debugging versions of cyrus-imap , cyrus-sasl, and openldap and created a backtrace of the crash. See the end of this message. @ cyrus-imap list For some reason the method using the debug_command in /etc/imapd.conf and the -D option for imapd in /etc/cyrus.conf as described in https://langhorst.com/cgi-bin/dwww//usr/share/doc/cyrus21-common/README.Debian.debug.gz does not work, i.e. it does not produce any logs in /tmp. Am I missing something? So what I did was to use CYRUS_VERBOSE=100 in /etc/default/cyrus2.2 and used the 15 second delay to attach a gdb. The following happened and produced the backtrace of the SEGFAULT: hermod:/# imtest -u cyrus -a cyrus -v -p imap -m DIGEST-MD5 hermod.mgr S: * OK hermod.mgr Cyrus IMAP4 v2.2.13-Debian-2.2.13-14 server ready C: C01 CAPABILITY S: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE IDLE STARTTLS AUTH=NTLM AUTH=DIGEST-MD5 AUTH=CRAM-MD5 SASL-IR S: C01 OK Completed C: A01 AUTHENTICATE DIGEST-MD5 S: + bm9uY2U9IjNFZzIrY2xsci84dmREdXprTkd3a1VmL25XYTRBVnRXQmMxSGpndFBiVEk9IixyZWFsbT0iaGVybW9kLm1nciIscW9wPSJhdXRoLGF1dGgtaW50LGF1dGgtY29uZiIsY2lwaGVyPSJyYzQtNDAscmM0LTU2LHJjNCxkZXMsM2RlcyIsbWF4YnVmPTQwOTYsY2hhcnNldD11dGYtOCxhbGdvcml0aG09bWQ1LXNlc3M= Please enter your password: C: dXNlcm5hbWU9ImN5cnVzIixyZWFsbT0iaGVybW9kLm1nciIsbm9uY2U9IjNFZzIrY2xsci84dmREdXprTkd3a1VmL25XYTRBVnRXQmMxSGpndFBiVEk9Iixjbm9uY2U9IjluczF0dmwwMUhWU095dzlNZXRXK0ltRnVyWHRINDd4TFhyUjEvcXpNZHM9IixuYz0wMDAwMDAwMSxxb3A9YXV0aC1jb25mLGNpcGhlcj1yYzQsbWF4YnVmPTEwMjQsZGlnZXN0LXVyaT0iaW1hcC9oZXJtb2QubWdyIixyZXNwb25zZT1lZmYxZjk2MjUyNzlmY2UyMDY3MmIxOTg1NjIzZmIwYw== failure: prot layer failure Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fa6ca1e3700 (LWP 5409)] 0x7fa6c72ed4aa in pthread_mutex_lock () from /lib/libpthread.so.0 (gdb) bt #0 0x7fa6c72ed4aa in pthread_mutex_lock () from /lib/libpthread.so.0 #1 0x7fa6c32b75a9 in ldap_pvt_thread_mutex_lock (mutex=0x1) at /home/admin/packages/openldap/openldap-2.4.11/libraries/libldap_r/thr_posix.c:296 #2 0x7fa6c32c112b in ldap_pvt_sasl_mutex_lock (mutex=0x1) at cyrus.c:1294 #3 0x7fa6c4b69828 in digestmd5_client_mech_step (conn_context=0x2094440, params=0x20960b0, serverin=0x0, serverinlen=0, prompt_need=0x7fffd21e8760, clientout=0x7fffd21e8748, clientoutlen=0x7fffd21e875c, oparams=0x209a510) at digestmd5.c:3955 #4 0x7fa6c9dc25e6 in sasl_client_step (conn=0x2099ca0, serverin=0x0, serverinlen=0, prompt_need=0x7fffd21e8760,
Re: ldapdb auxprop configuration
Hi there, For some reason the method using the debug_command in /etc/imapd.conf and the -D option for imapd in /etc/cyrus.conf as described in https://langhorst.com/cgi-bin/dwww//usr/share/doc/cyrus21-common/README.Debian.debug.gz does not work, i.e. it does not produce any logs in /tmp. Am I missing something? Sorry, after dumping /etc/cyrus.conf another time I found that -D was in the wrong place on the command line. Now it works. Regards, - lars. Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: ldapdb auxprop configuration
_S_eems we're coming closer ...
'signaled to death by 11' is a big red flag... your imapd process is
seg faulting. It's possibly caused by an old SASL/OpenLDAP reentrant
bug (are you running an old version of libldap?).
Looking at SASL Bug 3032
http://bugzilla.andrew.cmu.edu/show_bug.cgi?id=3032 and Debian Bug
#409495 it looks quite like that. Both bugs are not resolved according
to the bugtrackers. The install is Lenny current as per today. These are
the relevant packages:
hermod:/# dpkg -l '*cyrus*' | grep '^ii'
ii cyrus-admin-2.2 2.2.13-14 Cyrus mail
system (administration tools)
ii cyrus-clients-2.2 2.2.13-14+b3 Cyrus mail
system (test clients)
ii cyrus-common-2.22.2.13-14+b3 Cyrus mail
system (common files)
ii cyrus-imapd-2.2 2.2.13-14+b3 Cyrus mail
system (IMAP support)
ii libcyrus-imap-perl222.2.13-14+b3 Interface
to Cyrus imap client imclient libr
hermod:/# dpkg -l '*ldap*' | grep '^ii'
ii ldap-utils 2.4.11-1 OpenLDAP
utilities
ii libldap-2.4-2 2.4.11-1 OpenLDAP
libraries
hermod:/# dpkg -l '*sasl*' | grep '^ii'
ii libsasl2-2 2.1.22.dfsg1-23 Cyrus SASL
- authentication abstraction libr
ii libsasl2-modules2.1.22.dfsg1-23 Cyrus SASL
- pluggable authentication module
ii libsasl2-modules-gssapi-mit 2.1.22.dfsg1-23 Cyrus SASL
- pluggable authentication module
ii libsasl2-modules-ldap 2.1.22.dfsg1-23 Cyrus SASL
- pluggable authentication module
ii sasl2-bin 2.1.22.dfsg1-23 Cyrus SASL
- administration programs for SASL
The Debian Bugtracker has it that avoiding DIGEST-MD5 would work around
the bug. So I removed that MECH and eventually replaced it with
CRAM-MD5, but the SEGFAULT persists.
You can specify a debug_command in your imapd.conf to generate a back
trace. See:
https://langhorst.com/cgi-bin/dwww//usr/share/doc/cyrus21-common/README.Debian.debug.gz
Okay, if the error is known and open, it's worth the while to create a
debugging version of probably all the packages. Does anyone know more
about the current state of the bug? I could supply an OpenVZ Container,
which readily produces it. ;)
The strace ends in:
15:42:19.940818 poll([{fd=16, events=POLLIN}], 1, 5000) = 1 ([{fd=16,
revents=POLLIN}])
15:42:19.940883 ioctl(16, FIONREAD, [83]) = 0
15:42:19.940917 recvfrom(16,
\263\225\205\200\0\1\0\1\0\1\0\0\0013\0016\00216\003172\7in-addr\4a...,
1024, 0, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(172.16.6.3)}, [16]) = 83
15:42:19.940973 close(16) = 0
15:42:19.941020 uname({sys=Linux, node=hermod.mgr, ...}) = 0
15:42:19.941095 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
So the last thing done successfully is a DNS query for the LDAP server.
The ltrace is a little more informative. However, it looks like the
SEGFAULT is somewhere in SASL, probably the thread should continue there ...
3922 15:46:41.771218 read(0, dXNlcm5hbWU9ImN5cnVzIixyZWFsbT0i...,
4096) = 354
3922 15:46:41.771278 strlen() = 0
3922 15:46:41.771321 strncasecmp(0x7fffc67534d0, 0x46193b, 0, 5, 22) = 0
3922 15:46:41.771380 strlen() = 0
3922 15:46:41.771423 strlen(dXNlcm5hbWU9ImN5cnVzIixyZWFsbT0i...) = 352
3922 15:46:41.771470 sasl_decode64(0x7fffc67534d0, 352, 0x7fffc67534d0,
21848, 0x7fffc6758a3c) = 0
3922 15:46:41.771520 sasl_server_step(0x1f48140, 0x7fffc67534d0, 262,
0x7fffc6758a30, 0x7fffc6758a38 unf
inished ...
3922 15:46:41.771554 malloc(250) = 0x1f4a260
3922 15:46:41.771631 malloc(263) = 0x1f4a260
3922 15:46:41.771680 malloc(6)= 0x1f4a370
3922 15:46:41.771722 malloc(11) = 0x1f4a390
3922 15:46:41.771763 malloc(45) = 0x1f4a3b0
3922 15:46:41.771805 malloc(45) = 0x1f4a3f0
3922 15:46:41.771847 malloc(10) = 0x1f4a430
3922 15:46:41.771891 malloc(4)= 0x1f4a450
3922 15:46:41.771933 malloc(16) = 0x1f4a470
3922 15:46:41.771975 malloc(33) = 0x1f49b20
3922 15:46:41.772018 malloc(1219) = 0x1f4a490
3922 15:46:41.772061 memcpy(0x1f48ee1, cyrus, 5)= 0x1f48ee1
3922 15:46:41.772105 strlen(cyrus) = 5
3922 15:46:41.772148 strlen(cyrus) = 5
3922 15:46:41.772193 strcmp(unix, unix) = 0
3922 15:46:41.772241 strlen(cyrus) = 5
3922 15:46:41.772283 memmove(0x6fc420, 0x1f48ee1, 5, 2, 1)= 0x6fc420
3922 15:46:41.772333
ldapdb auxprop configuration
I'm trying set up cyrus-imap using the ldapdb auxprop. I guess I've the LDAP part up and running, but somehow imap does not really request for authentication. So probably I still have something messed in the configuration, which apparently has changed with respect to my last install a couple of years ago. Any ideas for systematic troubleshooting are welcome. Regards, - lars. This is the sasl related part of the imap configuration: hermod:~# grep sasl /etc/imapd.conf | grep -v '^#' | grep -v '^\s*$' sasl_mech_list: PLAIN DIGEST-MD5 CRAM-MD5 sasl_pwcheck_method: auxprop sasl_auxprop_plugin: ldapdb sasl_ldapdb_uri: ldaps://hel.mgr sasl_ldapdb_id: mailadmin sasl_ldapdb_pw: * sasl_ldapdb_mech: DIGEST-MD5 sasl_auto_transition: no The following is running as expected: hermod:~# ldapwhoami -U mailadmin -X u:cyrus -W -Y DIGEST-MD5 -H ldaps://hel.mgr Enter LDAP Password: SASL/DIGEST-MD5 authentication started SASL username: u:cyrus SASL SSF: 128 SASL data security layer installed. dn:uid=cyrus,ou=mailbox,dc=mgr and of course: ldapsearch -U mailadmin -X u:cyrus -W -Y DIGEST-MD5 -b ou=mailbox,dc=mgr (uid=cyrus) returns the password of cyrus, which is kept as plaintext inside the LDAP repositiory. ldapsearch returns the base64 encoded plain password. However using this same password the following happens: hermod:~# imtest -v -u cyrus -a cyrus -p imap -m DIGEST-MD5 hermod.mgr S: * OK hermod.mgr Cyrus IMAP4 v2.2.13-Debian-2.2.13-14+b3 server ready C: C01 CAPABILITY S: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE IDLE STARTTLS AUTH=DIGEST-MD5 AUTH=CRAM-MD5 SASL-IR S: C01 OK Completed C: A01 AUTHENTICATE DIGEST-MD5 S: + bm9uY2U9IlBMREhNY0JjbG1XOUt2dk5FQWQrb0R5cmZ3YjY3cHcyb1VIWHhacDE0dXc9IixyZWFsbT0iaGVybW9kLm1nciIscW9wPSJhdXRoLGF1dGgtaW50LGF1dGgtY29uZiIsY2lwaGVyPSJyYzQtNDAscmM0LTU2LHJjNCxkZXMsM2RlcyIsbWF4YnVmPTQwOTYsY2hhcnNldD11dGYtOCxhbGdvcml0aG09bWQ1LXNlc3M= Please enter your password: C: dXNlcm5hbWU9ImN5cnVzIixyZWFsbT0iaGVybW9kLm1nciIsbm9uY2U9IlBMREhNY0JjbG1XOUt2dk5FQWQrb0R5cmZ3YjY3cHcyb1VIWHhacDE0dXc9Iixjbm9uY2U9IkVZR2hkY1UvZy9vU0J5VkNsMkhSVWt3NWVuMTlOR3puWU9PQjZuSUpPams9IixuYz0wMDAwMDAwMSxxb3A9YXV0aC1jb25mLGNpcGhlcj1yYzQsbWF4YnVmPTEwMjQsZGlnZXN0LXVyaT0iaW1hcC9oZXJtb2QubWdyIixyZXNwb25zZT00Yjk3OWJhMTU0NWUzZDBkMTJiYWNlNjY4NTk4YjhjZA== failure: prot layer failure The detailed log of slapd has the following for this request: slap_listener_activate(10): slap_listener(ldaps:///) conn=15 fd=24 ACCEPT from IP=172.16.6.5:53956 (IP=0.0.0.0:636) connection_get(24): got connid=15 connection_read(24): checking for input on id=15 connection_get(24): got connid=15 connection_read(24): checking for input on id=15 connection_get(24): got connid=15 connection_read(24): checking for input on id=15 connection_get(24): got connid=15 connection_read(24): checking for input on id=15 connection_read(24): unable to get TLS client DN, error=49 id=15 conn=15 fd=24 TLS established tls_ssf=128 ssf=128 connection_get(24): got connid=15 connection_read(24): checking for input on id=15 ber_get_next ber_get_next on fd 24 failed errno=0 (Success) connection_closing: readying conn=15 sd=24 for close connection_close: conn=15 sd=24 conn=15 fd=24 closed (connection lost) So apparently imapd-ldapdb connects and establishes SSL. For the rest I'm unsure, but it seems like it does not talk to LDAP anymore and terminates, i.e. there is no authentication happening. The result is the same for trying telnet localhost imap2 and a login for cyrus. Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: ldapdb auxprop configuration
Thanks Dan, To make sure that the ldapdb plugin is installed correctly: # cat /usr/lib/sasl2/pluginview.conf # pluginviewer | grep ldapdb hermod:/# grep sasl /etc/imapd.conf | grep -v '^#' | grep -v '^\s*$' | sed 's/^sasl_//' /usr/lib/sasl2/pluginviewer.conf hermod:/# saslpluginviewer -a Installed auxprop mechanisms are: ldapdb sasldb List of auxprop plugins follows Plugin ldapdb , API version: 4 supports store: yes Plugin sasldb , API version: 4 supports store: yes Didn't know this tool so far. Should it say something different? Does your /var/log/auth.log or /var/log/syslog give you anything useful? At least it's not too useful to me ... (after setting sasl_log_level: 7) /var/log/auth.log: Jan 2 22:31:15 hermod cyrus/imap[3432]: DIGEST-MD5 server step 1 Jan 2 22:31:15 hermod imtest: DIGEST-MD5 client step 2 Jan 2 22:31:17 hermod imtest: DIGEST-MD5 client step 2 Jan 2 22:31:17 hermod cyrus/imap[3432]: DIGEST-MD5 server step 2 /var/log/syslog: Jan 2 22:31:15 hermod cyrus/master[3432]: about to exec /usr/lib/cyrus/bin/imapd Jan 2 22:31:15 hermod cyrus/imap[3432]: executed Jan 2 22:31:15 hermod cyrus/imap[3432]: accepted connection Jan 2 22:31:17 hermod cyrus/master[3425]: process 3432 exited, signaled to death by 11 Jan 2 22:31:17 hermod cyrus/master[3425]: service imap pid 3432 in BUSY state: terminated abnormally You may want to experiment with the ldapdb_starttls and ldapdb_rc options (see sasl's options.html doc). See 'man ldap.conf' for options that you can place in ldaprc. If you do choose to use starttls, you'll need to replace ldaps://hel.mgr with ldap://hel.mgr. I tried sasl_ldapdb_uri: ldap://hel.mgr sasl_ldapdb_starttls: try and it comes out the same; slapd logs a successful STARTTLS. I tried: sasl_ldapdb_rc: /etc/ldap/ldap.conf which yields sending short packages in both cases. This slapd debug output is from a STARTTLS variant: TLS: can't accept: A TLS packet with unexpected length was received.. connection_read(16): TLS accept failure error=-1 id=8, closing connection_closing: readying conn=8 sd=16 for close connection_close: conn=8 sd=16 conn=8 fd=16 closed (TLS negotiation failure) But still imtest fails with failure: prot layer failure. There is no activity in slapd before the password is entered in imtest. Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: ldapdb auxprop configuration
Lars Hanke wrote: hermod:/# saslpluginviewer -a Installed auxprop mechanisms are: ldapdb sasldb List of auxprop plugins follows Plugin ldapdb , API version: 4 supports store: yes Plugin sasldb , API version: 4 supports store: yes Didn't know this tool so far. Should it say something different? No, that confirms that ldapdb is installed. Does your /var/log/auth.log or /var/log/syslog give you anything useful? /var/log/syslog: Jan 2 22:31:15 hermod cyrus/master[3432]: about to exec /usr/lib/cyrus/bin/imapd Jan 2 22:31:15 hermod cyrus/imap[3432]: executed Jan 2 22:31:15 hermod cyrus/imap[3432]: accepted connection Jan 2 22:31:17 hermod cyrus/master[3425]: process 3432 exited, signaled to death by 11 Jan 2 22:31:17 hermod cyrus/master[3425]: service imap pid 3432 in BUSY state: terminated abnormally 'signaled to death by 11' is a big red flag... your imapd process is seg faulting. It's possibly caused by an old SASL/OpenLDAP reentrant bug (are you running an old version of libldap?). You can specify a debug_command in your imapd.conf to generate a back trace. See: https://langhorst.com/cgi-bin/dwww//usr/share/doc/cyrus21-common/README.Debian.debug.gz - Dan Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
