Summary: | courier-imap (authldap) can't bind to openldap unless allow bind_v2 is set in slapd.conf | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jaco Kroon <jaco> |
Component: | [OLD] Server | Assignee: | Net-Mail Packages <net-mail+disabled> |
Status: | RESOLVED UPSTREAM | ||
Severity: | major | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
authldap code fix
Updated, and *much* improved patch for courier-imap. |
Description
Jaco Kroon
2004-06-24 16:33:33 UTC
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". |