You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Andre Schild <A....@aarboard.ch> on 2004/06/04 17:04:24 UTC
mod_ldap & Win32
Hello,
is anyone using the mod_ldap module on win32 platform ?
We have used it up to build 2.0.48 with (almost) no problems.
But we can't get the mod_ldap from 2.0.49 or from the 2.1 to work.
The problem is, that apache.exe will crash on the first request
who actually does a authentication via LDAP.
There is a bug filed in bugzilled for this, but perhaps someone
else has a workaround.
We have tested it on Windows 2000 & on NT 4.0, but it fails on both.
André
Re: mod_ldap & Win32
Posted by Jess Holle <je...@ptc.com>.
Graham Leggett wrote:
> Jess Holle wrote:
>
>> My feedback was mainly attached to bug #18756
>> <http://issues.apache.org/bugzilla/show_bug.cgi?id=18756>. This bug
>> is still present in 2.0.49. I do not know if it is a true duplicate
>> as indicated or not. I just know it does not work.
>>
>> I also had reported 24801
>> <http://issues.apache.org/bugzilla/show_bug.cgi?id=24801> (crash on
>> cache overflow). I believe I tested it with the fix for bug #29207
>> <http://issues.apache.org/bugzilla/show_bug.cgi?id=29207> some time
>> back but the problem was still there.
>>
>> My test case for latter bug the is pretty simple:
>>
>> 1. Generate an LDIF containing 2500 users (all with known passwords)
>> and import it into your LDAP
>> 2. Have a simple script walk through the 2500 users doing a simple
>> GET against an authenticated resource as one user after another
>> and with the LDAP cache set at 2150 users.
>
>
> The way I tested it was to set the cache size to 1, logged in with one
> user, then logged in with a second in a different browser.
>
> On cue, I got a crash on the second login, which has been fixed and
> committed to v2.0.50-dev.
>
> Can you test against the latest HEAD (or v2.0.50-dev) to see if it is
> still there? There is a big difference between v2.0.49 and v2.0.50-dev.
I know I applied some patches as requested in the correspondence on bug
#24801. I ran the test above, rather than the simpler cache size of 1
-- simply because realistic cache sizes for our usage will be 2000+. It
still failed.
There is some chance I misapplied the patch. The note regarding my
efforts is in the bug comments for 24801 and is dated 2004-05-24. The
testing was prompted by your comment on 2004-05-22 on the same bug.
--
Jess Holle
Re: mod_ldap & Win32
Posted by Graham Leggett <mi...@sharp.fm>.
Jess Holle wrote:
> My feedback was mainly attached to bug #18756
> <http://issues.apache.org/bugzilla/show_bug.cgi?id=18756>. This bug is
> still present in 2.0.49. I do not know if it is a true duplicate as
> indicated or not. I just know it does not work.
>
> I also had reported 24801
> <http://issues.apache.org/bugzilla/show_bug.cgi?id=24801> (crash on
> cache overflow). I believe I tested it with the fix for bug #29207
> <http://issues.apache.org/bugzilla/show_bug.cgi?id=29207> some time back
> but the problem was still there.
>
> My test case for latter bug the is pretty simple:
>
> 1. Generate an LDIF containing 2500 users (all with known passwords)
> and import it into your LDAP
> 2. Have a simple script walk through the 2500 users doing a simple
> GET against an authenticated resource as one user after another
> and with the LDAP cache set at 2150 users.
The way I tested it was to set the cache size to 1, logged in with one
user, then logged in with a second in a different browser.
On cue, I got a crash on the second login, which has been fixed and
committed to v2.0.50-dev.
Can you test against the latest HEAD (or v2.0.50-dev) to see if it is
still there? There is a big difference between v2.0.49 and v2.0.50-dev.
Regards,
Graham
--
Re: Bug 24801
Posted by Jess Holle <je...@ptc.com>.
Graham Leggett wrote:
> Jess Holle wrote:
>
>> I've not tested 2.0.51-dev yet -- as 2.0.50 just came out a short
>> while ago...
>
> There was a big change to the LDAP stuff that was landed after 2.0.50
> shipped, there were questions about whether an MMN bump was needed,
> thus the holdoff till v2.0.51.
>
>> I do not believe this particular issue is due to locking as my test
>> does 2500 requests *in series* from a single client thread, so no
>> concurrency issues should be getting triggered.
>
> Can you confirm whether keepalives are being used in your test? A
> single client with no keepalives will quite possibly use different
> httpd processes/threads for each request, bringing locking issues into
> play. If keepalives are used, there may be limits as to the number of
> requests either the client or httpd is willing to service over that
> keepalive connection, which again means different httpd
> threads/processes come into play again, and we're back into locking
> territory.
I would assume that keepalives were used, but that is only an assumption
-- I didn't snoop anything. [The client is Jakarta Ant's 'get' task
running in Java 2 v1.4.2_04 or 1.4.2_05 on Windows for anyone who can
decipher better from this.]
> Which mpm is your httpd using?
worker
>> Understood. I just wanted to make sure that 24801 didn't get closed
>> out automatically when a lower-level cause of it is closed.
>
> I think this bug will only be closed out when all the people on it
> (including you) have said "works for me".
Cool.
--
Jess Holle
Re: Bug 24801
Posted by Graham Leggett <mi...@sharp.fm>.
Jess Holle wrote:
> I've not tested 2.0.51-dev yet -- as 2.0.50 just came out a short while
> ago...
There was a big change to the LDAP stuff that was landed after 2.0.50
shipped, there were questions about whether an MMN bump was needed, thus
the holdoff till v2.0.51.
> I do not believe this particular issue is due to locking as my test does
> 2500 requests *in series* from a single client thread, so no concurrency
> issues should be getting triggered.
Can you confirm whether keepalives are being used in your test? A single
client with no keepalives will quite possibly use different httpd
processes/threads for each request, bringing locking issues into play.
If keepalives are used, there may be limits as to the number of requests
either the client or httpd is willing to service over that keepalive
connection, which again means different httpd threads/processes come
into play again, and we're back into locking territory.
Which mpm is your httpd using?
> Understood. I just wanted to make sure that 24801 didn't get closed out
> automatically when a lower-level cause of it is closed.
I think this bug will only be closed out when all the people on it
(including you) have said "works for me".
Regards,
Graham
--
Re: Bug 24801
Posted by Jess Holle <je...@ptc.com>.
Graham Leggett wrote:
> Jess Holle wrote:
>
>> Bug 24801 is still present in Apache 2.0.50. [See my additional
>> notes in the report.]
>
> And the stuff that landed in v2.0.51-dev? There is an overhaul of
> locking in there that has potentially fixed a lot of problems.
I've not tested 2.0.51-dev yet -- as 2.0.50 just came out a short while
ago...
I do not believe this particular issue is due to locking as my test does
2500 requests *in series* from a single client thread, so no concurrency
issues should be getting triggered.
> Remember that bug 24801 doesn't describe a discrete bug, but common
> behaviour caused by many bugs. The behaviour is only going to
> disappear when we've nailed the final bug, so the only thing I can
> recommend right now is to keep trying until the last bug is squashed.
Understood. I just wanted to make sure that 24801 didn't get closed out
automatically when a lower-level cause of it is closed.
--
Jess Holle
Re: Bug 24801
Posted by Graham Leggett <mi...@sharp.fm>.
Jess Holle wrote:
> Bug 24801 is still present in Apache 2.0.50. [See my additional notes
> in the report.]
And the stuff that landed in v2.0.51-dev? There is an overhaul of
locking in there that has potentially fixed a lot of problems.
Remember that bug 24801 doesn't describe a discrete bug, but common
behaviour caused by many bugs. The behaviour is only going to disappear
when we've nailed the final bug, so the only thing I can recommend right
now is to keep trying until the last bug is squashed.
Regards,
Graham
--
Re: Bug 24801
Posted by Jess Holle <je...@ptc.com>.
Bug 24801 is still present in Apache 2.0.50. [See my additional notes
in the report.]
I realize this bug is marked as a duplicate of bug 29207. I can't
comment on the point issue noted in bug 29207 -- I just know that the
user-level symptoms in bug 24801 are still quite painfully present in
Apache 2.0.50.
In my opinion this is the biggest issue in Apache's LDAP authentication
since this leads to crashes when the user community exceeds original
expectations/estimates.
--
Jess Holle
Re: mod_ldap & Win32
Posted by Jess Holle <je...@ptc.com>.
My feedback was mainly attached to bug #18756
<http://issues.apache.org/bugzilla/show_bug.cgi?id=18756>. This bug is
still present in 2.0.49. I do not know if it is a true duplicate as
indicated or not. I just know it does not work.
I also had reported 24801
<http://issues.apache.org/bugzilla/show_bug.cgi?id=24801> (crash on
cache overflow). I believe I tested it with the fix for bug #29207
<http://issues.apache.org/bugzilla/show_bug.cgi?id=29207> some time back
but the problem was still there.
My test case for latter bug the is pretty simple:
1. Generate an LDIF containing 2500 users (all with known passwords)
and import it into your LDAP
2. Have a simple script walk through the 2500 users doing a simple
GET against an authenticated resource as one user after another
and with the LDAP cache set at 2150 users.
In my experience it always crashes between 2151 and 2156 users -- at
least on Windows. [I do this test on Windows as I don't have any
additional patches there to work around the first of these 2 bugs on
that platform and it gives me stack traces most readily ironically.]
--
Jess Holle
Graham Leggett wrote:
> Jess Holle wrote:
>
>> On UNIX?
>>
>> See the bug for what details I managed to muster at some point.
>
>
> Can you point out which bug, there were lots that I opened and closed,
> I just want to make sure I didn't close a bug that should be still open.
>
> Regards,
> Graham
> --
>
Re: mod_ldap & Win32
Posted by Graham Leggett <mi...@sharp.fm>.
Jess Holle wrote:
> On UNIX?
>
> See the bug for what details I managed to muster at some point.
Can you point out which bug, there were lots that I opened and closed, I
just want to make sure I didn't close a bug that should be still open.
Regards,
Graham
--
Re: mod_ldap & Win32
Posted by Jess Holle <je...@ptc.com>.
Graham Leggett wrote:
> Jess Holle wrote:
>
>> Hmmm.... We've had no such problems on 2.0.48 or 2.0.49 on Windows.
>>
>> We did have such problems attempting to build against any Microsoft
>> SDK prior to the Spring 2003 update, however....
>>
>> Now we just have this problem on UNIX with mod_worker.
>
>
> Can you post a stacktrace of it when it bombs?
On UNIX?
See the bug for what details I managed to muster at some point.
--
Jess Holle
Re: mod_ldap & Win32
Posted by Graham Leggett <mi...@sharp.fm>.
Jess Holle wrote:
> Hmmm.... We've had no such problems on 2.0.48 or 2.0.49 on Windows.
>
> We did have such problems attempting to build against any Microsoft SDK
> prior to the Spring 2003 update, however....
>
> Now we just have this problem on UNIX with mod_worker.
Can you post a stacktrace of it when it bombs?
Regards,
Graham
--
Re: mod_ldap & Win32
Posted by Jess Holle <je...@ptc.com>.
Hmmm.... We've had no such problems on 2.0.48 or 2.0.49 on Windows.
We did have such problems attempting to build against any Microsoft SDK
prior to the Spring 2003 update, however....
Now we just have this problem on UNIX with mod_worker.
Andre Schild wrote:
>Hello,
>
>is anyone using the mod_ldap module on win32 platform ?
>We have used it up to build 2.0.48 with (almost) no problems.
>
>But we can't get the mod_ldap from 2.0.49 or from the 2.1 to work.
>
>The problem is, that apache.exe will crash on the first request
>who actually does a authentication via LDAP.
>
>There is a bug filed in bugzilled for this, but perhaps someone
>else has a workaround.
>
>We have tested it on Windows 2000 & on NT 4.0, but it fails on both.
>
>André
>
>
>
>