You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Rainer Jung <ra...@kippdata.de> on 2010/06/03 13:30:46 UTC
Module build defaults for trunk
Reading the feedback on the modules list I posted got me into thinking:
1) Should static module linking be still the default for httpd building?
Of course the question is only relevant for platforms which allow
dynamic linking and if we have APR_HAS_DSO. I know that static linking
is expected to be more secure (but we still build mod_so by default) and
a bit more performant. On the other hand it seems most of the world
actually uses a dynamically linked httpd and the flexibility it provides
during runtime. So isn't it time to switch to dynamic by default - if
the platform supports it - and only build static on demand?
2) Which pre-cooked sets of modules to provide via configure?
Currently the default set (no configure flags) is a mixture of "minimal"
and some additional modules likely because their APACHE_MODULE m4 was
copied.
Then there is "most", "all" and the possibility to enable or disable
individual modules.
I wonder whether some notion of "most" would be a better build default -
but maybe not enabling the built modules by default.
So there would be "most" (default), "all" and "minimal".
Before actually defining the according sets of modules, what do you
think about the general direction?
Rainer
Re: Module build defaults for trunk
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 6/21/2010 3:57 PM, Dan Poirier wrote:
> On 2010-06-21 at 14:32, Stefan Fritsch <sf...@sfritsch.de> wrote:
>
>> On Monday 21 June 2010, Dan Poirier wrote:
>>> But is there any reason why we couldn't just make "all" actually
>>> build all? And I would suggest if there's not a really good
>>> reason, we should just fix "all" to do what it obviously should.
>>> That should be easy now, just delete the current "all" and rename
>>> the new "reallyall" to "all".
>>
>> I would prefer "all" to be everything except those modules that are
>> only useful for developers:
We appear to be overthinking this.
'all' should be ALL.
Everything except unstable/dev/test modules should be 'most'.
If we have some further, optimial module lists, those can become new categories.
Re: Module build defaults for trunk
Posted by Dan Poirier <po...@pobox.com>.
On 2010-06-21 at 14:32, Stefan Fritsch <sf...@sfritsch.de> wrote:
> On Monday 21 June 2010, Dan Poirier wrote:
>> But is there any reason why we couldn't just make "all" actually
>> build all? And I would suggest if there's not a really good
>> reason, we should just fix "all" to do what it obviously should.
>> That should be easy now, just delete the current "all" and rename
>> the new "reallyall" to "all".
>
> I would prefer "all" to be everything except those modules that are
> only useful for developers:
...
> BTW, is there a better name for "reallyall" that makes clear that it
> is geared towards developers? I thought "lint" (suggested by someone
> on the list) didn't sound descriptive enough to me. But maybe it's
> still better than "reallyall".
If that's the motivation, how about "maintainer", since we already have
--enable-maintainer-mode?
Dan
Re: Module build defaults for trunk
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Monday 21 June 2010, Dan Poirier wrote:
> On 2010-06-10 at 16:46, Stefan Fritsch <sf...@sfritsch.de> wrote:
> > On Monday 07 June 2010, Rainer Jung wrote:
> >> - build "most" module set by default.
> >>
> >> Alternatives are:
> >> - all
> >> - few (same set as was default before the change)
> >> - none
> >
> > I would like to have an option for developers/testers that builds
> > every module that can be built with the currently installed
> > libraries. The attached patch adds a "reallyall" set. My auto-fu
> > could be better but the patch works for me (tm). Of course, I am
> > open for better names than reallyall.
>
> Seems to work for me.
>
> But is there any reason why we couldn't just make "all" actually
> build all? And I would suggest if there's not a really good
> reason, we should just fix "all" to do what it obviously should.
> That should be easy now, just delete the current "all" and rename
> the new "reallyall" to "all".
I would prefer "all" to be everything except those modules that are
only useful for developers:
mod_optional_*_{im,ex}port
mod_bucketeer
examples/mod*
And maybe those that are really not in any usable state or have no
usecase yet:
mod_proxy_fdpass (unless some consumer exists)
mod_serf (doesn't seem stable, but this is not a strong opionion)
If we change "all", do we still want to activate all those modules in
the generated default config?
BTW, is there a better name for "reallyall" that makes clear that it
is geared towards developers? I thought "lint" (suggested by someone
on the list) didn't sound descriptive enough to me. But maybe it's
still better than "reallyall".
Re: Module build defaults for trunk
Posted by Dan Poirier <po...@pobox.com>.
On 2010-06-10 at 16:46, Stefan Fritsch <sf...@sfritsch.de> wrote:
> On Monday 07 June 2010, Rainer Jung wrote:
>> - build "most" module set by default.
>> Alternatives are:
>> - all
>> - few (same set as was default before the change)
>> - none
>
> I would like to have an option for developers/testers that builds
> every module that can be built with the currently installed libraries.
> The attached patch adds a "reallyall" set. My auto-fu could be better
> but the patch works for me (tm). Of course, I am open for better names
> than reallyall.
Seems to work for me.
But is there any reason why we couldn't just make "all" actually build
all? And I would suggest if there's not a really good reason, we should
just fix "all" to do what it obviously should. That should be easy now,
just delete the current "all" and rename the new "reallyall" to "all".
Dan
Re: Module build defaults for trunk
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Monday 07 June 2010, Rainer Jung wrote:
> - build "most" module set by default.
> Alternatives are:
> - all
> - few (same set as was default before the change)
> - none
I would like to have an option for developers/testers that builds
every module that can be built with the currently installed libraries.
The attached patch adds a "reallyall" set. My auto-fu could be better
but the patch works for me (tm). Of course, I am open for better names
than reallyall.
The patch also removes the --enable-distcache option. If the user
requested mod_socache_dc we already know he wants distcache. No need
for a special option (unless it allowed to select the prefix, which it
didn't).
And it also makes the --with-serf option default to /usr. Same
reasoning: If the user requested mod_serf, he wants --with-serf.
Re: Module build defaults for trunk
Posted by Rainer Jung <ra...@kippdata.de>.
On 03.06.2010 13:30, Rainer Jung wrote:
> Reading the feedback on the modules list I posted got me into thinking:
>
> 1) Should static module linking be still the default for httpd building?
>
...
> 2) Which pre-cooked sets of modules to provide via configure?
>
> Currently the default set (no configure flags) is a mixture of "minimal"
> and some additional modules likely because their APACHE_MODULE m4 was
> copied.
>
> Then there is "most", "all" and the possibility to enable or disable
> individual modules.
>
> I wonder whether some notion of "most" would be a better build default -
> but maybe not enabling the built modules by default.
>
> So there would be "most" (default), "all" and "minimal".
I commited the following changes:
- build modules dynamic by default
Except when APR does not support DSO and except
for the modules marked as "static" in m4 (so, core, http)
- build "most" module set by default.
Alternatives are:
- all
- few (same set as was default before the change)
- none
- add flag enable-mods-static
- keep flag enable-mods-shared for compat with existing build scripts
I also adjusted the docs a bit, because of these changes.
Possible next steps:
- Optimize the sets "most" (=default), "all" and "few"
- Decide about the term "few"
I didn't use minimal, because I think minimal is equal to
none (from a logics poinbt of view minimal means no module at all).
- Do we really want three switches, -enable-modules (now: shared),
-enable-mods-shared (for comapt reasons) and -enable-mods-static?
- Enable dynamic MPM building by default.
Rainer
Re: Module build defaults for trunk
Posted by Sander Temme <sc...@apache.org>.
On Jun 3, 2010, at 4:30 AM, Rainer Jung wrote:
> Reading the feedback on the modules list I posted got me into thinking:
>
> 1) Should static module linking be still the default for httpd building?
+1 for dynamic build by default when APR_HAS_DSO.
I don't buy the security argument: if you have sufficient privileges to replace DSO, you can also replace the web server itself. Of course folks should be able to keep building their modules static if they want to.
How much autofoo is required for this and who will write it?
This would be trunk, no changes to 2.2... give 'em a reason to upgrade.
> 2) Which pre-cooked sets of modules to provide via configure?
"minimal" (the minimum needed to run and serve pages)
"default" (a sane set likely to satisfy the majority of users)
"all" (all that could reasonably be used in a deployment scenario)
"lint" (every scrap of code in the tree)
The "lint" option would be mostly of interest to developers who want to ensure that every module in the tree can be built and tested.
If we build a module, we should turn it on (LoadModule). If the user doesn't want it turned on, they shouldn't build it. If a distributor wants to build a module and not turn it on by default, they can munge the configuration file (and many have done so).
How much additional autofoo would be needed for this, and who will write it?
Again, no changes to 2.2.x, trunk only.
S.
>
> Currently the default set (no configure flags) is a mixture of "minimal" and some additional modules likely because their APACHE_MODULE m4 was copied.
>
> Then there is "most", "all" and the possibility to enable or disable individual modules.
>
> I wonder whether some notion of "most" would be a better build default - but maybe not enabling the built modules by default.
>
> So there would be "most" (default), "all" and "minimal".
>
> Before actually defining the according sets of modules, what do you think about the general direction?
>
> Rainer
>
>
--
Sander Temme
sctemme@apache.org
PGP FP: FC5A 6FC6 2E25 2DFD 8007 EE23 9BB8 63B0 F51B B88A
Re: Module build defaults for trunk
Posted by Nick Kew <ni...@webthing.com>.
On 3 Jun 2010, at 12:30, Rainer Jung wrote:
> Reading the feedback on the modules list I posted got me into thinking:
>
> 1) Should static module linking be still the default for httpd building?
No. But we shouldn't change that within the 2.2.x line.
> 2) Which pre-cooked sets of modules to provide via configure?
A question to which a satisfactory answer is elusive. But with dynamic
linking we can sidestep the issue by building everything considered
stable by default, and excluding only modules that are considered
less-than mature.
IMHO :)
--
Nick Kew
Re: Module build defaults for trunk
Posted by Nick Kew <ni...@webthing.com>.
On 3 Jun 2010, at 14:59, Rainer Jung wrote:
>
> Right, that's the next topic, which modules to load by default and with which configuration.
Yes, this is another important question. But I think it's helpful to separate them,
because the issue of which modules are loaded can be delegated rather more
flexibly - to run time as opposed to compile time. We could relatively easily
provide a menu of potted configurations for different tasks. These then
serve as startingpoints for the more elaborate bundles our downstream
packagers love.
In fact, that could itself become an httpd subproject. I suspect some of our
non-coding docs folks might be interested.
--
Nick Kew
Re: Module build defaults for trunk
Posted by Rainer Jung <ra...@kippdata.de>.
On 03.06.2010 15:28, Jeff Trawick wrote:
> Here's a missing piece: A good generic httpd build has DSOs for all
> modules that could work on the system, but a nice httpd.conf loads only
> the modules that are necessary. Meanwhile, our module build system
> assumes that you wish to actively use the modules specified when you
> invoke configure.
>
> Different distros handle this in different ways, but the generic user
> who just wants to get past ./configure without doing anything stupid
> most likely ends up with many modules loaded which won't be used (extra
> security exposure, CPU, and memory).
Right, that's the next topic, which modules to load by default and with
which configuration.
I hope we won't have to do to much work on the configuration topic
(discussion might be hard like the ongoing deflate discussion shows),
but instead will come to an easier conclusion about a core module set we
want loaded by default. I expect most of those core modules already have
an acceptable configuration in the current config.
So after waiting a bit for more feedback on the general direction we can
proceed with agreeing on a "most" list, a "minimal" list and which of
those should be loaded by default.
Rainer
Re: Module build defaults for trunk
Posted by Jeff Trawick <tr...@gmail.com>.
On Thu, Jun 3, 2010 at 7:46 AM, Eric Covener <co...@gmail.com> wrote:
> On Thu, Jun 3, 2010 at 7:30 AM, Rainer Jung <ra...@kippdata.de>
> wrote:
> > Reading the feedback on the modules list I posted got me into thinking:
> >
> > 1) Should static module linking be still the default for httpd building?
> >
> > Of course the question is only relevant for platforms which allow dynamic
> > linking and if we have APR_HAS_DSO. I know that static linking is
> expected
> > to be more secure (but we still build mod_so by default) and a bit more
> > performant. On the other hand it seems most of the world actually uses a
> > dynamically linked httpd and the flexibility it provides during runtime.
> So
> > isn't it time to switch to dynamic by default - if the platform supports
> it
> > - and only build static on demand?
>
> +1 on dynamic by default when APR_HAS_DSO
>
> > I wonder whether some notion of "most" would be a better build default -
> but
> > maybe not enabling the built modules by default.
> >
> > So there would be "most" (default), "all" and "minimal".
>
>
> +1 on default == most.
>
> (agree with Nick re: 2.2.x as ewll)
>
>
Here's a missing piece: A good generic httpd build has DSOs for all modules
that could work on the system, but a nice httpd.conf loads only the modules
that are necessary. Meanwhile, our module build system assumes that you
wish to actively use the modules specified when you invoke configure.
Different distros handle this in different ways, but the generic user who
just wants to get past ./configure without doing anything stupid most likely
ends up with many modules loaded which won't be used (extra security
exposure, CPU, and memory).
Re: Module build defaults for trunk
Posted by Eric Covener <co...@gmail.com>.
On Thu, Jun 3, 2010 at 7:30 AM, Rainer Jung <ra...@kippdata.de> wrote:
> Reading the feedback on the modules list I posted got me into thinking:
>
> 1) Should static module linking be still the default for httpd building?
>
> Of course the question is only relevant for platforms which allow dynamic
> linking and if we have APR_HAS_DSO. I know that static linking is expected
> to be more secure (but we still build mod_so by default) and a bit more
> performant. On the other hand it seems most of the world actually uses a
> dynamically linked httpd and the flexibility it provides during runtime. So
> isn't it time to switch to dynamic by default - if the platform supports it
> - and only build static on demand?
+1 on dynamic by default when APR_HAS_DSO
> I wonder whether some notion of "most" would be a better build default - but
> maybe not enabling the built modules by default.
>
> So there would be "most" (default), "all" and "minimal".
+1 on default == most.
(agree with Nick re: 2.2.x as ewll)
--
Eric Covener
covener@gmail.com