Info: current module enable status for trunk
Whoever wishes to know, which module is enabled under what conditions: I compiled a list avalable under http://people.apache.org/~rjung/patches/mods_enabled.txt Most of it is done by the script http://people.apache.org/~rjung/patches/mods_enabled.pl (it needs to be started in the trunk directory) with a bit of hand editing w.r.t. the conditionally included modules. I hope the results are correct, at least they look plausible. I think some modules should change. There is a nice default setting, that will enable a module when --enable-modules=all is used. Some of the new modules (and filters) use this default, like mod_sed, some other older modules still stick to no (not even enabled with all) like mod_proxy. I'd say no should be only for unstable, example, debugging and test stuff. Mod_proxy and mod_ssl (if ssl toolkit was detected) make good candidates for moving from no to at least default. The borders between most and default (=all) are vague. It seems parts of default are old stuff not frequently used (e.g. cern_meta, mime_magic), parts are new stuff which didn't yet make it into most (e.g. sed). Regards, Rainer
Re: Info: current module enable status for trunk
On 6/2/2010 3:39 PM, Rainer Jung wrote: Mod_proxy and mod_ssl (if ssl toolkit was detected) make good candidates for moving from no to at least default. mod_ssl was 'no' simply because of concerns about cryptographic law and users in all these crazy jurisdictions. But I'm willing to consider 'yes' on the basis that if openssl is not found, the default becomes 'no'. So the user installing openssl is opening themselves up to accidentally creating a cryptographic channel in httpd, which seems just fine.
Re: Info: current module enable status for trunk
On Wed, Jun 2, 2010 at 5:16 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 6/2/2010 3:39 PM, Rainer Jung wrote: Mod_proxy and mod_ssl (if ssl toolkit was detected) make good candidates for moving from no to at least default. mod_ssl was 'no' simply because of concerns about cryptographic law and users in all these crazy jurisdictions. But I'm willing to consider 'yes' on the basis that if openssl is not found, the default becomes 'no'. Did you really mean no-yes or no-most for mod_ssl? Or are you also thinking some of the innocuous most move to yes (rewrite, expires, headers). Finally, remember that on unix if you don't do your ./configure homework you end up with all this stuff static. -- Eric Covener cove...@gmail.com
Re: Info: current module enable status for trunk
On 6/2/2010 4:21 PM, Eric Covener wrote: On Wed, Jun 2, 2010 at 5:16 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 6/2/2010 3:39 PM, Rainer Jung wrote: Mod_proxy and mod_ssl (if ssl toolkit was detected) make good candidates for moving from no to at least default. mod_ssl was 'no' simply because of concerns about cryptographic law and users in all these crazy jurisdictions. But I'm willing to consider 'yes' on the basis that if openssl is not found, the default becomes 'no'. Did you really mean no-yes or no-most for mod_ssl? Or are you also thinking some of the innocuous most move to yes (rewrite, expires, headers). Finally, remember that on unix if you don't do your ./configure homework you end up with all this stuff static. Sure, that's the beauty of --enable-mods-shared=most. Yes, I meant 'most' :)
Re: Info: current module enable status for trunk
On Wed, Jun 2, 2010 at 5:26 PM, William A. Rowe Jr. wr...@rowe-clan.netwrote: On 6/2/2010 4:21 PM, Eric Covener wrote: On Wed, Jun 2, 2010 at 5:16 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 6/2/2010 3:39 PM, Rainer Jung wrote: Thanks for the list! Do you know the best way to extract similar data for distros? Mod_proxy and mod_ssl (if ssl toolkit was detected) make good candidates for moving from no to at least default. mod_ssl was 'no' simply because of concerns about cryptographic law and users in all these crazy jurisdictions. But I'm willing to consider 'yes' on the basis that if openssl is not found, the default becomes 'no'. Did you really mean no-yes or no-most for mod_ssl? Or are you also thinking some of the innocuous most move to yes (rewrite, expires, headers). Can we move these from most to yes? expires and headers are probably tiny and will not do any harm and rewrite is so widely used that it's probably a good idea to have it in the yes even if it's not so tiny. Finally, remember that on unix if you don't do your ./configure homework you end up with all this stuff static. Sure, that's the beauty of --enable-mods-shared=most. Yes, I meant 'most' :) The size comment above mostly matters for static. Also, is there any way to have mod_deflate module to auto-detect zlib similar to your mod_ssl recommendations? Sergey
