Re: Small things to do
On 09 Nov 2011, at 1:52 AM, Daniel Ruggeri wrote: One thing I know for certain that does not fall in line with this is if some.where.back.there and some.where.different are signed out of the same CA, but you wish to send different client certs based on path (such a use case exists, silly as it may seem in my eyes). That would be the use case, yes. We have a service oriented platform that is hardened end to end, in other words services are client cert protected, and apps must strongly authenticate to use the service using their own client cert. Sometimes the apps need to expose the URL space of the service directly (for the benefit of ajax, etc), but currently can't using a simple proxypass because the app next door needs to expose a different service with a different client cert. As to the use case being silly, we live in an age of the cloud, where one app at location A is referencing a service in location B, with an unsecured network in between. Times have changed :) Regards, Graham --
Memory Leak when working with AliasMatch and Cache
Hi all, We have just witnessed a memory leak in the case of Apache 2.2.16 with WinOpenSSL running on Windows when downloading a file that is served from the disk via the AliasMatch directive and does not reside in the cache but is configured as cacheable. In this case, we see that the child process memory grows by the same size as the size of the file being downloaded and the memory usage does not decline. After this initial download, the file is cached and when downloading the file again, there is no memory leak. We have also sent that when Apache is configured not to cache this file and it is served via AliasMatch there is no leak. Anyone seen this before? Thanks, Ofer Israeli Team Leader, Endpoint Security Management Check Point Software Technologieshttp://www.checkpoint.com/ * +972-3-753-4715 | M +972-54-749-0320
RE: Memory Leak when working with AliasMatch and Cache
I don't think that this has something to do with AliasMatch. Most likely this is caused by reading the file that should be delivered into some request pool backed memory in order to write it to the cache. If you don't cache the file it is probably not read by httpd but transported via a sendmail like mechanism (transferfile on Windows?). Regards Rüdiger From: Ofer Israeli [mailto:of...@checkpoint.com] Sent: Mittwoch, 9. November 2011 14:38 To: dev@httpd.apache.org Subject: Memory Leak when working with AliasMatch and Cache Hi all, We have just witnessed a memory leak in the case of Apache 2.2.16 with WinOpenSSL running on Windows when downloading a file that is served from the disk via the AliasMatch directive and does not reside in the cache but is configured as cacheable. In this case, we see that the child process memory grows by the same size as the size of the file being downloaded and the memory usage does not decline. After this initial download, the file is cached and when downloading the file again, there is no memory leak. We have also sent that when Apache is configured not to cache this file and it is served via AliasMatch there is no leak. Anyone seen this before? Thanks, Ofer Israeli Team Leader, Endpoint Security Management Check Point Software Technologies http://www.checkpoint.com/ * +972-3-753-4715 | M +972-54-749-0320
[VOTE] Release 2.3.15-beta as beta
The 2.3.15-beta (prerelease) tarballs are available for download at test: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as 2.3.15-beta BETA and, with luck, this will be our last beta and the next release in ~2weeks or less will be 2.4.0 GA!! Vote will last the normal 72 hours...
Re: [VOTE] Release 2.3.15-beta as beta
Hi Jim, it looks like your key expired last Friday? % gpg --verify ../incoming/httpd/trunk/2.3.15/httpd-2.3.15-beta.tar.gz.asc gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information gpg: Signature made November 9, 2011 3:20:26 PM CET using RSA key ID 791485A8 gpg: Good signature from Jim Jagielski (Release Signing Key) j...@apache.org gpg: aka Jim Jagielski j...@jimjag.com gpg: aka Jim Jagielski j...@jagunet.com % gpg --list-keys 791485A8 gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information pub 4096R/791485A8 2010-11-04 uid Jim Jagielski (Release Signing Key) j...@apache.org uid Jim Jagielski j...@jimjag.com uid Jim Jagielski j...@jagunet.com sub 4096R/9B6D9BF7 2010-11-04 Regards, Rainer On 09.11.2011 06:24, Jim Jagielski wrote: The 2.3.15-beta (prerelease) tarballs are available for download at test: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as 2.3.15-beta BETA and, with luck, this will be our last beta and the next release in ~2weeks or less will be 2.4.0 GA!! Vote will last the normal 72 hours...
Re: Current LoadModule enabling status
On 08.11.2011 13:57, Stefan Fritsch wrote: On Tue, 8 Nov 2011, Rainer Jung wrote: After Stefan's change r1199027 we no longer load all built modules by default. The new behaviour is (citing Stefan): By default, only load those modules that are either required or explicitly selected by a configure --enable-foo argument. The LoadModule statements for modules enabled by --enable-mods-shared=most and friends will be commented out. I compiled trunk with reallyall and here's the list which of our modules are enabled by default - if it is compiled. Now is the time to comment whether modules should switch between enabled and disabled. Enabled I would vote for these to be demoted to 'most' / not loaded by default actions_module auth_form_module buffer_module ratelimit_module request_module +1 This one is actually not enabled by default? Did you pass --enable-suexec? suexec_module Yes, I did, but that one was the only flag changing the build state of an individual module. Regards, Rainer
Re: [VOTE] Release 2.3.15-beta as beta
On 09.11.2011 07:43, Rainer Jung wrote: Hi Jim, it looks like your key expired last Friday? Oups, was so convinced it is new, that I didn't see it already expired a year ago. Maybe you should sign 2.4.0 with a new one? Rainer % gpg --verify ../incoming/httpd/trunk/2.3.15/httpd-2.3.15-beta.tar.gz.asc gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information gpg: Signature made November 9, 2011 3:20:26 PM CET using RSA key ID 791485A8 gpg: Good signature from Jim Jagielski (Release Signing Key) j...@apache.org gpg: aka Jim Jagielski j...@jimjag.com gpg: aka Jim Jagielski j...@jagunet.com % gpg --list-keys 791485A8 gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information pub 4096R/791485A8 2010-11-04 uid Jim Jagielski (Release Signing Key) j...@apache.org uid Jim Jagielski j...@jimjag.com uid Jim Jagielski j...@jagunet.com sub 4096R/9B6D9BF7 2010-11-04 Regards, Rainer
Fwd: [users@httpd] 2.3.15-beta: module proxy_balancer requires the not automatically loaded module slotmem_shm
Devs, This one in from the users@ list. It sounds vaguely familiar to the issue previously mentioned about win32 defaults and some strange dependency failure between proxy_balancer and slotmem providers. Only, this is on the bleeding edge beta posted today, and hits Unix (particularly with our new cleaned-up default for #LoadModule). Thanks for the report, Jens. Original Message Subject: [users@httpd] 2.3.15-beta: module proxy_balancer requires the not automatically loaded module slotmem_shm Date: Wed, 9 Nov 2011 16:25:38 +0100 (CET) From: Schleusener, Jens jens.schleuse...@t-online.de To: us...@httpd.apache.org Hi, sorry if I report a small problem to this list although 2.3.15 seems still beta and I am not sure if it's not a personal problem: I just downloaded and extracted the source packages httpd-2.3.15-beta.tar.bz2 and httpd-2.3.15-beta-deps.tar.bz2 and issued in the httpd-2.3.15-beta directory ./configure --prefix=/usr/local/www/httpd2.3.15-beta --enable-so \ --disable-ldap --with-included-apr --with-pcre=/usr/local/soft \ --enable-mods-shared=most cache mem-cache mime-magic proxy ssl unique_id and then a make and make install and tried to start the server but without success. In the error_log I found [Wed Nov 09 16:19:47.001264 2011] [proxy_balancer:emerg] [pid 5581:tid 3076073744] ap_lookup_provider slotmem failed: is mod_slotmem_shm loaded?? Configuration Failed Ok, so I simply removed in the installed default httpd.conf the comment sign within the line #LoadModule slotmem_shm_module modules/mod_slotmem_shm.so and as expected now all works. But if the used options above are valid ones so the according automatically generated httpd.conf seems not correct per se (I didn't tested yet other combinations of options in combination with the option proxy). Is that normal or an error of the configuration process (or of the choosen configuration options)? Regards Jens - The official User-To-User support forum of the Apache HTTP Server Project. See URL:http://httpd.apache.org/userslist.html for more info. To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org from the digest: users-digest-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
RE: Memory Leak when working with AliasMatch and Cache
Your hypothesis sounds reasonable to me that has to do with memory that should be written to the cache, but the question pertains why this memory is not freed once the file is written to the cache? Ofer Israeli Team Leader, Endpoint Security Management Check Point Software Technologieshttp://www.checkpoint.com/ * +972-3-753-4715 | M +972-54-749-0320 From: Plüm, Rüdiger, VF-Group [mailto:ruediger.pl...@vodafone.com] Sent: Wednesday, November 09, 2011 3:57 PM To: dev@httpd.apache.org Subject: RE: Memory Leak when working with AliasMatch and Cache I don't think that this has something to do with AliasMatch. Most likely this is caused by reading the file that should be delivered into some request pool backed memory in order to write it to the cache. If you don't cache the file it is probably not read by httpd but transported via a sendmail like mechanism (transferfile on Windows?). Regards Rüdiger From: Ofer Israeli [mailto:of...@checkpoint.com] Sent: Mittwoch, 9. November 2011 14:38 To: dev@httpd.apache.org Subject: Memory Leak when working with AliasMatch and Cache Hi all, We have just witnessed a memory leak in the case of Apache 2.2.16 with WinOpenSSL running on Windows when downloading a file that is served from the disk via the AliasMatch directive and does not reside in the cache but is configured as cacheable. In this case, we see that the child process memory grows by the same size as the size of the file being downloaded and the memory usage does not decline. After this initial download, the file is cached and when downloading the file again, there is no memory leak. We have also sent that when Apache is configured not to cache this file and it is served via AliasMatch there is no leak. Anyone seen this before? Thanks, Ofer Israeli Team Leader, Endpoint Security Management Check Point Software Technologieshttp://www.checkpoint.com/ * +972-3-753-4715 | M +972-54-749-0320
Re: [VOTE] Release 2.3.15-beta as beta
2010-11-04 is the day I created the new key… it's unexpired (at least from what I can see ;) ) On Nov 9, 2011, at 7:52 AM, Rainer Jung wrote: On 09.11.2011 07:43, Rainer Jung wrote: Hi Jim, it looks like your key expired last Friday? Oups, was so convinced it is new, that I didn't see it already expired a year ago. Maybe you should sign 2.4.0 with a new one? Rainer % gpg --verify ../incoming/httpd/trunk/2.3.15/httpd-2.3.15-beta.tar.gz.asc gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information gpg: Signature made November 9, 2011 3:20:26 PM CET using RSA key ID 791485A8 gpg: Good signature from Jim Jagielski (Release Signing Key) j...@apache.org gpg: aka Jim Jagielski j...@jimjag.com gpg: aka Jim Jagielski j...@jagunet.com % gpg --list-keys 791485A8 gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information pub 4096R/791485A8 2010-11-04 uid Jim Jagielski (Release Signing Key) j...@apache.org uid Jim Jagielski j...@jimjag.com uid Jim Jagielski j...@jagunet.com sub 4096R/9B6D9BF7 2010-11-04 Regards, Rainer
Re: [VOTE] Release 2.3.15-beta as beta
Bring it (the key) tonight :) On 09/11/2011 11:12, Jim Jagielski wrote: 2010-11-04 is the day I created the new key… it's unexpired (at least from what I can see ;) ) On Nov 9, 2011, at 7:52 AM, Rainer Jung wrote: On 09.11.2011 07:43, Rainer Jung wrote: Hi Jim, it looks like your key expired last Friday? Oups, was so convinced it is new, that I didn't see it already expired a year ago. Maybe you should sign 2.4.0 with a new one? Rainer % gpg --verify ../incoming/httpd/trunk/2.3.15/httpd-2.3.15-beta.tar.gz.asc gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information gpg: Signature made November 9, 2011 3:20:26 PM CET using RSA key ID 791485A8 gpg: Good signature from Jim Jagielski (Release Signing Key) j...@apache.org gpg: aka Jim Jagielski j...@jimjag.com gpg: aka Jim Jagielski j...@jagunet.com % gpg --list-keys 791485A8 gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information pub 4096R/791485A8 2010-11-04 uid Jim Jagielski (Release Signing Key) j...@apache.org uid Jim Jagielski j...@jimjag.com uid Jim Jagielski j...@jagunet.com sub 4096R/9B6D9BF7 2010-11-04 Regards, Rainer
Re: [VOTE] Release 2.3.15-beta as beta
Already sent to ST yesterday… On Nov 9, 2011, at 11:19 AM, Issac Goldstand wrote: Bring it (the key) tonight :) On 09/11/2011 11:12, Jim Jagielski wrote: 2010-11-04 is the day I created the new key… it's unexpired (at least from what I can see ;) ) On Nov 9, 2011, at 7:52 AM, Rainer Jung wrote: On 09.11.2011 07:43, Rainer Jung wrote: Hi Jim, it looks like your key expired last Friday? Oups, was so convinced it is new, that I didn't see it already expired a year ago. Maybe you should sign 2.4.0 with a new one? Rainer % gpg --verify ../incoming/httpd/trunk/2.3.15/httpd-2.3.15-beta.tar.gz.asc gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information gpg: Signature made November 9, 2011 3:20:26 PM CET using RSA key ID 791485A8 gpg: Good signature from Jim Jagielski (Release Signing Key) j...@apache.org gpg: aka Jim Jagielski j...@jimjag.com gpg: aka Jim Jagielski j...@jagunet.com % gpg --list-keys 791485A8 gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information pub 4096R/791485A8 2010-11-04 uid Jim Jagielski (Release Signing Key) j...@apache.org uid Jim Jagielski j...@jimjag.com uid Jim Jagielski j...@jagunet.com sub 4096R/9B6D9BF7 2010-11-04 Regards, Rainer
Re: [VOTE] Release 2.3.15-beta as beta
On 09.11.2011 11:12, Jim Jagielski wrote: 2010-11-04 is the day I created the new key… it's unexpired (at least from what I can see ;) ) Sorry for the noise, false alarm :( Regards, Rainer On Nov 9, 2011, at 7:52 AM, Rainer Jung wrote: On 09.11.2011 07:43, Rainer Jung wrote: Hi Jim, it looks like your key expired last Friday? Oups, was so convinced it is new, that I didn't see it already expired a year ago. Maybe you should sign 2.4.0 with a new one? Rainer % gpg --verify ../incoming/httpd/trunk/2.3.15/httpd-2.3.15-beta.tar.gz.asc gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information gpg: Signature made November 9, 2011 3:20:26 PM CET using RSA key ID 791485A8 gpg: Good signature from Jim Jagielski (Release Signing Key) j...@apache.org gpg: aka Jim Jagielskij...@jimjag.com gpg: aka Jim Jagielskij...@jagunet.com % gpg --list-keys 791485A8 gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information pub 4096R/791485A8 2010-11-04 uid Jim Jagielski (Release Signing Key)j...@apache.org uid Jim Jagielskij...@jimjag.com uid Jim Jagielskij...@jagunet.com sub 4096R/9B6D9BF7 2010-11-04 Regards, Rainer
Re: [VOTE] Release 2.3.15-beta as beta
On Wed, Nov 9, 2011 at 6:24 AM, Jim Jagielski j...@jagunet.com wrote: The 2.3.15-beta (prerelease) tarballs are available for download at test: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as 2.3.15-beta BETA and, with luck, this will be our last beta and the next release in ~2weeks or less will be 2.4.0 GA!! Vote will last the normal 72 hours... Is anyone seeing this? Test Summary Report --- t/modules/cgi.t (Wstat: 0 Tests: 53 Failed: 0) Parse errors: Bad plan. You planned 58 tests but ran 53. t/modules/proxy.t (Wstat: 0 Tests: 15 Failed: 2) Failed tests: 9-10
Re: Fwd: [users@httpd] 2.3.15-beta: module proxy_balancer requires the not automatically loaded module slotmem_shm
Hi, On Wed, 9 Nov 2011, William A. Rowe Jr. wrote: This one in from the users@ list. It sounds vaguely familiar to the issue previously mentioned about win32 defaults and some strange dependency failure between proxy_balancer and slotmem providers. Only, this is on the bleeding edge beta posted today, and hits Unix (particularly with our new cleaned-up default for #LoadModule). I talked with Rainer about this and we came to the conclusion, that we simply should keep non-default modules commented out, even if they have been explicitly enabled with --enable-foo. This has also the advantage that it is more likely that the user will only enable what he currently needs, even if he has built some additional modules he may need later. Does anyone disagree? Cheers, Stefan
Re: [users@httpd] 2.3.15-beta: module proxy_balancer requires the not automatically loaded module slotmem_shm
On 09 Nov 2011, at 11:53 PM, Stefan Fritsch wrote: I talked with Rainer about this and we came to the conclusion, that we simply should keep non-default modules commented out, even if they have been explicitly enabled with --enable-foo. This has also the advantage that it is more likely that the user will only enable what he currently needs, even if he has built some additional modules he may need later. Definite +1. I hear from time to time people saying that httpd is big, but it turns out they're just loading a bunch of modules they didn't need when they started with a default config. It's particularly important for distros, where most/all modules are likely to be compiled in anyway, but the default config should remain lean. Regards, Graham --
Re: Current LoadModule enabling status
testing 2.3.15 on AIX, I found every module commented out. http://people.apache.org/~covener/config.log CC=xlc_r -q64; export CC ./configure \ --prefix=/tmp/httpd-2.3.15-beta/built \ --enable-ldap \ --with-ldap=ibmldap \ --with-ldap-include=/home/covener/SRC/2.2.8/6.2.0.1-TIV-ITDS/rios_aix_5/opt/IBM/ldap/V6.2/include/ \ --with-ldap-lib=/home/covener/SRC/2.2.8/6.2.0.1-TIV-ITDS/rios_aix_5/opt/IBM/ldap/V6.2/lib64/ \ --enable-mods-shared=reallyall \ --disable-ssl \ --with-z=/home/covener/gnu \ CC=xlc_r -q64 \ $@
Re: Current LoadModule enabling status
(but maybe I've misunderstood the change -- doing my homework) On Wed, Nov 9, 2011 at 5:38 PM, Eric Covener cove...@gmail.com wrote: testing 2.3.15 on AIX, I found every module commented out. http://people.apache.org/~covener/config.log CC=xlc_r -q64; export CC ./configure \ --prefix=/tmp/httpd-2.3.15-beta/built \ --enable-ldap \ --with-ldap=ibmldap \ --with-ldap-include=/home/covener/SRC/2.2.8/6.2.0.1-TIV-ITDS/rios_aix_5/opt/IBM/ldap/V6.2/include/ \ --with-ldap-lib=/home/covener/SRC/2.2.8/6.2.0.1-TIV-ITDS/rios_aix_5/opt/IBM/ldap/V6.2/lib64/ \ --enable-mods-shared=reallyall \ --disable-ssl \ --with-z=/home/covener/gnu \ CC=xlc_r -q64 \ $@ -- Eric Covener cove...@gmail.com
Re: [VOTE] Release 2.3.15-beta as beta
Am 09.11.2011 15:24, schrieb Jim Jagielski: The 2.3.15-beta (prerelease) tarballs are available for download at test: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as 2.3.15-beta BETA and, with luck, this will be our last beta and the next release in ~2weeks or less will be 2.4.0 GA!! Vote will last the normal 72 hours... I believe Eric added some SSL stuff to mod_lua, and this now causes at 1st glance that it doesnt compile at least for NetWare, and most likely also not for Windows (static makefiles need to be fixed); but in addition I think we need to make this SSL stuff optional so that its possible to build a mod_lua without SSL support. Gün.
Re: Fwd: [users@httpd] 2.3.15-beta: module proxy_balancer requires the not automatically loaded module slotmem_shm
On 09.11.2011 13:53, Stefan Fritsch wrote: Hi, On Wed, 9 Nov 2011, William A. Rowe Jr. wrote: This one in from the users@ list. It sounds vaguely familiar to the issue previously mentioned about win32 defaults and some strange dependency failure between proxy_balancer and slotmem providers. Only, this is on the bleeding edge beta posted today, and hits Unix (particularly with our new cleaned-up default for #LoadModule). I talked with Rainer about this and we came to the conclusion, that we simply should keep non-default modules commented out, even if they have been explicitly enabled with --enable-foo. This has also the advantage that it is more likely that the user will only enable what he currently needs, even if he has built some additional modules he may need later. Does anyone disagree? To recall: that would mean the LoadModule lines for the following modules are the only ones *not* commented out in the default config (including latest feedback): access_compat_module alias_module allowmethods_module auth_basic_module authn_core_module authn_file_module authz_core_module authz_groupfile_module authz_host_module authz_user_module autoindex_module cgid_module dir_module env_module filter_module include_module log_config_module mime_module negotiation_module reqtimeout_module setenvif_module status_module unixd_module userdir_module version_module plus the default MPM. What about: autoindex_module cgid_module filter_module include_module negotiation_module userdir_module Shouldn't we comment them out as well? Concerning the AAA modules. Since there is by default no user/group config, shouldn't we also comment out: auth_basic_module authn_file_module authz_groupfile_module authz_user_module Finally I'm not sure about allowmethods_module. It is very useful, but not used in the default config. Rainer
Re: Fwd: [users@httpd] 2.3.15-beta: module proxy_balancer requires the not automatically loaded module slotmem_shm
On 11/9/2011 3:53 PM, Stefan Fritsch wrote: Hi, On Wed, 9 Nov 2011, William A. Rowe Jr. wrote: This one in from the users@ list. It sounds vaguely familiar to the issue previously mentioned about win32 defaults and some strange dependency failure between proxy_balancer and slotmem providers. Only, this is on the bleeding edge beta posted today, and hits Unix (particularly with our new cleaned-up default for #LoadModule). I talked with Rainer about this and we came to the conclusion, that we simply should keep non-default modules commented out, even if they have been explicitly enabled with --enable-foo. This has also the advantage that it is more likely that the user will only enable what he currently needs, even if he has built some additional modules he may need later. So, absolutely no mechanism to populate the default config with the info, status modules, etc? I don't have an opinion yet. Of course I agree with simplified .conf snippets, smaller default server footprint, KISS directive complexity etc. Does anyone disagree? Provide a flag to ignore the new logic completely (enabling all built modules for testers, devs etc). It's a dogfood issue, I expect that mod_proxy_balancer / slotmem won't be the only non-functioning junk that accumulates in httpd once most devs never load 80% of the modules. In fact, --enable-maintainer-mode should force-toggle this option.
Re: [users@httpd] 2.3.15-beta: module proxy_balancer requires the not automatically loaded module slotmem_shm
Isn't the point different? If someone enables mod_proxy then the configure script needs to ensure that mod_slotmem is also built… On Nov 9, 2011, at 1:53 PM, Stefan Fritsch wrote: Hi, On Wed, 9 Nov 2011, William A. Rowe Jr. wrote: This one in from the users@ list. It sounds vaguely familiar to the issue previously mentioned about win32 defaults and some strange dependency failure between proxy_balancer and slotmem providers. Only, this is on the bleeding edge beta posted today, and hits Unix (particularly with our new cleaned-up default for #LoadModule). I talked with Rainer about this and we came to the conclusion, that we simply should keep non-default modules commented out, even if they have been explicitly enabled with --enable-foo. This has also the advantage that it is more likely that the user will only enable what he currently needs, even if he has built some additional modules he may need later. Does anyone disagree? Cheers, Stefan
Re: [VOTE] Release 2.3.15-beta as beta
I believe Eric added some SSL stuff to mod_lua, and this now causes at 1st glance that it doesnt compile at least for NetWare, and most likely also not for Windows (static makefiles need to be fixed); but in addition I think we need to make this SSL stuff optional so that its possible to build a mod_lua without SSL support. It's just wrapping an existing mod_ssl optional function (mod_proxy does the same, but maybe I've flubbed a bit?) -- so I don't think it needs to be supressable.
Re: [VOTE] Release 2.3.15-beta as beta
Am 10.11.2011 00:09, schrieb Eric Covener: I believe Eric added some SSL stuff to mod_lua, and this now causes at 1st glance that it doesnt compile at least for NetWare, and most likely also not for Windows (static makefiles need to be fixed); but in addition I think we need to make this SSL stuff optional so that its possible to build a mod_lua without SSL support. It's just wrapping an existing mod_ssl optional function (mod_proxy does the same, but maybe I've flubbed a bit?) -- so I don't think it needs to be supressable. I didnt yet look self closer at it - just got the problem reported ... so I guess mod_lua doesnt use OpenSSL functions, and therefore doesnt link against OpenSSL, and loads runs still fine without mod_ssl loaded? Gün.
Re: [VOTE] Release 2.3.15-beta as beta
Am 10.11.2011 00:11, schrieb Guenter Knauf: I didnt yet look self closer at it - just got the problem reported ... so I guess mod_lua doesnt use OpenSSL functions, and therefore doesnt link against OpenSSL, and loads runs still fine without mod_ssl loaded? ok, adding include path seems to be enough - fixed in svn. Gün.
Re: Small things to do
On 08.11.2011 13:10, Stefan Fritsch wrote: - Rainer wanted to check some pcre linking issues, but I don't remember the exact details The problem is mainly gone with trunk. It concerns dependency libs, which are likely used by 3rd-party modules as well. Until 2.2 PCRE was such a library *plus* we bundled a totally outdated version. So users e.g. typically build mod_security against a newer incompatible version of PCRE which supports recursion limits etc. At runtime - at least on Solaris and Linux - by default the dynamic linker searches symbols in the order the shared objects had been loaded. So when mod_security initializes PCRE, the symbol is found in httpd core (statically linked in), but later calls for PCRE functions not existing in the old PCRE lib will be found in the additionally loaded new PCRE lib. This normally gives a crash. At least on Solaris one can add flags when linking which encodes a different search strategy in the shared objects. It is called direct linking (-Bdirect) and means, that symbols are always searched first in the shared object itself, then in its dependencies and only if not found there in the remaining shared objects. That way mod_security e.g. would find all PCRE symbols in its own PCRE dependency. For trunk the problem is much smaller, because we no longer bundle and therefore it gets more likely, that the dependency libs used to compile httpd and to compile additional libraries will be compatible. Still we (I) could document how to use e.g. the LDFLAGS resp. LDADD variables and linker flags to fix this problem. But AFAIK there is no similar solution on Linux, so the info is of limited value. Regards, Rainer
Re: Fwd: [users@httpd] 2.3.15-beta: module proxy_balancer requires the not automatically loaded module slotmem_shm
On 09.11.2011 14:48, William A. Rowe Jr. wrote: On 11/9/2011 3:53 PM, Stefan Fritsch wrote: Hi, On Wed, 9 Nov 2011, William A. Rowe Jr. wrote: This one in from the users@ list. It sounds vaguely familiar to the issue previously mentioned about win32 defaults and some strange dependency failure between proxy_balancer and slotmem providers. Only, this is on the bleeding edge beta posted today, and hits Unix (particularly with our new cleaned-up default for #LoadModule). I talked with Rainer about this and we came to the conclusion, that we simply should keep non-default modules commented out, even if they have been explicitly enabled with --enable-foo. This has also the advantage that it is more likely that the user will only enable what he currently needs, even if he has built some additional modules he may need later. So, absolutely no mechanism to populate the default config with the info, status modules, etc? I don't have an opinion yet. If you build them, the LoadModule line is there, but might be commented out. Currently the suggestion is to always let mod_status active /if build) but comment out mod_info. Of course I agree with simplified .conf snippets, smaller default server footprint, KISS directive complexity etc. Does anyone disagree? Provide a flag to ignore the new logic completely (enabling all built modules for testers, devs etc). It's a dogfood issue, I expect that mod_proxy_balancer / slotmem won't be the only non-functioning junk that accumulates in httpd once most devs never load 80% of the modules. In fact, --enable-maintainer-mode should force-toggle this option. It is there: --enable-load-all-modules will add all LoadModule lines for the modules build without commenting any of them out. Regards, Rainer
Re: [PATCH] Support for TLS Session Tickets
On Sun, Oct 2, 2011 at 12:20 AM, Kaspar Brand httpd-dev.2...@velox.ch wrote: On 30.09.2011 08:08, Paul Querna wrote: Attached is a patch http://people.apache.org/~pquerna/tls_session_ticket_support.patch to add support for setting SSL_CTX_set_tlsext_ticket_keys. I have two questions: 1) What is the right ifdef to look for support of this feature? I was just using ifdef SSL_CTX_set_tlsext_ticket_keys and it seemed to work for me.. SSL_CTRL_SET_TLSEXT_TICKET_KEYS and #ifndef OPENSSL_NO_TLSEXT, respectively - I would suggest wrapping it in the same way as SSL_CTX_set_tlsext_servername_callback/SSL_CTX_set_tlsext_servername_arg. Generally speaking, I agree with Stefan that such keys shouldn't be stored in config files as (static) plain-text strings. RFC 5077 section 5.5 lists some recommendations for the management of ticket protection keys, although it hastens to add that A full description [...] is beyond the scope of this document. I've committed an updated patch that stores the key id, hmac secret, and aes key into a file: https://svn.apache.org/viewvc?view=revisionrevision=1200040 Feedback welcome! Thanks, Paul
Re: Small things to do
On Tue, 8 Nov 2011 22:01:07 + Nick Kew n...@webthing.com wrote: On Tue, 8 Nov 2011 22:10:06 +0100 (CET) Stefan Fritsch s...@sfritsch.de wrote: Hi, yesterday at the Dover Arms pub, we discussed what needs to be done for 2.4 and we came up with a list of things that would be nice, but are definitely not blockers for GA: mod_proxy_html: I want to switch to using ap_expr for conditional evaluation. I'd've done it long ago if it wasn't for the issue of 2.0/2.2 compatibility. In trunk that's not an issue. I'll tackle it within the next 48 hours. Done. In doing so, I also discovered and fixed a couple of omission bugs. The one that matters is that I had omitted the stock proxy-html.conf that is required for mod_proxy_html to do anything. - fix the bug in mod_authn_socache that I brought up on the list recently (I will do that unless Nick beats me to it) Heh. Looking back, I said I'd do that when I was back home. I've now been back home for some time with no excuse beyond a mild bout of seasonal lurgy. Done - but that's old news now! -- Nick Kew
Re: [VOTE] Release 2.3.15-beta as beta
On Wed, Nov 9, 2011 at 1:24 PM, Jeff Trawick traw...@gmail.com wrote: Test Summary Report --- t/modules/cgi.t (Wstat: 0 Tests: 53 Failed: 0) Parse errors: Bad plan. You planned 58 tests but ran 53. t/modules/proxy.t (Wstat: 0 Tests: 15 Failed: 2) Failed tests: 9-10 This is probably new-os-install/perl-version syndrome. The t/modules/cgi.t has since disappeared, the request from t/modules/proxy.t that fails verification works fine outside of the framework.
Re: [users@httpd] 2.3.15-beta: module proxy_balancer requires the not automatically loaded module slotmem_shm
On 11/9/2011 4:53 PM, Jim Jagielski wrote: Isn't the point different? If someone enables mod_proxy then the configure script needs to ensure that mod_slotmem is also built… Reporter suggests that *NOT* loading mod_slotmem_shm caused the server to start correctly; exactly the inverse of what we would expect.
Re: [users@httpd] 2.3.15-beta: module proxy_balancer requires the not automatically loaded module slotmem_shm
On 09.11.2011 21:20, William A. Rowe Jr. wrote: On 11/9/2011 4:53 PM, Jim Jagielski wrote: Isn't the point different? If someone enables mod_proxy then the configure script needs to ensure that mod_slotmem is also built… Reporter suggests that *NOT* loading mod_slotmem_shm caused the server to start correctly; exactly the inverse of what we would expect. No, his subject is module proxy_balancer requires the not automatically loaded module slotmem_shm (the not and not to not) and he writes Ok, so I simply removed in the installed default httpd.conf the comment sign within the line #LoadModule slotmem_shm_module modules/mod_slotmem_shm.so and as expected now all works. I think at the moment there is some tendency to further reduce the default active LoadModules to a very small module set (see elsethread) and not activate the other enabled modules. Module set at build time is only loosely coupled to needed modules at run time. Jim's suggestion still makes sense: even if we do not activate most modules by default, some modules have dependencies to other modules and when a module with such a dependency is build (enabled), we could build the dependencies automatically as well. Modules with dependencies are at least mod_ssl (for the session cache), mod_proxy_balancer, and I think the heartbeat stuff. Probably also ldap auth needing mod_ldap. On the other hand we now build most by default and there are all and reallyall, *and* we now only activate few modules by default. So most users should not have a real need to add individual modules to the list of modules to build. IMHO the automatic dependency handling in configure is not a must. We could add after GA if users really need it. Regards, Rainer
Re: [users@httpd] 2.3.15-beta: module proxy_balancer requires the not automatically loaded module slotmem_shm
On 11/10/2011 1:08 AM, Rainer Jung wrote: No, his subject is module proxy_balancer requires the not automatically loaded module slotmem_shm (the not and not to not) and he writes Ok, so I simply removed in the installed default httpd.conf the comment sign within the line #LoadModule slotmem_shm_module modules/mod_slotmem_shm.so and as expected now all works. Thanks for helping me reparse this ;-)
