The crash on Solaris is with a binary built from 2.0.48 sources + all committed mod_ldap changes from HEAD, i.e. I intentionally took the latest sources whether they were from the 2.0 or 2.1 branch. [Well, okay, I didn't take the latest APR/APU deprecation changes to give a better chance of compilation.]There is a patch that was committed to CVS HEAD that is waiting for enough votes to be backported to the 2.0 branch. The patch addresses PR #18756 that deals with shared memory issues and could very possibly fix the problems that you are seeing.
These same sources worked just fine on Windows, i.e. I built a 2.0.48+ binary and have been using it without issue, so my selection of newer sources does not seem to be abhorrantly amiss.
The patch has been sitting in theSounds good to me, but this does not appear to fix the Solaris issue I'm seeing. There are other comments attached to the bug report you site indicating that the patch did not fix their Solaris 8 crashes either.
backport queue for sometime now. I would like to go ahead and backport
this patch now if nobody has any objections and since auth_ldap is an
experimental module anyway.
As far as your other question goes, NetWare uses auth_ldapI really hoped that this would be the case. Unfortunately, it does not appear to be true.
extensively in our solutions and we have done a lot of testing using the
caching directives. The difference is that NetWare does not use shared
memory for the cache. Since the caching directives only appears to be a
problem on shared memory platforms, this leads me to believe that the
proposed patch should resolve this issue.
As I said, I know there are a few folk out there working this problem hard (and you're one of them, Brad). Unfortunately, there does not seem to be good coverage on common platforms like worker-MPM + shared memory (which is not to fault Brad, this is not his platform).
Since you mention it, though, Brad, is non-anonymous bind heavily used in NetWare? As noted in my previous message, there are open reports of connections staying bound to the user being authenticated and then not properly rebound to the "search/read-only-admin" dn to perform the next search. [Unfortunately, I've not personally reproduced this issue, but I've seen reports of it from auth_ldap 1.6.0 to all but the latest Apache 2 code -- perhaps you specifically fixed this in your 2.0.48 changes?]
* connections staying bound as wrong user preventing reliable
non-anonymous access to LDAP
-- Jess Holle
