The current stable version of openldap only likes protocol version 3 unless allow bind_v2 is set in slapd.conf I do not want to set this option (yea, I'm probably just being difficult). This means that courier-imap won't be able to connect to openldap as courier-imap uses protocol version 2 by default (in fact, anything that links to the ldap library does this). The solution is to explicitly change the protocol version to version 3. There is unfortunately no config options to do this, therefor I have dished up the following patch, which solves this problem. There is also a problem with the LDAP_TLS option. This should remain 0 at all times (not sure why). Reproducible: Always Steps to Reproduce: 1. emerge openldap courier-imap 2. configure slapd.conf, don't use allow bind_v2 3. configure courier-imap to make use of authldap 4. Try logging in, it will fail with a protocol error This can be confirmed by setting the "debuglevel" in slapd.conf to 4095 (too lazy to get the exact bitmask right now...
Created attachment 34094 [details, diff] authldap code fix The patch should be applied to the source tree using epatch, such as: epatch ${FILESDIR}/${PN}-3.0.2-ldap_protocol_version.patch This works for me.
Created attachment 34121 [details, diff] Updated, and *much* improved patch for courier-imap. This patch does something similar to the other one, except that it instead makes use of a config option in authldaprc (LDAP_PROTOVER) to determine the protocol version to switch to, and does some relatively extensive error checking on the value there. How can I submit this upstream as well?
the upstream mailing list is here: http://lists.sourceforge.net/lists/listinfo/courier-imap if you'd to take the initiative to send it upstream and get it improved/accepted there, by all means do, and then I'll either put the same patch they accept into a temporary release here, or just use their new release with it (depending how long they will be with the next release).
Right, submitted, could we please apply this patch against 3.0.2 and get it over with? I have patched my own version with this already and it is working as expected. The fact that I still can't get TLS working is not that serious and probably the subject area of another bug report. If and when an alternative solution gets accepted we can simply drop this patch against our own version and all will be well.
Have patience young grasshopper. upstream has an extremely fast response time on the courier-imap list (under 12 hours usually), and I do read the mailing list (digest form only) and I would like to see upstream's response before accepting your patch entirely, mainly because I don't use courier-imap with ldap myself, and as such I don't have the facilities to test it properly. So 'just now' ;-) when tomorrow rolls around I'll check for a response from upstream on it.
K, rush is not *that* big but I would really like to not run "in-house" patched machines as far as possible. But I do also understand that QA is a bigger issue than a single users needs :). Well, nothing back from them yet ... btw, courier imap really has a very nice structure and organization around it. Not quite as broken down as qmail (which I love). But I do see that it breaks down into seperate programs for handling tcp, authentication and so forth. The configs are broken down to a config per daemon - which is really cool. Brilliant piece of software so far. The code (that which I have seen) is also well structured and very readable.
Oh, wrote that just too soon. Seems there is already an upstream patch. Well, 3.0.4 (already "unstable" in portage) apparantly has a LDAP_PROTOCOL_VERSION option, would it be possible to find the patch from upstream or maybe just adjust the patch above to be LDAP_PROTOCOL_VERSION instead?
Yes, this is resolved in courier-imap-3.0.5 which is in portage. It runs beautifully here, I can recommend that it moves to "stable".
