Antw: [VOTE] Apache HTTP Server 2.0.51
Builds and runs OK on WIN32 as well. André >>> [EMAIL PROTECTED] 15.09.2004 15:46:45 >>> Hi, I've put the tarballs for 2.0.51 up at http://httpd.apache.org/dev/dist/. Please test and vote, Sander
Antw: httpd 2.0.51 release schedule?
Hello, as there is a security problem in webdav of 2.0.50, I think a 2.0.51 release will happen soon. http://www.heise.de/security/news/meldung/51086 http://www.securitytracker.com/alerts/2004/Sep/1011248.html André >>> [EMAIL PROTECTED] 15.09.2004 10:10:15 >>> Hi all, I am just about finishing a Flash MX 2004 book for O'Reilly Germany. As one of its topics is Flash and Server-Side Programming, the book's CD-ROM is going to contain Apache. The master CD has to be ready on Friday, so my question: Will the final release of httpd 2.0.51 happen until then, or should I consider including 2.0.50 instead? Regards, Sascha Btw: 2.0.51-rc2 builds and installs fine on SuSE Linux 9.0 (x86).
RE: 2.0.50 tarballs available for testing
> [EMAIL PROTECTED] 29.06.2004 02:27:06 >Hi, > >The 2.0.50 tarballs are up and available for testing at: > > http://httpd.apache.org/dev/dist/ > >Please test and cast your votes for release. > Compiles and runs fine under Windows 2000 +1 if I'm allowed to André
Antw: query regarding Apache bandwidth requirements
Don't you think, that the client is filling up it's buffer, and the after it's full just stream what it has played ? André aarboard ag internet - networks - screen&print design - multimedia Egliweg 10 - Postfach 214 - CH-2560 Nidau (Switzerland) Phone +41 32 332 9714 - Fax +41 32 332 9715 www.aarboard.ch - [EMAIL PROTECTED] >>> [EMAIL PROTECTED] 25.06.2004 13:43:04 >>> Hi, I have an Apache2 server that streams video to a VLC client. I have used NeTraMet to capture the traffic and used this data to draw the traffic profile. There is no other traffic on the test-bed (except for RIP). This profile shows a peak of about 3MB at the very beginning. After that, the streamed data is fairly constant at 200KB. Periodically (every 30 seconds), the TCP connection window size gets smaller, resulting in troughs in the profile. I am finding this behaviour particularly difficult to understand. I was thinking that the RIP updates might cause the window to decrease, but I'm not sure. It seems fairly severe that RIP would cause this behaviour. So I am trying to explain this phenomena - does the Apache server require this extraordinary amount in order to initially set up a connection? And is there some process where it will reduce the window size at regular intervals, maybe by buffering the data (which could result in the window being reduced)? Thanks for any help, Jesse __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Antw: Re: Apache HTTP Server 2.0.50-rc2 tarballs available for testing
I didi take it, and now it compiles fine under win 2000. The server runs well under win2000 and nt 4.0 server. As there are no other problem reportts, it's time to tag RC3 ? André aarboard ag internet - networks - screen&print design - multimedia Egliweg 10 - Postfach 214 - CH-2560 Nidau (Switzerland) Phone +41 32 332 9714 - Fax +41 32 332 9715 www.aarboard.ch - [EMAIL PROTECTED] >>> [EMAIL PROTECTED] 23.06.2004 21:13:10 >>> I just commited a fix for this. Bill Andre Schild wrote: > Hello, > > I have taken the sources as tagged in CSV and tried it to build under > Windows 2000. > > It fails when compiling xlate.c to generate libaprutil > > xlate.c > c:\Develop\Apache\httpd-2.0.50-rc1\srclib\apr-util\xlate\xlate.c(181) : > error C2 > 198: 'apr_iconv_close' : Nicht genuegend Parameter uebergeben > c:\Develop\Apache\httpd-2.0.50-rc1\srclib\apr-util\xlate\xlate.c(182) : > error C2 > 198: 'apr_iconv_open' : Nicht genuegend Parameter uebergeben > c:\Develop\Apache\httpd-2.0.50-rc1\srclib\apr-util\xlate\xlate.c(182) : > warning > C4047: '=' : Anzahl der Dereferenzierungen bei 'void *' und 'int ' > unterschiedli > ch > > > > The problem are the changes between 1.17.2.1 and 1.17.2.2 > > At two places the apr_iconv_close is called only with one argument, > but in the header file, it takes a second parameter. (The pool) > > apr_iconv_close(convset->ich); > > > > > André > > >>>>[EMAIL PROTECTED] 22.06.2004 22:09:39 >>> > > Hi, > > My second attempt at preparing a 2.0.50 rc tarball... > > I've tagged the tree (STRIKER_2_0_50_RC2) and uploaded associated > tarballs to: > > http://httpd.apache.org/dev/dist/ > > Please test and report. > > > Thanks! > > Sander >
Antw: RE: Apache HTTP Server 2.0.50-rc2 tarballs available for testing
Hello Eddie, >>198: 'apr_iconv_open' : Nicht genuegend Parameter uebergeben >> c:\Develop\Apache\httpd-2.0.50-rc1\srclib\apr-util\xlate\xlate.c(182) : >> warning >> C4047: '=' : Anzahl der Dereferenzierungen bei 'void *' und 'int ' >> unterschiedli >> ch >> >Are you sure you have the rc2 tag? it looks like you have the rc1 >directory name there?.. rc1 is NOT httpd 2.0 it was accidentally a 2.1 >head tarball. No, even as on my harddisk it's named RC1, I have checked out rc2. André aarboard ag internet - networks - screen&print design - multimedia Egliweg 10 - Postfach 214 - CH-2560 Nidau (Switzerland) Phone +41 32 332 9714 - Fax +41 32 332 9715 www.aarboard.ch - [EMAIL PROTECTED]
i18n of mod_autoindex
Hello, we just noticed, that the mod_autoindex always returns the strings in english, and the dates are also in a non-i18n format. Have there been any ideas on how to solve this ? André
RE: Apache HTTP Server 2.0.50-rc2 tarballs available for testing
Hello, I have taken the sources as tagged in CSV and tried it to build under Windows 2000. It fails when compiling xlate.c to generate libaprutil xlate.c c:\Develop\Apache\httpd-2.0.50-rc1\srclib\apr-util\xlate\xlate.c(181) : error C2 198: 'apr_iconv_close' : Nicht genuegend Parameter uebergeben c:\Develop\Apache\httpd-2.0.50-rc1\srclib\apr-util\xlate\xlate.c(182) : error C2 198: 'apr_iconv_open' : Nicht genuegend Parameter uebergeben c:\Develop\Apache\httpd-2.0.50-rc1\srclib\apr-util\xlate\xlate.c(182) : warning C4047: '=' : Anzahl der Dereferenzierungen bei 'void *' und 'int ' unterschiedli ch The problem are the changes between 1.17.2.1 and 1.17.2.2 At two places the apr_iconv_close is called only with one argument, but in the header file, it takes a second parameter. (The pool) apr_iconv_close(convset->ich); André >>> [EMAIL PROTECTED] 22.06.2004 22:09:39 >>> Hi, My second attempt at preparing a 2.0.50 rc tarball... I've tagged the tree (STRIKER_2_0_50_RC2) and uploaded associated tarballs to: http://httpd.apache.org/dev/dist/ Please test and report. Thanks! Sander
Re: Antw: Re: mod_ldap & Win32
Hello Guenter, I had just some tests with Jess, and now I am able to build a working mod_ldap for 2.0.49 It is in fact a problem, depending which MS SDK you use. With the old SDK I used previously (Whistler Beta1 March 2001) the mod_ldap stuff crashes. I have then rebuilt it with the MS SDK Spring 2003 Februar 2003 and now the LDAP authentication works fine. I have the Netscape C5 SDK available on my maschine too, but so far I have not found/seen a way to build apache 2 with the Netscape LDAP sdk. André aarboard ag internet - networks - screen&print design - multimedia Egliweg 10 - Postfach 214 - CH-2560 Nidau (Switzerland) Phone +41 32 332 9714 - Fax +41 32 332 9715 www.aarboard.ch - [EMAIL PROTECTED] >>> [EMAIL PROTECTED] 04.06.2004 18:31:49 >>> Hi Andre, > Any chance you could send me your mod_ldap.so & util_ldap.so for windows ? > So I can compare/test them with my modules ? have you tried a build with Netscape SDK? You can get binaries from my site: http://www.gknw.com/development/apache/ however I have not tested ldap on Win32 for longer... Guenter.
Antw: Re: mod_ldap & Win32
Hello, I too have downloaded the most current SDK available, but it still crashes. On what Windows are you running the apache server ? Any chance you could send me your mod_ldap.so & util_ldap.so for windows ? So I can compare/test them with my modules ? André >>> [EMAIL PROTECTED] 04.06.2004 17:08:21 >>> 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é > > > >
Antw: Re: mod_ldap & Win32
For Windows 2000 it's included in the bug report. Not sure if it whas for 2.1 or 2.0.50, it crashed in both, and always in the WLDAP32 DLL http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18334 André >>> [EMAIL PROTECTED] 04.06.2004 17:17:31 >>> 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 --
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é
Antw: Re[2]: where forum???
There are the mailing list archives for the history... And it's a personal preference if you like/dislike webforums. André >>> [EMAIL PROTECTED] 01.06.2004 16:56:32 >>> > The Apache httpd server project does not use web forums. very very bad !!! I didn't search previous topic :( And people not response by some question. only mail - this not good!!! :(
Antw: Re: Best place to log error 500 errors
Hello, >use piped log and tell your users to put the status in a certain location >write a custom module that implements the log-transaction hook, and do whatever >you want for status==500 Yep, is just what I did. (Using mod_examples as a starting point. >> I think of something like a (transparent) filter in the output chain. >having your custom module implement the log-transaction hook would be more >straightforward The module will show up in some days on the modules directory. Opensource, probably Apache license. Thanks. André
Antw: RE: consider reopening 1.3
>People will move Apache 1.x to this platform because there is virtually NO >migration cost (i.e. recoding modules etc) and they get a performance boost >and while replacing an aging infrastructure. >12 million user on the move - make it easy for them, buy a cheap AMD Opteron >and optimize and improve Apache 1.4 on that box. Today perhaps, but tomorrow with IPv6 ? André aarboard ag internet - networks - screen&print design - multimedia Egliweg 10 - Postfach 214 - CH-2560 Nidau (Switzerland) Phone +41 32 332 9714 - Fax +41 32 332 9715 www.aarboard.ch - [EMAIL PROTECTED]
Antw: RE: Re: mod_deflate and transfer / content encoding problem
>> I think we should put a warning on the second "recomended configuration" >> that compressing everything can cause problems. (Specially with PDF files) > >Could you file a bug against the documentation for this so it doesn't get >forgotten? Done. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24614 Thanks to all. André
RE: Re: mod_deflate and transfer / content encoding problem
>>> [EMAIL PROTECTED] 31.10.2003 23:44:06 >>> > >On Fri, 31 Oct 2003, Andre Schild wrote: >> Please have a look at the following Mozilla bug report >> >> http://bugzilla.mozilla.org/show_bug.cgi?id=224296 >> >> It seems that mod_deflate does transfer encoding, >> but sets the headers as if doing content encoding. >I'm not an expert in this, but that statement seems completely wrong to >me. Compressing the content is a content-encoding, not a >transfer-encoding. The only thing transfer-encoding is used for in HTTP >is chunking. I anyone here reading this who can answer this for sure ? >I see nothing wrong other than the fact that the browser is passing >compressed content to a plugin that can't handle it. Could well be a problem in the plugin interface code, since IE shows the same problem. >> >> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22902 >> >> Any ideas on this subject ? > >It seems to me that we should only recommend the "AddOutputFilterByType" >configuration, since compressing everything has too many potential >problems. I think we should put a warning on the second "recomended configuration" that compressing everything can cause problems. (Specially with PDF files) André
Best place to log error 500 errors
Hello, what would be the "best" way to log all error 500 (all status 50x responses in fact) into a separate logfile ? One way could be a piped log, but depending of the format the user has configured the output can be very different. I think of something like a (transparent) filter in the output chain. Thanks. André
mod_deflate and transfer / content encoding problem
Hello, today I noticed a problem with our webserver (Upgraded yesterday from 2.0.47 to .48), concering PDF files. We have mod_deflate active on the server and use the default config for this as described on the the module config page, where we compress everything, except images. http://httpd.apache.org/docs-2.0/mod/mod_deflate.html Please have a look at the following Mozilla bug report http://bugzilla.mozilla.org/show_bug.cgi?id=224296 It seems that mod_deflate does transfer encoding, but sets the headers as if doing content encoding. Due to this, the browser delivers the gzip'ed file to the acrobat plugin, and this one isn't knowing how to handle the content. The very same occurs with internet explorer. Part of the problem is, that Mozilla doesn't handle transfer encoding. So the only available option is to turn off compression for such content who isn't handled by the browser. Finaly (preliminary) conclusion: - What does "Accept-Encoding: gzip,deflate" in a request means ? Accepting transfer encoding, or accept content encoding ? - In the documentation the recommended config to compress everything, except pictures isn't appropriate, since it will content encode all content. Potentially this will cause a lot of troubles, for all file types not handled by the browser himself. (Quicktime, WAV etc. etc. ) There is a RFE in the apache bugzilla, dealing with the same problem. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22902 Any ideas on this subject ? André aarboard ag internet - networks - screen&print design - multimedia Egliweg 10 - Postfach 214 - CH-2560 Nidau (Switzerland) Phone +41 32 332 9714 - Fax +41 32 332 9715 www.aarboard.ch - [EMAIL PROTECTED]
Antw: [Win32] 1.3.29 & 2.0.48 src/binaries ready for testing
The patchs seems to not solve the problem with the missing ssl-std.conf.in
Otherwise I can build the release and on first tests it works fine.
André
>>> [EMAIL PROTECTED] 29.10.2003 21:26:00 >>>
Günter was right on target, of course, and I had to make the exact patch
he suggested simply to roll the release packages. As such, I've included
that change in the httpd-2.0.48-win32-src.zip image as well.
All Win32 related installation packages, diagnostic symbols and the
source tarball (with apr-iconv included) are available from
http://httpd.apache.org/dev/dist/
and should be moved asap as soon as another, less tired pair of eyeballs
than mine has taken a quick look at them.
Bill
At 08:04 PM 10/28/2003, Günter Knauf wrote:
>Hi,
>> The tarballs for 2.0.48 are ready for testing. You can find
>> them at:
>
>> http://httpd.apache.org/dev/dist/
>
>minor problem with InstallBin on Win32; seems the ssl-std.conf was renamed recently:
>
>--- Makefile.win.orig Tue Mar 11 01:18:52 2003
>+++ Makefile.winWed Oct 29 02:57:36 2003
>@@ -630,8 +630,8 @@
> <<
>if not exist "$(INSTDIR)\conf\httpd.conf" \
>copy "$(INSTDIR)\conf\httpd.default.conf" "$(INSTDIR)\conf\httpd.conf"
>- copy docs\conf\ssl-std.conf "$(INSTDIR)\conf\ssl.default.conf" <.y
>- -awk -f <
>"$(INSTDIR)\conf\ssl.default.conf"
>+ copy docs\conf\ssl-std.conf.in "$(INSTDIR)\conf\ssl.default.conf" <.y
>+ -awk -f <
>"$(INSTDIR)\conf\ssl.default.conf"
> BEGIN {
>serverroot = ARGV[2];
>delete ARGV[2];
>
>
>Guenter.
Antw: win32 piped logs really broken in 2.0.45
Hello, we have seen this behaviour with 2.0.45 when it can't write to the logfile (for whatever reason) Our server under NT 4.0 logs just fine (with ~20 rotatelogs running for the different vhosts.) André >>> [EMAIL PROTECTED] 04.04.2003 19:04:01 >>> See subject... Setup customlog to do piped access logging. Start the server and a rotatelogs.exe console pops up. Send the server a request, and that console goes down and another pops up (different pid). No access log is created. Yech... Looking into it. Bill
Re: Apache 2.0.45 -alpha tarball candidates for testing
Works fine under NT 4.0 with ssl and mod_jk since ~10 hours so far. André >>> [EMAIL PROTECTED] 31.03.2003 19:31:37 >>> Works just dandy under Solaris 8, prefork and worker, with SSL enabled. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
Antw: Re: Now tagged new Apache 2.0.45 candidate.
>> [EMAIL PROTECTED] 28.03.2003 06:55:25 >>> >At 11:27 PM 3/27/2003, William A. Rowe, Jr. wrote: >>Based on observations of broken SSLMutex behavior on Win32, >>and some other protocol.c based-bugs, we have now created what >>we hope is the final release candidate tag, WROWE_2_0_45_RC2. >Apologies that I wasn't specific, this tag includes the httpd-2.0 >repository, but also apr, apr-util and apr-iconv which will be released >in tandem as APR_0_9_3. The mutex problem mentioned above is I get a empty apr when using this tag. All others (httpd-2.0 apr-utils and apr-iconv) work. André
Re: Antw: Re: APR SSLMutex win32 2.0.45 RC1
>>But currently we are at the stage that the SSLMutex passes a NULL >>filename in for the mutexname and assumes the apr will generate >>"something". >It's more correct to say that it assumes APR "does the right thing", which >it does. Under Win32 it creates an unnamed mutex ala the mpm. The creation is OK so far. But the problem occurs when the child trys to open this mutex. Since it hasn't access the the win32 handle created by the parent, it trys to open a unnamed mutex, which of course won't do it. André
Re: Antw: Re: APR SSLMutex win32 2.0.45 RC1
>up with your dialog ;-) Be aware we are talking about win32 which >doesn't fork, so it doesn't have the same apr_global_mutex_t in the >child worker process as in the parent process. Correct. >File mutex modes aren't really win32 files - they are simply >named mutexes. Elsewhere in apr we've translated slash and >backslash to underbars so that the name is a legal object name >(as long as it's 255 characters or shorter.) Correct, the mutexname isn't allowed to have slash's in it >However, this means two servers with "logs/mymutex" end up >being the very same name. It almost seems like we need to >abspath this name, e.g. "c:/apache/logs/mymutex" and then >translate the reserved chars, so you get c__apache_logs_mymutex. >Then you can have c__apache_logs_mymutex happily coexisting >with c__apache21_logs_mymutex. Probably correct too. But currently we are at the stage that the SSLMutex passes a NULL filename in for the mutexname and assumes the apr will generate "something". server/mpm/winnt/mpm_winnt.c however does pass in a NULL filename and wishes to get NULL-filename mutex (ie. a private mutex). So a autogenerated filename from apr will probably break this behaviour. André
Antw: Re: APR SSLMutex win32 2.0.45 RC1
>I'm +1 for having the SSLMutex code autogen a bogus fname. I can add >this quickly... but please read below. In this case update the docu in the .h file accordingly. >vary. For example, would /tmp/apr879879 be OK under Win32? Again, >this is just the sort of abstraction I think would be prefect in >APR. In win32 all characters are allowed EXCEPT the / character ! So you just did hit the one of 255 (or is it unicode ?) possibilities. ;-) André
APR SSLMutex win32 2.0.45 RC1
Hello, I did some investigations on this message and found the following: Using SSLMutex default results in no-filename for the mutex. In the comments to this, there it stays: mc->szMutexFile = NULL; /* APR determines temporary filename */ According to the apr documentation (and the win32 implementation it doesnt) * @param fname A file name to use if the lock mechanism requires one. This *argument should always be provided. The lock code itself will *determine if it should be used. As for a solution to this problems my suggestions: We should initialize the mutexfilename with something "unique" in ssl_engine_config.c Instead of: mc->szMutexFile = NULL; /* APR determines temporary filename */ Proposition: mc->szMutexFile = apr_psprintf(mc->pPool, "%s.%lu", "Apache_OPENSSLMutex", (unsigned long)getpid()); Sidenote: The win32 implementations of apr_proc_mutex_create and apr_proc_mutex_child_init don't generate a error or print a warning when the (required) parameter fname is NULL. Would be nice if the APR notified this as an error.. André >>> [EMAIL PROTECTED] 25.03.2003 23:39:17 >>> William A. Rowe, Jr. schrieb: >At 02:20 PM 3/25/2003, André Schild wrote: > > >>William A. Rowe, Jr. schrieb: >> >> >> >>>Apache 2.0 testers, >>> >>>can you please help move forward the next HTTPD release by >>>checking out httpd-2.0 from the WROWE_2_0_45_RC1 tag? >>> >>> >>The SSLMutex always creates this message in the error log on the first access >>with a HTTPS request: >> >>[Tue Mar 25 21:04:55 2003] [warn] (OS 123)Die Syntax für den Dateinamen, Verzeichnisnamen oder die Datenträgerbezeichnung ist falsch. : Cannot reinit SSLMutex >> >> > >I got the message from it's number (thank goodness we finally group >these by 'role') - and I'm diagnosing now. > > There is a small error in my previous mail. Of course I use the SSLMutex default config entry, as on win32 you only have the choice between none and default. I'm using openssl 0.9.7a and MS dev studio 6.0 André
Antw: Re: [patch]2 : mod_auth_ldap doesn't effectively use thecache with"require user User1 User2 .." dir
> [EMAIL PROTECTED] 16.03.2003 21:45:12 >>> >>Graham Leggett <[EMAIL PROTECTED]> wrote: >Then your idea to use "'s and have only one check is probably a solution >or we can have an extra option to specify how this "require user User1 User2 .." > to be interpreted - as a single value or as a list of values. I'm against yet another option, because we can't guarantee correct behaviour if the quotes are turned off. Better when we find a " in the line, use those as quotes. If no " are found, then use the blanks as separarators. (And this automatically disallows usernames with blanks in them.) >BTW, how the other apache authentication modules treat this situation? Good question >If first all values are checked against the cache and then if we >don't find a match we go to the LDAP - this will make the >cache used properly - no ldap requests sent if we have cached >the positive result, the negative results are not cached anyway. > I don't see negative cacheing. The only advantage a negative caching would provide is (slightly) a better handling of DOS attacks. Of course a DOS attack is still possible when requestings user1, user2 user9 Of course a negative cache should have a "short" cache lifetime. 3-5 minutes or so. André aarboard ag internet - networks - screen&print design - multimedia Egliweg 10 - Postfach 214 - CH-2560 Nidau (Switzerland) Phone +41 32 332 9714 - Fax +41 32 332 9715 www.aarboard.ch - [EMAIL PROTECTED]
Antw: Re: Standarizing mod_auth_ldap across LDAP SDKs...
>makefiles will need to be updated to comply with the #defines values in >apr_ldap.h.in (Unix) and apr_ldap.hw (Win32). Could somebody on those >platforms fix the makefiles? If no one is faster, I could do the win32 part during the next 3-4 days. André
Antw: Re: [PATCH] Native Win32 mod_auth_ldap + util_ldap
>If Netware or Win32 can 'conditionally' support ldap, then we need >to consider having an apr_ldap.hxx file that contains all of the >#define APR_HAS_LDAP_* 0 statements. The header should >always exist, and inform the app if ldap is available. >Of course, I'm expecting that Win32 will support LDAP unconditionally >using MS's implementation, and it sounds the same on Netware. Wrong expectation. (Perhaps on w2k server) Under win32 there is no guarantee that a ldap library is available. For compiling/linking the apache with ldap support under win32 you will need a third party ldap library. Actually we did build it with Netscape ldap sdk. André
Antw: Re: stable 2.0 trees
+1 for a 2.1 tree Why? : When a securityproblem/bug is found in 2.0.43, then I excpect to get a new version who is just a "drop-in" replacement for it. What can be accepted is - To have to recompile all modules - Make sourcecode changes to the modules if AND ONLY IF the api change is directly involved with the problem/bug. What can't be accepted is: - Having to change the source of the modules because some API has changed - Changes in the configuration files because of nonrelated changes in apache About one month ago a lengthy discussion why httpd 2.0 is not used very much compared the 1.3.x versions was on this made list. When we now release a 2.0.44 with all the auth changes in it, we will have a reason more to add to this list... If the new version uses a version number like 2.0.43.1 or 2.0.44 is not realy relevant. But in fact it's a branch in the source code and two branches to maintain. So I'm for 2.1 to get all the auth changes done in, and use 2.0.44 for stability. [EMAIL PROTECTED] wrote: >My one thought about this proposal is that it is unclear whether or >not this is attempting to emulate the Perl versioning scheme. If so, >then it's backwards, since Perl uses even numbers for releases and odd >numbers for development, but Bill proposed that 2.1 be the "stable" >branch, and "2.2" become the "development" branch. Linux kernel uses 2.2/2.4/2.6 for stable, 2.1/2.3/2.5 for development. Why not let the 2.0 be the stable one, 2.1 the one with all the auth rewrite in it and when it's ready publish it a 2.2 GA ? André
Re: Antw: Re: building aut_ldap under win32
> [EMAIL PROTECTED] 09.10.2002 10:14:58 >>> >Andre Schild wrote: >> What about renaming util_ldap.c to mod_ldap.c ? >Is it that important for now? I think lets rather worry about this when >mod_auth_ldap gets fitted to the new authn/authz framework. Then we will >be renaming a whole bunch of stuff. Ok, lets wait. André
Antw: Re: building aut_ldap under win32
Here the updates. The apr_ldap.hw goes in the apr-util/include, as it isn't automaticaly generated for windows. What about renaming util_ldap.c to mod_ldap.c ? Would make the naming of the files/modules more consistent, but on the other hand break the build process for all platforms. But if we wish to change, then we should do it probably asap André >>> [EMAIL PROTECTED] 09.10.2002 08:53:31 >>> Andre Schild wrote: > finaly I got the module compiled and running under w2k. Sweet... I just comitted them - thanks! > If my changes are accepted, then I'm willing to update the README.ldap > file to replect the win32 > steps to build the module. If you can update the README it would be great... Regards, Graham -- - [EMAIL PROTECTED]"There's a moon over Bourbon Street tonight..." README.ldap.diff Description: Binary data apr_ldap.hw Description: Binary data
building aut_ldap under win32
Hello, finaly I got the module compiled and running under w2k. Here the steps required to get it working: 1. put the two dsp files from the attachement in the experimental folder 2. the netscape/iplanet ldap libraries are installed in srclib\ldap 3. Apply the util_ldap.c.diff and util_ldap.h.diff to the source tree (based on 2.0.43 release) 4. Compile the two modules using the dsp files 5. You get a mod_auth_ldap.so and a util_ldap.so module 6. Put them in the modules directory, don't forget to copy the nsldap32v50.dll somewhere where apache.exe will find it 7. Load the two modules in your httpd.conf, like below: LoadModule ldap_module modules/util_ldap.so LoadModule auth_ldap_module modules/mod_auth_ldap.so 8. Configure the directories as described in the docus. 9. Start apache.exe Additional infos: First: A main problem in the current sources is, that we build two modules (ldap_module and auth_ldap_module) as dll's, but the functions from ldap_module who are required by the mod_auth_ldap don't get exported. To do this, I have changed the util_ldap.h/c files (see diffs) to use a dllexport/import stuff, similar to the system used by mod_proxy. Second: ldap_module is "home" in a file named util_ldap, where as all other modules use the form of mod_XY Why not change the source-filename to mod_ldap too ? If my changes are accepted, then I'm willing to update the README.ldap file to replect the win32 steps to build the module. A. Schild dspfiles.zip Description: Zip compressed data util_ldap.h.diff Description: Binary data util_ldap.c.diff Description: Binary data
Re: Antw: Re: Instructions for building aut_ldap under win32 ?
Did you compile mod_auth_ldap as one module, and util_ldap as the second one ? If yes, how did you resolve the missing exports from util_ldap to be able to link mod_auth_ldap. Actually it seems for me, that in util_ldap.h all functions should be declared as AP_DECLARE_NONSTD (or whatever the types/returnvalues require). This way they get exported and can be imported by the mod_auth_ldap module. Building mod_auth_ldap together with util_ldap doesn't work, since util_ldap_connection_find in util_ldap.c has it's own moduleconfiguration where it stores the pool of ldap connections. André >>> [EMAIL PROTECTED] 08.10.2002 21:54:31 >>> Hmmm... . mod_ldap and mod_auth_ldap were working fine for me at 2.0.40 -- once my patch was applied to util_ldap_cache.c (before which it crashed due to unintialized memory). This patch was in before things were moved back into experimental Günter Knauf wrote: >Hi Andre, > > > >>here is my dsw/dsp file. (Configured for Netscape/iplanet SDK in >>srclib\ldap >>The module loads fine in relase and debug modes in apache, but as soon >>as a auth request commes, apache crashes. >> >> >hmm, I've seen exactly the same with another module mod_auth_pgsql; I thought it was the module as it is beta stuff, but it works fine on Linux; but now I think more there's a general problem with Win32...?? > >Guenter. > >
Re: Antw: Re: Instructions for building aut_ldap under win32 ?
Hello Guenter, >> The module loads fine in relase and debug modes in apache, but as soon >> as a auth request commes, apache crashes. >hmm, just looked at your *.dsp, but I think this is not planned so. Look at >util_ldap.c, it has an own module declaration, and from my understanding >it should be build as separate module and not linked together with mod_auth_ldap; > instead you should have two modules: util_ldap.so and mod_auth_ldap.so... O I didn't even look at the source of util_ldap, since it compiled on first try... But I think for now it's not that big a problem, first get it running, then we can still splitt it in two modules... André
Re: Antw: Re: Instructions for building aut_ldap under win32 ?
Hallo Günter, >> The module loads fine in relase and debug modes in apache, but as soon >> as a auth request commes, apache crashes. >hmm, I've seen exactly the same with another module mod_auth_pgsql; >I thought it was the module as it is beta stuff, but it works fine on Linux; but > now I think more there's a general problem with Win32...?? The default linux apache uses a non-threaded MPM, so all the mutex stuff doesn't get build/included. Look at the #if APR_HAS_THREADS lines, they aren't used by linux usually. But win32 uses threads (and the netware I think too) so this code is probably not widely "tested" André
Antw: Re: Instructions for building aut_ldap under win32 ?
Hello, here is my dsw/dsp file. (Configured for Netscape/iplanet SDK in srclib\ldap The module loads fine in relase and debug modes in apache, but as soon as a auth request commes, apache crashes. First tests show a stack trace of mod_auth_ldap -> apr_thread_mutex_create -> apr_palloc -> crash It gives a access violation, and it seems as if the pool parameter is invalid. Will investigate on the problem... André experimental.zip Description: Zip compressed data
Antw: Re: Instructions for building aut_ldap under win32 ?
>What seems to be the sticking point? I seem to recall that it was 1. where do I see if my APR has the ldap support included ? (I assume it hasn't) 2. Where should the ldap libraries/sdk be installed, so they are found ? >the LDAP stuff has moved into experimental. Actually, I would have >hoped that someone would contribute MSVC++ projects for these and >eliminate the need for questions like this. Things were to messy before If I can get it building, then we might have one to upload ;-) André
Instructions for building aut_ldap under win32 ?
Hello, can someone give me some hints how to build the auth_ldap module of the 2.0.43 apache ? I've already built the "normal" ssl version of apache since ~2.0.36... Actually we use another (half-self written) auth_ldap module with 2.0.42, but since it would require major work to get it working right. André
Antw: Vote: mod_jk connector in /experimental
>other container implements the protocol ? Moreover, the mod_jk is of no >use to other webservers than apache and with the increased use of But mod_jk is of no use without tomcat either.. >servlets, most apaches will use mod_jk anyway. Not so sure about this one. (For my webservers true, but all others too ?) Then lets ask for the same for the PHP module... I don't think it should go into the httpd project. I would let it where it is, perhaps add some more links to better find it, but otherwise, NO. André
Antw: RE: 2.0/2.1 split?
>I think this is an important fact which then stops many >users from updating to Apache2 because of missing their favorite modules... >All platforms which mainly use binary distributions such as Win32 and Netware are affected... As we are using Apache 2.x on Win32 and Linux I'm just affected by those "not" available modules. We upgraded from 1.3.x to the 2.x version about one month ago. We had the intention to do it before, but we did not because: - A 2.0 release is still a .0 release (The .36 doesn't count in this) Never trust a .0 release !! It's in my mind and probably in the heads of most sysadmins out there too. - mod_jk for the java integration is very difficult to find, and binaries are not available for win32 Actually it works, with some small problems, but it now works - mod_auth_ldap . did find exactly one, but who didn't work on win32, nothing else. So I had to investigate and solve the problem myself. For 1.3.x there are a lot of ldap modules available, even win32 binaries - mod_ssl no mod_ssl included in the win32 binaries and until recently no win32 binaries of this module where available Consider all the things above, then tell a sysadmin why he should upgrade, his 1.3.x server just does then job too. There are just some important modules missing or not working reliably for productive environments. When the modules become available and the api doesn't change for several months, then I think, the upgrades to the 2.0.x release will happen. We have our own webservers and also maintain several client webservers too. Our servers have been upgraded to 2.0.40, but we will only upgrade our client webservers to the 2.x release, when our own servers have proved stability for 2-3 months. André
Antw: Re: 2.1 repository?
>[EMAIL PROTECTED] 30.08.2002 19:20:58 >>On Fri, Aug 30, 2002 at 06:04:06PM +0100, Tony Finch wrote: >> The Apache project's dislike of branching seems slightly odd to me >> given that it seems to work quite effectively over long periods of >> time in the BSD projects. >+1 >This is not everyone here, only a vocal minority. I am totally in favor >of using cvs branches, especially for 2.1, both for the reason that I +1 for branches And consider naming the next repository 3.x ;-) André
Re: [PROPOSAL] Move AUTH_LDAP to /experimental(was:authentication rewrite)
+1 to this as well. We use LDAP authentication with 2.0.40 on win32 already and would very welcome a "official" module for this >Now that 2.0.40 has been released and we are in development of > .41 and the fact that there has been a proposal for re-architecting > the AUTH modules, I would like to propose that we move AUTH_LDAP > out of it's own project and into experimental. This will enable > AUTH_LDAP to get more exposure as an external module, allow it to > be included in future > releases of Apache 2 for testing and stabilization, and make sure > that it is not overlooked in future development. LDAP is an > important > authentication method and should be supported in Apache.
